21:57 < otavio> 3min for the meeting
22:00 < brother-_> .
22:01 < otavio> Is anyone online for the meeting?
22:02 < otavio> Please wave!
22:02 < otavio> :-)
22:02 < brother-_> I wasn't planning to say anything but I am here to watch
22:02 < brother-_> that came out wrong =)
22:03 < otavio> brother-_: you're welcome
22:03 < otavio> brother-_: but if we are the only alive people we'll need to postpone the meeting
22:03  * luk_ waves
22:04 < luk_> it would be good to highlight people that were present the previous meeting or indicated an interest in the meeting...
22:04 < luk_> liable: meeting is now...
22:05 < otavio> bubulle: 
22:05 < otavio> cjwatson: 
22:05 < otavio> Lunar^: 
22:05 < luk_> cjwatson said he would not be able to make it :-(
22:05 < otavio> luk_: oh ok
22:07 < otavio> luk_: i'm thinking about postpone it
22:08 < luk_> hmm, not good as we do not have a backup date IMHO
22:09 < otavio> right but without people, what we can discuss?
22:09 < otavio> heh
22:09 < luk_> very strange that bubulle is not here as he proposed the date and it did not get changed even if at least cjwatson and me told it to be a difficult time
22:09 < otavio> just you, me and brother-_ isn't a bulk of people ;-)
22:09 < brother-_> =)
22:09 < otavio> luk_: yes; indeed
22:10 < brother-_> as I don't intend to be that much of a participant
22:10 < otavio> luk_: maybe he had a personal compromise or something
22:10 < luk_> right, though I think postponing is worse than having a small meeting between us
22:11 < otavio> Well 
22:11 < luk_> we could at least discuss about udebs and the (old)stable point releases for instance
22:11 < otavio> All topics that are in agenda are quite difficult to talk with less people
22:11 < otavio> Ok
22:11 < otavio> luk_: that we both can sort 
22:12 < luk_> right, lets do that and only start with the other squeeze goals when more people show up
22:12 < otavio> luk_: mind to log the meeting?
22:12 < Ryan52> oh look, at meeting.
22:13 < otavio> luk_: I won't be around too much next week
22:13 < otavio> Ryan52: oh! nice!
22:13 < otavio> Ryan52: another guy :-)
22:13 < luk_> I log everything anyway, though if you expect it to be sent somewhere we should have a clear marker for me to easily find the borders of the meeting :-)
22:14 < otavio> luk_: ok
22:14 < otavio> ======= meeting starting ===============
22:14 < otavio> Please let's start the meeting and see if someone else joins during it
22:14 < luk_> ack
22:14 < otavio> Please who is alive and wants to participate, please wave
22:14  * Ryan52 waves
22:14  * otavio waves
22:15  * luk_ waves
22:15 < brother-_> a half wave then
22:15 < otavio> heh
22:15 < otavio> Anyone else?
22:15 < otavio> Ok
22:16 < otavio> Luk has suggested to us to talk about the (old)stable point release
22:16 < otavio> luk_: please start
22:17 < luk_> it was a bit unfortunate to have the d-i updates very late
22:17 < otavio> luk_: in which? oldstable or stable?
22:17 < otavio> luk_: you mean last week?
22:17 < luk_> even more because the point releases were both delayed
22:18 < otavio> Yes; I fully agree. I really missed the deadline due commitments here at work.
22:18 < luk_> for oldstable you spotted the .svn directories, so another upload was needed
22:18 < luk_> for stable we spotted the versioning issue regarding the binNMU, but only today which was too late to fix it properly
22:18 < otavio> yes; right
22:19 < otavio> There're few things we ought to avoid in d-i related packages; + is an example of it
22:19 < luk_> so I would like to have an overview of what changes we want to include in the next point releases (on the wiki for instance)
22:19 < otavio> It took three days to me to fix the massbuild script to be able to upload the kernel packages to lenny
22:20 < otavio> Well; I have no plans yet
22:20 < otavio> The only thing I really want to put in is the cdebconf fix
22:20 < luk_> and start uploading soon so any issue can be discovered soon and get corrected
22:20 < otavio> Nothing else comes to my mind
22:20 < luk_> well the cdebconf fix already includes a d-i update too
22:21 < otavio> That could be done during next week; also because it could allow us to upload d-i in sequence to properly test it
22:21 < luk_> I guess dannf will also look if a kernel update is not in order, it's best to track that closely
22:21 < otavio> Well; next week will be a bad one for me but (next (next)) works for me
22:22 < luk_> it would also not bad to already start looking at what things we would want to include in lennynhalf
22:22 < otavio> Well; but this doesn't involves d-i a lot
22:23 < otavio> It is mostly other packages and testing; since it is suppose to use a beta version of squeeze installer
22:23 < luk_> I was thinking at the network driver (e1000e?) and extra hardware support for some arm devices I guess
22:24 < otavio> e1000e is already in udebs
22:24 < luk_> it involves d-i as an important part is to make sure recent hardware can get installed with the lennynhalf kernel
22:24 < otavio> and it comes with updated kernel
22:24 < luk_> in udebs of what package?
22:24 < otavio> since it is suppose to use 2.6.30 or 2.6.31
22:24 < otavio> kernel
22:25 < otavio> modules/nic-extra-modules:e1000e
22:25 < otavio> in kernel-wedge
22:25 < Lunar^> Having better support for wireless network sounds like something desirable for lennynhalf as well… but we'll see how netcfg is improved
22:25 < otavio> if it is not included is because the kernel has it disabled
22:25 < otavio> Lunar^: yes; indeed
22:25 < otavio> Lunar^: nice to have you around
22:25 < Lunar^> (sorry for being late)
22:26 < otavio> Lunar^: could you take a look at liable patch?
22:26 < otavio> Lunar^: it could help us to get it merged soon
22:27 < luk_> right, better wireless support would be nice to have for lennynhalf
22:27 < Lunar^> There was already comments to be addressed IIRC, but I suggest that we switch to use wpasupplicant soon; that would already be an improvement over the current situation
22:27 < otavio> I've talked to kernel team two days ago and they said that a new kernel upload is planned to as soon as .2 goes out
22:27 < otavio> This would allow us to fully update to 2.6.29
22:28 < otavio> Lunar^: please check it with him if you can; it is quite important for us to get it moving soon
22:28 < Lunar^> I'll try
22:28 < otavio> Lunar^: perfect :-)
22:28 < luk_> Lunar^: he's liable on IRC btw
22:29 < otavio> Lunar^: liable 
22:29 < otavio> liable: Lunar^ 
22:29 < otavio> :-)
22:29 < luk_> lol
22:29 < Lunar^> I know :P
22:29 < otavio> They're properly introduced to each other now ;-)
22:29 < otavio> Ok
22:30 < otavio> So; my mental target is to have an Alpha 1 image in began of May
22:30 < luk_> for installing Etch with the Lenny installer, we chose to only have it work with preseeding, was that a short term solution or is it meant to stay that way?
22:30 < otavio> luk_: no; it works with the param too
22:30 < otavio> luk_: you can pass suite=oldstable too I guess
22:30 < otavio> Lunar^: confirms it?
22:31 < luk_> ah that would be good
22:31 < Lunar^> I have only tested "suite=etch" on the command-line
22:31 < otavio> luk_: I didn't check it though
22:31 < Lunar^> but "suite=oldstable" should also work
22:31 < otavio> Lunar^: but with suite=etch it worked right?
22:31 < luk_> ok, that's fine
22:32 < otavio> luk_: this is suppose to stay that way
22:32 < luk_> is that also updated in the manual btw?
22:32 < otavio> luk_: it is an "advanced" usage of the installer
22:32 < Lunar^> otavio: As I said, I have not tested an installation through the end
22:32 < otavio> Lunar^: yes yes; I know it
22:33 < Lunar^> luk_: The manual already mentions it IIRC. Being able to install etch with Lenny installer was working until Lenny actually became stable
22:33 < luk_> ok
22:33 < otavio> Lunar^: I didn't find it in manual in boot params section
22:34 < otavio> Lunar^: it would be nice to have something about it there too
22:35 < luk_> ok, I guess that concludes the part about stable/oldstable for now?
22:35 < otavio> Yes; I guess so
22:35 < otavio> Next topic?
22:35 < luk_> udeb support
22:35 < otavio> luk_: britney I suppose
22:36 < luk_> on the Squeeze page it's mentioned as 'Finish last bits of udeb transition'
22:36 < luk_> what does that mean?
22:36 < luk_> we started already a wiki page with some info:
22:36 < luk_> http://wiki.debian.org/UdebSupport
22:37 < otavio> luk_: I really don't know what this topic (on Squeeze Goals wiki page) means
22:37 < otavio> luk_: I think we should clarify it on mailing list
22:37  * otavio opens the UdebSupport wiki page to take a look
22:37 < Lunar^> luk_: http://wiki.debian.org/DebianInstaller/LibraryUdebs
22:38 < Lunar^> that's the page that was tracking the remaining issues IIRC
22:38 < luk_> Lunar^: that is linked from the wiki page I mentioned
22:38 < luk_> ah ok, that would be good
22:39 < otavio> Dunno if someone has been updating it BTW
22:39 < Lunar^> The last issue is probably xfsprogs-udeb then
22:39 < otavio> We'd need to recheck if the issues are still open and like
22:40 < Lunar^> although #474293 is closed now
22:40 < luk_> well the status is not the thing I worry most about (yet), I worry more about what entails the needed udeb support
22:41 < otavio> luk_: well; I think we need to clarify in which part
22:41 < otavio> luk_: udeb support on what?
22:41 < otavio> luk_: dpkg? britney?
22:41 < otavio> For dpkg, I dunno if I think we should extend it
22:41 < otavio> It is basically not target to be used in installed system
22:41 < otavio> and on installer we use udpkg
22:42 < otavio> so, I fail to see why to extend the support on dpkg itself
22:42 < luk_> udeb support in the sense that no team besides the d-i team has to do anything special to support them IMHO
22:43 < otavio> well; for me I think this just depends on britney properly supporting the migration of it
22:43 < otavio> and we add on installer the information about which one has "parts" copied into the initrd
22:44 < otavio> so we can automate the GPL thing
22:44 < luk_> right, these are certainly needed
22:44 < otavio> So if a package has parts "copied" into the installer, it needs to be blocked from uploads during release cycle 
22:45 < otavio> from/for
22:46 < otavio> luk_: who is working at britney support for udeb?
22:46 < luk_> why, is it not enough to keep the old version around?
22:47 < otavio> luk_: it is; for GPL
22:47 < otavio> luk_: but any update will be missed
22:47 < otavio> luk_: ok, not blocked but done with an ack for something
22:47 < otavio> luk_: we need to be aware of packages of that "type" that has been change
22:48 < otavio> luk_: also to know if we'll be going to do another d-i upload or just copy the binaries to the "hidden-release" to keep them around
22:48 < otavio> luk_: so we need to track them somehow
22:49 < otavio> luk_: even if it is fully automated to not break GPL we could require updating d-i to get the fixes
22:49 < otavio> luk_: got it?
22:50 < luk_> updating d-i might be needed to use the newer versions in d-i, but that's orthogonal to the source requirements, right?
22:50 < otavio> yes; for GPL yes
22:52 < luk_> another part of proper udeb support would be to see from udeb's meta information what impact a particular udeb could have on other udebs and d-i components
22:52 < otavio> luk_: you mean like a "depends"?
22:53 < luk_> versioned depends, conflicts, breaks or similar
22:54 < otavio> luk_: this is more difficult
22:54 < luk_> to ease maintenance and needed knowledge to know what impact a removal of broken udeb can mean
22:54 < luk_> s/of/or/
22:55 < otavio> luk_: since currently depends is used by main-menu to sort the questions and like
22:55 < otavio> luk_: we'd need to change it to allow us to properly use the depends for that information
22:55 < otavio> luk_: or we could use other fields for it
22:55 < otavio> luk_: but then we'll diverge a bit from regular debs; dunno if this is desirable
22:56 < luk_> no, not desirable
22:56 < Lunar^> I do like the current system of using depends for the different steps
22:56 < otavio> yes; but then we have a huge "transition"
22:56 < luk_> it would make more sense to change how main-menu knows to sort the questions
22:57 < otavio> Lunar^: yes; but where we'd put the information that luk_ is talking about?
22:57 < Lunar^> luk_: Do you have an example of something you miss?
22:57 < luk_> it could be rather easy by introducing a 'Menu-Dep' field or similar IMHO
22:58 < luk_> Lunar^: when upgrading a udeb, some other udebs might break
22:58 < luk_> knowing beforehand which ones would be what I want
22:59 < otavio> Lunar^: what we put in changelog nowadays
22:59 < otavio> Lunar^: like: requires foo (> 1.23)
23:00 < luk_> right, these should definitely be in the Depends field IMHO
23:00 < Lunar^> That would require some better research, but I think we don't use Depends mainly because of libd-i limitations
23:01 < luk_> these limitations being?
23:02 < otavio> My main concern about it, despides  the possibility we're missing a really reason to Depends being used, is the transition and backward compatibility
23:02 < otavio> If we change it, we'll break every custom distro or fork around there
23:03 < otavio> So it needs to be done in a very coordinated way BUT
23:03 < otavio> this specific case is almost do it in stages; I see no other alternative then change it all once
23:04 < otavio> almost impossible
23:04 < luk_> we should probably stage it in experimental or a separate repository
23:05 < Lunar^> From some quick git searching, we already uses Depends
23:05 < otavio> yes; that could be a way to test it while doing it; but we'd break all udebs around there
23:05 < otavio> Lunar^: ?
23:06 < Lunar^> we are just missing Breaks and Conflicts, but those should already be ignored in d-i
23:06 < Lunar^> look at r54699 for example
23:07 < Lunar^> r50353
23:08 < Lunar^> r52417
23:08 < otavio> Lunar^: yes but we don't use it for all cases
23:09 < otavio> Lunar^: well; maybe when we were suppose to be using Breaks
23:10 < Lunar^> I think so
23:10 < Lunar^> First step should IMHO to work on britney
23:11 < Lunar^> there might be some corner cases requiring adjustements, but I don't think they're huge
23:11 < otavio> yes; I agree
23:13 < luk_> the needed changes for britney are not large btw, they just need some coordination and testing, we already know how to do them
23:13 < otavio> well then I think we ought to start working on that and use the alpha1 as a test case for them
23:14 < otavio> what do you think?
23:14 < otavio> luk_: ^
23:14 < luk_> when is alpha1 supposed to happen?
23:14 < otavio> My mental target is to began of may
23:14 < otavio> not a hard date
23:15 < otavio> but that is what I have in mind
23:15 < otavio> once kernel is out and we switch it it, we'll be in better shape to do more realist ETA for things 
23:16 < luk_> as the kernel is not out yet, I think beginning of May will be hard to accomplish, though I'll put the udeb changes higher on the release team's TODO list
23:17 < otavio> luk_: do you think so?
23:17 < otavio> luk_: do you think it due the possible problems for the kernel to migrate?
23:18 < luk_> I still don't get why d-i people think it's best to first work on the britney part though as essentially it will change from semi-automatic migration to fully automatic migration of udebs and have hints to control udeb containing packages specially wrt blocking/unblocking
23:19 < luk_> well a kernel upload, means also modules updates
23:20 < luk_> and especially out of tree modules always need changes that were not foreseen (as they cannot really be foreseen the way the kernel is maintained upstream)
23:20 < otavio> luk_: about the britney: well, this is where we need to take more care while releasing and it could make your and our life eaiser
23:20 < otavio> luk_: and it is much better to do that now, instead of more to the end of the release cycle 
23:21 < otavio> luk_: also because first releases aren't target to mass-usage
23:21 < otavio> luk_: they'll be alpha quality so a good test case for it
23:21 < otavio> luk_: then we'll gain trustness on britney for it during that cycle
23:21 < luk_> we do not intend to move it to the end of the release cycle at all, though britney changes are in the pipeline for the time around DebConf
23:21 < otavio> luk_: bugs could be fixed then and like
23:22 < otavio> luk_: why?
23:22 < otavio> luk_: why not do it in this cycle?
23:23 < luk_> because we're busy with after release transitions and the like
23:24 < otavio> well I think at the end of the cycle will be worse
23:24 < otavio> but it is your call
23:26 < luk_> the beginning of the cycle is the first half a year IMHO, though as I said before I'll put it higher on the TODO list
23:26  * Lunar^ needs to leave, sorry
23:27 < otavio> luk_: ok
23:27 < luk_> anyhow, I think it's wrong to wait for the britney changes before looking at the other udeb transition related issues
23:27 < otavio> luk_: we're not going to not look at other things; specially the remaining issues with libraries
23:27 < otavio> luk_: I also agree we ought to solve them
23:29 < otavio> luk_: can we move to next topic?
23:29 < luk_> sure
23:30 < luk_> daily builds for alpha, amd64, hppa, mips and mipsel are now on d-i.debian.org
23:30 < otavio> luk_: NICE
23:31 < otavio> luk_: are you going to put the remaining ones too?
23:31 < otavio> luk_: if you do, we could drop our current aggregator and move to your builders
23:32 < luk_> I might be looking into providing the powerpc ones too as Yoe seems to have trouble providing them
23:33 < luk_> well I use the same aggregator code on d-i.debian.org: http://d-i.debian.org/daily-images/build-logs.html
23:33 < otavio> luk_: but are those all being done on buildds right?
23:33 < otavio> yes yes
23:33 < otavio> I mean that we can drop our instance of it
23:35 < luk_> amd64 is on my own machine, the others are on buildds
23:35 < otavio> Would be difficult to us to really use buildds for all?
23:35 < luk_> s/machine/server/
23:36 < otavio> That would be nice; specially if the auto-upgrade works
23:36 < otavio> or we get the chroot auto-setup working as well
23:36 < luk_> well, I'm working on these
23:36 < luk_> them being on buildds, having the auto-upgrade work and an auto-setup
23:36 < otavio> great :-)
23:37 < otavio> that will help a lot
23:38 < otavio> Well I guess we can continue to chat but there's any other topic you want to cover on the meeting?
23:39 < luk_> nope, other topics need more people around IMHO
23:39 < otavio> yes; fully agree
23:39 < otavio> so:
23:40 < otavio> ============ closing meeting ==============
23:40 < otavio> ok; well I'll be around for some minutes
23:40 < otavio> if you want to talk about anything we can do that, np
23:40 < luk_> I guess we should have a poll for the next meeting time
23:41 < otavio> Yes; I second that
23:41 < otavio> also schedule it with more time ahead
23:41 < otavio> and send more reminders about it during the period
23:41 < luk_> well the one who controls the options in the poll can easily do it with more time ahead :-)
23:42 < otavio> luk_: you offered help to work on digress
23:42 < otavio> luk_: are you still underested?
23:42 < luk_> digress?
23:42 < otavio> luk_: the d-i regression tests
23:42 < otavio> luk_: the machine that joeyh has hosting
23:43 < luk_> ah, well I think it's something we should continue (resurvive) to do
23:43 < otavio> luk_: well in that case we ought to coordinate how to take over it
23:43 < otavio> luk_: Joey wants to pass it
23:44 < otavio> luk_: and we'd need to ask him how we could access the machine in a way we both could get it working
23:45 < luk_> well I think Joey is right that shipping it somewhere is insane and shutting down the local controller is obvious when noone has local access
23:46 < luk_> from the rest of Joey's mail I concluded that it are just a bunch of machines which are getting old
23:46 < luk_> so it might be better to look for a similar setup elsewhere?
23:46 < otavio> well but the "server" could still be quite useful for it
23:46 < otavio> it has 8 CPUs 
23:47 < otavio> so we can do concurrent tests for a lot of machines
23:48 < luk_> ah indeed, an 8 CPU machine is still interesting
23:48 < luk_> even remote :-)
23:49 < CIA-2> debian-installer: fjp * r58214 manual/build/preseed.pl: Code simplification
23:49 < otavio> yes