Jun 06

tinderboxOne of the problems faced by the tinderbox of yesteryear is the picking information out of logs, as well as the reliance of one person to interpret the results. With this in mind, I’ve been doing some work to improve accessibility of this data and have produced a tinderbox interface.

A Portage bashrc (based on the original work by Diego Elio Pettenò) collects QA information about builds, and stores it in individual files to make it easier to operate on – eliminating a lot of the need to parse logs.

You’ll notice the interface lists all packages – not just those with a recent build. This allows for a central location to report static analysis information from tools such as repoman and pkgcore-checks. Other lesser-known tools are supported, with experimental reporting of sub-slot candidates and automated dependency checking.

What’s next? I’d like to add ways to find packages beyond the usual category breakdown – such as by maintainer or builds by architecture. There’s more build-time checks to add, and I’m sure there’s other static analysis tools out there too. I don’t personally have the resources to build packages at the scale seen previously, so last but of course not least, more building power is needed. Fortunately, it’s quite easy to collate the tinderbox data from multiple sources so we may be able to ‘crowd-source’ if necessary.

As always, comments/feedback/suggestions welcome.

2 Responses to “Reviving the tinderbox”

  1. Ryan Hill Says:

    Cool, thanks for working on this. It’s sorely needed. One thing I really miss is the reports we would get to gcc-porting when packages failed to build with new gcc versions or options. If we could filter based on failure type and system config, that might make a good replacement.

    Let me know if you need hardware – I’d be more than willing to help out.

  2. kensington Says:

    Failure reports are one of the next things I’m working on. I’m hoping to produce a sort of “best guess” for common types of build failure in order to produce specific reports (think “missing unistd include” report to use GCC 4.7 as an example). Custom filters are fairly easy to put together and since data can be collated from multiple sources we can come up with interesting reports like “newly failing builds [because of new gcc]” or “failures on arch/profile/whatever foo that passed on bar”.

Leave a Reply