Not only SUSE Limited, also Mendriva, Fedora, Debian, Ubuntu. There are problems, obviously, and I wanted to focus on this area of the build service.

But I'm flexible. Who knows what the OpenSORC build service is? Okay, who has used it? Okay, some. Good. So, very brief part. What is the OpenSORC build service?

In the first place, it was suddenly needed when SUSE decided to make the OpenSORC distribution really a community distribution. Until then, for 10 years, SUSE was developed in-house. So, if you wanted to join the SUSE distribution development,

it would mean you need a local NIS account inside of the SUSE network and other limitations. We had quite automated builds at that point of time, but this obviously wouldn't work out with an OpenSORC development. The good thing is we had 10 years of experience and we learned a lot of mistakes we did during the 10 years.

So, when we started from scratch, we were able to avoid these mistakes. But we don't want it to limit us to develop only OpenSUSE. We wanted to make it really a platform, also interested for people who just want to offer packages

because our idea is if you can get the software out to us, to come to us, to build packages there, then we get automatically also the better distribution because the authors work already at our system and are connected best with our system.

So, we want to offer them something that you don't get elsewhere. And this is building also for Fedora, for instance. So, the idea is to have all sources, all stuff in one place, change it and you get packages for all distributions. And of course, to connect with existing infrastructure,

so you can in extreme case with each SVN commit, you can get a new package. See that your commit now broke something, for instance. The build service for this reason had very many phases.

The users are seeing it, then there are packages seeing it, only interesting in their single package. Then there are people like our release manager seeing it, when it's also building the entire distribution, so ESO images, FTP, HPs and so on.

ISVs are using it for creating add-on stuff. Live systems, so really, really pretty much different use cases for it. We use it at build OpenSUSE org, obviously. This is the place where the OpenSUSE distribution gets developed,

but where everybody can go also create an account and create packages for any distribution. So, build OpenSUSE org is also supporting Fedor Obunto and so on. Then we have at Novell an internal build service, which is building the enterprise products, so the same software is used, just installed a second time.

Novell plans to offer an ISV build service, hosted at Novell, but where every ISV can come and build packages for the enterprise platforms. Then there are plenty examples, where people simply use the build service at their side.

For instance, there is one guy currently trying to port the OpenSUSE to a Spark distribution, to a Spark architecture. So he is able to reinstall the build service in the same way that we have in our side and just recompile it for Spark and fix the Spark-specific things. Other companies are creating entire distribution as well with it.

For instance, Intel is creating Moblin with it. Cray is creating some kind of distribution. I do not know the details, actually. And many small ISVs, like OpenExchange, is providing a group via support.

They use the build OpenSUSE org, actually, for publishing their open source product and having build service in-house again for the commercial product. It is possible because really everything in build service is designed to be as open as possible, as open as we can.

The license itself is under GPL, the code itself. The API is very simple. It is a REST-based API, so if you can operate it with just HTTP operations, that means that you can easily integrate it into any toolchain you have. You can either call it from command line with a cURL option.

You can integrate it with your Java stack easily because it is just HTTP and HTTP is supported everywhere. And the build service itself is not limited to SUSE-based and not limited to package formats. Besides RPM, it supports also Debian or, for instance, Kiwi.

The image descriptions are also handled like a package format, so when you place a Kiwi file there, for the build service it is just another package and, okay, the result is an ISO image. One thing, one concept we have is a project model inside

and this project model gives very much power and very much flexibility. I just have one example here. The project organizes a space in the build service. It defines which people have write access there,

can submit packages there. They can organize themselves. You put the sources inside there and you add the description how you want to build them, for instance, for OpenSUSE, for Fedora, whatever, Mendriva. You can reuse different sources.

For instance, you say, okay, I want to do the kernel, but I want to kick out this patch, which is fine for an Oracle database, but it's bad for my multimedia stuff. So you can easily follow an existing source with a different patch set and every time the upstream kernel,

the upstream package gets updated, you get a re-spin of your own package with your changes. And the result in the end is always a repository with all the packages and people can just add it to their tool and install the packages from the repositories.

