From Fedora Project Wiki
(Redirected from Packaging:IRCLog20061219)
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.