CMake-ifying git

by ⋅ 10 Comments

I’m going to use git for a project of mine and instead of parsing git’s output (which is the adviced way to use it from your application), I thought I’d rather use libgit and link to it. The first step was getting rid of autohell and moving to CMake.

This patch against git’s current master branch includes the CMakeLists.txt file and a few modifications to the source (mostly due to the different way variable replacement works in autotools vs CMake).

So far, only libgit, libxdiff and git are built. Will I go go for the other binaries (gitweb, gitk, etc)? I’m not sure, as I’m not interested but it shouldn’t be difficult to CMake-ize those.

I think the move from autotools to CMake could be very useful for the msysgit* developers, as they no longer would depend on MSys*

* I have not tried to build git on Windows with my CMakeLists.txt yet, I’ll do it tomorrow

** It’s not actually true yet: I run two bourne shell-scripts but I could easily rewrite those in CMake, too.

Update I’ve produced a new patch, as the old one did not perform a few needed renames

Is your keyboard working funny after updating to my backports?

by ⋅ 3 Comments

If you use Ubuntu and have added my Personal Package Archive to your /etc/apt/sources.list, you surely have noticed I have “backported” a lot of “sensitive” packages Hardy: Qt4, Glib, Gtk+, Cairo, lsb-base, HAL, hdparm, alsa, GNU parted, PCRE, etc. There are a lot more packages, not that “sensitive”: Samba, CMake, Telepathy, GStreamer, Rails, Boost 1.36.0, libvirt, Qemu, KVM, rdesktop, git, Apache, rsync, etc

If Ubuntu Intrepid or Debian Unstable or Experimental had the latest upstream version, I backported it to Hardy. If upstream was newer, I took the latest Debian/Ubuntu packaging and used that for the latest upstream version, with some fixes here and there.

This usually works fine because I’m careful and I test the packages myself. Actually, that’s the only reason I backport stuff: I usually need versions newer than the available ones in Ubuntu.

So far, the count had been “broke: 0 – fixed: a lot”, my biggest “success” being providing a fixed GNU Parted for bug 107326 months before Ubuntu did.

This time, however, I have inadvertedly inherited a bug present in some update (probably HAL), which makes your keys work in a “funny” way. First user to report that to me has been Michael Adams: “Having updated with your backports, I notice that my arrow keys have been converted to macro keys: my side keys don’t work, and up takes screenshots”. And indeed that happens! In my defense, I have to say I had not noticed before because I seldomly reboot my computer, so changes had not been applied to my system yet.

What’s the fix? Apparently nobody knows for sure (sometimes a reboot fixed it, sometimes setkbmap is needed) but it’s been already reported, see bug 255008.

Why am I posting this to Planet KDE? Because although the bug report barely mentions it, it does happen with KDE, too.

PS: If you use the ATI proprietary drivers, dual-head configuration, and one of your monitors is rotated (i. e. in vertical instead of horizontal), please contact me. Rotation was easy with NVidia but I’ve been unable to get it to work with ATI ðŸ™

Subtle errors

by ⋅ Leave a Comment

I am adding Strigi support to an application using the Strigi socket interface (it’s faster than DBus and, in my case, easier to use). When using the socket interface, Strigi needs to to know where the socket should be created (for instance, /home/pgquiles/.strigi/socket) and it will search for indices in a subdirectory of that directory (/home/pgquiles/.strigi/clucene if using the CLucene backend, /home/pgquiles/.strigi/estraier if using the HyperEstraier backend, etc).

So I was telling Strigi the socket should be created in /home/pgquiles/.strigi/socket and to use the CLucene backend, thus indices would be looked for in /home/pgquiles/.strigi/clucene. Problem is, I was not getting any result back!

    std::string socketpath("/.strigi/socket");

    const char *homeVariableName = "HOME";
    char *home = getenv(homeVariableName);

    if( 0 != home ) {
      std::string socketpath = std::string(home) + "/.strigi/socket";      
    }

    socket.setSocketPath( (const char*)socketpath.c_str() );

Notice the subtle error with block-scoped std::string socketpath hiding method-scoped std::string socketpath. Due to that, Strigi tried to use a socket from /.strigi/socket (which did not exist) instead of the right one, so it did not even try to look for indices!.

Sun Studio 12 and Apache STDCXX

by ⋅ Leave a Comment

This is mostly a self-reminder

I attended aKademy 2008 and there are so many things to write about I don’t even know what to start with. I’ll probably write something in a few days, when I’m feeling less sick (thanks to a Flemish waiter who had the OpenBossa guys, Knut and I waiting for almost one hour for dinner, I got a cold).

As you may know, part of my job (and hobby, too) consists on “shaking” software to make it compile on different platforms and with different compilers: I port Linux software which builds with gcc to Windows with Visual C++, or Visual C++ to MingW, or… well, whatever. It’s funny.

Back on topic: Wednesday as the Sun tutorials day and I got immediately interested in Sun Studio. Message to Sun Microsystems people: your installer is so broken on Linux it is impossible to make it work on Debian and Ubuntu (and I guess on anything other than RHEL). The only way I found to “install” SS12 was to download the Express version, remove the sh-code and untar the resulting package. It works but it’s so nasty hardly anybody would try that.

Sun Studio 12 is 100% ISO C++ compliant, which means support for wchar_t is not as good as most applications require nowadays. The best way to overcome this limitation is to use Apache Foundation’s STDCXX to replace SS12’s STL (which is STLport 4 (according to Adriaan, stdcxx would roughly correspond to STLport 6)

Building STDCXX is relatively easy, if you know the tricks:

  • export PATH=/path/to/sunstudioceres/bin/:$PATH
  • export CC=/path/to/sunstudioceres/bin/suncc
  • export CPP=/path/to/sunstudioceres/bin/suncc
  • export CXX=/path/to/sunstudioceres/bin/sunCC
  • You should be able to do this step by exporting CFLAGS, etc but it won’t work, so edit stdcxx-4.2.1/etc/config/sunpro.config and:
  • Replace
    CXXFLAGS= -library=%none
    with
    CXXFLAGS = -library=no%Cstd -YI,/path/to/source/of/stdcxx/include/
  • Replace
    CPPFLAGS =
    with
    CPPFLAGS = -YI,/path/to/source/of/stdcxx/include/
  • Replace
    LDFLAGS= -library=%none
    with
    LDFLAGS = -library=no%Cstd
  • make BUILDTYPE=12d
  • make locales(if you don’t use BUILDTYPE=12d, current Sun Studio Express Edition fails with yi_US, thus you need to edit stdcxx-4.2.1/etc/nls/gen_list and remove that line)
  • cd build && make install PREFIX=/where/you/want/to/install/stdcxx

    • At the moment, I’m trying to get Wt built with Sun Studio 12 on Linux. Given that SS12 is the compiler of choice for KDE4 on Solaris, I may try to get KDE4 built on Linux with SS12 at a later stage. That would help both the Solaris port and the Linux code.

    PS: Hello Planet KDE

    tux3

    by ⋅ Leave a Comment

    Daniel Phillips, the guy behind Zumastor and ddsnap, csnap, RamBack and many other brilliant developments is doing it again: yesterday he announced the tux3 versioned filesystem (as opposed to ddsnap, which was a software layer on top of any other filesystem) which uses versioned pointers instead of copy on write.

    He has also written a preliminary comparison with the HAMMER filesystem by Matt Dillon, which is included in DragonflyBSD 2.0

    Now, give up your hesitations and subscribe to the tux3 mailing list. Always keep an eye on everything Dan does because he is really smart!

    PS: Digg the story!

    Record a screencast with ffmpeg

    by ⋅ 3 Comments

    ffmpeg has been able to record a screencast on X11 for a long time now, using the x11grab input format and the :0.0 device (for the first instance of X). You’d run
    ffmpeg -f x11grab -y -r 12 -s 800x600 -i :0.0+480,200 -vcodec ffv1 -sameq ./out.avi
    and get a lossless video of the upper right 800×600 area of a 1280×800 desktop. Easy. You could even transcode to a lossy format (such as H.264, Xvid or Theora) if you had a powerful machine.

    On Windows it was not that easy. First of all, Windows is not X11, so x11grab does not work on Windows. You need to use GDI or DirectX but ffmpeg did not have support for GDI or DirectX capture. If you wanted screen-grabbing features in you application, either you developed your own solution (ugly, specially because of the video encoding part) or you used Camtasia Studio (Wink does not include a DLL or ActiveX component you can use in your app).

    Ramiro Polla and Christophe Gisquet had a heated discussion about one and a half years ago and some very interesting code was shown. Unfortunately, neither Ramiro’s nor Christophe’s code would work with current ffmpeg.

    Today I’ve finally brought Ramiro’s code up to date and it works with ffmpeg trunk. It is not perfect, though: it does not capture the mouse pointer, contextual menus shown as a result of a right-click and video scaling and color is not perfect (ffplay shows the video a little blue-ish). Patch. I’ll try and bring Christophe’s code up to date tomorrow, or fix Ramiro’s code.

    PS: A request for ffmpeg developers: please, replace your custom configure script with some cross-platform build system. I like CMake but Scons, Waf and others would also do.

    Amarok 2 on Windows (will full codec support)

    by ⋅ 11 Comments

    Yesterday I stayed up until 4:30 AM while trying to fix Amarok to works on Windows and when I got it to build it was so late I was too tired to test it. So I fired it this morning and this is the result (click for larger images):

    I have tested and it plays MP3, WMA, APE and whatever Magnatune streams on. Built with Visual C++ 2008.

    Update Two more screenshots added and in case you were wondering, yes, Plasma works!

    xkb-data y ~

    by ⋅ Leave a Comment

    Si utilizas una distribución de Linux/BSD/etc con servidor X11 X.org (el 99%) y estás te ha afectado el bug 9763, que hace que para teclear ‘~’ (dead tilde haya que pulsar AltGr + 4 dos veces (en lugar de una), aquí tienes el parche que corrige el caso de la tilde muerta.

    Para Ubuntu Hardy, hay paquetes en mi PPA

    Y ahora, que alguien me explique qué clase de mantenedor es el de los mapas de teclado en X.org que cambia el mapa de teclado de español de España porque un usuario brasileño se queja de que cuando tiene puesto el mapa de teclado de portugués y está escribiendo castellano se le hace raro tener que pulsar AltGr+4 para que le salga la ‘~’ (que por otra parte, no hace falta para escribir el idioma, ¡es un carácter especial!). Grrrrr.

    Kubuntu Hardy, ksynaptics

    by ⋅ Leave a Comment

    Yesterday I started preparing my computer and myself to upgrade from Kubuntu Gutsy to Kubuntu Hardy.

    As trivial as it might seem, any upgrade is quite complex to me because I use a lot of post-stable, and even post-unstable, packages coming from my PPA. I backport packages from Ubuntu unstable, Debian unstable and experimiental, and quite often I package myself versions which are not available yet in any of the former.

    Given that the PPA “copy packages” feature does not work for me (when I copy a Gutsy package to a Hardy package, it is built but never made available for Hardy from my PPA), yesterday I spent most of the day producing Hardy versions of my packages and fixing issues (what’s with the libfcgi maintainers!? why are they slightly changing the package name almost with every release!?)

    In the end, the upgrade went mostly fine: everything worked save for my USB external disk, the mouse in X, and the volume control. The only missing application was KSynaptics, which I use to disable the touchpad 99% of the time (I like it better my laser mouse).

    The external USB disk issue was rather easy to fix: just add usb-storage to /etc/modules.

    The mouse problem has drove me crazy for a couple of hours but I finally figured it: the new xorg.conf had set the mouse to InputDevice "Mouse0" "AlwaysCore" (whatever AlwaysCore means) and the fix was as easy as commenting out the "AlwaysCore" part.

    KSynaptics missing proved to be a bit more complex. The application does not work with modern versions of X.org, apparently due to X.org people forgetting about proper versioning of APIs, therefore KSynaptics’ developer decided to stop working on it and starting a new application (TouchFreeze) with a different approach. While TouchFreeze works fine, it was missing the enable/disable touchpad actions, which are the only reason I wanted to use it. But my friends, that’s the joy of open-source: I took the sourced code and a few minutes later I had implemented those actions and added a “disabled” icon like the one KSynaptics had. Here is the patch against TouchFreeze 0.2, in case you want to use it (I’ve sent it to the author to inclusion in a future release of TouchFreeze)