Knowledge Base

Preserving for the future: Shell scripts, AoC, and more

Devuan Ceres and zenity that uses gtk3

I tend to use zenity for my basic dialog needs, and sometimes yad. I found out recently that zenity now looks like a child drew it (read: the GNOME people use it) instead of showing a real dialog box.

So after some poking around, I found out that I cannot just purge it: Steam depends on zenity, and that zenity now (as of version 4.0.0-1) depends on libgtk-4-0. So, I found using one of the more helpful Debian web pages which version of zenity still uses gtk3: 3.44.2-1.

So I whipped up an Open Build Service project for zenity, but of course due to the ridiculous usrmerge problems Debian has introduced (and SUSE doesn't show any knack or willingness to fix on their behalf; can you blame them?!) the project doesn't build.

So I built it myself and host it on my own internal package repository. And then I updated my set-my-repos.sh script with 2 new lines. Thankfully I wrote a function I can call again.

confirm_preferences "all" "zenity" "zenity" "release" "600" "3.44.2-1"
confirm_preferences "all" "zenity-common" "zenity-common" "release" "600" "3.44.2-1"

Which if you don't bother to click through to that previous post, makes two files on a system where you run the script:

# file /etc/apt/preferences.d/zenity
Package: zenity
Version: 3.44.2-1
Pin: release
Pin-Priority: 600
# file /etc/apt/preferences.d/zenity-common
Package: zenity-common
Version: 3.44.2-1
Pin: release
Pin-Priority: 600

Perhaps I should have forked the package and given it a higher version, and figured how to enforce the same version. The d/control already has Depends: zenity-common (= ${source:Version}) but somehow it doesn't take effect; I was able to install zenity=3.44.2-1 but it kept my zenity-common=4.0.0-1 which failed, because gtk4 changes the paradigms of gtk so much that they got rid of the /usr/share/zenity/ directory with its xml-defined ui (glade?) business.

Fluxbox handle capslock media keys

VLC lets you configure global hotkeys, so you can map your XF86AudioPrev and related keys. However, when my Capslock is on, my keyboard sends different keycodes. Here's my fix for that.

I wrote a shell script to handle the logic.

files/2024/listings/vlc-command (Source)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
#!/bin/sh
# Startdate: 2024-01-01-2 14:36
# Purpose: to be a hotkey target for when CapsLock is on but I still press "Play/Pause" media button on the keyboard.
# Usage:
#    In ~/.fluxbox/keys:
#    # For capslock, media previous, pause, skip
#    171 :Exec bin/vlc-command skip
#    172 :Exec bin/vlc-command play-pause
#    173 :Exec bin/vlc-command previous

case "${1}" in
   "play-pause")
      dbus-send --type=method_call --dest=org.mpris.MediaPlayer2.vlc /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.PlayPause
      ;;
   "previous"|"back"|"left")
      dbus-send --type=method_call --dest=org.mpris.MediaPlayer2.vlc /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.Previous
      ;;
   "next"|"skip"|"right")
      dbus-send --type=method_call --dest=org.mpris.MediaPlayer2.vlc /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.Next
      ;;
esac

And then in my ~/.fluxbox/keys file I added these statements:

# For capslock, media previous, pause, skip
171 :Exec bin/vlc-command skip
172 :Exec bin/vlc-command play-pause
173 :Exec bin/vlc-command previous

I derived these of course with xev(1).

Errata

And the reason I sometimes end up with capslock on is I always use capslock to help wake on a monitor. I thought it was an XKCD comic that pointed out that Windows admins would use Ctrl+Alt+Delete to wake up a system, and that by default that reboots a Linux system, so when I have switched over to using all-Linux years ago, I use other methods (Capslock) to see if a system is awake/locked.

Undocumented feature of update-repo

In my newly improved apt-based update-repo function, there is a neat feature I failed to describe elsewhere.

Because the function looks for files in /etc/apt/sources.list.d/ that match glob ${NAME}.list, you can run update-repo with:

update-repo ../sources

And it will update the normal Devuan repositories. I really should have put that in the documentation somewhere. Well, here it is now.

Improved update-repo for apt

I've updated my update-repo command for Debian-based distros, to display the available packages to update from the targetted repository. Also, I've adjusted the autocomplete to handle colons in the filenames, e.g., /etc/apt/sources.list.d/file:name.list. It will need to escape a colon with a slash, but accomplish what you want.

I updated this because my update-repo for rpm-based distros already shows the available updates.

# File: /usr/share/bgscripts/bashrc.d/debian.bashrc
# update-repo command for apt-get update just one repository
update-repo() {
   for source in "$@"; do
      sudo apt-get update -o Dir::Etc::sourcelist="sources.list.d/${source}.list" \
         -o Dir::Etc::sourceparts="-" -o APT::Get::List-Cleanup="0"
      sudo apt-get -u upgrade -V --assume-no -o Dir::Etc::sourcelist="sources.list.d/${source}.list" -o Dir::Etc::sourceparts="-" -o APT::Get::List-Cleanup="0" | sed -n -r -e "/=>/s#^#${source}: #p;"
   done
}
# autocomplete for update-repo
_ppa_lists() {
   local cur
   _init_completion || return
   COMPREPLY=( $( find /etc/apt/sources.list.d/ -name "*${cur}*.list" \
      -exec basename {} \; 2>/dev/null | sed -r -e 's!\.list$!!;' -e 's/:/\\:/g;' 2>/dev/null ) )
   return 0
} &&
complete -F _ppa_lists update-repo

References

Weblinks

  1. package management - apt-get update only for a specific repository - Ask Ubuntu

Fedora sshd_config locale

Devuan includes this by default, but Fedora does not. There's probably good reasons. I'll take "Upstream doesn't package it that way" as a good reason!

files/2023/12/listings/allow-ssh-locale.sh (Source)

#!/bin/sh
# Startdate: 2023-12-14-5 10:17
# Reference:
#    https://stackoverflow.com/questions/29609371/how-not-to-pass-the-locale-through-an-ssh-connection-command
# Documentation:
#    Not needed for Devuan because this AcceptEnv is already in the default file sshd_config
tf="/etc/ssh/sshd_config.d/30-locale.conf"
test ! -f "${tf}" && touch "${tf}"
grep -qE '^AcceptEnv.*LC_\*' "${tf}" 1>/dev/null 2>&1 || {
   printf "%s\n" 'AcceptEnv LANG LC_*' >> "${tf}"
   systemctl reload sshd
}