-
Notifications
You must be signed in to change notification settings - Fork 23
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
[WIP] EESSI compatibility layer for next version (2025.02) #209
base: main
Are you sure you want to change the base?
Conversation
Instance
|
Instance
|
First runs went quite well, it failed (as expected) in the step that installs our package set, which we don't have yet for this version. The prefix bootstrap completed without issues though. |
# gentoo_git_commit: 29492845e41ea6a0a4a9769c7e0ce287d106079b | ||
# June 8 (aab8473aa90e0287553b3348a5c5b17872df4b7b) commit that was current when fetching luaposix | ||
gentoo_git_commit: aab8473aa90e0287553b3348a5c5b17872df4b7b | ||
gentoo_git_commit: db21a802e879f713cdb8a80235c5982ca257b63f |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Include a comment with some info on why this commit was picked (even if it simply was the latest at the time)
Once your PR to bump Lmod to latest has been merged, we'll have a clear reason...
prefix_required_space: 15 GB | ||
prefix_user_defined_trusted_dirs: | ||
- "/cvmfs/{{ cvmfs_repository }}/host_injections/{{ eessi_version }}/compat/{{ eessi_host_os }}/{{ eessi_host_arch }}/lib" | ||
prefix_mask_packages: | | ||
# stick to GCC 10.x; using a too recent compiler in the compat layer complicates stuff in the software layer, | ||
# stick to GCC 11.x; using a too recent compiler in the compat layer may complicate stuff in the software layer, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would go with at least GCC 13, perhaps GCC 14 (unless that causes trouble to build GCC 13.x in software layer)
On both |
bot: build arch:generic repo:compat |
Updates by the bot instance
|
Updates by the bot instance
|
New job on instance
|
New job on instance
|
New job on instance
|
New job on instance
|
bot: build arch:x86_64/generic repo:eessi.io-2023.06-compat (This will fail because we don't have a package set yet, and because we need #179, but I just want to check how far it gets.) |
Updates by the bot instance
|
Updates by the bot instance
|
New job on instance
|
Trying again, the bot will now request 3 days for the build job. bot: build repo:riscv.eessi.io-20240402 arch:riscv64/generic |
Updates by the bot instance
|
Updates by the bot instance
|
Updates by the bot instance
|
New job on instance
|
Haven't looked into the details yet, but it looks like the RISC-V build failed at installing GCC 14 in stage 3 of the bootstrap. |
Why GCC 14? We want a slightly older GCC in compat layer? |
That's a good question... I'm not sure if we had discussed this in a meeting, but this PR has been using GCC 14 for a while (by masking |
bot: build arch:x86_64/generic repo:eessi.io-2023.06-compat |
Updates by the bot instance
|
Updates by the bot instance
|
New job on instance
|
New job on instance
|
bot: build repo:riscv.eessi.io-20240402 arch:riscv64/generic |
Updates by the bot instance
|
Updates by the bot instance
|
Updates by the bot instance
|
New job on instance
|
I would at least stick to GCC 13.x, to avoid trouble if we do end up having to installed pre-2024a toolchains in this new EESSI version (though that's not the plan currently) |
The very last (test) step of the playbook failed, because ReFrame could not be installed:
|
bot: build repo:riscv.eessi.io-20240402 arch:riscv64/generic |
Updates by the bot instance
|
Updates by the bot instance
|
Updates by the bot instance
|
New job on instance
|
Using 2025.01 for now, not sure if that's going to be final version, but I'm using this to do some test runs/installations.