My KDE week

Adopt an openSUSE KDE package: everybody can help packaging

Posted on: June 3, 2012

If you think that you cannot help packaging, you might want to re-consider, since with the open buildservice at 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.


13 Responses to "Adopt an openSUSE KDE package: everybody can help packaging"

Hi Sven,

sehr schön, danke. Noch eines drauf setzen könntest jedoch, wenn auch für User die sich mit englisch schwertun (wie ich auch) diese Anleitung ins deutsche übersetzt veröffentlicht bekämen. Oder aber, Du übersetzt diese und ich poste die als eine Art deinigen “Gastbeitrag” bei mir über den Blog. So oder so, danke das sich manche noch die Arbeit machen und ihr tun dokumentieren … für die “wenigen” Fans die openSUSE noch hat. 😉

Die “SuS(i)E” sei mit euch, solange die’ s noch gibt … 😉
Grüße aus dem verregneten Länd’le … 🙂

I tried several times to become a KDE maintainer on openSUSE but was always rejected without valid reasons. [We do not have rules to become a KDE maintainer on openSUSE is not a valid one.]
So no thanks for this invitation to do further work on KDE …
For further information ask tittiatcoke, cartman, dirk or wstephenson on #opensuse-kde IRC.

[Auf Deutsch]
Ich versuchte mehrmals vergeblich ein KDE-Paketbetreuer zu werden.
Aufgrund fehlender Regeln für ein Aufsteigen im Projekt (z. B. Zugriffsrechte zu den Hauptpaketen) werden sich wohl nicht allzu viele Mitstreiter rekrutieren lassen.
Die aktiven KDE-Betreuer von openSUSE haben es inzwischen auch geschafft, dass ich nicht mehr viel Zeit in KDE und deren Übersetzung stecke (KUSC schleifen lassen, veraltete Übersetzungen, etc.).
Im #kde-quality IRC wurde mir nur mitgeteilt, dass es kein Problem vom KDE-Projekt sei. Mein Hinweis war dann lediglich: Es ist ja auch nicht das Problem eines Autoherstellers, wenn dessen Vertragswerkstätten nicht ordnungsgemäß arbeiten [und schließlich die Kunden Automobile eines anderen Herstellers kaufen] …
Fragt einfach mal tittiatcoke, cartman, dirk oder wstephenson im #opensuse-kde IRC.
Ich bin mir im Klaren, dass die eine andere Meinung haben werden.
Um mal auf eine der Diskussionen zu verweisen:

1. Most people will only maintain one or two packages, submit a patch here and there and mainly work in KDE:Extra or similar repos, not KDF, KUSC etc. So most people will not run into any of the “trouble” you state.

2. The “big” KDE repos are a bit different than the rest. In fact KUSC is different from KDF as it is mainly maintained by somebody not payed by openSUSE.
While there might be issues with giving people permissions on those repos it does not hold anyone back from submitting requests. And having different opinions on what a repo should contain or not is not unusual. In that case the community and/or those doing most work on a repo decide.

3. This is kind of repeating 1. Even if you do not want to work on KDF etc. due to whatever reasons or lack of permissions. There is plenty of work within KDE:Extra, KDE:UpdatedApps and Playground.

I still do not get why you would stop translating KDE just because your translation does not appear in some repo within the time you think it should. Before KUSC was created, people translated KDE trunk although there were no packages at all built before beta1. Seems a bit strange to me that you stop translating just because now trunk packages are not updated at least weekly.

I did not read every single post in that bug report but did you try to submit an updated translation package or did you try to submit one to normal Playground for those who want it? KUSC was never meant for “normal” users and those more familiar with Linux should be able to get your packages from Playground. Edit: I just saw that your suggestion to fix the script was accepted. If I understand correctly that was the better solution than separating the translation from the rest.

Good article. What license do you use in your blog? I would like to translate into spanish in my blog. I will say that you are the author, and link this page of course!! 😉

The licences is shown at the bottom of the right column in the blog. Feel free to translate the text. The more people know about the buildservice the better.

Excellent!, I hope this article will inspire us to contribute for packaging too.

[…] traducción que he hecho de un artículo escrito en inglés. Puedes ver el original en este enlace: escrito por rabauke. A él los créditos del original, y gracias por permitirme la traducción. […]

Hi !
I have made a translation in to spanish of this mini How to. Here’s the link:

Thank’s rabauke for let me do it!

Where can I ask for help, get some input or ask for a review? I started to update an older package from openSuse Factory after reading your blog post. But I run intro trouble with the install command.

If it is a KDE package you can drop-by on IRC #opensue-kde or subscribe to the opensuse-kde mailinglist.

Otherwise you can use the general #opensuse-packaging channel and mailinglist.

For a review you just have to submit the package back, e.g. by opening your package on the buildservice website > click on “Sources” > Show the diff and submit these changes back. It will automatically create a submit request which will be reviewed by the maintainer of the repo.


I’ve build a package to test the process. All worked OK, but I have two doubts:

– Can packages have multilingual descriptions? If so, how and where could I add them?
– Can I select distributions and versions for the build targets (openSUSE 12.x only; Fedora and CentOS only; etc.)?

Thanks in advance.

I think packages cannot have multi-lingual descriptions. If I’m right this not a buildservice limitation though but a rpm limitation. At least I don’t remember any multilingual RPMs within openSUSE. Within the buildservice you can of course write whatever you want into the description part of a package.

If you open the sub-project of the package in your home project you can click on “Repositories” and add new build targets, including other distros.

Packaging for several distros from one package and project is not that trivial though! and

As mentioned in another reply, you can ask on IRC #opensuse-packaging or on the mailinglist respectively.

Thank you for the answer.

In YaST (Install / Uninstall software) I can see descriptions under the Description tab that are translated to my language and the rest are in English. Do you know if those translations are provided in a separate package or how can it be done?

I’ll check the links and I’ll ask in the IRC if I can find the answers to my questions.

Thanks again.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: