[00:07] and all of this needs to be ported back to precise when it gets the next enablemnt kernel. [00:07] *sigh* [04:23] ogasawara: Want to commit something to git for me so Tim doesn't have a grumpy about me uploading things to the archive to fix bugs? :P === broder__ is now known as broder === broder is now known as broder___ === broder___ is now known as broder [08:05] I have a Question which always conflict to me http://en.wikipedia.org/wiki/File:Kernel_Layout.svg In this above pics Kernel is Directly connected with Devices and Memory , But what i know kernel is connected with cpu then via cpu it get connected with Memory and Devices === yofel_ is now known as yofel === henrix_` is now known as henrix [09:37] apw: remember the -mm patch? it just got accepted into mainline. [09:38] apw: crap! i should have waited one more day before submitting the CVE fix :) === rsalveti_ is now known as rsalveti === kentb_ is now known as kentb [09:59] apw: ok, i've just updated the cve-tracker and linux-overlay with the correct sha1 [10:01] henrix, heh oh well, great that you have fixed the tracker [10:02] apw: yeah, better do it now while its fresh. next year i wouldn't remember about it :) [10:04] infinity, i can take a look at that ... [10:06] apw: btw, is it worth submitting this fix for raring as well? i didn't as i was hoping the fix to hit raring from mainline in this merge window [10:08] henrix, well it cannot hurt to put it in R as it will simply rebase out of existance when the real fix hits [10:09] apw: ack, so i'll send it over. [10:10] ok ta [10:10] apw: err... that's embarassing... i've sent it already, and it's already in master-next :-/ [10:11] henrix, heh, then that is good [10:11] apw: its just the cve matrix that didn't got updated. let me figure out what went wrong [10:13] henrix, i bet the title isn't the same, U:S: prefix missing or something [10:14] apw: no, it looks correct to me... [10:14] henrix, ok then i'll have a look in a bit [10:15] apw: ok, thanks. i guess we can wait a little bit more, as i've just updated it with the upstream sha1... [10:15] henrix, shove the CVE number in here in the history so i can keep track [10:16] apw: CVE-2012-4530 [10:16] apw: i'll ping you later, after the next run (at :45, right?) [10:17] henrix, sure, i am going out for a bit shortly to get some food in before they sell out, so if i am quiet that is why [10:17] apw: no prob :) [10:18] oh, i just realised the raring is set to 'pending' for omap4 and armadaxp... [10:20] so those are rebase yes? [10:20] yep [10:27] henrix: omap4 and armadaxp don't have raring kernels, unless someone's finally gotten around to it. [10:27] henrix: I just copy the quantal kernels to raring. [10:28] infinity: hmm, right. i just got confused looking at the CVEs matrix, as it shows them as having raring kernels [10:28] infinity: thanks [11:32] has the number of file-descriptors and/or inotify user_watches been historically something like 4096? looking at the current /proc/sys/fs/[file-max|inotify/max_user_watches] it's much higher (390468 & 524288 respectively) [11:33] (in upstart we try to exhaust inotify watches & check that upstart still works correctly, but it seems like allocating 4096 watches will not do it anymore) [11:33] This seems like it could be a good thing. [11:34] xnox: Also, /proc/sys/fs/inotify/max_user_watches is 8192 here. What have you done to your computer? [11:35] (base)adconrad@cthulhu:~$ cat /proc/sys/fs/inotify/max_user_watches [11:35] 8192 [11:35] (base)adconrad@cthulhu:~$ uname -r [11:35] 3.7.0-7-generic [11:35] what about file-max? [11:35] It's high. [11:35] 1619078 [11:35] Then again, ulimit won't ever let me hit that. [11:36] well, I have ulimit unlimited. [11:36] (base)adconrad@cthulhu:~$ ulimit -n [11:36] 1024 [11:36] Again, your ulimit isn't the default setup. [11:37] * xnox runs bog standard ext4 (on top of lvm, crypt) [11:37] But a testsuite that relies on these things might want to try to synthesize such a setup. [11:37] well the idea is that we should exhaust it on a current machine and having artificial caps doesn't make sense to me, we should try to exhaust until we do =))))) [11:38] Could take a while. [11:38] it's a very tight loop, so i would not think so. [11:39] Can't be any worse than the glibc testcase that throws my laptop's load over 10000 (no, that's not a typo). [11:40] nice =) [11:40] actually, interesting to know how glibc testsuite reacts to being niced =) [13:02] henrix, did your CVE sort itself out? [13:03] * apw bets not cause i don't think the kteam-tools auto update is working at all [13:06] apw: nop :) [13:06] apw: now everything's 'needed', except for the omap4/armadaxp, which are 'pending' (??) [13:06] * apw will investigate indeed [13:07] thanks [13:51] * henrix -> late lunch [15:20] * henrix reboots === henrix is now known as henrix_ === henrix_ is now known as henrix [15:32] henrix, you made it back ... so it turns out to be a simple issue, after much debugging (sigh), i see we are using the wrong branch, master not master-next [15:33] apw: you mean, on the autotriage scripts? [15:33] apw: that makes sense then [15:34] heh yeah, doh [15:34] and if you look now, its all sane again [15:34] \o/ [15:34] an hour of debugging the code, wally me [15:34] *g* [15:35] anyway, i'll definitely need to dig deeper into 2 scary parts: the autotriage stuff and the shankbot :p [15:35] these are two things i've been avoiding looking at too closely :) [15:39] they are both heaps of complexity for sure [15:40] the autotriage stuff is particularly nasty to read :) === henrix is now known as henrix_ === dupondje_ is now known as dupondje [17:45] * apw wanders off ... have fun people