Chum-GUI: Multiple errors and flaws

[Olf0]

Chum-GUI does not really start (i.e., dies immediately) on an XperiaX@SFOS 3.2.1, when started per GUI.

When called at the command line, it does not really work:

1. No "About" selectable in the pulley menu.
2. "Available packages" page is empty.
3. Each "Reload" and "Refresh cache" does trigger a warning:

[nemo@sailfish]$ sailfishos-chum-gui 
[D] unknown:0 - Using Wayland-EGL
[W] unknown:474 - file:///usr/lib/qt5/qml/Sailfish/Silica/private/PulleyMenuBase.qml:474:13: QML State: Binding loop detected for property "when"

Using the sailfish-qml launcher yields a much worse result: A completely white app and

[nemo@sailfish]$ sailfish-qml sailfishos-chum-gui         
[D] unknown:0 - Using Wayland-EGL
[W] unknown:5 - file:///usr/share/sailfishos-chum-gui/qml/sailfishos-chum-gui.qml:5:1: module "org.chum" is not installed 
     import org.chum 1.0 
     ^
[nemo@sailfish]$ 

P.S.: Initially I did

1. curl -LO https://repo.merproject.org/obs/sailfishos:/chum/3.2.1.20_armv7hl/noarch/sailfishos-chum-0.2.0-1.4.1.jolla.noarch.rpm && pkcon install-local sailfishos-chum-0.2.0-1.4.1.jolla.noarch.rpm
2. curl -LO https://repo.sailfishos.org/obs/sailfishos:/chum/3.2.1.20_armv7hl/armv7hl/sailfishos-chum-gui-0.2.0-1.1.1.jolla.armv7hl.rpm && pkcon install-local sailfishos-chum-gui-0.2.0-1.1.1.jolla.armv7hl.rpm

Thus

[nemo@sailfish]$ ssu lr
Enabled repositories (global): 
 - sailfishos-chum ... https://repo.sailfishos.org/obs/sailfishos:/chum/3.2.1.20_armv7hl/

[mentaljam]

No "About" selectable in the pulley menu.

It is not implemented yet

"Available packages" page is empty.

Can you try something like pkcon get-packages | grep sailfishos-chum?

Each "Reload" and "Refresh cache" does trigger a warning:

Can be a Silica issue

Using the sailfish-qml launcher yields a much worse result: A completely white app and

sailfishos-chum-gui cannot be run with sailfish-qml

[Olf0]

"Available packages" page is empty.

Can you try something like pkcon get-packages | grep sailfishos-chum?

[nemo@sailfish ~]$ pkcon get-packages | fgrep chum
Installed    sailfishos-chum-0.2.0-1.4.1.jolla.noarch (installed)
Installed    sailfishos-chum-gui-0.2.0-1.1.1.jolla.armv7hl (installed)
[nemo@sailfish ~]$ 

This is what I expected.
You seem to have expected something different due to:

[nemo@sailfish]$ ssu lr
Enabled repositories (global): 
 - sailfishos-chum ... https://repo.sailfishos.org/obs/sailfishos:/chum/3.2.1.20_armv7hl/

> sailfishos-chum-gui cannot be run with `sailfish-qml`

Well, that became obvious! 😉
I just documented what I tried.

[mentaljam]

[nemo@sailfish ~]$ pkcon get-packages | fgrep chum
Installed sailfishos-chum-0.2.0-1.4.1.jolla.noarch (installed)
Installed sailfishos-chum-gui-0.2.0-1.1.1.jolla.armv7hl (installed)

It looks like you need to refresh the repo to fix the empty package lists. When launching the app within the desktop file the invoker is used. It allows you to interact with the PackageKit API. You cannot do it when launching the app withing the terminal.

The main question why you cannot launch the app within the desktop file. Can you try invoker --type=silica-qt5 /usr/bin/sailfishos-chum-gui?

[Olf0]

The main question why you cannot launch the app within the desktop file. Can you try invoker --type=silica-qt5 /usr/bin/sailfishos-chum-gui?

[nemo@sailfish ~]$ invoker --type=silica-qt5 /usr/bin/sailfishos-chum-gui
invoker: Invoking execution: '/usr/bin/sailfishos-chum-gui'
Failed to invoke: Booster: Loading invoked application failed: '/usr/bin/sailfishos-chum-gui: cannot dynamically load executable'

[nemo@sailfish ~]$

[mentaljam]

Please, try this https://repo.sailfishos.org/obs/sailfishos:/chum:/testing/3.2.1.20_armv7hl/armv7hl/sailfishos-chum-gui-0.2.0-1.6.1.jolla.armv7hl.rpm

[Olf0]

Please, try this https://repo.sailfishos.org/obs/sailfishos:/chum:/testing/3.2.1.20_armv7hl/armv7hl/sailfishos-chum-gui-0.2.0-1.6.1.jolla.armv7hl.rpm

Behaves exactly the same: Does not start per tap on its icon, does start at the command line, starting per invoker --type=silica-qt5 /usr/bin/sailfishos-chum-gui still yields the same error message (I suppose switching on "position independent code (PIC)" was supposed to fix the latter).

P.S.:

It looks like you need to refresh the repo to fix the empty package lists.

Yes, a pkcon refresh resolves this. Sorry that I did not think of it.

But why does a "Refresh cache" at sailfishos-chum-gui's GUI (in the main menu) not do that?
I tried that before (and now again) and it does immediately respond with "Repository refreshed" (and the aforementioned "when loop" warning at the command line), but obviously does not do what it says.
I.e., another flaw is to output that message, when the repository refresh action was not successful.

[mentaljam]

But why does a "Refresh cache" at ...

Because you have no appropriate rights to update the repo with PackageKit when start the app within the terminal without the invoker. In normal launch with the desktop icon this menu entry would work as expected.

I will try to figure it out why you cannot launch the app with the invoker.

[Olf0]

But why does a "Refresh cache" at ...

Because you have no appropriate rights to update the repo with PackageKit when start the app within the terminal without the invoker. In normal launch with the desktop icon this menu entry would work as expected.

Thank you for the explanation (again); I now understood it in the context of what we try to achieve (I had some disconnect between your statements and my doing, before).

I will try to figure it out why you cannot launch the app with the invoker.

👍

[rinigus]

Not sure it still applies. I haven't gone through discussion, but maybe you could check if the latest version still has this issue?

[Olf0]

@rinigus, thanks for asking and notifying me that there are new packages.
Quick answer: Yes, it still applies, i.e., it still has the core issue discussed here, plus most of the other and some new issues.

Due to your notification I installed https://repo.merproject.org/obs/sailfishos:/chum/3.2.1.20_armv7hl/noarch/sailfishos-chum-0.3.0-1.5.1.jolla.noarch.rpm and https://repo.merproject.org/obs/sailfishos:/chum/3.2.1.20_armv7hl/armv7hl/sailfishos-chum-gui-0.3.1-1.3.1.jolla.armv7hl.rpm on my XperiaX@SFOS 3.2.1

• Starting Chum-GUI regularly per tapping on the launcher-icon results in the app cover showing a spinner for much longer than originally (with v0.2.0), but ultimately it closes itself as before (just not "immediately" any more).

• Starting per invoker … yields exactly the same error message as sailfishos-chum-gui-0.2.0-1.1.1 and sailfishos-chum-gui-0.2.0-1.6.1 did before.

• Starting simply per /usr/bin/sailfishos-chum-gui works … basically (as before, with some minor improvements, but also new bugs):

  • On first startup it showed a spinner and "Get list of packages" for a while, then the GUI was visible and mostly functional. ☺
  • The "About" dialogue works now. ☺
  • Browsing the four "˃"-sections (Updates, Categories, Applications / Packages, Installed packages) works fine.
  • Switching between Applications and Packages per Pulley Menu entry seems to work fine.

  Flaws and errors:

  1. Triggering the Settings entry in the Pulley Menu of the main window does nothing! IIRC I was able to access the settings in v0.2.0. When trying, I see:

     [W] modifyPageStack:113 - Error while modifying page stack: Error: Error while loading page: file:///usr/share/sailfishos-chum-gui/qml/pages/SettingsPage.qml:122 Cannot assign to non-existent property "description"
     [W] unknown:483 - file:///usr/lib/qt5/qml/Sailfish/Silica/PageStack.js:483: Error: Error while loading page: file:///usr/share/sailfishos-chum-gui/qml/pages/SettingsPage.qml:122 Cannot assign to non-existent property "description"
     [W] unknown:474 - file:///usr/lib/qt5/qml/Sailfish/Silica/private/PulleyMenuBase.qml:474:13: QML State: Binding loop detected for property "when"
     

  2. On repeated startup I see:

     $ /usr/bin/sailfishos-chum-gui
     [D] unknown:0 - Using Wayland-EGL
     [D] unknown:0 - SSU repo: true false "sailfishos-chum"
     [W] unknown:0 - Failed to refresh Chum repository "Failed to obtain authentication."
     [D] unknown:0 - GitLab support added for "gitlab.com"
     [W] unknown:0 - Invalid Chum section for "harbour-lyrics;0.5.6-1.2.1.jolla;armv7hl;sailfishos-chum"
     [W] unknown:0 - Invalid Chum section for "date-devel;3.0.0.20210322.sfos.3-1.4.1.jolla;armv7hl;sailfishos-chum"
     

     • The message [D] SSU repo: true false "sailfishos-chum" is confusing (the true false part)!
     • The warning [W] Failed to refresh Chum repository "Failed to obtain authentication." persists.
       • Why do I need an authentication, when this seemed to work fine without one on the very first run (but I also did a pkcon refresh)?
         Likely due to the still non-working invoker thing.
       • The wording is awkward / hard to comprehend: "Failed to obtain authentication." is placed as a repository name, which it sure is not.
       • The package list is not refreshed. The behaviour when triggering that manually (main window: "Refresh repository") is identical to the automatic refresh on startup (including the output at the command line).
     • The two warnings [W] Invalid Chum section for … seem to be metadata errors of these packages, which may hint structural flaws in the process of accepting, building and / or quality assuring packages at Chum-OBS.
       IMO packages with exhibit such errors shall (preferably: automatically) not be accepted in the first place.
  3. The search function seems to also evaluate a package's category, i.e., searching for "library" finds everything in the category Library.
     • IMO this is not helpful, the search shall only evaluate package "pretty names" and their descriptions.
     • IMO it is fine that the search is case-insensitive, but it also does not search for "words" (e.g., in contrast to Openrepos). I.e., any string match results in a hit, which is confusing simple users: E.g. searching for "Imp" would match "simple" (confusing) and "Imperial" (fine IMO). Hence you may want to match strings only on the start of a word, with words being delimited by any non-minor letter (![a-z]) character (by white-spaces, numbers and non-letters to the left and right, by capital letters [A-Z] only to the left), but any non-whitespace character in the search string must be evaluated; i.e. searching for "go" shall match "SailGo", "game-go" and "coffee2go", but not "Farango".
     • Alternatively to the point before: Being able to limit the search solely to package "pretty names" (because e.g., searching for "Go" (the game) basically fails, because of hundreds of unrelated hits) may also alleviate this issue, but means another pulley entry, another way of user interaction etc.; IMO this would be an inferior solution, because optimally a search functions simply finds the right stuff, but not (much) more than that.
  4. An the "invisible" / hidden category "Library" exists, i.e., its packages are not displayed as Applications, which is its very purpose (alike Openrepos). But that category "Library" is also not displayed under "Categories" (in contrast to Openrepos), which is wrong IMO. Thus one is unable to find these packages hierarchically, only going to "Applications" and switching on "Show all packages" there works.
  5. Additionally to the aforementioned (hidden) category "Library", a (visible) category "Libraries" exists (which contains a single package). IMO this is confusing, please merge them; actually the correct name for this hidden category is "Libraries" (Plural), not "Library" (according to my English language knowledge).
  6. I have an update candidate in "1 update available" / "Updates".
     • See PR [PackagesListPage] Enhance wording #78.
     • Trying to update it, results in the GUI message "Failed to obtain authentication." and
       [W] unknown:474 - file:///usr/lib/qt5/qml/Sailfish/Silica/private/PulleyMenuBase.qml:474:13: QML State: Binding loop detected for property "when"
