 What we wanted to do now is doing some best practices for the service showing how people are working I'll show you some examples I can simply show you existing projects and how they work Ultimately, we can also package something you want to have packaged Or you fail it or you just wonder how to do it best Does anyone have an issue? A special setup you want to? I don't know Deviant sources now want to make up the ads out of them Okay Actually, there's an expert that forced them about that, but it's not Grunin Stefan Poulou who is not here at the moment, Stefan and with Michael Nutz wrote a script which converted automatically all Deviant sources and created spec files from them I can show you this Yeah, Stefan did try to import all many sources out of Deviant with Pository and built in the build service and maybe that ended up in complete flooding of the build service for some days but most of the stuff finally built and was available for long-long and the question is if the software really worked we never tested that of course because there were thousands of packages We tested multiple packages and the packages which do work nicely and which are now linked over to another project so they get really officially released but upstream is deviant but the build for open zoos are not about the SAPM package Okay, this is the local page We use a novell account there that means one has to create an account under novell.com and use afterwards a column on the build service This is something to change we are currently discussing and probably change to an open idea account in the future or make it also possible to use an open idea account The first one can always take a while but afterwards it's now really fast because we moved the front-end servers the first one in which drive one has So the deviant project I wanted to show is there you can go to the list of all projects Is there a good part of deviant already? No What we have is the port project I believe So we have here the local project and please excuse that this page takes a long to load because it loads 30,000 packages So it's really a large project but the good thing is it does not hazard all the other users anymore because if something else is to load then we prefer anything else just when the source is boring then it does put a complete deviant distribution And your example of the tools to convert the deviant description for the spec files are part of the tools project So this is the port deviant-based tools and here you find the dev to use a converter So you can simply try it I'm not sure about the current state but it will be invisible at any time in this window but most of the packages at least compile now automatically, it's not done anything manually so it's big for this Okay Does anyone else have a special thing that he wants to do? Is there a way of converting as soon as you have the API yet or not? So I'm doing the reverse So the reverse thing is not a regimented head file but I mean in the end the deviant and API works not that different They have file lists, they have tree and post scripts deviant has help-up tools So the trick here was that they use deviant help-up tools also on the zoos system They fix them and work with them So when you install this converted RPM it calls in the end the deviant help-up and installs the system like when you install this deviant on the recompiled against the zoos libraries on the zoos system and when it means that we are able to build the majority of the packages that means all the packages are reused to build the others So for instance a case review needs to take a list from the deviant except they have left it to the zoos ones but it means at least the installation of all the packages to work also and all others wouldn't be built Do you have seen such a web interface already? Or should I explain something to the project and the web pages? I think I should No one else has seen this So this is a classic project page What you see here is first of all this is the name of the project This is more or less a key It's not really important but I'll explain a bit about it Then we have a list of packages in the middle These are the source packages which are within the project and maintained Very important on the left you see there are two maintainers So inside of this project only two people can directly change something One is Richard Bünder and one is Stefan Kulu and they build all these packages multiple times One for open to the 10.2 one for open to the 10.3 and one for open to the factory factories are up to the distribution again So we see here already for 10.2 five packages succeeded, nothing failed In this case four packages for factory four packages built, one failed Now it would be interesting to find out why it failed So you can go to the monitor build status so you can get a fast overview Actually for me it's always way faster Whether it's a network here or I blame the network here So it doesn't behave like this Please watch it What you will see here is a matrix in the end You can click on the failed packages there and what you will get is a log file You can exactly see what happens wrong When it's hard to do a workshop if the server is hardly reachable Okay, I'll try something else Instead these are the basic projects It's just a project which has some packages and these packages get built and we have some result The whole thing becomes more interesting when you reuse existing sources What you can do is look for work in other repositories but build it in a different way One example is the KDE Backport project The interesting thing there is that it takes the latest sources we have in our distribution into the factory of KDE applications but compiles again for older user releases The advantage of this is that users who have open to the 10.3 or open to the 10.2 can install the latest versions on their system It's compiled against their libraries so there are no binary conflicts or they need to add further libraries and so on but it would be the case if they take the package directly from factory And for the packages, the great thing is they set it up once We are creating such a source link I'll show you some and they never ever need to touch it again The system discovers when, for instance, a new KDE application gets submitted to open to the factory our upstream distribution and it does automatically rebuild it for all the older distribution thanks to this project setup So it's a one-time work never look back again Of course, it can fail and you can look inside if you want to make fixes for older distributions as well So you see here it's really a long list of packages that are collected You see, we built for users enterprise Open to the 10.2, 10.3, 10.1 10.1 Fastdown somewhere I really promise This K3B package and usually in this package are the sources Here are the files You can see that these are the sources of the package and you see there are actually no files just the link file and the link file takes the sources from the factory project and takes the K3B So this file is a static file which needs never to get touched again The next step is not just to reuse exactly the same sources but to modify them I'll show you another example for that and even so one of our kernel developers not all his fishes succeed and not all his patches he would like to see in our kernel come in but no problem he trades his own kernel based on the suze kernel So this is a very similar setup like the KDZ project that contains just a link to the kernel that we have in open to the factory so he has a number of packages again in this site here and he builds it also for the deviant people besides suze but what's become interesting is that besides the link he has additional files here these files okay it works in this way it takes first the original sources he specified namely the kernel sources from the default kernel project and then it adds these files in addition to them what you can do and this file is by the way so this is a patch and after these files has been added the system applies this div to the directory when you look into the file there's a serious one which comes with the kernel which specifies which patches gets applied to our kernel and he modifies this file to get further patches applied you can do the same with spec files for instance so when you want to compile a package in a different way if you want to add some flex in the spec file you can use such a sourcing in the same way so sometimes it's easier just to apply a macro there's a special link in the link file format to add macros so that you have a one spec file and you have some if macro defines and z for instance debugging or enable experimental stuff and then you can just just specify this macro in this link file so this is since it's a notebook I was not prepared to work on I have to act now again as a user the user can go to OpenUser.org to the software.OpenUser.org and I want to show you the command line client and the command line client needs to be installed first so I act as a usual user here I'm sorry for that so the software OpenUser.org where you usually can download our OpenUser releases but also there's also an interface for additional build service depositories where you can search for all the stuff which is inside and in addition to that it features the one click installation provided by VentiWind so it's really easy for you to install software in a mile you don't need to figure out which depository apps are depository except configures a GPGT and all this stuff it's one click it starts just that you can select something and I look for OSC OSC is our command line client OSC 10.3 so here we see there's already a version of OpenUser 10.3 but we want to have the latest and the most straightest start which is yes it's this link it's usually green button on the right side okay I don't wait for that and this is the one click file it gets generated on the fly when the user just click on a file here and this starts a yasmin which tells you what it needs to do in this case it needs to add another depository namely the tools for OpenUser 10.3 and it would install one package OSC advanced as usual because any package installation can be evil what's also possible with this mechanism is when you want to install not only a single package but you want to define a set of packages for the users I can show you an example they have in the case of Digicam it's nice to have Digicam installed it's a nice application but actually and of course when Digicam needs a library this library gets installed also because yasmin dependency is so low but most likely in most cases you don't not only want to have the Digicam package but also the that's a keeping plug-ins and all the stuff that makes Digicam nice and in this case the project has defined a pattern a pattern is a list of packages in the end and from these patterns they are defined once and the build service uses the built-ins and generates for each defined target the depository thing the YMP file which are used for the one-click installation so again you may maintain one file and you get generated the proper YMP file for multiple distributions out that you need to go on it so then better for the other installation ok this is the other installation this tells me there is a new repo and you each project has a own GBG key this is important because per label there are people who have right access so if you add one label and trust them that does not mean that you need that you trust any other depositories so because one evil guy in the build service not everybody should be able to compromise your system so therefore you need to accept this GBG key Will I have a question which GBG key ring does it modify when you change that it's it's a usual RPM GBG key ring RPM has a known GBG ring and it gets added there as a distribution key ring where? the question is what does it help you? you can you can trust you can check the key because the key is signed with the global build service key so you can verify that if it's really signed with that apart from that it's more important that you check it would be more important that you check who has access to this project at all because this is really critical to the side if you trust these people or not if there is somebody in the project where you say no I don't trust them then you shouldn't install it and therefore we need a system this is not really possible at the moment I mean you can go manually to the build service check there's a list but it doesn't help you as a end user so therefore we desperately need a system where we can guide the users we can explain how much trust is in an abstract way that is this process of installation was successful I just start but I for presentation just to show the difference oh I see it the DNS resolution has taken 5 seconds okay I see it if you check open a new console so we'll see our command line console I just want to show you I want to see the first time for instance to check out my home this is what you get by default when you create a new account it asks me my account name and my password it stores it on the hard disk like SVN or CVS is doing as well I mean there are some complaints that we do store the password but you don't want to type it again and on every action you do is always see it but not too much I think and it's the same procedure as SVN or CVS it's working so of course OSC is also using the network it's as fast as the depth interface at the moment okay but now you see it's output already is similar to what you see with SVN you see the new file downloads my project I think I bought it after the first package and this became significantly faster last week actually because we improved our server infrastructure so usually it would be done already yeah it's how to better working for an affair as tumbling thousands of people in here so I'm here this is an exit package what I can do here is looking the result this is similar to what we have on the monitor page we have not seen yet because it's loading most likely okay so in this case it's a perfect package everything is built just for demonstration I had some bugs this is the build requires line is the list of packages which are needed instead of building time this is important because for each package build we set up a complete new system this is really required to guarantee that it's built so composable and also because theoretically any package could harm the system already so if there was once a package installed which harms the system you suddenly have a different system and you wonder why suddenly your package build does not work anymore so it couldn't be reproducible and of course because multiple people from multiple projects building on the same build costs we need to reset of it because we do not want that person A from project A is doing something which has an effect on project B there's a default set of packages which gets installed it's an absolute minimal system anything else needs to be specified as you see there's by default not even a compiler installed so we need to specify the devil packages needs to be specified and so on the good thing is that again the dependencies follow up so when you want to compile a KDE application you have to add KDE lips devil because all KDE all necessary dependencies for that are required by KDE lips devil so it's really easy to add something here but it does not exist so this is my change you see it works as SCN or not don't wait for now I check in so it uploads now the spec file because it's the only spec file I have modified generally we have what you would see is that it wouldn't try to start when we build but then suddenly discover that it actually can't because it does not exist surprisingly so we have the pageon error we call it here what we can do is for instance it does not exist it might be just the name of a package which does actually exist but under different names because some distribution has a different name for another one usually you map these automatically but it might be because that I have another packaging inside of my own project which costs this what I can do now is I edit the project config of my own project I show you an existing one open-loser 10.0.2 for instance so the project config is a config for a project which defines basic setups this is a really long project configuration it needs to have a project configuration which defines the basic setup and usually in some cases you don't need to touch it but you can, you have every option that you can modify your project config and just set up your own system as well as it's done in the basic system how you can provide the basic system I do not want to go into detail but the first line is the RPM config the jump meta data the input data the output and VNT files the good of course also add other types, you'll like the former former to get the future meta data you can get the final devian meta data this is a really long setup for the initial build system and especially for old distributions of old distributions which are not built in the build service they are backfixed inside because packages are old open-loser distributions they are quite broken actually but also from distributions are broken to some degree because packages do not require something what they do but they don't work all this kind of stuff can be fixed in this configuration we can also ignore dependencies because it would lead to cycles for instance or it would just slow down the build but it's actually not necessary so we can overwrite RPM dependencies here and this is an interesting part these are substitutes so these are definitions of packages which does exist in this project with a different name so what you read here is lift-open-ssl-level that exists here in open-ssl-level so when there is a filtrate file lift-open-ssl-level it will get changed in the beginning of the startup to open-ssl-level the nice thing about this is you have one spec file to maintain but you get source rpms for 10.3, 10.2 and so on and these contain the modifications for the target distribution that means the source rpms are available for users again to get automatically you have to fix spec files inside of them good question can you use this to map package names to different distributions because right now exactly the ifs inside of this so I want to say this is package x but on Fedora it's this and this is exactly what we are doing when you want to see this what we are doing you can go to the Fedora solution looking at this okay so it's done it's done on the metadata for the project so does this apply to my pack can I edit these at my package level or is this a distribution you can apply this to your project but actually this you don't need anymore because when you build against this project you get them for free you can edit when we have lacking something here or you want to test something you can edit in your project you should add this and then everybody gets this change so what you see all of Fedora is all of Fedora for instance so all of this work is taking away from you question is this specified in terms of this user names or also in terms of all of the other distributions names this is the case by case decision we need to avoid cycles so we cannot be careful that we don't map it while it's frozen the long goal should be that we define standards in the long run for instance the J-package people agree to define Java Devil and Java Devil should be mapped to a product thing that we all need is Java packages independent if it's GCJ IST and Java whatever so but it's a case by case decision which one this is a project conflict this is documented but I would recommend to look into the existing context you learn more and what I can do just to show it this I can edit my own so when I do it in my own project I suppose it's empty maybe not it's empty and I can add or replace any rule which exists so if I want to substitute I substitute so it does not exist and I leave I add nothing behind it means it does remove it that means I have to type over substitute substitute what what is it ah sorry substitute so what substitute substitute so yes substitute substitute substitute substitute but that's what it's okay no one I don't need this ah okay our basis to next curve okay I cannot so I'm to stupid okay what I'm to stupid officially and in this case I don't understand it what I do now is I add a dash h to get the server answer so he explains it does not exist he does hopefully explain to me is that your actual name what you have a low case use for your project no no I'm just but when I'm to stupid ah that yes I do it from technically ignore okay does not exist this is really better okay now it works okay and you see it does build again even though I have a spec file which is broken of course usually I should not add anything else I will be there tomorrow the whole day on the loose and I can look into your packages and your personal problems okay thank you