Packaging:Minutes20080212

Present

 * DavidLutterkort
 * JasonTibbitts
 * JesseKeating
 * RalfCorsepius
 * RexDieter
 * TomCallaway
 * ToshioKuratomi
 * VilleSkyttä

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] abadger1999, f13, lutter, rdieter, scop? [11:08] here [11:08] kinda here [11:09] quasi here [11:09] somewhat here. [11:09] (: [11:09]  * scop here [11:09]  Cool, a meeting. [11:10]  ok, lets get started [11:11]  http://fedoraproject.org/wiki/PackagingDrafts/OpenOffice.orgExtensions [11:11]  I reviewed that first openoffice extension. [11:12]  There's sort of the question of java guidelines being needed. [11:12]  the obvious missing item there seems to be a naming guideline [11:13]  That review was bug 386661 [11:13]  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]  also, should these extensions depend on just openoffice.org-core, or depend on the specific n-v-r used at build time? [11:13]  Perhaps not the best example as it bundled an OO extension as a subpackage. [11:16]  I'm not opposed to anything in there, per se [11:16]  but I'd prefer to have the naming and Requires issues resolved before approving it [11:16]  "Extensions Should be installed unpacked if possible to save disk-space" [11:16] hm, how does unpacking save disk space? [11:17] 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]  are there other questions or concerns we have about this draft? [11:18]  racor: http://fedoraproject.org/wiki/PackagingDrafts/OpenOffice.orgExtensions [11:18]  +1 to clarifying naming, Requires. [11:18]  i'll email them to caolan and try to get him to resolve them. [11:20]  I recall some weird bug reports about installing extensions while openoffice was actually running on the system. [11:20]  Not something we have to worry about in guidelines but still kind of weird. [11:20]  tibbs: ok, i'll ask him about that too [11:20]  alright, lets move on to the next item: http://fedoraproject.org/wiki/PackagingDrafts/Lisp [11:21]  i have concerns about the /usr/lib hardcoding and the total lack of a spec template. [11:22]  nod [11:22]  I also sent email to Anthony Green but he never replied to the concerns raised there :-( [11:22] also, /usr/lib/common-lisp/bin/ .sh is a little odd [11:22] rdieter: You have some experience with the lisp mess, don't you? [11:23] tibbs: only enough to be dangerous (and package maxima), beyond that, the guideline is mostly greek to me. [11:23] Wasn't it maxima that needs a lisp implementation around but you have a choice about which you install? [11:23] tibbs: yup [11:24] sorry, I am having networking probs. [11:24] I agree that it's good to clean up the lisp situation, but I'm not sure this actually cleans it up. [11:24] https://www.redhat.com/archives/fedora-packaging/2008-January/msg00102.html [11:24] maxima-runtime- : foo = (clisp|cmucl|gcl|sbcl) [11:25] tibbs: afaict, the guide covers packaging of lisp libraries (which afaik, we have none) [11:25] abadger1999: yeah, we really need those questions answered. [11:25] It covers packaging of interpreters as well. [11:25] i'll send him another email. [11:27] alright, thats all the items which are ready for review right now (SysVInit and EclipsePlugins still need attention from me) [11:27] Has anyone heard anything about Java? [11:27] SysVInit, does that make sense given our move to Upstart? [11:27] * scop was just about to ask the java question too [11:27] nothing beyond http://fedoraproject.org/wiki/PackagingDrafts/Java [11:28] which isn't even remotely ready. [11:28] f13: We should ask Casey about that. Initially Upstart will use SysV style scripts. [11:28] Yeah, there's not much there. [11:28] f13: yes, because we're still going to be using sysvinit scripts for a while [11:28] spot: I see. [11:28] and upstart will probably always support them [11:28] Should we attempt to write down some java things or would it be better to wait? [11:28] so having them standardized == good [11:29] tibbs: i would love to see someone knowledgable and/or motivated start writing things down [11:29] even if it is just to take what jpackage has and clean it up. [11:31] however, i will take the total silence as a lack of volunteers. [11:32] 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] fair enough, we'll wait then. [11:32] I keep saying I'll write something down, but I know so little about java. [11:33] ok, the floor is open to any other topics: [11:33] 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]  does anyone know for a fact whether someone's _actually_ working on the java guidelines at the moment? [11:33]  abadger1999: I've considered it. [11:33]  I haven't forgotten about working on octave draft, still on my todo list [11:34]  scop: no, but I'll email overholt and ask [11:34]  also, just sent something onlist about http://fedoraproject.org/wiki/PackagingDrafts/GGZ [11:34]  spot, thanks [11:36]  rdieter: looks good to me. [11:36]  Seems good. [11:36]  I see no problems there. [11:37]  Naming isn't an issue because these are just apps which use a set of libraries, right? [11:37]  yeah, and there also exist ggz implementations that don't use ggz-client-libs directly too. [11:38]  And wasn't there some issue with multiple packages wanting to modify a single plugins file? [11:38] Or is that unrelated to this draft? [11:38] yep, https://bugzilla.redhat.com/show_bug.cgi?id=431726, which is what prompted the draft. :) [11:38] Bug 431726: low, high, ---, Rex Dieter, CLOSED RAWHIDE, freeciv and kdegames are fighting for /etc/ggz.modules [11:40]  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]  After all, ggz-client-libs only has version 0.0.14 [11:41]  tibbs: there's an upstream spec, so yeah, compatibility is key (and presumably guaranteed). [11:42]  +1 to the ggz draft [11:42]  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]  Given what we have to work with, I don't see why we should consider accepting this draft. [11:43]  why we should? or shouldn't? :) [11:44] Erm, shouldn't consider accepting this draft. [11:44] Stoopid language. [11:44] :) lets vote on it then [11:44]  +1 [11:44]  +1 [11:44]  +1 [11:45]  rdieter: Was the issue of needing >&/dev/null resolved? [11:45]  I guess you didn't need it? [11:45]  shouldn't be required.  ggz-client is usually silent. [11:46]  OK, +1. [11:46]  hiding errors would mean hiding scriptlets that need fixing. [11:46]  f13? lutter? racor? [11:46]  scop? [11:47]  sorry, in a second meeting. [11:47]  reading backlog. [11:47]  +1 [11:47]  +1, although I see little need for that simple macros (%_ggz_*) [11:48]  +1 [11:48]  ok, it passes [11:48]  although why is it (usually) and what are the cases where it wouldn't? [11:48]  scop: nod, that's certainly optional overkill. :) [11:49] are there any other items for today? [11:49] f13: " yeah, and there also exist ggz implementations that don't use ggz-client-libs directly too." [11:50] spot: Did anything come of the call for fresh faces? Hans was interested. [11:51] abadger1999: thanks for the reminder. I'll send out an email about that today or tomorrow [11:51] I want to give up my spot.... [11:51] f13: yup, i have that in my notes [11:52] FPC: the fedora roach motel. [11:52] can't leave! [11:52] :) [11:53]  ok, then i think we're done for today [11:53]  thanks all. [11:53]  I will summarize.