-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
List,
I searched google for this error, but apparently I'm either lacking the necessary 1337 skillz, or you know I just am not gettin' a google friendly search put into it. The error is below.
[prata@crane ~]# sudo yum update Setting up Update Process Setting up Repos http://apt.sw.be/redhat/el4/en/i386/dag/repodata/repomd.xml: [Errno 4] IOError: HTTP Error 304: Not Modified Trying other mirror. Cannot open/read repomd.xml file for repository: dag failure: repodata/repomd.xml from dag: [Errno 256] No more mirrors to try.
Has anyone else received this error? Did I perhaps miss an announcement? I looked about the list, but nothing regarding this was apparent to me.
TIA
- -- Alex White prata@kuei-jin.org Fingerprint = 58DC 9199 CE73 74E8 B2C1 442E ACF5 92E0 E068 C46C gpg key location: http://www.kuei-jin.org/GPG-KEY-PRATA ~From the withered tree, a flower blooms --Zen Proverb
On Tuesday 10 May 2005 10:47, Alex White wrote:
I searched google for this error, but apparently I'm either lacking the necessary 1337 skillz, or you know I just am not gettin' a google friendly search put into it. The error is below. [prata@crane ~]# sudo yum update Setting up Update Process Setting up Repos http://apt.sw.be/redhat/el4/en/i386/dag/repodata/repomd.xml: [Errno 4] IOError: HTTP Error 304: Not Modified Trying other mirror. Cannot open/read repomd.xml file for repository: dag failure: repodata/repomd.xml from dag: [Errno 256] No more mirrors to try.
You're not alone, and I'm quite disappointed that it blows Yum completely out of the water. That particular error seems to be causing a problem with the apt repo as well; something more basic is at fault here. Dag?
On Tue, 10 May 2005, Lamar Owen wrote:
On Tuesday 10 May 2005 10:47, Alex White wrote:
I searched google for this error, but apparently I'm either lacking the necessary 1337 skillz, or you know I just am not gettin' a google friendly search put into it. The error is below. [prata@crane ~]# sudo yum update Setting up Update Process Setting up Repos http://apt.sw.be/redhat/el4/en/i386/dag/repodata/repomd.xml: [Errno 4] IOError: HTTP Error 304: Not Modified Trying other mirror. Cannot open/read repomd.xml file for repository: dag failure: repodata/repomd.xml from dag: [Errno 256] No more mirrors to try.
You're not alone, and I'm quite disappointed that it blows Yum completely out of the water. That particular error seems to be causing a problem with the apt repo as well; something more basic is at fault here. Dag?
Well, we've had our share of problems the last couple of days. I just got confirmation of Heanet (which is the main mirror apt.sw.be is pointing to).
This is what they answered:
> 3. Webserver problems (a few days) > Apparently since a few days an additional problem popped up, where > some people get (random?) 304 Not Modified messages. This might be > related to the fact that Heanet recently switched to an unstable > Apache version. > > http://toolbar.netcraft.com/site_report?url=http://apt.sw.be > > Now it seems to be running Apache/2.1.5-dev (Unix) Confirmed, I'm testing it out for a few days. Mainly to find bugs such as this. HEAnet participates in the Apache development effort, and we ocasionally run such tests - to identify bugs and benchmark new features (right now I'm testing mod_disk_cache). I'll probably revert tomorrow if there's a bug like this effecting people (full HTTP dumps of a relevant case will speed this up, so that I can reproduce it.)
It's nice they help out the Apache project this way, but at what expense ? So I'm wondering what to do next to avoid things like this.
More information about the recent problems:
http://lists.freshrpms.net/pipermail/freshrpms-list/2005-May/013024.html http://lists.freshrpms.net/pipermail/freshrpms-list/2005-May/013066.html
Any feedback is welcome, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Tuesday 10 May 2005 14:46, Dag Wieers wrote:
It's nice they help out the Apache project this way, but at what expense ? So I'm wondering what to do next to avoid things like this.
I for one have switched to www.mirrorservice.org's mirror, which seems to be working OK at this point.
My complaint isn't as much with the repository as it's with yum itself for blowing chunks and completely failing.
FWIW, when I update with synaptic I get a warning about the one repo being down but I get an update from the others just fine and can go ahead and upgrade from the loaded repos and wait until the ailing repo has things fixed. I wonder if yum can be configured to do similar; I for one track kde-redhat, the various centos.org mirrored repos as well as apt.sw.be; there have been times that either the kde-redhat main repo or apt.sw.be have been down for several hours, during which a yum-driven autoupdate dies, but an apt one can cope.
More than likely yum can be taught to do such, I just haven't yet done it.
On 5/10/05, Lamar Owen lowen@pari.edu wrote:
My complaint isn't as much with the repository as it's with yum itself for blowing chunks and completely failing.
You may have better luck discussing this on the yum-devel list. I know Seth reads this list, but not everyone working on yum does and I also know that Seth has been busy recently and may not ready every single post to CentOS.
In fact, there is a discussion on this topic already:
https://lists.dulug.duke.edu/pipermail/yum-devel/2005-May/thread.html#1140
Seth has responded with some reasons why simply noting that a repo is down and moving on isn't a good idea. I'm not familiar enough to say whether or not his reasoning makes sense, but I generally do respect his opinion.
Regards, Greg
On Tue, 2005-05-10 at 13:14 -0600, Greg Knaddison wrote:
On 5/10/05, Lamar Owen lowen@pari.edu wrote:
My complaint isn't as much with the repository as it's with yum itself for blowing chunks and completely failing.
The problem isn't yum ... it is the 304 status code from apache
You may have better luck discussing this on the yum-devel list. I know Seth reads this list, but not everyone working on yum does and I also know that Seth has been busy recently and may not ready every single post to CentOS.
In fact, there is a discussion on this topic already:
https://lists.dulug.duke.edu/pipermail/yum-devel/2005-May/thread.html#1140
Seth has responded with some reasons why simply noting that a repo is down and moving on isn't a good idea. I'm not familiar enough to say whether or not his reasoning makes sense, but I generally do respect his opinion.
I agree with Seth on this one ... if one repo doesn't work, you could get software installed from a repo where you don't expect it to come from. So I think it is perfectly reasonable to require manual intervention if something is broken.
yum --disablerepo {reponame} update
(or install, upgrade, groupinstall)
works fine and will work for a temporary issue
On Tue, 10 May 2005, Johnny Hughes wrote:
On Tue, 2005-05-10 at 13:14 -0600, Greg Knaddison wrote:
On 5/10/05, Lamar Owen lowen@pari.edu wrote:
My complaint isn't as much with the repository as it's with yum itself for blowing chunks and completely failing.
The problem isn't yum ... it is the 304 status code from apache
It's more like how Yum handles the situation.
You may have better luck discussing this on the yum-devel list. I know Seth reads this list, but not everyone working on yum does and I also know that Seth has been busy recently and may not ready every single post to CentOS.
In fact, there is a discussion on this topic already:
https://lists.dulug.duke.edu/pipermail/yum-devel/2005-May/thread.html#1140
Seth has responded with some reasons why simply noting that a repo is down and moving on isn't a good idea. I'm not familiar enough to say whether or not his reasoning makes sense, but I generally do respect his opinion.
I agree with Seth on this one ... if one repo doesn't work, you could get software installed from a repo where you don't expect it to come from. So I think it is perfectly reasonable to require manual intervention if something is broken.
Well, if you expect software to come from a designated repository (or not from certain other repositories). You should pin that software altogether to a repository.
Bailing out on every single error like this is a real problem. Not only in this case, but there are many other cases where Yum bails out where it doesn't have to.
BTW why not leave it up to the user to decide what to do, you're asking for a confirmation anyway, so let him decide without breaking the user's normal execution path.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Tuesday 10 May 2005 15:45, Johnny Hughes wrote:
On Tue, 2005-05-10 at 13:14 -0600, Greg Knaddison wrote:
On 5/10/05, Lamar Owen lowen@pari.edu wrote:
My complaint isn't as much with the repository as it's with yum itself for blowing chunks and completely failing.
The problem isn't yum ... it is the 304 status code from apache
Well, one can argue semantics, but it takes two to tango. While apache shouldn't be sending that code, perhaps, yum is still responding to the code in an inappropriate manner (if the file hasn't changed, use the local copy, this being repomd.xml we're talking about).
In fact, there is a discussion on this topic already: https://lists.dulug.duke.edu/pipermail/yum-devel/2005-May/thread.html#114
Already on too many mailing lists. Not another. I just finally got rid of my last Fedora Core box and have unsubscribed from the Fedora-list (and -test and -devel) quagmire. Cut my mailing volume significantly.
Seth has responded with some reasons why simply noting that a repo is down and moving on isn't a good idea. I'm not familiar enough to say whether or not his reasoning makes sense, but I generally do respect his opinion.
I agree with Seth on this one ... if one repo doesn't work, you could get software installed from a repo where you don't expect it to come from. So I think it is perfectly reasonable to require manual intervention if something is broken.
I've looked closely at the whole strawman of 'if one repo doesn't work, then you might get software installed from a repo where you don't expect it to come from' and found it full of holes. Unless your local repo (which is the common cause of this scenario) bumps epoch, your locally generated packages (or your preferred packages from other repos) can and will get overwritten and updated by other repos if those other repos deal in that package. And there is significant package overlap to be had: particularly in the case with kde-redhat.
Been there, done that, with mixing ATrpms, PlanetCCRMA, FreshRPMs, and DAG on Fedora Core 2: it was a rat race between the repositories: update, and DAG updates a package; update again and you got PlanetCCRMA's package; update a third time, ATrpms blows in; update the fourth time, and now Matthias' handiwork graces my disk. In many of these cases packages from one of the four repos had conflicts with the packages from one of the other: file conflicts, as in ATrpms had things packaged where the package owned a different set of files from the FreshRPMs package and the updated package from FreshRPMs can't install. I cleaned up manually so many times that it became ritual to clean the package cache before doing an update so that I could manually rpm -Uvh --force --nodeps afterward (after parsing the output of a straight rpm -Uvh, of course). This is using apt to perform the updates; I had too many issues with FC2's yum to continue using it. Not that apt was perfect, because it wasn't even close. But it was better than manually updating daily, that's for sure.
So I call that whole 'blindsided update' scenario a strawman: it can (and does) happen even if all your repositories are in working order; skipping a repository due to a repo failure somewhere has never caused me to have this problem, and I have done synaptic upgrades with skipped repos numerous times. This problem has indeed occurred for me, but always when ALL of my selected repositories are up and running normally.
The solution could be apt-style pinning. If I pin say fftw3 to be a local repo package, then when Dag updates his fftw3 package (before I have a chance to bump the version on my local copy) all my GNUradio code won't quit working: GNUradio requires a single-precision compile of fftw3, which is not the default. So I generated local packages for fftw3. If an update blows in, then it quits working. If I can tell yum (I CAN tell apt this already) to never update fftw3 from any other source than the local repo, I'm ok, otherwise I'm not. If the fftw3 package is pinned to local, then, even if the local repo is skipped due to error the Dag copy of fftw3 won't overwrite.
For those who run local modified repos this could be golden, and they would probably just want to blanket pin all local repo packages. Hmmm, to simplify things over the way apt deals with it, a repository directive 'My Packages Trump Your Packages Even If I Am Not Here' would be the ticket and prevent the strawman above from ever happening. Or a general 'repository priority' scheme where the admin can give repos priority and even pin a package down to only be updateable by that repo.
But yum was originally built to be a system UPDATER more than a general purpose system installer/package manager: it's now being used in a capacity for which it wasn't originally intended.
On 5/10/05, Lamar Owen lowen@pari.edu wrote:
On Tuesday 10 May 2005 15:45, Johnny Hughes wrote:
On Tue, 2005-05-10 at 13:14 -0600, Greg Knaddison wrote:
On 5/10/05, Lamar Owen lowen@pari.edu wrote:
My complaint isn't as much with the repository as it's with yum itself for blowing chunks and completely failing.
The problem isn't yum ... it is the 304 status code from apache
Well, one can argue semantics, but it takes two to tango. While apache shouldn't be sending that code, perhaps, yum is still responding to the code in an inappropriate manner (if the file hasn't changed, use the local copy, this being repomd.xml we're talking about).
So, to stay in your metaphor, if I go out on the dance floor and my partner steps on my foot because she can't tango, does that make it a flaw in my dance technique? No.
In fact, there is a discussion on this topic already: https://lists.dulug.duke.edu/pipermail/yum-devel/2005-May/thread.html#114
Already on too many mailing lists. Not another. I just finally got rid of my last Fedora Core box and have unsubscribed from the Fedora-list (and -test and -devel) quagmire. Cut my mailing volume significantly.
If you want to tilt at the windmills by all means, but if you want a meaningful response the place to get it is a yum mailing list.
I've looked closely at the whole strawman of 'if one repo doesn't work, then you might get software installed from a repo where you don't expect it to come from' and found it full of holes.
<snip lots of info>
You disagree with the maintainer. You seem to have strong opinions on this. Seems like it is time for you to find a new tool for the job or, if you really feel strong in your convictions to fork.
Greg
On Tuesday 10 May 2005 17:54, Greg Knaddison wrote:
On 5/10/05, Lamar Owen lowen@pari.edu wrote:
Well, one can argue semantics, but it takes two to tango.
So, to stay in your metaphor, if I go out on the dance floor and my partner steps on my foot because she can't tango, does that make it a flaw in my dance technique? No.
No, but if she steps on your foot, there's two reasons why: she can't dance, or you can't move your feet fast enough. Her misstep has two causes. In this case, yum is getting an RFC2616 compliant response code of 304 as an inappropriate response (after all, 304 is indicated only with a conditional GET and is intended to answer caching questions). Now, the question becomes how yum is doing its GET, and how yum responds to an unexpected 304, which just means Not Modified. The urlgrab routines apparently don't handle this for yum (it's open source; I read the source). Fixable with a little work, really.
If you want to tilt at the windmills by all means, but if you want a meaningful response the place to get it is a yum mailing list.
After having maintained the PostgreSQL RPMset for five years I think I know that. But I also know when to shed load; and adding another mailing list to my inbox and its folders is counterproductive when I pretty well know how the discussion will go, and when I respect Seth enough to not start up on the yum list right now. He has as much e-mail load as I do (1500+ e-mails per day or more is my current load; his is probably higher by a little, I would think).
I've looked closely at the whole strawman of 'if one repo doesn't work, then you might get software installed from a repo where you don't expect it to come from' and found it full of holes.
You disagree with the maintainer. You seem to have strong opinions on this. Seems like it is time for you to find a new tool for the job or, if you really feel strong in your convictions to fork.
As I said, I maintained the PostgreSQL RPM set for the PostgreSQL Global Development Group; my name is in the changelog in the CentOS 4 PostgreSQL RPM (rpm -qi --changelog postgresql for yourself). I have seen the results of the various packaging systems' issues up close and personal, and have been blamed for some of them. I have worked around bugs in RPM and other things; it isn't pleasant. So you're not telling me anything new or that I haven't thought about before.
Since I am actually paid to do my job, what I am able to do in the open source world reflects what I am doing in my work; thus, I am working on GNUradio, Zope, and Plone stuff right now instead of maintaining the PostgreSQL RPMs. Hmmm, yum is in python too....
So you might want to rethink your statement, as I'm not a freeloader open-source-wise. But I have to ask: fork yum, or fork CentOS? Why would I need to do either? Is a simple, low-grade disagreement enough to do something as counterproductive as fork something that works Pretty Well? This isn't Slashdot, after all.
I also use Apt at the moment; unfortunately apt for rpm is effectively not maintained anymore (as it's not really maintainable; the python code in yum is far more maintainable). There is smart available to replace the apt/synaptic duo. But open dialog about why there is an issue is good, I would think.
Push comes to shove I can do my own private version of yum, if I like, for my own uses.
On Tue, 2005-05-10 at 21:02, Lamar Owen wrote:
No, but if she steps on your foot, there's two reasons why: she can't dance, or you can't move your feet fast enough. Her misstep has two causes. In this case, yum is getting an RFC2616 compliant response code of 304 as an inappropriate response (after all, 304 is indicated only with a conditional GET and is intended to answer caching questions).
I don't think I've ever seen apache get that wrong, although it can be fooled by bad timestamps on the underlying files.
Now, the question becomes how yum is doing its GET, and how yum responds to an unexpected 304, which just means Not Modified. The urlgrab routines apparently don't handle this for yum (it's open source; I read the source). Fixable with a little work, really.
It makes perfect sense to do a conditional get if you already have a copy of something that is likely to be unchanged on the server.
On Tue, 10 May 2005, Greg Knaddison wrote:
On 5/10/05, Lamar Owen lowen@pari.edu wrote:
On Tuesday 10 May 2005 15:45, Johnny Hughes wrote:
The problem isn't yum ... it is the 304 status code from apache
Well, one can argue semantics, but it takes two to tango. While apache shouldn't be sending that code, perhaps, yum is still responding to the code in an inappropriate manner (if the file hasn't changed, use the local copy, this being repomd.xml we're talking about).
So, to stay in your metaphor, if I go out on the dance floor and my partner steps on my foot because she can't tango, does that make it a flaw in my dance technique? No.
That's not the point. If she steps on your foot, what do you do ? Do you slap her in the face, drop dead on the floor or gracefully handle the situation.
It depends how much you care for her, right ? :)
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Tue, 10 May 2005, Lamar Owen wrote:
On Tuesday 10 May 2005 14:46, Dag Wieers wrote:
It's nice they help out the Apache project this way, but at what expense ? So I'm wondering what to do next to avoid things like this.
I for one have switched to www.mirrorservice.org's mirror, which seems to be working OK at this point.
My complaint isn't as much with the repository as it's with yum itself for blowing chunks and completely failing.
Indeed. This is inherent to yum. I already complained about this in Yum's bugzilla and can only hope this will be fixed in a future release.
FWIW, when I update with synaptic I get a warning about the one repo being down but I get an update from the others just fine and can go ahead and upgrade from the loaded repos and wait until the ailing repo has things fixed. I wonder if yum can be configured to do similar; I for one track kde-redhat, the various centos.org mirrored repos as well as apt.sw.be; there have been times that either the kde-redhat main repo or apt.sw.be have been down for several hours, during which a yum-driven autoupdate dies, but an apt one can cope.
More than likely yum can be taught to do such, I just haven't yet done it.
Let me know if you find it. The only way to work-around is by disabling it and enable it whenever you require it. Which is the complete wrong approach being advertized as the right way to do it.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
I'm getting this as well.
Preston
On Tue, 2005-05-10 at 09:47 -0500, Alex White wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
List,
I searched google for this error, but apparently I'm either lacking the necessary 1337 skillz, or you know I just am not gettin' a google friendly search put into it. The error is below.
[prata@crane ~]# sudo yum update Setting up Update Process Setting up Repos http://apt.sw.be/redhat/el4/en/i386/dag/repodata/repomd.xml: [Errno 4] IOError: HTTP Error 304: Not Modified Trying other mirror. Cannot open/read repomd.xml file for repository: dag failure: repodata/repomd.xml from dag: [Errno 256] No more mirrors to try.
Has anyone else received this error? Did I perhaps miss an announcement? I looked about the list, but nothing regarding this was apparent to me.
TIA
Alex White prata@kuei-jin.org Fingerprint = 58DC 9199 CE73 74E8 B2C1 442E ACF5 92E0 E068 C46C gpg key location: http://www.kuei-jin.org/GPG-KEY-PRATA ~From the withered tree, a flower blooms --Zen Proverb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org
iD8DBQFCgMlwrPWS4OBoxGwRArUIAJ9Qr6ST5/9acQD6XwQoaZJ7lI8ztwCeK4pU ukvh3E6R1POrNkAkZRejjFg= =J5+I -----END PGP SIGNATURE----- _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Preston Crawford wrote:
I'm getting this as well.
Preston
On Tue, 2005-05-10 at 09:47 -0500, Alex White wrote:
List,
I searched google for this error, but apparently I'm either lacking the necessary 1337 skillz, or you know I just am not gettin' a google friendly search put into it. The error is below.
[prata@crane ~]# sudo yum update Setting up Update Process Setting up Repos http://apt.sw.be/redhat/el4/en/i386/dag/repodata/repomd.xml: [Errno 4] IOError: HTTP Error 304: Not Modified Trying other mirror. Cannot open/read repomd.xml file for repository: dag failure: repodata/repomd.xml from dag: [Errno 256] No more mirrors to try.
Has anyone else received this error? Did I perhaps miss an announcement? I looked about the list, but nothing regarding this was apparent to me.
This is a known issue, Dag is following up on this, more info at : http://lists.freshrpms.net/pipermail/freshrpms-list/2005-May/013024.html
Btw, the freshrpms.net list is broken too :)
- K
-- A: Maybe because some people are too annoyed by top-posting. Q: Why do I not get an answer to my question(s)? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Karanbir Singh wrote: | Preston Crawford wrote: | |>I'm getting this as well. |> |>Preston
<snip>
|>Has anyone else received this error? Did I perhaps miss an |>announcement? I looked about the list, but nothing regarding this |>was apparent to me. |> | | | This is a known issue, Dag is following up on this, more info at : | http://lists.freshrpms.net/pipermail/freshrpms-list/2005-May/013024.html | | Btw, the freshrpms.net list is broken too :) | | - K
I knew I was missing something! I need to subscribe to more lists..... ^_^
- -- Alex White prata@kuei-jin.org Fingerprint = 58DC 9199 CE73 74E8 B2C1 442E ACF5 92E0 E068 C46C gpg key location: http://www.kuei-jin.org/GPG-KEY-PRATA ~From the withered tree, a flower blooms --Zen Proverb
-
Alex White -
Dag Wieers -
Greg Knaddison -
Johnny Hughes -
Karanbir Singh -
Lamar Owen -
Les Mikesell -
Preston Crawford