Source packages?

FlightAware ADS-B Flight Tracking
1

I tried getting the source to the piaware package collection, but piaware-buster.list does not include a source URI and the distro directory does not allow directory listing. I tried adding “deb-src” to piaware-buster.list using the same URI as for the binaries, but there was no source/Sources where apt expected to find it. In short, I can’t find any way to get the source of the binary debs.

Now, I know I can find source code on github, but that’s a moving target. What I am after is the exact source of the current binaries including (indeed primarily) the .dsc files, so that I can build functionally identical x86(_64) rpms.

Would you please consider putting the deb sources in the repo and adding +Indexes/autoindex/ dir-listing.activate to it?

2

We’re not currently set up to produce source packages (the package build process is not exactly the “debian way” of an upstream tarball + changes etc) but the github repos are tagged (and the tagged piaware_builder in particular itself uses those tags when cloning the sub-repos) if you want to grab the exact source corresponding to a release.

e.g. Release v4.0 · flightaware/dump1090 · GitHub

3 Likes
3

Please have a look here. It does not build .rpm package, but does build Linux binaries for Fedora & Red Hat.

Howto Install dump1090-fa on FEDORA and RHEL x86_64

4

It does the job for someone who is familiar with compiling stuff, but it cannot compare to ‘yum install adsb-metapackage’ and being up and running in zero time.

I had several things somewhat nebulously in my mind when I asked about the deb-src. One is that I have an always-on SL7 workstation which, at least in theory, I could have used for the tracking. Another is more general: ready binaries for existing hardware tend to have a greater uptake than either source code or ready binaries for special hardware. I mean, let’s face it, the Raspberry is not exactly everyman’s old computer and ARM has a very limited uptake outside mobile phones and industrial computing. If the FA stuff was, say, included in the standard debian/ubuntu or fedora distributions, you would have many more people testing it on their existing hardware just for the fun of it, and some of them would get hooked and continue capturing and feeding data beyond their first test-for-fun phase. Also, a quick look at the coverage map says that where more coverage is most needed, is also where even a Raspberry can be prohibitively expensive[1]. And then, apart from all this, i absolutely detest putting stuff on my computers with make, make install.

So I set out to make some rpms and started from bottom up with the dependencies. I found rtl-sdr and bladeRF on SuSE; with minor adjustments they also build on recent redhat systems. hackrf and limesuite are already in fedora. I added ‘Provides: SDradio’ to them, to allow dump1090 to use any of them and made some other minor changes. With those and their dependencies done, I took a go at dump1090-fa. So far so well, and then I’ll get started on piaware packages. However, building this stuff on el7 is hell on earth, so even though el7 is what started me on this, I might not have the patience to actually produce binary rpms for el7.

SRPMS: SoapySDR, tecla, rtl-sdr, bladeRF, limesuite, dump1090-fa.
RPMS: here.

I would greatly appreciate testing and comments.

[1] Translations to Chinese, Russian, Spanish, Portuguese and French could also do wonders for uptake.

1 Like
5

I’m not familiar with the details of how RPM dependencies work, but if it’s like Debian and any one package satisfies the dependency, then that’s probably not what you want. dump1090 doesn’t have a runtime-module-loading system and is directly linked against the SDR libraries. So if you build and package dump1090 with, say, bladeRF support, then the bladeRF library must be present at runtime even if you don’t select the bladeRF on the command line.

While this is true, the support effort needed to support arbitrary PC-style hardware is huge and the payoff is not great (PCs are rarely going to be dedicated 24/7 feeders and that’s really what we need). The Pi is a nice target because it’s cheap, can be dedicated to running one thing 24/7, and has very predictable hardware. (For similar reasons, while we build ARM packages, we don’t explicitly support all the other similar ARM SBCs out there - there’s too much hardware variation to support)

2 Likes
6

Yes, exactly. The src.rpm accepts any of four --without rtl-sdr, bladerf, hackrf and limesuite. If you don’t specify anything, it will build with all of those that happen to be present on the build system, but because of a ‘Buildrequires: SDradio-devel’ it will refuse to even start building without any of them. The resulting binary rpm cannot be installed unless all of the compiled-in SRD libraries are present on the install system (and yum/dnf will pull them in automatically). If the dependencies are satisfied and dump1090 is installed, yum/dnf will subsequently refuse to uninstall the dependencies unless dump1090 is also uninstalled. At least in theory, because I haven’t tested it yet at all.

More recent versions of rpm allow ‘Requires: (thispkg <= 1.23 or thatpkg = 4.5)’. Using this would eliminate the need of an abstract SDradio provider, hence also the need to mess with packages that are already in fedora. I should try it.

My thinking is that playing around with something sometimes gets you hooked. Same principle that is behind free samples of cheese and shampoo and stuff. The only thing that should stand in the way of using any random hardware is a free flightfeeder, but you still need to be interested before you request one.

I would have imagined that the only hardware that FA needs to support is the radio, while everything else is abstracted by the kernel. It’s not that you need to deal directly with I/O, sound, video, or even input. Even the CPU idiosyncracies ought to be taken care of by the compiler as long as the source language is supported by it. Where am I wrong in this?

Anyway, it’s open source. If it doesn’t work on something, sooner or later somebody will come along with the right knowledge and provide a fix for it. In this sense I would reason that, as long as there is one tested and working platform, it is better to allow a broader choice even if it breaks on some hardware, than to stick to the one tested platform and discourage everything else.

7

There’s a bunch of potentially useful stuff in dump1090-fa/tools, but it does not get packaged in the distribution deb. Is that on purpose or an accidental omission?

8

At one time, the company I worked for had a software modeling/simulation system and the requirement was for this to work on Windows NT, Sun Unix, SGI Unix, and RedHat Linux. The code was UGLY with all the conditionals supporting or blocking the different operating systems, and hardware configurations. Can it be done? Perhaps. Is it worthwhile to expend the resources just to tease a few more people to try a code in their unique configuration? Highly Unlikely.

Obj with FlightAware may not politically be able to say this, but like any hobby, sometimes you need to constrain what you try to do and keep your code clean, clear and understandable. These codes are built primarily open source, using code from earlier developers going back many years. We stand on their shoulders as we build new capability and features. Others will stand on ours when they see something new we did not.

Cluttering up good working code to try to shoehorn it into different operating systems creates unmanageable code and I personally appreciate the developers associated with Piaware, Dump1090 and all the other flavors of ADSB (Kudos to prog with Airspy_adsb for example) and what they do every day to improve the reliability of these codes. Operating system flexibility comes at a huge cost in reliability. If it is flaky to operate, then people will abandon a project. Keeping the reliability high means clean clear code. I appreciate how reliable these systems keep running with little maintenance day to day. Truly amazing code. Just my 2 cents worth.

1 Like
9

That’s mostly tools that are potentially useful to a developer, but not really useful to the wider userbase. The assumption is that if you need those tools you’ll probably be working out of a git repo anyway…

10

That is certainly one use case, but you seem to be ignoring the fact that at the end of the day, FlightAware exists to market (sell) reliable data to its customers. They created their software to that end. to them, it’s not a hobby that they are putting together in their garage, it’s a business. Expending effort that doesn’t have a measurable return probably isn’t high on the priority list.

But, it’s open source. If someone wants to do the work for them, and they see a realization of the benefit, they may well integrate that work into a future release. The release notes for version 4.0 are testament to that.

11

You are absolutely right on all counts, except that I did not ask FA to expend any effort. I did not ask FA for rpms, nor for x86 binaries, nor for any other coding or support effort. I did and do that all by myself, just because (I think) I can and it pleases me to. Whether FA then adopts my rpms with joy or ignores them with disdain, is completely up to FA. All I’m doing here on this discussion board is discuss. Nothing else. Anyone who might have read any explicit or implicit demand on or expectation from FA in my postings, please stand corrected.

Exactly. That’s precisely my point too.

12

Just to set the record straight: I am not a developer. I can script bash and perl and even some python with a lot of googling, and I can read C as a five-year old can read Shakespere, but I have definitely no insight in the coding requirements that support for different OSes might pose.

With that said, and based on my very limited understanding, I wrote that “I would have imagined that the only hardware that FA needs to support is the radio, while everything else is abstracted by the kernel” and that “CPU idiosyncracies ought to be taken care of by the compiler”. If I’m out of touch with reality on this in principle, please short-circuit me.

On the other hand I am very much aware of “version tension” between different systems. You want to use libxyz-1.2.3 because is provides some very nifty shortcuts for your code, but it is only available in OS/1 and not in OS/2 or OS/3. That is where I suspect that the ugly conditionals come from: a desire to advance the code where it is possible, while still maintaining it functional where advancement is not possible.

If - and only if - I am correct in that, it seems to me that the appropriate course of action is maintaining only one code base, but different versions for different OSes. As in “code-2.0.1 has been released for RedHat Linux, while code-1.8.53 remains the latest version for Sun Unix and SGI Unix”. In other words you start with something very generic, then you incorporate whatever new stuff you want to in later versions, and you just let the OSes choose whether and when they want to enable your newer versions, or stay with your older ones.

13

Upfront, I do not write code for Flightaware, though from what I have watched and used, it is reliable, simple to install on known systems. Perhaps we can disagree. When code bases split to support different OS systems and use different versions, the code becomes unmanageable and unreliable.

Trying to support just the radio portion is only part of what these codes do. Code systems read inputs, translate/manipulate/convert data, process data, manage data, and output data. Lots more than just connect to the radio. Our little radios and computers are only one nitch of what happens.

The big job is in the servers staying up, injesting and processing thousands of packets each second, verifying the data is usable, and then incorporating it into their system. That is a much bigger job than Piaware/Dump1090 stuff. Kudos to those who work the code, manage the servers and databases. The devil is in the details, and lots of details in ADSB data and codes.

If this is important to you, you go for it. I sincerely hope you can get the results you desire. Best Wishes

1 Like
14

@zenonp - let it rip brother! Anyone who who is willing to spend the time to make this gig work cleanly on another set of tools should be applauded.

It’s obvious you care about the project. I can’t find a decent argument against it in all honesty. Your time spent should be greatly appreciated.

1 Like
15

I’m still working on this; I now also have mlat-client and dump978 ready and still need to do tcllauncher and piaware. But I just found out that I am not the first one to embark on this project. GWDG has been distributing piaware rpms for openSuSE since 2017, with the latest build today, just a few hours ago.

1 Like
16

This is very good news.

I did not attempt to make rpm packages, but did try to build the Linux Binary on Red Hat and Fedora. I succeeded to make & run Linux Binary for dump1090-fa. Also built piaware Linux Binary. However got stuck when tried to run piaware binary. Reason given in this post:

17

Heh, haste. It happens occasionally to all of us. piaware requires tls, but that has nothing to do with tcl; the two just look similar to the eye.

The piaware feed applications (faup* etc) make encrypted connections to the FA servers. That’s what they need tls for, and it has to be present at build time. On redhattish systems it would probably be provided by openssl-devel and/or gnutls-devel.

Edit: I just read your original post. The error is here:

Checked openssl , found it is already installed:
[abcd@localhost ~]$ sudo dnf install openssl

You needed openssl-devel.

1 Like
18

Oops!

Great! Thanks for the tips. Coming weekend I will try again.

19

I agree. To this end, I am thinking of a different path, a virtual appliance by way of virtualbox (or any popular hypervisor du jour) [[<-- debian (or any popular Linux distro) ← qemu ← piaware img (or Raspbian + FA packages)]]. This will allow anyone with x86 to experiment. As you are already considering the Debian community, QEMU should suffice to bring the experience to all Linux community.

20

Well if you’re competent to run a Debian VM then just compiling from source shouldn’t be hard, there are enough guides on the forum (and even without that it’s not that complicated to figure out).

Docker is all the rage, don’t you know? :slight_smile:
No, but seriously this is some nice stuff:
Guide to ADS B Data Receiving, Decoding and Sharing, Leveraging RTLSDR and Docker · mikenye/docker-readsb Wiki · GitHub