Now there's a issue: https://github.com/kimchi-project/kimchi/issues/333 The reason of this issue is because high level cherrpy version make some change about set_response. The high level cherrpy encode the unicode error message by itself. So the kimchi do not encode the unicode error message any more. It is right, the cherrpy should encode the unicode error message. Now we can require the cherrypy version to solve this problem. we can also check the cherrypy version in kimchi code as follow in order to avoid to require the cherrypy version. like: if cherrypy.__version__ << 3.2.5: return res else: return res.encode("utf-8") -- Thanks and best regards! Sheldon Feng(冯少合)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center
于 2014年03月03日 17:50, Sheldon 写道:
Now there's a issue: https://github.com/kimchi-project/kimchi/issues/333
The reason of this issue is because high level cherrpy version make some change about set_response.
The high level cherrpy encode the unicode error message by itself.
So the kimchi do not encode the unicode error message any more.
It is right, the cherrpy should encode the unicode error message.
Now we can require the cherrypy version to solve this problem.
we can also check the cherrypy version in kimchi code as follow in order to avoid to require the cherrypy version.
like: if cherrypy.__version__ << 3.2.5: return res else: return res.encode("utf-8")
Maybe it's better to use distutils.version from distutils.version import LooseVersion if LooseVersion(cherrypy.__version__) < LooseVersion('3.2.5'): blah else: blah -- Thanks and best regards! Zhou Zheng Sheng / 周征晟 E-mail: zhshzhou@linux.vnet.ibm.com Telephone: 86-10-82454397
Shelon, I got another idea to check of the string is utf-8 already not checking the cherrypy's version, see the below: | try: res.decode('utf-8') ||res.encode("utf-8") return res; except UnicodeDecodeError: return|res.encode("utf-8") 2014/3/3 17:50, Sheldon:
Now there's a issue: https://github.com/kimchi-project/kimchi/issues/333
The reason of this issue is because high level cherrpy version make some change about set_response.
The high level cherrpy encode the unicode error message by itself.
So the kimchi do not encode the unicode error message any more.
It is right, the cherrpy should encode the unicode error message.
Now we can require the cherrypy version to solve this problem.
we can also check the cherrypy version in kimchi code as follow in order to avoid to require the cherrypy version.
like: if cherrypy.__version__ << 3.2.5: return res else: return res.encode("utf-8")
On 03/03/2014 12:20 PM, Shu Ming wrote:
Shelon,
I got another idea to check of the string is utf-8 already not checking the cherrypy's version, see the below: | try: res.decode('utf-8') ||res.encode("utf-8") return res; except UnicodeDecodeError: return|res.encode("utf-8")
+1 We should avoid base our code in the package versions. That way we make sure the code will code independent of it.
2014/3/3 17:50, Sheldon:
Now there's a issue: https://github.com/kimchi-project/kimchi/issues/333
The reason of this issue is because high level cherrpy version make some change about set_response.
The high level cherrpy encode the unicode error message by itself.
So the kimchi do not encode the unicode error message any more.
It is right, the cherrpy should encode the unicode error message.
Now we can require the cherrypy version to solve this problem.
we can also check the cherrypy version in kimchi code as follow in order to avoid to require the cherrypy version.
like: if cherrypy.__version__ << 3.2.5: return res else: return res.encode("utf-8")
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
? 2014/3/4 0:24, Aline Manera ??:
On 03/03/2014 12:20 PM, Shu Ming wrote:
Shelon,
I got another idea to check of the string is utf-8 already not checking the cherrypy's version, see the below: | try: res.decode('utf-8') ||res.encode("utf-8") return res; except UnicodeDecodeError: return|res.encode("utf-8")
+1
We should avoid base our code in the package versions. That way we make sure the code will code independent of it.
After direct talk with Sheldon, the res will return to Cherrypy and it is Cherrypy to decode the "res" to a string or not based on Cherrypy's version. Just ignore my method in kimchi, because we need to check the cherrypy's assumption of the type of "res" to it. And checking Cherrypy's version is a fast way to know the assumption.
2014/3/3 17:50, Sheldon:
Now there's a issue: https://github.com/kimchi-project/kimchi/issues/333
The reason of this issue is because high level cherrpy version make some change about set_response.
The high level cherrpy encode the unicode error message by itself.
So the kimchi do not encode the unicode error message any more.
It is right, the cherrpy should encode the unicode error message.
Now we can require the cherrypy version to solve this problem.
we can also check the cherrypy version in kimchi code as follow in order to avoid to require the cherrypy version.
like: if cherrypy.__version__ << 3.2.5: return res else: return res.encode("utf-8")
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 03/03/2014 06:50 AM, Sheldon wrote:
Now there's a issue: https://github.com/kimchi-project/kimchi/issues/333
The reason of this issue is because high level cherrpy version make some change about set_response.
The high level cherrpy encode the unicode error message by itself.
So the kimchi do not encode the unicode error message any more.
It is right, the cherrpy should encode the unicode error message.
Now we can require the cherrypy version to solve this problem.
we can also check the cherrypy version in kimchi code as follow in order to avoid to require the cherrypy version.
like: if cherrypy.__version__ << 3.2.5: return res else: return res.encode("utf-8")
Did you confirm all the supported distros have access to the high cherrypy version? If so, I am OK to upgrade the cherrypy version
On 03/05/2014 03:24 AM, Aline Manera wrote:
On 03/03/2014 06:50 AM, Sheldon wrote:
Now there's a issue: https://github.com/kimchi-project/kimchi/issues/333
The reason of this issue is because high level cherrpy version make some change about set_response.
The high level cherrpy encode the unicode error message by itself.
So the kimchi do not encode the unicode error message any more.
It is right, the cherrpy should encode the unicode error message.
Now we can require the cherrypy version to solve this problem.
we can also check the cherrypy version in kimchi code as follow in order to avoid to require the cherrypy version.
like: if cherrypy.__version__ << 3.2.5: return res else: return res.encode("utf-8")
Did you confirm all the supported distros have access to the high cherrypy version? If so, I am OK to upgrade the cherrypy version royce has helped me to check the high cherrypy version is 3.2.2 on ubuntu.
So maybe we can not solve this problem by upgrade CherryPy. We can solve this problem by the patch. Issue #333: do not encode error.html when the cherrpy version less than '3.2.5' -- Thanks and best regards! Sheldon Feng(冯少合)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center
On 03/04/2014 11:24 PM, Sheldon wrote:
On 03/05/2014 03:24 AM, Aline Manera wrote:
On 03/03/2014 06:50 AM, Sheldon wrote:
Now there's a issue: https://github.com/kimchi-project/kimchi/issues/333
The reason of this issue is because high level cherrpy version make some change about set_response.
The high level cherrpy encode the unicode error message by itself.
So the kimchi do not encode the unicode error message any more.
It is right, the cherrpy should encode the unicode error message.
Now we can require the cherrypy version to solve this problem.
we can also check the cherrypy version in kimchi code as follow in order to avoid to require the cherrypy version.
like: if cherrypy.__version__ << 3.2.5: return res else: return res.encode("utf-8")
Did you confirm all the supported distros have access to the high cherrypy version? If so, I am OK to upgrade the cherrypy version royce has helped me to check the high cherrypy version is 3.2.2 on ubuntu.
So maybe we can not solve this problem by upgrade CherryPy. We can solve this problem by the patch. Issue #333: do not encode error.html when the cherrpy version less than '3.2.5'
Ok.
-- Thanks and best regards!
Sheldon Feng(冯少合)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center
participants (4)
-
Aline Manera -
Sheldon -
Shu Ming -
Zhou Zheng Sheng