Bug 1911529
Summary: | KX3 (Kenwood) cannot set split VFO | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | digger vermont <digger> |
Component: | wsjtx | Assignee: | Lucian Langa <lucilanga> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 33 | CC: | bobjensen, denis, hobbes1069, jskarvad, lucilanga, mdblack98, sindrb |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | wsjtx-2.2.2-6.fc33 wsjtx-2.2.2-6.fc32 wsjtx-2.2.2-6.el8 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2021-01-10 01:26:54 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
digger vermont
2020-12-29 21:31:23 UTC
That doesn't show split being set. Please do "S 0" and "S 1" I'm unable to reproduce this problem Did you do an "ldconfig"? Did you recompile WSJT-X after installing the new hamlib? This may be a problem with shared library compatibility...not sure... Mike W9MDB tl;dr If I rebuild wsjtx and js8call with "rpmbuild --rebuild" the locally built and installed packages run as expected. The official rpms likely need to be rebuilt with the newer version of hamlib. Otherwise: Maybe there is more than one issue for me, so for the moment forget about rigctl. With hamlib-4.0-2.fc33.x86_64 installed from updates-testing and wsjtx and js8call installed from the fedora 33 repository neither can set the KX3 to split. Here's what happens with wsjtx (js8call is almost exactly the same): 1. Install wsjtx from fedora 33 repository 2. Start wsjts in a terminal window 3. Check that rig is KX3 and settings are correct 4. click on "Tune" button What happens: 1. "Tune" and "TX" buttons flash red for a moment. 2. These lines are printed to the terminal window: 1. Sometimes nothing or most times pop up notification window with: "Rig Control Error Do you want to reconfigure the radio interface?" 2. These lines are printed to the terminal window: Hamlib: kenwood_set_split_vfo: unsupported VFO Sub Hamlib: kenwood_set_split_vfo: unsupported VFO Sub Hamlib: kenwood_set_split_vfo: unsupported VFO Sub Hamlib: kenwood_set_split_vfo: unsupported VFO Sub What I expect to happen: 1. "Tune" and "TX" buttons turn red 2. Set split mode on KX3 if not previously settings 3. Set KX3 to transmit test tone Two points: 1. If hamlib is downgraded to hamlib-4.0-0.9.fc33.20200615git779cd69287.x86_64 both wjstx and js8call work as expected and are able to set the KX3 to split mode. 2. If set up an rpmbuild environment and run "rpmbuild --rebuild wsjtx" the locally rebuilt rpm works as expected and can set the KX3 to split mode. The same is try with a locally rebuilt js8call. As far as rigctl -- I was not using it properly, however with a better understanding of it, the version in hamlib-4.0-2.fc33.x86_64 still doesn't seem to work as expected, but perhaps that is a different issue I can't quite tell from what you said if you recompiled WSJT_X with hamlib-4.0-2.fc33.x86_64 and if it works or not. Mike W9MDB Yes the packages were rebuilt with hamlib-4.0-2.fc33.x86_64. These locally rebuilt rpms work for me. Ok, I just got back from BSA winter camp so I'm wiped for today but I'll look at rebuilding dependencies soon. There were not supposed to be any API/ABI changes but apparently they snuck in. I think to prevent future problems you should build WSJT-X with the static hamlib and not rely on the shared library. WSJT-X uses structure references which are fragile and not guaranteed -- so always should be built with whatever hamlib is desired, It's not really an ABI change. But references inside rig->caps to things likerig->caps->vfo_list aren't guaranteed to remain the same. Mike W9MDB My understanding of this is rudimentary, but if that is the case then wouldn't you need to bulid all packages requiring hamlib statically? For me there is also an issue with JS8Call, and I'll bet with fldiji as well. On the otherhand the KX3, it is listed by rigctl as being beta (as are several other Elecraft rigs) and as mdblack98 wrote likely to be in flux. I created an issue for hamlib that will allow programs like WSJT-X, JSCall, JTDX, and others to avoid having to refer to data structures. You're correct that all those apps would require static linking for now but I think Redhat's policy disallows statically linked binaries. So this will be fixed over the next few months. Meanwhile will try to avoid any changes that impacts the shared library compatibility. Mike W9MDB For now it sounds like the quick fix is to rebuild wsjtx and js8call but I'll either need to wait until hamlib goes stable or setup buildroot overrides. FEDORA-2021-8f2cdbcc1d has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2021-8f2cdbcc1d FEDORA-2021-22ba74af32 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-22ba74af32 FEDORA-EPEL-2021-e28aa9eec8 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-e28aa9eec8 FEDORA-2021-8f2cdbcc1d has been pushed to the Fedora 32 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-8f2cdbcc1d` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-8f2cdbcc1d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-EPEL-2021-e28aa9eec8 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-e28aa9eec8 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2021-22ba74af32 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-22ba74af32` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-22ba74af32 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. I'll be able to try out the new rpm tomorrow morning. (In reply to Fedora Update System from comment #15) > FEDORA-2021-22ba74af32 has been pushed to the Fedora 33 testing repository. > Soon you'll be able to install the update with the following command: > `sudo dnf upgrade --enablerepo=updates-testing > --advisory=FEDORA-2021-22ba74af32` > You can provide feedback for this update here: > https://bodhi.fedoraproject.org/updates/FEDORA-2021-22ba74af32 > > See also https://fedoraproject.org/wiki/QA:Updates_Testing for more > information on how to test updates. It works for me. It's not yet available in the repo -- istalled the packeage on bodhi. Will there be an update for JS8Call as well? Yes, it's already built but the update system is having some issues right now. You can download/install directly from koji though: https://koji.fedoraproject.org/koji/buildinfo?buildID=1663750 Assuming x86_64: $ sudo dnf update https://kojipkgs.fedoraproject.org//packages/js8call/2.2.0/5.fc33/x86_64/js8call-2.2.0-5.fc33.x86_64.rpm I found when this problem was introduced. It was an addition to the hamlib_port structure which is defined very early in the rig_caps structure. So it changed the offset of all things after it. A patch has been submitted to WSJT-X to remove all such dependencies. And in 5.0 the structure will be changed to pointers so this won't happen again. Mike W9MDB FEDORA-2021-22ba74af32 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2021-8f2cdbcc1d has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-EPEL-2021-e28aa9eec8 has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report. |