Present Perfect

2010-3-18:15 pm

One of the things I really love about my N900 is the ease with which I could share photos. You take the picture, click a few buttons, and there it is, your photo on flickr on Facebook. I’m sure other devices offer a similar experience, but this really is the first time I’ve been able to appreciate

Since a few weeks my Facebook sharing has stopped working. At first it only seemed like a missing icon and broken config. But I had a really really hard time to figure out the problem, much harder than it should have been for a mostly open platform. Of course, for some reason this sharing part is closed, which doesn’t make much sense at all. What secrets can Nokia possibly have invested in some code that pushes photos to flickr or Facebook.

So, as part of the debugging process, over various weeks, I’ve seen and done the following:

When sharing through the Facebook account, the little ‘I’m sharing’ icon that pops up in the status area went away almost immediately, compared to sharing through Flickr

Sharing stores outgoing stuff in $HOME/.sharing/outbox – files were piling up there

At first I thought I had some login details problems, so I went to Settings > Sharing accounts and clicked on the Facebook account. That didn’t do anything at all, no dialog popped up. Since the Delete button is in that popup, I also couldn’t use the UI to recreate my Facebook sharing account.

I started learning about where the N900 stores account info, following some dubious posts until I found out about signond, a daemon running as root that stores login information. This daemon uses the file $HOME/.signon/user_db.xml (You get no points at all for correctly guessing whether this file contains XML data, but please do go look for yourself!)

I moved this file around to force recreation of data, which seemed to work after a reboot, since my Flickr data was now gone, as well as the Facebook one. I was able to click Flickr in Settings > Sharing accounts, but the Facebook still didn’t pop up a dialog. At least this narrows down the problem I should solve for now: I can’t even configure the service from scratch even when deleted, so let’s focus on that first.

I reinstalled the package that contained the facebook sharing plugin. This restored the icon, but the popup still didn’t work.

Usually I would just strace the relevant binary, but I considered the friction too high at first since there is no strace in fremantle, and I would have to set up a chroot for this.

But what binary ? I didn’t even know what program handles the settings. After comparing a few ps listings, I figured out the program was controlpanel.

Interestingly, you can just ssh into the device as the user, and execute controlpanel, and it will pop up the binary on the phone (even with X forwarding), which I didn’t expect, but is fine by me. This gave me a message like “sharing-accountstore.c 516 sharing_account_store_add_account Last added id exists: 35
” which I wrongly took to mean that adding a facebook account was failing because it was still somehow present in the config. This is when I figured out that this code is closed, because I wasn’t able to figure out where to get accountstore.c and look at what it is doing. I’m pretty sure it’s not storing its settings in gconf (at least I couldn’t find anything related to facebook sharing when walking the gconf tree), and it doesn’t seem to be in any dot folders in my home dir. Anyone know ?

Finally, I gave up, set up the chroot, and straced that binary. And I should have known this would have led me to the right solution. Among all the noise, there were some calls trying to open a library. It’s normal for a bunch of calls to fail as it searches the whole LD_LIBRARY_PATH, but usually the last one of those in an strace log should succeed. But they weren’t; apparently /usr/lib/libfacebookcommon.so.0 was missing!

Looking for that file on disk confirmed that it wasn’t there, and doing dpkg -L feedservice-plugin-fb-common showed that it should in fact be there. This reminded me of a pet peeve I have with those people who claim Debian’s packaging system to be far superior to rpm – apparently dpkg doesn’t have any equivalent of rpm -qv which allows you to verify that the files that should be installed by a package are indeed on disk. This would have saved me *a lot* of time figuring out this problem, and is typically the first thing I do on an rpm-based system where things act funny.

With my first real clue in hand, I used ldd to verify that indeed there were libraries missing:

Using dpkg -S to figure out what package this belonged to, I apt-get remove’d that package, then reinstalled it and dependencies.

Still didn’t work, so repeated the process, this time libfeeserviceutils.so.0 was missing, so reinstall feedservice-utils and dependencies.

And finally! The sharing plugin can again be configured, and all is well. But this experience was needlessly painful…

For the record, I didn’t tinker with any package files by hand (anyone who knows me a little knows my stance on packages and /usr), and I have no idea what I did to get into a situation where files that should be on disk aren’t. And I’m worried about what else is missing, so if anyone can point me to some resources explaining how to verify installed package manifests, that would be awesome.

Do a backup and flash the main thing (you don’t have to flash the eMMC with contains /home).

Maemo apps start in a special way. They’re actually dlls that are loaded by maemo-launcher after forking, so it has gtk+&friends pre-initialized. This helps app startup time significantly. Thats why they don’t get your environment variables (like DISPLAY=). There is a trick with maemo-summoner or something like that to run an app directly, but I never remember what it is. But it is in the developer doc somewhere if you care.

One problem I experienced with rpm’s verify command is that its checksum function is utterly useless (because it reports too many changes) when you have prelinking enabled (PRELINKING=yes in /etc/sysconfig/prelink on RHEL5) – which is the default.