Alternative update approach to slackpkg - request for testing/feedback

Eeel · 01-24-2022, 12:05 PM

Quote:

Originally Posted by reddog83

I was wondering if you could post the script to show notifications popup with kdialog?
I am have my own script hat automate's upgrading installing and allows me to make sure everything is updated on my home network. I am just trying to figure out how to get dbus to show a notification.

I'm also looking at how to send notification like notify-send but with dbus, i found thoses scripts interesting.

Code:

./notify-send.sh "Slackware" "update 1\nupdate 2\n update 3" -o "View more:kdialog --msgbox Slackware" -h 'string:desktop-entry:org.kde.konsole' -u critical

Actually i'm using this function to send notification, but i found notify-send limited

Code:

#!/bin/bash
# 
# KDE plasma notify-send function to user connected using display
# 

# Kde notify-send default icon Slackware
DEFAULT_ICON="/home/<my user>/.wallpaper/slackware.png"

# Notification expire in millisecond
DELAY=10000

# $1: notification title
# $2: notification text
# $3: Optional png icon path
notify_send () {

    if [[ -n "$1" && -n "$2" ]]; then

        # Plasma notification icon local file
        NOTIFY_ICON=${3-$DEFAULT_ICON}
        
        # Message with new lines
        local message=$( printf "$2" )

        # Name of the display in use
        local display=":$(ls /tmp/.X11-unix/* | sed 's#/tmp/.X11-unix/X##' | head -n 1)"

        # User using display
        local user=$(who | grep '('$display')' | awk '{print $1}' | head -n 1)
        
        # User uid
        local uid=$(id -u $user)
        
        # User connected found
        if [[ -n "${user}" ]]; then

            # notify-send command
            local cmd=(/usr/bin/notify-send --app-name="$1" --icon=$NOTIFY_ICON --expire-time=$DELAY -h 'string:desktop-entry:org.kde.konsole' "$message")
            
            # Script user uid
            local script_uid=$(id -u)
            
            # Get the DBUS_SESSION_BUS_ADDRESS of the user logged
            local DBUS_ADDRESS=$( ps -u $user -o cmd e | grep '^/usr/bin/kded5' | tr ' ' '\n' | grep DBUS_SESSION_BUS_ADDRESS )
            
            # Run as root
            if [ "$script_uid" == "0" ]; then
            
                sudo -u $user DISPLAY=$display $DBUS_ADDRESS "${cmd[@]}"
            
            # Run as user
            elif [ "$script_uid" == "$uid" ]; then
                
                export $DBUS_ADDRESS
                
                "${cmd[@]}"
                
            else
            
                echo -e "notify_send: only root and $user can execute this function."
                exit 1
                
            fi
        fi
        
    else
    
        echo -e "notify_send: Missing one or more function argument"
        exit 1
    fi
}

0XBF · 01-25-2022, 04:46 PM

Quote:

Originally Posted by reddog83

I was wondering if you could post the script to show notifications popup with kdialog?
I am have my own script hat automate's upgrading installing and allows me to make sure everything is updated on my home network. I am just trying to figure out how to get dbus to show a notification.

I'll post it here but a couple warnings about it:
1. I scripted talking directly to the notifications dbus service because the notify-send applet is limited, as the prior poster noted. I also manually listen for the response by monitoring the dbus. I consider this hackish and dbus should probably be interacted with using its C API instead of shell code... but I've gotten too rusty with C and the tools were all present to do it this way.

2. Its actually incorporated into another script that calls GazL's slackscan utility, as well as some parsing routines to generate/format the messages. I wrote this script as more of a "proof of concept" and not intended for distributing so it's not fully commented, most efficient coding practices, etc. I'll paste the entire thing for context and highlight the relevant bits in blue.

Code:

#!/bin/bash
#######################################################################
# This script uses slackscan to check for updates, new installs,
# and removals and outputs a clickable notification if the $DISPLAY 
# variable is defined. Clicking shows more details. This is designed to 
# work in KDE Plasma 5 on a slackware system.
#
# Requires: gdbus, kdialog, and kinfocenter (for the logo).

#######################################################################

