On 2023-12-26 12:34 +0100, Gioele Barabucci wrote:
> Control: tags -1 moreinfo
> Control: retitle -1 libacl1, debhelper: changelog not detected as binNMU
>
> On Sun, 24 Dec 2023 14:27:22 +0000 Simon McVittie <[email protected]> wrote:
>> libacl1 was recently binNMU'd on all architectures to address version skew.
>> Unfortunately, the binNMU'd version is no longer multiarch co-installable
>> because its changelog differs between architectures:
>> │ │ ├── ./usr/share/doc/libacl1/changelog.Debian.gz
>> │ │ │ ├── changelog.Debian
>> │ │ │ │ @@ -1,13 +1,13 @@
>> │ │ │ │ acl (2.3.1-3+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 sync binNMU versions
>> │ │ │ │
>> │ │ │ │ - -- all / amd64 / i386 Build Daemon (x86-conova-01) ...
>> │ │ │ │ + -- i386 Build Daemon (x86-grnet-01) ...
>> This binNMU changelog entry would normally be separated into
>> changelog.Debian.${DEB_HOST_ARCH}.gz, as can be seen in
>> /usr/share/doc/libxext6/ at the time of writing.
>
> dh_installchangelogs still has the same behavior as before when it
> comes to binNMU and their arch-specific changelogs, independent of the
> trimming logic.
That is not the case, AFAICS. This is what you installed in commit
af652db00:
,----
| sub install_debian_changelog {
| my ($changelog, $package, $arch, $tmp) = @_;
|
| if ($dh{NO_TRIM} || get_buildoption("notrimdch")) {
| # Install the whole changelog.
| install_file($changelog,
"$tmp/usr/share/doc/$package/$changelog_name");
| return;
| }
`----
All the binnmu handling happens _after_ that.
> What seems to have happened here is that the binNMU detection
> failed.
No, the logic in install_debian_changelog is incorrect and does not
handle biNMU entries at all if the changelog is not trimmed.
Cheers,
Sven
