On 08/18/2014 12:34, Christoph Berg wrote: > Re: Ansgar Burchardt 2014-08-18 <53f1cbb6.8080...@debian.org> >> So it's a case of should never break in theory, but does in practice? :) > > Not quite. You just found the single package which wasn't updated for > 9.4 yet, because it's broken upstream. There was no RC bug about it > yet because I had it on my radar.
i.e. it breaks. >> Please don't silently regenerate d/control. It could generate a new one >> and *fail* the build if it differs; the maintainer should use a special >> target in d/rules or "mv d/control.new d/control" and restart the build. > > We rely on that mechanism to make backports and builds for > apt.postgresql.org to automatically create the right set of binaries. > > Note that the regeneration of debian/control should only happen on > "clean" which I believe the buildds do not invoke. Except that pg-reorg started to build packages not listed in d/control on buildds... Which lead me to write a bug report. https://buildd.debian.org/status/fetch.php?pkg=pg-reorg&arch=s390x&ver=1.1.9-2%2Bb1&stamp=1408310111 > The current transition > has been started weeks ago, and this is the first problem report, so > we can probably say the mechanism is working. It works unless packages are built at a different time than you expect, like binNMUs for other reasons. That's what I mean by "works in theory, but breaks in practice". > (Note that > with the current system, having to manually confirm the control update > would just have traded one kind of FTBFS for another kind, which I > wouldn't see as a change in the right direction.) It would at least FTBFS on the buildd and not upload broken things to the archive. Ansgar -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
