 This talk is about RPM autospec, more specific that's to relieve maintainers, package maintainers from having to maintain the release fields and change log entries in their RPM spec files manually. Okay, what's it about? So in RPM spec files, we have manually maintained release fields and change log entries, as I mentioned already, and we've had them since forever, almost since RPM exists, which is sometime in the past, 1995-ish, I think was the first Pearl-based implementation of RPM. And since then, maintainers had to bump the release field and put in some information for context, what they changed with every change to their RPM package. Meanwhile, we have a way for other people to contribute to RPM packages in federal using pull requests. Since for about four years, we have that feature with this kit being implemented on top of Pagger. So that's a problem for this workflow because for every change, you have to bump the release field, you have to put in a change log entry, and every contributor does that, and the maintainer does it on the side, like bypassing the pull request workflow with every change that gets in before you get your pull request and you have to update your pull requests and resolve conflicts and stuff like that. And then we related to that, we have more or less fragile automation for mastery builds, like they also have to bump the release fields and put in a change log entry that this is for the mastery build and then build this stuff. The work I'm presenting is a continuation of the prototype work we did last year. There are some significant changes to what we did in the prototype that were in part requested by Fesco, and also we had a couple of things which we just didn't get around to implementing last time. So who's responsible for this? First, the prototype without the work we put in there, we wouldn't have gotten that far this time. So other than myself, Pierre Vichybon, who many of you probably know as Pingu, and Adam Saleh, when the team that worked on the prototype. And this time around, we had Stephen Cody, David Kerwin, and Patrick Polakowicz. And this is for mainly maintainers. So you shouldn't have to care for the release field or the change log entries because especially the last information you put in the commit locks already. So, and for contributors, this should remove the friction, like what I described earlier with conflicts, having to update the pull requests if something else changes underneath and so forth. And for the release engineers, just less hassle with master builds. You just have to put in a commit that contains the right lock entry and build it from there. So our goals for that are objectives, like the way we wanted to achieve this is just to have static fields. You put in just a placeholder in the release field and in the change lock and the code takes care of filling in the right contents there. It determines release values automatically and also reuses the relevant parts of commit lock messages for RPM change lock entries. We wanted this to be unobtrusive to have it blend in with existing technologies and workflows. Like I shouldn't get in the way. We didn't want to introduce yet another like domain specific language for this. We didn't want to interfere with how commit lock messages are, like what they're, how they normally look like. And it should be easy to use, easy to opt in and to opt out. Especially the opting out is also a low barrier of entry because that means you can try it out. If you don't like it, you can just revert your changes. We want to have reproducible package builds. We didn't want this to be something that locks in locks a maintainer or a package into using federal infrastructure. You should take the produced SRPMs and be able to rebuild them locally in other build systems like open source OSBS. And you need, as a maintainer, you need to have the ability to fix things later. Like I can't count how often I forgot to update, like to upload the source tile ball to the look inside cache and had to check the, commit that change later. And this is something I don't want to end up in a RPM change lock. So there needs to be a way to put a little polish on the change lock if the need arises. So the final thing, what we did is mainly a Koji plug-in, like that lives on the Koji builders. It pre-processes the spec files and fills in the right content where the placeholders are before building the SRPM, which is then built into installable packages. It's also a command line tool. You can, if you have it installed, you can run RPM autospec, say generate change lock and point it to a spec file and it will generate the change lock directly in your terminal. So you can see what it would do if you were to build your package right now. It's also a Python package, which is basically, like that's where all the action happens. And that allows us to have others use the functionality integrated with tools like FET package or with RPM def pump spec. So looking back when we talked about, when I talked about release engineering, they can use RPM def pump spec all across the board. And in the case of a package that uses these features, it will simply just, I think it will prepare the commit. I'm not quite sure what it does. It will leave the spec file alone. That's the main thing here. All right, changes since the prototype. We greatly simplified the release calculation algorithm. Previously, in the prototype, we tried to emulate what a maintainer would do or what we in the team thought a maintainer normally does. And for that, we had to like keep track of from which commits packages were built. We stored them in Git tags and Fesca didn't like that too much. So they asked us to use a more simple algorithm which simply counts the number of commits since the last time the version was changed in the package. With that, we lose the ability to have multiple builds from a single commit. So if you do one build and you want to do another, without doing any changes, just maybe say rebuild that thing against the new library or doing a master build in the case of release engineering, you have to add another empty commit. It gained some functionality. We just didn't get around to last time. So it works to complete a series including merge brand merges of different branches. It will like in the case of merges, I know let me talk about that later. And the most important thing it's deployed in CoG since mid of June this year. So you can use it right now for your packages. So to stop having to maintain the release field, just put the auto release macro in it. That will do it for the most common cases. If you need to have, like, if you need to package pre-releases or snapshot releases and you don't use the, I think that was using Carrey until the characters in the version field. If you do the old way, there are flags for this too. It will include the disk text. So having just a line that says release, auto release, that will be enough. As I mentioned, it counts the numbers, a number of commits since the last time the version field was bumped. And in the case of merges, it takes the branch that has the highest value. If you merge two branches, one has three changes, one has five, the release field gets a value of five. And the simplified algorithm that affects a clean upgrade path between federal releases, that was something we cared about a lot in the past, but not so much today because upgrades nowadays do the equivalent of DNF distro sync which doesn't care about whether package gets up or down graded when doing the upgrade. So for change log entries, it just uses the percent auto change log macro in the change log blog. And individual RPM change log entries are generated from the log subject lines and who did the commit and at what time. Like if you're not familiar with Git commit logs like the usual structures, you have a single line that describes the change and then you have a, that's the so-called subject and then you have a body where you can go into detail also into reasons why you did something. And also stuff like this fixes that bug or like signed off by Lyons who worked on the change. Also you can override this in a change log file. That's the way you fix things if they go, if you notice something went wrong in the past. So you simply dump the generator change log into that file. Do the fixes commit that and then it will take these contents from then on. We're also mentioning, like so far we only use the subject lines. We know there's a demand for being able to specify longer RPM change log entries, but we're still hashing that out. And for change log entries, because you can't really know what content, what changes were relevant, like you can't programmatically find that out really. The only way, the only situation where we support that fully is if one branch like wins and the other, the content of the other branch is simply discarded. That's the case if you use the hour strategy for merging, which simply does bookkeeping merge commit and takes the whole contents of one branch and discards the rest. And in the case of normal real mergers where you might have resolved conflicts between the two branches and stuff like that, like when it can't find out on its own what the changes are, it will put in a message saying that it can't resolve this merge so you can fix it manually. Okay, what's next? I mentioned longer change log entries. There are a couple of approaches to this. There's some discussion in an open issue about that. I want to do it in a way that the git commit log messages that they still look natural in some way, like that they look like any other git commit log message that we don't have to invent something that goes against normal git workflows. And the next thing is a way to preemptively say, oh, disregard this commit for the change log. I forgot to upload the table or something like that. That's not relevant for the RPM change log that you can do it right away instead of having to patch things later. And also we want to accommodate downstream users of that that would be like the Neil Gomper does some integration with OSBS to rebuild packages from Fedora there and they have some different requirements with regards to version and release fields in the change log. So we want to accommodate them with that. All right, I'm done here. So you can find further information at the project repository at the URL you see here. Same with documentation. There's much more information inside there. And you can also look at these slides if you haven't had enough of them already. They're on like the repository where these live, the source of these slides is on Pager as well. So are there any questions? Maybe they have bubbled up because I only looked at the speaker view of this. You see there are questions. Could you show us an example of how to use it? Of course, I'm happy to do that. Let me just unshare my slides. All right, I'll go to have a demo in the source code. This is how you enable automatic release numbering. And this is how you enable the automatic change log entry generation. It's really super simple. Let me run through generating the real spec file that then gets passed to Koji for building. No, sorry. Okay. I'm in the wrong top folder of the project. So this is what happens to the spec file before Koji gets to anything from it. It puts in, find the auto-release macro, sets the release number to 11, because that's the number of commits since the last time the version was changed in this particular project. And it fills in the whole change log of the file. That's all it does. So, any other questions? Okay, let me go from, start from the bottom. I fedora packages that RHP will apparently pull into Rella. Can I use RPM Autospec or will it cause problems for them? It depends on how, that depends on how they consume it. I imagine they will want to have a clone of the Git repository and build from there. They would have to have some enablement in the building infrastructure in Redhead. But that shouldn't be a huge problem. The internal system we use there also based on Koji, the only really hard requirement we have is it needs to, the Python version needs to be 3.6 or later. So our internal systems may need updating. I don't know. I haven't looked into them in quite a long while. What are the CLI commands? Let me share the screen again because it's much easier to simply run it. We have generate change log. It just, I mean, does the things and dumps the change log on the, on standard out. And also same thing with calculate release. There's not much more. We have some ideas. I forgot that in the slides. How could that happen? I don't know. To, like to automatically convert a package to using auto release and auto change log. Also to freeze the, like to generate the change log and freeze it into the change log files for editing. This is all stuff you can do manually using two or three commands or your text editor. But it would be very convenient if you could do that in one go. Okay. You didn't get the snapshot remark. Do tilde RC1 and curate devil work and how? Yes, they do work. You just wouldn't use the, the, the flags for the, for the legacy, legacy way to encode snapshot versions into the release field. RPM or spec largely doesn't care about the, the, the version contents. It just cares about, did it change? We don't really look at what's in the, in the version field other than comparing it with the version of a previous commit. And Matt, you're asking the, the interesting question when are we going to make this mandatory for new packages and mandatory for existing packages? I mean, yeah, I wouldn't be against it. I think it's solid. Let's give it some time to prove itself in the field. And then it's, it's a policy question like when are we going to tell people you have to do it this way? I don't, I don't really know. For, for me and for the release engineering folks, probably rather sooner than later. I mean, but I'm biased here. Okay. If there aren't any other questions, we're almost out of time. How many packages are using it already? I don't know exactly. I have converted one of mine. I think we will be eating our dog. We don't yet, but we will be eating our dog food on that soon. Another unrelated package of mine uses it. I have feedback from a couple of people. I think get Kola uses it. That's one instance like where we just discovered a bug with merges, which will be deployed soon. You use that and you notice that the source opm generation takes forever. I mean that little really, and until co-gd is restarted or something. Then you've run into that bug, but we have the fix. It's in, it's released already. We just need to deploy it, but I don't want to bother Kevin with it on the weekend. Anyway, yeah. All right. Don't. I'm missing some context with fat package mock build error. Change log entries must start with a star. This is odd. I haven't seen it already, but please tell me more about it. Maybe not right here because we're out of time, but just point me to the package or the repository that's happening. All right. The co-g plugin is separate from co-g. Yes. Like you can run co-g without it. It's not part of the co-g core code base. It's a separate plugin which you have to install and configure your co-gd process for it. All right. Oh, that solved itself. That's nice. I like these. I didn't have to do anything. They're my favorites. Okay. It's the top of the hour. Thanks so much for attending. I'll stick around in the general chat and probably the museum map or something. So if you want to hit me up there or on IRC, I'm regularly there when I'm at least when I'm working. So thanks again and have a good rest of the conference, folks. Bye-bye.