internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: spack/spack

Issue:
System boost 1.70+ preferred over spack boost < 1.70 when using cmake
### Steps to reproduce the issue

```console
$ apt-get install libboost1.71-all-dev
$ spack install -v range-v3 %gcc@:9 +examples cxxstd=14 ^boost@1.65.0
...

-- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake (found suitable version "1.71.0", minimum required is "1.59.0") found components: date_time program_options 
```

### Information on your system

* **Spack:** 0.16.0-102-623caf85a9
* **Python:** 3.8.6
* **Platform:** linux-ubuntu20.04-zen2
* **Concretizer:** clingo


Following https://cmake.org/cmake/help/latest/module/FindBoost.html#boost-cmake I've tried to fix this by adding this to boost/package.py:

```python
    def setup_dependent_build_environment(self, env, dependent_spec):
        if '^cmake' in dependent_spec and '^boost@:1.69' in dependent_spec:
            env.set('Boost_NO_BOOST_CMAKE', 'ON')
```

but this does not work, you really need to specify `cmake -DBoost_NO_BOOST_CMAKE=ON` on the command line, which is currently awkward from the parent package.


Discussion:

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/boost/package.py b/var/spack/repos/builtin/packages/boost/package.py
--- a/var/spack/repos/builtin/packages/boost/package.py
+++ b/var/spack/repos/builtin/packages/boost/package.py
@@ -539,3 +539,16 @@ def install(self, spec, prefix):
 
     def setup_run_environment(self, env):
         env.set('BOOST_ROOT', self.prefix)
+
+    def setup_dependent_package(self, module, dependent_spec):
+        # Disable find package's config mode for versions of Boost that
+        # didn't provide it. See https://github.com/spack/spack/issues/20169
+        # and https://cmake.org/cmake/help/latest/module/FindBoost.html
+        is_cmake = isinstance(dependent_spec.package, CMakePackage)
+        if self.spec.satisfies('boost@:1.69.0') and is_cmake:
+            args_fn = type(dependent_spec.package).cmake_args
+
+            def _cmake_args(self):
+                return ['-DBoost_NO_BOOST_CMAKE=ON'] + args_fn(self)
+
+            type(dependent_spec.package).cmake_args = _cmake_args


Test patch:
Repository: spack/spack

Issue:
Installation issue: Mesa finds system cmake instead of Spack's cmake
<!-- Thanks for taking the time to report this build failure. To proceed with the report please:

1. Title the issue "Installation issue: <name-of-the-package>".
2. Provide the information required below.

We encourage you to try, as much as possible, to reduce your problem to the minimal example that still reproduces the issue. That would help us a lot in fixing it quickly and effectively! -->

### Steps to reproduce the issue

<!-- Fill in the exact spec you are trying to build and the relevant part of the error message -->
```console
$ spack install -v mesa%gcc@8.3.0 ^cmake%clang ^python%clang ^llvm+shared_libs~clang~compiler-rt~gold~internal_unwind~libcxx~lld~lldb~polly
...
[+] /Users/stam/projects/spack/opt/spack/darwin-mojave-haswell/clang-10.0.1-apple/cmake-3.18.4-h3wyisgau2xqendkfrpt3mumbntsjfmb
...
Run-time dependency zlib found: YES 1.2.11
Found CMake: /Users/stam/anaconda2/envs/main/bin/cmake (3.12.2)
...

```

### Information on your system

<!-- Please include the output of `spack debug report` -->
* **Spack:** 0.16.0-3-b1dc3e787
* **Python:** 3.6.10
* **Platform:** darwin-mojave-haswell

<!-- If you have any relevant configuration detail (custom `packages.yaml` or `modules.yaml`, etc.) you can add that here as well. -->

### General information

<!-- These boxes can be checked by replacing [ ] with [x] or by clicking them after submitting the issue. -->
- [x] I have run `spack debug report` and reported the version of Spack/Python/Platform
- [x] I have run `spack maintainers <name-of-the-package>` and @mentioned any maintainers @chuckatkins 
- [ ] I have uploaded the build log and environment files
- [x] I have searched the issues of this repo and believe this is not a duplicate



