Differences between revisions 28 and 29
Revision 28 as of 2012-05-07 13:15:00
Size: 9548
Revision 29 as of 2022-12-10 02:04:39
Size: 9602
Editor: PaulWise
Comment: page content is release recertification not archive qualification
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
## page was renamed from ArchiveQualification/Wheezy




"The table"


FIXME: io.debian.net is not listed as kfreebsd-i386 porter box? Perhaps also note that asdfasdf/io are not DSA.

Decisions to be made

Could use a refresh on the status of each port; ideally from the porters themselves

Ben Hutchings wrote a great summary for the Linux arches at https://lists.debian.org/debian-release/2012/05/msg00154.html which is included below

Status of hurd

http://wiki.debian.org/Debian_GNU/Hurd#Goals_for_releasing_in_wheezy recently updated

See http://raphaelhertzog.com/2012/04/19/people-behind-debian-samuel-thibault-working-on-accessibility-and-the-hurd/

Imported packages from d-p.o.

  • "The Debian GNU/Hurd port can almost completely be installed from the official mirrors, using the standard Debian Installer."

Not sure if that means "we have imported packages" (which are not showing up on my radar) or if it is "just" an installer issue (which would be covered by the table). ~ Niels

They do: https://lists.debian.org/debian-hurd/2012/04/msg00110.html and ff. You need to check the build logs what they use for building packages. There is stuff in there thats only from d-p.o. ~ Joerg

Uninstallable count

From https://lists.debian.org/debian-release/2012/05/msg00079.html :

A few weeks ago I performed a few test britney runs, in order to try and answer the question "how much pain would trying to squeeze hurd in to testing be right now?". The end result of my test runs was an initial set of ~3800 hurd binaries in testing, of which around 150 were uninstallable. ~ Adam

I don't know when you did it precisely, but with libpulse being already fixed, and krb5 and libav being built, the figures would get better. ~ Samuel

Status of kfreebsd-{amd64,i386}

Since squeeze: kfreebsd-9 arrived, completed a (sort of unexpected) transition to new freebsd-libs, and new upstream kernel 8.3 just entered testing. Can now export (potentially ZFS-backed) iSCSI targets via new userland istgt package.

Building 89% of the archive, up from 85% at Squeeze release. Mainly lacking an openjdk, libv8, nodejs but progress has been made towards building these.

Some important fixes in eglibc recently should avoid races that were being seen on the buildd's, mostly in threaded python stuff.

Only one RC bug in kfreebsd-specific packages right now (kbdcontrol) :


I've been referring to this list to track bugs relevant to kfreebsd; at time of writing there are ~17 unpatched RC bugs filed as kfreebsd-* specific:


d-i hasn't been built recently due to (VM host) crash taking out two buildd's and this needs setting up again. Before that the daily images were quite usable (and improved since Squeeze). Now gives a choice of two stable kernel branches. Some issues installing to ZFS root are hopefully fixed by 8.3 kernel now in testing.

Status of armhf and s390x

  • Should we promote them to release architectures?
  • s390/s390x: Actively supported upstream by IBM. Only runs in virtual machines, so there is relatively little diversity of 'hardware' or need for hardware support. In Debian, the main kernel maintainer is Bastian Blank; Aurelien Jarno is also doing some work on it.
  • s390x experienced a big jump in % built packages recently (glib?)

See the nice list at ArmHardFloatTodo

  • armel/armhf: These have long been problematic due to the diversity of hardware platforms and 'siloed' development by platform vendors. However, vendor participation and coordination has improved greatly and there is also some hope of reducing the number of kernel flavours needed in future. A minor concern I have is that I find it hard to get bug fixes reviewed and applied upstream. In Debian, there are multiple kernel maintainers with ARM expertise, and I have no doubt about our ability to maintain these architectures. ~ Ben

Status of armel, mipsel

  • Any improvements since last time? (yellow entries)
  • Are these still "ok"?
  • see the above about ARM
  • mips/mipsel: This seems to be quite actively developed upstream, with contributions from multiple hardware vendors and others.

