 Hello everyone, thank you for joining us for the presentation. My name is Dan, actually have Nia besides me. Yeah, I'm a special guest for this presentation and I can hopefully help with questions and stuff. Yes, we are both NetBSD developers. Nia has been helping me with GNOME stuff and with the slides. And yeah, today I'm going to talk about porting GNOME to NetBSD, obviously. How did I start this port? How it continued with our common effort? And what is the lessons I learned while trying to port GNOME? A few words about me. My name is Dan. I'm currently located in Berlin. My background is a machine and web development. I've been writing APIs and backend servers. But I always had a passion for operating system and desktop software. My favorite operating system is of course an NetBSD and actually my favorite desktop environment is GNOME. That is the reason why the GNOME port appeared and why I'm here to speak today. Also, as I said, we have Nia next to me who helped me mentor and guide during my learning period of a package source NetBSD and porting GNOME. Yeah, I will talk today about how we started the GNOME port, what is actually part of our port a bit about GNOME architecture and how it fits into package source. One of the most important things is the pain points, like what was the trouble we encountered along the way. And a few words about how we can upstream our changes, what we can improve in the GNOME and Excel projects in NetBSD. How did all of this start? I actually was following NetBSD for a long time, but through coincidence, I left my full-time job before the pandemic. Well, the pandemic was not planned and it was a bit hard to find a job, but it was easy to find a lot of free time to work on side projects. And while I was interested in NetBSD initially, I encountered Mayans, who goes by Koipu, bounty on the mailing lists. She posted a bounty to port GDM, the GNOME display manager. And I found it really interesting, so I wanted to try. But I started all of this with very little C programming knowledge and very little OS development knowledge, so it has been quite a struggle for me personally. Yeah, I've helped quite a bit with the C programming stuff and since I do systems programming full-time, and it's been great working with them and reviewing his patches and stuff. So yeah, about the porting. As I mentioned, I didn't really have an idea where I'm starting, but thankfully there has been an OpenBSD port, I think then by Antoni. I'm sorry if I don't remember the name correctly. We didn't really talk, but basically my start was by copying OpenBSD's patches and importing them to package source. Of course, there have been some differences, but I don't think I could ever have managed to do it if I didn't have the initial gem start from OpenBSD guys. So thanks to them. And yeah, about the port, I started with the goal to port GNOME desktop manager, but found out that it actually implies upgrading and packaging a lot of stuff. So the priority is soon changed to porting, yeah, most of the GNOME desktop ecosystem includes GNOME shell, MATE, GNOME session, GNOME-based libraries. We had to spend a lot of time like removing all of the old GNOME 2 stuff from package source and importing the newer libraries and stuff. And we just removed GNOME 2 before starting on GNOME 3 because we already had MATE, and that just made the whole thing much easier basically starting from scratch on GNOME 3. Yeah, so well, I focused mainly on the GNOME desktop. The apps were a lower priority, at least for me. So things like Nautilus or other GNOME apps, some video player or music player, I didn't have any time to focus on those. So I don't have any idea what's going on in the app ecosystem. I think it's going on pretty well, and we have most of the important core applications, at least included in the MATE package. But as soon as we get better with the base platform, I wish to get more involved with the other apps as well. So yeah, about the GNOME desktop session. So in order to run a GNOME desktop session, to have the display, to have the panel on top and all the window management functions you are casting to, there are a couple of a number of base components, which is well, the aptly named GNOME session, the GNOME shell, which takes care of the UI and so on. And another important part is the GNOME settings statement, which actually spawns a lot of auxiliary statements like taking care of keyboard shortcuts, media keys, screen color, and many, many other helper things. Starting with, yeah, GDM without knowing the GNOME architecture, I thought that GDM would be a really simple thing to port and to package. But soon I discovered circular dependency, which is a bit interesting in GNOME. So GDM itself, in order to display the login screen and to grid the user with the login screen with the user and password, it needs the GNOME shell package to display the UI, which includes calendar and other buttons around. But if you want to run GNOME shell before porting GDM, well, you actually cannot. In order to build it, you need to have GDM installed. And GNOME shell depends on the GDM for deciding when to display or I don't know exactly, but it relies on it for displaying the login screen whenever there is a period of inactivity of the user. And yeah, what happened in the end because of this decided to split the GDM package in two parts. So one is the LibGDM, which includes only the library required by GNOME shell to communicate with the lock screen. And the actual display manager, the GDM package is packaged separately as a work in progress package, because I was still having issue with it. I could not restart the login screen after logging out from a user session. Right now we're just like spawning in GNOME for me the normal X, XDM display manager or just running StarTex with the name session in the X and XC file. Yeah, I would say StarTex or XDM is the recommended way for now. Yeah, also one thing important to note while packaging GNOME, porting GNOME, well, we have two separate packages for GNOME shell and MOTOR. They probably could be one thing, because MOTOR is responsible for window management and compositing, but it's actually loaded dynamically as a library by GNOME shell. And usually whenever the API is updated for MOTOR, you have to, there is a new GNOME shell version as well. So these packages cannot be updated independently from each other. They have to follow the same version. Yeah, most of the, especially newer GNOME packages use the meson drill system. So it was nice thing to learn. Maybe not everyone likes it, but I feel we have a good support for meson in the package source. And here below I have an example of how a typical configuration of meson would look like in a package. I wouldn't go in detail in a packaging for package source, because there is, I think, too much to talk on. That would deserve a different slide or a lesson. I think we have in it bestie, but we don't really have so much in our operating system. Yeah, so the story with PAX is that it was originally a patch for the Linux kernel, and then it just kind of laid dormant figures and was never accepted upstream, but we've integrated some of the PAX security features into NetBSD, including MProtect. And it just, it stops memory that was ever writable from becoming executable unless it's declared beforehand that it's allowed to become executable later. And I spent some time modifying SpiderMonkey, which is the Mozilla JavaScript engine to support this, because GNOME shell was loading SpiderMonkey dynamically, and we didn't want to disable this kind of important security feature while running GNOME, because it's quite a killer feature that NetBSD has, in my opinion. And as far as I know, MProtect is enabled by default in a new NetBSD install. So if we wouldn't patch SpiderMonkey or other just-in-time compiler to be aware of MProtect and to assign the memory properly or declare the mappings, then they would just fail to execute in a default install. You would have to disable the memory protection otherwise. Yep. And yeah, going on into the pain points, which was actually one of the most difficult parts of the port. One of them is the dependency, the very hard dependency on LoginD. Well, while GNOME used to support our things for seat management, the console kit, it has been removed just a couple of years ago. So most of the OpenBSD patches that we imported was actually for reintroducing console kit support. And yeah, those patches are in the Packersource bit difficult to upstream them, because we don't have a large user base that asks for a console kit. Yeah, I don't know what the perspective is of getting a console kit again into GNOME. Well, it was quite a weird discussion, because on the mailing list, they said, okay, we're going to remove console kit support. Is anyone using this? And people replied saying, yes, we're using this. And then they hadn't removed it anyway. So. Yeah, so at least officially, they support anything that is implementing the LoginD API, which we don't have in Packersource. We currently don't have any package that implement that API. But we do have a console kit fork called the console kit two, and patches we have for console kit work with this fork. There are some things in development that we might consider for LoginD support or something that might replace LoginD. There is a package developed by David McKay called Initware. It's a fork of SystemD, but as I had discussion with David, he had some trouble porting the sit management part of a LoginD. It's had a lot of Linux specific things. Another thing that is portable is a package called or two packages called the sit D and the live sit by Kenny Levison. I think he's one of the sway well and compositor guys. And the purpose of this library is to be portable. And yeah, as I cannot say much about it, but a portable library that can work on multiple operating systems has maybe more chance to be accepted into GNOME. Yeah, so this is very much also cry for help. So if anyone can contribute to this part of the ports or the ecosystem, it would be hugely helpful for us. One interesting thing that I discovered in let's say POSIX programming or UNIX programming, I come from a web dev background, especially things like PHP, Python, and localization was never a problem for me, but I discovered that on the operating system level, at least in UNIX, locale was usually set per process. And there is a possibility to set locales per thread. But everyone I talked to about the functions that implement this functionality use locale and set locale. They are considered as not great implementation or not great ideas. They are more a stop gap solution, but there was never a proper solution, I mean standardized. Yeah, we had this problem because use locale specifically is used by GNOME to set up the locale of the current thread in parts of the ecosystem that use localization. But we don't have use locale implemented in NBST. And probably there's no chance there will ever be, I guess. Yeah, we'll see what the future holds really. But the preferred replacements of the functions that just set the locale temporarily for that specific call. And that's what unspatched the GNOME packages to use and patches have been set up upstream, right? Well, I think my package upstream I'll share the link later. It's about supporting print underscore l functions on NBST. Problem is, it's only supported on NBST. And I don't know, the correct way is to maybe convince our operating system to implement them as well. One thing those that seem complete in NBST, even if we have print underscore l, which basically allows us to set the locale at function call, we don't have to set it per thread, is that when we want to use get text for localization for translated messages, there is no equivalent. So a thing that would be nice that we do in NBST if we also implement it, get text underscore l, family of functions. Yep, that's it about locales. Yeah, many probably would be curious about Wayland and what's going on. So unfortunately, at the current moment, we cannot run a Wayland session with GNOME. Mostly because, yeah, porting Wayland is difficult, and many most of the Wayland stuff depends on Linux kernel APIs. Maybe Nia, you want to tell more about this in detail? Yeah, I spent some time a couple of years ago porting some simpler compositors, and those are usable right now actually, but specifically porting the parts of GNOME that support Wayland is not something that I've gotten around to, and it's not something I'm sure I have time for at the moment. I'll complete the messages. Okay, so we're almost at the end, but That was a nice screenshot. I couldn't make a demo. It was not possible in my hardware for GNOME, but this is GNOME 40, or 40.1 or 40.2 GNOME shell session. This is how it looks in MBC. This is a standard GNOME installation with minimal modifications needed to run it on MBSD. It works and it's quite smooth on supported hardware. Of course, 3D accelerated graphics cards is required. We're going to hopefully have an update to the graphics stack very soon, so many more newer GPUs will be supported. That's becoming quite stable. Instructions to install GNOME desktop on the wiki. We have some a bit outdated package source packaging docs. I'm trying to keep them up today for GNOME. It's a lot of work though, but I feel they are quite good already, so if you want to give it a try, just go to the wiki and try installing. I mentioned a bit about Wayland and GNOME upstream. I found in my communications when I tried to upstream, well, that people are usually receptive or they're welcoming patches, but a big obstacle in having MBSD support is that there is no continuous integration pipelines. Neither free desktop or the Wayland people have it nor the GNOME. If we have some tests that are supposed to check for MBSD support, basically there's no automated way to run them in their infrastructure. While it's not a super difficult project, it still needs some time to implement the CI for MBSD. It's possible if we could get any kind of people or support to getting this that would go a long way into improving the ports. I have enjoyed working on the GNOME port a lot, and that's hugely thanks to Maya who initially posted the bounty on the mailing lists. Nia helped me a lot working on GNOME packages and Thomas also was sponsoring me because during this project also became an MBSD developer. That's a really great achievement for me and I'm really happy. That's about all. If there are any questions, please. Thank you Dan. Are there any questions? You can write them on the chat. Yes, I see a question. Thank you Luna also for joining the talk. Luna has a question about porting version 41 of GNOME. That's supposed to be released on Wednesday, as I see. Yes, I hope I can find the time, but getting the test version is straightforward. I think I already tried something in the WIP part of the package source, in the working focus packages, so definitely there is no big obstacle in getting version 41 of GNOME. It should be there soon. It shouldn't be that different from Voltation. Yes, it is not different. GNOME 40 was not very different from GNOME 3 in terms of packaging, so GNOME 41 is even less different. Okay, thank you very much for your answers. Any other questions, please? If not, thank you very much Dan for your presentation. Very nice one. I propose to adjourn here. The chat will remain open if there will come any new questions you can respond there. Of course, we can find us as well on the IRC channels, on the mailing lists. Thank you guys again for having us, and yeah, I hope you enjoyed it. Thank you again. Bye-bye. Hi. Oh, there is a question from Thomas, I think, yeah? Yeah. Do we know people at Free Desktop for GNOME that know how to add NBZ to CI? We were talking about adding a question using the sourcehub CI, but that wasn't possible for some reason. So the thing is, they use GitLab CI. That's a software I'm familiar with. I use that work. I have at least the basic knowledge how to do this, but I didn't work on NBZ deep backlines, especially with virtual machines. So it would take me quite some time, I guess a week or two to work on it. And yes, there was a sourcehub proposal to the guys on sourcehub offer NBZD runner, but there was a problem connecting GitLab CI to the sourcehub runners. Yeah. So if I find the time, I would love to work on the GitLab CI, I think, for GNOME and Free Desktop, but I don't know when this is going to happen. And if someone has the opportunity or needs any help, I'm happy to provide. We might be able to find some NBZD foundation funding for it. That's good. Any other questions? Okay, then thank you again for your answers. So we can remain here around. If there will be, we can write it on the chat. So thank you again then for your presentation. Thank you. Have a nice day. You too. Enjoy.