17:00:55 #startmeeting FESCO (2011-07-11) 17:00:55 Meeting started Mon Jul 11 17:00:55 2011 UTC. The chair is ajax. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:55 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:56 #meetingname fesco 17:00:56 The meeting name has been set to 'fesco' 17:00:57 #chair ajax notting nirik cwickert mjg59 mmaslano t8m pjones sgallagh 17:00:57 Current chairs: ajax cwickert mjg59 mmaslano nirik notting pjones sgallagh t8m 17:01:10 * sgallagh is here 17:01:15 * t8m is here 17:01:32 cwickert and nirik have said they can't make it 17:01:42 * notting is here 17:02:24 mmaslano is on holidays 17:02:25 * rbergeron peeks in 17:02:26 Hi 17:02:37 * pjones is here 17:02:54 that's everyone accounted for then 17:03:23 apologies for the lateness of the agenda. holy cats do we have a lot of tickets to look at today 17:03:34 * sgallagh grabs a snickers 17:03:53 * gholms hands out coffee 17:03:53 #topic #563 suggested policy: all daemons must set RELRO and PIE flags 17:03:53 .fesco 563 17:03:55 ajax: #563 (suggested policy: all daemons must set RELRO and PIE flags) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/563 17:04:38 kevin's out so there might not be a lot to cover here 17:04:53 redhat-rpm-config in rawhide has -Wl,-z,relro in LDFLAGS now 17:05:00 there was a comment from sgrubb in the bug on what to apply pie to 17:05:09 So "we want anything that parses untrusted content" is, what, everything? 17:05:14 notting: yes, but it basically says "everything, but these things too" 17:05:27 which, I mean, it's unsurprising. 17:05:34 mjg59: indeed 17:05:38 it's basically the same things we came up with 2 weeks ago 17:06:10 pie increases exec time, right? 17:06:12 yep 17:06:23 Does that scale with the number of libraries, size of executable or what? 17:06:35 number of dynamic symbols in the executable 17:07:10 And how much overhead is it? 17:07:13 Is this something we could handwave and say "Moore's Law will recoup this shortly"? 17:07:19 compared to not prelinking, that is. 17:07:31 compared to normal prelinked binaries it's a bit worse than that since, well, not prelinked. 17:07:52 Of course, the applications which would gain the most are the ones that are going to be hit the hardest 17:08:03 mjg59: but also the ones that you execute the least frequently. 17:08:04 This clearly ought to be done for firefox and libreoffice 17:08:09 pjones: Yeah 17:08:15 * pjones doesn't buy the "firefox has to start fast" argument, since he runs it once a month. 17:08:21 Maybe we should just turn it on for everything 17:08:25 And see who complains 17:08:25 * notting wonders how pjones avoids the leaks he sees 17:08:32 but, offtopic 17:08:46 mjg59: the prelink authors! 17:08:52 notting: well, assume a spherical bloated cow 17:09:01 firefox's launch time is not dominated by relocation processing 17:09:28 notting: ... aren't they also the PIE/RELRO authors? 17:09:41 pjones: ... yes, i suppose. 17:09:41 Ok, how about just everything that's in base, desktop, setuid or run as a daemon 17:09:48 Or... I don't know 17:09:54 mjg59: it's really a hard call 17:09:54 There doesn't seem to be any obvious place to draw a line 17:10:01 I think we should aim for some reasonable compromise - like network facing daemons (startup time does not matter much for daemons), suid binaries and the rest leave up to package maintainers? 17:10:06 i mean, bash(1) execs bajillions of times. 17:10:27 I guess bash has a reasonable track record 17:10:30 So could probably opt out 17:10:34 pjones: they've already stated they don't want it everywhere 17:10:47 mjg59: it's also relatively small, so may not see much cost? 17:11:04 are we tying full relro to pie? 17:11:05 Proposal: hand this off to the FPC to create a guideline 17:11:08 notting: Yeah, but haven't actually said where they *do* want it 17:11:19 sgallagh: No, I think this is a sufficiently technical decision that we want to handle it 17:11:47 yeah, this is a place where we need to tell them what's up 17:12:04 notting: functionally they're orthogonal. depends which attack you want to prevent 17:12:28 Ok. How about we turn it on everywhere but permit applications to opt out if they're frequently started, have an excellent security record and aren't suid or network facing? 17:12:35 ajax: sure, just wanted to be clear whether we want different guidelines for them 17:12:45 or if we notice they're not working well any more? 17:12:53 where's that line? 17:12:58 mjg59, we do not have a way how to turn it on everywhere just now 17:12:58 notting: meh. very fine hair to split. 17:13:06 mjg59: it drops a register on 32-bit. that could be severe performance 17:13:18 yowch. 17:13:20 mjg59, apart from creating a guideline that requests it but you know ... 17:13:32 notting: PIE does, yes. 17:13:33 mjg59: How exactly do they opt out? 17:13:40 sgallagh: redefine CFLAGS 17:13:53 which really means we should make CFLAGS conditional on some rpm variable 17:13:54 ah, ok. I was curious if there was a specific negation flag 17:14:06 (well, optflags) 17:14:12 probably we should have something like %define _hardened_build 1 that turns _on_ znow and pie 17:14:16 yeah 17:14:30 ajax: +1 to that 17:14:32 and _softened_build 1 to turn it off! :) 17:14:35 (hhjk) 17:14:45 esp. since you need to do both cflags and ldflags, right? 17:14:48 ajax: +1 17:14:50 notting: correct 17:14:53 ajax: +1 to that 17:15:13 ajax: With that as the default, and people able to define it to 0? 17:15:24 mjg59: right. similar to the debuginfo generation flag 17:15:24 mjg59: i was thinking the other way around. 17:15:27 opt-in. 17:15:27 +1 although we'll really need to split cflags and ldflags 17:15:33 mjg59: -1 to that, for 32-bit perf. reasons 17:15:43 t8m: why? 17:15:52 notting: I'm not keen on compromising 64-bit because 32-bit sucks 17:16:09 Perhaps a separate default per-arch? 17:16:15 pjones, -Wl cannot be used in CFLAGS - breaks things like precompiled headers 17:16:23 pjones: gcc gets confused in some scenarios if you pass -Wl in CFLAGS 17:16:28 And making it arch-specific means everyone has to fiddle with their spec 17:16:33 which is _dumb_, but gcc. 17:16:40 t8m: sure, they both need to be conditionalized -- I didn't think anybody was saying we'd put everything in both. that makes no sense at all. 17:16:55 mjg59: no it doesn't. 17:17:21 pjones: The advantage of doing it by default is that we don't have to audit everything to figure out whether it should be switched on or not 17:17:23 mjg59: rpm already has per-arch defines, you can use that to set a default in the macros in our rpmrc, and thus default flags from our rpmrc 17:17:26 we'd also want to write a verification test, to check to make sure it matches (app internally botches cflags/ldflags during build) 17:17:35 pjones: But if it's off by default on one architecture then we still need to audit everything 17:17:42 yes. 17:17:48 notting: ... which you can't really do without toolchain work. 17:17:59 So then there's no real advantage in doing it by default 17:18:21 We should just accept that 32-bit x86 is niche now and stop optimising for it 17:18:33 notting: for some reason I thought we already had generically said not to change CFLAGS/LDFLAGS 17:18:56 pjones: at the spec level yes. makefiles don't get audited. 17:18:58 pjones, I remember the same :) 17:19:14 ajax: sure 17:19:24 pjones: we do. doesn't mean app configure scripts/makefiles don't screw it up 17:19:29 right. 17:19:34 Ok, so where are we 17:19:35 ajax: checking PIE should be easy enough 17:19:44 yeah, checking the binary results should be plausible 17:20:05 #proposal: Enable pie by default everywhere, conditionalised in a way that lets packagers opt out 17:20:45 -1. 17:20:56 * notting is -1 as well 17:21:01 -1 17:21:03 at least for now on the grounds that we don't have an answer for -fPIE implying -rdynamic 17:21:21 i could really care less about i386 performance 17:21:50 but it affects the x86_64 performance as well although less 17:21:51 so, that takes us back to defining criteria for it? 17:21:53 ajax: Well that just seems like a bug we should fix 17:22:15 t8m: if I'm reading right: startup performance on x86_64, runtime on i386. 17:22:16 What if we have -rdynamic in a package we want to make pie? 17:22:32 t8m: honestly i generally disbelieve anyone who thinks the frame pointer is a material performance problem. 17:22:36 pjones, not only startup - adds indirect access to variables 17:22:54 Performance critical applications can opt out 17:23:12 mjg59: i really, really think this should be opt-in. 17:23:18 ajax, +1 17:23:41 ajax: I just have no faith whatsoever in us getting sensible coverage 17:23:59 we're rambling. 17:24:11 indeed. 17:24:16 * gholms rings the 20-minute bell 17:24:23 if this will be as easy as %define _hardened_build 1 and it is advertised appropriately to developers, it will get coverage 17:24:25 how much do we feel like continuing to talk about this now, and how much would we rather take it to the list for broader review? 17:24:36 what's clear is that we have no proposal that everyone likes, or really even approaches consensus. 17:24:44 I'd be alright with moving on to other topics for now 17:24:58 i'd prefer to table and come back next week 17:25:39 I don't think we can reasonably make progress until we find out why we have the -rdynamic/pie thing 17:26:05 right, deferring sounds like it's been consensed. (that can't be proper english.) 17:26:25 #agreed revisit PIE criteria next week 17:26:38 #topic #614 Proposed list of packages to drop due to FTBFS prior to F16 17:26:39 branching 17:26:39 .fesco 614 17:26:40 ajax: #614 (Proposed list of packages to drop due to FTBFS prior to F16 branching) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/614 17:27:09 ajax: FYI: it looks like your topics are getting line-wrapped 17:27:18 yeah, fixing locally 17:27:19 I'm vaguely +1 with this. If we can find more automake packages to add to the list, that'd be better. 17:27:54 didn't we discuss this once? where did we leave off? 17:28:01 I thought we previously agreed that to this. 17:28:05 +1, though we should have another round of it on list to make sure we're not catching anyone unawares 17:28:07 I thought we did as well, actually. 17:28:25 We were going to have mdomsch look into a tool to auto-detect this in the future, IIRC 17:28:25 sgallagh, +1 17:28:49 he's switching jobs this week. I bet that's a busy time. 17:29:41 the 6-27 notes make it sound like we agreed on something other than this list; instead, agreed on doing this as a process regularly 17:30:06 right, that's what I meant about this being a result of the policy we agreed on. 17:30:23 sounds like we're done then 17:31:00 #agreed package removal list as given is implicitly agreed to, based on last fesco's policy decision 17:31:04 http://fedoraproject.org/wiki/Deprecate_FTBFS_packages 17:31:07 sound right to everyone? 17:31:08 (for posterity's sake) 17:31:26 +1 17:31:48 +1 17:31:54 well if not, speak up quick-like, 'cause i'm barreling on ahead 17:31:59 #topic #615 Strategy for services that do not have systemd native unit files 17:32:02 .fesco 615 17:32:03 ajax: #615 (Strategy for services that do not have systemd native unit files) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/615 17:32:05 +1 (late) 17:32:19 That was for FTBFS 17:33:11 this is just a check-in, i guess 17:33:17 Viking-Ice, abadger1999: any updates here? 17:34:17 that sounds like no. we can revisit during open floor if there's anything more here. 17:34:27 last bit of old business: 17:34:27 #topic #531 Orphaned package ownership claiming clarification 17:34:28 .fesco 531 17:34:30 ajax: #531 (Orphaned package ownership claiming clarification) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/531 17:34:56 Again, I thought we addressed this last time. 17:35:22 AGREED: Policy will change to ""If a package is in orphan state in pkgdb, feel free to take it and revivie it, no re-review needed. If it's depreciated, you must re-review and get admins to unblock it" 17:35:29 did that happen? 17:35:32 i updated the docs, yes. 17:35:39 excellent. 17:35:47 * ajax closes the ticket so this goes away 17:36:09 ajax: Probably should have Viking-Ice send an update to the list or ticket -- he told me about progess the other day. 17:36:21 notting, if you could link to the doc update in the ticket, that'd be super. 17:36:24 well we are doing a ok on core and base 17:36:39 I believe he opened a FES ticket as well not sure what state FES is in currently. 17:36:53 yeah I think we need proven packagers to step in here 17:37:07 at this rate we dont include half of the submitted files 17:37:29 https://fedoraproject.org/wiki/User:Johannbg/Features/SysVtoSystemd 17:37:41 Viking-Ice: i'm confused - we're doing ok, but we need provenpackagers to step in? 17:37:58 yup we are doing ok on base and core the rest not so good 17:38:03 #topic systemd conversion status (round two) 17:38:31 sendmail iptables will be taken care of this week 17:38:56 audit in a bit more distant future 17:39:20 I finally received movement on multipathd ( today ) 17:39:43 so basically the only potential blocker is iscsid 17:40:04 Viking-Ice: What's the issue with iscsid (in brief)? 17:40:15 lack of man power mostly 17:40:31 Hans does not have time to look at it and the actual owner has not responded on the report 17:40:32 So nfs is all sorted? 17:40:39 hehe 17:40:43 Good to know 17:41:09 well I doubt that nfs will be a blocker if it is it's an human one 17:41:14 not a technical one 17:41:37 overall we are adopting to slowly 17:42:27 well, it's still four weeks until alpha change deadline 17:42:27 I've only been nagging base - x base + core and maintainers of few other services that are shipped on the live cd 17:42:44 er. three. four until alpha release. 17:42:49 ajax; we need this in before that time 17:43:00 preferable a week in so we dont disrupt the normal QA process 17:43:04 that's an assertion alright; why do you assert it? 17:43:45 ajax: I think that was OUR assertion when we decided to implement the Alpha deadline 17:44:23 "This option has already been partially adopted as we're planning to block alpha release for unconverted services on the livecd" 17:45:02 but i don't immediately see anything extending that to larger package sets 17:45:26 I'm not to worried that we wont make it before that time ( there should exist native systemd service files for all those services ) 17:45:36 we just need it package and shipped 17:45:52 uhum excluding iscsi and multipathd 17:46:16 however we need more service package 17:46:29 and on and on there should now exist around 200 17:46:47 given that I probably converted like 30 last week 17:47:32 there exist far greater number than those listed on my wiki page 17:47:43 that's just me walking through @groups 17:48:05 well, sounds like we're not stalled at least. 17:48:19 we are in the sense they are not being packaged 17:48:29 or being package @ to slow rate 17:48:44 fine 17:49:03 #action ajax to send email to devel@ reminding people of blocker-ness of not converting systemd services 17:49:13 anything else here? 17:49:30 might want to offer proven packager assistant in that mail ? 17:50:23 sure. 17:50:49 so, new business. 17:50:51 #topic #608 F16Feature: Trusted Boot - http://fedoraproject.org/wiki/Features/Trusted_Boot 17:50:55 .fesco 608 17:50:58 ajax: #608 (F16Feature: Trusted Boot - http://fedoraproject.org/wiki/Features/Trusted_Boot) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/608 17:50:58 oh no, not again. 17:51:38 Did we have anything new here? 17:51:43 not really? 17:51:53 since the last discussion the page has been edited, so: https://fedoraproject.org/w/index.php?title=Features%2FTrusted_Boot&action=historysubmit&diff=243593&oldid=241732 17:52:25 we had a mailing list thread that could largely be categorized as unhelpful. 17:52:26 Ok, pretty sure we have acecss to some of those machines 17:53:05 So to the extent that the packages are in fedora, and you could feed a kickstart file to get one installed by default, what are we missing? Just the grubby integration? 17:53:34 think so. 17:53:37 As the grubby maintainer, I haven't seen, say, patches from the feature owner or anything along that lines. 17:53:44 Ok 17:53:47 And, well, it's not very high on my priority list to look into, honestly. 17:53:51 SO I'm +1 to this feature assuming grubby happens 17:54:03 With it being dropped from the release notes if grubby doesn't happen 17:54:40 i'm disinclined to vote at this point, honestly. 17:54:46 likewise. 17:54:56 ajax, me too 17:55:06 though maybe we should tell the feature owner that the ball's in their court on whether or not it's technically viable as a feature. 17:55:08 have they officially re-proposed it? 17:55:22 pjones: +1 to that, drop it from agenda unless it's re-proposed 17:55:26 Didn't we discuss declinging it as a Feature? 17:55:46 sgallagh: we did, with a pile of conditionals 17:55:57 Most of which seem to have been satisfied 17:56:51 so, proposal: defer further discussion until grubby integration happens 17:57:04 (i'm +1) 17:57:04 ajax, +1 17:57:08 ajax: +1 17:57:18 ajax: +1 17:57:18 ajax: and tell mr Gang that he may want to look into making sure that happens. 17:57:30 ajax: (and with that stipulation I'm also +1) 17:58:04 #agreed feature discussion is deferred until grubby integration happens 17:58:08 or... well, whichever name is his surname. 17:58:15 #action ajax to email feature owner to remind 17:58:57 #618 F16Feature: pacemaker-cloud - https://fedoraproject.org/wiki/Features/pacemaker-cloud 17:59:01 .fesco 618 17:59:04 ajax: #618 (F16Feature: pacemaker-cloud - https://fedoraproject.org/wiki/Features/pacemaker-cloud) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/618 17:59:45 +1 18:00:01 ajax: #topic? 18:00:07 gah. 18:00:14 #topic #618 F16Feature: pacemaker-cloud - https://fedoraproject.org/wiki/Features/pacemaker-cloud 18:00:41 +1 18:00:49 +1 18:00:49 +1 18:00:54 seems like this is "approve our release notes" land, but sure, +1 18:01:06 +1 18:01:16 #agreed pacemaker-cloud feature is approved 18:01:37 #topic #619 F16 Feature: Matahari -- https://fedoraproject.org/wiki/Features/Matahari 18:01:41 .fesco 619 18:01:43 ajax: #619 (F16 Feature: Matahari -- https://fedoraproject.org/wiki/Features/Matahari) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/619 18:01:46 +1 18:01:57 seems like this is "approve our release notes" land, but sure, +1 18:02:15 pjones, heh 18:02:15 +1 18:02:28 I'd like to see the Summary expanded on. It's rather ambiguous what the API is supposed to do 18:02:39 the api is supposed to interface. 18:02:56 pjones: Thank you for that complete explanation :) 18:03:01 sgallagh: honestly I think they cover that down in the detailed description. 18:03:12 * notting is +1 to the feature 18:03:14 the Release Notes section too. 18:03:14 Eh, probably true. 18:03:15 +1 18:03:18 +1 18:03:25 #agreed matahari feature is approved 18:03:46 #topic #620 F16Feature: Virtual Machine Lock Manager - https://fedoraproject.org/wiki/Features/VirtLockManager 18:03:49 .fesco 620 18:03:50 ajax: #620 (F16Feature: Virtual Machine Lock Manager - https://fedoraproject.org/wiki/Features/VirtLockManager) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/620 18:03:53 +1 18:04:05 seems like this is "approve our release notes" land, and honestly I'm not sure why we'd bother putting it there. 18:04:26 seems a lot like an implementation detail. 18:04:32 pjones, +1 18:04:35 pjones: I agree, the lack of this seems more like a high-profile bug than a Feature 18:04:40 Feature: -1 18:04:42 this does not look like a feature 18:04:44 to be fair, the implementation is hard 18:04:49 rwmjones: sure. 18:04:56 rwmjones, no dispute on that 18:05:03 If this is being presented to us as a feature then at this point I think we treat it as a feature 18:05:12 rwmjones: I don't doubt it, but I'm not sure fixing it is a Feature of Fedora, as opposed to proper maintenance. 18:05:14 Our unhappiness with the state of the feature process has already been noted 18:05:29 I don't think we need to have this discussion again, since it'll jsut reiterate that 18:05:35 voting -1 means the work has to come out for F16. 18:05:38 so. 18:05:46 do we think that's a thing we want to do? 18:05:49 no 18:05:51 ajax: Doesn't it just mean the release note vanishes? 18:05:53 sgallagh: as the maintainer, i consider it a feature, not a bugfix 18:05:59 In that case, I revert to +0 18:06:02 ajax: afaik, it just means it falls out of the feature list 18:06:10 I think +1 on the work getting done and -1 on us advertising it in the way that being a feature usually implies. 18:06:23 I'm +1 because I think this arguably falls inside the feature process, and please can we fix the feature process 18:06:25 also my understanding is the same as notting's. 18:06:32 And that is all I'm going to say about the feature process today 18:06:33 chapter and verse? 18:06:53 (+1 to the feature regardless) 18:07:51 Well, I'd like to see it in Fedora. I just don't feel like it's a full Feature. But if voting -1 means we'd have to pull it, I can't condone that. 18:07:56 So +1 18:08:08 same as sgallagh +1 18:08:29 sgallagh: even if you vote -1, the code won't be pulled 18:08:30 ajax: https://fedoraproject.org/wiki/Features/Policy/Acceptance 18:08:48 sgallagh: because that would entail removing libvirt from the distro, which just isn't going to happen 18:09:17 notting: On point 3 of "Definition", I think I was then correct with my original -1 18:09:24 danpb: yeah, and I don't think that's a serious concern honestly so much as just gripery about the feature process. 18:09:24 hmm given that 18:09:27 I am also -1 18:09:31 rbergeron: Around? 18:09:35 -1 and go full speed ahead ;) 18:09:47 man did i not want to go down this detour today. 18:09:52 * ajax sits back for a bit 18:09:54 so if this doesn't count as a valid feature, is there a definiiton of what does, so I don't waste my time in the future 18:10:12 danpb: https://fedoraproject.org/wiki/Features/Policy/Definitions 18:10:26 mjg59: yes, I suck, but any fixes to the feature process would not go into effect until F17. 18:10:39 FEATURE FIXING IN PROGRESS WHEN I CAN BREATHE, I swear to god. 18:10:42 rbergeron: Actually, I was just asking what your thoughts on this fitting in were 18:10:47 Oh. 18:10:48 Well. 18:10:49 rbergeron: I know it's being worked on :) 18:10:51 * rbergeron asserts herself 18:10:56 danpb: Point 5 is kind of ambiguous, unfortunately 18:10:59 but feel free to let off some steam. 18:11:40 Honestly: I think that QEMU/KVM have importance to a lot of folks, and that showing that we're doing stuff in that space isn't a *bad thing*. 18:11:49 I don't know if there are future things down the road that build upon this. 18:12:36 danpb: In your estimation, is this fix of sufficient importance that it needs to be mentioned prominently in the Release Notes and the release highlights? 18:13:12 If libvirt is dependent on it, I think a lot of folks are dependent on libvirt, and therefore it should probably be working. 18:13:36 rbergeron: We're not disagreeing that it should go in. We're disagreeing about whether it's important enough to be called out as a Feature 18:14:07 rbergeron: I don't disagree, but we do have... 7 or 8 features about that subject. 18:14:27 there's no shortage of flag waving going on 18:14:48 well for people managing virt deployments I think it is pretty relevant, because for the first time they have a distributed lock manager for protecting disk images across hosts 18:14:50 If people are dependent on libvirt, and libvirt is dependent upon this, and this is going to change libvirt behavior, then I'd say yes, those changes need to be advertised. Is this something that needs to have Special Marketing Feature Love? I don't know that i'd say that. 18:15:13 i would prefer that we assume good faith on the part of current feature proposals, in that we trust their proponents to be proposing the feature because they think it's important. 18:15:22 Does it harm the project if we put this in the release notes? 18:15:28 No. 18:15:35 Because, if not, let's just do it and help rbergeron fix the process for F17 18:15:42 It makes the release notes even less interesting to read. 18:15:47 Ok, I'm swayed. +1 to the VirtLock feature 18:16:00 * notting is +1 re: danpb's comment 18:16:05 but what the hell, sure, +1, if we've decided that's not important. 18:16:07 If you think release notes are supposed to be interesting then I have some company financial reports for your bedtime reading 18:16:14 and danpb does have a reasonably good point 18:16:29 danpb: Sorry for all the drama :) 18:16:37 mjg59: do not threaten me with prospectus, for I have read many ;) 18:16:41 mjg59: you're +1 then? 18:17:19 Pretty sure I've said that twice 18:17:28 ok +1 from me then too - changing the decision for the second time 18:17:40 just being diligent 18:17:51 #agreed virtual machine lock manager feature is approved 18:18:00 #topic #621 F16 Feature: GNOME 3.2 - https://fedoraproject.org/wiki/Features/Gnome3.2 18:18:04 .fesco 621 18:18:06 ajax: #621 (F16 Feature: GNOME 3.2 - https://fedoraproject.org/wiki/Features/Gnome3.2) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/621 18:18:11 +1 18:18:20 yeah, +1 18:18:24 OK +1 18:18:33 +1 18:18:42 +1 18:18:50 #agreed gnome 3.2 feature is approved 18:18:56 #topic #622 F16Feature: KDE Plasma Workspaces 4.7 - https://fedoraproject.org/wiki/Features/KDE47 18:18:59 .fesco 622 18:19:00 ajax: #622 (F16Feature: KDE Plasma Workspaces 4.7 - https://fedoraproject.org/wiki/Features/KDE47) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/622 18:19:02 +1 18:19:04 +1 18:19:14 +1 18:19:19 +1 18:19:27 +1 18:19:38 * notting moves to shuffle the next feature to the end of today's discussion list, if we want to finish? 18:19:44 #agreed KDE 4.7 feature is approved 18:19:46 notting: +1 18:19:50 notting: wfm. 18:19:52 notting: I concur 18:19:56 +1 18:20:04 #topic #624 F16Feature: Virt Networking Enhancements - https://fedoraproject.org/wiki/Features/VirtNetworkingEnhancements 18:20:08 .fesco 624 18:20:09 ajax: #624 (F16Feature: Virt Networking Enhancements - https://fedoraproject.org/wiki/Features/VirtNetworkingEnhancements) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/624 18:20:28 that's... remarkably good docs. 18:20:35 at least wordy 18:20:42 heh, fair 18:21:00 +1 to this 18:21:03 +1 18:21:10 It's a substantial improvement to the virtual network setup 18:21:13 I do like that "how to test" section 18:21:14 +1 18:21:15 +1 18:21:16 +1. 'user experience' could have a minor note as to whether this affects virt-manager at all 18:21:47 #agreed virt networking enhancements feature is approved 18:22:04 #topic #625 F16Feature: USB Network Redirection - https://fedoraproject.org/wiki/Features/UsbNetworkRedirection 18:22:08 .fesco 625 18:22:10 ajax: #625 (F16Feature: USB Network Redirection - https://fedoraproject.org/wiki/Features/UsbNetworkRedirection) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/625 18:22:18 this looks pretty neat 18:22:49 i've even seen it work. it's pretty slick. 18:22:52 +1 18:22:52 +1 18:22:55 +1 18:23:07 needs a "Release Notes" section or else there are not practical implications of the +1 I'm giving it. 18:23:17 +1 but obviously release notes 18:23:17 indeed 18:23:30 That's noted both in the ticket, as well as with the submitter. 18:23:33 I'm really wary of the security implications of this 18:23:45 Remote access over the network to physical hardware? 18:24:05 sgallagh: surely this is 'if the admin sets it up insecurely, well...' ? 18:24:07 sure, but it's explicit. 18:24:21 If you don't want that, don't do it. 18:24:23 sgallagh: We already have that for various cases 18:25:01 Well, this better not be the default setup of libvirt 18:25:13 there's no reason to think it would be... 18:25:30 Other things that shouldn't be the default setup of libvirt include... 18:25:33 if by "the default setup" you mean "it automatically finds all your USB devices and forwards them to whatever guest you're viewing", no, it doesn't do that 18:25:55 it's something you have to choose to give to the guest 18:26:08 Alright then. +1 18:26:22 #agreed USB network redirection feature is approved (with release notes, please) 18:26:37 #topic #626 F16Feature: firewalld as default Fedora firewall solution - https://fedoraproject.org/wiki/Features/firewalld-default 18:26:41 .fesco 626 18:26:42 ajax: #626 (F16Feature: firewalld as default Fedora firewall solution - https://fedoraproject.org/wiki/Features/firewalld-default) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/626 18:26:55 Seems to be being handled by the right people with appropriate communication, so +1 18:27:03 firewall-cmd(1). sigh. 18:27:09 And really, there's no way it could be any worse than system-config-firewall 18:27:12 why not just firewall(1). anyway. 18:27:18 I'm slightly vary of the supposed rewrite for F157 18:27:21 F17 that is 18:27:34 "Services which are adding firewall rules directly with iptables commands need to be changed. These are: libvirtd " 18:27:36 ajax: don't want to give people openbsd 2 flashbacks? but yes, terrible naming. anyway, +1 18:27:38 * rbergeron notes that anything needing more solid release notes (and some of that stuff may be because they're still in the middle of developing said feature) has been notified and harassed, and knows that their feature can get dropped. 18:27:39 danpb: still around ? 18:27:43 or firewallctl? :D 18:27:44 notting: yep 18:27:52 danpb: are you in discussions with twoerner? 18:28:03 notting: nothing recent, 18:28:17 i can still change names :-) 18:28:21 last discussion about this was when firewalld was first announced on f-d-l several months back 18:28:36 so it'd be best if you guys coordinated this. 18:28:54 there were a number of missing capabilities in the API at that time which would prevent its use by libvirt, but haven't checked if this has changed at all recently 18:29:18 danpb: there are changes, but not pushed, yet 18:29:27 it would be a good step forward from the current firewall setup if we can use it though 18:29:39 we shouldn't push something as default if at least the basic UI is not stable enough 18:30:13 t8m: ? 18:30:32 like renaming commands/options whatever 18:31:26 why not? we're supposed to be aggressive at adoption, and adoption is generally what drives stability, not the other way around. 18:31:53 i'm +1, at least the right people are aware of each other, and we do have a contingency plan 18:31:59 yeah, likewise. 18:32:00 +1 18:32:16 (also it's generally a step in the right direction) 18:32:54 #endmeeting 18:33:02 Whoops, wrong channel. 18:33:03 Sorry 18:33:08 good thing the bot doesn't listen to you. 18:33:17 +1 myself, which i think makes four (mjg59 pjones notting me). 18:33:18 Yeah, I'm really sorry about that. :( 18:33:29 +1 18:33:35 gholms: no worries 18:33:46 #agreed firewalld feature is approved 18:33:47 I am +0 18:33:59 #topic #627 F16 Feature: network zones -- https://fedoraproject.org/wiki/Features/network-zones 18:34:03 .fesco 627 18:34:04 ajax: #627 (F16 Feature: network zones -- https://fedoraproject.org/wiki/Features/network-zones) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/627 18:34:33 this, i like. 18:34:34 +1 18:34:40 I see remarkably little discussion about NetworkManager or UI concerns in this feature, which worries me a little, but may be something for a later feature. 18:34:54 Because oh wow finally having mdns and samba work 18:35:00 pjones: He's been communicating with dcbw 18:35:03 +1 I'm all for this 18:35:17 mjg59: just not mentioning it in the feature? okay. 18:35:22 well, I'm +1. 18:35:23 +1 18:35:27 pjones: Yaeh, I checked earlier 18:35:28 +1 18:35:38 +1 18:35:42 #agreed network zones feature is approved 18:35:55 #topic #628 F16Feature: VirtSandbox -- https://fedoraproject.org/wiki/Features/VirtSandbox 18:35:58 .fesco 628 18:35:59 ajax: #628 (F16Feature: VirtSandbox -- https://fedoraproject.org/wiki/Features/VirtSandbox) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/628 18:36:22 +1 18:36:28 +1 18:36:35 I'd vote higher, but I don't think it's allowed. 18:36:39 +1 18:36:39 +10 18:36:41 :) 18:36:50 sgallagh doesn't care if it's allowed. 18:36:55 +1 18:36:56 danpb: so, i could have a copy of IE7 in a box? 18:37:07 because yes. 18:37:11 could stand to have some demos in blog posts, docs, etc 18:37:32 yeah, this is really nice demoware 18:37:42 demofodder? i dont mean that to sound insulting. 18:37:58 anyway, +1 and 18:38:06 #agreed virt sandbox feature is approved 18:38:22 #topic #629 F16Feature: Virt-manager Guest Inspection - https://fedoraproject.org/wiki/Features/Virt-manager_Guest_Inspection 18:38:25 .fesco 629 18:38:25 * shaiton is wondering if you notice that there should be the french meeting at 18:30 UTC. Did you change your schedule guys? 18:38:28 ajax: #629 (F16Feature: Virt-manager Guest Inspection - https://fedoraproject.org/wiki/Features/Virt-manager_Guest_Inspection) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/629 18:38:28 hi 18:38:51 shaiton: we're running a bit long, apparently. 18:39:23 Is this achievable in the F16 timeframe? 18:39:38 ajax, how much time will you need? 18:39:47 sgallagh: hopefully 18:39:57 +1 18:40:03 although the first set of patches are back on the drawing board at the moment 18:40:15 shaiton: four short features and one potentially noisy long one. ten minutes? 18:40:23 shaiton: or we can end now, i don't have a preference really 18:40:28 +1 18:40:32 I'm +1 18:40:38 +1 18:40:45 fine ajax, will come back in twenty minutes :) 18:40:47 +1 18:40:54 ajax: actually it'd only let you run linux apps - it is quite literally running binaries from your host OS inside the guest OS, using filesystem passthrough - so no Windows apps there (for now) 18:40:59 +1 to this as a feature 18:41:18 #agreed virt-manager guest inspection feature is approved 18:41:32 #topic #630 F16Feature: SELinux File Name Transition - https://fedoraproject.org/wiki/Features/SELinuxFileNameTransition 18:41:35 .fesco 630 18:41:36 ajax: #630 (F16Feature: SELinux File Name Transition - https://fedoraproject.org/wiki/Features/SELinuxFileNameTransition) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/630 18:41:41 shaiton: i'll do my best to keep it quick 18:42:12 I'ma ctually borderline -1 to this because it's supposed to be entirely user invisible and really does seem like an implementation detail 18:42:22 likewise. 18:42:30 -1 18:42:47 As we approved the virt image locking as a feature I think this should be approved so +1 18:43:11 Just -1 to having it in the release notes, right? 18:43:25 t8m: That was at least reasonably user-visible 18:43:25 (Not to the feature itself) 18:43:37 "This change only effects Policy writers and the kernel. No other applications should be effected by this change. ". so, -1 as a feature 18:43:41 gholms: Apparently it's already at 100% completion. We won't yank it. 18:43:58 -1 18:44:00 t8m: In that case, danpb said: " well for people managing virt deployments I think it is pretty relevant, because for the first time they have a distributed lock manager for protecting disk images across hosts", which in my mind specifically made it a feature. 18:44:08 in this case, the thing notting said specifically makes it not one. 18:44:30 also, 'affected' 18:44:53 18:44:55 notting: No, this feature causes Policy writers and the kernel to exist :) 18:44:57 (sorry) 18:44:57 It affects the EC2 image directly. 18:45:14 it seems to me due to this feature many explicit code parts in things like passwd, sshd etc. can be dropped 18:45:26 we're at 1 for, 4 against. 18:45:45 Defer to next week? 18:45:55 Tomorrow is feature submission deadline, FYI. 18:46:07 with a question of " will any apps need to change/remove code?" 18:46:10 rbergeron: traditionally things already on this list are counted as "submitted" 18:46:13 Technically it's been submitted, but 18:46:14 yes. 18:47:00 i smell deadlock, so. 18:47:02 * rbergeron wasn't sure if you were planning on deferring all things to next week, or etc. CARRY ON 18:47:04 Who hasn't voted? We have seven people in attendance, don't we? 18:47:11 Do we? 18:47:12 sgallagh: six. 18:47:23 That still implies that someone could -1 and solve this 18:47:24 Well, that's still possibly enough to resolve this, if they vote -1 :) 18:47:41 actually i may not have counted yours 18:47:45 I count 5 -1's. 18:47:55 Ok done 18:47:55 mjg59, me, sgallagh, notting, ajax 18:48:01 yeah. 18:48:02 Whee 18:48:15 There we go, then 18:48:16 #agreed selinux file name transition feature is not approved 18:48:30 (possibly I wasn't explicit enough, so appologies for not enough explicit in my life.) 18:48:36 #topic #631 F16Feature: TigerVNC 1.1 - http://fedoraproject.org/wiki/Features/TigerVNC1.1 18:48:39 .fesco 631 18:48:40 ajax: #631 (F16Feature: TigerVNC 1.1 - http://fedoraproject.org/wiki/Features/TigerVNC1.1) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/631 18:48:53 ack, +1 18:48:55 +1 given that we seem to do this kind of thing right now 18:48:58 oh good, more x509 18:49:03 +1 18:49:17 +1 18:49:23 +1 18:49:32 #agreed tigervnc 1.1 feature is approved 18:49:36 #topic #632 F16Feature: Grub2 - https://fedoraproject.org/wiki/Features/Grub2 18:49:39 .fesco 632 18:49:40 ajax: #632 (F16Feature: Grub2 - https://fedoraproject.org/wiki/Features/Grub2) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/632 18:49:41 Ha ha +1 18:49:57 Assuming that it was actually pjones who submitted this 18:50:02 pjones: still "very early stage"? 18:50:04 * pjones sighs. 18:50:05 +1 18:50:09 +1 18:50:13 +1 to me working my ass off, why not. 18:50:34 +1. looks like it was jeremy who started the feature page 18:50:36 well if it doesn't happen we just don't do it, so. 18:50:42 +1 to the both this and TigerVNC (late_ 18:50:53 #agreed grub2 feature is approved 18:50:58 * rbergeron gets her popcorn out 18:51:17 #topic #623 F16Feature: KDE Plasma Desktop by default - https://fedoraproject.org/wiki/Features/KDE_Plasma_Desktop_by_default 18:51:20 -1 18:51:20 .fesco 623 18:51:21 ajax: #623 (F16Feature: KDE Plasma Desktop by default - https://fedoraproject.org/wiki/Features/KDE_Plasma_Desktop_by_default) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/623 18:51:31 -1 18:51:36 given the last comment in the fesco ticket, -1 18:51:46 -1 as this is not endorsed by KDE SIG 18:52:10 it's kevin's and I heard cwickert's idea :) 18:52:17 And kevin doesn't seem to be here to discuss it 18:52:23 nor does cwickert. 18:52:37 we're at -4. 18:52:44 -1 not endorsed by kde sig 18:52:44 I'm abstaining. 18:52:49 okay, -5. 18:52:55 #agreed kde-by-default feature is rejected 18:52:58 with rdieter we understands as more like to be taken seriously 18:53:20 understand it 18:53:23 woo finally 18:53:28 #topic open floor 18:53:39 anybody? bueller? 18:53:39 I'll chair next week unless anyone else wants to? 18:53:44 does -1 mean that the work can happen, but won't be mentioned in release notes? :-) 18:53:58 kalev: It absolutely does mean that 18:54:14 kalev: from the perspective of the feature process, sure. 18:54:21 mjg59: all yours, man. 18:54:26 I was just trying to be funny about making KDE default and voting -1. 18:54:29 I'm on vacation next week 18:54:31 honestly, i'm not sure a change of the default offering is even a FESCo issue 18:54:40 If people convince everyone involved that the default should be changed then that's their decision 18:54:48 notting: but advertising it certainly is. 18:54:53 notting: yeah, well, i asked about our procedural standing on #fedora-devel earlier for a reason 18:55:01 (for reasons bizarre) 18:55:02 fesco's not in the business of overruling policy decisions unless there's a real technical reason for doing so 18:55:04 #action mjg59 to chair next week 18:55:38 will close in a minute if there's nothing else 18:55:49 hi, I'm the author of http://fedoraproject.org/wiki/Features/Ns3 18:55:56 it's intended for F17 18:56:05 I would be grateful for any suggestions 18:56:44 rivanvx: Probably best to bring it up on devel@ 18:56:52 aye. 18:57:15 ok, thanks 18:57:22 #endmeeting