21:00:08 <bubulle> #startmeeting
21:00:08 <blindvt> bubulle, eh. thanks so much, you saved my day/DNS setup fiddling ;)
21:00:08 <MeetBot> Meeting started Mon Nov 16 21:00:08 2009 UTC.  The chair is bubulle. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:08 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
21:00:14 * otavio waves
21:00:52 <bubulle> otavio: last meeting, you were mostly alone. This time we're apparently the 2 of us..:-)
21:01:29 <otavio> bubulle: yes; we aren't lucky those days
21:02:00 <bubulle> well, the lack of activity on the ML (except work by fjp) doesn't help that much...
21:02:19 <blindvt> ok, so what's the status of quik (apparently a ppc bootloader that doesn't quite work for me; I don't know zilch about that kind of box, admittedly).
21:02:35 <bubulle> so we can probably start on the one and only topic: release
21:02:38 <otavio> yes; but we have been hold by DAK changes
21:02:59 <bubulle> otavio: sure, but they're away now, right?
21:03:00 <otavio> we're still waiting for linux kernel udebs for mips to pass thorught NEW queue
21:03:20 <otavio> bubulle: somewhat but NEW queue still holds we up
21:03:35 <otavio> Ganneff: any ETA for mips udebs processing?
21:04:03 * mhy looks
21:04:04 <blindvt> Just today i've setup a qemu-system-ppc box with the daily build of the netinstall mini.iso; It prompted me for kbd layout twice (which may or may not be fixed by fjp's recent ci, didn't look)
21:04:11 <mhy> otavio: uhm
21:04:12 <mhy> linux-kernel-di-mips-2.6_1.17_multi.changes
21:04:12 <mhy> REJECT
21:04:12 <mhy> The key (0x2EA8994049A5F855) used to sign linux-kernel-di-mips-2.6_1.17.dsc wasn't found in the keyring(s).
21:04:15 <bubulle> any other things that need to get done before the release process starts?
21:04:18 * mhy scratches his head
21:04:30 <mhy> otavio: have you changed your key recently?
21:04:37 <bubulle> blindvt: see mailing list. These topics are currently handled (more or less)
21:04:52 <otavio> mhy: It has been changed today? :-)
21:04:57 <blindvt> bubulle, k, /me takes mental note
21:05:23 <mhy> otavio: I'llk talk to you about it after the meeting
21:05:46 <otavio> mhy: this is my 1024 bit key; my new 4096 has been waiting to get in for 4 weeks or so
21:05:49 <otavio> mhy: ok
21:05:50 <bubulle> otavio: what about the new cdrom-detect and di-utils? It seems that cdrom -detect breaks some builds, right?
21:06:04 * otavio looks
21:06:22 <mhy> otavio: I might need you to re-upload with a new signature then
21:06:33 <mhy> otavio: as the change seems to have propogated
21:07:04 <otavio> mhy: ok; we can do it after meeting then. No problem for me.
21:07:09 <blindvt> again from my (innocent bystander's POV) there are 2 points open: you use the somewhat ancient 1.14.x busybox and should bump that to 1.15.2; You use a >1.4MB (!!) libc instead of uClibc (<< estimated 500k)
21:07:14 <mhy> otavio: I'll reject the existing upload
21:07:41 <otavio> blindvt: sorry but let's talk about it after meeting?
21:07:56 <otavio> mhy: ok
21:08:09 <otavio> bubulle: coming back ...
21:08:10 <bubulle> blindvt: well, please don't jump on topics randomly....the ML, again is probably more appropriate for this
21:08:24 <blindvt> The former -- busybox bump -- may not be too pressing since you're somewhat up to date; But wasting a couple of MB for a gazillions of users is just gross ,again IMH(biased)O
21:08:41 <otavio> bubulle: I did the cdrom-detect upload since Debian Live needs the fix on 1.32
21:08:44 <blindvt> k. sorry
21:08:49 * blindvt -v
21:09:16 <bubulle> otavio: so that needs to go to testing and so does di-utils that seems to go with it
21:09:53 <otavio> bubulle: yes; di-utils is howding few builds to happen
21:09:56 <bubulle> So, as blockers we have the linux kernel udebs for mips, cdrom-detect to enter testing and same for di-utils
21:10:06 <otavio> bubulle: and since cdrom-detect depends on newer di-utils it has broken builds
21:10:31 <otavio> bubulle: both are fast to solve once we have DAK in shape (looks it happened today)
21:10:34 <otavio> mhy: right?
21:11:16 <mhy> otavio: dak is mainly fixed, yes
21:11:17 <otavio> bubulle: localechooser changes are also important to have in
21:11:31 <bubulle> otavio: yes, I was about to talk about them
21:11:33 <mhy> otavio: although I've a suspicion you'll trip us up again at the actual d-i release with the byhand stuff
21:11:36 <otavio> bubulle: BTW, can you comment about fjp and collin changes?
21:11:47 <bubulle> fjp is doing great job which we definitely want in a release
21:11:55 <otavio> mhy: hah; I'll be do my best ;-)
21:12:07 <bubulle> I think I'm on fjp's "side"
21:12:18 <otavio> bubulle: any reason?
21:12:39 <bubulle> the test images he produced are very impressive and I think he has a consistent rationale for the various changes
21:13:08 <otavio> bubulle: what about the mobile use-case presented by cjwatson ?
21:13:23 <otavio> bubulle: do you believe it handles it as well?
21:13:30 <bubulle> about the disagreement with cjwatson, I think that Frans arguments are fair and he's adressing the original motivations of Colin by his changes to localechooser
21:13:53 <otavio> right
21:14:40 <bubulle> otavio: "mobile use case". I need to come back on the thread to exactly answer
21:15:24 <otavio> bubulle: about the crazyness of someone that live in a place that talks a completely different language and he wants to use his computer as his born place and like.
21:15:35 <otavio> bubulle: but IIRC it addresses it as well
21:16:02 <bubulle> otavio: that was my test opf someone installing in Italian while living in Argentina and wanting a Swiss Italian locale
21:16:15 <bubulle> perfectly addressed by fjp changes..:-)
21:16:16 <otavio> bubulle: yes; I recall it now
21:16:33 <otavio> bubulle: so I think I support your and, by conseguence, fjp side :-)
21:17:04 <otavio> bubulle: in this case we need to revert cjwatson changes and go with fjp proposed ones as well
21:17:11 <bubulle> so, as said, and with all respect due to Colin (I think everybody knows how high I place it), I think that changes proposed by Frans are the way to go.
21:17:33 <otavio> bubulle: I think fjp is the best person to handle the migration to his proposal
21:18:13 <otavio> bubulle: the only pro I see for Colin's proposal is that it doesn't increase the initrd size (but runtime size it does)
21:18:28 <bubulle> yes...and I think we need all his pending work about these issue in the release. Not delay the release for it if possible (but, well, it's already delayed a lot anyway)
21:18:47 <otavio> bubulle: but fjp's one increases initrd a bit only and don't much at runtime
21:18:52 <bubulle> the chang ein initrd size in fjp proposal is not that big
21:19:02 <otavio> bubulle: do I'm fjp proposal too
21:19:26 <otavio> yes, we should focus in getting it all into release
21:19:33 <bubulle> what I like in both proposals is offering the possibility to choose UTC during interactive installs
21:20:01 <otavio> so let's talk to him and ask for him to upload the pending stuff and sort of "freeze" uploads for release then
21:20:17 <bubulle> for all these connected together changes, I think that Frans can (if he's OK to) coordinate the migraiton of the needed material
21:21:09 <otavio> bubulle: for this release the migration is quite easy; basically migrate everything. For next one it is harder since we want to avoid breaking testing installer
21:21:16 <otavio> bubulle: but this one it is trivial
21:21:16 <bubulle> otavio: what about partman-ext3? We still have 55 in testing and 58 in unstable
21:21:25 <otavio> bubulle: it is due mips udebs
21:21:33 <bubulle> arrrrrr
21:21:48 <otavio> bubulle: partman-ext3 depends on ext4 and it has not added on mips by mistake
21:22:54 <bubulle> otavio: could you by any chance try to build a release timeline so that we're not in the dark?
21:23:12 <bubulle> There might be some unknown variables but still, that could help
21:23:23 <otavio> bubulle: as soon as NEW queue is handled we can; otherwise is just a darness for everyone
21:23:55 <bubulle> mhy: any chance that di-related things get high priority in NEW processing?
21:24:36 <otavio> bubulle: they do; it was technical issues that made it to delay
21:24:43 <otavio> mhy: :)
21:25:14 <bubulle> ah, so we can say that we do'nt release because of the evil ftpmasters? Gooood
21:25:33 <otavio> mhy: can we, after meeting, handle mips udebs together? so it is not stuck again?
21:25:37 <bubulle> (for anybody not aware of this, the above is a P.U.N.
21:25:42 <otavio> bubulle: sure. It is all their fault :P
21:26:13 <otavio> bubulle: no; we had a lot of things changing but indeed DAK changes has come in a bad time since we were finally getting in the release time.
21:26:16 <mhy> otavio: yes
21:26:18 <otavio> bubulle: but it is done now.
21:26:25 <mhy> bubulle: you should have said eeeeeeeeeeeeeeeeeeevilllll
21:26:26 <otavio> bubulle: so it will work fine from now on
21:27:06 <otavio> mhy: good
21:27:09 <otavio> mhy: lol
21:27:22 <bubulle> well, then I propose we don't make the meeting last for too long, then and just leave you guys time to work on these issues..:-)
21:27:49 <otavio> bubulle: any other thing to handle today?
21:28:13 <otavio> mhy: I'm building mips udebs right now
21:28:33 <bubulle> not really: all I had in my mid was: release and "locale"related" stuff
21:28:52 <mhy> can I Just ask, as I'm here, what the svn/git status is?  Or should I wait for AOB?
21:28:59 <bubulle> otavio: what I'd like to propose is having a short meeting in a few days to see where we are
21:29:03 <mhy> I'm just a bit confused due to the appearance of git modules on git.d.o
21:29:18 <otavio> bubulle: sure; we can schedule something for end of this week?
21:29:28 <otavio> mhy: my idea is to push it after a1 release
21:29:39 <otavio> mhy: and I do support the migration
21:29:40 <bubulle> otavio: except that I'll be away on Sat+Sun, yes..:-)
21:29:51 <bubulle> I should be back home on Sun evening, though
21:29:52 <otavio> bubulle: we can do it at Thu
21:29:59 <otavio> bubulle: or monday
21:30:29 <otavio> bubulle: however as soon as I get unblocks added and new processed we can have a kind of schedule for release
21:31:36 <bubulle> OK, let's say a small meeting on Thu, but 21:30 UTC if you don't mind (and no more than 30 minutes, preferrably)
21:31:51 <otavio> bubulle: can be
21:31:56 <bubulle> then we'll see on Thu if we need another such very focused meeting
21:32:07 <otavio> bubulle: suer
21:32:13 <otavio> bubulle: sure
21:32:34 <bubulle> ok, then...let's close the meeting unless there is somethign I'm forgettign
21:32:51 <otavio> bubulle: please do
21:32:58 <bubulle> #endmeeting