# This script generates some files and needs a directory that the 
# user can read/write from. White and blacklists are kept here in a 
# sub folder called 'filter_lists' as well. Make sure these directories
# exist and contail files called inst.whitelist, inst.blacklist, 
# upgd.whitelist, upgd.blacklist, remv.blacklist.

work_dir="$HOME/slackscan"

### initalize variables ###############################################

# Optional sleep time can be passed on $1 (e.g. when using autostart at login)
[ ! -z "$1" ] && sleep $1

# Notifications dbus interface:
bus_name="org.freedesktop.Notifications"
obj_path="/org/freedesktop/Notifications"
method="org.freedesktop.Notifications.Notify"

# Working files:
inst_list="${work_dir}/inst.list"
upgd_list="${work_dir}/upgd.list"
remv_list="${work_dir}/remv.list"
message="${work_dir}/message"
details="${work_dir}/details"
outfile="${work_dir}/update.sh"

rm -f $inst_list $upgd_list $remv_list $message $details $outfile

filters="${work_dir}/filter_lists"
summary=""

### slackscan commands ################################################

/usr/sbin/slackscan -i - | grep -f ${filters}/inst.whitelist | grep -vf ${filters}/inst.blacklist > $inst_list
/usr/sbin/slackscan -u - | grep -f ${filters}/upgd.whitelist | grep -vf ${filters}/upgd.blacklist > $upgd_list
/usr/sbin/slackscan -r - | grep -vf ${filters}/remv.blacklist > $remv_list

cat $inst_list $upgd_list | ${work_dir}/slackscan_update_generator >> $outfile

### notification routines #############################################

# Details about where install scripts, etc. are kept:
if [ "$(cat $upgd_list | wc -l)" -gt "0" -o "$(cat $inst_list | wc -l)" -gt "0" ]; then
  echo "An update/install script is available to run at $outfile" >> $details
fi

if [ "$(cat $remv_list | wc -l)" -gt "0" ]; then
  echo "A list of packages to remove is available at $remv_list" >> $details
fi

echo >> $details

# Format and send a notification messages:
c="$(cat $upgd_list | wc -l)"
echo "$c package(s) to upgrade." | tee -a $message $details
if [ "$c" -gt "0" ]; then
  summary="Upgrades are available"
  cat ${upgd_list} | rev | cut -d'/' -f 1 | rev >> $details
  echo >> $details
fi

c="$(cat $inst_list | wc -l)"
echo "$c new package(s) to install." | tee -a $message $details
if [ "$c" -gt "0" ]; then
  if [ -z "$summary" ]; then
    summary="New packages are available"
  fi
  cat ${inst_list} | rev | cut -d'/' -f 1 | rev >> $details
  echo >> $details
fi

c="$(cat $remv_list | wc -l)"
echo "$c package(s) pending removal." | tee -a $message $details
if [ "$c" -gt "0" ]; then
  cat ${remv_list} >> $details
fi

[ -z "$summary" ] && summary="No upgrades available."

# Add some more information to the notification message:
echo "- - -" >> $message
echo "Click this message to view details." >> $message

# Check for a message and send the notification if we have a $DISPLAY
[ ! -z "$DISPLAY" ] || exit

if [ -r "$message" ]; then
  notification_id="$(gdbus call --session \
    --dest=$bus_name \
    --object-path=$obj_path \
    --method=$method \
    "slackscan" \
    0 \
    "/etc/kde/xdg/slackware_logo.png" \
    "$summary" \
    "$(cat $message)" \
    '["default",""]' \
    '{"urgency": <1>}' \
    10000 | sed 's/)//g')"
fi

# Monitor session dbus for the default action or until notification is closed.
# Note: 'default action' is clicking the notification popup.
pipe="${work_dir}/notifications_pipe"
mkfifo $pipe
gdbus monitor --session --dest=$bus_name --object-path=$obj_path > $pipe &
pid="$!"
trap "kill -9 $pid; rm $pipe" EXIT

while read -r line
do
  if [ ! -z "$line" ]; then
    if echo "$line" | grep -q "ActionInvoked ${notification_id} 'default')" ; then
      kdialog --title "slackscan" --textbox ${work_dir}/details 640 480 2> /dev/null &
      break
    elif echo "$line" | grep -q "NotificationClosed ${notification_id}" ; then
      break
    fi
  fi
