=================================== #fedora-meeting: FESCO (2011-06-08) =================================== Meeting started by nirik at 17:30:03 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2011-06-08/fesco.2011-06-08-17.30.log.html Meeting summary --------------- * init process (nirik, 17:30:03) * #563 suggested policy: all daemons must set RELRO and PIE flags (nirik, 17:32:50) * ACTION: defer until next week. (nirik, 17:35:08) * #594 F16Feature: F16 BTRFS default file system - http://fedoraproject.org/wiki/Features/F16BtrfsDefaultFs (nirik, 17:35:12) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=689509 <- btrfs tracker bug (gholms, 17:37:12) * LINK: https://fedoraproject.org/wiki/Talk:Features/F16BtrfsDefaultFs (mmaslano, 17:37:49) * 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. (nirik, 17:59:26) * #599 F16Feature: ConsoleKit Removal/Automatic Multi-Seat Support - https://fedoraproject.org/wiki/Features/ckremoval (nirik, 18:01:33) * AGREED: defer to next week (nirik, 18:18:09) * #602 meeting topic: Live CD's and Install Media's arch inconsistent (nirik, 18:18:16) * LINK: http://fedoraproject.org/get-fedora doesn't seem to mention i386 or i686 anywhere (mjg59, 18:22:29) * AGREED: will recommend to rel-eng that the live media change to be named 'i386' for the 32bit versions instead of i686. (nirik, 18:29:01) * #603 F16Feature: Ada developer tools - https://fedoraproject.org/wiki/Features/Ada_developer_tools (nirik, 18:29:16) * AGREED: Feature approved. (nirik, 18:31:37) * #604 F16Feature: CloudFS - http://fedoraproject.org/wiki/Features/CloudFS (nirik, 18:33:41) * AGREED: Feature approved. (nirik, 18:37:04) * #605 F16Feature: Xen Pvops Dom0 - http://fedoraproject.org/wiki/Features/XenPvopsDom0 (nirik, 18:37:09) * AGREED: Feature approved. (nirik, 18:44:17) * Open Floor (nirik, 18:44:30) Meeting ended at 18:48:48 UTC. Action Items ------------ * defer until next week. Action Items, by person ----------------------- * **UNASSIGNED** * defer until next week. People Present (lines said) --------------------------- * nirik (118) * mjg59 (63) * notting (54) * mmaslano (29) * ajax (29) * kylem (21) * mclasen (16) * jlk (14) * zodbot (11) * jreznik (5) * landgraf (3) * rbergeron (3) * gholms (2) * Rombobeorn (2) * cwickert (2) * jsmith (2) * Southern_Gentlem (1) * SMParrish (0) -- 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
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
