Meeting:Packaging IRC log 20061031

[11:00:03] Howdy -- meeting now or an hour ago? [11:00:38] now... [11:00:51] * rdieter pops in. [11:00:53] Those of us who were here an hour ago pretty much figured that out. [11:00:57] hold on a sec, finishing a call [11:01:05] sorry for the conclusion [11:02:07] s/conclusion/confusion [11:02:10] stupid spell check [11:05:10] Join scop has joined this channel (n=scop@cs27014175.pp.htv.fi). [11:05:48] oh kay [11:05:54] i'm here, who else is here? :) [11:05:59] * scop is here [11:06:04]  * abadger1999 is here [11:06:25]  here [11:06:35]  tibbs? [11:06:38]  f13? [11:06:44]  racor? [11:06:47]  here [11:06:49]  f13 is away today, I think. [11:07:08]  racor was here an hour ago... [11:07:15]  And he's here now. [11:07:24]  yeah, sorry for the confusion guys [11:07:26]  * rdieter rubs eyes, can't read. [11:07:29]  it should be 1700, right? [11:07:36]  So we know we'll be missing Axel and f13. [11:07:48]  It is currently just past 1700UTC, yes. [11:07:49]  spot: depends on what you intend [11:08:00]  racor: the meeting time, it should be at 1700, correct? [11:08:18]  Yes [11:08:23]  If it's supposed to be shifted with DST, then yes. [11:08:24]  we should be having our meetings at 1700 UTC instead of 1600 UTC now. [11:08:37]  Topic spot sets the channel topic to "Channel for Fedora packaging related discussion | Next Meeting: Tuesday, October 31st, 2006 17:00 UTC". [11:08:47] ok, i'll try to get it right next time [11:09:01] Topic You set the channel topic to "Channel for Fedora packaging related discussion | Next Meeting: Tuesday, November 7th, 2006 17:00 UTC". [11:09:02] lets get started [11:09:17] Writeups: [11:09:27] abadger1999, rdieter, tibbs [11:09:34] you guys still have writeups to do [11:10:00]  I can do it after the meeting (I have time today) [11:10:04] if you need help or clarification, please let us know. :) [11:10:11] Sorry. Will get on that. [11:10:59]  I'd like to talk about racor's static library draft now [11:11:07]  http://fedoraproject.org/wiki/PackagingDrafts/StaticLinkage [11:11:21]  imho, this is well written and obvious. [11:11:56]  I even agree with the extensions [11:12:15]  ditto, I like the -static extension too. [11:12:32]  (not sure about the versioning bit of it though) [11:12:34]  I find the 2nd extension arguable/discuss-worthy, myself [11:12:56]  racor: i really only see the need for one extension or the other [11:13:09]  i could see the case for both, but if it was my choice, i'd pick #1 [11:14:00]  +1 to the proposal, +1 to extension #1. Not sure about extension #2. [11:14:04]  the 2nd extension is aiming at intentionally breaking builddeps once a static lib changes [11:14:24]  I am not sure it this is too radical, or if it even works [11:14:24]  * spot nods [11:14:29]  I wonder if there's any chance of fixing debuginfo for static libraries. [11:14:36] i think it might be too painful. [11:15:00] tibbs: that's what I actually had in mind [11:15:14] but am not sure if it's doable [11:15:33] * spot idly wonders what folks like ulrich drepper think about it [11:15:48]  i'll ask him what he thinks [11:15:48] spot: What is your concern [11:16:24] racor: well, if eu-strip doesn't handle static libs reasonably, then debuginfo is just not really possible [11:16:40] not as it currently exists anyways [11:17:04] exactly, debug infos for static libs don't exist [11:17:36] so, i'll ask ulrich (upstream for elfutils) if he thinks there is any merit in extending eu-strip to deal with static libs [11:17:37] Quit Rathann|work has left this server ("Leaving"). [11:18:01] another leak in my original proposal: "case-by-case decision" - by whom? [11:18:15] i think that would be FESCO [11:18:28] what about Core pkgs? [11:18:58] * spot thinks this group is capable of making these case-by-case decisions [11:18:59] but [11:19:10] it also seems to be outside our current scope [11:19:18] rdieter: f13, notting, ?jeremy? (Whoever the Fedora Core de facto committee is) [11:19:41] would it be too loose to let pkg reviewers do it? [11:19:58] rdieter: imho, yes. [11:20:03] ok [11:20:05]  We should note that it's discouraged, and leave it up to FESCo and the Core cabal to decide what rule they'd like to insert. [11:20:07] would be nice to see which precedences Core allows [11:20:12] i think we'd get too many -static items when we really want to discourage it [11:20:41]  spot: making this obvious is one objective [11:20:42] i'm ok with FESCo+Core_cabal then. [11:21:00] racor: agreed [11:21:20] i'm ok with FESCO/Core_cabal deciding the case-by-case [11:21:38] + a list of precedence with rationale [11:21:53] s/precedence/precedences/ [11:22:07] Or just, rationale, including precedences where available [11:23:14] Packager must provide rationale for a -static subpackage, including precedences where available, to the appropriate Steering Committee (FESCO for Fedora Extras, Secret Core Cabal for Fedora Core) [11:23:43] for approval. [11:23:45] spot: OK, sounds reasonable to me [11:24:15]  ditto [11:24:27] ok, lets vote on the proposal, plus extension 1, and the above sentence for committee approval requirement. [11:24:37] +1 [11:24:39]  +1 [11:24:41]  +1 [11:24:41]  +1 [11:24:41]  +1 [11:24:48]  ok, it passes [11:25:17] +1 [11:25:26]  tibbs: :) [11:25:32]  always good for unanimous votes. [11:25:37]  Sorry, I'm at work. [11:25:39]  racor: good job. [11:25:40]  Damn users. [11:25:59]  lets talk about the Translations item [11:26:08]  If the package has any translations, add BuildRequires: gettext. If you don't, your package will probably fail to build in the buildroot. [11:26:29]  This seems to be rather obvious advice to add to the PackagingGuidelines [11:26:30]  Does this even need to be a guideline? [11:26:47]  I mean, if your package doesn't build, no guideline will save you. [11:27:04]  i don't see any reason why we can't document it [11:27:09]  I failed to mention in the proposal, that *some* pkgs will build, but simply fail to include translations. [11:27:17]  Will builds typically fail or just fail to build the translations? [11:27:22]  spot: Is this true at all? [11:27:25]  rdieter: Thanks. [11:27:42] racor: well, it will either not build or it will fail to include the translations [11:27:53] Perhaps it's good advice to stick in some kind of "hints for packagers" document, but I'm not sure it needs to be in the guidelines. [11:27:58] really depends on whether configure explodes on it [11:28:14]  tibbs: +0.5 [11:28:16] tibbs: i think there is merit in putting this next to the find_lang item [11:28:27] agreed. [11:28:34] so when packagers are enabling translations properly, they know they need to also have BR: gettext [11:28:44] spot: why? gettext support in configure scripts is supposed to be usable without having gettext installed [11:28:49] gettext + %find_lang pretty much go hand in hand. [11:29:09] racor: not if it needs gettext to generate translations. [11:29:27] spot: such packages are bugged [11:29:30] racor: you're right, most autotooled apps will ignore this. [11:29:56] racor: it's buggy to generate translations at build time? [11:30:07] "If the package has any translations, add BuildRequires: gettext. If you don't, your package will probably fail to generate translation files in the buildroot." [11:30:17] spot: better. [11:30:26] rdieter: yes, that's not they way gettext support is supposed to work [11:30:42] it's the same as running autotools at build-time [11:30:52] unfortunately, for most pkgs I've seen, that's the way it is. [11:31:00] doable, but not how things are supposed to be used [11:31:15] kde, I suppose? [11:31:20] (: [11:31:39]  * spot will take that as a yes [11:32:03]  No punt intended, kde is pretty wild at using the autotools (filtering Makefile.ins etc) [11:32:17]  moc* stuff etc. [11:32:20]  no argument there. [11:32:39]  i don't think it is harmful to add this to the guidelines, it doesn't hurt anyone (nor prevent any package which doesn't need it to generate validate translations from omitting it) [11:33:31]  How about s/probably fail/possibly fail/ to be a wee bit more pc. [11:33:40]  i'm not opposed to that [11:34:17]  "If the package has any translations, add BuildRequires: gettext. If you don't, your package could fail to generate translation files in the buildroot." [11:35:04]  I'm really only concerned that the guidelines will end up with too much additional stuff. [11:35:14]  tibbs++ [11:35:14]  tibbs: +1 [11:35:27]  But I guess we can deal with that when it becomes a problem. [11:35:36] i would rather have the guidelines be specific where possible to avoid mailing list confusion [11:36:01] we already have a find_lang section, this fits with it nicely imho [11:36:13] yeah, I proposed this only after seeing lots of ml ?'s and reviews stuck on it. [11:36:26] If they get too large, we can always split the hints out, or refer to an external document like the naming guidelines. [11:36:36] tibbs: agreed [11:37:06] ok, so lets vote on adding the last posted sentence to the PG [11:37:19]  +1 [11:37:20] +1 [11:37:23]  +1 [11:37:36]  +1 [11:37:39]  +1 [11:37:45]  +1 [11:37:52]  ok, two down. [11:38:22] does anyone have something they'd like to tackle? [11:38:50] We could talk about license tags, although I don't have a proposal. [11:39:09] well, we could make a standardized list for license tags [11:39:22] The basic question is whether we care about trying to indicate information like GPLv2 versus GPLv3. [11:39:36] IIRC, we probably do. [11:39:44] Currently we don't. [11:39:49]  since GPLv2 and GPLv3 are such different animals [11:39:55] yup. [11:39:58] GPLv2 and GPLv3 sound like they'll be very different [11:40:08] Well, we currently just say GPL and don't mention a version at all. [11:40:22] but we almost universally assume GPL = GPLv2 [11:40:25] Plus there are various incarnations of BSD which are not differentiated in the license tag. [11:40:26] Similarly BSD-old and BSD-new? [11:40:55] Apache 1 vs 2 [11:41:03] I think it would be a good start to make a list of licenses [11:41:05] Urgh, there are 100's of BSD'sh licenses, but only one original UCB-BSD license [11:41:25] racor: i also don't think we need to get that specific [11:41:28] And there are a couple of licenses which are variable (you can include several or no additional clauses). [11:41:56] So the question is whether the license tag should be a general reference or a more specific designation. [11:42:25] And if we want it to be specific, we need to standardize and be ready to provide additional standard tags as new packages with odd licenses appear. [11:42:28] it would be easiest for the people doing the audits if it was as specific as possible without being divergent [11:42:57] i think having a list of "approved" license tags would be a good start. we can always add to it over time [11:43:21] then, we can discuss whether the list is complete or missing items [11:43:37] Should a new package with a license that has no existing tag be stalled until we can decide on a tag? [11:43:42] the current de facto "approved" list is what's in rpmlint, I suppose [11:43:46] spot: cf. OSI + FSF homepage [11:43:57] they have such lists [11:44:03] racor: thats pretty much what i'm saying [11:44:12] although, we need to be careful [11:44:19] some of those licenses aren't in use [11:44:33] some of them are still on the OSI page but have been "retired" [11:44:48] two of the OSI licenses are listed by the FSF as non-free [11:45:05] we've never hit that conflict because they're not in use by anything in Fedora [11:45:07] ROTFL .... [11:45:37] It shouldn't be up to this committee to decide which licenses are acceptable, though. [11:45:46] tibbs: i agree [11:45:48] tibbs++ [11:46:07] tibbs: i'd rather see us make a list off of the licenses which are actually in use [11:46:15] tibbs: No, we are no lawyers and of different national backgrounds [11:46:33] So our function is just to provide a list of tags to be used which isn't intended to limit the set of acceptable licenses. [11:46:40] tibbs: yes [11:46:55] And the general concensus is that things like license version should be indicated in the tag? [11:46:58] as other acceptable licenses emerge, we'll make tags for them [11:47:08] +1 for version in the tag [11:47:23] 0 [11:47:27]  tibbs: GPLv2/GPL vs GPLv3 would be OK with me, not more [11:47:38] Apache should not get a version? [11:47:41] racor: why not other licenses? [11:47:46] Creative commons should not get a version? [11:47:49] other licenses diverge as significantly between versions [11:47:57] spot: what gives? [11:48:33] the rpm tag field should be treated as hint, not as legal statement [11:48:40] agreed [11:48:44] Indeed, that's true. [11:48:48] but it is useful for people to have as a base [11:49:04] The question is how much of a hint do we want to give. [11:49:28] i think there is merit (when the license has a version) in including that in the tag [11:49:34] when the versioning is relevant [11:49:46] spot: ack, but I don't want a list of 100s of licenses BSD(redhat.com),BSD(USB1998-10-02) ... [11:49:49] right, License: should try to be as reasonably accurate as possible. [11:49:49] so if Foo License 1.0 and 1.1 are only different in the changing of a typo [11:49:54] then screw that [11:50:07] racor: neither do i. :) [11:50:29]  OK, I'm just trying to get a general idea for how much information is necessary so that I can start building up a list. [11:50:52]  BSD with the names changed is "BSD" [11:51:08]  MIT/X11 should be a separate license [11:51:29]  but beyond that, i don't see anything more for that case unless they add clauses [11:51:51]  then we can standardize on BSD (with additional clauses, see LICENSE.txt) [11:52:09]  where LICENSE.txt is appropriately named [11:52:28]  does that make sense? :) [11:52:32] Yes. [11:52:32] am i talking to myself? :) [11:52:38] I think I have enough to start with now. [11:52:48]  great, we'll revisit that next week [11:52:58]  So feel free to move on and hopefully I'll have a proposal by next tim. [11:53:05]  well, we have 5 minutes or so, anything else? [11:53:37]  What about the source requirement? [11:53:52]  tibbs: i think i might need to reword that to be more specifc [11:54:18]  what about Requires vs PreReq [11:54:37]  Should we document that Requires is to be used, and not PreReq? [11:54:47]  imo, yes. [11:54:50]  I've not allowed PreReq in any packages I've reviewed. [11:55:03]  I guess rpmlint complains about it already. [11:55:20]  ok, i'll take that as my item, lets vote on it. [11:55:25]  seems like a no-brainer to me. [11:55:26]  +1 [11:55:30]  +1 [11:55:31]  +1 [11:55:35]  +1 [11:55:51]  note that the issue is slightly hairier than what it looks like on first sight [11:55:58]  Requires != PreReq [11:56:03] Requires(pre) != PreReq [11:56:12] Correct. But: [11:56:24] prereq is going away in RPM [11:56:33] (assuming that anything ever happens with RPM) [11:56:41] correct me if I'm wrong, but doesn't: Requires+Requires(pre)+Requires(post) essentially = PreReq? [11:56:49] I'm not sure that there are any packages that actually care about the difference. [11:56:56] and if rpm ever revives PreReq in a different fashion, we can revisit this. [11:57:05] sure, I'm not opposed to the change [11:57:14] rdieter, I dunno, what about erase order? [11:57:20] so +1 [11:57:20] * spot waits for the vote [11:57:24] rpm doesn't do erase order (never has, afaik). [11:57:32] (not yet, anyway) [11:57:33] +1 [11:57:44]  ok, it passes [11:57:51] rdieter, you mean Requires(preun) and Requires(postun) are no-ops? [11:57:52] last chance for quickie items [11:58:16] scop: no, I just didn't want to type all the pre/post variations... (: [11:59:00] Requires+ Requires (pre*) + Requires(post*) approximates PreReq, afaik. [11:59:23]  sometime in the future: discuss/decide/document which is the lesser evil: leaving users/groups created by packages behind on erase or removing them [12:00:05]  scop: i'll add that to the todo list [12:00:08]  scop: that's a good one. [12:00:11]  spot, thanks [12:00:19]  i think we're done for today, thanks guys! [12:00:45]  Who will summarize the changes for the announcement? [12:02:27]  i will [12:02:32]  i'm already editing the todo list [12:05:49]  Part scop has left this channel ("Leaving"). [12:09:37]  Amazingly productive. A few more meetings like this and we'll clear our backlog. [12:11:08]  Quit racor has left this server ("Leaving"). [12:22:38]  its because I wasn't here. I know it.