Hi John, On Thu, Feb 22, 2007 at 12:44:21PM -0600, John Goerzen wrote: > On Thu, Feb 22, 2007 at 07:26:35PM +0100, Andreas Metzler wrote: > > Hello, > > A binNMU does not show up in the pts, since there are no source > > changes.
> Hmm, I wonder if it would be possible for it to show up? Since there > are .changes files with binNMUs, and presumably also migration to > testing statuses? There are no wait periods and no bug checks for migrating binNMUs to testing; only dependencies are checked. That's one perceived advantage of using binNMUs. > > > Does anybody know what is going on here? > > http://lists.debian.org/debian-release/2007/02/msg00647.html > That seems to explain it (I think). Though I am still confused about > why a binNMU is being used even though it is being rebuilt across all > archs. Because the overhead of sending release-critical bugs to (in this case) 7 different maintainers, tracking those bugs, and eventually NMUing is much greater than that of sending automated requests to the buildd maintainers requesting binNMUs; because it's entirely possible that not all architectures *will* need binNMUs in cases like this (e.g., pdns was binNMUed on 4/12 archs); becaue no sourceful changes are actually required -- just rebuilds. It's been documented for some time that porters have the power to do binNMUs of packages; mass-binNMUs are merely an extension of that. In effect, what I'm doing is /requesting/ binNMUs via wanna-build, it's still the buildd maintainers who review, sign & upload the binaries after they've been autobuilt. > I maintain that anyone that uploads a package that is uninstallable *at > the time of upload* needs something more than gentle encouragement. To > upload someone else's package and render it uninstallable is even more > annoying. To do that without ever even filing a bug, let alone posting > info to the BTS about it, is even more so. But in effect, there are no bugs here that need to be tracked; by definition, if this were any bug that could be fixed in your package, it wouldn't be suitable for a binNMU. > Having said that, I would have sent a polite message in private to the > person that made the uploads. Only there is no record of that in the > package or the QA system. The number of people who are going to be doing this sort of binNMU is limited -- there are a handful of people who have wanna-build access for all archs, and only two (Ryan Murray and myself) who I know actively use it for scheduling binNMUs. Of course, any porter/buildd maintainer might schedule a one-off binNMU for their architecture, and if it goes via autobuilder you might still have this problem of unchecked dependencies in a package being uploaded. > * The upload violated policy section 4.4, in that the maintainer name > and the email address of the *person* uploading the version do not > appear in the changelog. In fact, each upload *does* include information about the source of the upload, by way of the autobuilder; since there is no source upload, the only uploads are the binaries (hence binNMU), and for each binary the uploader is different. I see that not all of the changelogs include a valid email address. Well, the buildd maintainers can be reached at <arch>@buildd.debian.org in that case. This seems like it would be good to document in that section of the devref. > Since this was a binNMU that effectively seems to have hit all archs, it > seems that the regular NMU requirements should apply, too (Devref sec > 5.11.1): Well, they don't; that section addresses sourceful NMUs (and says exactly that in 5.11), which this was not. But, ok: > * Make sure that the bug being fixed is in the BTS There was no bug in the package, only in the build environment where the packages had been built, so what should be put in the BTS? > * Wait for maintainer reaction What reaction should we wait for? Maintainers don't do porter uploads; porters do. > * Take responsibility for bugs you've introduced Well, the primary bug here is that bacula wasn't binNMU-safe. That bug wasn't introduced by the binNMUs themselves. :) Be that as it may, I certainly would have taken responsibility for the broken binary packages, but I'm afraid you fixed it before I had any opportunity to do so. > If you break something, you fix it. Not make someone else spend time > figuring out what changed, why, by whom, and fix it. Ok, next time please leave me something to fix... ;) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
