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

[Trustedqsl-testing] tQSL Crash

[Elsie & G. <te...@te...>]

Using an ADIF I already uploaded with the old tQSL.

First run: on the first Q got a message something like Cert. out of range on line 3.

Tried to sign and upload the same file again and tQSL locked up (not responding).

Was not asked for my private key???

When I created my location, I was able to move on without inputting a grid square.

73,
Gerry VE6LB/VA6XDX
DXCC, VUCC, WAS Card Checker-Southern Alberta
VE/VA6 QSL Bureau Team
(403) 251-0384
ve...@te...
http://www.qsl.net/ve6lb/

Re: [Trustedqsl-testing] tQSL Crash

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

Running a W7/64 bit/Home on a Quad Core.

LB

From: VE6LB 
Sent: Sunday, March 10, 2013 11:13 AM
To: tru...@li... 
Subject: Re: [Trustedqsl-testing] tQSL Crash


Also: using my existing cert.

Gerry

From: Elsie & Gerry 
Sent: Sunday, March 10, 2013 11:11 AM
To: tru...@li... 
Subject: tQSL Crash


Using an ADIF I already uploaded with the old tQSL.

First run: on the first Q got a message something like Cert. out of range on line 3.

Tried to sign and upload the same file again and tQSL locked up (not responding).

Was not asked for my private key???

When I created my location, I was able to move on without inputting a grid square.

73,
Gerry VE6LB/VA6XDX
DXCC, VUCC, WAS Card Checker-Southern Alberta
VE/VA6 QSL Bureau Team
(403) 251-0384
ve...@te...
http://www.qsl.net/ve6lb/


--------------------------------------------------------------------------------
------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
http://p.sf.net/sfu/symantec-dev2dev 


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

Re: [Trustedqsl-testing] TQSL 1.14 release candidate 1

[Robert K. <kc...@gm...>]

> 
> There are many little things that will annoy OS X users. I suspect, without expertise, that many are “features” of wxWidgets.

wxWidgets works fine with OSX and will produce 100% native applications. That said, we have to use (for now, at least) an older version of wxWidgets that only supports the Carbon framework, so they're not as "modern" as they could be. The more important question (to me) is how many annoyances are existing in 1.13, and how many are new. We're certainly trying to fix bugs and annoyances, but we're trying even harder to not introduce any more

> A few examples, so you can judge my level of tolerance:
> 
> • Application names are customarily Capitalized (and meaningful :-)

Certainly. At the moment, it's consistent with the Linux and Windows binaries and shortcuts. *All* platforms should probably have a more obvious naming, and the best way to do this is probably merging the functionality so there's just a "TrustedQSL" and not an arbitrary (to the user) division between tqsl/tqslcert

> • Gatekeeper posts an alert when starting tqsl; after dismissing the alert the main window appears but tqsl isn’t the active app.

I've got it disabled, but I'm not surprised. tqsl isn't signed by an Apple developer key, and it's not likely that it will be for this release, if ever.

> • Mysteriously, sometimes various menu items are disabled. “Quit tqsl” for example.

It would help if you could figure out how to reproduce this. It's probably "supposed" to be disabled whenever a modal dialog is up.

> • Window resizing doesn’t adopt the new “drag any edge” UI.

I'll look into this. It might be impossible to fix for this release given the old wxWidgets version

> • There are are no shortcut keys for any menu items other than Minimize.

This is consistent across all platforms, but adding shortcut keys is a decent idea. It probably won't go into this release, though.

> • There are several places where tqsl “forgets” things that OS X users expect will be remembered; e.g., my choice for log file type in the signing “wizard” file chooser. Another one: The Call-Worked Field Number value reverts to 5 (probably never correct) in the Add Contest window.

> • Specifying Cabrillo information for “less popular contests” is required, without listing which CONTEST names _are_ “popular". So, users are forced to fail: try uploading a Cabrillo log and see what happens. The “popular” contest names are defined in config.xml; why not display them?

Again, same as the above.


> 
> • Now that tqsl munges my uploads to remove duplicates, it really ought to tell me what it did: how many duplicates, how many QSOs uploaded.

It should display this in the output window?

> I tried the command line interface a bit, thinking to use it within my OS X contest logger. It’s not working as described. For example, “./tqsl -h -x” does the following:
> 
> • prints Usage
> • prints “Unknown option ‘h’”
> • starts the UI and opens the Select Station Location for Signing window.

Yeah, the command line options are a little funny. They seem to work alright for normal signing, but some of the combinations don't do what is expected.

73,
-Robert, KC2YWE

Re: [Trustedqsl-testing] tQSL Crash

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

Also: using my existing cert.

Gerry

From: Elsie & Gerry 
Sent: Sunday, March 10, 2013 11:11 AM
To: tru...@li... 
Subject: tQSL Crash


Using an ADIF I already uploaded with the old tQSL.

First run: on the first Q got a message something like Cert. out of range on line 3.

Tried to sign and upload the same file again and tQSL locked up (not responding).

Was not asked for my private key???

When I created my location, I was able to move on without inputting a grid square.

73,
Gerry VE6LB/VA6XDX
DXCC, VUCC, WAS Card Checker-Southern Alberta
VE/VA6 QSL Bureau Team
(403) 251-0384
ve...@te...
http://www.qsl.net/ve6lb/

Re: [Trustedqsl-testing] TQSL 1.14 release candidate 1

[K1GQ <Bill@K1GQ.com>]

I have been unable to break tqsl.app. 

I’m only equipped to test on OS X 10.8.2 (current OS), so that’s not a comprehensive statement.

There are many little things that will annoy OS X users. I suspect, without expertise, that many are “features” of wxWidgets. A few examples, so you can judge my level of tolerance:

• Application names are customarily Capitalized (and meaningful :-)

• Gatekeeper posts an alert when starting tqsl; after dismissing the alert the main window appears but tqsl isn’t the active app.

• Mysteriously, sometimes various menu items are disabled. “Quit tqsl” for example.

• Window resizing doesn’t adopt the new “drag any edge” UI.

• There are are no shortcut keys for any menu items other than Minimize.

• There are several places where tqsl “forgets” things that OS X users expect will be remembered; e.g., my choice for log file type in the signing “wizard” file chooser. Another one: The Call-Worked Field Number value reverts to 5 (probably never correct) in the Add Contest window.

• Specifying Cabrillo information for “less popular contests” is required, without listing which CONTEST names _are_ “popular". So, users are forced to fail: try uploading a Cabrillo log and see what happens. The “popular” contest names are defined in config.xml; why not display them?

• Now that tqsl munges my uploads to remove duplicates, it really ought to tell me what it did: how many duplicates, how many QSOs uploaded.

I tried the command line interface a bit, thinking to use it within my OS X contest logger. It’s not working as described. For example, “./tqsl -h -x” does the following:

• prints Usage
• prints “Unknown option ‘h’”
• starts the UI and opens the Select Station Location for Signing window.

  Bill, K1GQ

[Trustedqsl-testing] Connected

[John E B. <ba...@gm...>]

Signed up for this list.

John K8AJS
ba...@gm...

Re: [Trustedqsl-testing] Linux initial issues

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

On Sat, Mar 9, 2013 at 9:59 PM, iain macdonnell - N6ML <ar...@ds...>wrote:

> On Sat, Mar 9, 2013 at 6:38 PM, Robert KC2YWE <kc...@gm...> wrote:
>
> Yes, looks good. Also verified the ".tq8" extension fix.
>

I initially did a "huh? I just checked in that fix! How did he get it
already?" on this, then realized that you're building from source. :)
73,
    -Rick
-- 
Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA

Re: [Trustedqsl-testing] Linux initial issues

[iain m. - N. <ar...@ds...>]

