Bug 1179530

Summary: Copr not picking up built dependency when attempting build
Product: [Community] Copr Reporter: Graeme Gillies <ggillies>
Component: backendAssignee: Miroslav Suchý <msuchy>
Status: CLOSED NOTABUG QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: nalimilan, peter, vgologuz
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1179713 (view as bug list) Environment:
Last Closed: 2015-05-29 15:26:19 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Graeme Gillies 2015-01-07 02:56:19 UTC
I'm trying to build a package for EPEL 7 which requires a higher version of a dependency shipped in centos 7. I built the dependency (in this case, rubygem-minitest) in the centos-7-epel chroot, then when I try to build my package which depends on it, it errors with unsatisfied dependency. In other words, my newer version of rubygem-minitest isn't getting picked up.

Look at

https://copr.fedoraproject.org/coprs/ggillies/openstack-operations/build/66329/

You can see I have built rubygem-minitest-5.3.1 in epel-7-x86_64

However when I attempt to build rubygem-rdoc

https://copr.fedoraproject.org/coprs/ggillies/openstack-operations/build/66480/

you can see the following error

Error: No Package found for rubygem(minitest) > 5

at

https://copr-be.cloud.fedoraproject.org/results/ggillies/openstack-operations/epel-7-x86_64/rubygem-rdoc-4.1.1-3.fc21/root.log

It's almost like the repository metadata isn't getting regenerated to pick up rubygem-minitest version 5.3.1?

Comment 1 Peter Czanik 2015-01-07 08:07:22 UTC
Ran into a similar problem with my syslog-ng repo. Looking at the logs at https://copr-be.cloud.fedoraproject.org/results/czanik/syslog-ng36/fedora-21-x86_64/syslog-ng-incubator-0.4.1-3.fc22/root.log I see, that:

DEBUG util.py:366:  https://copr-be.cloud.fedoraproject.org/results/czanik/syslog-ng36//fedora-21-x86_64/devel/repodata/repomd.xml: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found"

Note the "/devel/" in the path. In real life that directory does not exists. So copr can't download repo information and skips dealing with packages from the repo -->> dependencies are not met.

Comment 2 Miroslav Suchý 2015-01-07 11:45:33 UTC
I see now:
rubygem-minitest.noarch                                      5.3.1-2.el7.centos                                       ggillies-openstack-operations

we had yesterday problem with severals files with incorect ownership, which resulted in not updating repo metadata.

This should be now fixed.

Comment 3 Milan Bouchet-Valat 2015-05-07 06:43:40 UTC
Reopening, as I see the same error here, see https://copr-be.cloud.fedoraproject.org/results/nalimilan/julia-nightlies/fedora-rawhide-x86_64/julia-0.4.0-0.20150505.fc21/root.log

DEBUG util.py:388:  https://copr-be.cloud.fedoraproject.org/results/nalimilan/julia-nightlies/fedora-rawhide-x86_64/devel/repodata/repomd.xml: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found"

Comment 4 Valentin Gologuzov 2015-05-29 15:26:19 UTC
Please ignore lines like:
DEBUG util.py:388:  https://copr-be.cloud.fedoraproject.org/results/.../devel/repodata/repomd.xml: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found"
unless you have set option "Disable automatic repository meta data generation".

It's expected behaviour, even if it is quite misleading. If you still have problems with missing dependencies please fill new issue with id of failed.