Problem building 3.7.0 on Ubuntu 20.04

[softins]

Describe the bug
Building 3.7.0 on Ubuntu 20 tries to run lrelease. On Ubuntu 18 it doesn't. Building 3.6.2 on Ubuntu 20 also doesn't.

To Reproduce

git clone https://github.com/jamulussoftware/jamulus.git jamulus-temp
cd jamulus-temp
git checkout r3_7_0
qmake "CONFIG+=nosound headless" Jamulus.pro
make

Expected behavior
Normal build

Screenshots

tony@ubuntu20:~$ git clone https://github.com/jamulussoftware/jamulus.git jamulus-temp
Cloning into 'jamulus-temp'...
remote: Enumerating objects: 9, done.
remote: Counting objects: 100% (9/9), done.
remote: Compressing objects: 100% (9/9), done.
remote: Total 25581 (delta 1), reused 0 (delta 0), pack-reused 25572
Receiving objects: 100% (25581/25581), 26.24 MiB | 2.96 MiB/s, done.
Resolving deltas: 100% (19407/19407), done.
tony@ubuntu20:~$ cd jamulus-temp
tony@ubuntu20:~/jamulus-temp$ git checkout r3_7_0
HEAD is now at 03bc4c11 Update version to 3.7.0 for release
tony@ubuntu20:~/jamulus-temp$ qmake "CONFIG+=nosound headless" Jamulus.pro
Info: creating stash file /home/tony/jamulus-temp/.qmake.stash
Project MESSAGE: building version "3.7.0" (release)
Project MESSAGE: Headless mode activated.
tony@ubuntu20:~/jamulus-temp$ make
/usr/lib/qt5/bin/lrelease src/res/translation/translation_de_DE.ts -qm src/res/translation/translation_de_DE.qm
make: /usr/lib/qt5/bin/lrelease: Command not found
make: *** [Makefile:1250: src/res/translation/translation_de_DE.qm] Error 127
tony@ubuntu20:~/jamulus-temp$

Operating system
Ubuntu 20.04 LTS

Version of Jamulus
3.7.0 or latest

Additional context
Doing a git checkout r3_6_2 before building gives a successful build:

tony@ubuntu20:~/jamulus-temp$ git checkout r3_6_2
HEAD is now at 337a4840 r3_6_2
tony@ubuntu20:~/jamulus-temp$ qmake "CONFIG+=nosound headless" Jamulus.pro
Info: creating stash file /home/tony/jamulus-temp/.qmake.stash
Project MESSAGE: Headless mode activated.
tony@ubuntu20:~/jamulus-temp$ make
g++ -c -pipe -O2 -std=gnu++11 -D_REENTRANT -Wall -W -fPIC -DAPP_VERSION=\"3.6.2\" -DOPUS_BUILD -DUSE_ALLOCA -DCUSTOM_MODES -D_REENTRANT -DHAVE_LRINTF -DHAVE_STDINT_H -DHEADLESS -DQT_NO_DEBUG -DQT_NETWORK_LIB -DQT_XML_LIB -DQT_CONCURRENT_LIB -DQT_CORE_LIB -I. -Isrc -Ilibs/opus/include -Ilibs/opus/celt -Ilibs/opus/silk -Ilibs/opus/silk/float -Ilibs/opus/silk/fixed -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem /usr/include/x86_64-linux-gnu/qt5/QtNetwork -isystem /usr/include/x86_64-linux-gnu/qt5/QtXml -isystem /usr/include/x86_64-linux-gnu/qt5/QtConcurrent -isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -I. -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -o sound.o linux/sound.cpp
g++ -c -pipe -O2 -std=gnu++11 -D_REENTRANT -Wall -W -fPIC -DAPP_VERSION=\"3.6.2\" -DOPUS_BUILD -DUSE_ALLOCA -DCUSTOM_MODES -D_REENTRANT -DHAVE_LRINTF -DHAVE_STDINT_H -DHEADLESS -DQT_NO_DEBUG -DQT_NETWORK_LIB -DQT_XML_LIB -DQT_CONCURRENT_LIB -DQT_CORE_LIB -I. -Isrc -Ilibs/opus/include -Ilibs/opus/celt -Ilibs/opus/silk -Ilibs/opus/silk/float -Ilibs/opus/silk/fixed -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem /usr/include/x86_64-linux-gnu/qt5/QtNetwork -isystem /usr/include/x86_64-linux-gnu/qt5/QtXml -isystem /usr/include/x86_64-linux-gnu/qt5/QtConcurrent -isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -I. -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -o buffer.o src/buffer.cpp
...

[softins]

The issue appears to be the addition of lrelease into CONFIG. Not sure why it affects Ubuntu 20 but not Ubuntu 18. Must be to do with different versions of Qt.

[hoffie]

The reason for this only affecting 3.7.0 may be #799 (cc @mirabilos).

As far as I understand, putting lrelease in CONFIG only works as of Qt 5.12. I assume the older Ubuntu versions use some Qt version before that.

[softins]

The problem appears to have been introduced by 9c693d3. Ubuntu 20 has Qt 5.12, but Ubuntu 18 has Qt 5.11.

A workaround is to install qttools5-dev-tools, although that pulls in a huge amount of other packages.

[hoffie]

Hrm, ideally builds should continue working without lrelease. At the same time, we should not have to fight with permanent local .qm changes.

• Would running lrelease (and committing) as part of a CI action be an option?
• Would running lrelease conditionally be an option, i.e. only running it if .ts files are newer than the .qm files? Standard make can do that (not sure if file timestamps are properly tracked with git, but I'd assume so)? This would make building official (pre)releases possible for everyone (as we pre-generate the files as part of the release process there), but would require lrelease for anyone working with translations and building afterwards.
• Would a fallback be an option? Run lrelease if available, but be ok with taking possibly outdated .qm files otherwise?

[softins]

Hrm, ideally builds should continue working without lrelease. At the same time, we should not have to fight with permanent local .qm changes.

It's hard to have it both ways. lrelease is the only tool to convert a .ts to a .qm

• Would running lrelease (and committing) as part of a CI action be an option?

May be worth investigating.

• Would running lrelease conditionally be an option, i.e. only running it if .ts files are newer than the .qm files? Standard make can do that (not sure if file timestamps are properly tracked with git, but I'd assume so)? This would make building official (pre)releases possible for everyone (as we pre-generate the files as part of the release process there), but would require lrelease for anyone working with translations and building afterwards.

I don't think this works. Git does not preserve timestamps. When doing a git checkout, all the changed files have their mtime set to now.

• Would a fallback be an option? Run lrelease if available, but be ok with taking possibly outdated .qm files otherwise?

Not sure this is possible. Remember the Makefile is generated by qmake, so we don't have full control over it.

It's a conundrum.

[jerogee]

What about using the package qtchooser? It provides lrelease in Ubuntu 16.04 and afterwards (probably earlier as well), does not seem to depend on QT version, and has way fewer dependencies than qttools5-dev-tools. See Ubuntu Package contents.

[softins]

What about using the package qtchooser? It provides lrelease in Ubuntu 16.04 and afterwards (probably earlier as well), does not seem to depend on QT version, and has way fewer dependencies than qttools5-dev-tools.

As far as I understand, qtchooser is just a wrapper front end allowing different versions of Qt to coexist on a system. It provides /usr/bin/lrelease which will then invoke the actual version such as the one in qttools5-dev-tools. It’s not sufficient on its own.

[jerogee]

Too bad. In that case the behemoth qttools5-dev-tools is all that remains.

[softins]

Actually, thinking about it, it seems reasonable to expect someone building from source to have all the required dev tools, including lrelease. It was just a surprise when I was helping someone last night who was failing to build on Ubuntu 20 using Simon Tomlinson's script (which has now been updated by me).

[mirabilos]

Yes, normally you’d build from source in a clean throw-away chroot in which you then install (only) the necessary build dependencies, so largish dependencies are not a problem.

And, indeed, users have to have either Qt 5.12 (and lrelease installed), or an older Qt and lrelease installed and must run that manually, or the precompiled binary *.qm files (of which I don’t eve know if they’re platform-dependent).

[dingodoppelt]

i saved on a few dependencies by calling:
apt install --no-install-recommends --no-install-suggests qttools5-dev-tools

[softins]

i saved on a few dependencies by calling:
apt install --no-install-recommends --no-install-suggests qttools5-dev-tools

Thanks, Nils, that’s useful to know. I’m still a beginner at the Debian way of doing things! I didn’t know there were recommended and suggested dependencies, as well as required ones.

[gilgongo]

Is this still a poblem?

[hoffie]

Is this still a poblem?

Yes, I think so. I don't know of any working attempt to fix it (I have some tests in a local branch of mine...) and stray .qm files is still an annoying issue when developing and switching branches.

[cdmahoney]

I have the same problem on Ubuntu 20 for just three of the resource files - those ending in pl_PL.qm, it_IT.qm, and sv-SE.qm. These are the only three qm files in that directory that are older than the corresponding ts files. Saving the three qm files to update the timestamp allows me to compile the project without problems.

Could this be fixed in the repository by touching the files to ensure the ts and qm have identical timestamps before uploading them? (I don't have enough knowledge of git to know if this is a practical solution)

[mirabilos]

cdmahoney dixit:

Could this be fixed in the repository by touching the files to ensure the ts and qm have identical timestamps before uploading them? (I don't have enough knowledge of git to know if this is a practical solution)

Unfortunately, not with git. In contrast to proper version control systems, git does not handle timestamps at all. You’ll need some kind of script that touches some files *in order* then creates the archive for this when relying on timestamps. Meow, //mirabilos -- Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~ (as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)

[mirabilos]

Dixi quod…

You’ll need some kind of script that touches some files *in order* then creates the archive for this when relying on timestamps.

In this case, when using a script anyway, it’d be better to not have the binary files in git anyway and just run lrelease before creating the archive. Captain Obvious missed due to time-of-the-night, //mirabilos -- Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~ (as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)

[pljones]

Could someone provide a nice clear statement of what the current position on this is? The issue title could, perhaps, be changed ("Problem building 3.7.0 on Ubuntu 20.04" -- I do this successfully with the master, which is what the example shows being done).

If it's no longer a problem, please close :).

[softins]

I was the OP, and raised it because the Ubuntu 20 system I was building on didn't have lrelease. Once the package containing lrelease is installed, the build works fine. Ubuntu 18 didn't need that because the earlier Qt version ignored the lrelease keyword in Jamulus.pro.

I no longer think this is an issue, so I'll close it.

[pljones]

OK - if lrelease is mentioned as a build-time dependency on Ubuntu with whatever Qt version is relevant, that should do.