supersedes PR 70239
Description from that PR
Make xorg apps look as intended. Most notable change: xmag color picker is usable now.
Before this commit, only two apps had properly configured resource paths: bitmap and xcalc. This commit automates and generalizes it to the rest of xorg.* apps.
xorg.bitmap: bin/bitmap-color is no longer installed. If you would like bitmap to be viewable in color, please refer to man 1 bitmap, selection COLORS. The described method is also applied to some other affected apps.
The new derivation should evaluate only if the old derivation does.
Sadly this means that the old derivation cannot depend on the new one
any more, which was used by xorgserver on Darwin. But this is not a
problem as `overrideAttrs` can (and should) usually be used instead.
This change allowed catching an invalid `meta.platforms` in the linux_rpi
kernels, which use `overrideDerivation`.
Previously, Darwin was kept on 1.18 because more recent versions were
broken, but now 1.18 is also broken on Darwin, so we might as well get
rid of the special case and bring Darwin forward. With these changes,
xQuartz builds on Darwin, but when run it will exit immediately.
This makes Darwin use the same derivation as Linux by default, which
will enable further cleanups. But as a result, we have to fix some
Linuxisms.
* Only add libdrm dependency on compatible platforms.
* Add libepoxy dependency for all platforms.
* Add bootstrap_cmds dependency on Darwin.
* Disable glamor on Darwin.
```
xdm-aarch64-unknown-linux-gnu> checking for cpp... no
xdm-aarch64-unknown-linux-gnu> checking if aarch64-unknown-linux-gnu-gcc -E requires -undef... aarch64-unknown-linux-gnu-gcc: fatal error: noinput files
xdm-aarch64-unknown-linux-gnu> compilation terminated.
xdm-aarch64-unknown-linux-gnu> aarch64-unknown-linux-gnu-gcc: fatal error: no input files
xdm-aarch64-unknown-linux-gnu> compilation terminated.
xdm-aarch64-unknown-linux-gnu> aarch64-unknown-linux-gnu-gcc: fatal error: no input files
xdm-aarch64-unknown-linux-gnu> compilation terminated.
xdm-aarch64-unknown-linux-gnu> configure: error: aarch64-unknown-linux-gnu-gcc -E defines unix with or without -undef. I don't know what to do.
```
it appears that the configure script isn't checking
`${ac_tool_prefix}cpp`
```
for ac_prog in cpp
do
# Extract the first word of "$ac_prog", so it can be a program name with args.
set dummy $ac_prog; ac_word=$2
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
$as_echo_n "checking for $ac_word... " >&6; }
if ${ac_cv_path_RAWCPP+:} false; then :
```
```
imake-aarch64-unknown-linux-gnu> checking for cpp... no
imake-aarch64-unknown-linux-gnu> checking if aarch64-unknown-linux-gnu-gcc -E requires -undef... aarch64-unknown-linux-gnu-gcc: fatal error: noinput files
imake-aarch64-unknown-linux-gnu> compilation terminated.
imake-aarch64-unknown-linux-gnu> aarch64-unknown-linux-gnu-gcc: fatal error: no input files
imake-aarch64-unknown-linux-gnu> compilation terminated.
imake-aarch64-unknown-linux-gnu> aarch64-unknown-linux-gnu-gcc: fatal error: no input files
imake-aarch64-unknown-linux-gnu> compilation terminated.
imake-aarch64-unknown-linux-gnu> configure: error: aarch64-unknown-linux-gnu-gcc -E defines unix with or without -undef. I don't know what to do.
```
it appears that the configure script isn't checking
`${ac_tool_prefix}cpp`
```
for ac_prog in cpp
do
# Extract the first word of "$ac_prog", so it can be a program name with args.
set dummy $ac_prog; ac_word=$2
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
$as_echo_n "checking for $ac_word... " >&6; }
if ${ac_cv_path_RAWCPP+:} false; then :
```
While looking into #197407, I noticed that <X11/extensions/XInput2.h>
depends on <X11/extensions/Xge.h> which is found in libXext and thus
needs to be propagated.
The i965 driver was removed in Mesa 22, but the xf86videointel driver
hasn't been updated to reflect this. This leads to the following error
when used with the affected hardware:
(EE) AIGLX error: dlopen of /run/opengl-driver/lib/dri/i965_dri.so failed
(/run/opengl-driver/lib/dri/i965_dri.so: cannot open
shared object file: No such file or directory)
(EE) AIGLX error: unable to load driver i965
To fix this, add a patch which makes the driver return the appropriate
DRI driver name from Mesa 22, i.e. `crocus` for older GPUs and `iris`
for newer.
Without the change build fails on upstream gcc-10 as:
ld: src/xgi_accel.h:125: multiple definition of `Alignment';
src/xgi_accel.h:125: first defined here
* xorg.xf86videoopenchrome: pull upstream fix for -fno-common toolchain
Without the chage build fails on upstream gcc-10 as:
ld: .libs/via_xvmc.o:/build/xf86-video-openchrome-0.6.0/src/via_vt1632.h:47: multiple definition of
`via_vt1632_funcs'; .libs/via_analog.o:/build/xf86-video-openchrome-0.6.0/src/via_vt1632.h:47: first defined here
* Update pkgs/servers/x11/xorg/overrides.nix
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
Several drivers are built for Darwin on Hydra even though they never
worked and probably never will work there. Mark them as broken to avoid
wasted cycles.
upstream startx unsets DBUS_SESSION_BUS_ADDRESS, which in turn breaks
applications run under the startx display manager. arch has shipped this
patch for years as well.
(with review changes from @Mic92)
OpenGL applications should not depend on the Mesa drivers, since these
are supposed to be loaded at runtime from /run/opengl-driver using the
glvnd library. Furthermore, the drivers output has a large closure
since it depends on LLVM.
The only dependency from dev to drivers came from the xatracker
pkg-config file. This commit moves this file into a new
output called driversdev.
continuation of #109595
pkgconfig was aliased in 2018, however, it remained in
all-packages.nix due to its wide usage. This cleans
up the remaining references to pkgs.pkgsconfig and
moves the entry to aliases.nix.
python3Packages.pkgconfig remained unchanged because
it's the canonical name of the upstream package
on pypi.
This partially reverts bf3d3dd19b.
I don't know why we weren't getting a default logfile back then but Xorg
definitely provides one now ($XDG_DATA_HOME for regular users and /var/log for
root, see `man Xorg`)
Xorg creates the log-dir in its output path because X crashes if it can't write
to its logfile. On a regular distro, this dir would be installed into the root
to prevent that from happening but with Nix, it sits in the read-only Nix store.
Ironically, when Xorg tries to write here, it fails and crashes.
To make Xorg log to /var/log, we have to stop the build script from trying to
create the log-dir as the sandbox doesn't (and shouldn't) have access to /var.
This creates a runtime dependency on /var when running as root but that should
exist on any Linux system (on NixOS, journald always creates /var/log).
Previously, the startx displayManager required some workarounds for logfiles
which are obsolete now.
patchPhase -> postPatch because overriding the patchPhase prevents patches from
being applied
This reverts commit c778945806.
I believe this is exactly what brings the staging branch into
the right shape after the last merge from master (through staging-next);
otherwise part of staging changes would be lost
(due to being already reachable from master but reverted).
