On 8/1/07, Tony Nelson tonynelson@georgeanelson.com wrote:
At 10:46 PM -0700 7/31/07, Antonio Olivares wrote:
[root@localhost ~]# yum install kernel-2.6.22.1-33.fc7 kernel-devel-2.6.22.1-33.fc7 kernel-headers-2.6.22.1-33.fc7 -y Loading "installonlyn" plugin Setting up Install Process Parsing package install arguments fedora 100% |=========================| 2.1 kB 00:00 primary.sqlite.bz2 100% |=========================| 3.8 MB 13:16 updates 100% |=========================| 1.9 kB 00:00 primary.sqlite.bz2 100% |=========================| 1.1 MB 03:42 Nothing to do
Trying again as of right now, but this is strange.
When that happens, yum isn't specific enough about why. To find out, do a "yum list whatever" to see if whatever is already installed or doesn't exist in the repos. -- ____________________________________________________________________ TonyN.:' mailto:tonynelson@georgeanelson.com ' http://www.georgeanelson.com/
That would not fix his problem. Antonio knows a specific set of packages exits; however, the repository used by yum lagged behind his awareness. The fix is actually simple: 1) Do not use a random miror via the mirrorlist. 2) Select a more responsive [in terms of syncing] mirror. [One can use the fastestmirror plugin, but I prefer selecting my own from http://mirrors.fedoraproject.org/publiclist/Fedora/7/ ] And/or 3) Use multiple mirrors for updates.
On Wed, 2007-08-01 at 09:19 -0700, Kam Leo wrote:
- Select a more responsive [in terms of syncing]
mirror. [One can use the fastestmirror plugin
Does the fastest mirror plugin also check for updatedness? I hadn't heard that, before.
On 8/1/07, Tim ignored_mailbox@yahoo.com.au wrote:
On Wed, 2007-08-01 at 09:19 -0700, Kam Leo wrote:
- Select a more responsive [in terms of syncing]
mirror. [One can use the fastestmirror plugin
Does the fastest mirror plugin also check for updatedness? I hadn't heard that, before.
You, of course, would read my reply out of context. I do not recommend using the fastestmirror plugin. I recommended using a fast mirror.
This is a generality, YMMV: My experience is that the faster mirrors; that is, those with high bandwidth, tend to have more resources available and, thus, sync to the Fedora servers on a dependable schedule. Find a fast mirror that does not lag too far from the main Fedora servers and you can be assured that eventually your system will able to get released updates.
One distro, was it SUSE?, had the sync schedule of their mirrors. It would be really nice if Fedora mirrors provided that data, too.
On 8/1/07, Rahul Sundaram sundaram@fedoraproject.org wrote:
Kam Leo wrote:
One distro, was it SUSE?, had the sync schedule of their mirrors. It would be really nice if Fedora mirrors provided that data, too.
File a RFE with Fedora infrastructure.
Rahul
Since I have no need for the feature I'll have to think about phrasing the problem before submitting the RFE.
By the way, experienced users don't need this feature and a work-around exists. Instead of just using the default fedora-updates.repo they can create (an)other updates repo file(s) and use a mirror that is in a different time zone, one that is advanced in time.
"Kam Leo" kam.leo@gmail.com writes:
One distro, was it SUSE?, had the sync schedule of their mirrors. It would be really nice if Fedora mirrors provided that data, too.
What the DJGPP mirrors do is, the master writes a "mirror.ts" timestamp file, with the time (seconds since epoch) and type (full, partial, etc) in it. It does this hourly. Nightly, it reads all the registered mirrors' timestamps and determines which are keeping up to date and which aren't, and updates the web page accordingly.
Examples: http://www.delorie.com/pub/djgpp/mirror.ts http://djgpp.linux-mirror.org/mirror.ts
On 01 Aug 2007 13:55:57 -0400, DJ Delorie dj@delorie.com wrote:
"Kam Leo" kam.leo@gmail.com writes:
One distro, was it SUSE?, had the sync schedule of their mirrors. It would be really nice if Fedora mirrors provided that data, too.
What the DJGPP mirrors do is, the master writes a "mirror.ts" timestamp file, with the time (seconds since epoch) and type (full, partial, etc) in it. It does this hourly. Nightly, it reads all the registered mirrors' timestamps and determines which are keeping up to date and which aren't, and updates the web page accordingly.
Examples: http://www.delorie.com/pub/djgpp/mirror.ts http://djgpp.linux-mirror.org/mirror.ts
Thanks, it's good to know that you have a means to check up on mirrors. It does not solve the issue at hand for the "got to have it now" user; i.e. how long a delay from announcement of a released package until it propagates to a given mirror.
Kam Leo:
- Select a more responsive [in terms of syncing]
mirror. [One can use the fastestmirror plugin
Tim:
Does the fastest mirror plugin also check for updatedness? I hadn't heard that, before.
Kam Leo:
You, of course, would read my reply out of context. I do not recommend using the fastestmirror plugin. I recommended using a fast mirror.
I read the whole thing. Perhaps you didn't write it very coherently, in the first place. Your prior message said, in whole:
That would not fix his problem. Antonio knows a specific set of packages exits; however, the repository used by yum lagged behind his awareness. The fix is actually simple: 1) Do not use a random miror via the mirrorlist. 2) Select a more responsive [in terms of syncing] mirror. [One can use the fastestmirror plugin, but I prefer selecting my own from http://mirrors.fedoraproject.org/publiclist/Fedora/7/ ] And/or 3) Use multiple mirrors for updates.
What you wrote reads as:
That would not fix his problem. Antonio knows a specific set of packages exits; however, the repository used by yum lagged behind his awareness. The fix is actually simple:
- Do not use a random miror via the mirrorlist.
- Select a more responsive [in terms of syncing] mirror. [One can use
the fastestmirror plugin, but I prefer selecting my own from http://mirrors.fedoraproject.org/publiclist/Fedora/7/ ]
And/or 3) Use multiple mirrors for updates.
Now tell me why point two doesn't suggest why the two things aren't related? It looks exactly like you're suggesting the fastest mirror plugin goes along with resolving a syncing problem.
That was why I asked if it did more than one thing.
This is a generality, YMMV: My experience is that the faster mirrors; that is, those with high bandwidth, tend to have more resources available and, thus, sync to the Fedora servers on a dependable schedule. Find a fast mirror that does not lag too far from the main Fedora servers and you can be assured that eventually your system will able to get released updates.
To me, a fast mirror is just one with good bandwidth between myself and it, it doesn't automatically mean anything else.