From Fedora Project Wiki
[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 (n=scop@cs27014175.pp.htv.fi).
[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.