easybuild (2.9.0)

[koomie]

Available at:

https://pypi.io/packages/source/e/easybuild-easyblocks/easybuild-easyblocks-2.9.0.tar.gz
https://pypi.io/packages/source/e/easybuild-easyconfigs/easybuild-easyconfigs-2.9.0.tar.gz
https://pypi.io/packages/source/e/easybuild-framework/easybuild-framework-2.9.0.tar.gz
https://pypi.io/packages/source/v/vsc-base/vsc-base-2.5.4.tar.gz

[boegel]

@koomie lt me know if you need any help with this, I'll do what I can!

[JohnWestlund]

I'm interested too -- especially with the new VSC components

[boegel]

fyi: EasyBuild v2.9.0 was released just now...

[JohnWestlund]

Has anything changed since v2.8 regarding the various VSC dependencies? I remember previously vsc-install was a new dependency but didn’t have a release at the time -- looks like there have been two releases now.

From: Kenneth Hoste [mailto:[email protected]]
Sent: Friday, September 23, 2016 7:06 AM
To: openhpc/ohpc [email protected]
Cc: John Westlund [email protected]; Comment [email protected]
Subject: Re: [openhpc/ohpc] easybuild (2.8.2) (#289)

fyi: EasyBuild v2.9.0 was released just now...

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com//issues/289#issuecomment-249202248, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AFP7v1mZBbhzr_DkeH7p1GL3XalnNbZBks5qs9zLgaJpZM4J7FYF.

[boegel]

@JohnWestlund The easybuild-framework component still requires vsc-base, which in turns requires vsc-install; both are available on PyPI (https://pypi.python.org/pypi/vsc-install, https://pypi.python.org/pypi/vsc-base).

They have been for a while, see for example https://github.com/hpcugent/easybuild-easyconfigs/blob/develop/easybuild/easyconfigs/e/EasyBuild/EasyBuild-2.8.1.eb .

[koomie]

@boegel, are the authoritative sources for source at pypi.python.org? The reason I ask is that the URLs used to be intuitively organized by version number. This made .spec file management trivial - for example:

Source0:   https://pypi.python.org/packages/source/e/easybuild-easyblocks/easybuild-easyblocks-%{version}.tar.gz
Source1:   https://pypi.python.org/packages/source/e/easybuild-easyconfigs/easybuild-easyconfigs-%{version}.tar.gz
Source2:   https://pypi.python.org/packages/source/e/easybuild-framework/easybuild-framework-%{version}.tar.gz
Source3:   https://pypi.python.org/packages/source/v/vsc-base/vsc-base-%{vsc_base_ver}.tar.gz

The newer versions look to have switched to a sha or equivalent, so it's more cumbersome.

https://pypi.python.org/packages/0f/c4/65f98c2dc041e8201a51d2be61ec407e421f02e4f43775c7cb85ed4b8bcd/easybuild-easyblocks-2.9.0.tar.gz

Are the tagged GitHub releases equivalent, such that we could pull from them instead?

[boegel]

@koomie for the easybuild-* packages, it should be safe to grab them from GitHub rather than PyPI, but that's not the case for vsc-base and vsc-install (see also hpcugent/vsc-base#232)

Just to make it clear: we didn't decide to go with the new style URLs including hashes on PyPI, see https://bitbucket.org/pypa/pypi/issues/438/backwards-compatible-un-hashed-package. I'm not happy with that change at all myself (in EasyBuild, we added a workaround, cfr. easybuilders/easybuild-framework#1749).

One thing worth considering is to grab the packages from PyPI Warehouse, see for example https://pypi.io/packages/source/e/easybuild-framework/easybuild-framework-2.9.0.tar.gz .

Althogh pypi,io isn't production yet, it should be soon, and it should work fine already...

[koomie]

@boegel, thanks for the pointer to the PyPI Warehouse. I am able to grab all the latest src from there using the versioned path. That's quite the lovely schema they changed to on PyPI...

[crbaird]

Hi @boegel. We're getting all VSC dependencies in OBS now, but the build fails in STAGE 2. I'm having trouble dumping the build log. Does the error at https://build.openhpc.community/package/live_build_log/OpenHPC:1.2:Factory/easybuild/SLE_12_SP1/x86_64 give you any hints?

[boegel]

@crbaird Please try in an environment where $EASYBUILD_BOOTSTRAP_DEBUG is defined (to any value), that will give you a lot more output and show the actual problem.

Also, the bootstrap script got a minor update recently (cfr. easybuilders/easybuild-framework#1944), it's probably wise to update your copy by redownloading it (from https://raw.githubusercontent.com/hpcugent/easybuild-framework/develop/easybuild/scripts/bootstrap_eb.py).

Another more substantial update to the bootstrap script is in the works, cfr. easybuilders/easybuild-framework#1946, but that needs to get more testing first.

Let me know what I can do to help out!

[crbaird]

Perfect, @boegel. Thanks for the pointers.

[boegel]

@crbaird I backported the change you've made to the bootstrap script in our upstream version (which has had several updates since your fork as well), see easybuilders/easybuild-framework#1955 .

Once we also get the enhancement in easybuilders/easybuild-framework#1946 merged, I'd like to sync the OpenHPC fork of the bootstrap script with the upstream version (doesn't have to be for the 1.2 milestone, the actual EasyBuild installation you end up with should be the same).

What's the best way to propose this change? Should I just issue a PR to this repo here, and if so, to which branch?
How can I make sure the updated bootstrap script will still do the proper just in OBS, is that tested automagically, or is there documentation available on how to verify that myself?

[crbaird]

@boegel A PR to the 1.2 branch would be just fine. Once the PR is merged an OBS build will automatically launch, and we can just keep working any problems on this issue.

[boegel]

@crbaird that sounds like you're bootstrapping EasyBuild in an environment where the EasyBuild/2.9.0 module is already available? In that case, stage2 will basically skip the installation (which may be considered a bug in the bootstrap procedure, I guess).

Can you try with MODULEPATH= python bootstrap_eb.py ... ?

[crbaird]

No, the bootstrap happens in a brand new VM without any predefined EB stuff. In any case, unsetting MODULEPATH didn't seem to help.

[boegel]

@crbaird just took a look at the log, this is weird... Does the log also include output to stderr?

This bit especially suggests that EasyBuild is installed:

This is EasyBuild 2.9.0 (framework: 2.9.0, easyblocks: 2.9.0) on host ohpc1

But the (debug) output for stage2 is certainly incomplete...
The start of the log also looks incomplete, is this supposed to be the complete log?

Is there a way to tell which $EASYBUILD_* environment variables are defined?

[crbaird]

Yep stderr should show up in that log, and any command that returns non-zero should cause the whole build to fail. The EASYBUILD_* vars can be seen in the spec file just above the bootstrap:

https://build.openhpc.community/package/view_file/OpenHPC:1.2:Factory/easybuild/_service:extract_file:easybuild.spec?expand=1

[boegel]

@crbaird I'm still not entirely sure why the bootstrap is utterly failing for you...

Can you try and see whether also defining $DEBUG_EASYBUILD_OPTIONS=1 provides more information?

Is there any way I can play around with this myself in the ohpc build environment?

[crbaird]

That definitely produced some more debug, but not a ton in stage2:
https://build.openhpc.community/package/live_build_log/OpenHPC:1.2:Factory/easybuild/CentOS_7.2/x86_64

We should be able to set you up an account on OBS. Give me just a moment.

[boegel]

@crbaird Another thing to try is bump vsc-base to the latest 2.5.5.

A bug was fixed in vsc-base recently that made eb die silently in headless mode, cfr. hpcugent/vsc-base#238 .

That should be fixed in vsc-base 2.5.4 too though, which is what you're using here, but it doesn't hurt to try...

[boegel]

@crbaird I think I found the issue...

The option parser used by EasyBuild picks up all $EASYBUILD_* environment variables, and uses them to configure EasyBuild. If it runs into an unknown option, it barfs. At least, it's supposed to barf...
For some reason, the error message that is supposed to be produced gets muted somehow, I'll have to figure out why that happens and add a test for it so this doesn't occur again in the future.

The problem in this setting is that $EASYBUILD_VERSION is being defined, while --version is not a valid configure option.
The fix would be to use $EB_VERSION or $OHPC_EASYBUILD_VERSION or whatever else, that should fix the problem from what I can see.
That is, if it should actually be set at all, I see no reason for it?

[boegel]

@crbaird As you figured out already, $EASYBUILD_VERSION is used by one of the patches that is applied...

Maybe it's a good idea to make it clear that $EB_VERSION only needs to be defined because the patch picks up on it?

Alternatively, the patch could use cd %s/eb_stage1/lib/python*/site-packages/easybuild_easyblocks-*-py*.egg/easybuild/easyblocks instead, making it agnostic to whatever EasyBuild/Python version is used.

In any case, it doesn't matter too much, since this particular patch is already backported, and will be part of the next EasyBuild release, so the spec will need to be reworked to remove the patch when EasyBuild is being updated (hence my suggestion to make it clear why defining $EB_VERSION should be accompanied by a comment). I hope I can look into that myself, now that I'm a bit more familiar with the OpenHPC procedure...

[crbaird]

@boegel Yeah I think a comment in the spec regarding EB_VERSION is appropriate. Is it clear to you why the bootstrap would try to install setuptools?

[boegel]

@crbaird I updated the bootstrap script in #333 to fix that problem

I'm trying to verify that using the OBS account you created for me, but it seems like I'm not sufficiently familiar with that setup yet... :-)

[boegel]

@crbaird In the mean time, I realised the exact problem with defining $EASYBUILD_VERSION...

It's actually behaving as intended. Each eb command line option can also be specified through an $EASYBUILD_* environment variable. So running EASYBUILD_VERSION=2.9.0 eb is really equivalent with running eb --version (the value of $EASYBUILD_VERSION is irrelevant, as long as it as some value...).

So, I'm not sure what to do with this...
I guess we should at least have some kind of warning if the equivalent of eb --version is being triggered somehow without using --version, since that's most likely not what was intended.

[crbaird]

Tests passing in CI. Thanks, @boegel.

[koomie]

Just wanted to also say thanks to @boegel for helping us with a fix today. This will make it into the next OpenHPC release this week....

[boegel]

Happy to help!

I hope I'll be able to just send you guys a PR for the next EasyBuild release...

Is there some kind of integration testing in place for EasyBuild in OpenHPC BTW?
If not, I'm definitely willing to help out with that too, together with improving integration like making sure that EasyBuild can pick up the modules that are produced outside of EasyBuild, etc.

[crbaird]

The current integration tests are quite limited in scope. We check to see that the RPM is installed by the setup recipe, that the EasyBuild module works, and that the eb binary is accessible and functioning. Unfortunately we can't guarantee the test environment will have network access to download and build an easyconfig, but we would appreciate help in making the tests more meaningful. You can see the current tests ohpc/tests/dev-tools/easybuild and the results are in the long cycle tests at http://ohpc2.tacc.utexas.edu:8080/