Howto

This is a longish story about how I migrated my photo library from Apple's discontinued iPhoto application to the open source program digikam (version 5.9.0 beta from March 2018). If you follow a similar migration path and make the same decisions as I did on what data to keep and what data to discard, then I hope you will find a reusable solution in this story. These are the pieces:

• An AppleScript for the initial iPhoto export
• A shell script for post-processing and preparing the exported data for the digikam import
• The instructions how to configure digikam to make the import work
• Optional cleanup work and sync'ing back of metadata to image files

A warning before you dig in: Although I have tried to explain everything in as much detail as I could, you should be prepared for surprises and an arduous migration - it certainly was for me.

A mobile app that integrates the Fabric mobile platform and the Crashlytics crash reporting framework requires two things to successfully communicate with the Fabric / Crashlytics server platform:

• The Fabric API key: This is required at build time so that the build process can upload the debug symbols that later are required to symbolicate crash reports. The API key is also required at runtime so that the app on a customer device can submit crash reports.
• The Fabric build secret: This is also required for uploading debug symbols at build time.

Whoever knows these two pieces of information can freely interact with the Fabric / Crashlytics server platform on behalf of the app, so obviously you want to restrict knowledge of the information to people who can be trusted. This article shows how to keep API key and build secret private even in an Open Source project like Little Go where, by definition, there is the desire to publish everything.

Ad-hoc distribution is definitely the way to go to make it easy for beta testers to install an iOS app that is not yet available through Apple's App Store. The answer to this stackoverflow question thoroughly explains how it works.

Today I tried to create a new ad-hoc distribution for my Little Go app, the first after iOS 5 has been released. Very much unexpectedly, the whole process fell flat on its nose due to a combination of code signature and entitlement problems. After a 4 hour battle I now have things working again, and although I am not entirely sure about the exact source of the problem, I thought I would like to write down what I have learned this afternoon.

The final solution, anyway, for those who don't want to read the whole story: Invalidate and then regenerate all provisioning profiles on Apple's iOS Provisioning Portal.

Last week I tackled another upgrade of Bugzilla on my Debian server. Unfortunately, I found out the hard way that the package that I tried to install (bugzilla3-3.4.7.0-2) was badly broken - I was left with a half-completed installation that simply would not work. I reported the problem but got no response, so I decided to get to the bottom of this and find out what the trouble is. This is not the story of what I found out, but of how I was finally able to fix the problem.

Two good news from the Mediawiki battle front of a "grizzled Debian veteran" :-) Read the whole article if you are interested.

Today I found out that there are simpler things than configuring an Apache virtual host for Bugzilla to live in. With a bit of URL rewriting magic, the basics are moderately difficult to solve. What drove me crazy, though, was that the CGI scripts stubbornly generated links to /bugzilla3/skin/[...], instead of just /skin/[...].

I have been fooling around a bit with Eclipse, Subclipse and the Fink package svn-javahl, trying to get Subclipse to work together with svn-javahl. Thanks to a fix by the package maintainer, Daniel Johnson, there is now a really easy solution available.

Note 1: You need svn-javahl-1.6.5-2 or later for the solutions in this article to work. If you use an earlier version of the package, Eclipse is likely to crash at some point. Read the article for more details.

Note 2: The original version of this article was posted on this website for less than 24 hours. It has been completely outdated by Daniel's fix, so what you are reading now is a totally revised version of the article.

My LAN consists of a Linux server that, among other things, exports a few Samba shares, and a number of Mac OS X and Windows clients that mount those shares when needed. On Windows it is possible to tell the system that it should automatically re-mount a share on login, but on Mac OS X there is no such option. Because of this, up until now I had to manually mount my shares each time I logged in on any of my Mac OS X clients. Not anymore!

Although the typical Mac user, living in the Aqua land of blissful ignorance, usually does not care about environment variables and other such "strange" beasts, it may sometimes become unavoidable having to deal with this stuff from the ninth hell of command line wickedness.

My moment of truth came when I wanted to run the Gimp (the official Mac port can be downloaded from here) in a different language (English) than the default language of my Mac OS X installation (German). For this I had to run Gimp.app using the environment variable LANG set to the value en.