Re: New supply-chain security tool: backseat-signed

[G. Branden Robinson]

At 2024-04-11T15:37:46+0100, Colin Watson wrote:
> On Thu, Apr 11, 2024 at 10:26:55AM -0400, Theodore Ts'o wrote:
> > Or, because some upstream maintainers have learned through, long,
> > bitter experience that newer versions of autoconf tools may result
> > in the generated configure script to be busted (sometimmes subtly),
> > and so distrust relying on blind autoreconf always working.
> 
> When was the last time this actually happened to you?  I certainly
> remember it being a problem in the early 2.5x days, but it's been well
> over a decade since this actually bit me.

A darkly amusing story of this frustration can be found under "Why
patch?" at .

For my part, I have come to associate the name "Akim Demaille" with the
advisability of extreme caution when adopting a release of new software.

Possibly I should be making that association with someone else, though.

Regards,
Branden


signature.asc
Description: PGP signature

Re: Validating tarballs against git repositories

[G. Branden Robinson]

At 2024-03-31T22:32:49+, Stefano Rivera wrote:
> Upstreams would probably prefer that we used git repositories
> *directly* as source artifacts, but that comes with a whole other can
> of worms...

Speaking from my upstream groff perspective, I wouldn't _prefer_ that.

The distribution archives get build-testing on a much wider variety of
systems, thanks to people on the groff@ and platform-testers@gnu mailing
lists that help out when a release candidate is announced.  They have
access to platforms more exotic that I and a few other bleeding-edge
HEAD mavens do.  This practice tangibly improved the quality of the
groff 1.23.0 release, especially on surviving proprietary Unix systems.

Building from the repo, or using the bootstrap script--which Colin
Watson just today ensured will be in future distribution archives--is
fine.[1]  I'm glad some people build the project that way.  But I think
that procedure serves an audience that is distinguishable in some ways.

Regards,
Branden

[1] 
https://git.savannah.gnu.org/cgit/groff.git/commit/?id=822fef56e9ab7cbe69337b045f6f20e32e25f566


signature.asc
Description: PGP signature

Re: Is it allowed to remove attribution in public domain "licensed" source code? (and pondering about ftp-level reviews)

[G. Branden Robinson]

Hi Otto,

At 2024-03-30T14:09:46-0700, Otto Kekäläinen wrote:
> While reviewing xz-utils commits I noticed that a bunch of old
> copyright holder names were removed in
> https://salsa.debian.org/debian/xz-utils/-/commit/d1b67558cbc06c449a0ae7b7c1694e277aef4a78.
> 
> Is this OK to do so?

My opinion is that, _apart from copyright concerns_, an author's
attribution should be removed only if that author's contribution has
been completely removed from the file/work in question.  This is largely
a matter of professional integrity and of avoiding plagiarism.

https://invisible-island.net/personal/copywrongs.html

If someone has rewritten an author's contribution such that none of the
author's "original expression" (a manifestation of human creativity)
remains in the file/work, then it is okay to remove their attribution
and/or copyright notice, and is arguably misleading if you _don't_
remove it.

The untruthful placement or removal of a copyright notices can be a
criminal act in the U.S.[1], but I've never heard of a situation where
someone got into trouble for lazily retaining a notice that was once
applicable to a work, but no longer.  This statute _does_ require
"fraudulent intent", as an element of the crime, a prosecutor is
required to prove it beyond a reasonable doubt to the trier of
fact.[2][3]

Still, candor is a virtue, and, in principle, a false (or no longer
true) claim of copyright could cause problems for an author incorrectly
credited, in the event of some sort of criminal or civil liability
attaching to the work.  The xz backdoor and the mysterious identity of
its perpetrator(s) should underscore this concern.

> Having source code in the public domain means that there is no
> copyright, so no attribution required either?

That's true, but world governments have had great trouble saying "no" to
copyright rentiers for the past century or more, so it can be wise to
retain a public domain dedication notice with the author's name and the
year.

> But if copyright attribution is done, each name should have a year
> next to it at least, right?

Yes, because in theory, software will one day _age_ into the public
domain.  Perhaps infants born today will live to see it happen.

> Is it so that the debian/copyright file is reviewed by ftp-masters
> only for packages in NEW queue, and there is probably no automation in
> place to flag subsequent copyright changes for re-review?

That was my understanding 20 years ago; I can't competently speak to the
status quo.

Regards,
Branden

[1] 
https://www.justice.gov/archives/jm/criminal-resource-manual-1855-protection-copyright-notices-17-usc-506c-and-506d

[2] In practice, over-assertion of copyright would seem to be little
policed; it is common practice for book publishers in the U.S. to
assert flatly impossible copyright notices, asserting a date that
hasn't happened yet.  My anecdotal impression is that over the past
20 years, the month in which one can observe copyright notices dated
in the next calendar year has crept steadily backward.

[3] Of course, most criminal prosecutions in the United States never
proceed to the trial stage,[4] so if you're ever sitting across a
table from a U.S. Attorney, the gap between what is asserted and
what can be proved can be huge.

[4] 
https://www.pewresearch.org/short-reads/2023/06/14/fewer-than-1-of-defendants-in-federal-criminal-cases-were-acquitted-in-2022/


signature.asc
Description: PGP signature

Re: Validating tarballs against git repositories

[G. Branden Robinson]

At 2024-03-30T14:38:03+0200, Jonathan Carter wrote:
> On 2024/03/30 11:05, Simon Josefsson wrote:
> > > 1. Move towards allowing, and then favoring, git-tags over source tarballs
> >
> > Some people have suggested this before -- and I have considered
> > adopting that approach myself, but one thing that is often
> > overlooked is that building from git usually increase the
> > Build-Depends quite a lot compared to building from tarball
> 
> How in the world do you jump to that conclusion?

I don't know about "usually", but "often" seems fair enough; it's true
of groff.

https://git.savannah.gnu.org/cgit/groff.git/tree/INSTALL.REPO?h=1.23.0#n15

Regards,
Branden


signature.asc
Description: PGP signature

Re: Proper handling of Lintian warnings due to other packages

[G. Branden Robinson]

package libghc-pandoc-dev
tag 1053777 + fixed-upstream
thanks

Hi Jonas!

At 2024-01-31T08:43:18+0100, Jonas Smedegaard wrote:
> Quoting G. Branden Robinson (2024-01-31 05:49:00)
> > Well, the version of pandoc that resolved the issue was 3.1.7,
> > released in August 2023.[1]  But the version in Debian unstable is
> > still 3.1.3, and the package is team-maintained.[2]
> 
> This particular bug is tracked in Debian as well:
> https://bugs.debian.org/1053777

Ah!  Thanks for pointing that out.  I might as well tell the BTS that
it's fixed upstream.

> > Unless it's release-critical to have these Lintian warnings, I would
> > disregard them in hope that the pandoc package in unstable will
> > catch up at some point soon.
> 
> Unfortunately it is not likely that the package will be catch up soon,
> because the Haskell team upgrade most Haskell libraries only as a
> whole.
> 
> That issue is not tracked in debbugs, because those vocal in the
> Haskell team actively discourages the use of debbugs:
> https://lists.debian.org/debian-haskell/2024/01/msg00012.html

Ah.  That's a shame.  I have a lot of respect for the Haskell language.

Regards,
Branden


signature.asc
Description: PGP signature

Re: Proper handling of Lintian warnings due to other packages

[G. Branden Robinson]

Hi Loren,

At 2024-01-30T19:55:07-0800, Loren M. Lang wrote:
> While building a package preparing for a possible upload, I am getting
> a large number of warnings from groff-message due to invalid fonts for
> C and CB in the manpages that are generated from Markdown with pandoc.
> From what I understand, this is a known issue with how pandoc
> generates nroff man pages and more recent versions of groff have
> started complaining about the issue. Here is an example warning I am
> getting:
> 
> groff-message troff::89: warning: cannot select font 'C'
> 
> And it seems to match the issue documented here:
> 
> https://github.com/jgm/pandoc/issues/9020

