 So, yet again, CFP for OpenFest in Sofia, Bulgaria, then we have Mathieu talking about Weyland progress on OpenBSD, Mohamed talking about sub-packages, Luigi about sub-packages Hi, my name is Teriana Shopovan, I know you guys love conferences, so I want to invite you to one. So, OpenFest is a local conference in Sofia, Bulgaria. It's dedicated to free and open source and also open culture. It's not BSD only, it's about open source like operating systems, projects, hardware also. So, it's going to be on the 4th and 5th of November 2023, this year obviously, at the John Atanasov forum at Sofia Tech Park, Sofia, Bulgaria. There's a website where you can find additional info and the conference is free beer, no registration required. So, we had the first edition back in 2003 and someone on the team cannot do proper math, so they think it's the 20th edition this year and I think it's the 21st and we didn't skip a year. So, we have a call for participation running, we are currently looking for partners, sponsors who will support the event. Also, we do have the call for papers running right now. The website says the deadline is the 17th of September, which happens to be tomorrow. But I will tell you a secret, we are going to extend that by a week at least, so you have like 8 more days to submit an interesting proposal for a talk. Also, well, even if you don't have any experience helping out, organizing a conference, we are always looking for help and Sofia is a nice place, so we have a call for volunteers open. And yeah, that's the QR code to the call for papers. We do have, we organize the talks in several tracks, which are technical, advanced technical, social. We also have an open art track this year, which is something we're experimenting with again, dedicated to open arts. And we also have a missed track that is for anything interesting that doesn't fit the other tracks, so if you have an idea that you think might fit, just throw it at us. And join us in Sofia in November and you can find more info on the website, we try to keep them dated. So I hope to see you there. I'm going to show you a bit of the work that I've done during the summer to get a way-long running on OpenBSD. It's there. I hope that the sound is okay. So a bit of my background, but I wanted to go fast there, just it's not the first time that I bring up a window system on some new machine or OS. Who in the room does not know anything about Wayland? Okay, good. So what? Wayland basically is now 10 years old, so it's not so new anymore, but it's clearly the successor of X11 for the windowing system on desktop machines running Linux and BSD also in the future because no one works on X11 anymore, so it's basically dead by now. There are some basic differences between X11 and Wayland. The main one is that the Wayland application do use EGL to directly talk to the hardware and there is no client-server protocol at the same level as an X11. There are still client-server protocols, but it's much lower level and there is no more separate window manager. It's the Wayland compositor, which is both the Wayland server and the window manager, and this has some implications in the way that you use it. So where to start to port Wayland to a new system? The first thing is to choose a compositor that we are going to start with. And for various reasons, I decided to go with WL routes and SWAY. Basically, Western, the reference implementation has too many Linux systems to start with. It's probably doable to port to Western to open BSD, but it's much more work. Mutter and K-wind, GNOME and KDE stuff are also way too large to start with, so WL routes look really like a good compromise. I've been saying for three or four years by now that on the output pass, we have all what we need in open BSD and most of the others are BSD too. Once you have DRM and MISA working, you have the EGL pipes ready. The input is a bit more difficult because Wayland assumes the Linux EV Dev and the input model for keyboard, mouse and so on, and we need to emulate that at some point. Three BSD apparently choose to implement EV Dev in the kernel and have a fully Linux compatible input pass. On open BSD, we are clearly not going this way, but we have some work that was done by Martin Pieuchot six years ago to have a port of LibInput that was almost working. I did a few days of work on LibInput during the hackathon in Tallinn in July to add more support and to fix some things that were not perfectly okay with this LibInput port, but by now at least we have something working. The other thing is to get WL routes and say what are the software dependencies to build WL routes and see what is missing and add ports for that. Basically, there were some libraries that are easy to port, LibDisplayInfo and graphics lift off, it's just software that just builds out of the box. On open BSD, the seat management demon is a bit more tough, but fortunately WL routes is a pass-through mode where basically all the seat D functions are just stubs and that works okay for now. So I did a bit more work on trying to get a seat D working with several virtual consoles and so on, but for now I'm not using that. As I said, I did some work on LibInput to add proper keyboard translation tables to add the handling of scrolling events for touchpads because all the work that I did was using a touchpad and not a regular mouse. Also, the library needs to be properly built by hiding all the internal symbols, otherwise it will conflict with WL routes because they use the same kind of internal list managing libraries and so on. So there is WL routes itself, the main helper library. This is the one that has the most of the dependencies. Once you have WL routes built, then Wayland and Sway, the actual compositor is just trivial to build and then we need a few applications. Back in July, I ported Havoc, a very simple terminal emulator, and WEV, the Wayland cousin of XEV to be able to debug the input events to be able to dump them. Then later in August, I did some more work with the help of other OpenBSD developers. Ingo, Schwarzsee added support for SHAR32T and the U-SHAR header to the OpenBSD LibC so that we can build more applications that are using this to represent unicode strings. We also need a port of the C11 Sway's library. This was easy. I just stole the FreeBSD code and added it as a port. And then I can build a foot, which is a better terminal emulator than Havoc. And there are other applications that also build when we have all this stuff. There are some trivial patches that enable Wayland support in GTK and Firefox. And at some point Firefox did work with Wayland. The recent Firefox versions are unfortunately broken with Wayland, but I don't know. Landry told me that apparently he was too strict commenting out some parts of the Firefox code that used Wayland and that it's just a matter of fixing that. So I will work with him in the next weeks to do that. And if we want to go further, LibInput still needs some work. For now, there is no mouse acceleration. My mouse is painfully slow. It just needs to add the code there. There is also in WL routes that there is the notion of input backends. And we could perhaps replace the LibInput-based backend by a pure WScones backend. But I haven't spent too much time looking at that. We need more Linux compatibility stuff. We need to try to build more GTK and KDE applications. And we need to have a way to package this properly into the system. One big issue is that Wayland has too many dependencies to be added to the base system like we did with Xenocara. So the installer will need to be able to install ports if we want to be able to boot into a graphical desktop directly. And also there is a problem of doing this on architecture that don't have the RI. I have not tried at all to see how it goes on ARM 64. For example, we have the RI there, but I don't know if it works. The demo we've just seen when I started my slides that I'm running right now. And if you want to help with this, because I'm not going to do that alone in OpenBSD, basically anyone who has some basic C language and debugging skills, access to the OpenBSD 3 and knows a bit how to build things there, maybe a bit of knowledge about the Mason build system which is used by most of the Wayland stuff. Look at the WS console driver. One thing that I would need to help is that there are more and more people writing nice stuff for Wayland in Rust. We have Rust support in OpenBSD, but I have not tested yet to build any of those nice utilities and I don't know much about Rust, so I need help there. Basically, if you want to help, just go to the Arch Linux Wayland page and pick up some nice tools and try to port them. And that's it. Hi, my name is Luca Pizzani. I'm a port committer in OpenBSD and I work on sub-packages. What they are, basically, is the ability to have from one port multiple packages that is flavors, like Python, you have a Python port and then you create Python 3.7, 3.8, 3.9 from the same information, from the same recipe, and sub-packages instead is one build. You create multiple packages directly. So you can basically split the output of a port into multiple packages. The main reason is to reduce the build time. So there are packages that can be applications like QT or PSP. You have one port with a lot of stuff and you want to split them in modules. At the moment, there are slave ports, the old name kind of derivation port. There are tricks to do that, but it's not very good. So every time you need to extract the same port, build only that part, configure to build only a section of it. The idea here is to build everything and package basically the QT or PSP in already module, so you don't need to make any adjustment. We are very fascinated. Math started implementation in 2018. Got stopped for five years. That was the previous review and now I restarted. Let me see if I can... Anyway, the risk is there will be packages everywhere. The prolification of packages. That is one of the risks and why. Sub-packages enable a Linux system. That is many distributions. You can have the minus devil, minus talk. You can basically split a package in multiple packages. It is something that usually we don't do. There are pro and cons. There are embedded systems. People say, oh, nice, because now we can not install documentation, man pages, header files. Basically, you strip down things to the minimum. But this is a huge breaking change. You're used to install a package and you have everything there. Just imagine a library. Then you have the adders. You have the static library. You have everything. Now it's not that anymore. Your as-able playbooks are going to be broken and think like that. Pretty sure there will be a lot of heated discussion in the community if we follow this direction. That's why at the moment, this specific thing is not in the scope because it's a very destructive change. That's why it's really not in the scope. It's really just to remember there were probably people looking at it and streaming is not in the scope. If I forget to say it, it's really not in the scope. Where we are at. There is a review. The work is basically done from the framework perspective. We have submitted. It's not yet committed. There is another review that I'm using basically as a subtree when there are examples. I'm not using real packages at the moment as an example because building stuff, it takes time. I just want to have some dummy parts to create stuff. It also contains this minus docs, minus example implementation, but that thread is not to be merged. The way to build packages is basically how we build all the packages for previously. But that needs to know of this. It's not transparent with this change. It's working, so we have an implementation that is running, but the patch is horrible. I'm polluting the quality of the code, so I need to clean up my patch before to be committed. Is a view on what it looks like? Well, pretty easy. This is an example. It's a package called port test with sub-packages. You define all the sub-packages that you want. In this case, common two. You can define internal dependencies between packages. In this case, just say, hey, you, common two, you can only... I mean, I'm common two. I need the main package as well. I cannot run send alone. And then there is the ability to associate additional sub-packages with options. If I enable an option in a port, I can generate basically additional sub-packages. And then when you just make a package, at the bottom you see that there are basically multiple packages built right before we're just supporting one. The most important change, and that is extremely small, is that in the package now I added an annotation that basically specifies this is a sub-package. So you can know if you install that, basically, what it is. The biggest problem was about specifying a sub-package as a dependency. In the port tree, usually there are basically two ways to specify the dependency, but let's say in this case, this is another port. I want to use the port test, common two, as a dependency. So that is, oh, I need this package to run. The problem is that here you specify the port. Okay, this is the origin of the port. Oh, that is, but now you don't want the port. You want only a piece of it, and this field annotation has been added to specify exactly this. And that's why we need to change Poitrier a lot. Roadmap is pretty straightforward. Once I'm comfortable with the review, we can run on Xbron so we can try to build everything without using any sub-packages. Basically, we only introduce the feature in the framework, but not using it to identify regressions. Then we change Poitrier with the updated version. Again, we check there is no regression, and only that we are going to have a controlled option and documentation to see how it goes. Basically, we are very conservative. We want to be conservative on the adoption because it's a lightning talk. If you have questions or feedback, feel free to reach me. And that's it. Seven minutes, that was a record. Are there? No. To go faster. A quick introduction. My name is Mohamed Nourildil. To make it short for you, just call me Noor. I'm a software engineer. I work for a small post-startup in Utrecht in the Netherlands. Together with Misha Peters, the guy behind BSDM, they are one of the partner sponsors. And Jeroen Jansse, the guy behind Lailio, one of the guys behind Lailio, and he's the one back there. Together we're running the BSDNL meetup. We're basically tinkering with all sorts of things like UNX, BSD, Illumis. And that's actually the reason why I came here today. You can follow us on Mestodon. And you can read more information about the meetup group here. And there's also information on how to chat with us over our own instance of Metamost. Again, managed and installed by Lailio Jeroen Jansse. And I do, when I have time and I'm not trying to injure myself, do some woodworking. I'm a woodworking worker wannabe, if you can call. I did deliver a project in production, a whole bed for my nephew. Okay, as I mentioned, one of the reasons I'm here is that we're tinkering with hardware in the BSDNL meetup and Misha and Jansse, Jeroen Jansse are very interested into everything networking. So they changed me with this mini router from CDStudio. I think you can see it here. It's, with all my due respect, of course, to China. It's another Chinese company that built our hardware. Basically, it's a mini router or router that is built around the Raspberryby Compute Module 4. Not a bad sign. Anyway, to cut the story short, it looks like that it should be easy to install because it's Raspberryby and it's the same, basically, as you see, as Raspberryby 4, but it's not. It's the same as you see, that's true, but it's not the same configuration. And for some reason, that you can read about more online, it's configured to boot from either the EMC that is on the board, if not the SD card slot. So actually, if you see here, or it should be a bit down somewhere, you see an SD card actually slot in that carrier board, but if you have a Raspberryby Compute Module 4 with EMC on board, it will not boot from there, even if you change the booting configuration which you can through the tool I'm going to show. So that's one fake thing that you need to overcome. USB. You see, in this case, at least two USB ports. It's not going to happen, you cannot boot from the USB port. I honestly don't know why. There are a lot of discussions about that. I tried all the suggested configurations. It's just in the work. Funny enough though, till the board itself boots and even the installed media from OpenBSD with you boots, you cannot see whatever put into the port. Once OpenBSD itself, in this case, the installation program starts, you can actually see in this case the USB stick and that's actually the only reason why I'm going to install OpenBSD on this board with this trick. Again, if someone from the OpenBSD community can later explain to me the intricacies of this, I would like to learn really. The tricks about making USB work, it has to do with the on-the-go mode. I don't know what exactly the details of that, but there's a different configuration that you can try and everybody says that should work, that should work. Never, not nothing worked. Something else interesting which might be a bug is if you use, there is an HDMI mini, I think, or micro HDMI port on the board and you see the booting sequence when it starts, but it comes, I think, after the U-boot and then nothing. And there is no, if you put, for example, a keyboard here or a mouse, there is no control whatsoever. It might be a bug because I read on one of the mailing lists that with some configuration should work, but it was for the Raspberry Pi SPC 4, but it didn't work here. We had it on or with OpenBSD 7.1, OpenBSD 7.2, given it was an old discussion and of course with OpenBSD 7.3 it didn't work. So again, if someone from the OpenBSD community can say if it's a bug or something, okay, now getting to work. So I shared with you one secret of how, whether you have EMC or not, that makes a lot of difference and the second key component to actually control this board is to get this tool from Raspberry Pi is the USB boot. With this you can do two things. I'm going to show you quickly. I'm not going to go through the whole sequence given the limited time, but yes. But that will solve a lot. So one thing is that you have to boot the board into what they call the boot mode, which is basically shortening two bins here. I'm using a jumper, but in one of the bitums we just used two wires and it worked. And when you do this and then you boot up the board, you see things blinking, but you can do two things with this tool. One is you have this command. If you run it as I'm going to do now. Yes, but I hope it doesn't screw things up. Is that visible enough? Okay. But when you do it like this, basically what it does, it uses something called Linux gadget file system, if I remember correctly. And what it does, it exposes the EMC to your host, in this case your laptop, as just a mass storage device. So you can simply flash as one of the steps I can share later, flash in the mini root or install media from OpenBSD73. That's one trick. You can just do this, or I don't have to do it. And if you go into, in this case, the recovery, you can basically build the EEV ROM media and you can flash it to the EEV ROM flash memory on the, not on the carrier board, but on the Raspberry Biocompute module board. So you can do two things with this tool. Actually, you need to do these steps. The EEV ROM media is not necessary unless you want to, as you can see here, change the boot configuration, which is equivalent to the BIOS or UEFI configuration and some config configuration. But you can follow the steps without changing anything and you will need the boot to go. And the second thing is that if you want to get the latest image from, the EEV ROM image from Raspberry itself. And that's about it. So basically, the steps are like this. You get these, all this nice software in the media. You flash the install, the full one on the USB stick. You flash the mini root on the EMC. And then, I need to switch this back. Then you un-set it, so it boots normally. And then you need this nice little thing, which is basically a USB, is it UART or UART? UART, okay, adapter. We had to do some modification because the board itself doesn't come with the pins, so there was a bit of soldering sessions at the bitup, so it was fun. And it's a little bit hazy, so sometimes it... What happens, it's a little bit complicated, at least to me, maybe for some of you experience that it's not... There is some of booting code on the SoC itself, like in the firmware, just to initialize some hardware. Then it boots from the EMC, in this case, on the board itself. If you don't have that, then from the SD card. Then basically, in this case, that's the mini-routine install media from OpenBSD 7.3. You follow it as it is. That's one part of the trick. In one of the steps, you will have to reformat the EMC as your standard file system that you will boot from at the end of the steps, but then you will lose, if you have it already, the file sets. So the trick is that you do the file sets on a different media. In this case, just to reuse it, I have the install 7.3 image. So basically, I can install from it, and it has the file sets. In one of the steps, it asks you, you have another disk from which you have the file sets. You say yes, you install it from here, and at the end you have a mini-router with OpenBSD 7.3. That's it.