<br>Dammit. Stupid gmail default reply-to options. Sending this to the actual list.<br><br>---------- Forwarded message ----------<br><span class="gmail_quote">From: <b class="gmail_sendername">Greg DeKoenigsberg</b> <
<a href="mailto:greg.dekoenigsberg@gmail.com">greg.dekoenigsberg@gmail.com</a>><br>Date: Aug 3, 2007 12:56 PM<br>Subject: Re: [PlanetCCRMA] Package does not match intended download (planetccrma-core on F7)<br>To: Wade Nelson <
<a href="mailto:hollywoodb@fastmail.fm">hollywoodb@fastmail.fm</a>><br><br></span>So I just had a long chat with Seth Vidal, yum maintainer, and we walked through some stuff.<br><br>Basically, every shred of evidence points to a transparent proxy storing files somewhere between the client and the repo in question. Period. And it's likely that the proxy isn't respecting the various "nocache" options, since that's what urlgrabber (the download client for yum) specifies.
<br><br>I wonder if there are strategems to defeat these kinds of caches? Subtly changing the URL by adding query string junk to the end, maybe? I suppose it's worth a shot. Next time I run into one of these errors, I'll try that.
<br><span class="sg"><br>--g</span><div><span class="e" id="q_1142ca7f204f4f40_2"><br><br><div><span class="gmail_quote">On 8/3/07, <b class="gmail_sendername">Greg DeKoenigsberg</b> <<a href="mailto:greg.dekoenigsberg@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
greg.dekoenigsberg@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<span>On 8/3/07, <b class="gmail_sendername">Wade Nelson</b> <<a href="mailto:hollywoodb@fastmail.fm" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">hollywoodb@fastmail.fm</a>> wrote:
</span><div><span><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The thing that strikes me as odd is that I can consistently fail those<br>two packages with the exact same MD5 sum bail-out. I live in a rural<br>area and happen to know my ISP very well, and there is no caching<br>involved. In fact, the error posted has been consistent now for about
<br>10 days, and just now I posted to the ML since between myself and my ISP<br>I had determined that nothing on our end should be acting up. In the<br>example posted I ran a `wget` on the packages (which reported they were
<br>already downloaded, because they were) and got the *exact* same cpio MD5<br>bail-out. I've subsequently rm'd the RPMs and `wget`'d them again with<br>the exact same MD5 bail-out. It just strikes me as very very odd.
</blockquote></span><div><br>Yep, I'm the guy who got the same errors.<br><br>I'm starting to wonder if it's a funky RPM/yum bug in FC6.<br><br>--hank<br> </div><br></div><br>
</blockquote></div><br>
</span></div>