On 23 November 2017 at 01:28, Nir Soffer <nsoffer@redhat.com> wrote:
On Thu, Nov 23, 2017 at 12:36 AM Barak Korren <bkorren@redhat.com> wrote:
On 22 November 2017 at 20:50, Nir Soffer <nsoffer@redhat.com> wrote:
Vdsm should be ready now for fc27 and fcraw builds: https://gerrit.ovirt.org/#/c/84368/
How was this verified?
Piotr, can you add more info about this?
Can we enable the builds again?
I'd rather make sure we have proper verification so we don't end up blocking the development again.... I'd would have been great if you'd let us temporarily enable the jobs before merging that patch so we could let them run on it to verify.
I enabled the fc27 project temporarily, and it still fails when building https://gerrit.ovirt.org/#/c/84368/ trying to import ovirt_imageio_common.
The package is specified in the packages file:
$ git grep ovirt-imageio-common automation/*.packages.fc27 automation/check-patch.packages.fc27:ovirt-imageio-common
We use these repos: $ cat automation/check-patch.repos.fc27 tested,http://resources.ovirt.org/repos/ovirt/tested/master/rpm/$distro virt-preview,http://fedorapeople.org/groups/virt/virt-preview/fedora-$releasever/$basearc...
I'm not sure how trustworthy is $releasever when used by mock ($distro works because our wrapper script takes care of that). I'f you have mock runner already running locally with this configuration. please take a look at what you get in /etc/dnf/dnf.conf when you shell into it and ensure we don't end up having the host release in $releasever
The package exists: http://resources.ovirt.org/repos/ovirt/tested/master/rpm/fc27/noarch/ovirt-i...
repoquery is happy: $ repoquery --repofrompath=r,http://resources.ovirt.org/repos/ovirt/tested/master/rpm/fc27 --repoid=r list ovirt-imageio-common ovirt-imageio-common-0:1.2.0-0.201711212128.git9926984.fc27.noarch
Maybe mock caching issue?
00:00:28.127 Using chroot cache = /var/cache/mock/fedora-27-x86_64-a9934b467f29c7317f7dd8f205d66ddd 00:00:28.127 Using chroot dir = /var/lib/mock/fedora-27-x86_64-a9934b467f29c7317f7dd8f205d66ddd-7425
No. This just tells you where the cache would be, not if its actually there already. But yeah, this run actually did use a cached chroot: 00:00:28.767 Start: unpacking root cache 00:01:01.624 Finish: unpacking root cache I cleaned it from the node and retriggerd, lets see what happens now: http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc27-x86_64/85/console -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted