Re: Findings from test compile of KDE

On 8/16/26 6:16 AM, sicarine ([email protected] via blfs-dev Mailing List) wrote:
> Morning,
> 
> Last night I had a go at testing some plasma packages on my system, so I
> thought I might email with some findings. I tested KF6 6.29.0 with gear 26.04.3
> and plasma 6.7.4.
> 
> Four new packages are required: corrosion-rs is now a dependency of kdeplasma-
> addons, tesseract is now a dependency of spectacle (and it itself depends on a
> package called leptonica), finally kmime is now part of kde frameworks.
> 
> Oxygen-icons have also been brought into frameworks as well. When I wrote my
> install list for kf6, I commented it out during the bulk install just like
> breeze-icons.
> 
> Corrosion-rs probably makes rust an indirect dependency of plasma.
> 
> It seems phonon dependency has been reduced. It's likely that the only in-book
> package that still depends on it is Okular, however I still have phonon stuff
> installed and could not fully verify this.
> 
> My system has opencv-5 installed, and it seems that kquickimageeditor-0.6.2.1,
> spectacle, and kdenlive built fine with opencv-5 libraries and headers on the
> system. Frei0r and MLT still require patches for now. I know that KDE is
> aiming to reduce dependency on opencv, so that's probably what I'm seeing.
> Worth double-checking this, as I have deviated from the book here.
> 
> Tesseract is a pain. It takes a while to compile, and seems to require some
> runtime launguage pack stuff to function. I haven't bothered to deal with that
> yet, since I don't currently have a need for OCR software. But the base
> package alone is enough for spectacle not to complain during compile.
> 
> Only interesting warning while compiling KDE stuff is the following, but it is
> not fatal, and I think is an old warning we've seen before.
> 
> CMake Warning at /usr/share/ECM/kde-modules/KDEInstallDirsCommon.cmake:169
> (message):
>    KDE_INSTALL_LIBEXECDIR got its value from CMAKE_INSTALL_LIBEXECDIR.  In
>    most cases this is unintended, check if you included GNUInstallDirs before
>    KDEInstallDirs.  Some third party modules include GNUInstallDirs too so eg.
>    find_package(Qt6 ...) is equivalent to include(GNUInstallDirs).  If you set
>    CMAKE_INSTALL_LIBEXECDIR deliberately before including KDEInstallDirs its
>    recommended to use KDE_INSTALL_LIBEXECDIR instead to suppress this message.
> Call Stack (most recent call first):
>    /usr/share/ECM/kde-modules/KDEInstallDirsCommon.cmake:270 (_define_relative)
>    /usr/share/ECM/kde-modules/KDEInstallDirs6.cmake:203 (include)
>    /usr/share/ECM/kde-modules/KDEInstallDirs.cmake:17 (include)
>    CMakeLists.txt:10 (include)
> 
> ~~
> That's it about it. Things seem to be working fine on my end. Nothing broke.
> Nothing seems to have installed in the wrong place, no lib64 directories
> sprung up, nothing ended up in /usr, so seems fine. All good.

Thanks for the report.  I will not be able to get to KDE for about a week but this 
will be very helpful for me when I am updating the book for BLFS-13.1.

   -- Bruce

-- 
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page