Yes.  I work on groff upstream (and at rare intervals make minor
contributions to the Debian package), and you've accurately summarized
the situation.

> My question is how to handle this. Should I just ignore it for now and
> upload anyways since it's only a warning or should I add an override
> to suppress it as it doesn't seem to be causing any breaking issues at
> the moment? Have other developers dealt with this warning before?

Well, the version of pandoc that resolved the issue was 3.1.7, released
in August 2023.[1]  But the version in Debian unstable is still 3.1.3,
and the package is team-maintained.[2]

Unless it's release-critical to have these Lintian warnings, I would
disregard them in hope that the pandoc package in unstable will catch
up at some point soon.  Those warnings from groff can arise under other
circumstances, and they do mean that a font change requested by the
document has not been honored,[3] so I do not recommend masking them in
general.

Regards,
Branden

[1] https://pandoc.org/releases.html
[2] https://tracker.debian.org/pkg/pandoc

[3] From technical writing and accessibility perspectives, it is not
wise to stake important semantic differences to changes in font
style, but a lot of documentation gets written with that coupling
nevertheless.


signature.asc
Description: PGP signature

static linking, modularity, and community (was: Proposal for how to deal with Go/Rust/etc security bugs)

[G. Branden Robinson]

[follow-ups should probably go to -project, but I'm not setting my
headers to try to force that]

At 2024-01-24T16:57:06+0100, Simon Josefsson wrote:
> One could equally well make the argument that distributors should care
> about the Go/Rust ecosystems, and make whatever changes needed in
> order to support them.  Those changes are what I'm trying to explore
> here.

Exploration is one thing; advocacy is another.  Please be clear which
role you're taking in any given discussion.  (If you switch hats
midstream, be explicit about it).

[rearranging]
> Speaking as a C person (I know little about Go/Rust), getting stable
> ABIs, dynamic linking [...] right is not simple, and we've been
> working on that for 20+ years consuming plenty of human resources on
> the way.

That's true, but think about the goal that stable ABIs and dynamic
shared objects achieve: software modularity in the field at runtime.  I
trust that I don't have to argue the benefits of modular design to any
even slightly experienced software developer; its benefits have been
understood for about fifty years.

(Just to get this on the record, and for obligatory technical content:
I've studied Go a little and Rust a bit more.  I think that, _as
languages_, they're likely both superior to C in most respects.  [If you
want to visualize PDP-11 assembler output and stack layout as you code,
both are likely ill-suited to the purpose, as standard C itself
increasingly is.]  In any case they are well worth a software
professional's time to look at, in my opinion.  That doesn't mean you
have to endorse their adoption.)

> and security upgrades

And there's the payoff of dynamic modularity, if you will.

If the origin of a statically linked object, whatever its language of
implementation, is not on the ball _for any reason_, the exposure of a
security vulnerability in it or anything upon which it depends expands a
temporal window of attack on affected systems.  We _know_ that certain
actors in the global IT sector hoard undisclosed vulnerabilities for
deployment later, at opportune times for extortion or data exfiltration
against targets of interest.

Next, consider some of the reasons why the origin of a statically linked
object might come "off the ball".  Maybe they got fired or laid off.
Maybe they burned out.  Maybe they died.  Maybe they've been told the
project is supposed to become part of their "20% time"[sic].  Maybe it's
just "not a priority" to their employer.  Maybe they had a baby or
finally went on that long-planned vacation to a tropical island.

If you've worked in Big IT you know that you can predict that when your
business unit gets a new director, _you_ get a new direction.  Directors
and other senior managers justify their huge salaries and benefit
packages by being "impactful", and one reliable way to be "impactful" is
by handing down dramatic decrees.  (All of the top capitalists are
gamblers; one can easily perceive this in their personalities and
rhetoric.)  At one place I worked such a thing happened twice in less
than a year, I think.  We were going to "drop all Linux" and rebase
everything on FreeBSD.  Then that director departed the company and
FreeBSD was out the window--back to Linux.[1]

Worse, when any of these disruptions happens to the origin of a module
that employs static linking, it can take an indefinite amount of time to
_find out_ that such has even taken place.  So its user community may
lose time while it politely waits for their upstream to check in from
vacation or whatever, because they don't want to be rude, or seen as
hijacking the project, or similar.  And even that assumes that the right
people in the community have sufficient expertise to reasonably
approximate the usual construction and release procedures, which can
vary not just in the technology of the implementation system, but in the
hosting/development site.

Consider the motivations and pressures that professionalized, corporate
software is developed under.  Any cost of development that can be
externalized experiences an unrelenting force in that direction.

  An economic profit is the difference between the revenue received from
  sales and the explicit costs of producing its goods and services, as
  well as any opportunity costs.[2]

Opportunity costs are an interesting subject.[3]  They are often
difficult or even impossible to measure.  In business culture, they are
often therefore utterly neglected, even when they are known to exist.
This is why firms pollute, know they pollute, deny to the public that
they pollute, argue with everyone who challenges them about the
consequences of their pollution, and ultimately attempt to escape
liability for their subjection of others--ultimately, human beings and
the environment generally--to their negative externalities.  The
emphasis on profit and a desire by the wealthiest in society to preserve
the prevailing economic system is also why very concept of negative
externalities is under-emphasized or 

Debian package signing and integrity (was: RFC: advise against using Proton Mail for Debian work?)

[G. Branden Robinson]

At 2023-11-15T14:58:15+, Jeremy Stanley wrote:
> I replied to you there too, but you still never seemed to be able to
> explain... why do you need to put an OpenPGP key on the service
> you're using to upload Python packages (not Debian packages) to
> PyPI, given that PyPI doesn't support uploading OpenPGP signatures
> anyway?

Yeah, this seems really scary to me.  The private key of a
public/private key pair associated with an identifiable individual
should absolutely be under the _exclusive_ control of that individual.
Including read access.

I thought this idea was, like, practical crypto 101.

Am I missing something?

> Yes I'm also annoyed that they saw no value in software authors
> uploading signatures for their release artifacts, I argued
> repeatedly in favor of keeping it, but the PyPI maintainers (rightly
> or wrongly) saw it as a mostly-unused attractive nuisance, and
> assert that their more recent addition of HTTPS and strong checksums
> mostly serves the purpose of users being able to double-check that
> what they downloaded is what PyPI meant to serve them (even if they
> can't as easily double-check that what they downloaded is what the
> author believes was originally uploaded).

It's funny how the same arguments recur over time.  Back in 2001, Ben
Collins, John Goerzen, and Wichert Akkerman tried to get this same sort
of thing into practice into Debian, and faced a wall of indifference
from the archive administration team[1].  One may recognize this
approach to package signing as a Merkle tree, an old concept even at the
time that was popularized as a thoroughly innovative lightning stroke of
genius called "blockchain" several years later.

(I seem to remember that John and I worked on a brief USENIX-style white
paper describing this, but I've long since lost track of it.  I also
don't remember if we tried to submit it for DebConf 1 or 2.[8])

I was excited by this development at the time, because it provided a
user-verifiable chain of custody for source bits.  You could have nested
signatures by the (source) package uploader, the party who built the
binary package, and one by each/any archive host.

I recall from IRC that some of the resistance was due to a vague notion
that package signing was suspect because John and I were drawing
salaries from Ian Murdock's company, Progeny Linux Systems; that some
hidden agenda was therefore at work[2], producing an undisclosed
conflict of interest.  Some of these same people suddenly perceived
massive _synergies_ of interest when they themselves started drawing
salaries from Mark Shuttleworth's Canonical Software.  All of a sudden,
they couldn't endorse external agendas enough.  Go figure.

It's noteworthy to me that, despite much more widespread understanding
of Merkle trees nowadays[3], one's opinion of the value of nested,
signed checksums seems to have a strong negative correlation with one's
status as an administrator of a centralized repository, such that only
the last link in the chain of custody is considered important.  With
that threat model, there's no need to compromise any packager's or
uploader's key; you conduct an injection attack on the archive directly.

And _that's_ something that's never happened to anyone, right?[7]

Regards,
Branden

[1] a.k.a. "ftpmasters", a term I have always refused to use because it
is too depressingly Nietzchean--if there's anything that team wasn't
lacking back them, it as a Will to Power...

https://lists.debian.org/debian-dpkg/2001/03/msg00024.html

[2] Such a fear isn't crazy.  Plenty of startups predicate their
promises of future profitability on some sort of "secret sauce" or
process of market capture.  But there would not have been any way to
convince anyone of that at the time.  As the saying goes, "you can't
reason someone out of a belief they weren't reasoned into".  As it
happened, (A) John and I would have been opposed to any such
unethical leveraging effort had one been on offer;[4] (B) Ben and
Wichert weren't affiliated with or compensated by Progeny in any
way;[5] (C) the design and implementation of the initiative were
completely transparent, and their applicability to the problem of an
indeterminate chain of (bit-modifying) custody obvious; and (D)
while it was pursuing a business plan of "get acquired for an absurd
amount of money", the company's strategic direction whipped to and
fro like an unmoored fire hose, depending on whatever Ian was
reading (or who he was talking to) at the time...I suspect that
these were frequently investors who knew far less about the industry
than he did.  Culturally, it doesn't seem that we've gotten any
better distinguish wealth (or the illusion thereof[6]) from domain
knowledge, competence, or virtuous character.

[3] Well, maybe not.  For one rollicking, schadenfreude-inducing tale of
vapidity, cupidity, and stupidity after another, see

Re: Hyphens in man pages

[G. Branden Robinson]

Hi Jon,

At 2023-10-23T17:24:30-0600, Jonathan Corbet wrote:
> When I wrote the article (last week) it was a lot closer :)
> 
> As for why: Debian may have resolved this, for now at least, but this
> is an issue that is sure to crop up in distributions that are not as
> quick to pick up new groff releases.  In that sense, the topic is very
> much timely.

Interestingly (perhaps), this wasn't the first thing that caught fire
after the groff 1.23.0 release.  What was, was a hack that Debian took
out of its man.local file to force SGR escape sequences off in
grotty(1).  But other distributions, like Arch and its many derivatives,
still had it and noticed when it quit working, because they also use the
less(1) termcap_XXX environment variable hack (until relatively
recently, undocumented) to convert overstriking character sequences
into...SGR escape sequences for selecting colors.

That was
.

It took nearly four months for a hyphen-minus debacle to flare up.
Another two and I would have decided I'd managed to duck controversy.

> And as for the groff release ... I sure wish we could find another
> writer to hire to help us restore some of our wider community coverage.
> If you know any likely candidates, do send them our way.

Could you update a URL in the article to be more robust?

https://git.savannah.gnu.org/cgit/groff.git/tree/PROBLEMS#n64

But this points to the master branch, so the text at that line number
will not be stable over time, and in fact it's not correct for the
"PROBLEMS" file in the groff 1.23.0 release.  (We managed to fix some
problems afterward.)

This URL would be better:

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

I also shifted the line address a little to make it more obvious how old
this issue really is.

Regards,
Branden


signature.asc
Description: PGP signature

Re: Hyphens in man pages

[G. Branden Robinson]

At 2023-10-23T11:17:07-0500, G. Branden Robinson wrote:
> Would someone be willing to send me a subscriber-sponsored link to it?

Thanks to the three fleet-fingered folks who supplied me with one.  I am
amply equipped to resume my crusade against ignorance and
misinformation...except...

Now that I have undertaken to attempt to shed light on a comment to the
article, of course LWN itself goes down.[1]

Because of course it did.

Regards,
Branden

[1] https://downforeveryoneorjustme.com/lwn.net

"It's not just you! lwn.net is down.

Last updated: Oct 23, 2023, 11:36 AM (1 second ago)"


signature.asc
Description: PGP signature

Re: Hyphens in man pages

[G. Branden Robinson]

At 2023-10-14T20:51:27-0600, Antonio Russo wrote:
> I discovered a new pet peeve today:

I must report with some dismay that this thread made LWN.

https://lwn.net/Articles/947941/

Would someone be willing to send me a subscriber-sponsored link to it?

I intend to attempt to address what I expect to be inevitable incorrect
statements about groff and/or man pages in the attached discussion
thread.

I am disappointed that LWN did not cover the groff 1.23.0 release, its
first in four years and featuring over 400 bug fixes,[1] even as a tiny
blurb on the back page, but seizes upon this issue, which quietly died
down a week ago, and should therefore have aged out of the current
window of "weekly" news.

Regards,
Branden

[1] https://lists.gnu.org/archive/html/info-gnu/2023-07/msg1.html


signature.asc
Description: PGP signature

Re: AltGr+ not working anymore on most Desktop apps in Gnome

[G. Branden Robinson]

Hi Andrew,

At 2023-10-23T10:41:10+1300, Andrew Ruthven wrote:
> On Sun, 2023-10-22 at 13:18 +0200, Bastian Venthur wrote:
> > fixed the problem. It is strange this option seems to be affected by
> > the keyboard settings in gnome settings, however i changed all
> > options back and forth in the GUI so they should work, but it
> > somehow didn't.  Resetting the option above fixed it. Since I've
> > never used dconf before, I guess there is a bug somewhere that lead
> > to this situation.
> 
> Possibly not related, but a friend noted that after a recent Gentoo
> update his compose key stopped working. Turned out to be a conflict
> between the XkbOptions compose:ralt and grp:switch which were both
> enabled. Turns out something has changed and if they're both set it
> won't work.

I had been surprised to learn earlier this year that quite a bit of
cleanup work has been going on in XKB upstream.

In fact, prior to some CVEs that cropped up last month, such cleanup,
undertaken by at least 3 different people, has dominated recent libx11
development.

https://gitlab.freedesktop.org/xorg/lib/libx11/-/commits/master

Way back when I was maintaining Debian's XFree86 packages, I had
despaired of such an effort ever being understaken.

It's a good thing to see.  But I would not be surprised if some formerly
invalid-but-quietly-accepted configuration combinations, which so often
in XKB seem to arise from cargo-cult practices, start behaving
differently, or stop behaving at all.

Regards,
Branden


signature.asc
Description: PGP signature

Re: Bug#1041731: Hyphens in man pages

[G. Branden Robinson]

At 2023-10-15T13:11:47-0700, Russ Allbery wrote:
> Sorry for my original message, which was very poorly worded and
> probably incredibly confusing.  Let me try to make less of a hash of
> it.  I think what I'm proposing is something like:

My reply to this didn't make it to the -devel list even after several
hours; I suppose it was blocked due to my inclusion of a PDF attachment.

Those who are curious about the issue can read it at
.

Regards,
Branden


signature.asc
Description: PGP signature

Re: 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

Re: 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

Re: 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

Re: 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 

Re: debian/copyright format and SPDX

[G. Branden Robinson]

At 2023-09-22T02:11:15-0700, Steve Langasek wrote:
> SPDX defines an xml format only.  They lost before they'd even
> started.
> 
> debian/copyright is supposed to be human-readable first and foremost.
> XML need not apply.

Very much +1 on everything quoted.

That said, SPDX's license list and the (plain text) tagging convention
that has grown up around it is of great value, and not at all
incompatible with Debian's documentary conventions.

Regards,
Branden


signature.asc
Description: PGP signature

Re: 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

Re: Questionable Package Present in Debian: fortune-mod

[G. Branden Robinson]

At 2023-08-23T15:40:06+0100, Adam Sampson wrote:
> "Andrew M.A. Cater"  writes:
> > where are we going to get our fortunes from - where's the canonical
> > source now that FreeBSD has gone?
> 
> There is Shlomi Fish's version:
>   https://github.com/shlomif/fortune-mod/

I've been mulling over whether to take the Debian package native, but
re-orienting our upstream may be a better idea.  The debian/patches
directory of our package is depressingly motley.

https://sources.debian.org/src/fortune-mod/1%3A1.99.1-7.3/debian/

> This includes the patches from Debian and other distributors,
> along with various other updates to the data files, including removing
> some (but certainly not all) of the more obnoxious fortunes.

Good, on both counts.  I had forgotten that the obnoxious cookie files
are already ROT13 encrypted in the source, so the complaint about the
source package containing them sounds to me like a case of taking a
letter opener to the sealed part of the "adult magazine" warning of
offensive content, greedily slicing one's way to access, and then
complaining to the 7-11 proprietor that your sensibilities are shocked.

(Translation: I'm so old I remember magazines doing this; AARP beckons.)

I find Amy Lewis's remarks on the matter, from 1995, noteworthy.

https://sources.debian.org/src/fortune-mod/1%3A1.99.1-7.3/Offensive/

> I am a bit dubious about the licensing of some of the original
> collection, though, even under the most liberal interpretation of fair
> use -- for example, songs-poems contains complete lyrics for several
> songs that are certainly still under copyright.

But they have also been there for a long, long time--not only, in many
cases I am sure, since before commercial access to the Internet was a
thing, but before many of the lawyers who might attempt to litigate such
claims were born.  For situations like this, there are theories of
estoppel and the principle of laches.  In a nutshell, if you sleep on
your rights, you risk giving them up--with respect to particular
infringements.  This is a U.S.-centric observation, but so is the music
publishing rights industry--never diverse, but a tall oligopoly today.

> (Although I guess we could now add a complete set of Tom Lehrer!)

Thank you for bringing this unalloyed happy news to the thread.  :)

Regards,
Branden


signature.asc
Description: PGP signature

Re: Questionable Package Present in Debian: fortune-mod

[G. Branden Robinson]

at come at
some risk to yourself.  Shelter Jews from Nazis.  March with Black Lives
Matter advocates, particularly in areas where white supremacists have
vowed to show up in counter-protest and/or where the police are known to
be cranky and vocally dedicated to an ethos of "busting heads" to
control crime.  The less your advocacy costs you, the less it matters.

It's okay if you're not up to exposing yourself to such danger.  We
rightly celebrate (and, often, commemorate after the violent deaths of)
people who do.  Martin Luther King, Jr.'s writings and speeches are
deservedly well-remembered.[2]  But we must remember that he got out and
marched at risk to himself, frequently.  He was imprisoned for this; I
urge you to read his "Letter from a Birmingham Jail" from start to
finish.  It connects speech with action more eloquently than I can.  Let
us also not forget that when the forces of evil finally took him out, it
was while he was in Memphis in solidarity with striking garbage workers.

At 2023-08-18T21:09:11+, Andrew M.A. Cater wrote:
> As the person who raised this on debian-project in November 2022 - see
> the archives for debian-project for November/December 2022
[...]
> There was unfortunately no consensus on removal on debian-project and
> G. Branden Robinson filed an ITA - intent to adopt - for this package
> at the time.

Thank you for the reminder, though I have not forgotten.  I postponed
this activity until groff 1.23.0 was released and packaged for unstable;
thanks to Bertrand Garrigues and Colin Watson, that's happened.

I admit to some procrastination on my follow-through.  I expect to
receive abuse from people who struggle to distinguish anarchists from
racists and Nazis, for instance, and such derogation would appear to be
in the offing--see below.  That such personal attacks would, it seems,
be carried out in the name of championing the Debian Code of Conduct is
an irony that I do not find pleasant in its familiarity.

> In the absence of any apparent package, this should possibly be 
> added to files considered for removal: in some sense, it would still 
> have been easier to do this prior to Bookworm release, but, hey, you 
> can't do everything :)

For the moment, I reiterate my ITA (adding the bug's -quiet in CC for
this purpose only).  As often happens in software development, I think
changes by small increments make larger adaptations tractable.

I therefore propose the following course of action for myself.

1.  Adopt the package as-is and upload to experimental.

2.  Rename fortunes-off to fortunes-nsfw and upload to unstable, with
the fortunes-nsfw package description rewritten to suggest its
purpose: the avoidance of encounters with the Human Resources
departments of businesses, NGOs, and other institutions where the
Debian distribution might be deployed.

3.  Add explanatory material insular to Debian (history, content) to the
source package, specifically including references to our mailing
list discussions of it.  Last year's thread is an obvious choice,
but whatever records survive of former DPL Bruce Perens's decision
to segregate the "fortunes-off" package and contemporary responses
to it from other Debian Developers would also be valuable for
edification of the younger generation of Debian contributors.[3]

4.  Begin to audit the package for objectionable content according to my
personal taste as suggested in last year's thread.  I venture this
metric not out of egomania, but because I am skeptical that I can
fairly represent anyone's taste but my own.  To summarize last
year's lengthy discussion, I expect I would take out material that I
think has become stale, or where I find a rebuttal to bigotry
insufficiently witty or forceful.

5.  Add stuff that I think is interesting.  Again recapitulating last
year's discussion, I believe that the acquisition of competence in
so-called "higher" mathematics is an ennobling practice and a much
needed remedy for the minds of those who embroil themselves in what
is popularly termed the Culture Wars.  (To my simple mind, much of
this warfare reduces to the age-old struggle between authoritarians
and their putative subjects, but played out at the periphery rather
than the core of official political operations.)

6.  Address _particularized_ and _specific_ bug reports about the
package's content as and when they arise.  What was said?  Who is
harmed, and how?  I pessimistically assume that I'd get appealed to
the CoC committee in nearly every case I rejected the report, but at
the very least I'd try to get a concrete record before the committee
regarding what, _exactly_, someone wanted removed.  I predict that
this would make their job easier.  See above regarding judicial
processes.

It does occur to me that the above plan is, arguably, violative of

Re: groff warning: TE macro called with TW register undefined

[G. Branden Robinson]

At 2023-08-17T01:37:52+0100, Colin Watson wrote:
> On Wed, Aug 16, 2023 at 07:08:18PM -0500, G. Branden Robinson wrote:
> > [6] https://man.cx/grog
> > 
> > I was going to link to
> > https://manpages.debian.org/unstable/groff/grof.1.en.html here, but
> > the man page is missing!  groff definitely ships it.  Any advice?
> 
> Aside from the typo in the last URL segment, the penultimate segment
> identifies the binary package, and grog(1) is in the groff-base package
> rather than groff.

Thanks, Colin.  That explains why I also couldn't find it under
<https://manpages.debian.org/unstable/groff/>.

Upstream mentality plus a senior moment--not a good combination!

>   https://manpages.debian.org/unstable/groff-base/grog.1.en.html

Regards,
Branden


signature.asc
Description: PGP signature

Re: groff warning: TE macro called with TW register undefined

[G. Branden Robinson]

Hi Hugh,

At 2023-08-17T07:54:03+1000, Hugh McMaster wrote:
> On Thu, 17 Aug 2023 at 03:39, Colin Watson wrote:
> > On Wed, Aug 16, 2023 at 09:29:45PM +1000, Hugh McMaster wrote:
> > > This all seems promising. Unfortunately, the man page is
> > > hand-crafted, not generated from another source, so groff is never
> > > invoked, and no other documents are referenced in the file.
> >
> > groff must be run somewhere, because you're seeing a warning from
> > groff.
> 
> I meant that groff is never called by FreeType's build system, as the
> man page is hand-crafted.

Okay.  But Lintian _is_ calling groff, to format man pages and sniff out
problems with them.