done < $pipe

The gist of it is to call the 'Notify' method directly on the session dbus, using 'gdbus call' to properly address the dbus. You can find the explanation for 'Notify's' arguments on this page: https://specifications.freedesktop.o...t/ar01s09.html

Once the notification daemon fires a notification instance, we take its 'id' and watch the dbus with 'gdbus monitor' to see what happens. That gets forked and piped to watch for what to do when the 'default' action of clicking the popup occurs.

Hope that makes sense. Good luck

hpfeil · 01-28-2022, 02:44 PM

I glanced at your invention only to ask what led you use this approach to the problem. If you have a better way to do updates, why not work with Roberto Batista and Evaldo Gardenali to improve slackpkg instead of competing with them? If you want a simple way to upgrade your installation in these days of fast error-free internet connections, unlike the old days of parity errors and modems, rsync slackware64 from your favorite mirror, then

Code:

find slackware64 -type f -name \*.txz -exec upgradepkg --install-new {} \;

It costs nothing to `upgradepkg` on packages already current, a few seconds to upgrade the new packages, then rm -r slackware64. Me, I parse ChangeLog.txt for upgrades, then download and upgradepkg only the new packages. Takes a couple of minutes. I wrote that script decades ago before slackpkg. Slackpkg is an elegant solution. Why reinvent the wheel?

GazL · 01-29-2022, 03:25 AM

When I wrote the first version of this, slackpkg+ didn't exist, and there was no way to merge two or more repos into a combined set of packages. I've been using this in one form or another for many years now.

