[Bug 561286] Review Request: libdmtx - Library for working with Data Matrix 2D barcodes

[bugzilla at redhat.com]

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=561286

Jason Tibbitts <tibbs at math.uh.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|nobody at fedoraproject.org    |tibbs at math.uh.edu
               Flag|                            |fedora-review?

--- Comment #6 from Jason Tibbitts <tibbs at math.uh.edu> 2010-11-17 09:37:22 EST ---
I'm still looking over old review tickets.  This one builds fine; rpmlint says:

  libdmtx.x86_64: W: shared-lib-calls-exit
   /usr/lib64/libdmtx.so.0.0.0 exit at GLIBC_2.2.5
Libraries shouldn't do this, but there's not much you can do about it.

  php-libdmtx.x86_64: W: private-shared-object-provides
   /usr/lib64/php/modules/dmtx.so dmtx.so()(64bit)
  python-libdmtx.x86_64: W: private-shared-object-provides
   /usr/lib64/python2.7/site-packages/_pydmtx.so _pydmtx.so()(64bit)
This is one of the packages where you cannot use the filtering macros since it
installs both public libraries and binary executables.  So there's not much you
can do about rpmlint's complaints.

Am I wrong or is wrapper/php/dmtx_write.c not GPLv2+ instead of LGPLv2+?  It
appears that this code is linked intothe php dmtx.so module, which would make
that code GPLv2+, wouldn't it?  And if so, you'll have to include COPYING
somewhere, not just COPYING.LESSER.

What does the test suite actually do?  I see that it gets built, but I don't
see where the built tests actually get run.  I'm not even sure if the can be
run automatically.


* source files match upstream.  sha256sum:
  73af17374cf45478fdcb4184c2321d3b923291780430dec4908d9ea686143646
   libdmtx-0.7.2.tar.bz2
* 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.
X license field matches the actual license.
* license is open source-compatible.
X license text not included in package.
* latest version is being packaged.
* BuildRequires are proper.
* compiler flags are appropriate.
* package builds in mock (f14, x86_64).
* package installs properly.
* debuginfo package looks complete.
* rpmlint has acceptable complaints.
* final provides and requires are sane:
  libdmtx-0.7.2-2.fc14.x86_64.rpm
   libdmtx.so.0()(64bit)  
   libdmtx = 0.7.2-2.fc14
   libdmtx(x86-64) = 0.7.2-2.fc14
  =
   /sbin/ldconfig  
   libdmtx.so.0()(64bit)  

  libdmtx-devel-0.7.2-2.fc14.x86_64.rpm
   pkgconfig(libdmtx) = 0.7.2
   libdmtx-devel = 0.7.2-2.fc14
   libdmtx-devel(x86-64) = 0.7.2-2.fc14
  =
   /usr/bin/pkg-config  
   libdmtx = 0.7.2-2.fc14
   libdmtx.so.0()(64bit)  

  libdmtx-utils-0.7.2-2.fc14.x86_64.rpm
   libdmtx-utils = 0.7.2-2.fc14
   libdmtx-utils(x86-64) = 0.7.2-2.fc14
  =
   libMagickCore.so.4()(64bit)  
   libMagickWand.so.4()(64bit)  
   libdmtx = 0.7.2-2.fc14
   libdmtx.so.0()(64bit)  
   libgomp.so.1()(64bit)  

  php-libdmtx-0.7.2-2.fc14.x86_64.rpm
   dmtx.so()(64bit)  
   php-libdmtx = 0.7.2-2.fc14
   php-libdmtx(x86-64) = 0.7.2-2.fc14
  =
   libdmtx = 0.7.2-2.fc14
   libdmtx.so.0()(64bit)  
   php-common  

  python-libdmtx-0.7.2-2.fc14.x86_64.rpm
   _pydmtx.so()(64bit)  
   python-libdmtx = 0.7.2-2.fc14
   python-libdmtx(x86-64) = 0.7.2-2.fc14
  =
   libdmtx = 0.7.2-2.fc14
   libdmtx.so.0()(64bit)  
   libpython2.7.so.1.0()(64bit)  
   python(abi) = 2.7

  ruby-libdmtx-0.7.2-2.fc14.x86_64.rpm
   Rdmtx.so()(64bit)  
   ruby(libdmtx) = 0.7.2
   ruby-libdmtx = 0.7.2-2.fc14
   ruby-libdmtx(x86-64) = 0.7.2-2.fc14
  =
   libdmtx = 0.7.2-2.fc14
   libdmtx.so.0()(64bit)  
   libruby.so.1.8()(64bit)  

? %check is present, but tests are not run.  Can they be run?
* shared libraries present; ldconfig called properly.  Unversioned .so link
   is in the -devel subpackage.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* 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 package.
* pkgconfig files are in the -devel package.
* 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.