17:07:04 <abadger1999> #startmeeting fpc
17:07:04 <zodbot> Meeting started Thu Feb  6 17:07:04 2014 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:07:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:07:09 <abadger1999> #meetingname fpc
17:07:09 <zodbot> The meeting name has been set to 'fpc'
17:07:21 <abadger1999> #topic Roll Call
17:07:37 <abadger1999> Many people are travelling today.  I don't think we'll get quorum
17:08:11 <abadger1999> tibbs|h, SmootherFrOgZ: Going to discuss a ticket since the reporter is here.
17:08:37 <abadger1999> #topic bundled bootstrap binary exception for sbt https://fedorahosted.org/fpc/ticket/389
17:09:28 <ktdreyer> (I'm also here, if you can discuss the Heimdal bundling exception, #387)
17:09:38 <abadger1999> k
17:09:44 <willb> So the big obstacle to getting most of the interesting Scala projects in to Fedora is the absence of sbt, the simple build tool.
17:09:54 <abadger1999> willb:  So for sbt, would htis be a one time bootstrap?
17:10:05 <willb> abadger1999, once for each major release, probably
17:10:25 <willb> abadger1999, the model is that you can build a release with the last stable release
17:10:58 <willb> but in practice that seems to be a little more flexible most of the time
17:12:39 * SmootherFrOgZ here
17:13:32 <abadger1999> willb: Okay.  I think there's plenty of precedent to allow one-time bootstrapping https://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions
17:13:47 <abadger1999> willb: We don't approve ongoing bootstrapping as often but I think we have done that in the past.
17:14:12 <willb> abadger1999, great!  Do you have an opinion about whether it's better to go with the upstream binaries as the bootstrap binary or binaries I've compiled from upstream binaries?
17:14:30 <abadger1999> willb: If you've read that page, the rule is pretty much just that the package built with the prebuilt binary shouldn't go out to the repositories.
17:14:49 <willb> yes.
17:14:59 <abadger1999> willb: My opinion would be upstream binaries as then people can check them against what upstream is providing.
17:15:21 <willb> abadger1999, sounds good; that's what I'm doing now
17:15:51 <abadger1999> willb: Cool.  If you want to add a comment to the ticket that just clarifis those points, I'll ask for voting in ticket following the meeting
17:16:04 <willb> thanks!
17:16:10 <abadger1999> (Likely, we won't get enough votes until next meeting anyway but we can always hope :-)
17:16:17 <willb> I appreciate it
17:16:22 <SmootherFrOgZ> heh!
17:16:56 <abadger1999> #topic https://fedorahosted.org/fpc/ticket/387  -- Bundling exception: Heimdal bundles libtommath
17:17:22 <ktdreyer> I think the strongest point to be made is that both upstreams are aware that bundling libtommath a problem and they want to work to resolve it.
17:18:21 <abadger1999> ktdreyer: <nod> I like that part of the ticket :-)
17:18:37 <abadger1999> ktdreyer: Probably the best thing here would be a temporary exception of some sort.
17:19:26 <SmootherFrOgZ> yep, sound like the best plan as of right now.
17:19:26 <abadger1999> ktdreyer: If you could provide an estimate of when the tommath library will provide the second API and Hiemdal could start using it then we could approve an exception that expires then.
17:20:14 <ktdreyer> unfortunately Steffen is a volunteer, and in talking with him I get the sense that he's not paid to work on libtommath. What happens if he says "I don't know" for a timeframe?
17:21:08 <ktdreyer> As you probably saw in the ticket, the core problem is that libtommath lacks the developer resources to come up with an new implementation that will satisfy the Heimdal developers. There was some work in a WIP branch (described in the FPC ticket), but nothing close to production ready.
17:21:28 <abadger1999> ktdreyer: ideally, he could give a timeframe like 1 year (I think 2 releases is the longest we've made an exception for in the past).
17:21:48 <SmootherFrOgZ> abadger1999: right, then we revisit the exception.
17:21:51 <abadger1999> ktdreyer: barring that, we could still approve a 1 year exception on speculation that it could be done in a year.
17:22:54 <abadger1999> ktdreyer: <nod>... we don't want to end up in a position where a temporary exception ends up being carried forever because the work doesn't get done.
17:23:04 <abadger1999> ktdreyer: but we also understand the vagaries of open source.
17:23:37 <ktdreyer> right, I guess I'm concerned that it might not peter down to a stable libtommath release in one year
17:25:05 <ktdreyer> would it be ok to approve the exception without setting a date, and instead limit it to this specific situation?
17:25:49 <abadger1999> ktdreyer: <nod>  Since this is definitely security sensitive code... we don't want bundling to go on indefinitely so a time limit is improtant in that respect.
17:25:59 <abadger1999> ktdreyer: I think there's been one time that we've done that.
17:26:11 <ktdreyer> "when libtommath supports a mp_expt_d() that Heimdal can use, then Heimdal must unbundle libtommath"
17:26:17 <ktdreyer> something like that?
17:26:27 <abadger1999> ktdreyer: But if that's the only time... then we also specified that the package maintainer had to be someone that could work on the bundled code.
17:26:50 <abadger1999> we might have done it more often though...
17:26:57 * abadger1999 takes a quick look at the exception page
17:30:54 <abadger1999> ktdreyer: I see two cases where we don't have a timeframe.  One of them is the one I mentioned (boost in passenger) where we required that the maintainer be capable of fixing bugs in the bundled code, updating to newer versions of the bundled library, etc
17:31:25 <abadger1999> I'll note that in that case the upstream project wasn't nearly as amenable as the two upstream's you're talking about here.
17:31:32 <ktdreyer> yeah, I was thinking of the passenger example as well when I wrote my ticket
17:31:44 <ktdreyer> that one was memorable :)
17:32:04 <abadger1999> ktdreyer: the other case looks like our oldest temporary exception... I think we jsut didn't realize that we should specifiy a timeframe for that one.
17:32:09 <abadger1999> Yeah :-)
17:33:13 <abadger1999> ktdreyer: Is it possible to only bundle the one function that has the difference?  Or is that function used by other code internal to the library?
17:35:13 <ktdreyer> looking through my #libtom logs... it's my understanding that the function is not trivial to separate out. For example Heimdal is actually using mp_n_root, which calls this function
17:35:28 <ktdreyer> so it's a couple layers down
17:36:57 <abadger1999> <nod>
17:37:46 <ktdreyer> you can see here the attempt to bring back the old behavior: https://github.com/libtom/libtommath/commit/c31e15b313c93473293b33b6a841b9717963d65a
17:38:23 <ktdreyer> unfortunately that's just adding ifdefs, so it's determined at compile-time, and we'd need it to be changed to a run-time option
17:38:57 <ktdreyer> it would involve an API change, and maybe a change to the mp_n_root function as well
17:38:58 <abadger1999> <nod>
17:39:22 <abadger1999> yeah -- it would probably need to be an added flag all the way up the API
17:39:29 <ktdreyer> right
17:41:14 <SmootherFrOgZ> hm.. I think we can work something out here to make it optional at run-time though
17:41:44 <abadger1999> ktdreyer: Are you capable of fixing code problems? (like we required for the passenger bundling)?
17:42:01 <abadger1999> SmootherFrOgZ: Like an environment variable that determines which code path is followed?
17:42:43 <ktdreyer> if there are security problems in the bundled library, I'd need to rely on the Heimdal developers, who would probably be just as responsive to them as Fedora would need to be
17:43:07 <abadger1999> <nod>
17:43:17 <SmootherFrOgZ> well, not really but this would work too.
17:44:44 <abadger1999> ktdreyer: okay... I think I'd vote for a temporary exception based on the feature going upstream but I'm not sure if we'd have the necessary +1's to approve.
17:45:13 <abadger1999> ktdreyer: so we'll have to wait until we have quorum for more discussion and a final decision
17:45:17 <SmootherFrOgZ> I see only 2 +!1 here :)
17:45:32 <ktdreyer> that's fair. Thanks. I'm around to answer any other questions about this
17:46:21 <ktdreyer> thanks a lot abadger1999 and SmootherFrOgZ for your time and consideration
17:46:35 <abadger1999> ktdreyer: thanks for coming.
17:46:54 <abadger1999> Hopefully people will be done with their travelling next week.
17:47:26 <ktdreyer> if the issue's still open at that time, I'll try to make next week's meeting too
17:48:04 <racor> ktdreyer: May-be it already had been considered and I am missing sth., but ... has it been considered to replace the original libtommath with heimdal's, rsp. is heimdal's libtommath compatible to the original libtommath?
17:49:48 <ktdreyer> racor: unfortunately I don't think that would be feasible for the reasons outlined in https://fedorahosted.org/fpc/ticket/387 , "In theory Fedora could revert upstream's optimization commit, but my current opinion is that Simone shouldn't do this for three reasons."
17:52:15 <racor> ktdreyer: OK, if you say so. I am not sufficiently familiar with the code to have an opinion.
17:52:28 <ktdreyer> the crux of the problem is that some libtommath consumers are going to want a "slow, secure" API, and others (eg Rubinius) don't care about having the computational time be linear because it's not cryptographically relevant
17:53:01 <ktdreyer> racor: no, that's fine, thanks for asking
17:56:42 <abadger1999> #topic Open floor
17:56:53 <abadger1999> We have three FPC members present now :-)
17:57:01 <abadger1999> anyone want to bring something else up for discussion?
17:57:48 * SmootherFrOgZ has nothing more
17:59:06 <racor> abadger1999: what's the situation of the headers-only packaging changes
17:59:44 <abadger1999> racor: I think we approved them but I need to add the writeup to the wiki.
17:59:52 <abadger1999> Unless someone else wants to write them up first.
17:59:56 <racor> abadger1999: I thought we had voted on it, but when encountering such a package recently, I could not find it in the FPG
18:00:28 <racor> abadger1999: Ah, ok.
18:00:42 <abadger1999> racor: Yeah -- I hopefully updated the ticket... but around Christmas, I did miss adding ticket notes from the meeting logs so I have to go back and check that too.
18:01:28 <abadger1999> racor: You can point people to the ticket if that's updated.  If not, I'm lagging behind because of the SCL work but I'm going to try to clear out that queue of things today and tomorrow.
18:02:20 <racor> abader1999: ticket no. at hand?
18:12:22 * abadger1999 looks
18:12:50 <abadger1999> https://fedorahosted.org/fpc/ticket/337
18:12:57 <abadger1999> racor: Looks like I didn't update that ticket.
18:13:07 * abadger1999 looks at whether he updated the other, static library ticket
18:15:49 <abadger1999> racor: alright -- looks like atm the decision is only in the meeting logs.
18:16:07 <abadger1999> I'll have to get around to pulling that information into the ticket and into the guidelines today or tomorrow.
18:17:13 <abadger1999> Anything else?
18:17:21 <abadger1999> Oh -- scl update:
18:18:19 <abadger1999> I've got builds of a python2.4 scl stack.  I'll upload those and the srpm/spec files I started with to my fedorapeople space this week for people to look at.
18:18:28 <abadger1999> The changes are somewhat invasive.
18:18:50 <abadger1999> I've talked with jzeleny and bkarbrda about some of the issues I encountered.
18:19:29 <abadger1999> I think we may have to create two separate scl-utils packages or something... one that can build scls compliant with fedora and another for building rh scls.
18:20:19 <abadger1999> there's a few changes to the guidelines that will need to be merged from what I've discovered by building these packages; I've merged a few not so hard changes already.
18:21:28 <abadger1999> I think I should build something like mariadb and some language bindings for it since there's some cases that I noticed would effect those types of packages but did not encounter in doing this python2.4 stack.
18:21:39 <abadger1999> (like statefiles cannot end up in /opt)
18:21:59 <abadger1999> Okay,  if nothing else, I'll end meeting in 1 minute
18:23:03 <abadger1999> #endmeeting