Fwd: Debian Installer etch beta 1 released

[Robert Millan]

On Sun, Nov 13, 2005 at 12:19:41AM +0100, Aurelien Jarno wrote:
> >
> >I think that releasing with etch is very ambitious.  I was thinking we 
> >might shoot for etch+1.  However, I think that the SCC archive for etch is 
> >not a bad idea.  This means that we need to be slightly more assertive 
> >about getting fixes included.
> 
> Well I agree that releasing with etch is almost impossible. I think the 
> only way to become an official release is to do as amd64, ie do an 
> unofficial etch release. So we have to be ready in a little bit than one 
> year (but the release will likely be delayed, so we have a little more 
> than that).

Well, the initial plan was to release with sarge ;).

I think it all depends on wether we gain enough momentum in time.  If the port
is added to unstable soon (along with amd64), I think that will attract lots of
people.

We have a recertification page in the wiki just like other arches:

  http://wiki.debian.org/kfreebsd-i386EtchReleaseRecertification

Basicaly, it seems we just need d-i and the missing 24% of ported packages.  And
in an extreme situation, we *could* even release without d-i (another issue is
if we really want that, of course).  I also wonder how many of these 24%
packages have patches in BTS.

> >Then, we'd have to port busybox, syslinux (or some other ISO booter), 
> >dosfsutils, parted, and discover1.  I think that's it.
> 
> AFAIK busybox is already ported.

There are two incompatible patches, one for debian and one for upstream (debian
autoconfised the source and is a bit different from upstream).  I managed to
merge part of the upstream one, but for the other changes they want to discuss
in the mailing list (which I didn't have time for).  Debian maintainers are
completely ignoring us.

I have a semi-working patch for dosfstools hanging around.  I'll commit it
later.

> For syslinux, ging is already able to 
> boot from a CD, so I think we already have a solution.

I would look at the scripts in web/cdscripts instead.  This is what Ging's
current boot code is based on.

> >I'm still unclear abot upx-ucl-beta, which compresses executables.  I'm 
> >not sure if our kernel supports that, or if it just happens on the fly (in 
> >which case the kernel doesn't have to support it).  We may have to patch 
> >it to support bootable FreeBSD kernels.
> Our kernel support gzip, maybe it is ok?

If we use ramdisk, the whole image is compressed.  The kernel is also
compressed.  You mean we support things like a gzipped ELF in /bin/sh ?

-- 
Robert Millan