Description of problem: Install cqrlog on raspi 3 (Fedora 25) and try to start it up. First it seems that something is preventing communication with the database server (MariaDB) on localhost. Did the usual things (disable selinux and kill firewalld) and this part started working. However, the program fails to display any windows (local or remote display). Curiously xfce taskmanager shows that the windows are there but there is nothing on the screen. The only window that shows is the initial question about the local vs. remote storage of log data. The same version of cqrlog works fine on x86_64.
I went through the build logs of both the arm and x86_64 builds and couldn't find any differences that stuck out to me. We can try a simple rebuild but there's not much to go on...
You can try this scratch build to see if it makes any difference: dnf reinstall https://kojipkgs.fedoraproject.org/work/tasks/9724/16259724/cqrlog-2.0.2-1.fc25.arm7hl.rpm The package isn't signed so dnf may complain about that...
I rebuilt it but no difference in behavior. I suspect that the problem is with one of the libraries etc. that cqrlog relies on. The only thing that I can see is that the executable somehow looks different: Compare the output from "file /usr/bin/cqrlog" and "file /usr/bin/ls" the cqrlog binary does not use shared libs. Probably not relevant. Are there any other programs based on fpc/lazarus that we could try to see if they run?
Looks OK to me: $ file cqrlog cqrlog: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.0.0, BuildID[sha1]=dfc9c2ec449d9032d7b6846b4000c90a294d5e3e, stripped ldd doesn't work but I think that's because on my x86_64 system it doesn't understand arm.
[eloranta@localhost ~]$ file /usr/bin/cqrlog /usr/bin/cqrlog: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.0.0, BuildID[sha1]=a6b38544d6abc0bc770cbc718f7d7c7fb7d5ffc4, stripped [eloranta@localhost ~]$ file /usr/bin/ls /usr/bin/ls: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=9092e8ee771b26479e355d752ce878a3558417ff, stripped and ldd /usr/bin/cqrlog not a dynamic executable whereas ldd /usr/bin/ls gives the usual list of shared libs. OK, sorry, it seems that it is dynamically linked but somehow ldd does not work on it. I don't know enough about the different binary formats to say what the above means exactly.
One more strange observation: I general, it fails to display any windows (except the question dialog of initializing new database or using remote). Even the initial splash window (CQRLOG with the vibro key) fails to show. This behavior includes the local display and another (new; fedora 25) computer with both intel and nvidia (closed source) drivers. However, I just got it to start normally on an older computer (up to date fedora 24) with an ATI card (using the standard video driver)!! I have also tried gnome3 and xfce desktops. gnome3 does not react to starting it at all whereas xfce somehow shows the windows in the task manager but not on the screen. So, this is probably something "bigger" than just cqrlog...
Forgot to say, the new/old computers above were the remote displays.
The Lazarus IDE does not start either. It behaves exactly the same way as cqrlog. XFCE is somehow aware of the window but does not display it. So, this problem is somewhere with lazarus.
At present cqrlog seems to start OK on remote displays but not on local. This is with up to date FC 25. Same situation with Lazarus.
OK - more testing. If I run openbox, I can start cqrlog and lazarus just fine. The issue seems to be with xfce. Also, if the remote display is running xfce, nothing shows up. Interestingly, if cqrlog is run on intel & local (or remote) display, it works fine (even with xfce). It seems to work also with mate (remote display) although the initial splash screen does not display. So, starting it up under openbox (local display), shows that it mostly works. Unfortunately, there is something messed up with the fonts. The dx cluster window and band map attempt to display the text but I am guessing that the font size is something very small. Changing the font settings crashes the program (although it shows that the font setting should be OK). The font issue also appears if I run it over the net to a remote display. I have run these with xorg. wayland & x emulation seem to work too but suffer from the above font issue.
It has probably something to do with the way Lazarus uses some API's. It could be that Lazarus does something legit bu that xfce did not implement the API's right. Or it could be that the problem is in Lazarus but that it works on other display-managers as a coincidence. So it is really difficult to investigate this. But could someone first try the new 1.6.2 Lazarus update?
Ok, there's a update coming to fpc which fixes builds for ppc64. That would be a good time to rebuild cqrlog. Has lazarus been rebuilt for pp64 yet?
With updates from the test repo as of today, cqrlog starts correctly under xfce. The dxcluster font is still messed up (it seems that it is extremely tiny font and that cannot be changed in any way using the font settings) and the text in menu items looks different from what they are on intel (not a big deal). So, something got fixed probably in the x-server or elsewhere. I did not see the fpc update yet but I will try to recompile cqrlog (from git) as soon as it becomes available. Jussi
OK, at this point cqrlog starts correctly but has serious font issues at least in DX cluster window, reverse beacon window, and in the initial "Version Changes" window. It looks like the font is very small (just a few pixels). None of the font settings affect this in any way. This happens only on arm (Raspberry PI 3). I just tried - for fun - the git version of cqrlog with Lazarus 1.8 RC3 and fpc 3.0.3 (that comes with it). No cigar, the problem is still there. One clue might be that it is spitting out the following warnings on the terminal window: (cqrlog:24201): GLib-GObject-WARNING **: value "-nan" of type 'gdouble' is invalid or out of range for property 'page-size' of type 'gdouble' when those windows are opened. I bet that this is some kind of issue with lazarus on arm (and most likely not cqrlog itself). Jussi
That being the case, should we change the assignment from cqrlog to fpc or lazarus? Probably would be a good idea to open up a bug upstream and link it to this one for tracking purposes.
Ha! Finally made some progress. If I set the DX Cluster window font size to zero, the text starts displaying correctly. Also, keeping the "use default fonts" seems to keep the Reverse Beacon window going. Bandmap is still a bit unstable but mostly also works. Of course, the problem is that one cannot change the font size for the dx cluster window - it is what you get. But, at least, cqrlog is now usable! The "new features" window still does not show anything but who cares ;-) So, for sure, this is a problem with lazarus (it is handling the fonts). Jussi
Sorry, forgot. I had to also set font size to zero for band map. Otherwise it would not display anything.
Reassigning to lazarus...
In addition to fonts, there are couple of other problems (presumably also lazarus/fpc related on arm): - Clicking on any scroll bar will abort the program (this with gtk2). Terminal shows "TApplication.HandleException Access violation" and a stack trace. - Dialogs showing progress bars do not display. They complain (in terminal) that the progress indicator value has to be between 0 and 1. Both of these problems are also present in the new lazarus 1.8 RC3 and fpc 3.0.3 (as well as the ones supplied by F26). Everything works ok on intel.
By the way, you will see the scrollbar problem already with lazarus-ide. Start it and clicking on any scrollbar will cause abort (both current and the RC3). For fun, I also tried compiling cqrlog with qt4. Scrollbars work but in most windows text is placed in the upper left hand corner of the window (everything on top of each other). So neither lazarus gtk2 or qt4 work correctly on arm (raspi 3). I tried looking into the scrollbar issue with gdb but it shows that it crashes somewhere quite deep inside gtk2 :-(
OK, I made some progress diagnosing this problem. I took cqrlog binaries from Debian and tested them. They have two variants: cqrlog_2.0.5-3_armel.deb cqrlog_2.0.5-3_armhf.deb The binary taken from the first one crashes the same way as I have reported on Fedora. Clicking on scrollbar etc. crashes the program. Taking the cqrlog binary from the second .deb file )armhf) on the other hand works great! All font problems are gone, scrollbars work etc. So, clearly, this has something to do with the floating point stuff. Note that all the warnings that also appear on terminal are floating point related. The armhf binary does not output any such warnings. I believe that there are two variants of fpc compiler one for hard and the other for emulated floating point operations? So, is there a confusion about this in Fedora?
Any progress on this? Lazarus, fpc and cqrlog are unusable on fedora arm. Since debian did this right, the solution should be out there.
Also, fpc is available for aarch64 (raspberry pi 3 in 64 bit) and cqrlog does compile under this arch. The debian folks have this working (one can get the binaries from debian and install the binaries on fedora aarch64).
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
I saw arm updates to fpc and lazarus - maybe cqrlog log would now compile correctly on arm?
Still has issues on ARM... https://koji.fedoraproject.org/koji/taskinfo?taskID=25323740
I was able to compile cqrlog from their git repo with the current fpc / lazarus on raspberry pi 3. I see in the git log the following: Author: ok2cqr <petr> Date: Sat Feb 24 12:14:54 2018 +0100 fixed compiling on armhf I wonder if this was done after the release that you have? (also not fully sure that this is the same thing that you saw...)
I was just going to pick the arm fix but there was a lot of good stuff in the commits so I created a patch to update 2.2.0 to master and I am doing a scratch build now to verify it builds.
The build is failing due to the problem with the glibc pthread library issue right now. I'll try again when it's resolved.
Now waiting for fpc 3.0.4 and lazarus 1.8.x to find their way into F26 & 27 before I can do builds...
For 27, they are in updates-testing. Not running 26 any more, so don't know if they are there. And next, aarch64 but I suppose the fpc support is not in their stable release yet.
Actually, I don't like fpc 3.0.4 being in fpc27-testing... It would be better to merge only the fix to f27... I'll see if I can correct this still.
Well 3.0.4 is a patch level release compared to 3.0.2 so why should it not be built for all supported Fedora releases? Cqrlog requires 3.0.4 so I will not be able to build it otherwise.
I second that. Please don't take 3.0.4 out - we finally have fpc that can compile cqrlog!
While 3.0.4 might officially be a patch level release, the changes are really huge compared to the prior versions. I have a few project that won't compile with 3.0.4, and some that will compile but will have some bugs when compiled with 3.0.4, so I'll have to add an update-exception on my build-machines when fpc is being updated in F27. Does Cqrlog really need fpc 3.0.4, or does it need the hardware-floating point fix which came along version 3.0.4? I did a quick test with fpc 3.0.2 and lazarus 1.6 and it builds totaly fine. (When I remove the version-requirement in the .spec file, that is) Can you test with this scratch-build? https://koji.fedoraproject.org/koji/taskinfo?taskID=25528773
Thank you for elaborating on the problem. I no nothing about lazarus so if you want to send me a patch (or do a pull request) and we can verify that nothing from 3.0.4 is needed I'm fine with that.
fpc-3.0.2-4.fc27 lazarus-1.8.0-4.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-b6e484dff7
fpc-3.0.2-4.fc27, lazarus-1.8.0-4.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-b6e484dff7
fpc-3.0.2-4.fc27, lazarus-1.8.0-4.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.