[04:56] <hallyn> sforshee: stgraber: apw: so sadly with this trivial patch http://paste.ubuntu.com/6889340/ I can create an overlayfs container clone, and sort of start it, but I can't write to anything.
[04:57] <hallyn> oh wait
[04:57] <hallyn> heh i see why, being silly
[04:58] <hallyn> right, works fine.  o/  course then we have the memory limit concerns
[05:02] <hallyn> as for the mknod-if-devicens-restricted idea, that's not feasible without an explicit "this cgroup is now ok" blessing from root.
[07:33]  * apw yawns mightily
[08:04] <ppisati> Friday morning
[08:38] <apw> are you sure ?
[09:28] <eagles0513875_> hey apb1963
[09:28] <eagles0513875_> i mean apw
[09:29] <apw> hi
[10:01] <rbasak> smb: am I right in thinking that all our kernels support hotplugging on Xen (via xenbus and its block devices)? Is it OK to make it a requirement that our kernel will continue supporting this in the future?
[10:02] <rbasak> The background here is an attempt to establish a standard for interoperability between distros for VM images in the ARM world. So we want Ubuntu cloud images to work on some other distro's OpenStack deployment, for example, which might be Xen based.
[10:07] <smb> rbasak, Maybe you could explain a bit more what exactly you expect to work. Adding new devices after boot or unplugging to replace the emulated disks by paravirt ones
[10:10] <rbasak> Sorry, lost connection.
[10:10]  * rbasak tries again
[10:10] <rbasak> smb: am I right in thinking that all our kernels support hotplugging on Xen (via xenbus and its block devices)? Is it OK to make it a requirement that our kernel will continue supporting this in the future?
[10:10] <rbasak> The background here is an attempt to establish a standard for interoperability between distros for VM images in the ARM world. So we want Ubuntu cloud images to work on some other distro's OpenStack deployment, for example, which might be Xen based.
[10:11] <smb> rbasak, Maybe you could explain a bit more what exactly you expect to work. Adding new devices after boot or unplugging to replace the emulated disks by paravirt ones
[10:11]  * smb repeats re-question
[10:11] <rbasak> smb: AIUI, Cinder expects to be able to hotplug a block device
[10:12] <rbasak> So adding new devices after boot, I believe.
[10:12] <rbasak> BTW, my connection is flaky. I may go again :-/
[10:12] <smb> rbasak, I would have to try that with virsh directly. I think virt-manager refuses to try
[10:13] <rbasak> smb: this might not be with libvirt necessarily.
[10:13] <smb> rbasak, what other way would openstack have to talk to xen?
[10:14] <rbasak> I thought it had a more direct nova driver?
[10:14] <smb> rbasak, afaik there is none. There was that xapi stuff that basically is gone for the time being)
[10:15] <rbasak> Oh yes.
[10:15] <smb> So to my knowledge libvirt is what is used (according to jamespage)
[10:15] <rbasak> Hmm. I'm not thinking specifically about Ubuntu here though.
[10:16] <rbasak> It's more in theory for any distro, since the currently proposed spec mandates that guest kernels support both pci(-e?) and xenbus hotplug.
[10:17] <rbasak> I just wanted to make sure that we won't have an issue with that requirement.
[10:18] <smb> rbasak, To know whether the whole chain of things work you probably should ask someone from the server team. ;)
[10:19] <psivaa> jdstrand: bjf: precise kernel sru regression testing for 3.2.0-1630.42 on armadaxp is throwing failure for test_010_proc_maps in our run. 
[10:19] <psivaa> would you mind taking a look: http://pastebin.ubuntu.com/6890443/
[10:19] <smb> rbasak, I can do some experiments with libvirt. Though I have not tried to do that before
[10:19] <fish_> any ideas how I can help fixing/debuggin this issue? https://bugs.launchpad.net/bugs/1275809
[10:19] <ubot2`> Launchpad bug 1275809 in linux (Ubuntu) "(docker/lxc) container restart causes kernel to lockup" [High,Triaged]
[10:19] <rbasak> smb: I'm just asking you about the kernel piece :)
[10:20] <rbasak> smb: am I right in thinking that we have relevant config options turned on?
[10:20] <fish_> since it's not trivial to reproduce I'm worried that anyone will pick it up :)
[10:22] <smb> rbasak, We have at least xenbus in there and if there is a way the managing entity can add things there (this would be xm/xl/virsh from dom0) the kernel handles hotplugging of disks in general
[10:22] <rbasak> smb: I think that's good enough for me - thanks. Assuming you won't want to drop xenbus in the future.
[10:22] <smb> rbasak, Not as long as upstream does not :)
[10:23] <rbasak> smb: OK. Thanks :)
[10:25] <apw> fish_, so you couldn't test 3.14, did you try a trusty 3.13 kernle (which would have aufs)
[10:25] <fish_> apw: good point, I'll try that
[10:30] <fish_> apw: should I try 3.13.2?
[10:31] <fish_> apw: btw, will trusty still contain aufs?
[10:35] <apw> the trusty kernels including the backports ones do yes, not the mainline kernels
[10:43] <fish_> looks like 3.13.2 doesn't include aufs
[10:44] <fish_> apw: hrm, so this one should have it, right? http://packages.ubuntu.com/trusty/amd64/linux-image-generic/download
[10:45] <fish_> eh, that's just a meta deb
[10:45] <fish_> http://packages.ubuntu.com/trusty/kernel/linux-image-3.13.0-7-generic <- this one, right?
[10:48] <fish_> well, I'll just try it
[10:49] <smb> fish_, You will need linux-headers (all), linux-headers (arch) and linux-image (arch) and linux-image-extra (arch)
[10:49] <smb> http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux-headers-3.13.0-7_3.13.0-7.26_all.deb
[10:50] <fish_> smb: hrm, but linux-image should be enough if I just need to boot it and see if I can reproduce my issue, right? I'm not building anything against the kernel headers
[10:50] <smb> http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux-headers-3.13.0-7-generic_3.13.0-7.26_amd64.deb
[10:50] <smb> if there are no dkms packages
[10:51] <fish_> no, no dkms
[10:51] <smb> but you need at least the -extra package too
[10:51] <fish_> for firmware and stuff?
[10:51] <smb> http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux-image-extra-3.13.0-7-generic_3.13.0-7.26_amd64.deb
[10:51] <smb> No for most other modules
[10:51] <fish_> ah okay
[11:36] <caribou> Is 3.13 still the target kernel version for Trusty ?
[11:42] <apw> caribou, yes
[11:42] <caribou> apw: ok, thanks
[11:49] <fish_> apw: looks pretty good so far
[11:50] <fish_> apw: system still hasn't crashed
[11:58] <apw> fish_, well that is encouraging, as that will be the latest LTS backports kernel after the next release
[13:35] <bjf> psivaa, you only see that on armadaxp?
[13:36] <psivaa> bjf: for precise, yes.  i have not tested that with pandaboard
[13:36] <psivaa> bjf: and this was not seen in the previous kernel on armadaxp
[13:38] <bjf> psivaa, jdstrand let me update my snapshot and put out a new release of the autotests. i know some work was done on that test recently
[13:39] <psivaa> bjf: just checked an amd64 precise run that just completed and the failure is seen there too
[13:40] <bjf> psivaa, ack, give me 30 min. to get you a new release
[13:40] <psivaa> bjf: ack
[14:23] <bjf> psiva, releae email sent. this updates all the QRT snapshots as well as fixes the issue with the results for the dashboard (i hope)
[14:35] <rtg> jjohansen, kamal, ppisati: rebooting tangerine for kernel update
[14:35] <jjohansen> rtg: ack
[14:40] <stgraber> hallyn: what kind of memory limit concerns for unprivileged overlayfs? does overlayfs actually keep that much stuff in memory instead of storing to the writable layer (which should respect memory quotas if it's a tmpfs)?
[14:40] <apw> open directory listings, other than that most things occur on the underlying filesystems which is kinda the point
[14:47] <hallyn> stgraber: that's why i was vague - i remember someone mentioning a concern last week, but couldn't remember exactly what it was
[14:48] <hallyn> Perhaps I'll send the patch to kernel-list for discussion
[14:49] <hallyn> really if it's a vfsmounts-in-kernmem concern, we already have that problem with unprivileged bind and tmpfs mounts
[14:49] <hallyn> in fact, tmpfs mounts are a bigger concern
[14:49] <stgraber> would be great. I'd very much like to have a final yes/no on this ASAP as we need to update upstream LXC to allow snapshotting and ephemeral containers if we can start using overlayfs unprivileged.
[14:49] <hallyn> ok will send it today.  all 5 lines :)
[14:59] <caribou> apw: want me to handle the SRU for bug 1259570 ?
[14:59] <ubot2`> Launchpad bug 1259570 in linux (Ubuntu Precise) "kexec should get a disabling sysctl" [Medium,New] https://launchpad.net/bugs/1259570
[15:07] <apw> caribou, tyhicks is working out which ones this is needed for
[15:08] <caribou> apw: ok, fine thanks
[15:51] <rtg> apw, I assume we can drop the trusty ppc64el branch now ?
[15:57] <apw> rtg, from the main repo?  ues
[15:57] <apw> yes
[15:57] <rtg> yup
[16:38] <apw> jsalisbury, one for your "keeping a vague eye on" list: 1277165
[17:06] <jsalisbury> apw, ack
[17:18] <rtg> apw, I've set annotations to 'CONFIG_CC_STACKPROTECTOR                       p policy<(arch amd64 i386 armhf &/ value y) | value n>', but I'm still getting enforcer errors.
[17:18] <rtg> apw, I've pushed unstable
[17:21] <infinity> rtg: Is this a workaround for toolchains that don't have SSP?
[17:21] <infinity> rtg: If so, ppc/ppc64el have SSP too, only arm64 doesn't...
[17:21] <infinity> (arm64 is almost there...)
[17:23] <rtg> infinity, not according to 3.14-rc1.
[17:23] <rtg> git grep HAVE_CC_STACKPROTECTOR arch
[17:23] <rtg> arch/Kconfig:config HAVE_CC_STACKPROTECTOR
[17:23] <rtg> arch/Kconfig:   depends on HAVE_CC_STACKPROTECTOR
[17:23] <rtg> arch/arm/Kconfig:       select HAVE_CC_STACKPROTECTOR
[17:23] <rtg> arch/mips/Kconfig:      select HAVE_CC_STACKPROTECTOR
[17:23] <rtg> arch/sh/Kconfig:        select HAVE_CC_STACKPROTECTOR
[17:23] <rtg> arch/x86/Kconfig:       select HAVE_CC_STACKPROTECTOR
[17:23] <rtg> perhaps more arches will get enabled throughout the series
[17:23] <infinity> Curious.
[17:24] <rtg> yeah, seems like a step back
[17:25] <apw> rtg, did you sort your enforcer errors or are they stull there
[17:25] <rtg> apw, they are still there. I don't understand that arcane language
[17:26] <rtg> I'm too stupid I guess
[17:27] <apw> rtg, ok i'll have a look shortly
[17:28] <rtg> apw, thanks
[17:36] <apw> rtg you were mixing annotations and enforcement, need to sort that split out
[17:36] <apw> rtg pushed something which workes for now
[17:36] <rtg> apw, hmm, ok
[17:37] <rtg> apw, are you working on grouper yama ?
[17:38] <rtg> apw, actually, you should be off drinking a beer by now. go away.
[18:01] <apw> rtg, grouper == 3.1 yes ?
[18:01] <rtg> apw, yup, just pushed it
[18:01] <apw> rtg, tyler was going to do it, but i am sure he won't mind if you have
[18:02] <rtg> apw, he sent patches on the mailing list
[18:02] <apw> oh ok, cool.  i am in the midst of uploading the others
[18:02] <apw> (to the PPA)
[18:02] <rtg> apw, there is also an interest patch proposal from hallyn on overlayfs that you ought to have a look at
[18:02] <apw> rsalveti was happy for them to be applied and pushed there
[18:02] <rtg> interesting*
[18:03] <apw> rtg, the usespace mount thing one?  i have been having discussions with security about it indeed
[18:03] <rtg> apw, I'll button up grouper and upload it to the PPA
[18:03] <apw> rtg, i have the others "in progress"
[18:03] <rtg> ok
[18:03] <apw> i'll do them shortly before chugging some beer
[18:17] <rtg> apw, grouper uploaded
[18:17] <apw> rtg, ack
[18:18] <rtg> apw, thats the only 3.1 kernel, right ?
[18:18] <apw> rtg, yep, maguro was 30
[18:18] <apw> 3.0
[18:19] <rtg> cool
[18:19] <apw> and i hope is dead
[19:15] <apw> rsalveti, i believe that is all of the touch kernels fixed up with the yama bits i was talking about, and all building/built in the CKT PPA; if you could let us know when you want something else done with them
[19:25] <rsalveti> apw: great, thanks
[19:53] <jsalisbury> apw, rtg Do you guys know of a way to get "git am" to format failures similar to when "git cherry-pick" fails?  For example, when git cherry-pick fails, the file it was modifying has a block with the HEAD and what the patch was trying to do.  
[19:53] <jsalisbury> apw, rtg 
[19:54] <jsalisbury> A git am failure leaves the file it was modifying unchanged and just lists the patch in .git/rebase-apply/patch
[19:54] <rtg> jsalisbury, when git am fails I usually just 'patch -p1 < 0*' and then fix it up by hand, then 'git am --resolved'
[19:54] <jsalisbury> Just looking for an easier way to do a diff to see why it failed
[19:55] <jsalisbury> rtg, hmm, yeah that sounds like it would help.  Let me give that a try
[19:57] <jsalisbury> rtg, does 'git am --continue' have the same effect as 'git am --resolved' ?  Seems like it from the man page but just wanted to check.
[19:58] <rtg> jsalisbury, it might I guess if you are importing multiple patches
[19:58] <rtg> you might have to --resolved first, then --continue
[19:58] <jsalisbury> rtg, cool, thanks.
[20:01] <jsalisbury> rtg, awesome, 'patch -p1 < patchname.patch' actually fixed the issue without me having to fix anything :-)  That's definitively the way I'll do it when I get a 'git am' failure from now on.
[20:02] <rtg> jsalisbury, patch is a little less anal about context, though you wanna look closely to make sure its done the right thing. you can likely get git am to be a little less restrictive too, but I've always just used patch
[20:02] <apw> git am -C1 gives you the same as patch
[20:03] <jsalisbury> rtg, apw, great, thanks!
[20:06] <bjf> jsalisbury, i do exactly what rtg does
[20:07] <jsalisbury> bjf, apw, rtg, for context, I'm just practicing turning the crank.  I'm applying the latest 3.11.10.4 patches from henrix's -review branch to a saucy tree.  I'm was just looking for the most efficient way to resolve a patch failure.
[20:18] <bjf> jsalisbury, i think there are upstream stable release, you could pick one and apply the commits, they all need to be processed
[20:21] <jsalisbury> bjf, is there a list or way to tell which ones have been done already?  For Saucy, do we wait until 3.11.10.4 goes from the linux-3.11.y-review branch to linux-3.11.y to apply them to saucy master-next?
[20:22] <bjf> jsalisbury, we don't apply them until they have been "released"
[20:22] <jsalisbury> bjf, ack
[20:22] <bjf> jsalisbury, you just go from stable branch/tree to stable branch/tree and see what has been applied in the related ubuntu tree
[20:23] <bjf> jsalisbury, sconklin and i are the only others that apply them so it's easy enough to know if someone is working on one already
[20:24] <bjf> jsalisbury, and if we know you are handling it, we'll just stand back and watch :-)
[20:24] <sconklin> waaay back :-)
[20:24] <jsalisbury> heh
[20:24] <sconklin> here, hold my beer
[20:25] <jsalisbury> bjf, sconklin, so how do I tell which stable release is ready?  Do you get that from one of the mailing lists?
[20:26] <sconklin> the maintainer announces, and there's also typically a release commit at the tip
[20:26] <jsalisbury> got it
[20:27] <jsalisbury> bjf, sconklin, Do you recommend which one I should start with?  I don't want to step on one you've already started.
[20:27] <bjf> jsalisbury, we're not working on any of them right now
[20:27] <sconklin> I don't have any in progress
[20:28] <bjf> jsalisbury, start with precise and work you way through saucy
[20:28] <jsalisbury> bjf, sconklin So there is nothing to do for Saucy yet, because 3.11.10.4 is still in review, correct
[20:28] <bjf> jsalisbury, that's what i normally do
[20:32] <sconklin> jsalisbury: you can always go ahead and apply to master-next. If a release gets held up or respun, everything has to be manually sorted and/or rebased anyway, and what's another few hundred patches, more or less? :-)
[20:32] <jsalisbury> bjf, sconklin Ok, I'll give precise a go.  I'll push what I do to my git location on zinc and send a pointer for you guys to review
[20:32] <sconklin> jsalisbury: perfect
[20:40] <jsalisbury> bjf, sconklin, It looks like the latest 3.2 stable kernel is 3.2.54.  Looking at the Precise master-next branch, it looks like it may have already been applied:
[20:40] <jsalisbury> e7ebafbdb203bed536102c184198bcf4f8f71d4f Linux 3.2.54
[20:40] <jsalisbury> I see a tracking bug as well: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1266546
[20:40] <ubot2`> Launchpad bug 1266546 in linux (Ubuntu Precise) "Precise update to 3.2.54 stable release" [Undecided,In progress]
[20:42] <bjf> jsalisbury, that's likely. upstream stable for that is benh and there's quite a period between upstream stable releases for 3.2
[20:44] <jsalisbury> bjf, should I give Quantal a try then?
[20:44] <bjf> jsalisbury, like i said, i just work through them all to check .. i'm looking at Q right now
[20:44] <jsalisbury> bjf, ack
[20:45] <Teduardo> Ah, there was no new netboot image put in for 12.04.4.. bummer
[20:46] <Teduardo> yes, build a 50,000 node cloud with no nic drivers =)
[20:46] <Teduardo> you win internets
[20:47] <Sarvatt> Teduardo: http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-amd64/current/images/saucy-netboot/
[20:47] <jsalisbury> bjf, So we apply all the latest upstream updates to master-next.  How do those updates then make it into all the various flavors, or does that all happen by the builder?
[20:49] <Teduardo> the saucy netboot will install precise?
[20:49] <Sarvatt> yep, its in precise, uses the saucy kernel just like 12.04.4 does
[20:50] <Sarvatt> http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-amd64/current/images/raring-netboot/ for 12.04.3, etc
[20:50] <Teduardo> so if that works why not just make that the netboot image that comes up in the main precise thing
[20:54] <infinity> Teduardo: "the main precise thing"?
[20:55] <Teduardo> http://cdimage.ubuntu.com/netboot/ -> click on 12.04
[20:55] <Teduardo> wouldn't it make sense to put the one with the most driver support right there in front?
[20:56] <infinity> Teduardo: Right, I was just going to edit that today.  Though "12.04" will still point to the one with the 3.2 kernel, I'm just going to at the HWE kernel options at the bottom.
[20:56] <Teduardo> so people aren't like.. zomg why doesnt ubuntu support NICs that were released in 2012
[20:56] <infinity> s/at/add/ .. Brain/finger disconnect.
[20:58] <Teduardo> So just to be clear, the 'saucy-netboot' in the precise tree, doesn't actually install the 3.8 kernel on OS right? it just uses it during the install?
[20:58] <Teduardo> the actual kernel that is installed is the regular thing that comes with 12.04.4?
[20:58] <rtg> Teduardo, yes
[20:59] <Teduardo> cool, thanks for your help. i get to go home now!
[20:59] <Teduardo> wheeeeeeeeee....
[21:06] <infinity> Teduardo: It doesn't use a 3.8 kernel at all...
[21:06] <infinity> Teduardo: It both boots with and installs a 3.11 kernel.
[21:08] <infinity> I'm so renaming those images for trusty to be less confusing.
[21:08] <bjf> jsalisbury, yes, we just update master-next and building multiple arches/flavours from the same branch/repo makes it all work
[21:12] <antarus> qq, do signed kernel modules require secure boot?
[21:13] <antarus> or is the kernel using some other model of trust for them?
[21:18] <infinity> antarus: Not related to secure boot at all, no, it's the kernel that does the checking.
[21:20] <antarus> infinity: hrm
[21:20] <antarus> infinity: so for modules built with dkms...
[21:20] <antarus> signing seems...like it would be difficult?
[21:20] <antarus> although, building modules on the localhost seems insane if you don't trust localhost
[21:21] <antarus> so perhaps not so much ;p
[21:21] <infinity> It's a bit of an unsolved problem, yes.  We discussed this at plumbers a while ago and no one had any bright ideas.
[21:21] <antarus> well in my proposal users can only run specific kernels, so we could in theory precompile modules for them
[21:21] <antarus> and sign those
[21:21] <infinity> You'd need to update the keyring to include your signing key too.
[21:22] <infinity> Since the signing key we use for our kernel binaries is generated and thrown away during the build process.
[21:25] <antarus> yeah
[21:25] <antarus> we will probably be stuck building our own copy of your kernel sources anyway ;p
[21:25] <antarus> so might as well use our own keys to sign
[21:26] <infinity> I'd like to solve this more elegantly, so "just rebuild the kernel" isn't the go-to option.
[21:27] <infinity> But other than that one session at plumbers when we all agreed it was too hard and we'd think about it later, I've not put much thought into it.
[21:27] <antarus> this is all pie in teh sky stuff right now
[21:27] <antarus> we have a summit internally in a few weeks
[21:27] <antarus> and I'm trying to think up ideas that we could do
[21:28] <antarus> particularly if we started over
[21:28] <antarus> and aborted the legacy mess we had today ;p
[21:28]  * marrusl wanders in
[21:28] <infinity> marrusl: Shoo.
[21:28] <infinity> marrusl: Whenever you're around, it seems to generate work.
[21:30] <marrusl> infinity, only "seems"?
[21:31] <infinity> antarus: So, yes, in a nutshell, the dkms-on-localhost use-case assumes that you trust localhost once it's booted, so you use a local signing key and scream "la la la, this doesn't feel right".  It's the centrally-distributed extra modules use-case that's more interesting (as that can be better locked down), and I'd like to come up with a sane solution for that.
[21:39] <jsalisbury> bjf, sconklin Just did a bunch of clones to my home systems that I can --reference for future clones :-)
[21:39] <jsalisbury> sconklin, bjf, I see that Quantal only has up to 3.5.7.27
[21:39] <jsalisbury> sconklin, bjf, So it looks like it needs 3.5.7.28 and 3.5.7.29 updates.  I can give that a go.
[21:40] <sconklin> jsalisbury: I generally reference Linus's upstream repo, as the vast majority of everything else is also in there
[21:46] <jsalisbury> sconklin, bjf Where there are two upstream releases to apply, do we do them one at a time, and create a seperate stable tracker bug for each?  Or can I apply all the patches from each in one shot?
[21:46] <bjf> jsalisbury, i do what sconklin said
[21:47] <sconklin> jsalisbury: apply the ones from the upstream maintainer's tree. I usually create a single tracking bug even if there are multiple upstream releases
[21:48] <sconklin> just make sure that the list of commits in the bug includes all the ones in both upstream updates, and that every commit in your branch has the bug id added
[21:48] <sconklin> jsalisbury: you know about maint-modify-patch, right?
[21:48] <jsalisbury> sconklin yes
[21:48] <bjf> jsalisbury, again i do the same as sconklin
[21:48] <jsalisbury> sconklin, that makes it easier to do them in one pass instead of two :-)
[21:49] <sconklin> good. You can expect it to throw errors on patches with unicode in people's names. This should really be fixed in the script but I have been just going back to verify that it did the right thing.
[21:50] <sconklin> and the way I do that is - say I was adding my SOB. I just "grep -v sconklin *patch" and it'll list any without my sob
[21:50] <sconklin> You'll know it if you see it :-)
[21:51] <jsalisbury> sconklin, looks like 200 patches for 3.5.7.28 and 3.5.7.29: 
[21:51] <jsalisbury> git log --pretty=oneline v3.5.7.27... | wc
[21:51] <jsalisbury>     200    1773   19309
[21:51] <sconklin> not surprising.
[21:51] <sconklin> builds character :-)
[21:51] <jsalisbury> heh :-)
[21:56] <jsalisbury> sconklin, do I add my sob when running the 'git format-patch' in the upstream tree, or does the maint-modify-patch do it for me?
[21:58] <sconklin> I just extract all the patches using "git format-patch -k tag.." and then add SOB and tracking bug number using maint-modify-patch
[21:58] <jsalisbury> sconklin, got it.  thanks!
[21:59] <jsalisbury> sconklin, Here's the tracking bug: https://bugs.launchpad.net/bugs/1277722  I'll add the subjects of all the patches.  Going to apply them now, and tackle the failures :-)
[21:59] <ubot2> Launchpad bug 1277722 in linux (Ubuntu Quantal) "Quantal update to v3.5.7.29 stable release" [Undecided,New]
[22:00] <sconklin> cool.
[22:07] <jsalisbury> sconklin, what is the format for --sob when passing it to the maint-modify-patch script?  
[22:07] <jsalisbury> sconklin, seems to fail for me.  I don't have an .kteam.rc file on my system.  Maybe I need one?
[22:09] <sconklin> yeah, you have to copy that rc file to your home dir and add your own name/email/nick
[22:10] <sconklin> you can add those to the kteam-tools sample version of that rc file, too if you want
[22:10] <jsalisbury> cool, thanks.  Looks like the script told me that, heh: ** Error: No aliases found, the required configuration file may be missing. Copy the file kteam-tools/maintscripts/doc/example_kteam.rc to ~/.kteam.rc.
[22:12] <sconklin> I think I added that error message in a rage one day
[22:14] <jsalisbury> sconklin, hmm, I get the unicode warning with the maint-modify-patch script:
[22:14] <jsalisbury> /home/jsalisbury/src/kteam-tools/maintscripts/maint-modify-patch:253: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
[22:14] <jsalisbury>   if expanded not in existing_sobs:
[22:15] <bjf> jsalisbury, just ignore it
[22:15] <sconklin> yeah, that's the one
[22:15] <jsalisbury> Ok
[22:15] <sconklin> you can verify that your SOB was applied to all the patches using grep -v, if you want to double check
[22:15] <jsalisbury> Yeah, looks like it did the right thing :-)
[22:19] <jsalisbury> sconklin, do you have a grep or something to pull the subject out of the patches, while dropping the "Subject" text, which I'll put in the bug tracker?  If not, I can figure one out. 
[22:20] <sconklin> I generally concoct a line something like this in the upstream maintainer's tree:
[22:20] <sconklin> git log --oneline <tag>.. | cut -b 47- > patchlist.txt
[22:21] <sconklin> and then I edit that and prepend " * ", or whatever the line beginning should look like (can't remember atm)
[22:22] <sconklin> adjust the 47 to suit, and you may need other options to git log. Lemme see if I have that in a script
[22:23] <sconklin> jsalisbury: I apparently have not saved that anywhere
[22:24] <jsalisbury> sconklin, Ok, I can figure out some sort of grep/awk combo.
[22:24] <jsalisbury> sconklin, If a patch fails because it's already applied, and I skip it, do I still add it to the bug tracker?
[22:25] <sconklin> I don't worry about that too much. If I already have the list in the bug I don't bother removing it
[22:38] <jsalisbury> sconklin, sweet, only two patches failed, and that was because they were already applied :-)
[22:38] <sconklin> best case scenario.
[22:40] <sconklin> You're more likely to run into conflicts with older kernels, as there may be patches which conflict with the context because they aren't in the upstream stable tree. That's not common, but it happens, and most of the time, it's only context, and for things like PCI id's in a driver or lists like that
[22:48] <jsalisbury> sconklin, I came up with this to pull the subject out of all the patch files:
[22:48] <jsalisbury> cat * | grep Subject: | awk '{first = $1; $1 = ""; print $0}'
[22:48] <jsalisbury> sconklin, but it seems to drop some subject text if a subject has a carriage return in it
[22:49] <sconklin> jsalisbury: dunno, I take the text from a git log in the upstream maintainer's tree, not from the patch files
[22:49] <jsalisbury> sconklin, heh, yeah I guess I could make it easy and just get it from git
[22:59] <jsalisbury> sconklin, cool, looks like I just need --pretty=%s:  
[22:59] <jsalisbury> git log --pretty=%s v3.5.7.27... > subjects
[22:59] <jsalisbury> sconklin, Thanks for all the help!
[23:00] <jsalisbury> sconklin, I'll finsh up the tracking bug, push to my tree on zinc and send an email with a pointer to you and bjf
[23:00] <sconklin> awesome! Yeah, git is your friend in a lot of ways, there are a ton of formatting options for logs
[23:02] <jsalisbury> sconklin, Thanks again!  Enjoy your weekend