=== fmasi_afk is now known as fmasi
[08:10]  * apw yawns
[08:11]  * cking offers apw coffee
[08:12]  * apw looks at the kettle, seems its tea for now, the coffee grinder is just toooo noisy to deal with this early in the morning
[08:12] <infinity> I think small town living is getting to you.
[08:13] <infinity> A coffee grinder at 9am is nothing compared to jackhammers outside at 6 in a real city.
[08:15] <apw> infinity, oh so very true, so very very true
[08:15]  * infinity can't wait to move back downtown next month.
[08:16] <infinity> Something about the complete lack of street noise out in the suburbs just amplifies ten-fold the one car that DOES drive by at 3am.
[08:19] <apw> yeah that is true you need either silence, or a constant drone
[08:19] <apw> though you could just fire up leviathan and get the same effect no ?
[08:19] <cking> either stick your head in a complete vacuum or inside a server, either suffice
[08:24] <infinity> apw: leviathan is right next to my ear, though, not quite the same as street noise.
[08:24] <infinity> (This, too, will change when I move)
[08:24] <apw> infinity, and if i make it compile a nice kernel for you to get a bit more variablility?
[08:25] <infinity> Heh.  Are you hinting that you need the machine?
[08:25] <infinity> I thought you were all done being nice to flavours for this cycle.
[08:28] <apw> heh no don't need it
[08:28] <apw> i was just trying to help you sleep
[08:29] <infinity> Too kind.
[08:31] <infinity> apw: Is there another kernel coming before release, or are we shipping with what's in the archive?
[08:32] <apw> infinity, we have a pending fix for confinment which i believe needs to go in, i should have it shortly for testing with a view to getting it in today
[08:33] <infinity> apw: Alright, cool.  Hopefully, small and testable fix(es) only from here out, unless we're doing a full SRU-style validation.  Don't want any unexpected regressions before release day.
[08:34] <apw> infinity, yep i will confirm, but this is eminently testable, and will be pounded i am sure, and the other bits which come with have been validated already and are hyper-v specific
[08:35] <infinity> Mmkay.
[08:35] <apw> sadly many of the hyper-v flaws prevent boot so are not handleable as a day0
[08:37] <apw> infinity, oh i lie the hyper-v bits mostly made the last upload, so its thiner than i thought
[08:37] <infinity> Even better.
[08:38] <infinity> apw: Did you catch my prattle in /msg over the weekend about dropping some build-deps for headers-only arches?
[08:38] <apw> infinity, it is possible that that is sitting in /msg on my other machine (i am remote right now)
[08:39] <apw> so if you want to paste it back to /msg that'd work
[08:40] <infinity> Assuming a headers-only build doesn't need things like libdw-dev, libelf-dev, etc, it would be nice to arch-restrict those to only the arches that actually build kernels/tools.
[08:40] <infinity> Perhaps we should test this theory before we break anything.
[08:40] <infinity> (This is motivated by elfutils being broken on arm64 right now, and my wanting to actually build the headers correctly in the archive from the linux source package)
[08:41] <infinity> apw: If you hold off on your upload until after I've had a nap, maybe we can pick this up in the morning, and I can do some test builds on real hardware.
[08:41] <apw> infinity, sure, i expect tim will be point on uploading tonight, or me in the am
[08:42] <infinity> apw: Alright, well pass along to Tim that I'd like to hold off for this change too, then. :P
[08:43] <infinity> Or maybe I'll find the brainpower and/or motivation to hunt down why elfutils hates me tomorrow.
[08:43] <infinity> But I dunno.
[08:43] <infinity> Still seems silly to install build-deps one doesn't need for a header-only build.
[08:47] <apw> infinity, so that'd be for powerpc i assume
[08:49] <infinity> apw: arm64, powerpc, x32, ppc64el
[08:50] <infinity> apw: The inverse is easier to express, in that you only need certain build-deps on [amd64 i386 armhf] until other arches also build kernels/tools.
[08:51] <apw> infinity, yeah makes sense, it would be nice if you could have 'includes' for things like that
[08:51] <apw> Build-dep-<random keyword>: stuf
[08:52] <apw> Build-depends: Build-depends-<random keyword> [i386] sort of thing
[08:52] <infinity> apw: The whole deb-profile stuff (when done) sort of caters to this, though these aren't really build profiles.
[08:53] <infinity> apw: It's not uncommon, though, for build-deps to be autogenerated based on smarter lists (see d-i's control file, for instance, which is self-regenerating madness)
[08:55] <jjohansen> cking: try pulling from the tree now
[08:55] <infinity> apw: Would be cute if you could hook it into the do_* targets somehow, but parsing that out to magically divine build-deps sounds painful.
[08:55] <cking> jjohansen, thanks
[08:55] <infinity> apw: (Since you have some build-deps that are generic, some just for kernels, some just for tools...)
[08:56] <apw> infinity, yeah indeed, it would be nice to have at least # Build-depends-tools: <list>
[08:56] <apw> in there so _we_ know which are added why
[08:57] <infinity> apw: Anyhow, engineering something fancy is probably out of scope for what will (hopefully) be the last upload in saucy.  But I'll play in the morning with getting a diff to arch-restrict a few build-deps to make headers-only builds more lightweight.
[08:58] <apw> infinity, sounds great, as it is low risk
[09:02] <infinity> zequence: Thanks for the SRU kernels, BTW.  Everything's built and copied to -proposed now.
=== psivaa-afk is now known as psivaa
[09:16] <zequence> infinity: cool
[09:17] <zequence> I'm off to the dentist soon again. Pain meds aren't helping anymore.
[09:18] <zequence> Wisdom teeth aren't all that wise, evolutionary-wise
[09:19] <infinity> zequence: I had mine done at 15.  My condolences for doing it as an adult.
[09:19] <infinity> zequence: At least you have an excuse to be whiney for a few days.
[09:33] <apw> zequence, ouch, you have my sympathy
[09:46] <zequence> Might have melted some stiches by drinking rum the same day as the operation. So, I should probably just blame myself - or the dentist. Not sure yet :P
=== fmasi is now known as fmasi_afk
=== psivaa is now known as psivaa-afk
[12:36]  * henrix -> lunch
=== psivaa-afk is now known as psivaa
[13:06]  * apw runs for home ...
=== fmasi_afk is now known as fmasi
[13:36] <sforshee> rtg: is there any reason to have the CONFIG_ANDROID options enabled in our non-touch kernels?
[13:37] <sforshee> rtg: I ask because of bug #1235161
[13:37] <ubot2> Launchpad bug 1235161 in linux (Ubuntu) "lowmemorykiller killing processes when swap still available" [Undecided,Confirmed] https://launchpad.net/bugs/1235161
[13:39] <rtg> sforshee, hmm, lemme check
[13:43] <rtg> sforshee, how about CONFIG_ANDROID_LOW_MEMORY_KILLER=n ?
[13:44] <sforshee> rtg: I definitely think that's what we should be using, but I'm wondering if we should go a step further and do CONFIG_ANDROID=n
[13:45] <rtg> sforshee, I was just looking at the other android staging bits. though most of them are built in, they don't really do anything unless prodded (so far as I've looked)
[13:46] <sforshee> rtg: indeed, the rest probably are mostly harmless
[13:47] <sforshee> I'm not so sure about including binder support however
[13:47] <rtg> sforshee, alarm-dev seems a bit more proactive....
=== kentb-out is now known as kentb
[13:49] <rtg> sforshee, can you think of any possible use folks might have for these android bits ? they _are_ staging. as such, they are also subject to abrupt termination.
[13:50] <rtg> or removal
[13:52] <sforshee> rtg: not outside of the touch images. I'm sure people _could_ find uses for them, but I'd think it unwise to become reliant on them for sure.
[13:53] <sforshee> rtg: my inclination is towards CONFIG_ANDROID=n, but at minimum the lowmemkiller should be disabled. It needs active management by userspace to be useful, afaict.
[13:54] <rtg> sforshee, agreed (about ANDROID=n). I'm whipping up a patch and test build...
[13:56] <sforshee> rtg: ta
[14:08] <nessita> jsalisbury, hey there, you around? have some minutes?
[14:08] <rtg> sforshee, patch sent
[14:09] <sforshee> rtg: ack
[14:10] <nessita> jsalisbury, regarding bug #1201528 (I was on a leave for 2 weeks so I'm catching up with it): not sure where to get kernel 3.11.0-7 from, on my saucy installation I have 3.11.0-11-generic, and on the precise installation I'm not sure where to install it from (I can not find 3.11.0-7 on http://kernel.ubuntu.com/~kernel-ppa/mainline/)
[14:10] <ubot2> Launchpad bug 1201528 in linux (Ubuntu Saucy) "[INTEL DP55WG,Realtek ALC889] - Audio Playback Unavailable" [Medium,Incomplete] https://launchpad.net/bugs/1201528
[14:10] <nessita> I guess I will leave a comment in the bug report
[14:16] <nessita> jsalisbury, replied to the bug report, now I need to reboot because audio playback broke while testing the latests kernel with mumble :-)
[14:36] <jsalisbury> nessita, I'll checkout the bug comment
[14:36] <jsalisbury> nessita, No need to test 3.11.0-7 anymore, since there is a newer kernel.  Just confirming the bug still exists in the latest saucy kernel is good enough.
[14:36] <nessita> jsalisbury, perfect, already did
[14:37] <jsalisbury> nessita, thanks.  I'll post the next test kernel to test in the bug.
[14:38] <nessita> jsalisbury, awesome. Is there any way you could post a list of ~5 kernels to test? is easier for me to do so in batch, since I need someone else on mumble to chat with me to ensure proper testing
[14:38] <jsalisbury> nessita, sure
[14:39] <nessita> thanks!
[14:40] <jsalisbury> nessita, if we end up having to bisect further, that would only give us one kernel at a time to test though.
[14:41] <nessita> jsalisbury, no problem
=== fmasi is now known as fmasi_afk
[16:19] <rtg> jsalisbury, if you haven't already seen it, please work with the reporter on bug #1234662 and build him some test kernels.
[16:19] <ubot2> Launchpad bug 1234662 in linux (Ubuntu) "Ubuntu-lts-3.8.0 kernels corrupt ext[234] filesystems with 1k block size in Xen guests" [High,Confirmed] https://launchpad.net/bugs/1234662
[16:19] <xnox> Is there any general advice w.r.t. debugging kernel panic? "Unable to handle kernel paging request at virtual address c02fabe4 pgd = d5e24000" bug #1236444
[16:19] <ubot2> Launchpad bug 1236444 in linux-goldfish (Ubuntu) "kernel panic" [Undecided,New] https://launchpad.net/bugs/1236444
[16:19] <xnox> ?
[16:21] <rtg> xnox, ow!
[16:21] <xnox> rtg: i know that apparmor triggers it (disabled) later, "Setting up X socket directories..." triggers it.
[16:22] <jsalisbury> rtg, I pinged kamal about that bug on Friday.  It seems that commit can't be backported very easily to 3.8, which is why it wasn't picked up from stable.
[16:22] <xnox> rtg: there are vague hints online that compiling with 4.7 helps (instead of 4.8) but we already do that.
[16:23] <jsalisbury> rtg, there is some history in #stable-kernel
[16:23] <rtg> xnox, actually, I'm using 4.6 on several of the Nexus kernels.
[16:23] <rtg> jsalisbury, ack
[16:25] <rtg> xnox, maguro, manta, and grouper
[16:26] <xnox> rtg: what cross-prefix should I be using when cross-compiling goldfish? arm-linux-gnueabihf-, or CROSS_COMPILE=arm-linux-gnueabi-, or something else?
[16:26] <xnox> rtg: or can you compile with 4.6 and give me the deb somehow, for me to try it?
[16:26] <rtg> xnox, yeah, gimme a min or 2
[16:27] <jsalisbury> rtg, commit b764915 was cc'd to stable, but it doesn't look like it was picked up in any of the stable branches.
[16:28] <jsalisbury> rtg, except 3.10
[16:28] <rtg> jsalisbury, ok, just note it in the bug report I guess.
[16:28] <jsalisbury> rtg, ack
[16:29] <xnox> rtg: cool.
[16:40] <rtg> xnox, http://kernel.ubuntu.com/~rtg/linux-image-3.4.0-1-goldfish_3.4.0-1.7_armhf.deb - Note that this has patches from jjohansen that fix socket containment.
[16:44] <xnox> rtg: better. Let me re-enable apparmor, and reboot again.
[16:47] <rtg> xnox, better, as in no crashes ?
[16:53] <xnox> rtg: yeap, all is perfect with http://kernel.ubuntu.com/~rtg/linux-image-3.4.0-1-goldfish_3.4.0-1.7_armhf.deb
[16:54] <xnox> rtg: all init succeeded, all android lxc container finished booting, system is stable and works for >> 2 minutes
[16:54] <rtg> xnox, so, the question is was it the compiler or jjohansen's patches. do you have time to try another deb built with gcc-4.7 ?
[16:54] <xnox> rtg: yeap, I have time to try another deb.
[16:54] <rtg> xnox, ok, 10 mins
[17:13] <kamal> jsalisbury, hey did you ever get any response from anyone re: your patch "Input: cypress_ps2 - Return zero finger count if palm is detected."
[17:15] <xnox> rtg: I need to go, ping me URL to the new kernel, when ready. And i'll test it when I get back.
[17:17] <rtg> xnox, http://kernel.ubuntu.com/~rtg/linux-image-3.4.0-0-goldfish_3.4.0-0.7_armhf_gcc47.deb - Note this is a downgrade from the previous kernel (ABI change)
[17:30] <xnox> rtg: panics.
[17:31] <rtg> xnox, dang compiler then
[17:31] <xnox> rtg: =(
[18:43] <jsalisbury> kamal, I didn't get any response from upstream, but I'll ping them again or see if it was accepted.
[18:44] <kamal> jsalisbury, if you haven't heard back, then it probably hasn't been ... yes, I recommend pinging dmitry and rydberg
[18:48] <jsalisbury> kamal, ack
[20:21] <apw> rtg, did i see compiler issues with arm for goldfish?
[20:23] <apw> we did get a new compiler this week, arm changes only
[20:24] <apw> i know jj wont see it quite like that :)
[20:24] <apw> bah
[20:59] <rtg> apw, yeah, I rebuilt with gcc-4.6 and all of xnox's problems seemed to go away.
[21:13] <rtg> apw, I pushed a patch to change the armhf compiler for goldfish
[21:28]  * rtg -> EOD
=== RAOF_ is now known as RAOF
=== JanC_ is now known as JanC