15:01:33 #startmeeting Fedora Packaging Committee 15:01:33 Meeting started Wed Jul 20 15:01:33 2011 UTC. The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:33 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:01:38 Howdy. 15:01:39 #meetingname fpc 15:01:39 The meeting name has been set to 'fpc' 15:01:43 #topic Roll Call 15:01:46 hi 15:01:52 hi2 15:03:12 abadger1999, rdieter_work, SmootherFrOgZ, geppetto: fpc ping ? 15:03:25 * abadger1999 here 15:03:30 * limburgher here 15:03:45 abadger1999: is there still a board timing conflict? 15:03:59 spot: There is. 15:04:12 abadger1999: hrm. hopefully they will resolve it. 15:04:23 spot: But I'm telling them I'm not giving their meeting 100% today. 15:04:32 and hopefully we'll resolve it today 15:04:56 i count 6 of us, so, lets get started 15:05:03 * rdieter_work can be 1/2 here 15:05:11 #topic Outstanding tickets 15:05:29 As you may have seen, i spent the last hour or so doing writeups and announcing changes. 15:06:02 We didn't talk about it last week, but I did switch everything over to absolute paths on the scriptlets page. 15:06:15 tibbs|h: fantastic, that was my first question. 15:06:18 i'll close it out. 15:06:26 Except for one insteance of %{bindir} which I wanted to ask about. 15:07:01 okay, now would be a great time to discuss that 15:07:02 Right down at the bottom on a systemd-sysv-convert call. Not sure what we want to do about that one. 15:07:44 is there any reason not to change it? 15:07:44 Seems more consistent to just use /usr/bin like everything else. I don't see any benefit to using the macro there. 15:08:16 tibbs|h: are you talking about ticket #96? 15:08:21 I just wanted to make sure we weren't doing that for any specific reason. 15:08:27 Rathann: yes, this is ticket #96 15:08:56 tibbs|h: /usr/bin is fine with me 15:09:14 * spot thinks that change is fine 15:09:44 I fixed it up. 15:10:38 Okay, there are a few other tickets that seem to be stale 15:11:10 notably: Static Library PIC (#9) and %find_lang for packages that do not store their lang files in /usr/share/locale (#79) 15:11:28 tibbs|h: i think both of these are yours, at least in part 15:12:05 Yeah, my status there hasn't changed. 15:12:27 I'm hoping to have the majority of next week off. Maybe I'll have a chance to take a look then. 15:12:36 abadger1999: ticket #84 is a seemingly stale ticket of yours (Update Python Guidelines to mention that subpackages are not to be used for python26-* packages) 15:13:17 spot: k. I'll close that now 15:13:34 (update is going to epel guidelines) 15:14:20 the other draft tickets are both tabled (new filtering mechanisms #76, PIE #93) 15:14:42 geppetto: Could you take #76 or get panu to take it? 15:14:43 :-) 15:15:32 So, lets move on to our followup from last meeting 15:15:35 I need to stop wading into things I don't really understand. 15:15:42 #topic php libzip bundling exception 15:15:44 https://fedorahosted.org/fpc/ticket/62 15:15:54 tibbs|h: heh. If you don't, though, it doesn't get done at all :-/ 15:16:00 So, PHP really did a number on libzip. 15:16:48 they made notable changes to the API, including disabling safety checks and rewriting conditionals 15:17:39 we could not simply apply these changes to the libzip system lib, because it would break everything that isn't PHP 15:17:49 According to https://bugs.php.net/bug.php?id=39388, "most" of the fixes were upstreamed. 15:17:54 But that was in 2006. 15:18:11 and sounds like, some of them are "wrong" as well? (disabling safety checks) 15:18:34 abadger1999: i don't know, it is possible that some of these changes are correct and exist in cvs 15:18:43 i did not compare the code to cvs, only to 0.9.0 and 0.9.3 15:18:50 15:19:11 Is libzip upstream active? 15:19:20 tibbs|h: i believe so 15:19:34 0.10 released on 2011-03-18 15:19:59 their mercurial repo shows commits as of 7 weeks ago 15:19:59 I'm all over the place on this one. 15:22:09 So -- I'd be okay with bundling if we can write down why it's okay and apply it equally to other bundling situations that we've decided on in the past. 15:22:13 Given the security sensitive nature of this, I'd kind of prefer to have a full accounting of the differences. Was it ever determined whether the recent libzip security issue applied to the bundled one? 15:23:11 tibbs|h: From reading, not code analysis, the bundled library has the security flaw but php doesn't exercise the code path that it is on. 15:23:14 also a clear and current statement from upstream why they are opposed to using system library would also be nice 15:24:14 To be fair I haven't looked at whether all of the information we request has been provided, but I don't think I've seen any mention of what upstream libzip thinks of the situation. 15:24:26 okay, i will try to talk to libzip upstream 15:24:40 I mean, if we get "good" answers to all of our stock questions then I'm fine with granting exceptions. 15:25:05 But it seems most of the requestors go away when we start asking for that info. 15:26:12 * spot will poke this one with a sharper stick. 15:26:21 #topic Open Floor 15:26:31 For me the bottom line is that upstream is going to be the ultimate expert when it comes to their code. If they tell us the changes made are unsafe, I think it's fair to trust them. 15:27:49 SOrry i've been quiet, $DAYJOB exploded. Better now. 15:28:23 Has anyone had a chance to peek at https://fedorahosted.org/fpc/ticket/98? Is there anything I should add? 15:29:18 Well, I read it, but it's missing all of that info so I assumed it wasn't ready for consideration. 15:29:23 The usual reaction would be "do we have the answers to the questions that we ask all bundling requests" 15:29:41 Ok, I'll be more explicit and nag upstream. 15:31:15 This came up on list: http://lists.fedoraproject.org/pipermail/packaging/2011-July/007833.html 15:32:00 I'm not sure if that kind of thing generally requires us to do anything. 15:32:04 I haven't seen mclasen around to ask why he hasn't answered the questions. 15:32:07 Well.. 15:32:26 yeah, i don't know that we need to do anything there, unless we're doing something manually that this replaces 15:32:35 We don't really have any means to prevent folks from adding dependency generators. 15:32:43 Especially since rpm makes it so much easier now. 15:32:43 So I guess a question would be: who controls the rpm dependency namespace? 15:33:29 Do we want that? 15:33:59 I mean, we can probably just say "we do that". 15:34:23 Yeh, I guess we do … kind of … although I don't know of any rules for adding extra provides etc. 15:34:31 Yeah -- and if so, that would be what we'd want to decide here. 15:34:37 Like the erlang mess a few months ago 15:34:41 is typelib(foo) okay for this. 15:34:58 seems reasonable enough 15:34:59 I have to admit that I really have no idea what that message is talking about. 15:36:20 abadger1999: As you said "typelib" seems a bit generic … but I could still live with it 15:37:31 Does anyone know of anyplace else that typelib is used that could conflict i nthe future? 15:37:39 abadger1999: Was there no response to that message? 15:37:53 It hasn't gone in upstream gnome yet, so now would be the time to ask for namespacing. 15:38:03 abadger1999: google typelib gets quite a few hits 15:38:10 tibbs|h: There was no response to the message and I haven't seen mclassen on IRC to ping him. 15:38:59 abadger1999: http://sourceforge.net/projects/typelib/ :) 15:39:05 Honestly I don't know what a typelib is; I was hoping to see an answer to your request for a definition. 15:39:27 geppetto: Can we assume that's not at all the same thing? 15:39:47 tibbs|h: yes … hence the use of "typelib" is more than a bit generic 15:40:11 goi-typelib() or something is likely much better 15:41:10 Sounds good. 15:41:23 tibbs|h: As to what the Gobject typelib is … this is the best resource I can see: http://live.gnome.org/GObjectIntrospection 15:41:46 Basically an on file definition of the object, AIUI 15:41:49 I'll take the action item to add our request to namespace to the upstream bug. 15:42:39 Oh, joy, more XML. 15:47:10 okay, so... 15:47:21 unless there is any other topic in the next minute or two 15:47:25 i'll close this meeting out 15:47:43 nothing from me 15:47:43 Nothing from me. I really do hope to have more time soon. 15:48:14 Did anyone read Ville's systemd suggestions? 15:48:31 i tried to, but my brain started hurting and i had to lie down 15:48:52 heh. I was just typing out the same thing :-) 15:49:12 my inclination at this point is to leave well enough alone unless there are clearly identified bugs that need resolving 15:49:14 * abadger1999 hoping someone else would take it up for that reason. 15:49:16 Seemed to me that much of the issue involves how we adapted to people who might want to do their own crazy things. 15:49:42 of which, there are people who are doing those things. 15:49:56 le sigh 15:49:57 (including the sysv initscripts in addition to the systemd unit files). 15:49:59 I'm not sure I've seen an example. 15:50:11 But I wonder how many of those maintainers somehow think it's required. 15:50:33 There are lots of misconceptions flying around. 15:50:49 Viking-Ice's updates about how many services have switched over to systemd unit files includes lists of packages that include the sysv init script in addition to the unit file (in the same package and therefor, a bug). 15:50:54 which is a shame, because unit files really aren't that hard. 15:50:58 The other day someone thought that you couldn't convert to systemd at all unless your daemon supported socket activation, for example. 15:51:05 yeah. 15:51:21 o.O 15:51:26 * Rathann has to go 15:51:36 bye 15:52:25 okay, and with that, i'm going to go back to libzip. 15:52:28 thanks everyone. 15:52:31 #endmeeting