Does Storeman not find its own updates?

[Olf0]

SailfishOS VERSION (Settings → About product → Build): 3.2.1, likely all supported versions 3.1.0 to 4.5.0

HARDWARE (Settings → About product → Manufacturer & Product name): Xperia X, likely hardware independent

Storeman VERSION (Storeman → <Top pulley> → About Storeman): 0.3.2

BUG DESCRIPTION

Storeman does not find its own updates, i.e., it does not offer its newer versions as update candidates to install. I currently have v0.3.2 installed on this older device, and there have been two newer releases published as of 2023-03-18 in its own OBS sub-repository: 0.3.3 and 0.3.4

STEPS TO REPRODUCE

1. Install an older Storeman release from GitHub's releases page of Storeman.
2. Check that its "Check for self-updates" switch is on in Storeman's settings, see /~https://github.com/storeman-developers/harbour-storeman/blob/devel/qml/pages/SettingsPage.qml#L180-L185
3. See that it does not find its updates.

ADDITIONAL INFORMATION

Maybe I broke something when adapting all the links (primarily by v0.2.12), but I cannot see what!

1. The URL and repo name is correct and consistent, see
   • /~https://github.com/storeman-developers/harbour-storeman/blob/devel/qml/pages/SettingsPage.qml#L180-L185
   • ssu lr displays this repo as first user repo.
   • /~https://github.com/storeman-developers/harbour-storeman/blob/devel/src/ornpm.cpp#L28
   • The repo address is correct, see e.g.: https://repo.sailfishos.org/obs/home:/olf:/harbour-storeman/4.3.0.15_aarch64

What I completely fail to understand is what src/ornrepo.cpp is for and does: /~https://github.com/storeman-developers/harbour-storeman/blob/devel/src/ornrepo.cpp
I also wonder about the empty pair of braces { } at its end?!? Is that correct?

The same applies to the corresponding header file (no clue): /~https://github.com/storeman-developers/harbour-storeman/blob/devel/src/ornrepo.h
What is the alias for and how does it work?

Maybe this was never working, i.e., maybe this bug exists since the switch to OBS-based builds with Storeman 0.2.9?!?

P.S.: I still have to determine how to enable the debug output (and where it writes to) to see /~https://github.com/storeman-developers/harbour-storeman/blob/devel/src/ornpm.cpp#L118-L119
When started at the command line as regular user by execution harbour-storeman, I usually see a couple of warnings and errors, but they always were there (I opened a bug report for that years ago which was closed, because these errors and warnings were deemed "normal").

• But often when triggering a repositories refresh manually (Repositories → [Top pulley] Refresh cache) an endless chain of launcher notifications (literally: it does not stop until Storeman is closed) pops up:
  An error occurred
Failed to obtain authentication.
• When Storeman was started at the command line, concurrently a long (maybe also endless; I usually stopped Storeman after many 10 such lines) chain of debug output messages is printed at the terminal:
  [D] unknown:0 - Specified Desktop file does not exist ""
  Note that I was successfully logged in at OpenRepos via Storeman all the time; the "authentication" mentioned seems to address something different (OpenRepos' API auth?)

P.P.S.: As a dirty workaround, I consider re-submitting Storeman to SailfishOS:Chum again. While this may trigger social conflicts (again), it would make Storeman updatable again vie, e.g., the SailfishOS:Chum GUI application.

I also considered switching the update OBS repo from a personal one to SailfishOS:Chum, which would free me from timely maintenance of the personal OBS repo after a new SailfishOS releasee. But then the Storeman-Installer has to enable the SailfishOS:Chum OBS-repo, which need some technical coordination so that the SailfishOS:Chum GUI app does not complain about other apps also handling this repo (it may work just fine, though). One would have to model all cases with both installers and the applications proper being installed or removed in any order. Nevertheless, this bug has to resolved for any of these considerations.

[Olf0]

@nephros, I am lost on this one (and not-updating is a serious bug): I checked my configuration changes as thoroughly as I can and recently documented all relevant information (IMO exhaustingly) in the original issue report above. I would appreciate very much if you take a closer look at this, when you can spare the time.

[nephros]

I haven't looked at the code yet, but can reproduce:

harbour-storeman-0.3.2-1.11.1.jolla.aarch64

is installed. Neither storeman nor pkcon find updates.

From the OBS repo is not surprising, as it is NOT in the list of user repos in ssu lr.

[nephros]

I also see a 'Storeman OBS repository' in Storeman itself (under Repos) but it is not clickable as opposed to (all?) other repos listed there.

And it cannot be found on the web page.

[nephros]

Manually adding the obs repo via ssu ar, refreshing does fix the issue.

From here it looks like either 0.3.2, its installer, or something removes the repo, hence no updates.

[nephros]

WHY is there a 'Storeman OBS Repo' listed when no part of the system knows of it?

Edit: answer: because it's inserted into the model whether or not it's in the list gotten from ssu, as long as it is not disabled:

115-    }
116-    qDebug() << "System has" << repos.size() << "ORN repositories";
117-
118-    qDebug() << "Getting the Storeman OBS repository";
119:    repos.insert(OrnPm::storemanRepo, !disabled.contains(OrnPm::storemanRepo));
120-
121-    qDebug() << "Getting the list of installed packages";
122-    auto spool = pool_create();
123-    auto srepo = repo_create(spool, OrnConst::installed.toLatin1().data());

