From Fedora Project Wiki

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Fedora Packaging Committee Meeting of {2008-03-25}

Present

  • DominikMierzejewski (Rathann|work)
  • HansdeGoede (hansg)
  • JasonTibbitts (tibbs)
  • 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:

Proposals Considered

The following proposals were considered. Note: "Target release" indicates the oldest release at which the draft is targeted. Some drafts require functionality not present in older releases, which prevents their application to those releases.

  • New Perl Guidelines
  • http://fedoraproject.org/wiki/PackagingDrafts/Perl
  • This is a new draft this week, which replaces existing Perl guidelines
  • Target release: F8
  • Accepted (7 - 0)
  • Voting for: tibbs scop rdieter Rathann spot hansg abadger1999
  • Minor changes were made to the draft during the discussion.
  • OpenOffice.org extensions guidelines
  • http://fedoraproject.org/wiki/PackagingDrafts/OpenOffice.orgExtensions
  • This was previously submitted for a vote but was not complete; it has been resubmitted.
  • Target release: F8, possibly F7.
  • Accepted (7 - 0)
  • Voting for: hansg abadger1999 Rathann scop spot tibbs rdieter
  • Minor changes were requested and made by the submitter.

Other Discussions

Due to the number of pending drafts (and a set of Java guidelines coming soon) the committee will meet next week, April 1, 17:00UTC. (Yes, April fools day.)

IRC Logs

