20:00:13 <bubulle> #startmeeting
20:00:13 <MeetBot> Meeting started Mon Sep 21 20:00:13 2009 UTC.  The chair is bubulle. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:13 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:00:28 <bubulle> #topic see who's around
20:01:06 <bubulle> hhhhm
20:01:13 <youpi> well :)
20:01:14 <bubulle> do we have a release manager?
20:01:30 <bubulle> otavio was around 2 hours ago
20:02:21 <bubulle> (deep sound of silence)
20:02:56 * mvz is here, hi all
20:02:59 <fezie> s/2 hours/40 minutes/
20:03:11 <bubulle> fezie: yes, right
20:03:18 <fezie> well I'm here too :)
20:03:51 <bubulle> well, at least we can start to talk about grub status, then?
20:04:01 <bubulle> #topic alpha release - grub status
20:04:17 <bubulle> fezie: what's the situation right now?
20:04:22 <fezie> the grub package in squeeze depends now on grub-pc
20:04:43 <fezie> grub-installer installs prefers now to install grub-legacy instead of grub because of that
20:05:10 <fezie> but I still haven't worked yet on the grub2 password support patch for g-i because I'm currently just too down :(
20:05:35 <mvz> does g-i need something special there?
20:05:57 <bubulle> fezie: last meeting we were talking about possible testing transition
20:06:01 <mvz> (assuming you meant graphical installer)
20:06:08 <bubulle> if I'm correct it just happened, no?
20:06:17 <fezie> mvz: basically it's just adding a debconf prompt to ask for the username and create a /etc/grub.d/00_password file
20:06:24 <fezie> mvz: oh I meant grub-installer
20:06:41 <fezie> bubulle: yes 1.97~beta3 is now in squeeze
20:06:43 <mvz> ah, ok, I was confused :)
20:07:02 * otavio is here
20:07:03 <bubulle> fezie: the password prompt is not a blocker, right?
20:07:10 <fezie> for Frans it is
20:07:27 <fezie> and also dmraid and multipath
20:08:54 <fezie> for dmraid and multipath we could just use grub-legacy for now
20:09:11 <fezie> I don't understand why for Frans the password support is a blocker, it's just asked in expert mode
20:09:43 <bubulle> I think it should be a blocker for a release but for an alpha release we could probably just document this in errata?
20:10:18 <mvz> seems reasonable to this bystander
20:10:24 <fezie> yes
20:10:57 <bubulle> otavio: do you agree that we could consider issues in grub-installer as non blockers?
20:11:16 <mvz> fezie: are the dmraid, multipath issues documented somewhere in more detail?
20:11:17 <bubulle> Is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477094 the right reference?
20:12:14 <mvz> just found #477090
20:12:31 <fezie> mvz: #540549 has some links to the grub-devel discussions
20:12:39 <bubulle> #link http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477094
20:12:52 <otavio> bubulle: yes; i fully agree
20:13:01 <otavio> bubulle: specially because it is a alpha version
20:13:14 <bubulle> #agreed Despite issues reported in #477094
20:13:33 <bubulle> #agreed we do not consider GRUB2 issues as a blocker for an *alpha* release
20:13:51 <otavio> bubulle: and it is the rightest moment to move to it and collect the regressions
20:14:09 <otavio> IMO grub regressions ought to be a blocker for Debian release but not for now
20:14:22 <bubulle> OK, we can move to other topics related to the release
20:14:40 <fezie> so we switch the grub2_instead_of_grub-l template to Default: true now?
20:15:17 <bubulle> fezie: yeah, let's break everything! :-)
20:15:28 <bubulle> seriously, that seems to be the moment, yes
20:15:37 <fezie> oki
20:15:42 <otavio> fezie: please do and upload
20:16:01 <bubulle> #topic alpha release - schedule
20:16:15 <otavio> fezie: put a note in scripts/testing about the requirement of new grub for it
20:16:16 <bubulle> otavio: that seems to be the moment where you tell your plans..:-)
20:16:23 <otavio> bubulle: ok, thx
20:16:38 <otavio> Well; as people should have noticed I started to ask for migration of packages
20:17:11 <otavio> My ideia is to get all required packages to build installer, just for a shot, and then update to latest kernel (due pat and other fixes)
20:17:20 <fezie> otavio: uhm there's just scripts/testing-summary/?
20:17:28 <otavio> The kernel ought to be easy and I did the builds locally already
20:17:30 <otavio> fezie: yes
20:17:56 <fezie> and what should I put there, sorry didn't get it right
20:17:59 <otavio> So I'd like to get the kernel udebs in testing to build installer and then do udebs uploads again
20:18:06 <otavio> fezie: see the annotations
20:18:57 <otavio> If all goes well, we ought to have installer uploaded by end of thís week and we could ask for a iso building using it for testing
20:19:10 <fezie> ah
20:19:25 <otavio> In meanwhile I'd be working in get new kernels udebs in sid and then get them aged  for us to get them in testing
20:19:59 <otavio> So first October week looks like a quite realistic date for me
20:20:13 <otavio> Anyone objects?
20:20:14 <bubulle> otavio: anything needed to have the kernel udebs in testing or are we just waiting for you to do the job?
20:20:39 <bubulle> otavio: nope (but it's not as if we wer 10,000 people around)
20:20:41 <otavio> bubulle: I asked RM people to age the udebs to them to migrate
20:20:58 <bubulle> otavio: OK, so nothing but waiting
20:21:02 <otavio> bubulle: yes
20:21:31 <bubulle> #agreed we wait for kernel udebs to enter testing (ageing asked to RMs already) and then otavio builds D-I
20:21:36 <otavio> bubulle: My main idea is to see if installer builds properly in buildds, more then real getting something usable
20:21:51 <otavio> bubulle: we had problems with installer before
20:22:08 <otavio> bubulle: and I prefer to deal with them now then when we're trying to release
20:23:19 <bubulle> ok
20:23:49 <bubulle> so, in short, we wait for the builds to happen and see if everythign is OK, then when ISOs are ready, you call for testing, right?
20:25:24 <otavio_> bubulle: mostly
20:25:33 <bubulle> otavio: I guess I can start preparing the errata, then?
20:26:13 <otavio_> bubulle: we wait buildds to built and see; if it was done with a workable installer we do a iso build otherwise we work directly into new kernel and then inside of a workable installer
20:26:19 <otavio_> bubulle: yes
20:26:26 <otavio_> bubulle: but kernel issues ought to be all ok for now
20:26:28 <bubulle> as usual, take the last errata.wml file, adapt it to the new release, from what I know and ask for patches
20:26:30 <otavio_> bubulle: pat issue at least
20:26:45 <bubulle> #agreed bubulle prepares the errata file
20:27:46 <bubulle> I don't think we have more to say about the release...unless someone raises a topic
20:28:19 <bubulle> Shall we go to netxt topic (git migration)?
20:28:52 <bubulle> OT: I just uploaded an NMU of lilo..:-)
20:29:15 <bubulle> #topic git migration
20:29:25 <bubulle> but no joeyh around
20:30:41 <bubulle> My opinion about this is that we should wait for Frans concerns to be followed up. I think he had valid points (remember my l10n-sync commit of Sunday?)
20:30:53 <otavio__> crap
20:30:58 <otavio__> my ISP  is a shit
20:30:59 <mvz> bubulle: did those work out ok? :)
20:31:13 <bubulle> mvz: yes
20:31:50 <otavio__> bubulle: yes; I agree we ought to discuss it a bit further (about GIT I guess)
20:32:07 <bubulle> thanks to mr I need very minor changes to the script (mostly because "svn" calls were not hardcoded in the script: it allows an "--svn" switch
20:32:41 <bubulle> I still need a bit of time to test more than just a one-shot
20:33:02 <bubulle> and ppl were legitimately concerned about the commit storms..:-)
20:33:11 <bubulle> Ryan52: that means you too..:-)
20:33:36 <otavio> :-)
20:33:43 <mvz> I agree Frans has valid points, and I got the impression that they are mostly organisational
20:33:45 <Ryan52> who what?
20:33:56 <Ryan52> oh yes that. :)
20:34:13 <mvz> ie. whether it makes sense to have a central repo for strongly interdependent components
20:34:15 <bubulle> #agreed git migration needs more discussion and addressing concerns
20:34:51 <mvz> not something primarily technical, I think, more of how we want to do things
20:35:18 <bubulle> I think joeyh will summarize his arguments pro the multiple componenets choice
20:35:50 <bubulle> we can probably close this topic for today, anyway
20:36:11 <bubulle> #topic Release goals overview
20:36:32 <bubulle> #link http://wiki.debian.org/DebianInstaller/SqueezeGoals
20:36:42 <Ryan52> now that you guys have got my attention...what are my chances of getting the "patch" in #509723 applied? :)
20:38:39 <bubulle> Ryan52: I'd say very high, as long as someone remembers to do it..:-)
20:39:08 <bubulle> #topic Release goals - Persistent device naming for disks
20:39:18 <Ryan52> bubulle: please remember to do it then! :)
20:39:20 <bubulle> that's cjwatson's baby
20:39:42 <bubulle> Ryan52: don't you have commit access?
20:39:52 <Ryan52> no :(
20:40:44 <bubulle> Ryan52: easy to change...
20:41:23 <bubulle> cjwatson: so, well, you're not around....From what I see this release goal should be completed with the switch to grub2
20:41:42 <bubulle> ah, no, needs support in other bootladers
20:41:43 <mvz> hm, except for non-grub2 archs, I think
20:42:06 <mvz> yes
20:42:36 <bubulle> #info Release goal nearly achieved: only needs support in non grub2 bootloaders
20:42:40 <mvz> ideally someone could do a survey like stephano did for ext4 and see which bootloaders support it
20:42:47 <fezie> even with the switch to grub2 it won't be fully complete because in the grub2/install_devices debconf prompt we still store the normal devices
20:42:58 <fezie> but cjwatson works on implementing support for disk/by-id
20:43:37 <bubulle> hmm, this should be added to http://wiki.debian.org/DebianInstaller/SqueezeGoals
20:44:12 <bubulle> #agreed cjwatson or fezize should add a mention about missing bits in grub2 for persistent device naming support
20:44:25 <bubulle> #agreed s/fezize/fezie
20:44:49 <bubulle> #topic Release goals - Switch to udhcpc DHCP client from busybox
20:45:01 <bubulle> nothing happened recently, here
20:45:17 <bubulle> #info no progress
20:45:32 <bubulle> #topic Release goals - Switch from console-data to console-setup
20:46:16 <youpi> one thing worth noting is that since xserver-xorg 1.6 got migrated to testing, yet more people are now testing console-setup
20:46:23 <bubulle> youpi: ^^^ no progress, right? Except that you reported several issues?
20:46:25 <youpi> thus more regression feedback
20:46:34 <bubulle> yes, I saw that
20:46:35 <youpi> else, no progress indeed
20:46:53 <mvz> bubulle: you are too fast :)
20:47:22 <bubulle> mvz: too fast moving through topics?
20:47:29 <mvz> re udhcpc, last meething IIRC we said we need decision about making it the default
20:47:47 <mvz> bubulle: yes.. but maybe I'm just slow today, :)
20:47:50 <bubulle> ah, yes sorry missed that
20:48:01 <bubulle> let's go backwards
20:48:06 <bubulle> #topic Release goals - Switch to udhcpc DHCP client from busybox
20:48:08 <mvz> otavio__: could you comment on dhcp client default?
20:48:21 <bubulle> #info: last meeting; "otavio should decide about switching to udhcpc by default instead of dhcp3"
20:48:50 <otavio__> well; it is just a matter of we drop dhcp3-client depends
20:48:57 <bubulle> (chocolate break for me)
20:48:58 <otavio__> if we do that we'll move to it
20:49:18 <otavio> if people agree we could give it a try in dailies
20:49:21 <mvz> much fallout expected, or unknown?
20:49:22 <otavio> and see how it goes
20:49:27 <otavio> mvz: unknown
20:49:32 <otavio> mvz: it is suppose to work
20:49:46 <mvz> then dailies+alpha seems like a good time to try :)
20:50:23 <bubulle> hmmm, I'd vote for dailies only..:)
20:50:48 <Ryan52> bubulle: yes, that is easy to change..could you please? :)
20:51:47 <otavio> I'd say we do it in dailies and then decide about  it during this week
20:51:59 <bubulle> Ryan52: what's you alioth login?
20:52:10 <Ryan52> bubulle: ryan52-guest
20:52:22 <bubulle> otavio: OK, we ask luk__ to do the switch, then?
20:52:45 <bubulle> Ryan52: done
20:52:50 <Ryan52> thanks!
20:52:55 <otavio> bubulle: it is just a matter of upload netcfg
20:53:34 <bubulle> otavio: sure, but that's luk__'s release goal, so.... (and he's not here so we can give him work to do)
20:54:13 <otavio> bubulle: can be; no problem for me
20:54:48 <bubulle> #agreed we change netcfg to use udhcpc by default and either otavio or luk__ upload. We keep this in dailies as of now
20:55:19 <bubulle> #topic Release goals - Add ext4 support
20:56:00 <mvz> done as far as I can tell, except for testing and preventing it in setups where the bootloaders can't handle it
20:56:05 <bubulle> If I'm correct, the alpha release should give this the exposure and testing it needs
20:56:34 <fezie> oh that reminds me that grub2 still has no 64bit support with ext4
20:56:53 <fezie> which matters with fs size > ext3 could handle
20:57:16 <bubulle> fezie: sound like a good candidate for the errata
20:57:47 <mvz> fezie: which size is the limit there? something we're likely to hit during squeeze lifetime?
20:58:02 <bubulle> #agreed document lack of 64bit support with ext4 in grub2: fezie just volunteered..:-)
20:58:17 <bubulle> #agreed --> in the errata file
20:58:23 <fezie> I don't know when INCOMPAT_64bit gets set but that's the flag it doestn't yet support
20:59:14 <mvz> about the other archs
20:59:17 <fezie> according to wikipedia ext3 can handle up to 16 TiB (or even 32 according to the german article)
20:59:46 <otavio> fezie: humm
20:59:47 <mvz> how about adding a whitelist for ext4 on / and /boot for archs that have grub/grub2 as listed in stephano's research?
21:00:12 <mvz> and warn strongly/disallow ext4 on all others
21:00:27 <bubulle> mvz: yes, that seems to be the way to go
21:00:29 <mvz> seems like a safe way to go
21:00:34 <xeon-enouf> yes, but msdos style partition tables only do up to 2TB? (sorry for butting in) so LVM is needed for anything larger?
21:00:34 <bubulle> aha
21:00:45 <mvz> ok, well, then I suppose I volunteer to do that ;)
21:00:58 <fezie> the problem is finding someone who can actually test the 64bit ext4 code
21:01:05 <mvz> xeon-enouf: or gpt
21:01:10 <bubulle> mvz: you know me sooo well..:-)
21:01:11 <xeon-enouf> right
21:01:18 <mvz> bubulle: hehe :)
21:01:33 <youpi> fezie: I used to run qemu with a sparse disk image
21:01:52 <fezie> and that works with creating a file after the size limit?
21:01:57 <bubulle> #agreed add a whitelist for ext4 on / and /boot for archs that have grub/grub2 as listed in sc research (mvz will try)
21:02:08 <fezie> I mean after the 32bit border
21:02:12 <youpi> fezie: I mean, for testing this kind of things
21:02:17 <youpi> I've never tested ext4
21:02:26 <bubulle> anythign to add about this ext4 support goal?
21:02:33 <youpi> just some buggy things in bios/grub, not related to the current discussion
21:02:38 <mvz> do we consider making it the default?
21:02:43 <mvz> I think ubuntu did? (will do?)
21:03:11 <fezie> ubuntu did already
21:03:46 <bubulle> otavio: oh, btw I was about to say "what about parted" but I just discover that it actually just entered testing 2 days ago
21:04:53 <fezie> youpi: well the problem isn't really just a filesystem of that size and having a file at the start, but beyond the border
21:05:07 <mvz> if ext4 default is something we'd want in debian, the earlier the better, methinks
21:05:10 <otavio> bubulle: yes; it has migrated
21:05:18 <mvz> but probably this is an entirely separate question
21:05:37 <bubulle> Folks, it seems to me that we reach the end of important topics to talk about...unless there are other release goals  that had significant progress
21:05:41 <CIA-6> debian-installer: 03ryan52-guest * r60819 10packages/debian-installer-utils/ (debian/changelog fetch-url-methods/tftp): add support for tftp to fetch-url for preseeding (Closes: 509723)
21:05:52 <bubulle> Ryan52: \o/
21:05:57 <Ryan52> bubulle: :)
21:06:00 <bubulle> stop spamming us!
21:06:01 <youpi> fezie: ah, right, one needs to create big files to reach 32bit
21:06:02 <otavio> mvz: yes but I think it is too dangerous to do that just now; better to ask for ext4 specific testing in alpha1 and then we do it for alpha2
21:06:45 <bubulle> otavio: objection to shudown the meeting?
21:06:51 <mvz> otavio: yes, seems very early indeed.. we could see how it goes for ubuntu too
21:06:58 * mvz wants to add some quick points
21:07:05 <bubulle> mvz: go
21:07:08 <otavio> mvz: please do
21:07:49 <mvz> git migration guide: I sort of started, but haven't written much yet. gnome has excellent material for their own migration, I'll see if we can use some of that. would still appreciate if people could point me to specific questions they have, else I run risk of trying to document everything ;)
21:08:25 <bubulle> #topic Additionnal topics
21:08:59 <bubulle> #info from mvz: git migration guide: I sort of started, but haven't written much yet. gnome has excellent material for their own migration, I'll see if we can use some of that. would still appreciate if people could point me to specific questions they have, else I run risk of trying to document everything
21:09:02 <mvz> right now noted as worth documenting: basic git tutorial/guide, typical d-i workflows, more references, where to go with unsolved questions
21:09:36 <mvz> </git-migration-guide>
21:10:01 <mvz> another thing I noticed while searching the wiki for d-i svn docs
21:10:21 <mvz> is is very confusing to navigate right now, at least to me
21:10:38 <mvz> wild mixture of user-targetted, devel-targetted, current, obsolete information
21:11:02 <mvz> we have e.g. the workaround notes for crypto-on-raid (which was relevant for etch, I think?) in a very prominent place
21:11:21 <bubulle> mvz: yes, franklin wanted to brush out the D-I wiki, but had other things to do since then
21:11:24 <mvz> if anyone is bored and looking for something to do, restructuring the wiki a bit would be very worthwile IMHO :)
21:12:09 <mvz> ok, I think that's all I wanted to add
21:12:31 <otavio> mvz: yes; indeed
21:12:36 <otavio> mvz: i fully agree
21:13:26 <mvz> bubulle: btw, is there svn-specific documentation for translators?
21:13:46 <mvz> bubulle: I'd want to update that for git specifically
21:14:01 <mvz> (once we decided to do the switch, of course)
21:14:15 * bubulle just fixed the "How to work around problems with combined RAID + crypto setups" page reference in the wiki home page
21:14:34 <bubulle> mvz: i18n doc in installer/doc/i18n
21:15:03 <mvz> #info d-i wiki is confusing and could use a restructuring; anyone interested please contact franklin and/or debian-boot
21:15:13 <bubulle> as translators are supposed to work in packages.po, which is kept in SVN, the change should be minial, indeed
21:15:14 <mvz> bubulle: thanks, I'll have a look
21:15:17 <otavio> :-)
21:15:25 <mvz> ah, ok, I didn't realize that
21:15:51 <bubulle> Sp, now I think we can close the meeting
21:15:52 <mvz> bubulle: so l10n-sync takes the master .po from svn, and syncs to the individual git repos?
21:15:59 <bubulle> mvz: yes
21:16:14 <bubulle> this is why "mr" is so useful for it
21:16:22 <mvz> oh I see :)
21:16:51 <bubulle> actually the switch is mostly calling l10n-sync with "--svn='mr -p -j4'"
21:17:52 <bubulle> the only drawback being the commit storms when PO files are updated in all packages (which doesn't happen very often indeed)
21:18:37 <bubulle> the storm on Sunday happened because the gitdemo repo was missing many l10n-sync runs
21:19:16 <bubulle> anyway, I said we close the meeting so I should stop talking and do the boring post-meeting work
21:19:23 <bubulle> #endmeeting