Fwd: [Seg3D] Re: Re: Re: Re: Packaging seg3d for Fedora - Problem with boost::mutex

[Mario Ceresa]

Dear all,
I had an interesting talk with Seg3D mantainers on the possibility to
accept patches to build against system version of the many bundled libs.
However, as you can see from the forwarded mails, they seem not willing to
help with that nor to accept any related patches. I'm not sure what to do
here: shall I package it regardless? I fear I'll end up mantaining a fork
of the program...

What would you suggest here?

Thanks and regards,

Mario

---------- Forwarded message ----------
From: Ayla Khan <ayla(a)sci.utah.edu&gt;
Date: 22 May 2013 07:09
Subject: [Seg3D] Re: Re: Re: Re: Packaging seg3d for Fedora - Problem with
boost::mutex
To: seg3d(a)sci.utah.edu


Hi Mario,

Many of the libraries we include with Seg3D have been modified, even if the
modifications are as basic as replacing their default builds with CMake and
doing some symbol mangling to make libraries play well with ITK. Our Boost
distribution includes a project from the Boost sandbox that will not be
available in a generic distribution. ITK has been customized as well.

Including specific versions of third-party libraries allows us to maintain
stable Seg3D builds across multiple platforms (Windows, Mac OSX and
different Linux distributions) with the least amount of effort for SCI
developers. We are also tightly coupled to Boost, ITK and Teem, so it is
preferable from our point of view to build against versions that we control.

Having a binary distribution for Fedora would be helpful - it's certainly
been a good thing for our Windows and OS X users, however keeping our
dependencies uniform across supported platforms has eliminated many of the
deployment headaches we used to have in the past.

Ayla

On May 7, 2013, at 3:27 AM, Mario Ceresa wrote:

>  Thanks Dan and Ayla for your prompt response! When do you plan to
> release 
2.1.5?
>  As for the 3rd party libs, unfortunately, Fedora has a strict policy
>  of not bundled and not static libs:
>  https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
>  
https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libr...
>  The only exceptions granted are usually for libraries that are heavily
>  modified. Does any of the 3rd party libs in "external" meet this?
>
>  Including seg3d in a distribution like Fedora it is usually a positive
>  force: it means a large user base, continuous feedback, builds ready
>  available for x86, arm and ppc archs, access to last releases of all
>  libs, prompt bug reports and many submitted patches. It also relieves
>  you part of the burden to assist users with bugs: package maintainers
>  will usually catch them up early and report to you, sometimes along
>  with a proposed fix. Thus you can concentrate more on working on your
>  software instead of all the maintenance tasks.
>
>  You can think about it as an investment :).
>
>  However, it needs a bit of involvement by your side because I cannot
>  maintain a complete fork of seg3d.
>
>  In the end I don't think the process is so complicated: we just need
>  to ensure we can choose at build time whether to link seg3d with the
>  included static libs or against system wide ones. I can send a patch
>  for this, if you are willing to review it. Then, if any
>  bugs/regression arises, we will work towards a fix.
>
>  I do hope that this would be the beginning of a long joint collaboration!
>
>  With best regards,
>
>  Mario
>
>
>
>
>
>
>
>  On 7 May 2013 07:07, Ayla Khan <ayla(a)sci.utah.edu&gt; wrote:
> > Hi Mario,
> >
> > You should check out the 2.1.5 release branch (
https://code.sci.utah.edu/svn/seg3d2/branches/2.1.5), or wait until I merge
the updates from the 2.1.5 release candidate back to the trunk once the
release is done. We're currently targeting a modified Boost 1.53.0 library
(see the Modifications.txt file in the src/Externals/boost directory). Keep
in mind that Seg3D is designed to work with statically linked libraries
built from the third-party dependencies that we include with it's sources
and does not support the use of other versions. I would strongly recommend
using our libraries and then attempting to work with Fedora's Qt system
libraries.
> >
> > Ayla
> >
> >
> > On May 6, 2013, at 12:42 PM, Dan White wrote:
> >
> >> Here is the fix for that error from our svn branch. Ayla can provide 
more
info, since it looks like there were multiple boost-upgrade-related
Seg3d2 source compiler fixes in addition to this one.
> >>
> >>
https://gforge.sci.utah.edu/gf/project/seg3d2/scmsvn/?action=browse&p...
> >>
> >> 
>>> On 5/6/2013 5:44 AM, Mario Ceresa wrote:
>>>> Hi all,
>>>> first of all, thank you for your work on seg3d: it's really a nice
>>>> software and helps a lot for image segmentation!
>>>>
>>>> I would like to package it for fedora, however, I have several build
>>>> problems. Once is especially difficult for me to figure out and I'd
>>>> appreciate some help.
>>>>
>>>> I have a:
>>>> * no matching function for call to
>>>>
‘boost::shared_lock<boost::shared_mutex>::swap(Core::MaskDataBlock::shared_lock_type)
> >>>
> >>> in Application/Filters/Actions/ActionAndFilter.cc:149. I past the full
> >>> compiler error:
> >>> * http://ur1.ca/dpo7o
> >>>
> >>> You can find in github a fork of the code with some of the changes so
far:
> >>> * https://github.com/mrceresa/seg3d2
> >>>
> >>> They are almost only in the cmake build system to enable use of Fedora
> >>> system-wide libs such as:
> >>>
> >>> * boost 1.50
> >>> * gdcm 2.0.18
> >>> * ITK 4.3.1
> >>>
> >>> Which is required for packaging.
> >>>
> >>> This was the cmake build line:
> >>> ccmake ../seg3d2 -DCMAKE_CXX_FLAGS="-fpermissive"
> >>> -DCMAKE_VERBOSE_MAKEFILE=ON -DBUILD_WITH_PYTHON=OFF
> >>>
> >>> Thanks for your attention and best regards,
> >>>
> >>> Mario Ceresa
> >>
> >

Fwd: [Seg3D] Re: Packaging seg3d for Fedora - Problem with boost::mutex

[Andreas Tille]

[Debian Med list in CC for further wisdom hints]

Hi Mario,

(I guess I should have read this before I have written my previous
answer.)  As a general answer there exists a so called Upstream Guide
in the Wiki

   http://wiki.debian.org/UpstreamGuide

IMHO everything written there should also apply for Fedora.  I'm
personally astonished that the topic of bundled libraries is not (yet)
mentioned there.  I'll suggest the authors of this guide to include this
topic.

On Wed, May 22, 2013 at 01:15:33PM +0200, Mario Ceresa wrote:
>  Dear all,
>  I had an interesting talk with Seg3D mantainers on the possibility to
>  accept patches to build against system version of the many bundled libs.
>  However, as you can see from the forwarded mails, they seem not willing to
>  help with that nor to accept any related patches. I'm not sure what to do
>  here: shall I package it regardless? I fear I'll end up mantaining a fork
>  of the program...
>  
>  What would you suggest here? 
I admit that's a pretty bad situation.  We just have some packages where
upstream includes third party software and we were not lucky enough to
convince them about droping it (even if constantly talking to them for
every new version).  However, I do not remember any case where really
widely used, large projects like boost or itk are affected by this
problem.  That's really bad and I admit I do not have a reasonable
answer to this.  For the moment I would regard this as a show stopper
and move to another package on your list.

I personally would not consider to maintain a clean fork if this is more
than say up to ten easily maintainable / automatically generatable
patches.  Finally your version will be way less tested and once users
might learn that "the Fedora packages of medical imaging are broken"
(yes, they might do this generalisation even if this is not true) this
might affect your whole project.

We might like to do another try from Debian Med side.  Perhaps upstream
might start thinking about it if two major distributions will not
consider something that would be in their interest ...

Kind regards

       Andreas.

>  ---------- Forwarded message ----------
>  From: Ayla Khan <ayla(a)sci.utah.edu&gt;
>  Date: 22 May 2013 07:09
>  Subject: [Seg3D] Re: Packaging seg3d for Fedora - Problem with
>  boost::mutex
>  To: seg3d(a)sci.utah.edu
>  
>  
>  Hi Mario,
>  
>  Many of the libraries we include with Seg3D have been modified, even if the
>  modifications are as basic as replacing their default builds with CMake and
>  doing some symbol mangling to make libraries play well with ITK. Our Boost
>  distribution includes a project from the Boost sandbox that will not be
>  available in a generic distribution. ITK has been customized as well.
>  
>  Including specific versions of third-party libraries allows us to maintain
>  stable Seg3D builds across multiple platforms (Windows, Mac OSX and
>  different Linux distributions) with the least amount of effort for SCI
>  developers. We are also tightly coupled to Boost, ITK and Teem, so it is
>  preferable from our point of view to build against versions that we control.
>  
>  Having a binary distribution for Fedora would be helpful - it's certainly
>  been a good thing for our Windows and OS X users, however keeping our
>  dependencies uniform across supported platforms has eliminated many of the
>  deployment headaches we used to have in the past.
>  
>  Ayla
>  
>  On May 7, 2013, at 3:27 AM, Mario Ceresa wrote:
>  
>  > Thanks Dan and Ayla for your prompt response! When do you plan to release
>  2.1.5?
>  >
>  > As for the 3rd party libs, unfortunately, Fedora has a strict policy
>  > of not bundled and not static libs:
>  > https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
>  >
>  https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libr...
>  >
>  > The only exceptions granted are usually for libraries that are heavily
>  > modified. Does any of the 3rd party libs in "external" meet this?
>  >
>  > Including seg3d in a distribution like Fedora it is usually a positive
>  > force: it means a large user base, continuous feedback, builds ready
>  > available for x86, arm and ppc archs, access to last releases of all
>  > libs, prompt bug reports and many submitted patches. It also relieves
>  > you part of the burden to assist users with bugs: package maintainers
>  > will usually catch them up early and report to you, sometimes along
>  > with a proposed fix. Thus you can concentrate more on working on your
>  > software instead of all the maintenance tasks.
>  >
>  > You can think about it as an investment :).
>  >
>  > However, it needs a bit of involvement by your side because I cannot
>  > maintain a complete fork of seg3d.
>  >
>  > In the end I don't think the process is so complicated: we just need
>  > to ensure we can choose at build time whether to link seg3d with the
>  > included static libs or against system wide ones. I can send a patch
>  > for this, if you are willing to review it. Then, if any
>  > bugs/regression arises, we will work towards a fix.
>  >
>  > I do hope that this would be the beginning of a long joint collaboration!
>  >
>  > With best regards,
>  >
>  > Mario
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  > On 7 May 2013 07:07, Ayla Khan <ayla(a)sci.utah.edu&gt; wrote:
>  >> Hi Mario,
>  >>
>  >> You should check out the 2.1.5 release branch (
>  https://code.sci.utah.edu/svn/seg3d2/branches/2.1.5), or wait until I merge
>  the updates from the 2.1.5 release candidate back to the trunk once the
>  release is done. We're currently targeting a modified Boost 1.53.0 library
>  (see the Modifications.txt file in the src/Externals/boost directory). Keep
>  in mind that Seg3D is designed to work with statically linked libraries
>  built from the third-party dependencies that we include with it's sources
>  and does not support the use of other versions. I would strongly recommend
>  using our libraries and then attempting to work with Fedora's Qt system
>  libraries.
>  >>
>  >> Ayla
>  >>
>  >>
>  >> On May 6, 2013, at 12:42 PM, Dan White wrote:
>  >>
>  >>> Here is the fix for that error from our svn branch. Ayla can provide
>  more info, since it looks like there were multiple boost-upgrade-related
>  Seg3d2 source compiler fixes in addition to this one.
>  >>>
>  >>>
>
> https://gforge.sci.utah.edu/gf/project/seg3d2/scmsvn/?action=browse&p...
>  >>>
>  >>>
>  >>> On 5/6/2013 5:44 AM, Mario Ceresa wrote:
>  >>>> Hi all,
>  >>>> first of all, thank you for your work on seg3d: it's really a nice
>  >>>> software and helps a lot for image segmentation!
>  >>>>
>  >>>> I would like to package it for fedora, however, I have several build
>  >>>> problems. Once is especially difficult for me to figure out and I'd
>  >>>> appreciate some help.
>  >>>>
>  >>>> I have a:
>  >>>> * no matching function for call to
>  >>>>
>
> ‘boost::shared_lock<boost::shared_mutex>::swap(Core::MaskDataBlock::shared_lock_type)
>  >>>>
>  >>>> in Application/Filters/Actions/ActionAndFilter.cc:149. I past the full
>  >>>> compiler error:
>  >>>> * http://ur1.ca/dpo7o
>  >>>>
>  >>>> You can find in github a fork of the code with some of the changes so
>  far:
>  >>>> * https://github.com/mrceresa/seg3d2
>  >>>>
>  >>>> They are almost only in the cmake build system to enable use of Fedora
>  >>>> system-wide libs such as:
>  >>>>
>  >>>> * boost 1.50
>  >>>> * gdcm 2.0.18
>  >>>> * ITK 4.3.1
>  >>>>
>  >>>> Which is required for packaging.
>  >>>>
>  >>>> This was the cmake build line:
>  >>>> ccmake ../seg3d2 -DCMAKE_CXX_FLAGS="-fpermissive"
>  >>>> -DCMAKE_VERBOSE_MAKEFILE=ON -DBUILD_WITH_PYTHON=OFF
>  >>>>
>  >>>> Thanks for your attention and best regards,
>  >>>>
>  >>>> Mario Ceresa
>  >>>
>  >> 
>  _______________________________________________
>  Medical-sig mailing list
>  Medical-sig(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/medical-sig 

-- 
http://fam-tille.de

Fwd: [Seg3D] Re: Packaging seg3d for Fedora - Problem with boost::mutex

[Mario Ceresa]

Hi Andreas,

I agree with you that forking the project is a bad idea. I'll tell Seg3D
maintainers that I step back from packaging it, at least until we can think
of a good way to handle the dependencies.

It's a pity, because I still think that Seg3d is a nice software and a much
needed one to easy create segmentations. I'll concentrate next on itksnap
instead (http://www.itksnap.org/pmwiki/pmwiki.php) and look at debian's
patches once more :)

Thanks for the kind response,

Best,

Mario

PS: Should you get in touch with Seg3d maintainers and they be willing to
change their policy, please tell me so I can resume packaging.

PPS: If anyone is curious, Fedora's package guidelines are available here (
http://fedoraproject.org/wiki/Packaging:Guidelines)



On 23 May 2013 17:34, Andreas Tille <andreas(a)an3as.eu&gt; wrote:

>  [Debian Med list in CC for further wisdom hints]
>
>  Hi Mario,
>
>  (I guess I should have read this before I have written my previous
>  answer.)  As a general answer there exists a so called Upstream Guide
>  in the Wiki
>
>     http://wiki.debian.org/UpstreamGuide
>
>  IMHO everything written there should also apply for Fedora.  I'm
>  personally astonished that the topic of bundled libraries is not (yet)
>  mentioned there.  I'll suggest the authors of this guide to include this
>  topic.
>
>  On Wed, May 22, 2013 at 01:15:33PM +0200, Mario Ceresa wrote:
>  > Dear all,
>  > I had an interesting talk with Seg3D mantainers on the possibility to
>  > accept patches to build against system version of the many bundled libs.
>  > However, as you can see from the forwarded mails, they seem not willing
>  to
>  > help with that nor to accept any related patches. I'm not sure what to do
>  > here: shall I package it regardless? I fear I'll end up mantaining a fork
>  > of the program...
>  >
>  > What would you suggest here?
>
>  I admit that's a pretty bad situation.  We just have some packages where
>  upstream includes third party software and we were not lucky enough to
>  convince them about droping it (even if constantly talking to them for
>  every new version).  However, I do not remember any case where really
>  widely used, large projects like boost or itk are affected by this
>  problem.  That's really bad and I admit I do not have a reasonable
>  answer to this.  For the moment I would regard this as a show stopper
>  and move to another package on your list.
>
>  I personally would not consider to maintain a clean fork if this is more
>  than say up to ten easily maintainable / automatically generatable
>  patches.  Finally your version will be way less tested and once users
>  might learn that "the Fedora packages of medical imaging are broken"
>  (yes, they might do this generalisation even if this is not true) this
>  might affect your whole project.
>
>  We might like to do another try from Debian Med side.  Perhaps upstream
>  might start thinking about it if two major distributions will not
>  consider something that would be in their interest ...
>
>  Kind regards
>
>         Andreas.
>
>  > ---------- Forwarded message ----------
>  > From: Ayla Khan <ayla(a)sci.utah.edu&gt;
>  > Date: 22 May 2013 07:09
>  > Subject: [Seg3D] Re: Packaging seg3d for Fedora - Problem with
>  > boost::mutex
>  > To: seg3d(a)sci.utah.edu
>  >
>  >
>  > Hi Mario,
>  >
>  > Many of the libraries we include with Seg3D have been modified, even if
>  the
>  > modifications are as basic as replacing their default builds with CMake
>  and
>  > doing some symbol mangling to make libraries play well with ITK. Our
>  Boost
>  > distribution includes a project from the Boost sandbox that will not be
>  > available in a generic distribution. ITK has been customized as well.
>  >
>  > Including specific versions of third-party libraries allows us to
>  maintain
>  > stable Seg3D builds across multiple platforms (Windows, Mac OSX and
>  > different Linux distributions) with the least amount of effort for SCI
>  > developers. We are also tightly coupled to Boost, ITK and Teem, so it is
>  > preferable from our point of view to build against versions that we
>  control.
>  >
>  > Having a binary distribution for Fedora would be helpful - it's certainly
>  > been a good thing for our Windows and OS X users, however keeping our
>  > dependencies uniform across supported platforms has eliminated many of
>  the
>  > deployment headaches we used to have in the past.
>  >
>  > Ayla
>  >
>  > On May 7, 2013, at 3:27 AM, Mario Ceresa wrote:
>  >
>  > > Thanks Dan and Ayla for your prompt response! When do you plan to
>  release
>  > 2.1.5?
>  > >
>  > > As for the 3rd party libs, unfortunately, Fedora has a strict policy
>  > > of not bundled and not static libs:
>  > > https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
>  > >
>  >
>  https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libr...
>  > >
>  > > The only exceptions granted are usually for libraries that are heavily
>  > > modified. Does any of the 3rd party libs in "external" meet this?
>  > >
>  > > Including seg3d in a distribution like Fedora it is usually a positive
>  > > force: it means a large user base, continuous feedback, builds ready
>  > > available for x86, arm and ppc archs, access to last releases of all
>  > > libs, prompt bug reports and many submitted patches. It also relieves
>  > > you part of the burden to assist users with bugs: package maintainers
>  > > will usually catch them up early and report to you, sometimes along
>  > > with a proposed fix. Thus you can concentrate more on working on your
>  > > software instead of all the maintenance tasks.
>  > >
>  > > You can think about it as an investment :).
>  > >
>  > > However, it needs a bit of involvement by your side because I cannot
>  > > maintain a complete fork of seg3d.
>  > >
>  > > In the end I don't think the process is so complicated: we just need
>  > > to ensure we can choose at build time whether to link seg3d with the
>  > > included static libs or against system wide ones. I can send a patch
>  > > for this, if you are willing to review it. Then, if any
>  > > bugs/regression arises, we will work towards a fix.
>  > >
>  > > I do hope that this would be the beginning of a long joint
>  collaboration!
>  > >
>  > > With best regards,
>  > >
>  > > Mario
>  > >
>  > >
>  > >
>  > >
>  > >
>  > >
>  > >
>  > > On 7 May 2013 07:07, Ayla Khan <ayla(a)sci.utah.edu&gt; wrote:
>  > >> Hi Mario,
>  > >>
>  > >> You should check out the 2.1.5 release branch (
>  > https://code.sci.utah.edu/svn/seg3d2/branches/2.1.5), or wait until I
>  merge
>  > the updates from the 2.1.5 release candidate back to the trunk once the
>  > release is done. We're currently targeting a modified Boost 1.53.0
>  library
>  > (see the Modifications.txt file in the src/Externals/boost directory).
>  Keep
>  > in mind that Seg3D is designed to work with statically linked libraries
>  > built from the third-party dependencies that we include with it's sources
>  > and does not support the use of other versions. I would strongly
>  recommend
>  > using our libraries and then attempting to work with Fedora's Qt system
>  > libraries.
>  > >>
>  > >> Ayla
>  > >>
>  > >>
>  > >> On May 6, 2013, at 12:42 PM, Dan White wrote:
>  > >>
>  > >>> Here is the fix for that error from our svn branch. Ayla can provide
>  > more info, since it looks like there were multiple boost-upgrade-related
>  > Seg3d2 source compiler fixes in addition to this one.
>  > >>>
>  > >>>
>  >
>
> https://gforge.sci.utah.edu/gf/project/seg3d2/scmsvn/?action=browse&p...
>  > >>>
>  > >>>
>  > >>> On 5/6/2013 5:44 AM, Mario Ceresa wrote:
>  > >>>> Hi all,
>  > >>>> first of all, thank you for your work on seg3d: it's really a
> nice
>  > >>>> software and helps a lot for image segmentation!
>  > >>>>
>  > >>>> I would like to package it for fedora, however, I have several
> build
>  > >>>> problems. Once is especially difficult for me to figure out and
> I'd
>  > >>>> appreciate some help.
>  > >>>>
>  > >>>> I have a:
>  > >>>> * no matching function for call to
>  > >>>>
>  >
>
> ‘boost::shared_lock<boost::shared_mutex>::swap(Core::MaskDataBlock::shared_lock_type)
>  > >>>>
>  > >>>> in Application/Filters/Actions/ActionAndFilter.cc:149. I past the
>  full
>  > >>>> compiler error:
>  > >>>> * http://ur1.ca/dpo7o
>  > >>>>
>  > >>>> You can find in github a fork of the code with some of the changes
>  so
>  > far:
>  > >>>> * https://github.com/mrceresa/seg3d2
>  > >>>>
>  > >>>> They are almost only in the cmake build system to enable use of
>  Fedora
>  > >>>> system-wide libs such as:
>  > >>>>
>  > >>>> * boost 1.50
>  > >>>> * gdcm 2.0.18
>  > >>>> * ITK 4.3.1
>  > >>>>
>  > >>>> Which is required for packaging.
>  > >>>>
>  > >>>> This was the cmake build line:
>  > >>>> ccmake ../seg3d2 -DCMAKE_CXX_FLAGS="-fpermissive"
>  > >>>> -DCMAKE_VERBOSE_MAKEFILE=ON -DBUILD_WITH_PYTHON=OFF
>  > >>>>
>  > >>>> Thanks for your attention and best regards,
>  > >>>>
>  > >>>> Mario Ceresa
>  > >>>
>  > >>
>
>  > _______________________________________________
>  > Medical-sig mailing list
>  > Medical-sig(a)lists.fedorahosted.org
>  > https://lists.fedorahosted.org/mailman/listinfo/medical-sig
>
>
>  --
>  http://fam-tille.de
>  _______________________________________________
>  Medical-sig mailing list
>  Medical-sig(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/medical-sig
>