Bug 567086 - (vxl) Review Request: VXL - C++ Libraries for Computer Vision Research and Implementation
Review Request: VXL - C++ Libraries for Computer Vision Research and Implemen...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Lemenkov
Fedora Extras Quality Assurance
:
Depends On: 570258 dcmtk 713677 868325
Blocks: fedora-medical vmtk InsightToolkit GoFigure2 Ginkgo-CADx 1001247
  Show dependency treegraph
 
Reported: 2010-02-21 10:45 EST by Mario Ceresa
Modified: 2013-12-16 09:16 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-03 23:56:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
lemenkov: fedora‑review+
limburgher: fedora‑cvs+


Attachments (Terms of Use)
Specfile with description blocks moved (4.33 KB, text/plain)
2010-04-09 07:07 EDT, Thomas Bouffon
no flags Details
More complete build (96 bytes, text/plain)
2010-04-25 12:32 EDT, Thomas Bouffon
no flags Details
New release of src rpm with lib6464 fixed + changelog + .so files in devel package (47 bytes, text/plain)
2010-04-26 06:27 EDT, Thomas Bouffon
no flags Details
Directory with src, i586, x86_64 rpms (28 bytes, text/plain)
2010-04-26 17:28 EDT, Thomas Bouffon
no flags Details
Fix soname problem (491 bytes, text/plain)
2010-09-19 07:06 EDT, Mario Ceresa
no flags Details

  None (edit)
Description Mario Ceresa 2010-02-21 10:45:50 EST
Spec URL: http://mrceresa.fedorapeople.org/vxl.spec
SRPM URL: http://mrceresa.fedorapeople.org/vxl-1.13.0-1.fc12.src.rpm
Description:

VXL (the Vision-something-Libraries) is a collection of C++ libraries designed
for computer vision research and implementation. It was created from TargetJr
and the IUE with the aim of making a light, fast and consistent system. 
VXL is written in ANSI/ISO C++ and is designed to be portable over many
platforms.

Questions:

1 - v3p/netlib dependency not removed because of heavily modifications seems to be heavily modified from the original sources. The changes are documented in v3p/netlib/README

2 - v3p/dcmtk exists an rpm package at http://dicom.offis.de/dcmtk.php.en but there is none in yum and neither there is a review request. Should we try to package it as well? 

3 - v3p/mpeg2 is different from Fedora's one: it misses at least:

mpeg2dec/video_out.h
mpeg2dec/mm_accel.h

Moreover the FindMPEG2.cmake file shipped with cmake 2.6.4 search lib livid and libvo, but none of them are available from yum.
Comment 1 Mario Ceresa 2010-03-02 14:54:31 EST
Spec URL: http://mrceresa.fedorapeople.org/vxl.spec
SRPM URL: http://mrceresa.fedorapeople.org/vxl-1.13.0-2.fc12.src.rpm

This version fixes previous problems with library generations
Comment 2 Chen Lei 2010-03-07 07:04:26 EST
The spec file seems strange, please add subpackage info after %description. Alos all of bundled libs must be packaged separately unless the bundled libs are heavily changed and incompatible with system-libs. Maybe I can help you to split some of those libs.

%description
VXL (the Vision-something-Libraries) is a collection of C++ libraries designed
for computer vision research and implementation. It was created from TargetJr
and the IUE with the aim of making a light, fast and consistent system. 
VXL is written in ANSI/ISO C++ and is designed to be portable over many
platforms.

%package	devel
Summary:	Headers for VXL library
Group:		Development/Libraries
Requires:	%{name} = %{version}-%{release}

%description devel

You should install this package if you would like to
develop code based on VXL.

%package	doc
Summary:	Documentation for VXL library
Group:		Development/Libraries
Requires:	%{name} = %{version}-%{release}

%description doc

You should install this package if you would like to
have all the documentation
Comment 3 Mario Ceresa 2010-03-08 09:43:36 EST
Hello Chen Lei!
thanks for your comments:

1) What do you mean "add subpackage info after %description"? Would you mind writing a small example?

(ie: 

%package devel
Summary: Headers for VXL library
Group:  Development/Libraries
Requires: %{name} = %{version}-%{release}

%description devel
You should install this package if you would like to
develop code based on VXL.

-> Here I think you should add some more text to clarify <-

)

2) As for the bundled libs:

- I've already removed jpeg png zlib tiff geotiff mpeg2
- v3p/netlib dependency not removed because of heavily modifications
- v3p/dcmtk: it exists an rpm package at http://dicom.offis.de/dcmtk.php.en but there is none in yum and neither there is a review request. Should we try to add it as well?

- All of the following libraries are being switched off:
-DBUILD_OXL:BOOL=OFF \
	-DBUILD_CORE_GEOMETRY:BOOL=OFF \
	-DBUILD_CORE_IMAGING:BOOL=OFF \
	-DBUILD_CORE_NUMERICS:BOOL=ON \
	-DBUILD_CORE_PROBABILITY:BOOL=OFF \
	-DBUILD_CORE_SERIALISATION:BOOL=OFF \
	-DBUILD_CORE_UTILITIES:BOOL=OFF \
	-DBUILD_CORE_VIDEO:BOOL=OFF \

because the main intent for this package was to allow InsightToolkit (which is blocked by this package review), my idea to speed up the approval was to disable these functionalities as they are not used in Insight Toolkit and require a significant effort to be decoupled and packaged as well.

If you can help in packaging and enabling these libraries, I would be more than grateful! One of those which has already been approved is:

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

Thanks and regards,

Mario
Comment 4 Chen Lei 2010-03-10 07:56:00 EST
(In reply to comment #3)
> Hello Chen Lei!
> thanks for your comments:
> 1) What do you mean "add subpackage info after %description"? Would you mind
> writing a small example?
> (ie: 
> %package devel
> Summary: Headers for VXL library
> Group:  Development/Libraries
> Requires: %{name} = %{version}-%{release}
> %description devel
> You should install this package if you would like to
> develop code based on VXL.
> -> Here I think you should add some more text to clarify <-
> )

It's not error, just a spec file standard. You see almost all spec files add subpackage info after %description, follow standard will increase the readability of spec file.

See
http://cvs.fedoraproject.org/viewvc/rpms/glibc/devel/glibc.spec?revision=1.430&view=markup


> 2) As for the bundled libs:
> - I've already removed jpeg png zlib tiff geotiff mpeg2
> - v3p/netlib dependency not removed because of heavily modifications
> - v3p/dcmtk: it exists an rpm package at http://dicom.offis.de/dcmtk.php.en but
> there is none in yum and neither there is a review request. Should we try to
> add it as well?
> - All of the following libraries are being switched off:
> -DBUILD_OXL:BOOL=OFF \
>  -DBUILD_CORE_GEOMETRY:BOOL=OFF \
>  -DBUILD_CORE_IMAGING:BOOL=OFF \
>  -DBUILD_CORE_NUMERICS:BOOL=ON \
>  -DBUILD_CORE_PROBABILITY:BOOL=OFF \
>  -DBUILD_CORE_SERIALISATION:BOOL=OFF \
>  -DBUILD_CORE_UTILITIES:BOOL=OFF \
>  -DBUILD_CORE_VIDEO:BOOL=OFF \
> because the main intent for this package was to allow InsightToolkit (which is
> blocked by this package review), my idea to speed up the approval was to
> disable these functionalities as they are not used in Insight Toolkit and
> require a significant effort to be decoupled and packaged as well.
> If you can help in packaging and enabling these libraries, I would be more than
We should packaging those libs, I can also help you to package some of them. Howerver, if I try to package those libs, I'll need some others to review my packages.
Comment 5 Mario Ceresa 2010-03-10 08:42:10 EST
Hello Chen Lei!

thanks for your quick response.

I'm sorry to say that I still don't catch what you want me to change in the spec file. 

Please be patient: English is not my mother tongue so there might be some subtleties that confounds me. Let's make an example:

#Example starts here#
[from vxl.spec]
%package	devel
Summary:	Headers for VXL library
Group:		Development/Libraries
Requires:	%{name} = %{version}-%{release}
%description devel
You should install this package if you would like to
develop code based on VXL.
[end vxl.spec]

[from glibc.spec]
%package xen
Summary: The GNU libc libraries (optimized for running under Xen)
Group: System Environment/Libraries
Requires: glibc = %{version}-%{release}, glibc-utils = %{version}-%{release}
%description xen
The standard glibc package is optimized for native kernels and does not
perform as well under the Xen hypervisor. This package provides alternative
library binaries that will be selected instead when running under Xen.
Install glibc-xen if you might run your system under the Xen hypervisor. 
[end glibc.spec]
#End of example#

As devel is a subpackage of vxl I added %description devel to create vxl-devel package. Then I added some descriptive info.

I would appreciate very much if you could rewrite the part of my example between [from vxl.spec] - [end vxl.spec] to show me the change you have in mind, so I can see what I'm missing. Sorry if it seems a stupid question.

On the other hand, on the library side, I'll be very happy to review any vxl related lib that you might try to package, and help with adding them to vxl.

The only think that I'd like to ask is that, if the time required to package them all would be considerable, we go on with the review for this subset only of vxl and file later bugs requiring more functionalities. 

I don't know if this could be a viable solution but it seems to me an acceptable compromise between blocking indefinitely the InsightToolkit review and packaging many scientific libs. I would love to hear what you think about this point.

Thanks for your time and best regards

Mario
Comment 6 Mario Ceresa 2010-03-21 19:09:22 EDT
Hello Peter,
this version builds against rply.

http://mrceresa.fedorapeople.org/vxl-1.13.0-3.fc12.src.rpm
http://mrceresa.fedorapeople.org/vxl.spec


Mario
Comment 7 Mario Ceresa 2010-03-23 07:49:14 EDT
Hello Peter,
this version fixes some other soname problems and a lib vs lib64 problem in cmake install files.

http://mrceresa.fedorapeople.org/vxl-1.13.0-4.fc12.src.rpm
http://mrceresa.fedorapeople.org/vxl.spec

Mario
Comment 8 Thomas Bouffon 2010-04-09 07:04:47 EDT
Hi,
I'm not an expert but I think what Chen Lei means is that the position of the subpackage info is wrong : The information about the package and its subpackages come alltogether. I've attached the specfile with the description blocks moved.

Thomas
Comment 9 Thomas Bouffon 2010-04-09 07:07:24 EDT
Created attachment 405520 [details]
Specfile with description blocks moved
Comment 10 Thomas Bouffon 2010-04-25 12:32:23 EDT
Created attachment 408977 [details]
More complete build

Hi,
I packaged vxl with the following options :
%cmake -DCMAKE_VERBOSE_MAKEFILE=ON \
        -DBUILD_SHARED_LIBS:BOOL=ON \
        -DBUILD_TESTING:BOOL=OFF \
        -DVXL_FORCE_B3P_EXPAT:BOOL=OFF \
        -DVXL_FORCE_V3P_DCMTK:BOOL=OFF \
        -DVXL_FORCE_V3P_GEOTIFF:BOOL=OFF \
        -DVXL_FORCE_V3P_JPEG:BOOL=OFF \
        -DVXL_FORCE_V3P_MPEG2:BOOL=OFF \
        -DVXL_FORCE_V3P_PNG:BOOL=OFF \
        -DVXL_FORCE_V3P_TIFF:BOOL=OFF \
        -DVXL_FORCE_V3P_ZLIB:BOOL=OFF \
        -DVXL_FORCE_V3P_RPLY:BOOL=OFF \
        -DBUILD_OXL:BOOL=ON \
        -DBUILD_CORE_ALL:BOOL=ON \
        -DBUILD_CONTRIB:BOOL=ON \
        -DBUILD_EXAMPLES:BOOL=OFF \
        -DBUILD_TESTING:BOOL=OFF \
        -DBUILD_DOCUMENTATION:BOOL=ON \
        -DCMAKE_BUILD_TYPE:STRING="Release"
All the core libs + the contribs are built
It hasn't any dependency which is not provided by the default repos.

Cheers,
Thomas
Comment 11 Mario Ceresa 2010-04-26 03:24:36 EDT
Thanks Thomas for all your hard work on this package! 

I'll try to post a new rpmsrc based on your attachment by tomorrow.

Cheers,

Mario
Comment 12 Thomas Bouffon 2010-04-26 04:51:43 EDT
Hi,
Some further explanation : 
I added 2 patches : 
  - vxl_ply which corrects a compilation problem because the ply functions have less arguments than before.
  - install_vpgl to install the corresponding library because some contrib library was relying on it. 

I moved some stuff in the specfile. I thought the .so were supposed to go in the default package, but I now know I'm wrong. Btw if you why, I'd like to know...

The x64 version does not build yet, rpmbuild returns :
error: Installed (but unpackaged) file(s) found:
   /usr/lib6464/libvpgl.so
line 6 of my install_vpgl patch should be 
+INSTALL_TARGETS(/lib vpgl)

I'm building agian to correct these problems.

cheers, 

Thomas
Comment 13 Thomas Bouffon 2010-04-26 06:27:46 EDT
Created attachment 409140 [details]
New release of src rpm with lib6464 fixed + changelog + .so files in devel package

Hi again, 
I re-built the package with the little problems fixed. It now also builds on x86_64 on opensuse buildservice. I don't have any account on koji.
The release in the spec file has been changed by opensuse buildservice : it should be 5, it 18, and the dist tag has been replaced by 1

Btw I don't know if everything in the package (especially the contrib stuff) is under the same license ?

Cheers, Thomas
Comment 14 Thomas Bouffon 2010-04-26 17:28:43 EDT
Created attachment 409296 [details]
Directory with src, i586, x86_64 rpms

Hi, 
I built the rpms on koji with the right release numbers. They're being uploaded to my ftp.

The rpm fails to build on ppc, I don't know why at the moment.
Nevertheless, on i586, I can build and run opengazer successfuly (which depends on vxl)

Cheers,

Thomas
Comment 15 Mario Ceresa 2010-06-28 05:01:39 EDT
Hello Thomas,
I'm very sorry for such a delayed response! thanks for all your work in the meantime.

I hope to post your work very soon so we can go on with the packaging!

Cheers,

Mario
Comment 16 Mario Ceresa 2010-09-19 07:06:55 EDT
Created attachment 448282 [details]
Fix soname problem

Hello Thomas, hello Peter,
I noticed that the new spec generates a lot of new libraries with improper soname. Instead of fixing them manually (they are 78!!) I tried a little bit of bash magic, which I include in the attached script.

The idea is that it generate a fixing bash command for each wrong lib detected, something like:

echo SET_TARGET_PROPERTIES(vcsl PROPERTIES ${VXL_LIBRARY_PROPERTIES}) >> vxl-1.13.0/core/vcsl/CMakeLists.txt

Actually I found my magic to be a bit rusty, so sometimes it outputs a wrong version:

echo SET_TARGET_PROPERTIES(${vgl_sources}) PROPERTIES ${VXL_LIBRARY_PROPERTIES}) >> vxl-1.13.0/core/vgl/CMakeLists.txt

where the target is "${vgl_sources}" instead of "vgl".
It happens because the awk regex in 

awk '/ADD_LIBRARY\([^$]+/ {print $2}'

matchs correctly ADD_LIBRARY( vgl ${vgl_sources}) but not ADD_LIBRARY(vgl ${vgl_sources}) (notice the extra space after "add_library(" )

