 Hello everyone. So welcome to this year's new experience for the Yocto project and open embedded both at ELC. So I mean as everybody knows, this is the first time for everyone where this is going to be a virtual event. So I'm Nicolas Duchenne, the Yocto project committee manager and with me we have Philippe Ballester. Philippe? Hello. So the both is always a very interesting exercise. So we are here as speakers, but really what we want to do is we want people to ask questions and we want someone from the audience to actually answer the question. So I mean our job is to find questions and to find who can answer the questions. So we have started and we have prepared a few slides to just get started and get us warmed up. So we'll go quickly through these slides and hopefully we'll have questions. So maybe there are a few things we have to say about the logistics. So there is the live chat. I think, I mean you can ask questions and you can raise your hands if you want to talk or say something and we have Jennifer from LF today that will help us and get you, put you on stage once you raise your hand. So we'll do our best to use this tool. I'm told this is, we are the very first people that you use it today. So if you raise your hand, we'll give you the mic at some point. Okay, so yeah and if you have anything, I mean just asking the live chat, we are, Philippe and I will try to keep an eye on the live chat as well. So some project updates quickly. We like to do that since the last time we had the booth, which was at ELCE. We've made a number of release for the doctor project. So I mean you have all the numbers and all the various release. So we've been quite busy. The engineering team has been busy with people around the world. The one thing to actually really highlight and I think, and I hope we are going to talk about that today is a 3.1, which is the very first project LTS release finally, which has been done in April. And yeah, so that's, I mean, one of the reasons why we ended up doing the LTS is because we've talked about the lack of LTS at many booths before. So hopefully we can talk about what is being changed now that we have the LTS. So that's just to give you an idea about how we are busy and who are the developers and how many developers are actually contributing to the release. Some also, I mean, various updates about the project. So since the last time we talked with, we had some membership updates. You probably have all seen the news. Microsoft has joined the project as Platinum. And we have two existing members who have updated to Platinum, Cisco and Xilinx. And also, a few months ago, HGL, the Automotive Grade Index has joined the project. And again, this is very important for us. The membership is actually what found the project. And they are also here to, they're involved in the day-to-day direction of the project. And that's very important for us. And we welcome all our members. It goes without saying the project is almost 10 years old. And that's quite a milestone. So we'll talk about that in a long year. Sadly, we are not all together for this anniversary. But that's a serious milestone for the project. And we are happy about all the work done over the years. And hopefully, what's coming for the next 10 years. I think we talked about that a few times. But we have some, we have Joseph, who is a very active community member from the Yachter Project and Open Embedded. And he's doing very often, I mean once a month, once every few weeks, some live coding sessions on Twitch, which is like a video streaming platform. If you don't know what it is, I encourage you to go and ping and find Joseph. He's here at ELC, he's probably here today. And he's basically just hanging out with his computer and doing something with our Open Embedded Yachter, showing you how to do it and how to use it. It's fun. And it's actually being watched more and more. So I encourage you to have a look into these things. Last time we talked, I think I mentioned that we were moving the infrastructure side of all the list, mailing list for the Yachter Project and the Open Embedded to Gov.io. I'm happy to report that it's done. And we don't have much to say because it just works and that's good. So now all the lists are hosted in Gov.io. Finally, some questions we have very often. People, I mean, want to start and they start with like a simple bug, fix a simple thing and get something merged and upstream for the Yachter Project, for Open Embedded, any of our projects, we have a specific wiki page with some entry points for people who really want to start and contributing on small bugs. Okay. A couple of more highlights. So the LTS, I'm not, I'm going to skip this one. There was a talk earlier today and I mean, it's been discussed and I mean, hopefully many people know what they are and I'm sure there will be questions. But yeah, the Yachter Project has its first LTS, which is great. Hashe Quivellense and RobProducibility, I've been enabled by default now. So they have been available for quite some time, but they weren't enabled. So if you notice any change, if you find an issue with these things, feel free to reach out to our community and we will work with you. But yeah, so it doesn't come as a surprise. It's actually something which is enabled by default. One more update, something with that new mini project that we've started, or it's actually not mini at all. We are in the process of doing a migration for the Yachter Project documentation from what it is today, which is based on Docbook and we've chosen to move to Sphinx. It's been a decision that has been approved by the Yachter Project TSC. The migration is just starting now. So if you are interested and if you use the Yachter Project documentation, like probably everyone out there, and if you like this documentation and want to contribute to the next version of the documentation, feel free to join. There is a dedicated mailing list, a doc mailing list, on the list of the Yachter Project.org and there are many reasons why we do that. If there are any questions, we can probably deep dive into that. But in terms of maintenance and what we want to do with the documentation, we felt it was actually the right thing to do the migration. Deep, you want to take this one? Yeah. So I'm Philip Ballester. I'm also on the open embedded board, which is basically the build system that got the whole Yachter Project started. And we hosted a workshop in February in Brussels the day after Fosdom and we had sponsorship from the Yachter Project. So thank you, Nico. We have recordings that should go live real soon now and you can get a link to those from the URL on screen there, which also should be findable from the open embedded website. And we had probably 20, 25 people there and it was very well received and we would like to do something similar again, because it's very nice to have one day of just concentrated talks. So please talk to me about running this virtually unless the world improves dramatically in the next few months. We should think about doing one of these virtually to see how it goes. And I'm very interested in getting people to talk about what they're doing who are not normally presenting at things. It's a smaller environment, a little bit easier to get your feet wet. So we would like to get more people talking about their work. Can we have the next slide, Nico? This is the list of talks at this conference and you've already missed the LTS talk that Nico did earlier. This is the BOF and one that I would like to just call your attention to is on Wednesday, Joshua Watt is going to talk about re-producible builds and hash equivalents, which we touched on on an earlier slide as something, some recent work in the project. Okay, next slide. So this is the interactive part of the BOF and for the audience, one thing I always like to hear is what are we doing well and what can we do better, especially things that we haven't thought about. So this is sort of throw it out to the audience and see if anyone has any questions. If you have questions, please type them into chat. So if you've been to the BOF before, I mean, you know how we like these things, we like any kind of questions and they are in the room. I mean, I can recognize many developers from different places of the project. So we can hopefully answer lots of questions and any questions you have. If you've not done the BOF before, I mean, know that. I mean, we will make sure that we find the right person to answer your question. Okay, so we've got a couple of questions. I'm brand new to Yacht2 and I want to start compiling OSes for ARM. Where should I start? Do we have anyone from ARM here who can answer that? Okay, we can at least give the genetic answer. So there are in the Yachter project documentation, we have the quick starter guide, which will guide you through actually running your first build. And you might choose to just build for ARM. That's fine. And you will end up with something that can work in like a QMU, a virtual platform that could be ARM or anything like this. So I mean, since you asked for ARM, especially, there is an ARM community around Open Embedded and the Yachter project. There is a dedicated mailing list. It's called Beta ARM at least.yachter.org. So feel free to join that list. And then if you have any questions or any specific ARM questions, you can ask them. Okay, and I'm still learning how this works. We have a special questions tab as well, Nico. And I think Richard is going to have to answer this one. I have immensely enjoyed using BitBake, the build tool behind Yacht2. I often like to use BitBake without Pocky. Is there a simpler way to use BitBake without OE Pocky INI? I'm guessing that's meant to say it'll be the Open Embedded build in a script. All that script does is just set some environmental variables. So if you don't want to use that, figure out what variables you need to set. It's usually, I think, BP path and go from there. But you don't have to use that script. Yes, okay. So if you look in the top level of Open Embedded Dash Core, and this is what I do all the time, there's catch me afterwards, and I can tell you what the exact name of the script is and how it works. Yeah, good catch, Richard. I was thinking that he was running BitBake alone without any metadata, because I overcomplicate everything. That's possible too. But I knew that's why I immediately thought of you, because that's the way it was designed to work. Okay, yeah. Putting questions in the question section is going to work easier, I think, because I can't see it and the chat. So when do we expect Yachto will support a read-only root FS with SystemD? Do we have any SystemD gurus in the room who might be able to have an answer? Raise your hand. Okay, let's skip that one and hope someone answers it. Nika, we might need to take these and take them to chat afterwards as well. So hopefully we can keep a list of the questions that we don't get good answers for. So we also have a question is CGL meta CGL still being maintained? Does anyone know an answer to that? Well, there's a couple of SystemD ones, so I can quickly touch on those. For the SystemD read-only root FS, I think it's a question of somebody figuring out and sending patches. I think it works in some configurations, but it's not perfect. So it is just a question of sending patches. There's also a question asking, is this five in it going to be dropped in favor of SystemD? And there's probably a similar question where people are saying, are we going to make SystemD the default? To cover those ones, I know we've talked about this in the past buffs. We were going to switch over to SystemD as a default, but because of all of the changes it was just going to make to the testing matrix, it's actually made sense to keep System5 in it as the default, have SystemD as the Pocky alt distro, the alt enter testing configuration. And therefore we test both equally now. And we have no plans to drop this five in it at this point. Both have uses and no plans to drop it. So we've got a raised hand. That's Jeremy. Jeremy wants to use the maintenance format CGN. Want to say something? Hey Jeremy. Can you hear me? Basically, I'm the current maintainer. A couple of the other maintainers have been vectored off to other projects. So they're not active as much, but we are accepting patches. They're having neural patches that went in for done file. If you have things that need to be fixed for updates, by all means send them in, and we will process them. All right. Thanks Jeremy. Okay, thank you. So again, a question about Ninja. So we actually lost H.R. So H.R. if you want to come back you'll have to raise your hand again. Are there any plans to move to Mason? Ninja is part of the default build mechanism. H.R. you want to take this one? Our horse maybe. Hi, can you hear me? Yeah. Packages have been moved over to Ninja or Mason as they upstream move. Changing OECO or OCTO by default doesn't make any sense, but we are actively switching as upstream packages do for all the good reasons that everyone loves Mason. Okay, thank you. Can you take the next question, Nico? Do you have pointers on how to easily create bootloaders for custom boards that use ARM or WISC-5? So do we have any maintainer of base port layers? We'd like to raise their hands. Cam, can we? Yeah, thank you. Yeah, so can you repeat the question once again? Yeah, I think it back to the questions. Do you have any pointers to easily, I think the word easily is important, bootloaders for custom board that use ARM or WISC-5? So yeah, I think the bootloaders are basically primarily part of the SOC development rather open embedded provides the environment for you to work with it, right? So, but we don't like have branches or any of that sort that you would want to do. However, we do have like at least for WISC-5 there is open SBI, right, which is actually available in meta-WISC-5. I think it is in the core now. Yeah, it is in the core metadata. So it is kept up to date to the latest releases. So, but I think you have to participate in open SBI ecosystem to do the development. And you could use a, you know, Yachter project to build and test and basically it can be your build system. But I think from community aspect, I think the upstream, respective upstream communities are where you want to participate. Okay. One question about PowerPC, someone is asking what happened to PowerPC support and if it's gone. Richard, maybe you want to come back, assuming you can. Can you go back? I don't know. Yeah. So the PowerPC question, right? So we still have PowerPC in the core. So still like PowerPC 64, for example, the support was added. And however, I think there is no, what do you call like, you know, default device or any supporting stock behind it that is being regularly tested. So it's also like matter of someone supporting it and backing it and making sure that, you know, it runs through all the tests and the auto builder requirements for it to be maintained there. But it will find, I think as of now, I think from testing point of view is where you'd have this drop. But if somebody is using it, supporting it, it is still there and patches are still accepted if someone sends patches respective to PowerPC. Okay. Thank you, Cam. So we have a question, interesting question about license manifest. So I think we'll need you, Richard. There is a, it's our process to collect all license information about the shipped open source packages. The generate license manifest is a good starting point. But the process of collecting the copyright holders for all packages is still manual. Yeah, it's a layer. There's some tools in there that allow you to. We are losing you, Richard. You can't hear me. Can now. I'll try again then. Yeah. There's a layer MetaSPDX scanner, which has some good tools in for handling a variety of different license situations. So that includes not just licenses, but also copyright information. So it takes some open source tools, some of them in phosology, some of them in other repositories, pulls them together and then allows them to find things like copyright information. So ultimately, I'd love to see more integration with some of these things into the core of the project. But for now, I would go and look at MetaSPDX scanner and some of those tools because there's definitely tools out there that can collect that information. And I'm just not entirely sure which ones MetaSPDX scanner is enabling right now. I think it does have copyright scanning in there. But if it doesn't, it should be easy to add using the sort of the process that's already there for licensing. Okay. Thank you, Richard. Do you have a question, Philippe, or should I continue? Go ahead if you see one. I'll take the next one. Okay. So we have an ESDK question. So prepare to raise your hand if you know the answer. I don't understand the workflow of bringing artifacts produced by teams using ESDK into my final image. Where is the best place to get more information from that? Would like someone to raise a hand now? I was hoping Paul would be here for that one. I'm not back, I never left. I figured I'd get removed as soon as somebody else raises their hand, I think. Do you want to answer this question or? I could certainly have a try. I mean, bringing back in artifacts is usually a question of writing the recipe to then go and build code or the standard model of contributing into a shared ESDK cache and working that way. It is the same sort of step as you would normally use, bringing things back into a normal build, which can then inject them back into an ESDK. It's sort of designed to be circular. I am a little bit disappointed we haven't been able to develop the ESDK further than we have. I think there's some good ideas in there. Equally there's some things that both Paul and I would do differently given the experiences that we've had and there's ways we'd like to improve it. If people are looking at that, I think it's something that probably needs a little bit more work on its developer workflows. I think the ideas are good, but unfortunately the people originally working on that have been moved on to other things and there isn't really development going on. It would be great if a new generation of people wanted to step forward and figure out where to take that. That would be awesome. Okay, can you go? I lost the window. I can. Please find it again. Is there a recommended tutorial in regards to creating a Jenkins configuration file and setting up a pipeline? That's a good question, so we can see if anyone, all of you already know, there is not one way to actually build with OpenMbD or build with Yocto. Everybody has more or less their own ways. That's why you have difficult questions. What I wanted to say before we can ask the audience is that there is a talk on the Yocto project dev day on Thursday on how to actually do CI CD with the Yocto project and GitLab. I mean, it's not Jenkins, but I mean, it's a hot topic. It's something that many people do on their own way and we actually wanted to show one of our committee members on how to do that with GitLab. Can someone, anything to say about Jenkins and OpenMbD? I've done it, but in very brute force manner. Yeah, so I gave a talk, I think, on living on master building with Jenkins and keeping everything together. So it's really very doable. Jenkins itself is a bit complicated, but in terms of pipelines, I would recommend looking at the groovy scripting language and doing your builds that way. We were building at that time using a Pocky container from Crofts. So all our builds were done in Pocky, sorry, in the container, in Docker containers. There were some gotchas in that regard in terms of number of file nodes and things like that that can get in the way. These days, I would probably look at Pyrex, which basically wraps all your BitBit calls with a container call. If you have any other specific questions, ping me or come to the booth and I can try to share more. And someone posted a comment that they experimented with Jenkins and GitLab CI and found GitLab CI slightly simpler to use. And we've got a couple of hands up or a hand up. David, you're on. Yes, I just, as I added a chat to the question about ESTKs, there is a tool in there to export your custom content to a layer. Once it's in a layer, then it can go anywhere you want it to to and lock your project. So that's a general solution. And I also added Paul Yelten, the author, he'll be at Dev Day. So if you want to see him, he's also been haunting the booth. So check him out there at RSLAC, but he'll be at Dev Day to ask specific questions. So we talk about Dev tool in general. Thank you. We have a hand. Make a lot. Okay. You can hear me now. They're just cut out for a second there. Yeah. I just wanted to say regarding the Jenkins, I work for Wind River and I've been experimenting because last three years with Jenkins and Docker Swarm, and I put some stuff up on our open source labs page for creating, for doing builds, doing Wind River Linux builds, but it should be fairly, the only, should be a lot of that stuff is relevant for building Yachto. I'm going to be talking about some of that stuff in the Dev Days as well. So if you have any questions, I'm happy to talk about it. I'm trying to move away from Jenkins personally. I'm looking at Kubernetes and Tecton and other things. But if you're interested in those sort of details, I'm happy to talk. I have to talk about them. Okay. Okay. Thank you. I've got a question here. Are there any interesting tools using the Tinfoil API to Bitfake internally or public? Did we lose Richard again? Lots of tools. Team say Dev tool. Richard is back. Infoil. Those are good places to start. People are starting to use it in other places. I can't think of any other big other tools, but those are good places to start. Okay. So there's some usage apparently. I had another one. I don't know what this question means. I'm just kind of curious if anyone out here can help. Is there a group of people who want to focus on support for FTPM or physical support? This may also benefit from a read-only root file system. Anyone have any ideas? Do we need any clarification for the question? All right. I was kind of a phishing expedition, I guess. I mean, you guys definitely can ask us questions. We don't know the answer to, but that doesn't mean that there's not people working on it, because we see an incredible diversity of use cases for this, some of which we've never thought of in our entire lives. So this is an easier one, I hope. Are there any plans for Yachto to support fetching build artifacts from sources like Artifactory or Conan? This is interesting. I'm still here. I've heard people asking about that before. It should be possible by doing that as a fetcher module, but I've not seen anybody submit patches for it yet. And I don't have access to such things myself, so I'm probably unlikely to do it. But the ability is definitely there in the code base to add in the modules for it. So Conan is for building binaries. I saw a talk on this at FOSDA. It sounds like they want to fetch binaries built in another system and then build packages. I mean, definitely, if we don't have good answers for your questions, we'll be around the chat for the rest of the week. I can see a question. You will say something to them. I would just like to add that there was an example implementation of a Conan fetcher a couple of weeks or months back on the mailing list, and Paul Barker, who unfortunately isn't with us today, had severe questions or concerns about the licensing problems with it, because you basically pull binary artifacts without any proper licensing information from somewhere in the cloud and pull them into your build. So unless the Conan folks actually get their stuff sorted out first, we cannot properly do this. Yeah, so on artifact tree, I think the setups are very proprietary or at least that's what I've seen. So there are fetches that are around, but we are specific to implementations because how you set up the artifact tree and it has like exchange of credentials and things like that. You can say that it can be done in a more like generic fashion and then the authentication part could be separated out. But we haven't done that. But yeah, so far I haven't felt that it will be a generic solution that would be appropriate in the core or elsewhere. So that's what I wanted to mention for artifact tree. And we've got one more hand. The hand went down. I think it was me. And you disappeared again. While we're waiting, let's do this question. I'm just starting to learn about Yocto. Does it support LUKS encryption for mounted file systems? I know I've seen some talks about encryption for file systems and I want to say there's one in the open embedded workshop, but I'm not sure if it's that specific encryption. Yeah, you know, so LUKS was one of the things that was supported by Intel IoT Refit. I mean, I realized it's a couple years old now, but if you go look for that, I can post the link into the chat. That was supported there. And also there's some references on like NXPs community board about doing LUKS encryption and so on. So it's definitely supported. It's just a matter of setting up your configuration properly and then the devil's always in the details in terms of what specifically your build system, what you're ending up building, what your image is, you know, but LUKS is definitely supported. Definitely work. Okay, nice. So a question about the HCP. No, I don't see the question anymore. But someone was asking about the deprecation of the IAC, the HCP, which I think I've been, I've seen discussed on the mailing list or IAC, like this week or last week. Os, Richard, do you want to explain what's going to happen with the HCP? Come on, guys. Feel free to jump in if we, I'm flipping through all the questions. Anybody else wants to take Os? I think you were discussing the HCP. Do you want to answer this question? Okay, so there is the answer. That's what I thought. But yeah, it's going to, the answer is yes. It's going to be replaced with KIA and it's going to happen on master soon. So the next question I see that we haven't touched on, is anyone having success with SE Linux labels on R0 root file system? Is significant work, is significant work policy work required to enable SE Linux? And these are the questions where we need help from the audience. Okay, so we have a hand up. And once again, please feel free to ask in chat afterwards, in case people are having trouble with the platform. So I see Bruce and Mark answering the question. Do you guys want to take the mic for a minute? Mark, you hear that? Yeah, I'll just talk briefly. I was a maintainer for Met SE Linux. I may still be in the maintainer file, but I've had no time in a while. But generally speaking, the expectation is that the SE Linux infrastructure, the support for the labeling, all of that supposed to continue to work. It's really down to the policy. There is no standard policy. So that is something that you'll have to develop yourself. And it is not easy to do. So keep that in mind. Okay, thank you, Mark. Okay, so just looking at the time, 37, 38 minutes. So we have some more time. So hopefully more questions will come. Yeah, what's happening, Nico, is the guys in chat are sort of answering the questions without opening their microphones. And if we're looking at the question list, we can't see them chatting. Are you saying that they don't need us? They're bypassing the system and making it a little bit tricky for us, because we think nothing's happening and something is. So who has their hand up? Joseph. Hey, Joseph. Hi, Nico. I would like to repeat a question from the YPDD in Lyon, actually. The question was, is there anybody here actually doing this for fun or as a hobbyist? Or are we all like doing this as professionals just to earn a living? Because that's kind of like, it's interesting whom we are actually working with. That's a pretty good question. I see. Hands raised. Yeah, so this bill is very much a hobby for me. And I'm very, I mean, I do a lot of stuff on my own time. It has absolutely nothing to do with my employer, but it's also my day job. So it's a lot of both. And I think many of us actually fall into that camp. Most of us probably had more time when we were earlier in our careers and experimented more, did more hobbyist type things. And just as life goes on, you tend to get busier and busier and less of that time. But yeah, so I was working on 3D printer stuff and other things in the maker space. And I still have a lot of interest in like home automation and things like that, like home assistant. But it's just a matter of time. Well, yeah, so I wanted to say I use it in both realms. So I have my home automation that is that I experiment quite a lot and stuff that where I use my Raspberry Pi as a gateway for my sprinklers. And for my washing machine and stuff, like you think in the stuff that I use for that. And professionally also I use the project in a separate realm of things. And also I have interest in other architectures that doesn't matter professionally to my employer, for example. And I use the project for doing that. Okay, I can see an interesting question here. Is there any support for building an asymmetric multiprocessing SOC? And if so, is that supported with RunQMU? So I want to take this one. And I guess we probably need to define asymmetric here, but I'm going to assume it's like SOC with various cores from different even different architecture maybe. Anybody wants to talk about that? Maybe multi-config? Yeah, so you can do heterogeneous computing with multi-config where you can compile different parts of the system for different architectures even. So that would be like your main cores or ARM and your secondary cores or AVRs or whatever you want. It doesn't need a little bit of work to get those tool chains set up, but that is definitely supported. That was a great talk from Microsoft. I think it was ELC last year, maybe ELC last year. And they explain how they actually build and use multi-config to build the asymmetric systems for the aziosphere. So you might want to watch what they've done. They did share like a lot of good tips and tricks about what they learned in the process. So I think part of the question was on QEMU and QEMU itself, I don't think like you can have same emulation in the same process. So I mean different CPUs in the emulation in the same process. It would be easy if that was the case, but I guess in a Yacht like really looking through how to set up multiple QEMU instances perhaps to run it. But as far as building it concerned, I think Yacht project is for that. QEMU mainline can't do that. Okay, I think we got most of that. Okay. So is there any questions that we have missed? Thank you for liking my cat. What the sword order is on these cats? Who gives the question thumbs up by the way? Anybody can have both questions and actually change the order and assaulting. Yeah, we're learning a lot today. Okay, the attendees. Thanks Jennifer. Okay, so we have more questions. We have a question maybe for you. Jennifer is the audio going to be available after each other. I asked this question. And so I think Jennifer, we have two questions for you. Is the chat and the questions going to be recorded somewhere? And is this live a video going to be available? Okay, it will be a video will be on YouTube. Okay, do you know if we'll have the chat available? I think given the circumstances, it was not too bad. We had more questions than we usually have the both. So in the platform, it's been almost working fine, except we zeroed each other. So about that. Any more questions? Okay, and if we have any follow up questions, we have the channel on Slack. And most of us should be around this week to help answer questions and try and clarify anything we didn't do. Oh, here we have a good question in chat. What can companies do to help the project? So that's a very interesting question. So there are many different answers. And the first and obvious one is actually to go and join the project, the Octo project that will actually provide resources and help set the directions for the Octo project and open embedded technologies. I mean, that one is obvious. But I mean, obviously, having your engineers contribute to the project, and you don't have to be a member to actually contribute and send patches. So definitely contribute your use case. I mean, sending patches is one thing. But also what we figure out, and especially in this barf, we are meeting users of the project that we don't talk to in general. And sometimes you guys do things that we didn't think about. So we don't know all the use cases. So sharing your use case with us, joining the mailing list and sending patches, I mean, obviously, is something. Reporting bugs, testing master, I mean, now that we have the LTS, I mean, contributing to the LTS is also something things that the company can do. Very often we see that and we hear that when we actually go into events. People just go and they get cloned, this thing, and they go and they use it, and they don't necessarily contribute. Even if they fix issues sometimes, I mean, they just fix issues on their own and don't send back. So just contributing back the fixes and the improvements you do on your side, it would be a tremendous help. Test cases, yes, testing. That's a good thing. We are relying more and more on automation for testing. I mean, I think we gave some numbers, but we run close to two millions of tests when we do a full test. And it's all automated. So it's many tests. I mean, self-test for the system, but also P-test for the recipes. So and more testing that we have means that we can catch issues more often and quicker. So that's always good. So testing things in such a way that we don't test them ourselves would be nice. Yeah, I wanted to say test tool is available for anyone to run tests on their environment and report back results. So I think that would be a great help if people have their devices perhaps that they can offer as they test or they can run tests on and report back perhaps. That would be helpful. And participation generally, not only in code, but also otherwise if you have resources for, you know, there are various other aspects of projects, starting from marketing and documentation, non-technical aspects of projects as well, documentation perhaps, you know, the health there as well. So obviously letting your engineers work upstream is one big day to contribute and also influence the product. Right. And I mean, there are many good suggestions from Richa, so I hope you get them. But helping us, Randy. A lot of what people can do is sign up to work on some bugs that are listed on the bug as well. And if you're also interested, you can participate in the bug tree on it, which happens every Thursday. Okay, you're a bit bad. Yeah, so the bugzilla, I should mention that bugzilla is the bug system we use. So most of the change we do, we try to use bugzilla. So if you can also have your engineers report issues and help us on bugzilla, would be something. On the day to day, if you talk to Richard on the day to day, I mean, there are issues every day that just come and pop. So there are two meetings every week where the team, the committee comes together. I mean, there is the technical meeting where they talk about the stages of the project and what's going on and what's going to be worked on. And there is a triage, bug triage meeting where I mean, people can join and help basically looking at bugzilla and finding what are the real issues and doing some bug triage. So again, I mean, you don't have to send patches. You don't have to be a member to do all these things. I mean, you can help the project in many different ways. Let me have a look. Right. There is a new testing manual which has actually been written like a week ago, finalized a week ago. So if you want to help, if you want to run the same test that the project is actually running, it's actually now a very well-documented process. We got a couple more questions. I can find them. I see a few things about Microsoft. They actually have made a few talks and they explain what they, what they do with the Octo project and why they use it. So that can give you some hints about why they've joined, I think. I linked one of them as one of the answers. Someone put a little notification. There was more questions. Someone is asking if we can replace Bugzilla with something better. So I don't know if Richard even wants to say something about this one. What's better these days? That's sort of a general question. Don't mention closed source software. There may have been some questions, but I can't find them. So as Richard said, there is a migration of Bugzilla to a new version, which is planned for the short term. Any questions on the question tabs? So Paul Barker has a GitLab instance running. If people want to play with that, someone mentioned GitLab. Yeah, that's correct. Actually, this is, we have gitlab.com slash open embedded. If you don't find it, ask me offline and I can point you. That's a place. I mean, some people have asked for like hosting open embedded layers on GitLab. So we set up the main namespace for open embedded there. So anybody is actually free to come to us and ask and we would just make a new project. And if they want to experiment with using GitLab for the layers, that's possible to do that on the open embedded GitLab. Yeah, and I, when I set up the MetaPython 2 layer, I had to do it with automation and IE's GitLab CI for that. So I posted that link in earlier, but if anybody has any questions about the approach that I took to that, I mean, I mostly copied some stuff actually from, I'm forgetting his name now, but a guy over in there who's seen this. But, yeah, it's, yeah, it definitely is fully functional. It's basically with things like a cross Docker container and maybe I'll use it for amount at work, but moving the entire project to that, it's just, there's a lot of things being made in terms of switching from a tool to another tool. Okay, Tim, thank you all for coming. Any final words, Nico? Yeah, I mean, thanks everyone. Thanks for using this platform and having us today. Thank you. And again, we are going to be on Slack for the rest of the week and we are on the mailing list on ISC, I mean, for the rest of the year. We also have a Yocto Slack channel as well as the embedded one, but most of us watch both of them. Yeah, that's not the Yocto Slack. We are actually using the conference main Slack server and we have a channel there. We usually don't use Slack. I mean, it's actually a good question with that we should have one discussed. No, no close source. Awesome thing, similar. That's it. Okay, so thanks everyone. Where have you been? I mean, have a good rest of the day, a good morning, good afternoon, good night, and enjoy the rest of the conference. Thank you. Bye-bye.