Control: tags -1 confirmed On 09/01/2019 22:41, Yavor Doganov wrote: > Package: release.debian.org > Severity: normal > User: [email protected] > 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
