Bug 230560

Since this is your first submission, you probably need a sponsor. You
should ask for one here, and mark the bugzilla ticket as blocking
FE-NEEDSPONSOR, see
http://fedoraproject.org/wiki/Extras/HowToGetSponsored for details.

According to the specfile, the upstream source should be available at
http://downloads.sourceforge.net/wqy/wqy-bitmapfont-pcf-0.8.0-6.tar.gz. I
can't find it there. The upstream source tarball must be available for
download, and match the tarball in the src.rpm.

The specfile:

* You lack an url tag. You should add an URL tag pointing to the main
  page of the project.

* The version and release tags doesn't match the latest changelog
  item.

* The package obsoletes an earlier version of itself. This is
  uneccessary, and may lead to strange problems. rpm will upgrade the
  package correctly without this.

* The package uses chkfontpath without adding it as a
  requirement. Parts of the %post scriptlet tests if chkfontpath is
  installed. It would be simpler to just make sure it is installed by
  adding it as a requirement. If chkfontpath is not installed, The
  %post scriptlet also edits xorg.conf, adding the needed. fontpaths.
  I find this way too intrusive. Just make sure chkfontpath is
  installed.

* The %preun scriptlet is a bit too aggressive too, at least in my
  eyes, deleting and moving files around, and editing xorg.conf. I am
  no font expert, but I thought chkfontpath and its relatives was made
  to avoid such hacks.

The rpm builds without errors on my fc6 system.

rpmlint outputs:

$ rpmlint wqy-bitmapfont-0.8.0-6.src.rpm 
W: wqy-bitmapfont no-url-tag
W: wqy-bitmapfont strange-permission wqy-bitmapfont.spec 0600

This is probably because you have built the source rpm from at tarball with the
specfile built-in. Copy the sources to /path/to/rpm/SOURCES, and the specfile to
/path/to/rpm/SPECS, and do a rpmbuild -bs on the specfile.

W: wqy-bitmapfont mixed-use-of-spaces-and-tabs (spaces: line 1, tab: line 59)

This one is easy :-)

$ rpmlint wqy-bitmapfont-0.8.0-6.noarch.rpm 
W: wqy-bitmapfont incoherent-version-in-changelog 0.8.0 0.8.0-6
W: wqy-bitmapfont no-url-tag
E: wqy-bitmapfont obsolete-on-name
W: wqy-bitmapfont dangerous-command-in-%post cp
E: wqy-bitmapfont no-prereq-on chkfontpath
W: wqy-bitmapfont dangerous-command-in-%preun rm
E: wqy-bitmapfont no-prereq-on chkfontpath


Keep on the good work!

Ingvar

W: wqy-bitmapfont strange-permission wqy-bitmapfont.spec 0600

This is probably because you have built the source rpm from at tarball with the
specfile built-in. Copy the sources to /path/to/rpm/SOURCES, and the specfile to
/path/to/rpm/SPECS, 

+ and change the permissions of the specfile to 644

and do a rpmbuild -bs on the specfile.

thank you Ingvar

I made the following changes based on your feedback:

1. add URL tag
2. remove obsolete requirement
3. add chkfontpath as dependence
4. remove the mixed tab and space on line 59
5. modify the changelog version tag to version-release format
6. the source wqy-bitmapfont-pcf-0.8.0-6.tar.gz is uploaded to the suggested url

I also compile the rpm file in the way you suggested, and modify the permission
of the spec file. The new spec and srpm files can be downloaded from the
original urls.

I guess I have to things to complete at this point: 1. find a sponsor, I will
read the web page you pointed out, and go through the steps. 2. to determine
whether to keep or remove the "aggressive" commands in the spec. I used cp/rm
commands in order to make the rpm file compatible to the older versions of X
window and fontconfig, and make it usable for older versions of redhat or
redhat-based systems. Particularly, fontconfig has changes from 2.1.x to 2.3.x
and to 2.4.x. For these older versions, I need to make sure the font setting
file is copied to the right directory. I think this needs suggestions from the
sponsor.

I compiled this rpm on my CentOS4.4, a redhat based distribution, I will install
a FC6 soon if I find time, but before that, if you can kindly give a quick test
on the new rpm file, I would be greatly appreciated.

again, thank you very much for your help.

Just a few comments:

How about naming the package "wqy-bitmap-fonts"?

