=== emma_ is now known as emma
=== lifeless_ is now known as lifeless
=== RAOF_ is now known as RAOF
=== fmasi is now known as Guest20935
=== tjaalton_ is now known as tjaalton
=== ivoks_ is now known as ivoks
[08:07] <ppisati> moin world
=== psivaa_ is now known as psivaa
=== lan3y is now known as Laney
=== Laney is now known as Guest1882
=== Guest1882 is now known as Laney
[09:16] <apw> moin moin
[09:16] <ppisati> apw: moin tech lead :)
[09:16] <smb> apw, No yawn (and bees)?
[09:18]  * smb feels like lead, too :-P
[09:20] <apw> ppisati, heh thanks :)
[09:20] <apw> smb, very droll, very droll ... and man i feel like lead more than anything
[10:02] <smb> apw, Oh btw, looking at  bug 1244176... (asked already on #ubuntu-devel but not sure it had been noticed) I think the reply there would be that Saucy images won't get re-spun. I have to figure out whether netboot mini-isos are. Otherwise do you have a howto for replacing kernels in isos?
[10:02] <ubot2> Launchpad bug 1244176 in linux (Ubuntu Trusty) "Server 13.10 Install Fails with USB Keyboard (Appears to Hang)" [High,Fix released] https://launchpad.net/bugs/1244176
=== Guest20935 is now known as fmasi
[10:04] <ppisati> smb: well, after all, who is using usb keyboards nowadays?
[10:04] <ppisati> couldn't resist sorry... :P
[10:05] <smb> ppisati, Just about everyone... :-P But I guess the secret also is whether they are coming in through usb2 or 3... or actually i think there was ehci and ohci for usb1... 
[10:05] <pkern> ppisati: People that use remote KVMs?
[10:06] <smb> Yeah those too
[10:06] <smb> But ppisati just "forgot" the sarcasm tags
[10:06] <ppisati> i was ironic dude...
[10:08] <pkern> I thought you'd argue that everybody installs within virtualization nowadays. :P
[10:11] <smb> It was unfortunately ambiguous. :) But true, I think it was a mix of reporters doing installs on physical hw with the "wrong" usb keyboard type and those doing remote kvm installs. Like I did but just was lucky that the remote just means basement to me and there the machine has a ps2 keyboard... :-P
[10:30] <smb> Ah, ok, not that it matters much but ohci and uhci where usb1 drivers... So that explains a bit why this was not hurting more people...
[10:31] <apw> i assume the simplest work around here is to install raring and upgrade to saucy instead
[10:35] <smb> Hm, yeah might be some other way... maybe not the most elegant but working
[11:14] <eagles0513875> apw: are you around? there was a post to bug #+
[11:14] <eagles0513875> whoops
[11:14] <eagles0513875> bug #967399
[11:14] <ubot2> Launchpad bug 967399 in linux (Ubuntu) "[11.10] Elantech trackpoint does not work Lenovo " [High,In progress] https://launchpad.net/bugs/967399
[11:15] <eagles0513875> another person was asking if this was going to get pushed to an SRU in terms of the kernel. Nobody else seems to have responded about this patch making it upstream
[11:16] <apw> eagles0513875, has anyone followed up on the upstream email thread do you know?
[11:17] <eagles0513875> apw: nobody that im aware of as nobody filed a comment on that bug
[11:17] <eagles0513875> is there an upstream bug filed for this issue?
[11:19] <apw> eagles0513875, mostly they just use the mailing lists as they 'issue tracker'
[11:20] <eagles0513875> im not subscribed there.
[11:20] <eagles0513875> can we at least get this backported and then for 14.04 have a push for it to be in mainline
[11:20] <apw> i have added some clarification on the position to the bug so everyone knows
[11:21] <eagles0513875> apw: thanks :) do you have any reference to what thread it was so i can revivie it or just start another one.
[11:22] <eagles0513875> apw: stupid question i cant seem to sign up wiht their mailing list
[11:23] <eagles0513875> http://vger.kernel.org/
[11:25] <eagles0513875> apw: what list should i subscribe to
[11:32] <apw> http://www.spinics.net/lists/linux-input/msg26869.html is the list it is on i think
[11:35] <eagles0513875> ok apw subscribed there. and will send an email to the mailing list
[11:36] <apw> eagles0513875, ask avout that specific patch
[11:36] <eagles0513875> will do
[11:40] <eagles0513875> apw: what is the address to send to the list
[11:41] <apw> its on the subscribe page i think
[11:42] <eagles0513875> http://vger.kernel.org/vger-lists.html  all im seeing are the links to archives
=== rbasak_ is now known as rbasak
[13:00] <apw> linux-input@vger.kernel.org is the main list send, linux-input-request to join i thiknk
[13:16] <rtg> apw, I updated a Lenovo laptop yesterday with 3.13 and it now cannot find the SSD. Stupidly I did not have an alternate version to make sure it really isn't HW failure. I'm checking that out this morning.
[13:17] <rtg> a different laptop with the same SSD (although larger) works fine.
[13:20] <apw> rtg, well that is typical isn't it
[13:20] <smb> rtg, If that isn't one of these fastboot ones, you could check whether the ssd at least appears as a boot selection in the bios
[13:21] <rtg> smb, good idea.
[13:21] <apw> when you say canot find it, who says that?  the kernel
[13:21] <apw> ?
[13:21] <apw> if so you know bios and grub found it
[13:22] <rtg> yeah, the BIOS finds the drive 'cause grub loads and launches the kernel. it drops to busybox after awhile because it could not mount the rootfs
[13:22] <apw> ok then not completely gone
[13:22] <smb> apw, Typically it would be if it happened when we are traveling
[13:22] <apw> does dmesg have any indication of the device
[13:22] <smb> Yeah, better than my state last time
[13:22] <apw> smb, heh yeah
[13:23] <rtg> checking dmesg.
[13:24] <rtg> hmm, dmesg|grep sd shows nothing
[13:24] <apw> what version did you have before the update i wonder
[13:25] <rtg> 3.13.0-13 I think. what is the one I just uploaded ?
[13:25] <rtg> that is the one that isn't booting
[13:25] <apw> -0.15
[13:25] <smb> rtg, anything grepping for ata
[13:25] <apw> so i think that is -rc5 -> rc7
[13:26] <rtg> apw, nothing about ata except false positives.
[13:27] <smb> Interesting, so not even found the controller
[13:27] <rtg> I'll boot the daily as soon as  its done flashing.
[13:30] <rtg> it doesn't help that I left the charger 100 miles away. doh! hopefully I've still got enough battery.
[13:30] <apw> rtg, it is one of those days for sure
[13:31] <rtg> tuesday is the new monday
[13:32] <smb> It might be a bit far fetched but at some point there was some discussion/patch that partially reverted fiddling with some bus master bit (iirc) when not doing kexec. Not sure but maybe the good old, remove battery and wait a bit trick works here
[13:34] <rtg> smb: can't hurt to try
[13:40] <rtg> smb, no joy on pulling the battery
[13:40] <smb> smb, ok, so at least not that. hm
[13:41] <rtg> I'm just reinstalling from the daily first, then I'll get 3.13 on it.
[13:43] <smb> During the install you could check lspci -vvvnn and see which driver the SATA controller is attached to (I guess ahci)
[13:44] <smb> Not that we forgot some vital other driver in the initrd
=== n0u is now known as nou
[13:49] <eagles0513875> apw: their mailing list setup is so complex holy cow
[13:51] <eagles0513875> apw: how do i send it to the proper list once im subscribed? 
[14:02] <apw> linux-input@vger.kernel.org is the main list send address
=== ricmm|sick is now known as ricmm
[14:40] <rtg> smb, apw: reinstalled from the daily, updated to 3.13-rc7. now everything works. wtf ?
[14:43] <apw> rtg, these things are sent to try us and no mistake
[14:44] <apw> rtg, oh do you have any dkms packages installed ?
[14:44] <rtg> apw, nope, it was pretty much stock
[14:44] <apw> rtg, as we have been ignoring abi on these kernels which has been causing me issues
[14:44] <apw> rtg, not even for testing?
[14:44] <apw> like vbox or similar
[14:44] <rtg> not on my travel laptop
[14:44] <apw> then it is a mystery indeed
[14:58] <smb> rtg, what driver does the disk use (I may have missed it)? I could only think of a case where initrd was misbuild
[14:58] <rtg> smb, checking
[15:02] <rtg> smb, [    2.765203] ata1: SATA max UDMA/133 cmd 0x2148 ctl 0x215c bmdma 0x2060 irq 19
[15:02] <rtg> [    4.112147] ata1.01: failed to resume link (SControl 0)
[15:02] <rtg> [    4.268151] ata1.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[15:02] <rtg> [    4.268168] ata1.01: SATA link down (SStatus 0 SControl 0)
[15:02] <rtg> [    4.327579] ata1.00: ATA-8: TOSHIBA MK5065GSXF, GP006B, max UDMA/100
[15:02] <rtg> [    4.327599] ata1.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 0/32)
[15:02] <rtg> [    4.332543] ata1.00: configured for UDMA/100
[15:03] <smb> rtg, looking in "lspci -vvvnn" for SATA should yield which module is used
[15:03] <smb> or driver
[15:05] <rtg> smb: oops, wrong dmesg. this one is 'ata1.00: ATA-9: Samsung SSD 840 EVO 120GB, EXT0BB0Q, max UDMA/133'. lspci says 'Kernel driver in use: ahci'
[15:07] <smb> Ah ok ahci then. I would think that one should be built-in
[15:07] <rtg> CONFIG_SATA_AHCI=m
[15:07] <smb> hm... ok not. :P
[15:07] <rtg> maybe it was just an initrd problem
[15:08] <infinity> It's been =m for ages.
[15:08] <infinity> But yeah, mismatched initrds or some other wonkiness would make that blow up.
[15:09] <rtg> its possible. we've been ignoring ABI changes
[15:52] <jsalisbury> **
[15:52] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:52] <jsalisbury> **
[16:56] <jsalisbury> ##
[16:56] <jsalisbury> ## Kernel team meeting in 5 minutes
[16:56] <jsalisbury> ##
[17:16] <xnox> \o/ 3.13 \o/ 
[17:16] <rtg> xnox, its coming. gimme a bit
=== jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues January 14th, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
[17:17] <xnox> rtg: as soon as it lands, i'd want some config changes to be ported to nexus kernels to match the distro configs ;-) maybe after some user testing / 3.13 landing in release pocket + some time.
[17:17] <rtg> dang, forgot the meeting
[17:17] <tseliot> rtg: I haven't updated the binary drivers yet, just FYI
[17:18] <rtg> tseliot, so you're kinda behind the eight ball
[17:18] <tseliot> right :)
[17:19] <rtg> tseliot, I imagine it'll take at least another day to propagate through the archive
[17:20] <tseliot> rtg: I'll try to finish fixing at least nvidia 331 tomorrow
[17:31]  * ppisati -> EOD
=== davmor2_ is now known as davmor2
=== stgraber_ is now known as stgraber
[18:32] <medberry> infinity, does the raring kernel in precise lose support on January 27th? linux-generic-lts-raring-eol-upgrade?
[18:33] <medberry> metadata in that package shows:
[18:33] <medberry> Supported: 18m
[18:34] <_bjf> medberry, no, we support it until 14.04.1
[18:34] <medberry> _bjf, cool Thanks.
[18:34] <medberry> https://wiki.ubuntu.com/Kernel/LTSEnablementStack says the same.
=== _bjf is now known as bjf
[18:34] <pkern> _bjf: Will there be any overlap for the saucy kernel where saucy and trusty are supported?
[18:35] <bjf> pkern, same deal .. the lts-backport-saucy kernel will be supported until 14.04.1
[18:35] <pkern> bjf: So that's a "no" then.
[18:35] <pkern> Annoying.
[18:36] <medberry> pkern, .1 comes after the dot nothing
[18:36] <medberry> so a bit of overlap
[18:36] <bjf> pkern, 14.04.1 is the first point release which is after 14.04
[18:36] <pkern> Hm.
[18:36] <bjf> pkern, so yes, there is overlap
[18:36] <pkern> So the trusty stack comes with a 12.04 point release.
[18:37] <pkern> How much later will the first trusty point release be?
[18:37] <bjf> pkern, one sec ..
[18:38] <bjf> pkern, it's about 3 mo. after the initial release
[18:39] <pkern> So the 12.04.x after 14.04 will come about 1 mo. later and saucy+trusty will be supported together for about 2 then?
[18:39] <pkern> Just to get the timeline straight.
[18:39] <pkern> Because the picture on LTS Enablement Stack is different and suggests a hard transition from saucy to trusty.
[18:41] <bjf> pkern, 14.04 (april 17)  14.04.1 (around end of aug.)  lts-backport-saucy will end support around end of aug. when 14.04.1 comes out
[18:41] <pkern> bjf: Thanks.
[18:41] <bjf> pkern, np
[18:42] <pkern> Oh hm. So no overlap then because it's only then when the trusty kernel hits precise?
[18:42] <pkern> Because August is also the line on that picture.
[18:43] <bjf> pkern, the lts-backport-trusty kernel for precise will be out about a week after 14.04 release
[18:44] <pkern> bjf: But without installer support?
[18:44] <bjf> pkern, if you mean that it there isn't a point release that has it as the default, you are correct
[18:45] <pkern> Well, it might as well miss the necessary installer bits in proposed.
[19:01] <xnox> pkern: we rebuild d-i shortly after lts-backport landing, and one has all installer bits / images in precise/daily generated.
[19:02] <xnox> pkern: although we will not cut .5 isos, there is no reason to not have d-i / netboot available with lts-backport-trusty kernel.
[19:04] <pkern> xnox: Ok, thanks, I guess that's something we can test, then.
=== manjo` is now known as manjo