19:30:10 <nirik> #startmeeting FESCO (2010-06-22)
19:30:10 <zodbot> Meeting started Tue Jun 22 19:30:10 2010 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:30:10 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:30:10 <nirik> #meetingname fesco
19:30:10 <zodbot> The meeting name has been set to 'fesco'
19:30:10 <nirik> #chair mclasen notting nirik SMParrish kylem ajax pjones cwickert mjg59
19:30:10 <nirik> #topic init process
19:30:10 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik notting pjones
19:30:43 <nirik> who all is around for the fesco meeting?
19:30:51 <nirik> #info notting sends regrets today.
19:30:53 * mclasen is here
19:30:58 * SMParrish here
19:31:56 <kylem> yo
19:32:35 <nirik> #info pjones also going to be unable to attend today.
19:32:46 <mclasen> ajax may be out today, not sure
19:32:52 * LinuxCode is lurking
19:32:54 <mclasen> at least I haven't seen him in the office
19:33:16 <mclasen> and mjg59 was at home with a cold ?
19:33:52 <nirik> well, we need 1 more for quorum. ;(
19:34:20 <mclasen> cwickert ?
19:34:27 <gholms|lunch> cwickert, ajax:  ping?
19:36:23 <nirik> mjg59 was around eariler. ;(
19:37:12 <nirik> we do have some tickets where notting voted we could do.
19:37:52 <nirik> I guess lets do those and see if anyone arrives late for others.
19:38:03 <nirik> #topic #398 F14Feature: perl 5.12: https://fedoraproject.org/wiki/Features/perl5.12
19:38:03 <nirik> .fesco 398
19:38:05 <zodbot> nirik: #398 (F14Feature: perl 5.12: https://fedoraproject.org/wiki/Features/perl5.12) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/398
19:39:18 <mclasen> +1 from me, seems a no-brainer
19:39:18 <nirik> this is ok with me... +1
19:39:24 <mclasen> and the builds have already happened, no ?
19:39:40 <SMParrish> no problems here +1
19:39:55 <kylem> seems fine to me, +1.
19:39:59 * mclasen is still fighting to get perl off the live cd...
19:41:07 <nirik> #agreed this feature is approved.
19:41:10 <nirik> yes, they have landed.
19:41:25 <nirik> there is a bit of a mixup on some of them.
19:42:02 <nirik> Since the rebuilds happened in a seperate tag, and then in some cases people updated and rebuilt newer versions, then when the tag merged the old version is now in...
19:42:22 <nirik> perhaps we can identify those somehow and get maintainers to make sure and fix them.
19:42:40 <kylem> oops.
19:42:41 <kylem> yeah.
19:42:42 <mjg59> Hey, sorry I'm late
19:42:45 <nirik> #topic #399 F14Feature: Erlang R14: https://fedoraproject.org/wiki/Features/Erlang_R14
19:42:46 <nirik> .fesco 399
19:42:46 <mjg59> The bus was early
19:42:48 <zodbot> nirik: #399 (F14Feature: Erlang R14: https://fedoraproject.org/wiki/Features/Erlang_R14) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/399
19:42:50 <nirik> mjg59: welcome. ;)
19:43:09 <nirik> notting provided +1 in the ticket on this one.
19:43:10 <mjg59> (And so it passed me just before I got to the stop)
19:44:35 <nirik> +1 here for me... another lang update that is probibly worth touting.
19:44:49 <mjg59> Yeah, +1
19:44:49 <nirik> I sure hope the provides are not still crazy. ;)
19:44:59 <kylem> nirik, i was just thinking that.
19:45:17 <kylem> +1.
19:45:19 <mjg59> Well, that;s kind of orthogonal, I think
19:45:27 <nirik> mjg59: agreed.
19:46:20 <nirik> mclasen, SMParrish ?
19:46:32 * mclasen was distracted by another meeting, sorry
19:46:39 <SMParrish> sorry was on the phone   +1
19:46:45 <mclasen> no objections here; +1
19:46:52 <nirik> no worries.
19:46:57 <nirik> #agreed Feature is approved.
19:47:05 <nirik> #topic #400 F14Feature: AtSpiTwo https://fedoraproject.org/wiki/Features/AtSpiTwo
19:47:05 <nirik> .fesco 400
19:47:06 <zodbot> nirik: #400 (F14Feature: AtSpiTwo https://fedoraproject.org/wiki/Features/AtSpiTwo) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/400
19:47:15 <nirik> mclasen added a note to the ticket here.
19:47:32 <nirik> shall we just drop this feature and have it as part of gnome3?
19:47:35 <mclasen> yeah, I'd like to retract this, I think
19:47:42 <mclasen> it is really subsumed by gnome3
19:47:50 <mclasen> which also addresses nottings comment
19:48:00 <nirik> sounds good.
19:48:07 <mjg59> Having worked on accessibility software before, I'm very, very enthusiastic to see the old at-spi die
19:48:12 <nirik> Make sure and fold anything usefull from this feature page back to the gnome3 one?
19:48:33 <mclasen> mjg59: don't rejoice before you've tried the new stuff...
19:48:44 <nirik> #info This feature will be dropped and merged into the gnome3 feature.
19:48:48 <mclasen> many of the issues stay the same, unfortunately :-(
19:49:00 <mclasen> I will make it so
19:49:11 <nirik> thanks.
19:49:14 <nirik> #topic #351 Create a policy for updates - status report on implementation
19:49:15 <nirik> .fesco 351
19:49:16 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351
19:49:21 <nirik> Not sure if we have any news here.
19:49:32 <mjg59> We got some QA stuff from adamw on fedora-devel-list
19:49:34 <nirik> I need to ping lmacken again and see whats holding up the bodhi update.
19:49:45 <nirik> yeah, sounds like proventesters are coming along.
19:50:24 <adamw> yup, proventesters is basically ready to go whenever the bodhi stuff gets done.
19:50:28 <nirik> wwoods / jlaska: either of you guys around for a quick few line update on where autoqa is at?
19:50:42 <adamw> jlaska gave me a canned quote earlier, if he's not around
19:50:52 <jlaska> nirik: Hi there
19:50:57 <adamw> ah, he is
19:51:01 <nirik> cool.
19:51:06 <jlaska> nirik: lemme hit send on this terse email update I've not yet sent
19:51:45 <mclasen> adamw: I think I missed how proventesters relate to a bodhi update (sorry if that was explained somewhere...)
19:52:09 <adamw> mclasen: well, just that there's nothing for proventesters to *do* until we actually enable gating of updates
19:52:12 * jlaska gives adamw the proventester mic
19:52:51 <nirik> mclasen: proventesters would be people who provide karma for critical path updates... to see if they promote to updates from updates-testing.
19:52:57 <mclasen> so this will replace the 'needs rel-eng/qa' karma thing we currently have ?
19:53:10 <nirik> mclasen: yep. It will be 'proventesters'
19:53:11 <mclasen> I see, thanks
19:53:12 <nirik> https://fedoraproject.org/wiki/Package_update_acceptance_criteria
19:53:18 <adamw> I suppose we could start working on providing the feedback before we hit the switch on requiring proventester feedback, thinking about it. look at it as practice.
19:53:26 <gholms|work> Does membership in releng or qa imply membership in proventesters?
19:53:44 <adamw> we grandfathered people who'd been active in providing feedback as rel-eng/qa members into the proventesters group, iirc.
19:54:13 <adamw> but from now on, it's a separate mechanism - documented at https://fedoraproject.org/wiki/QA/JoinProvenTesters
19:54:15 <jlaska> adamw: right, so if you were a previously approved 'qa' member, you are now a member of 'proventesters'
19:55:15 * cwickert rushes in and is sorry to be late
19:55:17 <jlaska> nirik: autoqa update ... there are 2 main areas.  1) having a public instance, and 2) the automation itself
19:55:23 <nirik> so, bodhi update and we can enable the important packages/critpath part of the process, as well as the 'all other updates' section (I hope). That leaves autoqa still to be enabled/ready for everything in this to be implemented.
19:55:34 <nirik> welcome cwickert
19:55:37 <mclasen> cwickert: welcome
19:56:01 <jlaska> nirik: the infrastructure folks (smooge and mmcgrath) have done a lot of work to bring autoqa systems online this week.  A lot of progress there, with only several smaller tasks to knock out before that is complete
19:56:07 <adamw> james just sent a more verbose update to -devel: http://lists.fedoraproject.org/pipermail/devel/2010-June/137821.html
19:56:40 <nirik> excellent.
19:56:46 <cwickert> .fasinfo cwickert
19:56:47 <zodbot> cwickert: User: cwickert, Name: Christoph Wickert, email: christoph.wickert@googlemail.com, Creation: 2005-09-18, IRC Nick: cwickert@irc.freenode.net, Timezone: Europe/Berlin, Locale: de, Extension: 5100271, GPG key ID: 1999A427, Status: active
19:56:51 <zodbot> cwickert: Unapproved Groups: cvsadmin hosted-content
19:56:55 <zodbot> cwickert: Approved Groups: gitsecurity-spin gitnodoka cla_done fedorabugs +packager ambassadors cla_fedora gitspin-kickstarts provenpackager
19:56:57 <jlaska> nirik: the automation aspect has a lot of moving parts unfortunately, aside from the core test and event watcher to prevent introducing dependency or conflicts into the repos, there are a few other efforts we're trying to move forward on
19:57:17 <cwickert> jlaska: I'm not a proventester, but I used to be in qa once upon a time
19:57:27 <nirik> ok. Do you guys have a target you are shooting for for having it enabled? Alpha?
19:57:51 <adamw> cwickert: very few people were actually members of the fas 'qa' group, since it wasn't used for anything. i was never added to it until f13. so if you were in qa team you weren't necessarily in qa FAS group =)
19:58:04 <jlaska> nirik: Sorry, no I'm not prepared with one yet ... but you can put me down to provide that by next week
19:58:13 <cwickert> adamw: I was in the fas group
19:58:22 <nirik> jlaska: no worries... just wanted to know if there was one already.
19:58:22 <adamw> ah, k
19:58:45 <nirik> #action nirik will ping lmacken about bodhi update progress.
19:59:15 <nirik> #action jlaska will see about any target date for autoqa enablement
19:59:17 <adamw> well, proventesters membership list is at https://admin.fedoraproject.org/accounts/group/members/proventesters .
19:59:22 <jlaska> nirik: we've been trying to narrow the scope of our efforts recently, so I suspect we may need to do that even further so we can deliver something, even if it's limited in functionality at first
19:59:32 <nirik> jlaska: yeah.
20:00:09 <nirik> ok, anything else on this implementation today?
20:00:17 <nirik> sounds like things are moving... hopefully we can have something soon.
20:00:41 <jlaska> nirik: yeah, things are moving in a positive direction.  Just too much in the backlog
20:00:47 <nirik> yeah.
20:01:05 <nirik> ok, moving along to the related topic...
20:01:08 <nirik> #topic #382 Implementing Stable Release Vision
20:01:08 <nirik> .fesco 382
20:01:10 <zodbot> nirik: #382 (Implementing Stable Release Vision) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/382
20:01:34 <nirik> I'd like to ask folks to take a few minutes now or later to add ideas to: https://fedoraproject.org/wiki/Stable_release_updates_vision_implementation_ideas
20:02:33 <nirik> ideally we should have some ideas for all the Board points...
20:02:43 <nirik> and we can choose which we want to try and get done and by when.
20:03:25 <mjg59> Right
20:03:55 <cwickert> stupid question because I still suffer from 4 weeks absence: have we already accepted the stable release updates vision?
20:04:03 <cwickert> where "we" is "Fesco"
20:04:28 <nirik> cwickert: yeah, see the ticket. We said we pretty much accept it... of course if we have reservations or want changes we could ask the Board anytime.
20:05:18 <nirik> or ask them to reword/change things, etc.
20:05:30 <cwickert> ok, the second point still gives me a little headache, but I guess most people are fine with it
20:06:24 <nirik> yeah, there is going to have to be some exception process/wiggle room there I think.
20:07:01 <cwickert> I think it is open to interpretation, so it's ok, lets implement it
20:07:58 <nirik> "consistent user experience" could be subjective somewhat... and also must weigh against things like security updates or things that need to consume outside resources to work (virus scanners, game clients, etc)
20:08:20 <nirik> but we could add that to our implementation and see if the Board objects or wants to clarify, IMHO
20:08:25 <mjg59> And sometimes we get caught in tight cases, like Mozilla dropping security support of a branch
20:08:38 <mjg59> We'll see what's reasonable
20:09:10 <nirik> or projects that do a constant stream of small bugfixes + new small features... there's no clear major version changes to gate on.
20:09:25 <cwickert> I recently had a case where I pushed an update that was everthing but a consistent user experience (gnome-applet-alarm-clock is not an applet any longer but a tray icon), but I guess it is ok since it was a bugfix for half a dozen of crashes
20:09:35 <nirik> anyhow, if folks could try and update that wiki page some over the next week, we could look at the pool of ideas next week.
20:10:18 <nirik> we could also solicit ideas from the community? or should we try and start with just fesco folks?
20:10:51 <kylem> i'll make a note to look at the wiki page tomorrow.
20:11:26 <nirik> I'd like to get more ideas personally, althought asking for them on devel will likely start another flamethread.
20:11:31 <cwickert> has this been discussed on devel list or are we afraid of an endless thread?
20:11:41 <mjg59> I think we're better off presenting our take first
20:12:01 <SMParrish> I agree with mjg59, get a list of our ideas then present and ask for comments
20:12:11 <nirik> cwickert: it has several times, but not specificially asking for ideas for implementing the Board's vision statement.
20:12:20 <cwickert> nirik: just what I was thinking, but I think we need to go that way. it will become a flamewar, but we cannot do it without the community
20:12:51 <nirik> perhaps add our ideas this week and then ask for more next week after we have some already down?
20:13:01 <mjg59> Yeah, I don't think we're going to impose anything without people having a chance to comment
20:13:48 <nirik> totally agreed. And the community may think of clever things we don't.
20:14:03 * nirik is fine with asking for input now, or waiting a week for more.
20:14:27 <nirik> Or those people who read fesco minutes could comment anytime... and we can put out a more general RFC next week?
20:14:51 <mjg59> Yeah
20:14:54 <mjg59> That seems fair
20:15:12 <nirik> any objections to that ?
20:15:25 <kylem> not from me. sounds reasonable.
20:15:38 <nirik> #info If you are reading this, feel free to add implementation ideas to https://fedoraproject.org/wiki/Stable_release_updates_vision_implementation_ideas
20:15:54 <nirik> ok, anything else on this this week?
20:15:59 <kylem> pretty sure someone will just mail f-devel-list ocne they read the minutes and it will explode on the list into a flamewar though. maybe my glass is just half full.
20:16:00 * nirik will move on in a few if nothing.
20:16:08 <nirik> kylem: yeah, could be.
20:16:31 <nirik> #topic #387 compile list of supported CPUs and reacto to recent loss of support for Geode LX on F13
20:16:31 <nirik> .fesco 387
20:16:33 <zodbot> nirik: #387 (compile list of supported CPUs and react to recent loss of support for Geode LX on F13) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/387
20:16:42 * cjb appears, hello.
20:16:46 * kylem groans.
20:17:09 <nirik> I was out last week, so not sure where we are here.
20:17:10 <mclasen> I added an update to that before the meeting
20:17:21 <cjb> For F13:  patch here:  https://bugzilla.redhat.com/show_bug.cgi?id=579838#c19
20:17:31 <nirik> Did we get buy in to change glibc?
20:17:37 <cjb> mclasen: oh?  it must be in another bug..
20:17:52 <cjb> nirik: yup, for F13
20:18:07 <nirik> cjb: in the fesco ticket
20:18:10 <cjb> so we just need someone to review/apply the patch.  any volunteers?
20:18:17 <cjb> oh, right
20:18:34 <nirik> cjb: we are forcing the maintainer? have we asked them nicely to apply it?
20:19:16 <cjb> nirik: yes, AIUI we're forcing the maintainers; they consider the bug WONTFIX, and FESCo doesn't.
20:19:35 <cjb> (I wouldn't say that we're forcing them to accept *this* patch, but it does seem correct that we're forcing them to accept *a* patch.)
20:20:10 <kylem> this doesn't seem like the correct way to do this to me. basically anything that uses -mtune=i686 is broken, no?
20:20:38 <mclasen> where anything == only glibc, right ?
20:20:46 <cjb> kylem: that doesn't sound right to me.  we're simply telling glibc's Makefilenot to invoke AS with -mtune=i686
20:20:53 <nirik> well, I guess the question is: is a Geode LX a i686?
20:20:58 <cjb> s/Makefilenot/Makefile not/
20:21:05 <cjb> nirik: There's backstory here too.
20:21:06 <mjg59> nirik: Yes, but also no
20:21:18 <nirik> yeah, I know... it's a mess.
20:21:28 <kylem> -mtune=cpu-type
20:21:28 <kylem> Tune to cpu-type everything applicable about the generated code, except for the ABI and the set
20:21:31 <kylem> of available instructions.  The choices for cpu-type are:
20:21:32 <kylem> soudns like gcc is broken.
20:21:35 <mjg59> kylem: Anything that passes -mtune=i686 to as, not gcc
20:21:45 <cjb> mjg59: not anything, just glibc
20:21:56 <mjg59> cjb: Does anything else pass it to as?
20:22:00 <cjb> nope.
20:22:11 <mjg59> Right, so I bet if anything else did we'd also see problems
20:22:17 <cjb> oh, right
20:22:25 <nirik> well, I would like to see if we can get the glibc maintainer to accept the patch or a similar one to do what we want... there's not been comment from them recently on the bug...
20:22:28 <cjb> mjg59: I thought kylem was talking about what *this patch* does.
20:22:32 <cjb> not what our policy does
20:22:44 <kylem> -mtune is only supposed to order code, if it's adding new instructions (contrary to the -march) then gcc/binutils are fucked, not glibc.
20:22:46 <mjg59> gcc and binutils both assume that 686 includes the full P6 instruction set
20:22:52 <kylem> glibc appears to be correctly using -mtune...
20:22:58 <mjg59> kylem: binutils interprets mtune differently to gcc
20:23:06 <cjb> nirik: sure.  our interactions with them consisted of them closing the bug WONTFIX, so that's why we're here at FESCo instead.
20:23:13 <mjg59> kylem: In binutils it implies march
20:23:29 <cjb> I think if someone on FESCo could volunteer to have a conversation with the glibc maintainers with a view to applying the patch or something like it, that would be a fine outcome.
20:23:30 <kylem> sigh.
20:23:35 <kylem> fucking novices.
20:24:05 <kylem> probably easier to patch binutils to ignore mtune and respect march. :)
20:24:10 <mjg59> In the long run we either need to "fix" binutils or come up with a kernel emulation approach that upstream don't hate
20:24:28 <mjg59> And there's also no guarantee that gcc won't start emitting other 686 instructions that geode doesn't have
20:24:42 * nirik doesn't care where the fix happens, as long as we can make f13 support this cpu and hopefully f14+ as well.
20:24:55 <cjb> mjg59: no guarantee, but also no evidence that it's likely.
20:25:10 <mjg59> Although I ahve to admit that emulating nops sounds about as elegant as an atomic blast
20:25:14 <kylem> if we default to -march=i686, then geode is unsupported because it's *not* i686.
20:25:26 <mjg59> kylem: It is. It's just not what gcc considers i686.
20:25:37 <cjb> kylem: you're redefining 686 to mean "Intel(tm) processors".
20:25:59 <mjg59> cmov was what used to trip us up, so we just dropped everything that doesn't support cmov
20:26:11 <kylem> cjb, well, when you clone someone elses shit, at least do a complete job of it.
20:26:13 <mjg59> Geode supports cmov but doesn't support some nop versions that gas now emits
20:26:21 <kylem> yes, we're all aware of this.
20:26:26 <mjg59> kylem: 686 is a documetned microarchitecture
20:26:36 <cjb> what mjg59 said.  the documentation doesn't include NOPL.  :)
20:26:38 <mjg59> And some of the instructions aren't documented as being required
20:27:08 <nirik> is there any way we could get gcc/binutils/glibc folks in a dialog and say: we want to support this cpu. Where can we fix this? Or is that unlikely to do anything?
20:27:23 <mjg59> nirik: I suspect that they'll just tell us to use 586
20:28:35 <nirik> applying a patch they don't want to support or agree with also seems non ideal.
20:28:41 <mjg59> It'd be a lot easier if OLPC weren't photogenic
20:28:54 <mjg59> (And also if we hadn't said that it was supported for this cycle)
20:29:10 <nirik> so, how do we move forward?
20:29:15 <cjb> yes, for F13 the problem is clearly that we broke support for a specifically-supported CPU.
20:29:34 <cjb> (where we == the gcc/glibc maintainers.)
20:29:38 <mjg59> The easiest thing to do is to apply this patch and drop Geode LX for F14
20:30:17 <kylem> easiest thing to do is drop i686 entirely. ;-)
20:30:20 <mjg59> This patch isn't a long term fix, so we either need the toolchain to stop emitting these instructions or we need the kernel to emulate them
20:30:28 <mclasen> f13 is a case of broken promises
20:30:40 <mjg59> But for F13 I think this patch is the correct approach
20:30:59 <nirik> mjg59: ok, would you like to apply it? ;)
20:31:01 <kylem> i'll talk to jakub/andreas about it.
20:31:13 <cjb> kylem: thanks!
20:31:14 <nirik> kylem: ok.
20:31:24 <cjb> sounds like we're nearly done with F13, at least
20:31:27 <mjg59> The less-confrontational approach to the toolchain would possibly be to try to create an i686-lite arch
20:31:37 <nirik> #action kylem will talk to glibc maintainers about the patch.
20:31:42 <kylem> i suspect they didn't intend -mtune on as to be braindead.
20:31:49 <kylem> (i certainly didn't.)
20:31:51 * gholms|work rings the 15 minute bell
20:32:03 <nirik> yeah, anything more on this, or are we done with it for now?
20:32:14 <cjb> nirik: well, the F14 policy
20:32:23 <cwickert> I don't think there is much we can do atm, let kylem to to them
20:32:42 <cjb> we could build i586 + i686 RPMs in koji
20:32:47 <nirik> cjb: yeah, might depend on how we can solve this in f13... and/or what the maintainers suggest...
20:33:11 <cjb> nirik: yep.  if you want to postpone the F14 discussion until next time, it's okay with me.
20:33:18 <nirik> cjb: yeah, I think thats best...
20:33:31 <nirik> Thanks for working on that patch cjb
20:33:33 <cjb> I'd like to hear some feedback on the i586+i686 idea next time.
20:33:52 <cjb> nirik: ah, the patch is from dsd; he couldn't make it here this week.
20:34:08 <nirik> oh, ok. ;)
20:34:14 <cjb> we were also talking, last week, about the possibility of moving i586 to secondary arch
20:34:30 <nirik> cjb: yeah, mclasen added some info on that to the fesco ticket.
20:34:46 <cjb> if FESCo decides not to keep LX support in F14, I think that's something we'd want help in setting up
20:35:25 * nirik would like to see us keep it if possible, but I think it will depend on how it gets "fixed"
20:35:36 <nirik> ok, moving on...
20:35:42 <cjb> Okay, thanks all.
20:35:48 <nirik> #topic FES tickets roundup
20:35:52 <nirik> https://fedorahosted.org/fedora-engineering-services/report/6
20:36:02 <nirik> mmcgrath is out at the summit, so might not be around.
20:36:21 <nirik> Not sure there is much to report this week...
20:36:39 <nirik> I'll be filing some more tickets soon I think... hopefully we can get some more things moving along.
20:37:31 <nirik> #topic Open Floor
20:37:37 <nirik> Anything for open floor?
20:37:57 * mclasen notes that live cds seem to be not booting lately
20:38:07 <mclasen> my rawhide spins last week all failed to boot
20:38:10 <nirik> not booting at all? or not booting once installed?
20:38:19 <mclasen> not booting at all
20:38:24 <mclasen> something about not finding root
20:38:38 <nirik> huh. I thought that was only after installed... ;(
20:38:44 * nirik hasn't tried them recently.
20:39:07 <nirik> dracut or livecd-tools bug I guess.
20:39:57 * nirik will close out the meeting in a few if nothing else comes up.
20:40:46 <mclasen> nirik: I was thinking the same, but couldn't really come up with anything concrete enough yet to file a bug
20:41:28 <gholms|work> Anything new with systemd?
20:41:53 <nirik> gholms|work: in what sense? selinux support was being worked on eariler I saw.
20:42:07 <gholms|work> There was talk earlier of making it the default, which would probably need to go through you folks.  I'm not sure if anything came of that.
20:42:42 <nirik> it was approved as a feature last week I think.
20:42:51 <nirik> I don't know if that included making it default.
20:42:55 <gholms|work> Yeah, but not as the default.
20:43:05 <nirik> I would like to see more positive testing before making it default.
20:43:08 <gholms|work> That needed to come back here for approval.
20:43:15 <nirik> ie, a bunch of people trying it out and showing that it worked for them.
20:43:52 <mclasen> gholms|work: still too early to decide
20:43:55 <nirik> yeah.
20:44:09 <gholms|work> Okee dokee
20:44:43 <nirik> ok, thanks for coming everyone!
20:44:47 <nirik> #endmeeting