https://bugzilla.redhat.com/show_bug.cgi?id=1885430 --- Comment #10 from giovanni.cabiddu@xxxxxxxxx --- I uploaded a new version of the SPEC and the RPM: Spec URL: https://raw.githubusercontent.com/intel/qatlib/v20_08/rpm/qatlib.spec SRPM URL: https://raw.githubusercontent.com/intel/qatlib/v20_08/rpm/qatlib-20.08.0-1.fc33.src.rpm >Yes please, the guidelines are clear here. "If the bundled package also exists separately in the distribution, use the name of that package." Use `Provides: bundled(openssl) = 1.1.1c`. The idea is that if there is a vulnerability discovered in a package, we can query for everything that provides it as a bundled library. That only works when we standardize on a name so we don't have to query for every possible variation or sub-library of that package. Done. >I'm not sure I follow. Those are provided by the system openssl library, not by qatengine. Where does it become circular? If it's debundled, the build order for the distribution would be openssl, qatlib, then qatengine. The dependency is a run time, if qatlib uses the OpenSSL EVP API. In that case we would have: app -> openssl:libcrypto_EVP -> qat_engine -> qat_lib -> openssl:libcrypto_EVP -> qat_engine -> qat_lib -> REPEAT We resolved it by linking against OpenSSL/libcrypto and using the lower level (public) crypto APIs for the algorithms we need. This change is included in the next release. This will work for now, however we have to re-think at the approach for the future since for OpenSSL 3.0 those APIs are marked as DEPRECATED. E.g. https://github.com/openssl/openssl/blob/master/include/openssl/aes.h#L51 >That's odd, because qatengine got permission to remove their license header (bug 1885495 comment 10). If the spec file will be under the MIT license (the Fedora default for spec files), then the comment header is just noise and needs to be removed to improve legibility. To be clear, the qatlib.spec.in file in the upstream repo can keep the header, we're only discussing the spec file that will be imported into Fedora package sources. I checked again and the guideline is to still leave the license on the file. In order to address the noise/visual clutter in the file we replaced the full header with the SPDX License Identifier: `# SPDX-License-Identifier: MIT` Is this ok? >The latter. There are many upstreams who don't test on alternative architectures. Fedora basically is their alternative arch testing and QA (which works better when there is an upstream test suite to run in %check). Unless it has been established as fact that the software doesn't compile, build, or work on an architecture, the package should build for that architecture. Thanks. I haven't run the build yet any alternative architectures. Is it something I have to do? If yes, which architectures should I try? -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ 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
