Tinderbox — Correcting the aim

While I haven’t been able to do much major Gentoo work lately (but I’m still working on fixing and bumping my own packages), I’m still working hard time on the tinderbox. As I’ve said a few times, my effort never started with the intention of being a full blown tinderbox, and only grew up from a few tests to what it is now. The work is hard, long, and heavy, but it gets results, I hope.

Stating from this month and stretching down to October, there will be quite a few packages that will be removed from the tree since they don’t build, some haven’t built in quite a few months if not years, and this should also mean faster emerge --sync (or at least, not excessively longer after a while – the main problem is that the tree is growing, but we have to cut out the dead branches).

Also, most of the issues related to the GCC 4.4 unmasking are getting pretty well known and should be getting fixed or booted out in a short while. The main trackers, for fortified sources, gcc 4.4, glibc 2.10, --as-needed and so on are, yes, pretty huge, but are also being emptied little by little. This hopefully will bring us to a much cleaner, sleeker tree.

Last night I went around fetching all the packages in the tree to make sure the tinderbox wouldn’t go waiting on the download to be completed; this alone was quite a task because it had to execute over 5700 packages (those that are queued up to be installed), and found out quite a few issues by itself; like fetch-restricted packages that didn’t use elog to output the fetch error – so you wouldn’t have a trace of why they failed to fetch! All the packages that require registration to fetch (or for which the download site was unavailable) are now masked in the tinderbox so they won’t be tried (and neither would the packages that depend on them).

There are quite a few obstacles still for a total coverage of the tree by the tinderbox; collisions are one of them, but there are also problems with cyclic dependencies, especially among Python and Ruby packages that are used for testing, and have circular dependencies with another package. All these are currently being looked at by the tinderbox with a huge performance drop. Another problem is with the dependencies that fail to build; for instance mplayer is currently failing to build because of some assembly mess-up; that in turn causes a domino effect with a huge number of other packages that tries to merge mplayer in.

To reduce the amount of stuff that will fail to merge, I’m also going to take measures for packages to be masked when I know they will cause other stuff to fail; this is the case of mplayer for instance, but also of PHP’s pear that fails (without any kind of error message) for every and each package.

Hopefully, one day most of the tree will build file and will not require me to do this kind of work…