On 23 November 2017 at 01:28, Nir Soffer <nsoffer(a)redhat.com> wrote:
On Thu, Nov 23, 2017 at 12:36 AM Barak Korren <bkorren(a)redhat.com> wrote:
>
> On 22 November 2017 at 20:50, Nir Soffer <nsoffer(a)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-$rel...
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/ovir...
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