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