Bug 1487776 - Review Request: wsjtx - Weak Signal communication by K1JT
Summary: Review Request: wsjtx - Weak Signal communication by K1JT
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Robert-André Mauchin 🐧
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-09-01 21:36 UTC by Jaroslav Škarvada
Modified: 2017-10-05 22:51 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-09-30 06:39:04 UTC
Type: ---
zebob.m: fedora-review+


Attachments (Terms of Use)

Description Jaroslav Škarvada 2017-09-01 21:36:13 UTC
Spec URL: https://jskarvad.fedorapeople.org/wsjtx/wsjtx.spec
SRPM URL: https://jskarvad.fedorapeople.org/wsjtx/wsjtx-1.8.0-0.1.rc1.fc25.src.rpm
Description: WSJT-X is a computer program designed to facilitate basic amateur radio communication using very weak signals. It implements communication protocols or "modes" called JT4, JT9, JT65, QRA64, ISCAT, MSK144, and WSPR, as well as one called Echo for detecting and measuring your own radio signals reflected from the Moon.
Fedora Account System Username: jskarvad

Comment 1 Robert-André Mauchin 🐧 2017-09-02 10:10:59 UTC
Hello,

 - make %{?_smp_mflags} install DESTDIR=%{buildroot} should be replaced with the %make_install macro
 - Same with: make %{?_smp_mflags} → %make_build

 - You've got files with executable permission that shouldn't have it:

wsjtx.x86_64: W: spurious-executable-perm /usr/share/doc/wsjtx/GUIcontrols.txt
wsjtx.x86_64: W: spurious-executable-perm /usr/share/doc/wsjtx/jt9.txt
wsjtx.x86_64: W: spurious-executable-perm /usr/share/doc/wsjtx/mouse_commands.txt
wsjtx.x86_64: W: spurious-executable-perm /usr/share/doc/wsjtx/prefixes.txt
wsjtx.x86_64: W: spurious-executable-perm /usr/share/doc/wsjtx/shortcuts.txt
wsjtx.x86_64: W: spurious-executable-perm /usr/share/doc/wsjtx/v1.7_Features.txt
wsjtx.x86_64: W: spurious-executable-perm /usr/share/doc/wsjtx/wsjtx_changelog.txt

Maybe use -m 0644 with install:

install -m 0644 -p -t %{buildroot}%{_datadir}/doc/%{name} GUIcontrols.txt jt9.txt \
  mouse_commands.txt prefixes.txt shortcuts.txt v1.7_Features.txt \
  wsjtx_changelog.txt

 - Similarly you've got files with Windows line ending:

wsjtx.x86_64: E: wrong-script-end-of-line-encoding /usr/share/doc/wsjtx/GUIcontrols.txt
wsjtx.x86_64: E: wrong-script-end-of-line-encoding /usr/share/doc/wsjtx/prefixes.txt
wsjtx.x86_64: E: wrong-script-end-of-line-encoding /usr/share/doc/wsjtx/wsjtx_changelog.txt

Switch them to UNIX line endings by adding *.txt to your dos2unix command:

dos2unix *.ui *.iss *.rc *.txt

 - mock fails to verify the certificate of https://physics.princeton.edu :

wsjtx.src: W: invalid-url URL: https://physics.princeton.edu/pulsar/k1jt/wsjtx.html <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:748)>
wsjtx.src: W: invalid-url Source0: https://physics.princeton.edu/pulsar/k1jt/wsjtx-1.8.0-rc1.tgz <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:748)>

Switch to http if the problem persists.

 - /usr/share/doc/wsjtx/INSTALL shouldn't be included in %doc

 - Rpmlint warns about jt9 having executable stack:

executable-stack:
The binary declares the stack as executable.  Executable stack is usually an
error as it is only needed if the code contains GCC trampolines or similar
constructs which uses code on the stack.  One common source for needlessly
executable stack cases are object files built from assembler files which don't
define a proper .note.GNU-stack section.

   You can remove it with: 

BuildRequires:	execstack

   Then below make install:

%make_install
execstack -c %{buildroot}%{_bindir}/jt9


 - There's an issue while installing the package:

Error: Transaction check error:
  file /usr/lib/.build-id/5d/1c3c62276031587a6ac333785ee12f62218a86 conflicts between attempted installs of wsjtx-1.8.0-0.1.rc1.fc28.x86_64 and hamlib-3.1-8.fc28.x86_64
  file /usr/lib/.build-id/d3/602e131e4dc419e24969dd19b48829ff695210 conflicts between attempted installs of wsjtx-1.8.0-0.1.rc1.fc28.x86_64 and hamlib-3.1-8.fc28.x86_64

I am not sure what's causing this, I've asked for help on fedora-devel.

Comment 2 Jaroslav Škarvada 2017-09-03 10:09:15 UTC
(In reply to Robert-André Mauchin from comment #1)
Hi,

thanks for taking the review.

Hopefully all fixed in the rebase:
Spec URL: https://jskarvad.fedorapeople.org/wsjtx/wsjtx.spec
SRPM URL: https://jskarvad.fedorapeople.org/wsjtx/wsjtx-1.8.0-0.2.rc2.fc25.src.rpm

I also reported the CR + LF and exec stack upstream.

Regarding the transaction conflict, for non-debug packages, it worked for me on F25. I guess it maybe some bundling problem. I tried to unbundle everything I have found. It maybe also related to the fact that upstream bundles hamlib fork. I have tried to switch to system hamlib, but there is probably something more.

Comment 3 Robert-André Mauchin 🐧 2017-09-04 14:30:46 UTC
I tried to do a Koji scratch to show you but the problem doesn't happen there. ( https://koji.fedoraproject.org/koji/taskinfo?taskID=21648651 )

Anyway the relevant part of my build.log is there:

++ mingw32-pkg-config libffi --cflags-only-I
++ sed 's|\-I||g'
+ export LIBFFI_INCLUDEDIR=
+ LIBFFI_INCLUDEDIR=

Full log https://gist.github.com/eclipseo/f034ce1c3bdc22b66ecf2e02ffcd055f

Since it doesn't happen in Koji, I think it's a bug on my end, so I accept the package. I don't understand why it happens though since when I run "mingw32-pkg-config libffi --cflags-only-I" in my chroot, it does display the include path.

Comment 4 Robert-André Mauchin 🐧 2017-09-04 14:39:15 UTC
Sorry wrong window.

Comment 5 Jaroslav Škarvada 2017-09-08 20:46:23 UTC
I am on vacation with the radio and I am testing the wsjtx package in the field. So far it has proven well. Regarding the conflict, I am pretty sure it's caused by the rigctl-wsjtx and rigctld-wsjtx which after the build-fix patch applied, is just rename of rigctl and rigctld. Try fixed version:

Spec URL: https://jskarvad.fedorapeople.org/wsjtx/wsjtx.spec
SRPM URL: https://jskarvad.fedorapeople.org/wsjtx/wsjtx-1.8.0-0.3.rc2.fc25.src.rpm

Comment 6 Robert-André Mauchin 🐧 2017-09-10 15:45:17 UTC
I've got build error because you didn't include the rigctl-wsjtx and rigctld-wsjtx binaries into %files.

Anyway, I've still got the error at install:
Error: Transaction check error:
  file /usr/lib/.build-id/01/2abbfd0bab84face20330c556905f12951a638 conflicts between attempted installs of wsjtx-1.8.0-0.3.rc2.fc28.x86_64 and hamlib-3.1-9.fc28.x86_64
  file /usr/lib/.build-id/72/eb0590dacbdfb833fe7f2cbf0345572b3639fb conflicts between attempted installs of wsjtx-1.8.0-0.3.rc2.fc28.x86_64 and hamlib-3.1-9.fc28.x86_64

I don't know how to fix it.

Comment 7 Jaroslav Škarvada 2017-09-14 12:19:00 UTC
(In reply to Robert-André Mauchin from comment #6)
> I've got build error because you didn't include the rigctl-wsjtx and
> rigctld-wsjtx binaries into %files.
> 
> Anyway, I've still got the error at install:
> Error: Transaction check error:
>   file /usr/lib/.build-id/01/2abbfd0bab84face20330c556905f12951a638
> conflicts between attempted installs of wsjtx-1.8.0-0.3.rc2.fc28.x86_64 and
> hamlib-3.1-9.fc28.x86_64
>   file /usr/lib/.build-id/72/eb0590dacbdfb833fe7f2cbf0345572b3639fb
> conflicts between attempted installs of wsjtx-1.8.0-0.3.rc2.fc28.x86_64 and
> hamlib-3.1-9.fc28.x86_64
> 
> I don't know how to fix it.

Hmm, is the compile-fix patch applied? You need up-to-date version of it from the SRPM. It dropped creation of the rigctl* files, not only the packaging in %files section which is in the spec file.

Comment 8 Robert-André Mauchin 🐧 2017-09-14 12:59:17 UTC
You're right, sorry, I had not updtated the patch, only the SPEC. Everything is okay now, package accepted.

Comment 9 Jaroslav Škarvada 2017-09-14 13:05:09 UTC
(In reply to Robert-André Mauchin from comment #8)
> You're right, sorry, I had not updtated the patch, only the SPEC. Everything
> is okay now, package accepted.

Great, thanks.

Btw, I really enjoyed the WSJT/WSPR operation all around the world with the wsjtx package during my vacation (and I even blasted off my 1:1 balun with overpower :).

Comment 10 Gwyn Ciesla 2017-09-18 11:49:34 UTC
(fedrepo-req-admin):  The Pagure repository was created at https://src.fedoraproject.org/rpms/wsjtx

Comment 11 Fedora Update System 2017-09-18 13:22:32 UTC
wsjtx-1.8.0-0.3.rc2.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-c3b4aa18ac

Comment 12 Fedora Update System 2017-09-18 13:42:07 UTC
wsjtx-1.8.0-0.3.rc2.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-bb8ff27428

Comment 13 Fedora Update System 2017-09-18 22:23:18 UTC
wsjtx-1.8.0-0.3.rc2.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-c3b4aa18ac

Comment 14 Fedora Update System 2017-09-19 04:21:57 UTC
wsjtx-1.8.0-0.3.rc2.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-bb8ff27428

Comment 15 Fedora Update System 2017-09-30 06:39:04 UTC
wsjtx-1.8.0-0.3.rc2.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.

Comment 16 Fedora Update System 2017-10-05 22:51:14 UTC
wsjtx-1.8.0-0.3.rc2.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.