Hi Phong, At 2026-07-22T18:21:10+0900, Nguyễn Gia Phong wrote: > 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.
Filed as <https://savannah.gnu.org/bugs/?68563>. > 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) "Software freedom" has a definition that is presumptively applicable to GNU projects, including groff and Guix; it is specific, not loose. https://www.gnu.org/philosophy/free-sw.en.html Even long before I became affiliated with the GNU Project as a volunteer, I found the FSF definition of Free Software highly useful, in my work for the Debian Project, for example.[1] In case it need be said--though I suspect it'll be no surprise to anyone who follows this mailing list and has seen me get into arguments with people--I don't think people should make themselves passive receptacles of "GNU doctrine". I won't tell you to use Emacs, for example. ;-) _But_, if you're going to float "software freedom" as a rationale for _excluding_ components of source releases, and make this part of your advocacy, then you are taking on the responsibility for developing a closely reasoned argument why your rationale makes sense. A "loose usage" is deeply inadequate in a social environment as conspicuously committed to a mission of software freedom--as defined above--as the GNU Project, and the FSF itself, is. I've received this advice much more often than I've offered it, but is this really an argument you _need_ to have with anyone to advance your goals? I do not even claim that the FSF definition of Free Software should be held sacrosanct; scripture is anathema to rational thought. But if you haven't prepared a well-reasoned critique of it, then I claim that you are simply not adequately prepared to support your claim of Guix's artifact aversion as constituting a better practice of "software freedom". However there is a straightforward way to present your case. > (used loosely here like the physical degree of freedom) A term no longer in vogue for describing the process of assembling a set of specific revisions of specific files is "software configuration management" (SCM). In this sense, and as you noted in terms I found a little vague, what you are advocating is an _exercise_ of software 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. That's totally fine, and, with hands waving sufficiently generally, it's not even all that novel. (I perceive a line of descent tracing back through Gentoo Linux to the decades-old BSD tradition of "make world".) The bottom line is that I am coaching you to use terminology carefully to reduce the risk of misunderstanding and alarm from people who bear the scars of battles fought and sometimes lost against those who would deprive all but a few of us of software freedom, in the FSF's sense and in your...Lagrangian-mechanical sense alike. Claims like "[the use of distribution archives as generated by GNU Automake] goes against the principle of building from (and thus patching) the preferred form for modification" are, I predict, virtually certain to provoke unhappy and unnecessary confusion and conflict. I wonder how the SFC v. Vizio case is going... Incidentally, I'm a fan of Guix's mission. When I learned of its "MES" subproject I was immensely excited. Someday, I might find the time to get involved. Please accept my thanks and encouragement for pushing the system along and making groff a part of it! > 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.) I _think_ I understand. Is this reproducible, cacheable checkout directory something you'd expect Guix to maintain itself, or ultimately something you'd like to see offered via Savannah's CGit interface? Because that doesn't sound crazy to me. "Snapshot tarballs" of any random Git commit ID proved to be an excessive support burden for groff's team. I'd like to think that, for _releases_ (possibly including release candidates), they wouldn't be. > 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: Yes. Ian Jackson and Sean Whitton (and others, I am sure) have expended much effort, and had to fight political battles with long-entrenched interests within the Debian Project ("delegates", that community's equivalent of peerage and gentry), to make headway in this area. > 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: > > > > 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. I know them feels. :-| > 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. As noted above, filed as <https://savannah.gnu.org/bugs/?68563>. > 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?). I'm starting to wonder if my introduction of `GROFF_COMMAND` wasn't simply an error. Maybe `GROFF_BIN_PATH` is a sufficient tool for achieving the objective I had in mind for `GROFF_COMMAND`. If it isn't, we need to _document_ how `GROFF_BIN_PATH` (and, at build time only, `GROFFBIN`, `PDFMOMBIN`, and [of late] `SOELIMBIN`), are deficient, so that people know when and why they need these variables. It would be helpful if someone would simply try a cross-compiling build of groff, maybe after the 1.25.0 release, and report their findings to <https://savannah.gnu.org/bugs/?68564>. Someday I mean to get around to it myself, but concurrent effort might get this goal achieved faster. ;-) Regards, Branden [1] I'm on public record as finding the "Invariant Section" and "Cover Texts" of the GNU FDL as anything _but_ highly useful, and argued openly with Richard Stallman over these aspects of that license, which I do not endorse when it bears those "options". I try to do my own thinking, and encourage everyone else to do likewise. I'll take this opportunity to share one of my favorite quotations, which I think should be framed and mounted on the wall anywhere "tech bros", "thought leaders", or "SABDFLs" are in evidence. "If some human mind created something then your human mind can understand it. You should always assume that, because if you assume it, it throws away all the doubts that are otherwise going to bother you, and it's going to free you to just concentrate on 'what am I seeing, how is it working, what should I do about it, what am I trying to learn from this'. Never, ever think that you're not smart enough; that's all nonsense." -- Robert P. Colwell
signature.asc
Description: PGP signature
