A package update notifier?

johnraff · 2023-04-25 09:48:30

johnraff wrote:

One thing I haven't figured out is how to close the icon once the terminal has done its work. I don't want to have to close it separately.

It was doable, but quite complicated. The menu item for the terminal is 'x-terminal-emulator -e <do stuff>' but yad seems to have no way to run a second command after that one has run. Ideal would be to be able to add 'quit', but instead the icon just sits there, and if you click "Show Available Upgrades" again it throws up another terminal...

First thing I tried was run a second process: the same script with a --show-upgrades option. That runs OK but the calling script still doesn't exit. What eventually worked was yad's --listen option. Use the second process to put up the terminal, then send a 'quit' command to the original process which is controlling yad, via a pipe.

From here: https://sourceforge.net/p/yad-dialog/wi … ationIcon/

It might be a simpler way would be to fork off yad with a final & but anyway for now this seems to work (still waiting for an upgrade to come in to test it for real):

#!/bin/bash

on_exit() {
    echo "quit" >&3
    rm -f "${PIPE}"
    rm -rf "${PIPE%/*}"
    exec 3>&-
}
trap on_exit EXIT

if [[ $1 = '--show-upgrades' ]]
then
    PIPE="$2"
    [[ -p "$PIPE" ]] || { echo "${0}: there is no fifo $PIPE" >&2 ; exit 1;}
    exec 3<> "$PIPE"
    x-terminal-emulator -T 'Available Package Upgrades' -e sh -c 'printf "%s\n" "Available upgrades:"; apt list --upgradeable; printf "\n%s\n\n"  "Held packages:"; apt-mark showhold; bash;'
    exit
fi

dir=$(mktemp --tmpdir --directory "${0##*/}".XXXXXXXX) || { echo "${0}: could not make temp dir" >&2 ; exit 1;}
PIPE="${dir}/yadpipe"
mkfifo "$PIPE" || { echo "${0}: could not make fifo $PIPE" >&2 ; exit 1;}
exec 3<> "$PIPE"

num_upgrades=$(( $( apt list --upgradable 2>/dev/null | wc -l ) - $( apt-mark showhold | wc -l ) -1 ))
script="$( readlink -f "$0" )"
if (( num_upgrades > 0 )); then
    notify-send  -t 15000 --urgency low "$num_upgrades Upgrades(s) Currently Available"
    yad --notification --listen --image="software-update-available" \
    --text="Package Upgrades - Right-Click For Options" \
    --menu="Show Available Upgrades!\"$script\" --show-upgrades \"$PIPE\"!applications-other|Quit!quit!application-exit" \
    --command="notify-send  -t 15000 --urgency low '$num_upgrades Upgrades(s) Currently Available'" <&3
fi

EDIT: made some improvements, though it might be better done exporting variables and functions instead of calling the script twice. That's if we don't ultimately go with package-update-indicator...

Last edited by johnraff (2023-04-27 03:05:06)

sleekmason · 2023-04-25 14:09:24

Nicely done @johnraff. I've been using two separate methods to provide a little variety. The one I posted here yesterday as a button update check from a tint2 menu, and then for an automatic timer version I've been using a tint2 executor that shows an icon color change and a notification when updates are available. Both work just fine for what they are, but neither are ideal.
I am really digging what you have going on above. Much cleaner in the end. Looking forward to an update to try your script out properly. Glad you took the time to check it all out. Should be a cool little addition in one way or another.

deleted0 · 2023-04-25 14:19:11

Looks like you guys have it well in hand. I just ran across this, so I'll share.

https://code.guido-berhoerster.org/proj … indicator/

8bit

sleekmason · 2023-04-25 15:27:11

^ lol But of course!

Cracks me up how a solution seems to almost always appear after the fact. If it works as advertised, we'll have yet another option. I should probably try it to see what shakes out.

deleted0 · 2023-04-25 15:45:20

^ It's icon in the tray is a bit too large.

Boot Xebian and see it in action.
Xfce-4 on Sid, interesting.
https://xebian.org/

8bit

johnraff · 2023-04-26 01:28:50

