Bug#918844: transition: gnustep-base, gnustep-gui
Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: transition
On behalf of the GNUstep team I'd like to ask for your permission to
carry out a last gasp GNUstep transition (libgnustep-base1.25 -> 1.26
and libgnustep-gui0.26 -> 0.27).
I realize it is way too late in the release cycle and the transition
freeze is imminent. The poor timing is entirely my fault becuase
until last week upstream were unaware of the Debian buster release
schedule. I didn't inform them in advance as I thought there were not
that many changes to warrant new releases. It was poor judgement on
my part and I'll make sure to avoid it in the future. They've been
working hard in the past few days to get the relases out in time
specifically for buster.
The changes are really minimalistic compared to any of the previous
transitions. In fact gnustep-base/1.26 is ABI-compatible with 1.25 if
it is configured for the GCC/GNU runtime (as is for Debian). The
SONAME was bumped for consistency because the support for the new
libobjc2 ABI (a.k.a. the GNUstep runtime, not packaged for Debian)
breaks the gnustep-base ABI. The incompatible changes in gnustep-gui
affect only a few classes; the rest is minimal API additions and
bugfixes. So in theory, this should be the smoothest GNUstep
transtion ever. An argument in favor of this presumptuous statement
is that for the first time only one of the rdeps fails to build.
Here's a summary of the issues:
* gnustep-base/1.26 FTBFS on:
- armhf: That's a known issue (#918366), it will build on a native
armhf buildd. Arguably, we should fix this bug ASAP but AFAICS it
is not RC (yet) and will not impede the transition.
- ia64: Never built there since this architecture was resurrected.
I suspect it is due to libffi as its own testsuite is failing.
Things are looking better with libffi/3.3 so we'll see. Nothing to
do here as there are no GNUstep packages on ia64.
- powerpc/ppc64: This came out as a surprise but it looks like a
transient problem (#918781). I really hope it is. In the worst
case I can disable the failing tests temporarily.
- Not yet built on mips64el, mipsel and kfreebsd-*. I don't expect
problems there.
* Rdeps that FTBFS:
- sogo: #918795. I'm not marking it as blocking the transition
because sogo is not in testing due to #914524.
* Rdeps not tested:
- fortunate.app: unrelated FTBFS (#897623), not in testing.
- pantomime1.2: I plan to file a RM bug against ftp.d.o as soon as
lusernet.app is rebuilt for the pantomime transition (release.d.o
#916445).
The automatic trackers look OK to me. Should you ACK the transition
for buster, I would suggest to do binNMUs for both libraries at once,
to spare buildds' resources. Let me know if you need the combined
list of the rdeps in the right order. Note that lusernet.app is
likely to require extra-depends on libpantomime-dev (>= 1.3),
otherwise the wrong library is likely to be be picked because the
package still build-depends on libpantomime1.2-dev.
As always, gnustep-back should not be binNMUed, there will be a
sourceful upload.
Reply to: