philipp's weblog header image

Contribute to openSUSE: Update a package

June 26th, 2012 · 1 Comment · English, other stuff

I’m sure many openSUSE users have already heard about the goodness of the openSUSE Build Service (OBS). But how many have already tried to use it as developer? I didn’t — until recently. A couple weeks ago I had found a wrong dependency in the calibre package, and today I was in the need for a newer version of hplip. I found that using OBS is much easier than I expected. Don’t believe me? Have a look how easy it can be to update a package. It all follows the popular github fork-and-pull-request development style. As an example I’ll use (a subset of) the changes I did today to the hplip package.

Step 0: Prepare your system to use OBS

Instead of duplicating existing documentation, just have a look at the OBS tutorial at the openSUSE wiki. You’ll only need to follow Step One. Basically, this means installing the required packages for OBS and creating a working directory.

If you’re done, switch to your working directory and you can follow the next steps*.

Step 1: Branch (fork) the original package you want to modify

$> osc branch Printing hplip

Step 2: Do a checkout of the branched project

$> osc co home:YOUR_USERNAME:branches:Printing/hplip
$> cd home:YOUR_USERNAME:branches:Printing/hplip

Step 3: Do the required changes to the package (the actual work!)

$> wget http://prdownloads.sourceforge.net/project/hplip/hplip/3.12.6/hplip-3.12.6.tar.gz
$> # verify binary (gpg, md5sum, etc.)
$> osc add hplip-3.12.6.tar.gz
A    hplip-3.12.6.tar.gz
$> osc del hplip-3.12.4.tar.gz
D    hplip-3.12.4.tar.gz
# adjust the spec file as necessary ...

Step 4: Build locally to verify your changes

$> osc build openSUSE_12.1

Instead of openSUSE12.1 you can use any target your might want to test (e.g. openSUSE_Factory etc.). This command is actually pure magic, it pulls all dependencies, installs them into a chroot build environment, and builds the package. Awesome!

You can now even install the resulting RPM package, the above command will tell you where to find it at the end of its output (probably somewhere in /var/tmp/build-root/home/abuild/rpmbuild/RPMS). You actually should do that and verify that everything works as expected.

Step 5: Finish it up

If you’re happy with your changes, and everything works as it should, we can get ready for submission.

First, add a changelog entry:

$> osc vc

will open an editor and allow you to add a changelog entry into the already prepared text template.

Now, check that you added/deleted all files by calling

$> osc status

If everything looks good, commit the package to OBS by using

$> osc commit

You can now go to the OBS web interface and watch your package build, or use

$> osc results

to see the results of the build process on the openSUSE servers. Note that building may take some time, depending on the OBS load and obviously your package.

Step 6: Submit the changes to the maintainer

Everything is great? The last step

$> osc sr

sends a “pull request” (in git language) to the package maintainer. You can see the status of this request in the web interface as well.

Now you only need to wait for the maintainer to accept your changes and then: Congratulations, you’ve made your possibly first contribution to openSUSE!

Further reading

OBS tutorial in the openSUSE wiki
Tutorial on how the branch/pull system works in OBS

 

* Actually, the steps as written here will not result in a working package. The update of hplip required some other changes that I didn’t document here, but I hope the real-life examples will help to make the steps more understandable.

Tags:

1 response so far ↓

  • 1 Johannes Meixner // Jun 27, 2012 at 12:14

    Many Thanks for your valuable contribution to openSUSE!

    I accepted it because you made the version upgrade and your changes very well.

    1)
    Your version upgrade still builds for all the SUSE distributions which are enabled in the original “Printing” project for the package so that the new version will be available for all SUSE distributions for which the previous version was available.

    2)
    You made your changes in perfect compliance to the existing hplip package which means in particular to provide explanatory comments both in the hplip.spec file and in the RPM changelog file so that it is obvious for everyone what the reasoning and meaning of each item is (without the need to try to find it out via some kind of reverse-engineering).

    3)
    You adapted existing patches (here in particular change-udev-rules.diff) so that the new version works in the same way as the previous version.

    4)
    You filed an upstream bug report for your new patch and you provided the URL of the upstream bug report https://bugs.launchpad.net/hplip/+bug/1017496 both in the hplip.spec file and in the RPM changelog file.

    In the end all this means that it is obvious for everybody to understand what you did and you did it well so that it was easy for me to accept your changes.

    FYI:

    I filed two more upstream bug reports:

    https://bugs.launchpad.net/hplip/+bug/1018303

    https://bugs.launchpad.net/hplip/+bug/1018312

Leave a Comment

Post comment

What is Persona?