Bug#903698: sphinxbase: build appears broken for multiple python3 versions

[Samuel Thibault]

Samuel Thibault, le ven. 12 oct. 2018 03:27:47 +0200, a ecrit:
> Samuel Thibault, le ven. 12 oct. 2018 03:02:32 +0200, a ecrit:
> > Samuel Thibault, le ven. 12 oct. 2018 00:55:47 +0200, a ecrit:
> > > Samuel Thibault, le ven. 12 oct. 2018 00:38:39 +0200, a ecrit:
> > > > To be sure, I have installed a VM from scratch with stretch (default
> > > > install, just not the graphical desktop task), created a chroot with
> > > > pbuilder there, and ran in it, and got the issue there too...
> > 
> > (actually I can't reproduce the issue with the stretch VM, I guess I
> > read wrongly previously)
> > 
> > > Doing the same with a VM with buster, I don't get the issue... I'll now
> > > be able to check what differences there can be in the chroots.
> > 
> > I dugged more and more... It seems the issue is... that my box hostname
> > is "function"...
> 
> Mmm, no, I have changed the hostname of my new "function" VM back to
> something else than "function" and I still have the issue there.
> 
> I have checked the chroot's dpkg -l, the environment, / is ext4 with
> relatime in both case, the kernel is the same, I even used -cpu host
> -smp 4 to expose the same CPU. What else?

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

Samuel