Bug 9545

title height is not defined by rpmdrake but by the window manager/desktop (here: GNOME)

Summary: rmpdrake erroneously shows that both the updated package and the removed package are identical (have the same version) => rpmdrake erroneously shows that both the updated package and the removed package are identical (have the same version)

Created attachment 3780 [details]
'Distribution Upgrade' window

The window title high difference rose to the surface since you added the global progress bar in rpmdrake. Before that it was fine. Maybe the title bar is smaller in heigh because there are no control buttons on the window 'Distribution upgrade'. All the other windows have control buttons (close, minimize, ...). Perhaps there is not much you can do here ... and this problem is related, as you said, with something else.
However, I will provide two screenshots for comparison.

Created attachment 3781 [details]
'Please wait' window

And now the attachment with the 'Please wait' window. Notice that this window has a normal title bar height.

Back to the subject: rpmdrake erroneously shows that both the updated package and the removed package are identical (have the same version) ... if you need additional details / screenshots / particular case, etc. to illustrate the problem just request here and I will try to provide that.

Created attachment 3782 [details]
Firefox window screenshot

(In reply to Bogdan Gruescu from comment #2)
>  ... Maybe the title
> bar is smaller in heigh because there are no control buttons on the window
> 'Distribution upgrade'. All the other windows have control buttons (close,
> minimize, ...).

No, I was wrong. Take a look at this third screenshot from Firefox. 'Clear All History' window has no control buttons on it and it still has a normal title bar height. So why the 'Distribution Upgrade' window from the first screenshot provided earlier makes exception and this window has a smaller title bar height?  
It's not a big issue and this is a lower priority problem, but I think it is worth to investigate this when you have some time.

Created attachment 3798 [details]
rpmdrake screenshot

I've just performed a network install and the window title height issue has miracoulously gone, so forget about it.

Here is a screenshot about rpmdrake reporting the wrong package was removed.
First, this is what I had before update (version 15.42):

[root@localhost bogdan]# rpm -qa | grep drakxtools
drakxtools-curses-15.42-1.mga3
drakxtools-backend-15.42-1.mga3
drakxtools-15.42-1.mga3
[root@localhost bogdan]# 

And now I did the update with rpmdrake.
In the screenshot you can see the text: "removing package harddrake-15.44-1.mga3.x86_64'...". This is the bug, the correct text should have been "removing package harddrake-15.42-1.mga3.x86_64'...".

(In reply to Bogdan Gruescu from comment #6)

> I've just performed a network install and the window title height issue has
> miracoulously gone, so forget about it.
> 

Not really ... On packages installation / update it's fine, but if the user remove one or more of the installed packages, the window title height is smaller (perhaps you have to apply the same change in more places).

Also the words "Packages installation" are in all scenarios in two places:
a) the window name is "Package installation"
b) inside the window in the upper part (above the global progress bar) there is a label "Packages installation".

There in clearly wrong to see in these 2 places "Packages installation" when the user remove a package and the words "Packages removal" should be appropriate ...

If you name the window "Apply changes" then this will cover all the scenarios with rpmdrake:
- user may install packages;
- user may remove packages;
- a mix of these two (install some packages and remove others in the same opertion);
- user may update packages;
- perhps some day the user will be able do downgrade packages.

One may consider "Apply changes" a dull name and surely this is not an excellent proposal, but is obvious better than the current situation when the window name is "Packages installation" irrespective of the scenarios / situations.

The same principle applies to b) - the global progress bar label - where it's better to find a name which applies to all situations.

Created attachment 3857 [details]
fix retrieving uninstalled package name

Does this patch fixes it?

(to be applied in )
as root, in a terminal, just run:
cd /usr/lib/perl5/vendor_perl/5.16.3/
patch -p1 < /tmp/9545.diff

Created attachment 3863 [details]
Package name missing in the removal phase

I am away from my Mageia computer till next week ... but I installed the RC DVD for testing purposes on a different computer.
Following the instructions provided, here is the output:

