=================================== #fedora-meeting: FESCO (2010-12-15) =================================== Meeting started by nirik at 17:30:01 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-12-15/fesco.2010-12-15-17.30.log.html Meeting summary --------------- * init process (nirik, 17:30:02) * Holiday meetings (nirik, 17:33:23) * will try and meet next week (the 22nd) but will not meet the 29th. (nirik, 17:37:38) * LINK: https://fedorahosted.org/fesco/ticket/508 (nirik, 17:38:42) * #508 improve the general standard of packagers/maintainers in the distribution. (nirik, 17:38:47) * ACTION: notting to work on wiki additions (nirik, 17:40:36) * #515 Investigate a "features" repo for stable releases (nirik, 17:45:01) * LINK: https://fedorahosted.org/fesco/ticket/515 (nirik, 17:45:01) * No progress on this, will revisit next week. (nirik, 17:47:53) * #516 Updates policy adjustments/changes (nirik, 17:47:59) * LINK: https://fedorahosted.org/fesco/ticket/516 (nirik, 17:48:00) * LINK: http://fedoraproject.org/wiki/Updates_Lessons#2008-02-28_-_dbus_security_update_issue (nirik, 17:50:55) * idea 1 is declined at this time. (nirik, 17:55:19) * AGREED: no direct stable pushes for security at this time. (nirik, 17:56:15) * QA unwilling to commit to testing all security updates at this time, but is open to testing critpath and more down the road once more testing plans are in place (nirik, 18:02:50) * AGREED: one week timeout allowed for security updates even if they are critpath (nirik, 18:24:11) * #517 Updates Metrics (nirik, 18:24:28) * LINK: https://fedorahosted.org/fesco/ticket/517 (nirik, 18:24:28) * #518 Abrt (nirik, 18:34:25) * LINK: https://fedorahosted.org/fesco/ticket/518 (nirik, 18:34:25) * ACTION: will revisit in 2011 with roadmap or plans from abrt maintainers. (nirik, 18:40:06) * #521 Reconsider RemoveSUID feature (nirik, 18:40:55) * LINK: https://fedorahosted.org/fesco/ticket/521 (nirik, 18:40:56) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=648654 (nirik, 18:48:24) * ACTION: revisit in 2011. Will see progress of rpm and/or kernel to fix mock tmpfs issue. (nirik, 18:58:33) * LINK: https://fedorahosted.org/fesco/ticket/522 (nirik, 18:58:59) * #522 F15Feature: GCC46 - http://fedoraproject.org/wiki/Features/GCC46 (nirik, 18:59:04) * LINK: https://fedoraproject.org/wiki/Releases/15/Schedule (kylem, 19:04:07) * AGREED: Feature is approved. Rel-eng to decide on mass rebuild scheduling. (nirik, 19:11:53) * Feature owner should look at coordinating with mdomsch to do a out of band mass rebuild. (nirik, 19:12:11) * #523 F15Feature: XenPvopsDom0 - http://fedoraproject.org/wiki/Features/XenPvopsDom0 (nirik, 19:12:43) * LINK: https://fedorahosted.org/fesco/ticket/523 (nirik, 19:12:44) * AGREED: feature is approved. (nirik, 19:18:00) * FES tickets (nirik, 19:18:12) * LINK: https://fedorahosted.org/fedora-engineering-services/report/6 (nirik, 19:18:16) * looking for a FES wrangler. (nirik, 19:18:56) * FPC: #525: Ratifiation of FPC statement (nirik, 19:20:24) * LINK: https://fedorahosted.org/fesco/ticket/525 (nirik, 19:20:54) * AGREED: This statement is ratified/approved (nirik, 19:25:44) * Open Floor (nirik, 19:25:51) Meeting ended at 19:27:19 UTC. Action Items ------------ * notting to work on wiki additions * will revisit in 2011 with roadmap or plans from abrt maintainers. * revisit in 2011. Will see progress of rpm and/or kernel to fix mock tmpfs issue. Action Items, by person ----------------------- * notting * notting to work on wiki additions * **UNASSIGNED** * will revisit in 2011 with roadmap or plans from abrt maintainers. * revisit in 2011. Will see progress of rpm and/or kernel to fix mock tmpfs issue. People Present (lines said) --------------------------- * nirik (199) * ajax (62) * kylem (40) * cwickert (28) * notting (27) * dwalsh (23) * mmaslano (16) * mjg59 (16) * mclasen (12) * abadger1999 (11) * mclasen_ (10) * gholms (7) * tibbs (5) * zodbot (5) * jlaska (3) * sgrubb (1) * jsmith (1) * mdomsch (1) * eparis (1) * marca (1) * drago01 (1) * SMParrish (0) -- 17:30:01 <nirik> #startmeeting FESCO (2010-12-15) 17:30:01 <zodbot> Meeting started Wed Dec 15 17:30:01 2010 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:02 <nirik> #meetingname fesco 17:30:02 <nirik> #chair mclasen notting nirik SMParrish kylem ajax cwickert mjg59 mmaslano 17:30:02 <nirik> #topic init process 17:30:02 <zodbot> The meeting name has been set to 'fesco' 17:30:02 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 mmaslano nirik notting 17:31:12 <nirik> who all is around for meeting today? 17:31:12 * cwickert is here 17:31:20 * marca here 17:31:21 * notting is here 17:31:25 * mdomsch lurks 17:31:28 <ajax> come on party people, throw your hands in the air 17:31:33 * mmaslano once again here ;-) 17:32:27 <mjg59> Afternoon 17:32:41 * mclasen is here for a bit 17:33:15 <nirik> cool. Lets dive in then... 17:33:23 <nirik> #topic Holiday meetings 17:33:39 <nirik> Should we meet on the 22nd and 29th? 17:33:46 <nirik> or will most people be away on holiday? 17:34:08 <notting> i am not going to be around 17:34:11 <notting> (on either day) 17:34:11 <mmaslano> well, 22nd possible for me, 29th probably not. 17:34:32 * cwickert could do both 17:34:39 * mclasen is the same 22 yes, 29 no 17:34:55 * nirik could do either probibly. 17:35:07 <mjg59> I can do 22nd but not 29th 17:35:34 <cwickert> propsal: let's do 22nd but not 29th 17:35:35 <ajax> i'm out both days 17:35:43 <ajax> but feel free to meet without me 17:36:00 * nirik is +1 to 22nd and not 29th. 17:36:19 <ajax> (i feel a little silly voting) 17:36:26 <nirik> kylem: we are discussing meetings on the 22nd and 29th... 17:36:37 <ajax> yeah, you guys should all show up and do work even when i won't! 17:36:48 <nirik> how about we try and meet on the 22nd and see if we have quorum. ;) 17:36:58 <mmaslano> fine 17:37:00 <kylem> i've got no plans, so i can show up either or. 17:37:02 <nirik> ajax: we will just assign all the tasks to you. ;) 17:37:35 <ajax> that's the spirit 17:37:38 <nirik> #info will try and meet next week (the 22nd) but will not meet the 29th. 17:37:59 <nirik> anything else anyone would like to note about holidays? 17:38:17 <ajax> don't drive in ontario 17:38:21 * jsmith wishes everyone a joyous end-of-year! 17:38:38 <nirik> Thanks jsmith 17:38:41 <nirik> #508 improve the general standard of packagers/maintainers in the distribution. 17:38:42 <nirik> https://fedorahosted.org/fesco/ticket/508 17:38:47 <nirik> #topic #508 improve the general standard of packagers/maintainers in the distribution. 17:38:52 <kylem> haha. 17:39:01 <nirik> notting: did you have a chance to look at folding the stuff into the wiki page? 17:39:12 <notting> i have not yet. will get to it before next week's meeting. 17:39:37 <nirik> I didn't talk to FPC, but abadger1999 made some comments there that he at least thought these were outside of their mandate. 17:40:36 <nirik> #action notting to work on wiki additions 17:40:43 <abadger1999> yeah -- only two of the points seem to fall within FPC's purview with a stretch of my imagination. 17:41:13 <nirik> yeah. 17:41:43 <nirik> so, I think we should look at wiki changes and call that good. 17:41:51 <abadger1999> I can take those two to the FPC if you like but as noted i nthe ticket, I'd probably vote against them. 17:42:06 * abadger1999 likes that idea 17:42:19 * mclasen notes that _all_ the bullet points start with 'require them', not a single one starts with 'we offer them'... 17:42:40 <nirik> mclasen: yes, last week when we discussed it we rejected the idea that any of these are requires. 17:42:55 <nirik> instead they should be suggestions or ideas for maintainers to look at... 17:43:00 <mclasen> ok 17:43:55 <nirik> ie, I think it would be great to point people in the new package process or responsibilitys page to a way to write test plans for qa on their package. 17:44:22 <nirik> ok, anything further on this from anyone? or shall we move on? 17:45:01 <nirik> #topic #515 Investigate a "features" repo for stable releases 17:45:01 <nirik> https://fedorahosted.org/fesco/ticket/515 17:45:07 <nirik> cwickert: any news here? 17:47:00 <nirik> If not, we can move on... ;) 17:47:12 <kylem> heh. 17:47:29 <cwickert> nirik, sorry, nope 17:47:39 <nirik> ok, no worries. 17:47:53 <nirik> #info No progress on this, will revisit next week. 17:47:59 <nirik> #topic #516 Updates policy adjustments/changes 17:48:00 <nirik> https://fedorahosted.org/fesco/ticket/516 17:48:12 <nirik> ok, I posted some ideas on security updates from our updates container. 17:48:40 <nirik> so, shall we go over them one at a time? 17:48:47 <cwickert> yes please 17:48:55 <nirik> idea 1. allow security updates to go direct to stable. 17:49:02 <ajax> i like point 3. 17:49:13 <nirik> folks wanted this to reduce the amount of time until end users could get security updates. 17:49:30 <nirik> I don't like it, given how we have had broken security updates in the past. 17:49:34 <nirik> so, I am -1 to it. 17:49:38 <kylem> i'm fine with point #1, as long as we distinguish between 'security updates' and 'updates' 17:49:46 <mclasen> dunno, we already have a way to get updates out quickly: give them karma quickly... 17:49:46 <kylem> and LART the hell out of people who abuse it. 17:50:06 <mmaslano> could we add button for stable for security updates? 17:50:20 <nirik> there already is a distinction. 17:50:42 * nirik is reminded of the dbus update a while back. 17:50:55 <nirik> http://fedoraproject.org/wiki/Updates_Lessons#2008-02-28_-_dbus_security_update_issue 17:51:03 <kylem> sorry, i mean: an update which just patches a single hole, versus one which patches it by updating to a new version. 17:51:33 <nirik> yeah, there's no distinction on that... an update is 'security' or 'enhancement' or 'bugfix' or 'newpackage' 17:51:38 <kylem> right. 17:52:23 <nirik> so, votes? or more discussion? 17:52:24 <kylem> this is what most other distros do to short circuit their updates process, have two classes of update, obviously correct security fixes, and 'updates' 17:52:30 <kylem> (debian/ubuntu at least.) 17:53:08 <mclasen> but if it is an 'obviously correct security fix', it should be quick to verify and give karma... 17:53:12 <nirik> yeah, except things can go wrong even with 'obviously correct' 17:53:20 * abadger1999 not really a proponent of this one but I think the argument in favor would be -- we're weighing cost vs risk: We have the opportunity to mitigate the risk of bad updates like dbus to weigh against however many non-broken security updates are being held up waiting for testing 17:53:42 <mmaslano> but if you have embargoed CVE, you should push update immediately after embargo pass 17:53:47 <mjg59> We need infrastructure for testing 17:54:01 <cwickert> I'm fine with requiring testing, but then the question is: how can we make sure it get's tested? how can we cover all apps and Fedora versions? 17:54:07 <nirik> btw: 'bodhi -s testing -t security' will show all updates currently in testing that are security. 17:54:23 * notting is -1 on this as it stands; would prefer to find ways to get testing rather than merely bypassing the process. 17:54:43 * mclasen concurs 17:54:53 <mjg59> Yeah 17:54:55 <nirik> ok, so thats -3 currently 17:55:03 <cwickert> another -1 17:55:06 <mjg59> -1 to allowing direct pushes 17:55:19 <nirik> #info idea 1 is declined at this time. 17:55:22 <kylem> i'm +1 to #1. 17:55:33 <mmaslano> +1 to #1 17:55:37 <gholms> Not #agreed? 17:55:44 <nirik> sorry yeah. 17:55:46 * gholms shrugs 17:55:53 <nirik> so, thats -5 / + 2 ? 17:56:01 <kylem> (with the caveat of distinguishing security patches from 'security updates' possibly through involvement with the security team.) 17:56:15 <cwickert> we need to have proven testers to check for security updates on a daily base 17:56:15 <nirik> #agreed no direct stable pushes for security at this time. 17:56:30 <nirik> which brings us to idea 2: 17:56:34 <nirik> idea 2. ask QA to commit to testing security updates 17:56:41 <nirik> I talked with adamw and jlaska the other day on this. 17:57:15 <nirik> Basically they are not willing to commit to something until they know what they are commiting to. ;) Ie, unless theres some kind of test plan or security testing process in place. 17:57:35 <nirik> they are much more willing to look at the subset of security updates that is also critpath since they are focusing on critpath. 17:57:53 <mclasen> cwickert: yeah, something of that sort; of course it takes some persistence to grow a culture like that 17:59:17 <nirik> so, while I have asked, I don't think we can get QA to commit to test all security updates at this time. 17:59:34 <cwickert> well, then I need to revert my vote 18:00:15 <nirik> cwickert: on the first idea? note the 3rd one coming up... ;) 18:00:19 * abadger1999 notes if QA is willing to committo testing critpath security updates, that does help with a portion of the problem. 18:00:33 <nirik> abadger1999: right. 18:01:05 <mmaslano> question is if they will be testing also on F-13 18:01:15 * mmaslano see there openssl (6 days) 18:01:25 <nirik> we could also help them by setting up/writing a base security testing plan. 18:01:42 <nirik> ie, check CVE's, run any proof of concept utils, etc. 18:02:50 <ajax> the thing is, i'd expect security updates to come with test instructions to begin with 18:02:50 <nirik> #info QA unwilling to commit to testing all security updates at this time, but is open to testing critpath and more down the road once more testing plans are in place 18:02:57 <nirik> ajax: yeah, ideally. 18:03:02 <ajax> maybe that's just my rhel experience speaking 18:03:13 <gholms> Where can maintainers put them? 18:03:19 <jlaska> ajax: you're right, they often do 18:03:39 <nirik> gholms: QA is working on a test plan space in the wiki. 18:03:40 <jlaska> gholms: that's the part of the puzzle we are addressing now ... where and how to document test procedures/cases 18:03:47 <nirik> for now, in the update info/bug ? 18:04:09 <mclasen> if there is a CVS, there should be some description of how to reproduce the problem, at least 18:04:37 <nirik> for example, I had a fontforge one recently... https://admin.fedoraproject.org/updates/fontforge-20100501-5.fc14 18:04:48 <nirik> I pointed to the bug, which had a proof of concept attached. 18:05:25 <nirik> so, should we move on to idea 3? or jlaska: anything to add or correct from my paraphrasing? 18:06:09 <jlaska> nirik: nothing from me, thank you 18:06:17 <gholms> Nothing to vote on? 18:06:42 <nirik> gholms: well, I already asked qa here... not sure we can vote on anything more... 18:06:48 <kylem> i'm +1 to #2 as an independent entity, it seems like a generally good idea to come up with the plan, and have some kind of security sig for QA. 18:06:57 <nirik> idea 3. allow timeout for security updates before going to stable. 18:07:24 <ajax> given that we're under-tested i think #3 is the best we can do 18:07:39 <nirik> thats another thing to note here... we basically depend on the rhel security folks filing the bugs when they notice them, but we don't really have a security sig. 18:07:59 <ajax> though we should probably have a figure-of-merit metric for how long security updates sit and how many simply hit the timeout 18:08:00 <kylem> nirik, yeah, i was going to motivate abit about that in #1, but we should move on and talk about it later or something. 18:08:08 <nirik> note that this idea 3 means critical path security updates (because normal package updates already have a timeout) 18:08:19 <cwickert> what kind of timeout? 18:08:39 <kylem> idea #3 is a pretty fair idea. 18:08:42 <nirik> 1 week. 18:08:56 <mmaslano> that could be too long for some updates 18:08:57 <nirik> so, if we allowed this would it be just for security updates? or all critical path? 18:09:03 <kylem> i like the idea of 'short timeout if there's no negative karma' or something. 18:09:25 <mmaslano> kylem: good point 18:09:34 <cwickert> this means a security update sits in testing for a week and does not get tested? what is the benefit over allowing it a direct push then? it's not tested anyways 18:09:39 <notting> mmaslano: if it is too long, they should get testing... 18:09:41 <kylem> i mean, if nobody notices in two days, will they notice in a week? 18:09:48 <nirik> cwickert: we don't know if it's tested. 18:09:53 <mjg59> cwickert: The assumption in that case is that people have installed it and it didn't break 18:10:06 <mjg59> Or, alternatively, that nobody runs the software anyway, so who cares? 18:10:11 <nirik> some people only report -karma. 18:10:24 <cwickert> mjg59, I don't thing this assumption holds true 18:10:35 <mmaslano> notting: like security updates in F-13 now? 18:11:00 <abadger1999> kylem: That could segue into an additional idea: shorter timeout for security updates that are non-critpath. 18:11:13 <kylem> abadger1999, indeed 18:11:17 * nirik notes again there are lots of knobs. 18:11:19 <cwickert> I can give you examples of updates that I don't expect to get any testing and I'm not sure somebody installs them ether - even though they are security updates 18:11:43 <nirik> personally I am -1 for this idea. I'd like to see us try and drum up more testing for these updates. 18:12:30 <cwickert> nirik, but how can we *make* *sure* they get tested? I cannot decide on something if I'm not sure 18:12:36 <ajax> i suppose it's fair to say that "item 3 is the best we can do" isn't necessarily an endorsement. 18:13:19 <nirik> cwickert: how can we be sure they won't break something going to stable? it's an unsure world. ;) 18:13:39 <nirik> Perhaps another idea might be some kind of karma exchange if we can get maintainers interested. 18:13:42 <cwickert> there is at least one person who should test them - the submitter 18:13:58 <nirik> "I will test your update if you test mine" 18:14:59 <nirik> or perhaps we could somehow rate the security issues and try and get a group to commit to test all the important ones? 18:15:06 <nirik> some of these are not really that big a deal. 18:15:37 <cwickert> for me the most important thing is that we must not have security problems. If QA is not willing to commit to security, we should trust the maintainers 18:15:59 <nirik> For example, the fontforge one was a overflow, but it fails to actually do anything on fedora due to FORTIFY_SOURCE 18:16:19 <ajax> CVE does have a category system for that already 18:16:20 <cwickert> then it shoud not be marked security, simple as that 18:16:37 <mclasen> nirik: in that case, no need for a security update ? 18:16:38 <abadger1999> cwickert: I'll note that, with security updates, that is ironically even less true than normal for old releases: it's a fix that obviously needs to be pushed back to the oldest affected release even if I have no boxes running the old release to test on personally. 18:17:02 <nirik> well, it does cause a crash of the application... which I suppose is anoying if you are working on something in it. 18:17:24 * gholms rings the 30-minute bell 18:17:46 <nirik> right. so, concrete proposals here? or vote on idea 3? 18:18:15 <ajax> +1 to idea 3 18:18:32 <ajax> not that i like it but that it's better 18:19:01 <kylem> heh, any chance the timeout could be scalable based on the 'importance' of the package, instead of boolean "critpath" "~critpath"? 18:19:04 <notting> is idea 3 fully formed? 18:19:05 <nirik> huh... you know. I don't think any of the current ones pending would be affected by this. 18:19:32 <notting> it says 'a timeout'. doesn't say what it is, or whether it applies to both critpath and not 18:19:44 <nirik> openssl I guess. 18:20:05 <nirik> notting: good point. Would a proponent of this idea care to phrase a more detailed thing? 18:20:42 <ajax> okay, fine. 18:20:48 <ajax> one week timeout, regardless of critpathness. 18:20:52 <kylem> i'm kind of divided on this, i think it's a good idea. but i think all 3 ideas are pretty independent... (there's no reason why we couldn't do all 3...) 18:20:56 <notting> ajax: for security? ok. 18:21:16 * notting notes looking over f13 updates, there are a lot of non-critpath stuff that *has* timed out that the maintainer hasn't bothered to push 18:21:34 <nirik> proposal: one week timeout allowed for security updates even if they are critpath ? 18:22:15 <mjg59> Yeah, ok 18:22:20 <kylem> +1. 18:22:23 * nirik doesn't know how many updates this would really end up affecting. 18:22:24 <mjg59> I don't like it, but we need some kind of fallback 18:22:29 <kylem> mjg59, agree. 18:22:43 <mmaslano> ok 18:23:00 <nirik> so, votes? I see +2? 18:23:05 <cwickert> notting, security? I only see one that could be pushed 18:23:11 <notting> +1. would like stats on how many updates hit this 18:23:19 <cwickert> +1 18:23:24 <ajax> +1 18:23:36 <nirik> -1 from me, as I'd prefer we find other ways to drum up testing on them. ;) 18:23:38 <kylem> notting, yeah, maybe we could get a summary of this after a few weeks and revisit it 18:23:51 <nirik> so, thats +5 / -1 and passes. 18:24:11 <nirik> #agreed one week timeout allowed for security updates even if they are critpath 18:24:17 <notting> cwickert: https://admin.fedoraproject.org/updates/wireshark-1.2.13-1.fc13, or https://admin.fedoraproject.org/updates/mailman-2.1.12-16.fc13. probably others 18:24:23 <nirik> speaking of metrics: 18:24:28 <nirik> #topic #517 Updates Metrics 18:24:28 <nirik> https://fedorahosted.org/fesco/ticket/517 18:24:41 <nirik> lmacken ran the bodhi updates stats for us. 18:25:02 <nirik> we need to look and see if these are the numbers we are looking for, or if there are some we would like to add 18:26:01 <nirik> would someone or someones be interested in taking the lead on this ticket and working with luke to improve the stats to where we would like them to be? 18:26:09 <kylem> sure, i'll do it. 18:26:10 <cwickert> notting, omg, you are right 18:26:35 <cwickert> I have a question on this 18:26:40 <nirik> kylem: cool. Will assign to you. 18:26:41 <nirik> :) 18:26:46 <kylem> *nod* 18:26:57 <cwickert> were the criteria already in place for the whole F13 lifetime? 18:27:06 <kylem> gives me a chance to review our criteria too. :) 18:27:20 <cwickert> I mean, if we are to see if there is a change, we need to compare F13 with F14 18:27:54 <cwickert> and do these statistics also include the time before release? 18:28:00 <nirik> yeah, I think they do. 18:28:06 <nirik> which would be nice to break out seperate. 18:28:24 <mmaslano> Do we have same rules in EPEL? 18:28:56 <nirik> mmaslano: similar. Except there it's 2 weeks in testing or karma for all updates, not just critpath. 18:29:12 <abadger1999> mmaslano: No critpath in EPEL and also 2 week timeout instead of 1. 18:29:13 <notting> nirik: i thought 2 weeks in testing was the only epel requirement? 18:30:07 <nirik> yeah... there is no critpath there... 18:30:38 <nirik> it would also be nice to see stats for the eol releases if the data still exists. 18:30:47 <notting> and the stats are obvs. different. 18:31:41 <nirik> yep. 18:31:53 * mclasen thinks that the accumulated stats are fairly useless; we need this broken down in say, months or 3 month periods, or somesuch 18:32:42 <nirik> yeah, that might be nice. 18:33:10 <nirik> any other ideas? or shall we add to ticket/ask kylem to work with luke on it and revist next week? 18:33:20 <kylem> noted. 18:34:11 <nirik> ok, will move on in a minute if nothing else... 18:34:25 <nirik> #topic #518 Abrt 18:34:25 <nirik> https://fedorahosted.org/fesco/ticket/518 18:34:42 <nirik> ajax: you care to introduce this? 18:35:00 <ajax> i'm actually pretty happy with the wishlist handling from the list 18:35:13 <kylem> i'm going to run out and grab and sandwich from the cafeteria, shoudl only be gone the length of this ticket. i'm pretty happy with the results of the discussion on devel- though. 18:35:26 <kylem> (sorry, i've not eaten since dinner yesterday...) 18:35:35 <nirik> yeah, the abrt maintainers have been pretty responsive to ideas I think. 18:35:47 <nirik> there sure are a lot of abrt bugs tho. ;( 18:36:39 <ajax> i think we should ask them for a status update sometime after the holiday break 18:36:47 <nirik> so, what action(s) should we take here? just close and let abrt maintainers handle wishlist items? or do we wish to ask them to entertain specific ideas/changes? 18:36:50 <ajax> to at least get an idea of roadmapping order 18:37:03 * nirik nods. Sounds good to me. 18:37:13 * notting is fine with waiting too 18:37:20 <mmaslano> ok 18:39:30 <ajax> so, i'll do that 18:39:35 <nirik> ok, sounds good. 18:39:37 <ajax> and i think that's all i've got for this one for now 18:39:48 <nirik> lets leave the ticket for now and revisit in jan. 18:40:04 <cwickert> first milstone on the roadmap should be to make ABRT actually work (TM) 18:40:06 <nirik> #action will revisit in 2011 with roadmap or plans from abrt maintainers. 18:40:29 <cwickert> e.g proper duplicate detection 18:40:35 <nirik> cwickert: it's been getting better... but sure, it needs more help with dups, etc. 18:40:55 <nirik> #topic #521 Reconsider RemoveSUID feature 18:40:56 <nirik> https://fedorahosted.org/fesco/ticket/521 18:41:13 <nirik> This feature has caused some issues for users of tmpfs. ;( 18:41:34 * mclasen dwalsh just ran out of my cube... 18:41:44 <nirik> ah. 18:41:59 <notting> "modify the feature to only allow caps in packages that are not themselves BuildRequires of anything else" is a tricky metric to follow 18:42:14 <ajax> notting: tbf i'm not entirely sure it would work anyway 18:42:18 <notting> since it's not just a BR, but anything that's required by some other random BR 18:42:39 <ajax> depends whether rpm stores caps in the filesystem or injects them into the cpioball itself 18:42:50 <ajax> (when constructing a binary package with cap'd files) 18:43:00 <nirik> dwalsh: welcome. 18:43:09 <nirik> we are looking at https://fedorahosted.org/fesco/ticket/521 18:43:23 <ajax> and of course, i still have all my original issues with capabilities 18:43:28 <nirik> the removesuid has caused some issues for folks using tmpfs (which seems to be a lot of people doing builds) 18:43:29 <dwalsh> I asked sgrubb to join also. 18:43:33 <nirik> cool. 18:43:46 <dwalsh> Yes I believe we need to fix this in RPM. 18:43:54 <dwalsh> RPM Should warn and not fail. 18:44:00 <dwalsh> Then not set the flags. 18:44:08 <nirik> but then won't things fail to work? 18:44:26 <dwalsh> Not in the use case people are complaining about. 18:44:48 <dwalsh> If a file system does not support file capabilities and you install an rpm into it, it can do one of three things. 18:45:02 <dwalsh> Fail, Install without file capabilities, or install setuid. 18:45:11 <dwalsh> Fail is causing mock builds to fail. 18:45:40 <nirik> suid would need package changes right? if they have switched to caps the rpm has no more info on what should be suid? 18:45:41 <dwalsh> Install without file capabilities will cause the app to fail when run from a user account, or to work differently. 18:46:02 <dwalsh> Yes, that is why I like obtion 2. 18:46:11 <dwalsh> Install, warn and no capabilities. 18:46:21 <mjg59> dwalsh: But... what if those capabilities are needed as part of the build? 18:46:35 <ajax> mjg59: i have trouble thinking of a case for that 18:46:36 <dwalsh> Builds tend to happen as root. I believe 18:46:37 * cwickert needs to leave now 18:46:43 <cwickert> bbl 18:46:52 * nirik assumes odds of adding capabilities support to tmpfs are less than adding patch to rpm. 18:46:57 <dwalsh> So you would have all capabilities. 18:47:03 <mjg59> nirik: That seems to be difficult for various reasons 18:47:03 <nirik> dwalsh: nope. they run as mockbuild user in the chroot. 18:47:19 <mclasen_> dwalsh: is fixing rpm part of the feature ? 18:47:30 <dwalsh> We have a bug report open on it. 18:47:51 <ajax> so here's a different kind of question 18:48:15 <mjg59> Treating it as a warning rather than an error seems like the safest option, but I worry that we'll find something that does depend on capabilities 18:48:18 <ajax> of the suid-root apps in the world that we want to convert to caps, how many of them are going to end up needing cap_sys_admin? 18:48:24 <nirik> https://bugzilla.redhat.com/show_bug.cgi?id=648654 18:48:29 <ajax> because, seriously: 18:48:29 <ajax> ~/linux-2.6% grep CAP_SYS_ADMIN **/*.[ch] | wc -l 18:48:30 <ajax> 439 18:48:38 <ajax> that may as well just be "root" 18:49:14 <dwalsh> Most do not require CAP_SYS_ADMIN and work is going on to break apart cap_sysadm now. 18:49:22 <dwalsh> CAP_SYSLOG has just been added. 18:50:23 <mclasen_> isn't syslog open for all ? 18:50:28 * mclasen_ always thought it was 18:50:36 <dwalsh> I think this is the ability to act like syslog. 18:50:41 <dwalsh> The server. 18:50:51 <sgrubb> I think it goes with the new dmesg sysctl 18:51:34 <nirik> so, where do we go here? give some time to see if rpm can work around the issue? 18:51:51 <eparis> there is a new kernel config to make dmesg non-readable by non-CAP_SYS_ADMIN. clearing dmesg used to be CAP_SYS_ADMIN but is now CAP_SYSLOG.... 18:51:52 <ajax> i'm fine with that for now 18:51:56 <dwalsh> I think we need to ping Panu about this 18:51:56 <mclasen_> should we roll back until rpm is ready ? 18:52:04 <kylem> back 18:52:32 <dwalsh> What packages are causing the problem. policycoreutils? And one other correct? 18:52:32 <ajax> i'd like to get an audit of which rpms have been cap'd and what that mitigates, so we have a better idea of what we're winning 18:52:48 <nirik> yeah, a list of done/tobedone might be nice. 18:53:04 <ajax> uh, one of the networking ones iirc? 18:53:06 <dwalsh> If you look at the buglist you can see 18:53:32 <dwalsh> newrole, seunshare, ping, Xorg, 18:54:34 <nirik> tracker bug: https://bugzilla.redhat.com/show_bug.cgi?id=646440 18:55:30 <nirik> ok, how about we revisit in 2011, and dwalsh can try and get rpm to have some workaround for the mock thing? 18:55:45 <dwalsh> eparis, Please comment on making tmpfs support File capabilitiies. 18:55:50 <ajax> wfm. just wanted to make sure we got a little more discussion going. 18:56:24 <kylem> dwalsh, i've got a WiP patch to do that 18:56:32 <kylem> will be posting it to lkml later today 18:56:55 <nirik> kylem: coolness. Is that likely to get in in time for f15? 18:57:16 <kylem> nirik, upstream? probably not. but if it's in tip or next or whatever i'll just pull it in 18:57:24 <nirik> ok. 18:57:52 <kylem> pays the cost to be the boss. ;-) 18:58:33 <nirik> #action revisit in 2011. Will see progress of rpm and/or kernel to fix mock tmpfs issue. 18:58:44 <nirik> thanks dwalsh / sgrubb / eparis 18:58:57 <nirik> ok, 2 features: 18:58:59 <nirik> #522 F15Feature: GCC46 - http://fedoraproject.org/wiki/Features/GCC46 18:58:59 <nirik> https://fedorahosted.org/fesco/ticket/522 18:59:04 <nirik> #topic #522 F15Feature: GCC46 - http://fedoraproject.org/wiki/Features/GCC46 18:59:32 <notting> this feels like it's landing awfully late in our release cycle 18:59:37 <nirik> yeah. 18:59:43 <nirik> and the mass rebuild seems very early. 18:59:51 <kylem> worried there's going to be another rebuild-forcing bug in gcc.... :( 19:00:03 <ajax> boy i wish gcc.gnu.org would load 19:00:19 <drago01> (it does here) 19:00:33 <nirik> they are proposing the mass rebuild before it's really even in bugfix only mode, which seems like a bad idea. 19:00:40 <ajax> there we go 19:00:55 <kylem> nirik, indeed 19:00:59 <nirik> also, we don't know if there will be other features requiring a mass rebuild yet. 19:01:39 <nirik> so, I would say: +1 to feature, with the change to mass rebuild to be 'scheduled as rel-eng would prefer' and probibly NOT over the holidays. 19:01:57 <abadger1999> "GCC 4.6.0 is going to be released in early to mid April, is currently in bugfix only mode and is going to switch into regression bug fix mode at start of January." 19:02:15 * nirik guesses he misread that. 19:02:22 <kylem> nirik, +1 to that. 19:02:28 <mmaslano> +1 19:02:39 <ajax> ooh, -fstack-usage 19:03:57 <ajax> where's our schedule again... 19:04:07 <kylem> https://fedoraproject.org/wiki/Releases/15/Schedule 19:04:18 <nirik> notting had a question on the talk page as well. 19:04:27 <nirik> "Is LTO a viable option to use at this point?" 19:04:58 <ajax> i think the answer is probably along the lines of "if the maintainer wants to keep both pieces" 19:05:34 <nirik> so, other votes? thoughts? 19:05:45 <gholms> LTO? 19:05:56 <ajax> gholms: link-time optimization. google has more detail. 19:06:00 <gholms> Ah 19:06:28 <ajax> if this lands before the holidays and the mass rebuild happens ~week1 then i suspect we'll probably have enough time to recover 19:06:30 <notting> i really don't like where it hits our schedule. especially if the gcc release slips 19:06:54 <ajax> oh, other question: do i get a gcc-go compiler? 19:07:33 <notting> according to the feature page, yes 19:07:39 <nirik> yeah. I think so 19:07:42 * mclasen_ is +1 19:07:48 <ajax> oh, there it is. 19:08:14 <nirik> so, thats +4 with the proviso that rel-eng schedules the mass rebuild. 19:08:43 <ajax> i don't see any major abi or api issues in the 4.6 changelist 19:08:53 <mjg59> +1 19:09:06 <ajax> so i think i'm leaning +1 with the releng proviso 19:09:19 * notting is -1 due to the schedule. it's not like we have a viable fallback if it explodes in early april 19:09:54 <nirik> notting: you seeing a repeat of the gcc-296 thing? 19:10:02 <nirik> (or whatever version that was) 19:10:08 <ajax> notting: mass offline rebuild first? 19:10:25 <notting> nirik: i suspect the gcc upstream isn't so picky at this point 19:10:39 <notting> perhaps i'm paranoid 19:10:45 <notting> ajax: that seems like a good idea regardless 19:10:52 <tibbs> Why do we have to mass rebuild? 19:11:02 * mmaslano must leave now, already voted in next ticket 19:11:10 <ajax> tibbs: strictly, no real reason 19:11:14 <mclasen_> if we don't, the risk of running into trouble late is bigger 19:11:25 <ajax> just the usual wipe-your-ass reasons to do with build deps and ftbfs 19:11:53 <nirik> #agreed Feature is approved. Rel-eng to decide on mass rebuild scheduling. 19:12:11 <nirik> #info Feature owner should look at coordinating with mdomsch to do a out of band mass rebuild. 19:12:43 <nirik> #topic #523 F15Feature: XenPvopsDom0 - http://fedoraproject.org/wiki/Features/XenPvopsDom0 19:12:44 <nirik> https://fedorahosted.org/fesco/ticket/523 19:12:53 <nirik> our old friend xen. ;) 19:13:00 <ajax> not dead yet 19:13:31 <nirik> strangely. 19:13:55 <notting> are all those people really working on it? 19:13:55 <nirik> anyhow, it's unclear to me how much of this is 'it's upstream now, we should build with it' and 'it needs a bunch of non upstream patches' 19:15:09 <ajax> yeah, reading. 19:15:15 <nirik> ah, info in the contingency plan 19:16:17 <ajax> seems like they've at least covered the bases 19:16:38 <ajax> approve and make sure it gets pulled from the feature list if it misses the deadline? 19:16:45 <kylem> +1. 19:16:49 <mjg59> Yeah 19:16:50 <mjg59> +1 19:16:55 <nirik> so sounds like they want to try and work on the grubby/anaconda/etc bits now, and wait until the kernel is ready for it to really go live. 19:16:56 <kylem> but yeah, it's all contingent on it getting upstream for .38 19:17:16 <ajax> +1 19:17:31 <mclasen_> +1 19:17:39 <notting> i still don't see what the *point* of working on this is, but ... *shrug* +1 19:17:51 <nirik> I guess I'm +1... we should be sure to pull it as soon as it is known not to make the right kernel tho... so it doesn't go out to press as being there when it's not. 19:18:00 <nirik> #agreed feature is approved. 19:18:12 <nirik> #topic FES tickets 19:18:16 <nirik> https://fedorahosted.org/fedora-engineering-services/report/6 19:18:26 <nirik> we haven't looked at these in a while... but they are still around. ;) 19:18:47 <nirik> mmcgrath has moved on to some place in the cloud, so we also need to find someone interested in help wrangling requests. 19:18:56 <nirik> #info looking for a FES wrangler. 19:19:05 <nirik> I poked some of the tickets the other day... 19:19:23 <nirik> as always, if someone can think of good things for this, feel free to file them or talk to me. 19:19:47 <nirik> #topic Open Floor 19:19:54 <nirik> Oh, wait. 19:19:57 <nirik> #undo 19:19:57 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x1e18d210> 19:20:24 <nirik> #topic FPC: #525: Ratifiation of FPC statement 19:20:32 <nirik> I know this was not on the agenda... 19:20:43 <tibbs> Positioning of the meetings makes this difficult. 19:20:45 <nirik> but it's a bit time sensitive, so if folks would be willing to look now. 19:20:54 <nirik> https://fedorahosted.org/fesco/ticket/525 19:21:24 <nirik> Basically the FPC is looking at the new systemd /var/run bugs. They would like to clarify the action maintainers should take on them. 19:21:49 <ajax> sounds right to me, to the extent that we abolish older inits 19:22:09 <tibbs> It's not really related to init. 19:22:37 <nirik> I'm +1 to this. We might want to add to that "If you are in doubt, wait for further guidelines or ask for clarification on the mailing lists before taking action" ? 19:22:39 <mclasen_> of course, the additional tempfiles.d configuration being 'not specified yet' makes it a bit difficult for packagers to act on this, no ? 19:22:50 <ajax> tibbs: yeah, true. 19:22:57 <abadger1999> mclasen_: It's rather putting a stop to packagers doing the wrong thing. 19:23:04 <tibbs> Indeed, but the problem is that lennart filed piles of bugs asking people to do things. 19:23:20 <nirik> I'd like to ask again for a "Mass bug filing SOP". ;) 19:23:21 <abadger1999> mclasen_: ie: if packagers are %ghosting directories now, that all has to be reverted later. 19:23:22 <mclasen_> oh, I see 19:23:22 <tibbs> I asked him not do to so; he did it anyway but his advice wasn't well considered. 19:24:01 <mclasen_> +1 from me then 19:24:14 <ajax> +1 19:24:23 <kylem> +1. 19:24:49 <notting> +1 19:25:26 <mjg59> +1 19:25:44 <nirik> #agreed This statement is ratified/approved 19:25:51 <nirik> #topic Open Floor 19:25:59 <nirik> Anyone have any items for open floor? 19:26:06 <ajax> not i 19:26:12 * nirik has not. 19:27:13 <nirik> ok, thanks for coming everyone! 19:27:19 <nirik> #endmeeting
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
