On Wed, Oct 25, 2017 at 3:21 PM, Nir Soffer <[email protected]> wrote:
> On Wed, Oct 25, 2017 at 9:33 AM Sandro Bonazzola <[email protected]> > wrote: > >> 2017-10-20 20:05 GMT+02:00 Yaniv Kaul <[email protected]>: >> >>> >>> >>> On Fri, Oct 20, 2017 at 7:56 PM, Nir Soffer <[email protected]> wrote: >>> >>>> On Fri, Oct 20, 2017 at 11:37 AM Sandro Bonazzola <[email protected]> >>>> wrote: >>>> >>>>> Just an heads up we have improvement margin on vdsm spec file quality. >>>>> >>>>> [sbonazzo@sbonazzo SPECS]$ rpmlint ./vdsm.spec >>>>> /var/lib/mock/epel-7-x86_64/result/*rpm >>>>> vdsm.x86_64: E: explicit-lib-dependency libnl3 >>>>> >>>> >>>> What is wrong with this? >>>> >>>> >>>>> vdsm.x86_64: E: explicit-lib-dependency libvirt-client >>>>> vdsm.x86_64: E: explicit-lib-dependency libvirt-daemon-config-nwfilter >>>>> vdsm.x86_64: E: explicit-lib-dependency libvirt-lock-sanlock >>>>> vdsm.x86_64: W: obsolete-not-provided vdsm-infra >>>>> vdsm.x86_64: E: no-binary >>>>> >>>> >>>> Ha? >>>> >>> >> The package should be of the noarch architecture because it doesn't >> contain >> any binaries. >> > > Vdsm has many arch specific requirements, and we have different > requirements > on different platforms. Having a arch specific meta package was the > solution > suggested by Fedora reviewers about 2 years ago. > > >> >> >> >>> >>>> >>>>> vdsm.x86_64: W: conffile-without-noreplace-flag /var/log/vdsm/mom.log >>>>> >>>> >>>> This is not a conf file, we should probably change this >>>> >>>> >>>>> vdsm.x86_64: W: conffile-without-noreplace-flag >>>>> /var/log/vdsm/supervdsm.log >>>>> vdsm.x86_64: W: conffile-without-noreplace-flag /var/log/vdsm/vdsm.log >>>>> vdsm.x86_64: W: non-conffile-in-etc /etc/NetworkManager/conf.d/ >>>>> vdsm.conf >>>>> >>>> >>>> Ha? >>>> >>> >>> Perhaps: >>> %{_sysconfdir}/NetworkManager/conf.d/vdsm.conf >>> >>> should be: >>> %config(noreplace) %{_sysconfdir}/NetworkManager/conf.d/vdsm.conf >>> >>> >>> >>>> >>>>> vdsm.x86_64: W: non-conffile-in-etc /etc/modprobe.d/vdsm-bonding- >>>>> modprobe.conf >>>>> vdsm.x86_64: E: non-readable /etc/pki/vdsm/keys/libvirt_password 600 >>>>> vdsm.x86_64: W: non-conffile-in-etc /etc/security/limits.d/99- >>>>> vdsm.conf >>>>> >>>> >>>> Ha? >>>> >>> >>> Same? >>> >>> >>>> >>>> >>>>> vdsm.x86_64: W: non-conffile-in-etc /etc/sudoers.d/50_vdsm >>>>> vdsm.x86_64: W: systemd-unit-in-etc /etc/systemd/system/libvirtd. >>>>> service.d/unlimited-core.conf >>>>> vdsm.x86_64: W: non-conffile-in-etc /etc/systemd/system/libvirtd. >>>>> service.d/unlimited-core.conf >>>>> vdsm.x86_64: E: zero-length /etc/vdsm/mom.d/01-parameters.policy >>>>> vdsm.x86_64: E: wrong-script-interpreter /usr/libexec/vdsm/kvm2ovirt >>>>> /usr/bin/env python >>>>> >>>> >>>> This used to be the recommended way to write scripts, but it is easy to >>>> replace with /usr/bin/python2. >>>> >>> >> It should be /usr/bin/python since python is under "alternatives" >> management >> > > But most of the code is python2 only - we recently update (most) scripts > to use > /usr/bin/python2. > > >> >> >> >>> >>>> >>>>> vdsm.x86_64: E: wrong-script-interpreter >>>>> /usr/libexec/vdsm/vm_migrate_hook.py >>>>> /usr/bin/env python >>>>> vdsm.x86_64: E: wrong-script-interpreter >>>>> /usr/share/vdsm/virt/vm_migrate_hook.py >>>>> /usr/bin/env python >>>>> vdsm.x86_64: E: non-executable-script >>>>> /usr/share/vdsm/virt/vm_migrate_hook.py >>>>> 644 /usr/bin/env python >>>>> vdsm.x86_64: E: non-standard-dir-perm /var/lib/libvirt/qemu/channels >>>>> 775 >>>>> vdsm.x86_64: E: non-standard-dir-perm /var/log/core 1777 >>>>> vdsm.x86_64: E: dir-or-file-in-var-run /var/run/vdsm >>>>> >>>> >>>> What is wrong with this? >>>> >>> >>> "/var/run may be a temporary filesystem, so any directories or files >>> needed there must be created dynamically at boot time." >>> >> > We create these directories in runtime, not sure why we create them also > during instillation. > As of my I0bdc3b1f2be960d536856465979c89ac85bce4a5 (introduced to silence rpmlint), we no longer do. I do not recall why do we still have this horrible /var/log/core 1777; I hoped that with proper integration to ABRT, we can delegate the responsiblity of collecting core dumps. Irit, do you recall?
_______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
