Red Hat Bugzilla – Bug 454148
Review Request: monafont - Japanese font for text arts
Last modified: 2008-07-29 10:23:22 EDT
Spec URL: http://mtasaka.fedorapeople.org/Review_request/monafont/monafont.spec
SRPM URL: http://mtasaka.fedorapeople.org/Review_request/monafont/monafont-2.90-1.fc9p.src.rpm
Mona Font is a Japanese proportional font which allows you to view
Japanese text arts correctly.
Thank you for packaging a new font! This is not a formal review, just initial
advice to make sure the actual review can proceed faster later.
1. Please make sure you've followed all the steps outlined in steps 1 and 2.a of
2. Please read attentively
3. Please try to stay as close as possible to
If you feel you need to deviate (umasks, defattrs, etc) please explain in this
review why the deviation is justified.
5. Some comments on your spec after a quick overview
A. Please do not create a metapackage
B. Please adhere to our font naming conventions (mona-fonts-bitmap,
mona-fonts-sazanami etc). Unlike other distributions we do not use the ttf affix
C. please ask on fedora-devel if it's not possible to detect font package
versions automatically. Your hardcoded versions are going to bite you someday.
D. you do not need to BR gzip
6. I seem to remember other core fonts packages used to execute mkfontdir in
%post with ghosting. However we do not have any official core fonts packaging
guidelines right now. If you feel you've fully researched the subject, and found
the best solution, do not hesitate to submit a core fonts packaging guideline
I realise this kind of package represents a lot of work (congratulations), and I
hope those comments will help you complete it.
There is not 4. I suck :p
Thank you for initial comments:
I did not know the wiki package, however as far as I check the wiki pacakage
it seems fine.
Perhaps I've read them
3-1: Some fedora contributor says that unless umask is set correctly fc-cache
font cache in a wrong permission: ref:
For example, fonts-japanese package has umask scriptlet.
I don't know if this issue has been correctly fixed. If you are sure this
is not needed now please let me know it.
3-2: %defattr(0644,-,-,0755) = %defattr(-,root,root,-) and actually I don't think
fonts packages must write a explicit umask values which differs from gerenal
packaging guidelines. Are there any rationale?
5-AB: Will fix
5-C: Very intentional. Actually I don't want to have this rpm _automatically_ find
i.e. If the dependent fonts make update version, then this srpm won't build and
someone (or Matt using automated massbuild) complains to me
"your srpm won't build, please fix it", which is actually what I am
6. Calling mkfontdir on scriptlet pulls X dependent packages, which is _banned_
on current Fedora packaging: related to
Actually one day (before the release of F-8) all packages including core
made to not call mkfontdir or chkfontpath on scriptlet.
* Sun Jul 6 2008 Mamoru Tasaka <firstname.lastname@example.org> - 2.90-2
- Gerenal packaing fix according to Fedora fonts packaing
(In reply to comment #3)
> For 1:
> I did not know the wiki package, however as far as I check the wiki pacakage
> it seems fine.
I don't see any wiki page on mona in
so you're definitely missing some steps in the fonts packaging workflow. Please
check. Those pages were not written for no reason.
> For 2:
> Perhaps I've read them
Can't answer for you.
> For 3:
> 3-1: Some fedora contributor says that unless umask is set correctly fc-cache
> creates font cache in a wrong permission: ref:
I didn't know this link but in any case that's a lot of maybes and since almost
all our fonts do not use umask (and have been so for a long time) I doubt there
is any problem in real life.
> For example, fonts-japanese package has umask scriptlet.
This was a mistake of the fonts-japanese packager. Silently changing one package
when the same pattern is repeated in many others is wrong.
> I don't know if this issue has been correctly fixed.
If this issue is real it needs to be addressed by guideline changes so every
packager (not just the ones aware of this mail post) can fix his packages. In
the meanwhile adding umasks not in the guidelines only adds to the confusion. Thus:
— please remove umasks from your packages
— please submit a guideline change proposal to FPC arguing the need for umask,
so the issue can be discussed properly. If FPC deems the umask necessary we'll
change all packages including yours.
> 3-2: %defattr(0644,-,-,0755) = %defattr(-,root,root,-) and actually I don't think
> fonts packages must write a explicit umask values which differs from gerenal
> packaging guidelines. Are there any rationale?
The defattr mask for font packages has been approved by FPC and FESCO with the
font spec template. Official page there
(unfortunately broken by recent mediawiki migration, the page I gave you is a
cleaned-up unofficial version).
FPC has generally avoided making statements on defattrs, because they can become
quite complex. It has let packagers exercise their good judgement on umasks or
not. However in the fonts case a correct deffatr is really simple which is why
the fonts guidelines include one (you can probably fish the IRC FPC minutes on
the subject if you care to).
> 5-AB: Will fix
> 5-C: Very intentional. Actually I don't want to have this rpm _automatically_ find
> the version.
Ok, good enough for me
> 6. Calling mkfontdir on scriptlet pulls X dependent packages, which is _banned_
> on current Fedora packaging:
Ok, right, I was not thinking. The actual rule on this is
BTW. I didn't think and didn't have any core fonts packaging guidelines to draw
on. Please write some.
On the spec file:
1. it's generally speaking a good idea to limit changes to the official
template, that makes rebasing after guideline changes easier. So it may be a
good idea to compare your spec with the template in rpmdevtools and try to limit
2. as stated on
the -f flag to fc-cache should not be necessary starting from F9 and the
fontconfig packager requested its removal
3. please remove umasks
4. please add defattrs
5. it's probably a good idea to add some fontconfig rules so fontconfig knows it
can substitute mona-sazanami to sazanami (same for VLGothic). See
6. URL could be
7. Source0 could be (probably wrong right now):
8. upstream tarball includes sfd files, and I dont see fontforge in your BR.
Please try to build from sfd sources if possible
9. upstream tarball is missing a detached file with licensing statements. Please
ask upstream to add it (this would be asked during formal review)
This informal review is quickly degenerating in a full review *sigh*
(In reply to comment #6)
> 2. as stated on
> the -f flag to fc-cache should not be necessary starting from F9 and the
> fontconfig packager requested its removal
Ahh.. actually after setting "umask 000" and calling fc-cache, fontconfig cache
with 0666 permission, which is wrong... So umask 133 is _definately_ needed and
Specifyin -f option with 'umask 000' also creates 0666 permission fontconfig cache,
which is also wrong.
(In reply to comment #8)
> Specifyin -f option with 'umask 000' also creates 0666 permission fontconfig
> which is also wrong.
-f has nothing to do with permissions, it's a totally different setting.
As for your findings, I don't disagree with them, they just seem not to be a
problem in actual life (I suspect changing root default umask is so impacting
almost no one does this).
Nevertheless, as stated before:
— do not add an umask when the guidelines says you should not
– if you care about the problem have the guidelines changed (it's easy: write a
short wiki page on the subject, and submit it to FPC with a mail, the procedure
is on FPC's page)
(In reply to comment #9)
> As for your findings, I don't disagree with them, they just seem not to be a
> problem in actual life (I suspect changing root default umask is so impacting
> almost no one does this).
sudores is affected by this.
> Nevertheless, as stated before:
> — do not add an umask when the guidelines says you should not
> – if you care about the problem have the guidelines changed (it's easy: write a
> short wiki page on the subject, and submit it to FPC with a mail, the procedure
> is on FPC's page)
Are you suggesting that I have to keep a potentially broke scriptlet until
FPC discusses this? (and please keep in mind that usually I won't be able to discuss
with FPC members just because I live in Japan... At the time I am writing this
it is around 1 am)
(In reply to comment #10)
> Are you suggesting that I have to keep a potentially broke scriptlet until
> FPC discusses this?
Yes. Because FPC may have a different perspective from you, and the fact most of
our fonts have been shipping without this umask for years (including distro
default fonts) strongly hints the problem is limited.
If you care about it have the guidelines changed, period. Localized workarounds
are wrong. If the problem is not important enough to be fixed distro-wide, it's
not important enough to be workarounded in your package.
> (and please keep in mind that usually I won't be able to discuss
> with FPC members just because I live in Japan... At the time I am writing this
> it is around 1 am)
Get some sleep please then :). A few hours delay won't hurt anyone.
FPC discussion happens by mail and in the wiki page submitted to FPC so being in
Japan is not a huge problem.
Honestly it just takes a few week to have FPC and Fesco approve a guideline
change, so just package without the umask for now, and add it back in a few
weeks if FPC decides it's a good idea (if it decides it's a bad idea well, I
trust FPC more than any individual packager)
Sorry, Nicolas, another big problem is found before discussing packagins issues.....
After rechecking license issue, README.euc says that ttf font is based on *Kochi
which turned before (some years ago) to contain some legal issue and
_cannot_ be shipped on Fedora.
Although bitmap part is public domain, I think only shipping bitmap part is rather
of no use, so I must withdraw this review request. Very sorry for troubling you
checking very fundamental issue carefully...
np, serves me right by not starting with the licensing bit. I don't care much
about the bitmap part, but we have a few bitmap users, so if you want to restart
with just this element, it's ok with me.
Last my comment 12 was my misunderstanding.. resubmitting
*** This bug has been marked as a duplicate of 457062 ***