Hi Fotis, On 09 Nov 2012, at 15:10, Fotis Georgatos wrote:
> > Hi Kenneth, > > On 09 Nov, 2012, at 13:26, Kenneth Hoste wrote: >> 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. > 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. > 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.
