 We're going to go ahead and get started with the session. So this is the second year that we've done the showcase. We're going to have a chance to hear from all of the different interns in the different mentored summer coding projects that Fedora is involved with and get to hear about some of their project work. You'll also learn about some of the different mentored projects that the programs that Fedora is involved with. And you'll also get to hear from a panel of mentors later about different career opportunities in open source, best practices for mentors and other opportunities to get involved with the Fedora community. Before we get started, I wanted to say a big thanks to our program administrators, Sumantro, Brian Axelbeard who could not be here, and Laura Abbott for Outreachy. So they do a lot of work that's in the background and is not super visible all the time. So can we just give them a big round of applause for all their hard work. So a quick overview of how this is going to run today. You'll hear a little bit from our different program admins about the different programs we're involved with. We'll do the FERT, we'll do five interim presentations to start off with. We'll switch to the mentor panel after that. And then we'll wrap up with the last four. And any leftover time we have will be unstructured, social time, hang out and chat a little bit. So with that, I'm going to go and hand over the mics to our program admins, Laura for Outreachy and Sumantro for Google Summer of Code and Google Code In. So Laura, do you want to start off with? Good morning, everyone. For those who don't know me, I'm Laura Abbott. My official job pedal is Fedora Kernel Engineer. But one of the things I also do is coordinate the Outreachy program. For those who aren't familiar with Outreachy, Outreachy originally started as the GNOME outreach project for women, started by the GNOME Foundation and was designed to help get more women into open source because based on their group reviewing statistics, it was found that there were a remarkably few number of women contributing to Google Summer of Code. Since then, the program has expanded to include other underrepresented groups in open source. And today it's just known as Outreachy. Outreachy is run twice a year. It's designed to give underrepresented groups a chance to contribute to a full-time project. It's paid. It's all various groups of open source get a chance to contribute. Fedora has done it off and on over the past years. Fedora did it during when we were still GNOME outreach for women. And I think that's about all I have to say about Outreachy right now. I'm happy to talk more about it offline. But once again, thank you for everyone who has done it in the past. I feel I should acknowledge Mo Duffy who did coordination and helped run the program somewhat before I took over as well. And yes, thank you, everyone. Thanks. Hey, good morning. I'm Shumanthro. And my official job title is Fedora QA. And I coordinate with Brian Axelbeard for Google Code in and Google Summer of Code that I'll be talking about in a bit. So Google Code in has targeted towards 13 to 17-year-old high school students. Essentially, the purpose is to serve as a starting ground for students to get familiarized with open source, the culture, and the ethics, and how they can start writing very small programs or documentation, QA, anything for that matter. The idea of Code in, so Fedora did not participate in Code in for a long amount of time. This is the first, last year was the first time, or rather the second time we did it. And we ran super successfully. I would like to thank Vipul who has taken part in it as an org admin. And he has done a fantastic job in making sure that we did the first Code in right. Fedora is supposed to participate this year as well. And we are hopeful to have more mentors who would help us understand our right tasks for students. The idea of like, so when a person or a student graduates out of Code in, they can actually go ahead and have something like Google Summer of Code. Summer of Code is mostly like a full functional project. And it's not just small tasks that they have to finish. It's mostly about a full functional project. And you would kind of see the mentees showcase their projects and how they have been working on the whole summer. The idea of Google Summer of Code was to kind of make sure that a person understands the philosophy of the project. They kind of bond with the community. And then they try to adopt the best practices that the project follows while they are making the software. So essentially, you would find most of these mentees talking about the number of challenges they're faced and how they overcome that with the community. And you would basically find more and more people getting involved in Google Summer of Code. As far as the statistics goes, there is a lot of contribution coming out from India. There are a lot of contributors coming out of India, which is good for us in terms of how we scale up the Google Summer of Code in the coming years. So yes, I would more than enough interested to talk to any one of you about how we can make Google Summer of Code and GCI better in Fedora, so moving forward. And that's mostly all about me. Thanks, everyone, for coming here at least. And I would like to move on with the project showcase. All right. Thank you, Laura, and thank you, Sumantro. So here's going to be our outline for the presentation. So we'll go ahead and get started with the crank presentation first. And we'll take a break about halfway through for coffee before we start the mentor panel. Lenka, are you here? Excellent. Hi, I'm Lenka, Segura. I'm an altitude intern from the past winter round. My mentor is Alexandra Fedorova there. And my project was to create a command line interface tool, which I called crank for Pakur. It's playing the second video, not the first one. So this one is about creating the pull request. There's necessary a title, and you see it's not possible. It doesn't work because an API token is necessary. So what's happening? You go to crank. You see command crank config. And that prompts you to get the API token on the web page. Then there is a tool which helps guess the URL of repo and the domain URL. And it works. The pull request is open. And you can also merge it with crank merge PR. You need the request ID. And it's successful merged. Yeah, it's there. No, there's the second video, which is the first video. This one, yeah. So this one is about getting the PRs and the issues. Crank get issues? No, this is the old one. They're the same. I have them here on my laptop. Yeah, that's the same video. OK, never mind. So the first video was about commands crank get issues and crank get PRs. For this, it's not necessarily an API token. And it's always done from the current directory. And yeah, I tested it. It works. If you want to try it for yourself, it's uploaded on PyPy. You can put pip install crank, should work. And OK, I'll have to continue with my presentation without slides. So what I wanted to say is that what I took away, there was a lot. Community-wise and tech-wise, I learned a lot about what pull request is, what is the workflow. I learned to think about the user experience because before writing it, I had to do the research, check the other command line interfaces, think about the structure of the commands. Not to be so they would not be random. They would follow some structure. And also take away a lot of community-wise. Got involved in the open source community. I even made a package for Fedora. So I have Fedora packages with one package. I would like to thank all who are organizing outreach programs in Google Summer of Code because it was an awesome experience. And I was even able to get the job after that. Yay. Thanks for your attention. All right, so next up we have creating a seccomp profile for a container using Podman. Hi, everyone. I'm Devanj. So this summer I was working on generating, working with Podman with Valentin and Dan. Dan couldn't join you, sadly. So I was working with Podman to generate a seccomp profile for individual containers, so generating a seccomp profile for container using Podman. So what's seccomp? For those who don't know here, the seccomp is a Linux security feature which blocks, which filters, is called by a process. So almost every container engine uses a seccomp to secure the container, secure the host. So Podman ships with the default seccomp profile, which blocks around 44 syscalls, which is really loose for certain workloads. Because we don't need a lot of syscalls. Like you want to run LS. You don't need around 200 syscalls to run LS. I skipped a thing in between. So let me talk about Podman first. So Podman is a container engine, which just like Docker. So Podman is designed to run OCI containers in pods. And containers can run in rootless or root mode. So that's pretty great. It works on the fork exact model rather than the demon model by Docker. So it's a tad bit lighter than Docker. So yeah, I was talking about why I worked on this project. So the idea was to trace all the syscalls made by the container and generate a seccomp profile using all the syscalls. So how? The initial proposal I wrote involved using ptrace. So ptrace is a syscall which gives the command of the sub process to the one, the process above that. At every step and the process can inspect its registers to check which syscall has been run. So the initial proposal was to use ptrace to trace all the syscalls made by the container. But there was a problem that ptrace slows down the running of the container and some time-based decisions can be affected. Also ptrace can't, I wasn't able to get all the syscalls using ptrace because some syscalls are required by Run-C which makes the container before applying the seccomp profile. So after that we tried using the audit daemon in the Linux kernel. When you apply a seccomp profile you can either block it or log it or trace it and many other things. So we tried to log every syscall made by the container by applying a profile which logs all the containers, logs all the syscalls. But the problem we encountered there was that we weren't able to figure out in a nice way that which process belongs to which container and is it in a container or not. So there was a workaround about that. The audit daemon was adding a container ID to the audit system but that couldn't be merged in the right time so we had to move past that. Then we tried using evpf to trace all the syscalls. So what's evpf? evpf is extended Berkeley packet filter. So seccomp is also implemented in BPF. So BPF was also used in filtering packets and all but now it's extended and you can write your own programs to run inside the kernel rather than writing kernel modules. So it compiles on the fly and attaches to certain code paths in the kernel. So in order to trace all the syscalls we made, it's now used in making tracing tools, networking tools and a lot more. So it's still being explored what can it do and what not. So this summer I had two things to do, research and implement the tool and more the tool upstream with the help of the mentors. So the PR is still open waiting for some CI fixes. Other than that the tool is working and it runs on a simple interface. So you have to pass annotations to the CLI and then it generates the profile. You have to provide it the path of the, name of the file you want to create and then you can use the profile. So the major takeaways by working on this project this whole summer was that it may sound silly but after doing this project I feel like I didn't, before that I didn't feel that there were people on the other side of the screen like I couldn't approach people or something. So after the project I was like, if I can approach everyone, people are willing to help it's really great awesome. And like I had some initial anxiety about contributing to open source. This project helped me a lot in getting started and yeah. So working on the logistics of a large project. So earlier than that I had encountered CI and working with huge project with many levels of abstraction and I had to work my way through it and write that and working remotely. So I thought that working remotely is really, really hard and I don't know how I'll do it. So fortunately I was able to work through that. Yeah, thanks. Thank you. So now we have the Fedora Gui Karma presentation. So what I worked on is the project is Fedora Gui Karma and it's basically a user interface for Fedora Easy Karma which I guess most of you are familiar with. What it does is like it connects with Bodhi and lists the packages that are available on Bodhi and lets you post karma and basically that's pretty much it. So let's go to project demo. So this is what my application looks like looks like when it started up. You have to first log in. I'm fetching the packages of old releases because I don't want to spam the new ones. So yeah, it works. I logged in. So now what I'll do is I'll fetch packages. Yeah, so Bodhi servers are pretty slow right now so it takes a bit of time to fetch some packages. Then let's get Python, Pysoc package. I get to post a comment. So let's say I'll just post it works and the karma is 0 minus 1 or 1 and then I'll just select 0 karma and then submit. Wait a second. Yeah, the karma is posted. You can fetch it again to get the different karmas that are already posted. It should show your karma after you fetch it again. It works basically. And that's pretty much it. What did I take away? So before this I've never contributed to a community or a big project which has already been out there. So working with a community is a nice thing to do. It's nice. I liked it. And it was also nice working with people I've never met before. So I was working with Sumantro, my mentor, and I've never met him before, Flock. So yeah, it was nice working with him. Yeah? Good morning everyone. So I'm Alesha Mahanpe. So I'm an outreach intern working on Fedora Happiness Packet. So I'm here to share my experience. So what is Happiness Packet? So Fedora Happiness Packet is a platform where we send emails and messages to people showcasing, like, sharing our love and gratitude for them. Then Fedora Happiness Packet actually aims to make people feel good about themselves. I know, like, in our culture, like in Fedora, we actually do that, but using Fedora Happiness Packet, we just make it a bit explicit. Then we have Happiness Archive in our website which aims to, like, which is a kind of a hub where all the messages that we have sent is being showcased. So we just need, like, the messages that are being sent in order to showcase the Happiness Archive, so the sender has to agree along with the recipient, and then, yeah, it gets showcased. Then, okay, when we have the liberty to showcase love and greetings, we also have the freedom to use it strongly. So if we get an abusive message so we can blacklist the person who sent it, we just report to the admins of Fedora Happiness Packet and what is an abusive message, okay? Anything that disobeys Fedora's code of conduct, anything like any harsh comment or any hatred or any all the bad stuff is what is an abusive message here. So what are the privacy concerns? Like, when we send a Fedora Happiness Packet to someone, then the message gets sent to the recipient via an email, and it is, and if the person agrees to showcase in the Happiness Archive along with the recipient, then it gets showcased in the Happiness Archive. So that's, so what I did in the project is that I implemented the fast user search, user search where we can send a Fedora Happiness Packet to any of the fast users with the knowledge of only their fast user ID just to try their mails and name, and we can send them Happiness Packets. Then more of my project was concerned with testing Fedora Happiness Packet. So now we have a test coverage of almost 93%, and I'm planning to increase in the forthcoming weeks. Earlier Fedora Happiness Packet was tested using Django's unit test, so I migrated the test to PyTest, which is really a good platform. Then I also ensured that the test cases are robust, and okay, I got introduced to mocking, and I tested the fast user search that I implemented by using mocking with PyTest mock. I also incorporated FedMenu so that it gets connected to the rest of the Fedora applications. I also improved the discoverability of the admin portal by incorporating it in the UI so that it can be more accessible. Now Fedora Happiness Packet is an fork of Happiness Packet, so the UI is very similar to the Happiness Packet and not consistent with the rest of the Fedora's UI. So I designed FHP for consistency with the rest of the Fedora apps. Those are my accomplishments. Now the takeaways are the good programming. My takeaways were always the documentation does not come that handy, so I referred to blogs, and for a beginner, blogs come more handy and useful because we get a deeper insight and does not get lost in all those technical terms. Then I was very lucky to have an awesome mentor, Justin, who was very helpful, and every time even I was very free to ask silly doubts. So thanks, Justin, for that. Okay, there's always a way. So what happened? I asked Justin if I could incorporate a functionality, and I thought if that functionality already present, and Justin said if it's not, we can ask the maintainers to make that. So it was easy. I thought like how it could be, but yeah, there's always a way that what if I like, the things we think that impossible, that can be made, actually. We just need to minimize the gap between that existence and our knowledge of knowing it. And also, I feel rereading documentation is also handy because the first time we read documentation, it's very overwhelming for mine, but as a beginner, so every time I reread the documentation, I find something new, something interesting, and something worth learning. So here's nothing as impossible. Thank you. Now we have one more Happiness Packets presentation. Hello, I'm Shraddha. I was working on Fedora Happiness Packets as well, as Alicia just explained. So I was working more on the backend and the day-waps part of it. So my first job in this was to integrate batches into Fedora Happiness Packets. I migrated initially, Fedora Happiness Packets had FedMessage. I migrated from FedMessage to the new Fedora Messaging. Then I also made a PiPi package for the Messaging module. For the same, I made an RPM package as well. I made the YAML rules for the batches. And while integrating Fedora Messaging and making the RPM and the PiPi package, I encountered some, in the documentation, like some additions that I could do, which I also integrated. In the backend features, I made the Web Access, I made the Web Interface for the sender and the received messages so that you could change the privacy settings. I also migrated the entire application from Python 2 to Python 3 and from Joinko 1.11 to Django 2.0. I wasn't expecting that. Thank you. I also integrated the Visivic text editor, so now you can, like, send fancy messages too. So during the development, we had this really tiresome issue that we always had to build the containers again. So I also made the auto-reload code change so that it could be done, like, on the fly for the backend as well as the templates. And I also made the custom admin interface as well as, so, automatically admin access to a couple of users which are in the config files that will be automatically given. Apart from all of that, I was also working on deploying the entire application on OpenShift. That is still under progress, so I didn't put it up on the slides. And, yeah, so my takeaways from the entire thing was I am not very good with communication with people, even face-to-face, so, on a screen, that was even more difficult. But, yeah, Justin was an amazing mentor. He made the communication very easy. If she's here, she was awesome. Alberto, so, I had great mentors which made that part really easy for me. And documentation, definitely. I was working with MiniShift, OpenShift, Python 2 to Python 3, Django, and a lot of that required documentation. I had to look a couple of places for Fedora Messing as well. So whenever I encountered something which could be improved, I definitely contributed to the documentation as well. So, yeah, that was me. Thank you.