chore: bump Qt and dependencies

[pfeerick]

Bump to Ubuntu 24.04 LTS (Noble Numbat) 22.04 (Jammy Jellyfish)

Testing the waters... waiting until 24.04.1 before going any further with this.

 E: Unable to locate package python3-clang-10

• might be possible to build from https://pypi.org/project/clang/
• or if possible move to python3-clang-14, as this is the oldest package available there now
• QT is not supported until v6.8 - i.e. QT5.15 LTS and 6.2 LTS requires 20.04, and 6.5 LTS is the first to support 22.04 https://doc.qt.io/qt-5/supported-platforms.html and https://doc.qt.io/qt-6/supported-platforms.html
• Qt version 5.15.1 onward is also compatible with OpenSSL 3.
• gstreamer1.0 support for qt5 and qt6
• Python 3.11 introduced the managed environment breakage aka PEP 668.

[elecpower]

Version not supported for Qt 5.15

[pfeerick]

Thanks, but no need to worry about that yet I don't think... this is only a placeholder for when 22.04 is no longer an option (or we move onto a version QT that is supported) ;)

[elecpower]

Once 2.11 is out the door I will start working on Qt 6.x

[pfeerick]

I don't disagree with this at all (I suggested exactly this myself in the MSYS build scripts), but I have since come across uv thanks to Raphael, and it makes package management and venv effortless... . Worth considering at a future time, if not now.

[elecpower]

Your solution is implemented in multiple files. If not too challenging I vote for changing now,

[elecpower]

Okay so I've had a play with uv and replaced you magic with this hack

RUN wget -qO- https://astral.sh/uv/install.sh | sh && \
    . $HOME/.local/bin/env && \
    uv venv && \
    uv pip install -U pip setuptools && \
    uv pip install \
    asciitree \
    jinja2 \
    pillow \
    aqtinstall \
    lz4 \
    pyelftools

RUN . $HOME/.local/bin/env && \
    uv run aqt install-qt --outputdir ${QT_INSTALL_DIR} ${QT_HOST} ${QT_TARGET} ${QT_VERS_STR} ${QT_ARCH} ${QT_MODULES}

It works but does not save any coding in fact means every python script run needs to be amended. However I stand to be duly corrected on matters such as these.

[raphaelcoeffic]

Using uv, we might want to make things differently:

• install uv into the dev/builder image into /usr/bin
• run aqt install as a "tool" (see uvx)
• move the Python dependencies definitions to a pyproject.toml file in EdgeTx repo
• pull dependencies when preparing build environment with uv sync --frozen
• activate venv with source .venv/bin/activate
• run everything else as usual

We might want to integrate the last 3 steps proper with CMake, so it is done automatically for the user.

[elecpower]

CMake 4.0 breaks things

cmake_policy(SET CMP0023 OLD) has been removed. From Discord I see @gagarinlg has also found and implemented a fix for radio firmware though I cannot see the fix.

miniz has an invalid cmake_minimum_required version. I have bugged with maintainer richgel999/miniz#337

[elecpower]

The change to Qt 6.5 multimedia is frustrating the begeebers out of me. So I'm taking the "throw the sink at it" methodology. When I have sound I'll work backwards to narrow the final list of extras.

[pfeerick]

I cannot see the fix.

He just commented out the policy line in cmake/GenericDefinitions.cmake 🤭

[gagarinlg]

Yes, quick fix for me without any testing except, the radio I was working on still compiles

[pfeerick]

Looks like CMake 4.x is a happy wrecking ball... it breaks the builds for miniz, yaml-cpp AND maxlibqt, plus edgetx 🤪

For miniz, I have a PR pending: richgel999/miniz#339
For yaml-cpp, this PR is already waiting: jbeder/yaml-cpp#1351
For maxlibqt, since we have our own fork, I can bump it via https://github.com/EdgeTX/maxLibQt/tree/pfeerick/bump-cmake-min

These, plus Malte's quick fix at least get the MSYS2 build container up and running again, which is the only one using CMake 4.0 at present.

i.e. This branch has successfully built on my fork... pfeerick/edgetx#18

[elecpower]

AppImages appear to not be backward compatible (could just be me) e.g. noble will not run on jammy lots of errors like this on launching:

/tmp/.mount_EdgeTXfeiGJn/AppRun.wrapped: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by /tmp/.mount_EdgeTXfeiGJn/usr/bin/../lib/libglib-2.0.so.0)

jammy AppImage will run on jammy and noble

If this is the case then the question is, what is the oldest version we want to support keeping in mind the different Linux flavours?

[pfeerick]

Well, since jammy (22.04) is a LTS as well, so we could increment to that rather than jump to noble (24.04). We're currently using focal (20.04) for dev and jammy for cloudbuild, so at minimum need to correct that discrepancy 🤪 Ubuntu 22.04 (jammy) is a supported platform for QT6.5, so that isn't a problem...

It doesn't surprise me that an AppImage built on Noble would/could have problems when running on Jammy, given mention to build on the oldest platform intended to support...

[pfeerick]

Want me to change it to jammy while rebasing (and we can start again from there)?

Oh, wait, you're trying to confuse me... 6.5, 6.8.2, 6.9.0? 🤣 Ok, 6.9 still lists Ubuntu 22.04 (jammy) as supported platform...

[elecpower]

My aim in life is to confuse as many as possible ;-)

[elecpower]

Jammy

[pfeerick]

A few rebase goofs later (combination of should not be working on this just before bed + github builds way faster than locally 🤭 ), and it should be right now. We can skip the --break-system-packages flag for python since jammy doesn't have that issue. i.e. allowing this to merge, and then I'll start working in the successor / uv. So if I didn't break anything, this is ready to play with again. QT version is still 6.8.2 btw ;) I'm hoping unpinning pillow won't bite us, as tests-radio target is only run using the dev image, and that has been a pain before. Only one way to check! 🤭

[raphaelcoeffic]

@pfeerick do we still need anything from this PR? AFAIK, everything has been already merged bit by bit and works well with Qt6 on main.

[pfeerick]

No, it looks like everything Neil wanted was here. Would have been better to have simply rebased and merged this PR though rather than rush through a potentially incomplete one since this had been used and tested or the last six months. 🤷