--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: transition: gnustep-gui
- From: Yavor Doganov <yavor@gnu.org>
- Date: Mon, 21 Dec 2009 14:59:53 +0200
- Message-id: <20091221125953.7382.2795.reportbug@keel.southway-varna.com>
Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: transition
Please give the green light for a libgnustep-gui0.16->0.17 transition.
This is going to be harder than last time -- more packages are
affected by the incompatible changes, and unfortunately we're lacking
sponsors these days. There are also two toolchain problems that
almost certainly will have a bad impact.
Packages going away:
libgnustep-gui0.16
libgnustep-gui0.16-dbg
gnustep-back0.16
gnustep-back0.16-art
gnustep-back0.16-cairo
(Replaced with 0.17 accordingly.)
Expected problems:
* This transition is combined with the removal of the defoma
dependency in gnustep-back, so there might be regressions we don't
know about yet.
* adun.app reliably fails to build on mipsen, which looks like is due
to a regression in binutils (#519006). It's very likely that some
other packages will choke here too.
* gobjc-4.4 regression on armel: #550049
I haven't seen such failures on the buildds yet, probably because
there were no uploads of GNUstep packages since GCC 4.4 became the
default compiler. This will surely affect a bunch of apps.
* The problems that the release team had in the past with GNUstep
transitions and involved Objective-C libraries/frameworks (see
subthread [1] if you forgot about this issue) are addressed, pending
sponsorship of the fixed packages [2].
[1] http://lists.debian.org/debian-release/2009/03/msg00110.html
[2] http://lists.debian.org/debian-mentors/2009/12/msg00237.html
* Packages which FTBFS with the new gnustep-gui or for other reasons:
- adun.app: #560514
Fix committed in debian-med SVN; can be uploaded any time as the
issue is not related to -gui (Andreas/Charles, could you please
take care about this at your earliest convenience? TIA!).
- cynthiune.app: #476381
FTBFS due to the libmpcdec6 transition, fixed long time ago.
Waiting to be sponsored, can be uploaded at any time.
- etoile: GSTheme/NSToolbar/NSScrollView incompatible changes
Fixed upstream, I'll cherry-pick the patches and upload when the
time comes.
- gnustep-dl2: #559884
gnustep-base problem, patch available, can be uploaded any time.
(I think Federico is working on it, right?)
- gnustep-examples: NSToolbar/NSToolbarItem incompatible changes
Fixed in my Arch repo, will upload to sid when 0.17 is there.
- gorm.app: #552913
Fixed in 1.2.10, waiting to be sponsored. This bug is not related
to the transition, but 1.2.8 also fails to build with
gnustep-gui/0.17.1-1.
GNUstep people: Please test the defoma-free gnustep-back from
experimental. You might want to try both with your usual settings and
temporary moving ~/GNUstep/Defaults/.GNUstepDefaults away. Everything
should work smoothly; everything that fails because of the migration
is most likely a bug we have to fix, and I personally prefer to hold
the transition while everything is ironed out in experimental.
Known problems:
1) The defoma-generated stuff at /var/lib/defoma is not actually
removed on upgrades (fixed in my tree already, will be included in
the upload to unstable).
2) I see no way to triggerize the regeneration of the .plist files
when a new font is installed/removed, because we ultimately rely on
fc-list and the fontconfig cache is refreshed by fontconfig's
trigger. TTBOMK there is no way to handle dependencies between
triggers. (At least this is not a regression from the defoma
implementation, just annoying and inefficient way to manage the
system fonts available for the art GNUstep backend.)
Thanks.
--- End Message ---