Log from the Debian Installer team meeting of April 29th 2006, 16:00UTC
----------------------------------------------------------------------

People who speak below:

bubulle   : Christian Perrier
fabbione  : Fabio Massimo di Nitto
fjp       : Frans Pop
joeyh     : Joey Hess
makx      : Maximilian Attems
_Max      : Max Vozeler
[-oskar-] : Xavier Oswald
otavio    : Otavio Salvador
pere      : Petter Reinholdtsen
tbm       : Martin Michlmayr
trave11er : Jurij Smakov
waldi     : Bastian Blank

Nicknames mentioned during the meeting though these people were not attending:

Kamion    : Colin Watson
ninou     : Sylvain Ferriol 
fil_      : Phil Hands
huggie    : Simon Huggins

Hours are European Time (UTC +0100):

17:59 < bubulle> So, let's open the meeting
17:59 -!- bubulle changed the topic of #debian-boot to: D-I Meeting in progress. Topic:(waldi|fjp) New busybox: config needs check (5mins)
17:59 < bubulle> here we go
17:59 < fjp> joeyh: Well, amd64 needs 2.6.15 kernel in testing + corresponding udebs and they're not there due to how the migration was handled.
17:59 < bubulle> waldi?
17:59 < fjp> OK
17:59 < bubulle> or fjp actually
18:00 < waldi> we currently have busybox 1.01 in the archive
18:00 < waldi> i'd like to update to 1.1.2
18:00 < waldi> but this needs a complete config recheck, as there was a large amount of changes between
18:01 < fjp> So who knows enough about current busybox config and what d-i needs to do this?
18:01  * fjp thinks of Kamion 
18:02 < joeyh> were there some issues with mdutils support being removed (just lsmod?)
18:02 < waldi> it may a start to just try to use it and see if it breaks
18:02 < waldi> joeyh: ah, yes, modutils will go away completely
18:02 < joeyh> even 2.4?
18:02 < bubulle> waldi: is 1.1.2 in experimental or so?
18:02 < waldi> bubulle: no, experimental have no udeb section
18:02 < waldi> joeyh: yes
18:03  * joeyh wonders how many floppies that will hose
18:03 < CIA-20> debian-installer: yeager-guest * r36790 manual/po/sv/ (8 files): Updates for the swedish translation
18:03 < bubulle> ah yeah...maybe making it avail somewhere, announce to -boot and have ppl test by building their custom images
18:03 < waldi> bubulle: i already did that
18:03 < fjp> joeyh: I sent a mail about that with proposal for lsmod, could you reply?
18:03 < joeyh> less worried about lsmod than modprobe :-)
18:04 < waldi> bubulle: <20060416175709.GA19472@wavehammer.waldi.eu.org>
18:04 < bubulle> waldi: so, actually, what can be done is doing more noise about this, then?
18:04 < bubulle> (mentioning the topic in the meeting report is already a way to do so)
18:05 < waldi> bubulle: yes, or just upload it and see what breaks
18:05 < bubulle> well, needs fjp GO, i guess
18:05 < joeyh> which would be ok or bad, depending on the schedule
18:05 < pere> waldi: how high is the risk assosiated with uploading and see what breaks?  how many did test it already?
18:06 < fjp> What do we for non-busybox modutils support currently? Only 2.6?
18:06 < waldi> pere: i did not get any response
18:06 < joeyh> yes, only 2.6 ATM
18:06 < waldi> fjp: 2.6 uses module-init-tools. 2.4 can use the modutils udeb again
18:06 < fjp> waldi: That is why I put it on the agenda for today. I think impact was not clear enough
18:07 < joeyh> insmod.modutils is enormous (131k), so I'm wondering if any 2.4 floppies will be possible..
18:07 < bubulle> ok, so the conslusion here seems to be: uploading it now would be risky but we must have people test the new busybox
18:07 < fjp> Well, we want to get rid of those anyway, don't we?
18:07 < waldi> yes
18:08 < bubulle> anything mor eto add about this busy box topic?
18:08 < waldi> no
18:08 < bubulle> ok, let's move...
18:08 -!- bubulle changed the topic of #debian-boot to: D-I Meeting in progress. Topic: 2.4 kernel support for Etch (15mins)...
18:08 < bubulle> i386: what to do?
18:08 < bubulle> fjp?
18:08 < waldi> drop it
18:09 < fabbione> waldi: ++
18:09 < fjp> Let me start of with the reason for bringing it up
18:09 < makx> thirded
18:09 < joeyh> I want to support 2.4 i386 until the kernel is no longer in the debian archive
18:09 < joeyh> and I've been doing the work to do that.
18:09 < waldi> joeyh: no problem, we can drop it tomorrow
18:09 < fjp> There was a short discussion on d-release about the status of 2.4
18:09 < fabbione> joeyh: is there any reason to keep 2.4 around for i386 generally?
18:09 < fjp> It looks like both RM and kernel team want to drom it for Etch.
18:10 < fjp> drop even
18:10 < waldi> yes
18:10 < joeyh> once we drop 2.4, I will have to discontine more than half of my automated testing
18:10 < joeyh> since those machines break with 2.6
18:10 < pere> keeping d-i support for 2.4 might make it easier to support installing sarge.
18:10 < CIA-20> debian-installer: jseidel-guest * r36791 packages/po/de.po: Minor cosmetic update. Adds e.g. a few missing colons, ...
18:10 < fjp> pere: that's only a secondary consideration though
18:11 < bubulle> I guess that if joeyh's machines break with 2.4, other machines will, don't they?
18:11 < fjp> joeyh: Shouldn't you make more noise with kernel team or porters to get those issues fixed then?
18:11 < bubulle> s/2.4/2.6
18:11 < joeyh> fjp: afaik bugs are in the bts for most of the issues
18:12 < joeyh> like the hppa bug that it doesn't see the pci bus with 2.6..
18:12 < fjp> bubulle: Well, partly it is relatively minor things like serial console no longer working
18:12 < fabbione> wasn't the discussion related only to i386 ?
18:12 < makx> for hppa kylem should be notified
18:12 < fabbione> joeyh: ^^
18:12 < waldi> fabbione: yes
18:12 < bubulle> yeah, my understanding was that the topic is now "drop *for i386*"
18:12 < fjp> Yeah, but having a bug in the BTS is sometimes not enough...
18:13 < fjp> I'm wondering if we'll have the choice to keep 2.4.
18:13 < bubulle> joeyh: so would dropping 2.4 for i386 break somethign for you?
18:14 < bubulle> fjp: at some moment we won't probably
18:14 < joeyh> sure, all i386 testing
18:14 < joeyh> grub refuses to work on 2.6 with my test machine's HW raid array
18:14 < fjp> Also keeping 2.4 does complicate d-i, or at least, dropping it would allow a lot of cleanup
18:15 < bubulle> about making it easier to install sarge, I'm unsure that keeping 2.4 support would help
18:15 < fjp> joeyh: Which means i386 testing is suboptimal anyway as our main target is 2.6
18:15 < bubulle> machines that can't be installed with sarge installer usually need 2.6 anyway
18:15 < fjp> Ack.
18:15 < bubulle> I suggest we move on on 2.4 issues to next subtopic:
18:15 < bubulle> sparc: drop 2.4 for next Beta 
18:16 < fjp> trave11er: You OK with that?
18:16 < trave11er> yeah, i don't know of any problems with that
18:16 < fjp> It would mean that stappers can no longer build his sparc floppies though.
18:16 < trave11er> joeyh: btw, i'm looking into the serial console problem
18:17 < bubulle> OK, then...move on again.
18:17 < bubulle> Need switch: m68k, mips/mipsel, S/390 (in progress)
18:17 < fjp> trave11er: 2.6 for sparc32 has no real problems any more, right?
18:17 < bubulle> porters?
18:17 < trave11er> fjp: it does
18:17 < waldi> i'm working on it
18:17 < trave11er> fjp: but hopefully they'll get sorted out
18:18 < bubulle> hmmm, well
18:18 < fjp> waldi: can you give an estimate when net and dasd could be ready? dasd is quite close to ready, right?
18:18 < fjp> After that, I can probably help with the rest.
18:18 < makx> needs 2.6.17 afair
18:19 < fjp> makx: What does?
18:19 < waldi> fjp: no I can't, I'm too short of time currently
18:19 < fjp> ths, tbm: comments on mips/mipsel?
18:19 < fjp> I'll mail m68k porters.
18:20 < bubulle> not sure they're around, yes...so mail
18:20 < bubulle> Partial: arm, powerpc apus
18:20 < bubulle> quickly as we're a bit late
18:20 < waldi> apus needs a patch
18:21 < tbm> arm can drop 2.4
18:21 < fjp> Sven has posted something about ppc. I understand that it needs work in the kernel which will probably take a while
18:21 < tbm> mipsel needs decstation support for 2.6.  Should work upstream, but need testers
18:21 < fjp> tbm: For all subarches? I thought only netwinder was on 2.6 currently?
18:22  * bubulle waits for last comments on mipsel and then we'll move on
18:22 < tbm> fjp: lart/bast support are broken anyway and only they are 2.4
18:22 < fjp> Ok, so drop lart/bast?
18:22 < tbm> yeah
18:22 < bubulle> for the report, I'll need to know what ar elast/bast
18:23 < bubulle> lart even
18:23 < fjp> arm subarches
18:23 < bubulle> ok
18:23 -!- bubulle changed the topic of #debian-boot to: D-I Meeting in progress. Topic: (fjp) installing sarge with the etch installer (10mins)
18:23 < bubulle> fjp (joeyh): your baby
18:23 < fjp> tbm: Can you try to mobilize testers for decstation?
18:24 < tbm> fjp: yeah
18:24 < fjp> Sarge installs
18:24 < fabbione> fjp, joeyh: what is the rationale behind installing sarge with etch installer?
18:24 < fjp> Basically it's possible again for i386, but result will be different from using Sarge installer
18:25 < tbm> ths: can you look at 2.6.17 for mips?
18:25 < fjp> Also, there are risks on reboot as you drop from installing using 2.6.16 to reboot with 2.6.8
18:25 < pere> fabbione: I can not speak for fjp or joeyh, but I want sarge installs to work for debian-edu, making it possible to use the new base-config-less install to install a normal sarge system.
18:25 < waldi> fjp: hmm, may it easier to use the 2.6.16 in the sarge system? the kernel team finaly wants to provide its own backports
18:26 < fjp> I want to add so dialogs with warnings and checks for arches that are known not to work (e.g. because the switched 2.4->2.6)
18:26 < waldi> (okay, this is not longer a pure sarge)
18:26 < fjp> Last remark
18:26 < bubulle> fjp: is this in a state that allows it to be in next beta (which we don't know when we'll ship anyway)
18:27 < fjp> Keeping sarge support very much depends on keeping all the hotplug etc hacks that are currently in mainly hw-detect
18:27 < bubulle> waldi: yep, that would be something between a pure sarge and kmuto customized CDs
18:27 < fabbione> pere: i can see your point even tho i don't fully understand why you want sarge when etch is out.
18:27 < fjp> If we decide to drop 2.4 and thus cleanup, Sarge support will disapear very fast too.
18:27 < bubulle> fabbione: because debian-edu has different schedules than Debian, maybe
18:28 < pere> fabbione: we want sarge support until etch is out, and a few months after that. :)
18:28 < waldi> bubulle: and we get sarge installations with rather actual kernels
18:28 < fjp> waldi: Yeah. Don't think it is feasably though as basically you'd also need to adapt debian-cd to support a second source for backports
18:29 < waldi> fjp: or provide this possibility only for non-cd-only installations
18:29 < fjp> Also, I'm not sure that Debian should go that way "officially" as that also means guaranteeing the upgrade path and dosumenting it in release notes
18:30 < fjp> That would mean having debootstrap support two sources...
18:30 < bubulle> so, keep the possibility to install sarge as a kind of "bonus feature"
18:30 < fjp> (or doing an upgrade immediately after debootstrap)
18:30 < waldi> hmm?
18:30 < bubulle>  and let CDD's that need more deal with it..:)
18:30 < waldi> fjp: the base system is not effected by this
18:31 < fjp> pere: Maybe we should talk more about this outside the meeting...
18:31 < bubulle> fjp: more on this?
18:31 < fjp> Not for me.
18:31 < pere> fjp: yeah.
18:31 < waldi> okay
18:31 -!- bubulle changed the topic of #debian-boot to: D-I Meeting in progress. Topic: (fjp) udeb dependency transition (g-i integration) (10mins)
18:32 < fjp> waldi: Hmm. Well it does at least affect base-installer, maybe not debootstrap though.
18:32 < fjp> Me again?
18:32 < bubulle> for non aware ppl: http://wiki.debian.org/DebianInstaller/LibraryUdebs
18:32 < bubulle> fjp: well, you did most of the coordination?
18:33 < fjp> Almost all udebs now have correct dependencies on other udebs
18:33 < bubulle> libtextwrap seems to be needed still?
18:34 < fjp> For g-i we only need pango from outside libraries and then rebuilds of gtk+-directfb and cdebconf which we can do ourself
18:34 < joeyh> yes, but it's not a very significant one in its effects
18:34 < fjp> So, very close
18:34 < bubulle> fjp: so do you think we're on time for g-i in next beta?
18:34 < fjp> joeyh: I'd like to talk to you during debcamp about integration
18:34 < bubulle> deoends on the beta schedule, of course
18:34 < fjp> bubulle: Yes, possibly.
18:34 < bubulle> do you think we can set this as a goal for debconf work?
18:35 < fjp> Yep.
18:35 < joeyh> ok
18:35 < bubulle> have an integrated build of g-i at the end of debconf
18:35 < fjp> Although the specialists won't be there...
18:35 < fjp> Depends on pango upload though.
18:35 < bubulle> maybe arrange a daily meeting with them on IRC while debconf is running
18:36 < fjp> And zinosat needs to really start on finalizing fonts...
18:36 < bubulle> fjp: adn will be at debconf and can do some work on it also
18:36 < fjp> K
18:36 < bubulle> I speak for him but heh....
18:36 < fjp> Next I think
18:37 < bubulle> ok, let's move
18:37 -!- bubulle changed the topic of #debian-boot to: D-I Meeting in progress. Topic: (ninou) make floppy builds work (10mins)
18:37 < bubulle> ninou is not around I think
18:37 < fjp> That is 2.6 floppies
18:37 < makx> klibc needs to provide udebs
18:37 < makx> issue is known
18:37 < makx> had build trouble to heavy upstream churns lately
18:37 < fjp> makx: Any ETA for that? Need help?
18:38 < bubulle> makx: this is a blocker, I guess
18:38 < makx> currently our latest klibc is  not building on arm
18:38 < makx> once this is fixed udeb integration is not hard
18:38 < fabbione> makx: hpa will be glad to help given an account the porting box. I did talk to him about porting issue no longer than 2 days ago
18:39 < bubulle> fabbione: what is hpa's real name?
18:39 < makx> fabbione that's great news
18:39 < fabbione> makx: Hans Peter Avin (modulo spelling orrors)
18:39 < bubulle> ok
18:39 < fabbione> (but call him Peter or he will be upset)
18:39 < fabbione> ;)
18:40 < pere> will klibc be ported to all archs?
18:40 < fjp> joeyh: What is your take on the status of 2.6 floppies? Almost there or not?
18:40 < makx> pere: it is almost to m68k
18:40 < joeyh> seems almost there, I haven't seen a lot of the code though
18:40 < makx> and still some statfs struct troubles on mips
18:40 < pere> it is blocking ltsp on mips and mipsel, so I hope so. :)
18:41 < makx> pere: it is building on mips and mipsel
18:41 < makx> so how is it blocking?
18:41 < fabbione> makx: please speak with hpa here on freenode to arrange stuff. He is getting m68k access
18:41 < pere> makx: good to hear.  I guess my knowledge is old news. :)
18:41 < makx> pere: yes.
18:42 < makx> fjp: once all archs are building again with latest udeb integration will force klibc into NEW so hard to give an ETA
18:42 < bubulle> OK, seems that nothing more will wome about the 2.6 floppies topic
18:42 < waldi> makx: udeb NEW is mostly no problem
18:42 < bubulle> main conclusion-->push work on klibc..:)
18:43 < fjp> [-oskar-]: There? Care to give a little status update on graphical parted for g-i?
18:43 < bubulle> heh, you're breaking my schedule..:-)
18:43 < fjp> [-oskar-]: (Later though)
18:43 -!- bubulle changed the topic of #debian-boot to: D-I Meeting in progress. Topic: (S. Thibault if around) brltty integration (5 mins)
18:43 < fjp> No forgot the "later"
18:43 < bubulle> not sure that someone can talk about it
18:44  * pere hope d-i can support reader lists again, but lack the skills and time to work on it myself.
18:44 < [-oskar-]> fjp: you are lucky, I'm here !
18:44 < fjp> There seem to be some open issues still that keep us from really applying the patches?
18:44 < fjp> joeyh: ?
18:44 < joeyh> not sure what the current status is
18:45 < [-oskar-]> fjp: well, I have to try the new build with gtk2.9 because I use gtk > 2.6 functions
18:45 < fjp> joeyh: Could you pick that up please? It's too much over my head to decide on it.
18:45 < fjp> [-oskar-]: Wait till a bit later please
18:45 < [-oskar-]> fjp: hope to have a functionnaly tool in about 1 month
18:45 < [-oskar-]> ok
18:45 < joeyh> have they sent an unapplied patch? I didn't see it
18:46 < fjp> Well, there were several threads and some ping-pong and some usb/udev module loading issues.
18:46 < bubulle> http://lists.debian.org/debian-accessibility/2006/04/msg00001.html
18:47 < joeyh> bubulle: not a patch though
18:47 < fjp> There was at least one patch to include the modules that we did not apply. AFAIK you only did the serial reorg, but not the actual loading of the brltty modules
18:47 < bubulle> of course...I was just wandering through the list to get an idea..:-)
18:48 < fjp> I'll try to make a summary.
18:48 < bubulle> OK, then....no one with mor eideas. I'l lprobably post the meeting minutes to -accessibility
18:48 -!- bubulle changed the topic of #debian-boot to: D-I Meeting in progress. Topic: (_Max) partman-crypto (10 mins)
18:48 < _Max> Should I give a quick status report?
18:48 < bubulle> firts, hurrah for the first upload, _Max 
18:48 < bubulle> yep, go ahead
18:48 < _Max> thanks :-)
18:48 < _Max> So, partman-crypto is in NEW and all udebs it depens on are in unstable
18:49 < _Max> We have working and tested support for loop-AES. dm-crypt/LUKS is basically working too. It still nees an upload of cryptsetup-udeb (which in turn waits for libpopt0-udeb)
18:49 < _Max> There are no big outstanding problems, so we're focusing on the remaining bugs, integration and UI improvements (most noted in TODO and BUGS in svn).
18:49 < _Max> It would be great to get feedback especially on the UI and if/how it could be improved (including templates, wording, conveying the crypto concepts etc.)
18:49 < bubulle> http://wiki.debian.org/DebianInstaller/PartmanCrypto for those not aware
18:50 < _Max> Yes, that's mostly up to date
18:50 < bubulle> _Max: yep, I planned having a look at the templates now
18:50 < _Max> bubulle: Some are still marked as untranslatable because we were not sure about the wording. Your feedback would be very welcome
18:50 < _Max> Also thoughts (fjp?) on starting to add documention to the manual
18:51 < makx> initramfs-tools got support for cryptoroot we are waiting for cryptsetup hooks from it's svn
18:51 < bubulle> _Max: yep, will check this and also ask advice of native speakers (Kamion, joeyh...)
18:51 < _Max> Also generally testing is very welcome :-)
18:52 < _Max> There are daily builds at http://nusquama.org/~max/d-i/crypto
18:52 < _Max> (last night was broken because of SVN)
18:52 < bubulle> and it will be in the dailies as soon as NEW is processed, right?
18:52 < _Max> I'm not sure? It is priority standard
18:53 < waldi> yes, this will pull it in
18:53 < _Max> Also it needs loop-aes-$KVERS-di which is not pulled in by dependency. I'm oncluding it in pkglists/local - not sure about dailies here
18:53 < _Max> s/oncl/incl/
18:53 < bubulle> _Max: I suggest that as soon as it enters unstable, you post some announcement to -boot (maybe wider) to get testing
18:54 < joeyh> _Max: what depends on that?
18:54 < makx> lvm-crypt is preferred
18:54 < _Max> bubulle: Good idea, will do
18:54 < _Max> joeyh: Currently the partition erase step
18:54 < _Max> joeyh: And for using loop-AES of course
18:54 < joeyh> you should make the udeb depend on loop-aes, which that udeb shuld provide
18:55 < _Max> dm-crypt is not fully functional though
18:55 < _Max> joeyh: Will it do the right thing if I depend on a vritual package wrt kernel version?
18:55 < joeyh> yes
18:55  * bubulle remembers the days of Debconf4 where people were beginning to talk about encrypted FS support..:)
18:55 < _Max> Cool, will do then
18:55 < _Max> :-)
18:55 < makx> _Max: what is missing in dm-crypt?
18:56 < makx> its the upstream solution
18:56 < _Max> makx: cryptsetup-udeb, mainly
18:56 < fjp> _Max: For the manual a proposed text would be welcome. I can do the formatting and integration if you're not comfortable with that.
18:56 < CIA-20> debian-installer: joeyh * r36792 /people/joeyh/autoinstall/schemes/ (elephant/common elephant/common-boot-opts zebra/manual): fix elephant, fix zebra manual mode
18:56 < _Max> makx: We'll support it
18:56 < bubulle> OK, anything more on partman-crypto?
18:56 < _Max> fjp: Great. I'm not very confident in my english :)
18:56 < _Max> If we have time?
18:57 < bubulle> we're mostly just OK with the schedule right now
18:57 < _Max> OK then, that's most important things
18:57 < fjp> _Max: Try to work it out with your partner in crime first though.
18:58 < bubulle> anyway, I think that we can all reward _Max and all other people who worked on this for their perseverance....this is a great achievement
18:58 < _Max> heh, OK ;-)
18:58 < _Max> thank you :-)
18:58 < bubulle> and now move on
18:58 -!- bubulle changed the topic of #debian-boot to: D-I Meeting in progress. Topic: (fjp) persistent device naming (5mins)
18:58 < bubulle> maybe more joeyh than fjp
18:59  * fjp has been terribly remiss there
18:59 < fjp> Luckily Md has magically fixed the issue for NICs
18:59 < joeyh> nics seems to be working ok, just from what I can see
18:59 < joeyh> is disk still an issue?
18:59 < fjp> So we only need to worry about the issues around disks
18:59 < waldi> this solution does not work on s390
18:59 < waldi> yes
19:00 < fjp> I still plan to organise an IRC meeting to discuss this with people involved, but things keep coming in between.
19:00 < bubulle> I suppose that the trickiest thing for disks is having the setup to actually test this?
19:00 < waldi> is there any problem with just using /dev/disk/by-path? at least for ide/scsi/dasd?
19:01 < fjp> Well, identify the issues involved and work out a plan first.
19:01 < waldi> hmm, yeah
19:02 < bubulle> well, silence is huge, so let's move on again
19:02 < fjp> The problem as I see it is that quite a few components are involved, there are several issues to be solved and it may be hard to do while still keeping 2.4 and 2.6.8 compatibility (devfs) throughout.
19:02 < bubulle> bu I suggest that someone at least describes which setup is needed to test the disks naming issues..:)
19:03 -!- bubulle changed the topic of #debian-boot to: D-I Meeting in progress. Topic: (fil_) dotslashdot preseeding (5mins)
19:03 < waldi> bubulle: a s390 installation with 4 dasds shows the problem quite good
19:03 < fjp> Simple: any system with two hd controllers
19:03 < bubulle> fjp: ah, even in vmware, then
19:03 < bubulle> anyway, we've moved
19:03 < bubulle> but not sur ethat fil_ is here
19:04 < fjp> Is that really a target for integration or more of an optional extra that should maybe be documented better?
19:05 < fjp> joeyh ?
19:05 < joeyh> AFAIK, fil has been trying to get patches in for some parts that are more generic
19:05 < joeyh> and we came up with some redesign of his stuff that allows adding some useful new features to preseed
19:05 < fjp> In his own tree so far only I think?
19:06 < joeyh> yes
19:06 < bubulle> so "target for integration", it seems..:)
19:06 < fjp> Should we give him go ahead to integrate those in trunk?
19:06 < joeyh> probably
19:06 < tbm> joeyh: can you upload nslu2 firmware installer so I can test it at some point
19:06 < joeyh> tbm: nslu2-utils with that included cleared NEW, finally, this morning
19:07 < bubulle> OK, no mor eon dotslashdot (someone explain me this name some day...:-))
19:07 -!- bubulle changed the topic of #debian-boot to: D-I Meeting in progress. Topic: (huggie,fabbione) raid in partman recipes (5mins)
19:07 < fabbione> ok
19:07 < tbm> joeyh: nslu2-utils ships the udeb?
19:07 < fabbione> i did speak a bit this morning with bubulle and huggie since i didn't really know i was involved in it till a few hours ago
19:07 < joeyh> tbm: oh, no.. just the deb that the udeb uses. The udeb is still not tested, but is in svn
19:08 < bubulle> yeah, sorry, I was thinking that fabbione is involved in this while he isn't really
19:08 < fabbione> from a look at the code and the thread on d-i mailing list i can see there is a lot of pontentiality in what huggie is doing
19:08 < fabbione> the general idea is to have a udeb able to preseed raid installations
19:09 < fabbione> but it is not yet a fully partman-auto-md module yet
19:09 < fabbione> and IME it breaks the concept of partman-auto-*
19:09 < tbm> joeyh: well, I've no idea how I'd test it from svn
19:10 < pere> how dynamic will such automatic partitioning be?  can it come with different disk sizes in a nice way?
19:10 < fabbione> it should probably be names partman-md-preseeding at this point in time due to the limited funcionality
19:10 < joeyh> tbm: build a udeb and wget?
19:10 < fabbione> pere: for what i saw you can pass some recipes to it. that's it. it's up to you to know what to give it
19:10 < tbm> ah, hm
19:10 < joeyh> pere: currently it just uses whole disks and raids them together then allows using partman on the raid
19:10 < fabbione> pere: you want to excuse me if i can't be more precise but i read the code once after i was told about it a few hours ago
19:11 < bubulle> fabbione: so all this is still pretty experimental
19:11 < bubulle> but huggie is actually the one who can tell more.
19:11 < pere> right.  I wonder if the auto* stuff can replace autopartkit, being able to set sizes based on memory size, disk size, requested partitions etc.
19:11 < bubulle> thanks for trying to sommarize....was not easy I suppose
19:12 < fjp> pere: What is missing in current partman for that?
19:12 < pere> fjp: not sure.  I do not know the current partman. :(
19:12 < fabbione> bubulle: well my plan was to work on partman-auto-md with the same concept of partman-auto*
19:12 < CIA-20> debian-installer: joeyh * r36793 packages/po/packages_list: add aslu2-firmware-installer to package list for translation
19:12 < fabbione> but it's not easy to do and won't have time till june after dapper release
19:12 < joeyh> the only thing missing is it does not use iential algos to size the partitions as autopartkit, afaik
19:12 < fabbione> but definetely i am willing to help huggie there
19:13 < joeyh> that is, identical algos
19:13 < bubulle> ok, let's record that intent.;:-)
19:13 < fjp> fabbione: Great.
19:13 -!- bubulle changed the topic of #debian-boot to: D-I Meeting in progress. Topic: (pere?) make online resizable ext3 file systems by default (#358001) (5mins)
19:13 < bubulle> seems to be a design issue, should we do what pere is suggesting?
19:13 < pere> right, my favorite topic.  making linux machines into real file servers.
19:13 < fjp> joeyh: Is autopartkit better in that respect?
19:13 < joeyh> fjp: not necessarily, just different
19:14 < bubulle> pere: I read the bug report quite quickly and what you propose seems pretty much harmless. Am I right?
19:14 < fabbione> bubulle: IME partman needs a lot of love but i doubt that it can come from one person and before etch.
19:14 < pere> yes, partman uses libparted to create ext2, and then uses tune2fs -j to convert it to ext3.  this give us a non-online resizable file system.
19:15 < pere> it will need to create the ext3 file system with -O resize_inode to get a online resizable file system.  the only tool available to add the resize_inode option is ext2prepare, and it is very fragile (and unsafe to use).
19:16 < bubulle> so either we go that way...or we change partman to create ext3 immediately with the right options?
19:16 < pere> so 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.
19:16 < waldi> pere: does libparted produce filesystems with large anough blocksizes in the meantime?
19:16 < fjp> The problem with partman IMHO is that we lack someone who coordinates.
19:17 < pere> waldi: I do not know about any problem with block sizes.
19:17 < bubulle> fjp: recurrent problem, yes
19:17 < _Max> Anton is still very busy, no?
19:17 < joeyh> and using mke2fs means losing the progess bar during fs creation, unless something can be hacked up using its output
19:17 < pere> the e2fsprogs maintainer plan to make resize_inode the default for mke2fs some time in the future, but this is not done yet.
19:17 < fjp> Well, we don't see much of him unfortunately...
19:18 < bubulle> I think that partman is probably the most fragile area in D-I actually
19:18 < pere> joeyh: well, you can have a progress bar with two steps.  "start of mkfs", and "mkfs finished". :)
19:18 < makx> aka no progress bar
19:19 < pere> I maintain the ext2resize package, which is the one with the ext2prepare tool.  Progress is slow as upstream is shattered.  a replacement tool might show up in e2fsprogs some time in the future, but ted said it was low priority for him to write it.
19:19 < bubulle> well, I'd say that at this moment the safest option seems to be for "the e2fsprogs maintainer plan to make resize_inode the default for mke2fs"
19:20 < bubulle> other options seem likely to break stuff
19:20 < pere> bubulle: partman isn't using mkfs to create ext3.  it is using parted.
19:20 < bubulle> ah bleh
19:20 < joeyh> we could live with a 2 step progress bar if the entire partman formatting of all partitions lived in 1 progress bar
19:21 < bubulle> let's move. We have to finish this meeting..:)
19:21 -!- bubulle changed the topic of #debian-boot to: D-I Meeting in progress. Topic: (fjp) Support ppc64 (what is status of that port)?
19:21 < pere> I changed autopartkit to use mkfs instead of parted to avoid problems like this.  I suspect partman should do the same.
19:21 < bubulle> any ppc/ppc64 people around?
19:22 < fjp> There are several patches open to add support for ppc64. My question is basically if we should just apply them or not?
19:22 < CIA-20> debian-installer: xam * r36794 packages/partman/partman-crypto/BUGS: Update BUGS with information from David
19:22 < waldi> the kernel team don't want to support it for now
19:22 < fabbione> fjp: what about asking Kamion that already did it?
19:22 < waldi> it does not provide any gain above powerpc
19:23 < fjp> I feel applying them only makes sense if that port is going somewhere, but AFAICT there's no consensus on that.
19:23 < fjp> fabbione: For Ubuntu?
19:23 < fabbione> fjp: are we talking about pure64 or just support for ppc64 kernel in d-i?
19:23 < bubulle> if that arch is not a close target, we'd better forget about it now...unless this helps Ubuntu stuff maybe
19:23 < fabbione> that's kind of an important bit
19:23 < fjp> vorlon: Any comments from RM on this?
19:24 < fjp> fabbione: We're talking about supporting ppc64 as arch in control files and such.
19:24 < fabbione> fjp: ok sorry. then forget what i said
19:24 < fabbione> bubulle: no it's nowhere in Ubuntu target
19:24 < bubulle> so, well, I personnally see no point in supporting it now
19:24 < fjp> Adding it in kdb-chooser as separate arch with list of keyboard arches supported.
19:25 < fjp> There is consensus about going forward with freebsd, right?
19:26 < CIA-20> debian-installer: xam * r36795 packages/partman/partman-crypto/debian/ (changelog control): Add Depends on loop-aes-modules (provided by loop-aes-$KVERS-di)
19:26 < bubulle> fjp: trying to get aurel32 in
19:26 < fjp> Deep silence...
19:26 < joeyh> I'm glad to see people working on it, porting to a different os will point out bad assumptions etc
19:26 < joeyh> s/os/kernel
19:27 < fjp> Did you see their new wiki?
19:27 < bubulle> fjp: will be possible to talk about this with aurel32 at debconf imho
19:27 < joeyh> n
19:27 < makx> fjp: link?
19:27 < bubulle> anyway, last topic
19:27 -!- bubulle changed the topic of #debian-boot to: D-I Meeting in progress. Topic: (fjp) Combined i386/amd64 install images (http://lists.debian.org/debian-boot/2006/04/msg00389.html) (5mins)
19:27 < fjp> http://wiki.debian.org/Debian_GNU/kFreeBSD/Debian-Installer
19:28 < bubulle> (/me feels tired and has someone behind his back who's waiting..:-))
19:28 < fjp> There was this request: http://lists.debian.org/debian-boot/2006/04/msg00389.html
19:28 < bubulle> I haven't seen any rationale
19:28 < fjp> Wondering if that is something we want to get involved in.
19:29 < bubulle> I guess this is meant to have optimised install for users who often have no clue that i386!=amd64
19:29 < fjp> It seems fairly invasive and likely to complicate maintenance.
19:29  * bubulle agrees
19:29 < fjp> Also, it will kill netinst
19:29 < joeyh> what about the ones who don't know that ia64 != amd64? :-P
19:29 < waldi> fjp: why?
19:29 < pere> bubulle: well, it would make it easier for me at work, with one cd to install any x86 machine.
19:30 < fjp> waldi: Extra kernel => size increase
19:30 < bubulle> I think that this is not a reasoinable target for etch
19:30 < fjp> For full CD it may kill tasks for the same reason
19:30 < bubulle> we have to remember that we need to pace things down....
19:31 < joeyh> it also needs a full set of amd64 debs
19:31 < joeyh> so it nearly doubles CD size for CDs with debs
19:31 < fjp> I'm inclined to reject it for the Etch timeframe.
19:31 < bubulle> fjp: seconded
19:32 < bubulle> OK, this seems to conclude the formal meeting
19:32 < pere> what about accepting patches to handle it, but not make such cds by default?
19:32 < pere> that way CDDs could make such CDs if they want to.
19:32 < bubulle> thanks to all people who attended. This was a really interesting meeting...and I already fear writing down the minutes..:-)
17:59 -!- bubulle changed the topic of #debian-boot to: D-I Meeting in progress. Topic:(waldi|fjp) New busybox: config needs check (5mins)