what is the fastest way to downgrade piaware and prevent future updates via apt-get?
Package pinning will prevent upgrades. See
For downgrades, there is no particularly simple mechanism; find an old .deb or build from a git tag. (But why do you want to downgrade?)
ok. have some strange behaviors with e.g. skyview - don’t know whether it’s related but began about same time when piaware upgrade was - just elimination process …
could you please elaborate this a little more in depth with a working example - as it did not work on my own and maybe others also want to try this from time to time?
Here is an example apt-preferences config that prefers the kernel package from the FA repository (used to prevent upgrades to versions that break mlat): https://github.com/flightaware/piaware-support/blob/master/etc/apt/preferences.d/50-pin-kernel.pref
You can add other criteria to the Pin: line to pick a particular version.
Downgrades are never something we’ve supported and are in fact likely to break if there was any config upgrade work done, so I am not going to go into any detail there - you really need to understand what you’re doing there so a “just do this” example is counterproductive.
thanx for feedback! yes - there was never a real downgrade path - but until some time it was easy to delete piaware install and then reinstall the older version via deb from flightaware. the ‘new’ behavior to autoinstall only the newest version is really inconvenient - would be nice to have an option to override that with a given version number e.g. piaware=3.5.1.
to give you feedback too - the new piaware obviously was not the reason for the problems i faced. it looks like it were the new html directory i used from github dump1090-fa dev branch. up to now i used html directory from master without any issues. but because i combine this with dump1090-mutability - maybe that all is without any meaning for the 3.5.3 release of dump1090-fa.
The install/upgrade behaviour has not really changed since 3.0, so whatever you did before you can still do now. There is no “new” behaviour here.
If you’re messing around with the html dirs and skyview breaks then that is certainly your fault, not the fault of the release.
What problem exactly you are facing after replacing /usr/share/dump1090-mutability/html directory by public_html of Skyview?
it showed network problems - the skyview website always was much more problematic in some network respects compared to other similar applications like virtualradarserver, modesmixer etc …
i don’t know maybe it was pre version 3.0 - but even if so the behavior back then was more comfortable for users to use a different version than it is today.
i was not ‘messing around’ i just used an uncommon and unsupported combination and clearly stated this. in my eyes it is simply not really a good idea to load on startup about 10 times as much files as virtualradarserver or others do and moreover about 120 history.json files with in total about e.g. 5 - 10 megabyte. and this is what skyview does.
Ok, so you used an uncommon and unsupported combination and it broke; you’ll need to clean that up yourself, regardless.
If you don’t like the design of dump1090 then fix it. The source code is available. I give you no guarantees about integrating your changes back into the versions that I maintain, though; you’ll need to convince me that they are worthwhile changes and from what I’ve heard so far there’s nothing compelling there.
For the history files in particular I would point you at
a) it’s been done that way since before dump1090-fa even existed; I find it strange that suddenly you find it an issue now
b) there are tradeoffs between initial browser load time and baseline load on the Pi, as dump1090 doesn’t have an internal webserver and would need to write out the entire aggregated history frequently even with no clients; the current design errs on the side of minimizing the load on the Pi without the large rewrite needed to include a robust internal webserver; if you want to address the current load behavior you’ll have to fix one or more of those issues
c) you can turn it off via #nohistory
it’s already fixed and was no big deal - i just wrote what happend - so you would not have to spend time to thinkover if there could be a problem in piaware
i like the design, code and capability of dump1090 very much and wrote this more than often! i’m not a professional coder - more a quite loyal flightaware customer who feeds acceptable good data and moreover tries to help here in the forum others and this way again flightaware. so - i’d say my free input to flightaware is quite ok. improving/debugging skyview seems to be mr. drakes paid job.
b) absolutely!!! integrating a webserver would blow up dump1090 with something that is not a core function and maintenance of this code would load much additional work on you. couldn’t something like a ‘dump1090-muta-format/protocol’ that i was asking for in another thread help here too? i mean a tcp-datastream instead of reading those single json-files …
c) cool thanx for the hint!
edit: couldn’t a tiny trigger-file that the webserver produces if there is a client and deletes if no client was seen for say 3 minutes help with the issue you mentioned in b)
I just thought I’d write because I feel like maybe you are coming off with a little harsh tone on TomMuc. He seems very understanding, and was very upfront about using an unsupportive config, is smiling, and is otherwise very pleasant. But you seem very unhappy with him and rather heavy on him.
Maybe I’m wrong here, but that’s just kind of how it feels.
And I know how incredibly helpful and supportive of the community you are, so I thought it was a little out of character. Maybe a rough day? Or getting tired of repeating yourself (pretty likely, as I know how that can be)?
He has burned many bridges in the past.
sorry but this is just your version of the story - mine is different - and one of them you know i already proved i was right but i’m simply not resentful
hmmm - does it work for you to add ‘#nohistory’ to url? when i try the site does not load a all …