The problem with the find approach, or even a shell wildcard approach such as upgradepkg --install-new slackware64/*/*.t?z is that they don't handle removed packages. They also can't tell whether gpg --verify is required so you'd either end up verifying everything, or nothing, which was not acceptable to me.

I don't see these as in competition with any other tools as they work quite differently, which is also why cooperating with the other tool developers wouldn't really work.

If others find my tools to their preferences that's gratifying, but I wrote them for myself, to my own preferences.

Other than a couple of people though, I've not really seem much interest, so I don't think the other update tool developers need worry!

Gerard Lally · 01-29-2022, 11:18 AM

Quote:

Originally Posted by GazL

Other than a couple of people though, I've not really seem much interest, so I don't think the other update tool developers need worry!

I'm interested, but I just haven't put the time in to study these tools properly.

Running slackup generates a list of SBo packages for removepkg ; is it your intention that a blacklist must first be created before passing this output to the shell?

Perhaps a warning might be in order for unsuspecting users?

GazL · 01-29-2022, 04:41 PM

I'm not going to add warnings as the intended demographic for slackscan/slackup is more advanced users who understand how the tools work. They shouldn't be run blindly and I strongly recommend reviewing the stream of generated pkgtool commands before executing them.

Personally, I recommend keeping package files around as the whole concept of slack{scan,up} was to keep the installed system in sync with "available" packages. However, if you don't want to keep your SBo packages around for some reason, then please see the section in the README about the "protect file" which was added to cater for this specific situation.

GazL · 02-04-2022, 02:17 PM

Slackup Version 4.0 now pushed to my github.

Changes:

1) Configuration files are now stored in 'profile' subdirectories for easier selection. Existing users will need to migrate their config files to the new locations:
/etc/slackup/default.conf to /etc/slackup/default/scan
/etc/slackup/filter to /etc/slackup/default/filter
/etc/slackup/blacklist to /etc/slackup/default/blacklist
/etc/slackup/protect to /etc/slackup/default/protect.

A profile may be specified by the -p option. The default, is unsurprisingly "default".

These changes will make it easier to have alternate configuration profiles: for example you might want to setup a "no-kde" profile using a different blacklist.

2) A sample post-install script for kernel-modules that handles updating the initrd and vmlinuz in a EFI/ELILO directory has been included in the doc directory. If you decide to use it, make sure you understand how it works and how you need to configure your system in order for it to do its thing.

GazL · 02-10-2022, 09:35 AM

slackscan updated to 2.7

fixes a bug where packages tagged _slack15.0 were being ignored because of a bad regex.

slackup updated to 4.3

Include slackscan 2.7

example output running against 15.0

Code:

$ /usr/sbin/slackup -cis
# Generated by slackup on host: ws1.local, Thu 10 Feb 15:37:09 GMT 2022

#
#  mozilla-firefox-91.6.0esr-x86_64-1_slack15.0.txz
#
gpg --verify \
  /local/slackware/mirror/slackware64-15.0/patches/packages/mozilla-firefox-91.6.0esr-x86_64-1_slack15.0.txz.asc \
  /local/slackware/mirror/slackware64-15.0/patches/packages/mozilla-firefox-91.6.0esr-x86_64-1_slack15.0.txz \
&&  upgradepkg  /local/slackware/mirror/slackware64-15.0/patches/packages/mozilla-firefox-91.6.0esr-x86_64-1_slack15.0.txz
#
#  mozilla-thunderbird-91.6.0-x86_64-1_slack15.0.txz
#
gpg --verify \
  /local/slackware/mirror/slackware64-15.0/patches/packages/mozilla-thunderbird-91.6.0-x86_64-1_slack15.0.txz.asc \
  /local/slackware/mirror/slackware64-15.0/patches/packages/mozilla-thunderbird-91.6.0-x86_64-1_slack15.0.txz \
&&  upgradepkg  /local/slackware/mirror/slackware64-15.0/patches/packages/mozilla-thunderbird-91.6.0-x86_64-1_slack15.0.txz
$

no at-3.2.3 because I'd already patched it locally.

P.S. Some folks were asking for blacklists in slackscan earlier in this thread.

slackup now has a -l option that will make it act like slackscan and output lists rather than a stream of shell commands, except that filter/blacklist and protect files are honoured (unless disable using option switches).

So there's probably no reason for slackscan to exist any more as a separate tool as slackup can also generate those simple lists.

GazL · 02-11-2022, 01:41 PM

Release 5.0.1 of slackup is now out.

Lots of improvements in this one. I think development is going to settle down now as the flurry of activity has about run its course (I've been on current for so long I hadn't really had time to test it with a stable release, and one or two things crawled out of the woodwork).

Also, I found a good use for the new profile and filtering
options...

My box is on 15.0, but I can YOINK that nice new current kernel with:

Code:

$ slackup -p current -si kernel-[gm]
curl -O https://mirrors.slackware.com/slackware/slackware64-current/slackware64/a/kernel-generic-5.16.8-x86_64-1.txz
curl -O https://mirrors.slackware.com/slackware/slackware64-current/slackware64/a/kernel-generic-5.16.8-x86_64-1.txz.asc
gpg --verify \
  kernel-generic-5.16.8-x86_64-1.txz.asc \
  kernel-generic-5.16.8-x86_64-1.txz \
&&  upgradepkg  kernel-generic-5.16.8-x86_64-1.txz
curl -O https://mirrors.slackware.com/slackware/slackware64-current/slackware64/a/kernel-modules-5.16.8-x86_64-1.txz
curl -O https://mirrors.slackware.com/slackware/slackware64-current/slackware64/a/kernel-modules-5.16.8-x86_64-1.txz.asc
gpg --verify \
  kernel-modules-5.16.8-x86_64-1.txz.asc \
  kernel-modules-5.16.8-x86_64-1.txz \
&&  upgradepkg  kernel-modules-5.16.8-x86_64-1.txz \
&&  /etc/slackup/post-install/kernel-modules kernel-modules-5.16.8-x86_64-1.txz
$

GazL · 02-16-2022, 09:51 AM

Slackup 5.2 Released.

Changes:

gpg --verify of CHECKSUMS.md5 can now be skipped with the '-N' option. Doing so is probably not wise but if all you want is to take a quick peak at what has changed without going to the trouble of importing the gpg key then this option conbined with '-l' will allow you to do so with a simple: slackup -Nl
There's a new convenience option '-x' which will cause slackup to execute the commands in a shell instead of outputting them to stdout: it's really no different than just doing slackup | sh, but a little easier to type.

marav · 02-16-2022, 10:45 AM

Hi GazL

in sbin/slackpup, line 30
you have

Code:

cd /

What is it for ?

GazL · 02-16-2022, 11:43 AM

Quote:

Originally Posted by marav

Hi GazL

in sbin/slackpup, line 30
you have

Code:

cd /

What is it for ?

It's just part of my standard boiler-plate. Setting the working directory to a known value. Has no effect on the script really.

edit. Or at least it didn't until I went and added that -x option. Hmmm... good point I need to go fix that.

Thanks for making me aware of it.

GazL · 02-16-2022, 12:36 PM

Bugfix release.

Use of the new -x will result in files being unintentionally downloaded to the root directory rather than the current directory as was the case with slackup | sh.

To avoid this we'll remove the 'cd /' from the top of the script.(it wasn't necessary anyway).

Also, add comments to README and man-page to make it clear that this is the expected behaviour.

Thanks to marav @ linuxquestions.org for querying this.

GazL · 02-17-2022, 08:00 AM

Release 5.3

slackup -x will now use /var/cache/packages for downloaded package files. This can be overridden by setting the SLACKUP_CACHE_DIR environment variable.
generated curl commands for remote package files will now include '-C -' to allow restarting a transmission.

GazL · 02-28-2022, 01:50 PM

slackscan 3.0 and slackup 6.0 are now available.

Both utilities are now shipped as part of my slackscan repo, and are available here:
https://github.com/glangshaw/slacksc...ags/3.0.tar.gz

The separate 'slackup' repo I was maintaining will no longer receive updates, and will eventually be retired.

Major changes this time, some of which will be user visible, so migration actions will be necessary.

Changes:

filter, blacklist and protect file processing have been moved into slackscan rather than being done in the slackup front-end.
blacklist and filter processing is now applied to the list of packages prior to them being compared to the packages on the host system.
slackscan no longer uses a single config file, but uses 'config profiles' as were seen in previous versions of slackup. Config profiles are now stored in subdirectories of /etc/slackscan/ rather than /etc/slackup. The blacklist, filter, and protect files are still optional however, so in reality only the location of the file has changed.
SLACKUP_PROFILE environment variable is now SLACKSCAN_PROFILE to reflect the above changes.

Migration actions (for users of prior versions):

If using an old style single config file, rename it to /etc/slackscan/default/scan.
Move any profile directories you have from /etc/slackup to /etc/slackscan. (post-install scripts remain in /etc/slackup/post-install/)
If using the SLACKUP_PROFILE environment variable to set the default profile name, rename it to SLACKSCAN_PROFILE.

So, how does this look on an installed system?

Code:

/etc/slackscan
├── 15.0
│   ├── blacklist
│   ├── filter
│   ├── protect
│   └── scan
├── current
│   ├── blacklist
│   ├── filter
│   ├── protect
│   └── scan
├── default -> local
└── local
    ├── blacklist
    ├── filter
    ├── protect
    └── scan

/etc/slackup
└── post-install
    └── kernel-modules

In the above, I have 3 profiles, one for current, one for 15.0, and my 'local' profile which is the one I actually use (symlinked from 'default' to save having to specify it each time, or set the env variable.). You'll also notice the post-install script for kernel-modules that will run mkinitrd and update the efi elilo directory.

With the filter and blacklist now being applied before comparing the available packages to those installed on the system it's possible to be more flexible with combining multiple sources and getting the desired results. For example, in my 'local' config's scan file I have:

Code:

https://slackware.uk/slackware/slackware64-current/slackware64/CHECKSUMS.md5
https://slackware.uk/slackware/slackware64-15.0/patches/CHECKSUMS.md5
/local/slackware/iso/slackware64-15.0/slackware64/CHECKSUMS.md5

... Which combines packages in current with the packages in patches and 15.0.

Then, in my local config's filter file I use the following to limit the packages taken from current to only the kernel-modules and kernel-generic packages:

Code:

/slackware64-current/slackware64/a/kernel-[gm]
/slackware64-15.0/patches/packages/
/slackware64-15.0/slackware64/

Slackware 15.0 updates works as normal, the kernel packages from current are given precedence over those in patches/ and 15.0.
Once configured, all I have to do is type:
slackup -six

This version is very new, with some big changes, so bugs are likely.
It's definitely going to be worth checking it does the right thing each time until it proves itself, so if you try it, be cautious: Using slackup with the -x option is probably not the best idea unless you've just run it without the -x to check it is going to do the right thing.

It seems to be working here, but as always, please let me know if you spot a bug.