Bug#1053978: ITP: golang-github-rodaine-table -- Go CLI Table Generator

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-rodaine-table
  Version : 1.1.0-1
  Upstream Author : Chris Roche
* URL : https://github.com/rodaine/table
* License : Expat
  Programming Lang: Go
  Description : Go CLI Table Generator

 Go package table provides a convenient way to generate tabular output
 of any data, primarily useful for CLI tools.
 .
 Features:
 .
  * Accepts all data types (string, int, interface{}, everything!) and
will use the String() string method of a type if available.
  * Can specify custom formatting for the header and first column cells
for better readability.
  * Columns are left-aligned and sized to fit the data, with customizable
padding.
  * The printed output can be sent to any io.Writer, defaulting to
os.Stdout.
  * Built to an interface, so you can roll your own Table implementation.
  * Works well with ANSI colors (fatih/color
(https://github.com/fatih/color) in the example)!
  * Can provide a custom WidthFunc to accomodate multi- and zero-width
characters (such as runewidth (https://github.com/mattn/go-runewidth))

Reason for packaging:
  * indirect dependency of gh >= 2.36.0
  * direct dependeny of golang-github-microsoft-dev-tunnels (to be packaged)

Re: Hyphens in man pages

[Wookey]

On 2023-10-15 01:30 -0500, G. Branden Robinson wrote:
> At 2023-10-14T20:51:27-0600, Antonio Russo wrote:
> 
> 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.

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. . The reason why it matters is: stuff about hyphen
and minus being different and minus being used in commands and
cut+pasting being important"

Hope that's helpful.

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Re: Hyphens in man pages

[Iustin Pop]

On 2023-10-15 16:08:32, Wookey wrote:
> 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).

At least you're not lazy. I am, so what I did many times is add a
build-depends on pandoc, and write the man page in rst or md. I think
that's a worse solution (pandoc is really heavy), but at least, I don't
have to go back to *roff.

regards,
iustin

Re: Hyphens in man pages

[Andreas Metzler]

On 2023-10-15 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'.
[...]

Hello,

a pretty good guidance[1] is to

use "\-" whenever it refers to option ("-h", --help"), argument ("find
-mmin -2") or something else that is not natural language but something
that might be pasted, like a command-name ("ssh-add" or "dpkg-source")

and "-" everywhere else.

cu Andreas

[1] Well it is "guidance": pasting will work, but there might still be
places in the prose where a dash would be typographically correct. Some
of these typographical conventions are langauage specific. All this
familiar to LaTeX users.
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Hyphens in man pages

[Gioele Barabucci]

On 15/10/23 17:33, Iustin Pop wrote:

At least you're not lazy. I am, so what I did many times is add a
build-depends on pandoc, and write the man page in rst or md. I think
that's a worse solution (pandoc is really heavy), but at least, I don't
have to go back to *roff.


Another option for the members of the lazy club is `podlators-perl`.

The `.pod` syntax is OK, and it is not as heavy a dependency as pandoc.

Regards,

--
Gioele Barabucci

Bug#1054001: ITP: libapp-sdview-perl -- terminal document viewer for POD and other syntaxes

[Ole Peder Brandtzæg]

Package: wnpp
Severity: wishlist
Owner: Ole Peder Brandtzæg 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: libapp-sdview-perl
  Version : 0.13
  Upstream Author : Paul Evans 
* URL : https://metacpan.org/dist/App-sdview
* License : Perl 5
  Programming Lang: Perl
  Description : terminal document viewer for POD and other syntaxes

The App::sdview module implements a terminal-based program for viewing
structured documents. It currently understands POD, some simple Markdown
formatting, and a basic understanding of nroff (for manpages). The
accompanying sdview script runs the App::sdview program, which renders a
structured document to a terminal output, via the less pager.

Why is this package useful/relevant?


I've found reading the documentation of various Perl modules using
sdview to be a very pleasant experience. Obviously, perldoc already
exists for this purpose, but the syntax highlighting sdview offers makes
for a much better reading experience in my opinion.

As the description notes, the support for manpages is quite rudimentary;
in my testing, the manpage for ls renders fine, whereas the manpage of
man itself does not:

⚘ ~ sdview man
Expected (?^u:\
) in /usr/share/man/man1/man.1.gz on line 1 at:
'\" t
 ^

I'm not sure if the package including such unstable features is a
blocker for packaging it; apologies for the noise if so. However, I
believe its POD support is the main selling point.

How do you plan to maintain it?
===

This would be my first Debian package, so I would need a sponsor (and
most likely a bit of mentoring). The Debian Perl Group seems to be a
natural fit for the package, but I would be happy to maintain it on my
own or co-maintain it with them/anyone else.

libapp-sdview-perl does depend on a few other modules (all by the same
upstream author) not presently packaged in Debian, so they would need to
be packaged, too, but I figured I should file this first. They are:

- Object::Pad::FieldAttr::Checked [0]
- Parse::Man [1]
- String::Tagged::Markdown [2]

All the best,
Ole

[0]: https://metacpan.org/dist/Object-Pad-FieldAttr-Checked
[1]: https://metacpan.org/dist/Parse-Man
[2]: https://metacpan.org/dist/String-Tagged-Markdown

Re: Hyphens in man pages

[Russ Allbery]

Wookey  writes:

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

- turns into a real hyphen (­, U+2010).  \- turns into the ASCII
hyphen-minus that we use for options, programming, and so forth (U+002D).

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.

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.

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.

-- 
Russ Allbery (r...@debian.org)  

Re: Hyphens in man pages

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Gioele Barabucci (2023-10-15 17:59:32)
> On 15/10/23 17:33, Iustin Pop wrote:
> > At least you're not lazy. I am, so what I did many times is add a
> > build-depends on pandoc, and write the man page in rst or md. I think
> > that's a worse solution (pandoc is really heavy), but at least, I don't
> > have to go back to *roff.
> 
> Another option for the members of the lazy club is `podlators-perl`.

that is a virtual package provided by perl. What mechanism exactly are you
referring to when mentioning podlators-perl?

> The `.pod` syntax is OK, and it is not as heavy a dependency as pandoc.

When I have to write a new man page I always write POD instead of troff and
then run pod2man on it. I have yet to find something I wanted to put in a man
page that I was unable to express via the POD format.

Another reason I'm a fan of pod2man is, that it's possible to embed POD
documentation into scripts that are not Perl. For example debvm does this and
even though the debvm tools are written in POSIX shell, pod2man is doing the
right thing:

pod2man /usr/bin/debvm-run | man -l -

Thanks!

cheers, josch

signature.asc
Description: 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

[Russ Allbery]

Minor point, but since you posted it

"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).

-- 
Russ Allbery (r...@debian.org)  

Re: Hyphens in man pages

[Gioele Barabucci]

On 15/10/23 19:13, Johannes Schauer Marin Rodrigues wrote:

Quoting Gioele Barabucci (2023-10-15 17:59:32)

On 15/10/23 17:33, Iustin Pop wrote:

At least you're not lazy. I am, so what I did many times is add a
build-depends on pandoc, and write the man page in rst or md. I think
that's a worse solution (pandoc is really heavy), but at least, I don't
have to go back to *roff.


Another option for the members of the lazy club is `podlators-perl`.


that is a virtual package provided by perl. What mechanism exactly are you
referring to when mentioning podlators-perl?


I was referring to `pod2man`, provided by the `podlators` Perl module.

`podlators-perl` is currently provided by `perl` but once upon a time it 
was a standalone package. Old habits. :)


--
Gioele Barabucci

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&T'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&R 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: 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: Bug#1041731: Hyphens in man pages

[Russ Allbery]

"G. Branden Robinson"  writes:

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

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:

\-   Basic Latin hyphen­minus (U+002D) or ASCII hyphen.  This is the
 character used for Unix command­line options and frequently in file
 names.  It is non-breaking; roff will not wrap lines at this
 character.  "-" (without the "\") is a true hyphen in roff, which is
 a different character; some output devices replace it with U+2010
 (hyphen) or similar.

What I was trying to get at but didn't express very well was to include
the specific Unicode code point and to avoid the term "minus sign" because
this character is not a minus sign in typography at all (although it is
used that way in code).  A minus sign is U+2212 and looks substantially
different because it is designed to match the appearance of the plus sign.
(For example, the line is often at a different height.)  I don't know if
*roff has a way of producing that character apart from providing it as
Unicode.

The above also explicitly says that it's non-breaking (I believe that's
the case, although please tell me if I got that wrong) and is more
(perhaps excessively) explicit about distinguishing it from "-" because of
all the confusion about this.

-- 
Russ Allbery (r...@debian.org)  

Re: Bug#1041731: Hyphens in man pages

[Trent W. Buck]

On Sun 15 Oct 2023 17:33:07 +0200, Iustin Pop wrote:
> At least you're not lazy. I am, so what I did many times is add a
> build-depends on pandoc, and write the man page in rst or md. I think
> that's a worse solution (pandoc is really heavy), but at least, I don't
> have to go back to *roff.

FWIW, there are lighter alternatives than pandoc:

pandoc:After this operation, 174 MB of 
additional disk space will be used.
sphinx-doc (sphinx-build -b man):  After this operation, 140 MB of 
additional disk space will be used.
rst2man (python3-docutils):After this operation, 37.6 MB of 
additional disk space will be used.
pod2man (perl):perl is already the newest version 
(5.36.0-9).

I'm not going to bother measuring docbook ;-)

If you are writing manpages by hand, this is an excellent overview:

https://manpages.debian.org/bookworm/manpages/man.7.en.html

See also:

https://www.oreilly.com/library/view/mastering-perl/9780596527242/ch15.html 
(POD)
https://www.docutils.org/docs/user/manpage.html#todo-open-issues


signature.asc
Description: PGP signature

Bug#1054020: ITP: python-certvalidator -- Validates X.509 certificates and paths

[Josenilson Ferreira da Silva]

Package: wnpp
Severity: wishlist
Owner: Josenilson Ferreira da Silva 
X-Debbugs-Cc: debian-devel@lists.debian.org, nilsonfsi...@hotmail.com

* Package name: python-certvalidator
  Version : 0.11.1
  Upstream Contact: Will Bond 
* URL : https://github.com/wbond/certvalidator
* License : MIT/expat
  Programming Lang: Python
  Description : Validates X.509 certificates and paths

Is a Python library that offers functionality for validating X.509 digital
 certificates. It is used to verify the security and integrity of X.509
 certificates, which are widely used in Internet security systems such
 as TLS/SSL, email encryption, and more.
 .
 The certvalidator library performs the following main tasks:
  - Certificate Validation: The library checks the validity of X.509
digital certificates. This includes checking the certificate signature,
expiration date, issuing authority (CA), certificate revocation, and
other important properties.
  -  Chain of Trust: It helps to build and validate the certificate chain,
that is, the sequence of certificates that links a specific certificate
to a trusted certification authority (root CA).
  - CRL (Certificate Revocation Lists) Check: The library checks whether a
certificate has been revoked by querying Certificate Revocation Lists
(CRLs) published by certification authorities.
  - Online Certificate Status Protocol (OCSP) Check: In addition to CRL
checking, certvalidator can check the status of a certificate through
the Online Certificate Status Protocol (OCSP) to determine whether the
certificate is still valid.
  - Custom Expiration Policy: You can configure and apply custom validity
policies to meet specific certificate validation requirements.
  - Extensibility: The library is designed to be extensible and customizable,

Bug#1054021: ITP: golang-github-ffuf-pencode -- Complex payload encoder for golang (library)

[Thiago Andrade Marques]

Package: wnpp
Severity: wishlist
Owner: Thiago Andrade Marques 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: golang-github-ffuf-pencode
  Version : 0.3
  Upstream Contact: Joona Hoikkala 
* URL : https://github.com/ffuf/pencode
* License : MIT
  Programming Lang: GO Lang
  Description : Complex payload encoder for golang (library)

Pencode is a tool that helps you to create payload encoding chains.
It has been designed to be used in automation wherever it is required
to apply multiple encodings to a payload.

This package is dependency of ffuf(2.1.0). I intend to maintain it in go-team.

Bug#1054023: ITP: bluer -- Official BlueZ Bindings for Rust

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: bluer
  Version : 0.16.1
  Upstream Contact: https://github.com/bluez/bluer
* URL : https://github.com/bluez/bluer
* License : BSD-2-Clause
  Programming Lang: Rust
  Description : Official BlueZ Bindings for Rust

  The bluer library provides the official Rust interface to the Linux
  Bluetooth protocol stack /BlueZ.
  Both publishing local and consuming remote GATT services using
  idiomatic Rust code is supported.
  L2CAP and RFCOMM sockets are presented using an API similar to Tokio
  networking.

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

[Gard Spreemann]

On October 16, 2023 2:41:08 AM GMT+02:00, "Trent W. Buck"  
wrote:
>FWIW, there are lighter alternatives than pandoc:
>
>pandoc:After this operation, 174 MB of 
> additional disk space will be used.
>sphinx-doc (sphinx-build -b man):  After this operation, 140 MB of 
> additional disk space will be used.
>rst2man (python3-docutils):After this operation, 37.6 MB of 
> additional disk space will be used.
>pod2man (perl):perl is already the newest version 
> (5.36.0-9).
>
>I'm not going to bother measuring docbook ;-)

I've also found scdoc to be a quite pleasant and very lightweight alternative: 
https://tracker.debian.org/pkg/scdoc

--  Gard