EdgeTX
chore: bump Ubuntu, Qt and supporting versions
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.
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) ;)
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 https://github.com/richgel999/miniz/issues/337
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.
I cannot see the fix.
He just commented out the policy line in cmake/GenericDefinitions.cmake :hand_over_mouth:
Yes, quick fix for me without any testing except, the radio I was working on still compiles
Looks like CMake 4.x is a happy wrecking ball... it breaks the builds for miniz, yaml-cpp AND maxlibqt, plus edgetx :zany_face:
For miniz, I have a PR pending: richgel999/miniz#339 For yaml-cpp, this PR is already waiting: https://github.com/jbeder/yaml-cpp/pull/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... https://github.com/pfeerick/edgetx/pull/18
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?
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 :zany_face: 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...
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? :rofl: Ok, 6.9 still lists Ubuntu 22.04 (jammy) as supported platform...
A few rebase goofs later (combination of should not be working on this just before bed + github builds way faster than locally :hand_over_mouth: ), 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! :hand_over_mouth:
@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.
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. :shrug: