You are not logged in.
This seems to be some defect in mirror sync mechanism, since they declare package as already synced, but in fact they don't have it.
It occurs so often and is really annoying. I have to use main server when this happens.
I believe this is a bug and Arch needs a better method of mirrors syncing.
Offline
In the mirrorcheck link, only about 15% of the mirrors are satisfactorily in sync at this time !
And the mirror http://mir.archlinux.fr is now more than four times slower than usual.
I chose another one for now to regain a satisfactory speed again.
Apart from that, the recent big upgrade goes smoothly, thanks to the devs for their good work.
But I agree with Mad Fish that it seems there are problems with the sync with mirrors globally.
Offline
And the mirror http://mir.archlinux.fr is now more than four times slower than usual.
I chose another one for now to regain a satisfactory speed again.
You too? I thought it was my connection ... what did you choose?
aur S & M :: forum rules :: Community Ethos
Resources for Women, POC, LGBT*, and allies
Offline
I thought it was just me too...I've had to rotate mirrors almost every other day and hopefully find one that has all of the packages that I need. This has been happening for the past few weeks I think.
Offline
You may try MirrorStatusReflector to keep track of most up-to-date mirrors. It appears to be Europe-centric, hoewever.
To know or not to know ...
... the questions remain forever.
Offline
But why does a mirror have to be up-to-date in order to work? The problem is caused by the $repo.db file not being consistent with the actual packages on the mirror, and I don't understand why that happens so often lately. Is it the sheer amount of traffic that is causing problems (KDE4.4, openoffice)?
Good ideas do not need lots of lies told about them in order to gain public acceptance.
Offline
My understanding of the packing process is that all testing packages are in a folder called testing-x86_64 or testing-i686 depending on the arch. Then when a package gets moved, it gets moved to extra-i686 or extra-x86_64.
So then on the mirror the pkg is being deleted from testing and being uploaded to extra. This seems to kill many of the mirrors.
Maybe a dev can shed a bit more light on this topic.
Last edited by pyther (2010-02-15 22:46:14)
Offline
My understanding of the packing process is that all testing packages are in a folder called testing-x86_64 or testing-i686 depending on the arch. Then when a package gets moved, it gets moved to extra-i686 or extra-x86_64.
So then on the mirror the pkg is being deleted from testing and being uploaded to extra. This seems to kill many of the mirrors.
Maybe a dev can shed a bit more lite on this topic.
That is exact. For example, the latest libpng/libjeg rebuild had over several GB of packages to be upload to all the mirrors when it was pushed to extra/community. Therefore, you have lots of packages and lots of mirrors so there's not enough rsync connections and/or bandwith to get the package to the mirrors fast enough. Plus the main server still has to serve web pages for the main web site, the forums, wiki, etc.
We are aware of the problem and got a patch to fix this (see dev ML). Basically, the packages will go in a pool and we'll use symlinks like we're doing for the 'any' arch. Instead of moving packages around, we'll be moving symlinks. As they are much smaller, it'll be faster.
Offline
Sounds good.
(If anyone cares, I haven't had any problem with mirrors since that week, see above.)
Last edited by fsckd (2010-02-16 23:46:34)
aur S & M :: forum rules :: Community Ethos
Resources for Women, POC, LGBT*, and allies
Offline