I’ve been running Buildd.Net for quite a long time. Buildd.Net is a project that focusses on the autobuilders, not the packages. It started back then when the m68k port had a small website running on kullervo, a m68k buildd. Kullervo was too loaded to deal with the increased load of that website, so together with Stephen Marenka we moved the page from kullervo to my server under the domain m68k.bluespice.org. Over time I got many requests if that page could do the same for other archs as well, so I started to hack the code to be able to deal with different archs: Buildd.Net was born.
Since then many years passed by and Buildd.Net evolved into a rather complex project, being capable to deal with different archs and different releases, such as unstable, backports, non-free, etc. Sadly the wanna-build output changed over the years as well, but I didn’t have the time anymore to keep up with the changes.
Buildd.Net is based on:
- some Bash scripts
- some Python scripts
- a PostgreSQL database
- gnuplot for some graphs
- some small Perl scripts
- … and maybe more…
As long as I was more deeply involved with the m68k autobuilders and others, I found Buildd.Net quite informative as I could get a quick overview how all of the buildds were performing. Based on the PostgreSQL database we could easily spot if a package was stuck on one of the buildds without directly watching the buildd logs.
Storing the information from the buildds about the built packages in a SQL database can give you some benefit. Originally my plan was to use that kind of information for a better autobuilder setup. In the past it happened that large packages were built by buildds with, let’s say, 64 MB of RAM and smaller packages were built on the buildds with 128 MB of RAM. Eventually this led to failed builds or excessive build times. Or m68k buildds like Apple Centris boxes or so suffered from slow disk I/O, while some Amiga buildds had reasonable disk speeds (consider 160 kB/s vs. 2 MB/s).
As you can see there is/was a lot room for optimization of how packages can be distributed between buildds. This could have been done by analyzing the statistics and some scripting, but was never implemented because of missing skills and time on my side.
The lack of time to keep up with the changes of the official wanna-build output (like new package states) is the main reason why I want to give Buildd.Net into good hands. If you are interested in this project, please contact me! I still believe that Buildd.Net can be beneficial to the Debian project. 🙂
merge into buildd.debian.org?
Have you considered looking at the official buildd site and comparing it with buildd.net and filing bugs for each additional feature that you find?
The official buildd site is
The official buildd site is package-centric and in the (long ago) past there was some effort from my side for a closer cooperation, but that was turned down by the officials.
Anyway, if the mind has changed on the official site I’m open for working together, but comparing both sites and filling bugs appears too time consuming too me and that’s the reason why I want to give away the project: no time. So, sadly this won’t happen as well, although it would be the best solution to integrate it into the official buildd suite. 🙁