[00:55] <jsalisbury> bjf, I added locking to the auto-reports-mako job on people by using flock.  I'll do the same on cranberry.
[01:13] <hggdh> infinity: quantal armadaxp done, should be ready for you soon
[01:15] <infinity> hggdh: \o/
[01:15] <infinity> hggdh: precise tonight too, or will that be tomorrow?
[01:16] <hggdh> infinity: I am afraid it will be tomorrow, just found there is a race between the test driver code, and the armada boot
[01:16] <infinity> hggdh: S'ok.  Wasn't pressuring, just looking for a timeline. :)
[01:17] <hggdh> infinity: I understand, np there. Just giving you a bit more of data
[01:17]  * infinity nods.
[01:18] <hggdh> infinity: anyway, for the record, it took ~ 3.5 hours to run
[01:18] <infinity> That's not too bad, given it only needs to run a few times every three weeks.
[01:21] <hggdh> I agree there. It is only bad cuz expected end is now around 00:00 CST -- and I will be *very* asleep by then. Or so I hope. Since I have to check the output, this puts a go/no-go for tomorrow 0630 CST
[01:22] <infinity> hggdh: Yeahp, s'all good.  Fire it off and let me know the results in the morning, and we can move this show along. :)
[01:22] <infinity> hggdh: And then I'll promote two more kernels for you tomorrow. :P
[01:22] <infinity> (To proposed, that is, for testing again)
[01:22] <hggdh> infinity: that's cool, gives me some job security
[01:22] <infinity> Heh.
[10:51] <Konstigt> hello.. any packages if I want 3.7 (latest) in 12.10/Quantal avail? Looked at http://kernel.ubuntu.com/~kernel-ppa/mainline but no packages for Quantal including all files..
[12:28] <apw> Konstigt, "including all files" ?
[12:29] <apw> Konstigt, (not that we recommend using those kernels for anything other than testing) you should be fine using the v3.7-rc7-raring one; the raring there refers to the config used, and -raring is the right config to use for 3.7 
[12:29]  * apw pokes smb
[12:30] <rtg> apw: I've been getting some weird PPA build failures lately. That lib/oid thingy. Restarting typically fixes it.
[12:57] <apw> rtg, got an example 
[13:01]  * smb is not listening to apw (at least not before returning)
[13:01] <rtg> apwhmm, not that I've kept. restart the build wipes out the log.
[13:02] <apw> rtg, ok next time grab a copy of the log, if you don't have one in Downloads
[13:02] <apw> and perhaps we can figure out what the heck this thing is
[13:02] <rtg> apw: we looked at one together awhile ago. neither of us could make sense of it at that time either.
[13:03] <rtg> I don't think its a timing race.
[13:03] <rtg> apw: I'm just complaining. not really asking you to do anything :)
[13:06] <apw> rtg, :)
[14:49] <rtg> ogra: is it safe to upgrade my N7 to Raring ? Thought I'd do taht before testing the kexec kernel patch.
[14:52] <ogra_> rtg, well, you lose unity 
[14:53] <ogra_> the nux patch is still missing so all unity elements are garbled
[14:53] <ogra_> if you just use it via ssh, go ahead :)
[14:55] <rtg> ogra_, huh, well maybe I'll just leave it as is for now and test the Raring kernel on Quantal. that should be sufficient.
[14:55] <ogra_> yeah, effectively you just want to know if it boots
[14:56] <ogra_> i'm wondering if we could somehow teach kmod to load the wlan module, that way it wouldnt have to be builtin and we wouldnt have to carry a 4MB vmlinuz
[14:57] <ogra_> (issue is that nothing loads the module if you build it modular, /etc/modules works indeed)
[14:57] <rtg> ogra_, its not udev triggerable ?
[14:58] <ogra_> hmm, that might be
[14:58] <ogra_> though i think it is an SDIO device, not sure if udev sees much of it
[14:58] <rtg> ogra_, ah, that may be why.
[14:59] <rtg> I'm not sure there is a platform device for SDIO that emits discovery events
[15:03] <ogra_> oh, intresting, putting "noinitrd rootwait" on the nexus cmdline lets me end up in the ubuntu initrd :P
[15:06] <ogra_> but at least i get a shiny splash before that happens
[15:34] <bjf> brendand, are my Precise and Quantal kernels going to get their testing finished today ?
[15:36] <brendand> bjf - absolutely
[16:36] <ogasawara> herton: heya.  bjf and I were chatting yesterday and he said you might be making some improvements to shankbot to automatically send upload announcements to the list
[16:37] <herton> ogasawara, yep, I can do it, it already sends email sometimes to some of the SRU lists, so it should be straightforward to do it
[16:38] <bjf> ogasawara, i talked to herton. shank-bot will process any tracking bug regardless of series
[16:38] <ogasawara> bjf: ah sweet
[16:38] <ogasawara> herton: so if I just create a tracking bug for our devel kernels, shankbot could handle it
[16:38] <herton> ogasawara, the bug just needs to be created with create-release-tracker. We may need to tweak the tasks though for dev kernels
[16:39] <herton> ogasawara, yes, any bug tagged with kernel-release-tracking-bug, create-release-tracker should do it with the tasks
[16:40] <bjf> herton, did you resolve that firmware issue you were having with your stable kernels on that one test system (gonzo) ?
[16:41] <ogasawara> herton: I was also curious if for the devel kernels along with sending to our kernel-team mailing list, would it also be possible to CC the ubuntu-installer mailing list as well as some specific QA individuals and BenC?
[16:41] <herton> bjf, I talked to rtg, the firmware were moved to linux-image for pxe boot, and removed from linux-firmware to save space (on the media I think)
[16:41] <herton> ogasawara, yes, that's possible
[16:42] <herton> ogasawara, just send to me the list of who wants the email I'll add
[16:42] <ogasawara> herton: ack
[16:43] <bjf> herton, so what does that mean for how we fix that for that particular system? do we need to install another pkg?
[16:43] <bjf> herton, i think i'm seeing the exact same failure for mainline builds
[16:44] <herton> bjf, yes, mainline builds will fail with same issue. I think for the moment it could be copied manually from the main kernels if possible
[16:44] <rtg> bjf, you could install the upstream linux-firmware package. that has all the firmware ever created.
[16:44] <bjf> rtg, ack
[17:04]  * rtg restores some armhf config options in Raring
[17:13] <herton> rtg, were you suggesting bjf install our linux-firmware package?
[17:14] <rtg> herton, well that won't help 'cause its missing the firmware you need. I'm suggesting you install the debian package which AFAIK hass all the firmware you'll need.
[17:15] <bjf> rtg, where do i get that from?
[17:15] <rtg> bjf, hang on, lemme find it.
[17:19] <rtg> bjf, well, maybe it won't work so well because you'll have conflicts. that, and debian hasn't kept up to date: http://packages.debian.org/search?keywords=firmware-linux-free&searchon=names&suite=stable&section=all . maybe copying manually for stable testing is the best route.
[18:23] <ogasawara> herton, bjf: just ran create-release-tracker for Raring -> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1084640
[18:23] <ubot2> Launchpad bug 1084640 in linux (Ubuntu Raring) "linux: 3.7.0-5.13 -proposed tracker" [Medium,In progress]
[18:24] <ppisati> mumble failing?
[18:24] <herton> ogasawara, ack, shank just set the prepare-package-* tasks to In Progress, shank bot will monitor the build on c-k-t ppa and set that to fix released when done
[18:24] <rtg> ppisati, working for everyone else
[18:24] <herton> s/shank//
[18:24] <ppisati> ba
[18:24] <ppisati> h
[18:25] <ogasawara> herton: do we want to add some checks so that the Kernel SRU Workflow bits aren't added to devel kernel tracking bugs?
[18:25] <bjf> ppisati, was working fine for us a second ago
[18:25] <ppisati> yeah, but it keeps disconnecting
[18:25] <ppisati> maybe it's my network
[18:25] <bjf> ppisati, seems stable for me
[18:25] <herton> ogasawara, ah yes, I have to adapt create-release-tracker to stop subscribing SRU team etc., will do
[18:26] <herton> ogasawara, it's a easy check, just see if it's set as a development kernel or not on ktl/ubuntu.py
[18:27] <rtg> ogra: uploaded linux-nexus7_3.1.10-8.15 to raring with kexec patches.
[18:27] <ogasawara> herton: ack.  you also just mentioned shank bot monitors the ckt ppa...we actually don't upload our devel kernels to the ckt ppa.  is that a problem?
[18:27] <herton> ogasawara, hmm it is, it monitors c-k-t ppa for the builds, but I can change that. It's uploaded directly to -proposed correct?
[18:28] <ogasawara> herton: yep that's correct
[18:28] <herton> ok, will fix this
[18:29]  * rtg -> lunch
[18:29] <ogasawara> herton: awesome, thanks.  no hurry on this if you have more important things to address
[18:30] <ogasawara> herton: this is one of those nice to have types of things, but not blocking or high priority by any means
[18:31] <herton> ogasawara, ack, I think it'll not be too much work, probably today or monday I can have it ready
[18:33] <bjf> ppisati, maybe it's a sign to call it a day 
[18:35] <ppisati> ok, killed mumble now
[18:36] <ppisati> still trying to undestand one thing, can't quit yet :P
[19:02] <herton> ogasawara, hmm, I think I'll want to create a new "Kernel Workflow" or "Kernel Devel Workflow" project on Launchpad, it'll be similar to Kernel SRU Workflow on tracking bugs. We need a similar set of tasks on the tracking bug
[19:02] <ogasawara> herton: ack
[19:04]  * henrix -> EOD
[19:44] <BenC> infinity: A little heads up next time you go poking around my git trees :)
[19:45] <BenC> I should enable email notifications for those trees
[19:57] <rtg> hmm, the current Raring kernel has broken my touchpad. Lenovo x120e
[19:57] <infinity> BenC: Hrm?  Did I cause you grief somehow?
[19:57] <infinity> BenC: The general concept of DVCS is that when you try to push, you notice you're out-of-date. :P
[19:58] <infinity> rtg: You should find someone on the kernel team to look at tha-- waaaait.
[19:58] <rtg> infinity, actually, I was just about to consult with sforshee :)
[20:01] <BenC> infinity: I noticed it after I did the upload…the one time I didn't push before dput
[20:01] <infinity> BenC: Well done. :P
[20:01] <BenC> infinity: And I'm used to doing --force on linux-ppc since it's almost always a rebase
[20:02] <BenC> I'm not sure why github doesn't send email notifications to me…let me check my spam folder
[20:03] <infinity> BenC: Anyhow.  I can poke you when I commit changed, but I figure if you're maintaining your packages in a DVCS, pushing before upload should just be part of the workflow.
[20:03] <infinity> s/changed/changes/
[20:03] <BenC> It usually is, so disregard my grumbling
[20:03] <BenC> Watch out if you ever mess with linux-ppc though
[20:03] <infinity> BenC: Also entertaining that the changelog now has the source package name flip-flopping. :)
[20:04] <sforshee> rtg, what kind of touchpad? synaptics?
[20:04] <BenC> History must be retained :)
[20:04] <rtg> sforshee, thats what I'm trying to figure out. any hints ?
[20:04] <infinity> BenC: Anyhow, I rejected your accidental linux-ppc-meta, s'all good.
[20:04] <BenC> Thanks
[20:05] <sforshee> rtg, that's a black art ;)
[20:05] <infinity> Oh lord, it's firefox security day.
[20:05] <infinity> Poor buildds.
[20:05] <sforshee> rtg, check dmesg, if there's nothing there you'll have to boot to a kernel where it works
[20:05] <rtg> sforshee, searched for 'synap' to no avail
[20:06] <sforshee> rtg, try searching for 'psmouse'
[20:06] <rtg> sforshee, will do as soon as this kernel is done installing. tip of master-next
[20:07] <sforshee> rtg, ack
[20:09] <rtg> sforshee, hmm, 'mousedev: PS/2 mouse device common for all mice'. Is that bad ?
[20:09] <sforshee> rtg, I'll have to look to be sure, but I suspect that means it's just falling back to the standard PS/2 mouse protocol
[20:10] <rtg> sforshee, I have a bunch of older kernels installed. lemme see what they have to say.
[20:10] <sforshee> rtg, it still doesn't work at all though?
[20:10] <rtg> sforshee, frozen
[20:14] <sforshee> rtg, that message is actually completely generic, it will always appear even if you don't have a mouse at all
[20:15] <rtg_> sforshee, [   19.179331] psmouse serio4: synaptics: Touchpad model: 1, fw: 7.5, id: 0x1e0b1, caps: 0xd000b3/0x340000/0xa0400
[20:15] <rtg_> [   19.179358] psmouse serio4: synaptics: serio: Synaptics pass-through port at isa0060/serio4/input0
[20:16] <rtg_> 3.5.0-18-generic
[20:16] <rtg_> let the bisecting begin
[20:16] <sforshee> rtg_, so right now all you know is that it broke between 3.5 and 3.7?
[20:16] <sforshee> rtg, ^
[20:17] <rtg> sforshee, I'm gonna try and get a little closer. I'm just sure the early 3.7 kernels worked
[20:19] <sforshee> rtg, virtually nothing has changed in the mouse or serio code since 3.7-rc1
[20:20] <rtg> sforshee, well, 3.7.0-2 doesn't work, but I'm sure it _used_ to. I would have discovered this issues 3 or 4 weeks ago. Could something in user space be buggered ?
[20:21] <sforshee> rtg, it _could_ be, but then you said the 3.5 kernels work
[20:21] <rtg> sforshee, yep
[20:23] <sforshee> rtg, we don't have the cypress patches in raring?
[20:24] <rtg> sforshee, I think they clashed and got dropped. lemme chaeck for sure
[20:24] <sforshee> rtg, the code isn't there
[20:24] <sforshee> i was just suprised
[20:24] <sforshee> *surprised
[20:24] <rtg> sforshee, kamal was working to upstream them, so I though we'd get 'em for 3.8
[20:25] <sforshee> rtg, there was this one userspace integration issue that the first round of those patches caused, which is why I noticed. But we can rule that out.
[20:25] <kamal> rtg, sforshee: the cypress driver was indeed dropped from raring
[20:25] <sforshee> rtg, can you pastebin dmesg from a non-working kernel?
[20:26] <kamal> one vestige remained (an enum that should have been harmless) but rtg recently rebased that away too
[20:26] <rtg> sforshee, lemme reboot and get tip of master-next dmesg
[20:31] <rtg> sforshee, ok, its intermittent. works now with tip of master-next. warm boot. I've also tried cold booting.
[20:31] <rtg_> sforshee, rtg@x120e:~$ dmesg |egrep -i "synap|mouse"
[20:31] <rtg_> [    1.800980] mousedev: PS/2 mouse device common for all mice
[20:31] <rtg_> [   19.457503] psmouse serio4: synaptics: Touchpad model: 1, fw: 7.5, id: 0x1e0b1, caps: 0xd000b3/0x340000/0xa0400, board id: 1403, fw id: 749625
[20:31] <rtg_> [   19.457528] psmouse serio4: synaptics: serio: Synaptics pass-through port at isa0060/serio4/input0
[20:31] <rtg_> [   19.501730] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio4/input/input8
[20:31] <rtg_> [   25.360441] psmouse serio5: trackpoint: IBM TrackPoint firmware: 0x0e, buttons: 3/3
[20:32] <rtg> sforshee, hmm, I'll have to noodle on this tomorrow. I gotta launch.
[20:32] <sforshee> rtg, hmm. It may be that after booting a bad kernel you need a cold boot to reset the EC to get it out of a funky state
[20:32] <rtg> sforshee, possibly. I'll see if I can determine a pattern.
[20:32]  * rtg -> EOD
[20:33] <infinity> BenC: Oh, mind if I gimp your linux-ppc upload to the end of the buildd queue?  With firefox appreciation day happening, I'd like to give the buildds some breathing room, and it looks like it was just a rebase against master.
[20:33] <BenC> infinity: it's unimportant from my end, so no problem
[20:33] <infinity> BenC: Great, thanks.
[23:18] <luc4_mac> Hi! I recently noticed that my server seems to have issues with USB. I just noticed a kernel trace in dmesg. Can anyone have a look?
[23:28] <myhrlin> luc4_mac: go ahead and paste the dmesg output with your paste-site of choice :)
[23:29] <luc4_mac> myhrlin: http://pastebin.com/t1cF17Ts
[23:29] <luc4_mac> myhrlin: here I plugged in a usb mouse.
[23:30] <luc4_mac> myhrlin: now I tried with a usb pen drive and a usb hard disk.
[23:30] <luc4_mac> myhrlin: nothing seems to be working.
[23:34] <luc4_mac> myhrlin: now I tired with an older kernel. I get other usb error messages and the mouse is still not working, but it seems after a while an hard disk appeared.
[23:35] <luc4_mac> myhrkin: this is the output http://pastebin.com/WmiDTbqc
[23:35] <myhrlin> luc4_mac: I'm sorry but I'm not really sure what to do.  I just said to provide the paste in case someone sees your question and would be able to solve it but they wouldn't have the dmesg output available
[23:35] <myhrlin> and if they think they can solve it but you're not around to provide the dmesg output or something goes wrong... :) better just paste it
[23:37] <luc4_mac> myhrlin: ok, thanks for the advice then!