Bug 450527

I note the following from rpmlint:

  libkni-doc.x86_64: E: zero-length 
   /usr/share/doc/libkni-docs-3.9.2/html/Timer_8h__incl.map
  libkni-doc.x86_64: E: zero-length 
   /usr/share/doc/libkni-docs-3.9.2/html/MathHelperFunctions_8h__incl.map
Any idea what these are?

  libkni-devel.x86_64: W: no-documentation
  libkni-examples.x86_64: W: no-documentation
  libkni-static.x86_64: W: no-documentation
These are OK.

There are a bunch of these:
  libkni.x86_64: W: undefined-non-weak-symbol /usr/lib64/libKNI_LM.so.3.9.0 
   _ZN7CKatana12waitForMotorEsiisi
  libkni.x86_64: W: undefined-non-weak-symbol /usr/lib64/libKNI_LM.so.3.9.0 
   _ZN8CKatBase7recvGMSEv
  libkni.x86_64: W: undefined-non-weak-symbol /usr/lib64/libKNI_InvKin.so.3.9.0 
_ZN7CKatana14moveRobotToEncEN9__gnu_cxx17__normal_iteratorIPKiSt6vectorIiSaIiEEEES7_bii
  libkni.x86_64: W: undefined-non-weak-symbol /usr/lib64/libKNI_InvKin.so.3.9.0 
   _ZN8CKatBase7recvMPSEv

Name mangling makes it a bit tough for me to understand what's going on here,
but something doesn't seem to be linked properly.

You probably want to s/für/for/ in the Summary.

What is the KatanaNativeInterface-v3.9.2.exe file in the tarball?  It seems to
be a complete waste of space.

(In reply to comment #1)
> I note the following from rpmlint:
> 
>   libkni-doc.x86_64: E: zero-length 
>    /usr/share/doc/libkni-docs-3.9.2/html/Timer_8h__incl.map
>   libkni-doc.x86_64: E: zero-length 
>    /usr/share/doc/libkni-docs-3.9.2/html/MathHelperFunctions_8h__incl.map
> Any idea what these are?

These are autogenerated by doxygen, and for some reasons it makes them zero
bytes long. I still want to keep those just in case they are not zero-bytes in
another release...

>   libkni-devel.x86_64: W: no-documentation
>   libkni-examples.x86_64: W: no-documentation
>   libkni-static.x86_64: W: no-documentation
> These are OK.
> 
> There are a bunch of these:
>   libkni.x86_64: W: undefined-non-weak-symbol /usr/lib64/libKNI_LM.so.3.9.0 
>    _ZN7CKatana12waitForMotorEsiisi
>   libkni.x86_64: W: undefined-non-weak-symbol /usr/lib64/libKNI_LM.so.3.9.0 
>    _ZN8CKatBase7recvGMSEv
>   libkni.x86_64: W: undefined-non-weak-symbol /usr/lib64/libKNI_InvKin.so.3.9.0 
>
_ZN7CKatana14moveRobotToEncEN9__gnu_cxx17__normal_iteratorIPKiSt6vectorIiSaIiEEEES7_bii
>   libkni.x86_64: W: undefined-non-weak-symbol /usr/lib64/libKNI_InvKin.so.3.9.0 
>    _ZN8CKatBase7recvMPSEv
> 
> Name mangling makes it a bit tough for me to understand what's going on here,
> but something doesn't seem to be linked properly.

How did you get these? If I rpmlint the main package everthing is quiet. I've
also downloaded the x86_64 package from the mentioned scratch build and can't
see anything. Are you on rawhide?
I've checked that the very last symbol (CKatBase::recvMPS()), it is in the base
lib. But the InvKin lib is not linked directly against the base lib, so maybe
this is the problem. But before trying a fix I'd like to know how to produce
these errors...

> You probably want to s/für/for/ in the Summary.

Indeed :-)

> What is the KatanaNativeInterface-v3.9.2.exe file in the tarball?  It seems to
> be a complete waste of space.

Agreed. I have contacted Neuronics about it (and sent them the patches). They
told me basically that usual customers are dumb and would call support because
they downloaded the very first file and then wondered where the Windoze drivers
were... So they just do it to get rid of these calls.

You can only get undefined-non-weak-symbol complaints by installing the package
and then running "rpmlint libkni".  My build script installs the built package
into the mock chroot in order to do this.

Ok, now that I could reproduce it (thanks for this info!) I could confirm that
it is in fact a problem because the LM and InvKin libs were not linked against
the Base lib. I fixed this. New SRPM is at
http://fedorapeople.org/~timn/robotics/libkni-3.9.2-4.fc9.src.rpm

Jason, would you mind to have a look again on the new package?

Jason, are you willing to continue the review and have a look at the latest package? Thanx!

Automated result from review-o-matic

http://koji.fedoraproject.org/koji/taskinfo?taskID=887113

0 packages and 0 specfiles checked; 0 errors, 0 warnings.

Above comment came due to a bug in review-o-matic, we are testing it in the intial stage.

Automated result from review-o-matic

http://koji.fedoraproject.org/koji/taskinfo?taskID=887113

libkni-devel.i386: W: no-documentation
libkni-devel.ppc64: W: no-documentation
libkni-devel.ppc: W: no-documentation
libkni-devel.x86_64: W: no-documentation
libkni-doc.i386: E: zero-length /usr/share/doc/libkni-docs-3.9.2/html/Timer_8h__incl.map
libkni-doc.i386: E: zero-length /usr/share/doc/libkni-docs-3.9.2/html/MathHelperFunctions_8h__incl.map
libkni-doc.ppc64: E: zero-length /usr/share/doc/libkni-docs-3.9.2/html/Timer_8h__incl.map
libkni-doc.ppc64: E: zero-length /usr/share/doc/libkni-docs-3.9.2/html/MathHelperFunctions_8h__incl.map
libkni-doc.ppc: E: zero-length /usr/share/doc/libkni-docs-3.9.2/html/Timer_8h__incl.map
libkni-doc.ppc: E: zero-length /usr/share/doc/libkni-docs-3.9.2/html/MathHelperFunctions_8h__incl.map
libkni-doc.x86_64: E: zero-length /usr/share/doc/libkni-docs-3.9.2/html/Timer_8h__incl.map
libkni-doc.x86_64: E: zero-length /usr/share/doc/libkni-docs-3.9.2/html/MathHelperFunctions_8h__incl.map
libkni-examples.i386: W: no-documentation
libkni-examples.ppc64: W: no-documentation
libkni-examples.ppc: W: no-documentation
libkni-examples.x86_64: W: no-documentation
libkni-static.i386: W: no-documentation
libkni-static.ppc64: W: no-documentation
libkni-static.ppc: W: no-documentation
libkni-static.x86_64: W: no-documentation
26 packages and 1 specfiles checked; 8 errors, 12 warnings.

I'm sorry I haven't been able to get back to this, but I have some time now.

Too bad the so-called "review-o-matic" can't actually interpret that rpmlint output.  The no-documentation complaints are OK, the zero-length files in the -docs package are all due to the usual suck that comes with doxygen.

The upstream URL doesn't seem to take me to anywhere useful.  The page isn't exactly blank, but it doesn't seem to actually refer to the software.   I went to the download page and there seems to be a 4.0.0 version out there; I'll look at it if you would like to do an update.

The source files indicate GPLv2+ (they have the "any later version" clause), so the license tag seems off.

There's some mixed macro use in the spec; if you're not going to use %{__mkdir_p} and %{__rm}, then don't use %{__install} either.

I can't tell if all of the source gets into the debuginfo package.  Its compiled, but I guess its possible that some of it may only go into the static libraries from which debuginfo can't be generated.  Certainly some of the source is in there.

* source files match upstream:
   85b28a100feb0dd77a94e4d77922fa7849078eef3438d969c0c01cfb6a01d296  
   KNI_3.9.2.tar.gz
* package meets naming and versioning guidelines.
X specfile does not use macros consistently
* summary is OK.
* description is OK.
* dist tag is present.
* build root is OK.
X license field matches the actual license.
* license is open source-compatible.
* license text included in package.
* BuildRequires are proper.
* compiler flags are appropriate (as far as I can tell; build output is hidden).
* %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:
  libkni-3.9.2-4.fc10.x86_64.rpm
   config(libkni) = 3.9.2-4.fc10
   libKNIBase.so.3.9()(64bit)
   libkni = 3.9.2-4.fc10
   libkni(x86-64) = 3.9.2-4.fc10
  =
   /sbin/ldconfig
   config(libkni) = 3.9.2-4.fc10
   libKNIBase.so.3.9()(64bit)
   libgcc_s.so.1()(64bit)
   libgcc_s.so.1(GCC_3.0)(64bit)
   libstdc++.so.6()(64bit)
   libstdc++.so.6(CXXABI_1.3)(64bit)
   libstdc++.so.6(GLIBCXX_3.4)(64bit)
   libstdc++.so.6(GLIBCXX_3.4.9)(64bit)

  libkni-devel-3.9.2-4.fc10.x86_64.rpm
   pkgconfig(libkni) = 3.9.2
   libkni-devel = 3.9.2-4.fc10
   libkni-devel(x86-64) = 3.9.2-4.fc10
  =
   libKNIBase.so.3.9()(64bit)
   libkni = 3.9.2-4.fc10
   pkgconfig

  libkni-doc-3.9.2-4.fc10.x86_64.rpm
   libkni-doc = 3.9.2-4.fc10
   libkni-doc(x86-64) = 3.9.2-4.fc10
  =

  libkni-examples-3.9.2-4.fc10.x86_64.rpm
   libkni-examples = 3.9.2-4.fc10
   libkni-examples(x86-64) = 3.9.2-4.fc10
  =
   libKNIBase.so.3.9()(64bit)
   libgcc_s.so.1()(64bit)
   libgcc_s.so.1(GCC_3.0)(64bit)
   libkni = 3.9.2-4.fc10
   libstdc++.so.6()(64bit)
   libstdc++.so.6(CXXABI_1.3)(64bit)
   libstdc++.so.6(CXXABI_1.3.1)(64bit)
   libstdc++.so.6(GLIBCXX_3.4)(64bit)
   libstdc++.so.6(GLIBCXX_3.4.9)(64bit)

  libkni-static-3.9.2-4.fc10.x86_64.rpm
   libkni-static = 3.9.2-4.fc10
   libkni-static(x86-64) = 3.9.2-4.fc10
  =
   libkni-devel = 3.9.2-4.fc10

* %check is not present; no test suite upstream.  I've no idea how to test this, 
   since I have no robotic arms handy.
* shared libraries present:
   unversioned .so files are in the -devel package.
   ldconfig called properly.
* 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.
* %docs are not necessary for the proper functioning of the package.
* headers are in the -devel package.
* pkgconfig file is in the -devel package, with proper dependency.
* static libraries are in a separate -static package.
* no libtool .la files.

I have fixed the license tag and converted to consistent (non-)macro usage. The URL used to contain more info, seems they changed it. I now added a link to http://www.neuronics.ch/cms_de/web/index.php?id=386 which describes the overall architecture and the place of the KNI in this. Additionally I added a patch that is necessary for usage with usb2ser adapter. Patch went to Neuronics as well.

I want to stay with version 3.9.2 for now. I will have to do some tests with the new version on the robot with the arm, as it is a major release and they changed some core components. I'll push an update later if it works just fine. I also have to check if it can be a drop-in replacement or if the API has changed.

The new SRPM is at http://fedorapeople.org/~timn/robotics/libkni-3.9.2-6.fc9.src.rpm.

This fails to build for me; patch 3 fails to apply:

Patch #3 (kni-3.9.2-ctor.patch):
+ /usr/bin/patch -s -p1 -b --suffix .ctor --fuzz=0
+ /bin/cat /builddir/build/SOURCES/kni-3.9.2-ctor.patch
1 out of 3 hunks FAILED
 -- saving rejects to file src/Base/cdlCOM.cpp.rej
RPM build errors:
error: Bad exit status from /var/tmp/rpm-tmp.JKAEJ2 (%prep)
    Bad exit status from /var/tmp/rpm-tmp.JKAEJ2 (%prep)

Keep in mind that rawhide applies patches with --fuzz=0.  It builds if you force  --fuzz=2 but that shouldn't be needed for new packages.

Also, while building the latest package (with fuzz set to 2) I noticed the following odd output:

Building: ../../lib/linux/libKNI_InvKin.so.3.9.0
 [failed]
/usr/bin/ld: cannot find -lKNIBase
collect2: ld returned 1 exit status


Building: ../../lib/linux/libKNI_LM.so.3.9.0
 [failed]
/usr/bin/ld: cannot find -lKNIBase
collect2: ld returned 1 exit status

Building: keycontrol.demo
 [failed]
/tmp/ccFUilYk.o: In function `main':
/builddir/build/BUILD/KNI_3.9.2/demo/keycontrol/keycontrol.cpp:591: undefined reference to `CikBase::getCoordinates(double&, double&, double&, double&, double&, double&, bool)'
/builddir/build/BUILD/KNI_3.9.2/demo/keycontrol/keycontrol.cpp:928: undefined reference to `CikBase::moveRobotTo(double, double, double, double, double, double, bool, int)'
(and several more failures)

Building: socketcontrol.demo
 [failed]
/tmp/ccxSSsex.o: In function `main':
/builddir/build/BUILD/KNI_3.9.2/demo/socketcontrol/socketcontrol.cpp:731: undefined reference to `CLMBase::moveRobotLinearTo(double, double, double, double, double, double, bool, int)'
/builddir/build/BUILD/KNI_3.9.2/demo/socketcontrol/socketcontrol.cpp:596: undefined reference to `CikBase::getCoordinates(double&, double&, double&, double&, double&, double&, bool)'
(and several more failures)

And also the following additional rpmlint complaint:
  libkni.x86_64: W: shared-lib-calls-exit /usr/lib64/libKNIBase.so.3.9.0 
   exit.5

which is a bit odd.  It's not a blocker, but I wonder why I'm only seeing it now.

- Patch applies now cleanly, though I don't see the reasoning behind this fuzz stuff. Now I have to create the patch between two patched versions (as I want to keep the patches separate)...
- Added another patch which removes the calls to exit() and replaces them with an exception which is more sane.

New version at http://fedorapeople.org/~timn/robotics/libkni-3.9.2-7.fc10.src.rpm

Ugh, this package fails in %install:

  + install -m 0644 -p lib/linux/libKNIBase.a lib/linux/libKNI_InvKin.a 
   lib/linux/libKNI_LM.a
   /builddir/build/BUILDROOT/libkni-3.9.2-7.fc11.x86_64/usr/lib64
  + install -p 'lib/linux/*.so.*' 
   /builddir/build/BUILDROOT/libkni-3.9.2-7.fc11.x86_64/usr/lib64
  install: cannot stat `lib/linux/*.so.*': No such file or directory

I checked the buid directory and only see .a files in there.

Also, I still see several incidences of "[failed]" in the build log:

Compiling: cdlSocket.o
 [failed]
cdlSocket.cpp: In constructor 'CCdlSocket::CCdlSocket(char*, int)':
cdlSocket.cpp:99: error: 'runtime_exception' is not a member of 'std'
cdlSocket.cpp:110: error: 'runtime_exception' is not a member of 'std'
cdlSocket.cpp:116: error: 'runtime_exception' is not a member of 'std'

Compiling: kmlExt.o
 [failed]
kmlExt.cpp: In member function 'void CKatana::create(KNI::kmlFactory*, CCplBase*)':
kmlExt.cpp:149: error: 'runtime_exception' is not a member of 'std'

mock.Root.build: 
Building: ../../lib/linux/libKNIBase.a
 [failed]
a - cdlCOM.o
a - cplSerial.o
libKNIBase.a
ar: cdlSocket.o: No such file or directory

Building: ../../lib/linux/libKNIBase.so.3.9.0
 [failed]
g++: cdlSocket.o: No such file or directory
g++: kmlExt.o: No such file or directory

Building: ../../lib/linux/libKNI_InvKin.so.3.9.0
 [failed]
/usr/bin/ld: cannot find -lKNIBase
collect2: ld returned 1 exit status

And many others.

Sorry for the noise. Didn't look enough and strangely the package (local) building did not fail. My bad.

SRPM: http://fedorapeople.org/~timn/robotics/libkni-3.9.2-8.fc10.src.rpm
(Successful) Scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=973409

This package does build now, but I still see a few failures in the log.  These failures are also present in your scratch build; just search for "failed" at 
  https://koji.fedoraproject.org/koji/getfile?taskID=973415&name=build.log

Packaging wise, macro usage is consistent, the license tag is fixed and the URL looks good.

I still can't tell about the debuginfo package.  I guess it comes down to the question of which shared libraries are actually supposed to be in the package.  The -static package has three: libKNIBase.a, libKNI_InvKin.a, and libKNI_LM.a.  The base package has only libKNIBase.so.3.9.0.  What happens to the other two?  I don't think it's a coincidence that these two failures appear in the build log:

Building: ../../lib/linux/libKNI_InvKin.so.3.9.0
 [failed]
/usr/bin/ld: cannot find -lKNIBase

Building: ../../lib/linux/libKNI_LM.so.3.9.0
 [failed]
/usr/bin/ld: cannot find -lKNIBase

I'm back, thesis handed in and now there is more time again...

- I have checked the library problems and fixed them with another patch. I have used this version with our arm and software and it works just fine.
- I have renamed the package to libkni3. I have checked KNI4. But for older arms (the previous version, just out of production for a year) is not supported in version 4. Therefore version 3 will be necessary for some time to come (I'll contact Neuronics about this issue). I will file another review request for a libkni package, will track up2date upstream (i.e. v4.2 atm).

Thanks for your patience, Jason. With your help we should be through with this real soon now. Sorry for the previous half-assed work, was distracted...

New package is at http://fedorapeople.org/~timn/robotics/libkni3-3.9.2-9.fc10.src.rpm, spec at http://fedorapeople.org/~timn/robotics/libkni3.spec, successful scratch build is at http://koji.fedoraproject.org/koji/taskinfo?taskID=1406033

I have updated two patches for F-11 compatibility. New SRPM is at http://fedorapeople.org/~timn/robotics/libkni3-3.9.2-10.fc10.src.rpm, F-11 scratch build is at https://koji.fedoraproject.org/koji/taskinfo?taskID=1409942

This one seems to address the complaints I had previously.  rpmlint is down to come complaints about no-documentation and the two zero-length files.  The library situation seems sorted, and along with it the debuginfo package, and everything builds fine with current rawhide.

One question I have is what you plan to do with /etc/kni and /usr/include/kni.  Should they be renamed to follow the naming of this package and to avoid conflicts with the libkni package you intend to submit?  It's probably easier to sort that out now rather than later.

It is now perfectly safe to assume that %fedora >= 10, so the txlive-utils/tetex conditional can go away.  (Or if you intend to submit this for EPEL, you can use a conditional based on %rhel, but either way the %fedora comparison is useless.)

rpmlint:
- zero-length files are auto-generated and therefore not removed
- complaint about no-doc is for the -devel sub-package and therefore should be fine, right?

paths:
You are right, I should rename at least the config path, although it is probably unlikely that you want to use both versions at the same time.

However, how do I need to handle this with the .so files? The .so symlinks in the -devel package will conflict, even though the real libraries have proper version suffixes. Is that considered to be correct (package conflict) or do I need to rename the libraries as well (and then the include file path as well)?

%fedora guard:
I would like to keep those, as we have robots running versions as old as FC3 (and upgrading robots can be a real problem). Is that a "must remove" or "can remove"?

The rpmlint complaints are fine.

Honestly I don't know how to deal with the conflicting .so links.  Generally yoou just can't do what it seems you're trying to do (two different versions of the same library with separate -devel packages useful in parallel) without actually renaming one of the libraries.

Generally stuff in Fedora should be as clean as possible.  I won't block you from checking it in, but anyone is welcome to go through and remove crap like that from packages so you really shouldn't rely on it being there.

I have uploaded a new version of the package. The shared libraries are now renamed (adding a 3 as suffix). Therefore the problem with parallel installing libkni3 (and a later proposed libkni v4) is solved.

SRPM at http://fedorapeople.org/~timn/robotics/libkni3-3.9.2-11.fc11.src.rpm, spec at http://fedorapeople.org/~timn/robotics/libkni3,spec.

Can I consider this package as approved then?

OK, finally things have calmed down from the new semester and I have some time to look at this.

Note the spec URL above has a typo; s/,/./.

Everything does build and it all looks pretty good to me.  The only weird thing I see now is  that you have a package "libkni3-doc" that installs files in /usr/share/doc/libkni3-docs.  It seems that the name of the package and the name of the directory should match.

Otherwise I think everything is OK.  The above is minor, and while I think it would be good to fix it before the package is imported, I don't think there's any point in waiting for an updated package before I approve this.

APPROVED

Agreed, will change that. Thanks for the thorough review and patience!

New Package CVS Request
=======================
Package Name: libkni3
Short Description: C++ library for the Katana robot arm
Owners: timn
Branches: F-10 F-11 EL-5
InitialCC:

cvs done.

libkni3-3.9.2-12.el5 has been submitted as an update for Fedora EPEL 5.
http://admin.fedoraproject.org/updates/libkni3-3.9.2-12.el5

libkni3-3.9.2-12.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/libkni3-3.9.2-12.fc10

libkni3-3.9.2-12.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/libkni3-3.9.2-12.fc11

libkni3-3.9.2-12.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

libkni3-3.9.2-12.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

libkni3-3.9.2-12.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.