Bug 244567 - mock complains about local repository
mock complains about local repository
Status: CLOSED UPSTREAM
Product: Fedora Hosted Projects
Classification: Retired
Component: mock (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: David Cantrell
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-17 08:40 EDT by Philippe Valembois
Modified: 2013-01-09 23:21 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-06-27 08:50:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Philippe Valembois 2007-06-17 08:40:56 EDT
Description of problem:
mock times out when trying to connect to "local" repository

Version-Release number of selected component (if applicable):
mock-0.7.1-1.fc7

How reproducible:
Always

Steps to Reproduce:
1. mock a package with --debug option
2.
3.
  
Actual results:
Sometimes work with timeout errors
Sometimes complains about useradd

Expected results:
Should work without any error

Additional info:
I am not a contributor on Koji

Error message is :
DEBUG: Executing timeout(0): /usr/sbin/mock-helper yum --installroot
/var/lib/mock/fedora-7-i386/root update
http://koji.fedoraproject.org/static-repos/dist-fc7-build-current/i386/repodata/primary.xml.gz:
[Errno 4] Socket Error: timed out
Trying other mirror.
Error: failure: repodata/primary.xml.gz from local: [Errno 256] No more mirrors
to try.
Comment 1 Jesse Keating 2007-06-17 20:26:20 EDT
I wonder if this is due to some settings on the http daemon on koji.fp.o.  I 
suspect that we could serve the came content out via a different machine (or 
machines) and this might get better.  Will investigate.
Comment 2 Jesse Keating 2007-06-25 10:27:10 EDT
Haven't located root cause of the timeouts yet, not related to content, server,
http server software/settings, NFS, nor xen.  May be networking infrastructure.

Also discovered bugs in yum/urlgrabber that are preventing urlgrabber from being
able to do retries which would make this problem (while still a problem) a bit
more manageable.  
Comment 3 Jesse Keating 2007-06-27 08:50:20 EDT
We tracked this down to firewall settings on the various hosts in the colo. 
Unfortunately these were default settings so perhaps something is busted in
iptables.  However we found a work around and things should work much nicer with
the static-repos.

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