* Introduction
==============
Following a suggestion from Stephe, my first real mail to this list is a
summary of how well our Ada pacakges support all Debian architectures.
First, a little bit of history. In the old days of gnat 3.14p and gnat
3.15p, the compiler only supported i386, powerpc and sparc, so all Ada
packages had to include Architectures: lines listing those three
architectures. That was the case in Debian 3.0 "Woody" and 3.1 "Sarge".
The switch to GCC 4.1 in Debian 4.0 "Etch" allowed us to add support for
alpha, amd64, hppa, ia64, kfreebsd-i386 (with special patches to GCC,
subsequently merged upstream), mips, mipsel and s390.
The switch to GCC 4.3 in Debian 5.0 "Lenny" allowed us to add support
for ppc64.
Now in Debian 6.0 "Squeeze", GCC 4.4 introduces support for
kfreebsd-amd64 (which at the same time became an official Debian
architecture, along with kfreebsd-i386) and armel.
At the same time, changes to dpkg and dak (the Debian Archive Kit,
working in the background on the Debian archive servers) now make it
unnecessary to restrict the Architectures: line in debian/control. If a
package specifies "Architectures: any" but build-depends on packages
that are unavailable on some architecture, dak will not flag an error
anymore; instead, the build daemons ("buildds" in Debian parlance) for
the missing architectures will simply not try to build the package on
that architecture and the package will eventually migrate to testing.
So, all Ada packages should move to Architecture: any.
Except that a few architectures are problematic.
* Problematic architectures
===========================
** alpha
The first problematic architecture is alpha. GCC 4.4 on this
architecture has a code generation bug[1] whereby it enters an infinite
loop when parsing a project file (even an empty project file triggers
the bug). Since Debian relies on project files so much, I have decided
to drop support for alpha from all packages even though the compiler is
present on the architecture. In fact, it is likely that the rest of
Debian will also drop alpha in Squeeze for lack of interest and
serviceable hardware.
[1] http://gcc.gnu.org/PR42073
** mips
Another architecture-specific compiler bug [2] hurts approximately a
third of our packages. I'm almost certain this is a Debian-specific
(not upstream) bug. Unfortunately, nobody has had access to a mips
machine for investigation. Xavier[3] and Reto have made attempts at
investigating on qemu but this is really too slow. Bootstrapping the
compiler on real hardware is slow enough as it is (13 hours on the
latest buildd log); on qemu it is even worse. Therefore, we have
dropped support for mips on a subset of our packages.
[2] http://bugs.debian.org/566234
[3] http://lists.debian.org/debian-mips/2010/02/msg00048.html
** mipsel
mipsel is in much better shape than mips; the only problems are lack of
available buildd machines and that the buildd administrators insist that
all packages must build in 150 minutes or less; they have introduced a
daemon that kills any build in progress for more than that. This makes
it impossible to build gnat-gps, which takes 7 hours to build on such
hardware. I'm trying to get the buildd admins to rebuild gnat-gps
manually or remove the timeout. I have root access to a mipsel machine
on the GCC CompileFarm[4] where I built gnat-gps manually, but the
machine is down now and I really don't want to rebuild manually for
every upload. So I am considering dropping support for mipsel in
gnat-gps.
[4] http://gcc.gnu.org/wiki/CompileFarm
** armel
Matthias Klose has backported patches from GCC 4.5 into GCC 4.4 to
enable support for armel starting with gnat-4.4 (=4.4.3-1) and is the
driving force behind this whole effort. The goal is for Ubuntu 10.04 to
support armel; Matthias has filed "important" bugs against every Ada
package requesting support for armel and suggesting that the package
move to "Architecture: any". The problem is that, last time I looked,
the Debian buildds did not have gnat-4.4 installed and did not build the
Ada packages we threw at them[5,6]. Also, armel is a slow architecture.
Even though some processors run at a reasonable 1.2 GHz, the current
buildd machines all have only 512 MiB RAM and tend to run out of memory
during large builds[7], so may not be suitable for such large packages
as gnat-gps or polyorb.
[5] https://buildd.debian.org/pkg.cgi?pkg=liblog4ada
[6] https://buildd.debian.org/pkg.cgi?pkg=libxmlezout
[7] http://bugs.debian.org/564280
* What to do now
================
All Ada packages should move to "Architectures: any" but this is not
urgent.
If a package cannot support some architectures, this information should
be in the file Packages-arch-specific[8] which is part of the Debian
Archive Kit (dak) running on the Debian servers. You cannot change this
file directly; if you need changes, you must file a bug against the
pseudo-package "buildd.debian.org". I have taken care of most of the
problems in #569665[9] but, since then, topal has been hit by #566234 on
mips.
[8] https://buildd.debian.org/quinn-diff/Packages-arch-specific
[9] http://bugs.debian.org/569665
So, the only consequence of moving a package to "Architectures: any", in
practice, will be to add support for armel. The unavailability of armel
buildd machines means that such a change is not urgent, just nice.
Also, if we are going to re-upload packages, we must do so in reverse
dependency order so that requires some coordination.
All in all I am quite happy with the current state of Ada packages in
Debian. Most of them are already in testing. The few that are not are
simply too young; there is no major roadblock ahead.
* Appendix: how to remove support for an architecture
=====================================================
If you decide to remove support for some architecture by changing
Packages-arch-specific, be sure to also file an architecture-specific
RM: bug against ftp.debian.org[10] to remove the previous version of the
package from that architecture; see #570801[11] for an example.
Otherwise, the old version that is already in testing will prevent
migration of the new version.
[10] http://ftp-master.debian.org/removals.html
[11] http://bugs.debian.org/570801
--
Ludovic Brenta.
Attachment:
pgpll0zebfn0z.pgp
Description: PGP signature