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