1. Forum
  2. Usenet
  3. LINUX.DEBIAN.BUGS.RC

  • Bug#1101533: pytorch-geometric: Failing autopkgtests

    From Santiago Vila@21:1/5 to All on Wed Apr 9 11:40:04 2025
    reopen 1101533
    thanks

    Hi. We are an architecture away (riscv64) from passing the autopkgtests.
    I'm making this official and visible by reopening again.

    https://qa.debian.org/excuses.php?package=pytorch-geometric

    The problem is that the package is arch:all and it's normally built
    in the amd64 buildds, but for the autopkgtests the package is actually
    built in all those non-amd64 architectures. If we could skip riscv64,
    we would be done.

    Should we drop autopkgtest-pkg-pybuild and "wrap" it in debian/tests,
    where we can still decide to build the package or not depending
    on the test architecture?

    Thanks.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Debian Bug Tracking System@21:1/5 to All on Wed Apr 9 11:40:04 2025
    Processing commands for control@bugs.debian.org:

    reopen 1101533
    Bug #1101533 {Done: Santiago Vila <sanvila@debian.org>} [src:pytorch-geometric] pytorch-geometric: Failing autopkgtests
    'reopen' may be inappropriate when a bug has been closed with a version;
    all fixed versions will be cleared, and you may need to re-add them.
    Bug reopened
    No longer marked as fixed in versions pytorch-geometric/2.6.1-6.
    thanks
    Stopping processing here.

    Please contact me if you need assistance.
    --
    1101533: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101533
    Debian Bug Tracking System
    Contact owner@bugs.debian.org with problems

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Santiago Vila@21:1/5 to All on Wed Apr 9 13:30:01 2025
    El 9/4/25 a las 13:13, Andrius Merkys escribió:
    Should we drop autopkgtest-pkg-pybuild and "wrap" it in debian/tests,
    where we can still decide to build the package or not depending
    on the test architecture?

    Let's do this. Thanks a lot for working on pytorch-geometric!

    Not so fast!

    Please take a look at

    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1102472

    The real solution might be in src:python3-torch, I was looking at
    dropping the following lines:

    # https://stackoverflow.com/questions/65966969/why-does-march-native-not-work-on-apple-m1
    # `-march=native` is unrecognized option on M1
    if not config.is_fbcode():
    if platform.machine() == "ppc64le":
    cflags.append("mcpu=native")
    else:
    cflags.append("march=native")

    from torch/_inductor/cpp_builder.py

    Thanks.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)