15:06:45 #startmeeting Fedora Packaging Committee 15:06:45 Meeting started Wed Jun 1 15:06:45 2011 UTC. The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:06:45 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:06:48 #meetingname fpc 15:06:48 The meeting name has been set to 'fpc' 15:06:52 #topic Roll Call 15:07:07 Howdy. 15:07:15 * spot is here 15:07:29 * abadger1999 here 15:08:01 here 15:08:29 rdieter_work, limburgher, SmootherFrOgZ: ping 15:10:39 * spot does a little dance 15:10:41 * limburgher here 15:11:00 okay, that is quorum 15:11:15 #topic Perl INC changes 15:11:37 just a quick update here, i'm still talking to people, so far, i have no more insight than before. 15:12:31 #topic filter_requires_in has started to match against paths prefixed with %buildroot - https://fedorahosted.org/fpc/ticket/87 15:12:52 I wonder when rpm changed. 15:13:13 * spot shrugs, maybe 4.9 ? 15:13:57 According to the linked bug it's changed in F14 as well (so something in the 4.8 series). 15:14:03 Not that it really matters. 15:14:05 tibbs|h: you proposed a change which seems sensible, but i'm not sure where you intended it to go 15:14:29 here now too. 15:14:36 In the current document on the filtering stuff, after the "Location of macro invocation" bit. 15:14:47 ah, okay, i see that now 15:15:25 so, i'm +1 to the change proposed in ticket 87 15:15:37 None of our examples need to change, so we're good there. 15:15:55 +1 15:15:58 +1 15:16:05 Although somehow what I proposed ended up somewhat mangled in trac. 15:16:17 I wonder what I did. 15:16:19 wfm and some day we'll get the new stuff documented. 15:16:20 +1 15:16:27 tibbs|h: trac hates us all. 15:16:47 so, that is +5, tibbs, if you'd like to vote on your own proposal... :) 15:16:51 +1 15:17:02 err, that was +4. 15:17:03 The mangled text is "^" (including the quotes). 15:17:14 its +5 now. 15:17:19 Which trac interpreted as a superscript. 15:17:25 geppetto: you're the missing voter. 15:17:28 yeh … +1 15:17:48 #action approved draft (+1:6, 0:0, -1:0) 15:19:47 hi all, sorry for being late 15:19:52 connection trouble 15:19:55 Rathann: no worries 15:20:12 tibbs|h: any updates on the other filtering draft? 15:20:26 (ticket #76) ? 15:20:31 Well, there was one set of comments I need to address. 15:20:55 Sadly it looks like using them complicates things quite a bit. 15:21:28 Other than that, no. 15:21:39 okay, we'll keep tabling it until it's ready 15:21:55 there are a few pending bundling requests 15:22:02 Might as well just perma-table it until I can get some movement. 15:22:44 Lets look at the OpenERP ones 15:22:59 #topic https://fedorahosted.org/fpc/ticket/88 - Permission to ship OpenERP with bundled SpiffGtkWidgets 15:24:02 my instinct here is to grant the temporary permission, given that the code is already merged in upstream source control 15:24:05 That seems to be missing some of the stuff we ask for. 15:24:07 I don't suppose they could migrate the functionality either to in-project code or external non-dead upstream projects? 15:25:31 What I'm confused about is what is stopping a SpiffGtkWidgets package? 15:26:05 Apart from that, it seems fine 15:26:05 * rdieter_work agrees with spot 15:26:58 So we don't have a separate package already? 15:27:10 geppetto: thats a good point, i had assumed there was a separate package, but i don't see one 15:27:10 for the widgets package the want to bundle? 15:27:26 not that I can see 15:27:37 Seems like getting that would be one step. 15:27:45 given that there is no separate package, it seems like an easy fix would be to package up the current upstream trunk 15:27:58 (lack of package means no one else is affected) 15:28:00 Then the question becomes one of why that that package couldn't just carry the patched stuff and eliminate the issue altogether. 15:28:05 * geppetto nods 15:29:05 So, i propose that we deny this request, and advise them to create a separate SpiffGtkWidgets package based on the trunk code (with the needed OpenERP changes applied). 15:29:34 Agreed, though that does assume that upstream of the widgets package is OK with that. 15:30:01 * spot is +1 to his proposal 15:30:08 I guess since they've accepted the patches that shouldn't be a problem. 15:30:11 +1 15:30:48 +1 15:30:53 +1 -- willing to reconsider with more information. 15:31:31 +1 15:31:36 +1 15:31:50 +1 - if changes are approved already, there's no reason for an exception unless upstream head is highly unstable 15:33:50 #topic Permission to ship OpenERP with bundled "faces-project" - https://fedorahosted.org/fpc/ticket/89 15:34:20 This one seems reasonable. 15:34:47 But again, all of the requested information hasn't been provided. 15:35:01 Or, sorry, not all of the requested information has been provided. 15:35:15 I agree that it looks reasonable 15:36:13 tibbs|h: what is missing? 15:36:15 Reasonable -- would want a proposed timeline and xrg to commit to packaging faces-project 15:36:33 abadger1999: i agree 15:36:35 even if the timeline is 1 year, it gives us a way to check up on the status. 15:37:08 Well, we ask nine questions. 15:37:33 so, err again, given that there is no "faces-project" in Fedora … why the bundling? 15:37:46 That's the second question we ask, which they did not answer. 15:37:50 :) 15:37:57 geppetto: which fork should be packaged? 15:38:10 The one openerp happens to need. 15:38:12 spot: The one which is used by something :) 15:38:25 At some point utility has to win out over something. 15:38:52 Now, there's a real question as to whether arbitrarily choosing a fork to package is better than bundling. 15:38:59 I'm with tibbs|h , ping back to answer all of https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Standard_questions so we can evaluate more fully 15:39:19 * spot has no problem asking for the full data before we decide here 15:39:29 so, i'll do that. :) 15:39:36 tibbs|h: Not really … it might become a similar problem if something ever needs the other fork … but we can hit then when we hit it 15:40:20 So far we've come down on the side of bundling being worse than having to pick a fork. 15:40:25 Which is fine with me. 15:40:34 geppetto: true, hopefully the aditional "urgency" can get things merged and working together more quickly, but that's probably a bit optimistic 15:40:41 * geppetto nods 15:40:44 Both packages will have to evolve together, but that's pretty simple when there's only one user. 15:40:45 geppetto: even better, ask xrg if he has a plan for dealing with that if/when it happens 15:40:50 Okay, lets move on to the last one, this one is a little more fun. 15:41:07 #topic Permission to ship OpenERP with bundled "pyftplib" - https://fedorahosted.org/fpc/ticket/90 15:41:16 pyftplib is packaged in Fedora 15:41:24 yeh, given that they've changed huge parts of this I'm happy to just treat it as new code 15:41:31 err, this is pyftpdlib 15:41:47 Well, have they really changed huge parts of this? 15:42:14 it is described as "heavily modified" 15:42:15 it seemed like it, but I haven't looked … all the IO has to be different etc. 15:42:18 Also, don't we at least ask for some feedback from the maintainer of the package that's been forked. 15:42:23 Yeah, are there examples of patches to 0.4.0? Are they really not applicable to 0.6.0 or just "hard"? 15:42:33 Yes, we do. That's question 7. 15:42:56 Okay, let get the full set of information here too. 15:43:03 tibbs|h: :) … I'm happy to require them to answer the questions we require people to answer :) 15:43:21 :) 15:43:33 okay, thats it for pending tickets 15:43:37 #topic Open Floor 15:44:18 For the pyftplib, ask clarification of whether the openerp maintainer is okay with leaving the ftp functionality out in the Fedora package. 15:44:23 It seems like he might be. 15:44:29 and that would be fine with me. 15:44:54 abadger1999: feel free to add that to ticket 90 15:44:59 will do. 15:45:00 It would be bad to needlessly disable functionality, I think. 15:45:04 There's a balance to be struck. 15:45:18 well... he talks about ftp being used to send private data insecurely. 15:45:23 We do want people to actually be able to use the functionality. 15:45:28 But FTP is insecure in general. 15:45:38 tibbs|h: Agreed, but I think we need to see that that's really warrant. If the patches are easy to do. . . 15:46:01 so it's not like it isn't icky... and pyftplib-0.6.0 adds ftps support so it may be that it should be disabled until it is ported. 15:46:10 But also heavily used in legacy systems, and in the types of software ERP often needs to talk to. 15:46:14 Sure; right now we don't know how to strike a balance because we don't have enough information. 15:46:19 15:47:00 Let's see --- mono revision is on the horizon/already being asked for comments. 15:47:15 Yeah. 15:47:50 i read the mono revision, and as distasteful as i find it, it seems acceptable enough. 15:48:06 basically, the chkr has finally gotten upstream mono to take a stand that C# assemblies should be arch independent and code that makes them arch independent should be treated as bugs. 15:48:07 is there someplace I can read more about the pyftplib request? 15:48:16 I thought I had pretty good recollection of the original mono discussion. 15:48:22 Jeff_S: https://fedorahosted.org/fpc/ticket/90 15:48:22 Jeff_S: All we have is that ticket. 15:48:35 Jeff_S: All that we have is in ticket 90 and in the bugzilla review of openerp: https://bugzilla.redhat.com/show_bug.cgi?id=693425 15:49:01 abadger1999: you mean code which makes them not arch-indepedent is a bug? 15:49:17 thanks everyone :) 15:49:20 geppetto: That's right. thanks for the correction. 15:49:38 Ok … so are they happy to use /usr/share … or do they still want /usr/lib ? 15:49:47 they still want /usr/lib. 15:49:58 Do they say why? 15:50:02 chkr does make a reasonable interpretation of the FHS to support using that. 15:50:27 The thing about libraries != ELF libraries? 15:50:34 seems a stretch, to me 15:50:50 from the fedora packager side, it's because upstream wants /usr/lib; from the upstream side, I don't think there is a real rationale. 15:51:21 * geppetto shrugs … we do let python do the wrong thing … so it's not the end of the world 15:51:38 Well, we keep missing opportunities to fix that even though we've talked about it. 15:52:00 it's getting to the place where mono's been around enough years that python and perl grandfathering becomes a valid precedent :-/ 15:52:01 But "well, we screwed up there so we should screw up elsewhere" is rarely a good argument. 15:52:32 yeh … and I don't really like the argument of "upstream are being stupid, but stubborn, so we should let them" 15:52:43 But abadger1999 does have a point 15:52:52 I'd like to hear what Ralf has to say, as someone who has read the FHS far more than I have. 15:53:21 Anyway, the matter isn't really before us yet so we have some time. 15:53:25 * spot nods 15:54:54 if there are no other items, i will close out the meeting in a minute or two 15:55:21 Nothing from me. 15:56:13 okay, thanks everyone 15:56:15 #endmeeting