[buildd-tools-devel] new buildd dependency resolution breaks self depends?

Goswin von Brederlow goswin-v-b at web.de
Wed Mar 30 20:22:43 UTC 2011


Kurt Roeckx <kurt at roeckx.be> writes:

> On Wed, Mar 30, 2011 at 06:45:50PM +0200, Wesley W. Terpstra wrote:
>> On Tue, Mar 29, 2011 at 8:03 PM, Kurt Roeckx <kurt at roeckx.be> wrote:
>> 
>> > On Tue, Mar 29, 2011 at 07:54:59PM +0200, Wesley W. Terpstra wrote:
>> > > If I may ask, for what purpose do the buildds have a special list of
>> > > packages above and beyond those in unstable?
>> >
>> > So that in case various packages have to be build in an order,
>> > where the seconds depends on the first being available and so on,
>> > that it doesn't take weeks to get them all build.  We would have
>> > to wait at least a dinstall before the next one could be build,
>> > assuming sometimes has the time to sign the package between
>> > dinstalls.
>> >
>> > It basicly just avoids a whole lot of delays.
>> >
>> 
>> Unfortunately, it seems also to add quite some delays in the self-compiling
>> case. :-/ Each time a buildd finishes, that buildd's Packages file gets
>> updated due to the completed binary upload and all other buildds go back
>> into the BD-Uninstallable state. (I assume this also means the package loses
>> its place in line on the busy buildd queues)
>
> That actually doesn't seem to be that case.  I think ftp-master
> just removed the old binary from unstable, and didn't give the
> buildd's the chance to actually build against the old version,
> and we're screwed now.
>
> I suggest you ask them to restore the old binaries in unstable,
> (and remove the arch all) packages for those arches it's not
> yet build/uploaded for.
>
>
> Kurt

It used to be that any _all.deb uploaded was added to all archs
directly. Under that setup the build would never have succeeded.

Having it suceed with a delay between upload and builds is an
improvement already.

MfG
        Goswin



More information about the Buildd-tools-devel mailing list