Bug 956127 - Review Request: entypo-fonts - Pictogram Suite Font
Summary: Review Request: entypo-fonts - Pictogram Suite Font
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Orion Poplawski
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 957339
TreeView+ depends on / blocked
 
Reported: 2013-04-24 10:26 UTC by Alec Leamas
Modified: 2013-06-19 16:11 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-06-19 16:11:32 UTC
Type: ---
orion: fedora-review+
gwync: fedora-cvs+


Attachments (Terms of Use)
fontlint output entypo (4.92 KB, application/octet-stream)
2013-05-08 12:51 UTC, Alec Leamas
no flags Details

Description Alec Leamas 2013-04-24 10:26:33 UTC
Spec URL: http://leamas.fedorapeople.org/entypo/entypo-fonts.spec
SRPM URL: http://leamas.fedorapeople.org/entypo/entypo-fonts-20121031-1.fc18.src.rpm
Description:Entypo is a set of 250+ carefully crafted pictograms. The source contains
an icon font — OpenType, TrueType and @font-face — EPS, PDF and PSD files.
Only the @font-face font is packaged.

Fedora Account System Username: leamas

rpmlint *.spec /home/leamas/rpmbuild/SRPMS/entypo-fonts-20121031-1.fc18.src.rpm
entypo-fonts.src: W: spelling-error Summary(en_US) Pictogram -> Pictograph
entypo-fonts.src: W: spelling-error %description -l en_US pictograms -> pictographs, pictograph
entypo-fonts.src: W: spelling-error %description -l en_US ttf -> Flatt
1 packages and 1 specfiles checked; 0 errors, 3 warnings.

Comment 1 Orion Poplawski 2013-04-25 15:05:05 UTC
Package Review
==============

Key:
[x] = Pass
[!] = Fail
[-] = Not applicable
[?] = Not evaluated
[ ] = Manual review needed


Issues:
=======

- I would suggest not copying the fonts into the main directory, but just installing from the  original location if possible.

- I installed the font, but it doesn't seem to appear in LibreOffice.  Is that expected?

===== MUST items =====

Generic:
[x]: Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[x]: All build dependencies are listed in BuildRequires, except for any that
     are listed in the exceptions section of Packaging Guidelines.
     Note: Using prebuilt rpms.
[x]: Package contains no bundled libraries without FPC exception.
[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[-]: Package contains desktop file if it is a GUI application.
[-]: Development files must be in a -devel package
[x]: Package requires other packages for directories it uses.
[x]: Package uses nothing in %doc for runtime.
[x]: Package is not known to require ExcludeArch.
[x]: Package complies to the Packaging Guidelines
[x]: If (and only if) the source package includes the text of the license(s)
     in its own file, then that file, containing the text of the license(s)
     for the package is included in %doc.
[x]: Package consistently uses macro is (instead of hard-coded directory
     names).
[x]: Package is named according to the Package Naming Guidelines.
[x]: Package does not generate any conflict.
[x]: Package obeys FHS, except libexecdir and /usr/target.
[-]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[x]: Package must own all directories that it creates.
[x]: Package does not own files or directories owned by other packages.
[x]: Requires correct, justified where necessary.
[x]: Spec file is legible and written in American English.
[-]: Package contains systemd file(s) if in need.
[-]: Large documentation must go in a -doc subpackage.
     Note: Documentation size is 30720 bytes in 1 files.
[x]: Package successfully compiles and builds into binary rpms on at least one
     supported primary architecture.
     Note: Using prebuilt packages
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
[x]: Each %files section contains %defattr if rpm < 4.4
[x]: Macros in Summary, %description expandable at SRPM build time.
[x]: Package does not contain duplicates in %files.
[x]: Permissions on files are set properly.
[x]: Fully versioned dependency in subpackages, if present.
[x]: Spec file lacks Packager, Vendor, PreReq tags.
[x]: Package use %makeinstall only when make install' ' DESTDIR=... doesn't
     work.
[x]: Package is named using only allowed ASCII characters.
[x]: Package do not use a name that already exist
[x]: Package is not relocatable.
[x]: Sources used to build the package match the upstream source, as provided
     in the spec URL.
[x]: Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[x]: File names are valid UTF-8.
[x]: Packages must not store files under /srv, /opt or /usr/local
[x]: Package installs properly.
[x]: Rpmlint is run on all rpms the build produces.
     Note: No rpmlint messages.

===== SHOULD items =====

Generic:
[x]: Reviewer should test that the package builds in mock.
[-]: If the source package does not include license text(s) as a separate file
     from upstream, the packager SHOULD query upstream to include it.
[x]: Final provides and requires are sane (see attachments).
[!]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[x]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[x]: Package should compile and build into binary rpms on all supported
     architectures.
[-]: %check is present and all tests pass.
[x]: Packages should try to preserve timestamps of original installed files.
[x]: Sources can be downloaded from URI in Source: tag
[x]: Buildroot is not present
[x]: Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
[x]: Dist tag is present.
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[x]: SourceX tarball generation or download is documented.
[x]: SourceX is a working URL.
[x]: Spec use %global instead of %define.

===== EXTRA items =====

Generic:
[x]: Large data in /usr/share should live in a noarch subpackage if package is
     arched.
[x]: Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).
[x]: Spec file according to URL is the same as in SRPM.