If you have any idea on how to go on from this, we might finish the package soon!

Thanks and regards

Mario
Comment 17 Peter Lemenkov 2011-04-22 00:07:11 EDT
All build-dependencies are in Rawhide now, so it's time to review this.
Comment 18 Mario Ceresa 2011-05-28 17:11:24 EDT
Hello Peter, hello Thomas

Here we are:

http://mrceresa.fedorapeople.org/vxl-1.14.0-1.fc15.src.rpm
http://mrceresa.fedorapeople.org/vxl.spec

* Fri May 27 2011 Mario Ceresa mrceresa fedoraproject org vxl 1.14.0-1%{?dist}
- Updated to new version
- Added BR doxygen (thanks to Ankur for noticing it)
- Changed patch naming schema
- Work around a rply related bug (patches 3-6)
- Thanks to Thomas Bouffon for patch 7-8
- Patches 9-10 address http://www.itk.org/pipermail/insight-users/2010-July/037418.html

Building in koji right now:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3098552

Best,

Mario
Comment 19 Mario Ceresa 2011-05-29 05:51:37 EDT
Hi again, fixed around 70 missing sonames, re-enabled parallel build and added some missing dirs:

http://mrceresa.fedorapeople.org/vxl-1.14.0-1.fc15.src.rpm
http://mrceresa.fedorapeople.org/vxl.spec

Here it is the koji link:

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

If it succeed, I think the package is ready for the review (all major blocker should be fixed)

Best,

Mario
Comment 20 Peter Lemenkov 2011-05-29 10:37:53 EDT
Great work!
Unfortunately there are still some remaining issues.

+/- rpmlint is NOT silent:

sulaco ~/Desktop: rpmlint vxl-*
vxl.src:108: W: macro-in-comment %{_docdir}
vxl.src:108: W: macro-in-comment %{name}
vxl.src:109: W: macro-in-comment %{_docdir}
vxl.src:109: W: macro-in-comment %{name}

^^^ these should be ignored (harmless)

vxl.x86_64: W: shared-lib-calls-exit /usr/lib64/libbrct.so.1.14.0 exit@GLIBC_2.2.5
vxl.x86_64: W: shared-lib-calls-exit /usr/lib64/libvil.so.1.14.0 exit@GLIBC_2.2.5
vxl.x86_64: W: shared-lib-calls-exit /usr/lib64/libnetlib.so.1.14.0 exit@GLIBC_2.2.5
vxl.x86_64: W: shared-lib-calls-exit /usr/lib64/libv3p_netlib.so.1.14.0 exit@GLIBC_2.2.5
vxl.x86_64: W: shared-lib-calls-exit /usr/lib64/libvil1.so.1.14.0 exit@GLIBC_2.2.5
vxl.x86_64: W: shared-lib-calls-exit /usr/lib64/libvul.so.1.14.0 exit@GLIBC_2.2.5
vxl.x86_64: W: shared-lib-calls-exit /usr/lib64/libvgl_algo.so.1.14.0 exit@GLIBC_2.2.5
vxl.x86_64: W: shared-lib-calls-exit /usr/lib64/libmvl.so.1.14.0 exit@GLIBC_2.2.5

