Bug 721112 (vmtk)

Cleaned up rpmlint errors. Now there are only warnings

http://ankursinha.fedorapeople.org/vmtk/vmtk-0.9.0-2.fc15.src.rpm

http://ankursinha.fedorapeople.org/vmtk/vmtk.spec

I'll take this one for you.

Some quick observations.

1. The %description is WAY TO LONG. 

2. I think the -devel package requires should include %{?_isa} since this isn't a noarch pacakge:

Requires:  %{name}%{?_isa} = %{version}-%{release}

3. Could use more comments especially in %prep. I assume you're mainly removing bundled libraries there.

Don't worry about posting a new release just yet until I can do a more in-depth spec review.

Thank you Richard! :)

I've made some progress trying to get it to build against the OpenNL package but I can't really test it because of:

rpmbuild -bc rpmbuild/vmtk/SPECS/vmtk.spec
error: Failed build dependencies:
        InsightToolkit-devel is needed by vmtk-0.9.0-2.fc14.x86_64
        vxl-devel is needed by vmtk-0.9.0-2.fc14.x86_64

Because of that I've added the review request of vxl and InsightToolkit as a blocker for this Review Request.

Back to this review :)

The only part of the project that appears to use OpenNL is the DifferentialGeometry sub-project. 

I've added a cmake option, USE_EXTERN_OPENNL to the main CMakeLists.txt and I'm working on getting the headers and linking working in the CMakeLists.txt for DifferentialGeometry.

Hi Richard,

(In reply to comment #4)
> I've made some progress trying to get it to build against the OpenNL package
> but I can't really test it because of:
> 
> rpmbuild -bc rpmbuild/vmtk/SPECS/vmtk.spec
> error: Failed build dependencies:
>         InsightToolkit-devel is needed by vmtk-0.9.0-2.fc14.x86_64
>         vxl-devel is needed by vmtk-0.9.0-2.fc14.x86_64
> 
> Because of that I've added the review request of vxl and InsightToolkit as a
> blocker for this Review Request.

I'm sorry, I forgot to mention that you need to build ITK and vxl for your fedora system before you can test it. I for example, have a local mock repo with these packages. 

[root@ankur ~]# ls /tmp/mock-repo/InsightToolkit-* /tmp/mock-repo/vxl-*
/tmp/mock-repo/InsightToolkit-3.20.0-5.fc16.i686.rpm            /tmp/mock-repo/vxl-1.14.0-1.fc16.i686.rpm
/tmp/mock-repo/InsightToolkit-3.20.0-5.fc16.src.rpm             /tmp/mock-repo/vxl-1.14.0-1.fc16.src.rpm
/tmp/mock-repo/InsightToolkit-debuginfo-3.20.0-5.fc16.i686.rpm  /tmp/mock-repo/vxl-debuginfo-1.14.0-1.fc16.i686.rpm
/tmp/mock-repo/InsightToolkit-devel-3.20.0-5.fc16.i686.rpm      /tmp/mock-repo/vxl-devel-1.14.0-1.fc16.i686.rpm
/tmp/mock-repo/InsightToolkit-doc-3.20.0-5.fc16.i686.rpm        /tmp/mock-repo/vxl-doc-1.14.0-1.fc16.i686.rpm
/tmp/mock-repo/InsightToolkit-examples-3.20.0-5.fc16.i686.rpm



> 
> Back to this review :)
> 
> The only part of the project that appears to use OpenNL is the
> DifferentialGeometry sub-project. 
> 
> I've added a cmake option, USE_EXTERN_OPENNL to the main CMakeLists.txt and I'm
> working on getting the headers and linking working in the CMakeLists.txt for
> DifferentialGeometry.


The package works with the fedora OpenNL which I packaged recently. You don't need to make any tweaks. The changes I've made in the prep and build sections are enough. 

At the moment, gdcm is broken in rawhide,(after the latest libpoppler soname bump) so I can't build it as well :/

Thanks,
Ankur

(In reply to comment #5)
> (In reply to comment #4)
> > I've made some progress trying to get it to build against the OpenNL package
> > but I can't really test it because of:
> > 
> > rpmbuild -bc rpmbuild/vmtk/SPECS/vmtk.spec
> > error: Failed build dependencies:
> >         InsightToolkit-devel is needed by vmtk-0.9.0-2.fc14.x86_64
> >         vxl-devel is needed by vmtk-0.9.0-2.fc14.x86_64
> > 
> > Because of that I've added the review request of vxl and InsightToolkit as a
> > blocker for this Review Request.
> 
> I'm sorry, I forgot to mention that you need to build ITK and vxl for your
> fedora system before you can test it. I for example, have a local mock repo
> with these packages. 

Yup, I run a local repo as well. I'll try that.


> > The only part of the project that appears to use OpenNL is the
> > DifferentialGeometry sub-project. 
> > 
> > I've added a cmake option, USE_EXTERN_OPENNL to the main CMakeLists.txt and I'm
> > working on getting the headers and linking working in the CMakeLists.txt for
> > DifferentialGeometry.
> 
> 
> The package works with the fedora OpenNL which I packaged recently. You don't
> need to make any tweaks. The changes I've made in the prep and build sections
> are enough. 

Well, I was trying for a few reasons. One, I'm trying to improve my cmake-fu :) Also, hacking the link.txt is not ideal. If I can come up with a good cmake patch then maybe upstream will accept it (which is the best case). 

Also, in retrospect, I'm wondering if we should have renamed the header file for OpenNL to be consistent with the library name, i.e.: nl.h -> opennl.h

What do you think?

Richard

Ok, after installing the other BuildRequires I got my cmake patch working!

Next issue: 
Are you on a 32bit or 64bit system? I noticed that "make install" doesn't put the libraries in /usr/lib64 on x86_64 systems. I added a %ifarch conditional to move /usr/lib to /usr/lib64 on x86_64 and ppc64 systems.

Second issue:
I noticed it put all the python files in /usr/lib/vmtk/vmtk. I think all of these should go into %{python_sitelib}/vmtk, right?

Richard

Update:

I need your help to figure out what exactly is supposed to go into the -devel package. 

I saw you had the python scripts going in there. Are they the "source" files for the python libraries or are they separate from them?

I find the whole /usr/lib/vmtk/vmtk structure that make install produces confusing...

> 
> Well, I was trying for a few reasons. One, I'm trying to improve my cmake-fu :)
> Also, hacking the link.txt is not ideal. If I can come up with a good cmake
> patch then maybe upstream will accept it (which is the best case). 
> 
> Also, in retrospect, I'm wondering if we should have renamed the header file
> for OpenNL to be consistent with the library name, i.e.: nl.h -> opennl.h
> 
> What do you think?
> 

Hrm, we certainly could do that. Although, we'd have to first look at it's effects. I'll look into it.

(In reply to comment #7)
> Ok, after installing the other BuildRequires I got my cmake patch working!
> 
> Next issue: 
> Are you on a 32bit or 64bit system? I noticed that "make install" doesn't put
> the libraries in /usr/lib64 on x86_64 systems. I added a %ifarch conditional to
> move /usr/lib to /usr/lib64 on x86_64 and ppc64 systems.

I run mock builds for a 32 bit system. I haven't tried on an x86_64 yet. 

I just looked at CMakeLists.txt. I think setting "VMTK_MODULE_INSTALL_LIB_DIR" would fix this. -DVMTK_MODULE_INSTALL_LIB_DIR:STRING=$RPM_BUILD_ROOT/%{_libdir}/ or something on these lines. Again, I'll try it out and confirm.

> 
> Second issue:
> I noticed it put all the python files in /usr/lib/vmtk/vmtk. I think all of
> these should go into %{python_sitelib}/vmtk, right?

Yes. Should. Again, setting VMTK_MODULE_INSTALL_LIB_DIR just might do the trick.

I'll try all of this out and post :)

Thanks,
Ankur

(In reply to comment #8)
> Update:
> 
> I need your help to figure out what exactly is supposed to go into the -devel
> package. 
> 
> I saw you had the python scripts going in there. Are they the "source" files
> for the python libraries or are they separate from them?
> 
> I find the whole /usr/lib/vmtk/vmtk structure that make install produces
> confusing...

I'll try getting in touch with upstream for suggestions.

I'm going to be unavailable until Monday. I'll only respond after that. I regret the inconvenience this will cause :/

Thanks,
Ankur

(In reply to comment #10)
> (In reply to comment #7)
> > Ok, after installing the other BuildRequires I got my cmake patch working!
> > 
> > Next issue: 
> > Are you on a 32bit or 64bit system? I noticed that "make install" doesn't put
> > the libraries in /usr/lib64 on x86_64 systems. I added a %ifarch conditional to
> > move /usr/lib to /usr/lib64 on x86_64 and ppc64 systems.
> 
> I run mock builds for a 32 bit system. I haven't tried on an x86_64 yet. 

Ok, my updated spec/SRPM file[1] fixes that.


> I just looked at CMakeLists.txt. I think setting "VMTK_MODULE_INSTALL_LIB_DIR"
> would fix this.
> -DVMTK_MODULE_INSTALL_LIB_DIR:STRING=$RPM_BUILD_ROOT/%{_libdir}/ or something
> on these lines. Again, I'll try it out and confirm.

Didn't work for me. It appears to just control the /usr or /usr/local part of the path, I set it to /lib64 (since it adds /usr seperately) and it ended up putting the files in /usr/lib64/lib/vmtk/vmtk... 



> > Second issue:
> > I noticed it put all the python files in /usr/lib/vmtk/vmtk. I think all of
> > these should go into %{python_sitelib}/vmtk, right?
> 
> Yes. Should. Again, setting VMTK_MODULE_INSTALL_LIB_DIR just might do the
> trick.

Probably will not work but worth a try... The problem is all the .py files need to go in %{python_sitelib} which is /usr/lib/pythonX.X/site-packages/ while the .so python libraries need to go in %{python_sitearch} which can be the same as %{python_sitelib} for 32bit systems but is /usr/lib64... for 64 bit systems. This is easier just to manage manually.

The only side effect I've found so far is that one (and only one) of the python .so libraries actually has a SONAME and the .so symlink is getting pulled into the regular package instead of the -devel package. Should be easy to fix though, there are other bigger problems...

One of the "big" problems is actually with vtk, not vmtk. It provides a necessary library, libVPIC.so, but only in the -devel package, not in the main package. Because of that I had to add a Requires for vtk-devel which pulls in a bunch of dependencies we don't need just to get the one file we do need. I added a BZ reference in the comment so we can watch to see when it get's fixed.

The other problem seems to be that some of the libraries from vmtk can't find other libraries it provides. In other words, it's finding libraries in /usr/lib{,64} but not the ones in /usr/lib{,64}/vmtk... Not sure why that is happening.

That's enough for now I think!

[1] http://hobbes1069.fedorapeople.org/vmtk/vmtk-0.9.0-2.fc14.src.rpm

Ankur,

I found out that I was wrong about the whole python_sitelib/sitearch thing. If there are ANY C python modules in the package then everything, including the pure python modules go in sitearch.

Richard

hi Richard, 

I'm waiting on vxl to be packaged. Mario's working on it. I can't get vmtk to build in mock at the moment. Some issue with the vxl package. 

Thanks,
Ankur

Ping? Any progress here? Or we can close this review?

Hi,

VXL has *just* been included in the repositories. I'm away and will not be able to work on this review for another month. Please feel free to start a new review if you need to.

Thanks,
Warm regards,
Ankur

Hrm, cannot still build it. Depends on ITK. Also found more bundled software *sigh* in the 1.0.1 release:

Doxygen  OpenNL  Stellar_1.0  tetgen1.4.3. I also see that tetgen is NOT free software, as noted in the review ticket:

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

I'm afraid this might mean we need to drop this package altogether. I'll see if I can speak to upstream about this.

I'll at least package stellar in the mean time: http://www.cs.berkeley.edu/~jrs/stellar/

Thanks,
Warm regards,
Ankur

Thanks Ankur for your efforts in packaging vmtk. You might be able to use vmtk with netgen, which is free:
http://www.vmtk.org/Tutorials/NetgenWay/

We hope to finish ITK anytime soon -if more bundled software doesn't show up, of course ;)

Best,
Mario

tetgen is free software now and I've just approved Sandro's package, so it can be unbundled from vmtk.

I'm going to close this as WONTFIX. I'm not working on medical applications anymore so I'm not the best person to maintain this package now.