FreeBSD in Randa

There will be a BSD-centric talk at Akademy / QtCon this september. Yay!

Since it’s rainy in Randa today, I’m going to write a little about all the bits-and-pieces of FreeBSD packaging that I worked on. The *NIX-packaging BoF has given me lots of ideas, for extracting metadata and for automating bits of packaging, but nothing has crystallized around that yet.

I’ve given a little thought to the current hotness, flakpak and snappy and appstream, wondering what parts of that could work on FreeBSD and how. I have a sketch of how we could leverage ZFS snapshots and poudriere and jails to quickly define an OS layer, a platform layer, and an application layer. Using unionfs mounts these can be combined into a single filesystem, allowing quick application testing. I’m not sure about how to wrangle permissions for such a scheme, though.

But maybe these schemes aren’t all that necessary on FreeBSD (as a distro) when all is functioning smoothly (that is a major caveat). Since I was asked a few times here in Randa how FreeBSD packaging works and what the process is, I’m writing it down here.

Normally speaking, FreeBSD has two major releases that are supported. Those are 9-STABLE and 10-STABLE, at the moment. A next major release is being prepared. That’s 11-CURRENT (not yet STABLE). Those are the operating system base systems, which in FreeBSD is a great deal more expansive than in the Linux world. There’s a kernel and a compiler included, and a good chunk of userland. Together, that forms the FreeBSD distribution. Compatibility of a distribution is guaranteed for its lifetime, which I believe is generally two years. 9-STABLE is almost done, 11-CURRENT is almost ready.

The base FreeBSD distribution can vary a great deal from one major version to another: 9-STABLE uses gcc, 10-STABLE uses clang (as does 11-, but that has a much newer clang). So while the base is stable and compatible, moving between base OSses can be a challenge.

On top of the base OS, we have ports. These are all the userland programs, libraries, whatnots that have been ported to FreeBSD. “Ported,” here, means that someone has created a Makefile for it that runs in the ports infrastructure. Packages are created from the ports; because of the differences in the base OS, packages are built for each supported release (and for each supported architecture) automatically by the FreeBSD builders.

What this effectively means is that FreeBSD could be considered a rolling-release distro (when looking at it from a Linux-distro point of view). The packages are continuously updated, based on the latest ports-Makefiles.

When things are moving smoothly, ports Makefiles get updated on time, packages are built, and a user can pkg upgrade the system regularly. With ZFS snapshots a rollback after a bad upgrade can be very simple (but pkg(8) itself doesn’t have any mechanism for this).

Area51 ports processBut how to ports get updated? There’s ports committers (people) who do this. The KDE-FreeBSD project has its own repository, area51, where the K-F team assembles ports. The area51 repository is open to more (or rather, other) people than ports committers. In area51, the trunk is the last staging area before ports are sent “downstream” to the official ports tree. In other words, trunk is the “next new thing”. For instance, when new versions of software are released that the KDE-FreeBSD maintains / packages in FreeBSD are released, that is often updated in area51 first, tested with our own package builders, and then “flushed” downstream to official ports. So there’s a little shared staging area for our ports.

Area51 also has branches for “next big new thing” work. That’s for large-scale reorganization efforts (which are sometimes necessary when we discover that things are not as co-installable as we thought, or when the names of ports and packages turn out to be poorly chosen). That’s for updates that affect a lot of ports at once, like Qt updates, or new KDE Applications updates.

The diagram (that’s my epic Kolourpaint skills there, with a crystal icon-set person-icon, and fonts from Blambot) shows roughly how this works. There are two SVN repositories, with branches visible in area51. FreeBSD committers move stuff from area51 to official ports; in between the other 22000 official ports update independently.

We’re just coming off of a long period of time in which we were bottlenecked in getting stuff out of area51 — i.e. unable to flush downstream. That’s an unpleasant situation to be in, because things get clogged up.

Users who were prepared to work with area51 ports could always use the area51 repository and keep up-to-date, but people using official ports or packages were lagging behind quite seriously. We (KDE-FreeBSD) don’t really have the capacity to serve up packages built from area51.

The situation is improving. Thanks to Randa, I’ve had time to work with Tobias Berner, Ralf Nolden, and others to wrestle a bunch of updates through to the ports system and to merge a lot of outstanding work to trunk, ready for the next iteration of flushing trunk downstream.

So here’s what we’ve achieved this week:

  • konsole patch updated and merged to ports; it’s still languishing in a reviewboard item on kde.org though. This improves support for home-dir handling and %-expansion which relies on system services.
  • QtCreator and qbs (Qt Build System) flushed downstream.
  • Last iteration of bump-KDE4-to-last-pre-Applications release prepared for downstream.
  • Qt 5.6 merged into area51 trunk.

What this effectively means is that KDE4 is about to be bumped (a little bit: there needs to be another round of reorganization before the changed form of releases under KDE Applications are supported) and that Qt 5.6 is being prepared for inclusion in official FreeBSD packages Real Soon Now.

Of course, this still lags behind on several fronts:

  • Qt 5.7 was released today,
  • We have not yet wrestled webengine into a releasable state,
  • KDE Frameworks 5 are not yet available,
  • KDE Plasma 5 is not yet available,
  • KDE Applications based on frameworks are not yet available.

These are all things that are being worked on, though! There is already a qt-5.7 branch which is close to being mergeable (but we really want webengine in shape for that). The plasma5 branch of area51 has been tracking Frameworks and Plasma and Applications closely for months, so that’s basically poised to swoop in as soon as we have some other bits flushed out.

So it’s been a good and productive week of getting those little annoyances worked out, and soon ™ I expect we can have FreeBSD back on track with the latest and greatest of KDE software. We even have a Krita port prepared!

Posted in Bla Bla | Comments Off on FreeBSD in Randa

Randa in General

One of the nice things about the Randa meetings is — for me at least — is the return to an almost student-like work scheme. Sleep, eat, code, repeat. The hacking room downstairs (there’s two more upstairs) has 16 people in it, working on all corners of KDE. People move around to form pairs as needed. The Davids are in high demand. Alexander jumps at all kinds of problems, from Python to I18n. Tomaz is doing neat things with Subsurface and explaining things to others. Just sitting here means catching up with KDE technologies and hearing tips.

The consequence of these long hacking days is that a lot of little stuff gets fixed as well. Stuff that get shunted aside at the end of a regular working day, but that fills up little gaps in the 16 hour working day that most of the Randa attendees have here. A common turn of phrase seems to be “I have this little annoyance ..” followed by some nearby participant saying “Yeah, I just fixed that.”

Keeping up 16 hour working days for a week requires a lot of organization. And the wonderful thing is is that that organization is there, and that you can roll out of bed (watch out if you’re in the upper bunk) and breakfast is ready. All the day-to-day necessities are already taken care of, and we can get to work. Catering to these day-to-day needs costs money, and you can support that (and therefore support the work that gets done) by making a donation to the Randa fundraiser.

Randa Fundraiser

A lot of the pictures you’ll see that come out of Randa are the “pretty pictures“, of the times between hacking sessions (which Lays Rodrigues describes above the pretty pictures). From here I can see 14 people behind laptops, water bottles, coffee cups, various candy wrappers, Umbrello, 3D-printing, flatpak, KMyMoney. There’s a lot of work getting done, but it’s not very photogenic.

Posted in Bla Bla, KDE | Comments Off on Randa in General

Zanshin 0.4 on FreeBSD

Zanshin 0.4 was released a little over a month ago. Today I got around to fixing up the packaging (see, this is why tooling and automation is important) for Zanshin on FreeBSD in the area51 repository. One stumbling block was a sudden requirement for C++14 while not checking if the compiler supports it. The base system clang on FreeBSD 10 doesn’t, and that led to weird and hard-to-diagnose build failures. Consistent failures, but it took a long time — and Tobias’s help — to find out that --std=c++14 was causing an error in FindLibIcal and that CMake wasn’t logging the failing compile command or the failing source code.

Anyway. It’s sorted out now, and Zanshin can be had through the unofficial ports repository. There’s no ETA for landing it (and the rest of KDE Frameworks 5) in official ports and packages, though.

Posted in FreeBSD, KDE | 1 Comment

Reconciling Packaging Data (2)

So previously I looked at the dependency data available in KDE repositories, and how that translates to information in the FreeBSD packaging system (i.e. the ports Makefiles). It seems likely that judicious use of list_dependencies can help fill in the dependency information when depending on KDE and Qt components.

“Judicious” here means something like “after the Randa *NIX-deployment meeting tomorrow”, since over lunch I learned from upstream (Scarlett) that the inconsistencies in the dependency data I noticed earlier are going to be tackled.

So it’s good to be here in Randa at the cross-platform meeting, also for the *NIX packagers.

But let’s look at two other bits of information in a FreeBSD port: the COMMENT string in the Makefile and the pkg-descr file.

KDE Frameworks all have a metainfo.yaml file, so there’s 81 of those sitting on y hard drive right now. Each of those files has a description line that could be used to fill the COMMENT. Since this is the upstream short description of the software product, that seems like a good pithy thing to use instead of coming up with our own.

The pkg-descr is a larger file, with multiple lines of text allowed describing the package. One special line in the file starts with WWW:, followed by a space, followed by the URL of the package’s homepage. That is information that isn’t available in the metadata in Frameworks. It could be available in the AppStream data, except that none of the Frameworks seem to have that, while AppStream does support generic components.

So my plan is slowly congealing, like lime-Jell-O pudding, into the following:

  • Get kde-build-metadata, on the assumption that it contains a list of all the frameworks (in particular all those frameworks released in a given iteration on KDE Frameworks)
  • For each Framework listed there:
    • grab the released tarball, and extract the description from the metainfo.yaml.
    • if there’s AppData somewhere, extract the description from it (that’s probably XSLT).
    • get dependency information from the build-metadata.
    • read the existing port Makefile to get FreeBSD-metadata.
    • write a new pkg-descr and Makefile.
    • make distinfo and run some FreeBSD-preparatory scripts.

See, with one bit of tooling, we can lighten our maintainence burden and make our package descriptions more consistent with upstream. It’s a win-win!

Posted in FreeBSD, KDE | 7 Comments

Reconciling Packaging Data

At the Randa sprint 2016, we’re talking about KDE om all the platforms. And I’m here to represent the traditional packaging scheme. FreeBSD ports are created by writing a Makefile which contains some settings and then invokes some magic. The Porter’s Handbook describes how.

But here in Randa there are efforts on doing Continuous Integration not only on Linux but also on Windows, and there’s talk of automation of package building (packages of what? for which devices? we don’t know yet). So I thought I’d take a look at a particular port Makefile and try to figure out what parts of the information in that Makefile come from — or could be automatically sourced from — somewhere else.

Here’s the port Makefile for devel/kf5-bookmarks (that’s the internal name for the port). I’ve numbered the lines, and will be commenting inline.

     1  # Created by: Tobias Berner
     2  # $FreeBSD: branches/plasma5/KDE/devel/kf5-kbookmarks/Makefile 12693 2016-06-13 18:31:53Z adridg $

These first lines are comments, with an SVN tag that’s been expanded. Seems that I was the last person to touch this port Makefile. This is boilerplate.

     4  PORTNAME=       kbookmarks
     5  PORTVERSION=    ${KDE_FRAMEWORKS_VERSION}
     6  CATEGORIES=     devel kde # kde-frameworks

Here’s a really important item: the name of the port. This is the only identifier for the port that we can find inside the Makefile. The categories are a way of organizing the ports; in this case, devel must be listed because the port is devel/kf5-kbookmarks, and kde is because it’s from us. So line 4 is important, and 5 and 6 are boilerplate.

     8  MAINTAINER=     kde@FreeBSD.org
     9  COMMENT=        KF5 library for bookmarks and the XBEL format

Line 8 is boilerplate again, and then line 9! That’s something that could be clipped straight from the metainfo.yaml file. After all, there’s a description: line in there with pretty much the same text. So, knowing that the port is kbookmarks, if we know what repository to get stuff from for kbookmarks, we could get the metainfo and extract the information for the COMMENT.

    13  USES=           cmake:outsource compiler:c++11-lib kde:5 tar:xz
    14  USE_QT5=        buildtools_build core dbus gui linguisttools \
    15                  qmake_build widgets xml

This is dependency and build information. We use various packages for building and set options on those packages: usually the KDE tarballs are xz-compressed (not always: that’s one of the unpleasant surprises packagers have to deal with; at least BSD-tar has a ‘z’ flag that’s smart); we’re doing an out-of-source cmake build. That kind of stuff.

The Qt dependencies are fairly fine-grained. This is a consequence of the BSD run-time linker, which doesn’t like transitively linked shared libraries. In other words, linking an application to QtWidgets (and QtWidgets links to QtCore) doesn’t link the application to QtCore. If the application also uses QtCore symbols, then it needs to explicitly link to QtCore.

I’ll write more about dependencies below.

    16  USE_KDE=        codecs config configwidgets coreaddons ecm \
    17                  iconthemes widgetsaddons xmlgui
    18  KDE_DIST=       frameworks

