Xquartz has been broken since #40574 because the Xquartz binary
couldn't find the corresponding XQuartz.app. This commit restores an
earlier patch to use an environment variable to find XQuartz.app, and
additionally embeds the path to the XQuartz.app's Nix store location
as a default.
In GitHub issue #221592 I found that virt-manager was not showing PCI info.
Tracking the issue down points to this library, which is consumed by libvirt.
libpciaccess was reading from the default path of /usr/share/hwdata/pci.ids,
which will likely not exist on NixOS.
Instead of using the hard-coded path, change the libpciaccess package to depend
on hwdata at runtime and to be configured with the hwdata share path.
Updated the generation script, as well as committed the newly generated changes.
Some notable changes since Xwayland 22.1 include:
- Support for linux_dmabuf v4 protocol,
- Support for wl_pointer.axis_v120 (high-resolution scrolling),
- Support for xwayland_shell protocol,
- Improved "rootful" mode for using Xwayland as a nested Xserver,
- Improved emulated XRandR support exposing the output names,
- Support for byte-swapped clients is now disabled by default.
Link: https://lists.x.org/archives/xorg-announce/2023-February/003330.html
The primary motivating example is openssl:
Before the change full package build took 1m54s minutes.
After the change full package build takes 59s.
About a 2x speedup.
The difference is visible because openssl builds hundreds of manpages
spawning a perl process per manual in `install` phase. Such a workload
is very easy to parallelize.
Another example would be `autotools`+`libtool` based build system where
install step requires relinking. The more binaries there are to relink
the more gain it will be to do it in parallel.
The change enables parallel installs by default only for buiilds that
already have parallel builds enabled. There is a high chance those build
systems already handle parallelism well but some packages will fail.
Consistently propagated the enableParallelBuilding to:
- cmake (enabled by default, similar to builds)
- ninja (set parallelism explicitly, don't rely on default)
- bmake (enable when requested)
- scons (enable when requested)
- meson (set parallelism explicitly, don't rely on default)
- waf (set parallelism explicitly, don't rely on default)
- qmake-4/5/6 (enable by default, similar to builds)
- xorg (always enable, similar to builds)
with structuredAttrs lists will be bash arrays which cannot be exported
which will be a issue with some patches and some wrappers like cc-wrapper
this makes it clearer that NIX_CFLAGS_COMPILE must be a string as lists
in env cause a eval failure
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.
Package bump:
- Grabs are now deactivated on Xwayland, leaving them to the compositor
- Memleak and length-check fixes for xkb
- Fix for kinetic scrolling
- Delayed wl_surface destruction to fix a race
```
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.
Minor release bump with various use-after-free fixes and a fix for
windowed vulkan windows rendering at 58FPS instead of the expected
60FPS.
Signed-off-by: Rouven Czerwinski <rouven@czerwinskis.de>
