Description of problem: Copr build tries to use packages from builds that were already done within that copr project, even though I have createrepo disabled and I never run it, so it shouldn't see the packages at all. At least that's my understanding of the errors I'm observing. All of the builds (except the first ones in given copr) fail with: DEBUG util.py:421: Running transaction check DEBUG util.py:421: [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' Observed on copr-dev, using custom-1 chroot
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 ***