Description of problem: after installation from: ISO: Mageia-9-alpha1-Live-GNOME-x86_64.iso DATE: Sun Nov 6 07:26:05 PM CET 2022 using Mageia Welcome app, both the *add on-line repos* and *update system* links appear to cause many popups: *"Mageia Welcome" is not responding* wait or cancel. Version-Release number of selected component (if applicable): How reproducible:often Steps to Reproduce: 1.install from above ISO 2.use Mageia welcome to initiate adding online repos and updating system 3.
Thank you for the report. Are you the only person to report it (be testing the Gnome Live ISO)? Do you know whether the same problem occurs with other Live ISOs, or just the Gnome one? Cruel question: does it happen with a Gnome-only install from the Classic ISO? All this is to try and pin down whether it is inherent in MageiaWelcome, or something to do with Gnome's strange desktop. The problem is so easy to try, other people will be able to comment on it. I shall try it with Gnome on this Cauldron box (ex upgraded multi-desktop M8 Classic install).
CC: (none) => lewyssmithSummary: multiple popups: *"Mageia Welcome" is not responding* => "Mageia Welcome is not responding, wait or cancel" on Gnome Live ISO when 'add on-line repos' and 'update system', multiple popups:Source RPM: (none) => mageiawelcome-2.16-3.mga9.src.rpm
Here under Gnome, not much joy. I could not see 'add on-line media', just 'Media sources'; possibly because they were already enabled. But doing that, 'Configure software sources' popped the usual media sources dialogue OK. As for 'update system', that worked fine, no problems. Sigh.
> Thank you for the report. > Are you the only person to report it (be testing the Gnome Live ISO)? I do not know ;( > Do you know whether the same problem occurs with other Live ISOs, or just > the Gnome one? only Gnome > Cruel question: does it happen with a Gnome-only install from the Classic > ISO? will check onto a 2 system machine. > during the live install (onto 11 system machine) multiple instances of "*draklive-install" is not responding* wait or cancel" ( ~104 times) and at least one *gurpmi is not responding* while installing bootloader. caught your addition while adding mine: was working from memory (on work windows machine) , you are correct : media sources
install of 64 CI alpha1: Gnome issue is apparent immediately after I attempt via Mageia Welcome *edit software sources*: configure media => *file* => *add a specific media mirror* and the *Mirror Choice* popup is displayed. > Cruel question: does it happen with a Gnome-only install from the Classic ISO? apparenty yes
This is caused by a change in the GNOME window manager (mutter). It now regularly pings GUI applications to check they are still alive and responding to input. The Mageia tools sleep whilst waiting for a sub-program to run, so don't respond to the pings. Note that this happens when running the various Mageia tools directly as well as via MageiaWelcome. A workaround is to disable the check by gsettings set org.gnome.mutter check-alive-timeout 0 but that disables the ability to forcibly terminate applications which are genuinely not responding.
Source RPM: mageiawelcome-2.16-3.mga9.src.rpm => (none)CC: (none) => mageia
Can the default timeout be set to 10 minutes to match that the Mageia tools currently use?
CC: (none) => davidwhodgins
Thank you Martin once again for an erudite explanation. And Dave for his suggestion. And Ben for the tedious testing. Why did this not show in my Cauldron system ex upgraded M8? I have: mutter-43.1-2.mga9 Is it just a question of chance that mutter's ping normally gets answered? (In reply to Martin Whitaker from comment #5) > A workaround is to disable the check by > gsettings set org.gnome.mutter check-alive-timeout 0 > but that disables the ability to forcibly terminate applications which are > genuinely not responding. Does this include terminating them via a task manager application (which is what users often do to kill unresponding applications)? Or using Alt/F4 ? Or via ps + kill from a terminal? If not, disabling the pinging looks sensible, a normal situation. We certainly have to do something about it, setting the mutter timeout value to 0 or at least 10 secs; indeed, does it matter if it is longer for an unresponsive application? Assigning directly to Gnome packagers, but please go on adding comments which advance the affair.
Assignee: bugsquad => gnome
(In reply to Lewis Smith from comment #7) > Why did this not show in my Cauldron system ex upgraded M8? I have: > mutter-43.1-2.mga9 > Is it just a question of chance that mutter's ping normally gets answered? I could easily reproduce it using MageiaWelcome to run one of the Mageia tools - start the tool, then do nothing for the requisite length of time. The default timeout is 5 seconds, but maybe on your upgraded system it's set to something different. Check by gsettings get org.gnome.mutter check-alive-timeout The value returned is in milliseconds. > (In reply to Martin Whitaker from comment #5) > > A workaround is to disable the check by > > gsettings set org.gnome.mutter check-alive-timeout 0 > > but that disables the ability to forcibly terminate applications which are > > genuinely not responding. > Does this include terminating them via a task manager application (which is > what users often do to kill unresponding applications)? > Or using Alt/F4 ? > Or via ps + kill from a terminal? > If not, disabling the pinging looks sensible, a normal situation. I don't know of a task manager application in GNOME. The usual way to terminate non-responding applications is to click on the window close button and wait for the timeout, and setting the timeout to 0 disables that. And Dave's suggestion of setting the timeout to 10 minutes makes it unusable too. Alt-F4 only works when the application is not stalled, whatever the timeout is set to. kill will work regardless. > Assigning directly to Gnome packagers, but please go on adding comments > which advance the affair. Unfortunately GNOME is working as intended here. The GNOME developers think a GUI application that becomes unresponsive for more than 5 seconds is a broken application. I largely agree with them. You would expect to be able to resize or minimise a window even when the application is busy doing something.
Priority: Normal => release_blocker
mageiawelcome-2.18-1.mga9 fixes the warnings about mageiawelcome not responding. And I have made some improvements to draklive-install which mostly fixes the warnings about that. I think we'll still see occasional warnings about gurpmi2 and rpmdrake when installing large packages.
First, thanks for your work to improve the situation. > I think we'll still see occasional warnings about gurpmi2 and rpmdrake > when installing large packages Noting for ERRATA with this in mind. Can I be clear about: - this is for Gnome desktop use, however installed ? - applies just to MageiaWelcome, or + other known applications? - click 'Wait' to continue.
Keywords: (none) => FOR_ERRATA9
(In reply to Lewis Smith from comment #10) > Noting for ERRATA with this in mind. Can I be clear about: > - this is for Gnome desktop use, however installed ? Yes. > - applies just to MageiaWelcome, or + other known applications? Should no longer apply to MageiaWelcome itself, as it now starts subsidiary applications without blocking until they complete. Will probably apply to drakrpm, drakdisk, drakboot, and maybe more. > - click 'Wait' to continue. Best not to click 'Wait', as the pop-up will be displayed again after another 5 seconds (or whatever the timeout is set to). If you just leave it, the pop-up will be automatically removed when the application starts responding again.
as of 30/12/2022 beta1 .iso this is fixed
Status: NEW => RESOLVEDResolution: (none) => FIXED
Keywords: FOR_ERRATA9 => (none)CC: (none) => fri
If the piece of writing is fiction, discuss https://2048-game.co/ the characters and how well-developed they were. Talk about how you felt emotionally invested in their journey.
CC: (none) => Zeldafarah10