Bug#1000320: RM: ginkgocadx -- ROM; FTBS; dead upstream

[Gert Wollny]

Package: ftp.debian.org
Severity: normal

The package has been abandoned by upstream, requires old versions of
libraries (vtk6), and forward porting is not an option, beause it would
either require a rewrite of the renderer, or need another package that
is not in Debian, namely wxWidgests >= 3.1 which is blocked on #919903

Thanks, 
Gert

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

[Gert Wollny]

With 'mem_encrypt=off' the kernel boots fine, thanks for the pointer. 

@Bastian: I'm not sure I understand why you downgraded the bug to
important (I could have understood serious, grave). 

When the package is installed as is, one can't boot from this kernel,
so the package should not got into testing as is, and for that reason
the severity should be "serious" at least (But I don't want to go into
a severity fight, so I don't add a control line to change this).

Best, 
Gert  

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#994449: linux-image-5.14.0-trunk-amd64: Please enable CONFIG_UDMABUF

[Gert Wollny]

package: src:linux
Version: 5.14.3-1~exp1
Severity: wishlist

Dear Maintainer,

UDMABUF is useful qemu, and required to get blob support, which in turn
is needed by mesa/virgl to get support for ARB_buffer_storage and
OpenGL 4.4 in the guest, and Vulkan support in the guest.

Many thanks,
Gert

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#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#941664: RM: vtk6-doc,vtk6-examples -- NBS;not built anymore

[Gert Wollny]

Control: -1 -moreinfo 

The dependency was fixed with gdcm-3.0.4-2 (just uploaded) 

Thanks, 
Gert

 

Bug#941664: vtk6: was the removal of vtk6-examples and vtk6-doc intentional?

[Gert Wollny]

Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: vtk6-doc,vtk6-examples -- NBS;not built anymore

Yes, the removal was intentional, since vtk6 is EOL upstream and will
get phased out slowly, 

Best, 
Gert 

Bug#943677: please package insighttoolkit5 (5.0 and 5.1 beta 1 are out)

[Gert Wollny]

Since I'm no longer working on anything related to image processing
that would require ITK (or its dependent packages) I'm not very
dedicated to package this, especially since packaging ITK really needs
a lot of work an time. 

Especially the python bindings are a nuisance, it is quite difficult to
get them to pass the tests reliably, and they increase the build time
quite *a lot*. So if we agree to drop these I might give it a shot. I
would package this as a all new package insighttoolkit5, to not
interfere with what is currently build against insighttoolkit4 (need to
disable one rather useless python test in 4.13.1 to get it pass). 

Best, 
Gert 

  

Am Sonntag, den 27.10.2019, 16:56 -0400 schrieb Yaroslav Halchenko:
> 
> While preparing a new package,
> https://github.com/InsightSoftwareConsortium/ITK/issues/1200#issuecomment-
> 524836729
> might be of relevance -- please build/ship with  Module_ITKReview On,
> or would
> it be too much?
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (600, 'unstable'), (300, 'experimental'), (100,
> 'unstable-debug'), (100, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8),
> LANGUAGE=en_US.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 

Bug#937480: pymia: Python2 removal in sid/bullseye

[Gert Wollny]

Hi Sandro, 

NMU is fine with me, as nearly all the packages in debian-med the
package is lowNMU, so no delay is necessary. 

Maybe next time consider to send the diff as merge request on salsa, it
makes it easier to apply ;) 

Best, 
Gert   

Bug#933414: ginkgocadx: Please rebuild against wxWidgets GTK 3 package

[Gert Wollny]

Am Mittwoch, den 31.07.2019, 12:58 +0200 schrieb Andreas Tille:
> Control: tags -1 help
> 
> Hi Gert,
> 
> As far as I can see /usr/bin/vtkParseOGLExt exists only in vtk6.
> 
> Could you please take over from here?

sure, 

Gert 

Bug#930277: unblock: gdcm_2.8.8-9

[Gert Wollny]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package gdcm-2.8.8-9 

