Closed
Bug 1290954
Opened 8 years ago
Closed 7 years ago
test_non_ascii_paths fails under VirtualBox on Mac host
Categories
(Webtools Graveyard :: DXR, defect)
Webtools Graveyard
DXR
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: erik, Unassigned)
Details
(Whiteboard: easy python)
The important part of the error message is this: Build command for 'code' failed, exited non-zero. Log follows: | rm -rf code | mkdir code | cd code && python -c "import os; os.mkdir('\x8d\xae\xa2\xa0\xef')" | Traceback (most recent call last): | File "<string>", line 1, in <module> | OSError: [Errno 71] Protocol error: '\x8d\xae\xa2\xa0\xef' | make: *** [all] Error 1 There's something unsupported about creating the folder with the icky name in a shared folder. It works fine in the (unshared) ~dxr home dir. It also works fine on a Linux-hosted docker container, which is how our Travis tests pass.
Reporter | ||
Comment 1•8 years ago
|
||
Putting ENV LC_ALL=C.UTF-8 LANG=C.UTF-8 in the Dockerfile avails not.
Reporter | ||
Comment 2•8 years ago
|
||
It's probably HFS+ getting mad about non-UTF-decodeable byte sequences in the names. We'll have to have the test machinery copy the code to be indexed to a non-shared dir first.
Reporter | ||
Updated•8 years ago
|
Whiteboard: easy python
Reporter | ||
Comment 3•7 years ago
|
||
It's test_unicode that fails now. We either moved the tests, or the initial report was mistaken.
Reporter | ||
Comment 4•7 years ago
|
||
Fixed in https://github.com/mozilla/dxr/commit/a4f5f3951148303715908641acf9a684256400d6.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Updated•3 years ago
|
Product: Webtools → Webtools Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•