Re: hurd-i386 qualification for Wheezy
Hello,
Cyril Brulebois, le Sat 19 May 2012 19:41:56 +0200, a écrit :
> (Ewww, long lines)
Oops, sorry, I forgot to reindent after import from the pad.
> 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.
Well, doing it before might have meant more work for everybody.
> > - 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?
I guess we have to say yes.
> > 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.
Even when they are just e.g. #include or configure.ac cases?
> > 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.
Well, the problem is that as long as hurd-i386 port is not released in
any sort, people care less about it. A patch was submitted to the webkit
package quite soon actually, but it wasn't applied just because it was
out of the maintainer's radar, and he didn't notice it, while the exact
same patch, submitted to fix kfreebsd, was quickly applied, since its
severity was "serious".
> > 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…
Which lack, more precisely?
> > 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
> missing…
See more precisely below: local socket *auth*, and bug in select() in
*cornercases*. These are really corner cases, which have gotten apparent
only recently, and don't pose problem for the vast majority of packages.
> “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).
Well, I wonder when it would have been preferrable. Before now we didn't
have pulseaudio fixed, which was making a lot of packages uninstallable.
Chicken and egg...
> - not happy with unblocking packages just to get hurd-i386 fixes in,
> already plenty of bugs to deal with on real architectures.
Mmm, I thought the first part of the freeze was just not allowing new
upstream versions or such, but would still permit fixes. I guess I'm
too new to the release process to know. If not, well, then we have a
figure already: 76% should be what we have now.
Samuel
Reply to: