From helmut at subdivi.de Mon Apr 13 06:51:14 2026 From: helmut at subdivi.de (Helmut Grohne) Date: Mon, 13 Apr 2026 07:51:14 +0200 Subject: [3dprinter-general] Bug#1133406: python3-pynest2d fails to coinstall Message-ID: <20260413055114.GA12763@subdivi.de> Package: python3-pynest2d Version: 5.0.0-3+b6 Severity: serious Justification: violates Debian policy 5.6.34.3 User: debian-qa at lists.debian.org Usertags: fileconflict python3-pynest2d is declared Multi-Arch: same, but fails to coinstall. The file /usr/lib/python3/dist-packages/pynest2d.pyi is shared by python3-pynest2d/5.0.0-3+b6 as present in forky|unstable with varying content. Please ensure that shared files have bit-identical content across architectures, move architecture-dependent files to architecture-dependent paths or remove the Multi-Arch: same field. Kind regards Helmut Grohne From onitake at gmail.com Mon Apr 13 11:56:47 2026 From: onitake at gmail.com (Gregor Riepl) Date: Mon, 13 Apr 2026 12:56:47 +0200 Subject: [3dprinter-general] Bug#1133406: Bug#1133406: python3-pynest2d fails to coinstall In-Reply-To: <20260413055114.GA12763@subdivi.de> References: <20260413055114.GA12763@subdivi.de> <20260413055114.GA12763@subdivi.de> Message-ID: <067d36e2-0668-4dd9-b26a-c66e33554c9c@gmail.com> Hello Helmut, > python3-pynest2d is declared Multi-Arch: same, but fails to coinstall. > > The file /usr/lib/python3/dist-packages/pynest2d.pyi is shared by > python3-pynest2d/5.0.0-3+b6 as present in forky|unstable with varying > content. > > Please ensure that shared files have bit-identical content across > architectures, move architecture-dependent files to > architecture-dependent paths or remove the Multi-Arch: same field. These packages are supposed to be co-installable, and the file in question should be identical across architectures. However, it _is_ an autogenerated file and that increases the risk of mismatches when the generator doesn't behave exactly the same. I just verified this, and the file is in fact identical between release architectures amd64, arm64 and ppc64el. riscv64 doesn't match, because it was built with a different SIP version: --- pynest2d.pyi.amd64 2025-12-06 00:45:50.000000000 +0100 +++ pynest2d.pyi.riscv64 2025-12-08 03:09:28.000000000 +0100 @@ -1,6 +1,6 @@ # The PEP 484 type hints stub file for the pynest2d module. # -# Generated by SIP 6.14.0 +# Generated by SIP 6.15.0 There are no other mismatched lines in the file. This should be easy to fix - I committed a patch that removes the version info from the file: https://salsa.debian.org/3dprinting-team/pynest2d/-/commit/8b0765177ff8f9de8a84d38146875ebed86060d7 @myon Could you upload 5.0.0-4 when you have time? Thank you! Regards, Gregor From helmut at subdivi.de Mon Apr 13 12:12:10 2026 From: helmut at subdivi.de (Helmut Grohne) Date: Mon, 13 Apr 2026 13:12:10 +0200 Subject: [3dprinter-general] Bug#1133406: Bug#1133406: python3-pynest2d fails to coinstall In-Reply-To: <067d36e2-0668-4dd9-b26a-c66e33554c9c@gmail.com> References: <20260413055114.GA12763@subdivi.de> <067d36e2-0668-4dd9-b26a-c66e33554c9c@gmail.com> <20260413055114.GA12763@subdivi.de> Message-ID: <20260413111210.GA2251770@subdivi.de> Hi Gregor, On Mon, Apr 13, 2026 at 12:56:47PM +0200, Gregor Riepl wrote: > These packages are supposed to be co-installable, and the file in question should be identical across architectures. However, it _is_ an autogenerated file and that increases the risk of mismatches when the generator doesn't behave exactly the same. > > I just verified this, and the file is in fact identical between release architectures amd64, arm64 and ppc64el. > riscv64 doesn't match, because it was built with a different SIP version: Thanks for tracking this down. This tends to be a rare problem, because usually packages get built with roughly the same versions of dependencies. riscv64 was lagging behind a a bit and delayed some builds. Its task queue is now below 3 hours. > This should be easy to fix - I committed a patch that removes the version info from the file: > https://salsa.debian.org/3dprinting-team/pynest2d/-/commit/8b0765177ff8f9de8a84d38146875ebed86060d7 The question I have here is whether the cure is better than the disease here. If we simply remove the version, there is no flagging of different versions being used. Therefore, bugs can become subtly architecture-specific. This may make debugging them harder. We don't technically need the version information as it is recorded in the .buildinfo. So another way to resolve this would be asking the release team for a binNMU with the expectation that such a version difference is rare. You're the domain expert here, so I trust your choice here. Helmut