Bug#809312: RFS: otb/5.2.0+dfsg-1 [ITP] -- Orfeo Toolbox

2015-12-29 Thread Ghislain Vaillant 



On 29/12/15 10:09, Rashad Kanavath wrote:

Hi Ghislain,

debian policy for shared library says each library must be in a seperate
package [1].


The following citation from the very link you provided is far from the 
definition I know of "must":


"If you have several shared libraries built from the same source tree, 
you may lump them all together into a single shared library package 
provided that all of their SONAMEs will always change together."



OTB is well modularaized since 5.0.0. This allows external apps or
libaries to use have some of the otb libs not all

For instance,
monteverdi required only a small subset of libs:
   OTBApplicationEngine
   OTBQtWidget
   OTBImageIO
   OTBVectorDataIO
   OTBTestKernel
   OTBCarto
   OTBProjection
   OTBStatistics

So splitting a shared library is useful there. It also aslo true for
remote modules. If anyone want to write a remote module that depends on
two other modules OTBCommon, OTBTestKernel. he don't need to drag in all
dependencies for that.


The modularization of OTB follows pretty much what ITK does from the 
distant look I had of it, and I am familiar with how VTK / ITK is 
packaged in Debian. Still neither of both were  modularized too much 
besides the separation of the Python and Qt specific stuff, in order to 
reduce (co)maintenance burden. Again, you're the maintainer and the 
final decision is totally yours here.


Besides, all the modules you provide seem to qualify for the case I 
cited above (same goes for ITK / VTK), hence my suggestion to place them 
in a common shlib package. Since you assumed that the policy "forced" 
you to do otherwise, I understand why you considered my advice defensively.



And in future otb may have more modules. If there is a problem with
split up libraries, I can change it and make it simply libotb and
libotb-dev


I can't comment on the "simplicity" of the conversion. Perhaps you have 
more experience on this aspect of packaging than I do.


On a side note, by contributing to other packages than I personally 
maintain, I can tell you one thing: the more complicated the packaging, 
the least I have been inclined to invest time in co-maintenance. That is 
likely to apply to others.



What do you think?


Not that it matters anymore, since your source package has now been 
sponsored. Good luck with the rest though.


Ghis

Bug#809312: RFS: otb/5.2.0+dfsg-1 [ITP] -- Orfeo Toolbox [uploaded]

2015-12-29 Thread Sebastiaan Couwenberg 
On 29-12-15 11:54, Rashad Kanavath wrote:
> should I fix the spelling and reupload now or wait for the NEW queue.

I'd fix it in git now, and wait for the next upload until it passes the
NEW queue.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#809312: RFS: otb/5.2.0+dfsg-1 [ITP] -- Orfeo Toolbox

2015-12-29 Thread KANAVATH Rashad 


Quoting Ghislain Vaillant :


On 29/12/15 10:09, Rashad Kanavath wrote:

Hi Ghislain,

debian policy for shared library says each library must be in a seperate
package [1].


The following citation from the very link you provided is far from  
the definition I know of "must":


I didn't mean RTFM (Read the fine manual). When I was having initial  
package review, I was asked to move shared libs into separate  
packages. I initially had separated qt and python stuff only.


"If you have several shared libraries built from the same source  
tree, you may lump them all together into a single shared library  
package provided that all of their SONAMEs will always change  
together."



OTB is well modularaized since 5.0.0. This allows external apps or
libaries to use have some of the otb libs not all

For instance,
monteverdi required only a small subset of libs:
  OTBApplicationEngine
  OTBQtWidget
  OTBImageIO
  OTBVectorDataIO
  OTBTestKernel
  OTBCarto
  OTBProjection
  OTBStatistics

So splitting a shared library is useful there. It also aslo true for
remote modules. If anyone want to write a remote module that depends on
two other modules OTBCommon, OTBTestKernel. he don't need to drag in all
dependencies for that.


