| jsalisbury | bjf, I added locking to the auto-reports-mako job on people by using flock. I'll do the same on cranberry. | 00:55 |
|---|---|---|
| hggdh | infinity: quantal armadaxp done, should be ready for you soon | 01:13 |
| infinity | hggdh: \o/ | 01:15 |
| infinity | hggdh: precise tonight too, or will that be tomorrow? | 01:15 |
| 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:16 |
| hggdh | infinity: I understand, np there. Just giving you a bit more of data | 01:17 |
| * infinity nods. | 01:17 | |
| 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:18 |
| 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:21 |
| 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. | 01:22 |
| === 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 | ||
| 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.. | 10:51 |
| apw | Konstigt, "including all files" ? | 12:28 |
| 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:29 | |
| rtg | apw: I've been getting some weird PPA build failures lately. That lib/oid thingy. Restarting typically fixes it. | 12:30 |
| apw | rtg, got an example | 12:57 |
| * 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:01 |
| 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:02 |
| 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:03 |
| apw | rtg, :) | 13:06 |
| === yofel_ is now known as yofel | ||
| === 20WABM4XS is now known as jussi | ||
| === jussi is now known as jussi01 | ||
| === jussi01 is now known as jussi | ||
| rtg | ogra: is it safe to upgrade my N7 to Raring ? Thought I'd do taht before testing the kexec kernel patch. | 14:49 |
| ogra_ | rtg, well, you lose unity | 14:52 |
| 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:53 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| rtg | I'm not sure there is a platform device for SDIO that emits discovery events | 14:59 |
| ogra_ | oh, intresting, putting "noinitrd rootwait" on the nexus cmdline lets me end up in the ubuntu initrd :P | 15:03 |
| ogra_ | but at least i get a shiny splash before that happens | 15:06 |
| bjf | brendand, are my Precise and Quantal kernels going to get their testing finished today ? | 15:34 |
| brendand | bjf - absolutely | 15: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:36 |
| 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:37 |
| 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:38 |
| herton | ogasawara, yes, any bug tagged with kernel-release-tracking-bug, create-release-tracker should do it with the tasks | 16:39 |
| bjf | herton, did you resolve that firmware issue you were having with your stable kernels on that one test system (gonzo) ? | 16:40 |
| 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:41 |
| herton | ogasawara, just send to me the list of who wants the email I'll add | 16:42 |
| ogasawara | herton: ack | 16:42 |
| 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:43 |
| 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 | 16:44 |
| === rudimeyer_ is now known as rudimeyer | ||
| * rtg restores some armhf config options in Raring | 17:04 | |
| herton | rtg, were you suggesting bjf install our linux-firmware package? | 17:13 |
| 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:14 |
| bjf | rtg, where do i get that from? | 17:15 |
| rtg | bjf, hang on, lemme find it. | 17:15 |
| 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§ion=all . maybe copying manually for stable testing is the best route. | 17:19 |
| === tyhicks` is now known as tyhicks | ||
| === rudimeyer_ is now known as rudimeyer | ||
| 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:23 |
| 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:24 |
| 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:25 |
| herton | ogasawara, it's a easy check, just see if it's set as a development kernel or not on ktl/ubuntu.py | 18:26 |
| 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:27 |
| ogasawara | herton: yep that's correct | 18:28 |
| herton | ok, will fix this | 18:28 |
| * rtg -> lunch | 18:29 | |
| ogasawara | herton: awesome, thanks. no hurry on this if you have more important things to address | 18:29 |
| ogasawara | herton: this is one of those nice to have types of things, but not blocking or high priority by any means | 18:30 |
| herton | ogasawara, ack, I think it'll not be too much work, probably today or monday I can have it ready | 18:31 |
| bjf | ppisati, maybe it's a sign to call it a day | 18:33 |
| ppisati | ok, killed mumble now | 18:35 |
| ppisati | still trying to undestand one thing, can't quit yet :P | 18:36 |
| 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:02 |
| * henrix -> EOD | 19:04 | |
| BenC | infinity: A little heads up next time you go poking around my git trees :) | 19:44 |
| BenC | I should enable email notifications for those trees | 19:45 |
| 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:57 |
| 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 :) | 19:58 |
| 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:01 |
| BenC | I'm not sure why github doesn't send email notifications to me…let me check my spam folder | 20:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| sforshee | rtg, ack | 20:07 |
| 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:09 |
| 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:10 |
| sforshee | rtg, that message is actually completely generic, it will always appear even if you don't have a mouse at all | 20:14 |
| 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:15 |
| 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:16 |
| rtg | sforshee, I'm gonna try and get a little closer. I'm just sure the early 3.7 kernels worked | 20:17 |
| sforshee | rtg, virtually nothing has changed in the mouse or serio code since 3.7-rc1 | 20:19 |
| 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:20 |
| sforshee | rtg, it _could_ be, but then you said the 3.5 kernels work | 20:21 |
| rtg | sforshee, yep | 20:21 |
| sforshee | rtg, we don't have the cypress patches in raring? | 20:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:31 |
| 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:32 | |
| 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. | 20:33 |
| === hugh__ is now known as Guest54770 | ||
| 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:18 |
| myhrlin | luc4_mac: go ahead and paste the dmesg output with your paste-site of choice :) | 23:28 |
| luc4_mac | myhrlin: http://pastebin.com/t1cF17Ts | 23:29 |
| luc4_mac | myhrlin: here I plugged in a usb mouse. | 23:29 |
| 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:30 |
| 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:34 |
| 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:35 |
| luc4_mac | myhrlin: ok, thanks for the advice then! | 23:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!