On 16/01/2019 09:31, Yavor Doganov wrote: > On Sat, 12 Jan 2019 01:24:54 +0200, > Yavor Doganov wrote: >> Emilio Pozuelo Monfort wrote: >>> And yes, a combined list would be appreciated if the rebuilds need >>> to be done in order. >> >> In previous transitions, the order was guaranteed because rdeps higher >> up the stack were in state BD-Uninstallable until the library packages >> they depend upon were rebuilt and installed. But in this cycle we >> have relaxed the dependencies between the -base/-gui binary packages >> to allow co-installation of different library versions, thus >> supporting partial upgrades. > > I would appreciate the release team's opinion regarding this > experiment; I think it failed not only because of the regressions [1] > when both library versions are installed but because testing migration > is now blocked by regression in gnustep-sqlclient's autopkgtests. > > [1] > https://alioth-lists.debian.net/pipermail/pkg-gnustep-maintainers/2019-January/004782.html > > Should we switch back to tight dependencies, thus allowing only one > gnustep-{base,gui} version to be installed? I believe that's also the > reason for the gnustep-sqlclient's autopkgtest failure in testing as > libperformance0.5 (from src:gnustep-performance) linked against > gnustep-base/1.25 is installed during the test. If the dependencies > were tight the test would be skipped in testing. > > Are you going to force gnustep-base to testing or you want me to do > something else?
I don't plan on forcing this. I would rather this is solved one way or another, either via strict dependencies or by versioned breaks if possible. I leave that up to you. >> What's important is that any package in this category which compiles >> and runs tests at build time will FTBFS because the tests will abort. >> This is precisely what happened to me with sogo when I tested it for >> this transition; see #918795 for explanation (I closed the bug as it >> turned out that sogo builds fine). TTBOMK, gnustep-sqlclient and sogo >> are the only rdeps that have tests, > > Same problem here; gnustep-sqlclient and sogo failed to build on > kfreebsd-amd64 as the builds were attempted with non-binNMUed > gnustep-performance and sope/sbjson. > > Other problems so far: > > * lusernet.app was built against libpantomime1.2 on all release > architectures + hurd-i386. Builds for debian-ports are fine AFAICS. > Would you schedule another round with the appropriate extra-depends > or you want me to make a sourceful upload? Scheduled. > * All binNMUs on kfreebsd-i386 were in vain because gnustep-base is > not installed there yet and gnustep-gui is not even built. Sorry but this is a problem of kbsd as packages there don't get installed for days. It should move to -ports to get autosigning or find another solution for this problem. > * There are some installability issues on kfreebsd-* due to libheif > not being rebuilt for the last x265 transition. Should I ask on > -bsd/-wb-team for help here? I probably skipped those there because it wasn't built (or probably installed) by the time I scheduled the binNMUs. I have scheduled them now. Emilio