The modularization of OTB follows pretty much what ITK does from the  
distant look I had of it, and I am familiar with how VTK / ITK is  
packaged in Debian. Still neither of both were  modularized too much  
besides the separation of the Python and Qt specific stuff, in order  
to reduce (co)maintenance burden. Again, you're the maintainer and  
the final decision is totally yours here.


yes. modularization of otb follows that of itk.



Besides, all the modules you provide seem to qualify for the case I  
cited above (same goes for ITK / VTK), hence my suggestion to place  
them in a common shlib package. Since you assumed that the policy  
"forced" you to do otherwise, I understand why you considered my  
advice defensively.


Not exactly. If there is some issue with the current state of  
packaging, I am okay to fix it.


ofcourse, going back to single libs is easy but a lot of work will be wasted.
But I don't have a problem with that. sorry If I sounded defensive to  
your comments, it may be because i was doing a single shared libs at  
first and then I decided to split them.



And in future otb may have more modules. If there is a problem with
split up libraries, I can change it and make it simply libotb and
libotb-dev


I can't comment on the "simplicity" of the conversion. Perhaps you  
have more experience on this aspect of packaging than I do.


On a side note, by contributing to other packages than I personally  
maintain, I can tell you one thing: the more complicated the  
packaging, the least I have been inclined to invest time in  
co-maintenance. That is likely to apply to others.


I guess maintaining the symbols file is easier when packages are  
separated. And before I start, I looked into other packaging works in  
DebianGIS. All of them follow this way. So I stick to that.


The complexity of maintenance you were mentioning was also similar as  
in the case of qgis.



What do you think?


Not that it matters anymore, since your source package has now been  
sponsored. Good luck with the rest though.


Thanks. I appreciate your feedback and possible interest in  
maintaining the package.



Ghis

Bug#809312: RFS: otb/5.2.0+dfsg-1 [ITP] -- Orfeo Toolbox

2015-12-29 Thread Rashad Kanavath 

Package: sponsorship-requests
  Severity: normal [important for RC bugs, wishlist for new packages]

  Dear mentors,

  I am looking for a sponsor for my package "otb"

 * Package name: otb
   Version : 5.2.0+dfsg-1
   Upstream Author : cont...@orfe-toolbox.org
 * URL : http://orfeo-toolbox.org
 * License : CeCILL-2.0
   Section : science

  It builds those binary packages:

libotb - ORFEO Toolbox library metapackage
 libotb-apps - Plugins for ORFEO Toolbox applications
 libotb-dev - Free library of image processing algorithms - development
 libotbapplicationengine-5.2-1 - ORFEO Toolbox library - 
OTBApplicationEngine

 libotbcarto-5.2-1 - ORFEO Toolbox library - OTBCarto
 libotbcommandline-5.2-1 - ORFEO Toolbox library - OTBCommandLine
 libotbcommandlineparser-5.2-1 - ORFEO Toolbox library - 
OTBCommandLinePaser

 libotbcommon-5.2-1 - ORFEO Toolbox library - OTBCommon
 libotbcurladapters-5.2-1 - ORFEO Toolbox library - OTBCurlAdapters
 libotbedge-5.2-1 - ORFEO Toolbox library - OTBEdge
 libotbextendedfilename-5.2-1 - ORFEO Toolbox library - 
OTBExtendedFileName

 libotbfuzzy-5.2-1 - ORFEO Toolbox library - OTBFuzzy
 libotbgdaladapters-5.2-1 - ORFEO Toolbox library - OTBGdalAdapters
 libotbimagebase-5.2-1 - ORFEO Toolbox library - OTBImageBase
 libotbimageio-5.2-1 - ORFEO Toolbox library - OTBImageIO
 libotbimagemanipulation-5.2-1 - ORFEO Toolbox library - 
OTBImageManipulation

 libotbiobsq-5.2-1 - ORFEO Toolbox library - OTBIOBSQ
 libotbiogdal-5.2-1 - ORFEO Toolbox library - OTBIOGDAL
 libotbiokml-5.2-1 - ORFEO Toolbox library - OTBIOKML
 libotbiolum-5.2-1 - ORFEO Toolbox library - OTBIOLUM
 libotbiomstar-5.2-1 - ORFEO Toolbox library - OTBIOMSTAR
 libotbiomw-5.2-1 - ORFEO Toolbox library - OTBIOMW
 libotbioonera-5.2-1 - ORFEO Toolbox library - OTBIOONERA
 libotbiorad-5.2-1 - ORFEO Toolbox library - OTBIORAD
 libotbiotilemap-5.2-1 - ORFEO Toolbox library - OTBIOTileMap
 libotbmathparser-5.2-1 - ORFEO Toolbox library - OTBMathParser
 libotbmetadata-5.2-1 - ORFEO Toolbox library - OTBMetadata
 libotbopenthreadsadapters-5.2-1 - ORFEO Toolbox library - 
OTBOpenThreadsAdapters

 libotbossimadapters-5.2-1 - ORFEO Toolbox library - OTBOssimAdapters
 libotbossimplugins-5.2-1 - ORFEO Toolbox library - OTBOssimPlugins
 libotbpolarimetry-5.2-1 - ORFEO Toolbox library - OTBPolarimetry
 libotbprojection-5.2-1 - ORFEO Toolbox library - OTBProjection
 libotbqtwidget-5.2-1 - ORFEO Toolbox library - OTBQtWidget
 libotbrcc8-5.2-1 - ORFEO Toolbox library - OTBRCC8
 libotbsiftfast-5.2-1 - ORFEO Toolbox library - OTBSiftFast
 libotbstreaming-5.2-1 - ORFEO Toolbox library - OTBStreaming
 libotbsupervised-5.2-1 - ORFEO Toolbox library - OTBSupervised
 libotbtestkernel-5.2-1 - ORFEO Toolbox library - OTBTestKernel
 libotbtransform-5.2-1 - ORFEO Toolbox library - OTBTransform
 libotbvectordatabase-5.2-1 - ORFEO Toolbox library - OTBVectorDataBase
 libotbvectordataio-5.2-1 - ORFEO Toolbox library - OTBVectorDataIO
 libotbwavelet-5.2-1 - ORFEO Toolbox library - OTBWavelet
 otb-bin- ORFEO Toolbox command line applications
 otb-bin-qt - ORFEO Toolbox graphical user interface applications
 otb-testdriver - ORFEO Toolbox library - OTBTestDriver
 python-otb - ORFEO Toolbox Python API for applications

  To access further information about this package, please visit the 
following URL:


http://mentors.debian.net/package/otb


  Alternatively, one can download the package with dget using this 
command:


dget -x 
http://mentors.debian.net/debian/pool/main/o/otb/otb_5.2.0+dfsg-1.dsc


  More information about otb can be obtained from http://orfeo-toolbox.org


here is the ITP report - 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764860


  Changes since the last upload:



  Regards,
   Rashad Kanavath

Bug#809312: RFS: otb/5.2.0+dfsg-1 [ITP] -- Orfeo Toolbox

2015-12-29 Thread Ghislain Vaillant 

Hi Rashad,

Thanks for working on packaging the ORFEO toolbox to Debian.

I am wondering about the usefulness of having so many binary packages. I 
guess this reflects the fact that OTB is nicely modularized, but even 
toolkits like VTK / ITK are packaged with a reduced number of binary 
packages for simpler maintenance. Besides, none of the shlib packages 
have a corresponding -dev package (ala Boost for instance), so providing 
individual shlib packages for each binary sounds excessive.


Also, please keep in mind that having one package per module means that, 
assuming OTB keeps introducing newer modules future releases, then new 
-shlib packages would have to be introduced each time and be manually 
validated by the release team. With a "combined" package approach (ala 
VTK for instance), the new modules can just be added to the existing 
packaging without requiring manual intervention.


