17:30:03 <nirik> #startmeeting FESCO (2011-06-08)
17:30:03 <zodbot> Meeting started Wed Jun  8 17:30:03 2011 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:30:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:30:03 <nirik> #meetingname fesco
17:30:03 <nirik> #chair mclasen notting nirik SMParrish kylem ajax cwickert mjg59 mmaslano
17:30:03 <nirik> #topic init process
17:30:03 <zodbot> The meeting name has been set to 'fesco'
17:30:03 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 mmaslano nirik notting
17:31:11 <mjg59> Afternoon
17:31:16 <mmaslano> hello
17:31:24 <nirik> morning
17:32:01 <ajax> buenos dias
17:32:15 <kylem> yoyosup.
17:32:29 * cwickert is here but pretty busy
17:32:40 <nirik> I guess thats enough folks... lets go ahead and dive in.
17:32:50 <nirik> #topic #563 suggested policy: all daemons must set RELRO and PIE flags
17:32:50 <nirik> .fesco 563
17:32:51 <zodbot> nirik: #563 (suggested policy: all daemons must set RELRO and PIE flags) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/563
17:32:54 <nirik> ajax: any news on this one?
17:33:17 <kylem> nirik, i dropped the ball on this, and haven't followed up with the binutils folks.
17:33:26 <kylem> sent a ping this morning though.
17:33:30 <nirik> ok, no worries.
17:33:41 <ajax> still not urgent, not like a mass rebuild is scheduled soon.
17:33:45 <nirik> so it was some package that broke in a weird way, right?
17:34:02 <ajax> it's a little more subtle.
17:34:15 <kylem> nirik, anything that uses symbol names which conflict with a library will have some issues.
17:34:18 <ajax> short answer is "-fPIE implies -rdynamic and that seems unintentional"
17:34:26 <kylem> ^^ what ajax said. :)
17:34:34 * nirik nods. ok.
17:34:40 <nirik> ok, revisit next week...
17:34:50 <kylem> i'll try to drag one or two of them to the meeting next week, if possible.
17:34:59 <nirik> sounds good.
17:35:08 <nirik> #action defer until next week.
17:35:12 <nirik> #topic #594 F16Feature: F16 BTRFS default file system - http://fedoraproject.org/wiki/Features/F16BtrfsDefaultFs
17:35:12 <nirik> .fesco 594
17:35:13 <zodbot> nirik: #594 (F16Feature: F16 BTRFS default file system - http://fedoraproject.org/wiki/Features/F16BtrfsDefaultFs) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/594
17:35:25 <nirik> so, we got a bit more info from josef. He's unable to attend today.
17:35:37 <mmaslano> I've added some question on Talk page
17:35:51 <mmaslano> so, hopefully he'll be able to answer them
17:35:53 <nirik> so, do we need more info? we were going to look at adding criteria.
17:36:12 <nirik> ie, it must do this by feature freeze, etc.
17:37:12 <gholms> https://bugzilla.redhat.com/show_bug.cgi?id=689509 <- btrfs tracker bug
17:37:16 <mmaslano> imho all mentioned points are important for F-16
17:37:37 <mmaslano> gholms: I don't think there are all problems
17:37:49 <mmaslano> https://fedoraproject.org/wiki/Talk:Features/F16BtrfsDefaultFs
17:38:03 <gholms> Sure, I'm just throwing that out there.
17:39:13 <mjg59> mmaslano: The kernel.org wiki doesn't seem to be keen on talking to me at the moment. What's the issue with dm-crypt?
17:40:24 <mmaslano> mjg59: there were some complaints about encryption with btrfs on dm-crypt
17:41:14 <mmaslano> mjg59: josef says that bug is in dm-crypt, but he didn't send any bug report
17:41:22 <mmaslano> or reproducer
17:41:27 <mjg59> Well, I think we'd expect dm-crypt to work
17:41:38 <mmaslano> I suppose dm-crypt is working
17:41:45 <mjg59> But otherwise the only thing that seems like a functional regression is quota
17:41:51 <mmaslano> withtout reproducer, hard to say
17:42:10 <mmaslano> whatabout fsck?
17:42:23 <nirik> so, I guess I'd like to see: a) some feedback from anaconda folks. Does this switch seem reasonable given their other plans for f16, etc.... and b) we need a hard list of criteria on the feature page that if they aren't all met we go to fallback.
17:42:23 <mjg59> We've got a commitment to fsck
17:42:32 <mjg59> If it doesn't arrive then we'd punt to F17
17:42:44 <nirik> yeah, so is quota something we punt for or not?
17:43:12 <mjg59> I'm leaning towards saying no?
17:43:19 <kylem> default surely doesn't mean 'only'
17:43:21 <nirik> what should be the hard critera list, I guess is what I am asking. ;)
17:43:29 <mjg59> In that anyone running a service where you need quota should probably not be using btrfs just yet
17:43:30 <kylem> as long as it's well documented ahead of time.
17:43:43 <mjg59> I'd say hard criteria are:
17:43:46 <nirik> * robust fsck/handles power loss, etc.
17:43:46 <mmaslano> nirik: a/ I was speaking with few of anaconda guys today. They have only basic setup, no fancy features
17:43:53 <ajax> yeah, i don't think i'd block on quota
17:43:55 <notting> flipping anaconda's default is pretty easy, as long as you're treating it as any other FS
17:43:58 <mjg59> * Works on top of lvm/dm-crypt
17:44:04 <mjg59> * Has a working bootloader
17:44:05 * nirik nods.
17:44:14 <nirik> * works for live media ?
17:44:23 <mjg59> Mrm.
17:44:30 <kylem> notting, right.
17:44:32 <notting> * handles simple failure conditions (-ENOSPC, etc.)
17:44:43 <mjg59> Live media? I guess?
17:44:56 <kylem> notting, obviously that won't cut mustard if you're installing from live though.
17:45:06 <mjg59> I suppose it ought to Just Work, but in the worst case it ends up as ext4 again and you get a different fs depending on install method
17:45:14 <nirik> also, /boot or not to /boot? ;)
17:45:15 <notting> handling live media implies handling grow/shrink
17:45:17 <mjg59> Which sucks, but then so does the set of differences you have depending on install method anyway
17:45:18 <mmaslano> mclasen has some questions from destop perscpective
17:45:26 <notting> nirik: that's 'has a working bootloader'
17:45:28 <ajax> we already have /boot varying.
17:45:47 <nirik> ajax: we do?
17:45:55 <mjg59> I can't see anything especially awkward from a desktop perspective
17:46:08 <notting> nirik: encryption
17:46:10 <kylem> then again, users shouldn't be storying crap on / and /usr, so they could always have those on btrfs and /home, /var/mail, etc. on ext4 if quota blocks them.
17:46:14 <nirik> notting: more a 'if we only need /boot for encrypted installs, do we force it for everyone? or leave it off default with no encryption'?
17:46:26 <mmaslano> mclasen mentioned thsi link http://lists.fedoraproject.org/pipermail/desktop/2011-June/007306.html
17:46:38 <ajax> at least, if you were using icantbelieveitsnotbtr in past releases, we were smart enough to not try btrfs on /boot
17:46:44 <nirik> I guess it's easier to just leave it
17:46:48 <mjg59> nirik: Or let people who want encryption create an unencrypted /boot slice?
17:47:01 <mjg59> Doing that's presumably a matter of shuffling
17:47:05 <nirik> mjg59: it should be easily doable via installer... ;)
17:47:13 <ajax> mmaslano: those sound like features desktop might want to add, not issues that would impede adoption
17:47:30 <mjg59> nirik: Yeah, so the only real reason to force a separate /boot for everyone would be if otherwise it was difficult to move to encryption later
17:47:36 <mjg59> And that doesn't seem to be an issue here
17:47:38 <mmaslano> ajax: i didn't read it yet...
17:47:53 <mjg59> I suppose that if we create slices then we probably need palimpsest to be able to deal with them, rather than just partitions
17:48:00 <nirik> mjg59: well, and confusion from a support perspective, but we are used to that. ;) (did you install from live media? etc)
17:48:29 <notting> mjg59: but, the implication is that we aren't creating slices
17:48:35 <nirik> anyhow, would someone like to add the critera to the wiki page? then we could either vote now, or ask josef to comment on our critera first?
17:49:28 <mmaslano> nirik: I suppose there were all marked with *
17:49:45 <mjg59> notting: Not by default, but if we want to drop /boot (except for people who choose encryption beforehand) then they'd need to add one later if they want to transition
17:50:07 <mjg59> But I think we're bikeshedding somewhat here
17:50:11 <nirik> mjg59: I expect re-install would be easier than tooling for that.
17:50:11 <mjg59> That kind of thing's up to Anaconda
17:50:23 <mjg59> nirik: Short term, probably. Long term I'd hope we can do better.
17:50:27 <nirik> sure.
17:50:34 <notting> mjg59: and a lot of this depends on the upstream roadmap for btrfs slices, raid, etc. which is all still somewhat up in the air
17:52:24 <nirik> so, are we assuming lvm still here?
17:52:30 <nirik> (by default0
17:52:34 <mjg59> nirik: I think so
17:52:55 <mjg59> If we have something better implemented by F16 then woo, but I don't think we'd require it?
17:53:00 <notting> bleah, this seems like something that needs more design
17:53:10 <nirik> yeah.
17:53:17 <mjg59> Integration requires a lot of design
17:53:23 <mjg59> I think btrfs-by-default doesn't
17:53:25 * nirik was thinking no lvm, but not sure why.
17:53:53 <ajax> possibly because, in a just universe, btrfs would be a functional replacement for lvm
17:54:00 <mjg59> The proposal here isn't that we transition overnight to an awesome new filesystem universe
17:54:07 <nirik> ajax: +1
17:54:09 <notting> what good is btrfs by default without integration ? just testing thereof?
17:54:12 <mjg59> The proposal is that we swap out ext4 and basically everything else carries on as is
17:54:20 <mjg59> notting: Yeah, and users can work on it
17:54:28 <notting> mjg59: then that just goes back to the simple criteria above
17:54:36 <mjg59> Right
17:54:39 <notting> ajax: alas, we do not live in a just universe
17:54:49 <ajax> notting: don't i know it
17:55:03 <nirik> if thats all we are doing, ok. add critera and +1. I was thinking we were moving to a more radical change...
17:56:06 <mjg59> Hm.
17:56:14 <mjg59> The feature description does actually say remove LVM
17:56:16 <notting> i am +1 to the 5 criteria above, with the understanding that it's s/etx4/btrfs/
17:56:31 <mjg59> But I suspect that depends on more anaconda work than anything else
17:56:54 <mjg59> I'm +1 to btrfs by default, and if the engineering work to replace lvm gets done then wonderful
17:56:56 <mmaslano> I suppose btrfs can't encrypt without lvm, but I might be wrong
17:57:02 <ajax> mmaslano: correct.
17:57:04 <mmaslano> +1 for criteria
17:57:04 <mjg59> But I'm sceptical about that happening
17:57:07 <notting> can't encrypt without device-mapper
17:57:10 <nirik> right, but in the non encrypt case it doesn't need it.
17:57:12 <notting> device-mapper isn't exactly lvm
17:57:18 <notting> (yeah yeah, semantics)
17:57:22 <nirik> yeah, that too.
17:57:35 <ajax> +1 for the simple default change
17:57:53 <nirik> thats +5 with the 5 critera added and just changing ext4 for btrfs.
17:58:05 <nirik> would someone be willing to add to the page the criteria?
17:58:16 <mjg59> Sure
17:58:22 <nirik> thanks
17:58:39 <nirik> we might also make clear that if the lvm replace/dropping happens we should re-evaluate?
17:58:40 <kylem> +1
17:59:15 <mmaslano> I don't think they will be able to make it to freeze...
17:59:26 <nirik> #agreed Feature is approved. Will add some base critera to the page to be met by feature freeze. This is just a swap of ext4 to btrfs for default, not change of lvm or other parts of default.
17:59:50 <nirik> anything more on this? or shall we move on?
18:00:36 <mmaslano> for the record I was for list of criteria, not for btrfs ;-)
18:01:26 <notting> nirik: surely it's change the default status of LVM that would cause re-evaluation.  we are not, and will not, replace/drop LVM support itself
18:01:33 <nirik> #topic #599 F16Feature: ConsoleKit Removal/Automatic Multi-Seat Support - https://fedoraproject.org/wiki/Features/ckremoval
18:01:33 <nirik> .fesco 599
18:01:40 <zodbot> nirik: #599 (F16Feature: ConsoleKit Removal/Automatic Multi-Seat Support - https://fedoraproject.org/wiki/Features/ckremoval) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/599
18:02:49 <nirik> any news here?
18:03:19 <ajax> what were we hoping for?
18:03:39 <mmaslano> KDE would like to know what does it mean for them if they want to support it
18:03:47 <mmaslano> more details will be appreciated
18:04:43 <notting> there's also a question of how this affects zaphod mode
18:04:47 <notting> which, wheee
18:05:03 <ajax> can i just delete zaphod mode already please
18:05:21 * mclasen apologizes - was in another meeting and had a networkmanager malfunction
18:05:35 <ajax> but no, zaphod mode is accounted for here
18:05:44 <ajax> if you want multiple GPUs on one seat, bind multiple GPUs to one seat.
18:06:25 <ajax> i _assume_ that's what's meant, since that's the case where currently you're forced into zaphod mode if you want 3d.
18:06:25 <mclasen> lennart was travelling last week and on vacation this week, so no surprise there's no updates...
18:06:44 * nirik got a phone call. just a sec.
18:06:49 <notting> mclasen: i'm assuming (hah) that if an older desktop still relies on CK, they can still require it?
18:07:00 <mclasen> notting: thats my understanding, yes
18:08:15 <mclasen> so the feature may be a bit misnamed
18:08:20 <nirik> should we defer? also cwickert had some questions I think...
18:08:34 <mclasen> since it is not so much about removal as replacement by something better
18:08:36 <nirik> if ck is still around, then I would think it would be ok.
18:08:41 <mmaslano> probably othere desktops would like to know if it'll still be working with ck
18:09:18 <mmaslano> and if it won't be removed/changed after freeze like network manager
18:09:27 <mclasen> I'll ask lennart to answer questions on the feature page for next weeks meeting
18:09:41 <nirik> sounds reasonable.
18:09:50 <nirik> any objections?
18:09:58 <ajax> sounds good to me
18:10:08 <notting> from the plan:
18:10:10 <notting> Transition:
18:10:10 <notting> We will ensure CK and the new scheme can run side-by-side. Only the ACL management of CK will be disabled when the new scheme is enabled
18:10:10 <notting> Phase-out similar to HAL’s, leave things running side-by-side but port important things over quickly. Should be much easier than HAL, since less code uses it
18:10:18 <notting> not sure it can be clearer than that.
18:10:41 <nirik> that sounds like it's being done in a way that shouldn't cause too much pain...
18:10:46 <cwickert> notting: so what does "Only the ACL management of CK will be disabled when the new scheme is enabled" mean exactly?
18:10:48 <notting> note that the ACL management is an implementation detail between CK and udev
18:11:02 <notting> cwickert: right now udev reads CK's db to determine the active user to apply ACLs
18:11:07 <mclasen> we can spell out some details, like 'the package will still be available', how to ensure it is installed/running if you need it, etc
18:11:20 <nirik> so ck using desktops will continue to work as they have?
18:11:30 <nirik> or something will need to happen to get acls setup for them?
18:11:31 <notting> cwickert: this will move to the generic pam_... module on login that systemd provides
18:11:55 <notting> cwickert: i.e., the implementation changes, but (AFAIK) the interface for users & packagers remains the same
18:11:58 <mclasen> nirik: that is the kind of question that I'll try to get lennart to provide details about, if you put it on the talk ppage
18:11:59 <jreznik> notting: another question - what we will have to do if we want to support new system/replacement - cause of interoperability between desktops
18:12:08 <jreznik> we can try to implement it then...
18:12:46 <mclasen> jreznik: is that a question about fast-user-switching between a systemd-using and a ck-using desktop ?
18:13:37 <nirik> so, lets add questions and revisit next week?
18:13:41 <nirik> unless there's a hurry?
18:13:42 <jreznik> mclasen: yeah, that's one issue
18:13:59 <jreznik> but I'd rather to have proper implementation - side by side hurts kitties :)
18:14:37 <notting> nirik: nothing should need to change for other desktops for ACLs
18:14:47 <nirik> notting: cool.
18:15:38 <nirik> so do folks just want to vote today? or ?
18:16:28 <mmaslano> more detail with mentioned questions?
18:16:34 <mjg59> Let's wait for Lennart
18:16:39 <kylem> i don't really feel confident enough about it to vote on it right now.
18:16:53 <ajax> yeah, wait
18:16:53 <notting> so, questions would be:
18:17:01 <notting> 1) clarify that existing CK desktops remain working without changes
18:17:08 <notting> 2) describe how to port to the new support
18:17:08 <notting> ?
18:17:14 * nirik nods.
18:18:00 <jreznik> notting: ok for me :) thanks!
18:18:09 <nirik> #agreed defer to next week
18:18:16 <nirik> #topic #602 meeting topic: Live CD's and Install Media's arch inconsistent
18:18:16 <nirik> .fesco 602
18:18:17 <zodbot> nirik: #602 (meeting topic: Live CD's and Install Media's arch inconsistent) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/602
18:18:45 <notting> blarg :)
18:18:49 <nirik> Here's a fun one. ;) This might be more rel-engy, but they have bumped around trying to get this discussed/addressed.
18:19:08 <nirik> I don't suppose we could do:
18:19:23 <nirik> /x86/32bit/
18:19:28 <nirik> /x86/64bit/
18:19:49 <mjg59> I vote we ignore this ticket due to "Fedora needs to be consistent"
18:20:17 <mjg59> WHich, if accepted as a premise, would result in a lot of changes
18:20:25 <nirik> ha.
18:20:45 <nirik> I agree this is a source of confusion, but I'm not sure how to make it all that clear.
18:20:58 <mclasen> mjg59: we could change the links without accepting the premise, I assume
18:21:04 <mjg59> If there's any confusion it's that the live media is called i686
18:21:21 <jlk> historically that was because we only included the i686 kernel on that media
18:21:22 <mjg59> I think i386 is pretty well established as the generic name for 32-bit x86
18:21:24 <notting> this is essentially uname -m vs. uname -p?
18:21:34 <jlk> whereas the DVD had i586 and i686 kernels
18:21:43 <mjg59> notting: Yeah
18:21:44 <jlk> also, I think this is "blame jeremy" land
18:22:08 <notting> yeah, this dates back to when live actually was different
18:22:18 <ajax> this is so minor i wonder why we're looking at it.  pick something consistent and do it.
18:22:23 <mjg59> Also, am I missing something?
18:22:29 <mjg59> http://fedoraproject.org/get-fedora doesn't seem to mention i386 or i686 anywhere
18:22:34 <jlk> mjg59: the iso names
18:22:41 <jlk> people are bitching about the iso names and iso labels
18:22:53 <notting> it is far far far far less kely to break things to rename the live image to i386 than to try and drive i686 everywhere
18:22:54 <jlk> (that much free time)
18:22:55 <mjg59> jlk: But we don't show those to the user
18:23:15 <jlk> mjg59: sortof.  They see it when they insert the disc
18:23:18 <mjg59> So honestly I don't care but if someone wants to rename the live image to i386 I'm fine with that
18:23:24 <jlk> or when they go to burn it from the download directory
18:23:28 <nirik> notting: then peope will ask why it doesn't run on their 486? ;)
18:23:41 <jlk> IIRC the live is still "different" in that it doesn't have PAE right?
18:23:42 <notting> nirik: LA LA LA
18:23:44 <nirik> I don't actually see i386 anywhere there on the current pages.
18:23:45 <jlk> whereas the DVD still has the PAE option
18:23:48 <mjg59> jlk: They're only going to notice the discrepency if they download both
18:23:49 <nirik> it's all i686
18:23:58 <jlk> or are we finally down to single kernel on 32bit ?
18:24:00 <notting> jlk: doesn't change the supported hardware set
18:24:02 <notting> iirc
18:24:15 <mclasen> nirik: we could offer them to drop them off at the westford office for free e-trash removal ? can't be that many...
18:24:16 <notting> jlk: just have least common denominator on live
18:24:18 <jlk> mjg59: these aren't normal people bitching.
18:24:22 <nirik> I guess with the dvd it is
18:24:47 * jlk is perfectly fine with having the iso and label changed to i386 to match the DVD.
18:24:56 <jlk> just so we're clear.  But I'm not releng anymore
18:25:05 <nirik> why not s/i386/i686/ ?
18:25:27 <mjg59> We don't work on all i686
18:25:35 <notting> nirik: that implies moving paths on the ftp/web servers, changing yum's $basearch, and all sorts of other similar ways to break everything
18:25:38 <mjg59> So that's not meaningful either
18:25:55 <ajax> mjg59: which one are you thinking of?
18:26:19 <ajax> iirc we went out of our way to hit the subset of (pentium pro, geode gx/lx)
18:26:29 <nirik> notting: yeah, pain for sure.
18:26:54 <nirik> /Fedora/15/ppro-and-geode-gx-and-stuff/
18:27:01 <mjg59> ajax: cmov
18:27:08 <mjg59> So some VIAs
18:27:22 <notting> mjg59: <insert trolling about relevance of via> ?
18:27:29 <mjg59> Yeah I know right
18:27:42 <notting> proposal: refer to rel-eng with recommendation of renaming the live iso ?
18:27:45 * mclasen submits that it doesn't make any difference how the iso is named, lets move on ?
18:27:46 <mjg59> But 686 is a meaningless string in terms of telling you which hardware we work on
18:27:58 <mjg59> So there's no reason to prefer 686 over 386, so if we're going to be consistent do it the way that's less work
18:27:58 <nirik> true I suppose.
18:28:02 <nirik> notting: +1
18:28:08 <mjg59> +1
18:28:12 <mclasen> +1
18:28:30 <notting> (the alternate propsal is "dontcare wontfix", i suppose
18:28:58 <kylem> really don't care one way or another: +1
18:29:01 <nirik> #agreed will recommend to rel-eng that the live media change to be named 'i386' for the 32bit versions instead of i686.
18:29:16 <nirik> #topic #603 F16Feature: Ada developer tools - https://fedoraproject.org/wiki/Features/Ada_developer_tools
18:29:16 <nirik> .fesco 603
18:29:18 <zodbot> nirik: #603 (F16Feature: Ada developer tools - https://fedoraproject.org/wiki/Features/Ada_developer_tools) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/603
18:29:49 <landgraf> I'm here.
18:30:16 <mjg59> It's just a toolchain and bindings update?
18:30:17 <mjg59> +1
18:30:25 <notting> yeah, +1
18:30:27 <mmaslano> +1
18:30:28 <nirik> +1.
18:30:34 <kylem> +1.
18:30:36 <landgraf> mjg59: no, not only update
18:31:08 <Rombobeorn> landgraf: I take it you expect full Ada 2012 support in GCC before F16? You're not bringing in GNAT GPL right?
18:31:37 <nirik> #agreed Feature approved.
18:32:08 <landgraf> Rombobeorn, I'm not sure that we can build GNAT GPL from scratch ... so only gcc
18:32:56 <nirik> ok, anything further on this or shall we move on?
18:33:02 <nirik> landgraf: thanks for being available. :)
18:33:17 <Rombobeorn> Do move on.
18:33:41 <nirik> #topic #604 F16Feature: CloudFS - http://fedoraproject.org/wiki/Features/CloudFS
18:33:42 <nirik> .fesco 604
18:33:43 <zodbot> nirik: #604 (F16Feature: CloudFS - http://fedoraproject.org/wiki/Features/CloudFS) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/604
18:34:47 <mjg59> +1
18:35:01 <notting> i'm failing to remember - why did we defer this from f15, and what's changed?
18:35:22 <nirik> I think they simply didn't have it working yet.
18:35:27 <kylem> some packages didn't get reviewed in time, or something, i believe/
18:35:30 <rbergeron> notting: he needed to get gluster to have some additional patches, etc.
18:35:35 <rbergeron> before he could do other things.
18:35:43 <rbergeron> And Time was just not there to do it well and right.
18:35:49 <nirik> +1 here
18:35:54 <notting> ok then. +1
18:36:25 <ajax> looks nicely documented from a quick look, +1
18:36:38 <kylem> sounds good, +1.
18:37:04 <nirik> #agreed Feature approved.
18:37:09 <nirik> #topic #605 F16Feature: Xen Pvops Dom0 - http://fedoraproject.org/wiki/Features/XenPvopsDom0
18:37:09 <nirik> .fesco 605
18:37:10 <zodbot> nirik: #605 (F16Feature: Xen Pvops Dom0 - http://fedoraproject.org/wiki/Features/XenPvopsDom0) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/605
18:37:14 <nirik> it's back! ;)
18:37:55 <jsmith> It's like deja-vu all over again
18:38:15 <kylem> fml.
18:38:18 <nirik> So, this is back to a kernel-xen package for dom0?
18:38:25 <nirik> subpackage rather
18:38:30 <nirik> or does the default work for this?
18:38:42 <notting> the point of pvops was that the default would work, right?
18:38:46 <mclasen> wasn't full xen support something that will appear in the 3.0 kernel ?
18:38:59 <notting> mclasen: still no hypervisor
18:39:05 <notting> so you'd have to still install that from elsewhere
18:39:11 <mclasen> oh, ok
18:39:15 <nirik> also, virt tools would be aware?
18:39:21 <kylem> i thought i already turned all that crap on tho.
18:39:24 <mjg59> Yeah, it's just turning on the config options in 3.0
18:39:40 <nirik> ah, it has a seperate initramfs
18:39:48 <ajax> libvirt has a pretty robust xen backend, yeah
18:40:30 <nirik> yeah, it notes that it should work...
18:41:09 <notting> i'm firmly in the "don'tcare" category here, but i'm fine with allowing people to tilt at their own windmills. would like a way to describe this as "we support this, but we recommend you do XYZ instead"?
18:41:51 <nirik> I'm not sure I like the seperate initramfs, but that also probibly increases the barrier to anyone using it...
18:42:07 <ajax> nirik: that's kind of always been true though
18:42:30 <nirik> yeah. seperate kernel has a similar effect.
18:42:51 <nirik> anyhow, +1 here...
18:43:18 <mmaslano> +1
18:43:22 <ajax> +1
18:43:35 <kylem> +1.
18:43:49 <mclasen> +1 too
18:44:16 <notting> +1
18:44:17 <nirik> #agreed Feature approved.
18:44:30 <nirik> #topic Open Floor
18:44:37 <nirik> ok, anything for open floor from anyone?
18:44:53 <nirik> I'll note that elections are coming to a close... so we should have a new set of fesco folks next meeting...
18:45:10 <nirik> If I'm not re-elected, it's been nice working with you all. ;)
18:45:18 <kylem> I'd like to take this opportunity to say thanks to you, nirik, for being the chair of the meetings for this term (regardless of the outcome I think you mentioned you'd be stepping aside.)
18:45:40 <Southern_Gentlem> kylem,  he is running
18:45:42 <nirik> yeah, I would kinda like to pass on the chair next session in any case... or move to a rotating one or something...
18:46:35 <ajax> indeed, really not fair to force the job onto one person all the time, it's a lot of work
18:46:40 <nirik> anyhow... anything for open floor? or should we call it a meeting?
18:46:44 <ajax> thanks for doing it though!
18:46:48 <nirik> yeah, it's not hard, but it takes time...
18:46:49 <ajax> nothing from me
18:46:55 <mmaslano> nirik: thank you
18:47:09 <mjg59> Well, thanks to everyone who's put in time
18:47:10 <jsmith> Thanks from the FPL as well!
18:47:28 <notting> do we want to have both new and old members at next meeting for transition?
18:47:56 <nirik> we could. That might be nice if folks can make it.
18:48:44 <nirik> ok, thanks for coming everyone!
18:48:48 <nirik> #endmeeting