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