On 17/05/26 11:58, Dominique Dumont wrote:
Mulitarch hinter mentions:There are issues with the multiarch metadata for this package. libisoburn-dev conflicts on /usr/share/doc/libisoburn-dev/changelog.Debian.gz on loong64 <-> amd64, arm64, armhf and 4 more libisoburn1t64 conflicts on /usr/share/doc/libisoburn1t64/changelog.Debian.gz on loong64 <-> amd64, arm64, armhf and 4 more As suggested by the wiki page, I've downloaded and compared loong64 and amd64 binary packages. Turns out that both have a truncated changelog. But the loong64 package has less entries.
Hi, the issue you are seeing is due to the fact that the loong64 buildd chroot has (had) a newer version of debhelper compared to the one used in the other archs.
Here is an edited version of what I said on #debian-devel a few days ago when the same issue has been described there:
* The newer debhelper has a new cutoff date for the changelog trimming function of dh_install_changelogs, so the generated changelogs may be different.
* This is issue is a special case of "use of different package versions in different buildd chroots". If the amd64 buildd chroot has a program that generates a file in /usr/share (say, pod2man) at version X and the loong64 has version X+1, then the generated file (a manpage, for example) may/will be slightly different.
* pod2man is just an example. What must not change between two binNMUs is the sum of all packages that are used to produce files that can cause M-A problems. The list is long (pod2man, texinfo, sphinx, doxygen, pandoc...) but luckily they are updated quite seldomly.
* The only solution to this problem is that 1) all buildd chroots must be updated at the same time, and 2) all binNMU must run inside the same dinstall window. Otherwise there will always be the risk of package version skew and M-A issues.
Regards, -- Gioele Barabucci
