Re: [Pkg-fonts-devel] packaging "Grünewalt VA"
2010/7/22 Andreas B. Mundt <firstname.lastname@example.org>:
> Tag: ITP
>> Retitle the RFP bug to ITP and set yourself as the owner to indicate
>> that you are working on it
Sorry, I assumed you knew how to use the BTS. Instructions on dealing
with WNPP bugs are here:
>> Take a look at one of the pkg-fonts packages that build-depends on
>> fontforge to find out how to build the font from source and how to
>> package fonts in general. Please note that for new packages you do not
>> need any of the defoma stuff that you might see in some of the font
> Did not find a fonts package that build-depends on fontforge, but
> ... (see below)
"sudo apt-get install devscripts ; build-rdeps fontforge" should find
some if you have a deb-src entry in your sources.list.
>> I note that the font is listed as GPL licensed, I'd recommend asking
>> upstream to add the standard GPL font exception to the license:
> I looked into the license (OFL ?!) and found:
Ah, the RFP bug says that it is GPL not OFL, which is why I asked that.
> "5) [...] The requirement for fonts to remain under this license does
> not apply to any document created using the Font Software."
> So I guess this is fine.
>> Then get someone from pkg-fonts or DebianEdu to review the package and
>> upload it.
> I prepared a draft package at:
You can remove the boilerplate comments from debian/rules.
README.source contains a typo: charafters
preinst/postinst do nothing and can be safely removed.
You need a long description for the font package.
The Vcs-* URLs are commented out and wrong.
Standards-Version is out of date.
The binary package name should be ttf-<foundry>-<fontname>
Fontforge gives some warnings when I open the fonts in it and fontlint
finds several issues.
DFSG and license issues:
The PDF and the font don't have source code in the tarball/orig dir.
In this case we know there is FontForge source code for the font so it
needs to be shipped. The PDF embeds part of the non-free ArialMT font
and according to the metadata embedded in it, was created with "Adobe
Acrobat 8.1 Combine Files" and was "optimised". A quick search for
that leads me to believe that the PDF was created by merging multiple
PDFs (which we don't have), so Debian definitely does not have access
to the source code for the PDF. In any case the PDF doesn't need to be
shipped in the font package.
The font is under the SIL OFL with a reserved font name, so Debian
cannot build the font from source (patched or unpatched) unless you
rename the font. On the other hand we might need to patch it and build
from source if upstream goes MIA, which would mean the font and
package would need to be renamed before we could do so. This might be
annoying so you might like to ask upstream to drop the reserved font
Looking at the font information in fontforge, the fonts are
dual-licensed under the GPL with font exception and the OFL (no
specific version) so you need to update debian/copyright or clarify
the situation with upstream and get them to release a new version with
correct copyright/license information embedded in the font.
> There is one issue I am not sure about how to handle it properly: The
> upstream source is distributed in a .zip file which contains file
> names with spaces.
If a repack is needed, usually you write a get-orig-source target in
debian/rules (rather than a README.source) to download the upstream
archive and munge it as needed.
> In the long run it would be nice to use the pkg-fonts svn repository to maintain it.
Please request to join the alioth group and someone will add you.