Bug 682544

Summary: Review request: gargoyle - multi-format interactive fiction interpreter
Product: [Fedora] Fedora Reporter: Carlo Teubner <ct.spammable>
Component: Package ReviewAssignee: Nobody's working on this, feel free to take it <nobody>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: rawhideCC: andrew, ct.spammable, extras-qa, fedora-package-review, j, ktdreyer, matteo, musuruan, tcallawa
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: NotReady
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-02-13 00:01:32 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 658489    

Description Carlo Teubner 2011-03-06 14:56:52 UTC
Spec URL: http://carlolab.appspot.com/files/gargoyle.spec
SRPM URL: http://carlolab.appspot.com/files/gargoyle-2010.1-2.fc14.src.rpm
Description:
---
Gargoyle is an interpreter for interactive fiction (text adventure) story files
which supports all major formats. It puts special emphasis on excellent text
display.

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
restrictions.
---

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.

Comment 1 Carlo Teubner 2011-04-08 21:08:43 UTC
In case anyone wants to try this out, I've uploaded binary RPMs too:

http://carlolab.appspot.com/files/gargoyle-2010.1-2.fc14.x86_64.rpm
http://carlolab.appspot.com/files/gargoyle-2010.1-2.fc14.i686.rpm

Anyone care to comment?

Comment 2 Ken Dreyer 2011-04-26 14:18:57 UTC
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?

Comment 3 Ken Dreyer 2011-04-26 14:26:48 UTC
Whoops, I see you've already blocked FE-NEEDSPONSOR, sorry about that!

Comment 4 Ken Dreyer 2011-04-26 14:35:19 UTC
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

Comment 5 Ken Dreyer 2011-04-26 14:47:36 UTC
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

!#/bin/sh
VERSION=$1

unzip gargoyle-$VERSION-sources.zip

# non-free license
# (non-commercial use only and cannot modify the source code), it's
# displayed in the Windows installer available at
# http://www.generalcoffee.com/hugo/gethugo.html

rm -r gargoyle-$VERSION/terps/hugo
rm gargoyle-$VERSION/licenses/HUGO License.txt

# non-free license (cannot modify the font)
rm gargoyle-$VERSION/garglk/fonts/LuxiMonoBoldOblique.pfb
rm gargoyle-$VERSION/garglk/fonts/LuxiMonoBold.pfb

# etc.

tar -cjf gargoyle-$VERSION-free.tar.bz2 gargoyle-$VERSION

Comment 6 Carlo Teubner 2011-05-14 12:20:48 UTC
Thanks, Ken. I've added a generate-tarball.sh script as suggested.

New/updated files:

http://carlolab.appspot.com/files/gargoyle.spec
http://carlolab.appspot.com/files/gargoyle-2010.1-3.fc14.src.rpm
http://carlolab.appspot.com/files/gargoyle-2010.1-3.fc14.x86_64.rpm
http://carlolab.appspot.com/files/gargoyle-2010.1-3.fc14.i686.rpm
http://carlolab.appspot.com/files/generate-tarball.sh

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.

Comment 7 Ken Dreyer 2011-06-03 18:33:31 UTC
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" ?

Comment 8 Jason Tibbitts 2011-06-03 20:59:22 UTC
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:
http://fedoraproject.org/wiki/Packaging:Guidelines#Bundling_of_multiple_projects
http://fedoraproject.org/wiki/Packaging:Guidelines#Duplication_of_system_libraries
http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
http://fedoraproject.org/wiki/Packaging:Treatment_Of_Bundled_Libraries

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.

Comment 9 Carlo Teubner 2011-06-07 20:01:19 UTC
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?

Comment 10 Ken Dreyer 2011-06-08 14:07:49 UTC
(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 legal.o 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
 [snip]
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?

Comment 11 Tom "spot" Callaway 2011-06-30 17:57:26 UTC
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.

Comment 12 Carlo Teubner 2011-07-02 13:38:32 UTC
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:

https://github.com/c4rlo/gargoyle-fedora/commit/9135af177e218b0e6b3909ab13a1db5cc6977c81
https://github.com/c4rlo/gargoyle-fedora/commit/603e8c05238a497cbb06457dab1856279a1f9a6f

Latest files:

http://carlolab.appspot.com/files/gargoyle.spec
http://carlolab.appspot.com/files/gargoyle-2010.1-4.fc15.src.rpm
http://carlolab.appspot.com/files/gargoyle-2010.1-4.fc15.x86_64.rpm

Comment 13 Ken Dreyer 2011-07-11 00:34:08 UTC
(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?

Comment 14 Andrew Engelbrecht 2011-07-24 14:45:43 UTC
> 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.

Comment 15 Carlo Teubner 2011-12-18 15:13:47 UTC
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."

Comment 16 Carlo Teubner 2011-12-21 17:54:07 UTC
Ok, new RPM is uploaded:

http://carlolab.appspot.com/files/gargoyle.spec
http://carlolab.appspot.com/files/gargoyle-2011.1-1.fc16.i686.rpm
http://carlolab.appspot.com/files/gargoyle-2011.1-1.fc16.src.rpm

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...

Comment 17 Jason Tibbitts 2012-06-29 20:43:17 UTC
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?

Comment 18 Jason Tibbitts 2012-07-03 23:35:23 UTC
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.

Comment 19 Carlo Teubner 2012-08-05 14:09:23 UTC
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:

http://koji.fedoraproject.org/koji/taskinfo?taskID=4360550
https://raw.github.com/c4rlo/gargoyle-fedora/patch/gargoyle.spec

Comment 20 Jason Tibbitts 2012-08-10 20:33:30 UTC
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.

Comment 21 Carlo Teubner 2012-08-11 13:20:11 UTC
Application for bundling exemption filed at https://fedorahosted.org/fpc/ticket/202

Comment 22 Jason Tibbitts 2012-08-15 19:10:44 UTC
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.)

Comment 23 Andrew Engelbrecht 2016-04-05 19:35:50 UTC
In light of the recent changes to the bundling policy:

* http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
* https://fedoraproject.org/wiki/Bundled_Software_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:

* https://groups.google.com/forum/#!msg/garglk-dev/RaIeXYNiivI/xDIQkFxoFwAJ

Can gargoyle-free be included before such work is completed?

Comment 24 Jason Tibbitts 2016-04-05 19:54:46 UTC
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.

Comment 25 Andrew Engelbrecht 2016-04-05 20:29:59 UTC
(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:

* https://bugzilla.redhat.com/show_bug.cgi?id=1324212