New info

source/_posts/2015-03-05-bizarre-packet-filtering-on-ovh-kimsufi-server.markdown

@@ -78,6 +78,10 @@ investigate, and resolve the problem.
 observed anymore. OVH indicates they are still discussing the underlying
 issue with Cisco, and the fix is not completed yet.
 
+**Update 2015-06-17** Service remains stable. OVH indicates that they have
+identified the origin of the issue, a fix is available, and they have
+scheduled its deployment.
+
 Acknowledgements
 ================
 

source/_posts/2015-09-05-building-kde-libraries.markdown

@@ -0,0 +1,98 @@
+---
+layout: post
+title: "Digikam, dependencies, and building KDE libraries"
+date: 2015-09-05 12:49:51 +0200
+comments: true
+categories: 
+---
+
+Context
+=======
+
+I have a very basic KDE environment, just enough to be able to run
+Digikam. Anytime I try to delete a photo, I get an error message:
+
+```
+Could not start process
+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.
+
+Building KDE workspace
+======================
+
+A little grep'ping in port plists hints that the missing dep
+might be x11/kde4-workspace. Alright, let's build that.
+
+```Build log
+[...]
+===>   Registering installation for kfilemetadata-4.14.3_2 as automatic
+pkg-static: Unable to access file /var/ports/work/usr/ports/sysutils/kfilemetadata/work/stage/usr/local/lib/libkfilemetadata.so.4.14.3: No such file or directory
+*** Error code 74
+```
+
+The 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
+
+```/usr/local/share/apps/cmake/modules/KDE4Defaults.cmake
+set(GENERIC_LIB_VERSION "4.14.2")
+```
+
+Where does this come from?
+
+```
+$ pkg which /usr/local/share/apps/cmake/modules/KDE4Defaults.cmake
+/usr/local/share/apps/cmake/modules/KDE4Defaults.cmake was installed by package kdelibs-4.14.2_5
+```
+
+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
+=================
+
+Let's instead upgrade kdelibs from binary package, and hope for the best:
+
+```
+# pkg install -f kdelibs
+```
+
+This breaks because the binary package depends on a newer libpng, so let's upgrade this one,
+keeping the old shared lib intact just in case.
+
+```
+$ digikam 
+/usr/local/lib/libpng16.so.16: version PNG16_0 required by /usr/local/lib/libkhtml.so.5 not defined
+```
+
+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. :-(