Arch Linux User Repository

Same error for me.

Same error here with the patch. Should this package be flagged as outdated for this reason?

Renaming the patch file from to qgroundcontrol-3.5.3.patch to qgroundcontrol-libicudata.patch made it build for me, but I'm not sure if that's the only change that @pryre made.

Missing file:

==> Starting prepare()...
/startdir/PKGBUILD: line 77: /startdir/qgroundcontrol-libicudata.patch: No such file or directory

Copying files
cp: cannot stat '/usr/lib/libicudata.so.56': No such file or directory
make: *** [Makefile:2584: release/QGroundControl] Error 1
==> ERROR: A failure occurred in build().

Maybe that patch is still needed.

It's solved in 3.5.2, please update. Don't liké third party repository as I had too much bugs ... Aur is here and it's fine

I see. We should keep the Qt modules then.

@kikislater You can also download qgroundcontrol from arch4edu. It's compiled with this PKGBUILD.

Ok make sense ! for version. Thanks @pyre for packages and happy flying ;-)

So we have 5 solutions in Arch based distribution now

• 3 AUR packages

• 2 App Images from website

Hi Guys,

I appreciate the feedback, and sorry I haven't been able to make changes very quickly, I haven't had a internet connection at home for the last 2 weeks.

petronny (19th): thanks, I cleaned things up a bit, should be nicer now.

petronny (24th): I believe this is part of the QGroundControl build process, and due to the way they use Qt abstract classes in private headers. From the start of the build log:

Project MESSAGE: This project is using private headers and will therefore be tied to this specific Qt module build version.
Project MESSAGE: Running this project against other versions of the Qt modules may crash at any arbitrary point.
Project MESSAGE: This is not a bug, but a result of using Qt internals. You have been warned!

This is part of their standard package distribution method, and if you check the start script, you'll see where they pull in the custom libs. So we have 2 options: either have the package potentially break on Qt updates, or copy the folder to libs and risk running an older / duplicate version. Obviously the first method would be preferable, but it would mean we either have users rebuild manually (or add a hook to rebuild on Qt updates?), an risk breaking, or we bump the package version on each Qt build (which I'm not keen on doing at all). If you have thoughts or another option, let me know.

kikislater (24th): In terms of Qt versions, yes they use a different of Qt than Arch does (they periodically push forward versions or something to that effect), and that explains the use of the libs/Qt in the -bin package. As for the "3 packages" question:

• -git pulls from git master, and is self-sustaining. I think this package is fine how it is.
• -bin is the pre-compiled release from the mavlink guys. I think this is self-explanatory as well.
• This package is the one that is floating in the void. I suppose one option would be to do what is mentioned above and have this as a stripped-down version that relies on system Qt libs, and just let users deal with the breakages. If a user wants a stable release, then use the -bin release, as it is pretty much the same as this package, but just uses the QGCS-decided Qt libs and doesn't waste the users time building the package. Incidentally, if we go this route, then I think the -git package should follow suit with using system libs.

(Edit): Honestly, it doesn't bother me with what is decided for the source packages, as I use the pre-built package anyway. I don't use QGCS enough at the moment to be bother rebuilding it myself. I am happy to keep maintaining the packages though.

Why is there 2 packages (in fact 3 but git is easily understandable) ? Agree with petronny but I think QGC use different versions of Qt than we have in Arch