eight.bit.al wrote:

Looks like you guys have it well in hand. I just ran across this, so I'll share.
https://code.guido-berhoerster.org/proj … indicator/
8bit

I referred to package-update-indicator a couple of days ago: https://forums.bunsenlabs.org/viewtopic … 68#p127268 but there was no reaction at that time.

I've been using it for a couple of weeks now and it works well. The icon it throws up for me is the exact same one @sleekmason chose for the yad notifier "software-update-available" and with the Papirus icon theme fits in fine.

The only reason I was looking for a home-brewed alternative is that it depends on packagekit and on my Bookworm VM wanted to pull in a long list of packages. (That and a bit of RAM because it runs all the time.) I forgot to exclude Recommends though; now with --no-install-recommends it's not bad at all:

sudo apt --no-install-recommends install package-update-indicator

The following additional packages will be installed:
  libpackagekit-glib2-18 packagekit
Recommended packages:
  gnome-package-updater packagekit-tools
The following NEW packages will be installed:
  libpackagekit-glib2-18 package-update-indicator packagekit
0 upgraded, 3 newly installed, 0 to remove and 1 not upgraded.
Need to get 760 kB of archives.
After this operation, 3,664 kB of additional disk space will be used.

So that remains an alternative, yes.

Right, of course the icon depends on your theme, and with the Material-Solarized-Suru++ I'm trying now in the VM, yes it is a bit big and intrusive. With Papirus on Beryllium the no-updates-available status icon is black and almost invisible.

Last edited by johnraff (2023-04-26 02:20:33)

johnraff · 2023-04-26 01:36:19

With the home-grown version, the question of how to install a systemd user timer from a package, or alternatively trigger a user script from a systemd system timer, remains. I was worrying about this point from the beginning - the two worlds are separate. Will do a bit of websearching, or maybe just use package-update-indicator, which isn't hugely bulky.

An advantage of homespun is that we can tweak things at will. Like, some people (eg me) might prefer to have the terminal window, with the info and a bash prompt, pop up right away when there are updates, without having to click an icon. Could be configurable.

Last edited by johnraff (2023-04-26 01:40:13)

johnraff · 2023-04-26 02:19:55

On the VM, with package-update-indicator's "Command for installing updates" set to:

x-terminal-emulator -T 'UPDATES' -e sh -c 'echo "Available upgrades:"; apt list --upgradeable; echo; echo "Held packages:"; apt-mark showhold; bash;'

Just now, the icon showed updates available, and clicking "Install updates" I got this:

So user can now run 'sudo apt upgrade', or whatever action they see fit.

sleekmason · 2023-04-26 02:28:32

Package-update-indicator might be a good backup, but i'm thinking our local script will be awesome. I agree with wanting to be able to make adjustments at will. It's just a neat little script.

johnraff · 2023-04-26 06:54:18

Now playing with setting up the systemd user timer in a Debian package.
If it works OK then we're almost ready to roll!
If...

sleekmason · 2023-04-26 16:19:55

@johnraff, As near as I can tell, the corrected/last version of the script above is calling the icon when the count is 0, and not if there are packages. Maybe it is reversed for testing purposes?

Last edited by sleekmason (2023-04-26 16:23:49)

johnraff · 2023-04-27 03:06:00

^oops yes that's exactly what was happening. Now fixed, thanks!

sleekmason · 2023-04-27 04:24:01

So far so good. Building with all of this included to test with the next updates.

For the systemd user timer, it appears it only needs to be enabled once and it will continue through reboot?

Does removing ~/.config/systemd/user/timers.target.wants kill the script as well? Or what command would you advise should be used to shut the script/timer down properly for an on/off switch?

I really dig it.

Last edited by sleekmason (2023-04-27 04:25:19)

johnraff · 2023-04-27 05:03:17

^Use the systemd commands (forget where I copied this from):

systemctl enable/disable controls the behaviour when booting
systemctl start/stop controls the behaviour right now
enable does not imply start (neither does disable imply stop). This can be overriden with the --now switch.
only enable and start the timer unit, not the service unit
issue systemctl daemon-reload whenever you edit the unit files

