Bug 749211 - Syncing a repo from Fedora ISO fails. Issue with relative path in ISO metadata
Summary: Syncing a repo from Fedora ISO fails. Issue with relative path in ISO metadata
Keywords:
Status: CLOSED EOL
Alias: None
Product: Grinder
Classification: Retired
Component: core
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: John Matthews
QA Contact: Preethi Thomas
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-10-26 13:45 UTC by John Matthews
Modified: 2020-03-27 18:04 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)

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


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