Bug 477416

[Since the bot made a mess of the text here it is again in properly indented form.]

This bug has been filed because we've detected your package includes one or several font files:

repoquery -C --repoid=rawhide -f '*.ttf' -f '*.otf' -f '*.pfb' -f '*.pfa' --qf='%{SOURCERPM}\n' |sed -e 's+-[0-9.-]*\.fc[123456789]\(.*\)src.rpm++g'|sort|uniq

Unfortunately this script does not detect symlinks to other packages, so if that's your case, you can close this bug report now.

Otherwise, you should know that:

— Fedora guidelines demand the packaging of fonts in a separate package (or subpackage):
http://fedoraproject.org/wiki/Packaging/Guidelines#Avoid_bundling_of_fonts_in_other_packages

— our font packaging guidelines recently changed, and every package that ships fonts must be adapted to the new templates available in the fontpackages-devel package:
  – http://fedoraproject.org/wiki/PackagingDrafts/Fonts_packaging_automation_(2008-11-18)
  – http://fedoraproject.org/wiki/Fedora_fonts_policy_package
  – http://fedoraproject.org/wiki/Simple_fonts_spec_template
  – http://fedoraproject.org/wiki/Fonts_spec_template_for_multiple_fonts

Please make your package conform to the current guidelines in rawhide (you can use the fontpackages package in F9 or F10 to test, but only submit changes to rawhide please).

If your package is not principaly a font package, depending on a separate font package or subpackage is the prefered solution. If your application does not use fontconfig you can always package symlinks to the files provided by the font package and installed in the correct fontconfig directories.

It is preferred to create a font package or subpackage per font family, though it is not currently a hard guidelines requirement (it may become before Fedora 11 is released). The definition of a font family is given on:
http://fedoraproject.org/wiki/Fonts_spec_template_notes/font-family

The new templates should make the creation of font subpackages easy and safe.

The following packages have already been converted by their packager and can serve as examples:
❄ andika-fonts
❄ apanov-heuristica-fonts
❄ bitstream-vera-fonts
❄ charis-fonts
❄ dejavu-fonts
❄ ecolier-court-fonts
❄ edrip-fonts
❄ gfs-ambrosia-fonts
❄ gfs-artemisia-fonts
❄ gfs-baskerville-fonts
❄ gfs-bodoni-classic-fonts
❄ gfs-bodoni-fonts
❄ gfs-complutum-fonts
❄ gfs-didot-classic-fonts
❄ gfs-didot-fonts
❄ gfs-eustace-fonts
❄ gfs-fleischman-fonts
❄ gfs-garaldus-fonts
❄ gfs-gazis-fonts
❄ gfs-jackson-fonts
❄ gfs-neohellenic-fonts
❄ gfs-nicefore-fonts
❄ gfs-olga-fonts
❄ gfs-porson-fonts
❄ gfs-solomos-fonts
❄ gfs-theokritos-fonts
❄ stix-fonts
❄ yanone-kaffeesatz-fonts

If you have any remaining questions about the new guidelines please ask them on:
fedora-fonts-list at redhat.com

Split -fonts, built in rawhide.

There are quite a lot of fonts in there and it's not sufficient to split them in a fonts subpackage, this subpackage also needs to conform to Fedora guidelines

The decision tree is the following:
for each font family in lilipond:
1. check with upstream if this font was created or modified by lilypond
  a. if it's just a copy of someone else's font, check if this font is available in Fedora
    i. if yes, add a dep on the existing fedora package (for example the urw fonts)
    ii. if no, get the original font source packaged separately
  b. if the font was created or modified by lilypond, create a separate subpackage for it (that installs it in correct font directories, using the official fedora rpm font macros)
2. symlink in the main lilypond package the font files installed in /usr/share/fonts provided by those packages of subpackages
3. add all the new font packages or subpackages to the fonts comps group

Looking at the pre-build tarball, it appears that the build process constructs the fonts at that time.  This would lead to 1b above.  Do I need to move the fonts from /usr/share/lilypond-%{version}/fonts to /usr/share/fonts/lilypond and symlink?

You need to package each set of OTF font files that corresponds to a font family using the %_font_pkg macro. That will pretty much force guidelines compliance on you.

I'm pretty sure at least the Century Schoolbook bit is an URW font which is already packaged many times in Fedora, and I'd be surprised the lilipond people had changed it. You probably need to discuss it a bit with lilypond people upstream.

The INSTALL indicates that they have changed it.

Then they should rename it at least :(

To help packagers manage the transition to the new guidelines, we've published the following FAQ

http://fedoraproject.org/wiki/Shipping_fonts_in_other_packages_(FAQ)

FPC approved those two additional guidelines recently, please take them into account if you need to create or update a fonts package or subpackage:

– 2009-01-14: naming
http://fedoraproject.org/wiki/PackagingDrafts/Font_package_naming_%282009-01-13%29

— 2009-01-06: exact splitting rules
http://fedoraproject.org/wiki/PackagingDrafts/Font_package_splitting_rules_%282008-12-21%29

(packagers that can drop font files and just depend on an existing font package are not impacted)

Trying to implement this using freecol as an example, running into build errors:

RPM build errors:
    File must begin with "/": %_font_pkg
    File must begin with "/": -n
    File must begin with "/": aybabtu-fonts
    File must begin with "/": lilypond/2.12.1/fonts/otf/aybabtu.otf
    File must begin with "/": %_font_pkg
    File must begin with "/": -n
    File must begin with "/": centuryschl-fonts
    File must begin with "/": lilypond/2.12.1/fonts/otf/CenturySchL*otf
    File must begin with "/": %_font_pkg
    File must begin with "/": -n
    File must begin with "/": emmentaler-fonts
    File must begin with "/": lilypond/2.12.1/fonts/otf/emmentaler*otf
    File must begin with "/": %_font_pkg
    File must begin with "/": -n
    File must begin with "/": feta-fonts
    File must begin with "/": lilypond/2.12.1/fonts/source/feta*mf

Attaching current spec.  Am I missing something obvious?

Created attachment 329111 [details]
Spec

1. You need to install your otf files in %{_fontdir} (you can keep the mf ones)

install -m 0755 -d %{buildroot}%{_fontdir}
install -m 0644 -p *.ttf %{buildroot}%{_fontdir}

2. Replace your %_font_pkg calls like

%_font_pkg -n centuryschl-fonts lilypond/%{version}/fonts/otf/CenturySchL*otf

by

%_font_pkg -n centuryschl CenturySchL*otf

(are the fonts really named centuryschl BTW?)

3. create a -fonts-common subpackage that will own %{_fontdir}

%files fonts-common
%defattr(0644,root,root,0755)
%doc 

%dir %{_fontdir}

4. make sure you use the fontpackages version in rawhide
http://koji.fedoraproject.org/koji/buildinfo?buildID=78561

5. and probably add symlinks to your main package so your app still sees the otf files in the place it's used to

How's this?

http://koji.fedoraproject.org/koji/buildinfo?buildID=79532

Whoops, broken deps.  Fixed:

http://koji.fedoraproject.org/koji/buildinfo?buildID=79653

(In reply to comment #14)
> Whoops, broken deps.  Fixed:
> 
> http://koji.fedoraproject.org/koji/buildinfo?buildID=79653

1. you really need to check your font family names in gnome-font-viewer or fontforge as explained in http://fedoraproject.org/wiki/Packaging:FontsPolicy
You'd see that "centuryschl" is actually "Century Schoolbook L", so the corresponding subpackage should be

lilypond-century-schoolbook-l-fonts (didn't check the others, please do so)

2. your font subpackages should require %{name}-fonts-common and not %{name} so the fonts can be installed without dragging the app in

3. I doubt providing lilypond-fonts <= 2.12.1-1 is of any use; yum only needs the obsoletes for a working upgrade path, and no other package will have deps on lilypond-fonts, no?

4. The font package descriptions do not tell users a lot about the fonts, but I guess this is a minor point for you

5. There does not seem to be any obvious typo in the upgrade path rules, of course the proof is in the pudding, do test it your side (install the f10 rpm, put your new rpms in a local dir with a createrepo, point yum to it and see what happens)

1. I see.  Sorry, new to fonts.

2. Ahhh.  Makes sense.  Should %{name}-fonts-common then be required by {%name} but not the other way round?

3. rpmlint will yell about that.

4. Not sure what I would say, honestly.

5. I'll have a go.

should the -common require the fonts and %{name} require common?  I'm confused as to what it should be, exactly.  

yum install lilypond needs to pull in common, and then the fonts.

(In reply to comment #16)
> 1. I see.  Sorry, new to fonts.

np, still documenting this

> 2. Ahhh.  Makes sense.  Should %{name}-fonts-common then be required by {%name}
> but not the other way round?

%{name} should require the font packages, and they will drag in common

> 3. rpmlint will yell about that.

rpmlint is not always right. Ask skvidal on irc if you don't believe me. Provides: oldname is only necessary if other packages depend on oldname and you don't want them to change

> 4. Not sure what I would say, honestly.

I know, probably need to ask on the oflb mailing list what a good description would be (or find one on wikipedia)

Ok, how's this?

http://koji.fedoraproject.org/koji/buildinfo?buildID=79819

1. You probably want to drop
Provides:	lilypond-fonts <= 2.12.1-1

it's going to do weird stuff at best

2. you don't need a %doc in common if you don't put any doc files in here (it would have been great if one of the txt files of lilipond explained the origin and licensing of the fonts

But that's minor; you package works fine now IMHO. Thank you for taking the time to do it right!

Cool.  Fixed in rawhide, added to comps.

Thanks for your work but, sorry, this is not done yet.

The guidelines state that the Type1 fonts need to be packaged separately. I already send an email to you (I wasn't aware of the presence of this bug), asking to split those .pfb fonts into yet another subpackage. For instance, this is done for the musixtex (ref: bug #481071 and bug #481070 ).

If you'd ask me how I ended up here: I wanted to package the guitar tablature editor "ktabedit" and ktabedit needs those .pfb files. And it won't be appropriate to make ktabedit require lilypond just for this reason.

Can you please add subpackage(s) for each families of those Type1 .pfb fonts? Thanks.

Sorry about that, I wanted to minimize your work by not adhering rigidly to splitting for pfb files and it only made more work for yo :(

Please make sure however the pfb and otf files can be installed independently in different subpackages 

http://fedoraproject.org/wiki/Shipping_fonts_in_Fedora_(FAQ)#What_if_my_package_bundles_the_same_font_in_several_different_formats.3F

Examining the fonts reveals that there are 33 distinct font families here.  Do I really need to create 33 subpackages or will feta, feta-alphabet, feta-braces and parmesan suffice?

If you'd ask me, it would be enough just to have feta and parmesan, 2 subpackages. Or maybe just one type1 subpackage.
But Nicolas is the boss here.

You can clearly put the different sizes of foo-XX fonts together

As to the different feta elements, you'll have to ask Jonathan Underwood or another TEXie. google-droid-sans has some rules to consolidate different font families in a single one fontconfig-side, you should also play with them.

This stuff screams 'legacy that should have been converted to a few big OTF fonts logn ago' to me.

Jonathan, any thoughts on how to proceed here?

This is a reminder for all the packagers that still have bugs open about adapting to font packaging guidelines there is only one month left before Fedora 11 beta:
http://fedoraproject.org/wiki/Releases/11/Schedule

A week of this month will see the Fedora 11 mass rebuild, that will load the build farm:
http://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild

As already converted packages showed it is quite possible to make mistakes during the conversion. Please make releng and QA happy and don't wait till the last minute to do your changes (avoid pre-beta panic). If possible start before the mass rebuild so we don't burn cycles on incorrect packages.

The PackageKit enhancements stated for Fedora 11 assume fonts and font-using packages are sane (basically respect packaging guidelines). It is quite possible that not-converted packages will interact with the F11 font autoinstall feature in "interesting" ways.
http://fedoraproject.org/wiki/Features/AutomaticFontInstallation

We don't want that

There is extensive documentation on the wiki and most of your questions have likely already been answered there. Please do read the FAQ before making more work for the support team by asking questions answered there.
http://fedoraproject.org/wiki/Shipping_fonts_in_Fedora_%28FAQ%29

Taking silence as agreement.  Updated to 2.12.2 as well, and FTBFS graciously fixed by Caolán McNamara.

Fixed in rawhide, added to comps.

Sorry I didn't respond, I missed the mail. To be honest I wouldn't have said much helpful anyway, tex font packaging is a mess. I am starting to think about how to sort it out and putting a proposal together as part of a concerted effort to rationalize tex packaging in general. But, real life is making this a slow goal. sorry.

No problem.  Sounds like my life these days. :)

Any plans to submit this change to F-10? This would make life easier for packagers who package a new program that uses lilypond fonts.

I have found a problem with F-10's emmentaler-14.otf font. As I pointed in bug 510668#c9, F-10's emmentaler-14 is missing a glyph at 0xe19d and because of that, all glyphs coming after this one is shifted by one unit. (for example: if these were regular fonts, this means that you push "p" button but your computer displays a "q"). F-11's emmentaler-14 doesn't have this problem.

I think making an F-10 update would be the easiest solution as you won't need to debug this weird error.

lilypond-2.12.2-4.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/lilypond-2.12.2-4.fc10

Please comment/add karma on the update if it meets your expectations.

Thank you for the prompt response. The new build is good as far as I tested.
I appreciate it :)

Oh, probably not the best place to report this, but one of the lilypond dependencies (mftrace) got orphaned. FYI

Ref: https://www.redhat.com/archives/fedora-devel-list/2009-July/msg00950.html

Anytime.  Glad it works.

No, this is a perfectly fine place to report it.  I've picked it up.  Thanks!

lilypond-2.12.2-4.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.