Re: Where did Bacula 1.38.11-7+b1 come from?
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.
vorlon@debian.org http://www.debian.org/
Reply to: