Over the last three or four weeks, I have been building the whole archive on a mipsel machine. The autobuild run with about 5400 packages has now been completed (many packages weren't actually built because a new version has entered the archive in the meantime and so the version I tried to build was no longer available but that's not a problem since the new version will be built by the Debian autobuilders anyway).
In the beginning, I was surprised about how few mips specific problems I found. It's probably not surprising given that I filed most of those bugs last time I built the archive but it's still good to see that they did actually get fixed. On the other hand, I found many generic failures for which other people (building on i386 or sparc) have submitted bugs a long time ago. Simple autobuild bugs left open for 90 days are unfortunately not uncommon. Towards the end, I found several mips specific bugs (outdated config.guess) and filed nine RC bugs. My list of packages was sorted by the date of the last upload but some packages were so old that they didn't have a date in the database; this put them at the end rather than the beginning of my sorted list. I also found two GOT errors for which Thiemo Seufer promptly offered a patch and a superb explanation. I can only echo Jordi's thanks to Thiemo — it's really a pleasure to work with him on the MIPS port.
In any case, in this entry I don't want to talk about MIPS failures but about something more general: packages breaking other packages (build) depending on them. It seems that quite a high number of new uploads have changes which break other people's packages. In just a few days, I found several failures because of this: docbook-dsssl switched from jade to openjade, thereby breaking im-sdk which explicitly needs jade, broken ALSA headers which break packages needing those headers, ocaml changing something in a new upstream release which broke regexp-pp, and a lesstif security update which causes other packages to fail to build. First of all, let me say that I'm not listing these cases to blame people. I think the maintainers did a pretty good job. Two of those bugs got fixed within hours and one maintainer sent some mail showing that he's investigating the case.
However, these cases are a good example to point out two things. First, regularly and systematically autobuilding the whole archive is very important to assurance that packages build with current toolchain and libraries. Second, people who have packages on which other packages (build) depend should really test their uploads by compiling these packages. When I filed the bug on lesstif, Sam Hocevar fixed it within hours and apologized for not testing any Motif 1 applications. Apparently, he tested his upload with some Motif 2 applications. I've always had a good opinion of Sam and it's good to see that he actually tested his new package by compiling some packages which build-depend on it. However, I honestly wonder how many maintainers do that. Seeing all the breakage which often occurs, I guess it's a minority.
I don't know if the Developers Reference mentions something like this already but if not it would be a good addition to tell maintainers to test their new uploads by building packages which build-depend on them. Obviously, you cannot test every dependent package, otherwise we'd never get new versions of libc or GCC uploaded. However, maintainers should be encouraged to take a sample of representative packages and see whether they still work with the changes they have made.