-
Notifications
You must be signed in to change notification settings - Fork 50
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
{2023.06}[2023a] Rivet 3.1.9 #418
Conversation
Instance
|
Thanks for the PR @APN-Pucky . I retargeted the PR to Could you try to use either of these?
Please let us know if you struggle with any of these changes / additional work (PR for easyconfig). |
Since this will also require updates of Rivets dependencies should they all in one PR to easyconfigs or single per-package requests? |
Updates by the bot instance
|
They should go in one PR I think. Otherwise you would have to list the dependencies in the easystack file and add the option |
@APN-Pucky Are you planning to follow up on this? |
Yes, but I thought when I am already at it I'd update all the dependencies in the 2023a for easybuild too. |
Updates by the bot instance
|
The easyconfigs MR is merged now. Can the build bot please be triggered? |
Updates by the bot instance
|
bot: build repo:eessi.io-2023.06-software arch:x86_64/intel/haswell |
Updates by the bot instance
|
New job on instance
|
What does that mean? |
Updates by the bot instance
|
It means there was some error during the build. I'll have to go into the system that builds things to find the error. Note however that another way to debug is to rerun the build yourself, manually, according to the instructions on https://www.eessi.io/docs/adding_software/debugging_failed_builds/ . This should mimic exactly what our bot does, and thus should result in the same build failure. Ideally, that lets you debug the issue on your own system, which is much easier :) For now, I'll go into our build system and check if the error is maybe trivial... I'll paste it here in a minute |
That's... weird to say the least, since I'm assuming that Edit: correction, it was trying to build |
Note that some issues may pop up in our builds that you might not have seen before since we build in a very minimal container. Thus, where some EasyConfigs might succesfully build because they silently pick up on system dependencies, they would fail in this minimal container. It's actually a very good test to figure out if all dependencies have been listed correctly. In YODA's case, they haven't. This configure tells me YODA (at least in the configuration as provided by this EasyConfig) depends on However, in this particular case, it won't resolve the issue: in EESSI, we filter Note, unrelated to it's installation in EESSI: it's still a good idea to add |
Thanks, I'll update the YODA easyconfigs. |
Updates by the bot instance
|
I updated the zlib dependency here: easybuilders/easybuild-easyconfigs#19679 |
Updates by the bot instance
|
Ah yeah, I used the old MR to reproduce the issue.
Yes, this is the problem:
I think you haven't seen this on other systems because that |
As for the solution... I'd really be interested what triggers to configure to add this |
Uhg, it has this very ugly section in the configure...
Clearly, that |
It originally comes from here btw:
|
Apparently, it is the officially documented behaviour for I see two potential approaches:
Now, since this involves logic (namely, checking an EasyBuild option, doing one thing in one case, and another thing in another case), it has to be done at an EasyBlock level, regardless of whether we go for option 1 or 2. Personally, I think 2 would be the cleanest approach. It shouldn't be rocket science to implement it, but still a bit of work. Before you go through that, I'd like to at least get one more opinion from one of the EESSI support people... I'll reach out to them on Slack, see if I can get some input on this :) |
I'm not sure it's true that this requires logic and hence an easyblock. How about this construct (use configopts = "--with-zlib=${EBROOTZLIB:-%(sysroot)s}/include " |
That's smart. The fallback mode seems to work in my build on top of EESSI and in the debug container. I updated the PR reference in this PR. |
Updates by the bot instance
|
Great idea from @boegel and much simpler. I knew I was asking for a second pair of eyes for a good reason ;-) I'll kick off another bot build. Just in case we wonder about this in the future: I saw that your
But indeed from the docs of
|
bot: build repo:eessi.io-2023.06-software arch:x86_64/intel/haswell |
Updates by the bot instance
|
New job on instance
|
bot: build repo:eessi.io-2023.06-software arch:x86_64/generic |
Updates by the bot instance
|
New job on instance
|
New job on instance
|
New job on instance
|
New job on instance
|
New job on instance
|
New job on instance
|
New job on instance
|
Just FYI: I'd like to merge easybuilders/easybuild-easyconfigs#19679 so we can be sure that's the final version before we deploy these builds in EESSI. I'm waiting on one more test report from a build I'm running, if that's ok, I think we can merge there and deploy here. I might be able to find a few minutes tonight to do that... otherwise it'll be tomorrow. |
Thanks for getting this through despite the hurdles! |
Updates by the bot instance
|
Sure! Thank you for pushing through :) As you've noticed, we are definitely still building experience with the particularities of the EESSI setup, but things go more and more smoothly as we learn :) |
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.
Lgtm!
…20.0-foss/2023a {2023.06}[foss/2023a] phonopy V2.20.0
No description provided.