On 31 Mar 2013, at 14:11, Fotis Georgatos wrote: > > Hi Ken, all, > > First, the major bits: > > From my tests so far there is mostly a green light, I have been able to > goolf-build: > * HPL-2.0-goolf-1.4.10.eb > * OpenFOAM-2.1.1-goolf-1.4.10.eb > * WRF-3.3.1-goolf-1.4.10-dmpar.eb > * petsc4py-3.3-goolf-1.4.10-Python-2.7.3.eb > > On the downside, I had to fiddle with 'DOLFIN-1.0.0_GCC-4.7.patch' w/out > success, > since DOLFIN failed for me at the very last step (ie. its dependencies seem > fine). > See below for some info - I may not have time to debug this today, really.
Please open an issue for this (in the easyblocks repo). This is not failing on our end, so it's something specific to your setup (which doesn't mean we shouldn't fix it). Have you been able to build DOLFIN with earlier EasyBuild releases (e.g. v1.2)? > What is more of a feature than a bug is, that the robot now kicks-in > automagically > (-r parameter); to be honest, I like that and, it saves my day... let's keep > it so :-) > (is it a default config parameter perhaps? haven't searched into it, as of > yet) Oh, but that *is* a bug. It's not a good idea to have it enabled by default, because that would lead to surprises, e.g. when you have an incorrect MODULEPATH or EASYBUILD_INSTALLPATH setting. You'd potentially end up rebuilding all dependencies with a default enabled robot, which is not what you want most likely... We will need to fix this before we ship v1.3... > > On Mar 30, 2013, at 5:27 PM, Kenneth Hoste wrote: >> Let me correct myself here: I had to tag a v1.3.0rc2 for easyblocks as well >> just now, otherwise the dependency check on easyblocks performed by the >> easyconfigs setup.py fails hard. > > OK, I think the idea that flew somewhere to release them as a single tarball, > makes a lot of sense: let's not propagate this artificial repo fragmentation > at the release milestone (I've never been too much in favor of a repo split, > because we still need to test the 3 collections in sync-step, for coherence). > > Operationally, I think we do the right thing just not in the obvious way. > fyi. Git has some kind of facility for sub-repos, I think that if it provides > a hash > that spans the 3 collections, that makes a lot of sense to have: 1 hash per > release. Let's look into this soon. Open an issue for this in the main easybuild repo (where the wiki is)? > >> ps2. we have quite a few lib* packages that ended up in "devel" category... >> let's fix it? >> Which ones? Can you open a PR to the v1.3.0.x branch to fix them? > > https://github.com/hpcugent/easybuild-easyconfigs/pull/197 > > That PR is against "develop", but I suggest you guys have a quick look > if you are happy with the current moduleclass categorization; (esp. for lib*) > I am sure you will find some things you would rather like to tweak a bit. Fixed by merging https://github.com/hpcugent/easybuild-easyconfigs/pull/200. K.
