Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=533919 --- Comment #5 from Igshaan Mesias <igshaan.mesias@xxxxxxxxx> 2010-01-12 06:44:24 EST --- Hi Nicolas, Upstream released a new version. I'm packaging that version and have completely re-written the spec file, though, still adhering to the points below. > Anyway, the review: > > 1. (not blocking) you don't include any fontconfig files, they would make your > user's life a lot easier (however, CJK is quite a mess in fontconfig, so maybe > it's better that way for now. Let's see what CJK users think of it) I have yet to come up with a decent fontconfig, but for now I'll be omitting it. > 2. (not blocking) rpmlint complains at the licensing string. I know the MPlus > license has been approved by spot, so it's not a legal problem. However I fear > all the repo-checking scripts will complain at you because of that. Please open > a fedora rpmlint bug so the license gets added to its list. (however upstream > would have made our life easier by using a standard font license such as the > OFL or the GPL with font exception) I have filed a bug against rpmlint, and it seems the issue has now been resolved ie, I no longer get rpmlint errors about the licensing at version 0.91. > 3. (not blocking) rpmlint complains some of the lines you used in descriptions > are too long. Please break them in smaller (<80) bits > > 4. (blocking) same problem for at least one for your summaries > I've made sure all the lines in the summary and descriptions are less than 80 characters. > 5. (not blocking) it seems rpmlint grew a spell-checker in fedora-devel. Please > fix the spelling mistakes it has identified (ie everything which is not a human > name) For someone who's native language should be english, I hope I fixed all the spelling mistakes. > 6. (blocking) please make sure your Source0 is a full URL pointing to the > source file. That will make your future packager life a lot easier (we have > many sf-hosted projects in Fedora, so it can be done) I have placed a url pointing to the tarball in the Source tag. > 7. (not blocking) you don't need to repeat the "Group: User Interface/X" > line in Fedora releases with a recent rpm I have removed the unnecessary Group tags from subpackages. > 8. (not blocking) it would be nice if each sub-package had a different summary. > What is the difference between 1c and 2c ? the one is Type 1 the other is Type 2. > 9. (blocking) m++ipa.pe is a build script, it has nothing to do in %doc I am excluding the build script for now. > 10. (not blocking) you don't need to specify %dir %{_fontdir} in the common > subpackage, it will be added automatically to each font subpackage removed. > 11. (not blocking) it's mostly cosmetic, but it would be nice if the font files > cased the style names they declare (ie "Bold" instead of "bold"). Apps are not > always smart enough to correct this I will try and fix, with some help as I am still newbie when it comes to fonts. > 12. (not blocking) a few font files declare an "heavy" weight. The standard > qualifier for "heavy" is "Black". That means weight selection won't work as > expected in apps not smart enough to try every possible "Black" legacy alias. > Please ask upstream to change this (also please have upstream check they did > mean "Black" and not some other weight). Standard style qualifiers and their > meaning have been described by Microsoft in the following whitepaper: > http://blogs.msdn.com/text/attachment/2249036.ashx Should I speak to upstream about this? > 13. (not blocking) the fonts fall just short of complete coverage for several > languages and unicode blocks (we only test if a language/block needs less than > 10 glyphs to be finished). Please relay upstream so it gets a chance to > complete them (for example, ab is incomplete because the Unicode consortium > added two glyphs to it this year IIRC) AFAIK the font is not complete as of yet. > 14. (not blocking) it would be nice if upstream included the text of their > license in the fonts copyright field, and not just "Copyright(c) 2009 M+ FONTS > PROJECT" without licensing info I have spoke to upstream regarding this, he seems unwilling to change the license. > 15. (not blocking) it would be nice if upstream released a source archive with > source files and build scripts, so we can re-build in Fedora using our own > fontforge version (that helps finding bugs in fontforge, and as our fontforge > improves, so do the fonts we build with it) I have yet to ask upstream. Would you kindly confirm whether the above is OK before I post the links to the new srpms and spec files. Thanks, Igshaan -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review