=================================== #fedora-meeting: FESCO (2011-01-05) =================================== Meeting started by nirik at 17:30:01 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2011-01-05/fesco.2011-01-05-17.30.log.html Meeting summary --------------- * init process (nirik, 17:30:01) * #516 Updates policy adjustments/changes (nirik, 17:40:30) * AGREED: will allow direct pushes for security updates that are not critpath. (nirik, 17:43:12) * #518 Abrt (nirik, 17:45:18) * will ask abrt maintainers for a roadmap (nirik, 17:47:39) * will see about a session at fudcon to try and improve abrt. (nirik, 17:47:51) * #521 Reconsider RemoveSUID feature (nirik, 17:51:03) * LINK: https://fedorahosted.org/fesco/ticket/521 (nirik, 18:07:18) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=648653 (dwalsh, 18:07:31) * LINK: http://forums.grsecurity.net/viewtopic.php?f=7&t=2522 (dwalsh, 18:08:04) * AGREED: will gather more info and revisit this next week. (nirik, 18:21:33) * need info on tmpfs status (nirik, 18:21:40) * need info on nfs capabilities status. (nirik, 18:21:48) * #526 "systemd" feature scope acurracy and precision (nirik, 18:22:15) * AGREED: mitr and mezcalero to work on updating feature page. (nirik, 18:42:33) * #527 Dist Git Branch Redux Proposal (nirik, 18:42:53) * AGREED: This proposal is accepted. (nirik, 18:46:09) * #528 Add xz package to buildsys-build comps group (nirik, 18:46:18) * AGREED: This proposal is accepted. (nirik, 18:47:02) * #532 Nonresponsive maintainer: pysvn (nirik, 18:47:09) * AGREED: will add reporter as co-maintainer (nirik, 18:50:45) * #531 Orphaned package ownership claiming clarification (nirik, 18:50:54) * #531 Orphaned package ownership claiming clarification (nirik, 18:51:33) * AGREED: ask pkgdb/releng folks about setting up something to auto retire/block packages after 3 months as orphan. (nirik, 19:03:04) * #434 F15Feature - DNSSEC_on_workstations - https://fedoraproject.org/wiki/Features/DNSSEC_on_workstations (nirik, 19:03:24) * will ask for updated info from feature owners. (nirik, 19:05:01) * #529 F15Feature: KDE46 - http://fedoraproject.org/wiki/Features/KDE46 (nirik, 19:05:09) * AGREED: feature is approved. (nirik, 19:06:41) * #530 F15Feature: Riak - http://fedoraproject.org/wiki/Features/Riak (nirik, 19:06:55) * AGREED: Feature is approved (nirik, 19:08:53) * #534 F15Feature: Dynamic Firewall -https://fedoraproject.org/wiki/Features/DynamicFirewall (nirik, 19:08:59) * AGREED: Feature is approved. (nirik, 19:20:02) * #537 F15Feature: Spice support for virt-manager - http://fedoraproject.org/wiki/Features/SpiceInVirtManager (nirik, 19:20:11) * AGREED: Feature is approved. (nirik, 19:20:55) * #535 F15Feature: ecryptfs in authconfig - http://fedoraproject.org/wiki/Features/EcryptfsAuthConfig (nirik, 19:21:05) * AGREED: Feature is approved. (nirik, 19:24:19) * #536 F15Feature: RPM 4.9 - http://fedoraproject.org/wiki/Features/RPM4.9 (nirik, 19:24:21) * AGREED: Feature is approved. (nirik, 19:25:59) * Open Floor (nirik, 19:26:10) Meeting ended at 19:28:20 UTC. People Present (lines said) --------------------------- * nirik (203) * cwickert (60) * mjg59 (57) * ajax (31) * notting (31) * zodbot (23) * mezcalero (19) * dwalsh (17) * sgrubb (16) * tibbs|h (13) * SMParrish_mobile (11) * mitr (10) * mmaslano (9) * skvidal (5) * rbergeron (2) * dgilmore (2) * pjones (1) * fenris02 (1) * drago01 (1) * kylem (0) * mclasen (0) * SMParrish (0) -- 17:30:01 <nirik> #startmeeting FESCO (2011-01-05) 17:30:01 <zodbot> Meeting started Wed Jan 5 17:30:01 2011 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:30:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:30:01 <nirik> #meetingname fesco 17:30:01 <zodbot> The meeting name has been set to 'fesco' 17:30:01 <nirik> #chair mclasen notting nirik SMParrish kylem ajax cwickert mjg59 mmaslano 17:30:01 <nirik> #topic init process 17:30:01 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 mmaslano nirik notting 17:30:37 <cwickert> fuck fuck fuck 17:30:39 <cwickert> sorry 17:30:54 <cwickert> the meeting is just to early for me :) 17:31:08 <nirik> sorry. ;( 17:31:10 <mjg59> Hi 17:31:14 <nirik> we could revisit times again... 17:31:29 * cwickert will be around in 5 minutes 17:31:37 <mjg59> I think we can wait 5 minutes 17:31:43 * notting is here 17:31:44 <cwickert> thanks 17:31:56 <SMParrish_mobile> I am here but mobile :) 17:32:07 * mmaslano is here 17:32:42 <ajax> hey hey\ 17:33:50 <nirik> shall we wait a few before starting for cwickert... 17:34:10 <ajax> sure 17:34:30 <ajax> i may have to duck out around 1, apologies 17:35:51 <nirik> no worries. we have a bunch of features today, but hopefully we can churn thru them pretty fast. 17:37:44 <nirik> hopefully everyone had a nice holiday. ;) 17:38:06 * cwickert is back 17:38:16 <nirik> cool. Shall we dive in then? 17:38:45 <cwickert> sure, but again I haven't found the time to work on the updates-feature proposal 17:38:54 <cwickert> so please don't ask for it ;) 17:38:57 <nirik> ok. ;) 17:39:19 <nirik> I also didn't pick anything on the updates process changing this week from the ideas container. 17:39:28 <nirik> Figured we had enough other stuff this week. 17:39:51 <nirik> #info #516 Updates policy adjustments/changes - no action this week. 17:40:02 <cwickert> hold on 17:40:09 <nirik> #undo 17:40:09 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0xe822d10> 17:40:11 <nirik> yeah? 17:40:17 <cwickert> can we have the one little change this week already 17:40:26 <nirik> sure, lets discuss. 17:40:30 <nirik> #topic #516 Updates policy adjustments/changes 17:40:30 <nirik> .fesco 516 17:40:32 <zodbot> nirik: #516 (Updates policy adjustments/changes) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/516 17:40:35 <nirik> what did you want to bring up? 17:40:35 <cwickert> propsal: allow direct pushes for security updates that are not critpath 17:41:26 <cwickert> I can understand we ban direct pushes for important conponents 17:41:29 <nirik> ok, the idea being that they can't break the universe because they are not critpath, and getting them out sooner than a week or after testing is better... 17:41:37 <cwickert> right 17:42:00 <ajax> fine with me 17:42:00 <cwickert> everybody fine with that or is someone feeling uncomfortable? 17:42:16 <mjg59> Not thrilled, but ok 17:42:18 <nirik> I guess I am a weak +1 on that... 17:42:24 <mmaslano> +1 17:42:25 <SMParrish_mobile> sounds fine to me 17:42:29 <cwickert> mjg59: any counterpropsal? 17:42:43 * cwickert is open to suggestions 17:43:12 <nirik> #agreed will allow direct pushes for security updates that are not critpath. 17:43:20 <cwickert> +1 (for the record) 17:43:50 <nirik> I'll note that I also still need to talk to lmacken about allowing critpath security updates to have a timeout. Will try and file tickets on these later today. 17:43:51 <cwickert> #note: needs to be implemented in bodhi 17:43:56 <nirik> yeah. 17:43:57 * notting is a weak +1 too 17:44:14 <mjg59> cwickert: Not really 17:44:20 <nirik> ok, anything more on updates right now, or shall we move on? 17:44:39 * cwickert thinks we should move on 17:45:02 <nirik> ok. 17:45:15 <nirik> Nothing on features repo, nothing on stats that I can see... so... 17:45:18 <nirik> #topic #518 Abrt 17:45:18 <nirik> .fesco 518 17:45:20 <zodbot> nirik: #518 (Abrt) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/518 17:45:30 <nirik> we wanted to look at this again in the new year. 17:45:53 <nirik> do we need to invite abrt folks to a meeting, or ask them for a roadmap, or what do we want here? 17:46:34 <cwickert> +1 for meeting with the abrt folks. or should we discuss this at tempe? 17:46:35 <ajax> i'll ping them for a roadmap, hopefully will have something next weekish 17:46:58 <ajax> after that i'll be traveling for LCA so i may not be very available. 17:47:18 <nirik> cwickert: if they are going to be there, an abrt session/brainstorming would be nice. 17:47:26 <nirik> ajax: thanks. Can you note that in the ticket? 17:47:37 <ajax> yep 17:47:39 <nirik> #info will ask abrt maintainers for a roadmap 17:47:51 <nirik> #info will see about a session at fudcon to try and improve abrt. 17:47:58 <nirik> Anything else on this topic? 17:48:11 <rbergeron> if abrt folks aren't coming and people think it would be useful, let me know and I'll see if i can get them wrangled. 17:48:45 <nirik> cool. Thanks. 17:48:48 * rbergeron bows 17:49:07 <mmaslano> they are in my timezone, maybe you should write into ticket or send them email 17:49:17 <mmaslano> not sure if they are going to tempe 17:49:32 <nirik> ok. can note that. 17:50:17 * nirik will move on in 30sec unless someone has something else on this topic. 17:51:03 <nirik> #topic #521 Reconsider RemoveSUID feature 17:51:03 <nirik> .fesco 521 17:51:04 <zodbot> nirik: #521 (Reconsider RemoveSUID feature) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/521 17:51:12 <nirik> This is another one we wanted to look at again in the new year. 17:51:30 <ajax> yeah 17:51:34 <mjg59> What's the situation with the tmpfs patches? 17:51:40 * nirik isn't sure. 17:52:02 <ajax> also, this: http://forums.grsecurity.net/viewtopic.php?f=7&t=2522 17:52:34 <ajax> in which over half of the capabilities are actually equivalent to root 17:52:49 * ajax becoming increasinly disillusioned with the whole idea 17:53:38 <nirik> yeah, seems like capabilities could have been designed for suid replacement, but were not really... 17:54:00 <nirik> ie, we need more of them or a better design of which ones do what or something. 17:54:08 <ajax> we need a _lot_ more of them 17:54:11 <ajax> hundreds. 17:55:15 <nirik> yeah. 17:55:19 <cwickert> ouch 17:55:35 <ajax> so, yeah. really not convinced. 17:55:47 <nirik> I'd like to hear from the feature owners here before we do anything, but yeah, this is seeming to be currently not very worth it. 17:56:20 <cwickert> is it not worth it or are we likely to run into troubles with it? 17:56:38 <notting> causes problems with tmpfs (and other fses that don't support it) 17:56:49 <notting> doesn't seem to actually gain much outside of a few simple cases? (ping?) 17:56:56 <dwalsh> I am here 17:57:01 <nirik> welcome. 17:57:21 <nirik> dwalsh: do you know the status of the tmpfs capabilities patches/work? 17:57:39 <nirik> and do you think the suid->capabilities feature is still worth doing? 17:57:44 <mjg59> Well, several of the capability->root cases do involve non-standard configurations 17:57:55 <mjg59> Or a set of specific circumstances 17:57:56 <dwalsh> Nope let me ping eparis 17:58:45 <mjg59> I think the question is the same as it was before, ie "In the absence of other bugs, does this increase or reduce security - and how much pain will it cause in the process" 17:59:22 <nirik> at the start the pain seemed pretty minimal... but the tmpfs thing is anoying lots of folks. ;( 18:00:02 <dwalsh> Is the tmpfs thing blowing up more then just ping? 18:00:03 <mjg59> Yeah. I think there's a pretty rational argument that this feature depends upon our standard filesystems supporting it, and that includes tmpfs 18:00:28 <dwalsh> I agree. 18:00:31 <nirik> dwalsh: well, the mock thing mostly. 18:00:41 <nirik> mock won't work with tmpfs anymore with this change. 18:01:45 <nirik> sgrubb: hey. welcome. 18:01:51 <sgrubb> hi 18:01:59 <nirik> we are just talking about the nosuid feature. 18:02:01 <mjg59> So I think unless we have a pretty good timescale for tmpfs supporting this it'll have to wait until it does 18:02:22 <nirik> sgrubb: do you know the status on any tmpfs patches? and do you still feel this feature is worth doing ? 18:02:24 <fenris02> mjg59, did you try the loopfs over tmpfs hack for /var/lib/mock ? 18:02:32 <mjg59> I didn't 18:02:42 <mjg59> But I don't think it matters 18:02:46 <sgrubb> I think eparis was working the tmpfs issue 18:03:18 <mjg59> If I can't copy ping to a tmpfs and run it, we don't have the infrastructure to support this feature 18:03:29 <sgrubb> but I thought we had a workaround for the mock issue of not having rpm failing when it cannot set the fs capabilities 18:03:47 <sgrubb> that could even be controlled by a .rpmmacro setting if need be 18:04:02 <dwalsh> Panu, Has this feature been added? 18:05:42 <nirik> so, proposal: gather more info and update our ticket, revisit next week? 18:05:50 <ajax> gotta run 18:05:52 * ajax afk 18:06:00 <nirik> ajax: thanks. Enjoy. 18:06:09 <sgrubb> nirik, I think we need to find out what's going on with tmpfs 18:06:13 <nirik> yeah. 18:06:20 <cwickert> +1 to nirik's proposal 18:06:23 <mjg59> I'd go with Proposal: Defer to F16 unless support in tmpfs can be provided in the immediate future 18:06:32 <sgrubb> I think the feature is worth doing as we constantly get requests for it 18:06:45 <sgrubb> otherwise we may as well go back to the old capabilities model 18:06:47 <nirik> sgrubb: would you be willing to track down status on tmpfs and update our ticket with it? 18:07:00 <sgrubb> the bz? 18:07:18 <nirik> https://fedorahosted.org/fesco/ticket/521 18:07:20 <mjg59> sgrubb: I don't see hacking around mock's behaviour as a solution 18:07:31 <dwalsh> https://bugzilla.redhat.com/show_bug.cgi?id=648653 18:07:39 <sgrubb> mjg59, I'm not talking about mock's behavior 18:07:52 <sgrubb> rpm itself fails when it probably shouldn't 18:07:52 <dwalsh> As far as whether this is worth doing. Here is some analysys. 18:07:58 <sgrubb> is not good 18:08:04 <dwalsh> http://forums.grsecurity.net/viewtopic.php?f=7&t=2522 18:08:38 <mjg59> sgrubb: rpm is failing because one of the standard filesystems we ship and support doesn't implement a feature we depend on 18:08:48 <dwalsh> Yes I think rpm has to be able to handle file systems not supporting file capabilities as a warning instead of failure. 18:09:01 <mjg59> There's an argument that rpm should handle that more gracefully, but it doesn't change the fact that one of the standard filesystems we ship and support doesn't implement a feature we depend on 18:09:29 <mjg59> Until tmpfs implements this I don't think we can depend on filesystem based capabilities for anything 18:09:31 <sgrubb> mjg59, there's several filesystems that don't support it and we depend on it 18:09:42 <notting> dwalsh: so, essentially, it's not worth it for any of the capabilities in the first set 18:10:02 <sgrubb> I wouldn't say that 18:10:11 <dwalsh> I think it is better just not perfect. 18:10:19 <sgrubb> right 18:10:26 * cwickert tends to agree with mjg59 18:10:29 <mjg59> I think the feature is worth it. But I think we need to be able to support the feature, and I don't think we can currently do that. 18:10:32 <dwalsh> But we need to look at this analysys and try to make the capabilties model better 18:10:43 * nirik nods. 18:10:43 <mjg59> Whether capabilities are perfect is an orthogonal issue 18:10:56 <mjg59> Does this feature enhance security? In the absence of other bugs, yes 18:10:58 <notting> dwalsh: even for 'cap_sys_admin'? 18:11:00 <sgrubb> dwalsh, what is missing from brad's analysis is the couple of fs caps with pam_cap 18:11:06 <mjg59> Does this feature break things? At present, yes 18:11:21 <mjg59> Should we ship features unless we have a known timescale for them not to break things? 18:11:24 <mjg59> I think the answer there is "no" 18:11:29 <sgrubb> pam_cap is an essential part of the new model 18:11:41 <nirik> mjg59: yeah. I'm inclined to agree, but I'd like to see if we can find out more status on tmpfs before just saying punt to next release. 18:11:48 <mjg59> nirik: Absolutely 18:11:57 <mjg59> But I don't want to keep just putting this off 18:12:12 <dwalsh> mjg59, I agree. 18:12:31 <dwalsh> notting, I would like to see cap_sys_admin broken up into more capabilities. 18:12:43 * nirik thinks it's reasonable to wait a week to gather more info... if tmpfs turns out to be a ways off, punt to next release and go back to suid for now. 18:12:45 <dwalsh> Since it is just a dump for many issues. 18:14:18 <mjg59> Yeah, I'm ok with revisiting next week if the assumption then is that if we don't have a timescale for tmpfs we punt to F16 18:14:34 <nirik> any objections to that? 18:15:09 <nirik> sgrubb: you said there were other fs'es we support that don't support caps? which ones? 18:15:39 <dwalsh> nfs? 18:16:30 <nirik> possibly... 18:16:38 <notting> nfs doesn't? ick. 18:16:39 <mjg59> So does this work with nfs / ? 18:16:51 <mjg59> And if not, what's the fallback? 18:17:22 <dwalsh> setuid would have to be fall back. 18:17:53 <notting> ... which could make provisioning fun, if you're not provisioning directly to the nfs root 18:18:04 <mjg59> Wurgh. 18:18:22 <pjones> setuid doesn't really make a good fallback... the bit is either set or not on the executable. 18:18:50 * nirik doesn't have a nfs handy to test to see... 18:18:53 <mjg59> So if we start distributing applications that have been *written* for fs-based capabilities, you're suggesting that installing them on NFS should make them SUID instead? 18:19:10 <nirik> anyhow, shall we gather info and revisit next week? we have a bunch of other items on the agenda. ;) 18:19:13 <mjg59> I don't think this is a good thing 18:19:33 <nirik> yeah, I don't think thats a good solution. 18:20:46 * nirik will move on in 30 seconds unless something further on this issue. 18:21:02 <mjg59> So I think we need a tmpfs timeline and more information on what happens with nfs 18:21:05 <nirik> Thanks for coming dwalsh, sgrubb. If you can gather info for us that would be great. 18:21:33 <nirik> #agreed will gather more info and revisit this next week. 18:21:35 <skvidal> nirik: you might think about pinging steved for the nfs question 18:21:40 <nirik> #info need info on tmpfs status 18:21:48 <skvidal> nirik: to be here next week 18:21:48 <nirik> #info need info on nfs capabilities status. 18:21:54 <nirik> skvidal: good idea. 18:22:15 <nirik> #topic #526 "systemd" feature scope acurracy and precision 18:22:15 <nirik> .fesco 526 18:22:16 <zodbot> nirik: #526 ("systemd" feature scope acurracy and precision) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/526 18:22:43 <nirik> I think this was mostly answered there... although I think we should ask that the feature page be updated. 18:23:10 <nirik> And we should find out if changing everything to systemd units files is in the scope of the feature or just a nice thing to have if people get around to it. 18:23:24 <mjg59> nirik: Lennart said he'd try to drop by for this 18:23:27 <mjg59> Hang on a minute 18:23:41 <mjg59> Ah, good 18:23:42 <nirik> cool. 18:23:48 <nirik> welcome mezcalero 18:23:50 <mezcalero> hi 18:24:32 <mezcalero> did imiss anything so far? 18:24:48 <nirik> not much. ;) 18:25:06 <nirik> so, mitr wanted to get a better idea on scope and parts for systemd feature. 18:25:12 <mjg59> 18:22 < zodbot> nirik: #526 ("systemd" feature scope acurracy and precision) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/526 18:25:15 <mjg59> 18:22 <+nirik> I think this was mostly answered there... although I think we should ask that the feature page be updated. 18:25:18 <mjg59> 18:23 <+nirik> And we should find out if changing everything to systemd units files is in the scope of the feature or just a nice thing to have if people get around to it. 18:25:30 <nirik> which I think were answered pretty well in comment 3. 18:26:12 <nirik> My outstanding question is: is changing everything to use systemd units part of this feature for f15? or is it just 'change things that would like to/can change'? it's unclear from the feature page. 18:26:27 <nirik> also, it would be good to update the feature page with info from comment 3. ;) 18:27:27 * cwickert thinks convert as much as possible to systemd units, but mezcalero can tell us better 18:27:56 <mezcalero> nirik: well, no, i don't want to make the convrsoin of all service files a feature for f15. i mean, i am happy to see if people convert their stuff, but i myself do not see that as my own priority 18:28:09 <mitr> If I may... I don't really think it's the feature owner's duty to actively get other people in the community involved, but the feature page should really allow people to see whether they should want to. 18:28:24 <nirik> mezcalero: ok, thats fine, but should perhaps be made clear on the feature page. 18:28:24 <cwickert> mitr: +1 18:28:47 * cwickert is willing to abuse his proven packager powers to help mezcalero 18:28:59 <mezcalero> cwickert: always happy for help ;-) 18:29:04 <mitr> Looking at any of the things discussed in comment #3, if you asked me to list things an init system does, none of them would be included. 18:29:05 <nirik> mitr: sure. Did your questions get answered? or do you have further ones? 18:29:07 <cwickert> mezcalero: is there a tracker bug? 18:29:19 <nirik> cwickert: there is... 18:29:24 <mezcalero> cwickert: there is 18:29:29 <mitr> nirik: "My wish, as a second best option, is that FESCo (probably in cooperation with the owners of the systemd feature) explicitly specifies the scope of the systemd feature" 18:30:21 <nirik> mitr: would what is on the feature page now + whats in comment 3 work for that? 18:30:50 <nirik> ie, cron is out of scope, rc.sysinit reorg is in scope, etc? 18:31:48 <mezcalero> hmm, so is this issue simply about extending the feature page? i don't think neither the cron-like functionality, nor the local stuff should be documented there really, as we don't use this for f15 really. the password stuff is an implementation detail, not many other packager folks should really care 18:31:51 <nirik> mitr: I think some of the things that are scope expansion are just part of rc.sysinit getting revamped. 18:32:10 <mezcalero> and regaridng the tmpfiles stuff this is kinda covered by the var/run tmpfs feature page 18:32:40 <nirik> mezcalero: yeah, the feature page would be nice to update to what it currently covered.. and perhaps even note what is _not_ covered... ? 18:32:54 <dwalsh> BTW Steved just said that NFS does support file capabilities. 18:32:54 <mitr> nirik: I don't know how to draw the boundary, but I'd like the boundary of a feature to be specified _in advance_. IOW, I'd like to _now_ know that mlocate is not in scope. 18:33:00 <nirik> dwalsh: cool. ;) 18:33:06 <mitr> (this is an obviously ridiculous example just to demonstrate the point) 18:33:29 <notting> dwalsh: yay. 18:33:30 <nirik> mitr: well, it's impossible to note everything thats not in scope, right? 18:34:15 <mitr> nirik: "Anything run from rc.sysinit is in scope" is the kind of answer I'd like. (although I'd be happier if it were more limited0 18:34:52 <mezcalero> well, systemd is a system and service manager 18:35:05 <mezcalero> so it manages the systemd, which is a really fuzzy description of what it does 18:35:24 <mezcalero> but stuff like the tmpfiles stuff i would definitely would subsume under "managing the system" 18:35:28 <nirik> perhaps we could approach it this way... mezcalero: has pretty much all the functionality landed in rawhide? it's just down to bugfix mode and converting to units packages? 18:35:51 <mezcalero> nirik: i don't se any big changes coming for F15, no 18:36:06 <mezcalero> nirik: currently working my way through rhbz and stuff 18:36:33 <mezcalero> nirik: rawhide is pretty much in shape already, when it comes to systemd 18:36:38 <nirik> yeah. 18:36:41 <mezcalero> (i mean, it kinda was already for the f14 timeframe ;-)) 18:37:21 <mezcalero> i mean, we will probably end up mergin the functionality of CK into systemd in F16 or so 18:37:22 <nirik> so, what shall we do here? mezcalero: can you work on updating the feature page with current status and note the scope there? mitr: would that be sufficent? would you be willing to work with him to get the feature page in shape? 18:37:30 <mezcalero> so there will be changes coming, but not for F15 really 18:37:43 <nirik> do you have a roadmap type doc? 18:37:49 <mitr> nirik: That works for me. 18:37:55 <drago01> there is a todo file in git 18:38:02 <mezcalero> nirik: there's a TODO list in systemd git which covers the CK stuff, though terse 18:38:18 <nirik> cool. 18:38:26 <nirik> anyone have objections to that plan? 18:38:34 <mezcalero> nirik: i kinda would like more clarficiations on what is actually requested here before we add clarifications to the feature page ;-) 18:39:41 <nirik> mezcalero: I think he just wants scope to note that systemd will be involved with things around rc.sysinit and things it runs, so maintainers of those packages should expect/be involved in changes. 18:40:50 <mitr> Well ideally more precise - but if no major changes are planned, just adding the items from comment#3 would make the scope more or less precise AFAICS 18:40:58 * nirik nods. 18:41:42 <nirik> mitr: perhaps you could propose feature page changes and mezcalero can look them over for accuracy? and if you guys get stuck, we can revisit? 18:42:24 <mitr> This is kind of backwards :), but I can do that 18:42:33 <nirik> #agreed mitr and mezcalero to work on updating feature page. 18:42:41 <nirik> Thanks mitr and mezcalero. 18:42:53 <nirik> #topic #527 Dist Git Branch Redux Proposal 18:42:53 <nirik> .fesco 527 18:42:55 <zodbot> nirik: #527 (Dist Git Branch Redux Proposal) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/527 18:42:57 <nirik> Oxf13: you around? 18:43:07 <mezcalero> thanks 18:43:28 <mitr> nirik, mezcalero: thank you 18:44:41 * nirik is fine with this proposal. It changes stuff for clients, but maintainers should hopefully figure things out. 18:44:43 <cwickert> +1 on this 18:45:03 <notting> I like simpler. +1 18:45:40 <mjg59> Sure, +1 18:45:43 <mmaslano> +1 18:46:09 <nirik> #agreed This proposal is accepted. 18:46:18 <nirik> #topic #528 Add xz package to buildsys-build comps group 18:46:18 <nirik> .fesco 528 18:46:19 <zodbot> nirik: #528 (Add xz package to buildsys-build comps group) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/528 18:46:24 <nirik> +1 from me. 18:46:51 <notting> +1 18:46:54 <mjg59> +1 can't see why not 18:46:54 <mmaslano> +1 18:46:57 <SMParrish_mobile> +1 18:47:02 <nirik> #agreed This proposal is accepted. 18:47:09 <nirik> #topic #532 Nonresponsive maintainer: pysvn 18:47:09 <nirik> .fesco 532 18:47:11 <zodbot> nirik: #532 (Nonresponsive maintainer: pysvn) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/532 18:47:49 <nirik> This maintainer has only the one package. 18:47:52 <nirik> pysvn 18:48:02 <nirik> They have not been active or answering emails, etc for a while. 18:48:56 <nirik> I guess I am +1 to adding the reporter as co-maintainer, then if they don't show up after a while changing ownership... 18:49:10 <SMParrish_mobile> I'm good with that +1 18:49:41 <mmaslano> +1 18:49:47 <ajax> (back) 18:50:08 <nirik> also, it would be nice if we had a better way to detect and handle missing maintainers (but thats a larger topic) 18:50:16 <mjg59> +1 18:50:28 * notting is +1 about adding sgallagher as a comaintainer 18:50:45 <nirik> #agreed will add reporter as co-maintainer 18:50:54 <nirik> #topic #531 Orphaned package ownership claiming clarification 18:50:54 <nirik> .fesco 529 18:50:56 <zodbot> nirik: #529 (F15Feature: KDE46 - http://fedoraproject.org/wiki/Features/KDE46) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/529 18:51:13 <nirik> this one has to do with when to re-review things that were orphaned coming back into the collection. 18:51:22 <nirik> ugh... 18:51:24 <nirik> wrong thing. 18:51:33 <nirik> #topic #531 Orphaned package ownership claiming clarification 18:51:33 <nirik> .fesco 529 18:51:34 <zodbot> nirik: #529 (F15Feature: KDE46 - http://fedoraproject.org/wiki/Features/KDE46) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/529 18:51:40 <nirik> wrong ticket. 18:51:45 <nirik> .fesco 531 18:51:46 <zodbot> nirik: #531 (Orphaned package ownership claiming clarification) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/531 18:52:13 <tibbs|h> The policy is clear, but seems a bit odd. 18:52:57 <nirik> I think the issue the reporter wanted to fix was that people could bypass the policy... 18:53:19 <nirik> just claim it in pkgdb, build, etc. If you don't need new branches or anything, scmadmins don't see it. 18:53:28 <tibbs|h> The problem is that you end up with what's basically a merge review. 18:53:42 <tibbs|h> Since there's no incentive to do the review, and if he hadn't posted one nobody would be the wiser. 18:54:18 <tibbs|h> Some cron job that auto-blocks packages after three months of orphanage, or somesuch, would resolve the issue. 18:54:19 <nirik> right. 18:54:45 <tibbs|h> (I'm not sure "blocks" is the right term. Maybe blocks in koji and retires in pkgdb.) 18:55:04 <nirik> or just blocks in koji... they couldn't build then, though it would be less clear. 18:55:19 <tibbs|h> I'm not sure how feasible any of that is, however. 18:55:40 <nirik> I can ask abadger1999... 18:56:06 <nirik> so really we need some kind of tech solution here, and there's not really any fesco action right? 18:56:22 <cwickert> can't we just trust people? do we need another technical solution to a social problem? 18:56:37 <tibbs|h> I don't think trust is the issue here. 18:56:47 <cwickert> if we have a problem, it's the missing knowledge of the guidelines 18:56:52 <tibbs|h> Since you can't see how long a package has been orphaned in pkgdb. 18:57:02 <nirik> cwickert: well, I don't know that people are doing it because they want to subvert the policy, it's because they don't know the policy. 18:57:05 <ajax> on the one hand, re-reviewing orphans is a little draconian without re-review of existing packages 18:57:21 <tibbs|h> I don't think it's draconian at all. 18:57:27 <ajax> actually i guess i just have the one hand there. 18:57:30 <dgilmore> tibbs|h: blocking a package in koji will cause it to drop from rawhide 18:57:36 <tibbs|h> Good. 18:57:42 <tibbs|h> That's what we want, isn't it? 18:57:53 <tibbs|h> I mean, if it's orphaned, it certainly shouldn't be in rawhide or the next release. 18:57:57 <ajax> re-re of blocked packages sounds perfectly sane 18:58:11 <ajax> re-re of things that are merely orphaned for a month during a rawhide cycle, meh 18:58:29 <cwickert> +1 18:58:38 <notting> releng is the one that blocks packages, but we don't (usually) check that the other orphaning/deprecation steps are done 18:58:39 <nirik> right, which is why the policy was 3 months. 18:58:45 <tibbs|h> Not a month, three months. Which is half of the release cycle. 18:59:08 <cwickert> and means it has missed at least one milestone 18:59:19 <ajax> sorry, i was inventing numbers with "1 month". 3 sounds reasonable. 18:59:47 <nirik> so we need something to move things to retired / block them after 3 months, right? 19:00:03 <skvidal> and maybe obsolete them? 19:00:18 <cwickert> ouch 19:00:24 <nirik> skvidal: ;) 19:00:30 <cwickert> I don't think this is necessary in rawhide 19:00:50 <skvidal> nirik: hey - just thought I'd give it a shot :) 19:01:03 <skvidal> I wonder if I can renick to sysiphus 19:01:36 <nirik> proposal: ask pkgdb/releng folks about setting up something to auto retire/block packages after 3 months as orphan. 19:02:12 <SMParrish_mobile> +1 19:02:29 <mmaslano> +1 19:02:31 <ajax> +1\ 19:02:40 * nirik is fine with his own proposal. ;) 19:02:58 <notting> +1 19:03:02 <cwickert> +1 19:03:04 <nirik> #agreed ask pkgdb/releng folks about setting up something to auto retire/block packages after 3 months as orphan. 19:03:17 <nirik> that would also save us the orphan cull step. 19:03:24 <nirik> #topic #434 F15Feature - DNSSEC_on_workstations - https://fedoraproject.org/wiki/Features/DNSSEC_on_workstations 19:03:24 <nirik> .fesco 434 19:03:25 <zodbot> nirik: #434 (F15Feature - DNSSEC_on_workstations - https://fedoraproject.org/wiki/Features/DNSSEC_on_workstations) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/434 19:03:30 <nirik> Does anyone know the status here? 19:03:35 <nirik> it's been around a while... 19:04:01 <ajax> not heard anything. 19:04:53 <nirik> I Guess I will ping the ticket and we can try again next week. 19:05:01 <nirik> #info will ask for updated info from feature owners. 19:05:09 <nirik> #topic #529 F15Feature: KDE46 - http://fedoraproject.org/wiki/Features/KDE46 19:05:09 <nirik> .fesco 529 19:05:11 <zodbot> nirik: #529 (F15Feature: KDE46 - http://fedoraproject.org/wiki/Features/KDE46) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/529 19:05:40 <cwickert> +1 19:05:47 <mjg59> Looks fine to me 19:05:52 <nirik> +1 here. 19:05:58 * nirik notes the spin size change. 19:05:59 <SMParrish_mobile> +1 19:06:07 <ajax> +1 19:06:12 <notting> "work on adding kde-integration to libreoffice " - details? 19:06:14 <notting> but, +1 19:06:41 <nirik> #agreed feature is approved. 19:06:47 <nirik> notting: might add that to the talk page... 19:06:55 <nirik> #topic #530 F15Feature: Riak - http://fedoraproject.org/wiki/Features/Riak 19:06:55 <nirik> .fesco 529 19:06:56 <zodbot> nirik: #529 (F15Feature: KDE46 - http://fedoraproject.org/wiki/Features/KDE46) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/529 19:07:27 <nirik> .fesco 530 19:07:28 <zodbot> nirik: #530 (F15Feature: Riak - http://fedoraproject.org/wiki/Features/Riak) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/530 19:07:31 * nirik has link issues today 19:07:47 <ajax> just new packages, +1 19:07:58 <mjg59> +1 19:08:00 <cwickert> +1 19:08:02 <nirik> sure, fine with me as well. 19:08:36 <SMParrish_mobile> +1 19:08:46 <notting> +1 19:08:53 <nirik> #agreed Feature is approved 19:08:59 <nirik> #topic #534 F15Feature: Dynamic Firewall -https://fedoraproject.org/wiki/Features/DynamicFirewall 19:08:59 <nirik> .fesco 534 19:09:00 <zodbot> nirik: #534 (F15Feature: Dynamic Firewall - https://fedoraproject.org/wiki/Features/DynamicFirewall) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/534 19:09:19 <cwickert> +1, however I'd like some clarification on this 19:09:24 <cwickert> maybe mjg59 can help 19:09:32 <mjg59> I think it needs a little clarification with respect to the tray icon 19:09:38 <cwickert> right 19:09:43 <mjg59> But otherwise no problem 19:09:52 <notting> danpb raised some points on the list about this 19:09:56 <cwickert> what if not a try icon? what are the alternatives? 19:10:04 <notting> but esp. if it's not the default, i think we can work through it 19:10:43 <notting> the implication is that the tray icon merely displays status 19:10:50 <notting> and wraps the command lne 19:10:55 <notting> so it can be controlled w/o it 19:11:12 <nirik> so, if it's not default, is this more of a tech preview? ;) 19:11:52 <mmaslano> proof of concept 19:11:53 * cwickert likes to have a try icon 19:12:02 <cwickert> s/try/tray :) 19:12:35 <nirik> anyhow, +1 for it... I think it's a good plan, if early. 19:12:57 <cwickert> I have seen it already in action 19:13:00 <cwickert> and it rocks 19:13:04 <SMParrish_mobile> +1 19:13:26 <cwickert> however if you do everything with notifications, the desktop can become messed up fast 19:13:35 <cwickert> this is why I like the tray icon 19:13:40 <notting> isn't the point of a good firewall that you *won't* see it? :) 19:13:51 <cwickert> I don't think so 19:14:09 <nirik> what would show in the tray ? denials? 19:14:21 <cwickert> If I cannot use the network printer due to a restrictive firewall, seeing it saves troubleshooting 19:14:36 <cwickert> nirik: for example 19:14:53 <mjg59> cwickert: I think that's the wrong expectation 19:14:57 <nirik> yeah, but if you are on a busy network with a bunch of port scans and junk it would be a bit nasty. 19:15:12 <mjg59> If I cannot use the network printer due to a restrictive firewall, then the firewall should just get out of the way rather than telling me why I can't see my printer 19:15:29 <nirik> yeah, the printer applet could/should just ask the firewall to change. 19:15:32 <cwickert> so you expect the firewall to know what you want? 19:15:56 * nirik expects the printer applet to know what it needs from the firewall. 19:15:58 <mjg59> cwickert: I think "I try to use my printer and something tells me that I'm potentially being attacked over the internet" is a poor user experience 19:16:37 <cwickert> mjg59: agreed, but this means the firewall is dump and firewalls only block attacks from the internet 19:16:52 <nirik> anyhow, where are we here. 19:16:59 <nirik> +1 I see 19:17:02 <cwickert> they do other things as well and it could be a meaningful info instead attack from the internet 19:17:04 <nirik> +3 rather 19:17:08 <mjg59> +1 from me 19:17:30 <cwickert> mjg59: for me the question is: (at least some people) want a tray icon. what alternative can GNOME provide that works across different desktops 19:17:35 <cwickert> +1 from me as wll 19:17:37 <cwickert> well 19:17:44 <mjg59> cwickert: I think for spins that want to focus on paranoia even when it conflicts with user desire, there's no problem in providing a tray icon 19:17:44 <dgilmore> it should be able to detect if its the same network or not 19:18:10 * nirik waits for one more vote at least 19:18:10 <mjg59> Whereas I'd really hope that any development on the desktop spin is aimed at doing this automatically, even if there's some perceived security cost 19:18:26 <mjg59> The important thing here is the backend 19:18:32 <mjg59> The UI is a desktop integration issue 19:19:27 <notting> %post 19:19:29 <cwickert> ok, lets not discuss this, lets focus on the feature itself. more votes please? 19:19:35 <ajax> +1 19:19:50 <notting> ln -sf /sbin/halt /sbin/init <- your paranoia spin 19:20:02 <nirik> #agreed Feature is approved. 19:20:08 * cwickert needs to leave now 19:20:11 <nirik> #topic #537 F15Feature: Spice support for virt-manager - http://fedoraproject.org/wiki/Features/SpiceInVirtManager 19:20:11 <nirik> .fesco 537 19:20:12 <zodbot> nirik: #537 (F15Feature: Spice support for virt-manager - http://fedoraproject.org/wiki/Features/SpiceInVirtManager) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/537 19:20:17 <cwickert> +1 19:20:24 <mjg59> +1 19:20:29 <nirik> +1 here too. 19:20:29 <SMParrish_mobile> +1 19:20:37 <notting> +1 19:20:50 <nirik> cwickert: if you are back on later, I have some quick questions for you. ;) 19:20:55 <nirik> #agreed Feature is approved. 19:20:55 <ajax> +1 19:21:05 <nirik> #topic #535 F15Feature: ecryptfs in authconfig - http://fedoraproject.org/wiki/Features/EcryptfsAuthConfig 19:21:05 <nirik> .fesco 535 19:21:06 <zodbot> nirik: #535 (F15Feature: ecryptfs in authconfig - http://fedoraproject.org/wiki/Features/EcryptfsAuthConfig) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/535 19:21:45 <nirik> +1 from me. I know some folks who would like this functionality. 19:21:48 <notting> ecrpytfs? 19:22:14 <nirik> well, a local per user encrypted dir/store. 19:22:41 <SMParrish_mobile> I like it +1 19:22:50 <ajax> cute trick, +1 19:23:17 <notting> neat idea. wonder how well it will work long term 19:23:21 <notting> +1 in general 19:23:27 <nirik> ecryptfs has been in a while. 19:23:30 <notting> would be interesting to talk to the desktop folks about tying this in more broadly 19:23:47 <nirik> yeah. 19:24:01 <nirik> one more vote? ;) 19:24:10 <mjg59> +1 19:24:19 <nirik> #agreed Feature is approved. 19:24:21 <nirik> #topic #536 F15Feature: RPM 4.9 - http://fedoraproject.org/wiki/Features/RPM4.9 19:24:21 <nirik> .fesco 536 19:24:22 <zodbot> nirik: #536 (F15Feature: RPM 4.9 - http://fedoraproject.org/wiki/Features/RPM4.9) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/536 19:24:30 <ajax> oh my yes +1 19:24:40 <ajax> i want collections so badly 19:24:55 <nirik> +1 here. Land as soon as feasable. ;) 19:25:03 <mjg59> +1 19:25:18 <SMParrish_mobile> +1 19:25:31 <notting> +1 19:25:59 <nirik> #agreed Feature is approved. 19:26:10 <nirik> #topic Open Floor 19:26:21 <nirik> That brings us to almost 2 hours and open floor. ;) 19:26:28 <nirik> Any items for open floor from anyone? 19:27:28 * nirik listens to the crickets chirp. 19:27:39 <nirik> will close out the meeting in a few here if nothing comes up. 19:27:43 <nirik> Thanks for coming everyone! 19:28:20 <nirik> #endmeeting
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
