 So my talk is about packaging the Osmo Comp stack for OpenSUSE. So creating RPM packages for RPM-based distribution. So my OpenSUSE, everybody has its own favorite distribution, minus OpenSUSE, and OpenSUSE had some great tools and great infrastructure in place, like the OBS. I will talk about later about this, OpenQA and Kiwi. It actually comes in two flavors. There's LEAP, which is the current stable and regular release. And there is a tumbleweed, which is a rolling release model. Then what does this talk about? The OpenBuild service, the OBS, which packages are currently available on OBS from the Osmo Comp stack and which challenges I encountered during my work. Why packaging at all? Because your developers and your users usually or often are not developers, and they do not want to work with source code, compiling stuff, and have often no clue about Linux systems. They just want to use the applications. And we all like to get super-installed or young install and packages for distributions make it more easy for your users to consume your applications. So OpenBuild system, formerly known as the OpenSUSE build system, is a build system that was written by SUSE employees for the internal build structure building the whole SUSE distribution. And what can it do for you? It can generate packages. You just need to write some spec files in case of RPM or if you have an RPM-based distribution, you have to feed it some DSC and control and rule files. And it supports multiple distributions and multiple architectures. And each package that you build there is a build in a clean change route environment, and it only has the dependencies installed that are absolutely necessary. And after successful building, it also takes care of publishing the packages in a consistent way in public-available repositories. OBS is also free software and licensed under the GPL. You can install it on your laptop or your own infrastructure, but most users just use the most popular OBS instance that's hosted by SUSE, and you can reach it via build.openSUSE.org. OBS has several user interfaces. One is the web UI, and it's great to have a quick overview of your projects and packages, but it's not really powerful. So most work you probably would do with the OSC command line client, and this OSC command line client works like a source control system like SVN or Git if you're familiar with it. And it also supports local builds for testing your stuff before you're submitted it back to the OBS server. So how does it look like? This is the web UI after your login. Here, can you see some project? In this case, it's the Osmo-com nightly project where every day a bunch of Osmo-com packages are checked in and built there for currently the Debian and Ubuntu distributions. It supports multiple architectures, and you can see if the last run has succeeded or failed or if there are any problems. If you dig deeper and look at the package level, you can see what files are in there. And in this case, this is the Osmo native package. You can see it's currently only packaged for Debian, at least for CIS repository. You have the Debian DSC file and some sources. And when it was checked in, who checked it in? And yeah, it's this. The web UI also provides you with a nice monitoring interfaces, so you have a matrix with the build result over all your packages. So like I said, it's modeled after some SVN or Git-like tools, so you can easily do some check out of some files, add and remove, and so on. Here's a more complete example where I check out the Osmo P-CAP, then I change to the directory, then I run some magic service. I talk in a bit about that, and I then created a test file, edited it via OSD, add and remove, and then committed it back to the build server. So this magic service you've seen here is one of those scripts that you can use to validate or generate or modify your sources. And you can run these services locally in your working check out copy or even directly on the OBS server. So as an example, you can look at the picture where I also took Osmo P-CAP. And besides the source code and, in this case, a spec file for generating the RPM stuff, there's also a service file. And within the service file, you can specify services like the TAR-SCM service, which allows you to check out code from source code repository. The major ones are all supported. And you just have to specify the source code repository URL diversion format. If you don't give a revision to default, it's master. And if you want to automatically create entries in the change log file from the version control, then there's another service you can change them up together that's compressed, downloaded source code to a tarbol, in this case, except compressed. And it also can set the diversion that you get from the tarbol, and in this case, the git revision. And you can set it in your spec file or in your DSC file. In case you have never seen an RPM spec file, this is how it looks like. It's not really complicated. I don't know if anybody is familiar with packaging for any distribution at all. You have an header. You have to give it a name, a version, a summary. Then where are your sources? What do you need to build the package? So you have to define all your build requires, description in the preparation section, your extracted tarbol. All the stuff that's prefix with a percentage sign are macros and replaced with some magic from RPM. You can look up that on the internet. There's plenty of information out there. And then you have a build section and install section. I also run the checks that are provided. And then you will specify the files that you want to be a part of the package. So which OsmoCom packages are currently available on OBS? Since some time, I think Kara started these package feeds. Packages for Debian and Ubuntu are available. There are two repositories. The first one is the OsmoCom network, OsmoCom latest repository, which holds all the latest tech releases of all OsmoCom cellular infrastructure software, or CNI. And the nightly feed contains the same packages, but that are the daily checked out master versions. So what's actually within the Susie distribution? There are already some common libraries from the OsmoCom project available thanks to various community contributors that have done that in the past, like LibOsmoNet, LibOsmoABS, SCCP, LibOsmoCore, of course, and so on. Then to that, I added some stuff, all stuff that I ever played with in the OsmoCom world, and packaged this in some way up in one of my home repositories. And this includes more or less all the cellular software, the client and the network side, several branches of the OsmoCom BB and a proper tool chain to build this OsmoCom BB firmware stuff. I also packaged more or less all OsmoCom SDR packages. I prepared a wiki page. It's not online yet. I have to decide or to discuss this with Harald Werder to put this in. But it's here that it's more or less modeled off. I took the page from segit.osmocom.org, and I linked all my packages that are available for Debian or for Open Susie on OBS and made links to them. And here, can you see what packages are available? I even once packaged all the stuff from Holger. I think not. More or less all that's worse packaging in some way. OK, back to my slides. And what else I did last year, I created two package feeds that are modeled after the Debian and the Bundu nightly and latest feeds. And those are also available for Susie, the current leap, the upcoming leap version for less the current and the last versions, and of course also for tumbleweed and several architectures. The daily packages are currently triggered from a cron shop from my personal machine. So this should be moved somewhere to the OsmoCom infrastructure. Yeah. So what are some challenges I encountered? Yeah, OBS is nice, and it supports multiple distributions. But if you have packages for Debian and RPM-based distributions, you will have to write your stuff multiple times. And if you want to provide your users a better experience, this should definitely be in sync. Because if you do not have this in sync, you are probably getting sooner or later complaints from your users that some things are not working the way it should or the way it's written in the manuals. And yeah, I listed some items that I think that are most important. These are package names, package descriptions, how you split up packages into sub-packages, compile time options. This is not so easy. And also the used sources. The used sources is also problematic because of multiple branches that may be out there. So as long as you're only packaging the master branches, this is no problem. But if you want more, then for all the distributions, like in this example, libdbi is not available in all the, or even in current, less distributions. It's less as the enterprise distribution from Susie. And it only contains 6,000 packages or so. OpenSusie has 16,000 packages. So they want to focus on the stuff they can support. In this case, when it's not available, you have to package it also up to have it ready as build dependency for the packages that need it. So another thing is if you are building or utilizing build.openSusie.org, normally it's only allowed to package up free software. So in case of, for example, GAPK, there are problematic codecs included, sir. I think normally they are downloaded from the internet and not part of the source code. I patched that. So it's part of my package to have it available on OBS because you cannot download things during the build. And you have to think about it if it's not more or better to move this package out of this repository away from build.openSusie.org and move it to another instance of OBS that maybe run by yourself or it's hosted by another host like Pacman. It's another popular OBS instance. And they are not so restricted about what's allowed there and whatnot. Another thing is how to deal with platform optimizations. Not everybody, not every user out there have advanced CPU instructions in one of their systems. And for example, in OpenSusie, you should maximally use SSE 4.1 and not the latest optimizations. Yeah. Like Folk or something like this, that would be perfect. And it's already supported by Libos Makor with RB decoder and by Osmo Turiks if I remember correctly. So feel free to use it. OK, perfect. Thanks. I think that in Osmo Turiks it's done at compile time, but I'm not sure I would need to check. But OK, yeah. By the way, there is a lib library from Google to detect CPU features at runtime. So we can also start to use it. It's probably called CPU features, yeah. OK, sounds like a good idea. So another thing when you're utilizing the build.openSusie.org or OBS Instance is that you have no download statistics. I'm not sure if it's really important for you to know how many users are out there using your software, but sometimes it may be interesting or not. Well, I think in the day of Docker files and other containers that download packages all the time from repositories, it's not really any indication whatsoever at all. Yeah, that's true. Let's assume we would look at the download statistics of our Debian packages. I'm sure our Titan tests are the primary downloader, because every time we build any of the containers for any of the programs, we download the packages from the nightly feed. So OK. So if you want to join the packaging effort, feel free to read up more. Yeah, and that's more or less to show you. My question is, why not merge? Or what's your thought about merging your non-Debian, non-Yubuntu spec file-based package feeds and the Debian-Yubuntu ones that we have? Good idea. And we should do this. It will take some time to do it in the right way. These source services could help, because there are source services that could extract a spec file from a Git. So the spec file does not have to be separately maintained in OBS. You can just extract it from Git. And as you've seen, you can set the diversion in the DSC. And the spec file with OBS services, it's a good idea. I just have to find some time to do this in a proper way. What I'm missing, basically, is when I'm working with OBS, I would like to have a really simple way how I can rebuild everything. So yes, I know there's local build. But for Osmo-com, usually we can't just local build one package, which has seven, six dependencies. How do you rebuild or debug issues if OBS can't build something? What we have right now that it can't build Osmo-MGW on non-64-bit architectures. And I have some scripts, but do you have a better or do you have a simple solution for such problems? No. OK. Thank you. OK, then thank you.