Re: [Savannah-hackers-public] problem with "Enhanced" bug queries in Savannah

[Ineiev]

Hello,

On Fri, Sep 02, 2022 at 04:23:49PM -0500, G. Branden Robinson wrote:
...
> Then, I click open the "Display Criteria" widget, and change the "Browse
> with the" list box control from "Basic" to "Enhanced", because I want to
> filter items by "Planned Release", and even the "Advanced" query
> interface doesn't enable that.  I then click the "Apply" button to
> submit the form.
...

Tracker admins can add custom query types for their tracker. "Enhanced"
in groff bug tracker is such custom query; it includes "Closed on"
both as an output column and as a selection criterion...

[reordered]
> 5. Even if I change the operators from "greater than" to "less than", I
>_still_ get no results.  This is because the "Open/Closed" control is
>still on "Open", and the "close_date_op" filter is still applied.
...

...and when a date field is undefined, it matches no range [0],
so it makes the query unsuitable for browsing items that have never
been closed.

[0] 
https://git.savannah.nongnu.org/cgit/administration/savane.git/tree/frontend/php/include/trackers_run/browse.php?id=8fefb52bdf34a501c56cb403dd225b665050aa4a#n443

> 1. Once the "Enhanced" form has been presented, there's no way via the
>controls on the page to omit them.  The filter always applies.

Correct; this is why various query types exist.

> 2. The dates always default to the current date and the _greater than_
>operator.  This is guaranteed to fail.  No bugs are ever submitted or
>closed in the future.

Good point.

> 3. There's no option in the controls to disable these two filters.

Strictly speaking, there is---for tracker's admins when defining
the query type.

> 6. To really use the filtering-by-date feature, you have to edit the URL
>by hand.  This is tedious.
> 
> 7. Erasing the operator from the chunk of the HTTP GET query doesn't
>work, possibly because there's no empty or null option for the date
>ordering operator.  It defaults to the first item in the list, which
>is "<".  (This appears to be true for both "date_op" and
>"close_date_op".)  You have to remove these chunks entirely.

I don't understand how these are possible.


signature.asc
Description: PGP signature

Re: Bug#1018737: /usr/bin/rst2man: rst2man: .TH 5th field shouldn't be empty

[Alejandro Colomar]

Hi Dmitry,

On 9/5/22 18:42, Dmitry Shachnev wrote:

Hi Alejandro!

On Mon, Aug 29, 2022 at 09:14:26PM +0200, Alejandro Colomar wrote:

Package: python3-docutils
Version: 0.17.1+dfsg-2
Severity: normal
File: /usr/bin/rst2man
Tags: upstream
X-Debbugs-Cc: alx.manpa...@gmail.com, groff@gnu.org, Quentin Monnet 


Hi,

When rst2man has no information to generate the 5th field to the
.TH macro (the one that sets the title line, i.e., the header and
footer of the manual page), it generates it as an empty argument,
that is "".  groff(1) and mandoc(1) have good defaults for the 5th
field of .TH when it is not specified, so that most manual pages
should need to specify it, but to use that default, the field has
to be missing, and an empty argument is an existing argument.


Regarding this bug, upstream wants to know [1] whether omitting the 5th
argument will work with all troff/manpage writers.

I believe it is the case, but can you confirm?


AFAIK, it will work.  The behavior may differ, in that groff(1) and 
mandoc(1) produce a default text, while others may not produce any text 
at all, but it should work.




[1]: https://sourceforge.net/p/docutils/bugs/458/#b7b6

--
Dmitry Shachnev


Cheers,

Alex

--
Alejandro Colomar



OpenPGP_signature
Description: OpenPGP digital signature

Re: Warn about long lines

[Alejandro Colomar]

On 9/5/22 14:51, Dave Kemper wrote:

On 9/5/22, Alejandro Colomar  wrote:

Hmmm, I found it to behave differently from what you say here, but I
can't reproduce it now.  I guess I had some other issue, and that it was
my mistake.


Your environment's setting of LC_CTYPE afftects how grep (and probably
other tools in that pipeline) interprets input, so if you've been
fiddling with that, or using different environments where it's set
differently, that might be the culprit.


The thing is I haven't, AFAICR.  But since I was in the middle of 
several related changes, I might have tested in a state where some other 
fix wasn't applied.


Cheers,

Alex

--
Alejandro Colomar



OpenPGP_signature
Description: OpenPGP digital signature

Re: Warn about long lines

[Dave Kemper]

On 9/5/22, Alejandro Colomar  wrote:
> Hmmm, I found it to behave differently from what you say here, but I
> can't reproduce it now.  I guess I had some other issue, and that it was
> my mistake.

Your environment's setting of LC_CTYPE afftects how grep (and probably
other tools in that pipeline) interprets input, so if you've been
fiddling with that, or using different environments where it's set
differently, that might be the culprit.

Re: 1.23.0.rc1.2875-9c30-dirty: does not prefer its own same-version subprograms?

[Steffen Nurpmeso]

Dave Kemper wrote in
 :
 |On 9/3/22, Steffen Nurpmeso  wrote:
 |> Letting aside that --with[out]-doc was blindly removed
 |
 |This was not done blindly: Ingo posted a lengthy rationale to this
 |list (http://lists.gnu.org/r/groff/2022-04/msg9.html), and invited
 |comment from anyone who wanted to retain the option.  No one spoke up
 |in its favor.

Yes i have read that.  You missed to quote

  Letting aside that --with[out]-doc was blindly removed even though
  i do not really think that so much changes to the involved
  documents happened,

But lenghty is the right word.

 |>   #?0|kent:src$ s-roff -v
 ...
 |>   called subprograms:
 |>
 |>   GNU grops (groff) version 1.22.4
 |>   GNU troff (groff) version 1.22.4
 |>
 |> ^ Finds the programs of the Linux distro's groff variant.
 |
 |You seem to have stumbled across an instance of Savannah #62860:
 |http://savannah.gnu.org/bugs/index.php?62860

Ah yes.  Thanks.  Yes, that seems to be the problem.

I can confirm it is still broken!

 --End of 

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Warn about long lines

[Alejandro Colomar]

Hi Ralph,

On 9/5/22 12:02, Ralph Corderoy wrote:

Hi Alejandro,


If you know a (hopefully trivial) filter that transforms any
multi-byte sequences in exactly the number of bytes that will be
visible (and hopefully those bytes should be similar to the original
UTF-8 content), that would greatly help.

...

tbl man1/memusage.1 \
| eqn -Tutf8 \
| troff -man -t -M ./etc/groff/tmac -m checkstyle -rCHECKSTYLE=3 \
  -ww -Tutf8 -rLL=78n \
| grotty -c \
| col -b -x \
| toplaintext \
| (! grep -n '.\{80\}.' >&2)


I'm unclear on the problem trying to be solved.  grep(1) in a UTF-8
locale already treats a multi-byte UTF-8 sequence for one rune as
matched by ‘.’ which leaves the terminal's escape sequences, but they've
been disabled by grotty's ‘-c’, and over-striking for underlining, dealt
with by col(1).

In other words, what's wrong with

 zcat man7/groff_char.7.gz |
 eqn -Tutf8 |
 troff -man -t -ww -Tutf8 -rLL=78n |
 grotty -c |
 col -pbx |
 (! grep -n '.\{80\}.' >&2)

Does it miss overlong lines or wrongly report a short line as too long?
If so, an example would help target further suggestions.



Hmmm, I found it to behave differently from what you say here, but I 
can't reproduce it now.  I guess I had some other issue, and that it was 
my mistake.  Since now it seems to work correctly, I'll change it to use 
-Tutf8 again, and assume that my problems were just EBCAK.


Thanks,

Alex

--
Alejandro Colomar



OpenPGP_signature
Description: OpenPGP digital signature

Re: Warn about long lines

[Ralph Corderoy]

Hi Alejandro,

> If you know a (hopefully trivial) filter that transforms any
> multi-byte sequences in exactly the number of bytes that will be
> visible (and hopefully those bytes should be similar to the original
> UTF-8 content), that would greatly help.
...
> tbl man1/memusage.1 \
> | eqn -Tutf8 \
> | troff -man -t -M ./etc/groff/tmac -m checkstyle -rCHECKSTYLE=3 \
>  -ww -Tutf8 -rLL=78n \
> | grotty -c \
> | col -b -x \
> | toplaintext \
> | (! grep -n '.\{80\}.' >&2)

I'm unclear on the problem trying to be solved.  grep(1) in a UTF-8
locale already treats a multi-byte UTF-8 sequence for one rune as
matched by ‘.’ which leaves the terminal's escape sequences, but they've
been disabled by grotty's ‘-c’, and over-striking for underlining, dealt
with by col(1).

In other words, what's wrong with

zcat man7/groff_char.7.gz |
eqn -Tutf8 |
troff -man -t -ww -Tutf8 -rLL=78n |
grotty -c |
col -pbx |
(! grep -n '.\{80\}.' >&2)

Does it miss overlong lines or wrongly report a short line as too long?
If so, an example would help target further suggestions.

-- 
Cheers, Ralph.