Bug#713551: 709554 blocks 713551

package src:mialmpick block 713551 by 709554 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#713683: mia: FTBFS: ../mia/3d/libmia3d-2.0.so.8.0.1: undefined reference to `mia::CICAAnalysis::set_row(int, itpp::Vecdouble const, double)'

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

Bug#713683: Fixing this bug

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

Bug#705385: mia: FTBFS on powerpc: test suite hangs

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

Bug#705384: mia: FTBFS on architectures such as ia64 lacking SSE or Altivec support

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

Bug#705383: mia: FTBFS on i386: 3 tests failed out of 228

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-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#705385: mia: FTBFS on powerpc: test suite hangs

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

Bug#705385: mia: FTBFS on powerpc: test suite hangs

The bug does not occur with the latest version of TBB (4.1 Update 2) . -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#705385: mia: FTBFS on powerpc: test suite hangs

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-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#705385: mia: FTBFS on powerpc: test suite hangs

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

Bug#720681: [Debian-med-packaging] Bug#720681: Help with cmake needed (Was: Bug#720681: (Further) help with C++ needed)

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

Bug#720681: [Debian-med-packaging] Bug#720681: Help with cmake needed (Was: Bug#720681: (Further) help with C++ needed)

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:

Bug#746863: FTBFS src:insighttoolkit4

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

Bug#746863: [Debian-med-packaging] Bug#746863: FTBFS src:insighttoolkit4

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

Bug#759945: [Debian-med-packaging] Bug#759945: elastix: FTBFS: make[3]: *** No rule to make target '/usr/lib/x86_64-linux-gnu/libhdf5.so', needed by 'bin/elastix'. Stop.

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

Bug#759945: [Debian-med-packaging] Bug#759945: elastix: FTBFS: make[3]: *** No rule to make target '/usr/lib/x86_64-linux-gnu/libhdf5.so', needed by 'bin/elastix'. Stop.

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,

Bug#754249: new driver available from AMD

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

Bug#746863: [Debian-med-packaging] Bug#746863: insighttoolkit4: ftbfs with GCC-4.9

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:

Bug#746863: [Debian-med-packaging] Bug#746863: insighttoolkit4: ftbfs with GCC-4.9

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

Bug#746863: FTBFS src:insighttoolkit4

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

Bug#746863: FTBFS src:insighttoolkit4

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

Bug#736172: [Debian-med-packaging] Bug#736172: gdcm: FTBFS on powerpc: _GLIBCXX_LONG_DOUBLE_COMPAT issue?

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

Bug#736172: little mistake

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-rc-requ...@lists.debian.org with a subject of unsubscribe.

Bug#759794: [Debian-med-packaging] Bug#759794: insighttoolkit4: FTBFS on amd64 with ENOSPC

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

Bug#795344: [Debian-med-packaging] Bug#795344: libmems-1.6-1: not properly linked to its dependencies

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

Bug#795344: libmems-1.6-1: not properly linked to its dependencies

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

Bug#795344: [Debian-med-packaging] Bug#795344: libmems-1.6-1: not properly linked to its dependencies

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?

Bug#795586: Bug#795586: libfreecontact-perl: FTBFS: Can't load '/tmp/buildd/libfreecontact-perl-0.08/blib/arch/auto/FreeContact/FreeContact.so

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

Bug#795586: [Debian-med-packaging] Bug#795586: libfreecontact-perl: FTBFS: Can't load '/tmp/buildd/libfreecontact-perl-0.08/blib/arch/auto/FreeContact/FreeContact.so

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

Bug#797651: [Debian-med-packaging] Bug#797651: mummy fails to build (libgccxml-dev vs GCC-5)

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

Bug#804575: [Debian-med-packaging] Bug#804575: insighttoolkit4: build-depends on libdcmtk2-dev which is no longer built

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

Bug#804569: dicomscope: build-depends on libdcmtk2-dev which is no longer built

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

Bug#804569: dicomscope: build-depends on libdcmtk2-dev which is no longer built

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*, >

Bug#804569: dicomscope: build-depends on libdcmtk2-dev which is no longer built

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

Bug#797738: [Debian-med-packaging] Bug#797738: gdcm: ABI transition needed for libstdc++ v5

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

Bug#803595: waiting for gdcm clearing new

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

Bug#799322: pocl: With 0.11 some test are failing

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

Bug#800481: [Debian-med-packaging] Bug#800481: dcmtk: versioned -dev package makes transitions too painful

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

Bug#797651: mummy will be phased out.

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

Bug#798165: activiz.net will be phased out

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

Bug#804578: [Debian-med-packaging] Bug#804578: Does not build using dcmtk 3.6.1

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

Bug#804578: [Debian-med-packaging] Bug#804578: Does not build using dcmtk 3.6.1

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

Bug#807675: More failures apparently unrelated to "SCU Failed: 0006:0213 Data dictionary missing"

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

Bug#808537: Please help (Was: Bug#808537: jellyfish: FTBFS: error: 'template class std::auto_ptr' is deprecated [-Werror=deprecated-declarations])

Hello Andres, On Wed, 2015-12-23 at 21:22 +0100, Andreas Tille wrote: > How were you able to respond without keyboard? ;-) Everybody has a superpower ;) > I commited a patch but now one unit test is failing... :-( Actually, for me it builds without a test failure. (SID updated right now)

Bug#808401: [Debian-med-packaging] Bug#808401: plastimatch: FTBFS: itkGDCMSeriesFileNames.h:25:29: fatal error: gdcmSerieHelper.h: No such file or directory

It seems that there is a conflict in which gdcm version is used. The log says that gdcm-2.6 was found but later the include files for gdcm -2.4 are used. I guess itk needs to be rebuild against gdcm-2.6 since it seems to pull in the old version. Best Gert

Bug#808653: [Debian-med-packaging] Bug#808653: elastix: FTBFS: Could NOT find DCMTK (missing: DCMTK_config_INCLUDE_DIR

I suspect that this has to do with the fact that currently ITK depends on an old version of dcmtk. Because of #808491 this transition is not yet completed. Best, Gert

Bug#808401: Bug#808401: plastimatch: FTBFS: itkGDCMSeriesFileNames.h:25:29: fatal error: gdcmSerieHelper.h: No such file or directory

On Sat, 2015-12-19 at 22:55 +0100, Andreas Tille wrote: > Hi Gert, > > On Sat, Dec 19, 2015 at 09:32:58PM +0100, Gert Wollny wrote: > > It seems that there is a conflict in which gdcm version is used. > > The log says that gdcm-2.6 was found but later the include files >

Bug#808491: insighttoolkit4: FTBFS when build against gdcm-2.6.1

Source: insighttoolkit4 Version: FTBFS when building against gdcm-2.6 Severity: serious Tags: upstream Justification: unknown The package has two tests related to GDCM failing when building against system GDCM-2.6. These tests passed when building against GDCM-2.4. -- System Information:

Bug#789931: tag this as wontfix/severity normal

tags 789931 wontfix severity 789931 severity thanks The bug was reported against version 2.2.0 which is outdated, version 3.2.0 now builds find on all architectures that are supported by the insighttoolkit4. On the other hand, the bug reports build failure on arm64 - this is an arch that is

Bug#825096: dolfin: FTBFS: No rule to make target '/usr/lib/libgl2ps.so', needed by

This is indeed a transition problem because gl2ps moved to multiarch, and the vtk cmake files specify full path names of the dependent libraries.  I think this is a good moment to move vtk-6.3 to unstable -  which I will do this weekend. (The alternative would be a vtk-6.2 binNMU, but IMHO at

Bug#822128: Boost 1.55 to be removed; your attention required

Hi,  shouldn't this be closed by now? As far as I can see, ball is now build against boost-1.58.  Best,  Gert

Bug#793607: FTBFS against QT5

in the BTS, but only confirmed with the VTK6 maintainers, the package pulls in some qt4 packages. This is an annoyance, but nifti2dicom still builds properly.) Many thanks, Gert Description: Correct the includes and libraries for QT5 Author: Gert Wollny <gw.foss...@gmail.com> Forwarded: no Last-

Bug#793607: nifti2dicom: FTBFS against VTK 6.2

Hi, now scrolling down the bug report I'd like to add another remark: insighttoolkit4 is (currently) only available on i386 and amd64 [1], and the insighttoolkit3 will be phased out sooner or later (no longer supported by upstream). Since [1] will not be resolved anytime soon all, packages

Bug#805170: ginkgocadx transition

Hello Dmitry, I was test-building the package the other day to see whether it would build against VTK6 and dcmtk > 3.6.1 because it is one of the last packages that still depend on the binary package libdcmtk2. For both cases the package will need some patching. For VTK it seems to be an easy

Bug#808401: Bug#808401: plastimatch: FTBFS: itkGDCMSeriesFileNames.h:25:29: fatal error: gdcmSerieHelper.h: No such file or directory

808401 I had filed a few days ago) and a rebuild is all that is needed. If the release team closes #808491 for other reasons than a successful rebuild I can take care of it, but someone first has to do dcut dm --uid "Gert Wollny" --allow plastimatch Best, Gert

Bug#808401: Bug#808401: plastimatch: FTBFS: itkGDCMSeriesFileNames.h:25:29: fatal error: gdcmSerieHelper.h: No such file or directory

all archs except i386 and amd64 for packaged that depend on ITK before stretch goes into freeze. > > dcut dm --uid "Gert Wollny" --allow plastimatch > > well, I wouldn't give out DM powers to somebody I've never heard > about before :) (and for sure using name/surname a

Bug#813875: [Debian-med-packaging] Bug#813875: insighttoolkit4: FTBFS on i386 (member reference base type 'void' is not a structure or union)

Hello, /usr/bin/castxml -o /«PKGBUILDDIR»/BUILD/Wrapping/itkDenseFiniteDifferenceImageFilter.xml [...] /usr/include/i386-linux-gnu/bits/mathinline.h:948:9: error: '(anonymous union at /usr/include/i386-linux-gnu/bits/mathinline.h:948:9)' cannot be defined in a type specifier (union

Bug#810946: manage bugs

Control: reassign 810946 libinsighttoolkit4-dev Control: severity 810946 important Control: forward 810946 https://issues.itk.org/jira/browse/ITK-3409 Control: merge 810946 810044 Control: thanks This is actually an issue between libinsighttoolkit4-dev and dcmtk, as reported in #810044, and

Bug#749531: fslview: Switch to vtk6

Hi,  since QWT now supports qt5 (libqwt-qt5-dev) I had a shot at this, but alas, the code still requires QT3 compatibility and since QT5 doesn't provide this, it doesn't compile:  In file included from /home/gerddie/packages-other/fslview-4.0.1/obj- x86_64-linux-

Bug#820635: igstk: depends on vtk 5

So far upstream didn't ported the code to use vtk6 and the last commit is 19 month old [1], so th best would be to drop the package, and only re-introduce it if upstream provides a new release that uses vtk6 (or the upcoming vtk7).  Best,  Gert  [1] http://igstk.org/gitweb?p=IGSTK.git;a=log

Bug#820635: igstk: depends on vtk 5

Hello, Am Montag, den 11.04.2016, 08:28 +0200 schrieb Andreas Tille: > I had the impression that VTK6 might be supported by the latest > version 5.2 but I'm not sure.  I personally have no free time slices > to verify this.   Well, I had a stab a this a few days ago, the complications are:   -

Bug#816569: Also need to fix libzeep first

Control: block 816569 by 824013 The fix will have to wait until libboost1.60 becomes the default and is build by using g++-6. In addition libzeep needs then to be fixed first (see blocker).  cheers,  Gert 

Bug#816569: mrs: FTBFS with GCC 6: was not declared in this scope

Control: block -1 by  823978 Hi,  I've added a patch to the packaging svn that fixes the problem, but building with g++-6 still doesn't work because of some boost-regex linking problem (see block request), Best,  Gert 

Bug#821677: Reassign to ftp.debian.org

Control: reassign -1 ftp.debian.org Control: clone  -1 -2  Control: retitle -1 RM: php5-gdcm -- ROM;doesn't support PHP7.0 Control: retitle -2 RM: php5-vtkgdcm -- ROM;doesn't support PHP7.0 GDCM removed building the php packages because php 7 is not supported.  Please remove the outdated

Bug#821731: CTK FTBFS

Well, that code version is horribly outdated. Upstream has yet to define somewhere which versions of third party libraries are required, and then tag a release, which may actually happen some day soon.  See also:  https://github.com/commontk/CTK/issues/608

Bug#798167: [Debian-med-packaging] Bug#798167: camitk: depends on vtk 5

Hello,  while moving to VTK 6 please take into account that we are preparing a transition to VTK 6.3.  Compared to VTK 6.2 version 6.3 removes some deprecated macros  and removes the module "vtkRenderingFreeTypeOpenGL".  You should be able to catch most of the problems related to macros by

Bug#798167: [Debian-med-packaging] Bug#798167: camitk: depends on vtk 5

Hi,  > At the moment I am trying some last faint hope solution (basically  > patching QVTKWidget2 with upstream VTK code)... It seems the proposed solution with QVTKWidget3 posted on stackoverfow [1] that you referenced would work. Why not use this one?  > If anyone else has some insight

Bug#811795: sitplus: FTBFS with GCC 6: error: reference is ambiguous

, but with c++11 the definition of std::shared_ptr is also pulled in, so that it comes to name clashes. this patch fixes this by either fully specifying boost::shared_ptr or replacing the broad "using namespace std" by using directives of the std:: types that are artually used. Author: G

Bug#811992: librostlab-blast: FTBFS with GCC 6: misc errors

Hi,  there seems to be a bug in g++-6 [1] that results in this compile failure.  I think the only way to quell this bug at the moment is to force c++03, i.e.    export DEB_CXXFLAGS_MAINT_APPEND  = -std=c++03 in d/rules.  Because this workaround exists I'm not adding #829604 as blocker now.

Bug#811815: murasaki: FTBFS with GCC 6: no match for

Control: block -1 823978 I've uploaded a patch to the packaging repository that fixes the g++-6 issues, but linking against boost will fail because of the issues discussed in #823978.  Best,  Gert

Bug#811682: Updated patch

contains architecture specific dir x86_64-linux-gnu E: libgtkmathview-dev: pkg-config-multi-arch-wrong-dir  usr/lib/pkgconfig/mathview-frontend-gmetadom.pc full text contains architecture specific dir x86_64-linux-gnu Best,  Gert    From: Gert Wollny <gw.foss...@gmail.com> Date: Sun, 26 Jun 2

Bug#811644: FTBFS with GCC 6: cannot convert x to y

Control: tags -1 pending  Hi,  I've uploaded a patch fixing this compiler problem, and I also added another patch that makes sure the test suite is actually run during package build.  I don't ask for sponsoring though, because the package is somewhat fishy: In the source one gets by using   

Bug#811876: disulfinder: FTBFS with GCC 6: no matching function for call to

Control: tags -1 pending  Hi,  I've added a patch in the svn to fix this bug and have also enabled parallel builds.  Tatiana, when you continue to work on the package please take note that you should run "svn up" first.  Best,  Gert

Bug#811657: FTBFS with GCC 6: cannot convert x to y

Control: tags -1 pending  This is fixed in the packaging repo, but there are some other issues that need to be resolved before the package can be uploaded. (Was discussed on the list [1].  Best,  Gert  [1] https://lists.debian.org/debian-med/2016/06/msg00230.html

Bug#835761: insighttoolkit4: FTBFS: itkTriangleHelperPython.cpp:5836:65: error: no matching function for call ...

Control: tags -1 pending  Upstream provided all the required patches, test building now before uploading. 

Bug#821731: ctk: FTBFS: ctkDICOMUtil.cpp:33:3: error: 'log4cplus' has not been declared

Hi, Some time ago there was some activity with an upstream issue [1] about making the package ready for proper inclusion into Debian. Unfortunately upstream doesn't properly document dependencies and seems to have the habit to use locally patched versions of these dependencies if they feel like

Bug#811818: crrcsim: FTBFS with GCC 6: no match for

that a newline was the intended output after the according message. Author: Gert Wollny <gw.foss...@gmail.com> Forwarded:no Debian-Bug: https://bugs.debian.org/811818 --- a/src/mod_video/crrc_animation.cpp +++ b/src/mod_video/crrc_animation.cpp @@ -84,7 +84,7 @@ else {

Bug#838808: gtkglextmm: FTBFS: thread.h:140:18: error: variable or field 'thread_init' declared void

Control: tags -1 pending Hello Adrian, thanks for the patch but it is actually easier (because less intrusive) to add -DGLIBMM_DISABLE_DEPRECATED in debian/rules. I will adopt the package and prepare an upload shortly. Best, Gert signature.asc Description: OpenPGP digital signature

Bug#828529: r-cran-openssl: FTBFS with openssl 1.1.0

Hello,  Am Donnerstag, den 27.10.2016, 08:56 +0200 schrieb Andreas Tille: > Hi, > > I can confirm this problem when trying to build against openssl 1.1: > > ... > gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG  -fpic  -g -O2 > -fdebug-prefix-map=/build/r-base-3.3.1.20161024=.

Bug#828308: downgrade severity, because the bug is not RC anymore

Control: severity important Hello Mathieu, thanks for the patch, but since itksnap uses gdcm, and also QT5, and the latter uses dlload to pull in openssl-1.0 dynamically (and this will not change for stretch), gdcm will also be build against the older version of openssl. Hence I will not apply

Bug#844140: mia: FTBFS: lxml.etree.XMLSyntaxError: None

I don't think that the bug is related to threading/locking failures within mia, i.e. compiling the package by using g++-5* and  -fsanitize=thread doesn't show any locking problems (specifically no double un-locking of a mutex).  Specifically, the error hints at     ./mia-3dmaskseeded

Bug#844835: orthanc: FTBFS: build-dependency not installable: libssl-dev

Hi,  orthnac build depends on libdcmtk-dev, and this pulls in libssl1.0-dev (since dcmtk (a) does not yet support openssl-1.1 and (b) it is used by programs that require QT which conflicts with openssl-1.1).  libssl1.0-dev conflicts with libssl-dev, and hence the build failure.  The solution is

Bug#846372: vtk6: FTBFS: /< ...

Hello Iain,  thanks for the patch and please go ahead with the upload. I will take care of adding it to the packaging git.  There is no use in forwarding this to upstream, because for them vtk-6 is EOL, they are now at vtk-7 which will only be packaged after stretch is released. Best, Gert 

Bug#845851: NMU: gnustep-sqlclient: switch to build depend on the metapackage default-libmysqlclient-dev

/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +gnustep-sqlclient (1.7.3-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * Build depend on default-libmysqlclient-dev, Closes: #845851 + + -- Gert Wollny <g...@debian.org> Wed, 04 Jan 2017 09:27:59 + + gnustep-sqlclient (1

Bug#838704: gnustep-dl2-postgresql-adaptor: fails to upgrade on a long grown system

Hello,  in    d/gnustep-dl2-postgresql-adaptor.maintscript the first link uses "Current" which is already a symlink. When one replaces this with "0" the upgrade works fine. (I tested this with -9+nmu build on sid upgrading to the patched -15 which also failed here for the unpatched version.  I

Bug#838704: NMU: gnustep-dl2-postgresql-adaptor: fails to upgrade on a long grown system

and a tif file +that don't appear to be arch dependent. + + -- Gert Wollny <g...@debian.org> Sun, 08 Jan 2017 21:29:41 + + gnustep-dl2 (0.12.0-15) unstable; urgency=medium * debian/control: build depends on latest libgnustep-gui-dev diff -ruN gnustep-dl2-0.12.0/debian/files gnust

Bug#846771: python-traits: FTBFS: dh_auto_test: pybuild --test -i python{version} -p 2.7 returned exit code 13

Digging to reasons for pending autoremovals I came across this bug  First I had a strange problem with the X connection: I run Debian in a chroot into which I ssh with "ssh -Y  localhost:". X-clients like emacs run correctly, but dpkg-buildpackage failed with  dh_auto_test

Bug#858260: Help needed for pandas bug: Could anybody verify the suspicion that tzdata might have some influence?

Hello, I did some digging: > Maybe it's a bug in python-tz? Most likely: Pandas uses this code to get the time offset for the local time in tslib.pyx: cpdef _get_utcoffset(tzinfo, obj): try: return tzinfo._utcoffset except AttributeError: return

Bug#858260: Help needed for pandas bug: Could anybody verify the suspicion that tzdata might have some influence?

At second thought it might not be a bug in python-tz, but some undefined behavior that results from the pandas use of tz._utcoffset: >   tz = pytz.timezone('Asia/Tokyo') >   dt = datetime.datetime(2011,1,1) >   >   In[76]:  tz.utcoffset(dt) >   Out[76]: datetime.timedelta(0, 32400) > >   In

Bug#871677: unblock regarding errors from castxml

Control: unblock -1 by 871573 Control: unblock 871282 by 871573  Will do an upload without Python bindings to avoid that the reverse dependencies get removed from testing. Another bug will be opened to track re-enabling the Python bindings, -- Gert

Bug#872353: itksnap: FTBFS on i386: unconditionally expects SSE support

Package: itksnap Version: 3.6.0-1+b1 Severity: serious Tags: upstream Justification: FTBFS The package expects SSE but this is not enabled in the build environment. -- System Information: Debian Release: 9.1 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable'),

Bug#871282: libinsighttoolkit4.10: requires rebuild against GCC 7 and symbols/shlibs bump

Control: tags -1 -wontfix Control: block -1 by 871573 Control: block 871677 by 871573 I was getting to that, first I had to check #871573. Well, before that I thought I had it uploaded after gcc-7 became the default (I'm quite positive that I built it with an older version of gcc-7) and

Bug#871573: Castxml: error: invalid operands to binary expression

Control: severity -1 important Control: retitle -1 Invalid operands to binary expression with float128 Downgrading because the bug only affects source code that uses __float128, and there are packages that use castxml that are not affected by this problem. Best,  Gert 

Bug#871282: insighttoolkit4.10: requires rebuild against GCC 7 and symbols/shlibs bump

Control: tags -1 wontfix Version 4.12 is in unstable, was already build using gcc-7, and will soon transition to testing thereby removing v4.10 from the archives. Best, Gert

Bug#872542: qtwebkit-opensource-src: FTBFS on various release archs (i386, armel, armhf)

Source: qtwebkit-opensource-src Version: 5.9.1+dfsg-3 Severity: serious Justification: FTBFS but build before Dear Maintainer, As can be seen from the build status, the package fails to build on these release archs as well as some non-release archs.

Bug#865781: orthanc-wsi FTBFS with libdcmtk-dev 3.6.1~20170228-2

Hi, I've pushed a patch that fixes this bug to the packaging repo. I didn't upload it though, because I saw that there was already a new version started for packaging. Best, Gert

Bug#874715: mesa: Games like Counter-Strike Global Offensive dont start after upgrading mesa to 17.2.0-2

Since you are using radeonsi you may have a conflict between the system libstdc++ and the one shipped with the steam runtime (Although this usually meant Steam doesn't start at all). cf: https://github.com/ValveSoftware/steam-for-linux/issues/3273

Bug#853568: Nanopolish: gcc-7 issue solved, but immintrin.h missing on most architectures

Am Montag, den 18.09.2017, 13:54 +0200 schrieb Andreas Tille: > control: tags -1 help > > Hi, > > the gcc-7 issue of nanopolish described in latest upstream (0.8.1) > which is now in unstable but according to the build logs[1] on most > architecture the build fails with > > ... > cc -o

Bug#873024: [Debian-med-packaging] Bug#873024: orthanc-wsi FTBFS with dcmtk 3.6.2

Control: tags -1 pending I've pushed the needed changes to the packaging git. Will check and upload tomorrow. Best, Gert

Bug#853568: [Debian-med-packaging] Bug#853568: No idea how to fix abs arguments in nanopolish

Am Donnerstag, den 31.08.2017, 21:00 -0700 schrieb Walter Landry: > Andreas Tille wrote: > > Hi, > > > > to fix bug #853568 I tried a patch (gcc-7.patch) to fix abs() > > arguments > > in nanopolish[1] but I have no idea how to deal with this: > > > > ... > > g++ -o

  1   2   >