Re: Bug#884662: glib2.0: sometimes FTBFS on reproducible-builds: tar: ./usr/share/locale/en_??/LC_MESSAGES/glib20.mo/: Cannot savedir: Not a directory

[Guillem Jover <guillem@debian.org>]

Hi!

On Mon, 2017-12-18 at 23:30:05 +0000, Simon McVittie wrote:
> On Mon, 18 Dec 2017 at 09:17:46 +0000, Simon McVittie wrote:
> > [#884662] (a build failure inside dpkg-builddeb, not a test failure)
> > I don't know what is going on, and it doesn't seem particularly likely
> > to be a GLib bug - GLib just puts files in a tree like any other package,
> > so I'm not sure how it would trigger this particular failure. It can be
> > seen in these logs:
> > https://tests.reproducible-builds.org/debian/rbuild/buster/i386/glib2.0_2.54.1-1.rbuild.log
> > https://tests.reproducible-builds.org/debian/rbuild/unstable/armhf/glib2.0_2.54.2-2.rbuild.log
> > (not build2, so we presumably can't blame disorderfs either).
> 
> tar and dpkg maintainers: does this look at all familiar to you, or
> can you think of anything that GLib might be doing strangely with its
> translations that would somehow make tar think it needed to treat the
> regular file glib20.mo as a directory? It's an ordinary GNU gettext .gmo
> file, with nothing GLib-specific that I'm aware of, and in particular
> File::StripNondeterminism was able to open and rewrite it like a
> regular file.

Nothing I've seen before, no.

> This is on the reproducible-builds infrastructure, so if there are any
> oddities implied by that, they apply here (for example I think it's a
> tmpfs - although I've been able to build GLib in a large tmpfs on my
> laptop without problems).
> 
> I don't know whether it's significant or just coincidence that the two
> languages affected in the failing builds that I've seen are the only two
> of the form en_??.
> 
> Unfortunately this is pbuilder, not sbuild, so the log doesn't list the
> versions of tar and dpkg used.

So I tried to invoke tar with some paths via -T (which is what
dpkg-deb is using) with a final ‘/’ for a filename and that does not
get handled like a directory.

Skimmed over tar's code, which is the one failing here, and didn't see
anything obvious. So without further analysis this does smell like a
problem in the repro environment, one of the nested fakers, filesystem
or similar, or a combination of those perhaps.

Thanks,
Guillem