[00:45] <cnd> RAOF: yep, I confirmed through testing earlier :)
[00:46] <cnd> upgraded the kernel and it still worked
[00:57] <Sarvatt> cnd: sure you aren't just using nv now?
[00:59] <RAOF> I'm using nouveau.
[01:00] <RAOF> I can tell, because my system both suspends *and* resumes.
[01:03] <lifeless> lol
[01:27] <bjf> akgraner, just saw that the kernel team meeting minutes showed up on The Fridge
[02:35] <jk-> pgraner: ping?
[02:44] <RAOF> cnd: Hm.  I was missing some important context there.  You mean to say that you're using the Maverick 2.6.34 kernel *on Lucid* and nouveau is working?  Can I get an Xorg.0.log?
[03:27] <JFo> RAOF, Tim is using it too and it works
[03:27] <JFo> rather tgardner
[03:27]  * JFo heads off to bed
[04:16] <cnd> RAOF: correct
[04:17] <cnd> let me send you an email with my log
[08:06]  * smb awakens
[08:07] <cking> morning smb
[08:07] <smb> morning cking 
[08:08] <amitk> morning guys
[08:08]  * smb waves to amitk 
[08:14] <cooloney> smb: cking and amitk morning
[08:14] <smb> Hey cooloney 
[08:14] <cooloney> smb: GrueMaster tested lucid security kernel for imx51
[08:14] <cooloney> it boots 
[08:14] <smb> Ok, so I can tick that off
[08:15] <cooloney> smb: but i just wander, is this security updates rebased on our lucid latest fsl-imx51 code?
[08:15] <smb> cooloney, Just for completeness, though likely less important. Anything on the Kamric fsl-imx51. Think that needs different hw
[08:16] <cooloney> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=shortlog;h=refs/heads/fsl-imx51
[08:16] <smb> cooloney, No there are some changes that were never uploaded in them (see one of the notes in the original email)
[08:16] <smb> Those will need to wait until I do a rebase for proposed uploads
[08:17] <cooloney> smb: ok, understood. hehe
[08:17] <cooloney> smb: since GrueMaster said the eth0 ifdown issue is still there in the security kernel. 
[08:18] <smb> So it certainly might be. :)
[08:18] <smb> s/might/will/
[08:20] <cooloney> smb: and GrueMaster will test Karmic kernel when he wake up 
[08:20] <smb> cooloney, Ah ok, most excellent
[08:38] <ikepanhc> apw: smb: I am going to submit a talk on Taiwan conference for open source coders. current plan is talking about how to packaging ubuntu kernel (ex:git,base,delta... etc), regression (and why we take it serious). You are the expert of this. Can you help me review after I finish the slide for it?
[08:38] <smb> ikepanhc, Sure will do
[08:39] <ikepanhc> smb thanks :D
[08:40] <apw> ikepanhc, yep
[08:41] <ikepanhc> apw: thanks :) it may take me 1 or two weeks
[09:47] <kraut> hi
[09:47] <kraut> anyone an idea what's going wrong while umounting cifs shares? http://pastebin.com/dvwnH51h
[09:47] <kraut> it's reproduceable
[09:57] <cooloney> ikepanhc: that's a great topic
[09:57] <cooloney> ikepanhc: can you share your slide for me as well?
[09:58] <ikepanhc> cooloney: sure, after I finish it
[09:58] <cooloney> ikepanhc: maybe next time we can give this kind of speech in Shanghai or Beijing. 
[09:58] <ikepanhc> cooloney: I plan to use it on COSCUP and UHS
[09:59] <smb> kraut, Hm, I am not sure. Sounds a bit familiar. Have the feeling there might be something in latest stable. Let me look
[10:00] <kraut> thanks
[10:01] <kraut> searched in launchpad but found nothing. via google i found one entry but when i clicked on it, i got a 404
[10:01] <kraut> really strange
[10:01] <smb> kraut, commit 793c338bac6fa1fb94504a0346f43e87d24b5daa
[10:01] <smb> Author: Jeff Layton <jlayton@redhat.com>
[10:01] <smb> Date:   Tue May 11 14:59:55 2010 -0400
[10:01] <smb>     cifs: guard against hardlinking directories
[10:01] <smb>     
[10:01] <smb>     commit 3d69438031b00c601c991ab447cafb7d5c3c59a6 upstream.
[10:01] <apw> smb, YEEKS
[10:01] <smb>     When we made serverino the default, we trusted that the field sent by the
[10:01] <smb>     server in the "uniqueid" field was actually unique. It turns out that it
[10:01] <smb>     isn't reliably so.
[10:01] <smb>     
[10:01] <smb>     Samba, in particular, will just put the st_ino in the uniqueid field when
[10:01] <smb>     unix extensions are enabled. When a share spans multiple filesystems, it's
[10:01] <kraut> +	 * uh oh -- it's a directory. We can't use it since hardlinked dirs are
[10:01] <kraut> +	 * verboten. 
[10:01] <kraut> rofl
[10:01] <smb>     quite possible that there will be collisions. This is a server bug, but
[10:01] <smb>     when the inodes in question are a directory (as is often the case) and
[10:01] <kraut> denglish for runaways
[10:01] <smb>     there is a collision with the root inode of the mount, the result is a
[10:02] <smb>     kernel panic on umount.
[10:02] <kraut> am i the only one who hits that bug!?
[10:03] <smb> Maybe not, otherwise it would not have been fixed. But here, yes denke schon
[10:04] <kraut> that must be verboten! ;)
[10:04] <smb> Very much :)
[10:04] <kraut> hmmm, i need the fsck a workaround
[10:05] <kraut> aaah, i think i got it
[10:05] <kraut> brb, rebooting
[10:06] <cooloney> apw: will the local "fdr binary-omap" command  run d-i/udeb stuff?
[10:06] <cooloney> apw: because i can use my cross compile to build a kernel package
[10:06] <cooloney> but it still failed in our PPA native builder
[10:07] <ikepanhc> cooloney: is PPA supported ARM arch?
[10:07] <apw> cooloney, no it won't   fdr binary-arch does that
[10:08] <apw> cooloney, and even then you might need to touch /CurrentlyBuilding in your chroot
[10:08] <cooloney> ikepanhc: oh, yeah, it will send it to our ARM hardware builder because in our package arch=armel
[10:09] <cooloney> apw: ok, this answer helps me a lot
[10:09] <cooloney> so i can test it locally before i dput it to ppa for building
[10:09] <apw> ikepanhc, in some PPAs it can be enabled, not generally
[10:09] <cooloney> the ARM building will cost me 6 hrs to know the result
[10:10] <apw> cooloney do you know about sbuild ?
[10:10] <apw> that uses qemu to emulate arm in an arm chroot, so you use the native compiler
[10:10] <apw> that takes about 2 hours a build for me
[10:13] <cooloney> apw: wow, cool man, i just heard the name of sbuild or pbuild
[10:13] <cooloney> apw: is there any wiki about that?
[10:13] <cooloney> i really wanna to setup such environment
[10:13] <apw> cooloney, not that i know about, i got pointed to it vaguly recently.  i installed 'ubuntu-dev-tools'
[10:14] <kraut> smb: fixed it with using the mount-option "noserverino". thanks for that info
[10:14] <apw> mk-sbuild --arch armel maverick
[10:14] <apw> then that makes this special armel chroot
[10:14] <apw> then you can make a the source package and build it with
[10:14] <apw> sbuild -d maverick-armel *.dsc
[10:14] <smb> kraut, Welcome. And the fix should get into one of the next updates
[10:15] <apw> it does take about 2x the time it takes to do a crosstools build, but it really uses the arm compilers etc
[10:15] <cooloney> apw: ok, let me try that. how's your build machine configuration? i guess it is very powerful
[10:15] <cooloney> and it still needs 2 hrs?
[10:15] <kraut> smb: that's fine
[10:15] <apw> its a 4x
[10:15] <apw> cooloney, you could do the build on emerald though
[10:16] <cooloney> apw: but we might need ask for installing some package as root
[10:16] <cooloney> sudo apt-get install ubuntu-dev-tools
[10:16] <cooloney> in emerald
[10:16] <apw> cooloney, that is possible
[10:16] <apw> what you got to compile on locally ?
[10:18] <cooloney> apw: normally, i cross compile the kernel for arm arch such as fsl-imx51 and ti-omap4
[10:19] <cooloney> fdr clean && export $(dpkg-architecture -aarmel) && CROSS_COMPILE=arm-none-linux-gnueabi- fdr binary-omap4
[10:19] <cooloney> apw: with this command
[10:19] <cooloney> it will generate a kernel package in the parent dir
[10:19] <apw> cooloney, yeah, but i've not found that works when you make the tools package etc, and as you found does not make the udebs
[10:20] <apw> i've used that form myself for most of lucid
[10:20] <cooloney> but i uploaded my source package to PPA, it failed to build because of d-i/udeb
[10:20] <cooloney> right
[10:20] <cooloney> apw: agree, 
[10:21] <cooloney> apw: so sbuild is the solution maybe, right?
[10:22] <apw> cirtianly it worked well for me, though its slower by some margin than crossbuilds, its some 3x the speed of a PPA for me
[10:22] <apw> and on emerald it would likely be faster yet
[10:24] <cooloney> apw: ok, i will try it. at least it is much faster than PPA
[10:24] <cooloney> apw: what's kind of CPU and memory do you have in your build machine running sbuild
[10:30] <apw> cooloney, emerald is on karmic and the tools don't exist
[10:31] <amitk> smb: going to linuxtag?
[10:31] <smb> amitk, Yep
[10:31] <amitk> registered already?
[10:32] <smb> amitk, Err, doh! nope
[10:33] <smb> amitk, Is there actually need? I only see registration for those who want to exhibit
[10:34] <amitk> smb: dunno. I am thinking if I should go. Some interesting talks...
[10:34] <smb> amitk, Yeah, and its not too far from my place. :)
[10:35] <smb> amitk, The hotel question was open, which reminds me to ask again
[11:15] <cooloney> apw: thanks a lot, building in sbuild now
[11:15] <apw> cooloney, awsome ... 
[11:15] <apw> cooloney, hope its less than 6 hours
[11:16] <amitk> cooloney: it's probably worth adding to kernelmaintenancestarter page for arm flavours
[11:18] <cooloney> amitk: right, will do soon
[11:18] <cooloney> apw: yeah, my machine is 4 core and 4G ram 1TB disk
[11:18] <apw> cooloney, so i'd guess more like 2 hours max
[11:18] <apw> which is a 3 builds a working day instead of one
[11:21] <cooloney> apw: great, man. hehe
[11:46] <ogra> dont forget that you build for lucid, not maverick ;)
[11:47] <ogra> (mk-sbuild --arch armel lucid)
[11:49] <cooloney> ogra: yeah, i am build for lucid
[11:58] <cooloney> apw: did you see this before? building in sbuild stops at 'Unpack source', doesn't move on
[11:58] <cooloney> http://pastebin.ubuntu.com/440341/
[11:58] <apw> cooloney, nope
[11:59] <cooloney> apw: need i setup gpg key in sbuild?
[11:59] <apw> that will take a while but not more than minutes
[11:59] <apw> i didn't no
[11:59] <cooloney> ok, 
[12:05] <cooloney> apw: so weird. it stops there for ever
[12:12] <apw> there should be a process doing something
[12:12] <apw> what does it seem to be doing
[12:14] <cooloney> dpkg-source is eating my 100% cpu from my 'top'
[12:14] <Kano> hi, how to DISABLE building perf tools?
[12:17]  * cooloney reboots and try again.
[12:23] <Kano> how about adding a ringbuffer patch?
[12:23] <Kano> http://intellinuxgraphics.org/h264.html
[12:30] <apw> Kano, do_tools=false i think
[12:30] <Kano> will try
[12:30] <apw> Kano, check debian/rules/0-*
[12:31] <apw> you can add that to your amd64.mk and i386.mk
[12:32] <apw> Kano, the kernel components are in maverick already according to that page
[12:32] <Kano> hmm
[12:33] <Kano> but for 2.6.34 rc5 you needed a patch
[12:33] <Kano> and this does not fully apply now
[12:34] <apw> hrm, i see, missread the stupid page. i suspect its aimed to .35, and we'll get it then
[12:36] <Kano> basically the rejects could be fixed
[12:36] <Kano> just you have to change a bit more, a workaround was active in one file
[12:37] <apw> Kano, its a pretty massive patch, not something we'd be that interested in worrying about till we get to our base release
[12:38] <apw> pgraner, we have a number of blueprints without priority, and none of us seems to have the touch to change them
[12:38] <pgraner> apw: nice
[12:38] <Kano> it would be an interesting patch for the edgers ppa
[12:38] <apw> pgraner, any idea how we get the ability ?
[12:39] <Kano> one thing i struggled last time was when i used
[12:39] <pgraner> apw: no, in the LP context blueprints are a black art... I'll give you a call in a few and we can walk thru them and I'll set
[12:39] <Kano> http://www.splitted-desktop.com/~gbeauchesne/libva/ironlake.patches/ubuntu.lucid/kernel/
[12:39] <Kano> those patches are basically against lucid
[12:39] <apw> pgraner, this view http://people.canonical.com/~pitti/workitems/maverick/canonical-kernel-team.html has a good view into them
[12:40] <Kano> i created the binary-headers too
[12:40] <Kano> but
[12:40] <apw> Kano, if X think they are of interest then there might be some point in doing them in edgers
[12:40] <Kano> why do they still need a patch?
[12:40] <Kano> like
[12:41] <Kano> http://www.splitted-desktop.com/~gbeauchesne/libva/ironlake.patches/ubuntu.lucid/linux-libc-dev/
[12:41] <Kano> this was not in the libc-dev
[12:42] <apw> Kano, the split out headers are a subset and stuff not added in the correct way can go astray during stripping, indeed that is common with new stuff
[12:43] <Kano> the same header is always shipped
[12:43] <Kano> hmm
[12:44] <Kano> most likely the patch should be updated
[12:44] <Kano> to patch directly the source
[12:44] <Kano> looks a bit weird
[12:53] <apw> Keybuk, you about ?
[12:54] <apw> Keybuk, think i have a clean-ish patch to allow setting the kernel arguements, my debugging says its doing the right thing
[12:55] <apw> Keybuk, so what form do you want this to do testing
[12:58] <ogra> apw, will it hand over console= options ? 
[12:58] <apw> ogra, it hangs over literally everything on the command line
[12:58] <apw> hands
[12:58] <apw> no exceptions
[12:59] <ogra> (arm and mobile are eagerly waiting for a way to autospawn gettys on serial consoles via upstart, thats a requirement for it)
[13:00] <ogra> though its still not clear to me how to distinguish if you have multiple console= options, i wish the kernel would require enumeration for them
[13:00] <ogra> apw, awesome :)
[13:01] <apw> http://people.canonical.com/~pitti/workitems/maverick/canonical-kernel-team.html
[13:01] <ogra> geez, i didnt know devicetree was essential for maverick !
[13:03] <ogra> "mounting /proc and /sys automatically" oh sweet, we wouldnt need fstab anymore !
[13:04] <Keybuk> apw: kernel in a ppa is always good
[13:17] <abogani2> cnd, apw: FIY I built lowlatency kernel on my PPA (https://launchpad.net/~abogani/+archive/broken) it is based on Lucid but for Maverick packaging is same. I can provide the patch (that is the contents of debian.lowlatency dir plus a little hack in debian/) or a git tree if you need. I hope that simplify your review work.
[13:32] <pgraner> tgardner: ping
[13:32] <tgardner> pgraner, yo
[13:47] <apw> abogani2, sure if you can point me at a git tree that would be great
[13:47] <apw> Keybuk, ack
[13:47] <apw> ogasawara, i see your current tip is an abi bumper, but the abi is not bumpered
[13:49] <apw> ogasawara, sorry not an abi bumper per-see, missing modules even
[14:10] <abogani2> apw: Sure but consider that the package in actual form don't include linux full source code copy so a fresh just cloned Maverick git tree could be deceivingly. Moreover should I use your ubuntu-debian.git as base? At the moment I have implemented, what seem to me, the Lucid way: so there are three directories debian/, debian.master/ and debian.lowlatency/.
[14:11] <apw> abogani2, don't worry about ubuntu-debian, i'll send you a pull request when thats ready to merge into there
[14:11] <apw> abogani2, but seeing the tree is very helpfil
[14:12] <abogani2> apw: Ok. Thanks.
[14:12]  * abogani2 goes to prepare the git tree
[14:17] <apw> Keybuk, ok, the init argument handling is building in my green PPA: https://edge.launchpad.net/~apw/+archive/green/+packages
[14:17] <apw> Keybuk, and the union mount enabled kernel is still in purple: https://edge.launchpad.net/~apw/+archive/purple/+packages
[14:18] <Keybuk> cool, can you mail me to remind me to test?
[14:24] <cnd> apw: https://wiki.ubuntu.com/KernelTeam/KernelSimpleGuide?highlight=(request\-pull)
[14:31] <apw> Keybuk, email away
[14:37] <pgraner> tgardner: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567681
[14:37] <ubot2> Debian bug 567681 in btrfs-tools "please add -a to fsck.btrfs" [Wishlist,Open]
[14:51] <cnd> Keybuk: do you know if we can remove the modalias for vga16fb now, or do we need to wait for some userspace changes?
[14:51] <Keybuk> well, you _can_
[14:51] <Keybuk> there will be consequences though
[14:51] <Keybuk> a zillion screaming nvidia-glx users
[14:51] <Keybuk> we haven't done the bit that goes in its place
[15:05] <cnd> Keybuk: ok, then we'll wait, thanks!
[15:05] <cnd> crimsun: will the hda powersave without popping fix be in maverick?
[15:05] <cnd> just want to double check
[15:21] <vanhoof> if we had to guesstimate, when will 2.6.35 be released to the wild?
[15:22] <cnd> vanhoof: I think kernel cycles average three months?
[15:22] <cnd> so I would guess middle of august
[15:22] <vanhoof> cnd: cool
[15:22] <vanhoof> thank you
[15:22] <bjf> pgraner, just an fyi bug 586150 (comment #1)
[15:22] <ubot2> Launchpad bug 586150 in blueprint "The "Whiteboards" section of blueprints should be given more space (affects: 2) (heat: 12)" [Low,Triaged] https://launchpad.net/bugs/586150
[15:27] <tgardner> vanhoof, ogasawara estimated sometime in September
[15:28] <vanhoof> tgardner: thanks
[15:39] <JFo> can I just say, I love it when i tell someone that they failed to respond on a bug and I expire it only to have them reopen it, fuss about it being closed, then go test the issue and tell me "oops, this is fixed, please close."
[15:39] <JFo> makes me crazy
[15:39]  * tgardner wonders if jfo has noticed that half of all humans are below average
[15:39] <JFo> I have, and most of that half file kernel bugs it seems
[15:40] <JFo> :)
[15:43] <JFo> cnd, wtf? re bug 581312
[15:43] <ubot2> Launchpad bug 581312 in linux (Ubuntu) "Unknown key fee[x] pressed with Dell Latitude XT2 (affects: 1) (heat: 20)" [Medium,Triaged] https://launchpad.net/bugs/581312
[15:44] <cnd> JFo: ummm, what?
[15:44] <JFo> did you see the last comments
[15:44] <cnd> yeah?
[15:46] <cnd> JFo: what about them?
[15:46] <JFo> apparently nothing
[15:54] <tgardner> lag, git log --pretty=oneline $*
[15:57] <JFo> amitk, you around?
 JFo, asac: someone added https://wiki.ubuntu.com/UbuntuARMTeam/ReleaseStatus/MaverickTasks?action=raw to maverick.cfg; should't that rather get into ubuntu-arm.cfg?
 it looks weird to distribute the ubuntu-arm WIs like that, but your call of course
[15:58] <JFo> ^^ from #ubuntu-devel
[15:58] <amitk> JFo: shoot
[15:58] <JFo> amit, the above was what I wanted to show you
[15:59] <smb> lag, To tell git the current top commit you could also use HEAD and HEAD~1 is the one before that and so on
[15:59] <JFo> from pitti
[15:59] <amitk> JFo: that'd be Jamie filing new stuff
[16:00] <ogasawara> apw: bah, forgot about missing modules when I built in fbcon
[16:00] <JFo> ah
[16:00] <ogasawara> apw: will get it fixed up
[16:00] <smb> ogasawara, Heh, yeah. Probably want to do a ignore.modules instead of a modules.ignore...
[16:00] <tgardner> lag, for example, 'git request-pull HEAD~1 git://kernel.ubuntu.com/ubuntu/ubuntu-maverick.git' assuming you have one commit in your local repo that you'd like to be pulled.
[16:01] <lag> Oh okay
[16:01] <ogasawara> smb: yah, I did the same for the last upload due to all the config tweaks
[16:01] <lag> Thanks smb, tgardner
[16:12] <vanhoof> JFo: skype just told me about tomorrow ;)
[16:13] <JFo> heh
[16:53]  * bjf will brb
[16:59] <kassah> What's the best way to load a proposed kernel (I was requested to load 2.6.32.13 from proposed)
[16:59] <kassah> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/511066
[16:59] <ubot2> Launchpad bug 511066 in linux (Ubuntu Lucid) (and 1 other project) "ModemManager: HP ev2210 Sierra MC5725 not detected (affects: 2) (heat: 18)" [Low,In progress]
[17:03] <tgardner> kassah, 'wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32.14-lucid/linux-image-2.6.32-02063214-generic_2.6.32-02063214_amd64.deb; sudo dpkg -i linux-image-2.6.32-02063214-generic_2.6.32-02063214_amd64.deb'
[17:04] <kassah> thanks =)
[17:06] <cking> manjo, you still around?
[17:06] <manjo> cking, yeah
[17:09] <manjo> cking, I think the problem is on my end 
[17:09] <manjo> cking, let me restart mumble
[17:09] <cking> manjo, its at your end
[17:17]  * bjf is back
[17:41] <cnd> anyone have any ideas why when I run the following as root, it works, but when run by pm-utils when power is disconnected, it errors out with error 1:
[17:41] <cnd> setterm -blank 1 -powersave powerdown -powerdown 1 \
[17:41] <cnd>         < /dev/tty1 > /dev/tty1 2>&1
[17:42] <cnd> when run as root, I have to sudo su first, so maybe sudo is doing something extra?
[17:42] <cnd> when pm-utils runs, it's running as root, no sudo
[17:43] <cnd> it's driving me mad...
[17:45] <jjohansen> cnd: environment variables?
[17:45] <cnd> jjohansen: could be, I did a diff of the env output in each case
[17:45] <cnd> nothing stood out as obvious
[17:45] <tgardner> cnd, you might ask kees, but its possible sudo is not granting the right CAPs
[17:46] <cnd> tgardner: it seems like in this case sudo may have more privs than root somehow
[17:46] <cnd> I'm going to strace it to see if I can find out exactly why it dies
[17:46] <jjohansen> cnd: that can happen, a root process doesn't necessarily get all caps
[17:49] <cnd> jjohansen: tgardner: strace FTW
[17:49] <cnd> write(2, "setterm: $TERM is not defined.\n", 31setterm: $TERM is not defined.
[17:49] <cnd> though I had tried it without 2>&1 I thought, and I never saw this
[18:32] <cnd> apw: yesterday you wondered if fdr binary-generic skipdbg=false would force generation of the ddeb without having to mess with touching /CurrentlyBuilding
[18:32] <cnd> I can confirm that's correct
[18:46]  * manjo heading out to get some lunch ... brb 1hr 
[19:55] <jjohansen> ->lunch
[20:06] <kees> where are local references stored in .git ?  i.e. I have an upstream linux-2.6 tree that I want to have as a --reference for a new clone.  but if I forgot to do that during the clone, I can add it later and do a git gc --prune, but I can't figure out where to add it...
[20:06] <tgardner> kees, I doubt it, you'll likely have to reclone
[20:07] <kees> tgardner: nah, smb showed me magic at the last sprint
[20:07] <tgardner> kees, perhaps its more hassle then its worth
[20:07] <tgardner> doh!
[20:07] <kees> well, I have various topic branches now, so I want to manipulate the repo without throwing it away
[20:08] <tgardner> push you topic branches to different repo (like the linux-2.6 repo)
[20:08] <tgardner> you can always delete them later
[20:09] <kees> ah-ha, .git/objects/info/alternates
[20:10] <kees> okay, next up.... I have a remote, I've added a remote to it, how do I create a local branch for a remote master that isn't "origin"?
[20:11] <tgardner> git checkout -b BRANCH origin/BRANCH
[20:12] <tgardner> 'git branch -a' show all of the branches at remote repos
[20:12] <kees> I said "remote" twice there, meant "branch" first time.
[20:12] <tgardner> I figured it out from context :)
[20:12] <kees> sounds like I want  "git checkout -b LOCAL-BRANCH-NAME REMOTE/REMOTE-BRANCH-NAME
[20:13] <tgardner> kees, exactly
[20:18] <kees> can I use "git log" to show other local branch logs?  (i.e. how do I find a commit id to cherry-pick without switching to the origin branch first?)
[20:33] <ogasawara> kees: you can do a `git log <branch name>`
[20:35]  * ogasawara -> lunch
[20:35] <kees> ah! I was trying too hard
[20:51] <achiang> kees: in git, just about every command works on a git identifier, whether it's a human readable name, or a sha1
[20:54] <kees> achiang: seems like format-patch is an exception
[20:56] <achiang> kees: eh?
[20:57]  * ogasawara goes to lunch for reals this time
[20:57] <tgardner> kees, I think format-patch works on a single SHA1, or a range of IDs
[20:57] <kees> achiang: if I'm in a branch, and I want to use "format-patch" I can't specify an arbitrary sha1
[20:57] <kees> tgardner: yeah, my mental problems with git seem to revolve around the "scope" of branches
[20:58] <kees> I'm used to having a full working directory per branch (as with bzr)
[20:58] <tgardner> kees, the syntax can be a bit dense
[20:58] <achiang> kees: interesting. i haven't used format-patch in a long time, not since i switched to stacked git
[20:58] <maks_> bzr is so bizarre
[20:58] <maks_> poor you kees 
[20:59] <maks_> format-patch <sha1sum>^..<sha1sum> kees 
[20:59] <kees> maks_: ah-ha.
[20:59] <kees> what does "^" mean in that syntax?
[20:59] <maks_> the one previous
[20:59] <maks_> you can also use ~1
[21:01] <cnd> mpoirier: these two files (<flavour>.ignore and <flavour>.ignore.modules) tell the build process to ignore checking
[21:01] <kees> neat, that worked.
[21:01] <kees> so, it seems "scope" for git commands is really "all commits ever in any known branch".  only when one uses less specific arguments does it kick down using the current branch's view of commits.
[21:02] <cnd> mpoirier: however, if you are just trying to build a kernel through fdr binary-omap, then you can add skipabi=true skipmodules=true to the command
[21:02] <mpoirier> something like:
[21:02] <lifeless> kees: I think its more 'reachable from reflog heads'
[21:02] <lifeless> kees: vs any commit
[21:02] <cnd> mpoirier: I just realized I forgot to link to the files: http://kernel.ubuntu.com/git?p=cndougla/hedley.git;a=tree;f=debian.mvl-dove/abi/2.6.32-204.16hedley6/armel;h=736bf1ef045abfab6e0930d8031ebdfc5453bfee;hb=HEAD
[21:02] <mpoirier> fakeroot debian/rules binary-omap skipabi=true skipmodules=true ?
[21:03] <tgardner> mpoirier, 'echo 1 > debian.master/abi/2.6.34-4.11/armel/ignore'
[21:03] <cnd> mpoirier: correct
[21:03] <kees> lifeless: ah, true, sounds right.  though I've never tried orphaning a commit and later tried to reach it
[21:03] <achiang> kees: note that format-patch is weird, in that you give it the sha1 of the commit *before* the one you really want
[21:04] <achiang> so that explains why you might be running into "scope" issues
[21:04] <kees> achiang: right, that bit I'm kind of used to now.  but this week I've tried to switch to using multiple topic branches so my existing workflows are slightly confused.  :)
[21:05] <achiang> if you're in master, and are trying to do a format-patch for a branch that has commits *after* master, then it looks like you can't simply specify a <since>
[21:05] <achiang> again, stg ftw. ;)
[21:07] <jjohansen> achiang: curious, have you ever used guilt, and if so how do you find it compares to stg
[21:08] <achiang> jjohansen: i tried using guilt a long while ago and didn't quite like it as much as stg
[21:08] <achiang> let me try and remember why...
[21:08] <jjohansen> fair enough, I defaulted to it as its syntax was closer to quilt
[21:10] <achiang> jjohansen: i think my complaint with guilt was that it followed the git model *too* closely, in that it was a PITA to be working on a patch series and attempt to modify an earlier patch
[21:11] <achiang> but that was about 1.5 years ago, so maybe it's improved a lot since
[21:11] <jjohansen> achiang: hrmm, no its just like quilt except better.  Just pop to the patch edit and refresh.  Better than quilt because any file under git control is automatically added, so no more quilt add/edit
[21:12] <achiang> jjohansen: yeah, ok. then i can't remember why i liked stg better (it has the same model btw)
[21:12] <jjohansen> I think there are a few things that stg probably handles better but, as I said I took a quick look at both an guilt was closer to quilt (which I used all the time)
[21:13] <jjohansen> right, its bascially the same
[21:13] <achiang> maybe it was the mailer? is guilt's send-email wrapper nice/easy to use?
[21:13] <achiang> stg has a nice mail templating feature that i used heavily
[21:14] <jjohansen> ah, that may be it, I have never gotten the mailer to work
[21:14] <jjohansen> and have to fallback to git send-email
[21:14] <jjohansen> of course I haven't tried it for a year
[21:14] <achiang> heh.
[21:15] <jjohansen> hrmm, looking at the current guilt there isn't even a mailer documented, though I am sure I tried playing with it in the past
[21:16] <jjohansen> perhaps it was one of the features that never got completed
[21:39] <tormod> is bug 585551 a udev or kernel bug, anyone?
[21:39] <ubot2> Launchpad bug 585551 in udev (Ubuntu) "mainline kernel makes udevd spin on device removal (inotify event) (affects: 2) (heat: 12)" [Undecided,Confirmed] https://launchpad.net/bugs/585551
[21:40] <mrec> oh dear, since the last Ubuntu update my system randomly reboots
[21:40] <mrec> intel's crap graphicdriver is still not fixed and I'm getting glitches all over the screen randomly
[21:41] <tormod> mrec, update of what exactly?
[21:41] <mrec> systemupdate there was not too much to update, is there any logfile available about system updates?
[21:41] <tormod> dpkg.log
[21:42] <mrec> libc was updated but not sure if that's the issue
[21:43] <tormod> mrec, you have lucid + proposed?
[21:43] <mrec> only lucid
[21:44] <mrec> libc was the most critical update probably I have the list here if it happens again I will report it
[22:09] <phunge0> achiang: hi, i've been having a WARNING in my linux-next kernel build
[22:09] <phunge0> "sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:02.0/slot'"
[22:09] <phunge0> googling showed a thread from a month ago http://lkml.org/lkml/2010/4/12/259
[22:09] <phunge0> but it doesn't look like anything was done about it
[22:09] <achiang> phunge0: yeah, i never really had a chance to debug that. :(
[22:10] <achiang> phunge0: i'm going to ask jesse to drop that patch, i don't have hardware or time to fix it
[22:10] <phunge0> i can help if you're interested, or maybe just revert the patch like you originally requested?
[22:10] <achiang> hm
[22:10] <achiang> phunge0: can you pastebin lspci -vt for me please?
[22:12] <phunge0> achiang: http://pastebin.com/yECfYNZJ ... i'm on KVM, like the original submission
[22:12] <achiang> oh!
[22:12] <achiang> phunge0: you know, i didn't even see that eparis was using kvm the first time around
[22:13] <phunge0> interesting
[22:15] <achiang> the fact that kvm is involved actually makes a lot more sense. i was *really* scratching my head initially about how on earth we could have gotten duplicate slot entries
[22:18] <achiang> phunge0: hm, weird. git grep sysfs_attribute_initialize returns nothing in my tree
[22:18] <phunge0> achiang: yeah, cool... my kvm setup is completely vanilla if you want to try to reproduce
[22:19]  * achiang does a git remote update ; git rebase origin
[22:19] <phunge0> i know only a little about sysfs... sysfs_attr_init?
[22:19] <achiang> oh perhaps that's it
[22:20] <achiang> hm
[22:20] <phunge0> # CONFIG_DEBUG_LOCK_ALLOC is not set
[22:20] <phunge0> it's a noop in my build, so i doubt that'd be it
[22:20] <achiang> i'm not sure that gregkh's email was correct. looking at the comment for sysfs_attr_init, it's talking about lockdep, which is completely unrelated to the warnings you're seeing
[22:20] <phunge0> yeah
[22:21] <achiang> phunge0: so you see that warning in the guest or the host?
[22:21] <phunge0> guest
[22:35] <tormod> why aren't the mainline daily builds, er, daily? :)
[22:38] <JFo> because they build based on when there is an RC
[22:39] <tormod> anyway I hope yesterday's drm-next has what I need from today's missing daily
[22:39] <tormod> JFo, I think they are built more often than that?
[22:41] <achiang> phunge0: can you please pastebin: for i in /sys/devices/pci0000:00/* ; do ls -l $i ; done
[22:41] <achiang> in the guest
[22:46] <phunge0> achiang: http://pastebin.com/rb26vUMW
[22:48] <phunge0> and bus/pci/slots: http://pastebin.com/Se1TGyv7
[22:48] <achiang> phunge0: sorry, one more pastebin please -- can you paste the entire dmesg from your guest so i can see the warnings?
[22:49] <phunge0> http://pastebin.com/Vc1h75Eu
[22:52] <achiang> phunge0: how do you feel about building kernels and testing patches?
[22:52] <achiang> phunge0: if it's too hard, don't worry about it, but if you're able, i'd like you to apply a debug patch for me
[22:54] <phunge0> achiang: i'm leaving work in around 20 minutes, gone until next tuesday :(
[22:54] <achiang> phunge0: how about if i send you an email and you can just report results when you get a chance?
[22:54] <phunge0> yeah absolutely
[22:54] <achiang> phunge0: address? you can /msg me if you want