Arch Linux User Repository

Same here. The issue is that in src/dialogs/guide.cxx in line 738, 739 and 740 there are stray 0x0d (CR/carriage return) characters. Something went wrong somewhere (commit from Windows?).

This patch fixes it (can't post it literally here, because the CR character would probably get mangled):

https://effekthasch.org/Ohseiz9Rui0Thah/fix-fldigi-aur-dialogs-guide-cr.patch

Does not build... It looks like there is a html page with included javascript that throws tons of errors so that the name of the file itself or any further informations have left screen buffering. Occurs on all of my machines.

(my turn) - UPDATED to ....14-1 .

@freswa works fine, thank you! Now I see that there is libxft among other deps of fldigi:

/usr/bin/fldigi (interpreter => /lib64/ld-linux-x86-64.so.2)
    libflxmlrpc.so.1 => /usr/lib/libflxmlrpc.so.1
    libportaudio.so.2 => /usr/lib/libportaudio.so.2
        librt.so.1 => /usr/lib/librt.so.1
        libasound.so.2 => /usr/lib/libasound.so.2
        libjack.so.0 => /usr/lib/libjack.so.0
            libdb-5.3.so => /usr/lib/libdb-5.3.so
    libpthread.so.0 => /usr/lib/libpthread.so.0
    libfltk_images.so.1.3 => /usr/lib/libfltk_images.so.1.3
        libjpeg.so.8 => /usr/lib/libjpeg.so.8
    libpng16.so.16 => /usr/lib/libpng16.so.16
        libz.so.1 => /usr/lib/libz.so.1
    libfltk.so.1.3 => /usr/lib/libfltk.so.1.3
        libXext.so.6 => /usr/lib/libXext.so.6
        libXfixes.so.3 => /usr/lib/libXfixes.so.3
        libXrender.so.1 => /usr/lib/libXrender.so.1
        libXft.so.2 => /usr/lib/libXft.so.2
            libfreetype.so.6 => /usr/lib/libfreetype.so.6
                libbz2.so.1.0 => /usr/lib/libbz2.so.1.0
                libharfbuzz.so.0 => /usr/lib/libharfbuzz.so.0
                libfreetype.so.6 => !!! circular loop !!!
                    libgraphite2.so.3 => /usr/lib/libgraphite2.so.3
                    libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0
                        libpcre.so.1 => /usr/lib/libpcre.so.1
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1
            libexpat.so.1 => /usr/lib/libexpat.so.1
    libm.so.6 => /usr/lib/libm.so.6
    libX11.so.6 => /usr/lib/libX11.so.6
        libxcb.so.1 => /usr/lib/libxcb.so.1
            libXau.so.6 => /usr/lib/libXau.so.6
            libXdmcp.so.6 => /usr/lib/libXdmcp.so.6
    libdl.so.2 => /usr/lib/libdl.so.2
    libsndfile.so.1 => /usr/lib/libsndfile.so.1
        libFLAC.so.8 => /usr/lib/libFLAC.so.8
        libogg.so.0 => /usr/lib/libogg.so.0
        libvorbis.so.0 => /usr/lib/libvorbis.so.0
        libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2
    libsamplerate.so.0 => /usr/lib/libsamplerate.so.0
    libpulse-simple.so.0 => /usr/lib/libpulse-simple.so.0
        libpulsecommon-13.0.so => /usr/lib/pulseaudio/libpulsecommon-13.0.so
            libdbus-1.so.3 => /usr/lib/libdbus-1.so.3
            libsystemd.so.0 => /usr/lib/libsystemd.so.0
                liblzma.so.5 => /usr/lib/liblzma.so.5
                liblz4.so.1 => /usr/lib/liblz4.so.1
                libgcrypt.so.20 => /usr/lib/libgcrypt.so.20
                    libgpg-error.so.0 => /usr/lib/libgpg-error.so.0
            libasyncns.so.0 => /usr/lib/libasyncns.so.0
                libresolv.so.2 => /usr/lib/libresolv.so.2
    libpulse.so.0 => /usr/lib/libpulse.so.0
    libhamlib.so.2 => /usr/lib/libhamlib.so.2
        libusb-1.0.so.0 => /usr/lib/libusb-1.0.so.0
            libudev.so.1 => /usr/lib/libudev.so.1
    libstdc++.so.6 => /usr/lib/libstdc++.so.6
    libgcc_s.so.1 => /usr/lib/libgcc_s.so.1
    libc.so.6 => /usr/lib/libc.so.6

Checkout the latest fltk.

@freswa I already have fldigi installed and working. If I install fltk from [community] then fldigi doesn't start up at all - you can see that there no dependencies on libxft and related libs in lddtree output. However if I rebuild fltk from community with -DOPTION_USE_XFT (and only with that) then fldigi works fine. No need to rebuild fldigi itself, it's only related to the fltk package

We don't fix packages that are not broken. fltk is working for all our rebuilds, so it's up to you to file a proper bug report which points us to a reproducible error in a clean chroot. Your bug report states, that the application doesn't run. I compiled fldigi several times against fltk in [community] and the application started fine for every rebuild.

If you need help debugging, please feel free to ask for help in the forum, the IRC or on the ML.

Unfortunately, my request for rebuilding fltk with Xft support was unsuccessful. This is the answer from project manager:

FS#67089 - [fltk] Update to 1.3.5-2 prevent fldigi and dl-fldigi to work
User who did this - freswa (frederik)

Reason for denial:
fldigi works for me with fltk from the repos.

Famous "works for me", sad

Actual fix for that is to enable -DOPTION_USE_XFT=ON during CMake call in PKGBUILD and add libxft dependency where needed

@mh00h great work! but I still don't understand - it's only a matter of specifying libxft in makedepends. when I tried to build 1.3.5-2 by hands I got the problem but when I built 1.3.5-3 (modified by me in the same way as maintainer did with the exception of changing dependencies) things worked fine

For those who are still struggling with this, the issue turned out to be that a dependency, fltk, is not compiled with --enable-xft in the official arch repo.