Package Details: qgroundcontrol 4.4.4-2

Git Clone URL: https://aur.archlinux.org/qgroundcontrol.git (read-only, click to copy)
Package Base: qgroundcontrol
Description: Micro air vehicle ground control station.
Upstream URL: https://github.com/mavlink/qgroundcontrol
Licenses: GPL3
Submitter: anselmolsm
Maintainer: edombek
Last Packager: edombek
Votes: 13
Popularity: 0.89
First Submitted: 2016-05-13 13:37 (UTC)
Last Updated: 2025-03-29 12:33 (UTC)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 Next › Last »

petronny commented on 2019-05-02 05:34 (UTC) 

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.

kikislater commented on 2019-04-29 09:06 (UTC)

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

petronny commented on 2019-04-29 08:42 (UTC)

I see. We should keep the Qt modules then.

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

kikislater commented on 2019-04-28 05:34 (UTC) (edited on 2019-04-28 05:34 (UTC) by kikislater)

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

pryre commented on 2019-04-28 01:01 (UTC) (edited on 2019-04-28 01:04 (UTC) by pryre)

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.

kikislater commented on 2019-04-24 11:31 (UTC)

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

petronny commented on 2019-04-24 07:29 (UTC)

Hi, why there is a libs directory in /opt/qgroundcontrol/Qt? All the libraries in it have been provided in /usr/lib/.

petronny commented on 2019-04-19 09:22 (UTC) (edited on 2019-04-19 09:25 (UTC) by petronny)

Missing dependencies: 'qt5-location' and 'qt5-svg'.

BTW, there is no need to add \ between the lines in depends, source or the other shell arrays.

pryre commented on 2019-04-17 11:07 (UTC) (edited on 2019-04-17 11:08 (UTC) by pryre)

Information for anyone confused with the soon-to-be-made changes, the following packages now (or will soon) exist and have been updated:

  • qgroundcontrol-bin: the latest release as a precompiled version, as distributed by the mavlink team. This is the package that you should migrate to if you are want the "old" style package that existed here

  • qgroundcontrol: the latest release, but must be compiled yourself.

  • qgroundcontrol-git: the latest development version, as found in the github, but must be compiled yourself.

petronny commented on 2019-04-16 05:38 (UTC)

This is not an any package. Please update arch to arch=('x86_64'). Also please move this package to qgroundcontrol-bin.

« First ‹ Previous 1 2 3 4 5 6 Next › Last »