[ adding reproducible-builds@ to the loop, after bouncing the first
email ]

On Fri, Sep 02, 2016 at 09:53:07PM +1000, Ben Finney wrote:
> The package ‘dput’ explicitly sets the ‘LC_ALL’ environment variable
> to “C.UTF-8”, and exports that value to sub-processes
> <URL:https://sources.debian.net/src/dput/0.10.1/debian/rules/>.
> Yet the latest reproducible-build attempt reports failure
> <URL:https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/dput.html>.

This started to happen the 2016-08-27 with 0.10; the 2016-08-26 the
version build happily succeeded (both in unstable/i386).

I'm not aware of any change of any sort in our infrastructure that day.

> Specifically, the build system does not detect a UTF-8 locale:
> =====
> Traceback (most recent call last):
>   […]
> UnicodeEncodeError: 'ascii' codec can't encode character u'\u2009' in 
> position 186: ordinal not in range(128)
> E: pybuild pybuild:276: test: plugin distutils failed with: exit code=1: 
> python2.7 setup.py test 
> dh_auto_test: pybuild --test -i python{version} -p 2.7 returned exit code 13
> debian/rules:24: recipe for target 'build' failed
> make: *** [build] Error 25
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
> =====

I kinda of leen toward some kind of regression in dput itself, not sure
what (and haven't digged deeper).

> This happens only on the reproducible build server; when running on a
> system that actually has a UTF-8 terminal locale, the build succeeds.

In the first build we export LANG=C, I wonder if that messes with
python's encoding foo.

                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
more about me:  https://mapreri.org                             : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

Attachment: signature.asc
Description: PGP signature

Reproducible-builds mailing list

Reply via email to