On Sat, Mar 9, 2013 at 6:38 PM, Robert KC2YWE <kc...@gm...> wrote:
>
> On Mar 9, 2013, at 8:50 PM, Robert KC2YWE <kc...@gm...> wrote:
>
> I just found the cmake code to do this:
> http://www.cmake.org/Wiki/CMake_RPATH_handling#Always_full_RPATH . I'm
> adding it to the tree now; it should fix the problem.
>
>
> This is fixed in the latest HEAD. CMake will patch the RPATH on "make
> install" to be the install path. If you've been affected and are comfortable
> cloning a git repository, feel free to give it a shot

Yes, looks good. Also verified the ".tq8" extension fix.

73,

    ~iain / N6ML

Re: [Trustedqsl-testing] Linux initial issues

[Robert K. <kc...@gm...>]

On Mar 9, 2013, at 9:37 PM, iain macdonnell - N6ML <ar...@ds...> wrote:

> the build scripts should support an
> alternative prefix specified by the builder.

You can use -DCMAKE_INSTALL_PREFIX=…

It's the equivalent to --prefix in a configure script, and similarly it defaults to /usr/local. I've tested it with ~/tqsl-install and it works fine with the rpath. 

> In both cases, the
> binaries should incorporate the runtime linker path to find tqsllib.

I believe rpath is only a hint, and so if the libraries aren't in the rpath (or in some cases even if they are, depending on OS) it will use any found in the normal search paths.

73,
-Robert, KC2YWE

Re: [Trustedqsl-testing] Windows install went smoothly

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

On Sat, Mar 9, 2013 at 8:26 PM, Jim Reisert AD1C <jjr...@al...>wrote:

> I installed RC1 on Windows 7 Pro 64-bit and had no problems.
>
> It was a little disconcerting to NOT be prompted for the output (TQ8)
> file. It must have been written to a temp directory somewhere, but I
> can't find it. Now I'm wondering where the duplicate files "file" is
> kept.
>

If you choose to sign and upload, it's a uniquely named temporary file, but
you shouldn't need to care about where it's stored. Credit to Robert, who
did all of the upload changes.

 I assume then when the station manager performs ITU zone validation,

that it allows multiple valid ITU zones for some states (like MS).
>

Yes. All of the possible valid combinations are encoded in the TQSL
configuration file for each entity and subdivision. Not just what's right
for ITU or CQ, but what pairs are valid for each entity/subdivision.
73,
    -Rick
-- 
Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA

Re: [Trustedqsl-testing] Linux initial issues

[Robert K. <kc...@gm...>]

On Mar 9, 2013, at 8:50 PM, Robert KC2YWE <kc...@gm...> wrote:

> I just found the cmake code to do this: http://www.cmake.org/Wiki/CMake_RPATH_handling#Always_full_RPATH . I'm adding it to the tree now; it should fix the problem.

This is fixed in the latest HEAD. CMake will patch the RPATH on "make install" to be the install path. If you've been affected and are comfortable cloning a git repository, feel free to give it a shot: https://sourceforge.net/p/trustedqsl/tqsl/ . Otherwise it will be in the next RC.

On my system, the command "objdump -x `which tqsl` | grep RPATH" following "make install" shows the expected /usr/local/lib.

73,
-Robert, KC2YWE

Re: [Trustedqsl-testing] Linux initial issues

[iain m. - N. <ar...@ds...>]

