Hi all, Not sure if you know but we're currently experiencing a spur of build failures related to eautoreconf (in particular, eaclocal) and libtool-2.4 The new libtool release only works with automake 1.9 and later. [1]
In this situation, the proper way to tackle the issue is to make sure the build system is updated to something more recent and can be built with automake 1.11 (which is the current version). Since automake tends to be pretty conservative, this often enough it's just a matter of dropping WANT_AUTOMAKE, at worst to play a bit with the build system to stop using deprecated/removed features. It's something I can do quite quickly, so between last night and today I fixed a few packages. Before you start to wonder, yes I did fix packages that I don't maintain; yes I have tested that the results are good for each of them. I did so on the count that a) I'm part of QA so making sure the tree builds is my duty and b) half the time the autotools-related problems are redirected back to me for a simple matter of experience. I'm currently running test on another list of 83 packages using various versions of automake… I'm planning on tackling all the failing ones just as I did up to now in the next couple of days. But since we're really hitting a number of issues related to this, I'm currently wondering if it wouldn't make much more sense to simply package.mask all the previous versions of automake. They should still be available, as they might be required for upstream work/test, but they shouldn't be depended upon, or brought in on users systems. If we have to go down that route, we're going to need to "fix what's not broken" by ensuring that also the packages not using libtool-2.4 won't use the older versions. As you might guess, I'm volunteering to do the conversion myself, it's probably going to take me less time that it'd take to explain and get someone else to do it. Doubts? Comments? [1] http://blog.flameeyes.eu/2010/12/01/the-automake-and-libtool-clash -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/
signature.asc
Description: This is a digitally signed message part
