Hmm, well that looks like it’s something external that’s doing the SIGKILL.
Next step would be to look through dmesg & syslog to see if there’s anything unusual in there.
ubuntu@ubuntu:~$ sudo killall rsyslogd
ubuntu@ubuntu:~$ sudo rsyslogd -dn | grep dump1090
9805.812000303:main Q:Reg/w0 : ruleset.c: processBATCH: next msg 0: <30>Apr 26 22:23:25 systemd[1]: dump1090-fa.service: Scheduled restart job, restart counter is at 15.
9805.812182501:main Q:Reg/w0 : ruleset.c: Filter: check for property 'msg' (value ' dump1090-fa.service: Scheduled restart job, restart counter is at 15.') contains '[UFW ': FALSE
9805.815661914:main Q:Reg/w0 : omfile.c: omfile: write to stream, pData->pStrm 0xffffac000d60, lenBuf 105, strt data Apr 26 22:23:25 ubuntu systemd[1]: dump1090-fa.service: Scheduled restart job, restart counter is at 15.
9805.816328678:main Q:Reg/w0 : ruleset.c: processBATCH: next msg 0: <30>Apr 26 22:23:25 systemd[1]: Stopped dump1090 ADS-B receiver (FlightAware customization).
9805.816505636:main Q:Reg/w0 : ruleset.c: Filter: check for property 'msg' (value ' Stopped dump1090 ADS-B receiver (FlightAware customization).') contains '[UFW ': FALSE
9805.819564734:main Q:Reg/w0 : omfile.c: omfile: write to stream, pData->pStrm 0xffffac000d60, lenBuf 96, strt data Apr 26 22:23:25 ubuntu systemd[1]: Stopped dump1090 ADS-B receiver (FlightAware customization).
9805.823289689:main Q:Reg/w0 : ruleset.c: processBATCH: next msg 0: <30>Apr 26 22:23:25 systemd[1]: Started dump1090 ADS-B receiver (FlightAware customization).
9805.823370548:main Q:Reg/w0 : ruleset.c: Filter: check for property 'msg' (value ' Started dump1090 ADS-B receiver (FlightAware customization).') contains '[UFW ': FALSE
9805.824628846:main Q:Reg/w0 : omfile.c: omfile: write to stream, pData->pStrm 0xffffac000d60, lenBuf 96, strt data Apr 26 22:23:25 ubuntu systemd[1]: Started dump1090 ADS-B receiver (FlightAware customization).
9805.833265450:main Q:Reg/w0 : ruleset.c: processBATCH: next msg 0: <30>Apr 26 22:23:25 dump1090-fa[1819]: Sun Apr 26 22:23:25 2020 UTC dump1090-fa 3.8.1 starting up.
9805.833339070:main Q:Reg/w0 : ruleset.c: Filter: check for property 'msg' (value ' Sun Apr 26 22:23:25 2020 UTC dump1090-fa 3.8.1 starting up.') contains '[UFW ': FALSE
9805.833418412:main Q:Reg/w0 : ruleset.c: Filter: check for property 'syslogtag' (value 'dump1090-fa[1819]:') isequal '[CLOUDINIT]': FALSE
9805.834468977:main Q:Reg/w0 : omfile.c: omfile: write to stream, pData->pStrm 0xffffac000d60, lenBuf 103, strt data Apr 26 22:23:25 ubuntu dump1090-fa[1819]: Sun Apr 26 22:23:25 2020 UTC dump1090-fa 3.8.1 starting up.
9805.883415891:main Q:Reg/w0 : ruleset.c: processBATCH: next msg 0: <30>Apr 26 22:23:25 dump1090-fa[1819]: rtlsdr: using device #0: Generic RTL2832U (Realtek, RTL2832U, SN 00001090)
9805.883569204:main Q:Reg/w0 : ruleset.c: Filter: check for property 'syslogtag' (value 'dump1090-fa[1819]:') isequal '[CLOUDINIT]': FALSE
9805.884650154:main Q:Reg/w0 : omfile.c: omfile: write to stream, pData->pStrm 0xffffac000d60, lenBuf 117, strt data Apr 26 22:23:25 ubuntu dump1090-fa[1819]: rtlsdr: using device #0: Generic RTL2832U (Realtek, RTL2832U, SN 00001090)
9806.127710155:main Q:Reg/w0 : ruleset.c: processBATCH: next msg 0: <30>Apr 26 22:23:26 dump1090-fa[1819]: Found Rafael Micro R820T tuner
9806.128159208:main Q:Reg/w0 : ruleset.c: Filter: check for property 'syslogtag' (value 'dump1090-fa[1819]:') isequal '[CLOUDINIT]': FALSE
9806.131029091:main Q:Reg/w0 : omfile.c: omfile: write to stream, pData->pStrm 0xffffac000d60, lenBuf 73, strt data Apr 26 22:23:26 ubuntu dump1090-fa[1819]: Found Rafael Micro R820T tuner
9806.286520178:main Q:Reg/w0 : ruleset.c: processBATCH: next msg 0: <30>Apr 26 22:23:26 dump1090-fa[1819]: rtlsdr: enabling tuner AGC
9806.286913275:main Q:Reg/w0 : ruleset.c: Filter: check for property 'syslogtag' (value 'dump1090-fa[1819]:') isequal '[CLOUDINIT]': FALSE
9806.289888477:main Q:Reg/w0 : omfile.c: omfile: write to stream, pData->pStrm 0xffffac000d60, lenBuf 69, strt data Apr 26 22:23:26 ubuntu dump1090-fa[1819]: rtlsdr: enabling tuner AGC
9806.481071365:main Q:Reg/w0 : ruleset.c: processBATCH: next msg 0: <30>Apr 26 22:23:26 dump1090-fa[1819]: Allocating 4 zero-copy buffers
9806.481545470:main Q:Reg/w0 : ruleset.c: Filter: check for property 'syslogtag' (value 'dump1090-fa[1819]:') isequal '[CLOUDINIT]': FALSE
9806.484597144:main Q:Reg/w0 : omfile.c: omfile: write to stream, pData->pStrm 0xffffac000d60, lenBuf 73, strt data Apr 26 22:23:26 ubuntu dump1090-fa[1819]: Allocating 4 zero-copy buffers
9806.485991165:main Q:Reg/w0 : ruleset.c: processBATCH: next msg 0: <28>Apr 26 22:23:26 systemd[1]: dump1090-fa.service: Main process exited, code=killed, status=9/KILL
9806.486168234:main Q:Reg/w0 : ruleset.c: Filter: check for property 'msg' (value ' dump1090-fa.service: Main process exited, code=killed, status=9/KILL') contains '[UFW ': FALSE
9806.488768689:main Q:Reg/w0 : omfile.c: omfile: write to stream, pData->pStrm 0xffffac000d60, lenBuf 104, strt data Apr 26 22:23:26 ubuntu systemd[1]: dump1090-fa.service: Main process exited, code=killed, status=9/KILL
9806.489000640:main Q:Reg/w0 : ruleset.c: processBATCH: next msg 0: <28>Apr 26 22:23:26 systemd[1]: dump1090-fa.service: Failed with result 'signal'.
9806.489077130:main Q:Reg/w0 : ruleset.c: Filter: check for property 'msg' (value ' dump1090-fa.service: Failed with result 'signal'.') contains '[UFW ': FALSE
9806.490308580:main Q:Reg/w0 : omfile.c: omfile: write to stream, pData->pStrm 0xffffac000d60, lenBuf 85, strt data Apr 26 22:23:26 ubuntu systemd[1]: dump109 -fa.service: Failed with result 'signal'.
1 Like
Uh no I meant the general syslog messages file that is usually written to /var/log/syslog or /var/log/messages. Maybe there is something from another process (systemd, etc) logged there that’s saying that it decided to kill dump1090.
/var/log/messages not found.
Only /var/log/syslog and /var/log/dmesg found.
Too big to post. Uploaded to DropBox. Download links are below:
NOTE: When I opened these downloaded files in Windows with Notepad, it was hard to read, no line breaks. I then opened these files in Notepad ++ and it showed line breaks properly.
Also, when I uploaded these files, these did not have any file extension. The DropBox added .sqb file extension.
Hm, nothing obvious in there, sorry. Not sure what’s going on.
@obj
Thanks for your help.
No problem if we could not debug it. I am not keen to find a solution for this distro if it is hard.
I am happy with my Piaware SD card img and Raspbian Buster img installs, which are so easy and headache free.
Tried on UBUNTU 20.02 32 bit version - SUCCESS
$ uname -a
Linux ubuntu 5.4.0-1008-raspi #8-Ubuntu SMP Wed Apr 8 11:17:03 UTC 2020 armv7l armv7l armv7l GNU/Linux
$ lsb_release -sc
focal
$ cat /etc/debian_version
bullseye/sid
(1) Installed Tools & Dependencies
## Build Tools
$ sudo apt install git dh-systemd
## Build dependencies:
$ sudo apt install librtlsdr-dev libusb-1.0-0-dev pkg-config libncurses5-dev
## Install dependencies:
sudo apt install lighttpd
(2) Cloned source-code, did workaround for bladeRF
$ git clone https://github.com/flightaware/dump1090 dump1090-fa
## In the cloned source-code, Edit two files (debian/rules and debian/control)
$ sudo nano dump1090-fa/debian/rules
## Scroll down to this line:
dh_auto_build -- RTLSDR=yes BLADERF=yes DUMP1090_VERSION=$(DEB_VERSION)
## In above line, change `BLADERF=yes` to `BLADERF=no`, so it becomes as follows
dh_auto_build -- RTLSDR=yes BLADERF=no DUMP1090_VERSION=$(DEB_VERSION)
$ sudo nano dump1090-fa/debian/control
## Modification (1) Scroll down to this line
Build-Depends: debhelper(>=9), librtlsdr-dev, libusb-1.0-0-dev, pkg-config, dh-systemd, libncurses5-dev, libbladerf-dev
## Deleted `, libbladerf-dev`, so the line became:
Build-Depends: debhelper(>=9), librtlsdr-dev, libusb-1.0-0-dev, pkg-config, dh-systemd, libncurses5-de
## Modification (2) Scroll down to this line
Depends: ${shlibs:Depends}, ${misc:Depends}, libbladerf1 (>= 0.2016.06), adduser, lighttpd
## Deleted `libbladerf1 (>= 0.2016.06), ` so the line became:
Depends: ${shlibs:Depends}, ${misc:Depends}, adduser, lighttpd
(3) Build & Installed dump1090-fa package
$ cd dump1090-fa
$ sudo dpkg-buildpackage -b --no-sign
$ cd ../
$ sudo dpkg -i dump1090-fa_3.8.1_armhf.deb
$ sudo reboot
(4) Checked status, SUCCESS
ubuntu@ubuntu:~$ sudo systemctl status dump1090-fa
● dump1090-fa.service - dump1090 ADS-B receiver (FlightAware customization)
Loaded: loaded (/lib/systemd/system/dump1090-fa.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2020-04-28 17:56:43 UTC; 2min 8s ago
Docs: https://flightaware.com/adsb/piaware/
Main PID: 1198 (dump1090-fa)
Tasks: 3 (limit: 1828)
CGroup: /system.slice/dump1090-fa.service
└─1198 /usr/bin/dump1090-fa --device-index 0 --gain -10 --ppm 0 --max-range 360 --fix --net --net-heartbeat 60 --net>
Apr 28 17:56:43 ubuntu systemd[1]: Started dump1090 ADS-B receiver (FlightAware customization).
Apr 28 17:56:43 ubuntu dump1090-fa[1198]: Tue Apr 28 17:56:43 2020 UTC dump1090-fa 3.8.1 starting up.
Apr 28 17:56:43 ubuntu dump1090-fa[1198]: rtlsdr: using device #0: Generic RTL2832U (Realtek, RTL2832U, SN 00001090)
Apr 28 17:56:43 ubuntu dump1090-fa[1198]: Detached kernel driver
Apr 28 17:56:44 ubuntu dump1090-fa[1198]: Found Rafael Micro R820T tuner
Apr 28 17:56:44 ubuntu dump1090-fa[1198]: rtlsdr: enabling tuner AGC
Apr 28 17:56:44 ubuntu dump1090-fa[1198]: Allocating 4 zero-copy buffers
Apr 28 17:56:44 ubuntu dump1090-fa[1198]: Detected Kernel usbfs mmap() bug, falling back to buffers in userspace
2 Likes
I’m somewhat suspicious that it’s the zero-copy stuff that’s failing (the code for the “detected kernel bug” message executes right after the “allocated zero-copy buffers” message, and I would have expected the 32- and 64-bit kernels to either both have the same bug or not have the bug); but the weird thing is that it’s a SIGKILL that arrives, I would have expected SIGSEGV/SIGBUS if something went wrong there.
1 Like
I installed this on my Pi 4 and did some debugging; the problem is indeed with the librtlsdr zero-copy stuff. It looks like access to the mmap-ed region of device memory allocated by libusb produces a SIGKILL (unexpected - I would have expected a SIGSEGV); this interferes with librtlsdr trying to see if the kernel has the USB mmap bug where it would map some random page, not a zero page (which it does by looking at the contents of the mapped memory - which produces a SIGKILL here…)
I think this will need a librtlsdr rebuild with the zero copy stuff turned off to avoid it. [or possibly an updated kernel]
4 Likes
just wanted to say that after pulling my hair out for days to get FA to work on a VM, this guide finally worked, thanks for everyone hard work.
1 Like
UBUNTU 20.04 armhf 32 bit version
ubuntu-20.04-preinstalled-server-armhf+raspi.img
$ cat /boot/README
An overview of the files on the /boot/firmware partition (the 1st partition
on the SD card) used by the Ubuntu boot process (roughly in order) is as
follows:
* bootcode.bin - this is the second stage bootloader loaded by all pis with
the exception of the pi4 (where this is replaced by flash
memory)
* config.txt - the first configuration file read by the boot process
* syscfg.txt - the file in which system modified configuration will be
placed, included by config.txt
* usercfg.txt - the file in which user modified configuration should be
placed, included by config.txt
* start*.elf - the third stage bootloader, which handles device-tree
modification and which loads...
* uboot*.bin - various u-boot binaries for different pi platforms; these
are launched as the "kernel" by config.txt
* boot.scr - the boot script executed by uboot*.bin which in turn
loads...
* vmlinuz - the Linux kernel, executed by boot.scr
* initrd.img - the initramfs, executed by boot.scr
* meta-data - meta-data for cloud-init; usually just contains the
instance id
* network-config - network configuration for cloud-init; edit this to set up
wifi access points and other networking settings
* user-data - user-data for cloud-init; edit this to configure initial
users, SSH keys, packages, etc.
Just running in to this today, glad smart folks are already looking in to it. I’d like to keep my Pi 4 64 bit if possible since I do plan to run other things on it. Thanks for the pointers on librtlsdr, I have worked with that before so will take a shot at building with the mmap/zcp stuff off.
@postl
Great. If you succeed, please dont forget to post step-by -step method for benefit of so many others who want to run 64 bit on Pi4. Thanks
That’s a big if, but I certainly will.
We’re not the first ones to find this. The most promising lead I have so far is a patch someone posted on Reddit - https://www.reddit.com/r/RTLSDR/comments/ds73ow/rtl_process_being_killed_newbie_troubleshooting/f6ynsaw/
I’ve checked out librtlsdr 0.6.0 and applied that patch, so far no luck but I’m trying a few other things, I have a feeling my build with the patch applied is not what was being used in the later rebuild of dump1090-fa.
1 Like
Alright, I was able to get a build working using that patch from Reddit. I’ll explain my process here and also revisit and try to run through the process from scratch in the morning to verify I didn’t miss anything.
First, uninstall all librtlsdr and dump1090 packages that you might already have installed from previous attempts:
sudo apt remove librtlsdr0 librtlsdr-dev dump1090-fa
We will replace them with our patched versions, starting with librtlsdr.
First we’ll fetch the librtlsdr source (I used a GitHub mirror, not the upstream directly but that should also work just fine)
git clone https://github.com/steve-m/librtlsdr
cd librtlsdr
git checkout 0.6.0
I used a text editor to apply the patch from Reddit
ubuntu@ubuntu:~/librtlsdr$ git diff
diff --git a/src/librtlsdr.c b/src/librtlsdr.c
index 433ed5b..cdd2853 100644
--- a/src/librtlsdr.c
+++ b/src/librtlsdr.c
@@ -1748,7 +1748,7 @@ static int _rtlsdr_alloc_async_buffers(rtlsdr_dev_t *dev)
dev->xfer_buf = malloc(dev->xfer_buf_num * sizeof(unsigned char *));
memset(dev->xfer_buf, 0, dev->xfer_buf_num * sizeof(unsigned char *));
-#if defined (__linux__) && LIBUSB_API_VERSION >= 0x01000105
+#if defined (__linux__) && LIBUSB_API_VERSION >= 0x01000105 && 0
fprintf(stderr, "Allocating %d zero-copy buffers\n", dev->xfer_buf_num);
dev->use_zerocopy = 1;
We’re just adding the ‘&& 0’ to the end of one line to negate the version check. Next we build, package, and install the library with this change.
mkdir build
cd build
cmake ../
make
cd ..
dpkg-buildpackage -b
cd ..
sudo dpkg -i librtlsdr0_0.6git_arm64.deb
sudo dpkg -i librtlsdr-dev_0.6git_arm64.deb
If you run in to issues with these let me know, I can try to reproduce or troubleshoot. With the patched librtlsdr packages installed we can now install dump1090 as folks have been.
git clone https://github.com/flightaware/dump1090.git
cd dump1090
dpkg-buildpackage -b
cd ..
dpkg -i dump1090-fa_3.8.1_arm64.deb
My current diff on this to address BladeRF issues is:
ubuntu@ubuntu:~/dump1090$ git diff
diff --git a/Makefile b/Makefile
index 6343ffb..c608333 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
PROGNAME=dump1090
RTLSDR ?= yes
-BLADERF ?= yes
+BLADERF ?= no
CPPFLAGS += -DMODES_DUMP1090_VERSION=\"$(DUMP1090_VERSION)\" -DMODES_DUMP1090_VARIANT=\"dump1090-fa\"
diff --git a/debian/control b/debian/control
index f60de0d..729577a 100644
--- a/debian/control
+++ b/debian/control
@@ -19,7 +19,7 @@ Description: transitional dummy package for dump1090
Package: dump1090-fa
Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, libbladerf1 (>= 0.2016.06), adduser, lighttpd
+Depends: ${shlibs:Depends}, ${misc:Depends}, adduser, lighttpd
Replaces: dump1090 (<< 3.0)
Breaks: dump1090 (<< 3.0)
Description: ADS-B Ground Station System for RTL-SDR
diff --git a/debian/rules b/debian/rules
index b97cd02..d31ed38 100755
--- a/debian/rules
+++ b/debian/rules
@@ -20,7 +20,7 @@ ifeq ($(DEB_HOST_ARCH),armhf)
endif
override_dh_auto_build:
- dh_auto_build -- RTLSDR=yes BLADERF=yes DUMP1090_VERSION=$(DEB_VERSION)
+ dh_auto_build -- RTLSDR=yes BLADERF=no DUMP1090_VERSION=$(DEB_VERSION)
override_dh_install:
dh_install
After dump1090-fa installed the systemd service came up just fine and piaware picked it up, connected, and started reporting spots.
2 Likes
@postl
Thank you 
Just to follow up, I’ve had one issue issue with this now. It is otherwise working great. apt/Ubuntu think that their librtlsdr package is an ‘upgrade’ to the one I manually built and installed:
ubuntu :: ~ » apt list --upgradeable
Listing... Done
debootstrap/focal-updates 1.0.118ubuntu1.1 all [upgradable from: 1.0.118ubuntu1]
landscape-common/focal-updates 19.12-0ubuntu4.1 arm64 [upgradable from: 19.12-0ubuntu4]
librtlsdr-dev/focal 0.6.0-3 arm64 [upgradable from: 0.6git]
librtlsdr0/focal 0.6.0-3 arm64 [upgradable from: 0.6git]
Since I have autoupdates configured at some point overnight Ubuntu ran that and replaced my librtlsdr build with the upstream one which caused dump1090-fa to start crashing again. I manually removed and reinstalled my version this morning and am looking in to how to prevent updates of specific packages.
EDIT: I marked the packages as ‘hold’ using apt which prevents them from being updated automatically by the package manager.
ubuntu :: ~ » sudo apt-mark hold librtlsdr0 librtlsdr-dev
librtlsdr0 set on hold.
librtlsdr-dev set on hold.
ubuntu :: ~ » sudo apt upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
liblimesuite20.01-1 libosmosdr0 limesuite-udev soapyosmo-common0.7 soapysdr0.7-module-lms7 soapysdr0.7-module-osmosdr
Use 'sudo apt autoremove' to remove them.
The following packages have been kept back:
librtlsdr-dev librtlsdr0
The following packages will be upgraded:
debootstrap landscape-common
2 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
Need to get 126 kB of archives.
After this operation, 1024 B of additional disk space will be used.
3 Likes
To prevent Ubuntu to upgrade librtlsdr0 and librtlsdr-dev, I tried to build deb package with version number 0.6.0-3 instead of 0.6git
ubuntu@ubuntu:~/librtlsdr$ sudo nano CMakeLists.txt
Scrolled down to this part of code:
# Set the version information here
set(VERSION_INFO_MAJOR_VERSION 0) # increment major on api compatibility changes
set(VERSION_INFO_MINOR_VERSION 6) # increment minor on feature-level changes
set(VERSION_INFO_PATCH_VERSION 0) # increment patch for bug fixes and docs
In the last line, changed 0 to 0-3, so it became:
set(VERSION_INFO_PATCH_VERSION 0-3) # increment patch for bug fixes and docs
Then ran:
ubuntu@ubuntu:~/librtlsdr/build$ cmake ../
Got this output: 
-- Building for version: 0.6.0-3 / 0.6.0-3
Ran following commands
cd ../
make
cd ../
dpkg-buildpackage -b
The packages built did not have version 0.6.0-3
They still had version number 0.6git 
librtlsdr0_0.6git_arm64.deb
librtlsdr-dev_0.6git_arm64.deb
1 Like
For debian/ubuntu packages, the package version is determined by looking at the latest entry in the changelog (debian/changelog)
If you want to bump the version locally then dch can help you add a new entry to the changelog with a new version (in particular see the --local switch). This is how piaware et al change the package version for backports to stretch etc.
2 Likes
OK, modified version number in debian/changelog and built package with version 0.6.0-3, and installed, but Ubuntu repository is smart, refuses to accept bumped version as genuine:
ubuntu@ubuntu:~$ apt list --upgradable
Listing... Done
... ... ...
... ... ...
librtlsdr-dev/focal 0.6.0-3 arm64 [upgradable from: 0.6.0-3]
librtlsdr0/focal 0.6.0-3 arm64 [upgradable from: 0.6.0-3]
... ... ...
... ... ...
ubuntu@ubuntu:~/librtlsdr$ git diff
diff --git a/debian/changelog b/debian/changelog
index 24d97e2..83f63a3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,4 +1,4 @@
-rtl-sdr (0.6git) unstable; urgency=medium
+rtl-sdr (0.6.0-3) unstable; urgency=medium
* New upstream release
diff --git a/src/librtlsdr.c b/src/librtlsdr.c
index 433ed5b..cdd2853 100644
--- a/src/librtlsdr.c
+++ b/src/librtlsdr.c
@@ -1748,7 +1748,7 @@ static int _rtlsdr_alloc_async_buffers(rtlsdr_dev_t *dev)
dev->xfer_buf = malloc(dev->xfer_buf_num * sizeof(unsigned char *));
memset(dev->xfer_buf, 0, dev->xfer_buf_num * sizeof(unsigned char *));
-#if defined (__linux__) && LIBUSB_API_VERSION >= 0x01000105
+#if defined (__linux__) && LIBUSB_API_VERSION >= 0x01000105 && 0
fprintf(stderr, "Allocating %d zero-copy buffers\n", dev->xfer_buf_num);
dev->use_zerocopy = 1;
ubuntu@ubuntu:~$ ls
dump1090-fa librtlsdr-dev_0.6.0-3_arm64.deb
dump1090-fa-dbgsym_3.8.1_arm64.ddeb librtlsdr0-dbgsym_0.6.0-3_arm64.ddeb
dump1090-fa_3.8.1_arm64.buildinfo librtlsdr0_0.6.0-3_arm64.deb
dump1090-fa_3.8.1_arm64.changes rtl-sdr-dbgsym_0.6.0-3_arm64.ddeb
dump1090-fa_3.8.1_arm64.deb rtl-sdr_0.6.0-3_arm64.buildinfo
dump1090_3.8.1_all.deb rtl-sdr_0.6.0-3_arm64.changes
librtlsdr rtl-sdr_0.6.0-3_arm64.deb