Archive

Posts Tagged ‘msynctool’

Finally Synching my Blackberry on Linux

January 2nd, 2010 18 comments

Some readers may recall all of the attempts that I’ve made in the past to synchronize my Blackberry with Mozilla’s Thunderbird email and calendar client. During each of these tries, I had relied on the OpenSync framework, along with the Barry project for communication with my phone, and a number of different solutions to link into Thunderbird. At various times, these included the opensync-plugin-iceowl, opensync-plugin-sunbird, and bluezync packages, none of which yielded success.

While running GNOME on my Debian laptop, I had managed to successfully synchronize my phone with the Evolution mail client. Even so, I continued to work at Thunderbird synchronization because I disliked Evolution, seeing it as a Microsoft Outlook clone, which is a platform that I have had considerable problems with in the past.

With my recent installation of Kubuntu 9.10 on my PC, I have been exposed to the Kontact PIM suite, and have thus far been impressed. Kmail is a solid email client, although the way that it handles the setup of multiple email accounts is confusing to say the least, forcing the user to create a sending, receiving, and identity object for each account, and then to link them together. Likewise, Kontact is a decent application, but is sorely lacking basic GUI configuration options, something I never thought that I would say about a KDE app. Finally, Kalendar does everything that one would expect, and allows the user to display appointments in a number of useful ways. All have excellent integration, and live in a tray widget that uses the native KDE notifications system to let me know when something important has happened.

Most importantly however, I managed to get the entire Kontact suite to sync with my Blackberry after about five minutes of playing around in the terminal. Unlike during previous installation attempts, I found the latest stable Barry packages available in my repositories, so installation was a snap. I simply added the following packages to my system:

  • libopensync0 v0.22-2
  • multisync-tools v0.92
  • libbarry0 v0.14-2.1
  • opensync-plugin-kdepim v0.22-4
  • opensync-plugin-barry v0.14-2.1

From a terminal, I then used the msynctool application and the following steps to do a little bit of configuration:

  1. msynctool –listplugins if the install went well, this command should list both kdepim-sync and barry-sync as available plugins
  2. msynctool –addgroup BB create an OpenSync sync profile for my Blackberry called BB
  3. msynctool –addmember BB barry-sync add the barry-sync plugin to the BB sync group
  4. msynctool –addmember BB kdepim-sync add the kdepim-sync plugin to the BB sync group
  5. msynctool –showgroup BB this lists each of the plugins that we just added to the BB sync group, along with their member numbers. In my case, barry-sync was member number 1, and kdepim-sync was member number 2. The output also showed that while barry-sync still needed to be configured, kdepim-sync had no configuration options to be set.
  6. msynctool –configure BB 1 configures member number 1 of the sync group BB. In my case, this was barry-sync, and simply popped a config file in the nano text editor. All that had to be changed in the file was the PIN of the Blackberry that the plugin would attempt to sync with.
  7. msynctool –sync BB actually performed the synchronization process. For safety’s sake, I made sure that Kontact was fully closed before running this command.

And that’s it! In the future, I simply have to run the msynctool –sync BB command to synchronize my Blackberry with Kontact. That’s one more reason to stick with Linux – Blackberry synchronization that isn’t tied to Microsoft Outlook!




On my Laptop, I am running Linux Mint 12.
On my home media server, I am running Ubuntu 12.04
Check out my profile for more information.

Blackbery Sync Attempt #3: Compiling from Source

October 5th, 2009 7 comments

After my first two attempts at getting my Blackberry to sync with Mozilla Thunderbird, I got pissed off and went right to the source of my problems. I emailed the developer of the opensync-plugin-mozilla package that (allegedly) allows Thunderbird to play nicely with OpenSync, and gave him the what for, (politely) asking what I should do. He suggested that I follow the updated installation instructions for checking out and compiling the latest version of his plugin from scratch instead of using the older, precompiled versions that are no longer supported.

I set to it, first removing all of the packages that I had installed during my last two attempts, excluding Barry, as I had already built and installed the latest version of its libraries. Everything else, including OpenSync and all of its plugins went, and I started from scratch. Luckily, the instructions were easy to follow, although they recommended that I get the latest versions of some libraries by adding Debian’s sid repositories to my sources list. This resulted in me shitting my pants later in the day, when I saw 642 available updates for my system in Synaptic. I figured out what was going on pretty quickly and disabled updates from sid, without ruining my system. If there’s one thing that Windows has taught me over the years, it is to never set a machine to auto-install updates.

Once I had the source code and dependency libraries, the install was a snap. The plugin source came with a utils directory full of easy to use scripts that automated most of the process. With everything going swimmingly, I was jarred out of my good mood by a nasty error that occurred when I ran the build-install-opensync.sh script:

CMake Error at cmake/modules/FindPkgConfig.cmake:357 (message):
None of the required ‘libopensync1;>=0.39′ found
Call Stack (most recent call first):
cmake/modules/FindOpenSync.cmake:27 (PKG_SEARCH_MODULE)
CMakeLists.txt:15 (FIND_PACKAGE)

CMake Error at cmake/modules/FindOpenSync.cmake:46 (MESSAGE):
OpenSync cmake modules not found.  Have you installed opensync core or did
you set your PKG_CONFIG_PATH if installing in a non system directory ?
Call Stack (most recent call first):
CMakeLists.txt:15 (FIND_PACKAGE)

It turns out that the plugin requires OpenSync v0.39 or greater to be installed to work. Of course, the latest version of same in either the Debian main or lenny-backports repositories is v0.22-2. This well-aged philosophy of the Debian Stable build has irked me a couple of times now, and I fully intend to update my system to the testing repositories before the end of the month. In any case, I quickly made my way over to the OpenSync homepage to obtain a newer build of their libraries. There I found out not only that version 0.39 had just been released on September 21st, and also that it isn’t all that stable:

Releases 0.22 (and 0.2x svn branch) and before are considered stable and suitable for production. 0.3x releases introduce major architecture and API changes and are targeted for developers and testers only and may not even compile or are likely to contain severe bugs.

0.3x releases are not recommended for end users or distribution packaging.

Throwing caution to the wind, I grabbed a tarball of compilation scripts from the website, and went about my merry way gentooing it up. After a couple of minor tweaks to the setEnvOpensync.sh script, I got the cmpOpensync script to run, which checked out the latest trunk from the svn, and automatically compiled and installed it for me. By running the command msynctool –version, I found out that I now had OpenSync v0.40-snapshot installed. Relieved, I headed back to my BlueZync installation. This time around, I managed to get right up to the build-install-bluezync.sh script before encountering another horrible dependency error:

– checking for one of the modules ‘glib-2.0′
–   found glib-2.0, version 2.16.6
– Found GLib2: glib-2.0 /usr/include/glib-2.0;/usr/lib/glib-2.0/include
– Looking for include files HAVE_GLIB_GREGEX_H
– Looking for include files HAVE_GLIB_GREGEX_H – found
– checking for one of the modules ‘libxml-2.0′
–   found libxml-2.0, version 2.6.32
– checking for one of the modules ‘libopensync1′
–   found libopensync1, version 0.40-snapshot
– checking for one of the modules ‘thunderbird-xpcom;icedove-xpcom’
–   found icedove-xpcom, version 2.0.0.22
–     THUNDERBIRD_XPCOM_VERSION 2.0.0.22
–     THUNDERBIRD_VERSION_MAIN 2
–     THUNDERBIRD_XPCOM_MAIN_INCLUDE_DIR /usr/include/icedove
–     NSPR_MAIN_INCLUDE_DIR /usr/include/nspr
–     THUNDERBIRD_XPCOM_LIBRARY_DIRS /usr/lib/icedove
–     THUNDERBIRD_XPCOM_LIBRARIES xpcom;plds4;plc4;nspr4;pthread;dl
– checking for one of the modules ‘sunbird-xpcom;iceowl-xpcom’
–   found iceowl-xpcom, version 0.8
SUNBIRD_INCLUDE_DIRS /usr/include/iceowl;/usr/include/iceowl/xpcom;/usr/include/iceowl/string;/usr/include/nspr
SEVERAL
–      SUNBIRD_MAIN_INCLUDE_DIR /usr/include/iceowl
–      SUNBIRD_VERSION 0.8
– Found xpcom (thunderbird and sunbird):
–   THUNDERBIRD_XPCOM_VERSION=[2.0.0.22]
–   SUNBIRD_VERSION=[0.8]
–   THUNDERBIRD_VERSION_MAIN=[2]
–   SUNBIRD_VERSION_MAIN=[0]
–   XPCOM_INCLUDE_DIRS /usr/include/nspr;/usr/include/icedove;/usr/include/icedove/addrbook;/usr/include/icedove/extensions;/usr/include/icedove/rdf;/usr/include/icedove/string;/usr/include/icedove/xpcom_obsolete;/usr/include/icedove/xpcom;/usr/include/icedove/xulapp;/usr/include/iceowl
–   XPCOM_LIBRARY_DIRS /usr/lib/icedove
–   XPCOM_LIBRARIES xpcom;plds4;plc4;nspr4;pthread;dl
–   SUNBIRD_VERSION 0.8
CALENDAR_VERSION=[8]
LIBTBXPCOM_INCLUDE_DIR
XPCOM_LIBRARIES  xpcom;plds4;plc4;nspr4;pthread;dl
ENABLE_TESTING [yes]
TESTING ENABLED
– checking for one of the modules ‘check’
CMake Error at cmake/modules/FindPkgConfig.cmake:357 (message):
None of the required ‘check’ found
Call Stack (most recent call first):
cmake/modules/FindCheck.cmake:27 (PKG_SEARCH_MODULE)
CMakeLists.txt:73 (FIND_PACKAGE)

CMAKING mozilla-sync 0.1.7
– Configuring done

From what I can gather from this output, the configuration file was checking for dependencies, and got hung up on one called “check.” Unfortunately, this gave me zero information that I could use to solve the problem. I can verify that the install failed by running msynctool –listplugins, which returns:

Available plugins:
msynctool: symbol lookup error: msynctool: undefined symbol: osync_plugin_env_num_plugins

Ah, shit. Looks like I’m stuck again. Maybe one day I’ll figure it out. Until then, if any of our readers has ever seen something like this, I could use a couple of pointers.