eg
'systemctl --user stop apt-update-check.timer'
'systemctl --user disable apt-update-check.timer'
also
'systemctl --user status apt-update-check.timer'
'systemctl --user list-timers --all'
and, if you edit a file
'systemctl --user daemon-reload'
reloads everything.

---
But I had another idea - instead of using a systemd timer, make a hook in apt configs to trigger the script whenever 'apt update' is run. Sounds cleaner, right? Just about to test it, but something like what packagekit uses (ours would be simpler) in /etc/apt/apt.conf.d/20packagekit:

// THIS FILE IS USED TO INFORM PACKAGEKIT
// THAT THE UPDATE-INFO MIGHT HAVE CHANGED

// Whenever dpkg is called we might have different updates
// i.e. if an user removes a package that had an update
DPkg::Post-Invoke {
"/usr/bin/test -e /usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && /usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call --system --dest org.freedesktop.PackageKit --object-path /org/freedesktop/PackageKit --timeout 4 --method org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo > /dev/null";
};

// When Apt's cache is updated (i.e. apt-cache update)
APT::Update::Post-Invoke-Success {
"/usr/bin/test -e /usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && /usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call --system --dest org.freedesktop.PackageKit --object-path /org/freedesktop/PackageKit --timeout 4 --method org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo > /dev/null";
};

johnraff · 2023-04-27 07:50:15

A test deb package:
https://drive.google.com/file/d/1glGK94 … sp=sharing

This one is triggered whenever there is an apt update. It adds apt config to do updates (not upgrades) daily. Manual updates would trigger the icon too.

The apt updates are done daily so even if the user dismisses the icon without installing upgrades, it will reappear the next day. I guess this might be reasonable behaviour?

Anyway, if you feel like installing it and seeing how it works out for a few days?

sleekmason · 2023-04-27 13:51:23

Nice! Just installed with no problems.

Notes for this and that..

updates were available at the time of install, but an apt update was needed to trigger the icon to appear. I don't think this matters in the slightest, but worth mentioning if an initial check is wanted upon install.

The terminal currently opens with /tmp in the path? Didn't know if this was wanted for some reason.

At a thought, adding a menu entry to perform the upgrade could be included. The removal of --listen might be required for any extra menu entries though, making for a manual exit again unless the -upgrade command is added to the existing command. Yeah, bit of a quandary.

Lots of little puzzles with this.

*edit - Maybe instead of a separate upgrade button, just add upgrading into the mix at the end since the terminal is already open?

One possibility -

; echo "Please enter your password to upgrade your system."; echo "Or close this window to quit now.  < ctrl +c >"; sudo apt upgrade; bash;'

guessing you will have a better method, but you get the idea.

Last edited by sleekmason (2023-04-27 19:19:55)

deleted0 · 2023-04-27 14:55:12

sleekmason wrote:

worth mentioning if an initial check is wanted upon install.

Yes, please.

8bit

johnraff · 2023-04-28 06:37:11

sleekmason wrote:

updates were available at the time of install, but an apt update was needed to trigger the icon to appear.
...worth mentioning if an initial check is wanted upon install.

Good point. I think an initial check could easily be added to the package postinstall script.

I was also wondering about when an update occurs while User is not logged in - could be possible. I guess adding back the timer to also run the check ~10min after login might cover that?

The terminal currently opens with /tmp in the path? Didn't know if this was wanted for some reason.

No that wasn't intended, and thanks for catching it! I guess this is because 'sudo -u USER' is not logging into the USER session, and maybe setting /tmp as the working directory is considered safer. I did some more reading and found that in fact runuser might be the recommended way of dropping privileges from a script run by root. For now, changed the command for running the check script to:

runuser -l "${displays[$d]}" -c "DISPLAY=:0 $(printf '%q ' "$cmd" "$@" ) &"

which results in the terminal which pops up running in $HOME, not /tmp. OTOH if /tmp were safer, could use:

runuser -u "${displays[$d]}" -- bash -c "DISPLAY=:0 $(printf '%q ' "$cmd" "$@" ) &"

