Arch Linux User Repository

thanks @m1h. I suggest waiting for that to be merged upstream

There is a fix for gcc-15 and clang for string initialization: https://github.com/flightaware/dump1090/pull/261/files

Patch:

diff -aur dump1090/ais_charset.c dump1090_new/ais_charset.c
--- dump1090/ais_charset.c  2026-01-15 15:29:32.582873756 +0000
+++ dump1090_new/ais_charset.c  2026-01-15 15:37:46.510014906 +0000
@@ -1,3 +1,3 @@
 #include "ais_charset.h"

-char ais_charset[64] = "@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_ !\"#$%&'()*+,-./0123456789:;<=>?";
+char ais_charset[65] = "@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_ !\"#$%&'()*+,-./0123456789:;<=>?";
diff -aur dump1090/interactive.c dump1090_new/interactive.c
--- dump1090/interactive.c  2026-01-15 15:29:32.618878654 +0000
+++ dump1090_new/interactive.c  2026-01-15 15:36:54.864180660 +0000
@@ -140,7 +140,7 @@
     static bool need_clear = true;
     uint64_t now = mstime();
     char progress;
-    char spinner[4] = "|/-\\";
+    char spinner[5] = "|/-\\";
     int valid = 0;
     double signalMax = -100.0;
     double signalMin = +100.0;
diff -aur dump1090/ais_charset.h dump1090_new/ais_charset.h
--- dump1090/ais_charset.h  2026-01-15 15:44:18.998128661 +0000
+++ dump1090_new/ais_charset.h  2026-01-15 15:45:27.358585702 +0000
@@ -1,6 +1,6 @@
 #ifndef AIS_CHARSET_H
 #define AIS_CHARSET_H

-extern char ais_charset[64];
+extern char ais_charset[65];

 #endif

Worked around the build issue by adding -Wno-error=unterminated-string-initialization to /etc/makepkg.conf CFLAGS but it would be nicer if the source was just patched to bypass the issue.

Hello anish

I get build errors like this when I build this:

ais_charset.c:3:24: error: initializer-string for array of ‘char’ truncates NUL terminator but destination lacks ‘nonstring’ attribute (65 chars into 64 available) [-Werror=unterminated-string-initialization]
    3 | char ais_charset[64] = "@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_ !\"#$%&'()*+,-./0123456789:;<=>?";
      |                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  SoapySDR support: yes
cc1: all warnings being treated as errors

any reason not to use the same start script as debian? https://github.com/flightaware/dump1090/blob/master/debian/start-dump1090-fa I think it doesn't pick up my location because of it (we don't source /var/cache/piaware/location.env)

after latest git dev merge seems like the patch is failing -

==> Starting prepare()...
patching file adaptive.c
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file adaptive.c.rej
patching file net_io.c
Reversed (or previously applied) patch detected!  Assume -R? [n] y
==> ERROR: A failure occurred in prepare()

The patch is no longer needed

It looks like they are using a starting script for the dump1090.service to handle the options. Right now it is hard coded in the ExecStart so creating the file alone would have no effect. We can do what dump978-fa-git does and put the current options in ExecStart to the default file. This should have minimal impact.

I'll take a look at adding soapy and the default dump0190 config. I'm not sure how disruptive changing the defaults can be. I'm not inclined to make lighttpd optional since that is also the default for piaware https://github.com/flightaware/dump1090/blob/master/debian/control#L20

Please also include the default configuration since piaware-config is not going to create it.

soapysdr can be added to the dependency to enable other sdr backends.