Re: [Groff] man file character encoding.

[Colin Watson]

On Thu, Sep 26, 2013 at 06:50:38AM +0200, Werner LEMBERG wrote:
> Hello Erwin!
> > How can this be fixed?
> 
> Assuming that the problem is caused by `-p', a possible solution is to
> not use this man option or environment variable and add option `-t' to
> nroff in `/etc/man.conf'.

Or use man-db instead, which is much smarter about character encodings
and handles your situation out of the box with no configuration
required; I just tested it to confirm this.

With all due respect to Federico (we're co-workers these days, as chance
would have it!), I'm afraid that the other man package simply doesn't
have enough encoding support to do this right in general, and most major
GNU/Linux distributions have switched away from it at this point because
of this.

Cheers,

-- 
Colin Watson   [cjwat...@debian.org]

Re: [Groff] man file character encoding.

[Colin Watson]

On Thu, Sep 26, 2013 at 05:55:52PM -0400, Federico Lucifredi wrote:
> On Sep 26, 2013, at 4:32 AM, Colin Watson  wrote:
> > Or use man-db instead, which is much smarter about character encodings
> > and handles your situation out of the box with no configuration
> > required; I just tested it to confirm this.
> 
> Since both pagers use troff in the back-end, this is just a matter of
> making the correct use of it.  Let me check if I am doing something
> funky upstream, with Werner's information it should be relatively
> simple.

Well, I did the work in man-db; starting from a relatively similar
baseline it took me years to get it up to a point I considered
acceptable encoding handling, and it was my main non-work project for
much of that time.  Admittedly most of that was before preconv existed
and before groff gained proper Unicode support upstream, which does
help, but only up to a point.

Of course I don't want to discourage you from improving man similarly,
but I don't think you should be under the false impression that it's a
simple problem when you're still at the point where users often have to
manually edit man.conf to make it do the right thing even for
single-encoding collections, and there's no support at all for
mixed-encoding collections, which is an important feature for
distributions.  man is still very much in a world where the user's
encoding is expected to match the encoding of all the manual pages they
want to read, which has not been a safe assumption for many years now.

One important element, although by no means the whole problem, is that
most manual pages do not have a coding tag, and a considerable amount of
automatic detection is necessary to do a good job in practice.
Obviously we can't autodetect all encodings, but with knowledge of the
language - which man generally has - you can usually reduce the likely
options to UTF-8 and a single legacy encoding for any given language,
and it is normally possible to tell the difference between those given a
large enough amount of text.  This is why I wrote manconv, and what much
of man-db/lib/encodings.c is for.  Even after you've done that, getting
exactly the right sequence of filters is quite a delicate matter.

(And, if you're going to improve encoding handling, you should arguably
start by throwing catgets in the bin and switching to gettext, so that
your translated messages work properly.  catgets is just not fit for
purpose in a world with more than one possible encoding for a given
language, and this has been the source of real-world bugs in man that
have gone unaddressed for a long time.  Replacing catgets with gettext
was one of the first things I did when I took over man-db back in 2001.
According to https://bugs.gentoo.org/show_bug.cgi?id=93664 you've been
saying that you're going to address the message translation problem
since at least 2005; killing off catgets is the correct way to do that.)

Maybe it's time to consolidate efforts rather than spending what's
likely to be a lot of effort catching up.  I've tried to ensure that
man-db has all the important features of man, assisted particularly by
bug reports from Gentoo and Fedora users switching to man-db; are there
any places where you still feel it's objectively lacking, and if so
would you be willing to help me out upstream to fill the gaps?  The only
substantial missing feature I'm aware of is man2html, which I kind of
feel is better off as a separate package anyway; indeed "groff -Thtml"
or w3mman2html.cgi arguably do better jobs nowadays.

Cheers,

-- 
Colin Watson   [cjwat...@debian.org]

Re: [Groff] man file character encoding.

[Colin Watson]

On Thu, Sep 26, 2013 at 09:58:04PM +0200, Erwin Waterlander wrote:
> I'm curious to know how man-db determines the encoding of the man
> page. I cannot find that information. Would you like to explain how
> man-db does the encoding detecion?

Certainly.  man-db contains a table of the typical legacy encodings for
each of a number of known languages (I'm happy to add to those, but
since new translation efforts tend to start with UTF-8 these days, it's
a closed set and I haven't had to extend it since 2008 when I synced up
with Fedora).  There is generally only one of these.  UTF-8 is a strict
enough encoding that for reasonable volumes of text it is usually
possible to distinguish automatically between it and a legacy encoding,
simply by trying to decode as UTF-8 and falling back to the legacy
encoding if that fails.  manconv does this job; it is more or less like
iconv except that it can take a priority order of possible input
encodings.

There are cases where this system fails, and in such cases you can store
manual pages in directories with an explicit encoding tag attached (e.g.
"/usr/share/man/man1/_."), or put an explicit
Emacs-style coding tag at the top of the file.  In practice this is
rarely necessary.

> The reason I work with Federico's man is that I often work on Cygwin
> when I don't have Linux at hand. Cygwin does not have man-db
> available. Soon I get a Russian translation of my program
> (dos2unix), that made this problem actual again for me. Three years
> ago I saw this problem coming. At that time I tested also on Fedora
> 12, which was still using Federico's man. I didn't notice that
> Fedora changed to man-db in the meantime.

Ah, yes.  I corresponded at one point with somebody who might be
interested in porting man-db to Cygwin, but it never came to anything.
I would be ecstatic if somebody could help with such a port, as I don't
use Windows myself.

I use Gnulib extensively, which deals with a lot of portability
problems, but not everything.  The main effort will be in porting
libpipeline to deal with Windows-style process creation and supervision;
after that I expect that it will just be a matter of various minor fixes
for Unix-specific assumptions I've made.  You don't have to come with a
complete patch; I'd be willing to accept incremental changes that make
the job easier for the next person, or even "this general pattern of
things you're doing is Unix-specific; you need to use this pattern
instead to be portable to Cygwin".

Cheers,

-- 
Colin Watson   [cjwat...@debian.org]

Re: [Groff] Where do we go from here?

[Colin Watson]

On Fri, Nov 15, 2013 at 08:35:02AM +0100, Werner LEMBERG wrote:
> Well, groff is mirrored since years as a Bazaar project at
> 
>   https://code.launchpad.net/~vcs-imports/groff
> 
> However, I've never checked how well they did the CVS import.
> 
> I was never happy with bzr since it always was (and still is) very
> slow.  I much prefer git.  Maybe a forthcoming maintainer has
> different preferences...

I'm happy with the quality of the bzr import we did, and long preferred
its UI, but even I have begun moving my projects to git in the
acknowledgement that it's won the DVCS wars; I wouldn't advocate groff
switching to bzr at this point.  I expect I'd switch the Debian
packaging over to git once there's an upstream tree to base it on.

In passing, I might be able to help with the automake work, maybe; I've
converted several projects to automake and gnulib, and that's how I tend
to build new projects these days.  groff is older and more complex than
most, but probably not intractably so.

I'd like to join the chorus of thanks to Werner for his impeccable work
and leadership over the years.

-- 
Colin Watson   [cjwat...@debian.org]

Re: [Groff] Where do we go from here?

[Colin Watson]

On Wed, Dec 11, 2013 at 11:21:06AM -0500, Eric S. Raymond wrote:
> Colin Watson :
> > I'm happy with the quality of the bzr import we did, and long preferred
> > its UI, but even I have begun moving my projects to git in the
> > acknowledgement that it's won the DVCS wars;
> 
> I myself prefer Mercurial's UI to git, but have reached the same rueful 
> conclusion.  One major point in git's favor is the fast-import stream
> format - without it, reposurgeon would never have come to be and the
> groff conversion would have been *considerably* more difficult.

Quite so, it's wonderful.  (Although it's been picked up by other
projects; I've used it for various imports into bzr.)

> You say you're happy with bzr's UI.  Does it not seem to you that bzr is
> deeply confused about what its unit of work is?  I tried learning bzr
> in order to work on Emacs and found that the distinction between repos
> and detached branches made my head hurt a lot.  

I've heard similar from others, but this has never bothered me (although
the colocated branch model used by git is certainly *convenient* in many
cases).  I guess it fits my brain.  It's probably several years too late
to have this debate, though. :-)

-- 
Colin Watson   [cjwat...@debian.org]

Re: [Groff] Where do we go from here?

[Colin Watson]

On Wed, Dec 11, 2013 at 01:51:49PM +, Colin Watson wrote:
> I expect I'd switch the Debian packaging over to git once there's an
> upstream tree to base it on.

Money, putting where mouth is, etc.:

  http://anonscm.debian.org/gitweb/?p=users/cjwatson/groff.git

The recent history is probably slightly hard to follow, at least in the
shortlog, since I took the opportunity to migrate to the "git-dpm" tool
to help me manage the Debian patch stack in a more git-idiomatic way.
It should get clearer as time goes on.

-- 
Colin Watson   [cjwat...@debian.org]

[Groff] [PATCH] '+' isn't a regex metacharacter in sed by default

[Colin Watson]

This is based on an old patch from Fumitoshi UKAI  in
the Debian groff packaging, cleaned up and extended to cover all fonts
by me.
---
 font/devascii/Makefile.sub  | 4 ++--
 font/devcp1047/Makefile.sub | 4 ++--
 font/devhtml/Makefile.sub   | 4 ++--
 font/devlatin1/Makefile.sub | 4 ++--
 font/devutf8/Makefile.sub   | 4 ++--
 5 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/font/devascii/Makefile.sub b/font/devascii/Makefile.sub
index 43b2b46..0fa2e77 100644
--- a/font/devascii/Makefile.sub
+++ b/font/devascii/Makefile.sub
@@ -12,8 +12,8 @@ $(FONTS): R.proto
@-rm -f $@
@(charwidth=`expr $(RES) / $(CPI)` ; \
 sed -e "s/^name [A-Z]*$$/name $@/" \
--e "s/^\\([^   ]*\\)   [0-9]+  /\\1$$charwidth /" \
--e "s/^spacewidth [0-9]+$$/spacewidth $$charwidth/" \
+-e "s/^\\([^   ]*\\)   [0-9][0-9]* /\\1$$charwidth 
/" \
+-e "s/^spacewidth [0-9][0-9]*$$/spacewidth $$charwidth/" \
 -e "s/^internalname .*$$/internalname $@/" \
 -e "/^internalname/s/BI/3/" \
 -e "/^internalname/s/B/2/" \
diff --git a/font/devcp1047/Makefile.sub b/font/devcp1047/Makefile.sub
index 4c2d1db..5aa6cff 100644
--- a/font/devcp1047/Makefile.sub
+++ b/font/devcp1047/Makefile.sub
@@ -12,8 +12,8 @@ $(FONTS): R.proto
@-rm -f $@
@(charwidth=`expr $(RES) / $(CPI)` ; \
 sed -e "s/^name [A-Z]*$$/name $@/" \
--e "s/^\\([^   ]*\\)   [0-9]+  /\\1$$charwidth /" \
--e "s/^spacewidth [0-9]+$$/spacewidth $$charwidth/" \
+-e "s/^\\([^   ]*\\)   [0-9][0-9]* /\\1$$charwidth 
/" \
+-e "s/^spacewidth [0-9][0-9]*$$/spacewidth $$charwidth/" \
 -e "s/^internalname .*$$/internalname $@/" \
 -e "/^internalname/s/BI/3/" \
 -e "/^internalname/s/B/2/" \
diff --git a/font/devhtml/Makefile.sub b/font/devhtml/Makefile.sub
index c1e5525..36fcf77 100644
--- a/font/devhtml/Makefile.sub
+++ b/font/devhtml/Makefile.sub
@@ -13,8 +13,8 @@ $(FONTS): R.proto
@-rm -f $@
@(charwidth=`expr $(RES) / $(CPI)` ; \
 sed -e "s/^name [A-Z]*$$/name $@/" \
--e "s/^\\([^   ]*\\)   [0-9]+  /\\1$$charwidth /" \
--e "s/^spacewidth [0-9]+$$/spacewidth $$charwidth/" \
+-e "s/^\\([^   ]*\\)   [0-9][0-9]* /\\1$$charwidth 
/" \
+-e "s/^spacewidth [0-9][0-9]*$$/spacewidth $$charwidth/" \
 -e "s/^internalname .*$$/internalname $@/" \
 -e "/^internalname/s/CR/4/" \
 -e "/^internalname/s/BI/3/" \
diff --git a/font/devlatin1/Makefile.sub b/font/devlatin1/Makefile.sub
index 127e02c..b261f57 100644
--- a/font/devlatin1/Makefile.sub
+++ b/font/devlatin1/Makefile.sub
@@ -12,8 +12,8 @@ $(FONTS): R.proto
@-rm -f $@
@(charwidth=`expr $(RES) / $(CPI)` ; \
 sed -e "s/^name [A-Z]*$$/name $@/" \
--e "s/^\\([^   ]*\\)   [0-9]+  /\\1$$charwidth /" \
--e "s/^spacewidth [0-9]+$$/spacewidth $$charwidth/" \
+-e "s/^\\([^   ]*\\)   [0-9][0-9]* /\\1$$charwidth 
/" \
+-e "s/^spacewidth [0-9][0-9]*$$/spacewidth $$charwidth/" \
 -e "s/^internalname .*$$/internalname $@/" \
 -e "/^internalname/s/BI/3/" \
 -e "/^internalname/s/B/2/" \
diff --git a/font/devutf8/Makefile.sub b/font/devutf8/Makefile.sub
index 221bd3f..1047bdc 100644
--- a/font/devutf8/Makefile.sub
+++ b/font/devutf8/Makefile.sub
@@ -12,8 +12,8 @@ $(FONTS): R.proto
@-rm -f $@
@(charwidth=`expr $(RES) / $(CPI)` ; \
 sed -e "s/^name [A-Z]*$$/name $@/" \
--e "s/^\\([^   ]*\\)   [0-9]+  /\\1$$charwidth /" \
--e "s/^spacewidth [0-9]+$$/spacewidth $$charwidth/" \
+-e "s/^\\([^   ]*\\)   [0-9][0-9]* /\\1$$charwidth 
/" \
+-e "s/^spacewidth [0-9][0-9]*$$/spacewidth $$charwidth/" \
 -e "s/^internalname .*$$/internalname $@/" \
 -e "/^internalname/s/BI/3/" \
 -e "/^internalname/s/B/2/" \
-- 
1.8.5.2

[Groff] [PATCH] Use bash for several contrib scripts

[Colin Watson]

---
 ChangeLog| 7 +++
 contrib/eqn2graph/eqn2graph.sh   | 2 +-
 contrib/grap2graph/grap2graph.sh | 2 +-
 contrib/pic2graph/pic2graph.sh   | 2 +-
 4 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index abf7534..33c5175 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2014-01-02  Colin Watson  
+
+   * contrib/eqn2graph/eqn2graph.sh: Use bash rather than sh; $RANDOM
+   is a bashism.
+   * contrib/grap2graph/grap2graph.sh: Likewise.
+   * contrib/pic2graph/pic2graph.sh: Likewise.
+
 2013-12-23  Bernd Warken  
 
groff/src/roff/groff/groff.cpp: add groff option `-G' to the
diff --git a/contrib/eqn2graph/eqn2graph.sh b/contrib/eqn2graph/eqn2graph.sh
index ee7cc5f..fb6f7f5 100644
--- a/contrib/eqn2graph/eqn2graph.sh
+++ b/contrib/eqn2graph/eqn2graph.sh
@@ -1,4 +1,4 @@
-#! /bin/sh
+#! /bin/bash
 #
 # eqn2graph -- compile EQN equation descriptions to bitmap images
 #
diff --git a/contrib/grap2graph/grap2graph.sh b/contrib/grap2graph/grap2graph.sh
index 58544e1..721c2b0 100644
--- a/contrib/grap2graph/grap2graph.sh
+++ b/contrib/grap2graph/grap2graph.sh
@@ -1,4 +1,4 @@
-#! /bin/sh
+#! /bin/bash
 #
 # grap2graph -- compile graph description descriptions to bitmap images
 #
diff --git a/contrib/pic2graph/pic2graph.sh b/contrib/pic2graph/pic2graph.sh
index 72c5477..c4a7781 100644
--- a/contrib/pic2graph/pic2graph.sh
+++ b/contrib/pic2graph/pic2graph.sh
@@ -1,4 +1,4 @@
-#! /bin/sh
+#! /bin/bash
 #
 # pic2graph -- compile PIC image descriptions to bitmap images
 #
-- 
1.8.5.2

[Groff] [PATCH] Appease "groff -wmac" when using eqn or pic

[Colin Watson]

* src/preproc/eqn/main.cpp: Define EQ and EN if they are not already
defined, to appease "groff -wmac".
* src/preproc/pic/main.cpp: Likewise for PS and PE.

Fixes: http://bugs.debian.org/495713
---
 ChangeLog| 8 
 src/preproc/eqn/main.cpp | 2 ++
 src/preproc/pic/main.cpp | 4 
 3 files changed, 14 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index abf7534..2953608 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2014-01-02  Colin Watson  
+
+   * src/preproc/eqn/main.cpp: Define EQ and EN if they are not already
+   defined, to appease "groff -wmac".
+   * src/preproc/pic/main.cpp: Likewise for PS and PE.
+
+   Fixes: http://bugs.debian.org/495713
+
 2013-12-23  Bernd Warken  
 
groff/src/roff/groff/groff.cpp: add groff option `-G' to the
diff --git a/src/preproc/eqn/main.cpp b/src/preproc/eqn/main.cpp
index 167fb4e..79b8565 100644
--- a/src/preproc/eqn/main.cpp
+++ b/src/preproc/eqn/main.cpp
@@ -374,6 +374,8 @@ int main(int argc, char **argv)
 }
   init_table(device);
   init_char_table();
+  printf(".if !dEQ .ds EQ\n"
+".if !dEN .ds EN\n");
   if (output_format == troff) {
 printf(".if !'\\*(.T'%s' "
   ".if !'\\*(.T'html' "// the html device uses `-Tps' to render
diff --git a/src/preproc/pic/main.cpp b/src/preproc/pic/main.cpp
index f242da0..f4d0fbe 100644
--- a/src/preproc/pic/main.cpp
+++ b/src/preproc/pic/main.cpp
@@ -616,7 +616,11 @@ int main(int argc, char **argv)
 out = make_fig_output();
   else
 #endif
+  {
 out = make_troff_output();
+printf(".if !dPS .ds PS\n"
+  ".if !dPE .ds PE\n");
+  }
 #ifdef FIG_SUPPORT
   if (whole_file_flag) {
 if (optind >= argc)
-- 
1.8.5.2

Re: [Groff] [PATCH] '+' isn't a regex metacharacter in sed by default

[Colin Watson]

On Thu, Jan 02, 2014 at 02:52:42PM +0100, Werner LEMBERG wrote:
> You have now write access :-)

Thanks!

> Please submit, together with a proper ChangeLog entry.

Yes, I realised I'd forgotten ChangeLog shortly after sending.  Done.

-- 
Colin Watson   [cjwat...@debian.org]

Re: [Groff] [PATCH] Use bash for several contrib scripts

[Colin Watson]

On Thu, Jan 02, 2014 at 03:03:48PM +0100, Steffen Nurpmeso wrote:
> Colin Watson  wrote:
>  |+2014-01-02  Colin Watson  
>  |+
>  |+ * contrib/eqn2graph/eqn2graph.sh: Use bash rather than sh; $RANDOM
>  |+ is a bashism.
>  |+ * contrib/grap2graph/grap2graph.sh: Likewise.
>  |+ * contrib/pic2graph/pic2graph.sh: Likewise.
> 
> I'd really rather do something like the below instead.

This will amount to $$-$$ on shells that don't support $RANDOM, which
seems rather pointless.  Perhaps just:

  tmp=$d/eqn2graph$${$RANDOM:+-$RANDOM}

then?

> Btw.: interesting that the auto-generated files like `configure'
> simply use $RANDOM, whereas the config.guess and such (i *never*
> used any auto*) do.  Imho it is a bug that the generated scripts
> use /bin/sh but are not compatible to a real /bin/sh.

Good point about configure.

I suppose it isn't a fatal incompatibility, since $RANDOM just expands
to the empty string on other shells and mkdir will probably fail; maybe
we could just leave it alone since the above is really no better than
that.  TBH I think I was trying to placate tools that check for
bashisms.

-- 
Colin Watson   [cjwat...@debian.org]

Re: [Groff] removing RUNOFF man page

[Colin Watson]

On Sun, Jan 05, 2014 at 12:35:25PM +0100, Bernd Warken wrote:
> > Von: "Ralph Corderoy" 
> > It also changes the licence from >=GPLv3 to >=GPLv2 on a couple of files
> > that remain;  they're copyright FSF.  COPYING at the top level is v3.  I
> > don't know if this is an issue, just raising it for those that do.
> 
> GPL2 is logical, GPL3 is bullshit from `above'.  Debian succesfully fought
> against GPL3 for years.  Everything using GPL3 and FDL became non-free and
> was hidden in normal Debian publications.

No, this statement about Debian's behaviour is simply untrue and always
has been.