[W] unknown:0 - Failed Chum::PackageOperation(PackageUpdate) "harbour-sailgo;0.4.0-1.5.1.jolla;armv7hl;sailfishos-chum" "Failed to obtain authentication."
       See also point 3 and my questions there; probably this is also caused by still non-working invoker thing.
       Hence I am currently unable to update any package via Chum-GUI. :-(
  7. Other
     I regularly see

     [W] unknown:17 - file:///usr/share/sailfishos-chum-gui/qml/components/PackagesListItem.qml:17:5: QML Image: Error decoding: https://gitlab.com/nephros/harbour-imagemagick/-/blob/obs/files/icon-imagemagick_sfos_256.png: Unsupported image format
     [W] unknown:17 - file:///usr/share/sailfishos-chum-gui/qml/components/PackagesListItem.qml:17:5: QML Image: Error decoding: https://gitlab.com/nephros/openrepos-nethogs/-/blob/obs/rpm/nethogs_512.png: Unsupported image format
     [W] unknown:17 - file:///usr/share/sailfishos-chum-gui/qml/components/PackagesListItem.qml:17:5: QML Image: Error decoding: https://gitlab.com/nephros/openrepos-nload/-/blob/obs/rpm/nload_512.png: Unsupported image format
     

     • Is PNG really not a supported image format?!?
       If this addresses an icon file embedded in an RPM: Yes, this must be a single GIF file (or XPM file), see [1] and [2] for details.
     • If so, these warnings hint a structural flaw in the process of accepting, building and / or quality assuring packages at Chum-OBS: Packages with PNG icons shall (preferably: automatically) not be accepted (as long as PNG is not a supported image format).

P.S.: Jolla heavily opposes using ssu's global section for third party repositories, but this is what Storeman-Installer and Chum / Chum-GUI do. While I have not researched the technical background of this, the consequence for users is to be let down by the Jolla support (see last web-link), because they simply state that you are doing it wrong (also see last web-link). Thus @mentaljam, @piggz and @rinigus, please evaluate, if a repository entry in the user section would also suffice.

P.P.S.: From my perspective this is not usable yet, even when not taking the apparently SFOS < 3.4.0 specific bug of the failing authentication / access rights rsp. failing invoker call and its consequences into account. I really do not intend to frustrate you (otherwise tediously testing and documenting these flaws would not make any sense), but I want to create awareness that SailfishOS:Chum is currently only usable for the ones mastering the command line and the commands pkcon or zypper. Promoting this state of Chum-GUI to regular users will backfire IMO.

Please notify me, when you created a new version, which may resolve some of these flaws (esp. WRT authentication / access rights on SFOS < 3.4.0) and should be tested.

[rinigus]

@Olf0 - thank you very much for analysis! I'll try to address those comments.

Chum repos

Let's start with the last. Chum repository now is in "user" section. That is whether you install sailfishos-chum or (yes, or) sailfishos-chum-gui. When all works (see below), you don't need sailfishos-chum as GUI is expected to add repository by itself using ssu dbus API.

Invoker: no invoker, no GUI

Much of the issues are coming from failure of starting GUI without invoker. As mentioned above by @mentaljam, this immediately disables PackageKit integration and (maybe) ssu. Hence you get all these permission issues, repos are not refreshed, and so on. So, we have to get that running and proper evaluation can start after that.

Whether invoker issue is isolated to you or 3.2.1.20 or bunch of earlier SFOS versions is hard to say. For us, on 4.3 it works without any issues. With invoker, try to run

invoker --type=generic  /usr/bin/sailfishos-chum-gui

Maybe that will help.

Settings failing

I wonder whether older SFOS Silica does not have "description" property for TextField. In Pure Maps, it was implemented using separate Label, maybe for that reason. Anyone knows when description was added? Maybe we should change that part to use older API. That's in case if we can get around invoker issue - otherwise there is no GUI for older SFOS anyway.

Confusing debug messages

Yes, those were made mainly for us while writing. Probably should make them clearer.

As for Invalid Chum section for, that we would have to comment out. It is mainly interpretation of YAML parser result. These packages don't have Chum sections at all. Corresponding commit has been submitted.

Library in categories

This has been corrected in just submitted commit. On a page where you can choose categories, "Libraries" is a correct term. Behind the scenes, it shows packages which have categoryId set to "Library", which should be correct as well. Similar usage is with Games/Game.

Search

I find it very helpful when category is added to search string. That makes it easier to find packages/apps in some cases. Also developer name is searched in addition. Now, your suggestions regarding improving search as illustrated by "go" example are good. Would have to look into how to implement it specifically.

Issues with icons

I accepted those packages after some thought and sent a feedback to nephros. Argument was that it was mostly correct. That one, due to OBS email settings, probably went to spam. So, I'll open issues in the corresponding projects. Hopefully will be fixed in time.

For reference, PNG is supported. Correct URL should point to RAW image, not the one embedded in GitLab UI.

[Olf0]

@rinigus, thank you for your prompt and thorough reply!
It was really helpful; for me and likely in turn for you, too:

Chum repos

Chum repository now is in "user" section.

❤️

That is whether you install sailfishos-chum or (yes, or) sailfishos-chum-gui. When all works (see below), you don't need sailfishos-chum as GUI is expected to add repository by itself using ssu dbus API.

Oh, I always assumed that installing the sailfishos-chum RPM deploys some software, but (because you made me curious) indeed, rpm -q with the query options -l or --dump reveals that it contains no files, only (per query option --scripts) a posttrans- and a postuninstall-scriptlet. Well, that was not obvious to me. Still I fail to find the "source code" for this spec file is here: https://github.com/sailfishos-chum/main/blob/main/rpm/chum.spec

Invoker: no invoker, no GUI working PackageKit integration

Whether invoker issue is isolated to you or 3.2.1.20 or bunch of earlier SFOS versions is hard to say.

IMO the latter ("a bunch of earlier SFOS versions") is the most likely case. This SailfishOS installation (3.2.1@XperiaX) is working quite flawlessly, which is one reason, why I keep it.

invoker --type=generic /usr/bin/sailfishos-chum-gui

Rinigus, you made my day: This is working fine, in contrast to --type=silica-qt5!

Settings failing

I wonder whether older SFOS Silica does not have "description" property for TextField. In Pure Maps, it was implemented using separate Label, maybe for that reason. Anyone knows when description was added? Maybe we should change that part to use older API.

Yes (:+1:), because "That's in case if we can get around invoker issue" = true.

Confusing debug messages

Yes, those were made mainly for us while writing.

Well, that is what debug messages are for; i.e., they do not need to be sophisticated prose, but IMO should be easy to comprehend and unambiguous. If they are not, they might solely be helpful for the original author of a specific debug message (or even less).

Probably should make them clearer.

🎉

As for Invalid Chum section for, that we would have to comment out. It is mainly interpretation of YAML parser result. These packages don't have Chum sections at all. Corresponding commit has been submitted.

I disagree with commit d44b99a:

• These messages were not confusing at all, IMO they are proper and correct warnings with well understandable wording.
  It was the one telling [D] SSU repo: true false "sailfishos-chum" which I perceived as strange (but only the true false part), as originally denoted.
• IMO you could and should be stricter on what you accept in the Chum-OBS and might consider to automatise rejecting stuff, e.g., which makes the YAML parser stumble. I do agree that a non-existing Chum-section is a border case (i.e., this can be tolerated, while still emitting a warning), but IMO any submitted package with real (YAML parser or other) warnings should be automatically rejected.

Library in categories

This has been corrected in just submitted commit.

AFAIU this commit 6dd4fe1 addresses points iv., and partially v.
But looking at it again, I now fully understood why my description of point v. cannot be comprehensible for you:

• Currently a single package is shown in "Categories→Libraries": RRDtool Development
  I still wonder why only this one is shown there but no other package. This may indicate some (logic or other) flaw.
• I misinterpreted the line below its name "RRDtool Development" as a single category name: "Library Graphics Science"
  Now I think that these are three different categories the package "RRDtool Development" is assigned to. If so, please separate multiple categories by commas at the GUI, e.g. "Library, Graphics, Science".

On a page where you can choose categories, "Libraries" is a correct term. Behind the scenes, it shows packages which have categoryId set to "Library", which should be correct as well. Similar usage is with Games/Game.

Absolutely agreed, also in the first place.

Search

I find it very helpful when category is added to search string. That makes it easier to find packages/apps in some cases. Also developer name is searched in addition. Now, your suggestions regarding improving search as illustrated by "go" example are good. Would have to look into how to implement it specifically.

While I still believe that matching a search string against the assigned category names is rarely helpful, matching it against the developer name sure is.
But if the search is narrowed in a (similar) way I described in point iii., I believe that including the assigned categories is O.K.

Issues with icons

I accepted those packages after some thought and sent a feedback to nephros. Argument was that it was mostly correct. That one, due to OBS email settings, probably went to spam. So, I'll open issues in the corresponding projects. Hopefully will be fixed in time.

Here I am mostly worried (again), that detecting and addressing such errors seems to be a fully manual process, which does not (and cannot) be scaled up (without more manpower).
IMO, packages which trigger such warnings or error messages shall be (fully or half-) automatically rejected with a log showing the corresponding message(s).
See what happened here: Now it has become your task to "open issues in the corresponding projects", which is sure O.K. once, only to learn that this must be avoided in the future. It is the packagers task to provide proper submissions to Chum-OBS, and many will be happy about the quick reaction time of an (fully or half-) automated submission-evaluation process.

For reference, PNG is supported. Correct URL should point to RAW image, not the one embedded in GitLab UI.

Is there some documentation for this? I am asking, because sooner or later I will submit some software to the Chum-OBS (with icons to be displayed in SailfishOS-Chum-GUI).
[Edit & answer] Rather a stub (see next message by piggz), hence I filed this issue: sailfishos-chum/main#43

[piggz]

@Olf0 Documentation is here https://github.com/sailfishos-chum/main/blob/main/Metadata.md if you find any problems with it then PR :)

[rinigus]

Related issues opened:

• Drop description in TextField #81
• Replace invoker call for older SFOS versions #82
• Add comma when listing categories #83

Re Icons you submitted an issue already. Note that those issues have been resolved already.

Re manpower and scaling up: currently it is not an issue, let's see what future brings. Note that we can also recruit more to help with Chum administration. Hard to make it fully automatic, though. But let's think about it when we get larger number of submissions.

[Olf0]

Re manpower and scaling up: currently it is not an issue, let's see what future brings. Note that we can also recruit more to help with Chum administration. Hard to make it fully automatic, though. But let's think about it when we get larger number of submissions.

Well, having interacted with the F-Droid maintainers a couple of times, I can assure you that …

• scaling will be limited by manpower at some point of time.
• recruiting more SailfishOS:Chum administrators is likely going to be very hard.
• to "fully" (i.e., 100%) automatise the process of handling submitted packages or their updates is impossible, there always must be some manual review for some checks and balances. But automating as much as possible is crucial when there is not sufficient manpower or the limited manpower prevents scaling up (i.e., to host more packages).

[Olf0]

AFAICS all aspects of this issue have been either addressed and are fixed in SailfishOS:Chum-GUI v0.4.0-1, or have been separated out into other issues. Hence I am closing this issue.

[rinigus]

If we get to that stage as F-Droid maintainers, I'd be happy - it means that Chum succeeded :)