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