16:57:54 #startmeeting Fedora Packaging Committee 16:57:54 Meeting started Wed Apr 3 16:57:54 2013 UTC. The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:57:54 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:57:57 #meetingname fpc 16:57:57 The meeting name has been set to 'fpc' 16:58:00 #topic Roll Call 16:58:04 * geppetto is here 16:58:05 Howdy. 16:59:34 limburgher, abadger1999, racor, Smoother1rOgZ: ping? 16:59:40 * abadger1999 here 16:59:43 * limburgher is here 17:00:03 okay, that makes exactly five of us 17:00:10 i'll give it a few more minutes before we start 17:00:31 * Smoother1rOgZ is around (in meeting at office) 17:02:07 #topic Listing .so names explicitly and fully in %files must be mandatory. - https://fedorahosted.org/fpc/ticket/266 17:02:55 Not much of a draft here, but the idea is that instead of %{_libdir}/libfoo.so.*, you'd have to have %{_libdir}/libfoo.so.8*, to make it more obvious to the packager when the shared object major version changes 17:03:10 Because the build woudl go boom. 17:03:34 Wouldn't make them announce it, but ok. 17:03:48 Honestly, I'm not a fan. I think this is something where we could write rules that listen for successful rawhide builds and compare them to the previous build. (same for pushes to updates-testing) 17:03:52 I assume this could affect a ginormous number of pacakges. 17:03:55 I'm not a fan either. 17:04:03 That would be better. 17:04:08 fedmsg and datanommer in theory let us do this. 17:04:26 "You have this nice mechanism that allows you to have compact file lists. Don't use it." 17:04:59 spot: Yeh, I agree this seems like a hack which would be much better done using some auto-QA/rpmdiff type thing 17:05:34 So I propose that I ask the Fedora Infrastructure folks working on fedmsg to figure out a way to detect this automatically and either send immediate notices out to devel@lists.fpo or rollup regular reports that would go there. 17:06:03 yeah, -1 to the proposal in ticket. Fine with asking infra if they would do that. 17:06:33 autoqa's rpmguard thing does this, but I don't know if it runs on rawhide at all... and I think it's opt in. 17:06:43 I see everyone -1 on the ticket, i'll mention that I'm opening a ticket for FI 17:06:46 spot: +1 17:06:50 * geppetto nods 17:06:52 on asking infra 17:08:50 Okay, moving on 17:08:59 #topic CVE numbers in RPM changelog - https://fedorahosted.org/fpc/ticket/267 17:10:24 * rdieter waves, sorry i'm late 17:10:24 I'm -1 … use "yum updateinfo" 17:10:40 This item is missing draft text, but it could be as simple as "If an update to your package resolves a known security concern with a Common Vulnerabilities and Exposures (CVE) number assigned to it, you should mention the CVE number in the RPM changelog entry." 17:10:44 eh, I like tracking CVEs but I don't think I like mandating what must be in the rpm changelogs. 17:11:11 fwiw, I'm in favor of ticket 266 in general, but seems I'm in the minority. been hit myself both others' not noticing soname bumps way too often 17:11:32 The other problem is that sometimes the CVE is assigned after the changelog is done, if we mandated this we'd need to rebuild rpms just to update the changelog. 17:11:51 And we'd need some process in place to make sure the changelog's were always correct wrt. having all the CVE data in them. 17:12:01 * rdieter agrees with geppetto , -1 17:12:07 geppetto: my wording makes it a "should", so that case wouldn't really apply. 17:12:08 -1 17:12:32 We could tweak it to be "If an update to your package resolves a known security concern (at the time of the update) with a Common Vulnerabilities and Exposures (CVE) number assigned to it, you should mention the CVE number in the RPM changelog entry." 17:12:37 spot: If anything I think should is worse … as it gives a false sense of having the complete list, but it's not guaranteed. 17:12:53 spot: i could go for that, that's no longer onerous 17:13:04 yeah, I'm not against a should... but I don't think a should will solve the ticket owner's use-case. 17:13:06 I don't think it is harmful for people to include CVE numbers in the changelog entries. 17:13:32 even if they only mention the ones they are aware of. 17:14:08 +1 to spot's revised wording (better than not mentioning it at all) 17:14:10 meh. … I'm 0 on should, I can see how it'd be nice … but I can see people thinking it will be canonical. 17:14:12 We should probably incorporate geppetto's suggestion that people use yum updateinfo to find a more accurate list of security fixes.... perhaps just in the ticket comment (not in the guideline) 17:14:45 Okay, just to get consistent voting, I propose: "If an update to your package resolves a known security concern (at the time of the update) with a Common Vulnerabilities and Exposures (CVE) number assigned to it, you should mention the CVE number in the RPM changelog entry." 17:15:01 +1 17:15:12 +1 17:15:17 +1 17:15:17 0 17:15:20 +1 17:15:20 +1 17:16:10 tibbs, if you'd like to vote on the record, feel free to chime in, we're at +5. 17:17:39 #action spot's draft text approved (+1:5, 0:1, -1:0) 17:18:03 #topic Static [UG]ID assignments in Packaging:UsersAndGroups - https://fedorahosted.org/fpc/ticket/269 17:18:11 draft is here: https://fedoraproject.org/wiki/User:Mitr/UsersAndGroups 17:19:27 This seems very well thought out, I'd only make one change to the draft: 17:19:30 Sorry, phone call. 17:19:48 +1 to the draft from four minutes ago. 17:20:11 * abadger1999 remembers this being a very tricky area 17:20:46 "To allocate a GID and/or UID, file a bug against the "setup" package, and request a static GID and/or UID. Once your allocation has been assigned and the setup bug ticket is closed, you may use the static uid/gid in your package. 17:21:02 Well, yeah, there's some history there where Red Hat folks had some internal registry of UIDs and their own procedure for dealing with them, and that crept into Fedora packages without anyone talking about it. 17:22:01 I'm happy with it … it seems like it'd be nice to have a link to create the BZ against setup. And I don't mind spot's addition to that paragraph. 17:22:05 But +1 17:22:18 geppetto: yeah, good idea, I can add that link 17:23:16 Personally I would prefer not to do any of the soft static allocation stuff at all (and keep the guideline we have currently), but kickstart still doesn't offer much of a mechanism for doing it and of course the aforementioned folks have been doing their own thing for years now. 17:24:05 fwiw, the author of this draft is part of the RH team who has been "doing their own thing" 17:24:12 Yes, I know. 17:24:18 so i think having them propose codifying it in this way is preferrable. 17:24:30 So at least people know what's what. 17:24:40 who's the gatekeeper here? The owner of the setup package? 17:24:44 .whoowns setup 17:24:45 abadger1999: ovasik 17:24:45 abadger1999: yes. 17:25:11 I think we might want to make sure that ovasik is okay with this before we make it a guideline. 17:25:15 That was my next question: are we comfortable with whoever happens to own the setup package being the gatekeeper for what is allowed a static allocation? 17:25:52 Because the language in the draft discourages their use, but then sort of implicitly lets whoever owns setup make the decision. 17:26:03 tibbs: even before that, there was the history of "how do we do static uids at all -- the fedora-usermgmt discussion" 17:26:06 I think that we trust the owner of the "setup" package pretty well for a number of reasons. 17:26:29 * abadger1999 would trust the owner more if the owner was notting. 17:26:34 but... eh. 17:27:24 karsten and pknirsch have full access there. 17:27:29 (too) 17:28:09 I think this is fine as long as ovasik is fine with it, if it becomes a problem, we can hand it to FESCo. 17:28:14 I'm in favor of the draft, +1 17:28:15 I kind of agree, but it seems bad to say "open a bug against notting" ;) 17:28:54 So I'm +1 here with my change, as long as ovasik is fine with it. 17:29:00 -1 17:29:04 +1 17:29:09 I guess I'm +1* *but would prefer we never did static allocation, oh well. 17:29:25 I think it needs a little bit about how the soft static ids are allocated. 17:29:29 abadger1999: because of the owner issue, or lack of desire for static allocations at all? 17:29:41 "Look at whether upstream has a uid" 17:29:49 :Look at whether debian allocates a uid" 17:29:52 things like that. 17:29:58 abadger1999: you want to take a pass at improving the draft? 17:30:11 abadger1999: I'd hope the owner of setup, and thus the BZ, would resolve those things. 17:30:12 Well, we could always say that some committee has to vote on them or something. 17:30:14 geppetto: I'm not thrilled but I could vote +1 if those types of criteria were included. 17:30:23 But then I'm pretty sure who that committee would end up being. 17:30:31 tibbs: lol 17:30:39 geppetto: yes, but that hasn't always been the case in the past. Therefore, it needds to be written down. 17:30:49 abadger1999: fair enough. 17:30:50 "common sense isn't common" :-( 17:31:07 Sadly. 17:31:27 fwiw, the "setup bug link is" : https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=setup 17:31:43 * geppetto nods 17:31:44 spot: Yeah, I can look at that this week. 17:31:48 abadger1999: okay 17:31:55 then lets table this one until next week 17:32:13 If other people would like to jot down their thoughts on criteria in the ticket, I'll include them in my update to the draft for next week. 17:32:32 * abadger1999 updates ticket with status/discussion 17:33:35 I guess: 1) look upstream for uid defaults. 2) Look at Debian for any soft static uid values there. 3) Look at FreeBSD/etc. 17:33:46 * geppetto can't think of any other ones. 17:33:52 To be honest, if the goal here is really NFS-sharing of those files without having admin setup first, this needs to go to something outside of Fedora. 17:34:17 The original argument was "our customers said they want this". 17:34:26 But Red Hat customers aren't the focus here. 17:35:03 * nirik wonders if this should say something about moving any fedora-usermgmt using packages to the new setup too. 17:35:17 nirik: uh, yeah. 17:35:27 * spot will have a little party when that nonsense dies. 17:35:31 * nirik too. 17:35:52 Wasn't that restricted to packages from a certain maintainer who no longer owns any of those packages? 17:35:59 hmmm since ensc has given up all his packages, I'd be happy to see us migrate away from that. 17:36:03 Might have been. 17:36:22 I have a few of them, including f-umgt. I could work on that. 17:36:38 Do we know how big a task this is? 17:36:57 i don't recall him owning a ton of things, but repoquery will tell you better. 17:36:57 Just remove the dependencies and go back to the recommended scriptlets. 17:37:26 And then retire the thing. 17:37:30 Okay, lets try to do a bundling ticket. 17:37:34 It won't hurt existing packages since the UIDs already exist, and new installs will get new random allocations. 17:37:41 * limburgher hopes we get to mine. 17:37:47 #topic Bundling exception request: mediatomb and libupnp - https://fedorahosted.org/fpc/ticket/268 17:37:50 tibbs: Right. 17:37:54 yaay! 17:38:21 English TLDR: mediatomb forks libupnp, depends on their forked API. 17:38:40 And by pure luck the security bug didn't hit it. 17:38:47 mediatomb upstream is willing to apply security fixes going forward. 17:38:49 Pretty much. 17:39:18 spot: Do they actually change it … or is it just old? 17:39:33 From what I can see it just looks like an old version, no actual changes to the fork. 17:40:01 At which point I'd heavily lean towards "you just won maintainership of compat-libupnp" 17:40:03 Upstream says: "Reason is simple: our version of the library has an API that is not compatible to libUPnP, it has various custom patches and extensions." 17:40:06 It's old, plus security patches. 17:40:29 geppetto: I wish it were that simple. 17:40:37 sigh 17:40:57 Yeah. 17:41:24 It's pretty amazing actually, that I don't drink more than I do. Which is barely. 17:41:33 indeed 17:41:43 They're making changes and patches to an old version, I think it is safe to consider this a fork and not a 'bundle'. Since it is not trivial to use the system libupnp, I'm +1 on an exception in this case. 17:42:38 * spot wants the world to be utopian, but I'm tired of this battle. If the upstream makes good faith efforts to help keep their fork secure, I'm fine with it. 17:42:42 I did get it to build, actually, and the patch is huge. And the resulting binary then fails horribly. 17:43:14 +1 exception 17:43:14 I don't particularly have a problem with this. 17:43:37 * spot sees +1:2, 0:0, -1:0 for an exception. feel free to either raise points or vote. :) 17:43:39 +1 17:43:45 It seems like we have all of the requested info, and there doesn't seem to be another solution which keeps a working package in the distro. 17:43:47 +1 17:44:28 * spot sees +1:4, 0:0, -1:0 for an exception. abadger1999, Smoother1rOgZ are our missing voters, assuming limburgher is abstaining. 17:44:37 limburgher: so... are the changes applicable to other users of libupnp? I'm not seeing hte answer to that in the upstream ticket? 17:44:53 * limburgher is. 17:45:06 +1 for the record 17:45:08 abadger1999: They don't seem to be. 17:46:03 Other users would have to have used exactly the same version of libupnp, and I don't think that's common. Although I guess it might, if that was somehow the last version before some big API upheaval. 17:46:36 And if it were the case, that would argue for some separate compat package, I guess. 17:47:06 Right, and I'd be happy to do and maintain that, if that were the case. 17:47:16 abadger1999: if you'd like to vote for the record, feel free to do so. otherwise, we're at +5. 17:47:28 limburgher: is the current released version of mediatomb (with bundled pnp) secure? Or only the git master? 17:48:23 abadger1999: I believe both contain various security fixes, but the git master is more secure. I'll update to that. 17:48:38 I guess I'm -1 for the record then. 17:48:43 I'm told a release is forthcoming. 17:48:55 #action Exception for mediatomb to include its fork of libupnp is granted (+1:5, 0:0, -1:1) 17:49:26 upstream doesn't appear to be keeping up with the flow of security bugs for end user consumption. 17:49:33 #topic Bundling exception for nodejs-should - https://fedorahosted.org/fpc/ticket/264 17:50:02 this is a case of a forked code fragment taken from one javascript file into another. 17:50:24 Based on the discussion on the list and in the ticket, I'm +1 for an exception here. 17:50:31 I was +1 in the ticket... but does anyone remember if we wrote up the "code fragment" thing somewhere? 17:50:45 I want to be able to point to it for cases like this. 17:50:50 abadger1999: i havent seen it, but i'd probably be in favor of it. 17:51:00 * abadger1999 will add that to his todo to write up. 17:51:00 seems trivial, +1 17:51:36 I don't think we should particularly care about mere fragments of code. I do recall talking about it at one point, but I'm not sure it was written into any guidelines. 17:52:04 +1 as well. 17:52:15 +1 17:52:19 +1 17:52:28 #topic Bundling exception for nodejs-should to include the forked code fragment from the Node.js "assert" module is approved (+1:6, 0:0, -1:0) 17:52:31 yeah, +! 17:52:34 errr.... 17:52:41 #action Bundling exception for nodejs-should to include the forked code fragment from the Node.js "assert" module is approved (+1:7, 0:0, -1:0) 17:53:15 But I am happy they asked about it. 17:53:49 do we need a virtual provide for this? 17:54:29 I wouldn't think so, but then we're going to have to decide where the threshold is. 17:54:45 Because some of the bundled crypto stuff we track is probably smaller. 17:55:20 tibbs: I was just thinking the same thing 17:55:51 Unless we wanted a generic Provides: bundled(js-fragment), but that's probably asking for trouble. 17:56:22 And is in general pretty impossible to track. I mean, the point of free software is that you can lift bits when you need them. 17:59:20 #topic open floor 17:59:29 Ah, thought I lagged out for a second. 18:00:07 To be honest, I think we as a committee need to do better about getting to things, but I can easily blame myself for that. 18:00:37 None of us escape that, really. 18:00:46 Yeah, there were several weeks in a row where I wasn't here to run the meeting. :/ 18:00:49 If we can't get to something in a meeting or two, we need to be voting in tickets, but someone has to keep track of tickets in that state. 18:00:57 * spot is getting pulled in all directions constantly 18:01:18 tibbs: +1 18:01:46 And my life, right now, is nuts. I basically have a teenage daughter now, and things are insane until she graduates from high school in June. 18:02:08 On that line, several people have asked me lately about whether there are any openings on the FPC. 18:02:22 So, if anyone wants to give up their seat on the FPC, feel free to let me know. 18:02:59 Interesting question. Maybe we should talk openly about whether it's time for anyone to step down. 18:03:03 I've been meaning to ask about that. Not that I'm interesting in giving up my seat, but we don't seem to have a real process around that like the other bodies. 18:03:33 the process is basically when a seat opens up, I send out a public call for people to apply 18:03:44 then the FPC considers candidates 18:03:58 Right. 18:04:02 I mean, I've been here since the beginning, but I'm not entirely sure how much I'm really able to do these days. I do try to be here except when it's simply not possible. 18:04:36 Maybe we could expand the committee but somehow relax the voting. 18:04:47 * spot is not thrilled with the idea of growing the committee to be any larger, but if others disagree, I'm open to hearing it. 18:04:52 Interesting. 18:05:19 I guess I'd rather see how a more robust ticket-voting process goes, before we consider structural change. 18:05:29 Sort of like how we run sponsorship. We don't expect a majority of people to even vote. We just want to ensure that someone paid attention and that there are more yes votes than no. 18:05:34 I think that the majority vote has worked well for us to date, along with a general policy of discussion around most -1 votes. 18:05:49 Well, except when we can't get quorum. 18:05:56 there is that. 18:05:57 But that hasn't really been a problem lately, I guess. 18:05:57 tibbs: Right. If I don't know the person, I keep my mouth shut. 18:06:34 * spot secretly hopes that at some point, we'll stop having major packaging drafts coming in, but that may be wishful thinking. 18:06:56 heh! 18:06:56 I once hoped the same thing about package reviews. 18:06:59 That will happen when there stop being new languages, and the old ones stop changing. 18:07:01 And looked how that turned out. 18:07:13 "Oh, we'll be done with most of the software at some point in the near future." 18:07:37 Hmm. That reminds me, I haven't beaten on the Merge Review Drum/Dead Horse in a while. . . 18:07:41 * abadger1999 feels that continuity is good in the packaging committee 18:08:04 abadger1999: I kind of agree. People should know what they're in for. 18:08:07 I agree, and we have some very valuable contributors. 18:08:11 And it's not really the kind of thing it makes sense to elect. 18:08:42 Plus, it's a FESCO subcommittee, technically, so if someone were causing a problem, couldn't they force a replacement? 18:09:27 Yes, FESCo has complete discretion over the committee. But they (we, back then) handed it over to spot pretty much completely. 18:09:30 I suppose although we'e been reasonably autonomous. (and didn't really start off as a fesco subcommittee) 18:10:02 the history of FPC is colorful at best. :) 18:10:04 we do have the rule that people need to attend meetings or give excuses in advance. 18:10:43 pretty sure we've all broken that at least once :-o 18:10:47 which has been used to remove people that just weren't contributing to getting things done but held a seat that could otherwise be used by someone who would do more work. 18:11:12 (I think it's two or three weeks in a row of absent without an excuse) 18:11:13 I would really prefer if people voluntarily stepped aside rather than to leverage that. 18:11:19 18:11:19 Yeah, that's the kind of open discussion I was getting at. 18:11:44 Yeah. I don't want to push anyone out. 18:11:45 prefer, yep... I would have prefered that when it had to be used in the past as well ;-) 18:11:51 But the reality is that we haven't been able to lock down a time that works for everyone. 18:11:52 i will send out an email to everyone asking if anyone wishes to step down. if anyone does, we'll open submissions for interested and well qualified candidates. 18:12:04 if no one does, i'll mention it next week. 18:12:31 consider me interested in giving up my seat. frankly, i've not enough free time to contribute much besides just voting for awhile. 18:12:32 k. We're not a horribly composed FPC at the moment, either. 18:12:43 Should we talk about where the questions about new FPC membership are coming from? Because I'm pretty sure I know, but I'm not sure it's relevant. 18:12:47 we generally have quorum and we do vote in tickets when prodded. 18:13:10 rdieter: I would think that unfortunate, because you often have a different opinion on a few core issues (mainly bundling) that I'd hate to see get lost. 18:13:12 I'd be happy to move aside for some fresh (active) blood 18:13:12 and we are generally able to discuss how to make drafts better whether we agree with the entire idea or not. 18:13:14 tibbs: lets just look at any candidates who apply rather than gossiping about motivations. :) 18:14:09 WIse. 18:14:22 tibbs: yeah, word 18:14:27 Well, my problem is that I see a significant amount of agitation from a few folks who could make committee membership as unpleasant as it used to be in the bad old days. But yes, indeed, gossip would be bad. 18:14:50 * abadger1999 agrees with tibbs on all counts he's made in the past few minutes. 18:14:53 tibbs: i doubt the current FPC would support some of those folks being on the FPC. 18:15:03 spot: Seconded. 18:15:16 * spot is not interested in ramming random Red Hat people onto the FPC and Red Hat is well aware of that. :) 18:15:56 So, on another sibject, how bad are we doing with the queue of stuff to look at? 18:16:06 Not like it matters, we're all just puppets of the Shadowman Cabal anyway. At least that's secret. Hang on, someone's at the door. 18:16:14 tibbs: its not too bad. there are a lot of writeups/announces pending. 18:16:38 if anyone wants to help with that, i'd sure appreciate it. 18:16:45 otherwise, i'll just get to it when i get to it 18:16:52 Unfortunately the open ticket list doesn't even fit on my screen, but I need to dig deeper to see what's actually done. 18:17:25 lots of open tickets where the reporter needs to provide more information. 18:17:51 some of those, we need to prompt the reporter with what information specifically we want. 18:17:54 Maybe we can use a status for that or something. 18:17:54 Then we might want to ping, wait a week or two, and close. 18:18:48 many of the open tickets are bundling requests... if we don't get a maintainer response, it would be fine to close them as it means that the package could not be bundled. 18:19:51 I think we leave many of those open because we're nice people who don't want to say no until we've explored the issue thoroughly but the burden of proof is definitely on the reporter so if they aren't communicative, there's nothing we can do but close it. 18:20:23 and in at least half of hte cases, saying no is likely the right answer. 18:21:09 (people are being lazy about asking to be able to bundle rather than forward porting or maintaining a new library package or making the library a true fork). 18:21:23 abadger1999: what milestone should we fix on that before closing after no responses? 18:23:06 * abadger1999 finds a ticket that should just be closed as resolved. 18:23:34 Smoother1rOgZ: I don't know. Open for suggestions. limburgherseemed to propose two weeks. 18:23:41 I have no objection to that 18:24:00 I was spitballing, but I think 2 weeks is workable. 18:24:16 * spot is fine with that. 18:24:58 * Smoother1rOgZ is ok too 18:25:11 sure 18:25:45 i see +5 on that 18:25:57 so feel free to codify that on the Packaging Committee wiki page 18:26:01 then triage! ;) 18:26:11 +1 18:26:33 I'll do that if there are no objections. 18:27:33 okay, we're at 90 minutes now, and I need to pee. :) 18:27:36 thanks everyone. 18:27:38 #endmeeting