Announcing PiAware 3.8.1!

No it means reinserting the sd-card fixed the problem :wink:

I’d suspect it’s a very strange error.

Hi @esmathews, given that you have piaware-repository_3.8.0_all.deb available, is this page mandating Stretch and showing only 3.8.0~bpo9+1 for a reason – or has it simply yet to be updated with the newer release?

Thanks,
Chris

I reinstalled my Pi3 the day before and i followed the official instructions.
I still have bpo9+1 installed now, so i assume the package hasn’t been updated to final so far.

It’s just not updated yet. The change to update it is actually on staging now, so it should go to production in Monday’s web release.

Many thanks Oliver. The reason I asked is I wrote up a tutorial on deploying VRS to a headless VPS and consolidating a number of remote PiAware feeders onto a single map via socat, purely for the purpose of friends viewing their combined efforts (NOT for the purposes of re-feeding anything).

It’s working great but, much as I like VRS, I do like the SkyAware map for its simplicity and miss it in this application. I fancy trying the same thing again but using a PiAware package installation on Buster and something like @wiedehopf’s Combine1090 project on the VPS, with socat pushing data from remote PiAware feeders to it. Again, purely for friends looking at the combined feeders on the map, NOT for re-feeding. A sort of de-clawed version of PiAware for viewing only, which I think is what Combine1090 does.

Once the Buster package is live I’ll give it a go.

Thanks.

I was running some minutes ago apt-get update and received this:

Target Packages (piaware/binary-armhf/Packages) is configured multiple times in /etc/apt/sources.list.d/piaware-buster.list:1 and /etc/apt/sources.list.d/piaware.list:1

Anything i need to do or is it part of the current work of updating the package in the sources?

EDIT: Message appears only on my RPI4, not on my RPI3. For this no updates are announced while executing the command.

What image are you using and what is the history of this install?

i do not use an image but the piaware and dump1090 installed per script on Raspbian Buster.

So i do not know what you mean wiht ā€œhistoryā€ of this install.
The system was set up mid of december with Piaware 3.7.2, later updated beginning of January, but wth the backport version.

Not sure, but I got the same messages a while after I manually had changed from the backported version on a buster add on to the newer one, with the commands @obj posted here somewhere.

What script?

Basically what you already described - how it was initially installed and what changes you made. The only detail missing is what that script was.

The warning is harmless, but it means that at some point you ran a remote upgrade command via piaware, which created piaware.list because there was no existing repository config. Later, you installed the piaware-repository package which installed piaware-buster.list. This should never happen if you either use the package install instructions (which install the repository package first) or use the sdcard image (which includes the repository package).

So I suspect whatever script you ran is doing something differently and it shouldn’t do that.

Anyway, the fix is to just delete the piaware.list file.

You don’t have a versionless piaware repository URL, which is unfortunate.

I suppose installing an old piaware repository debian package (3.7.2), then installing a new one might produce this?

Hmm nevermind, they would still be named:

piaware-stretch-testing.list
piaware-stretch.list

Sure we do. It’s the distribution name (not part of the configured URL) that varies. I don’t know how to avoid needing different versions of sources.list for different distributions given the way that the sources.list format works (and that we need to provide different packages for different distributions)

No i mean this:
http://flightaware.com/adsb/piaware/files/packages/pool/piaware/p/piaware-support/piaware-repository_3.8.0_all.deb

But it’s probably not an issue using the old version most of the time.

The only way I could see of providing a single repository package is if the package generated a sources.list at install time, rather than shipping one as a conffile directly, which seems… kinda horrible.

(it’s not completely crazy, and it would give us some interesting options like refusing to install the repository configuration on non-Raspbian / non-arm installs which we don’t build packages for, but this is a fairly critical bit so I’m reluctant to make a ton of changes here)

Well, a URL redirect would work, much like the install page directs users to the current version.
But it doesn’t matter, i usually think of changing the URL at some point.

I suppose i could check for the debian version, and use a different repository package depending on that.

How does that URL redirect tell what distribution the retrieved package is going to be installed on?

Edit: ohhh. You mean the ā€œ3.7.2ā€ vs ā€œ3.8.0ā€ part? I thought you were talking about the ~bpo suffixes used for different distributions. Yes, providing a redirect to the latest version of the package for a given distribution would be possible. https://(whatever)/piaware/buster/piaware-repository-latest.deb (which returns a 301 to the full URL) or something like that.

Setting up piaware-repository (3.7.2) ...
root@pi ~ # ls /etc/apt/sources.list.d              
piaware-stretch.list 

I assume fox was talking about my script as there aren’t too many around.

I was still using the 3.7.2 package in the script.

Anyhow i should probably add something for stretch …

This should do for now:

  2 if grep -qs stretch /etc/os-release
  3 then
  4     repository="http://flightaware.com/adsb/piaware/files/packages/pool/piaware/p/piaware-support/piaware-repository_3.8.0_all.deb"
  5 elif grep -qs buster /etc/os-release
  6     repository="http://flightaware.com/adsb/piaware/files/packages/pool/piaware/p/piaware-support/piaware-repository_3.8.0~bpo9+1_a    ll.deb"                                                                                                                            
  7 else
  8     echo "Only Raspbian Stretch and Buster are supported by this script, exiting!"
  9     exit 1
 10 fi

Anyhow if someone installed the repo on buster before 3.8 came out, he would have the piaware-stretch.list, no matter how he installed it.

I created an issue to look at creating that redirect, will let you know when something is there.

The redirect isn’t critical, so far the old repository packages were still reachable and continued working.

See the above for using the correct package for stretch/buster.

Scripts like this should probably be avoided, but i’m tired of explaining people how to fix their FR24 configuration, which is the main reason i created this script.
It just changes FR24 to use the 30005 port and dump1090-fa provides that …

It also fixes a readonly mount of / due to some failed FR24 scripting (which is fixed now).

Also deletes conflicting lighttpd configuration files and creates symlinks for the dump1090-fa conf files, one of the most annoying problems when multiple versions of dump1090 were installed at some point.

It’d also help with a related issue which is that it’s hard to install just the piaware package without installing the repository package to discover it first; it’d be a little nicer if there was a simple stable URL that would get you just the piaware .deb, since not everyone necessarily wants to install the repository config too.

Is there something that dump1090-fa can do here to avoid this? (Not sure exactly what the problem is from your description)

It could be worse… https://www.eveonline.com/article/about-the-boot.ini-issue