Skip to main content
  1. Planet
  2. Global
  3. Page 1032

a silhouette of a person's head and shoulders, used as a default avatar
a silhouette of a person's head and shoulders, used as a default avatar

small Qt based mail biff

Some days ago I was asked what this little button bar on my desktop is and I explained that it’s only a small program I wrote to keep track on my mail folders. I know there are many many programs out there which already does the same but for some reason he liked it and encouraged me to blog about it 🙂

qbiff runs as a server client application and is able to manage mails stored in the maildir format. The server should run on the machine which locally stores the data and the client or multiple of them can run on the desktop you have an eye on. The connection(s) between the server and the client(s) are SSL connections, even though there is no mailcontent which is transfered the information how many mails, how many new ones and what mail folders exists might be an information not everybody needs to know about… so I chose a secure connection 😉

If the file .qbiffrc exists the user can control which mail folders should be checked, if the file doesn’t exist all folders the server finds at start up will be used. Each folder is represented by a button. Whenever a new mail arrives the button changes its color and notifies the user with a tip window about the current mail situation of this folder. A click on the button runs a user defined program whereas the first parameter is the path and name of the folder. In my setup I call mutt respectively to read the mail in the folder

So it looks basically like this…

Packages can be found in my home Project at:

  • http://download.opensuse.org/repositories/home:/sax2
  1. Install the package qbiffd on your server
  2. Install the package qbiff on your client, server and client could be the same machine
  3. Edit the file /etc/sysconfig/qbiff on the server and setup at least the  QBIFF_USER which should be the same user the mails belong to and the QBIFF_FOLDER which is the base directory of your mails
  4. Run the server by calling rcqbiffd start
  5. Run the client by calling qbiff-client. The default password for the SSL certificates is “linux“
  6. click on a folder button and read the note about how to setup a personal mail reader script

If you want to create your own certificates you need to check out the code at

  • svn co https://svn.berlios.de/svnroot/repos/qbiff/qbiff-head .

and run the following commands:

  1. cd cert-server && make distclean && make
  2. cd ../cert-client && make distclean && make
  3. cd ..
  4. ./.certinstall on the server and the client

the avatar of Andrés G. Aragoneses
the avatar of Andrés G. Aragoneses

Hackweeks

