Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test is failing #38

Open
opoplawski opened this issue Apr 6, 2016 · 5 comments
Open

Test is failing #38

opoplawski opened this issue Apr 6, 2016 · 5 comments

Comments

@opoplawski
Copy link

I'm getting:

+ nosetests-2.7 -e ssh
......................E.............
======================================================================
ERROR: tests.local_tests.LocalProcessTests.exception_message_shows_unicode_bytes
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/builddir/build/BUILD/spur.py-0.3.15/tests/process_test_set.py", line 22, in run_test
    test_func(shell)
  File "/builddir/build/BUILD/spur.py-0.3.15/tests/process_test_set.py", line 108, in exception_message_shows_unicode_bytes
    shell.run(["sh", "-c", _u("echo ‽; exit 1")])
  File "/builddir/build/BUILD/spur.py-0.3.15/spur/local.py", line 109, in run
    return self.spawn(*args, **kwargs).wait_for_result()
  File "/builddir/build/BUILD/spur.py-0.3.15/spur/local.py", line 66, in spawn
    **self._subprocess_args(command, *args, **kwargs)
  File "/usr/lib64/python2.7/subprocess.py", line 710, in __init__
    errread, errwrite)
  File "/usr/lib64/python2.7/subprocess.py", line 1335, in _execute_child
    raise child_exception
TypeError: execv() arg 2 must contain only strings

----------------------------------------------------------------------
@mwilliamson
Copy link
Owner

Hmm, seems to work okay when I try it out myself. What locale is your system using?

@opoplawski
Copy link
Author

LANG=en_US.UTF-8

With python-3.5 I get:

ERROR: tests.local_tests.LocalProcessTests.exception_message_shows_unicode_bytes
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.5/site-packages/nose/case.py", line 198, in runTest
    self.test(*self.arg)
  File "/builddir/build/BUILD/spur.py-0.3.15/tests/process_test_set.py", line 22, in run_test
    test_func(shell)
  File "/builddir/build/BUILD/spur.py-0.3.15/tests/process_test_set.py", line 108, in exception_message_shows_unicode_bytes
    shell.run(["sh", "-c", _u("echo \u203d; exit 1")])
  File "/builddir/build/BUILD/spur.py-0.3.15/spur/local.py", line 109, in run
    return self.spawn(*args, **kwargs).wait_for_result()
  File "/builddir/build/BUILD/spur.py-0.3.15/spur/local.py", line 66, in spawn
    **self._subprocess_args(command, *args, **kwargs)
  File "/usr/lib64/python3.5/subprocess.py", line 950, in __init__
    restore_signals, start_new_session)
  File "/usr/lib64/python3.5/subprocess.py", line 1483, in _execute_child
    restore_signals, start_new_session, preexec_fn)
UnicodeEncodeError: 'ascii' codec can't encode character '\u203d' in position 5: ordinal not in range(128)

I'm seeing this on Fedora rawhide. I don't see it with python 2.7 on RHEL7.

@opoplawski
Copy link
Author

Actually this seems to only be an issue for me when building for Fedora 25 using mock on my EL7 machine. So something fairly strange seems to be going on. koji build for F25 worked http://koji.fedoraproject.org/koji/taskinfo?taskID=13569930

@mwilliamson
Copy link
Owner

Seems to be affected by the underlying locale. When I run the tests with LC_ALL=C, I get similar failures. I'm afraid I don't have time to track down the cause at the moment, but I'd be extremely interested (and grateful!) if you manage to get any further.

@mwilliamson
Copy link
Owner

locale.getpreferredencoding() might be useful in working out whether the system expects bytes or str (in Python 3-land, equivalents for Python 2), possible needing to locale.setlocale(locale.LC_ALL, '') beforehand. Alternatively, the code could just try both when loading the module and seeing which one actually works.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants