The package fail to propagate to testing, as can be seen on
<URL: https://tracker.debian.org/pkg/xnnpack >, because the autopkgtest
check for onnxruntime fail with the new package.  This is the error:

<URL: https://ci.debian.net/packages/o/onnxruntime/testing/amd64/52642186/ >
 39s autopkgtest [09:56:56]: test build: [-----------------------
 39s /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu/libonnxruntime.so: undefined reference to `xnn_setup_convolution2d_nhwc_qc8'
 39s /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu/libonnxruntime.so: undefined reference to `xnn_create_convolution2d_nhwc_qc8'
 39s collect2: error: ld returned 1 exit status
 40s autopkgtest [09:56:57]: test build: -----------------------]

Looking at the git history on salsa, I see that the symbols in question
was removed in commit 42982d3b267293bbc71d3e040126fd1a5fb532f7 when a
new upstream version 0.0~git20240229.fcbf55a was imported.

Such ABI changes require an updated SONAME to avoid breaking programs in
Debian, for example with a rename from libxnnpack0 to libxnnpack1.

control: block 1084103 by -1
control: block -1 by 1080510
control: block 1081664 by 1080510
xnnpack currently does not have a symbol control file, and had only
one reverse dependency pytorch until the recent upload of onnxruntime.

I was working on bumping pytorch's dependencies recently, without noticing
it having onnxruntime as rdep. And that's why I did not check through the
symbol changes and uploaded a breaking version.

Since pytorch 2.4 is now in sid, the only broken package is onnxruntime.
I have just packaged a new version of ort (see: 1080510) which can be used
with latest xnnpack in sid.

Thanks,
Shengqi Chen

[陈 晟祺]

Why does it not have a symbol control file?  Is there any hope to reach
upstream proper shared library practice?

Perhaps this would become easier with a symbol control file?

It is the only broken package in the Debian archive, but there might be
billions of software systems built locally on users machine which are
also broken.  Proper SONAME handling would reduce the problem.

Rebuilding and uploading a new onnxruntime make sense, but is not really
addressing this problem, which is incorrect handling of a shared
library.  Forcing unexpecting users to rebuild their software is not a
good approach.

Hi,

Mo Zhou packaged it solely as dependency of pytorch at first. I believe symbol
control file was not crucial that time, since xnnpack and pytorch are tightly
coupled. Also the library have some many platform-dependent symbols,
adding labour to maintaining symbol files.

And from the source side, xnnpack project is in very active development.
It has even not got any tags, all version we packed are git snapshots.
Upstream does not use any SOVERSION mechanism either.

But yes, I can try to put forward that with upstream.

Sure. I agree.

I plan to upload new fixed onnxruntime first. Then I would do the SONAME bump
without change upstream version, anticipating a smooth transition with no extra
problems. Do you think this can work?

BTW the ABI changes in onnx 1.16.2 also breaks onnxruntime [1]. It might also
need similar handling.


[1]: https://ci.debian.net/packages/o/onnxruntime/testing/amd64/52820493/

Thanks,
Shengqi CHen