On 2019-12-31 2:04 p.m., Martin von Gagern wrote: > My issue appears to be largely due to a version mismatch, and I have > been able to resolve this. > > I had tried to get a specific version from unstable to test a fix for > a different bug, but apparently I misunderstood how pinning works and > got updates to mesa packages from the unstable release even after the > version for which I intended this. Once I downgraded mesa packages to > testing version, I was able to start X again. > > I'll leave it to you whether you believe this kind of issue is worth > addressing at the distro level (perhaps via more strict version > dependencies?) or forwarding to the upstream maintainers
I suspect the problem was due to libegl-mesa0 being a different version than libglapi-mesa. The ABI between libglapi and other Mesa libraries isn't stable upstream, so all dependencies on libglapi-mesa should probably be restricted to the same version. > (so that unexpected behavior from a module library gets detected in a nicer > fashion than by crashing the X server). xserver code can't protect itself against memory corruption like this. > $ dpkg -l '*mesa*' > Desired=Unknown/Install/Remove/Purge/Hold > | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend > |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) > ||/ Name Version Architecture Description > +++-===============================-============-============-=========================================================> > ii libegl-mesa0:amd64 19.2.6-1 amd64 free > implementation of the EGL API -- Mesa vendor library > [...] > ii libglapi-mesa:amd64 19.3.1-3 amd64 free > implementation of the GL API -- shared library -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer
