[chirp_users] CHIRP on OpenBSD
Hello.
I have noticed that the OpenBSD port for CHIRP is still for version 0.4.1 which was seemingly posted on 8 October 2014. This version uses an older URL of chirp.danplanet.com/download/.
I have created a patch for which points it to trac.chirp.danplanet.com/chirp_daily/LATEST/ and uses chirp-daily-20160505.
Will development of CHIRP remain on chirp_daily, and no longer use build versions like 0.4.1?
Can the daily builds be considered stable? If not, how can I predict the path of stable builds?
Thanks for a great tool. This latest build works with my hardware perfectly.
As a side note, someone else has already added patches to the OpenBSD ports tree for these devices (I am sure the following will syntactically be mangled by gmail):
--- chirp/platform.py.orig Tue Apr 9 01:01:35 2013 +++ chirp/platform.py Thu Jun 12 14:14:18 2014 @@ -283,7 +283,9 @@ class UnixPlatform(Platform): os.system("firefox '%s'" % path)
def list_serial_ports(self): - ports = ["/dev/ttyS*", + ports = ["/dev/cuaU*", + "/dev/cua0*", + "/dev/ttyS*", "/dev/ttyUSB*", "/dev/ttyAMA*", "/dev/cu.*",
On Thu, May 5, 2016 at 10:51 PM, Ted Roby ted.roby@gmail.com wrote:
Hello.
I have noticed that the OpenBSD port for CHIRP is still for version 0.4.1 which was seemingly posted on 8 October 2014. This version uses an older URL of chirp.danplanet.com/download/.
I have created a patch for which points it to trac.chirp.danplanet.com/chirp_daily/LATEST/ and uses chirp-daily-20160505.
Will development of CHIRP remain on chirp_daily, and no longer use build versions like 0.4.1?
Correct. We realized that all the numbered releases were accomplishing was delaying release of bugfixes present in the daily builds. Now the only build is the daily build.
Can the daily builds be considered stable? If not, how can I predict the path of stable builds?
Yes, the latest daily build can be considered stable.
Sometimes when creating a new radio driver we will mark it "experimental" until it has been thoroughly tested. This is presented as a warning to the user when loading data from that particular radio. Radio driver code is compartmentalized and the core Chirp code is very mature, so an experimental radio driver doesn't warrant marking an entire build as unstable.
Thanks for a great tool. This latest build works with my hardware perfectly.
As a side note, someone else has already added patches to the OpenBSD ports tree for these devices (I am sure the following will syntactically be mangled by gmail):
--- chirp/platform.py.orig Tue Apr 9 01:01:35 2013 +++ chirp/platform.py Thu Jun 12 14:14:18 2014 @@ -283,7 +283,9 @@ class UnixPlatform(Platform): os.system("firefox '%s'" % path)
def list_serial_ports(self):
ports = ["/dev/ttyS*",
ports = ["/dev/cuaU*",
"/dev/cua0*",
"/dev/ttyS*", "/dev/ttyUSB*", "/dev/ttyAMA*", "/dev/cu.*",
Thanks. I formatted this properly and submitted it to the chirp_devel list for inclusion.
Tom
participants (2)
-
Ted Roby
-
Tom Hayward