Hi Here is the meeting log from the meeting and sorry for the delay.
/Magnus
[22:02:03] <Zorry> time? [22:02:13] <SwifT> yup [22:02:55] <Zorry> klondike: lejonet [22:03:09] <klondike> Zorry: pong [22:03:24] <Zorry> blueness: we take kernel now or when you get back? [22:03:34] <blueness> now is better [22:03:54] <blueness> she may be delayed in the meeting [22:05:23] <Zorry> were is prometheanfire [22:06:44] <Zorry> is it okay we start and with kernel as first [22:07:06] <blueness> Zorry let me do Kernel and Grsec/Pax together, i have very little to report [22:07:12] <SwifT> sure [22:07:43] <Zorry> blueness: okay go on [22:07:49] <blueness> okay 2.0 Kernel [22:07:49] <Zorry> 2.0 Kernel [22:08:39] <blueness> little has changed, since last meeting, i had a bug where I had the wrong deps on KERNEXEC and UDEREF for the preconfigured gentoo profiles, but that is fixed now and the broken ebuilds are off the tree [22:09:09] <blueness> i have made no other changes to those profiles, and prometheanfire is still looking into what works with with virtualization [22:09:12] <blueness> but it is a mess [22:09:28] <blueness> there is the issue of gcc-4.7 and the pax plugins [22:09:56] <blueness> basically upstream gcc has decided to go with g++ as the compile when building gcc [22:10:10] <blueness> well not exactly, 4.7 i allows both g++ and gcc [22:10:21] <blueness> but if i recall 4.8 and above will be g++ [22:10:34] <Zorry> yep [22:10:50] <blueness> this is a problem for the pax plugins to the kernel because they break due to c++ name space mangling of symbols [22:11:35] <blueness> and we will have to deal with this issue. dirtyepic has a suggestion for 4.7 to choose gcc but we will eventually have to deal with the issue [22:11:56] <pipacs> i will deal with it rather ;P [22:11:58] <blueness> that's a summary pipacs if you want to add more [22:12:17] <pipacs> i have to port some changes from another private tree of mine [22:12:31] <pipacs> that allows the kernel build system to compile c++ code [22:12:53] <blueness> ah [22:13:00] <pipacs> it's just low on the priority list [22:13:09] <blueness> 4.8 is a long way off [22:13:10] <pipacs> when will gcc 4.7 be in portage? [22:13:14] <pipacs> vs. some random overlay [22:13:28] <blueness> not sure that's the toolchain people [22:13:33] <Zorry> pipacs: when the patchset is done i think [22:13:44] <pipacs> 'cos i'd rather not worry about this until that happens [22:14:01] <pipacs> since it means only people who go out of their way to get the latest and greatest gcc are affected [22:14:06] <Zorry> and i think it will be masked to [22:14:12] <pipacs> and then they might as well build their gcc with gcc [22:14:21] <pipacs> it's a simple configure switch away [22:14:42] <pipacs> i don't care about masked as much as being in the main tree at all ;) [22:14:48] <pipacs> 4.6 is still masked after all yet i support it [22:15:05] <klondike> I have a question here [22:15:14] <pipacs> in fact, the plugins already work with gcc 4.7 per se as well [22:15:21] <klondike> Why don't use the namemangled symbol names in C? [22:16:13] <pipacs> 'cos gcc doesn't know how to generate them for me [22:16:30] <klondike> no, but namemangler.sh may ;) [22:16:33] <pipacs> g++ knows how to mangel C symbols, but not the other way around [22:17:17] <pipacs> anyway, the real solution is to teach the kernel build system to build with g++ as well [22:17:47] <slyfox> *choke*, what kernel? [22:17:49] <pipacs> there will be some with having to specify CXX in addition to CC in the future ;P [22:18:00] <blueness> i've never tried that, it sounds like one of those things that should be easy but is probably full of issues with switches [22:18:21] <pipacs> slyfox, i meant to build userland support code (in my case gcc plugins) with g++, not actual kernel code [22:18:30] <slyfox> *phew* [22:18:38] <pipacs> err, 'will be some fun with' [22:19:13] <klondike> Ohh C++ kernel code could be fun, imagine handling oops as exceptions :P [22:19:32] <blueness> guys, i've got to run in 5 mins to pick up my wife, she just phoned me, let me add one more item to report and then i'll continue when back --- sorry slightly out of order: [22:19:52] <blueness> i have yeat to make userland utility for the xattr pax stuff which is pipacs is pretty much finished with [22:20:32] <blueness> i think i'm just going to write a wrapper script to use both paxctl and set/getfattr to keep both the PT_PAX and xattr pax flags in line [22:20:46] <blueness> that's my first order of business now that summer has started and i'm not teaching [22:20:55] <blueness> long delay on that sorry [22:21:07] <blueness> (end of stuff i need to tell everyone) [22:21:29] <blueness> (off to pick up my wife) [22:21:36] <Zorry> blueness: cy [22:21:52] <Dwokfur> lucky it's just C++ for the kernel and not java - imagine a garbage collector... [22:23:14] <Zorry> any one else? [22:23:50] <klondike> hum [22:24:02] <klondike> I have other question regarding c++ [22:24:26] <prometheanfire> ok, I should be able to talk now [22:24:31] <klondike> I recall some qt based graphical config utility on the kernel, shouldn't that run with C++? [22:25:14] <pipacs> there's some limited support for compiling c++ code but it's not enough for plugins [22:25:29] <pipacs> heck, even the normal C suppor code wasn't enough for plugins, i had to tweak that too at the time [22:25:39] <klondike> aha, that explains it then [22:25:53] <pipacs> so you can build *apps* that use c/c++ shared libs, but that's about it [22:26:08] <pipacs> standalone c or c++ libs are not supported, that needs some patching in the build system [22:28:08] <Zorry> next? [22:28:38] <Zorry> okay then [22:28:53] <Zorry> 1.0 Toolchain [22:29:10] <Zorry> gcc 4.6 is still masked [22:29:29] <Zorry> most for the grub thing [22:29:48] <prometheanfire> grub2 or grub1? [22:30:18] <Zorry> grub2 lack docs and still some bugs on it and grub 0.x is broken [22:31:10] <Zorry> gcc-4.7 still lack the gentoo patchset before it hit the tree and would be masked i think [22:32:07] <Zorry> else i don't have any thing [22:32:14] <Zorry> any one else? [22:32:39] <Zorry> blueness: can talk about uclibc when he get back [22:32:44] <klondike> Well gcc-4.5.3 has a nice bug involving vector types :P [22:33:07] <klondike> Other than that nothing else here :P [22:33:44] <Zorry> okay next [22:33:58] <Zorry> 3.0 Selinux [22:34:08] <SwifT> k [22:34:34] <SwifT> I've moved the policy sources where we make our patch bundles from from github to gogo [22:34:44] <SwifT> those interested, it's on gogo's proj/hardened-refpolicy.git [22:35:15] <SwifT> i'll update the development guide to reflect this (so that interested parties and developers don't need to do magic to get the sources of our current policies) [22:35:39] <SwifT> regarding policies, in the main tree, the 2.20120215-r7 release is now stable [22:35:53] <SwifT> -r8 is ~arch, -r9 is in hardened-dev overlay and -r10 is in the making [22:36:20] <SwifT> the upgrade towards the 2.20120215 policies haven't been entirely smooth, but I've learned from it and will try to have the next upgrade more easy [22:36:36] <SwifT> for one, I'm backporting changes made to refpolicy into our policy to make changes less abrupt [22:36:50] <SwifT> another change is in the eclass (more abotu that later) [22:37:11] <SwifT> i've removed the 20110725 policies from the tree (little over 300 files removed) [22:37:47] <SwifT> that's so far the state-of-affairs on selinux in general. On the subtopic of this agenda (eclass): [22:38:03] <SwifT> I'm working on updating the selinux eclass to include two changes [22:38:22] <SwifT> the first is to support a more "smarter" way to load the policies after build [22:38:48] <SwifT> right now, the eclass just tries to load the policy and if it fails, it barks out the failure and dies... well, nt erally dies, because it's in postinst phase, but still [22:39:08] <SwifT> I'm going to have the eclass also retry loading the policy while also trying to load all other installed modules [22:39:20] <SwifT> this should allow for a moer smooth upgrade path in the future [22:39:33] <SwifT> it's not artificial intelligence, just an extra step to try ;) [22:39:53] <SwifT> another change is that the eclass now allows for contributors to create simple ebuilds containing additional SELinux policies [22:40:15] <SwifT> until now, contributors had to generate a patch to include their policy, and their policy could only contain a .te and .fc definition [22:40:36] <SwifT> the update on the eclass allows contributors to include .if files as well, and he can now just have the policies as part of the files/ directory [22:41:02] <SwifT> a lot easier to work with, and should allow more contributions in overlays (without interfering with our own set of policies) [22:41:16] <SwifT> the eclass in development is available in the hardened-dev overlay [22:41:39] <SwifT> the current state looks ok, just need to test it out with a whole new installation (going from hardened-noselinux to hardened-selinux) [22:41:55] <SwifT> so far my monologue on selinux & its eclass ;-) [22:42:12] <Zorry> any one else? [22:42:28] <Aleister> someone claimed that MCS _is_ supported is this correct? [22:43:03] <SwifT> yes, I have quite a few with MCS enabled here [22:43:16] <Aleister> heh ok :) [22:43:49] <SwifT> so if there is an issue with MCS, I should be able to either reproduce or work on it [22:43:53] <SwifT> MLS is a totally different matter [22:44:18] <SwifT> there was a gentoo user reporting that it worked for him, but I haven't been able to get one going (and frankly, don't have the time for it currently either) [22:44:27] <Aleister> just want to get the fact straight so i dont hand out any misinformation :) [22:44:50] <SwifT> MCS is only interesting if you use an applicationn that's SELinux-aware and using MCS itself (like svirt) [22:45:07] <Aleister> jup i know :) [22:46:11] <SwifT> no-one else? [22:46:17] <Zorry> okay [22:47:22] <Zorry> 4.0 Grsec/PaX was in kernel or so some one else have some thing? [22:48:01] <pipacs> two things perhaps [22:48:07] <Zorry> go [22:48:26] <pipacs> can we teach the module eclass to use patches in /etc/portage/patches? [22:48:34] <pipacs> iirc i had problems with that in the past [22:49:00] <pipacs> and related, there's the pax_kernel USE flag that some packages use for doing pax-mark'ing now? [22:49:06] <pipacs> i wrote about it today on the list [22:50:38] <Zorry> can ask blueness about the modules [22:51:53] <pipacs> ok, let's move on then [22:52:20] <Zorry> 5.0 Profiles [22:52:40] <Zorry> we did unmask unicode [22:53:11] <Zorry> so we have new stage3 files [22:53:45] <Zorry> that builds on the offciel stage build box [22:54:16] <Zorry> SwifT: do you have any thing? [22:54:42] <SwifT> Zorry: nope, will be for next meeting (hope to have selinux-enabled stages by then :) [22:54:59] <Zorry> k [22:55:12] <Zorry> any one else? [22:55:45] <Zorry> 6.0 Docs [22:55:50] <Zorry> klondike: SwifT [22:56:06] <Zorry> prometheanfire: do you have anything? [22:56:18] <klondike> Not much on my side, busy with live and stuff :( [22:56:19] <SwifT> for the selinux docs, I reverted the documentation on /sys/fs/selinux to be back towards /selinux, we need to have a ~arch portage stable before we can move to /sys/fs/selinux [22:56:39] <SwifT> other than that, a few FAQs were updated, but nothing major [22:57:04] <SwifT> the docs seem to be in line with the tools (no outdated ones afaik) [22:57:18] <SwifT> if i'm incorrect, please file a bug on it and we'll update the docs accordingly ;) [22:58:33] <Zorry> done? [22:58:55] <SwifT> yup [22:59:04] <Zorry> 7.0 Bugs [22:59:24] <Zorry> any bugs we need to talk about? [23:00:00] <prometheanfire> none that I know of [23:00:23] <Zorry> k [23:00:32] <Zorry> any one else? [23:01:01] <Zorry> 8.0 Media [23:01:04] <Zorry> klondike: [23:01:14] <klondike> Not much here [23:01:24] <klondike> We closed identi.ca [23:01:29] <klondike> Twitter still up [23:01:46] <klondike> And no talks in the nearby future so... [23:02:01] <klondike> that's it for media [23:02:16] <Zorry> okay [23:02:31] <Zorry> next [23:02:32] <klondike> Anybody else? [23:03:08] <Zorry> 9.0 Open floor
