Re: gash update failures

[Timothy Sample]

Hi Nikita,

(I’ve CC’ed gash-devel, BTW.)

Nikita Gillmann <address@hidden> writes:

> I've been packaging gash since 0.1 or some time before that for pkgsrc.
> Since we target a broad range of Operating Systems, I'd have 1 patch to
> prepare and upstream and 1 remark/question:
>
> in the Makefile.am:
>
>         timestamp=$$(git log --pretty=format:%ct -- doc/gash.texi \
>                          | sort -n -r | head -n 1); \
>
> How does guix (as primary user of this) cope with this? Outside of a
> sandboxed build and git being available, I get errors about the
> release tarball not being a git checkout (expected).  Sandboxed
> builders of us will probably crash the build, as I've been
> experiencing it with www/zola where I'm in the middle of a discussion
> and patches about git being invoked during build.
>
> This is precondition to the patch I need to make, which would either
> conditionally pick the right invocation for the right date(1)
> implementation or solve the release/month/day differently. Right now
> even when I would be on a system with a gnu date iplementation,
> timestamp would be empty and the command would not work.

First, thanks for packaging Gash!  I really appreciate the work that
package maintainers do and I am excited that Gash has been ported to the
BSD world.

That particular invocation of Git is supposed to be for maintainers
(i.e., me).  The resulting file (“version.texi”) is distributed in the
tarball, and should not need to be regenerated.  I wonder if there is an
mtime issue that is causing Make to try to generate it again.  Could it
be a difference between GNU and BSD Tar?  A quick and dirty fix would be
to run “touch doc/version.texi” before running “make”.

To address your first question directly, Guix doesn’t do anything
special.  It never tries to invoke Git because “version.texi” is already
there, and we don’t regenerate it.

For a bit of background, that rule was added in an effort to make
generating a tarball from the Git repository reproducible.  That is, if
someone other than me runs “make dist” from a release tag, they should
get the same result (bit for bit) as the corresponding release tarball.
(In practice there are some issues around which version of Autoconf, et
al. are used.)  The reason I bring this up (besides the fact the I think
it’s nifty) is that the way Tar is invoked to create the distribution
tarball sets all the timestamps to the time of the most recent commit.
Perhaps this is root of the mtime problems.

Let me know if the mtime thing is the issue and if there is any other
way I can make it easier to build and distribute Gash.  :)


-- Tim