https://bugzilla.redhat.com/show_bug.cgi?id=961237 --- Comment #21 from Daniel Pocock <daniel@xxxxxxxxxxxxx> --- On 09/08/13 09:38, bugzilla@xxxxxxxxxx wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=961237 > > > > --- Comment #20 from Michael Schwendt <bugs.michael@xxxxxxx> --- > Created attachment 784745 > --> https://bugzilla.redhat.com/attachment.cgi?id=784745&action=edit > licensecheck.txt done by fedora-review tool > > "fedora-review -b 961237" complains about a few things, not limited to the > src.rpm containing a spec file different from the separately linked spec file. > > The license headers it finds: > > *No copyright* zlib/libpng That appears to be a false positive https://github.com/sipXtapi/sipXtapi/blob/master/sipXcallLib/examples/include/nss/zlib.h contains a complete copyright and license info libpng does not appear to be included in the tree, it is used by some of the examples but is not a dependency of the binary packages. > BSD (3 clause) > BSD (4 clause) > BSD (4 clause) ISC These all appear compatible with the stated LGPL-2 license except for BSD 4 clause I checked the 4-clause BSD code It is code that is covered by the UCB statement retrospectively relicensing all their code as 3-clause, specifically: ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change > GPL (v2 or later) Some source files in the examples have a GPL license. They are not compiled or distributed in the binary RPMs, the package works without them. I've added comments about all of these extra licenses to the spec file, can you please look at it in github and see if the comments are sufficient to explain this package? https://github.com/dpocock/sipxtapi-rpm/blob/master/sipxtapi.spec > ISC > Unknown or generated > zlib/libpng > > [...] > >> - Package does not contain duplicates in %files. >> Note: warning: File listed twice: /usr/share/doc/sipxtapi/sipXcallLib >> See: http://fedoraproject.org/wiki/Packaging/Guidelines#DuplicateFiles > Indeed. Change the following from > > %files doc > %doc %{_docdir}/%{name}/* > %{_docdir}/%{name}/ > > to: > > %files doc > %{_docdir}/%{name}/ Fixed > What you wanted would be: > > %files doc > %{_docdir}/%{name}/* > %dir %{_docdir}/%{name} > > Files below %_docdir are marked %doc automatically, btw. > > [...] > > Rpmlint (installed packages) > ---------------------------- > # rpmlint sipxtapi-doc sipxtapi sipxtapi-devel > sipxtapi-doc.x86_64: W: spelling-error %description -l en_US softphones -> soft > phones, soft-phones, sousaphones > sipxtapi.x86_64: W: unused-direct-shlib-dependency > /usr/lib64/libsipXmediaProcessing.so.1.0.0 /lib64/libssl.so.10 > sipxtapi.x86_64: W: unused-direct-shlib-dependency > /usr/lib64/libsipXmediaProcessing.so.1.0.0 /lib64/libcrypto.so.10 > sipxtapi.x86_64: W: unused-direct-shlib-dependency > /usr/lib64/libsipXmediaProcessing.so.1.0.0 /lib64/libpcre.so.1 > sipxtapi.x86_64: W: unused-direct-shlib-dependency > /usr/lib64/libsipXmediaProcessing.so.1.0.0 /lib64/libdl.so.2 > sipxtapi.x86_64: W: unused-direct-shlib-dependency > /usr/lib64/libsipXmediaProcessing.so.1.0.0 /lib64/libpthread.so.0 > sipxtapi.x86_64: W: unused-direct-shlib-dependency > /usr/lib64/libsipXmediaProcessing.so.1.0.0 /lib64/libgsm.so.1 > sipxtapi.x86_64: W: unused-direct-shlib-dependency > /usr/lib64/libsipXmediaProcessing.so.1.0.0 /lib64/librt.so.1 > sipxtapi.x86_64: W: unused-direct-shlib-dependency > /usr/lib64/libsipXmediaProcessing.so.1.0.0 /lib64/libresolv.so.2 > sipxtapi.x86_64: W: unused-direct-shlib-dependency > /usr/lib64/libsipXsdp.so.1.0.0 /lib64/libm.so.6 > sipxtapi.x86_64: W: unused-direct-shlib-dependency > /usr/lib64/libsipXmedia.so.1.0.0 /lib64/libgsm.so.1 > sipxtapi.x86_64: W: unused-direct-shlib-dependency > /usr/lib64/libsipXport.so.2.0.0 /lib64/libm.so.6 > sipxtapi-devel.x86_64: W: no-documentation > 3 packages and 0 specfiles checked; 0 errors, 13 warnings. > # echo 'rpmlint-done:' > spelling-error seems odd. If we can't use "softphone", then words like "software" should become "soft-ware" perhaps I've suppressed spelling-error and no-documentation Do the other issues definitely need to be fixed upstream or can the package be accepted despite the warnings? The other issues require further work on the autotools build system. It is quite complicated because there are many custom macros and multiple library projects. It appears to just link some libs (e.g. libssl) for anything, and it needs to be changed to link those libs selectively when building libs that depend on them. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=AhK73XnLS0&a=cc_unsubscribe _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review