[Packaging] Only package qm files

[nephros]

Before this change, Storeman rpms contained translations/README.md,
translations.pri, and .ts files, all of which are unnecessary in an
installed app.

[nephros]

Sorry, this is against master - am I right in assuming I should rebase against devel?

[Olf0]

Before this change, Storeman rpms contained translations/README.md, translations.pri, and .ts files, all of which are unnecessary in an installed app.

Oops, good catch; thank you.
Seems I never thoroughly looked at rpm -ql harbour-storeman-*.rpm before.

Sorry, this is against master - am I right in assuming I should rebase against devel?

Yes, please.
For details see harbour-storeman/wiki/Git-commit-workflow.

May I also suggest to match against *.qm (instead of just *qm) to indicate that this is a file name extension and to use the longest generic substring of .qm files.

[Olf0]

Thank you very much!

[Olf0]

Oh, while this PR did sound reasonable and it reduced Storeman|s binary size by ~ 30%, it brought unexpected consequences: Instead of any translatable string, its ID is shown (e.g., orn-about, orn-description-full etc.). Bummer!

I am using en_GB, which should fall back to en.
Binaries for testing Storeman 0.3.6 can be obtained on Storeman's releases page at GitHub (compiled at GitHub) and the SFOS-OBS (which I used for testing).

Building the .qm files seems to work fine (as it always did, since I started maintaining Storeman).

@nephros, do you have an idea what went wrong?

P.S.: Something else caught my eye when looking through the compilation output:
harbour-storeman.aarch64: W: unstripped-binary-or-object /usr/bin/harbour-storeman
Should I set the -debug flag somewhere in the GitHub-CI-workflow definition (.yaml file)?
Oh, as I am using the Coderus' simple docker images for Storeman, I cannot set this here AFAICS; I would have to switch to the more sophisticated images, as used for compiling Patchmanager.
Never mind, as the binaries for distribution (installs by Storeman Installer and updates by Storeman) are built at the SFOS-OBS, where I (should) have the Debug flag switched on. Do you concur with these considerations?

[nephros]

I think I have seen this when the translation is idbased, and the -en.ts file contains some but not all translated strings.

Anyway I can't imagine how leaving out the .ts and README files could cause that.

[nephros]

P.S.: Something else caught my eye when looking through the compilation output: harbour-storeman.aarch64: W: unstripped-binary-or-object /usr/bin/harbour-storeman Should I set the -debug flag somewhere in the GitHub-CI-workflow definition (.yaml file)? Oh, as I am using the Coderus' simple docker images for Storeman, I cannot set this here AFAICS; I would have to switch to the more sophisticated images, as used for compiling Patchmanager. Never mind, as the binaries for distribution (installs by Storeman Installer and updates by Storeman) are built at the SFOS-OBS, where I (should) have the Debug flag switched on. Do you concur with these considerations?

Yes probably related to this line:

https://github.com/storeman-developers/harbour-storeman/blob/devel/harbour-storeman.pro#L22

Normally the Makefile should use install -s at some point, likely debug mode turns that off.

[nephros]

One thing I notice is that if you do

git co devel
lupdate *.pro

lupdate finds lots of vanished(obsolete) entries. Not sure why.

[Olf0]

I think I have seen this when the translation is ID-based, and the -en.ts file contains some but not all translated strings.

Just to clarify: There are no strings at all, solely their IDs displayed in the current (preview) release of Storeman 0.3.6.

lupdate finds lots of vanished (obsolete) entries. Not sure why.

May "lots of" be equivalent to "all" here? ;-)

[Olf0]

Before this change, Storeman rpms contained translations/README.md, translations.pri, and .ts files, all of which are unnecessary in an installed app.

I dunno about the exact compilation order, but maybe the .pri file is removed too early for this include statement?

[nephros]

May "lots of" be equivalent to "all" here? ;-)

Nope, it's 40 translated, about 170 or so obsolete. But it may be my invocation of lupdate is wrong.

[nephros]

Oh! OH! Simple.

The packages don't contain any .qm files at all! (At least https://repo.sailfishos.org/obs/home:/olf:/harbour-storeman:/testing/sailfish_testing_aarch64/aarch64/harbour-storeman-0.3.6-1.3.1.jolla.aarch64.rpm does not).

Now this would explain

[...] this PR [...] reduced Storeman|s binary size by ~ 30%

and of course

Instead of any translatable string, its ID is shown (e.g., orn-about, orn-description-full etc.). Bummer!

... exactly what happens if there is not translation (not a non-translated string, but no file to load it from!).

I have to look into how to fix this, it would seem the order of things (create .qm files, deploy them to install cache) is not correct.

[nephros]

Oh, and I just discovered I have direct commit access here! Sorry I commited directly to devel and not this branch.

Lets see if 92f410f fixes the issue.

EDIT: it did not. Three commits later situation has not improved - I'll continue experimenting in a feature branch and come back later.

EDIT2: Ah wrong, the last version works in packaging the .qm files.

Issue solved? :)

[Olf0]

One thing I notice is that if you do
git co devel
lupdate *.pro
lupdate finds lots of vanished(obsolete) entries. Not sure why.

May "lots of" be equivalent to "all" here? ;-)

Nope, it's 40 translated, about 170 or so obsolete. But it may be my invocation of lupdate is wrong.

Note that I have never used lupdate and / or lrelease: I performed the lupdate part manually for the few strings I changed, the lrelease part is covered by Transifex's mechanisms. Maybe I did or configured something wrong.

The only thing I can contribute to that is the translation documentation I once overhauled.

[nephros]

Nah, it's alright, not all the source files are picked up when using the .pro file as input - when using recursive mode all strings are found.

nemo@PGXperiiia10:~/git/_forks/storeman $ lupdate *pro -ts translations/harbour-storeman.ts
WARNING: Project ERROR: Unknown module(s) in QT: core gui concurrent dbus core-private
lupdate warning: TS files from command line will override TRANSLATIONS in /home/nemo/devel/git/_forks/storeman/harbo
ur-storeman.pro.
Updating 'translations/harbour-storeman.ts'...
Found 40 source text(s) (0 new and 40 already existing)
Kept 219 obsolete entries
nemo@PGXperiiia10:~/git/_forks/storeman $ git restore translations/*.ts
nemo@PGXperiiia10:~/git/_forks/storeman $ lupdate qml/ src/ *top  -ts translations/harbour-storeman.ts
Scanning directory 'qml/'...
Scanning directory 'src/'...
/home/nemo/devel/git/_forks/storeman/qml/pages/SettingsPage.qml:97: Unterminated meta string
Updating 'translations/harbour-storeman.ts'...
Found 259 source text(s) (0 new and 259 already existing)

[Olf0]

Oh, and I just discovered I have direct commit access here!

Yes, as there is nobody SFOS-related who I trust as much as you: Because Mentaljam (Petr T.) is very hard to contact (this may fail for weeks) and does not monitor these repos actively, what will happen if I get hit by a car? I thought I once communicated that you have admin rights for all repos of the org storeman-developers (and IIRC the org itself), plus to the Storeman related OBS-repos under my account at the SFOS-OBS. Hence in case of an emergency (i.e., new SFOS release breaks Storeman and I am not at all available), you may handle that, if you want to (without Storeman, OpenRepos is inaccessible for most SFOS-users).

Sorry I commited directly to devel and not this branch.

Never mind: This is why I like the devel / master separation. master should always build correctly and its builds should always work at least O.K-ish. To ensure that, devel is the staging branch for master: If anything goes wrong, it can be easily reverted in devel, before it reaches the master branch.

Lets see if 92f410f fixes the issue.

Wow, Intel made really cool ads ... 13 years ago. I suppose this advertisement was created in the context of recruiting ... well, I can tell Intel was not a really cool place to be hired at even 13 years ago. But back then they were still mostly engineering driven, attracted lots of smart people due to high wages, but already exhibited most downsides of big corporations.

[Olf0]

Issue solved? :)

I will check in practice (with a generated RPM file) ... when I find some time for that.

Thank you very much, as I strongly assume that the altered line
translations.path = $$PREFIX/share/$$TARGET →
translations.path = $$PREFIX/share/$$TARGET/translations plus the added line
translations.CONFIG += no_check_exist
in translations.pri fix the issue. (Why? See my first sentence in the previous message.)

Additional kudos for spotting the unterminated source string (though it apparently did no harm)!

[Olf0]

Issue solved? :)

I will check in practice (with a generated RPM file) ... when I find some time for that.

Yes, this is working fine, as the results of the CI runs for merging the master branch into the sfos3.2 branch (built on the SFOS3.2 SDK), the sfos3.3 branch (built on the SFOS3.3 SDK), the sfos4.2 branch (built on the SFOS4.2 SDK) and again the sfos4.2 branch (but built on the SFOS-latest SDK, i.e., 4.5) show.

Thank you very much!

_{P.S.: Still I have two minor questions left, which I will pose after the weekend.}

[Olf0]

P.S.: Still I have two minor questions left, which I will pose after the weekend.

I was able to resolve them on my own:

1. no_check_exist

the altered line
translations.path = $$PREFIX/share/$$TARGET →
translations.path = $$PREFIX/share/$$TARGET/translations plus the added line
translations.CONFIG += no_check_exist
in translations.pri fix the issue.

"no_check_exist" sounded unlogical to me, because why would one not want to check if they already exist (and hence do not need to be build)? And how does that possibly solve the issue, because in any case this would either leave files in place, which already existed or overwrite them, practically yielding the same!?!

Well, looking no_check_exist up shows that this flag is misleadingly named:
If not set, qmake looks to see if the files to install actually exist. If these files don't exist, qmake doesn’t create the install rule. Use this config value if you need to install files that are generated as part of your build process, like HTML files created by qdoc.

O.K., setting no_check_exist now completely makes sense, as did adapting the path, after the initial change selected only files in the translations directory, but not any longer the complete directory.

2. Warning: unstripped-binary

I do not comprehend your reply, and as usual my initial motion was to ultimately understand it, so I searched the WWW, which did not yield anything I recognised as useful, and was about to ask you.

But thinking about it, it is absolutely fine for the built binaries at GitHub to include debuginfo: They are only meant for testing and debugging. The distributed versions of Storeman (i.e., the ones installed by Storeman Installer and Storeman's self-updating mechanism from the Sailfish-OBS) are configured to create separate debuginfo files.

[Olf0]

Summary

Thanks a lot @nephros for starting this PR, implementing and fixing it, because despite taking a meandering, a bit tedious route, this enhancement ultimately reduced the size of the binaries significantly: By 87 KiB, which is almost 20%! 🥳

Additionally it allowed to check in practice, if the current tag naming and versioning scheme is sound, both at GitHub and the SFOS-OBS, specifically for fix-up releases which only increase the release version (never had this case, since I employed the current scheme): It is. 🙂