https://bugzilla.redhat.com/show_bug.cgi?id=2242971
--- Comment #38 from Tom Rix trix@redhat.com --- (In reply to Davide Cavalca from comment #36)
Looks like this breaks fedora-review because of the %include usage.
Source1: pt_dirs.txt Source2: pt_devel_headers.txt Source3: pt_python.txt
Please add comments to document how these were generated (or even better, generate them with a script and run that in %install instead like the systemd package does).
These are only somewhat automated, some judgement was used to include things. This package has a wide and deep directory / file structure. This approach is a less bad option to comment #4 from Neal. I would prefer to use aggressive globbling. How aggressive can I be ?
Summary: An AI/ML python package
As the comment above mentioned, this needs to match the summary in the review title; if you want it to include PyTorch for visibility, I'd suggest something like "PyTorch AI/ML framework".
Ok.
# auto reviewer not happy with : BSD-0-Clause AND Khronos
Neither of these are valid SPDX names. BSD-0-Clause is most likely 0BSD (https://spdx.org/licenses/0BSD.html). As for Khronos, you should submit that one for review at https://gitlab.com/fedora/legal/fedora-license-data as I don't see it in the list of allowed licenses (https://docs.fedoraproject.org/en-US/legal/allowed-licenses/).
Thanks for the 0BSD pointer. From the breakdown of the licenses, the Khronos ones are OpenCL headers They are not used so I am rm-ing them in prep.
# Limit to these because they are well behaved with clang ExclusiveArch: x86_64 aarch64 %global toolchain clang
Is this an upstream limitation? We definitely have other packages using clang that build find on all arches.
To cover the other arches in an early attempt here https://github.com/trixirt/pytorch-fedora/commit/e8602044dda5fe806787b060650... Ment using gcc. But there are many, many warnings when gcc is used, because I suspect, pytorch is really only built with clang. So instead of chasing problems with gcc, I reverted back to clang. And rawhide's clang changes faster than pytorch's, this choice of arches are imo the most stable for both pythorch and clang. Maybe this is only x86_64 ? I'd like to get aarch64 in as well.
# And they need to be stripped
Why are we manually stripping stuff in %install?
Fixed with fiddling with the cmake build type.