Update Manager never actually updates

Hi,

Thanks for the bug report.

Are you running compiz? I have seen something like the screenshot
you posted when compiz isn't happy. I think that is tangential to the
real problem though.

update-manager actually uses synaptic to do the upgrade, do you
have any problem running and using synaptic?
(System->Administration->Synaptic Package Manager)

It would be great to have any error message from the failure, it might
just be difficult to find them. Could you please attach your ~/.xsession-errors
from a session in which you had the problem? Do you get any error
messages if you run update-manager from a terminal?

Thanks,

James

Yes, I am using Compiz. I ran `sudo update-manager` from the command-line and when I click on [ Install Updates ] I get the proper window that shows me what operations it will perform, rather than just being returned to the available updates dialog. I did not run the update, so that I could continue to test. However, I can update one package if you think that is necessary.

I then tried running `gksu update-manager`, but since I just used sudo I did not get a pw prompt. I will wait for the sudo timeout and will try again with gksu, as I'm wondering if it is that pw prompt that might be the problem.

Per your request my ~/.xsession-errors is attached.

On Tue, 2008-06-03 at 11:19 +0000, Pete Goodall wrote:
> Yes, I am using Compiz. I ran `sudo update-manager` from the command-
> line and when I click on [ Install Updates ] I get the proper window
> that shows me what operations it will perform, rather than just being
> returned to the available updates dialog. I did not run the update, so
> that I could continue to test. However, I can update one package if you
> think that is necessary.
>
> I then tried running `gksu update-manager`, but since I just used sudo I
> did not get a pw prompt. I will wait for the sudo timeout and will try
> again with gksu, as I'm wondering if it is that pw prompt that might be
> the problem.
>
> Per your request my ~/.xsession-errors is attached.

Hi,

Thanks for the extra information.

'update-manager' itself doesn't run as root normally, so could
you test running plain 'update-manager' from a terminal?

Your ~/.xsession-errors doesn't have anything obviously related,
so I haven't got any more suggestions to give from that.

Thanks,

James

Thanks for your bugreport.

This sounds like a issue with gksu. Could you please open a terminal and run:
$ gksu id
and tell me what output that gives you?

Could you also please run "locale" and let me know what that outputs?

~$ gksu id

~$
~$

Essentially returns nothing. :-/

~$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

Let me know if you need additional information. Btw, I ran update-manger from the command line as a regular user and don't get any particularly interesting output. Don't think ~/.xsession-errors is interesting either, but let me know if you want me to attach it.

This might be a duplicate of the gksu problem in ug #237325

Hmm.... How so? There is no problem resolving the hostname and there is no hang. Just no action. :-/

pete@rhesus:~$ ping -c4 localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.074 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.069 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.071 ms
64 bytes from localhost (127.0.0.1): icmp_seq=4 ttl=64 time=0.075 ms

--- localhost ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2998ms
rtt min/avg/max/mdev = 0.069/0.072/0.075/0.006 ms
pete@rhesus:~$ ping -c4 rhesus
PING rhesus (127.0.1.1) 56(84) bytes of data.
64 bytes from rhesus (127.0.1.1): icmp_seq=1 ttl=64 time=0.075 ms
64 bytes from rhesus (127.0.1.1): icmp_seq=2 ttl=64 time=0.043 ms
64 bytes from rhesus (127.0.1.1): icmp_seq=3 ttl=64 time=0.070 ms

--- rhesus ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.043/0.062/0.075/0.016 ms
pete@rhesus:~$ ping -c4 rhesus.local
PING rhesus.local (192.168.122.1) 56(84) bytes of data.
64 bytes from rhesus.local (192.168.122.1): icmp_seq=1 ttl=64 time=0.030 ms
64 bytes from rhesus.local (192.168.122.1): icmp_seq=2 ttl=64 time=0.062 ms
64 bytes from rhesus.local (192.168.122.1): icmp_seq=3 ttl=64 time=0.061 ms
64 bytes from rhesus.local (192.168.122.1): icmp_seq=4 ttl=64 time=0.061 ms

--- rhesus.local ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 0.030/0.053/0.062/0.015 ms

OK. Well this definitely is not a problem with update-manager. This is a problem with libthinkfinger (or maybe libpam-libthinkfinger). I configured my system to use libthinkfinger and libpam-thinkfinger. If I authenticate with the integrated fingerprint reader it works fine. If I use a password the behaviour is as described above. If I use aptitude and use my password to authenticate. It is asking me for a password twice. Something is screwy here. I'll close this as invalid.