Spec URL: <http://subhodip.fedorapeople.org/arabeyes-core-fonts.spec> SRPM URL: <http://subhodip.fedorapeople.org/arabeyes-core-fonts-0.02-2.fc9.src.rpm> Description: <This package contains core Arabic fonts from Arabeyes.org project. It covers Arabic, Farsi, Urdu and Pashto languages, and is suitable for on screen display> koji build :<http://koji.fedoraproject.org/koji/taskinfo?taskID=800603> Can anybody review this ..please .
http://dev.laptop.org/ticket/8221 please see this for reference .
Hi Subhodip, I'll try to do a full review this week-end. In the meanwhile: 1. Please split your package in two, since you have two different fonts from two different sources. This will provide more user flexibility 2. Please follow the workflow described on http://fedoraproject.org/wiki/Font_package_lifecycle and in particular create a wiki page per font packages that can be referenced in release notes and other documentation
ok ..will do it
(You can rename this bug to make it a review for one of the fonts.:)
ok ..will do it by evening ..i am actually stuck because of koji ssl certificate revoked . Hope to fix it soon
requested by Jens Petersen (#27995)
koji build for F9 : http://koji.fedoraproject.org/koji/taskinfo?taskID=825141 New spec : http://subhodip.fedorapeople.org/Thabit-fonts.spec New SRPM : http://subhodip.fedorapeople.org/Thabit-fonts-0.02-3.fc9.src.rpm
big mistake : i accidently build the font with tag dist-f9 in koji .however this is corrected . new koji build : http://koji.fedoraproject.org/koji/taskinfo?taskID=831897
Nicolas, I feel like this would be a good candidate for naming "arabeyes-Thabit-fonts". Maybe after f10 we should consider revising the fonts packaging naming guidelines?
Strictly this doesn't block bug 462711 (Mothanna-fonts review) but in practice probably most of the changes to this packaging will need to be done for the other package too, so making it block.
Created attachment 319318 [details] Thabit-fonts.spec-1.patch Bit more cleanup now that Mothanna-fonts is going to be a separate package.
rpmlint says: Thabit-fonts.noarch: W: wrong-file-end-of-line-encoding /usr/share/doc/Thabit-fonts-0.02/OFL.txt 1 packages and 0 specfiles checked; 0 errors, 1 warnings.
Well comment 12 is after fixing rpmlint warning for ver-rel tagging syntax in the changelog: %changelog -* Mon Sep 08 2008 Subhodip Biswas <subhodip> -0.02-3 -- Packaged seperatly as Thabit and Mothana. -* Tue Sep 02 2008 Subhodip Biswas <subhodip> -0.02-2 +* Mon Sep 08 2008 Subhodip Biswas <subhodip> - 0.02-3 +- Packaged seperately as Thabit and Mothana. + +* Tue Sep 02 2008 Subhodip Biswas <subhodip> - 0.02-2 - Submit for review. + * Fri Aug 29 2008 Khaled Hosny <khaledhosny> - 0.02-1
ok ..will fix them soon
lowercase(In reply to comment #9) > Nicolas, I feel like this would be a good candidate for naming > "arabeyes-Thabit-fonts". lowercase please Appart from that, I really need to find a few hours to review the font packages backlog :(
(In reply to comment #14) > ok ..will fix them soon I'll review it just as soon as you post a new spec file, I promise :)
(In reply to comment #15) > > Nicolas, I feel like this would be a good candidate for naming > > "arabeyes-Thabit-fonts". > > lowercase please The upstream name is clearly Thabit: do you think we should lowercase it? Personally I usually prefer to preserve upstream casing as far as possible.
@ Jens I guess preserving the upstream naming is fine . @Nicolas Had problem with my net connection ..will upload tonight :)
we don't have any mixed-case package right now and I'd rather keep it this way. Mixed case confuses users that update/install from the CLI and fails as soon as there's a windows mirror or a fat usb key involved. So please do use lowercase package names only please.
Well there is VLGothic-fonts (and plenty of other mixed case packages in the distro), but I won't fight too much. Though IMHO case in tarball names is generally worth respecting.
i am getting confused .. lowercase or tarball name ?
please use arabeyes-thabit-fonts as package name (I'll find some reason to get VLGothic-fonts fixed later :))
I wanted to wait for a submission with a fixed name, but since I'm doing a font review run today anyway, here is a full review. (on http://subhodip.fedorapeople.org/Thabit-fonts-0.02-3.fc9.src.rpm) 1. Please rename package to arabeyes-thabit-fonts 2. You have a typo in Summary 3. Is upstream's URL http://www.arabeyes.org/ or http://www.arabeyes.org/project.php?proj=Khotot (as referenced in the README) ? 4. Is the description still ok for a Thabit-only package? 5. It's harmless, but a Source2 without Source1 is strange, especially on a new package 6. Please use normal %setup macro in your package. That will simplify the spec a lot (your complex manual unpacking was only necessary because you initially tried to stuff two fonts in a single package) 7. Since upstream uses fontforge for building, please ask upstream to publish sfd sources and build fedora fonts from those sources (we have many packages that do so, for example DejaVu, Liberation, Inconsolata, etc) 8. Some people want all Fedora-added source files in a package to be prefixed with the package name. You don't follow this convention for your fontconfig file. Please use %{name}-fontconfig.conf as suggested by http://fedoraproject.org/wiki/Packaging/FontsSpecTemplate 9. I don't know if 65 is the right fontconfig priority for this font. You need to discuss it with Behdad (preferably CC-ing the fedora fonts list) 10. Please only declare thabit-related fontconfig rules in the fontconfig file shipped with the thabit package 11. You probably want a "Generic name" rule in addition to the "Registering a font in default families" rule in your fontconfig file → http://fedoraproject.org/wiki/Fontconfig_packaging_tips#Generic_names This rule is used by fontconfig to complete your font with glyphs from other fonts when it encounters a codepoint your font is missing → http://fedoraproject.org/wiki/Fontconfig_packaging_tips#Registering_a_font_in_default_families This rule is used by fontconfig to identify what fonts to use when an application requests a "cursive" font. 12. Please reformat your xml files with xmllint --format before submission so they are nicely indented with the same rules as other font packages 13. When you've written fontconfig rules you're happy with it's always a good idea to send them upstream to be included in the font next releases (in the versionned source archive you're supposed to request) 14. You can drop the -f flag to fc-cache for releases ≥ Fedora 9 15. OFL.txt mentions an IBM copyright. Please ask upstream to add a Fontlog.txt to their source release archive (as recommended by SIL for OFL fonts), that clearly identifies what other fonts were used to create this font, so Fedora Legal can check there is no problem 16. Please make sure all the steps up to 2.a (included) have been followed in https://fedoraproject.org/wiki/Font_package_lifecycle In particular we need a wiki page that describes the font to be added to the wiki (for release notes) Well that's a lot of stuff to fix and it's a pity the OLPC folks didn't do a full review before accepting this font package. I'm putting a "NEEDINFO reporter" on this bug and the Mothanna one (since it needs more or less the same fixes). Please remove this flag once you've fixed the previous points. Please don't hesitate to ask questions on the fedora fonts list if there are elements you need help with.
i have mailed upstream since i am not a direct contributer to olpc . Anyways I am still waiting for a reply
(In reply to comment #24) > i have mailed upstream since i am not a direct contributer to olpc . Anyways I > am still waiting for a reply Please do not wait for OLPC to respond. Our packaging standards are higher than theirs, any any font package that passed Fedora review will just the OLPC package next time they rebase on a new Fedora version. Just do the requested fixes, so we can have a clean Fedora package OLPC can be referred to.
Hi, I have FAS account and I would love to co-maintain this package for fedora as my first fedora package we need 3 font packages 1. KACST 2. core 3. decorative http://www.arabeyes.org/project.php?proj=Khotot as you case see they are already split by upstream http://cvs.arabeyes.org/viewcvs/art/khotot/ KACST is not developed by Arabeyes thus they need its own super package while core and decorative should be two subpackages of the same package the core fonts are missing the best font which is simplified naskhi, which can be downloaded from Araveyes fonts team leader and the designer of the fonts http://www.khaledhosny.org/filebrowser KACST's fonts are released under GPLv1 the decorative fonts are GPLv2 and the core fonts are OFL licensed I'll attach my .spec file
Created attachment 323014 [details] spec file for arabeyes-fonts superpackage
Created attachment 323015 [details] font config configuration
(In reply to comment #27) > Created an attachment (id=323014) [details] > spec file for arabeyes-fonts superpackage Alsadi, as I stated on the list (and in this review) we do not do superpackages in Fedora, so if you want to propose spec files you need to propose one spec per font (ie 3 spec files), not a single spec that packages three different upstream archives in one go
(In reply to comment #26) > Hi, I have FAS account and I would love to co-maintain this package for fedora > as my first fedora package Unfortunately you have to be a packager in order to comaintain a package. > we need 3 font packages > 1. KACST kacst-fonts is already in fedora for a long time.
> Unfortunately you have to be a packager in order to comaintain a package. till I get that, I'll be pleased to help at least by attaching .spec files in bugzilla >> we need 3 font packages >> 1. KACST > kacst-fonts is already in fedora for a long time. I meant to say we should have 3 separate packages because we have 3 upstream packages kacst: is from different author while arabeyes-core and arabeyes-decorative have different license (the first is GPLed and the second is OFL) Nicolas Mailhot proposed that each font should be split into a different package so at least we need 3 different source rpms because we have three upstreams they later can be split using some macro into final rpm
(In reply to comment #31) > till I get that, I'll be pleased to help at least by attaching .spec files in bugzilla Thanks. > I meant to say we should have 3 separate packages > because we have 3 upstream packages Yep I think we all agree on this. :) > they later can be split using some macro into final rpm I think Nicolas was probably talking about subpackaging of upstream packages when they provide multiple fonts/faces, yes.
Ping?
[This is a simplified version of the message sent to every package maintainer that ships TTF/OTF/Type1 fonts in Fedora.] Our font packaging guidelines have now changed. New font package submissions must now be adapted to the new templates available in the fontpackages-devel package: – http://fedoraproject.org/wiki/fontpackages – http://fedoraproject.org/wiki/Simple_fonts_spec_template – http://fedoraproject.org/wiki/Fonts_spec_template_for_multiple_fonts It is preferred to create a font package or subpackage per font family, though it is not currently a hard guidelines requirement. http://fedoraproject.org/wiki/PackagingDrafts/Font_package_splitting_rules_(2008-12-21) has been submitted for FPC and FESCO approval today. The new templates should make the creation of font packages easy and safe. The following packages have already been converted by their packager in fedora-devel and can serve as examples: ❄ abyssinica-fonts ❄ 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 ❄ nafees-web-naskh-fonts ❄ stix-fonts ❄ yanone-kaffeesatz-fonts The new spec templates have been designed to be easy to update to from the previous guidelines, and to remove complexity from font packages. To help new package creation the fontpackages-devel package has been made available in Fedora 9 and 10. If you have any remaining questions about the new guidelines please ask them on: fedora-fonts-list at redhat.com
What is the status of this?
Peter: I think we are waiting for the submission to be updated to the new Fonts Packaging Guidelines.
Hello Subhodip, What is the status of the updates required to this package for the review? It would be great to get this into Fedora 11.
Its almost 7 months and no reply from submitter, I will close this review now. Anyone interested please submit new package review. Subodh, If you are still following this review and want to package this, submit updated package.