GNU bug report logs - #53820
[PATCH] gnu: Add jtdx

Previous Next

Full log

View this message in rfc822 format

From: "Sheng Yang" <styang <at> fastmail.com>
To: "Maxime Devos" <maximedevos <at> telenet.be>, 53820 <at> debbugs.gnu.org
Subject: [bug#53820] [PATCH] gnu: Add jtdx
Date: Sun, 06 Feb 2022 09:20:51 -0600

[Message part 1 (text/plain, inline)]

> Have these patches been submitted upstream?  If so, can we
> add a link to a web page tracking upstreaming progress,
> such that we can determine when 'jdtx-hamlib' can be removed
> in favour of 'hamlib'?
I don't think those patches are submitted upstream. I checked diff between jtdx-hamlib's master with commit 954d70c143a9a0293371d8def3a7300ce3ca68c4 <https://github.com/Hamlib/Hamlib/commit/954d70c143a9a0293371d8def3a7300ce3ca68c4>, which has quite some differences. I am not a developer of either package, so I cannot tell which one/ones is necessary. As it turns out, the configure options seem a lot different from the official one. The following is in the README of jtdx-hamlib:
> $ ../src/configure --prefix=$HOME/hamlib-prefix 
> --disable-shared --enable-static 
> --without-cxx-binding --disable-winradio 
> CFLAGS="-g -O2 -fdata-sections -ffunction-sections" 
> LDFLAGS="-Wl,--gc-sections" 
While in hamlib and wsjtx-hamlib, the build configuration is:
> (arguments
>      `(#:configure-flags '("--disable-static"
>                            "--with-lua-binding"
>                            "--with-python-binding"
>                            "--with-tcl-binding"
>                            "--with-xml-support")))

> Given that it is a fork, doesn't the home page, synopsis and
> description need to be tweaked?
> 
> Why define and not define-public?
I basically followed the existing package wsjtx-hamlib.

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.