This is just one example how you could use it in real life. So there was at the time the KDE4 project. It consisted from multiple packages. They were compiled for different targets. Simple thing. The good thing is that you can reuse it.

So the Amaroq people wanted to build also a current Amaroq at that time, but they had the problem that the KDE4 was not part of any of the distributions. So they were not able to compile just the Amaroq against OpenSUSE 10.0, for instance. But what they can do, they can compile it against the KDE4 project,

which compiles against the OpenSUSE 10.2. So you can easily reuse existing sources and collaborate with them. Okay, that's the generic part. Now the specific part, if you create packages,

which should compile on different distributions, you have problems. One part of the problem is actually not that it's the age of the distribution. And that means an older distribution has a complete different API set usually because the old version of glibc is packaged. The old version of qt is packaged. So you don't have the API interfaces you may need.

Also, the GCC is changing over time and the newer versions suddenly complain about programming errors, which were always there, but in the former times, they were just not detected and now suddenly it aborts.

Or each distribution may have any QA scripts to check that the package is not doing something evil or require, for instance, something. Also, the policies of the distributions are developing over time and there have been changes. Then there are distribution specific things.

Manriever, for instance, has the lib64 rule that all library packages have to start with lib64 and this shouldn't happen on other distributions. So you have really a number of problems. And you can, of course, solve them or just ignore them.

There are some generic solutions. So LSB is a nice idea. So it standardizes the base set of libraries up to GTK-QT. But one of the problems is that it's a runtime standard. It's not for standardizing the build time.

So you have to deal with the build time problems also. The package name problems, for instance, there are packages which have the same content but different name on each platform. And you want sometimes exceptions in your build descriptions. You want to have a specialty for Fedora

or for Zuza to support something specific only existing on this platform. So we have some methods to support this. So as an example, the Kanalypse package, for instance, it's really named differently on really every distribution. And that would mean you need a spec file

saying build requires differently on each distribution. And that's a pain for a package. The point is, when we know such things, we can have substitute rules. They are stored inside of the projects and the base distributions like Zuza, Fedora, Mendri, Vowel,

the projects in the build service. So for instance, when we could add a substitute rule in the Fedora project that says Kanalypse is Kanalypse with capital C. Then the packager just submits his package build requires, for instance, in the way Zuza is writing it

and it gets mapped automatically on Fedora. The nice thing is you get also another source RPM which differs to the source RPM from Zuza which works on a Fedora actually. Other common problems are macros.

For instance, just example for the run-level scripts for starting services. Zuza has a standard, Mendri has a different standard. Fedora, another one, they actually don't use macros at all for some reason. Yeah, of course you could now do

specific versions for each distribution again but we define some default macros in the build service where we have the hope that we can push them upstream to RPM at some point of time so that's really a standard insight of RPM. Right now they are only defined in the build service but that means when you submit this

back file using these macros in the build service again you get the right expansion, the right macros for each distribution again. You don't need to handle this manually on your own in your spec file anymore. Then there are the exceptions. For instance, you want to do something special

when you build against a Zuza version older than 10.1. You can construct such things. This writing, it's even working if you use this spec file on any other system where Zuza version is not known. So it looks a bit ugly but it works pretty well in the end.

For instance, when you want to follow the Mendriva policy you can rename your spec file completely so the resulting package is completely different if you use this writing. But of course all this is too complicated. This is nice that you can interact.

It is nice that you have the power to do specialties and to use these special things but most authors frankly don't want to package. Most authors of software just want well, I do all the day hacking my C, C++ code.

I don't want to learn how to write spec files and I don't want to learn how to write Debian files. So there are many approaches to generate these spec files and so on automatically. There are several generic approaches. So one guy thinking he can rule the world

and automatically just trade spec files for any kind of packages and I was also one of these guys but we all failed basically because we don't have the inside of each software stack in the Linux environment. So then some people said,

okay, no problem. We asked the user, create a wizard and then another problem appeared and suddenly the wizard is so complicated that it's easier to write the spec file. Didn't work out. Then there are people who tried with scrap and guessing how from the source code maybe how it could be and how it could like

but the success rate that you get a working package of that is very low. Autospec was something from Matthias Kettner which I took over. It was nice to read when you want to learn Bash and what you can do with Bash. It tried to compile a tarball

with generated spec files multiple times and it learned about the failures and re-tried it. It worked also not out in the end. What works out actually are specific approaches. So for CPON there is already a spec file generator. GEM has one.

And this means the Autos there, these software stacks contain all the information you need to generate a spec file, a Debian description. So the information is there and it is a standard upstream. So the Autos really take care about this. And then you have a very high success rate to automatically generate working package descriptions.

Autos unfortunately very often ignore this because they use their CMake, they use their Autoconf, they use their QMake whatever

and they make it in this way that they can run the application. They use their IDE, they click on the button and there is some result, some tarball. That means on the other hand that most of the information you need to know to build a package is inside of this build environment.

Because in the build environment are informations like I link against library, against the Mesa library for instance. So when we know that there is a link against the Mesa library we can find out, okay the Mesa library for this

usually you need the Mesa-devil package. So we can map this. We can of course also do some guessing but the point here is really that we have a specific generator for this specific build environment

which is maybe CMake, QMake, whatever. And the point is that these generators if they are for this specific language they can be written in this language and they should be maintainable by the people who are working with this language

not by some single guy who has no clue about the software stack actually. So what we designed and where we have a prototype working at the moment is the QMake example. I picked QMake because it was a very, very complete,

there are no dependencies to outside and they generate applications not only for Linux but also for Windows and MacOS and so on. So at QMake you have a profile and it defines the files to install,

very important for the file list. The version of course and the libraries to link. And my generator reads this profile, asks the library mapper, OK, I see it links against Qt, then which package is it? And it generates back files and not yet DB and DC files.

But it is straightforward to generate this as well. The good thing is it's not much work to provide such a generator actually because there is something which reads profiles,

that's QMake. So what I did is just I used the QMake which is there, I added some lines of patches and a small worker script and I was done. That was done within an hour and I had a working generator just for the specific approach. And the good thing is when QMake is evolving

I can easily follow because it's just a patch against QMake. Except that I want to drop QMake now. But just to visualize it, it should work also with any other system.

So these plugins are designed in a way that they are packaged itself in the end. The good thing is that we can support it on the server side but it works in the same way also on your workstation. So you can develop it on your workstation, you can run it on your workstation, it's not limited to the build service.

It's really a generic approach. Duncan yesterday saw this slide for instance and he said, oh well, why do you write? It's not yet integrated and he just made a plugin based on the gem generator. There's a gem generator, or based on gem, he generates spec files.

And within an hour we already had support for Rails. So that's the reason why I hope it will work out in this way. I want to show it to you. This is a build service web interface.

There's also a command line interface and so on, but this is a web interface. Then a technical guy, me, implemented a web wizard. This is the reason why it looks so ugly and it's not ready for end users. So this is an instance actually running on my notebook. It's a build service I brought you here.

It's not online yet. So for instance, I can say I want photo wall. It's a QMake application. I just say, Marvell photo, that's my package. I need to paste the URL and at the moment you need to say which generator you use.

I hope that we can skip this in the future. It needs to know some descriptions, whatever. And it's done. And if this means in this way we can package most of the simple applications,

I'm quite happy in future. What it actually has done is writing a service file. So it's pretty generic. Again, it's just saying use two services. One is a download URL, plug-in, just downloading the file in the end

and there could be some verification plug-ins which don't exist yet. And in this case, a QMake generator. Just use it. The result is the table, of course, and the spec file. What you see here are missing implementations.

You see it knows about specialties in the distributions. For instance, Fedora has no dependency to C++ even when you install libqt-devil. But we can handle it here.

Fedora has a different way to call QMake than those has. But it's handled. It has some special macro to support translations in desktop files. OK, handled. And we have a number of files which get installed, which is documented in the profile.

