From Fedora Project Wiki
Fedora Packaging Committee Meeting of {2008-02-12}
Present
- DavidLutterkort (
lutter) - JasonTibbitts (
tibbs) - JesseKeating (
f13) - RalfCorsepius (
racor) - RexDieter (
rdieter) - TomCallaway (
spot) - ToshioKuratomi (
abadger1999) - VilleSkyttä (
scop)
Writeups
No writeups this week.
Votes
The following proposals were considered:
- Guidelines for packages using ggc-client-libs
- http://fedoraproject.org/wiki/PackagingDrafts/GGZ
- Accepted (7-0)
- Voting for: spot rdieter abadger1999 tibbs lutter scop f13
- Voting against: (none)
This proposal provides some simple guidelines which moderate access to the ggz.modules file; several packages need to own or modify this file.
Other Discussions
The following additional items were discussed; see the logs for full details.
- http://fedoraproject.org/wiki/PackagingDrafts/OpenOffice.orgExtensions
- spot will present FPC's questions to Caolan.
- http://fedoraproject.org/wiki/PackagingDrafts/Lisp
- No response so far to abadger1999's questions.
- FPC is a bit short on Lisp expertise so any outside assistance would be appreciated.
- http://fedoraproject.org/wiki/PackagingDrafts/Java
- That's all we have for Java guidelines; we would really like to have more.
- Java-knowledgeable folks are desparately needed to help us cook up some useful guidelines for Java.
IRC Logs
[11:08] * spot looks around to see who might be here [11:08] * tibbs here [11:08] <spot> abadger1999, f13, lutter, rdieter, scop? [11:08] <abadger1999> here [11:08] <lutter> kinda here [11:09] <rdieter> quasi here [11:09] <f13> somewhat here. [11:09] <f13> (: [11:09] * scop here [11:09] <tibbs> Cool, a meeting. [11:10] <spot> ok, lets get started [11:11] <spot> http://fedoraproject.org/wiki/PackagingDrafts/OpenOffice.orgExtensions [11:11] <tibbs> I reviewed that first openoffice extension. [11:12] <tibbs> There's sort of the question of java guidelines being needed. [11:12] <spot> the obvious missing item there seems to be a naming guideline [11:13] <tibbs> That review was bug 386661 [11:13] <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=386661 medium, medium, ---, Jason Tibbitts, CLOSED RAWHIDE, Review Request: writer2latex - OpenOffice.org to LaTeX/XHTML filter [11:13] <spot> also, should these extensions depend on just openoffice.org-core, or depend on the specific n-v-r used at build time? [11:13] <tibbs> Perhaps not the best example as it bundled an OO extension as a subpackage. [11:16] <spot> I'm not opposed to anything in there, per se [11:16] <spot> but I'd prefer to have the naming and Requires issues resolved before approving it [11:16] <scop> "Extensions Should be installed unpacked if possible to save disk-space" [11:16] <scop> hm, how does unpacking save disk space? [11:17] <spot> scop: that is a good question. :) [11:17] --> racor has joined this channel (n=rc040203@HSI-KBW-082-212-056-027.hsi.kabelbw.de). [11:18] <spot> are there other questions or concerns we have about this draft? [11:18] <spot> racor: http://fedoraproject.org/wiki/PackagingDrafts/OpenOffice.orgExtensions [11:18] <rdieter> +1 to clarifying naming, Requires. [11:18] <spot> i'll email them to caolan and try to get him to resolve them. [11:20] <tibbs> I recall some weird bug reports about installing extensions while openoffice was actually running on the system. [11:20] <tibbs> Not something we have to worry about in guidelines but still kind of weird. [11:20] <spot> tibbs: ok, i'll ask him about that too [11:20] <spot> alright, lets move on to the next item: http://fedoraproject.org/wiki/PackagingDrafts/Lisp [11:21] <spot> i have concerns about the /usr/lib hardcoding and the total lack of a spec template. [11:22] <rdieter> nod [11:22] <abadger1999> I also sent email to Anthony Green but he never replied to the concerns raised there :-( [11:22] <spot> also, /usr/lib/common-lisp/bin/<impl>.sh is a little odd [11:22] <tibbs> rdieter: You have some experience with the lisp mess, don't you? [11:23] <rdieter> tibbs: only enough to be dangerous (and package maxima), beyond that, the guideline is mostly greek to me. [11:23] <tibbs> Wasn't it maxima that needs a lisp implementation around but you have a choice about which you install? [11:23] <rdieter> tibbs: yup [11:24] <racor> sorry, I am having networking probs. [11:24] <tibbs> I agree that it's good to clean up the lisp situation, but I'm not sure this actually cleans it up. [11:24] <abadger1999> https://www.redhat.com/archives/fedora-packaging/2008-January/msg00102.html [11:24] <rdieter> maxima-runtime-<foo> : foo = (clisp|cmucl|gcl|sbcl) [11:25] <rdieter> tibbs: afaict, the guide covers packaging of lisp libraries (which afaik, we have none) [11:25] <spot> abadger1999: yeah, we really need those questions answered. [11:25] <tibbs> It covers packaging of interpreters as well. [11:25] <spot> i'll send him another email. [11:27] <spot> alright, thats all the items which are ready for review right now (SysVInit and EclipsePlugins still need attention from me) [11:27] <tibbs> Has anyone heard anything about Java? [11:27] <f13> SysVInit, does that make sense given our move to Upstart? [11:27] * scop was just about to ask the java question too [11:27] <spot> nothing beyond http://fedoraproject.org/wiki/PackagingDrafts/Java [11:28] <spot> which isn't even remotely ready. [11:28] <abadger1999> f13: We should ask Casey about that. Initially Upstart will use SysV style scripts. [11:28] <tibbs> Yeah, there's not much there. [11:28] <spot> f13: yes, because we're still going to be using sysvinit scripts for a while [11:28] <f13> spot: I see. [11:28] <spot> and upstart will probably always support them [11:28] <tibbs> Should we attempt to write down some java things or would it be better to wait? [11:28] <spot> so having them standardized == good [11:29] <spot> tibbs: i would love to see someone knowledgable and/or motivated start writing things down [11:29] <spot> even if it is just to take what jpackage has and clean it up. [11:31] <spot> however, i will take the total silence as a lack of volunteers. [11:32] <scop> I am interested in that, and I guess one could say I'm somewhere near knowledgeable enough, but have very little time/energy these days [11:32] <spot> fair enough, we'll wait then. [11:32] <tibbs> I keep saying I'll write something down, but I know so little about java. [11:33] <spot> ok, the floor is open to any other topics: [11:33] <abadger1999> tibbs: Write something that 's totally wrong and then tell the java people that we're planning on making it the guidelines at the next meeting :-) [11:33] <scop> does anyone know for a fact whether someone's _actually_ working on the java guidelines at the moment? [11:33] <tibbs> abadger1999: I've considered it. [11:33] <rdieter> I haven't forgotten about working on octave draft, still on my todo list [11:34] <spot> scop: no, but I'll email overholt and ask [11:34] <rdieter> also, just sent something onlist about http://fedoraproject.org/wiki/PackagingDrafts/GGZ [11:34] <scop> spot, thanks [11:36] <spot> rdieter: looks good to me. [11:36] <abadger1999> Seems good. [11:36] <tibbs> I see no problems there. [11:37] <tibbs> Naming isn't an issue because these are just apps which use a set of libraries, right? [11:37] <rdieter> yeah, and there also exist ggz implementations that don't use ggz-client-libs directly too. [11:38] <tibbs> And wasn't there some issue with multiple packages wanting to modify a single plugins file? [11:38] <tibbs> Or is that unrelated to this draft? [11:38] <rdieter> yep, https://bugzilla.redhat.com/show_bug.cgi?id=431726 , which is what prompted the draft. :) [11:38] <buggbot> Bug 431726: low, high, ---, Rex Dieter, CLOSED RAWHIDE, freeciv and kdegames are fighting for /etc/ggz.modules [11:40] <tibbs> Do we expect that these ggz implementations will stay compatible and we won't have packages trying to do incompatible things to the modules file? [11:41] <tibbs> After all, ggz-client-libs only has version 0.0.14 [11:41] <rdieter> tibbs: there's an upstream spec, so yeah, compatibility is key (and presumably guaranteed). [11:42] <spot> +1 to the ggz draft [11:42] <rdieter> I've been trying to talk upstream into parsing this stuff at runtime, instead of relying on a static registration, and they're open to the idea, but not possible to implement in the current generation of the specification. [11:43] <tibbs> Given what we have to work with, I don't see why we should consider accepting this draft. [11:43] <spot> why we should? or shouldn't? :) [11:44] <tibbs> Erm, shouldn't consider accepting this draft. [11:44] <tibbs> Stoopid language. [11:44] <spot> :) lets vote on it then [11:44] <spot> +1 [11:44] <rdieter> +1 [11:44] <abadger1999> +1 [11:45] <tibbs> rdieter: Was the issue of needing >&/dev/null resolved? [11:45] <tibbs> I guess you didn't need it? [11:45] <rdieter> shouldn't be required. ggz-client is usually silent. [11:46] <tibbs> OK, +1. [11:46] <rdieter> hiding errors would mean hiding scriptlets that need fixing. [11:46] <spot> f13? lutter? racor? [11:46] <spot> scop? [11:47] <f13> sorry, in a second meeting. [11:47] <f13> reading backlog. [11:47] <lutter> +1 [11:47] <scop> +1, although I see little need for that simple macros (%_ggz_*) [11:48] <f13> +1 [11:48] <spot> ok, it passes [11:48] <f13> although why is it (usually) and what are the cases where it wouldn't? [11:48] <rdieter> scop: nod, that's certainly optional overkill. :) [11:49] <spot> are there any other items for today? [11:49] <spot> f13: "<rdieter> yeah, and there also exist ggz implementations that don't use ggz-client-libs directly too." [11:50] <abadger1999> spot: Did anything come of the call for fresh faces? Hans was interested. [11:51] <spot> abadger1999: thanks for the reminder. I'll send out an email about that today or tomorrow [11:51] <f13> I want to give up my spot.... [11:51] <spot> f13: yup, i have that in my notes [11:52] <rdieter> FPC: the fedora roach motel. [11:52] <rdieter> can't leave! [11:52] <rdieter> :) [11:53] <spot> ok, then i think we're done for today [11:53] <spot> thanks all. [11:53] <tibbs> I will summarize.