Hi!
Beta test binary is now uploaded to my web page.
This is a big update.
I like to thank Andreas, DL7OAP, for his great help, Without his help this beta may never appeared. It is lot more easier and fun to make cooperative programming work and discuss different options and problems in daily basis.
Similar changes are pull requested to official version, so unless major bugs are found under beta test they should be equal. Depending of official's release time it may have some more additions/bug fixes included.
This beta version ALTERS YOUR LOG DATABASE. So read and take serious the warning text you will find inside the zip file !!
After installation of 217 I get:
Database upgrade crashed with this error:
TMySQL57Connection : Error executing query: Duplicate column name 'stx'
Clicking OK, CQRlog seems to work...
EDIT: Does NOT work, being unable to log the finished QSO. Returning to 216 which worked for me. Will possibly make a pause with beta testing, I need to be ACTIVE (!).
BAD beta, at least for me!
73,
Martin, OK1RR
Hi Martin,
when you are on database version 15 you shouldn't have a stx column in your cqrlog_main.
did you perhaps compile and use our develop version from github before?
the upgrade of the database is like the updates before, no special functions have been inserted there. the only column where we expect trouble is column "info" in table "freqmem", because some beta user will have this column allready.
you can reset the database upgrade of version 16 with the following statements.
on the next start it will start the upgrade again.
ALTER TABLE cqrlog_main DROP srx_string;
ALTER TABLE cqrlog_main DROP srx;
ALTER TABLE cqrlog_main DROP stx;
ALTER TABLE cqrlog_main DROP stx_string;
ALTER TABLE cqrlog_main DROP contestname;
DELETE FROM db_version;
INSERT INTO db_version (nr) values ('15');
DROP VIEW view_cqrlog_main_by_callsign;
DROP VIEW view_cqrlog_main_by_qsodate;
DROP VIEW view_cqrlog_main_by_qsodate_asc;
when you get the same error again after this cleaning, we have to look what is special on your system.
73 de DL7OAP, Andreas
Hi!
Do you have Maridb or Mysql instaled ?
[saku@hamtpad ~]$ mysql --version
mysql Ver 15.1 Distrib 10.2.22-MariaDB, for Linux (x86_64) using readline 5.1
Checking "info" column (from previous beta binaries) in database upgrade to 16 seems to work only with Maridb. I think quite many distributions use Mariadb now, but there still exist ones that have Mysql running.
I will put new beta test binary 218 with a bit different way of checking existing "info" column as soon as I get it ready.
--
Saku
OH1KH
Saku,
$ mysql --version
mysql Ver 14.14 Distrib 5.7.26, for Linux (x86_64) using EditLine wrapper
Of course, I can change the engine to MariaDB but:
If this is the culprit, it means that there is another "new" dependence. This is the way opposite to the way we go. Any modern distro has MariaDB as an alternative, CQRlog should enforce to use this, or at least give the info what to do. The message
Database upgrade crashed with this error:
TMySQL57Connection : Error executing query: Duplicate column name 'stx'
is very insufficient and confusing!
Hi Martin,
just be aware that beta means beta.
the early beta versions from oh1kh/saku are a plattform where we are developing in a very agil style and we are thankful for every friendly hint when you found a bug or a mismatch in this early beta.
when you need to be active... then please use cqrlog stable version or the official beta versions from cqrlog. only there it is ensured that a lot of people has tested it and that Petr has accepted it and merged it, to his main master branch.
73 & Andreas, DL7OAP
Andreas (DL7OAP),
thanks for your lecture. You possibly overlooked that I am one of CQRlog originators. Look on the splash screen, please. Do you believe that I don't know what menas "beta"? Would you allow me to hope that an announced "beta" works?
My criticism goes to the fact that the program displays an confusing error message. The main problem with 217 is in accompanying documents - there is no warning about possible MyQSL/MariaDB conflict, even if this fact is already known.
My ideas about CQRlog development are sometimes different from Saku. My comments are quite rare. Anyway, I would be grateful if my comments will be taken with attention appropriate to my position in CQRlog development.
73, Martin, OK1RR
Hi Martin,
i am absolute aware that you and Petr has create cqrlog.
and i am absolute thankful and glad that you build a good linux ham suite which not have to hide behind the other "ham offices".
and i am absolute aware that you must have put a lot of voluntary time in cqrlog.
and, yes, i want also to deliver stable cqrlog versions with meaningful error messages.
and, yes, i want to help that cqrlog is up-to-date by helping beta testing or helping saku (or you with developing).
the only thing i want you to notice, in my IMHO, is, that there a 3 stages of cqrlog versions.
maybe this is not clear to everyone or it should be separated for the future:
- the official cqrlog stable version (https://www.cqrlog.com/download)
- the official cqrlog beta versions announced by petr, ok7an (https://www.cqrlog.com/node/1777)
- and the, "early beta versions" of saku, oh1kh on his webside (https://www.cqrlog.com/node/2243)
and of course a beta should be stable. you are absolute right here.
but the early beta versions are one stage before the official cqrlog beta versions.
and between this two stages many people are testing the "early beta versions" of saku, we get the feedback, we improve the early beta versions, and when a early beta versions seems to be stable, we do a pull request for the "official beta version". and there Petr (and you) have a review on the code and accept the pull request or rejected it.
so IMHO the "official cqrlog releases" and the "official cqrlog beta releases" should be clearly stable.
maybe we have to make it in the future more clear what is the difference between a official beta release and the beta releases of saku, oh1kh. i will discuss this with saku.
Martin, aside of this, it would be a great help if there would be a guidiance from you and petr as chief developer.
and i, of course, welcome every hint from you to get better cqrlog releases.
like in scrum it would nice if you can give epics or stories which way cqrlog should go.
We ask, Petr, in Nov/Dec 2018 to do the database upgrade, but it was not possible, so we did it now ourself.
it would be a great help if you or Petr give us feedback, where to go.
And, of course it would be nice to have some more amateurs, who give "early beta feedback" and how helps to develop cqrlog for the future.
so.. back to work and development of cqrlog :-)
55 & 73 de DL7OAP, Andreas
Hi!
No, it is NOT a new dependence.
We will fix that in way that works in both databases, It actually was there so at one version level of developing. There was no Mysql based computer to test with and notice that before release.
Duplicate column name 'stx' happens because database update went partially ok. There is no (simple) way to do upgrading "on background" and then, if no errors happened switch to update version.
Remember I specially warned to take backup of everything before trying this beta. So recovering takes only couple of seconds to copy all back. (unless you are using external database server when it may take little longer).
We do our best to release error free versions, but cqrlog is so big program that testing is hard. Specially when users have different kind of OS setups in use.
To do proper testing we need several testers with different setups and organized test schedule. That is what we do not have. Neither we do not have proper developing team.
I'm more than happy to do cooperative programming with Andreas, DL7OAP. Now I have someone to discuss with and get great help to my poor programming skills. But that does not make a developing team in a way many other ham programs have.
I think releasing beta binaries I a best what we can do and wait fingers crossed that we get feedback if something goes wrong. It is less harmful than let error go through up till official version.
--
Saku
OH1KH
Hi,
I already fixed that. MySQL does't support IF NOT EXIST in ALTER command. Please be more careful when adding new things. I had to fix my database manually and that is really not what I want to do. These database upgrades has to be very stable and tested.
Next, please stop adding all the features that every one want just dropping one line to the forum. A few days ago I downloaded recent source code from github and even cannot compile it, also already fixed. What makes me really sad is broken TRX window. Some like that is called Memory was added. What is that for? I told Saku that every new feature should be disabled by default. I do not want turn CQRLOG to a monster. I'm also not a big fan of digital modes. Hamradio was always about communication. Please tell me what do you communicate using FT* modes? If I want to let computer to talk each other, I connect them to the network, not to my radio.
I know it's my fault because I don't have time to develop CQRLOG on daily basis. I work like a dog and have barely time to be on the air.
About the partial update. That problem exists because of MySQL < 8.0 that doesn't support transaction when using CREATE, ALTER and DROP. New version should fix that but it will take years to get to all corners of Linux world.
73 Petr
--
http://HamQTH.com/ok2cqr
https://ok2cqr.com
Hello,
i managed the Update as following:
Saved my Configuration and my Log,
changed the Binary and Help Files,
with Beta 218 i created a new Log, imported my Configuration and my Log.
Now i can't upload new or changed QSO's to the Online Logs. I always got the message:
All QSO already uploaded.
73 de Heinz-Juergen
HI!
I'm more than surprised about: "I had to fix my database manually and that is really not what I want to do".
I simply can not say it clearer DO BACKUP BEFORE than dropping 2 zip files inside the other and put warming besides.
As programmer you should be aware to do backups always before testing someone else's code.
And what comes to user requests, isn't that just the meaning of program developing?
If we do not listen to user wishes and make them true, specially when they are quite simple to do, and keep program in original form we may as well keep funerals to that program.
OK. I got it.
There will be no future teasing any more with new properties.
If you do not like them do you know what other cqrlog users think?
Ham radio is about communication, but also about developing of new techniques. New communication modes like FTs make qsos possible during poor sunspot cycle with only wires and low power.
What bad there is if FT modes have activated many new hams that maybe are disabled so that working in other ways is not possible, of very difficult. Or those who can not use CW, even if they liked to. It is not foregone conclusion that everyone can learn CW.
Let also them possibility to enjoy DX contacts.
Using computer to Ham radio contacts still needs knowledge how to set up working station and what kind of contacts you can expect on certain band at certain time. It is not just "plug your internet and go".
I suggest you make a new version of cqrlog and take that out from GPL making it with closed source code. Then there are no more fools trying to make new properties to it.
I think it is now good time to start summer holiday, length unknown.
--
Saku
OH1KH
HI Saku,
It would be better if the forum could also save screenshot of my face when I wrote the last post. I really appreciate what you do for CQRLOG, I'm only afraid that CQRLOG has so many features that we can't keep them bug-free. The Preferences window has a few hundreds of options. I'm not sure if it's good.
Yes, I should make backup but I didn't. I backup the adif file when close CQRLOG but it doesn't backup all. And I also forget that there will be any database changes. My previous experience teached me that correct update is very important. When I released new stable version I got tons of emails from people who tried beta version and their database was in different state because of the alter table process didn't finish correctly. People do not do backups :(.
No, as I wrote, that is my fault. I accept the pull requests. I don't follow the development because of heavy workload. And I DONT THINK that contributors are fools.
No, unfortunately. I have TS-590SG here and the only knowledge to make my first FT8 QSO was to connect USB cable from radio to the computer, than install and run wsjtx. Yes, I had to set my callsign. That is all what I needed to know.
Making QSO means (to me) that I can feel the person on the other side. One mouse click is not that way. And when the condx are so poor that I can't make any QSO? That's the life, we are not professionals who have to make contact at any costs. That is the beauty of hamradio, you are not sure you make the QSO.
I can use CW and/or SSB even with poor CONDX and what is the best, there is still a person on other side. FT8 is not person communication, it's only between computers. Nothing more. When one computer can confirm that he can hear strange sound from another computer, that is not a QSO, at least for me.
Maybe I'm just too old to see the point. When I started I always want to be able to copy CW and took me years to learn it enough to copy directly to my head. I had to overcome a lot and maybe that is the reason why I love CW so much. It took me some time to get there. It worth for it. I'm afraid that when the operator with FT* mode doesn't have to overcome anything, he won't like the ham radio like I do. He/She leaves it very quickly and find another hobby.
Again, I'm sorry but ham radio is not a hobby for everyone, at least from my point of view.
--
http://HamQTH.com/ok2cqr
https://ok2cqr.com
Hi,
i know about heavy load. also have 8-9 hours working day, having 2 small childrens and working as voluntary in church, scouts (children work), rc modellflying club and in amateur radio club and having a garden + house ...
so i absolute can understand you petr, when you organize and plan your time and cqrlog is not in focus.
what i would wish:
1) IMHO it would be good, when you and Martin, as Chief Developer (or maybe more Chief Product Owner?) give guidiance what issues should be done and in which way. so you don't have to develop, but show a way and hold the hand over the master branch.
therefore it could help a lot, when we not build every issue which is mention forum. but when the issue list in github is well-kept (https://github.com/ok2cqr/cqrlog/issues) by you. that means, that issues are closed, which are old or obsolete and that issues are opened, which have been announced in the forum and which should find the way to cqrlog. (every issue like a story in scrum).
2) all users should be aware of the stage flow in cqrlog... a official cqrlog beta is not a early-beta. i did not spoke with saku. but in my opinion sakus version are something which are better then nightly-builds and they are not perfect stable betas.. maybe they should be labeled as alpha version. so all users have to be aware, that when you using this saku alphas.. that something can go wrong... before i develop i was a saku-beta-test user... and i was always aware that i am using the "hot end" of the software... with all the new features, but, too, with the danger of (heavy) crashs... and then its time to give friendly feedback and not to force ... force you can (IMHO) on the official cqrlog and on the official betas which are accepted and proofed by the Chief ProductOwner.
3) Sakus early beta (or should we better say alphas?) are a prefilter to have thereafter very well and on wide systems tested official cqrlog betas and there after a very stable official cqrlog. so is my point of view and notice of handling it. but it seems that some users forgot, that the alphas/early betas of saku are in a very early stage... most of the time they are tested by me and saku and maybe 1-2 friends of saku. so this is a very small bandwidth. we try our best to do pretesting.. so in the future i think, this have to get clear to all users. i would suggest to separated clearly on cqrlog webside between this two beta types or Saku should name his versions alpha, so you have not to change something on the webside.
4) petr, i think the same, about the amount on preferences and features. i like software which is clean/cleaned up and not every "nice to have" feature must be inserted. robustness and simplicity should be give more priority as every wish of the user.
what do you think for the future of cqrlog?
it would be a pity if cqrlog would get staled.
and it would be a pity if we lost Saku (oh1kh).
by the way:
I am using ft8 and it was one of my first possibilities to make far dx contacts, but i am also using cw and the last months i using the koch-method to get tempo 18-22wpm in my head. about 50% of the signs already work, the next 50% will come.
55&73 de DL7OAP, Andreas
I have used cqrlog from the first GA vesion, afterwards every betas also. Actually
I have been one the first users here in OH land and showed this program to many
ham friends. Installed it to many my friends with Linux, who never used linux
before and now they say, THANK TO DEV TEAM from THIS piece of ART!
Petr said, that FT8 is just plug usb cable into rig and let computers do the job :)
Have just a feeling, that it is not so simple. Firstly, to getting CAT working with CQRLOG
shown plenty of difficulties during this years.
From the beginning cqrlog has had modes like rtty (digital?) to choose. What's wrong
with these new DIGITAL modes?
From the beginning have been possible key CW from program, computer?
Seen people been very happy, to get DX contacts with WSJT-X, Without it, only a dream.
Some people has not skills for CW, even they try how hard. Many people has no skills
foreign languages SSB to get DX contacts.
Some people are dumb some deaf, but like HAMRADIO and like to have contacts all
over the world, these digital modes gives a change.
And with CQRLOG extensions now can be logged. I have been VERY happy, that CQRLOG
has stayed in KISS mode. Seen these monster logprogs, like HRD. If that could be the only
program, I'd turn back into paper :)
So, future... I wish, we keep logging with this simple way, no plingplin, dingledongle, just KISS.
Challenge still is, how in the h***, you guys can make cqrlog working with these 400+ linux
distributions :)
From my part, I try to report, when find something not working properly, mostly done in to Saku
avoiding "language" error, trouble with dialect errors :) :) Try to avoid my "fat fingers" errors.
Be NERD with you
<p>Jarmo</p>
I have been licensed for over 40 years. I got my first license while in primary grade school in 8th grade. I have always been a DX chasing and contesting CW operator first and SSB operator second. But in the last several years, I have started using RTTY from time to time and last year started using FT8. I really enjoy FT8 because even with marginal band conditions and low power, I can still make contacts. I've even started to work towards DXCC using FT8. Also, I'm trying to fill in WARC bands towards 9BDXCC using primarily FT8 and CW.
To Petr's point, he is absolutely correct in the fact that the computer IS making the contact. However there is also quite a bit more to it, than just that. Setting up a properly operating station, antennas, feed lines, proper grounding system, RFI and TVI suppression, computer knowledge, Linux knowledge, CQRLog experience - and knowing how to use the WSJT-X program etc. are all very challenging. There is more to it than just plugging in a USB cable and starting a log program.
I've been a faithful user of CQRLog for about 3 years. The "ONLY" reason I even considered moving to Linux over Windows, was strictly because of how GREAT the CQRLog program is. This program can pretty much do it all and that is wonderful. My hat is off to the development team. GREAT JOB !
The fact that CQRLog can now work with WSJT-X is fantastic. In fact, if WSJT-X wasn't supported, I may actually consider moving to another logging program. Just tune the bands every single day of the year - you hear lots and lots of dead space all over the bands (except during contests). Now, tune to any FT8 frequency and the band explodes with hams making thousands of QSO's around the clock. New digital modes like FT8 (FT4) should be embraced, because more and more hams are gravitating towards these interesting and fun modes of communication for the very reasons I mentioned above. CW and SSB will always be there and many, many hams use them all the time. It would be a shame if development stopped on this wonderful program.
Obviously, I am a fan of FT8 and suspect that many other CQRLog users are as well. Just look in last months issue of QST magazine and read the article about the very high amount of users that are embracing this mode. It's most definately here to stay.
Bob, WG9L
Update:
Even with a new empty log the Upload to HamQTH, Clublog and HRDLog did not work.
My upload today worked fine... To clublog Version 217
<p>Jarmo</p>
I tried deleting Log, repair Log, new empty Log, new Log with importing my Contacts, nothing worked. No upload possible. Even with the first contact in a empty Log it says, that all QSO had been uploaded yet. Must be something in the Database or the Configuration. Had these Error with 217 and 218. 216 is working fine.
Heinz-Juergen
Hi Heinz-Jürgen,
here 217/218 is working ok for me, we did not touch online log uploads in these updates.
So we have to find out what happens to your system.
Your solution ideas normaly should work (like a new log).
The uploads are tracked in a table called upload_status.
please open "Qso List" (Ctrl-O) and open menu "Filter" > "SQL console".
please start the following sql statements (just copy them into the upper box and press play button).
select * from upload_status
select max(id) from log_changes
what is the result of this two sql statements?
is the number of id_log_changes from the first query higher then max(id) from the second query?
Grüße aus der Nähe von Hildesheim, Andreas, DL7OAP
Hello,
with a empty Log I got this results:
"select * from upload_status" gives me a 1 in id_log_changes for all three Online Log
"select max(id) from log_changes" is also 1 in max(id)
same results with one Contact added. Adding (or deleting) Contacts did not change the results.
Schöne Grüße aus dem Münsterland
Heinz-Juergen
Andreas, this is weird.
Earlier versions, now 218, didn't work for me. I got allways error "could not delete
"call"" and stopped there. Now twice uploaded into clublog and went fine.
Fedora 29 distro. Is there something different , how these distros handling
database?
<p>Jarmo</p>
One Point I forgot to say.
217/218 did not load my 216 Log. It stuck on Database Loading. So for testing 218, I had to use a new Log with imported Contacts.
Heinz-Juergen
In addition to constantly developing new features and making new betas, I think it's more important to help Petr solve cqrlog problems.
For example, the latest version of Ubuntu officially supported is 18.04, but we are now at 19.10 and the program no longer installs.
Open source is a wonderful thing, but someone must also take the burden of helping to correct errors in the official version, otherwise we will find a sea of new features in beta on a dead program.
I've started to look around, especially at Log4OM on wine, but I'd be very sorry since I've been using cqrlog for 10 years.
Hi iw3hli,
what exactly is your problem? i can install cqrlog without problems in ubuntu 19.04 and in the daily build of ubuntu 19.10.
actual you "only" have to be aware the 2 main problems with appamor and gtk-libs. there are some threads in the forum to this topic.
Here a way to install cqrlog on Ubuntu 18.10, Ubuntu 19.04 and Ubuntu 19.10 (daily build):
1) install ubuntu 19.04/19.10 (i always choose the minimal version when the setup is asking)
2) sudo apt update && sudo apt upgrade
3) sudo apt install mysql-server
4) sudo apt install libgtk2.0-0 (ubuntu 19.04 and higher only have libgtk3.0-0, so you have to install libgtk2 manual)
5) #correction auf apparmor so mysld access is not denied
5a) sudo sh -c "echo '@{HOME}/.config/cqrlog/database/ r,' >> /etc/apparmor.d/local/usr.sbin.mysqld"
5b) sudo sh -c "echo '@{HOME}/.config/cqrlog/database/** rwk,' >> /etc/apparmor.d/local/usr.sbin.mysqld"
5c) sudo service apparmor restart
6) wget https://www.cqrlog.com/files/cqrlog_2.3.0/cqrlog_2.3.0_amd64.tar.gz -P /tmp
7) sudo tar vzxf /tmp/cqrlog_2.3.0_amd64.tar.gz --strip-components=1 -C /
8) cqrlog -debug=1
exactly these steps works here many times. i tested it with different virtual box installations of 19.04 and 19.10.
i will write two issues in github
a) to have a look if gtk3 is possible with freepascal, but it could be that users with old linux installations have to install gtk3 then.
b) to have a look why apparmor denied the access to mysld. this seems to be a general "bug" of ubuntu. there is a lot of stuff about this problems in the internet.
it would be nice to have feedback, if the installation routine above works for you. please make a backup of your cqrlog directory.
mv $HOME/.config/cqrlog $HOME/.config/cqrlog_backup (or some other way you want).
bye Andreas
i opened two issues for these points, so this can be discussed. every solution hint or feedback is welcome.
Ubuntu 19.04/19.10 have only gtk3. gtk2 have to be installed manually before:
https://github.com/ok2cqr/cqrlog/issues/177
Ubuntu 19.04/19.10 denies mysqld access with apparmor:
https://github.com/ok2cqr/cqrlog/issues/176
bye Andreas, DL7OAP
Hi,
cqrlog is starting without it, but it seems to be needed:
sudo apt install libcanberra-gtk-module
so point 4) is better:
4a) sudo apt install libgtk2.0-0 (ubuntu 19.04 and higher only have libgtk3.0-0, so you have to install libgtk2 manual)
4b) sudo apt install libcanberra-gtk-module
Bye Andreas