[Bug 1054] wrote:
https://qa.mandrakesoft.com/show_bug.cgi?id=1054Yes, it looks like urpmi cannot subparse 500 series ftp info messages or echo to a dialog (either would work, if a 15 line scrollable ftp status dialog or child pane\Xwindow would be doable). I found 3\4 of the failures, when followed by immediate ftp linkups, showed 530-- mirror at capacity for this class of user-- errors. Not dead mirror, not bad URL per se, rather mirror busy for anonymous access. so, typically in that case switched to another CONTINENT for downloading. I now, in my Software Manager in 9.0, install instead of update, and list by upgradability-- if the upgradability list would also show source, oe could pick from an upgradability list more intelligently and eliminate the use of the auto-updater module in MCC except for security updates. This would save dev time, lots of it. One or the other needs doing, imho.
Product: rpmdrake
Component: MandrakeUpdate
Summary: Mandrake Update hangs if Source is bad
Version: 2.0-27mdk
Platform: All
OS/Version: All
Status: UNCONFIRMED
Severity: normal
Priority: P1
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
When a Mandrake Update mirror entry is not valid, Mandrake Update will hang forever with the dialog "Please wait, contacting mirror to update packages." The only way to recover is (novice method) kill the window or (expert method) ps for the urpmi process and kill it. The Log Messages within the Mdk Control Center only says "MandrakeUpdate[3081]: launched command: /usr/sbin/urpmi.update update_source" Console messages are equally terse, hanging with the status message: retrieving description file of "update_source"... There are two things. First is that urpmi.update cannot recover if the update source URL is bad. It fails just the same way if invoked from the command-line. The second is that mirror URLs retrieved from the Choose A Mirror interface are not reliable. It's trial and error to select a working mirror as an Update Source, then that Source can become invalid some time later. SUGGESTION: Why _commit_ to an Update Source at all? Why not present the user with the Mirror List EACH TIME he/she invokes Mandrake Update? If fetching the Mirror List should fail, there can be one in cache. Then the user would choose one (or more?) from the List and press a button to retrieve the Description File. Any mirror that delivers a proper Description File is the mirror we use to retrieve files. If this fails, however, the user would be alerted and invited to try another mirror from the list. Repeat until success. The interface could get specific about failures w/o too much trouble, informing the user that the Mirror is full (try later), or else it doesn't respond (network down?), or the path is missing and requires administrator's attention.
full console trace: mcc pid 3052 examining synthesis file [/var/lib/urpmi/synthesis.hdlist.Installation CD 1 (x86) (cdrom1).cz] examining synthesis file [/var/lib/urpmi/synthesis.hdlist.Installation CD 2 (x86) (cdrom2).cz] examining synthesis file [/var/lib/urpmi/synthesis.hdlist.International CD (x86) (cdrom3).cz] examining synthesis file [/var/lib/urpmi/synthesis.hdlist.update_source.cz] examining synthesis file [/var/lib/urpmi/synthesis.hdlist.Installation CD 1 (x86) (cdrom1).cz] examining synthesis file [/var/lib/urpmi/synthesis.hdlist.Installation CD 2 (x86) (cdrom2).cz] examining synthesis file [/var/lib/urpmi/synthesis.hdlist.International CD (x86) (cdrom3).cz] retrieving description file of "update_source"...
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
John.
