 So I'm going to make a presentation, the statue of Erpenfusion, of this third-party community repository. I'm quite, it's quite interesting to make this presentation at this time because, for example, we have some issues with the infrastructure currently. So I'm quite pleased to make this presentation now to explain to you what we need as a project and what we expect to fix in the next months or the next federal release. So maybe I will ask some questions about who are using this third-party repository in the room. Maybe others are not using this repository and no people that are not using third-party repository in February. I think that exists also. So maybe some of you know people that don't use third-party repository. Everyone is using any third-party repository. So this is a commonly used repository, maybe, but I think there is some people that don't use this repository. The fact that we are making this presentation within the federal event is quite interesting and I'm pleased that some of you maybe have chosen this presentation because that's not a community repository that is some kind of band from Fedora. It can be discussed in the Fedora events because we often try to not say the name of which repository, which community repository can help users in the official Fedora mailing list. But we all know to explain to other people and users to install this repository as needed. Maybe it's not always needed, but when it's needed it's very useful to some users. I'm not going to enter into the details about what are the different sections in this repository. This is not a topic, but instead I'm going to describe the different point of view that might interest the user and the different states of this third-party repository from user perspective and developer perspective or contributor perspective. So this is the different topic I will try to address. I just will start with a few words about me. So I'm French, I apologize for my accent, my English is not very well, but I'm living in Paris and I've studied architecture. I'm architecture design in the school of the Beaux-Arts in Paris. So I'm not from computer studies, but I've entered in computers and free software using tools to do rendering and images. So I was interested in this area from my experience with architecture. So maybe something about this, something I studied at that time was that in architecture you have to follow some rule from carbonism and try to obey this rule to get freedom and try to get freedom from certain, some kind of rule. And it's something I try to find in my work and working with package and trying to solve issues that need to be solved within a certain kind of rule. So I'm a federal package manager since 2007 and I'm working for a Linaigoura French company which is doing only free software and open source since 2009. So I'm making a little bit of work on the Linaigoura later. Then I'm a coordinator of a third-party repository since 2011. And I'm with Incarnation, which is my wife since 2013. She's in this room. So she's supporting me and as a consequence she's supporting the project also. Just few words about what I've done in Linaigoura. I'm working in a company that is well aware of free software and open source. I've worked, for example, on the left is a project by G.C. Deco who is trying to build a dedicated OS for display image in the airport and some place. And it's a project with orange for the desktop of commercial. So from this project I've tried to play with ARM device and light desktop. So I'm quite interested in trying to work with ARM light reliance from this experience. That's why I try to push that on this third-party community repository. And this project on the left was made using Fedora. About this third-party repository I've made some stats, a little bit of stats. We'll see later. It's a project created in 2008. It was Fedora 8 also. Quite some time passed in Zemps. So it was merged from other community repository or personal repository. And it's still using Plagg. It was using Plagg at that time when Fedora was using Plagg. So Plagg is a build system. I think it's also used by Centres in Germany. They are using Koji for the external interface with Google. Building dedicated spin and they are using Plagg internally. And the idea is to follow the Fedora process and the idea whenever it's possible. We have some kind of plan guidelines that is meant to be stay as close as possible as Fedora. But we are actually a different project. Quite funny things was that appeared some time ago when some kind of special interest group made a decision. I think it was the KDU once that made a special decision that they need to install some kind of library by default in the build group. Because they want to circumvents some kind of issue. They had with G-Streamer and VLC. So it was kind of funny that they made this decision in this SIG meeting. And that decision applied to us as a project, as a supported project. That's quite funny but actually we are different projects of different way of making decision. And of course there is different people involved. So some of them are the same. Some little stats. As you can read there is a 200 source package in the free section for 18th-7th in the non-free section. We have been in the primary architecture. FEDORA ARMA is a new primary architecture starting Fedora 19 or 20 maybe. And we have made this as primary in Fedora 22. It's using the same question and stance as the other x84 build. There is around 5 GB of software for Fedora 22 release. And there is around 150 packages in the FAS project. And a little bit less in CBS. Some people using FAS for the project. There are not only packages. There are also people involved in the infrastructure and some others. As you can see this is from a daily snapshot of people from the US. It's one quarter of the circle that are coming from the US. This is statistics taken from the mirror of the list. The public mirror of the mirror. It's actually statistics from the mirror manager. The statistics shows that it's the same as Fedora as we have seen this morning. There is quite the same difference between x86 and 64 and x86. That's quite the same separation. Arm is around 1% less than 1%. This is the same. We can see with Fedora this is the raw statistics taken from the mirror manager. We probably don't see the difference. The blue area is Fedora 22 in June. There is around 5% in August. There is 15%. We show the same result as the Fedora infrastructure. This is quite a similar result. From a user perspective, I was trying to figure out what users are seeing when they use the project. Which is the process they follow to use the project to install the package and to get in relation with us. The first step when they use the project is probably to get into the wiki. What's our thing is this kind of infrastructure with the wiki. This is the front page of the project. There is quite a lot of area to improve in this area. There is some kind of documentation to improve and to get a better front page to move the Fedora support release. Maybe in the first place to get better support. The principal information for them is probably to get into the wiki and to grow the user process to install the package. They are going to install it from a common line or graphical install. From the user's perspective, the wiki is probably something that is under used. Because they probably don't find information to install their package or not each package has a wiki page. The method to install one or the other package is not addressed in this wiki. Maybe it's addressed in the upstream wiki but not the part that is dedicated to Fedora is addressed to this wiki. It's also a wiki that is free for anyone to conflate it to an open wiki. We had an issue with that some time ago because someone tried to edit the front page to show us advertising and spam. We tried to lock a certain number of page and to restrict some areas of the wiki. For example, the page that is displaying the GPG key that are certified to work with a given Fedora release for the project is locked. There is even a translation. Some pages are translated to Spanish and of course everyone is free to contribute. When the user installs the release, they try to probably install manually the release package that are trying to bring them to the project contents. They are also using a post-installation script or they are trying to use the project within the installer as they are enabling the repository in Anaconda. I don't know if it's still supported and if it was very well tested. Other methods to install the project was probably to use kickstart and to default the kickstart installation process. I don't know if it's really used but maybe it's some kind of process we can try to work further. So we can issue the full kickstart install automatically and install the RPM release package. So it's installed by default. I think it's quite interesting to address this issue because from my understanding the desktop DIM is trying to think about that kind of issue. For certain users it's not that easy to install additional packages because that doesn't come from source. That's not easy to think about to install additional packages every time we need additional packages from our community. So this is maybe a start for reflection about how this installation process is because that was also addressed in several many lists in the project. Not always, not everyone is fine with having this community repository installed by a different federal and that's fine. We are trying to work with this simple rule that we need to deal with. So of course this provides an Ansible Playbook that can be involved in the process but that's probably someone else doing the work. Like an admin that's installing the package for their user and that's perfectly fine. Maybe we can have a different playbook that we can find several. Of course there is this question that is quite open also that we might also try to build on media to build the package by default to the installation media. But that's not something that we would like to do because it would mean doing a separate QR process. And this is not very, I'm not very fond of that because that's some kind of we're doing the federal process and it jacking the federal process of the QR. But also we can leave that for our downstream user and not speak too much about downstream users of the interface. But there are a lot of formings of federal release that probably do the job well for this kind of process. Actually if we distribute media with RP Infusion packages on it, you don't know if the repo file is okay or not. But imagine you also distribute some RP Infusion stuff on the media. You can no longer call it Fedora and you need to re-brand it. And by that you basically create the form for remix and such forms of remix already exists. For example, Korora, which I don't know if it's actually in, I met it a few years ago, but it's basically Fedora with RP Infusion and something else. So we cannot easily distribute Fedora with RP Infusion in release just like that. Yes, I think that was my point of view a few times ago. But I think the remix process, maybe I'm saying something wrong, but I think as soon as there is something like 40% or 50% of the packages that come from Fedora, additional packages that might come from Fedora in a couple of repositories or something else might be good, I don't know. But yeah, that's kind of the reason why I'm not particularly fond to work with the media process. But then let's leave this question up on how to install the release package for users. Because the next step for users to install packages is to discover which packages they really need, like installing the whole multimedia stack, the restrimer and the other multimedia application. The way we tried to address this in the previous release was using groups metadata. And this was quite surprising that it works. I think it was a huge feature at that time that when you install a group of packages, it will install additional packages as soon as the package layout moves. So if you add a package to a group in NUM, then as soon as you have installed the group, the package will be there as an update automatically. The interesting thing was that if as a request tree we are using the same groups, some additional package could be installed and we could control some kind of additional package that could be installed within Fedora installation. So it was quite an interesting feature that was introduced in Fedora 20 maybe later. But I don't know if it still works because that was also surprising to have this behavior because we tried to build the same groups names as Fedora to match the group layouts. And it's then a static package that wasn't expected for a given spin. For example, it has installed the NUM carrier where most users didn't like this package installed by default, even if it's related to the NUM desktop. So that was quite an arbitrary package so we disabled this package but then it was also probably a security issue because additional requests could then install a package that users didn't want by default. So as soon as we don't ask the provider of the package, maybe it was some kind of issue with that thing. Another way to install a package was using Fedi or other post-installation tools so it was quite an interesting idea also. But maybe that's something that would need to be underlined with package kits because that's probably what the main tools that are expected to use. So with Fedora 22, there is no support to AppStream but this is the same issue because we need to install the AppStream data to get support to package data within the project but I'm not provided with the official AppStream metadata. Can you talk about this with the AppStream developers? I tried to get this idea spread to AppStream developers but I don't know where he is. Maybe he is here, I'm not sure. No, I'm not but the following member is here. I understand you just add some metadata to the repository and if no software center or whatever it's called, you should just get it in somehow. I don't know because I don't use this. That's probably the way to fix it is not to have the AppStream metadata into a separate package but into the repository directly. So the idea was to have the AppStream application to read the repository and to read the metadata repository. And eventually we could even spread some information where to look at other repository, other sort of party repository in this AppStream metadata. Because there is some great interest in AppStream to provide package data already in a vulnerable repository like in a girl form or Skype maybe or proprietary application. And that in this case are not in a repository but can be installed with a package that can be fetched from the internet. And maybe we can have a way to install, to spread where to look at for this single package in the related section of the repository. Maybe you can say there is a package that can be installed in this location and spread the metadata as an AppStream metadata to install this package manually. Even with bootstrapping GPJ key or something. So the other area of the project that is currently missing is of course this missing support for Rewide and Bronze. So I will talk about the reason why we are behind from the infrastructure point of view and the reason why that is missing. The Cannabody package are not Rewide or further 22. And of course there is also missing features like secure boot support that is really missing. Maybe I think it is not the priority of the project. There is no data RPM support also. We can probably address this issue at a later time but that is where we are from the user perspective I think. Is that the reason why it depends on the project? Is there a reason? Is the data the reason why it depends on the project? For Federation Z2 the reason is that maybe I will talk about this later because the main idea is that we are switching to the new infrastructure and that we are in some kind of in-between state. So because of that I need to concentrate on other things to build a new infrastructure and there is also issue that need to be fixed. So that we can envision to have a script to automatically address this issue in the new infrastructure. So that is why there is an in-between state with this future. And will the new infrastructure also have a Rewide branch? It could have a Rewide branch. It could have Fedora 33 branch also. But it is just a matter of time and to concentrate because actually I finished work on Fedora 22 just few days ago or few weeks ago. Because the release request we were still moving until that time and there is still package that was failing to build for different reasons. And this take my time until we try to figure out how to do. But I think we can move to work on Fedora 23 in early September or later to do a mass review. There is no technical issue to release but as soon as we fix the new infrastructure the better we will be done. The things from how you say it seems you do this alone is the crime. Like all the rebuilding and stuff like that. That is you personally and no one else. Is there anything we can do to help? Because I think it is very much working and I could help you if you want. Maybe I can speak about this later because I am going to speak about those areas. Actually it is like when you have something that is bad to you and you are concentrating on the headache because you have this problem. My presentation is trying to try to have a step back and try to see the different features. That is why I am trying to speak about user perspective and other contributors perspective. I am trying not to focus on the main issue that is important but that is also something to consider. I would say you absolutely don't have to care about that. There is absolutely no fix in the world. If it was good they put it only the last thing to do. It is only good to have maybe but not that. The only thing for Fedora is because of merit. Fedora merit is something like one and a half terabyte for primary and another three terabytes for secondary. There are really many people who don't want to do that. Last time I checked that I think usually three and one terabytes together is something like one hundred and two terabytes. I would say two and a half terabytes together is something like one hundred and two terabytes together is something like one hundred and two terabytes. I think I completely agree with the diagram. We can say something else but I think I will go a little bit faster because there is a bug zone. It is quite an old instance. It is trying to build a better one with bugzilla 4.4. This is 4.0. We are trying to move to another instance that is trying to address another feature. I don't know if it is similar but it is trying to use that support from the bugzilla. It is quite interesting feature to enable. That is user mailing list. I am just going to switch about abrc because I have an issue previously with vlc. vlc was complaining that the video landing was complaining that they are not receiving the backtrace from their crash. They are complaining about the message that was displaying abrc but they cannot report this message because it is not packaged from Fedora. It was trying to use Fedora package like just remote and totem and that was totally unacceptable from the video landing perspective. They are really angry about this so I try to make them speak abrc directly. Abrc was kind enough to address this issue and to reward the message that was displayed to user about the crash and the inability to report the crash. We really need to have this reporting because that is needed for open source project that is redistributed from community repository. That is another area of upstream relationship that upstream monitoring should be a feature that could be implemented. It is not the case and it is not done for a reason that should be work on. There is no mega alias to set up the abrc to report the feedback. From contributor perspective, this is package and plague interface. We are still using cbs and that is the main issue of the infrastructure and we are trying to move to Koji and this gate. Where we are from this point of view is that I am running currently the air pollution infrastructure from my own Koji instance. I am trying to address a better issue before it came out to the project. Such build tags, layouts and this is how to build separately some kind of package to make build overrides and that kind of thing. We are not trying to figure out how to fetch some external repository package like to automatically rebuild the kernel module for example from each Fedora 22. There is a need to figure out how to build a Koji layout to do this because from my example, I was not able to submit an override from a package in an external repository. If you have to deal with Koji, maybe you know the layout and the question of the layout but that is where I am about this issue. The same as the git preview, this is where I located the preview git repository and some packages are already converted to using git. The whole package from RPL Fusion are already converted to git but the git layout, this git method are not already there. That is an area to set up and we try to improve a lot in this area. What is missing from the contributor point of view is the Koji git migration and there is a need to work on the R package and Fed package like tools. This work hasn't been done. I have discovered recently that some contributors start working on the subject but it was not submitted to the mailing list and we haven't received the feedback on this work. There are still patches that are coming from contributors from different people involved in Fedora to have patch merged to the Fed package that will ease the work on this kind of tools. We need to have this Fed package tool that is funded to a R package imported to RPL Fusion. The same package DB and body was worked on by some users and unfortunately they never sent back to us their experience to set up this test tool. I'm just going to go straight to infrastructure because the infrastructure issue is that as you said we need to find out a way to delegate right. Maybe you have in mind that I'm trying to coordinate the project but actually I've only received very recently, like a week ago, I've received the route right to the supervisor of the project. So I'm not all mighty on the infrastructure project and I cannot delegate right as easily as I would like to do. When areas of improvement are about infrastructure, I've worked a little bit with this scaleway which is a spin off of online which is ESP. I'm a hosting provider in France and they are providing us this funds rate to ARM builders so the project will be able to have this builder to build a new infrastructure. Other infrastructure are headed by the primary mirror. Mirror manager instance are created by Adrian Reaver and that's quite easily self-managed. But we can also use GitHub and I've tried to set up some of the modules that have been in preview. The package that have been modified in 2020 are forwarded to this GitHub AirPen Fusion group. But unfortunately that's not forwarded to the commit mailing list so there's not public back to the data not public. We could also try to fetch accounts from cloud instance to get builder to our primary architecture and we could also try to set up in-house a builder for secondary architecture. That's something I tried to set up for ARM some time ago but now it's available online. So what we are missing from infrastructure perspective is probably we need more mirror manager instance because on each release the server are crashing and they are using a lot of resources and it's done scale well. So we need to find a way to build other mirror manager instance that can be done in cloud instance. Also a good way to delegate and to help the tool is to set up a public Git Ansible Playbook so that it can be work on the main idea of contributing to the infrastructure to submit playbook change. So the main idea is to pick the federal infrastructure Ansible Playbook and to convert them to use AirPen Fusion. Because there's a lot of, yeah, and that's what is done actually. I've done that for some role of Ansible like the Koji department and the purpose is to convert this so that it can be re-usable by other projects from Fedora to other projects. So it's not that easy. There was also an infrastructure talk a few hours ago. Yeah. Were you there for the public? No. Yeah. No, no, no. I ask if we want to use this for AirPen Fusion if we can just hit the magic button and all the playbooks will deploy and we will have Koji, Koji, epsilon and everything and it should work like that. Yeah, but that's not the case because there are a lot of things that are coded to the federal infrastructure like every host are coded in the Ansible infrastructure to our playbook. So there's need to abstract a lot from this playbook from Fedora. Okay. I have a lot of patch. I've done this conversion for Koji, but the same need to be done for Bodhi and other tools. And this Git, for example, the script that's creating the Git module for each package needs to be converted for other tools. Okay, so is there any questions left? How can we get involved? Yes, that's the last one. Yes, that's it. And I have the current state of... I need to figure out the things. So the main idea is to start working on each of the public Git Ansible playbooks and try to do the work to convert a given role to abstract the things. So the other area is to try to work for a given application and to try to get into the application, to div into the application and to try to remove everything that is outcoded to Fedora. I think there's a lot of things that... This is outcoded in other applications. That's working very well for Mirror Manager, because Adrian is actually doing this work. He's actually working with Mirror Manager, Jim, and he's making patch. He's working continuously to not to outcode things in the Fedora way. But this need to be headed to other applications also. So the problem is I cannot do this conversion for every application to collect the work and I think we get more involved in trying to set up Ansible in the infrastructure now and try to fetch to pull role as soon as they appear because now I have the ability to create instance and to create... to deploy application more easily now that I have the right to do this change. I think that's quite the way to deal with... to get involved in the process is probably to try to do it from work that can be published somewhere and that can be pulled in the dedicated instance more than trying to delegate the right because the problem with delegate several access is that those has privates several. They are not going to club the name of the one who is paying for the several but they are probably reluctant to delegate the right to people that they don't know or they don't know well enough or that don't often communicate with the project. So my idea to fix this is really to try to talk with us provider and try to get community server to receive community sponsored host. That's became a common good. That's what I'm trying to achieve to fix this issue with dedication of the right to the server because that's what is probably trying to lock the project. Yes, I think it's the contributor page for... There is an infrastructure page but I don't know if it's up to date. I think it's loosely current but there is not much time for... It's probably easier to fade from different infrastructure but I think that's not... The main area is probably to publish some kind of uncivil skeleton that someone can start working on to figure out how the server are located. But maybe it's easier to start working with federal ones, the federal infrastructure payback. Another question. I'm going to stop here. Thank you for your attention. Thank you for being here and for trying to support me during this project.