[gentoo-dev] Monthly x11@ project status for April 2018

[gentoo-dev] Monthly x11@ project status for April 2018

[Matt Turner]

[-- Attachment #1: Type: text/plain, Size: 6639 bytes --]

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!

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[gentoo-dev] Re: Monthly x11@ project status for April 2018

[Duncan]

Matt Turner posted on Sun, 01 Apr 2018 20:08:35 -0700 as excerpted:

> 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.

FWIW I understood it, but also knew it broke X for me back when I first 
tried it.  However...

> 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.

I noticed the recent no-superuser X changes here (on ~amd64), and decided 
to try it again...

And now (after undoing an old hack I had to manually set SUID here) I 
have X running as my normal user.  Thanks! =:^)

FWIW, systemd with modesetting (amdgpu), as you suspected.  startx (no *dm 
at all merged).  X starts on top of the vt1 login.  xorg-
server-1.19.99.901-r1

> == 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.

I noticed that I didn't need many of the protos any longer here too, and 
figured it was a recombining.  Thanks for the confirmation. =:^)

And thanks for the roadmap to what's ahead re X. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: Monthly x11@ project status for April 2018

[Matt Turner]

On Sun, Apr 1, 2018 at 8:08 PM, Matt Turner <mattst88@gentoo.org> wrote:
> == 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.

Question from IRC: why is the package named x11-base/xorg-proto
instead of x11-proto/xorgproto?

Once all of the now empty compatibility packages in x11-proto/ are
gone, the only remaining packages in the category will be printproto
and xcb-proto. The plan is to give last rites to printproto and move
xcb-proto to some other category, x11-base probably, and get rid of
x11-proto/ entirely.

The dash in the xorg-proto is just for consistency with the other
x11-base/ packages.