[Python-modules-team] Bug#916225: python3-docutils doesn't install on Sid armel/armhf/mips/mipsel

Simon McVittie smcv at debian.org
Tue Dec 11 19:43:26 GMT 2018

Control: tags -1 + moreinfo

On Wed, 12 Dec 2018 at 00:45:34 +0800, You-Sheng Yang wrote:
> Somehow dash failed to expand /usr/share/docutils/scripts/python3/*, so
> that exec variable is simply '/usr/share/docutils/scripts/python3/*',
> which is later expanded as extra dozens of update-alternatives'   
> arguments. To be more detailed, at the time executed, dash path   
> expansion still worked as it's able to expand /usr/share/* and
> /usr/share/docutils*, but it failed to expand /usr/share/docutils/* and
> any other pattern with a /usr/share/docutils/ prefix. Files has been
> installed correctly and accessible, but dash simply unable to expand
> such globs.

The obvious question is: why don't basic operations like glob() work
on the system in question?

Is there something unusual on the system where these expansions failed,
like a non-standard filesystem or kernel, or weird permissions
(directories not 0755 or files not 0755 or 0644) anywhere under

You mentioned Docker containers. What is the host system and how are
these Docker containers configured? If /usr is an overlayfs or similar,
failing to evaluate a glob might be a bug in the overlay implementation?

(Since 32-bit ARM and MIPS are not exactly fast machines, I would
suggest building your kernels with dpkg-buildpackage -B and using an
x86_64 machine to build documentation, which would maybe sidestep this
by not needing docutils at all.)

> Replace that path glob with a `find ... -type f` fixes the problem.

Sorry, I don't think python3-docutils can be expected to swap a path
expansion for a subprocess that ought to be equivalent to work around
whatever is going on with these systems - and definitely not without
understanding what it is that's going wrong and why.


More information about the Python-modules-team mailing list