Please reply to buildd mails

[Thorsten Glaser <tg@mirbsd.de>]

Hi,

there are now 125 packages in state Build-Attempted.
Dear co-builddadmins, if you get a mail saying log for _attempted_
build (not “for failed build”, these get giveback immediately by
the buildd software), do:

① Look through the build log (gzip compressed attachment, or on
  http://buildd.debian-ports.org/status/package.php?p=$pkgname ).
② Scan for a failure reason. If none can be seen, reply to the
  mail, to the buildd, with a mail whose body is just the one
  word “fail” on a line of its own, then goto 5. Otherwise,
  $failure be the reason.
③ Look whether it’s worth to reportbug against the package. If
  so, mention $reason in the bug, wait until the bug is recorded
  in the BTS, and set $reason = "#123456" where 123456 is the bug
  number in debbugs
④ Reply to the mail, to the buildd, with a message body looking
  like "fail\n\n$reason\n". Optionally, if it’s not been reported
  to the BTS and Julien Cristeau is not the maintainer (or any
  other person complaining about “yay, more debian-ports spam”),
  consider putting the package maintainer on Cc (may want to put
  the buildd on Bcc then)
⑤ Now, and only now, you’re allowed to delete that mail ;-)
⑥ If the package’s reason to FTBFS is that it needs porting, and
  such porting is unlikely to be done in the next upload or other‐
  wise RSN, ssh to leda and set the package on the Not-For-Us list:
  $ wanna-build -A m68k -d unstable -n ${Source}_${Source:Version}
  *BEFORE* doing so, make sure that the “fail” mail from your buildd
  is processed, by running:
  $ wanna-build -A m68k -d unstable --info ${Source}
  And inspecting the output; good looks like this (relevant fields):
   python-event:
     State               : Failed
     Previous-State      : Build-Attempted
     Failed              : #632763
  And bad looks like this:
   mingw32:
     State               : Build-Attempted
     Previous-State      : Building
  That’s bad because it’s missing a reason, *and* your buildd is
  still keeping state. For the record, after -n it looks like:
   mrpt:
     State               : Not-For-Us
     Previous-State      : Failed
     Old-Failed          : -------------------- 1:1.0.0-1 --------------------
       virtual memory exhausted: Cannot allocate memory
       apparently 768 MiB RAM + 3.6 GiB swap aren=E2=80=99t enough.
       We cannot provide more on m68k really.
  That’s why. (Though p.d-p.o doesn’t seem to display these reasons
  for N-F-U packages, only for Failed ones, which we might want to fix.)

Thanks,
//mirabilos
-- 
Sorry,  I’m annoyed today and you came by as an Arch user. These are the
perfect victims for any crime against humanity, like  systemd,  feminism
or social democracy.
		-- Christoph Lohmann on dev@suckless.org