15:58:43 #startmeeting Fedora Packaging Committee 15:58:43 Meeting started Wed May 9 15:58:43 2012 UTC. The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:58:43 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:58:48 #meetingname fpc 15:58:48 The meeting name has been set to 'fpc' 15:58:52 #topic Roll Call 15:59:17 * limburgher here 15:59:17 Howdy. 16:01:54 abadger1999, rdieter_work, Smoother1rOgZ: ping 16:02:15 yo 16:02:39 * geppetto is here 16:03:30 well, thats quorum. i'll give abadger1999 and Smoother1rOgZ a minute or so to join 16:04:56 * abadger1999 here 16:06:14 #topic Better elaborate placement of RubyGems binary extensions - https://fedorahosted.org/fpc/ticket/168 16:06:40 This one seems like a clarification, as opposed to a change in practice, so i'm inclined to say "easyfix, +1" 16:07:09 I agree. 16:07:22 +1 16:08:00 So, i'm officially +1. :) 16:08:14 +1 16:08:24 We should always feel free to clarify things when the guidelines are confusingg. 16:08:52 counting tibbs agreement as a +1, we're at +4 16:09:28 +1 16:09:58 limburgher: if you'd like to go on the record, now would be an excellent time to do so. :) 16:10:34 #action Clarification approved (+1:5, 0:0, -1:0) 16:10:47 +1 16:10:52 Sorry, distracted. :( 16:11:09 #topic Need Guidelines for packages with restrictive trademark licensing - https://fedorahosted.org/fpc/ticket/170 16:11:26 Yes, we do, but I'm pretty sure this falls into Fedora Legal's domain and not the FPC. 16:11:55 if anyone disagrees that this should be Fedora Legal's responsibility, please feel free to speak up. :) 16:11:59 I certainly don't want to wade into legal issues. 16:12:04 Yeah, shouldn't the BZ just block FE-LEGAL? 16:12:16 well, that much of a workflow is clear 16:12:27 We can add a link from the packaging guidelines to the legal guidelines if folks are missing it, I guess. 16:12:36 but it would be nice to have some sort of legal guidelines clarifying what is acceptable wrt a trademark license 16:13:10 legal++ 16:13:12 No problems there. 16:13:20 Just send it to you then? ;-) 16:13:28 abadger1999: i will point you to the legal trac. :) 16:13:34 hehe 16:14:03 I certainly don't envy the person who has to draft reasonable guidelines in that area while still allowing us to ship firefox. 16:14:22 * spot opens another bottle of beer 16:14:26 IceWeasel … :-o 16:14:36 tibbs|h: We can always rename to iceweasel if it's impossible to do that ;-) 16:14:47 #topic Applying for bundling exception: python-trml2pdf in openerp-server - https://fedorahosted.org/fpc/ticket/171 16:15:01 luke-warm ferret 16:15:07 I think this is something we haven't come across before. 16:15:09 spot: Do you want that in fedora-legal trac or on the legal mailing list? 16:15:10 i've been thinking about this one for a while now 16:15:18 abadger1999: the fedora-legal trac, please. 16:15:26 will od 16:15:28 *do 16:15:42 epinephrine, stat. 16:15:53 :-) 16:16:01 my summarized feelings here are this: we should strive to ensure that the packages we offer in Fedora are as useful and up to date as possible 16:16:53 so the situation we have now where the packaged python-trml2pdf is old and outofdate (and used only by one other package) seems... poor 16:17:22 i'd much rather either see that package renamed to python-trml2pdf12 or give satchmo (the user package) a bundling exception for it 16:17:31 So in effect we have two projects that want to consume two diverging versions of a dead upstream? 16:17:52 repoquery --whatrequires python-trml2pdf => empty ? 16:17:56 and allow the python-trml2pdf that is maintained (by OpenERP) to be in python-trml2pdf 16:18:16 rdieter: i think satchmo uses it, possibly only as a BR? 16:18:16 rdieter: The requiring package isn't even in the distro. (Maybe in the future, I think.) 16:18:23 spot: oh, ok 16:18:37 Or maybe I'm wrong. 16:18:39 oh,nm, tibbs is right 16:18:39 limburgher: mostly correct -- from the trac ticket, it looks like upstream for the library is the same as the second applicatoin (openerp) 16:18:44 satchmo never made it into Fedora 16:19:01 * rdieter prefers the 'allow bundling' option here 16:19:26 limburgher: so viewed in one way, they (openerp) aren't bundling... they've just chosen to fold their code from a library layer back into the application. 16:19:39 abadger1999: Nod. 16:19:42 If we allow bundling we should consider giving guidance on what should happen to the existing package. 16:20:03 yeah -- the existing package and satchmo if it gets in. 16:20:29 * spot almost prefers to see existing python-trml2pdf renamed to python-trml2pdf12 and the maintained OpenERP version moved into python-trml2pdf 16:20:46 abadger1999: This essentially the same as statically linking against a bundled library in other languages 16:20:47 spot: I like that. 16:21:07 just because it seems silly to have a python-trml2pdf that is an old fork, in case someone tried to use it 16:21:25 Another consideration is that python-trml2pdf includes an executable. 16:21:34 So it's actually kind of misnamed. 16:21:42 spot: Right, nothing about the name says "Old and crufty", but if I saw two I'd know which one I wanted. 16:22:00 Does the replacement include an executable? Might someone be relying on having that executable around? 16:22:24 tibbs|h: i thought that was something different? 16:22:47 Not sure what you mean. 16:22:52 nm. 16:22:56 racor: not really -- the code isn't being bundled at build time. it's being bundled when the tarball is released by upstream. 16:23:15 dealing with co-installability isn't really within the scope of what we're discussing here, is it? (ie, lets not get lost in the weeds) 16:23:19 racor: oh sorry --- I see 16:23:25 well, clearly, no one Requires python-trml2pdf now, so if they need the executable, they can Requires:python-trml2pdf12 just as easily. 16:23:51 racor: you said "statically linked against a bundled library" -- I misread and missed the bundled library part. 16:24:17 rdieter: given that this is python, it shouldn't be terribly difficult to adapt the older package to avoid conflicts 16:24:40 especially given that nothing in Fedora uses it currently (and it would be a very simple patch for future satchmo to adjust to it) 16:24:45 Do we even need to provide the old one? 16:24:56 If python-trml2pdf was moved to the openerp version, it would need to use the openerp tarball as it's Source. 16:25:03 spot: true, I'm just arguing that should not concern us (at the moment, at least) 16:25:13 and then copy the code from there and install it manually to the correct location. 16:25:17 abadger1999: alternately, the openerp tarball could generate python-trml2pdf 16:25:23 s/tarball/srpm 16:25:25 yeah 16:25:31 that's an option. 16:25:33 which i think i like better, tbh. :) 16:25:40 still have to manyally copy it to the correct location 16:25:46 * spot nods 16:25:52 but there is less risk of source divergence 16:25:55 spot: +1 16:25:59 16:27:08 So, i propose the following: The existing python-trml2pdf package must either be renamed to python-trml2pdf12 or retired. OpenERP must generate a python-trml2pdf subpackage (placed in the proper python site-packages path). 16:27:10 I'm +1 tto allowing openerp to contain this library and also +1 to the present python-trml2pdf moving to python-trml2pdf12... not sure about making the openerp maintainer create a python-trml2pdf subpackage. 16:27:12 openerp isn't concerned with the public api here I thought? generating a python-trml2pdf from it seems unwise to me 16:27:29 rdieter: perhaps, but they are the upstream 16:27:45 * rdieter would rather simply allow the bundling and be done with it then 16:28:46 but, if agree'ing to making a python-trml2pdf pkg out of it is what it takes to get consensus here, +1 either way 16:29:23 Pretty sure we don't have any API requirements on anything, esp. so on python stuff. 16:29:24 * spot would not lose much sleep over the openerp bundling with no subpackage, as long as the existing package either renames or retires 16:29:46 I think it's better to make it a sub-package. 16:29:55 geppetto: i lean in that direction as well 16:30:08 +1 without the need for the openerp maintainer to agree to the subpackage. Also okay with requesting that he consider making a subpackage but not make it a requirement. 16:30:10 +1 subpackage, rename old. 16:30:18 +1 16:30:18 seems like a waste to make subpkg no one will use, and that upstream doesn't want, but meh 16:30:32 okay, lets do this 16:30:57 * rdieter thinks that should be the pkg maintainers ultimate call, not ours 16:31:01 So, i propose the following: The existing python-trml2pdf package must either be renamed to python-trml2pdf12 or retired. FPC ask the openERP maintainer to consider making a python-trml2pdf subpackage (placed in the proper python site-packages path), but is not required to do so. 16:31:26 * rdieter likes that much better, thanks, +1 16:31:29 Works for me. +1 16:31:40 * spot is +1 16:31:45 +1 16:32:33 +1 16:33:36 * spot is waiting on racor and limburgher to vote on this proposal 16:33:53 0, I am hesitant. Doing the opposite (force openerp to rename their subpackage) would be less intrusive and more respectful (spot's proposal can be interpreted as sanctioning a hostile take-over) 16:34:33 There's no takeover; the upstream of both sources is the same as far as I understand things. 16:34:52 I think he means the downstream maintainers 16:35:25 rdieter: I mean those individuals, who are providing the source tar balls. 16:35:37 It's the same people in both cases. 16:35:38 ok, nvm 16:36:11 tibbs|h: Then, there'd be another option: Ask them to clarify the situation. 16:36:59 +1 16:37:05 #action The existing python-trml2pdf package must either be renamed to python-trml2pdf12 or retired. FPC asks the openERP maintainer to consider making a python-trml2pdf subpackage (placed in the proper python site-packages path), but is not required to do so. (+1:6, 0:1, -1:0) 16:37:45 Yeah -- if the situation isn't as represented in the ticket, I'm willing to vote differently. 16:38:06 I see that our tarball for python-trml2pdf is from the satchmo upstream website 16:38:38 if someone wants to investigate this and reopen the ticket, feel free. 16:38:56 but it looks like they took a snapshot of the original upstream to get that tarball (I assume from our ticket, that those people would be openerp) 16:39:01 it seems like the reporter has done due diligence on the situation, nor am i inclined to distrust the ticket info 16:40:48 #topic Open Floor 16:41:54 Nothing from me. 16:42:09 Nope. 16:43:31 Nothing here 16:44:03 spot: Is the legal trac setup so that people on the CC can view tickets? 16:44:16 abadger1999: i think so, yes. 16:44:38 k /me adds the current CC list and invites others who find the FPC ticket to request to be put on the legal CC. 16:48:17 Oh, just a celebreatory FYI: It looks like zlib will finally be unbundled from rsync :-) 16:48:36 Wow, finally. 16:48:53 nice 16:49:08 and with that, we're done, thanks everyone. :) 16:49:10 #endmeeting