| 1 |
I'd like to start giving ~monthly updates on the status of x11@ packages |
| 2 |
in Gentoo. I hope it gives some insight into the status of a rather |
| 3 |
important set of packages and maybe encourages others to lend a hand to |
| 4 |
a very understaffed project when possible. |
| 5 |
|
| 6 |
I expect future reports to be significantly shorter. |
| 7 |
|
| 8 |
x11@ currently maintains 291 packages. This number is down from 328 |
| 9 |
after the removal of 37 drivers for very old hardware in bug 606132. |
| 10 |
|
| 11 |
x11@ is currently assigned or cc'd on 222 bugs. This number is down from |
| 12 |
more than 412 in February 2015 (I reported this on #gentoo-desktop after |
| 13 |
closing out a bunch of bugs that day). |
| 14 |
|
| 15 |
I work on media-libs/mesa professionally for Intel, so I am involved |
| 16 |
with upstream for a number of the projects maintained by x11@ and know |
| 17 |
the right people to contact for the others. My strategy maintaining x11 |
| 18 |
packages is to keep a git ebuild in sync with upstream changes. When a |
| 19 |
release is made, everything should already be ready on the Gentoo side, |
| 20 |
and I'm able to just copy the git ebuild. This has enabled me to provide |
| 21 |
new versions of packages very quickly. I believe it has also helped |
| 22 |
reduce the time to stabilizing packages, since users often test and |
| 23 |
report bugs against the git ebuilds. |
| 24 |
|
| 25 |
My list of to-do items consists of: |
| 26 |
|
| 27 |
== Fix x11-base/xorg-server suid/systemd situation == |
| 28 |
https://bugs.gentoo.org/635102 |
| 29 |
|
| 30 |
Under some circumstances (kernel modesetting driver + systemd, I think) |
| 31 |
Xorg should be able to run without root privileges. We were shipping a |
| 32 |
USE=suid option without anyone knowing or understanding its purpose. |
| 33 |
|
| 34 |
For >=x11-base/xorg-server-1.20 I plan to ship the xserver in a way that |
| 35 |
allows systemd/elogind users with kernel modesetting drivers to run Xorg |
| 36 |
without root privileges. I expect to push version 1.19.99.902 (1.20 RC2) |
| 37 |
into the tree soon with something working for systemd. I would very much |
| 38 |
appreciate an ebuild patch from any elogind user as well as non-systemd |
| 39 |
testing to make sure I haven't broken anything like I did with |
| 40 |
1.19.99.901. |
| 41 |
|
| 42 |
== Update packages to depend on x11-base/xorg-proto == |
| 43 |
https://bugs.gentoo.org/651286 |
| 44 |
|
| 45 |
The new x11-base/xorg-proto package combines nearly all (28 in fact) of |
| 46 |
the x11-proto/* packages into one, with a very fast Meson build system. |
| 47 |
It installs on my laptop in less time than it takes to ./configure one |
| 48 |
of the individual x11-proto/ packages. I've kept empty versions of the |
| 49 |
x11-proto/ packages to ease the transition. |
| 50 |
|
| 51 |
Once the last two architectures have stabilized it (arm@ and arm64@), we |
| 52 |
can begin transitioning to depending on x11-base/xorg-proto directly |
| 53 |
instead of the x11-proto/ packages. |
| 54 |
|
| 55 |
If there's a way to have repoman alert developers to deprecated |
| 56 |
dependencies in the same way we handle deprecated eclasses, I'd like to |
| 57 |
know about it. |
| 58 |
|
| 59 |
== Remove x11-proto/printproto and x11-libs/libXp == |
| 60 |
https://bugs.gentoo.org/649076 |
| 61 |
|
| 62 |
Support for the Xprint extension was removed from xorg-server-1.6.0 |
| 63 |
released 9 years ago, yet a handful of packages still claimed a |
| 64 |
dependence on the Xprint client library libXp. |
| 65 |
|
| 66 |
We've nearly removed all traces of it, and are waiting on the last few |
| 67 |
bugs to be closed out. |
| 68 |
|
| 69 |
== Convert media-libs/mesa ebuild to build with Meson == |
| 70 |
|
| 71 |
Mesa has grown a Meson build system over the last few months. I plan to |
| 72 |
ship media-libs/mesa-18.1 (Q2 2018) using Meson. |
| 73 |
|
| 74 |
hanetzer in #gentoo-desktop has been working on this. |
| 75 |
|
| 76 |
== Convert media-libs/xorg-server ebuild to build with Meson == |
| 77 |
|
| 78 |
The Xserver has also grown a Meson build system. I think it will |
| 79 |
probably be in reasonable shape by 1.20, but I don't want to delay it |
| 80 |
getting into the tree for that. 1.21 will probably be a long way off, |
| 81 |
but I expect to ship it with Meson, if not something before. |
| 82 |
|
| 83 |
No work has been done on this. |
| 84 |
|
| 85 |
== Add and require glvnd == |
| 86 |
https://bugs.gentoo.org/606924 |
| 87 |
https://github.com/NVIDIA/libglvnd |
| 88 |
|
| 89 |
OpenGL has historically been provided by a vendor's libGL.so. That's |
| 90 |
caused a number of headaches for distributions, since both |
| 91 |
x11-drivers/nvidia-drivers and media-libs/mesa would like to install |
| 92 |
/usr/lib/libGL.so. |
| 93 |
|
| 94 |
The GL Vendor-Neutral Dispatch library ("glvnd") defines a new common |
| 95 |
library interface, which dispatches to the underlying hardware driver. |
| 96 |
|
| 97 |
Mesa and the NVIDIA drivers both have support, but it needs to be wired |
| 98 |
up in Gentoo. Doing this would allow us to get rid of |
| 99 |
app-eselect/eselect-opengl and a whole class of build failures. |
| 100 |
|
| 101 |
No work has been done on this. I plan to do it after Mesa is converted |
| 102 |
to build with Meson. |
| 103 |
|
| 104 |
== Drop app-eselect/eselect-mesa == |
| 105 |
https://bugs.gentoo.org/576334 |
| 106 |
|
| 107 |
While app-eselect/eselect-opengl allows users to switch between OpenGL |
| 108 |
implementations (x11-drivers/nvidia-drivers vs media-libs/mesa), |
| 109 |
app-eselect/eselect-mesa allows users to switch between Mesa drivers for |
| 110 |
the same hardware. This made sense a few years ago, when there were both |
| 111 |
Gallium and "classic" DRI drivers for the same hardware, but today only |
| 112 |
the 10 year old i915/i945 integrated graphics still falls into this |
| 113 |
category. Frankly, both of the driver options there are horrible. |
| 114 |
|
| 115 |
We should just get rid of this complexity and rid ourselves of the |
| 116 |
collection of unfixed bugs filed against eselect-mesa. |
| 117 |
|
| 118 |
No work has been done on this. I plan to do it after Mesa is converted |
| 119 |
to build with Meson. |
| 120 |
|
| 121 |
== Fix/Remove OpenCL == |
| 122 |
https://bugs.gentoo.org/546320 |
| 123 |
https://bugs.gentoo.org/647330 |
| 124 |
|
| 125 |
Mesa provides an OpenCL implementation to some Gallium3D drivers |
| 126 |
(radeonsi, nouveau, ...). I don't use these drivers and I don't use |
| 127 |
OpenCL, so this has been difficult for me to maintain. Or, honestly... |
| 128 |
care about. |
| 129 |
|
| 130 |
app-eselect/eselect-opencl provides the mechanism for switching |
| 131 |
libOpenCL.so symlinks between implementations, but I expect all |
| 132 |
implementations support the OpenCL Installable Client Driver ("ICD") |
| 133 |
interface, which allows drivers to be installed side-by-side like with |
| 134 |
glvnd. |
| 135 |
|
| 136 |
Or we can just rm -rf it all from the tree. That would suit me fine, and |
| 137 |
no one else seems to care enough to maintain it. I have given serious |
| 138 |
consideration to use.masking mesa's opencl flag. |
| 139 |
|
| 140 |
== Clean out x11 overlay == |
| 141 |
https://gitweb.gentoo.org/proj/x11.git/ |
| 142 |
|
| 143 |
The X11 overlay held git ebuilds for x11 packages but keeping them |
| 144 |
separate from the rest of the versions in the main tree is a receipe for |
| 145 |
problems. I've periodically moved things out of the X11 overlay to the |
| 146 |
main tree as it made sense. (For a lot of packages, there's no point in |
| 147 |
a git ebuild so we should just delete those from the overlay) |
| 148 |
|
| 149 |
Once that is done, I could see using the X11 overlay for things like old |
| 150 |
xserver versions (ones with XAA, maybe) or old drivers. |
| 151 |
|
| 152 |
|
| 153 |
|
| 154 |
|
| 155 |
|
| 156 |
If any of these pique your interest, please let me know. I'd love to get |
| 157 |
some help! |
Archives