Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1078283

Summary:	rhnplugin crash yum when LANG do not use UTF8
Product:	[Community] Spacewalk	Reporter:	Forlot Romain <rforlot>
Component:	Clients	Assignee:	Milan Zázrivec <mzazrivec>
Status:	CLOSED WONTFIX	QA Contact:	Red Hat Satellite QA List <satqe-list>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	2.0
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-03-21 09:58:32 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1484117

Description Forlot Romain 2014-03-19 14:26:29 UTC

Description of problem:
When we use yum with rhnplugin enabled and LANG set to fr_FR and repositories can't be reach then after timeout yum display following message :

 Options Error: 'utf8' codec can't decode byte 0xc1 in position 38: invalid start byte

When we launch yum with LANG set to fr_FR.UTF8, or C, it is fine. Another workaround is to disable rhnplugin but it isn't possible then to install from rhn repo.

Version-Release number of selected component (if applicable):
yum-rhn-plugin-2.0.1-1.el5

How reproducible:
Launch yum with unreachable rhn repo and LANG set to another charset than UTF8 and another language with exotic character.

Steps to Reproduce:
1. Make rhn repo unreachable
2. LANG=fr_FR yum remove <an_existing_package>
3.

Actual results:
 Loaded plugins: rhnplugin, security
 Options Error: 'utf8' codec can't decode byte 0xc1 in position 38: invalid start byte

Expected results:
Error with exotic char displayed and no yum crash.

Additional info:

Comment 1 Milan Zázrivec 2014-03-21 09:58:32 UTC

I'm wondering why you'd want to have your operating system set to
a latin1 encoding / locale. As far as french locale goes, you need
to, from the support point of view anyway, use fr_FR.UTF-8.

I'm sure there are many other places in our code which would show
similar error with non-utf8 locales.

As long as fr_FR.UTF-8 works, we have no case here, sorry.

I'm closing this with wontfix.

Comment 2 Eric Herget 2017-09-28 18:09:40 UTC

This BZ closed some time during 2.5, 2.6 or 2.7.  Adding to 2.7 tracking bug.