I'd like to start giving ~monthly updates on the status of x11@ packages in Gentoo. I hope it gives some insight into the status of a rather important set of packages and maybe encourages others to lend a hand to a very understaffed project when possible.
I expect future reports to be significantly shorter. x11@ currently maintains 291 packages. This number is down from 328 after the removal of 37 drivers for very old hardware in bug 606132. x11@ is currently assigned or cc'd on 222 bugs. This number is down from more than 412 in February 2015 (I reported this on #gentoo-desktop after closing out a bunch of bugs that day). I work on media-libs/mesa professionally for Intel, so I am involved with upstream for a number of the projects maintained by x11@ and know the right people to contact for the others. My strategy maintaining x11 packages is to keep a git ebuild in sync with upstream changes. When a release is made, everything should already be ready on the Gentoo side, and I'm able to just copy the git ebuild. This has enabled me to provide new versions of packages very quickly. I believe it has also helped reduce the time to stabilizing packages, since users often test and report bugs against the git ebuilds. My list of to-do items consists of: == Fix x11-base/xorg-server suid/systemd situation == https://bugs.gentoo.org/635102 Under some circumstances (kernel modesetting driver + systemd, I think) Xorg should be able to run without root privileges. We were shipping a USE=suid option without anyone knowing or understanding its purpose. For >=x11-base/xorg-server-1.20 I plan to ship the xserver in a way that allows systemd/elogind users with kernel modesetting drivers to run Xorg without root privileges. I expect to push version 1.19.99.902 (1.20 RC2) into the tree soon with something working for systemd. I would very much appreciate an ebuild patch from any elogind user as well as non-systemd testing to make sure I haven't broken anything like I did with 1.19.99.901. == Update packages to depend on x11-base/xorg-proto == https://bugs.gentoo.org/651286 The new x11-base/xorg-proto package combines nearly all (28 in fact) of the x11-proto/* packages into one, with a very fast Meson build system. It installs on my laptop in less time than it takes to ./configure one of the individual x11-proto/ packages. I've kept empty versions of the x11-proto/ packages to ease the transition. Once the last two architectures have stabilized it (arm@ and arm64@), we can begin transitioning to depending on x11-base/xorg-proto directly instead of the x11-proto/ packages. If there's a way to have repoman alert developers to deprecated dependencies in the same way we handle deprecated eclasses, I'd like to know about it. == Remove x11-proto/printproto and x11-libs/libXp == https://bugs.gentoo.org/649076 Support for the Xprint extension was removed from xorg-server-1.6.0 released 9 years ago, yet a handful of packages still claimed a dependence on the Xprint client library libXp. We've nearly removed all traces of it, and are waiting on the last few bugs to be closed out. == Convert media-libs/mesa ebuild to build with Meson == Mesa has grown a Meson build system over the last few months. I plan to ship media-libs/mesa-18.1 (Q2 2018) using Meson. hanetzer in #gentoo-desktop has been working on this. == Convert media-libs/xorg-server ebuild to build with Meson == The Xserver has also grown a Meson build system. I think it will probably be in reasonable shape by 1.20, but I don't want to delay it getting into the tree for that. 1.21 will probably be a long way off, but I expect to ship it with Meson, if not something before. No work has been done on this. == Add and require glvnd == https://bugs.gentoo.org/606924 https://github.com/NVIDIA/libglvnd OpenGL has historically been provided by a vendor's libGL.so. That's caused a number of headaches for distributions, since both x11-drivers/nvidia-drivers and media-libs/mesa would like to install /usr/lib/libGL.so. The GL Vendor-Neutral Dispatch library ("glvnd") defines a new common library interface, which dispatches to the underlying hardware driver. Mesa and the NVIDIA drivers both have support, but it needs to be wired up in Gentoo. Doing this would allow us to get rid of app-eselect/eselect-opengl and a whole class of build failures. No work has been done on this. I plan to do it after Mesa is converted to build with Meson. == Drop app-eselect/eselect-mesa == https://bugs.gentoo.org/576334 While app-eselect/eselect-opengl allows users to switch between OpenGL implementations (x11-drivers/nvidia-drivers vs media-libs/mesa), app-eselect/eselect-mesa allows users to switch between Mesa drivers for the same hardware. This made sense a few years ago, when there were both Gallium and "classic" DRI drivers for the same hardware, but today only the 10 year old i915/i945 integrated graphics still falls into this category. Frankly, both of the driver options there are horrible. We should just get rid of this complexity and rid ourselves of the collection of unfixed bugs filed against eselect-mesa. No work has been done on this. I plan to do it after Mesa is converted to build with Meson. == Fix/Remove OpenCL == https://bugs.gentoo.org/546320 https://bugs.gentoo.org/647330 Mesa provides an OpenCL implementation to some Gallium3D drivers (radeonsi, nouveau, ...). I don't use these drivers and I don't use OpenCL, so this has been difficult for me to maintain. Or, honestly... care about. app-eselect/eselect-opencl provides the mechanism for switching libOpenCL.so symlinks between implementations, but I expect all implementations support the OpenCL Installable Client Driver ("ICD") interface, which allows drivers to be installed side-by-side like with glvnd. Or we can just rm -rf it all from the tree. That would suit me fine, and no one else seems to care enough to maintain it. I have given serious consideration to use.masking mesa's opencl flag. == Clean out x11 overlay == https://gitweb.gentoo.org/proj/x11.git/ The X11 overlay held git ebuilds for x11 packages but keeping them separate from the rest of the versions in the main tree is a receipe for problems. I've periodically moved things out of the X11 overlay to the main tree as it made sense. (For a lot of packages, there's no point in a git ebuild so we should just delete those from the overlay) Once that is done, I could see using the X11 overlay for things like old xserver versions (ones with XAA, maybe) or old drivers. If any of these pique your interest, please let me know. I'd love to get some help!
signature.asc
Description: Digital signature
