[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Plans for ITK version 4



BTW -- just to keep itk4 packaging going forward:  tried to build it on
sid, seems to build (32bit tools on 64bit kernel) but some tests
fail/segfault:

The following tests FAILED:
        589 - itkFFTWF_FFTTest (SEGFAULT)
        590 - itkFFTWF_RealFFTTest (SEGFAULT)
        591 - itkVnlFFTWF_FFTTest (SEGFAULT)
        592 - itkVnlFFTWF_RealFFTTest (SEGFAULT)
        595 - itkVnlFFTWD_FFTTest (SEGFAULT)
        596 - itkVnlFFTWD_RealFFTTest (SEGFAULT)
        1300 - itkVectorThresholdSegmentationLevelSetImageFilterTest (Failed)
        1327 - itkLevelSetsv4DenseImageBaseTest (Failed)
        1647 - itkSimpleImageRegistrationTest (Failed)
        1972 - itkOtsuThresholdImageFilterTestShort (Failed)
        2142 - DigitallyReconstructedRadiograph1Test (Failed)
Errors while running CTest
make[2]: *** [test] Error 8
make[2]: Leaving directory `/tmp/buildd/insighttoolkit4-4.0.0/BUILD'

is that something known?

NB that sid environment might be a bit outdated though...


On Sat, 28 Jan 2012, Steve M. Robbins wrote:

> On Sat, Jan 28, 2012 at 01:25:46PM -0500, Dominique Belhachemi wrote:
> > On Sat, Jan 28, 2012 at 4:43 AM, Steve M. Robbins <steve@sumost.ca> wrote:
> > > On Tue, Jan 24, 2012 at 08:38:44AM -0500, Dominique Belhachemi wrote:
> > >> Steve,

> > >> Thanks for all the work.

> > >> It would be good to have ITK4 in 'experimental'. Having coexisting
> > >> packages is nice to have but will cause probably too much trouble
> > >> (especially if we build all the language wrappers again)

> > > Since it's released, I was planning to upload straight to 'unstable'.
> > > Do you think there's a need to stage in 'experimental' first?

> > I think it is better to have ITK4 in experimental for one or two
> > weeks. This is just to be on the safe side, there are sometimes
> > unexpected problems with including cmake configuration files.

> I fully expect a number of problems with configuration.

> However, I see no problem with working this out in unstable rather 
> than experimental.  The new packages do not replace any existing
> ones and nothing will build-depend on the new packages at first.

> Can you explain what issue you see with working this out in unstable?

> Thanks,
> -Steve



-- 
=------------------------------------------------------------------=
Keep in touch                                     www.onerussian.com
Yaroslav Halchenko                 www.ohloh.net/accounts/yarikoptic


Reply to: