Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 192564 - Review Request: uuid
Summary: Review Request: uuid
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jason Tibbitts
QA Contact: Fedora Package Reviews List
URL:
Whiteboard:
Depends On:
Blocks: FE-ACCEPT 192575
TreeView+ depends on / blocked
 
Reported: 2006-05-20 19:46 UTC by Steven Pritchard
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-05-29 23:12:45 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Steven Pritchard 2006-05-20 19:46:27 UTC
Spec URL: http://ftp.kspei.com/pub/steve/rpms/uuid/uuid.spec
SRPM URL: http://ftp.kspei.com/pub/steve/rpms/uuid-1.4.2-1.src.rpm
Description:
OSSP uuid is a ISO-C:1999 application programming interface (API)
and corresponding command line interface (CLI) for the generation
of DCE 1.1, ISO/IEC 11578:1996 and RFC 4122 compliant Universally
Unique Identifier (UUID). It supports DCE 1.1 variant UUIDs of version
1 (time and node based), version 3 (name based, MD5), version 4
(random number based) and version 5 (name based, SHA-1). Additional
API bindings are provided for the languages ISO-C++:1998, Perl:5 and
PHP:4/5. Optional backward compatibility exists for the ISO-C DCE-1.1
and Perl Data::UUID APIs.

Comment 1 Jason Tibbitts 2006-05-23 20:16:49 UTC
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.


Comment 2 Steven Pritchard 2006-05-23 21:43:23 UTC
(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.

Comment 3 Jason Tibbitts 2006-05-23 22:06:28 UTC
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.


Comment 4 Steven Pritchard 2006-05-23 22:32:55 UTC
(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.

Comment 5 Jason Tibbitts 2006-05-23 23:54:01 UTC
-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

Comment 6 Steven Pritchard 2006-05-24 14:12:52 UTC
(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


Comment 7 Steven Pritchard 2006-05-29 23:12:45 UTC
Imported into CVS, branches created, and builds requested.


Note You need to log in before you can comment on or make changes to this bug.