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.