X issues/crashes

[lowne]

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...

[m1k1o]

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.

[lowne]

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.

[m1k1o]

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.

[lowne]

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)