Hide Forgot
Description of problem: It seems that the metadata_expire is not reflected. According to documentation, the default timeout should be 48h, but using dnf with mock, the metadate are refreshed almost always (there doesn't look to be any pattern, sometimes they are refreshed and the other time they are not). Changing the configuration option in mock config does not look to have any influence. Moreover, I'd say that the value of 0 used to mean don't expire the metadata, now it seems that -1 should provide the same service (but it does not). Version-Release number of selected component (if applicable): $ rpm -q dnf dnf-2.0.0-2.fc26.noarch How reproducible: Steps to Reproduce: 1. $ mock -r fedora-rawhide-x86_64 rubygem-multi_xml-0.6.0-1.fc26.src.rpm -n 2. 3. Actual results: The metadata are refreshed every now and then. Expected results: The metadata are not refreshed until 48h passed. The metadata_expire should allow to control the timeout. Additional info:
Are you building packages again from the same buildroot for the same architecture, distro and release? It works for me: 1) dnf download --source rubygem-multi_xml 2) dnf download --source acpi 3) mock -r fedora-rawhide-x86_64 rubygem-multi_xml-0.5.5-4.fc24.src.rpm -n 4) mock -r fedora-rawhide-x86_64 acpi-1.7-5.fc24.src.rpm -n Step 4 runs blazingly fast.
I am building still the same package. And I typically develop on such package, so for me it is more like: 1) fedpkg srpm 2) mock -r fedora-rawhide-x86_64 rubygem-multi_xml-0.5.5-4.fc24.src.rpm -n 3) fedpkg srpm 4) mock -r fedora-rawhide-x86_64 rubygem-multi_xml-0.5.5-4.fc24.src.rpm -n But of course there is typically some adjustment of the package in between, so there might be some delays such as 1 minute between builds. And yes, sometimes the cache is not refreshed and sometimes it is. I can't see any pattern in the behavior. BTW I have enable the "local" repository if that makes any difference.
With jsilhan, we tried some test and did not find any reason why this should happen. We were not able to reproduce this outside of mock, while it was reproducible in mock. So this might be some change in mock. Changing the component ...
It happen for me (on F25) with just pure DNF. The fedora repo is NOT downloaded again, but the "local" repo is downloaded always again. [msuchy@dri/~/projects/mock{devel}]$ sudo '/usr/bin/dnf' '--installroot' '/var/lib/mock/fedora-rawhide-x86_64/root/' '--releasever' '26' '--disableplugin=local' '--setopt=deltarpm=false' 'install' '@buildsys-build' local 398 kB/s | 48 MB 02:03 Poslední kontrola metadat: před 0:01:09, Tue Jan 17 09:10:25 2017. Skupina 'Skupina nástrojů pro tvorbu (balíčků) systému' je již nainstalována, přeskakuji. Závislosti vyřešeny. Není co dělat Hotovo! [msuchy@dri/~/projects/mock{devel}]$ sudo '/usr/bin/dnf' '--installroot' '/var/lib/mock/fedora-rawhide-x86_64/root/' '--releasever' '26' '--disableplugin=local' '--setopt=deltarpm=false' 'install' '@buildsys-build' local 559 kB/s | 48 MB 01:27 Poslední kontrola metadat: před 0:01:00, Tue Jan 17 09:13:14 2017. Skupina 'Skupina nástrojů pro tvorbu (balíčků) systému' je již nainstalována, přeskakuji. Závislosti vyřešeny. Není co dělat Hotovo! [msuchy@dri/~/projects/mock{devel}]$ rpm -q dnf dnf-1.1.10-4.fc25.noarch
Well, it was reported on DNF-2.0 and mock-1.3.3. we will examine DNF-2.0 again with local repo enabled with steps in comment 4.
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
Please Miroslav, can you reproduce it with dnf-2.5.1? I tried it on my Fedora 25, but with something close to upstream version of dnf(2.5.1), but I was unable to reproduce the issue. Believe that you can have another setting. Thanks a lot.
What is the relation to bug 1293910?
I agree with Vit that this is likely dupe of 1293910. And with enabled local and metadata_expire=0 I do not see any additional downloads. *** This bug has been marked as a duplicate of bug 1293910 ***