[08:29] <ppisati> ah
[08:29] <ppisati> it just crashed
[08:29] <smb> yeah more fun
[08:41]  * apw idly wonders what has happened to his history load for this channel, either that or you guys have said the same things 3 days in a row
[08:42] <smb> Hm, I am not sure I normally look back 3 days to notice
[08:43] <smb> apw, but my scrollback here does not seem to repeat
[08:46] <apw> smb, heh no it is deffo a local issue, not saving scrollback or something
[08:46] <apw> or bip has lost its mind, or something
[08:46] <smb> always "or something"
[08:47] <apw> biund to be indee
[08:50]  * apw tries hands for type, yes much better than toes
[08:56]  * henrix reboots
[10:05] <henrix> brb
[11:35] <hrw> hi
[11:36] <hrw> does launchpad keeps all previous builds?
[11:40] <zequence> apw: There's a bug in linux lowlatency headers. Bug #1165259. I think maybe Q and R are affected both. Had a look at debian/rules.d/2-binary-arch.mk, line 238 (Raring). But, unsure how to fix it from there.
[11:40] <ubot2> Launchpad bug 1165259 in linux-lowlatency (Ubuntu) "13.04 Beta1 -- symlink missing for Linux Headers /usr/src" [Undecided,Confirmed] https://launchpad.net/bugs/1165259
[11:41] <zequence> The symlinks become pointed towards linux-headers-<version>. 
[11:42] <zequence> I wonder if the -lowlatency and -generic headers are the same.
[11:42] <apw> zequence, i'll look into it, they should be similarly broken i expect
[11:44] <hrw> when I boot 3.8.0-7.15 I get low res FB and no usb. ideas?
[11:45] <hrw> it worked month ago and had working usb3 (which -13+ do not have)
[11:52] <apw> zequence, ok i think i can see how this happens, and am fixing
[11:52] <apw> ogasawara, did i hear you intended another upload 'soon' ie before tommorrow ?  if so i may have something i want in it
[12:03] <zequence> apw: thanks
[12:44] <ogasawara> apw: indeed, I was thinking of an upload today before kernel freeze tomorrow
[12:44] <ogasawara> apw: feel free to drop anything on master-next that you'd like to see in
[12:45] <apw> ogasawara, in progress now, making sure it doesn't break master
[12:47] <rtg_> apw, just pushed some haswell audio patches
[12:54] <rtg_> ogasawara, why are we in a yank to upload today ? nothing in master-next appears all _that_ important.
[12:54] <ogasawara> rtg_: kernel freeze is tomorrow
[12:55] <rtg_> yeah,so what? we just upload tomorrow ?
[12:55] <rtg_> doesn't freeze take effect EOD ?
[12:55] <ogasawara> rtg_: usually 2200 UTC
[12:56] <ogasawara> rtg_: so we could upload tomorrow
[12:56] <rtg_> translate that for me
[12:56] <rtg_> thats like 4P my time
[12:57] <ogasawara> rtg_: I always assumed that meant we had to have the builds done and the package out of -proposed by that deadline
[12:57] <ogasawara> rtg_: so I always err'd on the safe side and gave us a day cushion
[12:57] <rtg_> dunno. we're special though, so we can pretty much interpret as we please :)
[12:58] <ogasawara> rtg_: indeed.  if we want to upload tomorrow I've no big problem with that either.
[12:59] <rtg_> ogasawara, you just _know_ someone will come crying at the last possible hour, so waiting a bit shouldn't hurt.
[13:01] <ogasawara> rtg_: ack
[13:26] <rtg_> apw, re: bug #1073499. it appears that there are a boatload of USB options to enable. How do we reconcile them against our mainline kernel config set ?
[13:26] <ubot2> Launchpad bug 1073499 in linux-nexus7 (Ubuntu) "please consider turning on all possible modules for external USB devices" [Undecided,In progress] https://launchpad.net/bugs/1073499
[13:44] <arges> slangasek: hello. Are you still hitting bug 1157678 ? I can reproduce now using an xrandr command, and was going to file a new upstream bug.
[13:44] <ubot2> Launchpad bug 1157678 in xserver-xorg-video-intel (Ubuntu) "unplugging an external monitor from laptop results in corrupted screen. Logging out fixes it." [Medium,In progress] https://launchpad.net/bugs/1157678
[13:54] <apw> rtg_, i'll handle that in my review, i am doing that next anyhow
[13:55] <apw> rtg_, we'll need to do the same to N4, though i hear bad things for our current kernel
[13:55] <rtg_> apw, OK. I was just gonna start with the Raring armhf USB config set and cat it onto the nexus7, updateconfigs, etc
[13:56] <apw> rtg_, well i would want to maintain the current ones, and one has to be a bit careful as the naming of osme of the usb things are dumb
[13:57] <apw> ie they are in the menu w/o usb sounding names, and not in it with usb sounding names
[13:57] <rtg_> apw, so perhaps I should wait until you've produced the config review ?
[13:58] <apw> rtg_, i'll do that one first how about that
[13:58]  * apw assigns the bug to self
[13:58] <rtg_> sure, I'll stick your name on the bug as an assignee
[13:58] <apw> ok ...
[14:04] <rtg_> apw, have you been chatting with ppisati about the state of the N4 kernel ?
[14:04] <apw> rtg_, when jani talks about the staging PPA is that something 'we' do or something they do
[14:04] <apw> rtg_, i asked him, he hasn't used it :)
[14:04] <rtg_> heck if I know
[14:04] <rtg_> must be something they do
[14:04] <apw> it was cking who was mentioning it was a bsod job
[14:04] <apw> rtg_, ack
[14:05] <apw> b == black
[14:05] <rtg_> if figured that meant something pejorative
[14:05] <apw> black-screen-of-death
[14:08] <cking> the "oh no, I have to reflash it again" scenario
[14:08] <smb> rtg_, He was there this morning
[14:09] <smb> rtg_, And I cannot mumble an git push
[14:09]  * smb just forgets always
[14:11] <apw> ogasawara, ok pushed
[14:12] <apw> ogasawara, when you are test building you might want to just check the header symlinks are right in the flavour specific packages... they looked right to me, but the extra eyes are always helpful
[14:14] <rtg_> apw, that should get applied to unstable-3.9 as well
[14:17] <rtg_> apw, P.S. I've been setting commits that only affect the generic debian rules to '(debian)' as opposed to '[Packaging]' just to have some consistency.
[14:17] <apw> rtg_, ok
[14:18] <james_w> hi everyone, my wife is affected by https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1140716 do you know when the fix will be released to quantal? She'll probably run a  test kernel if it will be a while
[14:18] <apw> rtg_, are you fixing my last commit ?
[14:18] <ubot2> Launchpad bug 1140716 in linux-lts-quantal (Ubuntu Precise) "[regression] 3.5.0-26-generic and 3.2.0-39-generic GPU hangs on Sandybridge" [Critical,Confirmed]
[14:18] <rtg_> apw, I have not.
[14:18] <apw> rtg_, ok will do
[14:19] <rtg_> james_w, bjf would be happy to answer your question.
[14:19] <apw> rtg_, re-pushed
[14:19] <james_w> thanks
[14:20] <rtg_> james_w, or even sconklin sicne they know what the Q/A cadence is right now.
[14:20] <rtg_> apw, pushed for unstable-3.9 as well
[14:21] <bjf> james_w, we should have a new kernel in proposed today
[14:21] <bjf> james_w, if it's Q that she's running
[14:21] <james_w> it is
[14:21] <james_w> thanks
[14:21] <bjf> np
[14:22] <bjf> james_w, it's in our ppa ready to be copied to -proposed when infinity gets to it (which won't be long)
[14:22] <sconklin> Quantal built overnight, I'm preparing quantal backport now
[14:23] <bjf> james_w, *don't* use our ppa please (that road leads to madness) though you could pull the .debs from there if you really wanted
[14:23] <james_w> yeah
[14:29] <apw> james_w, if you are going to expose those .debs then make a new ppa and copy them with binaries to it or something
[14:42] <slangasek> arges: yes, I still see it with the drm-intel-nightly kernel; I haven't tested 3.8.0-17 yet, but if you're seeing it there I assume I will also
[14:56] <arges> slangasek: filed a new upstream bug, will re-visit when I have some more time.
[14:56]  * slangasek nods
[14:57] <slangasek> arges: should we perhaps split my bug off from that one, since the original submitter hasn't really commented on reproducibility?
[14:58] <arges> slangasek: possibly. I see two distinct bugs.
[15:30] <ppisati> cking: http://paste.ubuntu.com/5695685/
[15:30] <ppisati> cking: 3.4.y is ok wrt ftrace
[15:31] <cking> ppisati, ok, it may be then a problem with that android kernel or the way I configured ftrace in the build (at a guess)
[15:32] <ppisati> cking: yep, i'll spend a bit more time on it
[15:32] <cking> ppisati, thanks, at least we know 3.4.y is reliable in this respect - which is a relief
[15:33] <ppisati> cking: yep, let's see if we can fix it
[15:44] <jsalisbury> bjf, henrix fyi: bug 1167114  I can bisect, but still gathering initial triage info.
[15:44] <ubot2> Launchpad bug 1167114 in linux (Ubuntu) "Linux 3.5.0.27.43 does not boot" [High,Confirmed] https://launchpad.net/bugs/1167114
[15:46] <henrix> jsalisbury: ack, thanks. i'll go take a look at that
[15:47] <bjf> jsalisbury, ack. there will be a new Q kernel in -proposed shortly which should get tested there were a bunch of upstream commits and it's possible this got fixed
[15:47] <bjf> jsalisbury, so that should be the first thing
[15:47] <jsalisbury> bjf, henrix, ack.  thanks
[15:52] <jsalisbury> henrix, bjf, I marked a couple of other bugs as duplicates as well.
[16:04] <ppisati> my webcam and google hangout don't like each other... bah...
[16:38] <apw> jsalisbury, it would be good to have the kernel version not the -meta version on that title
[16:51] <ppisati> rtg_: ping
[16:53] <rtg_> ppisati, yo
[17:27]  * rtg_ -> lunch
[18:09] <jsalisbury> apw, for bug 1167114, you mean 3.5.0-27 instead of 3.5.0.27.43 ?
[18:09] <ubot2> Launchpad bug 1167114 in linux (Ubuntu) "Linux 3.5.0.27.43 does not boot" [High,Confirmed] https://launchpad.net/bugs/1167114
[18:11] <rtg_> jsalisbury, yes
[18:11] <jsalisbury> rtg_, ok, done.
[18:26] <ppisati> rtg_: the nexus4 tree, it's actually a plain vanilla 3.4 kernel
[18:27] <ppisati> rtg_: am i missing something?
[18:27] <rtg_> ppisati, master-next
[18:27] <ppisati> rtg_: ah ok
[18:28] <rtg_> ppisati, I won't update master until we actually upload
[18:28] <ppisati> rtg_: ok
[19:59]  * rtg_ -> EOD
[20:54] <skaet> bjf, just applied latest updates to 12.10 system, and its continually throwing out GPU errors now.   known problem?
[20:59] <bjf> skaet, version number ?
[21:04] <skaet> bjf, Linux 3.5.0-28-generic
[21:05] <bjf> well, crap!
[21:05] <bjf> infinity, ^
[21:06] <bjf> infinity, i'm thinking we need to pull that kernel
[21:06] <sconklin> that's the one we just pushed, all right.
[21:06] <bjf> help me, help me, save me, save me
[21:07] <sconklin> skaet: are you able to file a bug so we can see the logs?
[21:07] <bjf> skaet, intel video?
[21:08] <skaet> bjf, sconklin - filing bug,   and yes  snadybridge-m-gt2L   False GPU lockup IPEHR... etc.   will see if I can coax a bug out of this systemm
[21:08] <infinity> That's not a new bug, if it's the lockup I'm thinking of.
[21:09] <skaet> no,  its showed up as duplicate of existing.  But it just started up after the last update.
[21:09] <bjf> skaet, i'll have a test kernel for you in a bit
[21:10] <skaet> bjf,  thanks.   standing by.
[21:11] <infinity> bjf: raring userspace and quantal kernels should get along basically fine, right?
[21:12] <infinity> bjf: I have the dreaded sandybridge lockup hardware of doom here, I can give it a spin.
[21:12] <infinity> (Whatever's finally been fixed in 3.8, I don't get the lockups anymore, but I used to get them constantly in Q and R both)
[21:13] <bjf> infinity, we pulled 5 commits from 3.8/3.9 back to fix a regression. i'm suspecting them.
[21:14] <infinity> Fun, fun.
[21:20] <skaet> bjf,  system is getting part way through generating the bug, and then tripping over the error again, so nothing's going out from the automated system.   What logs do you want me to collect?
[21:21] <bjf> skaet, just boot the previous kernel, do an apport-collect and fudge it by hand (i guess)
[21:30] <bjf> skaet, are you seeing a chain of "you've experienced a lockup" dialogs that keep "interrupting" each other?
[21:31] <bjf> skaet, if you are then try deleting everything in /var/crash/ and rebooting
[21:49] <skaet> bjf,  yes,  seeing that chain.   will do.
[21:53] <skaet> bjf,  rebooted,  behaving better so far.
[21:54] <infinity> skaet: So, that might have actually been the apport bug/misfeature where if you've at some point in the past dismissed (or minimized, or something) a report dialog, you then don't get any new ones until reboot.
[21:54] <infinity> skaet: And what it was actually doing was grinding your machine to a halt trying to report all the OLD lockups from your previous kernel.
[21:55] <infinity> But time will tell.
[21:56] <infinity> skaet: Under the previous kernel, did you ever have moments where all your windows would just freeze for a bit inexplicably, and then start working again after a few seconds/minutes?
[21:56] <infinity> (Or, potentially, the desktop seemed to "freeze", but a VT switch made it happy again, that sort of thing)
[21:56] <skaet> infinity,  yes, there were a couple of times like that,  esp. when using google docs from firefox.
[21:57] <infinity> Yeah.  Probably should have gotten you to check timestamps on /var/crash/* before deleting them, but my bet is that apport was reporting old lockups, not new ones.
[21:58] <infinity> On boot, the first thing update-notifier does is check /var/crash for unreported crashes and unhelpfully spawn a few dozen python processes to report them all in parallel.
[21:58] <infinity> Which, it turns out, is a bad idea.
[21:59] <infinity> skaet: Anyhow, if you still get the occasional lockup (though, hopefully not), that's likely not a regression.  If you start seeing a ton of them, yell at bjf to go a-revertin'.
[21:59] <skaet> infinity, indeed.   I saved off the logs before deleting,   xserver-xorg-video-intel.2013-04-10_11:49:14.495521.uploaded  <-- which was from before I updated this afternoon.
[22:00] <infinity> Ahh, good deal.  That lends some peace of mind to my hypothesis.
[22:00] <bjf> skaet, i'll have a kernel standing by if you start seeing true lockups with this version
[22:00] <infinity> bjf: She may well still see lockups, since she clearly did before.  It's the frequency that should be a concern. :)
[22:00] <skaet> bjf,  thanks,  if it starts up again - you'll hear from me. 
[22:00] <infinity> bjf: (Though, I'll be overjoyed if that lockup bug is actually fixed in the new kernel)
[22:01] <skaet> infinity,  might be worth putting out some sort of notice about this though,  since I doubt I'll be the only one encountering it.
[22:01] <skaet> ??
[22:02] <infinity> That apport misfeature has existed for ever.  It's just unfortunate when it bites people who have a bunch of old reports lying around. :/
[22:04] <skaet> yeah but the combination of that misfeature and the latest kernel is quite ugly from a user's perspective... :P
[22:04] <earthling_> hello, I have a question. I notice in security updates there are header files for 3.2... and 3.5 kernel versions. Should I install both updates?
[22:04] <infinity> Sure, my point is that it may have happened to others on the last kernel reboot, or the one before.
[22:04] <infinity> earthling_: Which kernel are you running?
[22:04] <earthling_> 3.5
[22:05] <earthling_> on Precise
[22:05] <infinity> earthling_: Do you have linux-generic-lts-quantal installed?
[22:05] <infinity> earthling_: If so, that'll be keeping your headers and kernel in sync.
[22:05] <infinity> earthling_: If not, you should probably install it.
[22:06] <earthling_> I'm running precise 12.04.2 LTS
[22:06] <infinity> earthling_: Right, I mean the package.  "apt-get install linux-generic-lts-quantal"
[22:06] <earthling_> hmm
[22:06] <earthling_> I did a standard install 2 weeks ago
[22:07] <infinity> Then you probably have that package installed.
[22:07] <infinity> Unless you forcefully removed it at some point.
[22:07] <earthling_> installed through update manager?
[22:07] <infinity> So, I guess the real point here is that security updates will upgrade things correctly without you manually installing packages.
[22:08] <earthling_> I'm looking at history
[22:08] <infinity> Oh, wait.  Do you mean that you have both 3.2 and 3.5 headers installed and update-manager is upgrading both?
[22:08] <earthling_> march 27 yeah
[22:08] <infinity> That would be either a bug on your end, or ours.  But you can safely remove the 3.2 ones if you're using 3.5
[22:08] <Sarvatt> speaking of that, i noticed old headers were getting updated in 12.04.2 too
[22:09] <earthling_> infinity, when I access the grub menu there is no version 3.2
[22:09] <Sarvatt> after a fresh install with no 3.2
[22:10] <infinity> Sarvatt: Curious indeed.  I took great pains to make sure the 3.2 headers weren't on the install media, but maybe something went weird.
[22:10] <infinity> Oh.
[22:10] <infinity> Or it's a dkms module pulling them in.
[22:10] <infinity> We haven't yet SRUed them all to get rid of that stupid dependency.
[22:10] <infinity> That's probably it.
[22:11] <infinity> earthling_: So, the short answer is "it's not a big deal".  The longer answer is "you can remove the 3.2 header packages, just make sure they don't seem to remove something else, like a driver package, but it shouldn't".
[22:11] <infinity> And I'll have to scour the archive to get this all sorted, if we still have a few broken packages.
[22:11] <earthling_> ok, that makes sense
[22:15] <earthling_> hmm update manager a bit frozen or slow
[22:20] <earthling_> restarted, its fine
[22:23] <earthling_> rebooting, thx
[22:24] <maxb> Huh, this is weird. Some of my boot items are not visible in efibootmgr - neither are they visible in /sys/firmware/efi/vars/ - yet they are in /sys/firmware/efi/efivars/ !
[22:26] <maxb> Although trying to read the files in efivars/ results in the processes getting SIGKILL or SIGSEGV
[23:11] <Kano64> hi, just build unstable-3.9 with uvd patches, but the name is uncommon
[23:11] <Kano64> cmd: CPU[x Intel Core i7-3770S @ clocked at 1600.000 Mhz]  Kernel[Linux 3.9.0-0kanotix1-generic x86_64]  Up[-4min-]  Mem[-771.7/7952.8MB-]  HDD[-188GB(48%used)-]  Procs[-217-]  Client[Shell wrapper]
[23:11] <Kano64> why is -generic at the end now?
[23:13] <Kano64> hm generic was always at the end, but never the kanotix1 in the middle
[23:14] <Kano64> every kernel has kanotix1 in the changelog here
[23:35] <infinity> Kano64: Did you used to version it as 0.kanotix1 instead of 0kanotix1?  The kernel packages split on '.' and slap the first part in the kernel version, the latter part is the build number.
[23:35] <infinity> s/slap/slaps/
[23:37] <Kano64> no, since when is a . needed?
[23:38] <infinity> Well, if the intent is to get abi.build, always.
[23:38] <infinity> For example:
[23:38] <infinity> linux (3.8.0-17.27) raring; urgency=low
[23:38] <infinity> Linux cthulhu 3.8.0-17-generic #27-Ubuntu SMP Sun Apr 7 19:39:35 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
[23:39] <infinity> Your 0kanotix1 is all being tacked on to extraversion.
[23:39] <Kano64> usally only in the changelog
[23:53] <Kano64> no extra package for 3.9?