Community OBS - Refurbished and re-floated

Well thank you very much @lbt - this is one of the fastest tracks I’ve read!
I assume the git repo and branch are in an XML, I’ll let you edit when you have time - enjoy the bbq!

(For the curious, I’ve managed to build a patchmanager version that should work with busybox and did not manage yet to build irremote)

One of the issues with updating an existing app from the obs repos that I’ve seen (other than no signature):

There is an update candidate for ‘patchmanager’ from vendor ‘meego’, while the current vendor is ‘’

1 Like

you spelt _service with a trailing s in the irremote package :slight_smile:

I never implemented signing for the community OBS but I think that may happen at some point.

The vendor change is deliberately part of libzypp (I think) and is intended to avoid accidentally switching packages if two repos provide it

1 Like

Ah yes, one thing I forgot - you must give cibot access to your projects…

Go to the Users ‘tab’ and add ‘cibot’ as a maintainer

1 Like

Thanks again:)
For irremote there is more stuff needed, I’ll get back to it later (android-headers)

I’ve managed to get a really simple QT/QML app and one more complicated C++ app running.

I’m asking myself if the subproject route is asking for trouble (seems ok?) and
Is it fine if I add

  <repository name="">
    <path project="sailfishos:" repository="latest_i486"/>
  <repository name="">
    <path project="sailfishos:" repository="latest_armv7hl"/>

I also noticed that the overview page for my user doesn’t show packages since they are in subprojects. is that a bug or a feature?

I think it would be a great thing, to update the release targets on the Community OBS together with the EA Releases. By doing that we could check and prepare if something is breaking in the new “chum” ecosystem and around. (Somehow this is a “reminder” about this request OBS targets update as a part of release process, but with chum and increased OBS usage the situation gets more important :wink:)


With OBS, I would be happy if the targets for proper releases would appear in timely manner. That would be already great improvement. As for EA, it is OK to skip them.

Is it only me having some Issues with the webhooks due to SSL certificate problems?

i must be a dau
so i have now a login for
but how that that help me here ?
Please Log In - SailfishOS Open Build Service
thanks !

The same credentials should work there, too. (At least they did for me)

How can I fix the state “downloading X dod packages” my packages (pyparsing / packaging) seem to be stuck in for some days?
They depend on some official packages from Jolla.

According to Show sailfishos: - SailfishOS Open Build Service , the download on demand repo seems to be broken, but the status page says that the last update was 2022-02-07 17:45:05+00:00

@takimata: I have pinged @lbt regarding it on Saturday and this morning. It is something that OBS administrators have to fix. Hopefully, it will be fixed soon. Not much we can do on our side…

edit: Seems to be fixed already, thanks!

Did you manage to get in? I’ve the same problem and think I must be missing something glaringly obvious :joy:

i my case : i had a miss communication with lbt
so i was using wrong user :slight_smile:

1 Like

We are getting close to the anniversary of the original announcement. As the commitment by Jolla was made for a year, it would be great to hear what are the plans regarding OBS.


So, the last Community Meeting repeats that sentiment.

Something is expected to be put forth to Jolla that hopefully will lead to another commitment of keeping OBS.

Personally I believe Chum to be a great success, and the Porters Community is also benefitting as always from the OBS workflow.

Question: how can we as the community help to make a good case?


I can see the following points at least:

  • reducing risk up upgrade failures caused by third-party repos (OpenRepos), because:
    • of per-release repos and builds on OBS/chum
    • less breakage with compatability changes
    • less “aging” of unmaintained repos because of auto-rebuild
  • speeding up adoption of new architecture (see the whole “app not available on aarch64” topic)
  • low barrier to entry for new developers: while OBS and all that goes with it is not easy to learn, collaborative building development can be helpful to app developers compared to development and building locally using SDK
  • low barrier to entry for picking up and maintaining abandoned apps (because they are quick to get built, and through community repos such as the chum github community can achieve more reliable maintainership)
  • increased quality of .specs/dependencies because of differences in OBS and SDK build environments

I’d add:

  • a future mechanism for signing packages?
  • leverage existing libraries
  • a future automated auditing (for a catalog of vulns)?
  • ease of use when upgrading (just one repo to disable/enable)

Just a couple of quick ideas.