Re: BSD port plans for the squeeze cycle
On Wed, Aug 19, 2009 at 10:56:33AM +0200, Petr Salinger wrote:
> Hi,
Hi,
> especially Aurelien and Cyril ;-)
>
> IMHO, we should discuss it here and to -release sent only result.
That was on my TODO list for a few days, but you have been faster ;)
>> As announced on dda [RT1], we want to get an impression when releasing
>> Squeeze is feasible. We have proposed a (quite ambitious) freeze in December
>> 2009, and some developers have noted that their planned changes wouldn't be
>> possible in this time frame. So, to find out when releasing would work for
>> most people, it would be great if you could answer the following questions:
>>
>> Do you have any big changes planned? How much time would they take, and
>> what consequences are there for the rest of the project?
>>
>> How many "big" transitions will the upcoming changes cause? When should those
>> happen? Can we do something to make them easier?
>
>
> * decide version of kernel and related utilities.
> It mainly depends on freeze time. Currently we use 7.2. The 8.0 should
> appear soon, but dot-zero is dot-zero ;-) May be 7.3 would be released
> before freeze.
I think we should definitely offer and support kernel 8.0. However, I am
not sure if it should be the default. I agree that 8.1 would be a lot
better, not sure when it is planned.
> * get rid of libfreebsd
> It waits for eglibc 2.10 upload, only 2 or 3 packages which b-d on
> libfreebsd-dev are not maintained by kfreebsd porters. Some binNMUs
> will be also needed.
That should be really easy to do once eglibc 2.10 is in unstable. I
don't think it will be a problem for the release.
> * gnat availability on kfreebsd-amd64
> gnat have been recently ported/bootstrapped on kfreebsd-amd64,
> this fact should propagate into debian/control files of ada related
> source packages.
I have already asked for Package-arch-specific changes. Maybe we should
already fill bug for those ones?
> * ghc6 availability on kfreebsd-amd64
> ghc6 is not yet available on kfreebsd-amd64, it have to be
> ported/bootstrapped. The 6.10 series does not support bootstrapping
> at all, the 6.12 should be much better, it should also eliminate
> the need of MAP_32BIT flag of mmap(), which is not available under
> FreeBSD kernel. When ghc6 6.12 become available, there will be need
> to change debian/control files of ghc6 related source packages.
Yes, that's something we definitely need for the release.
> * FTBFS on GNU/kFreeBSD with patches in BTS
As GNU/kFreeBSD is a release goal, it is now possible to NMU those
packages without any problem providing we respect the procedure
(actually we already started). The main problem given the number of
affected packages is probably the available manpower to do NMU.
> * entries in Packages-arch-specific
It is very easy to get that changed now. Either fill a bug against
buildd.debian.org, or publish your git tree and ask for a merge.
We already added a few packages there recently, maybe you have a more
detailed list already?
> * port of Debian Installer for GNU/kFreeBSD
>
That is currently on good track, at least for a basic version without
all the options enabled (gtk mode, UTF-8 console, ...).
Currently the kfreebsd branch is being merged into trunk. The remaining
problems that needs a lot of manpower are probably:
- porting network related applets of busybox (currently we are using a
mix of freebsd-utils and change in netcfg, that's not suitable for
official release).
- merging busybox patches upstream
- provide a way to configure the keyboard (related to the console-setup
entry below.
> What else ?
The release team will judge if this port can be released based on:
- percentage of packages built
- presence of an installer
- infrastructure (DSAed build daemons, DSAed porter machines)
- general usability of the port
For the two first entries, we are already working on that, we should
just hope having enough time to do that before the release;
For the infrastructure point, I have already interacted with the DSA
team and provided them an installation media, I should probably ping
them.
For the general usability of the port I would propose to make sure of a
few points:
- That Xorg works correctly on standard hardware. This is not the case
currently as there is a problem with keyboard (already addressed) and
mouse (still problematic, see the thread on the mailing list).
- Standard desktop environment are installable and work. Gnome and KDE
comes to mind, but we should probably check a few more
- Standard server packages (web, ftp, dns, mail) works.
If we still have more time I think we should probably have the following
things working:
- ZFS support. Kernel support should be there with the next kernel
upload, but there is still all the userland libs/tools to package.
- Keyboard configuration with console-setup.
Cheers,
Aurelien
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
Reply to: