bogus rawhide entries?? (desktop-backgrounds-basic 2.0.17)

[Vanco, Don]

Andre Robatino wrote:
>> Is this the same issue that others have seen with up2date pulling
>> (well, attempting to pull) rawhide files that no longer exist???
>> 
>> [root at localhost up2date]# rpm -Fvh desktop-backgrounds-*
>> error: open of <!DOCTYPE failed: No such file or directory
>> error: open of HTML failed: No such file or directory
>> error: open of PUBLIC failed: No such file or directory
>> 
>> 	....the problematic file was actually
>> desktop-backgrounds-basic-2.0.17.noarch.rpm  Worthy of Bugzilla?
>> 
>> Don
> 
>   I had the same problem with 5 files - control-center, the two
> desktop-background RPMs, indexhtml, and yum.  In each case, up2date
> says that the package is signed with an untrusted GPG signature (as
> opposed to the "normal" error message that it is unsigned), and if
> you look in /var/spool/up2date you find that the file is actually a
> 5896-byte HTML file containing a 404 error.  When this happens I
> clean out /var/spool/up2date and try to grab a few at a time, then
> grab the rest manually 
> from the FTP
> site.  I don't know whether up2date's willingness to download
> an HTML file
> should be considered a bug in up2date or in bad server maintenance. 
> Don't RPM files have a magic number or something that up2date could
> use to avoid
> downloading the 404 file?

Yeah - downloading via up2date shows all the above (as well as packages for
kernel-2.4.22-1.2115) as being zero length and belonging to the
"fedora-core-1" channel.  I'm guessing they're bogus entries.

Doesn't matter what you do to the contents of /var/spool/up2date - these
still show as zero length, and (when they do download) they're bogus.
Should it be assumed that this is just part of the prep for the
"fedora-core-1" release??

Don