The package is testing gdcm-2.8.8-6 FTBFS on some architectures
(#929718) because the provided .symbols file changes depending on the
build dependencies.

With version gdcm-2.8.8-9 the symbols file is dropped again because
this seem so be the only viable approach to alliviate this problem when
it comes to C++ libraries.

Many thanks, 
Gert 

unblock gdcm/2.8.8-9

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

Kernel: Linux 4.19.48-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
diff -Nru gdcm-2.8.8/debian/changelog gdcm-2.8.8/debian/changelog
--- gdcm-2.8.8/debian/changelog	2019-01-13 09:26:00.0 +0100
+++ gdcm-2.8.8/debian/changelog	2019-03-26 22:07:17.0 +0100
@@ -1,3 +1,24 @@
+gdcm (2.8.8-9) unstable; urgency=medium
+
+  * d/*.symbols: remove symbols file, with C++ libraries this
+just doesn't work well enough.
+
+ -- Gert Wollny   Tue, 26 Mar 2019 22:07:17 +0100
+
+gdcm (2.8.8-8) unstable; urgency=medium
+
+  * d/libvtkgdcm2.8a.symbols: Attempt to fix symbols on mips/mipsel
+
+ -- Gert Wollny   Tue, 26 Mar 2019 19:35:20 +0100
+
+gdcm (2.8.8-7) unstable; urgency=medium
+
+  [ Gianfranco Costamagna ]
+  * Fixup symbols file, mark as optional some symbols disappearing
+with a -O3 build
+
+ -- Gert Wollny   Fri, 08 Mar 2019 11:33:29 +0100
+
 gdcm (2.8.8-6) unstable; urgency=medium
 
   * d/p/fiX_charls_2: Fix compilation with CharLS-2.0
diff -Nru gdcm-2.8.8/debian/libvtkgdcm2.8a.symbols gdcm-2.8.8/debian/libvtkgdcm2.8a.symbols
--- gdcm-2.8.8/debian/libvtkgdcm2.8a.symbols	2019-01-13 09:26:00.0 +0100
+++ gdcm-2.8.8/debian/libvtkgdcm2.8a.symbols	1970-01-01 01:00:00.0 +0100
@@ -1,1001 +0,0 @@
-libvtkgdcm.so.2.8 libvtkgdcm2.8a #MINVER#
-* Build-Depends-Package: libvtkgdcm2-dev
- (regex|c++|optional)^_ZNK?4gdcm9Attribute.*@Base$ 2.8.7
- (regex|c++|optional)^_ZNK?4gdcm7Element.*@Base$ 2.8.7
- (regex|c++|optional)^_ZN?St.*@Base$ 2.8.7
- _Z23vtkImageRGBToYBRExecuteIaEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageRGBToYBRExecuteIcEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageRGBToYBRExecuteIdEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageRGBToYBRExecuteIfEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageRGBToYBRExecuteIhEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageRGBToYBRExecuteIiEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageRGBToYBRExecuteIjEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageRGBToYBRExecuteIlEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageRGBToYBRExecuteImEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageRGBToYBRExecuteIsEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageRGBToYBRExecuteItEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageRGBToYBRExecuteIxEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageRGBToYBRExecuteIyEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageYBRToRGBExecuteIaEvP16vtkImageYBRToRGBP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageYBRToRGBExecuteIcEvP16vtkImageYBRToRGBP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageYBRToRGBExecuteIdEvP16vtkImageYBRToRGBP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageYBRToRGBExecuteIfEvP16vtkImageYBRToRGBP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageYBRToRGBExecuteIhEvP16vtkImageYBRToRGBP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageYBRToRGBExecuteIiEvP16vtkImageYBRToRGBP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageYBRToRGBExecuteIjEvP16vtkImageYBRToRGBP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageYBRToRGBExecuteIlEvP16vtkImageYBRToRGBP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageYBRToRGBExecuteImEvP16vtkImageYBRToRGBP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageYBRToRGBExecuteIsEvP16vtkImageYBRToRGBP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageYBRToRGBExecuteItEvP16vtkImageYBRToRGBP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageYBRToRGBExecuteIxEvP16vtkImageYBRToRGBP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageYBRToRGBExecuteIyEvP16vtkImageYBRToRGBP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkLookupTable16MapDataIaEvP16vtkLookupTable16PT_Ptiii@Base 2.8.7
- _Z23vtkLookupTable16MapDataIcEvP16vtkLookupTable16PT_Ptiii@Base 2.8.7
- _Z23vtkLookupTable16MapDataIdEvP16vtkLookupTable16PT_Ptiii@Base 2.8.7
- _Z23vtkLookupTable16MapDataIfEvP16vtkLookupTable16PT_Ptiii@Base 2.8.7
- _Z23vtkLookupTable16MapDataIhEvP16vtkLookupTable16PT_Ptiii@Base 2.8.7

Bug#930275: unblock: dcmtk/3.6.4-2.1

[Gert Wollny]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package dcmtk

Upstream hasn't ported the package to use charls-2.yet, and the port
tried by me resulted in serious regressions (as reported in #923433). 

This upload removes the patch introducing the port to charls-2.0 and
the patch that forces the use of the system provided charls library,
since the old version charls-1 is no longer in the archives. As a
result dcmtk will  use the bundled version.

Many thanks, 

Gert 

unblock dcmtk/3.6.4-2.1

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

Kernel: Linux 4.19.48-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
diff -Nru dcmtk-3.6.4/debian/changelog dcmtk-3.6.4/debian/changelog
--- dcmtk-3.6.4/debian/changelog	2019-01-19 10:36:10.0 +0100
+++ dcmtk-3.6.4/debian/changelog	2019-05-28 21:39:19.0 +0200
@@ -1,3 +1,10 @@
+dcmtk (3.6.4-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Revert to convenient charls copy for now. Closes: #923433
+
+ -- Mathieu Malaterre   Tue, 28 May 2019 21:39:19 +0200
+
 dcmtk (3.6.4-2) unstable; urgency=medium
 
   * d/rules,d/p/03: Fix DATADIC path, Closes: #913304
diff -Nru dcmtk-3.6.4/debian/patches/series dcmtk-3.6.4/debian/patches/series
--- dcmtk-3.6.4/debian/patches/series	2019-01-19 10:36:10.0 +0100
+++ dcmtk-3.6.4/debian/patches/series	2019-05-28 21:29:41.0 +0200
@@ -1,8 +1,8 @@
 01_dcmtk_3.6.0-1.patch
-02_system_charls.patch
+#02_system_charls.patch
 03_datadic_install.patch
 04_Fixed-OFoptional-by-introducing-OFalign.patch
 05_performance.patch
 07_dont_export_all_executables.patch
 08_remove_system_processor.patch
-09_charls-2.0.patch
+#09_charls-2.0.patch

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#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#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#906535: [Debian-med-packaging] Bug#906535: src:gdcm: Please support Python3

[Gert Wollny]

Hello Andreas, 

the python3 version is already in experimental, so you should be able
to upload the new version of invesalius there and test it. 

I'll take care of the upload of the python3 supporting version of gdcm
to sid when I'm back from my vacations. 

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#901635: itksnap: Crashes when opening example file

[Gert Wollny]

*
> ITK-SNAP: Segmentation fault
> BACKTRACE: 
> /usr/lib/snap-3.6.0/ITK-
> SNAP(_Z24SegmentationFaultHandleri+0x144)[0xc5627d14]
> /lib/x86_64-linux-gnu/libc.so.6(+0x34f00)[0x7f02a322ff00]
> /usr/lib/x86_64-linux-gnu/dri/i965_dri.so(+0x45d4c8)[0x7f0281dcb4c8]
> /usr/lib/x86_64-linux-gnu/dri/i965_dri.so(+0x455968)[0x7f0281dc3968]
> /usr/lib/x86_64-linux-gnu/dri/i965_dri.so(+0x447d70)[0x7f0281db5d70]
> /usr/lib/x86_64-linux-gnu/dri/i965_dri.so(+0x1edc1e)[0x7f0281b5bc1e]
> /usr/lib/x86_64-linux-gnu/dri/i965_dri.so(+0xa27f2)[0x7f0281a107f2]
> /usr/lib/x86_64-linux-gnu/dri/i965_dri.so(+0xb72d5)[0x7f0281a252d5]
Given this backtrace it is very likely a bug in the Intel graphics
driver, at least I could not reproduce it with my AMD card. 

Could you try running itksnap like 

   LIBGL_ALWAYS_SOFTWARE=1 itksnap 

to see if it also crashes when the software rasterer is used for
OpenGL?

Best, 
Gert

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#897775: itksnap: ftbfs with GCC-8

[Gert Wollny]

Control: reassign -1 src:insighttoolkit4
Control: merge -1 897899

more of the same 

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#654839: retitle this to bring it up to date

[Gert Wollny]

Control: retitle -1 Paraview should use system VTK libraries

Unfortunately, upstream comented on this that it would be difficult to
use a seperate version of VTK because their development process just
doesn't take care of this. See, e.g. this recent thread:  

https://lists.debian.org/debian-science/2018/03/msg00048.html

Therefore, I keep that at severity wishlist. 

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#895900: invesalius: Please port to python3

[Gert Wollny]

Package: invesalius
Version: 3.1.1-3
Severity: important

Dear Maintainer,

Invesalius is the only package that depends on python-*gdcm, and gdcm
is currently 
going to a transition to provide python3-*gdcm instead. 

This change is also imposed by moving forward with VTK for which we now
also provide 
python3 packages. Unfortunately both, vtk and gdcm, don't make it easy
to provide bindings for both 
python 2 and 3 in one build (and if they would, I'm not sure whether
they would be 
co-installable). 

python3-vtk7 is now available in unstable, and python3-*gdcm is in
experimental, so please consider 
porting the package to python3, or co-ordinate with upstream to do so. 

Many thanks,
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#890891: systemd: PID1 getting stuck printing "systemd[1]: Time has been changed" continuously

[Gert Wollny]

Am Dienstag, den 20.02.2018, 15:31 +0100 schrieb Michael Biebl:
> 
> > Kernel: Linux 4.15.1-cm-fx6-my (SMP w/4 CPU cores; PREEMPT)
> 
> 
> Does this also happen with a Debian provided kernel? If so, which
> kernel version is that? 
I haven't tried this so far, for that reason I was initially also a bit
reluctant to report the bug here and I didn't report anything against
the kernel package. There is another problem: reproducing the bug is
not straightforward: in theory I should be able to trigger it by
setting the clock to a time past the year 2038, but hwclock doesn't let
me, and unplugging the device also doesn't switchset the RTC to a bogus
value right away.

> Which hardware?

Utilite pro (i.e. Freescale i.MX6 Quad) with the RTC EM Microelectronic
EM3027. While other kernel drivers, like rtc-mv.c, have a fail-save
against dates past 2038 that should alleviate the problem, this clock
driver hasn't.

Bug#890891: systemd: PID1 getting stuck printing "systemd[1]: Time has been changed" continuously

[Gert Wollny]

Am Dienstag, den 20.02.2018, 14:09 +0100 schrieb Michael Biebl:
> 
> As for the other cases, those are all hypothetical at this point,
> right?
> 

Yes, and that's why I did set this bug to severity normal and not
higher. 

In the original bug report I just wanted to point out that there might
be a problem beyond the bug in 32-bit kernels, a problem that may make
it worthwhile to add some kind of input validation (in this case just
to deflect a flooding with messages) to systemd/timerfd instead of
waiting for the kernel to fix the RTC related problem.

Bug#890891: systemd: PID1 getting stuck printing "systemd[1]: Time has been changed" continuously

[Gert Wollny]

Am Dienstag, den 20.02.2018, 13:33 +0100 schrieb Michael Biebl:
> Am
> 
> > make it lock up in this loop, but if someone can spoof this kind of
> > message and the system locks up because of this, wouldn't this be a
> > typical DoS attack?
> 
> How could an unprivileged user spoof such messages?

I am by no means a security expert, but doesn't the story usually go:
someone finds a bug that allows an escalation of rights that allows
them to do certain things, in the extreme case they can open a root
shell, in another case they may be able to set the RTC to a bogus value
that triggers the kernel to flood timerfd with messages that lock up
the system. Of course that is not a very likely scenario, but to me it
seems possible.

Bug#890891: systemd: PID1 getting stuck printing "systemd[1]: Time has been changed" continuously

[Gert Wollny]

Am Dienstag, den 20.02.2018, 12:56 +0100 schrieb Michael Biebl:
> Am 20.02.2018 um 12:40 schrieb Gert Wollny:
> > However, while upstream is certainly correct that a kernel bug is
> > the trigger of  the lockup, systemd should not hang on this,
> > because if sending messages to systemd can lock up the system then
> > this is actually an attack vector for a DoS attack. 
> 
> How is this an attack vector for a DoS attack? Please elaborate
> 
I don't really know by which channel systemd gets these messages that
make it lock up in this loop, but if someone can spoof this kind of
message and the system locks up because of this, wouldn't this be a
typical DoS attack?

In summary, systemd has no control over the messages the kernel sends,
so it should  treat the kernel as a possibly unreliable source, and if
only because also the kernel has bugs that might result in flooding
systemd with bogus messages like here.

Best,
Gert 

Bug#890891: systemd: PID1 getting stuck printing "systemd[1]: Time has been changed" continuously

[Gert Wollny]

Package: systemd
Version: 236-3
Severity: normal
Tags: upstream

Dear Maintainer,

on an 32 bit arm system when the RTC is set to a wrong time booting the system 
might 
fail because systemd gets stuck in a loop printing "systemd[1]: Time has been 
changed". 

The problem is known upstream and claimed to be a problem of the kernel: 
  https://github.com/systemd/systemd/issues/1143

However, while upstream is certainly correct that a kernel bug is the trigger 
of 
the lockup, systemd should not hang on this, because if sending messages to 
systemd 
can lock up the system then this is actually an attack vector for a DoS attack. 

A approach to work around this problem is posted in above bug report by user 
wtarreau and 
repeated here (comment included): 

  Basically manager_clock_watch() could start with something more or less like 
this
  (assuming it's the one responsible for this endless loop) :

   gettimeofday(, NULL);
   if (m->last_change == now.tv_sec) {
  m->change_count++;
   }
   else {
  if (m->change_count > 1)
 log("Time changed %d times in the last second\n", m->change_count);
  if (m->change_count >= 100) {
 log("Timerfd is broken on this system, disabling time change 
detection\n");
 manager_listen_stop(m);
 return 0;
  }
  m->change_count = 0;
  m->last_change = now.tv_sec;
   }

Best, 
Gert 

-- Package-specific info:

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: armhf (armv7l)

Kernel: Linux 4.15.1-cm-fx6-my (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  adduser 3.117
ii  libacl1 2.2.52-3+b1
ii  libapparmor12.12-2
ii  libaudit1   1:2.8.2-1
ii  libblkid1   2.30.2-0.3
ii  libc6   2.26-6
ii  libcap2 1:2.25-1.2
ii  libcryptsetup4  2:1.7.5-1
ii  libgcrypt20 1.8.1-4
ii  libgpg-error0   1.27-6
ii  libidn111.33-2.1
ii  libip4tc0   1.6.2-1
ii  libkmod225-1
ii  liblz4-10.0~r131-2+b1
ii  liblzma55.2.2-1.3
ii  libmount1   2.30.2-0.3
ii  libpam0g1.1.8-3.7
ii  libseccomp2 2.3.1-2.1
ii  libselinux1 2.7-2+b1
ii  libsystemd0 236-3
ii  mount   2.30.2-0.3
ii  procps  2:3.3.12-3
ii  util-linux  2.30.2-0.3

Versions of packages systemd recommends:
ii  dbus1.12.4-1
ii  libpam-systemd  236-3

Versions of packages systemd suggests:
ii  policykit-10.105-18
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
pn  initramfs-tools  
ii  udev 236-3

-- no debconf information

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#885045: amide: Depends on old GNOME libraries

[Gert Wollny]

Hello Andreas Henriksson,

thanks for digging into the code to see what's going on.

I'll give the porting it a shot as soon as  can.

Regarding gnome-canvas: are there already plans to drop that too, and
what is actually the suggested replacement for it (The Gnome porting
guide doesn't mention anything)?

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#845032: valgrind: unusable on amd64: false-positive Illegal opcode at address ..

[Gert Wollny]

Hi, 

Trying the packaged version of darktable in unstable with the packaged
version of valgrind (3.13.0-1) was not able to reproduce the error. 

However, I have seen a similar error with another program compiled with
the usual Debian flags. 

With a self compiled version you probably have enabled some instruction
set that valgrind does not (yet) support. You might consider disabling
some instruction sets (like xop etc.). 

The attached patch makes it possible for me to run the program that
failed, and it also helps me on Gentoo, where I compile with 
"-march=native -fno-xop" on an AMD FX 6300 processor.

If I enable "xop" other instructions are generated that are not
supported by valgrind. 

Best, 
Gert 






Author: chzchz...@gmail.com with fixes from Petr Pisar 
Description: Add bextr support to valgrind
Bug: https://bugs.kde.org/show_bug.cgi?id=322586
Debian-Bug: https://bugs.debian.org/845032

Index: VEX/priv/guest_amd64_toIR.c
===
--- a/VEX/priv/guest_amd64_toIR.c	(revision 2763)
+++ b/VEX/priv/guest_amd64_toIR.c	(working copy)
@@ -1,4 +1,3 @@
-
 /**/
 /*--- begin guest_amd64_toIR.c ---*/
 /**/
@@ -673,6 +672,8 @@
 #define PFX_VEXnV1 (1<<19)   /* ~VEX [1], if VEX present, else 0 */
 #define PFX_VEXnV2 (1<<20)   /* ~VEX [2], if VEX present, else 0 */
 #define PFX_VEXnV3 (1<<21)   /* ~VEX [3], if VEX present, else 0 */
+#define PFX_VEXn (PFX_VEXnV0 | PFX_VEXnV1 | PFX_VEXnV2 | PFX_VEXnV3)
+#define PFX_XOP(1<<22)   /* XOP prefix present (0x8F) */
 
 
 #define PFX_EMPTY 0x5500
@@ -30569,6 +30570,100 @@
 
 /**/
 /*---  ---*/
+/*--- Top-level post-escape decoders: dis_ESC_0F3A__XOP---*/
+/*---  ---*/
+/**/
+__attribute__((noinline))
+static
+Long dis_ESC_0F3A__XOP(
+/*MB_OUT*/DisResult* dres,
+/*OUT*/   Bool*  uses_,
+Bool (*resteerOkFn) ( /*opaque*/void*, Addr64 ),
+Bool resteerCisOk,
+void*callback_opaque,
+VexArchInfo* archinfo,
+VexAbiInfo*  vbi,
+Prefix pfx, Int sz, Long deltaIN 
+ )
+{
+   IRTemp addr  = IRTemp_INVALID;
+   Intalen  = 0;
+   HChar  dis_buf[50];
+   Long   delta = deltaIN;
+   UChar  opc   = getUChar(delta);
+   delta++;
+   *uses_ = False;
+
+   switch (opc) {
+  /* BEXTR r32b, r/m32, imm32 = XOP.0..LZ.00 0x10 /r /id */
+  /* BEXTR r64b, r/m64, imm32 = VEX.W..LZ.00 0x10 /r /id */
+  case 0x10:
+  if ((pfx & PFX_VEXn) == 0 && 0==getVexL(pfx)/*LZ*/) {
+ Int size  = getRexW(pfx) ? 8 : 4, ctrl;
+ UChar   start, len, opsize;
+ IRType  ty= szToITy(size);
+ IRTemp  dst   = newTemp(ty);
+ IRTemp  src1  = newTemp(ty);
+ UChar   rm= getUChar(delta);
+
+ if (epartIsReg(rm)) {
+delta++;
+ctrl = getSDisp32(delta);
+assign( src1, getIRegE(size,pfx,rm) );
+DIP("bextr %x,%s,%s\n", ctrl,
+nameIRegE(size,pfx,rm), nameIRegG(size,pfx,rm));
+ } else {
+addr = disAMode ( , vbi, pfx, delta, dis_buf, 0 );
+delta += alen;
+ctrl = getSDisp32(delta);
+assign( src1, loadLE(ty, mkexpr(addr)) );
+DIP("bextr %x,%s,%s\n", ctrl, dis_buf, nameIRegG(size,pfx,rm));
+ }
+
+ delta += 4; /* += control immediate */
+
+ start = ctrl & 0xff;
+ len = (ctrl >> 8) & 0xff;
+ opsize = 8*size;
+
+ if ((start + len) < opsize) {
+if (len == 0) {
+   assign(dst, mkU(ty, 0));
+} else {
+   assign (dst, 
+   binop(mkSizedOp(ty,Iop_Shr8),
+ binop(
+mkSizedOp(ty,Iop_Shl8),
+mkexpr(src1),
+mkU8(opsize-start-len)),
+ mkU8(opsize - len)));
+}
+ } else {
+if (start < opsize) {
+   assign(dst, binop(
+	  mkSizedOp(ty,Iop_Shr8), mkexpr(src1), mkU8(start)));
+} else {
+   assign(dst, mkU(ty, 0));
+}
+ }
+
+ putIRegG( size, pfx, rm, mkexpr(dst) );
+ stmt( IRStmt_Put( OFFB_CC_OP, mkU64(size == 8
+  ? AMD64G_CC_OP_ANDN64
+  : AMD64G_CC_OP_ANDN32)) );
+ stmt( IRStmt_Put( OFFB_CC_DEP1, widenUto64(mkexpr(dst))) );
+ stmt( IRStmt_Put( OFFB_CC_DEP2, 

Bug#873865: relion: Please add arm64

[Gert Wollny]

Hi Roland, 

You restricted the archs of that package? Was there any specific
problem? Otherwise I'd enable all arch, upload, and see what sticks. 

Best, 
Gert 

Bug#879194: [xfce4-session] Please add mate-screensaver to xflock4

[Gert Wollny]

Package: xfce4-session
Version: 4.12.1-5
Severity: wishlist
Tags: patch

Dear maintainers, 

mate-screensaver is another alternative for a screensaver that would be
a nice-have within the list that xflock4 can use. 

Please find a patch attached that updates d/patches/03 accordingly to
add this screensaver. 

many thanks, 
Gert  

--- System information. ---
Architecture: 
Kernel:   Linux 4.13.0-1-amd64

Debian Release: buster/sid
  500 testing ftp.it.debian.org 
  500 stable  dl.google.com 

--- Package information. ---
Depends  (Version) | Installed
==-+-=
libatk1.0-0(>= 1.12.4) | 2.26.0-2
libc6   (>= 2.3.4) | 
libcairo2   (>= 1.2.4) | 
libdbus-1-3(>= 1.9.14) | 
libdbus-glib-1-2 (>= 0.88) | 
libfontconfig1   (>= 2.12) | 
libfreetype6(>= 2.2.1) | 
libgdk-pixbuf2.0-0 (>= 2.22.0) | 
libglib2.0-0   (>= 2.37.3) | 
libgtk2.0-0(>= 2.24.0) | 
libice6   (>= 1:1.0.0) | 
libpango-1.0-0 (>= 1.14.0) | 
libpangocairo-1.0-0(>= 1.14.0) | 
libpangoft2-1.0-0  (>= 1.14.0) | 
libpolkit-gobject-1-0   (>= 0.101) | 
libsm6 | 
libwnck22  (>= 2.30.7) | 
libx11-6   | 
libxfce4ui-1-0  (>= 4.9.1) | 
libxfce4util7   (>= 4.9.0) | 
libxfconf-0-2   (>= 4.6.0) | 
xfce4-settings (>= 4.10.0) | 
xfconf | 


Recommends (Version) | Installed
-+-===
xfwm4| 4.12.4-1
xfdesktop4   | 4.12.3-4
libpam-systemd   | 235-2
systemd-sysv | 235-2
 OR systemd-shim | 
upower   | 0.99.6-1
dbus-x11 | 1.11.20-1
x11-xserver-utils| 7.7+7+b1
light-locker | 1.8.0-1


Suggests  (Version) | Installed
===-+-===
sudo| 1.8.21p2-2
fortunes-mod| 
pm-utils| diff -u xfce4-session-4.12.1/debian/patches/03_add-light-locker-to-xflock4.patch xfce4-session-4.12.1.new/debian/patches/03_add-light-locker-to-xflock4.patch
--- xfce4-session-4.12.1/debian/patches/03_add-light-locker-to-xflock4.patch	2015-03-04 08:15:58.0 +0100
+++ xfce4-session-4.12.1.new/debian/patches/03_add-light-locker-to-xflock4.patch	2017-10-20 11:39:23.049795662 +0200
@@ -1,9 +1,10 @@
 --- a/scripts/xflock4
 +++ b/scripts/xflock4
-@@ -27,6 +27,7 @@ export PATH
+@@ -27,6 +27,8 @@
  # Lock by xscreensaver or gnome-screensaver, if a respective daemon is running
  for lock_cmd in \
  "xscreensaver-command -lock" \
++"mate-screensaver-command --lock" \
 +"light-locker-command --lock" \
  "gnome-screensaver-command --lock"
  do

Bug#868383: amide: Please drop the (build-)dependency against gnome-vfs

[Gert Wollny]

amide pulls in gnome-vfs via libgnomeui and calls gnome-vfs also
directly. Unless upstream is changing this I don't see that there is a
good chance to remove this dependency. 

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#779655: [Debian-med-packaging] Bug#866434: invesalius: depends on obsolete python-imaging (replace with python3-pil or python-pil)

[Gert Wollny]

Patch pushed to packaging git, but someone should test it on real data.

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#731433: dcmtk: iteration 9396u invokes undefined behavior [-Waggressive-loop-optimizations]

[Gert Wollny]

Control: tags -1 wontfix

This warning is only relevant for 16 bit Jpegs and the comment in the
source code states: 

dcmjpeg/libijg16/jccolor.c

 16-bit per pixel is used with lossless JPEG only, and we don't convert
 RGB to YCC in lossless mode.

hence the code should never be run in this case. 

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#872319: insightoolkit4: Re-enable python bindings

[Gert Wollny]

Package: insightoolkit4
Version: 4.12.0-dfsg1-2
Severity: normal

Python bindings were (temporary) disabled because of a bug with Castxml 
#871573. 

This bug is here to track re-enabling these bindings 

--
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#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#724711: [Debian-med-packaging] Bug#724711: Bug#724711: insighttoolkit4: Drops architecture support

[Gert Wollny]

Am Donnerstag, den 10.08.2017, 08:33 +0100 schrieb Edmund Grimley
Evans:
> > As far as I can see all tests are disabled, failing tests means
> > that
> > the software has bugs, and I'm not sure whether we want to allow
> > software with known bugs into the archives.
> 
> Yes, but if the bug is in the test then disabling the test is one way
> of fixing the bug.
Well, in some cases this might indeed be the case, but ... 


> 
> On the other hand, a test failure on one architecture might (and, in
> a sense, quite likely does)
> indicate a bug in all architectures, so perhaps, to be on the safe
> side...
one typical problem is, that some archs handle "char" as signed and
others as unsigned, and if someone uses char as an int8, then this
results in test failures on one arch but not on the other. This might
be a logical bug on the arch where the test does not fail, but is
doesn't result in wrong calculations.

> 
> Has anyone looked at the failures in detail? If they look like they
> could easily be a consequence of differences in the results of
> floating-point calculations I'd say just disable them for now. If
> there's a segfault, that might be worth investigating.
Unfortunately it is also not that simple: Once I had a bug in some
package I'm actually upstream of where the conversion from a (signed)
float to an unsigned int was handled differently on different archs, in
one case the floating point value was clamped to be non-negative and
then converted, in the other case it was converted to a singed int and
then bit-wise copied to an unsigned, which results in big values for a
negative input, and this is the kind of error I certainly would not
want to ignore. 

In summary, the package is too big for me to fix bugs like these in my
spare time, usually I just forward bugs to upstream, but since they are
not interested in fixing other archs than amd64 and i386 I'm not going
to enable arm64 by myself. If someone else steps up and is willing to
fix bugs on other archs when users start to complain than this someone
is happily invited to co-maintain the package.

Best, 
Gert 

Bug#724711: [Debian-med-packaging] Bug#724711: insighttoolkit4: Drops architecture support

[Gert Wollny]

> Ubuntu built 4.9.0, 4.10.0 and 4.10.1 on arm64:
> 
> http://ports.ubuntu.com/ubuntu-ports/pool/universe/i/insighttoolkit4/
> 
> Though it looks like they may have ignored a few test failures to get
> there:
> 
> https://launchpad.net/ubuntu/+source/insighttoolkit4/+changelog

As far as I can see all tests are disabled, failing tests means that
the software has bugs, and I'm not sure whether we want to allow
software with known bugs into the archives. At the least it must be
documented which tests are failing. 

Gianfranco, since you did the upload to Ubuntu, could you comment on
this, and have you any idea whether upstream cares or someone else is
working on getting arm64 fixed?


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#870806: Also fails with 2.1.22

[Gert Wollny]

Control: forwarded -1 https://dev.gnupg.org/T3331

The problem persists with 2.1.22 (This I only tested on the host
system). 

There is also a related Gentoo bug: 

https://bugs.gentoo.org/show_bug.cgi?id=616096

I didn't try the workarounds described there though. 

Best, 
Gert 

Bug#870806: gpg: Address family not supported by protocol if kernel doesn't support ipv6

[Gert Wollny]

Control: tags -1 + upstream 

This is definitely an upstream problem. In my normal maintenance of my
Gentoo system I updated to gnupg 2.1.20, and it now also fails on the
host system unless I load the ipv6 kernel module, so the problem was
introduced somewhere between 2.1.15 and 2.1.20. 

I'll now check 2.1.22, and if it still fails I'll report a bug
upstream. 

 



 

Bug#870806: gpg: Address family not supported by protocol if kernel doesn't support ipv6

[Gert Wollny]

INFO
gpg: DBG: chan_3 -> D
pub::4096:1:02541A371530B71F:1395591437:1595083809::%0Auid:
1500475809Gert Wollny (DM key) <gw.foss...@gmail.com>:...1437:::
gpg: DBG: chan_3 -> D
%0Asub::2048:1:F81E368B9B26AB98:1445361906:1539969906::
%0A
gpg: DBG: chan_3 -> END
gpg: DBG: chan_3 <- ERR 167804933 Address family not supported by
protocol 
gpg: DBG: free_packet() type=6
gpg: DBG: free_packet() type=13
...
gpg: DBG: free_packet() type=14
gpg: DBG: free_packet() type=2
gpg: keyserver send failed: Address family not supported by protocol
gpg: keyserver send failed: Address family not supported by protocol
gpg: DBG: chan_3 -> BYE
gpg: DBG: [not enabled in the source] stop
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
  outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: secmem usage: 0/65536 bytes in 0 blocks

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

Versions of packages dirmngr depends on:
ii  adduser3.115
ii  libassuan0 2.4.3-2
ii  libc6  2.24-14
ii  libgcrypt201.7.8-2
ii  libgnutls303.5.14-2
ii  libgpg-error0  1.27-3
ii  libksba8   1.3.5-2
ii  libldap-2.4-2  2.4.45+dfsg-1
ii  libnpth0   1.5-2
ii  lsb-base   9.20161125

Versions of packages dirmngr recommends:
ii  gnupg  2.1.21-2

Versions of packages dirmngr suggests:
pn  dbus-user-session  
ii  libpam-systemd 234-2
pn  pinentry-gnome3
pn  tor

-- no debconf information

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#834493: Bogus value for vtkWrappingJava_RUNTIME_LIBRARY_DIRS

[Gert Wollny]

Control: tags -1 wontfix 

Hello Mathieu, 

It is true that vtk originally installs the vtk6.jar files into the
system library path that is indicated by
vtkWrappingJava_RUNTIME_LIBRARY_DIRS, but since this does not conform
to Debian policy, vtk6.jar is installed in /usr/share/java/ via
d/libvtk6-java.install.

However, the value for vtkWrappingJava_RUNTIME_LIBRARY_DIRS is created
as part of the general macros for modules in
/CMake/vtkModuleAPI.cmake which is somehow indirectly called by
vtk_module_library. Since both are generic macros used throughout the
VTK build system I don't think it is feasible to change the value from
withing the build system. 

The value could be corrected in d/rules, but since VTK6 is EOL upstream
the java module will probably be dropped after the stretch release (or
even all of vtk6), and for stretch itself the problem is not grave
enough to try to fix it now.

I will keep the bug open though and we may later reassign it to vtk7,
once that is packaged.

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#853419: All fail because ITK/vcl doesn't know gcc7

[Gert Wollny]

reassign 853419 insighttoolkit4
reassign 853460 insighttoolkit4
reassign 853386 insighttoolkit4
merge 853454 853386 853460 853419
affects 853454 ginkgocadx itksnap elastix 

thanks 


 

Bug#740296: SimpleITK

[Gert Wollny]

Am Samstag, den 28.01.2017, 15:48 + schrieb Ghislain Vaillant:
> What is the status of your packaging effort for simpleitk?
I never got past early tests to compile it. At that time I had a
certain interest in the package but that veined. 

> 
> This bug was switched back to RFP in 2014. 
Actually, it was not really "switched back", but only the title was
corrected because the original submitter didn't set the proper name. 

> Please confirm whether you are still working on it.
I'm not working on it. 

Best, 
Gert 

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#848590: llvm-toolchain-3.9: libclang-3.9-dev is missing cmake files

[Gert Wollny]

Source: llvm-toolchain-3.9
Version: 3.9.1-1
Severity: normal

Dear Maintainers,

For someone who is compiling using libclang-3.9-dev the current way to detect
the installation location by using cmake is to use FIND_PACKAGE(LLVM), since
here the required infomation about the root include directory is provided. As I
understand it, the installation location of the clang-dev include files is
always relative to the reported LLVM_INCLUDES path, and hence one can rely on
this test if one wants to use clang on a system that always install all
llvm/clang related debvelopment files.

However, in Debian the llvm related cmake files are installed with
libllvm-X.Y-dev and this package does not depend on libclang-3.9-dev. Hence, if
libclang-3.9-dev is not installed, but libllvm-3.9-dev is, then automatic
package detection will run without reporting an error, but later compilation
fails because the clang header files are not in the expected location, i.e.
they are missing.

To resolcve this it would be good if either the with libllvm-3.9-dev provided
cmake files would also check whether the clang development headers are
available, or if these cmake files are installed in a way that pulls in both,
libllvm-3.9-dev and libclang-3.9-dev.

Many thanks,
Gert



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

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

Bug#818505: sortmerna FTBFS on !x86

[Gert Wollny]

I think the best would be to restrict the package to amd64/i386/x32 and
add a preinst script that checks for sse2 support (see below). 

The only thing I wonder is whether there are legitimate cases wheer one
should be able to install the package non-functional.

Best, 
Gert 




#/bin/sh 
set -e 

grep sse2 /dev/cpuinfo 2>&1 >/dev/null 

if "x$?" = "x1" ]; then 
 echo "Your CPU doesn't have SSE2 support, but this package requires"
 echo "it, aborting installation."
 exit 1
fi 

exit 0 

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#796246: libc recently more aggressive about pthread locks in stable ?

[Gert Wollny]

Am Dienstag, den 15.11.2016, 18:06 +0200 schrieb Adrian Bunk:
> 
> > Unfortunately, in current unstable with thread sanitizer one might
> > get #796246 (at least I had this).
> 
> Does "-fsanitize=thread -no-pie" work for you?

Indeed, that fixed the problem with g++-6.2 (g++-5.4 doesn't has this
problem). 

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#796246: RES: FATAL: ThreadSanitizer: ... (confirmed with g++-6.2 but doesn't show up with g++-5.4)

[Gert Wollny]

I've can confirm the bug with g++-6 on Debian (unstable as of
2016/11/14). 

libtsan0: 6.2.0-13
g++-6: 6.2.0-13

When I compile the same software with g++-5 (5.4.1-3) in Debian or on
Gentoo using g++-5.4.0 the error does not occur.

In all cases the tsan library is libtsan.so.0.0.0. 

I've attached a test case that triggers the bug and also does double
un-locking of a mutex to trigger the thread sanitizer. 

The test program was compiled with 

 g++-5 -std=c++11 -fsanitize=thread -g double-unlock.cc -o \
   double-unlock-ts-5 

 g++-6 -std=c++11 -fsanitize=thread -g double-unlock.cc -o \
   double-
unlock-ts-6 

When running double-unlock-ts-5  the thread sanitizer reports the double mutex 
unlock (as expected). 

When running double-unlock-ts-6 the unexpected memory mapping error shows up as 
reported in this bug. 

Best, 
Gert 
#include 
#include 
#include 
#include 

using namespace std;

mutex g_mutex; 


void thread_function ()
{
g_mutex.lock();
cout << "One thread\n";

g_mutex.unlock();
g_mutex.unlock();
}


int main(int argc, const char ** args)
{
auto n_threads = thread::hardware_concurrency();

vector threads;

for (int i = 0; i < n_threads; ++i) 
threads.push_back(thread(thread_function));

for (int i = 0; i < n_threads; ++i) 
threads[i].join(); 

return 0; 

}

Bug#842796: libc recently more aggressive about pthread locks in stable ?

[Gert Wollny]

Am Sonntag, den 06.11.2016, 01:12 -0200 schrieb Henrique de Moraes
Holschuh:
> 
> 
> 
> Unfortunately, when hardware lock elision support was added to glibc
> upstream, libpthreads was *not* changed to properly assert() this
> forbidden condition on the non-hardware-elision codepaths.  Such an
> assert() would have given us consistent behavior, thus flushing the
> bugs out in the open... at the cost of a performance hit (I have no
> idea how severe), and much screaming.

An alternative to find problems with (un-)locking should be to compile
the program in question with -fsanitize=thread (on amd64) and run it.

Unfortunately, in current unstable with thread sanitizer one might get
#796246 (at least I had this).

Best, 
Gert 

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#836592: jessie-pu: package gdcm/2.4.4-3

[Gert Wollny]

As far as I can tell, the problem isn't the documentation, it's:

make[3]: *** No rule to make target
'/usr/lib/jvm/default-java/jre/lib/ppc64/libjawt.so', needed by
'bin/libvtkgdcmJava.so'.  Stop.



Agreed, I didn't see this because I was scanning for "error:".

The compilation failure is still unrelated to the patches though, 
because the patches only touch the C++ code, the compilation error is a 
result of some problem on the part that cmake does.


At the beginning of the build log one can even see that the library is 
correctly detected in the JRE ppc64el sub-directory, but later it wants 
ppc64 only and I can't find the according code in the gdcm VTK java 
module definition.


My suspect is SWIG_ADD_MODULE, but the according UseSWIG.cmake  this is 
part of cmake-data and there was no change in stable.  Swig2.0 might 
also be related, I saw it got two binary rebuilds on arm64 and one on 
ppc64el.


Best,
Gert

Bug#836592: jessie-pu: package gdcm/2.4.4-3

[Gert Wollny]

On 09.09.2016 03:03, Adam D. Barratt wrote:

On Mon, 2016-09-05 at 22:32 +0100, Adam D. Barratt wrote:



Unfortunately it FTBFS on ppc64el; see
https://buildd.debian.org/status/fetch.php?pkg=gdcm=ppc64el=2.4.4-3%2Bdeb8u1=1473373168


Hmm, this bug seem to be completely unrelated to the patch, and on the 
other archs I see the same errors related to the missing 'dot' and latex 
programs, and nothing else that would explain the build failure.


I should be able to fix these by adding doxygen-latex and graphviz to 
the build dependencies and do a new upload.


Best,
Gert

Bug#836592: jessie-pu: package gdcm/2.4.4-3

[Gert Wollny]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

Dear release team,

The version of gdcm in jessie suffers from two security problems:

  CVE-2015-8396 [1]
  CVE-2015-8397 [2]

However, the security team notified my that the issue does not warrant a DSA
and I should instead just fix it via a jessie point release.

The proposed patch against the package is enclosed, it adds the according fixes
from the upstream repository.

best regards,
Gert

[1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-8396
[2] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-8397



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

Kernel: Linux 4.6.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
diff -ruN gdcm-2.4.4/debian/changelog gdcm-2.4.4.new/debian/changelog
--- gdcm-2.4.4/debian/changelog	2014-10-06 08:08:33.0 +0100
+++ gdcm-2.4.4.new/debian/changelog	2016-08-23 18:45:09.415835673 +0100
@@ -1,3 +1,11 @@
+gdcm (2.4.4-3+deb8u1) jessie-proposed-updates; urgency=medium
+
+  * add patches:  
+- d/p/CVE-2015-8396.patch: fix according security vunerability
+- d/p/CVE-2015-8397.patch: fix according security vunerability
+
+ -- Gert Wollny <gw.foss...@gmail.com>  Sat, 20 Aug 2016 22:25:15 +0100
+
 gdcm (2.4.4-3) unstable; urgency=medium
 
   * Fix issue introduced by multiarch switch. Closes: #764029
diff -ruN gdcm-2.4.4/debian/patches/CVE-2015-8396.patch gdcm-2.4.4.new/debian/patches/CVE-2015-8396.patch
--- gdcm-2.4.4/debian/patches/CVE-2015-8396.patch	1970-01-01 01:00:00.0 +0100
+++ gdcm-2.4.4.new/debian/patches/CVE-2015-8396.patch	2016-08-20 23:23:27.990220328 +0100
@@ -0,0 +1,103 @@
+Author: Mathieu Malaterre <mathieu.malate...@gmail.com>
+Date:   Fri Dec 18 12:18:02 2015 +0100
+Description: Patches fixing CVE-2015-8396
+ Patches were backported from upstream commits 
+  92cd6d7 Always prefer boxRegion computation for area
+  9cbca25 Fix a case when Region was never initialized
+  e0dd111 Add an extra layer of check
+  0f6f820 Actually handle the case of error in ComputeBufferLength
+
+Index: gdcm-2.4.4/Source/MediaStorageAndFileFormat/gdcmImageRegionReader.cxx
+===
+--- gdcm-2.4.4.orig/Source/MediaStorageAndFileFormat/gdcmImageRegionReader.cxx
 gdcm-2.4.4/Source/MediaStorageAndFileFormat/gdcmImageRegionReader.cxx
+@@ -85,6 +85,7 @@ Region const ::GetRegi
+ size_t ImageRegionReader::ComputeBufferLength() const
+ {
+   // Is this a legal extent:
++  size_t npixels = 0;
+   if( Internals->GetRegion() )
+ {
+ if( !Internals->GetRegion()->IsValid() )
+@@ -92,10 +93,26 @@ size_t ImageRegionReader::ComputeBufferL
+   gdcmDebugMacro( "Sorry not a valid extent. Giving up" );
+   return 0;
+   }
++npixels = this->Internals->GetRegion()->Area();
+ }
+-  PixelFormat pixelInfo = ImageHelper::GetPixelFormatValue(GetFile());
+-  size_t bytesPerPixel = pixelInfo.GetPixelSize();
+-  return this->Internals->GetRegion()->Area()*bytesPerPixel;
++  else
++  {
++std::vector dims = ImageHelper::GetDimensionsValue(GetFile());
++BoxRegion full;
++// Use BoxRegion to do robust computation
++full.SetDomain(0, dims[0] - 1,
++   0, dims[1] - 1,
++   0, dims[2] - 1 );
++if( full.IsValid() )
++{
++  gdcmDebugMacro( "Sorry not a valid extent. Giving up" );
++  return 0;
++ }
++npixels = full.Area();
++  }
++  const PixelFormat pixelInfo = ImageHelper::GetPixelFormatValue(GetFile());
++  const size_t bytesPerPixel = pixelInfo.GetPixelSize();
++  return npixels*bytesPerPixel;
+ }
+ 
+ bool ImageRegionReader::ReadInformation()
+@@ -371,7 +388,17 @@ bool ImageRegionReader::ReadJPEGIntoBuff
+   theCodec.SetPixelFormat( ImageHelper::GetPixelFormatValue(GetFile()) );
+ 
+   std::istream* theStream = GetStreamPtr();
+-  const BoxRegion  = this->Internals->GetRegion()->ComputeBoundingBox();
++  BoxRegion boundingbox;
++  if( Internals->GetRegion() )
++boundingbox = this->Internals->GetRegion()->ComputeBoundingBox();
++  else
++  {
++std::vector dims = ImageHelper::GetDimensionsValue(GetFile());
++boundingbox.SetDomain(
++  0, dims[0] - 1,
++  0, dims[1] - 1,
++  0, dims[2] - 1 );
++  }
+   unsigned int xmin = boundingbox.GetXMin();
+   unsigned int xmax = boundingbox.GetXMax();
+   unsigned int ymin = boundingbox.GetYMin();
+@@ -445,7 +472,13 @@ bool ImageRegionReader::ReadJPEGLSIntoBu
+ bool ImageRegionReader::ReadIntoBuffer(char *buffer, size_t buflen)
+ {
+   size_t thelen = ComputeBufferLength();
+-  if( buflen < thelen )
++  if( thelen == 0 )
++{
++ 

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#835761: insighttoolkit4: FTBFS: itkTriangleHelperPython.cpp:5836:65: error: no matching function for call to

[Gert Wollny]

Control: forwarded -1 https://issues.itk.org/jira/browse/ITK-3466

This specific compilation error is fixed in the svn, however, other
problems with the Python bindings result in other FTBFS, i.e. various
tests are failing. 


Best, 
Gert 

 

Bug#832556: RFS: wvstreams/4.6.1-10 [QA, RC]

[Gert Wollny]

Package: sponsorship-requests
Severity: important

Dear mentors,

  I am looking for a sponsor for the package "wvstreams"

 * Package name: wvstreams
   Version : 4.6.1-10
   Upstream Author : Net Integration Technologies Inc. et al. 
 * URL : https://github.com/apenwarr/wvstreams/
 * License : LGPL-2.1 
   Section : libs

It builds those binary packages:

 libuniconf4.6 - C++ network libraries for rapid application 
                 development
 libwvstreams-dev - Development libraries and header files for 
                    libwvstreams4.6
 libwvstreams4.6-base - C++ network libraries for rapid application 
                        development
 libwvstreams4.6-doc - Documentation for WvStreams
 libwvstreams4.6-extras - C++ network libraries for rapid application 
                          development
 uniconf-tools - Tools to interface with UniConf
 uniconfd   - Server that manages UniConf elements

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/wvstreams


Alternatively, one can download the package with dget using this
command:

 dget -x https://mentors.debian.net/debian/pool/main/w/wvstreams/wvstre
ams_4.6.1-10.dsc

Changes since the last upload:

  * d/p/gcc-6: Update patch to fix more restrictive interpretation of
the standard by g++-6, Closes: #831146

Note with the upload of Version 4.6.1-9 Gianfranco pointed out to me
that it would be nice to update to dh-autoreconf too. However, on one
hand the package uses nested configure scripts, and I don't know how
this should be handled, and on the other hand, the build scripts
already calls autoheader and autoconf and manually copies the system
versions of config.sub and config.guess. 

In order to not introduce new bugs I prefer to just fix the RC bug and
not change the build system to use dh-autoreconf (I actually tried, but
it didn't really work out).

many thanks,
Gert

Bug#832138: librostlab-blast: The package should compile without forcing the older -std=c++03

[Gert Wollny]

Source: librostlab-blast
Version: 1.0.1-7
Severity: wishlist

The package should either be refactored to work around #829604 in g++, or we
have to wait thill that  bug is fixed.

Best,
Gert



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

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

Bug#829604: Bug reported upstream

[Gert Wollny]

forwarded 829604 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71975

Bug#831809: g++-5: exceptions thrown from callback with va_list not caugth on at least armhf and powerpc

[Gert Wollny]

Package: g++-5
Version: 5.4.0-6
Severity: important
Tags: upstream

Dear Maintainer,

in the attached program the exception is not caught on armhf and powerpc.

The compilation command line is

  g++ test_tiff_throw.cc -o test-tiff-throw -ltiff

I've tested the compilers:

powerpc:

  g++ (Debian 5.4.0-6) 5.4.0 20160609
  g++-6 (Debian 6.1.1-9) 6.1.1 20160705

armhf:
  g++ (Ubuntu/Linaro 5.3.1-14ubuntu2.1) 5.3.1 20160413

and optimization levels -O0, -O1, and -O2.

In each case the program aborts with

   terminate called after throwing an instance of 'std::runtime_error'
 what():  should_not_exists.tif: No such file or directory
   Aborted

The code works as expected on amd64 with:

  g++ (Debian 5.4.0-6) 5.4.0 20160609
  g++ (Gentoo 5.4.0 p1.0, pie-0.6.5) 5.4.0

and i386:
  g++ (Debian 5.4.0-6) 5.4.0 20160609

In this case the program prints:

  "error: should_not_exists.tif: No such file or directory"

I was not able to create a simpler test case. Specifically:

Normally throw-catch works fine, i.e. the exception is caught even when using a
callback funtion that makes use of the va_list based constructs, but everything
resides in the same translation unit. The only way I can get this error
reproducible is by using libtiff that internally uses the va_* constructs to
forwards the error function to the user supplied function.

Tested libtiff5-dev:
   4.0.6-2 (powerpc, amd64)
   4.0.6-1 (armhf, i386)

Best regards,
Gert










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

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

Versions of packages g++-5 depends on:
ii  gcc-55.4.0-6
ii  gcc-5-base   5.4.0-6
ii  libc62.23-1
ii  libgmp10 2:6.1.1+dfsg-1
ii  libisl15 0.17.1-1
ii  libmpc3  1.0.3-1
ii  libmpfr4 3.1.4-2
ii  libstdc++-5-dev  5.4.0-6
ii  zlib1g   1:1.2.8.dfsg-2+b1

g++-5 recommends no packages.

Versions of packages g++-5 suggests:
pn  g++-5-multilib
pn  gcc-5-doc 
pn  libstdc++6-5-dbg  

-- no debconf information
#include 
#include 
#include 

typedef TIFF * PTIFF;
void MyErrorHandler(const char *module, const char *fmt,  va_list ap)
{
	char buf[16384];

	vsnprintf(buf,16384, fmt, ap);
	throw std::runtime_error(buf);
}

struct CErrorHandlerReplacer {
	CErrorHandlerReplacer():
		m_old_handler(TIFFSetErrorHandler(MyErrorHandler))
	{
	}
	~CErrorHandlerReplacer() {
		TIFFSetErrorHandler(m_old_handler);
	}
private:
	TIFFErrorHandler m_old_handler;
};


struct CTiffFile {
	CTiffFile(const char *name, const char *flags):
		handle(TIFFOpen(name, flags))
	{
	}

	~CTiffFile()
	{
		if (handle)
			TIFFClose(handle);
	}
	operator PTIFF() {
		return handle;
	}
private:
	TIFF *handle;
};

int main(int argc, char **args)
{
	CErrorHandlerReplacer error_replace;

	try {
		CTiffFile tif("should_not_exists.tif", "r");
		if (tif) {
			std::cerr << "File 'should_not_exists.tif' existed\n"; 
		}
		
	}catch (const std::runtime_error& x) {
		std::cerr << "error: " << x.what() << "\n"; 
	}

	return 0; 
}

Bug#830827: RFS: wvstreams/4.6.1-9 [QA, RC]

[Gert Wollny]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for the package "wvstreams"

 * Package name: wvstreams
   Version : 4.6.1-9
   Upstream Author : Net Integration Technologies Inc. et al. 
 * URL : https://github.com/apenwarr/wvstreams/
 * License : LGPL-2.1 
   Section : libs

It builds those binary packages:

 libuniconf4.6 - C++ network libraries for rapid application
    development
 libwvstreams-dev - Development libraries and header files for 
    libwvstreams4.6Package: sponsorship-requests
  libwvstreams4.6-base - C++ network libraries for rapid application 
    development
 libwvstreams4.6-doc - Documentation for WvStreams
 libwvstreams4.6-extras - C++ network libraries for rapid application
    development
 uniconf-tools - Tools to interface with UniConf
 uniconfd   - Server that manages UniConf elements

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/wvstreams


Alternatively, one can download the package with dget using this
command:

 dget -x https://mentors.debian.net/debian/pool/main/w/wvstreams/wvstre
ams_4.6.1-9.dsc

Changes since the last upload:

  * d/p/gcc-6: Patch to fix compilation with gcc-6, Closes: #811659
  * run 'cme fix dpkg-control', updated standards version to 3.9.8 
  * d/compat, d/control: update compat level to 9
  * d/watch: Point to new github source location 
  * d/control: add new Github home page
  * d/uniconfd.init: source /lib/lsb/init-functions if available
  * d/rules: Add and install overrides for missing manpage of dev test 
program and the Doxygen created embedded javascript library 
  * d/rules: remove irrelevant *.md5 files from -doc package

Regards,
Gert 

Bug#830595: closed by Gianfranco Costamagna <locutusofb...@debian.org> (Re: Bug#830595: RFS: fracplanet/0.4.0-4 [QA, RC])

[Gert Wollny]

Hello Gianfranco, 

thanks for sponsoring. 

> you also bumped std-version, I added the entry in changelog, 

Well, since "cme fix dpkg-control" always bumps to the latest version,
I didn't add this explicitly ... 

Best, 
Gert 

Bug#830595: RFS: fracplanet/0.4.0-4 [QA, RC]

[Gert Wollny]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for the package "fracplanet"

 * Package name: fracplanet
   Version : 0.4.0-4
   Upstream Author : Tim Day 
 * URL : http://www.bottlenose.demon.co.uk/share/fracplanet
 * License : GPL-3
   Section : graphics

It builds those binary packages:

fracplanet - Fractal planet generator

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/fracplanet

Alternatively, one can download the package with dget using this
command:

  dget -x https://mentors.debian.net/debian/pool/main/f/fracplanet/frac
planet_0.4.0-4.dsc

Changes since the last upload:

  * cme fix dpkg-control 
  * d/p/gcc-6: Add patch to fix compilation with gcc-6, Closes: #811642

Many thanks,
Gert