(In reply to comment #3)
> 1. find a sponsor

yes

> 2. to determine
> whether to keep or remove the "aggressive" commands in the spec. I used cp/rm
> commands in order to make the rpm file compatible to the older versions of X
> window and fontconfig, and make it usable for older versions of redhat or
> redhat-based systems. Particularly, fontconfig has changes from 2.1.x to 2.3.x
> and to 2.4.x. For these older versions, I need to make sure the font setting
> file is copied to the right directory.

Ok, but this package in the first instance will be for Fedora: in particular
Fedora 7, and also FC6 and FC5.  We know also have the option of branches for EL.
So if you want to do builds for EL4 later you may need to think about it,
but for current fedora releases, I suggest you look at other font packages
to see how things are normally done.

> I will install a FC6 soon if I find time, but before that

EL4 is little old compared to Fedora now, but FC6 should be fine for testing
the package.

I have reviewed this package on FC6. Everything seems fine.

Maybe need to change to this:
Release: 6%{?dist}

I think it is good to make this rpm even work on old linux version which haven't
chkfontpath.

But the old Requires is wrong, should be:
Requires: freetype, %{_datadir}/fonts
Prereq: chkfontpath
Not chkfontconfig, as this package don't exist in FC6. Name changed?

The rpmlint output was this:
W: wqy-bitmapfont dangerous-command-in-%post cp
E: wqy-bitmapfont no-prereq-on chkfontpath
W: wqy-bitmapfont dangerous-command-in-%preun rm
E: wqy-bitmapfont no-prereq-on chkfontpath

The no-prereq-on will disappear after add "Prereq: chkfontpath".

Maybe you can look at bitmap-fonts package's spec file? It is for pcf files too.

Well, the newest spec file is what I can see on
http://wenq.org/release/08src/wqy-bitmapfont.spec , right?

Then:
* At least this spec file cannot be accepted as this
  rpm creates some non-owned files. All files created or
  installed by this rpm should be owned by this rpm.
  i.e. Generally using "cp" or "ln" "rm" on scriptlets are 
       generally prohibited. This means that file ownership
       is somewhat wrong.

  If you have some strong reason why you want to support
  older versions, then IMO you should introduce %if macro, for example,
  and split the case accordingly.

* /usr/X11R6/ directory is no longer used.
  mkfontdir is now under %{_bindir}.

* Please use proper macros (i.e. %{_bindir} %{_sysconfdir},...)

* Please check what rpm owns %{_datadir}/fonts/wenquanyi/ .

thank you Mamoru, I will make the update accordingly. 

by the way, I want to find a sponsor, but the link Ingvar pointed out requires
an account to view, is there another place I can find sponsor list? 

or any of you would like to sponsor me as a Fedora contributor ? :)

thanks

Qianqian

(In reply to comment #8)
> by the way, I want to find a sponsor, 

At least Jens and me are sponsors, so either of us may
sponsor you.

hi Mamoru

thank you very much for helping. if you don't mind, I will take you as my sponsor.

I think the complication of the spec file comes from the fact that I want
backward compatibility to older systems, however, if we are building rpm
specifically for FC6/FC7, as Jens suggested, then most of these "aggressive"
commands can be eliminated. 

here I updated the spec and srpm with the simple approach: adding fontconfig and
chkfontpath as dependence without worrying about their legacy versions, then the
install/uninstall can be simplified to as short as 3 lines.

also, I followed Jens's proposal, renaming the package to wqy-bitmap-fonts, the
names of the package/spec file were changed accordingly.

new file download link:
Spec URL: http://wenq.org/release/08src/wqy-bitmap-fonts.spec
SRPM URL: http://wenq.org/release/08src/wqy-bitmap-fonts-0.8.0-6.src.rpm

two things I haven't figured out: 

1) I tried to install and reinstall the built rpm file, the font folder and
font.cache-1 files can not be removed if I can not use "rm" command

2) you suggested to check the ownership of %{_datadir}/fonts/wenquanyi/, do you
mean all packages in FC/extra? if yes, how?

thank you

Qianqian

To Hu Zheng

you are right, the chkfontconfig was a wrong name I copied from somewhere else.
now I corrected it. Does "Prereq" different from "Requires" field?

thanks

Qianqian

PS: just noticed your email address, it is an interesting combination, a good one :)

(In reply to comment #11)
> Does "Prereq" different from "Requires" field?

"Prereq" is deprecated these days, please use "Requires(post)", etc instead.
See the packaging guidelines on the fedora wiki for more details.

Well,
* first of all, if you change or modify your spec/srpm,
  please change (i.e. increment) the release number.
  http://fedoraproject.org/wiki/Packaging/FrequentlyMadeMistakes

(In reply to comment #10)
> 1) I tried to install and reinstall the built rpm file, the font folder and
> font.cache-1 files can not be removed if I can not use "rm" command
  This should be treated by %ghost file method.
  fonts-japanese spec file is a good example of this.


> 2) you suggested to check the ownership of %{_datadir}/fonts/wenquanyi/, 
> do you
> mean all packages in FC/extra? if yes, how?
  The simplest way is that
  * After you install this package, what does the following
    command returns?
----------------------------------------------------
$ rpm -qf /usr/share/fonts/wenquanyi
----------------------------------------------------
    A. If it returns "no package owns ....", then it is wrong
       and this package should own the directory.
    B. If it returns some package (say named "foo"), does the package
       "foo" required by this package? If so, this package
       should have "Requires: foo".

> 
> thank you
> 
> Qianqian

(In reply to comment #8)
> but the link Ingvar pointed out requires an account to view

Did you try making a wiki account?

ok, now I think it is getting closer :)

I uploaded the spec file to
http://wenq.org/eindex.cgi?wqy-bitmap-fonts.spec

the differences from the previous version are listed here:
http://wenq.org/eindex.cgi?action=history&id=wqy-bitmap-fonts.spec

the new SRPM file was uploaded to
http://wenq.org/release/08src/wqy-bitmapfont-0.8.0-1.src.rpm

the following problems were fixed:
1. the new package has release number starting from 1, and will increase
everytime I revise it
2. the package owns the folder /usr/share/fonts/wenquanyi
3. add %ghost for fonts.dir

I built and tested this rpm on FC6, everything looks as I expected.

the only problem now, is that the release number is different from the upstream
release number, which I think is ok, thinking that this is a separate package.

please let me know if anything else I need to pay attention, thanks.

Qianqian


PS: I just created an account on Wiki, user name is FangQ.

(In reply to comment #15)
> http://wenq.org/release/08src/wqy-bitmapfont-0.8.0-1.src.rpm

The package is still seems to be named "wqy-bitmapfont"?

> the only problem now, is that the release number is different from the upstream
> release number

Should be fine, though I am not sure what you mean by "upstream release number"?

sorry, the link was wrong, should be

http://wenq.org/release/08src/wqy-bitmap-fonts-0.8.0-1.src.rpm

(In reply to comment #16)
> > the only problem now, is that the release number is different from the upstream
> > release number
> 
> Should be fine, though I am not sure what you mean by "upstream release number"?
> 

Ah. I found what this means. The upstream tarball is named as
"wqy-bitmapfont-pcf-0.8.0-6.tar.gz". 
In this case, The version of fedora package should be "0.8.0.6"
(this also happens on ImageMagick rpm) (although I hope
upstream won't release 0.8.0.1-1.tar.gz ...... )

hi Mamoru

maybe it is ok, because if we bind the release number to upstream, then the
flexibility of making small changes for Fedora will be limited by the version
synchronization, plus that they are under different names ("wqy-bitmapfont" vs
"wqy-bitmap-fonts").

while, if this is a policy, then I will roll back the release number and update
the files, please let me know.

Qianqian

Well, while I suppose many packages use my way,
I posted to Fedora packaging committee anyway.

oh, yes, if the release number start from 1, then, the version-release number in
%changelog will not match the package's number. perhaps the way you suggested is
better.

(In reply to comment #20)
> Well, while I suppose many packages use my way,
> I posted to Fedora packaging committee anyway.

heard of anything back from them?

https://www.redhat.com/archives/fedora-packaging/2007-March/msg00128.html

Basically the conclusion was that it should go into the version field
as Tasaka-san suggested.  So either "0.8.0_6" or "0.8.0.6".  It would
really be better though if the "upstream release number" could go away
since it just causes problems for packagers.

(In reply to comment #21)
> oh, yes, if the release number start from 1, then, the version-release number
> in %changelog will not match the package's number. 

They have to match. :)

> perhaps the way you suggested is better.

Well, I would put it more strongly, you cannot use the "upstream release number"
directly in the Fedora release field.  It could be embedded there if you do
not wish to include it in the version field.

See also <http://fedoraproject.org/wiki/Packaging/NamingGuidelines>.


Qianqian, as the submitter you cannot assign a Package Review to yourself.
Tasaka-san, do you want to take it?  Otherwise I can do it.

thanks Jens

after reading the links you posted, I think 0.8.0-1 is the appropriate
version-release tag for this package.

the new spec and srpm files can be viewed and downloaded here

http://wenq.org/eindex.cgi?wqy-bitmap-fonts.spec
http://wenq.org/release/08src/wqy-bitmap-fonts-0.8.0-1.src.rpm

the changes of the spec file(
http://wenq.org/eindex.cgi?action=browse&diff=1&id=wqy-bitmap-fonts.spec&revision=6&diffrevision=5)
include
1. used 1 as release number
2. updated release tags in %changelog
3. removed the changelog items for 0.7.0 and ealier, combined changelog items
for 0.7.9 (as upstream beta) and 0.8.0 as the new 0.8.0-1 tag

how do these changes look to you? 

by the way, I put my email address in the assignee just for fulfill my
curiosities when I played around. now I will restore it to
nobody until any of you take the package.

a second read of the package naming rules reminds me that the upstream tarball
name wqy-bitmapfont is recommended name for the package, Jens, do you suggest me
 rolling back the package name as well?

Ok, thanks for the updated package.

I can sponsor you.  If you have not already done so, please read
http://fedoraproject.org/wiki/PackageMaintainers/Join
to understand the process of becoming a Fedora Contributor better.

(In reply to comment #25)
> a second read of the package naming rules reminds me that the upstream tarball
> name wqy-bitmapfont is recommended name for the package, Jens, do you suggest me
>  rolling back the package name as well?

That is true, but font packages may be an exception since they are usually
named with "-fonts" in Fedora and also more than one font file is included. :)
So I think wqy-bitmap-fonts is ok.  Using the "-fonts" suffix makes font
packages easier to find.

The rpmlint output on srpm gives:
W: wqy-bitmap-fonts mixed-use-of-spaces-and-tabs (spaces: line 1, tab: line 65)

and on the rpm:

W: wqy-bitmap-fonts non-conffile-in-etc /etc/fonts/conf.d/85-wqy-bitmapsong.conf
E: wqy-bitmap-fonts no-prereq-on chkfontpath
E: wqy-bitmap-fonts no-prereq-on chkfontpath

You need to use "Requires(post):" and "Requires(postun):" for the latter two.
See also <http://fedoraproject.org/wiki/Packaging/ScriptletSnippets>.

Also since this is a bitmap font there is no need to use fontconfig AFAIK.

hi Jens

thank you for your sponsorship. I am following the instructions on the "Join"
page, and got to the point "Install the Build-System Client Tools". My account
is FangQ, I added cvsextras group, and I may need you to approve my subscription.

by the way, I have three computers running different linux distros (FC6,
CentOS4.4 and Ubuntu6.10). Does the Plaque system only work for FC? or can be
any system running Python? I set up the .plague-client.cfg file and when I run
"plague-client list_builders", it showed some error msgs, I am not sure if this
is because I am not an approved user or the system problem.

For the font, the provided fontconfig file allows the synergy of this bitmap 
font with other existing vector fonts at specific font sizes, which is a highly
desired feature and make web page display very pleasing. I prefer to keep this
feature by adding the fontconfig dependence (the X-Core font system still use
this font in the old way).

the spec and srpm files are updated.

changes of the spec file are listed here:
http://wenq.org/eindex.cgi?action=history&id=wqy-bitmap-fonts.spec

download url:
http://wenq.org/eindex.cgi?wqy-bitmap-fonts.spec
http://wenq.org/release/08src/wqy-bitmap-fonts-0.8.0-1.src.rpm

this time I used rpmlint and removed all error/warning messages :)

(In reply to comment #30)
> thank you for your sponsorship. My account is FangQ, I added cvsextras group, 
> and I may need you to approve my subscription.

Yes, I see your request.  Let me activate it when this review is complete. :)

> Does the Plague system only work for FC?

I have only used it on Fedora.  I would expect it to work with EL4 too,
but I don't know if packages for it are available anymore (ie fc3 packages).

> when I run "plague-client list_builders", it showed some error msgs, I am
> not sure if this is because I am not an approved user or the system problem.

It works for me right now, so it may be because you're not a full contributor
yet.  What error do you see?  BTW soon the Fedora buildsys will change to
use koji in place of plague.

> For the font, the provided fontconfig file allows the synergy of this bitmap 
> font with other existing vector fonts at specific font sizes, which is a highly
> desired feature and make web page display very pleasing. I prefer to keep this
> feature by adding the fontconfig dependence (the X-Core font system still use
> this font in the old way).

Ok, I think I was mistaken - you are right to keep it.

(In reply to comment #31)
> http://wenq.org/eindex.cgi?wqy-bitmap-fonts.spec

It would be nice if this just displayed the .spec text file.
Do you have an url for that?

> http://wenq.org/release/08src/wqy-bitmap-fonts-0.8.0-1.src.rpm

Please bump the release number when you make a new package to help the review.

> this time I used rpmlint and removed all error/warning messages :)

Good.

I have not tried yet, but is the font better suited to Chinese than
Japanese and Korean?  Perhaps it would be better to replace "CJK"
with "Chinese"?

hi Jens

Chinese/Japanese/Korean share a large number of ideographic glyphs (called
Hanzi/Kanji/Hanja). There Hanzi were organized as CJK Unified Ideographics
(U+4E00-9FA5), CJK Unified Ideographics Extension A and Extension B by Unicode
Consortium and endorsed by all governments.  The WenQuanYi bitmap font 0.8
include all CJK Unified Ideographics glyphs (20902 x 4 sizes), with much
improved glyph shape compared to any existing open CJK font. Beside these
unified CJK characters, we also provide Hangul(thousands) and
Hiragana/Katakana(less than 100) glyphs in this font. Although we are not expert
in these JK-specific glyphs, but they look as good as those I have seen in the
commercial fonts, IMHO.

So, I prefer to stay with CJK in the title. At the same time, with more people
start using our font, I also hope more Japanese and Korean people to get
involved in the glyph optimization. Our wiki is open to all people and the
submitted glyph will be automatically compiled into nightly-build fonts.

the link for the spec file:
http://wenq.org/release/08src/wqy-bitmap-fonts.spec

or
http://wenq.org/eindex.cgi?id=wqy-bitmap-fonts.spec&raw=1&action=browse
(you need to remove <pre> and </pre>)

I will increase the release number next time.

> So, I prefer to stay with CJK in the title. At the same time, with more people
> start using our font, I also hope more Japanese and Korean people to get
> involved in the glyph optimization. Our wiki is open to all people and the
> submitted glyph will be automatically compiled into nightly-build fonts.

Ok.  Well the "CJK" wording is a smaller detail, I just thought it might be
safer to call it a Chinese font with support for Japanese and Korean.

I lived in Japan for 12 years until last year and have yet to see
a unified CJK font - there are usually considerable differences between
Chinese Hanzi and Japanese Kanji glyphs but perhaps I will be pleasantly
surprised.  In the long term if it were really possible to make a unified font
it would make CJK support much easier. :)

Ok I tested the font now in gedit.  While it looks nice I can't honestly
say that the font is suitable for native Japanese.  The kana (hiragana
and katakana) look fine, (though I noticed some misalignment between some
hiragana and other glyphs at 10 and 11pt), but the kanji do standout in eyes
of Japanese i am afraid.  (I can attach some screenshots if you are interested
to see some examples.:)


A few more comments:

- Is there any particular reason for using a subdir (wenquanyi/wqy-bitmapfont)
  for the fonts?  Do you expect other fonts in wenquanyi/ in the future?

- You don't really need to include all the upstream changelog details in
  spec file at least not for the initial package.

Usually starting with something like:

%changelog
*Sun Feb 18 2007 Qianqian Fang <fangq.harvard.edu> 0.8.0-1
- initial packaging for Fedora (#230560)

would be sufficient.

- I see wqy-bitmapfont-pcf-0.8.1-7.tar.gz was released upstream,
  after wqy-bitmapfont-pcf-0.8.0-6.tar.gz, how about changing the upstream
  version numbering scheme?  Eg why not just number the next release
  wqy-bitmapfont-pcf-0.8.2.tar.gz say? :)

- AFAICT the md5sum of the tarball in the srpm and the one on sourceforge
are different.  The package tarball must be identical to the upstream released
tarball.

Sorry, one other point about the sponsorship process, since Contributors are
able to review and approve other submitted packages it would help to show
your understanding of the review process if you can do a so-called "pre-review"
of another package currently awaiting review.  When doing a pre-review one
should state that it is a pre-review but make useful comments along the Fedora
Review Guidelines.  If you can add a link to such a pre-review here that would
be very helpful.  Feel free to ask me offline if you need more details.

Hi,

Just FYI, we had a RPM SPEC for wqy bitmap song font at this URL:
SPEC: ftp://ftp.fedora.cn/pub/fedora-cn/in-review/fonts-wenquanyi-song.spec
SRPM:
ftp://ftp.fedora.cn/pub/fedora-cn/in-review/fonts-wenquanyi-song-0.8.6-0.1.n20070405.fc7.src.rpm

It is for nightly build, and contains a emacs setup file for FC-6 (In FC-7 it
should not be used, #175599). It also contains a font alias file which I think
should be useful.


Here is my review:
* bitmap fonts are always under "misc" directory.
* I like the name fonts-wenquanyi-song-pcf and -ttf since I believe your font
family will become huge in size & variants.
* The font has BDF source so why not use that as Source0, and use bdftopcf to
generate PCF on the fly.
* Summary and %description could be localized
* Requires(pre): /usr/bin/mkfontdir
* Why conflicts?
* Why provides? Why conflicts and provides are not match?
* install -d -m755 on both %{fontdir} and %{fontconfdir}
* %defattr(-, root, root, -) is nicer
* %doc should not contain INSTALL*
* %ghost %verify??
* Don't have to use [ -f .... ] && .... since you have already specified them in
Requires
* Keep old changelogs, and raise spec release number after each round of
review/modification


Thanks!

hi Jens and Yijun

I have been working on some other stuff and met some problems when using the
upstream pcf tar ball as source. I just figured out the problem and compiled the
new srpm. you can find the new spec and srpm files at

Spec URL: http://wenq.org/release/08src/wqy-bitmap-fonts.spec
SRPM URL: http://wenq.org/release/08src/wqy-bitmap-fonts-0.8.0-2.src.rpm
diff:
http://wenq.org/eindex.cgi?action=browse&diff=1&id=wqy-bitmap-fonts.spec&revision=9&diffrevision=7


to Jens:

1. We have been working on vector CJK fonts for two years, and we are expecting
our first release this year. Because we developed our vector fonts in a quite
general way, so, instead of generating a single font, you will find a families
of fonts. To keep things simple and easy to manage, a separate project folder is
highly desired, as /usr/share/fonts/dejavu* and /usr/share/fonts/bitstream*

2. the change log has been modified as you suggested

3. I updated Source to upstream 0.8.1-7, and use the exact file as source, so
the md5sum should match now.


to Yijun:

I am glad to see you here, and thank you very much for help with the spec file. 

1. I have seen /usr/share/fonts/bitmap-font folder in FC6, and also chinese/,
zh_CN/, zh_TW/ folders, however, as in my reply to Jens, I felt it will be much
more clear to keep wqy bitmap fonts under the wqy project folder. Debian
xfonts-wqy maintainers put this font under misc, however, I have heard many
complains such as X crashes when change settings for wqy fonts. It will be much
safer to separate this font from others, because of the complex nature of this
fonts (such as tricky fontconfig settings and accompanied fonts.alias file)

2. I saw you are using night-build GB18030 fonts as source. I do not recommend
using the CVS version because of the following reasons:

A. GB18030 fonts (including both CJK basic+CJK ext A glyphs) are for our next
release (v1.0), which is still not publicly announced yet; all the documents,
credits are not fully updated yet, font files are not fully tested and small
number of wrong glyphs exist.

B. version 1.0 is going to be 1/3 bigger than the 0.8.x version, I am thinking
to use SFNT ttf as the format for the next release. In this case, the whole font
file can be as small as 4M before compression. However, freetype seems not ready
for SFNT ttf, please refer to the discussion to this issue at
http://lists.freedesktop.org/archives/fontconfig/2006-August/002365.html
so, I have not decided which format to use.

C. nightly-build files are overwritten everyday, I thought source referred to a
downloadable link for the original file.

a side note, the correct build method for nightly-build is "make wqyv1" or "make
wqyv08"

3. I added install -d for both directories

4. %defattr I copied from other examples, is (-, root, root, -) a more commonly
used attribute?

5. the only publicly available RPM for wqy font is the mandriva RPM
"x11-font-wqy-bitmapfont", since it is a noarch RPM, so, I want to use 
conflict to block it. I am not sure if this is necessary.

6. for %ghost, I simply copied from fonts-japanese  
http://cvs.fedora.redhat.com/viewcvs/devel/fonts-japanese/fonts-japanese.spec?rev=1.25&view=markup

7. I think mkfontdir is in xorg-x11-font-utils, which is included in requires list

sorry for the long reply. I am glad to hear back from both of you.

thanks

Qianqian

It seems I have to explain my idea a bit longer. :)

* bitmap fonts are always under "misc" directory.
I totally agree that the /usr/share/fonts/wenquanyi/ directory is needed. What I
mean is to use "misc" sub directory instead of %{name}. Well this issue is minor.

* The font has BDF source so why not use that as Source0, and use bdftopcf to
generate PCF on the fly.
Why not?

* Requires(pre): /usr/bin/mkfontdir
I mean xorg-x11-font-utils may not exist in older release of fedora. I'm not
familiar with X packages so could anyone confirm it?

* Why conflicts?
* Why provides? Why conflicts and provides don't not match?
I forget where I read this, that when a package conflicts another, it should
also provides that package to make the upgrade happens smoothly. Also use
Provides intead of Conflicts is better I think. 
The package don't have explicitly Provides itself.

* install -d -m755 on both %{fontdir} and %{fontconfdir}
I mean -m755 is missing from your script.
The newly added "install -d ...fontdir" is redundant.

* %defattr(-, root, root, -) is nicer
Yes, this is in the default template. (Do you use rpmdev-newspec and rpmlint?)

* %doc should not contain INSTALL*
Again I forget where I learned this.

* Keep old changelogs
I like old changelogs, especially for projects like WenQuanYi. :D

Hope CCheng could have a look at this, too.

What is the status of this bug?
For current spec file:

* Versioning
  - I suggest again that the version of this spec/srpm should be
    0.8.1.7. 

* Requires:
---------------------------------------------
Requires(post): chkfontpath
Requires(postun): chkfontpath
---------------------------------------------
  - If you add this Requires, then the check of the existence on
    the scriptlets:
---------------------------------------------
    [ -f %{_bindir}/mkfontdir ]    && 
---------------------------------------------
    is not needed because you explicitly "require" it.
    IMO the binaies
---------------------------------------------
%{_bindir}/mkfontdir
%{_bindir}/fc-cache
%{_sbindir}/chkfontdir
---------------------------------------------
    should be added as Requires(post) or/and Requires(postun),
    and all checking part "like [ -f <> ] && " should be removed.

* Conflict
  - I still don't understand why you add the line
---------------------------------------------
Conflicts: x11-font-wqy-bitmapfont
---------------------------------------------
    Are the rpm "x11-font-wqy-bitmapfont" ever shipped *on Fedora*?
    If not, then this line should be removed.

* Provides:
---------------------------------------------
Provides: wqy-bitmap-fonts = %{version}-%{release}
---------------------------------------------
    - This is not needed. This is automatically added.

hi Mamoru

I think I got some conflict info on version number and changelog, I hope Jens to
help me clarify these issues. Seriously, I think either way works perfectly for
me, and both are reasonable scheme as long as we are consistent in the future
updates.

ok, I updated the spec/srpm one more time

Spec URL: http://wenq.org/release/08src/wqy-bitmap-fonts.spec
SRPM URL: http://wenq.org/release/08src/wqy-bitmap-fonts-0.8.1-7a.src.rpm
diff:
http://wenq.org/eindex.cgi?action=browse&diff=1&id=wqy-bitmap-fonts.spec&revision=10&diffrevision=9

I removed Conflict/Requires (I copied these from other examples, but I
personally don't think they are necessary either, plus that
x11-font-wqy-bitmapfont is not a Fedora package after all); the [-f ] conditions
were removed and added dependences in Requires(post) and Requires(postun); added
-m0755 for font directory as Yijun suggested; used (-,root,root,-) as default
attributes.

For version numbering scheme, I used the upstream number this time, following
Mamoru's suggestion. To accommodate the requirements in 
http://fedoraproject.org/wiki/Packaging/FrequentlyMadeMistakes
I used a letter "a" after the release number to avoid confusions. Similarly,
this tag is used in the changelog block. The next update will have 7b and so on.
How does this sound to you? and Jens?

by the way, I saw my Fedora account still shows "unapproved" for cvsextra, I am
wondering if there is something else I should do to get access.

thanks, looking forward to feedbacks.

Qianqian

I am very sorry for taking so long to followup.  I have been too busy recently.

(In reply to comment #40)
> * Summary and %description could be localized

Would be nice.  You could add the Chinese description with:

 %description -l zh_CN

for instance if you wish.

(In reply to comment #41)
> 1. We have been working on vector CJK fonts for two years, and we are expecting
> our first release this year. Because we developed our vector fonts in a quite
> general way, so, instead of generating a single font, you will find a families
> of fonts. To keep things simple and easy to manage, a separate project folder 
> is highly desired

Ok. I just wondering about the naming too:
"wenquanyi/wqy-bitmapfont/" vs say "wqy-bitmapfont/" or "wenquanyi-bitmap/"
or "wenquanyi/bitmap/", or even "wenquanyi/misc/" as Yuan Yijun suggested.
I suppose "wqy/bitmap/" would make the connection with the package name
clearer, but that is ok.

> 6. for %ghost, I simply copied from fonts-japanese  
>
http://cvs.fedora.redhat.com/viewcvs/devel/fonts-japanese/fonts-japanese.spec?rev=1.25&view=markup

I think it is good since fonts.dir is generated at install time.

(In reply to comment #42)
> * The font has BDF source so why not use that as Source0, and use bdftopcf to
> generate PCF on the fly.  Why not?

Do you have a comment, Qianqian Fang?

> * Keep old changelogs
> I like old changelogs, especially for projects like WenQuanYi. :D

It is ok to put a *summary* of upstream changes in the rpm changelog
but the detailed upstream changes should be in the upstream changelog file.

(In reply to comment #40)
> * %doc should not contain INSTALL*

Agreed.  Better to remove them, since they are not really useful to users.

(In reply to comment #43)
>     IMO the binaries
> ---------------------------------------------
> %{_bindir}/mkfontdir
> %{_bindir}/fc-cache
> %{_sbindir}/chkfontdir
> ---------------------------------------------
>     should be added as Requires(post) or/and Requires(postun),
>     and all checking part "like [ -f <> ] && " should be removed.

I think at least the fontconfig requires need not be required.
See <http://fedoraproject.org/wiki/Packaging/ScriptletSnippets> (Fonts section)
and also
<https://www.redhat.com/archives/fedora-packaging/2007-April/msg00067.html>.

(In reply to comment #44)
> ok, I updated the spec/srpm one more time
> 
> Spec URL: http://wenq.org/release/08src/wqy-bitmap-fonts.spec
> SRPM URL: http://wenq.org/release/08src/wqy-bitmap-fonts-0.8.1-7a.src.rpm

I am sorry about as stated earlier using the upstream -7 in the release
can't not be done since you need to be able to bump the release number
freely if you need to rebuild at any time.  Additionally it is highly
recommended to use the "%{?dist}" suffix in the release field.
If you really have to keep the upstream -7a in the package version-release
then I recommend adding it to the release field as a minor number:
see http://fedoraproject.org/wiki/Packaging/NamingGuidelines for detailed
information and examples of this.

But as I said before it would be much better for upstream to move to
a simpler versioning scheme: like just "0.8.1.7". I don't know what the meaning
of the "a" in "0.8.1-7a": I hope it was not added just for the purpose
of this packaging.

> the [-f ] conditions
> were removed and added dependences in Requires(post) and Requires(postun); 

> For version numbering scheme, I used the upstream number this time, following
> Mamoru's suggestion. To accommodate the requirements in 
> http://fedoraproject.org/wiki/Packaging/FrequentlyMadeMistakes
> I used a letter "a" after the release number to avoid confusions. Similarly,
> this tag is used in the changelog block. The next update will have 7b and so on.

Please see my comments above.  The package release field cannot equal
such an upstream release number.

> I saw my Fedora account still shows "unapproved" for cvsextra, I am
> wondering if there is something else I should do to get access.

Yes, please be patient.  We are getting closer to completing the review.
Also did you see comment 39: it would be good if you could try a pre-review
of a package.

(I would also recommend to upstream to version the top directory
in the tarball btw.)

Created attachment 154121 [details]
wqy-bitmap-fonts.spec-2.patch

Some suggested changes.

Personally I would just drop the .7a from the release field and call it
0.8.1-3 but if you feel the distinction is important you can keep it.

(In reply to comment #46)
> 
> I think at least the fontconfig requires need not be required.
> See <http://fedoraproject.org/wiki/Packaging/ScriptletSnippets> (Fonts section)
> and also
> <https://www.redhat.com/archives/fedora-packaging/2007-April/msg00067.html>.
> 

This package contains a fontconfig config file, so it should require fontconfig
to ensure directory ownership is correct. Am I right?

(In reply to comment #48)


thank you Jens, I think your edit of the spec file clarified most issues related
to this package. My updated spec files is uploaded again at

Spec URL: http://wenq.org/release/08src/wqy-bitmap-fonts.spec
SRPM URL: http://wenq.org/release/08src/wqy-bitmap-fonts-0.8.1-3.src.rpm

as you see, I removed "7a" tag, and use a single release number to reflect new
builds for fedora. I think this scheme just make things clear.
(just wonder, why %{?dist} did not show up in the release tag?)

most of your edits were included in the new spec, except for the line "The Wen
Quan Yi bitmap fonts include complete CJK Unified ..." in the description. I
kept the word "CJK", because here "CJK Unified Ideograph" is a dedicated word
for a specific Unicode zone (see http://www.unicode.org/charts/).

please let me know your thoughts on this version. thanks

(In reply to comment #42)
>> * The font has BDF source so why not use that as Source0, and use bdftopcf to
>> generate PCF on the fly.  Why not?

> Do you have a comment, Qianqian Fang?

i thought about using bdf as source, however, I realized that in order to build
font from the bdf package, I need to add dependence for bdf2pcf/bdftopcf, perl
and make, and afraid of adding complexities for the script. 

Plus that, I have not uploaded the bdf files for 0.8.0-6 and 0.8.1-7 (due to
laziness). So, the only update-to-date bdf you can download is our nightly-build
bdf, which is updated everyday.

I will make another spec to use bdf as source, I will upload it when it is done.
we can choose one from the bdf/pcf versions. 

hi

I compiled a new update using today's nightly-build as source (bdf file), I used
0.8.1-4 to name this package.

Spec URL: http://wenq.org/release/08src/wqy-bitmap-fonts-bdf.spec
SRPM URL: http://wenq.org/release/08src/wqy-bitmap-fonts-0.8.1-4.src.rpm

using either the pcf version (0.8.1-3) or the bdf version (0.8.1-4) are fine to
me, just want to note that the bdf version adds buildrequires to create the pcf
files from bdf sources.

0.8.1-4 with bdf looks ok, but please do not rename the spec file in the package.

I guess wqy-bitmapfont-bdf-all-cvs20070506 is a cvs snapshot: I think it would
be preferable to make the initial package with an official release.
So IMHO best to use wqy-bitmapfont-pcf-0.8.1-7.tar.gz currently or wait for
the next official release.

(I see wqy-bitmapfont-ttf-0.8.1-7.tar.gz was also released.:)

I don't think you need to buildrequire make or %{_bindir}/env.
perl is also listed in
<http://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions>.

It is generally better to avoid using explicit file requires since
for them yum may need to download filelists.xml.gz which is rather big.

Created attachment 154379 [details]
wqy-bitmap-fonts.spec-4.patch

some more suggested fixes and cleanup

One more update and I think I would like to proceed to the formal review.

sorry for my late reply. I have been working on tuning the fontconfig file to
optimize the performance, for a new release for the upstream. However, that
seems need more work than I thought. So, I will stay with what have been used
for this package.

I used pretty much the entire spec file from Jens, except that I bump the
release number to 5 and keep the cvs source. I wish we can put a new official
release out in the next couple of weeks, but even not, the cvs version is fine
and the file headers are identical to the 0.8.1-7 release.

Spec URL: http://wenq.org/release/08src/wqy-bitmap-fonts.spec
SRPM URL: http://wenq.org/release/08src/wqy-bitmap-fonts-0.8.1-5.src.rpm

Jens, you suggested me doing a review for a new package as practics, should I
just pick one and post my suggestions in their review thread? or post it here?

thanks

(In reply to comment #55)
> I used pretty much the entire spec file from Jens, except that I bump the
> release number to 5 and keep the cvs source. I wish we can put a new official
> release out in the next couple of weeks, but even not, the cvs version is fine
> and the file headers are identical to the 0.8.1-7 release.

OK, I will take a detailed look soon.

> Jens, you suggested me doing a review for a new package as practics, should I
> just pick one and post my suggestions in their review thread? or post it here?

Yes please, if you can post your unofficial "pre-review" in their review bug
and just mention the bug number here that would be just fine, thanks.

Here is the formal review.

Good:
- rpmlint is clean
- package naming is in line with other fonts packages
- spec has same name
- meets packaging guidelines
- licensed under GPL 2
- package includes COPYING file
- spec file is legible
- md5sum matches upstream tarball on Sourceforge
5055fdfb725da7e5a2a71765d9535419  wqy-bitmapfont-bdf-all-cvs20070506.tar.gz
- package is noarch and builds successfully on my pre-F7 machine
- package lists build dependencies
- owns its own directories
- filelist is correct
- has %clean
- macros used consistently
- font content is permissible
- cleans when doing %install
- scriptlets are sane

I have tested the font package lightly.  The current fontconfig file
seems less intrusive than before.  The only obvious affect I notice
on a Japanese desktop now is the "middle dot"(?) glyph used for
password input is now changed to wider smaller dotted glyph.

Package satisfies all MUST requirements.
Thank you very much for contributing this package to Fedora.

Package is APPROVED.

Just a small thing but I noticed some trailing whitespace in some lines
of the spec file.  It would be good to remove them before importing
the package to cvs.

thank you so much Jens. I am so glad to get my first Fedora package approved. I
am also appreciated for your patience going thought all these details, and
forgive my slowness in learning. 

I saw the cvsextras group in my account was approved, so, I will upload the
package in the next couple of days after examining every detail (and remove the
extra trailing space as well).

again, thank you, and Ingvar, Mamoru, Zheng and Yijun. 
I hope you don't mind me bothering with more questions in the future.

New Package CVS Request
=======================
Package Name: wqy-bitmap-fonts
Short Description: WenQuanYi Bitmap Chinese Fonts
Owners: fangqq
Branches: FC-6
InitialCC: petersen

New Package CVS Request
=======================
Package Name: wqy-bitmap-fonts
Short Description: WenQuanYi Bitmap Chinese Fonts
Owners: fangqq
Branches: FC-5,FC-6
InitialCC: petersen

added by cvsadmin

hi Jens

I followed the CVS admin page
(http://fedoraproject.org/wiki/PackageMaintainers/UsingCvsFaq) and built the
package for FC-6/F-7 branches on cvs, however, I did not find information on how
these new packages are downloaded or found by end users. I used yumex or yum, it
did not list the wqy-bitmap-fonts-0.8.1-6.fc6 in the output. what will happen
after the new package being built on cvs?

thanks

Have you done make tag and make build? If you received the build success email,
it will shown in yum automatically two or three days later.

I can see devel branch has been built
http://kojiweb.fedoraproject.org/packages/wqy-bitmap-fonts/

but not FC-6 branch. Who remembers the URL of build.log?
http://fedoraproject.org/wiki/PackageMaintainers/PackageStatus says "it's not
available in devel or release", I wonder if you have successfully tagged it for
FC-6.

yes, I did "make tag/make build", everything looks alright, got "successful"
emails too. so, I guess what I need to do is a little bit patience and wait for
a couple of days :)

the devel branch is now mapped to fc8, I am building it right now, should be
done in a couple of minutes.

the first thing I did this morning is to do a yum update, and a yum search,
excitingly, the package shows up in fc6 repository today, install it with no
problem on my FC-6, so happy!

Great!   (Closing this out.)

wqy-bitmap-fonts-0.8.1-6.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.

wqy-bitmap-fonts-0.8.1-6.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.

Now fedora has changed a policy about fonts, that is to use libXfont's embeded
parser instead of xfs.

Simply speaking, a font path is not added to /etc/X11/fs/config using
chkfontpath, but rather referred to by using a symbol link in the
/etc/X11/fontpath.d/ directory. Then libXfont will scan that directory.

This change requires in the spec, replace the chkfontpath usage with another
scriplet to create symbol links.

(In reply to comment #71)
> Now fedora has changed a policy about fonts, that is to use libXfont's embeded
> parser instead of xfs.

Please don't reopen this bug. Instead create a new bug report.
Note that this is already tracked by bug 252279.