Discussion:
@chuckatkins @v-dobrev ping . Have you run into this problem? Should there be a `depends_on(cmake)` in mesa's package file?
Judging by https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/meson.build, it looks like `cmake` may be used by the build system, at least in some cases. However, I'm not sure if `mesa` or `meson` should depend on `cmake` -- technically, I think `mesa` calls `meson` which then finds and calls `cmake`.
It looks like CMake needs to be a runtime-only dependency of meson

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/meson/package.py b/var/spack/repos/builtin/packages/meson/package.py
--- a/var/spack/repos/builtin/packages/meson/package.py
+++ b/var/spack/repos/builtin/packages/meson/package.py
@@ -35,6 +35,7 @@ class Meson(PythonPackage):
     depends_on('python@3.5:', type=('build', 'run'))
     depends_on('py-setuptools', type=('build', 'run'))
     depends_on('ninja', type='run')
+    depends_on('cmake', type='run')
 
     # By default, Meson strips the rpath on installation. This patch disables
     # rpath modification completely to make sure that Spack's rpath changes


Test patch:
Repository: spack/spack

Issue:
improve installation of Zoltran: imposing +int64 constrains on parmetis
<!--*Please add a concise summary of your suggestion here.*-->

### Rationale
zoltan spec has a variant called  `int64` which imposes the corresponding constrain on metis. 
https://github.com/spack/spack/blob/6947951aaf9954b1dfd12ca7a9266d7335f07105/var/spack/repos/builtin/packages/zoltan/package.py#L37-L44

The same constrain must be applied to parmetis. 


<!--*Is your feature request related to a problem? Please describe it!*-->

### Description
I guess a solution can be something like
```
depends_on('parmetis@4:', when='+parmetis') 
depends_on('parmetis@4: +int64', when='+parmetis+int64')
```

<!--*Describe the solution you'd like and the alternatives you have considered.*-->


### Additional information
<!--*Add any other context about the feature request here.*-->
I guess this happens because parmetis package has been recently updated and `int64` has been added. Because there was no such an option in parmetis for a long time people came up with a workaround by specifying `metis+int64` explicitly in their script. The parametis update brings an inconsistency because `int64`   is off by default in parmetis, however, and the ''legacy'' workaround imposes `int64` on metis.
My spack version is 0.16.0

### General information

- [x] I have run `spack --version` and reported the version of Spack
- [x] I have searched the issues of this repo and believe this is not a duplicate



<!--If you want to ask a question about the tool (how to use it, what it can currently do, etc.), try the `#general` channel on our Slack first. We have a welcoming community and chances are you'll get your reply faster and without opening an issue.

Other than that, thanks for taking the time to contribute to Spack!
-->


Discussion:
Your suggestion looks good to me, want to submit a PR?
Thanks. I will submit 

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/zoltan/package.py b/var/spack/repos/builtin/packages/zoltan/package.py
--- a/var/spack/repos/builtin/packages/zoltan/package.py
+++ b/var/spack/repos/builtin/packages/zoltan/package.py
@@ -39,6 +39,7 @@ class Zoltan(AutotoolsPackage):
 
     depends_on('mpi', when='+mpi')
 
+    depends_on('parmetis@4: +int64', when='+parmetis+int64')
     depends_on('parmetis@4:', when='+parmetis')
     depends_on('metis+int64', when='+parmetis+int64')
     depends_on('metis', when='+parmetis')


Test patch:
Repository: spack/spack

Issue:
Problems during install deal.II in spack
Hi everyone, first I want to apologize because I am new into ubuntu, so I could be wrong anywhere.

In order to install a library, I had to clone spack, and then to install deal.II and vtk. 
I followed this code: 


```
.bashrc file: "export SPACK_ROOT=/path/to/spack/
export PATH=${SPACK_ROOT}/bin:${PATH}"
sudo apt install python git curl make g++ gfortran
mkdir -p ${SPACK_ROOT}
cd ${SPACK_ROOT}
git clone https://github.com/spack/spack.git .
spack install environment-modules
.bashrc file: "source $(spack location -i environment-modules)/init/bash
source ${SPACK_ROOT}/share/spack/setup-env.sh"
```

Up to this point, everything seems fine, and I got no errors. 
Then I install 

`spack install dealii@9.2.0 ^suite-sparse@5.2.0`