Debian did determine that GFDL-licensed works containing unmodifiable
sections are non-free per its guidelines
(http://www.debian.org/vote/2006/vote_001 - note that this is
confusingly laid out, and the winning option was Amendment A).

Debian has never had any widespread objections to GPLv3, and has
certainly never considered it non-free.  Packages using GPLv3 have been
in Debian main for years.

Of course you are entitled to have whatever opinions you like about the
GPLv3 - but please refrain from spreading untruths about Debian in the
process.

-- 
Colin Watson   [cjwat...@debian.org]

Re: [Groff] removing RUNOFF man page

[Colin Watson]

On Sun, Jan 05, 2014 at 06:06:25PM +0100, Bernd Warken wrote:
> > Von: "Colin Watson" 
> > No, this statement about Debian's behaviour is simply untrue and always
> > has been.
> 
> That's a lie: http://archive09.linux.com/feature/51576?theme=print

Some individuals within the Debian project expressed concerns about it
during the consultation process, before the licence was released, sure.
That was the point of the consultation process.  But here's the log of
the bug that caused GPLv3 to be added to common-licenses in base-files
in 2007, less than two months after GPLv3 was released, which indicates
that it had already been accepted into the archive by the group
("ftpmaster") that makes routine determinations about whether licences
meet the DFSG:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=431176

-- 
Colin Watson   [cjwat...@debian.org]

Re: [Groff] man pages (tangential to Future Redux)

[Colin Watson]

On Fri, Feb 28, 2014 at 07:53:34PM +0100, Ingo Schwarze wrote:
> Eric S. Raymond wrote on Fri, Feb 28, 2014 at 12:15:35PM -0500:
> > 2. Some time ago I added to Linux man(1) the capability to recognize
> > HTML pages in the man hierachy and kick them over to the user's Web
> > browser.  All Linux and *BSD distributions now ship this code.
> 
> I'm not quite sure what you mean by Linux man(1); i failed to find
> your name here:  http://git.savannah.gnu.org/cgit/man-db.git/log/

Right.  I implemented Eric's $BROWSER spec in 2001, but I think that's
the only idea of his in man-db at the moment.  The change Eric's
referring to is in the other Linux man package as of version 1.6; but as
you say the BSDs use their own things, and as of earlier this year the
only major Linux distributions I could find using man rather than man-db
were Mageia and Slackware.  I may have missed a few, but "all Linux
distributions" is certainly not close to accurate.

Regardless of my feelings on whether it should be used by default, I'd
like to at least have this as an option in man-db on general feature
parity grounds.  Eric, do you want me to put together a patch at some
point, or will you?

> > Where I want us to be is that when users call man(1) the normal
> > behavior is to render through the browser.
> 
> That is most definitely not going to happen in OpenBSD, and i would
> be very surprised if any other BSD would follow.  Not all environments
> are running X, not all environments are fit for running a browser,
> but you want manuals everywhere.  And i doubt that any people even
> *want* to see manuals in a browser.

I think it makes more sense to make sure man:foo and similar URLs do
sensible things in all the browsers people use.  While there are
exceptions, if you want to see something in a browser, it's usually more
natural to start from that browser's URL bar.

> even though it is easily feasible with current tools, just have man(1)
> write to a tempfile and call the browser on that, using the usual
> man.conf(5) or manpath(1) or whatever mechanisms.

That's indeed basically what "man -H" does in man-db.  There are
annoyances with the lifetime of rendered image files, though, and it's
not clear how to solve that (https://bugs.debian.org/335411).  The same
would presumably hold for Eric's proposal.

-- 
Colin Watson   [cjwat...@debian.org]

Re: [Groff] Mission statement

[Colin Watson]

On Fri, Mar 14, 2014 at 11:26:46PM -0400, Eric S. Raymond wrote:
> Peter Schaffter :
> > The build system
> > 
> > - streamline the build system to improve flexibility and portability
> 
> Nothing you can ever do with autotools will ever be describable as 
> 'streamlining'.  It's a horrible, bloated, crufty mess that leads to
> horrible, bloated, crufty builds.
> 
> If I were running the project I would toss out autotools in a heartbeat
> and replace it with something cleaner and more modern.  My top choice
> would be scons.

scons is closer to a construction kit for build systems than a build
system, which makes it a pain to work with in any regular way from a
packaging perspective.  In particular I've never seen a scons-using
project that has managed to get cross-building working right; whereas
groff cross-compiles relatively easily out of the box today (you just
have to do a separate native build pass so that it can build its own
documentation).  I'd hate to see groff switching to something
significantly less battle-hardened.

-- 
Colin Watson   [cjwat...@debian.org]

Re: [Groff] new file DISTRIBUTIONS

[Colin Watson]

On Thu, Jul 03, 2014 at 05:56:13PM +0100, Keith Marshall wrote:
> On 03/07/14 15:50, Bernd Warken wrote:
> > I propose to start a new file DISTRIBUTIONS in the top directory.
> > This file will report the maintainers of known distributions.
> > 
> > ### DISTRIBUTIONS
> > OpenBSD - Ingo Schwarze 
> > LinuxMint Debian - Keith Marshall 
> 
> I am NOT the maintainer of the LinuxMint distribution; other than being
> a USER of their Debian Edition, I am, in no way, even associated with
> LinuxMint!  For their Debian Edition, I guess ...
> 
> > Debian - Colin Watson ".

> ... is the EFFECTIVE maintainer, since the LinuxMint distributors will
> pull packages from the Debian repositories.  Colin may also be the
> effective maintainer for the Ubuntu based LinuxMint variants.

I guess so.  They don't appear to modify it versus Ubuntu, and I'm the
effective maintainer for Ubuntu as well.  Maybe "Debian/Ubuntu and
descendants" or something.

-- 
Colin Watson   [cjwat...@debian.org]

[Groff] Reproducible dates in HTML/PDF/PS output files?

[Colin Watson]

Hi,

Various Debian developers are working on a long-term project to ensure
that our packages can be built in a byte-for-byte reproducible way.
This makes it easier to do interesting things like defending against
people attempting to attack free software developers' systems; for
example the Tor browser has reproducible builds, allowing people to
verify that the build machine wasn't compromised.  Our project page is
here, and I gather that some other distributions are working on similar
projects:

  https://wiki.debian.org/ReproducibleBuilds

There are all sorts of pieces to this, but one of them is either
eliminating timestamps from output files where they aren't all that
important, or making sure that they're consistent when a package is
built more than once.  As a general principle, the time when a package
was built is not information we believe should be recorded in that
package, although modification times of source files may be reasonable
things to use (for instance, we may well end up building packages under
faketime with the starting point set to the timestamp in the most recent
Debian changelog entry).  We would prefer to improve upstream build
systems to make them produce more reproducible results out of the box
where we can, since that benefits everyone rather than just Debian.

groff is a relatively small piece of this puzzle, since it's typically
not very security-sensitive, but it would still be good to make it
reproducible since it's in many distributions' base systems.  The
current sticking point I see is that grohtml, gropdf, and grops all
embed timestamps in their output files.  I have two suggestions on how
this could be improved, and would welcome feedback on which (if any) I
should submit patches for.

 1) Emit the timestamp of the source file rather than the current time
in these devices.  The time when the source file was modified is
typically rather more interesting than the time when the document
processing toolchain was run.  (Possible downside: do we have to
keep track of the maximum timestamp of any included file?)

 2) Add an option or environment variable or something to suppress the
inclusion of timestamps.  For bonus points, set this when building
groff's own documentation.

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Re: [Groff] Reproducible dates in HTML/PDF/PS output files?

[Colin Watson]

On Wed, Aug 27, 2014 at 08:28:53AM +0200, Werner LEMBERG wrote:
> Colin Watson wrote:
> >  2) Add an option or environment variable or something to suppress
> > the inclusion of timestamps.
> 
> This is the way to go, I guess.
> 
> > For bonus points, set this when building groff's own
> > documentation.
> 
> Hmm.  I rather suggest to provide this as a configuration option so
> that builds that need this functionality can access it.

OK.  If it's an environment variable then this comes for free by just
setting that variable.  How about the attached patch?

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]
>From d4f2151d6964a8d73f873f3e1f46b71af98d9eee Mon Sep 17 00:00:00 2001
From: Colin Watson 
Date: Wed, 27 Aug 2014 09:06:26 +0100
Subject: [PATCH] Honour GROFF_NO_TIMESTAMPS, for more reproducible builds

* src/devices/grohtml/post-html.cpp, src/devices/gropdf/gropdf.pl,
src/devices/grops/ps.cpp: Don't emit creation timestamp if the
environment variable `GROFF_NO_TIMESTAMPS' is set.
* src/devices/grohtml/grohtml.man, src/devices/gropdf/gropdf.man,
src/devices/grops/grops.man: Updated.
---
 ChangeLog |  8 +++
 src/devices/grohtml/grohtml.man   |  6 ++
 src/devices/grohtml/post-html.cpp | 45 ++-
 src/devices/gropdf/gropdf.man |  6 ++
 src/devices/gropdf/gropdf.pl  | 16 --
 src/devices/grops/grops.man   |  6 ++
 src/devices/grops/ps.cpp  |  3 ++-
 7 files changed, 63 insertions(+), 27 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 0812769..8b956c9 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2014-08-27  Colin Watson  
+
+	* src/devices/grohtml/post-html.cpp, src/devices/gropdf/gropdf.pl,
+	src/devices/grops/ps.cpp: Don't emit creation timestamp if the
+	environment variable `GROFF_NO_TIMESTAMPS' is set.  *
+	src/devices/grohtml/grohtml.man, src/devices/gropdf/gropdf.man,
+	src/devices/grops/grops.man: Updated.
+
 2014-08-20  Bernd Warken  
 
 	* groff.7 (man/groff.man): Add further preprocessor regions.
diff --git a/src/devices/grohtml/grohtml.man b/src/devices/grohtml/grohtml.man
index 02209e2..f20883d 100644
--- a/src/devices/grohtml/grohtml.man
+++ b/src/devices/grohtml/grohtml.man
@@ -370,6 +370,12 @@ and
 for more details.
 .
 .
+.TP
+.SM
+.B GROFF_NO_TIMESTAMPS
+If set, do not include the creation timestamp in the output file.
+.
+.
 .SH BUGS
 .B Grohtml
 has been completely redesigned and rewritten.
diff --git a/src/devices/grohtml/post-html.cpp b/src/devices/grohtml/post-html.cpp
index f4656a0..60fddbc 100644
--- a/src/devices/grohtml/post-html.cpp
+++ b/src/devices/grohtml/post-html.cpp
@@ -36,6 +36,7 @@ along with this program. If not, see <http://www.gnu.org/licenses/>. */
 #include 
 #endif
 
+#include 
 #include 
 #include 
 #include 
@@ -4988,12 +4989,6 @@ void html_printer::do_file_components (void)
 
 file_list.move_next();
 if (file_list.is_new_output_file()) {
-#ifdef LONG_FOR_TIME_T
-  long t;
-#else
-  time_t t;
-#endif
-
   if (fragment_no > 1)
 	write_navigation(top, prev, next, current);
   prev = current;
@@ -5014,10 +5009,18 @@ void html_printer::do_file_components (void)
 	.put_string(Version_string)
 	.end_comment();
 
-  t = time(0);
-  html.begin_comment("CreationDate: ")
-	.put_string(ctime(&t), strlen(ctime(&t))-1)
-	.end_comment();
+  if (!getenv("GROFF_NO_TIMESTAMPS")) {
+#ifdef LONG_FOR_TIME_T
+	long t;
+#else
+	time_t t;
+#endif
+
+	t = time(0);
+	html.begin_comment("CreationDate: ")
+	  .put_string(ctime(&t), strlen(ctime(&t))-1)
+	  .end_comment();
+  }
 
   if (dialect == html4)
 	writeHeadMetaStyle();
@@ -5107,12 +5110,6 @@ void html_printer::writeHeadMetaStyle (void)
 
 html_printer::~html_printer()
 {
-#ifdef LONG_FOR_TIME_T
-  long t;
-#else
-  time_t t;
-#endif
-
   if (current_paragraph)
 current_paragraph->flush_text();
   html.end_line();
@@ -5127,10 +5124,18 @@ html_printer::~html_printer()
 .put_string(Version_string)
 .end_comment();
 
-  t = time(0);
-  html.begin_comment("CreationDate: ")
-.put_string(ctime(&t), strlen(ctime(&t))-1)
-.end_comment();
+  if (!getenv("GROFF_NO_TIMESTAMPS")) {
+#ifdef LONG_FOR_TIME_T
+long t;
+#else
+time_t t;
+#endif
+
+t = time(0);
+html.begin_comment("CreationDate: ")
+  .put_string(ctime(&t), strlen(ctime(&t))-1)
+  .end_comment();
+  }
 
   if (dialect == html4)
 writeHeadMetaStyle();
diff --git a/src/devices/gropdf/gropdf.man b/src/devices/gropdf/gropdf.man
index 426a4d0..f698104 100644
--- a/src/devices/gropdf/gropdf.man
+++ b/src/devices/gropdf/gropdf.man
@@ -977,6 +977,12 @@ and
 for more details.
 .
 .
+.TP
+.SM
+.B GROFF_NO_TIMESTAMPS
+If set, do not include the creat

Re: [Groff] Reproducible dates in HTML/PDF/PS output files?

[Colin Watson]

On Wed, Aug 27, 2014 at 09:33:46AM +0100, Ralph Corderoy wrote:
> Werner's said he's in favour of this approach.  I'd just wonder if the
> option of providing a timestamp in the environment variable would also
> be useful.

I guess I would have to wonder why having the timestamp there is very
useful.  The presenter on the topic of reproducible builds at DebConf
today offered to start a support group for people addicted to
unnecessary timestamps. :-)

-- 
Colin Watson   [cjwat...@debian.org]

Re: [Groff] configure issue

[Colin Watson]

On Thu, Sep 04, 2014 at 12:50:29PM -0400, Peter Schaffter wrote:
> I haven't built groff from source for a while.  Just tried.
> 
> ./configure: line 4400: GROFF_CXX_CHECK: command not found

Bernd's commit 9f6f7cf3b0e4d1c615f625eda7c686a483d572a6 appears to have
badly damaged configure.  Running "autoreconf -fi -I m4" fixes it
(Bernd, the need for "-I m4" is documented in INSTALL.REPO; -fi is just
my usual reflex for making sure that autoreconf does everything it needs
to do).

-- 
Colin Watson   [cjwat...@debian.org]

[Groff] [PATCH] Add support for various BSD versions

[Colin Watson]

Hi,

The attached patch is the leftover bits of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717608 that have not
yet been applied upstream (as per a git rebase).  Original submitter
CCed.

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]
>From 1450bd34d11317e3d638a7803657e6f1a1b5d424 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Tue, 23 Jul 2013 01:13:58 +0200
Subject: [PATCH] Add support for various BSD versions

---
 tmac/doc-common | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/tmac/doc-common b/tmac/doc-common
index f3553c8..eac840e 100644
--- a/tmac/doc-common
+++ b/tmac/doc-common
@@ -587,10 +587,15 @@
 .ds doc-operating-system-FreeBSD-7.1 7.1
 .ds doc-operating-system-FreeBSD-7.2 7.2
 .ds doc-operating-system-FreeBSD-7.3 7.3
+.ds doc-operating-system-FreeBSD-7.4 7.4
 .ds doc-operating-system-FreeBSD-8.0 8.0
 .ds doc-operating-system-FreeBSD-8.1 8.1
 .ds doc-operating-system-FreeBSD-8.2 8.2
+.ds doc-operating-system-FreeBSD-8.3 8.3
+.ds doc-operating-system-FreeBSD-8.4 8.4
 .ds doc-operating-system-FreeBSD-9.0 9.0
+.ds doc-operating-system-FreeBSD-9.1 9.1
+.ds doc-operating-system-FreeBSD-9.2 9.2
 .ds doc-operating-system-FreeBSD-10.010.0
 .
 .ds doc-operating-system-Darwin-8.0.0  8.0.0
@@ -653,6 +658,8 @@
 .ds doc-operating-system-DragonFly-2.10   2.10
 .ds doc-operating-system-DragonFly-2.10.1 2.10.1
 .ds doc-operating-system-DragonFly-2.11   2.11
+.ds doc-operating-system-DragonFly-2.12   2.12
+.ds doc-operating-system-DragonFly-2.13   2.13
 .ds doc-operating-system-DragonFly-3.03.0
 .ds doc-operating-system-DragonFly-3.13.1
 .ds doc-operating-system-DragonFly-3.23.2
-- 
2.1.0

Re: [Groff] release ready

[Colin Watson]

On Sat, Oct 11, 2014 at 09:13:16AM +0200, Werner LEMBERG wrote:
> I think I've now done everything to make a new release – essentially,
> it was a matter of continued comparation between the last tarball and
> the current git repository.  There are surprisingly few changes
> (expect Bernd's clean-up of copyright issues), so I don't expect large
> surprises.
> 
> After Bernd's commits to fix the IPC issue, I can do `make dist' and
> distribute it.  Before doing this, however, I want to wait a few days
> so that you can test and check whether everything's fine.  Please do so!

I tried running a test "make dist", importing that into my Debian
packaging branch, and building.  This failed because src/utils/xtotroff
was missing.  On looking back I see this in the configure output from
before "make dist":

  configure: gxditview and xtotroff won't be built

I think it would be a good idea to make sure that these directories are
present regardless of configuration.

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Re: [Groff] release ready

[Colin Watson]

On Sat, Oct 11, 2014 at 12:03:14PM +0200, Werner LEMBERG wrote:
> Colin Watson wrote:
> > I tried running a test "make dist", importing that into my Debian
> > packaging branch, and building.  This failed because
> > src/utils/xtotroff was missing.  On looking back I see this in the
> > configure output from before "make dist":
> > 
> >   configure: gxditview and xtotroff won't be built
> > 
> > I think it would be a good idea to make sure that these directories
> > are present regardless of configuration.
> 
> OK.  Can you provide a patch, please?

How about the attached?

-- 
Colin Watson   [cjwat...@debian.org]
diff --git a/ChangeLog b/ChangeLog
index 19aa0b9..5c8429a 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2014-10-15  Colin Watson  
+
+	Always distribute the parts of groff that require X11.
+
+	* Makefile.in (ALLLIBDIRS): Clone from `LIBDIRS', but include
+	src/devices/libxutil unconditionally.
+	(ALLPROGDIRS): Clone from `PROGDIRS', but include
+	src/devices/xditview and src/utils/xtotroff unconditionally.
+	(DISTDIRS): Use `ALLLIBDIRS' and `ALLPROGDIRS' rather than `LIBDIRS'
+	and `PROGDIRS'.
+
 2014-10-14  Keith Marshall  
 
 	Minor update to NEWS for pdfroff.
diff --git a/Makefile.in b/Makefile.in
index 139d7cb..4dd82ef 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -625,6 +625,11 @@ LIBDIRS=\
   src/libs/libdriver \
   src/libs/libbib \
   $(XLIBDIRS)
+ALLLIBDIRS=\
+  src/libs/libgroff \
+  src/libs/libdriver \
+  src/libs/libbib \
+  src/libs/libxutil
 CCPROGDIRS=\
   src/roff/groff \
   src/roff/troff \
@@ -660,6 +665,13 @@ PROGDIRS=\
   $(CPROGDIRS) \
   $(SHPROGDIRS) \
   $(XPROGDIRS)
+ALLPROGDIRS=\
+  $(PROGDEPDIRS) \
+  $(CCPROGDIRS) \
+  $(CPROGDIRS) \
+  $(SHPROGDIRS) \
+  src/devices/xditview \
+  src/utils/xtotroff
 DEVDIRS=\
   font/devps \
   font/devdvi \
@@ -735,8 +747,8 @@ GNULIBDIRS=\
   src/libs/gnulib
 DISTDIRS=\
   $(INCDIRS) \
-  $(LIBDIRS) \
-  $(PROGDIRS) \
+  $(ALLLIBDIRS) \
+  $(ALLPROGDIRS) \
   $(DEVDIRS) \
   $(XDEVDIRS) \
   $(OTHERDEVDIRS) \

Re: [Groff] GNU troff version 1.22.3

[Colin Watson]

On Sat, Nov 08, 2014 at 01:27:37PM +, Ralph Corderoy wrote:
> Ubuntu's package manager?  http://packages.ubuntu.com/utopic/groff says
> 14.10's is currently 1.22.2-8 and that they take Debian's package,
> maintained by Colin Watson (who's on this list).  That version is what's
> in Debian's `testing', https://packages.debian.org/jessie/groff
> Debian's `unstable' has 1.22.3-1!  https://packages.debian.org/sid/groff
> Thanks Colin.  :-)
> 
> But I don't think Ubuntu will update the normal groff package until
> 15.04, and that's when Debian's 1.22.3 might arrive there.  Ah, Colin's
> https://launchpad.net/ubuntu/+source/groff has 1.22.3-1 down for 15.04.
> Whether you can find a PPA containing 1.22.3 that's compatible with
> whatever version you're running, I don't know.

For the record, I advised Grégoire to just download the .debs for 15.04
and install them directly using "dpkg -i"; the package structure is
simple enough that that shouldn't be much of a practical problem.

