FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 12-15-2010, 06:28 PM
Kevin Fenzi
 
Default Summary/Minutes from today's FESCo meeting (2010-12-15)

===================================
#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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 01:33 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org