[05:37] <hyperair> bleh i just tried creating a nonpae build, but the package build is failing with ls: cannot access ../linux-image-3.11.0-15-generic-nonpae_3.11.0-15.23_i386.deb: No such file or directory
[05:37] <hyperair> =\
[05:38] <hyperair> weird
[05:38] <hyperair> how does one introduce a new kernel flavour?
[06:22] <hyperair> aha, debian.master/rules.d/i386.mk
[06:22] <hyperair> dat elusive flavours variable
[07:19] <hyperair> oh gawd ccache, why won't you play properly with sbuild
[16:32] <jsalisbury> ##
[16:32] <jsalisbury> ## Kernel team meeting in 30 minutes
[16:32] <jsalisbury> ##
[16:34] <kdub> sforshee, i'm trying to tighten up/fix bugs around turning the phone's display on/off (from mir's perspective), and i'm trying to get some insight into powerd... would you be the one to bounce questions off of?
[16:36] <sforshee> kdub: I can try, but if the questions are specifically about the integration with unity8 then ricmm is the one who worked on that
[16:38] <kdub> sforshee, okay
[16:40] <kdub> sforshee, so you wouldn't know if its a hard guarantee that the system is active (out of suspend) before powerd goes and requests the display on?
[16:40] <sforshee> kdub: the system can't really request the display on if suspended ...
[16:41] <sforshee> kdub: if you're talking about autosuspend, then the answer is that autosuspend is disabled before powerd would request the display on
[16:42] <sforshee> however, there's one possible issue that I can warn you about
[16:42] <kdub> i don't really know the terminology very well in this area... to me there's 'system on' or 'system off'
[16:42] <kdub> and 'system off + mir attempting to display a frame == bad'
[16:42] <kdub> :)
[16:42] <sforshee> so here's the case which might be problematic
[16:43] <sforshee> android uses this file in sysfs, I don't recall the exact path off the top of my head, but basically it says whether or not the display device is ready
[16:43] <sforshee> there's a short period on some devices after disabling autosuspend where the device might not be ready yet, so you have to wait until that file says it's ready before you try to draw
[16:44] <kdub> oh, wake_lock?
[16:44] <sforshee> no
[16:44] <sforshee> let me look
[16:45] <kdub> okay, thanks
[16:45] <sforshee> kdub: /sys/power/wait_for_fb_sleep
[16:45] <sforshee> I know that when powerd talked to surface flinger it waited on that file, but I don't know if that's the case with the unity8 integration
[16:46] <sforshee> oh, actually /sys/power/wait_for_fb_wake
[16:46] <kdub> sforshee, excellent, sounds like what I need
[16:47] <kdub> let me tinker with that file to see if i can avert the problet
[16:47] <sforshee> kdub: actually it looks to me like powerd still waits on that before requesting the display be turned on
[16:50] <kdub> i see that in the startup, but not on every display on/off request
[16:51] <kgunn> sforshee: thanks for helping kdub...this thing has been a bear
[16:51] <kdub> yes, thanks sforshee
[16:52] <sforshee> kdub: I know the code worked when talking to sf, and the only part that's changed is that it now calls into unity instead
[16:52] <kdub> yeah, let me dig into what exactly goes on there
[16:52] <kdub> in the SF path
[16:52] <sforshee> good luck
[17:00] <jsalisbury> ##
[17:00] <jsalisbury> ## Meeting starting now
[17:00] <jsalisbury> ##
[17:14]  * jsalisbury makes his first s/2013/2014/ mistake
[17:15] <sforshee> jsalisbury: woah, no more meetings until Dec 2014? ;-)
[17:15] <jsalisbury> sforshee, an another whoops :-)
[17:16] <jsalisbury> sforshee, changing the month and year at the same time caused an overload 
[17:17] <sforshee> I just guessed it was consecutive copy/paste errors
[17:17] <jsalisbury> heh, yup
[17:21] <antarus> was teh meeting exceeding short, or am I missing something?
[17:22] <sforshee> antarus: our meetings are always exceedingly short
[18:09] <antarus> kees: or apw how do I go about getting https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts-saucy/+bug/1244627 fixed?
[18:09] <ubot2`> Launchpad bug 1244627 in linux-meta-lts-saucy (Ubuntu) "Please enable CONFIG_IMA in the ubuntu kernel" [Undecided,Confirmed]
[18:09] <antarus> I might have filed it against the wrong thing (I am really aiming for Trusty I guess.)
[18:09] <antarus> I wonder if there is a more generic pkg name
[18:11] <apw> antarus, i seem to remember that was the one which in the past has caused terrible performance issues, and so it is enforced off, and i am guessing i said we would need some benchmarks to convince us it didn't
[18:11] <apw> still cause the same degredation
[18:11] <antarus> apw: I think we looked and it doesn't do anything without a policy loaded
[18:11] <antarus> and it doesn't load a policy by default
[18:12] <apw> antarus, iirc it made osmething bigger and the effect was devistating to performance (back when we tested it before)
[18:12] <antarus> (the user has to load one)
[18:12] <apw> even thought it really shouldn't be ... that is my worry
[18:15] <antarus> so I'm going to clone trusty and enable it then
[18:15] <antarus> and boot into it..and probably break my graphics ;p
[18:23] <kees> antarus: if you can show benchmarks without CONFIG_IMA, with CONFIG_IMA, and with CONFIG_IMG + policy, in a bug comment, that should be sufficient.
[18:30] <antarus> kees: that is what I am doing
[18:30] <antarus> I'm still curious what benchmarks you want
[18:30] <antarus> do you have any recommendations?
[18:30] <antarus> (io? memory? something else?)
[18:34] <kees> antarus: it was memory consumption in the past.
[18:34] <mjg59> kees: Also intrested in those results
[18:36] <antarus> kees: ok
[18:36] <kdub_> sforshee, just to pick your brain some more... do you know  why powerd sometimes sends consecutive 'display on' signals?
[18:36] <kdub_> i don't know if it means something by that, or if the second 'on' signal can safely be ignored
[18:37] <kees> mjg59: subscribe to 1244627! :)
[18:38] <antarus> wow, I do not understand your kernel build system..
[18:38] <antarus> heh
[18:38] <antarus> config.common.amd64 and config.common.ubuntu
[18:39] <antarus> are they merged together when the kernel is built?
[18:39] <kees> antarus: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
[18:39] <antarus> yeah I'm following that
[18:40] <kees> cool
[18:40] <kees> there are scripts that do the merge, yes.
[18:40] <antarus> ok
[18:40] <antarus> I was confused because half of my change landed in common, and the other half in teh per-arch configs
[18:44] <antarus> thanks for your patience with me
[18:46] <kees> no problem! the more people can build the kernel the better :)
[18:50] <pkern> If we'd get one howto out of it that it's actually current. <insert xkcd about standards here>
[18:59] <sforshee> kdub_: are the flags changing? That would be my guess.
[19:02] <antarus> pkern: the kernel howto is fine
[19:02] <antarus> pkern: also, stop working ;p
[19:02] <kdub_> sforshee, i'll check... thats kinda my guess too
[19:03] <sforshee> kdub_: it shouldn't emit a new event if nothing has changed, so if it's doing that then it's a bug
[19:03] <sforshee> but if the flags are changing, well, then something changed ;-)
[19:03] <pkern> antarus: This is my personal IRC. o_O
[19:03] <antarus> pkern: sure it is ;)
[19:04] <kdub_> from my end, (mir/unity-mir) i see two on's in a row, not sure how to interpret the second one
[19:05] <sforshee> kdub_: how about this: if (signal.state == on && my_screen_state == on) return;
[19:06] <sforshee> ;-)
[19:06] <sforshee> that is if you don't care about any of the flags
[19:07] <antarus> man this build takes its sweet time
[19:08] <antarus> I have 64 cores
[19:08] <antarus> I can do better
[19:08] <kdub_> sforshee, yeah, i'll try something like that
[19:20] <Sarvatt> antarus: dont build under fakeroot, makes it take 10x longer
[19:20] <Sarvatt> aka, debian/rules do_tools=0 do_extras_package=0 no_dumpfile=1 build-arch then fakeroot debian/rules do_tools=0 do_extras_package=0 no_dumpfile=1 binary-debs
[19:22] <antarus> lol
[19:22] <antarus> my build failed
[19:22] <antarus> missing moduels tpm_tis
[19:22] <antarus> god I hate the tpm
[19:23] <antarus> hrm, all the other tpm modules are there, but not tis
[19:23] <antarus> weird
[19:23] <antarus> anyway, lunch
[19:23] <antarus> Sarvatt: thanks for the tips
[19:23] <antarus> I'll try em next time
[19:31] <antarus> ahh I see my error
[19:37] <antarus> ok so tpm_tis used to be a module
[19:37] <antarus> and it can't be with IMA on
[19:37] <antarus> and IMA is not able to be compiled as a module
[19:37] <antarus> and so I broke the kernel abi
[19:40] <antarus> oh
[19:40] <antarus> dch -i
[19:40]  * antarus tsks
[22:45] <spideyman> Hello! does anyone have any quick tips on debugging a compile failure of: make[1]: *** [sub-make] Error 2
[22:45] <spideyman> how do I get more info?