https://bugzilla.redhat.com/show_bug.cgi?id=2085444
--- Comment #68 from Yunying Sun <yunying.sun(a)intel.com> ---
(In reply to Daniel Berrangé from comment #65)
Please do not simply ignore requested changes from reviewers. It is
is fine
to disagree with requests, but if you're not going to address something
please explain why the request was inappropriate.
Sorry, I missed these: renaming
package to sgxsdk-devel, fixing typo fixes and
trailing whitespaces. Will fix both soon.
About the bundle thing Cole suggested in comment 63, we don't quite understand.
Are you suggesting to add all third party tools that linux-sgx is using their
old versions instead of the up-to-date system-provided versions, to spec file
with "Provides: bundled(xxx) = <the old versions>"?
Package guidance says:
"All packages whose upstreams have no mechanism to build against system
libraries MAY opt to carry bundled libraries"
does that mean bundled libraries are not necessarily listed in spec file?
> 5. Removed subpackage "sgxsdk-samples" stuff, which will be added later
after sgx-aesm-service available Fedora.
I'm not happy with that. As mentioned in
https://bugzilla.redhat.com/show_bug.cgi?id=2030595#c36 since they are
mutually dependant,
I think sgx-sdk and sgx-aesm-service need to be proposed together as a pair
and reviewed at the same time.
I don't think we should be approving this with bits cut out, which will be
re-added just after acceptance, but without review.
We removed sub-package
sgxsdk-samples because as Cestmir stated in comment 59:
"Perhaps sgxsdk-samples subpackage can be added later if you don't want to
address these now -- after sgx-aesm-service (that provides both
libsgx-enclave-common and libsgx-urt [and require many of the above discussed
fixes, too]) is in Fedora; until then its dependencies will not be satisfiable
anyway."
Since sgx-aesm-service depends on SGX SDK package reversely, could you confirm
if reviewing sgx-sdk and sgx-aesm-service in pair could satisfy the
cross-dependency for compiling?
If yes, I can add the sgxsdk-samples back(and rename it to sgxsdk-examples as
Cole suggested in comment 63).
> # The entire source code is BSD, except some third party projects are
> # under other licenses listed in License.txt.
> License: BSD and MIT and ASL 2.0 and NCSA/MIT and CC0 and FBSDDL and OpenSSL
and zlib and GPL and BSD/GPLv2 and EPL-1.0
Fedora recently switched to using SPDX expressions for license declarations,
so I'm afraid this needs to be updated to follow that new standard
https://docs.fedoraproject.org/en-US/legal/license-field/
NB, there is no license minimization done anymore - any license present in a
compiled source file needs to be listed - IOW, all versions of the GPL that
are present in source need explicitly listing
We will update the license fields to
follow the new expressions and standard.
> # To build SGX SDK from linux-sgx source, first download the prebuilt
> # binaries by "make preparation", then run script
> # ./linux/installer/rpm/sdk/build.sh to update spec and repack tarball.
> # The repacked tarball is shared on
01.org for generating target RPMs.
> Source0:
https://download.01.org/intel-sgx/sgx_repo/rpm_onespec/%{name}-%{version}...
These instructions don't appear to work when I try them
$ git clone
https://github.com/intel/linux-sgx
$ cd linux-sgx
$ make preparation
...snip...
$ ./linux/installer/rpm/sdk/build.sh
~/tmp/linux-sgx/linux/installer/rpm/sdk/sgxsdk-2.20.100.4 ~/tmp/linux-sgx
~/tmp/linux-sgx
readelf:
./linux/installer/rpm/sdk/../../../..//linux/installer/common/sdk/../../../..
//build/linux/sgx_sign: Error: No such file
./linux/installer/rpm/sdk/../../../..//linux/installer/common/sdk/
createTarball.sh: line 51: test: =: unary operator expected
Create the dest dir
Error !!!: src file not exist
/home/berrange/tmp/linux-sgx/build/linux/libsample_libcrypto.so
Seems like there is some intermediate step missing
There are some unpublished
fixes(needed for compiling source on Fedora) not
available on public github linux-sgx repo yet.
The fixes are available only in the tarball contained in SRPM @
https://yunyings.fedorapeople.org/sgxsdk-2.20.100.0-1.fc39.src.rpm.
> %autosetup -c
This is the correct thing to do in Fedora context, however, I would also
encourage filing a bug against the upstream project. It is really bad
practice for a release tarball to not unpack into a top level directory
matching the name+version of the tarball.
We will fix this.
> %{_libdir}/*.so
> %{_libdir}/pkgconfig/*.pc
> %{_libdir}/sgx-gdb-plugin/
> %{_prefix}/lib/sgxsdk/
> %{_datadir}/sgxsdk/
I'd like to see all of these expand the list of files being packaged. This
serves two purposes - it causes a build failure if a file unexpectedly goes
missing on a rebase, and it identifies when new stuff is added on a rebase.
Given that this package is bundling so much 3rd party code, I think the
identifying newly added libraries is especially important as it would likely
have implications for the license declaration.
> %{_includedir}/sgxsdk/
I don't want each .h file listed separately, but I'd like to see this list
the top level as again this clearly identifies what is being bundled:
%dir %{_includedir}/sgxsdk/
%{_includedir}/sgxsdk/sgx_*.h
%{_includedir}/sgxsdk/stdc++/
%{_includedir}/sgxsdk/libcxx/
%{_includedir}/sgxsdk/ipp/
%{_includedir}/sgxsdk/tlibc/
%{_includedir}/sgxsdk/tprotobuf/
We will expand the list of %{_includedir}/sgxsdk/
as you suggested above.
Do we need to expand %{_datadir}/sgxsdk/ and %{_libdir}/sgx-gdb-plugin/ to its
next level too?
Furthermore, code under the CC0 license is now broadly forbidden in
new packages addd to Fedora
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.o...
Latest post on this thread says:
"Realistically, we may also want to continue to allow CC0 covered code for a
short period of time for new packages that are just getting into Fedora until
some percolating has happened in those upstream communities".
Can we ship this package still with CC0 license, meanwhile we notify upstream
about the need for a license change?
We can refresh package license after upstream license changes. Is this
acceptable?
At least the ISC license appears relevant and isn't listed.
It seems the ISC license only appears in the "OpenBSD Copyright Policy"
part in
License.txt. Not related to any source code?
--
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=rep...