[Debian-med-packaging] Bug#561944: transition: gnustep-gui

[Yavor Doganov]

Package: release.debian.org
Severity: normal
User: release.debian.org at 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.