Op vr 15-08-2003, om 05:05 schreef Neil Roeth: > On Aug 14, Mark Howard (mh344@cam.ac.uk) wrote: > > On Wed, 13 Aug 2003 20:21:08 +0200, Joerg Wendland wrote: > > > > > Hi *, > > > is there a possibility to get notifications about success or failure of > > > builds of one's packages without having to poll buildd.d.o? Sorry if that > > > has been asked before, I didn't find anything. > > > > The answer I was given when I asked was that you will be informed of > > anything you need to deal with through the bts. Most build failures are > > not your fault (uninstallable packages), so you just have to wait and try > > again which is what the buildds do automatically. When something is your > > fault, the buildd maintainers will report a bug. > > That strikes me as irresponsible; why should it be the buildd maintainer's job > to monitor your packages? They should make sure the buildds are working > properly and are kept up to date, nothing more. If anything shows from this mail, it's your cluelessness wrt buildd machines (no pun intended :-) ) It is not a buildd maintainer's job to monitor any package (or any maitainer's packages) specifically; however, it is the buildd maintainer's job to monitor the work of the buildd; to check if everything keeps working, to make sure brokenness is fixed, to make sure things such as /proc and friends are mounted inside the building chroot, etcetera. The best way to do that is to monitor the actual builds running on the buildd. Indeed, for every package for which a build is _attempted_ on a buildd, the maintainer is sent a log (with a Cc: to logs@buildd.debian.org, so that everyone can see the same log through http://buildd.debian.org/). Based on that logfile, the buildd maintainer can do a number of things: * If the package was successfully built, extract the .changes from the logfile, sign it, and send it back so that the package will be uploaded. * Re-queue the package so that it will be rebuilt by another buildd (or by the same one provided a few hours have passed. * Immediately retry the build on the same buildd. This can happen, e.g. if the buildd's chroot was broken but has been fixed in the mean time, or if there were network failures while trying to download the source or any required build-dependencies. * Record the package as waiting for dependencies before it can be built (if a package depends on a library which currently fails to build on a specific architecture, this is what will happen). Once the dependencies become available, wanna-build will automatically requeue the package. * Mark the package as failed, so that it will not be retried until the next version is available. When this action is taken, depending on the reason for the failure, a bug report should be sent in as well; this is not done automatically (as there are occasionally failures that are not the package maintainer's fault, but require the package to be marked as failed non the less, although I cannot come up with an example right now) * Mark the package as architecture-specific, so that it will never be retried without manual intervention. Doing all that correctly requires some experience, and in some circumstances a good knowledge of the buildd's environment and history as well. Depending on package maintainers to be able do that correctly is thus quite unrealistic. In any case, my point was that there's a lot more to maintaining a buildd machine than just "making sure the buildd is working properly and kept up to date" :-) Rg, Wouter (m68k buildd maintainer :-) -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org "An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts." -- National Geographic Channel, in a documentary about large African beasts.
Attachment:
signature.asc
Description: Dit berichtdeel is digitaal ondertekend