Package: dh-strip-nondeterminism
Version: 1.6.3-2
Severity: important
Control: affects -1 + libruby2.5
libruby2.5 is marked Multi-Arch: same. However trying to coinstall it
for multiple architectures yields an unpack error:
| Unpacking libruby2.5:ppc64el (2.5.7-1+b1) ...
| dpkg: error processing archive
/tmp/apt-dpkg-install-ogGPd3/261-libruby2.5_2.5.7-1+b1_ppc64el.deb (--unpack):
| trying to overwrite shared
'/usr/lib/ruby/2.5.0/rdoc/generator/template/darkfish/images/macFFBgHack.png',
which is different from other instances of package libruby2.5:ppc64el
| dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Now looking into the ruby2.5 source package, we see that there is a
macFFBgHack.png:
028ebc15ad448256635073ebedaf1282006227f4cef68a8402c6c4d7001994a8
lib/rdoc/generator/template/darkfish/images/macFFBgHack.png
However it differs from the one being installed:
5921908de94f1f1c32b39848cab4e01738eead861484034896a5232aba8ae106
amd64/usr/lib/ruby/2.5.0/rdoc/generator/template/darkfish/images/macFFBgHack.png
9c9ea17044f29a72ec885908a94e338f478048963b70c2dff1ccba43341f82de
arm64/usr/lib/ruby/2.5.0/rdoc/generator/template/darkfish/images/macFFBgHack.png
af77542eac693dea616f874d680cc8060e554fc169ffa5c27f5b9cf7616e4ec7
ppc64el/usr/lib/ruby/2.5.0/rdoc/generator/template/darkfish/images/macFFBgHack.png
eba3347383f8247df7f6055dc3144f79313107fc4ad702b13a902d2d9c494344
s390x/usr/lib/ruby/2.5.0/rdoc/generator/template/darkfish/images/macFFBgHack.png
Where does the difference come from?
diffoscope tells us that it likely has to do with some timestamp:
| $ diffoscope
{amd64,ppc64el}/usr/lib/ruby/2.5.0/rdoc/generator/template/darkfish/images/macFFBgHack.png
| 2020-02-06 19:27:08 W: diffoscope.main: Fuzzy-matching is currently disabled
as the "tlsh" module is unavailable.
| ---
amd64/usr/lib/ruby/2.5.0/rdoc/generator/template/darkfish/images/macFFBgHack.png
| +++
ppc64el/usr/lib/ruby/2.5.0/rdoc/generator/template/darkfish/images/macFFBgHack.png
| │┄ Command `sng` exited with exit code 1. Standard output:
| │┄ sng: in stdin, 0 sBIT red bits not valid for 8bit/sample image
| @@ -3,13 +3,13 @@
| 00000020: 6300 0000 0473 4249 5408 0808 087c 0864 c....sBIT....|.d
| 00000030: 8800 0000 0970 4859 7300 000b 1200 000b .....pHYs.......
| 00000040: 1201 d2dd 7efc 0000 001c 7445 5874 536f ....~.....tEXtSo
| 00000050: 6674 7761 7265 0041 646f 6265 2046 6972 ftware.Adobe Fir
| 00000060: 6577 6f72 6b73 2043 5333 98d6 4603 0000 eworks CS3..F...
| 00000070: 0027 7445 5874 4372 6561 7469 6f6e 2054 .'tEXtCreation T
| 00000080: 696d 6500 3230 3230 2d30 312d 3139 5431 ime.2020-01-19T1
| -00000090: 383a 3036 3a34 362d 3030 3a30 30c9 ea2c 8:06:46-00:00..,
| -000000a0: e700 0000 2849 4441 5448 89ed cd41 0100 ....(IDATH...A..
| +00000090: 373a 3438 3a33 372d 3030 3a30 30ec 38b8 7:48:37-00:00.8.
| +000000a0: 4e00 0000 2849 4441 5448 89ed cd41 0100 N...(IDATH...A..
| 000000b0: 3008 0021 b47f a755 5b0a 7f47 0106 cfb1 0..!...U[..G....
| 000000c0: bd0e 4a4a 4a4a 4a4a 4a4a 4ac0 0759 d100 ..JJJJJJJJJ..Y..
| 000000d0: f11f fc9f 8500 0000 0049 454e 44ae 4260 .........IEND.B`
| 000000e0: 82 .
| $
But why would anything change the timestamp of a plain png file which
isn't created during build?
A look into the build logs revewals:
https://buildd.debian.org/status/fetch.php?pkg=ruby2.5&arch=amd64&ver=2.5.7-1%2Bb1&stamp=1579457813&raw=0
| dh_strip_nondeterminism -a
| Using 1579457206 as canonical time
| ...
| Normalizing
debian/libruby2.5/usr/lib/ruby/2.5.0/rdoc/generator/template/darkfish/images/macFFBgHack.png
using File::StripNondeterminism::handlers::png
https://buildd.debian.org/status/fetch.php?pkg=ruby2.5&arch=ppc64el&ver=2.5.7-1%2Bb1&stamp=1579456774&raw=0
| dh_strip_nondeterminism -a
| Using 1579456117 as canonical time
| ...
| Normalizing
debian/libruby2.5/usr/lib/ruby/2.5.0/rdoc/generator/template/darkfish/images/macFFBgHack.png
using File::StripNondeterminism::handlers::png
So what breaks macFFBgHack.png is nothing else than
dh_strip_nondeterminism.
This could affect any Multi-Arch: same package that is being binNMUed. I
think the only sane solution to this problem is having
dh_strip_nondeterminism skip binNMU changelog entries when generating
the timestamp.
Helmut
