[pacman-dev] pacman -Sy with no network = weird result
Here is a quick and lazy bug report so that I do not forget :) LANG=C sudo pacman -Sy :: Synchronizing package databases... error: failed to update testing (library not initialized) error: failed to update core (library not initialized) error: failed to update extra (library not initialized) error: failed to update community-testing (library not initialized) error: failed to update community (library not initialized) error: failed to synchronize any databases The error and the output is quite confusing.
On Thu, Nov 26, 2009 at 9:52 AM, Xavier
Here is a quick and lazy bug report so that I do not forget :)
LANG=C sudo pacman -Sy :: Synchronizing package databases... error: failed to update testing (library not initialized) error: failed to update core (library not initialized) error: failed to update extra (library not initialized) error: failed to update community-testing (library not initialized) error: failed to update community (library not initialized) error: failed to synchronize any databases
The error and the output is quite confusing.
Should this get turned into a real bug report? :P -Dan
On Mon, Nov 30, 2009 at 7:03 AM, Dan McGee
On Thu, Nov 26, 2009 at 9:52 AM, Xavier
wrote: Here is a quick and lazy bug report so that I do not forget :)
LANG=C sudo pacman -Sy :: Synchronizing package databases... error: failed to update testing (library not initialized) error: failed to update core (library not initialized) error: failed to update extra (library not initialized) error: failed to update community-testing (library not initialized) error: failed to update community (library not initialized) error: failed to synchronize any databases
The error and the output is quite confusing.
Should this get turned into a real bug report? :P
No, it should get turned into a patch :) I just realized an additional reason I got very confused by the above output (I thought my system was completely broken :D). I think I was used to the old ouput : :: Synchronizing package databases... error: failed retrieving file 'testing.db.tar.gz' from mir.archlinux.fr : Transient resolver failure error: failed retrieving file 'testing.db.tar.gz' from mir1.archlinuxfr.org : Transient resolver failure error: failed to update testing (Transient resolver failure) error: failed retrieving file 'core.db.tar.gz' from mir.archlinux.fr : Transient resolver failure error: failed retrieving file 'core.db.tar.gz' from mir1.archlinuxfr.org : Transient resolver failure error: failed to update core (Transient resolver failure) error: failed retrieving file 'extra.db.tar.gz' from mir.archlinux.fr : Transient resolver failure error: failed retrieving file 'extra.db.tar.gz' from mir1.archlinuxfr.org : Transient resolver failure error: failed to update extra (Transient resolver failure) error: failed retrieving file 'community.db.tar.gz' from mir.archlinux.fr : Transient resolver failure error: failed retrieving file 'community.db.tar.gz' from mir1.archlinuxfr.org : Transient resolver failure error: failed to update community (Transient resolver failure) error: failed to synchronize any databases So not only we did not set pm_errno (to ERR_LIBFETCH which prints fetchLastErrString = Transient resolver failure), but also we no longer printed the message for each url/mirror. This was caused by commit d2dbb04a9af7a18da which does fetchStat first , but did not print any error in that case. + fetchLastErrCode = 0; + if(fetchStat(fileurl, &ust, "") == -1) { + ret = -1; + goto cleanup; + } A patch will follow to restore the old more verbose behavior :) Sidenote : I saw many times people confused, even with the above verbose output, usually after installing arch and before setting up the network. Not sure how they cannot realize their network is down. Maybe 'transient resolver failure' is confusing ? That's a libfetch message though, so we cannot change it. And it seems appropriate. And 'failed retrieving file' sounds explicit enough. Comments and thoughts welcome.
download_internal is supposed to always set pm_errno but did not in many
cases.
The most important (and tested) change is the one concerning fetchStat. This
is typically where the code will fail when the network is down for example.
Before commit d2dbb04a9af7a18da, this fetchStat call did not exist and the
same kind of errors would be encountered in the fetchXGet call that follows.
I just copied the error printing to restore the old behavior.
Signed-off-by: Xavier Chantry
participants (3)
-
Dan McGee
-
Xavier
-
Xavier Chantry