-- 
Colin Watson   [cjwat...@debian.org]

Re: [Groff] Reproducible dates in HTML/PDF/PS output files?

[Colin Watson]

Here's an updated patch for this issue.  The difference relative to my
previous patch is that, rather than taking an environment variable to
disable timestamp output altogether, this takes an environment variable
to force a specific time: this is intended to be used by build systems
to e.g. ensure that all documents produced by a given build have a
creation date corresponding to the changelog date of the overall
package, rather than whatever time the build system happened to run.

Notwithstanding Werner's comments, I think that an environment variable
is a clearly better approach to this, because it's much easier to
arrange for it to be passed through build systems.  But I hope that
switching to the timestamp-based variable means that it's unlikely to be
set permanently in users' environments.  Also, SOURCE_DATE_EPOCH is an
emerging standard which is supported in an increasing number of other
packages, which means that build systems only need to set one variable
rather than kludging around things in a dozen different places.

The reason why filtering PDF output and the like is an inferior
solution, even though it's certainly possible (strip-nondeterminism
etc.; https://reproducible-builds.org/docs/timestamps/), is that it's
much more complicated and less transparent.  With a reproducible build
toolchain it is possible to build an entire package multiple times on
entirely different systems and get a bitwise-identical .deb; if you're
relying on postprocessing then it's much less obvious that nothing else
has sneaked in and you need a complicated pile of stuff to unpack two
packages and do a deep (possibly recursive!) comparison of files within
them.  Yes, we did without this for 20+ years, and it's not absolutely
the end of the world not to have it, but that doesn't mean it isn't
useful to work on it now.

More details on SOURCE_DATE_EPOCH (and there are many other useful
things on the same site):

  https://reproducible-builds.org/specs/source-date-epoch/

-- 
Colin Watson   [cjwat...@debian.org]
>From c111bb75c4793bbde55d173969492828d83496db Mon Sep 17 00:00:00 2001
From: Colin Watson 
Date: Wed, 27 Aug 2014 09:06:26 +0100
Subject: [PATCH] Implement `SOURCE_DATE_EPOCH' for reproducible builds.

* src/include/curtime.h: New file.
* src/libs/libgroff/curtime.cpp: New file.
* src/libs/libgroff/libgroff.am (libgroff_a_SOURCES): Add
src/libs/libgroff/curtime.cpp.

* src/roff/troff/input.cpp (init_registers): Use `current_time'
instead of `time(0)'.
* src/devices/grohtml/post-html.cpp
(html_printer::do_file_components): Likewise.
(html_printer::~html_printer): Likewise.
* src/devices/grops/ps.cpp (ps_printer::~ps_printer): Likewise.
* src/devices/gropdf/gropdf.pl: Use `$ENV{SOURCE_DATE_EPOCH}` if
available in preference to `time`.

* doc/groff.texi (Environment): Document `SOURCE_DATE_EPOCH'.
* src/devices/grohtml/grohtml.1.man (ENVIRONMENT): Likewise.
* src/devices/gropdf/gropdf.1.man (ENVIRONMENT): Likewise.
* src/devices/grops/grops.1.man (ENVIRONMENT): Likewise.
---
 ChangeLog | 23 ++
 doc/groff.texi|  6 +
 src/devices/grohtml/grohtml.1.man |  7 ++
 src/devices/grohtml/post-html.cpp |  5 ++--
 src/devices/gropdf/gropdf.1.man   |  7 ++
 src/devices/gropdf/gropdf.pl  |  3 ++-
 src/devices/grops/grops.1.man |  7 ++
 src/devices/grops/ps.cpp  |  3 ++-
 src/include/curtime.h | 23 ++
 src/libs/libgroff/curtime.cpp | 51 +++
 src/libs/libgroff/libgroff.am |  1 +
 src/roff/troff/input.cpp  |  3 ++-
 12 files changed, 134 insertions(+), 5 deletions(-)
 create mode 100644 src/include/curtime.h
 create mode 100644 src/libs/libgroff/curtime.cpp

diff --git a/ChangeLog b/ChangeLog
index 2333859..98eac45 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,26 @@
+2015-11-05  Colin Watson  
+
+	Implement `SOURCE_DATE_EPOCH' for reproducible builds.
+
+	* src/include/curtime.h: New file.
+	* src/libs/libgroff/curtime.cpp: New file.
+	* src/libs/libgroff/libgroff.am (libgroff_a_SOURCES): Add
+	src/libs/libgroff/curtime.cpp.
+
+	* src/roff/troff/input.cpp (init_registers): Use `current_time'
+	instead of `time(0)'.
+	* src/devices/grohtml/post-html.cpp
+	(html_printer::do_file_components): Likewise.
+	(html_printer::~html_printer): Likewise.
+	* src/devices/grops/ps.cpp (ps_printer::~ps_printer): Likewise.
+	* src/devices/gropdf/gropdf.pl: Use `$ENV{SOURCE_DATE_EPOCH}` if
+	available in preference to `time`.
+
+	* doc/groff.texi (Environment): Document `SOURCE_DATE_EPOCH'.
+	* src/devices/grohtml/grohtml.1.man (ENVIRONMENT): Likewise.
+	* src/devices/gropdf/gropdf.1.man (ENVIRONMENT): Likewise.
+	* src/devices/grops/grops.1.man (ENVIRONMENT): Likewise.
+
 2015-10-27  Deri James  
 
 	gropdf was choking on -I flag passed 

Re: [Groff] [Reproducible-builds] Reproducible dates in HTML/PDF/PS output files?

[Colin Watson]

On Mon, Jun 13, 2016 at 09:31:54AM -0400, Daniel Kahn Gillmor wrote:
> On Mon 2016-06-13 09:20:46 -0400, Ximin Luo wrote:
> > Hey, any news on this? The original thread I'm referring to is this one:
> >
> > https://lists.gnu.org/archive/html/groff/2015-11/msg00013.html
> 
> Werner LEMBERG said "Looks good, please proceed" here:
> 
> https://lists.gnu.org/archive/html/groff/2015-11/msg00038.html
> 
> but i don't know whether that was directing Colin or someone else to
> proceed (or whether Colin is able to do so directly), and what the next
> step actually is.

As far as I know I don't have direct commit access.  I believe my patch
still applies as-is with the exception of ChangeLog, though.  Werner,
might you be able to commit it?

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Re: [Groff] [Reproducible-builds] Reproducible dates in HTML/PDF/PS output files?

[Colin Watson]

On Tue, Jun 14, 2016 at 05:59:26AM +0200, Werner LEMBERG wrote:
> Colin Watson wrote:
> > As far as I know I don't have direct commit access.
> 
> You have :-)  So please proceed!

Right, so I do, and apologies for the delay.  Pushed now.

Cheers,

-- 
Colin Watson   [cjwat...@debian.org]

[Groff] BuildFoundries mistakenly installed?

[Colin Watson]

I was looking through Debian's groff packaging to see what could
usefully be simplified given some upstream changes.  At the moment I
have a custom rule to make $(datadir)/font/devpdf/util/BuildFoundries
executable, since it has a #! line, and I was going to apply this to
master to fix that for everyone:

diff --git a/font/devpdf/devpdf.am b/font/devpdf/devpdf.am
index 067da3fd..3e125694 100644
--- a/font/devpdf/devpdf.am
+++ b/font/devpdf/devpdf.am
@@ -50,7 +50,7 @@ DEVPDFFONTMAP_2 = font/devpdf/map/symbolmap
 devpdffontmap_DATA = $(DEVPDFFONTMAP_1) $(DEVPDFFONTMAP_2)

 devpdffontutildir = $(devpdffontdir)/util
-nodist_devpdffontutil_DATA = font/devpdf/util/BuildFoundries
+nodist_devpdffontutil_SCRIPTS = font/devpdf/util/BuildFoundries

 EXTRA_DIST += \
   font/devpdf/DESC.in \

However, I then took a closer look at history and found this:

2011-08-14  Deri James  

[gropdf] More minor fixes.

* font/devpdf/Makefile.sub (MOSTLYCLEANADD): Don't attempt to
install 'util/BuildFoundries', only used in 'make'.

So I think that this is a regression in Bertrand's Automake migration,
and a more correct fix would be as follows (whitespace-damaged, but this
is just for discussion - I can commit it myself if people think this is
correct):

diff --git a/font/devpdf/devpdf.am b/font/devpdf/devpdf.am
index 067da3fd..1facd122 100644
--- a/font/devpdf/devpdf.am
+++ b/font/devpdf/devpdf.am
@@ -49,9 +49,6 @@ DEVPDFFONTMAP_1 = \
 DEVPDFFONTMAP_2 = font/devpdf/map/symbolmap
 devpdffontmap_DATA = $(DEVPDFFONTMAP_1) $(DEVPDFFONTMAP_2)

-devpdffontutildir = $(devpdffontdir)/util
-nodist_devpdffontutil_DATA = font/devpdf/util/BuildFoundries
-
 EXTRA_DIST += \
   font/devpdf/DESC.in \
   font/devpdf/Foundry.in \
@@ -136,8 +133,8 @@ mostlyclean_devpdf_extra:
 install-data-local: install_devpdf
 install_devpdf:
@echo Installing devpdf files
-   -@test -d $(DESTDIR)$(devpdffontdir)/util \
- || $(mkinstalldirs) $(DESTDIR)$(devpdffontdir)/util
+   -@test -d $(DESTDIR)$(devpdffontdir) \
+ || $(mkinstalldirs) $(DESTDIR)$(devpdffontdir)
@for f in $(GROFF_FONT_FILES); do \
  $(RM) $(DESTDIR)$(devpdffontdir)/$$f; \
  if test -f $$f; then \
@@ -155,9 +152,6 @@ uninstall_devpdf:
  for f in $(GROFF_FONT_FILES); do \
rm -f $(DESTDIR)$(devpdffontdir)/$$f; \
  done; \
- if test -d $(DESTDIR)$(devpdffontutildir); then \
-   rmdir $(DESTDIR)$(devpdffontutildir); \
- fi; \
  if test -d $(DESTDIR)$(devpdffontencdir); then \
rmdir $(DESTDIR)$(devpdffontencdir); \
  fi; \

What do you think?

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

[Groff] [PATCH] mdate.sh: rewrite in Perl

[Colin Watson]

groff already requires perl to build.  This version is much shorter
and easier to understand than the shell/awk version: we don't have
to worry about convincing ls to produce output that we can parse,
and we don't have to play games with the way that the same field may
contain either the year or the time depending on how old the file
is.

While I'm at it, this version also adds `SOURCE_DATE_EPOCH' support
for reproducible builds: when `SOURCE_DATE_EPOCH' is set, files are
considered to have been last modified at that time.

* mdate.sh: Rewrite in Perl, moving to ...
* mdate.pl: ... this new file.
* Makefile.am (EXTRA_DIST, .man): Update references.
---
 ChangeLog   | 19 +++
 Makefile.am |  4 ++--
 mdate.pl| 32 
 mdate.sh| 59 ---
 4 files changed, 53 insertions(+), 61 deletions(-)
 create mode 100755 mdate.pl
 delete mode 100755 mdate.sh

diff --git a/ChangeLog b/ChangeLog
index e0263e6c..c73e23c6 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,22 @@
+2017-02-18  Colin Watson  
+
+   mdate.sh: rewrite in Perl
+
+   groff already requires perl to build.  This version is much shorter
+   and easier to understand than the shell/awk version: we don't have
+   to worry about convincing ls to produce output that we can parse,
+   and we don't have to play games with the way that the same field may
+   contain either the year or the time depending on how old the file
+   is.
+
+   While I'm at it, this version also adds `SOURCE_DATE_EPOCH' support
+   for reproducible builds: when `SOURCE_DATE_EPOCH' is set, files are
+   considered to have been last modified at that time.
+
+   * mdate.sh: Rewrite in Perl, moving to ...
+   * mdate.pl: ... this new file.
+   * Makefile.am (EXTRA_DIST, .man): Update references.
+
 2017-02-16  Ingo Schwarze  
 
mdoc %T: use typographic quotes
diff --git a/Makefile.am b/Makefile.am
index 2697115c..76e53525 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -834,7 +834,7 @@ EXTRA_DIST += \
   INSTALL.gen \
   LICENSES \
   MANIFEST \
-  mdate.sh \
+  mdate.pl \
   MORE.STUFF \
   PROBLEMS \
   PROJECTS \
@@ -879,7 +879,7 @@ SUFFIXES += .man
 -e "s|[@]MAN1EXT[@]|$(man1ext)|g" \
 -e "s|[@]MAN5EXT[@]|$(man5ext)|g" \
 -e "s|[@]MAN7EXT[@]|$(man7ext)|g" \
--e "s|[@]MDATE[@]|`$(SHELL) $(top_srcdir)/mdate.sh $<`|g" \
+-e "s|[@]MDATE[@]|`$(PERL) $(top_srcdir)/mdate.pl $<`|g" \
 -e "s|[@]OLDFONTDIR[@]|$(oldfontdir)|g" \
 -e "s|[@]PDFDOCDIR[@]|$(pdfdocdir)|g" \
 -e "s|[@]SYSTEMMACRODIR[@]|$(systemtmacdir)|g" \
diff --git a/mdate.pl b/mdate.pl
new file mode 100755
index ..c698f983
--- /dev/null
+++ b/mdate.pl
@@ -0,0 +1,32 @@
+#! /usr/bin/env perl
+#
+# Copyright (C) 1991-2017 Free Software Foundation, Inc.
+# 
+# This file is part of groff.
+# 
+# groff is free software; you can redistribute it and/or modify it under
+# the terms of the GNU General Public License as published by the Free
+# Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+# 
+# groff is distributed in the hope that it will be useful, but WITHOUT ANY
+# WARRANTY; without even the implied warranty of MERCHANTABILITY or
+# FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+# for more details.
+# 
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+#
+# Print the modification date of $1 `nicely'.
+
+use warnings;
+use strict;
+use POSIX qw(LC_ALL setlocale strftime);
+
+# Don't want localized dates.
+setlocale(LC_ALL, "C");
+
+my @mtime = gmtime($ENV{SOURCE_DATE_EPOCH} || (stat $ARGV[0])[9]);
+my $mdate = strftime("%e %B %Y", @mtime);
+$mdate =~ s/^ //;
+print "$mdate\n";
diff --git a/mdate.sh b/mdate.sh
deleted file mode 100755
index 2c24a009..
--- a/mdate.sh
+++ /dev/null
@@ -1,59 +0,0 @@
-#! /bin/sh
-#
-# Copyright (C) 1991-2014 Free Software Foundation, Inc.
-# 
-# This file is part of groff.
-# 
-# groff is free software; you can redistribute it and/or modify it under
-# the terms of the GNU General Public License as published by the Free
-# Software Foundation, either version 3 of the License, or
-# (at your option) any later version.
-# 
-# groff is distributed in the hope that it will be useful, but WITHOUT ANY
-# WARRANTY; without even the implied warranty of MERCHANTABILITY or
-# FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
-# for more details.
-# 
-# You should have received a copy of the GNU General Public License
-# along with this program. If not, see <http://www.gnu.org/licenses/

[Groff] [PATCH] doc: stop generating W3C validation icons

[Colin Watson]

Debian's `lintian' tool says:

  These badges may be displayed to tell readers that care has been
  taken to make a page compliant with W3C standards.  Unfortunately,
  downloading the image from www.w3.org might expose the reader's IP
  address to potential tracking.

I think the risk is a small one, but I also don't think the badges
are especially valuable, so it doesn't seem like much to ask to just
drop them at least for groff's own documentation.