So whether the man page is hand-crafted or generated from some other
format at build time is not relevant.  In fact, it's _meta_ irrelevant
(if that's even a thing) because the only reason (apart from the
validation Lintian's doing) for a source project to run groff at build
time on a man page is to generate a PDF, "cat page", or other
_formatted_ version of the man page.[1]  Examples of these are rare, but
Bash and NetHack generate cat pages, and groff itself generates a PDF
compilation of all its man pages.[2]

> > What exact check is failing here (is it lintian, or something else)?
> > Could you please give us a pointer to the man page in question?
> 
> Lintian issues the warning when checking for man-page issues using
> groff (via man). This particular warning has only appeared since the
> recent groff 1.23.0 upload.

The warning is new to groff 1.23.0.[3]

> The Lintian tag is 'groff-message'. The tag description helpfully
> provides the exact command used during the check:
> 
> LC_ALL=C.UTF-8 MANROFFSEQ='' MANWIDTH=80 \
> man --warnings -E UTF-8 -l -Tutf8 -Z  >/dev/null
> 
> The man page in question -- ftlint.1 -- is in the freetype2-demos
> package [1], or you can get an online copy from [2].

In the course of composing this message, I see that Colin covered this
point.[4]

I would also note that you can use the grog(1) command (new and improved
in groff 1.23.0![5]) to help you figure out which preprocessors (and
macro package) a *roff document needs.[6]

Let me know if this helps, or does not.

Regards,
Branden

[1] Another use case is to produce non-man-page manuals from *roff
sources using a macro package like "ms", "me", or "mm".  groff
supports all of these and it was commonly done in pre-Web days, but
it's now sadly close to a lost art.  The _Unix Time-Sharing System
Programmer's Manual Seventh Edition Volume 2_ (1979) remains
valuable reading and an example of high-quality technical writing
apply *roff to ends other than man pages.


https://archive.org/details/bitsavers_attunix7thersManualSeventhEditionVol21983_34117955/

It's particularly valuable for learning "classical Unix" tools in
their early and more easily grasped forms.  I've found that GNU
manuals, in spite of the advantages touted for Texinfo for
preparation of book-length works over mere reference guides (a.k.a.
man pages), are nevertheless often written in the style of man pages
with little effort made to give the reader a perspective from which
to integrate knowledge of the (nearly always) larger interface and
feature list of GNU replacements for Unix tools.  In other words,
they too often suffer from the same defects that the GNU Coding
Standards attribute to man pages.


https://web.archive.org/web/20041029120203/http://www.gnu.org/prep/standards/html_node/GNU-Manuals.html#GNU-Manuals

(To be fair, more recent versions of the GNU Coding Standards have
moved--slightly--in the direction of acknowledging that the
quality of the technical writing, not the formatting language used
to compose it, that is the predominant factor in production of
useful manuals.)

[2] https://www.gnu.org/software/groff/manual/groff-man-pages.pdf
[3] 
https://git.savannah.gnu.org/cgit/groff.git/commit/?id=80ee140eb0616b794b853bbad623263cbea06abc
[4] https://lists.debian.org/debian-devel/2023/08/msg00220.html
[5] Yes, I can feel my eternal soul tumbling down several rungs in Hell
for engaging in promotion.

[6] https://man.cx/grog

I was going to link to
https://manpages.debian.org/unstable/groff/grof.1.en.html here, but
the man page is missing!  groff definitely ships it.  Any advice?


signature.asc
Description: PGP signature

Re: groff warning: TE macro called with TW register undefined

[G. Branden Robinson]

Hi Hugh,

I work on groff upstream.

At 2023-08-15T22:46:30+1000, Hugh McMaster wrote:
> groff-message an.tmac::66: warning: tbl preprocessor
> failed, or it or soelim was not run; table(s) likely not rendered (TE
> macro called with TW register undefined)
> 
> It seems TW is not defined in the number register.
> 
> While I can define TW by adding `.nr TW 0` before .TS, I don't know if
> that's the correct solution.

It is a bad idea.  The purpose of the `TW` register is defined in the
tbl(1) man page.

The register TW stores the width of the table region in basic units;
it can’t be used within the region itself, but is defined before the
.TE token is output so that a groff macro named TE can make use of
it. [...]

This information is necessary for macro packages that want to center
tables, a common feature of packages _except_ those that render man
pages.  Because forgetting to run the tbl preprocessor is a common
error, during groff 1.23.0 development it occurred to me that I could
use this register as an indicator.

> Any ideas on fixing this warning, or is it best to ignore it for now?

The diagnostic message is trying to warn you that you _probably_ forgot
to run tbl.  But there are other causes.

1.  tbl crashed or aborted.

2.  The man(7) document embedded the beginning of table in a different
file that it "sourced" with the `so` request, but soelim(1) was not
run on the document.  This is valid, but not considered portable man
page composition style.[1]

3.  A `TE` macro call is in the man page with no `TS` preceding it.
This could arise due to clumsy editing, unfamiliarity with the
man(7) language, or bad luck combined with inexperience (an ordinary
text line happened to begin with `.TE` and the page author didn't
realize that *roff would attempt to interpret that as a macro call).

I tried to cover these bases in the diagnostic, but might have failed.

Can you tell me what part of the message was confusing?

Regards,
Branden

[1] Any *roff can handle this.  So can mandoc(1)--I just found that out.
This fact raises some interesting possibilities, since everything
that was ever called "man2html", the original motive for
groff_man(7)'s Portability section[2] has long gone to the dustbin.

[2] In groff 1.23.0, this section is now in groff_man_style(7).


signature.asc
Description: PGP signature

Re: How do you cause a re-run of autopkgtests?

[G. Branden Robinson]

At 2023-07-21T13:43:05+0200, IOhannes m zmölnig (Debian/GNU) wrote:
> On 7/21/23 12:57, G. Branden Robinson wrote:
> > Hi folks,
> > 
> > But I see no mechanism for interacting with autopkgtests to force
> > them to re-run due to the remedy of a defect in the test harness
> > itself.
> > 
> > How is this to be done?
> 
> you mean, apart from clicking on the ♻ retry icon?

Oh, _that's_ what that means!  It had no tooltip, but if I peer at the
URL preview it does say "retry", so I must confess blindness as well as
ignorance.

> (you probably have to be authenticated in order to even see these
> icons)

I don't have to be authed to _see_ it, but if I click on it, a login is
demanded of me.  Fair enough (robot/DoS defense).

> > Should some automated mechanism for achieving this be added, and if
> > so, where?
> 
> https://ci.debian.net/api/doc

As a bear of little brain, I can indeed infer from this that a mechanism
for prompting retry exists.

Thanks for the pointers!

Regards,
Branden


signature.asc
Description: PGP signature

How do you cause a re-run of autopkgtests?

[G. Branden Robinson]

Hi folks,

Regarding:

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

...progress of groff into testing is blocked because autopkgtests went
bonkers, failing on every architecture.  This was due to a change in a
groff diagnostic message not getting scraped away by dgit, which was
using a regex to match the message text, and employing one of its own
man pages as a model document to, I think, validate correct man/groff
operation, or man page rendering.  Unfortunately the dgit man page in
question was defective.  I reported the bug with an explanation and
patch, and Ian Jackson promptly fixed and uploaded it.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041317
https://tracker.debian.org/news/1446065/accepted-dgit-111-source-into-unstable/

But I see no mechanism for interacting with autopkgtests to force them
to re-run due to the remedy of a defect in the test harness itself.

How is this to be done?  Should some automated mechanism for achieving
this be added, and if so, where?

Regards,
Branden


signature.asc
Description: PGP signature

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[G. Branden Robinson]

At 2023-05-19T15:32:40+0100, Colin Watson wrote:
> I occasionally use 32-bit x86 even today (mostly for not very good
> historical reasons, but nevertheless), and I do it by using a 32-bit
> container on a 64-bit x86 machine instead.  It's much faster to run,
> and it doesn't depend on installer support.  There are doubtless edge
> cases where you need a completely separate kernel, but they aren't
> really ones I run into.

Yeah, I knew the containerization rejoinder would arise but failed to
pre-empt it.  And since time_t is a userland problem, it's probably good
enough for the subject of the parent thread.  But I still feel a twinge
of worry for the _unanticipated_ problems...

I am probably also utterly failing to manage my secret desire that by
2037 we'll all[1] be running RISC-V 64 and that no major fab in the
world will still be etching dies of x86-{32,64} cores.

You can laugh at my optimism now.

Regards,
Branden

[1] Not all.  I hope there will still be m68k machines humming away.


signature.asc
Description: PGP signature

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[G. Branden Robinson]

At 2023-05-19T15:03:40+0100, Steve McIntyre wrote:
> Luca Boccassi wrote:
> >+1 for stopping publishing installers for i386, it has been mentioned
> >many times but it's always worth repeating: electricity costs to keep
> >running i386 hardware are already way higher than what it costs to
> >buy a cheap, low-power replacement like a raspberry pi, that also
> >provides better performance.
> 
> Exactly.
[...]
> My plan is therefore [...]  to disable those builds for testing/trixie
> ~immediately after the release.
> 
> If people have strong opinions about that plan, let us know please.

Well, maybe not a strong view, but a sense of vague unease--possibly an
ill-informed one.  As someone who has used SIMH for "real" work[1], I
have to ask how someone would conduct an install to a 32-bit x86 machine
running under emulation, assuming no OS on the simulated machine.
Ordinarily, I'd turn to this:

https://wiki.debian.org/DebianInstaller/Qemu

What happens to that with trixie?

I think simulation of 32-bit x86 will get _more_ important as year 2038
approaches, not less, because in about 2037, people will suddenly notice
they need to test things before deployment.

And there are reasons we might not anticipate today.[2]

Regards,
Branden

[1] Running nroff and troff on an emulated PDP-11/45 running Version 7
Unix, to resolve compatibility defects in groff and settle arguments
about "authentic" Unix *roff behavior.

[2] https://ieeexplore.ieee.org/stamp/stamp.jsp?tp==7974703


signature.asc
Description: PGP signature

Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg)

