Package Details: dump1090-fa-git 1:9.0.r0.ga80ba8f8-2

Git Clone URL: https://aur.archlinux.org/dump1090-fa-git.git (read-only, click to copy)
Package Base: dump1090-fa-git
Description: FlightAware/Mutability fork of dump1090, a simple Mode S decoder for RTLSDR devices.
Upstream URL: https://github.com/flightaware/dump1090
Keywords: dump1090 mutability
Licenses: BSD
Conflicts: dump1090, dump1090-git, dump1090_mr-git
Provides: dump1090, dump1090-fa
Submitter: anish
Maintainer: anish
Last Packager: anish
Votes: 15
Popularity: 0.001827
First Submitted: 2015-06-22 04:22 (UTC)
Last Updated: 2024-08-26 20:16 (UTC)

Required by (4)

Sources (4)

Latest Comments

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

test0 commented on 2019-04-22 07:13 (UTC) (edited on 2019-04-22 07:36 (UTC) by test0)

EDIT: sorry, a clean build fixed it. Using the dev branch works OK with the latest piaware-git (+ Itcl patch).

I cannot compile the dev branch on armv7h. Compilation hangs at:

cc -D_FORTIFY_SOURCE=2 -DMODES_DUMP1090_VERSION=\"\" -DMODES_DUMP1090_VARIANT=\"dump1090-fa\" -DENABLE_RTLSDR -DENABLE_BLADERF -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -O2 -pipe -fstack-protector-strong -fno-plt -std=c11 -O2 -g -Wall -Werror -W -D_DEFAULT_SOURCE -I/usr/include/ -I/usr/include/libusb-1.0  -I/usr/include/  -c mode_ac.c -o mode_ac.o

PanisSupraOmnia commented on 2019-04-21 22:16 (UTC)

@anish thanks for fixing it! Sorry to keep bothering you, but I also just realized: since you changed piaware-git to use the dev branch as its source, do you think you could do the same for this package? I noticed that piaware was complaining about a version mismatch in its logs, and editing this PKGBUILD to point to the dev branch fixed it.

anish commented on 2019-04-20 22:50 (UTC)

@panissupraomnia I was thinking about that but most of the definitions in show_config() are wrong that way. For now that is a better fix, updated

PanisSupraOmnia commented on 2019-04-20 21:38 (UTC)

Yeah, this doesn't work on aarch64. Due to the pre-processor conditional, freq doesn't get defined, so the build errors out in that same function as before. Since you've updated the dependency on bladerf to be >=2.0.2, is there any reason why you even need the architecture-dependent definitions? I would think that just replacing it with the bladerf_frequency typedef would work across platforms (and be more clear).

anish commented on 2019-04-20 06:56 (UTC)

This should be working for everyone now, but I was only able to test arm6/arm7 & x86_64. Please let me know if you're on a different arm processor and it does not work for you

PanisSupraOmnia commented on 2019-03-20 20:11 (UTC) (edited on 2019-03-20 20:11 (UTC) by PanisSupraOmnia)

You'd probably figure this out pretty quickly, but this is the same issue that @kikoloche posted about in February, and I believe my solution is correct (it's been working fine for me at least). Unfortunately the fix hasn't made it into upstream because they need to maintain compatibility with Debian Jessie, which made the PR to fix it stall (see https://github.com/flightaware/dump1090/pull/22).

anish commented on 2019-03-20 19:44 (UTC)

Thanks for the heads up, I'll get to this tonight

Maria commented on 2019-03-20 19:23 (UTC)

Thank you for the great PKGBUILD. It seems that this version fails to build because of the bladerf dependency: not using bladerf but having this version bladerf 2.0.2-1

sdr_bladerf.c: In function ‘show_config’: sdr_bladerf.c:116:76: error: passing argument 3 of ‘bladerf_get_frequency’ from incompatible pointer type [-Werror=incompatible-pointer-types] (status = bladerf_get_frequency(BladeRF.device, BLADERF_MODULE_RX, &freq)) < 0 || ^~~~~ In file included from sdr_bladerf.c:23: /usr/include/libbladeRF.h:1162:56: note: expected ‘bladerf_frequency ’ {aka ‘long unsigned int ’} but argument is of type ‘unsigned int ’ bladerf_frequency frequency); ~~~~~~~~~~~~~~~~~~~^~~~~~~~~ cc1: all warnings being treated as errors make: *** [Makefile:41: sdr_bladerf.o] Error 1

kikoloche commented on 2019-02-16 19:53 (UTC)

Thanks. It works again with bladerf 2.0.2 version instaled

PanisSupraOmnia commented on 2019-02-16 17:50 (UTC)

Also, just to note, I can confirm that this builds successfully on aarch64, if you'd like to add that to the arch list.