update-manager very slow on asus eee box 202

[bsh]

hello
i am running ubuntu 8.04.2 with xfce on an asus eee box 202, intel atom n270 @ 1.6ghz, 1gb ram, 160gb hdd. it is running headless, accessible via vnc/ssh/ftp.
whenever the update-manager detects updates, i click on the system tray notification icon. then the software updates manager comes up, with a small popup window and a progress bar: building dependency tree, status information, etc. etc. etc., then it shows the available updates. i install them, then the popup comes again and re-checks everything.
when the popup is at the steps "reading status information" (translated back from hungarian, should be something like that), it gets VERY slow, takes a minute to proceed.
i know the eee box is not the fastest machine around, but i see no reason why the software updater gets that slow at this step: there is only 1-2% cpu usag, no heavy memory usage (as far as i can tell), and absolutely no hard disk activity.
so i have no idea why is it that slow?

[Michael Vogt (mvo)]

Thanks for your bugreport.

I do not have such a machine (unfortunately). That makes debugging a bit more difficult. Could you please apply the attached profiling patch and give feedback on the results (what it prints on the terminal).

[bsh (bsh)]

Hi Michael,

of course i could apply this patch, if you tell me exactly how, because i have no updatemanager.py file to patch.

[Brian Murray (brian-murray)]

You'll find the files you need to patch in the following directory:

/usr/lib/python2.5/site-packages/UpdateManager/

[bsh (bsh)]

thanks! (That will make another bugreport of file finder then ;-) )
patching was not successfull (or maybe partially), dunno if this is critical:

patching file GtkProgress.py
Hunk #1 FAILED at 24.
1 out of 4 hunks FAILED -- saving rejects to file GtkProgress.py.rej
patching file UpdateManager.py
Hunk #1 succeeded at 991 (offset 207 lines).

[bsh (bsh)]

ok, last time the kernel update screwed my network, i had to use a keyboard & monitor to fix it (instead of ssh/vnc, which didn't work without the network coming up...)
so i had the chance of trying this out too. it looks like it works fine with a monitor attached. but it is still terribly slow with vnc.
can't it be that somehow the update manager waits for or synchronizes it's progress bar to screen refrshes or something? that's the only thing i can think of, since vnc refresh rate is much slower than a monitor's refresh, but i don't think it's a vnc bug, since verything else works fast with vnc.
or maybe it doesn't like to be run on display :1 instead of :0?

[bsh (bsh)]

since a while, it now runs much better. i remember there were some updates to update-manager, maybe that solved it. or a kernel update, or something. don't know.
but now it is fine! finally! :)