Arch Linux

These are with rc9
I don't remember if they were fixed after that.

oops, I didn't see "1) redirection to a file works (report by Roman)". LOL! Sorry. :)
It's bad I don't have rights to edit/remove comments. :(

Fixed (hopefully) bugs where the download rate would be wrong (showing really high values, or infG/s perhaps).

I fixed the redirection stuff in CVS. The 'yesno' questions *should* remain on stderr (why they are not redirected to a file) as it allows for behavior like so:

# pacman -S foo --debug > blah
# Do you want to shoop da woop? [Y/n]

of course, typical 2>&1 > blah redirection will break this, but then pacman will also appear to hang as it waits for input.

In case of 2>&1 > redirection "yes | pacman ..." should be used.

or --noconfirm

--noconfirm is the best way to do this. Using 'yes' is a bit hacky when there are alternatives available.

First of all: all issues below are for rc9, so sorry if they were fixed after it.

1) when downloading file pacman displays sizes from 0K to 999K, and from 1M to 999M,
but IMO it would be better to display sizes from 1M up to 10M as 1,0M to 9,9M

2) pacman cuts packages names not very good,
for example on standard 80 char width screen it cuts beryl-plugins-unsupported as beryl-plugins-unsupport
I propose to cut long names in such way that they will look like beryl-plugins-unsuppo.. so there will be clear evidence that package name was cut.

3) while doing an update few minutes ago I noticed that pacman displayed "upgrading php-suhosin..." two times.

4) while pacman displays "upgrading php-suhosin..." and then post_upgrade() output, in pacman.log it uses reverse order - first post_upgrade() output, then "upgraded php-suhosin (5.2.0-4 -> 5.2.1-1)". IMO pacman.log's order should be changed.


Please sorry for the absence of screenshots, I did latest updates in plain text console.
If you need some clarifications I may reproduce these quirks in vmware or gnome terminal to get screenshots.

1) Actually the cutoff is 2048 in all cases (> 2048K , moves to M, > 2048M moves to G)

2) Yeah a "..." might be a good idea. Just curious though, does ellipsis (...) translate from language to language?

3 & 4 I will look at in alike 1-2 hours

An PS - you can use fbgrab to take console screenshots 8) Not saying they're required, just that they're fun.

Oh wait on #1, yeah - I have this change locally - total size int->float for output

1) I meant that it would be nice to have output like 2,0M -> 2,3M -> 2,7M -> 3,2M, than just 2M -> 3M
2) I don't understand what you mean by "translate from language to language" :-/

Thanks for reminding about fbgrab, I totally forgot about it. :)

regarding #2:
I meant, does "..." make sense for internationalized stuff. You know, like how the French quote things «like this» (lets see if html entities work) etc etc

1, 2, and 3 should be fixed in CVS.
4 might be more difficult, I'll look into it later.

Wait... I misread #4:
The current order is:
upgrading...
post_upgrade
upgraded...

To me, this makes sense, as even though post_upgrade implies "after the upgrade" the whole process isn't complete until post_upgrade is run

I think I'm going to close this out. Feel free to open another FR for the ordering of these messages, but I'm of the opinion that it is correct.