My ARM development notes

These are my notes to get useful cross-compilation, even with autotools, and GStreamer stuff.

toolchain

The convention is to have ‘arm-linux-gcc‘ and so on, so that you can compile with ‘make CROSS_COMPILE=arm-linux-’, the kernel and many other projects assume this is the default.

First, you would need ‘~/bin‘ to be on your path, so make sure you have it on ‘~/.bash_profile‘ (export PATH="$HOME/bin:$PATH") or whatever your favorite shell uses.

I use CodeSourcery (GNU/Linux 2009q3), you can fetch it from here.

cd ~/bin
toolchain=/opt/arm-2009q3
for x in $toolchain/bin/arm-none-linux-gnueabi-*
do
ln -s $x arm-linux-${x#$toolchain/bin/arm-none-linux-gnueabi-}
done

QEMU

This is needed for sb2 in order to kind of emulate an ARM system.

git clone git://git.savannah.nongnu.org/qemu.git
cd qemu
git checkout -b stable v0.12.5
./configure --prefix=/opt/qemu --target-list=arm-linux-user
make install

sbox2

This is needed to avoid most of the pain caused by autotools (thank you GNU… not!).

git clone git://gitorious.org/scratchbox2/scratchbox2.git
cd scratchbox2
git checkout -b stable 2.1
./autogen.sh --prefix=/opt/sb2
make install

Add sb2 to the PATH:
export PATH=/opt/sb2/bin:$PATH

sb2 target

Now it’s time to configure a target.

cd /opt/arm-2009q3/arm-none-linux-gnueabi/libc/
sb2-init -c /opt/qemu/bin/qemu-arm armv7 /opt/arm-2009q3/bin/arm-none-linux-gnueabi-gcc

You can check that it works with:
sb2 gcc --version

GStreamer

We are going to install everything into ‘/opt/arm/gst‘, so:

export PKG_CONFIG_PATH=/opt/arm/gst/lib/pkgconfig

You can skip the steps here and go directly to deployment if you download and extract this tarball on your target.

zlib

This is needed by GLib’s gio (which cannot be configured out).

wget -c http://zlib.net/zlib-1.2.5.tar.gz
tar -xf zlib-1.2.5.tar.gz
cd zlib-1.2.5
sb2 ./configure --prefix=/opt/arm/gst
sb2 make install

glib

GLib has bugs (623473, 630910) detecting zlib (thank you Mattias… not!). So either apply my patches, or do the C_INCLUDE_PATH/LDFLAGS hacks below:

export C_INCLUDE_PATH='/opt/arm/gst/include' LDFLAGS='-L/opt/arm/gst/lib'

git clone git://git.gnome.org/glib
cd glib
git checkout -b stable 2.24.1
./autogen.sh --noconfigure
sb2 ./configure --prefix=/opt/arm/gst --disable-static --with-html-dir=/tmp/dump
sb2 make install

gstreamer

git clone git://anongit.freedesktop.org/gstreamer/gstreamer
cd gstreamer
git checkout -b stable RELEASE-0.10.29
./autogen.sh --noconfigure
sb2 ./configure --prefix=/opt/arm/gst --disable-nls --disable-static --disable-loadsave --with-html-dir=/tmp/dump
sb2 make install

liboil

Needed by many GStreamer components.

git clone git://anongit.freedesktop.org/liboil
cd liboil
git checkout -b stable liboil-0.3.17
./autogen.sh --noconfigure
sb2 ./configure --prefix=/opt/arm/gst --disable-static --with-html-dir=/tmp/dump
sb2 make install

gst-plugins-base

git clone git://anongit.freedesktop.org/gstreamer/gst-plugins-base
cd gst-plugins-base
git checkout -b stable RELEASE-0.10.29
./autogen.sh --noconfigure
sb2 ./configure --prefix=/opt/arm/gst --disable-nls --disable-static --with-html-dir=/tmp/dump
sb2 make install

gst-plugins-good

git clone git://anongit.freedesktop.org/gstreamer/gst-plugins-good
cd gst-plugins-good
git checkout -b stable RELEASE-0.10.23
./autogen.sh --noconfigure
sb2 ./configure --prefix=/opt/arm/gst --disable-nls --disable-static --with-html-dir=/tmp/dump
sb2 make install

Deployment

So now we have everything installed in ‘/opt/arm/gst‘, but how to run on the target? Just copy the exact same files into the target on the exact same location, and then:

export PATH=/opt/arm/gst/bin:$PATH

That’s it, you can run gst-launch, gst-inspect, and so on.

Development

Ok, it should be clear how to do development from the previous steps, but in case it wasn’t clear, here’s how to:

gst-dsp

Each time you want to cross-compile, you need to tell pkg-config where to find the packages:

export PKG_CONFIG_PATH=/opt/arm/gst/lib/pkgconfig

git clone git://github.com/felipec/gst-dsp.git
cd gst-dsp
git checkout -b stable v0.8.0
make

Note that gst-dsp doesn’t use autotools, so sb2 is not needed.

Now, once you have the plugin (libgstdsp.so), copy to ‘/opt/arm/gst/lib/gstreamer-0.10‘ on the target.

And finally, you can run real gst-launch pipelines:
gst-launch playbin2 uri=file://$PWD/file.avi

Note: If you are missing some elements, play around with flags (flags=65 for native video-only)

Do some more development, type make, copy, repeat :)

Enjoy ;)

GStreamer, embedded, and low latency are a bad combination

This has been a known fact inside Nokia (MeeGo) for quite a long time due to various performance issues we’ve had to workaround, but for some reason it wasn’t acknowledged as an issue when it was brought up in the mailing list.

So, in order to proof beyond reasonable doubt that there is indeed an issue, I wrote this test. It is very minimal, there’s essentially nothing of a typical GStreamer pipeline, just an element and an app that pushes buffers to it, that’s it. But then, optionally, a queue (typical element in a GStreamer pipeline) is added in the middle, which is a thread-boundary, and then the fun begins:

Graph for x86
Graph for arm

The buffer size legends corresponds to exponentiation (5 => 2 ^ 5 = 32), and the CPU time is returned by the system (getrusage) in ms. You can see that in ARM systems not only more CPU time is wasted, but adding a queue makes things worst at a faster rate.

Note that this test is doing nothing, just pushing buffers around, all the CPU is wasted doing GStreamer operations. In a real scenario the situation is much worst because there isn’t only one, but multiple threads, and many elements involved, so this wasted CPU time I measured has to be multiplied many times.

Now, this has been profiled before, and everything points out to pthread_mutex_lock which is only a problem when there’s contention, which happens more often in GStreamer when buffers are small, then the futex syscall is issued, is very bad in ARM, although it probably depends on which specific system you are using.

Fortunately for me, I don’t need good latency, so I can just push one second buffers and forget about GStreamer performance issues, if you are experiencing the same, and can afford high latency, just increase the buffer sizes, if not, then you are screwed :p

Hopefully this answers Wim’s question of what a “small buffer” means, how it’s not good, and when it’s a problem.

Update

Ok, so the discussion about this continued in the mailing list, and it was pointed out that that the scale is logarithmic, so the exponential result was expected. While that is true, the logarithmic scale matches what people experience; how else would you plot the range from 10ms to 1s? Certainly not linearly.

But there’s a valid point; the results should not be surprising. We can take the logarithmic scale out of the equation by dividing the total CPU time by the number of buffers actually pushed, as Robert Swain did in the comments, that should give a constant number, which is the CPU time it took to do a push. The results indeed converge to a constant number:

queue: 0.078, direct: 0.011

This means that in a realistic use case of pushing one buffer each 10ms through a queue, the CPU usage on this particular processor (800mhz) is 0.78%.

Also, there’s this related old bug that recently got some attention and a new patch from Wim, so I gave it a try (I had to compile GStreamer myself so the results are not comparable with the previous runs).

Before:
queue: 0.074, direct: 0.011

After:
queue: 0.065, direct: 0.007

So the improvement for the queue case is around 12%, while the direct case is 31%.

Not bad at all, but the conclusion is still the same. If you use GStreamer, try to avoid as many elements as possible, specially queues, and try to have the biggest buffer size you can afford, which means that having good performance and low latency is tricky.

Update 2

Stefan Kost suggested to use ‘queue’ instead of ‘queue2′, and I got a pandaboard, so here are the results with OMAP4.

pandaboard (2 core, 1GHz):
queue: 0.017, direct: 0.004

N900:
queue: 0.087, direct: 0.021

i386 (2 core, 1.83GHz):
queue: 0.0059, direct: 0.0015

So, either futex got better on Cortex A9, or OMAP4 is so powerful it can’t be considered embedded :p

gst-av 0.4; better performance for flac, vorbis and mp3 (part 2)

This is a continuation of my previous post. Based on the feedback I decided to do two things; investigate the strange FLAC high CPU usage with FFmpeg, and get more accurate measurements.

GStreamer sucks

It turns out that GStreamer flac parser uses four times more CPU than FFmpeg’s decoder. Thanks to perf, I was able to quickly figure out the biggest offenders: GStreamer’s horrible bitstream reader (GST_BIT_READER_READ_BITS) was by far the worst.

53.03% libgstbase-0.10.so.0.26.0
24.78% libavcodec.so.52.72.2
17.35% libgstxiph.so
1.52% libc-2.12.1.so

This is on my laptop just running the parser (filesrc ! flacparse ! fakesink), in total it was taking 2.67s.

After reading the code and trying different things, I decided to go for something similar to what FFmpeg is doing, and I also borrowed pieces of the architecture-specific optimizations, now it even looks ok:

72.68% libavcodec.so.52.72.2
14.20% libgstxiph.so
4.00% libc-2.12.1.so

And it takes 0.81s.

But how much would this affect battery life on the N900?

Smart battery script

I tried different ideas, and after refreshing myself on statistics I wrote this script in Ruby that runs all the tests, gathers the battery capacity in a separate thread, and finally generates a report per test. Much easier than before.

Since I’m already working on FLAC, I decided to also apply some patches that split the decoder from the parser, and optimizations from Måns Rullgård (good thing I grabbed them because he seems to have left the project and deleted his repos).

Battery life graph

Battery life


Battery drain graph

Battery drain

So, yeah, much better now ;)

But how credible are these results? Well, judge by yourself, listed below are the raw measurements, the samples are the differences in capacity (mAh) measured each 10 minutes, from which the drain and battery life are calculated.

== baseline ==
samples: 3, 3, 3, 3, 4, 5
drain: 21.00±1.87mA
life: 65.39±4.77h
== av flac ==
samples: 9, 8, 8, 8, 7, 8, 7
drain: 47.14±1.45mA
life: 28.19±0.87h
== flac ==
samples: 11, 11, 11, 11, 11, 11
drain: 66.00±0.00mA
life: 20.00±0.00h
== av mp3 ==
samples: 11, 11, 11, 11, 11, 10
drain: 65.00±0.91mA
life: 20.33±0.30h
== nokiamp3 ==
samples: 12, 12, 12, 12, 12, 12
drain: 72.00±0.00mA
life: 18.33±0.00h
== av vorbis ==
samples: 10, 11, 11, 10, 11, 11
drain: 64.00±1.15mA
life: 20.67±0.38h
== vorbis ==
samples: 19, 18, 18, 19, 18, 19
drain: 111.00±1.22mA
life: 11.90±0.13h

If you are interested in the code: gst-av, gst-maemo-xiph. Enjoy ;)

gst-av 0.3; better performance for vorbis and mp3

So, I’ve been working on gst-av, a GStreamer plug-in to use FFmpeg codecs (only audio for now), in order to get it in good shape for ogg support. First, I had to fix oggdemux and flacparse to be compatible with tagreadbin, it seems I managed to do it (with the help of a patch from Sreerenj Balachandran), so now the custom tracker extractors are not needed any more.

Then, with a bit of work I managed to get not only vorbis, but flac, and mp3 working.

That was good, but was it really worth it? Tuomas Kulve did a nice comparison of gst-av vs the default vorbisdec, and I wanted to do something similar, however, running a series of tests each taking 20 hours to complete wasn’t so appealing.

So I asked in #meego and #maemo IRC channels for a simple way to measure battery drain reliably, and automatically. It seems powertop can do that on some platforms, but Maemo’s powertop is a very different beast. Fortunately, the folks at #maemo seem to have been busy trying to get all possible information from the battery, and they pointed me to a very nice powerscript. However, I got some tips to get even better results (from ShadowJK, DocScrutinizer, and SpeedEvil), and the result is this maemo-battery script (needs i2c-tools, and root permissions), which essentially prints the current charge of the battery each 10 minutes.

With this I was ready, but just to be clear how to properly measure battery draw; make sure you are in offline mode, plug your headphones (otherwise pulse-audio would run extra algorithms), and immediately blank the screen.

Here are the results (units in hours of battery life):

These results show that vorbis with FFmpeg is massively better than libvorbis, so my work wasn’t in vain :) . But it’s also interesting that FFmpeg’s mp3 decoder is slightly better than Nokia’s proprietary one. Also, FFmpeg still needs some work to complete with libflac. My guess is that these decoders can’t be optimized much further; now the bottlenecks would have to be pulseaudio and gstreamer.

This is the raw data (in mA); I ran my script for one hour for each test, and some I ran multiple times just to verify; the results seem to vary ±1 mA.

current -- mp3: 63, vorbis: 110, flac: 62
gst-av -- mp3: 61, vorbis: 62, flac: 69

gst-ffmpeg

Why not use gst-ffmpeg? You might ask. Initially that’s what I tried, but it doesn’t support vorbis, nor flac, which seems to fit GStreamer’s tradition of getting away from FFmpeg as much as possible. Then when I read the code it was clear to me that it was overly complicated; I’m familiar with FFmpeg’s API (it’s unbelievably simple), so I decided to play around, and see if I could get something working; I did, and the result was incredibly simple, and oh so sweet :) As a comparison, gst-ffmpeg is 16357 lines of code, gst-av is 563 (sure, gst-av does much less; just what is needed). Another reason that goes hand-in-hand with this, is the ability to tweak it; my goal is to get the absolutely best performance, and for that I want to be able to understand what the code is doing. And finally, gst-ffmpeg is using deprecated API.

What about performance?

The difference is not that big: ~1.6h of battery life, but it’s something.

current: 63, gst-av: 61, gst-ffmpeg: 66

What now?

Now we need to package FFmpeg; probably just include the codecs we need, and then ogg support might include these instead. Any volunteers?

Update

It turns out the issue was flacparse which is total crap: it’s using 4 times more CPU time than FFmpeg’s decoder just for parsing. After fixing it now it takes only 20%. I’m trying to get new measurements in a more automated and precise way now. I’ve pushed the code to my repo already.

msn-pecan 0.1.1 released; important bug-fix

Hi,

This is a maintenance release with not so many changes, mostly to fix the nasty DST bug. Everybody is encouraged to update.

That’s basically it. Enjoy :)

Felipe Contreras (7):
      oim: trivial cleanups and reorganization
      Fix date parsing for DST
      tests: add tests for DST date parsing
      plugin: add official set_alias()
      oim: fix crash on bad auth
      win32: tag 0.1.1
      dc: trivial cleanup

Download from the (usual place).

felipec’s installation notes

I regularly get rid of my home directory in order to prune my configuration, get rid of cruft, and backup important stuff. Here I’ll try to share the important steps to get a decent linux system configuration from scratch. Some of these are specific to GNOME, and some to Fedora, but mostly are generic.

root permissions

I hate to type the root password so I add my user to the ‘wheel‘ group and edit ‘/etc/sudoers‘ to add:
%wheel ALL=(ALL) NOPASSWD: ALL

So I just need to type ‘sudo -i‘ and I log-in as root (no password).

openbox

The first thing to do is to get rid of that annoying metacity. I choose openbox because the defaults work fine, and it doesn’t need anything special, just install it, and re-login with “GNOME/openbox”; voilà.

Now you have a decent window manager that resizes windows with alt + right button. And also you can configure it in many ways.

However, if you decide to stay with metacity, this makes it slightly more usable:
gconftool-2 --set --type bool /apps/metacity/general/resize_with_right_button true

Update: I found XFCE to be much superior to GNOME, and the WM works as expected by default.

keyboard settings

The next annoying thing is the keyboard settings; I find the repeat rate too slow:
gconftool-2 --set --type int /desktop/gnome/peripherals/keyboard/rate 98
gconftool-2 --set --type int /desktop/gnome/peripherals/keyboard/delay 242

zsh

I find bash too conservative; zsh provides many more options and extensibility, so install the ‘zsh‘ package, copy ‘/etc/skel/.zshrc‘ to your home, and then as root:

usermod -s /bin/zsh <user_name>

However, the defaults don’t play well with gnome-terminal; each console will show “Terminal” instead of the cwd, so edit ‘~/.zshrc‘:

case $TERM in
    xterm*)
        precmd () { print -Pn "\e]0;%n@%m: %~\a" }
        ;;
esac

Unfortunately, zsh doesn’t use readline’s inputrc, but it’s easy to convert:

bindkey -e
bindkey "\e[1~" beginning-of-line
bindkey "\e[4~" end-of-line
bindkey "\e[5~" history-search-backward
bindkey "\e[6~" history-search-forward
bindkey "\e[3~" delete-char
bindkey "\e[2~" quoted-insert
bindkey "\e[5C" forward-word
bindkey "\e[5D" backward-word
bindkey "\e[1;5C" forward-word
bindkey "\e[1;5D" backward-word

# for rxvt
bindkey "\e[8~" end-of-line
bindkey "\eOc" forward-word
bindkey "\eOd" backward-word

# for non RH/Debian xterm, can't hurt for RH/DEbian xterm
bindkey "\eOH" beginning-of-line
bindkey "\eOF" end-of-line

# for freebsd console
bindkey "\e[H" beginning-of-line
bindkey "\e[F" end-of-line

After doing these changes, re-login.

Certain settings are not specific to zsh and can be shared with bash, for that I use '~/.profile', which I manually include on '~/.bash_profile' (not needed on '~/.zprofile'):, and link '~/.zprofile' to it.

test -r ~/.profile && . ~/.profile

history-search

I avoid typing as much as possible, and quite often what I want to do is already in the history, so I find history-search-* commands essential. Fortunately this is now enabled by default in Fedora 13, but for the unlucky ones here are the instructions.

First, copy '/etc/inputrc' to '~/.inputrc' and make a minor modification:
"\e[5~": history-search-backward
"\e[6~": history-search-forward

This allows nice searches through the history, like 'cp ' will search for the previous command starting with 'cp ', type PGUP again and will search backards again.

However, you'll need this on your '~/.profile':

export INPUTRC=$HOME/.inputrc

(a similar change would need to be done on zsh's bindkeys)

development

Many applications benefit from these (on '~/.profile'):

export EMAIL=felipe.contreras@gmail.com
export EDITOR="gvim --nofork"

And also, set your real name (as root):
usermod -c “Real Name” <user_name>

GNOME vim syntax

I like to have GLib code properly highlighted (in C), so I install gtk-vim-syntax which has a lot of stuff (D-Bus, GTK+, clutter, etc.).

Create '.vim/after/syntax', copy the files you are insterested on (glib.vim, gobject.vim, and gio.vim for me), and then, on c.vim:

runtime! syntax/glib.vim
runtime! syntax/gobject.vim
runtime! syntax/gio.vim

git

These go into '~/.gitconfig'.

I like colors in git:
[color]
ui = auto

I'm not going to list all the aliases, just this one which is very useful:
[alias]
l = log --oneline --decorate --graph

I find mergetool essential to resolve conflicts:
[merge]
tool = gvimdiff
[mergetool]
prompt = false

Everyone should have their own exclude file:
[core]
excludesfile = /home/felipec/.gitignore

This is mine:
.*.sw[nop]

Very useful if you use sendemail often, (for more information see this other post)
[sendemail]
aliasesfile = /home/felipec/.mutt/aliases
aliasfiletype = mutt
chainreplyto = false
confirm = auto
smtpserver = /usr/bin/msmtp
envelopesender = "auto"

And a few more:
[user]
name = Felipe Contreras
email = felipe.contreras@gmail.com
[push]
default = current
[receive]
denyCurrentBranch = warn

Look and feel

fonts

Since I have a laptop (with LCD):
gconftool-2 --set --type string /desktop/gnome/font_rendering/hinting full
gconftool-2 --set --type string /desktop/gnome/font_rendering/antialiasing rgba
gconftool-2 --set --type string /desktop/gnome/font_rendering/rgba_order rgb

Also, I like the Droid fonts, and Iconsolata.

I copy them to '~/fonts', and instead of of manually configure everything on the
system to use them, I create a '~/fonts.conf' file like this:

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
  <alias>
    <family>serif</family>
    <prefer>
      <family>Droid Serif</family>
    </prefer>
  </alias>
  <alias>
    <family>sans-serif</family>
    <prefer>
      <family>Droid Sans</family>
    </prefer>
  </alias>
  <alias>
    <family>monospace</family>
    <prefer>
      <family>Inconsolata</family>
    </prefer>
  </alias>
</fontconfig>

Then re-login.

mouse cursor

I like jimmac's DMZ cursor theme.

gconftool-2 --set --type string /desktop/gnome/peripherals/mouse/cursor_theme dmz

Re-login.

Fedora has it installed by default, but if not, you can just extract the tarball into '~/.icons'.

vim

I also wrote my own color scheme for vim, just copy to '.vim/colors', and then on '~/vimrc':
colorscheme felipec

felipec's vim color scheme

My custom color scheme

extra

Before I know it, I need Flash, which I install manually by downloading the tarball and extracting 'libflashplayer.so' into '~/.mozilla/plugins'. You don't need to restart your browser, but it can't hurt.

Then when I need to do some multimedia-related stuff I configure rpmfusion. Then add mplayer, which plays pretty much everything, or gnome-mplayer if you want a fancier UI.

After doing all this, and installing a few essential packages (such as vim-X11, gcc) I consider my system usable :)

For the rest of my configuration files, check in github.

msn-pecan 0.1 released; the best option for Pidgin/libpurple

After a bit more than two years of development we are proud to announce the first stable release of msn-pecan. The project started as a “fork” of libpurple’s msn protocol (read below why it’s not really a fork), but it has grown and soon will become a standalone library with support for Telepathy too.

Why?

I’ve been involved in Pidgin (formerly Gaim) since 2002, trying to improve it’s support for the MSN protocol which has been a very difficult task due to the reluctance of the Pidgin development team to take the issues seriously.

But don’t take my word for it, you can read an example of their excuses on John Bailey’s blog:

So yes, we have been “neglecting” Pidgin to a certain extent. Our time is a precious resource, and in many cases we simply have better things to do or simply don’t have the time to sit down and attack bugs to get them closed.

So yes, Pidgin neglects MSN, and yes, they need help; they themselves acknowledge that. IOW their MSN plugin is under-maintained.

The main reason for that is that the people who wrote the code have left the project. You can read all about it on this post; after several years of leaving the project my code still accounts for 42% of the code base.

The result of this bad maintenance is already visible in their bugzilla, but what is not visible is that many bugs are simply closed as invalid after two weeks of inactivity.

Despite all this, they rejected my help. And that’s how msn-pecan was born; I took my own code and carried development away from Pidgin. One way of looking at this is that Pidgin’s MSN has become the fork, and msn-pecan is the trunk ;)

Advantages

Bugs are actually fixed

The main advantage of having the original development team (or person) is that the whole code base is maintained, which means that no bug will fall through the cracks due to lack of expertise.

Besides, all bugs are carefully evaluated and unlike Pidgin; they are not closed automatically. The result is that most bugs are resolved as fixed, and even verified. Even if it takes months for the reporter to verify, some bugs are that important.

This means if you report a bug to msn-pecan; you have higher chances of getting it fixed.

Performance

Since msn-pecan’s code is better organized, every operation is under control, which means less resources are wasted; faster login times, faster response times, etc. This might not be important to many people but in some platforms, like Nokia N900, it’s essential to maximize battery life, and minimize network bandwidth (e.g. 3G network).

Features

The main feature of msn-pecan is that it will always login. Many people have reported not being able to login to Pidgin’s MSN and they are with msn-pecan. We ensure this by prioritizing login issues as critical, and fix them ASAP. Currently there are only two login problems open in our tracker, and they will definitely be solved by 0.2, or sooner.

A very important feature is fast file transfers with p2p connections, it has been by far the most requested feature, and therefore basic support has been introduced in 0.1. It will work on most situations, but not all, further development would be needed to support more scenarios.

Other features include: winks, plus! sounds, and plus! tags.

Again, unlike Pidgin, we try to prioritize features based on user feedback. This way we ensure that the features we implement are actually relevant to our users. That’s how we found out that people wanted offline messages, and handwritten messages, and the next one to implement is multiple login support. In many cases we implement the features before Pidgin.

Future

We want to support as many clients and platforms as possible, therefore in our plans are:

Also in the scope is videocall support, but that might take some time.

The release

So in these two years the objective has been to reorganize the code, and stabilize it as quick as possible while developing the most wanted features. I believe we have reached that objective, therefore 0.1 is a release that is ready for mass consumption. Please spread the word.

These are the stats:
204 files changed, 50254 insertions(+), 15940 deletions(-)

Special thanks should go to Devid Antonio Filoni who has taken a big amount of tasks: translations, Ubuntu PPA, Adium builds, Instantbird support and porting patches from Pidgin, not to mention the usual development. Thanks Devid! Also important have been the contributions from Elliott Sales de Andrade, although his work goes to Pidgin, Devid makes sure we get the juicy patches. Single patches are also highly appreciated, please keep them coming :)

     1  Albert Cervin
     3  Alexandre André
     6  Andrea Piccinelli
     1  Chris Stafford
     3  Christiano Farina Haesbaert
     1  David Geary
    89  Devid Antonio Filoni
     1  Edgardo Fredz
     2  Eion Robb
     2  Elias Julkunen
    10  Elliott Sales de Andrade
     2  Erik Fredriksen
     2  Evan Schoenberg
   866  Felipe Contreras
     1  Geoffrey Antos
     1  Gulars
     1  Jisakiel
     1  John Bailey
     1  Jovan Turanjanin
     1  Ka-Hing Cheung
     1  Keir Lawson
     2  Luís Neto
     2  Marco de Moulin
     2  Mike Ruprecht
     3  Octavio Alvarez
     1  Peter Skov
     1  Sergei Zivukov
     1  Simo Mattila
     1  Simone Contini
     1  Tao Wei
     3  Thiago Silva
     1  Thomas Gibson-Robinson
     3  Víctor Manuel Jáquez Leal
     1  Wei Hsiang Hung
     1  Ying-Shiuan Pan
     1  ZyroBlue
     1  drummingdemon

Since we want to reach an audience as wide as possible, please vote up on sw sites:

Grab it while it’s hot! (usual place)

msn-pecan 0.1.0-rc4 ready for testing; thanks valgrind!

The previous rc introduced a number of regressions, so I started running different tests with valgrind and found multiple problems. This release should fix all of those, plus a few other goodies.

Only one bug is pending, and most probably it’s already fixed. It certainly looks like 0.1 is imminent :)

Continue reading