Announcing SailfishOS-Chum-Gui 0.3

Applications
#1

The “chum” devs are proud to announce the release of version 0.3 of the Chum GUI.

This release brings many many new features and improvements for both users and developers.

Instead of being a simple GUI for the RPM repository, the application now adds many features you would expect from an “Application Store”.

  • Install/Update/Remove options
  • Application Icons
  • Screenshots
  • Developer Details
  • Repository Details
  • A way to donate to the developers
  • Integration with Github/Gitab
    • Links to releases/changelogs
    • Issue List
    • Discussion forums

All this is powered not by a web application backend, but by simply adding meta-data to the application package description, makng it super-simple for developers to manage. Our meta-data additions are based closely on the AppStream spec, can be added in a way to be ignored by other packaging systems, and is fully documented here https://github.com/sailfishos-chum/main/blob/main/Metadata.md

The GUI now adds and manages the repository, so there is no need to install the seperate sailfishos-chum package, its also super easy to switch between repositories, or pin to a specific release (useful for early-access users when no matching chum repo is available). Grab the GUI package from https://chumrpm.netlify.app/

You will notice that not all entries are populated with all the above new data, that will rely on application developers adding the meta-data over time. Some applications may be filtered out of the list because they do not have the metadata (eg patchmanager), to fix this, goto settings and uncheck 'Show applications only by default’

We hope you enjoy this release and look forward to your feedback.

-chum devs

51 Likes
Introducing new tool: Bugger!, the inofficial SFOS Bug Reporting Tool
New tool: Link2Clip
New Settings Tool: Edge Swipe Control
SFOS 4.5 feedback thread
Sailfish Community News, 10th February, Sailfish SDK, PinePhone Pro
SailorD systemd viewer application
No Android Support for FX Pro1x
Installation History app
#2

wow, lovely, thanks Adam and all the Chum devs!! <3

1 Like
#3

Mostly @rinigus ! :slight_smile:

#4

Clean, clear, seems solid. Cool, thanks.

#5

Has been team work throughout with the large part of figuring the design out. Now we can only hope it will be adopted by users and developers.

7 Likes
#6

Very basic user, very basic question:
Let’s say I like the description of a package and wish to install it on my device.
I don’t know the developer work/posts/reputation.
Is there a risk that the app/patch/prog contains harmfull or spy code?
Or a way to check? (when I read source codes, it is mostly like martian to me)

4 Likes
#7

Good question. One thing you can be sure about is that packages in chum are built from source and in a reproducible way, similar to f-droid foe Android. Packages on openrepos or the Jolla store are binary uploads, so, while its impossible to say if any particular package is safe, you do at least have the ability to find out. In addition, packages backed with a github repository will show the github star count, as an indication to how liked the software is.

6 Likes
#8

wow!! very beautiful! :heart_eyes:

#9

So, does this now replace openrepos/storeman?

I’m a little confused at what I should now be using for community apps?

#10

No, this doesnt replace openrepos/storeman, it supplements it. In the future, maybe, but for not yet. The more devs/users who use it, the more popular it will become.

1 Like
#11

Ok, but I’m still confused. So, for example, both Storeman and your new GUI for Chum tells me I have updates for installed apps such as Pure Maps. Which should I use to update these apps? Or doesn’t it matter?

1 Like
#12

As @rinigus is behind pure maps and also chum, I would recommend chum in this case. My own apps, advanced-camera and amazfish etc will only be updated in chum going forward. Im not sure if storeman is showing that a general update is available, and that it will be installed from chum, or, if the openrepos version is also updated.

3 Likes
#13

Cool progress! Thank you.

I will have to say I find it a bit annoying that there is now yet another place to manage metadata in some almost-but-not-quite-like-the-others format.

AFAICS some random project may have bits and pieces of the the same information in various forms in

  • a .yaml file
  • a .spec file proper
  • the .spec file %description for chum
  • a .changes file
  • the OBS package name and description
  • a OBS _service file
  • a .pro file
  • some other build-specific config file (CMake, autotools etc)
  • Openrepos name, description, changelog
  • github action/gitlab ci yaml file
  • a .desktop file (esp. with sailjail)
  • QML files (e.g. About pages)
  • other source files (Qt.application.name etc)

Not a critique for your efforts at all just - you know - annoying. It’s almost as if the old spectacle-yaml-generates-stuff made some sense after all :slight_smile:

Anyway, anyone up for a patch to spectacle to generate the chum .spec metadata from .yaml?

1 Like
Sony Xperia 10 II Review (a lot of problems)
#14

I seem to remember installing an update from chum with the Jolla store app. But it may have been storeman. I mentioned this seemed like a bit of a security fail, but someone advised it’s the default behaviour (not to favour the original repo)?

1 Like
#15

At this moment, OpenRepos has a larger selection of software. So, you maybe not able to replace all the requirements by Chum provided software. OpenRepos has also proven itself over long time, something Chum still has to do.

@piggz already explained the main differences between Chum and other software channels in Sailfish. I would like to add few aspects. By compiling software at OBS, Chum is able to generate repositories for different SFOS versions. So, if software supports it, you can install it from repository matching SFOS version on your device, being it 3.2 or 4.3.

When comparing with OpenRepos, you don’t have to enable many repositories and hope that they are compatible with each other. In the case of Chum, you enable one repository (done for you automatically) and we (Chum admins and all software developers) are trying to keep software within that repository compatible with each other as well as base SFOS.

For my software, Pure Maps, OSM Scout Server and few others, I suggest to use Chum. I haven’t thought through on whether to stop distribution via OpenRepos or pause it at there. I guess that will come when I get to release next versions. But already now, latest version of Presage based keyboard (developed by few of us under https://github.com/sailfish-keyboard/) is available only via Chum.

Finally, Chum has a protection against mixing software channels by setting vendor to the packages. This should ensure that if you installed software from some other channel, Chum should not overwrite it. And the same goes in opposite direction. Thus, when switching to Chum, you may have to uninstall that package first and reinstall it from Chum.

6 Likes
#16

Hmmm. The new chum gui asks that I remove the chum repos first. Why? And second question, does this include sailfishos-chum-yggdrasil or just sailfishos-chum?

EDIT, I tried just removing sailfishos-chum, which works. Which repos are being used? EDIT: looks like: https://repo.sailfishos.org/obs ?

#17

This is to make it possible to add and change Chum repo via GUI. It would not ask you to remove sailfishos-chum unless you have it disabled. GUI is using repo aliases sailfishos-chum and sailfishos-chum-testing, depending on which version of the repo have you selected in Settings. If repo is disabled, SSU does not list it in DBus call and we fail when we try to add repo via SSU as it is using the same alias.

As for which repo exactly is used - cannot comment as you have the same repo defined twice. I guess you need to investigate.

#18

I know exactly what you mean. We have been discussing options in the design stage and it was the best we could come up with. Note that we reuse as much as we could from your RPM SPEC and just need data that was not there in addition.

Target was to make it as developer friendly as we could. Notice that communication with users is via the channels that developers specify allowing you to use GitHub/GitLab issues, releases, discussions. Much of it is autodetected and set what we though would be sensible: issues and releases are linked based on your project URL if we recognize it to be from GitHub/GitLab; type is set to desktop-application if package name starts with harbour-.

If you look at Pure Maps section (https://github.com/rinigus/pure-maps/blob/master/rpm/harbour-pure-maps.spec#L77), I could have omitted PackageName, Type, and Repo. Those were all set as we used Pure Maps record during development.

Missing data: Categories, Icon, Screenshots, Donation link are all what are not possible to derive. Categories could have been set based on Group property, but that one is not used, to my knowledge, by SFOS apps and even Fedora seems to retire it. Screenshots, icon are all expected to point to your repo, making it simple to change.

As for spectacle patch - not that I am aware of. I wonder whether description field in yaml would just work as before or it is a new obstacle. Personally I am writing SPEC directly as that yaml-based generation became more of a hassle.

2 Likes
#19

Um. The sailfishos-chum-yggdrasil repo is part of the install image. I assumed it’s device specific? In any case, removing sailfish-chum allows the gui to start and it seems to work. It’s a bit confusing not seeing chum with ssu lr:

Enabled repositories (global):

Enabled repositories (user):
SNIP

Is this correct?

#20

You should see it in the User repositories after the GUI has added/refreshed it.

The yggdrasil repo will probably stay for now as the device image build requires some packages from chum, but dont confuse this with the repo added by the GUI.