[00:55] bjf, I added locking to the auto-reports-mako job on people by using flock. I'll do the same on cranberry. [01:13] infinity: quantal armadaxp done, should be ready for you soon [01:15] hggdh: \o/ [01:15] hggdh: precise tonight too, or will that be tomorrow? [01:16] 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] hggdh: S'ok. Wasn't pressuring, just looking for a timeline. :) [01:17] infinity: I understand, np there. Just giving you a bit more of data [01:17] * infinity nods. [01:18] infinity: anyway, for the record, it took ~ 3.5 hours to run [01:18] That's not too bad, given it only needs to run a few times every three weeks. [01:21] 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] 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] hggdh: And then I'll promote two more kernels for you tomorrow. :P [01:22] (To proposed, that is, for testing again) [01:22] infinity: that's cool, gives me some job security [01:22] Heh. === jk-- is now known as jk- === RAOF_ is now known as RAOF === shadeslayer_ is now known as shadeslayer === rsalveti_ is now known as rsalveti === smb` is now known as smb === henrix_ is now known as henrix === rudimeyer___ is now known as rudimeyer [10:51] 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] Konstigt, "including all files" ? [12:29] 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] apw: I've been getting some weird PPA build failures lately. That lib/oid thingy. Restarting typically fixes it. [12:57] rtg, got an example [13:01] * smb is not listening to apw (at least not before returning) [13:01] apwhmm, not that I've kept. restart the build wipes out the log. [13:02] rtg, ok next time grab a copy of the log, if you don't have one in Downloads [13:02] and perhaps we can figure out what the heck this thing is [13:02] apw: we looked at one together awhile ago. neither of us could make sense of it at that time either. [13:03] I don't think its a timing race. [13:03] apw: I'm just complaining. not really asking you to do anything :) [13:06] rtg, :) === yofel_ is now known as yofel === 20WABM4XS is now known as jussi === jussi is now known as jussi01 === jussi01 is now known as jussi [14:49] ogra: is it safe to upgrade my N7 to Raring ? Thought I'd do taht before testing the kexec kernel patch. [14:52] rtg, well, you lose unity [14:53] the nux patch is still missing so all unity elements are garbled [14:53] if you just use it via ssh, go ahead :) [14:55] 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] yeah, effectively you just want to know if it boots [14:56] 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] (issue is that nothing loads the module if you build it modular, /etc/modules works indeed) [14:57] ogra_, its not udev triggerable ? [14:58] hmm, that might be [14:58] though i think it is an SDIO device, not sure if udev sees much of it [14:58] ogra_, ah, that may be why. [14:59] I'm not sure there is a platform device for SDIO that emits discovery events [15:03] oh, intresting, putting "noinitrd rootwait" on the nexus cmdline lets me end up in the ubuntu initrd :P [15:06] but at least i get a shiny splash before that happens [15:34] brendand, are my Precise and Quantal kernels going to get their testing finished today ? [15:36] bjf - absolutely [16:36] 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] 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] ogasawara, i talked to herton. shank-bot will process any tracking bug regardless of series [16:38] bjf: ah sweet [16:38] herton: so if I just create a tracking bug for our devel kernels, shankbot could handle it [16:38] 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] ogasawara, yes, any bug tagged with kernel-release-tracking-bug, create-release-tracker should do it with the tasks [16:40] herton, did you resolve that firmware issue you were having with your stable kernels on that one test system (gonzo) ? [16:41] 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] 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] ogasawara, yes, that's possible [16:42] ogasawara, just send to me the list of who wants the email I'll add [16:42] herton: ack [16:43] herton, so what does that mean for how we fix that for that particular system? do we need to install another pkg? [16:43] herton, i think i'm seeing the exact same failure for mainline builds [16:44] 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] bjf, you could install the upstream linux-firmware package. that has all the firmware ever created. [16:44] rtg, ack === rudimeyer_ is now known as rudimeyer [17:04] * rtg restores some armhf config options in Raring [17:13] rtg, were you suggesting bjf install our linux-firmware package? [17:14] 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] rtg, where do i get that from? [17:15] bjf, hang on, lemme find it. [17:19] 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§ion=all . maybe copying manually for stable testing is the best route. === tyhicks` is now known as tyhicks === rudimeyer_ is now known as rudimeyer [18:23] herton, bjf: just ran create-release-tracker for Raring -> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1084640 [18:23] Launchpad bug 1084640 in linux (Ubuntu Raring) "linux: 3.7.0-5.13 -proposed tracker" [Medium,In progress] [18:24] mumble failing? [18:24] 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] ppisati, working for everyone else [18:24] s/shank// [18:24] ba [18:24] h [18:25] 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] ppisati, was working fine for us a second ago [18:25] yeah, but it keeps disconnecting [18:25] maybe it's my network [18:25] ppisati, seems stable for me [18:25] ogasawara, ah yes, I have to adapt create-release-tracker to stop subscribing SRU team etc., will do [18:26] ogasawara, it's a easy check, just see if it's set as a development kernel or not on ktl/ubuntu.py [18:27] ogra: uploaded linux-nexus7_3.1.10-8.15 to raring with kexec patches. [18:27] 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] 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] herton: yep that's correct [18:28] ok, will fix this [18:29] * rtg -> lunch [18:29] herton: awesome, thanks. no hurry on this if you have more important things to address [18:30] herton: this is one of those nice to have types of things, but not blocking or high priority by any means [18:31] ogasawara, ack, I think it'll not be too much work, probably today or monday I can have it ready [18:33] ppisati, maybe it's a sign to call it a day [18:35] ok, killed mumble now [18:36] still trying to undestand one thing, can't quit yet :P [19:02] 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] herton: ack [19:04] * henrix -> EOD [19:44] infinity: A little heads up next time you go poking around my git trees :) [19:45] I should enable email notifications for those trees [19:57] hmm, the current Raring kernel has broken my touchpad. Lenovo x120e [19:57] BenC: Hrm? Did I cause you grief somehow? [19:57] BenC: The general concept of DVCS is that when you try to push, you notice you're out-of-date. :P [19:58] rtg: You should find someone on the kernel team to look at tha-- waaaait. [19:58] infinity, actually, I was just about to consult with sforshee :) [20:01] infinity: I noticed it after I did the upload…the one time I didn't push before dput [20:01] BenC: Well done. :P [20:01] infinity: And I'm used to doing --force on linux-ppc since it's almost always a rebase [20:02] I'm not sure why github doesn't send email notifications to me…let me check my spam folder [20:03] 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] s/changed/changes/ [20:03] It usually is, so disregard my grumbling [20:03] Watch out if you ever mess with linux-ppc though [20:03] BenC: Also entertaining that the changelog now has the source package name flip-flopping. :) [20:04] rtg, what kind of touchpad? synaptics? [20:04] History must be retained :) [20:04] sforshee, thats what I'm trying to figure out. any hints ? [20:04] BenC: Anyhow, I rejected your accidental linux-ppc-meta, s'all good. [20:04] Thanks [20:05] rtg, that's a black art ;) [20:05] Oh lord, it's firefox security day. [20:05] Poor buildds. [20:05] rtg, check dmesg, if there's nothing there you'll have to boot to a kernel where it works [20:05] sforshee, searched for 'synap' to no avail [20:06] rtg, try searching for 'psmouse' [20:06] sforshee, will do as soon as this kernel is done installing. tip of master-next [20:07] rtg, ack [20:09] sforshee, hmm, 'mousedev: PS/2 mouse device common for all mice'. Is that bad ? [20:09] 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] sforshee, I have a bunch of older kernels installed. lemme see what they have to say. [20:10] rtg, it still doesn't work at all though? [20:10] sforshee, frozen [20:14] rtg, that message is actually completely generic, it will always appear even if you don't have a mouse at all [20:15] sforshee, [ 19.179331] psmouse serio4: synaptics: Touchpad model: 1, fw: 7.5, id: 0x1e0b1, caps: 0xd000b3/0x340000/0xa0400 [20:15] [ 19.179358] psmouse serio4: synaptics: serio: Synaptics pass-through port at isa0060/serio4/input0 [20:16] 3.5.0-18-generic [20:16] let the bisecting begin [20:16] rtg_, so right now all you know is that it broke between 3.5 and 3.7? [20:16] rtg, ^ [20:17] sforshee, I'm gonna try and get a little closer. I'm just sure the early 3.7 kernels worked [20:19] rtg, virtually nothing has changed in the mouse or serio code since 3.7-rc1 [20:20] 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] rtg, it _could_ be, but then you said the 3.5 kernels work [20:21] sforshee, yep [20:23] rtg, we don't have the cypress patches in raring? [20:24] sforshee, I think they clashed and got dropped. lemme chaeck for sure [20:24] rtg, the code isn't there [20:24] i was just suprised [20:24] *surprised [20:24] sforshee, kamal was working to upstream them, so I though we'd get 'em for 3.8 [20:25] 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] rtg, sforshee: the cypress driver was indeed dropped from raring [20:25] rtg, can you pastebin dmesg from a non-working kernel? [20:26] one vestige remained (an enum that should have been harmless) but rtg recently rebased that away too [20:26] sforshee, lemme reboot and get tip of master-next dmesg [20:31] sforshee, ok, its intermittent. works now with tip of master-next. warm boot. I've also tried cold booting. [20:31] sforshee, rtg@x120e:~$ dmesg |egrep -i "synap|mouse" [20:31] [ 1.800980] mousedev: PS/2 mouse device common for all mice [20:31] [ 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] [ 19.457528] psmouse serio4: synaptics: serio: Synaptics pass-through port at isa0060/serio4/input0 [20:31] [ 19.501730] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio4/input/input8 [20:31] [ 25.360441] psmouse serio5: trackpoint: IBM TrackPoint firmware: 0x0e, buttons: 3/3 [20:32] sforshee, hmm, I'll have to noodle on this tomorrow. I gotta launch. [20:32] 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] sforshee, possibly. I'll see if I can determine a pattern. [20:32] * rtg -> EOD [20:33] 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] infinity: it's unimportant from my end, so no problem [20:33] BenC: Great, thanks. === hugh__ is now known as Guest54770 [23:18] 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] luc4_mac: go ahead and paste the dmesg output with your paste-site of choice :) [23:29] myhrlin: http://pastebin.com/t1cF17Ts [23:29] myhrlin: here I plugged in a usb mouse. [23:30] myhrlin: now I tried with a usb pen drive and a usb hard disk. [23:30] myhrlin: nothing seems to be working. [23:34] 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] myhrkin: this is the output http://pastebin.com/WmiDTbqc [23:35] 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] 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] myhrlin: ok, thanks for the advice then!