Re: unexpected NMUs || buildd queue
Wouter Verhelst <wouter@grep.be> writes:
> On Sat, Jul 17, 2004 at 06:14:15AM +0200, Goswin von Brederlow wrote:
>> Wouter Verhelst <wouter@grep.be> writes:
>> > 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.
>
> I didn't say it's impossible, I said the chances are pretty slim :-)
>
> (sure, it could theoretically happen that a missing depends from one
> -dev package to another causes a failure when 90% of the build is done,
> but usually it happens quite a bit earlier)
I had a cascade of such failures lately on amd64 because gcc had a bug
in /usr/lib/libffi2.la that caused 3rd generation Build-depends to
break, i.e. X fails because Y miscompiled because Z gets the wrong
Depends because libffi2.la is broken.
So I had that fresh in my mind.
> [...]
>> > * 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?
>
> When it is finished, I presume. Not sure, never looked at the source
> that closely.
>
> In any case, buildd doesn't write to disk what it's doing (the
> build-progress file is written by sbuild), so if it's aborted
> incorrectly (i.e., it doesn't have time to write a REDO file), that
> information goes lost.
>
> That's probably a bug, but once you know about it, it's easy to work
> around (it just means you have to clean up after a crash, but you have
> to do that anyway, so...)
Which is one of the things realy screwed up on the buildd/sbuild
combination.
Reply to: