"Refresh repository" or switching from / to the Testing repository does not reload data referenced in the Chum-metadata

[Olf0]

SailfishOS:Chum GUI application VERSION (<Top pulley> → About): Tested with v0.5.6 but very likely affects all versions since at least v0.4.0.

BUG DESCRIPTION

Updated, external information the Chum-metadata of a package references (i.e., links to) is not refreshed by "Refresh repository" or switching to or from the Testing repository. Only closing and restarting SailfishOS:Chum GUI app displays the current information.

STEPS TO REPRODUCE

I recently created an updated icon for the SailfishOS:Chum GUI app, but missed to upload it to GitHub; note that the Chum-metadata in the RPM spec file stayed the same, because the updated icon carries the same name as the prior version.

I realised that I missed to commit the new icon to the sailfishos-chum-gui repository at GitHub, when I looked at the SailfishOS:Chum GUI app's package in the SailfishOS:Chum GUI app. So I left the SailfishOS:Chum GUI app open on my phone and uploaded the overhauled icon to its source code repository via PR #158. After PR #158 had been committed, I went back from the package view (showing the SailfishOS:Chum GUI app) to the main page, then again to the "Applications" page and searched for "GUI" again: Still the old icon was displayed, also when I entered SailfishOS:Chum GUI app's package page again. So I went back to the main page for another time, triggered "Refresh repository" in the top pulley and repeated aforementioned steps: Still the old icon was displayed! Then I remembered the former test case (see issue #103) of switching to the testing repository and back: After each step still the old icon was displayed when looking up SailfishOS:Chum GUI app's package page.

Ultimately only closing the SailfishOS:Chum GUI app and restarting it showed the current Chum-metadata. I assume this does not only affect all the data the Chum-metadata references, but all data from a spec file (version etc.), though I have not tested this explicitly.

ADDITIONAL INFORMATION

This might be related to issue #103: They share some similarities, though the test case is quite different.

Combining both observations (#103 and #165) might be helpful to understand and test these bugs quicker and easier.

P.S.: Edit (2023-04-08) in italic and struck out.

[Olf0]

Re-tested with v0.6.0: "Combining both observations (#103 and #165)", plus now observing that also the lists of issues and releases are both not updated by Refresh repository and additionally issue content as well as content of a release, regardless how often, in which sequence and how (via the pulley menu entry or by switching between testing and regular repo) one triggers Refresh repository or switches between pages.

I conclude that even though Refresh repository seems to do something, no new data is ever used by the SailfishOS:Chum GUI app. I.e., it only loads fresh data on start-up (presumably with / by / immediately after the initial, automatic repository refresh), which is then displayed during its whole run-time! Consequently the Refresh repository pulley menu entry is currently useless.

[Olf0]

Another indication for aforementioned conclusion: After switching to the SailfishOS:Chum:Testing repository most often new versions of installed packages become available; trying to install one fails with Subprocess failed. Error: RPM failed: error: unpacking of archive failed: cpio: Bad magic.!

As described before no "Refresh repository" or switching back to the regular repo and forth to the testing repo again (regardless how often) does fix that; solely restarting the SFOS:Chum GUI app does.

[rinigus]

Yes, all data pulled from Github/Gitlab is not refreshed on "Refresh repository". Only RPM repo provided data is refreshed, such as RPM versions. As Github/Gitlab operations take long time, it was a compromise that was made during a design.

As for "Subprocess failed. Error: RPM failed: error: unpacking of archive failed: cpio: Bad magic." - hard to say. Could be something in pkcon.

[Olf0]

Yes, all data pulled from Github/Gitlab is not refreshed on "Refresh repository". As Github/Gitlab operations take long time, it was a compromise that was made during a design.

I assume this operation is performed on application start-up: That does not take very long. Furthermore "Refresh repository" is triggered by the user, hence it may take long, because (s)he wanted it.

IMO this design decision was made solely from a developer's perspective: A user cannot, should not, must not and does not know which data is retrieved via Web-API and which as RPM repo data. The "does not" stems from the fact, that this design decision is not documented anywhere.

Thus this design decision shall be revised IMO. A user can expect all data from a repo to be refreshed when the SailfishOS:Chum GUI app is explicitly commanded so. Thus this constitutes a bug.

Only RPM repo provided data is refreshed, such as RPM versions.

No, it is not (at least on the GUI), for example if you look at the testcase in #103: The currently available version is RPM repo provided data and neither "Refresh repository" or switching between the two repos refreshes that. It may be a different bug in the evaluation logic of the RPM repo data (this is why I left #103 as a separate issue), but the similarity is high.

As for "Subprocess failed. Error: RPM failed: error: unpacking of archive failed: cpio: Bad magic." - hard to say. Could be something in pkcon.

Well, the point is: I tested this with two different RPMs which I freshly uploaded and it is 100% reproducible. When it happened, it occurs persistently regardless what I did, until I restarted the GUI app, then these RPMs installed flawlessly on the first try!

[rinigus]

I assume this operation is performed on application start-up: That does not take very long. Furthermore "Refresh repository" is triggered by the user, hence it may take long, because (s)he wanted it.

We have two separate updates: one is for RPM repo refresh (the one you trigger) and the second one running in a background for fetching all data linked from SPEC. The latter one is slow, as it goes through all packages and gets info regarding it. Try to start GUI and notice how stars appear in the package list.

In practice, we have difference in metadata that is rather infrequent and can trouble mainly packagers. So, I suggest to document it and state that this is intended behavior.

Re #103 - replied there.

Re subprocess failed: just swapped to testing and updated without any issues. Couldn't reproduce it here.

[Olf0]

We have two separate updates: …

In practice, we have difference in metadata that is rather infrequent and can trouble mainly packagers.

I thought about this point over night and came to the same conclusion.

So, I suggest to document it and state that this is intended behavior.

I will consider that.

Re subprocess failed: just swapped to testing and updated without any issues. Couldn't reproduce it here.

I will try to reproduce it again, when I have another update candidate at hand. And then look for other factors which may contribute to this behaviour.

[rinigus]

Good. Let's see if this subprocess issue will be come up again

[Olf0]

As this issue does serve well as a preliminary documentation, that »"Refresh repository" or switching from / to the Testing repository does not reload data referenced in the Chum-metadata« is intended behaviour, I adapted the issue title accordingly.

P.S.: I will open a new issue referencing my first comment addressing the message Subprocess failed. Error: RPM failed: error: unpacking of archive failed: cpio: Bad magic. when it happens again.

[Olf0]

P.S.: I will open a new issue referencing my first comment addressing the message Subprocess failed. Error: RPM failed: error: unpacking of archive failed: cpio: Bad magic. when it happens again.

I likely won't, although it did happen again, but also when updating packages via Storeman. Even though Storeman and the SailfishOS:Chum GUI application share some concepts how to install and update packages, this rather indicates something specific to this SailfishOS installation; after a reboot some packages updated fine.
_{I will continue to observe this (involuntarily) and may investigate more in depth.}

[Olf0]

P.S.: I will open a new issue referencing my first comment addressing the message Subprocess failed. Error: RPM failed: error: unpacking of archive failed: cpio: Bad magic. when it happens again.

I likely won't, although it did happen again, but also when updating packages via Storeman. Even though Storeman and the SailfishOS:Chum GUI application share some concepts how to install and update packages, this rather indicates something specific to this SailfishOS installation; after a reboot some packages updated fine.
_{I will continue to observe this (involuntarily) and may investigate more in depth.}

Was able to pin this message to s single RPM package update, which was not easy due to issue #67: There were multiple update candidates and the error text emitted by packagekitd (then displayed by the SFOS:Chum GUI app, Storeman or pkcon) does not tell which one is the cause.

By the help of zypper I was able to identify the troublemaker, then verified it via pkcon download and rpm -qi.

It occurred because the RPM package was compressed with zstd and I used a SailfishOS release < 4.3.0. A %define _binary_payload w2.xzdio in its spec file resolved that.