16:59:29 #startmeeting fpc 16:59:29 Meeting started Thu Jan 9 16:59:29 2014 UTC. The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:59:29 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:59:35 #topic Roll Call 16:59:39 who's here? 17:00:23 #meetingname fpc 17:00:23 The meeting name has been set to 'fpc' 17:01:13 * RemiFedora here - Happy 2014 ! 17:01:35 * Rathann here 17:02:31 Hello! 17:02:33 As usual ticket 374 isn't on the agenda, but that doesn't seem to stop you guys from discussing it. 17:05:07 * geppetto is here 17:05:47 #chair RemiFedora Rathann geppetto 17:05:47 Current chairs: Rathann RemiFedora abadger1999 geppetto 17:06:12 ping limburgher, tibbs, racor, SmootherFrOgZ FPC meeting time 17:06:46 Here 17:07:37 #chair limburgher 17:07:37 Current chairs: Rathann RemiFedora abadger1999 geppetto limburgher 17:07:44 Well, that's enough for quorum. 17:07:57 #topic #339 software collections in Fedora 17:08:03 https://fedorahosted.org/fpc/ticket/339 17:08:13 I tried to work on this over vacation, honest :-) 17:08:36 I got a sample template done, a few minor renaming of terms. 17:09:01 Rombobeorn: You can ask me to add things to the agenda, and/or reply to the email to the lists. 17:09:22 https://fedoraproject.org/w/index.php?title=User%3AToshio%2FSCL_Guidelines_%28draft%29&diff=366334&oldid=364381 17:09:39 Rombobeorn: For some reason it's not in the list of tickets from report 12 … which is weird. 17:10:07 and https://fedoraproject.org/wiki/User:Toshio/SCL_Request_Template 17:10:43 View the source for the SCL Request Template just like you would for the Fedora Change Template to see instructions for filling it out. 17:11:18 What I tried to do over vacation but failed at was making an actual useful SCL. 17:11:21 Rombobeorn: Ahh, because it's status=writeup now. 17:11:39 I tried to take the python2.4 from RHEL5 and turn it into an SCL for fedora. 17:11:39 abadger1999: Was it really hard, or did you just not get around to trying? 17:12:17 Hey folks; I am waiting for someone to be towed out of my parking spot. 17:12:26 It turns out that SCLs are not a magic bullet for making old code run on newer libraries ;-/ 17:12:32 #chair tibbsphone 17:12:32 Current chairs: Rathann RemiFedora abadger1999 geppetto limburgher tibbsphone 17:12:44 abadger1999: ha :) 17:13:02 geppetto, I've seen that some tickets have a status of "meeting", but I seem to be unable to set that status. 17:13:26 Yeah, building Python 2.5 RPMs on EL-6 is challenging. Like, I've never been able to do it. 17:13:47 So yeah -- That might be a little ambitious... I guess since this is just to test the packaging guidelines I'll try to make a python2.7 or python3 SCL instead. 17:14:01 Rombobeorn: That's a keyword, not the status … and yeh, that gets set sometimes by someone on the FPC. 17:14:29 abadger1999: *nods* … something that has a chance of building would probably be a better start :) 17:14:39 limburgher: And getting it to run on Fedora turns out to be worse... Gave up last night when I found that db4.8 has a different API than db4.7 (they made things that were mentioned as private actually be private). 17:15:01 abadger1999: Neeto. 17:15:02 So that's the status there -- feel free to look over the template and give feedback. 17:15:07 We can vote on that next week. 17:15:17 the template seems fine 17:15:28 #topic #358 Please make some autotools guidelines. 17:15:32 https://fedorahosted.org/fpc/ticket/358 17:16:01 As mentioned i nthe agenda, defering this as no one's rounded up time to work on a draft. 17:16:08 #topic #369 Guidance on dealing with the bundled libev in perl-EV 17:16:14 https://fedorahosted.org/fpc/ticket/369 17:17:12 So...I would not want to consider this a coopylib. 17:17:26 -source is preferable to bundling. 17:17:44 using system libraries is preferable to -source 17:18:07 abadger1999: ACK. 17:18:20 so the question in my mind is whether we can get system libs working or have to go to the second best (-source in this case) 17:19:34 -source seems acceptable 17:19:51 From the comments it seems like upstream is pro. bundling, so using the system libs. would require a lot of work. 17:19:59 So normally -- we ask that maintainers try to get changes merged to upstream or consider forking upstream. 17:20:02 So I guess we go -source route. 17:20:13 For instance: https://bugzilla.redhat.com/show_bug.cgi?id=1049554#c2 17:20:32 I think there is also a php-ev (not in fedora), which also bundled this... 17:20:57 but I think demanding that maintainers fork upstream is a grey area where we have decisions which are on either side of the line. 17:21:52 php-ev description says it provides an interface to the libev library... so on the surface, there's no reason to let it bundle 17:22:20 -source is akin to static linking so it's the next compromise position if we can't get changes into (a new) upstrema. 17:22:27 bleh, it actually says libev is included with that extension 17:22:31 * geppetto nods 17:23:51 * SmootherFrOgZ is here now (sorry for the late) 17:27:13 problem with libev is the watchr structs which is design to be overrided at build time 17:27:23 https://bitbucket.org/osmanov/pecl-ev/src/30589504e7cbe14445053682e42c07f7d37f677d/embed.h?at=master 17:28:01 Proposal: mention that copylibs would not be an option here. say that we need to know why upstream doesn't want to merge changes to make this runtime changable 17:29:09 I don't mind waiting for that, but I suspect the answer is going to be "because he doesn't want to" 17:29:16 The question would still be -- if upstream doesn't have a good reason to keep that from being runtime settable, what are we comfortable with. 17:29:23 geppetto: yeah. 17:31:22 RemiFedora: ouch, that would ned to be un-embedded and might be hard to disentangle. 17:31:42 Are we doing libev now or still on SCLs? 17:31:50 libev 17:31:50 tibbs: libev 17:31:50 So we could vote on whether to allow -source now or vote on whether to allow -source now if the upstream refuses to make it runtime settable. 17:32:19 I guess I'm a reluctant +1 on allowing -source. 17:32:22 OK, so /topic is not syncing again or something. Sorry, finally got into my parking space and to the office. 17:32:47 abadger1999: My guess is the leading space screws it up? 17:32:58 oh, blah 17:33:04 #topic #369 Guidance on dealing with the bundled libev in perl-EV 17:33:09 geppetto: yep, you're right. 17:33:34 +1 on allow -source if upstream refuses 17:35:06 Proposal: Allow libev build -source package and packages which bundle libev presently need to switch to using the code from the -source package instead. Follow the static library guidelines for making sure that the packages which use -source stay up to date with libev changes. 17:35:21 Reluctant +1 17:35:33 +1 17:35:49 +1 if upstream refuses 17:35:53 I'll explain about the hierachy of preferences so that people know why copylibs doesn't cover this as well. 17:36:38 +1 I guess. I still don't get why this library needs to be so problematic, though. 17:36:59 reluctant +1 17:37:27 +1 17:37:32 Rathann: k. To accomodate your vote, I'll ask the package maintainer to post why upstream doesn't want to merge changes to make things runtime settable instead of buildtime settable. 17:38:07 Rathann: (Which could be... "I just don't want to") Is that acceptable to you? 17:38:22 yes 17:38:38 abadger1999: I am asking myself, why the Fedora maintainer is so reluctant on change the code himself. 17:40:31 racor: It would be a fork. I don't think all the places where libev is consumed have been evaluated to see what would need to be made runtime settable are. I think the package maintainer is only interested in the apps using libev; libev itself is code that he isn't familiar with. 17:41:51 abadger1999: That's the normal job as package maintainer :) 17:41:56 #info Proposal to allow libev-source (with conditions -- see summary in ticket) approved. (+1:6, 0:0, -1:0) 17:42:08 #topic #375 Update to the Addon Packages naming guidelines for Python 3 Modules 17:42:13 https://fedorahosted.org/fpc/ticket/375 17:42:47 abadger1999: actually, it's +1:7 17:42:54 abadger1999: spaces :-o 17:43:02 #undo 17:43:02 Removing item from minutes: 17:43:09 abadger1999: You want me to format the agenda differently? 17:43:13 #info Proposal to allow libev-source (with conditions -- see summary in ticket) approved. (+1:7, 0:0, -1:0) 17:43:22 #topic #375 Update to the Addon Packages naming guidelines for Python 3 Modules 17:43:30 whitespace will be the death of me 17:43:41 :) 17:43:51 geppetto: nah, it's just the way I'm cutting and pasting 17:44:09 https://fedorahosted.org/fpc/ticket/375 17:45:44 I'm having trouble seeing this as anything other than rules lawyering. 17:45:52 Let's see... I think for this one we wanted to make clear that new packages need to follow python-/python3-NAME 17:46:30 not python2/3-NAME? 17:46:53 but also make clear that packages which already exist and are NAME-python need to be NAME-python3 17:47:08 and python-NAME with python2/3-NAME subpackages if it supports both 17:47:14 Rathann: well... that's coming up in bkabrda's proposal. 17:48:47 Proposal: Treat this as a clarification to mean new packages need to follow python-/python3-NAME and old packages that are named NAME-python need to have NAME-python3 counterparts 17:49:08 As a clarificatoin, any of us can write that up once we get the 'round tuits 17:49:29 (and it might be moot after we discuss and vote on bkabrda's proposal) 17:51:54 Does the proposal work for everyone? 17:51:55 I guess that's a good idea in any case, but I'm not sure it will satisfy the original request. 17:53:34 * RemiFedora can't find where confusion is. Current guidelines seems clear about "a now removed exception" 17:54:02 yeah -- I think it's just the examples that he wants clarified. 17:55:01 I don't know; there's that wall of text but nothing actually saying what he'd like changed. 17:55:50 So, yeah, clarify the examples as much as possible but don't actually change any guidelines unless someone tosses in a proposal for what they actually want changed. 17:58:20 Okay. 17:58:29 I guess that's where we'll leave that then. 17:58:54 I'm sure we'll get complaints (and still no draft) if that wasn't what was being requested. 17:59:06 #topic 374 Ada guidelines changes for Comfignat and runpaths 17:59:11 https://fedorahosted.org/fpc/ticket/374 17:59:30 Running check-rpaths from %check seems to work well, so I agree to make it mandatory for packages that use GNAT_add_rpath. 17:59:36 I also propose to recommend it for other Ada packages, since the risk of accidental runpaths is fairly high in Ada packages for several concurrent reasons. 18:00:30 I have no problems with this. I've kind of wondered why we don't just run check-rpaths on every build. 18:00:47 +1 to the latest proposal 18:01:08 tibbs|w: Indeed. 18:01:15 tibbs|w: I'm not sure if check-rpaths would trigger on private libraries. 18:01:59 Off topic, yes, but I'd say that you can disable it if it gives false positives. But that's a separate discussion. 18:02:03 +1 to this proposal. 18:02:13 +1 as well. 18:03:03 +1 from me. 18:03:39 what are we voting on? https://fedoraproject.org/w/index.php?title=User%3ARombobeorn%2FAda_Guidelines_Changes_2&diff=365584&oldid=365581 ? 18:03:48 In that case, my vote -1 18:04:26 racor: The changes highlight what's changed from his original proposal. 18:05:34 No, the changes are relative to the current guideline page, after the Comfignat part was added. 18:05:36 abadger1999: the later 2 change block to me read as card-blanche to allow rpaths in Ada. 18:05:51 Rombobeorn: ah -- now I see i nthe history where you synced to the current guidelines. 18:07:22 I'm +1 18:07:37 That's +5 18:07:39 racor: You arne't fine with it even with the "must use check-rpath"? 18:08:00 +1 from me 18:08:09 #info Latest GNAT_add_rpath changes approved (+1:6, 0:0, -1:1) 18:08:09 Then you need to read more carefully, racor. The proposal is to require check-rpaths precisely to AVOID runpaths in installed binaries. 18:08:38 * RemiFedora cas confused by racor -1 18:09:09 #topic #377 tmpfiles.d guidelines update 18:09:11 Thanks guys! Please also fix the list structure as shown at https://fedoraproject.org/w/index.php?title=User%3ARombobeorn%2FAda_Guidelines_Changes_2&diff=365584&oldid=365581 as the current page has a broken XML structure. 18:09:40 Rombobeorn: Thanks. I'll do my best to remember to do that. 18:09:45 :-) 18:09:56 https://fedorahosted.org/fpc/ticket/377 18:09:56 My vote: -1, the changes are not-selfexplantory and will be subject to misunderstandings. 18:10:20 * abadger1999 runs over to see if his dryer is about to catch fire. brb 18:11:43 I'd rather have file permissions specified in RPMs, no more error prone than having to run another tool. 18:13:21 sorry, I have to leave now 18:14:25 in all case, the file must be list in rpm to be correctly own 18:14:52 so if rpm don't have the file it need to %ghost it... just awfull. 18:15:06 so I agree with rdieter comment 18:22:50 Yeh, so this is confusing 18:22:54 Hmm... 18:22:55 But I'm pretty sure I'm -1 18:23:08 I think this bit: 18:23:10 'Yes, that's the way it's done currently. It just feels error-prone to have to duplicate this list of files in two places. ' 18:23:16 Okay I've just read through those bugs and don't see how the proposed guideline update addresses them. 18:23:36 Basically means "yeh, it's annoying to have to put the data in rpm … much more fun to not have it in rpm so that rpm -V etc. doesn't work" 18:23:52 geppetto: 18:24:15 I'm not a fan. 18:24:44 Neither am I. 18:24:52 Plus requiring a scriptlet to do something that doesn't now require one seems a step backwards. 18:25:53 and the will be error-prone for dir/file ownership, so -1 18:26:28 tibbs|w: +1 18:27:37 -1 for the record. 18:27:51 -1 while we're at it. 18:27:58 -1 18:28:31 is also -1 18:28:31 with two more -1's, this would be definitively rejected (instead of failing for now due to lack of 5 +1s) 18:28:32 * RemiFedora will even think to add a "files create by tmpfile must be own by the package" 18:28:47 -1 18:29:15 my time is up, i've got to quit, bye. 18:29:18 geppetto: You still -1? 18:29:22 racor: Thanks for coming 18:30:53 #info Proposal to use systemd-tmpfiles --create and not have packages specify the directories under /var/lock in rpm's %files rejected. Vote to approve the proposal was (+1:0, 0:0, -1:5) 18:31:04 #topic Open Floor 18:31:20 That's everything from the agenda. Anyone have other tickets/issues/problems to bring up? 18:31:51 I may actually have more time to get involved again soon. 18:31:53 abadger1999: yeh 18:32:01 I have a lot of meetings at $DAYJOB today, can someone assist? 18:32:05 tibbs|w: Excellent! 18:32:17 limburgher: Sure. I'll trade you mine for yours ;-) 18:32:23 abadger1999: There were two more 18:32:29 abadger1999: 379 and 380 18:32:31 The kid is off to the dorms on Saturday and then my life can start to settle down. 18:32:36 abadger1999: But we can leave them for next week, I think :) 18:33:01 tibbs|w: congratulations to you and to the kid on reaching that milestone! 18:33:08 abadger1999: You don't know where I work or what they're about. Be very, very careful about making that offer. 18:33:21 tibbs|w: Wow. Cool! 18:33:31 limburgher: Be very very careful about letting someone ignorant of everything attend meetings in your place ;-) 18:33:46 abadger1999: :) 18:33:53 "Yeah, limburgher would be *happy* to do that by tomorrow" 18:33:57 ;-) 18:34:09 * limburgher gets out large mallet 18:34:36 Of course, it's the dorm at the university where I work, so I'm not completely free or anything, but at least some normalcy can return to my home life. 18:35:27 Okay, if nothing else, I'll close in 60s 18:36:17 Nothing from me. 18:36:47 #endmeeting