20:03:29 <otavio> #startmeeting
20:03:36 <otavio> Finally :-D
20:03:57 <otavio> Ok people, to it to be logged, let's say hello :-)
20:04:02 * otavio waves
20:04:05 <fezie> hello
20:04:05 <waldi> hello
20:04:06 <youpi> hello
20:04:09 <joeyh> hi
20:04:10 <mvz> hellooo
20:04:11 <zumbi> hello
20:04:16 <gaudenz> hello ;-)
20:04:17 * bdale is lurking
20:04:23 <aurel32> hello
20:04:30 <slackydeb> hello
20:04:52 <otavio> Cool :-) First I'd like to welcome everybody
20:05:32 <otavio> And before beggining I'd say that I'm in a bad time at work and then I'll try to be fast in topics
20:06:05 <otavio> Anyone wants to suggest any specific topic for the meeting?
20:06:40 <otavio> Otherwise I'll start with a "Alpha 1 to be done things"
20:07:12 <otavio> #topic Alpha 1 to be done things
20:07:29 <otavio> So ...
20:07:36 <gaudenz> otavio, if there is time we could discuss how to integreate the openmoko work
20:07:49 <otavio> We still have kernel issues and parted things to solve for alpha 1
20:08:10 <mvz> I can give a quick status on the PAT issue
20:08:11 <aurel32> what are the problem with parted?
20:08:16 <otavio> At parted side, I guess I fixed the version problem yestarday and will try to get it uploaded today
20:08:23 <otavio> aurel32: version problem
20:08:27 <aurel32> ah I see
20:08:33 <otavio> aurel32: if you can, you could give it a try
20:08:50 <otavio> aurel32: yes; otherwise we can't ask it to go to testing
20:09:28 <otavio> so if it finally solves it we can then prepare parted migration to testing
20:09:48 <otavio> mvz: could you give us the PAT status update?
20:09:51 <mvz> sure
20:10:02 <aurel32> yes I can give a try if you want (not sure today though)
20:10:07 <mvz> so upstream has narrowed down the problem and made a proposed patch
20:10:18 <mvz> amd64 build with the patch applied at http://people.debian.org/~xam/d-i/patfix/
20:10:29 <mvz> it was tested successfully by fezie (vmware,qemu)
20:10:42 <mvz> the patch is supposed to go onto lkml soonish (today, actually)
20:11:19 <mvz> after that? we need it in linux-2.6
20:11:33 <otavio> waldi: can you speed it up for us?
20:11:34 <mvz> waldi: when could it be added? after upstream merge?
20:12:00 <waldi> mvz: after review/merge. depends on the arguments
20:12:01 <otavio> waldi: if you could get it applied before would be nice since it is a wird problem from d-i POV
20:12:18 <otavio> waldi: so could you review it?
20:12:33 <waldi> sure, just send me a pointer
20:12:55 <mvz> waldi: http://bugzilla.kernel.org/show_bug.cgi?id=13877
20:13:24 <mvz> btw
20:13:29 <waldi> mvz: mail on linux-kernel?
20:13:36 <mvz> 2.6.30 in testing \o/
20:13:39 <mvz> thanks to everyone involved :)
20:13:50 <otavio> #agreed waldi is going to review the PAT proposed patch and comment if it is possible to apply it ASAP
20:13:57 <mvz> waldi: ah, that not yet. venkatesh said he'll send it
20:14:10 <mvz> waldi: will send you a link once it appears on lkml
20:14:20 <otavio> Ok
20:14:42 <otavio> Is anymore aware about any other blocker for alpha 1?
20:14:59 <otavio> To be honest I still have backlog to read on ml so I can have missed something
20:15:23 <waldi> busybox have some problems with missing ttys
20:15:28 <gaudenz> #541115?
20:15:44 <gaudenz> that's the relevant bug number
20:15:53 <otavio> waldi: are you tracking it? is it already sent upstream?
20:16:16 <waldi> otavio: its a debian patch
20:16:32 <otavio> waldi: ouch!
20:16:35 <waldi> i mangled the logic during the last update
20:16:46 <otavio> waldi: are you working on a fix for it?
20:16:53 <waldi> otavio: the other solution is to drop /dev/tty* from the inittab. yes
20:16:56 <otavio> waldi: gotcha
20:17:19 <waldi> i just wanted to test it, by the installer don't want to start in qemu
20:17:47 <otavio> waldi: I prefer to try to get it back  and then later we can revisit it and try to not use /dev/tty in inittab for installer
20:17:58 <otavio> waldi: so it don't block alpha1 due that
20:18:01 <otavio> waldi: ok
20:18:38 <otavio> #agreed waldi is going to deal with #541115 (busybox' missing tty bug)
20:18:53 <zumbi> i can try to help on that one
20:19:01 <otavio> Besides that any other blocker?
20:19:23 <otavio> waldi: then you could point the patch for zumbi to test it too
20:19:46 <zumbi> otavio: i would be more interested on pursuing the real fix
20:20:15 <otavio> zumbi: it looks like waldi has already did it
20:20:26 <otavio> zumbi: so it  would duplicate work ATM ;-)
20:20:35 <otavio> waldi: am I missing something?
20:20:53 <waldi> zumbi: i only know what needs to be done, not how it would work after that
20:22:53 <otavio> Any other block?
20:23:12 <otavio> mvz: from partman POV is there any issue to be solved before  a1?
20:23:24 <mvz> not that I'm aware of right now
20:24:28 <mvz> ah, just for planning, one question
20:24:39 <mvz> say we manage to solve the remaining blocker in one week
20:24:59 <mvz> after that, when could we be ready to release alpha1?
20:25:36 <mvz> probably many testing migrations to do since lenny? /me guessing
20:26:06 <otavio> mvz: the migrations are going to be fast (mostly udebs done by us)
20:26:29 <aurel32> probably related, is it still possible to upload udebs now for kfreebsd changes? or will it break testing migration?
20:28:32 <otavio> aurel32: i don't know
20:28:35 <otavio> luk_: ?
20:29:08 <aba> aurel32: up to now there is no udeb for kfreebsd?
20:29:19 <aba> if so, uploading it won't have any impact.
20:29:46 <aurel32> the question is about source uploads, does it means we will have to wait 10 days to propagate them to testing
20:29:46 <aba> (the only impact it could have would be a positive one - unless one of you here asks us to not migrate because of that udeb)
20:29:55 <otavio> aurel32: no
20:30:00 <aurel32> ok
20:30:08 <otavio> aurel32: we can ask RM team to unblock and age them according
20:30:45 <aurel32> anyway I am currently targetting very few of them, I won't have a lot of time to do too many uploads
20:30:57 <otavio> aurel32: OK; please go ahead
20:31:10 <otavio> aurel32: and then we handle it for the release
20:31:26 <aurel32> cool, thanks
20:31:31 <otavio> aurel32: obviously kfreebsd won't be functional in a1 but we can try for a2
20:32:01 <otavio> #topic Proposed GIT migration
20:32:05 <aurel32> when is planned a2?
20:32:18 <otavio> joeyh: can you tell us how is it going?
20:32:43 <otavio> aurel32: a2? no idea yet but I hope as soon as a1 is done we can have it more or less know
20:33:10 <aurel32> ok
20:33:29 <joeyh> otavio: well, I was hoping fjp would be here, but I see he may want a few more days to look at the sample conversions
20:33:39 <otavio> aurel32: probably 2.6.31 will be release in meantime and then it will be the right time for the updating
20:33:58 <joeyh> at this point it's up to the team to make a decision about it
20:34:35 <otavio> joeyh: right
20:34:40 <mvz> #link http://lists.debian.org/debian-boot/2009/08/msg00308.html
20:34:49 <otavio> joeyh: do you think we'd have gain doing it?
20:35:18 <joeyh> sure, that's why I spent several weeks on it
20:35:40 <otavio> joeyh: cool
20:35:53 <otavio> anyone wants to comment about the GIT migration proposal?
20:35:55 * mvz adds a voice of support :)
20:36:00 <waldi> joeyh: could you elaborate them?
20:36:15 <mvz> (I'm already using the test conversion for local hacking; note that this is not necessarily a good idea.)
20:36:40 <joeyh> waldi: since most of the core contributors are using git already, it would be better for them to use a real, shared git repo
20:36:48 <otavio> #agreed we'll wait for Frans' comments about the proposed migration to decide about it
20:36:59 <joeyh> also we see projects the the kfreebsd port that are using branches etc and would be better served by git
20:37:06 * gaudenz supports the migration as well
20:37:32 <joeyh> also, there are a lot of patches that float around in the mailing list, individual's laptops, etc, that don't get into svn, but would have a better chance being published in a git branch
20:37:59 <youpi> yes
20:38:00 <joeyh> and finally there are d-i derivatives, including ubuntu, that it would be useful to get into the same version control
20:38:09 <gaudenz> I'm a bit concerned that adding another tool on top of git (mr) would make it harder than necessary for new contributors.
20:38:18 <otavio> joeyh: specially major works like wpa integration for netcfg, for example
20:38:45 <zumbi> [OT] and could we have a patchwork like system on the mailing lists for such cases (lost patches)
20:38:48 <mvz> gaudenz: mr is not required for individual packages or the debian-installer package itself
20:39:04 <mvz> it is used to assemble a "complete" tree like the current svn trunk
20:39:05 <joeyh> gaudenz: I don't know if we want mr or not. It was an easy way to check out all the git repos to match the current svn tree
20:39:12 <gaudenz> Do ppl really work on individual packages?
20:39:26 <joeyh> I suspect some classes of contributors will only want one or two of the repositories
20:39:30 <gaudenz> I don't really see a use case for not checking out the whole of d-i
20:39:40 <otavio> gaudenz: many people do
20:39:44 <otavio> gaudenz: indeed
20:40:15 <otavio> gaudenz: most people do not do a full checkout specially when beggining to work on d-i
20:40:20 <joeyh> zumbi: yeah, I don't think git will entirely solve it, but being able to git-am a patch from the mailing list will at least help=
20:40:33 <otavio> joeyh: yes;
20:40:55 <gaudenz> otavio, It's probably my porters perspective then, while porting you touch a lot of packages.
20:41:13 <otavio> I think PatchWork is a nice tool (I use it in OE project) but it needs to be cleaned from time to time or it loses its propouse
20:41:20 <joeyh> oh, one other thing.. we have some packages in d-i that have a broader use outside d-i .. like debootstrap and busybox, and maybe cdebconf
20:41:44 <joeyh> having separate git repos for those might get some more involvement from outside d-i which couldn't hurt
20:41:45 <otavio> joeyh: and win32-loader and os-prober
20:42:19 <otavio> joeyh: indeed
20:42:24 <otavio> Ok
20:42:37 <mvz> I briefly looked at git submodules for d-i
20:42:38 <otavio> Any other comment in the topic or we can move to next one?
20:42:40 <joeyh> also, I wanted to get any feedback from anyone on the stuff I left out of the git conversion (like whole-tree branches and tags), etc
20:42:45 <otavio> mvz: ohh nice
20:42:46 <otavio> mvz: and?
20:42:52 <mvz> they seemed like an alternative, but I don't think we can use them in the current form
20:42:57 <joeyh> if anyone has stuff in /people that should be converted, etc
20:43:08 <mvz> they refer to subrepos by commit id
20:43:15 <mvz> so you can't just pull in HEAD of all subrepos
20:43:31 <mvz> the update of submodules must be made explicitly, and be committed
20:43:41 <joeyh> mvz: or automated somehow by post-commit hooks
20:43:53 <mvz> yeah, that could work I think
20:44:03 <joeyh> but I'm very skeptical of the submodule UI
20:44:04 <otavio> joeyh: but in this case we'd have daily snapshots
20:44:18 <otavio> joeyh: yes; the UI is far from nice
20:44:19 <otavio> heh
20:44:23 <mvz> it seems much more cumbersome to use than mr
20:44:33 <joeyh> http://progit.org/book/ch6-6.html <-- good coverage of submodules, including their problems
20:44:59 <gaudenz> one other concern about the individual repo aproach I have is that it will no longer be possible to make tags on the whole of d-i
20:45:02 <otavio> #url http://progit.org/book/ch6-6.html
20:45:14 <joeyh> the detached head problem would also be a big problem using submodules
20:45:18 <gaudenz> like tag the a1 release
20:45:36 <joeyh> gaudenz: yes, that's what I was talking about above WRT whole-tree tags and branches
20:45:50 <joeyh> the tagging .. is actually a use case for submodules
20:46:17 <otavio> gaudenz: yes; this is a problem but to be sincere I don't think it is so useful to block us to move to git
20:46:31 <waldi> the tagging needs to work on the versions anyway, so if the script uses one repo or many is not that relevant
20:46:36 <otavio> gaudenz: but as joeyh said, submodules could be used for this usecase
20:47:32 <joeyh> we've used release branches before to do eg, -1etch1 releases.. but you could probably just make the branch on a per-package basis when you need to do such a release?
20:47:33 <otavio> gaudenz: because even though we release d-i as a whole, it is made by small sub modules that are released so ...
20:47:45 <otavio> gaudenz: i'd think it mostly like Xorg release, for example
20:47:58 <otavio> joeyh: yes
20:48:12 <otavio> joeyh: that is what I think we'd end doing
20:48:37 <otavio> joeyh: and if we look closer we just used the 'tree branch' because d-i was a single repository
20:48:58 <otavio> joeyh: otherwise making the change only where it is required looks more logical for me
20:49:17 <mvz> waldi: what's your take on the switch to git?
20:49:31 <mvz> your mail to -boot seemed critical, but I'm not sure I understood correctly
20:49:43 <gaudenz> otavio, joeyh, get me right, I'm not against the git migration, it's just that a whole tree would better suit the work I do, but I'm fine either way.
20:50:19 <joeyh> gaudenz: I'm not unfamiliar with some d-i mod ending up spreading out to touch half the tree :)
20:50:50 <otavio> gaudenz: commiting works but you'd force anyone that would like to work on a specific module to have whole d-i around
20:50:51 <joeyh> but it's not *too* hard to learn "mr commit -m" if you need to commit such a thing
20:50:52 <mvz> another open question, maybe for later: l10nsync
20:50:59 <waldi> mvz: my workflow does not fit into the git one and often just ends in frustration
20:51:20 <otavio> mvz: this ought to be trivial to move from one to another
20:51:32 <joeyh> mvz: your l10n branch idea?
20:51:36 <otavio> mvz: and maybe mr could be used to make it more simple
20:51:44 <otavio> mvz: l10n branch?
20:51:49 <mvz> joeyh: perhaps, I'm not sure
20:52:01 <mvz> ideally we'd want translations to be individual commits by the translation authors, I think
20:52:28 <mvz> another point was very noisy history due to l10nsync
20:52:52 <mvz> I've been playing with history rewriting, but havent really gotten anywhere with it :)
20:53:29 <mvz> maybe I manage to do a proposal for next meeting
20:53:32 <joeyh> I'd be more interesting in making it less noisy going forward. The current noisy history we already have, and it's not often a big problem..
20:53:53 <otavio> joeyh: right
20:53:54 <mvz> ok, I think I'd agree with that
20:54:11 <waldi> joeyh: move the l10n generation into the release process, aka don't manage the files in the scope of the packages?
20:54:16 <otavio> maybe we could have a way to  trigger the commiting byhand
20:54:22 <joeyh> waldi: been thinking about it.
20:54:33 <otavio> so we do it once before uploading
20:54:35 <joeyh> not clear how it'd work tho
20:54:47 <mvz> similar to output-l10n-changes perhaps?
20:54:54 <otavio> yes
20:54:55 <mvz> "sync-l10n-changes" ;)
20:54:56 <otavio> mvz: indeed
20:55:00 <joeyh> maybe, but it needs to be able to find packages/po
20:55:19 <joeyh> and if you forget to do it during a debug build, you're not testing the right build
20:55:30 <otavio> mvz: it could be replaced for something to instead of output  authors it could also do the changes
20:55:37 <mvz> hm, yes, that could be tricky
20:55:45 <mvz> perhaps we should discuss again next meeting with bubulle around
20:55:52 <otavio> yes
20:56:07 <otavio> can we move to OpenMoko merging topic?
20:56:16 <joeyh> I'd like to not block the git transition on l10n stuff tho
20:57:17 <otavio> joeyh: agree
20:57:17 <mvz> yes, no harm in continuing the way we currently do
20:57:38 * otavio needs to go :(
20:57:46 <otavio> can we move to OpenMoko merging topic?
20:57:47 <gaudenz> any time frame for the git transition apart from fjps agreement?
20:58:11 <otavio> gaudenz: not yet; it is still a proposal
20:58:26 <otavio> gaudenz: after the comments from Frans we can then decide it
20:58:31 <mvz> waldi: thanks for explaining
20:58:32 <gaudenz> the git transition would probably render to openmoko topic mood
20:58:37 <otavio> gaudenz: and the migration should be fast  if we decide for it
20:58:50 <gaudenz> s/mood/moot/
20:58:55 <otavio> #topic OpenMoko merging?
20:58:58 <mvz> gaudenz: why that?
20:59:02 <otavio> gaudenz: can you talk about it?
21:00:21 <gaudenz> I currently have a pile of local patches I'd like to submit and then commit somehow.
21:00:49 <gaudenz> But there is currently no kernel support in the debian kernel. 2.6.31 will have basic support.
21:01:04 <waldi> i have not seen complete patches for the kernel
21:01:09 <gaudenz> Question is if it's worth to have a branch for my work
21:01:32 <gaudenz> waldi, only the 6 lines patch introducing s3c2442b is missing
21:01:47 <waldi> gaudenz: depends on the amount of changes
21:01:51 <gaudenz> It just got lost, but I've not seen any opposition
21:02:10 <otavio> gaudenz: I guess it would be nice for your work and also for people to be able to play with it
21:02:25 <otavio> gaudenz: merging stuff needs to be decided case by case
21:02:59 <gaudenz> Is there a way in the build system to disable a flavour? So it can be commited, but deactivated for builds.
21:03:12 <otavio> gaudenz: so I'd say to you to send the proposed changes for mailing list for review
21:03:21 <otavio> gaudenz: an image, yes;
21:03:38 <gaudenz> I'll do as soon as the subarch name is decided. See lucas mail
21:03:49 <otavio> gaudenz: ok
21:04:12 <otavio> gaudenz: so please send it and then it is easier for us to comment and decide about each change
21:04:38 <mvz> cool, PAT fix just hit lkml
21:04:45 <otavio> mvz: cool
21:04:48 <mvz> waldi: 1250540630.2709.193.camel@sbs-t61.sc.intel.com (not yet in web archive)
21:05:01 <gaudenz> #link http://lists.debian.org/debian-boot/2009/08/msg00410.html
21:05:17 <waldi> mvz: i have a linux-kernel subscription ...
21:06:15 <otavio> Anyone wants to discuss anything else during this meeting?
21:06:36 <otavio> take 1
21:06:37 <waldi> i had one point, but i'm unsure
21:06:44 <otavio> waldi: please go ahead
21:07:34 <waldi> currently all dos-partition table tools uses the arbitrary 63 sectors count for aligning the data
21:07:46 <otavio> waldi: yes
21:08:04 <otavio> waldi: parted is probably moving to 1mb by default
21:08:35 <waldi> i would have proposed 2^21, but anything 2^x with x > 18 is okay
21:09:32 <otavio> waldi: maybe you could take a look on parted ml archive about it?
21:09:38 <otavio> waldi: and raise it there?
21:09:43 <waldi> otavio: i hope the partition-refit code is trashed
21:09:49 <waldi> yep
21:10:14 <waldi> (the one that trashed all vista and above partitions by default ...)
21:11:05 <mvz> ouch. does this affect lenny too?
21:11:18 <waldi> no
21:11:49 <waldi> i just hope that this code is completely gone in the meantime
21:13:14 <otavio> waldi: i'm unsure about it
21:13:36 <otavio> waldi: so can we queue it  again for next meeting?
21:13:41 <waldi> yes
21:13:46 <otavio> waldi: and I think it would to be done in ml too
21:13:50 <otavio> waldi: and parted ml
21:14:03 <otavio> waldi: so we have both sides covered
21:14:09 <otavio> Anyone else?
21:14:20 <otavio> otherwise I'll close the meeting
21:14:27 <mvz> last point from meeting topics would be "# timeline and status 'Main Goals' for Squeeze "
21:14:54 <mvz> postpone to next?
21:15:24 <otavio> mvz: for me it would be better
21:15:40 * mvz tries to keep SqueezeGoals wiki page uptodate when he hears of changes
21:15:54 * otavio thanks mvz for that
21:16:16 <otavio> #endmeeting