[04:25] <cwillu_at_work> smb`, not sure if you got the message; the thing that henrix_ pointed out is correct
[07:01] <smb> cwillu_at_work, I saw the email exchange yesterday but not having set any brain power on it. And now I have one more important thing to archive first: coffee...
[07:02] <cwillu_at_work> let the hunt begin!
[07:45] <smb> Mischief managed!
[08:02]  * apw yawns
[08:05]  * smb shares some coffee
[08:08] <apw> sounds like a good plan indeed
[08:35] <apw> henrix, yo ... so i see you are wrapping an sru kernel for quantal
[08:35] <apw> henrix, you need to be aware for quantal there is now an additional package to prep
[08:36] <henrix> apw: ah, the signed thing?
[08:36] <apw> henrix, indeed the signed thing
[08:36] <henrix> apw: ok, i have completely forgot about that indeed
[08:36] <apw> there is a new repo, ubuntu-quantal-signed, which you need to checkout, then that needs to have the exact same version as the main kernel -- it has an update-version script in it which should sync the two for you
[08:37] <apw> it can and should be uploaded at the same time as linux, it has binary dependancies in it to make it build in the right order
[08:37] <apw> when you get to preparing that package, it makes sense for me to review that one
[08:37] <apw> henrix, ^
[08:38] <henrix> ok, cool.
[08:38] <henrix> i have already pushed the other git trees
[08:38] <henrix> so i was going to prep the pkgs
[08:38] <henrix> i'll take a look at this new package in a few minutes
[08:38] <henrix> and ping you for review
[08:38] <apw> henrix, is there a sensible page i can add the details of how it works etc
[08:39] <apw> in the wiki.  the nearest i can find is https://wiki.ubuntu.com/KernelTeam/StableHandbook/StablePackageBuilding but it seems somewhat thin on detail
[08:39] <henrix> apw: let me have a look...
[08:42] <apw> henrix, the basic plan with linux-signed is to run update-version ../ubutu-quantal; and then package the result up.  the update-version thing prints out the signing and commit commands to simpify use
[08:43] <henrix> ok, i'll give it a try in a few and ping you if any doubts. /me was sure there was a more detailed wiki page where this could be added...
[08:44] <henrix> maybe i need more coffee to find it...
[08:49] <caribou> smb: would you have a minute to take a look at an EC2 kernel panic trace ?
[08:50] <smb> caribou, maybe... though I am not sure I want to ... yet another one... Oh well anyway... where?
[08:51] <caribou> smb: I'll PM you the pastebin link
[08:51] <wmp> who can look: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1068340
[08:51] <ubot2> Launchpad bug 1068340 in linux "I havent second thread" [Medium,Incomplete]
[08:51] <caribou> smb: just want to know if this rings a bell to you
[08:52] <wmp> and why i cant add 2 attach in one comment?
[08:52] <caribou> smb: I've been trying to setup kernel dump on an test EC2 instance but didn't have any luck
[08:52] <smb> caribou, crashdump does not work for pv guests
[08:53] <caribou> smb: I expected that :)
[08:53] <cwillu> smb, just a heads up, given that you weren't cc'd:  [PATCH] sched, autogroup: fix kernel crashes caused by runtime disable autogroup
[08:54] <smb> cwillu, Did you see the change I am wondering about. Maybe you want to try it
[08:54] <cwillu> I saw your patch
[08:54] <henrix> apw: ok, so i've pushed to my git tree the new Q -signed package. do you have some time to take a look at it?
[08:54] <smb> caribou, If you can reproduce it on a local xen host you could use xen dumps
[08:55] <caribou> smb: k
[08:55] <henrix> apw: there's another script (download-signed)... what's its purpose?
[08:57] <smb> cwillu, Ah ok, so they moved things a bit... *shrug* if that helps
[09:02] <smb> cwillu, Thanks for the heads up... was that in upstream already or right now "only" on mailing lists? Need to make sure to backport that as well to stable
[09:03] <cwillu> I just got it 30 minutes ago
[09:03] <cwillu> mailing list
[09:03] <cwillu> yep, they didn't cc stable either; I'll test it tomorrow and poke them re: cc if nobody has yet
[09:03] <cwillu> er, re: cc'ing stable
[09:04] <apw> henrix, download-signed is part of the workings of the packag
[09:04] <apw> package
[09:04] <apw> it is used at build time on the buildds, not something you use
[09:04] <henrix> apw: ack
[09:04] <apw> henrix, will have a look now
[09:04] <henrix> apw: cool, thanks
[09:07] <apw> henrix, ok my bad you had an out of date tip, you'll need to redo that :/
[09:07] <henrix> apw: heh, no prob. gimme 1 min
[09:07] <apw> henrix, somehow i had managed to push the tag and not master, not quite sure how i managed that
[09:09] <henrix> apw: done
[09:10] <apw> henrix, looks good to me
[09:10] <henrix> apw: i guess we'll have to change the shankbot to handle this new pkg as a task in the tracking bug
[09:11] <apw> henrix, yeah i recon so indeed
[09:11] <henrix> apw: so, there's nothing special to build this pkg, right? a regular dpkg-buildpackage will do the job, correct?
[09:12] <apw> henrix, exactly that
[09:12] <henrix> apw: cool
[09:45] <apw> henrix, ok pushed -signed, and pushed the two missing tags
[09:46] <henrix> apw: great, thanks
[09:55] <dupondje> Somebody else is noticing shutdown issues sometimes?
[09:55] <dupondje> Like 1 on 10 times, shutdown just freezes, and I have to pull the power :(
[09:55] <dupondje> any hints to debug this?
[09:55] <tjaalton> is the old 3.1 packaging from early precise around somewhere?
[09:56] <tjaalton> huh, git of course
[10:04] <henrix> apw: just to confirm: i *must* upload linux-signed_3.5.0-18.29_source.changes right after linux_3.5.0-18.29_source.changes, right?
[10:05] <apw> henrix, the world won't end or anything if you don't.  they can be uploaded together safely.  linux-signed should be uploaded each time linux is abi bump or not.
[10:06] <henrix> apw: ok, understood. thanks :)
[10:06] <apw> henrix, expect linux-signed to fail 'depwait' which will resolve itself when the main build completes
[10:06] <apw> this is normal
[10:06] <henrix> apw: ack
[10:07] <apw> henrix, when you are getting shankbot fixed we need to check it is making bugs for lowlatency
[10:07] <apw> for quantal
[10:08] <henrix> apw: ok, we'll do that as well.
[10:11] <apw> henrix, i assume you haven't uploaded quantal yet ?
[10:11] <henrix> apw: no, not yet. but i was about too...
[10:11] <apw> henrix, cool, i just didn't see it in the tree
[10:11] <henrix> found any prob?
[10:12] <apw> s/tree/PPA
[10:12] <apw> no no problem, i was going to do the lowlatency rebase
[10:12] <apw> and upload that to the PPA as well
[10:12] <henrix> ok, cool. i'll be uploading it in a min. need to download the .orig.tar.gz first :p
[10:12] <apw> henrix, btw currently linux-signed only exists for linux, there is no linux-*-signed as yet
[10:12] <apw> heh
[10:14] <henrix> apw: does that mean we'll have to create the other -signed pkgs? 
[10:14] <apw> henrix, not as yet, we're only supporting signed boot on linux for now
[10:15] <henrix> apw: ah, ok. uff
[10:15] <apw> henrix, it is likely we will get more -signed packages for some branches in the future, but not for now
[10:15] <henrix> ack
[10:34] <caribou> Q: is there some kind of wrapper around git-send-email to automate patch submission ?
[10:34] <henrix> apw: building. as you referred, the -signed pkg failed due to deps. i'll retry it later once amd64 is done
[10:34] <caribou> like automating patch numbering in subject: & such ?
[10:35] <einonm> caribou: git send email does that for you, e.g....
[10:35] <einonm> git format-patch <first ref>...HEAD
[10:35] <einonm> then git send-email 000* --to etc
[10:36] <caribou> einonm: yeah, I've done that & used the git send-email command on the Wiki
[10:36] <caribou> einonm: doesn't seem to number the patch in the subject though. Maybe it needs to be done manually
[10:37] <einonm> caribou: hmmm, not in my experience... can you be more specific about the commands you're using?
[10:38] <einonm> caribou: It's actually the git format-patch line that formats the email header. You'll need to pass it a list of the git commits to number them correctly
[10:39] <caribou> einonm: maybe that's because I only have one commit
[10:39] <einonm> yes. It doesn't number a list of one patch
[10:39] <caribou> einonm: I followed the description here : https://wiki.ubuntu.com/Kernel/Dev/KernelBugFixing#Forward_the_Commit_for_Approval
[10:40] <caribou> einonm: ok, I'll test with two patches
[10:41] <einonm> If there's only one patch, is there a need to number it?
[10:41] <einonm> just a list of commit refs will do, you don't have to specify a range all the time
[10:42] <einonm> but for a single ref, it will create a list of the patches between that and the HEAD, so for a list of individual patches, you'll need to specify <first~1>...<first> <second~1>...<second> etc
[10:44] <caribou> einonm: you're right, I just tested with 2 commits & it numbers it correctly.
[10:44] <caribou> einonm: thanks for pointing that out
[10:44] <einonm> no probs :)
[10:51] <apw> henrix, it will retry itself without your intervention shortly after the end of the main build.  i confirmed this behaviour in my PPA previously
[10:52] <henrix> apw: ack
[10:53] <apw> caribou, how are you dumping the patches, git format-patch seems to have numbered them before i feed them to git send-email
[11:15] <einonm> I was talking crap about giving a list to format-patch. It only takes a single range ...
[11:16] <einonm> but to always number, you can use the -n option, even if there's only one patch
[11:19]  * henrix -> lunch
[11:29] <doko> apw, rtg, ogasawara: gcc-4.7 in r will be published in 5min. time to upload the kernel headers
[11:30] <apw> doko, ack
[11:33] <caribou> apw: yes, indeed, unless there is only one patch
[11:33] <apw> caribou, ahh yes, that would make testing seem like it didint
[11:35] <caribou> apw: just wanted to get things right for my first patch submission :)
[11:36] <apw> heh ... always a good idea indeed
[11:37] <caribou> apw: well, it's on its way now, & tested on Quantal & Precise
[11:37] <caribou> apw: should something be done on the public bug (i.e. identify it for Quantal & Precise or such) ?
[11:43] <apw> caribou, yeah it should be targetted to same indeed
[11:43] <apw> bug #?
[11:43] <apw> even if we say no and Won't Fix them they should exist to document the decision
[11:43] <caribou> apw: LP: #1056746
[11:44] <apw> bug #1056746
[11:44] <ubot2> Launchpad bug 1056746 in linux "kernel thread hang on iscsi target disconnect when multipath is active" [High,In progress] https://launchpad.net/bugs/1056746
[11:44]  * caribou needs to update the title: multipath is not mandatory
[11:44] <apw> caribou, is this alreayd fixed upstream ?
[11:45] <caribou> apw: yes. I cherry-picked the commit & tested it
[11:45] <apw> ok i'll close it for raring then
[11:45] <caribou> apw: submitted the patch for review to the ML ~1h ago
[11:46] <caribou> hence my questions regarding git send-email
[11:47] <apw> yep ... i've "given" the P and Q tasks to you and closed out the R
[11:51] <apw> caribou, are you subscribed to the mailing list ?
[11:51] <caribou> apw: yes, 
[11:52] <caribou> but for some reason, I didn't receive my email, I suspect that something went wrong
[11:52] <caribou> though I switched off the Digest Mode just before sending the mail
[11:53] <apw> caribou, its sitting waiting on moderation which implies you used a different addy to the one you subscribed with
[11:53] <caribou> apw: lemme check
[11:54] <apw> hopefully i just stroked them through
[11:56] <caribou> apw: email address is correct. Could it be caused by the Digest mode ?
[11:56] <apw> no don't think so
[11:58] <caribou> apw: ok, figured it out, it left my laptop with my username (caribou@canonical.com), not my real email address.
[11:58] <caribou> ssmtp blunder
[12:01] <caribou> default setup doesn't allow overriding the From: field
[12:08] <apw> caribou, ok that makes sense then, and the emails have come through now i've approved them
[12:08] <caribou> apw: I just fixed my ssmtp setup & tested again. Shouldn't happen again
[12:09] <henrix> smb: i didn't had a chance to try your autogroup patch yet
[12:09] <henrix> smb: i'll try to do it later today, or during the weekend
[12:09] <smb> henrix, Actually there seems that cwillu found some other version somewhere
[12:10] <smb> not sure he also fwd to you, a sec
[12:10] <henrix> i don't think so. can you forward it to me?
[12:10] <smb> henrix, done
[12:10] <henrix> smb: thanks
[12:12] <henrix> smb: ah, it makes sense. i'll give it a try later
[12:13] <smb> henrix, ok cool. I just had no time really to find out exactly where that is upstreaming wise
[12:14] <henrix> smb: i found it in lkml, no replies yet. i'll test it and provide some feedback
[12:14] <smb> henrix, ah ok
[12:14] <rtg> apw, whats the story with linux-signed 3.5.0-18.29  FTBS ? Are you on top of that ?
[12:14] <henrix> rtg: it failed due to dependencies, i believe. i should have waited a little bit more before uploading it.
[12:15] <henrix> rtg: i'll retry it later
[12:15] <henrix> rtg: (however, i haven't checked the logs yet)
[12:15] <rtg> henrix, shouldn't it have gone into DEPWAIT ? or is that just PPAs ?
[12:16] <henrix> rtg: ppa i believe. the main pkg is still building
[12:22] <tjaalton> i'm trying to bisect something, and building 3.1 would be the first step (to see if the fix is in 3.1 or 3.2), but checking out for instance 92f8343feec from the precise tree shows that the diff to v3.2 is suspiciously small, compared to v3.1..v3.2
[12:22] <tjaalton> how can I verify that it really is based on v3.1?
[12:26] <einonm> tjaalton: clone Linus' Linux repo and perform a diff of the relevant tags?
[12:28] <tjaalton> einonm: that's what I'm doing
[12:28] <tjaalton> v3.x are from there
[12:29] <einonm> you mentioned that you were using the precise tree, I'm talking about Linus' tree taken from kernel.org. 
[12:29] <tjaalton> I have the remote added
[12:31] <apw> tjaalton, normally i use git log then look for '    Linux '
[12:31] <apw> to find out what the next closing commit from linus was
[12:32] <tjaalton> Linux 3.2.14
[12:32] <tjaalton> great :)
[12:32] <apw> apw@dm:~/git2/ubuntu-precise$ git describe 92f8343feec
[12:32] <apw> v3.2.14-236-g92f8343
[12:32] <einonm> ah, I see - you can check out using a tag instead of a ref
[12:32] <apw> sometimes that will tell you what you want
[12:32] <apw> except when it says 'Ubuntu-' something
[12:33] <einonm> what about 'git checkout v3.1'?
[12:33] <tjaalton> einonm: I need the packaging too, though I could do a selective merge there
[12:34] <apw> Ubuntu-3.1.0-2.3
[12:34] <apw> tjaalton, that looks to be the last 3.1 based kernel
[12:34] <tjaalton> apw: yes
[12:35] <tjaalton> so I assumed that by branching from that I'd get 3.1 + packaging, but no :)
[12:36] <apw> well it appears to have been uploaded, so i would expect that too
[12:36] <apw> tjaalton, you would need to checkout the TAG and not the commit which _now_ has UBUNTU: Ubuntu-3.1.0-2.3 on it
[12:36] <apw> tjaalton, as the closing commit has since been rebased
[12:37] <tjaalton> hmm ok
[12:37] <apw> we rebase until release
[12:37] <tjaalton> yeah this looks a lot better, thanks :)
[12:38] <apw> tjaalton, though if it was built in the archive, the librarian has the binaries anyhow, so you could just test those
[12:39] <tjaalton> apw: I need to add one commit on top of it anyway
[12:53] <ppisati> brb
[12:56] <rtg> caribou, is caribou@canonical.com bogus ? I got a bounce
[12:57] <caribou> rtg: yes, wrong ssmtp setup when I sent to the list
[12:57] <caribou> rtg: got that fixed. apw had to force the email through
[12:57] <rtg> caribou, ok, then read my response to the list.
[12:57] <caribou> rtg: but I just got your reply to the list
[13:46] <apw> doko, hey, do actually have a compelling reason to take 3.6 headers over 3.5 at this point
[14:02] <apw> doko, i ask as the changes are pretty small, and we are slightly worried about the untested nature of the kernel itself
[14:04] <doko> apw, I thought you did want to start with 3.7?  the reason for the new headers is to catch ftbfs early.
[14:04] <doko> the untested nature of the kernel would be one more reason to build the headers from a separate source ;)
[14:05] <apw> doko, we're in a hole with headers from 3.7, they have changed the kernel side of them and we are still sorting the fallout; so the latest we could do is 3.6
[14:05] <apw> doko, though in that case we'd have headers advertising features the kernel didn't have, i suspect that'd also not go well !
[14:06] <apw> doko, i am working on 3.7 header issues now, but i'm not sure there is value in waiting for us
[14:06] <rtg> doko, I think we should stick with 3.5 until we've got some mileage on 3.7. its still kind of a steaming pile.
[14:06] <doko> ok
[14:45] <cking> doko, which version of gcc will be using for 13.04?
[15:13] <cking> doko, did you get any time to look at my email concerning gcc 4.7.x and kernel GCOV issues?
[15:37] <BlackNarcissus> Hello all. I ran into a serious bug during 12.10 install, and someone on ubuntu-bugs told me to report it under linux and to check with you guys. When installing on a laptop with nvidia integrated graphics, the system is not properly cooled, temperature goes above safety limits and shuts down, thus interrupting the install.
[15:37] <BlackNarcissus> It's  Bug #1068626
[15:37] <ubot2> Launchpad bug 1068626 in linux "System Overheats and Shuts Down during Install" [High,Incomplete] https://launchpad.net/bugs/1068626
[16:01] <doko> cking, 4.7.x, sorry, not yet. could you check with gcc-4.7 from debian unstable too?
[16:04] <cking> doko, ok, I will do that on monday
[17:06]  * ppisati -> EOW
[17:12]  * cking too EOW
[17:31] <henrix> almost beer o'clock here so...
[17:32]  * henrix -> EOD
[17:32] <bizhanMona> Hi, I have a new Ivy bridge mother board running Ubuntu 12.10. I am trying to identify a source of hardware interrupt for 0.1 msec periodicity. Any idea ?thx
[17:44]  * smb -> FEOW
[18:01] <rtg> jsalisbury, when you Cc stable, put it in the commit log, e.g., "Cc: stable@vger.kernel.org". that way you won't get hate mail from the gkh bot.
[18:05] <jsalisbury> rtg, yeah, I realize that now :-)
[18:06]  * jsalisbury tries round two
[18:07] <rtg> jsalisbury, don't forget '[PATCH v2]' in the subject.
[18:08] <jsalisbury> rtg, ack
[18:08] <jsalisbury> rtg, and no cover letter 
[18:18] <jsalisbury> rtg, do I also Cc the maintainers in the commit log, or just on the email to lkml?
[18:21] <rtg> jsalisbury, I generally use get_maintainers.pl and Cc everyone (and everything) on the list except LKML. I generally direct the email to LKML
[18:22] <jsalisbury> rtg, thanks.  
[18:22]  * rtg -> lunch
[18:23] <Ergo^> hello, i want to use 3.6 kernel on ubuntu 12.10 - but the docs say that mainline kernels are missing ubuntu patches in them, is there a place where i can get a prerelase kernel with all the patches ?
[18:24] <Ergo^> or should i just grab the "current" one ?
[19:51]  * ogasawara lunch
[19:54]  * rtg -> EOW