Status of garglk since moving to Github

[salty-horse]

Hey,

Since moving the project to Github in March, I've "invited" Ben Cressey's Github account to be an owner, but got no response.
Does anyone know if Ben is well and still able/interested in working on the project?

There is at least one crash issue that I fixed, but am waiting for someone to review. I just heard from someone wishing to release a game that may hit this bug.
https://github.com/garglk/garglk/issues/213

Is anyone willing to review it, and help with a new release? Perhaps cspiegel?
Or is not a large enough issue for a new point release? Is there any policy for that?

Also, does anyone know if there's a release guide anywhere? Which platforms should be built, which mailing lists should be notified, etc?

Thanks!

[Chris Spiegel]

I've taken a look at the merge request and it looks good.

As far as I know there's no information/policies on releasing: Ben took
care of it all. I'd argue that, even if this fix didn't necessitate a
new release (which I think it does), it's been a very long time since an
official release, and there have been enough other changes to justify one.

I think that the lack of a release guide does mean at least a little
planning should be done. However, I've got no experience with Windows or
OS X development, nor packaging on most Linux distributions, so I'm not
a particularly good person to deal with it. I'll do whatever I can to
help, in any case.

One thing to look at is interpreter versions: I periodically update
interpreters, but before a release we ought to make sure they're all up
to date. It also may be worth getting the latest TADS interpreter,
because the current one is woefully out of date. It's not anywhere near
as simple as other interpreters, though.

[Andrew Plotkin]

On Wed, 16 Dec 2015, Chris Spiegel wrote:

> I'd argue that, even if this fix didn't necessitate a
> new release (which I think it does), it's been a very long time since an
> official release, and there have been enough other changes to justify one.

Agreed! Not that I'm involved in this at all.

I am now a registered MacOS developer, if that helps. I see that the build
system in the garglk repository does not rely on Xcode, so I guess that
isn't a required skill for a Mac Gargoyle release.

--Z

--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*

[Adam Thornton]

>
> I've taken a look at the merge request and it looks good.
>
> As far as I know there's no information/policies on releasing: Ben took
> care of it all. I'd argue that, even if this fix didn't necessitate a
> new release (which I think it does), it's been a very long time since an
> official release, and there have been enough other changes to justify one.
>
> I think that the lack of a release guide does mean at least a little
> planning should be done. However, I've got no experience with Windows or
> OS X development, nor packaging on most Linux distributions, so I'm not
> a particularly good person to deal with it. I'll do whatever I can to
> help, in any case.

I’m pretty swamped, but I do know my way around many Linux packaging systems, so I might be able to help with production of RPMs and DEBs.

Adam

[be...@beuc.net]

Hi,

For the Debian part, I intend to keep
https://packages.qa.debian.org/g/gargoyle-free.html updated on new
Gargoyle releases.

Other distros such as Ubuntu and Mint are basing their packaging on
this one, so it's a good base for the .deb's. It was also converted
to .rpm for the Mageia distro, so I'd recommend checking that.

(The "-free" is just a matter of disabling Hugo and using a different
default monospace font to comply with the Debian Free Software
Guidelines.)

Cheers!
Sylvain

[Brad Town]

I'd be happy to contribute at least part of what I've got thus far:

• Mac: Build with latest changes.
• Mac: Allow compilation with either MacPorts or Homebrew.
  
• Mac: Use the improved resolution of Retina displays. (Requires ugly config hack, but it works.)
• Mac: Find locations of MacPorts and Homebrew installations, headers, and libraries more consistently.
  
• Mac: Automatically identify and copy all required dylibs when building the application bundle.
  
• Mac: Set the bundle version from script.
• Mac: Eliminate building the i386 version in favor of x86-64 and Mac OS X 10.8

I'm not sure of the best way to proceed, though.

Brad

[Andrew Engelbrecht]

Hello,

I'm going to begin work on making a native gargoyle-free packge for Fedora. I'm relatively new to packaging rpms, but luckily I have a helpful mentor. I plan on starting right away.

I don't think that the package can make it into Fedora 24 due to the release schedule, but Fedora 25 is a likely target.

I plan on removing the non-free Hugo interpreter and font files, like Debian does.

Thanks for the great software! : )

Andrew

[Andrew Engelbrecht]

On Thursday, December 17, 2015 at 8:55:53 AM UTC-5, be...@beuc.net wrote:

Other distros such as Ubuntu and Mint are basing their packaging on
this one, so it's a good base for the .deb's.  It was also converted
to .rpm for the Mageia distro, so I'd recommend checking that.

(The "-free" is just a matter of disabling Hugo and using a different
default monospace font to comply with the Debian Free Software
Guidelines.)

I'm planning on packaging gargoyle for Fedora. I'm relatively new to Fedora packaging, but I have an experienced mentor who is offering guidance.

I plan on getting started right away. It may be too late to get it into Fedora 24 due to the freeze windows, but Fedora 25 is a reasonable target.

Of course I will strip out the non-free Hugo interpreter and will likely use a free font, just like Debian does.

Thanks for the great software!

Andrew

[Rémi Verschelde]

You can check my Mageia RPM for an example that should be easily
portable to Fedora. It's mostly synced with Sylvain's Debian package,
with maybe a couple Mageia-specific or RPM-based distro-specific
differences.

Spec file: http://svnweb.mageia.org/packages/cauldron/gargoyle-free/current/SPECS/gargoyle-free.spec?view=markup
Patches: http://svnweb.mageia.org/packages/cauldron/gargoyle-free/current/SOURCES/
SRPM: http://ftp-stud.hs-esslingen.de/pub/Mirrors/Mageia/distrib/cauldron/SRPMS/core/release/gargoyle-free-2011.1-10.mga6.src.rpm

Feel free to ask if you have any question.

Cheers,
Rémi / Akien

[Andrew Engelbrecht]

On 04/03/2016 01:34 PM, Rémi Verschelde wrote:
> You can check my Mageia RPM for an example that should be easily
> portable to Fedora. It's mostly synced with Sylvain's Debian package,
> with maybe a couple Mageia-specific or RPM-based distro-specific
> differences.
>
> Spec file: http://svnweb.mageia.org/packages/cauldron/gargoyle-free/current/SPECS/gargoyle-free.spec?view=markup
> Patches: http://svnweb.mageia.org/packages/cauldron/gargoyle-free/current/SOURCES/
> SRPM: http://ftp-stud.hs-esslingen.de/pub/Mirrors/Mageia/distrib/cauldron/SRPMS/core/release/gargoyle-free-2011.1-10.mga6.src.rpm
>
> Feel free to ask if you have any question.

Thanks! This should be quite useful.

What are the licenses of the SPEC, README and patch files? The default
for Fedora spec files is to release them under a default license (as my
contributions) unless I specify otherwise. Since I didn't write these,
I'll need to know their license(s).

Once I get this or a derivative into Fedora, how do you suggest we
coordinate changes?

It turns out that I still have time to put this package into the f24
updates repository. Therefore a "dnf -y install <package>" should still
work in Fedora 24.

Andrew : )

[Andrew Engelbrecht]

On Sunday, April 3, 2016 at 2:48:20 PM UTC-4, Andrew Engelbrecht wrote:

What are the licenses of the SPEC, README and patch files? The default
for Fedora spec files is to release them under a default license (as my
contributions) unless I specify otherwise. Since I didn't write these,
I'll need to know their license(s).

The default license for SPEC files in Fedora is the MIT license.

Andrew

[Rémi Verschelde]

2016-04-03 20:48 GMT+02:00 Andrew Engelbrecht <andrew...@gmail.com>:
> On 04/03/2016 01:34 PM, Rémi Verschelde wrote:
>> You can check my Mageia RPM for an example that should be easily
>> portable to Fedora. It's mostly synced with Sylvain's Debian package,
>> with maybe a couple Mageia-specific or RPM-based distro-specific
>> differences.
>>
>> Spec file: http://svnweb.mageia.org/packages/cauldron/gargoyle-free/current/SPECS/gargoyle-free.spec?view=markup
>> Patches: http://svnweb.mageia.org/packages/cauldron/gargoyle-free/current/SOURCES/
>> SRPM: http://ftp-stud.hs-esslingen.de/pub/Mirrors/Mageia/distrib/cauldron/SRPMS/core/release/gargoyle-free-2011.1-10.mga6.src.rpm
>>
>> Feel free to ask if you have any question.
>
> Thanks! This should be quite useful.
>
> What are the licenses of the SPEC, README and patch files? The default
> for Fedora spec files is to release them under a default license (as my
> contributions) unless I specify otherwise. Since I didn't write these,
> I'll need to know their license(s).

That's actually a good question, I'm not sure we have a policy about
spec file license at Mageia. If anything I'd say CC0 or at most MIT,
we don't really see a point in having restrictive licenses for spec
files; such files are often so simple that it does not really make
sense to license them IMO. (I always avoid looking at openSUSE spec
files due to the huge copyright notice at the top of each spec file
that I don't want to have to comply with).

I'll ask on Mageia's dev mailing list to get more opinions about this,
but basically you can reuse the spec file without restriction.

A good practice when basing one's work on an existing spec file is to
import the original SRPM with its changelog (Mageia does not include
the changelog in the spec file itself on SVN, but you'll find it in
the SRPM), and then add your own customisations on top of it.

> Once I get this or a derivative into Fedora, how do you suggest we
> coordinate changes?

Since RPM 4.13 is finally starting to have macros and features that
can be used cross-distro, I guess if we can manage to keep both spec
files relatively in sync, it would be nice (also for players who would
have the same gargoyle experience on Fedora and Mageia).

Usually I try to have a look at Sylvain's work every once in a while
to update my Mageia package, so we can try to keep our three packages
relatively well in sync, as most of the work anyway is to define what
components are nonfree and should not be packaged, etc. Also some of
the customizations we have could maybe be pushed upstream to reduce
the maintenance burden.

>
> It turns out that I still have time to put this package into the f24
> updates repository. Therefore a "dnf -y install <package>" should still
> work in Fedora 24.

That would be awesome! :D
>
> Andrew : )

Rémi

[Andrew Engelbrecht]

>> On 04/03/2016 01:34 PM, Rémi Verschelde wrote:
>>> You can check my Mageia RPM for an example that should be easily
>>> portable to Fedora. It's mostly synced with Sylvain's Debian package,
>>> with maybe a couple Mageia-specific or RPM-based distro-specific
>>> differences.
>>>
>>> Spec file: http://svnweb.mageia.org/packages/cauldron/gargoyle-free/current/SPECS/gargoyle-free.spec?view=markup
>>> Patches: http://svnweb.mageia.org/packages/cauldron/gargoyle-free/current/SOURCES/
>>> SRPM: http://ftp-stud.hs-esslingen.de/pub/Mirrors/Mageia/distrib/cauldron/SRPMS/core/release/gargoyle-free-2011.1-10.mga6.src.rpm

It turns out that gargoyle was previously rejected from Fedora:

* https://bugzilla.redhat.com/show_bug.cgi?id=682544
* https://fedorahosted.org/fpc/ticket/202

The basic issue is that the program would need an exception to the "No
Bundling Libraries" rule, which was not granted.

There are a couple of possibilities here:

1.) Submit the package to RPM Fusion (rpmfusion.org)
* Someone would also need to maintain smpeg. (me?)
* (I got smpeg to build with a modified version of
Mageia's .spec file.)

2.) Push changes in gargoyle libraries upstream
* It might also be possible to create new upstream repos for
libraries that are no-longer being maintained. (I'm not sure
if that would work.)
* Once this is done, I believe each library would need to be
individually packaged.

Option 2.) also requires removing mp3 support in order for gargoyle to
be accepted in Fedora's repos.

Andrew

P.S. I'm also hoping to package the Inform 6 compiler once it's ready. : )

[Chris Spiegel]

From a distribution perspective, option 2 probably make sense (so you
have something like "gargoyle-scottfree" as a package). But the problem
there is that Gargoyle interpreters are intertwined with the Gargoyle
Glk implementation. You can't build and install garglk in such a way
that interpreters can link to it.

I imagine that the preferred solution for distributions would be to make
Gargoyle a fully-functioning development package, meaning installing
both libraries and headers to the system. This would make building
against Gargoyle much easier for independent interpreters. However, it
also means that we'd have to pay attention to ABI compatibility in the
library, which hasn't been an issue to this point. I suppose an easy
approach to that is to just increment the shared library version each
release regardless of what changes are made.

As an interpreter author, being able to link against a system Gargoyle
would be nice, because it means you can port/test your interpreter with
Gargoyle without having to integrate it into Gargoyle's build system.

Regardless of all of that:

I made the scottfree port solely to support Gargoyle, so I'd have no
problems adapting it to Gargoyle's needs, whatever those may become.

I wrote Bocfel expressly to work with Gargoyle (although it works fine
with other Glk implementations), so, as with scottfree, I'll happily
make any modifications needed for Gargoyle.

I'd be willing to maintain the unmaintained ports as well, which would
probably just wind up being a dump of the Gargoyle version at release
time, but if it satisfies third parties to have an "upstream" like that,
it's worth the small time investment.

In short, I'm fine with Gargoyle how it is, but if the general consensus
is that it's worth making changes to ease integration with some vendors,
I have no problem going that route, too, and I'll do what I can to help.

Chris

[Andrew Engelbrecht]

On 04/05/2016 12:03 AM, Chris Spiegel wrote:
> On 04/04/2016 08:27 PM, Andrew Engelbrecht wrote:
>>
>> It turns out that gargoyle was previously rejected from Fedora:
>>
>> * https://bugzilla.redhat.com/show_bug.cgi?id=682544
>> * https://fedorahosted.org/fpc/ticket/202
>>
>> The basic issue is that the program would need an exception to the "No
>> Bundling Libraries" rule, which was not granted.
>>
>> There are a couple of possibilities here:
>>
>> 1.) Submit the package to RPM Fusion (rpmfusion.org)

>> 2.) Push changes in gargoyle libraries upstream

It turns out that Fedora has made major changes to their bundling policy:

* https://fedoraproject.org/wiki/Bundled_Software_policy

The policy is a quick read, so I recommend taking a peek. In short, the
strong preference is to un-bundle system libraries, but failing that,
there are alternatives.

* https://bugzilla.redhat.com/show_bug.cgi?id=682544#c23

> But the problem there is that Gargoyle interpreters are intertwined
> with the Gargoyle Glk implementation. You can't build and install
> garglk in such a way that interpreters can link to it.

How intertwined is the code? If you're already compiling by static
linkage to a single garglk codebase then creating a dynamic .so library
should be pretty easy. I'm willing to help with that.

Does Garglk expand upon or change the standard Glk API?

> However, it also means that we'd have to pay attention to ABI
> compatibility in the library, which hasn't been an issue to this
> point. I suppose an easy approach to that is to just increment the
> shared library version each release regardless of what changes are
> made.

If you create a dynamic library then you should only need to focus on
the API. GNU/Linux and unix-based systems have a good record for drop-in
replacement of dynamic libraries and binaries across versions. If Garglk
makes incompatible API changes, then interpreters have only to specify
the needed version of Garglk in their build instructions.

> In short, I'm fine with Gargoyle how it is, but if the general consensus
> is that it's worth making changes to ease integration with some vendors,
> I have no problem going that route, too, and I'll do what I can to help.

I'm not familiar with the garglk/gargoyle code base, but I'm happy to
help in the effort of splitting out the garglk dependency and pushing
changes to living upstream projects.

Andrew

[Chris Spiegel]

On 04/05/2016 12:37 PM, Andrew Engelbrecht wrote:
> On 04/05/2016 12:03 AM, Chris Spiegel wrote:
>> On 04/04/2016 08:27 PM, Andrew Engelbrecht wrote:
>>>
>>> It turns out that gargoyle was previously rejected from Fedora:
>>>
>>> * https://bugzilla.redhat.com/show_bug.cgi?id=682544
>>> * https://fedorahosted.org/fpc/ticket/202
>>>
>>> The basic issue is that the program would need an exception to the "No
>>> Bundling Libraries" rule, which was not granted.
>>>
>>> There are a couple of possibilities here:
>>>

>> But the problem there is that Gargoyle interpreters are intertwined
>> with the Gargoyle Glk implementation. You can't build and install
>> garglk in such a way that interpreters can link to it.
>
> How intertwined is the code? If you're already compiling by static
> linkage to a single garglk codebase then creating a dynamic .so library
> should be pretty easy. I'm willing to help with that.
>
> Does Garglk expand upon or change the standard Glk API?

It's not intertwined in such a way that it'd be difficult to separate
(it's already built as a shared library, in fact); just that it's
currently meant for interpreters and libgarglk.so to be built together,
in the manner that FreeBSD, for example, bundles its base tools and
libraries. They can be separated with a little effort, but it wasn't
designed that way.

Gargoyle adds a few custom API functions, but nothing that should affect
non-Gargoyle-aware interpreters.

>> However, it also means that we'd have to pay attention to ABI
>> compatibility in the library, which hasn't been an issue to this
>> point. I suppose an easy approach to that is to just increment the
>> shared library version each release regardless of what changes are
>> made.
>
> If you create a dynamic library then you should only need to focus on
> the API. GNU/Linux and unix-based systems have a good record for drop-in
> replacement of dynamic libraries and binaries across versions. If Garglk
> makes incompatible API changes, then interpreters have only to specify
> the needed version of Garglk in their build instructions.

As it stands, we'd be free to change, for example, the "event_t" struct
(say to rearrange members, which wouldn't affect the API), and not worry
about how that affected anything, because we'd guarantee that all
interpreters are built knowing the proper struct layout. However, if
libgarglk were released as a shared library others were meant to link
against, we'd now have to know that there was an ABI change, as those
interpreters built against a prior release would have the wrong idea
about the struct layout. We'd have to make sure that, if the old one
was libgarglk.so.1, the new one is at least libgarglk.so.2.

It's not especially hard to manage, it's just something that would need
to be considered when now it's not.