Buildd.Net

When you see DB-maintenance! in the top left corner on the arch pages, it means that the database import script for the Packages files is running. This is a quite excessive task currently and it happened quite often that concurrent accesses/updates to the database from the page generating scripts resulted in broken web pages... This is now avoided by pausing the generation of the webpages. Usually this should only take approx. 30 mins.
When the source for this is released you might be able to give me some hints how to prevent those problems. ;)

When you're running a buildd, it is pretty easy to participate in status update on buildd.net:

• Send me an email with the needed information as buildd name, host, RAM, disk, buildd maintainer and all the other information that is displayed on the lists.
• You'll receive an answer with a password.
• Download update-buildd.net and run update-buildd.net once and a directory in your home dir of the user named '.buildd.net' will be created. Therein you can find a config file named 'update-buildd.net.conf' - edit to your needs, at least you need to change these two lines:
  

  	HOST=`hostname`  # change only if hostname reports a different name 
  	# than the registered one on buildd.net
  	PASSWD=yourpassword 
  	

• Setup two cronjobs (please at a random time such as *:31, *:47 or *:09 or similar) on your buildd similar to this one:
  

  	3-59/15  *    * * *    ~/bin/update-buildd.net status || true
  	57       */2  * * *    ~/bin/update-buildd.net heartbeat || true
  	

update-buildd.net status updates the package, which is actually being built on buildd.net, and heartbeat updates the time in the buildd.net DB (see here for details). The heartbeat cronjob doesn't need to run hourly, just regularly, so that an interval can be calculated and therefore can be checked, if the heartbeat is overdue or not.
As of version 0.4 of the update-buildd.net script it doesn't matter how often you call that script with option 'status', because it checks if the last reported building package differs from the actual building one. So it saves some bandwidth, too.
The update-buildd.net v0.1 script has been written by Thimo Neubauer. Thanks, Thimo, for your contribution! This is a sample implementation. You can, of course, write your own client. Please see the source code of update-buildd.net what form fields are supported by buildd.net or contact me via the feedback form.

Please don't abuse the reason and building abilities as short message method to display 'funny' things. That's not the intention of those methods.
When your are the first buildd of your arch, it is most likely that the whole arch is not yet listed on buildd.net, but that's not a problem at all. Buildd.net lists only participating archs because it tries to give additional information to the developers f.e. such as downtime reasons or so. Therefore it is just a little prerequisite to have a participating buildd to get an arch listed on buildd.net.

Currently the column 'time' displays the timespan the package listed under the column 'Building' is actually building.
Keep in mind that the HTML pages are updated as described under How often are these pages updated? and therefore the listed timespans are not very accurate. The faster the buildd is, the more inaccurate the times might be (compared to the build time from the build logs). But this is a feature in progress....

arch
Well, this is obvious, isn't it? ;-)

name
This too. It's the shortname of the buildd. Usually this can be found as well in the build logs you can find on buildd.debian.org.

lastseen
Lastseen is the timestamp when the buildd updated its status the last
time. The time is in localtime, which is for the server location during
the northern summertime CEST = UTC+2 and during winter CET = UTC+1.
Usually all times on this site are in that timezone if not otherwise stated.

interval
The interval is the time between two updates and is important for the last column.

expected at
This is probably the most important column. It defines until when a buildd have to update its status again to not marked as being down. It is 4x the interval duration. After 1.25x the interval the machine will be marked as "no response".

The little LED-style images are intended to give a quick overview to all buildds of an arch. There a basically several types of status LEDs for the host itself and for the buildd in particular. More to come.
Here a some common meanings:

Host centric LEDs:
up
The host is up and running. It regulary updates its status. Everything is fine with the machine itself and its connectivity.
no response
The host exceeded its update interval by 1.25x the previous interval. It is now marked as not responding. This might be caused by a intermittent network problem for example.
down
The machine hasn't updated its status 4x in a row. It is marked as down now. The might be caused by a crash of the machine.
not participating
The buildd admin has decided to not participate with his machine. For whatever reason he has. Ask him. :-)

buildd centric LEDs:
idle
The buildd runs, but is idle.
building
The buildd runs and is building a package.
stopped
The buildd has been stopped by touching NO-DAEMON-PLEASE.
not running
The buildd does not run at all.
wait for key
The buildd has no access to wanna-build database and cannot automatically build packages therefore. But maybe some friendly mind runs some manuals builds on it to use its CPU for something useful.
need setup
Usually this occurs when a new buildd is added. But it might happen as well that this was caused by a serious chroot breakage and the admin needs to re-install the buildd environment.

The buildd host list is updated every 15 mins. You can see the time of last update on the buttom of the page.

The short answer is: it depends (what you mean?). :-)
The long answer is:
The data behind these pages is updated every hour currently for unstable and every 12 hours for experimental, non-free, volatile. On every page there is something like:

Based on wanna-build dump from buildd.debian.org,
generated at: 2005-09-09 14:43:16 UTC+1

There you can see, when the data behind that page is last updated or - more exactly - last obtained from it's data source, usually a wanna-build. This timestamp is also listed when you do a Package status search: beneath each arch name, the appropriate timestamp is listed.

The HTML pages and the host & buildd status itself is updated every 5 minutes. So, when a buildd updates its status it takes at most 5 minutes until you can see the changes.
Of course, when the demand is high for it, the updates can be done more frequent.

Some years ago the m68k port was in a very bad shape. There was just kullervo as a buildd for m68k and over the time it couldn't keep up building packages. There were roughly around 400 packages in Needs-Build state, when I read on the debian-68k mailing list a posting from Christian Steigies searching for help. Because my Amiga 3000 with 68040/40 was just doing dnet rc5 key cracking, I thought that helping Debian with the m68k port might be a more valuable effort for that machine than just cracking keys for dnetc. Well, Arrakis was then the second buildd for m68k and within weeks the backlog was brought down.
But over time the number of packages raised and the complexity of packages as well, resulting in new backlogs from time to time. So, over time there has been a sort of "buildd farm" for m68k established and a completely own infrastructure was used.

The precessor of these pages was first setup by Rick Younie and located on his buildd, named "bruno". Then these pages moved to a new public machine called "crest". In the meanwhile these pages became useful not only for the m68k porters to check the status of their builds, but also for Debian Developers and maintainers. From time to time a maintainer asked why this kind of page only exist for m68k and not for the other archs as well?

One of the reason might have been that the parsing and generation of the page took up to 10 minutes on crest - only for m68k. Due to this fact, Rick disabled this service on crest during autumn 2003 because it took too much cpu time away. I offered him to host this service on my service and so the page moved. First it was available under http://m68k.bluespice.org/ but then I registered buildd.net and .org later on, because we enabled the generation of buildd stats for all archs. On the new machine it took only 2 minutes - for all archs.

Well, the page became quite well-known and was referenced by other people and I'm happy that many Debian Developers appreciate this service as an additional source of information to buildd.debian.org.
Therefore, I invested some time to enhance these pages a little bit, made them more supportable by me and added some new feature such as buildd status update, new graphical stats and some minor improvements (f.e. you can now see how old the wanna-build data is from which these pages are generated).

Yeah, but why all this?
It's simple. Because during the years there always arose the same kind questions on the m68k porters list, like "Why is m68k holding my package to go into testing?", "Please rebuild my package xyz!", etc.. These pages try to give you (as a maintainer) a helping hand to find your answers on your own. www.buildd.net lists some buildd related texts such as from Wouter Verhelst or Michael Schmitz. And it tries to help you to find your wanted information as quick and easy as possible.
So, if you have some idea to make this even more usable for you, please let me know! :-)