Re: binNMUs: please exercise some care
Philipp Kern dixit: >> Maybe wb could do a “dak ls” and whatever the equivalent for dpo mini-dak is. > >Unfortunately it is not being run on the same host as dak either. Hm, rmadison then. What does packages.d.o/sid/binpkgname use? (On the other hand, that’s often quite behind…) bye, //mirabilos -- exceptions: a truly awful implementation of quite a nice idea. just about the worst way you could do something like that, afaic. it's like anti-design. that too… may I quote you on that? sure, tho i doubt anyone will listen ;)
Re: binNMUs: please exercise some care
On Fri, Oct 23, 2015 at 02:46:23PM +0200, Thorsten Glaser wrote: > On Fri, 23 Oct 2015, Adam D. Barratt wrote: > > and testing), so the only way to be certain what binNMU number to use is to > > check manually. In practice what actually happens is that people forget > > about > Maybe wb could do a “dak ls” and whatever the equivalent for dpo mini-dak is. Unfortunately it is not being run on the same host as dak either. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: binNMUs: please exercise some care
On Fri, 23 Oct 2015, Emilio Pozuelo Monfort wrote: > I didn't say once per arch. I said once per package, which is worse. I > normally > schedule binNMUs for several dozens packages. Multiply that by several But you need to look the number up anyway? The wanna-build --binNMU parameter gets the number to use as argument. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Re: binNMUs: please exercise some care
On 23/10/15 13:02, Thorsten Glaser wrote: > On Fri, 23 Oct 2015, Adam D. Barratt wrote: > >> wanna-build does, yes, but at least the Release Team tend to use the "wb" >> wrapper tool which automatically works out the next free number on each >> architecture. > > Ah, cool – so we have only to patch this tool to automatically > use the highest number per batch on all affected architectures > (or even to use the highest number if all architectures would > be touched, but that’s probably an unreasonable amount of code > change). Sorry, aren't you saying the same thing in both cases? If not, can you rephrase or expand that? > Where’s the source code to that tool? https://anonscm.debian.org/cgit/mirror/release-tools.git/tree/scripts/wb Please open a bug report against release.debian.org when submitting a patch. Cheers, Emilio
Re: binNMUs: please exercise some care
On 23/10/15 13:21, Emilio Pozuelo Monfort wrote: > On 23/10/15 13:02, Thorsten Glaser wrote: >> On Fri, 23 Oct 2015, Adam D. Barratt wrote: >> >>> wanna-build does, yes, but at least the Release Team tend to use the "wb" >>> wrapper tool which automatically works out the next free number on each >>> architecture. >> >> Ah, cool – so we have only to patch this tool to automatically >> use the highest number per batch on all affected architectures >> (or even to use the highest number if all architectures would >> be touched, but that’s probably an unreasonable amount of code >> change). > > Sorry, aren't you saying the same thing in both cases? If not, can you > rephrase > or expand that? > >> Where’s the source code to that tool? > > https://anonscm.debian.org/cgit/mirror/release-tools.git/tree/scripts/wb > > Please open a bug report against release.debian.org when submitting a patch. OTOH, I'm not sure this fix is appropriate. It just feels like a workaround for a dpkg bug, which would be better fixed in dpkg itself. This won't help when we have to schedule a binNMU on one or two architectures and not all of them. Emilio
Re: binNMUs: please exercise some care
On 2015-10-23 11:56, Thorsten Glaser wrote: On Fri, 23 Oct 2015, Emilio Pozuelo Monfort wrote: I didn't say once per arch. I said once per package, which is worse. I normally schedule binNMUs for several dozens packages. Multiply that by several But you need to look the number up anyway? The wanna-build --binNMU parameter gets the number to use as argument. wanna-build does, yes, but at least the Release Team tend to use the "wb" wrapper tool which automatically works out the next free number on each architecture. Regards, Adam
Re: binNMUs: please exercise some care
On Fri, 23 Oct 2015, Emilio Pozuelo Monfort wrote: > >> Ah, cool – so we have only to patch this tool to automatically > >> use the highest number per batch on all affected architectures > >> (or even to use the highest number if all architectures would > >> be touched, but that’s probably an unreasonable amount of code > >> change). > > > > Sorry, aren't you saying the same thing in both cases? If not, can you > > rephrase > > or expand that? > This won't help when we have to schedule a binNMU on one or two architectures > and not all of them. That’s why I made the distinction. The change to the tool can be done by taking the highest version number across the _listed_ or _all_ architectures. (The listed ones is probably better.) On Fri, 23 Oct 2015, Adam D. Barratt wrote: > Well, except you only really want to do it for libraries that are ma:same, as > that's the only case where it actually matters and otherwise you're > pointlessly losing versions. Right, but it’s not as if losing versions would have any bad impact. > It's also not quite that simple, even working things out by hand - see #599128 > for example. Hm, I’m still under the impression that the +bN suffix to the Debian version of the package in the archive is the authoritative source for what binNMU version a package currently has, as that’s taking porter uploads into account which is a requirement. If the current code doesn’t do that I consider it a bug which must be fixed (at the same time, or before doing this change), which makes it more tricky, yes. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Re: binNMUs: please exercise some care
On Fri, 23 Oct 2015, Adam D. Barratt wrote: > and testing), so the only way to be certain what binNMU number to use is to > check manually. In practice what actually happens is that people forget about Maybe wb could do a “dak ls” and whatever the equivalent for dpo mini-dak is. I’ll have a look at the code, maybe on this weekend. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Re: binNMUs: please exercise some care
On 2015-10-23 13:28, Thorsten Glaser wrote:
[...]
On Fri, 23 Oct 2015, Adam D. Barratt wrote:
[...]
It's also not quite that simple, even working things out by hand - see
#599128
for example.
Hm, I’m still under the impression that the +bN suffix to the Debian
version of the package in the archive is the authoritative source for
what binNMU version a package currently has, as that’s taking porter
uploads into account which is a requirement. If the current code
doesn’t do that I consider it a bug which must be fixed (at the same
time, or before doing this change), which makes it more tricky, yes.
Specifically, wanna-build doesn't expose the binNMU version information
for suites other than unstable / experimental (actually, it might be
that it doesn't for suites that have an overlay - either way, it affects
{,old}stable and testing), so the only way to be certain what binNMU
number to use is to check manually. In practice what actually happens is
that people forget about the bug, schedule the binNMUs and then grumble
when either dak rejects the packages or something gets confused.
Regards,
Adam
Re: binNMUs: please exercise some care
+++ Emilio Pozuelo Monfort [2015-10-23 11:49 +0200]: > On 23/10/15 11:20, Thorsten Glaser wrote: > > How about, scheduling them all at once, but using the same version > > number across arches when doing it (i.e. the largest)? > > Again, that involves determining what that number is for each package... That is a single-page lookup, though, so only one lookup, not one for each arch e.g: https://buildd.debian.org/status/package.php?p=harfbuzz > Instead of all that manual work for every transition, you could ping > #758616 and try to get this solved at its root. It would clearly be better if we either did sourceful rebuilds or fixed the 'binNMU skew' problem. But we do need to do something reasonably soon otherwise it's not going to be ready for Stretch either. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: binNMUs: please exercise some care
On 23/10/15 11:20, Thorsten Glaser wrote: > On Fri, 23 Oct 2015, Emilio Pozuelo Monfort wrote: > >> I can go back to scheduling binNMUs for release architectures only, or for >> ANY >> -x32. But I don't have the time to look at every architecture and determine >> which one needs a binNMU and which one has already done it. Anyway if your > > OK. In this case, scheduling them is probably better. OK good to know. >> buildds are fast enough that they already rebuilt things, then maybe >> rebuilding >> them again is not such a big deal... > > This is probably true for x32, yes, but I was concerned about > M-A libraries not being coinstallable. For example, the harfbuzz > library currently has one +b more than all others, making trouble > for my desktop system (x32+i386 M-A). In that case, it wasn’t even > because the rebuild was done twice, but, because another rebuild > before the current (shared) one was necessary. > > How about, scheduling them all at once, but using the same version > number across arches when doing it (i.e. the largest)? Again, that involves determining what that number is for each package... Instead of all that manual work for every transition, you could ping #758616 and try to get this solved at its root. >> That wasn't me. But I'll try to spread the word about --extra-depends, as I >> agree it's useful to avoid this. I didn't use it much in the past when I just > > Okay, thanks a lot! Also, thanks for the response. Cheers, Emilio
Re: binNMUs: please exercise some care
On Fri, 23 Oct 2015, Adam D. Barratt wrote: > wanna-build does, yes, but at least the Release Team tend to use the "wb" > wrapper tool which automatically works out the next free number on each > architecture. Ah, cool – so we have only to patch this tool to automatically use the highest number per batch on all affected architectures (or even to use the highest number if all architectures would be touched, but that’s probably an unreasonable amount of code change). Where’s the source code to that tool? bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Re: binNMUs: please exercise some care
On Fri, 23 Oct 2015, Emilio Pozuelo Monfort wrote: > I can go back to scheduling binNMUs for release architectures only, or for ANY > -x32. But I don't have the time to look at every architecture and determine > which one needs a binNMU and which one has already done it. Anyway if your OK. In this case, scheduling them is probably better. > buildds are fast enough that they already rebuilt things, then maybe > rebuilding > them again is not such a big deal... This is probably true for x32, yes, but I was concerned about M-A libraries not being coinstallable. For example, the harfbuzz library currently has one +b more than all others, making trouble for my desktop system (x32+i386 M-A). In that case, it wasn’t even because the rebuild was done twice, but, because another rebuild before the current (shared) one was necessary. How about, scheduling them all at once, but using the same version number across arches when doing it (i.e. the largest)? > That wasn't me. But I'll try to spread the word about --extra-depends, as I > agree it's useful to avoid this. I didn't use it much in the past when I just Okay, thanks a lot! Also, thanks for the response. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Re: binNMUs: please exercise some care
On 23/10/15 12:23, Wookey wrote: > +++ Emilio Pozuelo Monfort [2015-10-23 11:49 +0200]: >> On 23/10/15 11:20, Thorsten Glaser wrote: > >>> How about, scheduling them all at once, but using the same version >>> number across arches when doing it (i.e. the largest)? >> >> Again, that involves determining what that number is for each package... > > That is a single-page lookup, though, so only one lookup, not one for > each arch e.g: https://buildd.debian.org/status/package.php?p=harfbuzz I didn't say once per arch. I said once per package, which is worse. I normally schedule binNMUs for several dozens packages. Multiply that by several transitions... Sorry but I'm not going to do that. >> Instead of all that manual work for every transition, you could ping >> #758616 and try to get this solved at its root. > > It would clearly be better if we either did sourceful rebuilds or > fixed the 'binNMU skew' problem. But we do need to do something > reasonably soon otherwise it's not going to be ready for Stretch > either. Ping the dpkg bug? :) Emilio
Re: binNMUs: please exercise some care
On 2015-10-23 12:02, Thorsten Glaser wrote: On Fri, 23 Oct 2015, Adam D. Barratt wrote: wanna-build does, yes, but at least the Release Team tend to use the "wb" wrapper tool which automatically works out the next free number on each architecture. Ah, cool – so we have only to patch this tool to automatically use the highest number per batch on all affected architectures (or even to use the highest number if all architectures would be touched, but that’s probably an unreasonable amount of code change). Well, except you only really want to do it for libraries that are ma:same, as that's the only case where it actually matters and otherwise you're pointlessly losing versions. It's also not quite that simple, even working things out by hand - see #599128 for example. Where’s the source code to that tool? http://anonscm.debian.org/cgit/debian-release/release-tools.git/ (in scripts/). Regards, Adam
Re: binNMUs: please exercise some care
[ Sorry for the cross-post, but I believe the people in -release and -wb-team should see this ] On 23/10/15 09:05, Thorsten Glaser wrote: > Hi, > > whoever is scheduling binNMUs now should do so with a little > bit more care, please. > > Case in point, frameworkintegration – x32 already was rebuilt > against the new Qt API and did not need the additional binNMU. That one was me. This is what I did: wb nmu fcitx-qt5 frameworkintegration gcin hime kwin libqtxdg lxqt-qtplugin qtcurve calibre . ANY . -m "Rebuild against qtbase-abi-5-5-1." --extra-depends "libqt5core5a (>= 5.5.1)" I can go back to scheduling binNMUs for release architectures only, or for ANY -x32. But I don't have the time to look at every architecture and determine which one needs a binNMU and which one has already done it. Anyway if your buildds are fast enough that they already rebuilt things, then maybe rebuilding them again is not such a big deal... Maybe when the transition tracker suggests commands to schedule binNMUs (something I want to implement) it can do so for affected architectures only. > Case in point, some OCaml binNMUs were done recently (within > the last month), to rebuild against the new compiler version, > but that version was not yet built on m68k. (You can set > extra Build-Depends and use that to version them, to make > sure that, while you have the comfort of scheduling them > all at once instead of in several batches, they only happen > after their prerequisite has been done.) That wasn't me. But I'll try to spread the word about --extra-depends, as I agree it's useful to avoid this. I didn't use it much in the past when I just used to wait for all architectures in wanna-build to build. But now that we got all the ports, it's a good way to schedule things just once without having to wait for every port. Cheers, Emilio
binNMUs: please exercise some care
Hi, whoever is scheduling binNMUs now should do so with a little bit more care, please. Case in point, frameworkintegration – x32 already was rebuilt against the new Qt API and did not need the additional binNMU. Case in point, some OCaml binNMUs were done recently (within the last month), to rebuild against the new compiler version, but that version was not yet built on m68k. (You can set extra Build-Depends and use that to version them, to make sure that, while you have the comfort of scheduling them all at once instead of in several batches, they only happen after their prerequisite has been done.) Unfortunately, I have no idea how to find out who was the person scheduling them, so this generic message will have to suffice. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
