> Too clever for me :-)  It's a Guile library; hence the correct Guix
> name (and variable) is ‘guile-g-golf’.  We have plenty of
> ‘python-pyfoo’ packages to keep it company.
>

No.  I can't change this to guile-g-golf.  The author of g-golf has
explicated stated they would like the package name to be g-golf.

> Could you add a comment here explaining why we use a git commit,
> instead of a release tarball or tag?  I assume there are none; that
> would do as comment.  However…

I've added a comment for why git sources are used.

> …‘1’ means the project has released version 1 prior to this commit, or
> at least regards this commit as part of the ‘1’ series. I didn't spot
> any version number on the home page, NEWS file, git tags, …
>
> If there is no ‘1’ release, use ‘0.0.0’.
>
> The second field (REVISION) should be ‘0’, since this is the first
> *Guix* revision of this package.  The idea is that you increment the
> revision each time you change COMMIT, so Guix knows which commit is
> newer and can ‘guix package -u’ properly.
>
> Since the 2 should be updated together, bind them together:
>
>  (let ((commit "f00")
>        (revision "0")) …
>
> You obviously got ‘683’ from somewhere though.  Where?
>

This is fixed now, this got carried over from me tracking upstream
revisions. I've reset it to version 0.0.0 and revision 0. This is
probably the most important fix.

> Prefer ‘verb-thing’; makes it much easier to skim unfamiliar packages.
>

done

>
> For now, all phases must return #t.  SUBSTITUTE* doesn't, so we need
>
>             (lambda …
>               …
>               (substitute* "test-suite/tests/gobject.scm"
>                 (("/dev/tty") "/dev/null"))
>               #t)

done

> No need to put the file name on its own line here.
>
> +           (add-before 'configure 'substitute-libs

done