Fwd: [PlanetCCRMA] Package does not match intended download (planetccrma-core on F7)

Fri Aug 3 09:58:03 2007

------=_Part_107513_26047412.1186160240743
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Dammit.  Stupid gmail default reply-to options.  Sending this to the actual
list.

---------- Forwarded message ----------
From: Greg DeKoenigsberg <greg.dekoenigsberg@gmail.com>
Date: Aug 3, 2007 12:56 PM
Subject: Re: [PlanetCCRMA] Package does not match intended download
(planetccrma-core on F7)
To: Wade Nelson <hollywoodb@fastmail.fm>

So I just had a long chat with Seth Vidal, yum maintainer, and we walked
through some stuff.

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.

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.

--g

On 8/3/07, Greg DeKoenigsberg <greg.dekoenigsberg@gmail.com> wrote:
>
> On 8/3/07, Wade Nelson <hollywoodb@fastmail.fm> wrote:
> >
> > The thing that strikes me as odd is that I can consistently fail those
> > two packages with the exact same MD5 sum bail-out.  I live in a rural
> > area and happen to know my ISP very well, and there is no caching
> > involved.  In fact, the error posted has been consistent now for about
> > 10 days, and just now I posted to the ML since between myself and my ISP
> > I had determined that nothing on our end should be acting up.  In the
> > example posted I ran a `wget` on the packages (which reported they were
> > already downloaded, because they were) and got the *exact* same cpio MD5
> > bail-out.  I've subsequently rm'd the RPMs and `wget`'d them again with
> > the exact same MD5 bail-out.  It just strikes me as very very odd.
>
>
> Yep, I'm the guy who got the same errors.
>
> I'm starting to wonder if it's a funky RPM/yum bug in FC6.
>
> --hank
>
>
>
>

------=_Part_107513_26047412.1186160240743
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------=_Part_107513_26047412.1186160240743--