 Hi there, I'm Christoph. I would like to greet you from the Outback of Munich in Germany, and I would like to talk about a tooling called UpDreepers, which might be useful for you if you need to get an overview about many UpDreepositories at the same time. Before we start, I will give you a short overview about the tooling and its background. I wrote the tool during my active time working for the city administration of Munich in the context of Lemux. If you don't know Lemux, it's the Linux distribution running in Munich. I'm not the right person to give you updates about the current political situation in Munich, but if you have questions, there should be some of the still active Lemux guys around on the DevCon, and I think it would be the best to ask them directly. Even though I'm currently no longer working for the city administration, I was a long time fellow of Lemux, starting with the project in 2005. After the success was finished of the project in 2012, there were about 13k PCs running on Linux, and Lemux was then continued in an operational phase and had about 15k PCs in its best time as far as I remember. In 2017, the former city council unfortunately decided to stop Lemux by the end of 2022, as far as I remember, and of course this was a very sad moment for us all in the team. Since it became clearer that Lemux team will shrink due to this decision, we reworked our deployment processes and its up-repository management and tried to simplify things to ensure that they can be handled with less people, and in this context up-repos was born. I'm very glad that I had the possibility to be part of the Lemux, and from my point of view, we should now concentrate on things that could be preserved from Lemux, and that's why I'm talking to you now. Up-repos is from my point of view one possible candidate for that, because it's a universal tool, and I know it because I'm still using it, and even in my new job with a completely different company now. If you are a distributor, a maintainer of a debiant-based Lemux distribution, then you would have to handle a lot of suites that are useful for you or that you use. For example, there are the upstream suites, because maybe you decided to not build every package by your own, but use upstream packages that are already available, and even the upstream suites come with main security updates and backboard suites, and there could be further PPAs and so on. Then, of course, there might be some business-specific third-party packages that you put into your distribution, and yes, custom packages that you build by your own are also there, and if you are doing, having a development process, then you might have got also some kind of development stages, for example, development, testing, and production stages. If you think about the deployment of your distribution, then in some points you might need some mirrors of things that you already deployed somewhere else. Just to visualize that a little bit, this could be one possible setup, main security updates, backboards from upstream repositories, then third-party repositories, and your three stages for the custom development, and yes, everything is one suite, one entity, and so we have got only for one distribution, eight entities that we want to track, and now if you think about that, it could be possible that our current distribution is not the only one, maybe we have got a previous distribution that we still have to maintain, and maybe also working on our next distribution that we are currently in development, and all these suites need to be tracked by you. So 24 entities in the end, how should we handle that? And if you have got a setup like that, then we might have got questions, for example, which suites do we have in our distribution? Just to get an overview, where is a single package, for example, Git, and in which version is it there, from which upstream repositories did we use a particular package, which update packages do we provide? So what we do here is just to list a complete suite. This is my mirror of Buster updates, for example, if we have got someone like that up to date, so we want to compare suites, and do we have got a change log for a particular repository, maybe if it is important for you to track things, how they develop in time. So how could we ask under these questions? This approach, one, yes, look at the up-to-repository structure that is provided by our repository, and there we can find some disk folder and some pool folder, and if we navigate through this structure, then we, in the end, find some packages, files, zip files, and we can unzip them and look at the list and see which packages are there. But this is not efficient enough, I think. Second approach is, since I am a distribution provider, I use tools, of course, for that, and maybe these are the tools that I had known in my past, for example, the Debian archive kit, aptly, rep repo, or also even depth mirror. All these tools are there, and we can use them and some of them can allow us to inspect the content of the repositories that we provide. But if I think about it, in all these cases, I have to be on the repository server itself. But why? Most of my repositories are open for everyone, and I just want to inspect them, and not only on the server, but anywhere. And I also would have to know different syntaxes and switches for how to use the tools, and so that's my question, why couldn't we just use the generic repository structure and work on that for the inspection of our many repositories? Okay, so here we get to the tooling app that you all know. Of course, we can do update to read packages lists that are in our sources list. We can do show policy search things like that that you all know very well. And do we really want to add our 24 suites that we want to track to our sources list of the local system? I think no. So that's why we thought about it and tried to find some solution that still uses the lib apt package library in the background. So we're using apt, but not the command line tool itself, but a different tool. And this is apt ripos now. So apt ripos is a tool that reads config files in JSON format that you can put somewhere and they generate suite names for selected suites that you're selecting at the moment. So and it's a temporary sources list generated here. And then we can also use commands like suites to get suites over few lists to get lists sources and show show things. It's a little bit similar to the apt command line here. Okay, let's go to the demo. My setup is I have got apt ripos installed. It's a devian package, very clear, I guess. Let's have a look at it. There's some config files put to etc apt ripos, there's some main pages there and a little bit documentation and of course the tooling itself. And if we call apt ripos now, then there are some sub commands and let's do suites, command suites. And now it's canning repositories that are configured in the etc config files. So what do I see? For a C for example, I know of you about some devian suites, devian stretch, buster, bull, balsai and also about some Ubuntu suites, trusty, bionic focal. And here in this section, we have got some suites that are added by myself. So I also put some config file to .config, apt ripos, my ripos. Here it is. So we can see, I just provide the URL of my repository, it's a devian mirror, the German one, and give some hints about the suites that I'm interested in. Don't want to deepen that very much. And what we see in this list is that we can also select different things. For example, minus s, the switch for selecting suites. I can select only devian suites, then I get only devian ones. But I can also select devian de suites from the German devian mirror. Here they are. And it is possible to add tags to different separate suites. So for example, this my distry, my distry. So if you think about I'm providing my own distribution, then I can tag some of the, for me, interesting suites with my distry. And I can search for them as well with my distry colon. So I get only the tagged ones selected. This was question one, I guess. Which suites do we have in our current distribution? So this is what we need to get an overview there. Let's go to question two. Where's Git and in which version do we have Git? Yes, of course. What we want to do now is we want to check for the devian repositories and see in which version we have Git there. So we can use apt-v-post-ls for list. We select some suites, the devian ones, and say we want to know about everything about Git. So what it's doing, it's checking about 12 suites because it recognized that we selected 12 suites and it's reading the packages lists like update would do. And then giving our list of packages in these suites. So we can see, I think, nice thing, the complete history about how Git involved in during the time between Stretch, Buster, and Palsai. Okay, let's go to question three. From which upstream repository did we import a particular package? And that's the case, Anacron. For example, it's very similar to the last check that we did. But what we do is, of course, we are searching for Anacron. In this case, we want to search all our suites and all suites are selected by the colon. So you can see that it's scanning the repositories first to get an overview about the suites contained there. And now it figured out that there are 31 suites that we need to check. And again, these list files for the suites are updated. And then in the end, a list of the Anacron packages is returned. And this sometimes needs a little bit of time. And the list files are also very large sometimes. It could be about a gigabyte ranges. But if you compare that to what you normally would have to do, then I think it's worth to do it in this way. So what do we see? We see a nice mix of Anacron. How it developed, involved in the different distributions. For example, trustee, stretch, bionic, buster. So it's a good mix of Debian and Ubuntu suites. And what we can see is here some interesting point, for example, that it seems that Ubuntu Bionic has taken the original Anacron package from Debian Stretch. At least if we just look at the version number. We could also have a look at the MD5 sums, but this is too much for me now in the moment. Okay, so let's go to question four. Which update packages do we provide? So we just want to list a complete suite. Upd, repos, list, ls, it's okay as well. What should we take? Let's take a focal Ubuntu focal updates. Seems to be a good list. So then we see our update packages. That's what we're questioned for. And we can select with a regular expression. So minus r stands for regular expression. And the simplest regular expression that matches all packages is just a dot. Let's do it. And we see there's a list of packages returned. Let's try to count them. Yes, 3,800 packages are there. And we can could also adjust the columns that we are showing there. Yes, let's go to question five. Is my mirror of Buster updates up to date? So we want to compare suites. If we have a look at our suites, repos suites, then we can see that there are two Buster updates suites contained. There's one with the Debian Buster updates from my mirror. And this is a German mirror. And the Debian Buster updates here. This is the main mirror. So let's try to compare these two suites. Up to repos, we do it by getting a list first and selecting our Debian Buster updates. And another one separated with comma. This one, Debian DeBuster updates. We're selecting all packages. So minus error dot is what we need here. And we can try to give us the list. So in the end, we get a list of packages from both suites. And you see it here. It's a nice mix of Debian Buster updates and Debian DeBuster updates packages. So now we see this column is a suite. And this is what is our differential argument here. So what we want to do is we want to get a diff over the suites. This is minus diff. And suites, this small s stands for suites. Some capitals and they are in the help messages contained so that you know what you're searching for. Let's do that. And it's already finished and the diff is already done. And it says that there's no differences at the moment. So it seems everything to be okay. So our repository is up to date. If we want to have a look what happens and need more detail or need a better overview about the diff, we could also use a different diff tool. And this could provide it with minus DT. And for example, let's use meld there. Then again, there are two lists generated for us. One for the Debian Buster updates suites and one for the Debian Buster DE Buster updates suites. And they are compared and yes, what we expect, we see no difference. All packages and all versions are the same. Okay, this was question number five, I guess. Let's go to question number six. Is there a change log for my custom repository? The answer is no, but you can easily build one using the Uptrepost tooling. For example, if you just do something like Uptrepost LS, which suite do we want to say it's our custom repository? Maybe the Debian DE Buster one and minus air dot. So this is again, what we already know. This is the list of our packages in Buster. And we could also try give it in a different format. Format is list and then we get a list. And if we redirect this list to Buster.list, then we can put this file into a Git repository and track what changes in this Git repository. This is also something that we really used very often in Unique. Okay, I think that's everything that I wanted to show here. I just summarized a little bit things together for you in the slides. So the questions and the others to the questions. Yes, so thank you very much for listening. I hope you enjoyed it and have fun at the conference. Bye.