Adopt an openSUSE KDE package: everybody can help packaging

Posted by: rabauke on: June 3, 2012

• In: KDE | openSUSE
• 13 Comments

If you think that you cannot help packaging, you might want to re-consider, since with the open buildservice at build.opensuse.org you can already help packagers with just a few clicks in your browser and without the risk of breaking anything – not only for openSUSE but also for Fedora and other distros.

While creating a new package might be out of scope for most distro users, updating a package is often very easy. All you need is a browser.

To start the small series on how to work with the buildservice’s web front-end, let’s have a look at updating an existing package to a new version. Very often the procedure of updating a package consists of only three steps which can all be done within your browser:

1. create a copy of the package to update
2. upload a new tarball and change the version string within the package
3. submit changes back to the package repo

Example: Updating a package

To make this easy to follow, I will give an example and break down the procedure into tiny steps.

Copying/Branching the package

1. log into the open buildservice (you can register for free)
2. click on All Projects
3. click on the repo the package you want to update is part of, e.g. KDE:Extra
4. click on Packages
5. click on the package you want to update, e.g. luckybackup
6. below the summary, click on Branch package (only available if you are logged-in) and on OK when asked if you really want to branch the package

You are now re-directed to the branched package within your home project. At the top of the website you can see the path to the package, e.g.  openSUSE Build Service > Projects > home:username:branches:KDE:Extra > Packages > luckybackup. This shows that the buildservice created a sub-project branches:KDE:Extra within your home project. If you want to navigate there manually you can click on Home Project at the top-right of the website, then on Subprojects and finally on branches:KDE:Extra.

Below that path you have a bar with links which we will use within this example, e.g. Overview, Sources etc.

Within your home project you can alter the package without breaking anything in the original repo. If you messed-up, just remove the package/sub-project and re-try.

Updating the package

Packages are built from tarballs, i.e. archives of the app’s source code. To update the package you have to re-place the existing tarball and alter the version string of the package.

1. click on the package within your home project
2. click on Sources

You will see the list of files within the package.

• luckybackup.spec: The spec file contains the information on how to build the package. Except for changing the version string you will not have to worry about it in most cases.
• luckybackup.changes: This is a log of the changes applied to the package. You will have to add something like “- updated package to version x.y.z”.
• luckybackup-0.4.6.tar.gz: This is the tarball of the app’s source code. You can get it from the app’s website or create one yourself in case you are updating a git snapshot.
• xyz.patch: Patches that are applied to the source code before building. Most often you will not have to worry about those.  Some hints about handling patches – in case it is necessary – will be part of one of the next posts.

Most files are represented as links. If you click on them you can edit them within your browser.

HINT: If you have trouble with the browser editor, e.g. line numbers not fitting the text or underscores not showing-up, change the fixed font to e.g. Droid Sans and increase its size.

While you might want to have a look at the details of the spec file, most often you just need to find the line:

Version:        0.4.6

and change it to e.g.

Version:        0.4.7

To save the changes click on the save icon  at the top of the editor. If you have a look at the spec file it will most probably use that string to determine the file name of the tarball to use for building the package, e.g.:

Source0:    %{name}-%{version}.tar.gz

This means that the tarball with the new version has to be named luckybackup-0.4.7.tar.gz. There are several ways to add a new tarball to a package, the easiest is to download the tarball to your computer and then upload it to the package on the buildservice.

1. go to the sources list and remove the old tarball by clicking on the remove icon  next to it
2. click on add file below the list and select the file on your computer
3. only in case it does not have the above mentioned name you will have to enter the correct file name into the input filed
4. save changes

Now click on the luckybackup.changes file to add the changes you made to the package. To insert a new item just click on the Insert changes entry template link at the top of the editor.

Re-submitting the package

If you click on Overview or Monitor you can see the build status of the package. Clicking on the status will open the log. You can follow the build process and check for errors. In case the building succeeds you can re-submit the updated package. Re-submitting can still not break anything within the original repo! Only if the submit request is accepted by the repo maintainer the changes will become relevant to the repo.

To re-submit simply click on Sources within the package. You will find a link Show the diff and submit these changes back. Click on it, click on submit and add a comment to the submit request, i.e. what you did. Submit the the diff.

That’s it! The buildservice will automatically send an email to the repo’s maintainers and they will handle your submit request.

Build failing

Of course building an updated package might fail. The most trivial error is e.g.:

error: File /usr/src/packages/SOURCES/luckybackup-0.4.75.tar.gz: No such file or directory

which tells you that the buildservice cannot find the file you told it to build, i.e. either the file name is wrong or the strings that are assembled to create the file name within the spec file. I will add some more hints on how to resolve other trivial errors in the next post.

Feel free to add comments in order to improve this little howto.