[bogdan@localhost ~]$ su
Password: 
[root@localhost bogdan]# cd /usr/lib/perl5/vendor_perl/5.16.3/
[root@localhost 5.16.3]# patch -p1 < /tmp/9545.diff
patching file gurpm/RPMProgressDialog.pm
Hunk #2 succeeded at 161 (offset -3 lines).
Hunk #3 succeeded at 185 (offset -3 lines).
Hunk #4 succeeded at 302 (offset -3 lines).
[root@localhost 5.16.3]# 

Then I did a full update ... now I see it would have been an inspired choice to update just a few packages and post the results, not all of them ...

However, if the patch applied correctly, then now is worse:

a) the name of the removed package is missing altoghether (screenshot provided);
b) the package count is now wrongly displayed (in the next screenshot you will see '137/109').

I have no idea whether the test results were influenced because of the way I performed it.

Created attachment 3864 [details]
number of packages to be installed

And here is the screenshot for b) - notice << 'libreoffice-ure' (137/109)... >> which shows the absurd situation with package no. 137 out of 109.

Also the global progress bar reaches 100% too quickly, but this minor problem is old (since its implementation).

Created attachment 3865 [details]
try this one instead

(but revert the first one first: redo the first command with -R)

Created attachment 3866 [details]
Screenshot after patch 9545b manually applied

I tried, but ... either I did some mistakes, or the file was replace during the first set of updates (reversing the patch) ... and I really don't possess any technical knowledge to understand what's wrong here.

[bogdan@localhost ~]$ su
Password: 
[root@localhost bogdan]# cd /usr/lib/perl5/vendor_perl/5.16.3/
[root@localhost 5.16.3]# patch -R -p1 < /tmp/9545.diff
patching file gurpm/RPMProgressDialog.pm
Unreversed patch detected!  Ignore -R? [n] n
Apply anyway? [n] y
Hunk #1 FAILED at 51.
Hunk #2 FAILED at 164.
Hunk #3 FAILED at 188.
Hunk #4 FAILED at 305.
4 out of 4 hunks FAILED -- saving rejects to file gurpm/RPMProgressDialog.pm.rej
[root@localhost 5.16.3]# 

[bogdan@localhost ~]$ su
Password: 
[root@localhost bogdan]# cd /usr/lib/perl5/vendor_perl/5.16.3/
[root@localhost 5.16.3]# patch -p1 < /tmp/9545b.diff
patching file gurpm/RPMProgressDialog.pm
Hunk #1 FAILED at 310.
1 out of 1 hunk FAILED -- saving rejects to file gurpm/RPMProgressDialog.pm.rej
[root@localhost 5.16.3]# 

Anyway, I saw that 9545b.diff contains only one change, so I took 'RPMProgressDialog.pm.orig' file, made the change manually (according to your patch) and saved the file replacing 'RPMProgressDialog.pm'. Hope this is a correct way ...

I was able to grab a screenshot during the update (provided as attachment) and shows that cpupower-3.8.10-1.mga3 was removed. This is the correct text since version 3.8.11 was installed during updates (the screenshot shows that well).
So, it seems that this change fixed the problem ... I hope so ...

Should this be tested more (where more packages are available as updates, in more than 1 transaction) to be sure that everything is fine? This time I got only 3 packages as updates (unfortunatelly I already updated a few before reading about the new proposed patch).

I will attach my current file 'RPMProgressDialog.pm' in the next message just in case this is helpful.

Created attachment 3867 [details]
current file /usr/lib/perl5/vendor_perl/5.16.3/gurpm/RPMProgressDialog.pm

Marking "Fixed" as (g)urpmi-7.26-1 which carry the fix is now available, thanks Thierry.

Please try to polish the graphical interface after Mageia 3 is out, maybe Comment 7 needs consideration and also the global progress bar needs some work as the progress displayed is not accurate.

Status: NEW => RESOLVED
Resolution: (none) => FIXED

You can test urpmi urpmi-7.26

Yes, I've already updated with urpmi-7.26 (and tested it before writing Comment 14 and also now) and the packages names and versions in the removal phase during update appear to be correct. Also it doesn't seem to be any regression. In short, I'm very confident that urpmi-7.26 fixed the main reported issue.