So everything is there and we get actually a running build. So the build is already running because build service always starts the build when the source is changing or when the pending packages are changing. You could watch it here. Yeah, it sets up still the build environment.

So for each package, the build service is creating and for our M in the end, a complete new system to avoid that older builds influence the build and the build is really repeatable. So I think we don't wait until it's finished

but I promise you that this particular example really compiled successfully for SUSE and Fedora at least. Any questions to this generic, to this spec file generation or otherwise I would just tell you

where we are with the build service in general and where we want to hit.

Desirability, rather the possibility to generate multi-distribution package. Distributing package is not just putting a file to download somewhere. It's also to provide the final user some kind of guarantee that it will work on the target environment.

When I create and maintain package, I do it from on river. I imagine and I already had some remarks about user that do you wonderful package work under my own environment? I have no way to test and even if I had a way to do,

I won't make any effort for it. So my point is what's the advantage of providing package for distribution, you don't have any way or any desirability to change the work.

You mean it would be nicer to have one package which works, one RPM which works on all distributions? My point is I don't care if I work as a well as an environment I'm targeting myself.

Absolutely, but if you're not some developers, your goal should be to make it easier for distribution to package yourself, not to distribute it yourself. I think when we get the software artists to use this, they will see bugs in their build environment and fix it there hopefully.

So we don't need a patch in the package anymore. That would be the best way of course. What we also want to have in future is the QA system that we can test more and show also more problems. But on the other hand, we want of course to have a fast success for the people. So there should be a package,

how broken it would be. I mean there are examples where they enforce to install to user locally, ignoring everything else. If I may also add to Adrian's answer, the interfaces and the results of the build service are open. So for example, notification system

when packages are built. So we're talking to people like CMake and CTest so they could automatically download the packages, install them, run their test suites, run a UI testing tool like Squish to check that the software actually runs and installs and performs correctly.

In practice, the open source build servers won't be of that much interest to other distributions themselves, but rather for use for developers to test them on these distributions. Well, there are people who are building

Fidora and Ubuntu with the build service to adapt them for their own needs. Okay, so if you are a new distribution, you can get a consistent build service to host your build building?

Theoretically, yeah. Theoretically, yeah. And usually they install their own instance. Yeah, yeah. But you could also do it at open source. Yeah, yeah, because for some, it might be lack of resources in terms of hardware bandwidth or even, I mean,

or also different architectures. I don't know how we support more than just the two normal ones. The instance at open source is only offering the normal ones, 64-bit and 32-bit, but it works, of course, for all other architectures as well.

So the version internally, it's also for S390, Itanium. Okay, yeah, but do you offer those in the build service? In another build service instance, yes. Okay, so you can actually build multiple architectures on the build service. Yeah, oh, cool. So there's a guy, for instance,

porting the open source distribution to Spark at the moment, just by installing it at his place and just really using the remote connection of the build service because you can interconnect them on his side. So he automatically gets all the factory updates and rebuilds it on Spark hardware at his place. Maybe we should move our dead Spark port there.

Okay. My question was, you can build for other distributions,

but you have no way to test them, so how can you guarantee if it will work? But for me, a big advantage is I can build packages of my applications for other distributions and have users test them. I have users using other distributions

who would not want to do packaging, but who would just give it a try and test them for me, tell me if the package runs so I can put it on my download page? I mean, when it compiles, it can't be that broken, actually. Frankly, of course, that can be a runtime issue,

of course, and you can integrate QA tests automatically, but what we don't offer is a live instance where you can connect to something we just don't offer. I mean, there are other offers. I think SourceForge is offering this, and we simply see no point in offering remote login shells for people.

It's not in our focus, basically. That's a resource question because we want to use the same hardware better for building more packages. One more question. It might be a bit odd. I know this service works on Linux. Is there a possibility to make it work

with other canals like Open Solaris or BSDS? Well, we have currently supported for packaging formats, build descriptions format, Open Solaris is not yet supported, but you need basically to adapt to places to add another format.

So if someone is spending time in supporting or implementing the parser for the Open Solaris format, it could be easily extended. It's not necessarily about the packaging format, but rather the hosting, the kernel that runs the build. You mean at our place, at Open Solaris?

Well, in the first... In the instance, yes. Well, it's Perl and Ruby on Rails, so I don't see a reason why you shouldn't be able to run it there. And how about building the packages themselves, for example, Debian packages for Open Solaris?

That's the tricky part. Well, Debian is supported. The question is how much would this system differ to Debian? I mean, the different kernel shouldn't matter, at least if you don't use any virtualization at build time. The point is that we really build inside of Xen or KVM

for security reasons, but you can also use just change root. And for this instance, it would be simpler to use just change root, and as long as you have all your libraries and stuff as Debian package already somewhere, then it should work out of the box.

Okay, I would just inform you what we plan with the build service in general, besides these features. Yeah, right now everybody can come to build OpenSUSE Org

and SUSE, Mendriva, Fedora, Debian, Ubuntu is there and is building. You can install your own build service. We offer this release on Tuesday, also appliances now. It makes it much easier to install because build service is, I think, about 20 or 25 processes running in parallel. You need to set up Bails and Perl.

They are packages, but it's not automatically happening. So the appliance is really easy to start a build service on your own. What we work on at the moment is to improving the developer collaboration parts. We have started a review of this team.

So it makes it more transparent, especially for our OpenSUSE factory distribution, what is happening until I check in a new package or a change to a package gets accepted for it. So they are basically a legal and a source review,

and this should become transparent in the system. Also we want to add the maintenance support so that the patch RPMs and the extra needed meter files which are needed to do official maintenance updates for our official products get generated by it.

And a very big point is to redo the web interface. There is the OpenSUSE Booster team at the moment which is unhappy with the web interface as it is right now because it just shows a very limited feature set of the build service actually, and it could be much better.

So the next version will be a complete new web interface basically. Then we have an attribute system, a very flexible system to store any kind of extra information to package this project and so on. And it is used to add information and to integrate with external systems.

And the automatic source processing is what I was speaking about here. What we also want to do this year maybe or not is really to enable the trust system. There was a diploma thesis which was successful but it is not really accessible yet.

So we wanted to build a trust system about their projects and people get some rating and based on the changes in the package you know how much you can personally trust these packages because everybody can build a package so also every evil guy can come to the build service and you need to know about it.

The LSP conform builds as another target. It would be really nice to have. The point is that it is really hard work for the package to create a successful build against this target. But it should be there. Then we wanted to separate the QA tests

which are inside as a separate framework so that the difference if the package is failing because of a compile error or because of a QA failure so that you see it differently. And there are also ideas of people who want a non-Linux platform support.

Windows and MacOS are obviously the biggest targets. That depends if we find people who have time for this. The plan is there since we started the build service but so far no one really made a serious approach for that.

Yesterday the KDE on Windows people approached me and asked. So that actually might even happen now. I talked with them before. We should talk again maybe.

In general if you want anything to know about the developments we have a concept page, we have the feature tracker. You can also request own features there but given the limited resources of our site it is better you implement it yourself.

And we have of course the mailing list, the instance and the IRC channel where people get help for getting into the stuff. Any last questions? The software itself is complete GPL

and you just need to create an account. No money, nothing. Just create an account and submit your packages.

There is Jan Simon Merlo running around here. Not in this room. He worked on adding ARM support. And of course ARM is working when you natively compile on ARM hardware but that is not what you want because ARM hardware is most likely too slow.

But he extended our build script and so on so that you actually, with a very clever trick in the end, it uses QA mode to emulate an ARM but the compiler backend is running natively. So you have only 10% speed reduction

and you can very fast compile ARM packages. And you don't need to adapt your packages because it looks like a native build. So you don't need to deal with all the broken build environments or all kinds of packages which are just not designed to work cross-build. So he had pretty much success with that.

Any last questions? Okay, if you have any personal questions or want to see something I am at the Zuzu booth most of the time. So thank you very much.