Bug#903698: sphinxbase: build appears broken for multiple python3 versions
sthibault at debian.org
Tue Oct 16 21:13:59 BST 2018
Samuel Thibault, le mar. 16 oct. 2018 03:04:16 +0200, a ecrit:
> Samuel Thibault, le ven. 12 oct. 2018 04:12:08 +0200, a ecrit:
> > I'm thinking... My chroots have a lib -> usr/lib symlink. Could it be
> > that python somehow gets lost between /lib/python* and /usr/lib/python*,
> > and dependending on e.g. inode number or directory order, we could have
> > one way or the other?
> > Right now I have two VMs with almost the same chroot (differences
> > notably lie in .pyc files), one works, the other doesn't. When I mount
> > the chroot of one on the other, the chroot behavior holds (i.e. the
> > failing chroot keeps failing on the VM which produced a working chroot).
> This is driving me crazy :)
> I have uploaded the VM images on
> Booting one or the other does not matter. What does matter is the
> disk image used to store the chroot. Each VM image has its own
> /var/cache/pbuilder/sphinxbase-build directory (almost exactly the
> same), and it does not matter which of the two I copy, if I copy it
> inside the fails.img disk I'm getting the lintian issue, and if it's
> inside the works.img disk I'm not getting it (there's a fresh checkout
> of sphinbase in /tmp/sphinxbase inside the chroots). And of course my
> own main system is in the fails case, thus preventing me from building
> the package :) tune2fsk does not show any difference between the two
> filesystem options, just creation time, mount count & such.
> Any other idea of what could be different between the two filesystems?
It could very well be e.g. the resulting inode numbers and such, thus my
hypothesis at the top of the quotes above. Python people can have a look
at the fails.img.gz image, where the issue is notably reproducible from
the chroot in /var/cache/pbuilder/sphinxbase-build , building for
instance in /tmp/sphinxbase.
More information about the Pkg-a11y-devel