Here, KDEDIST distinguishes between KDE Frameworks, KDE Plasma and KDE Applications, since they are delivered in slightly different ways. For instance, the Frameworks come with translations, while Applications don’t. So that variable controls some settings elsewhere. USE_KDE is the list of dependencies within KDE that this port has. This list uses the same names as you’d find in PORTNAME; a later KDE Framework or Application that needs bookmarks would list USE_KDE=bookmarks. More about dependencies below.

    20  OPTIONS_DEFINE= NLS
    21  OPTIONS_SUB=    YES

Let’s call this boilerplate. Frameworks have translations, and we have an option, NLS, for building and installing translations (or not). So Frameworks all have this. Applications don’t, because they have translations shipped separately.

    23  .include <bsd.port.mk>

Line 23 is where the magic happens.

So to sum up:

  • Lines 4, 6 and 18 establish the identity of this port: it’s devel/ in the filesystem, the resulting package is called kbookmarks and it’s a KDE Framework.
  • Lines 13-17 are build and runtime dependencies.
  • The rest is boilerplate, though some of it depends on KDE_DIST being equal to “frameworks”.

Back to dependencies. There are (at least) two ways that we can find dependenciesy information about a KDE Framework. One is to try to build it and to see where CMake complains. The other is to look at the kde-build-metadata repository. The kde-build-metadata repository contains a file where KDE documents the dependencies within the collection of KDE source repositories. So knowing that I’m working on the port for framework kbookmarks, I can query in-KDE dependencies with the tool list_dependencies.

Wouldn’t it be great if CMake’s find_package() also wrote a (machine-readable) record of what package was looked-for and whether it was optional or required? (And, while I’m dreaming, whether it was for build- or runtime use). That way you could get a straight-from-the-source list of dependencies.

Lacking that, list_dependencies uses a dependency file maintained by the KDE community. And using it, I find some surprising differences between the dependency information in there, what CMakeLists.txt says, and what our port Makefile says.

First off, the CMakeLists.txt for kbookmarks says:

find_package(Qt5 ${REQUIRED_QT_VERSION} NO_MODULE REQUIRED Widgets Xml DBus)

find_package(KF5Config ${KF5_DEP_VERSION} REQUIRED)
find_package(KF5CoreAddons ${KF5_DEP_VERSION} REQUIRED)
find_package(KF5Codecs ${KF5_DEP_VERSION} REQUIRED)
find_package(KF5ConfigWidgets ${KF5_DEP_VERSION} REQUIRED)
find_package(KF5IconThemes ${KF5_DEP_VERSION} REQUIRED)
find_package(KF5WidgetsAddons ${KF5_DEP_VERSION} REQUIRED)
find_package(KF5XmlGui ${KF5_DEP_VERSION} REQUIRED)

Maybe there’s more find_package calls, I didn’t look everywhere. But this is a clear statement of dependencies. Matching these lists against our ports Makefile shows:

  • Each direct dependency on another framework is reflected in USE_KDE’s list of frameworks. That’s good!
  • Each Qt component explicitly looked-for can also be found in USE_QT5. That’s good!
  • But there are other entries in USE_QT5. That’s because kbookmarks links (privately) against Qt5DBus. Possibly we could drop core from USE_QT5, and there’s three build-tools listed (I’m not sure linguisttools is a runtime requirement). So this is almost good: I get the feeling there’s a missing find_package, and our list is a little on the bulky side.

Turning to the information in kde-build-metadata, I can ask for direct dependencies, or transitive dependencies. Here’s the direct list:

frameworks/kbookmarks:
        kdesupport/extra-cmake-modules
        Qt5[stable]
        fram~/kdesrc/log/2016-06-14-10/kcalcore/cmake.logeworks/kxmlgui
        frameworks/kconfigwidgets
        frameworks/kwidgetsaddons
        frameworks/kcoreaddons
        frameworks/kiconthemes

This is roughly the same list as spotted in the CMakeLists.txt and in the port Makefile, but there’s a catch (or two):

  • The Qt (sub)module information is lost. This is documented at the top of the dependency-information file, so it is not surprising, but it is a little annoying.
  • The frameworks KF5Config and KF5Codecs have vanished, in spite of being explicitly searched for in CMakeLists.txt. There’s an explanation for this, because frameworks/kxmlgui depends on them (and lots else like kitemviews). So it looks like transitive dependencies have been removed here (this is not systematically done: kcmutils depends both on kxmlgui and kitemviews).

So, at least from my point of view, the dependency information could use some refinement (and/or expansion). But that’s why I’m in Randa! So I can sit down with the people most-responsible and figure out what we need, and what can be provided. You can support bringing together the right people in Randa though this year’s fundraiser.

Posted in FreeBSD, KDE | 1 Comment

GPG key transition

Some time ago I blogged about resuming the use of my GPG key (with short-ID FEA2A3FE, which I always thought was a neat ID). On that post someone commented that the key way weak and didn’t follow current best practices (no wonder, the key was created in 2002). A recent LWN article on key-ID collisions made me realise it was time to take some action. So here’s a statement, signed with my old and new key. I am aware of the irony of serving those up over HTTP.

The GPG key for Adriaan de Groot is now

sec 4096R/0x7FEA3DA6169C77D6 2016-06-11 [expires: 2018-06-11]
Key fingerprint = 00AC D15E 25A7 9FEE 028B 0EE5 7FEA 3DA6 169C 77D6

it used to be

sec 1024D/0x76ACEE01FEA2A3FE 2002-06-18
Key fingerprint = 934E 31AA 80A7 723F 54F9 50ED 76AC EE01 FEA2 A3FE

I was kind of attached to my short key-ID, so I’m glad to see FEA3 return in my new long key-ID. The new key has been sent to the sks-keyservers pool and should be available where ever needed. While I don’t expect to use much GPG, those things that need signing will be signed with the new key.

Posted in Bla Bla | Comments Off on GPG key transition

I’m going to Randa!

Like Christoph, I’m going to Randa! It’s a long train ride, but that means I can get some hacking done on the way.

Randa Fundraiser Image

You can support the Randa meetings! Click on the image for fundraiser information. The Randa meetings are one of the biggest sprints in KDE. Each year a tightly focused group gets together to work on KDE technology for one goal. This year the goal is KDE technology on every device.

While most of the participants seem to be going to the meeting for the purpose of getting more KDE applications on Windows, MacOS or Android — indeed platforms where our technology can make a difference for developers and where our applications can make a difference for Freedom — I’m going with a slightly different purpose. I’m there for our traditional niche platforms: the BSD’s. But also for packaging in a traditional sense, and for building our software effectively and efficiently.

There’s a lot of infrastructure in the KDE software (git) repositories, information about dependencies and build orders and where to find sources and stuff like that. For the traditional packagers, though, packaging is largely an artisanal process: discover what software is released this time, under what names and in which directory; figure out what new dependencies there are by trying to compile the new stuff in an environment that worked for the previous release; adjust sources for invalid assumptions. Lather, rinse, repeat.

Speaking of repeat, Scarlett has been working on reproducible builds of KDE software for Debian. FreeBSD is part of the same organization, so I hope to learn a lot from Scarlett towards that goal.

If containerized apps are really a thing, I’d hope to be able to build FreeBSD(-ish) containers from the same metadata as other containers are built from.

As preparation, I tried to build KDE (as in, the software stack needed for Zanshin) from source on a Linux distro. I failed. To me, that suggests that we shouldn’t forget the devices running Linux, either, and the packagers that work there.

Posted in KDE | 1 Comment

KDE-FreeBSD catching up

After a long struggle with digiKam (mostly because of the libmediawiki plugin), a brief struggle with KDevelop (it is well-behaved), and a careful struggle with CMake (because lots of other ports depend on it), official ports have been updated (by Tobias Berner and Raphael Kubo da Costa) with the state-of-the-art for KDE4 from the unofficial area51 repository. That means:

  • digiKam 4.14.0
  • KDevelop 4.7.3
  • CMake 3.5.2

Other bits and pieces have been updated as well; what hasn’t been added are zanshin and simon. Those are waiting on a next round of updates. As far as KDE Frameworks 5 are concerned, those work very nicely in area51, but are not yet candidates for downstream (official ports). There are a few steps to go:

  • Another round of KDE4 infrastructure updates so that it is compatible with what has been developed in the plasma5 branch for the new KDE Frameworks 5, KDE Plasma 5 and KDE Applications.
  • Merging plasma5 branch into area51-trunk and double-checking that KDE4 and KDE Frameworks 5 can co-exist.
  • .. then sending KDE Frameworks 5 downstream to the official ports.

I have two things on my “that’s what I’d like to do” list; one is preparing a Zanshin 0.4 with Frameworks port and the other is sorting out the branding of the desktop.

Posted in FreeBSD, KDE | 2 Comments

Akademy+ Call for Papers / Participation / Presentation

