internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: easybuilders/easybuild-easyblocks

Issue:
Add ability to turn off LAPACK in ESMF
I have found myself in the situation where I want to build ESMF without LAPACK dependent code paths - the EasyBlock forces the build into the 'user specified LAPACK' mode and doesn't allow this (unless I'm missing something!).

Adding an extra option to disable LAPACK would allow for non-LAPACK builds. PR to follow.


Discussion:

Resolving patch:
diff --git a/easybuild/easyblocks/e/esmf.py b/easybuild/easyblocks/e/esmf.py
--- a/easybuild/easyblocks/e/esmf.py
+++ b/easybuild/easyblocks/e/esmf.py
@@ -39,11 +39,20 @@
 from easybuild.tools.modules import get_software_root, get_software_version
 from easybuild.tools.run import run_cmd
 from easybuild.tools.systemtools import get_shared_lib_ext
+from easybuild.framework.easyconfig import CUSTOM
 
 
 class EB_ESMF(ConfigureMake):
     """Support for building/installing ESMF."""
 
+    @staticmethod
+    def extra_options():
+        """Custom easyconfig parameters for ESMF"""
+        extra_vars = {
+            'disable_lapack': [False, 'Disable external LAPACK - True or False', CUSTOM]
+        }
+        return ConfigureMake.extra_options(extra_vars)
+
     def configure_step(self):
         """Custom configuration procedure for ESMF through environment variables."""
 
@@ -75,13 +84,19 @@ def configure_step(self):
         env.setvar('ESMF_COMM', comm)
 
         # specify decent LAPACK lib
-        env.setvar('ESMF_LAPACK', 'user')
-        ldflags = os.getenv('LDFLAGS')
-        liblapack = os.getenv('LIBLAPACK_MT') or os.getenv('LIBLAPACK')
-        if liblapack is None:
-            raise EasyBuildError("$LIBLAPACK(_MT) not defined, no BLAS/LAPACK in %s toolchain?", self.toolchain.name)
+        if self.cfg['disable_lapack']:
+            env.setvar('ESMF_LAPACK', 'OFF')
+            # MOAB can't be built without LAPACK
+            env.setvar('ESMF_MOAB', 'OFF')
         else:
-            env.setvar('ESMF_LAPACK_LIBS', ldflags + ' ' + liblapack)
+            env.setvar('ESMF_LAPACK', 'user')
+            ldflags = os.getenv('LDFLAGS')
+            liblapack = os.getenv('LIBLAPACK_MT') or os.getenv('LIBLAPACK')
+            if liblapack is None:
+                msg = "$LIBLAPACK(_MT) not defined, no BLAS/LAPACK in %s toolchain?"
+                raise EasyBuildError(msg, self.toolchain.name)
+            else:
+                env.setvar('ESMF_LAPACK_LIBS', ldflags + ' ' + liblapack)
 
         # specify netCDF
         netcdf = get_software_root('netCDF')


Test patch:
Repository: easybuilders/easybuild-easyblocks

Issue:
crash when installing EasyBuild using older EasyBuild version with updated EasyBuildMeta easyblock
When installing (the latest or a recent version of) EasyBuild using an older EasyBuild version, and using the updated `EasyBuildMeta` easyblock from https://github.com/easybuilders/easybuild-easyblocks/pull/2805 (which does the installation using `pip` and fixes compatibility with recent `setuptools` versions), a crash occurs because of the changes to the `PythonPackage` easyblock that were done in #2828 .

```
$ eb --version
This is EasyBuild 4.5.0 ...

$ eb --install-latest-eb-release --include-easyblocks-from-pr 2805
...
  File "/tmp/eb-vdp62f2m/included-easyblocks-keqxive1/easybuild/easyblocks/easybuildmeta.py", line 277, in sanity_check_step
    super(EB_EasyBuildMeta, self).sanity_check_step(custom_paths=custom_paths, custom_commands=custom_commands)
  File "/tmp/eb-vdp62f2m/included-easyblocks-keqxive1/easybuild/easyblocks/generic/pythonpackage.py", line 796, in sanity_check_step
    if not self.sanity_check_module_loaded:
AttributeError: 'EB_EasyBuildMeta' object has no attribute 'sanity_check_module_loaded'
```

The problem here is that using `--include-easyblocks-from-pr 2805` not only pulls in the updated `EasyBuildMeta` easyblock from `develop` (since #2805 is merged), but also the updated `PythonPackage` easyblock (which includes the changes from #2828).
The latter relies on the changes made to EasyBuild framework in https://github.com/easybuilders/easybuild-framework/pull/4125, which are only included in EasyBuild >= 4.7.0 .

We should try and avoid this, since it break a typical way of updating EasyBuild (both only if `--include-easyblocks-from-pr 2805` is used, which may be necessary due to having a recent `setuptools`).


Discussion:

Resolving patch:
diff --git a/easybuild/easyblocks/generic/pythonpackage.py b/easybuild/easyblocks/generic/pythonpackage.py
--- a/easybuild/easyblocks/generic/pythonpackage.py
+++ b/easybuild/easyblocks/generic/pythonpackage.py
@@ -793,7 +793,7 @@ def sanity_check_step(self, *args, **kwargs):
         # load module early ourselves rather than letting parent sanity_check_step method do so,
         # since custom actions taken below require that environment is set up properly already
         # (especially when using --sanity-check-only)
-        if not self.sanity_check_module_loaded:
+        if hasattr(self, 'sanity_check_module_loaded') and not self.sanity_check_module_loaded:
             extension = self.is_extension or kwargs.get('extension', False)
             extra_modules = kwargs.get('extra_modules', None)
             self.fake_mod_data = self.sanity_check_load_module(extension=extension, extra_modules=extra_modules)


Test patch:
Repository: easybuilders/easybuild-easyblocks

Issue:
building Clang with NVPTX support is broken
problem was introduced in #2800, by using `get_software_root` in easyblock constructor to check whether CUDA is included as a dependency, while dependencies are only loaded during `prepare` step...


Discussion:
CUDA detection should be done similarly to what is done in LAMMPS (https://github.com/easybuilders/easybuild-easyblocks/blob/develop/easybuild/easyblocks/l/lammps.py#L175-L177). You need the configuration to work also when using `--module-only`, so there are limited options to move the detection elsewhere

Resolving patch:
diff --git a/easybuild/easyblocks/c/clang.py b/easybuild/easyblocks/c/clang.py
--- a/easybuild/easyblocks/c/clang.py
+++ b/easybuild/easyblocks/c/clang.py
@@ -177,18 +177,21 @@ def __init__(self, *args, **kwargs):
         build_targets = self.cfg['build_targets']
         # define build_targets if not set
         if build_targets is None:
+            deps = [dep['name'].lower() for dep in self.cfg.dependencies()]
             arch = get_cpu_architecture()
             try:
                 default_targets = DEFAULT_TARGETS_MAP[arch][:]
                 # If CUDA is included as a dep, add NVPTX as a target
-                if get_software_root("CUDA"):
-                    default_targets += ["NVPTX"]
+                # There are (old) toolchains with CUDA as part of the toolchain
+                cuda_toolchain = hasattr(self.toolchain, 'COMPILER_CUDA_FAMILY')
+                if 'cuda' in deps or cuda_toolchain:
+                    default_targets += ['NVPTX']
                 # For AMDGPU support we need ROCR-Runtime and
                 # ROCT-Thunk-Interface, however, since ROCT is a dependency of
                 # ROCR we only check for the ROCR-Runtime here
                 # https://openmp.llvm.org/SupportAndFAQ.html#q-how-to-build-an-openmp-amdgpu-offload-capable-compiler
-                if get_software_root("ROCR-Runtime"):
-                    default_targets += ["AMDGPU"]
+                if 'rocr-runtime' in deps:
+                    default_targets += ['AMDGPU']
                 self.cfg['build_targets'] = build_targets = default_targets
                 self.log.debug("Using %s as default build targets for CPU/GPU architecture %s.", default_targets, arch)
             except KeyError:


Test patch:
Repository: easybuilders/easybuild-easyblocks

Issue:
New sanity check commands for netCDF break build of older netCDF
This one took me a while to chase down. It might be a wontfix due to old software, but maybe this issue can at least serve as an FFR.

N.b. the easybuild and netCDF tag numbers are very similar here.

[In easybuild v4.6.2 some `nc-config` and `ncgen` sanity check commands were added to the netCDF easyblock](https://github.com/easybuilders/easybuild-easyblocks/commit/d8aa9420be572ab4df2c5993c5a3cdf370623404).

The command `ncgen -h`, in particular, should show the help text for `ncgen`. However, up until netCDF v4.6.1, `ncgen -h` meant running `ncgen` in 'header-only" mode, while `-H` was used for help. These flags were switched in [this commit](https://github.com/Unidata/netcdf-c/commit/2ea1cf5f1bc2a7352e3f66721f5181e26e556011#diff-6f23c24b125838dbee16fd3fd9edf84acc7a0492bd223c5ed03e9095cd50b15e) which first appeared in netCDF v4.6.2.

The problem is that when `ncgen` is run without any other args, or similarly, in "header-only" mode, it waits for stdin until an EOF. This causes the `ncgen` sanity check in the new easyblock to fail.

I think the fix would be to check `ncgen -H` instead of `ncgen -h` for netCDF older than v4.6.2.


Discussion:

Resolving patch:
diff --git a/easybuild/easyblocks/n/netcdf.py b/easybuild/easyblocks/n/netcdf.py
--- a/easybuild/easyblocks/n/netcdf.py
+++ b/easybuild/easyblocks/n/netcdf.py
@@ -143,7 +143,7 @@ def sanity_check_step(self):
 
         custom_commands = [
             "nc-config --help",
-            "ncgen -h",
+            "ncgen -h" if LooseVersion(self.version) > LooseVersion("4.6.1") else "ncgen -H",
         ]
 
         super(EB_netCDF, self).sanity_check_step(custom_commands=custom_commands, custom_paths=custom_paths)


Test patch:
Repository: easybuilders/easybuild-easyblocks

Issue:
Update version of `config.guess` used by `ConfigureMake`
The version of `config.guess` that we use is from 2018. Looking at https://git.savannah.gnu.org/cgit/config.git/log/config.guess it is probably important that we update it for RISC-V support


Discussion:
I agree we should use a more recent `config.guess`, but hopefully this won't lead to nasty surprises, since it will be difficult to ensure we don't introduce any regressions by doing so...

We should also use a `cgit` download URL, see https://git.savannah.gnu.org/cgit/config.git/commit/config.guess?id=888c8e3d5f7bf7464bba83aaf54304a956eefa60
In addition, we should check if we should also download `config.sub` alongside `config.guess`
I'm thinking about adding `CONFIG_GUESS_VERSION` as part of the `config.guess` filename. That way every version of EB will always use the same version of the file. Right now, if you we update the `eb` version and then someone uses an older version of `eb` to install something you will get an error about the checksum/dates not matching.
I looked into `config.sub` and according to the docs:
> `configure` recognizes short aliases for many system types; for example, `decstation` can be used instead of `mips-dec-ultrix4.2`. `configure` runs a script called `config.sub` to canonicalize system type aliases.

It's a good bit of work to add `config.sub` and I don't see it having any value for us since we are getting the system type from `config.guess`

Resolving patch:
diff --git a/easybuild/easyblocks/generic/configuremake.py b/easybuild/easyblocks/generic/configuremake.py
--- a/easybuild/easyblocks/generic/configuremake.py
+++ b/easybuild/easyblocks/generic/configuremake.py
@@ -34,6 +34,7 @@
 @author: Toon Willems (Ghent University)
 @author: Maxime Boissonneault (Compute Canada - Universite Laval)
 @author: Alan O'Cais (Juelich Supercomputing Centre)
+@author: Sebastian Achilles (Juelich Supercomputing Centre)
 """
 import os
 import re
@@ -57,10 +58,10 @@
 AUTOCONF_GENERATED_MSG = b"Generated by GNU Autoconf"
 
 # download location & SHA256 for config.guess script
-CONFIG_GUESS_VERSION = '2018-08-29'
-CONFIG_GUESS_URL_STUB = "https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb="
-CONFIG_GUESS_COMMIT_ID = "59e2ce0e6b46bb47ef81b68b600ed087e14fdaad"
-CONFIG_GUESS_SHA256 = "c02eb9cc55c86cfd1e9a794e548d25db5c9539e7b2154beb649bc6e2cbffc74c"
+CONFIG_GUESS_VERSION = '2023-08-22'
+CONFIG_GUESS_URL_STUB = "https://git.savannah.gnu.org/cgit/config.git/plain/config.guess?id="
+CONFIG_GUESS_COMMIT_ID = "28ea239c53a2d5d8800c472bc2452eaa16e37af2"
+CONFIG_GUESS_SHA256 = "ec2577614252326f889df1de97b9a457c03a9a94811048563c211a44496d8ba3"
 
 
 DEFAULT_BUILD_CMD = 'make'


Test patch:
Repository: easybuilders/easybuild-easyblocks

Issue:
Threaded mpi should be disabled by default in SCOTCH for all toolchains
https://github.com/easybuilders/easybuild-easyblocks/blob/2ecd3c97fa1563c7634adf4467f5081fd2debca1/easybuild/easyblocks/s/scotch.py#L112-L115

Comment indicates that it should have been dropped a long time ago. Lets do it for EB 5.0


Discussion:
Is this specific to `SCOTCH`?
I forgot to say scotch, yes, specifically scotch.

Resolving patch:
diff --git a/easybuild/easyblocks/s/scotch.py b/easybuild/easyblocks/s/scotch.py
--- a/easybuild/easyblocks/s/scotch.py
+++ b/easybuild/easyblocks/s/scotch.py
@@ -109,11 +109,6 @@ def build_step(self):
         if self.cfg['threadedmpi']:
             cflags += " -DSCOTCH_PTHREAD"
 
-        # For backwards compatability of v2.8.0 this is necessary but could be removed on a major version upgrade
-        mpi_family = self.toolchain.mpi_family()
-        if self.cfg['threadedmpi'] is None and mpi_family not in [toolchain.INTELMPI, toolchain.QLOGICMPI]:
-            cflags += " -DSCOTCH_PTHREAD"
-
         # actually build
         apps = ['scotch', 'ptscotch']
         if LooseVersion(self.version) >= LooseVersion('6.0'):


Test patch:
Repository: easybuilders/easybuild-easyblocks

Issue:
OpenMPI: Unknown UCC configure option
Trying to build OpenMPI 4.1.1 I get the error/warning that `--with-ucc` is not a known configure option.

It was added in https://github.com/easybuilders/easybuild-easyblocks/pull/2847 

@SebastianAchilles Do you remember which version has this for sure, i.e. where you found that to be missing/required/supported?

We might need to add a version check there.


Discussion:

Resolving patch:
diff --git a/easybuild/easyblocks/o/openmpi.py b/easybuild/easyblocks/o/openmpi.py
--- a/easybuild/easyblocks/o/openmpi.py
+++ b/easybuild/easyblocks/o/openmpi.py
@@ -69,7 +69,10 @@ def config_opt_used(key, enable_opt=False):
                 self.cfg.update('configopts', '--enable-%s' % key)
 
         # List of EasyBuild dependencies for which OMPI has known options
-        known_dependencies = ('CUDA', 'hwloc', 'libevent', 'libfabric', 'PMIx', 'UCX', 'UCC')
+        known_dependencies = ['CUDA', 'hwloc', 'libevent', 'libfabric', 'PMIx', 'UCX']
+        if LooseVersion(self.version) >= '4.1.4':
+            known_dependencies.append('UCC')
+
         # Value to use for `--with-<dep>=<value>` if the dependency is not specified in the easyconfig
         # No entry is interpreted as no option added at all
         # This is to make builds reproducible even when the system libraries are changed and avoids failures


Test patch:
Repository: easybuilders/easybuild-easyblocks

Issue:
torchvision sanity check requires a GPU
#2931 added a sanity check to torchvision, but this requires a GPU to be available when building. We should, instead, check if a GPU is available and only run the sanity check if there is one. If there is no GPU available then we should print a warning instead.


Discussion:

Resolving patch:
diff --git a/easybuild/easyblocks/t/torchvision.py b/easybuild/easyblocks/t/torchvision.py
--- a/easybuild/easyblocks/t/torchvision.py
+++ b/easybuild/easyblocks/t/torchvision.py
@@ -90,11 +90,12 @@ def sanity_check_step(self):
         #      the-cuda-backend-this-could-be-because-the-operator-doesnt-exist-for-this-backend/132352/4
         if self.with_cuda:
             custom_commands = []
-            python_code = '; '.join([
+            python_code = '\n'.join([
                 "import torch, torchvision",
-                "boxes = torch.tensor([[0., 1., 2., 3.]]).to('cuda')",
-                "scores = torch.randn(1).to('cuda')",
-                "print(torchvision.ops.nms(boxes, scores, 0.5))",
+                "if torch.cuda.device_count():",
+                "    boxes = torch.tensor([[0., 1., 2., 3.]]).to('cuda')",
+                "    scores = torch.randn(1).to('cuda')",
+                "    print(torchvision.ops.nms(boxes, scores, 0.5))",
             ])
             custom_commands.append('python -c "%s"' % python_code)
             custom_paths = {


Test patch:
Repository: easybuilders/easybuild-easyblocks

Issue:
Conda generic easyblock doesn't recognise Miniforge
When using Miniforge3 instead of Miniconda3 (created via [https://github.com/easybuilders/easybuild-easyconfigs/pull/20227](https://github.com/easybuilders/easybuild-easyconfigs/pull/20227)) the block does not identify that this is a viable conda environment.

The reported error in the logs is:

```
EasyBuild crashed with an error (at easybuild/base/exceptions.py:126 in __init__): No conda/mamba/micromamba available. (at easybuild/easyblocks/generic/conda.py:72 in install_step)
```


Discussion:

Resolving patch:
diff --git a/easybuild/easyblocks/generic/conda.py b/easybuild/easyblocks/generic/conda.py
--- a/easybuild/easyblocks/generic/conda.py
+++ b/easybuild/easyblocks/generic/conda.py
@@ -62,7 +62,8 @@ def install_step(self):
         """Install software using 'conda env create' or 'conda create' & 'conda install'
         (or the 'mamba', etc., equivalent)."""
         if (get_software_root('anaconda2') or get_software_root('miniconda2') or
-                get_software_root('anaconda3') or get_software_root('miniconda3')):
+                get_software_root('anaconda3') or get_software_root('miniconda3') or
+                get_software_root('miniforge3')):
             conda_cmd = 'conda'
         elif get_software_root('mamba'):
             conda_cmd = 'mamba'


Test patch:
Repository: easybuilders/easybuild-easyblocks

Issue:
R easyblock should check for ~/.Renviron
If the user building a module has an existing `~/.Renviron`, this may set the R libs path to OS packages, which will most likely the build.

The R easyblock should check for the existence of this file and warn the user.



Discussion:
Actually, the `RPackage` easyblock should do this, and maybe even flatout refuse to install anything while `~/.Renviron` is in place?

Or can we instruct R to ignore it?

Altering the R paths might violate the principle of least surprise, so I would prefer the former i.e. refusing to install in the presence of `~/.Renviron`.

Anything else, such as prepending the EB path to `~/.Renviron`, might be more trouble than it's worth.

It's so important to have a clean build environment and a clean OS package list.  My advice would be to create a special account for building software. 

Resolving patch:
diff --git a/easybuild/easyblocks/generic/rpackage.py b/easybuild/easyblocks/generic/rpackage.py
--- a/easybuild/easyblocks/generic/rpackage.py
+++ b/easybuild/easyblocks/generic/rpackage.py
@@ -33,13 +33,14 @@
 @author: Balazs Hajgato (Vrije Universiteit Brussel)
 """
 import os
+import pathlib
 import re
 
 from easybuild.easyblocks.r import EXTS_FILTER_R_PACKAGES, EB_R
 from easybuild.easyblocks.generic.configuremake import check_config_guess, obtain_config_guess
 from easybuild.framework.easyconfig import CUSTOM
 from easybuild.framework.extensioneasyblock import ExtensionEasyBlock
-from easybuild.tools.build_log import EasyBuildError
+from easybuild.tools.build_log import EasyBuildError, print_warning
 from easybuild.tools.filetools import mkdir, copy_file
 from easybuild.tools.run import run_shell_cmd, parse_log_for_error
 
@@ -88,6 +89,12 @@ def __init__(self, *args, **kwargs):
         self.ext_src = None
         self._required_deps = None
 
+        Renviron = pathlib.Path.home() / '.Renviron'
+        if Renviron.exists():
+            msg = f".Renviron file detected ({Renviron}). This file may impact the building of R packages. "
+            msg += "If you did not expect this file to exist then you should remove it."
+            print_warning(msg)
+
     def make_r_cmd(self, prefix=None):
         """Create a command to run in R to install an R package."""
         confvars = "confvars"


Test patch:
Repository: easybuilders/easybuild-easyblocks

Issue:
intel-compiler fails sanity check on Debian/Ubuntu
With the recent changes to gcc easyblock #3254 and the older change to intel_compiler easyblock #1237 and its followups, intel-compiler now fails sanity check due to an incorrect module file being generated.

```
multiarch_inc_dir, ec = run_cmd("gcc -E -Wp,-v -xc /dev/null 2>&1 | grep %s$" % multiarch_out)
```
returns
```
easybuild@b-cn1615:~$ gcc -E -Wp,-v -xc /dev/null 2>&1 | grep  x86_64-linux-gnu'$'
 /cvmfs/ebsw.hpc2n.umu.se/amd64_ubuntu2204_icelake/software/GCCcore/13.2.0/bin/../lib/gcc/x86_64-pc-linux-gnu/13.2.0/include-fixed/x86_64-linux-gnu
 /usr/include/x86_64-linux-gnu
```

resulting in an malformed CPATH being added to the module file:
```
append_path("CPATH", "/cvmfs/ebsw.hpc2n.umu.se/amd64_ubuntu2204_icelake/software/GCCcore/13.2.0/bin/../lib/gcc/x86_64-pc-linux-gnu/13.2.0/include-fixed/x86_64-linux-gnu
 /usr/include/x86_64-linux-gnu")
```

Simple fix is to do ```grep -v GCCcore``` at the and of the command.


Discussion:

Resolving patch:
diff --git a/easybuild/easyblocks/i/intel_compilers.py b/easybuild/easyblocks/i/intel_compilers.py
--- a/easybuild/easyblocks/i/intel_compilers.py
+++ b/easybuild/easyblocks/i/intel_compilers.py
@@ -177,7 +177,12 @@ def make_module_extra(self):
         multiarch_out, ec = run_cmd("gcc -print-multiarch", simple=False)
         multiarch_out = multiarch_out.strip()
         if ec == 0 and multiarch_out:
-            multiarch_inc_dir, ec = run_cmd("gcc -E -Wp,-v -xc /dev/null 2>&1 | grep %s$" % multiarch_out)
+            multi_arch_inc_dir_cmd = '|'.join([
+                "gcc -E -Wp,-v -xc /dev/null 2>&1",
+                "grep %s$" % multiarch_out,
+                "grep -v /include-fixed/",
+            ])
+            multiarch_inc_dir, ec = run_cmd(multi_arch_inc_dir_cmd)
             if ec == 0 and multiarch_inc_dir:
                 multiarch_inc_dir = multiarch_inc_dir.strip()
                 self.log.info("Adding multiarch include path %s to $CPATH in generated module file", multiarch_inc_dir)


Test patch: