[00:00] <infinity> bjf: Which includes a full set of virtual->virtual, since all of those were just enabled in lbm itself.
[00:01] <infinity> bjf: Want me to look at this and whip up a diff against the current source packages, or are you on it already?
[00:02] <bjf> infinity, i'm staring at it
[00:02]  * infinity nods.
[00:02] <infinity> Happy to re-review when you have something new to look at.
[00:02] <infinity> I suck at vacations. :P
[00:02] <bjf> infinity, lol, ack
[00:03] <infinity> The Q fix is just a simple s/virtual/generic/ and it's done, FWIW.
[00:03] <infinity> (And regenerating all the control bits)
[00:03] <infinity> P is a bit more annoying.
[00:04] <bjf> infinity, for Q there is a control.d/virtual file where that info is, i'm thinking it should be in control.d/generic
[00:04] <infinity> It should be, yeah.
[00:05] <infinity> And for P, the -hv- stuff should be in all of generic, generic-pae, and virtual, and then virtual should be fleshed out to have all the same content as generic.
[00:05] <infinity> Ish.
[00:05] <bjf> infinity, ack
[00:06] <bjf> infinity, should the Q virtual file have any of this in it?
[00:06] <infinity> The Q virtual should just go away.
[00:06] <infinity> cat control.d/virtual | sed 's/virtual/generic/g' >> control.d/generic && rm control.d/virtual
[00:06] <bjf> infinity, that's what i was thinking .. there is also a generic-pae ... i'm assuming we are just lazy
[00:07] <infinity> The generic-pae in Q is all transitional packages to generic.
[00:07] <bjf> ah
[00:07] <infinity> Oh, that's true of the rest of virtual too.
[00:07] <infinity> So it needs to stay.
[00:08] <infinity> Just remove the -hv- stanza, and move it to generic and rename sanely.
[00:08] <bjf> infinity, ack
[00:08] <infinity> We don't do transitional stuff for lbm, so no need to worry about such a thing.
[00:09] <infinity> (Though I do wonder if maybe we should, today's not the day to discuss that)
[00:12] <bjf> infinity, i've pushed the Q changes
[00:14] <infinity> Will have a look as soon as LP tells me about it.
[00:14] <bjf> infinity, just into the git repo
[00:14] <infinity> Oh. :P
[00:15] <infinity> The commit looks right, assuming it all generates properly when you do the source upload.
[00:16] <infinity> And assuming nothing has a sad about the extra linefeed.
[00:17] <infinity> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-quantal-meta.git;a=blob;f=meta-source/debian/control.d/generic;h=90d4e0bcc7ee770858ce9c6b5a7cc05715817828;hb=f77899061f924e6446d04d3a3f0f35e0da862dab <-- Line 56 doesn't need to be there.
[00:17] <ogasawara> infinity,bjf: yeek, sorry just back from dentist
[00:17] <infinity> But I'm pretty sure dpkg-genchanges won't be that annoyed.
[00:17] <bjf> ogasawara, i'm fixing
[00:17] <ogasawara> infinity, bjf: the virtual meta to generic cross dependency was on purpose according to apw
[00:17] <infinity> ogasawara: We've got it under control, I think.  Send me some nitrous and we'll call it even.
[00:17] <infinity> ogasawara: On purpose?
[00:17] <bjf> ogasawara, ok, i'm now holding
[00:18] <bjf> ogasawara, i've got to go fetch my son ... will be back in about 20 min
[00:18] <infinity> ogasawara: In Q or P?  In Q, it's pretty clearly just weirdly wrong.  In P, it seems pretty wrong too, given that it's built against generic, but installed for virtual?
[00:18] <infinity> (Which are two distinct kernel builds in P)
[00:20] <ogasawara> infinity, bjf: it's needed for a vitual install, but we don't build a virtual flavored lbm atm
[00:20] <infinity> ogasawara: Err, we do now.  It just got turned on.
[00:20] <ogasawara> infinity: oh
[00:21] <infinity> Besides, there's no way an lbm-hv-virtual depending on lbm-hv-$(abi)-generic would ever work.
[00:21] <infinity> Since that's installing modules in /lib/modules/$(abi)-generic, but you want to load them with the virtual kernel.
[00:21] <infinity> Work go splat.
[00:22] <infinity> s/Work/World/
[00:22] <infinity> So, yeah.  After looking at the actual contents of what LBM just spit out, the meta changes I'm having bjf do are absolutely required/correct.
[00:23] <ogasawara> infinity: ack, thanks for fixing up
[00:24] <infinity> bjf: When you get back, please unhold. :)
[01:20] <bjf> i'm unholding
[01:30] <bjf> infinity, ogasawara new pkgs uploaded
[01:30] <ogasawara> bjf: ack, thanks
[01:34] <bjf> ogasawara, infinity i'll be checking back frequently if anything pops
[01:35] <ogasawara> bjf: same here.  gonna run some quick errands and pop back in later.  I'll ping utlemming with current status.
[01:36] <infinity> bjf: So, Q looks good.
[01:37] <infinity> bjf: P is still missing all the *other* meta packages for -virtual.
[01:37] <infinity> bjf: (This LBM upload enabled lbm wholesale for virtual, so it wants to have all the same bits as -generic)
[01:39] <infinity> Maybe Andy didn't intend to enable all the LBM modules for -virtual, but he sure did...
[01:41] <infinity> That said, it's probably not world-ending to not have metapackages for all of them either.
[01:42] <ogasawara> infinity: in talking with apw we don't have a good mechanism to only build hyperv lbm for just virtual
[01:42] <ogasawara> infinity: we are intending to fix that
[01:42] <infinity> Building it for all is fine.
[01:42] <ogasawara> infinity: so I think not having meta package for the other's is ok
[01:42] <infinity> It's the other way around that's weird.
[01:42] <ogasawara> infinity: as we really don't want them in the end anyways
[01:42] <infinity> As in, building cw and net and such for virtual is weird.
[01:43] <ogasawara> infinity: indeed
[01:43] <infinity> This is already a solved problem where we only build -net- for server...
[01:43]  * infinity has a peek at the source package.
[01:46] <infinity> Oh, nevermind.
[01:47] <infinity> That's just a meta for server that shouldn't be there. :P
[01:47] <infinity> We don't build modules that match it.
[01:47] <ogasawara> infinity: that I believe that's just a stub for upgrade purposes and we plan to ditch it in 14.04
[01:48] <infinity> ogasawara: For LBM, it probably should have been ditched earlier.  But no harm.
[01:48] <infinity> ogasawara: Since LBM metapackages are named by release (ie: linux-backports-modules-net-precise-server), there clearly wasn't an upgrade path concern there.
[01:49] <ogasawara> infinity: ah right
[01:49] <infinity> Anyhow, the current state of things since bjf's uploads seems fine.
[01:49]  * ogasawara makes a note to review lbm meta's
[01:49] <infinity> I agree that metapackages for virtual for compat-wireless seem useless. :P
[01:50] <infinity> ogasawara: This is all right in Q/R, I believe, so it's just a wart in precise.  Not world-ending.  But we're kinda stuck with it now, if anyone actually installed that package.
[01:50]  * infinity shrugs.
[01:50] <infinity> Long live the status quo.
[01:54] <infinity> bjf: Thanks for the fixes.  Once I get it built on PPC, I'll push it through.
[01:54] <infinity> ogasawara: If Andy has a conniption when he wakes up, tell him to talk to me. :)
[03:06] <bjf> infinity, i'm just waiting on a ppc builder :-P
[04:18] <infinity> bjf: You and me both.  The bzr testsuite appears to be having a crazy.
[04:19] <infinity> bjf: Scavenging adare so we can get those metas built.
[04:38] <infinity> bjf: Ahh, I think I've divined the point of the cross-dep in Q (not in P, where it was just plain wrong).  Probably wanted it to match up with linux-image-virtual.  Still makes sense to have the -generic as well, but I could see the argument for also having the cross-dep -virtual.
[04:39] <infinity> bjf: If you have the energy to add the -virtual stub back as well (for Q), that might make all involved go "hey, yeah, that kinda works how I thought it should".  If not, I doubt anyone will care. :P
[04:47] <bjf> infinity, looking
[04:49] <infinity> bjf: If you decide to reupload Q again with the -virtual stub re-added (but don't revert the generic one, which is correct, IMO), I'll get it all promoted tonight before I go to bed, you don't need to babysit.
[04:49] <bjf> infinity, doing it now
[04:50] <bjf> infinity, so exactly like apw had it?
[04:50] <infinity> bjf: Yeah, that would be fine (but with the -generic that you added as well).
[04:51] <bjf> infinity, ack
[04:51] <infinity> Going to go watch an episode of Firefly and come back to this in a bit.
[04:51] <bjf> ack
[04:51] <bjf> shiny
[04:57] <bjf> infinity, and we're off again to the races
[05:56] <infinity> bjf: Poifect, thanks.
=== chiluk_away is now known as chiluk
=== chiluk is now known as chiluk_away
=== yofel_ is now known as yofel
=== gavin__ is now known as gavinguo
[09:27]  * cking reboots again
=== henrix_ is now known as henrix
[11:04] <b-quirk_> Hi!
[11:04] <b-quirk_> cking, could you help me with WMI buttons support on my laptop? I can do EC dumps and can provide dsdt
[11:06] <cking> b-quirk_, what laptop model is it?
[11:06] <b-quirk_> Lenovo Y460/560
[11:08] <cking> b-quirk_, I'm not working on enablement work on laptops at the moment. I suggest filing a bug and I can ask one of our engineers who works on lenovos to have a look at it
[11:10] <cking> I suggest putting the output from "sudo acpidump" into the bug report so we can look at the WMI blobs
[11:10] <b-quirk_> OK. But is chance high if SCI counter in /sys/firmware/acpi/interrupts/sci does not increase when pressing the buttons?
[11:11] <cking> hrm, I would expect to see something happen there on a button press
[11:12] <cking> but I'm not that familiar with this Lenovo model, so who knows 
[11:17] <b-quirk_> thanks
[11:24] <luc4> Hi! I'm experiencing a strange issue: it seems that for some months now my USB ports are all not working. If I plug a mouse in I get that the laser lights for some ms and then turns off. Hard disks seems to be on but nothing can be seen from the os. dmesg is not logging anything at all. Any idea what might be wrong?
[11:29] <cking> luc4, all your ports or just some of them are not working?
[11:29] <luc4> cking: all of them.
[11:30] <cking> do you get any messages if you do the following:  dmesg| grep usb | grep Product
[11:30] <luc4> cking: the strange thing is that I tried with older kernels and the same is happening...
[11:31] <luc4> No messages at all.
[11:31] <cking> sounds either broken (which is perplexing) or perhaps (at a guess) have you disabled them in the BIOS config?
[11:33] <luc4> cking: mmh... oops... Might explain... I'm checking that! Thanks!
[11:35] <luc4> cking: no, seems to be enabled...
[11:35] <cking> luc4, in which case, I don't really know, I was expecting the kernel to report it had seen something.
[11:36] <luc4> cking: there are 4 hubs here... seems strange that all of those are broken at the same time...
[11:38] <cking> luc4, does the following report anything?  dmesg | grep "Host Controller"
[11:39] <infinity> Or lsusb...
[11:39] <luc4> cking: interesting... I just found that it seems to work in recovery mode.
[11:39] <luc4> infinity: lsusb reports only the hubs.
[11:39] <luc4> infinity: in recovery mode instead I see both the hard disk and the mouse.
[11:40] <infinity> By default, there's nothing on the non-recovery kernel cmdline that would explain that, unless you've altered yours.
[11:40] <cking> or the H/W is flakey and you got lucky this time
[11:40] <luc4> infinity: I had to change the kernel command line to remove acpid.
[11:40] <infinity> Or enabling a framebuffer takes out his USB. :P
[11:41] <infinity> (Which would be both hilarious and a bit scary)
[11:41] <infinity> Oh, dropping ACPI could certainly account for this sort of behaviour.
[11:41] <luc4> Booted again in normal configuration and nothing works again.
[11:42] <cking> what is exactly your kernel boot line? cat /proc/cmdline 
[11:44] <luc4> cking: BOOT_IMAGE=/vmlinuz-3.5.0-19-generic root=UUID=f5d18141-1192-4ba1-91ea-15445600f4ad ro quiet splash acpi=off apm=off vt.handoff=7
[11:45] <luc4> cking: this is an old machine, like 15 yo. USB is 1.1.
[11:45] <cking> steam powered then
[11:46] <cking> luc4, so did USB ever work without acpi=off?
[11:47] <luc4> cking: it has always been working. Let me check now if removing acpi.
[11:50] <luc4> cking: you got it :-)
[11:50] <luc4> cking: is this supposed to happen?
[11:50] <cking> what, turning off ACPI support and expecting things to work?
[11:51] <luc4> cking: sorry, my connection dropped.
[11:51] <infinity> 04:50 < luc4> cking: is this supposed to happen?
[11:51] <infinity> 04:50 < cking> what, turning off ACPI support and expecting things to work?
[11:51] <cking> luc4, so disabling ACPI is not really helpful if you can avoid doing so
[11:52] <luc4> cking: sorry, I'm not an expert. I read acpi is something used to handle standby. Is this correct?
[11:53] <luc4> cking: I had to disable that because it seems it is randomly putting down my network connection, which is quite an issue for a machine used as a server.
[11:53] <infinity> It's used for all sorts of hardware detection and configuration.
[11:54] <cking> ..power management, performance states, H/W config at a load more besides
[11:54] <luc4> infinity: I see. The problem is that enabling that puts back a huge issue I've been having for months: network is somehow put to sleep at random times.
[11:55] <luc4> Anything I can do in between to have NO standby but to get my USB ports back?
[11:55]  * cking ponders
[11:58] <luc4> Also, is that supposed to happen? Packets being dropped because of some kind of power saving feature I didn't configure?
[12:00] <luc4> cking: this is the issue I'm talking about: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/997767. I reported it and it seems that acpi=off solved it.
[12:00] <ubot2`> Launchpad bug 997767 in linux (Ubuntu) "10ec:8139 Network connection rtl8139 lost after some hours of inactivity and comes up again on user interaction" [Medium,Confirmed]
[12:02]  * cking looks
[12:02] <luc4> cking: thanks for your time also :-)
[12:03] <luc4> cking: I've been testing this solution for some months before posting on the bug providing this information. To ensure it did solve my issue.
[12:04] <cking> yep, I'm just catching up with what's been done on this
[12:06] <cking> luc4, I'll assign this bug to me and I will think about it, I may update the bug in a few hours once I've got my head around what is happening
[12:07] <luc4> cking: it would be very interesting! Thanks for your help!
[12:07] <cking> :-)
[13:17] <brendand> henrix, will the precise -proposed kernel get verified today or is it more likely to be monday?
[13:18] <henrix> brendand: we still have 2 srus to verify, and i'm having a hard time contacting people that could verify them...
[13:19] <henrix> brendand: so, it's unlikely to have them ready today
[13:19] <rtg> henrix, how about rejecting their patches if nobody cares ?
[13:20] <henrix> rtg: yeah, that's a possibility. i'll give the patches another look
[13:21] <brendand> henrix, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/841315 is a common issue on lenovo systems, if i'm reading it right
[13:21] <ubot2`> Launchpad bug 841315 in linux (Ubuntu Precise) "on thinkpad-acpi devices, brightness setting ommits most steps" [Undecided,Fix committed]
[13:21] <brendand> henrix, we've seen it a lot in certification
[13:22] <henrix> brendand: would you be able to verify the bug? :)
[13:22] <henrix> i mean, are you able to reproduce the issue and verify the kernel in -proposed fixes it?
[13:22] <brendand> henrix, i need to dig up a system that had the issue. bear with me a few minutes
[13:22] <henrix> brendand: that would be great. thanks
[13:27] <henrix> brendand: this is the only bug missing verification. i just tagged the other one as david commented on the bug, stating it came from stable updates (not sure how i missed that...)
[13:28] <brendand> henrix, well i found a system that did have it. just liasing with the lab in lexington to get it checked
[13:29] <henrix> brendand: cool! the bug reporter refers to a thinkpad x60 tablet.
[13:30] <brendand> henrix
[13:31] <brendand> henrix, whoops sorry. slippy fingers
[13:31] <brendand> henrix, i'll get back to you asap
[13:31] <henrix> brendand: thanks
[13:40] <caribou> out of curiosity, what does LBM means ?
[13:41] <rtg> caribou, linux-backport-modules
[13:41] <caribou> rtg: ah, Backport, thanks!
[13:55]  * henrix is experiencing a power outage. running on battery + 3g ...
=== chiluk_away is now known as chiluk
[14:00] <wmp> hello, how to send issue about kernel to launchpad?
[14:00] <brendand> wmp, ubuntu-bug linux
[14:00] <wmp> ok, thank
[14:01] <wmp> i have problem with hybrid card and wake up in my acer, i should report bug into kernel?
[14:03] <brendand> wmp, probably the best place, yes
[14:03] <wmp> ok
=== henrix_ is now known as henrix
[14:07] <wmp> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1090373
[14:07] <ubot2`> Launchpad bug 1090373 in linux (Ubuntu) "Acer 4820TG problem with hybrid graphic cards and wake up" [Undecided,New]
[14:18] <Chipaca> Hi guys. My 12.10 (work) notebook just did http://ubuntuone.com/2H40O7MufWIuQmHMKZooOP
[14:18] <Chipaca> in the middle of a kernel upgrade
[14:18] <Chipaca> is that bug-worthy, or do you know about it already?
[14:21] <rtg> herton, ^^
[14:23] <herton> Chipaca, it should be fixed by 3.5.0-21.32 update
[14:23] <Chipaca> herton: ah, good
[14:24] <Chipaca> it was installing that that it broke
[14:24] <herton> it's now in proposed (since yesterday I think)
[14:24] <Chipaca> and i had to boot to single-mode to fix it all up
[14:24] <Chipaca> oh, wait
[14:24] <Chipaca> I'm now on 3.5.0-21-generic
[14:24] <Chipaca> that's not it?
[14:25] <herton> Chipaca, yes, 3.5.0-21 is the good kernel. Your oops on the screen showed the crash with the -20 kernel
[14:27] <Chipaca> herton: yep. \o/
[14:27] <Chipaca> thanks
=== rsalveti_ is now known as rsalveti
[15:06]  * herton -> lunch and errand
[15:38]  * ogasawara back in 20
[15:45] <bjf> moin
[15:51] <henrix> brendand: any luck verifying the bug?
[15:51] <brendand> henrix, it's a bit unclear right now
[15:52] <henrix> brendand: you mean, you can't reproduce it?
[15:54] <brendand> henrix, that's what's unclear. i don't have physical access again, so i'm going on second hand information
[15:54] <henrix> brendand: ah, right. that makes it a little bit more difficult to verify :)
[16:28] <rtg> AceLan_, chiluk, ikepanhc, arges: rebooting tangerine for kernel update
[16:28] <arges> rtg, one second
[16:28] <chiluk> O
[16:28] <chiluk> I'm off.
[16:28] <arges> rtg, n/m
[16:28] <rtg> arges, ready ?
[16:28] <arges> rtg, go for it
[16:28] <chiluk> must have been an important update.
[16:38]  * cking reboots for the nth time today
[17:29] <brendand> henrix - looks like -proposed doesn't fix the issue. sorry it took a while
[17:30] <henrix> brendand: grrrr... thanks a lot for the effort helping with this
[17:31] <brendand> henrix, although i may be losing it and it's not even the same issue, so i'd say the status is still 'unverified' rather than actually confirmed not working
=== chiluk is now known as chiluk_away
=== pgraner` is now known as pgraner
[18:29]  * henrix -> EOD
=== henrix is now known as henrix_
[18:32]  * rtg -> lunch
=== chiluk_away is now known as chiluk
[19:34] <bjf> slangasek, do you know who moderates the ubuntu-installer mailing list?
[19:35] <slangasek> bjf: no, but I'd guess cjwatson and/or ev
[19:36] <slangasek> https://lists.ubuntu.com/mailman/listinfo/ubuntu-installer claims cjwatson, at least
[19:36] <slangasek> (and he's off today, so maybe you're better off subscribing, disabling delivery, and re-posting?)
=== kees_ is now known as kees
[19:37] <bjf> slangasek, i'm subscribed but a bot running as me is doing the posting and it's not getting through
[19:37] <slangasek> ah
[19:37] <bjf> slangasek, i'll keep digging, thanks for the help
[19:43]  * rtg recovers a roached laptop....
[19:53] <slangasek> hmm, why would a system be missing /proc/slabinfo? (bug #1090308)
[19:53] <ubot2`> Launchpad bug 1090308 in mountall (Ubuntu) "init: mounted-proc main process terminated with status 1" [Undecided,New] https://launchpad.net/bugs/1090308
[19:59] <rtg> grr. xchat hates cut-n-paste
[20:00] <rtg> slangasek, is there a crash in dmesg which indicates that slabinfo might have disappeared ? or perhaps it is not an Ubuntu kernel ?
[20:00] <slangasek> rtg: it's not my machine; I asked the second question already on the bug, we'll see what comes back
[20:01] <rtg> slangasek, would you repeat the bug number ? I lost it when my IRC client crashed
[20:01] <slangasek> 1090308
[20:01] <rtg> bug #1090308
[20:01] <ubot2`> Launchpad bug 1090308 in mountall (Ubuntu) "init: mounted-proc main process terminated with status 1" [Undecided,Incomplete] https://launchpad.net/bugs/1090308
[20:04] <herton> slangasek, rtg, I think that's because CONFIG_SLUB_DEBUG was disabled accidentally on raring kernel, someone mentioned it this week
[20:04] <slangasek> ah
[20:04] <slangasek> should I move that to the linux package and dupe it somewhere, then?
[20:05] <rtg> herton, but that doesn't disable /proc/slabinfo does it /
[20:05] <herton> not sure, would have to check
[20:05] <rtg> hmm, maybe it does.
[20:05] <rtg> slangasek, I'll reassign it to linux
[20:08] <rtg> herton, CONFIG_SLABINFO seems to have disappeared.
[20:09] <rtg> herton, SLABINFO 'depends on SLAB || SLUB_DEBUG'
[20:10] <herton> rtg, yep, saw it now too, so indeed that's the problem (needs SLUB_DEBUG)
[20:10] <herton> disabled in our config right now
[20:10] <rtg> wonder why we turned it off ?
[20:16] <herton> rtg, ok I recalled now, yesterday kees reported this too here on irc, apw was going to take a look, but I think it was accidentally disabled. It's disabled in commit c28f49fd. colin did some measurements about having SLUB_DEBUG, and there was minimal overhead (http://kernel.ubuntu.com/~cking/slub-debug/)
[20:16] <rtg> herton, well I've just restored it and pushed
[20:17] <herton> yes, the conclusion was to have it enabled
=== rtg is now known as rtg-afk
[20:51] <herton> rtg-afk, CONFIG_SLUB_DEBUG_ON should be disabled, who wants extra debugging can use slub_debug on command line, this will have some overhead I think
=== rtg-afk is now known as rtg
[21:00] <rtg> herton, fixed
[21:47] <hggdh_> folks, I am experiencing something weird with armada -- I am installing the new kernel from -proposed (quantal) and flash-kernel is deferred but *not* executed at the end of the install
[21:47] <hggdh_> https://pastebin.canonical.com/80562/
=== hggdh_ is now known as hggdh
[21:48] <hggdh> a manual reinstall for the proposed *did* execute flash-kernel
=== chiluk is now known as chiluk_away