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

Mario Ceresa mrceresa at gmail.com
Fri May 24 09:47:17 UTC 2013


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 at an3as.eu> 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 at sci.utah.edu>
> > Date: 22 May 2013 07:09
> > Subject: [Seg3D] Re: Packaging seg3d for Fedora - Problem with
> > boost::mutex
> > To: seg3d at 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_Libraries
> > >
> > > 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 at sci.utah.edu> 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&path=%2F&view=rev&root=seg3d2&revision=1834
> > >>>
> > >>>
> > >>> 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 at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/medical-sig
>
>
> --
> http://fam-tille.de
> _______________________________________________
> Medical-sig mailing list
> Medical-sig at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/medical-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/medical-sig/attachments/20130524/92542b06/attachment-0001.html>


More information about the Medical-sig mailing list