Processed: transition: xnnpack and onednn for PyTorch 2.6

[Debian Bug Tracking System]

affects -1 + src:xnnpack src:onednn src:pytorch src:pytorch-cuda

Bug #1094440 [release.debian.org] transition: xnnpack and onednn for PyTorch 2.6
Added indication that 1094440 affects src:xnnpack, src:onednn, src:pytorch, and src:pytorch-cuda

[Debian Bug Tracking System]

retitle -1 transition: xnnpack, onednn, pytorch{,-cuda}

Bug #1094440 [release.debian.org] transition: xnnpack and onednn for PyTorch 2.6
Changed Bug title to 'transition: xnnpack, onednn, pytorch{,-cuda}' from 'transition: xnnpack and onednn for PyTorch 2.6'.

[Shengqi Chen]

Control: retitle -1 transition: xnnpack, onednn, pytorch{,-cuda}

Hi,

They have exact same reverse dependencies (pytorch and onnxruntime)
* pytorch needs a new upstream version (2.6+) that we are preparing
* onnxruntime needs a binNMU.
Since they are mainly used as dependencies of PyTorch 2.6, I would
like them to be in one, but not two independent, transition if possible.

After discussion with @lumin, we think xnnpack, onednn and pytorch need
to be in one transition, since their versions are tightly coupled.

The Ben file should then be:

title = “xnnpack, onednn, pytorch";
is_affected = .depends ~ /\b(libxnnpack0\.20241108|libxnnpack0|libdnnl3\.6|libdnnl3|libtorch2\.5|libtorch2\.6)\b/;
is_good = .depends ~ /\b(libxnnpack0\.20241108|libdnnl3\.6|libtorch2\.6)\b/;
is_bad = .depends ~ /\b(libxnnpack0|libdnnl3|libtorch2\.5)\b/;

[Shengqi Chen]

Hi,

Yes, I noticed that xnnpack in experimental depends on pytorch/experimental.

I think this should be the reversed way (pytorch depends on xnnpack)?
Thanks & noticed.

* pytorch-cuda is just a non-free variant which would be uploaded
after pytorch.
* pytorch-vision itself has autopkgtest issues and is not in testing
now.

Also, have you test rebuilt rdeps against the new packages?

@lumin has run rate on them:

For onednn, xnnpack:

* onnxruntime: FTBFS solved by new 1.20.1+dfsg-1~exp1

For pytorch{,-cuda}:

* pytorch-{cluster,scatter,vision,ignite}, baler: builds without issue
* pytorch-sparse: failed, in testing, @lumin is looking into it
* skorch, pytorch-{audio, geometric}, python-array-api-compat: failed, but not in testing

Thanks,
Shengqi Chen

[Shengqi Chen]

Hi Emilio,

Scheduled now.

They are all good now. Thanks!

I still have some questions, since this is my first time to do a
transition independently:

For onednn and xnnpack, the newly built packages are shown as
“unknown” state in the tracker. I suspect it is due to old SONAME
being a prefix of the new one (libdnnl3{,.6}, similar for xnnpack).
Maybe the automatic ben file generator can detect this and handle
the situation, or may be just add a pair of ^$ to the regex?

And for pytorch, its migration depends on the autopkgtest of
pytorch-{scatter,sparse}. But seems britney does not run tests for
binNMU versions (#944458), so the results on the tracker page are
all failure. Do we need any human intervention on this?

[Debian Bug Tracking System]

tags -1 confirmed

Bug #1094440 [release.debian.org] transition: xnnpack, onednn, pytorch{,-cuda}
Added tag(s) confirmed.