Hi Santiago and Lintian maintainers, Thanks, Santiago, for reaching out.
Lintian maintainers: Skip to the second last paragraph. On Tue, Jan 20, 2026 at 10:17:56PM +0100, Santiago Vila wrote: > I finally understand the information in tracker.debian.org about recode when > it > says this: > > " There are issues with the multiarch metadata for this > package. librecode3 conflicts on > /usr/share/doc/librecode3/changelog.Debian.gz on any two of amd64, > arm64, armhf, i386, and 3 more Can you help me improve the message to make it easier to understand to you? Evidently, you did follow the link. Can you suggest improvements to the wiki page to make this more clear? > The diffoscope program shows these differences between amd64 and i386: > > │ │ │ │ recode (3.7.15-1+b1) sid; urgency=low, binary-only=yes > │ │ │ │ > │ │ │ │ - * Binary-only non-maintainer upload for amd64; no source changes. > │ │ │ │ + * Binary-only non-maintainer upload for i386; no source changes. > │ │ │ │ * Rebuild to enable GCS on arm64 > │ │ │ │ > │ │ │ │ - -- all / amd64 / i386 Build Daemon (x86-grnet-03) > <[email protected]> Sat, 17 Jan 2026 09:09:49 +0000 > │ │ │ │ + -- all / amd64 / i386 Build Daemon (x86-conova-02) > <[email protected]> Sat, 17 Jan 2026 17:13:40 > +0000 > > > Should I really change "Multi-Arch: same" to "Multi-Arch: no" as suggested > by the multi-arch hinter, or maybe we should change the way we do > binNMUs? (or maybe I can just make another upload so that all archs > are in sync again?) In theory, this kind of problem should never happen. It is known that binNMU changelog entries vary with the architecture. Therefore, dh_installchangelogs has logic to separate binNMU entry from the main changelog. The binNMU entry should be installed to /usr/share/doc/PKG/changelog.Debian.ARCH.gz. The fact that the entry shows up in your main changelog indicates that this logic is not working as expected. I attempted locally reproducing the problem using sbuild and --make-binNMU. The problem is readily there. In particular, the binNMU entry shows up in both the architecture-specific changelog and the main changelog. I then stumbled into the build log. It says: | make[1]: Leaving directory '/build/reproducible-path/recode-3.7.15' | debian/rules override_dh_installchangelogs | make[1]: Entering directory '/build/reproducible-path/recode-3.7.15' | dh_installchangelogs --no-trim | dh_installchangelogs: warning: Could not parse timestamp 'Sat Jan 27 14:58:57 MST 1996'. debian/changelog will not be trimmed. | dh_installchangelogs: warning: Could not parse timestamp 'Sat Jan 27 14:58:57 MST 1996'. debian/changelog will not be trimmed. | dh_installchangelogs: warning: debian/changelog could not be trimmed. The full changelog will be installed. | dh_installchangelogs: warning: debian/changelog could not be trimmed. The full changelog will be installed. | make[1]: Leaving directory '/build/reproducible-path/recode-3.7.15' It says that dh_installchangelogs meant to trim (and in this case this refers to removing the binNMU entry, not the tail) the changelog and gave up. Could you fix the changelog? > I'm confused because this seems to me the kind of issue that a normal > maintainer should not worry about. I am inclined to agree here. Arguably, if debhelper insists on valid time stamps in the changelog, then maybe lintian should validate them all and flag bad time stamps in debian/changelog as an error? If error is too much, issue a warning unless there is a M-A:same package in which case it definitely needs to be an error. Helmut
