Your message dated Tue, 18 Feb 2025 11:18:31 +0100
with message-id <e1fb6511-59e2-4841-ba83-4a10d6aa6...@debian.org>
and subject line Re: Bug#1093620: transition: gnustep-multiarch
has caused the Debian Bug report #1093620,
regarding transition: gnustep-multiarch
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 ow...@bugs.debian.org
immediately.)
--
1093620: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1093620
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
Tags: moreinfo
X-Debbugs-Cc: pkg-gnustep-maintain...@lists.alioth.debian.org
User: release.debian....@packages.debian.org
Usertags: transition
We at the GNUstep team would like to make the GNUstep libraries
multiarch-capable. It has not been done until now mostly because for
a long time I've been neglecting this due to my initially negative
attitude towards the MultiArch effort (I thought it was useful only
for proprietary software). Admitting my mistake, I should add that we
actually need this now in order to reproduce some arch-specific bugs
and to make the packages cross-buildable. Needless to say, MultiArch
is a nice feature to have both for developers and users.
To support GNUstep frameworks (shared libraries in disguise that are
installed in /usr/lib/GNUstep/Frameworks with symlinks in /usr/lib and
/usr/include) and also some proper libraries like gnustep-sqlclient
which install bundles (dynamically loadable modules) in
/usr/lib/GNUstep/Bundles, we need to move the whole GNUstep System
Library directory from /usr/lib/GNUstep to
/usr/lib/${DEB_HOST_MULTIARCH}/GNUstep.
Also, because at least gnustep-base and gnustep-corebase have
arch-specific headers, for consistency we'll install all headers in
/usr/include/${DEB_HOST_MULTIARCH}/GNUstep. (Not only for
consistency, GNUSTEP_SYSTEM_HEADERS must be defined to one directory
only so there's no other easy way.)
The new package gnustep-multiarch (M-A: same) from src:gnustep-make
will provide the symlinks from /usr/lib/${DEB_HOST_MULTIARCH}/GNUstep
to arch-indep directories in /usr/share.
The only packages which need non-trivial changes are gnustep-make and
gnustep-base (gnustep-make must pass through NEW for the new
gnustep-multiarch package, hence the moreinfo tag).
The following preparations and tests have been made so far:
1. I rebuilt the GNUstep world with multiarch-based gnustep-make and
gnustep-base, identifying packages which FTBFS (list below) and
fixing all of them in the process.
2. I installed the multiarch-based GNUstep core packages on an
unstable system and can confirm my initial suspicion: packages that
provide a single executable (these are most packages ending with
".app") will continue to work properly. Packages which have
bundles (gworkspace, gnumail, to name a few) will be broken until
they are rebuilt for the new layout.
3. I installed some more complex packages that I've rebuilt for the
new layout and can confirm they work.
4. I tried building GNUstep software as a mortal user and can confirm
that it works; the various GNUSTEP_ variables are properly expanded
and sourcing GNUstep.sh (required for building/using software in
the USER domain) also works.
5. I cross-built the GNUstep world on amd64 for armhf, discovering
11 FTCBFS bugs in the process (all fixed locally).
6. I tested the non-GNUstep packages that could be affected by this
change (openvpn-auth-ldap and meson) and they both build fine.
This is the list of packages which FTBFS with the new layout:
Level 1:
gnustep-base
Level 2:
dbuskit
gnustep-corebase
gnustep-gui
gnustep-netclasses
gnustep-performance
pantomime
rsskit
sbjson
sope
universal-detector
Level 3:
camera.app
cenon.app
charmap.app
gnustep-sqlclient
gomoku.app
gorm.app
grr.app
lynkeos.app
paje.app
sogo
systempreferences.app
unar
Level 4:
gnustep-dl2
gworkspace
Level 5:
addresses-for-gnustep
steptalk
Level 6:
adun.app
agenda.app
gnumail
Except for gnustep-base, fixes are trivial (like updating .install
files or replacing some hard-coded path in debian/rules).
I realize this is not the best moment for such a transition, but there
are a few reasons why we would like to carry it out during the trixie
development cycle:
* For some multi-binary packages, I made the grave mistake to put
the symlinks from /usr/lib/GNUstep to /usr/share/GNUstep in the
arch:all package. Lintian did not complain, and at that time I
thought it was a good thing for a symlink that is always going to
be the same across architectures to be put in the arch:all
package if the arch:any package depends on it. JFTR, other
maintainers did the same (e.g., sogo). With the new layout these
are lintian errors and of course it will make the packages
unusable on any other arch except amd64. Fixing these bugs
through this transition will allow us to do it without
Breaks+Replaces and it'll be guaranteed there will no problems
when upgrading.
* For forky we are planning a more complex transition that will
require sourceful uploads of every package and we don't want to
combine two major changes within one release. That could possibly
complicate issues when upgrading from forky to forky+1 and will be
more stressful for our users (and for us, but let's ignore that).
* Currently, we don't have a way to track universal-detector for
classic GNUstep library transitions and ensure it's always
binNMUed before unar. It'll be done now via a virtual package
that libgnustep-base-dev will provide. Sure, this can be done at
any time, but it would mean that we won't be able to track
universal-detector for this transition.
* Trixie will be a better release with this change. (That's not a
serious reason and looks like it's written by a PR agent. I just
thought that a bullet list with three items is too short so I made
it up.)
This is a non-blocking transition -- packages will be able to migrate
as soon as the core packages migrate. That's bad in our case because
neither you nor we want to disrupt testing. So I would suggest to put
an explicit block hint when the transition starts:
block gnustep-make
That'll be enough to keep the whole stack in unstable, I think. All
packages, when rebuilt, will gain a dependency on the virtual package
gnustep-layout-multiarch provided by gnustep-multiarch. There are
some packages which don't use dh_gnustep so won't have the dependency
(I exclude those which will require a sourceful upload and thus will
be fixed during the transition):
universal-detector
unar
These are fine to migrate as they have nothing to do with the GNUstep
layout.
batmon.app
fortunate.app
pikopixel.app
terminal.app
These will work if they migrate but for extra safety I think it's
better to upload them now with fixes to use dh_gnustep.
Here is a proposed plan of action:
1. You approve the transition for trixie.
2. We upload gnustep-make to experimental, and after it's ACCEPTed we
upload the core packages (-base, -gui, -back) to experimental so
that maintainers outside our team can reproduce the bugs and test
the proposed patches.
3. We file all FTBFS bugs with severity:important, tagged pending for
packages under our umbrella and patch for the others.
4. We remove the moreinfo tag.
5. We wait for your confirmed tag for the upload to unstable and then
we raise the severity of the FTBFS bugs.
6. We start with the sourceful uploads in the right order.
7. We coordinate with you which packages to binNMU and when, and when
to remove the block hint.
Here is a proposed ben file:
title = "gnustep-multiarch";
is_affected = .depends ~ /libgnustep-base1.30/ | .source ~ /universal-detector/;
is_good = .depends ~ /(gnustep-layout-multiarch|gnustep-base-abi-1.30)/ |
.static-built-using ~ /universal-detector (= 1.1-6)/;
is_bad = !.depends ~ /(gnustep-layout-multiarch|gnustep-base-abi-1.30)/ |
!.static-built-using ~ /universal-detector (= 1.1-6)/;
Thanks for reading so far.
--- End Message ---
--- Begin Message ---
On 18/02/2025 11:11, Yavor Doganov wrote:
Emilio Pozuelo Monfort wrote:
On 17/02/2025 09:30, Emilio Pozuelo Monfort wrote:
On 17/02/2025 00:33, Yavor Doganov wrote:
If you agree that there are no evident problems, please remove
the block hint and let's see what britney will do with it.
Removal hint dropped.
I checked some core packages (gnustep-base, gui) and they
migrated. Can you check if there's anything else to do here?
All packages migrated so we're done. Thanks!
Great! Let's close this then.
Cheers,
Emilio
--- End Message ---
