I quite enjoy poking my nose into other peoples issues as it gives me some insight into the problems that they have, what tools are available to extract the relevant information and also gets me digging around the man pages and websites looking for how to fix some of these issues when I invariably cause them on my own machine.
It strikes me that the same toolset is invariably used time and time again (inxi, lsusb and its bretheren, journalctl -b -1 and so forth). Has there ever been any consideration into building a toolkit which a user can run on their machine and have the thing gather all the output, and either present it to them in obviously cut and pasteāable sections or even just upload the entire thing into a pastebin.
I often feel like a bit of a broken record (run this to show us what you really have as hardware, run this to show the logs, etc, etc.) so having it ran as one gathering process might well speed things up a bit.
Given the number of people who post screenshots of text, Iād argue that the searchability of the forum might well go up if you give the end user a way of mass uploading much of the relevant information, even if some of it has go via pastebin due to length restrictions on posts.
Speaking of which, what ARE the length restrictions on a post?
There is another way to use fpaste too, by putting it at the end of say an inxi command - piping it to fpaste I guess (Im on my phine or Id look it up)
We should rejig the fpaste post by Ankur to include that.
Great ideas Steve! Maybe if you write a post with the basic commands you said, we can replace or edit Ankurās pinned post? What do you think @ankursinha ?
FPASTE(1) User Commands FPASTE(1)
NAME
fpaste - manual page for fpaste 0.5.0.0
SYNOPSIS
fpaste [OPTION]... [FILE]...
DESCRIPTION
Send text file(s), stdin, or clipboard to the Fedora community pastebin at https://paste.centos.org and return the URL.
It is often useful to be able to easily paste text to the Fedora Pastebin at http://paste.fedoraproject.org and this simple utility will do that and return the resulting URL so that people may exā
amine the output. This can hopefully help folks who are for some reason stuck without a graphical interface, working remotely, or any other reason they may be unable to paste something into the
pastebin using a web browser.
Examples: fpaste file1.txt file2.txt dmesg | fpaste (prog1; prog2; prog3) | fpaste fpaste --sysinfo --confirm fpaste -t "debug output" -l python foo.py
OPTIONS
--version
show program's version number and exit
-h, --help
show this help message and exit
paste.fedoraproject.org Options:
-t "TITLE", --title="TITLE"
title of paste; defaults to UNTITLED
-a "AUTHOR", --author="AUTHOR"
author name; empty by default
-r PRIVATE, --private=PRIVATE
make paste private; defaults to 1
-l "LANGUAGE"
language of content for syntax highlighting; default is "text"; use "list" to show all 239 supported langs
-x LIFE
life of paste in minutes; default is 1 day (maximum)
Input/Output Options:
-i, --clipin
read paste text from current X clipboard selection [requires: xsel]
-w, --wayland-clipin
read paste text from Wayland selection [requires the wl-clipboard package]
-o, --clipout
save returned paste URL to all available clipboards
--input-selection=CLIP
specify which X clipboard to use. valid options: "primary" (default; middle-mouse-button paste), "secondary" (uncommon), or "clipboard" (ctrl-v paste)
--fullpath
use pathname VS basename for file description(s)
--pasteself
paste this script itself
--sysinfo
paste system information
--sysinfo-short
paste shortened system information
--audioinfo, --sysinfo-audio
paste general audio information
--videoinfo, --sysinfo-video
paste general video information
--diskinfo, --sysinfo-disk
paste general disk information
--netinfo, --sysinfo-net
paste general network information
--dnfinfo, --sysinfo-dnf
paste repository and package information
--pci-verbose, --sysinfo-pci-verbose
paste verbose pci information
--usb-verbose, --sysinfo-usb-verbose
paste verbose usb information
--btrfsinfo, --sysinfo-btrfs
paste btrfs related system information
--printonly
print paste, but do not send
--confirm
print paste, and prompt for confirmation before sending
--raw-url
print raw url
EXAMPLES
Paste file foo.txt at paste.fedoraproject.org
fpaste foo.txt
Paste output of ifconfig to paste.fedoraproject.org with description "my network config"
ifconfig | fpaste
Paste mycode.py to paste.fedoraproject.org with description as "problem with foo" and language "python"
fpaste -l python mycode.py
Paste mouse-selected text from the primary X selection clipboard, and then overwrite the same clipboard with the returned fpaste URL
fpaste -io
To manually paste clipboard contents, run fpaste without file arguments so that it waits for input, then paste using mouse middle-click, <Ctrl-V>, or other, then press <Enter> followed by <Ctrl-D> to finā
ish (EOF).
To paste the output of more than one program and/or file at a time, use the following example forms:
(lsusb ; lspci) | fpaste
fpaste <(lsusb) <(lspci)
fpaste <(fdisk -l) /etc/grub.conf
(fdisk -l ; cat /etc/grub.conf) | fpaste
(uname -a ; yum repolist) | fpaste
Gather and paste various information about the running system. The info collected should be practically anonymous, and you may use the --printonly or --confirm options to preview what would be sent.
paste.fedoraproject.org URLs are also practically anonymous ([a-zA-Z0-9]**4 == 14,776,336 combinations), so you may also preview it instead before giving the link out.
fpaste --sysinfo
fpaste --sysinfo --confirm
fpaste --sysinfo --printonly | less
BUGS
Report bugs to: https://pagure.io/fpaste/new_issue
or to: Jason 'zcat' Farrell <farrellj AT gmail DOT com> and Ankur Sinha 'FranciscoD' <ankursinha AT fedoraproject DOT org>.
AUTHOR
Fedora Unity
fpaste 0.5.0.0 August 2024 FPASTE(1)
You know, I had a feeling that Iād read something which basically stated it was a tool to easily send stuff to a pastebinā¦ which was evidently me reading the description and then entirely failing to read the rest of the man page.
Iāll ignore the fact that thereās a blindingly obvious pinned post all about fpaste and what it does becauseā¦ bloke, something, something, never read instructions, etc.
Iāve pulled together a small list of āstuff Iāve found usefulā but thereās overlap between some of those utilities so I need to stick it all in a matrix and work out whatās the best version for each piece of information so that the overlap is minimised.
All I actually wanted to do was to fork fpaste, update the man page and fire in a pull request.
Iāve now been into pagure, Iāve created ssh keys and all kinds of faffing about trying to work out why git push refused all attempts at authentication before I read the packaging documents and realised thereās way more to this than I realised. I now have fedpkg, mock and a load of other stuff Iāve never heard of to learn.
On the plus side, if I ever get it working building packages working Iāve updated the stuff I found which was out of date in the manpageā¦
No need to learn all that now You can file a bug with the fpaste developers and they can do that (hopefully). Find out where the upstream fpaste lives, and file the bug there.
If you put the updated info into a txt doc for them it will make it easy.
Sure, all improvements are always welcome. I merged the PR on GitHub now. I can cut a minor release, or if people have more improvements planned, I can wait to include those too.
(Weāll probably move off Pagure to Forgejo if thatās an option. Otherwise, the GitHub mirror will continue to exist for contributors and Iāll keep it in sync.)
I was going to add a section for powertop reporting, but it requires sudo/run0 access to execute it seems. Wasnāt sure if calling sudo binaries from within the script was discouraged or whether there was a preferred way to do it, so Iāve been in decision paralysis for a few days thinking about it.
Do we care about sudo binaries being called or is it a case of elevation if needed and warn the user about it
Iām simply the current maintainer, the original script predates me by a number of years
We can include those commands with a separate flag perhaps and document that they need fpaste to be run as sudoāwe could even include a check where if it wasnāt run as sudo, weād print out a message to the user informing them?
(Generally, we donāt want to run it as sudo because it may worry usersāwho are not expected to read the script to confirm that weāre not doing anything malicious. So the main functionality should perhaps run without sudoāit also ensures that users that may not have sudo access can also generally use it.)
Aye - this was why I was in a state of indecision. Iāll add in the powertop stuff alongside some text to inform the user and given them a chance to bail out if they want.
Iād prefer encouraging users to find a filter that isolates relevant journal entries (messages?). It can be useful to add your own messages (# echo MESSAGE > /dev/kmsg) to the journal, e.g., to note that some problematic USB device is about to be connected so you can jump to the time of interest.
It is clear that requests for inxi and journalctl output will be the first encounter with the command line for some users, and that reading man pages or other documentation is also a novel experience.
In workshops introducing participants with no previous Linux experience to some specialized software written for POSIX command-line environments, we found it important to spend an afternoon with the LinuxCommand book. These days I suspect many users would find YouTube videos helpful, but I havenāt looked for good examples.
I should also note that the number of mistakes made by users can be greatly reduced if they adopt a ābuddy systemā where the buddy checks the commands for typos before they are run.
In an Ideal world, me too. Sadly, itās not an ideal world, and thus the next best thing is to re-write it all in rust. Failing that, make error collection better.
Then make error collection better again because itās always crap.
Then train all the LLMās that users trust implicitly to be only trained on the correct answers to collections of questions posed by other users.
May have had a bottle or two of wine. It should still all be re-written in rust thoughā¦
You can file a bug with the fpaste developers and they can do that (hopefully). Find out where the upstream fpaste lives, and file the bug there.