Bug#953215: [libreadline-dev] libreadline-dev in stable lacks a .pc file for pkg-config

[G. Branden Robinson]

> The file readline.pc is provided since bullseye, so imho this bug can
> be closed.

But the history.pc file apparently isn't.

$ dpkg-deb -c libreadline-dev_8.2-1.3_amd64.deb
drwxr-xr-x root/root 0 2023-01-03 14:49 ./
drwxr-xr-x root/root 0 2023-01-03 14:49 ./usr/
drwxr-xr-x root/root 0 2023-01-03 14:49 ./usr/include/
drwxr-xr-x root/root 0 2023-01-03 14:49 ./usr/include/readline/
-rw-r--r-- root/root  4461 2023-01-03 14:49 
./usr/include/readline/chardefs.h
-rw-r--r-- root/root 10684 2023-01-03 14:49 ./usr/include/readline/history.h
-rw-r--r-- root/root  3201 2023-01-03 14:49 ./usr/include/readline/keymaps.h
-rw-r--r-- root/root 38171 2023-01-03 14:49 
./usr/include/readline/readline.h
-rw-r--r-- root/root  2829 2023-01-03 14:49 ./usr/include/readline/rlconf.h
-rw-r--r-- root/root  1837 2023-01-03 14:49 ./usr/include/readline/rlstdc.h
-rw-r--r-- root/root  3021 2023-01-03 14:49 
./usr/include/readline/rltypedefs.h
-rw-r--r-- root/root  2652 2023-01-03 14:49 ./usr/include/readline/tilde.h
drwxr-xr-x root/root 0 2023-01-03 14:49 ./usr/lib/
drwxr-xr-x root/root 0 2023-01-03 14:49 ./usr/lib/x86_64-linux-gnu/
-rw-r--r-- root/root 65332 2023-01-03 14:49 
./usr/lib/x86_64-linux-gnu/libhistory.a
-rw-r--r-- root/root657390 2023-01-03 14:49 
./usr/lib/x86_64-linux-gnu/libreadline.a
drwxr-xr-x root/root 0 2023-01-03 14:49 
./usr/lib/x86_64-linux-gnu/pkgconfig/
-rw-r--r-- root/root   318 2023-01-03 14:49 
./usr/lib/x86_64-linux-gnu/pkgconfig/readline.pc
drwxr-xr-x root/root 0 2023-01-03 14:49 ./usr/share/
drwxr-xr-x root/root 0 2023-01-03 14:49 ./usr/share/doc/
drwxr-xr-x root/root 0 2023-01-03 14:49 ./usr/share/info/
lrwxrwxrwx root/root 0 2023-01-03 14:49 
./usr/lib/x86_64-linux-gnu/libhistory.so -> 
/lib/x86_64-linux-gnu/libhistory.so.8
lrwxrwxrwx root/root 0 2023-01-03 14:49 
./usr/lib/x86_64-linux-gnu/libreadline.so -> 
/lib/x86_64-linux-gnu/libreadline.so.8
lrwxrwxrwx root/root 0 2023-01-03 14:49 ./usr/share/doc/libreadline-dev 
-> libreadline8

For instance, I got the following problem when attempting to build
"csope".[1]

