The “auth” command outputs a banner line followed by an
asterisk-prefixed list of accounts. It’s readable to humans but
requires some extra work to make usable for scripts. A common need is
to see the notifications on all accounts. For that I run:
$ toot auth | awk '/^[*]/{print $2}' | while read acct; do toot notifications -r -u "$acct"; done
The status quo of human-readable output could be beautified at any
point, or perhaps more information could be added to the auth output
in the future. Whenever that changes, it may break scripts and
complicate the above hack to act on all accounts.
So I suggest adding a “--raw” option of sorts to make the awk command
pipe above unnecessary.
i see you reported quite some bugs about toot, and they seem to be mostly enhancement to the tools. You'd have much better luck if you submit them directly upstream, https://github.com/ihabunek/toot/issues, so you can interact directly with the upstream development instead of thru a middle-man (the Debian maintainer). It would be nice if you could report all the issues you opened upstream at the link above and forward (https://www.debian.org/Bugs/server-control#forwarded) the debian bugs to the upstream once. thanks!
Hi +1, that would be ideal, we don't write code for toot or add new features for it in Debian, we package the upstream version, and might carry some bug fixes in the form of patches until they're fixed upstream, but other than that, I suggest filing ideas for improvement on the upstream bug tracker. thanks and keep well!
control: tags -1 upstream * Jonathan Carter 'jcc@debian.org' via 33Mail <sender@mailer1.33mail.com> [2023-07-07 17:34]: I’m not keen on using MS Github. The 2fa system blocks me because the registered email address there forces me to login to an account with a typically broken CAPTCHA. I also have ethical problems with using Microsoft assets. I understand the frustration though. I wouldn’t want your job. I’m glad the Debian BTS gives an easy way to report bugs so they are at least captured somewhere. There are plans to move the toot upstream bug tracker to a more accessible location (Sourceforge). Is there any issue with letting the bugs sit until that happens? I suppose the worst that could happen is they get archived during the wait, but at least they’re still reachable after archiving. I’ve noticed other maintainers being (understandably) reluctant to forward bugs upstream. What can be improved in the Debian BTS? It seems automation is lacking. Shouldn’t there be a simple control signal to the BTS to say “forward this upstream”, and the machinery does the rest? There is a developer tag “upstream”: https://www.debian.org/Bugs/Developer#tags Suppose that tag is applied to the bug reports I submitted. Would it help the management of the bug reports? Perhaps we could use that to tag bug reports waiting to be forwarded so they can be filtered out in searches, and so someone willing and able to use MS assets could perhaps use that tag to query bugs to forward.
I have added the “upstream” tags to a couple bug reports and noticed the search form provides a tag criteria. So if you want to filter out upstream bugs, this link does that: https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;exclude=tags%3Aupstream;package=toot We can also filter out downstream bug reports by including bugs tagged “upstream”: https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;include=tags%3Aupstream;package=toot Perhaps it would be useful to submit just one bug report upstream, call it a meta bug report of sorts, which simply references the link above. Ideally the upstream maintainer would then just leave that bug report open indefinitely and pin it to the top if possible so all upstream users are steered toward browsing upstream bugs in the Debian BTS as well.