https://bugzilla.redhat.com/show_bug.cgi?id=2085444 --- Comment #83 from Daniel Berrangé <berrange@xxxxxxxxxx> --- (In reply to Daniel Berrangé from comment #82) > > Also some other new changes/fixes are also not included in github official release yet. To address this, upstream team will create a new branch to include all the needed changes for Fedora. > > > > Later with all fixes available on new branch of linux-sgx, we'll make sure building RPM from linux-sgx github repo(+ make preparation + build.sh) work for rawhide. > > For the license issue of optimized_libs, it seems Fedora does not need the lib. Probably we need a dedicated download_prebuilt.sh for Fedora. We will update again once ready. > > IMHO this is all missing the point. Fedora does not want to be building RPMs > from special Fedora only branches of upstream that bundles Fedora. > > The RPM should be built from the official release *tarballs* at ie from the > linux-sgx-sgx_2.22.tar.gz linked at > https://github.com/intel/linux-sgx/releases/tag/sgx_2.22 > > If there are temporary patches needed to make it work on Fedora, add patches > for those to the RPM, until those patches can be incorporated in the *main* > upstream branch. I've taken your spec and changed it so that it uses the pristine tarballs from linux-sgx git release, along with pristine tarballs for each git submodule needed to build the SDK. The result looks like this: https://berrange.fedorapeople.org/review/linux-sgx/linux-sgx.spec https://berrange.fedorapeople.org/review/linux-sgx/linux-sgx-2.22-1.fc38.src.rpm The %prep / %build / %install stages are significantly more complicated because linux-sgx build system is quite crude and doesn't support a normal build/install approach that most apps use The important benefit of this is that we have high confidence in provenance of the source code. We also don't end up needing any of the pre-built libraries that the sgxsdk tarball bundles AFAICT, since we can replace the pre-built crypto with sgxssl + openssl. Building this way resulted in two extra libraries libtdx_tls.a and libsgx_mbedcrypto.a that sgxsdk tarball was missing. I don't know if they're desirable or not ? Also the libsgtcxx.a library is called libsgx_tcxx.a. sgxsdk seemed to take special action to rename it to libsgtcxx.a for some reason. Again I don't know if that's desirable or not ?: The %{_includedir}/sgxsdk/mbedtls/ files got installed, which was not the case with sgxsdk package too. The major unaddressed issue still is that we cannot be building a normal openssl. We must ensure that all ECC crypto is stripped out, as done in 0011-Remove-EC-curves.patch from te main fedora openssl package. BTW, I called my spec linux-sgx.spec since it is normal to name pacakges after the corresponding upstream project, but don't read too much into that. linux-sgx is a bit of an umbrella project though. In bug 2030595 you have a separate sgx-aesm-service.spec that also uses linux-sgx source. So we have two choices * Separate sgxsdk.spec and sgx-aesm-service.spec, which both use the same tarball released from linux-sgx.git, in the way you've proposed so far Or * A single linux-sgx.spec that builds absolutely everything Please take a look at my RPM proposal and let me know what you think about this approach of building from upstream source instead of the current sgxsdk source tarball. AFAICT, there should be no semantic difference between the two approaches, except for my decision to use sgxssl and no prebuilt ipp crypto -- 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=2085444 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202085444%23c83 _______________________________________________ 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
