[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

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)

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

This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

I have verified that this bug is still valid so I'm reopening it with
the FutureFeature keyword to make sure it's not going to be closed 
again.    

groff still ships the following fonts:

/usr/share/groff/1.18.1.4/font/devps/symbolsl.pfa
/usr/share/groff/1.18.1.4/font/devps/zapfdr.pfa

Hi Nicolas,

I'm sorry for postponing this so long.

These files doesn't contain real fonts, but contain only a few symbols or import other fonts and change their metrics - I'm not really sure how this exactly works. However the purpose of theirs presence is eventual embedding into postscript documents generated by groff.

freeeuro.pfa - contains only Euro sign
symbolsl.pfa - modifies Symbol font to slanted variant
zapfdr.pfa - reverses ITC Zapf Dingbats font 

Removing these "fonts" is risky, as some people can require them.
Creating a separate font packages makes no sense in this case.
groff subpackage can be created if necessary.

Please, can you take a closer look at it and give me your opinion?

Jan

The cleaner solution is just to create a font subpackage for each of those files, following font packaging guidelines, and have groff depend on them. If groff does not know to seach for the files in another place than its own directory, you just have to put symlinks there pointing to the new font file location.

If the files were not font files (but from your description they are) the solution would have been to change their extension and patch groff to use the result

Of course, since we already have a ton of fonts in the distro, the best solution would have been to make groff use one of them directly instead of its own variants. But from your description that seems difficult.

Nicolas, there is no problem in searching for fonts. Let me explain better:

'groff -Tps' is used to create PostScript documents. It uses it's own font description files, which can be generated by 'afmtodit' from AFM (Adobe Font Metrics) files. These files contain only general font description and font metrics information. Not the font itself. (These files are shipped with groff distribution for the most popular fonts.)

When you open the document (or sent it to the printer), then the document viewer (or printer) has to look up required fonts. groff doesn't care.

These three *.pfa files are not real fonts. If they are used in groff source document, they are embeded into resulting ps file.

= freeeuro.pfa =
Contains only one symbol which, I think, is not worthy of creating a font subpackage. In addition, it is not shipped separately as a font. It was created only for groff and it is shipped with it.

= symbolsl.pfa =
Doesn't contain the font, it requires Symbol font on target device and it just changes it's metrics. 20 lines, 4 kilobytes. I don't consider this to be a font.

= zapfdr.pfa =
The same here. This font requires ZapfDingbats font on target device. And it creates reverse variant of it by changing it's metrics. (Suppose it is used for decoration.) 218 lines, 8 kilobytes.

I would call all *.pfa files above "PS document extensions" rather than "fonts". And if the only problem is pfa extension, I can easily rename these files.

Do you agree?

Jan

Well, freeeuro is definitely a font though it's probably useless nowadays. And the rest are more like ps instructions than fonts. So feel free to change their extensions to mark they are not general-purpose fonts we care about

Thank you. Updated in F14 and Rawhide.

groff-1.20.1-2.fc14 has been submitted as an update for Fedora 14.
http://admin.fedoraproject.org/updates/groff-1.20.1-2.fc14

groff-1.20.1-2.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update groff'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/groff-1.20.1-2.fc14

groff-1.20.1-2.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.