On 19/04/2014 17:20, Richard Shaw wrote:
Hi Richard,
On Sat, Apr 19, 2014 at 8:40 AM, Bill Somerville
<g4...@classdesign.com <mailto:g4...@classdesign.com>> wrote:
On 19/04/2014 14:12, Richard Shaw wrote:
Hi Richard,
On Sat, Apr 19, 2014 at 5:56 AM, Bill Somerville
<g4...@classdesign.com <mailto:g4...@classdesign.com>> 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 to those repositories without falling foul of
their strict
entry requirements.
Well, static linking required a bundled library exception to be
made by the Fedora board but as your patches made it upstream
hopefully a new release (or as I'm a hamlib maintainer as well)
can we just patch up to it or do a repository checkout?
As always the problem is Windows :( getting a CMake script that
checks out Hamlib and builds it as part of the CMake script is
rather tricky on Windows (severe friction between Qt and Hamlib),
on other platforms no problem setting it up as an external project
in CMake. I was thinking of putting the Hamlib licence statement
into 'copyright' as a downstream dependency for now. As it stands
right now we can build using the Hamlib master repo but that may
change as a result of beta testing with a wider range of rigs
although my Hamlib fixes have been accepted pretty quickly so far.
Yup, as long as building against system libraries can be forced, I'll
be good. What I really need is an option to prevent kvasd from being
downloaded. Downloading during building is not permitted in Fedora. My
long term plan is to put a version of wsjtx in Fedora without kvasd
and then create a RPM Fusion nonfree package, something like
wsjtx-kvasd, for those users who want to add it.
Yes kvasd is a stumbling block. The CMake download was always a stopgap
and was only really meant as a developer aid IMHO, until a better
solution is implemented.
Here's another possible option:
Have wsjtx (and any other customers of kvasd) download kvasd at run time
and store it in a user directory ($HOME/.local/bin maybe). It doesn't
have to be on the PATH as wsjtx/jt9 have a mechanism for running it from
any directory with an absolute path. It would require an Internet
connection before it could happen which might be an issue for non
connected machines like /P operations (but it would only need to happen
once per user). I believe this would sidestep all the packaging issues
with non-free content. We would need a checksum mechanism to avoid
malicious substitution hacks but that's not tough to implement.
To this end I am working through the WSJT-X CMake/CPack package
generation for Linux with the aim to fully automate package
generation
for Debian and RPM style packages. Richard (KF5OIM) who is
our Fedora
RPM packaging expert tells me that the CMake/CPack tools fall
short of
actually creating a suitable RPM package but nevertheless the
closer we
can get, the smoother the process will be for any downstream
packager
like Richard. With Debian packages I think I can get pretty
close to a
suitable package straight out of the CMake/CPack build.
I've got my spec file setup to build for Fedora and RHEL (and
derivatives)... If we had a Suse person to look at it then I
think we would have the RPM based distro's covered.
Ok, do you think that might be suitable as a custom template spec
file for CPack?
It's got some Fedora/RH specific macros in it right now but those
could be removed/substituted and checked in with the sources.
Ok, I'm not sure if CMake/CPack goes to that level of granularity so we
might need a build option if the RPM packages for Fedora and RedHat are
different for example.
Currently I can run the RPM packaging on Ubuntu by installing 'rpm' (I
assume vice versa is possible too) but I doubt that is a real
possibility because of system library dependency issues. It is handy for
testing the build.
One of the requirements for a Linux package is a man page for
each
executable distributed. This can be reduced to a single man
page that is
shared by each program (for example wsjtx and jt9 could be
written up as
a single application). So has anyone written a man page for
wsjtx? I am
putting man page generation into the build using asciidoc as
a source
format and don't want to duplicate any effort that has been
made elsewhere.
If wsjtx doesn't accept any command line arguments and is a GUI
application then it doesn't have to have a man page on Fedora...
Is Debian different there?
wsjtx does accept command line arguments these days, that's how
you specify multiple instances connected to different rigs.
Ok, got ya. It doesn't respond to "--help" or "-h" and just brings up
the GUI so I wasn't sure. We may need to fix that behavior as well.
Yes, that is on my list. It will get done when I update the man page.
Thanks,
Richard
73
Bill
G4WJS.
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
