> On Mon, 18 Dec 2017 at 23:30:05 +0000, Simon McVittie wrote: > > dpkg-deb: building package 'libglib2.0-data' in > > '../libglib2.0-data_2.54.2-2_all.deb'. > > tar: ./usr/share/locale/en_CA/LC_MESSAGES/glib20.mo/: Cannot savedir: Not a > > directory > > This seems to be a symptom of some more general problem on the > reproducible-builds builders - I would guess it's either the > (FUSE?) filesystem, or a LD_PRELOAD hack that intercepts stat(), like > fakeroot does. Build logs indicate that regular files are sometimes > treated as directories by install(1), resulting in the build being > incomplete and unreproducible even in cases where it doesn't FTBFS:
This "Not a directory" problem has started popping up in PostgreSQL build logs: https://buildd.debian.org/status/fetch.php?pkg=pgagent&arch=alpha&ver=4.0.0-7&stamp=1602009768&raw=0 Dropping cluster 13/regress ... ### End 13 installcheck ### make[1]: Leaving directory '/<<PKGBUILDDIR>>' dh_strip_nondeterminism -a dh_compress -a dh_fixperms -a dh_missing -a dh_dwz -a -a Can't opendir(debian/pgagent/usr/share/doc/pgagent/changelog.Debian.gz): Not a directory at /usr/bin/dh_dwz line 119. https://buildd.debian.org/status/fetch.php?pkg=pgagent&arch=sparc64&ver=4.0.0-7&stamp=1601991893&raw=0 It has also been seen on amd64. PG extension packages have started to run tests at build time, which is done via pg_virtualenv. Internally, for creating the temporary PostgreSQL server instance, LD_PRELOAD is unset, and that seems to be what confuses the "dh" and dpkg-buildpackage processes that share the same fakeroot instance. jwilk did some debugging (thanks!) and came up with this simple recipe: $ fakeroot sh -c 'mkdir foo; env -u LD_PRELOAD rmdir foo; touch bar; stat bar | grep directory' Size: 0 Blocks: 0 IO Block: 4096 directory So, if "foo" is removed without fakeroot knowing, the "bar" file is reported as a directory. (It doesn't get it wrong for me, it depends on inode numbers being recycled and similar.) jwilk also noted that glib-2.0's debian/rules unsets LD_PRELOAD for the test suite too which strengthens the evidence that fakeroot is to blame. I'll see to move the PG extension packages to `R³: no`, that seems to be the best option in my case. Christoph
