Re: notifications from buildds?
On Aug 15, Wouter Verhelst (wouter@grep.be) wrote:
> 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 :-) )
I guess I am about to learn something :-)
> 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" :-)
I do realize that maintaining a buildd machine is a lot of work - that was my
motivation for objecting that someone add yet another responsibility on them
that he could easily take care of himself. Hey, I'm on your side, I want to
reduce your workload! :-)
I consider almost all of what you listed as "making sure the buildd is working
properly and kept up to date" (sorry if the short phrase didn't do the scope
justice). All, that is, except the second to last (sending a bug report that
it failed), of which I was unaware since the vast majority of buildd failures
of my packages have _not_ resulted in a bug report to me. I've had FTBFS
failures of my packages because of m68k, alpha, hppa and arm specific bugs
that required changes to the source package, and I didn't think those were the
buildd maintainer's responsibility. If they are, I take my hat off to them
for going the extra mile, because I think it _should_ be the package
maintainer's responsibility to monitor his packages for such problems and fix
them. Of course, I see why the rest of the above make sense for the buildd
maintainer to handle and that package maintainers should not.
> Rg,
>
> Wouter (m68k buildd maintainer :-)
I should note that the m68k buildd maintainers were very helpful and
responsive when I recently had FTBFS problems with some of my packages on that
architecture. I hope I left a good impression in that exchange.
P.S. Is the above description of buildd maintainer duties documented anywhere?
--
Neil Roeth
Reply to: