You can subscribe to this list here.
2013 |
Jan
|
Feb
|
Mar
(221) |
Apr
(14) |
May
(49) |
Jun
(9) |
Jul
(51) |
Aug
(15) |
Sep
(28) |
Oct
(2) |
Nov
(10) |
Dec
(5) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2014 |
Jan
(49) |
Feb
(8) |
Mar
(10) |
Apr
(7) |
May
(1) |
Jun
(2) |
Jul
(9) |
Aug
|
Sep
|
Oct
(4) |
Nov
(4) |
Dec
(1) |
2015 |
Jan
(8) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(8) |
Sep
(1) |
Oct
|
Nov
|
Dec
(8) |
2016 |
Jan
|
Feb
(10) |
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
(8) |
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
(5) |
Mar
(6) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(1) |
Nov
(17) |
Dec
(11) |
2019 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
2020 |
Jan
|
Feb
(15) |
Mar
|
Apr
(2) |
May
(2) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
(6) |
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
(3) |
Dec
(16) |
2022 |
Jan
|
Feb
(6) |
Mar
(6) |
Apr
|
May
(2) |
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(13) |
Oct
|
Nov
|
Dec
|
2024 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Greg T. <gd...@le...> - 2022-02-19 13:53:20
|
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 |
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-18 18:52:13
|
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: Richard S. <hob...@gm...> - 2022-02-12 02:40:16
|
FB, fixed a problem I had with the first beta. Thanks, Richard KF5OIM |
From: Rick M. <k1...@ar...> - 2022-02-12 00:51:51
|
I've published a -beta2 update to TQSL 2.6. Updates as before, plus a couple of corrections. One has to do with handling station location definitions when a single callsign has multiple DXCC entities, one with and one without a primary administrative subdivision. The case here was a call with valid certs for Alaska and USA. Moving from "DXCC=none" to DXCC=USA and state=anything didn't set the ITU/CQ zones to the values for that state. Minor, but wrong. The other change allows loggers using Update mode (-f=update) to omit a station location entirely. The rest of the 2.6 changes below. As always, feedback is greatly appreciated. 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: 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: Richard S. <hob...@gm...> - 2021-12-20 15:30:26
|
Also, it's not necessary since CMake 2.8.12 seems to work fine, but I would recommend installing the cmake3 package from Fedora EPEL for a MUCH more modern version. Works the same except the binary is renamed to cmake3. Thanks, Richard |
From: Richard S. <hob...@gm...> - 2021-12-20 15:19:53
|
Ok, not quoting this time, too much to sort through :) I installed a CentOS 7 VM and assuming you tried the modifications that are in current master I see the problem, GNUInstallDirs isn't magic, the install locations need to be updated as well in src/CMakeLists.txt ${CMAKE_INSTALL_LIBDIR} ${CMAKE_INSTALL_DATADIR} ${CMAKE_INSTALL_INCLUDEDIR} respectively. I would have provided a git diff but I installed the VM to command line only and apparently copy paste doesn't work with Gnome Boxes in that instance, however, I can do so if helpful but it's a pretty trivial change. This would also allow the end user to override the install location and not just the prefix if desired. With those changes I checked src/cmake_install.cmake and lib64 was found as expected. Thanks, Richard |
From: Rick M. <k1...@ar...> - 2021-12-20 14:44:14
|
On Mon, Dec 20, 2021 at 9:32 AM Greg Troxel <gd...@le...> wrote: > > Rick Murphy <k1...@ar...> writes: > > > [Sorry, this draft apparently has been stalled for some time unsent,[ > > no worries, everybody is busy > > > I accepted the patches here, removed the RPATH setting, removed the > setting > > for library path, and added an include for GNUInstallPaths, all of which > I > > assumed would make this a distribution responsibility. > > I tried to point out when I saw the patches that, while sensible in the > environment they were for, they would break most (in a general sense) > installs, working only for installs into the default prefix on systems > that don't use RPATH (which may be most installs on most computers by %, > but it's still narrow over the set of configurations). > > > Built a tar.gz and started down my list of VMs running various Linux > > distributions. > > Certainly you can test what you can test, but I tried to say earlier and > didn't seem to succeed: All the world is not Linux. (Besides windows > and mac) tqsl should work on any system meeting POSIX and for which the > prereqs are available. It has been working fine on NetBSD, for example, > perhaps with a bit of cmake patching, and I would expect it works on the > others BSDs and even on illumos, with minor effort. I have been > regularly testing and updating pkgsrc as releases happen for a number of > years, and I run tqsl on NetBSD for log upload. I just don't say > anything because almost always it builds fine. > > In addition, the earlier discussion has been focused on installs into > the default prefix of /usr. While some packaging systems (typical on > GNU/Linux variants) do that, some don't, and users who build tqsl > themselves will almost always use a non-default prefix. So dropping > RPATH setting always is basically wrong. It is reasonable to omit RPATH > when the libdir is known to be a system libdir that is searched without > RPATH. > > I'm glad to see you testing with /usr/local. If /usr/local/lib64 is in > the default search path, though, I suggest you test with /usr/tqsl as > the prefix, or /usr/foo or something else. tqsl should work for that > build too, and with the RPATH stuff taken out I bet it will not. > > > The VERY FIRST TRY failed. CentOS 7, It installed libtqsllib.so into > > /usr/local/lib/ and tqsl couldn't be activated because that library > could > > not be found (worked when moved to /lib64). > > Presumably you will back out this change then. You have encountered a > problem I expected from reading the patch. > > > I'm still asking for help here. People seem to be implying that > including > > GNUInstallPaths just fixes these library dependent issues, but I'm not > sure > > what to do when trying this runs right into an error. > > I think the only reasonable path forward is to understand multiple > things and design a plan based on that. I think it's > > have a way to find out if the system puts libs in /lib or /lib64. As > I understand it, lib64 is used on some but not all GNU/Linux systems > on x86_64 computers, but not on other CPU types. Or perhaps also on > arm64 (and sparc64, to the extent anything still supports that). > lib64 is never used on NetBSD; lib is always for native libs. I would > think Gnuinstallpaths would figure this out, or there'd be some other > direct support in cmake, as every single program needs to accomodate > this variation in where libs belong. Perhaps, this can be conditional > on the existence of /usr/lib64 if there isn't a better way. > > Set RPATH unless the configured libdir matches /usr/lib or /usr/lib64 > (if we found out that the system is of the lib64 persuasion). Or > perhaps "set RPATH unless prefix is /usr" is simpler and good enough, > and on refletion I lean to it. > > The first point is somewhat difficult, and the second should be fairly > easy. > > Can someone comment in more detail on the lib64 convention on various > GNU/Linux systems? Specifically: > > On systems with /usr/lib64, does the lib64 convention extend to > arbitrary prefixes that a user builds software for? E.g if I > "./configure --prefix=/usr/foo" etc. should that instlal to > /usr/foo/lib or /usr/foo/lib64? > > On typical systems, what directories are in the default linker search > path, so that libs in them may be found without RPATH? Is that > uniform across GNU/Linux variants? > > Are there any norms and standard procedures for how to find out > whether to use lib64 or not? Please describe. > > Are there any norms and standard procedures for how to find out if a > libdir is in the standard linker path and RPATH can be safely omitted? > > Are there norms for when RPATH should be omitted for libir in default > path, and are they uniform over all GNU/Linux variants or varying? > > > For NetBSD the answers are > > always lib, never lib64 > > /lib, /usr/lib is reliable. Don't assume more. > > [don't ever do anything about lib64] > > It's ok to omit RPATH for /lib and /usr/lib, and best practice is to > do so, but it's also irregular to build programs not provided with the > operating system with --prefix=/usr, so this doesn't come up in > practice. It is never ok to drop RPATH otherwise. > > > Hope this helps; there is no easy way out. > > 73 de n1dam > Thanks, Greg - appreciate the detail here. This isn't a one-size-fits-all. And yes, I'm quite aware of non-Linux systems. If BSD builds are ever broken, I'd like to know. I'm an OpenBSD user but that's a firewall so no GUI. 73, -Rick -- Rick Murphy, D.Sc., CISSP-ISSAP, K1MU/4, Annandale VA USA |
From: Greg T. <gd...@le...> - 2021-12-20 14:32:59
|
Rick Murphy <k1...@ar...> writes: > [Sorry, this draft apparently has been stalled for some time unsent,[ no worries, everybody is busy > I accepted the patches here, removed the RPATH setting, removed the setting > for library path, and added an include for GNUInstallPaths, all of which I > assumed would make this a distribution responsibility. I tried to point out when I saw the patches that, while sensible in the environment they were for, they would break most (in a general sense) installs, working only for installs into the default prefix on systems that don't use RPATH (which may be most installs on most computers by %, but it's still narrow over the set of configurations). > Built a tar.gz and started down my list of VMs running various Linux > distributions. Certainly you can test what you can test, but I tried to say earlier and didn't seem to succeed: All the world is not Linux. (Besides windows and mac) tqsl should work on any system meeting POSIX and for which the prereqs are available. It has been working fine on NetBSD, for example, perhaps with a bit of cmake patching, and I would expect it works on the others BSDs and even on illumos, with minor effort. I have been regularly testing and updating pkgsrc as releases happen for a number of years, and I run tqsl on NetBSD for log upload. I just don't say anything because almost always it builds fine. In addition, the earlier discussion has been focused on installs into the default prefix of /usr. While some packaging systems (typical on GNU/Linux variants) do that, some don't, and users who build tqsl themselves will almost always use a non-default prefix. So dropping RPATH setting always is basically wrong. It is reasonable to omit RPATH when the libdir is known to be a system libdir that is searched without RPATH. I'm glad to see you testing with /usr/local. If /usr/local/lib64 is in the default search path, though, I suggest you test with /usr/tqsl as the prefix, or /usr/foo or something else. tqsl should work for that build too, and with the RPATH stuff taken out I bet it will not. > The VERY FIRST TRY failed. CentOS 7, It installed libtqsllib.so into > /usr/local/lib/ and tqsl couldn't be activated because that library could > not be found (worked when moved to /lib64). Presumably you will back out this change then. You have encountered a problem I expected from reading the patch. > I'm still asking for help here. People seem to be implying that including > GNUInstallPaths just fixes these library dependent issues, but I'm not sure > what to do when trying this runs right into an error. I think the only reasonable path forward is to understand multiple things and design a plan based on that. I think it's have a way to find out if the system puts libs in /lib or /lib64. As I understand it, lib64 is used on some but not all GNU/Linux systems on x86_64 computers, but not on other CPU types. Or perhaps also on arm64 (and sparc64, to the extent anything still supports that). lib64 is never used on NetBSD; lib is always for native libs. I would think Gnuinstallpaths would figure this out, or there'd be some other direct support in cmake, as every single program needs to accomodate this variation in where libs belong. Perhaps, this can be conditional on the existence of /usr/lib64 if there isn't a better way. Set RPATH unless the configured libdir matches /usr/lib or /usr/lib64 (if we found out that the system is of the lib64 persuasion). Or perhaps "set RPATH unless prefix is /usr" is simpler and good enough, and on refletion I lean to it. The first point is somewhat difficult, and the second should be fairly easy. Can someone comment in more detail on the lib64 convention on various GNU/Linux systems? Specifically: On systems with /usr/lib64, does the lib64 convention extend to arbitrary prefixes that a user builds software for? E.g if I "./configure --prefix=/usr/foo" etc. should that instlal to /usr/foo/lib or /usr/foo/lib64? On typical systems, what directories are in the default linker search path, so that libs in them may be found without RPATH? Is that uniform across GNU/Linux variants? Are there any norms and standard procedures for how to find out whether to use lib64 or not? Please describe. Are there any norms and standard procedures for how to find out if a libdir is in the standard linker path and RPATH can be safely omitted? Are there norms for when RPATH should be omitted for libir in default path, and are they uniform over all GNU/Linux variants or varying? For NetBSD the answers are always lib, never lib64 /lib, /usr/lib is reliable. Don't assume more. [don't ever do anything about lib64] It's ok to omit RPATH for /lib and /usr/lib, and best practice is to do so, but it's also irregular to build programs not provided with the operating system with --prefix=/usr, so this doesn't come up in practice. It is never ok to drop RPATH otherwise. Hope this helps; there is no easy way out. 73 de n1dam |
From: Rick M. <k1...@ar...> - 2021-12-20 14:07:44
|
On Wed, Dec 8, 2021 at 8:37 AM Richard Shaw <hob...@gm...> wrote: > On Sun, Dec 5, 2021 at 3:23 PM Rick Murphy <k1...@ar...> wrote: > >> On Sun, Dec 5, 2021 at 3:16 PM Richard Shaw <hob...@gm...> wrote: >> >>> On Sun, Dec 5, 2021 at 2:10 PM Rick Murphy <k1...@ar...> wrote: >>> >>>> Yes, this builds on MacOS, Windows. and Linux. It also builds on >>>> Debian, Fedora, Ubuntu, .... building and installing is distinct from >>>> building to conform to a distribution's policies. >>>> >>>> For example, I stopped bundling a minimal trusted certificate store >>>> (ca-bundle.crt) on Unix builds because some distro forbade that. >>>> >>>> This issue with the RPATH setup in the CMakeLists.txt file is a patch >>>> that was submitted to correct a problem with some distro that doesn't use >>>> "/lib64" as I recall. This is essentially me accepting changes that work >>>> well for a single distribution and not working in a way to adapt to a wide >>>> range of distro and distro ages, along with the fact that I'm not an expert >>>> in how to build this portably. >>>> >>> >>> How long ago was it contributed? CMake handles RPATH pretty well these >>> days and should remove RPATH on install when installing into system >>> locations, or otherwise update it. >>> >> >> A long while ago. These changes are in TQSL 2.1 - circa 2015. Perhaps >> earlier. >> >> I'm happy to accept help here with cleaning this up, as it seems over >> time that this has become overcomplicated in a way that CMake is probably >> able to do a much better job at, versus the current ad-hoc attempts. >> > > Sounds good to me, How do you propose we test? Obviously Fedora is OK and > by extension RHEL and derivatives as I build for Fedora EPEL as well. > [Sorry, this draft apparently has been stalled for some time unsent,[ I accepted the patches here, removed the RPATH setting, removed the setting for library path, and added an include for GNUInstallPaths, all of which I assumed would make this a distribution responsibility. Built a tar.gz and started down my list of VMs running various Linux distributions. The VERY FIRST TRY failed. CentOS 7, It installed libtqsllib.so into /usr/local/lib/ and tqsl couldn't be activated because that library could not be found (worked when moved to /lib64). I'm still asking for help here. People seem to be implying that including GNUInstallPaths just fixes these library dependent issues, but I'm not sure what to do when trying this runs right into an error. > I'm unfamiliar with how tqsl development is managed. Is there any infra > where CI is performed? Known group of "testers"? > That question is kind of interesting. There is one developer, who is me. There's only one person who has ever provided me feedback on test releases (that is the purpose of this mailing list.) I have a fairly complete set of regression testing scripts for the command line operations, but I have no experience with building test harnesses for a multi-platform gui-driven UI. Any help here would be quite welcome. 73, -Rick -- Rick Murphy, D.Sc., CISSP-ISSAP, K1MU/4, Annandale VA USA |
From: Richard S. <hob...@gm...> - 2021-12-08 13:37:41
|
On Sun, Dec 5, 2021 at 3:23 PM Rick Murphy <k1...@ar...> wrote: > On Sun, Dec 5, 2021 at 3:16 PM Richard Shaw <hob...@gm...> wrote: > >> On Sun, Dec 5, 2021 at 2:10 PM Rick Murphy <k1...@ar...> wrote: >> >>> Yes, this builds on MacOS, Windows. and Linux. It also builds on Debian, >>> Fedora, Ubuntu, .... building and installing is distinct from building to >>> conform to a distribution's policies. >>> >>> For example, I stopped bundling a minimal trusted certificate store >>> (ca-bundle.crt) on Unix builds because some distro forbade that. >>> >>> This issue with the RPATH setup in the CMakeLists.txt file is a patch >>> that was submitted to correct a problem with some distro that doesn't use >>> "/lib64" as I recall. This is essentially me accepting changes that work >>> well for a single distribution and not working in a way to adapt to a wide >>> range of distro and distro ages, along with the fact that I'm not an expert >>> in how to build this portably. >>> >> >> How long ago was it contributed? CMake handles RPATH pretty well these >> days and should remove RPATH on install when installing into system >> locations, or otherwise update it. >> > > A long while ago. These changes are in TQSL 2.1 - circa 2015. Perhaps > earlier. > > I'm happy to accept help here with cleaning this up, as it seems over time > that this has become overcomplicated in a way that CMake is probably able > to do a much better job at, versus the current ad-hoc attempts. > Sounds good to me, How do you propose we test? Obviously Fedora is OK and by extension RHEL and derivatives as I build for Fedora EPEL as well. I'm unfamiliar with how tqsl development is managed. Is there any infra where CI is performed? Known group of "testers"? Thanks, Richard KF5OIM |
From: Rick M. <k1...@ar...> - 2021-12-05 21:23:57
|
On Sun, Dec 5, 2021 at 3:16 PM Richard Shaw <hob...@gm...> wrote: > On Sun, Dec 5, 2021 at 2:10 PM Rick Murphy <k1...@ar...> wrote: > >> Yes, this builds on MacOS, Windows. and Linux. It also builds on Debian, >> Fedora, Ubuntu, .... building and installing is distinct from building to >> conform to a distribution's policies. >> >> For example, I stopped bundling a minimal trusted certificate store >> (ca-bundle.crt) on Unix builds because some distro forbade that. >> >> This issue with the RPATH setup in the CMakeLists.txt file is a patch >> that was submitted to correct a problem with some distro that doesn't use >> "/lib64" as I recall. This is essentially me accepting changes that work >> well for a single distribution and not working in a way to adapt to a wide >> range of distro and distro ages, along with the fact that I'm not an expert >> in how to build this portably. >> > > How long ago was it contributed? CMake handles RPATH pretty well these > days and should remove RPATH on install when installing into system > locations, or otherwise update it. > A long while ago. These changes are in TQSL 2.1 - circa 2015. Perhaps earlier. I'm happy to accept help here with cleaning this up, as it seems over time that this has become overcomplicated in a way that CMake is probably able to do a much better job at, versus the current ad-hoc attempts. 73, -Rick -- Rick Murphy, D.Sc., CISSP-ISSAP, K1MU/4, Annandale VA USA |
From: Richard S. <hob...@gm...> - 2021-12-05 20:16:52
|
On Sun, Dec 5, 2021 at 2:10 PM Rick Murphy <k1...@ar...> wrote: > Yes, this builds on MacOS, Windows. and Linux. It also builds on Debian, > Fedora, Ubuntu, .... building and installing is distinct from building to > conform to a distribution's policies. > > For example, I stopped bundling a minimal trusted certificate store > (ca-bundle.crt) on Unix builds because some distro forbade that. > > This issue with the RPATH setup in the CMakeLists.txt file is a patch that > was submitted to correct a problem with some distro that doesn't use > "/lib64" as I recall. This is essentially me accepting changes that work > well for a single distribution and not working in a way to adapt to a wide > range of distro and distro ages, along with the fact that I'm not an expert > in how to build this portably. > How long ago was it contributed? CMake handles RPATH pretty well these days and should remove RPATH on install when installing into system locations, or otherwise update it. Thanks, Richard KF5OIM > |
From: Rick M. <k1...@ar...> - 2021-12-05 20:10:17
|
Yes, this builds on MacOS, Windows. and Linux. It also builds on Debian, Fedora, Ubuntu, .... building and installing is distinct from building to conform to a distribution's policies. For example, I stopped bundling a minimal trusted certificate store (ca-bundle.crt) on Unix builds because some distro forbade that. This issue with the RPATH setup in the CMakeLists.txt file is a patch that was submitted to correct a problem with some distro that doesn't use "/lib64" as I recall. This is essentially me accepting changes that work well for a single distribution and not working in a way to adapt to a wide range of distro and distro ages, along with the fact that I'm not an expert in how to build this portably. I am happy to accept fixes, but not fixes that undo work that supposedly corrects the issues already. 73, -Rick On Sun, Dec 5, 2021 at 1:53 PM Greg Troxel <gd...@le...> wrote: > Sounds good, except it isn't all Linux distributions, but all systems > conforming to POSIX. I'll have a look at the cmake stuff as I need to page > it in anyway. > > Is this supposed to build on windows? That's the odd one out, not POSIX. > -- Rick Murphy, D.Sc., CISSP-ISSAP, K1MU/4, Annandale VA USA |
From: Greg T. <gd...@le...> - 2021-12-05 18:53:18
|
Sounds good, except it isn't all Linux distributions, but all systems conforming to POSIX. I'll have a look at the cmake stuff as I need to page it in anyway. Is this supposed to build on windows? That's the odd one out, not POSIX. |
From: Rick M. <k1...@ar...> - 2021-12-05 18:47:39
|
The function causing the problem here is "tqsl_ssl_error_is_nofile()". It is intended to determine if an error in the SSL libraries was caused because of a failure to open a file. The "ERR_GET_LIB(l) == ERR_LIB_SYS" stanza means "did this error occur when calling the system libraries?" and the "ERR_GET_FUNC(l) == SYS_F_OPEN" means "did this error occur from an fopen() call?" If OpenSSL isn't going to return the function detail, then this entire section should be deleted and fall back on the second check. if (tQSL_Error == TQSL_SYSTEM_ERROR && tQSL_Errno == ENOENT) return 1; I'll map the first check out for OpenSSL > 3.0 As far as the libraries are concerned, I will be happy to take a fix that works across all Linux distributions. I think what's been happening here is changes being made based on the last distribution to complain, which isn't ideal. 73, -Rick On Sun, Dec 5, 2021 at 11:37 AM Richard Shaw <hob...@gm...> wrote: > On Sun, Dec 5, 2021 at 9:35 AM Greg Troxel <gd...@le...> wrote: > >> >> Richard Shaw <hob...@gm...> writes: >> >> > On Sun, Dec 5, 2021 at 8:56 AM Greg Troxel <gd...@le...> wrote: >> > >> >> >> >> Richard Shaw <hob...@gm...> writes: >> >> >> >> > Index: tqsl-2.5.9/src/openssl_cert.cpp >> >> > =================================================================== >> >> > --- tqsl-2.5.9.orig/src/openssl_cert.cpp >> >> > +++ tqsl-2.5.9/src/openssl_cert.cpp >> >> > @@ -4285,7 +4285,7 @@ static int >> >> > tqsl_ssl_error_is_nofile() { >> >> > unsigned long l = ERR_peek_error(); >> >> > if (tQSL_Error == TQSL_OPENSSL_ERROR && >> >> > - ERR_GET_LIB(l) == ERR_LIB_SYS && ERR_GET_FUNC(l) == SYS_F_FOPEN) >> >> > + ERR_GET_LIB(l) == ERR_LIB_SYS == SYS_F_FOPEN) >> >> > return 1; >> >> > if (tQSL_Error == TQSL_SYSTEM_ERROR && tQSL_Errno == ENOENT) >> >> > return 1; >> >> >> >> Did you also meen to remove " == SYS_F_FOPEN"? >> >> >> >> Is there really no semantics change from this? (It seems sensible to >> >> adjust, but I am not entirely following. >> > >> > Should it be removed? I only really hack at C/C++ code. >> >> I am surprised it builds and I'm not sure what it does. >> >> Basically >> >> && ERR_GET_FUNC(l) == SYS_F_FOPEN >> >> is a logical and an equality test. So dropping the entire test could >> make sense and your + line would then be >> >> >> > + ERR_GET_LIB(l) == ERR_LIB_SYS) >> >> but I don't understand what this did, and how one should try to do the >> same thing in the 3.0.0 world. >> > > Fixed in my patch, unfortunately I can't answer the last part... > > > (It strikes me as aggressive to be moving to 3.0.0, but those are tough >> calls, and surely beyond your control..) >> > > Well Fedora tends to be leading edge... Latest kernels, latest GCC, latest > python (currently testing 3.11 alpha) etc. Someone has to be first, right? > > There's also some additional deprecated functions in OpenSSL 3 if you > want to get ahead of it. > > > https://kojipkgs.fedoraproject.org//packages/trustedqsl/2.5.9/1.fc36/data/logs/x86_64/build.log > > Just search on "deprecated:" > > Here's the porting guide: > > https://www.openssl.org/docs/manmaster/man7/migration_guide.html > > > >> > I also have patches I maintain to clean up rpath/lib install location >> and >> >> > to provide a soversion for the tqsl library (required by Fedora). >> >> >> >> I'd be interested to see the rpath/lib patch. pkgsrc norms are to have >> >> RPATH of /usr/pkg/lib set in /usr/pkg/foo as /usr/pkg (or whatever) is >> >> not in the default search path. I know that various packaging systems >> >> have very different rpath rules, and I think that leads to a need to be >> >> able to configure the build for the varying environments. >> > >> > As long as you're installing into system library locations (which we >> are) >> > they're already in the library search path so RPATH isn't needed, in >> fact >> > as a packager I have to remove RPATH in these situations. >> >> Yes, but we are installing not into the system library path and thus we >> need to set RPATH. This is the basic difference between systems that >> have "base system" and then "packages" and systems that have "single >> base system but many things are optional". The first is the traditional >> UNIX approach, and the second the GNU/Linux approach. >> >> Even on GNU/Linux, if someone builds tqsl themselves with >> prefix=/home/johndoe/HAM, then RPATH is needed and should happen. So >> it's really a special case that if libdir is /usr/lib then RPATH should >> be skippped, and in general it should be included. >> >> > So I guess maybe the first step would be to wrap some conditionals >> around >> > the current logic so it's only used when needed. >> > >> > Here's my rpath/install patch: >> > >> > >> https://src.fedoraproject.org/rpms/trustedqsl/blob/rawhide/f/tqsl-2.5-rpath.patch >> > >> > The first part just roto-rooters the RPATH stuff from >> apps/CMakeLists.txt >> > since I don't need it. Probably not acceptable as is :) >> >> Indeed, that is not acceptable as it breaks many other systems. My >> impression is that CMake already has the concept of whether RPATH should >> be set or not and there are cmake-time config arguments to say which way >> it should be. I would say aligning to that is the standard approach. >> > > Yes, so I guess the question is why was that code once needed? Or are > there corner cases? > > > > The 2nd part should be more interesting to you. Here I replace all the >> > logic and replace it with the GNUInstallDirs module which will set all >> the >> > CMAKE_INSTALL_... variables correctly for Linux systems since RPM and >> DEB >> > based systems handle this very differently. This probably should be >> wrapped >> > in an "IF(LINUX)" conditional. >> >> If it's only for GNU/Linux systems, yes, but GNUInstallDirs seems like >> the right approach in general. pkgsrc path norms are basically >> inherited from autoconf and thus from the GNU coding standards, with >> some adjustments to be similar to the BSD hier(7), but all of that >> mostly is a common history from the 80s. >> >> As for "libsuffix", my view is that that standard libdir is $prefix/lib, >> and systems that use lib64 are unusual and it's ok to expect them to be >> configured wtih cmake libsuffix=64 or whatever, but if there's a way to >> query if the current system is like that and do it automatically, that's >> ok. >> > > As far as I know lib64 is used on all RPM based systems (certainly Fedora, > RHEL, OpenSUSE) that support multi-arch which allows use of 32-bit > libraries on 64-bit systems. > > > Does the Fedora world use lib64 on x86_64, or just lib? I have the >> impression that lib64 happens on Debian. >> > > No Debian uses a /lib/<multiarch-tuple> type arrangement. > > https://cmake.org/cmake/help/latest/module/GNUInstallDirs.html > > Thanks, > Richard > KF5OIM > _______________________________________________ > Trustedqsl-testing mailing list > Tru...@li... > https://lists.sourceforge.net/lists/listinfo/trustedqsl-testing > -- Rick Murphy, D.Sc., CISSP-ISSAP, K1MU/4, Annandale VA USA |
From: Richard S. <hob...@gm...> - 2021-12-05 16:36:56
|
On Sun, Dec 5, 2021 at 9:35 AM Greg Troxel <gd...@le...> wrote: > > Richard Shaw <hob...@gm...> writes: > > > On Sun, Dec 5, 2021 at 8:56 AM Greg Troxel <gd...@le...> wrote: > > > >> > >> Richard Shaw <hob...@gm...> writes: > >> > >> > Index: tqsl-2.5.9/src/openssl_cert.cpp > >> > =================================================================== > >> > --- tqsl-2.5.9.orig/src/openssl_cert.cpp > >> > +++ tqsl-2.5.9/src/openssl_cert.cpp > >> > @@ -4285,7 +4285,7 @@ static int > >> > tqsl_ssl_error_is_nofile() { > >> > unsigned long l = ERR_peek_error(); > >> > if (tQSL_Error == TQSL_OPENSSL_ERROR && > >> > - ERR_GET_LIB(l) == ERR_LIB_SYS && ERR_GET_FUNC(l) == SYS_F_FOPEN) > >> > + ERR_GET_LIB(l) == ERR_LIB_SYS == SYS_F_FOPEN) > >> > return 1; > >> > if (tQSL_Error == TQSL_SYSTEM_ERROR && tQSL_Errno == ENOENT) > >> > return 1; > >> > >> Did you also meen to remove " == SYS_F_FOPEN"? > >> > >> Is there really no semantics change from this? (It seems sensible to > >> adjust, but I am not entirely following. > > > > Should it be removed? I only really hack at C/C++ code. > > I am surprised it builds and I'm not sure what it does. > > Basically > > && ERR_GET_FUNC(l) == SYS_F_FOPEN > > is a logical and an equality test. So dropping the entire test could > make sense and your + line would then be > > >> > + ERR_GET_LIB(l) == ERR_LIB_SYS) > > but I don't understand what this did, and how one should try to do the > same thing in the 3.0.0 world. > Fixed in my patch, unfortunately I can't answer the last part... (It strikes me as aggressive to be moving to 3.0.0, but those are tough > calls, and surely beyond your control..) > Well Fedora tends to be leading edge... Latest kernels, latest GCC, latest python (currently testing 3.11 alpha) etc. Someone has to be first, right? There's also some additional deprecated functions in OpenSSL 3 if you want to get ahead of it. https://kojipkgs.fedoraproject.org//packages/trustedqsl/2.5.9/1.fc36/data/logs/x86_64/build.log Just search on "deprecated:" Here's the porting guide: https://www.openssl.org/docs/manmaster/man7/migration_guide.html >> > I also have patches I maintain to clean up rpath/lib install location > and > >> > to provide a soversion for the tqsl library (required by Fedora). > >> > >> I'd be interested to see the rpath/lib patch. pkgsrc norms are to have > >> RPATH of /usr/pkg/lib set in /usr/pkg/foo as /usr/pkg (or whatever) is > >> not in the default search path. I know that various packaging systems > >> have very different rpath rules, and I think that leads to a need to be > >> able to configure the build for the varying environments. > > > > As long as you're installing into system library locations (which we are) > > they're already in the library search path so RPATH isn't needed, in fact > > as a packager I have to remove RPATH in these situations. > > Yes, but we are installing not into the system library path and thus we > need to set RPATH. This is the basic difference between systems that > have "base system" and then "packages" and systems that have "single > base system but many things are optional". The first is the traditional > UNIX approach, and the second the GNU/Linux approach. > > Even on GNU/Linux, if someone builds tqsl themselves with > prefix=/home/johndoe/HAM, then RPATH is needed and should happen. So > it's really a special case that if libdir is /usr/lib then RPATH should > be skippped, and in general it should be included. > > > So I guess maybe the first step would be to wrap some conditionals around > > the current logic so it's only used when needed. > > > > Here's my rpath/install patch: > > > > > https://src.fedoraproject.org/rpms/trustedqsl/blob/rawhide/f/tqsl-2.5-rpath.patch > > > > The first part just roto-rooters the RPATH stuff from apps/CMakeLists.txt > > since I don't need it. Probably not acceptable as is :) > > Indeed, that is not acceptable as it breaks many other systems. My > impression is that CMake already has the concept of whether RPATH should > be set or not and there are cmake-time config arguments to say which way > it should be. I would say aligning to that is the standard approach. > Yes, so I guess the question is why was that code once needed? Or are there corner cases? > The 2nd part should be more interesting to you. Here I replace all the > > logic and replace it with the GNUInstallDirs module which will set all > the > > CMAKE_INSTALL_... variables correctly for Linux systems since RPM and DEB > > based systems handle this very differently. This probably should be > wrapped > > in an "IF(LINUX)" conditional. > > If it's only for GNU/Linux systems, yes, but GNUInstallDirs seems like > the right approach in general. pkgsrc path norms are basically > inherited from autoconf and thus from the GNU coding standards, with > some adjustments to be similar to the BSD hier(7), but all of that > mostly is a common history from the 80s. > > As for "libsuffix", my view is that that standard libdir is $prefix/lib, > and systems that use lib64 are unusual and it's ok to expect them to be > configured wtih cmake libsuffix=64 or whatever, but if there's a way to > query if the current system is like that and do it automatically, that's > ok. > As far as I know lib64 is used on all RPM based systems (certainly Fedora, RHEL, OpenSUSE) that support multi-arch which allows use of 32-bit libraries on 64-bit systems. Does the Fedora world use lib64 on x86_64, or just lib? I have the > impression that lib64 happens on Debian. > No Debian uses a /lib/<multiarch-tuple> type arrangement. https://cmake.org/cmake/help/latest/module/GNUInstallDirs.html Thanks, Richard KF5OIM |
From: Greg T. <gd...@le...> - 2021-12-05 15:35:52
|
Richard Shaw <hob...@gm...> writes: > On Sun, Dec 5, 2021 at 8:56 AM Greg Troxel <gd...@le...> wrote: > >> >> Richard Shaw <hob...@gm...> writes: >> >> > Index: tqsl-2.5.9/src/openssl_cert.cpp >> > =================================================================== >> > --- tqsl-2.5.9.orig/src/openssl_cert.cpp >> > +++ tqsl-2.5.9/src/openssl_cert.cpp >> > @@ -4285,7 +4285,7 @@ static int >> > tqsl_ssl_error_is_nofile() { >> > unsigned long l = ERR_peek_error(); >> > if (tQSL_Error == TQSL_OPENSSL_ERROR && >> > - ERR_GET_LIB(l) == ERR_LIB_SYS && ERR_GET_FUNC(l) == SYS_F_FOPEN) >> > + ERR_GET_LIB(l) == ERR_LIB_SYS == SYS_F_FOPEN) >> > return 1; >> > if (tQSL_Error == TQSL_SYSTEM_ERROR && tQSL_Errno == ENOENT) >> > return 1; >> >> Did you also meen to remove " == SYS_F_FOPEN"? >> >> Is there really no semantics change from this? (It seems sensible to >> adjust, but I am not entirely following. > > Should it be removed? I only really hack at C/C++ code. I am surprised it builds and I'm not sure what it does. Basically && ERR_GET_FUNC(l) == SYS_F_FOPEN is a logical and an equality test. So dropping the entire test could make sense and your + line would then be >> > + ERR_GET_LIB(l) == ERR_LIB_SYS) but I don't understand what this did, and how one should try to do the same thing in the 3.0.0 world. (It strikes me as aggressive to be moving to 3.0.0, but those are tough calls, and surely beyond your control..) >> > I also have patches I maintain to clean up rpath/lib install location and >> > to provide a soversion for the tqsl library (required by Fedora). >> >> I'd be interested to see the rpath/lib patch. pkgsrc norms are to have >> RPATH of /usr/pkg/lib set in /usr/pkg/foo as /usr/pkg (or whatever) is >> not in the default search path. I know that various packaging systems >> have very different rpath rules, and I think that leads to a need to be >> able to configure the build for the varying environments. > > As long as you're installing into system library locations (which we are) > they're already in the library search path so RPATH isn't needed, in fact > as a packager I have to remove RPATH in these situations. Yes, but we are installing not into the system library path and thus we need to set RPATH. This is the basic difference between systems that have "base system" and then "packages" and systems that have "single base system but many things are optional". The first is the traditional UNIX approach, and the second the GNU/Linux approach. Even on GNU/Linux, if someone builds tqsl themselves with prefix=/home/johndoe/HAM, then RPATH is needed and should happen. So it's really a special case that if libdir is /usr/lib then RPATH should be skippped, and in general it should be included. > So I guess maybe the first step would be to wrap some conditionals around > the current logic so it's only used when needed. > > Here's my rpath/install patch: > > https://src.fedoraproject.org/rpms/trustedqsl/blob/rawhide/f/tqsl-2.5-rpath.patch > > The first part just roto-rooters the RPATH stuff from apps/CMakeLists.txt > since I don't need it. Probably not acceptable as is :) Indeed, that is not acceptable as it breaks many other systems. My impression is that CMake already has the concept of whether RPATH should be set or not and there are cmake-time config arguments to say which way it should be. I would say aligning to that is the standard approach. > The 2nd part should be more interesting to you. Here I replace all the > logic and replace it with the GNUInstallDirs module which will set all the > CMAKE_INSTALL_... variables correctly for Linux systems since RPM and DEB > based systems handle this very differently. This probably should be wrapped > in an "IF(LINUX)" conditional. If it's only for GNU/Linux systems, yes, but GNUInstallDirs seems like the right approach in general. pkgsrc path norms are basically inherited from autoconf and thus from the GNU coding standards, with some adjustments to be similar to the BSD hier(7), but all of that mostly is a common history from the 80s. As for "libsuffix", my view is that that standard libdir is $prefix/lib, and systems that use lib64 are unusual and it's ok to expect them to be configured wtih cmake libsuffix=64 or whatever, but if there's a way to query if the current system is like that and do it automatically, that's ok. Does the Fedora world use lib64 on x86_64, or just lib? I have the impression that lib64 happens on Debian. NetBSD has no use of lib64. Native libs are always in $prefix/lib. Emulation libs are in /emul/foo/usr/lib for various other operating systems foo, and e.g. in /usr/lib/i386 on amd64 systems. But there is a "native-first" naming bias, and I sometimes run into configure scripts that try to apply the lib64 idea to system where it doesn't belong. |
From: Richard S. <hob...@gm...> - 2021-12-05 15:13:38
|
On Sun, Dec 5, 2021 at 8:56 AM Greg Troxel <gd...@le...> wrote: > > Richard Shaw <hob...@gm...> writes: > > > Index: tqsl-2.5.9/src/openssl_cert.cpp > > =================================================================== > > --- tqsl-2.5.9.orig/src/openssl_cert.cpp > > +++ tqsl-2.5.9/src/openssl_cert.cpp > > @@ -4285,7 +4285,7 @@ static int > > tqsl_ssl_error_is_nofile() { > > unsigned long l = ERR_peek_error(); > > if (tQSL_Error == TQSL_OPENSSL_ERROR && > > - ERR_GET_LIB(l) == ERR_LIB_SYS && ERR_GET_FUNC(l) == SYS_F_FOPEN) > > + ERR_GET_LIB(l) == ERR_LIB_SYS == SYS_F_FOPEN) > > return 1; > > if (tQSL_Error == TQSL_SYSTEM_ERROR && tQSL_Errno == ENOENT) > > return 1; > > Did you also meen to remove " == SYS_F_FOPEN"? > > Is there really no semantics change from this? (It seems sensible to > adjust, but I am not entirely following. > Should it be removed? I only really hack at C/C++ code. > > I also have patches I maintain to clean up rpath/lib install location and > > to provide a soversion for the tqsl library (required by Fedora). > > I'd be interested to see the rpath/lib patch. pkgsrc norms are to have > RPATH of /usr/pkg/lib set in /usr/pkg/foo as /usr/pkg (or whatever) is > not in the default search path. I know that various packaging systems > have very different rpath rules, and I think that leads to a need to be > able to configure the build for the varying environments. > As long as you're installing into system library locations (which we are) they're already in the library search path so RPATH isn't needed, in fact as a packager I have to remove RPATH in these situations. So I guess maybe the first step would be to wrap some conditionals around the current logic so it's only used when needed. Here's my rpath/install patch: https://src.fedoraproject.org/rpms/trustedqsl/blob/rawhide/f/tqsl-2.5-rpath.patch The first part just roto-rooters the RPATH stuff from apps/CMakeLists.txt since I don't need it. Probably not acceptable as is :) The 2nd part should be more interesting to you. Here I replace all the logic and replace it with the GNUInstallDirs module which will set all the CMAKE_INSTALL_... variables correctly for Linux systems since RPM and DEB based systems handle this very differently. This probably should be wrapped in an "IF(LINUX)" conditional. Thanks, Richard |
From: Greg T. <gd...@le...> - 2021-12-05 14:56:20
|
Richard Shaw <hob...@gm...> writes: > Index: tqsl-2.5.9/src/openssl_cert.cpp > =================================================================== > --- tqsl-2.5.9.orig/src/openssl_cert.cpp > +++ tqsl-2.5.9/src/openssl_cert.cpp > @@ -4285,7 +4285,7 @@ static int > tqsl_ssl_error_is_nofile() { > unsigned long l = ERR_peek_error(); > if (tQSL_Error == TQSL_OPENSSL_ERROR && > - ERR_GET_LIB(l) == ERR_LIB_SYS && ERR_GET_FUNC(l) == SYS_F_FOPEN) > + ERR_GET_LIB(l) == ERR_LIB_SYS == SYS_F_FOPEN) > return 1; > if (tQSL_Error == TQSL_SYSTEM_ERROR && tQSL_Errno == ENOENT) > return 1; Did you also meen to remove " == SYS_F_FOPEN"? Is there really no semantics change from this? (It seems sensible to adjust, but I am not entirely following. > I also have patches I maintain to clean up rpath/lib install location and > to provide a soversion for the tqsl library (required by Fedora). I'd be interested to see the rpath/lib patch. pkgsrc norms are to have RPATH of /usr/pkg/lib set in /usr/pkg/foo as /usr/pkg (or whatever) is not in the default search path. I know that various packaging systems have very different rpath rules, and I think that leads to a need to be able to configure the build for the varying environments. 73 de n1dam |
From: Richard S. <hob...@gm...> - 2021-12-05 14:34:44
|
I wanted to file this as a bug but every time I try to create an account on mantis I get a 504 gateway error... I'm the Fedora package maintainer and Fedora 36 will have OpenSSL 3.0.0. Unfortunately, tqsl uses a function that's being removed: ERR_GET_FUNC I have a trivial patch to remove it: Index: tqsl-2.5.9/src/openssl_cert.cpp =================================================================== --- tqsl-2.5.9.orig/src/openssl_cert.cpp +++ tqsl-2.5.9/src/openssl_cert.cpp @@ -4285,7 +4285,7 @@ static int tqsl_ssl_error_is_nofile() { unsigned long l = ERR_peek_error(); if (tQSL_Error == TQSL_OPENSSL_ERROR && - ERR_GET_LIB(l) == ERR_LIB_SYS && ERR_GET_FUNC(l) == SYS_F_FOPEN) + ERR_GET_LIB(l) == ERR_LIB_SYS == SYS_F_FOPEN) return 1; if (tQSL_Error == TQSL_SYSTEM_ERROR && tQSL_Errno == ENOENT) return 1; I also have patches I maintain to clean up rpath/lib install location and to provide a soversion for the tqsl library (required by Fedora). Thanks, Richard KF5OIM |
From: Rick M. <k1...@ar...> - 2021-11-19 00:07:12
|
That's probably because I built on a fairly recent Fedora. I've just rebuilt on Debian 10 and will see how well that transfers to other releases. I've got the message clearly and will continue to ship the tarballs as there are people depending on those. 73, -Rick On Thu, Nov 18, 2021 at 4:09 PM Walter Fey <dl...@da...> wrote: > Hi Rick, > > The AppImage does not start on the current stable openSUSE release "Leap > 15.3". > > TQSL built from from the source on the openSUSE build service works > perfectly and fits into this distribution. So I would prefer to get the > source files for building and distribution via the openSUSE build service. > > 73, Walter DL8FCL > > The error messages are: > > dl8fcl@osiris2:~/Downloads> ./TQSL-x86_64.AppImage > ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found > (required by ./TQSL-x86_64.AppImage) > ./TQSL-x86_64.AppImage: /usr/lib64/libstdc++.so.6: version > `GLIBCXX_3.4.29' not found (required by ./TQSL-x86_64.AppImage) > ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found > (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libtqsllib.so) > ./TQSL-x86_64.AppImage: /usr/lib64/libstdc++.so.6: version > `GLIBCXX_3.4.29' not found (required by > /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libtqsllib.so) > ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found > (required by > /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libwx_gtk3u_core-3.0.so.0) > ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found > (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libwx_baseu-3.0.so.0) > ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found > (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libcurl.so.4) > ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found > (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libcrypto.so.1.1) > ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found > (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libdb-5.3.so) > ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found > (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libgtk-3.so.0) > ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found > (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libtiff.so.5) > ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found > (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libSDL2-2.0.so.0) > ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.32' not found > (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libSDL2-2.0.so.0) > ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found > (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libssh.so.4) > ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found > (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libpsl.so.5) > ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found > (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libgssapi_krb5.so.2) > ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found > (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libkrb5.so.3) > ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found > (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libk5crypto.so.3) > ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found > (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libxkbcommon.so.0) > ./TQSL-x86_64.AppImage: /lib64/libselinux.so.1: no version information > available (required by > /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libkrb5support.so.0) > ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found > (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libkrb5support.so.0) > ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found > (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libdbus-1.so.3) > ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found > (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libXau.so.6) > ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found > (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libsystemd.so.0) > ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.32' not found > (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libsystemd.so.0) > ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.32' not found > (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/liblzma.so.5) > ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found > (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libcap.so.2) > ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found > (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libgcrypt.so.20) > dl8fcl@osiris2:~/Downloads> > Am 18.11.21 um 21:24 schrieb Rick Murphy: > > I was recently prodded by Pavel, CO7WT, to point out to me a new packaging > scheme for Linux programs that allows a sort of "universal" package that > can run on many different Linux distributions. This means that you don't > have to maintain a build for Ubuntu, Debian, Arch, Fedora, CentOS, SuSe, > and many other different Linux variations. This seems like a major advance, > as some Linux distros don't have supported copies of TQSL (or have copies > that lag behind). > > I've built and tested a beta kit for TQSL for Linux. If you're interested, > give it a try and let me know what you think and if it's working for you, > as I'm probably going to stop distributing .tar.gz files as those > require building for source and this AppImage format just needs to be > downloaded. > > https://www.rickmurphy.net/lotw/TQSL-x86_64.AppImage > > Download the file, then either install it on your desktop (which will > happen with a double-click if your distribution allows it), or use a > terminal to make it runnable: > > $ chmod a+x TQSL-x86_64.AppImage > $ ./TQSL-x86_64.AppImage > > 73, > -Rick > -- > Rick Murphy, D.Sc., 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, D.Sc., CISSP-ISSAP, K1MU/4, Annandale VA USA |
From: Walter F. <dl...@da...> - 2021-11-18 21:08:54
|
Hi Rick, The AppImage does not start on the current stable openSUSE release "Leap 15.3". TQSL built from from the source on the openSUSE build service works perfectly and fits into this distribution. So I would prefer to get the source files for building and distribution via the openSUSE build service. 73, Walter DL8FCL The error messages are: dl8fcl@osiris2:~/Downloads> ./TQSL-x86_64.AppImage ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by ./TQSL-x86_64.AppImage) ./TQSL-x86_64.AppImage: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by ./TQSL-x86_64.AppImage) ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libtqsllib.so) ./TQSL-x86_64.AppImage: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libtqsllib.so) ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libwx_gtk3u_core-3.0.so.0) ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libwx_baseu-3.0.so.0) ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libcurl.so.4) ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libcrypto.so.1.1) ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libdb-5.3.so) ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libgtk-3.so.0) ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libtiff.so.5) ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libSDL2-2.0.so.0) ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.32' not found (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libSDL2-2.0.so.0) ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libssh.so.4) ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libpsl.so.5) ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libgssapi_krb5.so.2) ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libkrb5.so.3) ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libk5crypto.so.3) ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libxkbcommon.so.0) ./TQSL-x86_64.AppImage: /lib64/libselinux.so.1: no version information available (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libkrb5support.so.0) ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libkrb5support.so.0) ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libdbus-1.so.3) ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libXau.so.6) ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libsystemd.so.0) ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.32' not found (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libsystemd.so.0) ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.32' not found (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/liblzma.so.5) ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libcap.so.2) ./TQSL-x86_64.AppImage: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by /tmp/.mount_TQSL-xFLzrAS/usr/bin/../lib/libgcrypt.so.20) dl8fcl@osiris2:~/Downloads> Am 18.11.21 um 21:24 schrieb Rick Murphy: > I was recently prodded by Pavel, CO7WT, to point out to me a new > packaging scheme for Linux programs that allows a sort of "universal" > package that can run on many different Linux distributions. This means > that you don't have to maintain a build for Ubuntu, Debian, Arch, > Fedora, CentOS, SuSe, and many other different Linux variations. This > seems like a major advance, as some Linux distros don't have supported > copies of TQSL (or have copies that lag behind). > > I've built and tested a beta kit for TQSL for Linux. If you're > interested, give it a try and let me know what you think and if it's > working for you, as I'm probably going to stop distributing .tar.gz > files as those require building for source and this AppImage format > just needs to be downloaded. > > https://www.rickmurphy.net/lotw/TQSL-x86_64.AppImage > <https://www.rickmurphy.net/lotw/TQSL-x86_64.AppImage> > > Download the file, then either install it on your desktop (which will > happen with a double-click if your distribution allows it), or use a > terminal to make it runnable: > > $ chmod a+x TQSL-x86_64.AppImage > $ ./TQSL-x86_64.AppImage > > 73, > -Rick > -- > Rick Murphy, D.Sc., CISSP-ISSAP, K1MU/4, Annandale VA USA > > > _______________________________________________ > Trustedqsl-testing mailing list > Tru...@li... > https://lists.sourceforge.net/lists/listinfo/trustedqsl-testing |
From: Rick M. <k1...@ar...> - 2021-11-18 20:24:48
|
I was recently prodded by Pavel, CO7WT, to point out to me a new packaging scheme for Linux programs that allows a sort of "universal" package that can run on many different Linux distributions. This means that you don't have to maintain a build for Ubuntu, Debian, Arch, Fedora, CentOS, SuSe, and many other different Linux variations. This seems like a major advance, as some Linux distros don't have supported copies of TQSL (or have copies that lag behind). I've built and tested a beta kit for TQSL for Linux. If you're interested, give it a try and let me know what you think and if it's working for you, as I'm probably going to stop distributing .tar.gz files as those require building for source and this AppImage format just needs to be downloaded. https://www.rickmurphy.net/lotw/TQSL-x86_64.AppImage Download the file, then either install it on your desktop (which will happen with a double-click if your distribution allows it), or use a terminal to make it runnable: $ chmod a+x TQSL-x86_64.AppImage $ ./TQSL-x86_64.AppImage 73, -Rick -- Rick Murphy, D.Sc., CISSP-ISSAP, K1MU/4, Annandale VA USA |