Best regards,
Ghis


On 29/12/15 09:20, Rashad Kanavath wrote:

Package: sponsorship-requests
   Severity: normal [important for RC bugs, wishlist for new packages]

   Dear mentors,

   I am looking for a sponsor for my package "otb"

  * Package name: otb
Version : 5.2.0+dfsg-1
Upstream Author : cont...@orfe-toolbox.org
  * URL : http://orfeo-toolbox.org
  * License : CeCILL-2.0
Section : science

   It builds those binary packages:

 libotb - ORFEO Toolbox library metapackage
  libotb-apps - Plugins for ORFEO Toolbox applications
  libotb-dev - Free library of image processing algorithms - development
  libotbapplicationengine-5.2-1 - ORFEO Toolbox library -
OTBApplicationEngine
  libotbcarto-5.2-1 - ORFEO Toolbox library - OTBCarto
  libotbcommandline-5.2-1 - ORFEO Toolbox library - OTBCommandLine
  libotbcommandlineparser-5.2-1 - ORFEO Toolbox library -
OTBCommandLinePaser
  libotbcommon-5.2-1 - ORFEO Toolbox library - OTBCommon
  libotbcurladapters-5.2-1 - ORFEO Toolbox library - OTBCurlAdapters
  libotbedge-5.2-1 - ORFEO Toolbox library - OTBEdge
  libotbextendedfilename-5.2-1 - ORFEO Toolbox library -
OTBExtendedFileName
  libotbfuzzy-5.2-1 - ORFEO Toolbox library - OTBFuzzy
  libotbgdaladapters-5.2-1 - ORFEO Toolbox library - OTBGdalAdapters
  libotbimagebase-5.2-1 - ORFEO Toolbox library - OTBImageBase
  libotbimageio-5.2-1 - ORFEO Toolbox library - OTBImageIO
  libotbimagemanipulation-5.2-1 - ORFEO Toolbox library -
OTBImageManipulation
  libotbiobsq-5.2-1 - ORFEO Toolbox library - OTBIOBSQ
  libotbiogdal-5.2-1 - ORFEO Toolbox library - OTBIOGDAL
  libotbiokml-5.2-1 - ORFEO Toolbox library - OTBIOKML
  libotbiolum-5.2-1 - ORFEO Toolbox library - OTBIOLUM
  libotbiomstar-5.2-1 - ORFEO Toolbox library - OTBIOMSTAR
  libotbiomw-5.2-1 - ORFEO Toolbox library - OTBIOMW
  libotbioonera-5.2-1 - ORFEO Toolbox library - OTBIOONERA
  libotbiorad-5.2-1 - ORFEO Toolbox library - OTBIORAD
  libotbiotilemap-5.2-1 - ORFEO Toolbox library - OTBIOTileMap
  libotbmathparser-5.2-1 - ORFEO Toolbox library - OTBMathParser
  libotbmetadata-5.2-1 - ORFEO Toolbox library - OTBMetadata
  libotbopenthreadsadapters-5.2-1 - ORFEO Toolbox library -
