Category: Hacks

gnome-web-photo, Ubuntu and “Could not get gre path!”

Another issue I came across in my current adventures in gnome-web-photo land was that gnome-web-photo just stopped running after upgrading up through four different Ubuntu releases. gnome-web-photo crapped out with an error message about the GRE path being wrong, and the only resources on the web were commit messages from when the error message was changed and committed to the gnome-web-photo project.

Digging, digging and a bit more digging led me to suspecting that xulrunner wasn’t behaving as it should. stracing the gnome-web-photo binary (named gnome-web-photo.real on Ubuntu, as gnome-web-photo is a simple wrapper script) revealed that it was attempting to load a difference version of xulrunner than what actually were present (it tried fstat-ing a non-existant directory).

Checking out the current configuration of gre in /etc/gre.d (.. where I’ve never ventured before) indicated that DPKG had left the new package configuration without switching it to the standard configuration. This meant that the old GRE configuration was used, and not the new one. Renaming the old configuration file to gibberish and then removing the suffix from the new one solved the issue.

  • Removed: 1.9.1.14.system.conf
  • Renamed: 1.9.2.11.system.conf.dpkg-bak to 1.9.2.11.system.conf

.. and now gnome-web-photo actually works again!

gnome-web-photo and GConf Error: Failed to contact configuration server

This error was quite hard to track down, and was also the cause for gnome-web-photo timing out. Things worked when running from the shell, but when running it through our web service (as another user), gnome-web-photo went misbehaving!

Reports on the intarwebs suggested changing ownership of the .dbus directory (so dbus can work properly), but as we don’t have a regular home directory for the user (we actually have to set a fake one to fool mozilla when it’s creating its .mozilla directory) we didn’t have any .dbus directories.

After toying around and getting nowhere fast, I finally had a bit of luck with just running dbus-launch before gnome-web-photo. This worked once, then things went back to being crap. After reading through the dbus-launch man page I finally found out that you can make dbus-launch set up the environment for proper dbus access and then launch a command line you provide.

End solution:

dbus-launch /usr/bin/gnome-web-photo -t 30 --mode=photo --format png ..

Space, Page Up, Page Down, Home, End Broken for Navigation in Firefox

While I initially thought I had gone crazy or were still dreaming, my fear was true – all my keyboard page navigation had stopped working in Firefox (3.6.3). I tried to move onto to the next by pressing space or page down, my hands trembled as I discovered that neither arrow keys or home / end keys worked. The friendly internet suggested that I should turn Caret Browsing (F7) off (.. so try that if you’re in this situation), but that just told me that I were turning Caret Browsing on (with a proper warning). No luck.

After a bit of tinkering I disabled all my add-ons (previously known as extensions), and voilá, everything worked as it were supposed to! Further problem hunting revealed the culprit: The Del.icio.us Bookmarks Add-on. Curse you, del.icio.us! Disabling the Add-on and re-enabling all the other addons solved the issue, and I’m now happily browsing the internet one page size at the time again.

Trac and “ClearSilver not installed” message

After updating our debian installation on one of our servers we were left with a non-functioning Trac installation. An exception were thrown with a message about ClearSilver suddenly missing from our installation.

Solution: Debian packages ClearSilver ready for python:

apt-get install python-clearsilver

.. and party like it’s 2010!

Install rdiff-backup and librsync on RedHat Enterprise Linux 4

We’ve just installed rdiff-backup on some of our older RedHat Enterprise Linux 64-bit servers. We decided to install the .tar.gz-distributions and you can build your own rpms from these source packages (I won’t cover that here). There are a few pitfalls you’ll have to avoid.

First: librsync needs to be built with the 64-bit lib directory as the standard linkage, and needs to be compiled as a shared module.

To do this, provide configure with a few hints:

./configure LDFLAGS=-L/usr/lib64 --enable-shared --enable-lib64

Then make and make installldconfig to be sure that your LD cache has been updated (make install should do this, but .. just to be sure.)

The “.. can not be used when making a shared object; recompile with -fPIC” error for librsync will occur if you build it without –enable-shared, while “/usr/lib/libpopt.so: could not read symbols: File in wrong format” will occur if you build the library with the standard 32 bit libraries.

After this rdiff-backup compiled as it should:

python setup.py install

After rdiff-backup builds it python module and other small items, you might have to run ldconfig again (if you get “ImportError: librsync.so.1: cannot open shared object file: No such file or directory”, try this):

ldconfig

If you still get the above error, check that the directory where librsync was installed is present in either one of the files in /etc/ld.so.conf.d/ or in /etc/ld.so.conf itself. After adding the path to the library directory (which by default will be /usr/local/lib), run ldconfig again.

rdiff-backup should now (hopefully) work as expected.

Solr, Tomcat and HTTP/1.1 505 HTTP Version Not Supported

During today’s hacking aboot I came across the above error from our Solr query library. The error indicates that some part of Tomcat was unable to parse the “GET / HTTP/1.1” string – where it is unable to determine the “HTTP/1.1” part. A problem like this could be introduced by having a space in the query string (and it not being escaped properly), so that the request would have been for “GET /?a=b c HTTP/1.1”. After running through both the working and non-working query through ngrep and wireshark, this did however not seem to be the problem. My spaces were properly escaped using plus signs (GET /?a=b+c HTTP/1.1).

There does however seem to be a problem (at least with our version of Tomcat – 6.0.20) which results in the +-s being resolved before the request is handed off to the code that attempts to parse the header, so even though it is properly escaped using “+”, it still barfs.

The solution:

Use %20 to escape spaces instead of + signs; simply adding str_replace(” “, “%20”, ..); in our query layer solved the problem.

Making Friends With Emacs and UTF-8

After having a few issues with UTF-8 support in Emacs earlier (I .. well .. err .. use emacs as my .. mail editor.), I finally found a solution that works with both putty and gterm as my terminals.

The important settings I ended up using in my .emacs:

(prefer-coding-system       'utf-8)
(set-default-coding-systems 'utf-8)
(set-terminal-coding-system 'utf-8)
(set-keyboard-coding-system 'utf-8)

(setq x-select-request-type '(UTF8_STRING COMPOUND_TEXT TEXT STRING))

Archived for my own use at a later time.

Simple PHP Hack to Print an Integer in Binary Form

Today: Using my own blog as a simple pastebin to remember a helper function I wrote while debugging a good selection of binary operations on integers in PHP. This will simply output the provided value as bit values (0 / 1). Wrap it in <pre>-s if you’re running it in a web context.

$len allows you do change how many bits it will print (starting from lsb – least significant bit), $blockSize adjust the amount of bits before throwing in a space.

function printBinary($val, $len = 32, $blockSize = 8)
{
    print("\n");

    for($i = $len - 1; $i >= 0; $i--)
    {
        print(($val & 0x1<<$i) ? 1 : 0);

        if ($i%$blockSize == 0)
        {
            print (" ");
        }
    }

    print ("\n");
}

Varnish: No ESI processing, first char not ‘<‘

I’ve spent some time setting up varnish for a service at work where we deliver JSON-fragments from different resources as a unified document. We build the resulting JSON document by including the different JSON fragments through an ESI (Edge Side Includes) statement in the response. Varnish then fetches these fragments from the different services, allowing for independent caching duration for each of the services, combining then into a complete document.

The main “problem” is that of Varnish 2.0.4, varnish does a check to see if the content returned from the server actually is HTML-based content. It does this by check if the first character of the returned document is ‘<'. The goal is to avoid including binary data directly into a text document. Since we’re working with JSON instead of regular HTML/XML, the first character in our responses is not a ‘<', and the ESI statement did not get evaluated. You can however disable this check in varnishd by changing the esi_syntax configuration setting - just add the preferred value to the arguments when starting varnish. To disable the content check, add: 

varnishd … -p esi_syntax=0x1

I’m not sure if you can set this for just one handler / match in varnish as this solved our issue, but feel free to leave a comment if you have any experience with this.

Unbreak My Hea.. Firefox Ctrl Click Please!

When we launched Gamer.no over a year ago, we had to come up with a wallpaper advertising solution in a rush (everything were a rush back then as we built and launched a site from scratch (after disagreements between the previous owner and Gamer) in just under four days (or 96 hours)). While this solution has worked .. good enough .. it has always had a few irky bugs that I’ve never really had the right inspiration to uncover the cause of. Usually I’ve spent an hour and decided that the time wasn’t worth it at the moment and then moved onto something else, but today! Today is a glorious day!

The bug has been fixed!

The wallpaper element is placed around the main content div, which sadly also makes the wallpaper element receive any click elements that the main content div receives. This leads to the wallpaper getting clicked and the wallpaper ad window opening regardless of where people click – which will get very, very annoying very quick. So to battle this issue the original solution was to call .stopPropagation() on the evt object in a click handler for the main content div. This solved the issue and everyone rejoiced! However, all was not perfect in paradise.

Some time later we discovered that the .stopPropagation() fix borked ctrl-click a link in Firefox. Other browsers handled it just fine, but Firefox were obviously not happy. Not happy at all. Mad and going on a killing spree it shot down the proposed fixes from both myself and other people who had a brief look at the code. It wasn’t a big issue as we only run the wallpaper code for small intervals of time and people didn’t complain (maybe we were some of the few who had the issue).

Today I decided to have a look at the issue again, and finally I realized that we had been way to focused on our call to .stopPropagation(). Everyone had been planning how we could get .stopPropagation to do what we wanted it to do – after all – the issue was that stopPropagation didn’t behave when we ctrl-clicked in Firefox. But wait.

If you instead think of the original problem; the window.open gets triggered when people click the inner element instead of the outer, there may be alternative solutions to using stopPropagation. And yes, THAT was quite a simple fix. Instead of trying to stop the event from bubling up through the cloud.. let’s just set a status variable that tells the code handling the wallpaper click that THIS CLICK IS NOT FOR YOU BAD HANDLER GO AWAY LET OTHER GROWNUPS HANDLE THIS. So that I did.

$(document).ready(function () {
    innerClick = false;
    $('#wallpaper').click(function() {
        if (innerClick)
        {
            innerClick = false;
            return true;
        }
        
        window.open("..");
    });
    $('#content').click(function(evt) {
        innerClick = true;
    });
});

As soon as I actually spent some time on what we were trying to solve instead of what seemed like the cause of the issue .. everything went better than expected.