[Bug 506339] Review Request: XZ Utils - LZMA Utils with newer file format

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=506339


Jason Tibbitts <tibbs@xxxxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|xjakub@xxxxxxxxxx           |tibbs@xxxxxxxxxxx




--- Comment #23 from Jason Tibbitts <tibbs@xxxxxxxxxxx>  2009-07-16 20:25:30 EDT ---
Perhaps Milos is on vacation, but it's come to my attention that this is
critical and needs a review immediately, so I've volunteered to take care of
this.  I don't mean to step on anyone's toes, but we have some important stuff
waiting on this review.

Builds fine; rpmlint says:
  xz.x86_64: W: name-repeated-in-summary XZ
Generally I'd just suggest dropping "XZ Utils" from the summary, but it's not a
big deal.

  xz.x86_64: W: incoherent-version-in-changelog 4.9999.8-0.6.beta 
   ['4.999.8-0.6.beta.fc12', '4.999.8-0.6.beta']
There's an extra '9' in the changelog entry.

  xz-devel.x86_64: W: no-documentation                          
OK.

  xz-lzma-compat.x86_64: W: dangling-relative-symlink /usr/bin/lzcat xz
  xz-lzma-compat.x86_64: W: dangling-relative-symlink /usr/bin/unlzma xz
  xz-lzma-compat.x86_64: W: dangling-relative-symlink /usr/bin/lzma xz
These are OK because the links aren't dangling when dependencies are installed.

  xz-libs.x86_64: W: unused-direct-shlib-dependency
   /usr/lib64/liblzma.so.0.0.0 /lib64/libpthread.so.0
This isn't a particularly big deal.

So outside of one typo in the changelog, I don't see anything that really needs
fixing.

I looked over the licensing and have a question.  The code that I believe you
currently indicate is LGPLv2+ is public domain unless the getopt_long code is
used.  But there shouldn't be any reason for that to be compiled or linked in,
because glibc should already have it.  Indeed, the build log shows no trace of
that code being used.  So why isn't the bulk of the package public domain? 
(Obviously the various scripts that are GPLv2+ and are correctly marked as
such.)

There's a test suite present.  I tried it and it fails utterly, though it
passes when I build the package locally.   I suspect this is related to the
rpath issues, so I went with the following:
  %check
  LD_LIBRARY_PATH=$PWD/src/liblzma/.libs make check
and it worked fine.   I think it's a good idea the test suite if at all
possible, and it seems possible.  Any reason not to add it?

* source files match upstream.  sha256sum:
   059da5a9fe51c28b38f67e5b8063a451c516f37fbb268177fd1081b70dd97f53  
   xz-4.999.8beta.tar.gz
* package meets naming and versioning guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* summary is OK.                                                              
* description is OK.                                                          
* dist tag is present.
* build root is OK.
? license fields match the actual licenses.
* license is open source-compatible.
* license text included in package.
* latest version is being packaged.
* BuildRequires are proper (none).
* compiler flags are appropriate.
* %clean is present.
* package builds in mock (rawhide, x86_64).
* package installs properly.
* debuginfo package looks complete.
* rpmlint has acceptable complaints.
* final provides and requires are sane:
  xz-4.999.8-0.6.beta.fc12.x86_64.rpm
   xz = 4.999.8-0.6.beta.fc12           
   xz(x86-64) = 4.999.8-0.6.beta.fc12   
  =                                  
   liblzma.so.0()(64bit)                
   xz-libs = 4.999.8-0.6.beta.fc12      

  xz-devel-4.999.8-0.6.beta.fc12.x86_64.rpm
   pkgconfig(liblzma) = 4.999.8beta
   xz-devel = 4.999.8-0.6.beta.fc12
   xz-devel(x86-64) = 4.999.8-0.6.beta.fc12
  =
   /usr/bin/pkg-config
   liblzma.so.0()(64bit)
   pkgconfig
   xz-libs = 4.999.8-0.6.beta.fc12

  xz-libs-4.999.8-0.6.beta.fc12.x86_64.rpm
   liblzma.so.0()(64bit)
   xz-libs = 4.999.8-0.6.beta.fc12
   xz-libs(x86-64) = 4.999.8-0.6.beta.fc12
  =
   /sbin/ldconfig
   liblzma.so.0()(64bit)

  xz-lzma-compat-4.999.8-0.6.beta.fc12.x86_64.rpm
   lzma = 5
   xz-lzma-compat = 4.999.8-0.6.beta.fc12
   xz-lzma-compat(x86-64) = 4.999.8-0.6.beta.fc12
  =
    /bin/sh
   liblzma.so.0()(64bit)
   xz = 4.999.8-0.6.beta.fc12

* %check is not present but there's a test suite.
* shared libraries are installed:
   ldconfig called properly.
   unversioned .so link is in the -devel package.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files (excepting license files, which has been deemed OK).
* file permissions are appropriate.
* no generically named files.
* scriptlets are OK (ldconfig).
* code, not content.
* documentation is small, so no -doc subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* headers are in the -devel subpackage.
* pkgconfig file is in the -devel package; pkgconfig dependency is there.
* no static libraries.
* no libtool .la files.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

_______________________________________________
Fedora-package-review mailing list
Fedora-package-review@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-package-review

[Index of Archives]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]