OTBOpenThreadsAdapters
  libotbossimadapters-5.2-1 - ORFEO Toolbox library - OTBOssimAdapters
  libotbossimplugins-5.2-1 - ORFEO Toolbox library - OTBOssimPlugins
  libotbpolarimetry-5.2-1 - ORFEO Toolbox library - OTBPolarimetry
  libotbprojection-5.2-1 - ORFEO Toolbox library - OTBProjection
  libotbqtwidget-5.2-1 - ORFEO Toolbox library - OTBQtWidget
  libotbrcc8-5.2-1 - ORFEO Toolbox library - OTBRCC8
  libotbsiftfast-5.2-1 - ORFEO Toolbox library - OTBSiftFast
  libotbstreaming-5.2-1 - ORFEO Toolbox library - OTBStreaming
  libotbsupervised-5.2-1 - ORFEO Toolbox library - OTBSupervised
  libotbtestkernel-5.2-1 - ORFEO Toolbox library - OTBTestKernel
  libotbtransform-5.2-1 - ORFEO Toolbox library - OTBTransform
  libotbvectordatabase-5.2-1 - ORFEO Toolbox library - OTBVectorDataBase
  libotbvectordataio-5.2-1 - ORFEO Toolbox library - OTBVectorDataIO
  libotbwavelet-5.2-1 - ORFEO Toolbox library - OTBWavelet
  otb-bin- ORFEO Toolbox command line applications
  otb-bin-qt - ORFEO Toolbox graphical user interface applications
  otb-testdriver - ORFEO Toolbox library - OTBTestDriver
  python-otb - ORFEO Toolbox Python API for applications

   To access further information about this package, please visit the
following URL:

http://mentors.debian.net/package/otb


   Alternatively, one can download the package with dget using this
command:

 dget -x
http://mentors.debian.net/debian/pool/main/o/otb/otb_5.2.0+dfsg-1.dsc

   More information about otb can be obtained from http://orfeo-toolbox.org


here is the ITP report -
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764860

   Changes since the last upload:



   Regards,
Rashad Kanavath

Bug#809312: RFS: otb/5.2.0+dfsg-1 [ITP] -- Orfeo Toolbox [uploaded]

2015-12-29 Thread Rashad Kanavath 



On 12/29/2015 11:46 AM, Sebastiaan Couwenberg wrote:

Hi Rashad,

Thanks for your work on otb. I've sponsored the upload.

lintian did report a new spelling error, please fix this as part of the
next upload:

  I: libotb-apps: spelling-error-in-binary
usr/lib/otb/applications/otbapp_GridBasedImageResampling.so intepreted
interpreted

Next time please also CC the RFS bugreport to the pkg-grass-devel list
as documented in the Debian GIS policy:
I did add the cc. The issue was that I used the work mail to post the 
bug which wasn't subscribed to that list.


I guarantee that this won't be a problem next time.

should I fix the spelling and reupload now or wait for the NEW queue.


  https://pkg-grass.alioth.debian.org/policy/packaging.html#sponsorship

Be aware that Alioth is currently down due to planned maintenance:

  https://lists.debian.org/debian-infrastructure-announce/2015/12/msg0.html

This makes the git repositories and team websites hosted on Alioth
unavailable too.

Normally packages are automatically removed from mentors when they are
accepted into the archive. Because otb will have to pass the NEW queue
first, and this may take some time, please remove the otb package from
mentors yourself to avoid non-actionable TODO items on the team DMD page:

  
https://udd.debian.org/dmd/?email1=pkg-grass-devel%40lists.alioth.debian.org#todo

done.

Kind Regards,

Bas

Bug#809312: RFS: otb/5.2.0+dfsg-1 [ITP] -- Orfeo Toolbox

2015-12-29 Thread Rashad Kanavath 

Hi Ghislain,

debian policy for shared library says each library must be in a seperate 
package [1].


OTB is well modularaized since 5.0.0. This allows external apps or 
libaries to use have some of the otb libs not all


For instance,
monteverdi required only a small subset of libs:
  OTBApplicationEngine
  OTBQtWidget
  OTBImageIO
  OTBVectorDataIO
  OTBTestKernel
  OTBCarto
  OTBProjection
  OTBStatistics

So splitting a shared library is useful there. It also aslo true for 
remote modules. If anyone want to write a remote module that depends on 
two other modules OTBCommon, OTBTestKernel. he don't need to drag in all 
dependencies for that.


And in future otb may have more modules. If there is a problem with 
split up libraries, I can change it and make it simply libotb and libotb-dev


What do you think?

[1] https://www.debian.org/doc/debian-policy/ch-sharedlibs.html