Bug 107316 - up2date won't download noarch yup repo items
up2date won't download noarch yup repo items
Status: CLOSED CURRENTRELEASE
Product: Red Hat Raw Hide
Classification: Retired
Component: up2date (Show other bugs)
1.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Adrian Likins
Fanny Augustin
:
Depends On:
Blocks: CambridgeBlocker
  Show dependency treegraph
 
Reported: 2003-10-16 16:22 EDT by Alan Schmidt
Modified: 2014-01-21 17:48 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-10-23 13:59:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Alan Schmidt 2003-10-16 16:22:08 EDT
Description of problem:
With no up2date repos active, using either an http or ftp yum repository on an
i686 system, up2date will just sit there on the first noarch package it tries to
download, until you hit cancel.

Version-Release number of selected component (if applicable):
4.1.7

How reproducible:
Always

Steps to Reproduce:
1. Comment out "up2date default" in /etc/sysconfig/rhn/sources.
2. Un-comment yum rawhide http://ftp.redhat.com/pub/redhat/linux/rawhide
3. Run up2date in graphical mode
4. Choose an update containing a noarch package.
5. Wait...
    
Actual results:
Up2date stops processing while displaying a message that is downloading
a noarch package. The "cancel" button works, so it is responsive.

Expected results:
The noarch package should be downloaded just like the i386 and i686 packages are.

Additional info:
Comment 1 William Hooper 2003-10-18 22:47:19 EDT
Me Too...

Using text mode, up2date gets stuck on solving dependencies.  Attaching strace
shows up2date doing something with the header files.  I waited and it went
through all the headers twice and was starting a third time.  Trying

# up2date redhat-config-samba
Comment 2 Alan Schmidt 2003-10-23 13:59:27 EDT
It turns out this is somewhat misreported. I'm not using redhat.com, but a
mirror. The catch is that the mirror is only mirroring the i386 portion of the
distribution. The problem seems to be that the noarch packages aren't being
pulled from the i386 part, but from s390x.

I added a "print url" to fetchUrl in urlUtils.py. You know, for laughs.  What I
got was the following.

http://mirror.hiwaay.net/redhat/redhat/linux/rawhide//headers/header.info
http://mirror.hiwaay.net/redhat/redhat/linux/rawhide//s390x/Fedora/RPMS/htmlview-2.0.0-11.noarch.rpm

...plus the traceback, ending with HTTP Error 404: Not Found.

The gui still sits there idle. I'm not smart enough to figure out why.
Comment 3 John Thacker 2003-10-26 02:07:33 EST
Why is this closed?  This is still a problem-- noarch packages up2date tries to
download from the s390x directory on ix86 machines, even when there's nothing in
the directory, and the packages are present in the i386 directory in the repository.

On repositories which don't mirror the s390x architecture, up2date still fails,
though it won't hang.  Now it just reports the 404.

It should download the noarch packages from the same directory used to download
the other packages.
Comment 4 Adrian Likins 2003-10-27 12:39:46 EST
still a problem in what versions? 

Comment 5 Adrian Likins 2003-10-27 12:41:43 EST
this is more of a yum-arch and mirrors bug than an up2date bug...
Comment 6 Seth Vidal 2003-10-27 12:45:14 EST
Rawhide's configuration of all architectures in one repo is dumb.

If someone doesn't mirror the whole thing how should yum-arch know about it?
Comment 7 Adrian Likins 2003-10-27 12:52:32 EST
>Rawhide's configuration of all architectures in one repo is dumb.

>If someone doesn't mirror the whole thing how should yum-arch know about it?

Agreed. 
Comment 8 Alan Schmidt 2003-10-27 13:03:21 EST
When I reported this particular bug, I was confounded by the fact that the
up2date GUI was just sitting there when it hit certain packages. I was stumped.

I was, of course, launching the GUI from a Gnome menu, so the 404 error written
to the terminal was never displayed.

I think the up2date GUI should still capture the 404 error and produce some kind
of message (death/continue/whatever).

I can accept the fact that this is not a bug per se, but it would be nice if
this were left open as a feature request.

Note You need to log in before you can comment on or make changes to this bug.