XQuartz.app needs to be able to find the `startx' from the `xinit'
package, but it defaults to assuming it is in the same directory as
the Xquartz binary, which it will never be. This restores a patch that
uses environment variables to locate `startx', which is what the
`xquartz' package is expecting to use.
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)
