Gnash makes me gnash my teeth in frustration

A new release of Gnash has arrived: 0.8.9. I like the idea of having an open-source Flash plugin, but Gnash has never quite managed to fill my needs; I was thinking with the new version, things might be a bit better. Alas, after compiling and installing Gnash 0.8.9, all I see are grey rectangles where flash movies should be. This is worse than the previous version! At least with 0.8.8 some flash movies did work.

When starting firefox from the terminal, I see this error output:

Error: Support for renderer agg was not build

“agg” refers to the antigrain renderer, which I indeed I *hadn’t* built. However, one would assume that if there is an option not to build a renderer, then that renderer is indeed optional to the operation of the software. Delving into the source, I discovered that the “agg” renderer was being set as the default at an early stage (in the command line options parsing, which is done via the boost library’s “program_options” module), and because it was then considered set, the setting in the configuration file was not being used, nor was the logic normally used to choose a sensible default coming into play.

So, an easy fix, but it does appear that the release was severely under-tested.

Having now gotten the Gnash plug-in working, I can report that it seems to play youtube videos quite well, but still fails on some flash websites. Hopefully further progress will come soon!

Edit: bug filed.

X keyboard crap

I’m getting this in my log when I try to start X:

[  7780.894] (EE) Error compiling keymap (server-0)
[  7780.894] (EE) XKB: Couldn’t compile keymap
[  7780.894] XKB: Failed to compile keymap
[  7780.894] Keyboard initialization failed. This could be a missing or incorrect setup of xkeyboard-config.
[  7780.894]
Fatal server error:
[  7780.894] Failed to activate core devices.

What’s going on? “Couldn’t compile keymap” has to be one of the most useless error messages ever. Why can’t you compile the keymap??!

Update:

I renamed the “xkbcomp” executable and replaced it with a script which logged options and output before executing the original. I’m seeing this output:

The XKEYBOARD keymap compiler (xkbcomp) reports:
> Error:            Cannot open “/tmp/server-0.xkm” to write keyboard descriptio
>                   Exiting

… However, I don’t understand why it’s unable to create a file in /tmp. I’ve verified the file doesn’t already exist before xkbcomp is run, and that all users can create files in /tmp (the “t” bit is set).

Once again, the error message is bad: please tell my why you can’t open the file. (Hint: it’s called perror).

Update: (Solved!):

Turns out the permissions were the problem. They were:  rwxr-xrwt, i.e. the group was denied write permission. I didn’t think this was a problem seeing as “other” users are allowed to write files, but apparently that’s not how Linux permission checking works.

Sakura 2.4.0 build failure

I was just trying to build the Sakura terminal emulator. More-or-less following the instructions exactly, after running “cmake .”, I then ran “make” at which point I got the following:

Unknown option: u
make[2]: *** [CMakeFiles/man] Error 1
make[1]: *** [CMakeFiles/man.dir/all] Error 2
make: *** [all] Error 2

Yeah, it’s not exactly the most helpful output, is it? This is what I hate about CMake and non-standard build systems in general. Eventually I figured out the problem is in the file “CMakeFiles/man.dir/build.make” where the target “CMakeFiles/man:” calls the “pod2man” utility (from that almighty piece-of-crap scripting language, perl) with a “-u” argument which “pod2man” doesn’t seem to recognize (perl 5.8.8). Removing that makes the build complete.