I'm going to give a brief summary of what I've done in the past weeks (and specially previous week (last one in August), sponsored by Novell as The Hackweek - a form of ITO, in which you can hack at working hours and not only spare time!

I was not so lucky as most of my teammates, who spent the week on the wonderful offices (as they say) of Novell Utah. Maybe if I was in the states already... but well, I had recently an interview in the US Embassy which was the last step of my visa process, so I hope that at least I can make it for the Gnome Boston Summit!

So, firstly I thought of dedicating my week to this task that I submitted to the ideas website, but in the end realized it would be a ton of work to complete without help, and nobody joined me so I decided to learn to use OpenSuseBuildService in order to package Bugzilla, a pretty complex server side software.

Fortunately, I've learnt a lot this week, especially thanks to all the people in irc://irc.freenode.net/#openSUSE-buildservice (above all, darix) and some people from my team (Ray Wang and Stephen Shaw). I could also contact the author of the RPM file for Fedora (who was formerly working for Red Hat), and he's willing to help on joining efforts, as OBS is cross-distribution.

Unfortunately, packaging is a complex task and I didn't finish the package. The documentation is a bit incomplete and having past experience in packaging is a plus that I didn't have. It's awesome that inside our UIA Team we have exclusive resources dedicate to this, because it would be impossible to do from just the developer side.

One of the difficulties I found is finding packages I needed. I could find some of them (BTW, using Webpin is cool for searching on SUSE software repositories, including Packman; except for the fact that doesn't enhance one-click-install) but not all so then I'll have to help on providing packages for some CPAN Perl modules, contributing to the devel:languages:perl official repo.

On the way of learning OBS, I also filed bugs and feature requests (not only to OBS, but also to Banshee! as I have been using it a lot lately at the same time I hack and I even cooked some small patches):

OBS:
Usability issues in project creation page
Link to "My projects" fails if no home:login project has been created yet
New option for uploading the tarball
ChangeLogs parsing is too strict: lines beginning with tab are not recognized, only one date format is accepted
OBS should not allow to create a package named "packageand"
The spec parser should detect the use of a miscplaced packageand(_:_) keyword

Banshee:
No such file or directory errors while importing
Cannot empty some ID3 tag fields
Importing songs without album metadata breaks artist navigation on the iPod
Banshee inserts deduced fictional text on metadata
Should try to locate correct album (and download its cover) in case no album is supplied on metadata


The patches are quite simple so I hope they get committed soon! Clearly Banshee devs and contributors are doing an amazing work, I'm specially amazed by the Moonlight effects, the Muinshee front-end and the effort that it seems is being dedicated to bring Library Sync & Refresh for 1.4. I wish them all the best success.

So let's get back to packaging. Firstly I thought I had found some limitations in OBS or rpm systems because the lack of proper "dual dependency" support. In the past when I installed Bugzilla manually (and updated it to newer versions) I found it a bit hard to do it, specially to deal with DB creation and upgrade. I wanted to make this process easier for the potential rpm user, but without limiting the choice of the DB engine used (as now Bugzilla supports MySQL, PostgreSQL, and Oracle, although the latter was not on my scope). It turns out that it's really hard to apply virtual-provides rules for these cases, as we should stablish more sub-dependencies depending on the db engine you choose, such as perl-DBD-mysql or perl-DBD-Pg, and because it would cause inconsistent situations in case someone in the future replaces his DB-engine with the alternative one (as in theory it should work at the dependencies-level without warning). For references, you may be interested in reading the whole thread about it in the BuildService mailing-list, whose last message includes a possible hack to workaround these problems using patterns (although I don't like to use patterns for solving something like this).

Even discarding the dream about solving this at a package level, it's difficult to solve it at an app level that wouldn't involve reading manuals. My idea was to modify Bugzilla upstream in order to avoid running manually a local script for its initialization, and replace it with a nice web front-end (even if it's only allowed to be run locally). That would cause problems because normally the webserver user doesn't have enough permissions to create files and the database tables and initial data (I'm sure there's always a solution that also doesn't expose security problems, but it's hard to find it as it's noticed in this thread in bugzilla devel newsgroup; so, help is truly welcome).

Maybe the easier and fastest solution is a mixture of both worlds, that is, having a web front-end that asks you the initial configuration, and the form submission process just writes it in a local XML and tells the admin to open a console and run a script as root to finish the process. But even with this solution I guess we should need something to detect at runtime (which should be cross distribution) if some package is installed (which also checks the version). I guess there's already some of that capabilities used in the bugzilla's script checksetup.pl, so I would reuse them. However, in case it finds a problem, there's no way for the application to request installation of a package directly to your OS (but I've attended to a PackageKit conference in last Guadec in which I heard something about this possibility in the future!).
a silhouette of a person's head and shoulders, used as a default avatar

a silhouette of a person's head and shoulders, used as a default avatar
a silhouette of a person's head and shoulders, used as a default avatar

Planning a short stay in Boston

Since my girlfriend wants to learn English and I'll probably have to attend a meeting in Boston, we decided to put it all together and we are planning to stay a couple of months in Boston, from end October to end December. After 5 years working alone at home, it will be refreshing to work in an office together with non-virtual coworkers. It also comes at a good timing because we are planning to release MonoDevelop 2.0 around the end of the year.

This is going to be an interesting end of year.

BTW, I'm currently looking for a small apartment (or big room) to rent, ideally around Cambridge. Unfortunately I'm not having much success, since apartments I found are either too expensive, or not available for those two months. So if you know about some good place, information will he highly appreciated! (mail lluis at novell dot com).

a silhouette of a person's head and shoulders, used as a default avatar
a silhouette of a person's head and shoulders, used as a default avatar

Google Chrome on openSUSE

As I guess everyone notice, Google has released their own Browser called Chrome. Based on Webkit (based on KHTML of KDE fame) it is a small, fast and foremost secure webbrowser. And if you are reading this, you likely know that it does not work on Linux, but only on Windows.

But wait … we have the Windows Emulator Wine and I am one of its developers…

This also explains the first comment from a colleague on Wednesday morning was: “Why don’t you have fixed Wine to run it yet?!?” We tried together to get the online installer to run, but not successful.

Over night however some other folks found out how to do it by using the offline installer.

So how to install Chrome:

1. Get the Wine 1.1.3 from the openSUSE buildservice Emulators:Wine repository.

Its available via the Community Repositories Module in YAST2 on openSUSE 10.3 and 11.0,
after adding this repository upgrade the wine package.

This piece of code run as root will do it on openSUSE 11.0:
zypper sa http://download.opensuse.org/repositories/Emulators:/Wine/openSUSE_11.0/ Wine
zypper in wine

All other steps are done as desktop user from a regular shell.

2. Download the Chrome Offline Installer

wget http://gpdl.google.com/chrome/install/149.27/chrome_installer.exe

3. Install richedit native libraries.

While Wine contains richedit libraries they are not yet up to the task to help Chrome yet.
(This is likely to be fixed soon.)

To install them run:
winetricks riched20 riched30

3. Run Chrome Installer

wine chrome_installer.exe

This will popup a dialog where you can press return until Chrome itself starts.

Since we need to supply Chrome with some Options to make it work with current Wine, you need
to close it again. Click anyway any crash messageboxes.

4. Run Chrome itself

We need to supply Chrome with some additional commandline options to make it run with Wine,
so we need to do start it by hand (instead of clicking on the convenient Desktop Icon already there).

cd ~/.wine/drive_c/windows/profiles/*/*/*/Google/Chrome/Application
wine chrome.exe --new-http --in-process-plugins

5. Surf!

And of course the obligatory screenshot:chrome wine opensuse

Most of the funny workarounds above will actually vanish in the next Wine releases, now that the Wine developers can actively debug it.

The WineHQ Application database entry has the ongoing discussion of getting it to work and links to the Wine bugzilla entries.

a silhouette of a person's head and shoulders, used as a default avatar
a silhouette of a person's head and shoulders, used as a default avatar

Convenient setters in C++?

Libzypp's RepoInfo class was originaly written with property setters returning a RepoInfo & reference to the modified object. This pattern is common in higher OO languages like Java and is convenient as it saves typing when setting serveral properties at once (i'm not sure how it is performance-wise).


RepoInfo repo;

// you write
repo
  .setAlias("foo")
  .setName("Foo Project Repository")
  .setEnabled(true).setAutorefresh(false);

// instead of
repo.setAlias("foo");
repo.setName("Foo Project Repository");
repo.setEnabled(true);
repo.setAutorefresh(false);


Unless the class is part of a class hierarchy, everything's OK. But after splitting RepoInfo to RepoInfoBase and a derived RepoInfo the dark side of C++ has shown up.


RepoInfo repo;
repo
  .setAlias("foo")   // RepoInfoBase setter
  .setEnabled(true)  // RepoInfoBase setter
  .setPriority(50);  // RepoInfo setter - this won't compile becase setEnabled() returned
                     // a RepoInfoBase &, and C++ does not bother with figuring out that the
                     // object is also a RepoInfo.


In order to make this work in this setup, you have to redefine each setter from the base class in the derived class and make it return the reference to the derived class:


class RepoInfoBase
{
  RepoInfoBase & setAlias( ... ) { _pimpl->alias = ...; return *this; }
}

class RepoInfo : public RepoInfoBase
{
  RepoInfo & setAlias( ... ) 
  { RepoInfoBase::setAlias(...); return *this; }
}


but by doing this the RepoInfo class looses some of the advantages of being derived from RepoInfoBase.

So, is it best to stick with setters returning void, or is there a better way to do this?

a silhouette of a person's head and shoulders, used as a default avatar
a silhouette of a person's head and shoulders, used as a default avatar

Funny Output For Some

Last week (aka Hackweek 3) I worked on a Linux From Scratch system.

A colleague dropped by and asked me what kind of power supply were sufficient for a certain machine. I thought “ok, let’s just ask lshal|grep battery
My hope was that the hardware would not only measure the voltage of the battery but also the current drained from it.

What I found was kinda funny from an Electrical Engineer’s point of view:

lshal output for laptop battery

So what? “voltage.current”? Voltage? Or current? Or multiplied?

After laughing a bit I thought seriously about bug report, but it isn’t a bug apparently.
I find those things funny, can’t help it. I therefore consider this an Easter Egg of HAL.

Still, if anyone knows if a laptop can tell me the current current (SCNR), let me know.

Cheers,
Jan

a silhouette of a person's head and shoulders, used as a default avatar
a silhouette of a person's head and shoulders, used as a default avatar

Unifying Progress During Installation – Continued…

So, my code from the hackweek is now in the YaST Subversion and the packages submitted for build.

Now the fun part begins, as some YaST developers noticed very quickly. There are several parts of YaST that got broken – e.g. YaST Partitioner on the running system spotted by Arvin, or sw_single not really adapted spotted by Bubli, …

Thanks to those I’m working with Kobliha to fix the issues as they come. So, if there is a progress in YaST (typically related to package installation) that does not behave as expected, it is certainly worth a bug report.

a silhouette of a person's head and shoulders, used as a default avatar
a silhouette of a person's head and shoulders, used as a default avatar

Quick configuration for Munin

From project website:

"Munin the monitoring tool surveys all your computers and remembers what it saw. It presents all the information in graphs through a web interface. Its emphasis is on plug and play capabilities. After completing a installation a high number of monitoring plugins will be playing with no more effort.

Using Munin you can easily monitor the performance of your computers, networks, SANs, applications, weather measurements and whatever comes to mind. It makes it easy to determine "what's different today" when a performance problem crops up. It makes it easy to see how you're doing capacity-wise on any resources."

The configuration file is:

/etc/munin/munin.conf

The minimal configuration file for server:

# Configfile for Munin master
dbdir       /var/lib/munin/
htmldir     /var/www/munin/
logdir      /var/log/munin
rundir      /var/run/munin/

[mynode.mydomain.com]
address 192.168.1.105

In the configuration file for server I specified only one single node: mynode.mydomain.com

Next step is to configure the node but the default configuration is fine, only  let the server to acces Munin port 4949:

allow ^192\.168\.1\.1$

where 192.168.1.1 is the ip number for server.

The final step si to check their website to read the documentation/faq for more configuration options.

That's all

a silhouette of a person's head and shoulders, used as a default avatar
a silhouette of a person's head and shoulders, used as a default avatar

Hackweek Day 3: cross-build with OBS Part 2

This is the second part of my article series about the Hackweek Project “cross-build in the OBS”. The first part can be found here.

Before I come back to our Hackweek project, some information about the qemu emulator. As a preparation to Hackweek, I talked with Uli Hecht and Jan Kiszka. Uli Hecht is the Novell/SUSE Maintainer of the qemu packages in openSUSE:Factory/qemu and maintainer of the OBS project Emulators, where every emulator you can imagine is maintained for a couple of linux distributions. Also I consulted Jan Kiszka, one of the reviewers and maintainers of the qemu upstream project about the status of the qemu in general, “User Mode” and status of important architectures specifily.

We also discussed in our OBS meeting at Hackweek on thursday what performance requirements cross-build has to fullfil in order to get the normal openSUSE:Factory beeing built with cross-build for architectures like arm, sh4 and others used in embedded space. The consensus was that the qemu architectures to start with in the cross-build project are qemu-kvm, including x86 support, and Arm and PowerPC, specifically in the “User Mode”. Ludwig Nussel had already implemented some weeks ago the possibility to use qemu-kvm and uml in addition to Xen inside the OBS workers/local build, and unified the code for the three emulators. The code for all the mentioned features except cross-build itself is already inside the OBS subversion repository in the trunk.

Results of the discussions were:

  • qemu needed further fixing at all, even compared to the very new version in Emulators/qemu, to run OBS cross-build
  • qemu system emulation was considered too slow, specifically when bootstrapping openSUSE:Factory
  • qemu KVM will get a spin later, as a Xen replacement. It is prepared inside OBS workers/osc build
  • qemu PowerPC is generally in bad shape, specifically the “User Mode”, so openSUSE:11.0/ppc cannot run. Inside the gcc/glibc uses the features futexes, pthreads with NTPL and compiler support for TLS, which are not yet implemented
  • qemu Arm, specifically “User Mode”, is in the best possible shape, so Debian:Etch/Arm can run. It does not yet use futexes, pthreads with NTPL and compiler support for TLS, specifically on Arm

    • So much for the theory. Now, I show you how to run build jobs for Debian:Etch/Arm, using normal unmodified Debian type packages. I have prepared for you inside build.opensuse.org/openSUSE:Tools:Unstable and openSUSE:Tools:Devel the required packages for installation. To keep modifications small, and to make sure cross-build can be used also with the official OBS on build.opensuse.org, we decided to first implement cross-build for use with “osc build” local build.

    If you are running a local OBS, you should already be familiar with the installation instructions for it, and I assume you had already successfully installed a local OBS in the past, and also migrated from version to version.

    Update your local OBS for cross-build

    This can be skipped, should Adrian provide Debian:Etch packages for Arm in the official OBS. You need to be root to install the packages. I assume you have ca. 55 GB harddisk space free, and you need to download ca. 36 GB via the internet. The example is for a openSUSE 11.0 machine with an x86_64 processor.

    # mkdir -p /tmp/obs-packages && cd /tmp/obs-packages
# wget -q -c http://download.opensuse.org/repositories/openSUSE:/Tools:/Unstable/openSUSE_11.0/x86_64/obs-api-1.1.0.4791M-2.1.x86_64.rpm
# wget -q -c http://download.opensuse.org/repositories/openSUSE:/Tools:/Unstable/openSUSE_11.0/x86_64/obs-server-1.1.0.4791M-2.1.x86_64.rpm
# wget -q -c http://download.opensuse.org/repositories/openSUSE:/Tools:/Unstable/openSUSE_11.0/x86_64/obs-worker-1.1.0.4791M-2.1.x86_64.rpm

    Now, first save your old /etc/sysconfig/obs-server

    # mv /etc/sysconfig/obs-server /etc/sysconfig/obs-server.old

    Then install the new OBS Packages:

    # rpm -Uhv {obs-api,obs-server,obs-worker}*4791M*.rpm

    Now, edit the new /etc/sysconfig/obs-server file, and comment in the line with arm inside. You have some possibilities. Normally, you would also run the OBS scheduler for x86_64 and i586, so you choose the line with armv4l inside in addition:

    ## Path:        Applications/OBS
## Description: define for which architectures the packages should get build
## Type:        stringlist
## Default:     "i586"
## Config:      OBS
#
# This needs to be a space seperated list of all supported architectures
OBS_SCHEDULER_ARCHITECTURES="i586 x86_64 armv4l"

    Now your OBS is ready to be started again. Start everything except the scheduler.

    Now depending on you local OBS setup, you either modify or add a new project with the name Debian:Etch. Once done, add an updated architecture record to it, with the new architecture armv4l added:

    # osc -A api.opensuse.org meta prj Debian:Etch >de.xml

    Now edit file “de.xml” with you favorite editor of you choice and add change the architecture block:

    ...
  <repository name="standard">
    <arch>i586</arch>
    <arch>x86_64</arch>
    <arch>armv4l</arch>
  </repository>
...

    Now save the changed file in your local OBS.

    Next copy the meta prjconf from the api.opensuse.org to you local OBS:

    # osc -A api.opensuse.org meta prjconf Debian:Etch >de.conf
# osc -A <your local ip> meta prjconf -F de.conf Debian:Etch

    To complete the installation, you now finally install the x86_64, i586 as a copy from the official OBS (downloads ca. 22 GB and takes a while):

    # obs_mirror_project Debian:Etch standard i586
# obs_mirror_project Debian:Etch standard x86_64

    After this, the appropriate directories “/srv/obs/build/Debian:Etch/standard/i586/:full” and “/srv/obs/build/Debian:Etch/standard/x86_64/:full” should have been created and filled with lots of .deb files.

    Then you also need the Debian:Etch binaries for Arm, found on 3 full DVDs. Download them (another ca. 13 GB):

    # wget -c -q ftp://ftp.tu-chemnitz.de/pub/linux/debian/debian-cd/4.0_r4a/arm/iso-dvd/MD5SUMS
# wget -c -q ftp://ftp.tu-chemnitz.de/pub/linux/debian/debian-cd/4.0_r4a/arm/iso-dvd/debian-40r4a-arm-DVD-1.iso
# wget -c -q ftp://ftp.tu-chemnitz.de/pub/linux/debian/debian-cd/4.0_r4a/arm/iso-dvd/debian-40r4a-arm-DVD-2.iso
# wget -c -q ftp://ftp.tu-chemnitz.de/pub/linux/debian/debian-cd/4.0_r4a/arm/iso-dvd/debian-40r4a-arm-DVD-3.iso

    Then check that the MD5SUMS so the downloads were all ok. Mount the images with:

    # mkdir ./mnt
# mount -o,ro -t iso9660 ./debian-40r4a-arm-DVD-1.iso ./mnt -o loop=/dev/loop3

    Then copy all files with name “*.deb” inside all the 3 DVDs to “/srv/obs/build/Debian:Etch/standard/armv4l/:full”. Finally, chown all correctly to the obsrun user:

    # chown -R obsrun.obsrun /srv/obs/build/Debian:Etch/standard

    Now youre done on the server and can start the scheduler again. It should show up with a line: “armv4l: running for about …” on the OBS monitor webpage, indicating all is done correctly on your local OBS server. The scheduler now needs a while to start up and rescan the new binaries.

    Updates for “qemu”, “build” and “osc” for cross-build

    First, download and install a specifically fixed qemu on your local machine where you want to run “osc build” local build:

    # wget -q -c http://download.opensuse.org/repositories/openSUSE:/Tools:/Unstable/openSUSE_11.0/x86_64/qemu-0.9.2svn20080824.5081-12.1.x86_64.rpm
# rpm -Uhv qemu-0.9.2svn20080824*.rpm
# sh /usr/sbin/qemu-binfmt-conf.sh
# wget -q -c http://download.opensuse.org/repositories/openSUSE:/Tools:/Devel/openSUSE_11.0/noarch/build-cross-2008.08.31.4831M-1.1.noarch.rpm
# wget -q -c http://download.opensuse.org/repositories/openSUSE:/Tools:/Devel/openSUSE_11.0/x86_64/osc-cross-0.108.4831M-2.1.x86_64.rpm
# rpm -Uhv {osc-cross,build-cross}*4831M*.rpm

    Now we are ready to run the first “osc build” command for cross-build. To do that, you need a package able to build for Debian:Etch targets. I suggest you to copy e.g. openSUSE:Tools/lzma to your local OBS. Then switch off building for armv4l targets for it inside the meta prj data, and switch on a arm target for the package lzma inside:

    .....
  <build>
<disable arch='armv4l'/>
  </build>
  <publish>
<disable arch='armv4l'/>
  </publish>
.....
  <repository name="Debian_Etch">
    <path repository="Debian_Etch" project="openSUSE:Tools"/>
    <arch>i586<arch>
    <arch>x86_64<arch>
    <arch>armv4l<arch>
  </repository>
.....

    Now, checkout the package and try your first cross-build:

    $ cd <goto some local dir>
$ osc -A <local obs ip> co openSUSE:Tools/lzma
$ cd  openSUSE:Tools/lzma
$ osc -A <local obs ip> build --userootforbuild --clean Debian_Etch armv4l lzma.dsc
Building lzma.dsc for Debian_Etch/armv4l
Getting buildinfo from server
Updating cache of required packages
Writing build configuration
Getting buildconfig from server
Running build
  sudo /usr/bin/build --root=/var/tmp/oscbuild-root/martin/Debian_Etch/armv4l --rpmlist=/tmp/rpmlist.gpIne8 --dist=/tmp/buildconfig.8xD3vp lzma.dsc --clean
--changelog --arch=armv4l
logging output to /var/tmp/oscbuild-root/martin/Debian_Etch/armv4l/.build.log...
Memory limit set to 5418004KB
Using BUILD_ROOT=/var/tmp/oscbuild-root/martin/Debian_Etch/armv4l
Using BUILD_ARCH=armv4l


jupiter started "build lzma.dsc" at Mon Sep  1 01:42:01 CEST 2008.


processing specfile /tmp/obs-update/tmp/openSUSE:Tools/lzma/lzma.dsc...
running changelog2spec --target debian --file /tmp/obs-update/tmp/openSUSE:Tools/lzma/lzma.dsc

...............cut off in the middle.................

dh_compress
dh_fixperms
dh_installdeb
dh_shlibdeps
dh_gencontrol
dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
dh_md5sums
dh_builddeb
dpkg-deb: building package `lzma' in `../lzma_4.32-6_arm.deb'.
 dpkg-genchanges
dpkg-genchanges: including full source code in upload
dpkg-buildpackage: full upload; Debian-native package (full source is included)


/var/tmp/oscbuild-root/martin/Debian_Etch/armv4l/usr/src/packages/DEBS/lzma_4.32-6_arm.deb

    And cheers, you got it.

    You can experiment with the resulting chroot environment inside the buildroot:

    $ sudo chroot /var/tmp/oscbuild-root/martin/Debian_Etch/armv4l/
root's password:
# uname -a
Linux jupiter 2.6.25.11-0.1-default #1 SMP 2008-07-13 20:48:28 +0200 armv5tel GNU/Linux
# file /bin/bash
/bin/bash: ELF 32-bit LSB executable, ARM, version 1 (ARM), for GNU/Linux 2.4.1, dynamically linked (uses shared libs), for GNU/Linux 2.4.1, stripped
# ldd /bin/bash
        libncurses.so.5 => /lib/libncurses.so.5 (0x42084000)
        libdl.so.2 => /lib/libdl.so.2 (0x420cf000)
        libc.so.6 => /lib/libc.so.6 (0x420db000)
        /lib/ld-linux.so.2 (0x40081000)

    We have a nice new toy now to play with! Keep happy hacking.

    This finishes the current part of the article series. The next part will be about the next steps in the development, a roadmap, what can we do with it and “when will it be inside build.opensuse.org”.