Re: groff 1.25.0.rc1 testing

--t76nxtbzijlx7rsj
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Subject: Re: groff 1.25.0.rc1 testing
MIME-Version: 1.0

At 2026-07-21T15:32:53+0900, Nguy=E1=BB=85n Gia Phong wrote:
> On 2026-07-21 at 00:35-05:00, G. Branden Robinson wrote:
> > At 2026-07-21T14:07:10+0900, Nguy=E1=BB=85n Gia Phong wrote:
> > > Alternatively, I'm trying to switch to building from Git (we are
> > > trying to avoid artefacts like generated configure where possible)
> > > and without the .git directory (which is not reproducible)
> > > configure is failing to find the version:
> >
> > Right.  You now need to specify `--enable-maintainer-mode` to
> > "configure" when building from Git.
> >
> > In my next push, this will be clearer.  Here's an exhibit from my
> > working copy.
> >
> >     INSTALL.REPO: Document `--enable-maintainer-mode`.
>=20
> Thanks, though looking at e2cd638955de ("doc/doc.am:
> Employ `MAINTAINER_MODE`.") this only affects requiring
> ImageMagick as a dependency.

For now.  There may already exist other "informal" maintainer-mode stuff
we should bring under the governance of the `MAINTAINER_MODE` Automake
macro, and further such things may arise in the future.

One existing instance I can think of is the generation of the Bison/YACC
grammars for eqn, pic, and refer.

See a recent commit:

commit baac1d37e9cbf38c786a89e34201bd9cce0ec19f
Author: G. Branden Robinson <[email protected]>
Date:   Thu Jul 2 12:12:37 2026 -0500

    [eqn,pic,refer]: Clean out-of-source build trees.

    ...better.

    * src/preproc/eqn/eqn.am:
    * src/preproc/pic/pic.am:
    * src/preproc/refer/refer.am: Improve clean behavior, deleting YACC/
      Bison-generated files _only_ from an out-of-source build tree.
      Because they are shipped in the distribution archive, only the
      "maintainer-clean" target should remove them from the source tree.
      Add new macros `GROFF_{EQN,PIC,REFER}_YACC_FILES` to track these
      artifacts.  Redefine `MAINTAINERCLEANFILES` in terms of these new
      macros.  Add `mostlyclean-{eqn,pic,refer}` targets to perform the
      cleaning.  Add these new targets as dependencies of
      `mostlyclean-local`.

    With this commit, the only files left behind after a command sequence
    like this...

    rm -r build
    mkdir build
    cd build
    ../configure
    make
    make clean

    ...are a bunch of ".dirstamp" and/or ".Po" files, which are GNU
    Automake's business to deal with.

With `MAINTAINER_MODE`, we might be able to make the foregoing even more
scrupulous.

> In the spirit of not relying on pregenerated artifact, Guix does want
> this flag.

Understood.  I think Colin Watson has the groff packages for Debian
doing the same thing already.

> On 2026-07-21 at 00:35-05:00, G. Branden Robinson wrote:
> > At 2026-07-21T14:07:10+0900, Nguy=E1=BB=85n Gia Phong wrote:
> > > How is this version string constructed?
> >
> > README:
> >     The version number is given in the file ".tarball-version" if
> >     you are building from a distribution archive; otherwise,
> >     building from its Git repository stores it in the file
> >     ".version".
> >
> > If you're doing an out-of-tree build, then the presence of
> > ".version" in your Git working copy can confuse a human
>=20
> I'm speaking for the automated build pipeline here.  On Guix, if a
> package is built from a Git checkout, a fresh clone would be made,
> then the .git directory shall be removed, hence the following won't
> work.

The .version file is not placed in the ".git" directory, but the root of
the build tree, wherever that is.  I could have been clearer; my usual
build tree happens to be a _sub_directory of my working copy.

> I've resulted to writing to .tarball-version instead and the build and
> tests succeeded.  Please let me know if this has any unintended
> effect.

None that I know of, but I'm nervous about the practice.  If your build
=66rom the repository is failing to properly populate ".version", I'm
strongly interested to know the failure mode.

> On 2026-07-21 at 00:35-05:00, G. Branden Robinson wrote:
> > At 2026-07-21T14:07:10+0900, Nguy=E1=BB=85n Gia Phong wrote:
> > There is no rc2 tarball; I haven't published one.  If the issues
> > Alexis found are the only ones that came up, my next distribution
> > archive release will be 1.25.0 final.
>=20
> Sorry for being unclear, I meant to ask for you to publish the rc2
> so distros will know the 1.25.0 tarball (which will differ only
> in the version string) will work.  It does not matter now for Guix at
> least because we can switch to building from the Git checkout.

The rc1 distribution archive _does_ work in some scenarios; I know
because I tested it myself.

Admittedly, I had an existing groff installation in my build
environment, so the build found the "wrong" soelim(1)[1] when generating
the man pages, and I also had ImageMagick installed, so any spurious
rebuild of "line-layout.png" succeeded.

Alexis's report prompted me to test a build in a more slimmed-down
environment, which is how I tested the fixes I pushed.

Regards,
Branden

[1] Any "soelim" should work, even one from AT&T troff.  Unless you're
    cross-compiling groff, in which case you must define the Make macro
    `SOELIMBIN` to point to a soelim(1) that the host can run.  However,
    there might be unsolved problems with cross-compiling groff; I
    haven't attempted it myself and, as far as I can recall I've never
    seen a report from anyone who did.

--t76nxtbzijlx7rsj
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAABCAAdFiEEh3PWHWjjDgcrENwa0Z6cfXEmbc4FAmpfGO4ACgkQ0Z6cfXEm
bc4W6g/+O6j7UDKRedDO63S3qSHiKmu68O6hqXYXeO/RByIzKWF7zht7YPz0+RGr
u+bwJ3aOBm0gZ47lVD6J5nG+dc+ojk6sbFrmixTwXTiUhDO+AW+UsXTI5ra57oq1
YOvW3uFJn9vn6dn0DSd6hvasafWbm5bkTtAK75sZ40Zc4PIzdvosk3Y+FBRlfpx3
e8rkbob1tO4Yz40JaNx8pXwv4IZXjNFpAP8bisC1EikTvR8BoeJ9kLmFpXgThi3/
VC/Ds5DggyMgLnpAzUWIF8HuMz0IsO17gYC4b/TZKkzTWXaQ+Pd/djgoapYFeVc8
VWiNORklldPIrh+RS3HvmU6U2QjlyepVn7aoyTWqdpdmVd97X7H0S5Jf0XlMP6/O
iqBi+Dpbu7ORulna6g6DJ1yXUgdWjFnIG6Bwfi5H7QjNmC9/aBXQnsuesXceaoTX
CniUDJiFhYQ/dS2vywgIfHkGg+4WObhtqwH79x6pPMK4QZmtqJ4NH4VG1EcllgUL
AlHT/e2rlD9PQhpU7soIEp8UpGjmK1lZxZ5gP0gB58Sdi285gS7SPMOdDHwys87s
i9xeQXNSqeu0abPteAXwvWXhmWlXWSfrvtKqNR+fXlCJBWJljCcomdmmg3OazYKm
ABqPXjlPnWwQniyadlOOms0SfB/+M2z8/ocf0/ru/+YuEM2qJqQ=
=n/i5
-----END PGP SIGNATURE-----

--t76nxtbzijlx7rsj--