Archive for the ‘Howto’ Category
git send-email tricks
I recently found out a few awesome tricks for git send-email that have made my life much easier, so I decided to share them here 
First, git send-email is an essential tool in every git guru’s arsenal, as it’s the preferred way of submitting patches. All you need to do is generate your patches with git format-patch (preferably with a cover letter), and then use git send-email to send those patches inlined in a nicely formatted email thread with your MTA.
But do you know about the different threading formats, address-book queries, or the cc-cmd option? No? Well, let’s get started.
Installing scratchbox 1 and 2 for ARM cross-compilation
Hi,
I’ve tried many different cross-compilation methods and so far scratchbox is the simplest and most effective. Here I’ll try to introduce the benefits of using it, and how to get started as simply as possible.
Intro
If you are not familiar with scratchbox; it’s a cross-compilation toolkit which allows you to use native tools (gcc, binutils, perl) when possible and emulate the target through qemu when needed.
It’s needed because of autotools; have you seen these checks?
checking whether the C compiler works... yes
The configure script actually compiles a small program and then runs it to validate it’s working, and sometimes extract information, such a the size of certain structures which might be different depending on the platform. If you tell ‘configure’ that you are cross-compiling it will go through a different path (which is much less tested) and ultimately will end up with wrong information that you need to correct.
OpenEmbedded and other distributions go through each and every package, make sure cross-compilation works, sometimes patching configure.ac, and often providing some information that normally would be obtained by running some test program.
This is an example of a typical GLib cross-compilation
./configure ---host=arm-linux --build=i386-linux
You’ll see something like:
checking whether the C compiler works... yes checking whether we are cross compiling... yes
And then:
checking for growing stack pointer... configure: error: in `glib-2.20.3': configure: error: cannot run test program while cross compiling
Of course, ‘configure’ has no way of knowing whether the stack grows on this particular platform. So you need to tell him yourself by creating an arm-linux.cache file like this:
glib_cv_stack_grows=no
And then running:
./configure --host=arm-linux --build=i386-linux --cache-file=arm-linux.cache
Of course that is not enough, you need to specify more:
glib_cv_stack_grows=no
glib_cv_uscore=no
ac_cv_func_posix_getgrgid_r=yes
ac_cv_func_posix_getpwuid_r=yes
And then the compilation fails because I don’t have glib-genmarshal in my system, and it’s needed by the build. Normally it’s compiled and run in the build, but now we can’t do that.
All these problems disappear with scratchbox.
Installing scratchbox 1
Many people think it’s difficult to install, but it’s not. Just follow these easy steps:
install
Download the basic packages:
wget -c http://scratchbox.org/download/files/sbox-releases/apophis/tarball/scratchbox-core-1.0.14-i386.tar.gz
wget -c http://scratchbox.org/download/files/sbox-releases/apophis/tarball/scratchbox-libs-1.0.14-i386.tar.gz
wget -c http://scratchbox.org/download/files/sbox-releases/apophis/tarball/scratchbox-devkit-qemu-0.10.0-0sb5-i386.tar.gz
wget -c http://scratchbox.org/download/files/sbox-releases/apophis/tarball/scratchbox-toolchain-cs2007q3-glibc2.5-arm7-1.0.12-9-i386.tar.gz
Extract them:
sudo tar -xf /tmp/sb/scratchbox-core-1.0.14-i386.tar.gz -C /opt
sudo tar -xf /tmp/sb/scratchbox-libs-1.0.14-i386.tar.gz -C /opt
sudo tar -xf /tmp/sb/scratchbox-devkit-qemu-0.10.0-0sb5-i386.tar.gz -C /opt
sudo tar -xf /tmp/sb/scratchbox-toolchain-cs2007q3-glibc2.5-arm7-1.0.12-9-i386.tar.gz -C /opt
Setup scratchbox, and add your user:
sudo /opt/scratchbox/run_me_first.sh
sudo /opt/scratchbox/sbin/sbox_adduser $USER yes
You'll need to re-login to be in the sbox group and have proper permissions:
sudo su $USER
target
Finally, setup an armv7 target (you can have multiple targets inside scratchbox):
/opt/scratchbox/tools/bin/sb-conf setup armv7 --force --compiler="cs2007q3-glibc2.5-arm7" --devkits="qemu" --cputransp="qemu-arm-sb"
/opt/scratchbox/tools/bin/sb-conf select armv7
/opt/scratchbox/tools/bin/sb-conf install armv7 --clibrary --devkits --fakeroot --etc
That's it, you have scratchbox setup 
I explicitly mentioned all the commands, but instead you can run this script that I wrote.
start
Before running scratchbox you'll need to do some steps as root:
echo 0 > /proc/sys/vm/vdso_enabled
echo 4096 > /proc/sys/vm/mmap_min_addr
/opt/scratchbox/sbin/sbox_ctl start
And then as user:
/opt/scratchbox/login
This will get you to this screen:
Welcome to Scratchbox, the cross-compilation toolkit! Use 'sb-menu' to change your compilation target. See /scratchbox/doc/ for documentation. [sbox-armv7: ~] >
Now if you want to cross-compile GLib, you do it as in your PC:
./configure && make install
Much easier, now scratchbox does all the magic
Scratchbox 2
Scratchbox 1 serves it's purpose, but there are many corner-cases where things get overly complicated so people came up with a much more elegant approach: Scratchbox 2.
In sb1 you need to login to a target (e.g. armv7, armv6, fremantle, diablo, etc.) in order to do anything, you can use only one target at a time, and each target is independent, in order to share tools between targets you need a devkit. Also, toolchains must be packaged in a special way.
In sb2, you don't login, you can setup any toolchain easily, you can use multiple targets at the same time, and you can configure it to do pretty much anything you want.
QEMU
sb2 doesn't include QEMU, you must have it already, this is how I compile it:
git clone git://git.savannah.nongnu.org/qemu.git
cd qemu
git checkout -b stable v0.10.5
./configure --prefix=/opt/qemu --target-list=arm-linux-user
make install
sbox2
Compile and install like this:
git clone git://anongit.freedesktop.org/git/sbox2
cd sbox2
./configure --prefix=/opt/sb2
make install
Add sb2 to the PATH:
export PATH=/opt/sb2/bin:$PATH
target
Now it's time to configure a target, I have a CodeSourcery toolchain installed on /opt/arm-2008q3, so:
cd /opt/arm-2008q3/arm-none-linux-gnueabi/libc/
sb2-init -c /opt/qemu/bin/qemu-arm armv7 /opt/arm-2008q3/bin/arm-none-linux-gnueabi-gcc
You don't need to log-in, just prefix your commands with sb2 to do the magic:
sb2 ./configure --prefix=/opt/arm/
If you want to use a different target just use the -t option:
sb2 -t armv8 ./configure --prefix=/opt/arm/
How cool is that?
Transcoding for the Internet Tablets the smart way
A while ago I wrote the “official” video transcoding for Maemo how-to based on the wiki page and some heuristics.
The interesting thing here is the intelligent script that automatically finds the right parameters to use for the encoding.
Some of the considerations include:
- As higher framerate as possible. For smooth videos.
- Keep aspect-ratio. So the videos don’t look weird.
- No cropping. You might miss something.
- Single pass. Bigger files, but constant CPU usage.
Is this thing really smart? Let’s try it.
Crappy clip from YouTube
transcode.rb -v -i youtube.flv
* Input: 320x240 [4:3], 29.917 fps, 0 kbps.
* Output: 320x240 [4:3], 29.917 fps, 400 kbps.
mencoder youtube.flv -o youtube_it.avi -srate 44100 -oac mp3lame -lameopts vbr=0:br=128 -af volnorm -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=400 -ofps 29.917000
Nothing special, the script maintained all the parameters, so there shouldn’t be any problems. Also, the aspect-ratio is not so different from the one of the device. This one is OK.
DVD
transcode.rb -v -i dvd://1
* Input: 720x480 [3:2], 29.97 fps, 7500000 kbps.
* Output: 400x240 [5:3], 29.97 fps, 400 kbps.
mencoder dvd://1 -o 1_it.avi -srate 44100 -oac mp3lame -lameopts vbr=0:br=128 -af volnorm -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=400 -ofps 29.970000 -vf-add scale=400:240
In this case the aspect-ratio is slightly modified (less than 10%), but the target aspect-ratio is exactly the same as the one of the device, so, it will look good.
So far the script does seem intelligent
High Definition
Now let’s try a non-standard resolution, high bitrate, and H.264 format.
transcode.rb -v -i starcraft.divx -f h264 -q 8
* Input: 1024x436 [256:109], 23.99 fps, 1917920 kbps.
* Output: 352x144 [22:9], 23.99 fps, 1500 kbps.
mencoder starcraft.divx -o starcraft_it.avi -srate 44100 -oac mp3lame -lameopts vbr=0:br=128 -af volnorm -ovc x264 -x264encopts bitrate=1500:nocabac -ofps 23.990000 -vf-add scale=352:144
The aspect ratio now is about 4% different, that’s good. Unfortunately the aspect-ratio is quite different from the one of the device, but that’s not too bad.
This is how it would look like:
note H.264 videos look pretty good on the device.
Conclusion
So far there hasn’t been a single video where I had to modify the parameters that this algorithm suggested; sometimes the quality is not that good but increasing it with the -q option does the trick.
Wondering if it would find the right parameter for your clips? Why don’t you try it and find out
GStreamer hello world
Continuing my previous GStreamer introduction this new tutorial will guide you on your first GStreamer application written in C.
For anxious people the code is here.
The whole thing is here.
It’s in bluwiki so if you want to modify it, feel free to do so
I feel a little bit ashamed of posting such simple things, but there doesn’t seem to be anything for the really newbies.
GStreamer hands-on introduction
I’ve never seen a GStreamer tutorial that explains all the very basic stuff in order to get you started with GStreamer, so I decided to create one very quickly.
Linux on board: Developing for the Nokia N800
Peter Seebach from Wind River has written an interesting article in IBM’s developerWorks explaining how to get started with the Maemo SDK in a very simple and straightforward way.
From the products’ introduction to well picked references, going through scratchbox, R&D mode and techspecs; this is probably the most hands-on introduction I’ve seen, and yet more is to come.
Fedora 8 network install from USB
This is basically a copy-paste from a similar post for Fedora 7.
wget ftp://download.fedora.redhat.com/pub/fedora/linux/releases/8/Fedora/i386/os/images/diskboot.img
sudo dd if=diskboot.img of=/dev/sdX
WARNING: be really careful to choose the right device or you might screw other partitions.
Also unmount it before doing the operation. If you want to check the contents just unplug and plug your memory stick.
When you reboot you’ll be able to choose the network installation. You’ll want to choose the HTTP method as FTP doesn’t seem to work and since you are required to type the URL of the server it’s better to write it down before rebooting.
For a list of mirrors check here (not working right now). An example URL would be:
http://spreader.yandex.net/fedora/linux/releases/8/Fedora/i386/os/
Here is the bug report. Please provide feedback if you can.
Thanks to this post.
NFS in Fedora 7 (and iptables)
Before I forget how to do it:
Use “lsof -i” to find out the ports you need to open. Look for rpcbind and rpc.mount.
rpcbind 2110 rpc 8u IPv6 7514 TCP *:sunrpc (LISTEN)
rpc.mount 2479 root 7u IPv4 8622 TCP *:59287 (LISTEN)
Now add them to iptables:
iptables -I INPUT -m state --state NEW -m tcp -p tcp --dport sunrpc -j ACCEPT
iptables -I INPUT -m state --state NEW -m tcp -p tcp --dport 59287 -j ACCEPT
I guess you can edit “/etc/sysconfig/nfs” and set MOUNTD_PORT to some value so you don’t have to check it.
That’s all I had to do, but for more information check here.
