There have been a lot of changes recently with Flickr, and from February, free users with over 1000 photos are going to start seeing their old photos being deleted. Premium membership has also seen a sharp increase in price.

So, this seems like an opportune moment to move my photos off the platform – I’ve got something going on to 3K photos on there, and while I still have the originals, I’ve nicely sorted them into albums, so it would be a shame to lose that.

Previous attempts at writing an import tool connected over the API, but this broke some time ago when Flickr changed their authentication mechanism, and honestly I’ve not had the time to fix it.

Thankfully, Flickr now offers a full data export via your accounts page. This export contains a bunch of zip files that contain all your media, as well as handy .json dumps of all the image meta data. Using this seemed like a much better way than fighting with Flickr’s API again.

Usage

The new tool is a Known console plugin, so unlike the previous tool, you’ll need to install this to your ConsolePlugins directory.

Next, you need to request and download all your data from Flickr. Do this via your accounts page.

Once you have your .zip files, place them in a directory somewhere, where you can access them from your Known install.

Next, execute your import by running the import code from the console:

./known import-flickr username-to-import-to /path/to/flickr/export

Where username-to-import-to is the user who’s stream these photos and videos will appear under, and /path/to/flickr/export is the directory you’ve stuffed your .zip files. 

There is no need to unzip these files ahead of time, the import tool will do that for you.

After you’ve run the import, assuming that there have been no errors, you should see all your photos and videos appearing on your stream!

» Visit the project on Github...

Just another quick update…

In an ongoing effort to make use of the Known API easier and more flexible, the latest version available in GitHub, or via my unofficial packages, now has built in support for OAuth2.

OAuth2 server functionality is provided by an updated version of my OAuth2 Server code, which I’ve written a bit about before.

Going forward, I’m hoping to build out an easier way for third party clients to be able to connect, paving the way for a possible mobile client.

Anyway, go grab the latest version and have a play!

Today was a very frustrating day.

So, yesterday, I did a rollup of software on my main work machine. I performed an apt-get upgrade as I have done a thousand times before. Logged off, and went to bed.

This morning, when tried to log on, after I’d entered my details on the login screen, I was greeted by a blank screen for about 2 minutes, before being kicked back to the login screen.

Hmm..

This kind of thing had happened before, and in the past it was just a matter of installing the vendor NVidia drivers for my card. Sometime back in the day the distro provided nvidia drivers had stopped working, so using the vendor ones was the way to go (this has since changed).

No joy. So, I began diving in and pulling at the various ends in an attempt to unravel this knotted ball of string.

Watching the logs, I noticed that just before the login process got thrown back to lightdm, I got a bunch of…

Activated service 'org.freedesktop.systemd1' failed: Process org.freedestop.systemd1 exited with status 1

…appearing in my syslog.

So, something was suddenly up with systemd, but I was nonthewiser.

My setup at home is that I have a server which has my home directory and users exported by NFS/NIS to various machines, so there was nothing actually on the work machine. Sod it I thought, nuke the site from orbit. So, I reinstalled, just in case I had bawked something up over the years.

The fresh install made me create a new user, fine. I installed all the graphics drivers, and was able to log in just fine. Great! So, installed the various bits of software, set up NIS/NFS, could log in on console… great! Logged in through gdm3… aaaand. Nothing. Same error. Switched to lightdm. Same thing.

But… the local user worked. Must be something in my user’s home dir, after all that. So, unmounted my home directory, and tried to log in as a fresh user… still no joy. But the local user could log in…

Hmmm….

Lightbulb!

As a hunch, I copied the user line from my server’s /etc/passwd into my local machine’s /etc/passwd… and bingo, I was able to log in.

So, what looks like has happened is that a recent change (within the last week or so) has broken NIS user support for systemd/dbus. So, when the window manager was trying to start the services it needed to run, it wasn’t able to, since the user it was attempting to use couldn’t be found. Lightdm/Pam still functioned with NIS, so my thinking is that there’s something about the environment that’s looking directly at /etc/passwd for something, or to validate uids.. I’m not an expert.

So, if any of you are in a similar situation, hopefully this blog post will stop you from losing an entire day of work!

My askubuntu ticket is over here, and I’ll keep updated should I find a better solution than this rather crufty hack.