Rpmlint
-------
Checking:
0 packages and 0 specfiles checked; 0 errors, 0 warnings.




Rpmlint (installed packages)
----------------------------
entypo-fonts.noarch: W: spelling-error Summary(en_US) Pictogram -> Pictograph
entypo-fonts.noarch: W: spelling-error %description -l en_US pictograms -> pictographs, pictograph
entypo-fonts.noarch: W: spelling-error %description -l en_US ttf -> Flatt

These are fine

Requires
--------


Provides
--------


MD5-sum check
-------------
http://dl.dropbox.com/u/4339492/Entypo.zip :
  CHECKSUM(SHA256) this package     : 58d5d41ed65a127d4de010bddb1558cb65f050595eae694da8fb7505fa3ad15c
  CHECKSUM(SHA256) upstream package : 58d5d41ed65a127d4de010bddb1558cb65f050595eae694da8fb7505fa3ad15c
Using local file /export/home/orion/redhat/entypo-fonts-20121031/entypo-fonts-fontconfig.conf as upstream
file:///export/home/orion/redhat/entypo-fonts-20121031/entypo-fonts-fontconfig.conf :
  CHECKSUM(SHA256) this package     : f98e00a75a6a0daa02989a3279dcd37bec466cf9463c8b9b09ac58461f26136c
  CHECKSUM(SHA256) upstream package : f98e00a75a6a0daa02989a3279dcd37bec466cf9463c8b9b09ac58461f26136c


Generated by fedora-review 0.4.0 (660ce56) last change: 2013-01-29
Buildroot used: fedora-18-x86_64
Command line :/usr/bin/fedora-review -n entypo-fonts -p

Comment 2 Alec Leamas 2013-04-25 15:45:47 UTC
[cut]

> Issues:
> =======
> 
> - I would suggest not copying the fonts into the main directory, but just
> installing from the  original location if possible.
Will fix (must rush away right now).


> - I installed the font, but it doesn't seem to appear in LibreOffice.  Is
> that expected?
Honestly, I don't know. This is a web font, primarely intended to be used by web applications and their clients. Basically it's a dependency of openerp7. Background: http://lists.fedoraproject.org/pipermail/devel/2013-April/181759.html

[cut] 
> Requires
> --------

FYI, you are running into a bug in fedora-review here, hence the empty Provides/Requires.  It's fixed in devel and upcoming 0.4.1

Comment 3 Alec Leamas 2013-04-25 15:51:36 UTC
Oops... The background link is not complete, the last two messages: http://lists.fedoraproject.org/pipermail/devel/2013-April/181770.html

Comment 4 Alec Leamas 2013-04-25 18:23:49 UTC
[cut]
> - I would suggest not copying the fonts into the main directory, but just
> installing from the  original location if possible.
Fixed. Updated in-place, same links.

[cut]

Comment 5 Orion Poplawski 2013-04-25 21:11:24 UTC
You need to bump the release for each change (even during review).

I've got some questions about this:

- What is the difference between the stuff in the @font-face directory and that in the Desktop typeface directory?
- Why not ship all of the fonts?
- Is the .svg file needed?
- What is the .woff file and is it needed?
- Do you need both the .ttf and the .otf files?

Comment 6 Alec Leamas 2013-04-25 21:51:36 UTC
(In reply to comment #5)
> You need to bump the release for each change (even during review).
No :)
https://fedoraproject.org/wiki/Packaging:Guidelines#Multiple_Changelog_Entries_per_Release


> I've got some questions about this:
Trying to answer, but bear in mind I'm on thin ice here. This is my first font package. Furthermore, it's about a web font which doesn't seem to have good guidelines in place(?)

> What is the difference between the stuff in the @font-face directory and
> that in the Desktop typeface directory?
Just assuming from the name: the desktop stuff is more like a regular font, targeted to be used by local applications. The @font-face stuff should then be what the web application send to a client requesting a font after parsing a css3 @font-face tag. 

> - Why not ship all of the fonts?
Basically because I'm lazy, I'm packaging this as a dependency for openerp7 which is a web application. Also, since this is a web-centric symbol font, I don't really see much value of it in e. g. a word processor (might be wrong, for sure).

> - Is the .svg file needed?
A @font-face tag typically lists several alternative formats for a font, svg sometimes being one of them. I see no reason to limit what the web server can offer in this respect.

> - What is the .woff file and is it needed?
woff format: http://en.wikipedia.org/wiki/WOFF
Needed: see above.

> - Do you need both the .ttf and the .otf files?
Here are not otf files I can see(?)

Comment 7 Orion Poplawski 2013-04-25 22:09:09 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > You need to bump the release for each change (even during review).
> No :)
> https://fedoraproject.org/wiki/Packaging:
> Guidelines#Multiple_Changelog_Entries_per_Release

Ooo, fun.  I'm going to quibble though and say that it has been "built" (by me), and not updating the release makes reviews harder.

> > What is the difference between the stuff in the @font-face directory and
> > that in the Desktop typeface directory?
> Just assuming from the name: the desktop stuff is more like a regular font,
> targeted to be used by local applications. The @font-face stuff should then
> be what the web application send to a client requesting a font after parsing
> a css3 @font-face tag. 

Hmm, okay, but I still wonder what the differences are.

> > - Why not ship all of the fonts?
> Basically because I'm lazy, I'm packaging this as a dependency for openerp7
> which is a web application. Also, since this is a web-centric symbol font, I
> don't really see much value of it in e. g. a word processor (might be wrong,
> for sure).

This doesn't sit right - if we're packaging the font, the whole thing should be packaged.

> > - Is the .svg file needed?
> A @font-face tag typically lists several alternative formats for a font, svg
> sometimes being one of them. I see no reason to limit what the web server
> can offer in this respect.

Okay, if it is a usable format - just seemed strange to me.

> > - What is the .woff file and is it needed?
> woff format: http://en.wikipedia.org/wiki/WOFF
> Needed: see above.

