These days some people from various teams spent a lot of time the last days discussing topics around L3. L3 means Level-3 support and is one of the services that we offer for our enterprise product series. It is about bugs which are not solvable through our support organisation but require developer eyes to stroll through source code.

What that has to do with openSUSE you might wonder. Well, since we’re currently working on switching our internal build process to a Buildservice based solution, L3 comes into play as well as other parts that are hardly visible for the community but important for the business.

L3 is a really tough game: Customers are paying money for the service and if they call they expect premium service quickly. Often enough enterprise operations are endangered by L3 bugs (or it is said that it is and clearification is needed quickly to relax the situation.

For the brave guys offering this service that means that they need to replay the customer situation quickly, debug, find the bug and if needed provide a fix for the customer.

The customer of course can tell more or less accurate which system he is running on which hardware. But than it’s getting rough for us: Finding the correct source for this constellation might sound easy, but if one adds up the amount of products that we maintain, it’s subflavours and service packs and also considers the lots of maintenance updates that the customer is expected to install, it becomes clearer that there are lots of possibilities and huge hard drives with content ;-).
Having found the correct source debugging (often together with the customer under time preasure), fixing and providing a fixed package begins.

L3 is an impressive bussiness for me, done by courageous guys.

Even more nice that the Buildservice helps a lot here because it makes at least building of debug info packages and fixes easy. A well thought through project structure in the Buildservice linked together with sourcelinks and aggregrations (which is a science for itself which one where eases (at least) the source organisation a lot. Other things also sound promising.

There is still some work to do until all peaces fit together but we are looking forward to helping the L3 collegues to improve their processes with the Buildservice and maybe some other tools.
I know, this is not exactly related to community questions but I thought it might be interesting to read about these things from time to time as well…

After two or three weeks of coding (not mine mostly, but by Marcus and Dirk), a lot of good stuff has accumulated in the osc development tree. Time to release a new package. It is a particularly good moment because today the 1.0 release of the Build Service has been announced.

The list of changes is long, the NEWS file has it all. Overview:

• version 0.105
• easier usage of osc submitreq: It is less picky on commandline arguments, can be called in working copies or project directories, figures out which build service instance to use, and has improved output. Also, there is a osc submitreq delete action now (which only works if you have write permissions on the destination though)
• osc search: added option -i|–involved, to show in which projects/packages a developer is involved
• osc importsrcpkg: no signature check anymore
• osc linkpac: –revision option added.
• osc copypac: use the correct userid when copying to another api host
• osc build: double check the buildinfo for local builds.
• osc buildhist: change the output into a format which better matches actual RPM filenames.
• osc commit: give commit message tempfiles a “.diff” suffix, so syntax highlighting automatically works in capable editors
• don’t expand/unexpand if the working copy has local modifications - this is a workaround for #399247 but this way the working copy isn’t screwed up. Also, make sure no _linkerror files end up in working copies.
• better error reporting in a whole number of cases, especially printing out more available detail. For instance, osc meta now prints out a concrete text why something you submitted was not accepted.

Have a lot of fun with it.

And just a note, remember that it is very easy to write osc plugins in order to extend or alter the functionality! Here’s the documentation.

As promised in my other blog about Hermes it grew up a bit since then. I was able to install it finally on the Buildservice production machines. Darix and Adrian helped me to get things underway. As the first process of the backend, the srcserver is notifying Hermes about things that happen: Commits to packages, udpates of packages etc.

Since starship is not yet in the shape that we really want to use it, we’re only offering RSS feeds so far, not yet personalized. Under the URL http://build.opensuse.org/feeds/allevents.rdf you find a RSS feed with all notifications the srcserver comes up with so far.

We realise that this feature is especially interesting for collaboration in general and especially for the new request stuff coming with the upcoming release 1.0. As a consequence we have created a feed that only contains the notifications about requests: Creation, change and deletion are reported to http://build.opensuse.org/feeds/requests.rdf

This is the first step with Hermes in production. Note that it is still beta and nothing one could expect proper functioning from. I am leaving to a two week vacation today and this is what I could still come up with before. Hope you enjoy it a bit - please give feedback, especially which notifications you would like to see coming through.

These are the areas where I would continue to work on after vacation if you don’t come up with other prios:

• Starship - Message displaying, configuration of notification subscriptions.
• Personalization - only show me notifications about projects where I am involved.
• More output agents - mail, jabber, personal RSS
• More usefull notifications, with help from the backend people

If you want to know more about Hermes find it in the infrastructure svn module (don’t miss the docu in the doc directory)

Tim and I updated the Amateur radio (hamradio) packages and made them ready for 11.0 .

Amateur radio (also Hamradio) is both a hobby and a service in which participants, called “hams”, use various types of radio communications equipment (also homebrew) to communicate with other radio amateurs for public service, recreation and self-training.

The repository is available at http://download.opensuse.org/repositories/hamradio/ .

You can also install single packages via the 1-click-Installer of the software-search-portal at http://software.opensuse.org/search or add the repository to YaST2/zypper.

YaST2:

Open the repository editor and add http://download.opensuse.org/repositories/hamradio/<your distribution version>

Example: http://download.opensuse.org/repositories/hamradio/openSUSE_11.0/

zypper:

10.1: zypper ar -r http://download.opensuse.org/repositories/hamradio/SUSE_Linux_10.1/hamradio.repo

10.2: zypper ar -r http://download.opensuse.org/repositories/hamradio/openSUSE_10.2/hamradio.repo

10.3: zypper ar -r http://download.opensuse.org/repositories/hamradio/openSUSE_10.3/hamradio.repo

11.0 zypper ar -r http://download.opensuse.org/repositories/hamradio/openSUSE_11.0/hamradio.repo

Here’s a list of available packages:

7plus
acfax
aldo
aprsd
as296-tty
ax25-apps
ax25-doc
ax25spyd
ax25-tools
axssh
axw3
baken
baycomepp
conlogv
cwdaemon
digi_ned
dpbox
dxc
fbbdoc
fbbsrv
fldigi
fltk
fpac
glfer
gmfsk
gnuradio
gpredict
gpsk31
gpsman
gpsmanshp
grig
HamFax
hamlib
hamlog
hf
ibp
kamplus
klog
kpsk
kptc
ktrack
libax25
libgdal
libgeos
libgeotiff
libhdf4
libproj4
linkt
linrad
minimuf
mtrack
multimon
node
qgrid
qrq
qsstv
rspfd
sdcc
shapelib
soundmodem
spandsp
splat
svxlink
tfkiss
tkconv
tlf
tnt
twpsk
unixcw
wxapt
xastir
xcall
xcircuit
xconvers
xdemorse
xdx
xfhell
xlog
xoscope
xsmc-calc
xwxapt
yfklog
z8530drv-utils

Thats > 80 packages in our repository.

I you find a bug you can report it HERE .

vy 73 es 55 de

DG7GT es DL9PF

some code was added to the buildservice backend already that generates Hermes notifications. That means that Hermes is getting closer, I will work this week to start a first test with Hermes on the production build service.

So let me introduce Hermes a bit.

Hermes is a system that helps it’s user to get back the decision about who is sending a message when and in which way. Using Hermes it is up to the user to decide if a message comes through at all, when and in which way. Hermes is going to be the central part of notifications in the openSUSE Buildservice.

Digest messages will be supported through Hermes. That means that messages (mostly automatically generated) of the same type coming regularly can be combined to one message combining all the bits. For example, imagine a notification about a package build fail. It might not make sense to send lets say 50 of them a day due to numerous rebuilds on different platforms that failed. It seems to be much more efficient to combine all these 50 to a digest message that lists all of the 50 fails. However, it’s users choice in Hermes.

The other important feature of Hermes is choice in the way of delivery. It is up to the user in which way the message comes through: Mail, RSS and jabber notification are already implemented in beta stadium, others may follow. It’s users choice based on the message type when and in which way the message is delivered.

The backend already has some code in it to notify Hermes. I hope I will be able to make let’s say some RSS feeds or mail running this week, especially for the submit requests. That would be another step into collaboration with the buildservice.

And since I seem to talk a lot about Hermes these days, Robert was cool enough to come up with a very cool logo for the (still little) Hermes. Do you like it? I think it is awesome - kind of 1960’s aircraft company

Thank you very much, Robert!

More about Hermes to follow…

We just released the Build Service 1.0 release candidate. The final release is expected in two weeks.

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.

(more…)

There is some work going on to put installation source creation functionality into kiwi.
At the moment kiwi can use prepared installation sources such as:

• BuildService Repositories
• mounted DVDs
• FTP trees

But what if you have a local Build Service building some binary only packages and you wish tp make a installable media set from, say, “SLES + binary only drivers”?
You can use the inter-BS-Connectivity feature to only build the drivers (and not the whole distribution) in your BS and then create an installation source from your main BS project.

This is possible since release of the package kiwi-instsource which extends the functionality of the config.xmlfile to allow the compilation of an installation source from scratch.
Hereby “scratch” means directories containing .rpm and .spm files. Of course some information must be provided for the metadata creation — but this is also all in the config file (with one known exception — the PDB data).

The rest is figuring out which packages must be on the installation source.
Since it is perfectly ok to have conflicting packages in instsources, there is no dependency check or package resolving in this stage. The information must come from the user.

Therefore the package list may become rather long and I already plan to implement some simplification.
These plans include:

• allowing more than one <repopackages> section
• implement outsourcing blocks in separate files using XML functionality

Out of total insanity I promised Adrian a couple of weeks ago to test local installation of the OBS build service and interconnect it with the build.opensuse.org instance. Last night I couldn’t sleep due to the heat, so I finally did. Half an hour later, everything was installed and set up correctly according to the README.SETUP instructions in the obs-server package. I’ve fixed a couple of small issues in the README while doing so.

This morning, Michael Schroeder fixed the remaining bugs in the scheduler so that it actually runs. And now it builds

Source and binary interconnects work fine, so I can e.g. branch a package that is somewhere in the openSUSE buildservice (some KDE:KDE4: package or even openSUSE:Factory) and modify it locally in a test project, and watch the resulting build failures. There are some smaller issues with “osc linkpac” and “osc branch”, but editing the _link  files directly works.This way one can do experimental changes to packaging without actually breaking the repository for all other users, or slow down the build power ressources for everybody else due to unnecessary rebuilds.

As a test case, I’ve imported KDE 4.0.5 packages into a local branch of KDE:KDE4:STABLE:Desktop for testing. More seems possible, like for example doing a daily rebuild of the KDE 4.

Really cool stuff. Buildservice guys, keep rocking!

Recently, I wanted to show how the buildservice makes packaging easier by creating a specfile template for you (just click the “Create RPM SPEC file templat” checkbox when creating a new package). Unfortunatelly, the template it creates is not really useful for someone not skilled in writing spec files. Also, it’s just a static template, so you have to write the summary and description even though you have just entered both in the web form. Definitely nothing to show off to newbies ;-). But knowing that the buildservice developers have more important stuff to do, and wanting to learn something new, I decided give it a try and fix it myself.

