Announcing SailfishOS-Chum-Gui 0.3

Applications
#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.

#21

Hmmm. I restarted, refresh ran. I still don’t see it. Just what I pasted above. ? I do see that Sailfishos Chum is installed which, I assume, is the repo?

#22

@poetaster: relevant code is in https://github.com/sailfishos-chum/sailfishos-chum-gui/blob/main/src/ssu.cpp

Your original installation had 2 Chum repos defined. In this case, GUI repo management avoids any repo handling and asks you to fix it. After you removed one of the repos, GUI was happy and could use the remaining one.

As in your case Chum repo is given as system-wide one, I am not sure you can change from regular repo to testing using Settings. Such switch is handy for developers as when you compile the app in :testing, you could check that metadata is detected correctly before you promote it to the main repo.

In your case, you could also disable system wide Chum repo and then GUI should work without problems in terms of switching between Chum versions.

/cc @piggz

#23

Ok. Since it appears that the device version (which piggz suggests is required) functions and I can identify it, it’s not a big issue. It was just a bit confusing. Thanks!

#24

Most of “my” packages on Chum are not developed by me, I merely package them. So usually I have

  • either a tag_git repo maintained by me, upstream by someone else
  • or a tarball and .spec file on OBS
  • URL: or SCM: fields pointing to the original sources (some of which are on github) in the .spec file
  • now added a DeveloperName: nephros tag to chum metadata section (but usually no other links like Custom Repo)

Chum GUI now shows for some packages e.g. nephros (google) or (nephros (somedevelopername) if the URL given points to github sources belonging to google or somedevelopername…

Is that intentional? Are these name (name) fields to be understood as maintainer (author)? Or am I using some fields wrongly? Or does the “guess developer from github” function need some tweaking?

#25

@nephros, thanks for raising it. Currently, expected field is to point to the original developer in the form DeveloperName (DeveloperLogin). For example, Adam Pigg (piggz) or similar for organizations. In the case of Github/Gitlab, name and login are queried from repo. If DeveloperName is specified in SPEC, that one is never overwritten. As in your SPECs nephros is given in SPEC, login is acquired from Github (let’s say google) leading to your results. Which clearly points to multiple shortcomings in our API.

API makes sense for the case where you have original SFOS apps in Chum. In this case, the author is packaging as well. In the case of common libs, tools, we don’t have currently ability to specify:

  • packager
  • packaging repo

I know that Ubuntu Touch store at one point added packager as separate entry. That allowed to distinguish the author and packager to give the credit to the both. I think we should do the same. So, I guess we should add PackagerName and, under Custom, PackageRepo. Question will be then where to display packager name (maybe under author, as Packaged by: packagerName), issues/releases from packager repo. Latter would make it rather crowded if we add it under issues/releases of upstream.

In addition, we don’t have DeveloperLogin as an option for SPEC metadata. Not sure if it is needed or we should suggest to enter name as “Name (login)” in the corresponding metadata section (DeveloperName). If we don’t add DeveloperLogin then we should avoid setting it if the name comes from SPEC.

I have opened issues regarding those at

Would be great to get feedback either here or at Github regarding these. That would allow us to implement it in the most sensible manner.

/cc @piggz

1 Like
#26

Makes sense, thanks for explaining/acknowledging.

From my PoV, the maintainer/packager is most important for the overview list in Chum GUI. This is where users I think expect to find familiar names from the SFOS dev community, and not necessarily author/developer names they might not know or care about.

Original author credits are obviously okay to have somewhere as well, but can be treated just like the link/support/donation subsections, i.e. displayed in the package details.

Therefore, IMO, iff there is a DeveloperName in the metadata, that should be there in the overview list. Github autodetection only active if that is absent*.

Everything else can be displayed in the package details as required/present.

*) ( if DeveloperName can be free form enough to do entries like Aragorn s.o.A. (elessar), one true Heir to the Throne of Gondor although he really would prefer just to stay Strider at the Pony and drink some ale (which does come in pints!) or more reasonably Peter G. (nephros), Patchmanger Dev Team, I think adding additional fields like DeveloperLogin, PackagerName etc can be avoided. Which they should if possible because lets be honest, will people bother to fill them…

3 Likes
#27

I have started working on it. DeveloperName can be given as a free string - tested in the form Test me (testme) and it went through. So, if set, Login fetched from GitHub will be ignored.

I will look into packager and packaging repo specification as well. Will work on implementation and then we can review it at PR stage.