Menu
▾
▴
trustedqsl-testing
|
From: Rick M. <k1m...@gm...> - 2022-02-07 00:37:51
|
I have a new release of TQSL being prepared and have a beta test release available. I would appreciate any feedback on this release and the related changes. Two major changes were made for this release to help improve usability. First, the Callsign Certificate tree no longer relies upon obscure icons to denote the state of a callsign certificate. There's an "Active, usable certificates" folder that's displayed expanded. Then there's a "Certificates that are awaiting ARRL approval", "Certificates that have expired", "Certificates replaced with a newer one", and an "invalid, unusable" category. The "usable" folder is expanded by default, the others are not. The second major change pertains to handling and display of Station Locations. I have moved to a "QSL card" motif. When you display a Station Location, the details are displayed with a large Callsign, slightly smaller DXCC entity, then with further details in a smaller font. This same card format is also used when confirming that the right station location was chosen for signing QSOs. Rather than "these will be signed with location HOME", TQSL now shows the complete station location detail for confirmation. The card format now extends to definition of Station Locations as well. Unlike prior versions of TQSL that displayed two different dialog boxes for getting location details (the first for DXCC, zones, gridsquare, etc. - details that applied to all DXCC entities - followed by a second page with entity-specific information when it is needed (for example, State info for US, Province for Canada.) TQSL now collects this data on a single page. Secondary entity information (State, Province) fields appear if appropriate, and do not appear if not. One big advantage of this is that changing those will be reflected immediately in the zones selected. If you're in a US state with only one zone, then selecting the state gets you the right zones. No longer are you told when choosing a State to move back to the first page to fix the zones. Minor changes include: * Addition of a log handling preference to ignore seconds in QSO times * Detection when signing a log if the related callsign certificate is still valid * TQSL displays more information about how to upload a log when "sign and save" is used * Displaying both TQ6 and P12 files when the "open" dialog for a Callsign Certificate is used * Automatically saving the resulting certificate when a TQ6 file is successfully imported * Correct handling of callsign certificate changes when signing a log in "update" mode when that callsign has certificates for multiple DXCC entities. This has been through my regression testing, but as that automates using command line operations. I would very much appreciate any feedback you have on whether or not these changes are helpful. I previewed these on ARRL-LOTW and got generally positive feedback. Installation kits: https://www.rickmurphy.net/lotw/tqsl-2.6.msi - Windows https://www.rickmurphy.net/lotw/tqsl-2.6.pkg - Mac (32/64 bit Intel) https://www.rickmurphy.net/lotw/tqsl-legacy-2.6.pkg - Mac (32-bit Intel, PowerPC). https://www.rickmurphy.net/lotw/tqsl-2.6.tar.gz - Linux/BSD 73, -Rick -- Rick Murphy, D. Sc., CISSP-ISSAP, K1MU/4, Annandale VA USA |
|
From: Greg T. <gd...@le...> - 2022-02-18 18:52:13
Attachments:
signature.asc
|
Rick Murphy <k1m...@gm...> writes: > I have a new release of TQSL being prepared and have a beta test release > available. > https://www.rickmurphy.net/lotw/tqsl-2.6.tar.gz - Linux/BSD Sorry for the delay; I thought this was going to be harder than it was. I have locally updated the pkgsrc package to 2.6 using this as the source tarball, and it builds and packages ok and starting it up and clickong around it looks fine. I did not dig into the specific changes, but it's a good confirmation that there's nothing in the build process that broken on untested systems. My accumulated notes about this package, some redundant with previous comments: The only patch I'm carrying is to force bdb instead of lmdb, because I believe there is some lack of automatic upgrade for users, and that seems more serious than whatever benefit switching brings. But I may be confused on this point. I have set a lot of cmake args about RPATH, which gets me a working package, apparently in a previous go-round when I switched to cmake, but the details have left my head. I have not tried to see which of them are really necessary. (I think RPATH should be set automtically for prefixes which are not in the system's default search path.) But until I determine what's really going on, don't take this as a bug report, just a comment. INSTALL doesn't mention it, but I believe a c++11 compiler is required. I have a note (that I didn't check and which may be out of date) that the build doesn't add --std=c++11 to the compilation lines. I think I had a problem before because pkgsrc only makes available declared languages. There is incorrect use of "test ==" (non-POSIX usage) in osx_createdmg.sh. Not a big deal but it trips a portability check and has to be listed for skipping in the pkgsrc package, and it would just as well to fix anyway. As far as I know, the license isn't OSI or FSF approved. I wonder if Debian has decided to accept it, as "DFSG-free as determined by Debian" is our third approval authority for licenses to avoid requiring the user to configure them as acceptable. What I really mean is: Does Debian put tqsl in "main", "contrib" or "non-free"? 73 de n1dam |
|
From: Rick M. <k1...@ar...> - 2022-02-18 21:46:38
|
On Fri, Feb 18, 2022 at 1:52 PM Greg Troxel <gd...@le...> wrote: > Rick Murphy <k1m...@gm...> writes: > > > I have a new release of TQSL being prepared and have a beta test release > > available. > > https://www.rickmurphy.net/lotw/tqsl-2.6.tar.gz - Linux/BSD > > Sorry for the delay; I thought this was going to be harder than it was. > > I have locally updated the pkgsrc package to 2.6 using this as the > source tarball, and it builds and packages ok and starting it up and > clickong around it looks fine. > > I did not dig into the specific changes, but it's a good confirmation > that there's nothing in the build process that broken on untested > systems. > > My accumulated notes about this package, some redundant with previous > comments: > > The only patch I'm carrying is to force bdb instead of lmdb, because I > believe there is some lack of automatic upgrade for users, and that > seems more serious than whatever benefit switching brings. But I may > be confused on this point. > That's effectively a one-time loss and is a really tough thing to fix, with a simple work-around. If you previously ran TQSL with BerkeleyDB, and now have an updated build with LMDB, then doing an upgrade within TQSL means that you need to build both into the package at least once. Then you can use the BDB code to dump the database and write a new one with LMDB. I prefer LMDB due to licensing reasons. If you just ignore this, which is what I've been doing, then when you update from BDB to LMDB, the only loss is that the record of previously uploaded QSOs is lost. It'll rebuild as you upload, or, more likely, it'll get rebuilt when you restore a backup file. That's the migration: build a tqslbackup.tbk on the BDB version, upgrade to LMDB, then restore the .tbk file. Since TQSL automatically backs this up (and keeps a history of 10 backups), the data is always there for restoration. Finally, if you do nothing, then you get one re-upload of a QSO before it gets recorded in the new database; Logbook will reject any duplicates. Given that set of circumstances, database upgrades are hard and it's easier to just upgrade. My plan for a future TQSL release is to look for a backup file that can be used to restore the upload data whenever the database can't be opened, and restore that. At that point I'm going to remove support for BerkeleyDB and go with only LMDB. > I have set a lot of cmake args about RPATH, which gets me a working > package, apparently in a previous go-round when I switched to cmake, > but the details have left my head. I have not tried to see which of > them are really necessary. (I think RPATH should be set automtically > for prefixes which are not in the system's default search path.) But > until I determine what's really going on, don't take this as a bug > report, just a comment. > I am a complete novice about RPATH. I've had strong feedback that it should never be set, but if I don't set the path then TQSL doesn't work because it cannot find libtqsllib.so. The current CMakeLIsts.txt for tqsl defaults to not setting RPATH. You may need to use "-DTQSL_RPATH" to enable the path to the shared lib to be properly set. > INSTALL doesn't mention it, but I believe a c++11 compiler is > required. I have a note (that I didn't check and which may be out of > date) that the build doesn't add --std=c++11 to the compilation lines. > I think I had a problem before because pkgsrc only makes available > declared languages. > This code doesn't require c++11 but should tolerate a newer C++ compiler. There's only two places where the code cares about the c++ version (src/location.cpp, in a pair of string trimming functions). Both versions of the code are included. > There is incorrect use of "test ==" (non-POSIX usage) in > osx_createdmg.sh. Not a big deal but it trips a portability check and > has to be listed for skipping in the pkgsrc package, and it would just > as well to fix anyway. > Fixed. Doesn't matter for anything but a mac anyway. I guess this shouldn't be "osx_" any longer. > As far as I know, the license isn't OSI or FSF approved. I wonder if > Debian has decided to accept it, as "DFSG-free as determined by > Debian" is our third approval authority for licenses to avoid > requiring the user to configure them as acceptable. What I really > mean is: Does Debian put tqsl in "main", "contrib" or "non-free"? Debian Stretch: $ apt-cache -f search trustedqsl | grep File Filename: pool/main/t/trustedqsl/trustedqsl_2.2.2-1_amd64.deb I think "main". > 73 de n1dam > _______________________________________________ > Trustedqsl-testing mailing list > Tru...@li... > https://lists.sourceforge.net/lists/listinfo/trustedqsl-testing > 73, -Rick -- Rick Murphy, D.Sc., CISSP-ISSAP, K1MU/4, Annandale VA USA |
|
From: Greg T. <gd...@le...> - 2022-02-19 13:53:20
Attachments:
signature.asc
|
Rick Murphy <k1...@ar...> writes:
> On Fri, Feb 18, 2022 at 1:52 PM Greg Troxel <gd...@le...> wrote:
>
>> Rick Murphy <k1m...@gm...> writes:
>>
>> The only patch I'm carrying is to force bdb instead of lmdb, because I
>> believe there is some lack of automatic upgrade for users, and that
>> seems more serious than whatever benefit switching brings. But I may
>> be confused on this point.
>
> That's effectively a one-time loss and is a really tough thing to fix, with
> a simple work-around.
>
> If you previously ran TQSL with BerkeleyDB, and now have an updated build
> with LMDB, then doing an upgrade within TQSL means that you need to build
> both into the package at least once. Then you can use the BDB code to dump
> the database and write a new one with LMDB. I prefer LMDB due to licensing
> reasons.
>
> If you just ignore this, which is what I've been doing, then when you
> update from BDB to LMDB, the only loss is that the record of previously
> uploaded QSOs is lost. It'll rebuild as you upload, or, more likely, it'll
> get rebuilt when you restore a backup file. That's the migration: build a
> tqslbackup.tbk on the BDB version, upgrade to LMDB, then restore the .tbk
> file. Since TQSL automatically backs this up (and keeps a history of 10
> backups), the data is always there for restoration.
>
> Finally, if you do nothing, then you get one re-upload of a QSO before it
> gets recorded in the new database; Logbook will reject any duplicates.
>
> Given that set of circumstances, database upgrades are hard and it's easier
> to just upgrade.
So given that, and that there are fairly few users, I should just switch
to lmdb and there will be a bunch of re-uploads, but no real harm done.
I think you explained before; sorry for not putting that in the makefile
and asking again.
> My plan for a future TQSL release is to look for a backup file that can be
> used to restore the upload data whenever the database can't be opened, and
> restore that. At that point I'm going to remove support for BerkeleyDB and
> go with only LMDB.
I don't see any reason for me to wait to switch pkgsrc, unless you want
to tell me I shouldn't.
>> I have set a lot of cmake args about RPATH, which gets me a working
>> package, apparently in a previous go-round when I switched to cmake,
>> but the details have left my head. I have not tried to see which of
>> them are really necessary. (I think RPATH should be set automtically
>> for prefixes which are not in the system's default search path.) But
>> until I determine what's really going on, don't take this as a bug
>> report, just a comment.
>>
>
> I am a complete novice about RPATH. I've had strong feedback that it
> should never be set, but if I don't set the path then TQSL doesn't work
> because it cannot find libtqsllib.so.
(Assuming an all-ELF world and ignoring Windows for the RPATH discussion.)
The statements that it should *never* be set are just wrong and it's
unreasonable of people to make them.
There are are variety of operating systems, and a variety of packaging
systems. GNU/Linux distributions are a combination of OS and packaging.
For each scheme, there are norms about what should be done with RPATH,
and those norms are different on different systems. The right thing to
do is to follow the norms for the system on which tsql is being built.
Some systems are anti-RPATH and that's their call for those systems.
But a claim from that world that everyone else is wrong and should never
use RPATH is unreasonable and unhelpful.
My impression is that on almost all systems, the standard approach is:
1) When libraries are in /usr/lib or someplace else in the
system-configured default path, there is no need to add RPATH
arguments to the link line, and thus they should be omitted.
/usr/local/lib might or might not be in this category on any
particular system. /usr/lib64, if it exists, is almost certainly in
this category.
2) When an executable links with a library that is not in the default
search path, such as /usr/pkg/lib, /usr/myhamstuff/lib, or any other
user-chosen path, then it's necessary to pass e.g. -R/usr/pkg/lib or
-rpath /usr/pkg/lib to the linker.
2a) Some systems might say that in case 2, you still shouldn't use
rpath and instead you should do something else. I don't know that
this case actually exists, and I don't understand how it could work in
the general case.
On systems like Debian, all packages are built with prefix=/usr, and
thus there should be no -R. On systems like pkgsrc, with /usr/pkg or
/opt/pkg, which are not part of the default path, -R should be used.
A question for people that think "rpath should never be set": Assume
that on a system like Debian I build tqsl from source and configure it
to be in prefix=/usr/foo so that my build will be separate from the
system-provided and system-controlled packages in /usr. So I have
/usr/foo/lib/libtqsllib.so
/usr/foo/bin/tqsl
Am I supposed to use -R in this build? If not, how does
/usr/foo/bin/tqsl find the matching libtqsllib.so?
I really don't know who you are hearing from that there should never be
RPATH set, and what their argument is that my summary is wrong. Until a
convincing explanation is provided (here), my recommendation is not to
listen to them.
> The current CMakeLIsts.txt for tqsl defaults to not setting RPATH. You may
> need to use "-DTQSL_RPATH" to enable the path to the shared lib to be
> properly set.
The pkgsrc package currently has:
# \todo Check/rationalize
CMAKE_ARGS+= -DBDB_PREFIX=${PREFIX}
CMAKE_ARGS+= -DBDB_INCLUDE_DIR=${PREFIX}/include/db5
CMAKE_ARGS+= -DCMAKE_INSTALL_PREFIX=${PREFIX}
CMAKE_ARGS+= -DCMAKE_INSTALL_MANDIR:PATH=${PKGMANDIR}
CMAKE_ARGS+= -DCMAKE_INSTALL_RPATH=${PREFIX}/lib
CMAKE_ARGS+= -DCMAKE_BUILD_WITH_INSTALL_RPATH=TRUE
CMAKE_ARGS+= -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=FALSE
and as I understand cmake, CMAKE_INSTALL_RPATH is the normal approach.
I don't know why TQSL_RPATH is needed vs INSTALL_RPATH but it may well
make sense and I'll look into it.
However, there are really multiple separate things going on:
whether to form the union of rpath args as returned when searching for
dependency libraries (which might be in different prefixes)
whether to add rpath for our prefix's lib (because tsql depends on
libtsqllib.so
whether to use the rpath args above, or omit them
On non-rpath systems, the pkgconfig etc. files for dependencies
shouldn't have rpath. And on systems that want rpath, they should.
So logic that says "add to rpath by default if not /usr/lib or
/usr/lib64" should get things right for almost everybody.
> This code doesn't require c++11 but should tolerate a newer C++ compiler.
> There's only two places where the code cares about the c++ version
> (src/location.cpp, in a pair of string trimming functions). Both versions
> of the code are included.
Thanks, I'll look into this more.
>> There is incorrect use of "test ==" (non-POSIX usage) in
>> osx_createdmg.sh. Not a big deal but it trips a portability check and
>> has to be listed for skipping in the pkgsrc package, and it would just
>> as well to fix anyway.
>
> Fixed. Doesn't matter for anything but a mac anyway. I guess this
> shouldn't be "osx_" any longer.
Thanks.
>> As far as I know, the license isn't OSI or FSF approved. I wonder if
>> Debian has decided to accept it, as "DFSG-free as determined by
>> Debian" is our third approval authority for licenses to avoid
>> requiring the user to configure them as acceptable. What I really
>> mean is: Does Debian put tqsl in "main", "contrib" or "non-free"?
>
> Debian Stretch:
> $ apt-cache -f search trustedqsl | grep File
> Filename: pool/main/t/trustedqsl/trustedqsl_2.2.2-1_amd64.deb
>
> I think "main".
Thanks. I will see about getting the license promoted within pkgsrc to
being treated as free software.
73 de n1dam
|
Thanks for helping keep SourceForge clean.
X