* doc/doc.am (.ms.html, doc/pic.html): Remove `-P-V' option.
---
 ChangeLog  | 17 +
 doc/doc.am |  4 ++--
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index e0263e6c..76491b1e 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,20 @@
+2017-02-18  Colin Watson  
+
+   doc: stop generating W3C validation icons
+
+   Debian's `lintian' tool says:
+
+ These badges may be displayed to tell readers that care has been
+ taken to make a page compliant with W3C standards.  Unfortunately,
+ downloading the image from www.w3.org might expose the reader's IP
+ address to potential tracking.
+
+   I think the risk is a small one, but I also don't think the badges
+   are especially valuable, so it doesn't seem like much to ask to just
+   drop them at least for groff's own documentation.
+
+   * doc/doc.am (.ms.html, doc/pic.html): Remove `-P-V' option.
+
 2017-02-16  Ingo Schwarze  
 
mdoc %T: use typographic quotes
diff --git a/doc/doc.am b/doc/doc.am
index 27f47d61..b662f13a 100644
--- a/doc/doc.am
+++ b/doc/doc.am
@@ -134,7 +134,7 @@ SUFFIXES += .me .ms .ps .html .txt .texi .dvi .pdf .xhtml
 .ms.html:
@$(MKDIR_P) `dirname $@`
$(DOC_GROFF) -P-p -P-b -P-I`basename $< | sed -e 's|.ms$$||'` \
--P-D$(imagedir) -P-V -Thtml -ms >$@
+-P-D$(imagedir) -Thtml -ms >$@
 .ms.txt:
@$(MKDIR_P) `dirname $@`
$(DOC_GROFF) -Tascii -ms -mwww >$@
@@ -155,7 +155,7 @@ doc/pic.html: $(doc_srcdir)/pic.ms $(devhtmlfont_DATA)
cd $(doc_builddir) && \
$(DOC_SED) $(doc_srcdir)/pic.ms | \
$(DOC_GROFF_ONLY) -P-p -P-Ipic -P-D$(imagedir) -P-jpic \
--Thtml -P-V -ms > pic.html
+-Thtml -ms > pic.html
 
 doc/examples.stamp: doc/groff.css
@$(MKDIR_P) $(doc_builddir)
-- 
2.11.0

Re: [Groff] [PATCH] Appease "groff -wmac" when using eqn or pic

[Colin Watson]

On Thu, Jan 02, 2014 at 01:55:05PM +, Colin Watson wrote:
> * src/preproc/eqn/main.cpp: Define EQ and EN if they are not already
> defined, to appease "groff -wmac".
> * src/preproc/pic/main.cpp: Likewise for PS and PE.
> 
> Fixes: http://bugs.debian.org/495713

I've gone ahead and pushed this old patch to master, since it's small
and seems to have been uncontroversial.

-- 
Colin Watson   [cjwat...@debian.org]

[Groff] [PATCH] Remove #! lines from non-executable files

[Colin Watson]

These are always invoked by the build system (either in-tree or via
the installed Makefiles) using the necessary program, so the #!
lines were unnecessary.  They were harmless except that they caused
Debian's `lintian` tool to complain about installed non-executable
scripts.

* font/devlj4/generate/special.awk: Remove #! line.
* font/devps/generate/symbol.sed: Likewise.
---
 ChangeLog| 13 +
 font/devlj4/generate/special.awk |  2 --
 font/devps/generate/symbol.sed   |  1 -
 3 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 861f8d80..a571a0be 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,18 @@
 2017-02-18  Colin Watson  
 
+   Remove #! lines from non-executable files
+
+   These are always invoked by the build system (either in-tree or via
+   the installed Makefiles) using the necessary program, so the #!
+   lines were unnecessary.  They were harmless except that they caused
+   Debian's `lintian` tool to complain about installed non-executable
+   scripts.
+
+   * font/devlj4/generate/special.awk: Remove #! line.
+   * font/devps/generate/symbol.sed: Likewise.
+
+2017-02-18  Colin Watson  
+
* src/preproc/eqn/main.cpp: Define EQ and EN if they are not already
defined, to appease "groff -wmac".
* src/preproc/pic/main.cpp: Likewise for PS and PE.
diff --git a/font/devlj4/generate/special.awk b/font/devlj4/generate/special.awk
index 26e8b92d..8e3c702b 100644
--- a/font/devlj4/generate/special.awk
+++ b/font/devlj4/generate/special.awk
@@ -1,5 +1,3 @@
-#! /bin/awk -f
-
 # Correct Intellifont-based height metrics for several glyphs in
 # special font for TrueType CG Times (LaserJet 4000 and later).
 
diff --git a/font/devps/generate/symbol.sed b/font/devps/generate/symbol.sed
index 153e6314..0bc4fb93 100644
--- a/font/devps/generate/symbol.sed
+++ b/font/devps/generate/symbol.sed
@@ -1,4 +1,3 @@
-#! /bin/sed -f
 # Set up uniform vertical dimensions for extensible glyphs (needed by eqn).
 /^C .*[ ;]N bracketlefttp[ ;]/bx
 /^C .*[ ;]N bracketleftex[ ;]/bx
-- 
2.11.0

Re: [Groff] [PATCH] mdate.sh: rewrite in Perl

[Colin Watson]

On Sat, Feb 18, 2017 at 01:07:38PM -0500, James K. Lowden wrote:
> On Sat, 18 Feb 2017 03:28:03 +
> Colin Watson  wrote:
> > This version is much shorter and easier to understand than the
> > shell/awk version: we don't have to worry about convincing ls to
> > produce output that we can parse, and we don't have to play games
> > with the way that the same field may contain either the year or the
> > time depending on how old the file is.
> 
> Attached please find fdate.c. It accepts filename argments and prints
> the files' mtimes (and, optionally, names).  Like date(1), it accepts a
> strftime format argument, defaulting to -mm-dd.

Thanks.  This is for a small build helper used to embed modification
times in manual pages, though; I'm not sure it's worth trying too hard.
It has precisely one purpose and does not require additional optional
behaviours.

My usual philosophy for such things is that small and
quick-to-understand code is better than more performant code;
furthermore, having to compile a helper first would require adding more
complication to the build system.

-- 
Colin Watson   [cjwat...@debian.org]

Re: [Groff] Nesting font macros in man pages

[Colin Watson]

On Mon, Apr 24, 2017 at 06:29:57PM +0200, Ingo Schwarze wrote:
> There is little you can do to make writing legacy man(7) code
> easier for the novice.  The problem is that it always requires
> mixing two different language levels:  man(7) macros and low-level
> roff requests and escapes.  And that it also requires writing
> physical rather than semantic markup, which is obviously harder
> to do in a consistent manner.
> 
> Writing mdoc(7) is much easier for the novice because it's semantic
> and because it does not require mixing in low-level roff features.
> But trying to make man(7) easier to write is bound for disaster.
> The only remaining asset of man(7) is portability,

The main practical reason I've stuck with man(7) in some cases (such as
in man-db) despite generally preferring mdoc(7) is that I think
translations are important, and po4a(1) works rather more gracefully
with man(7).  With mdoc(7), I find that I end up with nonsense like this
in my .pot file, which I really can't expect a translator to have the
slightest clue about:

  #. type: Plain text
  #: madison-lite.1:21
  msgid ""
  "E<.Nm> E<.Op Fl Fl config\\-file Ar file> E<.Op Fl Fl mirror Ar directory> "
  "E<.Op Fl Fl nocache> E<.Op Fl Fl update> E<.Op Fl S> E<.Op Fl r> E<.Op Fl a "
  "Ar architecture Ns Op , Ns Ar ...> E<.Op Fl c Ar component Ns Op , Ns Ar "
  "...> E<.Op Fl s Ar suite Ns Op , Ns Ar ...> E<.Ar package> E<.Op Ar ...>"
  msgstr ""

Locale::Po4a::Man(3pm) does offer some ways to hit this over the head,
but they don't really work very well in practice, I think because it
doesn't understand the way that mdoc(7) parses its argument list for
callable macro names.  An understandable omission given the complexity,
but it does end up being a blocker for me.

This is of course not a deficiency in *roff, but it's a problem in the
wider ecosystem that IMO a serious push towards mdoc(7) ought to
address.

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] Release Candidate 1.22.3.rc1

[Colin Watson]

On Sat, Feb 17, 2018 at 12:40:57PM +, Ralph Corderoy wrote:
> Hi Bertrand,
> 
> >   git clone https://git.savannah.gnu.org/git/groff.git
> >   cd groff
> >   git checkout 1.22.3.rc1
> >   ./bootstrap
> 
> ./bootstrap fails here.  autoconf 2.69-11 on Ubuntu 17.10.  It seems
> ./configure has unexpanded m4 macros.

This should just be a matter of amending INSTALL.REPO (and maybe
doc/automake.mom?) to note that you need pkg-config installed in order
to run ./bootstrap (because the .m4 file it ships must be available to
autoconf).

-- 
Colin Watson   [cjwat...@debian.org]

[groff] [PATCH] Switch to Gnulib implementation of snprintf

[Colin Watson]

This is more actively maintained, straightforward to integrate now that
we have Gnulib integration, and simplifies groff's overall licensing.

* bootstrap.conf (gnulib_modules): Add `snprintf' and `vsnprintf'.
* configure.ac: Remove local checks for `snprintf' and `vsnprintf'.
* Makefile.am: Remove various comments related to local checks for
`snprintf' and `vsnprintf'.
* src/include/lib.h: Remove declarations of `snprintf' and `vsnprintf'.
* src/libs/libgroff/libgroff.am (EXTRA_DIST): Remove
`src/libs/snprintf/snprintf.c'.
* src/libs/snprintf/snprintf.c: Remove.

* LICENSES: Remove section about `src/libs/snprintf/snprintf.c'.
* MANIFEST: Remove entry for `src/libs/libxutil'.
---
 LICENSES  |   10 -
 MANIFEST  |1 -
 Makefile.am   |9 +-
 bootstrap.conf|2 +
 configure.ac  |6 +-
 src/include/lib.h |   10 -
 src/libs/libgroff/libgroff.am |6 +-
 src/libs/snprintf/snprintf.c  | 1131 -
 8 files changed, 6 insertions(+), 1169 deletions(-)
 delete mode 100644 src/libs/snprintf/snprintf.c

diff --git a/LICENSES b/LICENSES
index 2471a001..7cd93c4a 100644
--- a/LICENSES
+++ b/LICENSES
@@ -36,16 +36,6 @@ hasn't been assigned to the FSF).
   Source Files
   
 
-  . The file `src/libs/snprintf/snprintf.c', written by Mark Martinec
-.
-
-Please look into snprintf.c for the copyright message.
-
-The complete snprintf package together with documentation is available
-from
-
-  http://www.ijs.si/software/snprintf/.
-
   . The `grn' preprocessor, written by Barry Roitblat 
 and David Slattengren .  These files have been part
 of the original Berkeley ditroff distribution, without AT&T code, and
diff --git a/MANIFEST b/MANIFEST
index 2bec20fe..4fe3b383 100644
--- a/MANIFEST
+++ b/MANIFEST
@@ -101,7 +101,6 @@ the groff source distribution.
   libdriver Parser for intermediate output and postprocessor code.
   libgroff  Library for general support functions used everywhere.
   libxutil  Utility functions for xditview and xtotroff.
-  snprintf  An implementation of snprintf() and friends.
 
 ./src/preproc   Preprocessors.
   eqn   Mathematical formulae.
diff --git a/Makefile.am b/Makefile.am
index 7de03f58..2d235f81 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -397,14 +397,12 @@ man7dir=$(manroot)/man$(man7ext)
 # HAVE_PUTENV  if you have putenv()
 # HAVE_RENAME  if you have rename()
 # HAVE_SETLOCALE   if you have setlocale()
-# HAVE_SNPRINTFif you have snprintf()
 # HAVE_STRCASECMP  if you have strcasecmp()
 # HAVE_STRNCASECMP if you have strncasecmp()
 # HAVE_STRERRORif you have strerror()
 # HAVE_STRSEP  if you have strsep()
 # HAVE_STRTOL  if you have strtol()
 # HAVE_SYMLINK if you have symlink()
-# HAVE_VSNPRINTF   if you have vsnprintf()
 #
 # NEED_DECLARATION_GETTIMEOFTODAY
 #  if your C++  doesn't declare
@@ -415,8 +413,6 @@ man7dir=$(manroot)/man$(man7ext)
 # NEED_DECLARATION_PUTENV  if your C++  doesn't declare
 #  putenv()
 # NEED_DECLARATION_RANDif your C++  doesn't declare rand()
-# NEED_DECLARATION_SNPRINTFif your C++  doesn't declare
-#  snprintf()
 # NEED_DECLARATION_SRAND   if your C++  doesn't declare srand()
 # NEED_DECLARATION_STRCASECMP  if your C++  doesn't declare
 #  strcasecmp()
@@ -425,8 +421,6 @@ man7dir=$(manroot)/man$(man7ext)
 #  strncasecmp()
 # NEED_DECLARATION_VFPRINTFif your C++  doesn't declare
 #  vfprintf()
-# NEED_DECLARATION_VSNPRINTF   if your C++  doesn't declare
-#  vsnprintf()
 #
 # HAVE_DECL_GETC_UNLOCKED  if you have getc_unlocked()
 # HAVE_DECL_SYS_SIGLISTif you have sys_siglist[]
@@ -461,12 +455,11 @@ man7dir=$(manroot)/man$(man7ext)
 
 # Include
 #
-#   {fmod,getcwd,mkstemp,putenv,snprintf,strcasecmp,
+#   {fmod,getcwd,mkstemp,putenv,strcasecmp,
 #strerror,strncasecmp,strtol}.$(OBJEXT)
 #
 # LIBOBJS
 # in LIBOBJS if your C library is missing the corresponding function.
-# vsnprintf is defined in the snprintf.$(OBJEXT) module.
 
 # `CCC' is the compiler for C++ (.cpp) files.
 CCC=@CXX@
diff --git a/bootstrap.conf b/bootstrap.conf
index deda4f60..6fd28de3 100644
--- a/bootstrap.conf
+++ b/bootstrap.conf
@@ -41,6 +41,8 @@ gnulib_modules="
 non-recursive-gnulib-prefix-hack
 wcwidth
 fprintf-posix
+snprintf
+vsnprintf
 "
 
 # Name of the Makefile.am
diff --git a/configure.ac b/configure.ac
index bf46a4e4..42bfe87e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -91,12 +91,10 @@ GROFF_NEED_DECLARATION([popen])
 GROFF_NEED_DECLARATION([pclose])
 GROFF_NEED_DECLA

Re: [groff] Release Candidate 1.22.3.rc1

[Colin Watson]

On Wed, Feb 21, 2018 at 11:48:56PM +0100, Bertrand Garrigues wrote:
> I'll add a check on the presence of pkg-config in m4/groff.m4 and update
> the doc.

But the pkg-config macros themselves already do that ...

> It should be documented in INSTALL.extra rather then INSTALL.REPO as
> INSTALL.REPO described the specificities of buildin from git.

This is exactly why I suggested that it should go in INSTALL.REPO,
because pkg-config is a dependency of ./bootstrap as well as of
./configure.  ./configure itself will issue a reasonable error if
pkg-config isn't installed, but ./bootstrap will only produce the
mysterious failure that Ralph noted.

(I wouldn't object to it being documented in INSTALL.extra too.)

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] Release Candidate 1.22.3.rc1

[Colin Watson]

On Wed, Feb 21, 2018 at 08:39:50PM -0500, Peter Schaffter wrote:
> The first warning is unrelated to the font installation
> problem, which, IIRC, we established was the result of the
> 'gsfonts-other' package not being installed.  Perhaps Colin would
> consider making gsfonts-other a dependency for the groff-base and
> groff packages?

Can't do that, because gsfonts-other is in non-free.  (It looks like
perhaps it's a conglomeration of free elements and random stuff like
shareware.)  Is there no free alternative that works?

-- 
Colin Watson   [cjwat...@debian.org]

[groff] [PATCH] Remove unnecessary randomness from example output

[Colin Watson]

The hdtbl examples don't need good randomness, as they're only
example output; removing the process ID from consideration allows
better integration with reproducible builds.

* contrib/hdtbl/examples/common.roff (random-s1): Remove process ID.
---
 ChangeLog  | 10 ++
 contrib/hdtbl/examples/common.roff |  6 +-
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/ChangeLog b/ChangeLog
index 25b6629..af6de40 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2018-03-05  Colin Watson  
+
+   Remove unnecessary randomness from example output.
+
+   The hdtbl examples don't need good randomness, as they're only
+   example output; removing the process ID from consideration allows
+   better integration with reproducible builds.
+
+   * contrib/hdtbl/examples/common.roff (random-s1): Remove process ID.
+
 2018-03-02  Werner LEMBERG  
 
Hyphenation exceptions in pattern files now obey `.hy' (#53196).
diff --git a/contrib/hdtbl/examples/common.roff 
b/contrib/hdtbl/examples/common.roff
index e112be8..7357918 100644
--- a/contrib/hdtbl/examples/common.roff
+++ b/contrib/hdtbl/examples/common.roff
@@ -234,7 +234,11 @@ along with this program.  If not, see 
<http://www.gnu.org/licenses/>.
 .af mo 00
 .af dy 00
 .
-.ds random-s1 \n[minutes]\n[seconds]\n[$$]\n[hours]\"
+.\" Since this just generates example output, we don't need good randomness;
+.\" basing this purely on the time and not on the process ID allows better
+.\" integration with reproducible builds.
+.\" .ds random-s1 \n[minutes]\n[seconds]\n[$$]\n[hours]\"
+.ds random-s1 \n[minutes]\n[seconds]\n[hours]\"
 .\" prevent overflow
 .substring random-s1 0 8
 .
-- 
2.7.4

[groff] [PATCH] Sort Perl hash keys

[Colin Watson]

Hash iteration order may differ between runs, which makes builds
harder to reproduce.  Sort hash keys in gropdf and afmtodit output
to avoid this.

* src/devices/gropdf/gropdf.pl: Sort hash keys.
* src/utils/afmtodit/afmtodit.pl: Iterate over sorted keys rather
  than using `each'.
---
 ChangeLog  | 12 
 src/devices/gropdf/gropdf.pl   |  8 
 src/utils/afmtodit/afmtodit.pl | 12 ++--
 3 files changed, 22 insertions(+), 10 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 25b6629..fb6914d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,15 @@
+2018-03-05  Colin Watson  
+
+   Sort Perl hash keys.
+
+   Hash iteration order may differ between runs, which makes builds
+   harder to reproduce.  Sort hash keys in gropdf and afmtodit output
+   to avoid this.
+
+   * src/devices/gropdf/gropdf.pl: Sort hash keys.
+   * src/utils/afmtodit/afmtodit.pl: Iterate over sorted keys rather
+ than using `each'.
+
 2018-03-02  Werner LEMBERG  
 
Hyphenation exceptions in pattern files now obey `.hy' (#53196).
diff --git a/src/devices/gropdf/gropdf.pl b/src/devices/gropdf/gropdf.pl
index 8a4b4b6..867ab30 100644
--- a/src/devices/gropdf/gropdf.pl
+++ b/src/devices/gropdf/gropdf.pl
@@ -375,7 +375,7 @@ my $info=BuildObj(++$objct,\%info);
 
 PutObj($objct);
 
-foreach my $fontno (keys %fontlst)
+foreach my $fontno (sort keys %fontlst)
 {
 my $o=$fontlst{$fontno}->{FNT};
 
@@ -844,7 +844,7 @@ sub do_x
my @xwds=split(' ',"<< $1 >>");
my $docinfo=ParsePDFValue(\@xwds);
 
-   foreach my $k (keys %{$docinfo})
+   foreach my $k (sort keys %{$docinfo})
{
$info{$k}=$docinfo->{$k} if $k ne 'Producer';
}
@@ -854,7 +854,7 @@ sub do_x
my @xwds=split(' ',"<< $1 >>");
my $docview=ParsePDFValue(\@xwds);
 
-   foreach my $k (keys %{$docview})
+   foreach my $k (sort keys %{$docview})
{
$cat->{$k}=$docview->{$k} if !exists($cat->{$k});
}
@@ -1697,7 +1697,7 @@ sub MapInsHash
 my $val=shift;
 
 
-foreach my $k (keys(%{$val}))
+foreach my $k (sort keys(%{$val}))
 {
MapInsValue($pdf,$o,$k,$insmap,$parent,$val->{$k}) if $k ne 'Contents';
 }
diff --git a/src/utils/afmtodit/afmtodit.pl b/src/utils/afmtodit/afmtodit.pl
index f2fc6c2..0a3857a 100644
--- a/src/utils/afmtodit/afmtodit.pl
+++ b/src/utils/afmtodit/afmtodit.pl
@@ -164,8 +164,8 @@ while () {
$depth{$n} = -$lly;
$left_side_bearing{$n} = -$llx;
$right_side_bearing{$n} = $urx - $w;
-#  while ((my $lig, my $glyph2) = each %ligs) {
-#  $ligatures{$lig} = $n . " " . $glyph2;
+#  foreach my $lig (sort keys %ligs) {
+#  $ligatures{$lig} = $n . " " . $ligs{$lig};
 #  }
}
}
@@ -267,7 +267,7 @@ $italic_angle = $opt_a if $opt_a;
 if (!$opt_x) {
 my %mapped;
 my $i = ($#encoding > 256) ? ($#encoding + 1) : 256;
-while (my $ch = each %width) {
+foreach my $ch (sort keys %width) {
# add unencoded characters
if (!$in_encoding{$ch}) {
$encoding[$i] = $ch;
@@ -407,9 +407,9 @@ my %default_ligatures = (
   "ffl", "ff l",
 );
 
-while (my ($lig, $components) = each %default_ligatures) {
+foreach my $lig (sort keys %default_ligatures) {
 if (defined $width{$lig} && !defined $ligatures{$lig}) {
-   $ligatures{$lig} = $components;
+   $ligatures{$lig} = $default_ligatures{$lig};
 }
 }
 
@@ -456,7 +456,7 @@ if ($opt_e) {
 
 if (!$opt_n && %ligatures) {
 print("ligatures");
-while (my $lig = each %ligatures) {
+foreach my $lig (sort keys %ligatures) {
print(" $lig");
 }
 print(" 0\n");
-- 
2.7.4

Re: [groff] Release Candidate 1.22.3.rc1

[Colin Watson]

On Fri, Feb 16, 2018 at 12:24:38AM +0100, Bertrand Garrigues wrote:
> I now have full access to GNU's ftp, and I have generated a release
> 1.22.3.rc1.  The target is to stabilize this version before generating
> an official 1.22.4.  If you think there are some important fixes that
> must be passed (I haven't reviewed the Savannah bug list for a while,
> I'll check in the next days) please feel free to comment on this list.

Would it be possible to include these simple fixes in 1.22.4?

  https://lists.gnu.org/archive/html/groff/2017-02/msg00015.html
  https://lists.gnu.org/archive/html/groff/2017-02/msg00017.html

And maybe also this one; it had a bit of inconclusive disagreement at
the time (though I stand by my view that there's no point bothering with
a C implementation of this build helper when Perl is already in use),
and has a trivial conflict due to spacing changes in a comment but
otherwise still applies:

  https://lists.gnu.org/archive/html/groff/2017-02/msg00014.html

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] Release Candidate 1.22.3.rc1

[Colin Watson]

On Mon, Mar 05, 2018 at 07:55:34PM +0100, Werner LEMBERG wrote:
> Colin Watson wrote:
> > Would it be possible to include these simple fixes in 1.22.4?
> > 
> >   https://lists.gnu.org/archive/html/groff/2017-02/msg00015.html
> >   https://lists.gnu.org/archive/html/groff/2017-02/msg00017.html
> 
> LGTM.
> 
> > And maybe also this one; [...]
> > 
> >   https://lists.gnu.org/archive/html/groff/2017-02/msg00014.html
> 
> LGTM, too.

Thanks for the reviews.  I've pushed all three of these (with obvious
rebasing as needed).

-- 
Colin Watson   [cjwat...@debian.org]

[groff] [PATCH] build: fix out-of-tree builds without dependency tracking

[Colin Watson]

The non-recursive-gnulib-prefix-hack module interacts poorly with
out-of-tree builds: if configure is run with
--disable-dependency-tracking, then nothing creates the out-of-tree
lib directory before running targets such as lib/alloca.h, and the
prefix hack isn't smart enough to insert a mkdir.  The simplest
workaround is to create the directory in configure.

* configure.ac: Create lib directory if needed.
---
 ChangeLog| 13 +
 configure.ac |  8 
 2 files changed, 21 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index 94eaebc..6f996f1 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,18 @@
 2018-03-09  Colin Watson  
 
+   build: fix out-of-tree builds without dependency tracking
+
+   The non-recursive-gnulib-prefix-hack module interacts poorly with
+   out-of-tree builds: if configure is run with
+   --disable-dependency-tracking, then nothing creates the out-of-tree
+   lib directory before running targets such as lib/alloca.h, and the
+   prefix hack isn't smart enough to insert a mkdir.  The simplest
+   workaround is to create the directory in configure.
+
+   * configure.ac: Create lib directory if needed.
+
+2018-03-09  Colin Watson  
+
man pages: fix incorrect cross-referenced section
 
* man/roff.7.man (FILE NAME EXTENSIONS): Correct reference to
diff --git a/configure.ac b/configure.ac
index f3c4dd0..84953a3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -198,6 +198,14 @@ AM_CONDITIONAL([BUILD_OTHERDOC], [test -n 
"$make_otherdoc"])
 AM_CONDITIONAL([BUILD_EXAMPLES], [test -n "$make_examples"])
 AM_CONDITIONAL([INSTALL_SHIPPED_HTML], [test -n 
"$make_install_shipped_htmldoc"])
 
+# The non-recursive-gnulib-prefix-hack module interacts poorly with
+# out-of-tree builds: if configure is run with
+# --disable-dependency-tracking, then nothing creates the out-of-tree lib
+# directory before running targets such as lib/alloca.h, and the prefix hack
+# isn't smart enough to insert a mkdir.  The simplest workaround is to
+# create the directory here.
+AS_MKDIR_P([lib])
+
 AC_CONFIG_FILES([Makefile])
 AC_CONFIG_FILES([test-groff], [chmod +x test-groff])
 AC_OUTPUT
-- 
2.7.4

[groff] Rename or remove doc/automake_migration_tests.txt?

[Colin Watson]

doc/automake_migration_tests.txt is in git, but it's also removed by
"make distclean", because it matches one of the patterns in the
clean_otherdoc target in doc/doc.am.  This is a bad combination.  If it
is to stay, I'd suggest renaming it to simply
doc/automake_migration_tests, with no extension.

However, this file documented a build system change that is now
essentially complete; the only parts that still seem needed are a couple
of notes on possible future work at the bottom which should probably
live in the top-level TODO file instead.  Should this file simply be
removed?  It can always be retrieved from the git history if anyone
needs it for archaeological purposes.

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] gropdf: failed to load 'download'

[Colin Watson]

On Fri, Mar 09, 2018 at 10:05:32AM +0100, Bernhard Fisseni wrote:
> A question about cleaning: My groff installation directory is still
> mostly `groff-1.22.3.rc1.24-ea225-dirty`, though it was clean (or
> rather: lacking "-dirty") occasionally while recompiling several times
> to compose this reply with the same build instructions.  I rebuilt with:
> 
> $ git reset --hard && git clean -f && make distclean
> $ ./bootstrap && ./configure --with-gs=/usr/bin/gs --prefix=$HOME \
>   && make -j9 install
> 
> Could building be done even less dirty?

The problem I described in
https://lists.gnu.org/archive/html/groff/2018-03/msg00025.html means
that running "./bootstrap" after "make distclean" currently results in
the tree appearing to be dirty.  Either of the fixes I suggested there
would deal with that.

In the meantime, "git checkout -- doc/automake_migration_tests.txt"
after "make distclean" should work around it.

-- 
Colin Watson   [cjwat...@debian.org]

[groff] [PATCH] Remove #! lines from more non-executable files

[Colin Watson]

As with my similar previous patch, these are always invoked using
the necessary interpreter, so the #!  lines were unnecessary, and
caused Debian's `lintian' tool to complain about installed
non-executable scripts.

* contrib/gpinyin/subs.pl: Remove #! line.  Make non-executable.
Fix file position references.
* contrib/groffer/main_subs.pl: Remove #! line.  Fix file position
references.
* contrib/groffer/man.pl: Remove #! line.
* contrib/groffer/split_env.sh: Likewise.
* contrib/groffer/subs.pl: Likewise.
* contrib/groffer/version.sh: Likewise.
* src/roff/grog/subs.pl: Likewise.
---
 ChangeLog| 19 +++
 contrib/gpinyin/subs.pl  |  6 ++
 contrib/groffer/main_subs.pl |  6 ++
 contrib/groffer/man.pl   |  2 --
 contrib/groffer/split_env.sh |  2 --
 contrib/groffer/subs.pl  |  2 --
 contrib/groffer/version.sh   |  2 --
 src/roff/grog/subs.pl|  1 -
 8 files changed, 23 insertions(+), 17 deletions(-)
 mode change 100755 => 100644 contrib/gpinyin/subs.pl

diff --git a/ChangeLog b/ChangeLog
index 4699a22..d5bb0db 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,22 @@
+2018-03-09  Colin Watson  
+
+   Remove #! lines from more non-executable files
+
+   As with my similar previous patch, these are always invoked using
+   the necessary interpreter, so the #!  lines were unnecessary, and
+   caused Debian's `lintian' tool to complain about installed
+   non-executable scripts.
+
+   * contrib/gpinyin/subs.pl: Remove #! line.  Make non-executable.
+   Fix file position references.
+   * contrib/groffer/main_subs.pl: Remove #! line.  Fix file position
+   references.
+   * contrib/groffer/man.pl: Remove #! line.
+   * contrib/groffer/split_env.sh: Likewise.
+   * contrib/groffer/subs.pl: Likewise.
+   * contrib/groffer/version.sh: Likewise.
+   * src/roff/grog/subs.pl: Likewise.
+
 2018-03-09  Deri James  
 
Allow a "." to signify a missing parameter in .pdftransition
diff --git a/contrib/gpinyin/subs.pl b/contrib/gpinyin/subs.pl
old mode 100755
new mode 100644
index 4eb42f4..398baac
--- a/contrib/gpinyin/subs.pl
+++ b/contrib/gpinyin/subs.pl
@@ -1,9 +1,7 @@
-#! /usr/bin/env perl
-
 # gpinyin - European-like Chinese writing 'pinyin' into 'groff'
 
-# Source file position: /contrib/gpinyin/gpinyin.pl
-# Installed position: /bin/gpinyin
+# Source file position: /contrib/gpinyin/subs.pl
+# Installed position: /lib/groff/gpinyin/subs.pl
 
 # Copyright (C) 2014  Free Software Foundation, Inc.
 
diff --git a/contrib/groffer/main_subs.pl b/contrib/groffer/main_subs.pl
index 51bc381..9faa881 100644
--- a/contrib/groffer/main_subs.pl
+++ b/contrib/groffer/main_subs.pl
@@ -1,9 +1,7 @@
-#! /usr/bin/env perl
-
 # groffer - display groff files
 
-# Source file position: /contrib/groffer/subs.pl
-# Installed position: /lib/groff/groffer/subs.pl
+# Source file position: /contrib/groffer/main_subs.pl
+# Installed position: /lib/groff/groffer/main_subs.pl
 
 # Copyright (C) 2006-2015  Free Software Foundation, Inc.
 # Written by Bernd Warken .
diff --git a/contrib/groffer/man.pl b/contrib/groffer/man.pl
index c254deb..ea03b89 100644
--- a/contrib/groffer/man.pl
+++ b/contrib/groffer/man.pl
@@ -1,5 +1,3 @@
-#! /usr/bin/env perl
-
 # groffer - display groff files
 
 # Source file position: /contrib/groffer/man.pl
diff --git a/contrib/groffer/split_env.sh b/contrib/groffer/split_env.sh
index 9d35119..3974bd5 100644
--- a/contrib/groffer/split_env.sh
+++ b/contrib/groffer/split_env.sh
@@ -1,5 +1,3 @@
-#! /bin/sh
-
 # groffer - display groff files
 
 # Source file position: /contrib/groffer/split_env.sh
diff --git a/contrib/groffer/subs.pl b/contrib/groffer/subs.pl
index 12f0260..d1dcc9c 100644
--- a/contrib/groffer/subs.pl
+++ b/contrib/groffer/subs.pl
@@ -1,5 +1,3 @@
-#! /usr/bin/env perl
-
 # groffer - display groff files
 
 # Source file position: /contrib/groffer/subs.pl
diff --git a/contrib/groffer/version.sh b/contrib/groffer/version.sh
index 3235e15..d6c0fee 100644
--- a/contrib/groffer/version.sh
+++ b/contrib/groffer/version.sh
@@ -1,5 +1,3 @@
-#! /bin/sh
-
 # groffer - display groff files
 
 # Source file position: /contrib/groffer/version.sh
diff --git a/src/roff/grog/subs.pl b/src/roff/grog/subs.pl
index db8128b..9ac6176 100644
--- a/src/roff/grog/subs.pl
+++ b/src/roff/grog/subs.pl
@@ -1,4 +1,3 @@
-#! /usr/bin/env perl
 # grog - guess options for groff command
 # Inspired by doctype script in Kernighan & Pike, Unix Programming
 # Environment, pp 306-8.
-- 
2.7.4

[groff] Warning in lj4_font(5)

[Colin Watson]

  $ groff -e -mandoc -Z -wmac -Tutf8 /dev/null
  eqn::122: unquoted escape

\~ in eqn input produces this warning.  It's not clear to me that we get
much benefit from using eqn in this page just for this one somewhat
malformed chunk of input (it also arguably ought to be using "times"
rather than "\[mu]" if it's going to be using eqn anyway).  How about
something like this?  Or is there a better approach?

diff --git a/src/devices/grolj4/lj4_font.5.man 
b/src/devices/grolj4/lj4_font.5.man
index 6e4cf51..6621fa6 100644
--- a/src/devices/grolj4/lj4_font.5.man
+++ b/src/devices/grolj4/lj4_font.5.man
@@ -1,4 +1,3 @@
-'\" e
 .TH LJ4_FONT @MAN5EXT@ "@MDATE@" "Groff Version @VERSION@"
 .SH NAME
 lj4_font \- groff fonts for use with devlj4
@@ -118,10 +117,7 @@ or any combination
 (e.g.,
 2400 and 3175)
 for which
-.EQ
-res\~\[mu]\~unitwidth = 7\|620\|000.
-.EN
-.
+\fIres\fR\~\[mu]\~\fIunitwidth\fR\~=\~7\|620\|000.
 Although HP PCL\~5 LaserJet printers support an internal resolution of
 7200 units per inch,
 they use a 16-bit signed integer for cursor positioning;

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] [PATCH] Remove #! lines from more non-executable files

[Colin Watson]

On Fri, Mar 09, 2018 at 07:44:36PM +, Ralph Corderoy wrote:
> Hi Colin,
> 
> > As with my similar previous patch, these are always invoked using the
> > necessary interpreter, so the #!  lines were unnecessary, and caused
> > Debian's `lintian' tool to complain about installed non-executable
> > scripts.
> ...
> >  contrib/gpinyin/subs.pl  |  6 ++
> >  contrib/groffer/main_subs.pl |  6 ++
> >  contrib/groffer/man.pl   |  2 --
> >  contrib/groffer/split_env.sh |  2 --
> >  contrib/groffer/subs.pl  |  2 --
> >  contrib/groffer/version.sh   |  2 --
> >  src/roff/grog/subs.pl|  1 -
> 
> I realise you're doing the minimally intrusive edit to fix the problem,
> but I've always found these suffixes perverse, and wondered why it's not
> groff.exe, etc., to match.

For actual executables, I entirely agree with you, of course.  An
extension on those requires the user to type additional characters (at
least on Unix; Windows at least has the justification that the user
doesn't have to type the ".exe" part), and it encodes the implementation
in the interface in an inappropriate way that can cause problems later.

The same considerations don't really apply to internal library files,
though, which these are.  If subs.pl were rewritten in Python for some
reason, then groffer would have to do a whole lot more than changing
"require 'subs.pl'" to "require 'subs.py'". :-)  It's useful to have
exactly one of a #! line or a file extension, because they serve the
purpose of cluing editors into which syntax highlighting mode to enable
without the need for embedding editor-specific metadata in the file.
And both .pl and .sh have a long history in their respective communities
of indicating a library file in the relevant language that's loaded by
some means other than fork/exec.  So, for all these reasons, I wouldn't
be in favour of removing the extensions here.

> Is another solution to remove these silly, foreign-platform, suffixes,
> and make the files executable?

For the most part, they definitely shouldn't be executable, because
they're not intended to be executed directly: for example, the Perl
components are libraries loaded using 'require'.  Setting the executable
bit on them would be quite misleading.

There is one possible exception in the above list: split_env.sh is at
least theoretically useful when executed directly, even though groffer
specifically invokes it using 'sh'.  But it's in fact an internal helper
for groffer, so I don't think it really makes sense to suggest that its
executability is part of its interface.

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] Warning in lj4_font(5)

[Colin Watson]

On Sat, Mar 10, 2018 at 09:16:24AM -0500, G. Branden Robinson wrote:
> This one's my fault.  I introduced it in
> a4f9b86065c02f6b2f385c85526a175ab13ae361 on 20 November.  Bag my head.
> 
> I have a patch ready (attached), which is basically yours but uses .IR
> for font-switching instead of embedded font escapes.

Cool, thanks.  Your patch seems reasonable to me.

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] Release Candidate 1.22.3.rc1

[Colin Watson]

On Sun, Mar 11, 2018 at 11:11:20PM +0100, Bertrand Garrigues wrote:
> You can also commit these two:
> 
> https://lists.gnu.org/archive/html/groff/2018-03/msg8.html
> https://lists.gnu.org/archive/html/groff/2018-02/msg00026.html

Thanks.  I've done so now.

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] Release Candidate 1.22.4.rc2

[Colin Watson]

On Thu, Mar 29, 2018 at 08:05:48PM +0200, Ingo Schwarze wrote:
> OpenBSD 6.3 still contains groff-1.22.3p8, we missed the deadline
> for the release, but i will commit the update to OpenBSD-current
> as soon as groff-1.22.4 is officially released, so it will be in
> OpenBSD 6.4 this autumn.

Similarly, I have this RC in Debian experimental and will upload it to
unstable once officially released, so it should be in Debian 10
"buster".  Downstream of that, it's missed the deadline for Ubuntu
18.04, but I expect it to be in Ubuntu 18.10.

-- 
Colin Watson   [cjwat...@debian.org]

[groff] \n[.Y] in release candidates

[Colin Watson]

In groff 1.22.4.rc2:

  $ echo '\n[.Y]' | nroff | grep .
  4.rc2

I can see why this happens, of course; but it seems odd for a number
register to contain non-numeric data.  Would it be better to change this
to chop off the dot and everything after it?

Failing that, can anyone suggest an improved version of this code
emitted by man-db that doesn't trip over this ("(4.rc2 >= 2)" in a
conditional doesn't work and ends up emitting noise to the output)?  I
know that testing versions rather than features isn't great, but I
couldn't find a better method in this case.  The purpose of this code is
to load per-locale macros while disabling warnings of the 'file'
category, in order that we don't need to first test whether the relevant
macro file exists, and to only do this with groff >= 1.20.2 because
otherwise we can't disable the resulting warning.  The appropriate
language code is of course substituted for %s.

  .if (\n[.g] & ((\n[.x] > 1) : ((\n[.x] == 1) & (\n[.y] > 20)) : ((\n[.x] == 
1) & (\n[.y] == 20) & (\n[.Y] >= 2 \{\
  .  warn (\n[.warn] - (\n[.warn] / 1048576 % 2 * 1048576))
  .  mso %s.tmac
  .\}

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] \n[.Y] in release candidates

[Colin Watson]

On Sun, Apr 01, 2018 at 07:34:44AM +0200, Werner LEMBERG wrote:
> And here (hopefully!) a final version that properly takes the `.g'
> flag into account.

Thanks!  I've applied this (with one refinement: I added ".rm Ystring"
to the end, for hygiene).

-- 
Colin Watson   [cjwat...@debian.org]

[groff] [anth...@derobert.net: Bug#892423: man -Tutf8 /usr/share/man/ja/man5/apt_preferences.5.gz (and several others) enter infinite loop]

[Colin Watson]

Hi,

The attached input file, when processed as follows:

  LC_ALL=ja_JP.UTF-8 groff -mtty-char -mandoc -Tutf8 --- Begin Message ---
Package: man-db
Version: 2.8.2-1
Severity: normal

Running:

man -Tutf8 /usr/share/man/ja/man5/apt_preferences.5.gz

starts outputting the manpage, but then at some point switches over to
outputting an (so far as I can tell) infinite loop of newlines:

   sources.list(5) ファイルに列挙された場所から取得した Packages ファイル
   や Release ファイルはすべて、/var/lib/apt/lists ディレクトリ
   や、apt.conf ファイルの Dir::State::Lists 変数で指定した場所に取得され
   ます。例え




Attaching the requested debug output is... difficult, but attached are
the first 100,000 lines:

   man --debug -Tutf8 /usr/share/man/ja/man5/apt_preferences.5.gz |& head -n 
10 | gzip -v9 > /tmp/man-debug.txt.gz

I've also attached the apt_preferences page, just in case you have a
different version of apt; but note that other pages do this too (e.g.,
Japanese dos2unix page).

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'testing'), (200, 'unstable'), (150, 'stable'), (100, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en_GB (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages man-db depends on:
ii  bsdmainutils   11.1.2
ii  debconf [debconf-2.0]  1.5.66
ii  dpkg   1.19.0.5
ii  groff-base 1.22.3-10
ii  libc6  2.27-1
ii  libgdbm5   1.14.1-4
ii  libpipeline1   1.5.0-1
ii  libseccomp22.3.1-2.1
ii  zlib1g 1:1.2.8.dfsg-5

man-db recommends no packages.

Versions of packages man-db suggests:
pn  apparmor
ii  chromium [www-browser]  62.0.3202.89-1
ii  elinks [www-browser]0.12~pre6-13
ii  firefox [www-browser]   58.0.1-1+b1
ii  google-chrome-stable [www-browser]  65.0.3325.146-1
ii  groff   1.22.3-10
ii  konqueror [www-browser] 4:17.08.3-2
ii  less487-0.1
ii  links2 [www-browser]2.14-5
ii  lynx [www-browser]  2.8.9dev16-3
ii  w3m [www-browser]   0.5.3-36

-- debconf information:
  man-db/auto-update: true
* man-db/install-setuid: false


man-debug.txt.gz
Description: application/gzip


apt_preferences.5.gz
Description: application/gzip
--- End Message ---
.mso ja.tmac
.TH "APT_PREFERENCES" "5" "15\ \&8 \[u6708]\ \&2015" "APT 1.6~beta1" "APT"
.nh
.SH "\[u540D]\[u524D]"
apt_preferences \- APT 
\[u7528]\[u9078]\[u629E]\[u5236]\[u5FA1]\[u30D5]\[u30A1]\[u30A4]\[u30EB]
.SH "\[u8AAC]\[u660E]"
.PP
\fBsources.list\fR(5)
\[u30D5]\[u30A1]\[u30A4]\[u30EB]\[u306B]\[u5217]\[u6319]\[u3055]\[u308C]\[u305F]\[u5834]\[u6240]\[u304B]\[u3089]\[u53D6]\[u5F97]\[u3057]\[u305F]
Packages
\[u30D5]\[u30A1]\[u30A4]\[u30EB]\[u3084]
Release
\[u30D5]\[u30A1]\[u30A4]\[u30EB]\[u306F]\[u3059]\[u3079]\[u3066]\[u3001]/var/lib/apt/lists
\[u30C7]\[u30A3]\[u30EC]\[u30AF]\[u30C8]\[u30EA]\[u3084]\[u3001]apt\&.conf
\[u30D5]\[u30A1]\[u30A4]\[u30EB]\[u306E]
Dir::State::Lists
\[u5909]\[u6570]\[u3067]\[u6307]\[u5B9A]\[u3057]\[u305F]\[u5834]\[u6240]\[u306B]\[u53D6]\[u5F97]\[u3055]\[u308C]\[u307E]\[u3059]\[u3002]\[u4F8B]\[u3048]\[u3070]\[u3001]debian\&.lcs\&.mit\&.edu_debian_dists_unstable_contrib_binary\-i386_Release
'\" t
.\" Title: apt_preferences
.\"Author: [FAMILY Given]
.\" Generator: DocBook XSL Stylesheets v1.79.1 
.\"  Date: 15\ \&8 月\ \&2015
.\"Manual: APT
.\"Source: APT 1.6~beta1
.\"  Language: Japanese
.\"
.TH "APT_PREFERENCES" "5" "15\ \&8 月\ \&2015" "APT 1.6~beta1" "APT"
.\" -
.\" * Define some portability stuff
.\" -
.\" ~
.\" http://bugs.debian.org/507673
.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
.\" ~
.ie \n(.g .ds Aq \(aq
.el   .ds Aq '
.\" -
.\" * set default formatting
.\" -
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.\" -
.\" * MAIN CONTENT STARTS HERE *
.\" -
.SH "名前"
apt_preferences \- APT 用選択制御ファイル
.SH "説明"
.PP
APT プリファレンスファイル
/etc/apt/preferences
と
/etc/apt/preferences\&.d/
フォルダにある断片ファイルは、インストールするパッケージのバージョンを制御するのに使用します。
.PP
\fBs

Re: [groff] PSPIC vs PDFPIC: adjust documentation to reality, or the reverse?

[Colin Watson]

On Tue, Apr 10, 2018 at 03:57:19PM +0100, Deri James wrote:
> To avoid making existing documents render incorrectly I propose to allow the 
> existing behaviour to be selected. Adding this to the NEWS file:-
> 
> 
> PDFPIC has now been corrected, so the behaviour is the same whether you use 
> the postscript or pdf drivers. However, this means that any documents which 
> were written using the old behaviour will not be rendered correctly if using 
> the pdf driver with the new version.
> 
> The change would mean that documents which relied on the previous behaviour 
> are likely to have a gap underneath the image which was not there before. If 
> you see this effect there are three ways you can restore the previous 
> behaviour (listed in order of priority):-
> 
> A) Add the line ".nr PDFPIC_LEGACY 1" to the document before the first call 
> to 
> .PDFPIC.
> 
> B) If it is just a single document which exhibits this behaviour you can run 
> groff adding "-rPDFPIC_LEGACY=1" to the command-line.

I don't have a specific name suggestion, and I'm aware that this is a
bikeshed, but can I suggest a more explicit variable name?  Otherwise
the next time some old behaviour needs to be switchably deprecated we're
in for some confusion.

(In my third year in college, I lived in "New Court", built in 1825.)

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] groff as the basis for comprehensive documentation?

[Colin Watson]

On Thu, Apr 19, 2018 at 02:28:36AM +0200, Ingo Schwarze wrote:
> Nate Bargmann wrote on Wed, Apr 18, 2018 at 06:52:44PM -0500:
> > I was disappointed that unlike "man" that I find on Slackware or
> > Debian, I had to add an uninstalled man page into the db in order
> > for "mandoc" to open it.  Perhaps I missed an option, but the "man"
> > I'm familiar with is capable of opening a file simply by giving it
> > a path name.
> 
> That is non-standard behaviour even on GNU/Linux:
> 
>$ lsb_release -d
>   Description:Debian GNU/Linux 8.10 (jessie)
>$ dpkg-query -l man-db | tail -n 1
>   ii  man-db 2.7.0.2-5i386 on-line manual pager
>$ ls *.1
>   apropos.1  demandoc.1  man.1  man.options.1  mandoc.1  soelim.1
>$ man apropos.1# the man-db man(1) implementation
>   No manual entry for apropos.1

"man ./apropos.1", as Nate pointed out.  man-db's heuristic is that if
the page name contains a slash then it's surely a path name instead and
should be treated as such; I think that's a reasonable one.

> I think it is good that the '-l' ("local") option is required when
> giving a file name in the local directory, or an absolute path.

I agree that man should not try to guess the difference between a page
name and an unadorned file name in the local directory (with no slash),
but when it's an absolute path or a relative path containing a slash,
the situation seems quite clear.

> Besides, with the mandoc implementation of man(1), it is not
> absolutely required to update the database even after installing a
> new page into /usr/share/man/.

You can also leave out the qualifier clause there: this is true of the
man-db implementation too.  (It used to not be true, but I fixed that
long ago, back in 2002 or so.)

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] groff as the basis for comprehensive documentation?

[Colin Watson]

On Thu, Apr 19, 2018 at 06:48:19PM +0200, Ingo Schwarze wrote:
> Colin Watson wrote on Thu, Apr 19, 2018 at 10:06:28AM +0100:
> > "man ./apropos.1", as Nate pointed out.  man-db's heuristic is that if
> > the page name contains a slash then it's surely a path name instead and
> > should be treated as such; I think that's a reasonable one.
> 
> Thank you for explaining the heuristic and for pointing out the
> missing feature in mandoc.  Given the existence of the -l option,
> having the heuristic is maybe not absolutely required, but i
> agree that it is not unreasonable, and we have seen that the absence
> of the heuristic can confuse casual users who are used to man-db.
> 
> So with the commit below, i added the same heuristic to mandoc.

Thanks.

> By the way, the old version of man-db in jessie exhibits a strange
> behaviour in that case, but probably that has been fixed long ago:
> 
>$ lsb_release -d
>   Description:Debian GNU/Linux 8.10 (jessie)
>$ dpkg-query -l man-db | tail -n 1
>   ii  man-db 2.7.0.2-5i386 on-line manual pager
>$ man --version
>   man 2.7.0.2
>$ man -w man ./man.1
>   man: man-./man.1: No such file or directory
>   man: man_./man.1: No such file or directory
>   /usr/share/man/man1/man.1.gz
>   ./man.1

This is still incorrect in current versions: man(1)'s command-line
parsing is not quite as elegantly well-factored as it ought to be ...  I
don't quite have time to sort it out just now, but I've filed
https://savannah.nongnu.org/bugs/index.php?53708 so that I don't forget
about it.  Thanks for the report!

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] Savannah bug field usage protocol

[Colin Watson]

On Sat, Apr 21, 2018 at 05:43:12PM -0400, G. Branden Robinson wrote:
> At 2018-04-21T14:21:03+0100, Ralph Corderoy wrote:
> > Some projects maintain a `pending' release notes so that significant
> > fixes and changes get added to as they're implemented.  This might avoid
> > the need to keep some bugs non-closed until the release.  Come release,
> > the file's reviewed, some minor things with highsight ditched, and the
> > commit log scanned for anything missing.
> 
> Our commit discipline is already supposed to include updating the
> ChangeLog, and, where appropriate, NEWS files as part of the commit
> where the underlying change is made.  Do you think that should suffice
> for aiding the preparation of Release Notes?

I agree with the sentiment, but do the ~40 lines of NEWS entries since
1.22.3 really reflect the ~1900 lines of ChangeLog for the same period?
I'm not really qualified to prepare updates there, but the ratio seems
unusually low to me.

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] Brian Kernighan on the evoution of eqn, pic, grap, into troff

[Colin Watson]

On Sat, May 05, 2018 at 11:35:14AM +0200, Andreas Eder wrote:
> On Sa 05 Mai 2018 at 01:15, Tadziu Hoffmann  
> wrote:
> > (BTW, most Germans who use it also pronounce it wrong,
> > namely as in "ich" instead of as in "Bach".)
> 
> What do you mean by that? The sound of the 'ch' is the same in both
> cases.

It depends on the dialect, but
https://en.wikipedia.org/wiki/Standard_German_phonology#Ich-Laut_and_ach-Laut
describes the difference in "standard German" - it's essentially about
whether the sound is produced towards the front or back of the mouth.

> 'Andreas ( a german native speaker :-) )

I don't know which dialect you speak; many southern dialects use [x] for
both "ich" and "Bach", rather than [ç] for "ich" and [x] for "Bach".
But as a native English speaker, I can certainly say that there are
aspects of my own language's phonology that weren't obvious to me
without a lot of attention that didn't come automatically!

The Scottish "loch", and hence TeX per Knuth, is indeed pronounced with
the [x] sound.  (In fact, Irish and Scottish Gaelic both have a similar
scheme for pronouncing "ch" as standard German does: if it's surrounded
by front vowels, traditionally called "slender", then it's [ç], while if
it's surrounded by back or "broad" vowels then it's [x].  I don't know
whether the similarity to German is one of common evolution, borrowing,
or just coincidence.)

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] Spooky action at a distance in line adjustment...sometimes

[Colin Watson]

On Wed, Jun 27, 2018 at 12:39:47PM +0100, Ralph Corderoy wrote:
> Hi Doug,
> 
> > But it soon became old hat and people migrated back to ragged right
> > margins, which may not look as neat from afar, but also seem to be
> > easier to read both because of even spacing and because the variable
> > margin provides distinguishablility to help a reader track vertical
> > position on the page.
> 
> Right.  That's why I have `--nj' in the MANOPT environment variable.
> I'm surprised more distributions don't turn off justification by default
> as most users are unaware that man(1) might have a configuration option.
> Colin?

Mostly conservatism, I guess.  I personally prefer full justification in
manual pages, but probably just because I've got used to it over the
years, and I only added the options in 2009
(https://bugs.debian.org/440047).

There's no good (i.e. configuration-file-based) way for a distribution
to change the default.  Could you file a bug report for me as a
reminder?

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] groff build problem

[Colin Watson]

On Sun, Aug 19, 2018 at 02:15:07PM +0200, Heinz-Jürgen Oertel wrote:
> using for the first time now OpenSuse Thumbleweed. Installed all tools (I 
> hope)
> ./configure runs without problems. Had to do:
> sudo ln -sf /usr/bin/aclocal /usr/bin/aclocal-1.13

As well as what other people have said, randomly dropping symlinks into
bits of /usr/ is a bad habit that I strongly recommend you avoid in
future (though I more usually see people attempting this with different
versions of libraries).  I notice that your error message included
mention of aclocal-1.16 as well, which means that the build system has
likely ended up with a mix of different versions of bits of automake,
and that's not going to be healthy.

I'd strongly advise removing /usr/bin/aclocal-1.13 (assuming it was
previously absent) before you do anything else, and then following the
other advice you've had here to rebootstrap the build system properly.

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] [off-topic] Reliable use of errno

[Colin Watson]

On Sun, Aug 19, 2018 at 02:32:49PM +0200, Carsten Kunze wrote:
> Many system calls (e.g. close(2),
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/close.html)
> return 0 on success and -1 on error and set errno.
> 
> My understanding is that errno is only reliably set when the system
> call returns -1, not for < -1 nor for > 0, so I do only check the
> error condition with "if (close(fd) == -1)" ignoring all other values.
> Some are testing for "< 0" but would it not be consequent for them to
> check for "!= 0"? So when can I rely on errno to be set, for -1, for
> "< 0" or for "!= 0"?

These kinds of system calls only ever return 0 or -1, so it doesn't much
matter which way you do the test.

It depends which way you read the implicit gap in the specification; it
explicitly enumerates all the possible return values, but what would any
other return value mean if it could happen?  Writing "== -1" implies a
reading that any other value would indicate success; writing "!= 0"
implies a reading that any other value would indicate an error; writing
"< 0" implies a reading that it depends on the sign of the hypothetical
not-zero-or-minus-one return value.

You could perhaps argue that you ought to explicitly test for some value
other than 0 or -1 and raise some kind of generic error that doesn't
make use of errno in that case; but in practice people don't want to
scatter all this untestable error handling code all over their programs
for a condition that's already specified not to happen, and possibly
printing a stale errno value in a hypothetical situation is a good
trade-off for writing less code (and thus, statistically, fewer bugs).

The "< 0" idiom probably arises from system calls such as read(2), which
return either zero for end-of-file, a positive value for the number of
bytes read on success, or -1 on error.  In that case "< 0" covers all
the return values that aren't defined to be successful.  As a result, my
habit is to use that form for everything that returns -1 on error unless
I have a good reason not to (e.g. if -2 were defined to mean something
else then I'd explicitly test for -1).

In short, you're asking for a specification for unspecified behaviour,
and you aren't going to get one unless the POSIX committee chooses to
clarify it.  But POSIX also says that the other return values you're
concerned about simply don't happen, so I'd suggest just picking
whatever syntax you prefer for testing for the cases that do happen and
moving on.

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] [off-topic] Reliable use of errno

[Colin Watson]

On Sun, Aug 19, 2018 at 03:08:26PM +0100, Ralph Corderoy wrote:
> Hi Colin,
> 
> > Writing "== -1" implies a reading that any other value would indicate
> > success;
> 
> Or it implies it's being coded to the spec.

If your program explicitly handles unspecified return values and handles
those as an error case but without making reference to errno, then you
might have a point, but in practice I've never seen anyone doing this,
probably because it's excessively pedantic and noisy for no real
benefit.

Otherwise, your programming style is implicitly choosing whether you
handle unspecified return values as success or failure; for instance, if
you only handle errors within an "== -1" condition, you're implicitly
saying that unspecified return values are successes.  IME, most
programmers don't care either way, and I would argue they are correct
not to waste brain cells or program text on it.

> > writing "!= 0" implies a reading that any other value would indicate
> > an error; writing "< 0" implies a reading that it depends on the sign
> > of the hypothetical not-zero-or-minus-one return value.
> 
> Both of these allow for more values than -1, `stuttering' the human
> reader, and potentially troubling the static analyser.

Since both the practices in my quoted text above are extremely
widespread, I dispute your unsupported claim that this could trouble
static analysers: any static analyser capable of handling typical C code
must be able to handle both.  (I would be inclined to say the same for
human readers, TBH, although as usual picking one style within a project
and sticking to it is helpful.)

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] gxditview Run by man-db Suffers SIGSYS; core dumped.

[Colin Watson]

On Thu, Aug 30, 2018 at 03:09:30PM +0100, Ralph Corderoy wrote:
> This warren I'm in is John's fault.
> 
> Talking of man-db and gxditview...
> 
> $ pacman -Q man-db groff
> man-db 2.8.4-1
> groff 1.22.3-7
> $ man -X100 core
> groff: gxditview: Signal 31 (core dumped)

Can you send me a bug report about this
(https://savannah.nongnu.org/bugs/?group=man-db or whatever other method
is convenient), ideally with "strace -f" output demonstrating the
failure?  SIGSYS probably has something to do with man-db's seccomp
sandbox, in which I suspect I've shamefully neglected to consider the
gxditview case.

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] improve a few terminal renderings of special characters

[Colin Watson]

On Sat, Sep 01, 2018 at 01:41:04PM +0200, Ingo Schwarze wrote:
>   http://mandoc.bsd.lv/man/man.options.1.html#l

This is an excellent resource that I hadn't seen before.  Thanks for
putting it together.  I'll certainly pay attention to it if I have cause
to add more short options to man-db (although I don't exactly expect
this to be frequent).

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] Release Candidate 1.22.4.rc2

[Colin Watson]

On Tue, Jun 19, 2018 at 12:49:03AM +0200, Bertrand Garrigues wrote:
> I will try now to finish the release now, and I'm currently checking all
> my unread mails.  I've also checked the recent commits and as far as I
> can see, there is no reason not to included them in the next release.

I hate to nag, but is there any likelihood of a 1.22.4 release in the
somewhat near future?  My next relevant deadline is that the freeze for
the next Debian release will begin in January 2019.  It would be good if
it could include a recent version of groff, but I'm not enthusiastic
about pushing in a release candidate.

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] How to show all hyphenation points?

[Colin Watson]

On Thu, Nov 08, 2018 at 09:50:31AM -0500, Doug McIlroy wrote:
> What I see as the typical use is a nonce question about a 
> single word. That is trivially handled by
>   groff -a
>   .ll 1u
>   recapitulation
> The result is marrred with "can't break line" diagnostics,
> but it's quick and intelligible.

This is perhaps me being Captain Obvious, but FWIW adding the -Wbreak
option suppresses those diagnostics.

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] 1.22.4.rc4 - Final RC before official 1.22.4

[Colin Watson]

On Fri, Nov 30, 2018 at 01:00:59AM +0100, Bertrand Garrigues wrote:
> To all the developers: please hold on your commits now, this release is
> for final sanity checks, only critical fixes should be commited from
> now.

I pushed a couple of corrections to error paths in the new
contrib/mom/examples/test-mom.sh.in script.  Not perhaps quite critical,
but since it was only added a week ago and the changes can only possibly
affect "make check" runs that are already about to fail, it seemed
reasonable.

Incidentally, the reason I ran into this was because I was building with
pdfinfo et al installed (having noticed that recent configure.ac change)
but didn't have URW fonts installed, and hadn't noticed the configure
warning.  Now, since this meant that my builds weren't generating the
U-* fonts, it's good that this caused me to notice and fix it.  However,
the reported symptom was as follows:

  Checking number of pages of 
/build/groff-9tRn1u/groff-1.22.4~rc4/debian/build/contrib/mom/examples/typesetting.pdf
Error: expected 3 pages, found 2 pages

This was a pretty opaque symptom, and it took me a little while to find
the real cause.  Should this be reported more clearly, perhaps by having
this test exit 77 (which would cause Automake to produce a SKIP result)
if configure didn't find any URW fonts?  At the moment we have a
supported configuration (configure explicitly tests for URW fonts but
chooses only to issue a warning if they're absent, presumably because
you can use most of groff without them) which then causes the test suite
to fail, which doesn't seem ideal.

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

[groff] gratitude for man pages (was: mom manpage)

[Colin Watson]

I've been staying out of this because I don't really have a position on
it either way; I don't share the apparent position that all
documentation should come in the form of man pages, but I also don't
know enough about mom to have any real idea about what might be best for
it.  But I couldn't resist replying to this bit:

On Tue, Dec 04, 2018 at 03:16:50PM -0500, Peter Schaffter wrote:
> How much a part has the documentation played in her adoption?  Again,
> hard to judge, but users actually thank me for it from time to time.
> (I leave open the question of why mom's documentation inspires
> gratitude where manpages do not.)

I reasonably often get emails from users who have the idea that, because
I happen to maintain an implementation of man(1) that's in some popular
distributions, I'm a good contact point for all the man pages they read.
(I generally try to redirect them as appropriate and as time permits, of
course.)

One pleasant side-effect of this mild confusion is that I get thank-you
letters about man pages in general from time to time.  Here are a few
samples, shorn of any personal information:

  "I've recently started using Ubuntu and I simply wanted to say thank
  you for your continued work on the 'man' pages... they're so helpful
  with getting me up and running with bash commands."

  "I recently switched to linux and my favorite thing so far is the
  vastly informative database of man pages. These man pages have been
  invaluable in my journey to learn more about Linux."

  "Thanks for up-keeping the man page database! I bet you dont get that
  alot so I just wanted to say THANKS!"

(I think most of the gratitude is not really deservedly directed at me,
so I don't feel bad about sharing emails like this in some form.)

I don't wish to set up any kind of competitiveness with mom here; if you
get unsolicited thank-you mails about it, it sounds like it's doing OK!
But my inbox suggests that man pages do in fact inspire quite a bit of
gratitude too, enough that I get a sense of it from just its misdirected
overspill.

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] mom manpage

[Colin Watson]

On Thu, Dec 06, 2018 at 06:38:40PM -0500, Peter Schaffter wrote:
> +@display
> +@file{/usr/share/doc/groff-base/html/mom/toc.html}
> +@end display
[...]
> +@display
> +@file{/usr/share/doc/groff-base/pdf/mom-pdf.pdf}
> +@end display
[...]
> I'm not sure whether it's okay for entry points to local files to
> have literal paths or whether they need to be rendered symbolically
> for build/install purposes, so I won't commit without your go-ahead.

These paths are *very* Debian-and-derivatives-specific (even leaving
aside the hardcoded /usr/share/doc prefix, the split between groff-base
and groff is a Debianism), so they can't be committed upstream like
that.  Either the local references will need to be omitted, or we'll
need some kind of arrangement along the lines of the existing
@HTMLDOCDIR@ and @PDFDOCDIR@ in groff's man pages (I'm not sure how
practical that is in texinfo).

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] GNU troff version 1.22.4

[Colin Watson]

On Mon, Dec 24, 2018 at 11:44:54PM +1100, John Gardner wrote:
> Kudos to everyone's hard work! I did my part
> <https://github.com/Homebrew/homebrew-core/pull/35385>. :-)

And me:

  https://tracker.debian.org/pkg/groff

All the best,

-- 
Colin Watson   [cjwat...@debian.org]

[groff] [akalka...@hotmail.com: Bug#919890: groff-base: Incorrect page numbers position when exporting BSD-style (mdoc) documents to other formats (ps, etc)]

[Colin Watson]

Hi groff@,

Would any mdoc folks like to have a look at this?  Details differ in
1.22.4 and this patch doesn't quite apply directly, but much the same
problem exists; page numbers are printed on the left of odd-numbered
pages and on the right of even-numbered pages, when one would normally
expect the opposite.

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]
--- Begin Message ---
Package: groff-base
Version: 1.22.3-9
Severity: minor
Tags: patch

Dear Maintainer,

I used the following to export man pages (ie ssh_config, written in
mdoc-style) to a pdf file for double-sided printing:
zcat /usr/share/man/man5/ssh_config.5.gz |groff -man -rD1 -Tps - |ps2pdf
- ssh_config.pdf

The page numbers in the resulting pdf file are placed incorrectly.

This does not affect documents written using the "man" format, for example
it will not affect the man.pdf resulting from the following:
zcat /usr/share/man/man1/man.1.gz |groff -man -rD1 -Tps - |ps2pdf
- man.pdf


-- System Information:
Debian Release: 9.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.9.0-8-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages groff-base depends on:
ii  libc6   2.24-11+deb9u3
ii  libgcc1 1:6.3.0-18+deb9u1
ii  libstdc++6  6.3.0-18+deb9u1

groff-base recommends no packages.

Versions of packages groff-base suggests:
pn  groff  

-- no debconf information
@@ -721,7 +721,7 @@
 .setup-page-layout
 .sp \n[footer-space]u
 .ie \n[D] \{\
-.ie o \
+.ie e \
 .tl 
%\*[caption-font2]\*[date-string]\f[]\*[caption-font]\*[operating-system]\f[]
 .el \
 .tl 
\*[caption-font]\*[operating-system]\f[]\*[caption-font2]\*[date-string]\f[]%
--- End Message ---

Re: [groff] [akalka...@hotmail.com: Bug#919890: groff-base: Incorrect page numbers position when exporting BSD-style (mdoc) documents to other formats (ps, etc)]

[Colin Watson]

On Mon, Jan 21, 2019 at 03:04:33PM +0100, Ingo Schwarze wrote:
> Colin Watson wrote on Sun, Jan 20, 2019 at 04:18:29PM +:
> > but much the same problem exists; page numbers are printed on the left
> > of odd-numbered pages and on the right of even-numbered pages,
> 
> Isn't that what one would most often want?  When somebody prints a
> manual page putting two virtual pages side-by-side on each sheet
> in landscape orientation, then page 1 ends up on the left side and
> page 2 on the right side of the first sheet, so the odd numbers
> should be on the left, as indeed they are.
[...]
> Maybe we should change the man macros rather than the mdoc macros?

I don't think I have any stake in this either way, except that man and
mdoc should be mutually-consistent, and IMO we should document the
choice made in both groff_man(7) and groff_mdoc(7) with a brief comment
on the rationale to head off future questions.

-- 
Colin Watson   [cjwat...@debian.org]

[groff] [vinc...@vinc17.net: Bug#920269: groff: gropdf can execute arbitrary commands]

[Colin Watson]

Hi,

I'm not quite sure of the circumstances in which an attacker (presumably
the author of a document you've received) might be able to control the
arguments to gropdf; but regardless, this does seem to be undesirable
command-line handling and I think we should fix it.

  $ find -name \*.pl | xargs grep -- '<>'
  ./src/devices/gropdf/gropdf.pl:while (<>)
  ./src/devices/gropdf/gropdf.pl: my $lin=<>;
  ./tmac/hyphenex.pl:while (<>) {
  ./contrib/gpinyin/gpinyin.pl:foreach (<>) { # get line from input
  ./contrib/gperl/gperl.pl:foreach (<>) {
  ./contrib/glilypond/glilypond.pl: LILYPOND: foreach (<>) {
  ./contrib/glilypond/glilypond.pl:  } # end foreach <>

What I'm not quite sure of is what the best fix would be, since my Perl
is a bit rusty.  Perl >= 5.20 has the safer <<>> operator, which only
interprets file names, but I don't know whether it would be acceptable
to bump groff's minimum Perl version from its current value of 5.6.1.
In my own wheelhouse, that would drop support for everything up to and
including Debian 7 (currently oldoldstable) and Ubuntu 14.04 (which goes
out of regular support this April), which does include some stuff that
we'd want to issue security updates for, so maybe that isn't the best
option.

Alternatively, perhaps we could just copy ARGV::readonly from CPAN into
the start of all our Perl scripts?  It's sufficiently small that it
might not be worth getting too worked up about the code duplication:

  https://metacpan.org/source/DAVIDNICO/ARGV-readonly-0.01/lib/ARGV/readonly.pm

Any other ideas welcome.

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]
--- Begin Message ---
Package: groff
Version: 1.22.4-2
Severity: grave
Tags: security
Justification: user security hole

According to the gropdf(1) man page:

   gropdf [-dels] [-F dir] [-I dir] [-p paper-size] [-u [cmapfile]]
  [-y foundry] [file ...]

but providing a "filename" with a pipe character can yield an
arbitrary command execution:

$ touch foo
$ ls foo
foo
$ gropdf "rm foo|"
$ ls foo
ls: cannot access 'foo': No such file or directory
$ 

The reason is that gropdf is a Perl script that uses the insecure
null filehandle "<>". The perlop(1) man page says:

  Since the null filehandle uses the two argument form of "open" in
  perlfunc it interprets special characters, so if you have a script like
  this:

  while (<>) {
  print;
  }

  and call it with "perl dangerous.pl 'rm -rfv *|'", it actually opens a
  pipe, executes the "rm" command and reads "rm"'s output from that pipe.

BTW, I fear that's not the only Perl script that is affected by such
a bug.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-1-amd64 (SMP w/12 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages groff depends on:
ii  groff-base  1.22.4-2
ii  libc6   2.28-5
ii  libgcc1 1:8.2.0-14
ii  libice6 2:1.0.9-2
ii  libsm6  2:1.2.2-1+b3
ii  libstdc++6  8.2.0-14
ii  libx11-62:1.6.7-1
ii  libxaw7 2:1.0.13-1+b2
ii  libxmu6 2:1.1.2-2
ii  libxt6  1:1.1.5-1

Versions of packages groff recommends:
ii  ghostscript  9.26~dfsg-0+deb9u2
ii  imagemagick  8:6.9.10.23+dfsg-2
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2
ii  libpaper11.1.26
ii  netpbm   2:10.0-15.3+b2
ii  perl 5.28.1-3
ii  psutils  1.17.dfsg-4

groff suggests no packages.

-- no debconf information


--- End Message ---

Re: [groff] Bug#920269: [vinc...@vinc17.net: Bug#920269: groff: gropdf can execute arbitrary commands]

[Colin Watson]

On Wed, Jan 23, 2019 at 03:21:53PM +0100, Jakub Wilk wrote:
> * Colin Watson , 2019-01-23, 13:56:
> > Perl >= 5.20 has the safer <<>> operator,
> 
> It was actually added only in Perl 5.22.

Sorry, indeed so - I grepped the perl*delta man pages for it but misread
"5220" as "5200".  So this option would also lose support for Debian 8
(currently oldstable).

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] Bug#920269: Bug#920269: [vinc...@vinc17.net: Bug#920269: groff: gropdf can execute arbitrary commands]

[Colin Watson]

On Wed, Jan 23, 2019 at 03:02:26PM +, Ralph Corderoy wrote:
> Hi Colin,
> 
> > So this option would also lose support for Debian 8 (currently
> > oldstable).
> 
> Also, `<<>>' doesn't support `-' to mean stdin.
> That might affect users of the groff Perl scripts that use `<>'.

Ah, yes - in that case I agree that that isn't a good option.

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] UTF8 characters to pdf

[Colin Watson]

On Thu, Jan 24, 2019 at 05:05:25AM +, jonathan ahumada wrote:
> I’m trying to get into groff  with the hopes that I could print my own
> literary drafts. However, I write in spanish and have had problems
> with accented characters such as (á, é, ó , etc). I have been
> searching and apparently groff doesn’t support utf-8, which is the
> format my files are written in. I have seen some people use a
> `preconv`command or a `-k` flag to convert their files for utf-8 into
> latin1 within the groff command.

Sort of; it preprocesses UTF-8 into ASCII plus \[u] escapes.  Using
preprocessors to transform the input in various ways is a routine
practice in groff.

On the phrasing in your last couple of sentences, I would rather say
that groff supports UTF-8, but only via preconv (which is part of
groff).

> But the build I have on my Mac computer doesn’t seem to have this
> (version 1.19.2).

Yeah, that is pretty prehistoric; groff 1.20 was released a full ten
years ago, and the current release is 1.22.4.  I'd really recommend you
try upgrading.

I'm not a Mac user so I don't know which you might prefer or what the
tradeoffs are, but MacPorts has 1.22.3 and Homebrew has 1.22.4.  Perhaps
you might try installing a newer version of groff from one of those?

> I know you can use escape sequences in order to tell the troff
> formatter to use certain characters, but modifying my files with a
> sort of tailored script to replace all my accents seems burdensome. 

You wouldn't actually modify your files, but just have the build script
you use to render them add the -k option.

-- 
Colin Watson   [cjwat...@debian.org]

[groff] [PATCH] Avoid Perl's unsafe "<>" operator

[Colin Watson]

The "<>" operator is implemented using the two-argument form of "open",
which interprets magic such as pipe characters, allowing execution of
arbitrary commands which is unlikely to be expected.  Perl >= 5.22 has a
"<<>>" operator which avoids this, but also forbids the use of "-" to
mean the standard input, which is a facility that the affected groff
programs document.

ARGV::readonly would probably also fix this, but I fundamentally dislike
the approach of escaping data in preparation for a language facility to
unescape it, especially when the required escaping is as non-obvious as
it is here.  (For the same reason, I prefer to use subprocess invocation
facilities that allow passing the argument list as a list rather than as
a string to be interpreted by the shell.)  So I've abandoned this
dubious convenience and changed the affected programs to iterate over
command-line arguments manually using the three-argument form of open.

This change involves an extra level of indentation, so it's a little
awkward to review.  It consists of changing this form:

  while (<>) {  # or foreach, which is similar but less efficient
...
  }

... into this:

  unshift @ARGV, '-' unless @ARGV;
  foreach my $filename (@ARGV) {
my $input;
if ($filename eq '-') {
  $input = \*STDIN;
} elsif (not open $input, '<', $filename) {
  warn $!;
  next;
}
while (<$input>) {
  ...
}
  }

Local variations: glilypond doesn't need the initial unshift since
that's already handled in contrib/glilypond/args.pl; gropdf declares
$input in a slightly different way since it's also used in the LoadAhead
function.

Fixes: https://bugs.debian.org/920269
---
 contrib/glilypond/glilypond.pl | 128 +++---
 contrib/gperl/gperl.pl | 188 +
 contrib/gpinyin/gpinyin.pl |  88 ---
 src/devices/gropdf/gropdf.pl   |  99 +
 tmac/hyphenex.pl   |  86 ---
 5 files changed, 318 insertions(+), 271 deletions(-)

diff --git a/contrib/glilypond/glilypond.pl b/contrib/glilypond/glilypond.pl
index 868801b2..f2a76158 100755
--- a/contrib/glilypond/glilypond.pl
+++ b/contrib/glilypond/glilypond.pl
@@ -565,73 +565,81 @@ our $Read =
 ); # end definition %lilypond_args
 
 
- LILYPOND: foreach (<>) {
-chomp;
-my $line = $_;
+ LILYPOND: foreach my $filename (@ARGV) {
+my $input;
+if ($filename eq '-') {
+  $input = \*STDIN;
+} elsif (not open $input, '<', $filename) {
+  warn $!;
+  next;
+}
+while (<$input>) {
+  chomp;
+  my $line = $_;
 
 
-# now the lines with '.lilypond ...'
+  # now the lines with '.lilypond ...'
 
-if ( /
-  ^
-  [.']
-  \s*
-  lilypond
-  (
-.*
-  )
-  $
-/x ) { # .lilypond ...
-  my $args = $1;
-  $args =~ s/
- ^
- \s*
-   //x;
-  $args =~ s/
- \s*
- $
-   //x;
-  $args =~ s/
- ^
- (
-   \S*
- )
- \s*
-   //x;
-  my $arg1 = $1; # 'start', 'end' or 'include'
-  $args =~ s/["'`]//g;
-  my $arg2 = $args; # file argument for '.lilypond include'
-
-  if ( exists $lilypond_args{$arg1} ) {
-   $lilypond_args{$arg1}->($arg2);
-   next;
-  } else {
-   # not a suitable argument of '.lilypond'
-   $stderr->print( "Unknown command: '$arg1' '$arg2':  '$line'" );
-  }
-
-  next LILYPOND;
-} # end if for .lilypond
+  if ( /
+^
+[.']
+\s*
+lilypond
+(
+  .*
+)
+$
+  /x ) { # .lilypond ...
+   my $args = $1;
+   $args =~ s/
+   ^
+   \s*
+ //x;
+   $args =~ s/
+   \s*
+   $
+ //x;
+   $args =~ s/
+   ^
+   (
+ \S*
+   )
+   \s*
+ //x;
+   my $arg1 = $1; # 'start', 'end' or 'include'
+   $args =~ s/["'`]//g;
+   my $arg2 = $args; # file argument for '.lilypond include'
+
+   if ( exists $lilypond_args{$arg1} ) {
+ $lilypond_args{$arg1}->($arg2);
+ next;
+   } else {
+ # not a suitable argument of '.lilypond'
+ $stderr->print( "Unknown command: '$arg1' '$arg2':  '$line'" );
+   }
 
+   next LILYPOND;
+  } # end if for .lilypond
 
-if ( $lilypond_mode ) { # do lilypond-mode
-  # see '.lilypond start'
-  $ly->print( $line );
-  next LILYPOND;
-} # do lilypond-mode
 
-# unknown line without lilypond
-unless ( /
-  ^
-  [.']
-  \s*
-  lilypond
-/x ) { # not a '.lilypond' line
- 

Re: [groff] [PATCH] Avoid Perl's unsafe "<>" operator

[Colin Watson]

On Thu, Jan 24, 2019 at 03:38:38PM +, Deri wrote:
> Have you seen:-
> 
> https://savannah.gnu.org/bugs/?7
> 
> Perhaps the patch could be uploaded there?

Thanks, I hadn't seen that.  Done.

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] UTF8 characters to pdf

[Colin Watson]

On Fri, Jan 25, 2019 at 02:10:32AM +1100, John Gardner wrote:
> There was an attempt to get man-db
> <https://github.com/Homebrew/homebrew-core/pull/25376> accepted in
> Homebrew, but a patch was needed for macOS support, which Homebrew required
> upstream to accept before they'd support it.

FWIW, this was gnulib upstream, not man-db / libpipeline upstream (i.e.
me).

If somebody could point me to where I could get SSH access to a macOS
box with the right set of build tools installed, I'd be happy to try to
get it working properly.

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] UTF8 characters to pdf

[Colin Watson]

On Thu, Jan 24, 2019 at 04:21:51PM +, Colin Watson wrote:
> On Fri, Jan 25, 2019 at 02:10:32AM +1100, John Gardner wrote:
> > There was an attempt to get man-db
> > <https://github.com/Homebrew/homebrew-core/pull/25376> accepted in
> > Homebrew, but a patch was needed for macOS support, which Homebrew required
> > upstream to accept before they'd support it.
> 
> FWIW, this was gnulib upstream, not man-db / libpipeline upstream (i.e.
> me).
> 
> If somebody could point me to where I could get SSH access to a macOS
> box with the right set of build tools installed, I'd be happy to try to
> get it working properly.

We got this sorted out so that libpipeline and man-db build without
patches in Homebrew:

  https://github.com/ylluminarious/homebrew-man-db/issues/1

However, the original submitter is reluctant to submit these formulae to
the Homebrew maintainers again due to their earlier conflict (see the
end of that issue).  I'm not a good person to do it since I don't use a
Mac.  Would anyone who uses a Mac and is reasonably Homebrew-literate
like to pick this up?  I don't think the conflict should recur since the
upstream build is clean now, and I'd be happy to do whatever other
upstream support is needed.

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] UTF8 characters to pdf

[Colin Watson]

On Mon, Jan 28, 2019 at 07:59:00PM +1100, John Gardner wrote:
> *> Would anyone who uses a Mac and is reasonably Homebrew-literate like to
> pick this up?*
> 
> Done! See https://github.com/Homebrew/homebrew-core/pull/36469 (I CC'd you
> on GitHub anyway)

Thanks!

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] [patch] modernize -T ascii rendering of opening single quote

[Colin Watson]

On Sat, Feb 02, 2019 at 05:57:31PM +0100, Ingo Schwarze wrote:
> Ralph Corderoy wrote on Sat, Feb 02, 2019 at 02:59:21PM +:
> > Ingo Schwarze wrote:
> >> It doubt that the benefit of avoiding the ugly ` ' in ASCII output is
> >> worth these (at least) three downsides.
> 
> > Whom is this change is meant to benefit?  I've lost track.
> 
> People reading roff(7) documents with nroff(1) or man(1) in a terminal
> window while they have LC_CTYPE=C set and while they are using a modern
> font.

One common real-world example I'd offer would be anyone who has a modern
terminal/font/etc. setup locally but who is reading a man page while
SSHed into a server that doesn't have a matching locale (it's not at all
unusual for me to find that en_GB.UTF-8 hasn't been generated on some
server or other).  Unfortunately we don't have a robust mechanism for
sshd to pick some other suitable locale that at least has a matching
encoding, and the details of this would no doubt be difficult to define
anyway; so the upshot is that somebody in this situation ends up with
the equivalent of LC_ALL=C on the remote system even though they
normally prefer UTF-8 locally.

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] Loss of MSVC support

[Colin Watson]

On Wed, Feb 13, 2019 at 06:58:18PM +0200, Eli Zaretskii wrote:
> Just to make what Keith says (and I concur) crystal clear: there's a
> need to distinguish between C99 compliance of the compiler and the
> C99/Posix compliance of the C runtime.  We can assume the former,
> certainly when using MinGW GCC, but we cannot assume the latter when
> building a native MS-Windows port (as opposed to Cygwin port) of
> Groff.

If it's just the runtime, then Gnulib should be able to paper over a
pretty fair number of the differences, and groff already uses that.  It
may just be a matter of somebody who can do test-builds on Windows
making sure that we're importing the right set of Gnulib modules.

(It's possible that some of the _WIN32 conditionals can be supplied by
Gnulib these days, but there's also no great urgency to remove them,
IMO.)

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] Loss of MSVC support

[Colin Watson]

On Thu, Feb 14, 2019 at 07:30:13PM +0200, Eli Zaretskii wrote:
> > Date: Thu, 14 Feb 2019 12:50:09 +
> > From: Colin Watson 
> > 
> > If it's just the runtime, then Gnulib should be able to paper over a
> > pretty fair number of the differences, and groff already uses that.
> 
> Up to a degree.  There's no fork for Windows, for example, and many
> other functions are missing.

Yeah, I'm not saying it'll cover everything, but it doesn't have to
cover everything to be an improvement.

Gnulib also doesn't operate simply in terms of one-to-one function
replacement; for example, it does already provide some process-spawning
functions that are implemented in terms of Windows or Unix APIs as
appropriate, although I haven't looked into whether they'd meet groff's
requirements.

> > (It's possible that some of the _WIN32 conditionals can be supplied by
> > Gnulib these days, but there's also no great urgency to remove them,
> > IMO.)
> 
> I doubt that.  The vast majority of those I see in the current sources
> deal with issues that Gnulib cannot fix:

Hmm.  Most of the ones you mention look like things that appear to be
either very much fixed by Gnulib or at least tractable.

>   . absence of SIGPIPE

  
https://www.gnu.org/software/gnulib/manual/html_node/signal_002eh.html#signal_002eh
  https://www.gnu.org/software/gnulib/MODULES.html#module=sigpipe

(groff is actually doing something a bit more complicated involving
error detection on an output stream, but I wouldn't want to bet that
Gnulib couldn't handle it, perhaps via something like the "fwriteerror"
module.)

>   . backslashes as directory separators

This ifdef could probably be eradicated using:

  https://www.gnu.org/software/gnulib/MODULES.html#module=filename

Also, one of the relevant #ifdefs is in
src/libs/libgroff/localcharset.c, which seems to be a somewhat old copy
of https://www.gnu.org/software/gnulib/MODULES.html#module=localcharset;
using the latter would likely make it easier to keep up to date.

>   . differences in how argv[0] is presented to 'main'

I haven't found the bit of groff you're referring to here, but it sounds
like the sort of thing that Gnulib could fix if its "getprogname" module
were ported.

>   . different names of environment variables, like TEMP vs TMPDIR

Gnulib doesn't handle this today, but it's clear that it could if the
package using it were using something like the "tmpfile" module.

>   . quoting of command arguments 'like this' that isn't supported on
> Windows

This seems like:

  https://www.gnu.org/software/gnulib/MODULES.html#module=system-quote


I appreciate this may seem like pedantry, but people who care about
portability to a given platform should actively prefer things like this
to be handled by a portability library wherever possible, because then
it's easier to apply them to more packages.  Further, reducing the
forest of #ifdefs makes it easier to follow the essential logic of the
application code rather than having to wade through platform minutiae
when not actually doing porting work.

Importing more modules from Gnulib is typically a matter of adding them
to gnulib_modules in bootstrap.conf and rerunning ./bootstrap, so it
should be quite an accessible thing for somebody to try who has access
to both Windows and non-Windows test platforms and wants to try to
reduce the Windows support burden in groff.

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] Upgrade to 1.22.4 breaks PDF font

[Colin Watson]

On Tue, Feb 19, 2019 at 05:00:43PM +, Richard Morse wrote:
> Hi! I just upgraded to groff 1.22.4, and suddenly my files are not
> turning into PDFs properly. The error is "can't find font NR" (and
> "NI"). This is on Mac OS X 10.13, with the groff installed by
> Homebrew.
> 
> Looking at /usr/local/share/groff/1.22.4/font/devpdf, especially when
> comparing it with devps, shows that there are many fewer fonts for the
> PDF than for the PS device (which I don't think is supposed to
> happen). The "NR" and "NI" fonts were definitely there in 1.22.3.

It's likely that this is a bug in the Homebrew formula: you can confirm
this by looking for "URW fonts for pdf" in the configure output (it
should say "yes", but I bet it says "no").  The formula needs to make
sure that whatever provides a010013l.pfb is installed when groff is
built.

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] [PATCH] Avoid Perl's unsafe "<>" operator

[Colin Watson]

On Thu, Jan 24, 2019 at 02:34:35PM +, Colin Watson wrote:
> The "<>" operator is implemented using the two-argument form of "open",
> which interprets magic such as pipe characters, allowing execution of
> arbitrary commands which is unlikely to be expected.  Perl >= 5.22 has a
> "<<>>" operator which avoids this, but also forbids the use of "-" to
> mean the standard input, which is a facility that the affected groff
> programs document.
[...]

Has anyone had a chance to review this patch (also in
https://savannah.gnu.org/bugs/?7, after Deri's suggestion)?  Should
I just go ahead and commit it?

I'm going to upload this patch to Debian unstable shortly in the cause
of getting release-critical bug fixes in ahead of our upcoming full
freeze, but it would be better to get it into upstream as well.

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] [PATCH] Avoid Perl's unsafe "<>" operator

[Colin Watson]

Thanks for the review.

On Fri, Mar 01, 2019 at 04:41:36PM +, Deri wrote:
> On Thursday, 28 February 2019 19:42:45 GMT Colin Watson wrote:
> > On Thu, Jan 24, 2019 at 02:34:35PM +0000, Colin Watson wrote:
> > > The "<>" operator is implemented using the two-argument form of "open",
> > > which interprets magic such as pipe characters, allowing execution of
> > > arbitrary commands which is unlikely to be expected.  Perl >= 5.22 has a
> > > "<<>>" operator which avoids this, but also forbids the use of "-" to
> > > mean the standard input, which is a facility that the affected groff
> > > programs document.
> > 
> > [...]
> > 
> > Has anyone had a chance to review this patch (also in
> > https://savannah.gnu.org/bugs/?7, after Deri's suggestion)?  Should
> > I just go ahead and commit it?
> > 
> > I'm going to upload this patch to Debian unstable shortly in the cause
> > of getting release-critical bug fixes in ahead of our upcoming full
> > freeze, but it would be better to get it into upstream as well.
> 
> Hi Colin,
> 
> There appear to be a lot of extra changes in the patch which are not to do 
> with what we are trying to fix.

No, despite appearances there are no unrelated changes here.  I
explained what's going on in detail in the patch's commit message:
because my change involves introducing an extra level of indentation, it
looks like there's a lot going on when you look at the raw patch, but
the commit message explains the actual effective changes, and if you
apply it to a local branch and use something like "git show -b" you
should see something that's easier to review.

> There may also be a problem with the gropdf patch. One aspect of using "<>" 
> is 
> that if there are multiple files on the command line an eof is not signalled 
> between the files, i.e. after reading the last line of the first file the 
> next 
> read will be the first line of the next file. This may not have an impact but 
> the read in the LoadAhead subroutine may be done on a file which is at eof, 
> rather than the first line of the next file. I admit this may not cause an 
> issue in normal operation but is a change in behaviour.

Hm, OK.  Could you suggest some example input that I can use to provoke
this?  gropdf is the only groff program that splits up the input reading
in such a way as to have this kind of problem, but I'd be happy to try
to work out a fix given a test case.

> I prefer the first solution you suggested, upon which my code was based, 
> because there will be no change of behaviour. I have been unable to find a 
> way 
> of defeating this protection method to make "<>" safe. Do you know of a way 
> to 
> circumvent it?

I don't have a specific way to circumvent it, and it may well be correct
in most cases.  It's true that it's an easier change.  However, I think
the phrasing of your question puts the burden of proof in the wrong
place.  The problem at hand is that argument handling is more magical
than expected.  Can you *prove* (not just by absence of evidence) that
the approach of pre-escaping @ARGV effectively disables the dangerous
parts of <>'s magic in the fact of arbitrary malicious arguments,
ensuring that each argument is only ever interpreted as a file of the
exact same name, or standard input in the case of "-"?  Is such a proof
likely to be robust against future innocent changes to the code by
people who don't remember this thread?  Perl's "open" documentation even
notes for the "< $file\0" trick that "this may not work on some bizarre
filesystems", which suggests to me that such a robust proof isn't
possible.

What we have here is a particularly magical (in the sense often used by
the Perl documentation) language facility with an assortment of special
behaviours, and we're trying to come up with ways to add extra
characters to its input that suppress that magic.  I argue that - if
we're trying to construct a secure system, which I hope we are - this is
fundamentally the wrong approach.  It's instead much better to use
language facilities that don't have these magical behaviours in the
first place.  This is true even if it takes a little extra effort to
come up with something that exactly matches the subset of the magical
behaviours that we actually want, because then at least our uses of
those behaviours will be explicit and we'll be able to understand them.

An analogy: by now it's fairly well-understood that Perl programmers
should avoid "system $string" (which passes $string to "sh -c") and
prefer "system @list

Re: [groff] [PATCH] Avoid Perl's unsafe "<>" operator

[Colin Watson]

On Sun, Mar 03, 2019 at 01:21:49PM +, Ralph Corderoy wrote:
> Hi Colin,
> 
> > Perl's "open" documentation even notes for the "< $file\0" trick that
> > "this may not work on some bizarre filesystems", which suggests to me
> > that such a robust proof isn't possible.
> 
> No, that's a misquote.
> 
>   $file =~ s#^(\s)#./$1#;
>   open(my $fh, "< $file\0")
>   || die "Can't open $file: $!";
> 
> (this may not work on some bizarre filesystems).
> 
> The `bizarre' bit is referring to non-POSIX filesystems that don't like
> `./' as a prefix for the current directory.

Thanks for the correction (I would say it was a misreading rather than a
misquote, since it genuinely wasn't clear to me).

It's true that the ./ part doesn't need to be considered in our case.

> > we're trying to come up with ways to add extra characters to its input
> > that suppress that magic.
> 
> We're using the method described in documentation written by Tom
> Christiansen and his pedigree says to me that's sufficient.  I agree in
> general one looks for a certain way to be safe, but this seems the
> accepted Perl idiom.

Tom indeed has a fine pedigree, but even very competent people can be
wrong, which is why I look for convincing proofs instead.  To be honest,
even with a proof I think I would still prefer my manual construction,
since it requires less effort to convince oneself that it's safe.

> 
> https://groups.google.com/forum/message/raw?msg=comp.lang.perl.misc/0tqkwns3aaw/auWXakdD1S0J
> 
> If magic `open' is a bit too magical for you, you don't have to turn
> to `sysopen'.

It's worth noting that Tom posted this in 1999, which was before the
three-argument form of open was introduced in Perl 5.6 (March 2000).
Nowadays it would be strange (perhaps even a strawman) to make this
argument, because if "magic" two-argument open is too magical for you,
then the obvious next thing to use is the non-magical three-argument
open, not sysopen.

So, even if that document from 1999 remains authoritative on how to
perform safe escaping, I don't think it's any longer authoritative on
style.  The modern perlopentut(1) still carries Tom's copyright notice
(now from 2013) and doesn't mention the two-argument form of open at
all; that's been relegated to more detailed reference documentation.

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] [patch] do not strip mdoc macros

[Colin Watson]

On Thu, Mar 14, 2019 at 12:43:53PM -0400, Doug McIlroy wrote:
> Bjarni Ingi Gislason wrote:
> > It is objectively correct to strip the macro files of bytes that are
> > meaningless for the program "groff"
> >
> > It is objectively correct to _not_ strip the macro files of bytes
> > that have a meaning for humans.
> >
> > So provide both versions.
> 
> The conclusion is compatible with the premises but doesn't 
> follow from them.
> 
> For human consumption, the comments are desirable. For machine
> consumption the comments are harmless. So there is no compelling
> need for the latter. For maintainability and intelligibility of
> the groff distro, smaller is better.

Quite.

It would follow from Bjarni's argument, if accepted, that it is
objectively correct (a strong claim!) to install programs in scripting
languages on user systems only after first stripping comments from them
(or perhaps even only after also running them through a compiler, where
available).  Now, there certainly are people who take that position; but
it is very far from being the dominant or accepted position at least in
free software circles, much less something that one can claim with a
straight fact to be "objectively correct".

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] 04/05: {g, n}roff.1.man: Give assistance to pager users.

[Colin Watson]

On Wed, Jul 03, 2019 at 11:39:32AM +1000, John Gardner wrote:
> I've lost the link, but I remember somebody got hold of a hard-copy
> terminal somehow and used it to display his Twitter's newsfeed by threading
> output through a serial port hooked up to his Linux workstation.
> 
> The output wasn't much to look at, but the effort somebody went to to
> connect two technologies invented 50 years apart was seriously inspiring.

In university we did a group project to build an EDSAC emulator, as part
of the Cambridge Computer Lab's celebrations of the 50th anniversary of
EDSAC's first running programs.  (This is probably enough information to
deduce my age quite accurately: I suspect younger than many here.)

When the original machine was built, debuggers weren't a thing yet, so
as a small affordance for users they connected a speaker to the
accumulator, and for example when you ran the prime-listing program you
could reportedly hear it counting off the rhythm of the primes.  As far
as we could tell nobody had ever made a recording of this, so we could
only guess at what it might have sounded like, but we certainly wanted
this feature in our emulator, even though this was a thing written 50
years later by a bunch of second-years in Java with only the most
tenuous connection to the original.

Best guess: shove the bits out what amounted to a serial port connected
to the sound card and cross our fingers, and it was enough to be able to
likewise hear the primes being counted off.  We eventually got somebody
who'd worked on the original machine to come and listen to it: he told
us that it really sounded nothing like the original but it clearly
fulfilled the same purpose.  Good enough for us considering what we had
to work with.

-- 
Colin Watson   [cjwat...@debian.org]

Re: [groff] Getting refer to pass through special Unicode characters

[Colin Watson]

On Tue, Sep 24, 2019 at 02:21:29PM +, Dorai Sitaram via groff wrote:
> I have some some Unicode characters with codes higher than 256 (e.g.,
> smart quotes) that 'refer' chokes on with the message "invalid input
> character code".  
> Is there a way to tell refer to just pass them through to stdout? The
> error happens even if the offending characters don't occur inside the
> refer-specific .[ and .] or in the bibliography database. They are
> just in the "surrounding" text that isn't relevant to refer anyway.

troff itself does this too, doesn't it?  I think the way you're supposed
to handle this at the moment is to run preconv before other
preprocessors, including refer.

-- 
Colin Watson   [cjwat...@debian.org]

Re: Two questons: Norwgegian characters and space when switching typeface

[Colin Watson]

On Mon, Nov 04, 2019 at 01:31:06AM -0800, Dale Snell wrote:
> For the Norwegian characters, you'll need to use constructions like "\[o/]"
> and "\[ae]".

Alternatively, run your input file through "preconv" as the first
preprocessor.

-- 
Colin Watson   [cjwat...@debian.org]

Re: Error in bootstrap

[Colin Watson]

On Tue, Nov 05, 2019 at 12:31:45PM -0600, Blake McBride wrote:
> While trying to build the latest git repo on a 64 bit Linux machine, I get
> the following when running bootstrap:
> 
> contrib/mom/mom.am:109: error: 'nodist_momprocessedexample_DATA' is used
> but 'momprocessedexampledir' is undefined

Thanks for your report.  This was a clear typo in
https://git.savannah.gnu.org/cgit/groff.git/commit/?id=e80baeaf2654feee6e69c489ea763d11968153aa,
so I went ahead and pushed a fix:

  
https://git.savannah.gnu.org/cgit/groff.git/commit/?id=da42ae7cf8d36fb689f5109dbdcb72b074b99517

CCing Peter, FYI.

-- 
Colin Watson   [cjwat...@debian.org]

Re: Problem with configure

[Colin Watson]

On Tue, Nov 05, 2019 at 12:39:21PM -0600, Blake McBride wrote:
> I am attempting to build the latest rpo copy of groff on 64-bit LinuxMint
> 19.2.  I am running:
> 
> ./bootstrap
> 
> ./configure --prefix=/usr
[...]
> config.status: error: cannot find input file: `Makefile.in'

I expect that this failed simply because the previous bootstrap command
had failed, as described in the other thread you posted today.  If you
git pull, it should work now.

-- 
Colin Watson   [cjwat...@debian.org]

[PATCH] mdoc: Update operating system release numbers

[Colin Watson]

Based on a patch from Guillem Jover .

* tmac/doc-common-u: Update NetBSD, OpenBSD, FreeBSD, Darwin, and
DragonFly version strings.

* tmac/groff_mdoc.7.man: Synchronize.

Fixes: https://bugs.debian.org/867123
---
 tmac/doc-common-u | 120 ++
 tmac/groff_mdoc.7.man |  35 +++-
 2 files changed, 143 insertions(+), 12 deletions(-)

diff --git a/tmac/doc-common-u b/tmac/doc-common-u
index 0d2e418d..1da0470f 100644
--- a/tmac/doc-common-u
+++ b/tmac/doc-common-u
@@ -504,6 +504,15 @@
 .ds doc-operating-system-NetBSD-6.1.2 6.1.2
 .ds doc-operating-system-NetBSD-6.1.3 6.1.3
 .ds doc-operating-system-NetBSD-6.1.4 6.1.4
+.ds doc-operating-system-NetBSD-6.1.5 6.1.5
+.ds doc-operating-system-NetBSD-7.0   7.0
+.ds doc-operating-system-NetBSD-7.0.1 7.0.1
+.ds doc-operating-system-NetBSD-7.0.2 7.0.2
+.ds doc-operating-system-NetBSD-7.1   7.1
+.ds doc-operating-system-NetBSD-7.1.1 7.1.1
+.ds doc-operating-system-NetBSD-7.1.2 7.1.2
+.ds doc-operating-system-NetBSD-8.0   8.0
+.ds doc-operating-system-NetBSD-8.1   8.1
 .
 .ds doc-operating-system-OpenBSD-2.0  2.0
 .ds doc-operating-system-OpenBSD-2.1  2.1
@@ -542,6 +551,16 @@
 .ds doc-operating-system-OpenBSD-5.4  5.4
 .ds doc-operating-system-OpenBSD-5.5  5.5
 .ds doc-operating-system-OpenBSD-5.6  5.6
+.ds doc-operating-system-OpenBSD-5.7  5.7
+.ds doc-operating-system-OpenBSD-5.8  5.8
+.ds doc-operating-system-OpenBSD-5.9  5.9
+.ds doc-operating-system-OpenBSD-6.0  6.0
+.ds doc-operating-system-OpenBSD-6.1  6.1
+.ds doc-operating-system-OpenBSD-6.2  6.2
+.ds doc-operating-system-OpenBSD-6.3  6.3
+.ds doc-operating-system-OpenBSD-6.4  6.4
+.ds doc-operating-system-OpenBSD-6.5  6.5
+.ds doc-operating-system-OpenBSD-6.6  6.6
 .
 .ds doc-operating-system-FreeBSD-1.0 1.0
 .ds doc-operating-system-FreeBSD-1.1 1.1
@@ -608,6 +627,16 @@
 .ds doc-operating-system-FreeBSD-9.2 9.2
 .ds doc-operating-system-FreeBSD-9.3 9.3
 .ds doc-operating-system-FreeBSD-10.010.0
+.ds doc-operating-system-FreeBSD-10.110.1
+.ds doc-operating-system-FreeBSD-10.210.2
+.ds doc-operating-system-FreeBSD-10.310.3
+.ds doc-operating-system-FreeBSD-10.410.4
+.ds doc-operating-system-FreeBSD-11.011.0
+.ds doc-operating-system-FreeBSD-11.111.1
+.ds doc-operating-system-FreeBSD-11.211.2
+.ds doc-operating-system-FreeBSD-11.311.3
+.ds doc-operating-system-FreeBSD-12.012.0
+.ds doc-operating-system-FreeBSD-12.112.1
 .
 .ds doc-operating-system-Darwin-8.0.0  8.0.0
 .ds doc-operating-system-Darwin-8.1.0  8.1.0
@@ -654,6 +683,44 @@
 .ds doc-operating-system-Darwin-13.3.0 13.3.0
 .ds doc-operating-system-Darwin-13.4.0 13.4.0
 .ds doc-operating-system-Darwin-14.0.0 14.0.0
+.ds doc-operating-system-Darwin-14.1.0 14.1.0
+.ds doc-operating-system-Darwin-14.2.0 14.2.0
+.ds doc-operating-system-Darwin-14.3.0 14.3.0
+.ds doc-operating-system-Darwin-14.4.0 14.4.0
+.ds doc-operating-system-Darwin-14.5.0 14.5.0
+.ds doc-operating-system-Darwin-15.0.0 15.0.0
+.ds doc-operating-system-Darwin-15.1.0 15.1.0
+.ds doc-operating-system-Darwin-15.2.0 15.2.0
+.ds doc-operating-system-Darwin-15.3.0 15.3.0
+.ds doc-operating-system-Darwin-15.4.0 15.4.0
+.ds doc-operating-system-Darwin-15.5.0 15.5.0
+.ds doc-operating-system-Darwin-15.6.0 15.6.0
+.ds doc-operating-system-Darwin-16.0.0 16.0.0
+.ds doc-operating-system-Darwin-16.1.0 16.1.0
+.ds doc-operating-system-Darwin-16.2.0 16.2.0
+.ds doc-operating-system-Darwin-16.3.0 16.3.0
+.ds doc-operating-system-Darwin-16.4.0 16.4.0
+.ds doc-operating-system-Darwin-16.5.0 16.5.0
+.ds doc-operating-system-Darwin-16.6.0 16.6.0
+.ds doc-operating-system-Darwin-17.0.0 17.0.0
+.ds doc-operating-system-Darwin-17.1.0 17.1.0
+.ds doc-operating-system-Darwin-17.2.0 17.2.0
+.ds doc-operating-system-Darwin-17.3.0 17.3.0
+.ds doc-operating-system-Darwin-17.4.0 17.4.0
+.ds doc-operating-system-Darwin-17.5.0 17.5.0
+.ds doc-operating-system-Darwin-17.6.0 17.6.0
+.ds doc-operating-system-Darwin-17.7.0 17.7.0
+.ds doc-operating-system-Darwin-18.0.0 18.0.0
+.ds doc-operating-system-Darwin-18.1.0 18.1.0
+.ds doc-operating-system-Darwin-18.2.0 18.2.0
+.ds doc-operating-system-Darwin-18.3.0 18.3.0
+.ds doc-operating-system-Darwin-18.4.0 18.4.0
+.ds doc-operating-system-Darwin-18.5.0 18.5.0
+.ds doc-operating-system-Darwin-18.6.0 18.6.0
+.ds doc-operating-system-Darwin-18.7.0 18.7.0
+.ds doc-operating-system-Darwin-19.0.0 19.0.0
+.ds doc-operating-system-Darwin-19.1.0 19.1.0
+.ds doc-operating-system-Darwin-19.2.0 19.2.0
 .
 .ds doc-operating-system-DragonFly-1.01.0
 .ds doc-operating-system-DragonFly-1.11.1
@@ -688,14 +755,67 @@
 .ds doc-operating-system-DragonFly-2.12   2.12
 .ds doc-operating-system-DragonFly-2.13   2.13
 .ds doc-operating-system-DragonFly-3.03.0
+.ds doc-operating-system-DragonFly-3.0.1  3.0.1
 .ds doc-operating-system-DragonFly-3.13.1
 .ds doc-operating-system-DragonFly-3.23.2
+.ds doc-operating-system-DragonFly-3.2.1  3.2.1
 .ds doc-operating-system-DragonFly-3.3   

Re: [PATCH] mdoc: Update operating system release numbers

[Colin Watson]

On Tue, Dec 17, 2019 at 01:14:06PM +, Colin Watson wrote:
> Based on a patch from Guillem Jover .
> 
> * tmac/doc-common-u: Update NetBSD, OpenBSD, FreeBSD, Darwin, and
> DragonFly version strings.
> 
> * tmac/groff_mdoc.7.man: Synchronize.

Side note: I am not the biggest fan of this business of encoding a bunch
of other projects' release history in groff, so please don't take me as
an advocate of that.  However, I am generally an advocate of the
position that if one is going to encode this sort of thing then it makes
sense to keep it up to date.

-- 
Colin Watson   [cjwat...@debian.org]

Re: [PATCH] mdoc: Update operating system release numbers

[Colin Watson]

On Sat, Dec 21, 2019 at 02:51:23PM +0100, Ingo Schwarze wrote:
> Consequently, i just pushed the patch to the upstream groff repository,
> with the following tweaks:
> 
>  * I included the following versions which appeared to be missing:
> - NetBSD 6.0.6 and 7.2
> - DragonFly 3.0.2 and 3.2.2
> 
>  * I did *not* include the following releases because x.y.0 are not
>included for any other DragonFly releases: DragonFly 3.6.0 and 3.8.0.
>I'm not a DragonFly user and i'm not completely sure what would make
>most sense for that system, so i just stuck to existing practice as
>best i could.

Thanks.  I have no complaints with these - I wasn't completely sure what
I was doing and am happy for the corrections.

(There was a small typo, which I've fixed on master.  It's very easy for
one's eyes to swim when dealing with these macros.)

-- 
Colin Watson   [cjwat...@debian.org]

Re: pic anomalies

[Colin Watson]

On Sun, Dec 29, 2019 at 04:33:59PM +0100, Ingo Schwarze wrote:
> Regarding the bugfix in the code, thanks to Larry McVoy for
> providing feedback directly to me.  In particular, he suggested
> that while my fix wasn't incorrect, the two lines immediately
> following it can be simplified, making the code easier to read.
> 
> There may be opportunity for major cleanup in this code, too,
> but i don't think that should be mixed into a bugfix.
> The simplification of these two lines, however, is so closely
> related to the bugfix that it seems reasonable to include it.
> 
> Any OKs for the patch in the following form?

LGTM as far as it goes.  If I were doing it I think I'd take the
opportunity to simplify it a little further into this sort of structure:

  if (*form == '%') {
form++;
result += '%';
  }
  else {
...
snprintf(sprintf_buf, sizeof(sprintf_buf),
 one_format.contents(), v[i++]);
result += sprintf_buf;
  }
  one_format.clear();

But I understand if you'd prefer not to do that here.

-- 
Colin Watson   [cjwat...@debian.org]

Re: pic anomalies

[Colin Watson]

On Mon, Dec 30, 2019 at 01:39:38PM +0100, Ingo Schwarze wrote:
> An extremely small number of tests (14 tests grand total) is scattered
> all around the groff source tree, for example:
> 
>  - contrib/gdiffmk/tests/gdiffmk_tests.sh
>  - contrib/hdtbl/examples/test-hdtbl.sh.in
>  - contrib/mom/examples/test-mom.sh.in
>  - src/roff/groff/tests/
>  - tmac/tests/
> 
> You can run that suite with "make check" from the top directory,
> but it is not much use because it is very fragile.  For example,
> right now, after "git pull" and building from source, nine out
> of the fourteen tests fail for me on OpenBSD-current, so it's at
> least about 65% broken.

FWIW, I run these tests as part of the Debian package build and enforce
that they pass.  This is obviously only of limited use since it's only
after releases, but it's better than nothing.  (I would hope that
maintainers also run "make check" prior to release, perhaps via "make
distcheck", although I don't actually know.)

I agree that some of these tests tend to be somewhat fragile,
particularly those that look at properties of generated PDFs.  That
said, with current git master on Debian unstable, all the tests pass for
me right now.

-- 
Colin Watson   [cjwat...@debian.org]