 So hello guys and as was said I will be talking about automation of rebasing of RPM packages with rebase helper. So just a question of curiosity who here maintains a package an RPM package? Okay it's nice to see a lot of you. So you probably know that rebasing your packages is quite a demanding task. It can take a long time there are many steps that you have to do and it can often fail which results in you having to do these tasks and steps again. So the goal of rebase helper is to automate these tasks as much as possible and if these tasks cannot be automated the goal is to provide information and provide assistance to the maintainer so we can do the rebase correctly. Rebase helper operates on a directory with a spec file. The directory can also contain patches and sources so this would typically be or clone this repository. And as I said it can do automatically many things which I will show you in the demo. It has many command line options so you can basically influence the whole rebase process so you can change for example the build tool that is used to create RPM or source RPM. I will show more of this later. And also rebase helper is package in Fedora so you can easily install it and it can also be run in a container for those container enthusiasts. And well because I think that examples are better than plain words and instead of just talking about what rebase helper can actually do I am going to try to show you what it can actually do and if anyone was interested there is a list of packages that I'm going to show you the basis of so you can later try it out. Just a quick note before I start some of these rebases take a long time because there are long builds so I'm going to show the most important steps and then just skip the build and show you the result. Okay so as the first package I've prepared a simple one which is called lip pipeline and basically it is just a simple package we can have a look at the spec file there is just a simple preamble and the build process is quite simple so rebasing of the package should be quite a simple task it should be just a matter of bumping the version and then adding a change lock entry. So there are no patches as you could have seen and this gripo is very simple. So let's just run the base helper now and see what happens. Because I run the base helper without any argument it automatically tries to oh I'm not going to the Wi-Fi so I have to log in. Oh nice. It's too short so I'm going to log in that's going to be faster. So I'm going to restart it and because I didn't provide any arguments. Okay it's running so I didn't provide any argument so either in the version here to determine the latest obscene version which it is going to rebase to. So in this case you determine the latest obscene version to be 152. There are many more tools aside from Anita so it can also fetch the latest obscene version from PyPy or NPM and as you can see then it runs spec hooks. Those are special tools that modify the spec file so that the build can pass. For example we can see replace old version which basically aims to replace hardcoded parts of the old version to the new version or replace it with a version macro so the builds can pass because without replacing it for example in the source it obviously wouldn't work correctly. Then sources are downloaded so you can see it started downloading sources. This is the old source so it is downloaded from Lucasitecache and then the new source is downloaded from the source URL. Then license check is run to check for license changes. You can obviously disable this check and there are many more checks I will talk about them a bit later. So this is going to take some time I think it will be in a second finished so just give it a moment. Okay and now as you can see Gidribase operation started because there weren't any patches so there was basically nothing to do. In the process the sources are extracted so first old version sources are extracted then new version sources are extracted and the patches are applied to the old sources. Then Gidribase is used to rebase the commits on to the new version and as you could see in the spec file there were no patches so basically there is nothing that could go wrong with the rebase. Then source RPMs are built first the old one then the new one and the same goes for new RPMs. By default rebase helper builds the packages using mock so this is what I'm using here but as I said you could also use RPM build or you could use some of the remote build tools such as Koji or Copper. This is going to finish in a bit so let's just give it a moment. While we are waiting I'm going to there is a question. So the question was is it built in locally in the repository or what did you mean? Okay so it creates a workspace directory in which it builds the packages. As you could see it fetched the sources and then it just used mock to build the packages. Okay so then the build finished successfully so it could go to checks so with an ABI package diff, package diff, RPN diff and so on. Then there is a short summary of the whole rebase where you can find information about where you can find basically more information about the rebase. So let's have a look at what rebase helper produced. So we can see that the sources were downloaded. We can see two tables and then there is the rebase helper results directory which contains all the results. So let's have a look at it and there is the report TXT. The report contains the whole summary what happened so we can see if there were ABI changes it would be listed here. If there were any patches it would also be here and there are also lists of files created etc. You could also create the report as JSON so that you could further process it. Then there is the changes of patch which contains the patch of the report that you can apply. So we can see that in this case as I said it was just a case of simply bumping the version, changing the res and adding a new change log entry. In other cases there could be some more modifications to the spec file or to the patches but in this case there were no patches so we're nothing to worry about. Then there is the rebase sources repository which as the name suggests contains rebase sources. So this is basically the copy of the disk repository and modifications are done here so the patch is then generated between the original disk repository and this rebase sources repository. Then there are the old build and new build directories which contain the build data so there are the created RPMs, source RPMs and also the locks. And then there are checkers so as I said as I showed a suite of checks is ran which aim to help you determine whether the rebase went correctly and whether there are any errors in the packages. So we can have a look for example at package diff. There is the full output of the package different package different time so we can have a look at for example the report so there is a list of the changes. Okay so this was it for the initial rebase where I just showed you what rebase output produces and how it works so let's now get to a more difficult rebase so this is going to be rebase of flipjpeg turbo. Let's have a look at the spec file as you can see there are already some patches so in the spec file they are also listed and let's have a look at prep we can see that they are applied normally without auto setup. So let's run the base over here this time I'm going to specify the version so I can just put it in as the argument this is going to be 202 and it's going to be based to this version. You could also provide a tar ball for the version so okay the Wi-Fi is quite slow so it may take some time. I just hope it finishes quite quickly or perhaps to speed things up I've already prepared the resources so I can have a look at that so let's go here and I will run it once again when the sources are already present rebase over doesn't redownload them because they would be pointless and also this time I'm going to disable some of the checks to make it a bit quicker so I'm going to just run package diff okay so as you can see when diff came up because there was a merge conflict during the git rebase operation so rebase oper used git merge tool to bring up the merge tool this is quite a simple conflict so let's have a look there is just one problem so I'm going to fix it and it should be all yes that's all so let's close it and let's look at the output so we can see that all the patches were applied to the old sources in the order that they were given and then rebase helper used git rebase to rebase the commits and as you can see it failed to auto merge the patch and a merge conflict occurred and we can see that rebase oper also we want to continue if there were any unedited hunks that were still left to solve it would also warn us so we could continue with fixing the merge conflict so let's continue for now and rebase oper is going to be building I hope just that it's going to finish quite quickly in the meantime I can show something else and get back to this a bit later I hope so let's jump out and I'm going to show you another result because this is just one rebase of the package and let's have a look at the other one I did two of them this this one was from version 203 to 204 and something interesting other than a merge conflict occurred so it was an auto merge let's have a look at the result and changes specifically so we can see that there is there are some changes in the patches because the source is changed and the lines have to be altered as well because well it would otherwise the patch wouldn't correspond correctly this is just this is just a advantage of using it for this I just hope oh it hasn't finished yet the problem here is that I had to prepare the results but I overloaded because I used the downloaded due to the I use the downloaded sources due to the slow Wi-Fi and my rebase of results directory that I had prepared had to been overridden by you new one so I think this is this is going to finish in a few minutes so I'm going to just let it run and show the results a bit later but for now I'm going to show another example which I've prepared and there is rebasing of example package no this is not the one okay so this is the example package as you can see the build went correctly we can see that the new RPMs finished successfully and the checks were ran and the rebaser wants us that there are some name changes because there is obviously a problem for a new backing for a base if some entries occur the maintainer should be warned so let's have a look at a more detailed output to see what's happening we can have a look at the report to get a better idea and we can see that in the package example same change from lip example SO3 to lip example SO8 so the maintainer could act on this report and he's aware so there is a good thing we could also have a look at the output of checkers here so ABI package dip was ran if you were interested we could have a look at the report of ABI but there are obviously no ABI changes so nothing nothing really wrong except for the SO name change and this isn't finished yet but the new build is already on the way so it should be very soon and let's jump into another example okay it's running package diff so I will just finish one more example and then get back to the rebase with merge conflict okay so in this example you can see that the new build failed but we implemented build log analyzers that aim to try to fix trivial problems and change the spec file so that the build passes so in this case it was an error of file section so there were some files missing and rebase help determine this and edit the files so we can see that a lot of files were added obviously in this case the maintainer would probably probably have to modify it because you can see that the pass could be somehow made easier using wild cards so there are a lot of paths edit but in the end you can see that I restarted the build and it built the RPMs again and then the build passed so let's have a look at the diff and if you look at the page a lot of files were added to the spec file which obviously the maintainer would many will have to check whether that is correct but the build passed and that's a good thing obviously so let's now get back to the rebase with merge conflict as you can see rebase open inform us here that there is a page modified and also that that some patches were deleted we can have a look at the results it is also mentioned in the report so there is a short legend and we can see two patches were deleted one page was modified if we now have a look at changes there are two deleted patches this is the first one this is the second one and then there are the changes in the spec file this is the modified one and then there is the spec file so we can see again version bump or erase update and these two patches were removed and they were also removed from the from the back section and changed look and trade it okay so now let's have a look at some of the some other options so the package maintainers here in the audience have probably seen bugs us like these where it tells you that there is a new upstream release of a package so I just picked a random one that is quite recent and you would obviously if you don't have the disk it cloned already you would have to clone it yourself so we decided to implement the feature so you can just copy the ID and now let's jump a bit up and we can launch a base helper with the option bugzill ID and just use the ID from the bugzill it is going to automatically determine what is the package and it's going to clone the repository and then it's going to determine the latest version from the comments so if we jump down we can see the latest sub-symmetry of 376 so it's going to read it from here and it's going to rebase to the version the building will take a long time so I'm just going to cancel it for now and well as I said there are a lot more options to a base helper so I'm just going to show you the help and explain some of the basic options so for example we can see that you can specify which checks you want to run or you can change the output so that you can have your JSON output and further process it if you wanted to create a wrapper script out in the base helper and you could also specify the version here which you want to use or maybe another interesting one are the build tools so that you can use yes you can see that there are four to support it and to source RPM build to support it another interesting option is non-interactive so that basically means that there are going to be no dialogues with the user so it is just going to run and do its thing obviously it is not 100% reliable because there are just some tasks that the maintainer has to do so for example marriage conflicts can easily be resolved so for example with marriage conflicts you can specify marriage strategy that can help possibly but it can add some drawbacks so it may not work perfectly and well I think that's almost all for now for me so now we have I think five minutes for the questions so the question was whether there is a way to skip downloading the sources right yes there is a way if you have already the sources in your this good repository if you have already for example from from previous builds then we basically won't download them okay so the question was whether you can build in a container which I've already mentioned it is described in the documentation you can run a base up in a container and you can also specify the federal version so it should be quite usable for the case you mentioned okay so the question is when we will start running as a service and well it is planned obviously but we first want to make sure that the base approach correctly in when is used offline because some of the maintainers who for example saw the talk three years ago about the base helper so it was already deployed to upstream is monitoring service and it didn't it wasn't very reliable so it made a lot of mess so we'd rather avoid it and make it a bit more stable but it is it's coming soon I hope okay okay so the question was whether it was accessible in centers and I don't think so there is a package in Apple but I don't think I don't know I'm not very positive what the version is and but it you should be able to build it or maybe download the latest sources it should work without the problem so the question was whether it is going to be tied to Fed package we'll see not very not very sure I think is quite a new project or it has been running for a long time but we first want to optimize it so it is very good could you please repeat it so the question was whether we are planning to implement RPM inspect instead of RPM Dave the thing is with these checks it can be quite easily extended they are implemented as plugins so even the user can program his own plug-in so it can run for example the RPM inspect so we can implement it if for example you can create an issue on github and we will be happy to implement it and at RPM spec so here is the QR code of our github repo if you are interested and you can add an issue and we will look into it I don't okay so the question was whether there is a way to merge upstream and downstream specs and I don't think there is a reliable way or at least not implemented in base helper well that yes that should be possible okay so the question was whether there is a way to skip downloading all sources spec file drama patches and I don't think it's going to support it but there is a good point and we will try to implement it because I think that that could be nice if the source gets big I don't think there is a point in them only two of the sources any other questions so thank you guys for attention and if you have any more questions you can reach us these ways