18:02:28 <abadger1999> #startmeeting FESCO (2013-12-18)
18:02:28 <zodbot> Meeting started Wed Dec 18 18:02:28 2013 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:28 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:02:30 <abadger1999> #meetingname fesco
18:02:30 <zodbot> The meeting name has been set to 'fesco'
18:02:31 <abadger1999> #chair abadger1999 mattdm mitr mmaslano notting nirik pjones t8m sgallagh
18:02:32 <zodbot> Current chairs: abadger1999 mattdm mitr mmaslano nirik notting pjones sgallagh t8m
18:02:33 <abadger1999> #topic init process
18:02:36 <sgallagh> nirik: Is that what's happening?
18:02:41 <nirik> sgallagh: usually.
18:02:41 <sgallagh> .hellomynameis sgallagh
18:02:43 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
18:02:47 <nirik> .hellomynameis kevin
18:02:50 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com>
18:02:53 * pjones is here, but also in the middle of his previous meeting of today.
18:02:57 <t8m> hi
18:03:24 * jreznik is listening but should leave soon, just needs resolution on eol process :)
18:03:43 <abadger1999> Cool.  So we have quorum despite the netsplit.
18:03:52 * t8m will have to leave soon as well
18:04:02 * notting is here
18:04:15 <mattdm> me is in real-life meeting and also starving to death
18:04:21 * mattdm ^
18:04:30 <pjones> yay, my other meeting ended.
18:04:33 <nirik> mattdm: real life "hunger games" ? :)
18:04:48 * abadger1999 scrambles to get the EOL ticket u[
18:05:11 <jreznik> well, I'm playing my personal hunger games too then! :)
18:05:23 <mattdm> I couldn't find the examples of users who couldn't reopen but I swear I saw it in person at LISA.
18:05:43 <mattdm> maybe that user had a particular problem -- I'm getting in contact with him.
18:05:56 <mattdm> In the meantime it is the case that non-reporters can't reopen.
18:05:59 <abadger1999> #topic  1198 Possible changes to Fedora EOL bug procedure
18:06:03 <abadger1999> .fesco 1198
18:06:04 <zodbot> abadger1999: #1198 (Possible changes to Fedora EOL bug procedure) – FESCo - https://fedorahosted.org/fesco/ticket/1198
18:06:35 <nirik> so, we don't actually need to change the message that goes out now, do we? just the final one with closing?
18:06:37 <nirik> or do we?
18:06:54 <jreznik> the reason why I brought it on fesco agenda today is, that we need eol warning asap
18:07:10 <mattdm> I would like it to say something about "if you are not the original reporter but are having this problem in a newer release, do [...]"
18:07:11 <t8m> mattdm, the non-reporters can clone
18:07:26 <mattdm> t8m no that's removed.
18:07:34 <jreznik> nirik: yes, for now but unless you want to do bigger changes - so I'd like to know we continue with the smae process
18:08:01 * nirik notes QA folks wanted to provide input, but don't seem to have done so yet... not sure if any of them are around.
18:08:01 <mattdm> If [...] is "e-mail mattdm and complain" I'm okay with that as an interim solution :)
18:08:16 <jreznik> t8m: that was previous message but I got a lot of complaints about clones that we decided to change it to reopen
18:08:31 <jreznik> mattdm: deal :)
18:08:47 <nirik> well, what do we need to change in the warning.
18:08:56 <nirik> the warning doesn't close anything.
18:09:03 <mattdm> yeah I think nothing for now.
18:09:06 <jreznik> nirik: in warning nothing
18:09:16 <jreznik> but I want to check with you, if the process stay same or not
18:09:22 <nirik> ah, ok.
18:09:28 <t8m> ok then just "note that in the bug and cc ... who can reopen"?
18:09:29 <jreznik> aka one month after release etc.
18:09:55 <abadger1999> mattdm: cloning is possible, though?  it's just been removed from the wording?
18:09:57 <nirik> I'm +1 for following the same process. Is there some other process proposed?
18:10:16 <nirik> I guess it could tie into the fedora.next stuff if we don't release a f21 on the same schedule...
18:10:33 * abadger1999 would be okay with wording that says "reopen or clone if reopening doesn't work for you"
18:10:35 <jreznik> as it was discussed too but as we are under time pressure, at least for f18 eol, I'd say stick with same process, just rephrase that wording for closure
18:10:47 <mattdm> jreznik +1
18:10:48 <jwb> please no clone
18:10:59 <jreznik> abadger1999: a lot of devels have that problem with clone, that's the only reason why it was changes...
18:11:12 <jreznik> jwb was one of them :)
18:11:13 <abadger1999> jwb: well -- if reopening does not work... what's the best option available?
18:11:17 <mattdm> cloning is off
18:11:19 <jwb> fixing reopen
18:11:39 <jwb> cloning wastes everyones time.  it's faster to just open a new bug
18:11:39 <nirik> proposal: send warning now, gather more info and revisit before sending close/closing.
18:11:40 <abadger1999> "open a fesco ticket to have the maintainer to reopen" ?
18:12:36 <jreznik> nirik: I'm ok with that, I just wanted to be sure we are not going to do any bigger changes to the process
18:12:45 <t8m> nirik, +1
18:12:50 * mattdm will be afk for a little bit
18:12:55 <abadger1999> jreznik: I don't believe we want any big change to the process.
18:13:08 <abadger1999> Really, we are in agreement with jwb that we just want reopening to work.
18:13:19 <nirik> I'd like to make sure we can confirm reopen works or what to tell people in the closing... but yeah, I don't know that I want any big changes at this point
18:13:23 <abadger1999> it's just that we don't know if it does.
18:13:29 <nirik> right. need more info
18:14:02 <abadger1999> nirik: +1
18:14:39 <abadger1999> and I guess we just keep mattdm on the hot seat to check whether reopening works until  the closing comes up.
18:15:30 <abadger1999> So -- who's in favor of nirik's proposal (basically, defer until mattdm verifies that reopening is fixed or it's time to actually close the bugs)
18:15:48 <nirik> +1 my own proposal
18:15:51 <abadger1999> +1
18:15:57 <77CAAU64F> +1
18:16:05 * 77CAAU64F blinks
18:16:17 <sgallagh> Ok, guess the netsplit ended...
18:16:19 * nirik also welcomes other plans or input from QA or anyone interested.
18:16:23 <sgallagh> Sorry, that was my +1
18:16:39 <t8m> nirik/abadger, +1
18:16:47 <abadger1999> We're at +4
18:16:49 * jreznik will try to follow up with mattdm, qa and other interested folks :)
18:16:59 <notting> i'm +1 to that
18:17:01 <pjones> +1
18:17:11 <nirik> jreznik: thanks!
18:17:29 <abadger1999> #info send warning now, gather more info and revisit before sending close/closing. Passed (+1: 6, 0:0, -1:0)
18:17:46 <t8m> mattdm, ?
18:17:51 <abadger1999> #action mattdm to verify that reopening works before it's time to close the EOL bugs.
18:18:07 <jreznik> thanks guys, I have to run now
18:18:08 <abadger1999> #topic #1209 	please allow the assignee to remove private status
18:18:10 <abadger1999> .fesco 1209
18:18:11 <zodbot> abadger1999: #1209 (please allow the assignee to remove private status) – FESCo - https://fedorahosted.org/fesco/ticket/1209
18:18:15 <abadger1999> jreznik: thanks for coming
18:18:25 <t8m> pjones, ?
18:18:40 <pjones> hrm?
18:18:49 <pjones> I'm not sure what you're asking when all you say is "?"
18:19:19 <nirik> so, on this one...
18:19:20 <t8m> pjones, the netsplit made here a long lag
18:19:31 <pjones> okay.  you got that I voted +1 on the previous one, then?
18:19:57 <t8m> pjones, yes, but later than I sent the message
18:20:02 <nirik> proposal: ask bugzilla.redhat.com maintainers to allow assignees on private abrt bugs to unmark them private if they choose.
18:20:16 <pjones> nirik: +1
18:20:17 <nirik> I don't know if that means it would need to be a priv in fedorabugs, or could tie to the assignee
18:20:24 <nirik> but we can discuss that with them
18:20:29 <sgallagh> nirik: +1
18:20:39 <abadger1999> I'd be oka with either implementation.
18:20:42 <abadger1999> nirik: +1
18:20:44 <t8m> nirik, +1
18:20:49 <pjones> Since I can't imagine that any of them are clear on what private means or doesn't mean, and therefore they almost certainly don't mean for them to be private, they should be allowed to mark them not private.
18:20:54 <notting> nirik: +1
18:21:45 <nirik> pjones: abrt  does it when it sees something it considers 'private data' or 'exploitable'... but it's not really clear what that hueristic is to me at least
18:22:28 <abadger1999> nirik: You're voting +1 on your proposal?
18:22:37 <nirik> yep. sure.
18:22:40 <pjones> nirik: which has no real affect on how users understand it, either ;)
18:23:19 <abadger1999> #info ask bugzilla.redhat.com maintainers to allow assignees on private abrt bugs to unmark them private if they choose (implementation could be tied to assignee or a new privledge for fedorabugs)  Passed (+1:6, 0:0, -1:0)
18:23:30 <pjones> obviously the heuristic should be if pam_passwdqc says something from a tokenized "strings" output is a good password, it's private.
18:23:38 <nirik> who wants to file that bug? ;)
18:24:02 * sgallagh chuckles
18:24:20 <t8m> pjones, that would not work
18:24:32 <pjones> you don't say ;)
18:24:51 <nirik> I guess I can if no one else will.
18:25:06 <abadger1999> Maybe if you reverse the conditional.   Aren't easy strings more likely to be a password ? ;-)
18:25:15 <t8m> pjones, all random strings would be private then
18:25:17 <abadger1999> nirik: Thanks!
18:25:23 <t8m> abadger1999, exactly ;)
18:25:25 <pjones> t8m: yes, and all bugs about perl implementation ;)
18:25:44 <t8m> heh :D
18:25:51 <abadger1999> #action nirik to open the bug to have bugzilla maintainers look at adding this permission
18:26:12 <abadger1999> #topic #1132 	libtool + %global _hardened_build 1 = no full hardening
18:26:13 <abadger1999> .fesco 1132
18:26:14 <zodbot> abadger1999: #1132 (libtool + %global _hardened_build 1 = no full hardening) – FESCo - https://fedorahosted.org/fesco/ticket/1132
18:26:31 <nirik> this is now enabled in rawhide I think
18:26:32 <abadger1999> So we've opened up the F21 featureChange Process.  And this is something we defered to F21.
18:26:40 <abadger1999> Cool.  So we can just close this?
18:27:41 <sgallagh> nirik: Is it? Wasn't there a problem with pre-generated libtools too?
18:28:15 <nirik> oh...mistook this for another one, sorry.
18:28:24 <nirik> not sure the status here, I can look.
18:28:51 <abadger1999> Ah okay.
18:29:12 <abadger1999> nirik: Should we defer then and look at this at the next meeting?
18:29:29 <nirik> yeah, it looks like it's not progressed any... still disabled.
18:30:38 <sgallagh> nirik: This discussion stalled at a round-and-round about forcing libtoolize
18:31:13 <abadger1999> mitr mentions that a new %configure hack was discussed (that from conext seems like it might also do what we need with pre-generated libtool)
18:31:14 <t8m> I would not force libtoolize
18:31:23 <t8m> abadger1999, +1
18:31:25 <abadger1999> But I don't know since I haven't seen any of the code.
18:31:36 <abadger1999> Maybe we need to defer until mitr is here to fill us in?
18:31:39 <notting> would the new %configure hack just be forcing libtoolize?
18:32:25 * abadger1999 opens up libtool bz to see if the information is there.
18:32:39 <t8m> proposal: defer until we know what the new %configure hack is
18:33:12 <nirik> yeah, defer for more info, but we should try and drive it forward.
18:33:54 <t8m> nirik, sure
18:34:20 <t8m> nirik, someone should just ask praiskup and post the hack to the ticket
18:34:41 <nirik> t8m: that would be great... you want to? ;)
18:34:49 <t8m> nirik, OK
18:35:12 <t8m> #action t8m will ask praiskup about the new %configure hack
18:35:36 <nirik> thanks t8m!
18:35:45 <abadger1999> https://bugzilla.redhat.com/attachment.cgi?id=782186&action=diff
18:36:10 <abadger1999> I think that's the new configure hack (but there might be one that's even newer)
18:36:28 <abadger1999> If it is the hack, then it would not require re-libtoolizing.
18:36:46 <pjones> well, that certainly is a hack
18:36:47 <abadger1999> It runs sed on the ltmain.sh that's present in the builddir.
18:37:04 <abadger1999> yeah.  definitely.
18:37:21 <t8m> this one looks good
18:37:31 <t8m> I'd say we should try it
18:38:29 <nirik> I think there was a problem with that one, but I can't recall it anymore.
18:39:16 <abadger1999> k
18:39:23 <abadger1999> Alright I think we should defer.
18:39:54 <abadger1999> Proposal: defer so t8m/mitr can get some more information on the current status.
18:40:08 <notting> +1
18:40:19 <abadger1999> +1
18:40:24 <t8m> abadger1999, +1
18:40:39 <nirik> +1
18:40:39 <sgallagh> +1 defer
18:40:42 <abadger1999> t8m: Thanks for taking on the task of getting more info!
18:40:46 <pjones> +1
18:41:21 <abadger1999> #info Defer the libtool question until next meeting so we can get more information (+1:6, 0:0, -1:0)
18:41:31 <abadger1999> #topic #956    Need to audit packageset for bundling of libiberty
18:41:32 <abadger1999> .fesco 956
18:41:33 <zodbot> abadger1999: #956 (Need to audit packageset for bundling of libiberty) – FESCo - https://fedorahosted.org/fesco/ticket/956
18:41:44 <nirik> thanks for all the followup on this one abadger1999
18:42:26 <nirik> +1 for the proposed actions in comment 29
18:42:36 <abadger1999> I started n current state and made a proposal: https://fedorahosted.org/fesco/ticket/956#comment:29
18:42:50 <abadger1999> *started analyzing
18:43:19 <abadger1999> Since it's been 13 months, I hope many of those packages will be able to close the bugs as "already fixed".
18:43:39 <t8m> +1
18:43:56 <abadger1999> but we just can't know at this point since there's been few bugs and little tracking of what may or may not have been done.
18:43:59 <t8m> (to the proposed actions in comment 29)
18:44:09 <abadger1999> +1 to proposal
18:44:22 <notting> "Analyze your package's code to see if the _objalloc_alloc() function in libiberty/objalloc.c is vulnerable. If so, check whether your package compiles it in and uses the _objalloc_alloc() from libiberty. If so, you may further analyze the package code to see if invalid input can be passed to _objalloc_alloc() and if so, if that input can cause any problems for the application." <- some HOWTOs here would be nice
18:45:11 <abadger1999> <nod>  I don't know precisely how people have been analyzing all of that... My inclination would be to just patch objalloc.c and be done with it.
18:45:36 <pjones> abadger1999: I'm a bit concerned by the idea that asking again will result in action where asking the first time didn't...
18:45:37 <abadger1999> but gdb, for instance, appears to have actually done the analysis rather than patching.
18:46:19 <abadger1999> pjones: Part of the problem is we don't know who was asked.
18:46:23 <pjones> True.
18:46:51 <abadger1999> the 5 I mention as having bugs opened are the only ones I know for sure were asked.
18:47:04 <abadger1999> (of those, only monodebugger failed to act)
18:47:45 <abadger1999> notting: We could take that section out or make it the second option, perhaps?
18:48:42 <notting> well, i think teaching people how to find this stuff out is useful anyway, even if they just preemptively patch it
18:49:05 <notting> i don't think i'm going to have time before break to write some stuff to flesh that section out, though
18:49:40 <abadger1999> <nod>
18:50:23 <t8m> I'll have to leave now.
18:51:04 <abadger1999> notting: Does this look like it's the best advice: https://bugzilla.redhat.com/show_bug.cgi?id=849693#c30  (# yum install avr-gdb-debuginfo to the end of comment)?
18:51:46 <notting> that seems a reasonable check to see if it's linked in, yes
18:52:21 <notting> and we should be able to point people to the patch to determine whether they have an affected version
18:52:59 <abadger1999> <nod> I have a link to the patch at the end but I can make it more prominent.
18:53:27 * abadger1999 unfortunately doesn't havea link to the upstream patch either... will have to navigate viewcvs to figure that out.
18:53:37 * nirik shudders
18:54:37 <abadger1999> Cool.  Okay, I'll parrot what's in c30 and link to the upstream patch for the Analysis section and move analysis to the second option.
18:54:59 <abadger1999> anything else that would make people happier with this plan?
18:55:19 * nirik is fine with that. +1
18:56:24 * nirik wonders if we lost everyone
18:56:46 <abadger1999> We're at +3 if we continue to count t8m's vote.
18:57:01 <abadger1999> Would need both notting and pjones to vote +1 to pass this today.
18:57:31 * notting is +1 with the changes
18:57:46 <sgallagh> +1
18:58:30 <abadger1999> Cool.  That's +5
18:59:13 <abadger1999> #action abadger199 to modify the proposal to include what's in the bugzilla comment 30 and link to the upstream patch for the Analysis section and move analysis to the second option.
18:59:32 <nirik> abadger1999: are you able to file the bugs, etc too?
18:59:49 <abadger1999> #info With the modifications that abadger1999 will make, the poroposal is approved (+1:5, 0:0, -1:0)
19:00:01 <abadger1999> nirik: Yep, I'll tke care of bug filings and such as well.
19:00:08 <nirik> awesome. thank you.
19:00:19 <abadger1999> #action abadger1999 to take care of the bug filings and other followup as well
19:00:42 <abadger1999> #topic Next week's chair
19:00:51 <abadger1999> By next week we mean January 8th
19:00:54 <abadger1999> two weeks from now
19:00:55 <nirik> are we meeting next week? ah...
19:01:00 <abadger1999> And t8m volunteered to do this
19:01:12 <abadger1999> So that's settled.
19:01:30 <abadger1999> #info Next meeting Wed, January 8th.  t8m to chair
19:01:34 <abadger1999> #topic Open Floor
19:02:03 <nirik> Thanks to everyone who worked on Fedora 20. ;) Congrats on a good release.
19:02:04 <sgallagh> F20 is out! Hurrah!
19:02:23 <abadger1999> #info A round of applause for everyone who worked on fedora 20
19:02:46 <sgallagh> nirik: One perk to releasing right before the holiday break: you and the rest of infra and rel-eng get a well-timed respite.
19:03:23 <pjones> abadger1999: sorry about that, had to step away fro a second.  am +1 but I see it passed so no need to update the count.
19:03:32 <abadger1999> I went through all of our tickets this week and tried to close, add to meeting, ping, or mark that we would deal with it in January.
19:03:35 <nirik> sgallagh: hopefully. we have a pile of stuff queued by the freeze tho. ;)
19:04:01 <abadger1999> Hopefully t8m will be able to close out more of the ping'd tickets for the next meeting.
19:04:54 * abadger1999 notices that he somehow failed to add #1212.  Oops.
19:05:20 <abadger1999> We're at the hour mark... does anyone want to talk about: #1212 	Unresponsive package maintainer policy change proposal
19:05:33 <abadger1999> or should we wait until next meeting
19:05:47 <pjones> Keeping in mind that we probably shouldn't meet next week
19:06:15 <abadger1999> <nod>  Two weeks,  Wed, January 8th will be the next meeting
19:06:24 <nirik> .fesco 1212
19:06:26 <zodbot> nirik: #1212 (Unresponsive package maintainer policy change proposal) – FESCo - https://fedorahosted.org/fesco/ticket/1212
19:06:35 * nirik is lazy and gets the link
19:06:59 <nirik> so, yeah, I agree our current policy isn't ideal, but I think the proposal doesn't really help much.
19:07:16 <nirik> we could punt and hope to come up with a better proposal. ;)
19:07:28 <pjones> Eh, this proposal is really pretty problematic
19:08:30 <notting> yeah, not a huge fan of bug-on-one-package expanding to all automatically
19:08:34 <notting> it certainly can be an *option*
19:09:06 <pjones> nor on people other than the package maintainer creating a list of outstanding bugs that /must/ be fixed.
19:11:49 <notting> i would think a policy of 'maintainer declared inactive for package A -> expand potentially to all packages' works better
19:11:53 <nirik> so yeah... punt? or reject now? ;)
19:12:04 <sgallagh> I vote just reject
19:12:12 <sgallagh> Hope for a better proposal to come along
19:12:12 <abadger1999> notting: i think that's already covered by https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers#Notes_for_Mass_Orphaning
19:12:29 * abadger1999 trying to figure out what the changes being proposed actually are...
19:12:34 <nirik> The problem is that there's many cases that are not really the same thing...
19:12:53 <abadger1999> I guess it's (1) file bug against generic component instead of specific package
19:13:02 <nirik> maintainer thats just completely gone, one that doesn't care about your pet bug in package A, but it otherwise around and active, etc.
19:13:11 <abadger1999> (2) have all other bugs owned by that maintainer block that bug.
19:15:10 <nirik> I outlined some of the reasons I would be against that in ticket.
19:15:31 <abadger1999> mm.. and (3) by default, non-responsive maintainer is for all packages of the maintainer instead of as an optional second phase.
19:16:46 <notting> proposal: reject this change to the nonresponsive maintainer policy, although we would consider other changes.
19:16:58 <pjones> Proposal: Reject this for now, until there are signs that his one example is becoming a common problem, and ask him to come back asking for remedy for his specific problem on an individual basis.
19:17:22 <abadger1999> +1 to either of those
19:17:39 * notting can be +1 to pjones'  - that's better wording
19:17:44 <nirik> yeah, +1 pjones
19:17:51 <pjones> alright, then I'm +1 to mine as well.
19:18:10 <sgallagh> pjones: _1
19:18:13 <sgallagh> err +1
19:18:33 <mattdm> shows up. +1s that
19:18:50 <mattdm> (having read the scrollback and the ticket, ftr)
19:18:56 <abadger1999> #topic  #1212 (Unresponsive package maintainer policy change proposal) – FESCo - https://fedorahosted.org/fesco/ticket/1212
19:19:18 <abadger1999> #info Reject this for now, until there are signs that his one example is becoming a common problem, and ask him to come back asking for remedy for his specific problem on an individual basis. (+1:6, 0:0, -1:0)
19:19:28 <abadger1999> #topic Open Floor
19:19:50 <abadger1999> Okay, I'll close the meeting in 60s if there's nothing else.
19:20:51 <abadger1999> #endmeeting