2009-08-07 14:30:38 |
corsbu |
bug |
|
|
added bug |
2009-08-07 14:30:38 |
corsbu |
attachment added |
|
updatemanager.jpg http://launchpadlibrarian.net/30006046/updatemanager.jpg |
|
2010-03-09 21:49:00 |
Richard Wilbur |
update-manager (Ubuntu): status |
New |
Confirmed |
|
2010-03-09 21:52:16 |
Richard Wilbur |
attachment added |
|
Picture of update-manager window with download size > update size. http://launchpadlibrarian.net/40643791/Screenshot-UpdateManager3-4MB.png |
|
2010-03-17 19:52:21 |
Richard Wilbur |
tags |
download jaunty update update-manager |
download jaunty karmic update update-manager |
|
2010-03-17 19:54:23 |
Richard Wilbur |
summary |
[jaunty 64bit] update-manager inconsistent with download size |
update-manager inconsistent with download size |
|
2010-06-09 07:40:12 |
Per Kongstad |
attachment added |
|
Updatemanager.png http://launchpadlibrarian.net/49996858/Updatemanager.png |
|
2010-08-30 17:54:15 |
Andrea Amoroso |
bug |
|
|
added subscriber Andrea Amoroso |
2010-08-30 17:58:16 |
Andrea Amoroso |
attachment added |
|
screenshot.png https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/410310/+attachment/1529921/+files/screenshot.png |
|
2010-10-17 17:13:39 |
TH |
bug |
|
|
added subscriber TH |
2010-11-14 13:24:48 |
Manfred Hampl |
attachment added |
|
update-manager-diff.png https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/410310/+attachment/1733111/+files/update-manager-diff.png |
|
2010-11-14 14:02:56 |
Michael Wood |
bug |
|
|
added subscriber Michael Vogt |
2011-03-20 18:35:13 |
Manfred Hampl |
attachment added |
|
natty.patch https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/410310/+attachment/1923981/+files/natty.patch |
|
2011-03-20 18:52:09 |
Manfred Hampl |
attachment added |
|
maverick.patch https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/410310/+attachment/1924097/+files/maverick.patch |
|
2011-03-21 17:36:21 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Review Team |
2011-03-21 17:36:24 |
Brian Murray |
tags |
download jaunty karmic update update-manager |
download jaunty karmic patch update update-manager |
|
2011-04-12 11:58:03 |
Manfred Hampl |
bug task added |
|
update-manager |
|
2011-04-12 12:00:36 |
Manfred Hampl |
update-manager: status |
New |
Confirmed |
|
2011-07-19 13:41:13 |
Robert Roth |
update-manager (Ubuntu): status |
Confirmed |
Incomplete |
|
2011-07-19 14:24:26 |
Robert Roth |
bug |
|
|
added subscriber Robert Roth |
2011-07-21 11:49:13 |
Robert Roth |
update-manager (Ubuntu): assignee |
|
Robert Roth (evfool) |
|
2011-07-21 11:49:16 |
Robert Roth |
update-manager (Ubuntu): status |
Incomplete |
Confirmed |
|
2011-07-21 11:55:09 |
Robert Roth |
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
All 3 state different sizes of a download. (see attachment)
This is also the case in Karmic. |
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. |
|
2011-07-21 11:55:15 |
Robert Roth |
update-manager (Ubuntu): status |
Confirmed |
Triaged |
|
2011-07-21 11:55:22 |
Robert Roth |
update-manager (Ubuntu): importance |
Undecided |
Low |
|
2011-07-22 07:39:46 |
Robert Roth |
update-manager (Ubuntu): status |
Triaged |
In Progress |
|
2011-07-25 09:38:31 |
Launchpad Janitor |
branch linked |
|
lp:~evfool/update-manager/stringfixes |
|
2011-07-25 09:39:18 |
Robert Roth |
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. |
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. |
|
2011-07-25 16:50:11 |
Launchpad Janitor |
update-manager (Ubuntu): status |
In Progress |
Fix Released |
|
2012-04-24 10:19:17 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/update-manager |
|