Bug#918844: transition: gnustep-base, gnustep-gui
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
Reply to: