Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1154719 > unrolled thread

Bug#1041373: toot: posts cannot begin with a hashtag

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1041373: toot: posts cannot begin with a hashtag debbug.toot@sideload.33mail.com - 2023-07-18 09:10 +0200
    Bug#1041373: toot: posts cannot begin with a hashtag "Ivan Habunek" <ivan@habunek.com> - 2023-07-18 09:10 +0200
      Bug#1041373: toot: posts cannot begin with a hashtag Sandro Tosi <morph@debian.org> - 2023-07-18 09:40 +0200
        Bug#1041373: toot: release notes overlooked debbug.1041373@sideload.33mail.com - 2023-07-18 15:50 +0200
          Bug#1041373: toot: release notes overlooked Sandro Tosi <morph@debian.org> - 2023-07-18 18:10 +0200
            Bug#1041373: toot: bug suppression must be thwarted debbug.1041373@sideload.33mail.com - 2023-07-18 22:10 +0200

#1154719 — Bug#1041373: toot: posts cannot begin with a hashtag

Package: toot
Version: 0.27.0-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.toot@sideload.33mail.com

When posting from the commandline, if -e is used then a template
states that lines beginning with a hash (“#”) are ignored. This is a
problem because it’s very often useful to begin a line with a
hashtag. It’s in fact common to write just hashtags on the last line
of a message.

It’s unclear¹ why users would want to put comments in a temporary text
file that will be destroyed right after posting, but certainly a hash
symbol should be avoided. Possible alternatives:

  % LaTeX and Erlang comments go from percent symbol to EOL
  /* comments in C, graphviz and many other languages² begin with forward slash asterisk and end with */
  // C++ comments go from // to EOL
  -- Ada comments go from -- to EOL
  ; Forgot where I’ve seen this but some app’s comments go from semicolon to EOL
  <!-- HTML comments begin with left angle bang 2 hyphens and end with -->
  [//]: # (markdown comments are complicated)

Considering some simplified subset of HTML is specified for
activitypub posts, HTML comments may be the most suitable.

Possible other bugs:

I’ve only identified this bug in the CLI version specifically in
conjunction with using an editor. I have not tested what happens to
lines beginning with hash when the text body is supplied on the
commandline, or what happens in the TUI. If the pure non-interactive
CLI approach is affected, then it would be a bug that the man page
does not cover it.

footnotes:

① implementation of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038664 would make comments more useful
② https://web.archive.org/web/20230301231734/geekflare.com/how-to-add-comments/

[toc] | [next] | [standalone]

#1154720

On Tue, 18 Jul 2023, at 08:58, debbug.toot@sideload.33mail.com wrote:
> Package: toot
> Version: 0.27.0-1
>
> When posting from the commandline, if -e is used then a template
> states that lines beginning with a hash (“#”) are ignored. This is a
> problem because it’s very often useful to begin a line with a
> hashtag. It’s in fact common to write just hashtags on the last line
> of a message.

This has been fixed in 0.28.1 (2022-11-12).

-- Ivan

[toc] | [prev] | [next] | [standalone]

#1154724

> On Tue, 18 Jul 2023, at 08:58, debbug.toot@sideload.33mail.com wrote:
> > Package: toot
> > Version: 0.27.0-1

this is the version in oldstable, it's probably time to upgrade to
something newer, which hopefully will stop this stream of bug reports
that do not belong to the debian tracking system (as mentioned before already).


> >
> > When posting from the commandline, if -e is used then a template
> > states that lines beginning with a hash (“#”) are ignored. This is a
> > problem because it’s very often useful to begin a line with a
> > hashtag. It’s in fact common to write just hashtags on the last line
> > of a message.
>
> This has been fixed in 0.28.1 (2022-11-12).
>
> -- Ivan
>


--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

[toc] | [prev] | [next] | [standalone]

#1154763 — Bug#1041373: toot: release notes overlooked

Package: toot
Version: 0.27.0-1
Followup-For: Bug #1041373
X-Debbugs-Cc: debbug.1041373@sideload.33mail.com

Ivan Habunek said:

> This has been fixed in 0.28.1 (2022-11-12).
> 
> -- Ivan

Thanks Ivan. I searched for this bug both in Github and in the Debian
BTS and found nothing prior to filing the report, but I did not review
the release notes. Sorry about that.  In attempt to improve my own
procedure, I found the Debian release notes here:

  https://metadata.ftp-master.debian.org/changelogs//main/t/toot/toot_0.34.1-1_changelog

They neglect to mention the fix, which is documented here:

  https://github.com/ihabunek/toot/releases?page=2

In the future, I will try to remember to check both sets of release
notes (Debian & upstream) before filing.

Since the upstream release notes are made available, the Debian policy
suggests that maintainers to include them in the distro release notes.
So I have submitted a separate (downstream) bug report for this but it
has not yet been assigned a number.

------------------------------

Sandro Tosi said:

> this is the version in oldstable, it's probably time to upgrade to
> something newer,

Perhaps eventually. I appreciate the information. But it’s important
to realize that upgrading a whole Debian system is not to be taken
lightly. People like myself keep various quite fragile pkgs on
life-support which are easily broken in upgrades. I’ve seen the havoc
and catastrophe dist upgrade can cause. Risks often far outweight the
benefits particularly in this case. It also requires having high-speed
unlimited broadband access. Sometimes either a hot site or cold site,
backups, roll-back contingencies, etc. It’s a big deal. The
undertaking would a crazy remedy to the bug herein, or for anything
toot related for that matter.

Most importantly: oldstable is still officially supported for another
year¹ from now.

> which hopefully will stop this stream of bug reports

Bug reports are essential for QA. It’s better to advocate for bug
reports, not push for their suppression.

> that do not belong to the debian tracking system (as mentioned
> before already).

Please read the “Don't file bugs upstream” section of the bug
reporting procedure².

Footnotes:

① https://wiki.debian.org/DebianReleases
② https://www.debian.org/Bugs/Reporting#filedalready

[toc] | [prev] | [next] | [standalone]

#1154780 — Bug#1041373: toot: release notes overlooked

> Most importantly: oldstable is still officially supported for another
> year¹ from now.

yet you wont receive any updates and instead you spam the debian bug
tracking system with "reports" that are just noise (like this one,
since it's fixed upstream).

> Bug reports are essential for QA. It’s better to advocate for bug
> reports, not push for their suppression.

if i go in a bakery and scream "my chair broke, i want a new one!" it
serves no one purpose. You need to submit the requests in the right
place for the right people to act on.

> > that do not belong to the debian tracking system (as mentioned
> > before already).
>
> Please read the “Don't file bugs upstream” section of the bug
> reporting procedure².

yeah which you conveniently omitted to report the big `if` before
hand: "If you file a bug in Debian, don't send a copy to the upstream
software maintainers yourself" -- what we are telling you is to NOT
file these bugs at all in the debian bts, but directly upstream. you
dont like github? it's sucks for you, it doesnt mean we are happy to
accept your dubious quality reports.

If i were the maintainer of this package, i'd bulk close all your
report and invalid and ask the BTS maintainer to temporarily ban you
from submitting more.


--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

[toc] | [prev] | [next] | [standalone]

#1154819 — Bug#1041373: toot: bug suppression must be thwarted

Package: toot
Version: 0.27.0-1
Followup-For: Bug #1041373
X-Debbugs-Cc: debbug.1041373@sideload.33mail.com

> yet you wont receive any updates

There are countless factors in determining the version that best
serves any particular user. It is not for you to decide or control
what version a user runs. When you suggest that users upgrade their
whole system in order to run a more recent version of a social media
app to overcome a trivial flaw, this is reckless advice. You need to
understand that every package has dependencies. Those version
dependencies either support or break other packages. Every dist
upgrade results in gains /and losses/. You cannot competently
prescribe arbitrarily to all users that they “chase the shiny” at all
costs. It’s an absurdity to impose this on others most particularly
when they are still running officially supported versions.

> and instead you spam the debian bug tracking system with "reports"
> that are just noise (like this one, since it's fixed upstream).

You’ve misidentified the problem. The problem was not with the version
I was running; it’s that I did not check the release notes
first. Please re-read my message from the top. I admitted to that
error which AFAIK only involves bug 1041373, not the others.

Users can run a range of different officially supported versions and
the Debian BTS is rightfully designed to accommodate this.

> if i go in a bakery and scream "my chair broke, i want a new one!"
> it serves no one purpose.

The misunderstanding here is that you think I am an individual looking
for personalized support. The bugs I have reported are *community*
bugs. So the /fallacy of analogy/ here is that you say “my” chair
broke, when in fact it’s a community resource that broke. By
extension, community bug reports serve the community, not the
individual.

In fact the individual bug submitter finds workarounds because bugs
are not fixed overnight and a Debian user won’t often see the change
for years out. By the time the lifecycle of the bug runs its course,
any benefit to the original submitter is marginal since their
workaround or alternate workflow is already established. The
beneficiaries of fixes are future users.

> You need to submit the requests in the right place for the right
> people to act on.

The “right place” differs from one user to the next. It is walled
gardens who decide who may enter, not users who decide whether a
walled garden must serve them. Often there is no “right place” for a
given user. Some bugs go entirely unreported because of obnoxious
CAPTCHAs or surveillance capitalist MitMs. Yes it’s clear that you’re
a gmail pawn but try not to view everyone through the “surveillance
capitalism is fine for everyone” lens. That’s not for you to control.

Users will contribute bug reports wherever they /can/. It’s rightfully
their choice. Demanding that voluntary contributors bend to your needs
is quite obnoxious.

> yeah which you conveniently omitted to report the big `if` before
> hand: "If you file a bug in Debian, don't send a copy to the upstream
> software maintainers yourself"

I simply pointed you to the whole document. How can that be an
omission?  The only omission I see is in your cherry picked requoting
of the doc, which omitted:

  “If necessary, the maintainer of the package will forward the bug
   upstream.”

> -- what we are telling you

Speak for youself please.

> is to NOT file these bugs at all in the debian bts, but directly
> upstream.

On what authority do you believe you can override the bug reporting
procedure document?  Clearly the policy you were shown gives
contributors a choice. If you don’t like that, it’s on you to change
it. This is not the appropriate place for that.

> you dont like github?

Github doesn’t like me either. Red herring nonetheless. Who likes who
is irrelevent when the Debian procedure gives contributors a choice.

> If i were the maintainer of this package, i'd bulk close all your
> report and invalid and ask the BTS maintainer to temporarily ban you
> from submitting more.

Then you would be a reckless maintainer. Nothing is worse for quality
than a bug suppressing emotionally hot-headed maintainer.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web