Bug 1394294
Summary: | DNF cannot download packages from Copr | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Michael Simacek <msimacek> |
Component: | dnf | Assignee: | rpm-software-management |
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | high | ||
Version: | 24 | CC: | clime, mluscon, msimacek, msuchy, packaging-team-maint, pnemade, rpm-software-management, vmukhame |
Target Milestone: | --- | Keywords: | Triaged |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-11-24 10:15:04 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
Michael Simacek
2016-11-11 15:21:08 UTC
I think there are actually two problems. One is that 'disable_createrepo' functionality is confusingly named. Repodata are still generated even with this option 'on' but they are created inside 'devel' subdirectory of a chroot. The devel data, which reference the latest versions of the packages, are employed during builds (the repo is added into yum.conf by mockchain) but end users will get only older (stable) versions of the packages because their yum configs contain url of the chroot and not url of the devel directory. The 'No such file or directory' error is likely specific to dnf. I don't want to guess now what might be the problem but this pastebin shows that yum-deprecated can install the jetty-start package without problems: http://paste.fedoraproject.org/478017/14788862/. (In reply to clime from comment #1) > functionality is confusingly named. Repodata are still generated even with > this option 'on' but they are created inside 'devel' subdirectory of a > chroot. The devel data, which reference the latest versions of the packages, > are employed during builds (the repo is added into yum.conf by mockchain) > but end users will get only older (stable) versions of the packages because > their yum configs contain url of the chroot and not url of the devel > directory. Right. This is intended for largge projects (like GNOME) when you need to rebuild a lot of packages, but you want to hide the rebuilds for users till all packages are rebuild (which can take days or weeks). I need to have a possibility to rebuild packages without previous builds affecting them - either by disabling this createrepo or omitting the repo from chroot configuration. What about making custom-2 chroot which doesn't point to it's own (devel) repo, but only the user supplied repos? So this is bug in DNF. Reproducer: $ dnf install --disablerepo=* --enablerepo='msimacek-koschei-1' jetty-start ... [Errno 2] No such file or directory: 'http://copr-be-dev.cloud.fedoraproject.org/results/msimacek/koschei-1/custom-1-x86_64/00272111-jetty/jetty-start-9.4.0-0.2.M0.fc26.noarch.rpm' $ yum-deprecated install --disablerepo=* --enablerepo='msimacek-koschei-1' jetty-start ... Complete! Hi guys, I guess this discrepancy is caused by differed metadata in yum and dnf since repo at https://copr.fedorainfracloud.org/coprs/msimacek/koschei/ currently does not contain jetty-start in its metadata. Could you please confirm it? Handing to Michal That's a different repo. The one with the problem is: http://copr-be-dev.cloud.fedoraproject.org/results/msimacek/koschei-1/custom-1-x86_64/devel/repodata/ It contains jetty-start and the location tag points at the correct rpm. The URL in dnf output (in the bug description) also points at the correct RPM. Since it fails with ENONENT (and not with http error) I think the problem is that it tries to open it as local file. I've just successfully installed jetty-start from koschei-1. Please provide your dnf.conf, .repo file and version of DNF. It's in copr-dev, I don't know how to get the configuration myself. Requesting copr maintainers to provide it. @msimacek I suppose you are using this repo file: http://copr-fe-dev.cloud.fedoraproject.org/coprs/msimacek/koschei-1/repo/custom-1/msimacek-koschei-1-custom-1.repo Additionally Michal is asking for your /etc/dnf/dnf.conf and version of dnf. @msuchy I reported a bug on copr - that I get copr build failures with valid copr configuration. My own dnf version and configuration is irrelevant, I'm not doing the builds, copr is. We need configuration that copr uses, which clime used to reproduce the bug with plain dnf (in comment #1). This is the repo file that was used in the paste (http://paste.fedoraproject.org/478017/14788862/): [msimacek-koschei-1] name=Copr repo for koschei-1 owned by msimacek baseurl=http://copr-be-dev.cloud.fedoraproject.org/results/msimacek/koschei-1/custom-1-$basearch/devel/ type=rpm-md skip_if_unavailable=True gpgcheck=0 gpgkey=http://copr-be-dev.cloud.fedoraproject.org/results/msimacek/koschei-1/pubkey.gpg repo_gpgcheck=0 enabled=1 enabled_metadata=1 This my dnf.conf: [main] gpgcheck=1 installonly_limit=3 clean_requirements_on_remove=True #exclude=copr-backend* copr-dist-git* copr-mocks* copr-frontend* Dnf version: Version : 1.1.9 Release : 2.fc24 Thank you for info. This is a duplicate of #1257965 fixed in dnf-1.1.10-1. *** This bug has been marked as a duplicate of bug 1257965 *** |