devel→master: For 2.2.6-release7

README.md

@@ -6,15 +6,15 @@
 
 Starting with version 0.2.9, Storeman is built by the help of the SailfishOS-OBS and initially installed by the Storeman Installer (or manually).  To update from Storeman <&nbsp;0.2.9 (requires SailfishOS ≥&nbsp;3.1.0), one should reinstall Storeman via the Storeman Installer.  After an initial installation of Storeman ≥&nbsp;0.3.0, further updates of Storeman will be performed within Storeman, as usual.
 
-The Storeman Installer works on any SailfishOS release ≥&nbsp;3.1.0 and all supported CPU-architectures (armv7hl, i486 and aarch64).  The current Storeman Installer RPM can be obtained from its ["latest release" page at GitHub](https://github.com/storeman-developers/harbour-storeman-installer/releases/latest) and [OpenRepos.net](https://openrepos.net/content/olf/storeman-installer).
+The Storeman Installer works on any SailfishOS release ≥&nbsp;3.1.0 and all three supported CPU-architectures (aarch64, armv7hl and i486).  The current Storeman Installer RPM can be obtained from its ["latest release" page at GitHub](https://github.com/storeman-developers/harbour-storeman-installer/releases/latest) and [OpenRepos.net](https://openrepos.net/content/olf/storeman-installer).
 
 RPMs of [older Storeman releases are also available at OpenRepos](https://openrepos.net/content/olf/storeman-legacy), e.g. v0.1.8 which works on SailfishOS 2.2.1 and may work on older SailfishOS 2 releases.
 
 ### Important notes
 
 * If you experience issues with Storeman Installer, please take a look at its log file `/var/log/harbour-storeman-installer.log.txt`.  If that does not reveal to you what is going wrong, please check first if an issue report describing this issue is [already filed at GitHub](https://github.com/storeman-developers/harbour-storeman-installer/issues), then you might file a new issue report there and attach the log file to it, or enhance an extant bug report.
 * If you experience issues when installing, removing or updating packages after a SailfishOS upgrade, try running `devel-su pkcon refresh` in a terminal app.
-* When Storeman Installer fails to install anything (i.e, a minute after installing it the icon of Storeman has not appeared on the launcher / desktop), most likely the preceding or the following bullet point is the reason.
+* When Storeman Installer fails to install anything (i.e. a minute after installing it the icon of Storeman has not appeared on the launcher / desktop), most likely the preceding or the following bullet point is the reason.
 * Before software can be build for a SailfishOS release at the SailfishOS-OBS, Jolla must create a [corresponding "download on demand (DoD)" OBS-repository](https://build.merproject.org/project/subprojects/sailfishos).  It may take a little time after a new SailfishOS release is published before the corresponding "DoD" repository is being made available, during which installing Storeman by the Storeman Installer or updating Storeman by itself on a device with the new SailfishOS release already installed does not work, because Storeman cannot be compiled for this new SailfishOS release at the Sailfish-OBS, yet; consequently this is always the case for "closed beta (cBeta)" releases of SailfishOS.  In such a situation one has to manually download Storeman built for the last prior SailfishOS "general availability (GA)" release (e.g. from [its releases section at GitHub](https://github.com/storeman-developers/harbour-storeman/releases) or [the SailfishOS-OBS](https://build.merproject.org/project/show/home:olf:harbour-storeman)), then install or update Storeman via `pkcon install-local <downloaded RPM file>`, and hope that there is no change in the new SailfishOS release which breaks Storeman; if there is, please report that soon at [Storeman's issue tracker](https://github.com/storeman-developers/harbour-storeman/issues).
 * Disclaimer: Storeman and its installer may still have flaws, kill your kittens or break your SailfishOS installation!  Although this is very unlikely after years of testing by many users, new flaws may be introduced in any release (as for any software).  Mind that the license you implicitly accept by using Storeman or Storeman Installer excludes any liability.
 
@@ -40,5 +40,5 @@ RPMs of [older Storeman releases are also available at OpenRepos](https://openre
 * Installing [Storeman Installer 1.3.1](https://github.com/storeman-developers/harbour-storeman-installer/releases/tag/1.3.1) and all later versions also automatically removes an installed Storeman (*harbour-storeman* package) <&nbsp;0.2.99, which eliminates the former necessity to manually remove ("uninstall") an old Storeman. 
 * [Storeman Installer 1.3.8](https://github.com/storeman-developers/harbour-storeman-installer/releases/tag/1.3.8) and all later versions create a persistent log file `/var/log/harbour-storeman-installer.log.txt`.
 * Storeman Installer 2 runs "unattended": I.e. without any manual steps, after its installation has been triggered, until Storeman is installed.
-* Storeman Installer is slow, because it calls `pkcon` two (releases before v1.3.8) to three times (releases from v[1.3.8](https://github.com/storeman-developers/harbour-storeman-installer/releases/tag/1.3.8) on), which acts quite slowly.  The minimal run time for Storeman Installer 2 is about 7 seconds, the typical run time is rather 10 seconds (measured from the moment Storeman Installer's installation is triggered, until Storeman is installed and its icon is displayed at the "launcher").  This is already a lot, but rarely the Packagekit daemon stalled (`packagekitd`, for which `pkcon` is just a command line front-end, communicating with the daemon via D-Bus) during heavy testing, which can be observed with the crude `pkmon` utility (`Ctrl-C` gets you out.:smiley:), so the Storeman Installer now tries to detect these "hangs" and to counter them: If that happens, its run time can be up to slightly more than 1 minute.  In the worst case a stalled PackageKit daemon (and with it its `pkcon` client process(es)) stalls Storeman Installer, until the PackageKit daemon reaches its idle time out of 300 seconds (5 minutes; this could theoretically happen three times, resulting in a likely unsuccessful run time of more than 15 minutes).<br />
+* Storeman Installer is slow, because it calls `pkcon` two (releases before v1.3.8) to three times (releases from v[1.3.8](https://github.com/storeman-developers/harbour-storeman-installer/releases/tag/1.3.8) on), which acts quite slowly.  The minimal run time for Storeman Installer 2 is about 7 seconds, the typical run time is rather 10 seconds (measured from the moment Storeman Installer's installation is triggered, until Storeman is installed and its icon is displayed at the "launcher").  This is already a lot, but rarely the Packagekit daemon stalled (`packagekitd`, for which `pkcon` is just a command line front-end, communicating with the daemon via D-Bus) during heavy testing, which can be observed with the crude `pkmon` utility (`Ctrl-C` gets you out. :smiley:), so the Storeman Installer now tries to detect these "hangs" and to counter them: If that happens, its run time can be up to slightly more than 1 minute.  In the worst case a stalled PackageKit daemon (and with it its `pkcon` client process(es)) stalls Storeman Installer, until the PackageKit daemon reaches its idle time out of 300 seconds (5 minutes; this could theoretically happen three times, resulting in a likely unsuccessful run time of more than 15 minutes).<br />
 Also note that SailfishOS sometimes fails to show an icon of a freshly installed app on the launcher ("homescreen") until SailfishOS is rebooted (rsp. more precisely: Lipstick is restarted).

bin/harbour-storeman-installer

@@ -72,14 +72,18 @@ source /etc/os-release; logentry="[Debug] From /etc/os-release: $ID $VERSION_ID
 printf '\n%s\n' "$(date -Iseconds) $logentry"
 systemd-cat -t "$called" -p 7 printf '%s' "$logentry"
 
-ssus="$(ssu s | grep -iv 'UID:\? ')"; logentry='[Debug] \`ssu status\`, UID omitted:'
+ssus="$(ssu s | grep -iv 'UID:\? ')"; logentry='[Debug] `ssu status`, UID omitted:'
 printf '\n%s\n%s\n' "$(date -Iseconds) $logentry" "$ssus"
 systemd-cat -t "$called" -p 7 printf '%s %s' "$logentry" "$(printf '%s' "$ssus" | sed 's/$/, /g' | tr -d '\n')"
 
 ssulr="$(ssu lr | fgrep storeman | tr -s ' ')"; logentry='[Debug] "storeman" entries from `ssu lr`:'
 printf '\n%s\n%s\n' "$(date -Iseconds) $logentry" "$ssulr"
 systemd-cat -t "$called" -p 7 printf '%s%s' "$logentry" "$(printf '%s' "$ssulr" | sed -e 's/^ - / /g' -e 's/ ... / /g' | tr '\n' ',')"  # Second string starts with a space due to substitution by `sed`
 
+ssuini="$(fgrep storeman /etc/ssu/ssu.ini)"; logentry='[Debug] "storeman" entries from /etc/ssu/ssu.ini:'
+printf '\n%s\n%s\n' "$(date -Iseconds) $logentry" "$ssuini"
+systemd-cat -t "$called" -p 7 printf '%s %s' "$logentry" "$(printf '%s' "$ssuini" | tr '\n' ',')"
+
 # Provide RPM with a little time to proceed finishing the RPM transaction,
 # which called this script asynchronously, because pkcon might fail
 # enqueuing a pkcon-job while this RPM transaction is unfinished.
@@ -175,7 +179,7 @@ do
     systemd-cat -t "$called" -p 4 printf '%s' "$logentry"
     killall -q -HUP pkcon
     sleep $i
-    killall -qw -KILL pkcon
+    killall -q -KILL pkcon
     sleep 1
     pkcon -pv quit
     sleep 1
@@ -194,13 +198,13 @@ do
     logentry="[Critical] Failed to refresh harbour-storeman-obs repository, because error-code $retc was returned by: $logentry"
     printf '\n%s\n' "$(date -Iseconds) $logentry"
     systemd-cat -t "$called" -p 2 printf '%s' "$logentry"
-    killall -qw -KILL pkcon
+    killall -q -KILL pkcon
     sleep 1
     pkcon -pv quit
     sleep 1
     systemctl stop packagekit.service
     systemctl start packagekit.service
-    logentry='[Notice] Scheduling harbour-storeman-installer for removal in 20 seconds, trying to install harbour-storeman despite the failed repository refresh meanwhile.'
+    logentry="[Notice] Scheduling $called for removal in 20 seconds, trying to install harbour-storeman despite the failed repository refresh meanwhile."
     printf '%s\n' "$(date -Iseconds) $logentry"
     systemd-cat -t "$called" -p 5 printf '%s' "$logentry"
     sleep 1
@@ -226,7 +230,7 @@ logentry='pkcon -pvy install harbour-storeman'
 # except for the final log message.
 setsid --fork sh -c '(sleep 1;\
                     i=0; while [ $i -le 9 ] && ps -eo pid | fgrep -q "$1"; do sleep 1; i=$(($i+1)); done;\
-                    printf '\n%s\n' "$(date -Iseconds) [Step 2 / 2] $2";\
+                    printf "\n%s\n" "$(date -Iseconds) [Step 2 / 2] $2";\
                     systemd-cat -t "$3" -p 6 printf '%s' "[Info] Executing: $2";\
                     eval $2)' sh_do_inst-storeman "$mypid" "$logentry" "$called"
                     # The first 15 characters of the spawned process' name
@@ -238,7 +242,7 @@ setsid --fork sh -c '(sleep 1;\
 # For a detailed description of double-forking in shell code, see
 # https://github.com/storeman-developers/harbour-storeman-installer/blob/master/double-fork-in-shell.md
 logentry="[Debug] ${called}'s main script (PID: ${mypid}) finishes"
-printf '\n%s\n' "$(date -Iseconds) $logentry"
+printf '\n%s\n' "$(date -Iseconds) ${logentry}."
 systemd-cat -t "$called" -p 7 printf '%s' "$logentry"
 exit $retc
 

rpm/harbour-storeman-installer.spec

@@ -4,7 +4,7 @@ Name:           harbour-storeman-installer
 # The Git tag format must adhere to <release>/<version> since 2023-05-18.
 # The <version> tag must adhere to semantic versioning, for details see
 # https://semver.org/
-Version:        2.2.5
+Version:        2.2.6
 # The <release> tag comprises one of {alpha,beta,rc,release} postfixed with a
 # natural number greater or equal to 1 (e.g. "beta3") and may additionally be
 # postfixed with a plus character ("+"), the name of the packager and a release
@@ -15,7 +15,7 @@ Version:        2.2.5
 # build at GitHub and OBS, when configured accordingly; mind the sorting
 # (`adud` < `alpha`).  For details and reasons, see
 # https://github.com/Olf0/sfos-upgrade/wiki/Git-tag-format
-Release:        release6
+Release:        release7
 # The Group tag should comprise one of the groups listed here:
 # https://github.com/mer-tools/spectacle/blob/master/data/GROUPS
 Group:          Software Management/Package Manager
@@ -151,25 +151,53 @@ then
   rm -f /var/cache/ssu/features.ini
   ssu_ur=yes
 fi
-if ! echo "$ssu_lr" | grep -Fq harbour-storeman-obs
+# Add sailfishos-chum repository configuration, depending on the installed
+# SailfishOS release (3.1.0 is the lowest supported, see line 68):
+source %{_sysconfdir}/os-release
+# Three equivalent variants, but the sed-based ones have additional, ugly
+# backslashed quoting of all backslashes, curly braces and brackets (likely
+# also quotation marks), and a double percent for a single percent character,
+# because they were developed as shell-scripts for `%%define <name> %%(<script>)`
+# (the same applies to scriplets with "queryformat-expansion" option -q, see 
+# https://rpm-software-management.github.io/rpm/manual/scriptlet_expansion.html#queryformat-expansion ):
+# %%define _sailfish_version %%(source %%{_sysconfdir}/os-release; echo "$VERSION_ID" | %%{__sed} 's/^\\(\[0-9\]\[0-9\]*\\)\\.\\(\[0-9\]\[0-9\]*\\)\\.\\(\[0-9\]\[0-9\]*\\).*/\\1\\2\\3/')
+# ~: sailfish_version="$(source %%{_sysconfdir}/os-release; echo "$VERSION_ID" | sed 's/^\([0-9][0-9]*\)\.\([0-9][0-9]*\)\.\([0-9][0-9]*\).*/\1\2\3/')"
+# Using an extended ("modern") RegEx shortens the sed script, but busybox's sed
+# does not support the POSIX option -E for that!  Hence one must resort to the
+# non-POSIX option -r for that, without a real gain compared to the basic RegEx:
+# %%define _sailfish_version %%(source %%{_sysconfdir}/os-release; echo "$VERSION_ID" | %%{__sed} -r 's/^(\[0-9\]+)\\.(\[0-9\]+)\\.(\[0-9\]+).*/\\1\\2\\3/')
+# ~: sailfish_version="$(source %%{_sysconfdir}/os-release; echo "$VERSION_ID" | sed -r 's/^([0-9]+)\.([0-9]+)\.([0-9]+).*/\1\2\3/')"
+# Note: Debug output of RPM macros assigned by a %%define statement is best
+# done by `echo`s / `printf`s at the start of the %%build section.
+# The variant using `cut` and `tr` instead of `sed` does not require extra quoting,
+# regardless where it is used (though escaping each quotation mark by a backslash
+# might be advisable, when using it inside a %%define statement's `%%()` ).
+sailfish_version="$(echo "$VERSION_ID" | cut -s -f 1-3 -d '.' | tr -d '.')"
+# Must be an all numerical string of at least three digits:
+if echo "$sailfish_version" | grep -q '^[0-9][0-9][0-9][0-9]*$'
 then
-  ssu ar harbour-storeman-obs 'https://repo.sailfishos.org/obs/home:/olf:/harbour-storeman/%%(release)_%%(arch)/'
+  if [ "$sailfish_version" -lt 460 ]
+  then ssu ar harbour-storeman-obs 'https://repo.sailfishos.org/obs/home:/olf:/harbour-storeman/%%(release)_%%(arch)/'
+  else ssu ar harbour-storeman-obs 'https://repo.sailfishos.org/obs/home:/olf:/harbour-storeman/%%(releaseMajorMinor)_%%(arch)/'
+  fi
   ssu_ur=yes
+# Should be enhanced to proper debug output, also writing to log-file and systemd-journal:
+else echo "Error: VERSION_ID=$VERSION_ID => sailfish_version=$sailfish_version"
 fi
 if [ $ssu_ur = yes ]
 then ssu ur
 fi
 # BTW, `ssu`, `rm -f`, `mkdir -p` etc. *always* return with "0" ("success"), hence
 # no appended `|| true` needed to satisfy `set -e` for failing commands outside of
-# flow control directives (if, while, until etc.).  Furthermore on Fedora Docs it
-# is indicated that solely the final exit status of a whole scriptlet is crucial: 
+# flow control directives (if, while, until etc.).  Furthermore Fedora Docs etc.
+# state that solely the final exit status of a whole scriptlet is crucial: 
 # See https://docs.pagure.org/packaging-guidelines/Packaging%3AScriptlets.html
 # or https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_syntax
 # committed on 18 February 2019 by tibbs ( https://pagure.io/user/tibbs ) in
 # https://pagure.io/packaging-committee/c/8d0cec97aedc9b34658d004e3a28123f36404324
-# Hence I have the impression, that only the main section of a spec file is
-# interpreted in a shell called with the option `-e', but not the scriptlets
-# (`%%pre*`, `%%post*`, `%%trigger*` and `%%file*`).
+# Hence only the main section of a spec file and likely also `%%(<shell-script>)`
+# statements are executed in a shell called with the option `-e', but not the
+# scriptlets: `%%pre*`, `%%post*`, `%%trigger*` and `%%file*`
 exit 0
 
 %posttrans