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...
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87lj8hx8d7.gnus_not_unix!%ya...@gnu.org
