[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: hurd-i386 qualification for Wheezy

(Ewww, long lines)

Please keep in mind I'm quite new in the release team, so I'll just
reply on some points that stroke me. I don't speak for the team as
a whole.

Samuel Thibault <sthibault@debian.org> (19/05/2012):
> - 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.

Starting a testing distribution for an arch less than a month before a
freeze doesn't smell too good to me.

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

Including big packages like say webkit or kde4libs or anything similar?

> 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).

I wouldn't be very happy to see unblock requests just to get hurd-i386
fixes in testing, if that's what you're suggesting. We already have
plenty of work to do without having to deal with that kind of requests.

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

Exactly the kind of situation that led my asking about removals of
problematic binaries above.

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

On a (very) personal note, the apparent lack of HW support is making it
look very bad…

> 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

From there, basic stuff like working local sockets and select() might be

“Get Xorg + gnome/kde/xfce (xfce should work, kde is missing working
dbus (due to local socket auth and bugs in select() cornercases)) + some
webbrowser working (iceweasel 9 works, though not https).”

Bottom line for me:
 - way too late in the release cycle to consider adding hurd-i386 to
   testing (even as a bad arch).
 - not happy with unblocking packages just to get hurd-i386 fixes in,
   already plenty of bugs to deal with on real architectures.


Attachment: signature.asc
Description: Digital signature

Reply to: