[07:53] <apw> xevious, in normal operation no you should not need to add addition sync commands
[12:23] <agm> henrix, I used your -proposed kernel
[12:23] <agm> it seems to fix the nfs issue
[12:23] <agm> how do I appropriately report my success?
[12:24] <henrix> agm: is there a 'verification-needed-trusty' tag in that bug?
[12:24] <agm> yes
[12:24] <agm> I mean, do I just say it seemed to work and tag it
[12:25] <agm> or is more information required
[12:25] <henrix> agm: then, just replace that tag by 'verification-done-trusty' :)
[12:25] <agm> Ok, I just made my launchpad.net account today
[12:25] <agm> thanks
[12:25] <henrix> agm: of course you can add more relevant info to the bug, that could eventually help other people testing
[12:25] <agm> ok, I'll describe my setup
[12:25] <henrix> agm: and thanks for testing and reporting back!
[12:26] <agm> thanks for fixing it! I just saw the issue last night, googled what I was seeing, saw the bug, and saw your fix
[12:26] <agm> fast!
[12:27] <henrix> yeah, sometimes that approach works :)
[12:36] <xnox> my processes tell me that they no longer can initialise inotify
[12:36] <xnox> did i run out of watches/discriptors, or i have something rougue running on my system, or is kernel buggy? or how do i check that?
[12:53] <agm> Do I add a tag just by appending that text to the bottom of a post?
[12:56] <agm> oh nevermind found it
[13:49] <xevious> apw: Can you think of an operation that would require manually running sync?
[13:54] <apw> xevious, a full sync, no
[14:48] <awe_> sforshee, ogasawara, can someone on the kernel team take a look at a WiFi adhoc driver bug for us?
[14:48] <awe_> https://bugs.launchpad.net/ubuntu/+source/linux-mako/+bug/1337753
[14:58] <sforshee> awe_: ugh, if android doesn't use ibss then there's a good chance that it isn't well-tested in the driver
[14:58] <awe_> yup 
[14:59] <sforshee> I'll try to take a peek at the code a little later today, but that driver makes my eyes bleed
[15:02] <awe_> sforshee, same problems with bq; although different driver
[15:03] <awe_> sforshee, this may be endemic of Android Wi-Fi drivers
[15:03] <awe_> that said, Wellark also claims that bq doesn't have "ap" support either
[15:03] <awe_> ( which is what I think we should be using for hotspot )
[15:05] <awe_> sforshee, one last comment... in the syslog, I see reference to a qcom platform drive that NM thinks is the WiFi driver;  it's not clear to me if the actual N4 WiFi driver is a blob or not...
[15:09] <sforshee> awe_: yeah, if android doesn't require ibss support then we probably need to assume that we can't rely on it when we're using those drivers
[15:11] <sforshee> awe_: I don't think the n4 wifi driver is a binary blob, but I'll double check
[15:11] <awe_> sforshee, well...the driver claims support, and without, we're missing the underlying framework to support hotspots
[15:15] <sforshee> awe_: but if android is using ap mode then that's the code that we know is tested and _should_ work, so why wouldn't we use that for hotspots instead?
[15:19] <awe_> so...we have existing code in Ubuntu to support hotspot, and it's tied to adhoc unfortunately.  I document why this isn't optimal in: https://bugs.launchpad.net/ubuntu/+source/linux-mako/+bug/1337753
[15:19] <awe_> sorry...https://bugs.launchpad.net/ubuntu/+source/linux-mako/+bug/1337753/comments/5
[15:20] <sforshee> awe_: okay ... so it's easier to go fix every android driver which has sub-par ibss support than to change our hotspot code?
[15:23] <sforshee> and based on that comment, there are other compelling reasons to use infrastructure mode rather than ibss
[15:23] <awe_> I haven't yet had this discussion with others
[15:24] <awe_> NM apparently does support AP-mode hotspot, but the discussion hasn't been had yet
[15:25] <sforshee> awe_: so as far as I can tell the options are a) continue with adhoc, create a lot of extra work, and have an overall crappy hotspot experience, or b) switch to infrastructure mode for hotspots and have fewer driver problems and a better user experience
[15:25] <sforshee> the answer seems pretty obvious to me
[15:26] <awe_> sforshee, also not all of the drivers we're interested in support ap mode
[15:26] <awe_> sforshee, it depends on how much code is involved
[15:26] <sforshee> awe_: then these same devices don't support hotspots under android I assume?
[15:27] <awe_> in theory, that's correct
[15:27] <sforshee> what about in practice?
[15:27] <awe_> ;)
[15:27] <sforshee> because if android doesn't support hotspots on those devices it seems unreasonable to demand that we should
[15:27] <awe_> agreed
[15:28] <awe_> sforshee, just asked abeato for the 'iw list' output for krillin
[15:29] <sforshee> awe_: so honestly I don't feel inclined to invest much effort at all in tring to fix adhoc on the n4 if it seems likely we'll just switch to ap mode anyway
[15:30] <sforshee> and to me that seems like the far more reasonable solution, all things considered
[15:32] <awe_> sforshee, we can't make a decision till we've looked at all the pieces...  I'd like at least some opinion from you or someone from the kernel team as to why fixing the driver is too much effort
[15:32] <awe_> it might be something obvious like building the driver with p2p support might conflict with adhoc mode
[15:33] <sforshee> awe_: okay, I'll take a look this afternoon
[15:33] <awe_> I *will* have the conversation re: adhoc mode today
[15:33] <awe_> thanks
[15:33] <awe_> don't spend a lot of time on it
[15:33] <sforshee> I don't plan to ;-)
[15:33] <awe_> cool
[15:33] <awe_> thanks much!
[17:11] <kdeuser56> how would I get the ubuntu kernel config file for a specific version from commandline?
[17:23] <infinity> kdeuser56: If you mean for the installed/running kernel, it's /boot/config-$(uname -r)
[17:23] <kdeuser56> infinity: not an installed one
[17:24] <kdeuser56> infinity: I was looking for the .config of any kernel ubuntu ever played with
[17:24] <kdeuser56> infinity: is there some archive?
[17:24] <infinity> I don't think anyone's bothered to extract the configs from every binary package and archive them, no.
[17:25] <infinity> But if you know which binary package you're interested in, you can download and unpack it.
[17:25] <infinity> Our git trees show the changes on a more granular level, but there's no .config in there, as it's broken into pieces and constructed at build time.
[18:42] <BLZbubba> hi guys, I'm trying to build 3.15.4 using "fakeroot debian/rules binary-headers binary-generic" and it builds just fine
[18:43] <BLZbubba> however, the deb only inculdes about 600 modules whereas the binary on kernel.ubuntu.com has over 3000
[18:46] <BLZbubba> i started looking at the generic inclusion list but it seems to match the one on the standard 3.13 kernel.  any idea where to look to make it include the correct set of modules in the kernel binary deb?
[18:59] <Sarvatt> BLZbubba: look in the linux-image-extra deb, if you want to build it all into one deb you'd want to fakeroot debian/rules do_extras_package=0 binary-headers binary-generic
[19:03] <trippeh> also might want to consider 3.15.5
[19:07] <BLZbubba> but there is no extras deb here: kernel.ubuntu.com/~kernel-ppa/mainline/v3.15.4-utopic/
[19:13] <BLZbubba> i'm just curious how to build the packages exactly the same way as these
[19:23] <BLZbubba> Sarvatt: you're right, extras had the missing ko files for useful things like the keyboard
[19:25] <BLZbubba> so how are they doing it differently for the images published to kernel.ubuntu.com?