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.
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
[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
Oops... The background link is not complete, the last two messages: http://lists.fedoraproject.org/pipermail/devel/2013-April/181770.html
[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]
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?
(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(?)
(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).
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
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.
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?
Thanks for all input so far! FPC ticket: https://fedorahosted.org/fpc/ticket/277
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.
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).
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.
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
Looks good. Approved.
Package Change Request ====================== Package Name: entypo-fonts New Branches: f18 f19 Owners: leamas InitialCC:
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 :(
Git done (by process-git-requests).
f18, f19, rawhide built, f18 and f19 in updates-testing. Closing.