Our current driver is to enable every OBS user to do maintenance for packages in the maintained products (which are currently openSUSE 11.0, 11.1 and a few days 11.2). The maintenance concept itself is described in a very first draft here

However, the attribute system is way more powerful and can be used to store all kind of informations, attached to projects, source packages or even binary sub packages. The important thing here is that the attribute types have own permission rules. So it is for example possible to edit data in projects like openSUSE:11.1 or Fedora:9 which are usually read only.

A simple example is the OBS:Screenshot attribute, as you might guess you can attach references to screenshots to it. Every maintainer or bugowner has write access to it, this means if you are the bugowner of a package, you store this kind of informations not only in your projects, but also in the openSUSE:11.X project packages.

There is also the openSUSE:Playground attribute type created, just for you, when you like to play with this. Btw, the current available attribute types can be requested via “osc meta prj OBS”. And when you use the osc 0.123svn from svn trunk or openSUSE:Tools:Unstable Project, you can even check single attributes in different ways or create them.

For example:


osc meta attribute openSUSE:11.2 # Shows the attributes of the openSUSE:11.2 project
osc meta attribute home:adrianSuSE --attribute openSUSE:Playground --create # just creates the attribute in my home project
osc meta attribute home:adrianSuSE zphoto # returns empty, since the package hasn't the attribute.
osc meta attribute home:adrianSuSE zphoto --attribute-project # returns with attribute, since it falls back to the project


# stores two values (World Domination and fast) inside of the attribute:
osc meta attribute home:adrianSuSE --attribute openSUSE:Playground --set "World Domination,fast"
osc meta attribute home:adrianSuSE # shows all attributes in my home


osc search --attribute openSUSE:Playground # finds all packages in all projects with the openSUSE:Playground attribute
osc search --package zphoto --attribute openSUSE:Playground # finds all zphoto packages in all project with the openSUSE:Playground attribute


Okay, Okay, all that sounds not horrible sexy when you read it first. But imaging the possibilities. Each team or use case can get their own attributes. They decide what to store in which package, independend if they can modify the sources of project or not. So a team can easily mark packages for any kind of purpose (to fix bugreport 1234, to complete their product Z, to show the state of the packages on web page X, …).

The “osc mbranch” command from the maintenance concept shows also the power of this. You do not need to know where all instances of your package, just tell the server that you need to work on it and the server collects them all.

Please note that the API for the attribute system still might change until OBS 1.7 gets released, we may even need to remove the attributes (even though this is not planned). However, the version running at opensuse.org should be ready to play with this system. And I _really_ would like to hear any kind of feedback, ideas or requests. Can you please comment here, what you can imaging, what else you can use this system for ?

Thanks a lot !

PS: New attribute types can be defined only by the administrator atm, but I am really happy to create any kind of attributes for you, even though you just want to play with it!

Some first impressions can get found on our gallery server already.

In case you are around Nuernberg, you can still drop by for a talk or a beer !

So the final goal is to get a 1-Click package build, but there is even more !

This was my test file:

<services>
  <service name="download_url">
    <param name="host">fotowall.googlecode.com</param>
    <param name="path">files/fotowall-0.7.1.tar.bz2</param>
  </service>
  <service name="generator_qmake" />
</services>


It lists two services offered by my local build service, the “download_url” service is downloading the file from the server. This is important, because we can ensure via this mechanism that our tar balls are really comming from a certain server and are not repacked by someone.

The second service is a spec file generator. Unlike former attempts where people tried to write one general purpose generator, this one is high specialized, in the case for qmake files. In fact, it is acctually a hacked qmake, this avoids that we need implement our own .pro file parser and interpreter. This means it is way more easy to write a generator without the need of all the internal knowledge.

Last but not least there is a first library package, which maps link calls (eg -lqt) to package names. In this way the qmake generator can easily create proper BuildRequire lines.

All this stuff is available in svn and openSUSE:Tools:Devel project. If you like to write another source service, you may want to look into the obs-service packages there. They are for sure no master piece of computer sience yet, but they prove the concept. It should be relative easy to write

• svn/git checkout service
• md5 or gpg validator
• cmake base spec file generator
• specialized autoconf/automake code generators
• Java ant based code generator
• Perl cpan based code generator
• You have for sure another idea

I will for sure not work on all the other code generators and further stuff, so any help is highly welcome !

You can already install these services on your workstation and run them manually. No need for a running build service instance. I will play around with the qmake generator first and try to solve general open problems like

• Get License field set
• Getting RPM Groups handled somehow
• Survive desktop Category check better (most likely by fixing our menu config file, it seems not to be maintained since quite a while).
• Handle package splitting (esp. for library packages).
• Getting descriptions from package meta data.
• Improving the library link to package mapping.

But before, I will rewrite the bs_service daemon in a more secure way, so that we can actually deploy it on build.opensuse.org

So you see we are still at the beginning, I hope some of you join the development. It would be extremly powerfull, if we just need to throw a URL at the service to get packages in 90% of the cases

Most important about this release are the improvements in source handling. Submissions to foreign projects are possible now. That does mean that after two years of development, direct work on openSUSE distribution becomes possible, without bugzilla in between ! You see, we need sometimes a bit longer, but we keep our promises

The Build Service at http://build.opensuse.org is already running it, so it can be already used for submissions. You just need the current osc from openSUSE:Tools project.

When editing a package in openSUSE:Factory, you work usually on a branch of the maintainers project. In this way everybody can work close together with the official maintainers.

These mechanisms are usable via the osc command line client already. But the functionality is provided by the server, so I hope we can easily make the same functionality accessible in the other clients soon.

We have a wiki page describing the way how to use this.

There weill be still some rough edges in the functionality, but only practical usage will show them. A 1.1 release has been added to the roadmap, which can improve these use cases.

Please keep in mind that Factory is frozen atm to get 11.0 out of the door. So submissions will not get check in in the next week. But they can get already prepared

Installing the Ruby framework in matching release can be done as root user via:

# zypper sa http://download.opensuse.org/repositories/openSUSE:Tools/YOUR_DISTRO openSUSE:Tools
# zypper install rubygem-rails-2_0

Getting the source code is easy just by anonymous checkout from svn:

# svn co https://forgesvn1.novell.com/svn/opensuse/trunk/buildservice/

Running the web interface is really easy now just by running

# cd buildservice/src/webclient
# ruby script/server

This runs a local instance where you can connect with any web browser using http://0.0.0.0:3000/ URL. So there is no need to install a full build service, no database administration, just checkout and run it You can easily edit files esp. below the app/ directory and customize or improve the web interface for your needs.

Of course it is easy to get svn write access, if you provide a useful patch

Have fun.