On Thu, Apr 14, 2016 at 1:19 PM, David Caro <[email protected]> wrote: > On 04/14 13:17, Nir Soffer wrote: >> On Thu, Apr 14, 2016 at 12:55 PM, Vinzenz Feenstra <[email protected]> >> wrote: >> > >> >> On Apr 14, 2016, at 11:52 AM, Nir Soffer <[email protected]> wrote: >> >> >> >> On Thu, Apr 14, 2016 at 12:23 PM, David Caro <[email protected]> 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 _______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
