Re: Releasability of the kFreeBSD ports
Hi,
Tuco wrote:
> I think as a desktop it's still inmature but as a server it's very
> usable and has wonderful capabilities in storage area thanks to ZFS
> (for example http://www.ypass.net/solaris/zfsbackup/).
Yeah, thanks to Tuco we made big advances with usable ZFS support
recently. Thanks! :-)
But I also have to agree that there are still many more or less small
but often very annoying issues, especially on the desktop, like:
* gdm[1] and kdm[2] not getting a working keyboard with default X
config, but restarting them later (e.g. via ssh or by calling the
XDMCP chooser) makes the keyboard work (Yet another nasty HAL issue?
Race condition somewhere?)
[1] http://bugs.debian.org/586539
[2] http://bugs.debian.org/586540
* konsole no more working with newer kfreebsd kernels:
http://lists.debian.org/debian-bsd/2010/08/msg00024.html and
http://bugs.debian.org/573063
* No bluetooth.
* ALSA: Many ALSA dependent packages not working/building/available.
(There is a limited emulation layer called SALSA, but either many
packages don't work with it or nobody tried to get them working with
it. Not sure how many unfixed bugs because of this are still open.)
* FUSE: fuse4bsd[3] hasn't been packaged yet, therefore most fuse based
packages are uninstallable. (For luck the upstream website
is back again, was replaced by some advertising portal or so for
some weeks.) Last commit[4] 17 months ago, last release June 2007.
[3] http://fuse4bsd.creo.hu/
[4] http://mercurial.creo.hu/repos/fuse4bsd-hg/
http://fuse4bsd.creo.hu/darcsweb/darcsweb.cgi?r=fuse4bsd
More on that in a seperate mail to debian-bsd@l.d.o.
Some smaller issues I noticed only happening on kfreebsd, but haven't
tracked them down (probably no bug report yet either, partially also
affects servers):
* Emacs 23 via remote X doesn't work. No idea why yet.
* aptitude segfaults approximately every second or third call. (That's
much better than months ago where I was used to start aptitude with
"until aptitude; do sleep 0.1; done")
* IPv6 support and some other stuff[4] in the /sbin/route wrapper is
missing. I do have that on my todo list, but not with top priority.
[4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567939
There are probably more of that kind, but those are the ones I
remember at the moment.
> > If it's not entirely up to our standards, would a separate suite, like it
> > has been done in the past for sarge-amd64 and etch-m68k, help having some
> > sort of release that can be updated independently from the main stable
> > release? Such a suite could also be useful to land larger changes than
> > normally allowed for stable.
Sounds like an fallback in case we don't get close to a releasable
state. At least I do have good memories(*) about using sarge-amd64, so
that's IMHO an option which should both, not affect the "normal"
release, but is still very close to the normal release. I.e. we do
have a more or less fixed state, so nobody who likes to try kfreebsd
does have to use rolling releases (i.e. testing/unstable). And being
close to the release even if not officially part of the release will
get us far more kfreebsd users than just kicking it out short before
the release.
(*) I'm writing this mail on a machine which started out as
sarge-amd64 and never needed a reinstallation since then, just
dist-upgrades as I'm used from Debian. :-)
> > Or do you think we should skip this release? (But keep it in testing, of
> > course.)
If we don't release it normal with Squeeze, I'd at least release it
like sarge-amd64, but definitely not do nothing (i.e. skip the
release).
Regards, Axel
--
,''`. | Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
`- | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
Reply to: