Hello Mathieu,
I installed the tbb version from experimental and can confirm that all
test in MIA run through, i.e. this version of tbb fixes the bug.
Best regards
signature.asc
Description: This is a digitally signed message part
I tried the new package, and one test fails to build on powerpc (sid, g
++ 4.6.4). The solution could be to replace the __sync_* calls by
__atomic_* calls (like in #708929)
The packages are build though, and the new version seems to fix
#705385.
[...]
g++ -o test_atomic_compiler_builtins.exe
package src:mialmpick
block 713551 by 709554
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
The bug most likely does result from switching from the configure based
build system to the CMake based build system.
As a result, also the pkg-config files (itpp*.pc) are no longer created
and therefore, also not installed.
Gert
--
To UNSUBSCRIBE, email to
On Sat, 2013-06-22 at 15:12 +0200, David Suárez wrote:
Source: mia
Version: 2.0.9-1
Severity: serious
Tags: jessie sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20130620 qa-ftbfs
Justification: FTBFS on amd64
Hi,
During a rebuild of all packages in sid, your package failed
Hello,
yes I did rebuild mia yesterday in an updated sid installation
successfully.
many thanks,
Gert
signature.asc
Description: This is a digitally signed message part
On Sat, 2013-04-13 at 23:02 -0400, Aaron M. Ucko wrote:
207/228 Test #212: 3d-transform-rotation Passed0.40 sec
Start 213: 3d-transform-spline
Is this build run on a multi-core machine? The build log somehow
suggests it is.
I've seen something similar before on my
At least one of mia's source files requires SSE (x86) or Altivec
(PowerPC) support:
.../mia-2.0.8/mia/3d/reg3d/navierasse.cc:387:2: error: #error need SSE or
ALTIVEC support
I think it is better when I restrict the architectures where the module
is build - currently I already do this for
The fixes are already in the pipeline, but I was told that one should
wait with a new upload until the package has been approved by
ftpmaster.
Best
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
I can confirm that the test hangs on powerpc if more then one thread is
used. The problem seems to lie somewhere in the thread cleanup routines
of TBB, i.e. the parallel code of MIA is run, and then
tbb::parallel_reduce/tbb:parallel_for do not return.
According to the changelog the TBB release
The bug does not occur with the latest version of TBB (4.1 Update 2) .
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Package: libtbb2
Version: 4.0+r233-1
Severity: normal
Tags: upstream, patch
Dear Maintainer,
on PowerPC the functions parallel_for and parallel_reduce may run
forever.
Specifically, they may hang in the cleanup routines that are called
after the
user provided callbacks are run.
This problem
I found a very crude fix for teh current version of TBB that needs to be
refined and fixes this bug (See blocking bug).
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
The code hangs in a call to atomic_backoff::pause that the main thread
initiated from __TBB_FetchAndStoreGeneric because a call to
__TBB_CompareAnsdSwapGeneric fails.
It seems that by replacing the latter with the new 4.1 version would fix
the bug, but it introduces a change of the call
fixes a lockup that may happen in the exit routines of
parallel_for and parallel_reduce.
.
Author: Gert Wollny gw.foss...@gmail.com
---
Origin: other
Bug-Debian: http://bugs.debian.org/705495
Forwarded: not-needed
Last-Update: 2013-04-16
--- tbb-4.0+r233.orig/include/tbb/tbb_machine.h
+++ tbb-4.0
On Mon, 2013-04-15 at 10:29 -0400, Aaron M. Ucko wrote:
We're too deep into the wheezy freeze for TBB's
maintainers to upload a new upstream version into unstable, but
cherry-picked patches might qualify for a freeze exemption.
The manageable small fix I found and posted in bug 705495
Package: libnlopt-dev
Version: 2.2.4+dfsg-2
Severity: normal
Tags: patch
Dear Maintainer,
upstream provides a nlopt.pc file that should be provided by the devel
package. The attached patch against the debian directory fixes this
problem.
-- System Information:
Debian Release: wheezy/sid
APT
Package: wnpp
Severity: wishlist
Owner: Gert Wollnygw.foss...@gmail.com
* Package name: vistaio
Version : 1.2.14
Upstream Author : Gert Wollnygw.foss...@gmail.com,
(abandoned by original author Arthur Popep...@cs.ubc.ca)
* URL
Package: wnpp
Severity: wishlist
Owner: Gert Wollny gw.foss...@gmail.com
* Package name: mia
Version : 2.0.6
Upstream Author : Gert Wollny gw.foss...@gmail.com,
* URL : https://sourceforge.net/projects/mia/files/mia/2.0.6/
DEBs : https://launchpad.net/~gert-die/+archive/ppa
Package: wnpp
Severity: wishlist
Owner: Gert Wollny gw.foss...@gmail.com
* Package name: mialm
Version : 1.0.6
Upstream Author : Gert Wollny gw.foss...@gmail.com,
* URL : https://sourceforge.net/projects/mia/files/lmpick/0.2.4/
DEBs : https://launchpad.net/~gert-die/+archive
Package: wnpp
Severity: wishlist
Owner: Gert Wollny gw.foss...@gmail.com
* Package name: mialmpick
Version : 0.2.4
Upstream Author : Gert Wollny gw.foss...@gmail.com,
* URL : https://sourceforge.net/projects/mia/files/lmpick/0.2.4/
DEBs : https://launchpad.net/~gert-die
Package: wnpp
Severity: wishlist
Owner: Gert Wollny gw.foss...@gmail.com
* Package name: pymia
Version : 0.1.2
Upstream Author : Gert Wollny gw.foss...@gmail.com,
* URL : https://sourceforge.net/projects/mia/files/mia/2.0.6/
DEBs : https://launchpad.net/~gert-die/+archive/ppa
Package: wnpp
Severity: wishlist
Owner: Gert Wollny gw.foss...@gmail.com
* Package name: viewitgui
Version : 2.0.2
Upstream Author : Gert Wollny gw.foss...@gmail.com,
* URL : https://sourceforge.net/projects/mia/files/mia/2.0.6/
DEBs : https://launchpad.net/~gert-die/+archive
Hi,
here the configure script claims that f2c is added anyway:
[AC_MSG_RESULT(not found, trying to use -lf2c anyway.)]
but then it does this (and the patch doesn't touch that line):
LDFLAGS=${LDFLAGS}
which should read (just like the in the BLAS test below)
LDFLAGS=${LDFLAGS}
Hello,
it seems the attached patch solves the problem (Building at 95% way
beyond where it failed before).
Actually, it is commit 1e76c9 in the ball git repro
https://bitbucket.org/ball/ball
Cheers,
Gert
From 1e76c9cb1920e9176b725269985c7eb43126d188 Mon Sep 17 00:00:00 2001
From: Luis de
Bad news is now compiling fails with:
/home/wollny/Debian/ball/build/source/PYTHON/EXTENSIONS/VIEWmodule/sipVIEWpart0.cpp:
In member function 'virtual void sipDatasetControl::destroy()':
/home/wollny/Debian/ball/build/source/PYTHON/EXTENSIONS/VIEWmodule/sipVIEWpart0.cpp:2981:9:
error:
Thanks for the patch. Since I'm also the upstream author I will
incorporated it in the next upstream release.
Best
Gert
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
gdcm FTBFS on powerpc with:
| cd /«PKGBUILDDIR»/obj-powerpc-linux-gnu/Utilities/VTK /usr/bin/gccxml ...
This is gccxml going boom. gccxml is used as a processing step to create
language bindings.
| namespace std
| {
| inline namespace __gnu_cxx_ldbl128 { }
| }
AFAIK the parser used by
Because the headers that were included I overlooked that the bug is
against GDCM and not VTK, so moving to a new version might not be an
option. The note on gccxml stands, of course.
best
Gert
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of
Hi,
I would look into packaging the software and ask on debian-med for
sponsoring, but only after Easter - in case someone else has time and
wants to step forward with the packaging.
I've seen that the latest versions are 0.7.1.post1 and 0.8rc1. I would
ask you to stick to a version
Hi,
You are referring to versioning of the tar balls found on SourceForge?
http://sourceforge.net/projects/simpleitk/files/SimpleITK/
Yes.
The numbering is only important for releases, at least I will not
package anything else.
A typical watch file entry for sourceforge looks like
Package: wnpp
Severity: wishlist
* Package name: maxflow
Version : 3.03
Upstream Author : Vladimir Kolmogorov and Yuri Boykov
* URL : http://pub.ist.ac.at/~vnk/software.html
* License : GPL3+
Programming Lang: C++
Description : This library implements the
I looked a bit on how the tables are addressed and it seems they only
use normal c-array indexing (and not some wired pointer arithmetic).
Therefore, I'm quite confident that the element Padding is indeed not
more than an explicit way to pad the structure to have a nice size.
Given that
Package: debian-maintainers
Severity: normal
Please add Gert Wollny to the Debian Maintainers keyring.
The jetring changeset is attached.
many thanks.
Gert
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture
Hi,
I've uploaded the patch to the debian-med git repository.
Since the original version of plplot doesn't contain the padding I'm
quite confident that it only needs to be consistent and the actual value
is of no further consequence (besides possible optimizations).
For the emboss team: the
The significant error is
/usr/share/gccxml-0.9/GCC/4.9/bits/stl_algo.h: In function
'_OutputIterator std::__unique_copy(_InputIterator, _InputIterator,
_OutputIterator, _BinaryPredicate, std::input_iterator_tag,
std::output_iterator_tag)':
/usr/share/gccxml-0.9/GCC/4.9/bits/stl_algo.h:1086:
Mmm. I think that's wishful thinking on the part of rock-dev. We
already have the latest git of gccxml (referenced in the above)
packaged and it was used in the build that failed.
I see, I've added a note the related upstream bug
http://www.gccxml.org/Bug/view.php?id=14912
best,
Gert
insighttoolkit4 repeatedly FTBFS on amd64 [1] because of ENOSPC. A
manual build on porterbox barriere.debian.org reported a need of ~44GB
while it failed on buildd barber at approx 37GB of disk space.
There are two things that could probably help:
- change the python-binding dimensions to
There must be something wrong with your setup because what is failing is
a plain CC compile command
/usr/bin/cc
that should never include the files from
/usr/share/gccxml-0.9/GCC/4.9/
as it does in this build.
Besides, from the compiler flags SSE is not enabled, and unless g++-4.9
on i386
My bad, I got irritated by the parallel build. The failing command seems
to be
/usr/bin/gccxml -fxml-start=_cable_
-fxml=/«PKGBUILDDIR»/BUILD/Wrapping/Modules/ITKCommon/vcl_complex.xml
--gccxml-gcc-options
/«PKGBUILDDIR»/BUILD/Wrapping/Modules/ITKCommon/gcc_xml.inc -DCSWIG
Il Mercoledì 2 Luglio 2014 13:15, Gert Wollny gw.foss...@gmail.com
The failing command seems to be
/usr/bin/gccxml -fxml-start=_cable_
-fxml=/«PKGBUILDDIR»/BUILD/Wrapping/Modules/ITKCommon/vcl_complex.xml
--gccxml-gcc-options
/«PKGBUILDDIR»/BUILD/Wrapping/Modules/ITKCommon/gcc_xml.inc
On Tue, 2014-07-15 at 23:14 +0200, Andreas Tille wrote:
[...]
I could do the sponsering if needed. Please confirm that
debian/makeSource.sh really fetches the source you are working on.
I also think *if* I would do the upload and nobody would beat me
I would switch to xz compression for the
Today I hit the same problem (after the dist-upgrade introduced
systemd). I also had a device listed in /etc/fstab that is not always
available and I forgot to add the noauto option.
Well, the system does boot, but it drops you into the emergency shell
where you can inspect the problem.
At
Source: double-conversion
Version: Package should generate and install *.cmake files
Severity: normal
Dear Maintainer,
the package is prepared to provide various *.cmake files that can be used by
third party libraries using cmake to find the required information about the
location of library
Hello,
I guess this is also a transitional problem and will try to rebuild later
this week before I'll close the bug.
I'm afraid it's more complicated. ITK exposes various libraries via the
ITKTargets-none,cmake files, amongst these htf5.so and libfftw3.so -
even though these libraries should
Hello Andreas,
It's actually way more simple since it can be explained by me beeing
stupid enough to rebuild 4.7-1 (which actually had the fftw3 problem)
instead of the current 4.7-2 which builds nicely.
Me too, and I saw that as of 4.7-2 elastix has libfftw3-dev as build
dependency.
Still,
The new driver 14.9 is out [1] and according to Phoronix it should
support xorg-video-abi-18 [2].
[1] http://support.amd.com/en-us/download/embedded?os=Linux
+x86rev=13.151
[2] http://www.phoronix.com/scan.php?page=news_itempx=MTc4NTQ
best regards,
Gert
signature.asc
Description: This is a
the config menu
appeared on screen 0 also for applets running on sereen 1.
This patch corrects this by setting the screen apropriately.
Author: Gert Wollny gw.foss...@gmail.com
Bug: https://github.com/mate-desktop/mate-panel/issues/234
Last-Update: 2014-09-18
--- mate-panel-1.8.0+dfsg1.orig
Hello Paul,
in Debian we are currently at ITK 4.6 and VTK 6.1 and AFAICS this is
what will go into Jessie. Hence, if you could get a version released
that can be compiled with these two libraries, we could update it,
Note however, that the freeze for Jessie is only a few weeks away.
Here is
Hello Paul,
On Tue, 2014-10-21 at 04:45 -0400, Paul Yushkevich wrote:
I am going to try looking into this problem this week. I have been building
on Centos, and there the Qt plugins are being picked up just fine. I
suspect the crash is due to the missing plugin, but I am not sure.
The crash
On Tue, 2014-10-21 at 06:31 -0400, Paul Yushkevich wrote:
A quick question about the plugins: when you build with Cmake, did you have
CMAKE_PREFIX_PATH set to point to the Qt5's lib/cmake directory? I think
this is the way the plugins get picked up.
No, I didn't.
signature.asc
... Oddly, this happens in
Debian but not other OSs.
Hope I can find a fix :)
On Tue, Oct 21, 2014 at 6:38 AM, Gert Wollny gw.foss...@gmail.com wrote:
On Tue, 2014-10-21 at 06:31 -0400, Paul Yushkevich wrote:
A quick question about the plugins: when you build with Cmake, did you
On Tue, 2014-10-21 at 07:49 -0400, Paul Yushkevich wrote:
Ok - it was an easy fix. I just checked it into dev32. Gert - could you
please confirm that the code runs and builds now?
Okay, when I can build it with the patches applied (disabling the search
for the plug-ins with cmake and added
On Thu, 2014-10-23 at 16:50 +0200, Michael Hanke wrote:
On Thu, Oct 23, 2014 at 10:43:56AM -0400, Paul Yushkevich wrote:
The file is here:
/usr/lib/x86_64-linux-gnu/cmake/Qt5/Qt5Config.cmake
I'd like to chime in that
grep -R QXcb *
in the according directory does not yield any
A few comments.
I'm not sure if the disassembly is the right one. Supposedly it is in a
function called fftwf_guru64_kosherp, but it should be in
really_have_neon.
There I would expect that the actual disassembly results in the the
signal SIGILL not being reset and return 1 always being
On Wed, 2014-10-29 at 18:36 +0100, Julian Taylor wrote:
the flags are only added to files which do the computations, the rest
of the program should not have this flag, this should include the file
that has the neon runtime check.
Makes sense, but then adding an intrinsic should be okay.
Package: systemd
Version: 215-5+b1
Severity: wishlist
Dear Maintainer,
currently in /etc/sysctl.d/99-sysctl.conf provided by the systemd
package ipv6 seems to be disabled by default i.e.
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
Hello,
On Mon, 2015-02-02 at 07:51 +0100, Andreas Tille wrote:
Hi Mentors,
It is very important to build vsearch with the maximum optimisation for speed
and thus I wonder whether dropping this option is a good idea or whether
I should enable it on i386 and amd64 (the question extends also
Hello,
I've now upload the latest changes, with that the package should be okay
for upload.
Additional changes:
* eliminated lintian warning: menu-icon-uses-relative-path
* added watch file
* corrected dependencies
* builds in sid pbuilder amd64
There are still some lintian info
Hi Michael,
They look like they need to be forwarded upstream, but should not hold up
an upload.
The spelling error needs to be forwarded.
Since I had to touch the package anyway, I now corrected the other two.
- I'd target experimental not unstable (solely for not causing problems
with
Hello all,
now that Paul provided an official upstream tarball I took the liberty
to update the itksnap package to version 3.2.0 in the packaging git on
alioth. There is still a lintian warning about
menu-icon-uses-relative-path
and some warnings about NMU, because currently my name is
Hi,
I started with the package. I hope some day next week it will be ready
for upload.
I'd change the vtk dependency to vtk6, because itksnap already requires
this and will link both packages, and I'd add ITK_WRAP_unsigned_long
because some filters require it for the python bindings.
Best,
The problem with these files is that they are listed in
one of the cmake files installed by vtk6 into /usr/lib/cmake/vtk-6.1,
e.g.,
VTKTargets-none.cmake:
IMPORTED_LOCATION_NONE
/usr/lib/x86_64-linux-gnu/python2.7/site-packages/vtk/vtkCommonExecutionModelPython.so
IMPORTED_SONAME_NONE
The package requires libmdc2, which is the library provided by the
xmedcon project, so there is a relation.
Considering the suggestion of (x)medcon one might add that amide does
also not suggest dcmtk (another set of command line tools for
manipulating DICOM files) even though it also has dicom
all changes pushed.
The new boost.m4 solved my problem, but adding the libraries in the link
dependencies was still needed.
The package builds and the boost libraries are also linked. BTW it was
_LIBS not _LIB, so no AC_SUBST needed.
However, building a package I got another error
On 13.08.2015 18:17, Andreas Tille wrote:
I confirm that this at least has some effect - unfortunately not the wanted
one sinde the
@BOOST_FILESYSTEM_LIB@ @BOOST_IOSTREAMS_LIB@ @BOOST_SYSTEM_LIB@
placeholders remain unresolved and the $(DEPS_LIBS) variable remains
empty. :_(
After
On 17.08.2015 09:14, Andreas Tille wrote:
I wonder whether there is some boost.m4 we could steal somewhere. Kind
regards Andreas.
Well, there is upstream
https://github.com/tsuna/boost.m4
I will now try with this one. Andreas, I you didn't push your changes,
right?
On 15.08.2015 16:54, Andreas Tille wrote:
This is something I somehow suspected - but *what* dependency?
gregor pointed at freecontact, and indeed freecontac.h from
libfreecontact0-dev exposes the std::string in the class predictor.
Best
On 15.08.2015 16:02, Andreas Tille wrote:
Hi Perl team,
I admit I have no idea how to fix this. It somehow smells like a gcc-5
issue but I'm not sure.
Most likely, the missing symbol (below) points to cxx11::std::string
which comes from the g++11 dual ABI, which means some dependency needs
On Thu, 2015-07-23 at 14:36 +0200, Andreas Tille wrote:
Hi,
considering the fact that SSE3 optimisation is really wanted on intel
architectures how could the option be added only for those architectures
that understand -msse3 option?
You can do this:
###
include(CheckCXXCompilerFlag)
Hi,
it seems that running Xnest with the -nocursor option is a workaround. I
didn't test it extensively, but I was able to open two screens with
xterms and copy from one to the other screen.
I was not able to debug it on Debian, because there I didn't have debug
information available, but on
Hello Andreas,
On the contrary users want to get the best performance from their recent
processors
I certainly can understand this ...
Is there any better place to help upstream implementing it?
This looks quite interesting:
https://gcc.gnu.org/wiki/FunctionMultiVersioning
It also
Hello Daniele,
On Thu, 2015-10-29 at 17:30 +0100, Daniele E. Domenichelli wrote:
> building the package with
>
> -DCMAKE_CXX_FLAGS=-D_GLIBCXX_USE_CXX11_ABI=0
>
> fixes this issue for me.
>
> Anyway I'm not sure whether the real issue is in this package or in
> libgccxml-dev that is built
Package: libdcmtk-dev
Version: 3.6.1~20150629-3
Severity: normal
The generated files DCMTKTargets*.cmake list executables that are either not
installed at all (/usr/bin/*_tests), or moved to another location
(/usr/lib/dcmtk/cgi-bin/).
However, packages like insighttoolkit4 use the information
On Mon, 2015-11-09 at 20:29 +0100, Andreas Tille wrote:
> ...
> /usr/include/dcmtk/dcmsr/dsrdoc.h:649:25: note: candidate expects 2
> arguments, 0 provided
> /build/dicomscope-3.6.0/interface/libsrc/DSRDocument.cpp: In function
> '_jstring* Java_J2Ci_jDSRDocument_getAccessionNumber(JNIEnv*,
>
I'll take on this bug once gdcm (=2.6) - another build dependency of
insighttoolkit4 - has cleared NEW.
I.e. in the packaging svn I already changed the dependency.
Best,
Gert
I've uploaded a patch to svn, but there are more errors like this. It
seems all related methods now uses the OFCondition return value, and
pass an OFString& parameter.
I'll try to get the complete patch out until tomorrow.
Best,
Gert
On Mon, 2015-11-16 at 16:29 +0100, Michael Onken wrote:
> There should already be a clean way in DCMTK to solve the issue
> without applying a Debian-specific patch:
>
> DCMTK offers the CMake option "BUILD_APPS" which is (obviously)
> enabled per default. If you disable it, applications (like
Uploaded everything to svn, it builds and the dependency was changed to
libdcmtk-dev.
If you give me upload rights then I will proper checking and uploading
tomorrow.
Best,
Gert
On Fri, 2015-10-30 at 15:53 +0100, Emilio Pozuelo Monfort wrote:
> This is a friendly ping wrt the libstdc++ ABI transition. Your
> package is listed as needing a transition but has seen no action.
> It'd be good to get things going
> so we can finish the transition soon.
Sorry that I forgot to
Hello,
I'll look into this as soon as gdcm-2.6 has cleared NEW because
vtk-dicom depends on gdcm which also needed the transition to vtk6.
Best,
Gert
Hi,
I've prepared a GDCM-2.6 upload that uses the compressed scripts, but
since depending on files from /usr/share/doc is a policy violation, I'd
suggest the following 2-step procedure to get rid of the problem:
1. Apply the attached patch to the vtk6 debian scripts to install the
perl
Hi, I had a look into the package, but I for me with 0.11 an llvm-3.6
two tests are failing - this has also already been reported upstream:
https://github.com/pocl/pocl/issues/181
Disk space used for building of ITK 4.8 with only 2 and 3 dimensions
to wrap:
chroot base system with all deps installed: 3.0GB
Source code unpacked: ~1.0GB
Build dir 36GB
Debian dir 5.1GB Sum: 42GB
Total:
On Fri, 2015-10-02 at 15:57 +0200, Mathieu Malaterre wrote:
> Forgot to quote section §8.4 Development files
>
> https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s
> -sharedlibs-dev
>
> [...]
> If there are development files associated with a shared library, the
> source package
Hello again,
> I'm just looking into plink1.9 to fix #799471. I currently test the
> build on a 32 bit arch, and would also try to compile the changes on
> amd64. I'll ping you when it's done.
I've created a patch that should fix the build failures reported in
#799471, but since it only
The package seems to fail on all 64-bit architectures that are not
x86_64 because the define __LP64__ is used to decide whether the SSE2
specific header emmintrin.h is available.
However, __LP64__ is defined on all 64 pit archs and not only on
x86_64.
On Debian replacing all instances of
Package: debian-maintainers
Severity: normal
Hi,
Here is my (slightly late) annual ping.
Thanks,
Gert
signature.asc
Description: This is a digitally signed message part
Hello Steven,
On Sun, 2015-10-04 at 11:09 -0500, Steve M. Robbins wrote:
> There are two things that could probably help:
> >
> > - change the python-binding dimensions to use only 2 an 3.
>
> I can definitely make this change for the next upload.
> Did you ever quantify whether this saves
> So let's say this is not urgent or RC, but it'd be good to change it
> in the next upload. It is trivial to change anyway ;)
Well, since itk-4.8.2 is out and gdcm was rejected by ftp master, I
will do another upload shortly, and when the new gdcm version has
passed NEW, we can request a new
Just letting double-conversion provide a *.cmake file is probably not
sufficient, since the current version of ITK exposes the interface of
double-conversion through itkNumberToString.h by including it without
the leading subdirectory "double-conversion".
The issue has now been reported upstream
The reason I filed this bug is no longer relevant, because I added a
patch to fix #733629 that doesn't require a cmake file.
Hence it would probably be okay to tag this patch as wontfix.
Best,
Gert
The last few days I did test the builds of ITK 4.8.2 on powerpc and
armhf - both without python bindings). Even so compiling took more than
24 hours, which means this was an experiment I'm not going to repeat
soon.
On armhf I have only a Ubuntu 15.10 installation (g++ 4.8), it builds
out of the
Since mummy depends on libgccxml. gccxml is incompatible with g++-5 and
no longer maintained by upstream, this package will be phased out.
Best,
Gert
activiz.net depends on mummy, which in turn depends on gccxml which is
no longer maintained by upstream and doesn't produce usable code with
g++-5.
Hence this package will be phased out.
Best,
Gert
I've uploaded a patch to svn that (hopefully) catches all the cases of
the CONDITION->OFCOndition transition.
This new patch [1] replaces the initial one done by Andreas. Please see
svn changelog for more details.
Also note that this is untested, because "d/rules get-orig-source"
failed on
Hi Andreas,
On Wed, 2015-12-02 at 13:56 +0100, Andreas Tille wrote:
> I checked this out and I'm afraid you did not really commited the
> latest version of your patch set:
That was a last minute change of the filename that I forgot to move to
the d/p/series file. (sorry).
> Wende Patch
After fixing dcmtk (uploading right now) there are still failures:
On one hand, during the build I get:
cd build && ../tests/run.sh
F: cannot initialize network: 0006:031c TCP Initialization Error:
Address already in use
E: Store Failed, file: dcmtkpp.iZA/data.dcm:
E: 0006:0317 Peer aborted
Package: dcmtk
Version: 3.6.1~20150924-1
Severity: important
The dicom dict is installed in a versioned directory, but that information is
not propagated to the osconfig.h file.
workaround: set
DCMDICTPATH=/usr/share/libdcmtk5/dicom.dic
-- System Information:
Debian Release: stretch/sid
There are actually two alternatives to fix this bug on the upstream
side:
* Either convert the .dox files actual man pages and then use these
directly (i.e, no longer invoking doxygen to create them). Since man
pages are actually text files this would be also a proper source
format to apply
1 - 100 of 297 matches
Mail list logo