[G. Branden Robinson]

At 2023-05-17T11:30:36+0200, Helmut Grohne wrote:
> This bootstrap aspect got me and I discussed this with a number of
> people and did some research.

I'd like to nominate you for a Russ Allbery Award for the most useful
post to the thread.  Your attention to concrete, empirical details,
arising necessarily from practical experimentation rather than pure
cogitation, made the nature of the problems here clearly comprehensible
to me.  And if I was befogged, I'll wager other people were too.

Regards,
Branden


signature.asc
Description: PGP signature

Re: RFC: More C errors by default in GCC 14 (no more implicit function declarations etc.)

[G. Branden Robinson]

[I am not subscribed to debian-gcc or c-std-porting]

Hi Florian,

At 2023-04-18T16:07:45+0200, Florian Weimer wrote:
> TL;DR: I want to propose a GCC 14 change which will impact
> distributions, so I'd like to gather some feedback from Debian.
> 
> Clang has disabled support for a few historic C features by default
> over the last few releases.  This mirrors a process that Apple has
> begun in Xcode even earlier (perhaps motivated in part by their
> AArch64 Darwin ABI, which is pretty much incompatible with some of the
> C89-only features).
> 
> These changes bring real benefits to C programmers because errors are
> much harder to miss during the build than warnings.  In many cases,
> the compiler is not able to generate correct code when such issues are
> present, and programmers who look at the generated machine code
> suspect a compiler bug.  And all this happens because they missed a
> warning.  So we want this change for GCC, too.
[...]
> Specifically, I'm investigating the following changes:
> 
> * -Werror=implicit-function-declaration: Functions can no longer be
>called without be declaring first.  Fixing this may need additional
>prototypes in package header files, or inclusion of additional
>header files (both package-specific and system headers).
> 
> * -Werror=implict-int: int types can no longer be omitted in old-style
>function definitions, function return types, or variable
>declarations or definitions.  Fixing that involves adding the int
>type (or the correct type if it is not actually int).  If there is
>already a matching declaration in scope that has a different type,
>that needs to be resolved somehow, too.
[reordered]
> I want to propose at least the first two for GCC 14.
[reordered]
> The exact mechanism how the default is changed may not be -Werror=,
> perhaps something along the lines of -fpermissive for C++.  The C89
> modes (-std=gnu89 etc.) will likely still enable all these features
> (even if they are not part of C89).  As an opt-out mechanism,
> -std=gnu89 is insufficient because there are packages out there which
> use features which are C99-and-later-only in GCC (predominantly
> C99-style inlining, I believe) together with
> implicit-int/implicit-function-declaration.

Perhaps the thing to do here is have, , yet another command-line
option for GCC.  The Ada language did something similar a couple of
decades ago to tighten up the language for hard real-time demands, with
what it called the "Ravenscar profile".[1]  That proved successful (as
successful as anything was in poor neglected Ada).

The term "profile" is perhaps unfortunate since it already has another
meaning in software performance measurement.  Maybe we could use the
term "contour", which isn't any longer, unlike "silhouette".  A
"contour" furthermore suggests boundaries, which would seem to be
apropos for what you're trying to do in two respects: (a) "ruling out"
certain coding practices that are accepted as standard, or at least
tolerated, otherwise; and (b) reducing the amount of undefined behavior
compiled code exhibits.

Whatever its name, some advantages to this approach are that
distributors could opt-in to such a thing, make it a clear matter of
policy, and more easily track adoption and progress.  You could also
version the contour much like the C standard itself.  So, for instance,
you introduce a contour called "clave23"[2] with the above features...

> * (tentative) -Werror=int-conversion: Conversion between pointer and
>   integer types without an explicit cast is now a compiler error.
>   Usually fixed by one of the two things above.  I do not have data
>   yet how many other cases remain after the initial issues are fixed,
>   but should have that in the coming weeks.  (Quite frankly, I'm
>   amazed that we created 64-bit ports without making this an error.)

So was I, 20 years ago when working on IA-64 ports...

> * (very tentative) -Werror=incompatible-pointer-types: GCC will no
>   longer automatically convert between pointer values of unrelated
>   pointer types (except when one of them is void * or its qualified
>   versions).  The fallout from this could be quite large, I do not
>   have data yet.  Clang does this for function pointer types only
>   (probably based on their ABI issues), but I'm not sure if it's a
>   reasonable distinction for our ABIs (the ppc64le cases I've seen had
>   explicit casts and no warnings).

And then perhaps adopt the above two for "clave26" in 2026 or so.

> * For -Wdiscarded-qualifies (e.g., using const pointers as non-const),
>   and -Wpointe-rsign (using char * as unsigned char *) I do not have
>   any plans.

With a versioned "profile" or "contour", you need not eat the elephant
all at once, and maintain ambitions that seem hopelessly distant today.

> I would appreciate some discussion on the Debian impact.  As Debian
> generally doesn't do mass rebuilds and we have upstreamed the fixes,
> maybe the impact is somewhat 

Re: Reducing allowed Vcs for packaging?

[G. Branden Robinson]

At 2023-03-26T13:56:55-0700, Sean Whitton wrote:
> On Sat 04 Mar 2023 at 10:58PM +01, Joerg Jaspert wrote:
> > But git or svn or even sccs and rcs is NOT, in any way, preferred
> > for of modification. Only one way of storage and handling some
> > metadata.
> 
> This is Debian's official position, but it's debateable.
> 
> There is the preferred form for modification for an individual *file*,
> and that probably doesn't include version control.  But the preferred
> form for modifying a *project* arguably does.

I wonder if, after twelve years, we have any empirical data regarding
whether Red Hat's stance, that change sets (discretized by the process
of commits to VCSes) are not constitutive of the "preferred form for
modifying a copyrighted work" when that is the form invariably used by
those performing the modifications, frustrated Oracle's aims, or whether
this deliberately anemic interpretation of the GPL was a perfomative
weakening of copyleft to little or no commercial advantage.

https://lwn.net/Articles/432012/

Regards,
Branden


signature.asc
Description: PGP signature

Re: need GBP help with groff 1.23.0 (1.23.0~rc3-1 package prepared)

[G. Branden Robinson]

At 2023-02-26T11:52:39+0100, Andrey Rakhmatullin wrote:
> Just import them? Do you have any specific questions or problems with
> this?
[...]
> Again, which advice? You said that it works for you.

Hi Andrey,

I think at least some of my confusion arose from trying to use gbp with
a git-dpm-based repository.  I was working in a big hurry, trying to
make the Bullseye release but that is now looking hopeless.

Thanks for responding so swiftly to my plea for help.

Regards,
Branden


signature.asc
Description: PGP signature

Re: 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

need GBP help with groff 1.23.0 (1.23.0~rc3-1 package prepared)

[G. Branden Robinson]

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

Can someone advise me as to the correct procedure for merging upstream
release candidate archives into https://salsa.debian.org/debian/groff ?

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. ***

