[ovirt-devel] [ACTION REQUIRED] vdsm_master_build-artifacts-fc23-x86_64 is failing due to missing dep on fc23 .packages

[Nir Soffer]

On Thu, Apr 14, 2016 at 1:19 PM, David Caro <dcaro at redhat.com> wrote:
> On 04/14 13:17, Nir Soffer wrote:
>> On Thu, Apr 14, 2016 at 12:55 PM, Vinzenz Feenstra <vfeenstr at redhat.com> wrote:
>> >
>> >> On Apr 14, 2016, at 11:52 AM, Nir Soffer <nsoffer at redhat.com> wrote:
>> >>
>> >> On Thu, Apr 14, 2016 at 12:23 PM, David Caro <dcaro at redhat.com> wrote:
>> >>> On 04/14 12:06, Dan Kenigsberg wrote:
>> >>>> On Thu, Apr 14, 2016 at 11:56:10AM +0300, Dan Kenigsberg wrote:
>> >>>>>
>> >>>>> I've added the package it check-patch.packages, but not to
>> >>>>> build-artifacts.packages. should be fixed in a minutes. Sorry.
>> >>>>
>> >>>> Actually, it's not that, as build-artifacts.packages is a softlink
>> >>>>
>> >>>>    build-artifacts.packages.fc23 -> check-merged.packages.fc23
>> >>>>
>> >>>> despite that,
>> >>>>
>> >>>> http://jenkins.ovirt.org/job/vdsm_master_build-artifacts-fc23-x86_64/823/consoleText
>> >>>>
>> >>>>    mock \
>> >>>>        --configdir="/home/jenkins/workspace/vdsm_master_build-artifacts-fc23-x86_64/vdsm" \
>> >>>>        --root="mocker-fedora-23-x86_64.fc23" \
>> >>>>        --install "autoconf automake git lago lago-ovirt libguestfs-tools-c m2crypto make mom policycoreutils-python pyflakes python-blivet python-coverage python-devel python-inotify python-ioprocess python-netaddr python-nose python-pep8 python-pthreading python-rtslib python-six python3-nose python3-six rpm-build sudo yum yum-utils grubby" \
>> >>>>        --resultdir="logs/mocker-fedora-23-x86_64.fc23.install_packages"
>> >>>>
>> >>>> does not list python3-netaddr. Any idea why?
>> >>>
>> >>> That package is not in the packages list of the check-merged.packages.fc23 file
>> >>> for that patch:
>> >>
>> >> We have single place for build requirements - vdsm.spec. How about
>> >> using yum builddep to
>> >> install dependencies instead of duplicating the data?
>> >
>> > That’s not really feasible, since we are generating vdsm.spec during the run of configure, then again configure requires some packages to be available….
>> > Not really the best of ideas
>>
>> Suggest a better way?
>
>
> Maybe you should try to avoid generating the spec? at least, not the
> 'buildrequires' section? (so it would be usable to extract the requirements
> even if some sections of it will be changed later by autotools/make/whatever)

Or maybe we should remove the build requirements from the spec, since it is
not a portable solution (e.g. debian), and have simple list of packages for each
supported platform.

Milan, what is the solution that will work best for debian?

Nir