Announcing sailfishos:chum

piggz · 20 July 2021 17:50

Today we are announcing a new repository for Sailfish application distribution.

Sailfishos:chum aims to be the community repository based within the community
OBS (Open Build Server) system and is available to all sailfish developers.

Chum differs to OpenRepos and Jolla Store by providing reproducible builds, from
source, against all available SailfishOS releases and all available architectures.

By collecting the software in a single automated build system, we can benefit
from collaboration between developers through shared packaging of required libraries,
reduce duplication of the work by keeping the packages up to date, and get a clear
overview of missing software.

For full information, see the readme at GitHub - sailfishos-chum/main: Documentation and issues

Getting-Started documentation for devs not used to OBS is at

github.com

sailfishos-chum/main/blob/main/GettingStarted.md

# SailfishOS Chum - Getting Started with OBS

This document summarises the proces of building your first package on 
OBS.  It only skims the surface of OBS and is not a manual.

To start building your packages on OBS you will require an account.
Follow the process in the README and contact 'lbt' for an account to 
be set up.

When your account is set up, you will have a "Home Project".  This is where
you can start creating packages.  The URL for your home project will be:
https://build.sailfishos.org/project/show/home:<username>

## Creating a package on OBS

Projects contain packages which are built against target repositories
(sailfish versions, not source/git respoitories).

### Prerequisites

This file has been truncated. show original

And our maintainer checklist documents the checks we will be looking for in submitted packages

github.com

sailfishos-chum/main/blob/main/Maintainer.md

# Maintainer's tasks on submission

On initial submission, maintainers are expected to check:

- `_service` file has specific git tag or commit ID. Alternative is
  source submission via compressed archive

- `_service` should not include any webhook

- license in RPM SPEC is open source and matches software license in
  repository or submitted archive
  
- license tag is one of https://github.com/sailfishos/rpmlint/blob/master/rpm/sailfish.toml#L152

- no binary blobs, such as precompiled libraries or applications, are
  submitted as a part of submission. Bundled databases or similar are
  allowed.

After checks,

This file has been truncated. show original

We will make the repository easily available as a package which can be installed from
OpenRepos and really encourage both developers and users to get involved and make
as much software as possible available for Sailfish. If you can’t wait, then the
repository can be added by installing this RPM which will work on all arch’s and releases:
Index of /obs/sailfishos:/chum/4.1.0.24_armv7hl/noarch and download the sailfishos-chum rpm.

The OBS project is at Show sailfishos:chum - SailfishOS Open Build Service.

Please discuss and ask questions below, and feel free to ping us on IRC if you want to ask anything
specific and to get involved.

@piggz and @rinigus

JoOppen · 20 July 2021 18:00

This is great!!!

nephros · 20 July 2021 18:49

Wow, tremendously cool.

As I’m aware of, but not familiar with OBS, I have the following semi-random Questions:

I maintain and build my packages elsewhere at the moment (GH actions, GL Ci, locally on the device, using coderus’ docker images etc). Is it possible to submit a package to chum testing while having it built elsewhere?
Is there a guide somewhere how to migrate from e.g. gitlab CI to the OBS builder?
Which QA rules apply for things submitted to chum testing? (Install locations, naming conventions etc).
Should I take care about splitting packages into -devel -doc -debuginfo/source etc or will OBS take care of that?

Thanks for any replies.

piggz · 20 July 2021 19:15

Thanks for the first good set of questions, I’ll try my best, and @rinigus may chip in.

Its possible to submit pre-built binaries to OBS (thats how we do the android packaging in ports) but for chum, i think its best if we build from source
2, No, we dont have a guide, but can add something to the documentation repo. Building on OBS is very easy though, just take a look at the other packages, all you need to provide is the _service file which points to the source repo, and everything will be built.
Currently we dont have any rules, its almost the wild west, except we ask that you try not to break anything. This may be revised as we progress.
AFAIK, and I may get corrected, OBS will do you debuginfo and debugsource packages, but doc and devel would be down to your .spec file.

rinigus · 20 July 2021 19:24

@nephros - nice set of questions, indeed. Just expanding on @piggz reply regarding few aspects.

Re building at OBS and guide: I presume you don’t have account at OBS yet. For start, you could ask for one by pinging lbt at #sailfishos. Be patient, he may respond with some delay, but always does. As @piggz replied, look at _service files - those will instruct OBS on how to pull your sources and build is automatic from there. If you wish, I can make an example from one of your projects and we can see how it works.

Re binary uploads: whole idea is to avoid them. So, when new SFOS will come out, it can build your software against that version as well. As a result, you don’t worry about arch either, all are covered for you.

Re QA: as it is community repository, we don’t have anything set in stone. There is a section regarding QA in README/Developers and consider it as a first draft. We can argue about it and change it accordingly. Should be some kind of compromise between all of us.

throwaway69 · 21 July 2021 08:11

Quick question as this point is a bit unclear:

Can I use the compiled RPMs of my software to upload it to OpenRepos? While you can do so, it is not recommended as it will prevent users from distinguishing whether the software was installed from chum repository or came from some other source. For a way to compile the packages using OBS, see the response above.

Is it a good idea to migrate apps from OR to chum then? On one hand you should be able to access all your apps (with a verified build) with just one repo added vs not having comments/description etc that OR provides, are the packages going to conflict? Install side by side? Or will chum version overwrite them?

rinigus · 21 July 2021 08:27

Is it a good idea to migrate apps from OR to chum then? On one hand you should be able to access all your apps (with a verified build) with just one repo added vs not having comments/description etc that OR provides, are the packages going to conflict? Install side by side? Or will chum version overwrite them?

As we don’t have GUI nor comments at chum, it is a compromise. I hope someone can figure out some GUI integration and website frontend. Storeman authors? Maybe some integration with OpenRepos is possible?

I will be probably publishing for now in the both places + Jolla Store for Pure Maps. But it does make sense to migrate at least for me and I hope I can focus on publishing via Chum mainly at some time in future.

Chum apps/packages should not overwrite your installed packages as they have chum set as vendor. So, at least zypper needs zypper in -f harbour-app-name to consider changing vendor of the package. Same goes other way - if you installed from chum, it should stay there. Don’t know about pkcon handling of it, though.

ljo · 21 July 2021 15:09

Great, maybe I missed it, but it would potentially be good to add explicitly that, if people like me, wonder if they could use the same credentials as to the build.merproject.org OBS, the answer is yes. Potentially it would save some requests to lbt.

ApB · 21 July 2021 18:51

Please no. While i totally get where all this comes from and Jolla is the only one to blame for the whole situation (the restrictions in the store) i truly believe that the goal should always be for the app -any app- to be in the official store.

Its sad that after all these years we haven’t found a way for the whole thing to work better so that the community can have apps and utilities get in the store/repos faster and without missing features. And make SFOS feel more like a “normal” distro.

rinigus · 21 July 2021 19:51

Please no. While i totally get where all this comes from and Jolla is the only one to blame for the whole situation (the restrictions in the store) i truly believe that the goal should always be for the app -any app- to be in the official store.

I have not formulated it fully clearly, sorry. Ideally, we could have some kind of integration between Chum and OpenRepos allowing migration (not including Jolla Store as it is not expected anyway). As for publishing in Store, for Pure Maps it will continue unless I hit some major obstacle. For other projects, it would make sense to focus on Chum repos.

takimata · 21 July 2021 20:26

I would say that Chum is exactly the solution to this problem, and even has some more benefits.
That is, always build using Chum and, if possible, publish in Harbour.
This gives users immediate access and Jolla time to focus on the most important restrictions.

The store rules help that unmaintained stuff keeps running for some more time.
But Chum could handle automatic recompilation for e.g. aarch64 and could show which Harbour restrictions are too conservative.

Jolla Harbour and OpenRepos are fine for just dumping some binaries, but on the long term I think the only viable solution is to have some infrastructure like other (Linux) distros.
From what I’ve read, Chum is the best candidate for this.

ApB · 21 July 2021 21:02

I am not sure TBH. Ideally we would be able to include packages that provide functionality in the official repos of the distro. And keep a community repo for the wilder stuff. Ie i’d love to have avahi and mosh for example ready to be installed. And maybe Jolla could accept APIs that don’t exist or commits to include stuff in the settings from the community (people who know what they are doing obviously, not me) so SFOS can become more functional.

Seven.of.nine · 21 July 2021 23:19

Right now I downloaded this .rpm and installed it. Phone reports ‘installed’ , but no icon is now present for Chum on app grid.

What can be the reason for this?

edit: tried 2 times, same result
SFOS 4.1.0.24 (Kvarken) on Xperia 10 Single SIM, Geräte Adaption 0.0.5.14

xaos · 22 July 2021 03:57

The .rpm only adds a repository to the package manager, it does not install an app.

I’m guessing currently the only way to browse the packages in chum is via command line

piggz · 22 July 2021 07:42

Correct, chum is just a repository, we may look at some UI at a later point, but for now its zypper or pkcon.

atlochowski · 22 July 2021 08:38

Maybe @mentaljam would be so kind to add chum repo handling in Storeman

rinigus · 22 July 2021 08:51

@ApB: you could always look into how to package avahi and mosh. See how other packages are composed in chum, how avahi is packages in Fedora, and try to reproduce it for SFOS.

As for use of chum - it is just through package managers. Not as convenient as on desktop due to the differences in size, but then keeps sanity in terms of requiring only one repository to install from. GUI would be perfect, but for me, it is more important to get the software coverage over there. So, there would be a place were you could get tools and apps from.

Re incorporation to main repos vs chum: we are supposed to share the load and help to develop SFOS. Jolla does their share, we do ours. Chum allows community to organize some of its work and make it available for all users.

mentaljam · 22 July 2021 09:21

Storeman relies heavily on OpenRepos API for displaying package info, screenshots, comments, etc. As for now I can’t imagine how to integrate chum to Storeman if chum is just a repo. Just a GUI frontend for PackageKit seems to be better. Or, maybe, integration between chum and OpenRepos.

PeegeeTips · 22 July 2021 11:32

i do question whether “chum” is a good name for your new public respository of software:

rinigus · 22 July 2021 12:28

Repo came with the name and it sounds that this name was set a while ago. Cannot comment on its suitability - I’d let the native Eng speakers to figure it out.