How I found out about the problem: in a nearly-mageia-4-cauldron KDE installed from LiveDVD, apper is installed by default. A notification came saying "there are updates, do you want to install them", or the like. I chose to try to install them, so it opened apper, but then it hangs forever with a loading animation. Starting apper from the menu does not work either: any action in it hangs. *Restarting packagekit makes it work* but after a few seconds or a few actions, any action I make hangs (list installed packages, show updates...). I first thought it might be due to mgaapplet locking the rpm database, but even after stopping mgaapplet and restarting packagekit again, the behaviour is the same: works for a few seconds then stops working. Reproducible: Steps to Reproduce:
Release blocker since apper is installed by default and isn't ready from primetime, although my bug report is probably too late in the release cycle.
Priority: Normal => release_blockerCC: (none) => mageia, mageia, pterjan, thierry.vignaudBlocks: (none) => 11704
The main problem is that KDE tries to make us use apper for installing updates, which kind of conflicts with mgaapplet, and it doesn't work (at least here, almost fresh install). Disabling KDE's builtin update feature via a configuration change would be enough for the bug to not get in user's way. It can be done via an update, but won't KDE try to make us use apper for that update?
As could be expected, problem is in packagekit (or in our urpmi back-end for packagekit). pkgcon get-updates works just after a packagekit restart. Then hangs in subsequent tries. Reproduced by neoclust.
Source RPM: apper-0.8.1-3.mga4.src.rpm => packagekit-0.8.14-3.mga4.src.rpm
Illustration: [samuel@localhost bin]$ su -c 'systemctl restart packagekit' Mot de passe : [samuel@localhost bin]$ LC_ALL=C pkcon get-updates Getting updates [=========================] Waiting in queue [=========================] Starting [=========================] Resolving dependencies [=========================] Normal lib64purple0-2.10.8-1.mga4.x86_64 The libpurple library for IM clients like Pidgin and Finch Normal mageia-gfxboot-theme-4.4.5.16-1.mga4.x86_64 Mageia graphical boot theme Normal meta-task-4-27.mga4.noarch Meta task listing packages by group Normal pidgin-plugins-2.10.8-1.mga4.x86_64 Pidgin plugins shared by the Purple and Finch [samuel@localhost bin]$ LC_ALL=C pkcon get-updates Getting updates [=========================] Waiting in queue [=========================] Starting [ == ] Then after killing it: [samuel@localhost bin]$ su -c 'systemctl restart packagekit' Mot de passe : [samuel@localhost bin]$ LC_ALL=C pkcon get-updates Getting updates [=========================] Waiting in queue [=========================] Starting [=========================] Resolving dependencies [=========================] Normal lib64purple0-2.10.8-1.mga4.x86_64 The libpurple library for IM clients like Pidgin and Finch Normal mageia-gfxboot-theme-4.4.5.16-1.mga4.x86_64 Mageia graphical boot theme Normal meta-task-4-27.mga4.noarch Meta task listing packages by group Normal pidgin-plugins-2.10.8-1.mga4.x86_64 Pidgin plugins shared by the Purple and Finch [samuel@localhost bin]$ LC_ALL=C pkcon get-updates Getting updates [=========================] Waiting in queue [=========================] Starting [ == ] The same over again.
Summary: apper is unusable: works for a few seconds then hangs at every action => apper is unusable: works for a few seconds then hangs at every action (packagekit issue)
isn't supposed that apper and the gnome-equivalent are disabled ?
CC: (none) => ennael1, tmb
(In reply to Manuel Hiebel from comment #5) > isn't supposed that apper and the gnome-equivalent are disabled ? apperd isn't, unfortunately (well, there's actually an option that says never check for updates... But it still does if started apparently. Changing apperd.desktop to set autostart to false seems to fix it)
That should be fixed before we release ihmo, Nicolas ?
Probably too late..
CC: (none) => mageia
maybe we can an update with the autostart to false ?
CC: (none) => balcaen.john, lmenutSource RPM: packagekit-0.8.14-3.mga4.src.rpm => packagekit-0.8.14-3.mga4.src.rpm, apper
Yeah, it definitely needs an update. And I would go as far as removing it from the distribution. There's no point to keep it if integration with packagekit doesn't work anyway. It can only cause unwanted trouble at unwanted times.. Now sadly shows up in reviews too :/
so remove gnome-packagekit too. Better is to fix packagekit for our backend, what we started to do. @Manuel: I will issue an update as soon as possible
fixed and pushed in testing of mga4.
Thanks Nicolas, if ready, please assign to QA with an advisory and SRPM et RPM list.
Assigning to QA for Nicolas, who will in exchange help testing updates :) ===== Advisory ====== This update to apper disables apperd, which displays notifications when new updates are available, in KDE, for two reasons: 1) users get the notifications twice, once from the KDE-specific apperd, and once from the Mageia-specific mgaapplet 2) the packagekit backend for urpmi in Mageia 4 is broken. The notification invites users to update through apper, but apper can't install the updates because of that broken backend. This should be fixed in a future packagekit update. ===== RPMs ===== Updated packages in core/updates_testing apper-0.8.1-3.1.mga4.i586.rpm apper-0.8.1-3.1.mga4.x86_64.rpm from apper-0.8.1-3.1.mga4 ===== Testing procedure ===== In Mageia 4 KDE, usually right after boot, notice that you get an update notification that does not come from the usual Mageia applet. Inside the notification there is a button (localized so I don't know the label in english) that opens apper, KDE's packagekit frontend. Apper seems to be loading the list of updates but nothing happens. After installing the update candidate, reboot. You should not get update notifications from apperd, only those from mgaapplet. This update does not fix packagekit, so it does not fix apper either: only one action can be performed and then it hangs... Until some timeout occurs in packagekit.
Version: Cauldron => 4Assignee: bugsquad => qa-bugs
Whiteboard: (none) => has_procedure
Testing complete i586.
Whiteboard: has_procedure => has_procedure MGA4-32-OK
Testing complete x86_64 following the procedure in comment 14. -- Validating update. Could someone upload the advisory and a sysadmin push the update to 4 core/updates? Thanks!
Keywords: (none) => validated_updateWhiteboard: has_procedure MGA4-32-OK => has_procedure MGA4-32-OK MGA4-64-OKCC: (none) => remi, sysadmin-bugs
Advisory uploaded, ready to push.
Whiteboard: has_procedure MGA4-32-OK MGA4-64-OK => has_procedure MGA4-32-OK MGA4-64-OK advisory
Update pushed: http://advisories.mageia.org/MGAA-2014-0017.html
Status: NEW => RESOLVEDResolution: (none) => FIXED