Log from the Debian Installer team meeting of March 30th, 2009, 20:00UTC
------------------------------------------------------------------------

People who speak below:
 bubulle      : Christian Perrier
 franklin     : Franklin Piat
 joeyh        : Joey Hess
 luk_sambaxp  : Luk Claes
 NCommander   : Michael Casadevall
 otavio       : Otavio Salvador
 wart         : Wartan Hachaturow
 Yoe          : Wouter Verhelst
 youpi        : Samuel Thibault
 zumbi        : Hector Oron
	   
	   
Nicknames mentioned during the meeting though these people were
not attending:

rmh             : Robert Millan
aurel32         : Aurélien Jarno
ag-             : Aurélien Gérôme

Hours below are UTC +0200:

22:56 < bubulle> OK, let's prepare for the meeting
22:57 -!- bubulle changed the topic of #debian-boot to: Debian Installer team meeting in progress
22:57 < bubulle> everybody who is around, please say hi!
22:57 < wart> hi
22:57 < luk_sambaxp> hi
22:57 < zumbi> hi
22:57 < bubulle> h
22:58 < otavio> hi
22:58 < otavio> oops: hi!
22:58 < otavio> heh
22:58 < bubulle> cjwatson: ?
22:58 < bubulle> Lunar^: ?
22:59  * wart feels it's going to be a short meeting
22:59  * otavio fears it too
23:00 < bubulle> ok, time to begin the meeting
23:00 < bubulle> that could be a short meeting, maybe but we still have things on the agenda
23:00 < bubulle> http://wiki.debian.org/DebianInstaller/Meetings
23:00 < NCommander> hi
23:00 < bubulle> first is continuing going through the release goals list:
23:00 < bubulle> http://wiki.debian.org/DebianInstaller/SqueezeGoals
23:01 < bubulle> we sorted things down to the "To be discussed" section of that page
23:01 < bubulle> so, now we need to go through that section and decide what to do with various items there
23:01 < bubulle> So, let's go
23:01 < bubulle> Add PlayStation 3 support zumbi: see Bug#514055
23:02 < bubulle> that should be an easy one as zumbi is around
23:02 < zumbi> well, wart is the man
23:02 < bubulle> wart: do you confirm?
23:02 < Yoe> wart: just rand the script
23:02 < wart> bubulle: PS3? Well, yes.
23:02 < bubulle> joeyh: around, by the way? :-)
23:03 < joeyh> yeah, thought I'd swing by
23:03 < bubulle> hey, glad to have you around!
23:03 < Yoe> oh, eh, meeting? Mm, might stick around then
23:03 < otavio> joeyh: wow be welcome :-)
23:03 < bubulle> anyway, PS3 support....
23:03 < otavio> I think PS3 is a good thing to have; specially if we can make it without many hacks to support it
23:03 < zumbi> i can help and support wart as well as other cell related people
23:03 < bubulle> as wart seems motivated by this, I propose moving it to "Other goal" with wart's name in it
23:04 < wart> bubulle: It's not my top priority, though, so if anybody else volunteers, I will be happy to help
23:04 < bubulle> ok, wart+zumbi
23:04 < bubulle> yeah sure
23:04 < NCommander> wart, I've done some work on Ubuntu PS3, so I have some interest (no PS3 ATM though)
23:04 < bubulle> havig names will help (imho) in the future to track the advance of these release goals during meetings
23:04 < wart> bubulle: sure
23:04 < otavio> wart: maybe you might coordinate zumbi and let him with this one?
23:04 < otavio> zumbi: ??
23:04 < bubulle> otavio: ok to move this to "other goals"?
23:05 < Yoe> it does require more than d-i support, though; AFAIK there is no PS3 bootloader currently
23:05 < otavio> bubulle: no problem for me
23:05 < Yoe> is that a big issue, or can that be ignored for the time being?
23:05 < wart> Yes, that's a bootloader job mostly.
23:05 < Yoe> (at least, no PS3 bootloader is packaged)
23:05 < NCommander> Yoe, there is kboot-ps3 package in existence, but its not very pretty.
23:05 < otavio> Yoe: yes, this is what zumbi and wart were discussing earlier today
23:05 < bubulle> Yoe: If I read correctly zumbi and wart were talking about BL support before the meeting
23:05 < Yoe> ah, okay, np then
23:05 < wart> d-i support is, like, 1% of the task.
23:05 < bubulle> ok, done for this one
23:05 < Yoe> okay. Just thought I'd mention it, in case it was overlooked
23:06 < bubulle> "inish last bits of UdebSupport (udeb transition)"
23:06 < bubulle> Finish, even
23:06 < bubulle> luk_sambaxp: that's your stuff..:)
23:06 < luk_sambaxp> as can be seen on the page I prepared a wiki page with some progress notes
23:07 < otavio> Yoe: no problem; I just meintioned it has already been discussed; :-) Please keep mentioning things :-)
23:07 < bubulle> (http://wiki.debian.org/UdebSupport)
23:07 < luk_sambaxp> the library udebs seem to be finished, at least the ones that are mentioned
23:07 < luk_sambaxp> probably need to have a recheck
23:08 < luk_sambaxp> the support in britney is prepared (aka analysed), though not implemented yet
23:08 < otavio> luk_sambaxp: did you talk with rest of RM team about what ETA to start implementing britney?
23:08 < bubulle> ok, so that's a topic we could move to "major goals" right?
23:08 < bubulle> (main goals, indeed)
23:09 < otavio> bubulle: I think I'd agree; this is a big step to remove a lot of work for both Debian RM and D-I RM.
23:09 < luk_sambaxp> the ordering of the udebs in the menu is done by Depends fields currently (next to the extra header field) which I'm not sure britney and other tools cope well with, but we can have a look once there is some basic support in general
23:09 < bubulle> I see luk is typing...waiting for his last input
23:10 < otavio> luk_sambaxp: no; order is taken by an extra-field; Menu-Item
23:10 < bubulle> joeyh might bring some background on the original reasons for udeb Depends being the source of the menu ordering
23:10 < otavio> luk_sambaxp: but Depends are considered to avoid running postinst before steps has been done
23:10 < bubulle> and whether we can switch to "normal" use of Depends
23:10 < Yoe> I thought the Depends is only used to keep state; i.e., choosing a menu item is actually calling dpkg --configure
23:10 < Yoe> or thereabouts
23:11 < luk_sambaxp> ordering in the menu != choosing from the menu
23:11 < bubulle> aha....all this (include what otavio just said) is what I was not able to explai to luk myself..:)
23:11 < Yoe> yes, that's what I'm saying
23:12 < otavio> luk_sambaxp: the order is done by menu-item
23:12 < luk_sambaxp> yes, in combination with the depends field as you confirmed
23:12 < otavio> luk_sambaxp: it considers needs that depends are satisfied before running postinst of them 
23:13 < bubulle> well hen....move the goal to main goals and tracked by luk (who'll progressively get a clearer picture about all this..:-))
23:13 < otavio> bubulle: yes, please
23:13 < bubulle> Next
23:14 < luk_sambaxp> oh now I get what Yoe was trying to tell
23:14 < CIA-1> debian-installer: otavio * r58314 packages/kernel/linux-kernel-di-i386-2.6/debian/changelog: Fix another wrong version
23:14 < bubulle> "Change "link in /" to "link in /boot"?"
23:14 < bubulle> reading this with luk before the meeting we interpreted this as "get rid of the kernel symlink in /"
23:15 < bubulle> but I have no memory about whan this was added as a goal for lenny (which wasn't achieved)
23:15 < bubulle> and who was pushing for this
23:15 < otavio> bubulle: I fully support it and this was mostly when we required to run bootloaders by hand
23:16 < otavio> bubulle: now it is mostly automated; so no requirement for it anymore
23:16 < otavio> bubulle: so I fully support it
23:17 < bubulle> but what is installing that link?
23:17 < bubulle> is this a d-i job?
23:17 < otavio> bubulle: I don't recall; need to check
23:17 < otavio> bubulle: I can take a look at it
23:18 < bubulle> if that's not done by d-i, then I see no point in keeping such goal for d-i (if this is done by kernel packages for instance)
23:18 < bubulle> OK, then otavio tries to sort this out then we'll decide at next meeting..:)
23:18 < Yoe> I don't think kernel-package will create such a link, though it will update one
23:19 < bubulle> well, let's move on again 
23:19 < bubulle> "Cleaner solution for including libgcc1 when needed for G-I (#373253). (bubulle: Needs to be summarized first?)"
23:19 < otavio> aboot-installer creates this link; flash-kernel handle it if it exists; 
23:20 < bubulle> so there might be some parts where we could clean this out then
23:20 < bubulle> ok
23:20 < bubulle> now move on
23:20 < otavio> bubulle: yes; it looks it is done by linux-image packages
23:20 < otavio> bubulle: this is what I read from postinst
23:20 < bubulle> #372253 is a very big bug report
23:20 < otavio> bubulle: so mostly a bugreport and code cleanup later
23:21 < otavio> bubulle: about /vmlinuz
23:21 < luk_sambaxp> otavio: I guess linux-image packages only update the links when they exist
23:21 < bubulle> about this libgcc1 thing , zinosat (Davide Viti) might remember, maybe
23:21 < otavio> luk_sambaxp: I'll take a more careful look at it, for sure
23:22 < bubulle> this libgcc thing mentions crashes on AMD64 for G-I but that was in an old past....
23:23 < otavio> luk_sambaxp: looks like few packages read this link too; so we need to check if any of them do require it
23:23 < otavio> luk_sambaxp: lilo-installer looks to use it
23:23 < otavio> bubulle: yes; we worked around it adding it byhand
23:23 < otavio> bubulle: I don't recall why it wasn't automatically added
23:24 < bubulle> aha, otavio is maybe volunteering to summarize the bug
23:24 < bubulle> :)
23:24 < bubulle> Lunar^ could be of some help, imho, there
23:24 < bubulle> but we can't nominate ppl without them being around..:-)
23:24 < otavio> bubulle: I can't promise; my free time is very limited nowadays
23:24 < Yoe> fjp sent a message to the bug that he wrote a hack because the etch release was near, and he didn't want do get through the trouble of having to unfreeze gcc so late in the release
23:24 < Yoe> that's 2006-11-29
23:24 < bubulle> So, let's move on and leave that one for the "still to be revisited" section
23:24 < otavio> bubulle: I can try to; but I can take longer then someone else
23:25 < bubulle> otavio: don't
23:25 < bubulle> we have a workaround
23:25 < bubulle> NExt
23:25 < bubulle> "Add t-p-u in debian-installer's build process (luk: is that such a good idea? This is risking to link d-i with packages that could later be REJECTed by the release team)"
23:25 < otavio> Yoe: yes; that is what I was going to say; It is probably a packaging issue of gcc
23:26 < bubulle> aurel32: ^^^ (about #373253)
23:26 < Yoe> (I'll keep reading the bugreport; I know little about the next few items anyway)
23:26 < luk_sambaxp> for t-p-u there are two distinctive periods
23:26 < otavio> luk_sambaxp: it feels risky IMO
23:26 < luk_sambaxp> before the freeze the release team does not really look at it and it mostly only contains testing-security stuff
23:26 < bubulle> otavio: this is also what luk and I were thinking
23:27 < luk_sambaxp> in the freeze it contains packages we rejected or packages that will only be very limited time there and will move to testing anyway
23:27 < otavio> luk_sambaxp: but I think we could have an environment configuration variable to "add t-p-u/p-u to sources.udeb.list"
23:27 < otavio> luk_sambaxp: by env I mean a local var to be set when preparing updates for stable
23:27 < luk_sambaxp> p-u is sensible, though t-p-u does not really make sense IMHO
23:28 < otavio> luk_sambaxp: in rare cases it might be required
23:28 < otavio> luk_sambaxp: and while on it, it should be simples to add both
23:28 < otavio> luk_sambaxp: so it could use local mirror instead of the public one, as we do nowadays
23:28 < otavio> luk_sambaxp: on buildds, I mean
23:28 < bubulle> so move this topic as "Add p-u to debian-installers' build process" to "to be picked up"?
23:29 < bubulle> "Work to pick up" more precisely
23:29 < luk_sambaxp> otavio: ok, sounds good
23:29 < otavio> luk_sambaxp: so it would be the same as we do now, but in a cleaner way
23:29 < luk_sambaxp> yep
23:29 < otavio> bubulle: i can take this one
23:29 < bubulle> ok
23:30 < bubulle> then moved to "wishlist" or "other goals"?
23:30 < otavio> bubulle: I think I'm able to prepare it; not ETA for it but I do it in a free slot near me :P
23:30 < otavio> bubulle: main goal I think
23:30 < otavio> bubulle: this is a simple one
23:30 < Yoe> re: libgcc_s -- all the bug really says is that libgcc_s is now included by way of EXTRAFILES on amd64 and ppc, but that it should instead be done by a proper libgcc_s udeb.
23:30 < bubulle> yep but that makes a lot of main goals for you..:-)
23:30 < bubulle> otavio: ^
23:30 < otavio> bubulle: so:
23:31 < otavio> Please someone take few main goal from me
23:31 < otavio> PLEASE!
23:31 < otavio> heh
23:31 < bubulle> your main goal is to release d-i..:-)
23:32 < bubulle> well, I'd still settle for "main goals" (that's purely semantics)
23:32 < bubulle> move on...
23:32 < bubulle> "partman-crypto: improve entropy handling, add support for keys-on-removable-devices, allow devices to be deallocated [DavidHärdeman]"
23:32 < bubulle> I think all we can do here is move it to "To be picked up"
23:33 < bubulle> "Maybe support partitioning a RAID device; madduck has indicated interest in working on this"
23:34 < bubulle> and madduck is not around, so, well...
23:34 < bubulle> move to "to be picked up"
23:34 < otavio> ack
23:34 < otavio> nice
23:34 < otavio> both are interesting to have but not blockers
23:34 < bubulle> "user-setup: Include some password strength checking code #364526. jfs once offered to implement this"
23:34 < otavio> and we do need someone to take this one
23:34 < Yoe> speaking of partitioning, I ran into issues there with my ever-so-slowly progressing NBD support
23:35 < bubulle> another wishlist with nobody who ever really started some work..:)
23:35 < otavio> bubulle: this one has a lot of code available in bug report
23:35 < otavio> bubulle: yes; there're
23:35 < otavio> bubulle: take a look on the bug
23:35 < Yoe> the issue being that parted does not support 0-size devices. I just checked, but apparently I failed to file a bug on that one, will do so ASAP.
23:35 < bubulle> otavio: yeah, but IIRC that code was not mentioned as very solid
23:35 < otavio> bubulle: but we ended discussing about code duplication; I belive we ought to use the available libraries for it
23:36 < otavio> bubulle: so we'd need someone to catch it and prepare a test image for it; so we can ask for required udebs to be added
23:36 < otavio> bubulle: maybe talk to jfs?
23:37 < bubulle> the main objection was coming from joeyh about reinventing the (cracklib) wheel
23:37 < bubulle> well, in general that seems to be OK to move this in "to be picked" uup
23:38 < bubulle> after all, what we need is someone implementing something and let people comment
23:38 < bubulle> "See DebianInstaller/GUIToDo"
23:39 < bubulle> I did not go through that one.
23:39 < bubulle> Maybe leave it for later
23:39 < bubulle> (http://wiki.debian.org/DebianInstaller/GUIToDo)
23:39 < Yoe> that is quite a bit, indeed
23:40 < otavio> bubulle: ack
23:40 < bubulle> well, there's at least this game idea tha popped up again recently
23:40 < otavio> bubulle: could you ping jfs about it?
23:40 < bubulle> that GuiTodo page should be cleaned
23:40  * bubulle will do it
23:41 < bubulle> Next: "Split the initrd into three"
23:41 < otavio> bubulle: for the GuiTodo I think that Lunar^ being available is mostly a requirement; he does understand it quite well
23:41 < bubulle> ooooooold topic but still relevant maybe
23:41 < otavio> youpi: since you're going to work on initrd merging; could you take this one?
23:41 < youpi> oh, I'd raise the 4th one that was suggested to avoid software speech synthesis being another disk eater
23:42 < youpi> I can see the technical part yes
23:42 < otavio> youpi: dunno if three is really a real need but add support for spliting is
23:42 < youpi> I guess splitting things won't be so easy once it's done
23:42 < otavio> youpi: yes; mklibs might need change
23:42 < Yoe> there was speak of adding another initrd image for non-free driver firmware stuff; perhaps that could be looked at, too?
23:42 < Yoe> or did I see correctly that current d-i has support for non-free firmwares?
23:43 < otavio> Yoe: it does; you load it during load of installer
23:43 < Yoe> right, so then this is probably not as useful as it once might've been
23:44 < bubulle> probably, yes
23:44 < bubulle> there is still that old idea of language initrd but....
23:44 < otavio> Yoe: well; initrd splitability is a requirement to allow extra support without blowing regular images
23:44 < bubulle> ...the page that summarizes it hasn't moved since more than 2 years..and nothing ever started about this
23:44 < otavio> Yoe: accessibility is one of areas that is going to use it
23:45 < Yoe> one area where it might also still be interesting is for tftp installs, so you don't have to carry around floppies or whatnot to get working network once stuff has booted
23:45 < otavio> bubulle: that's why I belive youpi is one of best persons to take it up since he is a real user for it
23:45 < otavio> Yoe: well; once it has been done, we'll start using it in all possible usage scenarios I think
23:45 < Yoe> point
23:46 < otavio> Yoe: but the basis for it need to be done
23:46 < otavio> Yoe: and to be clean
23:46 < otavio> youpi: agree?
23:46 < youpi> yes
23:46 < bubulle> so, we can summarize this to "could be merged with work around accessibility" and then moved to "other goals" or so
23:46 < Yoe> I guess once you have support for two initrds, adding a 3rd (or 4th, or 5th, or whatever) isn't that hard anymore
23:46 < otavio> bubulle: yes
23:46 < bubulle>  and add youpi there..:)
23:46 < bubulle> and youpi says "Youpi!" in French
23:46 < youpi> Yoe: it depends how you load it
23:47 < youpi> whether from syslinux or from the booted system
23:47 < Yoe> youpi: of course.
23:47 < CIA-1> debian-installer: otavio * r58315 packages/kernel/massbuild.versions: Update to current 2.6.29 versions
23:47 < youpi> anyway there shouldn't be blockers, as syslinux does support several initrds already
23:47 < bubulle> Next: "Add bootloader selector [GeertStappers]"
23:47 < Yoe> what's the deal there?
23:47 < bubulle> #413263
23:47 < Yoe> that's another long bug
23:47 < bubulle> I think this is no longer relevant
23:47 < bubulle> if it ever was
23:48 < bubulle> you can already select bootloaders in expert mode
23:48 < zumbi> which bootloaders?
23:48 < Yoe> zumbi: grub vs lilo on x86*
23:48 < CIA-1> debian-installer: otavio * r58316 packages/kernel/massbuild: workaround dch bug #515346, could be reverted once dch is fixed
23:49 < Yoe> and others on other architectures, obviously
23:49 < bubulle> otavio: I propose droping this goal
23:49 < bubulle> that's expert mode job, imho
23:49 < zumbi> but there are mor arches than x86
23:49 < Yoe> bubulle: couldn't agree more.
23:49 < otavio> bubulle: fully agree
23:49 < bubulle> Next: "Integration of http frontend developed by Attilio (DebianInstaller/WebInstaller)?"
23:49 < zumbi> i could take a closer look and ping geert
23:50 < Yoe> zumbi: the grub/lilo situation is fairly non-representative; most architectures have only one bootloader per subarch
23:50 < CIA-1> debian-installer: tbm * r58317 packages/oldsys-preseed/ (debian/changelog oldsys-preseed): Fix syntax error.
23:50 < zumbi> I propose to postpone it
23:50 < bubulle> here we ahave very nice work (web interface) that never made it further
23:50 < zumbi> Yoe: we want petitboot, redboot, uboot,...
23:50 < bubulle> a good candicate for a newbie who would like to start with something...hint hint
23:51 < Yoe> zumbi: well, if you want to look at it, I won't stop you... though it should not be visible in a default install
23:51 < bubulle> newbie: are you here? :-)
23:51 < Yoe> like bubulle said, that should be done in expert mode
23:51 < luk_sambaxp> zumbi: I don't think dummies will want to choose a bootloader...
23:51 < zumbi> that's me 
23:51 < Yoe> I guess I can see a point if you mean that rather than having this implemented in grub-installer, it could be a generic thing
23:52 < otavio> zumbi: I don't belive an "interface" to select it is useful; since it is going to be done in expert mode then an expert is suppose to know about lilo, grab, whatever 
23:52 < CIA-1> debian-installer: tbm packages * r58318 /oldsys-preseed/3.7/: tag 3.7
23:52 < zumbi> Yoe: yes, i just suggest to postpone it to have a closer look and ping geert about it
23:52 < bubulle> OK, about this web interface, all we can do is move it to "to be picked up"
23:52 < Yoe> in fairness, the bugreport doesn't really speak about interfaces
23:52 < bubulle> "Support for installing a server with Xen instances as suggested by Russel Coker at LCA?"
23:52 < Yoe> geert starts off with how he thinks the syntax of a preseed file looks 'strange', and suggests genericizing things
23:53 < otavio> bubulle: yes; you might ping attilio and ask if he could post the patches for someone to take a look at it 
23:53 < otavio> bubulle: if he is able to forward port it, even better
23:53 < Yoe> otavio: how old are those html frontend patches?
23:53 < bubulle> otavio: everything is in http://wiki.debian.org/DebianInstaller/WebInstaller I think
23:53 < otavio> bubulle: but not a requirement; just an diff and a svn point to check against is good
23:54 < otavio> bubulle: oh ok
23:55 < bubulle> OK, another try..
23:55 < CIA-1> debian-installer: otavio * r58319 packages/kernel/linux-modules-di-amd64-2.6/debian/changelog: releasing version 1.19
23:55 < CIA-1> debian-installer: otavio packages * r58320 /kernel/linux-modules-di-amd64-2.6/1.19/: tagging version 1.19
23:55 < CIA-1> debian-installer: otavio * r58321 packages/kernel/linux-modules-di-i386-2.6/debian/changelog: releasing version 1.19
23:55 < bubulle> "Support for installing a server with Xen instances as suggested by Russel Coker at LCA?"
23:55 < CIA-1> debian-installer: otavio packages * r58322 /kernel/linux-modules-di-i386-2.6/1.19/: tagging version 1.19
23:56 < otavio> heh, what Coker has suggested? eheh
23:56 < bubulle> yeah, then we should wait for him to propose an implementation, no? :-)
23:56 < Yoe> is there some more information on what he actually suggested?
23:57 < otavio> It could be nice to ping him and ask for him to propose it in ml so more people can comment
23:57 < bubulle> Yoe: http://etbe.blogspot.com/2007/01/lca-talk.html
23:57 < otavio> Ian can even take it I think but for that he needs more understanding of it 
23:57 < bubulle> ok, will try to remember pinging Russel
23:58 < bubulle> Ah, w're reaching youpi's bay
23:58 < bubulle> baby
23:58 < youpi> :)
23:58 < bubulle> Extend accessibility support - discussion . Preliminary investigation on a speakup+espeakup+sound drivers solution done, see results (SamuelThibault). Full orca screen reading would be nice but would bring a huge lot more deps.
23:58 < Yoe> bubulle: that post doesn't even mention Xen
23:58 < youpi> otavio was precisely working on it during the meeting actually by releasing 1.19 :)
23:58 < bubulle> Yoe: no idea where this entry comes from indeed...if it was there, then it got some approval by fjp at some moment, I'd say)
23:59 < otavio> bubulle: at least i386 and amd64 will have the sound modules available for youpi be able to provide testing images
23:59 < bubulle> youpi: so we move this close to the initrd split stuff, right?
23:59 < youpi> I'm a working prototype of software speech synth, I need patches getting uploaded in libasound & libspeak
23:59 < youpi> now it's mostly the initrd stuff yes
23:59 < youpi> s/I'm/I've
--- Day changed mer avr 22 2009
00:00 < otavio> bubulle: Frans didn't object it but wants it to be done as a "plugin" for regular initrd
00:00 < otavio> bubulle: that's why I suggested youpi to take the spliting poing
00:00 < bubulle> yay
00:00 < otavio> youpi: ack?
00:00 < youpi> yep
00:00 < bubulle> anyway, this is something that's on its way
00:00 < otavio> good
00:00 < otavio> bubulle: so I made youpi life easier adding it to kernel-wedge and kernel udebs
00:00 < bubulle> "Support for the miBoot bootloader as the recommended method to boot OldWorld PowerMac machines. [AurelienGerome]"
00:01 < otavio> bubulle: if we decline later is just a matter of droping it all
00:01 < otavio> aurel32: ??? 
00:01 < zumbi> this one is related to the last one we talked
00:01 < Yoe> I don't think that's feasible right now
00:01 < bubulle> otavio: AurelienGerome != aurel32
00:01 < zumbi> i can ping aurelien gerome
00:01 < youpi> "Gerome"?
00:01 < youpi> right
00:01 < zumbi> ag-
00:01 < wart> Is miboot supported by recent kernels at all?
00:01 < zumbi> Aurelien Gerome = ag-
00:01 < Yoe> ragtime, the machine that until recently did ppc dailies, is an oldworld powermac
00:01 < otavio> oops
00:01 < otavio> heh
00:02 < otavio> aurel32: sorry
00:02 < Yoe> it doesn't boot any recent kernel anymore that I know of
00:02 < Yoe> and I don't think miboot even worked with that kernel anymore
00:02 < bubulle> ah, so that's obsolete, then? :)
00:02 < wart> I think so, yes.
00:02 < CIA-1> debian-installer: otavio * r58323 packages/kernel/linux-kernel-di-amd64-2.6/debian/changelog: releasing version 1.54
00:02 < bubulle> so, dropped
00:02 < Yoe> bubulle: from where I stand, it looks that way, but of course my experience is based on just one apple model
00:02 < Yoe> knowing apple, that might not be entirely representative
00:02 < CIA-1> debian-installer: otavio packages * r58324 /kernel/linux-kernel-di-amd64-2.6/1.54/: tagging version 1.54
00:03 < CIA-1> debian-installer: otavio * r58325 packages/kernel/linux-kernel-di-i386-2.6/debian/changelog: releasing version 1.77
00:03 < bubulle> "Name pxe files release specific so one can easily have for multiple releases on the same tftp server [LukClaes]"
00:03 < otavio> yey! kernel updated to 2.6.29 :-)
00:03 < CIA-1> debian-installer: otavio packages * r58326 /kernel/linux-kernel-di-i386-2.6/1.77/: tagging version 1.77
00:03 < Yoe> (since they are the only ones writing official software for their hardware, they have a tendency to incompatibly change the boot process from time to time...)
00:03 < luk_sambaxp> http://ftp.de.debian.org/debian/dists/lenny/main/installer-i386/current/images/netboot/debian-installer/i386/
00:03 < otavio> luk_sambaxp: wants to take it? I think it is a matter of improving build system
00:04 < otavio> luk_sambaxp: I think you meant it to be done inside of tarball, no?
00:04 < Yoe> bubulle: I'd like to add to that the idea that it might be interesting to have multiarch (i386/amd64) netboot tarballs
00:04 < luk_sambaxp> if you look at that, it uses very common names which is not nice if you want to support multiple versions
00:04 < wart> otavio: I've also just built ppc 2.6.29 udebs.
00:04 < otavio> wart: don't forget to use latest kernel-wedge
00:04 < otavio> wart: it has fixes for squashfs moduels
00:04 < Yoe> I've actually been thinking of looking at that myself at some point, but never got around to investigating where the netboot.tar.gz is built
00:05 < bubulle> that topic could also be left for some newcomer who would be interested in learning mor eabout the build process...
00:05 < wart> otavio: Sure, it just did not build otherwise :) I'll commit things tomorrow.
00:05 < Yoe> where/how
00:05 < otavio> wart: it would be nice if you could also upload the udebs
00:05 < bubulle> w00t, we have a vls_BE team
00:05 < Yoe> bubulle: vls?
00:05 < bubulle> Vlaams
00:05 < Yoe> bubulle: ITYM vla :-)
00:05 < wart> otavio: Okay.
00:05 < otavio> bubulle: luk showed interest to get involved on d-i so it might be nice to him to catch up with the build system
00:06 < otavio> luk_sambaxp: what do you think?
00:06 < otavio> wart: once you do; and it goes through new, please update config in installer and kernel-table
00:06 < luk_sambaxp> right, though I'm not sure we're talking about the same as there is no netboot tarball involved in renaming pxe file, kernel and initrd
00:07 < otavio> luk_sambaxp: humm
00:07 < Yoe> luk_sambaxp: the netboot.tar.gz _contains_ all those files
00:07 < bubulle> ok, then move this to "Other goals" and assign to luk_sambaxp 
00:07 < bubulle> +Yoe
00:07 < otavio> luk_sambaxp: so please explain what you want
00:07 < Yoe> luk_sambaxp: I know we're not 100% talking about the same thing, but it's related
00:07 < luk_sambaxp> I want the archive to not have the common names for the pxe files like at the link I mentioned first ...
00:08 < franklin> bubble: add me too netboot thing
00:08 < franklin> [Hi, BTW]
00:08 < otavio> luk_sambaxp: well but it is part of installer
00:08 < otavio> luk_sambaxp: how you'd like it to look ?
00:08 < Yoe> luk_sambaxp: oh, the 'linux' and 'initrd.gz' files?
00:09 < Yoe> luk_sambaxp: I guess you'd prefer something like 'linux-2.6.29' instead?
00:09 < bubulle> otavio: he's in another meeting so that's hard for him to follow
00:09 < bubulle> or "linux-squeeze" maybe?
00:09 < luk_sambaxp> the latter looks more logical
00:10 < luk_sambaxp> especially when you also take the pxe file itself
00:10 < otavio> luk_sambaxp: humm
00:10 < Yoe> this really is related to what I'm saying
00:10 < luk_sambaxp> ok, even better
00:10 < bubulle> good
00:10 < otavio> luk_sambaxp: so it is really the tarball that needs change
00:10 < zumbi> including the triplet in the name?
00:10 < Yoe> currently you can install the i386 and amd64 version of the installer on the same tftp server,
00:10 < otavio> luk_sambaxp: the building of it
00:10 < Yoe> but the pxelinux.cfg file will only let you pick one
00:10 < bubulle> so linux-squeeze-i386, etc?
00:10 < otavio> Yoe: maybe list move it a directory deeper?
00:11 < Yoe> if the tarball were to introduce another directory level or some such, that could fix it
00:11 < Yoe> though it might be nice if there were also a way to merge pxelinux.cfg snippets, or so
00:11 < zumbi> linux-$DEB_HOST_ARCH_? 
00:11 < luk_sambaxp> Yoe: right
00:11 < Yoe> so that you can say 'boot the installer for sqeeze on amd64' when netbooting, vs 'boot the installer for lenny on i386' or whatnot
00:11 < bubulle> seems that good ideas are floating around already. Good
00:11 < franklin> Yoe: have a look at di-netboot-installer.  It need to be changed, but we still need a tool to build a menu.
00:11 < Yoe> without having to fiddle with config files
00:11  * bubulle stops this or I'll have to summarize everything
00:12 < Yoe> bubulle: heh :-)
00:12 < bubulle> so let's move to the next stuff
00:12 < bubulle> "Make d-i capable to cross compile armel|* firmware images [HectorOron]"
00:12 < bubulle> zumbi: your baby
00:12 < zumbi> :)
00:12 < zumbi> well, +zumbi
00:12 < bubulle> move to "Other goals"?
00:12 < bubulle> or "main"?
00:13 < zumbi> i do not want to block d-i, but it could help on previous topic
00:13 < zumbi> but i will take it as a main goal
00:13 < bubulle> good
00:13 < bubulle> No need to spend more time on this, then..:-)
00:13 < zumbi> i am also building the cross compilers
00:14 < bubulle> Next "Further develop cdebconf for use in the installed system (as replacement for debconf)"
00:14 < bubulle> zumbi: oh sorry I didn't want to interrupt you!
00:14 < bubulle> feel free to add info if you feel like
00:14 < zumbi> fine with me to go next
00:14 < bubulle> joeyh: this one above was your old baby
00:15 < bubulle> luk and I just tried to install cdebconf on a system (mine) but as it currently depends on debconf, that' lead nowhere
00:15 < luk_sambaxp> #328498
00:15 < bubulle> t seems there are still some blockers
00:15 < bubulle> I'm not sure this is still a *d-i* goal or a general one
00:16 < bubulle> luk_sambaxp: ?
00:16 < luk_sambaxp> well are debconf and cdebconf not maintained by d-i people? :-)
00:17 < bubulle> debconf does not list the d-i team as maintainer
00:17 < bubulle> it happens that some folks known (once) as "D-I folks" are listed in Maintainers or Uploaders
00:17 < luk_sambaxp> lol
00:18 < luk_sambaxp> as long as both are maintained, it's up to the maintainers really
00:18 < bubulle> right
00:19 < bubulle> then we can keep this in "To be picked up" in case someone want to invest time in it (that can be joeyh!)
00:19 < bubulle> "Don't forget reinstating translation for grub-installer/grub2_instead_of_grub_legacy and grub-installer/grub_not_mature_on_this_platform"
00:19 < bubulle> otavio or rmh (not here): still needed?
00:20 < bubulle> that's easy to do but i wouldn't like to  reactivate translations for nothing
00:21 < bubulle> ook, everybody seems to be sleeping or bored...
00:21 < luk_sambaxp> lol
00:21 < bubulle> so am I (sleepy!)
00:21 < zumbi> come on
00:21 < Yoe> bubulle: are those templates long?
00:21  * otavio at phone
00:21 < bubulle> Yoe: not short
00:22 < bubulle> and a little bit complicated (technically speaking)
00:22 < Yoe> bubulle: mmm. Well, in any case, I do think grub2 could still use some more testing on some platforms
00:22 < Yoe> though I should also note that I'm not intricately familiar with grub2
00:22 < Yoe> so my word should not be taken at face value :)
00:23 < bubulle> sure but as long as they're here only when grub2 is tested, maybe there's no need to i18n them
00:23 < bubulle> s/when: as long as
00:23 < bubulle> anyway,t hat's more a reminder than a "goal" per se
00:23 < bubulle> Let's keep it in "Other goals" and assign to me
00:23 < Yoe> right, indeed
00:24 < bubulle> LAST LINE!
00:24 < bubulle> "IPv6 support 
00:24 < bubulle> proposed patch for IPv6 support in busybox wget: #395839 
00:24 < bubulle> "
00:24 < Yoe> I doubt that's all that's needed for v6 support
00:24 < Yoe> you'd also need support in the network configuration bits
00:24 < Yoe> not if router advertisement is used, of course, but there are other ways to configure IPv6
00:25 < bubulle> moreover the bug is closed...
00:25 < Yoe> e.g., manual configuration is not yet possible in d-i for v6
00:25 < bubulle> so busybox' wget has IPv6 support
00:25 < bubulle> sure, I don't think that the list was meant to be exhaustive
00:25 < zumbi> busybox network stack i believe is mixed ipv4+ipv6
00:25 < zumbi> for this one emdebian is interested on busybox + has relationship with upstream
00:26 < Yoe> point I'm trying to make, getting IPv6 right is going to be quite some work
00:26 < bubulle> sure
00:26 < Yoe> though also desirable
00:26 < bubulle> is anyone feeling like able to list what would be needed in details?
00:26 < bubulle> that would be a first step...
00:26 < Yoe> - tftp support (thought that's mostly outside the scope of d-i)
00:27 < luk_sambaxp> not during the meeting...
00:27 < Yoe> er, point
00:27 < Yoe> I'll look into it in detail tomorrow
00:27 < Yoe> remind me if you don't hear from me
00:27 < bubulle> Even  I would add this to "To be completed" (new section) 
00:27 < zumbi> i will take a look as well
00:27 < bubulle> and assign to Yoe, yay
00:28 < bubulle> +sumbi
00:28 < bubulle> s/s/z
00:28 < zumbi> good
00:28 < zumbi> :)
00:28 < bubulle> OOOOOOOOOOOOOOOOOOOOOOOOOOOOOK (which is about the noise I made)
00:28 < Yoe> I'm not saying I have time to work at it, but I'm sure willing to look at what needs to be done
00:28 < bubulle> we went through the releas goals list
00:28 < zumbi> Yoe: let's coordinate
00:29 < Yoe> zumbi: sure
00:29 < bubulle> now we need to update the http://wiki.debian.org/DebianInstaller/SqueezeGoals page
00:29  * bubulle tries to prod franklin, justin case..:-)
00:30 < bubulle> (as the main job of someone coordinating stuff is being very careful about not doing anything him|herself
00:30 < franklin> I think I understood what prod mean. I'll have a look tomorow.
00:30 < bubulle> More generally speaking, what I was imagining for our meetings would be going through the goals list during the first part of our regular meetings, what would you think?
00:31 < luk_sambaxp> ok
00:32 < franklin> Sounds sensible. (Do you mean we will start the second part now ;)
00:33 < bubulle> franklin: well, there *is* a second part, see http://wiki.debian.org/DebianInstaller/Meetings
00:33 < bubulle> but I'm afraid that we have no survivors
00:33 < luk_sambaxp> most of it got covered in the previous meeting which still needs the log/minutes
00:34 < bubulle> the log is now linked
00:34 < bubulle> the minutes will be there when luk_sambaxp writes them...
00:34 < luk_sambaxp> lol
00:34 < bubulle> ok, so I think we can shut the meting down then