The current plan is to have a preliminary detailed schedule of most talks around June 26, 2009.

• clicfs: 637MB ISO Image booting in 1:28 min (0:24 min from RAM)
• squashfs-rw: 751M ISO Image booting in 1:50 min (0:28 min from RAM)

The difference in the sizes of the ISO images are due to the fact that clicfs is using LZMA compression while SquashFS is still using the in-kernel GZIP implementation. Surprisingly the clicfs image isn’t only smaller but is also faster booting on real media and from RAM (using KVM). So even if we ignore the fact that clicfs is optimized for limiting the number of seeks on disk the SquashFS implementation is still slower. It would be interesting to see if it is just the LZMA compression that is making the difference or something completely different.

The patches for the SquashFS fake write support are here: http://git.infradead.org/users/jblunck/linux-2.6.git?a=shortlog;h=refs/heads/squashfs-rw-v1.

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

Some people might have noticed the Kernel: projects that produce a quite heavy load on the build farm. These are KOTD projects that are mirrored to the openSUSE Build Service every night around 4pm CET if there are changes in the internal source repositories.

Currently the following KOTD projects exist:

• Kernel:HEAD is the KOTD of openSUSE:Factory
• Kernel:SL111_BRANCH is the KOTD of openSUSE 11.1
• Kernel:SL110_BRANCH is the KOTD of openSUSE 11.0
• Kernel:SL103_BRANCH is the KOTD of openSUSE 10.3

Additionally there are two projects that are related to upstream kernel development:

• Kernel:Vanilla includes the latest sources from Linus Torvalds’ linux-2.6 GIT tree
• Kernel:linux-next includes the latest sources from Stephen Rothwell’s linux-next GIT tree

With the help of the openSUSE Build Service running the KOTD became even more convenient since the project repository can be added to zypper. Besides that it is now very easy to build external kernel modules (KMP) matching the KOTD.