17
100%
master: 100%

Ran 09 Dec 2015 05:27PM UTC

Files 1

Run time 0s

Badge

Embed ▾

Committed 09 Dec 2015 05:25PM UTC coverage: 99.757%. Remained the same

Job # FORCE_TEST_VCS=bzr

Build Type

push

travis-ci

Committed by Marius Gedminas

Commit Message

Fix the failing Bzr encoding test

Once again I admit that I don't fully understand the issue.

There are two encodings on Windows: so-called ANSI (e.g. cp1252) and the
so-called OEM (eg. cp437).  On my test box locale.getpreferredencoding()
returns 'cp1252', while sys.stdout.encoding is 'cp437'.

When I run the tests manually, 'bzr ls' returns '\x82.txt' -- at least
when I use subprocess.Popen().  \x82 is the cp437 encoding of eacute.

When I use os.popen('bzr ls').read(), I get '\xe9.txt'.  This baffles me
to no end.  How come os.popen() and subprocess.Popen(..., shell=True)
act differently?

When the tests run in my Jenkins, they pass fine, which implies that
'bzr ls' returns '\xe9.txt' in the Jenkins environment.  No idea how
that differs from my interactive environment: both run on the same
Windows VM.

When the tests run in Appveyor, they fail the same way they do when I
run them by hand.  So I guess this commit ought to fix Appveyor and
manual test runs.  We'll see about Jenkins in about two hours (because
for no discernible reason a test run for a single Python interpreter now
takes 1255 seconds instead of 34 seconds I get when I run tox manually
ON THE SAME MACHINE).

Coverage Stats

411 of 412 relevant lines covered (99.76%)

1.0 hits per line

mgedmin / check-manifest / 198 / 17
100%
master: 100%

README BADGES
x

Markdown

Textile

RDoc

HTML

Rst

Source Files on job 198.17 (FORCE_TEST_VCS=bzr)

mgedmin / check-manifest / 198 / 17 100% master: 100%

README BADGES x

Markdown

Textile

RDoc

HTML

Rst

Source Files on job 198.17 (FORCE_TEST_VCS=bzr)

mgedmin / check-manifest / 198 / 17
100%
master: 100%

README BADGES
x