Open sleak-lbl opened 1 year ago
update: the spack dependencies -t elfutils
weirdness might be a red herring .. when I remove the buildcache from mirrors.yaml (and run spack clean -m
), the environment concretizes, but spack dependencies -t elfutils
still has the long list of nonsensical dependencies
I may be seeing something similar to this when I try to build a Spack bootstrap cache:
quellyn@ro-rfe1:/usr/projects/shavano/spack-environments-dev/ATS3I/2.3.0> spack bootstrap mirror --binary-packages ../../spack.bootstrap
==> Adding "clingo-bootstrap@spack+python %gcc target=x86_64" and dependencies to the mirror at /usr/projects/shavano/spack-environments-dev/spack.bootstrap/bootstrap_cache
==> Error: Unknown namespace: repo_lapdev
My current workaround is to clone a fresh copy of Spack and checkout the same hash that I'm using in the other environment. Then from a fresh window on the same system, I source the setup script from my fresh Spack clone and run:
$ spack bootstrap mirror --binary-packages /usr/projects/shavano/spack-environments-dev/spack.bootstrap
That works without issue.
Steps to reproduce
create an environment, and make a local repo for it with some namespace (eg
dev
), and in that repo put (and presumably edit/update) a spack package that you plan to build (in my case, I applied the patch in #34580 to a local copy of the ncview package)install the environment (wherever you like), and push the built package to your buildcache.
create a new environment to build something entirely unrelated to the first environment (in my example, elfutils), but allow that environment to use your buildcache (via
mirrors.yaml
)run
spack concretize
At this point you will get an error like:
==> Error: Unknown namespace: dev
If you make a local repo in the new environment, with the namespace
dev
(but nothing in it), then you get past that error and arrive at a new one:==> Error: Package 'ncview' not found.
It looks like Spack copies the buildcache index to your misc_cache, and then the concretizer baulks when it can't find the repo or package that was used to build some buildcache entry, even if that entry has no relevance to the current environment.
A better action in the event of "unknown thing in cache" would be to ignore the unknown thing.
More info
The tail of the stack trace (with
spack -dv concretize
looks like:but I think the root cause is that this call in
SpackSolverSetup.setup
(inspack/spack/solver/asp.py
)the list of specs to search for possible dependencies includes things that are not relevant. A possible clue is that when I run
spack dependencies -t elfutils
I get the following output:I'm quite confident that elfutils does not depend on, eg, cray-mvapich2, even indirectly, I'm guessing that something in my misc_cache or buildcache has a possible dependency on cray-mvapich2, and that causes cray-mvapich2 to be reported asa dependies for elfutils.
(running
spack clean -m
does not change this behavior, asspack dependencies
repopulates the misc_cache)Error message
No response
Information on your system
General information
spack debug report
and reported the version of Spack/Python/Platform