Bug 749211

Summary: Syncing a repo from Fedora ISO fails. Issue with relative path in ISO metadata
Product: [Retired] Grinder Reporter: John Matthews <jmatthew>
Component: coreAssignee: John Matthews <jmatthew>
Status: CLOSED EOL QA Contact: Preethi Thomas <pthomas>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecified   
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description John Matthews 2011-10-26 13:45:30 UTC 
Description of problem:

1) Download Fedora 14 x86_64 DVD iso
2) Open the ISO and expose it's content through apache
 Allow this path to work: 
 http://localhost/pub/isos/fuse/Fedora-14-x86_64-DVD.iso/
3) Verify wget of a package works.
4) Attempt a grinder fetch of the repo and it will fail.

I think the problem is that grinder looks at the metadata and sees the rpm is supposed to be at: "Packages/openoffice.org-langpack-mr_IN-3.3.0-9.3.fc14.x86_64.rpm"

It literally attempts to fetch the package from http://Packages/openoffice.org-langpack-mr_IN-3.3.0-9.3.fc14.x86_64.rpm

instead of prepending http://localhost/pub/isos/fuse/Fedora-14-x86_64-DVD.iso/ to the request.



Example logs below


10-25 17:03 grinder.WriteFunction DEBUG    File exists; offset at 0
10-25 17:03 grinder.BaseFetch INFO     Fetching 724900 bytes: openoffice.org-langpack-mr_IN-3.3.0-9.3.fc14.x86_64.rpm from Packages/openoffice.org-langpack-mr_IN-3.3.0-9.3.fc14.x86_64.rpm
10-25 17:03 grinder.WriteFunction DEBUG    File exists; offset at 0
10-25 17:03 grinder.WriteFunction DEBUG    File exists; offset at 0
10-25 17:03 grinder.WriteFunction DEBUG    File exists; offset at 0
10-25 17:03 grinder.BaseFetch INFO     Fetching 15708 bytes: libxkbfile-devel-1.0.6-2.fc13.x86_64.rpm from Packages/libxkbfile-devel-1.0.6-2.fc13.x86_64.rpm
10-25 17:03 grinder.BaseFetch INFO     Fetching 1358028 bytes: gnome-color-manager-2.32.0-2.fc14.x86_64.rpm from Packages/gnome-color-manager-2.32.0-2.fc14.x86_64.rpm
10-25 17:03 grinder.WriteFunction DEBUG    File exists; offset at 0
10-25 17:03 grinder.BaseFetch INFO     Fetching 37620 bytes: lm_sensors-libs-3.1.2-2.svn5857.fc14.x86_64.rpm from Packages/lm_sensors-libs-3.1.2-2.svn5857.fc14.x86_64.rpm
10-25 17:03 grinder.BaseFetch INFO     Fetching 52876 bytes: hyphen-nl-0.20050617-5.fc12.noarch.rpm from Packages/hyphen-nl-0.20050617-5.fc12.noarch.rpm
10-25 17:03 grinder.BaseFetch DEBUG    Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/grinder/BaseFetch.py", line 244, in fetch
    curl.perform()
error: (6, 'Could not resolve host: Packages; Cannot allocate memory')

10-25 17:03 grinder.BaseFetch ERROR    Caught exception<(6, 'Could not resolve host: Packages; Cannot allocate memory')> in fetch(openoffice.org-langpack-mr_IN-3.3.0-9.3.fc14.x86_64.rpm, Packages/openoffice.org-langpack-mr_IN-3.3.0-9.3.fc14.x86_64.rpm)
10-25 17:03 grinder.BaseFetch ERROR    Retrying fetch of: openoffice.org-langpack-mr_IN-3.3.0-9.3.fc14.x86_64.rpm with 1 retry attempts left.
10-25 17:03 grinder.GrinderLock DEBUG    A lock with pid [22947] already exists at [./test/Packages/openoffice.org-langpack-mr_IN-3.3.0-9.3.fc14.x86_64.rpm.lock]
10-25 17:03 grinder.WriteFunction DEBUG    File exists; offset at 0
10-25 17:03 grinder.BaseFetch INFO     Fetching 724900 bytes: openoffice.org-langpack-mr_IN-3.3.0-9.3.fc14.x86_64.rpm from Packages/openoffice.org-langpack-mr_IN-3.3.0-9.3.fc14.x86_64.rpm
10-25 17:03 grinder.BaseFetch DEBUG    Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/grinder/BaseFetch.py", line 244, in fetch
    curl.perform()
error: (6, 'Could not resolve host: Packages; Cannot allocate memory')
Comment 1 John Matthews 2011-10-26 13:46:40 UTC 
Looking at primary.xml from ISO which exhibits this problem:

<location xml:base="media://1287685820.403779" href="Packages/openoffice.org-langpack-mr_IN-3.3.0-9.3.fc14.x86_64.rpm"/>


Example of a metadata from a working repo:
<location href="9:kdevelop-libs-4.0.0-1.fc13.x86_64.rpm"/>
Comment 2 John Matthews 2011-10-26 13:49:13 UTC 
pkg objects from: self.repo.getPackageSack().returnPackages()

are returning with 'remote_url' populated to 'Packages/foo.rpm'.
Typically we would expect remote_url to be None, then we would prepend self.repo_url to pkg.relativepath

In YumInfo.py::__getRPMs():
  info['downloadurl'] = pkg.remote_url or self.repo_url + '/' + pkg.relativepath