[07:30] <apw> smb, moin, can you remember the bot-stop- tag name
[07:30] <apw> ppisati, moin
[07:30] <smb> apw, The thing about robots.thingy
[07:36] <ppisati> moin moin
[08:08] <apw> tseliot, i see that 3.10-rc5 kernel finally built, how did the dkms hacking go
[08:09] <tseliot> apw: I have started working on nvidia. It's going to be a rather invasive patch because of some changes in the kernel
[08:09] <apw> tseliot, nasty ...
[08:10] <tseliot> apw: yes, I have to switch to proc_create_data and proc_create, among other things
[08:11] <tseliot> I bet it will be the same for fglrx and broadcom
[12:20] <ppisati> brb
[13:10] <bjf> apw, should be bot-stop-nagging
[13:10] <apw> bjf, ta
[13:32] <rtg_> apw, any objection to uploading saucy rebased on v3.9.5 today ? 3.10-rc5 still doesn't have aufs support, so I'm not sure we should be switching over just yet.
[13:33] <apw> rtg_, none, tseliot was having some trouble too, so i thin 3.9.5 is a good place to be
[13:33] <rtg_> apw, k, I'm just about done compile and smoke testing.
[13:33] <apw> rtg_, do you want me to do it, or are you already ... ok then
[13:33] <rtg_> apw, have you tested overlayfs in 3.10 yet ?
[13:33] <tseliot> apw, rtg_: yes please, I'm not done fixing the drivers yet
[13:34] <apw> rtg_, i am playing in that sandbox right now, not tested that specific combination but that is about to be a sane test
[13:34] <infinity> BenC: You want to do some install/reboot/fiddle testing of the PPC kernels in raring-proposed on some of your hardware?
[13:34] <rtg_> apw, aufs hasn't been updated since march, so we might end up dropping it completely if it is no longer maintained.
[13:35] <apw> rtg_, they will be pleased :)
[13:35]  * infinity will mourn the loss of aufs.
[13:35] <infinity> Though, if the overlayfs/inotify argument ever amounts to anything, I might stop caring.
[13:37] <ogra_> so on the flipped container touch images i get a reboot loop on grouper (all other subarches seem to work and i can boot past the failure point using the grouper desktop kernel)  ...
[13:37] <ogra_> http://paste.ubuntu.com/5754882/
[13:39] <ogra_> i assume it is the "Warning: unable to open an initial console" that makes init die ... any obvious idea how i could get that console (without having to enable fbcon which will break the android container)
[13:40] <ogra_> (teh kernel panic happens right after run-init switched us to upstart)
[13:47] <rtg_> ogra_, I'm not seeing an FBCON option for grouper. CONFIG_FB=y and CONFIG_FB_TEGRA=y are set.
[13:47] <ogra_> well, it is there since we use it on the desktop kernel ... 
[13:48] <ogra_> might depend on something else thats off as well
[13:48] <ogra_> but fbcon isnt an option anyway 
[13:48] <ogra_> it would break the android container
[13:48] <rtg_> ogra_, does saucy grouper still work on the desktop image ?
[13:48] <ogra_> i tried randomly setting CONFIG_VT and stuff, but didnt get much further
[13:49] <ogra_> well, the kernel is the same 
[13:49] <ogra_> or at least largely ... 
[13:49] <ogra_> just different configs 
[13:49] <rtg_> ogra_, configs can make a difference
[13:50] <ogra_> so for testing i can replace zImage in the bootimg we use for touch ... indeed it fails miserably later in the boot but it gets past the panic point
[13:50] <ogra_> err, yes, i know, thats why i'm here :)
[13:50] <ogra_> obviously the -nexus7 kernel has something enabled to make it boot ... which the -grouper one is missing ... 
[13:51] <ogra_> my way to debug that is to enable options one by one and to do a test boot after a fresh build ... but thats very time consuming so i was hoping you guys have a better idea or see something thats obviously missing or so
[13:52] <rtg_> ogasawara, lemme take a stab at diffing the configs
[13:52] <ogra_> :)
[14:11] <rtg_> ogra_, there are quite a few differences. http://kernel.ubuntu.com/~rtg/config.diff 
[14:11] <rtg_> CONFIG_HW_CONSOLE looks suspicious
[14:11] <ogra_> oh, yeah
[14:47] <rtg_> ogra_, just pushed a patch to ubuntu-saucy grouper (CONFIG_VT=y). Can you give that a whirl ?
[14:47] <ogra_> sure
[14:48] <ogra_> i have a call soon, so only afterwards
[14:48] <rtg_> I'll flash my N7 with raring in the meantime to make sure it still works
[14:48] <ogra_> but i think i tried with CONFIG_VT=y alone already 
[14:49] <ogra_> CONFIG_HW_CONSOLE sounds more plausible
[14:49] <rtg_> ogra_, the whole patch has several more console options enabled
[14:49] <ogra_> ah, k 
[14:57] <tseliot> apw: does 3.9.5 have this commit? https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=80e928f7ebb958f4d79d4099d1c5c0a015a23b93
[14:58] <apw> tseliot, not obviously
[14:58] <tseliot> apw: ok, just checking
[14:59] <apw> tseliot, i cannot see it by sha reference or title, so very likely not
[14:59] <apw> tseliot, something you need
[15:00] <tseliot> apw: no, something that breaks the driver
[15:05] <Roberth1990> hello how do I get BFS and BFQ?
[15:08] <apw> Roberth1990, i suspect we need a little more context to have any hope of helping you.
[15:09] <Roberth1990> they are a part of the ck patchset for the kernel
[15:09] <Roberth1990> which is there again a part og zen and pf patchsets
[15:10] <apw> if it is part of ck, then its not something we have any trees for, you'd have to apply it yourself
[15:11] <jsalisbury> **
[15:11] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:11] <jsalisbury> **
[15:59] <apw> hallyn, yo ... bug #1098378 ... test kernels in the bug, if you could check them out and report back
[15:59] <ubot2`> Launchpad bug 1098378 in linux (Ubuntu Raring) "chroot+overlayfs seems to cause umount mis-behavior" [High,Confirmed] https://launchpad.net/bugs/1098378
[16:00] <apw> hallyn, and can you confirm this was new in raring, i think from the fix I expect it was
[16:16] <smb> Daviey, That is probably outside the scope of the meeting but if you want dkms packages checked imo its up to you to provide a list of interest. And I cannot recall "all" being agreed anywhere ever.
[16:25] <Daviey> smb: not agreed, but that is what i requested 
[16:25] <Daviey> it seems easy enough to test all, as it does a handful.
[16:25] <hallyn> apw: will look, thanks
[16:25] <Daviey> And for a test that seems really cheap to run, it seems like a good idea to the ubuntu ecosystem to do
[16:27] <smb> Daviey, Things are always easy when one has not to do it. :-P But anyway, I would say this is something the qa team will be responsible for anyway. So if they do, I won't complain.
[16:30] <Daviey> smb: it sounded like it was already in progress, from jibel.
[16:30] <smb> Daviey, It did, and plars just write that email. So we will see
[16:31] <Daviey> smb: Have you spotted complexity to it that i have blissfully sailed over?
[16:33] <ogasawara> Daviey: sorry to jump in here, but I've been chatting with jibel about automated DKMS package testing
[16:33] <Daviey> super!
[16:33] <ogasawara> Daviey: I actually have a meeting with him on thurs, he has something already prototyped for us to go through
[16:34] <smb> Daviey, To detect the build failing probably is simple enough (beside resource and time). Just the question what is done with that
[16:34] <ogasawara> Daviey: but if you can get me the list of dkms packages that your team is specifically interested in, I'll be sure they try to land on the list
[16:34] <ogasawara> Daviey: initiall, it's just getting a quick build test to ensure they still build with major version bumps of the kernel
[16:35] <ogasawara> Daviey: specific testing of the modules/packages beyond that would be something I'd consider phase 2
[16:35] <Daviey> ogasawara: Right. Just validating that the dkms packages still cleanly install sounds super.
[16:35] <ogasawara> Daviey: yep, that's my initial goal
[16:35] <Daviey> I can get a list.. but as a ubuntu developer, i'd love all to be covered :)
[16:35] <ogasawara> Daviey: indeed, and I suggested to him to to all the packages that rdepends spit out for dkms
[16:36] <Daviey> ogasawara: I will make sure I have a favoured list.
[16:36] <ogasawara> Daviey: great, thanks
[16:37] <ogasawara> Daviey: I was assuming for you guys is was something like openvs and iscsitarget
[16:37] <ogasawara> Daviey: not sure what else though
[16:37] <Daviey> someone in server raised oss4-dkms as another... not sure why i care about that.
[16:38] <Daviey> (HINT, i don't think i do)
[16:38] <Daviey> openswan module is interesting, but not demanded
[16:39] <Daviey> dahdi-dkms is a server universe package
[16:39] <Daviey> openvswitch-datapath-dkms is the priority 
[16:40] <Daviey> One of the real challenges we face is making these packages work on current development version of ubuntu, and precise (all supported kernels) concurrently 
[16:41] <smb> That oss4 may have been somehow misguided, but that sort of gets me back to the point that a list (not on irc) of interest and to what degree would help
[16:43] <infinity> ogasawara: `reverse-depends dkms` isn't a remarkably long list, I wonder if jibel could just test the lot?
[16:43] <infinity> ogasawara: Obviously, we have a priority list of what we care about fixing first, but I want to know if any of them are broken, so we can decide to fix or remove.
[16:45] <ogasawara> infinity: indeed, I was suggesting to him to just test the lot since it didn't seem incredibly large.  I've got a meeting on thurs to sync with him so I'm happy to bring up everything with him and circle back with you et al.
[16:46] <ogasawara> infinity: or I can just add you to the meeting if you wanted to sit in
[16:48] <infinity> ogasawara: You can add me, and I'll see how social I'm feeling when it rolls around. :)
[16:48] <ogasawara> infinity: ack
[16:48] <smb> infinity, and how awake... 
[16:48] <infinity> And that.
[17:01] <jsalisbury_> ##
[17:01] <jsalisbury_> ## Meeting starting now
[17:01] <jsalisbury_> ##
[17:14] <jsalisbury> Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues June 18th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
[17:22]  * ppisati -> gym
[17:25]  * rtg_ -> lunch
[17:37] <arges> has anyone here figure out how to upload .crash data from a kernel oops into a new launchpad bug? ubuntu-bug *.crash asks if I want to submit it but gives no feedback afterwards
[18:06] <arges> ok looks like bug 994921
[18:06] <ubot2`> Launchpad bug 994921 in apport (Ubuntu Quantal) "'ubuntu-bug /var/crash/app.crash' (and even more so, 'apport-cli -c /var/crash/app.crash') should still allow manual bug filing in stable releases" [Medium,Triaged] https://launchpad.net/bugs/994921
[18:23] <apw>  2291 apw        9 -11  568m 5904 4792 S 200.0  0.1  1349154h pulseaudio                       
[18:33] <BenC> infinity: Yeah
[18:45] <apw> bjf, http://people.canonical.com/~apw/unstable-saucy/
[18:45] <bjf> apw, ta
[18:47] <davmor2> apw: I'm not sure I want to work too close to you now I see you are unstable and saucy ;)
[18:48] <apw> davmor2, :)
[18:49] <infinity> BenC: Kay, I already marked it passed for regression-testing based on my own testing, but do let me know if it breaks for any of your platforms, so we can revert that. :P
[18:50] <BenC> infinity: it worked when I built it, so should be good. I'll let you know if otherwise.
[18:51] <infinity> BenC: Compiler bugs and bitflips happen.  There's also the possibility that I effed up the checkout.  Better safe than sorry. :)
[18:54] <infinity> BenC: Alternately: "It works on 750, 970, POWER5, and POWER7, so sucks to be you if your flavours don't work, nyah nyah." ;)
[20:22]  * rtg_ -> EOD