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@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