From Fedora Project Wiki

Revision as of 14:13, 24 May 2008 by fp-wiki>ImportUser (Imported from MoinMoin)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Fedora Packaging Committee Meeting of {2008-04-01}

Present

  • HansdeGoede (hansg)
  • JasonTibbitts (tibbs)
  • RalfCorsepius (racor)
  • RexDieter (rdieter)
  • TomCallaway (spot)
  • ToshioKuratomi (abadger1999)
  • VilleSkyttä (scop)

Writeups

The following drafts have been accepted by FESCO and are to be written into the guidelines:

Votes

Four new documents for FESCo's consideration this week. The following proposals were considered:

  • Java guidelines
  • http://fedoraproject.org/wiki/PackagingDrafts/Java
  • This is the first vote for this draft, but it's the culmination of significant work and discussion
  • Accepted (5 - 1)
  • Voting for: tibbs spot rdieter hansg scop
  • Voting against: abadger1999

Other Discussions

The following additional items were discussed; see the logs for full details.

  • FPC will meet again April 8, and will then hopefully return to meeting every other week.

IRC Logs

[12:05]  * spot coughs
[12:05]  * rdieter puts fpc hat on
[12:05]  * rdieter curses that other group
[12:05]  * hansg is present and waiting
[12:06]  * abadger1999 appears
[12:06]  <spot> racor, tibbs, scop?
[12:06]  <tibbs> been here all along
[12:07]  <scop> here
[12:07]  <racor> here (for now)
[12:07]  * spot isn't sure where Rathann is
[12:08]  <spot> so, i guess we'll get started
[12:08]  <spot> first item on the agenda is: http://fedoraproject.org/wiki/PackagingDrafts/Java
[12:09]  <spot> as originally promised, i am -1 on this, due to the lack of rationale for the continued naming exception
[12:09]  <overholt> I'd like to propose that we don't waste time discussing the naming exception here
[12:09]  <tibbs> I was hoping we could separate the naming issue from the guidelines.
[12:09]  <overholt> let's get the rest of the guidelines in shape and then we can deal with that issue
[12:09]  <dbhole> I agree
[12:10]  <spot> overholt: my concern is that i do not want to reinforce that the naming exception is a good thing
[12:10]  <spot> and since the draft explicitly grants it
[12:10]  <overholt> spot: I don't think anyone is getting that impression from you :)
[12:10]  <spot> we'd be taking in new packages with the jpp tag
[12:10]  <overholt> I don't expect the draft to pass
[12:10]  <spot> and i'd like to just have that stop now.
[12:10]  <overholt> I just don't want to deal with it here
[12:10]  <overholt> as in today
[12:10]  <overholt> I want to get everything else straightened around first
[12:10]  <hansg> tibbs +1 (I was hoping we could separate the naming issue from the guidelines)
[12:11]  <tibbs> Unfortunately I have not had sufficient time to actually review any packages using these guidelines.  Just no free time lately.
[12:11]  * spot suggests that it should not be in the draft if the intent is separation
[12:11]  <hansg> as the jpp release tag extension is in a different already approved guidelines doc, and the java guidelines just contain a pointer, lets leave it at that (just a pointer) and then eventually
[12:11]  <hansg> get around to updating the jpp release tag guidelines
[12:12]  <overholt> I think they should eventually be a part of the guidelines (either way - with or without the jpp thing)
[12:12]  <overholt> but for now, I want to discuss the *rest of* the draft
[12:12]  <hansg> overholt, +1 (discussing the *rest* of the draft)
[12:13]  <tibbs> Keep in mind that the draft has changed since this meeting started.
[12:13]  <overholt> it has?
[12:13]  <hansg> If its really a blocker (and there are no others) maybe its an option to remove the link to the jpp release tag from the java giuidelines
[12:13]  <tibbs> Well, the comments bit has.
[12:13]  <tibbs> I just got two more change notices.
[12:13]  <overholt> oh, Tom added "I agree" comments
[12:14]  <scop> I added some small bits a minute ago
[12:14]  <scop> (more comments, that is)
[12:14]  <overholt> hansg: I really don't expect the guidelines to pass as they are due to the release tag issue.  I *really* just want to deal with everything else first and deal with that separately since it's such a contentious issue.
[12:14]  <tibbs> Did we ever get an answer to the question of why two is the magic number in "If the number of provided JAR files exceeds two, you must place them into a sub-directory." ?
[12:15]  <overholt> Nicolas responded to that
[12:15]  <tibbs> With now four different places this draft has been discussed, it's tough to keep track.
[12:15]  <tibbs> IRC, telephone, wiki, mailing list.
[12:15]  <overholt> yup
[12:16]  <tibbs> There's an open question in the "class-path-in-manifest" bit.
[12:17]  <overholt> yup, I wrote that
[12:17]  <overholt> I honestly don't know if it will
[12:17]  <overholt> but someone requested an example o fit
[12:17]  <overholt> of it
[12:17]  <overholt> where "it" = using sed to fix the issue
[12:17]  <spot> i think i just requested an example of how to do this workaround, not that you had to use sed (or anything else specific)
[12:18]  <overholt> and I gave an example
[12:18]  <spot> :)
[12:18]  <overholt> :)
[12:18]  <spot> so, the issue is whether your example violates the java doc you pointed to
[12:18]  <overholt> yup
[12:19]  <hansg> AFAIK sed doesn't change line endings
[12:19]  <hansg> But if I read this sed command correctly it deletes a line, right?
[12:19]  <overholt> yeah
[12:20]  <overholt> my concern is this text on that linked page:  "Warning : The text file must end with a new line or carriage return. The last line will not be parsed properly if it does not end with a new line or carriage return."
[12:20]  <overholt> but I don't *think* that sed command will mess this up
[12:20]  <overholt> but I thought I'd err on the side of safety and put the question there
[12:21]  <spot> instead of a question
[12:21]  <hansg> OKay I just tried this on 2 txt files, one with dos, one with unix line endings, works fine
[12:21]  <overholt> hansg: thanks
[12:21]  <spot> perhaps simply noting that item, and saying something like "please be sure that any files edited in this manner end with a new line or carriage return"
[12:21]  <overholt> done
[12:22]  <overholt> (as in "I'll do it")
[12:22]  <spot> aside from the release tag, I'm +1 on the rest of the draft.
[12:22]  <scop> I think my earlier comments about javadocs were addressed a bit lightly
[12:22]  <hansg> So what issues do we have with this that need discussion beside the release tag?
[12:22]  <scop> http://fedoraproject.org/wiki/PackagingDrafts/Java?action=diff&rev2=38&rev1=37
[12:23]  <hansg> From the questions I see versioned or not versioned jars
[12:23]  <overholt> scop: okay.  how would you prefer it was addressed?
[12:23]  <overholt> hansg: yeah, that's something that needs to be discussed.  apparently no one cares either way except scop and Nicolas.
[12:24]  <scop> overholt, "without file://", "should be crosslinked" somewhere more prominent than just a comment in spec template
[12:24]  <dbhole> Currently, there are both, versioned and unversioned. So the dirs are bookmarkable. That said though, I don't see any reason why we cannot fall back to the same path as jars and have only unversioned
[12:24]  <scop> dbhole, are you talking about the javadoc dirs?
[12:24]  <overholt> scop: alright, I'll add it to my list of fixes
[12:24]  <dbhole> s/same path as jars/same strategy as jars
[12:24]  <dbhole> scop: yes
[12:24]  <hansg> Well I kinda like the versioned jars, as that way one can easily see what version one has, even if one is not good with rpm-foo
[12:25]  <scop> dbhole, it's unversioned only in the current draft for javadocs
[12:25]  <tibbs> Overall I am impressed with this draft.
[12:25]  <dbhole> scop: Doh.. I guess I missed that change. Nvm then, sorry.. originally they had both and I assumed that that was still the case
[12:26]  <scop> hansg, I don't think that's a very good argument
[12:26]  <overholt> didn't Nicolas have arguments in favour of versioned jar symlinks?
[12:26]  <tibbs> This is a terribly complex subject and I don't think we can get it 100% correct on the first try.
[12:26]  <scop> hansg, we don't have that for just about anything else either, I don't see why jars would be different
[12:27]  <hansg> Actually we do, for .so files, jars are not much different from so files actually they are very much alike
[[At this point there was a minor netsplit.  No committee members were dropped.]  
[12:27]  <scop> .so versions != package-they-belong-to-versions
[12:27]  <rdieter> tibbs: +1
[12:27]  <hansg> true
[12:27]  <hansg> tibbs:::: +1
[12:28]  <spot> fwiw, this is a solid first attempt, enough to lift the hold (if it passes)
[12:28]  <scop> Nicolas said he doesn't have strong opinions
[12:28]  <tibbs> Can we leave the versioned jar question open in the guideline?
[12:28]  <hansg> I don't have a strong opinion either way either
[12:28]  <tibbs> I.e. don't require it, but don't ban it.
[12:29]  <scop> having it in the guideline is more or less recommending it
[12:29]  <tibbs> Don't mention it at all, then?
[12:29]  <scop> I'd be more happy with that
[12:29]  <hansg> I say lets leave it as is (so versioned with an unversioned symlink), this leaves a better migration path to some sort of API version embedding in the name, then unverisoned
[12:30]  <hansg> Also this would mean less deviation from jpackage standard, so easier sync with them
[12:30]  <overholt> I believe that part was just copied from the JPackage guidelines (which we originally wanted to just reference but ...)
[12:30]  <tibbs> OK, does leaving it in lower the chances of this draft patching?
[12:30]  <abadger1999> Sorry, I haven't read the entirety of the thread but were spot's points #2 and #8 satisfactorily answered?
[12:30]  <scop> it's a difference between my 0 and +1
[12:30]  <tibbs> Personally I don't understand the issue sufficiently; I just care whether the requirements are clear enough.
[12:31]  <tibbs> So, Hans, will you vote against the draft if the versioned bits are removed?
[12:31]  <overholt> abadger1999: #8 can't be fixed until some other bugs are fixed
[12:31]  <abadger1999> overholt: How does it fix/prevent the problem?
[12:31]  <spot> #2 is answered to my satisfaction
[12:32]  <spot> and i'm convinced that #8 is a work in progress
[12:32]  <abadger1999> spot: Was that just nicolas's one email on the subject?
[12:32]  <scop> hm, what are these #'s we're talking about?
[12:32]  <spot> no, several emails
[12:32]  <hansg> nope
[12:32]  <abadger1999> scop: https://www.redhat.com/archives/fedora-packaging/2008-March/msg00186.html
[12:32]  <racor> sorry, my time for today is up, I got to quit.
[12:32]  <scop> abadger1999, thanks
[12:32]  <hansg> thats a bit ambigious I will not vote against the draft if the versioned jar stuff is removeed
[12:32]  <overholt> racor: I did a script for pde build and everything!
[12:33]  <tibbs> racor: Did you have any opinion on the current draft?
[12:33]  <overholt> racor: just for you!  :)
[12:33]  <abadger1999> Sorry again, Does someone have a pointer to where that discussion starts?  I can't dig through the thread fast enough :-(
[12:34]  <spot> abadger1999: Tom Fitzsimmons gave a good answer on Wed, 26 Mar 2008
[12:35]  <spot> targeting full multilib enablement for Java in F10
[12:35]  <tibbs> I can accept that.
[12:35]  <tibbs> Since stuff will be hidden by macros, we'll just need a rebuild once things are ready.
[12:36]  <spot> ok guys, excluding the release tag mess (which we can handle separately by repealing the JPackage naming exception)
[12:36]  <spot> lets get votes on this draft
[12:36]  <tibbs> +1
[12:36]  <spot> +1
[12:36]  <rdieter> +1
[12:36]  <scop> jar versioning in or out?
[12:37]  <hansg> +1 (both with and without versioned jars)
[12:37]  <abadger1999> spot: I think I understand the problem.  I'm wondering -- is using /usr/lib a "solution" because it creates a Conflict and therefore doesn't allow multiples to be installed?
[12:37]  <abadger1999> -1
[12:37]  <fitzsim> abadger1999: no
[12:37]  <fitzsim> abadger1999: currently 32- and 64-bit JDK packages can be installed in parallel
[12:37]  <scop> 0 with versioned jars, +1 without
[12:38]  <fitzsim> abadger1999: in /usr/lib/java-version-vendor{,.%[arch}}
][12:38]  <fitzsim> abadger1999: the problem is rpm screws up running post sections on upgrades, causing alternatives symlink breakage
[12:38]  <spot> overholt: welp, if you pull the versioned jars out of the draft, it will pass. otherwise, it doesn't.
[12:38]  <tibbs> abadger1999: Is the libdir thing your only objection?
[12:38]  * overholt doesn't care either way
[12:39]  <fitzsim> overholt: let's just pull them out
[12:39]  <tibbs> It would be nice to have concensus.
[12:39]  <overholt> does it break JPackage compatibility (much)?
[12:39]  <abadger1999> tibbs: NO I also am not satisfied with nim-nim's answer to #2.
[12:39]  <dbhole> It will create an additional discrepancy with the jpackage style, but I am find with it
[12:39]  <spot> abadger1999: the wording has been changed on the draft
[12:39]  <overholt> yay for NIH->forks
[12:39]  <dbhole> overholt: afaik, no it will not creak compatibility
[12:39]  <overholt> dbhole: cool
[12:39]  <dbhole> s/creak/break
[12:39]  <abadger1999> 88 I'd like to understand, (thanks fitzsim).  but #2 is my big sticky point
[12:39]  * abadger1999 rereads
[12:39]  <scop> I think we don't usually let things that we don't know what they're for through to guidelines, that's all
[12:40]  <spot> abadger1999: "Over time, we would like to remove any divergences in these documents, but where they are different, these Fedora guidelines will take precedence for Fedora packages."
[12:40]  <fitzsim> dbhole: jpackage could adopt the same strategy to regain compatibility
[12:40]  <overholt> scop: you're the author on the original source :)
[12:40]  <scop> right :)
[12:40]  <overholt> scop: (one of them)
[12:40]  <dbhole> fitzsim: Yes, I agree. If it passes without versioned on Fedora, I was thinking of proposing the same on JPackage.
[12:40]  <overholt> since no one really cares, let's remove that bit
[12:40]  <fitzsim> abadger1999: what's #2?
[12:41]  <scop> overholt, but as I said on fedora-devel, I've never understood it
[12:41]  <abadger1999> #2 is the "JPackage is the canonical source" pointer.
[12:41]  <overholt> scop: I know.  I was just pointing that out in case others didn't know that :)
[12:41]  <spot> abadger1999: i'm ok with the clarification that the Fedora guidelines trump Jpackage guidelines in fedora-space
[12:41]  <overholt> scop: and we just copied those bits since we had to have something at fp.o
[12:42]  <abadger1999> My issue with nicolas's justification is that .desktop files and such are pointers to specific functions.
[12:42]  <overholt> scop: but either way we'll remove them from the draft
[12:42]  <abadger1999> This pointer is  more of an overlay.
[12:42]  <scop> overholt, thanks
[12:42]  <overholt> (how does a single 0 make the vote swing one way?)
[12:42]  <abadger1999> I think it makes things more complex for a reviewer or new java packager this way.
[12:42]  <spot> overholt: takes +5 to pass
[12:42]  <overholt> spot: ah
[12:42]  <scop> 0 and -1 have no real difference
[12:43]  <overholt> -1 doesn't take away?
[12:43]  <abadger1999> I'd rather see one of the following: 1) Specific pointers from a section in Fedor aGuidelines to the JPackage Guidelines.
[12:43]  <scop> no
[12:43]  <spot> overholt: no.
[12:43]  <abadger1999> or 2) Read this version of the JPackage Guidelines and add the following Fedora specific changes.
[12:44]  <fitzsim> abadger1999: I tend to agree
[12:44]  <abadger1999> I would favor option 1 over option 2 because the java guidelines are much more complex than something like .desktop files.
[12:44]  <overholt> we were asked to bring sections of the JPackage guidelines in so we did
[12:44]  <overholt> I preferred the "use the JPackage guidelines with these exceptions" option, too
[12:44]  * spot doesn't deny that such changes would make things better
[12:45]  <dbhole> I had one minor thing. Can we add to the drafts a note along the lines of: "If you are trying to add a new package, it may be worth your time to check jpackage.org to see if a package already exists there, and import that package, fixed as per this guideline"
[12:45]  <spot> but i think that the most important thing is getting some solid guidelines approved so we can lift this hold
[12:45]  <abadger1999> overholt: Yah.  I'm perfectly fine with what was brought in.  I'm just against having to read two documents and keep track of which is overriding the other where.
[12:45]  <overholt> ah yes, the amazing hold
[12:45]  <overholt> abadger1999: I agree it's confusing.  To me, too :)
[12:45]  <abadger1999> :-)
[12:45]  <fitzsim> abadger1999: I think we should definitely give credit to the jpackage guidelines, but there was no point in this whole exercise if we still make people read the Jpackage policies
[12:45]  <overholt> +1
[12:46]  <spot> anyways, without the versioned jars in the draft, the draft passes
[12:46]  <dbhole> Most jpackage packages are very close to Fedora, and there is no reason Fedora should re-invent the wheel -- not to mention it could add a further divide in compatibility
[12:46]  <overholt> I like dbhole's addition
[12:46]  * spot notes that we have several other things to try to get through today
[12:46]  <overholt> it doesn't change anything
[12:46]  <overholt> so what's the next step, spot?
[12:46]  <scop> fitzsim, (slightly off topic) did you notice the find_jar bug I came across in https://www.redhat.com/archives/fedora-devel-list/2008-March/msg02346.html ?
[12:46]  <dbhole> fitzsim: Not making them read policies. Just importing the package from there. There is no need for the imported to read jpp guidelines, only Fedora ones. And they will read those anyway
[12:46]  <spot> overholt: FESCo has to pass it
[12:46]  <hansg> Maybe we should pass this one with the versioned jar stuff removed to get the hold lifted and then take a look at a new improved version in 2 weeks
[12:46]  <overholt> spot: so do we make the changes now?
[12:47]  <fitzsim> dbhole: right, we're talking about two different things
[12:47]  <spot> overholt: please take out the versioned jar stuff
[12:47]  <spot> overholt: but thats all
[12:47]  <overholt> spot: okay.
[12:47]  <dbhole> fitzsim: oops.. nvm
[12:47]  <spot> next item: http://fedoraproject.org/wiki/PackagingDrafts/SysVInitScript
[12:47]  <hansg> with improved I mean a new version that addresses abadger1999 concerns about having to read 2 documents
[12:48]  <spot> i re-added try-restart
[12:48]  * hansg is reading
[12:48]  <fitzsim> abadger1999: can you add your objection to the comments section of the draft?
[12:48]  <spot> http://fedoraproject.org/wiki/PackagingDrafts/SysVInitScript?action=diff&rev2=18&rev1=17
[12:48]  <-- abadger1999 has left this server ("Leaving.").
[12:48]  <scop> spot, thanks
[12:48]  <fitzsim> dbhole: can you add a comment saying we should explicitly tell people to check if jpackage has the package first in case it saves them work?
[12:49]  <dbhole> fitzsim: Sure. I will add that.
[12:49]  --> abadger1999 has joined this channel (n=abadger1@65.78.187.68).
[12:50]  <overholt> scop: I removed the versioned stuff.  Please check to make sure it's okay now ... when you get a chance.  Thanks.
[12:50]  <abadger1999> fitzsim: Yes, I'll do that.
[12:50]  <scop> overholt, thanks, will do later tonight
[12:50]  * spot assumes folks are reading the SysVInit draft
[12:51]  * tibbs on the phone.
[12:51]  <tibbs> I wonder about this draft, though, because isn't upstart supposed to be changing the way we do this?
[12:51]  <spot> tibbs: upstart scripts would not be SysV-style initscripts
[12:52]  <spot> this draft is focused on SysV-style initscripts
[12:52]  <spot> the long term plan is to migrate to upstart standard scripts
[12:52]  <spot> but the standard isn't in place for them
[12:52]  <spot> so, we're SysV for the forseeable future
[12:53]  <hansg> I think this is a good and much needed draft, but ....
[12:53]  <spot> but? :)
[12:53]  <hansg> There also should be examples added for chkconfig and LSB comments for services which are off by default
[12:54]  <spot> i can just change the examples to be off by default
[12:54]  <hansg> This is still one of my bug questions for LSB comments / INIT INFO blocks
[12:54]  <spot> actually, i'll just add an example
[12:55]  <hansg> To be clear, the .spec file example is fine, but I would like to see the small (single line) examples in the more detailed description in both versions
[12:56]  <hansg> btw s/bug question/big question/
[12:56]  <spot> i just added examples for LSB and chkconfig
[12:56]  <spot> off by default
[12:57]  <spot> http://fedoraproject.org/wiki/PackagingDrafts/SysVInitScript?action=diff&rev2=20&rev1=18
[12:57]  <spot> are we ready for a vote here? :)
[12:59]  * spot wonders if he's talking to himself
[12:59]  * overholt is still listening in the hopes that the EclipsePlugins draft comes up
[12:59]  <tibbs> This seems fine to me. (Still on the phone, sorry.)
[12:59]  <spot> ok, lets take a vote:
[12:59]  <spot> +1
[13:00]  <scop> +1
[13:00]  <hansg> +1
[13:00]  <rdieter> +1
[13:00]  <abadger1999> +1
[13:00]  <hansg> So ... the line should be omitted to be off by default, which genius came up with that ?? Anyways next draft ...
[13:00]  <spot> thats a +5. tibbs, i'm assuming your "fine to me" is a +1 as well.
[13:00]  <spot> if not, feel free to note your correction
[13:00]  <tibbs> Yes, thanks.
[13:01]  <spot> since overholt is here, lets try http://fedoraproject.org/wiki/PackagingDrafts/EclipsePlugins
[13:01]  <hansg> Any changes from last week?
[13:02]  <spot> all of the pain in the %build is now in a script: pdebuild
[13:02]  <spot> the base eclipse package provides this
[13:03]  <tibbs> That looks much simpler.
[13:03]  * spot is much happier with that
[13:04]  <abadger1999> hansg: I think this is the diff: http://fedoraproject.org/wiki/PackagingDrafts/EclipsePlugins?action=diff&rev2=45&rev1=41
[13:04]  <tibbs> I don't think I had any real objections to this last week.
[13:04]  <scop> overholt, any thoughts about inclusion of source jars?
[13:05]  <overholt> scop: nope
[13:05]  <overholt> scop: that's a tough issue
[13:06]  <spot> ok, lets take a vote on this one:
[13:06]  <spot> +1
[13:06]  <rdieter> +1
[13:06]  <tibbs> +1
[13:06]  <abadger1999> +1
[13:06]  <scop> in a perfect world, it'd be cool if there were -debuginfo packages containing the sources (also for noarch) and eclipse would automagically pick them up
[13:06]  <overholt> hence it being a perfect world :)
[13:06]  <hansg> Hmm, considering that eclipse is written in java, I assume most plugins will be written in java too, since we say people should use gcj, shouldn't the example spec file include gcj calls rather then a pointer to the GCJ guidelines?
[13:06]  <overholt> *all* plugins will be written in java
[13:07]  <scop> +1, but I think a small note about the source jars and possible mismatches when linking binary jars to system ones wouldn't hurt
[13:07]  <overholt> scop: I'll add something
[13:07]  <scop> overholt, thanks
[13:07]  <spot> ok, thats a +5.
[13:07]  <overholt> yay
[13:07]  <scop> my time's up for tonight
[13:08]  <hansg> I like it in general, but I would like to see gcj aot explicitly added to the example spec, any reasons not todo this?
[13:08]  <overholt> yes
[13:08]  <overholt> we don't want to confuse the issue
[13:08]  <overholt> it's going away
[13:08]  <spot> scop: thanks for your time
[13:08]  <overholt> and keeping it separate is best
[13:08]  <hansg> ok I can live with that, +1
[13:08]  <overholt> hansg: does that make sense?
[13:08]  <fitzsim> scop: thanks
[13:08]  <scop> thanks all
[13:08]  <overholt> scop: thanks for the comments
[13:08]  <overholt> (taht wasn't sarcastic)
[13:08]  <spot> we'll be back on schedule for next week
[13:08]  <spot> (where we deal with the remaining bombs on the todo list)
[13:09]  <scop> like I have mentioned to some people earlier, now that we seem to have the java packaging sorted out, I think it's time for me to step down from the FPC
[13:09]  <tibbs> "back on schedule" means "meet next week, then two weeks after"
[13:09]  <spot> scop: ok, we'll work on filling your seat. :)
[13:09]  <spot> tibbs: yes.
[13:09]  <spot> barring any other emergencies, of course.
[13:10]  <spot> floor is open to any quick items (we're already overtime)
[13:11]  <hansg> The gcj guidelines seem to be missing from the schedule
[13:11]  <scop> spot, if it starts to look time consuming, I can stick around a while longer so that there's quorum in the meetings etc
[13:11]  <scop> just let me know how it goes
[13:13]  <-- scop has left this channel ("Leaving").
[13:13]  <hansg> Erm anyone see my quick item:
[13:13]  <hansg> The gcj guidelines seem to be missing from the schedule
[13:13]  <spot> i'll add them
[13:13]  <hansg> Ok, what is there status (ready for next week)?
[13:13]  <fitzsim> hansg: what are the issues there?
[13:14]  <hansg> None that I know of
[13:14]  <hansg> But they weren't on the schedule for approval
[13:14]  <fitzsim> aren't they implicit in the java guidelines?
[13:14]  <spot> fitzsim: nope.
[13:15]  <overholt> I couldn't edit the schedule
[13:15]  <fitzsim> weird
[13:15]  <spot> overholt: yes you can, it lives at PackagingDrafts/DraftsTodo
[13:15]  <overholt> huh
[13:15]  <overholt> oh well
[13:15]  <fitzsim> they're linked from the java guidelines and useless in their absense
[13:15]  <spot> fitzsim: fwiw, i fully expect them to pass quickly
[13:15]  * hansg too
[13:15]  <fitzsim> like now?
[13:15]  <hansg> (pass quickly)
[13:16]  <hansg> maybe we can vote now?
[13:16]  <spot> i suppose we barely have quorum
[13:16]  <spot> http://fedoraproject.org/wiki/PackagingDrafts/GCJGuidelines
[13:16]  <hansg> its sorta strange to have the java guidelines approved, while they are pointing to a draft
[13:16]  * abadger1999 looks
[13:16]  * hansg is rereading to make sure
[13:16]  <spot> +1 from me
[13:17]  <abadger1999> Do we want to mention Fedora < 9?
[13:17]  <overholt> why?
[13:17]  <hansg> +1
[13:17]  <rdieter> +1
[13:18]  * tibbs still on the damn phone.
[13:18]  <abadger1999> As writtent it appears to only apply to Fedora 9.
[13:18]  <hansg> Nope, 8 too
[13:19]  <hansg> and for 7 not using gcj is not an option (nothing else to build with available there)
[13:19]  <spot> Perhaps changing 9 to be 8+ would be more clear?
[13:19]  <overholt> fitzsim: can you make the change?
[13:19]  <hansg> Jip, missed that one, that 9 definitely should be a 8+
[13:20]  <fitzsim> overholt: sure
[13:20]  <overholt> it's slightly messy since F8 didn't have "OpenJDK" branded as such
[13:20]  <spot> abadger1999, tibbs (on damn phone), we need votes on this one (with 8+)
[13:20]  <hansg> then do a 's|OpenJDK|OpenJDK / IcedTea|g'
[13:20]  <abadger1999> Do #4 & 5 mean "If there is already a %post, only add   %{_bindir}/rebuild-gcj-db" or do they mean "add if [ -x %{_bindir}/rebuild-gcj-db ]  then   %{_bindir}/rebuild-gcj-db fi"
[13:21]  <hansg> abadger1999, the latter, I agree it could be worded better
[13:21]  <spot> s/add the rebuild-gcj-db line to it./add the above lines at the bottom./
[13:21]  <fitzsim> overholt: done
[13:22]  <overholt> fitzsim: can you deal with these other comments?
[13:22]  <fitzsim> abadger1999: I just removed the reference to Fedora 9
[13:23]  <overholt> do releases < 8 need to have a clause like "Since no other JDK exists in Fedora < 8, GCJ bits *MUST* be built"?
[13:23]  <tibbs> I think this is all reasonable.  We can clean up wording without having to go through the committee if we need to.
[13:23]  <tibbs> +1
[13:23]  <abadger1999> +1
[13:23]  <spot> ok, thats +5
[13:23]  <spot> it passes
[13:23]  <overholt> sweet, thanks everyone
[13:23]  <abadger1999> overholt: That's a good cleanup, I think.
[13:23]  <overholt> abadger1999: k
[13:24]  <spot> any other last minute items?
[13:24]  <abadger1999> And for #4 & #5 I think we usually just say "Add these to the package's %post/%postun"
[13:24]  <abadger1999> ignoring the fact that the package might not have those scriptlets to begin with.
[13:24]  <overholt> okay
[13:25]  <spot> that would work well. :)
[13:25]  <spot> ok, this meeting is done, thanks everyone.
[13:25]  <spot> tibbs: hope you get off that call sometime this year. :)
[13:26]  <hansg> I'm really happy to see the java stuff is all sorted out now, kudos to all involved!
[13:26]  <hansg> See you all next week
[13:26]  <spot> hansg: hasn't passed FESCo yet... ;)
[13:26]  * hansg covers his face in his hands
[13:26]  <overholt> I for one can't wait for the jpp fight
[13:26]  <overholt> :)
[13:26]  <spot> not going to be much of a fight
[13:27]  * spot puts "withdraw jpp exception" on the agenda
[13:27]  * abadger1999 Sends email to the list about javascript.
[13:27]  <overholt> spot: not going to be much of a fight how?
[13:27]  <overholt> spot: you assume FESCo will side with you?
[13:27]  * overholt is genuinely curious
[13:28]  * hansg goes on to try out and then answer some issues surrounding a kernel patch of his which is causing regressions on 2.6.25rc7 (grrr)
[13:28]  <spot> oh, maybe on the FESCo end
[13:28]  <overholt> huh?
[13:29]  <overholt> nevermind
[13:29]  <overholt> see ya
[13:29]  <-- overholt has left this channel ("Leaving").
[13:29]  <fitzsim> abadger1999: check the new %post/%postun rebuild-gcj-db wording please
[13:30]  <fitzsim> hansg, spot: you too
[13:30]  <abadger1999> fitzsim: Looks great!
[13:30]  * spot nods
[13:32]  <-- hansg has left this server ("Leaving").
[13:35]  * tibbs is off the phone!
[13:35]  <tibbs> And off to get food.
Retrieved from "https://fedoraproject.org/w/index.php?title=Packaging:Minutes20080401&oldid=6060"