[Debian GNUstep maintainers] Bug#561944: GNUstep transition

[Yavor Doganov]

close 568307 0.17.1-1
close 585531 0.17.1-1
close 558993 0.17.1-1
thanks

Neil McGovern wrote:
> I note that there are 4 bugs left that aren't fixed yet (one pending),
> do you know when these are likely to be ready to transition?

#58198{5,6,7} are trivial and can be uploaded right away.  If the
maintainer doesn't react in time, I can NMU them when the transition
begins (at which point they'll be RC bugs, eligible for NMU).  Gürkan,
are you there?

The cure for #581940 (gorm.app) depends on -base/-gui from
experimental.  The specific fix can be backported easily if a new
upstream gorm.app release is not acceptable at this point.  Gürkan is
the de-facto maintainer, so he can tell more about the plan for this
bug.

The fix for #581934 (gnustep-dl2) depends on -base/-gui versions from
experimental, plus a fixed gorm.app.  I don't know how the maintainer
is planning to deal with it, I hope he's waiting for a fixed gorm.app
+ Debian-specific soname because of the ABI break.  Federico?  (I
withdraw part of what I said in the bug log: a snapshot of upstream's
repository ought to be out of question now, given that in the past few
months it has been rewritten from scratch...)

In any case, gorm.app and gnustep-dl2 are one of the few packages that
will definitely require sourceful uploads.

> 568307 [           ] Generates incomplete nfont bundles which makes the art backend unusable

Fixed in experimental by providing a defoma-free art backend.
GNUstep-specific .nfont bundles are generated via fc-cache now.

> 585531 [           ] [Debian GNUstep maintainers] TimeMon Preferences window's weird	behavior

A fairly old bug in the cairo backend, fixed in 0.17/0.18.  Combined
with the bug above (affecting only art), it makes GNUstep unusable in
squeeze/sid right now.  Fixed in experimental.

> 558993 [           ] Subject: FTBFS: NSWindow.m:198: fatal error: method definition not in  @implementation context

An embarassing bug that could be prevented if the upload of
gnustep-base/1.19.3 didn't happen.  But the damage has been done, and
various upstream authors have been quite disturbed (e.g., latest
Ubuntu stable release shipping a non-releasable core GNUstep libraries
combination).  Nothing to do here except move forward or backward.

FWIW, technically speaking we can release without a transition, by
"just" uploading gnustep-base/1.19.1 with an epoch (however, this will
still require binNMUs of all packages that were uploaded since then
because of the NS{U}Integer/CGFloat types which break the ABI, at
least on 64-bit archs).

But if we go that route, there are quite some important bugfixes that
we'll have to backport (including security -- the not-so-recent CVEs
about gdomap vulnerabilities), and I'm not sure we'll succeed...
Needless to say, we'll be completely alone in maintaining those
modified versions throughout the squeeze lifetime; upstream doesn't
give a damn about 1.19.x/0.17.x...