fun with git log

[Bjørn Mork]

tl; dr; "git log --format=..." may print much more than expected

Just had an exciting experience trying to buold an image from master.
The build would just hang at one specific package, which happend to be a
slightly modified one (I have been planning to cleanup and submit the
changes for a few years  - still on the todo list).

Looking closer, it seemed that autotools never completed configuring the
package.  It would just loop over

configure.ac:8: the top level
configure.ac:25: warning: The macro `AC_HEADER_STDC' is obsolete.
configure.ac:25: You should run autoupdate.
./lib/autoconf/headers.m4:704: AC_HEADER_STDC is expanded from...
configure.ac:25: the top level
 cd . && /bin/bash ./config.status Makefile depfiles
config.status: creating Makefile
config.status: executing depfiles commands
make[3]: Makefile.am: Timestamp out of range; substituting 2514-05-30 01:53:03.999999999
make[3]: Warning: File 'Makefile.am' has modification time 15446890191 s in the future
make[3]: configure.ac: Timestamp out of range; substituting 2514-05-30 01:53:03.999999999
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash '/home/bjorn/tmp/tmp-openwrt/build_dir/target-mips_4kec_musl/mini-snmpd-1.6/aux/missing' aclocal-1.16 
 cd . && /bin/bash /home/bjorn/tmp/tmp-openwrt/build_dir/target-mips_4kec_musl/mini-snmpd-1.6/aux/missing automake-1.16 --foreign
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash '/home/bjorn/tmp/tmp-openwrt/build_dir/target-mips_4kec_musl/mini-snmpd-1.6/aux/missing' autoconf
configure.ac:8: warning: The macro `AC_CONFIG_HEADER' is obsolete.
configure.ac:8: You should run autoupdate.
./lib/autoconf/status.m4:719: AC_CONFIG_HEADER is expanded from...
configure.ac:8: the top level



again and again.  Yes, and those files in the build directory really had
unexpcted timestamps.  They might be old, but not from 1901 :-)

Looking at the cached tar file revealed the source of confusion:

bjorn at canardo:/usr/local/src/openwrt$ zstdcat dl/mini-snmpd-1.6.tar.zst|tar tvf - 
drwxr-xr-x 0/0               0 -9223372036854775808 mini-snmpd-1.6/
-rw-r--r-- 0/0             504 -9223372036854775808 mini-snmpd-1.6/.clang-format
-rw-r--r-- 0/0             258 -9223372036854775808 mini-snmpd-1.6/.gitignore
-rw-r--r-- 0/0            1885 -9223372036854775808 mini-snmpd-1.6/.travis.yml
-rw-r--r-- 0/0             573 -9223372036854775808 mini-snmpd-1.6/AUTHORS
-rw-r--r-- 0/0            3501 -9223372036854775808 mini-snmpd-1.6/CONTRIBUTING.md
-rw-r--r-- 0/0           17989 -9223372036854775808 mini-snmpd-1.6/COPYING
-rw-r--r-- 0/0            6422 -9223372036854775808 mini-snmpd-1.6/ChangeLog.md
-rw-r--r-- 0/0            2398 -9223372036854775808 mini-snmpd-1.6/Makefile.am
-rw-r--r-- 0/0            2608 -9223372036854775808 mini-snmpd-1.6/README.develop
[snip]

Those timestamps do not look good. But where did that come from? I host
my forked source on github, so there shouldn't be any difference from
any other github hosted package.  But the bug only seemed to affect this
package (of the subset I built).  All the other generated tar archives
had sane timestamps.

Looking at include/download.mk I found that the timestamp is taken from
a TAR_TIMESTAMP variable, with rules to set that to a stable and
reasonable value for different version control systems.  But there were
no relevant changes to any of that code since the last time I built
this.  The git rule was

 export TAR_TIMESTAMP=`cd $(SUBDIR) && git log -1 --format='@%ct'`

which looked fine to me.  But just to be sure, I tested it in my openwrt
source tree.  And that's a "Doh!" moment:

bjorn at canardo:/usr/local/src/openwrt$ git log -1 --format='@%ct'
gpg: Signature made Sat Nov 30 14:24:36 2024 CET
gpg:                using EDDSA key 687BE08049F161EDA67AB21222044ECBBFA4615D
gpg: please do a --check-trustdb
gpg: Good signature from "Bjørn Mork <bmork at telenor.net>" [ultimate]
gpg:                 aka "Bjørn Mork <bjorn at mork.no>" [ultimate]
Primary key fingerprint: F461 6F51 2B11 3B3C 1827  3C21 E197 FC12 EFF0 5ECD
     Subkey fingerprint: 687B E080 49F1 61ED A67A  B212 2204 4ECB BFA4 615D
@1732973075


So, what happened here?  I can tell you: I recently set

 log.showSignature = true

in my global git config.  The special problem with the package source
was the top commit was signed.

I assume the reason this specific trigger qhasn't come up earlier is
that signed top commits still are relatively rare, and there are
probably very few people having set "log.showSignature = true" globally
on their OpenWrt build machine.

Just don't to that?  Or maybe make sure the output from "git log" is
consistent?  It is affected by several config settings.  You should
probably disable all global configuration in any script parsing git log
output.  I believe something like

 export GIT_CONFIG_NOSYSTEM=true
 export GIT_CONFIG_GLOBAL=/dev/null

will do.



Bjørn