https://bugzilla.redhat.com/show_bug.cgi?id=2368742 --- Comment #11 from Pavol Sloboda <psloboda@xxxxxxxxxx> --- > > [!]: Scriptlets must be sane, if used. > SELinux should be consulted with the SELinux team. We’ve encountered this a few months ago with the credcheck package [2], where they helped to do it by the book. > > [!]: Uses parallel make %{?_smp_mflags} macro. > Is there a reason why it’s not used in [3]? These are both solved by changing the .te selinux policy to the .cil format which does not need to be compiled. Therefore the issues with `%{?_smp_mflags}` no longer apply. I have discussed the policy. its installation and the BuildRequires and Requires related to selinux with the selinux team which approved my changes. These changes can be found here: https://src.fedoraproject.org/rpms/mariadb10.11/c/6c8b0197dbe96622d02396616249d646236acfc5 https://src.fedoraproject.org/rpms/mariadb10.11/c/ad73a518de02465ab5d7422dc1e993f26e1095a9 > > mariadb11.8.spec:621: W: unversioned-explicit-provides bundled(rocksdb) > Include the version of rocksdb The MariaDB upstream bundles rocksdb with MariaDB from commits that do not match the releases made by the rocksdb upstream, therefore pinpointing the exact version of rocksdb being bundled with mariadb is difficult and yields a rough estimate at best. I have documented this inside the spec file along with a couple of ways how to get the rough version of rocksdb that is bundled. This can be seen in this commit: https://src.fedoraproject.org/rpms/mariadb10.11/c/c8027d496ac14f5bb31ddcef8ab8131609ac22b4 > > mariadb11.8-server-galera.x86_64: E: non-readable /etc/sysconfig/clustercheck 640 > Are the permissions set correctly here [8]? I have consulted this with one of the creators of the commit that added this file. It is an environment file that is sourced by clustercheck. This can only be done as root. Therefore the read, write permissions for root are correct. The read permission for the root group is there as far as I understand just to enable the users inside of the root group to check the contents of this file and therefore is not necessary but also not detrimental. The file is correctly marked as a ghost file since the mariadb package and any of its subpackages don't provide it but it belongs to the mariadb-server-galera subpackage if it is ever created (by the user or any utility). > > mariadb11.8.spec:1484: W: libdir-macro-in-noarch-package %{pkgname}-common %{_libdir}/%{majorname}/plugin/dialog.so > > mariadb11.8.spec:1485: W: libdir-macro-in-noarch-package %{pkgname}-common %{_libdir}/%{majorname}/plugin/mysql_clear_password.so > The noarch packages should not use the %{_libdir} according to the FHS [9] I am aware of this issue but the files mentioned above are only being created and packaged if the package is being built with the clibrary option enabled, which has been disabled for quite a while now as all the files and functionality being provided by this option are provided by the mariadb-connector-c package. Therefore these files are not being built and packaged at the moment so the -common subpackage can still stay as noarch. However this issue has been noted and I will create a feature branch documenting it and enabling further development that will get rid of it in the future. > > mariadb11.8-sphinx-engine.x86_64: E: explicit-lib-dependency libsphinxclient > This dependency should be handled by dnf automatically according to the Packaging Guidelines [10]. If it’s not, it should be documented so the explicit dependency is justified. The BuildRequires of libsphinxclient of the -sphinx-engine subpackage is obsolete since is it already required by the libsphinxclient-devel package, which in turn is a BuildRequires of the -sphinx-engine subpackage itself. This ensures that the libsphinxclient package is present in the buildroot without an explicit BuildRequires. These changes are in this commit: https://src.fedoraproject.org/rpms/mariadb10.11/c/7984b9ae05639333de5749526e15c5ccc5d2669d > > mariadb11.8.x86_64: W: crypto-policy-non-compliance-openssl /usr/bin/mariadb SSL_CTX_set_cipher_list > > mariadb11.8.x86_64: W: crypto-policy-non-compliance-openssl /usr/bin/mariadb-admin SSL_CTX_set_cipher_list > > mariadb11.8.x86_64: W: crypto-policy-non-compliance-openssl /usr/bin/mariadb-binlog SSL_CTX_set_cipher_list > > mariadb11.8.x86_64: W: crypto-policy-non-compliance-openssl /usr/bin/mariadb-check SSL_CTX_set_cipher_list > > mariadb11.8.x86_64: W: crypto-policy-non-compliance-openssl /usr/bin/mariadb-dump SSL_CTX_set_cipher_list > > mariadb11.8.x86_64: W: crypto-policy-non-compliance-openssl /usr/bin/mariadb-import SSL_CTX_set_cipher_list > > mariadb11.8.x86_64: W: crypto-policy-non-compliance-openssl /usr/bin/mariadb-show SSL_CTX_set_cipher_list > > mariadb11.8.x86_64: W: crypto-policy-non-compliance-openssl /usr/bin/mariadb-slap SSL_CTX_set_cipher_list > > mariadb11.8-backup.x86_64: W: crypto-policy-non-compliance-openssl /usr/bin/mariadb-backup SSL_CTX_set_cipher_list > > mariadb11.8-embedded.x86_64: W: crypto-policy-non-compliance-openssl /usr/lib64/libmariadbd.so.19 SSL_CTX_set_cipher_list > > mariadb11.8-server.x86_64: W: crypto-policy-non-compliance-openssl /usr/libexec/mariadbd SSL_CTX_set_cipher_list > Is this at least reported to upstream? I am still investigating these and I will either provide a reason why they are valid or contact upstream about them in the near future. -- You are receiving this mail because: You are always notified about changes to this product and component You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2368742 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202368742%23c11 -- _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
