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.
What seems to have happened here is that the binNMU detection failed.
The binNMU detection is (and has always been) "the string
`binary-only=yes` appears in the first line of the changelog".
```
if (($. == 1) && ($line =~ /\A\S.*;.*\bbinary-only=yes/)) {
$is_binnmu = 1;
}
```
Please attach the changelog of the binNMU, so that it is possible to
debug why the binNMU detection logic failed in this case.
Regards,
--
Gioele Barabucci
