[00:06] <arrith> the kernel freeze is coming up and i would like to help fix Bug #1287966: "DisplayLink USB Graphics not supported by Ubuntu Kernel" before it passes, or find out that it's no longer a bug. the bug link is: https://bugs.launchpad.net/ubuntu/+source/linux-lts-saucy/+bug/1287966 (and a related blog post: http://plugable.com/2014/03/06/displaylink-usb-2-0-graphics-adapters-on-linux-2014-edition ).
[00:06] <ubot2> Launchpad bug 1287966 in linux-lts-saucy (Ubuntu) "DisplayLink USB Graphics not supported by Ubuntu Kernel" [Undecided,Confirmed]
[00:07] <arrith> would it be better to post about investigation into that on a bug, on the ubuntu kernel mailing list, here in the irc channel, or somewhere else?
[00:13] <jtn> apw: would it be useful to add my Wacom success report to bug 1293725, or is that for your own use?
[00:13] <ubot2> Launchpad bug 1293725 in linux (Ubuntu Trusty) "linux: 3.13.0-18.38 -proposed tracker" [Medium,Fix released] https://launchpad.net/bugs/1293725
[00:15] <bjf> jtn, that's just for internal tracking
[00:18] <jtn> OK. Well, it doesn't much matter, since it all works and no-one need do anything. Just wanted to share the \o/
=== gerald is now known as Guest99253
[04:17] <stag019> what are the odds that ubuntu 14.04 gets linux kernel 3.14 over 3.13?
[04:18] <antarus> I'm not on kernel team, but my impression was that the odds were 'none'
[04:20] <stag019> news articles from mid february keep mentioning they've been toying with 3.14
[04:21] <antarus> yeah they have weekly kernel meetings, I wonder if they publish minutes
[04:21]  * antarus only pays a brief sort of attention
[04:22] <antarus> https://wiki.ubuntu.com/KernelTeam/Meeting
[04:22] <antarus> maybe check there?
[04:22] <stag019> was just reading that as you mentioned it :P
[04:23] <stag019> The 3.13.0-15.35 Trusty kernel is available in the archive. This is bssed on the v3.13.5 upstream stable update. Our unstable branch has also been rebased to track the latest v3.14-rc5 release. 
[04:23] <stag019> from 3/3
[04:23] <antarus> other than that, hide out here and eventually someone will wake up and answer for real ;)
[04:25] <stag019> im pretty sure it would have to be out of rc before the kernel freeze on april 3rd, but if that happens i wonder how much time theyd need to test it
[07:13] <UserError> Trying to get all the ARM bloat removed before then
[07:38] <ppisati> yo
[08:21] <apw> stag019, none, the kernel will be 3.13 based, unstable is just our branch for the next release
[08:24] <stag019> thats a shame; is there any way any small patches from 3.14 could be backported in time for 14.04? particularly since it's a long term release
[08:26] <apw> stag019, you have to pick something, and for an lts we are always more conservative.  there are lots of fixes being backported, mostly via stable upstream
[08:27] <stag019> where would i be able to check if the particular fix i had in mind has already been backported and if it isnt, where could i suggest it?
[08:28] <apw> you could look in our git repo, or you could tell me the sha1 of that fix upstream
[08:29] <apw> if it isn't you would need to file a bug, and put the details in there, and tell us the bug #
[08:34] <apw> stag019, ^
[08:41] <stag019> okay yeah i just checked it it's still bugged; where would i file a bug report?
[08:43] <stag019> https://launchpad.net/ubuntu/+source/linux
[08:43] <stag019> there?
[08:45] <apw> stag019, yes, and include the sha1 of the fix, and once it is filed let us know here the bug#
[09:08] <stag019> submitted: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1295032
[09:08] <ubot2> Launchpad bug 1295032 in linux (Ubuntu) "3840x2160 fails with 30Hz with HDMI" [Undecided,New]
[09:39] <apw> tseliot, if you have any contact with the nvidia tester for that thing you refered to me for saucy, you might poke them else it will languish
[09:40] <tseliot> apw: I'll send him an email, thanks
[09:45] <tseliot> apw: ok, email sent. Hopefully we'll get feedback soon
[10:37] <apw> stag019, test kernels in the bug
[10:38] <apw> "there are test kernels in the bug" rather than "TEST NOW"
[12:39] <henrix> rtg: did you received any feedback from Dan on the ioat patches backport?
[12:39] <henrix> rtg: they definitely seem to be stable material
[12:39] <henrix> rtg: but i was holding queuing them for 3.5 stable to see if he replies to your email
[12:40] <rtg> henrix, nope
[12:40] <henrix> rtg: ok, cool. i'll wait a few more days
[12:40] <rtg> but I agree, they do seem like stable material.
[12:40]  * henrix can't hold them for too long as next 3.5 release will be the last one ;)
[12:41] <rtg> henrix, I've been able to test the ioat driver on real HW. I don't know for sure that code gets used, but it doesn't seem to have broken anything.
[12:42] <henrix> rtg: and the feedback on the bug report seems to be positive as well
[12:42] <henrix> rtg: i'll probably just reply to your email adding some more pression on the author :)
[12:43] <rtg> henrix, I forgot to look if my tester posted some results.
[12:43] <henrix> rtg: he did
[12:43] <rtg> henrix, what is that bug number ? 
[12:43]  * apw imagines henrix putting the reported in a "pression" a cafetiere/french press
[12:44] <henrix> rtg: bug #1291113
[12:44] <ubot2> Launchpad bug 1291113 in linux (Ubuntu Quantal) "Intel igb driver infinite loop in ksoftirqd, uses 100% of cpu 0" [Undecided,In progress] https://launchpad.net/bugs/1291113
[12:45] <rtg> henrix, based on his test feedback I'm gonna propose those patches for SRU
[12:45] <henrix> rtg: ack
[12:46] <henrix> apw: i guess i meant 'pressure'...? :)
[12:58] <apw> henrix, probabally, the the vision you gave me was much nicer
[12:58] <henrix> :)
=== cmagina-away is now known as cmagina
[13:32] <caribou> anyone of you having problems with Mumble's Push To Talk (PTT). Can't seem to get it to work anymore
[13:32] <caribou> I know if OT here, but many people here use Mumble
[15:26] <apw> caribou, is working for me on T
[15:27] <caribou> apw: yeah, working for many others I checked with, but thanks for checking
[15:38] <rtg> sforshee, do you have the iwlwifi bits in a branch somewhere ?
[15:38] <sforshee> rtg: no but I can push them real quick
[15:38] <rtg> sforshee, thanks
[15:40] <sforshee> rtg: git://kernel.ubuntu.com/sforshee/ubuntu-trusty.git iwlwifi-fw-dump
[17:15] <rtg> sforshee, /home/rtg/ukb/trusty/armhf/master-next/ubuntu-trusty/drivers/net/wireless/iwlwifi/mvm/debugfs.c: In function 'iwl_dbgfs_fw_error_dump_release':
[17:15] <rtg> /home/rtg/ukb/trusty/armhf/master-next/ubuntu-trusty/drivers/net/wireless/iwlwifi/mvm/debugfs.c:180:2: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration]
[17:15] <rtg>   vfree(file->private_data);
[17:16] <rtg> sforshee, Its probably safe to just disable iwlwifi for armhf
[17:20] <infinity> rtg: In theory, iwlwifi could run on armhf fine, if you find an armhf device with a minipci header.
[17:20] <infinity> rtg: (ie: fixing the bug would be better, but disabling it probably won't bite us anytime soon)
[17:21] <rtg> infinity, it won't run for shit if the kernel doesn't compile, but that is a different problem. I'm looking into it.
[17:22] <smoser> hey.
[17:22] <smoser> http://paste.ubuntu.com/7126278/
[17:22] <smoser> i think that errored because the package installation says that my cpu is not right for this deb.
[17:22] <smoser> but i do not care about that.
[17:22] <smoser> is there a way to make it not fail ?
[17:22] <infinity> rtg: I do think we need to do an audit of all the PCI/USB/etc devices that are disabled on ARM kernels and sort out why, as we're probbaly only a generation away from ARM machines that people will want to hang random devices off of.  But I'd agree that "just disable the silly thing" is the easiest way out right now, if finding the midding prototype proves to cross some arch/* boundaries or something equally intractable.
[17:23] <infinity> s/midding/missing/
[17:23] <rtg> infinity, vfree _should_ exist for armhf. I'll figure it out.
[17:24] <infinity> smoser: What's that's saying is that you don't have /proc mounted.  Why?
[17:25] <infinity> smoser: Expecting any package installation to work without all the right virtual fielsystems mounted is a crapshoot.
[17:26] <jtn> rtg: (Just FYI, I tested a Trusty daily cdimage with the Wacom Intuos fix you pushed, and my tablet Just Worked. Thanks again.)
[17:27] <smoser> infinity, i can mount /proc. but thats not what it says is the error.
[17:27] <infinity> smoser: It does if you read up.
[17:28] <infinity> smoser: As in, the line immediately above the one you're talking about.
[17:28] <smoser> no. it comlains it can't find proc. 
[17:28] <infinity> ... which is how it's checking the CPU caps.
[17:28] <smoser> suppose I *did* hav proc, and it did not find pae
[17:28] <smoser> i dont want it to fail then
[17:28] <smoser> i dont care if it can't run.
[17:29] <infinity> I can only assume this is mostly hypothetical, as I doubt you're doing this on a system without PAE.
[17:30] <infinity> Especially since it's amd64.
[17:32] <smoser> whether or not that is the caes, isnt' it generally bad packaging to fail the install ?
[17:33] <smoser> because the thing wont run.
[17:33] <infinity> smoser: No.  The preinst is there intentionally to stop you from shooting yourself in the foot on upgrade.
[17:34] <infinity> I suppose they could add an "IDONTCAREABOUTPAE" environment check or something, but in your case, mounting /proc will fix your issue, which you should be doing anyway.
[17:34] <infinity> And the number of people who would legitimately need IDONTCAREABOUTPAE would be vanishingly tiny.
[17:34] <infinity> Since the usecase here for you is "building images to run on another system", and the odds of someone running an image builder on a PPro from 1996 seem slim.
[17:35] <smoser> for this specific case, yes.
[17:36] <infinity> The only other legit case I can think of is that batch of PentiumMs that had PAE but didn't advertise it.
[17:36] <infinity> And I think there's a kernel hack for that.  Not sure if we carry it.  But the preinst could perhaps check for that model/stepping and not scream.
[17:37] <infinity> (It's a bit icky, though, as not every CPU in that class had PAE, just some subset)
[17:37] <smoser> i really dont care about the specifics. i thikn its generally wrong to fail thepackag install.
[17:37] <smoser> apt-get install webcam-software
[17:38] <smoser> E: you do not have webcam plugged in. sorry.
[17:38] <infinity> smoser: It's genuinely not wrong in a case like this.  preinst checks to stop you from hosing your system are rare, but an entirely appropriate use of preinst.
[17:38] <infinity> smoser: "You don't have a webcam" is entirely different from "after you do this upgrade, rebooting your system WON'T WORK".
[17:40] <smoser> its really not that different.
[17:40] <infinity> If it's any small consolation, we can drop that check in 14.10
[17:40] <smoser> because that isn't the case
[17:40] <infinity> smoser: That's absolutely the case.  On upgrade from precise to trusty, if you have a non-pae machine with linux-generic installed, you'll get a linux-generic that doesn't boot on your computer.  Refusing the upgrade is better than breaking the computer.
[17:41] <smoser> "after you do this upgrade, rebooting your system WON'T WORK... until you pick the old kernel that is still perfectly happiliy installed there (and may even be a newer version than this one to grub)"
[17:41] <infinity> Yes, because every user knows how to enter grub and ask for a different kernel.
[17:42] <infinity> (And the old kernel will definitely not be earlier in the list, we reverse sort on version for a reason...)
[17:42] <smoser> i didn't upgrade
[17:42] <smoser> i installed a package
[17:42] <smoser> the package had no context as to whether or not it would be booted.
[17:42] <infinity> Yeahp.
[17:42] <smoser> anyway.
[17:43] <smoser> thanks for arguing. 
[17:43] <infinity> You didn't upgrade.  But the kernel ABI changes meaning every kernel is a new package means it's pretty hard to detect upgrade versus install.
[17:45] <sforshee> rtg: I doubt anyone uses intel wireless with arm, though surely vfree exists for arm. Probably just an include which is needed.
[17:45] <sforshee> rtg: I'll look into it in a few minutes, attending to another fire drill right now
[17:46] <infinity> sforshee: Yeah, I doubt anyone uses it currently either, but they could.  There are ARM devices with PCI busses, and some with minipci, so it's possible, just not likely.
[17:46] <infinity> (But I've run e1000 NICs on powerpc, for instance, so assuming "Intel" == "x86", is usually a bad assumption)
[17:48] <hallyn> apw: do you know if the kernel in canonical-kernel-team ppa for precise would have http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-trusty.git;a=commitdiff;h=bdb820eab084eb94fc098fe7154deb0a5a8a75b6 ?
[17:49] <hallyn> i mean...  i assume not.  if not, can i do something to kick off a ne wbuild?
[17:49] <apw> hallyn, are you asking if the P kernel has that ?
[17:49] <sforshee> rtg: #include <linux/vmalloc.h>
[17:50] <hallyn> apw: no, the kernel in the canonical-kernel-team ppa
[17:50] <hallyn> no, that's quite old isn't it.
[17:50] <apw> but in the 3.2.0-* versions ?
[17:50] <hallyn> no, 3.13
[17:50] <apw> we have about 5 kernels in P
[17:51] <apw> so you are asking if the lts-backport-trusty has it?
[17:51] <hallyn> actually i should have just gotten a newer kernel from stgraber's ppa - i'm going to reboot and see
[17:51] <hallyn> yeah i guess that was my q:)
[17:52] <apw> what version is it
[17:52] <hallyn> 3.13.0-8-generic #28~precise1-Ubuntu SMP Tue Feb 11 18:53:36 .  so obviously not.
[17:52] <UserError> eol meta is the best from that ppa
[17:52] <hallyn> rebooting, biam
[17:52] <UserError> i think they are on 18
[18:00] <apw> m == month seemingly
[18:03] <apw> hallyn (not), it is -18 in the PPA as is the associated meta, so no idea why you have -8, and -17 had the commit you wanted in it
[18:03] <infinity> apw: If hally ever comes back, teach him how to use --contains.
[18:03]  * infinity was JUST going to mention that it was in -17...
[18:04] <apw> no idea where he got his -8 from even
[18:04] <infinity> apw: I assume from the PPA long ago, and then never upgraded. :P
[19:36] <apw> hallyn, it is -18 in the PPA as is the associated meta, so no idea why you have -8, and -17 had the commit you wanted in it
[19:53] <phillw> Hi, I've successfully made (with a lot of help) a non-pae kernel for 14.04 community respin. I generate the .deb files using 'make deb-pkg' but it seems a PPA cannot import ready made .deb files. Could someone please give me a link so that I can add and maintain the kernel during 14.04.
[19:54] <cristian_c> Hi
[19:54] <cristian_c> I've opened this bug report much time ago: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/972604
[19:54] <ubot2> Launchpad bug 972604 in linux (Ubuntu) "168c:001c [HP Compaq Presario C700 Notebook PC] Wireless led button doesn't switch colors" [Low,Triaged]
[19:54] <cristian_c> I've to open an upstream bug report
[20:00] <cristian_c> there is this wiki page: https://wiki.ubuntu.com/Bugs/Upstream/kernel
[20:00] <cristian_c> I've read it, but I've got some doubts:
[20:01] <cristian_c> for example: Please take care that when you provide the below information, you should be booted into the newest available upstream mainline kernel only. Failure to do this will have negative unintended consequences.
[20:01] <cristian_c> What kernel does it refer to, exactly?
[20:02] <apw> the latest linus' kernel, we build upstream kernels for that, but you know that cause we said that last time 
[20:03] <cristian_c> ok
[20:03] <cristian_c> apw, this:  http://kernel.ubuntu.com/~kernel-ppa/mainline/ ?
[20:04] <cristian_c> apw, http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.14-rc7-trusty/ ?
[20:09] <cristian_c> apw, And then: While booted into the newest mainline kernel only describe how the bug is reproducible in the latest mainline kernel only. If this is a regression, please note the specific commit. 
[20:09] <cristian_c> How can I find the commit?
[20:10] <cristian_c> Any ideas?
[20:19] <phillw> hi folks. I've had my question answered, to use 'debuild -S -sd' which was what I thought I needed :)
[20:30] <cristian__c> Has anyone answered to me?
[20:33] <cristian__c> uhm
=== cristian__c is now known as cristian_c
[20:47] <rtg> dannf, so, all of your x-gene crack is merged into master-next. please give it a spin.
[20:48] <dannf> rtg: awesome
=== cmagina is now known as cmagina-away
=== marrusl is now known as marrusl_afk
=== marrusl_afk is now known as marrusl