trustedqsl-testing — for use in reporting defects in the TQSL and TQSLCert applications, and in the TrustedQSL library

Re: [Trustedqsl-testing] Beta version of TQSL available for testing

[Rick M. <k1...@ar...>]

On Mon, Feb 24, 2020 at 10:51 AM Walter Fey <dl...@da...> wrote:

> The upload of does not work on openSUSE Leap 15.1.
>
> I tried a simple adi file, exported from XLOG without a "MY_" field, and a
> wsjtx_log.adi written with WSJTX and JTDX with the "my_gridsquare"
> information. I can start the program, do all inputs necessary, press the
> button that only new QSOs shall be uploaded and than nothing is happening
> anymore until I kill the process.
>
Walter,
Is  this a case where you're trying to sign and upload a file exported from
XLOG using tqsl directly, or is this a case where xlog is driving a tqsl
command line to do the upload?

If you're doing this directly using tqsl, a diagnostic log would be helpful.
If you're driving tqsl from XLOG, having the command line details would
also be helpful; ideally add "-t tqsldiag.log" to get a diag log here as
well.
73,
    -Rick

> 73, Walter DL8FCL
>
>
> Am 24.02.20 um 10:23 schrieb Rick Murphy:
>
> Correction - it's 2.5.2, not 2.5.3, so files are here:
> https://www.rickmurphy.net/lotw/tqsl-2.5.2.msi - Windows
> https://www.rickmurphy.net/lotw/tqsl-2.5.2.dmg - OSX 64-bit
> https://www.rickmurphy.net/lotw/tqsl-legacy-2.5.2.dmg - OSX 32-bit legacy
> https://www.rickmurphy.net/lotw/tqsl-2.5.2.tar.gz - Linux/BSD/etc.
>
> 73,
>     -Rick
>
>
> On Sun, Feb 23, 2020 at 9:36 PM Rick Murphy <k1...@ar...> wrote:
>
>> A new version of TQSL is available for testing.
>> I would very much like logger developers to test this release, along with
>> the new features for handling QTH updates from ADIF logs.
>>
>> The primary drive for this release is to allow a log being signed by TQSL
>> to take notice of the "MY_" fields in an ADIF file, using that data to
>> verify or update the Station Location used when signing a log. This will
>> allow operations such as VHF roaming to export things like gridsquares on a
>> per-QSO basis. It will also allow a logger to emit information that can be
>> used to help prevent users from uploading "Zombie" QSOs into Logbook.
>>
>> Fields from ADIF used to validate station location information include
>>
>> MY_CNTY   - County (Secondary Administrative Subdivision)
>> MY_COUNTRY - DXCC Entity (May be overridden by MY_DXCC)
>> MY_CQ_ZONE  - CQ Zone
>> MY_DXCC - DXCC Entity
>> MY_GRIDSQUARE -  Station Grid Square (may be overridden by MY_VUCC_GRIDS)
>> MY_IOTA - IOTA Identifier
>> MY_ITU_ZONE - ITU Zone
>> MY_STATE - State (Primary Adminstrative Subdivision)
>> MY_VUCC_GRIDS - Grid set
>> OPERATOR - Station Callsign
>> STATION_CALLSIGN-  Station Callsign
>> OWNER_CALLSIGN - Station Callsign
>>
>> The "Station Callsign" is chosen from STATION_CALLSIGN (if set),
>> OWNER_CALLSIGN, then OPERATOR. (i.e.OPERATOR has precedence, then OWNER,
>> then STATION).
>>
>> Control of how the QTH data from the ADIF log is handled is either
>> specified by a command line argument or by a TQSL preference.  The "-f" (or
>> --verify) argument can be set to "-f ignore" (ignore ADIF QTH fields), "-f
>> report" (Report on any discrepancies between the ADIF QTH data and the
>> chosen Station Location) or "-f update", which updates the Station Location
>> temporarily.
>>
>> There's a preference setting for log handling, part of a new "Log
>> Handling" preference tab. This preference setting is not used for command
>> line operations. The default in both cases is to report on QTH differences.
>>
>> I expect this capability to be very useful for roaming stations, as well
>> as being of interest to stations using loggers that record Gridsquares,
>> such as WSJT-X.
>>
>> That being said, none of this will have any impact unless logging
>> programs export the QTH info in the ADIF fields above. Please give this a
>> try, as it allows a logger to take better control of what gets uploaded to
>> Logbook. If it works, or doesn't, please send me feedback.
>> Thanks!
>>
>> Files in the usual locations:
>>
>> https://www.rickmurphy.net/lotw/tqsl-2.5.3.msi - Windows
>> https://www.rickmurphy.net/lotw/tqsl-2.5.3.dmg - OSX 64-bit
>> https://www.rickmurphy.net/lotw/tqsl-legacy-2.5.3.msi - OSX 32-bit legacy
>> https://www.rickmurphy.net/lotw/tqsl-2.5.3.tar.gz - Linux/BSD/etc.
>>
>> 73,
>>     -Rick
>> --
>> Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA
>>
>
>
> --
> Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA
>
>
> _______________________________________________
> Trustedqsl-testing mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/trustedqsl-testing
>
> _______________________________________________
> Trustedqsl-testing mailing list
> Tru...@li...
> https://lists.sourceforge.net/lists/listinfo/trustedqsl-testing
>


-- 
Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA

Re: [Trustedqsl-testing] Beta version of TQSL available for testing

[Walter F. <dl...@da...>]

The upload of does not work on openSUSE Leap 15.1.

I tried a simple adi file, exported from XLOG without a "MY_" field, and 
a wsjtx_log.adi written with WSJTX and JTDX with the "my_gridsquare" 
information. I can start the program, do all inputs necessary, press the 
button that only new QSOs shall be uploaded and than nothing is 
happening anymore until I kill the process.

73, Walter DL8FCL


Am 24.02.20 um 10:23 schrieb Rick Murphy:
> Correction - it's 2.5.2, not 2.5.3, so files are here:
> https://www.rickmurphy.net/lotw/tqsl-2.5.2.msi - Windows
> https://www.rickmurphy.net/lotw/tqsl-2.5.2.dmg - OSX 64-bit
> https://www.rickmurphy.net/lotw/tqsl-legacy-2.5.2.dmg - OSX 32-bit legacy
> https://www.rickmurphy.net/lotw/tqsl-2.5.2.tar.gz - Linux/BSD/etc.
>
> 73,
>     -Rick
>
>
> On Sun, Feb 23, 2020 at 9:36 PM Rick Murphy <k1...@ar... 
> <mailto:k1...@ar...>> wrote:
>
>     A new version of TQSL is available for testing.
>     I would very much like logger developers to test this release,
>     along with the new features for handling QTH updates from ADIF logs.
>
>     The primary drive for this release is to allow a log being signed
>     by TQSL to take notice of the "MY_" fields in an ADIF file, using
>     that data to verify or update the Station Location used when
>     signing a log. This will allow operations such as VHF roaming to
>     export things like gridsquares on a per-QSO basis. It will also
>     allow a logger to emit information that can be used to help
>     prevent users from uploading "Zombie" QSOs into Logbook.
>
>     Fields from ADIF used to validate station location information include
>
>     MY_CNTY   - County (Secondary Administrative Subdivision)
>     MY_COUNTRY - DXCC Entity (May be overridden by MY_DXCC)
>     MY_CQ_ZONE  - CQ Zone
>     MY_DXCC - DXCC Entity
>     MY_GRIDSQUARE -  Station Grid Square (may be overridden by
>     MY_VUCC_GRIDS)
>     MY_IOTA - IOTA Identifier
>     MY_ITU_ZONE - ITU Zone
>     MY_STATE - State (Primary Adminstrative Subdivision)
>     MY_VUCC_GRIDS - Grid set
>     OPERATOR - Station Callsign
>     STATION_CALLSIGN-  Station Callsign
>     OWNER_CALLSIGN - Station Callsign
>
>     The "Station Callsign" is chosen from STATION_CALLSIGN (if set),
>     OWNER_CALLSIGN, then OPERATOR. (i.e.OPERATOR has precedence, then
>     OWNER, then STATION).
>
>     Control of how the QTH data from the ADIF log is handled is either
>     specified by a command line argument or by a TQSL preference.  The
>     "-f" (or --verify) argument can be set to "-f ignore" (ignore ADIF
>     QTH fields), "-f report" (Report on any discrepancies between the
>     ADIF QTH data and the chosen Station Location) or "-f update",
>     which updates the Station Location temporarily.
>
>     There's a preference setting for log handling, part of a new "Log
>     Handling" preference tab. This preference setting is not used for
>     command line operations. The default in both cases is to report on
>     QTH differences.
>
>     I expect this capability to be very useful for roaming stations,
>     as well as being of interest to stations using loggers that record
>     Gridsquares, such as WSJT-X.
>
>     That being said, none of this will have any impact unless logging
>     programs export the QTH info in the ADIF fields above. Please give
>     this a try, as it allows a logger to take better control of what
>     gets uploaded to Logbook. If it works, or doesn't, please send me
>     feedback.
>     Thanks!
>
>     Files in the usual locations:
>
>     https://www.rickmurphy.net/lotw/tqsl-2.5.3.msi - Windows
>     https://www.rickmurphy.net/lotw/tqsl-2.5.3.dmg - OSX 64-bit
>     https://www.rickmurphy.net/lotw/tqsl-legacy-2.5.3.msi - OSX 32-bit
>     legacy
>     https://www.rickmurphy.net/lotw/tqsl-2.5.3.tar.gz - Linux/BSD/etc.
>
>     73,
>         -Rick
>     -- 
>     Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA
>
>
>
> -- 
> Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA
>
>
> _______________________________________________
> Trustedqsl-testing mailing list
> Tru...@li...
> https://lists.sourceforge.net/lists/listinfo/trustedqsl-testing

Re: [Trustedqsl-testing] Beta version of TQSL available for testing

[Rick M. <k1...@ar...>]

Correction - it's 2.5.2, not 2.5.3, so files are here:
https://www.rickmurphy.net/lotw/tqsl-2.5.2.msi - Windows
https://www.rickmurphy.net/lotw/tqsl-2.5.2.dmg - OSX 64-bit
https://www.rickmurphy.net/lotw/tqsl-legacy-2.5.2.dmg - OSX 32-bit legacy
https://www.rickmurphy.net/lotw/tqsl-2.5.2.tar.gz - Linux/BSD/etc.

73,
    -Rick


On Sun, Feb 23, 2020 at 9:36 PM Rick Murphy <k1...@ar...> wrote:

> A new version of TQSL is available for testing.
> I would very much like logger developers to test this release, along with
> the new features for handling QTH updates from ADIF logs.
>
> The primary drive for this release is to allow a log being signed by TQSL
> to take notice of the "MY_" fields in an ADIF file, using that data to
> verify or update the Station Location used when signing a log. This will
> allow operations such as VHF roaming to export things like gridsquares on a
> per-QSO basis. It will also allow a logger to emit information that can be
> used to help prevent users from uploading "Zombie" QSOs into Logbook.
>
> Fields from ADIF used to validate station location information include
>
> MY_CNTY   - County (Secondary Administrative Subdivision)
> MY_COUNTRY - DXCC Entity (May be overridden by MY_DXCC)
> MY_CQ_ZONE  - CQ Zone
> MY_DXCC - DXCC Entity
> MY_GRIDSQUARE -  Station Grid Square (may be overridden by MY_VUCC_GRIDS)
> MY_IOTA - IOTA Identifier
> MY_ITU_ZONE - ITU Zone
> MY_STATE - State (Primary Adminstrative Subdivision)
> MY_VUCC_GRIDS - Grid set
> OPERATOR - Station Callsign
> STATION_CALLSIGN-  Station Callsign
> OWNER_CALLSIGN - Station Callsign
>
> The "Station Callsign" is chosen from STATION_CALLSIGN (if set),
> OWNER_CALLSIGN, then OPERATOR. (i.e.OPERATOR has precedence, then OWNER,
> then STATION).
>
> Control of how the QTH data from the ADIF log is handled is either
> specified by a command line argument or by a TQSL preference.  The "-f" (or
> --verify) argument can be set to "-f ignore" (ignore ADIF QTH fields), "-f
> report" (Report on any discrepancies between the ADIF QTH data and the
> chosen Station Location) or "-f update", which updates the Station Location
> temporarily.
>
> There's a preference setting for log handling, part of a new "Log
> Handling" preference tab. This preference setting is not used for command
> line operations. The default in both cases is to report on QTH differences.
>
> I expect this capability to be very useful for roaming stations, as well
> as being of interest to stations using loggers that record Gridsquares,
> such as WSJT-X.
>
> That being said, none of this will have any impact unless logging programs
> export the QTH info in the ADIF fields above. Please give this a try, as it
> allows a logger to take better control of what gets uploaded to Logbook. If
> it works, or doesn't, please send me feedback.
> Thanks!
>
> Files in the usual locations:
>
> https://www.rickmurphy.net/lotw/tqsl-2.5.3.msi - Windows
> https://www.rickmurphy.net/lotw/tqsl-2.5.3.dmg - OSX 64-bit
> https://www.rickmurphy.net/lotw/tqsl-legacy-2.5.3.msi - OSX 32-bit legacy
> https://www.rickmurphy.net/lotw/tqsl-2.5.3.tar.gz - Linux/BSD/etc.
>
> 73,
>     -Rick
> --
> Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA
>


-- 
Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA

[Trustedqsl-testing] Beta version of TQSL available for testing

[Rick M. <k1...@ar...>]

A new version of TQSL is available for testing.
I would very much like logger developers to test this release, along with
the new features for handling QTH updates from ADIF logs.

The primary drive for this release is to allow a log being signed by TQSL
to take notice of the "MY_" fields in an ADIF file, using that data to
verify or update the Station Location used when signing a log. This will
allow operations such as VHF roaming to export things like gridsquares on a
per-QSO basis. It will also allow a logger to emit information that can be
used to help prevent users from uploading "Zombie" QSOs into Logbook.

Fields from ADIF used to validate station location information include

MY_CNTY   - County (Secondary Administrative Subdivision)
MY_COUNTRY - DXCC Entity (May be overridden by MY_DXCC)
MY_CQ_ZONE  - CQ Zone
MY_DXCC - DXCC Entity
MY_GRIDSQUARE -  Station Grid Square (may be overridden by MY_VUCC_GRIDS)
MY_IOTA - IOTA Identifier
MY_ITU_ZONE - ITU Zone
MY_STATE - State (Primary Adminstrative Subdivision)
MY_VUCC_GRIDS - Grid set
OPERATOR - Station Callsign
STATION_CALLSIGN-  Station Callsign
OWNER_CALLSIGN - Station Callsign

The "Station Callsign" is chosen from STATION_CALLSIGN (if set),
OWNER_CALLSIGN, then OPERATOR. (i.e.OPERATOR has precedence, then OWNER,
then STATION).

Control of how the QTH data from the ADIF log is handled is either
specified by a command line argument or by a TQSL preference.  The "-f" (or
--verify) argument can be set to "-f ignore" (ignore ADIF QTH fields), "-f
report" (Report on any discrepancies between the ADIF QTH data and the
chosen Station Location) or "-f update", which updates the Station Location
temporarily.

There's a preference setting for log handling, part of a new "Log Handling"
preference tab. This preference setting is not used for command line
operations. The default in both cases is to report on QTH differences.

I expect this capability to be very useful for roaming stations, as well as
being of interest to stations using loggers that record Gridsquares, such
as WSJT-X.

That being said, none of this will have any impact unless logging programs
export the QTH info in the ADIF fields above. Please give this a try, as it
allows a logger to take better control of what gets uploaded to Logbook. If
it works, or doesn't, please send me feedback.
Thanks!

Files in the usual locations:

https://www.rickmurphy.net/lotw/tqsl-2.5.3.msi - Windows
https://www.rickmurphy.net/lotw/tqsl-2.5.3.dmg - OSX 64-bit
https://www.rickmurphy.net/lotw/tqsl-legacy-2.5.3.msi - OSX 32-bit legacy
https://www.rickmurphy.net/lotw/tqsl-2.5.3.tar.gz - Linux/BSD/etc.

73,
    -Rick
-- 
Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA

Re: [Trustedqsl-testing] changing UL on the fly

[Rick M. <k1...@ar...>]

The next version of TQSL will allow your second solution.

Station location details in the ADIF file (for this example, the
MY_GRIDSQUARE or MY_VUCC_GRIDS) can optionally cause a new "Station
Location" to be created that tracks those when they change.

The other idea you propose is interesting as well, but it needs to be
generalized to allow any part of the QTH details to be passed on the
command line. "--qth GRIDSQUARE=FM18,ITUZ=8,CQZ=5,US_COUNTY=Fairfax"

73,
    -Rick

On Sun, Feb 16, 2020 at 4:59 AM Iztok Saje <izt...@te...> wrote:

> Hello!
>
> With WSJTX promoting Universal Locator Grids, and
> after ARRL Grid Chase in 2018, a lot of us are chasing UL-sqaures.
> Some 5 to 7% of LotW users do not report locator: either they overlooked
> it, or it does not pass ARRL LotW check (those russian oblasts...) or
> they travel a lot.
>
> For travelers, like /MM stations, it is not easy to create location
> profile for every UL sqare visited.
> This is fine for two or three, but not hundred.
>
> First solution:
> if UL square is not defined in the location profile, take the one
> specified in ADIF log file.
> Multiple different locators are acceptable for single file, and they are
> reported to LotW.
> It is up to LOGger creating ADIF to add proper UL square.
>
> Second solution:
> command line option --ul to override UL square defined in the TQSL
> location profile.
> As example: S52D is in JN76. If I spend some time operating from JN75, I
> can upload wth:
>
> tqsl  -a compliant -d --ul JN75 -u -x ~/jn75/wsjtx_log.adi
>
> Please consider this proposal.
>
> Best 73, mni DX
> Iztok, S52D
>
>
> [http://psn.sdn.si/ts/TS_Banner_NEO_oktober_2019_250x170.jpg]
> <
> https://neo.io/info?utm_source=mail_podpis&utm_medium=mail_podpis&utm_campaign=mail_podpis
> >
> Pravni pogoji / Legal disclaimer
> Telekom Slovenije, d.d., Ljubljana <http://www.telekom.si/disclaimer>
>
>
> _______________________________________________
> Trustedqsl-testing mailing list
> Tru...@li...
> https://lists.sourceforge.net/lists/listinfo/trustedqsl-testing
>


-- 
Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA

[Trustedqsl-testing] changing UL on the fly

[Iztok S. <izt...@te...>]

Hello!

With WSJTX promoting Universal Locator Grids, and
after ARRL Grid Chase in 2018, a lot of us are chasing UL-sqaures.
Some 5 to 7% of LotW users do not report locator: either they overlooked it, or it does not pass ARRL LotW check (those russian oblasts...) or
they travel a lot.

For travelers, like /MM stations, it is not easy to create location profile for every UL sqare visited.
This is fine for two or three, but not hundred.

First solution:
if UL square is not defined in the location profile, take the one specified in ADIF log file.
Multiple different locators are acceptable for single file, and they are reported to LotW.
It is up to LOGger creating ADIF to add proper UL square.

Second solution:
command line option --ul to override UL square defined in the TQSL location profile.
As example: S52D is in JN76. If I spend some time operating from JN75, I can upload wth:

tqsl  -a compliant -d --ul JN75 -u -x ~/jn75/wsjtx_log.adi

Please consider this proposal.

Best 73, mni DX
Iztok, S52D


[http://psn.sdn.si/ts/TS_Banner_NEO_oktober_2019_250x170.jpg]
<https://neo.io/info?utm_source=mail_podpis&utm_medium=mail_podpis&utm_campaign=mail_podpis>
Pravni pogoji / Legal disclaimer
Telekom Slovenije, d.d., Ljubljana <http://www.telekom.si/disclaimer>

[Trustedqsl-testing] (no subject)

[VE6LB <ve...@te...>]

Test

[Trustedqsl-testing] Final Beta release for TQSL 2.5

[Rick M. <k1m...@gm...>]

I've been getting a lot of good suggestions for TQSL updates lately,
which has been keeping me from getting 2.5 to a state where I can
consider it "done".
There's a couple of things in the queue, but I'm going to defer them
for a later release.

What's in 2.5 at the moment is the following:
- Callsign Certificate requests for US hams use the ULS database for
verifying the callsign and for providing address information. This
also includes validation for 1x1 callsigns.

- When creating a callsign certificate, the first question is for what
kind of call. Personal, former, club, etc. This makes the rest of the
process easier as defaults can be applied.

- When displaying the list of DXCC entities for a callsign
certificate, the deleted entities are now pushed to the end of the
list. The word "DELETED" in their names can now be localized so it's
easier for non-english speakers to understand.

- When loading a callsign certificate, TQSL no longer asks for a
password for that certificate. This can be re-enabled by a preference
setting.

- The TQSL ADIF editor now emits proper MODE/SUBMODE for modes that
require that.

- TQSL checks for operating as an elevated ("As Administrator")
account on Windows and complains. A user is allowed to permanently
bypass that check.

- References to "Duplicate" QSOs were changed to "previously uploaded".

- When editing a Station Location, do not override the existing data
with ARRL or ULS address data. Those are now only used when station
locations are initially created.

Lots of changes, especially around the callsign certificate processes,
so testing here would be much appreciated.

Files:
Windows: https://www.rickmurphy.net/lotw/tqsl-2.5.msi
OSX: https://www.rickmurphy.net/lotw/tqsl-2.5.dmg
OSX 32-bit: https://www.rickmurphy.net/lotw/tqsl-legacy-2.5.dmg
Linux: https://www.rickmurphy.net/lotw/tqsl-2.5.tar.gz
73,
    -Rick

-- 
Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA

[Trustedqsl-testing] TQSL 2.5 beta test available

[Rick M. <k1m...@gm...>]

A beta test release of TQSL 2.5 is available for testing. This release has
several changes made to eliminate several areas where users can

1. Fix TQSL updates failing on Windows when the user's home directory has
non-ASCII characters.

2. Detect running TQSL "As Administrator" and refuse to open.

3 Verify that the TQSL working directory is writable during startup.

4. Disable prompting for callsign certificate password by default. Add a
preference setting to allow this to be re-enabled if desired.

5. Fix error that was not overriding station location details with the
default
values when editing an existing station location.

6. Fix OSX error where the "Edit Station Location" icon was getting
squashed.

7. Update "Waiting for Callsign Certificate" icon to a clock versus the
slashed
circle. The latter was being interpreted as something broken versus
something
to wait for.

8. Keep track of Callsign Certificate requests and reject attempts to
request
certificates for the same callsign more than 3 times in 24 hours. This limit
will hopefully stop people from mistakenly re-requesting callsign
certificates
repeatedly for the same call because they don't realize that action needs to
be taken by ARRL staff to complete the process.

9. Correct defect that could cause TQSL to crash upon exit while attempting
to
back up.

10. When requesting US 1x1 callsigns, which always require signing, don't
ask for
a certificate type for the request. Require that the user have a valid
certificate for some other call to proceed. Remove the "1x1" callsign option
from the certificate request type page.

As always, any testing of this release is very much appreciated. I'm
waiting on a couple of translations; one those are done, this will be
promoted to a release candidate.

Download links:
https://www.rickmurphy.net/lotw/tqsl-2.5.msi (Windows)
https://www.rickmurphy.net/lotw/tqsl-2.5.dmg (Mac, 64-bit)
https://www.rickmurphy.net/lotw/tqsl-legacy-2.5.dmg (Mac, 32-bit)
https://www.rickmurphy.net/lotw/tqsl-2.5.tar.gz (Linux)
73,
     -Rick


-- 
Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA

Re: [Trustedqsl-testing] TQSL 2.4.4 release candidate available for testing

[Rick M. <k1m...@gm...>]

Duh. Stupid cut-and-paste error for the Linux kit. Correction:

https://www.rickmurphy.net/lotw/tqsl-2.4.4.
<https://www.rickmurphy.net/lotw/tqsl-2.4.4.msi>tar.gz - Linux

73,
    -Rick

On Sun, Mar 10, 2019 at 9:26 PM Rick Murphy <k1m...@gm...> wrote:

> There's a few pending updates for TQSL that I think are ready for prime
> time.
> 1. For Mac users, there's a 64-bit build that fixes the "TQSL is not
> optimized for your Mac" error. The older 32-bit i386/PowerPC build is still
> there (it requires MacOS 10.4 or later) as well as a 64-bit i386/x86_x64
> build (that requires MacOS 10.6 or later).  I'll keep the PPC/10.4 builds
> going as long as I can. Note that this release updates the wxWidgets GUI
> library to wx version 3, so there may be some glitches in the UI.
>
> 2. When defining a station location, there's several cases where the
> state/county (or primary/secondary administrative subdivision) would not be
> set by default. 2.4.4 fixes those.
>
> 3. When creating a callsign certificate request for a new call, TQSL
> didn't provide clear guidance for a certificate for a new callsign. There's
> now a new category for that.
>
> 4. TQSL 2.4.3 should have included support for a Polish localization,
> which I mistakenly omitted. That's now included with 2.4.4.
>
> Please give these a spin, especially the Mac folks.
> https://www.rickmurphy.net/lotw/tqsl-2.4.4.msi - Windows 2000 or later
> https://www.rickmurphy.net/lotw/tqsl-2.4.4.dmg - MacOS 32-bit, i386/ppc
> https://www.rickmurphy.net/lotw/tqsl64-2.4.4.dmg - MacOS 64-bit,
> i386/x86_64
> https://www.rickmurphy.net/lotw/tqsl-2.4.4.msi - Linux
>
> Thanks in advance for any feedback on this new version.
> 73,
>     -Rick
> --
> Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA
>


-- 
Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA

[Trustedqsl-testing] TQSL 2.4.4 release candidate available for testing

[Rick M. <k1m...@gm...>]

There's a few pending updates for TQSL that I think are ready for prime
time.
1. For Mac users, there's a 64-bit build that fixes the "TQSL is not
optimized for your Mac" error. The older 32-bit i386/PowerPC build is still
there (it requires MacOS 10.4 or later) as well as a 64-bit i386/x86_x64
build (that requires MacOS 10.6 or later).  I'll keep the PPC/10.4 builds
going as long as I can. Note that this release updates the wxWidgets GUI
library to wx version 3, so there may be some glitches in the UI.

2. When defining a station location, there's several cases where the
state/county (or primary/secondary administrative subdivision) would not be
set by default. 2.4.4 fixes those.

3. When creating a callsign certificate request for a new call, TQSL didn't
provide clear guidance for a certificate for a new callsign. There's now a
new category for that.

4. TQSL 2.4.3 should have included support for a Polish localization, which
I mistakenly omitted. That's now included with 2.4.4.

Please give these a spin, especially the Mac folks.
https://www.rickmurphy.net/lotw/tqsl-2.4.4.msi - Windows 2000 or later
https://www.rickmurphy.net/lotw/tqsl-2.4.4.dmg - MacOS 32-bit, i386/ppc
https://www.rickmurphy.net/lotw/tqsl64-2.4.4.dmg - MacOS 64-bit, i386/x86_64
https://www.rickmurphy.net/lotw/tqsl-2.4.4.msi - Linux

Thanks in advance for any feedback on this new version.
73,
    -Rick
-- 
Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA

Re: [Trustedqsl-testing] Gentoo Library Mismatch...

[Rick M. <k1...@ar...>]

Apparently my failure to reply here is being interpreted as my not wanting
to have this conversation in public.
So be it.

Bill,
You are having problems with the build of TQSL included with Gentoo. That's
off topic for this list, but I let this question stay as it was possible
that the maintainer of that build was subscribed here. Since nobody has
replied, there's apparently nobody on this list interested in maintaining
that build. The Gentoo project should, if they're like most Linux
distributions, maintain a list of people who supply packages to their
repositories. That's where you need to start.

I'm not interested in maintaining a list of TQSL ports. I'm happy to
support someone having troubles building from source, but that's as far as
it goes.

You'll need to take your questions somewhere that they're on-topic.
73,
    -Rick

On Tue, Dec 11, 2018 at 8:05 PM Bill Scherr IV <bs...@la...> wrote:

>
> Rick -
>
>    Apparently - whoever wrote it, did so without sufficient effort to let
> you all know...
>
>    Therein lies the root cause.  I will inquire @ Gentoo.  Whom shall I
> make aware?
>
> B.
>
> Circa 8:02, 11 Dec 2018, a note, claiming source Rick Murphy <
> k1...@ar...>, was sent to me:
>
> From:   Rick Murphy <k1...@ar...>
> Date sent:      Tue, 11 Dec 2018 08:02:09 -0500
> Subject:        Re: [Trustedqsl-testing] Gentoo Library Mismatch...
> To:     bs...@la...
> Copies to:      facilitate the testing of TQSL <
> tru...@li...>
>
> > Bill,
> > Perhaps this question is best asked on a Gentoo mailing list? You seem to
> > be asking who is responsible for the pre-built TQSL package on Gentoo.
> > (Assuming that's what an "e-build" is.) Whomever that is apparently isn't
> > on this list.
> >
> > 73,
> >     -Rick
> >
> > On Tue, Dec 11, 2018 at 5:51 AM Bill Scherr IV <bs...@la...>
> wrote:
> >
> > >
> > > Ping?
> > >
> > > Circa 8:34, 9 Dec 2018, a note, claiming source Bill Scherr IV <
> > > bs...@la...>, was sent to me:
> > >
> > > From:                   "Bill Scherr IV" <bs...@la...>
> > > To:                     Rick Murphy <k1...@ar...>,
> > >         TQSL Testing <tru...@li...>
> > > Date sent:              Sun, 09 Dec 2018 08:34:03 -0500
> > > Priority:               normal
> > > Subject:                Re: [Trustedqsl-testing] Gentoo Library
> Mismatch...
> > > Send reply to:          bs...@la...,
> > >         TQSL Testing <tru...@li...>
> > >
> > > >
> > > > Rick -
> > > >
> > > >    Thanks for the quick reply.
> > > >
> > > >    Who maintains the Gentoo E-Build?
> > > >
> > > > B.
> > > >
> > > > Circa 21:34, 8 Dec 2018, a note, claiming source Rick Murphy <
> > > tru...@li...>, was sent to me:
> > > >
> > > > From: Rick Murphy <k1...@ar...>
> > > > Date sent:    Sat, 8 Dec 2018 21:34:02 -0500
> > > > To:   bs...@la...,
> > > >               facilitate the testing of TQSL <
> > > tru...@li...>
> > > > Subject:      Re: [Trustedqsl-testing] Gentoo Library Mismatch...
> > > > Send reply to:        TQSL Testing <
> > > tru...@li...>
> > > >
> > > > > Bill,
> > > > > It doesn't seem like you understand the root cause here, and given
> > > that you
> > > > > apparently don't want to, I don't see any value in further
> engagement.
> > > > > 73,
> > > > >     -Rick
> > > > >
> > > > >
> > > > > On Sat, Dec 8, 2018 at 9:12 PM Bill Scherr IV <bs...@la...>
> > > wrote:
> > > > >
> > > > > >
> > > > > > Rick -
> > > > > >
> > > > > >    Thanks again for replying so quick!
> > > > > >
> > > > > >    We are way lost in the weeds here.
> > > > {Bandwidth Snip}
> > > >
> > > > > > ------  TQSL Error Message  ------
> > > > > >  $ Fatal Error: Mismatch between the program and library build
> > > versions
> > > > > > detected.
> > > > > > The library used 3.0 (wchar_t,compiler with C++ ABI 1010,wx
> > > > > > containers,compatible with 2.8),
> > > > > > and your program used 3.0 (wchar_t,compiler with C++ ABI 1011,wx
> > > > > > containers,compatible with 2.8).
> > > > > > ------  End TQSL Error Message  ------
> > > > > >
> > > > > > AND - this is second time I have posted about this error.
> > > > > >
> > > > {Bandwidth Snip}
> > > >
> > > > > > 73 de N1NZL
> > > > > > Bill Scherr, GSEC, GCIA, GCIH
> > > > > >
> > > > > > Circa 8:20, 8 Dec 2018, a note, claiming source Rick Murphy <
> > > > > > tru...@li...>, was sent to me:
> > > > > >
> > > > > > From:   Rick Murphy <k1...@ar...>
> > > >
> > > > {Bandwidth Snip}
> > > >
> > > >
> > > > Bill Scherr IV
> > > > Principal
> > > > bs...@la...
> > > > Lavwas, LLC
> > > > 703-943-0578
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Trustedqsl-testing mailing list
> > > > Tru...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/trustedqsl-testing
> > > >
> > > >
> > >
> > >
> > > Bill Scherr IV
> > > Principal
> > > bs...@la...
> > > Lavwas, LLC
> > > 703-943-0578
> > >
> > >
> >
> > --
> > Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA
> >
>
>
> Bill Scherr IV
> Principal
> bs...@la...
> Lavwas, LLC
> 703-943-0578
>
>

-- 
Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA

[Trustedqsl-testing] TQSL 2.4.3 Release

[Rick M. <k1...@ar...>]

TQSL 2.4.2 introduced a serious defect in the station location editor,
which would cause primary administrative subdivision (State, Province) and
secondary administrative subdivision (County) data to be blank when editing
a station location. TQSL 2.4.3 has a correction for that defect.

As usual, ARRL will pull the new installation kits and make them available
for an automatic update within TQSL. You can also pull the installers from
the locations below.

https://www.rickmurphy.net/lotw/tqsl-2.4.3.msi (Windows)
https://www.rickmurphy.net/lotw/tqsl-2.4.3.dmg (MacOS)
https://www.rickmurphy.net/lotw/tqsl-2.4.3.tar.gz(Linux)

Release notes (combined 2.4.2/2.4.3) attached.
73,
    -Rick
-- 
Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA

Re: [Trustedqsl-testing] Gentoo Library Mismatch...

[Rick M. <k1...@ar...>]

Bill,
Perhaps this question is best asked on a Gentoo mailing list? You seem to
be asking who is responsible for the pre-built TQSL package on Gentoo.
(Assuming that's what an "e-build" is.) Whomever that is apparently isn't
on this list.

73,
    -Rick

On Tue, Dec 11, 2018 at 5:51 AM Bill Scherr IV <bs...@la...> wrote:

>
> Ping?
>
> Circa 8:34, 9 Dec 2018, a note, claiming source Bill Scherr IV <
> bs...@la...>, was sent to me:
>
> From:                   "Bill Scherr IV" <bs...@la...>
> To:                     Rick Murphy <k1...@ar...>,
>         TQSL Testing <tru...@li...>
> Date sent:              Sun, 09 Dec 2018 08:34:03 -0500
> Priority:               normal
> Subject:                Re: [Trustedqsl-testing] Gentoo Library Mismatch...
> Send reply to:          bs...@la...,
>         TQSL Testing <tru...@li...>
>
> >
> > Rick -
> >
> >    Thanks for the quick reply.
> >
> >    Who maintains the Gentoo E-Build?
> >
> > B.
> >
> > Circa 21:34, 8 Dec 2018, a note, claiming source Rick Murphy <
> tru...@li...>, was sent to me:
> >
> > From: Rick Murphy <k1...@ar...>
> > Date sent:    Sat, 8 Dec 2018 21:34:02 -0500
> > To:   bs...@la...,
> >               facilitate the testing of TQSL <
> tru...@li...>
> > Subject:      Re: [Trustedqsl-testing] Gentoo Library Mismatch...
> > Send reply to:        TQSL Testing <
> tru...@li...>
> >
> > > Bill,
> > > It doesn't seem like you understand the root cause here, and given
> that you
> > > apparently don't want to, I don't see any value in further engagement.
> > > 73,
> > >     -Rick
> > >
> > >
> > > On Sat, Dec 8, 2018 at 9:12 PM Bill Scherr IV <bs...@la...>
> wrote:
> > >
> > > >
> > > > Rick -
> > > >
> > > >    Thanks again for replying so quick!
> > > >
> > > >    We are way lost in the weeds here.
> > {Bandwidth Snip}
> >
> > > > ------  TQSL Error Message  ------
> > > >  $ Fatal Error: Mismatch between the program and library build
> versions
> > > > detected.
> > > > The library used 3.0 (wchar_t,compiler with C++ ABI 1010,wx
> > > > containers,compatible with 2.8),
> > > > and your program used 3.0 (wchar_t,compiler with C++ ABI 1011,wx
> > > > containers,compatible with 2.8).
> > > > ------  End TQSL Error Message  ------
> > > >
> > > > AND - this is second time I have posted about this error.
> > > >
> > {Bandwidth Snip}
> >
> > > > 73 de N1NZL
> > > > Bill Scherr, GSEC, GCIA, GCIH
> > > >
> > > > Circa 8:20, 8 Dec 2018, a note, claiming source Rick Murphy <
> > > > tru...@li...>, was sent to me:
> > > >
> > > > From:   Rick Murphy <k1...@ar...>
> >
> > {Bandwidth Snip}
> >
> >
> > Bill Scherr IV
> > Principal
> > bs...@la...
> > Lavwas, LLC
> > 703-943-0578
> >
> >
> >
> > _______________________________________________
> > Trustedqsl-testing mailing list
> > Tru...@li...
> > https://lists.sourceforge.net/lists/listinfo/trustedqsl-testing
> >
> >
>
>
> Bill Scherr IV
> Principal
> bs...@la...
> Lavwas, LLC
> 703-943-0578
>
>

-- 
Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA

Re: [Trustedqsl-testing] Gentoo Library Mismatch...

[Bill S. I. <bs...@la...>]

Ping?

Circa 8:34, 9 Dec 2018, a note, claiming source Bill Scherr IV <bs...@la...>, was sent to me:

From:           	"Bill Scherr IV" <bs...@la...>
To:             	Rick Murphy <k1...@ar...>,
       	TQSL Testing <tru...@li...>
Date sent:      	Sun, 09 Dec 2018 08:34:03 -0500
Priority:       	normal
Subject:        	Re: [Trustedqsl-testing] Gentoo Library Mismatch...
Send reply to:  	bs...@la...,
       	TQSL Testing <tru...@li...>

> 
> Rick -
> 
>    Thanks for the quick reply.
> 
>    Who maintains the Gentoo E-Build?
> 
> B.
> 
> Circa 21:34, 8 Dec 2018, a note, claiming source Rick Murphy <tru...@li...>, was sent to me:
> 
> From:	Rick Murphy <k1...@ar...>
> Date sent:	Sat, 8 Dec 2018 21:34:02 -0500
> To:	bs...@la...,
>        	facilitate the testing of TQSL <tru...@li...>
> Subject:	Re: [Trustedqsl-testing] Gentoo Library Mismatch...
> Send reply to:	TQSL Testing <tru...@li...>
> 
> > Bill,
> > It doesn't seem like you understand the root cause here, and given that you
> > apparently don't want to, I don't see any value in further engagement.
> > 73,
> >     -Rick
> > 
> > 
> > On Sat, Dec 8, 2018 at 9:12 PM Bill Scherr IV <bs...@la...> wrote:
> > 
> > >
> > > Rick -
> > >
> > >    Thanks again for replying so quick!
> > >
> > >    We are way lost in the weeds here. 
> {Bandwidth Snip}
> 
> > > ------  TQSL Error Message  ------
> > >  $ Fatal Error: Mismatch between the program and library build versions
> > > detected.
> > > The library used 3.0 (wchar_t,compiler with C++ ABI 1010,wx
> > > containers,compatible with 2.8),
> > > and your program used 3.0 (wchar_t,compiler with C++ ABI 1011,wx
> > > containers,compatible with 2.8).
> > > ------  End TQSL Error Message  ------
> > >
> > > AND - this is second time I have posted about this error.
> > >
> {Bandwidth Snip}
> 
> > > 73 de N1NZL
> > > Bill Scherr, GSEC, GCIA, GCIH
> > >
> > > Circa 8:20, 8 Dec 2018, a note, claiming source Rick Murphy <
> > > tru...@li...>, was sent to me:
> > >
> > > From:   Rick Murphy <k1...@ar...>
> 
> {Bandwidth Snip}
> 
> 
> Bill Scherr IV
> Principal 
> bs...@la...
> Lavwas, LLC
> 703-943-0578
> 
> 
> 
> _______________________________________________
> Trustedqsl-testing mailing list
> Tru...@li...
> https://lists.sourceforge.net/lists/listinfo/trustedqsl-testing
> 
> 


Bill Scherr IV
Principal 
bs...@la...
Lavwas, LLC
703-943-0578

Re: [Trustedqsl-testing] Gentoo Library Mismatch...

[Bill S. I. <bs...@la...>]

Rick -

   Thanks for the quick reply.

   Who maintains the Gentoo E-Build?

B.

Circa 21:34, 8 Dec 2018, a note, claiming source Rick Murphy <tru...@li...>, was sent to me:

From:	Rick Murphy <k1...@ar...>
Date sent:	Sat, 8 Dec 2018 21:34:02 -0500
To:	bs...@la...,
       	facilitate the testing of TQSL <tru...@li...>
Subject:	Re: [Trustedqsl-testing] Gentoo Library Mismatch...
Send reply to:	TQSL Testing <tru...@li...>

> Bill,
> It doesn't seem like you understand the root cause here, and given that you
> apparently don't want to, I don't see any value in further engagement.
> 73,
>     -Rick
> 
> 
> On Sat, Dec 8, 2018 at 9:12 PM Bill Scherr IV <bs...@la...> wrote:
> 
> >
> > Rick -
> >
> >    Thanks again for replying so quick!
> >
> >    We are way lost in the weeds here. 
{Bandwidth Snip}

> > ------  TQSL Error Message  ------
> >  $ Fatal Error: Mismatch between the program and library build versions
> > detected.
> > The library used 3.0 (wchar_t,compiler with C++ ABI 1010,wx
> > containers,compatible with 2.8),
> > and your program used 3.0 (wchar_t,compiler with C++ ABI 1011,wx
> > containers,compatible with 2.8).
> > ------  End TQSL Error Message  ------
> >
> > AND - this is second time I have posted about this error.
> >
{Bandwidth Snip}

> > 73 de N1NZL
> > Bill Scherr, GSEC, GCIA, GCIH
> >
> > Circa 8:20, 8 Dec 2018, a note, claiming source Rick Murphy <
> > tru...@li...>, was sent to me:
> >
> > From:   Rick Murphy <k1...@ar...>

{Bandwidth Snip}


Bill Scherr IV
Principal 
bs...@la...
Lavwas, LLC
703-943-0578

Re: [Trustedqsl-testing] Gentoo Library Mismatch...

[Rick M. <k1...@ar...>]

Bill,
It doesn't seem like you understand the root cause here, and given that you
apparently don't want to, I don't see any value in further engagement.
73,
    -Rick


On Sat, Dec 8, 2018 at 9:12 PM Bill Scherr IV <bs...@la...> wrote:

>
> Rick -
>
>    Thanks again for replying so quick!
>
>    We are way lost in the weeds here.  I have several Gentoo Boxen, some
> headless, some have consoles attached, others are
> fully graphical workstations.  Obviously, I can pick and place, and GTK is
> fully functional.  TQSL is one of those programs
> that only I will use (nisi protege) - so it needs to go on my primary
> lappy.
>
>    Gentoo does not have version numbers.  It is released daily.  My kernel
> is 4.14.65.  The profile is v17.0 stable.  That is
> about as much of an OS Version available in Gentoo.
>
>    Since ALL of my other programs work in the existing GTK - the problem
> has to be in that interface.  That is the "ebuild" in
> Gentoo talk.  The library and the GUI need to be separately specified
> (forced), though I don't know exactly how to do that.  If
> I did, I would supply a patch.  Obviously, a lot has to be working to get
> this error.
>
>     I am not sure who writes that part of TQSL.  Most ebuild writers pay
> attention to their upstream devs.  I will post the
> error again, to get us back on track...
>
> ------  TQSL Error Message  ------
>  $ Fatal Error: Mismatch between the program and library build versions
> detected.
> The library used 3.0 (wchar_t,compiler with C++ ABI 1010,wx
> containers,compatible with 2.8),
> and your program used 3.0 (wchar_t,compiler with C++ ABI 1011,wx
> containers,compatible with 2.8).
> ------  End TQSL Error Message  ------
>
> AND - this is second time I have posted about this error.
>
>    I do not want to take away from the work that has been done.  Your
> insight below provides valuable clue as to how all of
> this went together.  Little is added with another cabrillo or adif spec,
> or a spec'd testing method to allow both.  I will just
> say Thank You.  You can just be surprised when an interface to sh(1p)
> shows up.
>
>    More people need to realize that identity establishment (Crypto) should
> be a high school requirement...  But that IS a
> different subject.
>
> 73 de N1NZL
> Bill Scherr, GSEC, GCIA, GCIH
>
> Circa 8:20, 8 Dec 2018, a note, claiming source Rick Murphy <
> tru...@li...>, was sent to me:
>
> From:   Rick Murphy <k1...@ar...>
> Date sent:      Sat, 8 Dec 2018 08:20:52 -0500
> To:     bs...@la...,
>         facilitate the testing of TQSL <
> tru...@li...>
> Subject:        Re: [Trustedqsl-testing] Gentoo Library Mismatch...
> Send reply to:  TQSL Testing <tru...@li...>
>
> > On Fri, Dec 7, 2018 at 2:05 PM Bill Scherr IV <bs...@la...>
> wrote:
> >
> > >
> > > Rick -
> > >
> > >    Thanks for the quick reply!  And thank you to everyone else for your
> > > indulgence.
> > >
> > >    I remember posting about this some time ago.  The wxwidgets you
> speak
> > > of are buried in gtk.  It seems you no longer support gtk2.
> > >
> >
> > I think you mean that Gentoo no longer supports gtk2. TQSL depends upon
> > wxWidgets, and wxWidgets depends on GTK. Whether or not your wxWidgets
> > libraries are built against gtk2 or gtk3, it'll work with TQSL.
> > Do you have multiple development libraries for wxGTK on your system?  Can
> > you force use of one or the other? What OS is this, what release? I'll be
> > happy to suggest a working build environment but can't do much other than
> > guess at the cause of your problems without knowing what you're running.
> >
> >    gtk2 WILL go away before gtk3 - I get that.  I just have to add gtk3
> to
> > > participate in ARRLs LoTW.
> > >
> >
> > That doesn't follow. You need a working wxWidgets development environment
> > if you're going to build TQSL. You don't have one. If all else fails,
> use a
> > different OS. :)
> >
> >
> > >    Is there really no way to do crypto in plain ascii?
> > >
> > >    As I see it - TQSL merely signs the file and sends it over http.
> Why
> > > do I need a GUI to do that?  Are we so enamored with
> > > single button computing that we cannot "trust" people to manage their
> own
> > > crypto?
> > >
> >
> > There's an API for signing that's part of TQSL. Some loggers use that. If
> > you don't want to use the API (which is fairly complex), the
> specification
> > of what a signed log looks like is publicly documented (see
> > https://www.rickmurphy.net/trustedqsl.org/ ). It's not just "signing the
> > file" - the spec requires that the QSO details be normalized, and that's
> > what is signed, the normalized form of the QSO details. We "trust" some
> > providers to manage crypto on behalf of users, so they don't have to get
> > bogged down in complications.  But, we've also got to supply enough user
> > interface to allow people to sign their logs without having to pay
> someone
> > else to manage them.
> >
> > There's no requirement to use TQSL to sign/upload a log. If you want to
> > independently write an application to build a GaBBI-format file and
> upload
> > that, go for it. You'll need to write your own certificate handling and
> > station location handling to allow that to work but none of that is
> rocket
> > science. But there's a specification for a reason, which is to ensure
> that
> > the QSO details are accurately recorded. If you do it yourself, you can
> do
> > some things that the spec allows but TQSL does not - for example,
> uploading
> > a single log spanning multiple station locations. SMOP.
> >
> >
> > >    OK - These are development questions.  I don't have time to get
> > > involved in everything.  I am aware of - and have built
> > > processes to establish my identity on the net - meaning crypto.  That
> is
> > > high school algebra.
> > >
> > >    It you teach people to fish - they'll feed themselves.  If you give
> > > them another out - they will depend on you.  And the
> > > rest of us have to add more bloat to play in a game run by the
> > > "establishment".  Hams should be comfortable inside the case.
> > >
> >
> > Are you saying that some random ham that wants to upload logs needs to
> > write their own program that signs their logs versus using TQSL? And if
> > they're not, they're stuck playing some game foisted upon them by LoTW?
> > That's a pretty strange conclusion to me. You're not restrained from
> > building your own signing app, LoTW won't care.
> >
> >    OR...  someone could adjust the e-build to require GTK3.  This is the
> > > right place to suggest that change.
> > >
> >
> > TQSL doesn't require any specific version of GTK, that's a decision made
> at
> > a lower level of your OS.  It just requires a functioning wxWidgets
> install
> > - wxMac, wxGTK, or wxWin. If your distro builds wxGTK against GTK2 but
> then
> > supplies GTK3, then they need to fix their build of wxGTK. IMHO, this is
> > not the right place to discuss that.
> >
> > 73,
> >     -Rick
> > --
> > Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA
> >
>
>
> Bill Scherr IV
> Principal
> bs...@la...
> Lavwas, LLC
> 703-943-0578
>
>
>
> _______________________________________________
> Trustedqsl-testing mailing list
> Tru...@li...
> https://lists.sourceforge.net/lists/listinfo/trustedqsl-testing
>


-- 
Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA

Re: [Trustedqsl-testing] Gentoo Library Mismatch...

[Bill S. I. <bs...@la...>]

Rick -

   Thanks again for replying so quick!  

   We are way lost in the weeds here.  I have several Gentoo Boxen, some headless, some have consoles attached, others are 
fully graphical workstations.  Obviously, I can pick and place, and GTK is fully functional.  TQSL is one of those programs 
that only I will use (nisi protege) - so it needs to go on my primary lappy.  

   Gentoo does not have version numbers.  It is released daily.  My kernel is 4.14.65.  The profile is v17.0 stable.  That is 
about as much of an OS Version available in Gentoo.

   Since ALL of my other programs work in the existing GTK - the problem has to be in that interface.  That is the "ebuild" in 
Gentoo talk.  The library and the GUI need to be separately specified (forced), though I don't know exactly how to do that.  If 
I did, I would supply a patch.  Obviously, a lot has to be working to get this error.

    I am not sure who writes that part of TQSL.  Most ebuild writers pay attention to their upstream devs.  I will post the 
error again, to get us back on track...

------  TQSL Error Message  ------ 
 $ Fatal Error: Mismatch between the program and library build versions detected.
The library used 3.0 (wchar_t,compiler with C++ ABI 1010,wx containers,compatible with 2.8),
and your program used 3.0 (wchar_t,compiler with C++ ABI 1011,wx containers,compatible with 2.8).
------  End TQSL Error Message  ------ 

AND - this is second time I have posted about this error.

   I do not want to take away from the work that has been done.  Your insight below provides valuable clue as to how all of 
this went together.  Little is added with another cabrillo or adif spec, or a spec'd testing method to allow both.  I will just 
say Thank You.  You can just be surprised when an interface to sh(1p) shows up.

   More people need to realize that identity establishment (Crypto) should be a high school requirement...  But that IS a 
different subject.

73 de N1NZL
Bill Scherr, GSEC, GCIA, GCIH

Circa 8:20, 8 Dec 2018, a note, claiming source Rick Murphy <tru...@li...>, was sent to me:

From:	Rick Murphy <k1...@ar...>
Date sent:	Sat, 8 Dec 2018 08:20:52 -0500
To:	bs...@la...,
       	facilitate the testing of TQSL <tru...@li...>
Subject:	Re: [Trustedqsl-testing] Gentoo Library Mismatch...
Send reply to:	TQSL Testing <tru...@li...>

> On Fri, Dec 7, 2018 at 2:05 PM Bill Scherr IV <bs...@la...> wrote:
> 
> >
> > Rick -
> >
> >    Thanks for the quick reply!  And thank you to everyone else for your
> > indulgence.
> >
> >    I remember posting about this some time ago.  The wxwidgets you speak
> > of are buried in gtk.  It seems you no longer support gtk2.
> >
> 
> I think you mean that Gentoo no longer supports gtk2. TQSL depends upon
> wxWidgets, and wxWidgets depends on GTK. Whether or not your wxWidgets
> libraries are built against gtk2 or gtk3, it'll work with TQSL.
> Do you have multiple development libraries for wxGTK on your system?  Can
> you force use of one or the other? What OS is this, what release? I'll be
> happy to suggest a working build environment but can't do much other than
> guess at the cause of your problems without knowing what you're running.
> 
>    gtk2 WILL go away before gtk3 - I get that.  I just have to add gtk3 to
> > participate in ARRLs LoTW.
> >
> 
> That doesn't follow. You need a working wxWidgets development environment
> if you're going to build TQSL. You don't have one. If all else fails, use a
> different OS. :)
> 
> 
> >    Is there really no way to do crypto in plain ascii?
> >
> >    As I see it - TQSL merely signs the file and sends it over http.  Why
> > do I need a GUI to do that?  Are we so enamored with
> > single button computing that we cannot "trust" people to manage their own
> > crypto?
> >
> 
> There's an API for signing that's part of TQSL. Some loggers use that. If
> you don't want to use the API (which is fairly complex), the specification
> of what a signed log looks like is publicly documented (see
> https://www.rickmurphy.net/trustedqsl.org/ ). It's not just "signing the
> file" - the spec requires that the QSO details be normalized, and that's
> what is signed, the normalized form of the QSO details. We "trust" some
> providers to manage crypto on behalf of users, so they don't have to get
> bogged down in complications.  But, we've also got to supply enough user
> interface to allow people to sign their logs without having to pay someone
> else to manage them.
> 
> There's no requirement to use TQSL to sign/upload a log. If you want to
> independently write an application to build a GaBBI-format file and upload
> that, go for it. You'll need to write your own certificate handling and
> station location handling to allow that to work but none of that is rocket
> science. But there's a specification for a reason, which is to ensure that
> the QSO details are accurately recorded. If you do it yourself, you can do
> some things that the spec allows but TQSL does not - for example, uploading
> a single log spanning multiple station locations. SMOP.
> 
> 
> >    OK - These are development questions.  I don't have time to get
> > involved in everything.  I am aware of - and have built
> > processes to establish my identity on the net - meaning crypto.  That is
> > high school algebra.
> >
> >    It you teach people to fish - they'll feed themselves.  If you give
> > them another out - they will depend on you.  And the
> > rest of us have to add more bloat to play in a game run by the
> > "establishment".  Hams should be comfortable inside the case.
> >
> 
> Are you saying that some random ham that wants to upload logs needs to
> write their own program that signs their logs versus using TQSL? And if
> they're not, they're stuck playing some game foisted upon them by LoTW?
> That's a pretty strange conclusion to me. You're not restrained from
> building your own signing app, LoTW won't care.
> 
>    OR...  someone could adjust the e-build to require GTK3.  This is the
> > right place to suggest that change.
> >
> 
> TQSL doesn't require any specific version of GTK, that's a decision made at
> a lower level of your OS.  It just requires a functioning wxWidgets install
> - wxMac, wxGTK, or wxWin. If your distro builds wxGTK against GTK2 but then
> supplies GTK3, then they need to fix their build of wxGTK. IMHO, this is
> not the right place to discuss that.
> 
> 73,
>     -Rick
> -- 
> Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA
> 


Bill Scherr IV
Principal 
bs...@la...
Lavwas, LLC
703-943-0578

Re: [Trustedqsl-testing] Gentoo Library Mismatch...

[Rick M. <k1...@ar...>]

On Fri, Dec 7, 2018 at 2:05 PM Bill Scherr IV <bs...@la...> wrote:

>
> Rick -
>
>    Thanks for the quick reply!  And thank you to everyone else for your
> indulgence.
>
>    I remember posting about this some time ago.  The wxwidgets you speak
> of are buried in gtk.  It seems you no longer support gtk2.
>

I think you mean that Gentoo no longer supports gtk2. TQSL depends upon
wxWidgets, and wxWidgets depends on GTK. Whether or not your wxWidgets
libraries are built against gtk2 or gtk3, it'll work with TQSL.
Do you have multiple development libraries for wxGTK on your system?  Can
you force use of one or the other? What OS is this, what release? I'll be
happy to suggest a working build environment but can't do much other than
guess at the cause of your problems without knowing what you're running.

   gtk2 WILL go away before gtk3 - I get that.  I just have to add gtk3 to
> participate in ARRLs LoTW.
>

That doesn't follow. You need a working wxWidgets development environment
if you're going to build TQSL. You don't have one. If all else fails, use a
different OS. :)


>    Is there really no way to do crypto in plain ascii?
>
>    As I see it - TQSL merely signs the file and sends it over http.  Why
> do I need a GUI to do that?  Are we so enamored with
> single button computing that we cannot "trust" people to manage their own
> crypto?
>

There's an API for signing that's part of TQSL. Some loggers use that. If
you don't want to use the API (which is fairly complex), the specification
of what a signed log looks like is publicly documented (see
https://www.rickmurphy.net/trustedqsl.org/ ). It's not just "signing the
file" - the spec requires that the QSO details be normalized, and that's
what is signed, the normalized form of the QSO details. We "trust" some
providers to manage crypto on behalf of users, so they don't have to get
bogged down in complications.  But, we've also got to supply enough user
interface to allow people to sign their logs without having to pay someone
else to manage them.

There's no requirement to use TQSL to sign/upload a log. If you want to
independently write an application to build a GaBBI-format file and upload
that, go for it. You'll need to write your own certificate handling and
station location handling to allow that to work but none of that is rocket
science. But there's a specification for a reason, which is to ensure that
the QSO details are accurately recorded. If you do it yourself, you can do
some things that the spec allows but TQSL does not - for example, uploading
a single log spanning multiple station locations. SMOP.


>    OK - These are development questions.  I don't have time to get
> involved in everything.  I am aware of - and have built
> processes to establish my identity on the net - meaning crypto.  That is
> high school algebra.
>
>    It you teach people to fish - they'll feed themselves.  If you give
> them another out - they will depend on you.  And the
> rest of us have to add more bloat to play in a game run by the
> "establishment".  Hams should be comfortable inside the case.
>

Are you saying that some random ham that wants to upload logs needs to
write their own program that signs their logs versus using TQSL? And if
they're not, they're stuck playing some game foisted upon them by LoTW?
That's a pretty strange conclusion to me. You're not restrained from
building your own signing app, LoTW won't care.

   OR...  someone could adjust the e-build to require GTK3.  This is the
> right place to suggest that change.
>

TQSL doesn't require any specific version of GTK, that's a decision made at
a lower level of your OS.  It just requires a functioning wxWidgets install
- wxMac, wxGTK, or wxWin. If your distro builds wxGTK against GTK2 but then
supplies GTK3, then they need to fix their build of wxGTK. IMHO, this is
not the right place to discuss that.

73,
    -Rick
-- 
Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA

Re: [Trustedqsl-testing] Gentoo Library Mismatch...

[Bill S. I. <bs...@la...>]

Rick -

   Thanks for the quick reply!  And thank you to everyone else for your indulgence.

   I remember posting about this some time ago.  The wxwidgets you speak of are buried in gtk.  It seems you no longer support 
gtk2.  

   gtk2 WILL go away before gtk3 - I get that.  I just have to add gtk3 to participate in ARRLs LoTW.  

   Is there really no way to do crypto in plain ascii?

   As I see it - TQSL merely signs the file and sends it over http.  Why do I need a GUI to do that?  Are we so enamored with 
single button computing that we cannot "trust" people to manage their own crypto?

   OK - These are development questions.  I don't have time to get involved in everything.  I am aware of - and have built 
processes to establish my identity on the net - meaning crypto.  That is high school algebra.

   It you teach people to fish - they'll feed themselves.  If you give them another out - they will depend on you.  And the 
rest of us have to add more bloat to play in a game run by the "establishment".  Hams should be comfortable inside the case.

   OR...  someone could adjust the e-build to require GTK3.  This is the right place to suggest that change.

73 de N1NZL
B.

Circa 5:59, 6 Dec 2018, a note, claiming source Rick Murphy <tru...@li...>, was sent to me:

From:	Rick Murphy <k1...@ar...>
Date sent:	Thu, 6 Dec 2018 05:59:21 -0500
To:	bs...@la...,
       	facilitate the testing of TQSL <tru...@li...>
Subject:	Re: [Trustedqsl-testing] Gentoo Library Mismatch...
Send reply to:	TQSL Testing <tru...@li...>

> > The library used 3.0 (wchar_t,compiler with C++ ABI 1010,wx
> containers,compatible with 2.8),
> 
> wxWidgets was built with one version of the c++ library, and ...
> 
> > and your program used 3.0 (wchar_t,compiler with C++ ABI 1011,wx
> containers,compatible with 2.8).
> 
> TQSL was built using a later version.  About all you can do is to (1) ask
> your distro to release an updated wxWidgets or (2) statically link against
> wxWidgets.
> You might also be able to downgrade your C++ build environment but that's
> not really practical.
> 
> File a bug report with Gentoo - the proper fix is for them to release a
> version of the wx libraries built against their current compiler suite.
> (This is really the only practical fix.)
> 73,
>     -Rick
> 
> On Thu, Dec 6, 2018 at 1:29 AM Bill Scherr IV <bs...@la...> wrote:
> 
> >
> > OK...
> >
> >    Last time the numbers and strings were different...
> >
> >    I tried compiling with the 7.3.0 and 6.4.0 gcc compilers...  Perhaps a
> > version refresh will do...  Otherwise, help!?!
> >
> > B.
> >
> > -------  error  -------
> > $ tqsl
> > Fatal Error: Mismatch between the program and library build versions
> > detected.
> > The library used 3.0 (wchar_t,compiler with C++ ABI 1010,wx
> > containers,compatible with 2.8),
> > and your program used 3.0 (wchar_t,compiler with C++ ABI 1011,wx
> > containers,compatible with 2.8).
> > Aborted
> > -------  END error  -------
> >
> > -------  version data  -------
> > # emerge tqsl -vp
> >
> > These are the packages that would be merged, in order:
> >
> > Calculating dependencies... done!
> > [ebuild   R   ~] media-radio/tqsl-2.4.1::gentoo  0 KiB
> >
> > Total: 1 package (1 reinstall), Size of downloads: 0 KiB
> > -------  END version data  -------
> >
> >
> > Bill Scherr IV
> > Principal
> > bs...@la...
> > Lavwas, LLC
> > 703-943-0578
> >
> >
> >
> > _______________________________________________
> > Trustedqsl-testing mailing list
> > Tru...@li...
> > https://lists.sourceforge.net/lists/listinfo/trustedqsl-testing
> >
> 
> 
> -- 
> Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA
> 


Bill Scherr IV
Principal 
bs...@la...
Lavwas, LLC
703-943-0578

Re: [Trustedqsl-testing] Gentoo Library Mismatch...

[Rick M. <k1...@ar...>]

> The library used 3.0 (wchar_t,compiler with C++ ABI 1010,wx
containers,compatible with 2.8),

wxWidgets was built with one version of the c++ library, and ...

> and your program used 3.0 (wchar_t,compiler with C++ ABI 1011,wx
containers,compatible with 2.8).

TQSL was built using a later version.  About all you can do is to (1) ask
your distro to release an updated wxWidgets or (2) statically link against
wxWidgets.
You might also be able to downgrade your C++ build environment but that's
not really practical.

File a bug report with Gentoo - the proper fix is for them to release a
version of the wx libraries built against their current compiler suite.
(This is really the only practical fix.)
73,
    -Rick

On Thu, Dec 6, 2018 at 1:29 AM Bill Scherr IV <bs...@la...> wrote:

>
> OK...
>
>    Last time the numbers and strings were different...
>
>    I tried compiling with the 7.3.0 and 6.4.0 gcc compilers...  Perhaps a
> version refresh will do...  Otherwise, help!?!
>
> B.
>
> -------  error  -------
> $ tqsl
> Fatal Error: Mismatch between the program and library build versions
> detected.
> The library used 3.0 (wchar_t,compiler with C++ ABI 1010,wx
> containers,compatible with 2.8),
> and your program used 3.0 (wchar_t,compiler with C++ ABI 1011,wx
> containers,compatible with 2.8).
> Aborted
> -------  END error  -------
>
> -------  version data  -------
> # emerge tqsl -vp
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies... done!
> [ebuild   R   ~] media-radio/tqsl-2.4.1::gentoo  0 KiB
>
> Total: 1 package (1 reinstall), Size of downloads: 0 KiB
> -------  END version data  -------
>
>
> Bill Scherr IV
> Principal
> bs...@la...
> Lavwas, LLC
> 703-943-0578
>
>
>
> _______________________________________________
> Trustedqsl-testing mailing list
> Tru...@li...
> https://lists.sourceforge.net/lists/listinfo/trustedqsl-testing
>


-- 
Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA

[Trustedqsl-testing] Gentoo Library Mismatch...

[Bill S. I. <bs...@la...>]

OK...

   Last time the numbers and strings were different...

   I tried compiling with the 7.3.0 and 6.4.0 gcc compilers...  Perhaps a version refresh will do...  Otherwise, help!?!

B.

-------  error  -------
$ tqsl 
Fatal Error: Mismatch between the program and library build versions detected.
The library used 3.0 (wchar_t,compiler with C++ ABI 1010,wx containers,compatible with 2.8),
and your program used 3.0 (wchar_t,compiler with C++ ABI 1011,wx containers,compatible with 2.8).
Aborted
-------  END error  -------

-------  version data  -------
# emerge tqsl -vp

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ~] media-radio/tqsl-2.4.1::gentoo  0 KiB

Total: 1 package (1 reinstall), Size of downloads: 0 KiB
-------  END version data  -------


Bill Scherr IV
Principal 
bs...@la...
Lavwas, LLC
703-943-0578

Re: [Trustedqsl-testing] TQSL 2.4.2 bug - existing station locations missing state and county. can't be edited

[Ryan N. <ai...@ya...>]

 Sorry about that! I suppose that bug report wasn't quite as clear as the previous one... :-)
The MSI download worked and the Station Locations appear to work fine now. The widgets on the second page of the Edit Station Location dialog are properly populated, and when edits are made, those edits are retained upon a subsequent opening of the Edit Station Location dialog. 
Thanks and 73, Ryan AI6DO


    On Friday, November 30, 2018, 12:27:23 PM PST, Rick Murphy <k1...@ar...> wrote:  
 
 Ah. The DOWNLOAD wasn't working. Please try it again - the files are now in the proper directory.73,    -Rick
On Fri, Nov 30, 2018 at 11:35 AM Ryan Noguchi via Trustedqsl-testing <tru...@li...> wrote:

 Still not working for me. 
73, Ryan AI6DO

    On Friday, November 30, 2018, 8:17:48 AM PST, Björn Ekelund <bj...@ek...> wrote:  
 
 Is it just me or do they still not work?
73,
Björn SM7IUN
Den fre 30 nov. 2018 kl 11:42 skrev Rick Murphy <k1...@ar...>:

Duh.https://www.rickmurphy.net/lotw/tqsl-2.4.3.msihttps://www.rickmurphy.net/lotw/tqsl-2.4.3.dmghttps://www.rickmurphy.net/lotw/tqsl-2.4.3.tar.gz
73,    -Rick

On Fri, Nov 30, 2018 at 1:56 AM Björn Ekelund <bj...@ek...> wrote:

None of the download links works for me.
73,
Björn SM7IUN

Den fre 30 nov. 2018 kl 03:47 skrev Rick Murphy <k1...@ar...>:

I've fixed this defect in a new TQSL release, 2.4.3Available from the usual places (links below). I'll be releasing this on Friday.
https://www.rickmurphy.net/tqsl/tqsl-2.4.3.msihttps://www.rickmurphy.net/tqsl/tqsl-2.4.3.dmghttps://www.rickmurphy.net/tqsl/tqsl-2.4.3.tar.gz
73,    -Rick

On Wed, Nov 28, 2018 at 9:23 PM Ryan Noguchi via Trustedqsl-testing <tru...@li...> wrote:

David AD7DB and I have found that with TQSL 2.4.2, the state and county fields for all of our existing station locations have been reset, i.e., State is now "[none]" and County is blank. They were defined when we created them, but those values are now missing. Furthermore, when I edit the State field, and hit the "Next" and "Finish" buttons, those changes are not retained. 
A quick Google search and a review of the archives on this list and the ARR...@gr... list didn't reveal any mention of this issue. I'd have posted on the latter list, but I haven't been approved yet. 
73, Ryan AI6DO_______________________________________________
Trustedqsl-testing mailing list
Tru...@li...
https://lists.sourceforge.net/lists/listinfo/trustedqsl-testing



-- 
Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA_______________________________________________
Trustedqsl-testing mailing list
Tru...@li...
https://lists.sourceforge.net/lists/listinfo/trustedqsl-testing

_______________________________________________
Trustedqsl-testing mailing list
Tru...@li...
https://lists.sourceforge.net/lists/listinfo/trustedqsl-testing



-- 
Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA_______________________________________________
Trustedqsl-testing mailing list
Tru...@li...
https://lists.sourceforge.net/lists/listinfo/trustedqsl-testing

_______________________________________________
Trustedqsl-testing mailing list
Tru...@li...
https://lists.sourceforge.net/lists/listinfo/trustedqsl-testing
  _______________________________________________
Trustedqsl-testing mailing list
Tru...@li...
https://lists.sourceforge.net/lists/listinfo/trustedqsl-testing



-- 
Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA_______________________________________________
Trustedqsl-testing mailing list
Tru...@li...
https://lists.sourceforge.net/lists/listinfo/trustedqsl-testing
  

Re: [Trustedqsl-testing] TQSL 2.4.2 bug - existing station locations missing state and county. can't be edited

[Björn E. <bj...@ek...>]

Thanks. Now they work.

73

Björn SM7IUN


Den fre 30 nov. 2018 kl 21:27 skrev Rick Murphy <k1...@ar...>:

> Ah. The DOWNLOAD wasn't working.
> Please try it again - the files are now in the proper directory.
> 73,
>     -Rick
>
> On Fri, Nov 30, 2018 at 11:35 AM Ryan Noguchi via Trustedqsl-testing <
> tru...@li...> wrote:
>
>> Still not working for me.
>>
>> 73, Ryan AI6DO
>>
>>
>> On Friday, November 30, 2018, 8:17:48 AM PST, Björn Ekelund <
>> bj...@ek...> wrote:
>>
>>
>> Is it just me or do they still not work?
>>
>> 73,
>>
>> Björn SM7IUN
>>
>> Den fre 30 nov. 2018 kl 11:42 skrev Rick Murphy <k1...@ar...>:
>>
>> Duh.
>> https://www.rickmurphy.net/lotw/tqsl-2.4.3.msi
>> https://www.rickmurphy.net/lotw/tqsl-2.4.3.dmg
>> https://www.rickmurphy.net/lotw/tqsl-2.4.3.tar.gz
>>
>> 73,
>>     -Rick
>>
>>
>> On Fri, Nov 30, 2018 at 1:56 AM Björn Ekelund <bj...@ek...> wrote:
>>
>> None of the download links works for me.
>>
>> 73,
>>
>> Björn SM7IUN
>>
>>
>> Den fre 30 nov. 2018 kl 03:47 skrev Rick Murphy <k1...@ar...>:
>>
>> I've fixed this defect in a new TQSL release, 2.4.3
>> Available from the usual places (links below). I'll be releasing this on
>> Friday.
>>
>> https://www.rickmurphy.net/tqsl/tqsl-2.4.3.msi
>> https://www.rickmurphy.net/tqsl/tqsl-2.4.3.dmg
>> https://www.rickmurphy.net/tqsl/tqsl-2.4.3.tar.gz
>>
>> 73,
>>     -Rick
>>
>>
>> On Wed, Nov 28, 2018 at 9:23 PM Ryan Noguchi via Trustedqsl-testing <
>> tru...@li...> wrote:
>>
>> David AD7DB and I have found that with TQSL 2.4.2, the state and county
>> fields for all of our existing station locations have been reset, i.e.,
>> State is now "[none]" and County is blank. They were defined when we
>> created them, but those values are now missing. Furthermore, when I edit
>> the State field, and hit the "Next" and "Finish" buttons, those changes are
>> not retained.
>>
>> A quick Google search and a review of the archives on this list and the
>> ARR...@gr... list didn't reveal any mention of this issue. I'd
>> have posted on the latter list, but I haven't been approved yet.
>>
>> 73, Ryan AI6DO
>> _______________________________________________
>> Trustedqsl-testing mailing list
>> Tru...@li...
>> https://lists.sourceforge.net/lists/listinfo/trustedqsl-testing
>>
>>
>>
>> --
>> Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA
>> _______________________________________________
>> Trustedqsl-testing mailing list
>> Tru...@li...
>> https://lists.sourceforge.net/lists/listinfo/trustedqsl-testing
>>
>> _______________________________________________
>> Trustedqsl-testing mailing list
>> Tru...@li...
>> https://lists.sourceforge.net/lists/listinfo/trustedqsl-testing
>>
>>
>>
>> --
>> Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA
>> _______________________________________________
>> Trustedqsl-testing mailing list
>> Tru...@li...
>> https://lists.sourceforge.net/lists/listinfo/trustedqsl-testing
>>
>> _______________________________________________
>> Trustedqsl-testing mailing list
>> Tru...@li...
>> https://lists.sourceforge.net/lists/listinfo/trustedqsl-testing
>> _______________________________________________
>> Trustedqsl-testing mailing list
>> Tru...@li...
>> https://lists.sourceforge.net/lists/listinfo/trustedqsl-testing
>>
>
>
> --
> Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA
> _______________________________________________
> Trustedqsl-testing mailing list
> Tru...@li...
> https://lists.sourceforge.net/lists/listinfo/trustedqsl-testing
>

Re: [Trustedqsl-testing] TQSL 2.4.2 bug - existing station locations missing state and county. can't be edited

[Rick M. <k1...@ar...>]

Ah. The DOWNLOAD wasn't working.
Please try it again - the files are now in the proper directory.
73,
    -Rick

On Fri, Nov 30, 2018 at 11:35 AM Ryan Noguchi via Trustedqsl-testing <
tru...@li...> wrote:

> Still not working for me.
>
> 73, Ryan AI6DO
>
>
> On Friday, November 30, 2018, 8:17:48 AM PST, Björn Ekelund <
> bj...@ek...> wrote:
>
>
> Is it just me or do they still not work?
>
> 73,
>
> Björn SM7IUN
>
> Den fre 30 nov. 2018 kl 11:42 skrev Rick Murphy <k1...@ar...>:
>
> Duh.
> https://www.rickmurphy.net/lotw/tqsl-2.4.3.msi
> https://www.rickmurphy.net/lotw/tqsl-2.4.3.dmg
> https://www.rickmurphy.net/lotw/tqsl-2.4.3.tar.gz
>
> 73,
>     -Rick
>
>
> On Fri, Nov 30, 2018 at 1:56 AM Björn Ekelund <bj...@ek...> wrote:
>
> None of the download links works for me.
>
> 73,
>
> Björn SM7IUN
>
>
> Den fre 30 nov. 2018 kl 03:47 skrev Rick Murphy <k1...@ar...>:
>
> I've fixed this defect in a new TQSL release, 2.4.3
> Available from the usual places (links below). I'll be releasing this on
> Friday.
>
> https://www.rickmurphy.net/tqsl/tqsl-2.4.3.msi
> https://www.rickmurphy.net/tqsl/tqsl-2.4.3.dmg
> https://www.rickmurphy.net/tqsl/tqsl-2.4.3.tar.gz
>
> 73,
>     -Rick
>
>
> On Wed, Nov 28, 2018 at 9:23 PM Ryan Noguchi via Trustedqsl-testing <
> tru...@li...> wrote:
>
> David AD7DB and I have found that with TQSL 2.4.2, the state and county
> fields for all of our existing station locations have been reset, i.e.,
> State is now "[none]" and County is blank. They were defined when we
> created them, but those values are now missing. Furthermore, when I edit
> the State field, and hit the "Next" and "Finish" buttons, those changes are
> not retained.
>
> A quick Google search and a review of the archives on this list and the
> ARR...@gr... list didn't reveal any mention of this issue. I'd
> have posted on the latter list, but I haven't been approved yet.
>
> 73, Ryan AI6DO
> _______________________________________________
> Trustedqsl-testing mailing list
> Tru...@li...
> https://lists.sourceforge.net/lists/listinfo/trustedqsl-testing
>
>
>
> --
> Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA
> _______________________________________________
> Trustedqsl-testing mailing list
> Tru...@li...
> https://lists.sourceforge.net/lists/listinfo/trustedqsl-testing
>
> _______________________________________________
> Trustedqsl-testing mailing list
> Tru...@li...
> https://lists.sourceforge.net/lists/listinfo/trustedqsl-testing
>
>
>
> --
> Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA
> _______________________________________________
> Trustedqsl-testing mailing list
> Tru...@li...
> https://lists.sourceforge.net/lists/listinfo/trustedqsl-testing
>
> _______________________________________________
> Trustedqsl-testing mailing list
> Tru...@li...
> https://lists.sourceforge.net/lists/listinfo/trustedqsl-testing
> _______________________________________________
> Trustedqsl-testing mailing list
> Tru...@li...
> https://lists.sourceforge.net/lists/listinfo/trustedqsl-testing
>


-- 
Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA