4.4.0.64 got added to obs most likely, nothing to worry, though redownloading all apps after every update seems bit weird
No, 4.4.0.64 was added “weeks” ago. And it wouldn’t cause the update of every package anyway… I think. I’ve never seen this behaviour before.
That .64 target was a ‘fake’ one, just .58 in disguise.
Now the proper one was added, which caused OBS to rebuild the world.
You can see that for most packages, the last section of the revision was increased whichis what OBS does in such cases.
Thanks! Then my world is increased as well .
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…
Already requested and considered (not quick and easy) - Announcing SailfishOS-Chum-Gui 0.3 - #41 by Levone1
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.
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?
“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.
Corresponding issue opened, feel free to comment: https://github.com/sailfishos-chum/sailfishos-chum-gui/issues/126
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?
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.
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.
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.
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?
server not found, it says.
… 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:
- https://harbour.jolla.com/faq
- https://docs.sailfishos.org/Develop/Apps/Harbour/
- https://github.com/sailfishos/sdk-harbour-rpmvalidator
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?
… 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
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?
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.