Beside criticising Intel for their x32 ABI I’ve spent the last few days working hard on the Tinderbox to make sure that the GCC 4.7 failures are identified quickly.
While the analysis of the logs is now vastly automated compared to earlier efforts, I’m still not using automated scripts for bug filing, and I file them by hand. How did I do that? Well, before I used delicious to store a number of bug templates for situations such as fortified sources, but this is no longer a viable option… for one simple reason. When the service was bought off Yahoo!, instead of focusing on the one reason why I’m pretty sure a number of users stopped using it (namely, the lack of a decent extension for Chrome), they decided to re-make it in a more “web 2.0” fashion…
… the problem is that it came with what I would define “web 0.2” developers, and the data import caused corruption in the (very long) URLs of those bug templates.
I had people contribute possible ways to deal with automated bug filings from the tinderbox, but all of these were fragile, because the interface between Bugzilla and the scripts has changed already too many times, and you need to be able to create the bug to attach a file to it (okay it’s not strictly true but it’s the case most of the times).
What did I decide to do then? Well, the output of the logs analysis is displayed as a webpage, through Sinatra, and when I’m doing the analysis of the logs I can come up with a little more data than before… and the very same system I used to file the bugs with templates can be used with a simple link. This means no worrying about Bugzilla authentication, credential sharing, bug filing and attachment adding.
What happens now is that near to every link for the build log, I have a [B] (which I’d love to replace with a 16×16 icon of a bug if somebody feels like finding or drawing one! — I could also use a wrench with a red bar to indicate a log with build failure, and a magnifying glass similarly barred for test failures). This is actually a link to an half-filled template, with the URL field pointing to the build log, the package name already set in the subject, and most importantly the maintainers already properly assigned.
The only remaining issue was having a way to tell the template which emerge --info posting, so for now it’s simply using a file on the system, with as name the hostname from which the log has been sent — this way I can easily set up multiple tinderboxes, after all the emerge --info output doesn’t change that often. The alternative would be to have a Portage feature that always outputs the full info at the top of the build log.
And to finish this off — I said before I can set up multiple tinderboxes with this new box. Indeed next week I’ll set a new one up, amd64 stable with hardened (right now it’s targeting ~arch and only runs hardened kernel). I was considering setting one up for x32 but then I would just end up filing bugs over bugs over bugs for no real gain and I don’t think the rest of the guys will like that.