Blog - Unity Behind Diversity

Searching for beauty in the dissonance

Tagged: n900

SOLUTION: gPodder 2.20.3 on N900: database disk image malformed

After some strange behaviour in gPodder 2.20.3 yesterday on my N900 (not responding to episode actions), I quit gPodder and tried to start it up again, but it would crash during startup everytime with an error about “database disk image malformed” from line 316 of dbsqlite.py on the query: “SELECT COUNT(*), state, played FROM episodes GROUP BY state, played”.

First, I opened up the sqlite database directly:
sqlite3 ~/.config/gpodder/database.sqlite

I could run that query and others no problem.

However, I found this guide on repairing a corrupt sqlite database, I ran the following integrity check command and it returned a couple errors along with the “database disk image malformed” message:
sqlite> pragma integrity_check;

So I followed the instructions from spiceworks, dumped my database to file and reloaded it into a new database:
cd ~/.config/gpodder/
echo .dump | sqlite3 database.sqlite > gpodder.sql # generate dump file
mv database.sqlite database.sqlite.bak # backup original database
sqlite3 -init gpodder.sql database.sqlite # initialize a new database from the dump file

And, voila, gPodder is working again.

Creative Commons Attribution-ShareAlike 4.0 International Permalink | Post a Comment

HOWTO: CalDAV/CardDAV Sync from N900 to SOGo using SyncEvolution

When I moved to Maemo in 2010, I was using Google Calendar. I setup a sync via Exchange and eventually Erminig, which allowed me to sync my wife’s Google calendar too. But, when I started degooglifying and moving to free network services, I left Google Calendar for Funambol, using SyncEvolution as a Maemo SyncML client.

This was far from ideal: we lost shared calendars, there was no web UI, and desktop SyncML options were lacking. I quickly realized that CalDAV would be the better long-term option. I choose SOGo as my CalDAV server, but I couldn’t find a CalDAV client for the N900. (I tried the Funambol SOGo Connector. but just couldn’t figure it out.)

I’d just about given up on a comprehensive sync solution in Maemo… until I hit the jackpot a few days ago and stumbled upon a post by Thomas Tanghus on a CalDAV/CardDAV sync from the N900 to ownCloud using SyncEvolution.

It looks like SyncEvolution gained CalDAV/CardDAV support in version 1.2 — the N900 has a CalDAV client!

CalDAV/CardDAV Sync using SyncEvolution

Thomas’ instructions were for ownCloud, but they work for any CalDAV/CardDAV server. I only ran into two issues, I think because I’d been using SyncEvolution pre-1.2. The steps included here are 90% from Thomas, with those two additions.

Reinstallation

First, I ran into the same problem as Wolfgang: the SyncEvolution WebDAV template wasn’t there when I tried to run Thomas’ first step. Wolfgang’s solution worked for me as well: just uninstall and reinstall SyncEvolution.

$ root
# apt-get remove syncevolution syncevolution-frontend
# apt-get install syncevolution syncevolution-frontend

I suspect you’ll need to do this if you initially installed SyncEvolution before it included WebDAV support.

Configuration

After reinstalling, I was successfully able to follow Thomas’ instructions (ignore the “backend failed” notices in the first command):

syncevolution --configure --template webdav username=YOURUSERNAME password=YOURPASSWORD target-config@sogo
syncevolution --configure database=CALDAVURL backend=caldav target-config@sogo calendar
syncevolution --configure database=CARDAVURL backend=carddav target-config@sogo contacts

The CalDAV URL for your default SOGo calendar is http://YOURSOGOINSTALL/dav/YOURUSERNAME/Calendar/personal and the CardDAV URL for your default SOGo addressbook is http://YOURSOGOINSTALL/dav/YOURUSERNAME/Contacts/personal. Your can right-click on any additional calendars in SOGo and select Properties > Links to find the CalDAV link for that particular calendar.

I ran into another issue with the next step in Thomas’ instructions. The above commands created new configuration files in /home/user/.config/syncevolution/sogo/, but the following commands operate on /home/user/.config/syncevolution/default/, in which I already had existing, older SyncEvolution configuration files. SyncEvolution complained about my pre-existing configuration, probably because I’d installed a much earlier version of SyncEvolution, and it said that I’d need to “migrate” with the following command:

syncevolution --migrate '@default'

Again, I suspect you’ll need to run this if you’d installed SyncEvolution pre-1.2. After this, I was able to continue with Thomas’ instructions.

In the following command, the username/password should stay blank:

syncevolution --configure --template SyncEvolution_Client sync=none syncURL=local://@sogo username= password= sogo

Then, configure the databases, backend and sync mode for calendar and contacts:

syncevolution --configure sync=two-way backend=calendar database=N900 sogo calendar
syncevolution --configure sync=two-way backend=contacts database=file:///home/user/.osso-abook/db sogo contacts

I’m running SSL on my server, so I had to add this step to get past an SSL error:
syncevolution --configure SSLVerifyServer=0 target-config@sogo

(I bet there’s a way to configure it to properly verify the SSL certificate… but I’ll save that for another day.)

Testing

To test the configuration:

syncevolution --print-items target-config@sogo calendar
syncevolution --print-items target-config@sogo contacts

If that shows the data you expect to be there, then go ahead and run your first sync.

First Sync

SyncEvolution has several sync modes. The above commands configured the default mode to be ‘two-way’, but if you have initial data on both your client and server, you’ll want to run a ‘slow’ sync first.

syncevolution --sync slow sogo

My initial slow sync took almost an hour for ~2540 calendar events and ~160 contacts.

(If you want to overwrite your client with data from the server, or vice versa, look up ‘refresh-from-client’ or ‘refresh-from-server’ instead of ‘slow’.)

Scheduling

After that initial sync, you can run a normal sync at anytime:

syncevolution sogo

While the command line is great for configuration and testing, you don’t want to open a terminal every time you want to sync your calendar. You could schedule the sync command via fcrontab, but the Maemo syncevolution-frontend GUI has a daily scheduler.

Maemo SyncEvolution Frontend

UPDATE: Syncing Multiple Calendars

I’ve adapted the above commands to create new target-configs for two other calendars I want to sync — my wife’s and my childcare calendar for my son. There may be a more elegant way to reuse the same target-config, but this works.

First, in the Calendar application, under Settings > Calendars, I created one for my wife’s calendar called “Heather” and one for my son’s calendar called “Noah.”

You can view all the available databases with the follow command:syncevolution --print-databases

You should see your new calendar listed here. It can be used by name, so long as that name is unique (and there aren’t any special characters to escape).

Then, adapting the above commands:
##### Heather
syncevolution --configure --template webdav username=MYUSERNAME password=MYPASSWORD target-config@sogoheather
syncevolution --configure database=HEATHERCALDAVURL backend=caldav target-config@sogoheather calendar
syncevolution --configure --template SyncEvolution_Client sync=none syncURL=local://@sogoheather username= password= heather@heather
# A one-way sync is fine here, because I just want to view my wife's calendar
syncevolution --configure sync=one-way-from-remote backend=calendar database=Heather heather@heather calendar
syncevolution --configure SSLVerifyServer=0 target-config@sogoheather
syncevolution --print-items target-config@sogoheather calendar
# no need for a first slow sync with one-way mode set
syncevolution heather
##### Noah
syncevolution --configure --template webdav username=MYUSERNAME password=MYPASSWORD target-config@sogonoah
syncevolution --configure database=NOAHCALDAVURL backend=caldav target-config@sogonoah calendar
syncevolution --configure --template SyncEvolution_Client sync=none syncURL=local://@sogonoah username= password= noah@noah
syncevolution --configure sync=two-way backend=calendar database=Noah noah@noah calendar
syncevolution --configure SSLVerifyServer=0 target-config@sogonoah
syncevolution --print-items target-config@sogonoah calendar
# refresh-from-remote is faster than slow, and I know the local calendar is empty
syncevolution --sync refresh-from-remote noah

YMMV and you may want different configuration for your additional calendars, but this should give you some examples for how to configure additional calendars. The key different in these commands, besides the straight replacements, is to add a unique source name to all the –configure commands from SyncEvolution_Client on (except the SSL fix for the target-config), so that the client config ends up distinct from your primary calendar above.

Lastly, using the syncevolution-frontend, I scheduled daily automatic syncs for these two calendars as well, at different times.

Conclusion

I’m not sure if there’s a more elegant/concise configuration. I’m curious if there’s some way to combine the ‘target-config’ and ‘sogo’ steps… but Thomas spent over 12 hours on this and it works, so I’m not going to mess with it. I’m just thrilled that I’ve got this up and running.

After more than a decade in proprietary software slavery, and nearly two years of wandering in the calendar/contacts desert, I’ve finally reached the promised land of seamless and libre mobile, web and desktop calendar/contact sync. [Edit: Almost: The Maemo calendar application is proprietary…] Thank you, Thomas!

Creative Commons Attribution-ShareAlike 4.0 International Permalink | Post a Comment

HOWTO: Sync Notes Between Tomboy and Conboy with Snowy [UPDATED]

Updated: I’ve updated this guide to detail a proper sync with Snowy, rather than the old Unison hack (below), since Conboy now supports more than just Ubuntu One, and an experimental version Snowy is operational.

I’ve been a regular user of the fantastic Tomboy note-taking application since I replaced my Palm Pilot with a Nokia N900. With Conboy, a Tomboy client for Maemo, and Snowy, a web application for Tomboy notes, it seems like the perfect platform for uniting personal notes across the desktop, mobile and web (except for one drawback: Tomboy itself is a Mono application…). Initially, I used a hack with Unison to synchronize Tomboy files manually between my N900 and laptop, but I recently moved to proper, albeit still experimental, syncronization through my own Snowy server.

Installing Snowy

Snowy is a Djano-based, AGPL web service for Tomboy notes, currently under heavy development (and still labelled as experimental). I installed Snowy on my own Ubuntu web server using the official installation guides. I went with mod_wsgi, though I have Django running via mod_python on another server.

Installation was very straightforward. Just a few notes:

  • The debugmail step in the INSTALL file within the Snowy source directory didn’t seem to work for me, but I’m not too concerned about email yet. I’m just running this for me and my family. I’ll likely revisit this later.
  • Between the time that I followed the INSTALL steps and when I went to first sync from Tomboy, I had decided to switch the installation to a slightly different URL. I couldn’t figure out why the sync didn’t work, but it turns out I still had the old URL in the Django Sites table. Just a silly mistake on my part.
  • When you log in to your new Snowy server, in the current version, it isn’t obvious where to click to see your notes. You can click on your avatar in the top-right corner, or simply add /<username> to the end of your Snowy URL (e.g. my username is balleyne, so http://<my-snowy-url>/balleyne brings me to my notes

Tomboy

Tomboy comes packaged with the web sync plugin in recent versions of Ubuntu.

  1. Backup your notes!
  2. Log into Snowy in your default web browser.
  3. Open Tomboy, and go to Edit > Preferences > Syncronization
  4. Select Tomboy Web as the Service, and put in the root URL of your Snowy installation as the server.
  5. Follow the instructions to authenticate, save your settings (I set Tomboy to automatically sync every 60 minutes), and synchronize!

Conboy

Conboy focused on supporting the proprietary Ubuntu One web service first, but it now supports synchronization to any Tomboy web service (though the feature is labelled Beta). The only problem I had setting this up was a strange error about a missing api-ref and local time, but it turns out Conboy just didn’t want a trailing slash in the URL (seems like the trailing slash prevented proper authentication at the sync stage).

  1. Backup your notes!
  2. Log into Snowy in your default Maemo web browser.
  3. Open Conboy, and go to Settings in the main application menu.
  4. Enter your Snowy URL — without a trailing slash — as the Synchronization URL
  5. Click Authenticate and follow the instructions.
  6. Synchronize!

Conclusion

I’m super happy that the Tomboy / Conboy / Snowy combination is now ready to use, but do pay attention to the beta nature of Conboy sync, and the experimental nature of Snowy — make sure to backup your notes regularly to avoid any data loss.

I’m happy to be a guinea pig myself.

Old Way: Sync Notes Between Tomboy and Conboy With Unison

Disclaimer: this is a hack from someone who doesn’t know Tomboy well. It worked for me, but YMMV. And I have backups. And, mostly importantly… why aren’t you using Snowy now instead?. The instructions below should be treated as a hack preserved for historical purposes.

I wanted a way to sync Tomboy on my Ubuntu desktop with Conboy on my Nokia N900, but Conboy only syncs to Ubuntu One—a proprietary web service. Snowy synchronization support is supposed to be on the way, but Snowy itself is still under heavy development, so this might be a great option in the near future, but not today.

A comment on maemo.org made me think that rsync over ssh was a possibility, and a quick rsync showed this to work (as far as I can tell). The trick is being able to sync changes back and forth; rsync can’t handle updates to both the source and destination—it’s unidirectional.

Hence, Unison—a bidirectional synchronization utility. In case it’s useful to anyone else, this is how I’ve setup Unison to sync notes between Tomboy and Conboy.

Step 0: Some things you should know

First, I want to be clear that this is a temporary hack while I wait for proper synchronization support through Conboy with Snowy.

Prerequisites: I already have OpenSSH running on my server, and I have key-based ssh access configured from both my laptop and N900. Unison syncs remotely over SSH.

What this does: It allows me to synchronize notes and changes to notes from my N900 to my laptop, and potentially to any number of other computers.

What this doesn’t do: Unison has support for handling conflicts, but it’s not the least bit Tomboy-aware. A proper Tomboy sync might give you the option of renaming a note that has been changed in more than one place, but with Unison, you’ll be looking at diffs and merges of cryptically named XML files. So, I don’t recommend relying on Unison to sort out conflicts. I plan to sync often, backup often, and avoid conflicts as much as possible. This is for advanced users.

Tomboy Concerns: I’m using Tomboy, but actually quite uncomfortable with the risk, since it depends on Mono. I’ve considered switching to Gnote, but haven’t yet because I’m concerned about losing data/synchronization compatibility. But, this solution might work for Gnote too, and I may well s/Tomboy/Gnote/g in the near future.

Step 1: Desktop

1A: Install Unison

Unison is cross-platform and available for a variety of operating systems

I have Ubuntu on both my laptop and server right now, and I’m syncing through that server (instead of directly to my N900, which would be another option).

In Ubuntu, you can install unison with the command:
sudo apt-get install unison

Or, if you want a GUI:
sudo apt-get install unison-gtk

1B: Create a Unison profile for Tomboy

I created a file called ~/.unison/notes.prf with the following text:
# Unison preferences file
root = /home/balleyne/.local/share/tomboy/
root = ssh://alleyne.to/.local/share/tomboy/

I decided to sync my notes with the Tomboy directory on my server, which is also a workstation.

Now, I can synchronize the notes on my laptop with my server by running the command:
unison notes

1C: Enable NoteDirectoryWatcher Add-in for Tomboy

Tomboy doesn’t automatically look for changes to notes on the file system unless you enable the NoteDirectoryWatcher Add-in: Edit > Preferences > Add-Ins > Tools > Note Directory Watcher > Enable. This way, Tomboy will accept any changes you get from the Unison sync.

Step 2: Mobile

2A: Installing Unison in Maemo 5

To compile Unison, you need the OCaml compiler. To compile OCaml, you need the gcc compiler. I began the process of compiling compilers, but then realized that there were some unison .debs available already:

These were compiled for an older version of Maemo, but the command line version seems to be working fine for me in Maemo 5. Note, that if you use the GUI, it’s standard GTK, not a Maemo port, so you might need the stylus to use it.

To install, I ran the following commands:
$ sudo gainroot
# wget http://www.bundyo.org/maemo/unison/unison_2.27.57-2_armel.deb
# dpkg -i unison_2.27.57-2_armel.deb

2B: Create a Unison profile for Conboy

Similar to step 1B, I created a file at ~/.unison/notes.prf:
# Unison preferences file
root = /home/user/.conboy
root = ssh://alleyne.to/.local/share/tomboy

Now, I can sync my mobile computer with the server by running the command:
unison notes

And there was much rejoicing.

Conclusion

With Unison configured, I now have a basic, low-level sync between Tomboy and Conboy. I’m getting into the habit of syncing every time I change anything, to avoid conflicts. This should tie me over until a Conboy Snowy sync is available.

Creative Commons Attribution-ShareAlike 4.0 International Permalink | Comments (5)

It’s Not A Phone, It’s A Mobile Computer

Nokia N900
Credit: mackarus [CC BY]

People keep asking me about my new “cell phone,” but the Nokia N900 isn’t a phone. It’s a handheld, mobile computer. Calling it a phone is like calling a house a bed—sleeping is just one thing you do inside a house.

I became interested in the Nokia N900 in the fall, and after a several good reviews, I ordered one off eBay earlier this month. The N900 is the first from a series of Nokia Internet tablets to have cellular capabilities, but the SIM card doesn’t overshadow all the other things you can do with the device—it just frees you to connect to the Internet on the go. The day after it arrived, I signed up with WIND Mobile (another contributing factor to the purchase: leaving Rogers). The combination of a powerful mobile computer, and unlimited 3G data for just $35/month has changed the way I use the Internet.

Yes, it can handle phone calls and SMS messages, but it’s totally arbitrary that a call is a cellular call as opposed to over Google Talk or SIP / VOIP, or that a message is SMS rather than IM; the same applications are used in either case. I can use it as a cell phone, but I can also use it as an Internet tablet, GPS, digital audio player, camera, etc.

Maemo, the operating system that comes installed on the N900, is a fully-featured GNU/Linux distribution. Android shares a common (ish) kernel with other Linux-based distributions, but Maemo has much more in common with the operating system running on my laptop. It uses the same system for finding and installing new software, and it has a lot of the same applications available, since it’s easier to port from other GNU/Linux distributions. Rather than forcing developers to write Java “apps,” Maemo makes a variety of common development environments available. Thus, it’s the first platform to see a Firefox mobile release.

It’s a computer, not a phone. And it’s not just semantics. When we think of mobile computers as merely “phones,” we tolerate restrictions that we would otherwise reject on our computers. How many iPhone users would come to Apple’s defence if they instituted the same strict policies and arbitrary limitations on third-party applications for a Macbook as they do on their mobile computer? (Update: I spoke literally hours too soon.) Recognizing that these devices are really mobile computers is an essential step to gaining control over our mobile computing. Carriers and handset makers control our phones. We should control our own computers.

Google has tried to replace the term “smartphone” with it’s own buzzword — “superphone” — but it’s not just the “smart” part that’s become inadequate. It doesn’t make sense to call these devices “cell phones” anymore than it would make sense to call the buildings we live in “beds.” I have a handheld computer, and my carrier is my ISP.

ps I wrote and edited this post on my N900 using MaStory

Creative Commons Attribution-ShareAlike 4.0 International Permalink | Comments (3)