Bug#918844: transition: gnustep-base, gnustep-gui
Control: tags -1 confirmed
On 09/01/2019 22:41, Yavor Doganov wrote:
> 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.
Go ahead with this. And yes, a combined list would be appreciated if the
rebuilds need to be done in order. If order doesn't matter and I can schedule
all the levels in one go, then I can combine them myself.
Cheers,
Emilio
Reply to: