16:07:12 #startmeeting Fedora Packaging Committee 16:07:13 Meeting started Wed Feb 24 16:07:12 2010 UTC. The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:07:14 ok, no bot. i guess we'll log this old-school. :) 16:07:15 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:07:16 Roll Call: 16:08:26 aha, there goes the bot 16:08:28 maybe i'm just lagged 16:09:00 racor, rdieter, tibbs|h: ping 16:09:09 hiya 16:09:13 Yep. 16:09:14 here 16:09:42 i don't see limb, abadger1999, Rathann, hans, or SmootherFrOgZ 16:10:36 but... we do have abadger1999's votes via email 16:11:00 so, we might be able to get some things done, assuming we count that as quorum on those issues 16:11:22 Don't see why we can't at least discuss things. 16:11:37 okay, lets start with item 1 16:11:41 #topic https://fedoraproject.org/wiki/Fix_Complex_Font_Template%28draft%29 16:12:32 The whole font thing still warps my brain. So much complexity. 16:13:34 tibbs|h: indeed 16:13:43 But I don't see how just putting the macro at the same place in the two templates could be a bad thing. 16:14:04 tibbs|h: yeah, i'm inclined to agree with you 16:14:30 I suppose we can assume that this has actually been tested. 16:14:46 i'm pretty sure it has been tested. 16:15:26 Was there input from the font people (besides all of the flaming)? 16:15:29 just move it then 16:15:55 the only real input was that it would require package changes to be compliant with the template change 16:16:34 nim-nim seemed to prefer that we added a dummy %_font_pkg macro to redhat-rpm-config instead 16:16:49 which would evaluate to %{nil} if not already defined by fontpackages-devel 16:17:03 Any particular reason that's not in the draft? 16:17:19 it is, per 16:17:20 not sure, i just saw it in bz 564613 16:17:25 as suggested by Panu 16:17:36 but not mentioned explicitly 16:17:55 * spot is not opposed to that solution either 16:17:55 Don't see how that relates to "Fix the tools". 16:18:23 It seems like less of a patch job to just tweak the packages, but then we're used to papering over all sorts of things. 16:19:36 nim seemed not happy to have to do any work changing stuff, and the fake %_font_pkg macro in redhat-rpm-config is one way to achieve that 16:20:11 well, i'm inclined to go with the macro fix for now, especially given that the longer term fix of section end markers is being worked on at some point in the distant future 16:20:35 Well, with a system as complex as all of the font templates, assuming that we'd never find any problem with it after approval is incredibly optimistic. 16:21:05 But sure, if one tweak to redhat-rpm-config solves the problem then I don't see why we wouldn't just do that. 16:21:10 I'm ok with any of the proposed fixes too 16:21:32 though mod'ing redhat-rpm-config feels the most hackish 16:21:35 racor: any thoughts here? 16:21:53 we could also do both, fix the template and add the macro failsafe 16:22:07 that way, new packages get cleaner, existant packages get grandfathered 16:22:28 I think I like that better, yes 16:22:38 Sure. 16:23:03 Okay, so lets vote on "Move the Macro and Add the Macro failsafe to redhat-rpm-config" 16:23:36 +1 from me 16:23:37 +1 16:23:54 +1 16:23:59 I just hope there's not some hidden breakage we'll find next month from this change. 16:24:04 +1 16:24:39 Toshio had no preference of choice, so I think it is safe to assume he +1s here as well 16:24:57 but i'll follow up with him as soon as he gets back from pycon to be sure 16:25:08 #action +4 for proposal 16:25:43 #topic https://fedoraproject.org/wiki/PackagingDrafts/RPMMacros_sharedstatedir_optflags_and_admonitions 16:26:33 this looks like a general cleanup of an older page 16:27:22 seems straightforward to me, +1 16:27:33 Shouldn't those EPEL issues be on the EPEL page? 16:27:33 old/crufty bad, clean good: +1 16:27:57 tibbs|h: yeah, but that's an implementation note, i'll do the writeup and make sure it ends up there 16:28:41 * spot has a big note in his todo list to make sure that all EPEL specific items at least get repeated on an EPEL specific page 16:29:55 any other concerns? if not, please toss out votes. 16:30:21 I'm doing a visual diff. 16:30:27 mmkay 16:31:31 Kind of wish we'd just not use $RPM_BUILD_ROOT and $RPM_OPT_FLAGS, but I guess that's just personal preference. 16:32:26 Some of these are weird enough that I wonder if there's a point in having them in the guidelines. 16:32:51 I mean, it's true that %{_oldincludedir} is defined by RPM. But why do we need to put that in the guidelines? 16:33:16 yeah, we probably don't need to reference that one 16:33:31 i wouldn't consider it "common" 16:33:40 He didn't add it; it was there from the beginning. But I've always wondered why it's even mentioned. 16:33:49 easy enough to remove if we're cleaning it now 16:34:10 The guidelines should be "this is what you should use", not "here's a list of everything you could find with rpm --showrc". 16:34:39 But, yes, a general +1 to these changes. 16:34:55 I don't understand what this "draft" is trying to achieve. 16:35:20 racor: its a cleanup for the existing RPMMacros page 16:35:39 Some of it is stuff we should just be doing anyway. 16:35:58 Not mentioning "Fedora Core" and such. 16:36:52 OK, but my feel is there are way too many critical details inside which all would require to be checked for, before voting. 16:37:03 such as? 16:37:22 eg. the /var vs. localstatedir section. 16:37:28 i mean, confirming the validity of these macros is as straightforward as --showrc 16:37:53 It's true that %{_var} and %{_localstatedir} evaluate to the same thing. 16:38:05 They serve different purposes, similar to %_lib and %_libdir 16:38:30 racor: that may be so, but they've evaluated like this since... well, at least FC3 16:38:52 If you wish to write a draft explaining which should be used when, please feel free. 16:39:16 It's not as if the original document didn't mention both in exactly the same way that the draft does. 16:39:50 Well, I actually feel this proposal should be split, because I feel it's too radical 16:40:04 You must have some odd definition of radical. 16:40:21 * spot notes that the part you have highlighted for concern is present in the existing guidelines page 16:40:47 All he did is change "Other macros" to "Other macros and variables for paths". 16:41:06 Taking too many steps at once, with a high probabilty of replacing existing bugs with new ones. 16:41:12 And add PM_BUILD_ROOT to the bottom of the section. 16:41:27 That... turned out weird. 16:41:34 And add $RPM_BUILD_ROOT to the bottom of the section. 16:41:43 racor: i really can't say i see where you're coming from on this one. 16:42:09 but, if you're opposed, go ahead and vote so we can move on. 16:42:28 But, sure, I couldn't object to actually going through all the stuff on this page to make sure we actually want people to use it. 16:42:36 racor: Are you willing to do that? 16:43:24 ... 16:44:24 * spot yawns 16:44:41 spot: This proposal is trying to change many _critical_ _core_ details of the configuration machinery. 16:44:51 racor: it doesn't change _anything_ 16:45:01 racor: this is how the macros are defined. right now. 16:45:09 I feel each sentence of this proposal needs to be explicitly reviewed 16:45:23 So I ask again: are you willing to do that? 16:45:24 not doing so would be grossly negligant 16:46:03 spot: This doesn't exclude the current state is broken. 16:46:11 That's true. 16:46:35 racor: this draft doesn't request that we change the current macro definitions, merely that we reflect what they are. 16:46:36 sorry, ... might/could be broken ... I don't know 16:46:38 I actually think that there's stuff in there which we probably don't want in there. 16:46:57 But there are nuances I'm sure I don't understand. 16:47:07 if you think that macros should be changed, then i think that is a separate issue 16:47:28 Still, if racor isn't even willing to given an answer to questions about whether he's willing to contribute to fixing the document, then I'm not sure we have much more to discuss. 16:47:29 (i'm not sure if that issue is within our scope or not.) 16:47:57 racor: would you like to vote on this draft, for the record? otherwise, i'll assume a vote of 0 and move on. 16:48:09 tibbs: Your provocations are beyond limits, get a grip on yourselv 16:48:32 I only asked if you were willing to assist in correcting the document. 16:48:50 spot: I don't want to be co-responsible for writing broken stuff into concrete: My vote -1 16:48:58 okay. 16:49:23 #action Voting on RPMMacros improvements: +3, -1 (racor) 16:49:37 #topic http://fedoraproject.org/wiki/Packaging/No_py_removal%28draft%29 16:51:07 My network just dropped for about 90 seconds. 16:51:10 fun. 16:51:18 well, you didn't miss anything 16:51:24 aside from me moving to the next topic 16:51:45 this draft seems to be common sense to me. 16:51:45 That link gets me to a "no such page" page. 16:51:52 https://fedoraproject.org/wiki/No_py_removal%28draft%29 16:51:54 ? 16:52:09 * spot just opened it 16:52:10 ok, better 16:52:15 wierd 16:52:28 No "Packaging/" 16:53:17 looks like a no-brainer 16:53:24 #topic https://fedoraproject.org/wiki/No_py_removal%28draft%29 16:53:27 I guess it's not a bad idea to make this explicit. 16:53:56 tibbs|h: agreed, especially since the question explicitly came up which inspired this draft 16:54:05 +1 from me 16:54:36 +1 16:54:40 +1 16:55:06 rdieter ? 16:55:15 +1 16:55:43 #action Voting on No_py_removal: +4 present, +1 from abadger1999 via email, it passes. 16:56:02 * abadger1999 shows up late 16:56:08 #topic http://fedoraproject.org/wiki/User:Ajax/Static_Library_PICness_Guidelines 16:56:54 abadger1999: we voted to both move the font macro in the template and to create a dummy macro in redhat-rpm-config as described in the bugzilla ticket 16:57:13 abadger1999: if you'd like to vote on that, it would decide whether that issue passes or not. 16:58:18 on the current topic, i think this draft is incomplete. 16:58:27 For Library PICness I'm not opposed to it but I don't think it's complete yet. 16:58:30 i agree. what needs doin'? 16:58:43 ajax: there are some open issues listed on that page 16:59:16 tsk. you mean if i hadn't written them down, you wouldn't have noticed? ;) 16:59:29 no, i would have caught at least two of them. ;) 17:00:08 So what happens when you build a static library without -fPIC on x86_64? 17:00:09 fwiw, i think this is the first time we've required .pc creation 17:00:23 (or rather, the first time that a draft has required it) 17:00:36 tibbs|h: nothing. amd64 doesn't allow non-pic DSOs; ld won't create them and ld.so won't load them. 17:00:43 i386 is the only arch that's this stupid. 17:00:50 (that we ship on) 17:01:05 But does it build it PIC anyway or does it fail? 17:01:26 oh, static lib. sorry, misread. 17:01:44 you can create ar archives containing non-PIC objects 17:02:03 if you try to link that lib into a DSO or a PIE executable, ld will fail 17:02:17 if you try to link that lib into a normal executable, it'll succeed 17:02:21 * spot had to patch the shit out of chromium to fix that issue 17:02:56 lots of fun. :) 17:03:54 spot: on the pc file issue: yes, but it seems like the correct mechanism. it means the non-PIC ar archive is something you have to explicitly ask for. 17:04:06 ajax: i don't disagree with that, just noting it. 17:04:14 I have to wonder if this is something we actually run into. 17:04:18 we should be discouraging static libs in most cases anyways 17:04:29 tibbs|h: i have one package that needs to do this (and actually does it) 17:04:36 except for the .pc part 17:04:42 Current guidelines permit static libs if the maintainer wants them. 17:04:59 Actually using those in other packages is what's restricted. 17:05:16 tibbs|h: fair enough. 17:05:36 it does however, say: "Static libraries should only be included in exceptional circumstances." 17:05:46 and "In general, packagers are strongly encouraged not to ship static libs unless a compelling reason exists. " 17:05:58 I think we're actually kind of contradictory about that. 17:06:04 really? 17:06:58 it's definitely a corner case. 17:07:20 i don't think we see it often. but we should still get it right. 17:07:28 anyways, that issue aside, i think we can push this one out two weeks for the draft to be finished up 17:07:48 I don't feel up on the technical issues here, but currently there's not enough there for reviewers to be able to use. 17:07:51 any issues besides the ones in the draft? 17:08:13 do we really want to be in the business of shipping fedora specific .pc files? 17:08:30 the "simple definition" bit in Open Issues should probably include a way of testing for picness; i'll include that. 17:08:37 ajax: The basics of my questions were: How does the reviewer determine that a package is doing it wrong and how doesthe packager fix the issue. 17:09:25 ajax: If answering the questions are sufficient for that then it's good, if a reviewer would still be lost then we'd need to add some more. 17:09:35 halfline: not in general? but this level of build configuration detail is a distro policy question, so it kinda makes sense to ask a per-distro mechanism. 17:10:08 i don't think anyone is actually going to bother to build their static libs both ways, so. 17:10:11 thing is, having disto-specific .pc files implies having distro-specific patches to configure.ac ... 17:10:37 seems like a road we souldn't want to go down... 17:10:45 it does indeed. i think that's the point; that's a diversion we generally don't want to carry, so you should have to justify it pretty hard. 17:11:58 which is why Exceptions says "non-PIC static libs need explicit approval from FESCO" 17:12:29 anyway. i'll work this more. thanks for the feedback! 17:12:29 ajax: but the .pc file is required even for the PIC static lib 17:12:36 spot: (What do you need me to vote on to either pass or fail?) 17:12:55 spot: that may be how it reads, but that is not the intent. 17:12:57 abadger1999: we voted to both move the font macro in the template and to create a dummy macro in redhat-rpm-config as described in the bugzilla ticket 17:13:07 ajax: okay, please fix then. ;) 17:13:44 spot: the pc file is only there for the "build both" case, is the intent. 17:14:14 ajax: okay, when you're polishing this up, please make that explicitly clear. 17:14:19 will do. 17:14:23 * ajax afk, lunch 17:15:01 okay, i'm going to go to the last issue for today 17:15:29 #topic Clarify line between bundled libraries and copied snippets of code https://fedorahosted.org/fesco/ticket/314 17:15:35 man, this is a fun one. 17:16:44 i dunno if we still need to do anything here, it was on the agenda, but i thought it was discussed last meeting 02/03 17:16:52 I don't think it's possible to write a reasonable guideline for this that answers more questions than it raises. 17:17:17 Yeah -- So this is a discussion and maybe be able to draft some guidelines topic. 17:17:46 All this over wordpress. 17:17:47 At when point does modified bundled libraries stop being bundled libraries and become forked code that happens to live in another package? 17:17:52 i don't know that we will be able to do this in a reasonable guideline that isn't contentious 17:17:56 s/when/what/ 17:18:20 abadger1999: The answer to that question depends on the disposition of both upstreams. 17:18:32 in the specific case of WP, are these three PHP files really "libraries" ? 17:18:55 That, as well, depends on the disposition of both upstreams. 17:18:59 spot: The one I looked at was really a library upstream. 17:19:08 I think it's all about intent. 17:19:14 But wordpress didn't treat it as a library. 17:19:24 We fork/patch/whatever code in Fedora all the time. 17:19:42 But our intent is not to diverge permanently or significantly in most cases. 17:19:47 It made changes to the code instead of calling the api... to my unaided eye, it seemed a bit gratuitous. 17:19:56 The wordpress folks just don't seem to care. 17:20:00 17:20:13 these seem to be forks with wordpress changes. 17:20:14 But that's a view through a long lens. 17:20:21 Some cases deserve to be divergent though -- for instance rsync's bundled library needs to be pulled out. 17:20:43 Because there's other libraries that want to be wire-sompatible with rsync. 17:20:49 s/libraries/applications/ 17:21:23 i'm not sure where the line of acceptability truly is here. is it a % of fork? is it upstream's intent? 17:21:36 is it affected by type of code in use (PHP vs traditional DSO) 17:21:45 The bottom line with wordpress is that we seem to be trying to make the decision between accepting what wordpress upstream does, basically forking wordpress ourself to "do the right thing", or kicking it out of the distro in protest. 17:22:00 ourselves. Jeez. 17:22:34 in the case of WP, if the code is forked with changes, we either accept that they are maintaining that code as part of WP or we don't permit the package. 17:22:48 i'm inclined to accept it in this situation. 17:23:10 I'm inclined to be more cautious. 17:24:03 Not that it's my decision anyway. 17:24:14 i think cases where libs or dynamically loaded files are simply copied for convenience or laziness are clearly unacceptable 17:24:40 but a forked work could easily be considered an improved (or simply derived) work 17:24:47 It starts as convenience or laziness, and then they change a couple of lines instead of bothering to send a patch upstream and all of a sudden it's a fork. 17:25:37 Sometimes when they are called on it, the fork can be made to go away. 17:26:05 spot: but what about when the forking causes compatibility problems? (for instance rysnc's zlib)? 17:26:31 well, i'm not sure that we can do much more on this issue. I think it is good for us to be pushing upstream, but at the end of the day, it is up to FESCo to decide whether the merits of keeping the code are enough to ignore upstream's bad behavior. 17:26:52 So what is actually before FPC at this point? 17:27:00 as far as i can tell, nothing 17:27:03 but i might be wrong 17:27:14 So... 17:27:24 So -- our final analysis is that FESCo will need to do the analysis -- FPC has no more input on the proper criteria to give? 17:28:04 abadger1999: i could write pages and pages on this topic, but i'm not sure it would do anything other than make a gray area even more gray 17:28:04 It's completely situational. 17:28:23 i'm happy for FESCo to ask for FPC advice on each situation 17:28:36 We can write "maintainer _should_ contact both upstreams regarding resolving forks" or something. 17:28:39 * abadger1999 is fine with that just wants an accurate summary. 17:28:52 spot: Hmmm... so what's FPC's advice i nthis situation? 17:29:18 well, if it were my package, this is what I would do 17:29:45 1. Package up the verbatim copied bits as proper upstream components, and make WP dep on them (with symlinks if needed). 17:30:16 2. Generate diffs of the changes made to forked components and submit them to the upstreams for consideration 17:30:59 If those upstreams rejected the diffs, I'd try to at least open a dialog with WP on the topic 17:31:15 If they accepted them, I would remove the forked code (as it wouldn't be forked anymore) 17:31:15 We could provide guidelines for naming forked libraries, I guess. 17:31:36 Based on a maintainer taking those actions, I would recommend that we permit WP. 17:32:38 Where dialog == more than the bug report that was already opened? Or that bug report was sufficient? 17:33:03 Well, "bug report" if awfully one way. 17:33:09 But if there's no response.... 17:33:18 Well, in this case, i was thinking of the upstreams of the forked bits 17:33:36 opening bugs there 17:33:39 * abadger1999 wants to avoid bug reports of the form: "My distro requires me to open this bug report to try to get you to unbundle these libraries but I really don't understand why it's helpful so feel free to close it if it's too hard" type things. 17:33:54 Ah. 17:34:02 heh. i think in such cases, i'd advise against including them. 17:34:16 Note that the one library I looked at (the one that seemed gratuitous) was all WP specific changes. 17:34:24 Rename classes to have WP in the names 17:34:33 Change error messages to be WP specific. 17:34:43 Unsurprising fail. 17:35:01 You know -- very little in the way of changes to the functioning of the code... but very specific to WP rather than upstreamable. 17:35:03 yep, its fail, but WP is taking responsibility for it at some level. 17:35:15 i mean, if it could be sanely patched out in our copy, maybe. 17:35:25 i patched out quite a bit of that from chromium 17:35:42 and to be fair, i think mozilla does some of that too 17:35:58 Doesn't make it remotely a good idea. 17:36:15 It's just that we weren't paying as much attention to this kind of thing way back when. 17:36:34 my feeling is that we should push maintainers to do the best that they can to inform the upstreams of the issue, try to get it resolved, and if all avenues fail, ask FESCo to decide if it is acceptable to keep. 17:36:54 i know that i'm not doing a very good job of defining what is acceptable at that point. :/ 17:37:00 Yes. 17:37:39 however, i suspect most packages with such issues will not have such diligent maintainers and will not get that far 17:37:43 The tough issue is to decide if and how much the popularity or importance of the application factors into the decision. 17:37:59 and those that do, well, that maintainer knows what they're in for and is making a level of committment. 17:38:26 i think those factors do weigh on the decision 17:38:48 i mean, if we were to pull rsync over this issue, it would be perceived as extremely negative and damaging to Fedora 17:39:14 Well, what's in is already in, and our focus has to be on fixing those mistakes as best we can. 17:39:17 spot: In ththe vien of the Fedora package maintainer making a level of commitment: "If it has to be modified I would ask that someone who knows PHP would take it [...]" <= wrong or right attitude? 17:39:50 abadger1999: well, at least he's admitting he's not the qualified person for the job. :/ 17:40:18 i hate to jump out at this point, but we're pushing on 1 hr 40 minutes now. 17:40:19 17:40:30 i'm going to open the floor for other topics, and hopefully, wrap this up 17:40:34 #topic Open Floor 17:40:39 Okay -- I'll update the fesco ticket to say we punt to them. 17:40:43 Re: fonts. 17:40:55 I readthe logs, why are we doing both? 17:41:08 abadger1999: so that existing packages can be effectively grandfathered 17:41:21 Doing just one will fix the base problem, though. 17:41:30 yes, but it is cleaner to do it right. 17:41:35 Okay. 17:41:42 +1 then. 17:41:46 And less work for those involved to do it simply. 17:42:02 #action Font macro changes as earlier voted are passed with abadger1999's late +1 vote. 17:42:30 Are there any other topics for today? 17:42:32 I have nothing. 17:42:41 none from me. 17:42:57 mdomsch: you submitted a draft for CMPI Plugins 17:43:15 mdomsch: there are some outstanding questions on the page that should be addressed 17:43:43 we'll look at it next meeting, hopefully it will be clearer at that point. 17:44:03 Okay, with that, I'm closing out the meeting. Thanks everyone. 17:44:06 #endmeeting