17:00:13 #startmeeting fpc 17:00:13 Meeting started Thu Feb 13 17:00:13 2014 UTC. The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:13 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:17 #meetingname fpc 17:00:17 The meeting name has been set to 'fpc' 17:00:21 #topic Roll Call 17:01:24 Rathann, geppetto, tibbs, SmootherFrOgZ: fpc ping 17:02:16 here 17:02:19 * geppetto is here 17:02:26 * SmootherFrOgZ here 17:02:32 #chair Rathann geppetto racor 17:02:32 Current chairs: Rathann abadger1999 geppetto racor 17:02:42 #chair SmootherFrOgZ 17:02:42 Current chairs: Rathann SmootherFrOgZ abadger1999 geppetto racor 17:03:05 racor: you are here, correct? (Just checking since we need you to make quorum.) 17:03:06 * racor is here, but I waiting for a phone call and likely will have to leave then. 17:03:11 k 17:04:47 #topic #142 Request for changes to FPG 17:04:55 #topic #142 Request for changes to FPG 17:04:57 https://fedorahosted.org/fpc/ticket/142 17:06:56 We deferred this before until syslog was no longer hte default. 17:07:11 I'm also unclear as to precisely what changes to the current guideline are being proposed. 17:07:11 yeh, seemed like johann being annoying 17:07:19 * abadger1999 will note those questions in the ticket. 17:07:43 #topic #317 Bundled Library exception request for Gazebo 17:07:49 https://fedorahosted.org/fpc/ticket/317 17:07:49 * RemiFedora is here (sorry to be late) 17:08:45 abadger1999: from the #142 ticket it looks like part of the proposal was approved, but I can't find the relevant text in the guidelines 17:10:40 Rathann: yeah -- someone will have to research to see if spot's redraft was moved over into the Packagin: namespace and linked into hte guidelines somewhere. 17:11:33 So from the ticket it looks like this version of ode could be considered a fork. 17:12:09 I'd like to ask upstream if they'd be willing to have their fork made public (not necessarily a separate tarball... just we build it as a separate subpackage and let other things link against it) 17:12:38 If that's the case, I think we could approve it as a fork. 17:13:11 anyone else have comments they think we should have addressed? 17:13:26 sound like a good plan 17:13:33 meh. … doesn't seem like a fork that _should_ be happening though. 17:13:42 from the responses in #317 I think it might be better to make Gazebo's fork the canonical version of ODE 17:14:05 I'm reviewing the diff and it seems they removed at least one function/method 17:14:15 Yeh, I'm tempted to suggest that route too … if only to use a stick to make the upstream ode maintainer play well with others. 17:14:48 so the question is if it's used by any other dependent project 17:15:04 yeh, they said there were 6 packages requiring ode in Feodra. 17:15:17 8, sorry. 17:16:05 there are a lot of cosmetic changes like comment delimiters or whitespace 17:16:16 :( 17:16:43 so these would need to go away as they obscure the real code changes 17:16:53 or at least be in a separate patch 17:17:19 yeh 17:17:50 seems like a simple request for them to break out their real changes from that stuff, so everyone can see what's changed. 17:18:14 Also some more reasoning for why upstream aren't taking "speed improvements" 17:21:11 After looking at the correspondence with the gazebo upstream it seems like some of hte speed improvments might be made by getting rid of safety checks 17:21:52 yeah, but they add safety checks in a few places as well 17:22:03 I wonder what the performance gain is 17:22:39 if the checks are redundant then fine, but if they're there for a reason, then maybe removing them isn't worth the risk of segfaults 17:23:20 yeah. 17:24:01 * abadger1999 notes that we do allow forks even if they're for no reason. 17:24:24 or political instead of technical reasons 17:24:58 for instance openoffice vs libreoffice; firefox vs iceweasel ; mysql vs mariadb 17:25:14 true 17:25:20 but then they should rename it 17:25:39 Rathann: I thought from the comment in the ticket that they had? 17:25:42 sorry, was distracted on the phone, back now (1/2 hour left) 17:25:54 The 17:25:55 installed libraries have a different name than ode, and 17:25:56 there should be no conflicts between gazebo and ODE. 17:26:14 (Part of the response from the gazebo upstream) 17:26:24 But they want to bundle it, not just fork and ship it. 17:27:14 If they want to create a new package for it, I'm less annoyed. 17:27:17 which is why I thinkk I'd be okay if the upstream (gazebo) is willing to see it be a subpackage that other applications can start depending on. 17:27:54 * RemiFedora agrees 17:28:35 a new upstream tarball would be even better but I'm personally comfortable as long as they are willing to accept that we're going to make subpackages and may start having other people link to it. 17:28:36 and provides (install) the need headers for other app, and agree to maintain this fork 17:28:45 yeah. 17:28:52 * geppetto nods 17:29:16 hm, looks like ODE has just moved to bitbucket and is active again 17:29:38 so maybe now is a good time to try and get the gazebo patches merged upstream 17:30:16 So -- how about I say that we have several ideas -- one being to make it clear that this is a fork (subpackage or new upstream tarball, may have others link against it, etc). the other being to have more information about why upstream ode doesn't accept the changes nad what the changes are. 17:30:47 sorry, I've to leave for a short. 17:30:49 work for everyone? 17:31:00 yes 17:31:47 #info abadger1999 to update ticket with our two ideas on how to make gazebo-ode acceptable 17:32:11 I'm going to move one ticket up the queue since we have the ticket submitter here: 17:32:13 #topic #389 bundled bootstrap binary exception for sbt 17:32:32 https://fedorahosted.org/fpc/ticket/389 17:33:21 willb is the submitter 17:33:32 Those of us who were here talked about it at last week's meeting. 17:33:44 I think the ticket covers everything, but can answer any questions 17:34:29 It's a bootstrapping bundling. Hopefully one-time but there is the potential that we'd need to bootstrap more often (if upstream doesn't keep enough backwards compatibility) 17:34:37 So this is just for the first bootstrap? 17:34:44 After that the bundling goes away? 17:34:49 Started voting in the ticket: https://fedorahosted.org/fpc/ticket/389#comment:2 17:34:55 So far spot and I voted +1 17:34:58 Or do you need the bundling for N months/weeks until Apache Ivy catches up? 17:35:11 geppetto, I'd like an ongoing exception but do not expect to use it that regularly 17:35:45 geppetto, Ivy is only an issue for the bootstrap binaries (I believe my Ivy patch will be in the next release of sbt) 17:36:01 * geppetto nods 17:36:15 I'm happy to give a one time exception 17:36:26 I'm less clear about why you need an ongoing one 17:36:55 but if spot/abadger1999 think it's fine I'll defer to them and +1 that too. 17:37:11 geppetto, in the event that we can't build an upstream version with the versions already in Fedora. It doesn't seem likely, but it happens. 17:38:06 +1 for bootstrap exception, meaning the bootstraped build will be used for non-bootstrap rebuild 17:38:52 +1 I concur with RemiFedora. 17:39:19 and of course, we never distribute the binary used for bootstrap 17:39:23 sorry, had a freenode hiccup 17:39:38 willb: Only missed this line: +1 for bootstrap exception, meaning the bootstraped build will be used for non-bootstrap rebuild 17:39:49 And I figured that was a given :) 17:39:52 :-) 17:40:02 abadger1999: So I guess that's +5 now. 17:40:12 +1 from me as well 17:41:05 #info Bootstrap bundling approved for sbt bundling itself. (+1:6, 0:0, -1:0) 17:41:17 thanks FPC! 17:41:45 No problem. Glad this one was relatively straightforward :-) 17:41:47 #topic #338 %doc and %_pkgdocdir duplicate files and cause conflicts 17:41:53 https://fedorahosted.org/fpc/ticket/338 17:46:14 bah too much reading … and my brain isn't working anyway. 17:46:32 I don't think there is anything proposed here, orion wants us to propose something. 17:46:37 yeah -- this is old enough I don't remember any of the prior solutions we threw out. 17:47:13 I'm tempted to just ask Panu to fix rpmbuild :) 17:47:35 heh. That would certainly make our life easier :-) 17:48:50 I'm somewhat short on time right now but if someone else would like to look into this, I think they need to take another look at mschwendt's comment to start the ticket and work from there. 17:49:10 * RemiFedora prefer the old days when %doc means rm -rf 17:49:40 Probably a small guideline addition and a bunch of grunt work to update all the places in the guidelines that reference the old macros is what's needed. 17:50:05 * racor is wondering what this ticket is aiming at. 17:50:19 (The guideline addition we proposed before might even work out... It needed one more to pass and we had four members who didn't vote on it.) 17:50:47 Moving on since there's no draft.. 17:50:49 #topic #339 software collections in Fedora 17:50:54 https://fedorahosted.org/fpc/ticket/339 17:51:10 Updat ehere -- I've uploaded the SCLs I've built so far if someone wants to take a look. 17:51:27 http://toshio.fedorapeople.org/scls/ 17:52:25 cool 17:52:58 I need to make some further modifications to scl-utils and then talk to jzeleny again. this time about whether we should package several versions of scl-utils-build in fedora for building fedora packages vs rhel packages. 17:53:27 (meaing packages which follow fedora guidelines vs packages which follow the way rhel-scl is packaged) 17:54:14 You can compare the spec files from what's in http://toshio.fedorapeople.org/scls/fdr-python2.4/centos5/ to what's in each fdr-python2.4-* package to see what had to be changed to make scls work. 17:54:34 I'm still figuring out how to make the git-koji-pkgdb side of things work. 17:54:37 #chair tibbs|w 17:54:37 Current chairs: Rathann SmootherFrOgZ abadger1999 geppetto racor tibbs|w 17:54:52 remind me, why do we need this definition: 17:55:00 Ugh, well, obviously I'm late today. 17:55:02 my feeling is that scl-utils in fedora should provides default values matching fedora Guildelines 17:55:03 %global scl_prefix %{scl}- 17:55:24 why %{scl}- can't be used everywhere? 17:55:25 I know we can do it with entirely separate package at the git level but I'm not sure if we can do it cleanly in other ways too. 17:55:31 it's even shorter... 17:56:05 Rathann, because we mostly use %{?scl_prefix} so whould means using something like %{?scl:%{scl}-} 17:56:26 Rathann: We probably could but the scl-utils upstream uses scl_prefix. 17:56:53 and %{?scl_prefix} seems more readable 17:56:56 abadger1999: Out of interest … what happens if you try to build your fdr-python2.4 packages with scl's disabled? 17:57:07 yeah, I'm looking at http://toshio.fedorapeople.org/scls/fdr-python2.4/pyOpenSSL/fdr-python2.4-pyOpenSSL-0.6-2.fc20.src.rpm spec 17:57:30 sometimes you use %{scl_prefix} and sometimes you use %{scl}- 17:57:45 RemiFedora: in fedora specifically, we won't need the conditionals (since we're keeping the spec files separate) but if people want specs that are similar to RHEL-SCL then they'd need that. 17:57:52 meh, %{scl} alone is used in one place 17:57:58 geppetto: what do you mean by scl's disabled? 17:58:15 So that %{?scl_prefix} would == '' 17:58:41 it won't build because it buildrequires %{scl}-build 17:59:11 geppetto: I think brokenness. But that was one of the architectural things we (FPC) thought would be okay. 17:59:20 it's a departure from RHEL-SCL 17:59:49 we decided to follow the mingw model to avoid having to conditionalize every use of an scl feature. 18:00:13 (but the guidelines do allow conditionalizing.. they just don't require it because it won't make snese to how we're using it) 18:00:28 ah, sorry, I meant that the pyOpenSSL package for fdr-python2.4 scl won't build 18:00:53 https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_(draft)#General_SCL_Package 18:01:02 See the admon/note there. 18:01:18 abadger1999: Yeh, just was confirming with the whole %{scl}- vs. scl_prefix thing. 18:02:54 yep. so for fedora packages that don't aim to keep the same spec file for scl and non-scl builds %{scl}- might be shorter. For RHEL-SCL packages %{scl_prefix} is shorter and more readable. 18:03:12 nods 18:03:25 ok, understood 18:04:30 and I really think using conditional can make "huge" spec file unreadable (such as main php, python, ...) but are perfectly ok for small spec (extensions) 18:05:50 RemiFedora: Yeah -- I'm on the fence but I'm perfectly willing to let individual maintainers decide that since we decided to keep the scl specs separate from the mainstream specs. 18:06:14 One thing I wasn't counting on was that autodeps are almost 100% broken for scls. 18:06:37 yes, probably the biggest issue 18:07:02 so even for extensions, you may end up with a large conditional block that filters the autoprovides and autorequires and then manually creates them instead. 18:07:20 * geppetto nods 18:07:38 I thought we knew we'd have to turn autodeps. off … or have someone fix them so they get scl prefixed. 18:08:22 we talked about it -- but a proir version of scl-utils actually filtered autoprovides. that's been reverted so we have to do all the filtering ourselves. 18:08:46 So... a bit of confusion there as to what the behaviour was supposed to be. 18:09:00 abadger1999, mostly because filtering autoprovides, wihtout filtering autorequires don't make sense 18:09:12 abadger1999: Do you know why? 18:09:27 RemiFedora: Yeh, but fix that by filtering both … not neither :) 18:09:44 RemiFedora: well... I'm not certain of that... I think filtering autoprovides made sense (since it's now boilerplate that we have to do ourselves). But yeah, you'd still have to remember to filter autorequires yourself. 18:10:40 filtering autoreq. is not so easy, as for each lib you need to know if those are in system or in one scl or in another dependent scl... 18:10:45 geppetto: There was a bug opened. I don't think the conclusion to revert filtering autoprovides was necessarily correct but there's a symmetry to having to filter both so I can see that viewpoint as well. 18:11:24 geppetto: basically, autorequires can create a link from, say fdr-python2.4-python => libpython2.4.so. 18:11:47 geppetto: if autoprovides are being filtered then there's nothing that provides libpython2.4.so. 18:11:51 * geppetto nods 18:11:54 So the bug decided not to filter autoprovides. 18:12:02 I'd contend that we still have to filter both. 18:12:10 But given the options having all autoreqs. and autoprovs. filtered seems the best, IMO. 18:12:16 Because the autoprovides is polluting the non-scl namespace. 18:12:21 yeh, for sure. 18:12:43 If either of those libpython2.4.so things get out in the wild, it's really bad. 18:12:46 for isntance, say that this was a pyhton2.7 scl primarily for rhel6 but also used on fedora for compat 18:13:08 if it has the autoprovide for libpython2.7.so then it conflicts with fedora's system python package. 18:13:12 * geppetto nods 18:13:50 anyhow, that was the reasoning in the bug and why the guidelines now say to filter everything. 18:14:03 so we'vre over two hours. 18:14:08 #topic Open floor 18:14:18 anyone have something they want to throw out there before we close? 18:14:19 we can write, in the Guildelines, a SCL package must not provide anythin outside the SCL namespace, and recommend to turn autoreq/prov off as a temporary solution 18:14:51 * geppetto nods 18:15:11 RemiFedora: This is what I've got written right now: https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_(draft)#Dealing_With_Automatic_Provides.2FRequires_and_Filtering 18:15:20 * RemiFedora notice thant the PHP stack have absolutly no dep issue :) 18:15:29 I'm sorry I'm late. Did I miss #387? (Heimdal bundling libtommath) 18:15:33 abadger1999: 2 hours? I've counted 1h15m so far 18:15:46 oh. am I just anxious to get out of here? 18:16:02 We can go on then, we still have quorum. 18:16:24 abadger1999: your draft text seem fine to me. 18:16:36 RemiFedora: What about for pear extensions? 18:16:47 #undo 18:16:47 Removing item from minutes: 18:17:16 abadger1999, php mostly use manual virtual provides, so evrything is ok 18:19:10 oh I meant pecl packages... I had my terminology wrong 18:20:03 the only issue is if you use a library included in the SCL. The only case you need to filter. 18:20:31 I have a test case for this (with php-pecl-event and libevent 2 not available in rhel) 18:21:03 well.. I had.. as I recently drop my SCL repo... 18:21:14 18:21:31 Alright.. let's move on. 18:21:59 Since ktdreyer is here 18:22:01 #topic #387 Bundling exception: Heimdal bundles libtommath 18:22:07 https://fedorahosted.org/fpc/ticket/387 18:22:35 those of us who were here discussed this last week. 18:22:36 ktdreyer: gogogo :) 18:22:43 It's a tough one. 18:23:06 Heimdal is a kerberos implementation so there are security ramifications... The alleviating factors we saw were: 18:24:15 1) The bundled copy is more secure (it removes an optimization which would allow attackers to use timing attacks to get information out of the system) 18:24:40 2) Both upstreams are working to merge the changes from the heimdal copy back to libtommath. 18:25:00 I think we'd normally be fine with a temporary bundling exception in these circumstances. 18:25:14 ok 18:25:30 seems reasonable, do we have any kind of timeline for merge? 18:26:40 Where we get stuck with a ttemporary exception is that the heimdal change can't go into libtommath verbatim -- it probably needs to have a parallel api added (code that needs to resist timing attacks uses one path while code that wants speed uses the other path). and that the libtommath upstream can't commit a lot of time to working on it. 18:26:54 ktdreyer: anything to add to my summary? 18:28:28 geppetto: I tossed around the idea of a 1 year/two Fedora release timeline with ktdreyer last week. he was hesitant because he doesn't know that libtommath upstream would have the time to complete it by then. 18:28:59 ktdreyer: three releases? 18:29:02 I think it's a case of both upstreams want to work together but someone has to actually have time to write code to implement the change. 18:29:05 I'm pretty much fine with this. I'd think it would be pretty easy to just have constant-time versions of various algorithms, and don't understand why any library used for crypto would reject that. 18:29:07 But that's just me. 18:31:07 I understand it could take some time to achieve (it take >2 years to unbundled libzip from php), so a temp. excep seems reasonable 18:31:54 * Rathann concurs 18:32:00 sorry guys, my internet cut out at the *worst* moment. I'm back now 18:32:07 +1 from me to temporary exception 18:32:41 +1 to a temporary exception, but we need to decide on how long. 18:33:06 I did ask Steffen about timelines this morning, and he hasn't responded yet 18:33:44 Now, I'm guessing mp_expt_d() gets called deeply by other libtommath functions and not just directly by Heimdall code, right? 18:33:56 Because if not then the answer seems to be kind of obvious. 18:33:58 tibbs|w: unfortunately yes 18:34:18 Proposal: Temporary exception until Fedora 22. FPC expressed a willingness to look at granting an extension of another two releases if this one expires without the changes being merged upstream. We'd want to see that it was still being worked on, just not completed. 18:34:43 Nuts, then you have to have constant-time variants of everything upwards in the call chain, or change the API or something. 18:34:54 abadger1999: +1 to that. 18:35:07 +1 to that 18:35:08 +1 18:35:30 tibbs|w: yeah, exactly :( 18:36:03 +1 18:36:44 like Heimdal uses libtommath's mp_n_root, and mp_expt_d gets called inside there 18:36:45 +1 18:37:40 One could say that there's a minimal set of libtommath that would have to be bundled, but I hardly think it worth it to go there. 18:37:54 #info Temporary exception for Heimdal to bundle libtommath until Fedora 22 granted. FPC expressed a willingness to look at granting an extension of another two releases if this one expires without the changes being merged upstream. We'd want to see that it was still being worked on, just not completed. (+1:5, 0:0, -1:0) 18:38:16 #topic #340 Bundling exception for nodeunit 18:38:36 thanks all very much for your consideration. I have to get to another meeting, so I'm heading out 18:39:39 ktdreyer: Thanks for gathering information and tracking upstream discussions :-) 18:39:51 This one doesn't have std questions answered. 18:40:44 yeh, leave it until they do 18:40:52 although it's been two weeks since I asked for them. 18:40:56 Maybe someone else ping 18:41:25 I'm going to add a question about whether it might make sense to make this a fork since it adds browser compat (either upstream or as a fedora subpackage) 18:41:33 That will serve a sa ping 18:41:52 #info abadger1999 to ping the ticket and ask additional question 18:42:16 this is different than the basis on which we approved the other three exceptions as it's not a code fragment. 18:42:44 #topic #358 Please make some autotools guidelines. 18:42:49 No draft so I'm closing htis now. 18:42:57 #topic #382 Go Packaging Guidelines Draft 18:43:01 https://fedorahosted.org/fpc/ticket/382 18:43:17 Last time we started discussing this, we ran out of time. 18:43:41 starting now seems like a bad idea 18:46:08 18:46:24 rjones added some information on how ocaml does things for comparison. 18:46:40 So get caught up on the reading and we'll get back to this topic next meeting 18:46:57 #topic #385 workarounds for rpm symlink <-> directory issue 18:47:00 This is on me. 18:47:34 I need to finish updating this ticket and hte /etc/shells ticket with things we want changed/added before we look at it again. 18:47:41 #topic #388 recommend %autosetup over %setup 18:47:45 https://fedorahosted.org/fpc/ticket/388 18:48:39 I really like the macro but am not entirely sure we should recommend one over the other. 18:49:04 I guess for templates we kind of have to pick something. 18:49:34 And if we put autosetup there we screw everyone who might want to branch for (older) EPEL. 18:50:05 The "oh, it doesn't work if we can't organize our patches cleanly" argument from comment 1 doesn't really hold water with me. 18:51:15 yeh, I'd just put a note about checking that it works in epel 18:51:28 But I have no problem recommending people use autosetup by default. 18:51:51 I mean if people just want latest fedora and epel-7 packages, it'll work everywhere. 18:52:01 Does use of autosetup -S $VCS automatically add a BR for the VCS? Or do we need to manually add the BR? 18:52:04 To me it's not so much what we recommend, but what we actually use in a template. 18:52:18 abadger1999: I was wondering about that as well. 18:52:43 abadger1999: AFAIK it doesn't add the BR … as it'd need to do that at another part of the specfile. 18:52:49 abadger1999: It just calls the correct commands. 18:53:12 okay 18:54:13 It could do so, though, I think. 18:54:26 I wonder why that wasn't done, because it's kind of an annoyance. 18:54:38 Especially since you can globally define a default SCM to use, I think. 18:54:59 Can ping Panu 18:55:21 I've yet to fully plumb what the scm setup stuff actually gets you. 18:55:29 -- I'll add him to the CC for the ticket and askthe question there. 18:55:32 Because if it gets you a lot, then that's what we should be recommending. 18:56:11 tibbs: As I understand it, the main thing it gets you is that you just add one line to add a patch, instead of two. 18:56:30 Well, you get that wuth autosetup. 18:56:49 Oh, right … what's the difference between using patch and git patch? 18:56:55 I mean, what benefits do you get by the scm repository being generated and all of the patches checked in to it. 18:57:09 I mean, I can guess, but I haven't seen how it actually impacts workload. 18:57:22 note -- I asked josh about a similar topic last week (someone asked me if we could require using git to apply patches) and he thought it would increase build times. For a large number of patches, it would increase by quite a bit. 18:57:25 I saw recent thread where people were saying that patch is very lazy about matching, and git patch isn't. 18:57:48 Because if we say "this is what you should use unless you can't" then all of our packager documentation can switch over to whatever magical patch stacking stuff this enables. 18:57:53 yes, patch cannot apply binary patch 18:58:01 I don't think git vs patch gets us much in the buildsystem. It might gain maintainers something if they're managing a set of patches and need to update them locally. 18:58:58 I don't think it does much at all for the buildsys, true. 18:59:02 I'm thinking more about workflow. 18:59:08 But that's not really a guideline thing. 18:59:09 RemiFedora: otoh, I'm not sure we'd want binary patches... might be better to just stick the binaries into the lookaside cache and cp %{SOURCEN} . 19:00:55 abadger1999, I have some patch with some reproducer for unit test, with small zip, mp3... file. And when you take the patch from upstream git, it's often simpler to apply this patch manually 19:01:20 rather than extracting the small file and add it separatly in source + patch for the code 19:01:21 #action abadger1999 to CC panu and ask whether we need to add buildrequires if -S VCS is used. 19:02:40 #topic Open floor 19:02:47 Okay, now we've hit two hours :-) 19:02:59 anything else people want to discuss today? 19:03:41 no, thank you 19:03:49 no, lunch for everyone :) 19:03:50 I'm sorry I keep showing up late. Lots of stuff going on right now. 19:03:57 tibbs: no problem 19:04:23 geppetto, diner for me ;) 19:04:35 :) 19:05:07 Thanks for coming everyone! 19:05:09 #endmeeting