Announcing sailfishos:chum

Applications
#121

Thanks! Then my world is increased as well . :wink:

1 Like
#122

Please consider making the Chum GUI app show all new submissions somehow. Currently it only shows updates to installed packages, whereas in order to check if there’s some new application it takes browsing the whole list of all packages, which (as the list gets longer and longer) gets really inconvenient and time consuming.

I would very much prefer to have it managed the Storeman way, i.e. to have a list of all newly submitted packages, be it a wholly new release or an update. One look at the list and I always know what’s new. Whereas in Chum GUI I can only see if any of the apps I already have installed has been updated, and to find out what else is new it takes scrolling the whole list and trying to spot some new items on it…

3 Likes
#123

Already requested and considered (not quick and easy) - Announcing SailfishOS-Chum-Gui 0.3 - #41 by Levone1

1 Like
#124

This is not a trivial change, but possible. Problem is that with Jolla not committing to OBS (corresponding question has been asked, not replied at the community meeting), it is rather discouraging to start making any non-trivial development for the GUI. When I have to choose if I deal with Chum GUI or something else, something else usually wins.

5 Likes
#125

Then how about a simple choice of list sorting method: either alphabetically (as it is now) or by release date (e.g. by the date of the most recent version as displayed in the “Releases” tab). Would that be difficult to do?

3 Likes
#126

“Releases” are available only for packages that have linked to their Github / Gitlab repo and are publishing releases. This is far from majority. Also that information is not available fast, only after all packages have been queried for that.

So, no, it is not as trivial as to change sorting order to the available field.

1 Like
#127

Corresponding issue opened, feel free to comment: https://github.com/sailfishos-chum/sailfishos-chum-gui/issues/126

2 Likes
#128

Question from an ignoramus on the politics of repository management: is there some deep reason Sailfishos:Chum GUI app cannot be in the Jolla Store, since also Aptoide (which frankly does not have a sterling reputation security-wise) is there?

1 Like
#129

CHUM is a repository for libraries and native applications,applications on this repository are not subject to the same security rules and are not all in sandboxes.
Aptoid is an android store, AOSP is in a LXC container, no risk that an APK modifies the file system of SailfishOS.

#130

Can’t tell from the top of my head, but there was something that we use in Chum GUI which prevents it from being accepted in Jolla Store.

2 Likes
#131

if this is reviewed and found to be resolvable somehow i would be delighted.

would like to see this available to [all] users - regardless of technical confidence.

1 Like
#132

CHUM is a repository for libraries and native applications, applications on this repository are not subject to the same security rules and are not all in sandboxes.

Thank you for clarifying, as I said I am something of a dilettante when it comes to repository politics. Can someone point me to the procedure of how applications get accepted into the Jolla store, I assume they are somehow thoroughly vetted?

#133

server not found, it says.

#134

… and obviously also when using internet search engines, plus reading documentation.

The first three hits when searching for jolla harbour rules with Google / Startpage provide:

If you take a look at SailfishOS:Chum GUI application’s source code, you can easily see, that it does not conform to harbour rule 2.11.0.

I have no idea how to work around this and other non-compliances, do you?

#135

… and obviously also when using internet search engines, plus reading documentation.
Thank you so much for your kind words, a reception like this makes me so eager to be a part of the community. /s

3 Likes
#136

Looking at the actual rpm package file at https://github.com/sailfishos-chum/sailfishos-chum-gui/blob/main/rpm/sailfishos-chum-gui.spec the following %postun section seems to be the only(?) problematic bit for this rule:

%postun
ssu rr sailfishos-chum || true
ssu rr sailfishos-chum-testing || true
rm -f /var/cache/ssu/features.ini || true
ssu ur || true

So, the housekeeping needed to uninstall the package is problematic because it gets run as root (and of course could do bad things at that point). What is the normal Jolla-approved procedure to do this kind of cleanup?

#137

It could for example be done as part of normal operation. I don’t see it registering the chum repository as part of the rpm for example, so why should it need to be part of the clean up? Indeed registering the repo is done in the c++ code it seems. So a possible alternative implementation could be to have the application register the chum repo, install what ever app is selected, and then unregister the chum repo again, leaving the system in a clean state. I.e. now the system is always in an unclean state once chum has installed a package, which is probably not desirable.

Also this code does’t properly handle user state. If I manually added the chum repo (i.e. as a user configuring my system I ran ssu addrepo) this code will remove it again.

3 Likes
#138

You are welcome! :blush:
I just feel obliged to clearly denote the mindset “searching the WWW and reporting the result in this forum costs me much more effort than asking in this forum and let somebody else do the searching and reporting” in a strongly negative manner in order to deter copycats.
Still I usually provide proper answers, if I can see some value in checking if my memory is valid and up-to-date, or documenting a proper answer.

But by …

… you just try again: You have the pointers, build an own opinion by reading the docs and present your findings here. Mind that Jolla’s documentation is sometimes a bit inconsistent (mostly due to very differently dated documents being online), hence shall read all relevant docs to come up with a well founded opinion. If my assessment of Jolla’s docs deviates from yours, I will speak up.

#139

@d.geelen, there are many reasons, one of them being that any app can be killed at any time, e.g., by the user, OOM-killer / “-reaper” / “low memory killer” etc. There are many signals to catch properly (I do not know how and which generic signals are handled currently) and some events cannot be caught at all (the OOM-reaper simply kills you).

Hence it is reasonable to perform cleanup-work when the RPM-package is uninstalled.

As already pointed out, these forbidden %postun scriptlets were just the first example I could think of: A thorough assessment sure reveals more breaches of Jolla’s “Harbour”-rules.

Pull Requests at GitHub accompanied by a proper reasoning why this changeset makes sense, are usually welcome.

BTW, the fact that one shall not manually configure SailfishOS:Chum repositories, install the SailfishOS:Chum repo-configuration helper-RPM and / or the SailfishOS:Chum GUI application in parallel (i.e., concurrently) is clearly presented in the corresponding READMEs at OpenRepos.

1 Like
#140

I would also like to point out that whereas Android uses purpose-built APK packaging, Sailfish uses pretty much vanilla RPM packages with restrictions (e.g. no %postun scripts allowed). Android APK and permission system allow, for example, background services which is not yet supported by Jolla Store rules. Extending the allowed features with RPM packaging in a controlled manner is a non-trivial task to do due to the original design of RPM.

(But then again, when was the last time you even saw the list of permissions an Android app has? WhatsApp asking for the camera permission is merely a polite gesture, considering all the other permissions it has simply by installing it…)

5 Likes