was some queue on mipsel buildd's recently... reason: temporary hardware failures, lost built packages because of hard disk brokeness, queue mostly "never compiled" ~ Andi

EDOS was showing a lot of packages uninstallable but this is much better now that new webkit got built. That's good because the old version seemed kinda buggy on this arch and that restricted web browser options. Personally I'm impressed by mipsel Wheezy running on Lemote Yeeloong for some months; just a couple of things to fix in Xorg and then I could say that 'out-of-the-box' it all just works. ~ Steven

Status of ia64

  • So far as I can tell, there is no longer any commercial support for Linux on Itanium aside from existing contracts. The upstream maintainer (Tony Luck) does not seem to be able to spend much time on it, and contributions from other developers are mostly just adjustments for kernel-internal API changes (which often result in regressions). For example, a system call added in Linux 2.6.27 and now required by udev was not 'wired up' for ia64 until Linux 3.3 (over 3 years later). This is also one of two architectures where we still have to enable an old-style IDE driver as there is no replacement using libata. (The other is m68k.) Dann Frazier is still listed as the Debian kernel maintainer for ia64, but I'm not sure that he's still able to do this. If not, I don't believe this port should be included in wheezy. ~ Ben

Status of sparc

  • This is actively maintained upstream by David Miller, but quite reasonably this seems to be a lower priority for him than networking. So far as I know, no hardware vendor supports Linux on SPARC. In Debian, the kernel maintainer is Jurij Smakov, though I don't think he has a lot of time for it. ~ Ben

Status of powerpc

  • This is quite well supported upstream. For the platforms we support, upstream development is dominated by IBM which is primarily concerned with 64-bit systems. One change made it into the 2.6.32.y-longterm branch without anyone ever testing a 32-bit configuration (where it failed to build). There is no Debian kernel maintainer for powerpc. I also see a problem of hardware availability for prospective maintainers (no new PowerPC Macs since 2006; PS3 'OtherOS' support removed in 2010). I am unsure whether this port should be included in wheezy. ~ Ben

Debian have access to at least one Power7 machine located at OSUOSL. The machine list shows three LPAR running on it. ~ Bastian

Status of amd64, i386, mips

  • Should be "all ok".
  • Our MIPS kernel images currently have more code built-in and less support for different boot configurations than most other architectures. I believe Aurelien has been working to resolve this, however. ~ Ben
  • amd64/i386: If we can't support these then we should give up on the release altogether. :-)


Other considerations

Borrowed from Niels, originally at https://lists.debian.org/debian-release/2012/04/msg00304.html

  • No imported packages (from -ports).
    • s390x still have libproxy (according to projectb). I am told they are working on it and presumbly this will be fixed before long.
    • hurd-i386 may have an issue here (see above)

  • Amount of RC bugs introduced by promoting an arch to release candidate.
    • We got too many RC bugs already now.
    • For s390x and armhf we can probably get a reasonable estimate by comparing their bug list with s390 and armel (respectively) plus looking at the build state stats for these architectures[5].
    • I got less ideas for hurd-i386 where there are no "comparison" arch.

Personally, I could probably also use a refresh on the status of some of our architectures. Presumably, I/we could ask the porters for an update, but I have to admit - I am not really sure what to ask for and what to expect from them.

[4] By "bug list" I mean the usertagged bugs for armhf and s390x. e.g.


Take all non-RC bugs on that list, and if its not on


then it will "possibly" be a new RC bug.

[5] Something like querying the buildd data base for "FTBFS" on armhf that are in a "good" state for armel. This is a possibly unfiled FTBFS bug.

Currently looks like non-RC bug counts of ~16 for s390x (plus 30 more marked as RC already) vs. 1 for s390; 10 for armhf vs. 2 for armel; probably more FTBFS bugs are filed but not usertagged yet.

About 39 bugs currently usertagged for Hurd without patch; Perl accounts for 7 of these.