Packaging:Minutes20070731

Fedora Packaging Committee Meeting of {2007-07-31}

Present

• DavidLutterkort (lutter)
• JasonTibbitts (tibbs)
• JesseKeating (f13)
• RexDieter (rdieter)
• TomCallaway (spot)
• ToshioKuratomi (abadger1999)
• VilleSkyttä (scop)

Votes

The following proposals were considered:

• The license tag refinements requested by the board:
• http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag
• Accepted (7 - 1)
• Voting for: rdieter f13 tibbs lutter abadger1999 spot scop
• Voting against: racor (on-list)

• Dynamic user and group creation policy:
• http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups
• Accepted (6 - 0)
• Voting for: spot lutter scop abadger1999 tibbs rdieter
• Abstaining: f13

Other Discussions

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

• OnlyShowIn in desktop files

IRC Logs

[12:04]  * spot waves his broom around
[12:04]  <spot> shoo! shoo!
[12:05]  <XulChris> all i wanted to ask about was all the onlyshowin stuff
[12:05]  <XulChris> i guess i can bring it up next week
[12:05]  <rdieter> kinda packaging related...:)  question?
[12:06]  <Kevin_Kofler> I think many of the OnlyShowIn crap should go away.
[12:06]  <rdieter> Kevin_Kofler: +1
[12:06]  <Kevin_Kofler> But that needs to be coordinated with the (GNOME) Desktop Team.
[12:06]  <XulChris> ya i need to make a list of packages which i think are questionalbe, ill have more next week
[12:06]  <Kevin_Kofler> Because ironically what we do will affect them and the opposite.
[12:06]  <Kevin_Kofler> So we need to work together.
[12:07]  <rdieter> Or FPC make a standard policy around that. :)
[12:07]  <XulChris> i think a gmenu-kde package (opposite of kmenu-gnome) would work
[12:07]  <rdieter> spot: can we discuss that (OnlyShowIn in .desktop files) today, if we have time?
[12:07]  <Kevin_Kofler> We've seen how well that works... :-( (*cough* GenericName *cough* Name *cough* *cough*)
[12:08]  <spot> sure.
[12:08]  <tibbs> Is there any hope that we'll be able to vote on anything today?
[12:08]  <spot> well, who
[12:08]  <rdieter> dunno if we have a quorum.
[12:08]  <spot> who is here?
[12:08]  <abadger1999> I'm here
[12:08]  <rdieter> here
[12:09]  <f13> here
[12:09]  <spot> thats 5 (with tibbs)
[12:09]  * lutter is here
[12:09]  <spot> 6.
[12:09]  *** Kevin_Kofler sets the channel topic to "Fedora Packaging Committee Meeting".
[12:09]  <spot> so, we do have quorum
[12:09]  <CyberSpy> I'm here, but not on KDE team yet
[12:10]  <Kevin_Kofler> CyberSpy: KDE meeting is over.
[12:10]  <CyberSpy> Ah, ok, nevermind then, sorry.
[12:10]  <spot> ok.
[12:10]  <spot> lets get the white elephant out of the way
[12:10]  <Kevin_Kofler> This is FPC now.
[12:10]  <spot> http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag
[12:11]  <tibbs> After the latest round of changes I'm pretty much OK with this.
[12:12]  <spot> Hopefully, everyone has read the most recent revision.
[12:12]  <tibbs> Although I think that at some point we really should abandon any hope of automatic parsing and just say "License: Complicated, see /path/to/file".
[12:12]  <rdieter> License: foobar'd
[12:12]  <tibbs> The "Combined Dual and Multiple Licensing Scenario" is really beyond the bounds of what we can hope to make useful.
[12:12]  --> scop has joined this channel (n=scop@cs181043142.pp.htv.fi).
[12:12]  <rdieter> oops, spellcheck: fubar
[12:13]  <scop> hello, sorry I'm late
[12:13]  <spot> scop: welcome
[12:13]  <lutter> lol
[12:13]  <spot> scop: we're talking about http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag
[12:13]  <scop> ok
[12:14]  <spot> tibbs: lets give it a try, if it turns out that there are packages where the corner cases are very painful to follow, we can revise as needed
[12:14]  <rdieter> spot: +1 proposal, looks to be about as good as we can hope, for a first try.
[12:14]  <tibbs> netpbm is a good example to try, if you want.
[12:14]  <lutter> yeah, the multiple license thing is icky, but I don't see a better way for it
[12:14]  <spot> tibbs: yeah, netpbm is a royal cluster fsck.
[12:14]  <tibbs> License: Assorted licenses, see %{_docdir}/%{name}-%{version}/copyright_summary
[12:15]  * spot wonders if anyone would notice if i took it out back and shot it in the head
[12:15]  <tibbs> The point is that the current draft has no escape pod for that kind of thing.
[12:15]  <spot> yes, but we've always permitted exceptions in extreme cases with justification
[12:15]  <lutter> spot: one minor thing: when people indicate licenses in the %files section, maybe hte comment should be '# License: LGPLv2+' just to be ultraclear
[12:15]  <tibbs> But then I'd argue that "License: Python and LGPLv2+ and BSD and (MPLv1.1 or GPLv2+)" is the kind of extreme case.
[12:15]  <spot> eh, i don't think that matters, as long as the intent is clear
[12:16]  <lutter> it's justa  little more grep-friendly
[12:16]  <spot> lutter: that section is just suggestions on how to document it.
[12:16]  <abadger1999> What about my suggestion to make GPLv2+ generic?
[12:16]  <spot> abadger1999: not sure what you're referring to here
[12:16]  <f13> I'm a bit unclear on the mixed source
[12:17]  <abadger1999> ie: Instead of having separate entries for GPLv2 and GPLv2+ just say that version followed by a plus means version or later.
[12:17]  <abadger1999> Otherwise you have to specify things like MPLv1.1+ as well.
[12:17]  <spot> GPLv2 means GPLv2 only
[12:17]  <spot> which is an important distinction for GPL licenses
[12:17]  <spot> and not for MPL
[12:17]  <abadger1999> (Could have a note in the GPLv2 section saying that it is important to make the distinction.)
[12:18]  <lutter> spot: I am suggesting to strongly recommend a format if format differences would just be annoying (similarly, I'd just pick a name for hte external licensing file and tell people to use that)
[12:18]  <spot> i coulda sworn i did that, but i'll look again
[12:18]  <tibbs> One thing I find problematic about this whole thing is that you can no longer just look at the COPYING or LICENSE file to determine the license tag.
[12:18]  <tibbs> Because that won't generally include the "or later" information.
[12:18]  <lutter> tibbs: but that's true toady, we just haven't gone through the trouble to indicate that in teh specfile
[12:19]  <tibbs> You callin' me a toady?
[12:19]  <spot> hehe
[12:19]  <abadger1999> spot: Err.. MPL1.0 is GPLv2 incompatible, MPL1.0+ is compatible when dual licensed.... GPLv2 is incompatible with GPLv3, GPLv2+ is compatible....
[12:19]  <lutter> tibbs: lol ... just can't type my way out of a wet paper bag
[12:19]  <tibbs> You're correct, of course.  Upstream lies about licensing all the time.
[12:19]  <spot> tibbs: while it is problematic, it seems to be an unnecessary evil.
[12:19]  <abadger1999> So the version can make a difference there as well.
[12:20]  <tibbs> It does seem simpler to say "+ means 'or later'" in one place.
[12:20]  <spot> abadger1999: hm. the FSF seems to think that only MPL 1.1 is GPL compat when dual licensed
[12:20]  <f13> spot: maybe I'm just confused by the mixed source license example.  "one of the files is generated from a BSD with advertising source file and a QPL source file" becomes (BSD, with advertising and QPL).  What is the comma for?
[12:21]  <spot> f13: the comma is in the short name for BSD w/ads
[12:21]  <Kevin_Kofler> I've also seen upstreams like Wesnoth first using "General Public License" with no version specified, and now adding "version 2" and claiming they were always v2 only even though the text of v2 says the opposite.
[12:22]  <f13> spot: can I ask why?
[12:23]  <f13> other than history, is there any reason to add another seperator there, which likely confuses humans when looking at groupings?
[12:23]  <abadger1999> spot: If it's MPL1.0 or later, then it would be compatible because you take the code under the 1.1 license in order to use it.
[12:23]  <abadger1999> That's why it's important to be able to specify version everywhere.
[12:23]  <abadger1999> FWIW, the comma threw me off for a bit as well.
[12:24]  * spot isn't tied to the comma
[12:24]  <spot> i can easily take that out without losing sleep
[12:24]  <f13> yes, it's nit-picky, but *shrug* (:
[12:24]  <abadger1999> Err s/specify version/specify or later/
[12:25]  <spot> abadger1999: i'll add a section describing the usage of +
[12:25]  <abadger1999> Thanks :-)
[12:25]  <spot> (i think i'm going to keep the GPLv2+, because it is such a common case)
[12:26]  <spot> and i'll drop the comma from the License idents
[12:26]  <abadger1999> Fair enough since pointing out GPLv2 only vs GPLv3 is one of our major goals here.
[12:26]  <tibbs> So we've rearranged the deckchairs...
[12:27]  <rdieter> recolored the bikeshed...
[12:27]  <f13> this gets a +1 fro mme
[12:27]  <tibbs> And given that we are being directed to implement this, I have to say the current draft is pretty good.
[12:27]  <tibbs> +1
[12:28]  <spot> "Some licenses state that either the current version of the license or later versions may be used. It is important to note when a license states this. When a license has an "or later version" clause, we note that by appending a + to the Short License Identifier."
[12:29]  <f13> looks good to me
[12:29]  <lutter> yeah, +1
[12:29]  <abadger1999> +1
[12:29]  <rdieter> +1
[12:29]  <spot> +1 from me
[12:29]  <spot> we should note racor's -1 vote, sent in advance
[12:29]  <scop> just drop the separate GPLv2+ identifier then, otherwise we'll start seeing GPLv2++ :)
[12:29]  <rdieter> heh
[12:30]  <rdieter> GPLv2++ = GPLv3 :)
[12:30]  <spot> scop: would you like to vote?
[12:30]  <abadger1999> rdieter: So we'll start seeing GPLv2+++ soon?
[12:30]  <scop> what is this vote exactly about, the whole shebang or...?
[12:30]  <rdieter> shebang.
[12:30]  <f13> the whole shebang
[12:30]  <scop> ok
[12:31]  <scop> +1
[12:31]  <spot> ok, it passes
[12:32]  <spot> http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups
[12:32]  <XulChris> #! <- isnt that a shebang?
[12:32]  <spot> are we waiting on any changes or tests for this item?
[12:32]  <scop> spot, does http://fedoraproject.org/wiki/Licensing have an ACL
[12:32]  <spot> scop: its about to. :)
[12:32]  <spot> but right this second, it does not.
[12:33]  * scop answers the phone, brb
[12:33]  <spot> i'm going to try to form a "licensing" group of crazy^Wmotivated individuals to help keep it current
[12:34]  <spot> a thought on UsersAndGroups
[12:34]  <spot> I think we should consider that to be our "Dynamic UID/GID creation" policy
[12:34]  * scop is back
[12:35]  <rdieter> users/groups is eating my brane
[12:35]  <spot> and hold off on a Static policy, to see if the LSB/LANANA is willing to maintain a static registry
[12:35]  <rdieter> spot: +1, wholelottasense
[12:35]  <scop> sounds sensible to me
[12:36]  <tibbs> +1
[12:37]  <spot> so, with that, i'd vote +1 for the draft, with the addition of some text clarifying that it is for dynamic UID/GID only at this time.
[12:37]  <lutter> yep, ultimately we'd want static assignments, but the UsersAndGroups thing is a good stopgap until various committees have come to a conclusion
[12:37]  <lutter> +1
[12:37]  <scop> +1
[12:37]  <abadger1999> spot: +1 for the draft with clarification.
[12:37]  <abadger1999> It should probably replace the "To create users and groups in packages, use the following: " line at the top.
[12:37]  <tibbs> +1
[12:38]  <f13> +0, I just haven't had the brainspace to think on it lately
[12:38]  <spot> rdieter: ?
[12:38]  <rdieter> +1 draft.
[12:38]  <spot> ok. this one passes.
[12:38]  <tibbs> Progress!
[12:38]  <scop> I think thimm has +1'd it too on ML
[12:38]  <spot> (FESCo is going to pee its pants)
[12:38]  <tibbs> scop: Please let me know if you find a link to that +1.
[12:38]  <spot> ok.
[12:39]  <spot> next item (no draft yet): OnlyShowIn in desktop files
[12:39]  <f13> erg.
[12:39]  <spot> this prevents kde apps from showing up in gnome menus and vice versa
[12:39]  <f13> I hoped we wouldn't have to have policy on this
[12:39]  <spot> do we want to make policy for that?
[12:40]  <f13> Leave it up to the maintainer.
[12:40]  <f13> let them battle it out in bugzilla
[12:40]  <spot> rdieter: this was your item, do you have thoughts on it?
[12:40]  <f13> maybe just 'beware' of it in the .desktop file section?
[12:41]  <f13> or rather 'be aware'
[12:41]  <abadger1999> Does someone have a link to what the spec says about OnlyShowIn?
[12:41]  <rdieter> just wondering if folks thought it worth documenting some sort of recommended policy.
[12:41]  <rdieter> for consistency.
[12:41]  <rdieter> right now, it's being used quite willy-nilly.
[12:42]  <scop> "A list of strings identifying the environments that should display/not display a given desktop entry. Only one of these keys, either OnlyShowIn or NotShowIn, may appear in a group (for possible values see the Desktop Menu Specification)."
[12:42]  <scop> http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html
[12:42]  <tibbs> abadger1999: http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html
[12:42]  <abadger1999> Thanks
[12:43]  <spot> i'm inclined to recommend that Fedora packages not use it
[12:43]  <spot> but i'm ok with it being up the maintainers discretion
[12:43]  <lutter> maybe just add a reference to that and to the menu spec .. but I don't think we need to pass a lot of rules around it
[12:43]  * rdieter nods
[12:44]  <abadger1999> I'm inclined to convert all OnlyShowIn to NotShowIn as a stopgap.
[12:44]  <abadger1999> that way the desktop environment that wants to limit the apps in their menu has control.
[12:44]  <rdieter> hee.
[12:44]  <scop> tibbs: thimm's +1 @ http://www.redhat.com/archives/fedora-packaging/2007-May/msg00098.html
[12:44]  <scop> that's a LONG time ago though
[12:45]  <scop> but he posted a few comments in favour of it later too
[12:45]  <spot> abadger1999: the logic makes sense, its the difference between ExcludeArch and ExclusiveArch
[12:45]  <tibbs> I'll just play it save and not count a vote from him.
[12:46]  <spot> i'd really prefer to see a draft on this before voting.
[12:46]  <f13> abadger1999: that was my immediate thought too.  Go for the surgical strike rather than the nuke from orbit.
[12:46]  * f13 too
[12:46]  <rdieter> spot: ok, I'll draft something up for further discussion.
[12:46]  <spot> rdieter: thanks. :)
[12:47]  <spot> so, thats all that I see on the agenda for today (other than needing to update GuidelinesTodo)
[12:47]  <spot> does anyone else have any items?
[12:48]  <spot> scop: while i'm thinking about it, i'm working on altering rpmlint to check against the Fedora licenses as opposed to the old list
[12:48]  <spot> scop: i'll send you an email with the diffs when I'm ready
[12:48]  <scop> I thought about it for a minute half an hour ago but it was too scary :)
[12:48]  <spot> i have most of it done already
[12:48]  <spot> just need to poke it a bit more
[12:49]  <scop> I'm anxiously waiting to see how you're dealing with all possible combinations ;)
[12:49]  <spot> ok, we're done. thanks everyone.
[12:49]  <f13> cheers