The pre-baked approach to building software

Mostly convenience foods are fun but loaded with sugar and salt. But building software needn't be inconvenient or make your waistline or disk requirements start to bulge. I've been pushing the openSUSE Build Service to anyone in the KDE community who'll listen, since making tiny tweaks to existing codebases with minimum effort is exactly what it's designed to do.

So here's a worked example to go from a new Build Service account to a built, tweaked RPM in 5 minutes*.

Aaron just asked for testing for a patch to the KDE 3 codebase, since he doesn't have a build tree for KDE 3 any more. We'll take the existing openSUSE 11.0 kdebase3 package, and make a customised version including the patch, and finally have a repository online that Aaron can point his comma-as-decimal-point using users at to test.

Go to your home project
Add subproject 'KDE3'
Add repository: Click Advanced, find KDE:KDE3/openSUSE 11.0 and add it
Link package kdebase3 from KDE:KDE3

Get the sources:
$ osc checkout home:wstephenson:KDE3 kdebase3
Add the patch:
$ mv aseigo_kdesktop_comma.diff home:wstephenson:KDE3/kdebase3
$ cd home:wstephenson:KDE3/kdebase3
$ vi kdebase3.spec
Tell the build service about the new patch
$ osc addremove
Check it in
$ osc ci -m "Add aseigo comma kdesktop patch for testing"

Shake n'bake! The package is scheduled for immediate build including the new patch.

You can do the command line bits using the web frontend, and vice versa, but this is my way of working. Now all I want for Christmas is a Plasmoid to monitor my Build Service projects.

*Build time not included. I expect the finished package will pop out here, accompanied with the mouthwatering smell of fresh baking.

Update: x86_64 was done at 1300 UTC - I've tested it and 100,3 * 4 does indeed equal 101,2 401,2.<


Holy *crap* that's hot!

I'm absolutely going to have to learn more about osc and what can be done with it; the FOSS world ought to be abuzz about this tool, though I appreciate how it can be hard to make something be perceived as "sexy" when it doesn't include a nifty OpenGL engine or include the word "hyper" (as in "hypervisor" ;) or "para" ... I wonder what Novell could do to get this story out there more, as this could be a really impressive way to help both test as well as push out custom packages where needed..

By Aaron J. Seigo at Wed, 10/08/2008 - 14:55

...alright. need more cycles/time to work with this.

By rdieter at Wed, 10/08/2008 - 17:33

3 things I should clarify:

* I actually worked on the 3.5.10 packages in the KDE:KDE3 repository; these are not the default 3.5.9 packages released with openSUSE 11.0 but the latest KDE 3.5 release, built for 11.0.

* Users of a broad range of other distributions (Hello, Rex!), are encouraged to use the Build Service. We have imported the sources of all the major current Linux distributions already. So you can build or modify Fedora, Mandrake, or even Debian or xbuntu packages natively using the same steps.

* You can simply add patches to the existing patch list of a package, using a simple XML file, or if you know your way around a spec or control file, you can edit that directly. Your changes are stored as a patch to the specfile so upstream changes since your edit aren't lost.

If there's demand I can put on an IRC workshop in using the OBS.

By Will Stephenson at Thu, 10/09/2008 - 06:18

Well, I've just taken the patch, applied it to kdebase/F-8 in Fedora CVS and sent it straight to dist-f8-updates-candidate. ;-) If it wouldn't have worked, I'd just have removed the patch afterwards, candidate updates don't have to go anywhere, but as it works (and I simply fetched the build from Koji to verify that), it'll likely be included in our next F8 kdebase update (no way I'm going to push out a new kdebase just for such an almost cosmetic fix though ;-)), if any (F8 will be EOL in about 2 months).

This reminds me a lot of the centralized vs. decentralized SCM debate: what I did was the centralized method, I just committed to the central repository and checked the result (I did proofread the patch first and so expected it to work; I don't commit nonsense, don't worry ;-)), what you did was the decentralized workflow (branch the package and test the change in a branch). In this case, both worked equally well, and I only got it tested first (Oct 8 10:34 UTC) because I found the blog entry earlier.

We do also have support for scratch builds in Koji though. But those don't end up in any repository and I also don't think it's possible in Koji to use scratch builds as dependencies for other scratch builds, your build system is vastly superior there. Additional repositories are its strong point, here in Fedora we have to either use the central one or do our own builds for our own repositories outside of the build system. (Or use yours. ;-)) In this case, a scratch build would have worked though.

By Kevin Kofler at Thu, 10/09/2008 - 22:20