I think the license is essentially the MIT license:
http://www.opensource.org/licenses/mit-license.php
It's probably a better fit than "Distributable".

rpmlint, as usual, finds something to complain about:

E: uuid binary-or-shlib-defines-rpath /usr/bin/uuid ['/usr/lib64']
W: uuid unstripped-binary-or-object /usr/lib64/libuuid.so.14.0.22
W: uuid-c++ unstripped-binary-or-object /usr/lib64/libuuid++.so.14.0.22
W: uuid-c++ no-documentation
W: uuid-dce unstripped-binary-or-object /usr/lib64/libuuid_dce.so.14.0.22
W: uuid-dce no-documentation
W: uuid-dce-devel no-documentation
W: uuid-pgsql no-documentation
W: uuid-php no-documentation

The no-documentation ones are OK.  The unstripped object warnings are
problematic; I don't know what to do about those.  The rpath problem can be made
to go away by adding:

BuildRequires: libtool

then changing the make line to:

make LIBTOOL=/usr/bin/libtool %{?_smp_mflags}

and then adding this after the make install:

rm -f $RPM_BUILD_ROOT%{_libdir}/*.a

* package meets naming and packaging guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* dist tag is present.
? license field matches the actual license.
* license is open source-compatible.  License text included in package.
* source files match upstream:
   fdfe93bc134dfb73814456c3b444dda1  uuid-1.4.2.tar.gz
   fdfe93bc134dfb73814456c3b444dda1  uuid-1.4.2.tar.gz-srpm
* latest version is being packaged.
* BuildRequires are proper.  (I didn't realize you could list them in the
subpackage declarations.)
* package builds in mock (development, x86_64).
X rpmlint complains of rpath and unstripped libraries.
* final provides and requires are sane.
* shared libraries are present; ldconfig is called where necessary.  (Some
libraries are internal to Perl, PHP, pgsql, etc. so ldconfig is not called for
those packages.)  Unversioned libraries are in -devel subpackages.
* packages are not relocatable.
* own the directories they creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* %clean is present.
* %check is present and all tests seem to pass.
* scriptlets present and quite sane.
* code, not content.
* documentation is small, so no -docs subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* headers are in -devel subpackages.
* no pkgconfig files.
* no libtool .la droppings.
* not a GUI app.

(In reply to comment #1)
> I think the license is essentially the MIT license:
> http://www.opensource.org/licenses/mit-license.php
> It's probably a better fit than "Distributable".

OK.  Fixed in -2.

> rpmlint, as usual, finds something to complain about:
> 
> E: uuid binary-or-shlib-defines-rpath /usr/bin/uuid ['/usr/lib64']
> W: uuid unstripped-binary-or-object /usr/lib64/libuuid.so.14.0.22
> W: uuid-c++ unstripped-binary-or-object /usr/lib64/libuuid++.so.14.0.22
> W: uuid-c++ no-documentation
> W: uuid-dce unstripped-binary-or-object /usr/lib64/libuuid_dce.so.14.0.22
> W: uuid-dce no-documentation
> W: uuid-dce-devel no-documentation
> W: uuid-pgsql no-documentation
> W: uuid-php no-documentation
> 
> The no-documentation ones are OK.

Agreed.

> The unstripped object warnings are problematic; I don't know what to do about
those.

I don't either.  I'm assuming the auto-strip magic is breaking for some reason,
but I can't imagine what that reason is...

> The rpath problem can be made to go away by adding:
[libtool stuff]

I tried that, but I still get the %{_libdir} rpath.  Is that really an issue?

I fixed a build directory rpath problem in the PHP module, BTW.  Trying a
similar fix for the %{_libdir} rpath thing (introduced, I'm 99% sure, by a
-rpath in Makefile.in) results in a failed build.  Well, actually, a failed
install.  Try adding "sed -i -e 's/ -rpath \$(libdir)//' Makefile.in" to %prep
if you want to see what I mean.  I might just be dense, but I don't see how to
fix the problem.

Looks like we need more expertise.

As for rpath, my understanding is that we should do what we can to eliminate it
but that if it's simply not possible then it won't keep the package out.  But
after patching the spec as I suggested I see no trace of rpath.  That technique
has worked for me in the past.

About the unstripped libraries, it looks like they aren't executable, so they
don't get stripped.  I've seen this in the past, and a chmod 755 has fixed it
up, but while looking through /usr/lib/rpm/redhat/brp-strip* I saw this:

# Strip ELF shared objects
# Please note we don't restrict our search to executable files because
# our libraries are not (should not be, at least) +x.

Sometimes it's just so difficult to figure out how things are really supposed to
be done.

(In reply to comment #3)
> As for rpath, my understanding is that we should do what we can to eliminate it
> but that if it's simply not possible then it won't keep the package out.  But
> after patching the spec as I suggested I see no trace of rpath.  That technique
> has worked for me in the past.

Weird.  I just tried it again, and it works this time.  I must have changed the
wrong make line or something.

> About the unstripped libraries, it looks like they aren't executable, so they
> don't get stripped.  I've seen this in the past, and a chmod 755 has fixed it
> up, but while looking through /usr/lib/rpm/redhat/brp-strip* I saw this:
> 
> # Strip ELF shared objects
> # Please note we don't restrict our search to executable files because
> # our libraries are not (should not be, at least) +x.

That's interesting.  Just about everything else in my /usr/lib64 is executable.
 And, sure enough, adding in a chmod gets rid of that rpmlint warning.

Try -3, please.

-3 looks good except for this:

W: uuid-php devel-file-in-non-devel-package /usr/lib64/php/modules/uuid.a

I guess this cropped up with your fix for an rpath issue in the PHP module.  I
didn't notice it before but maybe rpmlint just didn't pick it up.

At this point, with the exception of deleting that errant static library I think
we're ready to go.  So I'll approve now and you can clean it up when you check in.

APPROVED

(In reply to comment #5)
> -3 looks good except for this:
> 
> W: uuid-php devel-file-in-non-devel-package /usr/lib64/php/modules/uuid.a
> 
> I guess this cropped up with your fix for an rpath issue in the PHP module.  I
> didn't notice it before but maybe rpmlint just didn't pick it up.

Oops.  I didn't notice that.  (And yes, it is new in -3.)  Sorry.

I'm importing -4 into CVS now with that fixed.

$ rpmlint uuid-*1.4.2-4.x86_64.rpm
W: uuid-c++ no-documentation
W: uuid-dce no-documentation
W: uuid-dce-devel no-documentation
W: uuid-pgsql no-documentation
W: uuid-php no-documentation

Imported into CVS, branches created, and builds requested.