https://bugzilla.redhat.com/show_bug.cgi?id=2242971 --- Comment #38 from Tom Rix <trix@xxxxxxxxxx> --- (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/e8602044dda5fe806787b0606508f50d304115a7 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. -- 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=2242971 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202242971%23c38 -- _______________________________________________ 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
