Announcing SailfishOS-Chum-Gui 0.3

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

#28

@nephros: few comments:

  • you can check your metadata submissions by compiling at chum:testing, starting Chum GUI and, in its settings, selecting testing repository. That would change chum repo to point to chum:testing and you could see how your new metadata looks.

  • when setting screenshots or icons, use “raw” URL. For GitLab, something like https://gitlab.com/nephros/harbour-imagemagick/-/raw/obs/files/icon-imagemagick_sfos_256.png . That is the one that can be loaded by QML Image from using that URL as a source. If image is in this “pretty” format surrounded by GitLab/GitHub elements, QML Image will fail to load it.

#29

If Chum-GUI shows update available for multiple packages, and even if I choose to update only a specific package (going to app page and selecting update from pulley menu or by long pressing package name), it updates all the update available packages. Is that the intended behaviour? Shouldn’t there be a way to update only a selected package.

Believe the behaviour is same in Storeman too, unable to update individual packages.

#30

This happened to me as well, although I thought I must have done something wrong at the time. Perhaps I didn’t after all.

#31

Same experience. I’m going to report this as a bug.

#32

That has always been this way with cusrom repos, also pkcon install behaves like that.

I believe it’s a limitation of packagekitd.

1 Like
Installation History app
#33

We call update API as it is supposed to be for single app update. For some reason it still updates all. Same can be observed if you update using pkcon update packageName. So, please file an issue at packagekit repo against pkcon. I didn’t see such issue there, maybe missed it.

3 Likes
#34

Storeman updates can be done individually. Package by package.

Edit: At least it appears that way. But that may just be that one ‘Installed’ message didn’t display? I had two updates (in planet_os repo) selected one (Beam Calc) and updated. Got a success message. But the second update appears to have been made withOUT a message being displayed. Hmmm. Well, I’m doing a bunch of updates so I can test it, I guess.

#35

Oh, the message will just be for the package you select. It will still install all updatable packages in the background.

2 Likes
#36

Yeah, I can sadly confirm that. I had to wait for some updates I uploaded to openrepos to confirm :). It even seems to span more than repo. sigh.

#37

Ah well, best to keep everything up to date anyway :smiley:

#38

Do not mess with running system :slight_smile:

#39

is Chum GUI v1.0 the moment where Sailfish Chum becomes the app ‘solution’ for Jo User?

Chum is obviously in development right now, fair enough, but curious when its going to reach a level of usability where ‘Jo’ is invested in using it…

#40

For bg info - we were considering releasing the last version as 1.0. In the end, we went with the increment of the version number to

  • have a chance to fix bugs if they come out after such larger rewrite
  • allow to translations to catch up

The bugs reported so far are not really a show-stoppers in my understanding. I think you can use it already.

5 Likes