Mageia 9 installed on two HW with GNOME DE. In both I don't have notifications updates. The applet doesn't work. With MGA8. I could see the applet furtively, but it was there. Even gnome software doesn't prompt me for updates.
look if you don't have a urpmi.update process that not finish ps aux|grep urpmi.update If you get different output that user 185199 0.0 0.1 12560 2432 pts/2 S+ 12:27 0:00 grep --color urpmi.update Then killall -9 urpmi.update Remove the repositories with drakrpm-editmedia if you have a repository not from mageia or with urpmi.removemedia -a If only have the mageia repositories And add again the repositories This happens to me yesterday, i don't know why, but this method fixes the issue
CC: (none) => j.alberto.vc
As this happen for several users, i think it should enter errata when we know more. In case someone needs it: https://wiki.mageia.org/en/Install_media_in_Mageia_for_beginners
CC: (none) => friKeywords: (none) => FOR_ERRATA9
Done https://wiki.mageia.org/en/Mageia_9_Errata#Mageia_tools
Keywords: FOR_ERRATA9 => IN_ERRATA9Summary: No GNOME update notification => No updates offered by mgaapplet
Check that you have the GNOME shell AppIndicator extension installed and enabled. To install (as root) urpmi gnome-shell-extension-appindicator To enable (as a normal user) gnome-extensions enable appindicatorsupport@rgcjonas.gmail.com or use the GNOME Extensions GUI tool.
Just a note that in my experience mgaapplet works okay in Mageia 9 when the desk top environment is KDE Plasma.
CC: (none) => rihoward1
(In reply to r howard from comment #5) > Just a note that in my experience mgaapplet works okay in Mageia 9 when the > desk top environment is KDE Plasma. Plasma user here, yesterday the icon rise searching for updates and hide like no one was found (now I think it crash), the iwas for test packages dowloading with qarepo and the application did say that the repository couldn't be enabled/disabled. Running qarepo from console, a urpmi.update process was locking the db, but just not ends. Kill all urpmi.update process and try to update repositories manually with urpmi.update -a and get stuck on Tainted 32bit (if I remember well), try to just urppmi --clean and not works, so I remove and add again the repositories and even if they were added right, I again urpmi.update -a and until now the issue is not reproduced.
The errata shouldn't be cluttered with fast conclusions without proper facts. Katnatek, please be aware that you are talking about a completely different failure picture as Guillaume. Additionally what you put into the errata is completely incomprehensible for normal users...
A way better entry for errata would be: No updates offered by mgaapplet. The root cause is under investigation. As intermediated solution it is recommended to check for updates via terminal: #urpmi --auto-update
I have cleaned the entry in Errata. However, I see that there a § saying "Remedies" following, but this is not clear to what problem the remedies apply.
CC: (none) => yvesbrungard
Note that I tested the instructions in comment 4 using the GNOME Live ISO. With the AppIndicator extension enabled, the mgaapplet notification appears in the top bar. The AppIndicator extension is pre-enabled in the GNOME Live ISO, so people who use that (or install from that) should not see this issue unless they add new users.
CC: (none) => mageia
(In reply to papoteur from comment #9) > I have cleaned the entry in Errata. > However, I see that there a § saying "Remedies" following, but this is not > clear to what problem the remedies apply. This is a leftover from Morgano. The chapter where it belonged to „If upgrade fails“ got removed and this part got forgotten…
I did a test installation with Mageia-9-x86_64.iso and the Gnome pattern. No online media enabled whilst installation but added online media after the system started the first time to have some updates in the pipeline. The update icon is not visible and only for 2 seconds a notification popped up at the top "Updates available". Checked extension settings and found that "gnome-shell-extension-appindicator" is disabled by default. After enabling the extension and a reboot, the icon for updates popped up after 5 minutes at the top bar. So the root cause is: The "gnome-shell-extension-appindicator" is disabled by default on a 64bit Gnome installation. Solution: Enable the extension by default. Summary: mgaapplet or the indicator is not broken but disabled by default for classic media.
in the qa thread that produce the report https://ml.mageia.org/l/arc/qa-discuss/2023-10/msg00005.html, is reported that plasma users are also affected. So what we have?, 3 similar issues: gnome, plasma and my comment#6 or one with different causes?
The problem is that this report and the ML thread miss ALL informations to reproduce the issue! Martin tested according comment 10 with a GNOME live ISO where it works out of the box. I tested according comment 12 with the classic 64 bit media and GNOME pattern, where it doesn't work out of the box but after enabling the applet. - which medias where used from the reporters? - online media enabled whilst installation or only afterwards? - are online medias enabled at all? - architecture? - wayland or X11? - is it an upgrade from MGA8 or a clean MGA9 installation? - ... And please don't mix this topic with test boxes which have QA-repo or other QA/testing stuff enabled. This issue needs to be reproducible on a normal user box. Anything else doesn't belong into Errata as it would be special to testing/QA setups. As long as there are no reproducible steps this seems like clairvoyance....
(In reply to sturmvogel from comment #14) use qarepo was just a coincidence, the part of urpmi.update process not is related btw if let this as gnome only bug then the errata need to be changed of place
Did another fresh MGA9 64 bit Plasma installation from Mageia-9-x86_64.iso - no online media enabled whilst installation (to have some updates available for testing) - adding online medias after first start of the machine - reboot - after 5 minutes the mgaaplet notifier pops up and informs about updates That means, with the amount of provided informations the issue is not reproducible (yet): comment 5 : Plasma works comment 16: Plasma (Classic installation) works comment 10: Gnome (Live installation) works comment 12: Gnome (Classic installation) only works after enabling the extension So it seems there are several pieces of information missing to reproduce the issue...
Digging a little bit further. On a fresh standard 64 bit Plasma installation (classic installer, no software adjustments, online media disabled whilst installation) there are 99 packages for update available as of 02.10.2023 17:07 CEST after adding online media. BUT 90% of these packages got already added end of August or beginning of Septemper. Only in the last few days a handfull of updates (~15) got added by David and Dan. That means if you installed MGA9 directly after release with online medias enabled, you had really for 2 or 3 weeks no updates as there weren't any available at all. This is backed by one of my machines. I upgraded it online directly after release of MGA9. Yesterday i updated this machine and only ~15 packages got pulled on a machine that wasn't online for nearly a month! To verify a misbehaviour of mgaaplet, the reporter (and the guys and gals in the french forum) should issue a "urpmi --auto-update" and verify if there are updates available at all. If there are no updates available in commandline, the mgaapplet is working properly...
(In reply to sturmvogel from comment #11) > (In reply to papoteur from comment #9) > > I have cleaned the entry in Errata. > > However, I see that there a § saying "Remedies" following, but this is not > > clear to what problem the remedies apply. > > This is a leftover from Morgano. The chapter where it belonged to „If > upgrade fails“ got removed and this part got forgotten… Oops I will fix that...
See bug 23795 for background on why the GNOME extension isn't enabled by default on clean installs (noting that the AppIndicator extension is a replacement for the TopIconsPlus extension).
(In reply to Morgan Leijström from comment #18) > (In reply to sturmvogel from comment #11) > > (In reply to papoteur from comment #9) > > > I have cleaned the entry in Errata. > > > However, I see that there a § saying "Remedies" following, but this is not > > > clear to what problem the remedies apply. > > > > This is a leftover from Morgano. The chapter where it belonged to „If > > upgrade fails“ got removed and this part got forgotten… > > Oops I will fix that... I fix it by removing the hidden procedure
(In reply to Martin Whitaker from comment #19) > See bug 23795 for background on why the GNOME extension isn't enabled by > default on clean installs (noting that the AppIndicator extension is a > replacement for the TopIconsPlus extension). I guess no package requires gnome-shell-extension-appindicator: LC_ALL=C urpmq --whatrequires gnome-shell-extension-appindicator gnome-shell-extension-appindicator LC_ALL=C urpmq --whatrequires rpm-build alien alien bm bm checkinstall checkinstall cpan2pkg cpan2pkg easyrpmbuilder easyrpmbuilder erlang-rpm-macros erlang-rpm-macros gambas3-ide gambas3-ide mgarepo mgarepo openscap-utils openscap-utils project-builder project-builder rpm-build rpm-mageia-setup-build rpm-mageia-setup-build rpmdevtools rpmdevtools rpmrebuild rpmrebuild spec-tree spec-tree supermin-devel supermin-devel task-packager task-packager tito tito
I've just taken the time to read this long list of comments. My apologies if I wasn't precise enough in my descriptions but I thought that if I wasn't exhaustive enough you would have asked me to be more specific. I also confused it with my email on the QA list. The French user did indeed have a problem, but it was different. Papoteur has opened a report on the subject n°32354. As for my problem, it exists on 2 Gnome PCs, one a new installation classic iso 64 and the other an update from MGA8 to MGA9 (from MGA7 live GNOME). Both installations date back to the release and there have been a few updates since which I have obviously checked with urpmi --auto-update. I checked that the extension was enabled and configured. I'll keep an eye out for future updates.
(In reply to katnatek from comment #20) > (In reply to Morgan Leijström from comment #18) > > (In reply to sturmvogel from comment #11) > > > (In reply to papoteur from comment #9) > > > > I have cleaned the entry in Errata. > > > > However, I see that there a § saying "Remedies" following, but this is not > > > > clear to what problem the remedies apply. > > > > > > This is a leftover from Morgano. The chapter where it belonged to „If > > > upgrade fails“ got removed and this part got forgotten… > > > > Oops I will fix that... > > I fix it by removing the hidden procedure I reinstated hidden procedure, with correct end tag syntax ;) :)
(In reply to Guillaume Royer from comment #22) Thanks for the clarification. That makes sense now. - Plasma is not affected (this was another bug that was confused with another problem) - on fresh Gnome classic installation the extension needs to be enabled by the user (disabled by default) - on your old upgraded live installation (7->8->9), the extension is also disabled by default as Mageia's policy doesn't allow changes in the /home directory whilst upgrades. So you also need to enable the extension by yourself. As you have now the extension enabled on both machines, you/we need to wait until some updates get validated by QA and sync to the mirrors...
(In reply to sturmvogel from comment #24) > you/we need to wait > until some updates get validated by QA and sync to the mirrors... You can urpmi --downgrade some updated package to a release version, to see if it then picks up an update.
(In reply to katnatek from comment #21) > I guess no package requires gnome-shell-extension-appindicator: No. It is listed in rpmsrate which causes it to be automatically selected by the installer and is also recommended by task-gnome-minimal which causes it to be selected if you add GNOME to an existing install.
New errata: https://wiki.mageia.org/en/Mageia_9_Errata#Update_notifications
Together with the MLO community, we have made progress on this issue. It turns out that my problem is the same as the Plasma user's, he actually had GNOME as his second DE. When he did again install without GNOME, he no longer had the applet problem. My problem is the same as this one: 32350 It turns out that on my GNOME PCs: $PATH bash: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/usr/local/games:/usr/games:/usr/lib64/qt5/bin:/usr/lib64/qt6/bin:/home/guillaume/.local/bin:/home/guillaume/bin: No such file or folder Normally /usr/bin should be in front of /usr/sbin. On my GNOME PCs it's the other way round and that was the case for the Plasma/GNOME user. We fixed the problem by adding the following to the end of my ~/.bashrc file: export PATH="/usr/bin:$PATH"
(In reply to Guillaume Royer from comment #28) > Together with the MLO community, we have made progress on this issue. It > turns out that my problem is the same as the Plasma user's, he actually had > GNOME as his second DE. When he did again install without GNOME, he no > longer had the applet problem. > My problem is the same as this one: 32350 > It turns out that on my GNOME PCs: > $PATH > bash: > /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/usr/local/games:/usr/ > games:/usr/lib64/qt5/bin:/usr/lib64/qt6/bin:/home/guillaume/.local/bin:/home/ > guillaume/bin: No such file or folder > Normally /usr/bin should be in front of /usr/sbin. On my GNOME PCs it's the > other way round and that was the case for the Plasma/GNOME user. > > We fixed the problem by adding the following to the end of my ~/.bashrc > file: > export PATH="/usr/bin:$PATH" That sound to me like bug#32354
(In reply to katnatek from comment #29) > (In reply to Guillaume Royer from comment #28) > > Together with the MLO community, we have made progress on this issue. It > > turns out that my problem is the same as the Plasma user's, he actually had > > GNOME as his second DE. When he did again install without GNOME, he no > > longer had the applet problem. > > My problem is the same as this one: 32350 > > It turns out that on my GNOME PCs: > > $PATH > > bash: > > /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/usr/local/games:/usr/ > > games:/usr/lib64/qt5/bin:/usr/lib64/qt6/bin:/home/guillaume/.local/bin:/home/ > > guillaume/bin: No such file or folder > > Normally /usr/bin should be in front of /usr/sbin. On my GNOME PCs it's the > > other way round and that was the case for the Plasma/GNOME user. > > > > We fixed the problem by adding the following to the end of my ~/.bashrc > > file: > > export PATH="/usr/bin:$PATH" > > That sound to me like bug#32354 Yes, I made mistake, I wanted to write 32354 and not 32350... It's same bug but I don't know why it'happen with GNOME DE and not others...
It looks like agreement that this bug is a consequence of bug 32354, a duplicate: "It's same bug": /usr/bin/urpmi.update is a wrapper script provided by urpmi. /usr/sbin/urpmi.update is a symlink provided by mgaonline to /usr/libexec/urpmi.update The latter doesn't work if launched as user. So just 'urpmi.update' uses the first one found in PATH, which should have /usr/bin before /usr/sbin so that /usr/bin/urpmi.update is launched (and mgaapplet runs correctly, updates are notified). That is the normal case. If the two /bin directories are reversed (that other bug), /usr/sbin/urpmi.update gets run, which does not work correctly for users so mgapplet does not run correctly and updates do not get noticed. Closing as such, re-open for a different diagnosis if necessary. *** This bug has been marked as a duplicate of bug 32354 ***
Status: NEW => RESOLVEDResolution: (none) => DUPLICATE