And I get errors as you see in the screen. 
Do you have any ideas about what could I do? Thanks everyone! 
<img width="595" alt="errore dealii" src="https://user-images.githubusercontent.com/56541934/102512972-ed8c6e00-408a-11eb-8e5c-aff82b0d2a04.PNG">






Discussion:
@davydden  @jppelteret  @luca-heltai
As far as dealii is concerned, we don't use netcdf support from trilinos. Can you try and see if 

~~~
spack install dealii@9.2.0 ^trilinos~netcdf
~~~
succeeds?



> As far as dealii is concerned, we don't use netcdf support from trilinos. Can you try and see if
> 
> ```
> spack install dealii@9.2.0 ^trilinos~netcdf
> ```
> 
> succeeds?

Thanks a lot for the answer!
Unfortunately it doesn't work, this is what I get: 

<img width="590" alt="mandare" src="https://user-images.githubusercontent.com/56541934/103180173-901acd00-4893-11eb-9d3f-a517a7382df4.PNG">

Hi @SalvoBella!

The following should work (just tested succesfully):
```
spack install dealii@9.2.0 ^boost@1.72.0 ^mumps@5.2.0 ^trilinos~exodus~netcdf
```

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/dealii/package.py b/var/spack/repos/builtin/packages/dealii/package.py
--- a/var/spack/repos/builtin/packages/dealii/package.py
+++ b/var/spack/repos/builtin/packages/dealii/package.py
@@ -181,6 +181,8 @@ class Dealii(CMakePackage, CudaPackage):
     depends_on('slepc@:3.6.3',     when='@:8.4.1+slepc+petsc+mpi')
     depends_on('slepc~arpack',     when='+slepc+petsc+mpi+int64')
     depends_on('sundials@:3~pthread', when='@9.0:+sundials')
+    # FIXME: next line fixes concretization with trilinos and adol-c
+    depends_on('trilinos~exodus~netcdf',    when='@9.0:+adol-c+trilinos')
     depends_on('trilinos gotype=int', when='+trilinos@12.18.1:')
     # Both Trilinos and SymEngine bundle the Teuchos RCP library.
     # This leads to conflicts between macros defined in the included


Test patch:
Repository: spack/spack

Issue:
Feature/r-genefilter updated to version 1.72.0

update version to avoid compile error
update version to avoid this issue:
```
/home/spack-develop/lib/spack/env/gcc/g++ -std=gnu++11 -shared -L/home/spack-develop/opt/spack/linux-centos8-aarch64/gcc-8.3.1/r-4.0.2-kyflwfdhj63kvb67y5z7fqbxsb6sxcfe/rlib/R/lib -L/home/spack-develop/opt/spack/linux-centos8-aarch64/gcc-8.3.1/r-4.0.2-kyflwfdhj63kvb67y5z7fqbxsb6sxcfe/rlib/R/lib -Wl,-rpath,/home/spack-develop/opt/spack/linux-centos8-aarch64/gcc-8.3.1/r-4.0.2-kyflwfdhj63kvb67y5z7fqbxsb6sxcfe/rlib/R/lib -o genefilter.so half_range_mode.o init.o nd.o pAUC.o rowPAUCs.o rowttests.o ttest.o -lgfortran -lm -L/home/spack-develop/opt/spack/linux-centos8-aarch64/gcc-8.3.1/r-4.0.2-kyflwfdhj63kvb67y5z7fqbxsb6sxcfe/rlib/R/lib -lR
installing to /home/spack-develop/opt/spack/linux-centos8-aarch64/gcc-8.3.1/r-genefilter-1.66.0-yrlczxbuim4tcivg2marptqkjgpxuafu/rlib/R/library/00LOCK-spack-src/00new/genefilter/libs
** R
** data
*** moving datasets to lazyload DB
** inst
** byte-compile and prepare package for lazy loading
Error: objects 'rowSums', 'colSums', 'rowMeans', 'colMeans' are not exported by 'namespace:S4Vectors'
Execution halted
ERROR: lazy loading failed for package 'genefilter'
* removing '/home/spack-develop/opt/spack/linux-centos8-aarch64/gcc-8.3.1/r-genefilter-1.66.0-yrlczxbuim4tcivg2marptqkjgpxuafu/rlib/R/library/genefilter'
```


