On 12/11/2014 20:14, KI7MT wrote: Hi Greg, > >From what I can gather, it's been just over two years since a formal > update was publisged. Bill probably has a much better intel on this than > I do, as he works with Nate on various elements. From where I sit, > there's 3 rational options and one not so popular idea. I'm not aware of any committed schedule over and above that promise. I do know that Nate is working on some fairly large enhancements that he would wish to be in v3. > > - The ideal situation, not just for the WSJT group, would be to get some > level of update published from the Hamlib team, but I have no idea how > far out that is. Something is better than nothing at this point. We must be careful not to overcommit on something that only gives us Linux distribution compatibility. It is an excellent goal but given the smallish community of mainly technical people, not having inclusion in the official repos is not a major show stopper. If it were an easy problem to solve I would love to see WSJT-X v1.4 available via apt-get or yum but if trying to get there does no more than teach us a lot about what is required then at least we bet some value from the process. > > - Publish a shared-dev version to link against, one that can die off ( > become deprecated ) as the formal Hamlib is released, a transitional > package of sorts. This done in allot of cases, py2 to py3 for example. Are you offering to support such a published package because someone will have to do that? > > - Publish a fork, be it static or shared. Or, maybe just include the > Hamlib source code along WSJT-X Source code and be done with it. Then > build both elements separately. As far as the RPM guardians are concerned I don't believe this option is any different from your first suggestion. > > - Last and I'm sure not very popular, de-leverage the WJSTX application > from Hamlib. Well I won't disagree that hamlib has its faults but, from a position of considerable knowledge and research, there is nothing better out there, not even close. If you are willing to develop a substitute that covers at least all the current hardware that hamlib does and at least APIs that we require then go for it, but it will need a community and support team in place and will need to be proven in battle before we adopt it. This is no small undertaking and IMHO a dilution of effort from the mainstream goals of Joe's DSP algorithms and QSO procedures.
At the root of many of the hamlib issues is that the flow of new equipment from the rig manufacturers is much too fast for the release cycle of Linux distributions for a small part time team and any replacement will almost certain suffer many of the same problems unless it uses some sort of domain specific language to define CAT interfaces such that they can be either user defined or at least downloaded from some common repository. Unfortunately the rather poor implementations of CAT by the rig manufacturers over the years make developing such a language very difficult indeed and the framework to support such a language itself will not be trivial either. Such an effort is roughly equivalent to developing a new programming language and a mini operating system to run the programs on. This is not the bread and butter of the average amateur radio operator who collaborates on amateur radio software. There is also considerable tension between a solution that "emulates" a generic virtual rig providing a common subset of features and an "all singing, all dancing" interface that allows every feature of each rig to be controlled. WSJT-X needs the former but many users want full remote control of their expensive super-duper DX hunting black box. These requirements do not sit well together and divide the user base before you even start. > > Having WSJT-X tied to Hamlib this way has been frustrating for a long > time. Especially as there seems no real target date ( maybe there is, > and it's just not published or something ) or milestone for releases exists. Don't take this the wrong way, I am largely in agreement, but you are not offering solutions here just open ended proposals for alternatives. > > As it stands now, I would be included to publish pre-built packages > somewhere until this gets sorted out properly. Builds can easily be done > today with minimal time invested at each even turn. 73 Bill G4WJS. > > > On 11/12/2014 12:03 PM, Bill Somerville wrote: >> On 12/11/2014 18:41, Joe Taylor wrote: >>> Hi Bill and all, >> Hi Joe, >>> Back to more-or-less normal here, after a busy weekend in the ARRL EME >>> Contest -- a total of 215 QSOs by our multi-op crew. :-) >> That's impressive. >>> I just wanted you to know that I have now done both a "Type 1" and a >>> "Type 2" build using your Superbuild script. Both worked without >>> problems. >> Unfortunately the concept has hit yet another road block on the route to >> acceptance by the official Linux distributions. The bundling of a fork >> of hamlib or just the use of a fork of another project internally is not >> really acceptable so we may have to wait until the hamlib team catch up >> and get their v3 release into the distributions before we can proceed >> smoothly. This basically boils down to the need for the distribution >> maintainers to control the patching of all sources that they distribute >> from. I can sort of see their point but there has, at some point, to be >> a boundary of the domain of the application developers responsibility >> and the distribution managers. OTOH I don't think we want to be adopting >> hamlib in any way, they have a product in the field and offer support >> etc. for it and we must be careful not to step in inadvertently and find >> ourselves inflating the WSJT-X sources with the hamlib sources and the >> consequential support requirements. >> >> We might be able to progress a little further if I generate a giant >> patch of the differences between the current released hamlib2 and what >> we are using. This may be more acceptable and the superbuild script can >> be fairly easily adapted to use such a patch as it already has patching >> capabilities. I will try an progress this soon after kvasd matters are >> resolved. Update on that to follow. >>> The man pages for wsjtx, jt65code, and rigctld-wajtx also look very >>> nice. Many thanks for setting these up! >> These are a requirement of Linux packaging for the official >> distributions. Every executable must have a manpage. >>> -- Joe, K1JT >> 73 >> Bill >> G4WJS. >> >> ------------------------------------------------------------------------------ >> Comprehensive Server Monitoring with Site24x7. >> Monitor 10 servers for $9/Month. >> Get alerted through email, SMS, voice calls or mobile push notifications. >> Take corrective actions from your mobile device. >> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk >> _______________________________________________ >> wsjt-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel >> > ------------------------------------------------------------------------------ > Comprehensive Server Monitoring with Site24x7. > Monitor 10 servers for $9/Month. > Get alerted through email, SMS, voice calls or mobile push notifications. > Take corrective actions from your mobile device. > http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk > _______________________________________________ > wsjt-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wsjt-devel ------------------------------------------------------------------------------ Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
