RfC: New repo for collecting reusable issue support scripts and instructions?
I have a private list of bash and other scripts to support users that opened issues. Should we create a new repo (eg. named "support") to collect those things? It would help - to make it reusable for all of us - make issue support easier by just linking to a script or instructions
What is the nature of these scripts? Can these be used by the users, too? Maybe creating a folder inside the primary repo (e.g.: support, support-scripts, tools, etc.) and putting them there can help. Debian and a couple of other packages have dedicated, CLI based bug report tools. Maybe we can develop something which can take the burden from both parties and accelerate the reporting and diagnose procedures. Happy new year! Cheers, H.
On 28 Dec 2023, at 19:16, BiT dev <python@altfeld-im.de> wrote:
I have a private list of bash and other scripts to support users that opened issues.
Should we create a new repo (eg. named "support") to collect those things?
It would help - to make it reusable for all of us - make issue support easier by just linking to a script or instructions
_______________________________________________ Bit-dev mailing list -- bit-dev@python.org To unsubscribe send an email to bit-dev-leave@python.org https://mail.python.org/mailman3/lists/bit-dev.python.org/ Member address: hakan@bayindir.org
Hello, if you see value (for others) in your scripts then I see it as a good solution to open a new public repo in the bit-team. Maybe be more explicite with the naming. "support-scripts", "bit-helpers", "bit-scripts", "bit-toolbox", just brainstorming. Am 30.12.2023 20:12 schrieb Hakan Bayındır:
report tools. Maybe we can develop something which can take the burden from both parties and accelerate the reporting and diagnose procedures.
Mhm... There is a burden? Really? ;) We do not bother users with stupid markdown created formulas like other projects do. And we do not close issues without comments when they do not fit our expections and do not provide all information we need in the first place. We try to be polite and patience with each reporter. Aren't we not? :D OK, do you see something how we can improve the bug reporting procedure? Kind Christian
On Sat, 2023-12-30 at 22:12 +0300, Hakan Bayındır wrote:
What is the nature of these scripts? Can these be used by the users, too?
The scripts are mostly diagnostic code snippets I add to issue comments instructing the users to execute them and show me the output. It would be great (to save my time and user questions) to not manually construct them for every user and issue but parse the BiT config in ~/.config/backintime/config on the user's side to extract required paths and settings. Example snippets are: # Show system log entries journalctl --since=today | grep -i backintime # Estimate snapshot deduplication by counting the number of hardlinked files in a folder and all its subfolders (recursively): find . \! -type d -links +1 -printf . | wc -c # Test systray icon support: What is the output of this snippet (should be True otherwise the file is corrupted)? cd /usr/share/backintime/common python3 -c "import sys; sys.path.insert(0, '/usr/share/backintime/plugins/'); import systrayiconplugin; p = systrayiconplugin.SysTrayIconPlugin(); import snapshots; s = snapshots.Snapshots(); print(p.init(s))" # Check current Qt5 theme on Wayland: pkexec env QT_QPA_PLATFORM=wayland-egl XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR XAUTHORITY=$XAUTHORITY python3 -c "from PyQt5.QtGui import QIcon; from PyQt5.QtWidgets import QSystemTrayIcon,QApplication; app = QApplication(['']); print('isSystemTrayAvailable: ' + str(QSystemTrayIcon.isSystemTrayAvailable())); print('Theme name: ' + QIcon.themeName()); print('has theme icon <document-save>: ' + str(QIcon.hasThemeIcon('document-save'))); print('themeSearchPaths: ' + str(QIcon.themeSearchPaths())); print('fallbackSearchPaths: ' + str(QIcon.fallbackSearchPaths())); print('fallbackThemeName: ' + str(QIcon.fallbackThemeName()))"
Maybe creating a folder inside the primary repo (e.g.: support, support-scripts, tools, etc.) and putting them there can help.
Yes, I guess this is better than another repo because some scripts could even be used for unit testing (eg. above script to count the number of hardlinks in snapshot folders)
Debian and a couple of other packages have dedicated, CLI based bug report tools. Maybe we can develop something which can take the burden from both parties and accelerate the reporting and diagnose procedures.
Yes, that would be great! What I observe is that diagnostics always is a "ping pong game" and requires me to collect and adapt code snippets, post them to ask the user, the user has problems to execute it or the result is unexpected and I use the next script to ask for more input. This takes my and the user's time and if the user may get bored or reluctant to answer at some point. I have a dream: ;-) A single script that - the user can download and executes just once - collects all required diagnostics information into a file - anonymizes sensitive info like path names The user then just needed to upload the file instead of pasting it into comments (making them lengthy to scroll). We already have the "--diagnostics" option in BiT which currently reports "only" OS, installation and general settings. We could add a the code snippets as bash/shell script or even extend above option (or add another option like "--generate-bug-report-file").
I think integrating the feature into BiT makes sense. The script can be a different executable/script, so knowledgeable users can generate reports without opening up the GUI, and the GUI can call the script and use its output during bug reporting. This will accelerate bug reporting procedure and reduce ping-pong between users and developers a great deal if done correctly. While I can't promise for development help, I can help with testing it. Happy new year, Cheers, H. On 31.12.2023 18:14, BiT dev wrote:
On Sat, 2023-12-30 at 22:12 +0300, Hakan Bayındır wrote:
What is the nature of these scripts? Can these be used by the users, too?
The scripts are mostly diagnostic code snippets I add to issue comments instructing the users to execute them and show me the output.
It would be great (to save my time and user questions) to not manually construct them for every user and issue but parse the BiT config in ~/.config/backintime/config on the user's side to extract required paths and settings.
Example snippets are:
# Show system log entries journalctl --since=today | grep -i backintime
# Estimate snapshot deduplication by counting the number of hardlinked files in a folder and all its subfolders (recursively): find . \! -type d -links +1 -printf . | wc -c
# Test systray icon support: What is the output of this snippet (should be True otherwise the file is corrupted)? cd /usr/share/backintime/common python3 -c "import sys; sys.path.insert(0, '/usr/share/backintime/plugins/'); import systrayiconplugin; p = systrayiconplugin.SysTrayIconPlugin(); import snapshots; s = snapshots.Snapshots(); print(p.init(s))"
# Check current Qt5 theme on Wayland: pkexec env QT_QPA_PLATFORM=wayland-egl XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR XAUTHORITY=$XAUTHORITY python3 -c "from PyQt5.QtGui import QIcon; from PyQt5.QtWidgets import QSystemTrayIcon,QApplication; app = QApplication(['']); print('isSystemTrayAvailable: ' + str(QSystemTrayIcon.isSystemTrayAvailable())); print('Theme name: ' + QIcon.themeName()); print('has theme icon <document-save>: ' + str(QIcon.hasThemeIcon('document-save'))); print('themeSearchPaths: ' + str(QIcon.themeSearchPaths())); print('fallbackSearchPaths: ' + str(QIcon.fallbackSearchPaths())); print('fallbackThemeName: ' + str(QIcon.fallbackThemeName()))"
Maybe creating a folder inside the primary repo (e.g.: support, support-scripts, tools, etc.) and putting them there can help.
Yes, I guess this is better than another repo because some scripts could even be used for unit testing (eg. above script to count the number of hardlinks in snapshot folders)
Debian and a couple of other packages have dedicated, CLI based bug report tools. Maybe we can develop something which can take the burden from both parties and accelerate the reporting and diagnose procedures.
Yes, that would be great!
What I observe is that diagnostics always is a "ping pong game" and requires me to collect and adapt code snippets, post them to ask the user, the user has problems to execute it or the result is unexpected and I use the next script to ask for more input. This takes my and the user's time and if the user may get bored or reluctant to answer at some point.
I have a dream: ;-)
A single script that - the user can download and executes just once - collects all required diagnostics information into a file - anonymizes sensitive info like path names
The user then just needed to upload the file instead of pasting it into comments (making them lengthy to scroll).
We already have the "--diagnostics" option in BiT which currently reports "only" OS, installation and general settings.
We could add a the code snippets as bash/shell script or even extend above option (or add another option like "--generate-bug-report-file").
_______________________________________________ Bit-dev mailing list -- bit-dev@python.org To unsubscribe send an email to bit-dev-leave@python.org https://mail.python.org/mailman3/lists/bit-dev.python.org/ Member address: hakan@bayindir.org
I like the idea of such a repo despite I am not using something like this currently. Maybe name it "support-tools"? Because it is related to "bit-team" organization it is clear that it belongs to BIT.
participants (3)
-
BiT dev -
c.buhtz＠posteo.jp -
Hakan Bayındır