Thanks (who's being lazy now :)

> > - Do you need both the .ttf and the .otf files?
> Here are not otf files I can see(?)

Sorry, they are in the Desktop typeface directory and not (yet) packaged.

I think some more discussion may need to happen with the packaging committee and the font folks (i.e. Nicolas).

Comment 8 Orion Poplawski 2013-04-25 22:17:44 UTC
For example - it might be worth coming up with a scheme where the @font-face files are installed into a web-accessible location rather than /usr/share/fonts, espcially if the *.ttf files are different (which these ones appear to be):

Binary files ./@font-face/Entypo @font-face/entypo.ttf and Desktop typeface/Entypo.ttf differ

Comment 9 Alec Leamas 2013-04-25 22:31:44 UTC
I'm all for it, trusting you to handle the process.

(Feeling a bit ashamed, as it turns out this was not a fair deal. Seems that I will owe you one more before this is over).

Don't forget we might have to re-evaluate if it's really a good idea to package web-fonts. In general, is there such thing as a "web-accessible" location besides the very web-app space? 

The simple solution is to handle web-fonts as client-side javascript i. e. allowing a general bundling exception. The crucial problem with licenses could be handled by forcing web-fonts into a subpackage.

This is not part of the review discussion, just some input when contacting Nicolas, FPC etc. The background links in comment #2 and comment #3 are important input to this.

Comment 10 Orion Poplawski 2013-04-27 04:44:42 UTC
No, I'm not going to be able to drive this process, sorry.  But here are my thoughts which perhaps you could present to the packaging committee, as well as things that need exploring:

- In this particular package we seem to have some "regular"? desktop fonts and some web font versions of them.  (I'd like to know what is different).  The regular version should probably be packaged like regular fonts.  The web-fonts like web-fonts.

- How should we package web-fonts?  Should their be a separate install locaton for them?  For many web accessible items (javascript libraries) we often install an apache conf file that opens up access to their location, and then we can patch applications to point to that location.  Would that work in this case?

- For a package like mnmlicons-fonts, which seems more like a pure web-font, does it even make sense to follow the font packaging conventions?

Comment 11 Alec Leamas 2013-04-27 11:39:58 UTC
Thanks for all input so far! FPC ticket: https://fedorahosted.org/fpc/ticket/277

Comment 12 Alec Leamas 2013-05-08 12:51:54 UTC
Created attachment 745238 [details]
fontlint output entypo

Output from repo-font-audit. The upstream website does not have a bugtracker, so I have sent an email with the results. The missing codepoints are easy to patch, the rest is beyond my abilities. 

It's worth noting that the three errors Self Intersecting Glyph, Missing Points at Extrema and Bad Glyph Name are quite common in currently packaged fonts.

Comment 13 Alec Leamas 2013-05-08 13:16:56 UTC
The webfont discussion seems to boil down to that there is no such thing. As a consequence, this is packaged as a regular ttf desktop font.

Also because of this discussion, I don't package the @typeface fonts, just the desktop ones. The -Social fonts have trademarked symbols and are not packaged for these reasons.

When installing the font, it does show up in Libreoffice for me (when using Format|Character).

Comment 14 Orion Poplawski 2013-05-08 15:48:23 UTC
I thought the plan was only to ship the .ttf (and perhaps the .eot if ie9 support was needed)?

Is the fontconfig file still correct, this seems wrong to me:

$ cat /usr/share/fontconfig/conf.avail/70-entypo.conf
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
  <alias>
    <family>entypo</family>
    <prefer>
      <family>@font-face</family>
    </prefer>
  </alias>
</fontconfig>

though I'm not sure what is correct.

Comment 15 Alec Leamas 2013-05-09 09:28:08 UTC
Yes, that's definitely wrong. Looking into [1] I understand the the fontconfig .conf template is normally is §used for two things:
- To define a whether this font (entypo) should be replacing another font specified by user (the <prefer> stuff)
- To define a fallback font (the <default> clause)

Since entypo basically can't substitute for another font, and since there is no useful specific fallback I've just made the config file to an empty placeholder. 

New release, new links:
http://leamas.fedorapeople.org/entypo/2/entypo-fonts.spec
http://leamas.fedorapeople.org/entypo/2/entypo-fonts-20121031-2.fc18.src.rpm

[1] http://fedoraproject.org/wiki/Fontconfig_packaging_tips

Comment 16 Orion Poplawski 2013-05-09 15:42:27 UTC
Looks good.  Approved.

Comment 17 Alec Leamas 2013-06-19 13:07:41 UTC
Package Change Request
======================
Package Name: entypo-fonts
New Branches: f18 f19
Owners: leamas
InitialCC:

Comment 18 Alec Leamas 2013-06-19 13:15:22 UTC
New Package SCM Request
=======================
Package Name: entypo-fonts
Short Description: Pictogram Suite font
Owners: leamas
Branches: f18 f19
InitialCC: fonts-sig

New try, let's forget the previous one :(

Comment 19 Gwyn Ciesla 2013-06-19 14:46:36 UTC
Git done (by process-git-requests).

Comment 20 Alec Leamas 2013-06-19 16:11:32 UTC
f18, f19, rawhide built, f18 and f19 in updates-testing. Closing.


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