From Fedora Project Wiki

(Redirected from Packaging:IRCLog20061031)

[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 (
[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>
[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(,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.