 Hello and welcome. My name is Odin Parmax and I'll be talking about packaging Rust applications for Arch Linux. So here's a little bit of introduction about me. I'm a free and open source software enthusiast, which means I like to create open source projects and contribute to others. I'm a Rust developer and I like to learn new stuff. You can find more information about me on my website or on .dev. So Rust programming language. Rust is a multi-partline programming language focused on performance and safety, especially safe concurrency. Version 1.0 of Rust released in 2015 and since 2016 is the most loved programming language according to the Stack Overflow Developer Survey. So why Rust? In this section I'll be covering some of the reasons why we should prefer Rust. So first one is performance. Rust is blazing fast and memory efficient, with no runtime or garbage collector. It's reliable because it's type system and ownership model guarantee memory safety and thread safety and it enables you to eliminate many of the bugs at compile time. Rust is a general purpose language. It means that it's appropriate language for any type of programming. It's project oriented. It has an integrated build system and package manager called Cargo. And Cargo comes with great tools like auto format and lint checker. Then lastly it's well supported. It has a wide community and great documentation. So applications. We can do pretty much most of things using Rust from command line tools to embedded programming. And it's well suited for low-level Linux systems, user space programming. So you can write them services and command line tools using Rust in Linux. And it's because that Rust provides a robust configuration. It will deal with namespaces and formats for us. It can generate manual pages for the application automatically. And it has a lot of logging libraries and you can configure them with different targets and with different styles. And it's easy to distribute a Rust application in Linux because everything compiles down to a single binary. And there's no need for users to have a runtime or libraries installed. Everything is handled by Cargo. And lastly, you can communicate with machine using Rust which means that it supports many of the output formats. And actually there is a quote from the UNIX philosophy that is in the official Rust documentation. So because of these features, there's a meme on the internet called We Write It in Rust. So there is a packaging demo and I'd like to give a disclaimer before I start to demo. And more up-to-date information may be available on the Wiki pages. Here are the Wiki pages that I'm using right now. And latest standards can be found there. And when in doubt, ask for help in forums, mailing lists and IRC. So I'll start by installing Rust. I'll use the Rust app package for installing the Rust tools. Then I'll use the stable tool chain for the demo. And I'll create a new project. I'll name it Conf. It will be a binary. Then I'll use the Git as VCS. So it will utilize a Git repository inside the project directory. Then we can go in the directory and see our Tamil file is pretty much empty. It contains just the basic package information and dependencies section is empty. Then we can see our main.rs file is just a simple hello world program. And I'll go ahead and run it. Then I'll commit the changes. So I'll be using a create call device query for demonstrating, for creating an app actually for printing the mouse coordinates. The device query uses the X server for querying the mouse and mouse coordinates, mouse details, and keyboard details, etc. And I'll use the device query for simply printing out the mouse coordinates in my little Rust program. So I'll go ahead and assume that it depends on libxcb, which is actually a false assumption, but I'll be checking the libxcb for now for proving a point afterwards. When we create the package, I'll show you how to detect some of the things like false dependencies afterwards. So I'll go ahead and check if the libxcb is installed. It is installed and I will add the device query create to the dependencies list in the cargo Tamil. I'll update the main.rs file for printing out the mouse coordinates. It's actually an example from the device query create. It's from its documentation. Then I'll go ahead and run the Rust program and it will print out the mouse coordinates. We can run it multiple times to see if it works. Then I'll use the fmt tool for formatting the code if it's now formatted. Then use Clippy for checking the links for seeing if my code contains any of the common mistakes. Then lastly, I'll check the code again, which is not necessary, but I'll check it and I'll build a release binary from the little conf project. Release binary is created in the target slash release directory. You can go ahead and run it if you want. We will be installing this binary and other details in our Arsling package. The other details are the license and readme. I'll add an example license and readme to the project. License is mit and readme does not contain anything fun. Then we go ahead and commit the changes. Then we'll create a tag for versioning our application. Then we can use the git archive command for creating an archive from one of the branches. I'll use the master branch, which is the default branch. It will create an archive in our project directory. Then we can start writing our package. I'll go ahead and create a package directory and I'll copy the archive into it because we're going to use the local files for our package build. Package build is what we need for Arsling's packages. Package build essentially contains package details like package name, description, and it contains some functions for installing that package or building that package on our Arsling system. I'll go ahead and create our package build here. I'll explain some of the fields. The first line is actually maintainer tag, which means I am the maintainer of this package. If we push this package to AUR, it's important to add the maintainer and contributor tags to the package build. Then we will have basic information like package name, package verb, which is the version. And package drill is the release version. And the description is, it should be simple because it should not self-referenced package itself. We should use the simple description, architecture, and URL will be empty because we don't have any upstream URL that we need for this case. So it's empty. The license is MIT. My package will depend on the libxcb package, but as I said, it's not true, but it will build anyway. I'm going to show you how we can detect the actual dependency when we proceed with the package. So make-depends is cargo. We will need cargo for building our Rust application. So source is the archive we just created. And sha512 sums, it will be skipped for now because I want to show you a really convenient way of filling this array with the correct sums. We can do it manually, but I'll show another way. And the functions are build, check, and package. Build will check the code for compilation arrays or if anything like that exists in the code. Then actually a target there is here is not necessary, but I wanted to add this because I wanted to talk about it because most of the time it's missed. Actually, the default directory for the Rust applications, the default build directory is target, but we can actually change that with the environmental variable. So if that's changed, we use the target there with the cargo build command for indicating that we want this project to be built in the target directory. So in this case, our target directory, the default build directory is already target, but we can change that. So it's unnecessary but it's there. So we go ahead and cargo build with release, flag and locked will mean eventually the cargo locked file should be up to date. Then check will run the tests, although we don't have any tests. It's just running the tests. And the package function actually installs, it copies the necessary files to the correct locations. So we are copying the release binary inside the target release directory to user bin. And we are installing readme to user share doc. And license is important because normally if we are using a license like GPL3 or GPL2, we don't have to install the license because it's in the user share license, license is a common directory. So if a license is in that directory, we don't have to install because it's installed in the system as a default license, but MIT is not installed. So we have to install the license to the user share licenses manually here. So we are doing that. And we can go ahead and use Mac package for building the package. See if it's going to build. Then we can see it's fine. Everything looks okay. But we are missing the SHA 512 sums. So I'm going to use a script from the Pacman country package, which is update package sums. It performs an in-place update of the check sums in a package build. So I'm going to use the update package sums for updating the check sums in the package build. Then we can use a tool like NAMCAP for checking the common mistakes in package builds. It can give false positives sometimes, but it's overall a great tool. So we can go ahead and say NAMCAP package build. It didn't print out anything important. Then we can go ahead and check if our file locations are correct. Basically we can do that with the tree command. We will just go into tree the package directory to see if anything is not in place. So we see that everything is fine, but the more convenient way is using the tar-tf tar command with the tf arguments. t means list and f means we're going to give it a file. So we are giving it the archive we just built, and it will print out the contents of the archive so we can see what we did with the files everything looks in place. Cool, then we can create our SRC info if we want to push this package to AUR. Then I'll go ahead and create another package here, which will be a VCS package. I'll use the latest state of the git repository for building the confpack application, confrask application. So I'm going to create a new directory called VCS package. I'm going to copy the package build we just created because we just need to update some of the variables here, like the package name. It will be conf-git because we are using git as VCS. Then we can update the package description if you want. Then we can go ahead and add the conflicts and provide sections. Inside there we are using bash parameter expansion for removing the git suffix. So it will conflict with the conf package and provide the conf package. Then I'll update the source array, which will use the local git repository. Then sha512 sums will be skipped because we don't need that. Then I'll update the package word function for the package word is actually invoked when the package is building. So it will be invoked for updating the package word variable itself. So I'll go ahead and update that. Then the rest is the same except we are removing the git suffix from the package name. So we can go ahead and use NAMCAP for the package build we just created. And this time it will show something because I missed something on purpose, which is the git make dependency. So we need git as make dependency because we are building a VCS package. So I'll go ahead and add the git here. Then we can see it's built just fine. Then we can check the file locations with the tard-tf. Again, everything looks in place. Cool. Then if you want to, again, if you want to create the SRC info, we can go ahead and do that. And like I said, I used the libxcb for the package dependency, but it's not actually correct. So I'll use a true, I'll create a true environment for building our package in a clean arsenic setup. So in Dell tools, we need some of the tools in the Dell tools package. So I'm going to go ahead and install that. Then I'll create a truth directory and set a environment variable for it because we will need it. And I'll use the make arch-root script for creating an arsenic's truth at a specified location, which will be our truth directory. And I'll install the base-developed packages inside it. Then I can use the arch-n-spawn command for truthing in the directory and running a command inside it. So I'll go ahead and update my simple arsenic's clean arsenic setup inside our truth directory. Then we are ready to building our package inside a clean arsenic setup. So I'm going to go into the package directory and use make-truth-package tool with the C and R. C flag will mean it will clean the truth before building it. And R means we are using the truth directory with the environment variable we just set. So we go ahead and run this command and everything should be fine. But we are seeing that the package didn't build. So this is why we used libxcb, but libxcb can be installed without the eq server itself. So we need libx11 for the package to be built. So I'm going to update my package build and add the libx11. In fact, libx11 depends on the libxcb, so we don't need libxcb at all. So I'm going to remove the libxcb from the package build. And when we use that same command again, it will build just fine. And I'll update the VCS package as well. And we are ready to go. But there is a regular convenient way instead of the classic truth, which is built, which is extra x8664 build, it will use the presets from the presets directory. And it's actually easier for us to use this command because we don't have to deal with the other truth stuff. And we can go ahead and do that if we are actually, this command is used for the official packages because it's convenient. We don't have to, like I said, we don't have to deal with the truth itself. That was the classic way. So that is it for the presentation and demo. I try to show you how to create a Rust application from scratch and package it for arsenics. I wanted to show some points with the missing fields and the false dependency. And I think I showed how to detect the false dependencies and how to detect other mistakes in the package build. So that is it. Thank you.