>> Package history was not found in the pkg-config search path.
>> Perhaps you should add the directory containing `history.pc'
>> to the PKG_CONFIG_PATH environment variable
>> No package 'history' found

Fortunately it was easy to hand-roll a replacement.

Regards,
Branden

[1] https://github.com/agvxov/csope


signature.asc
Description: PGP signature

Bug#1037353: lynx.1: a few formatting fixes for the manual

[G. Branden Robinson]

Hi Thomas,

At 2023-06-14T17:49:04-0400, Thomas Dickey wrote:
> On Mon, Jun 12, 2023 at 01:56:56AM +, Bjarni Ingi Gislason wrote:
> > Output from "mandoc -T lint lynx.1"
> > mandoc: lynx.1:27:2: WARNING: missing date, using "": TH
> > mandoc: lynx.1:109:2: WARNING: unknown font, skipping request: ft C 
> > 
> > mandoc: lynx.1:317:2: WARNING: unknown font, skipping request: ft C 
> > 
> > mandoc: lynx.1:366:2: WARNING: unknown font, skipping request: ft C 
> > 
> > mandoc: lynx.1:831:2: WARNING: unknown font, skipping request: ft C 
> > 
> > mandoc: lynx.1:838:2: WARNING: unknown font, skipping request: ft C 
> > 
> > mandoc: lynx.1:1131:2: WARNING: unknown font, skipping request: ft C
> > 
> 
> That seems to be harmless for nroff, but mainly is for troff (and
> groff) to select a fixed-pitch font for PDFs and PostScript.  I'll see
> if this is at least no worse than the plain "C".

groff 1.23.0 warns about that font name too.  Here's one place the issue
was explored (and remedied).

https://sourceforge.net/p/docutils/patches/205/

> Solaris 10 appears to have "CO" for "Courier" (troff), while an AIX
> that I can access uses "CR".  But on those systems, I'm not actually
> using troff :-)

As far as I can tell, font names simply were not standardized, even by
common practice.  Each troff vendor came up with their own set of names,
I would guess inspired by whatever PostScript fonts they paid to license
from relevant foundries, and aliases may have been set up on an ad hoc
basis if/as problems with document rendering arose.

> I've been using "C" quite a while, and hadn't noticed a problem with
> the indicated usage (i.e., generating PDFs, etc).

Selecting a nonexistent font is a no-op, so it's unlikely to ruin
a document's formatting.  Proportional fonts generally set with more
horizontal compactness constant-width ones, so lines written in the
expectation of, say, Courier are unlikely to overrun when set in Times.

To detect a problem, you'd have to know that a constant-width face was
expected there, and man page styling conventions were (are?) seldom
consistent enough that you'd notice this unless you were a page's
author, or an editor of a collection.

> > ###
> > 
> > Increase size of ~ (tilde) to make it more visible
> > with "troff" by using character \(ti.
> 
> That appears to be groff-specific.

Historically, the troff semantics of ~ are that it's a high-flown
character that will compose well with alphabetic glyphs when overstruck
with them.  I'm attaching a screenshot of Table I from a scan of the
CSTR #54 1976 document, Joseph Ossanna's "Nroff/Troff User's Manual".  A
tilde glyph did not exist in the Times faces, but appeared in the
"Special Mathematical Font" that Bell Labs commissioned.  One of the
purposes of that font was to get full coverage of the ASCII character
set, which typographers in those days did not respect as a necessary
basis for a font's glyph repertoire.

However, it is true that there was only variety of tilde available to
troff back then, so there was no need for a `\(ti` special character,
and none was defined.

Enter Kernighan's device-independent troff circa 1980.  An output device
could use any font names it wanted, and any special character names it
wanted.

As fonts' glyph repertoires grew, this freedom saw some exercise.
Eventually the arrival of a larger, lower tilde character necessitated
the invention of a name to refer to the "full" or "spacing" tilde as
depicted at U+007E in Unicode 2.0 and later.[1]

So, for example, while Documenter's Workbench 3.3 troff, one of several
lines of descent from Kernighan troff, does not define a `ti` special
character, its descendant Heirloom Doctools troff _does_.  And mandoc(1)
recognizes it as well.

I wouldn't expect any System V troff to do so.  But strings can be
defined to work around that problem just as they can for typographer's
(and programmers' neutral) quotation marks.

> > an.tmac:lynx.1:27: style: .TH missing third argument; suggest document 
> > modification date in ISO 8601 format (-MM-DD)
> > an.tmac:lynx.1:27: style: .TH missing fourth argument; suggest 
> > package/project name and version (e.g., "lynx ...")
> 
> maybe - there are pros/cons (the version number is in the manpage,
> and that indirectly gives an accurate date).  If I did put a date,
> it would be the modification date for _that_ file.

That appears to be a best practice, if not quite a common one, and it is
what groff_man_style(7) recommends.

 .TH topic section [footer‐middle [footer‐inside [header‐middle]]]
[...]
By convention, footer‐middle is the date of the most recent
modification to the man page source document, and footer‐
inside is the name and version or release of the project
providing it.

Regards,
Branden

[1] I don't say "Unicode [1.0]" because the standard supported 

Bug#1041731: Hyphens in man pages

[G. Branden Robinson]

Hi Russ,

At 2023-10-15T12:06:14-0700, Russ Allbery wrote:
> Minor point, but since you posted it

No worries!

> "G. Branden Robinson"  writes:
> 
> > ...
> 
> >  \- Minus sign or basic Latin hyphen‐minus.  \- produces the
> > Unix command‐line option dash in the output.  “-” is a
> > hyphen in the roff language; some output devices replace it
> > with U+2010 (hyphen) or similar.
> 
> The official name of "the Unix command-line option dash" is the
> hyphen-minus character (U+002D).  Given how much confusion there is
> about this, and particularly given how ambiguous the word "dash" is in
> typography (the hyphen-minus is one of 25 dashes in Unicode), you may
> want to say that explicitly in addition to saying that it's the
> character used in UNIX command-line options (and, arguably as
> importantly, in UNIX command names).

How about this?

 \- Minus sign.  \- produces the basic Latin hyphen‐minus
specifying Unix command‐line options and frequently used in
file names.  “-” is a hyphen in roff; some output devices
replace it with U+2010 (hyphen) or similar.

Regards,
Branden


signature.asc
Description: PGP signature

Bug#1041731: Hyphens in man pages

[G. Branden Robinson]

At 2023-10-15T10:01:20-0700, Russ Allbery wrote:
> I think my position at this point as pod2man maintainer (not yet
> implemented in podlators) is that every occurrence of - in POD source
> will be translated into \-, rather than using the current heuristics,
> and people who meant to use ‐ should type it directly in the POD
> source.  pod2man now supports Unicode fairly well and will pass that
> along to *roff, which presumably will do the right thing with it after
> character set translation.

It will, as long as something (like preconv(1)) translates the UTF-8
into something GNU troff can understand.  One of the most painful
decisions James Clark made was to follow AT's example and use "char"
as the fundamental character type, instead of throwing his elbows with
an "int" (or better yet, an int-sized C++ type, since C++ had real type
checking in 1989, while K C was still in vogue and scoffed at such
gratuities).[1]  I took a stab at changing this about 3 years ago but
it was too big a bite.  I didn't know enough yet about how the formatter
worked.  If I have n months to set aside I suspect I can get it done on
a second attempt.

Anyway, to illustrate.  (UTF-8 follows.)

$ for n in $(seq 8); do printf 'abc\\[u2010]defgh '; done | nroff | cat -s
abc‐defgh  abc‐defgh abc‐defgh abc‐defgh abc‐defgh abc‐defgh abc‐
defgh abc‐defgh


> Currently, pod2man uses an extensive set of heuristics, but I think
> this is a lost cause.  I cannot think of any heuristic that will
> understand that the - in apt-get should be U+002D (so that one can
> search for the command as it is typed), but the - in apt-like should
> be apt­like, since this is an English hyphenated expression talking
> about programs that are similar to apt.  This is simply not
> information that POD has available to it unless the user writing the
> document uses Unicode hyphens.

Yes.  This is the same point I was trying to make with my mg(1) man
page example.

> I believe the primary formatting degredation will be for very long
> hyphenated phrases like super-long-adjectival-phrase-intended-as-a-
> joke, because *roff will now not break on those hyphens that have been
> turned into \-.  People will have to rewrite them using proper Unicode
> hyphens to get proper formatting.

Even that can be overcome.  You can tell groff that a line can be broken
after a minus sign.  But I'm going to stone-facedly require people to
RTFM for that.  The character remapping in the PROBLEMS file is the
prescribed band-aid for those who can't or don't care to fix bad
typography in man pages, and I'd prefer not to see additional cargo cult
techniques piled on top of it.

https://git.savannah.gnu.org/cgit/groff.git/tree/PROBLEMS?h=1.23.0#n82

Regards,
Branden

[1] Just like the omission of bounds checks on array types.  What a
brilliant efficiency that was.  Jean Ichbiah saw Dennis Ritchie
coming a mile away in the 1970s, and Ada 83 did the right thing--in
countless respects.  Compiler authors squealed like pigs in hot oil
at the idea of doing any amount of static analysis of input--this is
back when compilers would not _automatically_ pass anything in
registers at all (_everything_ hit the stack) and common
subexpression elimination was regarded as a state-of-the-art
optimization--and spent over a decade slandering Ada's name in every
forum available to them.  Nowadays, static analysis is cool and
compiler engineers make big, big bucks developing its techniques
professionally.  And I'll bet you those who have even heard of Ada
still turn their noses up at it.

Stick around, and I'll share the secret legacy of the hated IA-64...


signature.asc
Description: PGP signature

Bug#1041731: Hyphens in man pages

[G. Branden Robinson]

Hi Wookey,

At 2023-10-15T16:08:32+0100, Wookey wrote:
> OK. So I read all that, and learned a whole load of stuff I was quite
> happy not knowing about.
> 
> However despite reading it all, and especially this bit:
> > Whenever I've maintained man pages in roff I tend to be precise in
> > the usage of - and \-, but TBH this has seemed like a lost battle,
> 
> I was left not actually know what - and \- represent, nor which one I
> _should_ be using in my man pages. And that seems to be the one thing
> we should be telling the 'average maintainer'.
> 
> I think you can consider me representative of the typical maintainer
> who's intereaction with *roff languages almost entirely takes the
> form: 'Oh bloody hell I really ought to write a man page for this
> because upstream is too youthful to have done so - now how the hell
> does roff/nroff/groff work again' (no I'm not sure which it is I'm
> actually using, nor how any of this machinery really works, nor where
> to look for good practice, so I mostly copy existing stuff and DDG for
> answers, which is less than ideal when it comes to details like this).
> 
> So this message is mostly a reminder that most people have not been
> following along at all, so just referring people to bugs like this,
> which discuss the issue in some detail, is not sufficient for
> maintainers to stop doign unhelpful things.
> 
> (Yes I realise I could look it up, but I get the impression that
> everyone involved in this discusssion assumes people know what '-' and
> '\-' are so if they are just told to 'use the right one' will do so,
> and I thought it worth pointing out that that's not correct). Info for
> your average maintainer needs to go one step back and say "use stringA
> in this circumstance and stringB in this circumstance.  what they represent>. The reason why it matters is: stuff about hyphen
> and minus being different and minus being used in commands and
> cut+pasting being important"

Yes, I appreciate your popping of the context stack.

Andreas and Russ provided good, quick answers.  One can reasonably
wonder where to find the same answer in groff's documentation.

Subsection "Fundamental character set" of the groff_char(7) man page
covers the matter, but like the bug report we've Cced, it goes into
great detail.

Subsection "Portability" of groff_man_style(7) (or groff_man(7) in groff
1.22.4) covers the subject in a more practical, how-to manner.

[UTF-8 follows.]

groff_man_style(7):
 ... Some escape sequences
 are however required for correct typesetting even in man pages and
 usually do not cause portability problems.

 Several of these render glyphs corresponding to punctuation code
 points in the Unicode basic Latin range (U+–U+007F) that are
 handled specially in roff input; the escape sequences below must be
 used to render them correctly and portably when documenting
 material that uses them syntactically—namely, any of the set ' - \
 ^ ` ~ (apostrophe, dash or minus, backslash, caret, grave accent,
 tilde).

...

 \- Minus sign or basic Latin hyphen‐minus.  \- produces the
Unix command‐line option dash in the output.  “-” is a
hyphen in the roff language; some output devices replace it
with U+2010 (hyphen) or similar.

 \(aq   Basic Latin neutral apostrophe.  Some output devices format
“'” as a right single quotation mark.

...

 \(ga   Basic Latin grave accent.  Some output devices format “`” as
a left single quotation mark.

 \(ha   Basic Latin circumflex accent (“hat”).  Some output devices
format “^” as U+02C6 (modifier letter circumflex accent) or
similar.

 \(rs   Reverse solidus (backslash).  The backslash is the default
escape character in the roff language, so it does not
represent itself in output.  Also see \e above.

 \(ti   Basic Latin tilde.  Some output devices format “~” as U+02DC
(small tilde) or similar.

> Hope that's helpful.

I hope this message goes some way toward relieving your frustration.

Regards,
Branden


signature.asc
Description: PGP signature

Bug#1041731: Hyphens in man pages

[G. Branden Robinson]

At 2023-10-14T20:51:27-0600, Antonio Russo wrote:
> I discovered a new pet peeve today: if you search for a command in a
> manual page, say -e in man 1 zgrep, it's a crapshot whether just
> searching for '-e' will find the command or not.  The reason is that
> "-" may been accidentally encoded as ‐ instead of -.

You can blame me for this.

https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS?h=1.23.0#n206

...me, and man page authors who don't think about whether they intend
a hyphen or a minus sign when they strike the '-' key...

Quick background: in the context of Unix usage as documented by
nroff/troff, the dash used at the shell prompt, in text editors, and in
programming language source code is a "minus sign".  troff has an em
dash special character as well since the mid-1970s; groff adds an en
dash as well, and furthermore supports user definition of characters
providing access to any other sort of dash that comes down the Unicode
pike.  (Not that doing so is a good idea in a man page; see below
regarding a "restricted dialect" of man(7).)

> Now, depending on your email client and settings, the above will
> appear to be the ravings of an unhinged lunatic who wrote the same
> thing twice, or an unhinged lunatic who slammed their fists onto the
> keyboard.

This issue does indeed have a history of provoking unhinged lunacy.

Before we proceed, you might wish to be aware of
 and its
proposed remedy.

> The reason is that man(1) convert bare dashes (0x2D) to hyphens
> (U+2010).  These are not the same symbol: searching for one does not
> find the other without some kind of normalization, pasting commands
> with one vs. the other does different things.  New users who do not
> understand this will be discouraged trying to read manual pages.
> Chances are, they will fill forums with mundane questions that could
> and should have been addressed by a simple search of a manual page.

I run into this problem, too, since I dogfood my own changes.  When
irritated by this, I try the search again, replacing '-' with '.', which
has yet to fail me (and produces false positives surprisingly rarely).

For example, I've recently been playing with the mg(1) editor, and
observed extremely poor discipline in this area.  So I forked it on
GitHub and have been preparing a bunch of revisions.  I wrote a sed
script to fix its numerous hyphen/dash problems.[1]

> I recently fixed a ton of these in another upstream package with this
> vim "one-liner":
> 
> :%s/--\([a-z]\+\)\(-[a-z]\+\)*/\=substitute(submatch(0), '-', '\\-', 'g')/g

My Vimscript is not very sophisticated, but it looks like you're
replacing only hyphens that appear in long option names here.  That's
good, as you're unlikely to clobber any hyphens that should _not_ become
minus signs.

Such discernment is important.  Many people who want to "solve" this
issue forget (or ignore) that not every '-' is a minus sign.  Some are
actual hyphens, as in "long-term effects" and "word-aligned struct
members".  Trying to infer a distinction from white space adjacency also
won't work.  Consider the phrases "word- or byte-sized caching" and
"object-based vs. -oriented programming".  While sophistication with
compound hyphenated affixes is seldom seen in man pages, we most often
find it where a man page author has taken considerable care with their
technical writing.  Such pages are less likely than most to require
revision with blunt instruments like regular expression-based global
search and replace operations.

> However, this requires manual review

Surprisingly often, the composition of high-quality technical
documentation requires the engagement of a human brain.

> and does not fix the '-e' example from zgrep.

Mapping all hyphens and minus signs to a single character, as people
whose blood pressure spikes over this issue tend to promote as a first
resort, is an ineluctably information-discarding operation.  In my
opinion, man page source documents are not the correct place to discard
that information.

(I acknowledge that you didn't propose such a crude remedy; I write to
anticipate the inevitable follow-ups from people who will.)

Doing so at rendering time is much more defensible, and happens anyway
on devices that do not distinguish these characters in the first place.

> There are also a whole host of this kind of problem, e.g., dashes in
> URLs that get naievely pasted into man pages (another live example I
> just addressed).

Yes, people commonly type URLs and email addresses into man page sources
as they would into an MUA or browser navigation bar.  Since U+2010 is
difficult to encode in such things, the man(7) package could help by
performing an automatic character translation in this area.  However,
(1) no one's actually asked for this and (2) it would address only a
tiny part of the problem.  The means of "help" I have in mind is
employment of the groff man(7) extension macros `UR`/`UE` and 

Bug#885698: What licenses should be included in /usr/share/common-licenses?

[G. Branden Robinson]

At 2023-09-10T21:47:36+0200, Johannes Schauer Marin Rodrigues wrote:
> Quoting Bill Allombert (2023-09-10 18:29:36)
> > On Sun, Sep 10, 2023 at 09:00:22AM -0700, Russ Allbery wrote:
> > > Jonas Smedegaard  writes:
> > > >>  Hmm, how about providing license-common package and that
> > > >>  depends on "license-common-list", and ISO image provides both,
> > > >>  then? It would be no regressions.
> > > 
> > > I do wonder why we've never done this.  Does anyone know?
> > > common-licenses is in an essential package so it doesn't require a
> > > dependency and is always present, and we've leaned on that in the
> > > past in justifying not including those licenses in the binary
> > > packages themselves, but I'm not sure why a package dependency
> > > wouldn't be legally equivalent.  We allow symlinking the
> > > /usr/share/doc directory in some cases where there is a
> > > dependency, so we don't strictly require every binary package have
> > > a copyright file.
> > 
> > Or we could generate DEBIAN/copyright from debian/copyright using data in
> > license-common-list at build time. So maintainers would not need to manage
> > the copying themselves.
[...]
> I have zero legal training so the only potential problem with this approach
> that I was able to come up with is, that then the source package itself would
> not anymore contain the license text

...why wouldn't it?  Remember how a source package is defined:

A DSC file, an upstream source archive (maybe more than one in exciting
new source formats I haven't learned), and a compressed diff of Debian
changes.

Debian _source_ packages generally don't chop copyright notices and
license texts out the upstream distributions, and should not do so
unless those notices/texts are invalid or the material they cover has
been removed.  (Both of these do sometimes happen.)

Even if one worries about theoretical liability due to the existence of
separate files for .dsc, .tar.gz, and .diff.gz, then let us recall that
(1) the DSC is minimal, containing metadata that may not rise to the
threshold or originality required by copyright [in the U.S., anyway];
(2) the upstream archive has the notices and texts that the _original
distributor_ put in it, and as a rule, if permission to distribute the
work exists, it is not incumbent on redistributors to add notices/texts
where the rightsholder themselves neglected to do so; and (3) the
.diff.gz will not be in the business of removing notices/texts except as
contemplated in the previous paragraph (correcting erroneous
notices).[1]

> and thus we would be shipping code covered by a license that states
> that the code may only be distributed with the license text alongside
> it without that text.

I don't think that is a risk as long as people continue to follow
packaging practices that Debian has applied with little objection from
our upstreams for 25+ years.[2]

> So while auto-generating this would probably create compliant binary
> packages, it would leave the source package without the license text.

I am unable to imagine the mechanism by which that would happen, given
what Russ and Bill proposed.

Regards,
Branden

[1] When repackaging, e.g., to remove non-free material, affected
content is removed altogether even from the source.  Nothing in
copyright law can compel you to distribute copyright notices and
texts that don't apply to work you're not distributing.[3]

[2] I don't know of Debian _ever_ having had a problem, as in receiving
a cease-and-desist letter or other threat of legal action with what
one might term an "institutional" copyright holder.  We've certainly
had our share of nasty emails from cantankerous individual copyright
holders, often who had their own perverse misreadings of licenses
drafted by others (hello to the memory of Jörg Schilling).  There
also was once an upstream who stuck a Trojan horse into the source
code to try to get Debian's users to stop using versions we
distributed, but to go directly upstream instead.  Nowadays, that
seems quaint; you can today Trojan your machine much more
conveniently with npm(1).

[3] At the same time a few non-free FSF manuals under the GNU FDL
declaim the GNU _GPL_ text to be an Invariant Section.  Like most of
the defects of the FDL, I think this is a pointless encumbrance; if
you distribute GPL'ed software, a copy of its text must come along
anyway.  The only rationale I can imagine is to mandate, for printed
copies of the manuals, the inclusion of the GPL's preachy preamble.
But I digress.


signature.asc
Description: PGP signature

Bug#1051357: lintian: RfC: resurrect hyphen-used-as-minus-sign

[G. Branden Robinson]

Package: lintian
Version: 2.116.3
Severity: wishlist
X-Debbugs-Cc: cjwat...@debian.org, sthiba...@debian.org

Background: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785353

Samuel Thibault and Colin Watson have suggested resurrecting this
lintian tag now that groff 1.23.0 handles the underlying issue a bit
differently.  (Mainly, the new groff makes it easier for sites to opt-in
and -out of this behavior by putting things in man.local and mdoc.local
instead of in the macro packages themselves, which are not conffiles.)

Debian's groff package is presently _not_ remapping input hyphens to
U+002D, to try and attract package maintainer attention and shake these
issues out, but it is also carrying a serious-severity ticket to prevent
itself from shipping that way in the next stable release.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041731#57 .

Regards,
Branden


signature.asc
Description: PGP signature

Bug#1043256: man.local: missing font transformation for 'C'

[G. Branden Robinson]

X-Debbugs-CC: Bjarni Ingi Gislason 

In my opinion, this bug should be reassigned to the zip package.

Also, the correct term is "font translation", not "font transformation".

https://www.gnu.org/software/groff/manual/groff.html.node/Selecting-Fonts.html

At 2023-08-07T22:11:43+, Bjarni Ingi Gislason wrote:
> Package: man-db
> Version: 2.11.2-3
> Severity: normal
> 
> Dear Maintainer,
> man zip > /dev/null 
> 
>* What was the outcome of this action?
> 
> troff::175: warning: cannot select font 'C'
> ...

Can reproduce.  This warning occurs many times, along with two others.

troff:zip.1:1675: warning: cannot select font 'N'
troff:zip.1:2636: warning: escape character ignored before 'i'

These two appear to be due to typos.

>* What outcome did you expect instead?
> 
> No warnings.

These messages arise due to errors in the page sources; the formatter is
unable to do what is being asked of it.

> File "/etc/groff/man.local" needs a font transformation
> 
> .if n .ftr C R

Colin Watson rejected this idea when Python docutils-generated man pages
exhibited the same problem.  This issue has now been fixed upstream in
python-docutils--the right place, in my opinion--and uploaded to Debian.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041809

zip(1) appears to have been composed directly by a human.  The page is
(strictly speaking) buggy, and use of the `\fC` escape sequence is not
portable across *roff implementations.  It is also ineffectual on
terminal output devices regardless of implementation.

There are a number of related problems here.

* It's impossible to change font family or type size in an nroff
  document.  Nevertheless, it is attempted commonly enough that GNU
  troff (and all other troffs I know of) silently ignore such attempts.
* Not all troffs even support the _concept_ of "font families"; you will
  not find it in Ossanna troff or Kernighan troff.
* Portable man pages must use only fonts named `R`, `I`, and `B`.  It is
  consequently better to use man(7)'s facilities for switching fonts.
* Even on typesetting devices, a font named `C` is not guaranteed to
  exist.  As far as I can tell from my research over the years, this
  font name was never supported by the troff in BSD Unix until it
  replaced its AT troff with GNU troff.
* AT device-independent troff, in lines of descent from Kernighan
  troff (ca. 1980), _sometimes_ supported a font named `C`.  Sometimes
  it was called `CW` instead.  Sometimes both were available.  Sometimes
  it wasn't available at all.
* There is no portable interface for testing the availability of a font
  in the output device.  GNU troff supports `.if F` for this purpose;
  AT troff and at least some of its descendants do not.

It appears to me that in most or all cases, zip(1) uses this 'C' font
mark up literal input, like examples of command-line usage, on their own
output lines.  That's good, because it suggests that the page can easily
migrate to the EX/EE man(7) extension, first developed in Research Ninth
Edition Unix (1986) and adopted by groff in 2007-2009.

To retain portability, since Info-ZIP likely wants to retain support for
a huge variety of systems, the page could take the approach recently
adopted by lexgrog(1) in the man-db project.

It looks like the upstream package hasn't been updated in 15 years.  I'm
happy to prepare some patches to improve its man pages for the Debian
package.  It looks like most of the corrections relevant to this bug
report can be straightforwardly automated with sed(1).

I'm also happy to contribute some further correctness and portability
issues to the page per groff_man_style(7).

Let me know.

Regards,
Branden


signature.asc
Description: PGP signature

Bug#1041731: groff-base: "-" mapped as HYPHEN

[G. Branden Robinson]

At 2023-07-23T09:46:51+0100, Colin Watson wrote:
> On Sat, Jul 22, 2023 at 11:54:24PM -0500, G. Branden Robinson wrote:
> > I know it's not very generous to observe that Sven either made this
> > claim without verifying it first, or had no concern for the facts
> > when making it, but it's hard to account for otherwise.
> > 
> > https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS?h=1.23.0#n206
[snip]
> Please don't do this?  I really don't think there's a need to link
> [...] carelessness in bug reporting to a [...] conspiracy theory.

Okay, fair--my point would have been made as well or better if I had
used only a citing URL to punctuate it rather than indulging my tendency
to conduct social philosophy.

I'll shuffle a further thought on this to the end of the mail.

> > My reasoning is this:
> [...]
> > It is only through the efforts of people in groups 2 and 4 that any
> > headway will be made on the problem.  That is where the Sisyphean
> > effort lies.  The good news is that this effort distributes...but
> > only if distributors decide not to hide the problems.
> 
> OK.  Thanks for making the good-faith attempt, but I'm afraid this has
> not convinced me.  My reasoning is that, no matter what way you slice
> it, it should always be the case that there are many more people who
> read manual pages than people who write them.

Heh--you countered my oblique reference to the Debian Social Contract
with an oblique reference (wittingly or not) to the Ada 83 Rationale
document (though the insight is surely older still).  Well played!

> If you want to bring in real-world analogies: externalizing costs onto
> relatively powerless consumers in the hope of using them to relay
> complaints to the people in power offends my sense of natural justice.

The trouble with knowing me is that you know the best arguments to use
against me...

> Incidentally, I realize belatedly that in writing this I'm implying
> that correct typography in PDF output is without value.  I don't mean
> to imply that.

Admittedly off-topic, but...

Deri James has done terrific work on gropdf.  I've been wondering what
its prospects for moving into groff-base might be.  The day might not be
too far off when it make sense for 'pdf' rather than 'ps' to become
groff's default output format.  (Maybe sooner if I learn package
triggers well enough to resolve Debian #609549.)

> For a campaign that would put the burden closer to the correct set of
> shoulders, I suggest agitating for the reversal of
> https://bugs.debian.org/785353.

I was unaware of this report.  Thanks.  I see that one of the premises
for retirement of the Lintian warning is "these days even upstream groff
renders both - and \- as HYPHEN-MINUS."  That was never entirely true,
but it is once more not true on the 'utf8' output device.

> Lintian is in a better position to bother developers without causing
> problems for users in the meantime, and I somewhat regret not pushing
> back on that particular change at the time.  It's also in a position
> to give us quantitative distribution-wide data.

Fair.  Maybe Lintian developers can help me see a path to structuring
the style warnings for man pages that groff now supports, which is such
an ad hoc feature in its present form that I _didn't_ document it.
(Alex Colomar is already using it for Linux man-pages, though.)

https://savannah.gnu.org/bugs/?62042

> > [3] In full disclosure, the inclusion of "NEWS" in the release
> > announcement was at my prompting, because we got essentially no
> > feedback on the first 1.23.0 release candidate 3 years ago, and
> > I had thought that the reason was because we didn't tell people
> > what was new in it, to motivate them to upgrade.  (It's also
> > common, but not universal, practice in GNU software release
> > announcements.)
> > 
> > I now have to modify my understanding.  Much distribution
> > maintenance is robotic (often, I think, because it is done in
> > the course of professional employment, which was not the case
> > nearly as often in the 1990s when I became part of the FLOSS
> > ecosystem).
> 
> I'd also say that there's just a lot more to do than there was in the
> 1990s

[Please excuse a digression.]

We also enjoy productivity advantages that we didn't have back then.
CI/CD infrastructures were in their infancy in 2002, when Debian stable
had 11 architectures to support.  My professional experience
(anecdote!) leads me to believe that there is, at most, as much time
for on-the-clock engineering as there was then.  Just as "work expands
to fill the schedule allotted for it", any engineer time freed up by
improvements in processes or technology is not left for staff to attack
unsolved problems t

Bug#1041731: groff-base: "-" mapped as HYPHEN

[G. Branden Robinson]

Hi Colin,

On Sun, 23 Jul 2023 00:37:43 +0100, Colin Watson wrote:
> On Sat, Jul 22, 2023 at 06:46:28PM +0200, Sven Joachim wrote:
> > This version of groff maps an unescaped "-" to HYPHEN rather than
> > HYPHEN-MINUS.  Due to that, copying text from manpages or following
> > references in the "SEE ALSO" section is rather unreliable, because
> > many manpages contain a plain "-" where they should have used "\-"
> > instead.

Yes.  That's an error in the man pages, an error Debian has been hiding
for 10+ years.

> > [...] the upstream NEWS file [...] make[s] [no] mention of this
> > change, or how to revert it locally.

Yeah, see, that's where the hyphen-minus brigade gives itself away.

I know it's not very generous to observe that Sven either made this
claim without verifying it first, or had no concern for the facts when
making it, but it's hard to account for otherwise.

https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS?h=1.23.0#n206

If it's any comfort (it actually isn't, to me), Sven's not alone; it's
obvious that the Arch Linux groff packager didn't read the NEWS file
either.[1]

I would add that groff's GNU maintainer, Bertrand Garrigues, included
the entire portion of the NEWS file applicable to groff 1.23.0 in the
release announcement.[2][3]

It is pretty discouraging as an upstream maintainer to go to the trouble
of carefully documenting these things only to find that people not only
don't read the documentation, but assert in the face of obvious contrary
evidence that such documentation doesn't exist.

As annoyed as someone might be by "-" not copying and pasting correctly,
be assured that I am at least ten times as annoyed by people adopting
this QAnon-esque approach to software defect reporting.  The entire
project of cooperative bug reporting and remediation breaks down if
people don't attend conscientiously to material reality.

> I admit I overlooked this; I was aware of the change, but it somehow
> fell off my list of things to make a positive decision about when
> packaging 1.23.0.  I'm rather inclined to revert this by adding the
> rest of the recipe above to debian/mandoc.local (while I agree with
> the idealized typographical point being made, I have approximately
> negative appetite for the Sisyphean task of fixing an entire
> distribution's manual pages in practice), but I'll let this suggestion
> sit for a few days in case anyone wants to make a reasoned argument
> against it in the meantime.

Okay.  Here is my attempt at such.

My reasoning is this:

1.  We're not going to get people to fix these problems by asking them
to fix them when they cannot observe the deleterious effects they
create.  Debian has tried this approach for as long as its relevant
`char` requests have been in place in its groff package; you know
that duration better than I do.  (I guessed at 10+ years above.)

2.  There are a few exceptions to this rule, like Alex Colomar and me,
but we are maintainers of man page collections[4] and moreover we
are both bent on precision and correctness in detail.

3.  Some people will notice the problem Sven reported, become annoyed by
it, research it (perhaps by reading groff's NEWS file, which like
the maintenance of an exercise regimen or healthy diet, appears to
enjoy more lip service than adherence in practice), and work around
it on their systems; either in a narrowly focused way, as with the
recipe in groff's PROBLEMS file, or with a crude, blunt approach
(like LC_ALL=C) as noted by Sven.

4.  Some people will notice the problem Sven reported, become annoyed by
it, and report bugs to Debian.  Possibly against man-db or groff.
As an unofficial groff co-maintainer, I'm willing to shoulder the
responsibility of copy-and-pasting from groff's NEWS and/or PROBLEMS
and reassign the bug reports.  I hadn't been monitoring man-db's
Debian bug list, but I have started.

5.  Some people will notice the problem Sven reported, will not be
annoyed by it, and resign themselves to correcting cut-and-pasted
text.  It's not all _that_ hard: with Bash's no-longer-brand-new
bracketed paste mode, it's a lot easier to distinguish what gets
pasted to the shell prompt, and ^X^E is available by default to
permit editing of command lines.  Not everyone is bent on driving
their shell at breakneck speed, and if they are comfortable
undertaking this effort, I will not tell them they're living their
lives wrong.

6.  Some people will not notice the problem.  For them there is no bug,
and bliss is enjoyed.

It is only through the efforts of people in groups 2 and 4 that any
headway will be made on the problem.  That is where the Sisyphean effort
lies.  The good news is that this effort distributes...but only if
distributors decide not to hide the problems.

Regards,
Branden

[1] 
https://gitlab.archlinux.org/archlinux/packaging/packages/groff/-/commits/main
[2] 

Bug#769626: groff-base: want mailcap entries for .ms and .me files

[G. Branden Robinson]

reassign 769626 groff
retitle 769626 groff: want mailcap entries for .ms and .me files
thanks

Since the ms(7) and me(7) macro packages are not shipped in groff-base,
but in groff, these mailcap entries, if ever created, should be provided
in a file /usr/lib/mime/packages/groff in the "groff" package.

Regards,
Branden


signature.asc
Description: PGP signature

Bug#1041317: dgit: table too wide in man page, trashes autopkgtests

[G. Branden Robinson]

Package: dgit
Version: 9.13
Severity: Important
Justification: causes problems for everybody's autopkgtests

I noticed that groff 1.23.0-2 (and -1 before it) will be blocked from
ever migrating to testing due to an autopkgtest failure on EVERY
architecture.

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

So I downloaded the 2.4MB compressed autopkgtest log for groff 1.23.0-2
on amd64 and trawled through the 325,000+ lines of output looking for
the problem.  On the one hand, that is an obnoxiously huge amount of
information.  On the other, the log is annotated well enough that I was
able to quickly locate the problem.

Here are the juicy bits.

[...]
941s + for roff in $manpages
941s + section=1
941s + page=dgit
[...]
941s + cmd='man --warnings "$@" $section $page'
941s + eval 'man --warnings "$@" $section $page 2>&1 >/dev/null |tee 
/tmp/autopkgtest-lxc.3j70k01o/downtmp/autopkgtest_
tmp/dgit.1.txt-errs'
941s ++ man --warnings 1 dgit
941s ++ tee 
/tmp/autopkgtest-lxc.3j70k01o/downtmp/autopkgtest_tmp/dgit.1.txt-errs
941s :46: warning: table wider than line length minus 
indentation
[...]
941s RE (?^:^(?:(?^:^(?=a)b))$)|(?^:^(?:ERROR.*)$)|(?^:^(?:.* # table wider 
than line width)$)
941s unexpected: :46: warning: table wider than line length 
minus indentation
941s unexpected errors
941s END failed--call queue aborted, <> line 1.
[...]
941s  EXITING 22 
[...]
941s TEST FAILED
[...]
2435s manpages-format  FAIL non-zero exit status 16

That regex is sufficiently complex that I can't tell if it's trying to
filter the diagnostic message "table wider than line width" or not.  If
it is, the fact that I have recast the language of the diagnostic
message in groff 1.23.0 has fooled it.

It is a bad idea to rely on the exact wording of diagnostic messages.
That is one reason error conditions in many software systems are given
an unintelligible identifier.

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

Yes, the language in the regex could be updated if it's doing what I
think it is, but that just kicks the can down the road.  It is better
for groff to have the freedom to continue to improve its diagnostic
messages for the comprehension of the user.

So let's the fix the problem in the dgit man page.

Man pages are formatted for a width of 78n if the terminal width is 80
columns.  This origin of this practice is not well documented but
experience with groff upstream leads me to believe that it is a
workaround for bugs in GNU tbl(1).  (In AT Unix Version 7, they were
formatted for a line length of 65n, with a page offset of one tenth of
an inch.  On Western Electric Teletype Model 37 printing terminals.)

How wide is dgit's man page?

$ MANPAGER=cat MANWIDTH=80 command man --warnings dgit |wc -L
:46: warning: table wider than line length minus indentation
79

Hence the warning.

groff 1.22.4 didn't used to throw this warning in this circumstance.

That was a bug.

https://savannah.gnu.org/bugs/index.php?61854

Now it does.

The diagnostic is wholly legitimate.

Let's have a look:

$ MANPAGER=cat MANWIDTH=80 command man --warnings -Tascii dgit | sed -n 
'/DESCRIPTION/,/OPERATIONS/p'
:46: warning: table wider than line length minus indentation
DESCRIPTION
   dgit allows you to treat the Debian archive as if it were a git reposi-
   tory.   Conversely, it allows Debian to publish the source of its pack-
   ages as git branches, in a format which is directly useable by ordinary
   people.

   This is the command line reference.  Please read the tutorial(s):
   dgit-user(7)  for users: edit, build and share packages
   dgit-nmu-simple(7)for DDs: do a straightforward NMU
   dgit-maint-native(7)  for maintainers of Debian-native packages
   dgit-maint-debrebase(7)   for maintainers: a pure-git rebasish workflow
   dgit-maint-merge(7)   for maintainers: a pure-git merging workflow
   dgit-maint-gbp(7) for maintainers already using git-buildpackage
   dgit-sponsorship(7)   for sponsors and sponsored contributors
   dgit-downstream-dsc(7)setting up dgit push for a new distro

   See dgit(7) for detailed information about the data model, common prob-
   lems likely to arise with certain kinds of package, etc.

OPERATIONS

Yup, if we look carefully, we can see that the word "git-buildpackage"
encroaches into the right margin.

My recommendation is a simple tweak to the table format, stealing one en
of column separation to make the table fit.

$ diff -u ./dgit.1.orig ./dgit.1
--- ./dgit.1.orig   2023-07-17 06:03:04.465368217 -0500
+++ ./dgit.12023-07-17 06:03:26.309288710 -0500
@@ -42,7 +42,7 @@
 This is the command line reference.
 Please read the tutorial(s):
 .TS
-lb l.
+lb2 l.
 dgit-user(7)   for users: edit, build and share packages
 dgit-nmu-simple(7) for DDs: do a straightforward NMU
 dgit-maint-native(7)   for maintainers of 

Bug#1040440: groff: new upstream version 1.23.0 available

[G. Branden Robinson]

Package: groff
Version: 1.22.4-10
Severity: normal

[Bertrand has tagged and uploaded groff 1.23.0 as of an hour or so ago,
and reported it to the groff development list, but not as of this
writing, yet announced it to info-gnu.  I'm filing this report on my own
initiative as an impatient Debian-using jerk.]  The following text is an
announcement based on the "ANNOUNCE" file in groff's Git repository but
will only resemble, and not be identical to, Bertrand's official
announcement.]

We are pleased to announce the availability of groff 1.23.0.  Obtain it
from the GNU mirror network,

  https://ftpmirror.gnu.org/groff/groff-1.23.0.tar.gz

or, if the network is for some reason inoperative, directly from GNU.

  https://ftp.gnu.org/gnu/groff/groff-1.23.0.tar.gz

Ensure the integrity of your download by checking this source code
archive's cryptographic signature; see "Obtaining groff" below.

What is groff?
==

groff (GNU roff) is a typesetting system that reads plain text input
files that include formatting commands to produce output in PostScript,
PDF, HTML, or DVI formats or for display to a terminal.  Formatting
commands can be low-level typesetting primitives, macros from a
supplied package, or user-defined macros.  All three approaches can be
combined.

A reimplementation and extension of the typesetter from AT Unix, groff
is present on most POSIX systems owing to its long association with Unix
manuals (including man pages).  It and its predecessor are notable for
their production of several best-selling software engineering texts.
groff is capable of producing typographically sophisticated documents
while consuming minimal system resources.

  https://www.gnu.org/software/groff/

Changes
===

Changes since the most recent release candidate, 1.23.0.rc4, comprise
about 200 commits' worth of changes to documentation, including over
1,000 lines of updates to each of doc/groff.texi (our Texinfo manual)
and the man pages groff_mm(7) and eqn(1).

Since groff 1.22.4 was released in December 2018, 28 people have made a
total of over 4,500 commits.

$ git shortlog --summary 1.22.4..1.23.0
14  Bertrand Garrigues
14  Bjarni Ingi Gislason
 2  Bruno Haible
 6  Colin Watson
 1  Cynthia A. E. Livingston
 1  Damian McGuckin
31  Dave Kemper
29  Deri James
 2  Dorai Sitaram
 1  Edmond Orignac
 1  Eric Allman
  4778  G. Branden Robinson
 1  George HELFFRICH
33  Ingo Schwarze
 1  John Gardner
 4  Keith Bostic
25  Keith Marshall
 2  Michael J. Karels
 1  Nate Bargmann
 3  Nikita Ivanov
 1  Paul Eggert
71  Peter Schaffter
 1  Samanta Navarro
 1  T. Kurt Bond
 3  Tadziu Hoffmann
 1  Thomas Dupond
 2  ivan tkachenko
 1  наб

(Some possibly surprising names in the above are due to a rebase of
groff me(7) against 4.4BSD.)

Headline features nominated by our development community include:
  * a new 'man' macro, "MR", for formatting man page cross references;
  * hyperlinked text in terminals via the ECMA-48 OSC 8 escape sequence;
  * a new 'rfc1345' macro package, contributed by Dorai Sitaram,
enabling use of RFC 1345 mnemonics as groff special characters;
  * a new 'sboxes' macro package, contributed by Deri James, enabling
'ms' documents to place shaded and/or bordered rectangles underneath
any groff page elements (PDF output only);
  * 'mom' 2.5, a macro package contributed by Peter Schaffter;
  * the 'ms' package's new strings to assist subscripting;
  * Italian localization, including hyphenation patterns and macro
package string translations, thanks to Edmond Orignac; and
  * new hyphenation patterns for English.

For more on these and other feature changes, see "News" below.

Much attention has been given to fixing bugs, improving diagnostic
messages, and correcting and expanding documentation.  The previous
release shipped with three automated unit tests; this one ships with
over 160 unit and regression tests.

As of this writing, per the GNU Savannah bug tracker, the groff project
has resolved 431 problems as fixed for the 1.23.0 release.  Some of the
bugs we've corrected were over 30 years old.

Classifying these issues by type and the component of the project to
which they apply, we find the following.

  Type  Component
    -
  Build/installation   39   Core  102
  Crash/unresponsive   11   Driver: grohtml 7
  Documentation   111   Driver: gropdf 10
  Feature change   41   Driver: grops   2
  Incorrect behavior  131   Driver: grotty  4
  Lint 15   Driver: others/general  7
  Rendering/cosmetics  10   Font: devpdf1
  Test  6   Font: devps

Bug#1011666: need help with groff 1.23.0 (1.23.0~rc3-1 package prepared)

[G. Branden Robinson]

[added Alex Colomar to CC]

At 2023-02-26T13:30:58+, Colin Watson wrote:
> Sorry about that!  Feel free to grab me on IRC if I'm not replying to
> email.

Ah!  I'm never on IRC anymore.  I shifted to machines with power
management for everyday use; the loss of a nailed-up Internet connection
destroyed my IRC continuity.  (I hear there are ways around this...)

> > I am not a proficient gbp user, but I think I have done what is
> > necessary.
> 
> groff doesn't use gbp - it uses git-dpm.

Right.  You told me that before and the information trickled out of my
sieve-like brain.  TLA overload, so I was SOL.  FML.

> If you try to use gbp for it then you will probably get quite confused
> and so will I, so please don't.

Yes, indeed, thanks.

> First, move your current branch somewhere for reference, then make a new
> one.  Then, my routine for pulling in new upstreams looks roughly like
> this:
> 
>   git-dpm import-new-upstream -p $UPSTREAMTAG^{} --rebase-patched 
> ../foo.orig.tar.gz
>   # this imports the unpacked upstream tarball onto an upstream branch
>   # based on $UPSTREAMTAG, then drops you into a rebase session
> 
>   ... continue with rebase as needed, then once you're finished ...
> 
>   git-dpm update-patches --amend
>   # the --amend is just because the import-new-upstream step will
>   # already have recorded the new upstream on the branch you started
>   # from, but the history looks clearer if you bundle the rebase with
>   # that in a single merge commit, which this does
> 
> Then you can cherry-pick your packaging changes on top of this, as well
> as telling pristine-tar about the new upstream tarball based on the
> appropriate imported branch.
> 
> If you push the results to a temporary branch on salsa then I can look
> over them, which is probably a good idea since you're unfamiliar with
> git-dpm.

Thanks for this.  I also found
https://wiki.debian.org/PackagingWithGit/GitDpm which is helpful for my
fallback plan described below.

> > How do we move forward with this?  I am anxious about the closing of the
> > soft freeze window.
> 
> There is no way that this giant new upstream release will be suitable
> at this stage in the freeze; it's too late.  This should be targeted
> at experimental.

Oh, man.  That really sucks the wind out of my sails.  :(

(Good thing I did the packaging update work already!)

The freeze policy says, "Starting 2023-02-12, only small, targeted fixes
are appropriate for bookworm. We want maintainers to focus on small,
targeted fixes. This is mainly at the maintainers discretion, there will
be no hard rule that will be enforced."[1]

I was kind of hoping for an exercise of that discretion in favor of
getting the groff release in.  I hope you feel I have been attentive to
issues of implementation quality.  Nevertheless I admit I have a
conflict of interest as an active upstream (for the moment, still
unoffical) co-maintainer who wants to see his 4,000 commits including
400 bug fixes get into the next Debian release.[2]

But, also, Bertrand Garrigues (GNU maintainer, who has had to step back
quite a bit for personal reasons) is going to be unavailable to tag
1.23.0 final until _next_ weekend so I think groff and Debian release
timing may simply have a curse on them.

Please find attached my much more modest proposal.  Let's make sure the
groff in Debian bookworm will not throw confusing undefined register
warnings or drop text from man pages that begin to embrace groff 1.23's
new features.

Alex Colomar, the Linux man-pages maintainer, is eager to adopt the new
man(7) MR macro ASAP, so that's 2,500 man pages, many commonly used,
that will be undergoing a transition in the next few months, I expect.

Meanwhile I reckon I'll start praying to the gods of backports and point
releases.

Regards,
Branden

[1] https://release.debian.org/testing/freeze_policy.html#soft
[2] 
https://git.savannah.gnu.org/cgit/groff.git/tree/ANNOUNCE?id=99e5b4ae55a7c222f6bf57b355289a88d862478d

https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS?id=99e5b4ae55a7c222f6bf57b355289a88d862478d
commit 69e844df84929b8a6a440cbbafe55dcd134107b6
Author: G. Branden Robinson 
Date:   Mon Feb 27 06:27:17 2023 -0600

Rename and document patch

diff --git a/debian/changelog b/debian/changelog
index ca8a27d5..4f867aeb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,8 +1,14 @@
-groff (1.22.4-10) UNRELEASED; urgency=medium
+groff (1.22.4-10) unstable; urgency=medium
 
+  [ Colin Watson ]
   * Set upstream metadata fields: Repository-Browse.
 
- -- Colin Watson   Mon, 02 Jan 2023 13:38:52 -
+  [ G. Branden Robinson ]
+  * debian/patches/add-groff-1.23-forward-compatibility.patch: Prevent
+    formatter warnings and dropped man(7) document text when encountering
+documents written using new features of groff 1.23.
+
+ -- G. Branden Robinson   Mo

Bug#1011666: need help with groff 1.23.0 (1.23.0~rc3-1 package prepared)

[G. Branden Robinson]

[CCing debian-devel because I need some mentoring]

Hi Colin,

I've sent you a couple of mails over the past few months, but I don't
recall seeing a reply.

I am not a proficient gbp user, but I think I have done what is
necessary.

...except that I don't think I did the upstream merge/tagging right.

I suspect this because if I do a "git rebase -i origin", git goes crazy
and tells me I have merge conflicts.  None of the release candidates
were already staged even as reference points, so I had to wade into the
gbp documentation myself, and I probably screwed it up.

*** I have not PUSHED anything. ***

But after the point where I merged the upstream tarballs, things are
clean and I can rebase at will.

The upstream diffs are too gigantic to enclose (4,500+ commits since
groff 1.22.4), and not very interesting as they can be seen at groff's
own Git repo.

I'm attaching a git diff -p of my changes after that, meaning the actual
packaging work.

For the benefit of people reading this message, here are the commit
messages themselves (git log -r HEAD~21..HEAD).

commit 3cff7c6967e89d187efb160ce7d2a09af5ea82aa (HEAD -> master)
Author: G. Branden Robinson 
Date:   Sat Feb 25 22:53:06 2023 -0600

debian/changelog: Add upstream bug closers.

commit 1fd80f4151713e9f1d3cb52a4b749fa643776908
Author: G. Branden Robinson 
Date:   Sat Feb 25 22:29:27 2023 -0600

debian/groff{,-base}.install: Add new files

...provided upstream (en.tmac, hyphen.it, it.tmac, groff_font.5,
groff_out.5, groff_tmac.5, groff_man_style.7, groff_rfc1345.7,
FontMap-X11, ptx.tmac, rfc1345.tmac, sanitize.tmac, sboxes.tmac; see
upstream NEWS).

commit 56bf101afd21b9516775f58511e51d85dde06ef1
Author: G. Branden Robinson 
Date:   Sat Feb 25 22:09:23 2023 -0600

debian/groff{,-base}.install: Drop files

...that are no longer produced upstream (see upstream NEWS).

commit 9e99a662a4512e1f6656da2b9408f0f411abd311
Author: G. Branden Robinson 
Date:   Sat Feb 25 21:53:50 2023 -0600

debian/rules (confflags): Migrate option name.

...to "--with-appdefdir" from "--with-appresdir" per upstream NEWS.

commit 21ca0ea6c2162a95faf850b7f9c208b4d6d05374
Author: G. Branden Robinson 
Date:   Sat Feb 25 21:47:03 2023 -0600

Drop {meintro,meref,pic}.txt.

commit 58720f040d16da8bc868eca5466c91ee1a343889
Author: G. Branden Robinson 
Date:   Sat Feb 25 21:17:45 2023 -0600

debian/patches/clamp-negative-tab-stop*: Drop

Applied upstream in commit 6692653f7cae4116d4e70318f71b3d0808f2261f,
2021-09-11.

commit 01d76131b10c44f05ba7378a6193a5ce74f10fb9
Author: G. Branden Robinson 
Date:   Sat Feb 25 21:14:29 2023 -0600

debian/patches/destructor-segv.patch: Drop

Applied upstream in commit c788cf8c6bbe939fa11f7ec032e525a7e33f41b6,
2020-09-29.

commit 0323958c2ea85b86d24e07907e5718584fe5e746
Author: G. Branden Robinson 
Date:   Sat Feb 25 21:11:54 2023 -0600

debian/patches/document-sgr.patch: Resync

...with upstream.

commit 34942d9ebdb365be2765d1cf05850f7a8a6b78ad
Author: G. Branden Robinson 
Date:   Sat Feb 25 21:07:36 2023 -0600

debian/patches/bsd-updates.patch: Drop

Applied upstream in commit 5a8af7104f1c581bcfbad12b56033ad403b0afe1,
2019-12-21.

commit 915e5df22c31ce935de36322f1fa4db933c923e5
Author: G. Branden Robinson 
Date:   Sat Feb 25 21:04:51 2023 -0600

debian/patches/mdoc-Lk-arguments.patch: Drop

Applied upstream in commit 76e4db6e839904d2e2a28b29b483678214598f3b,
2019-01-12.

commit 34fe473ff1c2853d823d5acd3362aeef3e634c7b
Author: G. Branden Robinson 
Date:   Sat Feb 25 21:00:23 2023 -0600

debian/patches/avoid-perl-diamond.patch: Drop

Applied upstream in commit 27472b5ae548d3dbe933713d488d676708996253,
2019-01-24.

commit 4266e24f1d65d5e7c06ac3c2ae2a202c3d0629ce
Author: G. Branden Robinson 
Date:   Sat Feb 25 20:57:25 2023 -0600

debian/patches/sort-perl-hash-keys.patch: Drop

Applied upstream in commit fcf3dc68839d83bfba206d1febffd9514a71ee82,
2015-11-06.

commit cb1cbb55e73e877c73a45d070eed89179699f316
Author: G. Branden Robinson 
Date:   Sat Feb 25 20:52:43 2023 -0600

debian/patches/series: Drop display-utc-times.*

commit 2ec0236804bf60e18282526d343068e9c26d6df2
Author: G. Branden Robinson 
Date:   Sat Feb 25 20:49:14 2023 -0600

debian/patches/mmse-note.patch: Resync w/ upstream

commit e8e7c6ce1e8267bbf6c65ce5910140ccc5a8993a
Author: G. Branden Robinson 
Date:   Sat Feb 25 20:45:39 2023 -0600

debian/patches/load-desc-failure.patch: Resync

...with upstream.

commit b7dc5d92ac984184ab30aef76e5d21752a044fe9
Author: G. Branden Robinson 
Date:   Sat Feb 25 20:40:55 2023 -0600

debian/patches/papersize-config.patch: Resync

...with upstream.

commit bb6d8e31ae4f60afd1ede232618dbff17e64ac87
Author: G. Branden Robinson 
Date:   Sat Feb 25 20:35:20 2023 -0600

debian/patches/extratmacdirs.patch: Resync

...with upstream.

commit c2714677d1d1bbb46a311bfa41676cfa48b3e210

Bug#415292: libgl1-mesa-glx: assertion failure in libGL.so.1

[G. Branden Robinson]

At 2023-01-02T18:54:02+0100, Fabio Pedretti wrote:
> upstream bug report was closed with:
> "This code has been rewritten since and almost certainly fixed,
> closing."

Jesus.  I'd never trust a claim like that without output from a formal
verification suite to confirm it.

I think we may have a brogrammer at play.

Regards,
Branden


signature.asc
Description: PGP signature

Bug#1021961: groff(7) mangled .ft documentation

[G. Branden Robinson]

package groff
tag 1021961 + upstream
thanks

It seems I can never learn how to get the magic "-1" bug number to work
for me.  I suspect it is a curse Anthony Towns laid on me lo these many
years ago...


signature.asc
Description: PGP signature

Bug#906091: groff: .tm writes troff special character syntax to stderr

[G. Branden Robinson]

package groff groff-base
severity 906091 wishlist
reassign 906091 groff-base
retitle groff-base: troff `tm` request has no means of writing non-ASCII 
characters
tag 906091 + upstream
thanks

This would be a significant new feature.

See https://savannah.gnu.org/bugs/?63074#comment9 for lengthy analysis
of this and related feature gaps.

Regards,
Branden


signature.asc
Description: PGP signature

Bug#312935: groff-base: grotty -c should be - no it MUST be - made the default

[G. Branden Robinson]

At 2022-09-26T15:40:39-0500, G. Branden Robinson wrote:
> > less interprets b^Hbo^Hol^Hld^Hd by outputting the correct escape
> > sequences for the terminal in use.
> 
> No, it doesn't, and cannot, because that representation form is
> ambiguous when the character to be overstruck is an underscore.  This
> actually comes up in man pages.  Somewhere in the Debian BTS there is
> an exhibit from a real page about this, but I don't recall right now
> where.

I found it.  Mark Wooding pointed this out in 2020.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963490#5

I was wrong about Mark supplying a specimen from a real-world man page,
but he did offer a reproducer which enabled me to find a few.

Here's a more full reproducer (it still doesn't take much).  Remember,
for this to behave badly you _have_ to use the celebrated SGR
disablement feature.

.TH demo 1 2022-09-26 "a demonstration"
.IB x _mid_ y

In the output you will see that the first underscore is underlined
("italicized") while the second is boldfaced.  Obviously from the macro
arguments they should both be bold.  On my Debian bullseye system, ul(1)
seems to guess better with this input than less 581.2 does.  (I use a
more recent version of less because I needed it to test grotty's OSC 8
support.)

With the overstriking approach there is simply no way around this
guesswork.  One could of course propose some sort of in-band signaling
protocol utterly alien to the fluttering standard of the Teletype Model
37 around which opponents of grotty's SGR output have rallied.

The cowpoke(1) man page in Debian offers several exhibits of
misrendering arising from this ambiguity.

Here's one paragraph.

   SIGN_KEYID
  If this option is set, it is expected to contain the gpg
  key ID to pass to debsign(1) if the packages are  to  be
  remotely  signed.   You  will  be  prompted  to  confirm
  whether you wish to sign the packages after  all  builds
  are  complete.   If  this  option  is  unset or an empty
  string, no attempt to sign packages will  be  made.   It
  may be overridden on an arch and dist specific basis us‐
  ing the arch_dist_SIGN_KEYID option described below,  or
  per‐invocation with the --sign command line option.

This email strips typeface changes, of course, but anyone wanting to
continue to prosecute their mistaken and erroneous position regarding
this groff feature can observe that the underscores after "arch" and
"dist" are underlined ("italicized") when they should be bold.

Observe the page source.

made.  It may be overridden on an \fIarch\fP and \fIdist\fP specific basis using
the
.IB arch _ dist _SIGN_KEYID
option described below, or per-invocation with the \fB\-\-sign\fP command line
option.

Here are some other pages worth investigating.

/usr/share/man/man1/pamdice.1.gz
/usr/share/man/man1/winicontoppm.1.gz
/usr/share/man/man7/lvmraid.7.gz

I emphasize that there's nothing incorrect about the man page source
code above.  Pages misrender because overstriking for font changes is an
inherently limited and ambiguous convention that simply cannot reliably
produce correct output in some cases.

If you want correctness, enable SGR.

> As much as I'd like to think that some grief could have been avoided
> by naming grotty something like "groansi" instead, I suspect the
> amount would be vanishingly small.  From what I've seen, users
> scandalized by the violence that less(1) does to grotty's output do
> not, as a first recourse, research the problem.  Instead they file
> bugs like this one.
> 
> Nevertheless, I have given serious consideration to making grotty(1)
> use the terminfo library to determine terminal capabilities; its
> current approach is admittedly crude.  It seems like it would be
> friendly to users to _ask_ their terminals, or at least their $TERM
> variables, what they claim to be capable of.

I should add that even if I do this, I don't expect _any_ observable
reduction in the number of complaints.  xterm (and ncurses) maintainer
Thomas Dickey's website regales the reader with story after story of
users (and GNU/Linux distributions) who changed TERM environment
variable settings and terminal database descriptions, practicing their
marksmanship, if not blindly, then in terribly low light.

The problem is that the set of people who hate the fact that grotty
produces SGR considerably overlaps the set of people who clamored for
256-color (and subsequently "true color") support in xterm, because they
wanted skinnable color schemes for Vim and similar.  (Admittedly, some
of the pressure in this area was relieved when the Atom IDE came along
and skimmed a lot of these people off.)

The people in the large intersection of these sets want simultaneous
fidelity to ultra-modern x

Bug#1016412: dh-make: manpage.1.ex: Incorrect formatting for dash

[G. Branden Robinson]

Hi Mike,

At 2022-07-31T11:54:13-0400, Mike Bianchi wrote:
> I come into this very late and without having studied the on-going
> discussion.  For this I apologize.
> 
> > However, since many manual pages in existence are incorrect, and
> > they use '-'  >>> when they should use '\-' <<< ...
> 
> Let me take exception to the claim that  '-'  should be '\-' .  

...and permit me to rebut you!  ;-)

> In manual pages of UNIX/Linux commands, system calls, libraries, etc.
> all the examples are for strings and negative numbers expressed in
> ASCII characters.
>   man(1)
>   execve(2)
>   fileno(3)
>  :

Well, no, they're not.

Let's go to what I have earlier referred to exaggeratedly as the
"Ur-source of all correct practice", the Unix Version 7 Programmer's
Manual (1979).  Surveying its man pages we find exhibits like the
following.

Believe it or not, this is a _brief_ sampling.  I've drawn exhibits from
every section of the manual and attempt to show usage of \- in several
correct context.  (The sharp eye will spot an authentic solecism.)

man5/passwd.5-.SH NAME
man5/passwd.5:passwd \- password file
man5/passwd.5-.SH DESCRIPTION

man5/filsys.5-Thus is i-list is
man5/filsys.5:.IR s_isize \-2
man5/filsys.5-blocks long.

man5/filsys.5-array contains, in
man5/filsys.5:.I "s_free[1], ... , s_free[s_nfree\-1],"
man5/filsys.5-up to NICFREE free block numbers.

man5/a.out.5-if the program was loaded
man5/a.out.5:with the `\-s' option
man5/a.out.5-of

man5/mpxio.5-the operating system aligns records
man5/mpxio.5:on short (i.e. 16\-bit) boundaries
man5/mpxio.5-by skipping bytes when necessary.

man5/mpxio.5-.ti -.5i
man5/mpxio.5:M_WATCH \- a process `wants to attach' on this channel.
man5/mpxio.5-The second parameter is the 16-bit

man6/reversi.6-[ [
man6/reversi.6:.B \-r
man6/reversi.6-]

man6/ching.6-six straight
man6/ching.6:(\-\-\-)
man6/ching.6-and broken
man6/ching.6:(\-\ \-)
man6/ching.6-lines.

man6/ching.6-(lines)
man6/ching.6:using yarrow\-stalks
man6/ching.6-or tossed coins.

man6/ching.6-which drives a simulated
man6/ching.6:coin\-toss divination.
man6/ching.6-The answer is then piped through

man6/arithmetic.6-[
man6/arithmetic.6:.B +\-x/
man6/arithmetic.6-] [ range ]

man6/arithmetic.6-to be generated;
man6/arithmetic.6:.B +\-x/
man6/arithmetic.6-respectively cause

man6/arithmetic.6-problems will be mixed in random order; default is
man6/arithmetic.6:.B +\-
man6/arithmetic.6-.PP

man8/boot.8-177412
man8/boot.8:005040  clr \-(r0)  / rkda cleared by start
man8/boot.8:010040  mov r0,\-(r0)
man8/boot.8:012740  mov $5,\-(r0)
man8/boot.8-05

man8/boot.8-176726
man8/boot.8:005040  clr \-(r0)
man8/boot.8:005040  clr \-(r0)
man8/boot.8:005040  clr \-(r0)
man8/boot.8:010040  mov r0,\-(r0)
man8/boot.8:012740  mov $5,\-(r0)
man8/boot.8-05

man1/lint.1-[
man1/lint.1:.B \-abchnpuvx
man1/lint.1-]

man1/ld.1-Except for
man1/ld.1:.BR \-l ,
man1/ld.1-they should appear before the file names.
man1/ld.1-.TP
man1/ld.1:.B  \-s
man1/ld.1-`Strip' the output, that is, remove the symbol table

man1/awk.1-and are built using the operators
man1/awk.1:+, \-, *, /, %,  and concatenation (indicated by a blank).
man1/awk.1:The C operators ++, \-\-, +=, \-=, *=, /=, and %=
man1/awk.1-are also available in expressions.

man1/awk.1-or by using the
man1/awk.1:.BI \-F c
man1/awk.1-option.

man1/awk.1-.nf
man1/awk.1: { for (i = NF; i > 0; \-\-i) print $i }
man1/awk.1-.fi

man1/quot.1m-.TP
man1/quot.1m:.B \-n
man1/quot.1m-Cause the pipeline
man1/quot.1m:.B "ncheck filesystem | sort +0n | quot \-n filesystem
man1/quot.1m-to produce a list of all files and their owners.
man1/quot.1m-.TP
man1/quot.1m:.B \-c
man1/quot.1m-Print three columns giving file size in blocks, number of

man1/make.1-.I makefile
man1/make.1:is `\-', the standard input is taken.
man1/make.1-More than one
man1/make.1:.B \-f
man1/make.1-option may appear

man7/term.7-.nf
man7/term.7:.ta \w'450\-12\-8  'u
man7/term.7-1620DIABLO 1620 (and others using HyType II)
man7/term.7:1620\-12same, in 12-pitch mode
man7/term.7-300 DASI/DTC/GSI 300 (and others using HyType I)
man7/term.7:300\-12 same, in 12-pitch mode
man7/term.7-300sDASI/DTC 300/S
man7/term.7:300s\-12same, in 12-pitch mode
man7/term.7-33  TELETYPE\*R Model 33
man7/term.7-37  TELETYPE Model 37
man7/term.7:40\-2   TELETYPE Model 40/2
man7/term.7-43  TELETYPE Model 43
man7/term.7-450 DASI 450 (same as Diablo 1620)
man7/term.7:450\-12 same, in 12-pitch mode
man7/term.7:450\-12\-8  same, in 12-pitch, 8 lines/inch mode
man7/term.7-735 Texas Instruments TI735 (and TI725)

man2/kill.2-.PP
man2/kill.2:If the process number is \-1, and the user is the super-user,
man2/kill.2-the signal is broadcast universally

man2/kill.2-Zero is returned if the process is killed;
man2/kill.2:\-1 is returned if the process does not

Bug#1011666: groff 1.23.0 build dependencies will change

[G. Branden Robinson]

I need to amend my recommendations slightly.

pkg-config _will_ need to remain in Build-Depends due to a very recent
change in groff upstream.

> 2022-05-26  G. Branden Robinson 
>
> * bootstrap.conf: Add "pkg-config" to `buildreq`.  Not having it
> causes pretty horrible macro expansion problems and diagnostics
> when 'autoreconf' is run; they're still pretty bad even if you
> use `AC_REQUIRE` and `m4_pattern_forbid`.  So just demand it.

Regards,
Branden


signature.asc
Description: PGP signature

Bug#1011666: groff 1.23.0 build dependencies will change

[G. Branden Robinson]

At 2022-05-26T13:13:44+0100, Colin Watson wrote:
> On Wed, May 25, 2022 at 07:55:10PM -0500, G. Branden Robinson wrote:
> > I apologize for filing this bug report a bit prematurely, but I've
> > been working on building groff in a bullseye chroot lately to
> > prepare for groff 1.23.0.rc2, and I wanted to document some findings
> > while they were fresh in my mind.
> 
> Thanks for this research!

My pleasure!

> > * Add a dependency on m4.
> > 
> >   o m4 is now required to build.  Any m4 that implements the
> >   features documented in the Version 7 Unix m4(1) man page, and the
> >   `-D` option, should suffice.
> 
> It'll be there anyway due to debhelper → dh-autoreconf → autoconf →
> m4, but I generally approve of directly specifying direct
> (build-)dependencies.

Agreed.  To do otherwise discards important advantages of modularity and
a dependency resolution system that copes with transitive relationships.

> > * Add a dependency on "cups-client | cups-bsd | lpr".
> > 
> >   This is not due to new development.  I confess to being puzzled
> >   why this build dependency isn't already present.  groff's
> >   configure script has for years looked for an installed "lpr"
> >   command, then fallen back to "lp".  Only "groff -l" uses the
> >   detected spooler command, however, and maybe people just don't do
> >   that very often.  I think it is possible that for chroot-built
> >   groff packages in Debian--for those done by the buildds, for
> >   instance--the compiled groff command is silently ignoring the
> >   flag.
> > 
> > https://git.savannah.gnu.org/cgit/groff.git/tree/src/roff/groff/groff.cpp#n408
> 
> Isn't this handled by passing PSPRINT=lpr to configure, as we do in
> debian/rules?  I generally prefer this approach over
> build-dependencies in cases where the build-dependency would just be
> for path detection and isn't actually used during the build.
> 
> The fact that /usr/share/groff/1.22.4/font/devps/DESC ends with "print
> lpr" suggests that this is working.

You are quite right.  I withdraw that suggestion.  I guess if someone
doesn't want a BSD-style print spooler installed but does have an lp(1)
command and still wants to use 'groff -l', they'll have to edit the DESC
files for the output devices...which aren't conffiles.  Yuck.

Maybe grops(1), grodvi(1), grolbp(1), and grolj4(1) (and gropdf(1)?)
should grow an option to override the "print" directive in their DESC
files.

This is probably not urgent.  The lack of bug reports from people
satisfying the demographic sector I characterized above suggests that
their numbers are few.

> > Please let me know if I can be of assistance.
> 
> Would you like to co-maintain the package?  You're already much more
> active upstream than I am and you've been doing lots of bug
> maintenance; I'd be happy for you to do that with a maintainer hat.

Thank you for this gracious invitation!  I've been looking for a way
back into measurable Debian development activity.  I accept.

> (My only conditions are that I'd like to keep using git-dpm for patch
> maintenance and dgit for uploads.)

Certainly.  I have no revolutionary aspirations there.  Nor, I'm ashamed
to admit, a basic level of competence with git-gpm.  I seem to remember
using dgit and git-buildpackage the last time I uploaded a package,
which was quite some time ago thanks to my upstream slowing WAY down.

I would ask that you to take the decision about the man/mdoc/UTF-8 glyph
contretemps[1] (which boils down to: patch {man,mdoc}.local or not?); as
the upstream instigator of the controversial change, I'm afraid I'm
conflicted out on the issue.

Unless you agree with me but would prefer I wore the blame for it.  3;-)

Thank you again.  It will be strange to have responsibility for a
package in main again.  I might feel duty-bound to cast DPL election
ballots...

Regards,
Branden

[1] https://lists.gnu.org/archive/html/groff/2022-05/msg00050.html et seq.


signature.asc
Description: PGP signature

Bug#1011666: groff 1.23.0 build dependencies will change

[G. Branden Robinson]

Package: groff
Version: 1.23.0-1
Severity: wishlist

I apologize for filing this bug report a bit prematurely, but I've been
working on building groff in a bullseye chroot lately to prepare for
groff 1.23.0.rc2, and I wanted to document some findings while they were
fresh in my mind.

Here is the current build-dependencies declaration for Debian's groff
package.

Build-Depends: bison (>= 1:1.875b), debhelper-compat (= 12), dh-exec, dpkg-dev 
(>= 1.17.0~), ghostscript, netpbm, psutils, x11proto-core-dev, libx11-dev, 
libxmu-dev, libxt-dev, libxaw7-dev, texinfo (>= 4.8), pkg-config, 
libuchardet-dev, gsfonts, poppler-utils 

When packaging groff 1.23.0, some changes should be made.  I'll quote
the 'NEWS' file for rationales.

* Drop the bison dependency.

  o Building groff from its distribution archive no longer requires byacc
(or GNU Bison) to be installed.

* Drop the texinfo dependency.

  o Because all generated forms of groff's Texinfo manual are now included
in the distribution archive, building from that archive no longer
depends on GNU Texinfo or a TeX installation (the latter was only
required for the "doc" target, which had to be explicitly given).

* Add a dependency on m4.

  o m4 is now required to build.  Any m4 that implements the features
documented in the Version 7 Unix m4(1) man page, and the `-D` option,
should suffice.

* Add a dependency on "cups-client | cups-bsd | lpr".

  This is not due to new development.  I confess to being puzzled why
  this build dependency isn't already present.  groff's configure script
  has for years looked for an installed "lpr" command, then fallen back
  to "lp".  Only "groff -l" uses the detected spooler command, however,
  and maybe people just don't do that very often.  I think it is
  possible that for chroot-built groff packages in Debian--for those
  done by the buildds, for instance--the compiled groff command is
  silently ignoring the flag.

https://git.savannah.gnu.org/cgit/groff.git/tree/src/roff/groff/groff.cpp#n408

I looked at the BuildProfileSpec page[1], and while bootstrapping is
discussed there, I couldn't find a spec that would be applicable to
groff for bootstrapping it.  ("nocheck" is already used in the event
groff's test suite is not run.)  But in case it's useful to know, here
are all the (non-Debian-packaging-process-related) build-dependencies
that could be dropped for such a profile.  In other words, groff will
still 'configure' and 'make' without these, albeit with reduced
functionality.

ghostscript
netpbm
psutils
x11proto-core-dev
libx11-dev
libxmu-dev
libxt-dev
libxaw7-dev
pkg-config
libuchardet-dev
gsfonts

And of course the already-profiled "poppler-utils".

The aforementioned "cups-client | cups-bsd | lpr" is also not necessary
for bootstrapping.  "m4" _is_ (or will be, in groff 1.23.0).

Please let me know if I can be of assistance.

Regards,
Branden

[1] https://wiki.debian.org/BuildProfileSpec


signature.asc
Description: PGP signature

Bug#192144: groff-base: eqn formats complex matrices badly on nroff devices

[G. Branden Robinson]

package groff groff-base
forwarded 192144 https://savannah.gnu.org/bugs/?62298
thanks

I've opened a ticket for this upstream.  In reproducing it, I found
diagnostics that no one ever commented on before which suggest that eqn
could be improved, even if it doesn't ultimately make the input
useful in this case (that remains to be seen).

Thanks for Colin for the simple reproducer.

Regards,
Branden


signature.asc
Description: PGP signature

Bug#541688: groff: Patch for unicode box drawing characters in groff_char

[G. Branden Robinson]

package groff groff-base
retitle 541688 groff-base: want Unicode box drawing characters in groff_char(7)
tag 541688 + patch upstream
forwarded 541688 https://savannah.gnu.org/bugs/?62296
thanks

I recommend closing this 12 year-old bug.

1. If it wants to add groff special character identifiers of the form
   "U2500" to the predefined groff glyph list, it's "wontfix".
2. If it wants to document glyphs that are not accessible via a groff
   special character identifier _apart_ from those selecting Unicode
   character by code point, it's "wontfix".
3. If it is addressing deficiencies in the erstwhile page-local `C2`
   macro used by the groff_char(7) page, it is invalid, and has been
   since since 2012.

I don't think it would benefit Debian any to deviate from upstream
practice as regards points 1 and 2.

Further details are available at the forwarded-to- URL.

Regards,
Branden


signature.asc
Description: PGP signature

Bug#982302: groff: bad ghostscript version in the font path

[G. Branden Robinson]

package groff
forcemerge 982302 952922
thanks

Hi Marc,

Your bug report #952922 appears to have been resolved by the closure of
bug #982302.

Regards,
Branden


signature.asc
Description: PGP signature

Bug#488213: groff-base: Escaped version of apostroph (\') does not display in ISO-8859-15 locale

[G. Branden Robinson]

I reiterate (after ~17 months) that the suggestion in this bug report is
ill-advised.

ISO 8859-15 (Latin-9) simple _has_ no code point for the acute accent,
any more than ASCII does.

Further, as Jakub Wilk pointed out, it's just plain wrong semantics to
use the \' escape sequence to obtain any form of quotation mark.  All
known *roffs going back to Osanna's 1973 troff define this escape
sequence as representing an acute accent.

Any man page that uses \' to attempt to obtain a quotation mark is in
error.

I suggesting tagging this bug "wontfix" and closing it.

Regards,
Branden


signature.asc
Description: PGP signature

Bug#409046: groff: Empty files in /usr/share/doc/groff/html/img

[G. Branden Robinson]

Hi Colin,

As you noted in 2009, this is no longer a problem with the Debian
package.

$ dpkg -L groff | grep /img | xargs test -f  && echo | cksum \
  | awk '/$2 == 0/ {print "$3 is empty"}'

This produces no errors apart from complains from cksum about operating
on a couple of directories.

> You'll find that this has gone away for now, but that's only because I
> switched from doing my maintainer uploads on powerpc to doing them on
> i386, and it seems to work properly when I build it on my laptop. On
> the i386 build daemon, no dice. On all of the Ubuntu build daemons, no
> dice.  On the other hand *some* of the Debian build daemons seem to
> get it right. I can't reproduce it in a debootstrapped Ubuntu chroot
> with just the build-dependencies installed. I have no idea why any of
> this is.
> 
> The error message during build is as follows (unfortunately rather
> uninformative):
> 
>   Calling `pnmcut 108 293 583 52 < /tmp/groff-page-sONKf1 | pnmcrop
>   -quiet | pnmtopng -background white -transparent white >
>   img/pic1.png' returned status 256

That sure _looks_ like a wait(2)-encoded exit status which at the shell
level would be '-1', indicating a command not found.  I can't be sure,
but it sure _looks_ like one of the PNM tools must have been
unavailable.

groff's build system has been converted to Automake since 2009 but I
still see no evidence of an Autoconf check for the PNM tools.  That
seems like an upstream defect.  If you'd like, we can reimagine this one
as an upstream bug.

> With any luck this mail will serve as notes to myself in case I manage
> to figure it out later.

Any thoughts after having had some time to cogitate?  :)

Regards,
Branden


signature.asc
Description: PGP signature

Bug#551111: groff: wrong escape sequence for acute accent

[G. Branden Robinson]

tag 55 + upstream fixed-upstream
thanks

This bug was found and corrected independently.  The fix is expected in
the groff 1.23 release.

commit 2bd31bb3f2de8e8ff21540ca7c247025903d8acc
Author: G. Branden Robinson 
Date:   Thu Feb 13 20:25:08 2020 +1100

groff(7): Fix style and correctness issues.

* Add a sentence calling out the characters (key engravings) that
  most often come to grief on output devices.  Add cross-reference to
  groff_char(7).
* Drop language later on describing what the ' and ` characters do when
  "unescaped", which was incompletely presented, not done for other
  characters, and was erroneously presented for ' in the first place.

* Follow the advice we give; in literal input examples, use \[ha]
  instead of ^, and \[ti] instead of ~.

* Replace many uses of \[cq] with \[aq] when the latter is what is
  meant: in input sequences, the .tl example, and a page-private macro
  definition for documenting escape sequences.
* Delete unused 'escq' macro.
* Don't refer to "'" as a "single quote" in an input context.  It's the
  apostrophe in all modern character encodings.
* Mention that how the apostrophe is rendered depends on the output
  device.

* Recast discussion of the space character in input.  Rewrite for
  clarity.  Discuss how spaces are treated when filling and/or
  adjustment are enabled.
* Add \0 to the list of "spaces of definite width".  Hat tip to Dave
  Kemper for prompting this.
* Add mention of the nonbreaking space escape \~.

* Note end-of-sentence detection in discussion of spaces and newlines.

* Drop mentions of ASCII; as noted in recent discussions of the \[oq]
  escape and Latin-1 encoding (-Tlatin1), most people who purport to
  viewing nroff output on an ASCII device probably are not.  It's been a
  UTF-8 world in *nix land for a long time now; mentions of ASCII should
  be confined to specialized situations.

* More closely align the names of characters represented by the \[de]
  and \[rs] escapes with their Unicode codepoint descriptions.  More
  work could be done on this page in this respect.

* Add \[ha] and \[ti] to the list of character escapes.

* Correct erroneous presentation of a \´ (backslash, acute accent)
  escape.  Once again, an apostrophe is meant.

* Fix minor formatting inconsistencies (not visible on output).

Misinformation about acute accents and apostrophes in this page was
presented with such unrelenting dedication that I have to wonder if it
was originally written by someone using a German keyboard with the acute
accent (´) key remapped to apostrophe (').  See
<https://www.cl.cam.ac.uk/~mgk25/ucs/apostrophe.html>.

Regards,
Branden


signature.asc
Description: PGP signature

Bug#892423: man -Tutf8 /usr/share/man/ja/man5/apt_preferences.5.gz (and several others) enter infinite loop

[G. Branden Robinson]

tag 892423 + upstream fixed-upstream
forwarded 892423 https://savannah.gnu.org/bugs/?44018
thanks

This bug is the same as upstream Savannah #44018.

Bisecting ran into problem with gnulib (sigh), but I suspected I knew
which patch to cherry-pick onto a check of the the groff 1.22.4 tag, and
luckily I turned out to be right.

How I tested:

zcat /usr/share/man/ja/man5/apt_preferences.5.gz \
  | ./build/test-groff -Tutf8 -k -b -man -mja

There _is_ a diagnostic when generating this page.  Unfortunately no one
yet understands why an output line is being measured as zero-length.

$ zcat /usr/share/man/ja/man5/apt_preferences.5.gz \
  | ./build/test-groff -Tutf8 -k -b -man -mja > /dev/null
troff: :594: warning [p 6, 7.2i]: line has non-positive width 0m
troff: :595: warning [p 6, 7.2i]: can't break line

The commit you want to cherry-pick is
bcdf2f4c7c28328c711c6a7ac2ea17f2ecd5cdd4.

I'm attaching it for extra reassurance.

Regards,
Branden
commit bcdf2f4c7c28328c711c6a7ac2ea17f2ecd5cdd4
Author: G. Branden Robinson 
Date:   Wed Oct 21 00:29:24 2020 +1100

src/roff/troff/env.cpp: Avoid infinite loop.

* src/roff/troff/env.cpp (environment::possibly_break_line): Emit break
  warning and return if the output width is not positive.  The code
  assumes that it will be and loops infinitely if it isn't.  I _think_
  this is because we're not able to get width data for (some?) CJK
  glyphs.  Based on a patch by Osamu Sayama.

Fixes <https://savannah.gnu.org/bugs/index.php?44018>.

diff --git a/ChangeLog b/ChangeLog
index ce0b7ea83..d9ccebcbc 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,18 @@
+2020-10-20  G. Branden Robinson 
+
+	* src/roff/troff/env.cpp (environment::possibly_break_line):
+	Emit break warning and return if the output width is not
+	positive.  The code assumes that it will be and loops infinitely
+	if it isn't.  I _think_ this is because we're not able to get
+	width data for (some?) CJK glyphs.  Based on a patch by Osamu
+	Sayama.
+
+	* src/roff/groff/tests/\
+	do_not_loop_infinitely_when_breaking_cjk.sh: Test it.
+	* src/roff/groff/groff.am: Run test.
+
+	Fixes <https://savannah.gnu.org/bugs/index.php?44018>.
+
 2020-10-20  G. Branden Robinson 
 
 	* src/preproc/tbl/table.cpp (table::init_output): Save the value
diff --git a/src/roff/troff/env.cpp b/src/roff/troff/env.cpp
index 9cbc13048..cb6b1b1af 100644
--- a/src/roff/troff/env.cpp
+++ b/src/roff/troff/env.cpp
@@ -2142,6 +2142,14 @@ void environment::possibly_break_line(int start_here, int forced)
 }
 distribute_space(pre, bp->nspaces, extra_space_width);
 hunits output_width = bp->width + extra_space_width;
+// This should become an assert() when we can get reliable width
+// data from CJK glyphs.  See Savannah #44018.
+if (output_width <= 0) {
+  double output_width_in_ems = output_width.to_units();
+  output_warning(WARN_BREAK, "line has non-positive width %1m",
+		 output_width_in_ems);
+  return;
+}
 input_line_start -= output_width;
 if (bp->hyphenated)
   hyphen_line_count++;
@@ -4107,3 +4115,9 @@ void init_hyphen_requests()
   init_request("hpfa", hyphenation_patterns_file_append);
   number_reg_dictionary.define(".hla", new hyphenation_language_reg);
 }
+
+// Local Variables:
+// fill-column: 72
+// mode: C++
+// End:
+// vim: set cindent noexpandtab shiftwidth=2 textwidth=72:


signature.asc
Description: PGP signature

Bug#991633: mdoc: At: 32V is "[AT] UNIX/32V", not "Version 32V AT UNIX"

[G. Branden Robinson]

tag 991633 + upstream fixed-upstream
thanks

As наб noted, this was fixed in upstream commit 21d307286.

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

The fix is expected in the groff 1.23.0 release.

Regards,
Branden


signature.asc
Description: PGP signature

Bug#692765: Issue in man page ascii.7.po

[G. Branden Robinson]

Hi, Helge!

At 2022-03-14T12:29:26+0100, Helge Kreutzmann wrote:
> Just to ensure that credit is where credit is due: This was a bug
> report by a l10n/i18n team member of Debian and the fix was developed
> by Colin Watson, see:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692765
> 
> Thanks for confirmation and fixing it upstream, so downstreams
> (translations) get it automatically.

For the sake of neurotic precision, I (and the groff documentation I've
been updating over the past 5 years) term the `\&` escape sequence a
"non-printing input break", not a "zero-width character" of any sort.
The reasons for this are that (1) `\&` affects how the formatter (troff)
interprets its _input_, and (2) this escape sequence does not directly
produce _anything_ in formatted output.  We're familiar with zero-width
space characters from HTML and Unicode, but such a concept is not really
applicable to *roff formatters.

To answer the question you raised in the Debian bug's history...

> Why don't you need it for line 1 as well? There is an ! also.

The "!" over on the left-hand side of the table has only one space after
it, not two.  For a potential end-of-sentence character (".", "?", and
"!" by default) to be recognized as ending a sentence, it must be
followed by a newline or _at least_ two spaces.

I have tried to make the formatter's behavior very clear in the groff
Texinfo manual[1].  I'd appreciate critique of any ways in which it
fails to be.

Regards,
Branden

[1] https://git.savannah.gnu.org/cgit/groff.git/tree/doc/groff.texi#n4775


signature.asc
Description: PGP signature

Bug#243238: fixed upstream

[G. Branden Robinson]

package groff
tag 243238 + upstream fixed-upstream
thanks

Fix expected in groff 1.23.0.

commit 964ea49e4ac5908811f1c434c7d752d1eb2f4179
Author: G. Branden Robinson 
Date:   Tue Mar 8 01:44:51 2022 +1100

[fonts]: Fix \[oq] and \[cq] in X11 text fonts.

* /font/devX100-12/CB:
* /font/devX100-12/CBI:
* /font/devX100-12/CI:
* /font/devX100-12/CR:
* /font/devX100-12/HB:
* /font/devX100-12/HBI:
* /font/devX100-12/HI:
* /font/devX100-12/HR:
* /font/devX100-12/NB:
* /font/devX100-12/NBI:
* /font/devX100-12/NI:
* /font/devX100-12/NR:
* /font/devX100-12/TB:
* /font/devX100-12/TBI:
* /font/devX100-12/TI:
* /font/devX100-12/TR:
* /font/devX100/CB:
* /font/devX100/CBI:
* /font/devX100/CI:
* /font/devX100/CR:
* /font/devX100/HB:
* /font/devX100/HBI:
* /font/devX100/HI:
* /font/devX100/HR:
* /font/devX100/NB:
* /font/devX100/NBI:
* /font/devX100/NI:
* /font/devX100/NR:
* /font/devX100/TB:
* /font/devX100/TBI:
* /font/devX100/TI:
* /font/devX100/TR:
* /font/devX75-12/CB:
* /font/devX75-12/CBI:
* /font/devX75-12/CI:
* /font/devX75-12/CR:
* /font/devX75-12/HB:
* /font/devX75-12/HBI:
* /font/devX75-12/HI:
* /font/devX75-12/HR:
* /font/devX75-12/NB:
* /font/devX75-12/NBI:
* /font/devX75-12/NI:
* /font/devX75-12/NR:
* /font/devX75-12/TB:
* /font/devX75-12/TBI:
* /font/devX75-12/TI:
* /font/devX75-12/TR:
* /font/devX75/CB:
* /font/devX75/CBI:
* /font/devX75/CI:
* /font/devX75/CR:
* /font/devX75/HB:
* /font/devX75/HBI:
* /font/devX75/HI:
* /font/devX75/HR:
* /font/devX75/NB:
* /font/devX75/NBI:
* /font/devX75/NI:
* /font/devX75/NR:
* /font/devX75/TB:
* /font/devX75/TBI:
* /font/devX75/TI:
* /font/devX75/TR: Regenerate font descriptions with xtotroff, using
  updated ISO-8859_1 map.  \[aq] and \[oq] are now aliases of "'" and
  \[ga] is an alias of "`".  This change probably should have been made
  when the X11 fonts were corrected in XFree86 4.0 (March 2000).  See
  <https://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html>.

Fixes <https://bugs.debian.org/243238>.


signature.asc
Description: PGP signature

Bug#716109: [Mayhem] Bug report on groff: lookbib crashes with exit status 139

[G. Branden Robinson]

Fixed upstream and expected in the groff 1.23.0 release.

commit 1b97881fc0e2246cf29b4758139a665c7816ba23
Author: G. Branden Robinson 
Date:   Sun Sep 12 05:53:43 2021 +1000

[libbib]: Validate input to avoid heap overread.

Since June 1991 if not earlier, groff (technically, the refer, lookbib,
and lkbib programs) has trusted the header contents of binary
bibliographic index files (canonically generated with indxbib(1))
regarding the sizes of the data structures that follow in the file, a
notorious class of security problem.  In July 2013, the Mayhem Team at
Carnegie Mellon University reported to the Debian Bug Tracking System a
problem with groff's refer(1) implementation dumping core when reading
an index file prepared by a fuzzer.

* src/libs/libbib/index.cpp (index_search_item::check_header): Add new
  member function to validate the header of an indexed bibliography
  file, returning a string describing in detail the first validity
  problem encountered.

  (index_search_item::load): Perform the foregoing check before using
  any of the size values taken from the header; they are relied upon for
  pointer arithmetic.  If in verification mode (using the undocumented
  `-V` flag to refer(1), lkbib(1), or lookbib(1)), report the details of
  the problem encountered.  Regardless of that mode, if there is a
  validity problem, report corruption of the index file and abandon it,
  forcing fallback to the text version of the corresponding bibliography
  file.

Fixes <https://bugs.debian.org/716109>.


signature.asc
Description: PGP signature

Bug#990406: groff: ".ta T -5" causes troff assertion failure

[G. Branden Robinson]

tag -1 + upstream fixed-upstream
thanks

A fix for this problem has been committed upstream and it is expected in
the groff 1.23.0 release.

commit 6692653f7cae4116d4e70318f71b3d0808f2261f
Author: G. Branden Robinson 
Date:   Sat Sep 11 07:02:07 2021 +1000

[troff]: Clamp negative tab stop positions to 0.

...instead of throwing an assertion failure.

* src/roff/troff/env.cpp (tab_stops::distance_to_next_tab): Replace
  `assert` with clamping logic, ensuring that `lastpos` can never be
  negative.  While negative tab stop positions don't make much sense
  (they result in zero horizontal motion), user input like `.ta T -5`
  should never provoke an assertion failure.

  (set_tabs): Throw range warning in additional scenario, viz., if a
  repeating tab offset is negative.

Fixes <https://bugs.debian.org/990406>.  Thanks to наб for the report.

Also wrap nearby long source lines.



signature.asc
Description: PGP signature

Bug#990406: groff SIGABRTs after negative .ta request

[G. Branden Robinson]

retitle 990406 groff: ".ta T -5" causes troff assertion failure
tag 990406 + upstream
thanks

What's going on is much clearer if groff Git HEAD, thanks to its
improved `assert()` implementation.

$ printf '.ta T -5\n\t' | tg
troff: ../src/roff/troff/env.cpp:2620: distance_to_next_tab(): assertion 
failed: 'lastpos > 0'
.../groff/build/groff: error: troff: Aborted (core dumped)

I'll have a look at this.

Regards,
Branden


signature.asc
Description: PGP signature

Bug#710178: groff-base: some warnings now split on several lines, makes lintian reports useless

[G. Branden Robinson]

package groff-base
tag 710178 + fixed-upstream
thanks

This has been fixed in groff's Git repository and is expected in the
1.23.0 release.


signature.asc
Description: PGP signature

Bug#284002: [PATCH] mdoc: Update operating system release numbers

[G. Branden Robinson]

At 2020-11-22T16:08:56+0100, Ingo Schwarze wrote:
[worthy backgrounder snipped]

> There are many obvious problems in the design:
> 
>   1. The syntax is not really consistent: both coded references
>  like "BSD" "4.4" and free text strings are supported.

Yes, I found this particularly startling.

>   2. The concept of encoding names and versions of all operating
>  systems is not sustainable in the long run.

This was probably a product of its times; there was BSD, only one BSD,
and then there was System V, and the importance of that conflict caused
people to adopt a kind of tunnel vision.

>   3. Cynthia was already unhappy with the chosen default behaviour
>  as early as 1991/08/05.

Does Cynthia ever pop up to reflect on mdoc's design?

[more snippage]

> Consequently, i would suggest to say something like the following:
> 
>   .Os [operating system or software package name and version]
> 
> This is the mandatory third macro of every mdoc(7) document.
> In manual pages that are part of the base system of an operating
> system, do not provide an argument.
> In manual pages that are part of a portable software package,
> the name of the software package can optionally be provided
> as an argument, optionally followed by a version number.

This looks sound to me, content-wise.

> I would leave the decision about the default behaviour to the
> formatter and to the operating system the formatter is running on.
> For example, mandoc(1) uses uname(3) by default.  But using a
> fixed string provided by the operating system or just leaving
> the field in the page footer blank seem fine as alternatives.

Agreed.

> > How about we officially relax the semantics of ".Os" in mdoc(7) from
> > "operating system" to, say, "original source"?
> 
> I tend to dislike backronyms, in particular when they are not very
> descriptive or even misleading.  It doesn't matter at all in this
> case whether the source is "original" or not.  For example, if
> somebody forks a software project, applies some improvements to the
> code and to the manual page and published the fork, then the argument
> of the .Os macro (if any) should be updated or removed, *not* left
> to point to the "original source".

Good point.

> So i think documenting it as "operating system or software package"
> or something like that is better than saying "original source".

Yes, I'm amenable to this.

> > Meaning whatever the author/maintainer of the mdoc(7) document
> > uses as a version control identifier.
> 
> Yes.  And i would consider all forms
> 
>   .Os
>   .Os groff
>   .Os GNU troff
>   .Os groff-1.23.0
>   .Os GNU troff 1.23.0
> 
> valid, treating all information as optional, provided at the
> discretion of the author.

Cool.  I prefer the form we're using for the groff man(7) pages:
groff 1.22.4
but really this is a matter of the originating project's discretion.

> Well, groff_mdoc(7) is already quite clear that the .Os macro itself
> is mandatory, but the developer of some portable project would
> probably see little reason to provide an argument.  That's not a
> huge problem because providing arguments is optional, but nothing
> is wrong to with providing arguments if desired.

Yes, I think the idea here to _encourage_ portable project developers to
start using .Os to say something, instead of as a stump.

> Sure.  I dislike the concept of mdoc.local for more than one reason,
> but probably it is good enough for this purposes if there is no
> better way in Debian.  If mdoc.local gets automatically updated
> during system updates, the proposed string also seems fine.  If it
> is considered a user config file and does *not* get updated
> automatically, then something like just "Debian GNU/Linux" might
> be even better.

Hahaha. This is Debian...it's _both_ automatically updated during system
updates _and_ considered a user config file!

https://www.debian.org/doc/debian-policy/ap-pkg-conffiles.html

"conffiles" have been a dpkg feature for something like 25 years now.
Every Debian sysadmin is familiar with the dpkg conffile prompt.  :D

Configuration file '/etc/bash.bashrc'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it?  Your options are:
Y or I  : install the package maintainer's version
N or O  : keep your currently-installed version
  D : show the differences between the versions
  Z : start a shell to examine the situation
 The default action is to keep your current version.
*** bash.bashrc (Y/I/N/O/D/Z) [default=N]?

I suspect most people don't touch mdoc.local, so it will be
automatically updated for them.

Colin, what do you think?

Regards,
Branden


signature.asc
Description: PGP signature

Bug#284002: [PATCH] mdoc: Update operating system release numbers

[G. Branden Robinson]

At 2019-12-21T14:51:23+0100, Ingo Schwarze wrote:
> Colin Watson wrote on Tue, Dec 17, 2019 at 01:15:30PM +:
> > On Tue, Dec 17, 2019 at 01:14:06PM +, Colin Watson wrote:
> > 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.
> 
> I completely agree with all you are saying here.
[...]
> I do think that removing version verification and just printing
> whatever the manual page author requests in the same way as mandoc(1)
> is already doing it would be an improvement, but that should be
> discussed separately, not in this ticket.

There's another Debian bug report that impinges on this question.

https://bugs.debian.org/284002

How about we officially relax the semantics of ".Os" in mdoc(7) from
"operating system" to, say, "original source"?  Meaning whatever the
author/maintainer of the mdoc(7) document uses as a version control
identifier.  This would increase parallelism with man(7)'s fourth .TH
argument, and give projects an easy place to hang an identifier for the
page release.

Debian #284002 proposes overriding the "BSD" default with a
distribution-specific string in the mdoc.local file, and that seems a
resonable thing to do to me _as a fallback_ when there is no .Os in the
first place, and with the current mnemonic and documenttion, a portable
GitHub project developer, for instance, has little reason to suspect
they should use this macro.

As far as I can tell, this is already designed for with the string
"doc-default-operating-system".

So my proposal is twofold:

1. Update groff_mdoc(7) as described above, to encourage mdoc(7) page
   authors to use this to record a package/project name and release.
2. Encourage Colin to add the following to mdoc.local:

.ds doc-default-operating-system Debian 11 (bullseye)\"

   or similar.

Thoughts?

Regards,
Branden


signature.asc
Description: PGP signature

Bug#421437: groff: grops and grodvi crash on invalid input

[G. Branden Robinson]

package groff-base
tag 421437 + upstream fixed-upstream
thanks

I can verify that, as I suspected (I mention that only because my
suspicions are so often incorrect), both instances arose from the same
bug, fixed in groff upstream last year and expected in the 1.23.0
release.

Details:

$ grodvi ./crash-grodvi.txt 
grodvi:./crash-grodvi.txt:30: missing argument
grodvi:./crash-grodvi.txt:30: missing argument to 'c' command
grodvi:./crash-grodvi.txt:31: font 'TR' does not contain ascii character '\'
Segmentation fault (core dumped)
$ gdb $(which grodvi) ./core
GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/grodvi...Reading symbols from 
/usr/lib/debug/.build-id/4b/02d06b7ebb1cdad715cddb0f3735235ca3a7a3.debug...done.
done.
[New LWP 23670]
Core was generated by `grodvi ./crash-grodvi.txt'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x5634b3ed5baa in font::get_code (this=0x5634b3f65580, g=0x0) at 
../../src/libs/libgroff/font.cpp:547
547 ../../src/libs/libgroff/font.cpp: No such file or directory.
##(gdb) cd groff-1.22.4/debian/build
Working directory /tmp/branden/groff-1.22.4/debian/build.
##(gdb) list
542   abort();
543 }
544
545 int font::get_code(glyph *g)
546 {
547   int idx = glyph_to_index(g);
548   assert(idx >= 0);
549   if (idx < nindices && ch_index[idx] >= 0) {
550 // Explicitly enumerated glyph
551 return ch[ch_index[idx]].code;
##(gdb) up
#1  0x5634b3ecf8d2 in dvi_printer::set_char (this=0x5634b3f664b0, g=0x0, 
f=0x5634b3f65580, env=0x5634b3f5bb70, w=0)
at ../../src/devices/grodvi/dvi.cpp:346
346   int code = f->get_code(g);
##(gdb) list
341 void dvi_printer::set_char(glyph *g, font *f, const environment *env,
342int w, const char *)
343 {
344   if (*env->col != cur_color)
345 set_color(env->col);
346   int code = f->get_code(g);
347   if (env->size != cur_point_size || f != cur_font) {
348 cur_font = f;
349 cur_point_size = env->size;
350 int i;
##(gdb) up
#2  0x5634b3ed381c in printer::set_ascii_char (this=0x5634b3f664b0, 
c=, env=0x5634b3f5bb70, widthp=widthp@entry=0x0)
at ../../src/libs/libdriver/printer.cpp:181
181   set_char(g, f, env, w, 0);
##(gdb) list
176
177   buf[0] = c;
178   buf[1] = '\0';
179
180   glyph *g = set_char_and_width(buf, env, , );
181   set_char(g, f, env, w, 0);
182       if (widthp) {
183 *widthp = w;
184   }
185 }

commit 5d0990500c2d16ed1025f1f0738cb419800652fe
Author: G. Branden Robinson 
Date:   Thu Jun 27 04:42:51 2019 +1000

libdriver: Fix SEGV (Savannah #56555).

Check result of set_char_and_width() for error condition before relying
on it.

diff --git a/ChangeLog b/ChangeLog
index 61e20b05..8e7973b6 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2019-06-27  G. Branden Robinson 
+
+   libdriver: Fix SEGV (Savannah #56555).
+
+   * src/libs/libdriver/printer.cpp: Check result of
+   set_char_and_width() for error condition before relying on it.
+
 2019-06-27  G. Branden Robinson 
 
groff: Add regression test for Savannah #56555.
diff --git a/src/libs/libdriver/printer.cpp b/src/libs/libdriver/printer.cpp
index f20e4b0a..773d438b 100644
--- a/src/libs/libdriver/printer.cpp
+++ b/src/libs/libdriver/printer.cpp
@@ -178,9 +178,11 @@ void printer::set_ascii_char(unsigned char c, const 
environment *env,
   buf[1] = '\0';
 
   glyph *g = set_char_and_width(buf, env, , );
-  set_char(g, f, env, w, 0);
-  if (widthp) {
-*widthp = w;
+
+  if (g != UNDEFINED_GLYPH ) {
+set_char(g, f, env, w, 0);
+if (widthp)
+  *widthp = w;
   }
 }
 


signature.asc
Description: PGP signature

Bug#488213: groff-base: Escaped version of apostroph (\') does not display in ISO-8859-15 locale

[G. Branden Robinson]

If this bug report is asking for a latin9 output driver for groff, it's
should be retitle and moved to wishlist severity.

If it's asking for the semantics of \' to change from acute accent, it's
wontfix.

Regards,
Branden


signature.asc
Description: PGP signature

Bug#710178: groff-base: some warnings now split on several lines, makes lintian reports useless

[G. Branden Robinson]

package gross-base
tag 710178 + fixed-upstream
thanks

This has been fixed in groff's Git repository and is expected in the
1.23.0 release.

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


signature.asc
Description: PGP signature

Bug#312935: groff-base: grotty -c should be - no it MUST be - made the default

[G. Branden Robinson]

After 15 years, I recommend closing this bug as "wontfix".

The traditional output mode only makes sense for overstriking terminals,
of which there are vanishingly few that aren't paper terminals, which
are themselves a dead breed.

The virtue of "ANSI escapes" is that they're actually standardized in
ISO 6429.  Moreover, they are known to be widely supported in many
hardware terminals and emulators.

For those with truly "dumb" terminals, "grotty -cbou" is probably a good
invocation to learn.  It can be passed through from groff with the
option "-P-cbou".  For example:

groff -Tascii -t -man -P-cbou ./build/tmac/groff_man.7 | more

The grotty(1) man page in groff 1.22.4 is significantly improved over
past versions, and the one forthcoming in groff 1.23.0 will be even
better[1].

I would appreciate knowing if the "-cbou" trick is worth explicitly
calling out there.  I use it for groff regression tests, but I don't
know how many other people would have any use for it.

Regards,
Branden

[1] https://man7.org/linux/man-pages/man1/grotty.1.html


signature.asc
Description: PGP signature

Bug#284002: default for mdoc's volume-operating-system

[G. Branden Robinson]

[groff upstream committer here]

I think there is a bit of a culture clash between BSD and the rest of
the world here.  In man(7) pages a fairly common, though not universal,
practice is to use the fourth argument to .TH to designate more or less
a package release of a software project.  groff itself does this.

BSD by contrast has this "make world" tradition where package versions
tell you a lot less than the bolt of lightning that created the
universe.

I think to fix this _right_ means having a new mdoc(7) macro for
capturing this information.  And that in turn probably means having
another knock-down, drag-out argument with Ingo Schwarze, mdocml
maintainer.  Since he and I both buy ink by the barrel, I have to ration
my fights with him.  :)

But just as a straw man, I'd propose a '.Pj' macro for a
"project/package release", and if this is defined for a page, it goes in
the "footer-inside" position, opposite the page number in the
"footer-outside" position[1].  If .Pj has _not_ been defined, .Os is
used for the "footer-inside".

Maybe I _can_ sell this to Ingo--he wants the whole world to be writing
mdoc(7) instead of man(7) pages, and having a standard way to identify
the origin of a page might offer some slight incentive to people to take
it up.

Thoughts?

Regards,
Branden

[1] groff_mdoc currently gets this wrong; when rendering with
double-sided layout (groff -rD1), the page numbers are incorrectly
placed toward the binding edge rather than the leaf edge.[2]
[2] Discussed a couple of years ago on the groff list, but no mdoc fan
contributed a fix.
https://lists.gnu.org/archive/html/groff/2019-01/msg00021.html


signature.asc
Description: PGP signature

Bug#945056: jekyll: terrible failure mode when run by novice

[G. Branden Robinson]

Package: jekyll
Version: 3.8.3+dfsg-4
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

I'm trying to debug why some Markdown didn't convert to HTML properly on
a jekyll-generated website.  So that I don't have to shoot in the dark
while troubleshooting it, I wanted to install a local copy of Jekyll so
I could test and evaluate my fixes/workarounds.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

With no Ruby experience, I ran "apt install jekyll".

I then ran "man jekyll".  The page is terse to a fault and the synopsis
is nonstandard.  It is scarcely better than the output of "help2man".
It does not document the syntax "jekyll new $SITENAME", which I had to
find via Web search.  (I found a better source later; see below.)

   * What was the outcome of this action?

[wide terminal required]

$ jekyll
Traceback (most recent call last):
10: from /usr/bin/jekyll:9:in `'
 9: from /usr/lib/ruby/vendor_ruby/jekyll/plugin_manager.rb:50:in 
`require_from_bundler'
 8: from 
/usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler.rb:107:in 
`setup'
 7: from 
/usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler/runtime.rb:20:in
 `setup'
 6: from 
/usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler/runtime.rb:108:in
 `block in definition_method'
 5: from 
/usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler/definition.rb:226:in
 `requested_specs'
 4: from 
/usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler/definition.rb:237:in
 `specs_for'
 3: from 
/usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler/definition.rb:170:in
 `specs'
 2: from 
/usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler/spec_set.rb:85:in
 `materialize'
 1: from 
/usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler/spec_set.rb:85:in
 `map!'
/usr/share/rubygems-integration/all/gems/bundler-1.17.3/lib/bundler/spec_set.rb:91:in
 `block in materialize': Could not find ffi-1.9.25 in any of the sources 
(Bundler::GemNotFound)

   * What outcome did you expect instead?

A diagnostic message that:

1. Is not an interpreter traceback.  "jekyll" is a command-line utility
and its communication should be targeted to users, not programmers.

2. Does not suggest a package dependency problem, in turn implying that
Debian screwed up its stable release.

3. Does not pair the grave accent with the apostrophe.  This doesn't
look good in any font that people actually use.  See
https://www.gnu.org/prep/standards/html_node/Quote-Characters.html .
This ugly typography simply adds insult to injury.

The interpreter takes all that time to spin up and doesn't actually
appear to spend any of it sanity-checking the command-line arguments,
the environment, or the file system for signs that it is being run by a
newcomer.

The good news is that "jekyll --help" actually documents (briefly) the
subcommands.

The bad news is that "jekyll --help" takes over 7 seconds to run on a
six-core i5-8500 at 3GHz:

$ time jekyll --help && uptime
jekyll 3.8.3 -- Jekyll is a blog-aware, static site generator in Ruby
[...]
real0m7.476s
user0m0.304s
sys 0m0.021s
 15:25:17 up  1:08,  4 users,  load average: 0.50, 0.49, 0.46

"jekyll --help" produces 1255 characters of output.  Rounding to 7
seconds, that gives 179.2 characters per second.

Fortunately, that is faster then Thompson & Ritchie's 110 baud ASR 33
Teletypes.

But not by much.

The Ruby ecosystem is making a poor first impression on me.

-- System Information:
Debian Release: 10.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages jekyll depends on:
ii  bundler 1.17.3-3
ii  ruby1:2.5.1
ii  ruby-addressable2.5.2-1
ii  ruby-classifier-reborn  2.2.0-1
ii  ruby-colorator  1.1.0-1
ii  ruby-em-websocket   0.5.1-2
ii  ruby-i18n   1.5.3-1
ii  ruby-jekyll-coffeescript1.0.1-2
ii  ruby-jekyll-feed0.3.1-1
ii  ruby-jekyll-gist1.5.0-1
ii  ruby-jekyll-paginate1.1.0-1
ii  ruby-jekyll-sass-converter  1.5.2-1
ii  ruby-jekyll-watch   2.0.0-1
ii  ruby-kramdown   1.17.0-1
ii  ruby-launchy-shim   2.3.0.1
ii  ruby-liquid 4.0.1-1
ii  ruby-mercenary  0.3.6-1
ii  ruby-mime-types 3.2.2-1
ii  ruby-pathutil   0.16.1-1
ii  ruby-pygments.rb1.2.0-4
ii  ruby-rdiscount  2.1.8-1+b5
ii  ruby-redcarpet

Bug#923298: chromium: file overlap with chromium-sandbox without Conficts and/or Replaces

[G. Branden Robinson]

Package: chromium
Version: 72.0.3626.96-1~deb9u1
Severity: grave
Justification: renders package unusable

I have been tracking testing for several months.

This looks to me like a missing or insufficiently versioned Replaces
declaration, but I did not dig deeply into this except to check the BTS
to see if it had bitten anyone else.  To my surprise, it looks like it
has not.

# apt install chromium-sandbox
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following NEW packages will be installed:
  chromium-sandbox
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 137 kB of archives.
After this operation, 851 kB of additional disk space will be used.
Get:1 http://ftp.au.debian.org/debian buster/main amd64 chromium-sandbox amd64 
72.0.3626.53-1 [137 kB]
Fetched 137 kB in 1s (179 kB/s)  
Selecting previously unselected package chromium-sandbox.
(Reading database ... 351969 files and directories currently installed.)
Preparing to unpack .../chromium-sandbox_72.0.3626.53-1_amd64.deb ...
Unpacking chromium-sandbox (72.0.3626.53-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/chromium-sandbox_72.0.3626.53-1_amd64.deb (--unpack):
 trying to overwrite '/usr/lib/chromium/chrome-sandbox', which is also in 
package chromium 72.0.3626.96-1~deb9u1
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/chromium-sandbox_72.0.3626.53-1_amd64.deb

-- System Information:
Debian Release: buster/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages chromium depends on:
ii  libasound2   1.1.8-1
ii  libatk1.0-0  2.30.0-2
ii  libatomic1   8.2.0-21
ii  libatspi2.0-02.30.0-7
ii  libavcodec57 7:3.2.12-1~deb9u1
ii  libavformat577:3.2.12-1~deb9u1
ii  libavutil55  7:3.2.12-1~deb9u1
ii  libc62.28-7
ii  libcairo21.16.0-2
ii  libcups2 2.2.10-3
ii  libdbus-1-3  1.12.12-1
ii  libdrm2  2.4.97-1
ii  libevent-2.0-5   2.0.21-stable-3
ii  libexpat12.2.6-1
ii  libflac8 1.3.2-3
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3
ii  libgcc1  1:8.2.0-21
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-7
ii  libglib2.0-0 2.58.3-1
ii  libgtk2.0-0  2.24.32-3
ii  libicu57 57.1-6+deb9u2
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.20-1
ii  libnss3  2:3.42.1-1
ii  libopenjp2-7 2.3.0-1.1
ii  libopus0 1.3-1
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpangoft2-1.0-01.42.4-6
ii  libpci3  1:3.5.2-1
ii  libpng16-16  1.6.36-5
ii  libpulse012.2-4
ii  libre2-3 20170101+dfsg-1
ii  libsnappy1v5 1.1.7-1
ii  libstdc++6   8.2.0-21
ii  libvpx4  1.6.1-3+deb9u1
ii  libwebp6 0.6.1-2
ii  libwebpdemux20.6.1-2
ii  libwebpmux2  0.5.2-1
ii  libx11-6 2:1.6.7-1
ii  libx11-xcb1  2:1.6.7-1
ii  libxcb1  1.13.1-2
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.1.15-2
ii  libxdamage1  1:1.1.4-3
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxml2  2.9.4+dfsg1-7+b3
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.32-2
ii  libxss1  1:1.2.3-1
ii  libxtst6 2:1.2.3-1
ii  x11-utils7.7+4
ii  xdg-utils1.1.3-1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages chromium recommends:
ii  fonts-liberation  1:1.07.4-9
ii  libgl1-mesa-dri   18.3.2-1

Versions of packages chromium suggests:
pn  chromium-driver
pn  chromium-l10n  
pn  chromium-shell 
pn  chromium-widevine  

-- no debconf information

Bug#917258: reportbug: -N, --bugnumber options seems to not work

[G. Branden Robinson]

Package: reportbug
Version: 7.5.1
Severity: normal

> $ reportbug --bugnumber 541147
> *** Welcome to reportbug.  Use ? for help at prompts. ***
> Note: bug reports are publicly archived (including the email address of the 
> submitter).
> Detected character set: UTF-8
> Please change your locale if this is incorrect.
> 
> Using '"G. Branden Robinson" ' as your from 
> address.
> Retrieving report #541147 from Debian bug tracking system...
> No report available: #541147
> No such bug report.

Huh.

And yet...

> $ bts status 541147
> bug_num 541147
> date1250032322
> pending pending
> source  groff
> locationdb-h
> last_modified   1266455885
> msgid   <20090811231046.24819.31638.report...@jondo.cante.net>
> log_modified1266455885
> tagswontfix
> subject please avoid backticks in error messages
> severityminor
> keywordswontfix
> package groff
> id  541147
> originator  Jari Aalto 

I am having trouble reconciling these.

-- Package-specific info:
** Environment settings:
EDITOR="vim"
DEBEMAIL="g.branden.robin...@gmail.com"
DEBFULLNAME="G. Branden Robinson"
INTERFACE="text"

** /home/branden/.reportbugrc:
reportbug_version "7.1.5"
mode advanced
ui text
email "g.branden.robin...@gmail.com"

-- System Information:
Debian Release: buster/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages reportbug depends on:
ii  apt1.8.0~alpha2
ii  python33.7.1-3
ii  python3-reportbug  7.5.1
ii  sensible-utils 0.0.12

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail   
pn  debconf-utils
ii  debsums  2.2.3
ii  dlocate  1.07+nmu1
pn  emacs24-bin-common | emacs25-bin-common  
ii  file 1:5.34-2
ii  gnupg2.2.12-1
ii  postfix [mail-transport-agent]   3.3.2-1
pn  python3-urwid
pn  reportbug-gtk
ii  xdg-utils1.1.3-1

Versions of packages python3-reportbug depends on:
ii  apt1.8.0~alpha2
ii  file   1:5.34-2
ii  python33.7.1-3
ii  python3-apt1.7.0
ii  python3-debian 0.1.33
ii  python3-debianbts  2.7.2
ii  python3-requests   2.20.0-2

python3-reportbug suggests no packages.

-- no debconf information

Bug#913815: xterm: does not correctly document saveLines default

[G. Branden Robinson]

Package: xterm
Version: 337-1
Severity: normal
Tags: upstream

The man page says *saveLines defaults to 64.  But it really defaults to
1024.

Patch attached.  It also synchronizes xterm.dat, whatever that is, with
the application defaults file.

-- System Information:
Debian Release: buster/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages xterm depends on:
ii  libc6   2.27-8
ii  libfontconfig1  2.13.1-2
ii  libfreetype62.8.1-2
ii  libice6 2:1.0.9-2
ii  libtinfo6   6.1+20181013-1
ii  libutempter01.1.6-3
ii  libx11-62:1.6.7-1
ii  libxaw7 2:1.0.13-1+b2
ii  libxft2 2.3.2-2
ii  libxinerama12:1.1.4-1
ii  libxmu6 2:1.1.2-2
ii  libxpm4 1:3.5.12-1
ii  libxt6  1:1.1.5-1
ii  xbitmaps1.1.1-2

Versions of packages xterm recommends:
ii  x11-utils  7.7+4

Versions of packages xterm suggests:
pn  xfonts-cyrillic  

-- no debconf information
Index: xterm-337-quilt/xterm.dat
===
--- xterm-337-quilt.orig/xterm.dat
+++ xterm-337-quilt/xterm.dat
@@ -4,7 +4,7 @@
 *iconName: Xterm
 *c132: TRUE
 *scrollBar: on
-*saveLines:1000
+*saveLines:1024
 
 ! This is nonsense: if the xterm has no session management capabilities,
 ! it is useless, and if it does, it is harmful.
Index: xterm-337-quilt/xterm.man
===
--- xterm-337-quilt.orig/xterm.man
+++ xterm-337-quilt/xterm.man
@@ -1130,7 +1130,7 @@ should not cause the window to be reposi
 This option specifies the number of lines to save that have been scrolled
 off the top of the screen.
 This corresponds to the \fBsaveLines\fP resource.
-The default is \*(``64\*(''.
+The default is \*(``1024\*(''.
 .TP 8
 .B \-sm
 This option, corresponding to the \fBsessionMgt\fR resource,
@@ -4540,7 +4540,7 @@ The default is \*(``false\*(''.
 .B "saveLines\fP (class\fB SaveLines\fP)"
 Specifies the number of lines to save beyond the top of the screen when a
 scrollbar is turned on.
-The default is \*(``64\*(''.
+The default is \*(``1024\*(''.
 .TP 8
 .B "scrollBar\fP (class\fB ScrollBar\fP)"
 Specifies whether or not the scrollbar should be displayed.

Bug#913413: [PATCH] Map Shift+Win to Menu

[G. Branden Robinson]

At 2018-11-13T10:37:20+0100, Łukasz Stelmach wrote:
> +// Pressing the Shift+Win (left or right, respectively) acts as Menu
> +// while Shift+Win acts as Menu.

I don't understand this comment; it seems tautologous.

Shouldn't it be more like:

// Pressing left or right Win acts as Win, while Shift+Win acts as Menu.

?

-- 
Regards,
Branden


signature.asc
Description: PGP signature

Bug#913572: Shouldn't shipping broken symlinks be against policy?

[G. Branden Robinson]

At 2018-11-13T17:02:49+, Ian Jackson wrote:
> G. Branden Robinson writes ("Shouldn't shipping broken symlinks be against 
> policy?"):
> > Not reopening, but I have some questions for the Policy team.
> ...
> > I could have sworn you were incorrect, but sure enough, I read §10.5
> > carefully and grepped the rest of the policy manual and could find no
> > such prohibition.
> 
> I don't think there is anything *inherently* wrong in shipping a
> broken symlink.

I almost do. :-D

> But if a broken symlink causes some kind of malfunction then that
> seems to be just a bug.  Not every bug is a bug because it contravenes
> policy.  Some bugs are just bugs :-).
> 
> > Well, when a package ships a man page, I expect something more
> > illuminating to happen than:
> > 
> > $ man rust-gdb
> > /usr/bin/man: warning: /usr/share/man/man1/rust-gdb.1.gz is a dangling 
> > symlink
> > No manual entry for rust-gdb
> > See 'man 7 undocumented' for help when manual pages are not available.
> 
> I agree that this is untidy and undesirable.  I don't see any good
> reason why one would want to do this rather than shipping the
> rust-gdb.1.gz symlink in the same package as the thing it points to.
> 
> I guess the maintainer will also think this is a bug.

No; he closed it, and cited Policy's lack of a prohibition of shipping
broken symlinks in support of the present arrangement.

> Did anyone report it ?

That would be me.

-- 
Regards,
Branden


signature.asc
Description: PGP signature

Bug#913572: Shouldn't shipping broken symlinks be against policy?

[G. Branden Robinson]

Not reopening, but I have some questions for the Policy team.

At 2018-11-13T16:26:00+, Ximin Luo wrote:
> Control: notfound -1 1.28.0+dfsg1-2
> 
> Closing, as far as I can tell it is not against Policy to ship a
> broken symlink,

I could have sworn you were incorrect, but sure enough, I read §10.5
carefully and grepped the rest of the policy manual and could find no
such prohibition.

It is certainly untidy.  So I ask the Policy team--_shouldn't_ it be
prohibited?

> if it doesn't affect the functionality of the package.

Well, when a package ships a man page, I expect something more
illuminating to happen than:

$ man rust-gdb
/usr/bin/man: warning: /usr/share/man/man1/rust-gdb.1.gz is a dangling symlink
No manual entry for rust-gdb
See 'man 7 undocumented' for help when manual pages are not available.

> The man page is available in the rust-doc package which is already in
> Suggests.

In that case, isn't a better fix to put the symlink in that package,
too?

On my buster system, this is the only one of over 4,300 symlinks in
/usr/share/man that is broken:

$ find /usr/share/man -type l | wc -l; for F in $(find /usr/share/man \
-type l); do if ! test -f "$F"; then file "$F"; dpkg -S "$F"; fi; done
4938
/usr/share/man/man1/rust-gdb.1.gz: broken symbolic link to gdb.1.gz
rust-gdb: /usr/share/man/man1/rust-gdb.1.gz

> X
> 
> G. Branden Robinson:
> > Package: rust-gdb
> > Version: 1.28.0+dfsg1-2
> > Severity: normal
> > File: /usr/share/man/man1/rust-gdb.1.gz
> > 
> > $ dpkg -S /usr/share/man/man1/rust-gdb.1.gz
> > rust-gdb: /usr/share/man/man1/rust-gdb.1.gz
> > 
> > $ file /usr/share/man/man1/rust-gdb.1.gz
> > /usr/share/man/man1/rust-gdb.1.gz: broken symbolic link to gdb.1.gz
[snip]

Thanks for your time.  Policy mavens, please CC me or the bug on
replies; I don't subscribe to a billion lists like I did in the old
days.

Regards,
Branden


signature.asc
Description: PGP signature

Bug#913572: /usr/share/man/man1/rust-gdb.1.gz: rust-gdb: ships broken symlink /usr/share/man/man1/rust-gdb.1.gz

[G. Branden Robinson]

Package: rust-gdb
Version: 1.28.0+dfsg1-2
Severity: normal
File: /usr/share/man/man1/rust-gdb.1.gz

$ dpkg -S /usr/share/man/man1/rust-gdb.1.gz
rust-gdb: /usr/share/man/man1/rust-gdb.1.gz

$ file /usr/share/man/man1/rust-gdb.1.gz
/usr/share/man/man1/rust-gdb.1.gz: broken symbolic link to gdb.1.gz

-- System Information:
Debian Release: buster/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages rust-gdb depends on:
ii  gdb  8.1-4+b1

rust-gdb recommends no packages.

Versions of packages rust-gdb suggests:
pn  gdb-doc  

-- no debconf information

Bug#742466: bash-completion: [PATCH] bash-completion: unexpected EOF while looking for matching `) while completing in subshell

[G. Branden Robinson]

At 2018-11-10T15:07:23-0200, Gabriel F. T. Gomes wrote:
> Hi,
> 
> On 10 Nov 2018, G. Branden Robinson wrote:
> 
> >Package: bash-completion
> >Version: 1:2.8-2
> >Followup-For: Bug #742466
> >
> >I'm attaching a debdiff of a proposed NMU for this.  I don't intend to
> >actually NMU unless this bug threatens not to make it into the next
> >Debian release (it's been around for several already :( ).
> 
> It wouldn't be a problem, at all, if you submitted this as a NMU.
> Anyhow, thanks for bringing this up for discussion first.

My pleasure.  I see you recently took over the package, so I'm not
really inclined to preëmpt you, as exasperating as I have found the bug.
:)

> >I hope this will make it easy to apply and get shipping.
> 
> It does, indeed.  Thank you very much.

You're most welcome!

> >This bug has been complained about for years; see, e.g.:
> 
> I'm sorry that this has been open for so long...  I have been working
> on many ancient bugs recently, and I hope to fix many of them before
> the next Debian release.  However, I started with those marked as
> important (I didn't question the reasons why a few bugs were marked as
> important, nor the correctness of the classification, because it
> predates my adoption of bash-completion).

Having maintained the XFree86 bug list long ago I appreciate what a task
this is.  Starting with the high-severity bugs is the right thing to do.
And some bugs will have been miscategorized or insufficiently triaged;
it is the nature of the beast.

> Thank you very much for raising awereness for this bug...  If you know
> of any other bugs that deserve immediate attention, please let me know
> and I'll glady focus on them.

For the most part, bash and its completions work as I expect, or
completions simply silently fail the way I got used to back in the days
before bash had programmable completion at all.

This was the only completion bug I can ever recall that upset me.  :-O

> >Note that tab-completion within POSIX command substitution is still not
> >fully-fledged; with this fix, one gets command-name substitution after
> >'$(', but filename completion after entering a command does not take
> >place.  One has to force it manually, say with M-/.
> 
> I have tested this change and it does exactly what's described above,
> with one addition: after the command name substitution, nor filename,
> nor *subcommand* substitution take place.  For instance:
> 
>   $ echo $(cv[TAB][TAB]
>   cvlccvs-debicvs-switchroot  
>   cvs cvs-debrelease  cvt 
>   cvs-debccvs-debuild cvtsudoers
> 
> as expected, but:
> 
>   $ echo $(cvs lo[TAB][TAB]
>   (no output)
> 
> when it should have completed `log' with `log '.

Yes, that's true.  There is definitely still a bug, or a missing feature
here.

The instant issue is simply to get bash to stop spewing noise to stderr
during completion attempts.

> I agree and I'm preparing a new upload with this and other changes.
> 
> May I attribute this change to you (as commit author) in the git
> repository for Debian's bash-completion.  It would like like the
> attached patch.

I'm fine with that, but credit for identifying that stanza as requiring
deletion should go to Malte Skoruppa; he made the observation in June of
2015.

https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1312243/comments/8

Thank you for your efforts in getting bash-completion into good shape
for the buster release!

Regards,
Branden


signature.asc
Description: PGP signature

Bug#913398: lintian: Use of uninitialized value $magic in numeric eq (==) at /usr/share/lintian/collection/java-info line 115.

[G. Branden Robinson]

Package: lintian
Version: 2.5.111
Severity: normal
File: /usr/share/lintian/collection/java-info

Now running lintian bash-completion_2.8-2.1_amd64.changes ...
Use of uninitialized value $magic in numeric eq (==) at 
/usr/share/lintian/collection/java-info line 115.
Use of uninitialized value $magic in numeric eq (==) at 
/usr/share/lintian/collection/java-info line 115.
Use of uninitialized value $magic in numeric eq (==) at 
/usr/share/lintian/collection/java-info line 115.
Finished running lintian.

-- System Information:
Debian Release: buster/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages lintian depends on:
ii  binutils   2.31.1-7
ii  bzip2  1.0.6-9
ii  diffstat   1.61-1+b1
ii  dpkg   1.19.2
ii  file   1:5.34-2
ii  gettext0.19.8.1-8
ii  intltool-debian0.35.0+20060710.4
ii  libapt-pkg-perl0.1.34+b1
ii  libarchive-zip-perl1.64-1
ii  libcgi-pm-perl 4.40-1
ii  libclass-accessor-perl 0.51-1
ii  libclone-perl  0.41-1+b1
ii  libdpkg-perl   1.19.2
ii  libemail-valid-perl1.202-1
ii  libfile-basedir-perl   0.08-1
ii  libipc-run-perl20180523.0-1
ii  liblist-moreutils-perl 0.416-1+b4
ii  libparse-debianchangelog-perl  1.2.0-13
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.74-1
ii  libxml-simple-perl 2.25-1
ii  libyaml-libyaml-perl   0.74+repack-1+b1
ii  man-db 2.8.4-2+b1
ii  patchutils 0.3.4-2
ii  perl [libdigest-sha-perl]  5.28.0-3
ii  t1utils1.41-2
ii  xz-utils   5.2.2-1.3

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b5

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.19.2
ii  libhtml-parser-perl3.72-3+b3
ii  libtext-template-perl  1.53-1

-- no debconf information

Bug#742466: bash-completion: [PATCH] bash-completion: unexpected EOF while looking for matching `) while completing in subshell

[G. Branden Robinson]

Package: bash-completion
Version: 1:2.8-2
Followup-For: Bug #742466

I'm attaching a debdiff of a proposed NMU for this.  I don't intend to
actually NMU unless this bug threatens not to make it into the next
Debian release (it's been around for several already :( ).

I hope this will make it easy to apply and get shipping.

This bug has been complained about for years; see, e.g.:

https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1312243

Note that tab-completion within POSIX command substitution is still not
fully-fledged; with this fix, one gets command-name substitution after
'$(', but filename completion after entering a command does not take
place.  One has to force it manually, say with M-/.

Nevertheless this is still a huge improvement over the status quo by
preventing ugly stderr spew into the middle of the command one is
typing.

Tested with:
Debian's bash 4.4.18-3.1
upstream bash 5.0.0(1)-alpha

-- System Information:
Debian Release: buster/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

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

-- no debconf information
diff -Nru bash-completion-2.8/debian/changelog 
bash-completion-2.8/debian/changelog
--- bash-completion-2.8/debian/changelog2018-11-04 15:01:45.0 
-0500
+++ bash-completion-2.8/debian/changelog2018-11-10 08:27:09.0 
-0500
@@ -1,3 +1,11 @@
+bash-completion (1:2.8-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix extremely annoying and long-standing breakage of completion
+within POSIX command substitution $().  (Closes: #742466)
+
+ -- G. Branden Robinson   Sat, 10 Nov 2018 
08:27:09 -0500
+
 bash-completion (1:2.8-2) unstable; urgency=low
 
   * Fix for held packages completion in dpkg (Closes: #907294)
diff -Nru bash-completion-2.8/debian/patches/00-fix_quote_readline_by_ref.patch 
bash-completion-2.8/debian/patches/00-fix_quote_readline_by_ref.patch
--- bash-completion-2.8/debian/patches/00-fix_quote_readline_by_ref.patch   
2018-11-04 13:14:10.0 -0500
+++ bash-completion-2.8/debian/patches/00-fix_quote_readline_by_ref.patch   
2018-11-10 08:26:27.0 -0500
@@ -9,13 +9,23 @@
 Bug-Debian: https://bugs.debian.org/739835
 Forwarded: yes, <5328f418@canonical.com>
 
+From: G. Branden Robinson 
+Subject: Revert "double escaping" hunk of patch.
+ - That portion fixed no cited bug.
+ - It broke extremely common command-substitution cases, e.g.
+ "grep pattern $()", producing:
+ bash: unexpected EOF while looking for matching `)'
+ bash: syntax error: unexpected end of file
+Origin: vendor, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742466
+Bug-Debian: https://bugs.debian.org/742466
+
 ---
  bash_completion |   13 -
  1 file changed, 12 insertions(+), 1 deletion(-)
 
 bash-completion.orig/bash_completion
-+++ bash-completion/bash_completion
-@@ -536,13 +536,24 @@ __ltrim_colon_completions()
+--- a/bash_completion
 b/bash_completion
+@@ -526,9 +526,15 @@
  # @param $2  Name of variable to return result to
  _quote_readline_by_ref()
  {
@@ -32,12 +42,3 @@
  else
  printf -v $2 %q "$1"
  fi
- 
-+# Replace double escaping ( \\ ) by single ( \ )
-+# This happens always when argument is already escaped at cmdline,
-+# and passed to this function as e.g.: file\ with\ spaces
-+[[ ${!2} == *\\* ]] && printf -v $2 %s "${1///\\}"
-+
- # If result becomes quoted like this: $'string', re-evaluate in order to
- # drop the additional quoting.  See also: http://www.mail-archive.com/
- # bash-completion-de...@lists.alioth.debian.org/msg01942.html

Bug#913351: man-db: lexgrog handles escaped hyphens after the first wrongly

[G. Branden Robinson]

At 2018-11-09T21:38:46+, Colin Watson wrote:
> Control: tag -1 fixed-upstream
> 
> On Fri, Nov 09, 2018 at 02:30:42PM -0500, G. Branden Robinson wrote:
> > $ for F in $(man -w tfmtodit hpftodit afmtodit); do lexgrog "$F"; zcat "$F" 
> > | sed -n '3,4 {/\\-/p}'; done
> > /usr/share/man/man1/tfmtodit.1.gz: "tfmtodit - create font files for use 
> > with groff - Tdvi"
> > tfmtodit \- create font files for use with groff \-Tdvi
> > /usr/share/man/man1/hpftodit.1.gz: "hpftodit - create font description 
> > files for use with groff - Tlj4"
> > hpftodit \- create font description files for use with groff \-Tlj4
> > /usr/share/man/man1/afmtodit.1.gz: "afmtodit - create font files for use 
> > with groff - Tps and - Tpdf"
> > afmtodit \- create font files for use with groff \-Tps and \-Tpdf
> 
> Some day I may run across whoever decided that it was a good idea for
> man to have to parse a subset of *roff input in order to identify pages,
> and have some Stern Words with them about the wisdom of that design
> decision.

I'll contribute some stern words of my own; it is truly a layering
violation and a cruel one, at that.

> I think I've hacked this into shape:
> 
>   
> https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=95023279b69986a9c1fee841b2c626ae3973205c

Ah!  Had I bothered to find out you were maintaining man-db on Savannah,
I'd have gone straight there.  As you may know, I have an account there.
:)

>   $ for F in $(man -w tfmtodit hpftodit afmtodit); do src/lexgrog "$F"; done
>   /usr/share/man/man1/tfmtodit.1.gz: "tfmtodit - create font files for use 
> with groff -Tdvi"
>   /usr/share/man/man1/hpftodit.1.gz: "hpftodit - create font description 
> files for use with groff -Tlj4"
>   /usr/share/man/man1/afmtodit.1.gz: "afmtodit - create font files for use 
> with groff -Tps and -Tpdf"

Looks good to me!  Thank you!

Regards,
Branden


signature.asc
Description: PGP signature

Bug#913351: man-db: lexgrog handles escaped hyphens after the first wrongly

[G. Branden Robinson]

Package: man-db
Version: 2.8.4-2+b1
Severity: normal
Tags: upstream

$ for F in $(man -w tfmtodit hpftodit afmtodit); do lexgrog "$F"; zcat "$F" | 
sed -n '3,4 {/\\-/p}'; done
/usr/share/man/man1/tfmtodit.1.gz: "tfmtodit - create font files for use with 
groff - Tdvi"
tfmtodit \- create font files for use with groff \-Tdvi
/usr/share/man/man1/hpftodit.1.gz: "hpftodit - create font description files 
for use with groff - Tlj4"
hpftodit \- create font description files for use with groff \-Tlj4
/usr/share/man/man1/afmtodit.1.gz: "afmtodit - create font files for use with 
groff - Tps and - Tpdf"
afmtodit \- create font files for use with groff \-Tps and \-Tpdf

-- System Information:
Debian Release: buster/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages man-db depends on:
ii  bsdmainutils   11.1.2+b1
ii  debconf [debconf-2.0]  1.5.69
ii  dpkg   1.19.2
ii  groff-base 1.22.3-10
ii  libc6  2.27-8
ii  libgdbm6   1.18.1-1
ii  libpipeline1   1.5.0-2
ii  libseccomp22.3.3-3
ii  zlib1g 1:1.2.11.dfsg-1

man-db recommends no packages.

Versions of packages man-db suggests:
ii  apparmor   2.13.1-3+b1
ii  chromium [www-browser] 70.0.3538.67-2
ii  firefox-esr [www-browser]  60.3.0esr-1
ii  groff  1.22.3-10
ii  less   487-0.1+b1
ii  lynx [www-browser] 2.8.9rel.1-2
ii  w3m [www-browser]  0.5.3-36+b1

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

Bug#908964: evince: reports "! SyncTeX Error : No file?" at startup

[G. Branden Robinson]

Package: evince
Version: 3.30.1-1
Followup-For: Bug #908964

This problem is reproducible on the version of evince in testing, and
with the following trivial document:

$ cat > hello.txt
Hello, world!

Make me with "groff -Tpdf hello.txt > hello.pdf".

-- System Information:
Debian Release: buster/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages evince depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.0-1
ii  evince-common3.30.1-1
ii  gsettings-desktop-schemas3.28.1-1
ii  libatk1.0-0  2.30.0-1
ii  libc62.27-8
ii  libcairo-gobject21.16.0-1
ii  libcairo21.16.0-1
ii  libevdocument3-4 3.30.1-1
ii  libevview3-3 3.30.1-1
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-6
ii  libglib2.0-0 2.58.1-2
ii  libgnome-desktop-3-173.30.1-1
ii  libgtk-3-0   3.24.1-2
ii  libnautilus-extension1a  3.30.0-4
ii  libpango-1.0-0   1.42.4-3
ii  libpangocairo-1.0-0  1.42.4-3
ii  libsecret-1-00.18.6-3
ii  shared-mime-info 1.10-1

Versions of packages evince recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.10-1
ii  dbus-x11 [dbus-session-bus]   1.12.10-1

Versions of packages evince suggests:
ii  gvfs 1.38.0-2
ii  nautilus-sendto  3.8.6-2
ii  poppler-data 0.4.9-2
pn  unrar

-- no debconf information

Bug#902555: radeon.4: Some fixes in the manual

[G. Branden Robinson]

At 2018-06-28T11:31:30+0200, Michel Dänzer wrote:
> 
> Please send this kind of change directly upstream to the
> amd-...@lists.freedesktop.org list for review, split up into one patch
> per logical change.

Well, a lot of these changes aren't "logical", they're stylistic.

> On 2018-06-27 09:07 PM, Bjarni Ingi Gislason wrote:
> > 
> > Don't begin a sentence with a digit.
> 
> Why not? What's the problem with that?

It's considered substandard English style.

See, e.g., [1]

https://www.editage.com/insights/scientific-writing-avoid-starting-sentences-with-a-number-or-abbreviation

The Chicago Manual of Style, which is the preferred style guide of
Michael Kerrisk of the Linux Man-Pages Project, is paywalled[2], but my
copy of the 14th edition says:

§8.9 "At the beginning of a sentence any number that would ordinarily be
set in numerals is spelled out, regardless of any inconsistency this may
create [...]".

Other style guides broadly agree, though they might not be quite as
militant about it as Chicago is.

> > Add a comma after "e.g.".
> 
> That looks odd to me.

It's standard to have the comma.

Chicago, 14th ed. again:

§5.62 "A comma is usually used after such expressions as _that is_,
_namely_, _i.e._, and _e.g._  The punctuation preceding such expressions
should be determined by the magnitude of the break in continuity.  If
the break is minor, a comma should be used.  If the break is greater
than that signaled by a comma, a semicolon or an em dash may be used, or
the expression and the element it introduces may be enclosed in
parentheses". [italics replaced by underscore delimeters]

I've run into Bjarni in the groff and man-pages projects.  He's a
detail-oriented style maven after my own heart and I can vouch that his
proposed corrections are usually sound ones.

[1] ;-)
[2] >:( http://www.chicagomanualofstyle.org/16/ch06/ch06_toc.html
redirects me to a login screen.

-- 
Regards,
Branden


signature.asc
Description: PGP signature

Bug#872529: /usr/bin/caff: caff: puts TTY into weird state when prompting to send mail

[G. Branden Robinson]

At 2018-06-02T17:33:38+0200, Guilhem Moulin wrote:
> Control: tag -1 pending
> 
> Hi,
> 
> On Sun, 20 Aug 2017 at 21:40:44 -0400, G. Branden Robinson wrote:
> > I'm at a loss for what put my terminal into that state in the first
> > place
> 
> Just got another report from Grégoire Détrez, who stumbled upon the same
> problem and found out how to reproduce it, namely by sending a SIGINT or
> SIGTERM at the "gpg> " prompt.  While gpg(1) seems to catch the signal,
> it doesn't restore the original TTY settings before exiting.
> 
> I'd argue it's a gpg(1) bug as it changes the TTY settings and doesn't
> clean up after signal handling, but here is a workaround:
> https://salsa.debian.org/debian/signing-party/commit/b534819f0385d62a23035feab36825f418a070ee

Thanks, Guilhem!  That makes perfect sense.

-- 
Regards,
Branden


signature.asc
Description: PGP signature

Bug#880551: xterm: corrections to man page

[G. Branden Robinson]

At 2017-11-07T08:10:40-0500, G. Branden Robinson wrote:
> Here's an updated version of the patch, reverting the de-boldfacing of
> action names (and some token names) in resource translations.

Of course, by sending that I guaranteed I'd find a problem with it.

Here's my next try.  The problem with the previous was stuff like this:

\\fP(ti

in many of the resource translation lines.

Third try attached.

-- 
Regards,
Branden
--- xterm-330/xterm.man	2017-06-18 14:07:02.0 -0400
+++ xterm-330-branden/xterm.man	2017-11-07 08:15:09.462564868 -0500
@@ -61,16 +61,16 @@
 .\"
 .\" Bulleted paragraph
 .de bP
-.ie \n(.IP \(bu 4
-.el.IP \(bu 2
+.ie n .IP \(bu 4
+.el   .IP \(bu 2
 ..
 .\" these would be fallbacks for DS/DE,
 .\" but groff changed the meaning of the macros.
 .de NS
-.ie \n(.sp
-.el.sp .5
-.ie \n(.in +4
-.el.in +2
+.ie n .sp
+.el   .sp .5
+.ie n .in +4
+.el   .in +2
 .nf
 .ft C			\" Courier
 ..
@@ -912,7 +912,7 @@
 Also, \fI\*n\ \-e\fP is supposed to provide a consistent
 functionality for other applications that need to start text-mode
 programs in a window, and if \fBloginShell\fP were not ignored, the
-result of ~/.profile might interfere with that.
+result of \(ti/.profile might interfere with that.
 .IP
 If you do want the effect of \fB\-ls\fP and \fB\-e\fP simultaneously, you
 may get away with something like
@@ -1325,9 +1325,9 @@
 (the first two are equivalent
 since the descriptor follows the last \*(``/\*(''):
 .NS 15
--S/dev/pts/123/45
--S123/45
--Sab34
+\-S/dev/pts/123/45
+\-S123/45
+\-Sab34
 .NE
 .IP
 Note that \fI\*n\fP does not close any file descriptor
@@ -1488,13 +1488,13 @@
 .bP
 .B ptyInitialErase\fP (PIE), along with the
 .bP
-\fIstty\fP erase character (^H for backspace, ^? for delete)
+\fIstty\fP erase character (\(haH for backspace, \(ha? for delete)
 .RE
 .IP
 will affect DECBKM.  First, \fI\*n\fP obtains the initial \fIerase\fP character:
 .RS
 .bP
-\fI\*n\fP's internal value is ^H
+\fI\*n\fP's internal value is \(haH
 .bP
 \fI\*n\fP asks the operating system for the value which \fBstty\fP shows
 .bP
@@ -1509,14 +1509,14 @@
 _ _ _ _
 l c c c.
 \fBPIE\fR	\fBstty\fR	\fBtermcap\fR	\fIerase\fP
-false	^H	^H	^H
-false	^H	^?	^?
-false	^?	^H	^H
-false	^?	^?	^?
-true	^H	^H	^H
-true	^H	^?	^H
-true	^?	^H	^?
-true	^?	^?	^?
+false	\(haH	\(haH	\(haH
+false	\(haH	\(ha?	\(ha?
+false	\(ha?	\(haH	\(haH
+false	\(ha?	\(ha?	\(ha?
+true	\(haH	\(haH	\(haH
+true	\(haH	\(ha?	\(haH
+true	\(ha?	\(haH	\(ha?
+true	\(ha?	\(ha?	\(ha?
 .TE
 .IP
 Using that \fIerase\fP character, \fI\*n\fP allows further choices:
@@ -1526,8 +1526,9 @@
 character for the initial state of \fBDECBKM\fP
 .bP
 if \fBbackarrowKeyIsErase\fP is false, \fI\*n\fP sets \fBDECBKM\fP
-to 2 (internal).  This ties together \fBbackarrowKey\fP
-and the control sequence for \fBDECBKM\fP
+to 2 (internal).
+This ties together \fBbackarrowKey\fP and the control sequence for
+\fBDECBKM\fP.
 .bP
 applications can send a control sequence to set/reset \fBDECBKM\fP control set
 .bP
@@ -1540,14 +1541,14 @@
 _ _ _ _ _
 c l l c c.
 \fIerase\fR	\fBBKIE\fR	\fBBK\fR	\fBDECBKM\fP	\fIresult\fP
-^?	false	false	2	^H
-^?	false	true	2	^?
-^?	true	false	0	^?
-^?	true	true	1	^?
-^H	false	false	2	^H
-^H	false	true	2	^?
-^H	true	false	0	^H
-^H	true	true	1	^H
+\(ha?	false	false	2	\(haH
+\(ha?	false	true	2	\(ha?
+\(ha?	true	false	0	\(ha?
+\(ha?	true	true	1	\(ha?
+\(haH	false	false	2	\(haH
+\(haH	false	true	2	\(ha?
+\(haH	true	false	0	\(haH
+\(haH	true	true	1	\(haH
 .TE
 .TP 8
 .B "fullscreen\fP (class\fB Fullscreen\fP)"
@@ -1911,17 +1912,18 @@
 susp,
 swtch and
 weras.
-Control characters may be specified as ^char (e.g., ^c or ^u)
-and \fB^?\fP may be used to indicate delete (127).
-Use \fB^\-\fP to denote \fIundef\fP.
-Use \fB\\034\fP to represent \fB^\\\fP, since a literal backslash in
+Control characters may be specified as \fB\(ha\fPchar
+(e.g., \fB\(hac\fP or \fB\(hau\fP)
+and \fB\(ha?\fP may be used to indicate delete (127).
+Use \fB\(ha\-\fP to denote \fIundef\fP.
+Use \fB\e034\fP to represent \fB\(ha\e\fP, since a literal backslash in
 an X resource escapes the next character.
 .IP
 This is very useful for overriding
 the default terminal settings without having to do an \fIstty\fP every time
 an \fI\*n\fP is started.
 Note, however, that the \fIstty\fP program on a given host may use different
-keywords; \fI\*n\fR's table is built-in.
+keywords; \fI\*n\fR's table is built in.
 .IP
 If the \fBttyModes\fP resource specifies a value for \fBerase\fP,
 that overrides the \fBptyInitialErase\fP resource setting,
@@ -2443,7 +2445,7 @@
 .B "charClass\fP (class\fB CharClass\fP)"
 Specifies comma-separated lists of character class bindings of the form
 .NS
-\fIlow\fP[-\fIhigh]\fP[:\fIvalue\fP].
+\fIlow\fP[\-\fIhigh]\fP[:\fIvalue\fP].
 .NE
 .IP
 These are used in determining which
@@ -3064,9 +3066,9 @@
 .IP
 It is possible to select suitable bitmap fonts using a script such as this:
 .NS
-\
<

Bug#880551: xterm: corrections to man page

[G. Branden Robinson]

Here's an updated version of the patch, reverting the de-boldfacing of
action names (and some token names) in resource translations.

My additional fixes are described at the end, numbered 21-25.

Please find two attachments:

1. The actual diff.

2. A diff of the nroffed output of the two pages prepared like this:

 nroff -ww -man $DIR/xterm.man | colcrt -

This makes it _much_ easier to see what all my patches were up to, and
also serves as a bit of a sanity check.

Note that (a) I'm using a UTF-8 environment, so the nroff output and
diffs reflect that (it also helps expose the hyphen-minus fix) and (b) I
cheated out the whitespace changes resulting from the fixed conditionals
in the page local macros bP and NS.

-- 
Regards,
Branden
 01. The local macro definitions for bP and NS were testing the values of
 registers which were likely to be undefined; e.g.
   "./xterm-330/xterm.man:64: warning: number register `.I' not defined"
 Make them test instead simply for "n" (nroff mode, as opposed to
 troff mode), since that appears to be the intention.

 02. Use the \(ha, \(ga, and \(ti character escapes instead of ^`~
 literals, since these produce full-sized spacing glyphs instead of
 small ones intended as combining characters on troff output devices.

 03. Use \- character escape in examples, URLs, and other literal
 contexts  when an ASCII "hyphen-minus" is intended; ensures that
 the correct glyph can be cut and pasted from the man page both from
 TTY and PDF output devices.

 04. Apply font markup to "Control characters may be specified as ^char
 (e.g., ^c or ^u)", consistently with the ensuing discussion.

 05. Minor style fix: "the feature is built in" vs. "the program's
 built-in features".

 06. Remove no-op zero-width space character escapes from the xfontsel
 example.

 07. Add linebreaks after sentences that had only one space between them
 and the succeeding sentence, so the roff system recognizes them as
 separate sentences and pads ("adjusts") the line appropriately.
 (ca. lines 3389, 5382, ...)

 08. Remove trailing whitespace from the ends of input lines.

 09. Convert several uses of bare `` and '' to use the page's local
 string defines, for consistency with the rest of the page.

 [item 10 reverted]

 11. Remove trailing "\n\" from the BtnUp select-end example; it didn't
 seem necessary and the \ was syntactically meaningful to
 roff so it didn't get rendered as expected and caused a warning:
   "./xterm-330/xterm.man:5033: warning: number register `.' not defined"
 It also turned off fill mode outside of the examples for a few
 paragraphs, making the output ugly.

 12. "etc" is an abbreviation that gets a period.

 13. Join two really short input lines ca. line 5029 (about
 triple-clicking).

 14. Use the local AQ string definition instead of bare 's in printf
 examples, for correct appearance and more successful cut and
 pasting.

 15. In the big default charClass table, use a dingbat asterisk at the
 end of the C comment for symmetry with the beginning, which already
 uses one.

 16. Rewrite the upper half of the charClass table so it depicts the
 actual (printable) glyphs in \x80-\xff.  What was there was largely
 incomprehensible to me.

 17. Use character escape '\e' instead of '\\' in resource translation
 examples.  '\\' does not render as desired and makes the examples
 wrong.  (\(rs would be more strictly correct than \e, but is a
 groffism; \e is not an invariant glyph reference but instead means
 "whatever the current roff escape character is"; fortunately, most
 man pages do not change the escape character.  Traditional roff
 does not have a character escape for the "reverse solidus".)

 18. The translation examples also don't need zero-width spaces (\&) at
 the ends of the input lines; this is a no-op.  Remove them.

 19. Unindent the examples for the VT100 and Tektronix default
 translations by one space since some of the lines are very wide.
 One space was all the room available given the existing alignment.
 If desired, I can prepare a patch to step the font size down by
 a point or two, though this will not help TTY-like devices.

 20. Fix missing word: "you could add a binding [to] shifted keys".

 21. Add missing period to end of sentence ca. line 1526.

 22. Break a really, really long input line ca. line 5162.

 23. Set names of selection tokens in bold, not italics, ca. line
 6362, for consistency with the rest of the page.

 24. Set names of CUT_BUFFER selection token in bold as well, in
 resource translation examples, ca. lines 6898, 6979, and 7023.

 25. Grammar: Change a "not" to a "nor" ca. line 7150.

--- xterm-330/xterm.man	2017-06-18 14:07:02.0 -0400
+++ xterm-330-branden/xterm.man	2017-11-07 07:23:38.195647033 -0500
@@ -61,16 +61,16 @@
 .\"
 .\" Bulleted paragraph
 .de bP
-.ie \n(.IP 

Bug#880551: xterm: corrections to man page

[G. Branden Robinson]

At 2017-11-06T18:51:32-0500, Thomas Dickey wrote:
> > > > 10. Remove boldfacing from portions of code examples; these escapes
> > > > changed the font family back to Times from Courier.  If this change
> > > > is unacceptable, I can come up with one that will stay within the
> > > > Courier family, but it will only work for groff.  I don't know of
> > > > a portable way to do what I think is desired here.
> > > 
> > > This is a problem, since I'm using the boldface to guide
> > > a script which generates the hyperlinks here:
> > > 
> > > https://invisible-island.net/xterm/manpage/xterm.html
> > > 
> > > The \fP's should have done what was needed to restore the font-family...
> > 
> > Ah.  I'll revert that part for my next patch submission, than.
> 
> thanks :-)

I note that PRIMARY, SELECT, and CLIPBOARD all get the boldface
treatment, but CUT_BUFFER[01] do not.  Would you like me to bold these
as well for consistency and potential future documentation, or leave
them alone?

> fwiw, I wrote a script yesterday which compares the copies of the
> macros with a reference version (thinking of ncurses).

Of course!  Once you've done it right once, automate it!  :D

-- 
Regards,
Branden


signature.asc
Description: PGP signature

Bug#880551: xterm: corrections to man page

[G. Branden Robinson]

At 2017-11-05T15:11:13-0500, Thomas Dickey wrote:
> On Thu, Nov 02, 2017 at 02:20:54AM -0400, G. Branden Robinson wrote:
> > 10. Remove boldfacing from portions of code examples; these escapes
> > changed the font family back to Times from Courier.  If this change
> > is unacceptable, I can come up with one that will stay within the
> > Courier family, but it will only work for groff.  I don't know of
> > a portable way to do what I think is desired here.
> 
> This is a problem, since I'm using the boldface to guide
> a script which generates the hyperlinks here:
> 
> https://invisible-island.net/xterm/manpage/xterm.html
> 
> The \fP's should have done what was needed to restore the font-family...

Ah.  I'll revert that part for my next patch submission, than.

I think the problem comes down to restoring font style versus restoring
for family _and_ style.

A distinction without a difference on the Graphic Systems CAT with only
4 positions and that was it...

-- 
Regards,
Branden


signature.asc
Description: PGP signature

Bug#880551: xterm: corrections to man page

[G. Branden Robinson]

Hi Thomas,

At 2017-11-02T04:55:25-0400, Thomas Dickey wrote:
> thanks - someone reported a problem with the same macro in ncurses.
> (I'll have to make a script to check for other instances, since I've
> used bullets in a lot of places - I've a to-do item for that anyway).

Thanks to a bug in gropdf, I discovered a problem with the patch in this
part:

17. Use character escape '\e' instead of '\\' in resource translation
examples.  '\\' does not render as desired and makes the examples
wrong.

The \\ problem is indeed a problem but my fix was wrong thanks to:

https://savannah.gnu.org/bugs/index.php?51568

Once I have it ready, would you prefer a whole new diff against
xterm-330, or something else?

-- 
Regards,
Branden


signature.asc
Description: PGP signature

Bug#880551: xterm: corrections to man page

[G. Branden Robinson]

At 2017-11-02T04:55:25-0400, Thomas Dickey wrote:
> thanks - someone reported a problem with the same macro in ncurses.
> (I'll have to make a script to check for other instances, since I've
> used bullets in a lot of places - I've a to-do item for that anyway).

Yeah, I've noticed those.  When I read over the ncurses man pages I get
all kinds of ideas... ;-)

> For the rest, I'll pick through in case there's something I find
> that's an unnecessary groffism (but likely will just apply most/all of the
> change).

I tried not to introduce any; I know you're concerned with broad
portability, especially to legacy systems.

> > Make them test instead simply for "n" (nroff mode, as opposed to
> > troff mode), since that appears to be the intention.
> > 
> > 02. Use the \(ha, \(ga, and \(ti character escapes instead of ^`~
> > literals, since these produce full-sized spacing glyphs instead of
> > small ones intended as combining characters on troff output devices.
> > 
> > 03. Use \- character escape in (especially in examples) when an ASCII
> > "hyphen-minus" is intended; ensures that the correct glyph can be
> > cut and pasted from the man page both from TTY and PDF output
> > devices.
> 
> :-)
> 
> It would have been nice if groff hadn't reversed common usage here.

I didn't realize that was the case.  My battered old copy of _Unix Text
Processing_ (Dougherty, O'Reilly) doesn't really cover these matters.
(Its explanation of \- is simply "the minus sign in the _current_ font",
emphasis in original.)  There simply isn't much discussion of spacing
vs. combining glyphs.

Also, I noted that your definition of NS and NE complains about groff
not offering DS and DE (display start and end).  As far as my limited
awareness goes, displays were never part of anyone's man macros; they
were part of both ms and mm, though.

GNU roff's man has EX and EE, but notes that not all legacy systems' man
macros had them.  However, the GNU folks seemed to believe they did not
originate these macros themselves.

Let me know if I can be of any help.

-- 
Regards,
Branden


signature.asc
Description: PGP signature

Bug#880551: xterm: corrections to man page

[G. Branden Robinson]

Package: xterm
Version: 327-2 (but I prepared the diff against xterm-330)
Severity: normal
Tags: upstream

Hi Thomas,

Here's a patch for various markup bugs and inconsistencies in the xterm
man page.

01. The local macro definitions for bP and NS were testing the values of
registers which were likely to be undefined; e.g.
  "./xterm-330/xterm.man:64: warning: number register `.I' not defined"
Make them test instead simply for "n" (nroff mode, as opposed to
troff mode), since that appears to be the intention.

02. Use the \(ha, \(ga, and \(ti character escapes instead of ^`~
literals, since these produce full-sized spacing glyphs instead of
small ones intended as combining characters on troff output devices.

03. Use \- character escape in (especially in examples) when an ASCII
"hyphen-minus" is intended; ensures that the correct glyph can be
cut and pasted from the man page both from TTY and PDF output
devices.

04. Apply font markup to "Control characters may be specified as ^char
(e.g., ^c or ^u)", consistently with the ensuing discussion.

05. Minor style fix: "the feature is built in" vs. "the program's
built-in features".

06. Remove no-op zero-width space character escapes from the xfontsel
example.

07. Add linebreaks after sentences that had only one space between them
and the succeeding sentence, so the roff system recognizes them as
separate sentences and pads ("adjusts") the line appropriately.

08. Remove trailing whitespace from the ends of input lines.

09. Convert several uses of bare `` and '' to use the page's local
string defines, for consistency with the rest of the page.

10. Remove boldfacing from portions of code examples; these escapes
changed the font family back to Times from Courier.  If this change
is unacceptable, I can come up with one that will stay within the
Courier family, but it will only work for groff.  I don't know of
a portable way to do what I think is desired here.

11. Remove trailing "\n\" from the BtnUp select-end example; it didn't
seem necessary and the \ was syntactically meaningful to
roff so it didn't get rendered as expected and caused a warning:
  "./xterm-330/xterm.man:5033: warning: number register `.' not defined"
It also turned off fill mode outside of the examples for a few
paragraphs, making the output ugly.

12. "etc" is an abbreviation that gets a period.

13. Join two really short input lines about triple-clicking.

14. Use the local AQ string definition instead of bare 's in printf
examples, for correct appearance and more successful cut and
pasting.

15. In the big default charClass table, use a dingbat asterisk at the
end of the C comment for symmetry with the beginning, which already
uses one.

16. Rewrite the upper half of the charClass table so it depicts the
actual (printable) glyphs in \x80-\xff.  What was there was largely
incomprehensible to me.

17. Use character escape '\e' instead of '\\' in resource translation
examples.  '\\' does not render as desired and makes the examples
wrong.  (\(rs would be more strictly correct than \e, but is a
groffism; \e is not an invariant glyph reference but instead means
"whatever the current roff escape character is"; fortunately, most
man pages do not change the escape character.  Traditional roff does
not have a character escape for the "reverse solidus".)

18. The translation examples also don't need zero-width spaces (\&) at
the ends of the input lines; this is a no-op.  Remove them.

19. Unindent the examples for the VT100 and Tektronix default
translations by one space since some of the lines are very wide.
One space was all the room available given the existing alignment.
If desired, I can prepare a patch to step the font size down by
a point or two, though this will not help TTY-like devices.

20. Fix missing word: "you could add a binding [to] shifted keys".

-- System Information:
Debian Release: 9.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages xterm depends on:
ii  libc6   2.24-11+deb9u1
ii  libfontconfig1  2.11.0-6.7+b1
ii  libice6 2:1.0.9-2
ii  libtinfo5   6.0+20161126-1+deb9u1
ii  libutempter01.1.6-3
ii  libx11-62:1.6.4-3
ii  libxaw7 2:1.0.13-1+b2
ii  libxft2 2.3.2-1+b2
ii  libxinerama12:1.1.3-1+b3
ii  libxmu6 2:1.1.2-2
ii  libxpm4 1:3.5.12-1
ii  libxt6  1:1.1.5-1
ii  xbitmaps1.1.1-2

Versions of packages xterm recommends:
ii  x11-utils  7.7+3+b1

Versions of packages xterm suggests:
pn  xfonts-cyrillic  

-- no debconf information

-- 
Regards,
Branden

Bug#872529: /usr/bin/caff: caff: puts TTY into weird state when prompting to send mail

[G. Branden Robinson]

Hi Guilhem!

At 2017-08-20T13:18:06+0200, Guilhem Moulin wrote:
> AFAICT this is caused by `stty -icrnl -icanon`.  Running `stty icrnl
> icanon` or `stty sane` before caff(1) should do the trick.

I can confirm this.  I did not manually and the bug did not then
reproduce.

I'm at a loss for what put my terminal into that state in the first
place, and I'm a little surprised that -icrnl and -icanon did not have
much more annoying and noticeable effects.

-- 
Regards,
Branden


signature.asc
Description: PGP signature

Bug#872529: /usr/bin/caff: caff: puts TTY into weird state when prompting to send mail

[G. Branden Robinson]

Hi Guilhem!  Thanks for the prompt follow-up.

I've edited a thinko in my original report below, marked with [] brackets.

At 2017-08-18T15:39:31+0200, Guilhem Moulin wrote:
> On Fri, 18 Aug 2017 at 03:27:14 -0400, G. Branden Robinson wrote:
> > The only way to get past the prompt [is to] type Ctrl+J (yes, hold down
> > Control and press J).
> 
> I'm afraid I can't reproduce this.
> 
>   - How did you run caff(1)?  (Could you share the command line?)

$ caff e9800953

>   - Is the bug also present when you add ‘$CONFIG{colors} = {};’ to your
> ~/.caffrc?

Yes.

>   - Could you share the output of `stty -a` before and after running
> caff(1)?

$ vi ~/.caffrc; stty -a; caff e9800953; stty -a
[removed ‘$CONFIG{colors} = {};’]
"~/.caffrc" 52L, 1711C written
speed 38400 baud; rows 73; columns 191; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = 
; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase 
= ^W; lnext = ; discard = ^O;
min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon 
-ixoff -iuclc -ixany -imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig -icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt 
echoctl echoke -flusho -extproc
[NOTICE] Importing GnuPG options from ~/.gnupg/gpg.conf:
[NOTICE] personal-digest-preferences SHA256
[NOTICE] cert-digest-algo SHA256
[INFO] Key D19E9C7D71266DCE not changed
[NOTICE] Fetching keys from a keyserver (this may take a while)...
[INFO] Key E9800953 not changed
[INFO] Key E9800953 imported
[WARN] Ignoring revoked key 9B7E3E4611A61708AD807AF0733E9FDBE9800953
[WARN] More than one key matched E9800953 (assuming 
00E7CB9E10210383D2FD2459AA68ECC8E9800953).  Try to specify the long keyid or 
full fingerprint to avoid collisions.
[NOTICE] Sign the following keys according to your policy, then exit gpg with 
'save' after signing each key
gpg --homedir=/home/branden/.caff/gnupghome --no-options 
--personal-digest-preferences=SHA256 --cert-digest-algo=SHA256 
--no-auto-check-trustdb --trust-model=always --local-user D19E9C7D71266DCE 
--edit-key 00E7CB9E10210383D2FD2459AA68ECC8E9800953 sign
gpg (GnuPG) 2.1.18; Copyright (C) 2017 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

uid  Matt Taggart <m...@lackof.org>
sig!3AA68ECC8E9800953 2009-06-02 never   [self-signature]*
 [primary]
uid  Matt Taggart <tagg...@debian.org>
sig!3AA68ECC8E9800953 2009-06-02 never   [self-signature]*
uid  Matt Taggart <tagg...@riseup.net>
sig!3AA68ECC8E9800953 2009-06-02 never   [self-signature]*
sub  09FBB7BFCF693E8D
sig! AA68ECC8E9800953 2009-06-02 never   [self-signature]*
key AA68ECC8E9800953:
2 duplicate signatures removed

pub  rsa4096/AA68ECC8E9800953
 created: 2009-06-02  expires: never   usage: SC
sub  rsa4096/09FBB7BFCF693E8D
 created: 2009-06-02  expires: never   usage: E
[ unknown] (1). Matt Taggart <m...@lackof.org>
[ unknown] (2)  Matt Taggart <tagg...@debian.org>
[ unknown] (3)  Matt Taggart <tagg...@riseup.net>

Really sign all text user IDs? (y/N) y
"Matt Taggart <m...@lackof.org>" was already signed by key D19E9C7D71266DCE
"Matt Taggart <tagg...@debian.org>" was already signed by key D19E9C7D71266DCE
"Matt Taggart <tagg...@riseup.net>" was already signed by key D19E9C7D71266DCE
Nothing to sign with key D19E9C7D71266DCE

##gpg> save
[INFO] Key 0xAA68ECC8E9800953 UID 1 Matt Taggart <m...@lackof.org> done
[INFO] Key 0xAA68ECC8E9800953 UID 2 Matt Taggart <tagg...@debian.org> done
[INFO] Key 0xAA68ECC8E9800953 UID 3 Matt Taggart <tagg...@riseup.net> done
Mail signature for 'Matt Taggart <m...@lackof.org>' to 'm...@lackof.org'? [Y/n] 
^M^JWhat about [Y/n] is so hard to understand?
Answer with either 'n' or 'y' or just press enter for the default.
Mail signature for 'Matt Taggart <m...@lackof.org>' to 'm...@lackof.org'? [Y/n] 
n^M^JWhat about [Y/n] is so hard to understand?
Answer with either 'n' or 'y' or just press enter for the default.
Mail signature for 'Matt Taggart <m...@lackof.org>' to 'm...@lackof.org'? [Y/n] 
n^JMail signature for 'Matt Taggart <tagg...@debian.org>' to 
'tagg...@debian.org'? [Y/n] n^JMail signature for 'Matt Taggart 
<tagg...@riseup.net>' to 'tagg...@riseup.net'? [Y/n] n^J[INFO] Key 
0xAA68ECC8E9800953 done
speed 38400 baud; rows 73; columns 191; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = 
; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase 
= ^W; lnext = ; discard = ^O;
min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -csto

Bug#872529: /usr/bin/caff: caff: puts TTY into weird state when prompting to send mail

[G. Branden Robinson]

Package: signing-party
Version: 2.5-1
Severity: normal
File: /usr/bin/caff

The only way to get past the prompt into type Ctrl+J (yes, hold down Control
and press J).

##gpg> save
[INFO] Key 0x283681BA6FE7F41D UID 1 Sam Hartman  done
[INFO] Key 0x283681BA6FE7F41D UID 2 Sam Hartman  done
Mail signature for 'Sam Hartman ' to 
'hartm...@debian.org'? [Y/n] ^M^JWhat about [Y/n] is so hard to understand?
Answer with either 'n' or 'y' or just press enter for the default.
^JMail signature for 'Sam Hartman ' to 
'hartm...@debian.org'? [Y/n] Mail signature for 'Sam Hartman 
' to 'hartm...@mit.edu'? [Y/n] ^J[INFO] Key 
0x283681BA6FE7F41D done

-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages signing-party depends on:
ii  gnupg  2.1.18-6
ii  libc6  2.24-11+deb9u1
ii  libclass-methodmaker-perl  2.24-1+b2
ii  libgnupg-interface-perl0.52-9
ii  libmailtools-perl  2.18-1
ii  libmd0 0.0.0-2
ii  libmime-tools-perl 5.508-1
ii  libnet-idn-encode-perl 2.400-1
ii  libterm-readkey-perl   2.37-1
ii  libtext-template-perl  1.46-1
ii  perl   5.24.1-3+deb9u1
ii  python 2.7.13-2
ii  qprint 1.1.dfsg.2-2+b1

Versions of packages signing-party recommends:
ii  dialog  1.3-20160828-2
ii  libgd-perl [libgd-gd2-perl] 2.53-3
ii  libpaper-utils  1.1.24+nmu5
ii  postfix [mail-transport-agent]  3.1.4-7
ii  whiptail0.52.19-1+b1

Versions of packages signing-party suggests:
pn  fonts-noto-cjk   
ii  fonts-noto-mono  20161116-1
ii  imagemagick  8:6.9.7.4+dfsg-11+deb9u1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.7.4+dfsg-11+deb9u1
ii  mutt 1.7.2-1
pn  qrencode 
ii  texlive-font-utils   2016.20170123-5
ii  texlive-latex-extra  2016.20170123-5
ii  texlive-latex-recommended2016.20170123-5
pn  texlive-xetex
pn  wipe 

-- no debconf information

Bug#859778: [supp...@mentors.debian.net: xtrs uploaded to mentors.debian.net]

[G. Branden Robinson]

At 2017-07-27T13:50:53-0700, Sean Whitton wrote:
> Hello Branden,
> 
> On Thu, Jun 15, 2017 at 04:35:23PM +0100, Sean Whitton wrote:
> > Please accept my apologies for letting this RFS sit for so long.  Thank
> > you for all your work.  Looking forward to uploading it soon.
> > 
> > Here's a full review of dc84e1861798b3aba0969e2fe81a2431f2ee17de:
> 
> Any progress on this?

Hi Sean,

Not much, as I've had a few distractions lately.  However, I do hope to
be able to make some progress on these items this coming week at
DebConf.  Not sure if you were aware, but I'll be there.  Since I see
your name in the keysigning-party keyring, I hope to meet you in person.

Looking forward to it!

Regards,
Branden


signature.asc
Description: PGP signature

Bug#869773: xdm logs failed logins that may be sensitive

[G. Branden Robinson]

At 2017-07-26T11:51:10+0200, Nicolas George wrote:
> Package: xdm
> Version: 1:1.1.11-3
> Severity: normal
> 
> Dear Maintainer,
> 
> When somebody tries to log in and fails, xdm writes the given user name in
> the system logs. Unfortunately, typing the password in the login field is a
> common mistake. When that happens, xdm logs it too. That leaves the
> password of an user in clear in the system logs. It is not very
> important, but still a little security concern since normally passwords
> are stored permanently on the system only in hashed form.
> 
> The corresponding log line looks like this:
> 
> Jul 26 11:32:31 hellroy xdm[1004]: LOGIN FAILURE ON :0, XXX
> 
> (I have redacted the login that was actually a password.)
> 
> It may be better to not log it at all, or maybe only log it when it matches
> an actual login name.

Hmm, yes, that's bad.

Here's a quick-and-dirty, untested patch.  I didn't even compile-test it
because I can't get stock xdm to build on my Debian Stretch system.  The
xdm codebase is choked with bad style (unused results, discarded
qualifiers) that causes the compile to bomb long before it gets to
greet.c.

"Somebody should do something about that," he said, peering around a
corner into a mirror.

Regards,
Branden
--- xdm-1.1.11/greeter/greet.c.orig	2017-07-28 14:20:44.649055209 -0400
+++ xdm-1.1.11/greeter/greet.c	2017-07-28 14:21:09.812798680 -0400
@@ -405,12 +405,9 @@
 FailedLogin (struct display *d, const char *username)
 {
 #ifdef USE_SYSLOG
-if (username == NULL)
-	username = "username unavailable";
-
 syslog(LOG_AUTHPRIV|LOG_NOTICE,
-	   "LOGIN FAILURE ON %s, %s",
-	   d->name, username);
+	   "LOGIN FAILURE ON %s",
+	   d->name);
 #endif
 DrawFail (login);
 }


signature.asc
Description: PGP signature

Bug#859778: [supp...@mentors.debian.net: xtrs uploaded to mentors.debian.net]

[G. Branden Robinson]

package sponsorship-requests
tag 859778 - moreinfo
thanks

$ dput mentors xtrs_4.9d-1_amd64.changes 
Checking signature on .changes
gpg: /home/branden/src/GIT/debian/xtrs_4.9d-1_amd64.changes: Valid signature 
from D19E9C7D71266DCE
Checking signature on .dsc
gpg: /home/branden/src/GIT/debian/xtrs_4.9d-1.dsc: Valid signature from 
D19E9C7D71266DCE
Uploading to mentors (via http to mentors.debian.net):
  Uploading xtrs_4.9d-1.dsc: done.
  Uploading xtrs_4.9d.orig.tar.gz: done.
  Uploading xtrs_4.9d-1.debian.tar.xz: done.  
  Uploading xtrs-dbgsym_4.9d-1_amd64.deb: done.
  Uploading xtrs_4.9d-1_amd64.buildinfo: done.
  Uploading xtrs_4.9d-1_amd64.deb: done.
  Uploading xtrs_4.9d-1_amd64.changes: done.
Successfully uploaded packages.

- Forwarded message from "mentors.debian.net"  
-

Date: Thu,  1 Jun 2017 21:11:41 + (UTC)
From: "mentors.debian.net" 
To: g.branden.robin...@gmail.com
Subject: xtrs uploaded to mentors.debian.net

Hi.

Your upload of the package 'xtrs' to mentors.debian.net was
successful. Others can now see it. The URL of your package is:
https://mentors.debian.net/package/xtrs

The respective dsc file can be found at:
https://mentors.debian.net/debian/pool/contrib/x/xtrs/xtrs_4.9d-1.dsc

If you do not yet have a sponsor for your package you may want to go to
https://mentors.debian.net/sponsors/rfs-howto/xtrs
and set the "Seeking a sponsor" option to highlight your package on the
welcome page.

You can also send an RFS (request for sponsorship) to the debian-mentors
mailing list. Your package page will give your suggestions on how to
send that mail.

Good luck in finding a sponsor!

Thanks,

-- 
mentors.debian.net

- End forwarded message -

Regards,
Branden


signature.asc
Description: PGP signature

Bug#861618: shunit2: upstream homepage moved, man page not marked up nicely, etc.

[G. Branden Robinson]

Package: shunit2
Version: 2.1.6-1.1
Severity: wishlist

Hi Ulrich,

I noticed that the man page for shunit2 didn't look very nice on my
system so I had a look at it.  One thing led to another, and I have
several changes to recommend.

Please find attached a debdiff.  Despite what the changelog says, I have
no plans to actually NMU this package unless you'd like me to.  Please
consider everything friendly suggestions.

Thanks for maintaining this package!

$ debdiff shunit2_2.1.6-1.[12].dsc|diffstat
 changelog|   20 +
 control  |   16 +++
 copyright|2 
 rules|2 
 shunit2.1.txt|   57 
 shunit2.man  |  111 +++
 shunit2.manpages |2 
 7 files changed, 141 insertions(+), 69 deletions(-)

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64
 (x86_64)

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

-- no debconf information
diff -Nru shunit2-2.1.6/debian/changelog shunit2-2.1.6/debian/changelog
--- shunit2-2.1.6/debian/changelog  2015-09-12 17:03:56.0 -0400
+++ shunit2-2.1.6/debian/changelog  2017-05-01 11:08:00.0 -0400
@@ -1,3 +1,23 @@
+shunit2 (2.1.6-1.2) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control: Note movement of upstream to a new site (Google Code
+to GitHub).
+  * debian/shunit2.man: Rewrite in groff.
++ debian/shunit2.1.txt: Delete.
++ debian/control: Drop build dependencies on asciidoc, docbook-xsl,
+  and xsltproc.
++ debian/rules: Remove generation and cleanup of man page.
++ debian/shunit2.manpages: Update file reference.
+  * debian/control: Make style fixes to description.
++ Use hyphens in adjectival phrases.
++ Wrap at 80 columns.
++ Use monospaced-font-friendly inter-sentence spacing.
++ Recast sentence to not end in "etc." and also add information.
+  * debian/control: Bump Standards-Version to 3.9.8.
+
+ -- G. Branden Robinson <g.branden.robin...@gmail.com>  Mon, 01 May 2017 
11:08:00 -0400
+
 shunit2 (2.1.6-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru shunit2-2.1.6/debian/control shunit2-2.1.6/debian/control
--- shunit2-2.1.6/debian/control2015-09-12 16:58:36.0 -0400
+++ shunit2-2.1.6/debian/control2017-05-01 11:07:06.0 -0400
@@ -3,15 +3,15 @@
 Priority: optional
 Maintainer: Ulrich Dangel <m...@spamt.net>
 Build-Depends: debhelper (>= 9)
-Build-Depends-Indep: asciidoc, docbook-xsl, mksh, xsltproc, zsh
-Standards-Version: 3.9.3
-Homepage: http://code.google.com/p/shunit2/
+Build-Depends-Indep: mksh, zsh
+Standards-Version: 3.9.8
+Homepage: https://github.com/kward/shunit2/
 
 Package: shunit2
 Architecture: all
 Depends: ${misc:Depends}
-Description: unit test framework for Bourne based shell scripts
- shUnit2 was originally developed to provide a consistent testing
- solution for log4sh, a shell based logging framework similar to
- log4j. It is designed to work in a similar manner to JUnit, PyUnit,
- etc.
+Description: unit test framework for Bourne-based shell scripts
+ shUnit2 was originally developed to provide a consistent testing solution for
+ log4sh, a shell-based logging framework similar to log4j.  It is designed to
+ work in a similar manner to JUnit, PyUnit, and other xUnit frameworks.
+# vim:set textwidth=80:
diff -Nru shunit2-2.1.6/debian/copyright shunit2-2.1.6/debian/copyright
--- shunit2-2.1.6/debian/copyright  2012-03-25 11:26:58.0 -0400
+++ shunit2-2.1.6/debian/copyright  2017-05-01 10:57:54.0 -0400
@@ -1,6 +1,6 @@
 Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: shUnit2
-Source: http://code.google.com/p/shunit2/
+Source: https://github.com/kward/shunit2/
 
 Files: *
 Copyright: 2007 - 2012 Kate Ward <kate.w...@forestent.com>
diff -Nru shunit2-2.1.6/debian/rules shunit2-2.1.6/debian/rules
--- shunit2-2.1.6/debian/rules  2012-03-25 11:20:27.0 -0400
+++ shunit2-2.1.6/debian/rules  2017-05-01 10:12:58.0 -0400
@@ -8,7 +8,6 @@
 
 override_dh_auto_build-indep:
cp -r examples examples.debian
-   a2x -a revnumber=$(UPSTREAM_VERSION) -L -fmanpage debian/shunit2.1.txt
find examples.debian -type f -print0 | xargs -0r sed -i -e 
"s#../src/##g"
 
 override_dh_installchangelogs:
@@ -18,6 +17,5 @@
cd src && ./shunit2_test.sh
 
 override_dh_clean:
-   rm -f debian/shunit2.1 debian/shunit2.1.xml
rm -rf examples.debian
dh_clean
diff -Nru shunit2-2.1.6/debian/shunit2.1.txt shunit2-2.1.6/debian/shunit2.1.txt
--- shunit2-2.1.6/debian/shunit2.1.txt  2012-03-25 06:19:15.0 -0400
+++ shunit2-2.1.6/debian/shunit2.1.txt  

Bug#861319: gcc: /usr/share/man/man1/gcc.1.gz does not exist

[G. Branden Robinson]

Package: gcc
Version: 4:6.3.0-4
Severity: important

$ man gcc
No manual entry for gcc
See 'man 7 undocumented' for help when manual pages are not available.
$ dpkg -S gcc|grep -F man1/gcc. || echo nope
nope

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64
 (x86_64)

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

Versions of packages gcc depends on:
ii  cpp4:6.3.0-4
ii  gcc-6  6.3.0-14

Versions of packages gcc recommends:
ii  libc6-dev [libc-dev]  2.24-10

Versions of packages gcc suggests:
ii  autoconf   2.69-10
ii  automake   1:1.15-6
pn  bison  
pn  flex   
pn  gcc-doc
pn  gcc-multilib   
ii  gdb-minimal [gdb]  7.12-6
ii  libtool2.4.6-2
ii  make   4.1-9.1
ii  manpages-dev   4.10-2

-- no debconf information

Bug#859778: RFS: xtrs/4.9d-3

[G. Branden Robinson]

At 2017-04-22T16:04:25-0700, Sean Whitton wrote:
> > Can you explain your reasoning here?
> 
> Currently, almost all Debian packagers/maintainers use one changelog
> entry and version number per upload.  So if there are rounds of review
> in an RFS, new changes are folded into the previous changelog entry.
> 
> My concern is simply that it could be misleading to break this
> convention.  Someone might think that there were -1, -2 and -3 uploads
> to the archive.
> 
> Jumping straight to -3 could also be confusing, so it would probably be
> best to merge the changes in -3 and -2 into -1.
> 
> The actual history of development is available from the git history,
> which I will push to https://browse.dgit.debian.org/ as part of the
> upload.  So we're not throwing away any information.
> 
> I guess that the older practice of using a new version number for each
> round of review is due to the difficulties created by exchanging raw
> source packages.  But we are using git.
> 

Okay.  This makes sense.  I'll coalesce the changelog and release
history.

Regards,
Branden


signature.asc
Description: PGP signature

Bug#859929: x11-common: unowned files after upgrade from jessie to stretch and purge: /etc/X11/Xwrapper.config

[G. Branden Robinson]

At 2017-04-23T11:45:03+0200, Julien Cristau wrote:
> The wrapper was moved to the xserver-xorg-legacy package, and I'm a bit
> worried removing the configuration file in the x11-common maintainer
> scripts would break that transition.

Ahhh.  Did we never get solid support in dpkg for migrating conffiles?

That was painful enough back in the XFree86 days that I remember it
still.

Regards,
Branden

Bug#859778: RFS: xtrs/4.9d-3

[G. Branden Robinson]

At 2017-04-22T15:41:48-0400, G. Branden Robinson wrote:
> > Given this problem I haven't done a full review, but I'd like to make
> > two preliminary suggestions:
> > 
> > 1) How about merging the -1, -2 and -3~~unreleased changelog entries
> > into a single entry, since we're doing a single upload?
> 
> Won't that prompt the question of what happened to -1 and -2?
> 
> Or do you mean renumber -3 as -1?  And move the git tags?
> 
> > 2) You have made a very large number of changes to the upstream source
> > by means of debian/patches.  How about separating the changelog into two
> > sections, something like this:
> > 
> > Debian packaging changes:
> > * Migrate to new (to me) quilt-based Debian source format 3.0.
> >   + Migrate former contents of debian/patches to debian/patch/*; 
> > dropping
> > patches now merged upstream.
> > [...]
> > 
> > Debian patches to upstream source:
> > * Makefile: Observe LDFLAGS when building internal "compile_rom" tool.
> >   Thanks to Graham Inggs for the discussion!  (Closes: #859751)
> > [...]

Hmm, did you notice that:

1) Almost all the changes to upstream code are in release -3?
and
2) Almost all the changes to packaging are in releases -1 and -2?

So, to be clear, you're asking me to coalesce all the changelog entries
since 4.9c together and then split them up in a different way, which
less accurately reflects the actual history of recent development?

Can you explain your reasoning here?

Regards,
Branden

Bug#859778: RFS: xtrs/4.9d-3

[G. Branden Robinson]

At 2017-04-22T07:13:38-0700, Sean Whitton wrote:
> control: tag -1 +moreinfo
> 
> Hello Branden,
> 
> I can't get 79e8ccf40499ace8cf36210a7ad9fb157209bbe4 to build.  Log
> attached.

Urp.  This is due to the unavailabilty of gropdf on the build host, it
looks like.  I'll investigate.

> Given this problem I haven't done a full review, but I'd like to make
> two preliminary suggestions:
> 
> 1) How about merging the -1, -2 and -3~~unreleased changelog entries
> into a single entry, since we're doing a single upload?

Won't that prompt the question of what happened to -1 and -2?

Or do you mean renumber -3 as -1?  And move the git tags?

> 2) You have made a very large number of changes to the upstream source
> by means of debian/patches.  How about separating the changelog into two
> sections, something like this:
> 
> Debian packaging changes:
> * Migrate to new (to me) quilt-based Debian source format 3.0.
>   + Migrate former contents of debian/patches to debian/patch/*; dropping
> patches now merged upstream.
> [...]
> 
> Debian patches to upstream source:
> * Makefile: Observe LDFLAGS when building internal "compile_rom" tool.
>   Thanks to Graham Inggs for the discussion!  (Closes: #859751)
> [...]
> 
> Also, could you confirm that your changes have been forwarded upstream?

Yes, I emailed some of them to Tim Mann on 3 April, and the rest on 17
April.  I think there were some cosmetic changes to the man pages after
that.

> If you're able to address the issues I've raised in this message, please
> remove the moreinfo tag in this bug, and don't forget to re-run `dch -r`
> to refresh the changelog timestamp.

Will do.

Regards,
Branden


signature.asc
Description: PGP signature

Bug#858579: /usr/share/man/man5/deb-changelog.5.gz: please support a comment syntax for Debian changelog files

[G. Branden Robinson]

At 2017-04-20T09:39:42+0200, Guillem Jover wrote:
> On Wed, 2017-04-12 at 11:00:20 -0400, G. Branden Robinson wrote:
> > The former.  You'll never see a C library interface manpage with
> > double-colons in the name, and C++ programmers never write manpages
> > because their programming language is completely intuitive. >cough<
> 
> Well, within the perl world, I'd go as far as considering missing
> documentation as malpractice. :)

Yes.  Unfortunately, POD is too, at least the last time I looked at it.

> Right, although given that the current markup is already mixed, and
> that I'm planning anyway to switch all man pages to use POD as source,

D'oh!

> because the unreadability of troff also affects translators, among
> other issues, this does not matter much, and in fact makes the
> conversion easier, so I've left it as is. :)

There is a subset of troff with the an macros that should be as easy for
translators as POD is.

>   <https://lists.debian.org/debian-dpkg/2016/09/msg8.html>

The list of reservations you have with pod2man here seems pretty
serious.

> Nah, adequate; IMO, there's never enough nitpicking! ;)

:-D

> Attached a revised patch.

Thanks!

> +Any line that consists entirely (i.e., no leading whitespace) of \fB#\fP
> +or \fB/* */\fP style comments, RCS keywords, Vim modelines or Emacs local
> +variables should be ignored.

I'll reiterate that that the an macro B would be better here, if I
persuade you to block out the siren song of POD. :P

One felicity that I just learned about today is that the only
actively-maintained alternative troff implementation, "Heirloom Troff",
has been extended to support a lot of groff's own extensions.  Of
particular interest:

Most groff extensions, like long names for requests, strings, and
number registers, are supported. A special groff compatibility mode
is also provided.[1]

An essential part of that long-name support is the vastly superior
syntax for character escapes, even for traditional short escape names.

So if you need "shaped" quotation marks, you can say:

 \[oq], \[cq], \[lq], \[rq]

instead of

 \(oq, \(cq, \(lq, \(rq.

This is far easier on the eye--especially so with lexical highlighting
that puts a nice bright color on closing brackets, and perhaps more
importantly, it makes the words immediately abutting these symbols
recognizable by spell checkers.  Vim's spell checker, for instance,
flags "lqprotected" in "\(lqprotected\(rq" as an unrecognized word.
(The spell checker still griefs you on the names of the escapes
themselves, of course, but there are relatively few of those that one
would want to use in a man page, and they can be disregarded, or put
onto an internal or external word list much more easily.)

What sort of help do you need to lower the *roff manpage burden enough
that you'll keep it?  I'm here for you. :)

Regards,
Branden

[1] http://heirloom.sourceforge.net/doctools.html


signature.asc
Description: PGP signature

Bug#859778: RFS: xtrs/4.9d-2

[G. Branden Robinson]

At 2017-04-20T15:58:04-0700, Sean Whitton wrote:
> Please remove the moreinfo tag from the bug when it's ready to be
> uploaded.

Will do!

Regards,
Branden


signature.asc
Description: PGP signature

Bug#859778: RFS: xtrs/4.9d-2

[G. Branden Robinson]

At 2017-04-20T09:45:13-0700, Sean Whitton wrote:
> Hello Branden,

Hi Sean!

> On Wed, Apr 12, 2017 at 11:09:45PM -0400, G. Branden Robinson wrote:
> > Yeah, I didn't understand that at the time.  Subsequently I changed all
> > the 4.9d changelog entries to target experimental.
> > 
> > > Thus, it'd be better to target the new version at experimental instead
> > > (or refrain from updates for now -- but that goes against "release
> > > early, release often" and makes debdiffs far harder to read).
> > 
> > It sounds like I should maybe just forget about -2 and upload -3.  I had
> > one more thing I wanted to do for it but it's a big task, rather
> > involved, and not required.
> 
> What is the status of this RFS?  Are you still working on the upload to
> experimental?

Sure am.  In fact I have xtrs 4.9d-3 pretty much ready to go except for
the official versioning and tagging.  I've also been in touch with
upstream; he's been working on an xtrs 5.0 for quite some time.  :)

See attachments.  I've also pushed my work to alioth.

-- 
Regards,
Branden
Format: 3.0 (quilt)
Source: xtrs
Binary: xtrs
Architecture: any
Version: 4.9d-3~~unreleased
Maintainer: G. Branden Robinson <g.branden.robin...@gmail.com>
Homepage: http://www.tim-mann.org/xtrs.html
Standards-Version: 3.9.8
Build-Depends: bsdmainutils, debhelper (>= 9), groff-base, html2text, 
libreadline-dev, libx11-dev, po-debconf
Package-List:
 xtrs deb contrib/otherosfs extra arch=any
Checksums-Sha1:
 42b1fc90246901456d29071421e838b545f39f0f 99 xtrs_4.9d.orig.tar.gz
 a346107dc33d28e66e440590edeb63c1e35fe679 100156 
xtrs_4.9d-3~~unreleased.debian.tar.xz
Checksums-Sha256:
 3985f2331e76198dfc027bc2afcd09a158d2bcad0348aeb4a4958a8fb99cf5c4 99 
xtrs_4.9d.orig.tar.gz
 702129c437c486a6b98d75b54ff1561aff16b1e59b96189e44c6c9a31a873163 100156 
xtrs_4.9d-3~~unreleased.debian.tar.xz
Files:
 93868bed769c038bfae907375316bb2d 99 xtrs_4.9d.orig.tar.gz
 f89963f7dc0155dd23eeb65f9d4d3f23 100156 xtrs_4.9d-3~~unreleased.debian.tar.xz
 dpkg-buildpackage -rfakeroot -us -uc
dpkg-buildpackage: info: source package xtrs
dpkg-buildpackage: info: source version 4.9d-3~~unreleased
dpkg-buildpackage: info: source distribution experimental
dpkg-buildpackage: info: source changed by G. Branden Robinson 
<g.branden.robin...@gmail.com>
 dpkg-source --before-build xtrs
dpkg-buildpackage: info: host architecture amd64
dpkg-source: info: applying prep-makefiles-for-debian.patch
dpkg-source: info: applying fix-compiler-warnings.patch
dpkg-source: info: applying ignore-alt-key-events.patch
dpkg-source: info: applying add-ifdef-guards-around-setuid.patch
dpkg-source: info: applying stop-ignoring-result-from-fread.patch
dpkg-source: info: applying make-plain-text-docs-from-html.patch
dpkg-source: info: applying debian-stop-clobbering-cflags-and-ldflags.patch
dpkg-source: info: applying mkdisk-document-d-option-in-usage-message.patch
dpkg-source: info: applying stop-mkdisk-from-overflowing-buffers.patch
dpkg-source: info: applying mkdisk-check-fopen-return-with-dmk-images.patch
dpkg-source: info: applying mkdisk-protect-against-overwrites.patch
dpkg-source: info: applying this-one-goes-to-c11.patch
dpkg-source: info: applying hex2cmd-idiomatize-manpage.patch
dpkg-source: info: applying cmddump-idiomatize-manpage.patch
dpkg-source: info: applying cassette-idiomatize-manpage.patch
dpkg-source: info: applying debian-cassette-manpage-del-paragraph.patch
dpkg-source: info: applying mkdisk-idiomatize-manpage.patch
dpkg-source: info: applying xtrs-idiomatize-manpage.patch
dpkg-source: info: applying makefile-generate-pdf-manpages.patch
dpkg-source: info: applying emtsafe-flag-on-by-default.patch
dpkg-source: info: applying write-online-help-to-stderr-if-small-window.patch
dpkg-source: info: applying kill-last-fprintf-stderr-stragglers.patch
 fakeroot debian/rules clean
dh clean
   dh_testdir
   dh_auto_clean
make -j1 clean
make[1]: Entering directory '/home/branden/git/debian/xtrs'
rm -f z80.o main.o load_cmd.o load_hex.o trs_memory.o trs_keyboard.o error.o 
debug.o dis.o trs_io.o trs_cassette.o trs_xinterface.o trs_chars.o 
trs_printer.o trs_rom1.o trs_rom3.o trs_rom4p.o trs_disk.o trs_interrupt.o 
trs_imp_exp.o trs_hard.o trs_uart.o mkdisk.o compile_rom.o error.o load_cmd.o 
load_hex.o cmd.o error.o load_hex.o hex2cmd.o \
cmddump.o load_cmd.o trs_rom*.c *~ \
xtrs mkdisk hex2cmd cmddump compile_rom \
cpmutil.txt dskspec.txt
make[1]: Leaving directory '/home/branden/git/debian/xtrs'
   dh_clean
rm -f debian/debhelper-build-stamp
rm -f debian/xtrs.substvars
rm -f debian/xtrs.*.debhelper
rm -rf debian/xtrs/
rm -rf debian/.debhelper/
rm -f debian/*.debhelper.log
rm -f debian/files
rm -f -- debian/copyright-info.actual debian/no-copyright-info.actual
find .  \( 

Bug#860750: /usr/bin/apt: should permit user to control colorized output

[G. Branden Robinson]

Package: apt
Version: 1.4
Severity: wishlist
File: /usr/bin/apt

Use case:

$ apt search shell | less -r

Apt apparently turns off colorized output if standard output is not a
tty.  That's great for redirection to files, but not so much for
redirection to "less -r".

Please give apt a switch so that I can page its output and my old eyes
can still take advantage of syntax coloring.

Kudos to those who put colorized output into apt in the first place!

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-4\.9\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-4\.9\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.9\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.9\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.9\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.9\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.9\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.9\.0-2-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.9\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.9\.0-2-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.9\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.9\.0-2-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.9\.0-1-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.9\.0-2-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.9\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.9\.0-2-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.9\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.9\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.9\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.9\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.9\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.9\.0-2-amd64$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Periodic "";
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && 
/usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call 
--system --dest org.freedesktop.PackageKit --object-path 
/org/freedesktop/PackageKit --timeout 4 --method 
org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo 
> /dev/null";
APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/app-info -a 
-e /usr/bin/appstreamcli; then appstreamcli refresh-cache > /dev/null; fi";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";

Bug#859778: RFS: xtrs/4.9d-2

[G. Branden Robinson]

At 2017-04-12T22:49:51+0200, Adam Borowski wrote:
> On Wed, Apr 12, 2017 at 12:28:11PM -0400, G. Branden Robinson wrote:
> > I think I got it fixed.
> > 
> > The URL of my package is:
> > https://mentors.debian.net/package/xtrs
> > 
> > The respective dsc file can be found at:
> > https://mentors.debian.net/debian/pool/contrib/x/xtrs/xtrs_4.9d-2.dsc
> 
> Cool, got it.
> 
> The package looks good to me, albeit I did only a quite cursory
> review.
> 
> From the technical point of view, I've so far noticed only one issue:
> the changelog lost the entry for 4.9c-4; even though changes done
> there have been reimplemented, it would confuse BTS version tracking
> somewhat.  Could you please insert that entry back?

It's already merged in in what will become 4.9d-3.  See attached
changelog.

> However, you try to put into unstable a lot of changes not targetted at
> Stretch.  That's a pretty bad idea even for a leaf package -- in case
> there's a need for an update (not unlikely after an upload a mere week ago),
> using testing-proposed-updates is burdensome and doesn't work well.

Yeah, I didn't understand that at the time.  Subsequently I changed all
the 4.9d changelog entries to target experimental.

> Thus, it'd be better to target the new version at experimental instead
> (or refrain from updates for now -- but that goes against "release
> early, release often" and makes debdiffs far harder to read).

It sounds like I should maybe just forget about -2 and upload -3.  I had
one more thing I wanted to do for it but it's a big task, rather
involved, and not required.

-- 
Regards,
Branden
xtrs (4.9d-3~~unreleased) experimental; urgency=medium

  * mkdisk.c: Fix buffer overflow when given filename >8 characters.  Truncate
filename by default when copying to hard disk image.  Add -S ("spill")
flag to partially simulate old behavior.  Exit with error if filename
argument would overflow even the subsequent structure member historically
used by xtrs to store extra filename characters.
+ mkdisk.man: Document -S flag and related issues.
+ test-mkdisk.sh: Add tests for overflow and new filename truncation and
  spillage logic.
+ Makefile: Add "check" target to run the foregoing test.  Nothing
  upstream calls this target automatically.
  * mkdisk.c: Check return value of fopen() when creating DMK disk image file.
  * mkdisk.c: Refuse to clobber files by default.  Add -f ("force") flag to
override this behavior.
+ mkdisk.man: Document new behavior and -f flag.
+ test-mkdisk.sh: Test default no-clobber and -f flag behavior.
  * mkdisk.c: Document the -d option for hard disk images in usage message.
  * Makefile: Observe LDFLAGS when building internal "compile_rom" tool.
Thanks to Graham Inggs for the discussion!  (Closes: #859751)
  * Port to C11 and build with -std=c11.

 -- G. Branden Robinson <g.branden.robin...@gmail.com>  Sun, 09 Apr 2017 
15:34:01 -0400

xtrs (4.9d-2) experimental; urgency=medium

  * Export Debian build flags to environment.  Executables are now hardened
per < https://wiki.debian.org/Hardening >.
  * Add Turkish debconf template translations; thanks, Mert Dirik!
(Closes: #757864)
  * Add Dutch debconf template translations; thanks, Frans Spiesschaert!
(Closes: #767488)
  * Add Indonesian debconf template translations; thanks, Izharul Haq!
(Closes: #835622)

 -- G. Branden Robinson <g.branden.robin...@gmail.com>  Sun, 26 Mar 2017 
22:17:39 -0400

xtrs (4.9d-1) experimental; urgency=medium

  * Merge new upstream release.
+ "Deleted all SIGIO code.  The code was a kludge to begin with and it no
  longer worked with current X libraries and Linux kernels, causing xtrs
  to hang.  It was also reported to cause hangs when xtrs was compiled for
  Windows using Cygwin.  Thanks to Howard Pepper, Dennis Lovelady, Arumin
  Nueckel, Christopher Currie, and Joe Peterson for bug reports."
  (Closes: #511645)
  * Update README.Debian to refresh URLs and reflect developments in the
TRS-80 retrocomputing enthusiast community over the past several years.
  * Implement debian/compare-copyright script.
+ Add "check-source" target to debian/rules to call the script.
+ Add debian/{no-,}copyright-info.expected files.
  * Migrate former contents of debian/checklist to debian/README.source.
  * Rewrite debian/copyright using machine-readable copyright info.
  * Migrate to new (to me) quilt-based Debian source format 3.0.
+ Migrate former contents of debian/patches to debian/patch/*; dropping
  patches now merged upstream.
  * Migrate former contents of debian/README.contrib-only to Disclaimer field
of debian/copyright, and update discussion.
  * Stop shipping Tim Mann's TRS-80 FAQ document.  It's great, but strictly
s

Bug#859778: RFS: xtrs/4.9d-2

[G. Branden Robinson]

I think I got it fixed.

The URL of my package is:
https://mentors.debian.net/package/xtrs

The respective dsc file can be found at:
https://mentors.debian.net/debian/pool/contrib/x/xtrs/xtrs_4.9d-2.dsc

##lftp mentors.debian.net:/debian/pool/contrib/x/xtrs> ls
drwxr-xr-x  --  ..
-rw-r--r-- 433K  2017-04-01 02:48  xtrs_4.9c.orig.tar.gz
-rw-r--r--  30K  2017-04-12 16:19  xtrs_4.9d-2.debian.tar.xz
-rw-r--r-- 1.8K  2017-04-12 16:19  xtrs_4.9d-2.dsc
-rw-r--r-- 434K  2017-04-12 16:19  xtrs_4.9d.orig.tar.gz

At 2017-04-12T17:39:54+0200, Adam Borowski wrote:
> On Wed, Apr 12, 2017 at 10:20:55AM -0400, G. Branden Robinson wrote:
> > Hrm #1: GMail helpfully categorized your mail as spam.
> 
> Not nice, let's try again; if you don't respond in a day I'll send
> from some other place.

It's fixed.  I told GMail you're not a spammer.  :)

-- 
Regards,
Branden


signature.asc
Description: PGP signature

Bug#858579: /usr/share/man/man5/deb-changelog.5.gz: please support a comment syntax for Debian changelog files

[G. Branden Robinson]

At 2017-04-09T03:57:01+0200, Guillem Jover wrote:
> Hi!
> 
> On Sat, 2017-03-25 at 19:27:55 -0400, G. Branden Robinson wrote:
> > On Sat, Mar 25, 2017 at 03:07:32PM +0100, Guillem Jover wrote:
> > > The implementation in dpkg-dev already supports all of this
> > > (see man Dpkg::Changelog::Debian), including:
> > 
> > Section 3 manpages for Perl modules?  Will wonders never cease?  ;-)
> 
> I'm not sure if the wonder is becuse there's documentation at all for
> those, or because secion is 3 instead of say 3perl. In any case, this
> prompted me to check and fix the latter, so I've queued a patch for
> 1.19.x. :)

The former.  You'll never see a C library interface manpage with
double-colons in the name, and C++ programmers never write manpages
because their programming language is completely intuitive. >cough<

> Ok, what about the attached patch, which I've queued for 1.19.x? I'm
> not documenting the ancient formats, because I feel that might induce
> people to use them, while this should be IMO pretty much just an
> implementation detail.

It looks good to me.  I see no actual problems; I will make a few
observations that boil down to style, preference, and/or judgement.

1.  The abbreviation "i.e." should always be followed by a comma.  See,
e.g., man-pages(7).
2.  I prefer to use "an" (man) macros for font changes, as they
integrate better with lexical highlighters and spell checkers, and
hide some grotty[1] syntax from those reading or writing the manpage
source.  Most such people do not bother to learn what *roff syntax
really is, and I can't blame them.  This does mean adding linebreaks
in the manpage sources, but filled paragraphs in *roff sources are
usually a bug, not a feature.[2] *roff is not Markdown, and
definitely not plaintext.  There's only one place that you can't
escape using font escapes, and that's if you need three different
fonts in the tag of a tagged paragraph (.TP)[3].

So instead of \fB#\fP, you can have
.B #
and similarly
.B /* */

3.  Vim and Emacs should be capitalized when referred to in prose as
editing systems, rather than by their command-line invocation names.
4.  "CVS keywords" are more properly referred to as "RCS keywords", or
maybe even "ident(1) strings".  RCS is the system that introduced
them[4].  CVS and Subversion followed the syntax.  ident(1) is also
somewhat likely to be installed on the user's system, so a broader
audience will have ready access to the manpage to learn more about
what they are.  See the rcs package description (last paragraph).

I know that's a lot of nitpicking. :-O

Regards,
Branden

[1] pun intended
[2] See man-pages(7), "Conventions for source file layout" and groff(7),
"Control Characters", ".".
[3] This annoys me so much that I'm trying to learn enough *roff to
write a fix or a replacement macro that people can use instead, that
we may banish the use of font escapes in manpages forever. :-|
[4] SCCS had keywords, but they were more primitive than RCS's and
infeasible to pattern-match once expanded; see <

https://docs.oracle.com/cd/E19504-01/802-5880/6i9k05dht/index.html#sccs-15316
>.


signature.asc
Description: PGP signature

Bug#858573: maint-guide: should be updated for stretch, and note that it has been

[G. Branden Robinson]

At 2017-04-07T00:44:18+0900, Osamu Aoki wrote:
> Hi,
> 
> On Thu, Mar 23, 2017 at 04:45:35PM -0400, Branden Robinson wrote:
> > Package: maint-guide
> > Version: 1.2.38
> > Severity: normal
> > 
> > Chapter 1 notes that "This document has been updated for the Debian
> > jessie release."
> > 
> > I suggest that the document be updated for the stretch release and note
> > this fact, since stretch is about to release.
> 
> Very true but things aren't so simple.  There have been some updates bit
> ...
> 
> This document was originally written before "dh $@#" was used.  I
> updated for that (debhelper 7 days).
> 
> Since then several additional text was added to address multi-arch etc.
> 
> With several DEP and multi-arch ... updating this document became
> difficult partly because dh_make used in the example did not address
> M-A.
> 
> Also writing long English text for all these details became too much for
> me ...

I understand.  It sounds like you could use some help.  Have you
considered opening a wnpp bug and tagging maint-guide RFH (request for
help)?

> So I wrote a debmake package and rewrote the tutorial text as
> debmake-doc.  It is in archive now for stretch...

Excellent--thank you!

Regards,
Branden


signature.asc
Description: PGP signature

Bug#859778: RFS: xtrs/4.9d-2

[G. Branden Robinson]

At 2017-04-07T15:23:19+0200, Adam Borowski wrote:
> On Fri, Apr 07, 2017 at 07:41:51AM -0400, G. Branden Robinson wrote:
> > * Package name: xtrs
> >   Version : 4.9d-2
> 
> > https://mentors.debian.net/package/xtrs
> > dget -x 
> > https://mentors.debian.net/debian/pool/contrib/x/xtrs/xtrs_4.9d-2.dsc
> 
> I'm afraid these URLs are 404-compliant.  Am I missing something?

Hrm #1: GMail helpfully categorized your mail as spam.

Hrm #2: Apparently I forgot the correct sponsorship-request procedure.

$ dput mentors xtrs_4.9d-2_amd64.changes
Package has already been uploaded to mentors on mentors.debian.net
Nothing more to do for xtrs_4.9d-2_amd64.changes

lftp mentors.debian.net and then "ls" returns no results.

How do I find my upload after I've uploaded it?

Regards,
Branden


signature.asc
Description: PGP signature

Bug#859929: x11-common: unowned files after upgrade from jessie to stretch and purge: /etc/X11/Xwrapper.config

[G. Branden Robinson]

At 2017-04-09T13:34:44+0200, Andreas Beckmann wrote:
> 1m37.2s INFO: Warning: Package purging left files on system:
>   /etc/X11/Xwrapper.config not owned

It appears the old Xwrapper was killed off at some point.

The patch should be trivial enough that I can do it.  This would also
serve as an exercise of branden-guest's permissions on alioth.

Any objection?

Regards,
Branden


signature.asc
Description: PGP signature

Bug#859751: xtrs: please pass buildflags

[G. Branden Robinson]

At 2017-04-07T20:08:05+0200, Graham Inggs wrote:
> On 7 April 2017 at 19:06, G. Branden Robinson
> <g.branden.robin...@gmail.com> wrote:
> > All of this hardening stuff, as I understand it, involves mitigation
> > strategies for unsafe memory usage in the C language family in the ELF
> > object file format.
> 
> It's not only hardening stuff, it's whatever flags someone building
> the package locally would like, e.g.
> one could 'export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed' from
> debian/rules and expect everything to be linked with that option.

Ah, okay.  That melts my objections away like butter.

It looks like no great effort is required to address this; the problem
is that the compile_rom target in the Makefile is the only one that
invokes $(CC) without passing $(LDFLAGS).  With your argument above I
can even justify recommending this change to upstream.

Thanks for the discussion!

Regards,
Branden

Bug#859751: xtrs: please pass buildflags

[G. Branden Robinson]

At 2017-04-07T14:10:06+0200, Graham Inggs wrote:
> On 07/04/2017 13:12, G. Branden Robinson wrote:
> > compile_rom is an utility internal to the build.  It's not shipped and
> > thus not subject to attacks.  I'm considering adding an --ignore-line
> > for it, but I need to figure out how to embed this information in the
> > package itself so the buildd log scanner knows to use this flag itself.
> 
> Is there any harm in linking compile_rom with those flags?

Probably not, but what's the use case?

This compile_rom utility is only useful for, and only used to, embed
Z-80 instructions into the memory map of an emulated TRS-80 computer;
specifically _this_ emulator, xtrs.

All of this hardening stuff, as I understand it, involves mitigation
strategies for unsafe memory usage in the C language family in the ELF
object file format.

Again, the tool is not shipped.  I am having trouble thinking of any
attack vector involving compile_rom that isn't dwarfed by the fact that
it would have to be expoited during a package build, at which time there
are much simpler and nastier ways to attack a host, such as by embedding
hostile code into a maintainer script.  Those kinds of exploits are much
easier to write and we don't really screen for them.  Just the other I
saw on #debian-devel that we had a package that goofed up an rm -rf
command in its postinst and trashed /usr/bin or something like that.

My preference is to be fastidious about things, but I also have a strong
antipathy towards cargo-cult software engineering.  I cannot think of
any benefit of hardening compile_rom that is not extremely speculative.

Can you?

> > Please advise if you think the attachments don't address the issue.
> 
> All looks good, thanks!  I see the 'format not a string literal and no
> format arguments' errors are already fixed in upstream 4.9d.

Yes, and in the forthcoming -3 I fixed a bunch more that were exposed
when I compiled with -std=c11.

See attached patch.

Regards,
Branden
Align build with the ISO C11 standard.

-- Branden Robinson, 2017-04-04T09:40:13-0400
--- a/debug.c
+++ b/debug.c
@@ -18,6 +18,8 @@
$Id: debug.c,v 1.28 2009/06/16 00:10:39 mann Exp $
 */
 
+#define _POSIX_C_SOURCE 200112L /* signal.h: sigemptyset(), ... */
+
 #include "z80.h"
 #include "trs.h"
 
@@ -25,6 +27,7 @@
 #include 
 #include 
 #include 
+#include  /* strcasecmp() */
 
 #ifdef READLINE
 #include 
@@ -318,7 +321,7 @@
 int i;
 
 traps = (Uchar *) malloc(ADDRESS_SPACE * sizeof(Uchar));
-bzero(traps, ADDRESS_SPACE * sizeof(Uchar));
+memset(traps, 0, ADDRESS_SPACE * sizeof(Uchar));
 
 for(i = 0; i < MAX_TRAPS; ++i) trap_table[i].valid = 0;
 
--- a/cmddump.c
+++ b/cmddump.c
@@ -27,6 +27,9 @@
  *-p foo  select PDS entry "foo" (padded to 8 bytes with spaces)
  *-x  ignore anything after the first xfer address
  */
+
+#define _XOPEN_SOURCE /* unistd.h: getopt(), optarg, optind, opterr */
+
 #include 
 #include 
 #include 
--- a/mkdisk.c
+++ b/mkdisk.c
@@ -15,6 +15,8 @@
 /* If available, use C11 fopen()'s exclusive open flag.  Option -f overrides. */
 #define _ISOC11_SOURCE 1
 
+#define _XOPEN_SOURCE 500 /* unistd.h: getopt(), ...; sys/stat.h: fchmod() */
+
 #include 
 #include 
 #include 
--- a/trs_cassette.c
+++ b/trs_cassette.c
@@ -50,6 +50,9 @@
  *   Fabio Ferrari contributed the SB_SOUND implementation.  
  */
 
+#define _POSIX_C_SOURCE 200112L /* signal.h: sigemptyset(), ...
+   stdio.h: fileno() */
+
 #if __linux
 #define HAVE_OSS 1
 #define OSS_SOUND 1
--- a/trs_disk.c
+++ b/trs_disk.c
@@ -26,6 +26,8 @@
 #define SIZERETRY 1   /* Retry in different sizes on real_read */
 #define DMK_MARK_IAM 0/* Mark IAMs in track header; poor idea */
 
+#define _XOPEN_SOURCE 500 /* signal.h: SA_RESTART */
+
 #include "z80.h"
 #include "trs.h"
 #include "trs_disk.h"
--- a/trs_imp_exp.c
+++ b/trs_imp_exp.c
@@ -13,6 +13,8 @@
  *  easier.  
  */
 
+#define _XOPEN_SOURCE 500 /* ftruncate(), strdup() */
+
 #include 
 #include 
 #include 
--- a/trs_interrupt.c
+++ b/trs_interrupt.c
@@ -10,6 +10,8 @@
  * Emulate interrupts
  */
 
+#define _XOPEN_SOURCE 500 /* signal.h: SA_RESTART */
+
 #include "z80.h"
 #include "trs.h"
 #include 
--- a/trs_uart.c
+++ b/trs_uart.c
@@ -10,6 +10,8 @@
  * Emulation of the Radio Shack TRS-80 Model I/III/4/4P serial port.
  */
 
+#define _POSIX_C_SOURCE 200112L /* signal.h: sigemptyset(), ... */
+
 #include 
 #include 
 #include 
--- a/trs_xinterface.c
+++ b/trs_xinterface.c
@@ -28,6 +28,9 @@
  * X Windows interface for TRS-80 simulator
  */
 
+#define _DEFAULT_SOURCE /* string.h: strcasecmp() */
+#define _XOPEN_SOURCE 500 /* string.h: strdup() */
+
 #include 
 #include 
 #include 
--- a/Makefile
+++ b/Makefile
@@ -149,7 +149,7 @@
 include Makefile.local
 
 CFLAGS += $(DEBUG) $(ENDIAN) $(DEFAULT_ROM) $(READLINE) $(DISKDIR) $(IFLAGS) \

Bug#858304: vim-runtime: markdown syntax highlighting (and possibly others) goes crazy and drives the terminal crazy

[G. Branden Robinson]

At 2017-04-07T12:08:58-0400, James McCoy wrote:
> On Fri, Apr 07, 2017 at 07:23:39AM -0400, G. Branden Robinson wrote:
> > However, my xterms are somewhat customized.  I'm attaching my
> > .Xresources file.
> 
> Perfect! That seems to be the difference.  I, and presumably Francesco, aren't
> using TTF fonts.  If I change your Xresources to use
> 
> XTerm.*.VT100.Font: 
> -misc-fixed-medium-r-normal--18-120-100-100-c-90-iso10646-1
> 
> instead of the FaceName/FaceSize resources, then playing the recording
> reproduces the problem.

I agree that we're narrowing it down.  I commented out my *.face*
resources, xrdb -merged .Xresources, ran xterms from other xterms, and
got some intriguing stuff on stderr.

$ xterm
xterm: cannot load font '-Misc-Fixed-Bold-o-*-*-13-120-75-75-C-60-ISO10646-1'
$ xterm -fn '-misc-fixed-medium-r-normal--18-120-100-100-c-90-iso10646-1'
xterm: cannot load font 
'-Misc-Fixed-Medium-o-*-*-18-120-100-100-C-90-ISO10646-1'
xterm: cannot load font '-Misc-Fixed-Bold-o-*-*-18-120-100-100-C-90-ISO10646-1'
xterm: cannot load font 
'-Misc-Fixed-Medium-o-*-*-18-120-100-100-C-180-ISO10646-1'
xterm: cannot load font 
'-Misc-Fixed-Medium-o-*-*-18-120-100-100-C-180-ISO10646-1'

To me, this implicates something at or near the bold font emulation
stuff that xterm does.  This may be enough for Thomas Dickey to locate
the bug.

There's some pretty complicated logic involved; from xterm(1):

alwaysBoldMode (class AlwaysBoldMode)
   Specifies whether xterm should check if the normal and bold
   fonts are distinct before deciding whether to use overstriking
   to simulate bold fonts.  If this resource is true, xterm does
   not make the check for distinct fonts when deciding how to
   handle the boldMode resource.  The default is "false".

   boldMode   alwaysBoldMode   Comparison   Action
   
   false  falseignored  use font
   false  true ignored  use font
   true   falsesame overstrike
   true   falsedifferentuse font
   true   true ignored  overstrike

   This resource is used only for bitmap fonts:

   ·   When using bitmap fonts, it is possible that the font
   server will approximate the bold font by rescaling it from
   a different font size than expected.  The alwaysBoldMode
   resource allows the user to override the (sometimes poor)
   resulting bold font with overstriking (which is at least
   consistent).

   ·   The problem does not occur with TrueType fonts (though
   there can be other unnecessary issues such as different
   coverage of the normal and bold fonts).

   As an alternative, setting the allowBoldFonts resource to false
   overrides both the alwaysBoldMode and the boldMode resources.

Regards,
Branden


signature.asc
Description: PGP signature

Bug#859778: RFS: xtrs/4.9d-2

[G. Branden Robinson]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I seek a sponsor for my package "xtrs".

* Package name: xtrs
  Version : 4.9d-2
  Upstream Author : Tim Mann
* URL : http://www.tim-mann.org/xtrs.html
* License : 2 different custom permissive licenses
  Section : otherosfs

It builds these binary packages:

xtrs  - emulator for TRS-80 Model I/III/4/4P computers

To access further information about this package, please visit the
following URL:

https://mentors.debian.net/package/xtrs

Alternatively, one can download the package with dget using this
command:

dget -x 
https://mentors.debian.net/debian/pool/contrib/x/xtrs/xtrs_4.9d-2.dsc

Changes since the last upload:

  * Export Debian build flags to environment.  Executables are now hardened
per < https://wiki.debian.org/Hardening >.
  * Add Turkish debconf template translations; thanks, Mert Dirik!
(Closes: #757864)
  * Add Dutch debconf template translations; thanks, Frans Spiesschaert!
(Closes: #767488)
  * Add Indonesian debconf template translations; thanks, Izharul Haq!
(Closes: #835622)

Regards,
Branden

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

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

Bug#858304: vim-runtime: markdown syntax highlighting (and possibly others) goes crazy and drives the terminal crazy

[G. Branden Robinson]

At 2017-04-06T21:56:13-0400, James McCoy wrote:
> On Fri, Apr 07, 2017 at 12:54:19AM +0200, Francesco Poli wrote:
> > On Thu, 6 Apr 2017 15:06:17 -0400 G. Branden Robinson wrote:
> > 
> > > At 2017-04-06T13:33:58-0400, James McCoy wrote:
> > > > On Thu, Apr 06, 2017 at 01:17:55PM -0400, G. Branden Robinson wrote:
> > > > > The below is not a sufficient reproduction receipe for me.
> > > > > 
> > > > > I'm running Debian Stretch (testing).
> > > > > 
> > > > > Things do not go wrong at step #5, nor afterward.
> > > > 
> > > > Make sure the terminal is sized small enough (80x24).  That causes the
> > > > syntax highlighting in Vim to get a little confused and enable some bold
> > > > highlighting, which then causes the visual bell to turn everything bold.
> > > 
> > > It was.
> > 
> > Hello Branden!
> > Thanks for trying to reproduce the bug.
> > 
> > Does it help to know that I have:
> > 
> >   xset b off
> > 
> > in my ~/.xsession script?
> 
> I don't think that's relevant.  My bell is on.  I was also able to
> reproduce it without causing the bell.
> 
> I've attached an asciinema recording of me reproducing the problem.
> When I replay the recording, it causes the same problem to the xterm in
> which it is running, so hopefully this helps debug the problem.

That's really interesing.  I _still_ can't repro this, even playing back
James's demo with asciinema--a tool of which I wasn't aware, thanks!

I'm launching xterm in GNOME with the GNOME command runner, whatever
that's called--the Alt+F2 thing.

However, my xterms are somewhat customized.  I'm attaching my
.Xresources file.

Regards,
Branden
XTerm.PtyInitialErase: true
XTerm.TermName: xterm-256color
XTerm.ToolBar: false
! From xterm(1):
!
! If your xterm is configured to support the “toolbar”, then those patterns need
! an extra level for the form-widget which holds the toolbar and vt100 widget.
! A wildcard between the top-level “XTerm” and the “vt100” widget makes the
! resource settings work for either, e.g., “XTerm*vt100.NAME”.
XTerm.*.VT100.Background: gray10
XTerm.*.VT100.FaceName: FreeMono
! Set FaceSize big, but small enough for 165x50 text on a 1898x1143 root window.
! 14 would work, but underscores (_) do not render at all in FreeMono on Debian
! Stretch. (See < http://bugs.debian.org/858142 >).
! XXX: You can''t have unpaired apostrophes in X resource comment lines?  When
! did that happen?
XTerm.*.VT100.FaceSize: 13
XTerm.*.VT100.Foreground: gray90
XTerm.*.VT100.VisualBell: true
! Keep left Alt working as a Meta key, while letting right Alt work as an
! AltGr key under the following X configuration:
! xkb_keymap {
!   xkb_keycodes  { include "evdev+aliases(qwerty)" };
!   xkb_types { include "complete"  };
!   xkb_compat{ include "complete"  };
!   xkb_symbols   { include 
"pc+us(altgr-intl)+us:2+us:3+inet(evdev)+level3(ralt_switch)+compose(caps)+terminate(ctrl_alt_bksp)"
};
!   xkb_geometry  { include "hhk(basic)"};
! };
XTerm.*.VT100.MetaSendsEscape: true
! vim:set ai et sw=4 ts=4 tw=80:


signature.asc
Description: PGP signature

Bug#859751: xtrs: please pass buildflags

[G. Branden Robinson]

package xtrs
tag 859751 + pending
thanks

At 2017-04-06T22:01:05+0200, Graham Inggs wrote:
> Source: xtrs
> Version: 4.9c-4
> Severity: wishlist
> Tags: patch
> 
> Hi Maintainer
> 
> Welcome back!

Thanks!

> According to the buildd log scanner [1],
> 
> Issues found in current buildd logs for xtrs:
> 
> W dpkg-buildflags-missing CPPFLAGS 27 (of 27), CFLAGS 27 (of 27),
> LDFLAGS 5 (of 5) missing (amd64, arm64, armel, armhf, i386, mips,
> mips64el, mipsel, powerpc, ppc64el, s390x)
> 
> You can check this locally with the 'blhc' tool.  After passing
> CPPFLAGS, CFLAGS and LDFLAGS, as per the attached patch, the following
> errors appeared:
> 
> debug.c:518:10: error: format not a string literal and no format
> arguments [-Werror=format-security]
>printf(help_message);
>   ^~~~
> 
> dis.c: In function ‘disassemble’:
> dis.c:2118:2: error: format not a string literal and no format
> arguments [-Werror=format-security]
>   printf (code->name);
>   ^~
> 
> These are also fixed in the patch.

Hi Graham.  I already have these fixed in the 4.9d branch of the
package; my upload sponsor advised me that including these (and other)
changes violated the minimality constraints of the release freeze.

I'm arranging sponsorship for an upload of 4.9d-2 right now, but you can
preview the changes via the attachments.  I see only one remaining
issue:

$ blhc xtrs_4.9d-2_amd64.build
LDFLAGS missing (-Wl,-z,relro -Wl,-z,now): cc -o compile_rom
compile_rom.o error.o load_cmd.o load_hex.o

compile_rom is an utility internal to the build.  It's not shipped and
thus not subject to attacks.  I'm considering adding an --ignore-line
for it, but I need to figure out how to embed this information in the
package itself so the buildd log scanner knows to use this flag itself.

Please advise if you think the attachments don't address the issue.

Regards,
Branden


xtrs_4.9d-2.debian.tar.xz
Description: application/xz
Format: 3.0 (quilt)
Source: xtrs
Binary: xtrs
Architecture: any
Version: 4.9d-2
Maintainer: G. Branden Robinson <g.branden.robin...@gmail.com>
Homepage: http://www.tim-mann.org/xtrs.html
Standards-Version: 3.9.8
Build-Depends: debhelper (>= 9), libncurses5-dev, libreadline-dev, libx11-dev, 
groff-base, bsdmainutils, po-debconf, html2text
Package-List:
 xtrs deb contrib/otherosfs extra arch=any
Checksums-Sha1:
 42b1fc90246901456d29071421e838b545f39f0f 99 xtrs_4.9d.orig.tar.gz
 e1a1ed4692d5cef24466980de5c2bce64fad905d 30912 xtrs_4.9d-2.debian.tar.xz
Checksums-Sha256:
 3985f2331e76198dfc027bc2afcd09a158d2bcad0348aeb4a4958a8fb99cf5c4 99 
xtrs_4.9d.orig.tar.gz
 5466f8a110a0c6f7fc30017fb5bf36586195cffe0dc478b7cff315ec24dc32ad 30912 
xtrs_4.9d-2.debian.tar.xz
Files:
 93868bed769c038bfae907375316bb2d 99 xtrs_4.9d.orig.tar.gz
 0ebf4eb05f566ec11cbce22ce3b5669d 30912 xtrs_4.9d-2.debian.tar.xz


signature.asc
Description: PGP signature

Bug#858304: vim-runtime: markdown syntax highlighting (and possibly others) goes crazy and drives the terminal crazy

[G. Branden Robinson]

At 2017-04-06T13:33:58-0400, James McCoy wrote:
> On Thu, Apr 06, 2017 at 01:17:55PM -0400, G. Branden Robinson wrote:
> > The below is not a sufficient reproduction receipe for me.
> > 
> > I'm running Debian Stretch (testing).
> > 
> > Things do not go wrong at step #5, nor afterward.
> 
> Make sure the terminal is sized small enough (80x24).  That causes the
> syntax highlighting in Vim to get a little confused and enable some bold
> highlighting, which then causes the visual bell to turn everything bold.

It was.  Would it help for me to record a short video and add it to the
bug?

Regards,
Branden


signature.asc
Description: PGP signature

Bug#858304: vim-runtime: markdown syntax highlighting (and possibly others) goes crazy and drives the terminal crazy

[G. Branden Robinson]

The below is not a sufficient reproduction receipe for me.

I'm running Debian Stretch (testing).

Things do not go wrong at step #5, nor afterward.

At 2017-04-05T22:03:50-0400, James McCoy wrote:
> On Mon, Mar 20, 2017 at 10:29:20PM +0100, Francesco Poli (wintermute) wrote:
> > I finally found a reliable way to reproduce it.
> > 
> > Steps to reproduce:
> > 
> >   0) open the attached test.md file:
> > 
> >  $ vim -u NONE test.md
> > 
> >   1) enable syntax highlighting:
> > 
> >  :set bg=dark
> >  :syn on
> > 
> >   2) go to the end of the file:
> > 
> >  [Shift+G]
> > 
> >   3) go back to the beginning of the file (line by line):
> > 
> >  [k].[k] ← hold the key pressed until you reach the first line
> > 
> >   4) visualize file info on the status line:
> > 
> >  [Ctrl+G]
> > 
> >   5) the syntax highlighting has gone crazy (even the status line is
> >  in boldface!): see the attached screenshot
> >  wrong_vim_syntaxmarkdown.png
> > 
> >   6) exit from vim:
> > 
> >  :q
> > 
> >   7) the terminal (xterm), or rather the shell (bash), has also gone
> >  crazy (it now prints everything in boldface by default): see
> >  the attached screenshot
> >  wrong_vim_syntaxmarkdown2.png
> > 
> >   8) the terminal won't come back to normal behavior until I quit it;
> >  another trick to regain the normal behavior of the terminal is
> >  opening test.md again, enable syntax highlighting, and exit vim
> >  (steps 0, 1, and 6 above)

Regards,
Branden


signature.asc
Description: PGP signature

Bug#859686: recordmydesktop: man page is really ugly

[G. Branden Robinson]

Package: recordmydesktop
Version: 0.3.8.1+svn602-1+b2
Severity: normal

Whoever wrote recordmydesktop's manual page did not have a good grasp of
*roff markup or the effects of the macros.

I've corrected many problems without rewriting it per se.

1. I brought the manual page into line with the guidance and
   recommendations found in man-pages(7), groff_man(7), groff(7), and
   man(7).
2. I added some information about defaults based on review of the source
   code.
3. I made many English language style corrections and tweaks.

Please find attached:

A. A diff of the stock manpage and my revised one;
B. The full text of my revised one;
C. A PDF of the stock manpage;
D. A PDF of (B).

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages recordmydesktop depends on:
ii  libasound21.1.3-5
ii  libc6 2.24-9
ii  libice6   2:1.0.9-2
ii  libjack-jackd2-0 [libjack-0.125]  1.9.10+20150825git1ed50c92~dfsg-5
ii  libogg0   1.3.2-1
ii  libpopt0  1.16-10+b2
ii  libsm62:1.2.2-1+b3
ii  libtheora01.1.1+dfsg.1-14+b1
ii  libvorbis0a   1.3.5-4
ii  libvorbisenc2 1.3.5-4
ii  libvorbisfile31.3.5-4
ii  libx11-6  2:1.6.4-3
ii  libxdamage1   1:1.1.4-2+b3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  zlib1g1:1.2.8.dfsg-5

recordmydesktop recommends no packages.

recordmydesktop suggests no packages.

-- no debconf information
--- recordmydesktop.1.orig  2017-04-05 08:59:29.438685068 -0400
+++ recordmydesktop.1   2017-04-05 17:50:33.441926686 -0400
@@ -1,567 +1,643 @@
-.TH "RECORDMYDESKTOP" 1 "13/7/2006" "Linux"
-
-
-.SH NAME
-recordMyDesktop \- record desktop sessions to an Ogg\-Theora\-Vorbis file.
-
-
-.SH SYNOPSIS
-
-.Brecordmydesktop
-[
-.B
-Options
-]^
-.B
-filename
-.br
-.br
-.SH DESCRIPTION
-.PP
-recordMyDesktop produces a file(default out.ogv) that contains a video 
and audio recording
-.br
-of a linux desktop session. The default behavior of recording is to mark areas 
that have changed(through libxdamage)
-.br
-and update the frame. This behavior can be changed (option
-.B
-\-\-full\-shots
-) to produce a more accurate result
-.br
-or capture windows that do not generate events on change(windows with 
accelerated 3d context)
-.br
-but this will notably increase the workload.
-.br
-recordMyDesktop doesn't have a commandline interface.
-.br
-After startup, it can be controled only through the following signals:
-.br
-.br
-.B
-SIGUSR1
-causes the program to pause if it's currently recording, and vice-versa.
-.br
-.B
-SIGTERM
-causes normal termination of the recording.
-.br
-.B
-SIGINT
-also causes normal termination.
-.br
-.B
-SIGABRT
-terminates the program and removes the specified output file.
-.br
-.br
-This signals can also be delivered on the application, with the use of 
-shortcuts.
-.br
-See 
-.B
-\-\-pause\-shortcut
+.TH recordMyDesktop 1 2017-04-05
+.SH Name
+recordMyDesktop \- record desktop sessions to an Ogg Theora video file with \
+Vorbis audio
+.SH Synopsis
+.B recordmydesktop
+.PP
+.B recordmydesktop
+.I output-filename
+.PP
+.B recordmydesktop \-\-rescue
+.I path-to-data
+.PP
+.B recordmydesktop
+.RI { image-options | sound-options | encoding-options | miscellaneous-options 
\
+"| ... }
+.PP
+.B recordmydesktop
+.RB { \-h | \-\-help }
+.PP
+.B recordmydesktop \-\-version
+.PP
+.B recordmydesktop \-\-print\-config
+.SH Description
+.B recordMyDesktop
+produces a file
+.RI ( out.ogv
+by default) containing a video and audio recording of an X Window System
+session.
+.PP
+For a typical scenario, recording your session is as simple as
+.RS
+$
+.B recordmydesktop
+.RE
+which will produce a full-screen recording named
+.I out.ogv
+in the current working directory, while the command
+.RS
+$
+.B recordmydesktop ../foo
+.RE
+will save the recording in
+.I foo.ogv
+in the parent of the current working directory.
+.PP
+To end a recording, press
+.BR Control+C .
+(This action sends a
+.B SIGINT
+to
+.BR recordMyDesktop .)
+.PP
+To designate a region of the screen for recording you can type this:
+.RS
+$
+.B recordmydesktop \-x
+.I x-pos
+.B \-y
+.I y-pos
+.B \-\-width
+.I w
+.B \-\-height
+.I h
+.B \-o foo.ogv
+.RE
+where
+.I x-pos
 and
-.B
-\-\-stop\-shortcut
-, on the 
-.B
-Misc.
-section
-of 
-.B
-Options
-bellow.
-.br
- 
-.br
- 
-.br
- 
-A typical scenario of recording can be a command as simple as:
-.br
-.B
-~$ recordmydesktop
-.br
-which will produce a fullscreen 

Bug#859495: /usr/share/man/man1/display-im6.q16.1.gz: manpage says to install wrong package for HTML docs

[G. Branden Robinson]

Package: imagemagick-6.q16
Version: 8:6.9.7.4+dfsg-2
Severity: normal
File: /usr/share/man/man1/display-im6.q16.1.gz

"man display" says:

   For more information about the display command, point your  browser  to
   file:///usr/share/doc/imagemagick-6-common/html/www/display.html(on
   debian  system  you  may  install   the   imagemagick-6   package)   or
   http://www.imagemagick.org/script/display.php.

But that's wrong.

$ dpkg -S /usr/share/doc/imagemagick-6-common/html/www/display.html
imagemagick-6-doc: /usr/share/doc/imagemagick-6-common/html/www/display.html

The same problem seems to exist for all the manpages, probably due to 
templating:

$ man animate compare composite conjure convert display identify \
 import mogrify montage stream

-- Package-specific info:
ImageMagick program version
---
animate:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
compare:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
convert:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
composite:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
conjure:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
display:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
identify:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
import:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
mogrify:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
montage:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
stream:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages imagemagick-6.q16 depends on:
ii  hicolor-icon-theme 0.15-1
ii  libc6  2.24-9
ii  libmagickcore-6.q16-3  8:6.9.7.4+dfsg-2
ii  libmagickwand-6.q16-3  8:6.9.7.4+dfsg-2

Versions of packages imagemagick-6.q16 recommends:
ii  ghostscript  9.20~dfsg-3
ii  libmagickcore-6.q16-3-extra  8:6.9.7.4+dfsg-2
ii  netpbm   2:10.0-15.3+b2

Versions of packages imagemagick-6.q16 suggests:
pn  autotrace
ii  cups-bsd [lpr]   2.2.1-8
ii  curl 7.52.1-3
pn  enscript 
pn  ffmpeg   
ii  fig2dev [transfig]   1:3.2.6a-2
ii  gimp 2.8.18-1
pn  gnuplot  
pn  grads
pn  graphviz 
ii  groff-base   1.22.3-9
pn  hp2xx
pn  html2ps  
ii  imagemagick-6-doc [imagemagick-doc]  8:6.9.7.4+dfsg-2
ii  libwmf-bin   0.2.8.4-10.6
pn  mplayer  
pn  povray   
pn  radiance 
ii  sane-utils   1.0.25-3
ii  texlive-binaries [texlive-base-bin]  2016.20160513.41080.dfsg-2
ii  transfig 1:3.2.6a-2
pn  ufraw-batch  
ii  xdg-utils1.1.1-1

-- no debconf information