From Fedora Project Wiki

Revision as of 16:35, 24 May 2008 by Ravidiip (talk | contribs) (1 revision(s))

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:

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.

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.
Retrieved from "https://fedoraproject.org/w/index.php?title=Packaging:Minutes20080212&oldid=16107"