^^^ these ones indicates a flaw in the library's API design (the library shouldn't call exit but rather return error code to the main application allowing it to clean up stuff). This is not a blocker (you can't do much here) but I advise you to notice upstream about this.

vxl.x86_64: W: no-manual-page-for-binary octree

^^^ as said - no man-page for the particular binary. Let's hope that someone will write this man-page sometime.

vxl-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/vxl-1.14.0/contrib/brl/bbas/bsta/Templates/bsta_von_mises+double.3-.cxx
vxl-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/vxl-1.14.0/core/vgl/algo/Templates/vgl_orient_box_3d_operators+double-.cxx
vxl-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/vxl-1.14.0/core/vgl/Templates/vgl_infinite_line_3d+double-.cxx
vxl-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/vxl-1.14.0/contrib/brl/bbas/bsta/bsta_von_mises.h
vxl-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/vxl-1.14.0/core/vnl/io/Templates/vnl_io_vector_fixed+float.2-.cxx
vxl-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/vxl-1.14.0/contrib/gel/mrc/vpgl/bgeo/bgeo_sun_pos.cxx
vxl-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/vxl-1.14.0/core/vgl/Templates/vgl_infinite_line_3d+float-.cxx
vxl-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/vxl-1.14.0/contrib/brl/bbas/bsta/Templates/bsta_gaussian_sphere+double.2-.cxx
vxl-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/vxl-1.14.0/core/vil/Templates/vil_image_view+vil_rgb+bool--.cxx
vxl-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/vxl-1.14.0/core/vgl/algo/Templates/vgl_orient_box_3d_operators+float-.cxx
vxl-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/vxl-1.14.0/core/vil/Templates/vil_image_view+vil_rgba+bool--.cxx
vxl-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/vxl-1.14.0/core/vil/Templates/vil_rgb+bool-.cxx
vxl-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/vxl-1.14.0/contrib/brl/bbas/bsta/Templates/bsta_von_mises+float.3-.cxx
vxl-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/vxl-1.14.0/contrib/brl/bbas/bsta/Templates/bsta_von_mises+double.2-.cxx
vxl-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/vxl-1.14.0/core/vgl/Templates/vgl_infinite_line_3d+int-.cxx
vxl-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/vxl-1.14.0/contrib/brl/bbas/bsta/Templates/bsta_von_mises+float.2-.cxx
vxl-debuginfo.x86_64: E: script-without-shebang /usr/src/debug/vxl-1.14.0/contrib/brl/bbas/bsta/bsta_von_mises.txx
vxl-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/vxl-1.14.0/core/vgl/vgl_infinite_line_3d.h
vxl-debuginfo.x86_64: E: script-without-shebang /usr/src/debug/vxl-1.14.0/core/vgl/vgl_infinite_line_3d.txx

^^^ Please fix permissions on source files during %prep stage to suppress these messages.

vxl-devel.x86_64: E: invalid-soname /usr/lib64/libexpat.so libexpat.so

^^^ that sounds like an issue - still no soname for this and several other libraries. They are *not* a symlinks to the corresponding libraries with a suffix. Namely:

- libexpat.so
- libmvl2.so
- libvepl2.so

And there is another one possible issue - some libraries have too generic names (libexpat.so.* and many others) and might interfere with other ones. Could you, please, put them under dedicated directory? Under something like %{_libdir}/%{name} (with corresponding /etc/ld.so.conf.d/*.conf file). I'm open for suggestions here.

vxl-devel.x86_64: W: no-documentation

^^^ may be omitted - we have a separate package for docs.

5 packages and 0 specfiles checked; 3 errors, 31 warnings.
sulaco ~/Desktop: 

- Bundled library - v3p/dcmtk.
- Bundled library - v3p/netlib. This looks pretty hard to fix because netlib isn't available in Fedora as a whole. instead there are some parts of it packaged separately. Namely - blas, lapack, f2c and maybe some others. Also it looks like a licensing nightmare.
- Bundled libraries - contrib/brl/b3p/{expat,expatpp,minizip,shapelib}

- You didn't enable building of v3p/Qv module - is it intentional? I can't find any licensing details about it. 

- What's the purpose of vcl directory?
Comment 21 Mario Ceresa 2011-05-29 17:02:22 EDT
Just a note for me to remember where new rpms are:

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

This should fix the permission problems, some more sonames and the dcmtk, minizip and shapelib issues.

I'll continue to work on the problem with the installation
Comment 22 Mario Ceresa 2011-05-31 07:55:00 EDT
Hey Peter, I think we are getting closer:

http://koji.fedoraproject.org/koji/taskinfo?taskID=3101700
http://mrceresa.fedorapeople.org/vxl-1.14.0-1.fc15.src.rpm
http://mrceresa.fedorapeople.org/vxl.spec

This solves the missing dependency: a vxl library had no install target in cmake. Still with netlib but without dcmtk, expat, expatpp, minizip and shapelib.

ITK also builds correctly with this version!

However, rpmlint is *not* silent:

[mario@shadow vxl]$ ls *.rpm
vxl-1.14.0-1.fc15.x86_64.rpm            vxl-devel-1.14.0-1.fc15.x86_64.rpm
vxl-debuginfo-1.14.0-1.fc15.x86_64.rpm  vxl-doc-1.14.0-1.fc15.x86_64.rpm

[mario@shadow vxl]$ rpmlint *.rpm
vxl.x86_64: W: shared-lib-calls-exit /usr/lib64/libbrct.so.1.14.0 exit@GLIBC_2.2.5
vxl.x86_64: W: shared-lib-calls-exit /usr/lib64/libvil.so.1.14.0 exit@GLIBC_2.2.5
vxl.x86_64: W: shared-lib-calls-exit /usr/lib64/libnetlib.so.1.14.0 exit@GLIBC_2.2.5
vxl.x86_64: W: shared-lib-calls-exit /usr/lib64/libv3p_netlib.so.1.14.0 exit@GLIBC_2.2.5
vxl.x86_64: W: shared-lib-calls-exit /usr/lib64/libvil1.so.1.14.0 exit@GLIBC_2.2.5
vxl.x86_64: W: shared-lib-calls-exit /usr/lib64/libvul.so.1.14.0 exit@GLIBC_2.2.5
vxl.x86_64: W: shared-lib-calls-exit /usr/lib64/libvgl_algo.so.1.14.0 exit@GLIBC_2.2.5
vxl.x86_64: W: shared-lib-calls-exit /usr/lib64/libmvl.so.1.14.0 exit@GLIBC_2.2.5
vxl.x86_64: W: no-manual-page-for-binary octree
vxl-devel.x86_64: W: no-documentation
4 packages and 0 specfiles checked; 0 errors, 10 warnings.

Let me know what do you think of it!

Do you still want me to put all libraries in a separate dir, now that expat is out?

Mario
Comment 23 Elad Alfassa 2011-06-05 01:14:17 EDT
moving to Package Review (was 0xFFFF)



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 24 Ankur Sinha (FranciscoD) 2011-06-16 04:19:19 EDT
Hello,

An informal review :D

+ OK
- NA
? ISSUE

+ Package meets naming and packaging guidelines
+ Spec file matches base package name.
+ Spec has consistant macro usage.
? Meets Packaging Guidelines.

There's the issue of bundled libraries. Most of them have been removed. On the ones that are still present:

netlib: is heavily modified and therefore should not be removed
QV: Some parts of this appear to have been used in the package. The qv library is now obsolete and it's routines have probably been made a part of Inventor. (We've asked the Inventor maintainer to please look into it)

Since QV is obsolete, it's unlikely that there will be a duplication of the library (It's been dead for a while now).  IMO, it's okay to let these files be in the package.

There are some more bundles:
./contrib/conversions/
^^^
I haven't been found anything online regarding the source either. The README says that it's only a couple of routines, and not the entire library. Think this one can be counted as an internal library too. 

./contrib/gel/vgel/kl/
^^^
I did find the source of KLT here, and therefore I think we need to unbundle it:
http://www.ces.clemson.edu/~stb/klt/

I've submitted a review request here:
https://bugzilla.redhat.com/show_bug.cgi?id=713677

It's a simple package, shouldn't take more than 20 mins to review> I'm hoping that will serve the purpose. If it does not, keeping the bundle is the only way to go. 

./contrib/oul/oufgl/
^^^
The only results that I get on googling these two appear to be from the VXL source tree. It mentions "Otago University Frame Grabber Library" but I cannot find the source anywhere online. I did one of the developers' homepage here:
http://www.cs.otago.ac.nz/staffpriv/mccane/software.html

As you'll see, he is the developer of vxl as well. I don't think oufgl is intended for any other use and is therefore an "internal library" here. If in future, there is a source release of the library, we can package it separately and unbundle it from vxl.

Please feel free to add any more info on these bundles if you come across any. 

+ License
+ License field in spec matches
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You might want to check on this. Grepping the directory for LGPL does give some output. :
[ankur@ankur vxl-1.14.0]$ egrep -nri "LGPL" *
Binary file contrib/gel/vifa/tests/cam0013.tif matches
contrib/brl/bbas/bil/algo/bil_edt.h:37://  Implementation influenced by the LTI lib, which is licensed under LGPL:
contrib/brl/b3p/shapelib/shpopen.c:11: * or at the option of the licensee under the LGPL (see LICENSE.LGPL).  This
contrib/brl/b3p/shapelib/shptree.c:11: * or at the option of the licensee under the LGPL (see LICENSE.LGPL).  This
contrib/brl/b3p/shapelib/dbfopen.c:11: * or at the option of the licensee under the LGPL (see LICENSE.LGPL).  This
contrib/brl/b3p/shapelib/shapefil.h:13: * or at the option of the licensee under the LGPL (see LICENSE.LGPL).  This

Please do double check this. 


+ License file included in package
+ Spec in American English
+ Spec is legible.
- Sources match upstream md5sum:

- Package needs ExcludeArch
+ BuildRequires correct
- Spec handles locales/find_lang
- Package is relocatable and has a reason to be.
+ Package has %defattr and permissions on files is good.
? Package has a correct %clean section.
Not required any more. You can get rid of it.

? Package has correct buildroot
%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Not required any more. You can get rid of it.

+ Package is code or permissible content.
+ Doc subpackage needed/used.
+ Packages %doc files don't affect runtime.

+ Headers/static libs in -devel subpackage.
+ Spec has needed ldconfig in post and postun
- .pc files in -devel subpackage/requires pkgconfig
+ .so files in -devel subpackage.
+ -devel package Requires: %{name} = %{version}-%{release}
- .la files are removed.

- Package is a GUI app and has a .desktop file

+ Package compiles and builds on at least one arch.
+ Package has no duplicate files in %files.
+ Package doesn't own any directories other packages own.
+ Package owns all the directories it creates.

? No rpmlint output.
^^^^^^^^^^^^^^
[ankur@ankur SRPMS]$ rpmlint /var/lib/mock/fedora-rawhide-i386/result/*.rpm ../SPECS/vxl.spec vxl-1.14.0-1.fc15.src.rpm 
vxl.i686: W: shared-lib-calls-exit /usr/lib/libv3p_netlib.so.1.14.0 exit@GLIBC_2.0
vxl.i686: W: shared-lib-calls-exit /usr/lib/libvil.so.1.14.0 exit@GLIBC_2.0
vxl.i686: W: shared-lib-calls-exit /usr/lib/libvil1.so.1.14.0 exit@GLIBC_2.0
vxl.i686: W: shared-lib-calls-exit /usr/lib/libnetlib.so.1.14.0 exit@GLIBC_2.0
vxl.i686: W: shared-lib-calls-exit /usr/lib/libmvl.so.1.14.0 exit@GLIBC_2.0
vxl.i686: W: shared-lib-calls-exit /usr/lib/libvul.so.1.14.0 exit@GLIBC_2.0
vxl.i686: W: shared-lib-calls-exit /usr/lib/libvgl_algo.so.1.14.0 exit@GLIBC_2.0
vxl.i686: W: shared-lib-calls-exit /usr/lib/libbrct.so.1.14.0 exit@GLIBC_2.0
vxl.i686: W: no-manual-page-for-binary octree
vxl.src:132: W: macro-in-comment %{_docdir}
vxl.src:132: W: macro-in-comment %{name}
vxl.src:133: W: macro-in-comment %{_docdir}
vxl.src:133: W: macro-in-comment %{name}
vxl-debuginfo.i686: W: invalid-url URL: http://vxl.sourceforge.net/ <urlopen error [Errno -2] Name or service not known>
vxl-devel.i686: W: no-documentation
../SPECS/vxl.spec:132: W: macro-in-comment %{_docdir}
../SPECS/vxl.spec:132: W: macro-in-comment %{name}
../SPECS/vxl.spec:133: W: macro-in-comment %{_docdir}
../SPECS/vxl.spec:133: W: macro-in-comment %{name}
vxl.src:132: W: macro-in-comment %{_docdir}
vxl.src:132: W: macro-in-comment %{name}
vxl.src:133: W: macro-in-comment %{_docdir}
vxl.src:133: W: macro-in-comment %{name}
6 packages and 1 specfiles checked; 0 errors, 23 warnings.

>> The macro in comments are ignorable.
>> The shared-lib-calls-exit needs to be reported upstream. There isn't any thing we can do to correct this. We can ignore it for the time being IMO.

- final provides and requires are sane:
[ankur@ankur result]$ review-req-check
== vxl-1.14.0-1.fc16.i686.rpm ==
Provides:
libbcal.so.1.14
libbdgl.so.1.14
libbdpg.so.1.14
libbgeo.so.1.14
libbgrl.so.1.14
libbil.so.1.14
libbil_algo.so.1.14
libbnl.so.1.14
libbnl_algo.so.1.14
libbrct.so.1.14
libbrip.so.1.14
libbsol.so.1.14
libbsta.so.1.14
libbtol.so.1.14
libbtom.so.1.14
libbugl.so.1.14
libbvgl.so.1.14
libclsfy.so.1.14
libgeml.so.1.14
libgevd.so.1.14
libgmvl.so.1.14
libgst.so.1.14
libgtrl.so.1.14
libipts.so.1.14
libmbl.so.1.14
libmvl.so.1.14
libnetlib.so.1.14
libosl.so.1.14
libpdf1d.so.1.14
librgrl.so.1.14
librrel.so.1.14
librsdl.so.1.14
libsdet.so.1.14
libstrk.so.1.14
libtestlib.so.1.14
libv3p_netlib.so.1.14
libvbl.so.1.14
libvbl_io.so.1.14
libvcl.so.1.14
libvcsl.so.1.14
libvdgl.so.1.14
libvdtop.so.1.14
libvepl.so.1.14
libvgl.so.1.14
libvgl_algo.so.1.14
libvgl_io.so.1.14
libvgl_xio.so.1.14
libvidl.so.1.14
libvifa.so.1.14
libvil.so.1.14
libvil1.so.1.14
libvil1_io.so.1.14
libvil3d.so.1.14
libvil3d_algo.so.1.14
libvil3d_io.so.1.14
libvil_algo.so.1.14
libvil_io.so.1.14
libvimt.so.1.14
libvimt3d.so.1.14
libvimt_algo.so.1.14
libvipl.so.1.14
libvmal.so.1.14
libvmap.so.1.14
libvnl.so.1.14
libvnl_algo.so.1.14
libvnl_io.so.1.14
libvnl_xio.so.1.14
libvpdfl.so.1.14
libvpgl.so.1.14
libvpgl_xio.so.1.14
libvpl.so.1.14
libvpro.so.1.14
libvpyr.so.1.14
libvsl.so.1.14
libvsol.so.1.14
libvtol.so.1.14
libvtol_algo.so.1.14
libvul.so.1.14
libvul_io.so.1.14
vxl = 1.14.0-1.fc16
vxl(x86-32) = 1.14.0-1.fc16

Requires:
/sbin/ldconfig
/sbin/ldconfig
libbdgl.so.1.14
libbgeo.so.1.14
libbil_algo.so.1.14
libbrip.so.1.14
libbsol.so.1.14
libbsta.so.1.14
libbtol.so.1.14
libbugl.so.1.14
libc.so.6
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1)
libc.so.6(GLIBC_2.1.3)
libc.so.6(GLIBC_2.11)
libc.so.6(GLIBC_2.3.4)
libc.so.6(GLIBC_2.4)
libgcc_s.so.1
libgcc_s.so.1(GCC_3.0)
libgcc_s.so.1(GCC_4.0.0)
libgcc_s.so.1(GLIBC_2.0)
libgeotiff.so.1.2
libgevd.so.1.14
libjpeg.so.62
libjpeg.so.62(LIBJPEG_6.2)
libm.so.6
libm.so.6(GLIBC_2.0)
libm.so.6(GLIBC_2.1)
libmbl.so.1.14
libmvl.so.1.14
libnetlib.so.1.14
libosl.so.1.14
libpng12.so.0
libpng12.so.0(PNG12_0)
librrel.so.1.14
librsdl.so.1.14
libsdet.so.1.14
libstdc++.so.6
libstdc++.so.6(CXXABI_1.3)
libstdc++.so.6(GLIBCXX_3.4)
libstdc++.so.6(GLIBCXX_3.4.11)
libstdc++.so.6(GLIBCXX_3.4.15)
libstdc++.so.6(GLIBCXX_3.4.5)
libstdc++.so.6(GLIBCXX_3.4.9)
libtiff.so.3
libv3p_netlib.so.1.14
libvbl.so.1.14
libvbl_io.so.1.14
libvcl.so.1.14
libvcsl.so.1.14
libvdgl.so.1.14
libvgl.so.1.14
libvgl_algo.so.1.14
libvgl_io.so.1.14
libvgl_xio.so.1.14
libvil.so.1.14
libvil1.so.1.14
libvil3d.so.1.14
libvil3d_algo.so.1.14
libvil3d_io.so.1.14
libvil_algo.so.1.14
libvil_io.so.1.14
libvimt.so.1.14
libvimt_algo.so.1.14
libvipl.so.1.14
libvmap.so.1.14
libvnl.so.1.14
libvnl_algo.so.1.14
libvnl_io.so.1.14
libvpdfl.so.1.14
libvpgl.so.1.14
libvpro.so.1.14
libvsl.so.1.14
libvsol.so.1.14
libvtol.so.1.14
libvul.so.1.14
libz.so.1
rtld(GNU_HASH)

== vxl-1.14.0-1.fc16.src.rpm ==
Provides:

Requires:
cmake >= 2.6.3
libpng-devel
libtiff-devel
zlib-devel
libjpeg-devel
libgeotiff-devel
texi2html
rply-devel
doxygen
expat-devel
shapelib-devel
minizip-devel
dcmtk-devel

== vxl-debuginfo-1.14.0-1.fc16.i686.rpm ==
Provides:
vxl-debuginfo = 1.14.0-1.fc16
vxl-debuginfo(x86-32) = 1.14.0-1.fc16

Requires:

== vxl-devel-1.14.0-1.fc16.i686.rpm ==
Provides:
libmvl2.so
libvepl2.so
vxl-devel = 1.14.0-1.fc16
vxl-devel(x86-32) = 1.14.0-1.fc16

Requires:
libbcal.so.1.14
libbdgl.so.1.14
libbdpg.so.1.14
libbgeo.so.1.14
libbgrl.so.1.14
libbil.so.1.14
libbil_algo.so.1.14
libbnl.so.1.14
libbnl_algo.so.1.14
libbrct.so.1.14
libbrip.so.1.14
libbsol.so.1.14
libbsta.so.1.14
libbtol.so.1.14
libbtom.so.1.14
libbugl.so.1.14
libbvgl.so.1.14
libc.so.6
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1.3)
libc.so.6(GLIBC_2.4)
libclsfy.so.1.14
libgcc_s.so.1
libgcc_s.so.1(GCC_3.0)
libgeml.so.1.14
libgeotiff.so.1.2
libgevd.so.1.14
libgmvl.so.1.14
libgst.so.1.14
libgtrl.so.1.14
libipts.so.1.14
libjpeg.so.62
libm.so.6
libm.so.6(GLIBC_2.0)
libmbl.so.1.14
libmvl.so.1.14
libnetlib.so.1.14
libosl.so.1.14
libpdf1d.so.1.14
libpng12.so.0
librgrl.so.1.14
librrel.so.1.14
librsdl.so.1.14
libsdet.so.1.14
libstdc++.so.6
libstdc++.so.6(CXXABI_1.3)
libstdc++.so.6(GLIBCXX_3.4)
libstdc++.so.6(GLIBCXX_3.4.11)
libstdc++.so.6(GLIBCXX_3.4.9)
libstrk.so.1.14
libtestlib.so.1.14
libtiff.so.3
libv3p_netlib.so.1.14
libvbl.so.1.14
libvbl_io.so.1.14
libvcl.so.1.14
libvcsl.so.1.14
libvdgl.so.1.14
libvdtop.so.1.14
libvepl.so.1.14
libvgl.so.1.14
libvgl_algo.so.1.14
libvgl_io.so.1.14
libvgl_xio.so.1.14
libvidl.so.1.14
libvifa.so.1.14
libvil.so.1.14
libvil1.so.1.14
libvil1_io.so.1.14
libvil3d.so.1.14
libvil3d_algo.so.1.14
libvil3d_io.so.1.14
libvil_algo.so.1.14
libvil_io.so.1.14
libvimt.so.1.14
libvimt3d.so.1.14
libvimt_algo.so.1.14
libvipl.so.1.14
libvmal.so.1.14
libvmap.so.1.14
libvnl.so.1.14
libvnl_algo.so.1.14
libvnl_io.so.1.14
libvnl_xio.so.1.14
libvpdfl.so.1.14
libvpgl.so.1.14
libvpgl_xio.so.1.14
libvpl.so.1.14
libvpro.so.1.14
libvpyr.so.1.14
libvsl.so.1.14
libvsol.so.1.14
libvtol.so.1.14
libvtol_algo.so.1.14
libvul.so.1.14
libvul_io.so.1.14
libz.so.1
rtld(GNU_HASH)
vxl = 1.14.0-1.fc16

== vxl-doc-1.14.0-1.fc16.i686.rpm ==
Provides:
vxl-doc = 1.14.0-1.fc16
vxl-doc(x86-32) = 1.14.0-1.fc16

Requires:
vxl = 1.14.0-1.fc16
^^^^^^^^^^^^^^^^^^^^^^
It's a *long* list :P. Can you just glance through it once Mario ?

SHOULD Items:

+ Should build in mock.
+ Should build on all supported archs
- Should function as described.
+ Should have sane scriptlets.
+ Should have subpackages require base package with fully versioned depend.
+ Should have dist tag
+ Should package latest version
- check for outstanding bugs on package. (For core merge reviews)

Thanks!
Ankur
Comment 25 Peter Lemenkov 2011-06-16 04:30:12 EDT
Hello!

(In reply to comment #24)
> Hello,
> 
> An informal review :D

Ankur, please, reassign this ticket to yourself - I don;t have free time to compolete the review in the next week or two.
Comment 26 Mario Ceresa 2011-06-16 04:35:34 EDT
Hi all!

@Ankur: thanks a lot for your input!
I'll review klt and agree that the other libs should stay bundled. 
I'm not familiar with the "final provides and requires are sane:" and
"review-req-check" parts. What exactly should I do here?

@Peter: ok thank you for bringing me so far :) 

Best,

Mario
Comment 27 Ankur Sinha (FranciscoD) 2011-06-16 04:42:49 EDT
Hi Peter,

(In reply to comment #25)
> Hello!
> 
> (In reply to comment #24)
> > Hello,
> > 
> > An informal review :D
> 
> Ankur, please, reassign this ticket to yourself - I don;t have free time to
> compolete the review in the next week or two.

I'll do that :)
Thanks,

(In reply to comment #26)
> Hi all!
> 
> @Ankur: thanks a lot for your input!
> I'll review klt and agree that the other libs should stay bundled. 
> I'm not familiar with the "final provides and requires are sane:" and
> "review-req-check" parts. What exactly should I do here?

Hi Mario,
You need to just look at the list and see if the requires and provides are what they should be ;)

review-req-check is just an alias:

alias review-req-check='for i in *rpm; do echo "== $i =="; echo "Provides:"; rpm -qp --provides $i | sed "/rpmlib.*/d" ; echo  ; echo "Requires:"    ; rpm -qp --requires $i | sed "/rpmlib.*/d"; echo; done'$


> 
> @Peter: ok thank you for bringing me so far :) 
> 
> Best,
> 
> Mario

Thanks for taking klt Mario,

Thanks
Ankur
Comment 28 Ankur Sinha (FranciscoD) 2011-06-20 03:50:27 EDT
Taking over review
Comment 29 Richard Shaw 2011-08-13 12:38:06 EDT
Ankur,

I'll see if I can help workout the problems between this and vmtk if someone will post the latest spec and SRPM.

Thanks,
Richard
Comment 30 Ankur Sinha (FranciscoD) 2011-08-15 08:04:49 EDT
#22 has them. Let's wait for Mario to fix it up first. It wouldn't be nice if two people worked independently and came up with the same fixes :P
Comment 31 Richard Shaw 2011-09-19 10:55:43 EDT
Ankur,

Are you still actively pursuing this review? 

Richard
Comment 32 Ankur Sinha (FranciscoD) 2011-10-15 00:52:53 EDT
Richard,

Please go ahead and take over the review if you'd like to.

Thanks,
Ankur
Comment 33 Richard Shaw 2011-10-16 21:48:48 EDT
We'll have to wait and see if Mario posts new links after updating but I can probably take care of it!

Richard
Comment 34 Volker Fröhlich 2011-12-13 14:43:46 EST
Any progress here?
Comment 35 Volker Fröhlich 2011-12-18 04:23:31 EST
Can somebody publish the latest state of the work? I'd like to see if I can help.
Comment 36 Volker Fröhlich 2011-12-19 16:32:07 EST
Found them, on http://mrceresa.fedorapeople.org, if that's really the latest state.
Comment 37 Volker Fröhlich 2011-12-27 15:58:46 EST
A random finding:

Klt is not used, because vgel is not built. It's only built if you choose to build for the VXL dashboard or if you opt to build libraries no longer maintained.
Comment 38 Mario Ceresa 2012-02-01 06:27:43 EST
Hi everybody! please see this post on the current status of ITK dependencies:

https://fedorahosted.org/pipermail/medical-sig/2012-February/000240.html

Best,

Mario
Comment 39 Peter Lemenkov 2012-10-08 08:40:15 EDT
Taking this over for review. Mario, please provide your latest package - let's revive this.
Comment 40 Mario Ceresa 2012-10-09 06:31:33 EDT
I setup a repository at 
http://repos.fedorapeople.org/repos/mrceresa/cil/

and I'm populating with the last rpms. VXL has a problem to build on f17-f18 and I'm working on it. I hope to fix that soon.

I'll also have a git repository here:
https://github.com/mrceresa/vxl

where we can collaborate on the patches.
Comment 41 Mario Ceresa 2012-10-09 14:01:51 EDT
Unfortunately the build error is a major incompatibility of VXL with current libpng (gosh!):
http://sourceforge.net/mailarchive/message.php?msg_id=28478595

Fixed in late august but the fix never made to the official release, only in svn... This means I have to rebase all the patches on the development version...
Comment 43 Mario Ceresa 2012-10-10 12:46:59 EDT
Thanks Volker! 
As I was saying, I switched to the devel branch (vxl-1.17.rc2 approximatively) because older versions have and incompatibility with libpng.

For this reason we should reapply all the patches and see if they are still valid.

The new git repo is: 
https://github.com/mrceresa/vxl_dev

where you'll find the original code I picked up from the svn in tag r35730 and all the patches valid and included so far in branch master.

In the meantime I had to set BUILD_BRL=OFF because of a build error in bbio. The problem seems related to new version of gcc not including unistd.h by default but I had no time to look further at it. Anyone else would like to investigate this issue?

I'm looking at your patches now.

The online repos should be populated with the new rpms in short time. (@Peter: I populated only the fedora-17 branch because it's the one I'm using now.)

Best,

Mario
Comment 44 Peter Lemenkov 2012-10-10 13:41:17 EDT
Ok, what we have now:

It builds in Koji cleanly:

* http://koji.fedoraproject.org/koji/taskinfo?taskID=4578855

Here is a Git repo (git-svn mirror):

* http://vxl.git.sourceforge.net/git/gitweb.cgi?p=vxl/vxl;a=summary

And here is a page with the latest 1.17: 

* http://sourceforge.net/projects/vxl/files/vxl/1.17/

I'd say - that's a good starting point.
Comment 45 Mario Ceresa 2012-10-10 14:52:27 EDT
I made a new version with Volker's patches (Please Volker, check that I did it in the correct way!)

Here there is the git repo which clones the git-svn mirror and has all the patches applied:

* https://github.com/mrceresa/vxl_dev

Here there is the new koji build (in progress):

* http://koji.fedoraproject.org/koji/taskinfo?taskID=4579084

Tomorrow I'll start looking into the rpmlint output
Comment 46 Volker Fröhlich 2012-10-10 15:45:51 EDT
Please incorporate my changes from the spec file diff as well. I think they are quite usable and important too.

Some of the patches actually look like they could go upstream. I thought they were worse.

I don't really get the purpose of the repo. I expected to find a repository much like for packaging, containing spec file and patches. Can you enlighten me?
Comment 47 Mario Ceresa 2012-10-11 04:59:35 EDT
I actually incorporated a lot of the changes you proposed to the specfile. I didn't moved the doc and devel sections in the upper part because I find more readable this way, but this is just a personal taste, and left over some of the other changes -such as comments or parts I didn't understand well- because the spec will surely change again before the package is approved and we will have time to include them later.

Is there something big that I missed out?

I use the repo to:

* generate the source tarball:
$ git archive --prefix=vxl-git14bc2bc/ -o vxl-git14bc2bc.tar.gz 14bc2bc

* work on the patches, store them and generate the patch-files:
$ git format-patch 0d312e7..

I like the idea to put also the specfile in the repo, but I don't how to put it without cluttering the sources... suggestions welcome!
Comment 48 Volker Fröhlich 2012-10-12 17:20:20 EDT
These two sections were not only moved, but also changed:

- Added ?_isa macros
- Made doc noarch
- Removed useless %defattr
- Simplified the file list

I still suggest to move them, because it's the general style in Fedora.

The reason why I sorted the BRs, is, you can more easily spot duplicates: doxygen is in there twice and so are libgeotiff-devel and expat-devel. The version requirement for cmake is pointless. Even EL 5 has a newer version.

Many of the TODO items refer to bundled stuff that must be dealt with.
Comment 49 Mario Ceresa 2012-10-14 12:24:53 EDT
Hi! here you are the last updates which includes:

* I incorporated Volker's last suggestions
* Fixed sonames in several more libs

License issues from comment 24:

+ $ egrep -nri "LGPL" *
Binary file contrib/gel/vifa/tests/cam0013.tif matches
contrib/brl/bbas/bil/algo/bil_edt.h:37://  Implementation influenced by the LTI lib, which is licensed under LGPL:
contrib/brl/b3p/shapelib/shptree.c:11: * or at the option of the licensee under the LGPL (see LICENSE.LGPL).  This
contrib/brl/b3p/shapelib/dbfopen.c:11: * or at the option of the licensee under the LGPL (see LICENSE.LGPL).  This
contrib/brl/b3p/shapelib/shapefil.h:13: * or at the option of the licensee under the LGPL (see LICENSE.LGPL).  This
contrib/brl/b3p/shapelib/shpopen.c:11: * or at the option of the licensee under the LGPL (see LICENSE.LGPL).  This

---> shapelib is removed in the prep section and shapelib-devel is used instead

+ builds in koji http://koji.fedoraproject.org/koji/taskinfo?taskID=4589017

! rpmlint is NOT silent:

[mario@gervis x86_64]$ rpmlint ./vxl-1.17.0-3.fc17.x86_64.rpm
vxl.x86_64: W: shared-lib-calls-exit /usr/lib64/libvil.so.1.14.0 exit@GLIBC_2.2.5
vxl.x86_64: W: shared-lib-calls-exit /usr/lib64/libnetlib.so.1.14.0 exit@GLIBC_2.2.5
vxl.x86_64: W: shared-lib-calls-exit /usr/lib64/libvgui.so.1.14.0 exit@GLIBC_2.2.5
vxl.x86_64: W: shared-lib-calls-exit /usr/lib64/libv3p_netlib.so.1.14.0 exit@GLIBC_2.2.5
vxl.x86_64: W: shared-lib-calls-exit /usr/lib64/libvil1.so.1.14.0 exit@GLIBC_2.2.5
vxl.x86_64: W: shared-lib-calls-exit /usr/lib64/libvul.so.1.14.0 exit@GLIBC_2.2.5
vxl.x86_64: W: shared-lib-calls-exit /usr/lib64/libvgl_algo.so.1.14.0 exit@GLIBC_2.2.5
vxl.x86_64: W: shared-lib-calls-exit /usr/lib64/libmvl.so.1.14.0 exit@GLIBC_2.2.5
vxl.x86_64: W: no-manual-page-for-binary octree
vxl.x86_64: W: no-manual-page-for-binary xcv
vxl.x86_64: W: no-manual-page-for-binary vxl_vrml_viewer
1 packages and 0 specfiles checked; 0 errors, 11 warnings.

[mario@gervis x86_64]$ rpmlint ./vxl-devel-1.17.0-3.fc17.x86_64.rpm
vxl-devel.x86_64: W: shared-lib-calls-exit /usr/lib64/libbzip2.so exit@GLIBC_2.2.5
vxl-devel.x86_64: W: no-documentation
1 packages and 0 specfiles checked; 0 errors, 2 warnings. 

Please comments on them and I'll continue with the packaging.
Comment 50 Mario Ceresa 2012-10-19 10:11:43 EDT
Waiting for expatpp to be approved (#868325)
Comment 51 Mario Ceresa 2012-10-29 05:43:13 EDT
Okay, thanks to Peter expatpp has been approved. 
I'll wait for it to hit the repositories and then build a new version of vxl which builds against it.
Comment 52 Peter Lemenkov 2012-10-29 05:46:48 EDT
(In reply to comment #51)
> Okay, thanks to Peter expatpp has been approved. 
> I'll wait for it to hit the repositories and then build a new version of vxl
> which builds against it.

Is anything else left or that was the last bundled library?
Comment 53 Mario Ceresa 2012-10-29 06:26:00 EDT
Let's summarize what we have so far:

+ We successfully removed png, jpeg, zlib, tiff, geotiff, rply, dcmtk, shapelib, minizip, expat, expatpp, kl.

- Still there might be issues with Qv, netlib, bzlib, oufgl. However:

1) bzlib is included in Fedora so I'll simply build against it. (How could I have missed that?)

2) netlib: is heavily modified and therefore we keep it (see comments 1, 3, 20, 23)

3) QV and oufgl: We keep them (see comment 24)
Comment 54 Volker Fröhlich 2012-10-29 06:34:01 EDT
I think we have to get an exeception granted for netlib. Better yet, upstream should try to sort it out.
Comment 55 Mario Ceresa 2012-11-02 13:25:48 EDT
A lot of improvements such as fixed broken BRL compilation. BuildRequires expatpp-devel which is now in testing:

