This partially reverts bf3d3dd19b48c432dd83aa0385b47dbe84aa647b.
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
Both e3d3bc66dc496f940b427443b503a67434e115b5 and 1d15641433b97eb1a45a7adec0a0e94600127dfb were done incorrectly.
Also, use python3 in generate-expr-from-tarballs.pl instead of overrides.nix.
Since c2526545844bdbb8347f9d9169a77728bf2bdd73, 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 c778945806b 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: 4effe769e2b
- `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 (803ca85c209)
- 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 c778945806b44d46ec16bc4302e7e7163e6bab97.
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).
I'm sorry; I didn't notice it contained staging commits.
This reverts commit 17f5305b6c20df795c365368d2d868266519599e, reversing
changes made to a8a018ddc0a8b5c3d4fa94c94b672c37356bc075.
