neko icon indicating copy to clipboard operation
neko copied to clipboard

X issues/crashes

Open lowne opened this issue 3 years ago • 4 comments

Just wanted to have an issue to track possible repercussions of #151 - feel free to close after a while if nobody chimes in.

Copypaste from PR

Sometimes on container startup X will throw a fit with (possibly non-exhaustive list):

Xorg: ../../../../../../include/privates.h:121: dixGetPrivateAddr: Assertion 'key->initialized' failed.
Xorg: ../../../../dix/privates.c:384: dixRegisterPrivateKey: Assertion '!global_keys[type].created' failed.

as soon as neko starts (and then neko itself dies). When that happens supervisord will restart both and soon enough they'll both manage to say alive and settle down. Looking for clues reveals a bunch of long-standing X bugs with a bunch of supposed patches and the general advice of "start X as root kthx" (which is not the case in neko, as it stands).

References

Some of the links I dug up:

  • https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1745345
  • https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1861609
  • https://gitlab.freedesktop.org/xorg/xserver/-/issues/615

And a hilarious quote from one of them which perhaps accurately reflects the state of Xorg:

Is there another workaround?

Yes, just select 'Ubuntu on Wayland' from the login screen.

Which had me think that maybe one day in the distant future it might be nice to switch to wayland+pipewire...

lowne avatar Mar 22 '22 09:03 lowne

Looks like this addition made mutliplatform build to fail. https://github.com/m1k1o/neko/runs/5955936398?check_suite_focus=true

Either we shoudl find multiplatform solution for this or at least install it only when it is ams64, so that it at least builds.

m1k1o avatar Apr 09 '22 18:04 m1k1o

If you're talking about #151 then absolutely it should only be for amd64, there's no QSV on non-Intel CPUs (and so - reasonably - no related packages for arm64). I haven't touched the build scripts as I don't know how they work, I just saw a Dockerfile.arm and assumed it was the one used for arm builds - and left it untouched.

lowne avatar Apr 09 '22 18:04 lowne

Currenty Dockerfile.arm is used for armv7 and i am experimenting with armv8 in different build pipeline.

it should only be for amd64 Then we either need own build for armv8, or join armv7 and armv8, or add that dependency conditionaly.

m1k1o avatar Apr 09 '22 18:04 m1k1o

own build for armv8

Seems to me like the way to go, I assume armv7 will go away at some point, no?

add that dependency conditionaly.

It's possible, and it's desirable to have a unified pipeline, but imho it creates more headaches than it's worth; the multiarch story in the general Linux ecosystem doesn't seem quite ready yet (and for containers specifically, multiarch still seems to be the exception rather than the norm)

lowne avatar Apr 10 '22 10:04 lowne