Smaller talks have some kind of tradidion at these camps, namingly being heavily dynamic. You start preparing a talk about an hour or two before it starts.

When the first talk was about start, people noticed a small bug... Missing canvas. 2 people were ordered to pick one up but they did not arrive yet, so the dynamic part this time would be actually having some kind of canwas.

Here's a pic of what we came up with

All in all it's fun every year. If you speak german, you can get some additional info about it at LUG Camp 2009 site

I have always been a fan of this, as it involves more people and I have nothing to do except reviewing patches and committing that. 5-10 packages are easy to handle for any dev, so no big drama.

Though when I joined our php team as commitmonkey, things started to become a bit hairy. There are like 200 packages who want regular revisit. Soonish there is a missing file on commit or whatever lil' fault you can think of as grepping changes from one dir and applying them to another is not that userfriendly when cvs is part of that game.

So some really bad scripts magically appeared to do that task yet they failed as well sometimes due to not recognizing same versions and whatnot. End of story: A GUI was needed to get a visual impression about what is going on there. Doing copy of selected files and run some commands after the copy (like cvs add and whatnot).

2 1/2 days of coding later, here it is

It's part of the upcoming maintainer-helper release (yah I know, I was slacking at that project), so keep fingers tight or grep the live version

a) When copying stuff from sunrise/ to reviewed/ so that it goes out via layman, the file was added although it was merged.

b) It left empty dirs behind when I kicked an app (as it went over to gentoo-x86)

After reading a bunch of mailinglists and forums posts, I finally had a working solution. Just add these lines to .git/config file:

[diff]
renames = copies
[svn]
findcopiesharder = 1
rmdir = 1

But why am I writing about this here? Well, also some time ago, araujo and me started something called gui project. Main target was obviously getting some nice gui for our day-to-day tasks. I don't really know where (maybe some mailinglist) it came to my ears that our obviously loved packages site was down more a month. So hey, we're a gui project, I more or less have finished my previous tinderbox thingy (just minor stuff open). So some spare time available. I never did a webpage yet with a python based framework so I decided to give some of them a try and if I would find a nice and not bloated one, this could be worth a try.

Two days of trying different ones later, I finally got settled with cherrypy and genshi (there's a nice tutorial on the genshi homepage if you're curious now)..

After some thinking about databases and stuff, finally got a db generator going resulting in data useful for such a site. That's the moment where I started to git the code and let the show begin. In the meantime I was on holiday for more than a week so you might notice some inactivity in the timeline. Anyway, at least startpage and some filtering works. See http://tinyurl.com/2fq9dw for working features of the live version at http://packages.gentooext.net

It's a starting project, mind you, though basics are working now, more stuff to come. If you have questions or comments, feel free to join irc.freenode.net #gentoo-guis , cookies are on topic

While the actual build script was done in one day, getting all involved things to play nice and friendly was really a hard job. Involved were cachings, optimizations for different VCSs and many minor corner cases.
Facing facts I'm abusing a system which was designed to fetch source from some repository then run tests on it and if multiple requests come in, just work on latest one. This is partially what I want and the other part is the opposite. So I had to dig deep into BuildBot to solve all outstanding issues.

Job management was more like coding top down (no really hard task after all) though needed tweaks along the road as well.

But as I said it was worth it. The thing has no dark corners anymore for me

And: there are pre-stable tests now for the incoming requests

Note for interested people:
Repo of it has moved to dev.gentoo.org/~jokey/tinderbox-bzr
URL of the BuildBot Status Page: http://buildbot.gentooext.net/

As member of x86 arch team, I decided to start there. After open the site it felt a bit like bad news. ~30 requests being normal, 67 that day.
So either there were just some slackers over the weekend or some herd woke up and filed requests like drinking coffee. Neither was the case though.
Only possible solution: boot up all boxes and have them compile...

All boxes.. my pc, my desktop,my errrrr... ok that's it. (As weird as it may sound to people who've never done AT stuff, even with two devices it's much to do). Our "Gentoo Arch Tester Tool" (aka gatt) does a good job there by guessing packages just via bugzie ids though it's still a lot of work and quite a lot of time. Only to find out $package doesn't even build. Worked through ~20 bugs (and 3 failures) in about 8 hours. Not that efficient from what it felt like.
Luckily the php guys needed some help on getting stuff over from the overlay to portage and the day had a positive ending.

But I would like a tool that does a build on request to verify it atleast compiles on a default stable profile, maybe with a slightly polished make.conf. A quick look around returned only a "hey, let's build whole portage tree" script and some non-working or "I run emerge via cron" scripts. Both won't clearly do the job here.
Result: It's open source environment -- "Don't moan, code yourself".
First starting as a base on the build whole tree script I mentioned but then it quickly turned out that it wouldn't do the job for me. So more or less, inspired by the stuff seen in that script, start coding from scratch.

After like 12 hours of intensive coding work on wednesday evening I finally had this thing done: Tinderbox Output
What does it do?

1. Update system and world
2. clean out unneeded build and non-world packages (world only contains 4 pkgs there)
3. calculate minimum requirements for package X
4. build those and make binpkgs of them for later use

What are the next steps? Obviously the request handling. Though another thing comes to mind: if there is more than one request at a time, parallel building on more than one box would be cool. Also there has do be at least a minimalistic bit of status overview.
Tried some build environments for the job, finally good old BuildBot was chosen as candidate. The setup is easy, all of the build boxes already have Python on it so not much overhead and I know the lang so can extend it if needed later on.

After reading through some docs to get the deeper know-how about how to distribute a buildjob, the thing looked like this:

RL wanted some attention today so I didn't put that much energy into it. Tomorrow will be our next LUG event so I think Sunday will be the time for more steps towards a request tinderbox (as only request handling stuff is left now).

If you want the (not yet documented) tinderbox script, "bzr get http://dev.gentooexperimental.org/~jokey/tinderbox/"

(click to enlarge)

The debug part still needs some love to work as expected but the rest works nicely already.

So we have an open-source virtualizer now? Yes we do The test on the page showed that it's only a bit slower compared to the other mentioned virtualizer, so I gave it a run and it worked okay from the first moment. Stats indicated that there were some binaries around but we don't like binaries if we can get the source, right?

I've put a masked live ebuild in the tree and in fact we're the first distro that has virtualbox in the official repository. So give it a run if you want to see the power of open source
There are good docs available on the homepage but if everything fails, you can stop by in #vbox on freenode (upstream irc channel)