Suggestion: Add a few SFOS OBS repos to build against

Feature request: Please add the missing SailfishOS 3.2.0.12 "DoD" repositories at the SailfishOS-OBS to build against

I always wondered why the SailfishOS build entries for 3.2.0.12 and ≤ 3.0.3.9 are missing, so I researched this.

Result:
- The build entries for SailfishOS 3.2.0.12 work fine, they are simply missing in the configuration.
- There currently are no “Download on demand sources (rpmmd)” defined for the "DoD repos" sailfishos:3.0.3.9:armv7hl|i486 and the "DoD repos" for any older SailfishOS releases. Thus sailfishos:3.1.0.12:* are currently the oldest "Download on Demand (DoD)" repositories available to build against.
Feature request: Add the following section to both, the meta configuration of the SailfishOS:Chum testing repository and the meta configuration of the regular SailfishOS:Chum repository, between the repository entries for 3.2.1.20_armv7hl and 3.1.0.12_i486.
```
<repository name="3.2.0.12_i486">
<path project="sailfishos:3.2.0.12" repository="latest_i486"/>
<arch>i586</arch>
</repository>
<repository name="3.2.0.12_armv7hl">
<path project="sailfishos:3.2.0.12" repository="latest_armv7hl"/>
<arch>armv8el</arch>
</repository>
```

Caveat: These two sailfishos:3.2.0.12:armv7hl|i486 "DoD repos" become enabled for all packages. This is a reasonable default for new packages, but may be wrong for existing packages. In my opinion one should not mind, if the builds fail for this single, old release (in two architectures). It is far more important that these two entries are on by default for new packages and likely this is the correct setting for many old packages, too. Also the "compromise approach" to have them enabled for SailfishOS:Chum testing, but disabled for the regular SailfishOS:Chum repository appears to be really confusing. Hence I strongly suggest not to disable them (YMMV) by adding (usually in the global section, right before the first repository definition; but it is XML, it can be placed anywhere):
<build>
<disable repository="3.2.0.12_armv7hl"/>
<disable repository="3.2.0.12_i486"/>
</build>

Suggestion: Consider to enable the sailfishos:latest "DoD" repositories for SailfishOS:Chum testing

Currently no sailfishos:latest "DoD" testing repositories are defined for SailfishOS:Chum testing, but it would be useful to know for developers if their software builds correctly against these targets (although Jolla seems to usually miss the chance to switch sailfishos:latest to a newer release during cBeta or EA phase). These "DoD" testing repositories are provided for all three architectures: {aarch64,armv7hl,i486}

Suggestion: Add the following section to the meta configuration of the SailfishOS:Chum testing repository.
```
<repository name="sailfish_testing_i486">
<path project="sailfishos:latest" repository="latest_i486"/>
<arch>i586</arch>
</repository>
<repository name="sailfish_testing_armv7hl">
<path project="sailfishos:latest" repository="latest_armv7hl"/>
<arch>armv8el</arch>
</repository>
<repository name="sailfish_testing_aarch64">
<path project="sailfishos:latest" repository="latest_aarch64"/>
<arch>aarch64</arch>
</repository>
```
Special properties:
- With above configuration (for all three architectures: {aarch64,armv7hl,i486}) their built packages are published at https://repo.sailfishos.org/obs/sailfishos:/chum:/testing:/<package-name>/sailfish_testing_aarch64/, …/sailfish_testing_armv7hl/ and …/sailfish_testing_i486/, but also in every other …/<sfos-release>_{aarch64,armv7hl,i486}/.
- Thus one can select the CPU-architecture, but the built package is available for every SFOS-release. This is very resource efficient for noarch or other packages, which are not SFOS-release dependent: Built once, available-for all SFOS-releases.
- The git-tag date and short-hash is omitted in their package name.

Besides for testing purposes these repositories allow to build SFOS-release independent packages once and have them in all SFOS-release specific download directories.

P.S.: I have tested both suggestions (1 & 2) with a few C++, QML packages and a simple QML noarch package, e.g., Storeman.

Addition of each old SFOS version repository adds maintenance cost on addition. Namely, each package that doesn't compile for these old versions has to be configured to skip it. Looking at 3.2.1.20, it is more than 50 packages. Such disabling will have to be done for :chum:testing and :chum.

This is a significant work and brings the question: how many users would actually benefit from it? It is not motivating to add those repos for just having them.

In principle, we should even start considering closing older repos. Unfortunately, I don't have any stats and cannot judge the use of 3.1.0.12 or other older releases. Wouldn't surprise me if it is zero.

Addition of each old SFOS version repository adds maintenance cost on addition. Namely, each package that doesn't compile for these old versions has to be configured to skip it. Looking at 3.2.1.20, it is more than 50 packages. Such disabling will have to be done for :chum:testing and :chum. This is a significant work and …

I would not mind doing this: It is the kind of tedious, but easy work one can do while listening to music late at night.

The longer this is avoided, the bigger the hurdle becomes, because more and more packages are available at SailfishOS:Chum. Thus the "this is a lot"-argument IMO means: Do that as soon as possible, because it will become even harder when more time has passed.

… brings the question: how many users would actually benefit from it? It is not motivating to add those repos for just having them.

Well, Jolla offers "DoD (rpmmd)" repos for all releases ≥ 3.1.0 and 3.2.0 was the only one left out.

IMO it is up to the developers to decide if these "DoD" repos are useful for them and the users of their apps.

And you do not need to be motivated as long as you do not block my motivation, as stated above.

In principle, we should even start considering closing older repos.

For what reason? It is just an offer for developers to use them, with no duties implied.

Unfortunately, I don't have any stats and cannot judge the use of 3.1.0.12 or other older releases. Wouldn't surprise me if it is zero.

You know that I still use SFOS 3.2.1 on my "production" phone due to the low release quality of all releases ever since, and have a couple of apps from SailfishOS:Chum installed.

Re suggestion 2: With the current SSU config, Chum with "latest" will never be used as SSU resolves URL using SFOS version. Having "latest" in addition could lead to conflicts when the packages would start accidentally leaking RPMs that would work only on latest versions and not some older SFOS version. Thus, such saving on copies for efficiency leads to a less stable solution.

So, I prefer current approach. Note that it already allows developers to test their builds against latest SFOS versions as well.

Re old releases: @Olf0 , there is probably a reason why you stayed on 3.2.1. Do you know good reason to stay on even older ones? Or on some releases in between 3.2.1 and the current SFOS?

Re old releases: @Olf0 , there is probably a reason why you stayed on 3.2.1.

Yes, all later releases have one or more flaws (different releases different ones) which breaks one or more important use cases for me. This abstractly stated, that seems to be generally the reason for people to stay on older SFOS releases. 4carlos (Wolfgang) wrote at FSO, "If you have an SFOS installation running fine, stay at that release and never upgrade SFOS." Years ago I would have called such a statement "an extreme position", but looking at the quality of all SFOS 4.x.y releases so far, I now concur with this statement (and 4carlos wrote that in 2021).

So everybody has different reasons and some even stick to a specific SFOS release, because Patchmanager-Patch XYZ does not run on newer releases: Also something I think of "a bit extreme", but I do understand that the losing for example Ancelad's "Ultimate Statusbar" and "Lockscreen Analog Clock" (which provides far more than just a clock) constitutes a significant regression in usability.

Jolla forcing people to use the recent SFOS release by not providing older installation images and the technical inability to downgrade (the latter is well understandable: almost no desktop Linux distribution manages to do that successfully) contributes massively to the fact that some long time SFOS users are becoming very reluctant abut upgrading SFOS: Once you are on a SFOS release which does not work for you, one has to reflash and reinstall everything from the scratch, which is only possible if you have kept an old installation image (see how comprehensible 4carlos' aforementioned statement becomes).

For me SFOS 3.2.1 is working really well on my "production phone" Xperia X, only the AAC playback is broken, which mutes most internet radio stations (only very few use MP3).
SFOS 3.3.0 fixes the AAC decoder library, but breaks SD-card access for AlienDavik, which is a no-go for me. Quite some people seem to stick to this release, because it seems to be really well working.
SFOS 3.4.0 was the transitional release to SFOS 4 and thus broke many Patchmanager-Patches due to Lipstick / Silica changes. I have the impression this is also the release with which the lack of quality assurance by Jolla started to become obvious: Many little annoyances appeared. OTOH it is the last release which supports the Jolla 1 phone. But not only J1 users seem to be stranded on this release, also other who became aware of the deteriorating release quality after upgrading to 3.4.0.
SFOS 4.0.1 is really a bad release. Trying it on my testing phone (XA2+) made me waiting at least a month and reading the bug reports for all later releases, which resulted in skipping them all. I am curious what the long due time and the high micro release version of the current cBetas of 4.4.0 mean, but likely some new features and more / new / other broken things.
The 3.1.0 target is also an interesting one, because software compiled for it should also run on 3.0.x (maybe even 2.2.0 / 2.2.1: I might try installing the SailfishOS:ChumGUI app on my old J1@2.2.1, when time allows). SFOS 3.0.1 or 3.0.3 was the last release for the Intex Aquafish, because Intex's support contract with Jolla ended.

Do you know good reason to stay on even older ones?

See above: Yes, if it works fine for you, plus there are sufficient reasons to be reluctant to upgrade. Or owning an Intex Aquafish, which can be transformed via a CLI-intensive procedure to mimic a Jolla C, if you have not upgraded to 3.0.x (otherwise: factory reset to 2.0.0 and upgrade via stop release hopping): Again sufficient reasons to stay where one is (at 3.0.x) if the installation is running fine.

Or on some releases in between 3.2.1 and the current SFOS?

See above for 3.3.0 and 3.4.0: Lots of people love them. Even though I do not believe anyone sane wants to stay at 4.0.1 or 4.1.0, in general always somebody will love some characteristic or feature of any specific release and stick to it.

Hey Rinigus, please take step back from looking at the technical details and try to grasp the big picture: The fact that in the realm of Android OS releases which are almost 10 years old are still supported by many apps (especially FLOSS ones at F-Droid) definitely has appeal. I still run a current OSMand~ release on the AOSP 4.4.4 (API level 19, published 2013) based AlienDalvik on my Xperia X, while I cannot install a recent OSM Scout Server and Poor Maps on SFOS 3.2.1 (published December 2019) for long. Actually, that Firefox for Android (for me the only really usable browser on SailfishOS with AlienDalivik) ceased to support Android 4.4 in 2020 (after 7 years) is the major reason why I want to switch to the XA2+ as "production phone", if only Jolla would deliver a decent SFOS 4.x release.

SailfishOS:Chum promises (besides the technical and security stuff I emphasised in its README) to enable developers to support all SFOS releases back to 3.1.0 easily (except for 3.2.0, currently), especially if they utilise Slava's harbour-lib. This infrastructure is a huge step forward towards more software-longevity on SailfishOS, which allows users to escape Jolla's constant pressure to be their beta-tester for their "latest & greatest" (and quite often "shittiest", lately) SailfishOS release.

What I really do not understand is why you appear to be jumping multiple times between "maintaining SailfishOS:Chum is not much work" to "copy & paste of a special build target configuration for Storeman is a lot of tedious work" and back to "SailfishOS:Chum is low maintenance" to "Addition of each old SFOS version repository adds maintenance cost on addition." and "~ 200 configuration changes (armv7hl / i486, plus Chum proper / Chum testing) for ~50 apps failing to compile for 3.2.0" is infeasible, while I offered to do that, if you would let me. BTW, no I really do not want to become a Chum administrator, this would be a one-shot action to enable the 3.2.0 target now, because the number of apps in Chum will rise and so does the number of necessary configuration changes.

-- HTH

Re suggestion 2: With the current SSU config, Chum with "latest" will never be used as SSU resolves URL using SFOS version. Having "latest" in addition could lead to conflicts when the packages would start accidentally leaking RPMs that would work only on latest versions and not some older SFOS version. Thus, such saving on copies for efficiency leads to a less stable solution.

Yes, sure; that is why I suggested that only for Chum testing. For users it is "testing", hence anything can be broken at any time (like in Debian testing) and it is always a developers' task to use features responsibly. To clearly show that, the targets are labelled sfos_testing_<arch>. Mind that all people developing software for SFOS can do anything with the SailfishOS installations of all of their users and will continue to do so until SailJail becomes mandatory for everything without a chance to escape (lol: :grin:). This seems to be working surprisingly well the last 10 years (or we just have not detected the malware on our devices, yet). Also note that at OpenRepos "anything goes": I can install a lot of packages on SFOS 3.2.1 which fail to run, because some developers are too lazy to set proper dependencies. TL;DR: There is no real safety and IMO there is no need for safety at anything called "testing".

Anyway, this was just an idea when I researched why mentaljam configured and uses sailfish_testing_armv7hl for Storeman Installer (as a noarch RPM) and for Storeman-testing, plus what the sailfishos:latest "DoD repo" does and is for.

For development, I would expect that personal OBS repos would be used, not Chum testing. Chum testing was created to test your packages before release in Chum proper in the environment that is close to the Chum proper (in respect of interaction between packages). So, I am opposing the suggestion to add sfos_testing_xxxx to chum:testing

Re Pure Maps and OSM Scout Server on older SFOS: Those apps use libraries relying on "new" C++ standards. Before, I had to maintain my own copy of GCC for building it. So, as soon as it became possible to rely on system-provided GCC, I switched to that.

Re whether it is much work or not to maintain Chum: It is not "free" to add new target with older SFOS version as many developers tend to prefer using newer libs and gcc. So, if we decide to add it, we better be aware of such requirement and it makes sense to know how many users would actually benefit from it. As SFOS is remarkably well supporting older hardware on newer SFOS versions, the bulk of users update. Add to that small number of SFOS users in general and I wouldn't be surprised if we have ZERO users on some version/arch combinations.

With Storeman, I personally think it is wrong approach and hence I don't want to spend my time into adding these build targets. If you bring Pure Maps as example above, I can bring it over here as well. In Pure Maps, I am supporting multiple Qt versions and backends (Silica, UbuntuTouch one, Kirigami) all from the same branch. That is resolved on build system level and in small sections of the code and the challenge is way larger than what you face with Storeman, from what I have heard. Anyway, Storeman discussion has been going on for too long already and I would prefer to work on my projects instead of getting dragged into it.

For development, I would expect that personal OBS repos would be used, not Chum testing. […] So, I am opposing the suggestion to add sfos_testing_xxxx to chum:testing

That is O.K. So I dropped that idea of making "testing" binaries easily available for people willing to try them.

BTW, I did gain understanding why you do not want the sailfishos-latest target. _{I think I missed to denote that clearly, that your arguments and some additional evaluation convinced me.}

Re Pure Maps and OSM Scout Server on older SFOS: […]

… was not my point at all. It was merely an example, maybe a badly chosen one, both technically and that it seems to have startled you. Sorry, if that came across as criticising you; it was not at all meant that way.

The principal point was:

SailfishOS:Chum promises (besides the technical and security stuff I emphasised in its README) to enable developers to support all SFOS releases back to 3.1.0 easily (except for 3.2.0, currently), especially if they utilise Slava's harbour-lib. This infrastructure is a huge step forward towards more software-longevity on SailfishOS, which allows users to escape Jolla's constant pressure to be their beta-tester for their "latest & greatest" (and quite often "shittiest", lately) SailfishOS release.

But I do get that you deem this as not relevant and hence do not want to consider enabling the 3.2.0 targets. Which is O.K., I only would have preferred if you clearly stated that earlier, instead of asking (and then being dissatisfied with the answers):

[…] there is probably a reason why you stayed on 3.2.1. Do you know good reason to stay on even older ones? Or on some releases in between 3.2.1 and the current SFOS?

With Storeman, I personally think it is wrong approach and hence I don't want to spend my time into adding these build targets.

???

a. This thread is unrelated to Storeman. Storeman would not benefit from enabling the 3.2.0 target to a greater extent than any other software which still supports this SFOS release.

b. What does "the approach taken for Storeman" have to do with "hence I don't want to spend my time into adding these build targets."? This bears no logic to me. Maybe there is a link on an emotional level, but IMO not on a technical or logical one.

P.S.: Unrelated stuff (= off topic, here)

If you bring Pure Maps as example above, I can bring it over here as well.

This really sounds like "tit for tat". As written above, I did not intend to criticise you, but obviously you intend to criticise mentaljam (Petr Tsymbarovich) for how he structured the support for multiple SailfishOS releases for Storeman.

In Pure Maps, I am supporting multiple Qt versions and backends (Silica, UbuntuTouch one, Kirigami) all from the same branch.

I know that and this is quite an achievement and technically really cool.

That is resolved on build system level and in small sections of the code and the challenge is way larger than what you face with Storeman, from what I have heard.

I do not face any "challenge" with that, because it is something I never wanted to address, I likely cannot address properly and hence will not, as mentioned in the "Submitting Storeman to SailfishOS:Chum"-thread. For now the Storeman sources are structured that way mentaljam did, until someone comes up with a PR that changes that in a proper, comprehensible and easy to handle way. At least the current structure fulfils the last two points for me.

P.P.S.: Yes, this was a lengthy conversation to receive two "No, I oppose this.". Thus I assume it makes sense to close this issue.

sailfishos-chum / main

Suggestion: Add a few SFOS OBS repos to build against #76