http://repos.fedorapeople.org/repos/mrceresa/cil/fedora-17/SRPMS/vxl-1.17.0-6.fc17.src.rpm
Comment 56 Peter Lemenkov 2012-11-24 07:29:23 EST
Koji scratch build for Rawhide:

* http://koji.fedoraproject.org/koji/taskinfo?taskID=4723014

REVIEW:

Legend: + = PASSED, - = FAILED, 0 = Not Applicable

+ rpmlint is almost silent

Auriga ~: rpmlint Desktop/vxl-*
vxl.src:224: W: macro-in-comment %{_datadir}
vxl.src:224: W: macro-in-comment %{name}

^^^ harmless.

vxl.src: W: file-size-mismatch vxl-git4e07960.tar.gz = 41848047, http://sourceforge.net/projects/vxl/files/vxl/1.14/vxl-git4e07960.tar.gz = 24325

^^^ harmless as well.

vxl.x86_64: W: shared-lib-calls-exit /usr/lib64/libvil.so.1.14.0 exit@GLIBC_2.2.5
vxl.x86_64: W: shared-lib-calls-exit /usr/lib64/libnetlib.so.1.14.0 exit@GLIBC_2.2.5
vxl.x86_64: W: shared-lib-calls-exit /usr/lib64/libv3p_netlib.so.1.14.0 exit@GLIBC_2.2.5
vxl.x86_64: W: shared-lib-calls-exit /usr/lib64/libvil1.so.1.14.0 exit@GLIBC_2.2.5
vxl.x86_64: W: shared-lib-calls-exit /usr/lib64/libvul.so.1.14.0 exit@GLIBC_2.2.5
vxl.x86_64: W: shared-lib-calls-exit /usr/lib64/libvgl_algo.so.1.14.0 exit@GLIBC_2.2.5
vxl.x86_64: W: shared-lib-calls-exit /usr/lib64/libmvl.so.1.14.0 exit@GLIBC_2.2.5


^^^ these issues should be fixed upstream. It's a generally good idea for every library to return an error code instead of dying simply. It's not a blocker.

vxl.x86_64: W: no-manual-page-for-binary octree
vxl-devel.x86_64: W: no-documentation

^^^ Just lack of a documentation.

5 packages and 0 specfiles checked; 0 errors, 12 warnings.
Auriga ~: 

+ The package is named according to the  Package Naming Guidelines.
+ The spec file name matches the base package %{name}, in the format %{name}.spec.
+ The package meets the Packaging Guidelines.
+ The package is licensed with a Fedora approved license and meets the Licensing Guidelines.
+ The License field in the package spec file matches the actual license (BSD, sta stated at the SF page - http://sourceforge.net/projects/vxl/ ).
0 No licensing info provided in tarball.
+ The spec file is written in American English.
+ The spec file for the package is legible.

-/+ The sources used to build the package, MUST match the upstream source, as provided in the spec URL. Proper link for 1.17 is

* http://downloads.sourceforge.net/project/vxl/vxl/1.17/vxl-1.17.0.tar.gz

Please update your spec-file before uploading.

+ The package successfully compiles and builds into binary rpms on at least one primary architecture. See Koji link above.
+ All build dependencies are listed in BuildRequires.
0 No need to handle locales.
+ The package stores shared library files in some of the dynamic linker's default paths, and it calls ldconfig in %post and %postun.

+/- The package does contain copies of system libraries. Namely it contains some pieces extracted from well-known netlib library. And some parts of this library were already packaged so technically we should build package against them.

However I believe that we should strip them later. First of all no full netlib library is available in Fedora - just a few chosen pieces. Second, we could run into a superposition of issues - let's test package first and start unbundling the rest of the stuff later. 

So *I believe we should package library as is* and later (after all interested parties confirm that it works as expected) start looking at the netlib issue (which could be even more complicated than packaging this library itself).

Size of this package does matters so I really don't want to wait another year for this package to be available in Fedora.

0 The package is not designed to be relocatable.
+ The package owns all directories that it creates.
+ The package does not list a file more than once in the spec file's %files listings.
+ Permissions on files are set properly.
+ The package has a %clean section, which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT).
+ The package contains code, or permissible content.
0 No extremely large documentation files within the main rpm (they are packaged separately).
+ Anything, the package includes as %doc, does not affect the runtime of the application.
+ Header files are stored in a -devel package.
0 No static libraries.
0 No pkgconfig(.pc) files.


+/- The package doesn't contain library files without a suffix (e.g. libfoo.so) in some of the dynamic linker's default paths in the main rpm. However I =m worried about two libraries within the devel subpackage - libvml2.so, libvepl1.so. They look like a leftover - it seems that you missed them while adding sonames. 

+ The library file(s) that end in .so (without suffix) is(are) stored in a -devel package.
+ The -devel package requires the base package using a fully versioned dependency: Requires: %{name}%{?_isa} = %{version}-%{release}
+ The package does NOT contain any .la libtool archives.
0 Not a GUI application.
+ The package does not own files or directories already owned by other packages.
+ At the beginning of %install, the package runs rm -rf %{buildroot} (or $RPM_BUILD_ROOT).
+ All filenames in rpm packages are valid UTF-8.

So although this package still has room for further improvements and I fully share concerns expressed earlier by Volker Fröhlich I feel that we should declare it as a "ready for Fedora" at this stage. Therefore I declare this package as


APPROVED.
Comment 57 Mario Ceresa 2012-11-24 08:07:22 EST
Well, it might not be the most professional thing to do on my side but...

!!!!!!YHUHUUUHUHHUUUUUUUUUUUUHH!!!!!!!!!!!

:D:D
Comment 58 Mario Ceresa 2012-11-24 08:11:00 EST
New Package SCM Request
=======================
Package Name: vxl
Short Description: C++ Libraries for Computer Vision Research and Implementation
Owners: mrceresa
Branches: f17 f18 el6
InitialCC: peter
Comment 59 Jon Ciesla 2012-11-24 13:14:22 EST
Git done (by process-git-requests).
Comment 60 Fedora Update System 2012-11-25 08:44:46 EST
vxl-1.17.0-7.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/vxl-1.17.0-7.fc17
Comment 61 Fedora Update System 2012-11-25 20:54:30 EST
vxl-1.17.0-7.fc17 has been pushed to the Fedora 17 testing repository.
Comment 62 Fedora Update System 2012-11-29 15:02:16 EST
vxl-1.17.0-7.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/vxl-1.17.0-7.fc18
Comment 63 Fedora Update System 2012-12-03 23:57:01 EST
vxl-1.17.0-7.fc17 has been pushed to the Fedora 17 stable repository.
Comment 64 Thomas Bouffon 2012-12-04 05:22:46 EST
A little late, but congrats to everyone ! This was a hell of a build !

Thomas
Comment 65 Fedora Update System 2012-12-05 09:48:42 EST
vxl-1.17.0-8.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/vxl-1.17.0-8.fc18
Comment 66 Fedora Update System 2012-12-05 09:49:11 EST
vxl-1.17.0-8.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/vxl-1.17.0-8.fc17
Comment 67 Fedora Update System 2012-12-15 13:02:03 EST
vxl-1.17.0-8.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 68 Fedora Update System 2013-01-11 19:49:58 EST
vxl-1.17.0-8.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.