Bug#918844: marked as done (transition: gnustep-base, gnustep-gui)
Your message dated Fri, 18 Jan 2019 10:12:04 +0100
with message-id <dda7704f-0221-3752-b487-07ef8f7cfbef@debian.org>
and subject line Re: Bug#918844: transition: gnustep-base, gnustep-gui
has caused the Debian Bug report #918844,
regarding transition: gnustep-base, gnustep-gui
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)
--
918844: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918844
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
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.
--- End Message ---
--- Begin Message ---
On 18/01/2019 09:25, Yavor Doganov wrote:
> Yavor Doganov wrote:
>> Emilio Pozuelo Monfort wrote:
>>> On 16/01/2019 09:31, Yavor Doganov wrote:
>>>> Are you going to force gnustep-base to testing or you want me to do
>>>> something else?
>>>
>>> I don't plan on forcing this.
>>
>> OK.
>
> It looks like Paul Gevers added a ci hint to install gnustep-performance
> from unstable so it passed and the GNUstep stack migrated. Thanks, Paul!
>
>>> I would rather this is solved one way or another, either via strict
>>> dependencies or by versioned breaks if possible.
>>
>> I'm going to upload gnustep-base/1.26.0-3 with strict dependencies as
>> there are other issues which makes this necessary; hopefully the
>> gnustep-sqlclient autopkgtest in testing will be skipped then.
>
> I still plan to do this (also for -gui), which would: 1) avoid manual
> hints in the future; 2) the order will be guaranteed so you can
> schedule all binNMUs for future transitions in one shot; 3) will
> prevent the sheer breakage which happens when two GNUstep core library
> versions are installed.
>
> Not sure if something else needs to be done or this bug can be closed?
The transition is finished, let's close this.
Emilio
--- End Message ---
Reply to: