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