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 f45 update has been re-tested (because it was edited), it's failed at least once.
Is there anything I can help with? I've a zero experience with these tests, thus it's harder to understand what should be done.
My initial impression was that the click just focused the window, that the second click could press the button, but if the log says it's doing something, but does not show that in the GUI, then it's fishy.
Could that be lower in the stack, or you suspect mutter/gnome-shell?
localsearch update clashes with my FFmpeg 9 update . Do you have an ETA when this is going stable? I'd like to avoid tagging this into my already big update.
@mcrha I suspect most likely mutter. Since I can't reproduce it manually it's tricky :/ I can have the test try clicking more than once to see if that helps. Beyond that, if you can maybe guess at some change between beta and RC that might have caused this, I can test reverting it; otherwise I may just have to bisect+cannon it, which I can do, it just takes a while (I have to do scratch builds for every step of the bisect, and run the scratch builds through 20 or so tests each to be sure whether they're good or bad, it'll probably take me the rest of today).
I've been away from computer on Friday, back just now. I see there was an attempt made upstream to fix it, but you wrote there it did not help. I can do a build with that commit reverted for now, to have the GNOME 51.rc part of the Beta. The 51.0 release is planned for this weekend, thus being out the next week the latest. It clashes with this 51.rc release.
I'm doing builds for f45 and f46 with the upstream fix backported, as it looks good in testing. I'll regen the updates when they're done. This one will go stable immediately if it passes tests.
Thanks for all the paper work, and I'm sorry for the mess with the gnome-software 51.0, it went out earlier and I forgot the 51.rc is part of this update (not talking I did not realize it will make trouble for this update, even it was obvious). You are correct about the rebuild, it's not needed.
This update's test gating status has been changed to 'waiting'.
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 f45 update has been re-tested (because it was edited), it's failed at least once.
Hmm, interestingly, in the journal I see:
but we never see that on screen. We never see the storage spoke actually rendered.
Is there anything I can help with? I've a zero experience with these tests, thus it's harder to understand what should be done.
My initial impression was that the click just focused the window, that the second click could press the button, but if the log says it's doing something, but does not show that in the GUI, then it's fishy.
Could that be lower in the stack, or you suspect mutter/gnome-shell?
localsearchupdate clashes with my FFmpeg 9 update . Do you have an ETA when this is going stable? I'd like to avoid tagging this into my already big update.No idea when this gets stable, due to the found issues. I can rebuild
localsearchonce your changes are in, if it'll make things easier for you.@mcrha I suspect most likely mutter. Since I can't reproduce it manually it's tricky :/ I can have the test try clicking more than once to see if that helps. Beyond that, if you can maybe guess at some change between beta and RC that might have caused this, I can test reverting it; otherwise I may just have to bisect+cannon it, which I can do, it just takes a while (I have to do scratch builds for every step of the bisect, and run the scratch builds through 20 or so tests each to be sure whether they're good or bad, it'll probably take me the rest of today).
@mcrha @mcatanzaro preliminary bisect result fingers https://gitlab.gnome.org/GNOME/mutter/-/commit/3f17e687f3c2d410cb03a7a28faa243cabe7deb6 . I'll confirm this shortly.
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?
I've been away from computer on Friday, back just now. I see there was an attempt made upstream to fix it, but you wrote there it did not help. I can do a build with that commit reverted for now, to have the GNOME 51.rc part of the Beta. The 51.0 release is planned for this weekend, thus being out the next week the latest. It clashes with this 51.rc release.
I'm doing builds for f45 and f46 with the upstream fix backported, as it looks good in testing. I'll regen the updates when they're done. This one will go stable immediately if it passes tests.
adamwill edited this update.
New build(s):
Removed 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'.
needs a new localsearch build as the ffmpeg update went stable.
adamwill edited this update.
New build(s):
Removed build(s):
Karma has been reset.
This update's test gating status has been changed to 'waiting'.
adamwill edited this update.
Removed build(s):
Karma has been reset.
gnome-software 46.0 was built separately so I took it out of this update. I don't think it has to be built against anything in this specifically.
This update's test gating status has been changed to 'passed'.
This update has been submitted for stable by bodhi
Thanks for all the paper work, and I'm sorry for the mess with the gnome-software 51.0, it went out earlier and I forgot the 51.rc is part of this update (not talking I did not realize it will make trouble for this update, even it was obvious). You are correct about the rebuild, it's not needed.