With the help of a unique identifier that is stored in every binary executable matching the executable, a coredump and the corresponding debuginfo together becomes really easy. You don’t need to know the package name and the version-release string to download and install the correct debuginfo package. This is achieved by extending the linker, some additional tools and the package management itself.

The build id is a unique identifier stored in the .note.gnu.build-id note section of the executable file and loaded into the process image during run-time. Different means to compute the unique identifier are supported although the default setting is to use a 20 byte SHA1 hash of the unstripped executable (see ld linker documentation for further information about the –build-id option).

To be able to read the build id from a core dump the kernel must include the ELF header pages in file-backed private memory areas (see documentation on /proc/<pid>/coredump_filter). This is the default setting on recent openSUSE kernel versions.

Different tools can be used to print out the build-id. eu-readelf (from the elfutils package) prints the contents of the note sections given the -n option in a human readable fashion. pbuildid (from the ptools package) is prints the build-id from executables and from core files including the build-id of all loaded shared objects during the crash.

Now, zypper can be asked to install the debuginfo package that provides the debuginfo for the given build-id.

# zypper install -C "debuginfo(build-id)=b75bab63c9a25eb13264bb95f1fef190e157f865"
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following NEW package is going to be installed:
  bash-debuginfo


Overall download size: 605.0 K. After the operation, additional 2.1 M will be used.
Continue? [YES/no]: yes
Retrieving package bash-debuginfo-3.2-148.2.x86_64 (1/1), 605.0 K (2.1 M unpacked)
Retrieving: bash-debuginfo-3.2-148.2.x86_64.rpm [done]
Installing: bash-debuginfo-3.2-148.2 [done]
# 

If you are really lazy you can call the following script to do the job for you:

#!/bin/bash                                                                     
#                                                                               
# Sample script how to install debuginfo packages by build-id                   
#                                                                               

IDS=''
for f in "$*"; do
    case "$(file -L $f)" in
        *ELF*)
            IDS+="$(pbuildid $f 2>/dev/null | awk '{print $NF}') "
            ;;
        *)  
            ;;
    esac
done

echo "Install Debuginfo for following build-ids: $IDS"

CMDLINE=""
for i in $IDS; do
    CMDLINE+="debuginfo(build-id)=$i "
done

echo $CMDLINE | xargs zypper install -C

The issue caused by the OBS worker update on arm builds is fixed by a new qemu.

This new qemu version also has fixed the Fedora 10 @ ARM build problem.

So we have the following working ARM target distros available for ARM: Fedora 10, Debian 5.0 and Ubuntu 9.04.

Have fun.

A lot of my day job now involves working with Ruby on Rails. At first I wasn’t sure how much I would like Rails or ruby, given that I had been doing a lot of C#/C/whatever desktop work before. Not surprisingly, though, I’ve become quite addicted. The test-driven nature of development is a welcome change — most desktop apps I worked on didn’t even have tests. The Rails community has done a great job of banging automated testing into people’s heads. Almost every tutorial, book, or random blog post I’ve seen emphasizes the importance of good automated tests. Hopefully it has helped decrease the instances of ‘snorpage’, but perhaps my co-workers would disagree :)

Anyway, I love Rails so much that I’ve converted my blog from Wordpress to Enki. Enki is more of a create-your-own-blog construction kit than a turn-key solution like Wordpress. That was one of the main reasons I chose it over Typo or Mephisto — I wanted to be able to easily hack on it.

I wrote a quick and dirty script to help me import the Wordpress posts into Enki. Any fellow Enki hackers can grab it here.

Its a while since I posted the status about the ongoing work for ARM support in the OBS and for an openSUSE port. It all started with my participation in the OBS development as an external contributor. Then, on Hackweek 2008, we had the idea to enforce a new solution other than the traditional methods of compiling code either natively or via a cross compiler on a host system. The idea was to give build scripts as much of the target enviroment as they need to just work without changes in the packaging definition – in order not to change thousands of package descriptions which define a linux distribution.

A lot happened in the meantime. And I can now report some significant progess in bringing the joys of OBS and openSUSE also to all the ARM users:

I held a talk about cross build in OBS on FOSDEM 2009 – documenting the solution

ARM support is in the source tree for OBS and the publicly available packages

ARM support is activated in the public OBS

OBS 1.6 release is currently in beta – this release is the dedicated version for ARM

The Linux foundation will bring the joy of OBS to an even wider audience

Some preparations have been done for porting Base:build to ARM – we can mix cross compilers an native emulated code now

A Summer of Code project will be done to accelerate the development of an openSUSE @ ARM port

To accelerate the openSUSE @ ARM development itself, we want to involve more people of the community. We have an IRC Channel #opensuse-arm for OBS and openSUSE @ ARM – i invite you to visit us there. We will also find a solution to bring the needed changes into the openSUSE Factory codebase so regular build for openSUSE can take place once the base system is working. I will inform you once we have a working base system that can be used to port many other packages. The soon starting Summer of Code Project “Porting openSUSE to ARM platform” is intended as the starting point here.

The next steps are to bring in all the useful applications into OBS, so you have the wide range of applications that is already available for x86 or powerpc then also on ARM. You will see interesting things happening during the next time here. To support this, more and more of the tested ARM targets will be made available also on the public OBS. I will follow up with status updates.

With this message I want to make you aware that the ARM builds inside OBS are currently broken. This is due to an update of the buildservice worker code on Friday. This update removes the limit of 2 GB for the build results from the buildservice. Also, the performance of the buildservice backend code has been improved for high loads with lots of new events.

We are now faced with an incompatibility of the underlying QEMU emulator with this new code to extract the build results in the combination of XEN and QEMU user mode. You can in fact see in your build logs for ARM error messages like:

… saving built packages
/usr/src/packages/DEBS/dsme-tools_0.6mer3_armel.deb
Unsupported ioctl: cmd=0x0002 (0)
FIGETBSZ: Function not implemented
Unsupported ioctl: cmd=0x80041272 (4)

We are working on a solution already. A new QEMU with this and another issues fixed is already under test and has been dropped to openSUSE:Tools:Devel/qemu-svn. I will inform you when we have this fixed in the public build service.

Currently, the openSUSE-Education team is “playing” with the new features of the external build service. As a first result, we’re proud to announce our new live/installable DVD!

This DVD includes:

• the official updates to all packages since the openSUSE 11.1 release
• fully pre-configured, ready to run KIWI-LTSP server
• tons of applications from openSUSE Education repository

You can get it from here: http://download.opensuse.org/repositories/Education/images/iso/ – it’s called openSUSE-Edu-KIWI-LTSP-live*.iso (the openSUSE-Edu-KIWI-LTSP-live-unstable*.iso is for development only). Please watch for the Build Numbers at the end of the ISO-Name if you report bugs in our bugzilla.

Have a look at CyberOrgs blog on the most efficient ways to download the image.

Needless to say more :

"Not sure how you are doing it, but you always make me smile when we are talking."
"I know how - because you are doing the same. It is then easy to smile in return."

Wish you a nice day (evening/night, depending on the timezone you are in) and if you haven't got any compliment today so far, try to give some out :)

P.S. Exceptionally, I am being positive. Enjoy it, it does not happen to me very often :D

Today I discovered Dropbox, an online storage and synchronization tool. It offers 2 GB of free storage to its users and is available for Mac OS X, Windows and Linux. I’ve tested it on Linux and Windows so far and it’s working great. If you’re tired of carrying around USB sticks to share files between different workstations, be sure to check it out. Hint: by clicking on the link above you (and me) will get 250 MB of free online storage as a bonus.

Installation and Setup on openSUSE 11.1 is a breeze

• 1-click install is available in Gnome:Community
• Logout from your GNOME Session and login again
• Run “Dropbox” from the GNOME menu to link your workstation to your Dropbox account

Currently there’s a plugin for nautilus available. Hopefully some KDE coders more experienced than me will come up with a Dolphin plugin soon. Where the Dropbox daemon is proprietary software, the nautilus plugin is released under GPL and its sourcecode should provide the required information about the Dropbox daemon’s API to port it to KDE/Dolphin as well.

Have fun!

During the fall, Olivier showed up on tomboy-list announcing a school project he would be working on: Tomdroid, a Tomboy note reader (and eventually editor) for the Android mobile platform that drives the wonderful G1 phone. After a few months of development, the first "baby-eating" release is available for testing. Olivier mentions a number of nasty little bugs in this first release, but he is already working on fixing them, and people are already starting to poke around with the code and find ways to help.


Obviously, having access to your Tomboy notes on your mobile phone is a huge win. Even when they are read-only, you can:

• Access your grocery list without having to call your wife (which only proves that you weren't listening in the first place)
  
• Quickly access your notes about obscure system configurations when visiting a client site, instead of googling (ever worked for a client who stood over you shoulder, and wasn't too impressed by your frequent googling?)
  
• For me, I often forget to add contacts and calendar events until I am repeatedly burned, but it's pretty common to have that info floating around in my Tomboy notes.
  
• And the number one win: you can have the schizophrenic dude next to you on the bus review the draft of your latest blog post (this keeps him busy, making it less likely he will stab you in the face)

See? Tomdroid just saved your life.

As a G1 owner, I'm extremely excited about this project. I downloaded the Android SDK just so I could start playing around with the code. Olivier has communicated extensively with us on tomboy-list and in #tomboy, and one of the really nice things he's done is initial work on an XML schema for the Tomboy note format. This will be extremely useful to maintain, as it is inevitable that Tomboy notes will being to be read and edited via interesting new clients.

If you're looking for a fun (because it's Tomboy-related) and hip (because it's mobile) project to work on, I recommend spending some time with Tomdroid. New projects are always fun, for example you could work on tighter integration with phone features (like phone numbers, contacts, calendar, and web), or you can start playing with note editing (maybe a nerdy markdown editor would be a good fit?).

Ideas for getting your notes onto your G1:

• Manually copy ~/.tomboy/*.note to your G1 periodically. Verdict: Lame
  
• Write Tomboy add-in that hooks into HAL, notices when a G1 is connected, offers to push notes to phone (could be a button that appears in the note toolbar, a libnotify bubble, or even a totally automatic process). Verdict: Instant win, minus the requirement to plug in your phone.
  
• Implement Tomboy online service, and corresponding sync functionality in Tomdroid. Verdict: Epic win, may not be ready for a few months.

Those are great ideas. While drafting this post last night I really liked the second one, so here you can download my quick hack job that Gets It Done. Drop Tomdroid.dll into ~/.tomboy/addins, or `make && make install`. Many thanks to James Wilcox for his incredible vision and Aaron Bockover for all the Banshee code I stole to make interacting with HAL devices brain-dead simple. Right now you just get an item in the Tools menu in the note window, but clearly there are better things that could be done. Patches welcome, I'll dump this into git as soon as I get rid of the excess Banshee code I brought in.

This post brought to you by the Tomboy Blogposter add-in.

As you may know, SUSE was originally based on Slackware. And some some relics from those early days if SUSE survives to present. The biggest example visible for end-users was packaging of desktop environment to /opt. Gnome was switched few years ago and KDE3 packages still remains in it, because packagers decided to focus on KDE4, so only those packages are comfortable with FHS and are installed into /usr.

With opening of SUSE development towards community via BuildService’s collaboration, or Contrib, the another relict of Slackware days was raised – which I mentioned in my previous post – a .changes file.

This file is used in SUSE for tracing of package changes and rpm %changelog is created from this file during build. As it has a consistent format, we used an internal command called vc for add a new entry to it and this tool generates a proper header of changes file. So after my last patch, implementation of osc vc was a logical (but not straightforward) job.

After some discussions with Ludwig Nussel and on opensuse-buildservice mailing lists, I implemented and committed an osc vc command. This is based on buildvc script written by Ludwig and is available in build.rpm (from version 2009.04.17). It has the same behavior as an old vc command.

Basic usage of this command is simple:

user@host:some:project/package/ $ osc vc

Command will find a changes file, open it in EDITOR (default is vim) and fill a header. You can also use it in non-interactive mode using -m MESSAGE. You can also specify a file to edit, or edit a file in other directory than current, … – see osc vc –help

The main difference between buildvc and osc variant is in e-mail address handling. The osc implementation has more sources of it, so it try to

1. use content of mailaddr variable (same as buildvc)
2. read a configuration from ~/.oscrc
3. read an email from user’s metadata (see osc meta user your_login)

This is because many users want to use a different e-mail for changelogs than iChain one, so osc allows configure an email for each instance of BuildService. Appropriate part of ~/.oscrc looks like

[https://api.opensuse.org/]
user = login
pass = password
email = user@defined.email