Fix ARM CI with QT6

[theofficialgman]

Resolves: #22178
Resolves: #18598

The ARM CI was not updated to support QT6 and so builds have been failing (eg: https://github.com/musescore/MuseScore/actions/runs/9026607087)

This PR firstly fixes the use of qmake6 from distro repositories (where qmake is only QT5).
It makes the necessary changes to the ARM CI to use QT6 from the distro repositories on Ubuntu Jammy.
And finally it changes all remaining CI to use Ubuntu Jammy (as mentioned here #18598 (comment)).

If desired, the x64 Linux build could be swapped over to using the distro QT6 instead of the custom QT6 build and this would allow the setup.sh and setup-arm.sh to be fully combined

• I signed the CLA
• The title of the PR describes the problem it addresses
• Each commit's message describes its purpose and effects, and references the issue it resolves
• If changes are extensive, there is a sequence of easily reviewable commits
• The code in the PR follows the coding rules
• There are no unnecessary changes
• The code compiles and runs on my machine, preferably after each commit individually
• I created a unit test or vtest to verify the changes I made (if applicable)

[theofficialgman]

Passing CI runs:
https://github.com/theofficialgman/MuseScore/actions/runs/9026548403
https://github.com/theofficialgman/MuseScore/actions/runs/9026622031

[theofficialgman]

This PR does not implement the ability to toggle QT5 OFF/ON in the CI (unlike Linux x64 CI). If this is needed let me know.

[theofficialgman]

Passing CI with above commit https://github.com/theofficialgman/MuseScore/actions/runs/9036508620

[cbjeukendrup]

I seem to recall that switching to Ubuntu 22 had some undesirable side effects. @igorkorsukov do you remember more about this? I guess it would mean that MuseScore can't run anymore on Ubuntu 20 and other older OSs because of mismatching C standard library versions, and I'm not sure if we're already ready to drop support for these OSs. OTOH, if the maintainer of Ubuntu is already deprecating 20, that might mean that not many users use it anymore.

[cbjeukendrup]

This PR does not implement the ability to toggle QT5 OFF/ON in the CI (unlike Linux x64 CI). If this is needed let me know.

That's not needed; soon, all traces of Qt 5 will be removed from the master branch.

Also, this PR contains quite some commented code. It would be preferable to delete it entirely, before this PR is merged.

[theofficialgman]

I seem to recall that switching to Ubuntu 22 had some undesirable side effects. @igorkorsukov do you remember more about this? I guess it would mean that MuseScore can't run anymore on Ubuntu 20 and other older OSs because of mismatching C standard library versions, and I'm not sure if we're already ready to drop support for these OSs. OTOH, if the maintainer of Ubuntu is already deprecating 20, that might mean that not many users use it anymore.

Github will start the deprecation process for Ubuntu 20.04 runner soon. It will be removed late this year same as happened for 18.04 two year ago. Its a known process, they only support the latest two LTS at once. Building on Jammy or newer is a requirement for Wayland support for Jammy and newer distros (see the link I posted in the first comment). So now is the time to implement this.

[theofficialgman]

Also, this PR contains quite some commented code. It would be preferable to delete it entirely, before this PR is merged.

Sure but I would like feedback on this comment first:

If desired, the x64 Linux build could be swapped over to using the distro QT6 instead of the custom QT6 build and this would allow the setup.sh and setup-arm.sh to be fully combined

I am not going to waste time cleaning up setup-arm.sh if you want the two scripts to be combined and have the x64 builds use the distro QT6.

[igorkorsukov]

I seem to recall that switching to Ubuntu 22 had some undesirable side effects. @igorkorsukov do you remember more about this? I guess it would mean that MuseScore can't run anymore on Ubuntu 20 and other older OSs because of mismatching C standard library versions, and I'm not sure if we're already ready to drop support for these OSs. OTOH, if the maintainer of Ubuntu is already deprecating 20, that might mean that not many users use it anymore.

I don’t remember which ones exactly, but there were problems with the vtests, so we went back to 20.04
#21981

Github will start the deprecation process for Ubuntu 20.04 runner soon. It will be removed late this year same as happened for 18.04 two year ago. Its a known process, they only support the latest two LTS at once. Building on Jammy or newer is a requirement for Wayland support for Jammy and newer distros (see the link I posted in the first comment). So now is the time to implement this.

We don’t know how we can assess which users there are more, and, accordingly, which part of the users we should refuse.
At the moment, our strategy is to support users with older OS as much as possible.

[igorkorsukov]

I am not going to waste time cleaning up setup-arm.sh if you want the two scripts to be combined and have the x64 builds use the distro QT6.

We cannot use Qt6 from the distro, because there are differences in behavior between different versions of Qt6 (6.2 and 6.5), in order for us to ensure the stability of the application, we need one predefined version of Qt6 and this is 6.2.4.

[theofficialgman]

I am not going to waste time cleaning up setup-arm.sh if you want the two scripts to be combined and have the x64 builds use the distro QT6.

We cannot use Qt6 from the distro, because there are differences in behavior between different versions of Qt6 (6.2 and 6.5), in order for us to ensure the stability of the application, we need one predefined version of Qt6 and this is 6.2.4.

That's not what I was saying. Instead of using your built QT6 tarballs, use the Ubuntu Jammy QT6 (also 6.2.4) and package it in the appimages. This is what is done from the CI for ARM. I'm not saying use the QT6 version from the USERS distro.

[cbjeukendrup]

If the build from Ubuntu repositories is 6.2.4 and stays 6.2.4 until we explicitly ask for something else, and they didn't compile it in any unusual Ubuntu-specific way, then I guess that build is as good as any other build (e.g. self-built ones). So that would be fine, right? (@igorkorsukov)

[igorkorsukov]

Looks like I misunderstood... @cbjeukendrup , yes that's right.
(just in case, for x64 we do not build the Qt ourselves, it is just a Qt downloaded using the Qt online installer)

[cbjeukendrup]

Okay. So @theofficialgman, if Ubuntu's Qt distribution is compatible with non-Ubuntu and indeed stays at 6.2.4 until we ask for something else, you can use that one.

[theofficialgman]

Okay. So @theofficialgman, if Ubuntu's Qt distribution is compatible with non-Ubuntu and indeed stays at 6.2.4 until we ask for something else, you can use that one.

It is. The ARM builds have always been non-QT official builds (since QT doesn't produce official Desktop ARM Linux builds, at least on any current LTS release).

[theofficialgman]

I seem to recall that switching to Ubuntu 22 had some undesirable side effects. @igorkorsukov do you remember more about this? I guess it would mean that MuseScore can't run anymore on Ubuntu 20 and other older OSs because of mismatching C standard library versions, and I'm not sure if we're already ready to drop support for these OSs. OTOH, if the maintainer of Ubuntu is already deprecating 20, that might mean that not many users use it anymore.

I don’t remember which ones exactly, but there were problems with the vtests, so we went back to 20.04 #21981

Github will start the deprecation process for Ubuntu 20.04 runner soon. It will be removed late this year same as happened for 18.04 two year ago. Its a known process, they only support the latest two LTS at once. Building on Jammy or newer is a requirement for Wayland support for Jammy and newer distros (see the link I posted in the first comment). So now is the time to implement this.

We don’t know how we can assess which users there are more, and, accordingly, which part of the users we should refuse. At the moment, our strategy is to support users with older OS as much as possible.

Ok I dropped that change for the x64 linux builds then. You can update to Jammy when you are forced to then (in a few months). You will need to continue to disable Wayland for x64 release builds until you update to Jammy.

[cbjeukendrup]

(The test failure comes from the master branch and is not related to this PR)