[12:00]  * spot looks around
[12:00]  * tibbs here
[12:01]  * scop_ here
[12:01]  <rdieter> here
[12:03]  * spot doesn't see hans or racor
[12:03]  <spot> abadger1999: ping
[12:04]  <abadger1999> here
[12:04]  * f13 is so not here.
[12:04]  <rdieter> +1 to whatever spot says, can I go now? :)
[12:04]  * spot curses at the wiki
[12:04]  <abadger1999> We've had troubles with it all morning.
[12:04]  * Rathann gets back from dinner
[12:05]  <tibbs> I have all of the pages loaded; I may be able to save them off.
[12:05]  <rdieter> it's almost like it's a release day or something.
[12:05]  <Rathann> present! :)
[12:05]  <spot> ok, so we're at 6 out of 8...
[12:05]  --> hansg has joined this channel (n=hans@ip32-174-211-87.adsl2.versatel.nl).
[12:06]  <hansg> hi all
[12:06]  * hansg is present
[12:06]  <spot> ok, thats everyone except ralf (and he said he wasn't coming)
[12:06]  <spot> lets see how much we can get done
[12:06]  <hansg> sorry for being late (my wife was back from work a bit late
[12:06]  <scop_> np
[12:06]  <spot> first item: http://fedoraproject.org/wiki/PackagingDrafts/ASCIINaming
[12:07]  <spot> this contains the amendment about looking at other distros when transliterating
[12:07]  * hansg is checking the amendment
[12:07]  <scop_> +1
[12:07]  <tibbs> +1
[12:08]  <hansg> +1
[12:08]  <Rathann> +1
[12:08]  <spot> +1
[12:08]  <rdieter> +1
[12:08]  <abadger1999> Nothing violates these rules currently, right?
[12:08]  <tibbs> I didn't see anything.
[12:08]  <f13> abadger1999: the package up for review does
[12:08]  <abadger1999> +1
[12:08]  <spot> ok, it passes
[12:08]  <abadger1999> f13: yeah, but I think nim-nim will accept this.
[12:08]  <f13> écoler fonts or whatever.
[12:08]  <spot> item number 2: http://fedoraproject.org/wiki/PackagingDrafts/Perl
[12:09]  <abadger1999> Next week, ASCIINamingLowercase!
[12:09]  <spot> mostly, this is putting in writing what the perl community has been doing for years.
[12:09]  <Rathann> :)
[12:09]  <spot> it would replace Packaging/Perl
[12:09]  <spot> (all of the items currently in Packaging/Perl are in this draft)
[12:09]  <hansg> +1
[12:09]  <rdieter> +1
[12:09]  <scop_> looks like the issues I pointed out on list haven't been addressed yet
[12:10]  <abadger1999> spot: Looked good to me +1
[12:10]  <spot> scop_: which issues?
[12:10]  <Rathann> +1 (except for scop's comments need to be addressed)
[12:10]  * scop_ looks up the message, hold on
[12:10]  <Rathann> 2) Versioned MODULE_COMPAT_ Requires:
[12:10]  <Rathann> "This is to ensure that all perl modules are built against the appropriate
[12:10]  <Rathann> version of perl."
[12:10]  <tibbs> Didn't Ralf have some comments as well?
[12:10]  <Rathann> This rationale is wrong - it doesn't ensure that, but that packages have a
[12:10]  <Rathann> dependency to a perl that uses stuff from dirs versioned with that version
[12:10]  <Rathann> number.
[12:10]  <spot> ah, ok, the rationale cleanup
[12:10]  <spot> i can do that, no problem.
[12:11]  <scop_> https://www.redhat.com/archives/fedora-packaging/2008-March/msg00160.html
[12:11]  <scop_> two other minor things
[12:11]  <spot> i added a section on subdir ownership for ralf
[12:12]  <tibbs> s/ExtUtils::Build/Module::Build/
[12:12]  <hansg> This reminds me that at fosdem one of the centos guys asked me about a bug in how the perl autoprovides / depends handles versioning, I then asked a Dutch guy I know who is a core perl developer what the correct way is to determine the version for Provides and he said that the correct way is to eval (in perl) the line which sets the version instead of using regex on that line (cpan uses the eval method)
[12:12]  <scop_> eval is dangerous
[12:12]  <hansg> Someone really needs to file a bug against rpm about this (sorry for the offtopic it just popped into my mind)
[12:13]  <spot> ah, i see your email scop. i will make those two corrections (move cpanspec down, fix Module::Build)
[12:13]  <hansg> cpan has a sandbox eval
[12:13]  <scop_> oh, that sounds better
[12:13]  <hansg> some -DSAFER option, but then the perl version
[12:13]  * hansg doesn't know much perl
[12:13]  <scop_> +1
[12:14]  <tibbs> +1 the old perl guidelines are rather ungood compared to these.
[12:14]  <Rathann> "ungood"? are you switching to newspeak? ;)
[12:15]  <tibbs> I wonder if some will object to the "For a variety of reasons" bit near the end.
[12:15]  <f13> double plus ungood
[12:17]  <tibbs> Did I lag out?
[12:17]  <spot> "This is to ensure that perl packages have a dependency on a perl which provides the appropriate versioned directory structure (otherwise, the modules won't be found)."
[12:17]  <spot> scop_: is that wording ok?
[12:17]  <scop_> spot, works for me
[12:17]  <spot> ok, then +1 from me on my own draft. :)
[12:17]  <scop_> but actually, I just noticed the "include test suite sources in doc" part
[12:18]  <scop_> I can't +1 that
[12:18]  <tibbs> Crap, I scanned for that but must have missed it.
[12:18]  <spot> thats a very loose suggestion
[12:18]  <spot> not a must
[12:18]  <tibbs> Sorry, I have to -1 with the "Tests can make for good documentation" bit.
[12:18]  <spot> "Sometimes a test suite shows off a modules uses well. If this is the case, consider including part or all of it in %doc. "
[12:18]  <scop_> ditto, -1 with it
[12:19]  <spot> ok, why such a switch over something which is not forbidden anywhere else?
[12:19]  <Rathann> scop_, tibbs: that's "consider", not even "should"
[12:19]  <scop_> I read it as a recommendation or encouragement
[12:19]  <scop_> I strongly thing that generally it should be _discouraged_
[12:19]  <tibbs> I mean, sometimes the source code of any program can make for documentation.  But we don't encourage its inclusion as %doc; that's what the srpm is for.
[12:20]  * spot isn't attached to that section, i can just drop it, and let people argue with you when they do it on review
[12:20]  <Rathann> many packages include examples in %doc
[12:20]  <scop_> examples are designed to be examples
[12:20]  <spot> since it isn't forbidden anywhere else
[12:20]  * Rathann shrugs
[12:21]  <scop_> test suite code is often quick/dirty and uses APIs in "wrong" ways or touches code internals to be able to unit test bits
[12:21]  <spot> ok, i'll drop that section
[12:21]  <tibbs> The problem I have with it is that many times Chris has been including the test suite even when it is not useful as documentation.
[12:22]  <tibbs> My thinking is that he's just trying to legitimize this practise in the guidelines.
[12:22]  <spot> ok. (as soon as the wiki loads, i will drop that section)
[12:22]  * scop_ agrees and dislikes that too
[12:23]  <Rathann> tibbs: that's a valid point
[12:23]  <spot> ok, its gone.
[12:23]  <tibbs> +1
[12:23]  <spot> can i get a revote on it? :)
[12:23]  <scop_> ok, still +1 with that section dropped
[12:23]  <rdieter> +1
[12:23]  <Rathann> +1
[12:23]  <spot> +1
[12:24]  <spot> hansg, abadger1999?
[12:24]  <hansg> I already +1-ed, but ...
[12:24]  <hansg> +1
[12:24]  <spot> ok, i'll assume abadger1999's earlier +1 still stands
[12:24]  <spot> it passes
[12:24]  <abadger1999> yeah.  My +1 still valid
[12:25]  <hansg> Ah I missed the revote question, sorry
[12:25]  <spot> next item: http://fedoraproject.org/wiki/PackagingDrafts/EclipsePlugins
[12:25]  <hansg> Have their been any changes to that the last 4 hours?
[12:26]  <spot> no
[12:26]  <hansg> +1
[12:26]  <Rathann> -1, the build commands are too complicated and need to be turned into either macros or external scripts. I'm against putting those in specfiles
[12:26]  <tibbs> The Group tag bit is kind of odd, since our other guidelines say we don't care.
[12:26]  <spot> Rathann: yes, but they're valid.
[12:27]  <Rathann> yes they are, but I'm against making a mess of specfiles if it can be avoided
[12:27]  <tibbs> How difficult would it be in practise to provide those macros?
[12:27]  <hansg> Rathann, I agree, but the same could be said for many of the things on: http://fedoraproject.org/wiki/Packaging/ScriptletSnippets, I really think we need to discuss this seperately
[12:28]  <abadger1999> I also wondered whether we want the debug_package %{nil} workaround taken out.
[12:28]  <tibbs> Well, to be fair we do have a chance to get this right initially.
[12:28]  <hansg> this = "putting "complicated" repeating spec file parts in macros"
[12:29]  <tibbs> Yeah.  If adding macros is easy, then we can get the specfiles simple from the outset.
[12:29]  * Rathann wonders how many of these parameters are the same for most eclipse plugins
[12:29]  <spot> i'm pretty sure andrew would be willing to macroize/script these build commands
[12:29]  <tibbs> I note that we shouldn't have time-dependent information like "t is still in its infancy" in guidelines, since someone on the committee will have to change them later.
[12:30]  <spot> tibbs: yeah, i clean that out before i push them live
[12:31]  <tibbs> Also, note that we can't really approve this without the "Packaging/Java" bit that it refers to.
[12:31]  <tibbs> And I note that the Java guidelines aren't on the schedule.
[12:31]  <Rathann> instead of macros, it could be a shell script which would be added to one of the packages that are in BR:
[12:31]  --> overholt has joined this channel (n=overholt@32.60.107.139).
[12:31]  <tibbs> Ahh.
[12:31]  <overholt> hey hey
[12:31]  <scop_> overholt, right on time
[12:31]  <tibbs> overholt: We were just discussing the complexity of the eclipse stuff.
[12:32]  <spot> overholt: the major remaining concern about the EclipsePlugins draft is around the complicated build calls
[12:32]  <overholt> okay
[12:32]  <spot> we'd all prefer those to be in macros or scripts to keep the specs simple
[12:32]  <overholt> everyone would
[12:32]  <tibbs> But we don't really know if that's possible.
[12:32]  <overholt> it's probably possible
[12:33]  <overholt> is it really that big of a deal?  I'm hoping to fix this upstream in a better way.
[12:33]  <tibbs> Rathann was objecting.
[12:33]  <Rathann> overholt: I'd like to avoid them directly in specfiles if possible
[12:33]  <overholt> Rathann: avoid what?
[12:34]  <tibbs> How much of the java -cp... calls will be identical for all of these packages?
[12:34]  <Rathann> java .... calls
[12:34]  <tibbs> And, will we ever want to add or change the arguments for all packages?
[12:34]  <Rathann> if upstream doesn't have a clean solution, I'd like to see a macro or an external script that wraps them up in the meantime
[12:35]  *** hansg is now known as hansg_afk.
[12:35]  <Rathann> similar to make or ant
[12:35]  <overholt> I don't really think it's good to paper over the crappiness of upstream's build procedure with a script
[12:35]  <overholt> I'm actively trying to get it fixed there
[12:35]  <overholt> so it can be a simple one liner
[12:36]  <tibbs> That's a reasonable argument, I suppose.  But then once upstream gets fixed, you could just change the script without having to change the packages.
[12:37]  <Rathann> well, it'll be easier to change one line than 20+ in all eclipse plugin specfiles later
[12:37]  <overholt> I'll work on a script
[12:37]  <scop_> I'm wondering whether some words about symlinking to system jars but including source code jars should be added, or if plugins should actually include source code jars in the first place
[12:38]  <Rathann> hm I thought something to that effect was already in there
[12:38]  <scop_> I mean if you symlink to /usr/share/java/foo.jar but include the sources of the private bundled copy of foo are shipped with the plugin, there's a mismatch
[12:38]  <scop_> oh, if it was, I missed something
[12:39]  *** hansg_afk is now known as hansg.
[12:40]  <Rathann> scop_: does the mismatch have any side-effects?
[12:40]  <scop_> I think source jars are practically only useful for debugging
[12:41]  <scop_> the code running might not be the code eclipse shows in the debugger
[12:41]  <overholt> true
[12:41]  <spot> should we revisit this one in a week, when overholt's got his script ready?
[12:41]  <scop_> line number offsets, different versions, patches applied in one but not the other, etc
[12:41]  <overholt> it's not likely I'm going to have a script ready in a week.  is it really a blocker?
[12:41]  * spot hates to be rushing good discussion, but we have a LOT more to go
[12:41]  <tibbs> I don't personally think it's a blocker.
[12:42]  <tibbs> Who does?
[12:42]  <spot> neither do, as long as it comes soonish.
[12:42]  <hansg> I'm still +1
[12:42]  <rdieter> +1 eclipse draft either way (it's better than the status-quo)
[12:42]  <scop_> not really, but don't the java guidelines need to be ready before this can be accepted anyway?
[12:42]  <overholt> I had hoped that wasn't true
[12:42]  <overholt> they're quite different beasts
[12:42]  <tibbs> Well, it does refer to them directly.
[12:42]  <Rathann> well, eclipse plugins are java, aren't they?
[12:43]  <tibbs> And there's the gcj question as well.
[12:43]  <spot> i don't think these two drafts are linked anymore
[12:43]  <tibbs> Rathann: I see them as a specific subset of java stuff.
[12:43]  <hansg> tibbs, whats is the gck question
[12:43]  <tibbs> Just search for gcj in the draft.
[12:43]  <tibbs> While many Eclipse plugins will be architecture-independent, please follow the [Packaging/Java Java packaging guidelines]  with regards to gcj ahead-of-time compilation. As those guidelines specify, gcj-compiled packages are arch-dependent and are thus not noarch.
[12:44]  <hansg> I've read it including the gcj part, but I didn't see a question there
[12:44]  <spot> tibbs: ah, ok.
[12:44]  <tibbs> And yet Java guidelines both don't yet exist and have an open question as to what to do about gcj.
[12:44]  <hansg> Thats a reference to the java guidelines, yes, but still no question
[12:44]  <hansg> That question has been answered, I and or overholt need to write it down though.
[12:45]  <tibbs> Then I guess you can understand my confusion.
[12:45]  <hansg> I do
[12:45]  <spot> we really should have Java guidelines in place before we can approve this in good faith.
[12:45]  <overholt> the gcj question isn't open and has been answered separately
[12:45]  <tibbs> The draft Java guidelines refer to a third document for gcj.
[12:45]  <overholt> yes
[12:45]  <overholt> it shouldn't be part of the java guidelines
[12:45]  <overholt> but still needs to be fleshed out
[12:46]  <hansg> The text we're planning to put in the java guidelines is ""please add gcj bits but we're not going to stop a package's inclusion without them."
[12:46]  <overholt> in the gcj guidelines,  you  mean
[12:46]  <tibbs> Then the Eclipse guidelines should refer to the GCJ guidelines, not the java guidelines.
[12:46]  <overholt> yup
[12:46]  <spot> http://fedoraproject.org/wiki/PackagingDrafts/GCJGuidelines says they must be built
[12:46]  * scop_ afk for 3 minutes
[12:46]  <overholt> it needs to be fixed
[12:46]  <spot> overholt: can you fix it now?
[12:46]  <hansg> We have seperate gcj guidelines too, is that really needed?
[12:46]  <spot> we'll tackle some other topics and come back to this
[12:46]  <overholt> k, what everyone's saying is they don't want guidelines for anything written in java until the java guidelines are finished
[12:47]  <overholt> the java guidelines are nearing completion
[12:47]  <overholt> we can revisit the eclipse guidelines when they're done
[12:47]  <overholt> okay?
[12:47]  <hansg> This is starting to feel like an ITU-T telecom specification, where each standard links to another doc which links to another doc, which ...
[12:47]  <spot> overholt: no, what we're saying is that you can't have a guideline which says "look at the java guidelines" when they're not there.
[12:47]  <overholt> spot: I know what you're saying
[12:47]  <tibbs> I don't personally think the Eclipse guidelins need to wait for java.
[12:47]  <spot> i think we can vote on this and revise later as needed
[12:48]  <abadger1999> Should JAR Expansion (rare)::workaround #2 (disable debuginfo) be taken out?  Should workaround #1 be explained in the guidelines instead of "see eclipse-mylyn" for examples?
[12:48]  <spot> abadger1999: thats a good point, i would prefer that
[12:48]  <spot> we shouldn't be disabling debuginfo anywhere when there is another option
[12:49]  <hansg> Does debuginfo generation do anything for java packages? AFAIK it doesn't and then to me workaround 2 would be prefered, and maybe even made the default for any eclipse plugins
[12:49]  <overholt> ugh, i thought I removed that workaround
[12:49]  <overholt> to be honest, I'm not sure why these are back up for discussion
[12:49]  <overholt> I guess 'cause I didn't explicitly remove them from the agenda
[12:50]  <spot> overholt: do you want these tabled for now?
[12:50]  * scop_ is back
[12:50]  <overholt> spot: yes, please table them
[12:50]  <spot> ok, this issue is tabled
[12:50]  <spot> next issue: http://fedoraproject.org/wiki/PackagingDrafts/OpenOffice.orgExtensions
[12:50]  <-- overholt has left this channel ("Leaving").
[12:50]  --> Kevin_Kofler has joined this channel (n=Kevin_Ko@chello213047068123.17.14.vie.surfer.at).
[12:51]  <abadger1999> I had a bunch of nits on this that I sent to the list a couple hours ago.
[12:51]  <abadger1999> The only one of substance was whether plugins should install directly to %{_datadir}/pluginname or if there should be %{_datadir}/openoffice.org/plugins
[12:52]  * Rathann would prefer the latter
[12:52]  <Rathann> also, I would like to see some rationale for guideline 3. Unpacked Extensions Must be installed in a dir called NAME.oxt, NAME.uno.pkg or NAME.zip
[12:53]  <Rathann> as in "why those names and only those"
[12:53]  <tibbs> abadger1999: Which list did you send that to?
[12:53]  <hansg> abadger1999: "The only one of substance was whether plugins should install directly to %{_datadir}/pluginname or if there should be %{_datadir}/openoffice.org/plugins" +1
[12:53]  * spot grabs caolan
[12:53]  <abadger1999> fedora-packaging
[12:54]  <Kevin_Kofler> What exactly is covered by the OO.o plugins proposal? Is NWF integration such as openoffice.org-kde a "OO.o plugin"?
[12:54]  --> caolan has joined this channel (n=caolan@089-101-005252.ntlworld.ie).
[12:54]  <hansg> what is nwf?
[12:54]  <Rathann> Kevin_Kofler: it covers extensions
[12:54]  <spot> caolan: hi, we had a few questions (as usual)
[12:54]  <Kevin_Kofler> Native Widget Framework
[12:54]  <spot> "Unpacked Extensions Must be installed in a dir called NAME.oxt, NAME.uno.pkg or NAME.zip"
[12:54]  <caolan> yup
[12:54]  <spot> why the three choices there? could it just be one?
[12:55]  <caolan> there's a link off the spec IIRC that says why, let me check a sec
[12:55]  <Rathann> oh right
[12:55]  <Rathann> it links somewhere
[12:56]  <Rathann> forget my question then
[12:56]  <tibbs> Wow, they have three different behaviors depending on what the directory is named?
[12:56]  <spot> abadger1999: does that answer your first question as well?
[12:56]  <caolan> there's a subtle difference between them a "modern" extension describes itself properly, while "old" ones don't and old ones have to be in a named dir for OOo to know they're old one is the summary
[12:57]  <tibbs> oxt is the new format?
[12:57]  * caolan checks carefully
[12:57]  <hansg> except for making plugins install in %{_datadir}/openoffice.org/plugins/pluginname instead of %{_datadir}/pluginname (and the same for libdir) this gets a +1 from me
[12:58]  <caolan> yes, .oxt is the newest variant
[12:58]  <abadger1999> caolan: ^^
[12:58]  <abadger1999> Is that an okay change?
[12:58]  <tibbs> I guess my question is whether the name of the directory is something the packager can choose or if it depends on the package itself, and if the latter how can you tell?
[12:59]  <Kevin_Kofler> So is openoffice.org-kde an extension or not? (If not, I'd like it black on white so I don't have to fight with the CVS admins over it. ;-) )
[13:00]  <caolan> tibbs: given the correct suffix, then the prefix can be anything the packager wants for the dirname. It does affect how the extensions are named for the --remove thingy, but they can be named whatever-SUFFIX
[13:00]  <caolan> Kevin_Kofler: no, the -kde thing is not an extension
[13:00]  <scop_> hm, are these things primarily called "extensions" or "plugins"?
[13:01]  <caolan> Kevin_Kofler: the -kde thing is just a build-modularization issue for OOo "proper"
[13:01]  <scop_> if extensions, then %{_datadir}/openoffice.org/extensions rather than %{_datadir}/openoffice.org/plugins
[13:01]  <caolan> scop_: "extensions" is the canonical name
[13:01]  <scop_> ok
[13:01]  <caolan> e.g. http://extensions.openoffice.org/
[13:02]  <caolan> abadger1999: ah, perhaps, but I worry then about conflicting java specifications for e.g. a java extension, does it go in /usr/share/java/foobar.uno.pkg or /usr/share/openoffice.org/foobar.uno.pkg
[13:03]  <spot> caolan: this is a special case, you would trump general java specifications
[13:03]  <hansg> Well its an openoffice extension written in java right
[13:03]  <hansg> ?
[13:03]  <scop_> is it expected that an oo.o extension is used anywhere else than from within/with oo.o?
[13:03]  <caolan> it's no skin off my nose, so I just said "see lang-specific guidelines"
[13:03]  <caolan> right now the idea is silly to be used outside of OOo alright, but it is technically possible
[13:04]  <caolan> so, sure. lets say /usr/lib/openoffice.org/extensions for arch-dependant ones
[13:04]  <scop_> s|/usr/lib|%{_libdir}|, no?
[13:04]  <abadger1999> s!/usr/lib!%{_libdir}!
[13:04]  <caolan> and for arch-independent /usr/share/openoffice.org/extensions ?
[13:04]  <caolan> yeah, yeah
[13:04]  <abadger1999> Sounds good.
[13:04]  <spot> that seems good to me
[13:04]  <hansg> yip, +1
[13:05]  <spot> the only other notes were minor cleanups
[13:05]  <abadger1999> +1
[13:05]  <Rathann> +1 from me then
[13:05]  <scop_> +1
[13:05]  <spot> +1
[13:05]  <tibbs> +1
[13:05]  <tibbs> Do we need a note as to which openoffice versions support this?
[13:06]  <Rathann> ideally, I'd like a summary of that e-mail that was linked in the draft
[13:06]  <rdieter> +1
[13:06]  <hansg> Maybe a versioned requires in the example specfile with comment explaining why
[13:06]  <spot> caolan: its only F-9+ at the moment, right?
[13:06]  <tibbs> I thought the proper openoffice version was pushed to F7+.
[13:06]  <rdieter> tibbs: either is, or will be.
[13:06]  <caolan> spot: tibbs: right, there are some bugs in < F9 that makes it a problem, but there are backports in -testing at the moment
[13:06]  <spot> caolan: can you add a versioned Requires in there? :)
[13:06]  <Rathann> good
[13:07]  * scop_ needs to leave in 10 minutes
[13:08]  <spot> ok, the one item i think we can do which will not be contentious:
[13:08]  <spot> Move licensing guidelines out of FPC space
[13:08]  <tibbs> They are already, aren't they?
[13:08]  <spot> LicensingGuidelines is in Packaging/ now
[13:08]  <tibbs> The only thing in FPC space is the specifics of what goes in the license tag, which seems to be properly there.
[13:09]  <spot> most of that needs to move out
[13:09]  <tibbs> Well, crap, I can't get to the wiki now.
[13:09]  <Rathann> moved out where?
[13:09]  <spot> to Licensing/
[13:10]  <Rathann> right
[13:10]  <tibbs> So which parts of LicensingGuuidelines should move?
[13:10]  <tibbs> "Distributable", I guess.
[13:11]  <tibbs> But most of that seems to be related to mechanics of the license tag, which seems properly in FPC space.
[13:11]  <tibbs> Although honestly I don't really care where it lives as long as it's there somewhere.
[13:11]  <scop_> tibbs++
[13:11]  <spot> so, the motivation here is twofold
[13:11]  <spot> 1. The Red Hat lawyers want this moved, because they have authority on this, not the FPC
[13:12]  <spot> 2. The FSF wants it moved, for consolidation of licensing in one location
[13:12]  <Rathann> hmm
[13:12]  <Rathann> but most of this is about the implementation in specfiles and packages
[13:12]  <spot> essentially, what i would do is move these guidelines, then add an entry to the Packaging Guidelines that says "follow the licensing guidelines over here"
[13:13]  <tibbs> I don't really get why the FSF is meddling here, but I still don't really care.
[13:13]  <scop_> +1 (FWIW), next :)
[13:13]  <Rathann> I agree that "what licences are allowed" is not ours to decide
[13:13]  <Rathann> but the rest
[13:13]  <rdieter> shrug, ok, +1 move.  don't let the door hit ya on the way out.
[13:14]  <spot> +1 to the move (obviously)
[13:14]  <Rathann> 0, I don't want to decide without knowing WHAT exactly gets out and what stays
[13:15]  <spot> Rathann: http://fedoraproject.org/wiki/Packaging/LicensingGuidelines would move to Licensing/Guidelines
[13:15]  <Rathann> all of it?
[13:15]  <spot> yes.
[13:15]  <tibbs> The lawyers really have authority over whether we have "Python and (BSD and QPL)" versus "Python && (BSD && QPL)"?
[13:15]  <Rathann> -1 then
[13:15]  <spot> and i'd add a section to Packaging/Guidelines called "Licensing"
[13:15]  <abadger1999> -1
[13:15]  <-- Kevin_Kofler has left this channel ("Bye!").
[13:15]  <tibbs> And you thought this wasn't contentious.
[13:16]  <Rathann> and what would be in that section?
[13:16]  <spot> tibbs: they seemed to think that they did.
[13:16]  <spot> let me revisit this.
[13:16]  <hansg> Hmm, I don't get it, I can understand the FSF wanting to link to http://fedoraproject.org/wiki/Licensing, considering all the work they have done on that, and I can understand both the FSF and the lawyers not wanting most people to have edit rights on http://fedoraproject.org/wiki/Licensing, I can even understand the lawyers wanting to restrict editing rights to: http://fedoraproject.org/wiki/Packaging/LicensingGuidelines, and in tha
[13:16]  <hansg> t light even to http://fedoraproject.org/wiki/Packaging/Guidelines#head-76294f12c6b481792eb001ba9763d95e2792e825
[13:16]  <spot> i might be able to make everyone happy without making any changes here at all
[13:16]  * scop_ wonders if it matters at all what we vote here about legal issues when legal has made their point clear
[13:17]  <spot> ok, next item: http://fedoraproject.org/wiki/PackagingDrafts/SecureBuildRoot
[13:17]  <hansg> either way I must say I don't care much, it would be good to have it all under http://fedoraproject.org/wiki/Licensing, which should then have subpages, note that http://fedoraproject.org/wiki/Packaging/Guidelines#head-76294f12c6b481792eb001ba9763d95e2792e825, should also move tghere
[13:18]  <hansg> securebuildroot -1
[13:18]  <scop_> -1, for reasons discussed on list (needs to move to rpm, both suggested implementations have issues)
[13:18]  <abadger1999> I'm all for moving "Distributable" through "GPL" out.  But the other stuff seems to be about how to represent that in the license tag.
[13:18]  <Rathann> I'm all for separating legal issues from technical issues, but not by moving all technical guidelines over to the legal side
[13:18]  <tibbs> -1, for the reasons I posted on-list.
[13:18]  <Rathann> -1 for securebuildroot, reasons posted
[13:18]  <abadger1999> BuildRoot:  If we can get it into rpmbuild I'd like that a whole lot better.
[13:18]  <spot> ok, this one fails.
[13:19]  <spot> i'll talk to panu and see if he's willing to fix this in rpm
[13:19]  <spot> next item: http://fedoraproject.org/wiki/PackagingDrafts/ProvidesList
[13:19]  <tibbs> I have no problem revisiting this if it's impossible to fix buildroot in rpm.
[13:19]  <abadger1999> tibbs: +1
[13:20]  <tibbs> I'm not really sure about ProvidesList.
[13:20]  * hansg neither
[13:20]  <scop_> I like the general idea
[13:20]  <tibbs> I mean, as written you have to document perl(Blah).
[13:20]  <tibbs> And that's just crazy talk.
[13:21]  <scop_> you're right, but I don't think that was the intention
[13:21]  <spot> i think his intention is explicit virtual provides
[13:21]  <scop_> autogenerated provides do not need to be documented
[13:21]  <spot> not implicit
[13:21]  <nim-nim> abadger1999: nim-nim would accept it better if FPC treated (ab)users of camelcase names the same way it treates users of UTF-8
[13:21]  <nim-nim> so +1 for ASCIINamingLowercase
[13:21]  <tibbs> Some of the perl ones are explicit, though.
[13:22]  <spot> also, it seems like the sort of thing that we should be able to autogenerate
[13:22]  <tibbs> Good point.
[13:22]  <rdieter> +1 ProvidesList (should be documented somewhere, this is as good as any)
[13:22]  <spot> without having to keep a list by hand
[13:23]  <hansg> I'm tending to -1, I like the idea, but I think it needs more work / discussion
[13:23]  <Rathann> I think it's a good proposal, even if a bit incomplete
[13:23]  <tibbs> And if we can't autogenerate it, then we probably can't provide good rules about when someone needs to add a provide to the list.
[13:23]  <spot> -1, because i think this info should live in the packagedb
[13:23]  <Rathann> hmm
[13:23]  <spot> the idea is good, but i don't think a manual list is what we want here
[13:23]  <Rathann> yes
[13:24]  <Rathann> but it needs to be easily accessible
[13:24]  <Rathann> so that packagers know which virtual provides to use
[13:24]  <scop_> I really need to go now, so for the remaining bits if you'll still discuss them: SysVInitScript: 0 (need to read it more, and I don't think s/try-restart/condrestart/ was a good idea), and NoBitsInSrv: -1 as it currently stands (needs to state what the policy is towards existing packages using /srv)
[13:24]  <rdieter> and a pony
[13:24]  <spot> scop_: thanks
[13:24]  <Rathann> and that they are there
[13:24]  <scop_> thanks, see ya
[13:25]  <-- scop_ has left this channel ("Leaving").
[13:25]  * rdieter fetches more coffee
[13:25]  * abadger1999 writes up ASCIINamingLowercase for the next meeting
[13:25]  <spot> so, i see two -1, and a +1
[13:25]  <Rathann> 0 from me
[13:25]  <abadger1999> 0
[13:25]  <tibbs> -1 as written.
[13:26]  <spot> ok, this one fails
[13:26]  <spot> i am tabling the remaining drafts until next week
[13:26]  <spot> i want to work on SysVInitScript and NoBitsInSrv a bit more
[13:26]  <abadger1999> I tend to agree with spot about it being in pkgdb but it's not something I have on my radar.
[13:27]  <abadger1999> It would need a bit of work to implement as that's currently information in the yum metadata and it's not duplicated in the pkgdb.
[13:27]  <spot> abadger1999: can you put it on your todo list? :)
[13:27]  <abadger1999> spot: On my mile long one or the uber-secret short list? :-)
[13:27]  <rdieter> short list obviously. :)
[13:28]  <spot> ;)
[13:28]  <spot> ok, the only remaining item is that we need to meet next week
[13:28]  <Rathann> abadger1999: but there needs to be some information along the lines of "here's what they mean and here's the list"
[13:28]  <spot> the Java guidelines should be ready by then
[13:29]  * spot opens the floor to any additional topics
[13:29]  <abadger1999> Rathann: Another good point.  So we can pull the provides out of metadata but the descriptions will have to be stored separately...
[13:29]  <spot> if you've got nothing, please say so.
[13:29]  <hansg> java guidelines ready? I guess andrew made that promise, as I don;t have the time for that atm (writing usb webcam drivers takes a lot of time)
[13:29]  <abadger1999> I've been thinking that we might want to have python virtual provides like perl virtual provides.
[13:29]  <spot> hansg: they are not ready.
[13:29]  <abadger1999> Where should that be discussed initially?
[13:29]  <spot> hansg: they asked for another week
[13:30]  <Rathann> abadger1999: and ruby? ;)
[13:30]  <Rathann> and (insert your favourite language here)? ;))
[13:30]  <abadger1999> Rathann: heh, sure but we'll have to get lutter to deal with it :-)
[13:30]  * spot looks around
[13:31]  * spot coughs
[13:31]  <Rathann> maybe a general guideline for "language extensions" which would cover perl, python and whatnot would be better?
[13:31]  <spot> ok. meeting is done. thanks for your extreme patience.
[13:31]  <Rathann> well, it was productive so it's time well spent
[13:31]  <hansg> wait
[13:31]  <abadger1999> The reason I ask is that it would need an rpm script to automatically make the provides.
[13:32]  <hansg> There is one small issue I would like to discuss while talking with Andrew about the java guidelines
[13:32]  <spot> hansg: okay.
[13:33]  <hansg> I believe that the "Introduction" which explains about source versus byte versus jar doesn't belong there
[13:33]  <hansg> its good to have something like that somewhere, but not in the guidelines themselves
[13:33]  <hansg> we don't explain what a .so file is in other guidelines who reference .so files, we should expect some level of knowledge about the stuff being packaged / reviewed
[13:34]  <spot> information which is good for reviewers who are not familiar with the language is usually ok in guidelines
[13:34]  <hansg> This would also allow us to remove ^H^H^H^H^H
[13:34]  <hansg> oh wait, I see the handholding part there was is already gone now, and gone from the todo list too, looks like reality has caught up with me and overtaken me
[13:35]  <hansg> never mind
[13:35]  <spot> okay. :)
[13:35]  <spot> anything else?
[13:35]  <hansg> not from me
[13:37]  <spot> ok, we're done. thanks all.
[13:37]  <Rathann> cool
[13:37]  <tibbs> And I have a long summary to write.
Retrieved from "https://fedoraproject.org/w/index.php?title=Packaging:Minutes20080325&oldid=66589"