Fwd: Debian Installer etch beta 1 released

[Aurelien Jarno]

Brian M. Carlson a écrit :
> On Saturday 12 November 2005 16:55, Aurelien Jarno wrote:
> 
>>Robert Millan a écrit :
>>
>>>Does this mean we're out of time for porting d-i?  Maybe we'll have to
>>>stick
>>
>>2 or 3 more release of d-i are planned before the etch release.
>>
>>
>>>with FreeBSD installer for the etch release (it could be easily hacked to
>>>use debootstrap, remove FreeBSD-specific portions, etc).
>>>
>>>What do you think?
> 
> 
> 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).


>>If that happens, I mean if we are not able to port d-i quite enough, I
>>think it would be better to make an unofficial patched version of d-i.
>>We are all short on time, so it is better to work on the final installer
>>than on an intermediate one.
> 
> 
> d-i depends on bogl (source), which is very Linux-specific.  I"m trying to 
> patch out the Linux-specific bits into a bogl-linux.[ch] and create a 
> bogl-freebsd.[ch] (since all it cares about are devices and ioctls).  This 
> will break the API, but in a compatible way (we're only adding functions, so 
> we can bump shlibs).  Or we could simply make the bogl_os_ symbols (which I 
> implemented) static with a versioning script.  Either way, this will help not 
> only us, but also other non-Linux ports.
> 
> Ben Pfaff (bogl's upstream) is not interested in any major changes (of any 
> type), so the bogl port will probably be Debian-specific.
> 
> 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. For syslinux, ging is already able to 
boot from a CD, so I think we already have a solution.

> 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?

> Other things we have to do include porting kFreeBSD 6.0, fixing the kernel and 
> libc so that we can use RT signals (patch in the BTS, kernel *must* be fixed 
> first), and moving ld.so.1 from address 0.  I will reboot in a second and try 
> the new kernel for RT signals, and report to the BTS.  When we've 
> accomplished these things, we should report to -devel.

Well I don't know if we have to concentrate our efforts on kFreeBSD 6.0 
now. There is a huge work to do, whereas kFreeBSD 5.4 work pretty well, 
even if it is a bit outdated.

Concerning the threads, I will have a look at the patch when the glibc 
is fixed, so that we can make some tests. I don't see any reason to 
include it in the kernel before.

Bye,
Aurelien

-- 
   .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
  : :' :  Debian developer           | Electrical Engineer
  `. `'   aurel32 at debian.org         | aurelien at aurel32.net
    `-    people.debian.org/~aurel32 | www.aurel32.net