When the Muon Update Manager is started it automatically checks for updates and, if any are found, lists them. At this point pressing Install Updates results in the updated packages being downloaded and then installed. As expected. However, if Check for Updates is selected from the More... menu and updates are found, pressing Install Updates does not result in the updated packages being downloaded and installed, though the tool reports success. Instead the list of packages that need updating is redisplayed. Futher attempts to Install Updates repeat the failure-as-success pattern. After the Muon Update Manager is Quit and restarted the list of packages that need updating is displayed. At this point - without doing a Check for Updates - pressing Install Updates works correctly. Reproducible: Always Steps to Reproduce: 1. Start Muon Update Manager. 2. Select Check for Updates from the More... menu. 3. After the check completes and there is a list of packages needing update, press Install Updates. Actual Results: The tool reports success, but no "software on this computer is up to date" screen. No packages were downloaded and installed and the list of packages needing update is redisplayed as before Install Updates was pressed. Expected Results: The packages needing update should be downloaded and installed, and the "software on this computer is up to date" screen is displayed. After doing Check for Updates, if a list of packages needing update is displayed, restart the Muon Update Manager and do not Check for Updates before doing Install Updates. This is a workaround.
Confirmed on 2.1.2.
On refresh ApplicationUpdates::prepare is called more than once. prepare in turn calls m_aptBackend->markPackagesForDistUpgrade() which changes the package states. Apparently calling this more than once will break the states and therfore result in an update that will not actually change any packages because no package has correctly formed state flags to match the upgrade criteria. Preventing prepare to be called more than once (inbetween ApplicationBackend::reload calls) or at least preventing it from doing it on any subsequent call should resolve this issue. From IRC <apachelogger> it's inside muon <apachelogger> void ApplicationUpdates::prepare <apachelogger> on refresh this function is called more than once <apachelogger> so it basically tells qapt::backend to mark a cache that was already marked for upgrades <apachelogger> the quick fix would be to track prepare calls <apachelogger> e.g. m_marked=false; in parpare: if(m_marked) return; m_marked=true; in transactionFinished: m_marked=false <apachelogger> that is assuming transactionFinished is really the only way you can get reload() called <apachelogger> the more appropriate solution would probably be to not call prepare more than once though ;) <apachelogger> apol_: on a somewhat related matter, I noticed that the errorOccurred handler does not call reload() which IIRC can cause problems if the backend has pending transactions
*** Bug 328986 has been marked as a duplicate of this bug. ***
Git commit b966840d9e1addc6c72cf45ab22f1ca088b29a73 by Aleix Pol. Committed on 30/01/2014 at 03:21. Pushed by apol into branch '2.1'. Change how we manage to get the clean cache At the moment we were taking advantage of a bug (or anomaly) in QApt where packages market as ToKeep are not being listed as marked, so this would provide us proper UI feedback but then when intending to work it wasn't working properly. This patch instead considers a clean cache the one received on ::prepare() instead. I was able to reproduce the bug, now I can't reproduce anymore. M +17 -3 libmuon/backends/ApplicationBackend/ApplicationUpdates.cpp M +2 -0 libmuon/backends/ApplicationBackend/ApplicationUpdates.h http://commits.kde.org/muon/b966840d9e1addc6c72cf45ab22f1ca088b29a73
*** Bug 330273 has been marked as a duplicate of this bug. ***