Summary: | dev-python/python-termstyle-0.1.10: fails tests | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Diego Elio Pettenò (RETIRED) <flameeyes> |
Component: | Current packages | Assignee: | Alex Brandt (RETIRED) <alunduil> |
Status: | RESOLVED TEST-REQUEST | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build.log |
Description
Diego Elio Pettenò (RETIRED)
2014-10-25 17:26:46 UTC
Hey Diego, Thanks for the report. It looks like the failure is due to LC_ALL="C" being set (I have not confirmed this yet) and upsetting the python character encoding detection. Is LC_ALL="C" something that we should expect as common and test against? I'm fine with that if it's the case but received the impression that users generally use a UTF-8 locale set by eselect (which does not set LC_ALL from what I've observed). The localization materials I used for reference are these: https://wiki.gentoo.org/wiki/Localization/HOWTO They indicate that the use of LC_ALL should be avoided. Which aligns with my observation that it's unset by eselect during locale selection. Thanks for any input you can provide. Let me know if I should be including this case in my testing routine. If I should I'll go ahead and get this fixed when I get a chance. Created attachment 388072 [details] build.log Autoattach of build.log -- if there are any issues with this file please add bug to tracker bug 527870 If it breaks with LC_ALL=C then you should fix or skip the tests in that configuration. I've pushed before for the council to use a decent default (UTF-8 locale) but until that doesn't happen, LC_ALL=C is a valid config. Is it possible to get a tinderbox run against the version in my overlay to verify that my testing was correct? |