https://bugzilla.redhat.com/show_bug.cgi?id=2342978 --- Comment #14 from Daniel Berrangé <berrange@xxxxxxxxxx> --- (In reply to Richard W.M. Jones from comment #10) > Issues: > ======= > - The License field must be a valid SPDX expression. > Note: Not a valid SPDX expression 'Apache-2.0 AND BSD-2-Clause AND > BSD-3-Clause AND BSD-4-Clause AND BSD-4-Clause-UC AND GPL-2.0-only AND > ISC AND MIT AND MIT-0 AND NCSA AND OpenSSL AND SMLNJ AND SunPro AND > LicenseRef-Public-Domain'. > See: https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_1 > > This seems to be a problem. Yes, same as my other package, it should be LicenseRef-Fedora-Public-Domain > - systemd_post is invoked in %post, systemd_preun in %preun, and > systemd_postun in %postun for Systemd service files. > Note: Systemd service file(s) in sgx-aesm, sgx-mpa, tdx-qgs > See: https://docs.fedoraproject.org/en-US/packaging- > guidelines/Scriptlets/#_scriptlets > > Maybe a problem? I had scripts for aesm, but forgot scripts for mpa/qgs, so have added those now. I also added scripts for sysusers, but conditionalized for RHEL only given Fedora 42 relies on RPM magic now. > [!]: Package requires other packages for directories it uses. > Note: No known owner of /usr/share/aesmd, /usr/lib64/aesmd, > /usr/lib64/aesmd/bundles > > Seems like an issue. Those dirs are now owned by sgx-aesm. > > [!]: Package must own all directories that it creates. > Note: Directories without known owners: /usr/lib/udev, > /usr/x86_64-intel-sgx/lib64, /usr/lib/.build-id/5b, > /usr/lib64/aesmd/bundles, /usr/share/aesmd, /usr/x86_64-intel-sgx, > /usr/lib/.build-id/47, /usr/lib/udev/rules.d, /usr/lib64/aesmd > > That .build-id directory also seems wrong. Note this is from a > mock-built package on my machine. I've added ownership of those dirs except the wierd build-id ones. > [ ]: Package does not own files or directories owned by other packages. > Note: Dirs in package are owned also by: /usr/x86_64-intel- > sgx/lib64(sgx-enclave-prebuilt-common) > > Unclear. As far as I'm aware it's OK for multiple RPMs to own a > directory. Yep, multiple packages can own a dir provided they agree on permissions, which is trivial if relying no default permissions > [x]: Package does not generate any conflict. > Note: Package contains Conflicts: tag(s) needing fix or justification. > > I'm not sure what it's complaining about here. There's a > BuildConflicts line, but it is justified. Yeah, I think it is the BuildConflicts it is reporting, which is ok. > > [ ]: Fully versioned dependency in subpackages if applicable. > Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in sgx- > common , sgx-enclave-latest-pce-unsigned , sgx-enclave-latest-ide- > unsigned , sgx-enclave-latest-qe3-unsigned , sgx-enclave-latest-tdqe- > unsigned , sgx-enclave-devel , sgx-devel , sgx-libs , sgx-aesm , sgx- > pccs-admin , sgx-pckid-tool , sgx-mpa , tdx-qgs , tdx-attest-libs , > tdx-attest-devel > > Unclear. There is no "%{name}" package emitted at all, so it is a false positive to add such a dep Several of the subpackages do have deps on the -libs sub-RPM, which fully set the version + release, but omit %{_?isa} which is fine since this is ExclusiveArch to a single target > [ ]: Spec use %global instead of %define unless justified. > Note: %define requiring justification: %define linux_sgx_version 2.25, > %define dcap_version 1.22, %define dcap_qvl_version 1.21, %define > dcap_qvs_version 1.1.0-2885, %define sgx_ssl_version 3.0_Rev4, %define > ipp_crypto_version 2021.12.1, %define sgx_emm_version 1.0.3, %define > openssl_version 3.0.14, %define libcbor_version 0.10.2, %define > abseil_cpp_version 20230125.3, %define jwt_cpp_version 0.6.0, %define > wamr_version 1.3.3, %define epid_version 6.0.0, %define rdrand_version > 1.1, %define vtune_version 2018, %define enclave_pce_version 2.25, > %define enclave_ide_version 1.22, %define enclave_qe3_version 1.22, > %define enclave_tdqe_version 1.22, %define enclave_qve_version 1.22, > %define with_enclaves 1, %define with_enclave_pce 1, %define > with_enclave_ide 1, %define with_enclave_qe3 1, %define > with_enclave_tdqe 1, %define with_enclave_qve 0, %define > _with_enclave_pce %{expr:%{with_enclaves} ? %{with_enclave_pce} : 0}, > %define _with_enclave_ide %{expr:%{with_enclaves} ? > %{with_enclave_ide} : 0}, %define _with_enclave_qe3 > %{expr:%{with_enclaves} ? %{with_enclave_qe3} : 0}, %define > _with_enclave_tdqe %{expr:%{with_enclaves} ? %{with_enclave_tdqe} : > 0}, %define _with_enclave_qve %{expr:%{with_enclaves} ? > %{with_enclave_qve} : 0}, %define vroot build/vroot > > I believe this requirement is wrong, %define is fine with modern RPM. I switched to %global regardless, just to be consistent within the spec as I had mixed both -- 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=2342978 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202342978%23c14 -- _______________________________________________ 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
