Il giorno mer 30 gen 2019 alle ore 21:39 Nir Soffer <[email protected]> ha scritto:
> Last time we discussed this here, we had only sanlock issue: > https://bugzilla.redhat.com/1593853 > > The bug was fixed upstream about 2 month ago, but the Fedora package was > not available. > > The package is not available yet in Fedora, but we have a build here: > https://koji.fedoraproject.org/koji/buildinfo?buildID=1182539 > Reviewing it on https://bodhi.fedoraproject.org/updates/FEDORA-2019-ea4ecdc166 I see takotron found 6 issues with automated testing: there's a comment in spec file containing a macro: # %patch0 -p1 -b .0001-foo.patch which may cause unexpected behavior and should either be escaped (%%patch) or dropped. Also: rpmlint FAILED for sanlock-3.6.0-4.fc28 (x86_64, noarch, src): 6 errors, 9 warnings ##### SRPMs ##### sanlock.src: E: description-line-too-long C The sanlock daemon manages leases for applications on hosts using shared storage. sanlock.src:40: W: macro-in-comment %patch0 sanlock.src:81: W: mixed-use-of-spaces-and-tabs (spaces: line 7, tab: line 81) 1 packages and 0 specfiles checked; 1 errors, 2 warnings. ##### RPMs ##### python2-sanlock.x86_64: W: no-documentation sanlk-reset.x86_64: W: spelling-error %description -l en_US lockspace -> lock space, lock-space, locks pace sanlk-reset.x86_64: E: dir-or-file-in-var-run /var/run/sanlk-resetd sanlk-reset.x86_64: E: non-standard-dir-perm /var/run/sanlk-resetd 775 sanlock.x86_64: E: description-line-too-long C The sanlock daemon manages leases for applications on hosts using shared storage. sanlock.x86_64: W: manual-page-warning /usr/share/man/man8/sanlock.8.gz 535: warning: macro `/"' not defined sanlock.x86_64: E: dir-or-file-in-var-run /var/run/sanlock sanlock.x86_64: E: non-standard-dir-perm /var/run/sanlock 775 sanlock.x86_64: W: empty-%postun sanlock-devel.x86_64: W: no-dependency-on sanlock/sanlock-libs/libsanlock sanlock-devel.x86_64: W: no-documentation sanlock-lib.x86_64: W: no-documentation 5 packages and 0 specfiles checked; 5 errors, 7 warnings. RPMs tested: python2-sanlock-3.6.0-4.fc28.x86_64.rpm sanlk-reset-3.6.0-4.fc28.x86_64.rpm sanlock-3.6.0-4.fc28.src.rpm sanlock-3.6.0-4.fc28.x86_64.rpm sanlock-devel-3.6.0-4.fc28.x86_64.rpm sanlock-lib-3.6.0-4.fc28.x86_64.rpm If you want to whitelist some warnings/errors, see https://fedoraproject.org/wiki/Taskotron/Tasks/dist.rpmlint#whitelist These RPMs use `python-` prefix without Python version in *Requires: sanlock-3.6.0-4.fc28 BuildRequires: * python (python2 is available) * python-devel (python2-devel is available) This is strongly discouraged and should be avoided. Please check the required packages, and use names with either `python2-` or `python3-` prefix. Read the following document to find more information and a possible cause:https://fedoraproject.org/wiki/Packaging:Python#Dependencies Or ask at #fedora-python IRC channel for help. If you think the result is false or intentional, file a bug against:https://github.com/fedora-python/task-python-versions/issues ----------- You've used /usr/bin/python during build on the following arches: sanlock-3.6.0-4.fc28: armv7hl, x86_64 Use /usr/bin/python3 or /usr/bin/python2 explicitly. /usr/bin/python will be removed or switched to Python 3 in the future. Grep the build.log for the following to find out where: DEPRECATION WARNING: python2 invoked with /usr/bin/python Read the following document to find more information and a possible cause:https://fedoraproject.org/wiki/Changes/Avoid_usr_bin_python_in_RPM_Build Or ask at #fedora-python IRC channel for help. If you think the result is false or intentional, file a bug against:https://github.com/fedora-python/task-python-versions/issues ----------- > > > You can install sanlock from this build using: > > dnf upgrade > https://kojipkgs.fedoraproject.org//packages/sanlock/3.6.0/4.fc28/x86_64/python2-sanlock-3.6.0-4.fc28.x86_64.rpm > \ > > https://kojipkgs.fedoraproject.org//packages/sanlock/3.6.0/4.fc28/x86_64/sanlock-3.6.0-4.fc28.x86_64.rpm > \ > > https://kojipkgs.fedoraproject.org//packages/sanlock/3.6.0/4.fc28/x86_64/sanlock-lib-3.6.0-4.fc28.x86_64.rpm > > Hopefully the package will pushed soon to updates-testing repo. > > With this you can use enable selinux as god intended. > > But if you update your host to kernel 4.20.4-100, multipath is broken. All > multipath devices > are not available, and your hosts will probably become non-operational > since they report the > iSCSI/FC storage domains in problem. > > The issue was reported here: > https://lkml.org/lkml/2018/11/5/398 > > And we have this Fedora 29 bug: > https://bugzilla.redhat.com/1669235 > > Ben explains it is: > > The kernel is switching over to use block multiqueue instead of the old > request > queue. Part of doing this is removing support for the old request queue > from device-mapper. Another part is to remove support for the old > request queue from the scsi layer. For some reason, the first part got > into this fedora kernel, but the second part didn't. It seems to me > that since the fedora kernel has removed support for non-blk-mq based > devices, > I should have been compiled with CONFIG_SCSI_MQ_DEFAULT=y > > > To fix this issue you need to add the scsi_mod.use_blk_mq=Y option to the > kernel command line: > > grubby --args=scsi_mod.use_blk_mq=Y --update-kernel > /boot/vmlinuz-4.20.4-100.fc28.x86_64 > > After reboot, your multipath devices will appear again. > > Cheers, > Nir > -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> [email protected] <https://red.ht/sig>
_______________________________________________ Devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/[email protected]/message/7EHLC73FE46SELG67YFYUORDCJ5SRMQO/
