Duncan Mac-Vicar P.

Today I used some of the coolest openSUSE Build Service features: project layering, patches against linked packages and aggregates. I want to write about them.

I needed to test a feature in PackageKit. I am using openSUSE 11.0. However upstream PackageKit does not play nice with 11.0. Stefan Haas fixed this, taking our PackageKit sources, adding some patches, and building them in his home project, which results in a repository here.

My feature involved a patch against PackageKit and then testing it from a client application (to adapt it), so what I wanted to achieve was to use Stefan’s PackageKit plus my patch, packaged in a rpm.

I could just copy Stefan’s sources and patches to my home project, and add my patch, but that would be duplication. Any change Stefan does later would require to copy it again.

Luckily the build service has a feature call linking, so I can link Stefan’s package to my home project. You can do that from osc or from the web user interface (Link package from another project), and that would result in a new package called PackageKit in my project (I created a subproject home:dmacvicar:packagekit for this purpose) with a single file called _link.

This version of PackageKit only builds with Factory’s libzypp, so here we have various options:

• build on top of zypp:svn/openSUSE11.0 which is ZYpp svn built on openSUSE11.0
• link all zypp:svn packages to my project (too inefficient, Adrian would kill me if I start to rebuild ZYpp in every project )
• aggregate all ZYpp openSUSE_11.0 packages from zypp:svn in my project (aggregate explained later)

Because I already have the repo zypp:svn in my repo list, I chose building on top of zypp:svn. (This will mean that in order to use this modified PackageKit repo, you need to add zypp:svn as well )

So now, I can add my patch next to the _link file. However, How to make this patch appear in Stefan’s specfile? Do we need to patch the spec file too? No. The build service does it for you. Just edit the _link file which looks like this:

<link project='home:haass' package='PackageKit'>
    <patches/>
</link>

So it looks like:

<link project='home:haass' package='PackageKit'>

    <patches>
        <add name="pk-outdated-notification.patch" />
    </patches>
</link>

This will insert the patch in the spec file when building. That is real magic.

Sadly, this bleeding edge PackageKit version requires some libtar-devel not available in 11.0. Stefan had a backport to 11.0 in his home project too. Do we need to link the package to our project too? No. Linking here is unnecessary because we don’t really need to rebuild a copy of this package, we only need to make it available in our repository for people installing PackageKit from our project, who don’t have Stefan’s project added in their repository list, that will get libtar grabbed via dependencies, but we don’t care if the metadata grabs the final rpm from Stefan’s project.

That is called “aggregate”. To aggregate a package from another project, we create a new package (called libtar) and add to it a file called “_aggregate” (the web interface does not help you here). Edit that file so it looks like:

<aggregatelist>  
    <aggregate project="home:haass">  
        <package>libtar</package>  
        <package>libtar-devel</package>  
    </aggregate>  
</aggregatelist> 

This will map home:haass repositories 1:1 to our repositories. So if we build our project against openSUSE11.0, it will aggregate our package with home:haass/openSUSE11.0 too. If you don’t have a 1:1 mapping, look the Build Service Tips and Tricks to do more complex aggregates.

Then I am ready to install my new PackageKit:

sudo zypper in -r home_dmacvicar_packagekit PackageKit PackageKit-devel
Reading installed packages...

The following NEW packages are going to be installed:
  PackageKit-devel PackageKit


Overall download size: 1.1 M. After the operation, additional 5.1 M will be used.
Continue? [YES/no]: y

There are features that are present since some time, but people just don’t know about it. This time I will mention one that is very useful to developers.

Imagine you are a contributor to foo, which is also available to the distribution as foo.rpm. However, you install the distro from packages, but compile your foo source tree by hand. Compiling foo requires lot of packages.

zypper to the rescue. If foo is in the distribution, make sure you have the main distribution repository added, plus the source repository. Source packages have a nice feature: their Requires, are the BuildRequires of the binary package.

The source install command (si) has a -d option to install only the dependencies, and not the source package itself. So lets say we want to compile PackageKit, lets install all the compile dependencies:

# sudo zypper si -d PackageKit
Reading installed packages...

The following NEW packages are going to be installed:
  opensp openjade gtk-doc docbook_3 docbook-dsssl-stylesheets sqlite-devel

Then I can go and compile:

PackageKit> ./autogen.sh --libdir=/usr/lib64
  --prefix=/usr --enable-developer --with-security-framework=dummy 
  --sysconfdir=/etc --with-dbus-sys=/etc/dbus-1/system.d
  --enable-zypp --with-default-backend=zypp

Note, you do need the source repository added in order for this to work, otherwise zypper will not be able to find a matching src.rpm package to read the dependencies from.

Federico posts about git interactive rebase to squash commits with build errors together with the fix, which is a nice feature.

However, git design of “commit often” does not mean you need to commit whenever you modify one line, that is a bit overkill.

The git index can be used to incrementally add your work to the point it is really worth committing, and actually you can also interactively pick stuff to be added to the index for later committing just as you can interactively rebase.

I recommend reading the article Embrace the Git Index to know more. Also this blog post mentions the topic.

On the same topic, does anyone knows if it is possible to install gitorious or its fork gitlab on a separate server to the machine actually hosting the repositories (and therefore having the web application push the configuration from the database to the other server via ssh or something? ).

I never expected to see Kopete running natively on Windows, but the KDE-Windows guys have done enormous progress:

See the rest of the article on how to run KDE applications on Windows.

Long time since I haven’t blogged.

The server where I have my blog suffered a big crash, and after they had reenabled most services, the status of the databases was unclear. For some days, my blog was gone, forever.

I had some backup, and also experimented recreating it from google cache using a html parser using hpricot. I was successful in recreating an atom feed from there, but had no much luck with the comments (because atom comments are not very standard). Well, I learned a lot on the way

At the end, the sysadmins were able to recover everything, and my blog came to life again, except for some encoding issue that crashed wordpress, which was solved by the sysadmins without any intervention (thanks guys).

So here I am, back. I will be posting some stuff I had on the queue.