[Bug 410310] Re: update-manager inconsistent with download size

Robert Roth evfool at gmail.com
Thu Jul 21 11:51:51 UTC 2011


Thanks Manfred, you've got a really good point there, and you've found the root of the problem. Setting to Triaged, and updating the description of the bug according to your highly detailed comment.
---
Ubuntu Bug Squad volunteer triager
http://wiki.ubuntu.com/BugSquad

** Changed in: update-manager (Ubuntu)
     Assignee: (unassigned) => Robert Roth (evfool)

** Changed in: update-manager (Ubuntu)
       Status: Incomplete => Confirmed

** Description changed:

  Binary package hint: update-manager
  
  There are three places, where the update-manager states the download size of an update:
  -For every package itself
  -For all packages together
  -During download
- All 3 state different sizes of a download. (see attachment)
- This is also the case in Karmic.
+ The first two and the third one differ. (see attachment - the total and the per-package difference has been fixed in the meantime, the difference between update-manager main window and the progress windows still exists)
+ 
+ When doing an update with update-manager some numbers displayed on screen come from update-manager and some from apt.
+ And now apt is displaying the numbers with decimal kilos (K=1000), and update-manager is displaying the numbers with binary kilos (K=1024). Even if the float problem is solved, this still gives a difference in display of about 4.8% for Megabyte numbers. (see some more details in my comment #9 above and some of the attached pictures).
+ 
+ Before this bug is set to 'Fix Released' I would like to raise the
+ question if it would make sense to consistently use one and the same
+ factor for kilo/mega representation throughout all package management
+ programs. This could be done either by changing humanize_size to decimal
+ as well, or changing apt/apt-pkg/strutl.cc to binary, or even by totally
+ eliminating humanize_size and using also the apt subroutines in update-
+ manager.
+ 
+ As far as I can see there is even another weakness in humanize_size (at
+ least in older versions, I have not checked the most recent ones yet):
+ the localization of the decimal separator is not correct and always
+ displayed as '.' even in 'decimal point is comma' local settings as with
+ German language.

** Changed in: update-manager (Ubuntu)
       Status: Confirmed => Triaged

** Changed in: update-manager (Ubuntu)
   Importance: Undecided => Low

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to update-manager in Ubuntu.
https://bugs.launchpad.net/bugs/410310

Title:
  update-manager inconsistent with download size

Status in Update Manager:
  Confirmed
Status in “update-manager” package in Ubuntu:
  Triaged

Bug description:
  Binary package hint: update-manager

  There are three places, where the update-manager states the download size of an update:
  -For every package itself
  -For all packages together
  -During download
  The first two and the third one differ. (see attachment - the total and the per-package difference has been fixed in the meantime, the difference between update-manager main window and the progress windows still exists)

  When doing an update with update-manager some numbers displayed on screen come from update-manager and some from apt.
  And now apt is displaying the numbers with decimal kilos (K=1000), and update-manager is displaying the numbers with binary kilos (K=1024). Even if the float problem is solved, this still gives a difference in display of about 4.8% for Megabyte numbers. (see some more details in my comment #9 above and some of the attached pictures).

  Before this bug is set to 'Fix Released' I would like to raise the
  question if it would make sense to consistently use one and the same
  factor for kilo/mega representation throughout all package management
  programs. This could be done either by changing humanize_size to
  decimal as well, or changing apt/apt-pkg/strutl.cc to binary, or even
  by totally eliminating humanize_size and using also the apt
  subroutines in update-manager.

  As far as I can see there is even another weakness in humanize_size
  (at least in older versions, I have not checked the most recent ones
  yet): the localization of the decimal separator is not correct and
  always displayed as '.' even in 'decimal point is comma' local
  settings as with German language.

To manage notifications about this bug go to:
https://bugs.launchpad.net/update-manager/+bug/410310/+subscriptions




More information about the foundations-bugs mailing list