The framework was unaffected, the bugs were limited to particular
software packages.
Nice. What is your recommended "authoritative" way to track such
changes?
I am having my view at this one now which is not always most
readable summary:
https://github.com/hpcugent/easybuild-easyconfigs/commits/master
and I understand this addresses the zlib version fighting I
noticed, too!
I'd say checking the commit log is indeed the best way to go. Only a
limited number of commits are involved, and I tried to make the
commit messages clear.
Also, a few packages have an issue to download their sources
correctly, I think you have not noticed yet since you haven't
cleaned the sources cache? (notably: mvapich v1.7, MTL4 and perhaps
a couple more; and this affects deps)
Some of them are not easy to solve: MVAPICH2 only provides tarballs
for the latest release, not for older releases it all it seems (see
note in easyconfig file, e.g.
https://github.com/boegel/easybuild-easyconfigs/blob/develop/easybuild/easyconfigs/m/MVAPICH2/MVAPICH2-1.7-GCC-4.6.3.eb
).
If you can compose a full list of builds that have this problem,
please open an issue for it in the easybuild-easyconfigs list.
I consider this to be a non-blocking problem, which we can resolve by
the next easyconfigs release.
i was never very happy with this option since it gives the user the
illusion that it will always work, which ofcourse is impossible (similar
to some of the other --try- options).
it is nice for most cases, but i wouldn't rely on it too much.
it makes great demos however, so i'm all in favour ;)
at some point we should add 2 extra options:
- just check if software can be downloaded from the link (ie check url,
maybe download a few bytes?) and for the rest nothing. this could be
part of some easyconfig validator? (maybe it's there already?)
- download-only, ie download, do not build
the code should be already there, probably needs some refactoring
Furthermore, some packages -including the bioinformatics ones we
have contributed- may have a little bit difficulty to build
straight out of the box. I suggest to play clean and lean for the
v1.0 release and put them aside for a next release. (ie. if you see
any suspicion of trouble, better put it in a queue for later). We
do not need to be so strict for next releases, just this first
one.
They seem to be building fine on our end, although we have had some
issues with the MUMmer easyblock you contributed, see
https://github.com/hpcugent/easybuild-easyblocks/issues/8 .
There will be several easyblocks that are not perfect in the current
release, but I don't see that as a reason to exclude them. We want to
get feedback, and if people think we're building something in the
wrong way, we want to get feedback on it, or even better, to let them
contribute fixes for our mistakes. So, I'd leave those in, especially
since the build works fine in a clean regtest.
if you are aware of issues with configs or blocks that prevent
functional usage, we shouldn't ship them at all.
stijn
IMHO, this is really important for newcomers of easybuild -we
expect a flux next week-, there is no reason to distract them with
issues of individual packages and, we all know that complex system
environments can make things tricky enough.
If they end up submitting issues for the problems, that would
actually be great, because then we're gaining traction and getting
feedback. No software is perfect, neither is ours.
Finally, let's take advantage of our proposed meeting @ Uni.Lu by
the end of the month to discuss such issues that newcomers find (I
especially care for osdependencies aspects) with v1.0 and how to
make their bootstrapping simple (eg. build a community FAQ etc).
Can you send us some kind of (rough) planning? I haven't booked a
hotel or some such yet...
ps. To make you cheer: 100s of packages can build fine in the
automated way with 1.0-rc1 by sourcing Makefiles of NetBSD's
pkgsrc; As discussed, these are just templates but they provide a
quick solution for a few trivial packages (a2ps was my trigger):
https://github.com/fgeorgatos/easybuild.experimental
That sounds great!
For such automated-based contributions to EasyBuild however, we'll
need to make sure the builds are checking somehow, e.g. by providing
test cases that EasyBuild can run and this check the build. I know
this requires human intervention, but if we want to have some form of
quality control, we'll need that imho.
K.
