Meeting:Packaging IRC log 20061219

Fedora Packaging Meeting of 2006-12-19; times are in US/Central

[11:02]  <spot> ok, anyone want to bring up anything for discussion?
[11:03]  <spot> before i start randomly throwing darts at the minefield
[11:04]  <scop> http://fedoraproject.org/wiki/PackagingDrafts/ProvidesObsoletes should be ready for discussion
[11:04]  <rdieter> Hopefully, discussion can be minimal, and we can try to vote/pass more items today.
[11:04]  <rdieter> i'd like to vote on iconcache, if possible.
[11:05]  <spot> ok, lets tackle ProvidesObsoletes
[11:05]  <spot> the draft seems like common sense to me
[11:05]  * rdieter agrees
[11:05]  <spot> short, to the point
[11:06]  <spot> ok, lets vote on it
[11:06]  <spot> +1
[11:06]  <racor> ack, i am missing a note on epochs
[11:06]  <thimm> +1
[11:06]  <racor> +1
[11:06]  <rdieter> +1
[11:06]  <scop> +1
[11:06]  <spot> racor: good catch, epoch should be in the envr
[11:06]  <lutter> yeah, looks good .. if the Provides is meant to be removed, it might be good to indicate that in a comment right next to it, like '# Will be removed in FEn'
[11:06]  <scop> epoch and comment noted, will add
[11:07]  <lutter> other than that: +1
[11:07]  <spot> ok, approved with minor revisions
[11:07]  <tibbs> What implication does dropping old Provides: have on upgrades over several versions?
[11:07]  <scop> breakage
[11:07]  * f13 is back
[11:07]  <spot> do we lose anything by keeping the provides around indefinitely?
[11:08]  <tibbs> Is it important to consider that people might jump from FC5 to FC7, given that we have 13 months of support now?
[11:08]  <tibbs> I think at least two-version upgrades will be common.
[11:08]  <f13> yes.
[11:08]  <lutter> more stuff to churn through for yum .. though I doubt this case willcause a lot of extra data
[11:08]  <thimm> We should have a policy of how long to keep compatibility provides
[11:08]  <f13> if we're providing, perhaps with a timeout
[11:08]  <tibbs> Obviously we do want to get rid of crap at some point.
[11:08]  <f13> becuase while today we may provide what Foo does, but tomorrow we may not
[11:08]  <lutter> and make it at least the support life of the next release
[11:08]  <f13> so Provides are not guarenteed to last forever.
[11:08]  <tibbs> Old provides can even get in the way; that came up recently.
[11:09]  <scop> it'd be nice if there was a real way of marking something as deprecated in packages
[11:09]  <thimm> Remove compatibility releases two releases from introduction?
[11:09]  <f13> care could be taken when removing a provide to make sure nothing depends on it
[11:09]  <tibbs> So we really do  need to put a time limit on them; I just think one release is too short.
[11:09]  <f13> or fixing what does depend on it.
[11:09]  <spot> so, drop in FC-current+1? FC-current+2?
[11:09]  <f13> repoquery anybody?  (:
[11:10]  <scop> fixing is encouraged in the draft
[11:10]  <tibbs> repoquery would be great if it could work on arbitrary repodata instead of what yum would use on the machine you're running it on.
[11:10]  <spot> i dont think upgrades across three major revs are a good idea, +2 is probably the limit
[11:10]  <rdieter> agreed.
[11:10]  <f13> tibbs: we could fix that.
[11:10]  <spot> why not just say FC-current+2 ?
[11:10]  <tibbs> I would try if I knew enough Puthon.
[11:10]  <lutter> spot: I would draw the line at the EOL of the next release
[11:10]  <tibbs> spot: +1.
[11:10]  <thimm> spot++
[11:10]  <f13> tibbs: gotta start somewhere (:
[11:11]  <f13> spot +1
[11:11]  <tibbs> I can't even spell Python.
[11:11]  <lutter> +1
[11:11]  <spot> ok, FC-current +2.
[11:12]  <scop> ok
[11:12]  <spot> alright, next up: iconcache
[11:12]  <spot> http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache is the latest draft (i think)
[11:12]  <rdieter> yep
[11:12]  <tibbs> Last modified 12-14.
[11:12]  <scop> tibbs, btw, repoquery's -C and --repoid options may be what you're looking for
[11:12]  <thimm> need for discussion?
[11:12]  <thimm> if not: +1
[11:13]  <spot> it looks good to me.
[11:13]  <spot> +1
[11:13]  * f13 gives it a quick look
[11:14]  <spot> someone should file a bug against hicolor-icon-theme to Require: xdg-utils
[11:14]  <rdieter> I will.
[11:14]  <rdieter> for F7, of course.
[11:14]  <spot> ok
[11:14]  <racor> the "If none of the package's existing dependencies..." doesn't seem sound to me
[11:14]  <tibbs> I guess we can assume that there won't be any more split.
[11:14]  <spot> simple == good in my book. :)
[11:14]  <racor> such deps can go on and off at random
[11:15]  <rdieter> racor: I can drop that part (for now, at least).
[11:15]  <f13> +1 to iconcache.  Looks much simplier
[11:15]  <tibbs> Yes, and there's a difference between a plain dependency and Requires(post).
[11:15]  <f13> more simple that is.
[11:15]  <scop> the current draft will not apply to Core < 7 packages?
[11:15]  <scop> or?
[11:16]  <tibbs> there's no way that it can.
[11:16]  <f13> does it work on core < 7 packages?
[11:16]  <rdieter> scop: no.
[11:16]  <f13> oh crud
[11:16]  <thimm> why not?
[11:16]  <tibbs> Unless you want core to require something in extras.
[11:16]  * f13 hoped we wouldn't get into version specific guidelines.
[11:16]  <tibbs> xdg-utils isn't in core.
[11:16]  <lutter> +1 for iconcache
[11:16]  <scop> dependencies on xdg-utils aren't possible in Core < 7
[11:16]  <f13> tibbs: well, we aren't adding any new core packages at this point so....
[11:16]  <f13> why not "this rule applies to all new packages"
[11:16]  <rdieter> I figured it would be ok, since Core packages (<7) are pretty much done (modulo errata's anyway)
[11:16]  <racor> scop: why?
[11:16]  <thimm> There could be ne FC6 packages
[11:17]  <thimm> s/ne/new/
[11:17]  <rdieter> f13: makes sense, "new packages" (:
[11:17]  <scop> racor, AFAIU, Core can't include dependencies from Extras, Core does not add new packages
[11:17]  <f13> thimm: there could be new FE6.  Very highly unlikely to be new FC6, adn they could get a waive
[11:17]  <thimm> Ah, ok!
[11:17]  <f13> scop: very rarely does core add new packages, but it does happen.
[11:17]  <racor> scop: Core's problem, FE packages can requires them
[11:17]  <tibbs> It's simpler for us to just not worry about it.
[11:17]  <f13> indeed
[11:18]  <f13> just apply to new packages and be done with it.
[11:18]  <racor> f13: +1
[11:18]  <scop> racor, exactly, that's why I mentioned _Core_ < 7 packages
[11:18]  <rdieter> +1 iconcache (duh)
[11:18]  <tibbs> xdg-utils is there for all supported FE releases so all of the important situations are handled already.
[11:18]  <racor> i.e. let FE people use it, if they want. How to handle Core is RH's problem
[11:19]  <spot> racor: and hopefully, not a problem much longer. :)
[11:19]  <spot> ok, iconcache passes
[11:19]  <thimm> No, it's our problem as well
[11:19]  <tibbs> +1 iconcache, assuming the bit about "If none of the package's existing dependencies....' is dropped.
[11:19]  <rdieter> I'll drop the "if none" bit, and add "for new packages".
[11:19]  <rdieter> ok?
[11:19]  <scop> +1 with those changes
[11:20]  <racor> thimm: why? if xdg-utils are in FE and work, FE < 7 packages _can_ use
[11:20]  <racor> it
[11:20]  <tibbs> I wouldn't even worry about "for new packages"; I could update my existing packages.
[11:20]  <abadger1999> +1 iconcache
[11:20]  <thimm> racor: why about what?
[11:20]  <tibbs> Perhaps just add a note that obviously it doesn't work for core packages before F7.
[11:21]  <rdieter> tibbs: yeah, I think that's the easiest way to say it.
[11:21]  <thimm> tibbs++
[11:21]  * spot nods
[11:21]  <f13> worksforme
[11:21]  <spot> ok, thats two down.
[11:21]  <racor> thimm: may-be a misunderstanding: I wanted to say "FE < 6" can use it, people should feel encouraged to switch, even with FE < 7
[11:21]  <spot> any other easyvote items?
[11:22]  <f13> trifecta!
[11:22]  <scop> debuginfo is pretty easy, I think
[11:22]  * rdieter nods
[11:22]  <tibbs> Is there a draft?
[11:23]  <tibbs> Just Packaging/Debuginfo?
[11:23]  <spot> ok.so, the debuginfo item is basically "comment if you're disabling debuginfo to explain why?"
[11:23]  <scop> basically just a link to http://fedoraproject.org/wiki/Packaging/Debuginfo needed in guidelines
[11:23]  <scop> and a requirement to add a comment to specfile if debuginfo is intentionally disabled
[11:24]  <spot> +1
[11:24]  <spot> obviously preferred
[11:24]  <f13> +1
[11:24]  <rdieter> +1
[11:24]  <tibbs> +1
[11:24]  <scop> +1
[11:24]  <thimm> +1
[11:24]  <tibbs> What about the TODO: item in there?
[11:25]  <lutter> +1
[11:25]  <spot> i'll check one of my R packages
[11:25]  <scop> someone who knows R, Mono and/or Ruby will have to comment on the TODO item
[11:25]  <lutter> scop: you can drop the reference to ruby packages, teh noarch issue has been fixed, and we build noarch packages for all supported releases
[11:25]  <f13> hurray
[11:26]  <abadger1999> We should add the requirement to comment next to "%define  debug_package %{nil}"
[11:26]  <abadger1999> Otherwise +1
[11:26]  * spot has to step afk for a moment, electrician is here to rewire my lab... bbiaf
[11:26]  <scop> lutter, ok, cool, doing it now
[11:26]  <scop> abadger1999, yes, that's included in what's being proposed, see the item in GuidelinesTodo
[11:26]  <thimm> it obviously passes :)
[11:26]  * Rathann|work has to go, will read the log later
[11:27]  <racor> +1, had to read it, first
[11:27]  <abadger1999> scop: Ah I see now.
[11:28]  <tibbs> A bit of info about Java debuginfo packages might be in order; I'll see if I can remember the magic incantation to get it working properly and send something to the list.
[11:28]  <racor> scop: BTW, I recently encountered a case where a debuginfo was generated from a noarch
[11:28]  * f13 shudders at 'java'
[11:28]  <scop> racor, whoo
[11:29]  <tibbs> f13: Someone had to review those packages, after all.
[11:29]  <tibbs> racor: I didn't think that was possible, but I guess anything is possible with RPM.  What was the package?
[11:29]  <racor> Cross compilers, debuginfo bogusly being generated from foreign elf-binaries
[11:29]  <scop> hm, interesting
[11:29]  <thimm> cross compilers packaged as noarch???
[11:30]  <f13> tibbs: no, the current java packages are not reviwed
[11:30]  <f13> at least the core ones.
[11:30]  <racor> thimm: yes target libs,
[11:30]  <tibbs> f13: I reviewed many Java packages for extras.
[11:30]  <thimm> why???
[11:30]  <tibbs> Well, they're just data.
[11:30]  <f13> tibbs: are they jpackage crap?
[11:30]  <tibbs> f13: Sort of, but I beat them into shape.
[11:30]  <thimm> tibbs: "why???" was for racor  ;)
[11:31]  <racor> thimm: target libs are just binary data, without any meaning to linux
[11:31]  * spot is back
[11:31]  <tibbs> Too many concurrent threads.  I'm not multi-core, I guess.
[11:31]  <racor> comparable to "firmware"
[11:31]  <f13> same reason wireless firmware are noarch
[11:31]  <rdieter> makes sense.
[11:31]  <tibbs> racor +1; it's just bits of data
[11:31]  <spot> yeah, that makes sense
[11:31]  <thimm> racor, f13: make sense, thansk for clarifcying
[11:32]  <racor> tibbs: but they can be elf => debuginfo
[11:32]  <spot> racor: i think when we have a cross-compiler guideline document, we can tie the two together
[11:32]  <thimm> Maybe worth mentioning the Ville's debuginfo page?
[11:32]  <tibbs> I guess you learn something new about RPM every day.
[11:33]  <tibbs> The debuginfo from those packages isn't in any way useful, is it?
[11:33]  <thimm> Perhaps with a croos-gdb
[11:33]  <thimm> corss-gdb
[11:33]  <thimm> arghhhh
[11:33]  <f13> cross-gdb ?
[11:33]  * rdieter boggles at that
[11:33]  <f13> (:
[11:33]  <thimm> cross-gdb, sorry for being illiterate
[11:33]  <f13> thimm: happems to the best of us
[11:34]  <thimm> ;)
[11:34]  <tibbs> In any case, that can probably be left to evolve for a bit.
[11:34]  <thimm> OK, are we done with that item?
[11:34]  <spot> i think so
[11:34]  <racor> tibbs: +1, yes it's a corner case, but I wouldn't be surprised if it hadn't already hit somewhere
[11:35]  <spot> i'd like to very briefly touch on the jpackage naming item
[11:35]  <tibbs> Was there movement there?
[11:35]  <spot> currently, the jpackage naming scheme is in violation of the Fedora naming guidelines
[11:35]  <spot> afaik, there is no movement to resolve this, despite rather significant effort
[11:36]  <tibbs> Wouldn't they be caught in any mass-review?
[11:36]  <f13> yes
[11:36]  <thimm> movement = convergment from the jpackage camp?
[11:36]  <spot> i think so.
[11:36]  <f13> There is a proposal on the board.
[11:36]  <f13> but no real input from the java folks.
[11:36]  <spot> i'm not sure anything is in our domain to do on this item anymore
[11:36]  <spot> i'd like to retire this one, since there is no changes we're making at this time
[11:37]  <tibbs> I forced the issue on the extras packages I reviewed and the packages were changed.
[11:37]  <f13> yeah, the proposal means no changes to our guidelines, so its up to them to either use the proposal, or propose something better
[11:37]  <rdieter> agreed, the java folks will have to step up when mass review hits... (:
[11:37]  <f13> but at this point, I don't think we should accept any new jpackage packages with the naming scheme.
[11:37]  <spot> f13: +1
[11:37]  <tibbs> !2
[11:37]  <tibbs> doh.
[11:37]  <tibbs> +1
[11:37]  <racor> f13: +1
[11:37]  <spot> tibbs: please, only vote with non-imaginary numbers. ;)
[11:37]  <abadger1999> f13: +1
[11:37]  <lutter> the problem wit hwaiting until mass review is that there will porbably be a time crunch etc. that makes people less inclined to actually resolve it
[11:38]  <spot> lutter: if they want their package in fedora, they'll make the trivial change.
[11:38]  <rdieter> lutter: then the java folks need to get off their asses.
[11:38]  <tibbs> True.  And we're not going to have a lot time to argue about this.
[11:38]  <lutter> we saw how well that works last time it came up
[11:38]  <tibbs> The proposed schedule is seriously tight.
[11:38]  <abadger1999> lutter: So you think we should issue a warning?  "Mass review coming up, all your packages are going to fail"
[11:38]  <spot> abadger1999: i think it might be prudent to do so
[11:38]  <f13> yes
[11:38]  * rdieter snickers
[11:39]  <spot> something similar to the email i sent out prior to fc6
[11:39]  <f13> I'm pinging our java folks right now...
[11:39]  <tibbs> I suppose someone could do a general sweep over all of the packages, looking for crap names.
[11:39]  <tibbs> We don't have to single out Java here.
[11:39]  <spot> tibbs: indeed
[11:39]  <spot> when i checked last time, i found lots of non-java badness in naming
[11:39]  <f13> yeah
[11:39]  <tibbs> That's a lot of work; did you use scripts?
[11:39]  <lutter> yeah, that's a good idea
[11:40]  <f13> we're slowly making noise about hte merger internally, as things move from proposals to accepted plans.
[11:40]  <spot> nah, i did it by hand, unfortunately
[11:40]  <rdieter> speaking of naming, when chatting with the rpmforge folks, they had issues with mixed-case package names.  Opinions?
[11:40]  <tibbs> I suspect a few regexps could help.
[11:40]  <spot> rdieter: what sort of issues?
[11:40]  <spot> they want it or don't want it?
[11:40]  <rdieter> they argued we should mandate lower-case names.
[11:40]  * scop would love all lowercase names, everywhere, period
[11:41]  <spot> rdieter: and, um, what exactly do we gain from that?
[11:41]  <tibbs> I personally prefer all lower-case, but upstream might have other ideas and we should try not to screw them over.
[11:41]  <spot> other than sane sorting. :)
[11:41]  <rdieter> spot: dunno, I didn't have much opinion.
[11:41]  <spot> this is tricky, as trademarks are case sensitive
[11:41]  <rdieter> rpmforge is already using lower-case, so we were hitting extras vs. rpmforge incompatibilities
[11:42]  <rdieter> of course, it was all *our* fault. (:
[11:42]  <thimm> rpmforge is not pure lower letters
[11:42]  <f13> spot: just wait for a trademark to include a space.
[11:42]  <lutter> given the realities, we can't do more than say 'packae names _should_ be all-lower case'
[11:42]  <spot> i'm not seeing any reasons to actually mandate lowercase vs mixedcase
[11:42]  <tibbs> I think we'd have to consider those case by case.
[11:42]  <f13> foo\ bar-1.0-2.src.rpm
[11:42]  <scop> we have had an item/discussion somewhere that would mandate adding an all-lowercase Provides if %{name} is not
[11:42]  <scop> I wonder where that has gone
[11:42]  <rdieter> well, how about I raise the issue on the ml, and we move on.
[11:42]  <spot> scop: yes, i remember that
[11:43]  <spot> i think it may have even been my idea
[11:43]  <f13> that doesn't help to make yum any faster :/
[11:43]  <thimm> but rpmforge is not using lower letters ...
[11:43]  <thimm> are we seeing issues were there are none?
[11:43]  <spot> How about we ask upstream what they prefer?
[11:43]  <racor> thimm: Yes
[11:43]  <spot> if they don't care, we go lowercase. if they care, we follow upstream.
[11:43]  * rdieter agrees with spot.
[11:44]  <racor> spot: confusion
[11:44]  <spot> racor: well, it makes mixedcase naming the corner case
[11:44]  <thimm> What about all our perl-Some-There packages?
[11:45]  <racor> Spot: How do you spell your name?
[11:45]  <spot> thimm: thats a good point
[11:45]  <spot> ~spot
[11:45]  <f13> thimm: thankfully they all provide perl(Some::There)
[11:45]  <f13> thimm: and all things should be using that method.
[11:45]  <scop> I don't think perl-Foo-Bar should be an exception
[11:45]  <tibbs> I really don't think we need to go mandating too much here; won't reason preclude someone from importing "pAcKaGe"?
[11:46]  <spot> tibbs: one can only hope
[11:46]  <scop> we had GiNaC
[11:46]  <scop> we have DevIL
[11:46]  <spot> but these are the upstream names
[11:46]  <tibbs> reason -1, I guess.
[11:46]  <racor> scop: We have Xt, Xaw, etc.
[11:46]  <f13> yeah, really, what are we buying by setting a mandate?
[11:46]  <f13> whats missing from our existing Naming Guidelines in this regard?
[11:46]  <thimm> Some metrics: FC devel has 104 Mixed vs 1060 lower case
[11:46]  <spot> perhaps this is a place for a recommendation
[11:46]  <racor> f13: plain nothing, this is just debianish zealotry again
[11:47]  <spot> rather than a MUST
[11:47]  <scop> what about the all-lowercase Provides?
[11:47]  <spot> scop: well, we know it will slow down yum, what do we gain?
[11:47]  <thimm> Provides are the real important bits!
[11:47]  <tibbs> One thing we should really try to avoid is two package names that differ only by case.
[11:48]  <scop> spot, got any figures exactly how much?
[11:48]  <spot> scop: i do not
[11:48]  <thimm> Mixed case slows down yum?
[11:48]  <spot> it should be something that can be tested (i'm not volunteering for this, i'm buried in aurora)
[11:48]  <rdieter> thimm: extraneous Provides do
[11:48]  <spot> thimm: no, adding additional Provides: lowercasename
[11:48]  <tibbs> More provides = more metadata.
[11:48]  <thimm> Ah, ok!
[11:48]  <scop> spot, well, I can say that mixed case names have slowed *me* down quite a few times - needed a few iterations and sometimes yum search to get something right
[11:49]  <spot> perhaps this is a yum plugin?
[11:49]  <spot> ignorecase ? :)
[11:49]  <tibbs> Although now they're talking about shipping raw sqlite databases as metadata, so who knows what the future will hold.
[11:50]  <spot> alright, next item
[11:50]  <racor> tibbs:future, we are just adopting 1970's standards, to make yum/rpm run on 6bit machines
[11:50]  <spot> Packages already reviewed for Core. Do they need to be re-reviewed for Extras?
[11:50]  <abadger1999> Yes.
[11:50]  <spot> I think the answer is yes.
[11:50]  <tibbs> I don't see why.
[11:50]  <abadger1999> Oh wait -- the reviewed packages?
[11:51]  <abadger1999> I think no.
[11:51]  <spot> i think the wording here is bad, as it applies to the merge
[11:51]  <thimm> Who reviewed withing Core and according to what guildleines?
[11:51]  <tibbs> I've reviewed core packages, according  to the guidelines in place at the time.
[11:51]  <spot> i think packages which have not gone through a formal Fedora review (not grandfathered in Core by Red Hat)
[11:51]  <spot> need to be reviewed as we merge
[11:51]  <f13> so here was my thinking.
[11:51]  <f13> once we do the merger, _every_ package CVS gains an 'unreviewed' file.
[11:52]  <f13> the only way you can remove htis file is by referencing the review bug ID
[11:52]  <tibbs> There is an opportunity for a grand cleanup here, but I just don't think we have the time to do it all.
[11:52]  <f13> there are many things in Extras that are unreviwed right now too
[11:52]  <rdieter> f13: right, grandfatherd from fedora.us.
[11:52]  <f13> we'll have to have some hounds watching CVS commits to make sure nobody is just removing the file without referencing a review ticket.
[11:52]  <f13> rdieter: also moved w/out review from Core
[11:52]  <spot> f13: how about a review file instead, containing either "unreviewed" or the bugzilla number
[11:52]  <scop> many folks disliked "flag" files in CVS in the last FE mass rebuild
[11:53]  <spot> that way, we can script query to list the unreviewed items
[11:53]  <f13> spot: that could work.
[11:53]  <tibbs> spot +1
[11:53]  <f13> scop: for what reason?
[11:53]  <scop> lots of files, lots of commits, did not notice, whatever
[11:53]  <f13> spot: this is in lieu of a package DB where the review bug could just be an entry in the packages db entry
[11:53]  <spot> f13: absolutely
[11:53]  <spot> the mythical package DB
[11:53]  <abadger1999> f13, spot: +1
[11:53]  * spot also wants a flying pony
[11:53]  <scop> why not a blocker bug or keyword in current bugzilla?
[11:53]  <scop> s/blocker/tracker/
[11:54]  <abadger1999> c4chris proposed a reviewURL field for the packageDB that I added.
[11:54]  <rdieter> spot: +1 (+1 to flying pony too)
[11:54]  <abadger1999> We can use the contents of the review file in cvs to fill that with data.
[11:54]  <f13> scop: ever tried to make changes to a bug that was on a blocker bug that blocked 3K other bugs?
[11:54]  <tibbs> bugzilla is so much more difficult for this kind of thing than a file in CVS.
[11:54]  <scop> f13, doh
[11:54]  <f13> brings bz to its knees pretty easily
[11:55]  <scop> ok
[11:55]  <spot> ok, 5 minutes left, i'd like to ask a simple question
[11:55]  <scop> and keyword?
[11:55]  <spot> since we have such good attendance
[11:55]  <thimm> Whatever method we use for tracking unreviewed packages, we need to think of a backup plan in case F7 is there and several important packages are not yet through with the review.
[11:55]  <scop> thimm++, not sure if it's our area though
[11:55]  <rdieter> thimm: we'll just have to make sure that doesn't happen. (:
[11:56]  <tibbs> spot: ?
[11:56]  <f13> thimm: barcamp hack session to chew through missing reviews
[11:56]  <spot> Here is my simple question: Do we want the License field to be detailed or simple?
[11:56]  <spot> I think this affects the policy we would make
[11:56]  <f13> Simple.
[11:56]  <tibbs> Ah, I was going to ask that.
[11:56]  <scop> simple
[11:56]  <rdieter> Simple
[11:56]  <tibbs> Spooge proposed something like:
[11:56]  <spot> simple
[11:56]  <racor> simple
[11:56]  <f13> simple or non-existant.
[11:56]  <tibbs> BSD, Original, See /usr/share/licenses/BSD.Original
[11:56]  <thimm> simple
[11:56]  <abadger1999> Much simpler than what smooge proposed :-)
[11:56]  <tibbs> I think that's just too much stuff.
[11:56]  <spot> tibbs: i agree wholeheartedly
[11:56]  <f13> License tag could be the location of the license file in teh package payload...
[11:57]  <f13> oh n/m
[11:57]  <tibbs> What about GPL versus GPLv1, GPLv2 ?
[11:57]  <spot> i think simple is the pretty clear winner there
[11:57]  <spot> tibbs: i think there is merit in some distinction
[11:57]  <thimm> Do we have any GPL1 packages at all?
[11:57]  <racor> tibbs: that's simple enough, IMO.
[11:58]  <f13> tibbs: those are actually different licenses, so yeah... :/
[11:58]  <spot> where it is relevant
[11:58]  <racor> thimm: they will come
[11:58]  <scop> f13, there's a %license macro apparently sometime meant for use in %files, but nobody knows how it works (and it probably doesn't nowadays)
[11:58]  <spot> for example, GPLv3
[11:58]  <tibbs> Frankly I've never read the GPLv1; for all I know it could be a typo fix.
[11:59]  <tibbs> scop: Well, the RPM news afoot may mean that it could be made useful.
[11:59]  <tibbs> The question is, should it?
[11:59]  <spot> so, part of this will come up in the course of the next round of license auditing
[11:59]  <spot> i'm going to try to accurately document the actual licenses of things
[11:59]  <spot> Distributable is a terrible lie
[11:59]  <tibbs> Indeed.
[11:59]  <spot> (for 99% of the packages carrying it)
[12:00]  <spot> ok. thats our time for the day. thanks everyone for coming out
[12:00]  <tibbs> What about "PHP License" versus just "PHP"?
[12:00]  <spot> i hope you all have a great holiday season
[12:00]  <f13> topic owners please send notes to maintainers-list about the things that passed.
[12:00]  <abadger1999> Before we all leave, FESCo asked us to consider a guideline to not use file deps outside of /etc and the bin dirs
[12:00]  <thimm> It's holiday? ;)
[12:00]  <tibbs> Ah, it's noon.  I'll continue on-list.
[12:01]  <f13> abadger1999: does '/usr/lib' and '/lib' count as 'bin dirs' ?
[12:01]  <spot> abadger1999: draft it, send it to the list for vote? :)
[12:01]  <tibbs> abadger1999: THL likes to propose things for us to do.
[12:01]  <scop> next meeting in 2007?
[12:01]  <abadger1999> I'll bring it up on the list unless people are vehemently opposed now :-)
[12:01]  <spot> or remind thl that we take drafts from anywhere
[12:01]  <spot> scop: yes, next meeting is... (looks)
[12:01]  <rdieter> (sorry, I was supposed to bring that up)
[12:01]  <spot> either Jan 2 or Jan 9
[12:01]  <abadger1999> f13: I'll have to check.  It's to help yum.
[12:01]  <spot> you guys going to be sobered up by Jan 2? :)
[12:01]  <f13> abadger1999: yes, but there are good reasons to file dep on lib files.
[12:02]  <tibbs> I have no objections.
[12:02]  <f13> or there was.
[12:02]  <scop> why sober in these meetings? ;)
[12:02]  *** thimm sets the channel topic to "Channel for Fedora packaging related discussion | Next Meeting: Tuesday, January 2nd, 2007 17:00 UTC".
[12:02]  <rdieter> f13: /usr/lib and /lib counts.
[12:02]  <abadger1999> k.  I'll draft something and send to the list.
[12:02]  <spot> /lib64/libc.so comes to mind
[12:02]  <racor> spot: Don't know yet, Jan 6 also is a holyday, here and I don't know if I'll be back Jan 2
[12:02]  <rdieter> Better stick with Jan 9. (:
[12:03]  <thimm> We'll be short on time for F7
[12:03]  <spot> we'll try for the 2nd, and fall back on the 9th if needed
[12:03]  <rdieter> ok, I'll (most) likely be here.
[12:03]  <spot> is anyone going to do the logs minutes?
[12:03]  <abadger1999> f13: Yes, lib dirs should be included as well.
[12:03]  <spot> (volunteers?)
[12:03]  <tibbs> I have them and will put them up.
[12:03]  <spot> tibbs: awesome, thanks.