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/
This has been fixed in 0.28.1 (2022-11-12).
This has been fixed in 0.28.1 (2022-11-12).
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).
Ivan Habunek said: 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: 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. Bug reports are essential for QA. It’s better to advocate for bug reports, not push for their suppression. 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
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). 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. 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.
Package: toot Version: 0.27.0-1 Followup-For: Bug #1041373 X-Debbugs-Cc: debbug.1041373@sideload.33mail.com 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. 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. 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. 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. 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.” Speak for youself please. 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. Github doesn’t like me either. Red herring nonetheless. Who likes who is irrelevent when the Debian procedure gives contributors a choice. Then you would be a reckless maintainer. Nothing is worse for quality than a bug suppressing emotionally hot-headed maintainer.