[bug #68563] explore support for "artifact-free" builds and manual groff version number specification

--8323329-1714636915-1785006726=:305754
Content-Type: TEXT/plain; CHARSET=utf-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-Disposition: inline

URL:=0A  <https://savannah.gnu.org/bugs/?68563>=0A=0A                 Summa=
ry: explore support for "artifact-free" builds and=0Amanual groff version n=
umber specification=0A                   Group: GNU roff=0A               S=
ubmitter: gbranden=0A               Submitted: Sat 25 Jul 2026 07:11:53 PM =
UTC=0A                Category: General=0A                Severity: 1 - Wis=
h=0A              Item Group: Build/Installation=0A                  Status=
: None=0A                 Privacy: Public=0A             Assigned to: None=
=0A             Open/Closed: Open=0A         Discussion Lock: Unlocked=0A  =
       Planned Release: None=0A=0A=0A    __________________________________=
_____________________=0A=0AFollow-up Comments:=0A=0A=0A--------------------=
-----------------------------------=0ADate: Sat 25 Jul 2026 07:11:53 PM UTC=
 By: G. Branden Robinson <gbranden>=0A[https://lists.gnu.org/archive/html/g=
roff/2026-07/msg00013.html Phong wrote of=0Aa build scenario] appealing to =
those who attempt to minimize use of=0A"artifacts" (roughly, files in a sou=
rce release that are not directly=0Ahuman-maintained).  I speculate that on=
e of the reasons people are interested=0Ais to minimize surface area expose=
d to an=0A[https://en.wikipedia.org/wiki/XZ_Utils_backdoor XZ Utils backdoo=
r-style=0Aattack].=0A=0AThe discussion sprawled considerably, so here's my =
summary of the backbone of=0Ait as applied to this ticket.=0A=0A=0AI'm tryi=
ng to switch to building from Git=0A(we are trying to avoid artefacts like =
generated configure=0Awhere possible) and without the .git directory=0A(whi=
ch is not reproducible) configure is failing to find=0Athe version:=0A=0A  =
  configure flags: ("CONFIG_SHELL=3D.../bin/bash"=0A                      "=
SHELL=3D.../bin/bash"=0A                      "--prefix=3D...groff-1.25.0.r=
c2"=0A                      "--enable-fast-install"=0A                     =
 "--docdir=3D   groff-1.25.0.rc2-doc/share/doc/groff"=0A                   =
   "--build=3Dx86_64-unknown-linux-gnu")=0A    configure: WARNING: unrecogn=
ized options: --enable-fast-install=0A    checking that groff version strin=
g has valid format...  invalid=0A    configure: groff's version string must=
 start with three decimal=0A    integers separated by dots.  "" does not ma=
tch.=0A=0A=0ALater, [https://lists.gnu.org/archive/html/groff/2026-07/msg00=
016.html Phong=0Aelaborated].=0A=0A=0AI'm speaking for the automated build =
pipeline here.  On Guix,=0Aif a package is built from a Git checkout, a fre=
sh clone=0Awould be made, then the .git directory shall be removed,=0Ahence=
 the following won't work.=0A=0AOn 2026-07-21 at 00:35-05:00, G. Branden Ro=
binson wrote:=0A> The rules for generating these files are as follows.=0A> =
=0A> $ nl -ba Makefile.am | sed -n 872,874p=0A> 872  # Version files - see =
script "build-aux/git-version-gen".=0A> 873  .version:=0A> 874          $(A=
M_V_GEN)echo $(VERSION) > $@-t && mv $@-t $@=0A=0AOn 2026-07-21 at 00:40-05=
:00, G. Branden Robinson wrote:=0A> Earlier in the file.=0A> =0A> $ nl -ba =
Makefile.am | sed -n 509,509p=0A> 509  # 'VERSION' is generated by gnulib s=
cript git-version-gen=0A=0AI've resulted to writing to .tarball-version ins=
tead=0Aand the build and tests succeeded.  Please let me know=0Aif this has=
 any unintended effect.=0A=0A=0A[https://lists.gnu.org/archive/html/groff/2=
026-07/msg00017.html I replied.]=0A=0A=0ANone that I know of, but I'm nervo=
us about the practice.  If your build=0Afrom the repository is failing to p=
roperly populate ".version", I'm=0Astrongly interested to know the failure =
mode.=0A=0A=0A[https://lists.gnu.org/archive/html/groff/2026-07/msg00018.ht=
ml Phong followed=0Aup to sketch the shape of a potential solution.]=0A=0A=
=0AIIUC, both .version and .tarball-version comes from $VERSION,=0Awhich in=
 turn is derived from the current Git HEAD in .git.=0A=0ATBH manually popul=
ating a version file is not unusual practice in Guix,=0Athough it'd be love=
ly if the configure script excepts a --version=3D...=0Aoverride flag.  If t=
hat sounds good, I don't expect it in 1.25,=0Aand can offer a patch.=0A=0A=
=0A[https://lists.gnu.org/archive/html/groff/2026-07/msg00019.html I respon=
ded].=0A=0A=0A>> The .version file is not placed in the ".git" directory,=
=0A>> but the root of the build tree=0A> =0A> I was referring to the git-ve=
rsion-gen script, which needs .git to=0A> determine the current tag/commit.=
=0A=0AAh.  In that case your build is neither fish nor fowl: neither a buil=
d=0Afrom a distribution archive, nor a build from a Git working copy,=0Abec=
ause there is no working copy.=0A=0AWhat is the rationale for this sort of =
build configuration?=0A=0AWe've had problems supporting that sort of thing =
in the past.=0A=0Ahttps://lists.gnu.org/archive/html/groff/2022-06/msg00001=
.html=0A=0AThe consensus at that time was not to support them, hence the di=
sabled=0A"snapshot tarballs" via Savannah's cgit interface.=0A=0A...=0A=0A>=
 IIUC, both .version and .tarball-version comes from $VERSION,=0A> which in=
 turn is derived from the current Git HEAD in .git.=0A=0AUltimately, yes.=
=0A=0A> TBH manually populating a version file is not unusual practice in=
=0A> Guix, though it'd be lovely if the configure script excepts a=0A> --ve=
rsion=3D...  override flag.  If that sounds good, I don't expect it=0A> in =
1.25, and can offer a patch.=0A=0AHmm.  If it's that easy, why isn't this a=
lready standard practice in=0Aprojects using Autoconf?  Or is it, and I hav=
en't noticed?=0A=0A=0A[https://lists.gnu.org/archive/html/groff/2026-07/msg=
00020.html Phong then=0Asnarfed a potential mechanism from a Guix thread.]=
=0A=0A=0AI don't know if it will be easy, I was offerring a hand=0Aundersta=
nding it is not a high priority for Groff.=0A=0AFrom the linked thread, how=
 about hardcoding in configure.ac=0Athe `build-aux/git-version-gen --fallba=
ck' version?=0AThis can be done every time a new version number is added=0A=
to the NEWS file.=0A=0A=0A[https://lists.gnu.org/archive/html/groff/2026-07=
/msg00023.html I dithered=0Anoncomittally.]=0A=0A=0AThat's not a bad idea. =
 We're down to only 2 places where a hand update=0Ais required, and one of =
those is going to be essential anyway.  If I can=0Afix the other case, then=
 we'd still be no worse off.=0A=0AI seem to remember we fooled with `--fall=
back` in that 2022 groff=0Athread, though, and ran into problems.  Somethin=
g to do with gnulib...??=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A    _________________=
______________________________________=0A=0AReply to this item at:=0A=0A  <=
https://savannah.gnu.org/bugs/?68563>=0A=0A________________________________=
_______________=0AMessage sent via Savannah=0Ahttps://savannah.gnu.org/=0A
--8323329-1714636915-1785006726=:305754
Content-Type: APPLICATION/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQQk97aszIMMAvLLwm6qLAuaBUf3TgUCamUKhgAKCRCqLAuaBUf3
TgbqAP4yVhAQvoAhkYGN+RFa56qtm7M7xnxfB2xDmzK2onabRQEA0t/hM7VC44t7
WEAmar9j9CvuGoVTDAui3AX99gNsWgg=
=0SfU
-----END PGP SIGNATURE-----

--8323329-1714636915-1785006726=:305754--