Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

don't try to create failures/ directory in upstream repo #15526

Merged
merged 1 commit into from
Mar 18, 2020

Conversation

germasch
Copy link
Contributor

When trying to use an upstream spack repository that is read-only, in particular,
the one on Summit, I got an error because Spack was trying to create the failures/
subdir in the upstream .spack_db.

This adds a little check to prevent slack from trying to mkdir failures/ in an upstream
repo.

When trying to use an upstream spack repository that is read-only, in particular,
the one on Summit, I got an error because Spack was trying to create the failures/
subdir in the upstream .spack_db.

This adds a little check to prevent slack from trying to mkdir failures/ in an upstream
repo.
@tgamblin tgamblin added this to In progress in Spack v0.14.1 release via automation Mar 17, 2020
@scheibelp scheibelp self-assigned this Mar 18, 2020
@scheibelp scheibelp merged commit 3df712a into spack:develop Mar 18, 2020
Spack v0.14.1 release automation moved this from In progress to Done Mar 18, 2020
@scheibelp
Copy link
Member

Thanks!

@germasch germasch deleted the pr/upstream-no-failures branch March 19, 2020 13:46
@tgamblin tgamblin moved this from Done to Reviewer approved in Spack v0.14.1 release Mar 19, 2020
@tgamblin tgamblin moved this from Reviewer approved to Done in Spack v0.14.1 release Mar 20, 2020
tgamblin pushed a commit that referenced this pull request Mar 20, 2020
When trying to use an upstream Spack repository, as of f2aca86 Spack
was attempting to write to the upstream DB based on a new metadata
directory added in that commit. Upstream DBs are read-only, so this
should not occur.

This adds a check to prevent Spack from writing to the upstream DB
likask pushed a commit to likask/spack that referenced this pull request Apr 7, 2020
…upstream_master

* commit 'e2b1737a42c9c0c796671f9dd0c39f623e4c91c0': (1343 commits)
  update CHANGELOG.md for 0.14.1
  version bump: 0.14.1
  multiprocessing: allow Spack to run uninterrupted in background (spack#14682)
  Cray bugfix: TERM missing while reading default target (spack#15381)
  Upstreams: don't write metadata directory to upstream DB (spack#15526)
  Creating versions from urls doesn't modify class attributes (spack#15452)
  bugfix: fix install_missing_compilers option bug from v0.14.0 (spack#15416)
  bugfix: installer.py shouldn't be executable (spack#15386)
  Add function replace_prefix_nullterm for use on mach-o rpaths. (spack#15347)
  ArchSpec: fix semantics of satisfies when not concrete and strict is true (spack#15319)
  suite-sparse: fix installation for v5.X (spack#15326)
  testing:  increase installer coverage (spack#15237)
  bugfix: resolve undefined source_pkg_dir failure (spack#15339)
  Bugfix: resolve StopIteration message attribute failure (spack#15341)
  Recover coverage from subprocesses during unit tests (spack#15354)
  Correct pytest.raises matches to match (spack#15346)
  bugfix:  Add dependents when initializing spec from yaml (spack#15220)
  Uniquify suffixes added to module names (spack#14920)
  bugfix: ensure proper dependency handling for package-only installs (spack#15197)
  Fix for being able to 'spack load' packages that have been renamed. (spack#14348)
  ...

# Conflicts:
#	.travis.yml
#	lib/spack/spack/modules/common.py
#	var/spack/repos/builtin/packages/mofem-cephas/package.py
#	var/spack/repos/builtin/packages/mofem-fracture-module/package.py
#	var/spack/repos/builtin/packages/mofem-users-modules/package.py
#	var/spack/repos/builtin/packages/python/package.py
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

None yet

3 participants