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

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Simon McVittie-7
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.

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.

The most relevant bits of the (armhf + all) build log (the i386 + all
failure is similar, but en_GB is the one that fails there):

make[4]: Entering directory '/build/1st/glib2.0-2.54.2/debian/build/deb/po'
mkdir -p /build/1st/glib2.0-2.54.2/debian/tmp/usr/share; \
catalogs='af.gmo am.gmo an.gmo ar.gmo as.gmo ast.gmo az.gmo be.gmo [hidden email] bg.gmo bn.gmo bn_IN.gmo bs.gmo ca.gmo [hidden email] cs.gmo cy.gmo da.gmo de.gmo dz.gmo el.gmo en_CA.gmo en_GB.gmo [hidden email] eo.gmo es.gmo et.gmo eu.gmo fa.gmo fi.gmo fr.gmo fur.gmo ga.gmo gd.gmo gl.gmo gu.gmo he.gmo hi.gmo hr.gmo hu.gmo hy.gmo id.gmo is.gmo it.gmo ja.gmo ka.gmo kk.gmo kn.gmo ko.gmo ku.gmo lt.gmo lv.gmo mai.gmo mg.gmo mk.gmo ml.gmo mn.gmo mr.gmo ms.gmo nb.gmo nds.gmo ne.gmo nl.gmo nn.gmo oc.gmo or.gmo pa.gmo pl.gmo ps.gmo pt.gmo pt_BR.gmo ro.gmo ru.gmo rw.gmo si.gmo sk.gmo sl.gmo sq.gmo sr.gmo [hidden email] [hidden email] sv.gmo ta.gmo te.gmo tg.gmo th.gmo tl.gmo tr.gmo ug.gmo tt.gmo uk.gmo vi.gmo wa.gmo xh.gmo yi.gmo zh_CN.gmo zh_HK.gmo zh_TW.gmo'; \
for cat in $catalogs; do \
  cat=`basename $cat`; \
  case "$cat" in \
    *.gmo) destdir=/usr/share/locale;; \
    *)     destdir=/usr/lib/arm-linux-gnueabihf/locale;; \
  esac; \
  lang=`echo $cat | sed 's/\.gmo$//'`; \
  dir=/build/1st/glib2.0-2.54.2/debian/tmp$destdir/$lang/LC_MESSAGES; \
  mkdir -p $dir; \
  if test -r $cat; then \
    /usr/bin/install -c -m 644 $cat $dir/glib20.mo; \
    echo "installing $cat as $dir/glib20.mo"; \
  else \
    /usr/bin/install -c -m 644 ../../../../po/$cat $dir/glib20.mo; \
    echo "installing ../../../../po/$cat as" \
         "$dir/glib20.mo"; \
  fi; \
...
installing ../../../../po/af.gmo as /build/1st/glib2.0-2.54.2/debian/tmp/usr/share/locale/af/LC_MESSAGES/glib20.mo
... and the same for many more languages ...
   dh_strip_nondeterminism
...
        Normalized debian/libglib2.0-data/usr/share/locale/dz/LC_MESSAGES/glib20.mo
... and the same for many more languages ...
...
   dh_builddeb
...
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
tar: Exiting with failure status due to previous errors
...
dpkg-deb: error: tar -cf subprocess returned error exit status 2
dh_builddeb: dpkg-deb --build debian/libglib2.0-data .. returned exit code 2

Thanks,
    smcv

Reply | Threaded
Open this post in threaded view
|

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
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