A late meeting log and a
HAPPY NEW YEAR from the
Gentoo Hardened Project.
/Magnus
[21:13:10] <Zorry> 1.0 Toolchain
[21:13:23] <Zorry> not mutch new there :(
[21:13:39] <Zorry> gcc 4.8 still on stage3
[21:14:09] <Zorry> will start with the patches when it geting to is end
[21:14:10] <SwifT> crap, can't even find him info through a mthode.org whois... "Obfuscated whois"
[21:15:05] <blueness> Zorry, are you moving to the new spec_driver with only one profile, 100% hardened?
[21:15:08] <Zorry> will most likly use the some backport of that i did try upstream
[21:15:29] <Zorry> blueness: some thing like that
[21:15:33] <blueness> k
[21:15:38] <blueness> where will that leave mips?
[21:15:51] <Zorry> full supported :)
[21:15:55] <blueness> excellent
[21:16:13] <blueness> we have all the arches then, except ia64 which never had ssp
[21:16:16] <Zorry> and hardenedno will be gone
[21:16:23] <blueness> no problem
[21:17:22] <Zorry> that is the gcc stuff
[21:17:45] <blueness> i have a few shorts about uclibc
[21:17:49] <Zorry> glibc 2.16 hit the tree and have it problems with pax
[21:18:02] <blueness> yeah i was going to talk about that
[21:18:03] <Zorry> more on that on the kernel topic
[21:18:19] <Zorry> blueness uclibc
[21:18:46] <blueness> not much just a quikc report
[21:19:04] <blueness> 1) full catalyst for amd64, i686 and mips32r2
[21:19:19] <blueness> 2) working on armv7a right now
[21:19:28] <blueness> 3) will work on mipsel later
[21:19:43] <blueness> but once that's done, everything is automated and i can move on to other things
[21:19:44] <SwifT> with full catalyst, you mean that stages are autobuilt now?
[21:19:48] <blueness> yes
[21:20:10] <blueness> i do have to populate /etc/portage a little
[21:20:33] <blueness> but that's okay because catalyst fully supports that and it makes its way into the deliverable stages
[21:20:53] <blueness> so this effort is reaching a stable plateau
[21:21:23] <blueness> i have yet to fix up the documentation to address issues brought up by klondike but other than that, its in production
[21:21:39] <blueness> okay that's it
[21:21:55] <Zorry> some else?
[21:22:08] <Zorry> next then
[21:22:25] <Zorry> 2.0 Kernel, Grsec/PaX
[21:22:56] <blueness> okay first pure kernel, i have had some difficulty stabilizing a 3.6.x kernel, some configurations give panics
[21:23:24] <blueness> upstream was in some flux but i'm hoping maybe the latest will be stable else i have to push bug reports their way
[21:23:32] <blueness> until then we're still stable on 3.5.4
[21:24:02] <blueness> next point, tmpfs xattr support has been extended to user.* namespace
[21:24:17] <blueness> we need that for full portage + xattr based pax flags
[21:24:39] <blueness> it was a simple patch but hard to convince myself that it was correct
[21:24:51] <blueness> and finally the big one ....
[21:25:16] <blueness> glibc-2.16 will be dropping the decls needed for PT_PAX from <elf.h>
[21:25:43] <blueness> and it will be dropping the patch for PT_PAX phdr from binutils
[21:26:05] <blueness> as a result, PT_PAX flags will go bye-bye and we will have only xattr based pax flags
[21:26:21] <blueness> so for the next few days i'm putting 100% of my energy into getting that ready
[21:26:45] <pipacs> you don't need to do much, do you?
[21:26:53] <blueness> nope not much
[21:27:05] <pipacs> for xattr you only care about binaries where you need something other than the defaults
[21:27:20] <pipacs> for the majority you don't need to set the xattr at all
[21:27:25] <blueness> i'm cleaning up the scripts after that misunderstanding of how the flags were interpreted in user.pax.flags
[21:27:40] <blueness> pipacs, yep but we also need a migration path
[21:27:52] <pipacs> migration for what?
[21:27:52] <blueness> i'll get it done in time
[21:28:00] <SwifT> the convern given last meeting about possible (kernel)memory overuse by userspace, is that covered ?
[21:28:00] <pipacs> the kernel will continue to parse the elf header
[21:28:02] <blueness> migration for systems invested in pt_pax
[21:28:13] <pipacs> but what's the worry there?
[21:28:27] <pipacs> users can recompile userland at their leisure
[21:28:34] <blueness> pipacs, true
[21:29:01] <pipacs> SwifT, yes, at least in pax i only allow setting user.pax.flags, nothing else, and its size is limited
[21:29:11] <blueness> pipacs, so for elf binaries that have *only* PT_PAX markings and no user.pax.flags field, it will revert to just PT_PAX
[21:29:28] <pipacs> yup
[21:29:31] <blueness> and for elf binaries that have *only* XATTR pax flags, it will use those
[21:29:36] <pipacs> yes
[21:29:41] <blueness> and *only* if someon has both on must they be the same
[21:29:51] <pipacs> and if the binary has neither, then defaults will be used
[21:29:55] <SwifT> yes, but we'll probably want to check the same on the kernel patch, otherwise user scan use the setfattr on tmpfs systems they have access to (which usually is the case)
[21:29:56] <pipacs> depending on softmode
[21:30:02] <blueness> if the are not, then what? both PT_PAX and xattr flags are ignored and the default is ueds?
[21:30:04] <blueness> used?
[21:30:08] <pipacs> yes
[21:30:18] <blueness> okay i read the code correctly then
[21:30:34] <blueness> pipacs, not so much migration as communicating that to our users
[21:30:49] <blueness> and making sure our pax-utils.eclass is working
[21:30:58] <pipacs> yeah, but if the toolchain does the right thing, they won't even notice anything
[21:31:16] <blueness> okay
[21:31:24] <blueness> we'll be alright
[21:31:37] <blueness> okay i'm done, any questions?
[21:31:49] <SwifT> blueness: the idea from last meeting on restricting the user.* access for tmpfs, has that been checked?
[21:32:07] <blueness> restricting? or allowing?
[21:32:13] <SwifT> you know, to make sure regular (unprivileged) users cannot reserve too much (kernel)memory
[21:32:18] <pipacs> better question, will you use my user.* code in pax or something more generic?
[21:32:43] <pipacs> 'cos the user. support in pax is already properly restricted
[21:33:02] <SwifT> otherwise, users might just fill up memory through "while true; do setfattr -n user.${i} $((
[21:33:03] <pipacs> but if you need more then you'll have to change that code
[21:33:12] <SwifT> meh, pressed return too soon, but you get the idea
[21:33:30] <blueness> pipacs, i'm good with your restrictions, i think Swift is bringing up a different point
[21:33:57] <blueness> SwifT, i may have to return to that and make sure that that space is restricted to just user.pax.flags and that only 5 bytes can be used
[21:33:58] <SwifT> yes, its on the kernel side patch, the one blueness introduced to support user-level xattr on tmpfs
[21:34:14] <SwifT> blueness: that'd be a good solution, yes
[21:34:36] <blueness> SwifT, the function is a sanitizing function so all i need to is add more checks
[21:34:40] <blueness> i forgot about that issue
[21:34:48] <blueness> SwifT, you can always open a bug if i forget again
[21:34:53] <SwifT> will do
[21:35:17] <blueness> but yeah, unlike inode based xattrs, i'm not sure what would happen if you kept lopping on xattrs on tmpfs
[21:35:46] <blueness> hopefully there is a check elsewhere in kernel code, but let's make sure
[21:35:53] <schmitt953> ugh, I'm about to be dragged away for something that I don't want to go to, is selinux next?
[21:35:59] <schmitt953> (sorry to interrupt)
[21:36:09] <blueness> i'm done
[21:36:11] <blueness> thanks guys
[21:36:12] <Zorry> prometheanfire did have the global pax_kernel stuff
[21:36:27] <Zorry> the use flag thing
[21:36:28] <blueness> Zorry, yeah but i think vapier didn't like it, i didn't follow through why
[21:36:47] <blueness> he felt it wasn't a very useful flag, but i cannot recall his argument
[21:37:00] <pipacs> the kernel itself restricts individual xattrs to 64k
[21:37:02] <pipacs> so that's one limit
[21:37:27] <pipacs> in pax i restrict the user. namespace to a single specific value (pax.flags), so that's all you can set under pax on tmpfs
[21:37:35] <Zorry> blueness: okay we take it later in the meeting if he get here
[21:37:40] <pipacs> now you can relax that code at your peril ;P
[21:37:53] <blueness> pipacs, no need to relax it
[21:38:47] <SwifT> it's easily tested, just opened the bug so we can track it if needed
[21:39:06] <pipacs> so swift's concern is moot? ;)
[21:39:14] <pipacs> or i must be missing something here
[21:39:44] <blueness> pipacs, its in the tmpfs patch i created
[21:39:49] <blueness> not in your code
[21:40:04] <blueness> tmpfs was *only* allowing trusted name spaces for selinux
[21:40:05] <SwifT> pipacs: if, "with pax" you mean that on kernel-level the pax patches restrict xattr "user" category access for tmpfs, then perhaps... I don't know the details
[21:40:09] <pipacs> yes but that code will collide with mine
[21:40:14] <pipacs> you'll have to resolve that
[21:40:19] <blueness> pipacs, how will it collide?
[21:40:29] <pipacs> we change the same code? ;)
[21:40:31] <blueness> now i think i'm missing something
[21:40:43] <blueness> pipacs, i don't think so
[21:40:46] <pipacs> i do :P
[21:40:50] <blueness> did you touch anything in tmfps?
[21:40:54] <pipacs> given that i looked at your patch before i wrote mine
[21:40:56] <blueness> tmpfs
[21:40:57] <pipacs> yes
[21:41:09] <pipacs> how else could i have added suppor for the pax flags on tmpfs ;P
[21:41:12] <SwifT> perhaps we should just wait and see ;)
[21:41:13] <blueness> oh, i didn't see htat
[21:42:09] <blueness> pipacs, i'm talking about in mm/shmem.c
[21:42:26] <pipacs> me too
[21:42:33] <pipacs> maybe look at the pax code some time ;P
[21:42:36] <blueness> k then we are conflicting i'll have to look
[21:43:11] <pipacs> that's why i asked if gentoo wants to go with my tmpfs/user.* code or yours
[21:43:29] <pipacs> 'cos in my case the size problem is solved, but at the price of restricting the namespace
[21:43:39] <pipacs> i think i even mentioned it in a gentoo bug
[21:43:44] <blueness> pipacs, well yours but i didn't even know it was there
[21:43:54] <blueness> 1 sec this is an easy check
[21:44:04] <SwifT> blueness' patch got upstreamed and updated without him knowing ;)
[21:44:29] <blueness> pipacs, i see i now
[21:44:40] <blueness> +#ifdef CONFIG_PAX_XATTR_PAX_FLAGS
[21:44:40] <blueness> + { XATTR_USER_PREFIX, XATTR_USER_PREFIX_LEN},
[21:44:40] <blueness> +#endif
[21:44:42] <blueness> and then
[21:44:48] <pipacs> i'm prett sure i mentioned it in public ;)
[21:44:51] <blueness> +#ifdef CONFIG_PAX_XATTR_PAX_FLAGS
[21:44:51] <blueness> + if (!strncmp(name, XATTR_USER_PREFIX, XATTR_USER_PREFIX_LEN)) {
[21:44:51] <blueness> + if (strcmp(name, XATTR_NAME_PAX_FLAGS))
[21:44:51] <blueness> + return -EOPNOTSUPP;
[21:44:52] <blueness> + if (size > 8)
[21:44:52] <blueness> + return -EINVAL;
[21:44:54] <blueness> + }
[21:44:56] <blueness> +#endif
[21:44:58] <blueness> +
[21:45:00] <blueness> so that does it!
[21:45:15] <blueness> pipacs, you may have
[21:45:38] <blueness> anyhow i see the check SwifT wants is there
[21:45:38] <blueness> so we're done!
[21:45:38] <blueness> drop my pathc
[21:45:38] <SwifT> ok then, topic resolved ;)
[21:45:41] <blueness> yeah
[21:45:58] <blueness> that second hunk is the "fix"
[21:46:02] <pipacs> it's only insufficient if you expect more stuff under user.*
[21:46:07] <pipacs> then my code won't be enough
[21:46:10] <blueness> pipacs, no its fine
[21:46:46] <blueness> i'm glad that point came up
[21:47:07] <Zorry> any thing more or next?
[21:47:15] <blueness> i'm done
[21:47:28] <blueness> (and my dog also says "FEED ME NOW")
[21:47:34] <Zorry> 3.0 Selinux
[21:47:39] <schmitt953> yay
[21:47:48] <Zorry> SwifT:
[21:47:49] <schmitt953> can I go first because I'm already 20 minutes late to a meeting
[21:47:58] <SwifT> schmitt953: sure, go ahead
[21:48:25] <schmitt953> two things, I'll test the selinux-kerberos issues I noticed, the second thing is I got samba-4.0.0 to build with selinux enabled
[21:48:50] <schmitt953> I don't know how much selinux has been tested with samba 4 but upstream had some guidelines for its policies along with policies for BIND and selinux
[21:48:51] <SwifT> schmitt953: keep close track of everything you get (both denial as well as application errors)
[21:48:57] <schmitt953> I will do that
[21:49:05] <schmitt953> has anything been done in regards to samba 4 and selinux?
[21:49:23] <SwifT> nothing specific; I think we'll notice a few updates from fedora soon on this
[21:49:29] <schmitt953> I have some VMs ready in that regard but it may also involve patching the selinux policy for bind in a samba 4 active directory domain
[21:49:35] <schmitt953> so it won't just be for the samba package
[21:49:56] <schmitt953> (and if selinux is running under bind it needs some policies in regards to the kerberos keytab)
[21:50:24] <schmitt953> SwifT: I'll follow the email list and see if we can get updates, we may have to do some things on our own since they don't even support samba 4 yet
[21:50:32] <SwifT> could be... make sure you test on the latest repo for those things (the live ebuilds) as there are often changes trickling in from debian & fedora as well
[21:50:35] <schmitt953> (Gentoo is the first distro to have it in their tree I think)
[21:50:49] <schmitt953> I can do that, by latest do you mean ~amd64?
[21:51:03] <schmitt953> or is stable ok
[21:51:04] <SwifT> no, they're not keyworded
[21:51:08] <schmitt953> ok
[21:51:18] <SwifT> you'll need to add in a "sec-policy/* **" in your package.accept_keywords
[21:51:25] <schmitt953> I will do that I synced the VMs yesterday and samba 4 has some notes for selinux
[21:51:30] <SwifT> then regularly rebuild (emerge $(qlist -IC sec-policy))
[21:52:12] <schmitt953> I will, I'll take a look at the selinux-samba package too in case there's something we need to add to samba 4 before fedora does it
[21:52:24] <SwifT> k
[21:52:29] <SwifT> much appreciated ;)
[21:53:02] <SwifT> anything more?
[21:53:07] <schmitt953> nope I'm good
[21:53:11] <SwifT> k then
[21:53:11] <schmitt953> thanks for letting me jump ahead
[21:53:19] <SwifT> the SELinux userspace utilities have been stabilized
[21:53:33] <SwifT> at least, all except for setools-3.3.7-r5 due to a swig incompatibility with apol application
[21:53:44] <SwifT> that should be "worked around" in -r6 (currently ~arch)
[21:54:00] <SwifT> worked around as in: require swig-1 instead of swig-2
[21:54:14] <SwifT> i'm tired of trying to fix ugly code to work with ugly libraries and tools like swig
[21:54:24] <SwifT> so I'm just going to follow what upstream tells
[21:54:50] <SwifT> swig-1 is a build dependency, not a runtime dependency, so that shouldn't hurt too much
[21:55:15] <SwifT> next to the userspace utilities, the r8 policies are in the main tree, ~arch'ed, but I will stabilize tomorrow
[21:55:20] <prometheanfire> meeting?
[21:55:24] <SwifT> (unless major breakage is suddenly reported)
[21:55:33] -*- prometheanfire is late :(
[21:55:41] <Zorry> prometheanfire: yes you are
[21:55:47] <SwifT> I'll also be pushing out a r9 to the hardened-development overlay with the new set of updates on it
[21:56:03] <SwifT> I'm just chewing through a few changes on cron/at support, but they're almost finished
[21:56:06] <prometheanfire> at least I'm not pregnant
[21:56:13] <SwifT> lol
[21:56:19] <SwifT> well, that's it for SELinux from me
[21:56:47] <Aleister> prometheanfire: what ever you say arnold
[21:56:49] <Anarchy> Sup fellas
[21:57:08] <Zorry> any one else?
[21:57:12] <Zorry> next else
[21:57:19] <blueness> yes next
[21:57:21] <Zorry> 4.0 Profiles
[21:57:41] <blueness> one minor update
[21:57:55] <Zorry> nvidia have ben unmasked but still have X and tools use flag masked
[21:58:13] <Zorry> and is only on 304.60 and newer
[21:58:51] <blueness> Zero_Chaos, wanted it but i've never really gotten around to testing it
[21:59:19] <blueness> i'm not sure about the newer nvidia drivers, but the older ones always failed for me under a pax kernel
[21:59:49] <blueness> i have one minor announcements on the profiles
[21:59:56] <blueness> i've added: arm hardened/linux/uclibc/arm/armv7a dev
[22:00:19] <blueness> to the official profiles.desc since i'm almost done with catalyst stages
[22:00:35] <blueness> i make these profiles "public" when catalyst works on them
[22:00:55] <blueness> <done>
[22:01:15] <Zorry> any one esle?
[22:01:37] <Zorry> 5.0 System interity
[22:01:59] <Zorry> or we take prometheanfire pax_kernel
[22:02:00] <SwifT> not that much to say - 3.7 is out, which includes an important patch that we needed
[22:02:11] <SwifT> but I haven't gotten around to testing it yet due to work :(
[22:02:20] <SwifT> so expect more updates by the next meeting
[22:02:27] <Zorry> k
[22:03:09] <SwifT> let's let prometheanfire do some typing on pax_kernel ;)
[22:03:09] <Zorry> 6.0 Docs
[22:03:11] <prometheanfire> ok, I guess I'll just go on about pax_kernel
[22:03:21] <prometheanfire> or 6.0 :P
[22:03:22] <Zorry> gogo
[22:04:02] <Zorry> prometheanfire: do it
[22:04:20] <prometheanfire> I want to get pax_kernel as a global use flag but some were worried that since paxctl was not installed by default and the flag requires it we cannot make it a global flag
[22:04:42] <pipacs> what's pax_kernel mean anyway?
[22:04:55] <pipacs> seems to be used for different things
[22:04:57] <prometheanfire> pipacs: just a flag we use to either patch or packmark stuff
[22:05:11] <prometheanfire> it's only those two things from what I've seen
[22:05:22] <pipacs> i saw it used for kernel modules too
[22:05:26] <pipacs> like nvidia ;P
[22:05:30] <blueness> pax_kernel has a very specific meaning ...
[22:05:41] <pipacs> yeah, spell it out for me please ;)
[22:05:41] <prometheanfire> blueness: go ahead :D
[22:05:59] <blueness> it refers to what needs to be done to userland utility so that it works if it were run under a pax enabled kernel
[22:06:12] <blueness> but should make no difference for vanilla kernel
[22:06:29] <blueness> so you should do USE="pax_kernel" for any userland program that *might* be run under a pax kernel
[22:06:39] <pipacs> what about kernel modules?
[22:06:44] <pipacs> 'cos nvidia-drivers has it
[22:06:48] <blueness> nope shouldn't really
[22:07:04] <blueness> well ... i'd have to look at it
[22:07:18] <Zorry> it is for patching it
[22:07:19] <blueness> what are they doing compiling out of tree kernel modules?
[22:07:19] <prometheanfire> it uses it for patching
[22:07:22] <pipacs> the kernel module gets patched then to allow it to load under kernexec/etc
[22:07:23] <blueness> ah
[22:07:34] <blueness> well makes sense
[22:07:38] <SwifT> prometheanfire: selinux is a global use flag, but the USE is masked on non-selinux profiles
[22:07:48] <SwifT> prometheanfire: perhaps a similar approach can be used for pax_kernel?
[22:08:01] <blueness> SwifT, its not the same because USE="selinux" messes things up on a non-selinux system
[22:08:12] <prometheanfire> I don't think the definition is in question, just if a global use flag has to have it's helper util installed by defualt on ALL systems
[22:08:17] <SwifT> doesn't mess things up, just won't work :p
[22:08:18] <blueness> but pax_kernel should do nothing on a vanilla system, but maybe ... with the modules ... it does
[22:08:25] <prometheanfire> SwifT: I was thinking about the use.mask as well
[22:08:27] <blueness> SwifT, tru
[22:08:35] <pipacs> well, you see, the nvidia kernel patch has nothing to do with paxctl
[22:08:43] <blueness> right
[22:08:57] <pipacs> that's why i don't see the clear purpose behind this use flag
[22:09:17] <ryao> Hi pipacs. Welcome to freenode. :)
[22:09:27] <blueness> pipacs, it was originally as i said
[22:09:39] <prometheanfire> the purpose for me is the following 'make package work with pax enabled kernel'
[22:09:53] <blueness> to distinguish between toolchian hardening and pax hardening
[22:09:57] <pipacs> prometheanfire, but then it may or may not depend on the presence of paxctl
[22:10:02] <pipacs> which is what blueness was arguing for
[22:10:06] <pipacs> so make up your mind ;)
[22:10:20] <SwifT> blueness: if it shouldn't do anything on a vanilla system, just have use.mask pax_kernel and it won't be possible to enable it (which shouldn't hurt either) and if enabled, you can depend on paxctl all you like as it means you're in a hardened profile anyhow
[22:10:30] <prometheanfire> I was arguing to make it a generic flag :P
[22:11:01] <blueness> prometheanfire, you know what, let's leave it local and let its meaning "slur" a little
[22:11:06] <SwifT> unless there is need to support USE="pax_kernel" on a non-hardened profile
[22:11:21] <pipacs> sure there is
[22:11:22] <prometheanfire> blueness: ya fine with me, too much work for not enough gain
[22:11:27] <pipacs> i don't use hardened but i use a pax kernel ;)
[22:11:28] <blueness> i can live with not having a global clear meaning behind something, but locally defined contextual meanings
[22:11:59] <prometheanfire> ok, so moving forward it's gonna stay a local use flag
[22:12:07] <prometheanfire> Zorry: done :D
[22:12:31] <Zorry> some one else?
[22:12:45] <Zorry> 6.0 Docs
[22:12:46] <blueness> nah good enough!
[22:12:54] -*- blueness cringes!
[22:13:11] <Zorry> nothing new from my part
[22:13:19] <blueness> i will start documenting the xattr pax stuff
[22:13:21] <SwifT> for SELinux, I added in a few blurbs about USE=unconfined, which we'll be using from r9 policies onwards for mcs/mls selinux types
[22:13:45] <SwifT> but other than that no changes on hardened-related docs
[22:15:02] <Zorry> next then
[22:15:12] <Zorry> 7.0 bugs
[22:15:14] <blueness> SwifT, klondike seems busy these days, do you might looking over my stuff (and committing at will) when i get it up
[22:15:22] <blueness> ie the xattr pax stuff
[22:15:42] <SwifT> blueness: of course, no problem
[22:16:32] <SwifT> no bugs that need special attention from my part
[22:16:48] <blueness> Zorry, i just want to repeat what i said earlier and that is that i have been hitting some kernel panics with the 3.6 hardened sources, i haven't passed them upstream yet no filed them, but it is delaying stabilizatoin
[22:17:05] <blueness> if people could test 3.6.6 to 3.6.8 and let me know, much appreciated
[22:17:23] <blueness> i'm only hitting this on Chainsaw' HP proliant that he sent me
[22:18:04] <SwifT> blueness: any specific trigger?
[22:18:13] <SwifT> i'm on 3.6.7 for vms and workstation without problems
[22:18:47] <blueness> SwifT, not sure
[22:18:58] <N8Fear> I haven't had any panics with 3.6.6,3.6.7 or 3.6.8
[22:19:01] <blueness> it is a statically linked kernel
[22:19:14] <blueness> N8Fear, yeah i think its a corner case
[22:19:17] <Zorry> blueness: runing 3.6.8 on the tinderbox
[22:19:18] <pipacs> blueness, upstream as in kernel.org or us?
[22:19:30] <blueness> pipacs, its pax/grsec
[22:19:46] <pipacs> ok, do pass those bugs to us then ;)
[22:19:52] <blueness> pipacs, i didn't want to just send it to you without narrowing it down
[22:19:59] <blueness> i will do so this evening
[22:20:25] <pipacs> usually if i just get the first oops or similar, i can already ask the next question to help debug the problem
[22:22:31] <blueness> k i'll either narrow it or pass it along tinight
[22:22:35] <blueness> tonight
[22:22:50] <blueness> done?
[22:23:41] <Zorry> bug 417191
[22:23:43] <willikins> Zorry: https://bugs.gentoo.org/417191 "app-emulation/emul-linux-x86-gtklibs-20120520 needs pax marking - gtk-query-immodules-2.0-32: error while loading shared libraries: libGL.so.1: failed to map segment from shared object: Operation not permitted"; Gentoo Linux, Ebuilds; UNCO; powerman-asdf:amd64
[22:24:20] <Zorry> i think is okay to mark it if nvidia is install but not else
[22:24:58] <Zorry> we can't start to mark random
[22:25:03] <pipacs> pax-marking? or more like execstack -c?
[22:25:13] <Zorry> the opengl thing
[22:25:40] <pipacs> oh, that's a long standing issue, -m for all the affected binaries ;P
[22:25:56] <Zorry> yep
[22:25:59] <blueness> revdep-pax
[22:26:12] <Zorry> yep but no docs yet :(
[22:26:18] <blueness> i know!
[22:26:26] <blueness> i need to do that too
[22:26:32] <blueness> i need liek 2 of me
[22:26:39] <Zorry> or just add it to the wiki ?
[22:26:51] <Zorry> for now
[22:26:58] <blueness> or to stop taking on projects, i'm like bleeding heart dev, everytime i see a package that needs love i stop to help it
[22:27:37] <blueness> Zorry, the documentation should be long actually
[22:27:54] <blueness> htere's only like a few libraries like this
[22:28:00] <pipacs> blueness, what are your slaves^Wstudents doing? :)
[22:28:35] <blueness> twitch153|fulong, Nichols ^^^^ we need help
[22:28:40] <blueness> get you butts in here!
[22:28:42] <twitch153|fulong> Allo.
[22:28:46] <twitch153|fulong> I've been in here :D
[22:28:46] <SwifT> =)
[22:28:58] <blueness> we need slave labor
[22:29:12] <twitch153|fulong> Of what sort?
[22:29:19] <blueness> pipacs, the problem is it would take them a while to get up to documentation
[22:29:25] <blueness> i have to pass on more of my other work to them
[22:29:26] <SwifT> I got to go guys; hardly got any sleep lately. Don't think there's stuff left on the agenda anyway
[22:29:28] <blueness> to free up my time
[22:29:35] <Zorry> SwifT: gn8
[22:29:36] <pipacs> you have to start somewhere otherwise they'll never get there
[22:29:39] <blueness> SwifT, k good night
[22:29:41] <pipacs> now's as good as any tiem ;P
[22:29:43] <twitch153|fulong> SwifT, night :)
[22:29:47] <SwifT> good work guys; n8
[22:29:55] <blueness> twitch153|fulong, get working on the quizzes!
[22:29:59] <blueness> so we can get you commit
[22:30:13] <blueness> and you can take care of all my packages that i keep dragging in from the cold
[22:30:15] <twitch153|fulong> I was planning on working on them this weekend. :)
[22:30:20] <Zorry> blueness: hardened-doc ?
[22:30:24] <twitch153|fulong> But I suppose I can do it sooner.
[22:30:52] <blueness> Zorry, you mean i should commit to hardened-doc first?
[22:31:06] <blueness> i can i usually put stuff up right away but don't link it
[22:31:25] <Zorry> blueness: is up to you hoe to do it
[22:31:31] <blueness> k
[22:31:56] <blueness> so three docs to do: 1) clean up uclibc, 2) xattr pax, 3) revdep-pax
[22:33:28] <Zorry> next then
[22:33:46] <Zorry> 8.0 Media
[22:33:56] <Zorry> don't have anything there
[22:34:35] <Zorry> 9.0 Open floor
[22:34:40] <Zorry> any thing?
[22:34:58] <Zorry> else the meeting is done and ty all
