Skip to content

Commit

Permalink
devel→master: For 2.2.6-release7 (#310)
Browse files Browse the repository at this point in the history 
* [README.md] Minor improvements

* [README.md] Make smiley visible again

* [bin/harbour-storeman-installer] Add recent fixes and improvements from SailfishOS:Chum GUI Installer

* [harbour-storeman-installer.spec] Post release version increase (#307)

* [rpm/harbour-storeman-installer.spec] Copy adaption to SailfishOS ≥ 4.6.0 for SailfishOS-OBS over from SailfishOS:Chum GUI Installer (#309)
  https://github.com/sailfishos-chum/sailfishos-chum-gui-installer/blob/main/rpm/sailfishos-chum-gui-installer.spec#L138-L182
  • Loading branch information
@Olf0
Olf0 authored Sep 30, 2024
2 parents aa9f46a + fb35549 commit 1d23b92
Show file tree
Hide file tree
Showing 3 changed files with 50 additions and 18 deletions.
6 changes: 3 additions & 3 deletions README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand All @@ -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).
16 changes: 10 additions & 6 deletions bin/harbour-storeman-installer
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down Expand Up @@ -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
Expand All @@ -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
Expand All @@ -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
Expand All @@ -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

46 changes: 37 additions & 9 deletions rpm/harbour-storeman-installer.spec
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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
Expand Down Expand Up @@ -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
Expand Down

0 comments on commit 1d23b92

Please sign in to comment.