Red Hat Bugzilla – Bug 186787
Pirut (and pup also) are hellish unresponsive when downloading packages
Last modified: 2008-08-02 19:40:32 EDT
Description of problem: Pirut (and pup also) are very unresponsive when downloading packages. While downloading the gui and the progress-window are not redrawn. I think some users can become confused and think the prog died. Version-Release number of selected component (if applicable): latest How reproducible: by running pirut or pup Steps to Reproduce: s.a. Actual results: pirut and pup are very unresponsive Expected results: The gui and especially the progress-bar should be redrawn, so the user still nows something is going on. Additional info:
It's pretty responsive for me here. What sort of network connection do you have and where are you pulling from? The only way I can really see that it wouldn't be updated relatively "frequently" is if the server isn't returning the size of the packages being downloaded. Also, if it's a really slow straw, then it could be infrequent -- I added something so that it will update once a second as long as we're getting the size.
Though I'm not the original reporter, I think I'm seeing the same issue. If I have Pup downloading updates and am doing other things with my computer I sometimes notice (via the GNOME applet that the network activity has died away earlier than I expect) if I switch to the Pup window it never (and I have left it for more than an hour) redraws its screen, I'm not sure whether it crashes or a mirror has dropped connection and it never recovers or...? I don't experience similar problems with yum and my network connection is mediocre (512Kb home ADSL). (I use the standard repos + livna) Not able to reliably reproduce this but I'm happy to run with extra logging etc. for a while if you explain to me (assume I'm a complete idiot) how.
Pup and pirut should create a thread, so that the gtk event loop could occur even when download stalls. This would avoid these hangs...
(In reply to comment #3) > Pup and pirut should create a thread, so that the gtk event loop could occur > even when download stalls. This would avoid these hangs... there is a thread in the devel list about this: http://www.redhat.com/archives/fedora-devel-list/2006-June/msg00529.html for me in FC6T1 pup seems never to redraw the download window. I have a cable connection 4Mbit and and it is downloading with ~400Kb/s now (used gnome-system-monitor to check)
In FC6 test releases, the download progress bar was never getting set due to a yum bug -- I've fixed that up in yum CVS I've also changed things so that the progress bar will be updated for every 8k downloaded or every half a second, whichever is longer.