calculating changes seems unresponsive

[Edwin Grubbs]

The update-manager stopped on "Setting new software channels" for over five minutes. The progress bar was all the way to the right except for a tiny sliver. Below the progress bar, it said "Calculating the changes". I almost killed it since it was taking so long with no indication of progress.

Info on the system being upgraded:
https://wiki.canonical.com/UbuntuPlatform/QA/LucidInternalTesting/EdwinGrubbs

TEST CASE:
1. install karmic
2. run update-manager
3. click on "new release available"
4. follow the steps
5. verify that the "calculating changes" step shows a progress pulse

[Michael Vogt (mvo)]

Thanks for your bug report.

I think we should add two changes:
a) a spinner that is shown next to the "Calculating changes text"
b) and changing the text to append "Calculating the changes (this may take some minutes)…"

Unfortunately we are in string freeze currently.

[Martijn_Hoekstra (martijnhoekstra)]

Though I have no experience in the freeze Exception process, it seems an exempt would be in place, as I killed the process from the terminal three times because I thought the process was frozen. If the fix is reasonably simple or straightforward, and pretty soon loads of people are going to be using this feature.

I know and understand the freeze process is pretty stringent, but one just can't expect update manager is used much before a new release.

[Michael Vogt (mvo)]

One simple way to keep the UI alive is:

=== modified file 'DistUpgrade/DistUpgradeCache.py'
--- DistUpgrade/DistUpgradeCache.py 2010-04-12 14:47:37 +0000
+++ DistUpgrade/DistUpgradeCache.py 2010-04-12 16:26:24 +0000
@@ -574,7 +574,16 @@

     # FIXME: make this a decorator (just like the withResolverLog())
     def updateGUI(self, view, lock):
+ progress = view.getOpCacheProgress()
+ i = 0
+ step = 1
         while lock.locked():
+ i += step
+ progress.update(i)
+ if i == 100:
+ step = -1
+ elif i == 0:
+ step = 1
             view.processEvents()
             time.sleep(0.03)

but for some reason this seems to crash on the qt frontend of the release upgrader (segfault deep in libqt).

[Michael Vogt (mvo)]

I commited the change to lucid and will aim with this at lucid-updates.

[Michael Vogt (mvo)]

I also closed the upstream task, the ubuntu task is enough to keep track of this problem.

[Michael Vogt (mvo)]

I add this as a SRU because its
a) trivial to add
b) lts -> lts upgrade calculation can be slow
c) netbooks are slow

and because of b) and c) people may be mislead that it hangs.

[Martin Pitt (pitti)]

Accepted update-manager into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Launchpad Janitor (janitor)]

This bug was fixed in the package update-manager - 1:0.134.8

---------------
update-manager (1:0.134.8) lucid-proposed; urgency=low

  * DistUpgrade/DistUpgradeCache.py:
    - show pulse while calculating the changes (LP: #548398)
  * DistUpgrade/DistUpgradeQuirks.py:
    - add workaround for 10_lupin infinite loop (LP: #540579)
      Thanks to Juergen Klar for providing the test-case
  * DistUpgrade/10_lupin:
    - include (fixed) lucid version of 10_lupin that fixes a possible
      infinite loop on upgrade
 -- Michael Vogt <email address hidden> Fri, 30 Apr 2010 17:08:46 +0200

[Martin Pitt (pitti)]

Copied update-manager lucid-proposed to maverick.