Hi Alexis and Branden,
On 2026-07-22 at 02:35-05:00, G. Branden Robinson wrote:
> groff can be (and maybe is) fairly deep in the dependency stack.
> I've given consideration to supporting a "bootstrapping profile"
> of groff that builds only what is needed to generate, say,
> man pages for terminal viewing. Not building anything in contrib/,
> or anything written in Perl, would drop groff's own build dependencies
> to something near minimal: C, C++, and their standard libraries.
Thanks, that would indeed help (6172 packages on Guix transitively
depends on groff), though it is not a major concern
as the bootstrapping variants of build tools just disable man page
generation AFAIK.
On 2026-07-22 at 02:35-05:00, G. Branden Robinson wrote:
> At 2026-07-22T14:33:33+0900, Nguyễn Gia Phong wrote:
> > which goes against the principle of building from (and thus patching)
> > the preferred form for modification,
>
> I disagree with your (or whoever's) interpretation of this principle.
>
> Copyleft requires the provision of the preferred form for modification
> _as a sufficiency condition_. It does _not_ forbid the distributor
> from including auxiliary or supplementary materials
> that they think might be of aid.
Licensing is not the sole motivation behind the software freedom
(used loosely here like the physical degree of freedom)
Guix intends to help exercise. Like Nix, we want to support
declarative package variants, e.g. groff with a certain patch
can be expressed as (with-patches groff-1.25 "foo.patch" "bar.patch").
Patching configure.ac or Makefile.am is much easier than
the generated configure and Makefile. NixOS and Guix at heart
are source-based distribution, we just have binary cache
for the majority of packages.
On 2026-07-22 at 02:35-05:00, G. Branden Robinson wrote:
> At 2026-07-22T14:33:33+0900, Nguyễn Gia Phong wrote:
> > and (2) version-controled archives are more friendly to Software
> > Heritage (content-addressed VCS archives).
> >
> > (Guix does have content-addressed file archives for tarballs, but our
> > infra is limited, and the distro-agnostic one called ERIS is still
> > under development. Neither is publicly financed in long term like
> > Software Heritage.)
>
> I'll take your word for it. This sounds like another crack at the
> long-standing problem of the "software bill of materials", originally
> pursued for license compliance (or avoidance) reasons.
Again, not motivated by licensing, but reproducibility and reusability.
If the upstream mirrors/forges is down or link rotten, we expect
(with-patches groff-1.25 "foo.patch" "bar.patch") to still be able
to fetch the _source_ of groff from Guix cache servers,
or if the particular version 1.25 is not available, from a long-term
archival site like Interet Archive or Software Heritage
On 2026-07-22 at 02:35-05:00, G. Branden Robinson wrote:
> At 2026-07-22T14:33:33+0900, Nguyễn Gia Phong wrote:
> > As for removing the .git directory, it is for the reproducibility
> > of the checkout directory, as there can be new objects not relevant
> > to the commit of interest in future clones.
>
> That seems like a tautologous statement to me. Any clone of a future
> line of development is going to have new deltas (in old-fashioned
> SCCS/RCS parlance) or content-addressable "blobs" (in Git parlance).
>
> I don't claim there isn't a good reason for scrubbing ./.git, but what
> you said was not intelligible to me.
What I meant is to have a reproducible, and thus cachable,
groff-1.25-checkout directory, hence the VCS-specific deltas
or objects cannot be included in such directory, hence
the following became a common practice. (Thanks, BTW, Alexis.)
On 2026-07-22 at 08:01+02:00, Alexis (surryhill) wrote:
> 1. sed -i '/m4_esyscmd/s/.*/${finalAttrs.version}/' configure.ac
> where ${finalAttrs.version} is the version I'd like to give groff.
> For snapshot builds nixpkgs recommends something along the lines of:
> groff-1.25.0.rc1-unstable-2026-07-22
Other distros must have something similar, for e.g. apt-source
in Debian, but of course that depends on if they prefer VCS checkouts
over dist tarballs:
On 2026-07-22 at 02:35-05:00, G. Branden Robinson wrote:
> At 2026-07-22T14:33:33+0900, Nguyễn Gia Phong wrote:
> > On 2026-07-21 at 21:48-05:00, G. Branden Robinson wrote:
> > > Ah. In that case your build is neither fish nor fowl: neither a
> > > build from a distribution archive, nor a build from a Git working
> > > copy, because there is no working copy.
> > >
> > > What is the rationale for this sort of build configuration?
> >
> > The rationals for avoiding the dist archives on Guix were discussed
> > in the following thread.
> >
> > https://yhetil.org/guix-devel/[email protected]/T
>
> Yes. I see that's quite extensive. But only from March of this year;
> unless Guix moves super-fast, the project may still be finding its
> direction in this area.
I don't see much directional search, but it's been going slowly
(as we update each package) due to the lack of human power.
On 2026-07-22 at 02:35-05:00, G. Branden Robinson wrote:
> At 2026-07-22T14:33:33+0900, Nguyễn Gia Phong wrote:
> > From the linked thread, how about hardcoding in configure.ac the
> > `build-aux/git-version-gen --fallback' version? This can be done
> > every time a new version number is added to the NEWS file.
>
> That's not a bad idea. We're down to only 2 places where a hand update
> is required, and one of those is going to be essential anyway. If I can
> fix the other case, then we'd still be no worse off.
>
> I seem to remember we fooled with `--fallback` in that 2022 groff
> thread, though, and ran into problems. Something to do with gnulib...??
Thanks, I'll look into it too.
On 2026-07-22 at 02:35-05:00, G. Branden Robinson wrote:
> Other hits for `\<GROFF_COMMAND\>` involve only logs or documentation.
>
> At present, I don't think we have a way to inject `GROFFBIN` into test
> scripts. Solving that problem would enable us to attack another item on
> my to-do list. [...]
>
> At 2026-07-22T14:33:33+0900, Nguyễn Gia Phong wrote:
> > test-groff is obviously not executable under cross-build,
>
> Well, "test-groff" _itself_ is. It's just a shell script. That fact
> might enable some cleverness, or eliminate a barrier to a
> straightforward solution. I'd likely start with making `GROFF_BIN_PATH`
> overridable--something like this?
>
> -GROFF_BIN_PATH=$builddir
> +: ${GROFF_BIN_PATH:="$builddir"}
>
> XENVIRONMENT=$srcdir/src/devices/xditview/GXditview.ad
> export XENVIRONMENT
>
> Steering that variable's nose to /usr/riscv64-unknown-elf/bin or the
> moral equivalent should solve several problems. Any command in groff,
> the project, that must find our other commands searches `GROFF_BIN_PATH`
> (if it is defined and non-empty) before `PATH`.
This sounds good to me, though with the specific case of test-groff,
I don't think it should be executed as a wrapper of GROFFBIN
as it should be for tests (or maybe an additional doc-groff name
would be more appropriate?).
Best wishes,
Phong
