CQRLOG 2.4.0 has been released

Submitted by ok2cqr on

After really long time we have new version of CQRLOG. There are tons of bugfixes and log of improvements done mosty by Saku, OH1KH and others. More in Download section. Deb packages for Ubuntu 18.04, 19.04 and 19.10 are already on Launchpad.

Comments

Fine !

Submitted by oh1kh on

This was really needed because of eQSL web page migration.

I know how limited your time is, but do we have any news from snap / flatpack integration that would help daily snapshots delivery ?

ok2cqr's picture

Re: Fine !

Submitted by ok2cqr on

Hi Saku,

I'm in a blind alley. The basic version works including TRX control but there is a problem with external apps like WSJTX, fldigi, tqsl. It would work but only when they are also part of the snap package. That is sad because I had to release new version od snap everytime when any of these app releases new version. Another problem is with confuguration. If user changes anything, it would be changed only for app in the snap, not for app on you base system. It seems I can't run any app from the snapped application that is located on the host system. So I can't run wsjtx installed on Ubuntu using deb or binary from cqrlog running in snap :(. I don't know how to solve it and unfortunately didn't get any response to my question on snapcraft forum :(.
I suppose flatpak will be the the same.

73 Petr

Snap

Submitted by oh1kh on

Oh!
Sad to hear that.
How ever I do not understand why wsjt-x or fldigi (in xml remote) could not work with snap. Both are accessed via network. Internal, but I have worked them also having them on other PC in home network.
Must be some kind of firewall issue between snap localhost and PC local host then.

Thing that I can understand is that they probably will not start as cqrlog process without being inside snap, but if user just starts them manually outside of cqrlog they should work. (the way I run them all the time)
So just drop the preferences "start when remote...."

Tqsl may be bigger problem as it does not have TCP connection.
Same as configuration but if "real" Mysql server is in use at port 3306 and no MysqlProcess is started from inside of cqrlog? What about then? Then everything is transferred via TCP to outside of snap.

Or if regular mysql_save process is used, but started outside of snap. Then everything that is inside database is saved as usual to ~/.config/cqrlog.

Did you know that mysql_save process started by cqrlog has security hole and is wide open to network without any passwords, up to internet if firewall is not set properly?
So starting that process by bash, outside of snap, can probably be accessed via localhost net connect from snap.

Or should just generation of daily binary file be considered ? No bells and whistles. Only cqrlog binary (32 & 64bit) that user can copy to /usr/bin manually.
New fresh stabile installs via normal package manager as now, but upgrade to daily alphas just by bash cp command.

ok2cqr's picture

Re: Snap

Submitted by ok2cqr on

There is no problem with communication over TCP/IP or UDP. Problem is that CQRLOG can run wsjt directly when you hit a shortkey. That won't be possible with CQRLOG in snap. We can have some workaround, snap cqrlog users could run the wsjt by hand.
The real problem is with tqsl as you mentioned. It doesn't have any communication, cqrlog has to run it from command line :(. There would be only one way - create some utility that would talk with CQRLOG over tcp/ip or udp and runs on host system. CQRLOG would send a request and get back signed file. That could work but it's another app that we have to take care of :(.
Mysql is not a problem, there is a way how to store data into .config/cqrlog also when running in a snap but it's not a good idea. Much better would be to use standart snap way how to store the data. Or even the best is to use external MySQL server. That would be the best way but only for technical people. There are many users without knowledge how it works internally, so I would prefer to have as easiest install and usage as possible. It should work without reading manual or doing some tweaks.

Publishing only the binaries is the same problem. You have to take care of backuping original file, it will be different from that installed by package manager etc. Releasing whole directory with complete files is better. It's creating automatiall when you run script from tools/new_version with beta parameter. That has also some disadvantages e.g. database changes, you may not return back to stable version.

Auto creating of snap/flatpack/appimage would help a lot. It seems the appimage could be the best because it should be possible to run app outside the image.

Snap

Submitted by oh1kh on

Thanks for explanations!
Maybe I do not see the problem running wsjt-x/fldigi from startup menu (or icon) separately from cqrlog as I have always done that. Simply because cqrlog crash won't kill wsjt-x/fldigi then and you can finish ongoing qso. Not so common nowadays but was with cqrlog 1.9.XX versions.

Tqsl is problem and there is no mind to make external additions for that as you say.

External Mysql server should not be a problem to anyone because when you install linux and select database server there it is up an running when you start linux usage. And almost the same if you install it later with packet manager. Server is ready running after install.
Only thing is to grant cqrlog user to connect and use database. Just a command that can be scripted, too.
Backup is bit more complicated than copying the ~/.config/cqrlog folder, but also that can be scripted.

Idea of copying just binary gets better when copying also other folders, not overwriting user data, getting help and other stuff there up to date.
Some programs have that kind of system built in. They suggest to load new version (that must be stable). Loading alpha/beta could be option from menu.
Before loading new version cqrlog could backup itself and user's data. Then returning would be easier in case it is needed.

We should not underestimate users. When the have chosen linux they are not average Windows-cattle, or then have an Elmer lying somewhere.
When I remember back times in local support I must say that Windows program installs are not any easier, or then the world has changed a lot in five years.

But these are just thoughts.
It seems that every way has it's good and bad sides.
The goal must be easy to maintain system with reasonable short interval of new version releases and/or ability to test alphas with own risk without doing the compile.

Ideas are welcome, also from others !

sm0rux's picture

Upgrade on hold

Submitted by sm0rux on

Hi,

Using Xubuntu 18.04. The update is hold back when using sudo apt update && sudo apt upgrade.

73's de SM0RUX Pontus

download link

Submitted by CX1FK on

debian package there is a quotation mark in the download link, after cqrlog_2.4.0-1_amd64.deb, it produces a 404 error when trying to download it

sp6ina's picture

rotor control

Submitted by sp6ina on

Do you plan the rotor control and graphical view of rotor to cqrlog?

rotor control

Submitted by oh1kh on

Hi!
Cqrlog has rotor control via hamlib rotctld.
At preferences set ROT control: the path to rotctld, rotor model 1 and check "run rotctld at program start" and you can simulate it without any rotor.

Open window/rotor control, enter a callsign to new qso and set cursor to rst fields (press Tab once so that DXCC info for callsign is filled). Then press rotor control window's short or long path button and rotor will turn towards the station whose callsign was entered.
If you actually have rotctld supported rotor connected (other model ID than 1) your rotor actually turns!

As far as I know there is no plan for graphical rotor view but keeping grayline and rotor control windows open gives quite good start (grayline shows only short path)