[Fedora-packaging] file-not-utf8 complaints

Toshio Kuratomi a.badger at gmail.com
Sat May 31 01:56:33 UTC 2008


Jason L Tibbitts III wrote:
> Normally we fix up non-utf8 documentation and such with a quick call
> to iconv.  It seems that this is problematic for some; see
> https://bugzilla.redhat.com/show_bug.cgi?id=226079
> 
> Any comments on how much we actually care about this, especially in
> the case that it might not actually be as easy as a call to iconv
> (such as a changelog file with a pile of random encodings in it).
> 
Well... The reason that all files must be UTF-8 is exactly the problem 
that the ChangeLog exhibits so I don't have a lot of sympathy there. 
The names and special characters in that file are already corrupted 
since there's no common encoding and none is recorded with the names.
Dropping it from the package, as Daniel expressed is certainly an option 
as there's no requirement that ChangeLogs need to be in a package and it 
is not something that must be changed.

Reencoding the xml files that specify an encoding isn't strictly 
necessary.  We should probably ask upstream whether they are amenable to 
changing to utf-8.  Since libxml2 deals with utf-8 internally and the 
upstream author made a nice writeup about why he made that choice, 
upstream might be amenable to that.  If upstream is not amenable, we 
should consider changing the Packaging Guidelines to reflect that xml 
files which specify their encoding do not have to be re-encoded utf-8. 
(Although we then have to ask ourselves if we should be checking that 
the xml files actually use the encoding that they specify :-(

NEWS and other files that are neither specifying an encoding nor mixed 
up in such a way that they are hopelessly corrupted WRT the original 
characters should definitely be converted to utf-8.  If Daniel wants to 
hold open the Merge Review until that has gone in upstream, that is his 
perogative.

The most chilling aspect of that review is that the maintainer does not 
seem to think that it's his responsibility to take issues with the 
upstream source to upstream.  Since Daniel is upstream, I'm not certain 
I can see why he feels that someone else should be reporting it upstream 
before he deals with it.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/packaging/attachments/20080530/04ee140a/attachment.bin 


More information about the packaging mailing list