Partially verified this.
I checked the "manifests" for the rpms and debs. Sure enough the
binaries are
being distributed as part of the WSJT-X binary package. They are not
listed as
dependencies.
Working trough the source code, they are not there. It would appear
that those
of us build
As Mike has already said, USB is not a valid com port. So the error
message says exactly what the problem is.
Linux should be something similar to this: /dev/ttyUSB0 or /dev/ttyUSB1.
My Icom 7100 is set to /dev/ttyUSB0 for cat control.
Windows is a completely different beast. Again, the er
Having read and seen much of the same. I agree that F/H needs some
work. Andy is spot on about the user base not reading and following
instructions. Therefore, we do need forced compliance with the message
format. Of course there will be a lot of whining about it, but the
Clipperton DXE
Is there a reason why you have the compiler set to treat warnings as
errors? There are several warnings that pop up, which is normal, but
so long as you are set to treat those warnings as errors, the compiler
will break make.
On 1/17/24 19:27, Greg Cook via wsjt-devel wrote:
Hello,
I am
Reporting a perfect build. No errors, usual amount of warnings.
Working very well.
[kb6ibb@kb6ibb-15 ~]$ cat /etc/os-release
NAME="Red Hat Enterprise Linux"
VERSION="9.3 (Plow)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="9.3"
PLATFORM_ID="platform:el9"
PRETTY_NAME="Red Hat Enterprise Linux 9.3 (P
Yes, what Hranfnkell said...
If we have been keeping up with our Linux journals and news. We would
realize that Pulse is out, pipewire is in. Announcement made over 18
months ago. Debian following the Enterprise has implemented pipewire
with that strange pulse bridge for backward compatibi
To in any way lock down the software is 100% inappropriate. It's not
just "ham radio" software as we can clearly see, but also a very
important scientific tool used world wide for various purposes. We can
not turn our backs on the scientific community over a few ham radio
contacts that might
While this always seems to be a good idea on the surface, it really ties
the hands of the software's flexibility and portability. For example, I
have run into Appimage issues with GQRX on various platforms. Usually
various library versions out of sync with the Appimage. To the point
where
Test Result and Solution to follow...
Downloaded SuSE Tumbleweed from SuSE Web Site
Standard (out of box options) Gnome Install
kb6ibb@KB6IBB-TW-Test:~> cat /etc/os-release
NAME="openSUSE Tumbleweed"
# VERSION="20230610"
ID="opensuse-tumbleweed"
ID_LIKE="opensuse suse"
VERSION
SuSE happens to be one of my areas of interest. Building on both SuSE
Linux Enterprise and Leap. Let me spin up a Tumbleweed in the VM and
see what's going on. Are you using SuSE MicroOS in your configuration?
Just to be sure, are you following the procedure as outlined in the
Install fi
You are awesome!! Thank you Richard.
On 5/23/23 11:51, Richard Shaw wrote:
On Tue, May 23, 2023 at 9:42 AM Jeff Stillinger via wsjt-devel
wrote:
Yes, I think we need a focused effort as a whole ham radio
community on
9. I love what they have done with Rocky 9 (RHEL 9) so far
Yes, I think we need a focused effort as a whole ham radio community on
9. I love what they have done with Rocky 9 (RHEL 9) so far. It was
just the "face lift" that 8 needed. However, 9 is falling short on
some key libraries. Hamlib was there, but GNURadio isn't. Of course,
WSJT-X had
Thank you Uwe,
I was one of those victims of the "ban" and fellow operators lost years
of my support work. I moved my stuff over to Reddit r/WSJTX. Everyone
is welcome. Please feel free to use it. It is not to compete with
other resources, but rather to support the community. I would
No, you are not a goof. The auto sequencer is looking for either
"RR73", or "RRR" to move onto the next sequence. "RRR 73" (extra R and
a space) is not recognized by the auto sequencer. Therefore, it will
send TX3 until it receives what is expected, or you intervene
manually. The issue is
Greetings,
I have built WSJT-X 2.6.0 on LMDE 5 and have run across the array
warnings in:
Building Fortran object CMakeFiles/ft8sim.dir/lib/ft8/ft8sim.f90.o
Warning: Array ‘cwave’ at (1) is larger than limit set by
‘-fmax-stack-var-size=’, moved from stack to static storage. This makes
the
Hi Glenn,
Version 2.5.4 is the latest released version. Version numbers
containing -RC in the file name are release candidates for beta
testing. They may not be stable, they may have bugs, they may have
things missing, they expire. They are not intended for daily use, but
rather for test
b1bqe
*From:* Jeff Stillinger via wsjt-devel
*Sent:* Sunday, December 4, 2022 4:45 PM
*To:* wsjt-devel@lists.sourceforge.net
*Cc:* Jeff Stillinger
*Subject:* Re: [wsjt-devel] libboost and Mint 21
On Mint 21, you have to build 2.5.4 from source, or, use a package from
the Mint 21 repos
On Mint 21, you have to build 2.5.4 from source, or, use a package from
the Mint 21 repository.
Go here and download the script for Mint 21. Run the script,
instructions inside the script. This will install all of the required
run time and build libraries for WSJT-X, W1HKJ (FLDigi, FLRig, et
Or... you can download the .deb from the WSJT-X site and install with
sudo apt -y install ./wsjt-x_2.3.4_amd64.deb Not having to worry if the
repository is up to date or not.
On 9/1/22 18:03, John Fioroni via wsjt-devel wrote:
You might add a note to your Users Manual that installing wsjtx
This isn't actually a problem. You have identified the changes that
will be required when 2.6 replaces 2.5. That is what RC candidates are
meant to do. So moving forward, with 2.6 GA, you should have a
seamless integration.
On 7/27/22 09:31, Sam W2JDB via wsjt-devel wrote:
Hi All,
Jus
Complied on SuSE Leap 15.4 and SuSE Linux Enterprise 15.4 with warnings,
no errors.
On 7/21/22 07:58, Joe Taylor via wsjt-devel wrote:
Dear WSJT-X Users,
We are pleased to announce that Release Candidate WSJT-X 2.6.0-rc2 is
ready for download by beta testers. A list of its essential changes
I think everyone here is slightly confused...
Henryk,
Two things need to be checked in WSJT-X settings. On the General Tab
in Settings, check the following two items:
"Double Click on Call sets TX enable", and, "Disable Tx after sending 73"
What these two setting do for you is after you s
On the Pi, or any Linux based system, you have to be a member of the
dialout group in order to have access to the serial port. So if all of
the software is being denied access to the serial port, most likely,
your not a member of group dialout.
sudo -a -G dialout
Reboot to be safe, but logg
Greetings,
As we know, SuSE released Enterprise 15, Service Pack 4 Beta last month
for testing. I am happy to report that WSJT-X compiles without error
and operationally functions without error. The PREEMPT Kernel will be
the default moving forward with both OpenSuSE and Enterprise. Oh b
WSJT-X is open source, so you are free to build your suggestions. No
need for the developers to get involved. My working version looks and
feels nothing like the generic default version. Complete
customization. Looking forward to seeing your proto type.
On Tuesday 5/17/2022 07:18, Al
* - Building on what platform? Windows, Linux, macOS, or other? *
SuSE Linux Enterprise 15.3 (15.4 Beta), Debian 11, Experimental on
FreeBSD 13. Created and made available shell scripts to create and
configure the development environment on *nix systems.
* - What are your particular progra
There are a couple of options. I build on SuSE Linux Enterprise (15.3)
and the issue you bring up isn't an issue.
With that said, you can try rolling back the libraries to one that is
functional. Tumbleweed is a rolling forward release, well ahead of the
Enterprise, as you already know. T
Perhaps your issue with rig control is taken care of in the FLRig
update. Current version is 1.4.4
On 3/4/22 11:22, Juergen Christlieb via wsjt-devel wrote:
After everything worked fine for months, I suddenly no longer get any
control on the trx (possibly after an Ubuntu update?). Have mea
work under 12.X?
Thanks again
Jason
On 1/7/22 09:50, Jeff Stillinger via wsjt-devel wrote:
That has been fixed and WSJT-X 2.5.4 builds out of the ports
collection on FreeBSD 13.
portsnap fetch update
make install clean
WSJT-X 2.5.4 builds and installs without error.
Oh, and thanks fo
That has been fixed and WSJT-X 2.5.4 builds out of the ports collection
on FreeBSD 13.
portsnap fetch update
make install clean
WSJT-X 2.5.4 builds and installs without error.
Oh, and thanks for the reminder to send Diane the request to add the
binary to the package collection.
On 1/6/2
The source build went well. However, it's time for one of those code
clean ups. Several misc. warnings popping up during the build.
On 1/3/22 10:54, Joe Taylor via wsjt-devel wrote:
Please welcome two new members of the core WSJT Development group:
Chet Fennell, KG4IYS, and Uwe Risse, DG2Y
As the audio drop outs... You can try to modify /etc/pulse/daemon.conf
and see if adjusting the daemon priority and a faster sample rate
helps. Solved a couple of issues for me with Debian 11.
Uncomment this line:
; high-priority = yes
Uncomment this line:
; default-sample-rate = 44100
C
For years, Linux users simply get the tar ball of source at the bottom
of the web page. That is more than perfect. Bill wrote many many
times that the recommended method is to always build from that source
tar ball. Myself and many others have created build scripts for
various flavors of
Thank you Bill, Neil, and James for helping make my earlier point. Open
source code allows a station to completely customize the U.I. for their
style of operations. So for those that are on the fox/hound hunt and
desire the checkbox in a specific location for their operations, simply
move it
Thanks & 73 de KM8V Jon
On Sun, Oct 10, 2021 at 9:37 AM Jeff Stillinger via wsjt-devel
<mailto:wsjt-devel@lists.sourceforge.net>> wrote:
How about an alternative to your prediction. WSJT-X is open
source. You have complete access to the source code, and one of
the
How about an alternative to your prediction. WSJT-X is open source.
You have complete access to the source code, and one of the wonderful
conveniences of the package is the ability to customize the software to
a specific style of station operations.
That is the fancy and PC way to say, if y
This is the actual issue...
/home/kb6ibb/src/wsjtx-2.5.0-rc6/build/hamlib-prefix/src/hamlib/tests/testlibusb.c:343:2:
warning: #warning LIBUSB-1.0.23 will be required in Hamlib > 4.3 [-Wcpp]
#warning LIBUSB-1.0.23 will be required in Hamlib > 4.3
The current Enterprise level version of the li
Just an FYI...
Making all in rigs/prm80
libtool: compile: cc -DHAVE_CONFIG_H -I.
-I/home/kb6ibb/Downloads/wsjtx-2.5.0-rc1/build/hamlib-prefix/src/hamlib/rigs/prm80
-I../../include -I/usr/local/include -DIN_HAMLIB
-I/home/kb6ibb/Downloads/wsjtx-2.5.0-rc1/build/hamlib-prefix/src/hamlib/includ
Hi Bill,
I know this is not exactly the suggestion that you may want to consider,
but, I would feel remiss if I didn't mention it. The development team
has a difficult choice to make. I can empathize with people vs.
technology.
If you are trying to please the most people. I would suggest
WSJT-X is open source. You can make those changes you are suggesting,
thereby customizing your station operations. There is no licensing
restrictions that would stop you from doing so (see GPL 3).
However, do not be surprised if you actually loose a lot of
confirmations. Yes, I am one of
Using Boost 1.66 on SuSE Enterprise. Works just fine, builds without
error.
On 2/5/21 5:36 AM, jarmo wrote:
Has anyone managed install version 2.3.0 into F32?
2.3.0 has depencies to BOOST 1.73 and in F32
there is BOOST 1.69.
So anyone solved this?
Jarmo, oh1mrr
essing that and removing the forced styling
if it is no longer necessary.
73
Bill
G4WJS.
On 13/01/2021 15:22, Jeff Stillinger via wsjt-devel wrote:
The problem is you have Red Hat Enterprise, Oracle Enterprise,
Fedora, and CentOS pulling from the same repository with that line as
modified. So... for
ox is
built for the Enterprise.
On 1/13/21 8:48 AM, Bill Somerville wrote:
On 13/01/2021 14:41, Jeff Stillinger via wsjt-devel wrote:
File: wsjtx.desktop
Change line 5 FROM: Exec=wsjtx TO: Exec=wsjtx --style="fusion"
It took me a while to figure out why my local builds looked different
File: wsjtx.desktop
Change line 5 FROM: Exec=wsjtx TO: Exec=wsjtx --style="fusion"
It took me a while to figure out why my local builds looked different
from those I found in the pre-built repositories. I was waiting to
mention this at the next RC cycle to make it easy to correct. Chang
"c++: fatal error: Terminated signal terminated program cc1plus "
That is actually an out of memory error. Either not enough ram or swap
space to handle all of the multiple parallel processes going on during
compilation.
Use make -j 4 instead to reduce the number of parallel processes
45 matches
Mail list logo
