https://bugzilla.redhat.com/show_bug.cgi?id=2510919
--- Comment #28 from Cristian Le <[email protected]> --- > I believe you have seen https://github.com/marekandreas/elpa/issues/78, yet I > want to mention some more things related to above comment here in case I > forgot them: Doing catch-up after my PTO, so it's helpful to re-ping me on many stuff. I'll try to be thorough when going through the backlog. > - `src/shipped_srcs/OPENCCL_TESTS`: I didn't find it but > `src/shipped_srcs/ONECCL_TESTS` in the git repo, which was excluded in the > release artifact in https://elpa.mpcdf.mpg.de/. Unfortunately these inconsistencies are not uncommon, so it's up to us to dig into the why and if it is needed for us. At first glance it seems it would be useful for testing on some gpu hardware, but that might also need some additional setup on our side. At the very least we should document it and ask upstream for thoughts. The size difference of the source is not a big concern for us, only for the built rpms we need to consider more. On a side note, having test files in the source rpm can be surprisingly helpful because you can design a test to consume the ones that are linked directly to them instead of downloading them from `main` branch and hope it still works on older versions. > Only `NVIDIA_A100_kernel/hh_test` in the release artifact, but it seems > unlikely that they are compiled and included the CPU build. Unfortunately, > the `LICENSE` file under that subfolder also doesn't explicitly said what > general license they're following. It is MIT and pointing to https://github.com/hummingtree/hh_test. That part looks fine to me, just needs documentation. And yes it is unlikely that we would use it. > - Regarding OpenMP, consumers can choose what they want: `elpa` for > non-OpenMP building, and `elpa_openmp` for OpenMP building. Sure, but is that a meaningful option that either we or upstream should still be providing. MPI variants is already proving how that complexity can blow in our face. I have not dig deep into how these 2 variants interact but I believe it was safe to use the openmp variant and would not collide with the consumer's usage, other than the common environment variable that controls the parallelization there. But it's worth reopening the issue with upstream. > - From https://elpa.mpcdf.mpg.de/LICENSING.html and copyright banner in the > source files they only mentioned "LGPLv3" Indeed, but just a gentle poke to upstream to remind them of needing to more explicitly clarify it would be appreciated. -- You are receiving this mail because: You are always notified about changes to this product and component https://bugzilla.redhat.com/show_bug.cgi?id=2510919 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202510919%23c28 -- _______________________________________________ package-review mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
