Sat Sep 30 14:19:26 CEST 2006
Tinderboxing again, and Reports
Today I've restarted the tinderbox - I fixed a few minor bugs and moved
some parts over to pkgcore. The compilation is fully driven by emerge,
just bits like checking USE-flags are now about ten times as fast.
I don't have any real estimates how long this will run, from a limited sample of packages I'd guess around 350 hours (or roughly three weeks) for the initial run. So maybe I'll stop, emerge --sync and restart every week or so so that I don't fall to far behind the actual state of the tree.
And because I'm exquisitely lazy I've got a cronjob generating a few reports every 6 hours. I'm thinking about collecting the reports and generating graphs from them - would be nice to see how good our QA efforts are. And ... erm ... while I was digging around I found some really evil stuff in ebuilds. I'll file some bugs, of course - but seeing someone use "echo" instead of einfo is painful, and 'grep foo /var/db/pkg/' might not be the smartest thing to do in an ebuild.
I just hope I don't find more stupid things like that, filing bugs for every silly things is getting a bit annoying :-) But then it's for greater goodness, so release zig, for great justice!
I don't have any real estimates how long this will run, from a limited sample of packages I'd guess around 350 hours (or roughly three weeks) for the initial run. So maybe I'll stop, emerge --sync and restart every week or so so that I don't fall to far behind the actual state of the tree.
And because I'm exquisitely lazy I've got a cronjob generating a few reports every 6 hours. I'm thinking about collecting the reports and generating graphs from them - would be nice to see how good our QA efforts are. And ... erm ... while I was digging around I found some really evil stuff in ebuilds. I'll file some bugs, of course - but seeing someone use "echo" instead of einfo is painful, and 'grep foo /var/db/pkg/' might not be the smartest thing to do in an ebuild.
I just hope I don't find more stupid things like that, filing bugs for every silly things is getting a bit annoying :-) But then it's for greater goodness, so release zig, for great justice!
Sun Sep 24 15:48:26 CEST 2006
Tinderboxing continued
So I've had my tinderbox run for ~16h with only two or three
interuptions. It's quite interesting to compare amd64 to x86 - looks
like x86 carries a lot of cruft that is not well maintained. That is to
be expected, but still mildly frustrating.
There's a few things that slow down the process:
- the infinite build - app-admin/fam tends to go into an infinite waiting loop. Takes a bit longer than I can accept ;-)
- aclocal b0rkage. Quite a few ebuilds have not been adapted to the latest changes in autotools, usually trivial to fix.
- use-based dependencies: we need them. So many ebuilds fail with "please recompile app-fruit/banana with the apple useflag", would be very easy to filter that out in depgraph building if portage had that feature. Who needs to be bribed? ;-)
Many thanks to jakub who finds dupes where my search skills fail. I blame the lack of canonical bug titles - but then we'd have to train bugzilla users even more.
Since there were a few unexpected failures in the build process I did some tweaks (useflags and package.mask) and restarted. Now I wonder - how fast are we adding packages to the tree? Is that faster than I can compile? Will I be able to catch up after the first full build? As I'm keeping logfiles it shouldn't be hard to extract information about average build time etc. - I'll do that once I have the report generation up and running :-)
There's a few things that slow down the process:
- the infinite build - app-admin/fam tends to go into an infinite waiting loop. Takes a bit longer than I can accept ;-)
- aclocal b0rkage. Quite a few ebuilds have not been adapted to the latest changes in autotools, usually trivial to fix.
- use-based dependencies: we need them. So many ebuilds fail with "please recompile app-fruit/banana with the apple useflag", would be very easy to filter that out in depgraph building if portage had that feature. Who needs to be bribed? ;-)
Many thanks to jakub who finds dupes where my search skills fail. I blame the lack of canonical bug titles - but then we'd have to train bugzilla users even more.
Since there were a few unexpected failures in the build process I did some tweaks (useflags and package.mask) and restarted. Now I wonder - how fast are we adding packages to the tree? Is that faster than I can compile? Will I be able to catch up after the first full build? As I'm keeping logfiles it shouldn't be hard to extract information about average build time etc. - I'll do that once I have the report generation up and running :-)
Sat Sep 23 23:15:51 CEST 2006
Tinderboxing
I've been meaning to do this for quite some time, but somehow I always
found excuses not to do it. So, just for fun, I've taken swegener's
tinderbox scripts, fixed it with the help of marienz and ferringb
(thanks to you guys!) and let it run.
Here is the output of emerge building the highest visible version of every package that is in the tree - x86 and AMD64.
Small bonus of all that compiling:
BinPKGs, also in x86 and AMD64 flavours (with PPC32 and PPC64 coming soon)
Of course that goes without warranty, if the logfiles don't reflect reality or the binpkgs eat your system don't blame me, I didn't ask you to use it ;-)
From the people that brought you pkgcore comes pkgcore-checks - a magic collection of scripts that find lots 'o b0rkage. I haven't set up cronjobs yet, but looking at the reports can be quite scary. I hope that this helps to find and fix some silly bugs ... next up: ~arch auto-compiler ;-)
Here is the output of emerge building the highest visible version of every package that is in the tree - x86 and AMD64.
Small bonus of all that compiling:
BinPKGs, also in x86 and AMD64 flavours (with PPC32 and PPC64 coming soon)
Of course that goes without warranty, if the logfiles don't reflect reality or the binpkgs eat your system don't blame me, I didn't ask you to use it ;-)
From the people that brought you pkgcore comes pkgcore-checks - a magic collection of scripts that find lots 'o b0rkage. I haven't set up cronjobs yet, but looking at the reports can be quite scary. I hope that this helps to find and fix some silly bugs ... next up: ~arch auto-compiler ;-)