Bug 107316 - up2date won't download noarch yup repo items
Summary: up2date won't download noarch yup repo items
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: up2date (Show other bugs)
(Show other bugs)
Version: 1.0
Hardware: i686 Linux
Target Milestone: ---
Assignee: Adrian Likins
QA Contact: Fanny Augustin
Depends On:
Blocks: CambridgeBlocker
TreeView+ depends on / blocked
Reported: 2003-10-16 20:22 UTC by Alan Schmidt
Modified: 2014-01-21 22:48 UTC (History)
4 users (show)

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

Attachments (Terms of Use)

Description Alan Schmidt 2003-10-16 20:22:08 UTC
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):

How reproducible:

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-19 02:47:19 UTC
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 17:59:27 UTC
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.


...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 07:07:33 UTC
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 17:39:46 UTC
still a problem in what versions? 

Comment 5 Adrian Likins 2003-10-27 17:41:43 UTC
this is more of a yum-arch and mirrors bug than an up2date bug...

Comment 6 Seth Vidal 2003-10-27 17:45:14 UTC
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 17:52:32 UTC
>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 8 Alan Schmidt 2003-10-27 18:03:21 UTC
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.