On Tue, Apr 06, 2004 at 11:52:58PM +1000, Mark Purcell wrote: > One thing I don't exactly understand, and haven't been able to find documented > is the criteria by which the buildd kick off a buildd request of a previously > failed build. > > For this case in point the last rebuild of t38modem on m68k was attempted > on 28 Feb 04. The t38modem dependant packages which fixes the issues > which failed on 28 Feb 04, is the openh323 build which was successful on > m68k on 22 Mar 04. > > How was the buildd to know that t38modem should be rebuilt given the new > openh323 which was succesful on 22 Mar 04? If the build failed due to an obvious build-dependency, then the operator may place the buildd in state dep-wait. It then automatically requeues when that dependency is fulfilled. Neither of these seemed to be immediately obvious build-dep problems, so they were failed (a FTBFS bug was also filed), only to be requeued manually or when a new upload was made. buildd.net and buildd.org have facilities for you to determine what state your package is actually in. Basically, your package is needs-build until an autobuilder picks it up. It is then building until a buildd operator does something. For success, the log is signed and the package gets uploaded. For failure, usually it ends up in state dep-wait or failed. hth, Stephen -- Stephen R. Marenka If life's not fun, you're not doing it right! <stephen@marenka.net>
Attachment:
signature.asc
Description: Digital signature