On Sat, Mar 9, 2013 at 6:10 PM, Rick Murphy <k1...@ar...> wrote:
> On Sat, Mar 9, 2013 at 8:42 PM, Robert KC2YWE <kc...@gm...> wrote:
>>
>> On Mar 9, 2013, at 6:45 PM, iain macdonnell - N6ML <ar...@ds...> wrote:
>>
>> I don't think you can make assumptions like that. There is no standard
>> (think POSIX) that requires ANY default runtime linker path (that I'm
>> aware of). On Fedora 18 (vanilla installation in a VM that I made
>> specifically for the purpose of testing tQSL), the only "default"
>> linker paths are:
>>
>> [n6ml@localhost ~]$ cat /etc/ld.so.conf
>> include ld.so.conf.d/*.conf
>> [n6ml@localhost ~]$ egrep -v '^#' /etc/ld.so.conf.d/*
>> /etc/ld.so.conf.d/llvm-x86_64.conf:/usr/lib64/llvm
>> /etc/ld.so.conf.d/tracker-x86_64.conf:/usr/lib64/tracker-0.14
>> /etc/ld.so.conf.d/xulrunner-64.conf:/usr/lib64/xulrunner
>> [n6ml@localhost ~]$
>>
>>
>>
>> While it doesn't appear that the linker needs to look anywhere specific,
>> the Filesystem Hierarchy Standard
>> (http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.pdf) states in section
>> 4.8.2 that "Locally installed software must be placed within /usr/local
>> rather than /usr unless it is being installed to replace or upgrade software
>> in /usr." The appropriate place to install libraries from source on Linux is
>> /usr/local/lib, and both Autotools-based and CMake-based build tools default
>> to this location. Given that, I'm surprised that Fedora (and apparently Red
>> Hat based on a quick Googling) doesn't define /usr/local/lib as a default
>> search path.
>>
>> That said, Fedora is certainly a common OS and we absolutely need to
>> support its default behavior. Defining rpath is definitely the right way to
>> do this, so it'll be in the next RC. Thanks for the report.
>>
>> Rick K1MU - I believe you use Fedora? How do you handle this locally?
>>
> There aren't many Linux distributions that bundle TrustedQSL, but Ubuntu
> does have it in their repositories.
> I've tracked changes to TrustedQSL that Ubuntu made, and ensured that those
> fixes made it into the source pool where possible.
> They install the shared library into /lib, so I follow that "convention":
>
> $ ls -l /lib/libtq*
> lrwxrwxrwx 1 root root      19 Jan 16 14:42 /lib/libtqsllib.so ->
> libtqsllib.so.1.0.2
> lrwxrwxrwx 1 root root      19 Jan 16 14:18 /lib/libtqsllib.so.1 ->
> libtqsllib.so.1.0.2
> -rwxr-xr-x 1 root root 1836764 Mar  5 20:00 /lib/libtqsllib.so.1.0.2
>
> That's my local setup, but it's not what we should be doing for the standard
> source pool. We're an application, and should install into /usr/local/lib,
> not /lib. Note that "/lib" doesn't violate the letter of your quote above,
> but it does violate the spirit.
>
> I think we need to continue to put the .so into /usr/local and fix it during
> the link phase. Let distributions decide how they're going to handle this
> based on their policy.

Agreed; when building from source, the default destination prefix
should be /usr/local, but the build scripts should support an
alternative prefix specified by the builder. In both cases, the
binaries should incorporate the runtime linker path to find tqsllib.

73,

    ~iain / N6ML

[Trustedqsl-testing] Reply-To fixed

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

FYI: I've just changed the list configuration so replies go to the list,
not the original poster.
73,
    -Rick
-- 
Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA

Re: [Trustedqsl-testing] Linux initial issues

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

On Sat, Mar 9, 2013 at 8:42 PM, Robert KC2YWE <kc...@gm...> wrote:

> On Mar 9, 2013, at 6:45 PM, iain macdonnell - N6ML <ar...@ds...> wrote:
>
> I don't think you can make assumptions like that. There is no standard
> (think POSIX) that requires ANY default runtime linker path (that I'm
> aware of). On Fedora 18 (vanilla installation in a VM that I made
> specifically for the purpose of testing tQSL), the only "default"
> linker paths are:
>
> [n6ml@localhost ~]$ cat /etc/ld.so.conf
> include ld.so.conf.d/*.conf
> [n6ml@localhost ~]$ egrep -v '^#' /etc/ld.so.conf.d/*
> /etc/ld.so.conf.d/llvm-x86_64.conf:/usr/lib64/llvm
> /etc/ld.so.conf.d/tracker-x86_64.conf:/usr/lib64/tracker-0.14
> /etc/ld.so.conf.d/xulrunner-64.conf:/usr/lib64/xulrunner
> [n6ml@localhost ~]$
>
>
>
> While it doesn't appear that the linker needs to look anywhere specific,
> the Filesystem Hierarchy Standard (
> http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.pdf) states in
> section 4.8.2 that "Locally installed software must be placed
> within /usr/local rather than /usr unless it is being installed to replace
> or upgrade software in /usr." The appropriate place to install libraries
> from source on Linux is /usr/local/lib, and both Autotools-based and
> CMake-based build tools default to this location. Given that, I'm surprised
> that Fedora (and apparently Red Hat based on a quick Googling) doesn't
> define /usr/local/lib as a default search path.
>
> That said, Fedora is certainly a common OS and we absolutely need to
> support its default behavior. Defining rpath is definitely the right way to
> do this, so it'll be in the next RC. Thanks for the report.
>
> Rick K1MU - I believe you use Fedora? How do you handle this locally?
>
> There aren't many Linux distributions that bundle TrustedQSL, but Ubuntu
does have it in their repositories.
I've tracked changes to TrustedQSL that Ubuntu made, and ensured that those
fixes made it into the source pool where possible.
They install the shared library into /lib, so I follow that "convention":

$ ls -l /lib/libtq*
lrwxrwxrwx 1 root root      19 Jan 16 14:42 /lib/libtqsllib.so ->
libtqsllib.so.1.0.2
lrwxrwxrwx 1 root root      19 Jan 16 14:18 /lib/libtqsllib.so.1 ->
libtqsllib.so.1.0.2
-rwxr-xr-x 1 root root 1836764 Mar  5 20:00 /lib/libtqsllib.so.1.0.2

That's my local setup, but it's not what we should be doing for the
standard source pool. We're an application, and should install into
/usr/local/lib, not /lib. Note that "/lib" doesn't violate the letter of
your quote above, but it does violate the spirit.

I think we need to continue to put the .so into /usr/local and fix it
during the link phase. Let distributions decide how they're going to handle
this based on their policy.
73,
    -Rick

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

Re: [Trustedqsl-testing] Linux initial issues

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

On Sat, Mar 9, 2013 at 8:42 PM, Robert KC2YWE <kc...@gm...> wrote:

> On Mar 9, 2013, at 6:45 PM, iain macdonnell - N6ML <ar...@ds...> wrote:
>
> I don't think you can make assumptions like that. There is no standard
> (think POSIX) that requires ANY default runtime linker path (that I'm
> aware of). On Fedora 18 (vanilla installation in a VM that I made
> specifically for the purpose of testing tQSL), the only "default"
> linker paths are:
>
> [n6ml@localhost ~]$ cat /etc/ld.so.conf
> include ld.so.conf.d/*.conf
> [n6ml@localhost ~]$ egrep -v '^#' /etc/ld.so.conf.d/*
> /etc/ld.so.conf.d/llvm-x86_64.conf:/usr/lib64/llvm
> /etc/ld.so.conf.d/tracker-x86_64.conf:/usr/lib64/tracker-0.14
> /etc/ld.so.conf.d/xulrunner-64.conf:/usr/lib64/xulrunner
> [n6ml@localhost ~]$
>
>
>
> While it doesn't appear that the linker needs to look anywhere specific,
> the Filesystem Hierarchy Standard (
> http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.pdf) states in
> section 4.8.2 that "Locally installed software must be placed
> within /usr/local rather than /usr unless it is being installed to replace
> or upgrade software in /usr." The appropriate place to install libraries
> from source on Linux is /usr/local/lib, and both Autotools-based and
> CMake-based build tools default to this location. Given that, I'm surprised
> that Fedora (and apparently Red Hat based on a quick Googling) doesn't
> define /usr/local/lib as a default search path.
>
> That said, Fedora is certainly a common OS and we absolutely need to
> support its default behavior. Defining rpath is definitely the right way to
> do this, so it'll be in the next RC. Thanks for the report.
>
> Rick K1MU - I believe you use Fedora? How do you handle this locally?
>

There aren't many Linux distributions that bundle TrustedQSL, but Ubuntu
does have it in their repositories.
I've tracked changes to TrustedQSL that Ubuntu made, and ensured that those
fixes made it into the source pool where possible.
They install the shared library into /lib, so I follow that "convention":

$ ls -l /lib/libtq*
lrwxrwxrwx 1 root root      19 Jan 16 14:42 /lib/libtqsllib.so ->
libtqsllib.so.1.0.2
lrwxrwxrwx 1 root root      19 Jan 16 14:18 /lib/libtqsllib.so.1 ->
libtqsllib.so.1.0.2
-rwxr-xr-x 1 root root 1836764 Mar  5 20:00 /lib/libtqsllib.so.1.0.2

That's my local setup, but it's not what we should be doing for the
standard source pool. We're an application, and should install into
/usr/local/lib, not /lib. Note that "/lib" doesn't violate the letter of
your quote above, but it does violate the spirit.

I think we need to continue to put the .so into /usr/local and fix it
during the link phase. Let distributions decide how they're going to handle
this based on their policy.
73,
    -Rick
-- 
Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA

Re: [Trustedqsl-testing] Zone validation

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

On Sat, Mar 9, 2013 at 8:27 PM, Jim Reisert AD1C <jjr...@al...>wrote:

> If someone installs and runs the new program, but their zones were
> backwards from the past, will the new program warn them to fix the
> problem?  I.e. is the station location re-validated for consistency
> each time the program is run?
>

Yes. If you try to use a location with bad (for example, reversed) zones,
you'll be warned that they're wrong before you sign your log.  If you
ignore the error and sign anyway, the bad data is now ignored.
If you edit a location with bad zones, you'll get an error message telling
you about the errors. The location editor only allows you to choose from
zone values that make sense - for example, if you're in the US, you can
only chose ITU zones 6, 7, or 8, and you can only choose CQ zones 3, 4, or
5. If you pick a combination that doesn't make sense (ITU zone 8 and CQ
zone 3, for example), you'll get an error message. If you then select a
state, then only zones valid for that state (or province, oblast) are
acceptable. I can't pick ITU 8, CQ 4 for my Virginia QTH since only 8 and 5
are valid. You can always choose "None" if you don't like being forced to
make valid choices.

The update doesn't do anything to "automatically" fix location data. We
could flip the zone selections, for example, to see if they're right if
reversed, then fix them, but I don't think it's our job to make those kind
of choices for users. We won't let them get it wrong any longer, though.

(Full disclosure: my first uploads to LoTW had the zones reversed. I'm
quite aware of the fact that it's easy to get wrong.)
73,
    -Rick
 --
Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA

Re: [Trustedqsl-testing] Linux initial issues

[Robert K. <kc...@gm...>]

On Mar 9, 2013, at 8:11 PM, Rick Murphy <k1...@ar...> wrote:

> That would be "-rpath=${CMAKE_INSTALL_PREFIX}/lib", which will work on Linux as well as OS X.
> Or, we could have the installer put the .so in /lib or /usr/lib - but I prefer adding the -rpath to the LDFLAGS.

I just found the cmake code to do this: http://www.cmake.org/Wiki/CMake_RPATH_handling#Always_full_RPATH . I'm adding it to the tree now; it should fix the problem.

It's contrary to the Filesystem Hierarchy Standard to install local programs anywhere other than /usr/local, so you're right - we shouldn't do that. 

As for OSX, setting rpath will work fine if anybody 'make install's, which is fine for personal use, but for the .app bundles we create, we have to set the rpath to a bundle-relative search path anyway. This is handled with the install_name_tool in the createdmg script.

73,
-Robert, KC2YWE

[Trustedqsl-testing] Zone validation

[Jim R. A. <jjr...@al...>]

If someone installs and runs the new program, but their zones were
backwards from the past, will the new program warn them to fix the
problem?  I.e. is the station location re-validated for consistency
each time the program is run?

-- 
Jim Reisert AD1C, <jjr...@al...>, http://www.ad1c.us

[Trustedqsl-testing] Windows install went smoothly

[Jim R. A. <jjr...@al...>]

I installed RC1 on Windows 7 Pro 64-bit and had no problems.

It was a little disconcerting to NOT be prompted for the output (TQ8)
file. It must have been written to a temp directory somewhere, but I
can't find it. Now I'm wondering where the duplicate files "file" is
kept.

I'm glad you fixed the behavior of double-clicking on the station location.

I assume then when the station manager performs ITU zone validation,
that it allows multiple valid ITU zones for some states (like MS).

In all, a pleasant experience. It's nice not to have to load into LoTW
to perform the upload.  And a QSO I had this morning with PE2HD is
already confirmed! Maybe I can even get W1JR to run this himself
without my having to do it for him.

I'll have a more interesting test case soon.  Using Rick Murphy's
program, I recently downloaded all of my QSOs from the LoTW server. I
am going to compare (programatically) with my log and determine which
QSOs were lost on upload, then upload them again. This will cover
several callsigns and QTH's.  Should be fun.

-- 
Jim Reisert AD1C, <jjr...@al...>, http://www.ad1c.us

Re: [Trustedqsl-testing] Linux initial issues

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

On Sat, Mar 9, 2013 at 5:41 PM, iain macdonnell - N6ML <ar...@ds...>wrote:

> I managed to get 1.14 built on Fedora 18 (after working through the
> obligatory plethora of -devel package dependencies). I should note
> that I don't normally run tQSL on Linux, so these may not be new
> issues.
>
> 1) The tqsl and tqslcert binaries do not have the path to
> libtqsllib.so in their runtime linker path, so I had to add
> "/usr/local/lib" to LD_LIBRARY_PATH to get them to run. I'm not
> familiar with cmake, so can't suggest a quick fix (usually including
> "-R..." in LDFLAGS will do it). Maybe I'll look into it later.
>

That would be "-rpath=${CMAKE_INSTALL_PREFIX}/lib", which will work on
Linux as well as OS X.
Or, we could have the installer put the .so in /lib or /usr/lib - but I
prefer adding the -rpath to the LDFLAGS.

2) The default output filename doesn't include the ".tq8" suffix -
> e.g. I signed "sync.adi" and accepted the default output filename (the
> drop-down menu in the "Select file to write to" dialog shows "TQSL
> compressed data files (*.tq8)"), but I ended up with a file named just
> "sync" - expected "sync.tq8"
>

That's a defect that's been there for quite a while. I've fixed it for the
final 1.14 release.
Thanks for the reports.
73,
    -Rick

[Trustedqsl-testing] Windows uninstall

[iain m. - N. <ar...@ds...>]

Minor issue with the MSI; after uninstalling, it instructs Notepad to
open "quick.txt", which no longer exists.

73,

    ~iain / N6ML

[Trustedqsl-testing] Linux initial issues

[iain m. - N. <ar...@ds...>]

I managed to get 1.14 built on Fedora 18 (after working through the
obligatory plethora of -devel package dependencies). I should note
that I don't normally run tQSL on Linux, so these may not be new
issues.

1) The tqsl and tqslcert binaries do not have the path to
libtqsllib.so in their runtime linker path, so I had to add
"/usr/local/lib" to LD_LIBRARY_PATH to get them to run. I'm not
familiar with cmake, so can't suggest a quick fix (usually including
"-R..." in LDFLAGS will do it). Maybe I'll look into it later.

2) The default output filename doesn't include the ".tq8" suffix -
e.g. I signed "sync.adi" and accepted the default output filename (the
drop-down menu in the "Select file to write to" dialog shows "TQSL
compressed data files (*.tq8)"), but I ended up with a file named just
"sync" - expected "sync.tq8"

73,

    ~iain / N6ML

Re: [Trustedqsl-testing] VVV TEST de N6ML

[Michael K. K. <k1...@ar...>]

On 3/9/2013 3:21 PM, iain macdonnell - N6ML wrote:
> QRL?

QRV

[Trustedqsl-testing] (no subject)

[Joe S. W. <w4...@su...>]

-- 

73,

   ... Joe, W4TV

[Trustedqsl-testing] VVV TEST de N6ML

[iain m. - N. <ar...@ds...>]

QRL?