-
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}[foss/2021a] RStudio-Server V1.4.1717-Java-11-R V4.1.0 #299
{2023.06}[foss/2021a] RStudio-Server V1.4.1717-Java-11-R V4.1.0 #299
Conversation
Instance
|
bot: build repo:eessi-2023.06-software arch:x86_64/generic |
Updates by the bot instance
|
New job on instance
|
Not sure this one is a good idea, easybuilders/easybuild-easyconfigs#13951 |
@TopRichard For |
bot: build repo:eessi-2023.06-software arch:x86_64/generic |
Updates by the bot instance
|
New job on instance
|
…o eessi-2023.06-RStudio-Server/1.4.1717-Java/11-R-4.1.0.eb-foss/2021a
Just checked the log of this build, and it failed during the build of
It's not really clear to me why that |
I debugged it a bit more by manually building this on an AWS node, and then I indeed ran into the same error:
It turns out that it's a combination of
Removing the
Just don't understand why this wasn't an issue before... |
And digging a bit more... initially I suspected that it may be related to the version of However, the main cause is probably that the file I'm going to try and rebuild EasyBuild 4.7.2 and see if the same thing happens again. |
TBH I have also found that read-only installation led to a problem with an R extension installation that didn't expect a template file to be read-only (and of course it wouldn't normally be). |
I'm not sure if it makes sense to change this upstream, by chaing the
to something like:
but that does solve the issue. This can also be easily achieved by using a hook, so perhaps that's the quickest solution for now anyway. I've just tried the following, and that worked fine:
|
…o eessi-2023.06-RStudio-Server/1.4.1717-Java/11-R-4.1.0.eb-foss/2021a
bot: build repo:eessi-2023.06-software arch:x86_64/generic |
Updates by the bot instance
|
New job on instance
|
Looks like the |
def parse_hook_xvfb_cp_permissions(ec, eprefix): | ||
"""Add user write permission to xvfb-run before copying it in the postinstallcmds.""" | ||
if ec.name == 'Xvfb': | ||
ec['postinstallcmds'] = ["chmod u+wx xvfb-run && cp -a xvfb-run %(installdir)s/bin/"] |
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.
@TopRichard Can you clarify why this is needed?
If there's a problem here, I'm not sure why we didn't see it outside of EESSI...
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.
@boegel Xvfb is a dependency, and so it was set to avoid a failure.
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 got that part, but I don't see why we would see this problem with Xvfb outside of EESSI.
I'm seeing it too in #328 where I'm trying to get R
installed (just to break down this PR a bit), so I'll take a closer look.
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.
@boegel I debugged that issue some time ago, see #299 (comment) and the messages below that one. TLDR (if I remember correctly): it's a combination of our writable overlay + setting the installation dir as read-only (and xvfb-run
is shipped as "patch" in the EB installation dir).
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'm also running into the same issue with #335
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.
@boegel Could the issue with Xvfb be related to the version of XZ? That is the only difference I can discern in EESSI.
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.
It's (I believe) somehow related to the fact we now have write-only installations and the writable overlay. We should probably create an upstream PR to reverse the order of statements in the Xvfb
postinstallcmds
, which is what the hook update here is doing (or we just move forward with the hook update here).
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.
OK, I understand this a bit better now. The cp -a xvfb-run
fails in our particular build environment in which we use fuse-overlayfs
(but not in a regular build environment when the file is just copied from one filesystem to another) because of the read-only permissions on the EasyBuild installation (where xvfb-run
comes from).
I strongly prefer fixing this centrally in EasyBuild, so I've opened a pull request for it: easybuilders/easybuild-easyconfigs#18834
I'm also fixing the chmod u+x
, which should actually be chmod a+x
, so exec permissions on xvfb-run
in the installation directory are set for all users, not just for the account used to perform the installation.
With the following pr, https://github.com/easybuilders/easybuild-easyconfigs/pull/18834/files. The installation of Xvfb works. |
improve error reporting when EasyBuild PR is not merged - CI still fails even after using an older apptainer version (via EESSI#303) - opened a PR for debugging issue (maybe it's related to NESSI or to the environment that runs the CI workflow ... usually the same script works flawlessly when building software)
No description provided.