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.
The library does not depend on stdenv, that stdenv exposes lib is
an artifact of the ancient origins of nixpkgs.
I didn’t run the generator since it takes quite a while, but it should
be automatically done the next time somebody updates a package.
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
Since c252654584, building xf86videointel
has been broken on my system due to missing libXv. This commit
explicitly includes the dependency when building the package to
hopefully avoid things being broken for others.
I made a mistake merge. Reverting it in c778945806 undid the state
on master, but now I realize it crippled the git merge mechanism.
As the merge contained a mix of commits from `master..staging-next`
and other commits from `staging-next..staging`, it got the
`staging-next` branch into a state that was difficult to recover.
I reconstructed the "desired" state of staging-next tree by:
- checking out the last commit of the problematic range: 4effe769e2
- `git rebase -i --preserve-merges a8a018ddc0` - dropping the mistaken
merge commit and its revert from that range (while keeping
reapplication from 4effe769e2)
- merging the last unaffected staging-next commit (803ca85c20)
- fortunately no other commits have been pushed to staging-next yet
- applying a diff on staging-next to get it into that state
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).
