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

[Gert Wollny]

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 lines)

Turning off the boot "quiet" option, and/or adding "nomodeset" doesn't
change things.

regards,
Gert


-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: ASUSTeK COMPUTER INC.
product_name: TUF Gaming FX505DY_FX505DY
product_version: 1.0   
chassis_vendor: ASUSTeK COMPUTER INC.
chassis_version: 1.0   
bios_vendor: American Megatrends Inc.
bios_version: FX505DY.308
board_vendor: ASUSTeK COMPUTER INC.
board_name: FX505DY
board_version: 1.0   

** PCI devices:
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD]
Raven/Raven2 Root Complex [1022:15d0]
Subsystem: ASUSTeK Computer Inc. Raven/Raven2 Root Complex
[1043:17c1]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
SERR- TAbort-
SERR- 

00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family
17h (Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
SERR- TAbort-
SERR- TAbort-
Reset-
FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:01.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD]
Raven/Raven2 PCIe GPP Bridge [6:0] [1022:15d3] (prog-if 00 [Normal
decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
SERR- TAbort-
Reset-
FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:01.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD]
Raven/Raven2 PCIe GPP Bridge [6:0] [1022:15d3] (prog-if 00 [Normal
decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort+
SERR- TAbort-
Reset-
FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:01.4 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD]
Raven/Raven2 PCIe GPP Bridge [6:0] [1022:15d3] (prog-if 00 [Normal
decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
SERR- TAbort-
Reset-
FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family
17h (Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
SERR- TAbort-
SERR- TAbort-
Reset-
FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:08.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD]
Raven/Raven2 Internal PCIe GPP Bridge 0 to Bus B [1022:15dc] (prog-if
00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
SERR- TAbort-
Reset-
FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus
Controller [1022:790b] (rev 61)
Subsystem: ASUSTeK Computer Inc. FCH SMBus Controller
[1043:17c1]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- SERR- TAbort- SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- 
Kernel driver in use: amdgpu
Kernel modules: amdgpu

02:00.0 Non-Volatile memory controller [0108]: Kingston Technology
Company, Inc. U-SNS8154P3 NVMe SSD [2646:5008] (rev 01) (prog-if 02
[NVM Express])
Subsystem: Kingston Technology Company, Inc. U-SNS8154P3 NVMe
SSD [2646:5008]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-

Bug#972909: insighttoolkit4 ftbfs with python3.9

[Gert Wollny]

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
(everything else would be insane regarding the build time and the disk
space needed for building the package). 

If you don't object I'll now check whether the configuration error also
occurs with 3.8 and lower the severity if there are no problems. 

Best, 
Gert 

[1]  https://wiki.debian.org/Python#Supported_Python_Versions

Bug#971433: marked as pending in dcmtk

[Gert Wollny]

Control: tag -1 pending

Hello,

Bug #971433 in dcmtk 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:

https://salsa.debian.org/med-team/dcmtk/-/commit/d92d18c445d1a28521584ca1e7f3049b3dfad33d


d/rules: don't install libcharls.so Closes: #971433

Signed-off-by: Gert Wollny 


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/971433

Bug#968176: marked as pending in gdcm

[Gert Wollny]

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:

https://salsa.debian.org/med-team/gdcm/-/commit/adc0be5e36c5f180e5eaa54ccec4a449fddc40a1


d/control: update mono deps Closes: #968176


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/968176

Bug#944636: marked as pending in insighttoolkit

[Gert Wollny]

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:

https://salsa.debian.org/med-team/insighttoolkit/commit/35adbf6b5fcd547bda056a8f3fc3ebef786886cf


d/control: Add libminc-dev to dev deps, Closes: #944636 (Thanks Bas Couwenberg)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/944636

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

[Gert Wollny]

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 needed to rename the python
package)

Best, 
Gert

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

[Gert Wollny]

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 following error: 

  CMake Error at
debian/ThirdPartyDownloads/JavaScriptLibraries.cmake:10 (file):
file COPY cannot find "/usr/lib/nodejs/axios/dist/axios.min.js".
  Call Stack (most recent call first):
CMakeLists.txt:68 (include)

It seems like the file has changed its location to 

   /usr/share/nodejs/axios/dist/axios.min.js

Best, 
Gert 


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.3.9-gentoo (SMP w/6 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages orthanc-dicomweb depends on:
ii  libboost-filesystem1.67.0  1.67.0-13
ii  libboost-locale1.67.0  1.67.0-13
ii  libboost-regex1.67.0   1.67.0-13
ii  libboost-system1.67.0  1.67.0-13
ii  libboost-thread1.67.0  1.67.0-13
ii  libc6  2.29-3
ii  libgcc11:9.2.1-19
ii  libgdcm2.8 2.8.8-9+b1
ii  libjsoncpp11.7.4-3+b1
ii  libpugixml1v5  1.9-3
ii  libstdc++6 9.2.1-19
ii  libuuid1   2.34-0.1
pn  orthanc

orthanc-dicomweb recommends no packages.

orthanc-dicomweb suggests no packages.

Bug#943765: marked as pending in gdcm

[Gert Wollny]

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:

https://salsa.debian.org/med-team/gdcm/commit/3b564e917769f50aae98c33043870e6887b6d9de


d/control: Add Breaks/Replaces for *gdcm2-dev Closes: #943765

Also rename the dev package from *gdcm3-dev to plain gdcm-dev.


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/943765

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

[Gert Wollny]

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

[Gert Wollny]

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

[Gert Wollny]

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

[Gert Wollny]

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:

https://salsa.debian.org/med-team/dicomscope/commit/9dd909f674e8381c405e1ecc66b91f0cb8f23760


d/p/remove_Tar..: Add patch to remove use of removed interface, Closes: #919739


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/919739

Bug#919193: orthanc: FTBFS with dcmtk-3.6.4

[Gert Wollny]

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 functions that take strings now also take a size parameter
for each string

- DIMSE_findUser now takes an additional parameter 

Best, 
Gert

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

[Gert Wollny]

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 really be enabled again on armhf/armel, but I also
included this fix. I would not suggest to re-assign the bug, and
instead close it when camitk builds successfully on i386. 

BTW: feel free to upload vtk7 when there is need, it's supposedly a
team maintained package anyway. 

Best, 
Gert 

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

[Gert Wollny]

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:

https://salsa.debian.org/med-team/castxml/commit/f2a2d175929766dc8b0b410936ac3644ff62


d/p:0004: add patch series for llvm7 support, Closes: #912561



(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/912561

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

[Gert Wollny]

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 away, and the python thing was not so
difficult after all. 

> and src:gdcm (and rebuilding fw4spl).  At the very least, I'm going
> to rename libvtkgdcm2.8 to something else; thinking about
> libvtkgdcm2.8a (libvtk7gdcm2.8 would be somewhat against policy, as
> it wouldn't match the SONAME anymore, and I don't really like to
> change a library's SONAME without coordingation with upstream).
Thanks, btw: Mathieu (who proposed the libvtk7gdcm) is actually
upstream.

> I'd hope the "both vtk6 and vtk7 were loaded in memory" is not so
> relevant... after all they are different libraries, they shouldn't
> mess with each other that much (there chances of it, but…).
The problem is that vtk6 and vtk7 share many symbols, so linking both
into the same executable is likely to create problems.

[...]

> Gert: you mention you gave up on symbols, but at least in gdcm's
> changelog I don't see anything about that.  Had you had troubles
> there as well?
TBH I never tried with gdcm, I think I started to upload the package
when it was already at version 2.4 and I didn't even note that there is
a script for the symbols there (which points at 2.2). 

When I started packaging some of my software (mia) that has lots of
templates I just noted that getting symbols right there is kind of an
infinite task because each arch would need its own file because of
templates that on 64 bit use some types that are not available, and
were not instanciated on 32 bit systems. Maybe the tools are better
now, but at that time (2012) it was all kind of wired.

> What I would welcome your help with is explaining the camitk FTBFS on
> i386.
Just had as peek, my guess is that this will help: 

ifeq ($(DEB_BUILD_ARCH),i386)
  export DEB_CXXFLAGS_MAINT_APPEND=-ffloat-store
endif

The same was needed for ITK because they write tests with floating
point values apparently comparing with high accuracy, and on i386
optimizations can lead to the used of intermediate 80 bit floating
point values that then result in test failures because the references
were tuned for 64 bit floating point values. Adding above flag makes
sure that intermediate results are not keps in these 80 bit FPU
registers. 

Best,
Gert

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

[Gert Wollny]

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 
> autoremoval for another month (thanks to Adrian as well, as that's 
> exactly what is happening).
> 
> Thank you to Mattia for finding the ABI problem and to Matthieu for
> his comments.
> 
> Thank you to Gert for the explanation about vtk7 (by the way do you
> have any idea about the possible future introduction of vtk8 or
> vtk9?).
The problem is that I moved to a different work which is rather
unrelated to using VTK, so my personal interest there is quite limited.
There was also some discussion of actually using paraview as a vehicle
to also bring in the VTK libraries, because paraview has them bundled
and it seems to be difficult to unbundle them.   


> You are right about camitk-imp and camitk-config: they are not
> linked 
> with gdcm. When camitk-imp or camitk-config are run they load some 
> plugins (e.g. the dicom plugin) that itself is linked with gdcm.
> Running ldd on one of the pluging get the similar missing vtk
> symbols and so. So I suppose the problem is in vtk7
I found the problem with the missing libraries, it was indeed something
I messed up when I removed the QT dependency on armhf/armel. 

> 
>  From what I can understand (sorry in advance for any approximation
> or  stating the obvious):
> 1) gdcm 2.8.7-2 moved to python3 (probably because a move from
> python2 to python3 was required) which I think triggered the choice
> of moving from vtk6 to vtk7 (which probably made more sense, as I
> presume vtk6 is  also on its way out of buster).
AFAIK vtk6 doesn't support python3 at all, and the general idea is to
at least minimize the use of vtk6, only provide the libraries, but let
vtk7+ provide the language bindings.  

It will not be possible to remove it completely because of the switch
to OpenGL 3.2 in vtk7 which breaks a number of reverse dependecies
(ginkgocadx and maybe also itksnap).

> 2) When gdcm 2.8.7-2 arrived in sid, it generated a SegFaults
> during camitk 4.1.2-1 as camitk 4.1.2-1 was still based on vtk6, and
> loading  any camitk executable meant that both vtk6 and vtk7 were
> loaded in memory.
This is where I messed up a bit, because I didn't expect that vtkgdcm
would export symbols from vtk, and I didn't check the reverse
dependencies because I was only focused on python3 (and there
inveselius), but this is independend from camitk pulling in two
versions of vtkm, even if vtkgdcm would not export VTK symbols then
this would still have been a problem.

> 3) camitk 4.1.2-2 introduced a patch so that it only depends on vtk7 
> (and like gdcm 2.8.7 without changing the upstream source version).
> 4) gdcm 2.8.7-5 then fixed the double dependency to vtk6 and vtk7
> but camitk 4.1.2-2 was not rebuilt against it, therefore generating
> the initial error that triggered bug #911793
> 5) vtk7 (which was updated in the meantime) seems to have now some 
> missing libraries and as hdf5 is broken as well camitk 4.1.2-2 can
> not be rebuilt yet
I'm noit so sure about the inbetween parts, but the last step is
correct. I just have to check the pytjon problem, and then I should be
able to upload a new vtk7 version. 

> 
> Let me know if there is anything I can do to help.
> 
> On a side discussion:
> Does the fact that I moved the dependency of camitk from vtk6 in
> 4.1.2-1  to vtk7 in 4.1.2-2 might generate another ABI break? 
AFAICS camitk is a leaf package, so there shouldn't be any ABI break
possible.

> If this is the  case, I will take any advice regarding how to specify
> this properly! I will also welcome any information/documentation
> about how to track the symbol.
I tried to tdo this once, but with C++ libraries and templates it was
not quite streightforward, so I gave up on it. 

Best, 
Gert 

Bug#911793: gdcm: ABI break

[Gert Wollny]

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
  libvtkRenderingMatplotlib-7.1.so.7.1 => not found

So my guess it that I botchered vtk7 when I tried to fix the missing
armhf/armel build and somehow managed to exclude these libraries from
the package, and since camitk was build against an vtk7 package version
is has these libraries in the link list. 

I'll see what I can do to get this fixed, but vtk7 now has also a
python related bug and these are usually ugly to fix, so it may take
some time (especially since this is really not my field of work
anymore).

Best,
Gert

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

[Gert Wollny]

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:

https://salsa.debian.org/med-team/vtk-dicom/commit/0bdaa3eb4f19f0bdc8d8382eb3954f18cbf8dfc5


d/control: Add break/replace lib package, Closes: #901214



(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/901214

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

[Gert Wollny]

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:

https://salsa.debian.org/med-team/vtk-dicom/commit/9ae5b2c26fe8bdee88cc76b11231e78738c4b6ca


d/*.install: move cmake files into -dev package, Closes: #901214



(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/901214

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

[Gert Wollny]

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 support for vtk in the armel build, but
that would leave vtk7 in this half fixes state.  

- switch back to vtk6 on those arches for the time being
Not really an option, because this would mess with the pythn support
and when qt4 goes away the problem just comes back. 

- remove gdcm and rdeps from armel/armhf
No realley ;) 

Best, 
Gert

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

[Gert Wollny]

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:

https://salsa.debian.org/med-team/gdcm/commit/21ebea9089756135bd9f9b77c07d81d9d020ff16


d/control: Add conflict with python2 packages, Closes: #908472



(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/908472

Bug#904661: vtk7 FTBFS due to uninstallable build dependencies

[Gert Wollny]

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 think it is very uncommon to file a bug against a
package that FTBFS because of some dependency being (temporarly) not
installable. 

Best, 
Gert 

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

[Gert Wollny]

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 re-
checked and #897775 was indeed fixed by this version. 

many thanks, 
Gert

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

[Gert Wollny]

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 it is pulled in by python3-all or python3-all-dev, but now
even removing this given problems for yet another python3 package
(incidently python3-pexpect that fails to configure)

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

[Gert Wollny]

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 "/usr/lib/python3/dist-packages/twisted/conch/manhole.py", line
154
def write(self, data, async=False):
  ^
SyntaxError: invalid syntax

  File "/usr/lib/python3/dist-packages/twisted/mail/imap4.py", line
1093
def sendUntaggedResponse(self, message, async=False
^
SyntaxError: invalid syntax

dpkg: error processing package python3-twisted (--configure):
 installed python3-twisted package post-installation script subprocess
returned error exit status 1

This leaves the package itself and dependend packages un-configured. 

Apparently with the latest python-3.6 "async" can no longer be used as
a variable name because it is a keyword. 

Best, 
Gert

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.44-gentoo (SMP w/6 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages python3-twisted depends on:
ii  python3   3.6.6-1
ii  python3-automat   0.6.0-1
ii  python3-constantly15.1.0-1
ii  python3-hyperlink 17.3.1-2
ii  python3-incremental   16.10.1-3
ii  python3-openssl   18.0.0-1
ii  python3-service-identity  16.0.0-2
ii  python3-twisted-bin   18.4.0-1
ii  python3-zope.interface4.3.2-1+b2

Versions of packages python3-twisted recommends:
pn  python3-pam 
ii  python3-serial  3.4-3
-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.44-gentoo (SMP w/6 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages python3-twisted depends on:
ii  python3   3.6.6-1
ii  python3-automat   0.6.0-1
ii  python3-constantly15.1.0-1
ii  python3-hyperlink 17.3.1-2
ii  python3-incremental   16.10.1-3
ii  python3-openssl   18.0.0-1
ii  python3-service-identity  16.0.0-2
ii  python3-twisted-bin   18.4.0-1
ii  python3-zope.interface4.3.2-1+b2

Versions of packages python3-twisted recommends:
pn  python3-pam 
ii  python3-serial  3.4-3

Versions of packages python3-twisted suggests:
pn  python3-glade2
pn  python3-gtk2  
pn  python3-qt4   
ii  python3-tk3.6.6-1
pn  python3-wxgtk2.8  

-- no debconf information
Versions of packages python3-twisted suggests:
pn  python3-glade2
pn  python3-gtk2  
pn  python3-qt4   
ii  python3-tk3.6.6-1
pn  python3-wxgtk2.8  

-- no debconf information

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

[Gert Wollny]

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:

https://salsa.debian.org/med-team/gdcm/commit/ab558251685f1abcccbf6138c6a2a99232d02497


d/p/fix-vtkjava-build-dir Closes: #894371



(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/894371

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

[Gert Wollny]

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:

https://salsa.debian.org/med-team/gdcm/commit/ab558251685f1abcccbf6138c6a2a99232d02497


d/p/fix-vtkjava-build-dir Closes: #894371



(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/894371

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

[Gert Wollny]

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:

https://salsa.debian.org/med-team/gdcm/commit/16a8ca34e530acb64f3ded8ca64157eaa9e34eb4


d/control: Change back to default-jdk Closes: #894371



(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/894371

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

[Gert Wollny]

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:

https://salsa.debian.org/med-team/gdcm/commit/7ca036f362778ce5182e2f0af6e528dbec21c1ef


d/p/gdcm-fix-xslt-maxdepth.patch set maxdeph Closes: #901519



(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/901519

Bug#895246: gconf: Intent to Adopt

[Gert Wollny]

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. Adrian is obviously dedicated to maintain
the package, and in this (and other cases with gnome2 related packages)
there are no RC bugs or known security problems. 

I have ported two packages away from gconf, but it would be better to
have at least the posibility to read the gconf configuration, to be
able to convert it to a new backend. If only for that keeping gconf for
the next release cycle is a good thing, and thank you, Adrian, for
stepping up to adopt the package.

best,
Gert

 

Bug#894371: gdcm FTBFS with openjdk-9

[Gert Wollny]

>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

[Gert Wollny]

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

[Gert Wollny]

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

[Gert Wollny]

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 subscribed to the bug or
> > package, because bug submitters don't normally get copies of bug
> > mail in the Debian BTS; adding him to Cc.)
> 
> Thanks.
> 
> > > 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. 
> 
> I am not a huge fan of co-maintaining low-effort packages,[1]
> either you or me maintaining a package would be fine for me.

Okay, that's fine. Since you started it, I'd say continue with these
packages, and if you need help just ping me. 

> > Do you (either or both of you) also intend to adopt the language
> > bindings src:libgnomecanvasmm2.6 (in theory currently maintained by
> > Deng Xiyue, most recent maintainer upload 2009)?
I didn't intend to look at these, I only looked at dependencies of what
I maintain myself.

Best, 
Gert

Bug#895247: libgnomecanvas: Intent to Adopt

[Gert Wollny]

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 

[1]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893770

Bug#894371: gdcm FTBFS with openjdk-9

[Gert Wollny]

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 all compiling with an older openjdk version
works), so whatever is going on here, it must be something different. 

In addition: When I build the package with cowbuilder (arch:i386) it
fails, but when I then drop into a shell within cowbuilder, and then
run  dpkg-buildpackage manually, the error doesn't occur any more.

OTOH, when compiling the package directly on the host system (amd64)
the error is always reproducible, running  e.g. 

javac -verbose -classpath /usr/share/java/vtk6.jar \
   vtkGDCMImageReader.java

in the correct sub directory terminates with: 

[wrote SimpleFileObject[/home/gerddie/Debian/debian-med/build-
area/gdcm-2.8.4/obj-x86_64-linux-
gnu/Utilities/VTK/java/vtk/vtkGDCMImageReader.class]]
[total 1308ms]
An exception has occurred 
...
---

The file vtkGDCMImageReader.class is written and has a non-zero size. 

Running javac with "strace -f" doesn't show any strange file access
close to the point when the exception is raised. 

Bug#894371: gdcm FTBFS with openjdk-9

[Gert Wollny]

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 get a public bug url.

Best,
Gert

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

[Gert Wollny]

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 Qt4!
> 
> I've just upgraded to it on my Debian testing box, but I found a bad
> regression that renders the package unusable to create beautiful and
> clear visualizations (this may be considered as basically the main
> purpose of paraview!).

Since I did this upload as a team upload I can give you one comment  (I
don't used the program myself, and I have no idea how to use it, I am
only somewhat familiar with VTK, but also only from the "get it to
compile" side and not so much from the "how to use it properly").

With this upload I switched the package from using the deprecated
"OpenGL" redering interface (based on OpenGL 1.1) to the new "OpenGL2"
rendering interface (based on openGL 3.2), which means that his might
be a fallout from this rather big upstream change. 

These two upstream bugs might also be related: 

https://gitlab.kitware.com/paraview/paraview/issues/17202
https://gitlab.kitware.com/paraview/paraview/issues/16882

Best, 
Gert

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

[Gert Wollny]

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
> libgnomecanvas, one of the old unmaintained libgnome libraries. Your
> package Build-Depends and Depends on this library.

Well, porting amide to something else than libgnomecanvas seems to be
quite a task - i.e. I have no idea where I would start, and on the
other hand, amide just works and is widely  used by people who work
with image processing, so it would be a shame to have to drop it from
Debian. 

What would be your opinion on offering libgnomecanvas for adoption?

My approach would then be to strip out everything that requires 
gnome-common and gnome-pkg-tooks, possibly also gtk-doc-tools so that
the package can continue to be available until upstream ports it or
gtk2 is dropped, at which point maintainance really will become
impossible.

> amide has one more old dependency: scrollkeeper. I can submit a patch
> for this later if you like.
> 
> [1] https://lists.debian.org/debian-devel/2018/02/msg00169.html
That would be nice, 

Gert

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

[Gert Wollny]

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 until upstream has provided a fix.
> 
> > I admit, I have no idea about libnetcdf and Steve did not responded
> > to the issue yet.
> 
> libminc passed custom flags to the nccreate() via its micreate()
> wrapper:
> 
>  ip->fd = micreate(ip->name, NC_CLOBBER|MI2_CREATE_V1); /*Create
> MINC1 format*/
> 
> These flags are passed along to nccreate() which is more strict in
> its what it accepts.
Actually, MI2_CREATE_V1 coincides with the NC_MPIPOSIX flag, and since
MPI is not compiled in the file creation fails, luckily, one might say.

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

[Gert Wollny]

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
and from personal experience I know that moving the interface
definitions files to glade3 syntax is not a simple translation.

Also with amide there was the discussion about gnome-canvas. 

many thanks, 
Gert 

Bug#589003: cdrdao deletes cue file

[Gert Wollny]

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 parsing it regardless of
finding the bin file.

Actually, after some tests I think that deleting the "cue" file with
the --remote flag given is the intended behaviour. That's why I
downgrade the severity to normal. 

In any case, could you elaborate why you were using this flag? If you
were calling cdrdao from another program, which one was it? How did you
open the cue file? 

Best, 
Gert

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

[Gert Wollny]

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?
>
> (
> will eventually have a longer list of requests to stop using GConf)
>
> Stopping using GConf is a change to upstream source code. The modern
> replacement is GSettings, part of GIO; for C++ code that should be
> available via glibmm, although I don't know which specific APIs are
> involved.
>
I'll look into this as son as I get the time for it.

Best,
Gert

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

[Gert Wollny]

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 src/thirdparty/scrappie/scrappie_common.o -c -g -O2 -fdebug-
> prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security  -fPIC
> src/thirdparty/scrappie/scrappie_common.c
> In file included from src/thirdparty/scrappie/scrappie_common.c:3:0:
> src/thirdparty/scrappie/util.h:4:14: fatal error: immintrin.h: No
> such file or directory
>  #include 
>   ^
> compilation terminated.
> ...
> 
> 
> On amd64 this is provided by libgcc-*-dev package - how to build the
> package on those other architectures?

immintrin.h is a x86/amd64 specific header for intrinsics, so the
package may simply not support other architectures. At least in util.h
I see nothing that tests whether the according SSE and related 
intrinsics are actually supported. 


Best, 
Gert 

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

[Gert Wollny]

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

[Gert Wollny]

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 update gcc6 patch. 

Best, 
Gert 

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

[Gert Wollny]

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 src/hmm/nanopolish_pore_model_set.o -c -g -O2 -fdebug-
> > prefix-map=/build/nanopolish-0.5.0=. -fstack-protector-strong
> > -Wformat -Werror=format-security -g -O3 -std=c++11 -fopenmp -Wdate-
> > t
> > src/common/nanopolish_variant.cpp: In function
> > 'std::vector extract_variants(const string&, const
> > string&)':
> > src/common/nanopolish_variant.cpp:32:69: error: call of overloaded
> > 'abs(std::__cxx11::basic_string::size_type)' is ambiguous
> >  size_t difference = std::abs(reference.size() -
> > haplotype.size());
> 
> The result of subtracting two size_t's is still a size_t, which is
> unsigned.  So you need to cast it to a signed type.  The correct type
> is ptrdiff_t.
> 
>   http://en.cppreference.com/w/cpp/types/ptrdiff_t
> 
> The line then becomes
> 
>   size_t difference =
> std::abs(static_cast(reference.size() -
> haplotype.size()));

Casting the difference may result in undefined behavior. Consider the
case 

   reference.size() == 1
   haplotype.size() == 2 

then 

   reference.size() - haplotype.size() 

will be 0x (on 32 bit), and how this is casted to a signed type
is implementation dependent (i.e. it is not guaranteed that this simply
wraps to -1, it may also raise a trap because of integer overflow). 

It would be better to avoid the cast altogether by doing something like

   size_t difference = reference.size() > haplotype.size() ? 
   reference.size() - haplotype.size() : 
   haplotype.size() - reference.size(); 


or cast both values before doing the subtraction.

Best, 
Gert 

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

[Gert Wollny]

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)

[Gert Wollny]

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. 

https://buildd.debian.org/status/package.php?p=qtwebkit-opensource-src=unstable

Unfortunately the logs seem to be cut off before the actual error is reported

best regards, 
Gert 


-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.11.7-gentoo-radeon (SMP w/6 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

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

[Gert Wollny]

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

[Gert Wollny]

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'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE:de (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages itksnap depends on:
ii  libc6 2.24-11+deb9u1
ii  libgcc1   1:6.3.0-18
ii  libgdcm2.62.6.6-3
ii  libgl1-mesa-glx [libgl1]  13.0.6-1+b2
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  libinsighttoolkit4.10 4.10.1-dfsg1-1.1+b1
ii  libqt5core5a  5.7.1+dfsg-3+b1
ii  libqt5gui55.7.1+dfsg-3+b1
ii  libqt5opengl5 5.7.1+dfsg-3+b1
ii  libqt5qml55.7.1-2+b2
ii  libqt5widgets55.7.1+dfsg-3+b1
ii  libstdc++66.3.0-18
ii  libvtk6.3 6.3.0+dfsg1-5
ii  zlib1g1:1.2.8.dfsg-5

itksnap recommends no packages.

itksnap suggests no packages.

-- no debconf information

Bug#871677: unblock regarding errors from castxml

[Gert Wollny]

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

[Gert Wollny]

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 since the bug was filed against 4.10 I didn't check. 

For now insighttoolkit4 doesn't build anyway, and we'll have to wait
for upstream to fix #871573. 

Best, 
Gert 

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

[Gert Wollny]

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

[Gert Wollny]

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?

[Gert Wollny]

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 [77]: tz._utcoffset
>   Out[77]: datetime.timedelta(0, 33540)
> 

In the first case tz.utcoffset has a reference date, and can select the
 proper time offset, i.e. in 2011 this is 09:00, but tz._utcoffset
doesn't know which year it refers to, and hence, it picks one offset,
in this case the first on the list that has the additional 19 minutes
offset. 

I do also not understand why the test fails only now though, and why
pandas picks one code path to define the test case, and another to
create the expected value.

Best, 
Gert 

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

[Gert Wollny]

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 tzinfo.utcoffset(obj)

Now with 

  tz = pytz.timezone('Asia/Tokyo')
  dt = datetime.datetime(2011,1,1)
  

I get 

  In[76]:  tz.utcoffset(dt)
  Out[76]: datetime.timedelta(0, 32400)

  In [77]: tz._utcoffset
  Out[77]: datetime.timedelta(0, 33540)

which is exactly the 19 min difference we see, and the result  depends
on the code path taken in _get_utoffset. 

Best, 
Gert

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

[Gert Wollny]

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 -O--buildsystem=pybuild
pybuild --test -i python{version} -p 2.7
I: pybuild base:184: cd /home/gerddie/debian-other/python-traits-
4.6.0/.pybuild/pythonX.Y_2.7/build; python2.7 -m unittest discover -v 
X11 connection rejected because of wrong authentication.
python -m unittest: cannot connect to X server localhost:11.0

Anywy, when I run the test manually then I can confirm the bug - with
different numbers though (see below).

==
FAIL: test_delegation_refleak
(traits.tests.test_regression.TestRegression)
--
Traceback (most recent call last):
  File "/home/gerddie/debian-other/python-traits-
4.6.0/.pybuild/pythonX.Y_2.7/build/traits/tests/test_regression.py",
line 173, in test_delegation_refleak
self.assertEqual(counts[warmup:-1], counts[warmup+1:])
AssertionError: Lists differ: [83406, 83481, 83556, 83631] != [83481,
83556, 83631, 83706]

First differing element 0:
83406
83481

- [83406, 83481, 83556, 83631]
?  ---

+ [83481, 83556, 83631, 83706]
? +++


==
FAIL: test_no_leaking_notifiers
(traits.tests.test_regression.TestRegression)
Extended trait change notifications should not leaf
--
Traceback (most recent call last):
  File "/home/gerddie/debian-other/python-traits-
4.6.0/.pybuild/pythonX.Y_2.7/build/traits/tests/test_regression.py",
line 125, in test_no_leaking_notifiers
self.assertEqual(len(ctrait._notifiers(1)), 0)
AssertionError: 1 != 0

--
Ran 538 tests in 24.723s

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

[Gert Wollny]

Dear all, 

since the hard freeze come closer I've uploaded an NMU with two days
delay. 

Apart from the already proposed patch I also added overrides for the
two lintian warnings because it seems that the files in question are
not actually arch dependent. Moving these files into an arch
independent additional deb might be an alternative, but obviously not
at this point in the release cycle. 

Enclosed you find the NMU patch against version 0.12.0-15. 

best, 
Gert   

diff -ruN gnustep-dl2-0.12.0/debian/changelog gnustep-dl2-0.12.0.new/debian/changelog
--- gnustep-dl2-0.12.0/debian/changelog	2017-01-08 21:39:39.194304479 +
+++ gnustep-dl2-0.12.0.new/debian/changelog	2017-01-08 21:47:28.712306736 +
@@ -1,3 +1,16 @@
+gnustep-dl2 (0.12.0-15.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * d/gnustep-dl2-postgresql-adaptor.links: correct link to make it
+possible that update replaces directory with link. Closes: #838704
+  * Override lintian errors
+   E: gnustep-dl2-sqlite-adaptor: arch-dependent-file-in-usr-share
+   E: gnustep-dl2-postgresql-adaptor: arch-dependent-file-in-usr-share
+In both cases the files in question are just a plist 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 gnustep-dl2-0.12.0.new/debian/files
--- gnustep-dl2-0.12.0/debian/files	1970-01-01 00:00:00.0 +
+++ gnustep-dl2-0.12.0.new/debian/files	2017-01-08 21:47:39.409306788 +
@@ -0,0 +1 @@
+gnustep-dl2_0.12.0-15.1_source.buildinfo gnustep optional
diff -ruN gnustep-dl2-0.12.0/debian/gnustep-dl2-postgresql-adaptor.lintian-overrides gnustep-dl2-0.12.0.new/debian/gnustep-dl2-postgresql-adaptor.lintian-overrides
--- gnustep-dl2-0.12.0/debian/gnustep-dl2-postgresql-adaptor.lintian-overrides	1970-01-01 00:00:00.0 +
+++ gnustep-dl2-0.12.0.new/debian/gnustep-dl2-postgresql-adaptor.lintian-overrides	2017-01-08 21:27:42.279301033 +
@@ -0,0 +1,2 @@
+# These files actually seem to be arch independent 
+gnustep-dl2-postgresql-adaptor: arch-dependent-file-in-usr-share usr/share/GNUstep/Frameworks/PostgreSQLEOAdaptor/Versions/0/LoginPanel.bundle/LoginPanel
diff -ruN gnustep-dl2-0.12.0/debian/gnustep-dl2-postgresql-adaptor.maintscript gnustep-dl2-0.12.0.new/debian/gnustep-dl2-postgresql-adaptor.maintscript
--- gnustep-dl2-0.12.0/debian/gnustep-dl2-postgresql-adaptor.maintscript	2016-07-13 09:56:56.0 +
+++ gnustep-dl2-0.12.0.new/debian/gnustep-dl2-postgresql-adaptor.maintscript	2017-01-05 09:28:36.346876308 +
@@ -1,4 +1,4 @@
-symlink_to_dir	/usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Resources	/usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Versions/Current/Resources	0.12.0-15~
+symlink_to_dir	/usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Resources	/usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Versions/0/Resources	0.12.0-15~
 dir_to_symlink	/usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Versions/0/Headers	/usr/include/GNUstep/PostgreSQLEOAdaptor	0.12.0-14~
 dir_to_symlink	/usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Resources/LoginPanel.bundle/Resources	/usr/share/GNUstep/Frameworks/PostgreSQLEOAdaptor/LoginPanel.bundle	0.12.0-14~
 dir_to_symlink	/usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Versions/0/Resources	/usr/share/GNUstep/Frameworks/PostgreSQLEOAdaptor/Versions/0	0.12.0-14~
diff -ruN gnustep-dl2-0.12.0/debian/gnustep-dl2-sqlite-adaptor.lintian-overrides gnustep-dl2-0.12.0.new/debian/gnustep-dl2-sqlite-adaptor.lintian-overrides
--- gnustep-dl2-0.12.0/debian/gnustep-dl2-sqlite-adaptor.lintian-overrides	2017-01-08 21:45:08.576306063 +
+++ gnustep-dl2-0.12.0.new/debian/gnustep-dl2-sqlite-adaptor.lintian-overrides	2017-01-08 21:26:42.583300746 +
@@ -1,3 +1,5 @@
 # Empty dir is intentional
 gnustep-dl2-sqlite-adaptor: package-contains-empty-directory usr/include/GNUstep/SQLite3EOAdaptor/
 
+# The files in this directory actually seem to be arch independend
+gnustep-dl2-sqlite-adaptor: arch-dependent-file-in-usr-share usr/share/GNUstep/Frameworks/SQLite3EOAdaptor/Versions/0/LoginPanel.bundle/LoginPanel

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

[Gert Wollny]

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 would prepare an NMU but:  

The packaging git does not contain the latest version (i.e. -15) but  
only -14, so I don't know whether you have already any  updates
privately queued up. 

The package has two lintian errors that should either be suppressed  
or corrected: 

E: gnustep-dl2-sqlite-adaptor: arch-dependent-file-in-usr-share
usr/share/GNUstep/Frameworks/SQLite3EOAdaptor/Versions/0/LoginPanel.bun
dle/LoginPanel
E: gnustep-dl2-postgresql-adaptor: arch-dependent-file-in-usr-share
usr/share/GNUstep/Frameworks/PostgreSQLEOAdaptor/Versions/0/LoginPanel.
bundle/LoginPanel

I guess the *plist file is considered to be arch-dependent, although I
don't see why given its content.  

I've attached the according patch to fix this bug. 

Best, 
Gert 
 



--- gnustep-dl2-0.12.0/debian/gnustep-dl2-postgresql-adaptor.maintscript	2016-07-13 09:56:56.0 +
+++ gnustep-dl2-0.12.0.new/debian/gnustep-dl2-postgresql-adaptor.maintscript	2017-01-05 09:28:36.346876308 +
@@ -1,4 +1,4 @@
-symlink_to_dir	/usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Resources	/usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Versions/Current/Resources	0.12.0-15~
+symlink_to_dir	/usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Resources	/usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Versions/0/Resources	0.12.0-15~
 dir_to_symlink	/usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Versions/0/Headers	/usr/include/GNUstep/PostgreSQLEOAdaptor	0.12.0-14~
 dir_to_symlink	/usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Resources/LoginPanel.bundle/Resources	/usr/share/GNUstep/Frameworks/PostgreSQLEOAdaptor/LoginPanel.bundle	0.12.0-14~
 dir_to_symlink	/usr/lib/GNUstep/Frameworks/PostgreSQLEOAdaptor.framework/Versions/0/Resources	/usr/share/GNUstep/Frameworks/PostgreSQLEOAdaptor/Versions/0	0.12.0-14~

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

[Gert Wollny]

Dear maintainers, 

since this is an RC bug and affects packages in debian-med, I've
prepared an NMU and uploaded with with 2 days delay. 

Attached you will find the according diff.

best, 
Gert 

diff --git a/debian/changelog b/debian/changelog
index 541f09e..945a150 100644
--- a/debian/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.7.3-2) unstable; urgency=low
 
   * debian/rules (override_dh_auto_test): Explicitly set the permissions
diff --git a/debian/control b/debian/control
index fef2942..e2aab77 100644
--- a/debian/control
+++ b/debian/control
@@ -6,7 +6,7 @@ Uploaders: Yavor Doganov <ya...@gnu.org>
 Build-Depends: debhelper (>= 9),
 	   libgnustep-base-dev,
 	   libperformance-dev,
-	   libmysqlclient-dev,
+	   default-libmysqlclient-dev,
 	   libecpg-dev,
 	   libsqlite3-dev
 Standards-Version: 3.9.5

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

[Gert Wollny]

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

[Gert Wollny]

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 to remove libssl-dev from the build dependencies, since
libdcmtk-dev already takes care of pulling the right version in. 


Best, 
Gert 

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

[Gert Wollny]

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 --help-xml  

not generating the required output that is later used by the python
program that actually fails. And this command is run without reported
errors, i.e. it doesn't crash like it seems to be what would be
expected from threading errors that are revealed when TSX is enabled. 

In addition, the only place in the code where mutex locking is applied
when running the command like given above is a piece of code that is
shared by all other command line tools in mia, and running these tools
with the the same command line option (--help-xml) don't fail.

It would be nice to know whether the failure was exactly at the same
point when the build was tried, or whether there were differences
there?

Are there any other options, apart from using the thread sanitizer,
that can help me to debug this problem?


Best, 
Gert 

* g++-5, because for g++-6 on Debian the thread sanitizer is currently
broken (#796246). 

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

[Gert Wollny]

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 the patch now, but wait until you release the
next gdcm version to close this bug.

best,
Gert

 



signature.asc
Description: OpenPGP digital signature

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

[Gert Wollny]

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=. -fstack-protector-
> strong -Wformat -Werror=format-security -Wdate-time
> -D_FORTIFY_SOURCE=2 -g  -c cert.c -o cert.o
> cert.c: In function 'R_cert_info':
> cert.c:45:37: error: dereferencing pointer to incomplete type 'X509
> {aka struct x509_st}'
>    OBJ_obj2txt(buf, sizeof(buf), cert->sig_alg->algorithm, 0);
>  ^~
> /usr/lib/R/etc/Makeconf:132: recipe for target 'cert.o' failed


The problem is, that with openssl 1.1.0 many of the structures are now
opaque and elements can only be accessed by specific functions. 

I did a transition for DCMTK some time ago and there it seemed rather
straight forward. I also helped out with qt4, but there the patch is
not tested at all, and some of the changes were not trivial, i.e. one
would need deeper knowledge of openssl to know exactly what is the
access function to be used. 

There is a page that gives some hits, but it is far from complete: 

https://wiki.openssl.org/index.php/1.1_API_Changes


Currently, I'm quite busy moving, but in two weeks or so I might be
able to give a hand in this. 

best, 
Gert 

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

[Gert Wollny]

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

[Gert Wollny]

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 it.

Given that they are also reluctant to tag a release, and the only useful
dependent package would be Slicer (which has exactly the same issues), I
think that packaging CTK doesn't make much sense.

Best,

Gert

[1] https://github.com/commontk/CTK/issues/608





signature.asc
Description: OpenPGP digital signature

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

[Gert Wollny]

Control: tags -1 patch

Dear maintainer,

please find enclosed a patch that fixes building with gcc-6.

Note that the patch makes the assumption that a newline was expected in 
the output instead of std::cerr.


best regards,

Gert

Description: Correct compilation with gcc-6
 The patch assumes 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
   {
 std::cerr << "createAnimation: unknown animation type '"
-  << type << "'" << std::cerr;
+  << type << "'" << std::endl;
   }
   
   if (anim != NULL)

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

[Gert Wollny]

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

[Gert Wollny]

Hello, 

the attached patch fixes the compile errors with gcc-6. However, in the
packaging git the new upstream version has already been started to be
packaged, and it suggests that the upstream package is now split into
two packages. Also the wxwidgets patch doesn't apply cleanly. 
Hence I don't know how to handle this without interfering. 

My suggestion would be to upload a corrected 1.0.3 to get rid of the RC
bug and then see how to deal with the new upstream version.

Best, 
Gert 



 Description: Make code compile with g++-6 and default C++ standart
 The code uses boost::shared_ptr, 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: Gert Wollny <gw.foss...@gmail.com>
Bug-Debian: https://bugs.debian.org/811795


--- a/src/mod_collage/Kernel/kernel.cpp
+++ b/src/mod_collage/Kernel/kernel.cpp
@@ -26,8 +26,8 @@
 
 using boost::shared_ptr;
 using std::vector;
+using std::string;
 
-using namespace std;
 using namespace XMLImplementation;
 using namespace Pictures;
 
@@ -379,4 +379,4 @@
 	shared_ptr CiclicKernelFactory::getKernel(shared_ptr mod) {
 		return shared_ptr(new CiclicKernel(mod));
 	}
-}
\ No newline at end of file
+}
--- a/src/mod_collage/Pictures/Transitions.cpp
+++ b/src/mod_collage/Pictures/Transitions.cpp
@@ -28,7 +28,6 @@
 
 using namespace spcore;
 using namespace mod_sdl;
-using namespace std;
 
 
 namespace Pictures {
@@ -258,4 +257,4 @@
 	SmartPtr VibratePackagePictureTransition::getTransition(){
 		return m_transition->getTransition();
 	}
-}
\ No newline at end of file
+}
--- a/src/mod_collage/XMLImplementation/DBImages.cpp
+++ b/src/mod_collage/XMLImplementation/DBImages.cpp
@@ -28,10 +28,11 @@
 #include 
 
 using std::string;
+using std::pair;
+using std::map;
 using mod_sdl::CTypeSDLSurface;
 using boost::shared_ptr;
 using Poco::FileNotFoundException;
-using namespace std;
 
 namespace XMLImplementation{
 	
@@ -103,4 +104,4 @@
 		else  surf = it->second;
 		return surf;
 	}
-}
\ No newline at end of file
+}
--- a/src/mod_collage/XMLImplementation/LoadXML.cpp
+++ b/src/mod_collage/XMLImplementation/LoadXML.cpp
@@ -28,7 +28,7 @@
 
 using boost::shared_ptr;
 using Poco::XML::XMLReader;
-using namespace std;
+using std::string;
 
 namespace XMLImplementation{
 	/*
--- a/src/sphost/componenthelper.cpp
+++ b/src/sphost/componenthelper.cpp
@@ -61,7 +61,10 @@
 
 using namespace spcore;
 using namespace std;
-using namespace boost;
+
+using boost::tokenizer;
+using boost::trim;
+using boost::escaped_list_separator;
 
 
 #define GETTEXT_DOMAIN_SCRIPTS	"sitplus-sp"
@@ -825,14 +828,14 @@
 	ThrowError (err_msg, linenum, line.c_str(), m_file.c_str());
 }
 
-shared_ptr child= shared_ptr(new ParsingContext);
+boost::shared_ptr child= boost::shared_ptr(new ParsingContext);
 
 unsigned int child_linenum= 0;
 child->PreProcess (ifs, true, child_linenum, fname);
 
 // Try to add to the subcomponents map
-pair<map<string,shared_ptr >::iterator,bool> ret;
-ret= m_subcomponents.insert (pair<string,shared_ptr >(child->m_type, child));
+pair<map<string,boost::shared_ptr >::iterator,bool> ret;
+ret= m_subcomponents.insert (pair<string,boost::shared_ptr >(child->m_type, child));
 if (ret.second== false) {
 	// Component already found
 	string error_msg("Parse error. Component ");
@@ -861,13 +864,13 @@
 // Subcomponent found
 CheckNumTokens (t, 1, 1, linenum, , _file);
 		
-shared_ptr child= shared_ptr(new ParsingContext);
+boost::shared_ptr child= boost::shared_ptr(new ParsingContext);
 
 child->PreProcess (is, false, linenum, m_file);
 
 // Try to add to the subcomponents map
-pair<map<string,shared_ptr >::iterator,bool> ret;
-ret= m_subcomponents.insert (pair<string,shared_ptr >(child->m_type, child));
+pair<map<string,boost::shared_ptr >::iterator,bool> ret;
+ret= m_subcomponents.insert (pair<string,boost::shared_ptr >(child->m_type, child));
 if (ret.second== false) {
 	// Component already found
 	string error_msg("Parse error. Component ");
@@ -1030,7 +1033,7 @@
 SmartPtr compo;
 try {
 	// Check subcomponents
-	map<string,shared_ptr >::iterator itm= m_subcomponents.find (t[1]);
+	map<string,boost::shared_ptr >::iterator itm= m_subcomponents.find (t[1]);
 	if (itm!= m_subcomponents.end()) compo= itm->second->BuildComponent(t[2].c_str(), argc, argv);
 	else {
 		compo= getSpCoreRuntime()->CreateComponent(t[1].c_str(), t[2].c_str(), argc, argv);
@@ -1201,7 +1204,7 @@
 	// Stores script lines with additional context information
 	vector< LineWithContext >

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

[Gert Wollny]

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.
Also I'd like to know th opinion of the gcc maintainers on whether this
is really a bug, or a new c++ feature I'm not aware of. 

If #829604 is for real, I will open a whishlist bug instead that asks
for removing -std=c++03 and and the according blocker. 

best, 
Gert 


[1]  https://bugs.debian.org/829604

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

[Gert Wollny]

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

[Gert Wollny]

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

[Gert Wollny]

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 

  apt source idba 

no patches are applied or even listed. In the svn are two patches
however that are from 2014. They seem to be partially applied now, so
I've disabled one, and rebased the other. 

Also, when I run 

  svn-buildpackage 

the source tarball is not properly unpacked leaving me with an empty
tree and finally with an empty package. However, when I do 

   svn-buildpackage -S 

then the resulting source package is fine - i.e. I can unpack with
dpkg-source -x and compile it. 

Best, 
Gert 

Bug#811682: Updated patch

[Gert Wollny]

Hi,

I've updated the patch according to my last comment and also tested it
with g++-5 (i.e. without -std=c++11) and it  builds successfully. 

Note however that their are lintian errors: 

E: libgtkmathview-dev: pkg-config-multi-arch-wrong-dir
usr/lib/pkgconfig/gtkmathview-gmetadom.pc full text 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 2016 13:25:00 +0200
Description: gcc 6.0 build fixes
Bug: https://bugs.debian.org/811682

--- a/src/engine/common/View.cc
+++ b/src/engine/common/View.cc
@@ -291,7 +291,7 @@
 	  }
 }
 
-  return false;
+  return SmartPtr();
 }
 
 bool
--- a/src/backend/common/tfm/TFM.hh
+++ b/src/backend/common/tfm/TFM.hh
@@ -37,7 +37,7 @@
 unsigned char face;
 const char* codingScheme;
 int designSize;
-int checksum;
+unsigned int checksum;
 unsigned int nDimensions;
 unsigned int nCharacters;
   };
@@ -52,7 +52,7 @@
   struct Kerning
   {
 UChar8 index;
-int value;
+unsigned int value;
   };
 
   struct Ligature
@@ -67,7 +67,7 @@
 UChar8 index;
 int width;
 int height;
-int depth;
+unsigned int depth;
 int italicCorrection;
 unsigned char nKernings;
 const Kerning* kerning;
--- a/src/backend/common/ComputerModernShaper.cc
+++ b/src/backend/common/ComputerModernShaper.cc
@@ -578,7 +578,7 @@
   };
 #endif
 
-static ComputerModernShaper::PlainChar cmsMap[] =
+static ComputerModernShaper::PlainChar32 cmsMap[] =
   {
 { 0x007B, 0x66 },  // LEFT CURLY BRACKET
 { 0x007D, 0x67 },  // RIGHT CURLY BRACKET
--- a/src/backend/common/StandardSymbolsShaper.hh
+++ b/src/backend/common/StandardSymbolsShaper.hh
@@ -32,20 +32,20 @@
   struct HStretchyChar
   {
 Char16 ch;
-Char8 normal;
-Char8 left;
-Char8 glue;
-Char8 right;
+UChar8 normal;
+UChar8 left;
+UChar8 glue;
+UChar8 right;
   };
   
   struct VStretchyChar
   {
 Char16 ch;
-Char8 normal;
-Char8 top;
-Char8 glue;
-Char8 middle;
-Char8 bottom;
+UChar8 normal;
+UChar8 top;
+UChar8 glue;
+UChar8 middle;
+UChar8 bottom;
   };
 
 protected:
--- a/src/backend/common/StandardSymbolsShaper.cc
+++ b/src/backend/common/StandardSymbolsShaper.cc
@@ -29,7 +29,7 @@
 #include "ShapingContext.hh"
 
 struct GlyphMap {
-  Char8 index;
+  UChar8 index;
   Char16 ch;
 };
 

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

[Gert Wollny]

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

[Gert Wollny]

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

[Gert Wollny]

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 this point this
would be a waste of computing cycles.) 

Best, 
Gert

Bug#816569: Also need to fix libzeep first

[Gert Wollny]

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

[Gert Wollny]

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

[Gert Wollny]

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 binaries. 

best, 
Gert 


 

Bug#821731: CTK FTBFS

[Gert Wollny]

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
https://github.com/commontk/CTK/issues/358

Best, 
Gert 

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

[Gert Wollny]

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
compiling with VTK_LEGACY_REMOVE defined.

VTK 6.3 is available from experimental. 

Best, 
Gert

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

[Gert Wollny]

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 about problem with integrated cards
> Qt 5 and VTK 6, I will be delighted!
Last week I came across a shader compiler problem on Intel that that
could be fixed by changing the shader code [2], but I guess that is
unrelated. 

Best, 
Gert 

[1] http://stackoverflow.com/questions/26944831/using-qvtkwidget-and-qo
penglwidget-in-the-same-ui
[2] https://github.com/gerddie/ginkgocadx/issues/18

Bug#820635: igstk: depends on vtk 5

[Gert Wollny]

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: 

 - no vtk6 
 - The Qt GUI requires that vtk is compiled with Qt support, 
   but it uses QT4 and vtk6 is build against QT5

At this point I gave up, and looked at the project activity: The
developers list has below one mail a month, in the last three years and
it's mostly unanswered questions, and the user list is likewise very
low traffic and there are two mail that spell out the missing VTK6
support. 

> If nobody raises his hand to volunteer maintaining this package in a
> short time frame I'd be fine with removing it.
I pass on this one. The project is hosted by Kitware, and somehow I
suspect that they would continue maintaining it if there was serious
interest. 

Best, 
Gert 

Bug#820635: igstk: depends on vtk 5

[Gert Wollny]

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

[Gert Wollny]

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-
gnu/src/fslview/../../../src/fslview/overlayinfodialog.h:13:0,
 from /home/gerddie/packages-other/fslview-4.0.1/obj-
x86_64-linux-gnu/src/fslview/moc_overlayinfodialog.cxx:9:
/home/gerddie/packages-other/fslview-4.0.1/obj-x86_64-linux-
gnu/src/fslview/overlayinfodialogbase.h:27:33: fatal error:
Qt3Support/Q3GroupBox: No such file or directory

Best, 
Gert 

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

[Gert Wollny]

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 { double __d; int __i[2]; }) {__d: __x}).__i[1]
   ^
/usr/include/i386-linux-gnu/bits/mathinline.h:948:55: error: member
reference base type 'void' is not a structure or union
  (union { double __d; int __i[2]; }) {__d: __x}).__i[1]

As you can see, this  is actually a bug in castxml, which is used to parse
the files and create XML descriptions of the code as an intermediate step
to create Python bindings. CastXML uses LLVM as a backend, hence there may
be incompatibilities.

Since I'm currently on mobile devices only and don't have my GitHub
password, would you please consider filing a bug upstream [1] . They are
quite responsive (at least on weekdays).

Best,
Gert

[1] https://github.com/CastXML/CastXML

Bug#810946: manage bugs

[Gert Wollny]

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 a workaround is in place. 

Best, 
Gert 

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

[Gert Wollny]

> Gert seemed to know what was up with this, and TBH I don't really
> understand what he wrote...
Well, there was  bug #808491 (now resolved) in ITK+GDCM that made
builds against ITK fail, that's why I set it as blocker. 

Andreas Beckmann already requested a NMU (i.e. re-opend the NMU bug
#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

[Gert Wollny]

> https://buildd.debian.org/status/package.php?p=plastimatch
> 
> this was done today (I didn't notice it).
> So, amd64 and i386 succeeded, but all the other failed.
> nice.  no ^^
> 
> Do you know something about this too?

Well, I'm not sure what are the problems there in the actual build, it
seems there ITK would have to be rebuild against gdcm-2.6, 
but on these archs insighttoolkit4 is not available, and since
insighttoolkit3 will be phased out soon, I'm not sure whether we should
bother requesting a rebuild of the latter. 

Eventually, we will have to drop 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 as a uid...)
> sorry.
No worries, that was more like a copy-paste hint to Andreas, and as for
using  name/surname as a uid, that's actually the way it is written in
the DM wiki. 

Best, 
Gert

Bug#805170: ginkgocadx transition

[Gert Wollny]

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 fix that I have done before in other packages, but dcmtk
will require some work.

I was going to look into this, but if you're on it I won't interfere. 

Best, 
Gert 

Bug#789931: tag this as wontfix/severity normal

[Gert Wollny]

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 not (yet) supported by insighttoolkit4 and the arch
support depends on upstream. Hence the downgrade and tag.

Bast, 
Gert 

Bug#793607: FTBFS against QT5

[Gert Wollny]

Hello, 

the error actually stems from the handling of the QT5 includes an
libraries. The attached patch corrects this problem. 

Note that you will also have to build depend on libvtk6-qt-dev (instead
of only libvtk6-dev). 

(There is an open issue with libvtk6-qt-dev that I didn't report 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-Update: 2016-01-10

--- nifti2dicom-0.4.9.orig/src/gui/CMakeLists.txt
+++ nifti2dicom-0.4.9/src/gui/CMakeLists.txt
@@ -50,6 +50,10 @@ endif()
 if(Nifti2Dicom_QT_VERSION EQUAL 5)
 qt5_wrap_cpp(qnifti2dicom_MOC_SRCS ${qnifti2dicom_MOC_HDR})
 qt5_add_resources(qnifti2dicom_QRC_SRCS ${qnifti2dicom_QRC_RCC})
+set(QT_QTCORE_INCLUDE_DIR ${Qt5Core_INCLUDE_DIR})
+set(QT_QTCOREGUI_INCLUDE_DIR ${Qt5Gui_INCLUDE_DIR})
+set(QT_QTCORE_LIBRARY ${Qt5Core_LIBRARIES})
+set(QT_QTGUI_LIBRARY ${Qt5Gui_LIBRARIES})
 else()
 qt4_wrap_cpp(qnifti2dicom_MOC_SRCS ${qnifti2dicom_MOC_HDR})
 qt4_add_resources(qnifti2dicom_QRC_SRCS ${qnifti2dicom_QRC_RCC})

Bug#793607: nifti2dicom: FTBFS against VTK 6.2

[Gert Wollny]

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 that depend
on insighttoolkit* will have to drop all non-intel architectures. 

Best, 
Gert 

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724711

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

[Gert Wollny]

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)

best, 
Gert 
 

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

[Gert Wollny]

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

[Gert Wollny]

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 
> > 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.
> 
> Sounds sensible.  Do you need any help for this?

Well, it turns out that Emilio from the release team already tried to
build ITK against the new gdcm. 

Which means this bug is now blocked by #808491, which is something for
which I need help from upstream ITK and/or GDCM. 

Best,  
Gert