Re: new buildd dependency resolution breaks self depends?
Kurt Roeckx <firstname.lastname@example.org> 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 <email@example.com> 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.
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