Spec URL: http://www.cs.toronto.edu/~behdad/fedora/freetype1/freetype1.spec SRPM URL: http://www.cs.toronto.edu/~behdad/fedora/freetype1/freetype1-1.4-0.1.pre.src.rpm Description: I removed FreeType 1.x stuff from the freetype package in core. That happened when going from freetype-2.1.10 to freetype-2.2.1. A few Extras packages depend on FreeType 1.x, hence this package. %description The FreeType engine is a free and portable TrueType font rendering engine, developed to provide TrueType support for a variety of platforms and environments. FreeType is a library which can open and manages font files as well as efficiently load, hint and render individual glyphs. FreeType is not a font server or a complete text-rendering library. The version 1.x of FreeType is obsolete. New applications should use the more advanced FreeType 2.x library packaged as freetype.
Where does freetype-1.4pre come from? The latest I can find is 1.3.1: http://sourceforge.net/project/showfiles.php?group_id=3157&package_id=3068 I guess we would know how/where to find it, if you used a full URL in the Source: field.
And you should omit static libs (%_libdir/lib*.a) and %{_libdir}/lib*.la files.
> %package utils > Summary: A collection of FreeType 1.x utilities > Group: System Environment/Libraries > Requires: %{name} = %{version}-%{release} > # Upgrade path > Provides: freetype-utils = 2.2.0-1 > Obsoletes: freetype-utils < 2.2.0-1 Very ugly. At the time this freetype-utils sub-package was introduced, it should have started at 1.x, not 2.x. You could still do that with a proper Epoch.
(In reply to comment #1) > Where does freetype-1.4pre come from? The latest I can find is 1.3.1: > http://sourceforge.net/project/showfiles.php?group_id=3157&package_id=3068 Don't know. It probably is rolled by someone specifically for Red Hat Linux / Fedora. I just got it from freetype-2.1.10 SRPM.
(In reply to comment #3) > > %package utils > > Summary: A collection of FreeType 1.x utilities > > Group: System Environment/Libraries > > Requires: %{name} = %{version}-%{release} > > # Upgrade path > > Provides: freetype-utils = 2.2.0-1 > > Obsoletes: freetype-utils < 2.2.0-1 > > Very ugly. At the time this freetype-utils sub-package was > introduced, it should have started at 1.x, not 2.x. > > You could still do that with a proper Epoch. Right. So, should I use Epoch instead? Like: Provides: freetype-utils = 1:1.4-0.1.pre
(In reply to comment #2) > And you should omit static libs (%_libdir/lib*.a) and %{_libdir}/lib*.la files. Correct. The freetype package in Core is not dropping those. Will fix both.
Re: comment #4 If there exists no upstream freetype-1.4pre1, then I suggest you change to a release that *does* exist. Re: comment #5, >So, should I use Epoch instead? Like: >Provides: freetype-utils = 1:1.4-0.1.pre imo, yes, this is better. (though epochs should usually be avoided when/if possible, I see no better alternative in this case to fix the previous hackage).
(In reply to comment #7) > Re: comment #4 > If there exists no upstream freetype-1.4pre1, then I suggest you change to a > release that *does* exist. I don't agree. This is about a compatibility library that was last developed (the 1.x series) in 2000. I strongly believe that we should just continue to ship the exact same thing that we have been shipping so far in core, instead of archeology. There's absolute no advantage in switching over.
(Justifications aside) my point is that *I*, as reviewer, won't approve of any package for which there exists no (verifiable) upstream source.
(In reply to comment #9) > (Justifications aside) my point is that *I*, as reviewer, won't approve of any > package for which there exists no (verifiable) upstream source. What do you suggest I do, given that changing source is not an option?
(In reply to comment #10) > What do you suggest I do, given that changing source is not an option? There is an obvious solution: Use the latest official tarball as basis and provide a patch against it.
I refuse to fix something that is not broken. If you just want to verify the tarball, you can compare it to the one in freetype-2.1.10 core package. If the review cannot go through with the current tarball, I withdraw my request and let someone else package freetype1. A few Extras packages depend on it. Thanks,
As I said to Behdad, if you really care about 6 year old tarballs that much, do the work. Behdad did what you could expect from him by providing a package that picks up exactly the bits that he dropped from Core. Some Extras packages do depend on libttf, so either the maintainers of those packages will have to fight to get this reviewed, or have to port their packages away from libttf...
I fail to find any official upstream releases of FreeType 1.x.
> I fail to find any official upstream releases of FreeType 1.x. Here? http://sourceforge.net/project/showfiles.php?group_id=3157&package_id=3068
Re: comment #12: > If the review cannot go through with the current tarball, I withdraw my request That is the case (imo). If you refuse to play by the rules (using verifiable, upstream source), then follow through on your threat and withdraw the Review Request (and close this bug).
(In reply to comment #16) > Re: comment #12: > > If the review cannot go through with the current tarball, I withdraw my request > > That is the case (imo). If you refuse to play by the rules (using verifiable, > upstream source), then follow through on your threat and withdraw the Review > Request (and close this bug). This was not a threat. And I appreciate if you don't call my acts like that. I removed freetype1 code from the Core package, so I tried to be nice and package it for Extras. If it's too much work for little to no benefit, I don't have the time to do that. I actually did download the tarball you linked to and it's sitting in my laptop waiting for some attention. But that doesn't mean much in this conversation...
> This was not a threat. And I appreciate if you don't call my acts > like that. It was what it was, though I apologize for taking the too aggressive tone. I was cranky that I had too many (inactive) bugs not getting fixed this morning, and I took a little of that out on you. > I actually did download the tarball you linked to and it's sitting in > my laptop waiting for some attention. Thanks for the Extras (pun intended) effort. (:
Hi all, First of all apologies for hijacking this review, but it seems a bit stalled. Some timeago davej send a mail to the FE list that he would dearly miss MagicPoint, since davej is a nice guy and does tremendous work for the FC kernel I thought I could do him a favour by unorphaning MagicPoint however it turns out that MagicPoint requires freetype1, so here I am. Behdad Esfahbod, thanks for creating and posting the freetype1 compat package, I think it is great that you thought about possible troubles for FE when dropping this from Core. However I also see that you are not an FE contributer at the moment and thus need to go to the sponsering process. Is this the only package you intend to submit and maintain in FE, or do you plan to submit other packages too? If this is the only one then it would maybe be better if someoneelse (me for example) maintained freetype1 in FE, in that case I would like to ask you to be my co-maintainer as I assume you no freetype infinetely better then I do so if I get any bug reports against freetype which are about functional problems (not packaging problems) then I could really use your help. If you intend to submit more packages then you'll need a sponsor. Since I can sponsor people and I know have a vested interest in getting freetype1 into FE, let me offer myself as your sponsor in this scenario. Either way I've already prepared a cleaned up and improved freetype1 package with the following changes: * Thu Oct 19 2006 Hans de Goede <j.w.r.degoede> 1.4-0.2.pre - Base on freetype-1.3.1.tar.gz + a patch with the changes contained in the 1.4pre tarbal found in previous Fedora Core freetype releases - Cleanup and FE-ize the spec file - Don't reautoconf as that doesn't seem nescesarry - Fix (remove) use of rpath - Don't include static libs and .la files - Give the freetype1-utils Obsoletes and Provides an Epoch instead of using a 2.x version. Do you know why the whole reautoconf thing was ever done in the first place? You can get this new version from here: http://people.atrpms.net/~hdegoede/freetype1.spec http://people.atrpms.net/~hdegoede/freetype1-1.4-0.2.pre.src.rpm
(In reply to comment #19) > Behdad Esfahbod, thanks for creating and posting the freetype1 compat package, I > think it is great that you thought about possible troubles for FE when dropping > this from Core. However I also see that you are not an FE contributer at the > moment and thus need to go to the sponsering process. Is this the only package > you intend to submit and maintain in FE, or do you plan to submit other packages > too? I'm actually sponsored by Daniel Veillard, but by all means, please go for it. I have enough packages to maintain in Core that I really appreciate a hand here. This bug is yours now.
As for the autoreconf, it's there because the tarball is really really old. If you remove that, make sure you do libtoolize at least. We depend on a recent libtool for libraries to work on all platforms.
Ok, I'll take this through review and import it then. Rex, can you do a formal review of the version I posted please? Thanks!
I'm swamped temporarily, maybe next week.
Okay, no problem I only named you because of your previous comments, who knows maybe someone will beat you to it :)
*** Bug 212488 has been marked as a duplicate of this bug. ***
I can get on with it later today (just got to get the buildsys working again).
Paul, many thanks for offering to review this, but it seems it has fallen through the cracks, anytime on a review soon? Thanks!
Sorry for the delay - had all sorts of problems at this end. rpmlint - clean on all package (non main packages have no docs warnings, ignore) mock - clean REVIEW License - is BSD-like a valid type? Consistent use of macros Spec in UTF-8, US English, Clear No permission / ownership issues Contains documentation (see above) Contains reason for not using smp_make Removes .la files MD5s match for the tarballs Contains clean, pre and postuns No RPM dep issues If you can confirm that BSD-like is a valid license, I'm happy.
Well rpmlint likes it, so I assume its a valid license, I took this from the spec initially created by the core freetype maintainer.
*** Bug 217479 has been marked as a duplicate of this bug. ***
APPROVED
Thanks, now that I'm sorta back online I've imported and build this, closing.