Daniel Belenky <dbelenky@redhat.com> writes:

> The same test is working in the experimental flow, so looks like a local
> issue.
> Are you using the most up to date master branch of ost?

Yes, the latest version from git.

> On Tue, Jun 27, 2017 at 1:58 PM, Milan Zamazal <mzamazal@redhat.com> wrote:
>
>> I tried to run OST on current basic-suite-master and it fails in
>> 000_check_repo_closure.  Is it only my local problem or is there
>> something broken?  How can I get OST running again?
>>
>> ## Params: ['repoclosure', '-t', '--config=/home/pdm/ovirt/
>> lago/ovirt-system-tests/basic-suite-master/reposync-config.repo_repoclosure',
>> '--lookaside=ovirt-master-tested-el7', '--lookaside=ovirt-master-snapshot-static-el7',
>> '--lookaside=glusterfs-3.10-el7', '--lookaside=centos-updates-el7',
>> '--lookaside=centos-base-el7', '--lookaside=centos-extras-el7',
>> '--lookaside=epel-el7', '--lookaside=centos-ovirt-4.0-el7',
>> '--lookaside=centos-kvm-common-el7', '--lookaside=centos-opstools-testing-el7',
>> '--lookaside=copr-sac-gdeploy-el7', '--repoid=internal_repo'].
>> ## Exist status: 1
>> ## Output: Reading in repository metadata - please wait....
>> Checking Dependencies
>> Repos looked at: 12
>>    centos-base-el7
>>    centos-extras-el7
>>    centos-kvm-common-el7
>>    centos-opstools-testing-el7
>>    centos-ovirt-4.0-el7
>>    centos-updates-el7
>>    copr-sac-gdeploy-el7
>>    epel-el7
>>    glusterfs-3.10-el7
>>    internal_repo
>>    ovirt-master-snapshot-static-el7
>>    ovirt-master-tested-el7
>> Num Packages in Repos: 37128
>> package: cockpit-ostree-138-1.el7.x86_64 from internal_repo
>>   unresolved deps:
>>      /usr/libexec/rpm-ostreed
>> package: python2-botocore-1.4.43-1.el7.noarch from internal_repo
>>   unresolved deps:
>>      python-dateutil >= 0:2.1
>>
>> Thanks,
>> Milan
>> _______________________________________________
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>