Bug#994453: linux-image-5.14.0-trunk-amd64: Kernel hangs at loading initramfs Ryzon based laptop

Package: src:linux Version: 5.14.3-1~exp1 Severity: critical Justification: breaks the whole system Dear Maintainer, booting the kernel on the computer as given in the description below hangs at the message "loading initial ramdisk" (no change of display mode, just the two initial boot message

Bug#972909: insighttoolkit4 ftbfs with python3.9

Hi Matthias, shouldn't the severity be "important" if the FTBFS is really related to python 3.9 until this version becomes the default python version? AFAICS 3.8 is still the default, here [1] it is not yet listed for bullseye, and ITK is build only against the default python version

Bug#971433: marked as pending in dcmtk

/d92d18c445d1a28521584ca1e7f3049b3dfad33d d/rules: don't install libcharls.so Closes: #971433 Signed-off-by: Gert Wollny (this message was generated automatically) -- Greetings https

Bug#968176: marked as pending in gdcm

Control: tag -1 pending Hello, Bug #968176 in gdcm reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at:

Bug#944636: marked as pending in insighttoolkit

Control: tag -1 pending Hello, Bug #944636 in insighttoolkit reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at:

Bug#944636: insighttoolkit4: CMake missing files for imported targets

Hello Bas, the gdcm warnings are just noise that this difficult to avoid unless one wants to pull in packages that are actually not needed for building (see #826048 for details). The missing minc-dev is geniue though, but I'll have to wait until the last version clears NEW (the NEW upload was

Bug#944683: FTBFS: missing file /usr/lib/nodejs/axios/dist/axios.min.js

Package: orthanc-dicomweb Version: orthanc-dicomweb_1.0+dfsg-1 Severity: serious Justification: 4 Dear Maintainer, While I was trying to rebuild the package to use libgdcm-dev instead of libgdcm2-dev (change already pushed to the repo) the package failed to build for another reason with the

Bug#943765: marked as pending in gdcm

Control: tag -1 pending Hello, Bug #943765 in gdcm reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at:

Bug#923433: EncoderStrategy::Flush (this=0x5555557452f0) at ./src/encoderstrategy.h:156

Hello Mathieu, thanks for looking intio this. I think reverting to CharLS 1. 0 is good for now. It really makes more sense if upstream does the port. Thanks for the NMU, I'll add the debdiff to the repo. Best, Gert

Bug#923750: gdcm: FTBFS in buster/sid

Hi, the problem is I at least don't know the offending package because I was not able to reproduce the build failure. Whatever it was, it has probably already benn fixed. Best, Gert

Bug#923750: gdcm: FTBFS in buster/sid

I can't reproduce this in current sid. I've did a new upload with a minior unrelated fix incorporated by Gianfranco. If this passed on the build servers, I'm going to close the bug, best, Gert

Bug#919739: Bug #919739 in dicomscope marked as pending

Control: tag -1 pending Hello, Bug #919739 in dicomscope reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at:

Bug#919193: orthanc: FTBFS with dcmtk-3.6.4

Source: orthanc Version: 1.5.1+dfgs-1 Severity: serious Justification: 4 FTBFS but build before Dear Maintainer, The package FTBFS with dcmtk-3.6.4. The main issues: - unlock() now needs to be replaced by rdunlock() or wrunlock() depending on which *lock() method was called - Various

Bug#914817: [Debian-med-packaging] Bug#914817: camitk: FTBFS on i386

Am Sonntag, den 02.12.2018, 15:45 +0100 schrieb Mattia Rizzolo: > > Guess having this bug reassigned to vtk7, and Gert uploading a fixed > vtk7. Then camitk can be finally rebuilt on i386 as well. > I made an upload of vtk7 to exprimental, there mostly because I want to see whether QT can

Bug#912561: Bug #912561 in castxml marked as pending

Control: tag -1 pending Hello, Bug #912561 in castxml reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below, and you can check the diff of the fix at:

Bug#911793: Bug#914483: Control: reassign -1 src:gdcm 2.8.7-2

Am Freitag, den 23.11.2018, 20:14 +0100 schrieb Mattia Rizzolo: > Hi, > > so, if you don't particularly mind, I'm happy to just take the least > and fix all the involved packages here, so src:vtk7 I just uploaded vtk7, I knew where to look because I did the changes that made the libraries go

Bug#911793: Control: reassign -1 src:gdcm 2.8.7-2

Hello, Am Freitag, den 23.11.2018, 16:30 +0100 schrieb Emmanuel Promayon: > Dear all > > Thank to Paul for your answers about the autoremoval and explanation > about the ABI problem. It seems that Adrian Bunk's triage message in > 909120 (added blocking bug(s) of 909120: 911793) did push the

Bug#911793: gdcm: ABI break

Control: reassign -1 vtk7 Control: retitle -1 Don't drop some libvtkRendering* libraries I don't think that this is a problem with gdcm, both camitk-imp and camitk-config don't even list any gdcm library with ldd, but they both list libvtkRenderingFreeTypeFontConfig-7.1.so.7.1 => not found

Bug#901214: Bug #901214 in vtk-dicom marked as pending

Control: tag -1 pending Hello, Bug #901214 in vtk-dicom reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below, and you can check the diff of the fix at:

Bug#901214: Bug #901214 in vtk-dicom marked as pending

Control: tag -1 pending Hello, Bug #901214 in vtk-dicom reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below, and you can check the diff of the fix at:

Bug#910791: gdcm: outdated packages on armel/armhf

Hi, thanks for - fix vtk7 to build on those architectures That means dropping support for QT there, which seems like the best option, but needs some time to test properly. Ithink I'll open a bug for that. - drop that build-dep on armel/hf (if it is optional) Alternatively, dropping the

Bug#908472: Bug #908472 in gdcm marked as pending

Control: tag -1 pending Hello, Bug #908472 in gdcm reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below, and you can check the diff of the fix at:

Bug#904661: vtk7 FTBFS due to uninstallable build dependencies

Control: reassign -1 src:py-ubjson Control: merge -1 902762 Control: affects 902762 vtk7 python-autobahn is currently not installable with python3-all-dev because the latter depends on python3.7 and python-autobahn depends on python-ubjson, which in turn FTBFS with python-3.7. As a side note: I

Bug#897756: 897775 & 897756 *: ftbfs with GCC-8 (because of an error in insighttooklit4)

Hello Andreas, you marked these two bugs as found in insighttoolkit4/4.12.2-dfsg1-2, but they should actually have been merged with #897899 (maybe I did something wrong theer), a bug that was closed by exactly this version. Could you ellaborate why do you tagged these bugs like this? I just

Bug#902766: python3.7 causing python3-twisted failure?

Am Samstag, den 30.06.2018, 18:38 +0100 schrieb Neil Williams: > Do you have python3.7 installed? A similar error was reported against > python3-pexpect with python3.7: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902646 > > 'async' is a reserved keyword in Python 3.7. > Yes, because

Bug#902766: python3-twisted fails in the post-installation script when doing a first-time install

Package: python3-twisted Version: 18.4.0-1 Severity: serious Justification: Policy 5.2 (package remains in unconfigured state) Dear Maintainer, When doing a fresh install the post-installation script fails with Setting up python3-twisted (18.4.0-1) ... File

Bug#894371: Bug #894371 in gdcm marked as pending

Control: tag -1 pending Hello, Bug #894371 in gdcm reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below, and you can check the diff of the fix at:

Bug#894371: Bug #894371 in gdcm marked as pending

Control: tag -1 pending Hello, Bug #894371 in gdcm reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below, and you can check the diff of the fix at:

Bug#894371: Bug #894371 in gdcm marked as pending

Control: tag -1 pending Hello, Bug #894371 in gdcm reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below, and you can check the diff of the fix at:

Bug#901519: Bug #901519 in gdcm marked as pending

Control: tag -1 pending Hello, Bug #901519 in gdcm reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below, and you can check the diff of the fix at:

Bug#895246: gconf: Intent to Adopt

Am Sonntag, den 13.05.2018, 15:18 -0400 schrieb Jeremy Bicha: > Respectfully, you are the only one complaining about gconf's > removal. I might not have been complaining here, but I'm also not that happy about some removals, and I don't understand the resistance to let someone adopt the package.

Bug#894371: gdcm FTBFS with openjdk-9

>As a workaround to let the poppler transition complete in raspbian I >whipped up a version of the package that forces openjdk-8. I intend to do the same, best Gert

Bug#896598: [Debian-med-packaging] Bug#896598: libglademm2.4: Intent to Adopt

Hi Adrian, while I generally agree that dropping all the gnome2 related libraries from Debian is not a good idea, in this case, where aeskulap is the only reverse dependency I'm aware of, I wonder whether is is really a good idea to put effort into providing this library package? Best, Gert

Bug#893770: libgnomecanvas will be adopted

Control: severity -1 important In light of #895249 I downgrade the bug severity. Autoremove will still happen since src:libgnomecanvas still has a few RC bugs. Best, Gert

Bug#895247: libgnomecanvas: Intent to Adopt

Am Donnerstag, den 12.04.2018, 23:32 +0300 schrieb Adrian Bunk: > On Thu, Apr 12, 2018 at 06:09:32PM +0100, Simon McVittie wrote: > > On Thu, 12 Apr 2018 at 15:03:11 +0200, Gert Wollny wrote: > > > Hi Adrian, > > > > (Adrian won't have seen this unless he's subscr

Bug#895247: libgnomecanvas: Intent to Adopt

Hi Adrian, as the maintainer of amide[1], a package that depends on libgnomecanvas I was also already thinking about adopting this package and libart- lgpl. In other words I'd happily join to co-maintain these two packages. Best, Gert

Bug#894371: gdcm FTBFS with openjdk-9

Control: forwarded -1 https://bugs.openjdk.java.net/browse/JDK-8200610 The bug is now visible upstream. but they closed it immediately. Unfortunately I can't comment on the bug, because I am unable to figure out how to open an account, but the suspected output path is definitely writeable (after

Bug#894371: gdcm FTBFS with openjdk-9

Control: reassign -1 src:openjdk-9 Control: affects -1 gdcm Control: tags -1 upstream The error message states: An exception has occurred in the compiler (9.0.4). Please file a bug against the Java compiler ... Hence, I reported the bug upstream and will update this report here when I

Bug#894462: paraview: edges are blotted [regression]

Am Freitag, den 30.03.2018, 18:01 +0200 schrieb Francesco Poli (wintermute): > Package: paraview > Version: 5.4.1+dfsg4-2 > Severity: grave > Justification: renders package unusable > > Hello paraview Debian package maintainers, > thanks for uploading a Debian revision that uses Qt5 rather than

Bug#893770: amide: Don't depend on libgnomecanvas

Am Donnerstag, den 22.03.2018, 00:40 -0400 schrieb Jeremy Bicha: > Source: amide > Version: 1.0.5-10 > Severity: serious > User: pkg-gnome-maintain...@lists.alioth.debian.org > Usertags: libgnomecanvas oldlibs > > As announced [1], we do not intend to release Debian 10 "Buster" with >

Bug#888925: [Debian-med-packaging] Bug#888925: libminc FTBFS with netcdf 1:4.6.0-2: NetCDF: Attempt to use feature that was not turned on when netCDF was built

I'm on it Am Donnerstag, den 08.02.2018, 07:52 +0100 schrieb Sebastiaan Couwenberg: > On 02/08/2018 07:41 AM, Andreas Tille wrote: > > > libminc needs to fix their test or their usage of libnetcdf. > > > > Could you be more verbose what exactly needs to be changed? > > You can skip the test

Bug#885078: aeskulap: libglademm2.4: Don't release with Buster

Hello Jeremy, can we please have a list of _all_ libraries that you want to drop? I just went through porting this package to gsettings just to see that there is now another dependency which should go away, and in this case it is probably impossible, because the interface is build around glade2

Bug#589003: cdrdao deletes cue file

Control: severity -1 normal Hi Axel, Without giving the "--remote" flag cdrdao doesn't delete the cue file. I think this flag is only useful when cdrdao is started by another external program that is supposed to create the "cue" file on the fly,  because cdrdao always unlinks the file after

Bug#885035: aeskulap: Please don't (build)-depend on gconfmm2.6

On 23.12.2017 13:55, Simon McVittie wrote: > On Sat, 23 Dec 2017 at 07:10:49 +0100, Andreas Tille wrote: >> When droping libgconfmm-2.6-dev from Build-Depends I get >> >> configure.ac:43: error: possibly undefined macro: AM_GCONF_SOURCE_2 >> >> What package provides this macro? > >

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#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#853687: trinityrnaseq: ftbfs with GCC-7

Am Freitag, den 01.09.2017, 15:16 +0200 schrieb Andreas Tille: > Hi, > > > I admit I have no idea why this and other header files are not found. In  Chrysalis/Makefile it is only tested up until gcc version 6 to set the include path, for 7 no additional include path is set. I've pushed the

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

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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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 >

  1   2   >