 Welcome everyone to this Federal Classroom session. It's going to be a one-on-one session, which means we'll touch upon all the basics without going into too many details. It is strictly an hour. Unfortunately, we have work meetings after the hour, but you can continue asking those questions on the different channels afterwards. So ideally what this session will tell you is what an RPM package is, how you can extract information about your RPM packages, metadata, and so on. And of course, we'll then go through the pipeline to construct an RPM package. Depending on how much time we have at the end, we will also try and give you a quick overview of how these packages are built in the Fedora pipeline. So from a package maintainer, including a new piece of software in Fedora to how it gets to the repositories so that you can install it on your computers using either DNF or in some cases, Nome Software. Right, so I'm going to switch to my terminal. The session is meant to be hands-on, which means I will show you commands and I will put them in the chat. You don't have to use them, but if you follow along and run the command on your system as well, it'll give you a much better idea of how things work. Okay, so let's... Okay, I do hope everybody can see my terminal now. I've switched there and I'm going to chat open a different window. If you have questions, please raise your hands or put them in the chat and I'll keep answering them when I break. Okay, so we're in the terminal now. As you can see, I've created a new directory for this, which I suggest everybody should do, just so that it'll keep your computer clean. Right, so first of all, let's have a look at a package that everybody should have on Fedora already, right? So most of you have used the FBase tool, which is quite an easy tool for you to gather some system information and share it on the Fedora pasting. So for example, if you do this, before I go any further, is the font large enough? Can everybody read the command? Okay, that's great. So for example, if you run FBase double dash, this info, which I'll put in the chat for you now, what you'll see is that it gathers a lot of system information and then it'll return you a link, right? And the link is a link on the Fedora pasting, which gathers lots of information about your system. And we use this to debug issues, right? So for example, if you've ever been to one of our support channels, somebody may have asked you to provide the output of FBase's info, right? So it gives you information about the release, what desktop environment you're running, your SeLinux status, some information about your hardware, what processes are running, your PCI devices and so on, some kernel messages, the most recent ones, all your repositories, which come in quite handy when we're debugging issues, and then, you know, more information about your packages and so on. Recently, we've also added a BTA, a flag for ButterFS, because a lot of people are now on a new file system. So it can also give you information on that, right? And FBase is included by default in federal installations. In pretty much all the standard installations, all the spins, I also believe it's on the server and so on, right? And what FBase effectively is, is one file. So if you run which FBase, you'll see that one file in user bin. That's all it is, right? So most of you will know this, but I'll cover this anyway. If you do RPM minus QF paste, right? That is query the RPM database, you should find out what version of FBase you're on. If you add some more flags to query, you can see more information about FBase, right? So I stands for information. And what this will show you is, what this will show you is a short output with the various metadata tags, right? So what the name of this package is, what version do you have right now, what release is this? If you're in Fedora 33, this will be FC33 at the end. The architecture, FBase is a pure Python file, right? Which means it's portable and does not depend on the architecture. So the tag for that is no arch, right? Which means it can run on all the arch of the Fedora supports. Then you get installation date, the size of your package to license, which of course in Fedora is very important, right? Since we want to use free and open source software. And then it'll give you some more information about the build, right? So what the source RPM is, we'll cover this later. Packager vendor, these are all standard fields. Fedora is a package, right? Because you've got it from your repositories. And then there's more information. So for example, the upstream, this is where we develop FBase on Fagger. And then if you want to file bugs, you can use this URL here. And then you have a summary, which tells you what the tool does in short and a much longer description. Okay, so this is how you can query RPM about a package that is already installed, right? And all of this information is included in the RPM that you've installed, all right? So an RPM, and we can see this. So if you use the L flag along with Q, Q is for query, L is for list. It will tell you all the files that were included in this RPM, right? So you've got your FBase script. You've got some quick documentation. You've got the man page, and you've got the license file. So this is what me as the package maintainer for FBase included in the FBase package, all right? So in short, an RPM is a compressed archive, right? It's not a zip file. It uses a different algorithm. I think nowadays we use XZ, but it is a compressed file, which includes all of these files along with some metadata, right? The metadata that you were able to query. And this metadata includes all of these tags and information about what files are included in the RPM, right? And this is how RPM on your system will construct a database. And when you run all of these commands, the query commands, all of this information comes from the RPM database, right? Because I don't have this directory is completely empty. I don't have the RPM file here with me. So all of this information is included in the RPM. And when you install the RPM, it gets pulled into the RPM database to allow you to query these things. Now RPM is only for your local systems, right? So if I want to get some information from the repositories, I cannot use RPM, right? RPM does not know about repositories. RPM only knows about RPM packages. I want to get information from the repositories, then we need to use DNF, right? Which knows about all the federal repositories. So if you want to get information of F-paced, you will use DNF info, right? You don't have to use sudo here. I use it because that way it always uses the system cache, right? Now this information is not coming from the local, well, it's a combination. It's coming from the local RPM database, but it's also using the repo, right? But if it's a package that I don't have on my system, RPM will be unable to help me. Will somebody give me a random package name, which I will unlike, which I will probably not have on my system. Whipple, any ideas? Where? Dominator? Let's go with Sway, because it's quite popular now, this. There we go. Right, so I do not have Sway on my system at all, right? You can see it's not installed, but I can do, right? So now you see the distinction. DNF gives you, yeah, so to answer your question, ED, LER, 88. It will tell you everything that's included, all the files and directory structure from your package will be, sorry, will be listed when you do RPM minus QL, okay? You can also do this using DNF actually, so you can do repo query. If you want to look at what files are included in a package that you do not have installed, you can use DNF repo query, right? So make that clear, let's have a look at what Sway includes. And these are all the files that are included in the Sway package, all right? So you have configuration files, you have your binaries, right, you have some debug information, you've got your backgrounds, you've got various completion scripts for bash and fish, and then you've got your licenses, and of course your man pages documentation and so on, right? So this is how you can get information about packages that you don't have in your system, okay? There's a lot more you can do with DNF, so if you look at what, like I'm using that, if you don't have that installed, you can install it using all that, right? It's cat with more features pretty much, right? If I move this, now we're looking at the FBA script, okay? So you can also use cat, you can use more, you can use less, you can use tail, right? But what you see on top of the file is that it has what in Linux jargon we call a sheban, right? A sheban tells the shell what, well, program should be used on the script, okay? And as you can see, FBA is a pure Python script, and therefore we need Python 3 installed, right? So in order to run FBAs, we need Python 3 installed. And let's do this, so now what I'm querying is, I'm running RPM, I'm querying RPM, and I'm asking RPM, what does FBAs need to run, right? That is what requires does. So if you want to run this in your own terminal, there's a command, right? And what you see here is that it includes this extra information that F-paste, this package, requires Python 3 to run, right? What this means is when you do DNF install F-paste, DNF will then go through the list of requirements for F-paste and also install all of these, right? This is why DNF does dependency resolution. All of this information is again included in your RPM, okay, so that is requires. Now all of this is more from a usage perspective, so what information do you need to inspect a package to see what it requires? And we, as package maintainers, this is our responsibility to make sure that all the requires of a package are correct. We have lots of checks in the build system, which I'll try and show you at the end, which check to see if a package installs correctly or if there's something wrong with its requires, right? But again, all of this information is included in your RPM itself, right? So it's a self-contained archive of files and metadata that are required to install or remove or upgrade the package and so on, right? Let's take a two-minute break here. Does anybody have any questions so far? Please put them in the chat. Yeah, I'll give it another minute and then we'll move on. Ed, so the most common reason is that it needs to update the metadata, right? So if your metadata for DNF is not, well, is not up to date, it will contact your repositories and fetch it again. So that is one reason for DNF taking some time. The other reason is dependency resolution. So depending on how many packages there are in a transaction, DNF does the math under the hood to see what else is required to complete the transaction correctly, right? So that may take some time. But if you think DNF will use quite slow, it's best to file a bug and the developers can then have a look and see where there might be some optimization opportunities. Taptashi, yes. So all your RPM commands are for packages that are either installed in your system so it can use the database or if you have the RPM file, right? If you do not have the RPM file and it's not installed in your system, then you use DNF. Telnama, yes. So along with requires, you can also see what capabilities, right? A package has. So for example, if you run, if you replace requires with provides, for F-PACE, you'll see that it provides this package with this version. If you want to have a look at, so you can do something like this, right? I don't want to write F-PACE because I don't think anything when it opposed requires F-PACE, but let's, let's, let's, let's try in three and see. This is probably going to give us a very long list, right? So all of these packages will have Python 3 listed as requires. Well, as expected, it did not disappoint. The whole Python package said requires Python 3. So this is the loudspeaker while provides, I use the word capability because it's not necessarily just the final binary, right? So if I, let's see. So if I do, right? So this was the G-Lib C. And so this will tell you that it provides the G-Lib C package, this particular version, but then all of the libraries that are included in G-Lib C will also be listed here, right? So that is why we say capabilities rather than a file, right? Right, so example here, you can see that the Fedora Packager package provides some configuration here, config, right? If you look at the requires, you'll see that it pulls in the things that we need for building RPMs. That's why we asked you to install Fedora Packager. And tell them, I'm not entirely sure. We'll have to look at the man page for the query. I think, as the name suggests, it is meant to look at the complete repository. It may be, that's called a shebang. You can look that up online. What's interesting about Fedora Packager is, yeah, it's more of a meta package, it just installs all the things. Okay, Vipul, sorry, I'll keep that in mind. Okay, so I think we've done kind of user-facing bits. Let's have a look at how F-Paste is packaged. So, your first link is, right? So we're now looking at the sources that are used to build all the packages in the Fedora ecosystem, right? So we call it source-to-Fedora-project.org, and all RPMs are under the RPM namespace. And now we also have containers and so on. So there's a different namespace for containers. There's a different namespace for modules. Right, but if you go here, you can look at, I'm getting some feedback. Somebody's mic on. Thanks. Right, so if you look at the Fedora package sources, this is where the package maintainers store all the information required to build our packages. Okay, so this is the one for F-Paste. As you see, I am the maintainer for F-Paste. If you click on files, you can look at the spec file. All right, and now if you look at the spec file, you'll notice that all of this information is what you had seen when we had run RPMQI on F-Paste. Right, it had given us a name, version, license information, the URL. Right, so all of these are metadata tags that we use to provide information to RPM about the package. Okay, and then as we saw F-Paste is pretty much, well, one Python script along with some more information. If you skip all of the bits in between and come down to the file section, right, you'll see that we have, bindir is a macro or the binary directory which on Fedora expands to user bin. Right, so this is how we put user bin and the name here is F-Paste. We saw that in documentation for F-Paste, we had to read me, let me actually do. Right, so on the left, I'm going to show you the output of a few commands. Right, and then we can compare them to the spec file. Right, so if you look at the top bits, name, version, release, all of this comes from here in the spec file. Right, the description is here too. Yeah, bindir does mean user bin, yes. There's a list of all macros that we defined for Fedora. I'll give you a link later when we get to that bit. Yeah, and then if you come down to the file section, right, you can see the bindir here goes to user bin. Right, the doc macro expands to user shared doc and the name of the package, so you can see that here. And you can see I've included the read me file and the to-do file, and you can see both of them listed here. Right, similarly, the license macro expands to user share license and package name, and you can see that the copying file from my spec comes down to user share licenses F-Paste copying over here. And finally, if you look at the man page, the mandir is another macro. So the to-do file, the question here is what is a to-do file? The to-do file is a list of features we want in F-Paste. Right, it's not something users need to look at, but we leave it there in case users are wondering what more features and bug fixes and so on are sort of in the pipeline. That is pretty much the maintainer's decision, right, what extra files they want to include in the package. So yeah, and finally, you look at mandir, which expands to user share man, okay, and then we want this to be in section one of the man pages, so that's man one, and then we have the man page, right? To learn more about sections, to learn more about the file system hierarchy, you should try reading the man page for hierarchy, that's man hire, H-I-E-R, all right, this will explain to you the standard directories where we place files and why. There's something else I wanted to tell you, yeah, and of course, man itself has a man page, right? So you can read through that. It'll tell you why the different sections. So for example, section one is executable programs or shell commands, and so on and so forth, okay? Okay, so now we know where the metadata goes and we know how the files are specified, right? Now there's some stuff in the middle, the three sections. You can see the prep section, which is short for preparation. Well, I'm not sure about that, but I would assume that's it. There's the build section and there's the install section, right? So to do this, you're going to clone, right? So because the Fedora package sources are, so this is a pager instance, a Pega instance rather, right? So you can see how you can clone your repositories. If you have Fed package installed in the system, you should be able to clone the repository using Fed package, right? I think this applies if you have a Fedora account. If you don't have a Fedora account, I believe you need to use the anonymous flag holding. Yeah, give me a minute, we have, right? So if you don't have a Fedora account, use, and this is the link. Joe, the session is being recorded. Mandy, no, I'll discuss that more in detail, but Fed package is, it does a lot more than just clone the repository, right? Because you can technically clone the repository just with the clone. But again, we have Fed package installed. The easiest thing to do is read the man page, right? And that will tell you everything that Fed package can do. But anyway, so let's clone the repository, right? So I've got now an FPACE repository. If I enter this, you'll see the same files that we saw here, right? And you also have a git ignore file. It's just a hidden file, right? So you can use LS with H and so on to, well, with LA rather, to look at your hidden files in this directory. Well, let's expand this. Now, the same file. I've just opened it locally on my system. I'll wait a minute for everybody to clone and open the file and have a quick look at it. Any questions in the second part of session yet? Diego, you'll have to use the anonymous clone. So that'll be for you. It'll be Fed package. Yeah. What I've just said. To create a Fedora account, you go to accounts that. If you have an account, make sure you've logged in to source the Fedora project raw once that can create a profile for you. Miguel, I'll talk about how we can, how you can join up and contribute, right? Yeah. So the question is what is, if you're packaging something from scratch? Yeah. So you get the source code from upstream and then you write a spec file from zero, right? So I'll cover some of that. I won't cover all of it. Okay. I'm assuming people have the repository clone. So here's what else that package can do for you. If you write Fed package sources, it'll fetch the source code or F paste. So then you should have F paste data file that I used to make releases. And then if you extract this, if you extract this, you'll then have the F paste source folder. And of course, if you go inside the source folder, you'll find the source code of the package, right? You can do this for any package. So you can clone any repository and use Fed package sources. Mandy, it depends. If you want to access the F paste source code, that's on Pagger for that. I think you can use HTTPS to read any of this. You do not need SSH keys, right? All of this is open source. You can access all of this information without SSH keys. Right? The difference is that, for example, this is where the sources of F paste are, right? And you can clone, right? If you log in and have an account, it might give you some more options also. Okay, so then you get more options. The SSH will only work if you have an SSH key, as far as I know. You do not have an SSH key uploaded to Pagger, then you'll have to use HTTPS, right? Okay, anyway. So now let's, we're looking at the source code for F paste, all right? Now, this is where packaging requires a little knowledge about the tool that you're trying to package, right? You need to know how the source code is organized, and you need to know where different files have to be installed, right? That is how we'll popular the files system, the files section of your spec file. So I've started with F paste because it's a very, very simple one, all right? So for example, here you can see that there is the F paste not by script, right? There's read me and to do files, right? We call this the root of the folder, okay? The changelove and copying also in the root of the folder. And finally, if you look at docs, right? You've got the man page inside the docs folder. So that's docs slash man for manual slash en for the language because you can translate your man pages into different languages if you. Now the exercise of this RPM is to take these files, right? And put them in the right place on your local system. Okay, that is all the spec file is telling the RPM, right? So if we look at the spec file again, and I'm going to, okay, so on the right hand side you're looking at the source code for F paste, right? And on the left hand side you're looking at my spec file. Now, when we define the source code at source 0 over here, that tells RPM where your source code is, right? And as you see, it's a URL and at the end it expands to name version tar dot gz, which on the right hand side you'll see expands to F paste dash 0.4.2.0.tar dot gz. So the source file here is telling RPM, this is the file that needs to be included here, that needs to be used to generate my build, okay? After we have more metadata, when you come to the prep section, what the prep section does is it tells RPM different steps to take to prepare the source code for the next steps. Mainly that's because you're looking at the source code for F paste, you're not looking at the RPM source code, right? So there are two different levels. The source code for the software is different, that comes from the upstream developers, and the spec file and the sources that are used to build the RPM are in Fedora infrastructure, right? So there are two different repositories, okay? So what the prep section is doing here, in this case, it's all it's doing is it's extracting this tar, right? The way we did manually, because before you access its files, you need to extract this, right? F paste is very simple, we don't have anything to build in here, but if you have used tools, for example, that are written in C or C++, you generally have to run configure make and make install, right? So all of that would go in this build section, okay? I'll show you a more complex spec which has to do in a bit. And finally, the install section is where you tell RPM where your files have to be installed, right? So as you can see here, I'm creating a new directory, I'm creating bin dir, which we now know is user bin, and I'm running make install in this, the build section. And if you look at the make file for F paste, it's a very, very simple make file, and all it does is, it puts the F paste script in its right place, right? And it installs the man page in the right place, that's all it does, okay? It doesn't do much. And what's interesting here to see is, these are some make file specifics which you won't go into much now. But if you look on the left in my spec, I've said bin dir equals something, something, something, okay? And when we run make, make replaces bin dir in my make file with that value, okay? So it's just a replacement. Similarly for man dir which I define here, my make file will replace that in here. One thing to note here is a special macro called build root. So when, if you build some source from source, you want to make sure that it doesn't produce a, it doesn't pollute your home directory, and the whatever you have installed on your system currently does not affect the build, right? So what opium does is it creates a new build root, right? Think of it as a different isolated file structure, right? So when you're installing in bin dir, it's not actually installing in user bin because we don't want to dirty your system, right? It creates a different, a different system structure and creates a bin dir over there, okay? So everything we do is relative to this newly created build root, okay? So any questions so far? Otherwise we'll build a face again and see how that looks. To add, there are different kinds of macros. All of these macros, the location macros are in the guidelines, but then each, the language specific guidelines. So for example, the Python macros are in the Python guidelines. The Java macros will be defined as Java guidelines because the maintainers, that doesn't actually exist in the file, that's only in my editor to show me where the line ends, right? The dollar sign at the end of the line. If you open the file on, in your browser, on source, you'll see that the dollar sign isn't there. Okay, fine. So let's, okay, so I'm going to restore this file. I'm going to change this to it at the moment. Now, an auto setup is a slightly advanced version of setup. That's, that's not quite federal specific, that's RPM specific, so this documentation lies in the RPM documentation, right? And had asked if, where the explanation for the auto setup macro is given, okay? Right, so now in order to build your RPM, we need to use the RPM build tool, okay? So, generally your command is RPMBA, which means build all, and then your spec file. But we're going to do this in two steps because we want to show you what a source RPM is. So first I'm going to run RPMBS, let's build source, okay? And very quickly, it gives me an output. What one should notice here is that this is a source RPM, right? It's SRC.RPM, it's not your final binary RPM, right? We've got a new file here called the source RPM. What you'll also see now is that it's created new folders in my, in my space folder for the build root, right? There's another folder for build and this is another folder for RPMs. RPMs are where the finally generated RPMs will go. Build root is the alternative directory structure that RPM creates for us. Build is a temporary directory where whatever needs building, right? For example, when you run configure, make, make, install, all of that will happen in build. Yeah. Now the idea here is that your source RPM includes all your sources. So this includes the tar file for F-Paste, it will include the spec file and quite a few packages will have multiple sources, right? So you may have one tar, but there might be other external files that you want to include in the RPM. All the patches that we carry, I haven't shown you any here, but any patches that you carry. So basically everything that's required to build the RPM needs to be included in your source RPM, right? It is another loudspeaker that's because you don't have the tarf. The loudspeaker is asked, they're getting an error where they can't find F-Paste. All right, that's because I'll discuss it later. So the difference is that my system is now set up to pick up sources from the current directory, whereas you're still using the default system which has a different directory structure. Let's see, I think that might be a problem. So if you want to be able to run the commands around running exactly, please go to this link on paste.centers.org and download the file as a raw file and place it in your home directory as a hidden file as .rpm macros. All it's really doing is it's telling RPM build to use my current directory for all of this rather than look elsewhere. All right, we only have 10 minutes left so I'm going to go through this rather quickly. Unfortunately. So now we have RPMBS and to build RPM we'll go I seem to have done something wrong here I guess I seem to have run into some sort of bug which I'm not sure about so we'll skip that for the moment. Yeah, that's where you go. Okay, so in an ideal world if I hadn't run into a bug this is how you'd build your RPM. The requirement here is that because you're using RPM which has no idea about all your repositories, everything that's required to build your RPM needs to be on your local system. Ed's know there isn't at the moment. Well, at least I'm not aware. Ed asks, is an XDG based directory compliant location? No, I'm not aware of one. Jose, make sure you download the raw version of the file otherwise if you download the HTML version that won't work. And now to give you a quick walkthrough of that package. So instead of using an RPM build, what I can do now is use FET package. Right? Let's quickly look at the mind patients and see what we want to do. What we want to do is we want to build a local build. Right? So we can search the mind page for local and there you go. Right? The FET package local will build a local RPM build test. Let's try it out. So as you can see I get the same error as I got RPM build, which means FET package and literally just calling RPM build under the hood. Right? What do you suggest I should cover in the remaining five minutes? I thought I'd do mock, but I think we don't have enough time for mock. Yeah, maybe we can open up for more people to discuss some questions if they have from what we have talked now in five minutes. Yeah, I think that's the best idea and we can do one or two session later where we assume that all of this has been covered and then we do yeah. I think we can use this recording as prerequisite for the next time and then we can take a continuation of it. Okay. So Robbie here has asked how do you join as package maintainers? Right? So I think that's what I'll cover as a last bit. Joe, now because when you think of Fedora, when you think of source code, it's actually many, many different packages that are all installed together to make the operating system. When you're building your RPM, you're not actually touching the you're not actually touching your file system at all over here. That's why it builds a different build route. But yes, it's good to be careful about it just to be sure. Right. So in the last few minutes, let's have a look at how we can join up to become package maintainers. Somebody's already shared the link, right? So this is the page you start with. Initially, it'll tell you to create your Buzzer account, your Fedora account. All of this is required to access the infrastructure. Somebody has asked where can access the recording. The recording will be made available after the session. We'll try and update the Fedora magazine post with the information. Yeah, it also will be on YouTube. We'll share it by Twitter and magazine post comments. Okay. Yeah, then you should join the mailing list because it's quite important that you're part of the community. You need to set up Git. I think most people should have that set up already. You need to install Fedora Packager which we installed for this session, right? Now, the first step is of course to find something that you want to include in Fedora, right? You need to download the source code and you need to be able to build it from source on your own, right? So the first step is to figure out how something builds. As you saw in the spec file, it is literally a set of instructions on how to build it. So if you can build something from source on your system, it is generally likely that you will be able to put those instructions into your spec file, right, to build it there. The first step after you've managed to build your RPM is that you need to file a review request, right? The Fedora follows a peer review model when it comes to packages. So if I package something up, I'll file a review request and then somebody else from the community, another Fedora Packager will review my package to make sure that it complies with the Fedora guidelines, right? So this way we help each other. If you are on the developer list, you'll see that a lot of times we ask for review swaps, which means I've got this new package I need reviewed. No, on and off. Any package maintainer can do reviews. Proven packages are different, right? All package maintainers can review other people's packages, right? And it's encouraged. But the idea is that I have a new package that I want reviewed. Mandy, I think some of the questions are probably likely out of scope. We'll answer them on a discussion topic, perhaps. Okay, sorry. Okay, so for example, I can show you a review request. Let's see what I have. So this okay, so the link is there. I'm looking at there's also a review package review status tracker. So have a look at this, right? So it lists packages are waiting for review packages that are in progress and so on and so forth. But you can go there and look for different packages and see if there's something you want to review. What you're seeing now is an example review request. You can see Anil had filed this review as the maintainer. It was assigned to me so I was doing the reviewing. You see we upload the spec and the source RPM because as the reviewer I need to be able to rebuild this and test it out. And then a review is basically a discussion and back and forth of issues that need to be fixed. So for example, you can see I've given a long list of issues here. Then Anil's made some changes to it and corrected these issues. Then I go on and make some more comments and so on and so forth. At the end of this the package will be approved. Which is very odd because I thought we have out there we go. But the ideal scenario to make sure your review continues to be reviewed is to email on the devil list, right? Because all us package maintainers will be looking at the devil list. If it gets stalled, what you can do is you can set the need info flag which will send reminders. If the reviewer is stalled, it's best to wait for some amount of time before well asking somebody else to take over. If the person that submitted the review has stalled then unfortunately there's not much you can do because they need to make the changes required for the package to be accepted. If somebody submits a package and after a while they stop replying to review comments then we end up closing the review ticket as a dead review. And then the idea is if somebody else wants to package the software they can come and take on. It depends on which side gets stalled in the review. This is the review. As you can see I went on and reviewed this for me. There's quite a bit checklist but you can use Fedora review. If you do and have a look at what that does it will run all the basic checks for you. It's not completely automated. You still have to do some work manually. And then at the end of it, when this gets approved as you can see here I file a ticket and a repository is created for me. If you're looking for the commits you'll see that the first commit comes from somebody from release engineering. The release engineering team takes care of all of this very co-infrastructure for us. They create this repository after which I'm able to push my files to it. So it's got the same files it's got a spec file as you see there are two extra files which have included the sources. At this point your package is in the source repositories. Once you've done that you can then so this is how you use Fed package import that will pull everything from your source RPM onto your repository. You commit, you push and then to build your package you don't Fed package build. And I can show you the code you build system. So if you go there you'll see all the builds that I've pushed for this particular package. Now at this point you submitted a package it has been approved. You've imported it into Fedora, you've built it. The next step is to go through the quality assurance system. So the idea of the QA system is for example let's look at the first one. So we create an update and it stays in this update for some days and allows people to test this package. You can look here. So for example for this package there wasn't any negative karma saying that no it doesn't work. In which case we were able to push it to stable in seven days time. When it's pushed to stable then it ends up in your update repository and you can install it using DNF. That's kind of a really really short whirlwind tour of how to go about this. But all the information you need is on this Wiki page. And the best thing to do is to subscribe to the devil list and just ask whatever queries you have. Pretty much all package maintainers will hang out there. The community is extremely helpful. We always want more and more people to join up as package maintainers because quite frankly we have thousands of packages and the more package maintainers we have the more software we'll manage to keep included in Fedora. I think I'm going to close this because unfortunately I need to run off for another meeting. How about this? How about I create a discussion topic on discussion.fedora.org and all of the questions coming in now can go there and then people can discuss and thanks a lot Angur. I'll stop recording right now and if people want to stay back and discuss for a while that's totally all right and we'll also have some following classroom we'll discuss and discuss with Angur and more classroom wranglers on when we can organize it and look forward to the recording. It might end up on YouTube. We'll update the magazine post as Angur said.