Note that you have to follow the satnogs-client-ansible master branch (instead of stable, which is the default) to get the update to satnogs-client version 0.9.1 (SATNOGS_SETUP_ANSIBLE_BRANCH=master).
Thanks for noting this… I’ll take a look, I probably need to update the stable branch too. I’ll let you know what’s going on asap. Until then I suggest you don’t change SATNOGS_SETUP_ANSIBLE_BRANCH variable.
Master and stable branches are synced. So now update it should work by following the instructions in the first post, without any need for changing SATNOGS_SETUP_ANSIBLE_BRANCH variable.
No, updating to buster is not required. By following the instructions in the wiki page you will stay on the same debian version that you are now, (stretch or buster) and you will have the new version of client.
The suggestion not to update on buster from stretch is still valid as we haven’t found yet a path for updating from stretch to buster safely.
Alternatively someone could re-flash the sd-card with the latest image, this is for now the best way to move to buster version. @Acinonyx let me know if I got something wrong with this.
How come that every time satnogs-client is updated it wipes the configuration in /etc/default/satnogs-client? The updater just leaves an empty file there.
Luckily I have been there before so it was easily remedied, but a newcomer might tear her hair out over it.
Bent
It is unedited so it shows all my typos too
It is not exactly the same as is written in the wiki, but hopefully is close enough. The apt dist-upgrade didn’t upgrade anything.
As you can see from my post above I do run ‘satnogs-setup’. I downloaded the updates and applied the updates.
If that’s not what you mean by ‘update stuff that exists in satnogs-setup’ I might have misunderstood you question so perhaps you could clarify.
I saw all the extra stuff at the bottom and didn’t realize you actually updated with ansible. I though you were somehow manually updating stuff. Also I haven’t experienced my config ever resetting on either my Pi 3 system or my x86-64 system.
It has happened every time I update stanogs-client.
I just got a thought: Perhaps it is because I do not use the configuration options present in satnogs-setup but rather just copy a saved copy of the configuration from /root to /etc/default/ . Could that upset the next update?
It’s probably not possible any more to reconstruct the steps I took when I updated. Next time I update - which appears to be not too far away, conf. the announcement of version 1.0 - I’ll be very careful with the steps I take and report back here.
Hi there,
I’m new to this, and have the v0.9.1 client installed. This version doesn’t seem to heed my “False” setting for enabling rotctld, giving “Cannot connect to socket 127.0.0.1:4533” errors. When I tried to use satnogs-client to update to version 1.0, however, I ran into problems with pip not being happy with python 2.7. My RPi with Stretch currently has both python 2.7.13 and 3.5.3 installed. Is it reasonable for me to assume that eventually v1.0 of the client will automatically and gracefully handle this and then become the default when I use satnogs-client? Also, is there an easy way to learn of updates, i.e., when they are stable and ready for general use?
Thanks for any comments,
Andreas
About the error you get check the troubleshooting page in the wiki. You can ignore this error as you are in a non-rotator setup.
Did you follow the instructions on this thread to update to v1.0? What errors did you get for python 2.7? Was it the one about python 2.7 being deprecated at the end of the year? If this was the case don’t worry as soon all of our software will move to use python 3.
Still we need to make changes for v1.0 being the default version, there will be an announcement about it.
Currently we announce new versions here in the forum, however as v1.0 will be a major release we may send an email to all station owners for letting them know about this new release.