[07:04] <ppisati> moin
[08:16] <smb> again... :-P
[08:50] <smb> apw, one way fail
[08:50] <smb> apw, meaning we hear you but not other way round :)
[08:54] <apw> smb, situation normal, thank you pulse
[08:54] <smb> As normal as any situation involving PA can be
[09:18] <caribou> smb: morning
[09:18] <caribou> smb: have you tried to use crash 6.1.0 on a Raring kernel ?
[09:19] <caribou> smb: I get "(no debugging symbols found)" on the 3.8.0.2 ddebs
[09:19] <smb> caribou, morning. maybe not. I honestly cannot remember...
[09:19] <caribou> smb: ok, just wanted to check; I'll investigate
[09:20] <smb> Though potentially I did with 3.7 based kernels. 
[09:20] <smb> caribou, I would try to see how the last 3.7 we had works
[09:22] <caribou> smb: well, the ddebs are not available for 3.7 kernels in the archive
[09:23] <smb> caribou, Doh! Seems we would rely on whatever copy you or arges have. Since we cannot keep ours from vanishing.
[09:23] <caribou> smb: I'll check what I have
[09:23] <smb> Or re-build a kernel from git based on a tag
[09:25] <diwic> If we have bugs in 12.04 that are fixed by using the -lts-quantal kernel, would it be appropriate just to advice people to move to that kernel or should one spend time trying to backport fixes to 3.2?
[09:30] <infinity> diwic: Depends on the bug.
[09:31] <infinity> diwic: If it's flat-out hardware enablement, asking them to switch to our HWE stack is reasonable.  If it's rather something broken in 3.2, finding the commit that fixes it and pulling it into 3.2 is the right thing, IMO.
[09:32] <infinity> diwic: Keep in mind, also, that we don't have lts-backport on !x86.  So, if it's a bug that's not specific to some x86 hardware, not fixing it in 3.2 doesn't help, say, ARM users.
[09:32] <infinity> That was a lot of negatives.
[09:33] <diwic> infinity, hmm, ok
[09:33] <caribou> smb: ok, I found the ddebs, I just no longer have the original 3.7 kernel package
[09:34] <smb> caribou, Those should be on LP
[09:34] <caribou> smb: I have the 3.7.0.4 ddeb
[09:35] <caribou> smb: ok, got it
[09:35] <smb> caribou, https://launchpad.net/ubuntu/raring/+source/linux/3.7.0-7.15
[09:45] <caribou> smb: ok, got everything I need, I'll let you know what I find
[09:46] <smb> caribou, cool. thanks
[10:13] <apw> ogra_, about ?  i have a kernel i'd like you to test if you have a chance
[10:23] <ogra_> now i am (i got a sick cat and need to spend 1-2h at the vet every day this week)
[10:23] <ogra_> apw, ^^
[10:24] <apw> ogra_, what fun
[10:24] <ogra_> yeah
[10:29] <janimo> apw, ogra_  said he'll land the userspace the orientation changes as soon as the kernel input side is changed for the nexus
[10:29] <apw> ogra_, ok ... so ...
[10:29] <janimo> I am fine with either chicken or egg first though, but users will need to be fully upgraded to have it working
[10:31] <apw> ogra_, ok ... once you have tested that one, i'll spin you another with janimos orientation change
[10:31] <apw> ogra_, so you can test your orientation fixes :)
[10:31] <apw> and when you are happy we can upload together
[10:31] <ogra_> given that the arm livefs builder is dead since days, i dont think we need to worry to much about ahlf a day delay between the uploads
[10:31] <ogra_> ok
[10:33] <ogra_> apw, perfect !
[10:33] <ogra_> i wonder why i still saw the wifi messages in my build
[10:33] <apw> ogra_, ok good.  i'll get your new one built in a minute
[10:33] <ogra_> totally silent with yours
[10:33] <ogra_> janimo, do you have the acceld changes handy ?
[10:34] <janimo> ogra_, yes, I'll paste them again, a moment
[10:34] <apw> ogra_, and note that the login screen doesn't have rotate
[10:34] <janimo> ogra_, http://paste.ubuntu.com/1585333/
[10:35] <apw> og
[10:35] <apw> ogra_, that fixes things once you are logged in, but at the password prompt ?
[10:35] <ogra_> apw, it will, as soon as i dropped the forced rotate from xorg.conf ;)
[10:35] <janimo> I think we have an xrotate call somewhere there, which needs to be dropped
[10:35] <apw> heh great
[10:37] <ogra_> janimo, line 6 is wrong :P
[10:38] <janimo> which is line 6? I think I only shuffled the matrix orders
[10:38] <janimo> ah, DIR='right'
[10:38] <janimo> is that the default orientation? Indeed that right is wrong
[10:39] <ogra_> right 
[10:39] <ogra_> *grin*
[10:39] <janimo> that's why first tilt did not work I guess :)
[10:39] <ogra_> doesnt od any harm, but you need to rotate once to actually activate the rotation if thats wrong
[10:40] <ogra_> right, its one more tilt you need... i had the same issue in my foirst upload
[10:54] <ogra_> grrr
[10:54] <ogra_> i cant get the xorg.conf right :/
[11:32] <apw> ogra_, seemed to work for me
[11:32] <ogra_> great, uploaded the changes
[14:45] <ppisati> has it ever happened to you that, during a bisect with, with  commit X being good, and commit X +  Y being bad
[14:46] <ppisati> git bisect goes _behind_ commit X instead of picking one in between X and X+Y?
[14:55] <einonm> ppisati:  could be due to branching between X & Y?
[14:56] <rtg> ppisati, yeah, make sure its a linear range
[15:16] <apw> ogra_, ok all of those changes are in the -release pocket now
[15:18] <ogra_> yay
[15:39]  * ogasawara back in 20
[15:39] <tseliot> apw: what's the source package for linux-image-3.1.10-9-nexus7 ?
[15:40] <apw> linux-nexus7
[15:40] <apw> tseliot, ^^
[15:40] <tseliot> apw: ok, thanks
[15:40] <apw> tseliot, need something ?
[15:42] <tseliot> apw: no, I just needed to know the name as I'm adding kernel names in my test suite for ubuntu-drivers-common so that I can tests for problems with my code and these name schemes
[15:46] <ogra_> tseliot, there is also linux-ac100 (tegra2)
[15:47] <tseliot> apw, ogra_: ok and do you know if linux-ti-omap4 has linux-headers-ti-omap4 etc.? (With this name scheme)?
[15:48] <ogra_> it should, yes
[15:48] <apw> it should be linux-headers-omap4
[15:48] <apw> and linux-image-omap4
[15:48] <ogra_> oh, right, the -ti is only in the source 
[15:48] <apw> ti-omap4 is the source package name
[15:48] <apw> -omap4 is the flavour name
[15:49] <tseliot> ok, thanks
[16:18] <smb> arges, Out of interest, is the xen package again flagged broken in raring +1? Right now it won't compile in my sbuild chroots (even the version you uploaded). And as a second thing, can I prevent others from fixing it while I look? ;)
[16:39] <jsalisbury> ##
[16:39] <jsalisbury> ## Kernel team meeting today @ 17:00 UTC
[16:39] <jsalisbury> ##
[16:59] <zequence> apw: Am I expected to set the bug reports for regression-testing and/or Verification-testing to "fix released"?
[17:02] <arges> rtg: was the bug you were seeing, you could suspend with pm-suspend, but there was no way to do it via the menu, or Fn-F7 (on mythinkpad)
[17:02] <apw> infinity, i forget already what lowlatency testing was ... can you remind
[17:02] <apw> ie when we do the regression testing what we are meant to set to what
[17:03] <rtg> arges, I was just closing the lid. haven't really explored much further, but am uploading a bug report
[17:03] <arges> rtg: ok. i might be hitting the same thing
[17:04] <infinity> apw: If no lowlatency-specific bugs, mark verification-testing Fix Released if the parent kernel is done.
[17:04] <infinity> apw: If specific bugs, verify, then do above.
[17:05] <infinity> apw: For smoke testing, mark regressing-testing Fix Released, and tag the bug "qa-testing-passed" to appease the bot.
[17:05] <apw> zequence, ^^ :)
[17:06] <infinity> arges: If pm-suspend works, but various buttons and UI triggers don't, gnome-settings-daemon is probably wedged.
[17:06] <arges> hmm
[17:06] <zequence> apw: Thanks. I'll ask infinity some more, if I didn't get it yet :)
[17:06] <apw> zequence, so this has no specific patches for lowlatency it is a pure rebase
[17:07] <apw> zequence, so that means vefication-testing is not needed, so it can go Fix Released for no actions
[17:07] <rtg> infinity, pm-suspends works even after upowerd augers in
[17:07] <zequence> apw: Ok. Good
[17:07] <zequence> apw: But, I still add the tag?
[17:08] <zequence> Do I add it in a comment?
[17:08] <infinity> rtg: pm-suspend should always work, barring kernel bugs or massive userspace sadness.
[17:08] <infinity> rtg: But most of the higher level plumbing for this relies on gnome-settings-daemon being alive and willing to talk pleasantly to you.
[17:08] <rtg> infinity, right, 'cause I think about all it does these days is blat something into sysfs
[17:08] <infinity> rtg: Which doesn't sound like your sort of date.
[17:09] <apw> zequence, the otehr testing one once they are boot tested, mark regression-testing fix-released and add a tag in the tags field at the top as above
[17:12] <zequence> apw: So, this should be right then
[17:12] <zequence> https://bugs.launchpad.net/kernel-sru-workflow/regression-testing/+bug/1105146
[17:12] <ubot2> Ubuntu bug 1105146 in Kernel SRU Workflow verification-testing "linux-lowlatency: 3.5.0-23.22 -proposed tracker" [Undecided,In progress]
[17:12] <apw> zequence, well verification-testing is done as there is none,
[17:13]  * herton -> back in 1.5h
[17:13] <caribou> smb: FYI, the debug symbols were fine in he 3.7 kernel in Raring
[17:14] <smb> caribou, Ok. Thanks. Sounds like yet another thing moved around
[17:22] <apw> rtg, could you add me and cjw to the bug please, so we can see it
[17:22] <rtg> apw, ack
[17:23] <rtg> apw, done
[17:34] <jsalisbury> rtg, is there a public bug?  Just wondering in case we get a bunch of duplicate reports.  Else, I can see if I can reproduce it and create a public report.
[17:34] <rtg> jsalisbury, it'll be public as soon as the apport retracer runs
[17:34] <jsalisbury> rtg, ack
[17:36]  * ppisati goes out to find some food, before the food finds me
[18:00] <smb> apw, arges, So the xen build fail was actually two parts. One (for which I found reference on xen-devel) is that the check for needing librt was using clock_gettime but that is not requiring it anymore. The other (for which I could not yet be bothered to search) is some part using ulong wihtout including sys/types.h (which probably something else used to do).
[18:01] <smb> arges, I will include that in the stuff I am working on, so you won't have to worry about that ftbs :)
[18:01] <arges> smb: ok great! let me know if there is anything i can do to help
[18:02] <smb> arges, Just the usual grinding work for youknowwhat issues for the youknowho team... ;-P
[18:02] <arges> : )
[18:02]  * rtg -> lunch
[18:21] <apw> rtg, bjf, there will be a new upowerd in the archive 'immently' which should fix things up
[18:21] <bjf> apw, ack, i see there have been quite a few bugs filed against it
[18:45] <apw> bjf, well it at least fixes my 32bit systems
[18:47]  * smb -> donefortheday
[18:48] <apw> smb, done in by the day
[18:48] <smb> apw, Or so I guess :)
[19:41] <zequence> Ah, I can be really slow sometimes
[19:41] <zequence> Anyway, I think I got the bug handling for next time
[20:05] <apw> rtg, you pushed just before me dammit, but you forgot the acks for the second one
[20:05] <rtg> hmm, I thought I got both.
[20:06] <apw> rtg, and both are missing the bug numbers
[20:06] <rtg> apw, drat. why don't you push yours then since I'm clearly incompetent right now :)
[20:07] <rtg> I didn't tag yet
[20:07] <apw> :) ack
[20:07] <apw> rtg, yeah i'll wrapit and upload it
[20:07] <rtg> apw, ok
[20:07] <rtg> apw, I'm about done for the day anyways
[20:08] <apw> rtg np
[20:09]  * rtg is outta here. back on Feb 5.
[20:34] <infinity> smb: If the only reason it links librt is for clock_gettime, it doesn't need librt.
[20:34] <infinity> smb: (Though, --as-needed linking will sort that out anyway)
[21:24] <arges> computer suspends properly again! thanks
[22:54] <infinity> jjohansen: You have a few pending security-signoff tasks for the current SRU round still, FYI.
[22:55] <jjohansen> infinity: yep thanks for the poke, I'll get them done
[22:56] <infinity> jjohansen: All good.  I'm sure you'll get them done before cert finishes. :)