My idea is: The buildservice api asks a set of questions, which are presented by the client (webclient, osc, …) to the user, and creates a specfile based on these questions. Also, the api tries to suggest good defaults where possible. After spending some time learning ruby, rails and the api code, I have an ugly 200 line patch to the api that generates a working specfile for GNU hello ;-).

The user interface part is not yet done, but should be easy. What’s more chalenging is adding heuristics to “do the right thing”: detecting the build system (autotools, cmake, Makefile.PL, etc), detecting build dependencies, and so on. Right now, it only extracts the version number from the tar name.

Collaboration is not always an easy thing: Talking, meetings, making decisions and finding compromises. Sometimes I have the impression that some people in our business find this inter personal activities very exhausting and thus prefer to work on their own. Depending on how genius one is that works far. But for obvious reasons working alone has limits. If we talk about a whole Linux distribution for example one can not succeed: The working power, creativity and time of one is not enough.

That is one reason why we consider it as one of the keys for success that the Build Service enables people to work together in a useful and non annoying way. We think of tools in the Build Service which help. That is difficult because some formalism and guidance (in business often called ‘process’) is needed to keep things going in a transparent and reproduceable way. Control should stay there where it needs to be, for example at the maintainer of a project. On the other hand collaboration tools should not constrict people and their working together.

