Well, like picking a scab I just couldn't leave it alone, so I dug into the
Python3 package and figured out how to bootstrap it.
There are now more python packages in my COPR repository than wsjt related
packages, and I've still got a few more to go...
Thanks,
Richard
Well, to get the 3 python3 dependencies required for wspr, I had to build
an additional 15 packages, but it's done!
http://copr.fedoraproject.org/coprs/hobbes1069/WSJT/monitor/
Richard
--
Slashdot TV. Video for Nerds. S
Perhaps changing it to "pre" for pre-release would be better?
Thanks,
Richard
--
Slashdot TV. Videos for Nerds. Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
I'm not sure why it worked for others (or perhaps why it was broken for me)
but building an "official" rpm for Fedora I got an error with gzip.
Looking at the CMake config, it seems the man pages were being "globbed"
for zipping instead of specifing the specific file. Maybe it was a parallel
make
On Tue, Sep 30, 2014 at 2:39 PM, Bill Somerville
wrote:
> On 30/09/2014 20:34, Richard Shaw wrote:
> > Looking at the CMake config, it seems the man pages were being
> > "globbed" for zipping instead of specifing the specific file. Maybe it
> > was a parallel make
On Tue, Sep 30, 2014 at 4:23 PM, Bill Somerville
wrote:
> I think 'rpm' should install dependent packages but it didn't work for
> me on Fedora 20 so it is still on my list to investigate further.
What dependency are you missing? When I check I get the following from my
RPM:
$ rpm -qp --requir
On Tue, Sep 30, 2014 at 5:33 PM, Bill Somerville
wrote:
> On 30/09/2014 22:42, Richard Shaw wrote:
>
> Hi Richard,
>
> On Tue, Sep 30, 2014 at 4:23 PM, Bill Somerville
> wrote:
>
>> I think 'rpm' should install dependent packages but it didn't work f
On Tue, Sep 30, 2014 at 8:10 PM, Bill Somerville
wrote:
> On 01/10/2014 02:00, Richard Shaw wrote:
>
> In the yum-utils package there is a helper script called "package-cleanup"
> which can be used to find orphans (or other issues).
>
> $ package-cleanup --leaves
&
Yes, for users of Fedora I have submitted a review request to the RPM
Fusion non-free repository, though no one has picked it up yet.
https://bugzilla.rpmfusion.org/show_bug.cgi?id=3400
So as long as the rpmfusion repositories are installed, a "yum install
wsjtx kvasd" would be sufficient.
Unfor
On Fri, Nov 21, 2014 at 10:44 AM, Joe Taylor wrote:
> cc -c -arch i386 usleep.c
> cc -c -O2 -arch i386 asd1.c
> gfortran -o kvasd_1.12_mac32_10.7 -m32 kvasd.f90 asd1.o usleep.o
>
> cc -c -arch x86_64 usleep.c
> cc -c -O2 -arch x86_64 asd1.c
> gfortran -o kvasd_1.12_mac64_10.7 -m64 kvasd.f90 asd1.
On Fri, Nov 21, 2014 at 11:48 AM, Joe Taylor wrote:
> Richard --
>
> No need for CMake here, this is a trivial (and infrequently required)
> build operation.
Perhaps, but it seems different flags are needed just between mac
versions... Putting it in a build system keeps you from having to remem
I notice that I have to adjust the input level into wsjt-x every time I
start it up. I thought perhaps it was a bug in the gnome-shell sound applet
but I noticed that the name of the input changes every time I start wsjt-x,
currently it is "QtPulseAudio:542" and the time just before it was
"QtPulse
I setup a COPR[1] repository for Fedora some time ago and I've been using
the package from it with a good deal of success, though sometimes I have
trouble being heard but I think that's more of an antenna problem than
software problem :)
I don't recall ever seeing an official 1.4.0 release, just r
On Wed, Feb 18, 2015 at 11:07 AM, Bill Somerville
wrote:
> On 18/02/2015 16:58, Richard Shaw wrote:
> Hi Richard,
> > I setup a COPR[1] repository for Fedora some time ago and I've been
> > using the package from it with a good deal of success, though
> > sometimes I
Mike,
Sorry I can't find the first email in this thread though I remember reading
it.
I currently do the Fedora builds for COPR but unfortunately it doesn't
support arm yet but you can use the SRPM to build your own.
https://dl.dropboxusercontent.com/u/34775202/wsjt/SRPMS/wsjtx-1.4.0-0.2.rc4.fc2
Not specific to any particular version but I did notice that the "DT"
column is not documented. I assume this is some measure of signal deviation
or drift?
Thanks,
Richard
--
BPM Camp - Free Virtual Workshop May 6th at 10a
On Fri, May 8, 2015 at 8:38 AM, Joe Taylor wrote:
> I notice that the resulting wsprd.exe is more than 5 times larger than
> the one built from .../wsjtx_exp/lib/wsprd/Makefile.MinGW :
>
> (JTSDK-QT) C:\JTSDK\wsjtx_exp\install\Release\bin)ls -l wsprd*.exe
> -rwxrwxrwx 1 joe 0 674132 2015-05-08 0
I wouldn't mind testing things out but I prefer to work from tags at least.
Can we get a tag of 1.6.1 in svn?
If so, is it worth updating my COPR repository?
Thanks,
Richard
--
One dashboard for servers and applications a
On Tue, Jun 2, 2015 at 6:38 PM, Bill Somerville
wrote:
> Hi All,
>
> I have fixed a couple of minor issues reported since the RC2 release and
> I am happy that they will not cause any regressions.
>
> Does anyone know of any reasons why I should not start the process of
> tagging and building a G
I was casually trying to make contacts while working on another FOSS radio
project and I completed the QSO and the log window came up. I then saw a
station I was interested in so I went ahead and double-clicked on it (with
the auto-enable TX turned on).
I then went back and looked up the OP name i
This has happened to me a couple of times with 1.5.0-rc2 and 1.5.1-rc1
I just finished a QSO and while I was looking up the persons name on QRZ
before logging the QSO I hear my radio go into TX and look back at wsjt-x
and it has changed automatically to the CQ message and starts transmitting
even
On Sat, Jul 4, 2015 at 3:18 PM, Bill Somerville
wrote:
> On 04/07/2015 20:42, Richard Shaw wrote:
> Hi Richard,
> > This has happened to me a couple of times with 1.5.0-rc2 and 1.5.1-rc1
> >
> > I just finished a QSO and while I was looking up the persons name on
> >
On Wed, Jul 22, 2015 at 8:00 AM, Joe Taylor wrote:
> What's up at SourceForge ???
>
> This is getting ridiculous. Maybe it's time for us to consider github
> seriously?
I tried to send an email the other day and it bounced...
Thanks,
Richard
KF5OIM
I'm not sure who else has battled this but Qt in their infinite wisdom
decided they need a random name for the audio connection to PulseAudio
which means it will NEVER remember the volume level you set.
I did some digging on PA command line options and came up with a script to
start wsjtx:
launch
Wed, Jul 22, 2015 at 2:14 PM, Bill Somerville
wrote:
> On 22/07/2015 18:45, Richard Shaw wrote:
>
> Hi Richard,
>
> I'm not sure who else has battled this but Qt in their infinite wisdom
> decided they need a random name for the audio connection to PulseAudio
>
On Mon, Sep 7, 2015 at 3:47 AM, Alan VK2ZIW
wrote:
>
> No probs here on Fedora 21 x86_64
>
> svn co svn://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx_exp
>
> == cmake ==
> # cd wsjtx_exp; mkdir build; cd build; cmake ../
> # edit CMakeCache.txt change INSTALL ; make install
> # ge
If you're an early adopter and working out of a non-release branch you have
to understand what you're signing up for.
When a release it tagged, what about dropping them from the archive?
Richard
--
Monitor Your Dynamic In
Also, you can do verbose make to see more detail
$ make VERBOSE=1
Or set CMAKE_VERBOSE_MAKEFILES to TRUE (I think that's the right variable)
Thanks,
Richard
--
Monitor Your Dynamic Infrastructure at Any Scale With Datado
Excellent news!
This will make both programs MUCH easier to get into distributions such as
Fedora and Debian without the need for hokey workarounds.
Thanks,
Richard
KF5OIM
--
__
On Fri, Oct 23, 2015 at 10:13 AM, David Ranch
wrote:
>
> Hey Greg,
>
> Though slightly older versions at the moment, Richard Shaw has had WSJTX
> RPMs available for Fedora for some time:
>
> https://copr.fedoraproject.org/coprs/hobbes1069/WSJT/builds/
Yeah, I've
nging there, but that's not too far off either I would think.
>
> Re: Fedora, I forgot about looking in the SRPM's for the package lists.
> I can use that an add to grab a rough pkg list ad add to the file.
>
> 73's
> Greg, KI7MT
>
>
> On 10/23/2015 09:20,
ACK! Accidentally hit Cntl-Enter in gmail and it sent the message early!
On Fri, Oct 23, 2015 at 5:19 PM, Greg Beam wrote:
> One important thing to note, for FOSS platforms, Steve and Joe are close
> to having a replacement for KVASD it would seem, for both WSJT and
> WSJT-X, so when they make t
I was trying to update the wsjtx version in my COPR repository[1] but the
builds are failing on Fedora 22+ (but working on Fedora 21)
Here's a link to the failing build on rawhide:
https://copr-be.cloud.fedoraproject.org/results/hobbes1069/WSJT/fedora-rawhide-x86_64/00129822-wsjtx/build.log.gz
Bu
Ok, a little more detail, I dug out the internal log and found this:
In file included from
/builddir/build/BUILD/wsjtx-1.5/build/wsjtx-prefix/src/wsjtx/WFPalette.cpp:1:0:
/builddir/build/BUILD/wsjtx-1.5/build/wsjtx-prefix/src/wsjtx/WFPalette.hpp:53:40:
error: expected constructor, destructor, or t
On Mon, Oct 26, 2015 at 6:08 PM, Bill Somerville
wrote:
> It is a newer Qt issue, they reorganized some header files and v1.5 does
> not build with QT >= 5.4. I had not worried about it since a v1.6.0
> release is probably more likely than a v1.5.1 release.
>
> If you really need to build V1.5 on
Thanks for setting that up Bill.
I worked around it by creating two patches :) One addressed the qt 5.4
issue and the other modified CMakeLists.txt to include a patch during the
wsjtx build but that will make things easier in the future.
Richard
KF5OIM
I ran into an additional issue with hamlib not being built with -fPIC which
caused the wsjtx build to fail during linking but I fought through that and
now have good builds of wsjtx 1.5.1-rc2 for Fedora 21, 22, and Rawhide. I
forgot to add F23 to the COPR so that build is happening now.
https://co
On Tue, Oct 27, 2015 at 11:13 AM, Joe Taylor wrote:
> Hi Bill, Richard, and all,
>
> I guess we need to decide whether there will be a v1.5.1 release. As
> Bill suggested, an alternative is to offer a v1.6.0-rc1.
>
> If we do a v1.5.1 release, it would be well to include the corrected
> version
On Tue, Oct 27, 2015 at 11:34 AM, Bill Somerville
wrote:
> On 27/10/2015 16:00, Richard Shaw wrote:
> Hi Richard,
> > I ran into an additional issue with hamlib not being built with -fPIC
> > which caused the wsjtx build to fail during linking but I fought
> > throug
On Tue, Oct 27, 2015 at 12:54 PM, Bill Somerville
wrote:
> On 27/10/2015 17:38, Richard Shaw wrote:
>
> On Tue, Oct 27, 2015 at 11:34 AM, Bill Somerville <
> g4...@classdesign.com> wrote:
>
>> On 27/10/2015 16:00, Richard Shaw wrote:
>> Hi Richard,
>> >
On Tue, Oct 27, 2015 at 1:25 PM, Bill Somerville
wrote:
> On 27/10/2015 16:28, Richard Shaw wrote:
>
> Hi Richard,
> > Also, while you're at it I have some improvement ideas for the
> > superbuild script:
> >
> > https://dl.dropboxusercontent.com/u/347752
Ok, based on the feedback here, I have removed all 1.5.1 builds and
replaced it with 1.5.0. If you previously upgraded I would recommend you
"downgrade" to 1.5.0 by either removing and reinstalling or for those on
yum the following SHOULD work:
# yum distro-sync wsjtx
or for DNF:
# dnf distro-sy
Sorry if I missed the email but I remember seeing some discussion on the
replacement of kvasd. Is that transition (or will it be) complete with the
release of 1.6.x?
Thanks,
Richard
KF5OIM
--
__
On Wed, Nov 18, 2015 at 8:17 AM, Joe Taylor wrote:
> Version 1.6.0 uses kvasd. Version 1.7.0 (formerly known as v1.6.1) does
> not.
Ok, I've still got a Review Request over at RPM Fusion non-free which never
went anywhere. I'll leave it alone for now I can cancel it when 1.7
releases.
Thanks,
Interesting, while I found many references to it using google, I'm not
familiar with INSTALLD but what I did find I don't think that's what you
want to use with DESTDIR.
DESTDIR is to basically relocate where a package is installed for packaging
purposes so a non-root user can do the install. The
>
> Hi Richard,
> We meet again ;)
> INSTALLD is just a variable name in Greg's script which does use
> CMAKE_INSTALL_PREFIX - see the extract below:
>
> ---snip---
> # set install locaiton
> if [ $SEPARATE == "Yes" ] ; then
> INSTALLD="$PREFIXD/$APP_NAME/$VERSION/$WSJTXV"
>
On Fri, Nov 27, 2015 at 8:57 AM, Bill Somerville
wrote:
> On 27/11/2015 14:45, Richard Shaw wrote:
> > I don't use the shell script, I just use the superbuild script directly.
> >
> > $ cmake -DWSJTX_TAG=tags/wsjtx-1.6.0-rc1 ~/svn/wsjtx-superbuild
> > $ make s
On Fri, Nov 27, 2015 at 10:08 AM, Bill Somerville
wrote:
> On 27/11/2015 16:03, Richard Shaw wrote:
>
> > $ cmake -DWSJTX_TAG=tags/wsjtx-1.6.0-rc1 ~/svn/wsjtx-superbuild
>> > $ make source
>> A big green tick next to that from me! Although upstream source tarba
On Fri, Nov 27, 2015 at 10:17 AM, Greg Beam wrote:
> Hi Richard,
>
> As far as I'm aware, I do not pass any CMAKE_INSTALL_PREFIX in a chroot
> or build server environment. Whatever is set by Cmake or the server is
> what gets used, which I am pretty sure is /usr.
>
> The only time I pass the CMAK
On Fri, Nov 27, 2015 at 10:33 AM, Greg Beam wrote:
> Hi Richard,
>
> From what I've read, and I may be way off on this, DESTDIR has no
> bearing on CMAKE_INSTALL_PREFIX or RPATH, for example:
>
> If I set:
>
> CMAKE_INSTALL_PREFIX=/home/ki7mt/wsjtx
>
> and prefix it with DESTDIR=/tmp/example1
>
I just tried building for Fedora 22 using the superbuild script and ran
into this building the fork of hamlib:
libtool: compile: gcc -DHAVE_CONFIG_H -I.
-I/home/build/rpmbuild/wsjtx/BUILD/wsjtx-1.6.0-rc2/build/hamlib-prefix/src/hamlib/adat
-I../include -DIN_HAMLIB
-I/home/build/rpmbuild/wsjtx/BUI
On Wed, Dec 9, 2015 at 4:15 PM, Bill Somerville
wrote:
> Does the following file exist after the failure:
>
>
> /home/build/rpmbuild/wsjtx/BUILD/wsjtx-1.6.0-rc2/build/hamlib-prefix/src/hamlib-build/include/config.h
>
> and if it does, what do the first 11 lines say?
Looks like something is off.
On Thu, Dec 10, 2015 at 6:55 AM, Bill Somerville
wrote:
> On 10/12/2015 03:32, Richard Shaw wrote:
>
> On Wed, Dec 9, 2015 at 4:15 PM, Bill Somerville
> wrote:
>
>> Does the following file exist after the failure:
>>
>>
>> /home/build/rpmbuild/wsjtx/BUILD/
On Thu, Dec 10, 2015 at 8:14 AM, Bill Somerville
wrote:
> On 10/12/2015 14:03, Richard Shaw wrote:
> > Yes, disabling parallel make fixed the problem, but why? Did I didn't
> > see any changes in the superbuild script that would affect that.
> Hi Richard,
>
> I m
New builds for Fedora 22 through Rawhide and EPEL 7 have been completed in
my COPR:
https://copr.fedoraproject.org/coprs/hobbes1069/WSJT/
On a whim I tried ppc64 builds but they all failed, I haven't had time to
look into why though.
Thanks,
Richard
KF5OIM
---
On Sat, Apr 19, 2014 at 5:56 AM, Bill Somerville wrote:
> Hi All,
>
> as most Linux distros are starting to include Qt 5 in their stable
> official repos and because we are statically linking the Hamlib we are
> using at present it is possible for us to generate packages that could
> be submitted
On Sat, Apr 19, 2014 at 8:40 AM, Bill Somerville wrote:
> On 19/04/2014 14:12, Richard Shaw wrote:
> Hi Richard,
>
> On Sat, Apr 19, 2014 at 5:56 AM, Bill Somerville
> wrote:
>
>> Hi All,
>>
>> as most Linux distros are starting to include Qt 5 in their sta
On Sun, Apr 20, 2014 at 7:25 PM, Chuck Forsberg WA7KGX wrote:
> What is the current build procedure for wsjtx
> not limited to Debian??? Fedora in particular.
>
> I have hamlib compiled, installed, and working
> with wspr.
Would you like a SRPM? I have what I more or less intend to submit as a
On Sun, Apr 20, 2014 at 8:12 PM, Chuck Forsberg WA7KGX wrote:
>
> On 04/20/2014 06:00 PM, Richard Shaw wrote:
>
> On Sun, Apr 20, 2014 at 7:25 PM, Chuck Forsberg WA7KGX wrote:
>
>> What is the current build procedure for wsjtx
>> not limited to Debian??? Fedora
On Friday, May 16, 2014, Claude Frantz wrote:
> While tying to compile on 32 bit Fedora 19, I encounter the following
> situation:
>
> running scons
> Removing build directory /tmp/tmp3nbwxy
> /usr/bin/mv w.*.so WsprMod/w.so
> /usr/bin/mv: cannot stat ‘w.*.so’: No such file or directory
> make: *
Well, I just submitted build of wsjtx and wsprx for Fedora 19 & 20, and
EPEL 6 and 7. I have no idea if they will all complete but I'll try and fix
anything that doesn't.
http://copr.fedoraproject.org/coprs/hobbes1069/WSJT/
Thanks,
Richard
-
I'm working on creating an RPM for Fedora linux and ran into a few issues
building wspr.
First one:
/bin/f2py -c --quiet --fcompiler=gnu95 --f77exec=gfortran
--f90exec=gfortran \
--opt="-cpp -fbounds-check -O2" thnix.o -Wl,-z,relro -Wl,-z,relro
-lfftw3f -lgfortran -lportaudio -lpthread -lsampler
Ok, I got it fixed but I'm not sure what the exact problem is.
WSPR doesn't like the default LDFLAGS on Fedora (and probably the same for
Debian?)
LDFLAGS="-Wl,-z,relro
If anyone is interested I have a couple of patches that I needed to fix the
build as f2py didn't like LDFLAGS as well as adding
On Tue, Jun 17, 2014 at 7:45 PM, Chuck Forsberg WA7KGX wrote:
> On 06/17/2014 04:45 PM, ki7mt wrote:
>
> Hi Richard,
>
> Sorry, was away for a few days and just now caching up. See below.
>
>
> On 06/10/2014 10:52 AM, Richard Shaw wrote:
>
> Ok, I got it fixed b
On Thu, Jun 19, 2014 at 11:39 AM, Joe Taylor wrote:
> On 6/19/2014 12:19 PM, Mike Thompson wrote:
> > Any idea how long this will take to come to Linux?
>
> It runs fine in Linux now... but you need to compile it yourself.
I've got a Fedora RPM package done but without a make install target I'm
It's not a super recent checkout but you can try rebuilding an SRPM from my
COPR repository.
http://copr.fedoraproject.org/coprs/hobbes1069/WSJT/monitor/
Richard
On Saturday, June 21, 2014, Chuck Forsberg WA7KGX wrote:
> [ 80%] Building CXX object CMakeFiles/wsjt_qt.dir/HRDTransceiver.cpp.o
>
I'm currently targeting:
EPEL 6 (i686/x86_64)
EPEL 7 (x86_64)
Fedora 19 (i686/x86_64)
Fedora 20 (i686/x86_64)
Fedora 21 (i686/x86_64)
I just built new packages for Fedora but the EPEL builds are still failing
which leads me to a question:
Is there any reason to prefer python 3 to python 2? I must
I just build a package for Fedora 20 and needed to tweak a few things in
the CMake config to get a good build.
I addressed two issues:
1. PortAudio is required but is not detected or linked against.
2. Move the linking of palir-2.dll (which I'm guessing is a pre-built PA
library for windows) to th
On Tue, Sep 16, 2014 at 7:38 AM, Michael Black wrote:
> I just noticed that svn says version 4321 but "svn log" has not entries
> after r4297.
>
> I see other big holes in the log…so is somebody not making commit comments
> like they should?
>
Since all the wsjt programs are in one big svn repos
Ok, I'm going to give up on EPEL for now. I just found out they don't have
Python 3 at all. I'm not sure I want to support the whole stack needed for
the wsjt programs.
Thanks,
Richard
--
Want excitement?
Manually upgrade
On Wed, Sep 17, 2014 at 3:54 PM, KI7MT wrote:
> Hi Richard,
>
> I'm not well versed in EPEL, but, is EPEL ( RHEL, CentOS etc )? Does
> package inclusion or exclusion in EPEL mean Python3 based apps are a
> no-go for Fedora as well or are they managed separately?
>
Basically, Fedora EPEL are pack
I'm trying to build wsjtx for both EL 6 and 7. The EL 7 build succeeds but
the EL 6 build fails:
Building C object CMakeFiles/wsjt.dir/lib/gran.c.o
/builddir/build/BUILD/wsjtx-1.4.svn4524/lib/options.f90:301.4:
class(option), intent(in) :: opt
1
Error: Unclassifiable statement at (1)
/buil
I can't promise they're 100% functional but I have built hamlib 3 (latest
git as of today) packages for Fedora 19, 20, & 21 and EPEL 7.
I tried EPEL 6 but autoconf is too old.
I renamed pretty much everything to be parallel installable with hamlib
1.2.X.X
Most of which was done through patching
I know a lot of tweaks have been made to hamlib since the last official
release to work with WSJT-X which means for now I'm using the superbuild
script which builds a bundled checkout of hamlib.
That's pretty much the only thing keeping me from getting WSJT-X into
Fedora proper.
I can ask on the
On my Fedora 27 x86_64 system I get a segmentation fault when trying to use
the FreqCal mode...
Starting program: /usr/bin/wsjtx
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7fffe0a98700 (LWP 24504)]
[New Thread 0x7fffd6ce6
On Wed, Jan 17, 2018 at 10:00 AM, James Barron wrote:
> Someone please tell me how to get off this list?
>
> Thank you very much
>
> 73 de jim
>
Try looking at the bottom of every single email. :)
Richard
KF5OIM
--
Che
I have not seen this crash but I get a crash when I try to enable
calibration mode but haven't had time to troubleshoot. FT8 has been rock
solid for me (Fedora 27 x86_64 w/ 1.8. from my COPR[1])
RIchard
KF5OIM
[1] https://copr.fedorainfracloud.org/coprs/hobbes1069/WSJT/
--
Here's my output:
$ readelf -lW `which jt9` | grep GNU_STACK
GNU_STACK 0x00 0x 0x 0x00
0x00 RWE 0x10
Thanks,
Richard
--
Check out the vibrant tech community on one of the
On Fri, Jan 19, 2018 at 6:44 AM, Jaroslav Skarvada
wrote:
>
> I am Fedora packager, and AFAIK the answer is NO. Also it seems there is
> no Fedora global policy about it. Just rpmlint is complaining. I fixed the
> spec not to enforce the NX stack and released updated builds. Feel free to
> test a
I somehow completely missed that. I've been maintaining a COPR for some
time now which includes support for EL 7.
If you want to add me as a maintainer (FAS: hobbes1069) I'll put in a
ticket for EPEL 7 so I can close my COPR.
Thanks,
Richard
---
On Fri, Jan 19, 2018 at 9:03 AM, Jaroslav Skarvada
wrote:
> OK, no problem, I added you. I have no problem with EPEL-7, I didn't
> request it in the beginning, just because I didn't need it :)
>
Thanks. I'm running Fedora 27 but there are a number of hams that prefer
the stability of the EL dist
Just a heads up...
Fedora adopts the gcc prereleases (version 8 right now) within Rawhide
(devel release of Fedora) to work out bugs so other distro's don't have to.
The following link is the standard "porting to.." for gcc but it's not yet
finalized. It does, however, have some early info to the
I had this problem with 1.8.0 and I'm pretty sure I posted it here but
didn't get a response.
A few seconds after switching to FreqCal mode WSJT-X crashes with the
following error:
$ wsjtx -c calibration
At line 52 of file
/builddir/build/BUILD/wsjtx-1.9.0-rc3/wsjtx/lib/freqcal.f90
Fortran runtim
I haven't been following this thread in detail but we're not having any
issues building the official Fedora packages, you may want to look there
for some hints...
https://src.fedoraproject.org/rpms/wsjtx
Thanks,
Richard
KF5OIM
--
On Wed, May 16, 2018 at 1:52 PM Saku wrote:
>
> How ever your link to src.fedoraproject has rpm that works.
>
> Just wondering what is the difference in gcc-gfortran, libgfortran and
> libquadmath between "average user's F28" and rpm builder's F28
> Those seems to be the source of this problem.
Ok, this is precisely why I wait a month or two before upgrading :)
However, since so many people are having issues and as I'm one of the
package maintainers I think what I'm going to do is boot to a live instance
of F28 via USB flash drive and install wsjtx and see what I can figure
out...
Somew
On Mon, May 21, 2018 at 9:51 AM, Claude Frantz wrote:
> On 05/21/2018 03:19 PM, Michael Pittaro wrote:
>
> Hi Mike, Saku & All,
>
> I was able to make QSO's today using F28: I have compiled wsjtx from
> source code (r8667). I have directed cmake to use a locally installed
> hamlib 3.3.1 (because
I ran into a similar issue a while back when I was rolling my own wsjtx
packages...
I just grepped through current SVN and I can see the requirement in the
CPack portion of the CMake config but I can't see what in the sources pulls
in the requirement and the official Fedora package does not have t
On Wed, May 30, 2018 at 3:32 AM, Saku wrote:
> One problem:
>
> 1.9.0 does not install to Fedora 27 (that is still valid release) from
> 64bit rpm ( https://physics.princeton.edu/pulsar/k1jt/wsjtx-1.9.0.x86_
> 64.rpm )
>
> Using
>
> *rpm -Uvh *[saku@hamtpad ~]$ sudo rpm -Uvh
> /home/saku/Latauks
On Wed, May 30, 2018 at 8:38 AM, Claude Frantz wrote:
> On 05/30/2018 02:06 PM, Richard Shaw wrote:
>
> Hi Bob & Saku,
>
> > I know it takes a few days to a week but sometimes it's best to wait for
> > the official packages to work through the release syste
While trying to build wsjtx 1.9.1 I got a build error. It looks like the
long depreciated qt5_use_modules macro has been removed from the release of
qt5 in Fedora Rawhide.
I made some simple changes as recommended[1], here's an example snippet:
@@ -1343,7 +1343,8 @@ else ()
)
endif ()
On Thu, Jun 14, 2018 at 4:05 PM Barry Jackson wrote:
> On 09/06/18 19:23, Bill Somerville wrote:
>
> > the WSJT svn repository is back up and running now, sorry for the
> > extended outage, reorganization is complete.
> >
>
> Just ran my regular script to create a 1.9.1 tarball which uses
> wsj
So I've ran into the same bug as other and am just as dumbfounded
Actually audio did work just after install but after a few transmit cycles
the waterfall froze. I noticed this a couple of times. I also tried just
receiving and no freeze occured.
Then I tried updating and rebooting and how no
On Sat, Jun 16, 2018 at 11:01 AM Claude Frantz
wrote:
> On 06/16/2018 03:44 AM, Richard Shaw wrote:
>
> > Then I tried updating and rebooting and how now matter what I try,
> > pavucontrol, alsamixer, etc. I can't see any attempt to send audio.
> >
> > Fedora 2
On Sun, Jun 17, 2018 at 2:56 AM Claude Frantz
wrote:
> On 06/16/2018 10:26 PM, Richard Shaw wrote:
>
> Hi Richard & All,
>
> > I had that problem early on with WSJT-X but not for the last several
> > releases. When I say I don't get any audio, I mean zero. The A
Ok, while good, this is very frustrating...
Went back and build current git, waterfall locked up, no audio out, process
hung on exit...
Went back and changed it from Release to Debug and changed the QT option
for debug output, make clean, make, make install - waterfall lockup after
tune, no audio
On Sun, Jun 17, 2018 at 9:16 AM Claude Frantz
wrote:
>
> can you type "pacmd list-sources" and see if there is anything abnormal.
>
Nothing jumped out at me...
$ pacmd list-sources
4 source(s) available.
index: 2
name:
driver:
flags: DECIBEL_VOLUME LATENCY DYNAMIC_LATENCY
state: SUSPENDED
On Sun, Jun 17, 2018 at 2:06 PM Saku wrote:
> Barry Jackson kirjoitti 17.06.2018 klo 20:23:
>
> Closing wsjtx leaves a running instance and lockfile which has to be
> killed manually.
>
> That is because it leaves a "pulse" sub process hanging.
>
> This have been noticed already a month ago with
Claude
Thank you for the very detailed instructions.
I'm a Fedora packager for several years so I understand most of the ins and
outs of pulseaudio. Unless the also device was chosen for both input and
output I would not see anything pop up in Playback when transmitting, even
for "Tune". There mu
For those on Fedora who want to test the pre-release version of WSJT-X I
have completed RC1 builds in my COPR[1].
I will not be updating the mainline Fedora package until the final release.
Thanks,
Richard
KF5OIM
[1] https://copr.fedorainfracloud.org/coprs/hobbes1069/WSJT/
__
1 - 100 of 236 matches
Mail list logo
