diff --git a/source/_posts/2015-09-05-building-kde-libraries.markdown b/source/_posts/2015-09-05-building-kde-libraries.markdown index de557a4..5f1f8b2 100644 --- a/source/_posts/2015-09-05-building-kde-libraries.markdown +++ b/source/_posts/2015-09-05-building-kde-libraries.markdown @@ -18,13 +18,17 @@ Unable to create io-slave: klauncher said: Unknown protocol 'trash'. ``` Oh, well. So I guess the FreeBSD port for Digikam fails to list a -required dependency. +required dependency. Fixing this is a long (ongoing) journey, +with lots of interesting adventures all along. This is not a step +by step buid, but a series of notes about various traps I fell +on the way. -Building KDE workspace -====================== +KDE libraries versioning +======================== -A little grep'ping in port plists hints that the missing dep -might be x11/kde4-workspace. Alright, let's build that. +Executive summary: you cannot build KDE libraries (such +as sysutils/kfilemetadata) of a given version if it does +not match exactly the installed version of kdelibs: ```plain Build log [...] @@ -33,13 +37,10 @@ pkg-static: Unable to access file /var/ports/work/usr/ports/sysutils/kfilemetada *** Error code 74 ``` -The kfilemetadata fails to install. That file is indeed missing; the staging area +kfilemetadata fails to install. That file is indeed missing; the staging area does however contain a libkfilemetadata.so.4.14.2. So why does the source package of 4.14.3 generate a 4.14.2 library? -A trip in KDE-build-land -======================== - Answer: the library version is not set by the package itself, it comes from a default value from: o @@ -58,14 +59,6 @@ $ pkg which /usr/local/share/apps/cmake/modules/KDE4Defaults.cmake Conclusion: the build dependency for kfilemetadata should list the exact same version of kdelibs, or the port won't build. -So, we now need to upgrade kdelibs in order to be able to build kfilemetadata, which -is a dependency of kde4-workspace, which is an unlisted dependency of Digikam. - -Rebuilding kdelibs from sources involves a portmaster operation that will on this -system rebuild a few hundred depedencies, so doesn't sound like an attractive option -(too big a build to babysit, with likely hiccups on the way, and in any case too -much of an earthquake with so many ports being updated at once. - Upgrading kdelibs ================= @@ -86,26 +79,38 @@ $ digikam Strange that libpng 1.6.16 does not have version 16... Sigh... OK, upgrading from png-1.6.16 to png-1.6.18 appears to fix the problem. Back on track... -Back to KDE Workspace -===================== - -Side note: hey, couldn't I just install kde-workspace from packages as well? Well, -for some reason pkg wants to remove my TeXlive install, and upgrade two dozen other -packages, so thanks, but no thanks. (I would have gone for it were it not for the -removal of TeXlive. But that's too much breakage to fix downstream.) - Now Digikam displays its splash screen and starts initializing, then segfaults. Hell, I'll have to bite the bullet and upgrade a few hundred packages from ports. :-( -portupgrade: Be Afraid, Be Very Afraid -====================================== -```plain -# portmaster -dvw digikam -``` +VLC ports variants +================== + +The vlc port by defaults depends on QT5, whereas the rest of the +KDE system depends on QT4. You can rebuild vlc with the QT4 option, +but that's not quite sufficient: actually phonon (part of KDE) +depends explicitly on slave port vlc-qt4 (so you can't just install +vlc with QT4 option, you have to go through the separate slave +port). + +OpenSLP +======= + +Digikam does not segault anymore, CUPS is repaired (I had to reinstall +it somewhere in the process, as it would silently fail to startup +due to a missing symbol) but I still cannot delete photos. On second +guess, the missing item might be kde4-runtime, not kde4-workspace. + +Here the dead end is quickly reached: x11/kde4-runtime depends on net/openslp, +which won't build because of a security vulnerability... Oh well, let's +build with `DISABLE_VULNERABILITIES=yes`... -(It's beyond my understanding why `-w`, i.e. "Keep old shared libs in the hope of not rendering -other applications unusable" is not the default) +Epilogue +======== -As a corollary, I'll have to upgrade to GnuPG 2.1 (dependncy of `security/gpgme`) -- I had so -far carefully stuck with `security/gnupg20`. +At long last, small victory: the missing piece was indeed x11/kde4-runtime. +The problem has been `reportd `. +I must admit I'm getting sick and tired of the amount of breakage I need to +investigate and fix most times I want to install something using the ports system. +Desktop work nowadays requires humongous dependency closures that are extremely +fragile, and I'm very much tempted these days to switch back to Debian for that.