on skyaware 3.8.1 the range rings go back to default when i reset the map…is this correct? (ie. there are 3 rings, if i add a 4th ring and “set” all is good until i reset)
I have 2 setups, one is Piaware SD card, the other is Piaware Debian add-on.
Edit: Yes, I see that now when resetting the map.
I had to build it for the build to be happy on my RockPi4.
@mikkyo Thank you. That solved it. Had to install a few missing dependencies to get it to build, but runs like a charm. I used the following code:
cd git clone http://github.com/flightaware/tcltls-rebuild.git cd tcltls-rebuild/ ./prepare-build.sh stretch cd package-stretch/ sudo dpkg-buildpackage -b cd .. sudo dpkg -i tcl-tls_1.7.16-1+fa1~bpo9+2_arm64.deb
Actually, most previous versions require this too; it’s just that we only discovered the problem recently, and it was mitigated for most jessie/stretch installs because a suitable version of tcl-tls was already provided in the FA repository (so if you were using the prebuilt piaware packages from the FA repository, you’d get a fixed version of tcl-tls too)
The bug that this fixes is that without a fixed package, piaware can entirely hang if it loses the network connection to the FA servers in some cases.
The piaware_builder README.md for 3.8.1 talks about the tcl-tls requirement, FWIW.
Building from the tcltls-rebuild git repo is the right thing to do to fix it.
Piaware 3.8.1 on UBUNTU 18.04.4 amd64
./sensible-build.sh: line 139: dch: command not found
Should this warning be ignored?
$ lsb_release -sc bionic $ sudo apt update $ sudo apt install git dh-systemd $ cd ~/ $ git clone http://github.com/flightaware/piaware_builder $ cd piaware_builder $ sudo ./sensible-build.sh bionic .... .... .... .... .... .... db4c8c9 (HEAD, tag: v3.8.1, origin/staging, origin/master, origin/HEAD, master) Release 3.8.1 Retrieving cxfreeze 2020-03-27 09:13:50 URL:https://codeload.github.com/anthony-tuininga/cx_Freeze/tar.gz/6.0  -> "-"  Updating changelog for bionic build ./sensible-build.sh: line 139: dch: command not found
## File sensible-build.sh: 139 dch --changelog $OUTDIR/debian/changelog --local "$extraversion" --distribution "$targetdist" --force-distribution "Automated backport build via piaware_builder"
You need to install the
Thanks for guidance.
As I did not know this solution, I did not install
devscripts, ignored the warning, and proceeded with building/installing piaware. Apparently piaware is working OK. Is this acceptable or missing
devscript will affect performance of piaware in some way?
Well, you’ll have the wrong version number. It doesn’t really matter. I should probbaly make sensible-build.sh halt on error though.
I got correct version number even without
abcd@ubuntu-18:~$ ls Desktop examples.desktop Documents Music Downloads piaware_builder dump1090_3.8.1_all.deb Pictures dump1090-fa Public dump1090-fa_3.8.1_amd64.buildinfo tcltls-rebuild dump1090-fa_3.8.1_amd64.changes Templates dump1090-fa_3.8.1_amd64.deb Videos dump1090-fa-dbgsym_3.8.1_amd64.ddeb
abcd@ubuntu-18:~$ cd piaware_builder abcd@ubuntu-18:~/piaware_builder$ ls buster package-bionic README.md changelog piaware_3.8.1_amd64.buildinfo sensible-build.sh common piaware_3.8.1_amd64.changes stretch Jenkinsfile piaware_3.8.1_amd64.deb jessie piaware-dbgsym_3.8.1_amd64.ddeb
No you didn’t - a bionic build would usually be
3.8.1~ubuntu1804+1. The version number is modified by the
Thanks, I will now install
devscripts and rebuild the package.
devscripts and rebuild the package.
Now I have 2 sets of packages, the old one without
~ubuntu1804+1 and new one with
abcd@ubuntu-18:~/piaware_builder$ ls buster piaware_3.8.1~ubuntu1804+1_amd64.buildinfo changelog piaware_3.8.1~ubuntu1804+1_amd64.changes common piaware_3.8.1~ubuntu1804+1_amd64.deb Jenkinsfile piaware-dbgsym_3.8.1_amd64.ddeb jessie piaware-dbgsym_3.8.1~ubuntu1804+1_amd64.ddeb package-bionic README.md piaware_3.8.1_amd64.buildinfo sensible-build.sh piaware_3.8.1_amd64.changes stretch piaware_3.8.1_amd64.deb
Not sure if i am the only one but feeding to FR24 stopped on both of my devices with the upgrade to 3.8.1
a simple restart of the script helped, but i was surprised about it.
On my device, the :8754 local page is not working, but it’s feeding still the FR24 webpage. Restart doesn’t help.
However, this might not be appropriate discussion here.
~$ sudo systemctl status fr24feed
● fr24feed.service - Flightradar24 Decoder & Feeder
Loaded: loaded (/etc/systemd/system/fr24feed.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2020-03-28 09:02:39 EDT; 1min 33s ago
Process: 17516 ExecStartPre=/usr/lib/fr24/install_dump1090.sh (code=exited, status=0/SUCCESS)
Process: 17536 ExecStartPre=/usr/lib/fr24/unregister_kernel_modules.sh (code=exited, status=0/SUCCESS)
Process: 17541 ExecStartPre=/usr/lib/fr24/create_missing_directories.sh (code=exited, status=0/SUCCESS)
Main PID: 17544 (fr24feed)
Tasks: 16 (limit: 4512)
Mar 28 09:02:39 Ubuntu-Latitude-E6420 systemd: Starting Flightradar24 Decoder & Feeder…
Mar 28 09:02:39 Ubuntu-Latitude-E6420 systemd: Started Flightradar24 Decoder & Feeder.
yes, i had the same. local site not available, but also no data upload. After a systemctl restart everything is back working.