This year, Akademy is being held together with other Free Software conferences, all rolled up into one. The umbrella we all live under is QtCon, and it will bring KDAB‘s Qt Training Day, the Qt Contributor Summit, Akademy, as well as the FSFE Summit and VideoLan Dev Days under one roof (well, multiple roofs; one umbrella). The call for papers is now available.

Because of this wide range of events at one time, there is unprecedented opportunity for presenting your work to a broad audience. I’ll be there; maybe “Keeping Qt going on non-tier-1 operating systems” is a useful talk to give. I really want someone to submit an “Optimizing Qt scene graph through algebraic geometry” talk, too. And a “Biggest video wall in Amsterdam with Qt and VLC”. And “Estimating proprietary development through observation of Free Software development”. And .. gosh, the list goes on and on.

Deadline is may 15th!

Posted in eV, KDE | Comments Off on Akademy+ Call for Papers / Participation / Presentation

Digikam updated in area51

The latest version of digiKam has been added to the unofficial ports tree in area51. The unofficial ports tree is where the KDE-FreeBSD team works on ports in preparation for their inclusion into the official ports tree. The trunk of that repository is basically “what’s next” for the official ports tree from our point of view. There are other branches: mostly plasma5, for the upcoming (from a FreeBSD perspective, at least) KDE Frameworks 5 and Plasma 5; qt5.6 for testing the recently-released Qt 5.6. Official ports will remain Qt 5.5 for the time being.

This has been one of my bigger packaging jobs so far; also one of my first for an application I don’t actually use. Here’s some notes from this packaging exercise (previous digiKam version was 4.2.0 in FreeBSD, so it’s quite a big jump).
  1. For dependencies within KDE — be it frameworks, support libraries, whatever — there’s lots of links to projects.kde.org. Since projects.k.o seems to be going away in favor of other systems of organizing repositories and projects, I foresee a lot of necessary updates fixing URLs / pointers to dependencies. This is easiest to illustrate on the digiKam site, where as of right now, the dependencies-listing page links to a file in digiKam’s git repository through projects.k.o, which now leads to a landing page on quickgit.k.o. From there, it’s possible to find the README file in master, but nowhere near as easy as originally intended. In other words, the change in KDE infrastructure is affecting links and the availability of information to packagers already.
  2. CMakeLists that output a nice list of missing dependencies — also the optional ones — with good pointers to those dependencies are wonderful to work with. Keeping those pointers to dependencies up-to-date (see point 1) is extra work for application developers though.
  3. Unbundling libraries is an unexpected pain in the packager’s butt, even if there’s a nice pointer to find the now-unbundled libraries provided by CMakeLists. The reason it’s a pain is because “update package” becomes “introduce new packages whis may not be co-installable with the old version with bundled libraries; update package”.
  4. Changelogs which are written for usersare pretty much useless for packagers, since they don’t include notes like (see point 3) “Libraries have been unbundled”. At work-work we get things sort-of-right, writing release notes for users and including a separate section specifically for sysadmins detailing internal changes (it’s a Python app, but still ..). Part of distribution outreach is making things easier for packagers by providing this kind of information in an easy-to-find and easy-to-read format.
  5. Changing CMake policies can make the simplest porting job an exercise in wading through gobs of CMake warnings. It would be nice to have a cmake command-line argument complementary to set_policy(). It means that the version of cmake relevant at the time of the software release matters — building a six-month old release with the latest CMake can be problematic.
  6. Translations can be a bumpy ride — appearing one release, vanishing the next. 

These are just items I jotted down based on packaging digiKam. They’re not specific to digiKam, really:  for instance, I just built amor and it encounters some of these points as well.

The update to digiKam 4.14 in the unofficial ports tree is a bit weird, in the end:
  • New ports libkface and libkgeomap,
  • digiKam 4.12 is used to build the libmediawiki library,
  • digiKam 4.14 is used to build the rest of the application,
  • digiKam 4.14 is used to build all the kipi-plugins, including the mediawiki one,
  • the is (Icelandic) translation of the Google Drive plugin has gone away.
I’m actually not sure whether the mediawiki kipi-plugin is still supposed to build: it’s there in the source, it builds if it’s possible, but it isn’t listed among the available plugins on the digiKam site nor has the digiKam team released libmediawiki standalone (like it has for libkgeomap and libkface). We’ve decided to keep the plugin, on the grounds that that is less change in the available packages and Fedora seems to do the same.
Anyway, this unofficial update will hopefully be followed fairly soon by an update to the official ports tree — then the KDE-FreeBSD photography community can enjoy updated software.

Posted in FreeBSD, KDE | Comments Off on Digikam updated in area51