Hi Ricardo, thanks for the information!
Ricardo Wurmus <rek...@elephly.net> writes: > Oh, commit 8429f25ecd83594e80676a67ad9c54f0d6cf3f16 added > python-pytorch2 at version 2.2.1. Do you think you could adjust your > patches to modify that one instead? I already adjusted the patches yesterday to remove the python-pytorch2 package you added, as the patch series updates the main python-pytorch package to version 2. The new inputs of your package were already included, with the exception of python-opt-einsum. I had overlooked it before and included it now. :) Is there a reason to keep version 1 around? Then I could adjust the patches again. Otherwise, it makes sense for me to move the python-pytorch package to version 2.2.1 and have a package variant with 2.0.1 for r-torch (which I kept and adjusted). Due to problems when building dependencies, the new package only succeeds to build for x86_64. As I explained in the patch series, asmjit fails on armhf because GCC runs out of memory (it reaches 4 GB I think and more is of course not possible) and cpuinfo has a known bug on aarch64 [1], which causes the tests to fail and AFAICT also break PyTorch at runtime. Through python-pytorch -> python-expecttest -> poetry -> python-keyring -> python-secretstorage -> python-cryptography, the python-pytorch package now depends on rust, which currently requires too much memory to build on 32 bit systems, so i686 is not supported either. What do you think should be done here? I added all packages required for the core tests to native-inputs, but decided to disable them as they require a long time to run. If I remove the test inputs (in particular python-expecttest), the package could probably also be built for i686. Would it be acceptable keep them as a comment for reference? > I think it is sufficient to only have the current version of ROCm; other > versions could be added if there is reasonable demand. That sounds good to me. Best, David [1] https://github.com/pytorch/cpuinfo/issues/14