17:04:14 #startmeeting fpc 17:04:14 Meeting started Thu Nov 21 17:04:14 2013 UTC. The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:04:14 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:04:27 #topic Roll Call 17:04:38 * geppetto is here 17:04:40 * limburgher here 17:04:41 limburgher is here but busy for a few minutes. 17:04:43 * kkeithley_ is here 17:05:18 racor, tibbs|w, RemiFedora, Smoother1rOgZ: FPC ping 17:05:28 Howdy. 17:05:31 * racor is here 17:06:16 * RemiFedora here 17:06:21 #chair geppetto limburgher tibbs|w racor RemiFedora 17:06:21 Current chairs: RemiFedora abadger1999 geppetto limburgher racor tibbs|w 17:06:28 Okay, we have quorum 17:06:37 #topic SCLs 17:07:21 I went to the LSB meeting this week and proposed an FHS change that would address limburgher's /opt issue. 17:07:28 https://bugs.linuxfoundation.org/show_bug.cgi?id=1164#c7 17:07:34 Patch to FHS is in the bug. 17:08:21 tibbs|w: Did notting's reply address your concerns with /opt? 17:08:44 If not, feel free to ask him more questions ;-) 17:08:51 I mean, I understand the position. 17:09:02 I was going to reply at least one more time 17:09:17 I don't really agree with it, but I don't agree with this whole thing so it's difficult to make constructive arguments. 17:09:22 17:09:31 But if everyone else is happy with /opt now, I'm not really against it. 17:10:17 Okay, I'll leave it to you and geppetto to try to talk with him about it and I'll continue working wih the LSB people towards the FHS change. 17:10:31 I feel a lot more comfortable with /opt with that patch, but still not loving it. 17:10:44 and at some point we'll simply have to vote on it to see if we're okay with /opt or we want to force a change. 17:11:15 (I guess once LSB commits to or rejects the FHS change would be that time) 17:11:35 abadger1999: Yup. 17:11:50 Without it I revert to my previous stance. 17:11:54 17:12:13 Okay, I have one more info item for scls 17:12:29 Apparently there's work being done on sclv2 which can contain backwards incompatibilities. 17:12:38 abadger1999: Also … once that change goes through I think it'd be if filesystem automatically created at least /opt/fedora and /opt/rhel (or whatever) … to make it more obvious that those are now reserved. 17:12:58 geppetto: Yes. 17:12:58 geppetto, right 17:13:20 geppetto: That's a great idea /me makes a note to file a filesystem bug if the change goes in. 17:13:52 abadger1999: Will v2 be ready before we publish a full policy … if not, do we know how it'll be compatible? 17:14:03 incompatible, even 17:14:35 geppetto: (1) I don't think so -- but it would give us the opportunity to approve some things we don't like while also having a commitment that it would be fixed for a future version of Fedora. 17:14:47 (2) I don't have any info on that yet. 17:15:01 I think I'm also getting this second hand... 17:15:11 I don't think mmaslano is the one actually working on the scl tools. 17:16:17 Is it jzelany that's the actual coder? 17:16:37 * abadger1999 feels that we haven't actually talked to jzelany at all throughout this... 17:16:48 At first I thought that slavek was the scl coder. 17:17:00 jzelany works on scl-utils AIUI … but there's at least more person working on them. 17:17:51 Okay. I feel like we're in the old days when things inside of RH were opaque and we didn't know who was doing what. 17:17:58 It's kind of confusing because it has moved around too, I think … I know at least florian and another guy who left used to work on it months ago. 17:18:20 I guess I should just ask mmaslano for a current who's who list. 17:18:23 but I'm pretty sure they don't at all now. 17:18:26 * geppetto nods 17:18:31 * abadger1999 puts that on his todo 17:18:31 She should know :) 17:19:18 One thing to vote on this week for scls: https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_(draft)#SCL_Approval 17:19:31 The "Approval of General SCL Packages" box in that sectin 17:19:53 I wasn't sure where to add that before so this week I just picked a place. 17:19:59 I think that reflects our past discussions. 17:20:35 what changed? 17:20:47 geppetto: I added the "Approval of General SCL Packages" box 17:20:57 ahh, I see 17:21:03 before we had discussed that but hadn't mentioned it in the Guideline. 17:21:27 any discussion or do we want to just vote? 17:22:00 I think I could vote. 17:22:03 Maybe say it the other way around to make it clearer … approval is only needed for the top level scl packages? 17:22:33 aproval by FPC 17:22:37 right 17:22:43 or whoever 17:22:48 yes 17:23:01 once FPC is approved => standard review for all packages 17:23:10 17:23:14 yeh 17:23:22 I means, once SCL ... 17:23:32 Okay -- I'll work on turning the wording around this week and we can vote on it next week. 17:23:41 Works for me. 17:23:54 or in likelihood, the wek after. 17:23:56 ok, sorry to bring it up … but it just seemed confusing to me as worded :( 17:24:00 (thanksgiving) 17:24:04 abadger1999, perhaps my comment about having the main package in fedora should be include here ? 17:24:08 Oh, yeh, I won't be here next week. 17:24:08 No problem. 17:24:15 Ditto. 17:25:48 RemiFedora: Yeah. Could you drop a draft in there? And mark it for voting like I did with an {{admon/question||}} box? 17:26:15 I have add the comment, but lower in the draft, probably better place here. 17:26:46 RemiFedora: ah okay -- go ahead and move it up and we can vote on both of them in two weeks. 17:27:14 (both the main package and the General SCLs are just normal package reviews) 17:27:29 Okay, next topic 17:27:48 kkeithley_: Since you're here -- was there one of these topics that you were waiting on? 17:27:59 yes, #363 17:28:11 moved 17:28:13 vote started last week, 17:28:32 https://fedorahosted.org/fpc/ticket/363 17:29:31 #topic 363 exception for bundled library libntirpc in nfs-ganesha 17:30:09 So status on this: we need one more +1. 17:30:19 rathann might be +1 as his question was answered. 17:30:29 correct 17:30:40 tibbs|w: You could make it official as well as you haven't voted on it yet. 17:30:56 racor: And the same applies to your vote. 17:30:57 Yeah, sorry, I was away when this was discussed. 17:33:00 kkeithley_: For rathann's question, I think that he just wasn't sure what roles steved and Chuck Lever had in upstream/downstream/wherever. 17:33:30 I can +1 this. 17:33:34 Cool. 17:34:00 #info Temporary bundling exception for libntirpc in nfs-ganesha until after Fedora 23 approved (+1:5, 0:0, -1:0) 17:34:24 thank you. 17:34:26 0, I am ambivalent. libntirpc looks like a classic fork of tirpc to me. 17:34:26 kkeithley_: I'll come up with a virtual provide and post it to the ticket after the meeting. 17:34:33 #undo 17:34:33 Removing item from minutes: 17:34:38 #info Temporary bundling exception for libntirpc in nfs-ganesha until after Fedora 23 approved (+1:5, 0:1, -1:0) 17:35:13 racor: Note -- we do allow forks. We just strictly review bundling. 17:35:35 (and this is on the border as the intention seems to be to fork, they just haven't gotten to releasing the fork yet). 17:35:59 #topic #358 Please make some autotools guidelines. 17:36:03 https://fedorahosted.org/fpc/ticket/358 17:36:17 So... we've voted on this many times. 17:36:22 abadger1999: Allow, yes, but I do not want to encourage them. 17:36:47 Perhaps we just need to write up "There's two ways to do this. Maintainers can use either one" 17:37:58 Maybe expressing "Try X first. If that fails, you can to Y" 17:38:08 s/to/do/ 17:38:33 limburgher: did we have agreement within FPC about promoting one over the other? 17:38:50 abadger1999: I honestly don't recall. 17:40:14 I think racor and I have always been able to agree on allow but don't encourage but fall on opposite sides of which technique is the $subject of that ;-) 17:40:26 ha 17:41:14 I guess I'm in the middle … if some packager is willing to do the work/testing (hopefully also as part of upstream) to run autoreconf all the time … I don't mind them doing that. 17:41:35 If not, then don't. 17:41:37 Okay, I'll write up something simple that tells the two methods and attempts to point out the cons of both methods. 17:41:39 17:41:56 sounds good. 17:41:56 geppetto: Ah -- on that subject, I guess I would be willing to recommend not running autoreconf. 17:42:07 geppetto: If it's not broke, don't fix it. 17:42:09 :-) 17:42:13 I have to agree. 17:42:27 Yeah, I only run it when I have to. 17:42:37 Okay, I'll include that position in the guideline too. 17:42:44 I would kind of do that by saying "see all this work you have to do if you want to run autoreconf, and you must do it if you run it" … or you could just not :) 17:43:05 geppetto: Neither do I, but I doubt those packagers who are running autoreconf are skilled enough to validate their doings. Sorry if this sounds harsh. 17:43:43 racor: that's probably true … but we don't really have a way to check that, apart from asking them :( 17:43:44 racor: I'll be the first to admit that my autotools skill are limited to "poke at it until it does what I want" 17:45:10 geppetto, libburgher: That's why I prefer patching generated files. Doing so has much more limited scope of potential damage. 17:45:25 #action abadger1999 to write up some guidelines based on past FPC decisions. It will allow both strategies. 17:45:28 racor: A minimalist approach. 17:45:29 or unwanted side-effects. 17:45:41 limburgher: Yep. 17:46:59 #topic 359 Forbid sysv initscripts in addition to systemd unit files https://fedorahosted.org/fpc/ticket/359 17:47:36 So..status on this is: 17:47:51 Banning is at +4 racor could vote ban and it would pass. 17:48:01 exception: If upstream recommend or relies on running autoreconf. In this case, it's them who are supposed to test and to blamed ;) 17:48:21 +1 on 359 17:48:31 alternately, instead of banning, add wording to tell people they really should not be shipping those. 17:48:37 Alright, that's +1 17:49:18 err +5 and actually... we don't have an exact vote. 17:49:22 err prooposal 17:49:28 * abadger1999 trying to think one up. 17:50:13 isn't the proposal in the ticket simple enough "Packagers MUST NOT include SysV initscripts in addition to systemd unit files, even in a separate $name-sysvinit subpackage." 17:51:16 I guess I'm +1. 17:51:24 +1 17:51:24 17:51:31 +1 17:51:35 RemiFedora: and we'd drop the sysv subpackage section of hte guidelines. 17:51:37 -1 17:52:17 tibbs|w and racor want to vote on RemiFedora's proposal just to be clear? 17:52:24 abadger1999, I still don't understand the value of keeping sysv init script... 17:52:58 I means why you want to allow them 17:53:34 (and it's not my proposal ;) but bocheca one) 17:53:40 +1 17:53:50 RemiFedora: I don't like banning things that an industrious packager might need to make the package useful for themselves and their environment. 17:54:08 I mean, they can shove them in %doc or something. 17:54:14 RemiFedora: however, the one person I knew that used those says he's not using a sysv-based init system anymore. 17:54:34 yes, and a conditional sub-package %if %with_sysinit or something like that 17:54:42 So although I'll vote -1, I don't feel an urgency to fight for it anymore :-) 17:55:01 But we never could conclusively say that a regular user couldn't screw things up just by installing a -sysvinit package. 17:55:02 17:55:49 tibbs|w: yeah, as with anything there can always be bugs in corner cases even if the design states what should happen. 17:55:54 So I am a bit confused; what was the extra proposal I should look at? 17:56:04 tibbs|w: "Packagers MUST NOT include SysV initscripts in addition to systemd unit files, even in a separate $name-sysvinit subpackage." 17:56:17 tibbs|w: It's basically what was voted on in principal before; just wasn't spelled out. 17:56:39 I thought that was the last line of the initial message in the ticket. 17:56:44 I feel we need to clarify, for which Fedora releases this "MUST" applies and whether/when action is required to remove existing "SysV" scripts. 17:57:11 at the last meeting this was discussed we decided old packages are grandfathered. 17:57:17 Well, we never go back and enforce removal anyway. 17:57:29 If you want, I could just mention that in the announcement text. 17:58:25 "as in many cases of guideline changes, old packages are grandfathered but packagers are encouraged to look into dropping the sysvinit subpackages as they update in rawhide" 17:58:25 abadger1999: I regret, but I feel this is inevitable. 17:58:38 tibbs|w, yes, and the ticket have been created mostly because someone propose a new package, for review, with a sysint subpackage 17:59:11 Right, and these days I'd simply like the answer to be "don't include those, they have no useful purpose". 18:00:22 racor: is my proposed announcement text sufficient? 18:01:17 tibbs|w, it seems there is a dispute between the packager and the reviewer, so question comes to us 18:01:56 abadger1999: Which proposal? 18:02:17 "as in many cases of guideline change..." => ok for me 18:03:49 racor, "as in many cases of guideline changes, old packages are grandfathered but packagers are encouraged to look into dropping the sysvinit subpackages as they update in rawhide" 18:04:01 RemiFedora: I was looking into trac for something to pop up ;=) 18:04:07 Ok, with me. 18:04:37 alright... so tibbs|w, we just need your +1 to make it official. 18:07:03 Or propose alternate wording. 18:07:03 Sorry. I thought I had already +1'd what's being asked. 18:07:06 But +1 in any case. 18:07:07 Col. 18:07:10 Cool. 18:07:30 #info "Packagers MUST NOT include SysV initscripts in addition to systemd unit files, even in a separate $name-sysvinit subpackage." Approved (+1:5, 0:0, -1:1) 18:07:42 #topic #361 Two more bundled MD5 implementations 18:07:46 https://fedorahosted.org/fpc/ticket/361 18:08:28 mschwendt reports two more uses of bundled md5. 18:09:06 are they suggesting that they'll replace the implemention in the first case? 18:09:32 geppetto: that's what I get from mschwendt's report. 18:09:44 Ok, do we need to vote on anything then? 18:09:58 ie: they're currently using the RSA reference impl but he's going to convince them to use an already covered one 18:10:07 The second one, libsidplayfp does. 18:10:27 So that's a port of L.Peter Deutsch's code into a C++ class. 18:10:48 which means that there are some meaningful changes to the code. 18:10:51 right, just needs the provides with "-c++" added or something, right? 18:11:33 yeah the two alternatives are: new virtual provide or reuse the old one. 18:11:43 I lean towards a new one 18:12:03 so as you say, something like bundled(md5-deutsch-c++) 18:12:25 but my leaning isn't strong. 18:12:29 yeh, you might think the class would just wrap C calls … but, no, that would be the easy way :) 18:13:33 I'm +1 on that. 18:14:04 Okay, proposal: New Virtual Provide for C++ port of deutsch's md5 code: bundled(md5-deutsch-c++) 18:14:06 +1 18:14:21 although I haven't verified that the code hasn't changed apart from the c++ification … I going to assume it's good. 18:14:22 +1 18:14:40 +1 18:14:51 +1 18:15:09 There are some differences but it's mostly the same. variables passed in to functions have been made class attributes and things like that. 18:15:19 +1 18:15:42 #info New Virtual Provide for C++ port of deutsch's md5 code: bundled(md5-deutsch-c++) passed: (+1:5, 0:0, -1:0) 18:16:20 #topic 362 lpf in Fedora 18:16:36 The proposal to allow lpf and remove lpf-* passed in ticket. 18:16:42 I'll lcose this after the meeting 18:17:02 How are people doing on time? 18:17:12 We have two more bundling tickets on the agenda 18:17:18 I'm fine for them 18:17:22 fine 18:17:27 #topic #364 exception for bundled library ccan in ocserv 18:17:31 https://fedorahosted.org/fpc/ticket/364 18:17:58 from the looks of hte website, this meets our definition of a copylib 18:18:13 http://ccodearchive.net/ 18:18:31 the "Use the Code" section 18:18:32 It's that time of day, again ... Dinner is waiting ... I've got to quit. Bye. 18:18:39 racor: so long 18:18:41 Ugh. Yeah. it does. I hate these things. 18:18:42 Bye! 18:18:49 I have to go before long, too, actually. 18:19:17 Ugh; phone and then someone at the door. 18:19:42 k. Let's keep going until limburgher leaves -- that's when we'll lose quorum :-) 18:19:49 do we know what it copies? 18:19:56 K, that's about 11 minutes. 18:20:01 Reading that page, it's actually kind of scary. 18:20:14 yep 18:20:24 The library doesn't have a single purpose; it's just "dump some code snippets here". 18:20:30 they don't realy understand how to translate CPAN into C. 18:20:37 - build-assert, check_type, container_of, hash, htable and list from http://ccodearchive.net/ (ccan dir). 18:20:40 If we blanket excepted that, I think we'd be up for problems. 18:22:08 Okay -- so strategy? Maybe ask the reporter to figure out what they're using and we specifically allow them to bundle those particular functions into their program -- everything else from ccan needs to be deleted? 18:22:53 I think they're using => http://git.infradead.org/ocserv.git/tree/HEAD:/src/ccan 18:22:54 build-assert/check_type/container_of are all trivial 18:22:57 alternately... precedent for copylibs is things like egglib which are kinda random snippets of code as well (although egglib is constrainded to gtk+based gui stuff) 18:23:13 It's a difficult issue. 18:23:33 At some point we have to accept that trivial code snippets are going to get cut-n-pasted all around, as it should be. 18:23:38 hash is like 10x bigger 18:23:41 18:23:52 Bob Jenkins, May 2006, Public Domain 18:24:00 and hash could have security issues 18:24:48 RemiFedora: -- but md5 could as well. and there we decided we just had to make sure our tracking was of the code was up to the task. 18:25:34 bundled(ccan/hash) ? 18:25:37 ugly 18:26:01 I guess 18:26:20 list looks like the list code from the linux kernel. 18:26:31 Oh, yay. 18:26:32 So the only one I'm iffy on is hash 18:28:12 and I guess I could just sigh and let them do it. 18:28:17 Junkcode => well named 18:29:13 I have about a minute, are we voting or deferring? 18:29:15 no version... nightmare to track change... 18:29:23 Let's defer. 18:29:31 The hash is also the "bob jenkins hash" … not sure if that's the better provide … I wouldn't be shocked if someone had an implemention of that in another package (although if they'd not told us, I wouldn't be shocked either). 18:29:52 Ok. See you all in 2 weeks! 18:30:03 yeh 18:30:08 geppetto: yeah -- given how this is "cpan-like" that makes sense to me too. 18:30:43 are we willing to okay this; we're just not sure how to express the virtual provides? 18:30:57 Hmmm … /usr/share/man/man3/hashkit_jenkins.3.gz 18:31:42 * RemiFedora hides 18:31:48 * abadger1999 dislikes copylibs in general... but it is precedent/guideline so has to bite tongue and figure out how to apply it to the specific case :-( 18:35:18 yeh, so that's the same hash: 18:35:18 http://bazaar.launchpad.net/~tangent-trunk/libmemcached/1.2/view/head:/libhashkit/jenkins.cc 18:35:57 with less comments 18:36:40 I'm sure you will all be shocked to discover that libmemcached does not have any copylib. provides. 18:36:55 My heart may stop. 18:37:00 :-) 18:37:23 I … guess I could just waive it, it's probably fine. 18:38:01 In theory the libmemcached guys would have made libhashkit a separate project, and we'd have a separate package … and people would/could use that. 18:38:15 geppetto, it's the case 18:38:30 => /usr/lib64/libhashkit.so.2 18:38:45 RemiFedora: Yeh, but you have to install libmemcached to get it. 18:38:57 well, not a separated project, but a separated lib 18:38:58 http://burtleburtle.net/bob/c/lookup3.c <= original for that code 18:39:13 abadger1999: *nods* 18:39:44 abadger1999: Note: libccan has previously received an exception for certain samba-derived libs. 18:39:58 We were able to drop that dependency, but you have the precedent. 18:40:05 sgallagh: However that was different in several regards 18:40:41 sgallagh: there we didn't okay it as a copylib. we okayed it as a temporary exception where the upstream for the lib was the same as the bundling project. 18:41:01 sgallagh: this one would neither be temporary nor the same project. 18:41:18 true 18:44:33 alright -- anyone have an idea of what our way forward is? 18:45:30 I guess just hold my breath and +1 18:45:43 k 18:45:59 Yeah, from copylib precedent I think I'll +1 as well. 18:46:10 Also log a bug against libmemcached to add the copylib provides :) 18:46:35 but figuring out the bundled provide should be will be harder than normal. 18:46:36 18:47:25 Okay, I'll note to the ticket that we're leaning towards allowing but we may require separate exceptions for tracking each module being bundled. 18:47:42 And that we'll need to discuss this more to figure out what the provides should be. 18:47:54 #topic Open Floor 18:48:12 Anyone have anything they'd like to note before we end the meeting? 18:48:13 yeh, something specific for the bob jenkins hash … not sure about list (maybe kernel/lib … lol) … the others I'm happy to just put ccan/whatever 18:48:33 please check if I havent forget anyone from FPC https://fedoraproject.org/wiki/F20_anniversary_tshirt 18:48:59 I will very probably needed your physical address 18:49:32 Mine is no secret. 18:49:40 I didn't realize anyone was doing that; it's a neat idea. 18:49:50 RemiFedora: this is for past FPC members as well? 18:50:01 abadger1999: says F1-F20 18:50:11 Gabriele will ask me for the missing address (she already have some, I think) 18:50:21 18:50:42 RemiFedora: okay, there's a lot of past FPC members that will need to be added. But I don't remember them all offhand. 18:50:43 abadger1999, yes, i search in the FPC wiki page history, but only found Rex and Dennis 18:50:52 RemiFedora: maybe ask spot if he knows of old lists. 18:51:49 Off the top of my head I can remember Ville Skytta and Jesse Keating 18:52:40 yes, I will ask spot 18:54:59 RemiFedora: Cool. Let me know if spot doesn't have any old lists and I'll try to clear out some time to dive into old meeting logs or something. 18:55:19 But I'll be more confident if spot just has a record somewhere :-) 18:55:41 #endmeeting