Package: release.debian.org Severity: normal User: release.debian....@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.
