Translations not created in OBS

As explored in [Bug] `TS` files are not translated to `QM` files when building on OBS · Issue #68 · sailfishos-applications/filecase · GitHub, the documentation about internationalisation explains how to do it, using libsailfishapp, see
libsailfishapp docs - Sailfish OS.

Within the SDK, everything is fine. Since the documentation is made for the SDK, there is no bug stricto sensu. But, besides the dependency on libsailfishapp, there is a implied dependency on qt5-qttools-linguist which provides the internationalisation tools (like lupdate).

I don’t know what is the best solution here:

  • libsailfishapp could itself have a dependency on qt5-qttools-linguist so when it is pulled for the build, it will install the internationalisation tools,
  • complete the documentation to add that the spec file (or YAML one) should have a build dependency on qt5-qttools-linguist.

Personally, I would prefer the first option which is more direct for the user (less changes to spec files and things to add for it to work). @olf created an issue in [Bug] Document build time dependencies when utilising `sailfishapp_i18n` · Issue #46 · sailfishos/libsailfishapp · GitHub about it.

1 Like

This is not limited to linguist, many Qt deps are included in the SDK but absent in the OBS builder.

SDK-born .spec files often have to be updated for builds to work on OBS as they tend to be incomplete.

I guess a dedicated doc section on how to move from SDK to OBS would be useful.

2 Likes

Yes, but in this case it is clearly a missing dependency definition for the libsailfishapp-devel package.

While in general much more (development) packages are pre-installed in the Sailfish-SDK in contrast to the Sailfish-OBS, many failing OBS-builds can really be attributed to missing dependency definitions in the software to build.

This is definitely true, regardless of the points discussed above.

Fixed by [libsailfishapp] Requires qt5-qttools-linguist in devel. by dcaliste · Pull Request #47 · sailfishos/libsailfishapp · GitHub (merged).

2 Likes

From my point of view the issue is two layered.
First the devel package ship an optional feature an app my not require translations.
So from a pure packaging point of view a Recommends: would have been better

The other issue is that apps don’t specify their full dependencies, mostly because it wasn’t required in SDK.
I would have preferred if apps BuildRequire lupdate if they use it.
But perfect is the enemy of the good, this solution is the easiest for users and most apps use Qt’s own translation system.

1 Like

The point is: They don’t “use it” knowingly!
But many SailfishOS apps employ an unsuspicious “CONFIG += sailfishapp_i18n” in their .pro-file for qmake due to Jolla’s recommendation. This results in requiring both, lupdate and lrelease, which does not become obvious when using the Sailfish-SDK, because both are preinstalled inside the SDK; but both are not installed in the compile environment of the Sailfish-OBS.

It is the indirection via “CONFIG += sailfishapp_i18n”'s undocumented requirement of lupdate and lrelease, which makes the errors in the OBS build-log untraceable to their root cause without much research.

That would have not solved anything, because “Recommends:” is merely a hint which GUI package management tools may display, but when using command line tools as pkcon, zypper or rpm a “Recommends:” is silently ignored (IIRC one can explicitly ask zypper to use this info).

Yes, definitely!

Yes that is exactly what I am describing, they don’t but should have. Not to their fault directly, the docs did not mention this requirement.

But many apps employ an unsuspicious CONFIG += sailfishapp_i18n in their .pro -file for qmake due to Jolla’s recommendation.

The instruction is not unsuspicious but incomplete. The docs did not portray packaging outside of the SDK. A user might add the configuration to their project by accident.
The SDK isn’t perfect, reproduceable builds are not part of it but rather the preference to lower the barriers for new developers to the cost of clean packaging.

This results in requiring both, lupdate and lrelease , which does not become obvious when using the Sailfish-SDK, because both are preinstalled inside the SDK; but both are not installed when using the Sailfish-OBS.

It is the indirection via CONFIG += sailfishapp_i18n 's undocumented requirement of lupdate and lrelease , which makes the errors in the build-log untraceable to their root cause without much research.

I wouldn’t call it much research, the SDK provides all the tools to find the dependency, e.g.:
zypper search --provides /usr/bin/lupdate
But how easy it is to find the source depend on the expirience of the individual developer.

Recommends is not merely a hint to the user, pkcon or zypper can handle them and pull recommends by default. For rpm of course it is just meta information as rpm doesn’t handle dependencies outside of making sure that Requires is for-filled.

First the devel package ship an optional feature an app my not require translations.

Yes, I fully agree. I was a bit reluctant to add a Requires: in libsailfishapp, that will pull a dependency that is not necessary if you don’t use translation. But my fear was mitigated by the fact that it’s only the -devel package that has the dependency, thus it’s cluttering the build environment, which is less of an issue than the runtime one, I would say.

So from a pure packaging point of view a Recommends: would have been better

My RPM knowledge didn’t extent so much : / Sorry. I’ll try to remember it next time. Thanks for pointing it out.

The docs did not portray packaging outside of the SDK.

Indeed, that’s why I mentioned in the first post that it was not strictly a documentation bug. The idea was more to discuss about what to do about this. Which turned out to be the case. The suggestion by @nephros to add a guide to move from SDK to OBS is very good in my opinion. I lack the practice with OBS to help there though : (

… which outputs qt5-qttools-linguist.
But a developer using “CONFIG += sailfishapp_i18n” in their .pro-file does not specify any dependency requiring qt5-qttools-linguist!

This was the point when my testing and research started, because there is no obvious connection.