[00:03] <kees> ogasawara: is aufs supposed to work in the .34 kernels?
[00:03] <ogasawara> kees: I'd assume it should, we haven't touched it
[00:04] <kees> ogasawara: hrm, it is misbehaving.  I will dig further and file an actual bug report.  :)
[00:05] <ogasawara> kees: thanks. can you ping me or JFo with the bug # once you have it.
[00:05]  * kees has to figure out how to use it in a non-schroot context first.  :)
[00:06]  * bjf taking off for a bit
[00:17] <kees> jjohansen: (from the other channel) yeah, aufs is in there, and it seems that manual usage works.  schroot doing it results in weird states... /me tries some more
[00:18] <jjohansen> kees: yeah I know aufs is there, /me just wasn't sure if it needed updating to have it work properly on .34
[00:18] <kees> # umount /var/lib/schroot/mount/maverick-i386-58acab8c-28d3-4044-994a-403cc650acc0
[00:18] <kees> umount: /var/lib/schroot/mount/maverick-i386-58acab8c-28d3-4044-994a-403cc650acc0: device is busy.
[00:18] <kees> fuser says:
[00:18] <kees>                      USER        PID ACCESS COMMAND
[00:18] <kees> /var/lib/schroot/mount/maverick-i386-58acab8c-28d3-4044-994a-403cc650acc0:
[00:19] <kees>                      root     kernel mount /var/lib/schroot/mount/maverick-i386-58acab8c-28d3-4044-994a-403cc650acc0
[00:19] <kees> no clue what that's about.
[00:19] <vanhoof> JFo: yo
[00:19] <vanhoof> back now
[00:19] <vanhoof> JFo: on that bug, you looking for a home for it?
[00:20] <kees> OH... getting kernel Oops.  hah.
[00:20] <kees> [  360.979217] kernel BUG at /build/buildd/linux-2.6.34/ubuntu/aufs/f_op.c:84!
[00:23] <jjohansen> kees: sadly not surprising
[00:23] <kees> jjohansen: and aufs isn't upstream, right?
[00:23] <jjohansen> correct
[00:23] <jjohansen> and it never will be
[00:25] <jjohansen> kees: that is one of the reasons we are reevaluating union mounts this cycle
[00:25] <jjohansen> they look like they might finally go upstream soon
[00:26] <kees> right, cool.  in the meantime, I've filed bug 585175
[00:26] <ubot2> Launchpad bug 585175 in linux (Ubuntu) "kernel BUG at /build/buildd/linux-2.6.34/ubuntu/aufs/f_op.c:84! (affects: 1)" [Undecided,New] https://launchpad.net/bugs/585175
[07:03] <lag> Morning :)
[07:20] <cooloney> lag: good morning
[07:20] <lag> cooloney: Hi ya
[08:31]  * apw waves
[08:33] <apw> smb, morning
[08:33] <amitk> morning gentemen
[08:33] <smb> apw, Morning
[08:34] <smb> amitk, dito
[08:34] <apw> moin amitk 
[08:34] <cking> morning
[08:34] <ikepanhc> good morning .eu
[08:34] <smb> cking, Youare required to log in to mumble
[08:34] <apw> moin .ap
[08:35] <cking> smb, ok - firing up
[08:35] <lag> Morning everyone
[08:35] <jk-> hey peeps
[08:44] <jk-> cnd: how come your mumble icons (muted & deafened) have blue crosses instead of red ones?
[08:45] <jk-> oh, muted & deafened by the server?
[08:48] <apw> jk-, muted by me instead
[08:48] <jk-> ah
[08:55] <ikepanhc> eh, is there any update on mumble server?
[08:55] <apw> ikepanhc, shoul 
[08:55] <apw> s
[08:55] <apw> ikepanhc, should be working
[08:56] <ikepanhc> apw: server tells me wrong password..
[08:56] <apw> ikepanhc, the username is changed to be your launchpad accounts email address
[08:56] <apw> note i said email address
[08:56] <ikepanhc> apw: trying, thanks
[09:00] <cooloney> smb: just sent you an email for omap4 branch in lucid
[09:01] <smb> cooloney, No, actually you sent ogasawara that mail. I am not looking at things without a release in the topic that I care
[09:01] <smb> cooloney, Darn
[09:02] <smb> You had it at the end. I am not reading that far at that time of the day
[09:03] <cooloney> smb: i did not send git pull email to ogasawara 
[09:03] <cooloney> smb: i think amitk sent that for adding omap flavor in Maverick
[09:03] <cooloney> smb: but mine is for adding omap4 branch in Lucid
[09:04] <smb> cooloney, I was just bitching about not having a [Lucid][pull request]
[09:04] <smb> cooloney, Is that a new topic branch or should replace the current ti-omap?
[09:04] <cooloney> smb: ok, next time i will take care of that.
[09:04] <cooloney> smb: oh, it is a new branch 
[09:05] <cooloney> smb: won't replace ti-omap
[09:05]  * apw watches smb cry
[09:05]  * smb looks for something to strangle cooloney 
[09:05] <apw> cooloney, whats its base version ?
[09:05] <smb> .33 it seems
[09:05] <cooloney> since ti-omap for omap3 machine
[09:05] <cooloney> yeah, .33
[09:05] <cooloney> apw: ^^
[09:05] <amitk> cooloney: call it ti-omap4 (or something)
[09:05] <smb> amitk, he has
[09:06] <cooloney> yeah, it is ti-omap4
[09:06] <apw> was ti-omap a .33 kernel too ?
[09:06] <amitk> yes
[09:06] <smb> amitk, Just that I am so very happy to take in yet another topic branch that needs care
[09:06] <cooloney> rihgt.
[09:06] <apw> smb, you can't take it till someone handles the MIR
[09:06] <amitk> smb: I'm sure you are (Father Hen counting his chickens)
[09:06] <apw> and the FFE, and all the other paperwork
[09:06] <smb> cooloney, amitk Can't you guys get one tree per manufacturer
[09:07] <amitk> smb: someday (hopefully before I lose all my hair)
[09:07] <cooloney> smb: it is difficult. so we created 2 branches
[09:08] <cooloney> even ti has 2 different git tree
[09:08] <smb> cooloney, It is difficult to manage so maybe I just not take it...
[09:08] <apw> just because they cannot maintain a tree doesn't make it right
[09:09] <amitk> apw: they're working on it, we expect to have a single tree for M+1 for TI
[09:09] <amitk> and with luck, it will all be in 'master'
[09:09] <cooloney> right.
[09:10] <cooloney> as amitk said, we are going to make M has omap flavor in master branch
[09:10] <cooloney> and omap4 branch for those patches from ti but not in mainlien
[09:11] <cooloney> but for lucid, i do think we can put them together easily
[09:11] <cooloney> i don't think, sorry
[09:11] <cooloney> smb: this lucid omap4 branch is for TI 10.07 release.
[09:12] <amitk> smb: it only has to be supported until Jan
[09:12] <cooloney> because of the time frame, i picked up our lucid code base for that release
[09:13] <smb> cooloney, amitk I am _very_ reluctant about adding anything to the official repo just based on a pull request
[09:13]  * apw wonders if amitk knows quite how far away january is
[09:14] <cooloney> apw: yeah, it is july
[09:14] <amitk> smb: apw: Perhaps, this isn't very clear, but cooloney doesn't want you to spin new kernels, the binary packages will be done in a PPA. He just wants the git tree in a single place.
[09:14] <amitk> (in a branch)
[09:15] <cooloney> amitk: right, that's point
[09:15] <smb> amitk, Well it will be in the repo. And we were given trees like that before and suddenly there is need to put in security fixes and other generic fixes. And so it is suddenly a bunch of additional work
[09:16] <smb> amitk, cooloney So I want something more official than just "here, pull it"
[09:16] <amitk> ok
[09:17] <amitk> cooloney: ask davidm to send email to u-k mailing list outlining the support requirements for this tree (which should be none)
[09:18] <cooloney> amitk: ok, looks like i don't have any other choice, -:|
[09:26] <apw> amitk, what is the support requirement on ti-omap itself ?
[09:30] <amitk> apw: I'd like to say "standard release - 18months", but you should confirm with davidm
[09:31] <amitk> 10.07 is a special release for TI, so they can ship ubuntu on their new HW. And we throw it away once omap4 is a first class citizen in maverick.
[09:35] <smb> amitk, I hope you are aware that ti-omap currently will receive no stable updates. I have no common base for that and I do not apply .33 patches
[09:35] <cooloney> apw and smb, i have to say the ti-omap4 is very special, so I would talk to guys eariler about that.
[09:36] <smb> cooloney, That would have been a good idea
[09:40] <amitk> smb: understood
[10:16] <lag> Who is responsible for the filesystem in Ubuntu? 
[10:20] <cooloney> lag: i guess it surhbi's area? but she is sick today.
[10:20] <lag> cooloney: Thanks. 
[10:42] <apw> smb that is the range right: 332d90de3fa1254dd49c71882e407a169efddb9e..8eb93181b49f13e241970c358be254d4df9c2419
[10:44] <apw> Linux-2.6.32.11+drm33.2 -> Linux 2.6.32.12+drm33.3
[10:44] <smb> c4176d0557f28a68846aa7de10197aed3d5f78a2..8eb93181b49f13e241970c358be254d4df9c2419
[10:44] <smb> apw, You want to start were I branched
[10:45] <smb> apw, That stable branch is based on last released lucid and has other things since then
[10:45] <apw> 183, phew that sounds better <- smb
[10:47] <smb> apw, Right, given that there are quite a few patches skipped compared to upstream (or replaced)
[10:48] <smb> apw, Note, that I currently skipped the EC changes as we still have a slightly different approach there
[10:48] <apw> ok
[11:00] <lag> What are the different numbers called in linux version? I.e. 2.6.32-21.1 
[11:09] <lag> Something like this perhaps? "version.series.release-abi-minor-flavour"
[11:18] <ikepanhc> cooloney: do you know we shall use -march=armv7a or -march=armv7-a on lucid fsl-imx51 kernel?
[11:19] <ikepanhc> seems cross compiler use v7-a...
[11:19] <ikepanhc> but I dont know how about the native compiler
[11:21] <cooloney> -march=armv7-a when i'm doing cross compiling
[11:21] <ikepanhc> and armv7a for native compiler?
[11:22] <cooloney> i never try on native compiler
[11:22] <ikepanhc> I mean build server
[11:23] <cooloney> right, i think it is the same
[11:23] <cooloney> arch/arm/Makefile
[11:23] <cooloney> arch-$(CONFIG_CPU_32v7)         :=-D__LINUX_ARM_ARCH__=7 $(call cc-option,-march=armv7-a,-march=armv5t -Wa$(comma)-march=armv7-a)
[11:23] <cooloney> the CFLAGS is set in kernel Makefile
[11:24] <ikepanhc> so, we shall use v7-a, not v7a?
[11:24] <cooloney> yeah, v7-a not v7a
[11:25] <ikepanhc> oh, I saw that, a freescale patch modify it. so I need to revert it, thanks
[11:26] <cooloney> cool. i almost remember that patch, they wanna compile the kernel with old toolchain. 
[11:26] <cooloney> so they modified that, 
[11:27] <ikepanhc> ya, that's it
[12:07] <lag> amitk: Is there a better way to push local/branch -> remote/branch than "git push <remote> HEAD" when the remote branch is currently checked out?
[12:08] <amitk> lag: is the remote tree on zinc?
[12:08] <lag> No, it's on a build-server
[12:08] <lag> And has a working tree
[12:09] <amitk> lag: I assume you have ssh access to that machine
[12:09] <lag> When I do "git push <remote> HEAD", I receive a warning about the branch being checked out and I have to do a reset followed by a checkout on each of the remote branches
[12:09] <lag> Yes
[12:10] <amitk> in which case, have you setup you .git/config to push using ssh?
[12:10] <lag> If that's the way to do it, then fine. I just thought there may be a better way
[12:10] <amitk> [remote "zinc"] url = ssh://amitk@zinc.ubuntu.com/srv/kernel.ubuntu.com/git/amitk/maverick.git
[12:10] <lag> Yes, I've done that
[12:10] <lag> That's how my push works
[12:10] <amitk> ok
[12:10] <amitk> git push <branch name> should work
[12:11] <lag> It's happy to do it, but because the branch is checked out on the remote server (as that's where I'm building), it complains 
[12:11] <lag> Okay, I'll give it a go
[12:11] <lag> Sounds simple enough
[12:12] <amitk> perhaps I haven't understood the real problem, re-reading...
[12:14] <lag> Same warning
[12:14] <lag> warning: updating the current branch
[12:14] <lag> warning: Updating the currently checked out branch may cause confusion,
[12:14] <lag> warning: as the index and work tree do not reflect changes that are in HEAD.
[12:14] <lag> warning: As a result, you may see the changes you just pushed into it
[12:14] <lag> warning: reverted when you run 'git diff' over there, and you may want
[12:14] <lag> warning: to run 'git reset --hard' before starting to work to recover.
[12:14] <hrw> hi
[12:14] <ogra> just use bzr 
[12:14]  * ogra hides
[12:15] <hrw> ogra: ;d
[12:15] <ogra> hmm, was possibly not the best idea to make a bad joke right before asking the kernel team for a favour :P
[12:16] <ogra> so hrw and me are here to make a feature request ... 
[12:16] <amitk> lag: hmm, never see that
[12:16] <ogra> we would like to autospawn a getty on serial consoles if console=ttyS,... is set
[12:16] <amitk> ogra: Denied!
[12:16] <ogra> for that hrw created an upstrat script we showed Keybuk for possible upstart upstream inclusion
[12:17]  * abogani waves
[12:17] <abogani> Please don't forget me https://lists.ubuntu.com/archives/kernel-team/2010-May/010707.html :-)
[12:17] <hrw> ogra forgot to mention that enabling of autogetty has to be done by user first
[12:17] <lag> amitk: Do you use build servers?
[12:17]  * amitk points ogra, hrw to apw, ogasawara 
[12:17] <amitk> lag: on occassion
[12:18] <lag> I edit on my local machine, then push to my remote one (on the build server)
[12:18] <ogra> during discussion Keybuk pointed out that the script would better operate on a kernel event i.e. in a way that you can use "start on" if the actual device is existent 
[12:18] <amitk> ogra: possibly best to write email to the mail list
[12:18] <ogra> currently the kernel doesnt expose such an event and we would need it to be added
[12:18] <ogra> amitk, hmm, yeah, probably better
[12:20] <amitk> lag: I only use bare repos to push stuff to
[12:20] <amitk> lag: never done it with a 'checked-out' repo on the remote side
[12:21] <lag> Okay
[12:21] <lag> I think here lies my problem :)
[12:21] <amitk> lag: you could setup a bare repo to push to and then clone it and checkout
[12:22] <apw> lag, whats the issue?  i use non-bare upstreams commonly to build in
[12:22] <Keybuk> ogra: not expose an event so much, as expose the value of console= ;-)
[12:22] <ogra> Keybuk, indeed 
[12:22] <Keybuk> we have the events anyway, we just don't know whether or not ttyS0 is the console
[12:22] <ogra> but you wanted an even too for "start on", no ? 
[12:22] <Keybuk> we have the event
[12:22] <ogra> ah, k
[12:22] <Keybuk> we want the "is ttyS0 the console" test in a form that is useful
[12:23] <Keybuk> either as a payload to the event
[12:23] <lag> apw: Look up
[12:23] <Keybuk> or $console as environment variables or command-line arguments to init
[12:23] <ogra> Keybuk, note that a serial console can have pleanty of names :)
[12:23] <ogra> the only indicator we have is that its not tty[0-9]
[12:23] <apw> lag, all it says is you push and build ... what am i to make from that, other than good
[12:23] <ogra> everything with a letter is serial
[12:25] <persia> But not everything that is serial is a console
[12:25] <hrw> yep
[12:25] <ogra> persia, i think we can safely assume that everything added to the console= cmdline option is a console ;)
[12:26] <persia> Fair :)
[12:26] <lag> apw: When I push it complains
[12:26] <apw> did you read the complaint ?
[12:26] <apw> and take the action it proscribed ?
[12:27] <ogra> so we want both, the event (as Keybuk says that already exists) and handing over console= to upstart
[12:27] <apw> if you set the thing it whines about to ignore, then you can do it
[12:27] <ogra> the prob here is that you will likely have multiple console= args 
[12:28] <lag> apw: It says that as the remote branch is checked out there will be issues
[12:28] <apw> lag, as we discussed you have to push, then git checkout -f branch on the remote side before building
[12:28] <apw> the 'issue' is the head and the working tree will not match
[12:28] <lag> apw: When I do the push, I have to do a 'git reset' and 'git checkout <file>' for it to act sane again
[12:28] <apw> the fix is to check it out
[12:29] <apw> you should just have to git checkout -f <branch>
[12:29] <lag> Every time?
[12:29] <apw> every single time you push yes
[12:29] <lag> That's annoying!
[12:29] <apw> remember the push stuff is repository level
[12:29] <apw> the working directory is not there
[12:29] <apw> and not synced, hence the whine
[12:29] <apw> but as you have to go to the copy to compile it you can simply make it part of your tooling
[12:29] <lag> Okay
[12:29] <apw> both smb and my tooling do that
[12:30] <amitk> kteam-tools?
[12:30] <lag> They do, but I'm not building just yet
[12:31] <lag> As long as that's the definitive answer, I'm happy
[12:31]  * smb sees a lot of stuff in the srollback
[12:34] <smb> lag, apw I am not sure I could catch the problem and the answer exactly when skipping through the scrollback
[12:34] <smb> lag, Is it the complaint about pushing to a checked out branch?
[12:34] <lag> smb: Correct
[12:34] <apw> yep
[12:35] <lag> smb: I've been educated by apw to do a 'git checkout -f' on the remote to solve
[12:35] <apw> you need a new variable set.  once set you already do the right thing by checking out -f 
[12:35] <smb> lag, Ah yeah, so at the moment its a warning. Or you do what it tells you and set the variable
[12:35] <smb> Long term the scripts should do that
[12:35] <smb> Oh, it changed to an error with lucids version of git?
[12:37] <lag> It's just a warning with mine
[12:37] <smb> I believe the rune on the remote side was "git config receive.denyCurrentbranch ignore"
[12:38] <lag> [receive]
[12:38] <lag> 	denyCurrentbranch = ignore
[12:39] <smb> So that is now set
[12:39] <lag> Yup :)
[12:52] <amitk> apw: was there a W-I for the omap-mainline kernel for maverick?
[12:52] <apw> not that i've seen though there should be
[12:53] <amitk> apw: it should probably be 2-3 W-I (given it wasn't a 2hr job)
[12:55] <apw> a work item is meant to be a 2-3 day effort, but if you need one thats smaller then you need it, if it bigger then it should be split a bit
[12:57] <amitk> apw: aah, for some reason i thought it was a 2-4hr effort
[12:58] <amitk> where should it be added?
[12:58] <amitk> what spec, I mean
[12:59] <apw> its a new flavour right?  we discussed those on config-review i think, the remove -preempt should be on it
[13:00] <amitk> new flavour, yes
[13:14] <persia> Remove -preempt?  I thought the plan was only to split out -preempt into a separate package.
[13:27] <cnd> smb: care to unmute and undeafen me?
[13:52]  * ogra wonders why his touchbook kernel has a mailbox
[13:52] <ogra> is that an addition to the in kernel httpd ? :)
[13:55] <ogra> oh, hm, "interrupt driven messaging"
[13:58] <amitk> ogra: are you referring to omap mailbox?
[13:59] <ogra> yeah, never heard of it 
[13:59] <ogra> i just saw the module in lsmod :)
[13:59] <amitk> among other things it is used by the dspbridge
[14:01] <abogani> Do you have some thought about https://lists.ubuntu.com/archives/kernel-team/2010-May/010707.html ?
[14:10] <apw> abogani, not had a chance to look at it yet.  doing stable reviews first
[14:10] <abogani> apw: Ok. Thanks in advance.
[14:10]  * JFo yawns
[14:19] <pgraner> JFo: yea keep yawning while you blow up my imap server... dude seriously?
[14:19] <JFo> :-D
[14:19]  * JFo has more mail for you today oh captain, my captain!
[14:20] <pgraner> JFo: good thing this ain't like the the postoffice where you get charged by the piece....
[14:20] <JFo> indeed :-/
[14:20] <JFo> i can't imagine what the bill would be for all of this
[14:20] <JFo> but I know i wouldn't want to pay it
[14:20] <JFo> :0
[14:21] <tgardner> JFo, are you filling my bug box? I haven't checked this AM yet
[14:21] <JFo> tgardner, I am
[14:21] <JFo> i am spreading the love to all with my bug expiration mails
[14:21] <pgraner> tgardner: hope you have a fast connection to your mail server, he hit me with over 1k messages in bug spam
[14:21] <JFo> and that is just for the expiring ones :)
[14:22] <tgardner> maybe thats why it felt so slow earlier this morning. it took forever to get my inbox stuff.
[14:22] <pgraner> JFo: you have my fetchmail process breathing hard, its never done that much work
[14:22] <JFo> heh
[14:24] <JFo> so pgraner, looks like I had the wrong objectives but alice has fixed them.
[14:24] <JFo> they need your sign off so I can fix them up
[14:26] <pgraner> JFo: ok give me 5
[14:27] <JFo> k, thanks
[14:37] <JFo> apw, in the grand tagging scheme, where would bug 324894 fit
[14:37] <ubot2> Launchpad bug 324894 in linux (Ubuntu) ""Corrupted low memory at" kernel warning on resume (affects: 25) (dups: 6) (heat: 188)" [Medium,Triaged] https://launchpad.net/bugs/324894
[14:38] <JFo> just wondering whenever you have time to look
[14:38] <JFo> my money is on acpi maybe
[14:38] <manjo> JFo, that bug can be quirked, but they need to send me the dmidecode info
[14:38] <manjo> the quirk is in the core kernel 
[14:38] <JFo> which manjo ?
[14:38] <JFo> the one here or some other?
[14:38] <manjo> jfo Corrupted low memory at
[14:38] <JFo> ah
[14:38] <manjo> JFo,  Corrupted low memory at
[14:40] <apw> JFo, i would put it in kernel-core .. its biosy ick
[14:40] <apw> what manjo said
[14:41] <manjo> JFo, this one is a diff one from what I was looking at, but basically the same bug, like apw said bios issues, quirk is in the kernel 
[14:41] <smb> apw, Dude, I wonder who is madder of the two of us. You doing all the 180 plus writing or me. But thanks! :)
[14:41] <JFo> apw, k
[14:41] <apw> smb, you made the t-shirt, who looked madder there ... i think its a draw
[14:42] <apw> smb, i need a lie down i thkink
[14:42] <smb> apw, It surely is. And yes I think you would have earned it
[14:47] <JFo> vanhoof, yeah, I need a home for it
[14:52] <amitk> mpoirier: you have new booogs assigned to you
[14:52] <mpoirier> yes, just saw - thanks
[14:54] <amitk> mpoirier: were you able to run my kernel?
[14:54] <mpoirier> indeed but your .deb died in userspace.
[14:54] <mpoirier> it could find the sd card.
[14:54] <mpoirier> I check-out your tree
[14:54] <mpoirier> recompiled and it all worked properly.
[14:55] <mpoirier> i did not look for specific bugs/error
[14:57] <amitk> ok
[14:58] <JFo> look out for all the boogs!!!
[14:58]  * JFo goes for coffee to escape the boogs
[15:26]  * cking wrestles with evolutions junk filters
[15:40] <amitk> ogasawara: will there be any more uploads before alpha-1, or just the one?
[15:42] <tgardner> amitk, I was gonna ask her why she hasn't already uploaded. there are a pile of changes in  the pipe
[15:43] <smb> apw, Hm I guess you have done ti-omap and qcm-msm uploads sort of recently. Should ti-omap have a orig.tar.gz?
[15:44] <amitk> tgardner: I see that you'll press her to do it. My job here is done :)
[15:45] <tgardner> amitk, yeah, I'll annoy her when she shows up this morning.
[15:45] <smb> apw, Probably could only be a raw linus-2.6.33 tarball
[15:45] <apw> smb, it should have had one, though i have the feeling i was remis in providing that one
[15:46] <smb> apw, There is nothing on archive.ubuntu.com, but so I try whether it works with one
[15:48] <bjf> moin all
[15:50] <apw> smb, you can inject one at any time
[15:50] <apw> bjf, moin
[15:51] <smb> apw, Yeah, just sometimes the build explodes when you do it cause they need executable things or ...
[15:51] <smb> but I will try
[15:54]  * smb grows several new gray hairs over the lucid rebase mess
[15:57] <apw> smb, i see, i think ti-omap is mostly upstream so the risk is lower than normal for an ARM nightmare branch
[15:58] <smb> apw, Its mostly keeping 3 kernel versions and 6 topic branches somehow in memory without getting too confused
[15:58] <ogasawara> amitk: was planning to upload this morning, just had one extra question for you before I do
[15:58] <apw> yeah i have a checklist
[15:59] <ogasawara> amitk: you mentioned you purposely didn't run updateconfigs after doing the -omap flavour
[16:00] <ogasawara> amitk: I'm gonna have to run updateconfigs for other bits when I rebase, do you prefer that -omap config not be touched?
[16:00] <tgardner> ogasawara, what I think he meant is that it will be easier for you to do it at the time of integration
[16:00] <smb> apw, Mine is still brain based. That sort of worked before Lucid but I think this needs some external list now...
[16:01] <apw> smb, ogasawara, the checklist i used for lucid development is on chinstrap in ~apw/CHECKLIST
[16:01] <apw> you can see the form i used
[16:02] <ogasawara> apw: thanks
[16:02] <apw> smb, though if you put that together with all the releases on it you may kill self
[16:03] <smb> apw, thanks. I will try anyway. Better that than try to keep all in mind
[16:05] <bjf> ##
[16:05] <bjf> ## Kernel team meeting today @ 17:00 UTC
[16:05] <bjf> ##
[16:06] <bjf> JFo, didn't see as many expired emails as I was expecting
[16:07] <JFo> yeah, the script fell over on one
[16:07] <JFo> but I am running it again so I can see what happens
[16:07] <JFo> more expring now
[16:10] <bjf> ogasawara, do you have a list of active blueprints that we should be reviewing in the irc meeting?
[16:10] <ogasawara> bjf: primarily this is what I'm using for Alpha1 https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Maverick#Milestone maverick-alpha-1
[16:12] <bjf> ogasawara, that's quite the list, i'll work on getting it into the meeting
[16:13] <ogasawara> bjf: I was gonna mention it during the Maverick Release Status
[16:13] <ogasawara> bjf: and remind those who still have open items
[16:14] <bjf> ogasawara, so you want to do them all as a single meeting topic or do you want me to break them out as one blueprint per topic like before?
[16:15] <ogasawara> bjf: actually, one blueprint topic like before might be good for accountability
[16:15] <bjf> ogasawara, i'll work on that now
[16:15] <ogasawara> bjf: thanks
[16:29] <ogasawara> smb: just a heads up, the security-m-kernel-hardening blueprint had a work item of "review and consider security hardening patches for Stable Releases" but it was assigned to canonical-kernel-team
[16:29] <ogasawara> smb: so I reassigned to you specifically else it'd likely get ignored
[16:30] <smb> ogasawara, Ok, thanks. I saw it in the mail lp sent out when you changed it
[16:30] <ogasawara> smb: it's currently an Alpha1 work item, but feel free to bump to Alpha2 if you haven't time to review before Alpha1
[16:30] <ogasawara> smb: I realize I sorta dumped it to you last minute
[16:31] <smb> ogasawara, Remind me when is alpha1? something june?
[16:31] <ogasawara> smb: next Thurs, june 1
[16:31] <smb> ogasawara, joy. :-P
[16:31] <JFo> what the heck is pwmconfig? bug 475641
[16:31] <ubot2> Launchpad bug 475641 in linux (Ubuntu) "pwmconfig does not work after upgrade to 9.10 on TYAN server (affects: 2) (heat: 12)" [Undecided,Triaged] https://launchpad.net/bugs/475641
[16:32] <tgardner> ogasawara, I'm currently looking at the ptrace hack from kees
[16:32] <ogasawara> smb: make that June 3, not june 1
[16:32] <bjf> JFo, power management config
[16:32] <JFo> ah hah
[16:32] <ogasawara> tgardner: any thoughts yet?
[16:32] <JFo> I was hoping it was that
[16:32] <smb> ogasawara, two more day then :)
[16:32] <tgardner> nah, still have to noodle around with it. I'll get to it this afternoon
[16:33] <JFo> that the bug from last night tgardner?
[16:33] <tgardner> JFo, dunno. what bug?
[16:33] <smb> tgardner, let me know what you think, too. Somehow I remember two were sort of ok'ish and one was scary
[16:33] <JFo> bug 585175
[16:33] <ubot2> Launchpad bug 585175 in linux (Ubuntu) "kernel BUG at /build/buildd/linux-2.6.34/ubuntu/aufs/f_op.c:84! (affects: 1) (heat: 6)" [Undecided,Triaged] https://launchpad.net/bugs/585175
[16:33] <tgardner> smb, I've already reviewd and ack'd the first 2
[16:33] <JFo> ogasawara, ^^ that is the one kees filed last night
[16:34] <smb> tgardner, Cannot remember which one was which. But I think the hardlink thing was something scary
[16:34] <tgardner> smb, hardlink/softlink was straightforward and testable
[16:35] <smb> tgardner, Hm from my memory hardlink might have some side effects. But testable could be
[16:35] <tgardner> JFo, different bug
[16:35] <ogasawara> JFo: can I add that to our 50 to review/discuss?  I know there is a new aufs we can update to but we're holding off on it till we finish the union mounts evaluation as an alternative to aufs
[16:35] <JFo> ogasawara, you may indeed
[16:35]  * JFo makes a note
[16:35] <ogasawara> JFo: not that I'm sure the newer aufs would resolve it...
[16:36] <tgardner> it'll just add new and different bugs
[16:36] <JFo> ogasawara, it is on my paper list to add
[16:36] <ogasawara> JFo: I'm still cleaning up the KernelBuglist script, I keep getting side tracked
[16:36] <JFo> k, no sweat
[16:36] <JFo> too much to do
[16:37] <bjf> ##
[16:37] <bjf> ## Kernel team meeting in 25 minutes
[16:37] <bjf> ##
[16:38]  * tgardner wonders what timezone in which bjf exists
[16:38] <tgardner> bjf, never mind. can't read
[16:39] <smb> Hm 17UTC is a bit more than 25 mins away in my world
[16:40] <bjf> smb, according to my 'puter it will be 5:00 p.m. in london in 22 minutes, is that not 17:00 utc?
[16:41] <smb> bjf, no london has daylight savings too
[16:41] <bjf> smb, they switched to BST didn't they
[16:41] <bjf> so that would be in 1 hr and 20 minutes then
[16:41] <smb> yep I think so
[16:41] <smb> cking, apw ?
[16:42] <ogasawara> $ date --utc
[16:42] <ogasawara> Tue May 25 15:40:32 UTC 2010
[16:42] <ogasawara> I'm seeing 1hr 20min
[16:42] <bjf> ##
[16:42] <bjf> ## Kernel team meeting in 1 hour and 20 minutes  (time correction)
[16:42] <bjf> ##
[16:42] <apw> bjf, do you have the list of blueprints you will be asking about yet as the agenda just has the 'NEEDS LIST' in it
[16:43] <bjf> apw, working on it, will update in 3 minutes
[16:44] <JFo> I have a list of them bjf
[16:45] <bjf> JFo, me too, i'll put mine on the meeting page and we can compare notes
[16:45] <JFo> ah
[16:45] <JFo> just blasted them to you in pw :-/
[16:45] <JFo> will check the meeting page
[16:46] <amitk> ogasawara: what tgardner said (regarding updateconfigs). Run it now that the patch is integrated.
[16:46] <ogasawara> amitk: ack
[16:50] <tgardner> apw, what was the reasoning for creating a new PPA for the LTS backports? Whats wrong with just using the well known kernel-ppa ?
[16:51] <apw> tgardner, none if that PPA is not being used for anything
[16:51] <bjf> apw, ogasawara, JFo, blueprint list on meeting page, let me know if you want more added, i just put on the ones with A-1 deliverables
[16:51] <JFo> k
[16:51] <apw> nominally i would use a named PPA for such a specific thing though
[16:52] <tgardner> acht pht
[16:53] <lag> Does anyone know what this means: <directory>/*[!~]
[16:54] <bjf> lag, context?
[16:54] <lag> bash
[16:54] <lag> * = everything
[16:54] <lag> Don't know what [!~] means
[16:54] <tgardner> not $HOME ?
[16:54] <lag> Not home?
[16:54] <lag> Doh!
[16:55] <smb> depends on how regex bash is. I thought there were limits
[16:55] <smb> Maybe only something ending with ! or ~
[16:56] <lag> It's actually /etc/pm/config.d/*[!~]
[16:56] <manjo> If the first character following the ‘[’ is a ‘!’ or a ‘^’ then any character not enclosed is matched
[16:56] <blue_anna> can I get help getting i2c-core module for my build? it's not in my kernel and I don't see an alternative in the repositories
[16:56] <tgardner> lag, um, I think that matches all files except those ending in '~'
[16:57] <lag> That could work
[16:57] <manjo> lag, If the first character following the ‘[’ is a ‘!’ or a ‘^’ then any character not enclosed is matched
[16:58] <lag> manjo: ack
[16:58] <lag> Thanks :)
[16:58] <JFo> apw, did we say KMS was core or graphics?
[16:59]  * JFo is in forgettory mode
[16:59] <kees> tgardner: if there's anything I can help with for the ptrace review, please let me know.
[16:59] <tgardner> kees, ack
[16:59] <bjf> apw, ogasawara, JFo, adding more BPs to the agenda, just a sec
[17:01] <bjf> apw, ogasawara, JFo, meeting agenda updated let me know if you want changes
[17:01] <JFo> k
[17:01] <JFo> apw, nm I think that was KVM I was thinking of
[17:03] <smb> JFo, KVM as in the virtualization engine?
[17:03] <apw> JFo, KMS kernel-graphics, KVM kernel-core yea
[17:04] <JFo> yeah
[17:04] <JFo> that was it
[17:04] <JFo> I was getting them tangled
[17:04] <smb> apw, Wasnt there a KSM too
[17:04]  * JFo slaps smb
[17:04] <JFo> :)
[17:04] <apw> heh maybe
[17:04] <smb> Hey I am only the messenger :-P
[17:04] <JFo> :-D
[17:04]  * smb thinks of something with shared memory
[17:05]  * JFo puts an action item to continue updating the Kernel Dictionary
[17:08] <bjf> JFo, manjo, jjohansen, apw, tgardner, cnd, ogasawara, cking, smb, just a heads up, you are on todays meeting agenda for a blueprint
[17:09] <jjohansen> bjf: yep thanks
[17:09] <apw> bjf, ack ... am prepared
[17:09] <tgardner> bjf, INPROGRESS
[17:09] <bjf> :-)
[17:10] <jjohansen> apw: why wouldn't all the items on my blueprints be showing up in https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Maverick
[17:10] <smb> bjf, I did not see me on a complete blueprint but as subitems. apw Ithing in yours (misc)
[17:10] <apw> jjohansen, which blueprint
[17:10] <bjf> smb, sorry, your on for the usual reason :-)
[17:10] <apw> smb, he prolly means for the stable update
[17:10] <bjf> smb, we just love ya man!
[17:11] <apw> jjohansen, there are many reasons, easiest to look at the source of the blueprint
[17:11] <smb> heh, thanks a lot
[17:11] <jjohansen> https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-pv-ops-ec2-kernel
[17:11] <jjohansen> https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-apparmor
[17:11] <jjohansen> https://blueprints.launchpad.net/ubuntu/+spec/security-m-apparmor
[17:11] <jjohansen> https://blueprints.launchpad.net/ubuntu/+spec/security-m-apparmor-profile-packaging
[17:11] <jjohansen> apw: okay, what am I looking for, some of the items are there, and some of the items there aren't reflecting status changes that were made friday
[17:12] <apw> ok the DB was last updated my end about an hour ago
[17:13]  * bjf notes it's going to be a balmy 60 degrees F today in Portland (and rain _all_ day)
[17:13] <jjohansen> okay, so I will assume I broke the work item format, and check all those
[17:13] <apw> pvops looks ok
[17:13] <apw> jjohansen, bearing in mind 'inprogress' does not get seen
[17:14] <apw> it appears as Todo 
[17:14] <jjohansen> apw: oh?  For some reason I thought it showed up different
[17:14] <apw> apparmor loos ok
[17:14] <apw> sadly no, pitti's db squashes inprogress to 'not done yet'
[17:16] <apw> jjohansen, as far as i can see they are all there
[17:17] <JFo> cnd, any Jerone love coming for Big Daddy's bug 581312 ?
[17:17] <ubot2> Launchpad bug 581312 in linux (Ubuntu) "Unknown key fee[x] pressed (affects: 1) (heat: 20)" [Medium,Triaged] https://launchpad.net/bugs/581312
[17:17] <jjohansen> apw: hrmm, /me wonders why is browser tab isn't refreshing when reload is hit
[17:17] <cnd> JFo: I haven't heard anything
[17:17] <blue_anna> can I get help getting i2c-core module for my build? it's not in my kernel and I don't see an alternative in the repositories
[17:17] <JFo> k
[17:18] <blue_anna> I was directed here form ubuntu devel
[17:18] <blue_anna> *from
[17:18] <cnd> blue_anna: I'm guessing it's already built in
[17:19] <jjohansen> apw: alright killing firefox fixed it, sorry and thanks
[17:19] <cnd> blue_anna: yes, it's already builtin in Ubuntu kernels
[17:19] <apw> jjohansen, la la la can't heard you
[17:19] <cnd> CONFIG_I2C=y
[17:20] <blue_anna> cnd: not in 2.6.32-21-powerpc64-smp
[17:20] <smb> apw, Bah! Having one common enforcer file was probably not the most brilliant idea
[17:20] <ogra> jjohansen, stop moaning, i'm trying to get mobile blueprints on our charts and fail miserably, you ate least have something more than one work item :) (http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile.html) 
[17:20] <ogra> *at least
[17:20] <apw> smb, that is already sorted in my ubuntu-debian replacement
[17:20] <apw> it moves to being repository specific
[17:21] <smb> apw, More reason to have that soon. *sigh*
[17:21] <apw> smb, its waiting on your trees quiesing long enough to apply it
[17:22] <apw> i know thats a difficult thing
[17:22] <blue_anna> cnd: apt-file search i2c-core | wc -l | xargs -0 echo "results found " ==> results found 0
[17:22] <jjohansen> ogra: wow I guess that means you have no work items for this ;)
[17:22] <smb> apw, While its causing more trouble getting then quieting down. :-P 
[17:22] <ogra> jjohansen, easy dev cycle this round :)
[17:23] <apw> blue_anna, if its built-in there is no module file to search for
[17:23] <blue_anna> apw: oo that kind of built in :)
[17:24] <apw> blue_anna, yep, =y on a CONFIG_* item means make it part of the kernel image itself
[17:24] <apw> ogra, heh got an example blueprint, i've been through most of the errors this week
[17:24] <apw> (one thats missing i mean)
[17:25] <ogra> apw, just catched pittin in -devel :)
[17:25] <blue_anna> apw: so I can just behave as if it is already loaded as a module -- like I can do all the insmods without the modprobe at this instructions? http://ubuntuforums.org/showpost.php?p=4267018&postcount=7
[17:25] <ogra> *pitti in
[17:25] <blue_anna> apw & cnd thank you both
[17:27] <ogra> apw, seems i always make the same mistakes of adding a blank line after "Work items" (it looks so ugly without)
[17:27] <apw> ogra, hehe :)
[17:27] <cnd> blue_anna: you should be able to ignore anything that tells you to insmod or modprobe i2c-core
[17:27] <ogra> and since all our specs were discussed under ubuntu-arm they are all named wrongly as well
[17:27] <ogra> its a total mess
[17:28] <blue_anna> cnd: thanks again
[17:28] <cnd> np
[17:34]  * cking is going ACPI testing loopy
[17:35] <achiang> cking: ah, is there anything from the bios testing blueprint i can help with?
[17:37] <bjf> ##
[17:37] <bjf> ## Kernel team meeting in 25 minutes
[17:37] <bjf> ##
[17:43] <manjo> bjf, wonder why I don't see it in the canonical calendar
[17:43] <bjf> manjo, looking
[17:43] <JFo> sounds like user error manjo :-P
[17:44] <cking> achiang, I have a git repo now with my code on it - it may be worth occasionally giving it a test spin
[17:44] <achiang> cking: ah, cool. pointer to the repo?
[17:45] <cking> achiang, http://kernel.ubuntu.com/git?p=cking/ubuntu-firmware-test-suite/.git;a=summary
[17:45] <bjf> manjo, it's on the calendar that i'm looking at
[17:45] <achiang> cking: thanks
[17:45] <manjo> bjf, strange... something wrong at my end 
[17:46] <cking> achiang, check it out, ./configure and run ./src/testsuite --help ;-)
[17:46] <achiang> cking: yep, maybe i'll get a chance to play with it today
[17:46] <bjf> manjo, the calendar it's on is "Ubuntu Kernel Schedule"
[17:47] <manjo> bjf, ah I am subscribed to it somehow... wonder what happened
[17:48] <manjo> bjf, *not*
[17:48] <manjo> bjf, can you add me to that calendar ? 
[17:49] <bjf> manjo, i don't think so, probably has to be pgraner or tgardner 
[17:51] <JFo> looks like the other meeting will run over bjf 
[17:52] <bjf> JFo, when we all stomp into the channel, they may close up
[17:52] <JFo> mayhap
[17:53] <manjo> bjf, you need to get ops fro that one too
[17:57] <bjf> ##
[17:57] <bjf> ## Kernel team meeting in 5 minutes
[17:57] <bjf> ##
[18:00] <apw> they finished on the dot
[18:01] <bjf> ##
[18:01] <bjf> ## Meeting starting now
[18:01] <bjf> ##
[18:24] <achiang> cking: what's the git url to clone your test suite?
[18:24] <achiang> cking: my guess of:  git://kernel.ubuntu.com/projects/cking/ubuntu-firmware-test-suite.git was unsuccessful
[18:25] <cking> achiang, hrm, dunno why, let me check it out after the meeting
[18:31] <apw> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/397845
[18:31] <ubot2> Launchpad bug 397845 in linux (Ubuntu) "Thinkpad T30 backlight remains on during supend (affects: 1)" [Undecided,Expired]
[18:33] <phunge0> hi i have a question
[18:33] <phunge0> for pgraner possibly
[18:33] <phunge0> i'm the submitter of https://bugs.launchpad.net/ubuntu/+source/linux/+bug/585092
[18:33] <ubot2> Launchpad bug 585092 in linux (Ubuntu) "tmpfs umount slowdown (affects: 1) (heat: 12)" [Undecided,Incomplete]
[18:34] <phunge0> i have a ubuntu-lucid git fork with backports of mainline packages that i'd like to link on that bug
[18:35] <phunge0> so i need to be able to host the git repo somewhere
[18:36] <apw> phunge0, if the backport is big enough that you can't attach it, then its likely not going to be SRUable
[18:36] <phunge0> it's 3 cherrypicked patches
[18:36] <cking> achiang, try git clone  git://kernel.ubuntu.com/cking/ubuntu-firmware-test-suite
[18:36] <phunge0> should i just attach 3 patches?
[18:36] <apw> then simply putting the three headers from those in the bug
[18:37] <phunge0> how do you mean headers? fyi the cherrypicking involved some merging
[18:38] <JFo> apw: http://status.qa.ubuntu.com/qapkgstatus/linux
[18:38] <achiang> cking: yep, that got it, thanks
[18:38] <apw> then attach the full patches.  if they were just cherry-picks then the sha1's and description would have been enough ... else the whole patches are needed
[18:38] <phunge0> k i'll do that tx
[18:43] <cking> achiang, you need to do a git pull on that got pick up klog.h - then ./configure and run sudo ./src/testsuite --show-progress --results-output=achaing.log --stdout-summary
[18:44]  * cking goes for food
[18:46] <apw> Keybuk, yo ... SYSFS deprecated settings you wanted off, were there any other than the SYSFS_DEPRECATED* those ones ... 
[18:46] <apw> cnd, http://people.canonical.com/~scott/daily-bootcharts/20100406-max-kernel.png that was from the 4th
[18:47] <Keybuk> no, was just wanting to make sure they're all in the config checker
[18:47] <Keybuk> they should be all off atm
[18:47] <apw> Keybuk, ack ... thakns
[18:48] <apw> Keybuk, do you need warning of getting all kernel command line options in upstart
[18:49] <Keybuk> I'd like to know when that lands
[18:49] <Keybuk> but I don't need to do anything first
[18:51] <apw> bjf, is the topic here on the list to change page, and i note the link still points to my copy not yours and mine exists and shouldn't
[18:51] <bjf> apw, ack, haven't fixed that yet, will do so now
[18:53] <bjf> apw, which link are you refering to, i'm looking on the knowledgebase page
[18:55]  * manjo going to a meeting on improving server testing with checkbox ... yaaay!
[18:55]  * cking wonders if we should have an ignorancebase page for answers we don't have
[18:55] <apw> bjf i added one to the top of the meeting page, as that is where i yearned to find the info
[18:56] <bjf> apw, that's too obvious
[18:56] <apw> sorry
[18:57] <JFo> bjf, that topic probably needs to change to Home: https://wiki.ubuntu.com/Kernel/
[18:57] <JFo> whoops
[18:57] <JFo> nm
[18:57] <JFo> I just finished reading back
[18:57] <JFo> :)
[19:05] <cking> achiang, any luck with the test tool?
[19:09] <achiang> cking: trying to get my test machine up. :-/
[19:11] <cking> ;-(
[19:12]  * achiang learns a lesson about touching interesting BIOS knobs on proto hardware.
[19:12] <achiang> luckily, pulling the CMOS battery did the trick
[19:12] <cking> phew
[19:20] <cking> achiang, well, when you get some results, email the log to me so i can sanity check the code
[19:20] <cking> ..no rush
[19:20] <achiang> cking: yep, i'm installing lucid now
[19:21] <phunge0> JFo: i've updated my bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/585092 with the triage info, what needs to happen to get it out of incomplete triage land?
[19:21] <ubot2> Launchpad bug 585092 in linux (Ubuntu) "tmpfs umount slowdown (affects: 1) (heat: 12)" [Undecided,Incomplete]
[19:22] <JFo> phunge0, I need to get to it :)
[19:22] <phunge0> thanks :)
[19:26] <JFo> phunge0, done
[19:26] <phunge0> JFo, thanks
[19:26] <JFo> np
[19:59] <jjohansen> -> lunch
[20:26] <vanhoof> JFo: I grabbed that bug for now until I can divy it out
[20:27] <JFo> cool, thanks bro :)
[20:27] <JFo> sorry for all the confusion
[20:31]  * ogasawara -> lunch
[20:35]  * bjf -> lunch
[20:37] <vanhoof> JFo: no worries, the whole thing is kinda screwed up
[20:38] <JFo> yeah
[21:06] <JFo> Can HAz bug servur dat stays available longer than 5 minutes? kthxbai
[21:06]  * JFo kicks Launchpad in it's bad pants
[21:12] <cwillu> is btrfs anybody's pet project here?
[21:13] <pgraner> bjf: can you add ubuntu-news-team@lists.ubuntu.com to cc: list of the email you send out after the k-t meeting
[21:13] <bjf> pgraner, sure
[21:14] <pgraner> bjf: thanks that way it will make UWN
[21:14] <pgraner> bjf: I sent them this weeks already
[21:14] <pgraner> bjf: thanks
[21:14] <bjf> pgraner, "the queen" was going to take care of it for me :-), but I'll do this as well
[21:22] <bjf> JFo, I'm looking at your "Release Meeting Bugs", you have "fsl" and "mvl" listed though we don't have them in maverick
[21:22] <JFo> hmmm, excellent point :)
[21:23] <bjf> ogasawara, ^
[21:23]  * JFo marks them for removal if that is the consensus
[21:23] <bjf> ogasawara, what should we be tracking "Release Meeting Bugs" wise?
[21:45] <ogasawara> bjf: we don't have fsl and mvl-dove for Maverick at the moment, so no need to track
[21:45] <ogasawara> bjf: release meeting have yet to start, so nothing to track at the moment
[21:45] <ogasawara> bjf: I'd just go with tracking any Alpha1 targeted bug at the moment
[21:46] <bjf> ogasawara, ok
[21:47] <svu> chrisccoulson, hi :)
[21:48] <svu> chrisccoulson, who would be the person to talk to?
[22:05] <vanhoof> what is the key for push to talk on mumble?
[22:05] <vanhoof> anyone know off hand
[22:05] <bjf> vanhoof, you set it yourself
[22:05] <vanhoof> hmm ok
[22:05]  * vanhoof looks
[22:05] <bjf> vanhoof, configure->settings->shortcuts
[22:06] <vanhoof> bjf++ thanks!
[23:05] <kees> ogasawara: around?  I need rebase help.  :)
[23:06] <ogasawara> kees: I'm here
[23:07] <kees> ogasawara: okay, so I have a git tree that was a clone of ubuntu/ubuntu-maverick.  I've worked on it and comitted locally.  more changes have gone into the origin, so how do I carry my stuff forward to be at the "top"?
[23:07] <kees> (if I do "git pull" I end up with a "merge" commit at the top)
[23:08] <achiang> git fetch && git rebase origin
[23:08] <kees> \o/ that worked.  thanks achiang :)
[23:08] <ogasawara> kees: what achiang said :)
[23:08] <kees> huzah, my git push even worked now.
[23:09] <achiang> kees: in general, you almost never want to do a git pull
[23:09] <achiang> since it'll more often than not add a merge commit on top
[23:09] <kees> achiang: yeah, totally agreed.  :)
[23:10] <achiang> git fetch will pull down the new metadata and then you can do a git rebase origin to move your patches to the end
[23:10] <achiang> also, stacked git is way nicer than raw git
[23:10] <kees> achiang: what is "stacked git" ?
[23:11] <kees> ogasawara: here is my tree, is this in the right form for me to do a pull-request?  http://kernel.ubuntu.com/git?p=kees/ubuntu-maverick.git;a=summary
[23:11] <achiang> kees: conceptually, it's quilt + git
[23:11] <achiang> kees: but way nicer than either quilt or git by itself. :)
[23:11] <kees> hunh, neat
[23:12] <achiang> kees: basically, the problem it solves is, "how do i manage a patch queue on top of a git tree?"
[23:13] <achiang> so here's a limitation in git: a commit is forever. so if you're developing a bunch of patches, say 1, 2, 3 ; have committed 1 and 2 and are now working on 3, then realize that you really wanted to do something different in 1, you are screwed
[23:13] <cwillu_at_work> git pull --rebase
[23:14] <achiang> you have to do ugly stuff like save off the patches manually, then reapply them
[23:14] <achiang> in stacked git, you can just say: stg pop ; stg pop ; <hack hack hack> ; stg refresh ; stg push ; stg push
[23:14] <ogasawara> kees: git request-pull Ubuntu-2.6.34-4.11 git://kernel.ubuntu.com/kees/ubuntu-maverick.git master
[23:15] <kees> ogasawara: cool; I had most of that but not the final "master".  what is the convention for the email subject line?
[23:16] <cwillu_at_work> achiang, why wouldn't you just branch off a to a'; hack hack hack; and then rebase b and c on a'?
[23:16] <kees> ogasawara: but, I mean, it's sane for me to have the reverts followed by the updates?
[23:17] <ogasawara> kees: subject line can just be "Maverick pull request for <insert blurb>"
[23:17] <achiang> cwillu_at_work: in your example, what are b and c?
[23:17] <ogasawara> kees: yep, sane to revert patches you want to drop and then apply the ones you want
[23:18] <kees> perfecto
[23:18] <cwillu_at_work> achiang, I meant your 1, 2, 3
[23:18] <cwillu_at_work> the patches series
[23:19] <achiang> cwillu_at_work: to keep a clean development history
[23:20] <achiang> that's the simplest answer
[23:20] <cwillu_at_work> I don't follow;  that's what rebase is for:  to keep a clean development history, no?
[23:20] <kees> wheee, I did a pull request.  ;)
[23:21] <achiang> cwillu_at_work: what if you want to edit the changelog of patch 1 and your HEAD is pointing to patch 3?
[23:21] <ogasawara> kees: \o/
[23:22] <kees> ogasawara: and I even did the sneaky interactive rebase merge thingy.
[23:22] <ogasawara> kees: I'll get these applied and uploaded for Alpha1
[23:23] <kees> ogasawara: oooh, cool, thanks.
[23:25] <cwillu_at_work> achiang, I'm finding it difficult to come up with something different than "uh, rebase it?" as a response :p
[23:27] <achiang> hm.
[23:27] <achiang> so you commit patch 1.
[23:27] <achiang> then, commit patch 2
[23:28] <achiang> decide you want to change patch 1, so ... git branch <sha1 of patch 1 - 1>
[23:28] <achiang> actually, i can't figure out how you would do what you propose with rebase
[23:30] <achiang> each commit is atomic, so i fail to see how a rebase lets you change a commit
[23:34]  * achiang shrugs, goes outside to hack at stubborn roots
[23:45] <jjohansen> achiang: you can do an interactive rebase, tell it which commits you want to edit
[23:45] <jjohansen> but I find guilt/stgit easier to work with than interactive rebase
[23:47] <jjohansen> guilt/stgit also make it easier to shelve patches