Re: Releasability of the kFreeBSD ports
the Release Team is currently wondering if it makes sense to release with
kFreeBSD as a regular stable architecture with squeeze. It might be that
it is not yet up to the standards of a regular Debian release as it might
not contain everything that's expected by users.
So, what do you think is still missing? What would we need to communicate
as a disclaimer to the users if releasing kFreeBSD in this state?
Call it "technology preview" ?
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.
Or do you think we should skip this release? (But keep it in testing, of
Please do not skip squeeze release.
The GNU/kFreeBSD architectures cover majority of packages,
see  for missing packages ordered by popcon count.
From TOP 500, most packages have their counter part
already available, like
net-tools -> freebsd-net-tools
module-init-tools -> kldutils
linux-2.6 -> kfreebsd-8
strace -> ktrace in freebsd-utils
iptables -> pfctl in freebsd-net-tools
grub -> grub2
The uninstallable packages in testing are currently
related mainly to fuse/iptables/udev.
Update of :
* decide version of kernel and related utilities.
8.1 have been released in July 2010, currently in sid
Also zfsutils have been packaged.
* port of Debian Installer for GNU/kFreeBSD
it is being built daily with local udebs, based on 7.2 kernel,
switch to 8.1 kernel is being prepared
* gnat availability on kfreebsd-amd64
* ghc6 availability on kfreebsd-amd64
* openjdk on both kfreebsd-i386/kfreebsd-amd64
man-power is missing, we use gcj similarly as hppa
* cleanup after eglibc 2.10 upload (drop of libfreebsd)
* specific FTBFS on GNU/kFreeBSD, many with patches in BTS, see 
continuously updated ...
* infrastructure (DSAed build daemons, DSAed porter machines)
state not known to me
* general usability of the port
continuously tested ;-)
The implementation of #555527 (support [only out-of-date] on buildd status
pages) would be very helpfull for prioritizing porters work.