[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

--- Comment #7 from Mike Laughton <mike at dragonflylogic.com> 2010-11-17 11:01:50 EST ---
(In reply to comment #6)

Thanks for looking into this ticket. I'm the lead developer for libdmtx and
would like to help on these issues if possible. This package has been developed
primarily on Fedora since day one, so it would give me great satisfaction for
it to find a home in the repositories. Please see my comments below:

> 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.

Whoops - looks like I missed that one. I've added an item to my TODO list to
clean up any remaining calls to exit().

> 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.

Would it greatly simplify things if I split the package into a library-only
package and a separate utilities/wrappers/other package? I have been tempted to
do this for maintenance reasons anyway, but would appreciate any input from
someone on the packager side of the fence.

> 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.

Everything was intended to be LGPLv2, so if you are seeing otherwise then it's
probably due to a mistake somewhere. What are you seeing that suggests GPLv2+?

> 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.

There are a few different testing components representing a mixture of uses:

 * compare_test - Regression testing script (invoked manually)
 * multi_test - Visualization and experimental program for interactive testing
 * rotate_test - Visualization and experimental program for interactive testing 
 * simple_test - Basic round-trip test of library internals
 * unit_test - Intended to someday hold unit tests for automated testing

But to answer your question, nothing is set up to execute when you issue a
'make test' during the main build.

Going through your open issues list:

X license field matches the actual license.
X license text not included in package.
  [Mike] Please let me know what I can do to resolve this issue. I may still
have the original email where that contributor agreed to LGPL if that helps.

? %check is present, but tests are not run.  Can they be run?
  [Mike] Is there an automated testing requirement for inclusion in Fedora? If
so, please point me to a resource where I can get up to speed.

Thanks again for looking into this old ticket. I'd like to package libdmtx in a
way that makes life easy for packagers, but unfortunately I'm not very familiar
with that world.

Mike

-- 
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.