I’ve been playing around with waf in the last couple of weeks. My first contribution was helping Richard Hughes to port PackageKit to waf. We did 90% of the work in a couple of hours just guessing from the examples in the demos/ directory of the waf repository. Note that it took me a couple of weeks to accomplish a similar work with autotools with the same level of understanding.

Yesterday I started to extend the java tool, I added support for the JAVA_HOME environment variable and class_checking support. I wrote both patches in less than an hour. My next steps are adding support for manifest attributes for the jar files, and a better classpath elements handling. Thomas gently granted me write access to the waf repositories, so it looks that suddenly I’m a waf developer.

So far, the experience is pretty pleasant, I would like to see more stable releases in the future though, and maybe some autotools arg compatibility module (for –datadir, –configdir and the like) and It absolutely needs testing on more platforms, but it’s so easy to fix that it’s worth.

Regarding the discussion about porting GNOME to something else than autotools, I think that people asking maintainers to do it are losing some perspective on how important it is to keep what we have, there’s a lot of knowledge on our autoconf/automake scripts, so this can’t be done from day 0, and it can’t be a "waf xor autotools" approach, I think that a parallel effort of a small set of waf experts adding waf support to some modules is the best approach, we can get a lot of testing from there and we don’t need to break things.

One interesting focus here is the Windows builds, one of the reasons that prevents building GNOME from jhbuild on windows is that it’s painful to setup a sane environment due to require of a unix shell and make. Waf can play an important role here to allow a more pleasant Windows testing and development experience.

So, if you’re a GNOME maintainer, and you’re interested in exploring a new world of faster builds and easier maintainability, just poke us at #waf@irc.freenode.net, take a look at our wiki page or join to our mailing list.

Coming soon: a waf tutorial post.


Vala powered clutter reflection

Another dirty hack from the vala department.

I’ve done a generic clutter container class that takes a Clutter.Texture and performs the reflection effect.


Clutter reflection effect
YouTube / OGG

If you want to check it out, get the latest vala release (0.1.4 is mandatory to use the latest clutter bindings. so ubuntu universe packages won’t work), get the latest clutter release.

And grab the vala bindings for clutter from opened-hand’s svn:

$ svn co http://svn.o-hand.com/repos/clutter/trunk/bindings/clutter-vala

You can checkout the tests to have a closer look on how to clutter from vala.

Finally, clone the clutter-reflection git repository:

$ git clone http://people.freedesktop.org/~aruiz/vala/clutter-reflection.git


The light at the end of the tunnel.

Since I’ve joined Sun, I’ve been using Solaris/SPARC as my daily workstation (eventually I’ve got an x86 that I used for Linux testing). It got me a while to get used to the environment, and I’m absolutely thrilled about the core features (DTrace, ZFS, RBAC, Zones…) and the kernel side of the environment.

However, as a Debian guy, most of the development experience has been quite frustrating for me, the source of this frustration is in most cases directly or indirectly related to the lack of a decent packaging system on the environment, and the incompatibilities with the GNU world.

That’s why I got excited at the beginning of the whole Indiana thing around OpenSolaris. Ian and Glynn nailed exactly the problems that Solaris has to reach a wider audience and get its full potential, and the work done since the Indiana thing came into the scene has reached a point where I can see a comfortable Solaris enviroment for Linux guys as me.

Today I tried the development preview of Inidana, a try-before-install LiveCD iso image. That is, no more registration forms to try the cool Solaris features, no more neverendings DVD downloads, plus, bash as default shell, gnu userland as a first class citizen on the $PATH variable, ZFS as the default filesystem, graphical installer, network automagic, and tons of other cool stuff.

Congrats to all the people that have worked on achieving this, OpenSolaris is on it’s way now!

It actually booted pretty fast on my 512Mb x86 box, it had some problems to start the Gnome session, eventhough it started X smoothly. So I started with the command line, and started submitting bugs. And found some small bugs on the packaging system.

So I used the brand new bugzilla site for opensolaris and submitted my first two bugs (It’s actually pleasant to use the typical community tools that I’m used to for other projects):
#72 & #73


Now I’m looking forward to see some things happening around the community.
First is growth around the packaging effort as a community, there’s a lot of work done by the Blastwave and SFE guys, we just need to start providing IPS ports of that work.

Second, stop useless discussions about how important the shell is for some users on the indiana discuss list. I’m pretty sure you guys have strong reasons to prefer ksh or tcsh over bash, but try not to be selfish, the Indiana effort has a strong direction towards reaching more potential developers, which will end up with a bigger and healthier community.

The truth is, if you happen to care so much about shells, you have skills enough to perform ‘usermod -s /bin/myshell user’, people are getting sysadmin lessons on the universities using bash, the vast majority of the shell documentation you find out there, is bash.

PS: By the way Miguel, it turns out that OpenSolaris does cure cancer 😉