Hi,
On 01/03/2026 13:08, Adrian Bunk wrote:
On Sat, Feb 28, 2026 at 09:33:42PM +0100, Sebastian Ramacher wrote:
On 2026-02-24 09:58:15 +0100, Dylan Aïssi wrote:
Hi,
On 29/01/2026 20:45, Adrian Bunk wrote:
Oups, actually tests segfault during the initiation step (so before
testing onnxruntime), this seems to be an issue with either ONNX or
PyTorch.
I proposed a new autopkgtest to onnx to catch this kind of bugs earlier:
https://salsa.debian.org/deeplearning-team/onnx/-/merge_requests/5
Your manual test from #1126427
import torch
import onnx
fails for me in unstable but works after downgrading to python3-onnx/forky.
IMHO onnx should not migrate to testing when it isn't understood what is
going wrong there.
Fwiw, building ONNX with ONNX_USE_LITE_PROTO set to ON prevents the crash:
https://salsa.debian.org/deeplearning-team/onnx/-/merge_requests/6
But, it seems that we need to rebuild at least onnxruntime (and pytorch?)
against this new ONNX.
Scheduled a rebuild of onnxruntime.
This had no effect due to ONNX not yet uploaded.
The good news is that changing ONNX and then rebuilding onnxruntime
fixes my minimal testcase in #1126427.
The bad news is that "we need to rebuild at least" is because the ONNX
change changes the ABI:
ImportError:
/usr/lib/python3/dist-packages/onnxruntime/capi/onnxruntime_pybind11_state.cpython-313-x86_64-linux-gnu.so:
undefined symbol: _ZN4onnx39AttributeProto_AttributeType_descriptorEv
This would need a package rename[1] with transition:
Package: libonnx1l
Replaces: libonnx1, libonnx1t64
Breaks: libonnx1 (<< ${source:Version}), libonnx1t64 (<< ${source:Version})
<remove time_t Provides>
rdeps in the transition:
- onnxruntime
- pytorch
- pytorch-cuda (not in testing)
- toppic
The 3 packages in testing build for me with the changed ONNX.
The new ONNX (1.20.0-3) is now in experimental, should I fill a
transition request for it? Or can I upload it to unstable directly?
Best regards,
Dylan
