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

Re: dpkg upload


On Sun, 2010-08-01 at 13:48:54 +0200, Philipp Kern wrote:
> next time, when uploading a piece as critical as dpkg, please look at the
> archive state before uploading.  dpkg had so strict dependencies
> that it could not be built anymore (due to debhelper, dpkg-dev and
> libdpkg-perl I think), as the dpkg version on mips was still
> (Newer source uploads also auto-trashed the builds on buildds.)  A quick
> glance at rmadison would've told you that.

Actually, the strict dependencies introduced in should have
been there in 1.15.8, so the fact they were missing was just a bug
(and a helpful one, or all the architectures would have suffered the
same fate :).

I don't see why it cannot be built anymore, the only thing changed was
bumping a dpkg-dev Depends on dpkg, at which point the new dpkg-dev
(arch:all) became uninstallable because the new dpkg (arch:any) was not
yet available, *but* those are always installed on buildds.

Now that you've brought this up, I've recalled last time this happened
(2007-12, dpkg 1.14.14) it was deemed a problem in wanna-build's
AutoDepWait support. This was discussed in oftc.net on #debian-release
back then.

If I had remembered this would cause problems again I'd have checked,
so I think it's a bit unfair blaming us (well me as the one doing the
change and the upload :) when this seems like a bug in a piece of the
build infrstructure.

(BTW I'd be curious to know what the source auto-trash thingy means.)

> So I had to build against testing after the whole of unstable got
> moved to bd-uninstallable, that's also why the binNMU happened on mips.

Regardless of the above, I'm sorry this caused you guys major
inconveniences. A positive outcome though, is that a bug was unvelied.
I'll be uploading .3 tomorrow, just in case anything else pops up.


Reply to: