[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Debian Installer team monthly meeting minutes (20060429 meeting)

(reply-to: debian-boot)

Debian Installer team meeting number 11 has been held from 16:00UTC to
17:30UTC on Saturday April 29th 2006.

There were about 75 people connected to the channel during the meeting
and 12 of them spoke during the meeting at least once.

The full log of the meeting is available at

New busybox

Bastian Blank has a pending upload for busybox 1.1.2 to replace
current 1.01 in unstable. He would like to have this version in but
this needs deeper testing with D-I.

The new version was announced in
http://lists.debian.org/debian-boot/2006/04/msg00542.html but no
testing report has been made since then.

It is suggested that more people test this by building their own D-I
netboot images with this new busybox, before it is uploaded to

2.4 kernel support for etch

In general, we want to support 2.4 until the kernel is no longer in
the archive. However, depending on architectures, we may want to drop
it at different times.

Both the kernel and the release teams want to drop it, so the D-I team
has to be prepared for this to happen.

Joey mentions that many of his automated testing will break if 2.4 is dropped.

Petter also adds that it may help in the installer to be able to
install sarge (see another topic).

  i386: what to do?

No strong conclusion here. The discussion kinda got lost among various
more general consideration.

There seems to be an increasing consensus that supporting 2.4 on i386
is mostly a waste of time, but actually dropping it would break stuff,
mostly Joey Hess automated tests which are very useful to the team.

  sparc: drop 2.4 for next Beta 

General agreement for dropping it. It will break floppt images that
are currently build by G. Stappers (daily sparc images).

There are some issues with 2.6 kernels on sparc32, but 2.4 has issues
as well. Jurij Smakov is working on this.

  Need switch: m68k, mips/mipsel, S/390 (in progress)

Work is needed for net and dasd to be ready, for S/390. It seems that
2.6.17 could be needed. Basian Blank is working on this when he has
spare time. As soon as that is done, the remaining work can be handled
by Frans. So dropping 2.4 could be a little early for S/390.

No news for m68k: Frans will mail the porters.

For mipsel, DEC-station support for 2.6 is needed. It should work
upstream, but testers are needed. Martin Michlmayr will attempt to
mobilize some testers for that.

  Partial: arm, powerpc apus

arm can drop 2.4 now. only lart/bast sub-architectures are broken and only
these are stuck with 2.4. Until they're fixed, they will be dropped.

powerpc apus needs a kernel patch. From our understanding things need
some work in the kernel team, which may require time.

Installing sarge with the etch installer

There is a demand for this, at least from the Debian-Edu people.
The installed system can either be a full sarge system (which
means that we would reboot in 2.6.8, which won't work in all
situations) or a mixed system with backported 2.6.16 or later kernels
(which the kernel team will probably maintain as backports).

The bricks for using backports are not there yet because some support
should be added for debian-cd to use two sources. A workaround would
be supporting sarge installs only with netboot/businesscard images.

Moreover, if 2.4 support is completely dropped, many cleanups will
occur in D-I (mostly removing hotplug hacks in packages like
hw-detect) which is very likely to break sarge installs as well.

As a summary, effort to allow sarge installs will go on if they're
possible. Deeper discussion with Debian-Edu might be needed about how
to achieve this.

udeb dependency transition (g-i integration)

Correct dependencies on other udebs for D-I udebs is a requirement for
the integration of the graphical installer builds in the normal build
system for D-I.

The status of this work is kept at http://wiki.debian.org/DebianInstaller/LibraryUdebs.
The work is mostly finished now, with no critical packages affected.

Now we only need pango from outside libraries and then rebuilds of
gtk+-directfb and cdebconf which we can do ourselves.

The path thus seems cleared for g-i integration in the next
beta. Debconf work of the D-I team will focus on this with "have an
integrated build of g-i at the end of debconf" as goal. The only
blocker is the needed pango upload.

Work on fonts should now be finalized by Davide. If he needs some
help, some other people could bring manpower.

Make floppy builds work

Of course, we're here talking about 2.6 floppies as dropping 2.4 is
very likely to happen at some moment.

The main blocker is klibc that needs to provide udebs. The maintenance
team is focusing on solving arm build issues, then building a udeb
shouldn't be a problem.

H. Peter Avin would gladly bring help here and was needed an account
on the porting machine (which has been fixed in the meantime).

So, we can expect this to be solved soon, then the udeb being build
and need NEW processing (which is usually not a problem for udebs).

In short, nearly everything seems ready.

brltty integration

Unofficial images have been built by Samuel Thibault but we don't have
much news.

More coordination seems needed on that issue, while things however seem
mostly ready. More involvement from -accessibility people could help here.

These minutes will be posted in that mailing list for this...


The whole team congratulates max Vozeler for his perseverance on the
topic. Two years after the first discussion for encrypted file system
support in D-I, the first partman-crypto has been uploaded last week.

Now testing will be possible with daily images and unofficial builds
from http://nusquama.org/~max/d-i/crypto. loop-AES is working and
dm-crypt/LUKS is also (but needs an upload of cryptsetup-udeb, which
is waiting for libpopt0-udeb).

http://wiki.debian.org/DebianInstaller/PartmanCrypto summarizes everything.

Some work on debconf templates can now happen (some are marked
untranslatable because the wording needs to be checked). Christian
Perrier will do his best to do this, with the help of some native

Encrypted file systems support should also be documented in the
installation manual.

Persistent device naming

Issues seem solved now for NICs. Remaining issues are for disks. The
compatibility with 2.4 and 2.6.8 kernels does not help solving them,

dotslashdot preseeding

Phil Hands wasn't around to give details about this. In short, some
parts seem ready for integration in main D-I (most development is done
in Phil's tree in the SVN).

RAID in partman recipes

Simon Huggins is the most aware of these features intended to bring
some RAID-related recipes in partman-auto. The general idea is to have
a udeb able to preseed raid installations.

Integration into partman isn't ready yet and Fabio definitely intends
to give help on that issue. The main blocker is that the team
desperately needs someone really coordinating the work around partman.

Make online resizable ext3 file systems by default (#358001)

The suggestion made in this bug report is an interesting feature.

Here again, we would need someone to coordinate partman work and
decide whether such new feature is harmless or not. ext3 file systems
are curerntly created from ext2 filesystems created by parted.

The options are to add support in parted for creating ext3 file
systems, using mke2fs to create ext3 file systems, or get a working
tool to add the resize_inode to the file system

In short, even though it seems pretty harmless, it is unlikely that
this feature comes up in a near future unless a magic partman
coordinator jumps in.

Support ppc64 (what is status of that port)

Neither the kernel team, nor the release team plan to support this
architecture now or in a middle term future. As a consequence, the
decision is to ignore requests to support it and notify Andreas
Jochens in the relevant bug reports.

As a side comment, work to support kFreebsd has begun and activity is
increasing. Later after the comment, Otavio Salvador branched the SVN
so that kfreebsd work does not currently interfere.

Combined i386/amd64 install images

This comes from a request by Goswin von Brederlow

Though not giving rationale, one may assume that this request is meant
to have better optimisation for users of amd64 arches who are usually
not aware that they would benefit from a native port.

However, the request will probably lead to a pretty invasive work and
the planned release for etch is too close for it to happen.

As a conclusion, while not ruling it out completely, the team prefers
delaying this to post-etch work.


The next meeting will be held at some moment after Debconf,
preferrably at the end of May or beginning of June. One can expect
that it will be meant to set the final lines for beta3 (targeted to be
the last beta before Etch release).

Attachment: signature.asc
Description: Digital signature

Reply to: