https://qa.mandrakesoft.com/show_bug.cgi?id=1054
------- Additional Comments From [EMAIL PROTECTED] 2003-01-27 14:20 -------
Francois, what do you think? Maybe the timeout delay should be
lowered?
It sounds more logical to select one mirror, the closest or
better for you, and use it afterwards.
------- Additional Comments From [EMAIL PROTECTED] 2003-01-27 15:00 -------
Le lun 27/01/2003 � 14:00, Guillaume Cottenceau a �crit :
It should not have problem if the site is connectable, there should be
an immediate error saying the file doesn't exist.
------- Additional Comments From [EMAIL PROTECTED] 2003-01-27 15:40 -------
Fran�ois Pons <[EMAIL PROTECTED]> writes:
yes but obviously it's not the fact :/.
------- Additional Comments From [EMAIL PROTECTED] 2003-01-28 17:17 -------
Francois, I installed curl as you suggested and there was an improvement: the
first BAD update_source eventually timed out and the next update_source was used
successfully. Before, it hung forever. This is better behavior. But I still suggest
that picking a mirror should not be a separate procedure. Let's pick a mirror(s)
from the list (or a cached copy) just before we begin updating from it, this way the
choice of mirrors is always current. BTW Here's an extremely unscientific
account of the mirrors that come up available for the U.S. checked with Konqeror and
command-line ftp.
ftp://ftp-linux.cc.gatech.edu/pub/linux/distributions/mandrake/updates/9.0/RPMS
FTP DOES NOT RESPOND
ftp://mirrors.secsup.org/pub/linux/mandrake/Mandrake/updates/9.0/RPMS
GOOD
ftp://ftp.stealth.net/pub/mirrors/ftp.mandrake.com/Mandrake/updates/9.0/RPMS/
UNRELIABLE, TIMED OUT AT FIRST, THEN CONNECTED
ftp://ftp.wtfo.com/pub/linux/mandrake/updates/9.0/RPMS/
CONNECTION REFUSED, NO EXPLANATION
ftp://carroll.cac.psu.edu/pub/linux/distributions/mandrake/updates/9.0/RPMS/
ANONYMOUS LOGIN EXREMELY LIMITED M,T,W,R,F 0900-1700: 25 ftp, 25 http, 10
rsync All other times: 75 ftp, 25 http, 10 rsync
ftp://ftp.math.utah.edu/pub/linux/Mandrake/updates/9.0/RPMS/
UNRELIABLE, TIMED OUT AT FIRST, THEN CONNECTED
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
------- Reminder: -------
assigned_to: [EMAIL PROTECTED]
description:
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"...
