Let’s frag the bugs!

So if somebody was wondering why I haven’t written much lately, well, I spent the weekend with friends, and yesterday I picked up a new drug still, Unreal Tournament 3 at less than half the price (sometimes that shop has crazy low prices on stuff, I still don’t know how they do that). I used to be a heavy player of Unreal Tournament, to the point I was admin of an Unreal Tournament server, the first european server of the Thievery UT mod, too.

Anyway, I connected an extra keyboard and my trackball first to try UT3 out and.. it’s cool! The visual is much better than the good old Unreal Tournament when I started playing FPS seriously, and the response of the keyboard is not bad at all; I had to replace the trackbal with a mouse though since I couldn’t play with that (or with the gamepad), and now I’m getting my practice back. For the Gentoo developers out there playing UT3: time to get rolling with a tournament guys! 😛

But even if I’m now playingone of my favourite games types, it does not mean I’m not continuing my work for Gentoo and free software; although I cannot connect to the Gentoo CVS server, because my ISp is probablty having routing problems, I left the chroot to build again a part of the tree so that it could check if something is going to break with linux-headers, especially in those bitrotting packages that lack a maintainer and most common users don’t use themselves.

Talking about bitrotting and packages lacking maintainers, last week I started filing bugs for packages that don’t respect CC and other variables by calling directly some common tools’ names, like cc, gcc, g++ and so on. Although I didn’t finish filing bugs (also because I noticed a trend in the bugs being often related to the same team of maintainers, and I wanted to give them a chance to proactively fix their ebuilds instead of waiting for the bugs to be reported), I got one idea that hopefully Zac will implement, if he hasn’t already by now: warning users for unmaintained packages.

When you install a package, explicitly, so not as a dependency, that is not actively maintained in the tree, it makes sense to warn the user of this, so that who merges it won’t find it strange if it does not build, work or if it’s so outdated that it nears uselessness. The idea is that if users start to see that the software they rely on is unmaintaiend, they can decide to either join Gentoo to maintain it or proxy-maintain it, or at least submit patches for the bugs that are open, or for the problems they do find.

Right now I’m testbuilding packages against linux-headers 2.6.27, although not a huge update, it might as well have problems, and then I’ll move on to gcc 4.4 (since 4.3 does not seem to build on that chroot right now it might as well be a good idea to try). While I’m sure automated testing that some developers are working on will be a nice thing, for nowI’m still glad I can do manual testing on my chroots, I think I’ll keep that way; adding to that I’m probably going to test for more respecting of chost-prefixed tools, like ld, ar and ranlib, and maybe if it’s no too noise to do, I would check for packages that force optimisation on even if the user requested -O0 (knowing that some software fails to build with -O0).

So while Yamato builds, I’ll take the rest of the night off, enoy!