On Wed, Jan 21, 2026 at 07:24:42AM +0100, Helmut Grohne wrote: > 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?
Well, we really want the library to be "Multi-Arch: same", as I guess most libraries should be, so instead of "there are issues with the multiarch metadata", it could say that there is a mismatch between the multiarch metadata and reality. Maybe something like this: Package declares "Multi-Arch: same" but librecode3 conflicts etc. > > 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. This is why I reassigned the bug to debhelper. > 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? Oh, well, yes I can, but I find that an excuse not good enough for debhelper to provide the full changelog and/or put everything in changelog.Debian instead of changelog.Debian.amd64. > > 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? Yes, good idea. We should know about this via a lintian warning (or even an error) if some other tools (like debhelper) will not work properly because of this. Thanks.
