Maintainer stupidity
As a buildd admin, you get to see the myriad of ways in which packages can fail to build. Sometimes this is due to interesting technical reasons about the architecture in question; sometimes... not so much.
cc1: unknown option: -mmmx
For reference, I maintain powerpc and m68k buildd hosts.
configure: error: pkg-config: command not found
Checking build-dependencies is hard. Right?
ccache: failed to create /home/buildd/.ccache (No such file or directory)
No, I don't manually install ccache inside the buildd chroot, which must mean some build-dependency pulled it in. Why one would want to do that, I dunno—it's not like a build that takes longer would produce a different package, so it clearly is not required for the build.
(BTW, the invalidity of $HOME is on purpose -- packages are not allowed to write outside their build directory during builds, which includes home directories)
... and more. Sometimes, I wonder how people get the right to upload. But, well.
Of those three errors, two of them look like they could be caught by automated tools like pbuilder. I can see why such tools can't easily catch the -mmmx hard-coded (if you're only building on i386 and amd64, you'd not discover it), but I'd have thought that not only could running pbuilder just before you upload catch a bad build deps, but it could also catch FS accesses outside your build directory.
Given this, would it be fair to say that the cause of the problem is DDs not being aware that they can "quickly" run their package through pbuilder or the like just before upload, and discover faults that don't show up most of the time?