Re: hurd-i386 qualification for Wheezy
Hello,
Adam D. Barratt, le Wed 16 May 2012 13:19:46 +0100, a écrit :
> Comments on / additions and corrections to the content of
> http://release.debian.org/wheezy/arch_qualify.html would be appreciated,
> as would any other information you think is relevant to helping us
> determine hurd-i386's status for the release.
First, a quick summary of points that we believe are important:
- We of course aim at tech preview for wheezy only, not a full release. Our goal is to establish a testing distribution for wheezy which does not block others ports (i.e. so-called fuckedarch), and get a full testing for wheezy+1.
- We are rebuiding the archive without debian-ports, it should be over before the end of May. debian-ports now only contains packages helpful for users; it is no longer used by the buildds since the archive rebuild started.
- The archive coverage has passed 75%, and we believe it is fairly good already for a non-Linux non-BSD architecture, i.e. which was almost not exposed to upstream at all. Our long-term goal is of course to continue to port further packages, and the general trend as seen on https://buildd.debian.org/stats/graph.png is positive.
- The buildds are keeping up fine nowadays, so the 96% uptodate figure should improve once the current issues are resolved.
- It is fine to us to see problematic binary builds (e.g. blocking testing migrations eventually) be removed, even if they have a couple of rev-deps.
Some questions/open issues for the release team:
- About entering testing: apart for the archive rebuild, is there any remaining requirement or improvement from our side to fulfill still, or is it just for the release team to decide?
- How are discussions about the concerns-* fields coordinated? Is the release team going to inquire those, or should we?
- About buildd-fast-sec, we do have some fast buildd, it is a matter of enabling a security chroot after a testing distribution is introduced.
- About buildd-dsa, we are fine with a DSA'd buildd, if DSA is happy to maintain it, they will however probably have to learn a few Hurd things? We don't know to what extend DSA have to tinker with the machine, but we would be happy to help.
Now some more verbosity:
Concerning portbox, it should probably be rather pointed at exodar, strauss is running on quite old and slow hardware.
Concerning the installer, there is just one bug left during template loading that we need to find a proper fix for (our current images use a workaround).
Concerning the archive coverage, the 76% figure should be accurate for the current state. The freeze period should allow us to continue increasing it more easily (no new upstream releases). If you look at the current buildd figures, we are rather at 75%, this is due to current transitions, the gcc-4.7 FTBFSes, and webkit FTBFS (about to be fixed).
Concerning buildds, we have set up a 4th one in a third place, improving redundancy.
Concerning installability, it currently can not really be measured because the latest upstream webkit release is once more broken for some trivial reasons, #669059, making a big part of gnome uninstallable. The haskell transition doesn't help either :)
Concerning buildd-fast-sec and buildd-dsa, we simply haven't taken time to set them up, essentially to spend it on other tasks. We welcome advise on when would be preferrable to spent time on it.
Concerning hardware support, Linux 2.6.32 network drivers are now included and will be used by default in the coming days. That provides a fairly good coverage of not too-new hardware. We are working on integrating the linux AHCI driver to support SATA HDDs. Concerning X.org, drivers which do not require drm should be working. At worse, the vesa driver should work. There is no USB support, no sound support.
Concerning the debian-ports packages, it is probably good to provide more details. The status is tracked on our wiki page:
http://wiki.debian.org/Debian_GNU/Hurd
The packages that had been there and are now gone have simply been merged in main, except in one case, gcc-4.6 and binutils, described a couple of paragraphs below.
The remaining packages are either
- new Hurd-specific packages (marked hurd-any).
- patched packages which are now waiting for an upload to main. Some of them have actually already been merged upstream.
We were building packages with debian-ports essentially because patches for non-released non-Linux architectures take time to be accepted, and in a few important cases stalled progress because there is always something broken, even if only in a trivial way, particularly for a non-Linux and non-*BSD arch. With the recent fix of pulseaudio (at last!), we have started on 30th April to rebuild the whole archive without debian-ports for good measure. It is currently at 5500 over 7300 packages, with k* and g* behind, so we expect it to complete before the end of May.
The exception to patches being merged to main is about an issue with the famous no-add-needed option, which lead to bug #629866 that was posing problems on hurd-i386 in a lot of c++ code. The patch has been to disable the now-systematic no-add-needed in the meanwhile, to be able to make progress. Last month, we circumvented the issue by building our libpthread as part of the eglibc build, just like it is done on GNU/Linux with NPTL. This was however not enough just because of some part of binutils which was not enabled for hurd-i386, #671804, NMUed in DELAYED/5, in order to be able to build the packages where that poses problem (estimated to about 200 packages).
Please ask for details on any remaining concerns.
Debian GNU/Hurd porters
Reply to: