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
Summary: | Review Request: uuid | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Steven Pritchard <steve> |
Component: | Package Review | Assignee: | Jason Tibbitts <j> |
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Package Reviews List <fedora-package-review> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-05-29 23:12:45 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 163779, 192575 |
Description
Steven Pritchard
2006-05-20 19:46:27 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. (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. |