[ci-on-tags.yml] Redefine LATEST sensibly

[Olf0]

For details see new comment in the altered file.

[nephros]

Ah I didn't realize that there is no 4.6 version yet.

Thing is, the icon generation for 4.6 (#464) relies on the sailfish-svg2png version from 4.6. Only there are the new paths defined.

Which means as long as there is no docker env for 4.6 and higher, icons will end up on the "old" place, and if the resulting packages are installed, there will be no icon for Patchmanager in Settings, and the Top menu.

I have worked around this issue on OBS by "backporting" (i.e. adding) sailfish-svg2png-0.4.1 from 4.6/5.0 to the build env: https://build.sailfishos.org/project/show/home:nephros:devel:patchmanager. Builds in that OBS project will use it, and therefore package the icon files correctly got 4.6 and higher.

Not sure how we should handle this for release builds. Should we work around this temporaily somehow until a newer SDK is available?

[Olf0]

Ah I didn't realize that there is no 4.6 version yet.

There is. "LATEST" as formerly defined was not updated for long in the CI configuration.

I once considered using the latest link to Coderus' Sailfish-SDK docker-images, but I saw no easy way to obtain the SFOS release version of that to properly name the generated RPMs / ZIP-file; I might reconsider using the string SFOS-latest, but that is misleading, because regularly a newer SFOS release exists, but Jolla has not yet released an SDK release for it and / or Coderus has not yet created a new docker-image from that. SFOS-SDK-latest is not much better IMO.
What are your thoughts on this?

Mind that these GH-CI builds are basically intended (by me) only for testing purposes, so I derived the requirement for them to simply be executable on the "latest" SailfishOS release (which is 5.0.0 for which no docker-image of the Sailfish-SDK exists yet, but the builds for 4.3.0 run on 5.0.0). But I now see that "no icons" means "no fun testing".

All in all, I do not exactly understand what the requirements for the CI workflows are, hence I recently asked @b100dian what he wants and offered a few choices. You added another choice by pointing him to https://build.sailfishos.org/project/show/home:nephros:devel:patchmanager which is better maintained than my SFOS-OBS-PM-testing repo.

My only requirement is that the ci-on-pull_request.yml configuration is fast and hence a simple compile test for i486 with the oldest feasible (hence smallest) SDK-release (i.e. for SFOS 3.4.0).

[Olf0]

BTW / OT:

Which means as long as there is no docker env for 4.6 and higher, icons will end up on the "old" place, and if the resulting packages are installed, there will be no icon for Patchmanager in Settings, and the Top menu.

I have worked around this issue on OBS by "backporting" (i.e. adding) sailfish-svg2png-0.4.1 from 4.6/5.0 to the build env: https://build.sailfishos.org/project/show/home:nephros:devel:patchmanager. Builds in that OBS project will use it, and therefore package the icon files correctly got 4.6 and higher.

What does that mean for Storeman build at the SFOS-OBS without such workarounds (or FileCase / FlowPlayer)? Do they also show no icons (or only no in-app icons?) without this workaround? Shouldn't this workaround then be better available at SailfishOS:Chum(:Testing), too?
Edit: Late at night, but I realise that I do not use sailfish-svg2png of which versions ≥ 0.4.1 likely deploy the generated PNGs to the new paths. But my SPEC files simply deploy icons to the old paths, so what happens then? I.e., do I have to create another sailfish-version based switch in the SPEC files, now for the %files section?

_{Did I ever mention that I hate Jolla for their permanent stream of app-breaking changes out of carelessness / negligence? 😉
If they are convinced that they must alter paths, (user-)names etc. simply for beautification, they could at least deploy compatibility links when doing that. But as they don't care about SailfishOS' app- and developer-ecosystem I assume they never considered anything like that.}

[nephros]

What does that mean for Storeman build at the SFOS-OBS without such workarounds (or FileCase / FlowPlayer)? Do they also show no icons (or only no in-app icons?) without this workaround? Shouldn't this workaround then be better available at SailfishOS:Chum(:Testing), too?
Edit: Late at night, but I realise that I do not use sailfish-svg2png of which versions ≥ 0.4.1 likely deploy the generated PNGs to the new paths. But my SPEC files simply deploy icons to the old paths, so what happens then? I.e., do I have to create another sailfish-version based switch in the SPEC files, now for the %files section?

I haven't checked these apps, but all of this only applies to "theme" icons under /usr/share/themes. Many apps do not use that location, but rather /usr/share/icons/..., and these will be fine.
There are not too many apps using /usr/share/themes really, PM is one, some of mine and things by coderus tend to use it. Storeman does not.

So I suspect the fallout to be not too drastic.

(I do agree that lack of backward compatibility with SFOS is annoying.
I kinda understand though if there is the goal of getting rid of the MeeGo and other legacy names (what with changes of MeeGo and Nemo to Amber and other names), keeping backwards compatibility by e.g. providing a "meegotouch" symlink kind of defeats that goal.)

[nephros]

Now, to solve the whole current icon mess, we could, in Patchmanager, move the icon location to /usr/share/icons. I believe that will work also for our Settings plugin,
This way we would be compatible with all releases. (At least until someone decides to change the icon theme path away from hicolor. I think that's unlikely though, as that name is probably defined by the FDO desktop standard.

[Olf0]

I haven't checked these apps, but all of this only applies to "theme" icons under /usr/share/themes.

Thank you for the clarification! Yes, now I see this is nothing I have to worry about.

---

Now, to solve the whole current icon mess, we could, in Patchmanager, move the icon location to /usr/share/icons. I believe that will work also for our Settings plugin. This way we would be compatible with all releases.

👍
That sounds like a cool way out, in order to avoid another sailfish-version dependent switch.

At least until someone decides to change the icon theme path away from hicolor. I think that's unlikely though, as that name is probably defined by the FDO desktop standard.

Yes, it is by FDO's icon theme specification: $XDG_DATA_DIRS resolves to /user/share (all elements on OpenSUSE LEAP: ~/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share) and a hicolor directory there is required, so /usr/share/icons/hicolor must exist.
Hence this appears to be a sound approach.

[Olf0]

Back to the original topic, i.e. the one of this PR:

All in all, I do not exactly understand what the requirements for the CI workflows are, …

Practically I might add a true LATEST in another PR and use the string SDK-latest in the generated artefacts.

[Olf0]

Now, to solve the whole current icon mess, we could, in Patchmanager, move the icon location to /usr/share/icons. I believe that will work also for our Settings plugin. This way we would be compatible with all releases.

👍 That sounds like a cool way out, in order to avoid another sailfish-version dependent switch.

At least until someone decides to change the icon theme path away from hicolor. I think that's unlikely though, as that name is probably defined by the FDO desktop standard.

Yes, it is by FDO's icon theme specification: $XDG_DATA_DIRS resolves to /user/share (all elements on OpenSUSE LEAP: ~/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share) and a hicolor directory there is required, so /usr/share/icons/hicolor must exist. Hence that appears to be a sound approach.

See also the corresponding remark by @ichthyosaurus in #468 (comment).

[nephros]

I tried the /usr/share/icons approach, unfortunately it does not work.

Apparently Settings (and perhaps Lipstick) need the images to be in the themes directory.

[Olf0]

Unfortunate, but "it is what it is".

I realise that I do not use sailfish-svg2png of which versions ≥ 0.4.1 likely deploy the generated PNGs to the new paths.

Is this understanding I gathered correct (please confirm)?

If so, IMO it makes sense that I:

• Build (also) with SDK-4.6 in the ci-on-tags.yml workflow.
• Use a sailfish-version based switch in the %files section of the spec file (I am starting to become an expert on this, unfortunately) to reference the correct theme icon directories.

Does this plan sound reasonable for you?

[nephros]

Unfortunate, but "it is what it is".

I realise that I do not use sailfish-svg2png of which versions ≥ 0.4.1 likely deploy the generated PNGs to the new paths.

Is this understanding I gathered correct (please confirm)?

Versions of sailfish-svg2png >0.4.1, which are used in qmake .pro files (via CONFIG += sailfish-svg2png), will deploy to the new paths, older to the old paths. Path meaning /usr/share/themes/foo.

One can also use sailfish-svg2png in other ways, by calling the program manually instead of relying on the shipped qmake configuration. (This can be used to populate /usr/share/icons/hicolor/NxN with correctly scaled icons generated from a SVG file.)
By forgoing the shipped configuration, one can put the results anywhere.

At Patchmanager, before #464, we used a part of the shipped configuration, but still called the binary manually. This was a bit superfluous, as we basically did just the same thing as the shipped configuration does. Which is why #464 reduces the .pro file to just a few lines. (But that may have been different in older releases.)

If so, IMO it makes sense that I:

* Build (also) with `SDK-4.6` in the `ci-on-tags.yml` workflow.

[EDIT:] most of the following proved to be irrelevant. See the next comment.

I guess.

Whichever way we deal with this, it all boils down to the fact that we have to specify the version the rpm is going to be installed on during the build process. If install-os-version === build-host-version, the current setup works for all releases.

There's a couple of things we could do differently, e.g. doing the generation of the icons manually independently of build-host-version, copy them around after generation etc., but with all those variants we always have to specify the install-os-version in some way.

The only point where we can be sure what to do is at RPM install time, so during the %post and related phases. There we could copy the files to the correct location.
But that's ugly, and it makes the filesystem contents not match with the RPM contents.

We could even do something more ugly, and Require: sailfish-svg2png, and generate the PNGs at install-time :D, and use %ghost entries in the RPM %files section.

* Use a `sailfish-version` based switch in the `%files` section of the spec file (I am starting to become an expert on this, unfortunately) to reference the correct theme icon directories.

I'm not sure this is required, iff the right many-asterisked paths are used. Currently I think we are good here.

[nephros]

Disregard everything I said.

What if we:

1. Generate/"install" icons for all the (currently two) locations at build time
2. Package them in subpackages:
   patchmanger-icons-silica and patchmanger-icons-meegotouch
3. Use Requires: patchmanger-icons in the main patchmanager RPM
4. Use Provides: patchmanger-icons and Requires: sailfish-release <=/>= foo in those icon subpackages

So this: master...nephros:patchmanager:icons-both-ways

That should shift the burden to the package management solver and thereby solve (heh) our problems with build/install/SDK/release versions.

[nephros]

Please continue discussion of the icon location topic in PR #479

[Olf0]

• Use a sailfish-version based switch in the %files section of the spec file (I am starting to become an expert on this, unfortunately) to reference the correct theme icon directories.

I'm not sure this is required, if the right many-asterisked paths are used. Currently I think we are good here.

Ack: Sorry, I already forgot how I designed PR #471, because the last weeks have been extremely busy for me.

So with that being understood as superfluous, the only thing left is to also build with the SailfishOS-SDK for 4.6.0 in the ci_on_git-tags workflow.