Discussion:
Hmm, https://bioconductor.org/packages/release/bioc/html/genefilter.html only lists the previous release. Anyway, it looks like the dependencies are out-of-date and need to be updated.


Resolving patch:
diff --git a/var/spack/repos/builtin/packages/r-genefilter/package.py b/var/spack/repos/builtin/packages/r-genefilter/package.py
--- a/var/spack/repos/builtin/packages/r-genefilter/package.py
+++ b/var/spack/repos/builtin/packages/r-genefilter/package.py
@@ -13,13 +13,15 @@ class RGenefilter(RPackage):
     homepage = "https://bioconductor.org/packages/genefilter"
     git      = "https://git.bioconductor.org/packages/genefilter.git"
 
+    version('1.72.0', commit='8cb0b2e73531a417d53e5625bcf436265cdbe101')
     version('1.66.0', commit='1c4c471ccca873bf92dcf0b50f611eaa64c4f0cf')
     version('1.64.0', commit='82e91b7751bae997b9c898c219ea201fd02a8512')
     version('1.62.0', commit='eb119894f015c759f93f458af7733bdb770a22ad')
     version('1.60.0', commit='c98f695253c330a9380b2b4ffa27f3b7d66773e4')
     version('1.58.1', commit='ace2556049677f60882adfe91f8cc96791556fc2')
 
-    depends_on('r-s4vectors@0.9.42:', type=('build', 'run'))
+    depends_on('r-biocgenerics@0.31.2:', type=('build', 'run'), when='@1.68.0:')
+    depends_on('r-s4vectors@0.9.42:', type=('build', 'run'), when='@:1.66.0')
     depends_on('r-annotationdbi', type=('build', 'run'))
     depends_on('r-annotate', type=('build', 'run'))
     depends_on('r-biobase', type=('build', 'run'))


Test patch:
Repository: spack/spack

Issue:
Open MPI 4.0.5 build fails on macOS 10.15: libevent
I am trying to install Open MPI 4.0.5 on macOS 10.15 via Spack using AppleClang as the compiler. The instance runs on Azure Pipelines as part of my quality assurance scripts, since I don't own a mac.

Following a build error on macOS 10.15 and checking the homebrew recipes, I think Open MPI depends on libevent.

### Steps to reproduce the issue

```console
$ spack install openmpi
```

### Information on your system

* Operating system/version: macOS 10.15
* Computer hardware: x86_64
* Network type: Azure Pipelines / cloud (single node, 2 vcores)

### Additional information

