Re: Request to Update Gpredict Repository
Hi Christoph,
Thanks for you reply. I am an engineer at LASP mentoring Sean on his
work on gpredict.
> can you try to get upstream to release a new version? We aren't
> actually on "2.3.72", we are 72 git commits ahead of the 2.3 release.
> We should get back to proper tarball builds, but the last tagged
> release on github.com is from January 2018.
I would really like if the upstream developers would make a new
release. However, the project seems to have been fairly inactive over
the past year or so. Another user already opened an issue (#282)
on Jan. 22 of this year requesting a new release:
https://github.com/csete/gpredict/issues/282
Unfortunately, this has received no comments from the developers. (Or
anyone else for that matter--i.e., fellow community developers.)
I myself opened two minor issue reports, #273 and #275, with
corresponding pull requests #272 and #274 (respectively):
Add internationalization to gtk-freq-knob decimal separator
https://github.com/csete/gpredict/pull/272
https://github.com/csete/gpredict/issues/273
Allow configuring default frequencies per radio
https://github.com/csete/gpredict/pull/274
https://github.com/csete/gpredict/issues/275
Unfortunately, #274/#275 hasn't received any comments, though #272/#273
has, perhaps because #274/275 is a larger set of changes, and perhaps
the developers just aren't interested. These were submitted around
November of last year.
Since then, the main changes that we're working on implementing
include:
1. Adding user preferences to allow selecting a satellite in the
radio and rig editor windows, such that the radio and rig
controllers will initialize with a radio/rig already selected.
2. Adding user preferences to allow starting the radio/rig control
windows automatically at program start, and moreover causing these
to connect to the radios/rigs automatically at program start, to
make gpredict amenable to automated use.
This is an attempt to replace the effort of #272/#273 with a more
flexible set of preferences (i.e., instead of hard-coding desired
frequencies, the frequencies would be set according to a chosen
satellite).
These are mostly implemented already (save for changes that might be
requested by the upstream developers), and for curious users, you can
find our changes on our fork of the upstream repository on the
'expanded-config-options' branch:
https://github.com/lasp/gpredict/tree/expanded-config-options
I had sent Alexandru Csete (the lead developer and repository owner) a
message by way of the Libre Space forums a few months back expressing
our interest in working with him (and any other gpredict developers) to
make improvements to the project, but I haven't heard back. I assume he
is just very busy. I did see that he much more recently merged a few
pull requests (5 days ago).
I say all of this just to say that I am not sure if perhaps our
contributions are considered undesirable changes to the program, or if
the developers are just too busy to respond. So, I am wondering if we
may need to make a PPA to release our fork until such time that some or
all of our changes might get merged.
Since it's been a little while, we could try to re-initiate contact
with the gpredict developers and perhaps we'd have better luck this
time around.
Pino--regarding your request:
> Please introduce multi-thread... Gpredict becomes frozen when
> connected to other programs if something goes wrong in the protocol.
> (e.g. when enabled to control antennas)
Multi-threading was introduced for rotator control in commit 089922EF,
authored by Alexandru Csete (the gpredict maintainer, username csete),
and committed on Dec. 8, 2017:
https://github.com/csete/gpredict/commit/089922efa7de9f14676240e122f1a5989fcb0599
This fixes issue #46: https://github.com/csete/gpredict/issues/46
Multi-threading for radio control was introduced in commit 677EBD88,
authored
by Patrick Dohmen, DL4PD, and committed on Dec. 9, 2017:
https://github.com/csete/gpredict/commit/677ebd8826bce75cb5be94679f3c447d4ad2ce00
This fixes issue #45: https://github.com/csete/gpredict/issues/45
If you take a look in the history, both of these commits come before
tag 2.0. If you are still on Debian Stretch (released 2017-06-17 and
EOL'd as of 2022-06-30),
If you are on "oldstable" (Debian Buster, released 2019-07-06), you
should have gpredict version 2.3-33-gca42d22-1. If you are on (the
current) "stable" (Debian Bullseye, released 2021-08-14), you should
have gpredict version 2.3-72-gc596101-3.
Both of these versions are newer than these commits, so unless you are
on Stretch, both radio and rotator control should be running in a
separate thread. What version of Debian and gpredict do you have?
Thanks,
Nick
--
Nicholas DeCicco
Professional Research Assistant
Laboratory for Atmospheric & Space Physics
1234 Innovation Drive
Boulder, CO 80303
Phone: 1-303-735-8214
Reply to: