 Hello, and welcome, everybody. My name is Nis Phirpsen. I'm here with my colleague and boss, Julia Bly, and I'll be presenting the latest news about RPM Autospec, which is automatic release fields and change locks in RPM packages. As it says on this first slide, in order to find the presenter view, there it is. All right. Once upon a time, so this is a long timeline. RPM is a very old piece of software, like it's from 1995, so it's 26 years by now. And we still use it because it is pretty good for what it does. So at the time and in the intervening 25 years, like 1995 through mid of 2021, at least in Retter in Fedora, we maintained release fields and change lock entries for RPM packages manually, which wasn't a really big problem. It was just unnecessary, but there were more and bigger fish to fry, as you can see on this timeline. We put down a couple of milestones in terms of redhead Linux and Fedora releases that we zoomed through them very quickly. So we have RH-L2021, which is the very first release with RPM that was still programmed in Perl. We almost immediately re-implemented that in C with RH-Linux 4 in 1996. We had Quick Zoom. We had the GC-C296 debacle, like people didn't love us for it because we use a different compiler than anyone else, and so we're incompatible, at least. And some languages covered by the compiler. And then in 2002, we got the first extra packages repository started by Warren Tugami, who was a student at the University of Hawaii. Like any additional software that wasn't in redhead Linux, but was built for redhead Linux and was tested. And so that's basically what we have with Apple now for CentOS and REL. That was Fedora Linux at the time, which was a completely separate piece, nothing to do with redhead officially. And at some point, we merged like redhead Linux and Warren's Fedora Linux. We merged into Fedora Core plus extras. That was 2003. And in 2007, we have Fedora 7, No More Core, No More Extras, everything together, like everybody could contribute to everything before that the core packages were limited to people trusted by redhead, I guess, maybe only redhead employees I don't know anymore. 2009, we got Apple, which is basically the same extra packages thing just on top of the REL derivatives or REL itself. We have in 2012 Fedora 17, which moves all the programs, all the software to user where it could be read only, which is a big stepping stone for all that comes in terms of atomic, a core OS later, which is read only system images. This was a big building block for that. And then with a tier in my eye, there's Fedora 20. Heisenbach, which is the last release with a code name. Previously, every redhead Linux or Fedora release had a code name, which is an interesting story. Like the code names always had a relationship, like the previous one to the next one, they were the same thing had to be. That was the rule. People would submit code names for the next Fedora release that would go through legal. So we don't run a file of trademarks. And then with the clear names, they were put to vote, and the winner would become the next code name, which is a very nice thing to have, because it's really good to identify with something, but it was just too much effort. So we ditched it with Fedora 20. And then in mid-2017, so this gets back on topic a little more, we get Pagura over diskit, which means all our package repositories live on a Pagura instance, which allows contributors to submit pull requests, which we couldn't do previously, and that opens a can of worms, because now we have, for all the changes in, if you're a package maintainer for all the changes you do, you usually bump the release by one for every change. And if you suddenly have five contributors, opening a pull request, everybody bumps the release. One pull request gets merged. All the other ones get conflicts on the release field and the change log entries, because all the context has changed, and so that was a lot of hassle. So we finally thought about automating these two pieces in the puzzle, which we could have done 20 years ago, but the pain never wasn't enough, and started working a prototype in 2020, which we picked up in 2021 again with a couple of change requests and from the community, from Fesco. And since mid-of-2021, it's live. We have it in production. This morning, I checked how many packages use it, and I was surprised very positively. As of this morning, 1,358 of 21,358 active RPM packages use RPM motor spec, which is a little over 6%. And that's in a couple of months. So we're very pleased with how that turned out. And contrasting that with a relatively low number of bug reports, so that pleases me to know. OK, so why do we do this? We have less work as package maintainers, as contributors to a package that is in our own way. There's less friction. It's smoother to get a pull request in. And as release engineers who have to rebuild the distribution every six months give or take, it's less hassle to do with automatic release number management. Because previously, they would have to touch every spec file for every rebuild package, like all 20 plus thousand of them. And bump the release, put in a change lock entry. Like there's tools for that, but there are always the spec files that won't work with this. So there's manual intervention necessary. And the more packages use this, the less hassle the release engineers will have with rebuilding the whole distribution. So the idea is instead of a manually maintained release field and change lock block, we just put in static macros, really. The release values are determined automatically from the Git commit history. Like every commit bumps the release by one until the version is changed. Then it gets reset back to one. We reuse the relevant parts of a Git commit lock message for the change lock entries. It's, in my opinion, pretty unobtrusive. So it doesn't stand in the way. It works nicely with the existing framework of things we have around RPM packages. It has an extremely low barrier of entry. It's very easy to opt in and out. Just put in the macros or rip them out again. And also the produced packages, they are reproducible. Like what comes out of our build system, the release number stays stable. Like we can use the produced SRPM source packages, build them anywhere else, and they will get the same release field. They will get the same change lock contents as we have in our environment. And one thing, the last point is like it's a bit, there's stuff to be done there. The ability to fix things later, we have that already. Like we have a change lock file, really, which is where we can freeze the change lock and make changes. But this is a bit awkward. This is more to migrate from a traditional manual maintenance way of doing things to the automatic way. For skipping commits and stuff like that, we want to give people better tools than that. So for you as a package maintainer, this is like the upper part of the iceberg. This is what you deal with. There's a Fed package, which is your primary tool to building packages in our infrastructure. There's a corresponding build system plug-in in Koji, which takes care of things like if you have an RPM auto spec enabled package, it will fill in the computed values and then build the package. There's RPM depth bomb spec, which is the other tool I mentioned for release engineering, which manually, well, which half automatically took over the manual bumping job from a package maintainer or from a release engineer. And there is the RPM auto spec command line tool, which can be used to find out what will the next release number be, how would the change lock look like. If I commit like that, if I pushed it upstream and built from that, and underlying under the surface, there's a big Python package, which does essentially all the work. So what's in it for me? This is how you do things in the upper left terminal window fake thing I put in there. This is how it would look in your editor. You put in the percent auto release macro in the release field. You replace the whole change lock by percent auto change lock, move the contents away to the change lock file if you want to retain them. Otherwise, I think they would get lost or it will just consume all the older commit locks. So please have a change lock file, even if it's empty. And in conjunction with that, you see a Git history timeline goes from old at the bottom to new at the top. To the left, you have an example commit lock message, don't get eaten by a guru is the subject line and the explanation how to do that is not play Zorg. And there's a sign off byline. And the subject line is what ends up in the RPM change lock. So there you have an entry with the date from the commit with your name and email address as it's in the commit itself with a version and release. And that's it, basically. Like from there or not, you shouldn't have to care too much about the release field or the change lock anymore. So by the way, just for the record, this guru wouldn't eat you, his dog would though. Going forward, we still have a couple of plans. It's like as everybody who was involved in the project, we're busy with other things meanwhile. So it's always trying to find some spare cycles to implement things or to review pull requests. Thanks for everybody who contributed there, especially thanks Q-Logic. That's Eliott, Celeste, Andrade. I hope I pronounced that correctly, who implemented conversion sub-command to the RPM Autospec tool, which isn't yet available. So it's queued up for the next release, which will be coming out shortly, I hope. And the other things we want to do, I mentioned that already. Magic comments to skip whoopsies like, oh, I forgot to upload the table and stuff like that. You don't want that to end up in the change-log. You also don't want to just freeze the change-log into the change-log file just for stuff like that. And of course, also more detailed change-log entries. Right now, you only get the subject line of a Git commit log, which is like the convention is that it's not longer than 50 characters, which is good for a Git commit log. But for an RPM change-log entry, sometimes you need to be a bit more verbose. Also, if you have several items you do in one commit, that just doesn't fit in the subject log. We have some ideas how to do that. There's an open RFE ticket for it. We have a pretty good picture how it can be solved. And I hope I get to it very soon. Also, that one will please Neil Gompater here if he's in here right now. We want to accommodate downstream consumption, which means basically he's our primary customer there. Rebuilding federal packages in the open SUSE build system. They have some different requirements in terms of version numbers, release numbers in the change-log. So some slightly modified formatting of the change-log will be necessary to make that happen. So if you're interested in the details, how we went about this, how you use this in more detail, like what are the pits you could fall into? Well, not really fall into that trip over or something. There's our project repository documentation. And these slides are up on my Federal People page. So feel free to download them and browse them at home, wherever, at your leisure. And with that, thank you for being here. And do you have any questions? There are actually questions. And Neil Gompater, by the way, says hi. Hi, Neil. So the question is coming from Ben. And it's basically asking, is RPMO to spec available in COPR or only Fedora Distinct? At the moment, it is only available in official Fedora build infrastructure. So not in copper yet. I don't see a technical problem to have it. Well, maybe let me restate that. Like, RPMO to spec relies on Git history. Like, it counts Git commits, and from that determines the release number. And it consumes the Git commit logs to produce the change log entries. I know that copper uses Git repositories, but as far as I'm aware, it doesn't retain the history, but basically has a new one every time. I'm not sure about the details. Like, if I would very much like to have it in copper, but I would need to talk to some people who actually know how copper works on the back end side. Like, I know how I use it, but I don't know the details. I'd be happy to have it. OK, so we're going to take that as an action. I mean, there are actually two more questions as well. One is from Matthew. What's the path to making this default for all packages? I don't know. This is policy. I mean, I'm just a developer. Like, as far as I'm concerned, as soon as we have easy skipping of commits for the change log and longer commits than it's for purposes of official Fedora builds, it's feature complete, I'd say. So at that point, I would have no qualms to making this mandatory or anything. But this is a policy question. This has to be decided in a greater group of people than just myself. Perfect. And the other question is actually from Troy. And he's asking, is it available for any of the Apple builds, maybe Apple 7, 8, et cetera? Because our builders are running on Fedora 34, you can use it to build any package. Like, all the magic happens on this side of the build route. So you can build Apple packages using OPM Autospec. And I hope I'm pretty sure that I'm correct with that statement. So yeah, if I'm not, shout at me. Perfect. James actually says, make the colonials. And Fabio actually says, thank you for implementing this feature. It makes maintaining Rust packages much, much easier. Also, Copper's Discord package first recently gained support for our PM Autospec, as far as he knows. This is great news. So that means we already have it in Copper. I have to try that one out. Cool. I like it. There we go. Any additional questions from anyone? Silence is a great message. Yeah, I mean, please, if you want to get on the call, show your face and talk to us directly in the call, please do so. I think we still have seven potentially open slots here. There's Matthew. Hi, Matthew. Welcome. I just want to say I really like this. I found it really convenient for my packages. And I think it's the right direction to go for everything. So technical implementation on your side, fine. The rest of us, let's figure out how we can make this be used in more packages and eventually the default within a fairly short time. I don't want this to be five years from now when it's still 80% of packages and 20% not. Yeah, I think there are a couple of outliers in terms of their requirements, how they use the release field and stuff like that. I think some of the, maybe even the Fedora release package can't use RPM Autospec for some reason today. The Fedora release package has got a weird quirk in how it's done, because it's self-eating its own tail about what the Fedora release is. So yeah. I think it could be done in a release, but it uses RPM Autospec. I haven't checked. Like this morning, I hammered Pagger to find out how many packages use that already, because I didn't look into the stats before that. But I haven't checked the individual packages. Yeah, Fedora release is the package. That is where DIST version is defined. So it causes all sorts of complication. There was, now I remember. Oh yeah. No, it's not a release. Cool. That's awesome. Yeah. I think there was a request for a flag or something to leave out the DIST tag in the produce release field or something. That's missing for a couple, at least one package. That needs it for the kernel package we need. I think it should work. Like this was one of my test items. So I'm aware of that they have quirky release numbering, like the 100, 200, 300 based thing, depending on if you're in the current branch release or stable release or the older one or whatever. So we have a flag to add an offset in the auto release field. So that should work. But honestly, I haven't asked the kernel package maintainers to try it out or try it out myself. So it should work. I don't know. Perfect. Anything else, any other questions? Because otherwise, we give everyone a little bit of a break and get some coffee. Smell break. My five minutes to grab lunch, I think. Ooh. Yeah. Enjoy. All right. Wonderful. Thanks, everybody, for attending the talk. And if you have any questions, feel free to send me an email. Hit me up on IRC or wherever. Thanks. Thanks so much, everyone.