Build log: [341.txt](https://github.com/spack/spack/files/5765811/341.txt)

Open MPI bug report: https://github.com/open-mpi/ompi/issues/8332

Declared dependencies in Homebrew include `libevent`: https://github.com/Homebrew/homebrew-core/blob/master/Formula/open-mpi.rb

Proposed fix: #20658

### General information

N/A

cc package maintainer @hppritcha


Discussion:
Upstream maintainer feedback from my bug report:

> [libevent] is required on all platforms.
>
> Open MPI has an embedded copy of libevent, however. I think your issue is this: https://www.open-mpi.org/faq/?category=building#libevent-or-hwloc-errors-when-linking-fortran
>
> Be sure to also read: https://www.open-mpi.org/faq/?category=building#internal-or-external-hwloc-and-libevent

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/openmpi/package.py b/var/spack/repos/builtin/packages/openmpi/package.py
--- a/var/spack/repos/builtin/packages/openmpi/package.py
+++ b/var/spack/repos/builtin/packages/openmpi/package.py
@@ -266,6 +266,8 @@ class Openmpi(AutotoolsPackage):
 
     depends_on('pkgconfig', type='build')
 
+    depends_on('libevent@2.0:', when='@4:')
+
     depends_on('hwloc@2.0:', when='@4:')
     # ompi@:3.0.0 doesn't support newer hwloc releases:
     # "configure: error: OMPI does not currently support hwloc v2 API"
@@ -676,6 +678,9 @@ def configure_args(self):
         if spec.satisfies('+lustre'):
             lustre_opt = '--with-lustre={0}'.format(spec['lustre'].prefix)
             config_args.append(lustre_opt)
+        # external libevent
+        if spec.satisfies('@4.0.0:'):
+            config_args.append('--with-libevent={0}'.format(spec['libevent'].prefix))
         # Hwloc support
         if spec.satisfies('@1.5.2:'):
             config_args.append('--with-hwloc={0}'.format(spec['hwloc'].prefix))


Test patch:
Repository: spack/spack

Issue:
mumps@5.3.3 fails: patch rejected
`mumps@5.3.3` is failing, I think, because of the patch introduced with 0150b394d7df0a3b6104f061514dfa5539bddde0

Using:
* `spack@develop` (1e971b62de76d731d5a220a0b271e105bf01caca)
* `Mon Dec 28 13:48:20 2020 -0800`
* Ubuntu 18.04 on x86_64

Concrete spec: [mumps-nnlqlp.spec.yaml.txt](https://github.com/spack/spack/files/5748938/mumps-nnlqlp.spec.yaml.txt)

```
$> spack install -f ./mumps-nnlqlp.spec.yaml
...
==> Installing mumps-5.3.3-nnlqlpa4wpvksountoctpeu25pndj2ui
==> Fetching https://spack-llnl-mirror.s3-us-west-2.amazonaws.com/_source-cache/archive/27/27e7749ac05006bf8e81a457c865402bb72a42bf3bc673da49de1020f0f32011.tar.gz
##################################################################################################################################################################### 100.0%
1 out of 2 hunks FAILED -- saving rejects to file src/Makefile.rej
==> Patch /opt/spack/var/spack/repos/builtin/packages/mumps/mumps.src-makefile.patch failed.
==> Error: ProcessError: Command exited with status 1:
    '/usr/bin/patch' '-s' '-p' '1' '-i' '/opt/spack/var/spack/repos/builtin/packages/mumps/mumps.src-makefile.patch' '-d' '.'
```

@payerle @adamjstewart @scottwittenburg 


Discussion:
@payerle Do you know why these are getting rejected? What version of mumps did you test this with? The src/Makefile lines targeted for patching don't match the patch file with mumps 3.3, did you test on a different version? Do we need to maintain two different patches -- one for the version you tested this with and one for mumps 3.3?
My bad.  I tested with mumps@5.2.0, and it looks like they changed ordering of some of the include -I flags between that and 5.3.3.

It looks like two versions of the patch are needed.

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/mumps/package.py b/var/spack/repos/builtin/packages/mumps/package.py
--- a/var/spack/repos/builtin/packages/mumps/package.py
+++ b/var/spack/repos/builtin/packages/mumps/package.py
@@ -55,7 +55,8 @@ class Mumps(Package):
     patch('gfortran8.patch', when='@5.1.2')
     # The following patches src/Makefile to fix some dependency
     # issues in lib[cdsz]mumps.so
-    patch('mumps.src-makefile.patch', when='+shared')
+    patch('mumps.src-makefile.5.2.patch', when='@5.2.0 +shared')
+    patch('mumps.src-makefile.5.3.patch', when='@5.3.0: +shared')
 
     def write_makefile_inc(self):
         if ('+parmetis' in self.spec or '+ptscotch' in self.spec) and (
@@ -79,6 +80,8 @@ def write_makefile_inc(self):
         orderings = ['-Dpord']
         # All of the lib[cdsz]mumps.* libs depend on mumps_common
         extra_libs4mumps = ['-L$(topdir)/lib', '-lmumps_common']
+        # and mumps_common depends on pord
+        extra_libs4mumps += ['-L$(topdir)/PORD/lib', '-lpord']
 
         if '+ptscotch' in self.spec or '+scotch' in self.spec:
             makefile_conf.extend([


Test patch:
Repository: spack/spack

Issue:
Porting of Anuga code 
Dear Team,

Wanted to integrate Anuga code to spack list.
https://github.com/GeoscienceAustralia/anuga_core



Discussion:
PRs are always welcome! It looks like Anuga is a simple Python program. In that case, the following docs may be helpful: https://spack.readthedocs.io/en/latest/build_systems/pythonpackage.html

I'm more than happy to review any PRs once you get a simple package working.
@adamjstewart  I feel like need to go through python and porting python packages in Spack.
I tried it hard but couldn't succeed yet. 
Can I get help for porting the same? 


Resolving patch:
diff --git a/var/spack/repos/builtin/packages/py-anuga/package.py b/var/spack/repos/builtin/packages/py-anuga/package.py
new file mode 100644
--- /dev/null
+++ b/var/spack/repos/builtin/packages/py-anuga/package.py
@@ -0,0 +1,32 @@
+# Copyright 2013-2021 Lawrence Livermore National Security, LLC and other
+# Spack Project Developers. See the top-level COPYRIGHT file for details.
+#
+# SPDX-License-Identifier: (Apache-2.0 OR MIT)
+
+from spack import *
+
+
+class PyAnuga(PythonPackage):
+    """ANUGA (pronounced "AHnooGAH") is open-source software for the simulation
+    of the shallow water equation, in particular it can be used to model
+    tsunamis and floods."""
+
+    homepage = "https://github.com/GeoscienceAustralia/anuga_core"
+    url      = "https://github.com/GeoscienceAustralia/anuga_core/archive/2.1.tar.gz"
+
+    version('2.1', sha256='0e56c4a7d55570d7b2c36fa9b53ee4e7b85f62be0b4c03ad8ab5f51464321d2f')
+
+    variant('mpi', default=True, description='Install anuga_parallel')
+
+    # At present AnuGA has only been run and tested using python 2.x.
+    # We recommend python 2.7.
+    depends_on('python@2.6:2.8', type=('build', 'run'))
+    depends_on('py-setuptools@:44', type='build')
+    depends_on('py-numpy@:1.16', type=('build', 'run'))
+    depends_on('py-netcdf4', type=('build', 'run'))
+    depends_on('py-matplotlib@:2', type=('build', 'run'))
+    depends_on('gdal@:3.2+python', type=('build', 'run'))
+    depends_on('py-pypar', when='+mpi', type=('build', 'run'))
+
+    # https://github.com/GeoscienceAustralia/anuga_core/issues/247
+    conflicts('%apple-clang@12:')


Test patch:
Repository: spack/spack

Issue:
Spack stages file/directory permissions hardcoded to `700`
Currently, the spack stages directory & file permissions are set to `700`. I believe this is only due to historical reasons.

Basically, this behavior was added here https://github.com/spack/spack/pull/8773/commits/be7c5f684e80f63293380cb309b1c7bf4e9c7f8e#diff-ef561cde79864134a9c7c4fd5746f04535ebcf460065d212ba2d5d07986b9e93. I can only assume that someone noticed that the file permissions for temporary files are `700` by default and so ported this behavior also for normal stage directories.

Later on, temporary stage directories were removed here https://github.com/spack/spack/pull/12072 and now normal stage directories are stuck with hardcoded `700` file permissions.

This is overly restrictive and an issue if one wants to inspect someone else's stage directory (e.g., to look at the build log). Specifically, we use jenkins to build spack packages nightly. When they fail, the build logs are only accessible to the jenkins user.

Permissions of the install directories are configurable (https://spack.readthedocs.io/en/latest/build_settings.html#package-permissions) whereas stage directories have hardcoded permissions:
https://github.com/spack/spack/blob/af9bf816fe17a92f56ca0354779ac2fa7892f377/lib/spack/spack/stage.py#L601-L614

I think at least group members should get read permissions. Possibly this should also be configurable.


Discussion:

Resolving patch:
diff --git a/lib/spack/spack/stage.py b/lib/spack/spack/stage.py
--- a/lib/spack/spack/stage.py
+++ b/lib/spack/spack/stage.py
@@ -603,12 +603,12 @@ def create(self):
         """
         Ensures the top-level (config:build_stage) directory exists.
         """
-        # Emulate file permissions for tempfile.mkdtemp.
+        # User has full permissions and group has only read permissions
         if not os.path.exists(self.path):
-            mkdirp(self.path, mode=stat.S_IRWXU)
+            mkdirp(self.path, mode=stat.S_IRWXU | stat.S_IRGRP | stat.S_IXGRP)
         elif not os.path.isdir(self.path):
             os.remove(self.path)
-            mkdirp(self.path, mode=stat.S_IRWXU)
+            mkdirp(self.path, mode=stat.S_IRWXU | stat.S_IRGRP | stat.S_IXGRP)
 
         # Make sure we can actually do something with the stage we made.
         ensure_access(self.path)


Test patch: