anaconda
anaconda copied to clipboard
rhinstaller
Xorg server removal
Drop the X.Org server dependency
Start GNOME Kiosk as a Wayland compositor and run Anaconda as a native Wayland client.
This commit is a follow up on the work done by @Conan-Kudo [1] and @M4rtinK [2]. Credit goes to them for the code I copied and pasted.
[1] https://github.com/rhinstaller/anaconda/pull/5401 [2] https://github.com/rhinstaller/anaconda/pull/5309/
Please note that the last patch ("Drop the X.Org server dependency") is the only change intended in this PR.
I cherry picked my patches removing libxklavier and xrandr as they are required to support a Wayland session. I'll rebase this PR once the mentioned dependencies are merged.
Hello @jexposit! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:
There are currently no PEP 8 issues detected in this Pull Request. Cheers! :beers:
Comment last updated at 2024-06-06 12:21:12 UTC
Could you please use Co-authored-by: Neal Gompa <[email protected]> in your commit message instead of tagging @Conan-Kudo, since parts of #5401 are included in here and I would very much like to not to get an email every time this commit gets shuffled around.
Please reword like so:
Start GNOME Kiosk as a Wayland compositor and run Anaconda as a native
Wayland client.
This commit is a follow up on the work done by Neal Gompa [1] and
Martin Kolman [2]. Credit goes to them for the code I copied and pasted.
[1] https://github.com/rhinstaller/anaconda/pull/5401
[2] https://github.com/rhinstaller/anaconda/pull/5309
Co-authored-by: Neal Gompa <[email protected]>
Co-authored-by: Martin Kolman <[email protected]>
Thanks! I really didn't want an email every time this commit got refreshed, cherry-picked, or forked. 😅
No problem, I didn't want to share your email publicly without your consent, so I used your GitHub username. Fixed now :D
Images built based on commit 01f49fce1ec662e7f8a8e04a13f69578fb6d3e5d:
-
boot.iso: success
Download the images from the bottom of the job status page.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
When we are at it I suggest we mention also @halfline, as he helped me a lot with my PR & an important part of it was provided by him - run-in-new-session.py script, even though it might not be evident from the way the PR was structured:
Ray Strode <[email protected]>
Is there a reason this isn't tagged for F40?
In order to fully support Wayland, we need to remove libxklavier and drop xrandr and xrdb.
While I think that the xrandr change can be merged in Fedora -as it doesn't affect the live session and the Spins-, the change libxklavier removal would affect the spins.
https://github.com/rhinstaller/anaconda/pull/5463 relies on GNOME Kiosk to configure the keyboard layouts, which won't be available in other environments.
Until we find an API that works across DEs or we implement different backends, this PR can't be merged for Fedora.
@M4rtinK could correct me if I'm wrong. I've been working on Anaconda literally one month part time, he knows way better than me how the different images work.
Yes, the keyboard layout thing is an issue. Most of the compositors support being live reconfigured through locale1, GNOME is the only exception at the moment.
Could we put all the the GNOME Kiosk/Mutter stuff into its own class and make the display.py module a "simple" class like I did in #5401? I would like to be able to rebase #5401 for shipping with CentOS Hyperscale and a few other things, and I expect other distributions using Anaconda (such as ROSA et al) would like to be able to easily plug in alternative compositors (such as KWin or Cage).
While I think that the xrandr change can be merged in Fedora -as it doesn't affect the live session and the Spins-, the change libxklavier removal would affect the spins.
Agreed, I think we can merge the xrandr change into Fedora, but I would like to do that to Rawhide, rather than piling more stuff on Fedora 40 by this point.
#5463 relies on GNOME Kiosk to configure the keyboard layouts, which won't be available in other environments.
Until we find an API that works across DEs or we implement different backends, this PR can't be merged for Fedora.
So with this change, we do cover the boot.iso/netinst images, as those always have GNOME Kiosk, but indeed the problem is with the spins. On the other hand I'm pretty sure we already can't change the keyboard in all the spins that switched to Wayland, but this would potentially also break all the other spins that still have Xorg & libXklavier still works.
I'm not saying we can totally avoid breaking at least some of the spins eventually, but I think this definitely needs to be a process that starts with an announcement & most likely a Fedora Change as well, to make it possible to the various Spin stakeholders to react if they have the capacity to do something about it.
Best options would be if at least the major spins adopted the localed keyboard API - IIRC KDE already does and possibly others ?
Best options would be if at least the major spins adopted the localed keyboard API - IIRC KDE already does and possibly others?
KDE and Sway both do, and they're the current Wayland ones. It's on the roadmap for Budgie as part of their switch to Wayland. And I'm going to try to make sure this is covered as I work through uplifting the other desktops to Wayland too.
KDE and Sway both do, and they're the current Wayland ones. It's on the roadmap for Budgie as part of their switch to Wayland. And I'm going to try to make sure this is covered as I work through uplifting the other desktops to Wayland too.
Sounds good, that indeed looks like it might work out for most of the spins finally. :)
Could we put all the the GNOME Kiosk/Mutter stuff into its own class and make the display.py module a "simple" class like I did in #5401? I would like to be able to rebase #5401 for shipping with CentOS Hyperscale and a few other things, and I expect other distributions using Anaconda (such as ROSA et al) would like to be able to easily plug in alternative compositors (such as KWin or Cage).
For this first version of the Wayland switch I would like to avoid additional changes if possible, so we can have it ready to go to RHEL soon.
But for the eventual upstream Fedora version I think we can certainly do some sensible adjustments, as long as GNOME Kiosk support is kept in place & we have the capacity together to get it done & maintain the result.
Like, it will have to be different anyway if we want to handle keyboard switching on spins.
Thank you, looks good to me, I think we should update / add unit tests for the new API and classes, but we can take care of it as a follow-up ? Or maybe better I can add the tests to this PR.
I will likely have a follow-up PR to reorganize things a little bit to make things easier for me too...
This looks good to me now, further work can be done in subsequent pull requests. I certainly am going to have some work to do after this. 😉
Images built based on commit 03a59ab338ff160ddf4fa4e86497ddcb68337015:
-
boot.iso: success
Download the images from the bottom of the job status page.
Thank you, looks good to me, I think we should update / add unit tests for the new API and classes, but we can take care of it as a follow-up ? Or maybe better I can add the tests to this PR.
The tests are added in this draft PR: https://github.com/rhinstaller/anaconda/pull/5503. The PR runs also pylint tests so it reveals some pylint issues in this PR.
The tests are added in this draft PR: https://github.com/rhinstaller/anaconda/pull/5503. The PR runs also pylint tests so it reveals some pylint issues in this PR.
Thanks @rvykydal, I'm not sure why pylint didn't complain in this PR or in #5463 / #5470, but I fixed each problem in the right PR and cherry-picked everything here, including your unit tests so we don't miss them.
Images built based on commit 44fc0461a1f1c4db83af07fbe24535886e66c511:
-
boot.iso: success
Download the images from the bottom of the job status page.
After an update in systemd, the Wayland session is failing to start because the PAM binaries are not found with the following error:
Starting [email protected] - User Manager for UID 0...
pam_unix(systemd-user:account): helper binary execve failed: No such file or directory
pam_unix(systemd-user:account): helper binary execve failed: No such file or directory
PAM failed: Authentication service cannot retrieve authentication info
[email protected]: Failed to set up PAM session: Operation not permitted
I added a new patch from @M4rtinK ("FIXME: don't drop pam binaries during image build") to solve the issue while we wait for https://github.com/weldr/lorax/pull/1385 to be reviewed and merged.
Images built based on commit 4dc0046817f852d87ae0196a6d2e4a9c3547e186:
-
boot.iso: success
Download the images from the bottom of the job status page.
/kickstart-test --skip-testtypes knownfailure,manual,skip-on-fedora,gh576,gh595,gh640,gh641,gh680,gh740,gh769,gh774,gh777,gh910,gh890,gh871,rhbz1853668,gh975,gh1023
/kickstart-test firewall-use-system-defaults,mountpoint-assignment-1,initial-setup-enable