From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 Description of problem: rpmbuild tells me my specfile "does not appear to be a specfile." The specfile was created with the locale en_US. Now I have Red Hat Linux 9 and have my locale set to en_US.UTF-8. All because I have my name within comments. If I remove my name from the comments, everything is ok. Version-Release number of selected component (if applicable): rpm-4.2-0.69 How reproducible: Always Steps to Reproduce: 1. Set environment to en_US 2. Edit a specfile 3. Add a commented ine with accented characters 4. Test the specfile to make sure it works ok 5. Set environment to en_US.UTF-8 6. Retry the specfile. Actual Results: I got: error: File <spec-file> does not appear to be a specfile. Expected Results: I would have expected my rpm package to build Additional info: Yes, internationalization enhancements that cause problems for international users are NOT HUMOROUS. International users are really hating the UNICODE effort. It really could have waited a bit. en_US only users may love it to death but I just want stuff that works, not "ooh looky, it's bleeding edge, unf unf"
What happens if you move your accents to the end, not the beginning, of the spec file?
If I remove the comment with my name, which has accented letters, to the end of the spec-file, then rpmbuild accepts it as a spec-file and attempts to build.
OK, then this is the dumb file check for printable characters that tries to insure that the user has not specified a package instead of a spec file to rpmbuild. Ironically, all this dates back like 5 years ago when locales were first introduced, and the check is quite feeble, always has been, remains in rpm because, well, somone may call the check a feature. Even more amusing is the comments from PLD that are in the source (I'll leave to you to find the rather obscene translation): /* * Kurwa, durni ameryka?ce sobe zawsze my?l?, ?e ca?y ?wiat mówi po * angielsku... */ /* XXX this is still a dumb test but at least it's i18n aware */