17:14:51 <spot> #startmeeting Fedora Packaging Committee
17:14:51 <zodbot> Meeting started Wed Dec 12 17:14:51 2012 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:14:51 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:14:54 <spot> #meetingname fpc
17:14:54 <zodbot> The meeting name has been set to 'fpc'
17:16:41 <spot> i count seven
17:16:45 <spot> so thats easily quorum
17:17:05 <spot> #topic Java
17:17:24 <spot> I know abadger1999 wanted to discuss the overarching question of whether arch-specific files in noarch packages should be allowed to use %{_prefix}/lib rather than %{_libdir}
17:17:42 <spot> But I don't want to block the Java draft on that, tbh.
17:17:54 <abadger1999> I think the discussion on list was a little "meh" but generally in favor of allowing.
17:17:59 <spot> FESCo voted to allow java to not be multilib
17:18:20 <spot> so I don't think there is any reason to not approve their draft changes.
17:18:26 <abadger1999> So maybe we can vote on that as a general policy and it would pass.
17:18:46 <spot> abadger1999: i'm fine with that approach as well.
17:18:54 <spot> abadger1999: can you word the proposal?
17:19:51 <abadger1999> "If a package is not multilib'd, then they are allowed to use %{prefix}/lib and %{_libdir} interchangably"
17:19:57 <abadger1999> Does that work and cover this case?
17:20:10 <tibbs> Not sure that makes sense.
17:20:22 <tibbs> You can't use them interchangeably since they don't have the same value.
17:20:29 <abadger1999> <nod>
17:21:03 <spot> I think perhaps "If a package is explicitly not multilib enabled, then it may use %{_prefix}/lib instead of %{_libdir}."
17:21:04 <limburgher> Maybe cut out "and" and after?
17:21:10 <limburgher> spot: like that.
17:21:15 <abadger1999> spot: +1
17:21:15 <tibbs> spot: +1
17:21:44 <spot> +1
17:21:47 <geppetto> I'm +1 … but it might be worth adding an explicit %{_noarch_libdir} or something.
17:21:51 <limburgher> +1 for clarity
17:22:14 <spot> that's +5. racor, Rathann, feel free to vote for the record.
17:22:21 <Rathann> why would it need to use %{_prefix}/lib in the first place?
17:22:54 <tibbs> The point is not to force the use of different locations between 32 and 64-bit if there's no reason for it.
17:24:01 <Rathann> hm, ok
17:24:05 <Rathann> +1 from me as well
17:24:07 <geppetto> Rathann: it's easier for them, and FESCO said they could.
17:24:36 <spot> #action "If a package is explicitly not multilib enabled, then it may use %{_prefix}/lib instead of %{_libdir}." is approved. (+1:6, 0:0, -1:0)
17:24:51 <spot> Given that, can we vote on the Java guidelines draft?
17:24:57 <tibbs> +1 for Java.
17:25:03 <spot> this is https://fedorahosted.org/fpc/ticket/222 (for reference)
17:25:04 <spot> +1
17:25:30 <racor> -1
17:25:39 <tibbs> The Java folks are really gettings to a sane point.
17:25:43 <spot> racor: is that to the first proposal or the second one?
17:26:31 <spot> (first proposal is the general case, second is to approve the java draft)
17:26:59 <racor> spot: Dunno, I was temporarily distracted. My vote is against any non-matching binaries in /usr/lib  == no exception for java
17:27:12 <spot> racor: okay, so -1 for both? :)
17:28:09 <racor> ... reading ... trying to catch up, sorry.
17:28:18 <limburgher> +1
17:28:43 <abadger1999> +1 for java
17:28:44 <Rathann> where's the %{_prefix}/lib vs. %{_libdir} in Java guidelines draft?
17:28:59 <Rathann> I only see %{_libdir} mentioned there
17:30:14 <spot> %{_jnidir} evals to %{_prefix}/lib
17:30:24 <spot> "{{admon/note|Macro expansions|<code>%{_jnidir}</code> usually expands into <code>%{_prefix}/lib/java</code>. <code>%{_prefix}/lib64/java</code> will cease its existence and will be decomissioned}}"
17:30:39 <Rathann> right
17:31:03 <spot> We're at +1:4, 0:0, -1:0 on the Java draft.
17:31:09 <spot> sorry
17:31:11 <spot> We're at +1:4, 0:0, -1:1 on the Java draft.
17:31:11 <racor> -1 to both ..., worse, I consider the general exeception "if cannot be multilib'ed, go /usr/lib" to be beyond reason. It's a card-blanche to allow all poorly designed crap to break the rules.
17:31:32 <tibbs> When the rules are pointless....
17:31:34 <geppetto> oh, sorry … +1
17:32:09 <geppetto> racor: I'd kind of agree … but we also shouldn't be saying we refuse to follow FESCO.
17:32:13 <racor> tibbs: ... or the devs behind the crap dumb.
17:32:23 <Rathann> +1 to Java guidelines
17:32:25 <tibbs> I see no dumbness here at all, honestly.
17:33:02 <spot> #action Java draft approved (+1:6, 0:0, -1:1)
17:33:09 <tibbs> lib64 was simply a hack to begin with.  Not that there was any alternative, but forcing it on things that have no reason to need it seems pointless to me.
17:33:25 <racor> geppetto: It should be our duty to be opposed, if FESCO is doing it wrong - Like in this case
17:33:49 <spot> Okay, lets move on.
17:34:24 <racor> tibbs: It's a card blanche, which allows any crappy app, whose devs did not spend a thought about multilibs, to go into fedora without modification.
17:34:28 <spot> #topic Github-like download URLs - https://fedorahosted.org/fpc/ticket/233
17:34:40 <racor> It essentially means abandoning multiarching.
17:34:48 <tibbs> That's completely untrue.
17:35:02 <tibbs> Java isn't multilib in Fedora.
17:35:15 <racor> tibbs: then lets agree to disagree.
17:35:24 <Rathann> I was under the impression that going non-multilib needs FESCO exception?
17:35:32 <abadger1999> We could clarify the wording "If a package has been given an exception to be explicitly non-multilibed"
17:35:40 <racor> tibbs: yes, java historically did not care about multiarching.
17:35:49 <spot> abadger1999: i'm not opposed to that.
17:35:58 <abadger1999> it's the present intention as I read it.
17:36:07 <tibbs> spot: So which part of that ticket are we actually going to vote on?
17:36:21 <spot> tibbs: that is not at all clear to me. :/
17:36:23 <geppetto> yeh, the intention is the same IMO, but the wording might be a little clearer.
17:37:01 * SmootherFrOgZ is late (sorry!)
17:37:09 <racor> tibbs: Provided Ubuntu goes multiarched, I wonder who they will treat java ... /me ducks ...
17:37:18 <spot> "If a package has been granted an explicit exception from FESCo to permit it to not be multilib enabled, then it may use %{_prefix}/lib instead of %{_libdir}."
17:37:33 <spot> ?
17:37:37 <geppetto> spot: +1
17:37:53 <abadger1999> hmm...
17:38:20 <abadger1999> The last (attachment) draft on the github proposal is poor.
17:38:42 <spot> can we get a quick show of hands on that rewording?
17:38:43 <abadger1999> Ubuntu was going multiarch in a different way than RH last I looked.
17:38:48 <abadger1999> +1
17:39:04 <Rathann> +1
17:39:34 <tibbs> The problem is that nobody's going to go FESCo for every Java package.
17:39:51 <spot> tibbs: i think that Java has already been given a blanket exception
17:39:56 <spot> which meets this criteria
17:40:02 <geppetto> tibbs: I assume the current FESCO exception for Java applies to all Java packages.
17:40:06 <spot> its not explicit-per-package, just explicit from FESCo
17:40:11 <tibbs> I sure hope it does.
17:40:15 <tibbs> Anyway, +1.
17:40:29 <abadger1999> "package or language stack"?
17:40:32 <tibbs> I guess if there's confusion, it defaults to "must use multilib" which is good.
17:40:39 * abadger1999 would vote +1 either way
17:40:45 <spot> +1
17:40:48 <spot> so that's enough.
17:40:51 <tibbs> I'd hate to get into what a language stack is.
17:41:01 <abadger1999> heh  Fair enough :-)
17:41:28 <spot> So, lets look at the Troublesome URLs change proposal in isolation for a moment
17:41:51 <racor> abadger1999: AFAICT, ubuntu's multiarching only looks different (differnent multi-subdirs), but otherwise is similar.
17:42:10 <spot> this is the second half of comment 6
17:43:33 <spot> that seems reasonably non-controversial to me.
17:43:35 <abadger1999> troublesome url update +1
17:43:39 <spot> +1
17:43:40 <tibbs> Is that actual intentional behavior of rpm?
17:43:55 <geppetto> abadger1999: What are we voting on … the last comment?
17:43:58 <racor> spot: Url?
17:44:12 <spot> https://fedorahosted.org/fpc/ticket/233#comment:6
17:44:23 <spot> but only the second proposal (Troublesome URL)
17:45:50 <geppetto> ok, +1
17:45:56 <tibbs> This is replacing http://fedoraproject.org/wiki/Packaging:SourceURL#Troublesome_URLs
17:46:07 <tibbs> I'm fine with it if RPM is actually intended to work that way.
17:46:30 <tibbs> But I'd hate to rely on something that just happens to work.
17:46:41 <geppetto> tibbs: all accidental features are intended, and will never break ;)
17:47:01 <tibbs> Poor Panu.
17:47:38 <spot> if RPM behavior ever changes here, we can always amend this to just use the fallback "comment URL and only list tarball name" method
17:48:10 <geppetto> I'll make sure Panu knows that the feature is being used.
17:49:07 <limburgher> +1
17:49:16 <spot> Okay, we're at +4 on this specific draft section.
17:49:32 <SmootherFrOgZ> +1 from me
17:50:04 <spot> racor, tibbs, Rathann: I don't see votes from you, we're at +5, feel free to vote for the record.
17:50:11 <tibbs> I thought I'd spend at least a couple of minutes hurting myself in the RPM source.
17:51:12 <tibbs> Oh god why does rpm bundle jquery.
17:51:17 <racor> tibbs: I am in a similar position as tibbs.
17:51:23 <spot> tibbs: because everything else does.
17:51:28 <spot> all the cool rpms are doing it.
17:52:00 <racor> how about asking panu, before voting?
17:52:22 <tibbs> I'm pretty much OK about it, but we should be prepared to back out of Panu complains.
17:52:37 * abadger1999 can agree with tibbs
17:52:40 * spot is perfectly happy to back it out if Panu is unhappy
17:52:48 <abadger1999> ie: approved but prepared to revisit if panu doesn't like it
17:52:53 <spot> abadger1999: yes.
17:53:07 <tibbs> I do wonder what spectool -g does with that, though.
17:53:28 <tibbs> Since it's in there, I assume someone actually tested it.
17:53:41 <racor> spot: I'd put it differently: We should consider this to be a proposal to Panu, and then wait for his feedback.
17:53:54 <tibbs> It sort of sounds like all of the support for this was put into things ages ago, and we just don't know where it's documented.
17:54:05 <abadger1999> tibbs: it does the right thing -- at first I thought it was a spectool-ism and was more sceptical but later found that rpm treats it that way as well.
17:54:22 <tibbs> I'm prepared to support this.
17:55:19 <geppetto> Given it's a feature that works everywhere, I think it's better to just +1 it … and I'll notify Panu tomorrow that policy is starting to rely on it
17:55:25 <spot> geppetto: i agree.
17:55:32 <tibbs> +1
17:55:40 <geppetto> If he twitches we can bring it up again later.
17:56:03 * abadger1999 still +1
17:56:19 <SmootherFrOgZ> geppetto: right.
17:56:26 <spot> Okay, so lets talk about the harder item: The github specific section
17:56:40 <spot> when i look at the long draft here: https://fedorahosted.org/fpc/attachment/ticket/233/slask
17:56:48 <spot> I'm okay with _most_ of it
17:56:59 <spot> the point I dislike is the use of the TAG as the Version
17:57:08 <spot> since that is very likely to be non-numeric
17:57:49 * abadger1999 agrees
17:57:58 <tibbs> Is it even guaranteed to be monotonic?
17:58:01 <limburgher> and non-sequential
17:58:19 <Rathann> agreed, it could be part of Release
17:58:48 <Rathann> following our naming and versioning convention
17:59:25 <spot> So i think this part needs to be rewritten, to be broken into two categories: github upstreams which use sane-numeric-versioned tags && github upstreams which do not use sane-numeric-versioned tags.
17:59:32 <geppetto> I kind of assumed tag was more like v1.0.1 or whatever.
17:59:42 <tibbs> Right, just blindly saying "use the tag" is bad; treating the tag as if it were the version in a tarball is reasonable.
17:59:59 <geppetto> fair enough, seems reasonable to me.
18:00:03 <tibbs> Because we already have plenty of rules about dealing with insane versions.
18:00:17 <spot> tibbs: yeah. part of me says "just read those and use common sense"
18:01:23 <spot> okay, i'll take a crack at writing something new here.
18:01:29 <tibbs> I'm honestly happy to have pretty much anything that talks about dealing with github.
18:01:32 <spot> we'll revisit that next week.
18:01:37 <tibbs> I would remove the "Increasingly" bit, though.
18:02:00 <tibbs> In two/five/ten years when tarballs are rare it will just sound dumb.
18:04:27 <spot> I'd like to try to do one more ticket (we started late, my apologies)
18:04:51 <tibbs> I'm still around.
18:05:01 <spot> #topic Bundling exception for forked copy of pyttsx in Openteacher - https://fedorahosted.org/fpc/ticket/234
18:05:53 * spot notes that pyttsx seems to be a dead upstream, no code changes in almost 3 years
18:05:59 <abadger1999> I'd like to know what the modifications are.
18:06:10 * Rathann too
18:06:12 <limburgher> Yeah, one line, 500 lines. . .
18:06:52 <tibbs> It really doesn't seem like we've been provided with the usual requested information here.
18:07:03 <limburgher> <nods>
18:07:27 <tibbs> Any communication with the maintainer of pyttsx (either upstream or in Fedora)?
18:07:39 <tibbs> Magnitude of the changes?
18:07:54 <limburgher> I'd say ask for that in the trac and move onward.
18:09:23 <Rathann> https://bugs.launchpad.net/openteacher/3.x/+bug/1074471 seems to contain some discussion about this
18:10:17 <Rathann> there are two other bundled packages as well in there: pydist and pyratemp
18:10:41 <Rathann> but upstream said they can be removed and system versions used
18:10:53 <spot> here's the diff: https://fedorahosted.org/fpc/attachment/ticket/234/openteacher-pyttsx-changes.patch
18:12:00 <limburgher> Hmmm.
18:12:32 <Rathann> it's the _whole_ diff?
18:12:43 <tibbs> So,,,, they didn't like one calling convention and decided a fork was a good idea?
18:13:03 <spot> Rathann: yep.
18:13:04 <limburgher> Looks that way.
18:13:19 <Rathann> -1 on the exception
18:13:48 <spot> "OT doesn't work correctly when importing submodules in the default Python way (which this text to speech library does if it's not adjusted)."
18:14:15 <spot> so its less of a "we prefer it like this" and more of a "if we do it the normal way, it doesn't work"
18:14:25 <limburgher> So. . .fix OT.  No?
18:14:36 * spot shrugs
18:14:47 <abadger1999> voice = moduleManager.importFrom(moduleManager.resourcePath(".."), "voice");
18:15:04 <abadger1999> Is that hte only real difference?
18:15:10 <spot> abadger1999: basically
18:15:22 <spot> and thats their alternate way to do "from ..voice import Voice"
18:15:25 <abadger1999> Maybe it's trying to load its own data files and needs to inject the path to that?
18:15:54 * spot doesn't know, probably isn't qualified to say, i haven't looked at openteacher at all
18:16:01 <spot> i just downloaded the two sources and made the diff
18:17:28 <abadger1999> <nod>
18:18:18 <abadger1999> I'm in a fesco meeting right now but I could look at this in the afternoon
18:18:23 <Rathann> last commit to pyttsx seems to have been in May 2011
18:18:42 <spot> abadger1999: alright, lets table this then.
18:19:11 <Rathann> I wonder if OT contacted pyttsx author about accommodating their needs
18:19:40 <Rathann> could be a matter of adding new API
18:19:48 <spot> I think we're done for the day, unless there is some other burning issue that we need to discuss this week.
18:19:55 <Rathann> ok
18:19:58 <Rathann> nothing from me
18:20:01 <tibbs> Probably not; judging from the attitude in that launchpad ticket.
18:20:20 <tibbs> I'm out.  Zero free time for the last few weeks anyway.
18:20:23 <Rathann> I have to drop off now
18:20:27 <spot> Thanks everyone.
18:20:28 <Rathann> thanks
18:20:29 <spot> #endmeeting