-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Does Storeman not find its own updates? #406
Comments
@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. |
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 |
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. |
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. |
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:
|
(sorry for the spamming, SFOS browser can't edit GH comments) That known/unknown OBS repo Edit: confirmed by using context menu->refresh on it. |
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. |
I never tried the latter: Now I did with the same result,
That is definitely not true for my devices and should be "impossible":
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 So this is O.K., although the entry "Check for self-updates" in Storeman's settings does exactly the same: Enable and disable the
¿Which web-page?
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
As stated: I cannot reproduce this and never saw this in the past while testing.
True, that behaviour is confusing. Likely Petr (mentaljam) did not consider (neither did I, up to now) the situation you experience, because having no
… and when it is disabled it still is handled specially, presumably be some piece code elsewhere.
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).
… which I never saw before, because I always had the
Well, this consequence of the
My assumption is that I did miss something when converting the
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. |
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:
|
This is the scripts section of the 0.3.2 RPM:
|
Maybe the failsafe fix would be to add and enable the storeman repo when the selfupdate settings switch is toggled (instead of just enabling it)? |
This looks fine and is unaltered ever since (i.e., in 0.3.3 and 0.3.4). Puzzled. Does
I do not want to "repair" an issue with a hammer, which I do not comprehend at all:
WTF! |
Yes, the output looks fine. The only thing I have encountered that does not do an update even though it is there is a vendor change. Does zypper let you update? |
I don't know why the
|
Me too, but as I do not set a vendor in the spec file, I assumed that this cannot be the case here. This was an excellent suggestion:
So I did Oh yes, sure, now I remember that the SailfishOS-OBS stubbornly sets the Vendor to My ideas how to avoid such accidents:
Does that sound O.K.? |
Neither do I; something I have not researched and likely will not, because
AFAIR from my install tests a year ago, it does not matter: It is a cache file and becomes rebuilt, if missing.
I looked at this before and still do not understand it. As usual sailors do not write comments or commit messages, except for "Fixes JB #xxxxxx" (referencing a "Jolla bug" in their internal bug tracker). Jolla has never been a Free Software company as SuSE or RedHat and will never be one, because they fiercely do not want that. |
Aha! OBS does set the So any rpm coming from chum will not update to any non-chum-built one and vice versa. I guess that explains the phenomenon of this issue. About my missing repo, it's probably not worth pursuing, I may have removed that manually at one point, I can't be sure. (Or maybe the Storeman 'empty repo detection' removes it under certain circumstances if the ssu system presents it as empty for some reason.) |
… because Jolla configured that as default.
Yes, they override it via
Not exactly: One can override both defaults via spec file. Thus my considerations to unify on one specific vendor setting for different distribution channels.
For my issue: Yes.
I wondered what the two "have"s in points 1 and 2 of this comment of yours meant: Did you reinstall (this was my initial interpretation) or was that the status quo?
IMO, this has to be manually triggered and confirmed by the user, hence it should not "just happen". |
BTW, WRT this message of yours:
I do understand it, now (as already a few times before, only to forget about it soon after):
Still I would appreciate very much if someone explains your original question, …
… after removing a repository via |
…, regardless where they are built, to avoid blocked upgrade paths (as, e.g., observed in [Storeman issue \#406](storeman-developers/harbour-storeman#406 (comment))) due to [vendor stickiness](https://en.opensuse.org/SDB:Vendor_change_update).
Ever since becoming aware of this issue (by your mention in the comment above), my main device has had 0.3.2-1.11.1.jolla aarch64 installed - from when or how exactly I'm not sure. I did not downgrade, reinstall or otherwise alter the installation of Storeman that was already there. So I was genuinly affected by this issue of updates not being detected (though for a different reason - missing repos vs vendor change - as it turns out). I did confirm though that this installed version 0.3.2 had vendor |
Thank you for the clarification! |
I'm not familiar enough with the "RPM publication" history of Storeman to say for sure. Were there at any point e.g. Because if there were, installed versions would "forever" stay at their original version if any updates were vendored |
The answers to your three questions are: "Yes", "Only But OTOH, the last two SailfishOS releases (4.4.0 and 4.5.0) and IIRC even their point releases removed Storeman (and the SFOS:Chum GUI app alike). So users regularly have to reinstall any way. 😁 I see no choice but to go for the most distributed vendor name, which clearly is P.S.: The same applies to Patchmanager and my corresponding, open (and unreviewed, BTW 😉) PR: Here |
I was wondering if there was a way to let Storeman allow vendor changes at least for self-updates. And indeed even
So the PackageKit install action can perform a vendor change. (The OpenSuSE doc page on vendor changes says this as well, albeit a bit "hidden".) So one solution could be to make Storeman not use the
|
…, regardless where they are built, to avoid blocked upgrade paths (as, e.g., observed in [Storeman issue \#406](storeman-developers/harbour-storeman#406 (comment))) due to [vendor stickiness](https://en.opensuse.org/SDB:Vendor_change_update).
Yes, that would be nice, but solely for self-updates (see below).
Thank you, this is cool. And I just tried that with the Storeman "stuck at 0.3.2": But I really fail to find any such statement on https://en.opensuse.org/SDB:Vendor_change_update
Yeah, if only one could inject a vendor into an extant RPM package. 😏
Unfortunately not: I currently have four update candidates on a device, and the first of them fails (likely due to a damaged RPM file), plus trying to install this one sets Thus ultimately we may consider to let Storeman perform solely its own updates as "install" action, hence ignoring a vendor change. I currently tend to: This is not worth the effort, also because this is not so extremely trivial as to always perform "Install" actions instead of "Update". But I consider the general switch from "Update" to "Install" for updating packages by the SailfishOS:Chum GUI app, because at SailfishOS:Chum there are no packages superseding "system packages" by employed rules for submitting packages, see the first paragraph of the section "Developer's guide" in the SailfishOS:Chum main documentation. But I currently fail to find where: I cease clicking through the tree now, instead I may clone and |
I that agreement isn't in the chum/main repo texts but was mentioned in one of the Forum threads? |
The hint is in using |
Well, the section "Single package Vendor change" states to either update to a specific version or using a specific repository to override a vendor change. But I am glad you used |
Sorry, I pointed to the right document, but the wrong section. Now rectified (changes in italic) the original message to:
Still (because I did nothing in this regard since yesterday, yet):
|
From the final paragraph of this comment:
Now all this has become nicely reproducible for me.
Uff, I simply checked this incorrectly. 😌 So what remains of this thread are the derived considerations for the SailfishOS:Chum GUI app. |
|
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
ADDITIONAL INFORMATION
Maybe I broke something when adapting all the links (primarily by v0.2.12), but I cannot see what!
ssu lr
displays this repo as first user repo.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.cppI 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").An error occurred
Failed to obtain authentication.
[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.
The text was updated successfully, but these errors were encountered: