Dear Javier,
thanks for continuing in giving me attention about this problem.

I made some tests and I succesfully made cdo work in the following versions:

cdo 1.5.6.1 (source package from the developers' site; https://code.zmaw.de/attachments/download/3605/cdo-1.5.6.1.tar.gz)
cdo 1.5.4 (since this is no more available on the developers' site, I downloaded it from http://archive.ubuntu.com/ubuntu/pool/universe/c/cdo/cdo_1.5.4+dfsg.1.orig.tar.gz ; I hope this is is conformal to the developers' original one).

I made it work on Ubuntu Quantal, it seems reasonable to me that these conclusion should hold also for other Ubuntu releases (but I'm not an IT scientist, and I won't dare state this sentence too loud! :) ).

I run cdo succesfully both on grib1 and grib2 data, getting the correct results with both versions of cdo.

I compiled the two above packages with the following compilation commands:

export CC=mpicc
configure --prefix=${HOME}/src/cdo-1.5.6.1 --with-grib-api=yes --with-netcdf=yes --with-hdf5=yes
make
make install

Of course, a different prefix value for version 1.5.4, so I did not override the resulting executable. I made the above choice of the configure options in order to stick as closer as possible to the cdo compiled for the Ubuntu Quantal repositories, but ensuring that the resulting executable was working. Of course, in order to compile cdo with those options, the following packages are needed in the compiling environment:

libhdf5-openmpi-dev
libnetcdf-dev

Actually, I do not remember why I have the MPI parallelised version of the libhdf5 package installed on my system, maybe for compatibility with some other software (maybe the same cdo). However, it peacefully coexhists with the Ubuntu repositories version of cdo, while the serial one does not.

I'm attaching to this report a sample grib 2 file, with analysis and forecasts of 2 metre temperature packaged in the same file. Unfortunately, the area of the data I had available for this report is not the same (Europe for the grib 2 data, versus the South African framework I used to rise the problem for grib 1), so the spatial cutting command must be different in the two cases.

For both versions of the cdo compiled software, I run (I am reporting only the test of version 1.5.6.1 for brevity, but I performed the same operations also for version 1.5.4, getting the same results):

${HOME}/src/cdo-1.5.6.1/bin/cdo sellonlatbox,10,15,50,40 t2m.grib2 tagliato_t2m.grib2
${HOME}/src/cdo-1.5.6.1/bin/cdo sellonlatbox,23,31,-25,-31 t2m_ei_1979.grb tagliato_t2m_ei_1979.grb
wgrib2 -v tagliato_t2m.grib2   # See further notes
wgrib -v tagliato_t2m_ei_1979.grb | head -n 8

Till this moment, I only posted the commands rather than their output. It is important to note that for grib 2 data files the wgrib utility mentioned in my previous post is not helpful anymore. Rather, there is a specific utility for grib 2 data that is the wgrib2.

The wgrib2 is downloadable from
http://www.cpc.ncep.noaa.gov/products/wesley/wgrib2/
and, more specifically, in that quite messy page, from
http://www.ftp.cpc.ncep.noaa.gov/wd51we/wgrib2/wgrib2.tgz.v1.9.7
In order to use the wgrib2 it must be compiled. Unpack the archive, change directory to "grib2" then edit the makefile as the following:
from lines 89 on, my makefile reads as

# often enviroment variable FC=fortran compiler, is set to f77, need f90 compiler
FC=gfortran
CC=gcc

(I uncommented the declaration of the FC and CC compilers variables)

then it is necessary to execute make twice (the first one gives a compilation error; the second time, everything works fine and the executable is created, and it works)

make
make

The executable of wgrib2 is named wgrib2 and it is in the directory wgrib2 (considering the directory "grib2" where there is the makefile as a reference point).

The usage of wgrib2, for the present purpose, is the same as wgrib. The grib2 file I posted as an example has less than 8 time records, so it is not necessary to select only a few lines of output piping it into the head command used in the other case. A difference between the wgrib and the wgrib2 utilities is the format of the on screen output

wgrib2 -v tagliato_t2m.grib2
results, correctly, in

1:0:d=2010113000:TMP:2 m above ground:anl:
2:292:d=2010113000:TMP:2 m above ground:6 hour fcst:
3:584:d=2010113000:TMP:2 m above ground:12 hour fcst:
4:876:d=2010113000:TMP:2 m above ground:18 hour fcst:
5:1168:d=2010113000:TMP:2 m above ground:24 hour fcst:
6:1460:d=2010113000:TMP:2 m above ground:30 hour fcst:
7:1752:d=2010113000:TMP:2 m above ground:36 hour fcst:

#########################################

wgrib -v tagliato_t2m_ei_1979.grb | head -n 8
results, correctly, in:

1:0:D=1979010100:2T:sfc:kpds=167,1,0:3hr fcst:winds are N/S:"2 metre temperature [K]
2:1736:D=1979010100:2T:sfc:kpds=167,1,0:6hr fcst:winds are N/S:"2 metre temperature [K]
3:3472:D=1979010100:2T:sfc:kpds=167,1,0:9hr fcst:winds are N/S:"2 metre temperature [K]
4:5208:D=1979010100:2T:sfc:kpds=167,1,0:12hr fcst:winds are N/S:"2 metre temperature [K]
5:6944:D=1979010112:2T:sfc:kpds=167,1,0:3hr fcst:winds are N/S:"2 metre temperature [K]
6:8680:D=1979010112:2T:sfc:kpds=167,1,0:6hr fcst:winds are N/S:"2 metre temperature [K]
7:10416:D=1979010112:2T:sfc:kpds=167,1,0:9hr fcst:winds are N/S:"2 metre temperature [K]
8:12152:D=1979010112:2T:sfc:kpds=167,1,0:12hr fcst:winds are N/S:"2 metre temperature [K]

This demonstrates that the compilation I posted at the beginning of this comment produces on Ubuntu Quantal for the two versions of cdo under examination two good executables, that they actually do well what they are supposed to do.

There is in fact one difference between the cdo available in the Ubuntu repositories and the ones I tested to write this post. The command
cdo -V
gives some information about the cdo executable creation. For the official Ubuntu repositories the output of this command is:

Climate Data Operators version 1.5.4 (http://code.zmaw.de/projects/cdo)
Compiler: mpicc -std=gnu99 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -fPIC
version: gcc: error: unrecognized command line option '-V'
with: PTHREADS Z JASPER PROJ.4
Compiled: by buildd on roseapple (i686-pc-linux-gnu) Sep  8 2012 18:02:35
CDI library version : 1.5.4 of Sep  8 2012 18:02:29
GRIB_API library version : 1.9.16
netCDF library version : 4.1.3 of May  1 2012 04:15:00 $
HDF5 library version : 1.8.8
SERVICE library version : 1.3.0 of Sep  8 2012 18:02:13
EXTRA library version : 1.3.0 of Sep  8 2012 18:02:08
IEG library version : 1.3.0 of Sep  8 2012 18:02:12
FILE library version : 1.7.1 of Sep  8 2012 18:02:08

while for the one I compiled it is

Climate Data Operators version 1.5.4 (http://code.zmaw.de/projects/cdo)
Compiler: mpicc -std=gnu99 -g -O2
version: gcc: error: unrecognized command line option '-V'
with: PTHREADS NC4 Z
Compiled: by myself on pcubuntu (i686-pc-linux-gnu) Nov 14 2012 12:17:31
CDI library version : 1.5.4 of Nov 14 2012 12:17:19
CGRIBEX library version : 1.5.1 of Aug 29 2011 20:30:27
GRIB_API library version : 1.9.16
netCDF library version : 4.1.3 of May  1 2012 04:15:00 $
HDF5 library version : 1.8.8
SERVICE library version : 1.3.0 of Nov 14 2012 12:16:49
EXTRA library version : 1.3.0 of Nov 14 2012 12:16:41
IEG library version : 1.3.0 of Nov 14 2012 12:16:47
FILE library version : 1.7.1 of Nov 14 2012 12:16:42

The only significative difference is the presence, in my configuration, of the CGRIBEX library, that is the one dealing with grib 1 data files. Now I cannot understand why, for my case, the --enable-cgribex option was not necessary to make things go well, while in your case it was necessary to specify it explicitely at configuration time.

At the moment I did not have the possibility to test the packages on your ppa; I prefer to do that on a virtual machine before harming my system. However, I will do that as soon as possible, with both grib1 data files, grib2 data files and maybe also netCDF files. At the moment I found that the procedure I outlined in this and in the previous post produces something working at least on my system.

I will let you know of my forthcoming double check on your ppa. However, if you have any further questions or comments, let me know.

Best regards
Marco