[00:07] <xnox> and all of this needs to be ported back to precise when it gets the next enablemnt kernel.
[00:07] <xnox> *sigh*
[04:23] <infinity> 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
[08:05] <bipul> 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
[09:37] <henrix> apw: remember the -mm patch? it just got accepted into mainline.
[09:38] <henrix> apw: crap! i should have waited one more day before submitting the CVE fix :)
[09:59] <henrix> apw: ok, i've just updated the cve-tracker and linux-overlay with the correct sha1
[10:01] <apw> henrix, heh oh well, great that you have fixed the tracker
[10:02] <henrix> apw: yeah, better do it now while its fresh. next year i wouldn't remember about it :)
[10:04] <apw> infinity, i can take a look at that ...
[10:06] <henrix> 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] <apw> 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] <henrix> apw: ack, so i'll send it over.
[10:10] <apw> ok ta
[10:10] <henrix> apw: err... that's embarassing... i've sent it already, and it's already in master-next :-/
[10:11] <apw> henrix, heh, then that is good
[10:11] <henrix> apw: its just the cve matrix that didn't got updated. let me figure out what went wrong
[10:13] <apw> henrix, i bet the title isn't the same, U:S: prefix missing or something
[10:14] <henrix> apw: no, it looks correct to me...
[10:14] <apw> henrix, ok then i'll have a look in a bit
[10:15] <henrix> apw: ok, thanks. i guess we can wait a little bit more, as i've just updated it with the upstream sha1...
[10:15] <apw> henrix, shove the CVE number in here in the history so i can keep track
[10:16] <henrix> apw: CVE-2012-4530
[10:16] <henrix> apw: i'll ping you later, after the next run (at :45, right?)
[10:17] <apw> 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] <henrix> apw: no prob :)
[10:18] <henrix> oh, i just realised the raring is set to 'pending' for omap4 and armadaxp...
[10:20] <apw> so those are rebase yes?
[10:20] <henrix> yep
[10:27] <infinity> henrix: omap4 and armadaxp don't have raring kernels, unless someone's finally gotten around to it.
[10:27] <infinity> henrix: I just copy the quantal kernels to raring.
[10:28] <henrix> infinity: hmm, right. i just got confused looking at the CVEs matrix, as it shows them as having raring kernels
[10:28] <henrix> infinity: thanks
[11:32] <xnox> 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] <xnox> (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] <infinity> This seems like it could be a good thing.
[11:34] <infinity> xnox: Also, /proc/sys/fs/inotify/max_user_watches is 8192 here.  What have you done to your computer?
[11:35] <infinity> (base)adconrad@cthulhu:~$ cat /proc/sys/fs/inotify/max_user_watches
[11:35] <infinity> 8192
[11:35] <infinity> (base)adconrad@cthulhu:~$ uname -r
[11:35] <infinity> 3.7.0-7-generic
[11:35] <xnox> what about file-max?
[11:35] <infinity> It's high.
[11:35] <infinity> 1619078
[11:35] <infinity> Then again, ulimit won't ever let me hit that.
[11:36] <xnox> well, I have ulimit unlimited.
[11:36] <infinity> (base)adconrad@cthulhu:~$ ulimit -n
[11:36] <infinity> 1024
[11:36] <infinity> Again, your ulimit isn't the default setup.
[11:37]  * xnox runs bog standard ext4 (on top of lvm, crypt)
[11:37] <infinity> But a testsuite that relies on these things might want to try to synthesize such a setup.
[11:37] <xnox> 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] <infinity> Could take a while.
[11:38] <xnox> it's a very tight loop, so i would not think so.
[11:39] <infinity> 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] <xnox> nice =)
[11:40] <xnox> actually, interesting to know how glibc testsuite reacts to being niced =)
[13:02] <apw> 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] <henrix> apw: nop :)
[13:06] <henrix> apw: now everything's 'needed', except for the omap4/armadaxp, which are 'pending' (??)
[13:06]  * apw will investigate indeed
[13:07] <henrix> thanks
[13:51]  * henrix -> late lunch
[15:20]  * henrix reboots
[15:32] <apw> 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] <henrix> apw: you mean, on the autotriage scripts?
[15:33] <henrix> apw: that makes sense then
[15:34] <apw> heh yeah, doh
[15:34] <apw> and if you look now, its all sane again
[15:34] <henrix> \o/
[15:34] <apw> an hour of debugging the code, wally me
[15:34] <henrix> *g*
[15:35] <henrix> anyway, i'll definitely need to dig deeper into 2 scary parts: the autotriage stuff and the shankbot :p
[15:35] <henrix> these are two things i've been avoiding looking at too closely :)
[15:39] <apw> they are both heaps of complexity for sure
[15:40] <apw> the autotriage stuff is particularly nasty to read :)
[17:45]  * apw wanders off ... have fun people