Spec URL: http://carlolab.appspot.com/files/gargoyle.spec
SRPM URL: http://carlolab.appspot.com/files/gargoyle-2010.1-2.fc14.src.rpm
Gargoyle is an interpreter for interactive fiction (text adventure) story files
which supports all major formats. It puts special emphasis on excellent text
See http://ifdb.tads.org/ and http://www.ifarchive.org/ for many free works.
This package excludes the Alan 2, Alan 3 and Hugo interpreters due to licensing
Since this is my first package, I require a sponsor.
Some further background: Gargoyle (http://ccxvii.net/gargoyle/) bundles
interpreters for several interactive fiction story file formats, including
Z-code, TADS and others. It uses the same subpixel text rendering presentation
for all of these; it does not expose the UI for any of the bundled
interpreters, but only the interpreter core. It's been around for a few years
and is very popular in the Interactive Fiction community. It's already in
several other distros: http://code.google.com/p/garglk/wiki/Packages
The bundled interpreters have a variety of licenses. A couple don't have
Fedora-approved licenses, so these had to be left out from the SRPM. The
license situation may change in the future, so they may be included in a future
version. I've also left out some bundled fonts with Fedora-incompatible licenses, and instead declared dependencies on linux-libertine-fonts and liberation-mono-fonts, which gargoyle is configured to use.
I had previously submitted this to RPM Fusion because upstream gargoyle links against smpeg, but discovered that I could instead just leave out -lsmpeg from the link line; gargoyle would be unable to take advantage of it anyway, because it only uses SDL_sound directly, and the Fedora version of SDL_sound is configured without its optional MP3 support via smpeg. Very few interactive fiction games use sound at all, so this is not a big deal.
In case anyone wants to try this out, I've uploaded binary RPMs too:
Anyone care to comment?
Hi Carlo, I see that you're in FAS as "carlo", but I don't see that you're in the packagers group yet. Do you need a sponsor?
Whoops, I see you've already blocked FE-NEEDSPONSOR, sorry about that!
You've included a URL in the comments to the original source zip file, great. Can you include a script that documents how you are transforming upstream's .zip to what you're proposing in your .tar.bz2? https://fedoraproject.org/wiki/Packaging:SourceURL#When_Upstream_uses_Prohibited_Code
Looks like you've documented things in README.fedora. Can you can transform this into a shell script so it's easily repeatable? Something like
# non-free license
# (non-commercial use only and cannot modify the source code), it's
# displayed in the Windows installer available at
rm -r gargoyle-$VERSION/terps/hugo
rm gargoyle-$VERSION/licenses/HUGO License.txt
# non-free license (cannot modify the font)
tar -cjf gargoyle-$VERSION-free.tar.bz2 gargoyle-$VERSION
Thanks, Ken. I've added a generate-tarball.sh script as suggested.
Note that since README.fedora already contains an explanation of why we cannot include the various pieces, I have omitted such explanation from generate-tarball.sh.
Slowly working my way through reviewing this.
MUST: The License field in the package spec file must match the actual license.
This looks ok, with one exception. Please help me understand the license for the"Glulxe" portion ? From terps/glulxe/README:
The source code in this package is copyright 1999-2010 by Andrew Plotkin.
You may copy and distribute it freely, by any means and under any conditions,
as long as the code and documentation is not changed. You may also
incorporate this code into your own program and distribute that, or modify
this code and use and distribute the modified version, as long as you retain
a notice in your program or documentation which mentions my name and the
URL shown above.
"as long as the code and documentation is not changed" ? But then "You may also ... modify this code" ?
I note that this program appears to bundle multiple separate upstream projects, in contravention of the Fedora packaging guidelines.
Have a look at the following:
Simply, separate upstream projects should be packaged separately and this package can depend on them. (It must delete the source code, even for the free ones, in %prep. This is in addition to deleting the non-distributable ones from the tarball.) If it's properly written (finds the available interpreters at runtime), someone could even separately package up the non-free ones and distribute them outside of the project.
Jason, it's the upstream gargoyle project that does the bundling. And it's not bundling libraries, but it's distributing its own versions of the executables for each interpreter, modified to use the Gargoyle display library. Indeed, that is the only library contained in this package.
So even if one of the bundled interpreters was present on a system, gargoyle would be unable to take advantage of that, even in principle.
Changing this would be a major rearchitecting of the upstream project.
Ken, I agree that is some weird phrasing. But it is not self-contradictory, merely redundant. So I don't see it as a problem.
If it is a problem, how could this be addressed? Would I need to obtain a statement from Andrew Plotkin clarifying his intention?
(In reply to comment #9)
> Jason, it's the upstream gargoyle project that does the bundling. And it's not
> bundling libraries, but it's distributing its own versions of the executables
> for each interpreter, modified to use the Gargoyle display library. Indeed,
> that is the only library contained in this package.
Fedora's policy is to work with upstream to get changes pushed to the respective project owners. So, if the Gargoyle project has modified another underlying project, they need to push those changes back to the project's upstream owner.
> So even if one of the bundled interpreters was present on a system, gargoyle
> would be unable to take advantage of that, even in principle.
This sounds like they have made some changes to the bundled interpreters that need to go upstream into those interpreters.
> Changing this would be a major rearchitecting of the upstream project.
You have the freedom to apply for an exception from FESCo, but they will want more details regarding why Fedora's policy would not apply here. Please carefully read over http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries . (Not to be a pain on this, but if we don't ask about this, someone else will.)
> Ken, I agree that is some weird phrasing. But it is not self-contradictory,
> merely redundant. So I don't see it as a problem.
> If it is a problem, how could this be addressed? Would I need to obtain a
> statement from Andrew Plotkin clarifying his intention?
The best thing imho would be if Andrew could just re-license his package under something that is already approved by Fedora, eg MIT. His terms sound similar to the MIT License, although Andrew is also requiring that his URL be preserved, so I'm really not sure. I asked on firstname.lastname@example.org in case Andrew is unwilling to re-license. http://lists.fedoraproject.org/pipermail/legal/2011-June/001674.html
In the course of my review I found two technical things that should be fixed in the package:
$ rpmlint gargoyle-2010.1-3.fc14.src.rpm
gargoyle.src: W: strange-permission generate-tarball.sh 0775L
gargoyle.src: W: invalid-url Source0: gargoyle-2010.1.tar.bz2
1 packages and 0 specfiles checked; 0 errors, 2 warnings.
Please fix the permissions on generate-tarball.sh (755 should be ok)
$ rpmlint gargoyle-debuginfo-2010.1-3.fc14.i686.rpm
gargoyle-debuginfo.i686: E: incorrect-fsf-address /usr/src/debug/gargoyle-2010.1/terps/nitfol/globals.c
1 packages and 0 specfiles checked; 81 errors, 0 warnings.
The 81 warnings on the debuginfo package are all for the incorrect FSF address. Would you mind filing bug(s) upstream on this?
Since the Glulxe license is okay, I'm lifting FE-Legal here, even with the bundling issues still to be resolved, as those are not strictly speaking, legal blockers.
Thanks Tom. I've emailed Andrew Plotkin, asking him to consider changing the license to standard open source license anyway. I've changed the License tag in the spec file to "Glulxe" as per your recommendation at http://lists.fedoraproject.org/pipermail/legal/2011-June/001684.html; unsurprisingly I now get
gargoyle.x86_64: W: invalid-license Glulxe
I've changed the permissions of generate-tarball.sh to 0755 and rpmlint is still complaining:
gargoyle.src: W: strange-permission generate-tarball.sh 0755L
Regarding the incorrect-fsf-address issue, I've filed http://code.google.com/p/garglk/issues/detail?id=153 with Gargoyle.
As for the bundling issue, I'm fairly certain that nothing can be done about this upstream, but I'm reaching out to the maintainer for a comment on this.
I've also repackaged this for Fedora 15.
To see my (minimal) changes to the spec file:
(In reply to comment #12)
> As for the bundling issue, I'm fairly certain that nothing can be done about
> this upstream, but I'm reaching out to the maintainer for a comment on this.
How significant are the changes in Gargoyle's copies of the bundled libs?
> How significant are the changes in Gargoyle's copies of the bundled libs?
From the README in the support/ directory containing the libraries (i'm guessing not much has changed):
These packages have been stripped of makefiles, config scripts,
examples, test files, unused modules, and that sort of files
in order to reduce the size.
The originals can be found on the internet. Use google.
Is there any chance that this will get sponsored at some point?
If so, I might work on packaging the latest version of Gargoyle (2011.1) for Fedora 16.
For reference, here's what the Gargoyle upstream maintainer, Ben Cressey, said when I asked him about the possibility of depending on upstream interpreters.
"It might be possible to pull in the interpreters as dependent packages, however most of them are not actively maintained and no package exists.
"Even where an upstream version exists, building them for Gargoyle is akin to building them for a different UI toolkit. I don't know what Fedora's policy is on maintaining separate packages linked to Qt versus Gtk, but it seems reasonable to me that the requisite changes to the source would be treated as a fork rather than pushed upstream.
"Gargoyle's Glk implementation is an alternative both to other Glk implementations and native UI toolkits (Gtk/Qt). Under Linux it is the de facto standard for Glk since it is the only one with multimedia support that is actively maintained. But that just means that an IF interpreter built for Linux will target the native UI toolkit instead, to avoid being locked into Gargoyle.
"If the objection is that Frotz exists as a Fedora package, I should mention that Gargoyle bundles GlkFrotz which is now an independent fork. The version packaged for Fedora appears to be much older and probably lacks support for Unicode and the Z-Machine Standard 1.1."
Ok, new RPM is uploaded:
I've upgraded to the new upstream version, Gargoyle 2011.1. http://code.google.com/p/garglk/wiki/Changes has the changes.
In addition, because the Alan 2 and Alan 3 interpreters are now under a Fedora-approved license (Artistic 2.0), I'm no longer excluding those. Hugo is still excluded. The interpreters new in this version (bocfel, scottfree) are both GPL.
Would be nice to see this sponsored finally...
I just came across this while looking through the older NEEDSPONSOR tickets. I'm actually quite interested in this kind of thing, so I'd be happy to help you out. Are you still interested in submitting this package?
Never mind; I found the account had gone inactive. The spec looks pretty good, and its obvious that a lot of work went into it, so hopefully either Carlo will come back or someone else will pick it up.
Hi Jason, sorry for the slow response. I'm still interested in getting this sponsored and submitted! I've made some small changes and verified that it builds for F17:
You neglected to link to the srpm, but I pulled it from the koji task. I'll reiterate that the spec itself looks good; a first glance shows only a couple of minor issues. However, as mentioned in earlier comments, the bundling really is a blocker here. The relevant guidelines are at http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
Now, what to do about that? I really don't see going back to the original versions of the interpreters, if you can even find them. Without porting to glk there would be no point in using them. Probably best to file a bundling exception with the packaging committee as documented on that wiki page and see if there's any consensus. We will meet on Wednesday so if you can get your ticket in before then it's possible we can move forward with this soon. Do be sure to answer as many of those stock questions as possible in as much detail as you can.
By the way, it's not the package that is sponsored, it's the packager. The package itself is merely reviewed. Once you're a packager, you don't require sponsorship to submit additional packages.
Application for bundling exemption filed at https://fedorahosted.org/fpc/ticket/202
So, FPC has met about this. There's no vote yet, but let me summarize the meeting:
You will probably be granted an exception for the interpreters in cases 1-3. Almost certainly for 1-2.
You will probably not be granted an exception for cases 4-5. 4 specifically is a question of why upstream isn't up to date. 5, well, that's just saying that it's a bit too much trouble.
However, there is a chicken and egg thing going here, and the situation is complicated, so nothing is decided. There is also a question of whether it's permissible to have a content interpreter with no content, as we have a prohibition against that. (Though in my opinion it is misguided and unless frotz is removed it would be unevenly applied.)
In light of the recent changes to the bundling policy:
Is gargoyle-free eligible to be in included in Fedora as-is? If not, what changes need to be made?
There is a discussion of possible un-bundling work going on here:
Can gargoyle-free be included before such work is completed?
Yes, the bundling restrictions have been lifted. I have no idea whether the package actually meets the packaging guidelines, though; it would need a proper package review.
If someone wants to submit a gargoyle package, they should open a new ticket so as to not spam the person who submitted this one.
(In reply to Jason Tibbitts from comment #24)
> If someone wants to submit a gargoyle package, they should open a new ticket
> so as to not spam the person who submitted this one.
Here's the new ticket for gargoyle: