Spec URL: http://people.redhat.com/petersen/extras/eblook.spec SRPM URL: http://people.redhat.com/petersen/extras/eblook-1.6.1-1.src.rpm Description: eblook is a command-line EB and EPWING dictionary search program. http://openlab.ring.gr.jp/edict/eblook/
mockbuild failed as zlib-devel is not present in BuildRequires When added above BR, mock build is fine but rpmlint on RPM gave W: eblook file-not-utf8 /usr/share/info/eblook.info.gz The character encoding of this file is not UTF-8. Consider converting it in the specfile for example using iconv(1).
Better, create a patch (with the help of iconv) and apply the patch in the specfile.
(In reply to comment #2) > Better, create a patch (with the help of iconv) and apply the > patch in the specfile. It is quite usual for Japanese document to use simply iconv. Creating patch results in making the patch contain both EUC-JP and UTF-8 characters and the patch cannot be seen easily.
In general, running iconv can silently break the file, e.g. when it is encoded in the target encoding already and when iconv doesn't encounter any illegal encoding.
(In reply to comment #4) > e.g. when it > is encoded in the target encoding already and when iconv doesn't > encounter any illegal encoding. I think you are raising an example which won't usually happen... Anyway, it is usual to use iconv, i.e. iconv -f EUC-JP -t UTF-8 foo.txt > foo.txt.tmp && \ mv -f foo.txt.tmp foo.txt || rm -f foo.txt.tmp
Try that when "foo.txt" is UTF-8 already, because for example upstream syncs with changes found in an rpm. iconv either creates invalid output silently or throws an error. The latter is good, the former is bad. Using a patch avoids that case. Btw, my comment is not specific to iconv. It also applies to other spec inline hacks (sed, Perl, and more). Breakage we've encountered before in Fedora packages.
(In reply to comment #6) > Try that when "foo.txt" is UTF-8 already, So.. this should not happen. Why don't you check the encoding beforehand?
By the way.. EUC-JP and UTF-8 encondings are quite different, so when trying to "already UTF-8 encoded" Japanese text from EUC-JP to UTF-8, this fails 100%.
> Why don't you check the encoding beforehand? Because the spec file would not do that either. It would run iconv with hardcoded options, regardless of what encoding is used in the input file actually. Anyway, I believe my message has become clear. Whether all sequences in an UTF-8 stream are invalid EUC-JP encodings is beyond the scope of my initial comment. That is an assertion that doesn't hold true for a few common other conversions, e.g. ISO Latin-1 to UTF-8.
(In reply to comment #1) > mockbuild failed as zlib-devel is not present in BuildRequires > When added above BR, mock build is fine but rpmlint on RPM gave Thanks for catching that. I made eb-devel require zlib-devel. > W: eblook file-not-utf8 /usr/share/info/eblook.info.gz > The character encoding of this file is not UTF-8. Consider converting it > in the specfile for example using iconv(1). I think in this case using iconv should be pretty safe since it will choke on utf8 when trying to convert from eucjp. Updated to: Spec URL: http://people.redhat.com/petersen/extras/eblook.spec SRPM URL: http://people.redhat.com/petersen/extras/eblook-1.6.1-2.src.rpm
Review: + package builds in mock (development i386). + rpmlint is silent for SRPM and RPM + source files match upstream. c570ce70697e6653d4d086fa3ad97e19 eblook-1.6.1.tar.gz + package meets naming and packaging guidelines. + specfile is properly named, is cleanly written + Spec file is written in American English. + Spec file is legible. + dist tag is present. + build root is correct. + license is open source-compatible. + License text is included in package. + %doc is small; no -doc subpackage required. + %doc does not affect runtime. + BuildRequires are proper. + %clean is present. + package installed properly. + Macro use appears rather consistent. + Package contains code, not content. + no static libraries. + no .pc file present. + no -devel subpackage exists. + no .la files. + no translations are available. + Does owns the directories it creates. + no duplicates in %files. + file permissions are appropriate. APPROVED.
Thanks! Requested CVSSyncNeeded.
Packages for devel, FC-5 and FC-6 have been built.