Archive

Posts Tagged ‘mozilla’

Miscoloured PNGs: Firefox 3.5.4 Fails It Again

October 20th, 2009 1 comment

The Situation:

A while back I decided to see if I could install Firefox 3.5.4, because I like to live at the bleeding edge. I opted to go with 3.5.4, since version 3.5.3 decided to hue all blue PNG’s orange, as I mentioned in our first podcast.

The Process:

After checking in YaST Software Management to see if I could upgrade from 3.0.14 to 3.5.4 and finding out that no, no I could not, I decided to check my good friend Webpin. Webpin, being literally 1000000 times better than the piece of shit that is YaST Software Management, supplied me with a “one-click install” file for Firefox 3.5.4.

Hooray, Webpin rocks! Or does it...

Hooray, Webpin rocks! Or does it...

I’d like to point out that these one-click install files are hardly one-click. For your viewing pleasure, here is the shit you have to go through to install one of these bad boys:

YaST loaded up.

YaST loaded up.

After hitting next.

After hitting next.

Hitting next again.

Hitting next again.

After hitting next, yet again. Seeing a trend here?

After hitting next, yet again. Seeing a trend here?

Holy dialogs batman! 20 bucks if you can guess my root password!

Holy dialogs batman! 20 bucks if you can guess my root password!

Holy crap its finally installing!

Holy crap its finally installing!

Okay that last one didn't require me to click, but look! YaST fails at resolving a dependency, as usual.

Okay that last one didn't require me to click, but look! YaST fails at resolving a dependency, as usual.

Not only did YaST fail at installing, it also lied and told my the install was successful. I hate liars.

Not only did YaST fail at installing, it also lied and told my the install was successful. I hate liars.

Okay, so Webpin let me down too. That sucked pretty hard, as I like to think of Webpin as useful, and less shitty than YaST Software Management.

As a next-to-last ditch effort, I tried the openSUSE website’s page for Firefox. Here I was provided with yet another lovely one-click installer for the “most recent version of Firefox”. This one worked, and upon restarting Firefox, I was met with… wait for it… orange.

Its like Firefox threw up pumpkin guts all over my PNGs.

Its like Firefox threw up pumpkin guts all over my PNGs.

Checking in YaST Software Management showed a bugfix-type update for Firefox 3.5.4, which is confusing since I thought I just installed the most recent version of Firefox. Giving Mozilla the benefit of the doubt, I tried to update my installation, however once again I was met with an unresolvable dependency for xulrunner. At this point I decided that the bleeding edge had cut me deep enough, and I reverted back to Firefox 3.0.14.

This is what it's suppose to look like. Orange free since version 3?

This is what it's suppose to look like. Orange free since version 3?

The Conclusion:

I’m largely disappointed with this whole situation, and I don’t know if I’m to blame Linux, openSUSE, or Mozilla. Let me know in the comments if you’ve had a similar issue and/or found a way to fix it.

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.

Barry: Round Two with the Blogosphere riding Shotgun

September 30th, 2009 2 comments

Given the problems that I’ve been having lately with getting my Blackberry calendar and contacts to synchronize with anything in Linux, I was quite surprised when I almost got it working tonight. Forgetting everything that I’ve learned about the process, I started over, following these helpful tutorials and working through the entire install from the beginning. Unfortunately, aside from some excellent documentation of the install process (finally), the only new idea that those blogs provided me with was to try syncing the phone with different pieces of software. Specifically, Chip recommended KDEPIM, although I opted to  jump through a few more hoops before giving in and dropping the Thunderbird/Lightning combination entirely.

After a bit more mucking about, I decided to give up Lightning and installed Iceowl, Debian’s rebranding of Mozilla Sunbird, instead. Iceowl is the standalone calendar application that Lightning is based on, and is a very lightweight solution that is supposed to cooperate with the opensync-plugin-iceowl package. In theory, this allows calendar data to be shared between my device and the Iceowl calendar after configuring the plugin to read my Iceowl calendar from the /home/username/.mozilla/iceowl/crazyfoldername/storage.sdb file. In practice, the sync process gets locked up every time:

Screenshot-PIM Synchronization - KitchenSync-1

Why must you tease me?

Well, I’ve tried everything that I can think of to get my phone to synchronize with any Mozilla product. I’m very close to giving up, which is a shame, because they really are superior products. The ridiculousness of the entire thing is that I can easily dump my PIM data to a folder, and Thunderbird stores it’s data in an SQLite database. If this were Windows, I’d have written a VB app to fix my problems hours ago… Anybody know any python?

Update: I’ve also managed to successfully synchronize my phone with the Evolution mail client. Unfortunately, Evolution looks rather pale next to Thunderbird. In fact, the entire reason that I switched to Thunderbird about a week ago is that Evolution mysteriously stopped receiving my IMAP email with no explanation. No new email comes in, and the Send/Receive button is grayed out. Until now, I was happy with my decision, as Thunderbird is a superior application.

Barry: The Open-Sourced Blackberry Utility

September 30th, 2009 No comments

There is no denying that the installation process for the Barry project sucks. That said, the promise of having the ability to sync my blackberry with a linux-based calendar application like Mozilla’s Thunderbird or the Evolution mail client kept me working at it through the wee hours of the night. The Barry site at Sourceforge provides not one, not two, but four Debian packages (which rely on an additional two undocumented packages), that need to be downloaded and installed in a specific and undocumented order:

  1. libbarry0_0.15-0_i386.deb (sourceforge)
  2. barry-util_0.15-0_i386.deb (sourceforge)
  3. libglademm-2.4-1c2a (debian.org)
  4. barrybackup-gui_0.15-0_i386.deb (sourceforge)
  5. libopensync0 (debian.org)
  6. opensync-plugin-barry_0.15-0_i386.deb (sourceforge)

With the packages installed, I launched a terminal and used the auto-complete feature to find the command barrybackup. At first, I couldn’t figure out what it’s syntax was, until I realized that it doesn’t need any arguments, because it simply launches a GUI (that doesn’t appear anywhere in my Applications menu) that lets you back up your device databases:

Screenshot-Barry Backup

Well, thats a handy utility, assuming that it is also capable of restoring the backups to the device. I shied away from trying the restore feature, as I didn’t have access to a Windows box with which to fix the device should the worst happen.

I’m currently using Mozilla’s Thunderbird (re-branded in Debian as Icedove) as my primary mail client, along with the Lightning calendar plugin, and would be thrilled if I could synchronize it with my Blackberry. You’ll note that libopensync and a Barry opensync plugin were both a part of the installation process; having never used libopensync, I had a tough time figuring out how to make them cooperate.

The opensync page on Wikipedia lead me to install the multisync-tools package, which claims to be able to “synchronize calendars, address books and other PIM data between programs on your computer and other computers, mobile devices, PDAs or cell phones. It relies on the OpenSync  framework to do the actual synchronisation.” I have PIM data that I would like to sync! I have the OpenSync framework! We’re on a roll!

Finally, I installed the multisync-0.90 GUI and opensync-plugin-evolution v0.22-2 opensync plugin packages, which should have allowed me to sync between the Evolution mail client and my phone. I chose to try the process with this software first, as a plugin for Thunderbird was not immediately available. Unfortunately, when attempting to sync, I got this message:

Surprisingly, it was the evolution plugin that failed to connect

Surprisingly, it was the evolution plugin that failed to connect

Useful? Sort of. The Add button let me set up a Blackberry profile with both the barry and evolution plugins, but no matter how I tweaked the settings, I couldn’t get the evolution plugin to connect to my PIM data. Further, after making a synchronization group and adding plugins to it, I couldn’t find a way of replacing a plugin with a different one.

Sick of the limited GUI, I moved on to try KitchenSync, the KDE-based alternative. While it was uglier, I found it to be a far more useful front-end, and managed to get it to sync my device calendar and contacts with my filesystem:

Screenshot-PIM Synchronization - KitchenSync

This process exported all of the calendar and contact information from my Blackberry to a folder full of vCalendar and vContact files on my machine. Now if only I could get Thunderbird to read these files.

After a bit more looking around on the OpenSync webpage, I found a link to these guys, who claim to have programmed an opensync plugin called libopensync-plugin-mozilla-0.1.6 that allows Thunderbird and Lightning to talk to the OpenSync manager. They provide the plugin as a tarball that contains a *.so binary file and a sample *.xml configuration file… but no instructions on how to install them.

Thouroughly lost, I turned to the #opensync channel on freenode.net for help. Until they see fit to help me out, I’m taking a break from this. No sense in giving myself a heart attack out of extreme frustration.

Edit: I got some help from the members of the #opensync channel, who recommended that I drop the mozilla-sync.so file into the /usr/lib/opensync/plugins/ directory. While this didn’t immediately allow OpenSync to see the plugin, I noticed that every other plugin in the directory has an associated *.la configuration file. So I fabricated my own *.la file, and tried again. That didn’t work either.

The members of the channel then recommended that I try downloading the source code directly from the creators. I did as much, and found that it didn’t include a configure or make script, but just the source code. Not knowing how to proceed, I attempted to follow these instructions, which entailed downloading another 20 or so packages, including the sunbird-xpcom-devel package, which again lacks documentation on how to proceed with installation.

Lacking that package, and again frustrated beyond belief, I decided to drop the issue for another hour or so and do some math homework. That’s right, I chose to do math homework over playing with my computer, because this process has been that frustrating.

It doesn’t help that this entire process seems to be aimed at installed BlueZync, and not the opensync-mozilla-plugin. What the hell is going on here?