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
Announcements:
- https://docs.mesa3d.org/relnotes/20.2.0.html
- https://docs.mesa3d.org/relnotes/20.2.1.html
I've rebased the patches accordingly and avoided:
meson.build:320: WARNING: Platform `surfaceless` is now always selected; setting this option will be an error in Mesa 20.3
meson.build:324: WARNING: Platform `drm` is now automatically selected; setting this option will be an error in Mesa 20.3
This will also fix the list in the configuration summary:
EGL/Vulkan/VL platforms: x11 surfaceless wayland drm surfaceless drm
https://lists.freedesktop.org/archives/mesa-dev/2018-October/207343.html
Optimistically drop disk cache patch, changelog mentions related
changes to cache behavior.
Not sure if those changes address our problem
(can we count on build-id?) so someone more familiar with
this should probably take a look before merging :).
Mesa usually uses the timestamps of the llvm and driver shared libraries
as a cache key. In /nix/store these are all zero, so we'll include
$(drivers) in the cache key, which should be unique for all combinations
of mesa and llvm versions.
