On Mon, Apr 19, 2021 at 06:28:05PM +0200, Julian Andres Klode wrote: > On Mon, Apr 19, 2021 at 06:08:23PM +0200, Julien Cristau wrote: > > On Mon, Apr 19, 2021 at 06:01:18PM +0200, Julian Andres Klode wrote: > > > I see. Nobody pinged me since then, but it is indeed fixed in the > > > 1.8.5 stable update that at least one release team member was > > > not exited about. > > > > > > https://salsa.debian.org/apt-team/apt/-/compare/1.8.2.2...1.8.5 > > > > > > So it's up to the release team if they want 1.8.5 or whether we'll have > > > to cherry-pick a subset of it into a 1.8.2.3. I think my opinion on that > > > is clear - I don't want to maintain a 1.8.2.z branch, it's more work > > > compared > > > to just following the normal stable apt updates, and there's a lot less > > > testing going on. > > > > > Please upload just that fix to buster; I don't care too much about the > > version number you pick. > > Is there a buster point release before bullseye release, or should that > be in buster-updates? > I don't know. It needs to make its way to spu soon either way.
> Given that buster is going to security support only soon anyway, I don't > mind where I apply security updates to that much :D > > > But I really do want to cherry-pick at least two other code fixes, and one > test > suite fix: > Can we defer these until after the AllowReleaseInfoChange change is out, please? Thanks, Julien > * > https://salsa.debian.org/apt-team/apt/-/commit/cfee71c6f2d1478ce4d4ed74ef690ae1350ea403 > > https://salsa.debian.org/apt-team/apt/-/commit/75f452c7309d66548c86a6526cbd65fc51a70039 > > (really just one change, but it was split over two releases, first > turned error to warning, next one ignores it completely; because it > was in 2 releases in main so I kept it separate :D) > > too, they'll make immediate configuration errors non-fatal. Currently > they are fatal in the sense that they are ignored and the upgrade runs > and then it just exits with 1 at the end. So it does not change the > outcome, it just makes the error reporting less silly. > > It is very likely that some upgrades on multi-arch systems fail erronously > without them. To be fair, the multi-arch aspect is also fixed by > > https://salsa.debian.org/apt-team/apt/-/commit/7f65fa3843abc476cbba65c808abc5dd77835815 > but that changes ordering results, and is not strictly necessary. > > * And I want > > https://salsa.debian.org/apt-team/apt/-/commit/cfc6870e9b8ad119219ce5dc1871531006bb2d71 > > to avoid people getting packages removed that stuff still depends on > because their prerm script failed. This might happen during an upgrade > to bullseye, and it's very very likely APT will not be able to recover from > it > - I've never successfully recovered a distribution upgrade that had a > failure in the > middle (and fwiw, all of them had, but they were my faults, really). > > * Also the testsuite-only change in > > https://salsa.debian.org/apt-team/apt/-/commit/730c5c861c32c9385dc862af8673984b12902343 > which makes things work reliably on debci armhf (no regression > potential, wheee) > > -- > debian developer - deb.li/jak | jak-linux.org - free software dev > ubuntu core developer i speak de, en >