instead, which looks more like the result of the original

sudo -u "${displays[$d]}" DISPLAY="$d" bash -c " $(printf '%q ' "$cmd" "$@" ) & "

It's a subtle difference, and need to think about it a bit more.

At a thought, adding a menu entry to perform the upgrade could be included. The removal of --listen might be required for any extra menu entries though...

I wanted to avoid too much hand-holding and thought BL users would be capable of (might prefer) typing 'sudo apt upgrade' for themselves. And after looking at the list of packages, they might want to do something else anyway. Not sure if adding an "Upgrade" item to the menu would save all that much work anyway - the password would still be needed - but I expect it would be fairly easy to do. I'm guessing --listen would still work.

---
Now on GitHub: https://github.com/BunsenLabs/bunsen-apt-update-checker

Last edited by johnraff (2023-04-28 06:39:32)

sleekmason · 2023-04-28 13:41:01

Cloned. Thanks for the details on runuser vs sudo -u $USER! All of this is a perfect level for me to explore, learn, and create. This script can be modified in so many different ways. Good stuff.

johnraff · 2023-04-29 05:35:06

I'm still not sure whether that apt trigger is going to work. It does when you run 'sudo apt update' in a terminal, but I'm waiting for an update to come down the wire to see if it will be triggered automatically.

It might be more reliable to go back to the timer, eg 10min after login and every 24hrs after that.

But we'd still need that funky root-to-users script to run the apt checker after install, because package maintainer scripts run as root.

So maybe throw the whole lot in and run bl-apt-update-check:
1) on install
2)10 min after every login
3) every 24 hours if user remains logged in
4) whenever 'sudo apt update' is run

It's a very small package (~5KB atm) but the timer would mean a dependency on systemd.

EDIT I've just found that the apt trigger can sometimes cause apt update to hang at "reading package lists..." until the yad icon is closed. That happened when I ran bl-welcome anyway, though 'sudo apt update' in a terminal seems OK. Needs more investigation...

EDIT2 The hang seems to be connected with the safeUpdate function (from bunsen-includes in bunsen-common) which does some redirection to handle error messages. Replace that with 'sudo apt-get update' and there's no hang. Maybe it's time for those "safe" apt functions to be dropped, but that still leaves something about update-checker's apt trigger to be sorted out.

EDIT3 Another glitch: if the outstanding packages are upgraded while the notify icon is still active, it stays up untill it's closed manually. eg run bl-welcome, do the apt update offered there, update checker icon comes up, bl-welcome finishes the update/upgrade, checker icon stays active...

I'm starting to wonder if this is going to be worth all the trouble, compared with just offering to install package-update-indicator in bl-welcome?

Last edited by johnraff (2023-04-29 06:35:35)

#21 2023-04-25 09:48:30

Re: A package update notifier?

#22 2023-04-25 14:09:24

Re: A package update notifier?

#23 2023-04-25 14:19:11

Re: A package update notifier?

#24 2023-04-25 15:27:11

Re: A package update notifier?

#25 2023-04-25 15:45:20

Re: A package update notifier?

#26 2023-04-26 01:28:50

Re: A package update notifier?

#27 2023-04-26 01:36:19

Re: A package update notifier?

#28 2023-04-26 02:19:55

Re: A package update notifier?

#29 2023-04-26 02:28:32

Re: A package update notifier?

#30 2023-04-26 06:54:18

Re: A package update notifier?

#31 2023-04-26 16:19:55

Re: A package update notifier?

#32 2023-04-27 03:06:00

Re: A package update notifier?

#33 2023-04-27 04:24:01

Re: A package update notifier?

#34 2023-04-27 05:03:17

Re: A package update notifier?

#35 2023-04-27 07:50:15

Re: A package update notifier?

#36 2023-04-27 13:51:23

Re: A package update notifier?

#37 2023-04-27 14:55:12

Re: A package update notifier?

#38 2023-04-28 06:37:11

Re: A package update notifier?

#39 2023-04-28 13:41:01

Re: A package update notifier?

#40 2023-04-29 05:35:06

Re: A package update notifier?

Board footer