=== rsalveti` is now known as rsalveti
=== smb` is now known as smb
[07:34]  * smb -> BOD
[07:54] <dileks> hmm, this colord again crashing #934308
[07:58] <RAOF> Urgh, libdbus again.
[08:00] <dileks> that bugs seems not to exist?
[08:00] <dileks> https://bugs.launchpad.net/bugs/934308
[08:00] <ubot2> dileks: Error: <Bugtracker.plugin.Launchpad instance at 0xa2d980c> bug 934308 not found
[08:01] <dileks> hehe. that bug-# was displayed in that crash-report whatever app
[08:04] <RAOF> It's a private bug which is why the bugbot can't scrape it.
[08:05] <dileks> whats a "private bug"?
[08:05] <dileks> a # generated by the crash-reporter-app?
[08:07] <RAOF> A private bug is one marked as private; all apport-reported bugs start as private, because they contain coredumps that may contain sensitive data.
[08:08] <dileks> OK
[08:10] <dileks> looks like ...
[08:11] <dileks> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=dc332fdf9f373a87b1e2f423b5b004b2a3c37e1a
[08:11] <dileks> ... fixing 3.5-rc6 ...
[08:11] <dileks> http://paste.ubuntu.com/1089450/
[08:11] <dileks> happened after suspend+resume*
=== henrix_ is now known as henrix
[08:32] <caribou> smb: morning
[08:32] <smb> caribou, about right... :-P
[08:33]  * smb is still tired
[08:33] <caribou> smb: can I ask you a quick question about the bisecting of the kexec issue ?
[08:33] <smb> caribou, dunno, you may try... :) yes.
[08:33] <caribou> smb: though I don't plan to do it myself, but I'd like to learn how to do it
[08:33] <caribou> smb: this would be too long to build the kernels on my laptop
[08:34] <caribou> smb: but here is the question
[08:34] <smb> caribou, No I don't do that either
[08:34] <caribou> smb: since we identify that it's between v3.4 and v3.5-rc1, I wanted to learn the commands to bisect
[08:34] <caribou> smb: so I got the Quantal git clone, then did :
[08:35] <caribou> smb: git bisect start v3.5-rc1 v3.4
[08:35] <smb> caribou, Ok, so basically I take an upstream kernel tree (our trees, especially development trees are not that good since they are rebased)
[08:36] <caribou> smb: well I followed https://wiki.ubuntu.com/Kernel/KernelBisection
[08:36] <caribou> smb: so I picked git://kernel.ubuntu.com/ubuntu/ubuntu-quantal.git
[08:36] <caribou> smb: then which one should I take ?
[08:37] <smb> caribou, ...slow down... its morning
[08:37] <caribou> smb: hehe, sorry I was up early today :)
[08:38] <smb> Not sure what the wiki say, so I need to look...
[08:38] <caribou> smb: I just see something weird in my git environment : after the git bisect start, I am no longer in a branch
[08:38] <smb> caribou, no that is correct, you are somewhere in the middle of things
[08:39] <caribou> smb: I think there is a step needed after the git bisect to get the bisected code back into my branch
[08:39] <smb> no
[08:39] <smb> Can we go back to tree selection? 
[08:40] <caribou> smb: sure
[08:40] <apw> if you need a branch name on the bisect commit to get it built (for example to use a remote machine to build it) then i just do a 'git branch buildtmp' which makes a branch pointing to 'here'
[08:40] <smb> So after we release you could use our tree for bisection as it is not rebased anymore (the master branch), but more often we need to bisect something in mainline
[08:41] <smb> Then as I said you take the upstream tree, "cp -a <ourtree>/debian/* ." and be sure debian.master/config/enforce(r?) is empty
[08:42] <smb> PRobably git bisect start good bad works too, though I like to be single stepped as I am single minded... :-P
[08:42] <smb> So git bisect start
[08:42] <smb> git bisect good <version>
[08:42] <smb> git bisect bad <version>
[08:43] <smb> This throws your tree roughly into the middle of good and bad
[08:43] <smb> I usually edit the debian.master/changelog to have some indicator (version numbering) of which kernel build this is
[08:43] <caribou> smb: yes, this mostly what is described in the Wiki
[08:44] <smb> and then you run the build (usually skipabi=true skipmodule=true fakeroot debian/rules binary-generic)
[08:44] <caribou> smb: what puzzles me is that, after the bisect good/bad, I'm no longer in a branch and don't have the debian.master directory etc
[08:44] <smb> This normally asks some config questions, I try to just hit enter and use default version
[08:45] <smb> caribou, You will have one 
[08:45] <caribou> and 'git branch' tells me "*(no branch)"
[08:45] <smb> if you had before
[08:45] <smb> but you clearly are *not* on any branch anymore
[08:45] <smb> Of course
[08:45] <apw> caribou, that is normal mid-bisect, as it is mid-rebase
[08:46] <apw> you are on a 'diconnected HEAD'
[08:46] <caribou> apw: yes, I got that far.
[08:47] <caribou> apw: so is there anything else to be done at that point to get from the mid-bisect disconnected HEAD to some branch in order to build
[08:47] <caribou> ?
[08:47] <smb> caribou, No, it means you are at a point between version but still this is what you want to build
[08:48] <smb> caribou, And if you do the bisect on an upstream tree and copy the debian files in, those remain untouched by you moving forward through the bisect
[08:48] <smb> (since for the upstream tree those are not part of the repo)
[08:49] <apw> so you can use the term HEAD to refer to there, and as i said before to get a name attached to here you can just "git branch NAME" which will attach that name to wherever HEAD is
[08:49] <caribou> smb: yes, that's clear to me. 
[08:50] <caribou> apw: ok, that was the missing bit I was after !
[08:51] <smb> caribou, But that you actually don't need
[08:52] <smb> After you proceed through bisection, you will end up at a point where git tells you this commit (sha1) is what should be the offending one
[08:52] <cking> if you've done it right ;-)
[08:52] <smb> you can use that sha1 to look at the commit (or do whatever else is appropriate)
[08:53] <smb> cking, Yeah... minor thing... :)
[08:53] <caribou> smb: yes I figured that part out. I was only puzzled by the "disconnected HEAD" situation
[08:53] <smb> ok
[08:53] <cking> juist don't interrupted and make a mistake is my advice ;-)
[08:53] <apw> and i recommend you keep a copy of 'git bisect log' every now and again as that can be used to get you back to where you are when you break your tree
[08:54] <apw> or lose track or say good when you meant bad, or similar
[08:54] <smb> right
[08:54] <caribou> smb: when I use one of our trees to test, after the "git bisect start", I was in a disconnected HEAD and the debian.master bits were no longer there
[08:54] <smb> and sometimes one also needs a "git bisect skip" to say neither good nor bad, it just failed to build
[08:54] <apw> yep as our debian bits are near the tip of the tree at all times
[08:55] <apw> so any bisect which drops you way down into mainline commits won't have them
[08:55] <smb> caribou, Ah, ok. That is true as long as start is before a final release
[08:55] <caribou> ok thank very much guys. this is all very useful information to me
[08:56] <caribou> smb: which is the case with the Quantal tree
[08:56] <caribou> smb: I should test with a stable tree
[08:56] <smb> caribou, Quantal is not release, so yes
[08:56] <caribou> ok, thanks for your time guys !
[09:07] <_ruben> got a hardy box on which i need to mount a ext4 disk, guessing the easiest way to make that possible is by using a mainline kernel? any recommendations for a specific version(range)?
[09:18] <apw> _ruben, blimey.  i think if it was me, i would try a lucid kernel
[09:18] <apw> though that combination likley has not been tested
[09:19] <smb> though between hardy and lucid I think there was some incompatibility with lvm userspsace
[09:19] <smb> (iirc because /sys/block became links)
[09:19] <_ruben> sounds scary, tho i might've found a different solution by means of virtualization
[09:20] <apw> that sounds safer indeed
=== ricotz_ is now known as ricotz
[11:04] <cking> apw, ping
=== anubhav_ is now known as anubhav
=== yofel_ is now known as yofel
=== rsalveti` is now known as rsalveti
[14:18] <psusi> is there not a -dbg build of the kernel so you can get gdb some debug symbols?
[14:26]  * ogasawara back in 20
[14:49] <herton> psusi, you can get dbgsym packages directly from http://ddebs.ubuntu.com/pool/main/l/linux/, there is also a general guide on the wiki about dbg packages: https://wiki.ubuntu.com/DebuggingProgramCrash/#Debug_Symbol_Packages
[14:52] <psusi> herton: thanks... hrm... it seems that gdb needs me to specify the base address to add-symbol-file.. how can I figure that out?
[14:52]  * jsalisbury back after another x201 overheat crash :-/
[14:53]  * ppisati -> goes packing stuff
[14:53] <psusi> aha!  there we go... just use file instead of add-symbol-file...
[14:59]  * cking reboots
[15:01] <jsalisbury> pgraner, just wondering if you had a chance to test the v3 kernel for bug 1018020 ?
[15:01] <ubot2> Launchpad bug 1018020 in linux "Logitech webcam not working" [High,In progress] https://launchpad.net/bugs/1018020
[15:06] <pgraner> jsalisbury, not yet, give me 5 and I'll let you know
[15:06] <jsalisbury> pgraner, great, thanks.
[15:14] <pgraner> jsalisbury, ok looks good with a quick 3 min camera run
[15:15] <jsalisbury> pgraner, cool.  And you didn't notice any delay at the login screen, when trying to enter your password?
[15:15] <pgraner> jsalisbury, not really, let me try on my other box for sanity
[15:44] <pgraner> jsalisbury, no noticeable speed issues on my i7 or i5 box
[15:44] <jsalisbury> pgraner, great news!  Thanks for testing.
[15:45] <jsalisbury> ogasawara, ^^^ I've had good feedback from a couple of people that the single patch(2/2) fixes bug 1018020
[15:45] <ubot2> Launchpad bug 1018020 in linux "Logitech webcam not working" [High,In progress] https://launchpad.net/bugs/1018020
[15:46] <jsalisbury> ogasawara, want me to repost to the list with just the single patch?
[15:46] <ogasawara> jsalisbury: cool thanks.  I think tim applied both so I'll just drop patch 1/2.  no need to reply to the list, I'll just send a note out that I've dropped it.
[15:46] <jsalisbury> ogasawara, cool, thanks
[15:47] <jsalisbury> ogasawara, this patch should land in mainline soon too
[15:47] <ogasawara> jsalisbury: ah, nice.
[15:47] <jsalisbury> ogasawara, Takashi applied it to his tree, so whenever Linus pulls that it should land
[15:48] <skaet> ogasawara,  there are alot of bugs sticking around in fix committed state on http://reports.qa.ubuntu.com/reports/rls-mgr/rls-q-tracking-bug-tasks.html for multiple weeks,   is there possibly a janitor processing glitch,  or its just waiting for a specific drop to land?
[15:49] <ogasawara> skaet: I'll have to take a look, might just be waiting for something to move out of -proposed
[15:49] <skaet> thanks ogasawara 
[15:51] <ogasawara> skaet: ah, those are for CVE's.  likely never auto-closed by our bot for Quantal.  I'll go through and clean them out.
[15:51] <skaet> thanks ogasawara   :D
[15:59] <ogasawara> skaet: is there a reason there is a separate "linux" section in that report?
[16:01] <skaet> ogasawara,  report is oriented around teams,  and packages in the team's responsibliity areas.
[16:04] <ogasawara> skaet: I'm still a bit confused then as that would indicate that section should contain then all the bugs against the "linux" package, but really it's all the linux-armadaxp bugs
[16:05] <ogasawara> skaet: and I'm not sure why linux-armadaxp is then special to have it's own section when we group all the other kernel related packaged, eg linux, linux-ti-omap4 under the "kernel" section.
[16:07] <skaet> ogasawara, yeah,  I agree what's emerged has become confusing.... time for some cleanup.   I'm guessing its because of vanhoof's team involvement in the armadaxp board.   I'm fine with it all being lumped under kernel.
[16:08] <skaet> if that makes it clearer
[16:11] <ogasawara> skaet: that's fine, at least I'll be sure to see it then
[16:12]  * skaet adds it to the TODO list ;)
[17:51]  * henrix -> EOD
[19:41] <mdz> what is the difference between linux-image and linux-image-extra? the package descriptions look identical
[19:45] <ogasawara> hiya mdz, with quantal we eliminated the need for having a separate virtual flavor by splitting the kernel package into a paired down linux-image package and linux-image-extra to contain everything else not included in linux-image.  ie install linux-image for a paired down offering, install linux-image + linux-image-extra for a complete offering.
[19:46]  * ogasawara has to run, back in a bit
[19:47] <mdz> ogasawara, thanks. maybe the package description could be updated to clarify this?
[19:47] <mdz> maybe mention the categories of modules which are in linux-image vs. -extra
[19:48] <mdz> -extra looks like it has many (but not all) network, sound, input, media, etc.
[19:52] <mdz> about half the modules my system uses are in -extra, interesting
[21:14] <jjohansen> herton: you around?
[21:14] <herton> jjohansen, yep
[21:16] <jjohansen> herton: For the hardy bug that I had you change the attribution on (3d3e740d89b3267ceb0ef19fd741aeb0b75c1f47) the commit text still needs to be modified.
[21:16] <jjohansen> It still has "John Johansen reported"
[21:19] <herton> jjohansen, hmm... yeah. reported by is correct though. But the patch I resent to the mailing list was right, I guess someone when applied modified by hand the first patch. I think it can go this way now... anyway, you two were involved I guess
[21:20] <jjohansen> herton: yeah the patch is right, and reported-by is right, just want to make sure that all the credit goes where its due, as I wouldn't want to upset an active contributor
[21:22] <herton> jjohansen, it will cause some hassle to fix this now, since went to master and the update is ready. And since the reported by is correct, I don't think it's too bad
[21:25] <herton> jjohansen, I guess the better action would be to apologize to him through mail, since it wasn't intentional, just to avoid any misjudgments
[21:25] <herton> jjohansen, I can write up one if you want
[21:26] <jjohansen> herton: no I can write one up if we go that route
[21:27] <herton> bjf ^, what do you think?
[21:31] <jjohansen> herton: okay, I think we will go that route with this one
[23:04] <bjf> herton, jjohansen, email is the way to go, worst case we will revert the patch and reapply a different one with the correct attribution
[23:04] <bjf> herton, jjohansen, but that seems kind of extreme
[23:17] <jjohansen> bjf: yeah email has already been sent
[23:17] <bjf> jjohansen: thanks, really sorry about that
[23:18] <jjohansen> bjf: heh it happens I should have caught it sooner
[23:18] <bjf> jjohansen, are you planning on sprinting with us at all?
[23:19] <jjohansen> bjf: yep, a couple days. is looking like Wed, Thursday for me atm
[23:19] <bjf> jjohansen: cool