[nephros]

(sorry for the spamming, SFOS browser can't edit GH comments)

That known/unknown OBS repo may also be is the reason for the 'couldn't find the specified repository' message that always pops up on refresh.

Edit: confirmed by using context menu->refresh on it.

[nephros]

I assume something is amiss with all the 'either use an openrepos-foo OR hardcoded Storeman update repo name' logic.

Can't investigate this weekend tough.

[Olf0]

I haven't looked at the code yet, but can reproduce:

harbour-storeman-0.3.2-1.11.1.jolla.aarch64

is installed. Neither storeman nor pkcon find updates.

I never tried the latter: Now I did with the same result, There is no update candidate for harbour-storeman-0.3.2-1.8.1.jolla.armv7hl!?!

From the OBS repo is not surprising, as it is NOT in the list of user repos in ssu lr.

That is definitely not true for my devices and should be "impossible":

1. Storeman Installer sets this repo, if not already set in its %post scriptlet and never removes it.
2. Storeman sets this repo, if not already set in its %post scriptlet.
3. ssu lr | less displays the harbour-storeman-obs repo as the first entry of the user repos on my device.

I also see a 'Storeman OBS repository' in Storeman itself (under Repos) but it is not clickable as opposed to (all?) other repos listed there.

Oh, I never realised that. While this repository entry is not "clickable" in the sense of "openable", it does have a context menu in which it can be disabled. But this repository already gets some special treatment, because its context menu does not offer "Refresh cache", "Disable" and "Remove" as for all other repositories, but only "Refresh cache" and "Disable". Only when it is disabled (does work fine, see ssu lr), the context menu shows "Enable" for it, but not "Enable" and "Remove" as for all other disabled repositories.

So this is O.K., although the entry "Check for self-updates" in Storeman's settings does exactly the same: Enable and disable the harbour-storeman-obs repository. Consequently the only function the entry "Storeman OBS repository" in the repo list offers uniquely is "Refresh cache". This fine, and I am glad that your remark triggered me to check that all this works well and as intended: It does.

And it cannot be found on the web page.

¿Which web-page?
It is there, see https://build.merproject.org/project/show/home:olf:harbour-storeman
And its download repository appears to be (& to me) looking as it should, see for example https://repo.sailfishos.org/obs/home:/olf:/harbour-storeman/4.5.0.19_aarch64/
also via its alternative DNS name, see https://repo.merproject.org/obs/home:/olf:/harbour-storeman/4.5.0.19_aarch64

Manually adding the obs repo via ssu ar, refreshing does fix the issue.

Really?!? Not for me. As denoted before the repo is set correctly by the Storeman Installer and Storeman for me and is not removed, unless Storeman is removed. I have tested that many times. Can you please re-test, because the different outcomes at this point is strange.

By "the issue" you still mean the original one; i.e., now a pkcon update harbour-storeman works fine for you rsp. Storeman shows an own update as an update candidate?

From here it looks like either 0.3.2, its installer, or something removes the repo, hence no updates.

As stated: I cannot reproduce this and never saw this in the past while testing.

WHY is there a 'Storeman OBS Repo' listed when no part of the system knows of it?

True, that behaviour is confusing. Likely Petr (mentaljam) did not consider (neither did I, up to now) the situation you experience, because having no harbour-storeman-obs entry in SSU's repo list (neither enabled nor disabled) should never occur, as long Storeman is installed. It may make sense to take and display this repository's status from SSU, so one can at least see that it is not there at the GUI; but that is primarily beautification, as ssu lr does the job, and bit off-topic WRT this issue here.

Edit: answer: because it's inserted into the model whether or not it's in the list gotten from ssu, as long as it is not disabled:

… and when it is disabled it still is handled specially, presumably be some piece code elsewhere.

(sorry for the spamming, SFOS browser can't edit GH comments)

If you have a license Alien Dalvik / "AAS", do use Firefox! The SFOS browser is still unusable and featureless, just as Jolla Mail is compared to K9 Mail. This will never change (for many reasons), especially now that AAS is Jolla's primary product and SFOS is basically relegated to a mass testing platform for AAS betas; consequently the Jolla apps seem to be in maintenance mode since 2022 (i.e., after the SFOS 4.4.0 release).

That known/unknown OBS repo may also be is the reason for the 'couldn't find the specified repository' message that always pops up on refresh.

… which I never saw before, because I always had the harbour-storeman-obs entry in SSU's config. So before proceeding, we have to determine what went wrong for you, because I never experienced that and never received a bug report indicating that. Note that the Storeman Installer would not work, if it does not configure the harbour-storeman-obs repo correctly (for SSU), refreshes it successfully and lastly installs Storeman from it: This has worked fine for thousands of users with no complaints.

Edit: confirmed by using context menu->refresh on it.

Well, this consequence of the harbour-storeman-obs entry missing in SSU's config is fine and as it should: All pkcon errors triggered by Storeman shall be displayed as such messages or notifications on the GUI.

I assume something is amiss with all the 'either use an openrepos-foo OR hardcoded Storeman update repo name' logic.

My assumption is that I did miss something when converting the mentaljam-obs entry pointing to Petr's personal repo at the SailfishOS-OBS to harbour-storeman-obs pointing to mine. You may do such trivial things as grepping for "mentaljam" in the whole source tree (I did this two times, but may be "too blind to see" something relevant): "mentaljam" should now solely occur in text strings for output (e.g., on the "About" QML page).

Can't investigate this weekend tough.

Take your time (and do that on a laptop, notebook or desktop PC 😉), I am aware of this issue for many, many months and only recently found the time to document it properly and concurrently to re-evaluate it; a few weeks more or less does not matter at all. As usual, no user has opened a bug report, yet.

[nephros]

Hm, no idea how to track down when the repo was removed.

While /var/log/zypp/history has 'rremove' events, it seems such event is logged even when simply refreshing repos.

There are no useful entries there for adding a repo as far as I can see.

I did try again:

1. have storeman 0.3.2-1.11.1.jolla aarch64 installed
2. Have NO harbour-storeman-obs repo configured
3. --> no self-updates found
4. Manually add repo: ssu ar harbour-storeman-obs https://repo.sailfishos.org/obs/home:/olf :/harbour-storeman//4.4.0.72_aarch64
5. Restart Storeman
6. --> update to harbour-storeman-0.3.4-1.14.1.jolla.aarch64 is offered.

[nephros]

This is the scripts section of the 0.3.2 RPM:

postinstall scriptlet (using /bin/sh):
# The %post scriptlet is deliberately run when installing *and* updating:
ssu_ur=no
ssu_lr="$(ssu lr | grep '^ - ' | cut -f 3 -d ' ')"
if printf %s "$ssu_lr" | grep -Fq mentaljam-obs
then
ssu rr mentaljam-obs
rm -f /var/cache/ssu/features.ini
ssu_ur=yes
fi
if ! printf %s "$ssu_lr" | grep -Fq harbour-storeman-obs
then
ssu ar harbour-storeman-obs 'https://repo.sailfishos.org/obs/home:/olf:/harbour-storeman/%(release)_%(arc
h)/'
ssu_ur=yes
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 only the final exit status of a whole scriptlet is crucial:
# https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_syntax
postuninstall scriptlet (using /bin/sh):
if [ $1 = 0 ]  # Removal
then
ssu rr harbour-storeman-obs
rm -f /var/cache/ssu/features.ini
ssu ur
fi