Bug 477416 - [lilypond] Please convert to new font packaging guidelines
[lilypond] Please convert to new font packaging guidelines
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: lilypond (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jon Ciesla
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: F11-new-font-rules
  Show dependency treegraph
 
Reported: 2008-12-20 19:32 EST by Nicolas Mailhot
Modified: 2009-07-23 15:00 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-05 15:14:57 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Spec (8.69 KB, application/octet-stream)
2009-01-15 12:16 EST, Jon Ciesla
no flags Details

  None (edit)
Description Nicolas Mailhot 2008-12-20 19:32:25 EST
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 the 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.                                                                                                                                                             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 make 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 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
Comment 1 Nicolas Mailhot 2008-12-20 19:56:12 EST
[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_packagehttp://fedoraproject.org/wiki/Simple_fonts_spec_templatehttp://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
Comment 2 Jon Ciesla 2008-12-31 08:50:06 EST
Split -fonts, built in rawhide.
Comment 3 Nicolas Mailhot 2009-01-09 11:02:18 EST
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
Comment 4 Jon Ciesla 2009-01-09 12:18:32 EST
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?
Comment 5 Nicolas Mailhot 2009-01-09 12:39:50 EST
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.
Comment 6 Jon Ciesla 2009-01-09 12:44:46 EST
The INSTALL indicates that they have changed it.
Comment 7 Nicolas Mailhot 2009-01-09 13:26:51 EST
Then they should rename it at least :(
Comment 8 Nicolas Mailhot 2009-01-11 10:19:47 EST
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)
Comment 9 Nicolas Mailhot 2009-01-14 13:37:23 EST
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)
Comment 10 Jon Ciesla 2009-01-15 12:16:32 EST
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?
Comment 11 Jon Ciesla 2009-01-15 12:16:56 EST
Created attachment 329111 [details]
Spec
Comment 12 Nicolas Mailhot 2009-01-15 13:22:25 EST
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
Comment 13 Jon Ciesla 2009-01-20 13:02:01 EST
How's this?

http://koji.fedoraproject.org/koji/buildinfo?buildID=79532
Comment 14 Jon Ciesla 2009-01-21 11:09:56 EST
Whoops, broken deps.  Fixed:

http://koji.fedoraproject.org/koji/buildinfo?buildID=79653
Comment 15 Nicolas Mailhot 2009-01-21 17:58:35 EST
(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)
Comment 16 Jon Ciesla 2009-01-22 09:52:42 EST
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.
Comment 17 Jon Ciesla 2009-01-22 10:04:05 EST
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.
Comment 18 Nicolas Mailhot 2009-01-22 10:06:23 EST
(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)
Comment 19 Jon Ciesla 2009-01-22 13:59:28 EST
Ok, how's this?

http://koji.fedoraproject.org/koji/buildinfo?buildID=79819
Comment 20 Nicolas Mailhot 2009-01-22 16:58:55 EST
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!
Comment 21 Jon Ciesla 2009-01-23 12:33:44 EST
Cool.  Fixed in rawhide, added to comps.
Comment 22 Orcan Ogetbil 2009-01-24 16:55:26 EST
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.
Comment 23 Nicolas Mailhot 2009-01-25 06:07:59 EST
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
Comment 24 Jon Ciesla 2009-01-26 12:28:53 EST
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?
Comment 25 Orcan Ogetbil 2009-01-26 12:38:54 EST
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.
Comment 26 Nicolas Mailhot 2009-01-26 13:09:25 EST
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.
Comment 27 Jon Ciesla 2009-01-26 13:31:16 EST
Jonathan, any thoughts on how to proceed here?
Comment 28 Nicolas Mailhot 2009-02-18 14:32:25 EST
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
Comment 29 Jon Ciesla 2009-03-05 15:14:57 EST
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.
Comment 30 Jonathan Underwood 2009-03-05 16:58:47 EST
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.
Comment 31 Jon Ciesla 2009-03-09 08:33:42 EDT
No problem.  Sounds like my life these days. :)
Comment 32 Orcan Ogetbil 2009-07-13 04:57:05 EDT
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.
Comment 33 Fedora Update System 2009-07-14 09:36:57 EDT
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
Comment 34 Jon Ciesla 2009-07-14 09:39:09 EDT
Please comment/add karma on the update if it meets your expectations.
Comment 35 Orcan Ogetbil 2009-07-14 23:27:02 EDT
Thank you for the prompt response. The new build is good as far as I tested.
I appreciate it :)
Comment 36 Orcan Ogetbil 2009-07-14 23:31:44 EDT
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
Comment 37 Jon Ciesla 2009-07-15 08:18:00 EDT
Anytime.  Glad it works.

No, this is a perfectly fine place to report it.  I've picked it up.  Thanks!
Comment 38 Fedora Update System 2009-07-23 15:00:08 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.