"The table"

FIXME: 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 which is included below

Status of hurd recently updated


Imported packages from d-p.o.

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: 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 :

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

See the nice list at ArmHardFloatTodo

Status of armel, mipsel

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

Status of sparc

Status of powerpc

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


Other considerations

Borrowed from Niels, originally at

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.;tag=s390x

Take all non-RC bugs on that list, and if its not on;tag=s390

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.