[06:56] arges: hey [07:02] mlankhorst, Hope you don't expect him to be around at this time of day. :) [07:51] 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] pkern: Can we assume from your comments on bug 1300739 that it's also working for you for lts-trusty? [07:59] bug 1300739 in keepalived "keepalived doesn't load any ipv6 virtual servers" [Undecided,New] https://launchpad.net/bugs/1300739 [09:36] infinity: I tried the trusty kernel on precise and I tried the lts-trusty kernel on precise. Both worked fine. [09:37] infinity: Somewhat annoyed that the audit fix didn't make it into -30, though. [09:38] 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] apw: Tempting to just divert the x32 ld-linux away. [09:41] I think my initial fix was pretty close to fixing stuff. One could've switcheroo'ed the arch designation, but meh. [09:42] x32, ugh [09:42] pkern, yeah i asume the issue here is there is noone stepping up to care about x32 upstream [09:42] buggy POS ;) [09:43] and security hazard [09:52] trippeh_: Security hazard how? Because one security bug was found in it? [09:52] pkern: Seems odd that production machines would have libc6-x32 installed in the first place. [09:52] because it is messy and is bitrotting, as far as I understood the discussions on lkml some time ago [09:53] they besicly regretted merging it [09:53] 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] ok, I think the wording was something like "horrible mess" [09:54] ;) [09:57] its a while ago, but I doubt much has changed [10:05] infinity: gcc-multilib [10:05] infinity: Because engineering. [10:06] 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] apw: Opinions? [10:06] s/saucy/sauce/ [10:06] Stupid release names breaking my ability to type. [10:06] 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] https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1302605 [10:07] Ubuntu bug 1302605 in linux (Ubuntu) "Calls to /libx32/ld-linux-x32.so.2 hang when using auditd" [Undecided,Confirmed] [10:07] apw: Ack. [10:07] 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] But surely bounds-checking alone will just exclude syscalls from auditing, which is wrong as well. [10:08] "but auditing is slow and utter crap, *sounds or machine guns and people screaming*" [10:10] And they're probably right. But it's not my choice to make. [10:10] no indeed, helping make it less crap and work mostly would have been nice [14:34] hi and maybe silly question [14:34] which modules belong to debian.master/d-i/modules/kernel-image [14:35] ? [15:17] marvin24, that is the d-i module kernel-image which contains the kernel [19:12] apw: ok, so this affects only debian installer (not the kernel in a installed system) [20:05] marvin24, it defines a grouping of files for installation into the image which becomes the CDs yes [20:07] apw: the reason I'm asking is that I want to get the utopic kernel booting on my tegra2 netbook [20:07] it seems that srwarren (from nv) added a lots of tegra specific drivers to kernel-image [20:08] hmmm, that sounds like it owuld be odne if they wern't already in the right places [20:08] in fact, the generic kernel already boots fine, but misses the tegra-drm module [20:09] and likely that should be in the appropriate other d-i module for arm [20:09] I can submit a patch to fix this, but I wonder if I should also add it to kernel-image [20:09] yes, maybe some video module [20:10] on the other hand, some modules are necessary to get the system to some useful state, e.g. regulators, i2c [20:11] so kernel-image should be ok [20:11] but I'm not an d-i expert [20:14] 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] apw: yes, the real problem is that everything is a module, but I guess that won't change [22:19] apw, any progress?