Some relevant shell history is at the end of this message.[1]

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:

dh_clean fails with diagnostics involving cp, checksums, and a "bucket"

[G. Branden Robinson]

Hi folks,

It's been a while since I've done any packaging.  I was baffled when
presented with the following.

   dh_clean
cp: cannot stat 
'debian/.debhelper/bucket/files/19c12bb2ca19e68724c2854ed0512469518df19b0710cc2011a5ca540810979c':
 No such file or directory
dh_clean: error: cp -an --reflink=auto 
debian/.debhelper/bucket/files/19c12bb2ca19e68724c2854ed0512469518df19b0710cc2011a5ca540810979c
 
debian/.debhelper/bucket/files/19c12bb2ca19e68724c2854ed0512469518df19b0710cc2011a5ca540810979c.tmp
 returned exit code 1
make: *** [debian/rules:3: clean] Error 25

1.  What is the debhelper "bucket"?  A web search turns up no
documentation of this architectural feature, one evidently important
enough that its identification is permitted to leak into diagnostic
messages.
2.  Why is dh_clean trying to copy files around at all?  Nothing about
this is disclosed in dh_clean(1).
3.  Why is dh_clean's own diagnostic message pretty much a
recapitulation of the one before?  First, dh_clean should know why
it is calling cp, and be able to emit an informative diagnostic
about the context of the failure.  Second, why is there no handler
for this failure mode?  It looks like the diagnostic was generated
by a generic wrapper around execve() (or Perl's system(), maybe):
it reports the attempted command line verbatim and its exit status.
This sort of interaction, even with sophisticated users, is suitable
more for tracing or debugging output.
4.  The exit status "25" is fairly unusual, suggesting that it has
significant semantics.  Yet I find no documentation of such
significance in dh_clean's own man page nor in debhelper(7).  Why?
"Exit status" is a common and well-known section heading.

Can someone shed some light on these matters?

Please CC me on replies--many years ago I kept up obsessively with
debian-devel traffic, but not any more, I'm sorry to say.

Thank you in advance.

Regards,
Branden

...so help me, a _bucket_...
https://www.hactrn.net/sra/vaxen.html


signature.asc
Description: PGP signature

Re: Realizing Good Ideas with Debian Money

[G. Branden Robinson]

At 2019-06-01T09:04:39+0200, Philipp Kern wrote:
> Are we then looking more closely at AMD-based machines given that
> those had less problems around speculative attacks?

To borrow a phrase from Christopher Hitchens, this comment gives a
hostage to fortune.

My team at work closely follows (and part of it contributes to) the
research in microarchitectural timing-channel attacks; we just covered
the white paper on one of the three new attacks (RIDL)[1] on Friday.

I'll say this now because I don't know of anything embargoed that could
get me into trouble: don't count on AMD's good smell just this second to
last.  Remember that the previous round of embarrassments
(Spectre/Meltdown) didn't entirely spare AMD and ARM, and we haven't yet
seen any ground-up reimplementations of CPU cores with publically
auditable, formally-verified proofs of immunity to microarchitectural
timing channel attacks.

I see no reason to reward AMD with purchases based on what may be an
accidental and temporary lack of egg on the face.  This is the same firm
that followed Intel into the land of unauditable system management
firmware[2] and acquired ATI and shut down the information channels
enabling good free video drivers to be developed[3].

My two cents[4] is that DSA should make its purchasing and hardware
solicitation decisions with the architectural security issue fairly far
down the priority list.  It saddens me to say that, but this new class
of exploits, what van Schaik et al. call "microarchitectural data
sampling" (MDS), is a playground for security researchers right now; a
big rock has been turned over and bugs are erupting from the soil in a
squamous frenzy.  It will take months or years for the situation to
settle down.

To acquire hardware based on what is known today is to risk buyer's
remorse.  Plan on inescapable remorse later; every chip vendor will let
us down until corporate managers learn to treat confidentiality and
integrity as feature rather than cost centers.  (And count on them to
forget what they've learned after a few quarters pass without
embarassing headlines.)

Some day, perhaps, if the universe is less than maximally cruel, we'll
have the option of server-class RISC-V systems with fully-documented,
formally-verified designs.  But that day is not yet here.

In the meantime, always keep a fork with some cooked crow on it ready to
hand, so that the next time you run into one of the many "pragmatic"
people in our community who puffed and blew about how we didn't "really
need" open hardware, you can invite them to eat the stuff and so be
silent.

One wonders how pragmatic they'll feel when it's _their_ private data
being exfiltrated.

[1] https://mdsattacks.com/files/ridl.pdf
[2] https://libreboot.org/faq.html#amd
[3] I don't have a good cite handy for this, but Michel Dänzer can
doubtless tell the story with more accuracy and precision than I
can.
[4] ...further discounted reflecting my rather low level of project
activity.


signature.asc
Description: PGP signature

Accepted xtrs 4.9d-2 (source amd64) into unstable

[G. Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 15 Aug 2018 11:59:02 -0400
Source: xtrs
Binary: xtrs
Architecture: source amd64
Version: 4.9d-2
Distribution: unstable
Urgency: low
Maintainer: G. Branden Robinson 
Changed-By: G. Branden Robinson 
Description:
 xtrs   - emulator for TRS-80 Model I/III/4/4P computers
Closes: 905584
Changes:
 xtrs (4.9d-2) unstable; urgency=low
 .
   * debian/control: Bump Standards-Version to 4.0.0.
 + Update debian/patches/make-plain-text-docs-from-html.patch and
   debian/patches/makefile-generate-pdf-manpages.patch to respect "nodoc"
   in DEB_BUILD_OPTIONS.
 .
   * debian/rules: Set DEB_CFLAGS_MAINT_APPEND to "-Wall -Werror".  Set
 DEB_LDFLAGS_MAINT_APPEND to "-Wl,--as-needed".
 .
   * debian/rules: Run upstream "check" target as part of our "check-binary"
 target.
 .
   * debian/rules: Add "maintainer-clean" target to work around the fact that
 some of our patches cause new files to be created, and the package build
 unapplies all the patches without cleaning the build tree.
 .
   * debian/control: Add link to upstream GitHub site in package description;
 thanks, Reiner Herrmann!  (Closes: #905584)
   * debian/control: Tweak English style in package description.
 .
   * debian/README.source: Add material from the Debian Policy Manual's
 upgrading checklist to document my findings regarding this package's
 compliance with it.
 .
   * debian/patches/stop-mkdisk-from-overflowing-buffers.patch:
 + Don't spuriously report test failures if $MKDISK is set to a non-default
   value.
   * debian/patches/ignore-alt-key-events.patch:
 + Update help window to stop documenting Alt key bindings.
   * debian/patches/map-f12-to-shifted-down-arrow.patch:
 + Update help window to document what F12 does now.
   * debian/patches/move-error.c-prototypes-to-new-error.h.patch:
 + Move diagnostic function prototypes into their own header.
   * debian/copyright: Add patch-created error.h file.
   * debian/patches/add-warning-diagnostic-function.patch:
 + A few places in the code were calling error() with "warning:" in the
   argument string, which looked weird.  Make a warn() function for these
   use cases.
   * debian/patches/fix-compiler-warnings.patch:
 + Fix clunky logic in unused variable warning suppression when neither
   SB_SOUND nor HAVE_OSS is #defined.  Don't bother specifying the
   signedness of the ints we use as booleans.  Move declaration of
   sb_address such that it is only present if either SB_SOUND and/or
   HAVE_OSS is #defined.  Add explanatory comment.  Actually throw a
   warning about lack of host system sound support for emulated cassette
   and sound ports only once each.  Don't bother zeroing sb_address after
   issuing said warning.
   * debian/patches/stop-mkdisk-from-overflowing-buffers.patch:
 + Update to resolve GCC 8's stringop-truncation warnings (which
   mysteriously do not appear with debian/rules-driven builds, just with
   manual "make"s).  Get rid of unneeded variable fname_truncated.  Use
   GCC pragmas to suppress remaining instance; add comment explaining that
   we know what we're doing, since we're writing to a static buffer inside
   a struct.
   * debian/patches/fix-stringop-truncation-warning.patch:
 + Issue warning diagnostic if the argument to cmddump -p is too long.
   Swap order of space-padding strncat and forced setting of pdsbuf[8] to a
   null byte.  This persuades GCC that we're ensuring pdsbuf has a string
   terminator.  Use '\0' instead of '\000' as null character escape.
Checksums-Sha1:
 af78b65bce7b23e92bdff4319367160af694de87 1812 xtrs_4.9d-2.dsc
 377bd11ed46bf0bf20858b7e9f01382a00fee5bf 113720 xtrs_4.9d-2.debian.tar.xz
 61118f3baf8e2cb0e36e582cfc133da56074725c 206192 xtrs-dbgsym_4.9d-2_amd64.deb
 9228ee97538e5398a5be9470b591c2c8cd229907 6822 xtrs_4.9d-2_amd64.buildinfo
 296fdca87ff74159943abdcc625ce49f6448491a 371464 xtrs_4.9d-2_amd64.deb
Checksums-Sha256:
 8a136fb45be3f012ded5c919f904bc5e7f4738c7907d01881204ae6d8728a06f 1812 
xtrs_4.9d-2.dsc
 56bd451fbe8d92c7cc54ffd5418c8dfc6625241c37c2a30e68f1fd9e70d23012 113720 
xtrs_4.9d-2.debian.tar.xz
 c2970bb5d542f7b0a9ffd6fceeb4bd0be8cf521b98e6435a1ef7701ed5443393 206192 
xtrs-dbgsym_4.9d-2_amd64.deb
 8cf93042bc1609966f1c84f49913b42b5e90bef2f030d2840ecb03e19eddd7f6 6822 
xtrs_4.9d-2_amd64.buildinfo
 17ed3704913b13c7673453d2fb33045a492f0bee3e785f2844469ddede407e6e 371464 
xtrs_4.9d-2_amd64.deb
Files:
 b7a33e98b438657b9a75ee2c7be5fb60 1812 contrib/otherosfs optional 
xtrs_4.9d-2.dsc
 9c8bd7747c10898e7b580836889d7b53 113720 contrib/otherosfs optional 
xtrs_4.9d-2.debian.tar.xz
 80a4d3f7eff308fd0667191ad1353723 206192 contrib/debug optional 
xtrs-dbgsym_4.9d-2_amd64.deb
 502775bcfd6b66d475d2dcad8ef6c30b 6822 contrib/otherosfs optional 
xtrs_4

Accepted xtrs 4.9d-1 (source amd64) into unstable

[G. Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 08 Aug 2018 03:21:44 -0400
Source: xtrs
Binary: xtrs
Architecture: source amd64
Version: 4.9d-1
Distribution: unstable
Urgency: medium
Maintainer: G. Branden Robinson 
Changed-By: G. Branden Robinson 
Description:
 xtrs   - emulator for TRS-80 Model I/III/4/4P computers
Closes: 511645 757864 767488 835622 859751
Changes:
 xtrs (4.9d-1) unstable; 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)
 .
   * Patches to upstream:
 + trs_imp_exp.c: Turn on the "emtsafe" flag by default, preventing actions
   potentially harmful to the host environment (like removing the user's
   files or running shell commands) from being done within the emulator.
   - xtrs.man: Document the new default.
 + trs_keyboard.c: Map F12 to the TRS-80 shifted down-arrow key.
 + 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.
 + trs_xinterface.c: Write the key binding help to standard error if the
   emulator's X window is too small to hold it.
 + trs_xinterface.c, main.c: Convert the last users of fprintf(stderr, ...)
   to use the functions from error.c.
 + 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.
 + Makefile: Generate and install PDF versions of man pages.
   - debian/xtrs.docs: Ship them, too.
   - debian/control: Promote groff-base build-dependency to full groff, for
 gropdf.
   * 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)
   * 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
 speaking, it doesn't carry a license, I don't want to pester him to put
 one on it, and in any event it updates much more frequently than the xtrs
 software itself.  Finally, I trust people to do web searches, and
 archive.org to stick around, more now than I did 19 years ago.
   * Write doc-base descriptions for the supplementary documentation in
 /usr/share/doc/xtrs.
   * Add check-binary target to debian/rules to aid regression testing.
   * Thanks to Christian Perrier, Hector Oron, Cyril Brulebois, and
 YunQiang Su for taking care of this package during my long absence.
Checksums-Sha1:
 dd71428b33a8e2aa90f8c8f51247dad042a41e33 1812 xtrs_4.

Accepted xtrs 4.9c-4 (source) into unstable

[G. Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 30 Mar 2017 09:20:32 -0400
Source: xtrs
Binary: xtrs
Architecture: source
Version: 4.9c-4
Distribution: unstable
Urgency: medium
Maintainer: G. Branden Robinson <g.branden.robin...@gmail.com>
Changed-By: G. Branden Robinson <g.branden.robin...@gmail.com>
Description:
 xtrs   - emulator for TRS-80 Model I/III/4/4P computers
Closes: 511645
Changes:
 xtrs (4.9c-4) unstable; urgency=medium
 .
   * Makefile: Undefine HAVE_SIGIO.  (Closes: #511645)
   * Update Maintainer full name and email address from the "old me" to the
 "new me".
Checksums-Sha1:
 032f2eedfc1a4d260f0826d3e076cf5e482f37e0 1810 xtrs_4.9c-4.dsc
 f31203ae8c2f1cc8eceb5cb687dad8b4b5731bb1 101820 xtrs_4.9c-4.diff.gz
Checksums-Sha256:
 5f8d4d18df9bc446c257f7cc4f3af2d6d411acbc48241c0969b14b0ded9bf126 1810 
xtrs_4.9c-4.dsc
 6a14a7cd2e815bf77632b230be22640c43e0b30b2c790a916c138d18fe7e4f9a 101820 
xtrs_4.9c-4.diff.gz
Files:
 c21752b27198f31f3ce6677c18623b65 1810 contrib/otherosfs extra xtrs_4.9c-4.dsc
 75efbc8ac0abadc9b766ef1990e0907d 101820 contrib/otherosfs extra 
xtrs_4.9c-4.diff.gz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAljfwuwACgkQaVt65L8G
YkCyzxAAskyuTdd9vUuayR/Cz7CfQ6kAg3sz8W03f3TaNVeC3kLDNAKXc8Bl//Dr
29pDjqek+wVQVEcQH5ZgF08968SSR0X0o2wOcl+ampodBn3sNWNbD9U29XJ5x+Aa
v5+Y5NbGgu9/XNEEdGJ7TR8V/GQe8iu2QtD6q6qXZYWNFCTEcIcAmKQjFVwWOPx0
sZo2ZdKAecIrBCuEBGVJ5KFZvSTxCeTPckRxrU5Uq5jagJ8MjVqX4ebLv6OLRKDM
r7aM9dWfLQYDRS2HLplVS24jVvBTw129uzs6EWa6v7f2X4m37qrVJJgX6SQueqA2
FVL4dWwVuJyRbJIZa/bUIqltdVs634dG84TGDVa5Pb3HUgm8PzxM6XZ2eKphlmN0
rdHDH1B38WqMLJ/yL3ki5/P/7s7XcwkCdASLZiRVEM1R4Fj1fZYk95cL9IUo7H/+
5GVhLWcDmFXuxKZbBT7GFauY+eX6IwfNmFeSStBLP44gZ0SNtLrS9Vf0s/Vk3RBJ
qeWq/5+GjGwIZq0PAKZiwGLZKXuToD5cWKFjg6r0gFoOO7Z+ebfA913A1Moku4kY
2hRh66Rd4NKGfYaDQH3dZKRwPQ8jEenVE30ifawOrrGhhdVBiNRMiai1X4ChAoAh
ubaRl3xRJOnANWg3HQLlNF04gPwgx3YPJcmkJhYVyCLJ1LJLwzU=
=TW2m
-END PGP SIGNATURE-