Getting included in Planet Ubuntu is proving to be quite difficult due to bureaucracy.

On one side, I’m too technical to apply for plain Ubuntu membership.

On the other side, given that all the work I do in my PPA (mostly backports for Hardy and Jaunty, but also some new packages not yet accepted in Debian) I do it on myself, with no external help, I don’t have a history of collaboration with other Ubuntu members/developers/MOTUs. Which means I don’t get any endorsement in my MOTU application.

In the end, I have the largest PPA in Launchpad, providing lots of backports for Hardy and Jaunty, but very few people know about it because I can’t blog about my backports in Planet Ubuntu. Weird.

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

Most of my coworkers use Qt4 but only on Windows. Some of them did not even know KDE existed, much less that since KDE 4.1 there are official packages and an official installer for Windows.

Last week, I wandered around the office, occasionally assaulting people to show them KDE on Windows, the API docs, this-and-that widget, answering their questions (mostly technical), etc (if you know how tackatpromotioned Marble at past aKademy-s, you know what I did 🙂 )

So, what was the reaction of people to KDE? Surprisingly, extremely good! I was expecting more resistance to the fact that to use K* classes, KParts, etc you have to convert your QApplication to a KApplication but they went like “the advantages of using KDE classes and KDE’s ActiveX [that’s how some of them call KParts] are so obvious I will do that as soon as I installing a development version of KDE on Windows is easy”. People specially liked the Kate, oKular and KPlato KParts (although I showed KPlato 1.6 and only on Linux). The pie-like ToolBox menu in Amarok also received some praising.

My conclusion: I really think we should raise more awareness of KDE among Windows developers and the “wander-around-and-assault-for-no-reason” approach works very well. Try it with your Win32 coworkers and friends and blog about KDE on Windows. Let’s get some momentum for KDE4 on Windows!

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 🙁

By coincidence, today I arrive to the ACCU website. ACCU is an organisation of programmers who care about professionalism in programming and are dedicated to raising the standard of programming. They publish a magazine (C Vu) and a newsletter (Overload), and organize a yearly conference in Oxford, UK. Slides from last year’s conference are available online and seem quite interesting. Next year‘s conference is from April 22 to April 25 and one of the three tracks will be about patterns.

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

    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!

    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.