Package Details: trustedqsl 2.4.7-1

Git Clone URL: (read-only)
Package Base: trustedqsl
Description: QSO log signing data for the ARRL Logbook of The World (LoTW)
Upstream URL:
Licenses: custom:ARRL
Conflicts: trustedqsl-git
Provides: tqsllib, trustedqsl
Replaces: tqsl
Submitter: jecxjo
Maintainer: not_anonymous
Last Packager: not_anonymous
Votes: 19
Popularity: 0.018723
First Submitted: 2011-08-27 23:42
Last Updated: 2019-06-03 19:09

Latest Comments

1 2 3 4 5 Next › Last »

waterlubber commented on 2019-06-18 19:26

I'm having issues with themes. I'm using a dark system GTK theme (matcha-dark-sea) and the text in the main windows is illegible (very light gray on white). Does anyone know how to launch this with a specific theme? I can't figure out the enviromnent variable for the life of me. I suspect it has to do with wxGTK.

not_anonymous commented on 2019-06-03 19:11


xiretza commented on 2018-01-29 16:07

needs 'libxxf86vm' as makedepends.

TheLugal commented on 2017-05-27 15:31

@not_anonymous I don't have the faintest idea. I tried installing from AUR both using bb-wrapper, and yaourt. I also tried compiling from git repo. It is not much of an issue, since I only had to manually copy the file. Maybe I'm just an odd one out, but the comment is there if anyone else experience this.

not_anonymous commented on 2017-05-26 22:25

UH, I'd love to know what you are the package I have here puts the lib file where it belongs v/v the current PKGBUILD. The *only* reason this would happen is IF there was a change in the upstream code *without* a corresponding change in the version number....BUT ****** even the latest code from the -git repo, using the same basic PKGBUILD, builds this correctly. SO.... I am left wondering what you did on your end of things ???

TheLugal commented on 2017-05-26 15:37

I got an error after trying to run tqsl; "tqsl: error while loading shared libraries: cannot open shared object file: No such file or directory".

I fixed it by manually copy ?/tqsl/files/tqsl-2.3.1/src/ to /var/lib. Seems like the installation process doesn't do this by it self.

not_anonymous commented on 2017-05-26 01:33's important to NOT expect pacman to do what yaourt does, as it (pacman) will not do what you wanted to do. (That is what you experienced, which is why I mentioned using yaourt in my last message...hi hi.)

There are *always* potential changes needed "under the hood" to various programs over time, some of which require so input from the packager to "fix" (if such issues are not fixed "upstream"...). SO, when you find something important; speak up !! <- The *trick* is knowing when to speak up **&** what to say....hi hi !!!!

Anyways, I am glad you worked this out AND I am glad that this package is A.O.K. as is.

noway2 commented on 2017-05-25 19:12

I'm glad the report was helpful. By "regular repository" I meant the ones like core and extra that you can download the compiled binary files from rather than AUR where you compile it form source. The confusion was in my thinking of Arch in terms of being a cross between a binary only distribution and a source only.

It seems strange that I was having trouble getting it to install the dependencies, which is even more weird in that I recall seeing the line about downloading and checking for them which would pass but then it would stop claiming it had unresolved ones that needed to be rectified. I looked in the package build file and saw that they were available in AUR. I made sure that I did a pacman Syu sync and then tried every combination of I could think of or Google for in both makepkg and yaourt.

I am getting the impression that there may be some changes going on "under the hood" with some of the libraries by the way some of the ham radio applications I've been trying to build have been running into trouble compiling. For example, I also installed wsjt-x and had to manually 'hack' the MainWindow.cpp file because it was started complaining about an ambiguous type cast and I saw that people were running into this with other applications too.

not_anonymous commented on 2017-05-25 15:22

Thanks for the report that wxgtk 3.x does not work at this time. I'm glad that this package is not using it.

I do not understand what a "regular repository" means v/v aur. There is only one aur and it is adjunct to other repositories like core, extra and community. IF something is not available outside of aur, then you will find it in aur (or not at all). SO...assuming your system is a.o.k. v/v setup; you should be able to type "yaourt trustedqsl" and yaourt should get stuff straightened out as needed.

I checked the dep. chain and ALL of the packages you had to install "manually" ARE in the aur OR the "binary repos" (core, base, or community) and *should-have* been installed as needed.

noway2 commented on 2017-05-24 20:06

The package seems to be linked against wxgtk2.8 though the current version in the regular repository is I had great difficulty in getting trustedsql to obtain the dependencies and compile. It would not compile against version 3 despite the comment below to the effect that it would and instead would complain about missing some wx_widgets LIBRARIES. wxgtk2.8 has been moved to AUR and I was able to get that to compile after obtaining gstreamer0.10 and gstreamer0.10-base, both of which are older than the current repository versions. Getting these installed required a large number of dependencies that, thankfully were in the regular repository and these versions would compile against them. Attempts to have AUR, or yaourt, automatically obtain the required dependencies would fail claiming they could not be found requiring me to manually slog through them.