[06:56] <mlankhorst> arges: hey
[07:02] <smb> mlankhorst, Hope you don't expect him to be around at this time of day. :)
[07:51] <infinity> zequence: I see fresh lowlatency rebases in your PPA.  Are those good and ready to be copied?
[07:52]  * infinity assumes "yes" and copies away.
[07:58] <infinity> pkern: Can we assume from your comments on bug 1300739 that it's also working for you for lts-trusty?
[09:36] <pkern> infinity: I tried the trusty kernel on precise and I tried the lts-trusty kernel on precise. Both worked fine.
[09:37] <pkern> infinity: Somewhat annoyed that the audit fix didn't make it into -30, though.
[09:38] <apw> pkern, last i looked they hadn't settled on a sane fix for that, a lot of "this doesn't fix blah and i don't care" going on
[09:41] <pkern> apw: Tempting to just divert the x32 ld-linux away.
[09:41] <pkern> I think my initial fix was pretty close to fixing stuff. One could've switcheroo'ed the arch designation, but meh.
[09:42] <trippeh_> x32, ugh
[09:42] <apw> pkern, yeah i asume the issue here is there is noone stepping up to care about x32 upstream
[09:42] <trippeh_> buggy POS ;)
[09:43] <trippeh_> and security hazard
[09:52] <infinity> trippeh_: Security hazard how?  Because one security bug was found in it?
[09:52] <infinity> pkern: Seems odd that production machines would have libc6-x32 installed in the first place.
[09:52] <trippeh_> because it is messy and is bitrotting, as far as I understood the discussions on lkml some time ago
[09:53] <trippeh_> they besicly regretted merging it
[09:53] <infinity> trippeh_: Upstream regrests merging nearly everything, I think I'd take that with a grain of salt unless I read the thread in question and put it in context.
[09:54] <trippeh_> ok, I think the wording was something like "horrible mess"
[09:54] <trippeh_> ;)
[09:57] <trippeh_> its a while ago, but I doubt much has changed
[10:05] <pkern> infinity: gcc-multilib
[10:05] <pkern> infinity: Because engineering.
[10:06] <infinity> pkern: Fair enough.  What was the bug again?  As much as we're fans of "upstream first", I vaguely recall your patch being trivial enough that maybe we should JFDI as Ubuntu saucy for the next cycle.
[10:06] <infinity> apw: Opinions?
[10:06] <infinity> s/saucy/sauce/
[10:06] <infinity> Stupid release names breaking my ability to type.
[10:06] <apw> infinity, i think the issue was it fixed the bit in question but broke auditing or something, and upsteam instrad of helping went all postal on auditing
[10:07] <pkern> https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1302605
[10:07] <pkern> apw: Ack.
[10:07] <pkern> It was a bit inconsistent to have two syscall paths both yield to auditing, one with arch=i386 and one with arch=amd64. I admit that.
[10:08] <pkern> But surely bounds-checking alone will just exclude syscalls from auditing, which is wrong as well.
[10:08] <apw> "but auditing is slow and utter crap, *sounds or machine guns and people screaming*"
[10:10] <pkern> And they're probably right. But it's not my choice to make. 
[10:10] <apw> no indeed, helping make it less crap and work mostly would have been nice
[14:34] <marvin24> hi and maybe silly question
[14:34] <marvin24> which modules belong to debian.master/d-i/modules/kernel-image
[14:35] <marvin24> ?
[15:17] <apw> marvin24, that is the d-i module kernel-image which contains the kernel
[19:12] <marvin24> apw: ok, so this affects only debian installer (not the kernel in a installed system)
[20:05] <apw> marvin24, it defines a grouping of files for installation into the image which becomes the CDs yes
[20:07] <marvin24> apw: the reason I'm asking is that I want to get the utopic kernel booting on my tegra2 netbook
[20:07] <marvin24> it seems that srwarren (from nv) added a lots of tegra specific drivers to kernel-image
[20:08] <apw> hmmm, that sounds like it owuld be odne if they wern't already in the right places
[20:08] <marvin24> in fact, the generic kernel already boots fine, but misses the tegra-drm module
[20:09] <apw> and likely that should be in the appropriate other d-i module for arm
[20:09] <marvin24> I can submit a patch to fix this, but I wonder if I should also add it to kernel-image
[20:09] <marvin24> yes, maybe some video module
[20:10] <marvin24> on the other hand, some modules are necessary to get the system to some useful state, e.g. regulators, i2c
[20:11] <marvin24> so kernel-image should be ok
[20:11] <marvin24> but I'm not an d-i expert
[20:14] <apw> likely things like that would be in kernel, not 100% sure myself, i'd say make the patch send it to kernel-team@ list, and i can talk it through with the d-i folk to make sure it is appropriate
[20:20] <marvin24> apw: yes, the real problem is that everything is a module, but I guess that won't change
[22:19] <hans109h> apw, any progress?