Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

X issues/crashes #159

Open
lowne opened this issue Mar 22, 2022 · 4 comments
Open

X issues/crashes #159

lowne opened this issue Mar 22, 2022 · 4 comments
Labels
not our bug Bug is inside used dependency / library

Comments

@lowne
Copy link
Contributor

lowne commented Mar 22, 2022

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:

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 m1k1o pinned this issue Apr 9, 2022
@m1k1o
Copy link
Owner

m1k1o commented Apr 9, 2022

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
Copy link
Contributor Author

lowne commented Apr 9, 2022

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
Copy link
Owner

m1k1o commented Apr 9, 2022

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
Copy link
Contributor Author

lowne commented Apr 10, 2022

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)

@m1k1o m1k1o added the bug Something isn't working label Jun 17, 2022
@m1k1o m1k1o added not our bug Bug is inside used dependency / library and removed bug Something isn't working labels Oct 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
not our bug Bug is inside used dependency / library
Projects
None yet
Development

No branches or pull requests

2 participants