`quick_start.sh` demo fails with Spack 1.1.1 on top of EESSI 2023.06: failed to concretize `quantum-espresso~mpi`

[boegel]

...
 2. Check available compilers:
   $ spack compiler list

==> Available compilers
-- gcc rocky9-x86_64 --------------------------------------------
[e]  gcc@13.2.0

 3. Concretize a sample spec (reusing externals):
   $ spack spec -Ilt quantum-espresso~mpi

==> Warning: Spack is trying attach a Python dependency to 'meson@=1.1.1 build_system=python_pip platform=linux os=rocky9 target=aarch64'. This feature is deprecated, and will be removed in v1.2. Please make the dependency explicit in your configuration.
==> Error: failed to concretize `quantum-espresso~mpi` for the following reasons:
     1. Only external, or concrete, compilers are allowed for the fortran language
     2. Only external, or concrete, compilers are allowed for the cxx language
     3. Only external, or concrete, compilers are allowed for the c language

@lorisercole Any idea from the top of your head what may cause this?

[boegel]

Same problem with latest Spack develop (commit e0a74b0eff5b8926247cfa6759adbd2e2c39a00e).

Maybe @haampie or @alalazo or @tgamblin have an idea here?

[alalazo]

Did you add back the patches that @lorisercole mentions in the README:

?

[boegel]

Ah, I overlooked that, I assumed all required changes were already included in Spack v1.1.1...

@alalazo It looks like that's mostly about the changes being contributed in spack/spack#51873 ?

[lorisercole]

Hey @boegel,
yes for sure you need the patches of spack/spack@develop...lorisercole:spack:eessi.
spack/spack#51873 contains some of them, but the most important one for EESSI is the redefinition of SYSTEM_PATHS in lib/spack/spack/util/environment.py to account for the non-standard sysroot, see spack/spack@159a648.

[lorisercole]

I've updated the README with simpler installation instructions. Let me know if it works!

[boegel]

Just tried again, using a patched installation of Spack, yet I'm still running into the "Error: failed to concretize quantum-espresso~mpi for the following reasons" issue.

Not sure what I'm doing wrong, to be honest.

I did get it working yesterday using @lorisercole's eessi branch of Spack, but for some reason that doesn't work anymore now.

Maybe there's a some hidden state depending on which Spack commit is being used initially, or something like that?

[lorisercole]

Maybe there's a some hidden state depending on which Spack commit is being used initially, or something like that?

Are you running the quick_start.sh script?
Have you tried to delete the old demo directory (named demo_spood by default) before running it?

This demo script sets SPACK_USER_CONFIG_PATH (that is the location of the user-scope configuration files) to the demo directory. The database and installation dir will also be inside the demo dir. Possibly it's using an old configuration or database that is not valid

[ocaisa]

Locally on my laptop I had problems due to pollution from OS packages (I think)

==> Error: the spec 'cmake@3.31.8 target=aarch64' depends on 'curl@8.3.0 target=aarch64', but there are multiple external specs that could satisfy the request [candidates are curl@=8.3.0~gssapi~ldap~libidn2~librtmp~libssh~libssh2+nghttp2 build_system=autotools libs=shared,static tls=openssl platform=linux os=ubuntu24.04 target=aarch64, curl@=8.3.0~gssapi~ldap~libidn2~librtmp~libssh~libssh2+nghttp2 build_system=autotools libs=shared,static tls=openssl platform=linux os=ubuntu24.04 target=aarch64] [/home/ocaisa/webinar/spood/demo_spood/packages.yaml:198]

but I now have functional multi-arch CI for this in ocaisa#1 (with a bit of help of some target architecture mappings for the demo yaml).

[boegel]

Ah, that must have been my problem as well, using an aarch64 system.

I was switching between Arm and AMD system, which is why I got confused that I got it working at some point, and then not anymore...