Here is a little story of Karl who wants to change something in the openSUSE Factory project. He needs to work with the Factory maintainers and this is how that is planned for the future:

Karl, a developer working for a small software company, loves openSUSE but not really the one package Kabax because there is a packaging problem Karl has analyzed.

Karl wants to change that to make sure that the next version of openSUSE contains a good version of Kabax.

For that, a branch of Kabax in Factory is needed where the fixes can be put in, built and tested. Karl uses osc to create a branch. The package is not really maintained in Factory itself, because the few Factory maintainers can not care about all packages there. Kabax has a Devel Project entry in its meta data that points to the project where it is actually maintained by the expert Karsten.

Because of the devel project, osc branches not really from the Factory package but from the development project where the development happens by Karsten. That might be different from the Factory package, but is clearly the development version that soon will be synced to Factory. When that happens is up to Karsten and the maintainers of Factory.

In the branch Karl starts to work on Kabax and creates a beautiful patch. Since his branch package also lives on the Build Service, it builds live for all relevant repos and along the changes of the devel project.

Once Karl is happy with his work he raises the attention of Karsten on his change by creating a submit request. A request in general informs others of something somebody else has done which requires action. In the case of the submit request it tells Karsten that there is a valuable change to his package that should make it’s way to Factory. Karsten now accepts the request and Karls contribution is in.

The nice thing about all this is also that the branch packages as well as the requests are open and visible to everybody who is interested in. That gives us the transparency we need. And of course that does not only work for Factory but for all projects if one wants to change something on a package where he/she does not have permissions yet.

How do you like this story?