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

People who speak below:
 bubulle        : Christian Perrier
 cjwatson       : Colin Watson
 elmig		: Migel Figueiredo
 franklin	: Franklin Piat
 luk_		: Luk Claes
 otavio		: Otavio Salvador
 Ryan52		: Ryan Nebur
 waldi		: Bastian Blank
 wart		: Wartan Hachaturow
 xoswald	: Xavier Oswald
 youpi		: Samuel Thibault


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

fjp		: Frans Pop
joeyh		: Joey Hess

Hours below are UTC +0200:

22:04 < luk_> cjwatson dondelelcaro franklin Ganneff luk_ Lunar^ mvz OdyX otavio Ryan52 Sledge tbm vorlon xoswald youpi bubulle: meeting now
22:04 < youpi> yep
22:04 < Sledge> gah, crap
22:04 < Ganneff> me? what me?
22:04 < xoswald> hola
22:04  * Sledge is in a meeting elsewhere
22:04  * OdyX is mainly reading.
22:04 < luk_> Ganneff: I guess you said something in the previous meeting :-)
22:04 < Ganneff> oh. my fault then.
22:05 < luk_> otavio: ping
22:05 < franklin> hola
22:06 < luk_> I guess we should start by mentioning our name for the records?
22:06 < luk_> Luk Claes
22:07 < franklin> Franklin Piat
22:07  * xoswald Xavier Oswald
22:07  * Ryan52 says hi
22:07  * Ryan52 is Ryan Niebur
22:07 < cjwatson> sorry I'm late, had to change the baby
22:07 < cjwatson> Colin Watson
22:08 < luk_> who is leading the meeting till bubulle is back?
22:08 < youpi> Samuel Thibault here
22:08 < otavio> sorry
22:08 < otavio> I was in a meeting here in the company
22:08 < youpi> np
22:09 < otavio> luk_: want to do that?
22:09 < otavio> otherwise I do
22:09 < luk_> please do
22:10 < otavio> Ok ...
22:10 -!- otavio changed the topic of #debian-boot to: Debian Installer Meeting in progress
22:11 < otavio> First ...
22:11 < otavio> I belive the main motivation of this meeting is to try to organize how we'll be doing  the squeeze cycle 
22:12 < otavio> and also what is in progress or needing someone to take care of
22:12 < otavio> Basically, a discussion of Squeeze Goals
22:12 < luk_> indeed, sounds about right
22:12 < otavio> People can take a look at the current draft at http://wiki.debian.org/DebianInstaller/SqueezeGoals
22:13 < otavio> Another thing is the organization of daily builds
22:13 < otavio> luk_: wants to start talking about it?
22:13 < luk_> sure
22:13 < otavio> luk_: I belive it is a short topic so
22:13 < otavio> luk_: please go ahead 
22:14 < luk_> there was a meeting at Fosdem (where I was not present)
22:14 < luk_> where basically there was a proposal to have them more centralised on Debian infrastructure (buildds)
22:14 < luk_> so I thought of testing it with some missing already
22:15 < luk_> currently the alpha, mips and mipsel ones are already building in a separate chroot on the buildds
22:15 < cjwatson> how are chroot updates handled?
22:15 < cjwatson> many of the daily build problems we have are due to out-of-date chroots
22:15 < luk_> currently manually, though I wanted to test auto-upgrades
22:16 < luk_> for amd64 I'm currently testing the automatic updates and they seem to work ok
22:16 < cjwatson> if they were auto-building in automatically updated chroots on buildds, that'd be fantastic
22:16 < luk_> right, that's what I'm after
22:16 < otavio> indeed
22:16 < otavio> and there're any kind of chroot backup planned?
22:17 < luk_> next thing would be to centralise the logs and images on some central d-i account (/srv/debian-installer or similar) on some Debian machine IMHO
22:17 < otavio> if we auto-update we could have a fallback chroot
22:17 < otavio> and if the build fails on the first, try the fallback  
22:17 < luk_> no, chroot backup is not planned, though setting up the chroot could certainly be more automated
22:18 < luk_> what do people think of a central d-i account (including webpages etc)?
22:18 < otavio> luk_: well; if it is fully automated the backup shouldn't matter since we could just do it again for all builds
22:18 < otavio> luk_: I belive this would help us to avoid forgetting things and make the whole management easier
22:19 < luk_> right, I don't think the backup is needed, but automating the chroot creating and initialisation would be nice
22:19 < luk_> and is certainly possible AFAICS
22:19 < otavio> luk_: sure
22:19 < otavio> that's great
22:20 < otavio> when you talk about a central d-i account you mean for what? buildds? scripts? what?
22:20  * bubulle is 1/4 around....mostly in read-only mode
22:20 < otavio> bubulle: once you're up to date, please take up the chair :-)
22:20 < luk_> the central d-i account would be for the daily images/logs, status webpages etc
22:21 < otavio> so basically it would run the scripts to generate the testing status, report the image logs and testing of images using digrees?
22:21 < luk_> anything d-i related that is now spread over developer's accounts which should not get lost when the developer would leave Debian
22:21 < otavio> yes; that makes sense
22:21 < Ganneff> it would be what http://release.d.o  or ftp-master.d.o is - i tosunds like it
22:21 < otavio> indeed
22:21 < otavio> Ganneff: agreed
22:22 < bubulle> luk_: that could include the l10n sync stuff that's running under my account on alioth, too
22:22 < luk_> so, does anyone object if I ask DSA to create such a central d-i account/space?
22:22 < otavio> bubulle: oh! you'll stop to have the highest commit rate in the whole world ;P
22:22 < luk_> bubulle: yes
22:22 < cjwatson> who should have sudo access to such an account?
22:23 < cjwatson> the whole d-i team (intersected with people who have Debian shell access, I assume that's only fully-fledged DDs), or some subset?
22:23 < bubulle> cjwatson: I'd say a subset
22:23 < otavio> cjwatson: imo this should be by need
22:23 < luk_> indeed, I would go by need
22:23 < cjwatson> still, anything >1 is better than the current situation
22:23 < otavio> cjwatson: so the subset would be make growing depending on the need
22:24 < otavio> cjwatson: sure; currently I belive that I, bubule and luk_ could be a good starting group
22:24 < luk_> it would be good to know an initial list of people that need access
22:24 < otavio> cjwatson: luk_ could handle the script migration that dato is offering help to do
22:24 < otavio> luk_: or if you prefer dato itself  
22:25 < luk_> some parts of the script migration dato is doing will happen on release anyway, though when it makes more sense to have it for d-i, then indeed it's better to place it on a central d-i spot
22:26 < otavio> and which machine this account would run?
22:26 < luk_> I'll ask DSA what they propose
22:26 < otavio> what kind of access it would have? Can it have a read access to the ftp-master projectb database?
22:26 < luk_> is there a special need for the l10 sync stuff
22:27 < luk_> bubulle: ^^
22:27 < otavio> if it has, then the current idea of moving the status of udebs to release could be change to have it on the central account
22:27 < luk_> otavio: yes, certainly on a copy
22:28 < otavio> luk_: the only problem with that is the delay to get up to date; specially near of release this is quite boring 
22:28 < luk_> the status of udebs will be on release anyway as the Release Team will have similar info anyway
22:28 < otavio> luk_: so is quite difficult to have a global view of what is going on
22:28 < luk_> s/have/need/
22:28 < otavio> luk_: but if release has that up to date then is better to have it there
22:28 < otavio> Ganneff: ^
22:29 < Ganneff> otavio: anyone has read access to projectb on merkel
22:29 < otavio> Ganneff: and how long it takes to get up to date?
22:29 < luk_> we will work on the udeb migration anyway which would solve already a lot of the need for a status page for d-i I guess
22:29 < otavio> Ganneff: after ftp-master run?
22:29 < Ganneff> otavio: its shortly after dinstall
22:29 < otavio> luk_: hopefully
22:29 < Ganneff> otavio: its what all of QA uses, so not way outdated
22:30 < otavio> Ganneff: ok
22:30 < luk_> otavio: but I'll ask DSA where to best put it
22:31 < otavio> luk_: ok
22:31 < luk_> last thing I wanted to ask about the daily builds:
22:31 < otavio> sure, go ahead
22:31 < luk_> currently if something changes we need to update in 3 different repositories
22:31 < luk_> d-i, debian-cd and webwml
22:32 < luk_> it's true that they are not completely the same info or should be completely in sync
22:32 < cjwatson> if they weren't in per-developer accounts, it wouldn't really matter
22:32 < otavio> any suggestion how to improve it?
22:32 < cjwatson> if it settled down to ~d-i/<architecture>/images/ or whatever then we could just leave it that way
22:32 < luk_> though I would like to look into having a central place to update the info of the daily builds
22:33 < cjwatson> daily builds usually only need to be updated when the responsibility for them transfers between developers
22:33 < luk_> cjwatson: right
22:33 < cjwatson> and so it seems sufficient to solve that problem
22:33 < luk_> cjwatson: though on webwml and debian-cd
22:33 < luk_> there is also the enabling/disabling of arches
22:33 < otavio> luk_: i agree with cjwatson ... having it centralized reduces the problem a lo
22:33 < otavio> lot
22:34 < cjwatson> well, yeah, but that's fairly rare - I wouldn't be too worried about that
22:34 < luk_> ok, I'll concentrate on centralising
22:34 < cjwatson> I don't think it's worth inventing complicated infrastructure to centralise that information (given that debian-cd is a package in the archive, etc.)
22:34 < luk_> right
22:34 < luk_> lets move on to the next topic :-)
22:34 < otavio> luk_: I fully agree about your concern and I also think we can try to reduce that requirement but centralizing the account should fix most of this boring tasks
22:35 < luk_> ack
22:35 < otavio> luk_: and the ones that remain will be rare enough to not bore too much
22:35 < bubulle> OK, I'm now completely around
22:35 < otavio> bubulle: wow
22:35  * otavio waves to bubulle 
22:35 < bubulle> luk_: special need for l10n sync?
22:35 < luk_> bubulle: does the l10n sync need special access to somewhere?
22:36 < cjwatson> svn
22:36 < otavio> bubulle: yes; like space, installed packages, anything like that
22:36 < bubulle> commit access to SVN
22:36 < bubulle> space is about the size of a full checkout of d-I SVN
22:36 < otavio> bubulle: we could set up an account to be used by this account when commiting
22:36 < bubulle> and ability to push files back to D-I www on Alioth
22:37 < otavio> bubulle: like Debian Installer Commit Agent or something like that
22:37 < bubulle> yes
22:37  * bubulle waves bye to his commit rank...:)
22:37 < otavio> yeah! this was unfare
22:37 < otavio> hhahah
22:37 < bubulle> no special tools except standard gettext stuff
22:37 < luk_> ok, the alioth push back is something to look into, though I guess a cronjob on alioth would be fine?
22:38 < bubulle> yes
22:38 < otavio> luk_: if it has access to ssh this doesn't matter too much since we could use ssh-keys to automate it
22:38 < luk_> right as the svn user will also exist on alioth
22:38 < otavio> luk_: so central d-i could push files using scp to d-i account
22:38 < otavio> luk_: yes
22:39 < otavio> luk_: and he will be part of d-i project
22:39 < luk_> ok, lets move on
22:39 < otavio> ok
22:39 < bubulle> luk_: related to l10n-sync, I have a robot that notifies translators about changed files
22:39 < bubulle> name is "websec" (script in D-I SVN)
22:39 < otavio> bubulle: are you going to take the charing?
22:39 < luk_> right, mail should not be a problem AFAICS
22:40 < bubulle> otavio: hmmm, I'll try but need to put my mind back in Debian mode....something not really easy these days, except for recurrent tasks
22:40 < otavio> heh
22:40 < bubulle> so, out other main topic was either Squeeze release goals or "how do we organize work"
22:41 < bubulle> otavio: when do you think we could try to release a first beta?
22:41 < otavio> bubulle: I think we should talk about how we will do and a draft of plans for betas and like
22:41 < otavio> Ok 
22:42 < otavio> So ...
22:42 < otavio> There're few things about this cycle I'd like to talk and if noone objects I'd like to test how it goes
22:42 < otavio> First is to start uploading installer main package every  two weeks or so
22:43 < otavio> That has very important reasons, at least for my POV 
22:43 < otavio> Those are:
22:43 < otavio>  - spot build failures more fastly
22:43 < otavio>  - make possible to have squeeze installer more up to date (even it doesn't work until betas or like) 
22:44 < cjwatson> amen
22:44 < otavio> heh
22:44 < luk_> good idea AFAICS
22:44 < bubulle> cjwatson: means you agree?
22:44 < otavio>  - we could upload installer manual too to give more up to date docs
22:45 < otavio> Even if installer manual is not translated, this can bring up more attenting to what is done
22:45 < otavio> and what is míssing
22:45 < otavio> Besides that
22:45 < cjwatson> bubulle: yes
22:45 < otavio> I'd like to have a mouthly mass upload of translation updates
22:45 < bubulle> I think it's OK to upload the d-i manual without the l10n during the development cycle
22:46 < cjwatson> I'm not especially keen on a monthly mass upload without some care
22:46 < cjwatson> perhaps only for packages that tend not to be uploaded any other way
22:46 < otavio> cjwatson: modules with other changes needs to be decided  
22:46 < bubulle> why not "just" improve the buildscript and use it to build a special image with "everything up to date"?
22:47 < bubulle> for l10n purposes, that would be enough, imho
22:47 < otavio> bubulle: because it doesn't try the other installation methods
22:47 < otavio> bubulle: and also because it doesn't give to our regular users the feel of what is being done 
22:48 < luk_> maybe both should be considered?
22:48 < otavio> luk_: sure
22:48 < otavio> cjwatson: so do you object about the translatino uploads?
22:48 < luk_> improving the build script for l10n related things and have more regular installer uploads to be able to test them more easily 'live'
22:48 < cjwatson> otavio: I think the uploader should take care rather than it being an automatic thing
22:48 < otavio> One thing I belive we ought to change is how long something stay on installer svn before it is uploaded 
22:49 < otavio> cjwatson: even if it is only translatino updates?
22:49 < bubulle> otavio: well, we had accidents in the past with translation updates..:-)
22:49 < luk_> right, I would rather not encourage automatic uploads
22:49  * bubulle wouldn't like an upload of a 250MB package because of a giant Danish translation
22:50 < cjwatson> otavio: if it's only translation updates and nothing else, that's fine; I meant in the case of other things already being pending upload
22:50 < otavio> cjwatson: I mean translation-only
22:50 < bubulle> maybe a semi-automatic thing where someone would just have to "push a button" to trigger an automated upload?
22:50 < otavio> bubulle: well but until we upload we will take longer to notice it
22:50 < otavio> bubulle: can be
22:51 < otavio> bubulle: no problem
22:51 < otavio> bubulle: what I want to change is that we mostly do that just for releasing
22:51 < bubulle> also having "something" that warns us about a longstanding pending thing in SVN (besides l10n) would be a good thing to have
22:52 < otavio> Well 
22:52 < otavio> That are the more radical changes I was going to propose and I'd like to hear from you all what you think
22:52 < bubulle> you heared, I guess? :-)
22:53 < luk_> I think more beta releases which include the whole of testing would be a good idea btw
22:53 < bubulle> I think that the general feeling can be summarized to "why not but let's be very careful"
22:53 < otavio> Ok; let's summarise it then:
22:53 < luk_> not every 2 weeks though :-)
22:54 < otavio>  - debian-installer uploads: every two weeks (this is not going to be a release, just a snapshot)
22:54 < bubulle> uploading the d-i package itself very often is not the most frightening
22:54 < otavio>  - installation-manual: uploaded together (to bring an idea of what is documented and what is missing) 
22:55 < cjwatson> I think we're basically agreed; let's move on
22:55 < otavio>  - packages: translation-only ones could be uploaded in mounth basis to avoid a big backlog 
22:55 < franklin> Having few beta that are actually named "beta 1" ~ "beta 3" probably helps getting beta-testers attention.
22:56 < otavio> franklin: I agree
22:56 < youpi> I need to have people from a11y testing them more
22:56 < otavio> and that's why I want us to have alpha releases 
22:56 < bubulle> so I feel like it would be good to have a rough idea of "when the first beta" (and what to put in it)?
22:56 < youpi> there have been a few bug reports _after_ the release which are only annoying so not worth a fix
22:56 < franklin> otavio: ack.
22:56 < youpi> they could have been spotted before if people only tested them :)
22:57 < luk_> right, the general beta releases is hopefully a step in getting more testing
22:57 < bubulle> OK...shall we go through http://wiki.debian.org/DebianInstaller/SqueezeGoals?
22:57 < otavio> If all people around buys the idea, I'd like to have a alpha 1 at begin of May  
22:57 < cjwatson> otavio: as long as this doesn't involve a significant slowdown in development
22:58 < franklin> Is it ok if I update https://wiki.debian.org/Schedule with teh planning?
22:58 < otavio> cjwatson: I think this can be avoided
22:58 < otavio> cjwatson: specially if we have things on unstable more ofthenly
22:58 < bubulle> cjwatson: I think we need to decide that the RM gives the release preparation process by branching
22:58 < otavio> cjwatson: so the every two weeks d-i upload will be a snapshot of it
22:59 < luk_> right, I would also propose branching when preparing (alpha, beta...) releases
22:59 < otavio> bubulle: you mean we always use a branch for it?
22:59 < cjwatson> branching> yes please
22:59 < bubulle> yep, something like that
22:59 < wart> branches> +1
22:59 < otavio> bubulle: like d-i/branches/squeeze/alpha1
22:59 < luk_> otavio: yes
22:59 < otavio> np to me
22:59 < bubulle> if that involves a switch to git to make things easier...then git we go..:-)
23:00 < otavio> bubulle: cjwatson would kill us
23:00 < bubulle> (as long as I don't have to do the work)
23:00 < otavio> bubulle: but I'd love
23:00 < wart> bubulle: That'd be hard.
23:00 < cjwatson> let's switch to bzr instead
23:00 < youpi> let's switch to arch instead
23:00 < luk_> bzr is sloooow
23:00 < otavio> cjwatson: I would kill you
23:00 < cjwatson> now, take your reaction to that, and mirror it
23:00 < otavio> heh
23:00 < cjwatson> at least we are used to svn and we know it basically works for us
23:00 < bubulle> ok, VCS topic is over..:-)
23:00 < luk_> anyway, I won't object any VCS
23:00 < otavio> cjwatson: that is the problem, basically
23:00 < otavio> ok
23:01 < otavio> let's move on
23:01 < otavio> so 
23:01 < bubulle> otavio: do you agree that we need to clean out the SqueezeGoals page?
23:01 < otavio> Current SVN has already enough material for an Alpha 1 IMO 
23:01  * bubulle would propose to go through it but that will be a long process
23:01 < otavio> bubulle: yeah
23:01 < bubulle> yes, alpha 1 should be more or less "what we have plus kernel updated"
23:02 < cjwatson> how are we doing with 2.6.29?
23:02 < otavio> So my idea is to start to look at modules and see what could be uploaded
23:02 < otavio> cjwatson: I'll be able to look at it on Wed
23:02 < otavio> cjwatson: but AFAIK mostly done
23:03 < bubulle> so, focus on kernel stuff, then when kernel stuff is ready, give the go for the alpha-1, branch and start the release process?
23:03 < otavio> bubulle: yes
23:03 < bubulle> sold
23:03  * bubulle not sure that "early May" is realistic but never mind..:)
23:03 < otavio> my idea is to, after having kernel updated and few days of testing
23:03 < cjwatson> maybe I can squeeze in persistent device naming before that
23:03 < otavio> upload d-i
23:03 < cjwatson> ?
23:03 < otavio> cjwatson: if you're up to, ok
23:04 < otavio> cjwatson: that would be an awesome thing
23:04  * wart won't be able to work on 2.6.29/powerpc until mid-april, short vacation next week.
23:04 < wart> (if anybody cares)
23:04  * bubulle was about to mention persitent naming as top release goal, yes
23:04 < otavio> wart: yes, we care
23:04 < cjwatson> I implemented partman/mount_style recently in Ubuntu which I think should be able to cover most of the complaints people have (i.e. "how can I turn this thing off?")
23:04 < otavio> wart: but we won't delay due that
23:04 < otavio> wart: is a alpha release
23:04 < otavio> wart: but you'll have time for it once you're back I think
23:05 < wart> otavio: Sure thing, I don't think there will be too much problems, powerpc is a gentle arch kernel-wise :)
23:05 < otavio> wart: hheh
23:05 < otavio> So all agreed?
23:05 < bubulle> wart: would be nice to record yourself on http://wiki.debian.org/DebianInstaller/Tasks under ppc "porter"..:)
23:05 < luk_> otavio: yep
23:06 < otavio> good
23:06 < bubulle> otavio: yes
23:06 < otavio> let's move on 
23:06 < otavio> bubulle: ? :-)
23:06 < bubulle> otavio: yes, agreed
23:06 < bubulle> OK, next release goal mentioned is "includes supplemental repository support for udebs started by Bastian Blank; work parked in http://people.debian.org/~waldi"
23:06 < bubulle> waldi: around?
23:06 < luk_> that site is not available, is it?
23:07 < bubulle> luk_: oh, yes
23:07 < otavio> I think this is quite important to have; specially for overlays (or blends nowadays) 
23:07 < bubulle> very well parked, indeed..:-)
23:07 < otavio> hah
23:07 < cjwatson> that's the libd-i work to permit multiple Packages files?
23:07 < otavio> cjwatson: yes
23:07 < otavio> cjwatson: but afaik it also involves anna
23:08 < bubulle> we already had this as a Lenny RG, indeed
23:08 < waldi> oh, this is an old item
23:08 < cjwatson> otavio: well, yes
23:08 < otavio> waldi: are you still willing to work on that?
23:08 < luk_> waldi: what's the status?
23:08 < otavio> waldi: this is an important feature
23:08 < waldi> yeah. i have the code, but the dep resolver is missing on the new data structures
23:09 < bubulle> so maybe move out of "Major issues" to "Wished features"?
23:09 < bubulle> We'll see...
23:10 < bubulle> let's move down the messy list
23:10 < bubulle> "Find replacement for the ISC DHCP client in d-i"
23:10 < bubulle> old topic, again
23:10 < waldi> udhcpc?
23:10 < otavio> IMO we should move to udhpc
23:10 < waldi> is integrated into the busybox source by now
23:10 < cjwatson> the wiki page makes it look like something of a bikeshed
23:10 < otavio> waldi: agreed
23:10 < bubulle> this is an option mentioned in the wiki page, yes
23:10 < cjwatson> is there in fact more agreement than the wiki page suggests?
23:11 < cjwatson> I would hate to be interminably cycling around among DHCP clients :-)
23:11 < otavio> cjwatson: if we do it early, it shouldn't hurt too much
23:11 < cjwatson> of course something in busybox has a space advantage
23:11 < otavio> cjwatson: since we can spot any regression on the way
23:11 < bubulle> that's a good candidate for "we need a volunteer to work on this and propose options"
23:12 < luk_> I think it's a good idea to try if udhcpc would fit the needs as a start
23:12 < bubulle> with advantage given to busybox integrated stuff
23:12 < otavio> waldi: are you able to take a look and see if it lacks any required feature? 
23:12  * waldi forgot one point: libd-i may need an abiname bump ...
23:12 < waldi> otavio: sure
23:12 < bubulle> OK, move on
23:13 < bubulle> "Switch from console-data to console-setup. Status page: ../ConsoleSetupSwitch"
23:13 < otavio> waldi: perfect; can we put you on that task?
23:13 < youpi> I'm working on it
23:13 < youpi> though I've been busy recently :)
23:13 < bubulle> youpi: I was about to nominate you..:)
23:13 < otavio> heh
23:13 < cjwatson> youpi: you were doing the translation work, weren't you?>
23:13 < cjwatson> youpi: how far did you get with that?
23:13 < otavio> what is the missing things yet?
23:13 < waldi> otavio: that means work, but yes
23:13 < youpi> cjwatson: I know how to do it, just didn't take the time to implement :)
23:14 < otavio> waldi: thanks a lot!
23:14 < otavio> bubulle: place waldi on that ;-)
23:14 < bubulle> otavio: already done..:)
23:14 < otavio> bubulle: since you're editing the webpage heh
23:14 < otavio> bubulle: ok
23:14 < cjwatson> youpi: I can certainly help if you need it
23:14 < bubulle> (mentally, I mean)
23:14 < youpi> there are also a few things that can be inherited from xkb-data instead of hardcoding them in the config script
23:14  * bubulle was thinking of a youpi+cjwatson+anton as triumvirate for console-setup switch
23:14 < youpi> I have submitted a patch some time ago, but didn't receive comments
23:15 < otavio> youpi: please resend it
23:15 < bubulle> youpi: patch to xkb-data?
23:15 < bubulle> ah, no, patch to c-s, I think
23:15 < youpi> ah, that was in the middle of Re: console-setup fetching data from xkb-data
23:15 < cjwatson> youpi: can you mail me directions to the thread and I'll look? I must have missed it
23:15 < bubulle> I guess that not receiving comments means that your patch is OK..
23:15 < cjwatson> cjwatson@debian.org
23:16 < otavio> youpi: it is better to starta new thread for it
23:16 < youpi> otavio: sure, I'll do it
23:16 < otavio> youpi: so people can comment on that
23:16 < bubulle> anyway, I'm confident that we can make it, this time (c-s switch)
23:16 < otavio> youpi: and tag it as [RFC] heh
23:16 < youpi> :)
23:16 < otavio> youpi, cjwatson: any guess if it fits alpha1?
23:17 < cjwatson> otavio: a bit risky, I think
23:17 < bubulle> agreed
23:17 < youpi> maybe, yes
23:17 < bubulle> maybe we can switch one language to c-s as proposed on the status page
23:17 < otavio> bubulle: humm
23:17 < otavio> bubulle: English? heh
23:18 < cjwatson> bubulle: mm, I'd rather not on the whole
23:18 < bubulle> actually, this is IIRC already done for cyrillic languages (without the udebs)
23:18 < cjwatson> I think it would be pretty confusing
23:18 < otavio> cjwatson: ack
23:18 < bubulle> fine
23:18 < bubulle> move on
23:18 < bubulle> "Improve support for Intel-based Apple MacBook systems; current support is a bit of a kludge and needs restructuring (cjwatson has patches)"
23:18 < otavio> cjwatson: what patches you have for it?
23:19 < cjwatson> I think I do still have a few patches I can stick into svn, fairly miscellaneous corrections
23:19 < cjwatson> I think we should use the gptsync patch to parted from Ubuntu
23:19 < cjwatson> Matthew Garrett wrote it originally; it makes life a lot easier
23:19 < otavio> cjwatson: Is any reason to not merge it upstream?
23:20 < cjwatson> no except that I die of old age any time I try to merge a parted patch upstream :-(
23:20 < otavio> cjwatson: ok; I'll take a look on that
23:20 < otavio> cjwatson: and will check the ext4 stuff too 
23:20 < bubulle> that topic seems covered now
23:20 < cjwatson> I can send it to parted-devel but I have no time to write a test suite for it and less time to figure out how it could even feasibly be tested cross-platform
23:21 < cjwatson> (the patch looks at DMI to figure out whether it's running on an Apple system or not)
23:21 < cjwatson> (and has to do that because Apple broke the GPT spec)
23:21 < otavio> cjwatson: you could send a mail to the ml and explain why it is required and like 
23:21  * cjwatson nods
23:21 < otavio> cjwatson: so people can even think in alternative solutions
23:21 < otavio> cjwatson: that should work
23:21 < bubulle> Another dusty item inherited from lennyGoals: Make grub installer show a list of disks to install on if more than one disk controller is detected; lilo already has code for selecting a target which might be nice to use as well."
23:22 < otavio> cjwatson: and we're in meanwhile of 1.9 release
23:22 < cjwatson> I'm pretty depressed about the state of the ext4 patch though, the current code is blatantly wrong but nobody cares
23:22 < otavio> cjwatson: I'll look into it, promisse
23:22 < cjwatson> thanks
23:23 < bubulle> otavio: that grub thing is still seomthing to care about?
23:23 < Ryan52> that (grub installer show a list of disks) sounds easy and would give me something to do that I think I understand...I would be willing to do it.
23:23 < bubulle> yay, we have a volunteer..:-)
23:23 < youpi> :)
23:23 < otavio> Ryan52: go go go !
23:23 < Ryan52> :)
23:23 < bubulle> Ryan52: probably to work with grub maintainer(s)
23:24 < otavio> Ryan52: yes, please talk to nyu about it and post your patches :-)
23:24 < bubulle> (which includes otavio, IIRC, but don't tell him, he has too many things to do)
23:24  * Ryan52 nods
23:24 < otavio> Ryan52: forgets me, plz!
23:24 < otavio> hahaha
23:24 < bubulle> yep, talkint to nyu is the way to go
23:24 < Ryan52> heh
23:24 < bubulle> NExt
23:24 < bubulle> Make os-prober readonly ( #418163)
23:24 < bubulle> again inherited from LennyGoals
23:24 < otavio> waldi: could you take the blockdev patch to busybox?
23:24 < otavio> waldi: that could allow us to make it work
23:25 < otavio> waldi: or somewhat, heh
23:25 < waldi> hmm, use dmsetup and setup a read-only device *run*
23:25 < cjwatson> is busybox maintained in d-i svn yet?
23:25  * otavio slaps waldi 
23:25 < otavio> heh
23:26 < otavio> cjwatson: yes
23:26 < otavio> waldi: ack about cjwatson adding it?
23:26 < otavio> cjwatson: you were who did the patch IIRC
23:26 < bubulle> otavio: if you slap waldi, he will talk less and this is not something we want...;-)
23:27 < waldi> otavio: better send it upstream, i have to do a new version anyway
23:27 < cjwatson> otavio: where? don't see it in packages/busybox
23:27 < waldi> cjwatson: somewhere in /people/waldi
23:27 < otavio> waldi: even if it is not accepted I belive it is quite important for us 
23:27 < cjwatson> waldi: oh. I'm probably not supposed to edit that though
23:28 < otavio> waldi: why don't you move it to d-i packages dir?
23:28 < cjwatson> otavio: I'm not sure, I don't have it in the Ubuntu busybox package
23:28 < otavio> waldi: that would allow us to help with it
23:28 < bubulle> ok, move to next thing (and I agree that busybox shuld move to packages)
23:28 < otavio> cjwatson: http://people.ubuntu.com/~cjwatson/busybox.blockdev.diff
23:28 < bubulle> "support TFTP to retrieve preseed files (#509723)"
23:29 < cjwatson> huh
23:29 < otavio> bubulle: I belive it is important and we just need someone to take care of it  
23:29 < cjwatson> well, OK, apparently I didn't think it important enough to keep; you can tell the age of that patch because it's against busybox-cvs
23:29  * Ryan52 would like support for that as well, and could maybe work on it
23:29 < otavio> bubulle: this should be an easy task for a new devel
23:29 < otavio> Ryan52: so, take it :-)
23:29 < Ryan52> k :)
23:30 < bubulle> yay
23:30 < cjwatson> dropped in Jan 2006 so it will need serious updating
23:30 < bubulle> Ryan52: the bug report mentions that a tftp client udeb is needed but busybox has one, too
23:30 < bubulle> Ryan52: and cjwatson said "Using busybox's would probably indeed
23:30 < bubulle> be a better idea"
23:31 < otavio> cjwatson: another possibility would be to write a small tool for os-prober-udeb that does it 
23:31 < Ryan52> do other people care about fjp's size concerns? should they actually be looked at? 4k doesn't seem that big. (or did he just make up that number?)
23:31 < cjwatson> busybox makes more sense I think
23:31 < bubulle> Ryan52: you're right, fjp concerns were a good objection...so that need to be considered and pondered
23:32 < otavio> Ryan52: we all care about space but we can't also stop adding features because someone will ever need to install Debian in a toster
23:32 < waldi> oh size ...
23:32 < Ryan52> ok.
23:32 < otavio> Ryan52: so; if required and we don't see an alternative, we accept the size issue
23:32 < otavio> Ryan52: but is nice to avoid
23:32 < bubulle> next topic (as we found a volunteer for that one)
23:32 < bubulle> "General cleanup"...aha
23:32 < youpi> :)
23:33  * bubulle bets we won't find a volunteer for that one..:)
23:33 < Ryan52> heh
23:33 < luk_> time permitting, I would like to help there, though probably need someone to guide me
23:33 < otavio> bubulle: I belive we're more or less doing it all the time
23:33 < bubulle> that means "general code cleanup, e.g. old backwards compatibility hacks"
23:34 < otavio> bubulle: from time to time we drop a old code that is not used anymore
23:34 < bubulle> luk_: fjp could be a good option as a guide in this
23:34 < bubulle> or joeyh (dream dream)
23:34 < cjwatson> joeyh only said he was taking a year off, didn't he?
23:34 < cjwatson> IIRC
23:35 < bubulle> other topic in SqueezeGOald: "Various". I propose skipping it and move to partman stuff
23:36 < cjwatson> hah
23:36 < bubulle> We have "add ext4"
23:36 < waldi> add btrfs
23:36 < bubulle> and we have the volunteer..:-)
23:36 < cjwatson> ext4's just waiting on the blocking bugs
23:36 < luk_> bubulle: I'd rather know what still needs to be done for the udeb one
23:36 < otavio> waldi: btrfs hheh
23:37  * otavio hides 
23:37 < cjwatson> Ted did an upstream release of e2fsprogs but "forgot" to upload it to Debian
23:37 < bubulle> luk_ I won't forget about it
23:37 < cjwatson> (the upstream release includes debian/ so this is pretty bizarre)
23:37 < otavio> HAHA
23:37 < cjwatson> any objections to me NMUing grub with Colin King's ext4 patch?
23:38 < cjwatson> I think there's a newer version of it, I'll check
23:38 < waldi> otavio: at least it does not longer break down during a bonnie run ...
23:38 < otavio> cjwatson: is it supporting grub2?
23:38 < otavio> waldi: hehe
23:38 < otavio> waldi: is it a feature? :-)
23:38 < otavio> hehe
23:38 < cjwatson> otavio: I think grub2 already supports ext4, but as I said a while back I'd like to decouple the addition of ext4 from the switch to grub2
23:38 < cjwatson> makes it simpler for users to upgrade too
23:39 < otavio> waldi: I like the idea BTW
23:39 < otavio> cjwatson: yes; I agree
23:39 < waldi> otavio: it is a new filesystem and some s390 developers made a "small" test and broke it several times
23:39 < otavio> waldi: heh
23:39 < bubulle> cjwatson: so my understanding is that you got a GO for grub NMU..:)
23:40 < cjwatson> "Merge ext3 support into partman-basicfilesystems so it is available by default in lowmem installations"
23:40 < cjwatson> I'm confused by this. Why not just install partman-ext3 by default if this is wanted?
23:40 < otavio> cjwatson: I'd like you to ask nuy to avoid problems with him
23:40 < cjwatson> otavio: ok
23:40 < otavio> cjwatson: but if grub2 has it, I see no objection on supporting it in grub2 
23:40 < otavio> grub1
23:41 < bubulle> cjwatson: not sure of the rationale. That's an old thing inherited from LennyGoals again and nothing moved here during Lenny devpt
23:42 < cjwatson> I'll put a question against it on the wiki
23:42 < bubulle> So we can probably move this down in a "questionable proposals" section
23:42 < bubulle> "Try to get some issues in libparted fixed: #406680, #328629, #377263"
23:42  * otavio hides completely
23:42 < otavio> I'll take this one
23:43 < cjwatson> IIRC 406680 was supposed to be solved by using external tools rather than filesystem reimplementations
23:43  * bubulle was about to assign it 
23:43 < otavio> but I won't be able to look into it until next week I think
23:43 < bubulle> otavio: you have the entire release cycle for this
23:43 < otavio> cjwatson: parted is moving to use external tools when possible
23:43 < otavio> cjwatson: well, not to use
23:43 < bubulle> "Implement "resize partition and install to free space" in guided partitioning"
23:43 < otavio> cjwatson: but to drop things that can be done using external tools
23:43 < cjwatson> otavio: I've heard that a few times, but hadn't seen any code yet - does it exist?
23:43 < otavio> cjwatson: to reduce our code size and maintainence
23:44 < cjwatson> otavio: and does the use of external tools still provide progress bar updates?
23:44 < otavio> cjwatson: we had two alternatives
23:44 < otavio> cjwatson: use external tools
23:44 < otavio> cjwatson: drop them
23:44 < otavio> cjwatson: we opted to drop them
23:44 < otavio> cjwatson: so parted will be really to work with partitions, not fs 
23:44 < otavio> cjwatson: except fat that our code is quite good 
23:45 < cjwatson> interesting; I'll reserve judgement until I've seen it I think
23:45 < bubulle> Again: "Implement "resize partition and install to free space" in guided partitioning"
23:45  * otavio warns that he needs to go in 15min
23:45 < cjwatson> it's probably the right answer long-term but that's bound to have loads of knock-on effects
23:45 < bubulle> yet another "cjwatson has patches" thing
23:45 < cjwatson> bubulle: well, sort of
23:46 < cjwatson> the work I've done on that makes some assumptions about the likely size of the target installation, which as we know is rather hard to predict
23:46 < bubulle> I propose moving this to "Pick up your task" section in case someone other than Ryan52 comes and asks about what to work on
23:46 < cjwatson> IOW, it only bothers to offer you a partition if it has at least 3GB free
23:47 < cjwatson> I think it's the right place to start but I don't think it's ready for merging
23:47 < bubulle> Proposals about partman-crypto:
23:47 < bubulle> -improve entropy handling, add support for keys-on-removable-devices, allow devices to be deallocated
23:47 < bubulle> -Allow a user to re-use an existing encrypted filesystem
23:47  * franklin likes "Pick up your task" section 
23:48  * otavio likes it too
23:48  * luk_ too
23:48  * Ryan52 too
23:48 < bubulle> So, franklin just volunteered to reorganize the SqueezeGoals page, yay
23:48 < otavio> LOL
23:48 < otavio> hah
23:48 < luk_> yay
23:48 < Ryan52> heh
23:48 < franklin> for what would be left... why not
23:49 < bubulle> franklin: you're certainly much faster than I can be anyway
23:49 < bubulle> OK, the partman-crypto things were David's babies....
23:49  * bubulle doesn't remember his nickname, dammit
23:50 < bubulle> so, mve to "pick your task"
23:50 < bubulle> as well as "kill lvmcfg and mdcfg"
23:50 < bubulle> and "support partitioning a RAID device"
23:51 < bubulle> ah, "Maybe (selectively) enable relatime/noatime by default"
23:51  * Ryan52 was originally interested in killing mdcfg, bug still doesn't understand what exactly that task involves. *sigh*. if somebody who does could teach me, I would defidently want to learn.
23:51 < Ryan52> but*
23:51 < cjwatson> bubulle: I recently edited the wiki page for that; modified relatime will be the default in 2.6.30
23:51 < cjwatson> so I don't think we need to keep that to-do item
23:51 < otavio> Ryan52: I think your other tasks should be done before  
23:51 < bubulle> ok, we'll drop it then
23:51 < bubulle> (relatime)
23:51 < Ryan52> otavio: indeed
23:52 < bubulle> Folks that does not end up the SqueezeGoals page but we went though the most important parts of it
23:53 < otavio> Yes
23:53 < otavio> When we could have another meeting?
23:53 < luk_> ack, I only love to know what's still needed for the udeb transition
23:53 < bubulle> I propose postponing the remaining for yet another meeting
23:53 < bubulle> ah, yes the udeb transition
23:53 < otavio> I think we're doing quite fine on those small ones
23:53 < wart> One note regarding ps3 support: I will try to make it, but it's hard to promise.
23:53 < otavio> wart: we trust you
23:53 < otavio> wart: hehe
23:53 < wart> Bootloader issue is hmm.. hard.
23:53 < bubulle> wart: I was about to mention it too as you already worked on it, right?
23:54 < wart> Yep.
23:54 < bubulle> so, we can mention PS3 support as wart's baby
23:54 < otavio> bubulle: heh
23:54 < luk_> I already found http://wiki.debian.org/DebianInstaller/LibraryUdebs and will have a look
23:54 < otavio> bubulle: you're a baby builder ;-)
23:54 < luk_> though is anything else missing?
23:54 < franklin> wart: PS3 is something I am interested in. i'll come back to you 
23:55 < otavio> luk_: I can try to look at it with you later (next week) if you want
23:55 < elmig> So we will have a Bits from the d-i team? ^_^
23:55 < wart> franklin: okay
23:55 < otavio> Well think; I'm about to leave
23:55 < luk_> otavio: ok, maybe on Wednesday?
23:55 < bubulle> elmig: I think that "Bits from the D-I team" is more or less what I intended as "minutes from the March 16th, March 30th" meetings
23:56 < otavio> luk_: I think it works
23:56 < otavio> luk_: if I have any problem we coordinate it
23:56 < elmig> as a user it's nice to read what is hapenning
23:56 < luk_> otavio: ok
23:56 < elmig> it's inspiring .)
23:56 < luk_> bubulle: great!
23:56 < bubulle> I propose April 11th 20:00 UTC as next meeting
23:56 < cjwatson> maybe we could keep wiki notes for Bits accumulation, like the developer news
23:56 < bubulle> to finish going through the SqueezeGoals page
23:56 < otavio> bubulle: it works for me ATM
23:57 < luk_> bubulle: not 19 UTC?
23:57 < otavio> bubulle: ah; clean up the ReleaseAnnouncement
23:57 < cjwatson> I can't make Apr 11th
23:57 < otavio> bubulle: so we can use it to Alpha1 work
23:57 < cjwatson> oh, wait, maybe I can. It's the next weekend I'll be away
23:57 < otavio> Well; bye!
23:58 < otavio> see you all and thanks!
23:58 < bubulle> otavio: will try but I can't commit on many things right now
23:58 < luk_> for me it's easier on a work day
23:58 < bubulle> and the minutes should get priority, imho
23:58 < cjwatson> luk_: likewise
23:58 < otavio> bubulle: ok then we can try to find someone to do that
23:58 < otavio> bubulle: sure
23:58 < otavio> bubulle: start a pool for the meeting date again
23:58 < bubulle> So, I hereby officially close the meeting (and my log).
23:59 < otavio> bubulle: it works
23:59 < bubulle> I prepare the meeting log, post it and go to bed..:-)
23:59 < franklin> Thanks.
23:59 < luk_> tnx