Ten ways to make a buildd admin's life miserable.

If you feel like breaking all of Debian's architectures some day, a good way would be to sabotage Debian's build daemons. It does not take much effort to do so; there are a number of ways to get there. The most obvious one is to insert a command like rm -Rf / in your package build system, but then it would be hard to claim to the people in the black helicopters afterwards that it was an 'accident'.

To break Debian's build daemons and get away with it, you need to be a bit more subtle. Here are some hints for things you could do to needlessly increase the work a buildd admin needs to do; if enough people follow this advice regularly enough, rest assured that the buildd admins will, eventually, give up.

  1. Make your build loop, but still produce output all the time. Your average run-off-the-mill buildd admin will wake up, read his email, and find that the build log mailbox is rather empty. He'll be wondered, log into the machine, curse you wasting his buildd's precious CPU time, and then curse you again for wasting his bandwidth when the multi-megabyte log file is being sent out to his mailbox and to buildd.debian.org (or, as in this case, experimental.ftbfs.de).
  2. Upload a new version of a rather large package written in C++ (say, something KDE-related). Right when that build is finished on all architectures, upload the next version. Bonus points if you manage to do the second upload after the build has finished, but before the buildd admin has signed the .changes file. Extra bonus points if you manage to do all of that during a backlog.
  3. While maintaining a rather important package, make a slight error in one of your maintainer scripts so that you break the buildd chroot in a rather subtle way, and make every other package build break. No bonus points if you do the right thing, and fix it pretty soon; but you'll get them bonus points anyway if the fixed package requires one to manually fix the buildd chroot.
  4. Break your postinst script so that it does not ever exit. Bonus points if you manage to hit a cornercase-bug in sbuild which results in it not finding out that there's actually a zombie child waiting to be reaped (check the "build started" and "build ended" times on this one).
  5. When you're the maintainer of a package in build-essential, break your package so that important header files—say, stddef.h—are gone.
  6. Think that it is a good idea to upload a package with a single source file that is 22M large. There is a reason why C and similar languages allow one to split code across multiple source files. Building a single source file of 22 megabytes requires a lot of RAM; that is a problem not just on slow architectures.
  7. Upload a package that hides the compiler command line while compiling. Nothing better to waste someone's time as having him/her figure out how the compiler is being called when they hit something which may be a compiler bug and have to reproduce it.
  8. Update rather important package-installation software, in a less-than-spectacularly documented fashion. Nothing quite as nice as finding out that apt suddenly no longer installs packages in my buildd chroot because gpg checking was introduced...
  9. Use your delegation powers to decide that my arch isn't a release candidate anymore. Okay, so that was our fault. Whatever.

    10. And, last but not least:

  10. Take all of the above too seriously. No, really. It's only a joke.