Le Sun, Jul 16, 2023 at 09:16:55PM +0200, Matthieu Herrb a écrit : > Hi, > > I've now finished a first draft set of ports to get sway running on > OpenBSD. > > The good news is that sway works over the existing mesa version in > Xenocara, so building a custom mesa is not needed (at least for now). > > I've made all those ports available there : > https://gitlab.tetaneutral.net/mherrb/wl-ports > > This include the 2 ports I've posted here already, including fixes for > jca@'s comments. (graphics/libliftoff and sysutils/libdisplay-info) > > Other ports are not really suited for import in the main ports tree > for now. This is mainly because there are still a number of bugs, but > also because I used non released versions of seatd and wlroots (the > latests existing releases have bugs and linuxisms that make an OpenBSD > port more painful than their development branches). > > I've pointed to my forks of the different projects as MASTER_SITE for > these ports for now. The goal is to move back to the original distrib > files as soon as good enough releases are made. My branches will > either be submitted for merging upstreams or shipped as patches. > > Also the libinput-openbsd sources are kind of hackish. They were > derived from the official libinput from 2016, with some later changes > folded back in, but the main project has re-factored and moved sources > files around. I think more work needs to be done to either fully fork > this and remove remnants from the original code that aren't needed or > to re-align it with the Linux libinput repository. > > I'm taking patches, both to the ports and to the forked repositories > (see MASTER_SITES or the Waylan on OpenBSD doc below). > I'm going to maintain them for now to keep track of the work. > > If anyone wants to give ok to commit some of these to OpenBSD, I'll do > that and remove the corresponding ports from the wl-ports > repository. But apart for the 2 already submmitted, they all depend on > non-ready ports imho.
there's imo one thing to consider before linking anything to the build: assess how much of the portstree will detect the evdev/libinput headers, and what will break from that. there's nothing preventing those ports from being imported (even if you point at your own forks), they can be improved in-tree and switched to the upstream sources once patches are upstreamed/cleaned up. thanks for the tremendous amount of exploratory work here, promising! Landry
