[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: unexpected NMUs || buildd queue



Wouter Verhelst <wouter@grep.be> writes:

> On Fri, Jul 16, 2004 at 09:42:00AM +0200, Goswin von Brederlow wrote:
>> Andreas Metzler <ametzler@downhill.at.eu.org> writes:
>> > BTW sometimes packages get stuck in the buildd queue, e.g. the initial
>> > build failed because of a transient error but the buildd maintainer
>> > does not process the buildd log for a long time (for reasons unknown)
>> > and reschedule the build. If this happens contacting the buildd admins
>> > helps. (Don't sk me what "a long time" is, it depends on how big the
>> > buildd's backlog is and whether the update i urgent.)
>> >         cu andreas
>> 
>> Most likely reason I can think of is when buildd logs are too big and
>> get not delivered by the mail system. Some packages have buildd logs
>> exceeding 30MB and some peoples mailserver might not accept them.
>
> If a package log exceeds 30MB, I'd say the chances of it being a
> transient error are pretty slim.

Missing Depends on -dev packages can produce a lot of compiler
warnings. Since fixing the -dev package fixed the FTBFS I would call
that transient too. But maybe you just ment uninstallable
build-depends.

> What's more likely is one of
> * The buildd maintainer decided to investigate further on the buildd box
>   itself, but forgot or didn't finish that investigation

Human error. Sure.

> * The buildd box went down somewhile during the build, and the build was
>   aborted or something due to that, resulting in "lost" packages

Shouldn't buildd check the current file and return or retry it when it
is restarted? That shouldn't be too hard to do.

When is a packages removed from the buildds private build queue? When
the build starts or when it is finished?

> * something freaky (something I didn't think of) happened to the buildd ;-)

That is always scary. :)

MfG
        Goswin



Reply to: