Hi Wookey, On Fri, Mar 17, 2017 at 10:44:00PM +0000, Wookey wrote: > Bin-NMUs break multiarch co-installability, so we always end up with a > somewhat random set of packages+architectures in a release which would > be co-installable, except that some arches got binNMUed so they aren't. > > I would like to discuss with the release team what we can do to > minimise this breakage, and when to do it. > > To clarify the issue, for anyone unfamiliar:
[...] > So at least for Stretch, and probably for the foreseeable, either the > versions match exactly or things are not co-installable. > > There isn't much point doing MA 'unskewing' builds, if there is going > to be another upload of a package anyway, or further binNMUs, so it's > best if any unskewing is done as late as possible before release. > > Ideally, just before release, we would go and just rebuild every > package that emits an MA:same binary package and has a binNMU for some > arch or other. That would eliminate the issue completely, but it's > probably also quite a lot of building and delay. What does the release > team think of this idea? Is there a good time to do such a thing? I don't think waiting to 'just before the release' is a good idea. The issue can be fixed (by scheduling binNMU's) as soon as it is noticed. [...] > Josch produced a chart of the current set of multiarch-skewed MA:same > packages: > https://mister-muffin.de/p/Rfbk.html > > So that's 130 packages right now, but only a fairly small number of > those are really important for co-installability. I created a page that gets info from udd (which shouldn't be more than an hour behind dinstall): https://udd.debian.org/~ivodd/cgi-bin/multiarch-same.cgi This page is very basic, and is currently not at a permanent url, but it shows the current situation in the archive. > It seems that after ivodd did a lot of rebuilding for pie fixes, most > of the packages that really matter got fixed, but it would be good to > do at least some of that list, and most importantly, check that the > situation doesn't get significantly worse before release with any > vital low-level packages being affected. I made sure that all the pie rebuilds for ma-same packages were done with the same binnmu number on all architectures, so it's no coincidence that the issue got better for those. > So, I'd be very pleased to get some advice from the RT on how best to > deal with this, without getting in their way, but maximising the > co-installability of what ends up getting released, and if there is a > good time to do some unskewing? I scheduled binNMU's for most of the packages listed on the page above (they show 'recent change in wanna-build'). They should disappear from the list as soon as the binNMU's are in testing. Some of the packages on the list have FTBFS bugs, or are waiting for other uploads. I didn't schedule those. If there are other packages that need a binNMU, let me know. > If that table of skew is useful we can arrange for it to be > automatically generated at a permanent URL. Cheers, Ivo