Dear Maintainer,
The reproduced reports failure for the dtrace-tests deb due to the kernel
version string that is included in the USDT ELF notes. The kernel versions
on the two systems (orginal and comparison system) are not the same, and
thus this is flagged as a failure and it also affects the build-id which is
therefore different.
6.12.88+deb13-arm64
#1 SMP Debian 6.12.88-1 (2026-05-15)
vs
6.12.90+deb13-cloud-arm64
#1 SMP Debian 6.12.90-1 (2026-05-22)
This is highly unlikely to be arm specific, just you happened to get the same kernel on the other tested architectures. Most likely this is due to GNUmakefile:KERNELS ?= $(shell uname -r) ... or various other calls to "uname -r" which somehow get embedded in the binaries. Ideally this can be patched out of your package, as relying on the kernel version matching is unlikely to be the same over the course of days, months or years as security updates for the kernel come out. I will take a quick stab at patches... live well, vagrant
Control: tags 1140167 +patch Those were all false leads. It seems embedding some utsname data is the culprit... The attached patch seems to fix this issue as well as embedded hostname and domainname as a side-benefit! Not sure if there are unintended consequences to removing this information; not very familiar with dtrace to be able to evaluate that. live well, vagrant
The data in question is part of the USDT probe data that is stored in ELF notes. It puts the utsname data in there because that helps identify the system where the library or executable with the probes was built. It is not functional information, but rather informative in case issues with the USDT data need to be debugged. In that sense it is perhaps more akin to including gcc version in executables, etc. Since it is information only, it is not meant to be reproducible across systems, which clearly runs afoul with the reproduced processing. Ideally, it should be something that can be ignored because it is not functionally different. I can opt to exclude it from being generated but I would expect that similar issues can pop up elsewhere as well since ELF note data like that can depend on things that will differ between systems where the artifacts are built. The executables in question in dtrace-tests are testsuite triggers that are only ever used in testsuite runs. For those executables, the data is not really important, but USDT probes can be compiled into any executable or library and there it can be quit4e beneficial to have this data available for debugging since such executables and libraries are typically deployed to different systems. <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virus-free.www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
We believe that the bug you reported is fixed in the latest version of dtrace, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1140167@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Kris Van Hees <kvanhees@gmail.com> (supplier of updated dtrace package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmaster@ftp-master.debian.org) Format: 1.8 Date: Tue, 16 Jun 2026 19:46:35 -0400 Source: dtrace Architecture: source Version: 2.0.7-2 Distribution: unstable Urgency: medium Maintainer: Kris Van Hees <kvanhees@gmail.com> Changed-By: Kris Van Hees <kvanhees@gmail.com> Closes: 1140165 1140166 1140167 1140168 Changes: dtrace (2.0.7-2) unstable; urgency=medium . * Apply fixes in control file. (Closes: #1140165) * Use static linking for libbinutils. (Closes: #1140166, #1140168) * Suppress adding utsname info in USDT ELF notes. (Closes: #1140167) Checksums-Sha1: 81996f2016dae1c83853d18d0db9b54b04d68bb5 2143 dtrace_2.0.7-2.dsc 6540103d931ccfcf2580be0af879eb08a3e2eb9a 8844 dtrace_2.0.7-2.debian.tar.xz 339ad50f96405e862e9f2b840433629157d73ff3 7423 dtrace_2.0.7-2_source.buildinfo Checksums-Sha256: f999764bb2cd0d65cce1faa98c023ab6cec3eff74c480fb1ce902dd5268c2a7c 2143 dtrace_2.0.7-2.dsc ee47aecdce4d2579439662ff36e064cf222c9d1392d06835d10a879bb787f148 8844 dtrace_2.0.7-2.debian.tar.xz fb883112ad62baf63317ded5bb291c2746e8484c64b8f9b0c1a7d152821027b4 7423 dtrace_2.0.7-2_source.buildinfo Files: ef41e33168f632f0f505aa863b1035fd 2143 utils optional dtrace_2.0.7-2.dsc 5132e790d990a8755bfc5d1a549f17ed 8844 utils optional dtrace_2.0.7-2.debian.tar.xz 7d5770cfc0b5f019a9e9bfc6ac41ae5a 7423 utils optional dtrace_2.0.7-2_source.buildinfo -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEtgob82PcExn/Co6JEWhSvN91FcAFAmo+r7IACgkQEWhSvN91 FcBt9w//VRKYBnJKCnlj52F/z5VaWUwwc/US6T1nYXZZw/v/xq/LuFTWgJS/dvpF SJD8Zqm5lwSfkmliT7fG6jfwUeC8Tk3VinQlnG/1groqJLhs2SZJvXVcYEwXlPKK C6BtJO/Onua45CQ7g0K3BYigd9pImAzjenRJTB4sjZt+o0cWR4TLnhogdZ9H5fmc cRE8yoB4pi31iV/zu7nmmeF9fOeH2ZgtxTYVas4T2AE2rAc7cLzlpkiP+jP8xSip 4zlhmgtOmf68OHHnt/eCBl5wqXm5Onzc53WLqyVSfuqQl3o6DDkSjm5xgprzHYWP h5xltlv9Ur4OZofOGZvbGayOM268PerF64tv4MnUzpxzRvf310C6z+E0VhpABpGX bxa1QrpB3SU2lmcOd7L+j6sQ07azSgOqvBgmNHfzDe8uyPb/ig9KBxSmCV7wbVrU glld+byTf1LPNl10PDVP7tlDYfOcEWruOcGRG3N55sZ6Ki1ND6vVm6grL98+Hb1V Yi+GjNHaLLauYWD7v9oyP/bRRPi1kiuX6Wrqsu8Lm8VRzsCoKMgh/vNKXyfaG15q QiEgjnK5r4k8CpQUCH6EDEEbZnd/ifIKCj//L95PYnv6Si+VVzH4f+WKSBTXIHWt L+1SJU9IzpDvu4IxnMSvu8VHdcHGBb4CV+/nnarY8kU/EJKdY0I= =wPS2 -----END PGP SIGNATURE-----
This issue is still present with 2.0.7-2. Investigating further. <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virus-free.www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>