So from time to time I like to write down what my tinderbox is doing and this sounds like the perfect time to do so.
First of all, GCC 4.7 is getting unmasked soonish — the number of new bugs in the tracker is basically zero (I opened one today for a newly bumped package), and since at least a little bit of newly fixed bugs appear every other week, it should soon be feasible to just use GCC 4.7.
But the important part is the new tasks; both the ~amd64 and the stable/hardened amd64 tinderboxes are currently running aimed at two different packages’ reverse dependencies.
The former is running against the new, multilib-capable media-libs/freetype package, which Michał introduced recently — this version is able to build the 32-bit together with the 64-bit one, making the binary emul-linux package unnecessary for binary, 32-bit software requiring it. Finally being able to configure which 32-bit packages to install is going to be a win especially for systems with reduced storage space. Unfortunately, Freetype has a design that I would call naïve not to fall into foul language, and its headers are actually architecture-dependent; this means that the 64-bit and the 32-bit builds have different header files. Can you tell how bad that is?
While the proper solution would be to fix the design so that it does not have different headers at all, what we can do in the mean time is installing both sets in different paths, so that they do not collide with each other and software does not build against the wrong version. Unfortunately, since this means moving away even the native ABI headers, it means that you need to tell every single package where to find them. This should be solved by using pkg-config but unfortunately a number of packages out there don’t do that, especially non-autotools based ones — CMake packages seem to use pkg-config … but then they expect to guess the position of the headers instead of actually accepting what pkg-config says.
So I’m now building the reverse dependencies (at least those that the tinderbox can build, some of the games have interactive properties, because they require a CD to be mounted, and sometimes the dependency chain breaks too soon), and I’m going to report them in the tracker bug so that they can be tackled.
The second task is a bit more important from a point of view (even though it’s easier to not trigger): sys-libs/ncurses gained recently an USE flag tinfo that makes it build a separate library for some of the symbols that were, before, collapsed into libncurses alone. Unfortunately this means that now the symbols are defined in libtinfo and nobody is looking for it (or very few). The solution is, for this as well, to rely on what pkg-config tells you, but most packages do not use it for ncurses, mostly for compatibility with very old ncurses versions as far as I can tell.
It wouldn’t be half-bad if the same guy who ignore my bug reports, and who unmask glibc versions that are known to break half the tree didn’t decide to introduce said USE flag into stable already, knowing full well that most of the tree hasn’t been tested in that particular configuration. And here’s where my tinderbox enter the scenes, as it’s currently checking the stable tree to make sure I can report all packages breaking when that USE flag is enabled.
So the builds are running and the bugs are flowing — please just remember that the first primary resource that the tinderbox consumes is my time.