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

Minutes of #debian-boot meeting of 20040706 (was: Debian Installer IRC meeting on Tuesday 07/06 20:00 UTC)

[Thanks to Christian Perrier for reviewing the minutes]

Minutes of #debian-boot Meeting of 2004.07.06.2000

Dates and times are UTC-referenced.

Meeting started at 2000.

There were 106 IRC nicknames present at #debian-boot at the start time.

The following people provided input to the meeting:
(a few names are missing as I cannot retrieve them currently)

 anibal: Anibal Monsalve Salazar
 anmar: Anmar Oueja
 bubulle: Christian Perrier
 calc: Chris Cheney
 cjwatson: Colin Watson
 dannf: Dan Frazier
 doogie: Adam Heath
 dsilvers: Daniel Silverstone
 fjp: Frans Pop
 gaudenz: Gaudezn Steiling
 jbailey: Jeff Bailey
 joeyh: Joey Hess
 joshk: Joshua Kwan
 kmuto: Kenshi Muto
 luther: Svan Luther
 mckinstry: Alastair McKinstry
 pere: Petter Reinholdtsel
 seppy: Dennis Stampfer
 tbm: Martin Michlmayr
 ths: Thiemo Seufer
 waldi: Bastian Blank


 aj: Anthony Towns
 anton: Anton Zinoviev
 bdale: Bdale Garbee
 vorlon: Steve Langasek


 bubulle: Christian Perrier

Discussion topics at:


Meeting logs:
(please refer to the logs to check who said what)


Release Plan

As it is possible that we want to go by 2.6 by default on powerpc for
sarge, this is a bit problematic.

HP folks have mentioned a couple times that they might prefer 2.6 by
default on ia64 and hppa. HP folks had better get moving ... :-)
Speaking from experience, it takes a while to do a d-i port to 2.6, and
you want both running concurrently for a while.

Sid is now in a situation where the installer works well on all release
candidate architectures except arguably s390. And s390 has had an
installation report that really doesn't sound all that bad.

The amount of development effort we have concentrated on sarge right now
is pretty low relative to sid. When the skew between sarge_d-i and
sid_d-i gets too great, it becomes unmanageable. And we're there or

No matter how much testing we do, we really can't know if something is
release quality until it's been beat on by the world in a beta release.

As current sarge is not in a releasable state, we need to go back to the
old method for at least one beta release. Wich means that we'll take a
snapshot of the udebs in unstable one day, do some testing, and call
that a release.

The plan is:

1. "Abandon" sarge_d-i
2. Fix sid
3. Feature freeze sid


Sarge d-i has some problems with separate boot partitions. vorlon fixed
them in current sid. He did a very good job in sid_d-i for alpha.

jbailey is doing the alpha nightlies, but haven't tested an install

Last known problem not in the manual is that aboot needs some space
in front of your drive. Latest install report also missed that. But
beside that sid_d-i has better reports than sarge_d-i.

alpha is in good shape.


The only big issues is that sometimes people have recent hardware that
isn't autodetected yet.

Once sarge is released, it would be a good idea to keep the d-i images up
to date with new kernels if possible.

The main question for amd64 is what do we do about it at release if the
ftp-master has not put it in the archive? Do we mention it? As

calc notes ftpmaster is not forthcoming with why its not being allowed
in. tbm mentioned there was some reason he forgot about but hasn't
responded to requests to nudge the info out of ftpmaster.


Were gonna be releasing with 2.4, as support for several of our
platforms is missing in 2.6 till upstream sorts it. But on all the
current sub arches with kernels we have had adequate install reports,
except riscpc which is supposed to be worked on by others.

kyllikki downloaded the cds built earlier and certenly netwinder
seems to net install.

Working CDs have been built fine; AIUI arm bootloading is a matter of
"specify location of kernel in CD" so they should now be fine.

arm is pretty much in good shape for sid_d-i, as long as the 2.4
kernels are ok.


jbailey has an hppa box now (acquired a week ago) and he hasn't done
further testing yet. The hppa folks have told him that 2.6 doesn't suck
for fork+exec, which might solve the partman issues. Aside from that
there's been success reports for install.

And failure reports (hangs) that remain undiagnosed, as joeyh notes.

cjwatson offered jbailey help with moving to 2.6.


joeyh found some nasty pcmcia problems recently, hopefully fixed

The base-config charset problems seem to keep popping up but not in

There are some upcoming changes to testing that will probably break
things: the 2.6.7 kernel, new tasksel. Also, new ethdetect is a lot
friendlier on all arches.

bubulle is confident the base-config charset problems are solved if we
use sid_d-i and the new lang/countrychoosers.

kmuto did the patch for the the no-framebuffer problem.

zboob has not changed his patch for a long time, but he will test it
again, however he can not go down ~23 MB because of dependencies. He
will test if its is applyable to the latest anna.

zboob informs, he has tested plip with last new netcfg, and it works

We should all give a few more attention to partman stuff and maybe try
to do some bugs triage.


The EFI partition bug suggests it never rebooted correctly.

Jim Lieb has been working on sid_d-i. With his last elilo-installer fix,
he said it was installable. He's been working on partman to fix the
autopartition stuff.

Someone at HP told dannf, it worked fine on their ia64 box, excluding the
autopart stuff.

At HP, they have a contractor working on ia64-specific issues, so please
let dannf know of any of them. He may do 2.6 for d-i but his main
objective is getting the current stuff working well. Once that's done,
dannf is sure he can look at it. dannf plans to do a
linux-kernel-di-ia64 in preparation.


There's still a chance that some m68k image builds will have broken
filesystems on them, and we still don't know why.

The status for m68k is having them (Yoe and smarenka) do a status


mips/mipsel is 2.4 kernel only so far.

The status is still "low memory situtations need investigation". Either
investigation or generally a lowmem limit above 32 MB.


In unstable, 2.4 and 2.6 both work fine on newworld pmac. 2.4 oldworld
pmac is unbootable, but then again it always has been.

It is reasonable to move for a 2.6 powerpc kernel for sarge, for all
currently supported architectures, the support for those is
better, and upstream (that is the linuxppc folk) as well as our own
kernel powerpc specialist are favoring 2.6 development and bug fix over

oldworld has a bootloader installer so if you boot it using BootX that
should theoretically be OK, but there's been zero testing. BootX depends
on non-free macos 9.

We should drop apus from the support, Simon may not like it, but there
maybe be something like 3 or so users left, and none of them helped.

No RC issues, apart possibly from Sven's keymap thing.


Currently, target is getting ssh working for stage2.

libcrypto is not fixed, waldi will do an nmu.

Missing for release of s390: some fixes in zipl-installer, uploads of
the other s390 specific packages.

Releasable after ssh is working.


busybox in sarge currently has functional biarch support so those
problems are all but over. busybox in sarge is A-Ok.

On sparc32, SMP kernels seem to have lots of problems, so joshk might
disable these in base-installer.

The initrd + SILO issues. It turns out it is a problem with _physical_
memory alignment. One tester repositioned some SIMMs, and it worked. So,
BenC needs to fix that, who knows when. Sounds like it should go in the
install manual.

Floppy builds still need root.

The 2.6 kernel on sparc is currently installable.

D-I Manual

Pretty much stalled. Some people anounced wanting to work on it, but
it's easy to get bogged down.

The manual is not even accurate yet about things like images. For
mips/mipsel, joeyh skimmed over it, and it is completely out of date.

Main problem is you need to take all architectures into account when
updating the manual. And it's not easy to identify what's left-over
Woody and what's OK for Sarge.

Meeting closed at 2355.

Attachment: signature.asc
Description: Digital signature

Reply to: