[00:19] <bjf> jjohansen: you marked bug 1020888 as 'invalid' for security. this is rebased on the precise main branch. also, this release replaced a previous one in -proposed that didn't make it to -updates
[00:19] <ubot2> Launchpad bug 1020888 in linux-armadaxp "linux-armadaxp: 3.2.0-1605.8 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1020888
[00:21] <jjohansen> bjf: right we aren't doing USNs for armadaxp, currently they being "maintained" by OEM and the deal is that the security team isn't in general doing USNs for them
[00:21] <jjohansen> bjf: so its likely you still need to do the CVE end of things, and I will just clear them through as invalid when I see them, at least until I am told to do otherwise
[00:22] <jjohansen> s/they being/they are being/
[02:00] <Vromoth> Hello?
=== philipballew__ is now known as philballew
=== jibel_ is now known as jibel
[11:59] <janimo> apw, seems the latest 3.5.0 rebase on rc7 does not have a tag in the repo
[12:00] <janimo> Ubuntu-3.5.0-5.5 missing
[13:07] <apw> janimo, i do not see it uploaded yet which would trigger tagging normally, so its not definatly 'done'
[13:08] <apw> janimo, but i will check and find out why
[13:33] <dcgen> Hi i am using a dell xps 14 and I wanted to know what version of the kernel which has the backlight fixed for xps should I use..
[13:37] <ogra_> hmm, no ppisati ?
[14:08] <janimo> apw, oh I thought the tag happens on commit not upload.thanks
[16:55] <jamespage> how is the best person to direct ARM kernel requests to?
[17:05] <rtg> jamespage, likely cooloney or ppisati
=== _bjf is now known as bjf
[17:08] <cooloney> jonmasters: sorry, i just reboot my machine, what am i missing?
=== shadeslayer_ is now known as evilshadeslayer
[17:15] <rbasak> jamespage: ^^
[17:15] <jamespage> rtg, thanks
[17:16] <jamespage> cooloney, specifically I was trying to use the rbd module on omap4
=== yofel_ is now known as yofel
[17:36] <cooloney> jamespage: any failure when you are trying use rbd in omap4? which kernel are you using?
[17:37] <jamespage> cooloney, kernel - Linux winehouse 3.4.0-204-omap4 #9-Ubuntu SMP PREEMPT Mon Jul 9 12:56:56 UTC 2012 armv7l armv7l armv7l GNU/Linux
[17:37] <jamespage> cooloney, I get a 'FATAL: Module rbd not found.' when running modprobe rbd
[17:52] <cooloney> jamespage: oh, yeah, i found for ti-omap4 we disable this 
[17:52] <cooloney> debian.ti-omap4/config/config.common.ubuntu:# CONFIG_BLK_DEV_RBD is not set
[17:53] <jamespage> cooloney, can we enabled it? I'm assuming its disabled for a reason...
[17:53] <cooloney> jamespage: is this necessary for ceph or other stuff? i found it's built as module in our master branch
[17:54] <jamespage> cooloney, yes - at the moment I can run a ceph server on omap4 - but I can access block devices...
[17:54] <cooloney> ppisati: do you know why we disable CONFIG_BLK_DEV_RBD for ti-omap4?
[17:54] <jamespage> cooloney, the same would apply to other ARM kernels - its specifically important for server targets
[17:55] <cooloney> jamespage: cool, i will send out patch for this
[17:55] <jamespage> cooloney, thanks v. much :-)
[17:55] <cooloney> jamespage: thanks for pointing out, btw, running ceph on ARM is quite cool
[17:58] <jamespage> cooloney, if we can get this module and openvswitch module enabled for ARM archs == fully functional openstack!
[17:58] <jamespage> backed by ceph for scalable instance volume block storage - nice!
[17:59] <jamespage> zul, ^^ FYI
[18:04] <infinity> jamespage: the higbank config should match master pretty closely.  armadaxp might need a twiddle, since it was originally cargo-culted from ti-omap4, I think.
[18:04] <infinity> jamespage: So, double-checking all the configs and filing bugs might be sane.
[18:04] <infinity> jamespage: Doubly-so, if this should be fixed in the SRU kernels too.
[18:05] <jamespage> infinity, where do I look at kernel configs?  I can do a cursory check
[18:05] <infinity> jamespage: I'd just grab the actual debs and check /boot/config-* inside.  Easier than constructing it from the twisty maze of bits in debian.*/ in the source. ;)
[18:06] <jamespage> infinity, ack - I'll take a look
=== kentb-out is now known as kentb
[18:26] <cooloney> jamespage: OPENVSWITCH should be enabled by apw in both ti-omap4 and master
[19:09] <hggdh> kernel folks: armadaxp 3.2.0-1605.8-armadaxp does not have ip_tables.ko. Is this how it should be?
[19:49] <pgraner> jsalisbury, did the web cam patch make it into a released kernel yet?
[20:04] <bjf> hggdh: looking at it
[20:13] <ogasawara> pgraner: it did and I uploaded to our PPA to build.  I'll copy it out to the release pocket when it's all done.
[20:37] <janimo> hggdh, seems like in armadaxp ip_tables is built in not a module
[20:37] <hggdh> janimo: perfect, thank you
[20:38] <janimo> hggdh, is that a failure actually - I do not recall explicitly making it built in
[20:38] <janimo> this may be the first time these tests are run on armadaxp
[20:38] <hggdh> janimo: I believe so, I do not know of anybody else running these tests except me, the security team, and (of old) gruemaster
[20:40] <janimo> hggdh, so is there a need for concern if it is built in?
[20:40] <hggdh> janimo: no, not really, but the QRT must be adjusted for that
[20:41] <janimo> hggdh, I should probably make it a module though to be in line with the other kernels
[20:42] <hggdh> janimo: I agree 100%. So can we assume you are making these changes for the next build(s) -- precise and quantal?
[20:42] <janimo> ikepanhc, cooloney unless you know something about it needing to be built-in
[20:42] <janimo> hggdh, yes. For precise, and the same package will likely make it to quantal (copied)
[20:42] <janimo> so no need to adjust the test either I guess
[20:42] <hggdh> janimo: perfect, thank you much
[20:43] <ikepanhc> janimo: none
[20:43] <ikepanhc> janimo: I am ok with build-in or module
[20:43] <janimo> hggdh, np thanks for testing this kernel thoroughly :)
[20:44] <janimo> hggdh, any other tests that you know of before this can be decalred ok for -updates? just curious
[20:44] <hggdh> janimo: I am marking the bug now fix-released, qa-testing-passed
[20:45] <infinity> janimo: Have you checked if you're in line with other modules, compared to master?
[20:46] <infinity> janimo: See, eg, discussions above about CONFIG_BLK_DEV_RBD in ti-omap4, no idea if that's enabled in armadaxp.
[20:46] <janimo> infinity, no config checking done, I should probably do that to when enabling this change
[20:47] <janimo> infinity, just copying over from mainline/highbank should do it or do I need a line by line review?
[20:48] <infinity> janimo: Better answered by someone like apw or ogasawara (they do line-by-line reviews).
[20:48] <infinity> janimo: But you can probably cheat a bit, given that master already has sane reviews, and you can likely cargo-cult a bit, and adjust for platform differences.
[20:49] <janimo> alright
[20:49] <janimo> will schedule this for next SRU.
[20:49] <infinity> Well, FSVO "sane".  I vaguely recall a rather large amount of alcohol involved in the config review I participated in.
[20:49] <janimo> or actually maybe ikepanhc will do it if we switch tasks (armada/highbank) for a while
[20:49] <ikepanhc> janimo: yes, I am thinking on this
[20:50] <apw> infinity, the alcohol is needed to avoid self termination
[20:50] <hggdh> janimo: bug is ready for next stage
[20:50] <ogasawara> janimo: we're sprinting this week and doing a config review, let us know if there is a particular config we need to examine
[20:50] <janimo> infinity, is there anything you participate in that does not involve large amounts of alcohol?
[20:50] <infinity> ogasawara: armadaxp/precise should probably look as close to master/precise as possible.
[20:51] <janimo> hggdh, if next stage is taken care of by bjf's bot or some friendly admin I'm not touching it :)
[20:51] <ogasawara> infinity: indeed, that's the goal
[20:51] <infinity> ogasawara: No idea how off it is currently, but I'd guess "a bunch".
[20:51] <ikepanhc> janimo: ok, I will do this these two weeks, let me pick up those "purple" items again
[20:51] <hggdh> janimo: bjf's bot will do it
[20:52] <infinity> hggdh: Still needs a regression-testing signoff, surely?
[20:52] <hggdh> infinity: already done
[20:53] <infinity> hggdh: Nu uh.
[20:53] <hggdh> infinity: barf on hitting enter on the bug
[20:53] <hggdh> check it now
[20:54] <hggdh> bloody hell, barf again :-)
[20:54] <infinity> Hahaha.
[20:54] <infinity> Launchpad loves you. ;)
[20:54] <infinity> Right, *now* the bot will DTRT.
[20:54] <infinity> Or, I might pre-empt it and just take the release tasks.
[20:54] <infinity> After I smoke.
[21:00] <infinity> ogasawara: Waitaminute.  Back up.  Did you just imply that you're doing config reviews sober?
[21:01] <ogasawara> infinity: no one said we were sober
[21:01] <infinity> ogasawara: Phew.
[21:05] <infinity> janimo: Released.
[21:05] <janimo> infinity, \o/ thanks
[21:34] <infinity> ogasawara: Say, while you guys are sprinting, want to take a vote about getting me added to the 2550(kernel_team) and 2616(kernel_cdev) UNIX groups for emergency use and random collaboration?
[21:46] <rtg> infinity, I would prefer that you commit changes to your repository (perhaps on zinc) and email a pull request to the k-team list. I notice that you don't have a publicly visible directory on zinc. I can request that one be created for you.
[21:47] <rtg> That would necessitate joining kernel_team, but not kernel_cdev.
[21:50] <infinity> rtg: I'm sure that could be done.  It's been a while since I've had to do any emergency faffing, but it's irksome to then get hunted down by the "it's not in git" police. ;)
[21:51] <infinity> rtg: And kernel_team would probably be enough for collaboration on other projects, yes (like, if we want to keep initramfs-tools on zinc)
[21:51] <rtg> infinity, ok, I'll start an RT and get you a public directory.
[21:52] <infinity> rtg: Danke.