So the openQA failures here are interesting. It seems like often, but not every time, we hit a failure on the old (gtkui) installer test.
The tests boot the installer and click through the initial screens to the hub. Then they switch to a console and run some commands to check the installation source is as expected. Then they switch back to the installer UI and click Install Destination.
This is where we get the failure: when the test clicks Install Destination, nothing happens.
This is the first time the test actually clicks anything in the hub, so it may just be that clicking in the hub doesn't work.
Again, this doesn't happen on every gtkui install test, but happens quite often. Each time this update or the f46 update has been re-tested (because it was edited), it's failed at least once.
GNOME SIG does not routinely update gnome-disk-utility anymore because it has commit-only access to the package. We only proactively update packages where we have admin access. We have a spreadsheet documenting this here where gnome-disk-utility update responsibility is set to "Package owner."
Upon updating, after gdm's switch to pam-oo7, a subsequent dnf autoremove offers to remove gnome-keyring-pam as unnecessary. But when I removed it, restarting hangs or takes a very long time, and the system demands extra authentication steps to unlock the keyring when logging in.
This update's test gating status has been changed to 'waiting'.
In addition to @cmorris' issue, I just updated my silverblue from 45.20260828.0 to 45.20260911.0 and on reboot, when i logged in, i got the 'keyring was not unlocked at login' prompt and had to enter my password again to unlock it.
It'll be good to fill a bug against the oo7, though there is an indication that a newer version of it should have some fixes, thus maybe wait for the next oo7 release. The 0.6.0 is from 7 months ago.
This update's test gating status has been changed to 'waiting'.
This update has obsoleted gnome-initial-setup-51~beta-2.fc45, and has inherited its bugs and notes.
This update's test gating status has been changed to 'waiting'.
This update has been submitted for testing by bodhi.
This update's test gating status has been changed to 'failed'.
mcrha edited this update.
New build(s):
Karma has been reset.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'failed'.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'failed'.
This update's test gating status has been changed to 'waiting'.
ngompa edited this update.
New build(s):
Removed build(s):
Karma has been reset.
This update's test gating status has been changed to 'failed'.
So the openQA failures here are interesting. It seems like often, but not every time, we hit a failure on the old (gtkui) installer test.
The tests boot the installer and click through the initial screens to the hub. Then they switch to a console and run some commands to check the installation source is as expected. Then they switch back to the installer UI and click Install Destination.
This is where we get the failure: when the test clicks Install Destination, nothing happens.
This is the first time the test actually clicks anything in the hub, so it may just be that clicking in the hub doesn't work.
Again, this doesn't happen on every gtkui install test, but happens quite often. Each time this update or the f46 update has been re-tested (because it was edited), it's failed at least once.
This update has been pushed to testing.
Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe.
no regressions noted
Bisected and reported as https://gitlab.gnome.org/GNOME/mutter/-/work_items/5033 . We could put a build with the commit reverted in the update, I guess, but it might be good to figure out a correct fix instead?
Any reason to omit gnome-disk-utility, which was finally ported to gtk4 during this cycle?
That's a question for @amigadave , why the 51.beta is not in rawhide. There was no 51.rc release of it yet.
GNOME SIG does not routinely update gnome-disk-utility anymore because it has commit-only access to the package. We only proactively update packages where we have admin access. We have a spreadsheet documenting this here where gnome-disk-utility update responsibility is set to "Package owner."
adamwill edited this update.
adamwill edited this update.
New build(s):
Removed build(s):
Karma has been reset.
This update has been submitted for testing by adamwill.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'passed'.
This update has been pushed to testing.
Works
Can confirm this fixes the user switching bug.
This update can be pushed to stable now if the maintainer wishes
Upon updating, after gdm's switch to pam-oo7, a subsequent dnf autoremove offers to remove gnome-keyring-pam as unnecessary. But when I removed it, restarting hangs or takes a very long time, and the system demands extra authentication steps to unlock the keyring when logging in.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'failed'.
This update's test gating status has been changed to 'passed'.
This update has been submitted for stable by adamwill.
This update has been pushed to stable.
In addition to @cmorris' issue, I just updated my silverblue from 45.20260828.0 to 45.20260911.0 and on reboot, when i logged in, i got the 'keyring was not unlocked at login' prompt and had to enter my password again to unlock it.
It'll be good to fill a bug against the oo7, though there is an indication that a newer version of it should have some fixes, thus maybe wait for the next oo7 release. The 0.6.0 is from 7 months ago.