Bug#1065331: libhdf5-103-1t64: depends on libcurl4 instead of libcurl4t64

[Gilles Filippini]

Hi Vincent,

Vincent Lefevre a écrit le 03/03/2024 à 01:08 :

Package: libhdf5-103-1t64
Version: 1.10.10+repack-3.1
Severity: serious

libhdf5-103-1t64 depends on libcurl4 instead of libcurl4t64.
This makes the upgrade of curl impossible.


How am I expected to solve this issue? As I understand it a binNMU 
should suffice. Am I right?


Thanks,
_g.



-- System Information:
Debian Release: trixie/sid
   APT prefers unstable-debug
   APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.15-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libhdf5-103-1t64 depends on:
ii  libc6   2.37-15.1
ii  libcurl48.6.0-3
ii  libssl3t64  3.1.5-1.1
ii  libsz2  1.1.2-1
ii  zlib1g  1:1.3.dfsg-3.1

libhdf5-103-1t64 recommends no packages.

libhdf5-103-1t64 suggests no packages.

-- no debconf information

Bug#1064095: hdf5: NMU diff for 64-bit time_t transition

[Gilles Filippini]

Hi Steve,

Steve Langasek a écrit le 01/03/2024 à 06:06 :

Dear maintainer,

Please find attached a final version of this patch for the time_t
transition.  This patch is being uploaded to unstable.

Note that this adds a versioned build-dependency on dpkg-dev, to guard
against accidental backports with a wrong ABI.


I fail to see this change in your patch. Is that wanted?

I've started working on the last HDF5 upstream release (1.14.3 currently 
in experimental). As I read your patch I have nothing to do beside 
adding the versionned build-dependency on dpkg-dev. Am I right?



Thanks!


Thank you!

_g.

Bug#1050952: r-bioc-rhdf5lib: autopkgtest regression: Expected '1.10.8', got '1.10.10'

[Gilles Filippini]

Source: r-bioc-rhdf5lib
Version: 1.6.3+dfsg-1
Severity: serious
Justification: Test regression

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

See 
https://ci.debian.net/data/autopkgtest/unstable/amd64/r/r-bioc-rhdf5lib/37206202/log.gz.

> 69s - FAILED[data]: test_library_version.R<3--3>
> 69s  call| expect_identical(libver, "1.10.8")
> 69s  diff| Expected '1.10.8', got '1.10.10'

Please fix the testcases so that they won't fail each time the HDF5
release number is bumped.

Thanks in advance,
_g.

- -- System Information:
Debian Release: 11.7
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-25-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAmTw1b4ACgkQ7+hsbH/+
z4MVFAf/cmL8/oW3owSvrnYpqf68EwqR4stYB/NS+KOqtM/B5Ed2FYoUkxmgOhWG
9q9u1lkW0T0mMVlVMLKJlhKdfS/brQgk/Z+LYmc5sqTpvj5Re2C2DIW/XhyAsNxn
Nz7HiRURg4MOKd2F9Nq5iRoI8mVwgtiRiTI12Fne5QlAyXMBOGD4IBrgINOttiKT
LPkZgaO+jXN7nV9HOYkeFm2Jf8bRVEpS5t1ityuN+HVohl0YJ8ieqwzQFsKnAave
o1ag7xZ21iX6hF88ApfTlzBc6SdkRPBf0/AjNuAWnBz0UQHbYVSsKYtL1TshnPUN
virmPFskzmAa345AD6/BA/gyzMME6g==
=UnqI
-END PGP SIGNATURE-

Bug#1025492: openjdk-17: Upstream commit f71b21b causes segfault in hdf5 java test suite on arches i386 and mips64el

[Gilles Filippini]

On Mon, 05 Dec 2022 20:19:37 +0100 Gilles Filippini  wrote:

Package: openjdk-17
Version: 17~14-1
Severity: serious
Tags: upstream
Justification: makes unrelated software on the system break

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

A few weeks ago default-jdk was switched from openjdk-11 to openjdk-17.
Afterward hdf5 has been suffering FTBFS on arches i386 [1] and mips64el [2]
caused by a segfault in one of its java test case:

junit.sh: line 926: 3107321 Aborted ( $RUNSERIAL $JAVAEXE 
$JAVAEXEFLAGS -Xmx1024M -Dorg.slf4j.simpleLogger.defaultLog=trace 
-Djava.library.path=$BLDLIBDIR -cp $CLASSPATH -ea org.junit.runner.JUnitCore 
test.TestH5Arw > JUnit-TestH5Arw.ext )
**FAILED**JUnit-TestH5Arw
Expected result differs from actual result
*** JUnit-TestH5Arw.txt 2022-11-26 00:28:33.024585625 +
--- JUnit-TestH5Arw.out 2022-11-26 00:28:42.316468486 +
***
*** 7,13 
  .testH5Aread_32bit_floats
  .testH5Aread_16bit_ints
  
! Time:  
! 
! OK (7 tests)
! 
--- 7,27 

  .testH5Aread_32bit_floats
  .testH5Aread_16bit_ints
  
! #

! # A fatal error has been detected by the Java Runtime Environment:
! #
! #  SIGSEGV (0xb) at pc=0xf74070c5, pid=3107321, tid=3107322
! #
! # JRE version: OpenJDK Runtime Environment (version (number)) (build 
17.0.5+8-Debian-2)
! # Java VM: OpenJDK Server VM (version (number))
! # Problematic frame:
! # V  [libjvm.so+0x65e0c5]
! #
! # No core dump will be written. Core dumps have been disabled. To enable core 
dumping, try "ulimit -c unlimited" before starting Java again
! #
! # An error report file with more information is saved as:
! # /<>/hdf5-version (number)
! #
! # If you would like to submit a bug report, please visit:
! #   https://bugs.debian.org/openjdk-17
! #

[1] 
https://buildd.debian.org/status/fetch.php?pkg=hdf5=i386=1.10.8%2Brepack-3=1669422533=0
[2] 
https://buildd.debian.org/status/fetch.php?pkg=hdf5=mips64el=1.10.8%2Brepack-3=1669424344=0


Please find attached the related java error report file.

Best,
_g.


hs_err_pid59953.log.gz
Description: application/gzip


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025492: openjdk-17: Upstream commit f71b21b causes segfault in hdf5 java test suite on arches i386 and mips64el

[Gilles Filippini]

Package: openjdk-17
Version: 17~14-1
Severity: serious
Tags: upstream
Justification: makes unrelated software on the system break

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

A few weeks ago default-jdk was switched from openjdk-11 to openjdk-17.
Afterward hdf5 has been suffering FTBFS on arches i386 [1] and mips64el [2]
caused by a segfault in one of its java test case:

junit.sh: line 926: 3107321 Aborted ( $RUNSERIAL $JAVAEXE 
$JAVAEXEFLAGS -Xmx1024M -Dorg.slf4j.simpleLogger.defaultLog=trace 
-Djava.library.path=$BLDLIBDIR -cp $CLASSPATH -ea org.junit.runner.JUnitCore 
test.TestH5Arw > JUnit-TestH5Arw.ext )
**FAILED**JUnit-TestH5Arw
Expected result differs from actual result
*** JUnit-TestH5Arw.txt 2022-11-26 00:28:33.024585625 +
--- JUnit-TestH5Arw.out 2022-11-26 00:28:42.316468486 +
***
*** 7,13 
  .testH5Aread_32bit_floats
  .testH5Aread_16bit_ints
  
! Time:  
! 
! OK (7 tests)
! 
--- 7,27 
  .testH5Aread_32bit_floats
  .testH5Aread_16bit_ints
  
! #
! # A fatal error has been detected by the Java Runtime Environment:
! #
! #  SIGSEGV (0xb) at pc=0xf74070c5, pid=3107321, tid=3107322
! #
! # JRE version: OpenJDK Runtime Environment (version (number)) (build 
17.0.5+8-Debian-2)
! # Java VM: OpenJDK Server VM (version (number))
! # Problematic frame:
! # V  [libjvm.so+0x65e0c5]
! #
! # No core dump will be written. Core dumps have been disabled. To enable 
core dumping, try "ulimit -c unlimited" before starting Java again
! #
! # An error report file with more information is saved as:
! # /<>/hdf5-version (number)
! #
! # If you would like to submit a bug report, please visit:
! #   https://bugs.debian.org/openjdk-17
! #

[1] 
https://buildd.debian.org/status/fetch.php?pkg=hdf5=i386=1.10.8%2Brepack-3=1669422533=0
[2] 
https://buildd.debian.org/status/fetch.php?pkg=hdf5=mips64el=1.10.8%2Brepack-3=1669424344=0

Thanks to snapshot.debian.or I was able to spot that openjdk-17 17~14-1
was the first release with this issue in Debian.

I then ran a bisect against the openjdk upstream repo and found out that
upstream commit f71b21b [3]  was the culprit. Reverting this commit on
current openjdk-17 source (17.0.5+8-2) makes the hdf5 java test suite
successful.

[3] https://github.com/openjdk/jdk/commit/f71b21b

I don't know what to do from here. Any chance to release openjdk-17 with a patch
reverting the faulty commit?

Setting this bug as serious since it causes an unrelated package to FTBFS.

Thanks,
_g.


- -- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-19-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAmOORD8ACgkQ7+hsbH/+
z4MFRQf+LG9hnV03M1QsxDPg7mHeDQBIzQEaBl6jTOjIgnQ0n7qwlxk+hKdhi4pw
5oKrDWN3XxzxpwDcP+PH8/7JBbtp1b6m+xFFTe12fogj3/So7/hsJRoImZFajbO3
VKEeCyV8K1d11T13nJdXXvcFtQ1ergeApI5ClY6JIsT499Lj0r6tTZNvblGXfDMp
qq2MHnNFM4AoRcXY+PGhnYJY4InmvL6Cg/1gUnWul45n63WrFE+R19MnLbnR+rLW
K1XAUDKG0jKxhkbOeZ6B80sYldza+vhuAsilga9Y6I1NludMLzR/91+u9GApBYRd
mUiUpIeWB3X/iwgPCkpS4v9DLvR+qg==
=KzlR
-END PGP SIGNATURE-

Bug#1025232: hdf5: Build dependencies on openjdk-11 that will not be in bookworm

[Gilles Filippini]

Hi,

Sebastian Ramacher a écrit le 01/12/2022 à 10:25 :

Source: hdf5
Version: 1.10.8+repack-4
Severity: serious
Tags: sid bookworm
X-Debbugs-Cc: sramac...@debian.org

openjdk-11 will not be be part of bookworm (see #1023237). Please adapt
the package to use the default JDK version (openjdk-17) in its build
dependencies.
Yes, I was told so. That's unfortunate. A change between openjdk 17~11 
and 17~14 broke the hdf5 java test suite on i386 and mips64el arches.


I'm running a bisect against the jdk repo to find out more about that. 
But this will take some time.


Best,
_g.

Bug#1017997: hdf5 ftbfs on s390x

[Gilles Filippini]

Hi Steve,

Steve Langasek a écrit le 23/08/2022 à 22:40 :

Package: hdf5
Version: 1.10.8+repack-1
Severity: serious
Tags: patch
Justification: ftbfs
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch

Hi Gilles,

hdf5 has been failing to build from source on s390x.  In Ubuntu we have a
patch to fix this build failure.  Please consider including it in Debian as
well.


Thanks for this patch. However I can't reproduce the FTBFS on the s390x 
porterbox zelenka.debian.org.


Would you mind sharing build logs?

Best,
_g.

Bug#998383: nheko: nheko/{armel,armhf} has unsatisfiable dependency

[Gilles Filippini]

On Wed, 3 Nov 2021 14:25:41 +0200 Adrian Bunk  wrote:

Control: reassign -1 src:gst-plugins-good1.0 1.18.5-1
Control: retitle -1 gstreamer1.0-qt5 should again be built on armel/armhf
Control: affects -1 nheko

On Wed, Nov 03, 2021 at 12:03:20PM +0100, Sebastian Ramacher wrote:
> Source: nheko
> Version: 0.8.2-2
> Severity: serious
> X-Debbugs-Cc: sramac...@debian.org
> 
> nheko fails to migrate to testing since it depends on gstreamer1.0-qt5.

> This package is not available on armel and armhf.

With #894076 fixed, gstreamer1.0-qt5 builds again on armel/armhf.

I'll submit a MR for that.


Hi Adrian,
Any progress on this topic?
Thanks,
_g.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#995594: libhdf5[-openmpi]-dev: missing Depends: libcurl-dev

[Gilles Filippini]

Drew Parsons a écrit le 04/10/2021 à 21:14 :

On 2021-10-03 12:15, Gilles Filippini wrote:

Drew Parsons a écrit le 02/10/2021 à 22:17 :

...
Since h5pcc and h5cc invoke -lcurl, libhdf5-openmpi-dev, libhdf5-dev 
(and

probably libhdf5-mpich-dev also) should declare Depends: libcurl-dev

...
I guess this is a consequence of enabling access to HDF5 on S3. See 
#972537.



Judging by fclib and 
https://ci.debian.net/data/autopkgtest/testing/amd64/f/fclib/15757105/log.gz 


I guess libhdf5*-dev needs libssl-dev as well


Done.
Thanks,

_g.

Bug#995594: libhdf5[-openmpi]-dev: missing Depends: libcurl-dev

[Gilles Filippini]

Hi,

Drew Parsons a écrit le 02/10/2021 à 22:17 :

Package: libhdf5-openmpi-dev
Version: 1.10.7+repack-2
Severity: serious
Justification: FTBFS
Control: affects -1 src:fenics-dolfinx

The hdf5 compiler wrappers declare -lcurl as a linked library
e.g.
$ h5cc -showconfig | grep curl
 Extra libraries: -lcrypto -lcurl -lpthread -lsz -lz -ldl -lm
$ h5pcc -showconfig | grep curl
 Extra libraries: -lcrypto -lcurl -lsz -lz -ldl -lm


But libcurl-dev is not declared as a Dependency for libhdf5-openmpi-dev.
This means that compiling with h5pcc (or h5cc) fails unless [a]
libcurl-dev is installed.

This affects client packages using cmake that check HDF5
configuration using find_package(hdf5),
e.g. a trivial sample CMakeLists.txt

--
project(TEST_hdf5)

set(HDF5_PREFER_PARALLEL TRUE)
find_package(HDF5 REQUIRED COMPONENTS C)
--

gives the result,

   -- HDF5 C compiler wrapper is unable to compile a minimal HDF5 program.
   CMake Error at 
/usr/share/cmake-3.21/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
 Could NOT find HDF5 (missing: HDF5_LIBRARIES HDF5_INCLUDE_DIRS C) (found
 version "")


A current example is the broken build of fenics-dolfinx on i386,
https://buildd.debian.org/status/fetch.php?pkg=fenics-dolfinx=i386=1%3A0.3.0-3=1633198410=0


cmake is desparately opaque, but with enough sweat and tears
(ultimately, by compiling the cmake hdf5 test file manually with
h5pcc) one can eventually discover that the problem is the -lcurl flag
in h5pcc,

   CMakeFiles/hdf5$ h5pcc cmake_hdf5_test.c
   /usr/bin/ld: cannot find -lcurl



I'm filing this bug against libhdf5-openmpi-dev, providing h5pcc,
since I want to use hdf5-mpi, but the problem also affects libhdf5-dev
(providing h5cc).

Since h5pcc and h5cc invoke -lcurl, libhdf5-openmpi-dev, libhdf5-dev (and
probably libhdf5-mpich-dev also) should declare Depends: libcurl-dev

Finally, since libcurl-dev is virtual, the actual declaration should be
(following hdf5's Build-Depends)

   Depends: libcurl4-openssl-dev

or possibly Depends: libcurl4-openssl-dev | libcurl-dev
(the libcurl variants seem to be interchangeable)


Why h5cc needs -lcurl is a separate question! What is it trying to
download?


I guess this is a consequence of enabling access to HDF5 on S3. See #972537.

Best,

_g.

Bug#994109: scilab FTBFS with hdf5 1.10.7

[Gilles Filippini]

Julien Puydt a écrit le 13/09/2021 à 08:51 :

Excellent! Please commit to salsa but don't upload yet


Done.

Best,

_g.

Bug#994109: scilab FTBFS with hdf5 1.10.7

[Gilles Filippini]

Adrian Bunk a écrit le 11/09/2021 à 23:35 :

Source: scilab
Version: 6.1.0+dfsg1-7
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=scilab=sid

...
In file included from /usr/include/hdf5/serial/H5public.h:32,
  from /usr/include/hdf5/serial/hdf5.h:22,
  from src/c/h5_readDataFromFile.c:26:
/usr/include/hdf5/serial/H5version.h:39:4: error: #error "Can't choose old API 
versions when deprecated APIs are disabled"
39 |   #error "Can't choose old API versions when deprecated APIs are 
disabled"
   |^
make[5]: *** [Makefile:1380: src/c/libscihdf5_algo_la-h5_readDataFromFile.lo] 
Error 1



Patch proposal attached.

Best,

_g.
diff -Nru scilab-6.1.1+dfsg2/debian/changelog 
scilab-6.1.1+dfsg2/debian/changelog
--- scilab-6.1.1+dfsg2/debian/changelog 2021-09-10 07:02:44.0 +0200
+++ scilab-6.1.1+dfsg2/debian/changelog 2021-09-12 14:50:46.0 +0200
@@ -1,3 +1,11 @@
+scilab (6.1.1+dfsg2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * New patch hdf5-1.10.7.patch to disable H5_NO_DEPRECATED_SYMBOLS which
+causes FTBFS against HDF5 1.10.7 (Closes: #994109)
+
+ -- Gilles Filippini   Sun, 12 Sep 2021 14:50:46 +0200
+
 scilab (6.1.1+dfsg2-1) unstable; urgency=medium
 
   * Drop even more files from upstream's archive (now dfsg2),
diff -Nru scilab-6.1.1+dfsg2/debian/patches/hdf5-1.10.7.patch 
scilab-6.1.1+dfsg2/debian/patches/hdf5-1.10.7.patch
--- scilab-6.1.1+dfsg2/debian/patches/hdf5-1.10.7.patch 1970-01-01 
01:00:00.0 +0100
+++ scilab-6.1.1+dfsg2/debian/patches/hdf5-1.10.7.patch 2021-09-12 
14:50:46.0 +0200
@@ -0,0 +1,52 @@
+Index: scilab/scilab/modules/hdf5/Makefile.am
+===
+--- scilab.orig/scilab/modules/hdf5/Makefile.am
 scilab/scilab/modules/hdf5/Makefile.am
+@@ -103,8 +103,7 @@ FORCE_HDF_API = \
+ -DH5Gopen_vers=2 \
+ -DH5Tget_array_dims_vers=2 \
+ -DH5Acreate_vers=2 \
+--DH5Rdereference_vers=2 \
+--DNO_DEPRECATED_SYMBOLS
++-DH5Rdereference_vers=2
+ 
+ 
+ libscihdf5_la_CPPFLAGS = \
+Index: scilab/scilab/modules/hdf5/src/c/h5_readDataFromFile.c
+===
+--- scilab.orig/scilab/modules/hdf5/src/c/h5_readDataFromFile.c
 scilab/scilab/modules/hdf5/src/c/h5_readDataFromFile.c
+@@ -13,8 +13,6 @@
+ *
+ */
+ 
+-#define H5_NO_DEPRECATED_SYMBOLS
+-
+ #ifndef _MSC_VER
+ #include 
+ #else
+Index: scilab/scilab/modules/hdf5/includes/HDF5Objects.h
+===
+--- scilab.orig/scilab/modules/hdf5/includes/HDF5Objects.h
 scilab/scilab/modules/hdf5/includes/HDF5Objects.h
+@@ -16,7 +16,6 @@
+ #ifndef __HDF5OBJECTS_H__
+ #define __HDF5OBJECTS_H__
+ 
+-#define H5_NO_DEPRECATED_SYMBOLS
+ #undef H5_USE_16_API
+ 
+ #define H5Eset_auto_vers 2
+Index: scilab/scilab/modules/hdf5/src/c/h5_readDataFromFile_v1.c
+===
+--- scilab.orig/scilab/modules/hdf5/src/c/h5_readDataFromFile_v1.c
 scilab/scilab/modules/hdf5/src/c/h5_readDataFromFile_v1.c
+@@ -13,8 +13,6 @@
+ *
+ */
+ 
+-#define H5_NO_DEPRECATED_SYMBOLS
+-
+ #ifndef _MSC_VER
+ #include 
+ #else
diff -Nru scilab-6.1.1+dfsg2/debian/patches/series 
scilab-6.1.1+dfsg2/debian/patches/series
--- scilab-6.1.1+dfsg2/debian/patches/series2021-09-10 07:02:44.0 
+0200
+++ scilab-6.1.1+dfsg2/debian/patches/series2021-09-12 14:50:46.0 
+0200
@@ -20,3 +20,4 @@
 no-ftbfs-icu.patch
 find_external_libintl_jar.patch
 ocaml_411.patch
+hdf5-1.10.7.patch


OpenPGP_signature
Description: OpenPGP digital signature

Bug#992068: libhdf5-mpich-dev: please bump libmpich-dev dependency to (>= 3.3-3~)

[Gilles Filippini]

Andreas Beckmann a écrit le 10/08/2021 à 17:54 :

Package: libhdf5-mpich-dev
Version: 1.10.6+repack-4
Severity: serious
Tags: patch
User: debian...@lists.debian.org
Usertags: piuparts

During an piuparts upgrade test of libhdf5-mpich-dev on the upgrade path
   squeeze -> wheezy -> jessie -> stretch -> buster -> bullseye
I observed this failure:

   Setting up libhdf5-mpich-dev (1.10.6+repack-4) ...
   update-alternatives: priority must be an integer

   Use 'update-alternatives --help' for program usage information.
   dpkg: error processing package libhdf5-mpich-dev (--configure):
installed libhdf5-mpich-dev package post-installation script subprocess 
returned error exit status 2

At the time of the failure the libmpich1.0-dev package which
   Provides: libmpich-dev
was still installed, but that uses an ancient mpi alternative scheme
the postinst cannot parse.
Making the libmpich-dev versioned (buster shipped with 3.3-3 which uses
the new alternatives scheme) ensures that libmpich-dev gets upgraded
(or rather installed, kicking out the ancient libmpich1.0-dev from
squeeze).

This fix needs to get backported to bullseye-pu.

This needs an update of mpich as well, since there is an unhandled
file conflict between libmpich1.0-dev and mpich, #992065.

I've verified that using the two updated packages fixes the problematic
upgrade path.

Andreas

PS: it took me quite some time to understand what was going on here
so the fix wasn't ready before the bullseye deadline.


Thank you Andreas. I'll prepare an upload asap.

Best,

_g.

Bug#988722: postgresql-common: Upgrading cluster with postgis does not migrate tables using postgis

[Gilles Filippini]

Sebastian Ramacher a écrit le 16/06/2021 à 17:22 :

Thanks for uploading the fix!

Unfortunately, the changes to the S3 virtual file driver caused
regressions in hdf5's reverse dependencies (some of them are caused by
missing dependencies for -lcrypto and -lcurl). See
https://qa.debian.org/excuses.php?package=hdf5. Could you please prepare
another upload reverting this change?


Done. I'll re-introduce this change after the release.

Best,

_g.

Bug#988722: postgresql-common: Upgrading cluster with postgis does not migrate tables using postgis

[Gilles Filippini]

Hi Andreas,

Andreas Beckmann a écrit le 14/06/2021 à 10:18 :

On 08/06/2021 13.05, Sebastian Ramacher wrote:

Here it is. Now testing upgrades ...
There were some new symbols ... but they appeared independently of my
changes (I built in bullseye, not sid, in case it does matter).


Tests have not shown any problems. And in combination with patched gdal 
and friends we have achieved co-installability ;-)


This is good news. Thanks for this work.


Thanks Andreas! Once that tests are done and the packages was uploaded,
please let me know so that I can add the appropriate hints on the
release team side.

FWIW, the symbol is a template instantiation of a function from the
standard library and should be marked as optional.


Attached is a new version of the patch. Some wording was tweaked and 
'optional' added.


The new packages are still available as cruft in sid, so we should be 
able to avoid NEW.


Gilles, do you want to do the upload or shall I NMU it?


I'll try to upload this evening.

I'll now reupload libaec with the recently added Breaks dropped, since 
they are no longer needed ;-)


Thanks again!

_g.

Bug#988722: postgresql-common: Upgrading cluster with postgis does not migrate tables using postgis

[Gilles Filippini]

Andreas Beckmann a écrit le 08/06/2021 à 11:57 :

On 08/06/2021 08.27, Andreas Beckmann wrote:
Or, wait, easier: we can reintroduce metapackages libhdf5*-103 
depending on libhdf5*-103-1 and all the other packages containing 
libraries that were in the merged package in buster.



I actually like that solution and will try to come up with a patch ;-)


That could to the trick, indeed.


Here it is. Now testing upgrades ...


Yes please.

There were some new symbols ... but they appeared independently of my 
changes (I built in bullseye, not sid, in case it does matter).


OK.

This patch shouldn't close the bug as it only allows for a tedious 
workaround (installing back postgresql-11-postgis-2.5 from buster).


But the actual bug will still need to be addressed: postgis requires 
previous runtime to be able to migrate data.


Best,

_g.

Bug#988722: postgresql-common: Upgrading cluster with postgis does not migrate tables using postgis

[Gilles Filippini]

Control: reassign -1 postgresql-13-postgis-3

Andreas Beckmann a écrit le 08/06/2021 à 08:27 :
An alternative solution would be to rename libhdf5*-103-1 back to 
libhdf5*-103 and add dependencies on the split out libraries (s.t. e.g. 
dependencies of a buster package depending on libhdf5-103 for a -hl 
library are still satisfied). These Depends can be removed once the 103 
SOVERSION gets bumped.


I don't think so. The problem is in postgis which *requires* a 2.5 
runtime to migrate databases from buster to bullseye.


I acknowledge and regret that this 103 to 103-1 hdf5 transition (*) is 
unfortunate and doesn't help at all with a workaround, but this is not 
where the problem lies in the first place. This painful postgis 
migration experience seems well [0] known [1] and documented [2] at 
several places.


[0] 
https://stackoverflow.com/questions/63413582/can-not-upgrade-postgis-2-5-to-3-0-1-for-postgresql-11-on-ubuntu

[1] https://github.com/postgis/docker-postgis/issues/207
[2] 
https://oslandia.com/en/2020/11/05/mettre-a-jour-vos-vieux-clusters-postgis/


The only solutions I can see are either to document postgis databases 
manual migration (such as in [2]) or to reintroduce a minimal 
postgis-2.5 runtime built against postgresql 13 to fix the scripted 
migration procedure.


(*) As a side note, this hdf5 transition was triggered by an hdf5 
Fortran API SONAME bump while the SONAME for the C library wasn't 
changed. All the hdf5 runtime libraries now have their own binary 
package to prevent such a Breaks / Replaces transition to happen again.


Best,

_g.

Bug#988722: postgresql-common: Upgrading cluster with postgis does not migrate tables using postgis

[Gilles Filippini]

Hi,

On Wed, 2 Jun 2021 22:22:04 +0200 Sebastian Ramacher 
 wrote:

Hi Gilles, hi Andreas,

On 2021-06-01 14:15:52 +0200, Andreas Beckmann wrote:
> On Tue, 18 May 2021 20:36:23 +0200 Dennis Filder  wrote:
> > One more observation: Bullseye's gdal-data 3.2.1+dfsg-1 defines a
> > Breaks: libgdal20 (< 2.5.0~), but the libgdal20 in Buster is 2.4.0,
> > and postgresql-11-postgis-2.5 depends on that.  libgdal28 depends on
> > gdal-data (>=3.2.1+dfsg-1).  To me it looks like there's no way to
> > keep postgresql-11-postgis-2.5 around if anything that depends on
> > libgdal28 (postgis, libopencv-imgcodecs4.5, ...) gets installed.
> 
> What would be needed to reintroduce postgresql-11-postgis-2.5 (i.e.

> src:postgis-2.5) (built against bullseye libraries) into bullseye? Probably
> libraries and -dev packages from postgresql-11, too.
> Here I assume that src:postgis-2.5 could be built against gdal 3.2.x and
> that can be used to perform the upgrade to postgis 3.x - is that true?

So here is a different view. At least the hdf5 part of this upgrade
issue could have been avoided if we transitationed to hdf5 1.12 (which
bumps all the SOVERSIONs to 200) for bullseye. Alas, we didn't and it's
too late for that.

So, what if we use the free versions between 103 and 200 to transition
to a Debian-specific version? Attached is a patch that does that. It's
not an optimal solution as we would have a release with a
Debian-specific SOVERSIONs. For good reason, we usually try to avoid
those. So, it would be good for someone more familiar with the users of
hdf5 to check if that would be an issue in this specific case.


I'm not in favor of that. I can't understand why we'd need to bump the 
HDF5 C library's SONAME for no reason but postgis wants an old runtime 
to properly run a migration. That's awkward.


If postgresql-11-postgis-2.5 needs to be re(instroduced, then it has to 
be built against current gdal and hdf5. Is that not feasible?


Best,

_g.

Bug#955694: scilab: FTBFS: Scilab cannot create Scilab Java Main-Class (we have not been able to find the main Scilab class. Check if the Scilab and thirdparty packages are available).

[Gilles Filippini]

Control: found -1 5.5.2-4
Control: found -1 6.0.1-10

Julien Puydt a écrit le 23/04/2020 à 09:37 :
> Hi,
> 
> Le jeudi 23 avril 2020 à 00:20 +0200, Gilles Filippini a écrit :
>> Gilles Filippini a écrit le 22/04/2020 à 09:59 :
>>> I think I've eventually found a fix for Scilab. Please hold.
>>
>> Here it is, attached.
> 
> I'm checking it right now.

Thanks for the upload. Could you please address this bug for stable-sec
and old-stable as well?

Thanks in advance,

_g.

Bug#949780: maptool: Maptool segfaults

[Gilles Filippini]

Gilles Filippini a écrit le 24/04/2020 à 15:08 :
> On Sun, 26 Jan 2020 12:39:01 + ael  wrote:
>> On Sat, Jan 25, 2020 at 06:26:35PM -0800, Joseph Herlant wrote:
>>> Hi,
>>>
>>>
>>> You mention in the bug there that you were able to run your pbf by
>>> compiling maptool from the git repo. What compilation flags did you
>>> use?
>>
>> I just realised that I answered the wrong question :-)
>>
>> I used the simplest defaults I think.
>>
>> In my history I just have
>> cmake ../navit/
>> make maptool
> 
> I can confirm I have the same error as reported by Joseph when using the
> Debian maptool package, but it works as described by ael when built as
> specified above. I used the very same version of navit in both cases.

When building maptool with the default configuration, the selected build
profile is 'Release' where the compiler flag '-DNDEBUG' is set.

The Debian build uses the 'Debian' profile which doesn't define this flag.

From the assert(3) manpage:
> If the macro NDEBUG is defined at the moment  was last included, 
> the macro assert() generates no code, and hence does nothing at all.

So, the error is there actually, but silently ignored when maptool is
built with the default configuration.

I propose to add '-DDEBUG' to the 'Debian' cmake profile to workaround
this issue for now.

_g.



signature.asc
Description: OpenPGP digital signature

Bug#949780: maptool: Maptool segfaults

[Gilles Filippini]

On Sun, 26 Jan 2020 12:39:01 + ael  wrote:
> On Sat, Jan 25, 2020 at 06:26:35PM -0800, Joseph Herlant wrote:
> > Hi,
> > 
> > 
> > You mention in the bug there that you were able to run your pbf by
> > compiling maptool from the git repo. What compilation flags did you
> > use?
> 
> I just realised that I answered the wrong question :-)
> 
> I used the simplest defaults I think.
> 
> In my history I just have
> cmake ../navit/
> make maptool

I can confirm I have the same error as reported by Joseph when using the
Debian maptool package, but it works as described by ael when built as
specified above. I used the very same version of navit in both cases.

_g.



signature.asc
Description: OpenPGP digital signature

Bug#955694: scilab: FTBFS: Scilab cannot create Scilab Java Main-Class (we have not been able to find the main Scilab class. Check if the Scilab and thirdparty packages are available).

[Gilles Filippini]

Control: tag -1 + patch

Gilles Filippini a écrit le 22/04/2020 à 19:35 :
> Gilles Filippini a écrit le 22/04/2020 à 09:59 :
>> Hi,
>>
>> Matthias Klose a écrit le 20/04/2020 à 12:49 :
>>> On 4/20/20 11:52 AM, Gilles Filippini wrote:
>>>> I'd like to do a bisect between openjdk-11 11.0.6+10-2 and 11.0.7+9-1 to
>>>> better understand the problem but I can't find the corresponding branch
>>>> on the openjdk Mercurial repo.
>>>
>>> http://hg.openjdk.java.net/jdk-updates/jdk11u/
>>>
>>
>> This commit is the culprit:
>> http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/21710e014d7f
>>
>> It makes sense since it is related to System.loadLibrary().
>>
>> Because Scilab loads Java from C++ code I guess moving usr_paths ans
>> sys_paths initialization out of System.loadLibrary might have some
>> consequences.
>>
>> Applying the attached patch to openjdk-11 solves the problem. Not sure
>> this is the right thing to do, but it keeps the deadlock fix brought by
>> the jdk changeset and allows for sys_paths and usr_paths initialization
>> in System.loadLibrary() when needed.
>>
>> @doko, please consider adding this patch to the openjdk-11 source
>> package until a proper fix is found for Scilab.
> 
> I think I've eventually found a fix for Scilab. Please hold.

Here it is, attached.

_g.
diff -Nru scilab-6.1.0+dfsg1/debian/changelog 
scilab-6.1.0+dfsg1/debian/changelog
--- scilab-6.1.0+dfsg1/debian/changelog 2020-03-01 17:03:05.0 +0100
+++ scilab-6.1.0+dfsg1/debian/changelog 2020-04-22 21:55:44.0 +0200
@@ -1,3 +1,11 @@
+scilab (6.1.0+dfsg1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * New patch addLibraryPath.patch to fix NullPointerExeption with
+openjdk >= 11.0.7+9 (closes: #955694, #956908)
+
+ -- Gilles Filippini   Wed, 22 Apr 2020 21:55:44 +0200
+
 scilab (6.1.0+dfsg1-1) unstable; urgency=medium
 
   * Package new upstream release 6.1.0.
diff -Nru scilab-6.1.0+dfsg1/debian/patches/addLibraryPath.patch 
scilab-6.1.0+dfsg1/debian/patches/addLibraryPath.patch
--- scilab-6.1.0+dfsg1/debian/patches/addLibraryPath.patch  1970-01-01 
01:00:00.0 +0100
+++ scilab-6.1.0+dfsg1/debian/patches/addLibraryPath.patch  2020-04-22 
21:55:44.0 +0200
@@ -0,0 +1,40 @@
+Description: Starting with openjdk 11.0.7+9 it is not possible anymore
+ to force java.library.path reload by setting sys_paths to null.
+ Related jdk changeset:
+ http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/21710e014d7f
+Author: Gilles Filippini 
+Index: 
scilab-6.1.0+dfsg1/scilab/modules/jvm/src/java/org/scilab/modules/jvm/LibraryPath.java
+===
+--- 
scilab-6.1.0+dfsg1.orig/scilab/modules/jvm/src/java/org/scilab/modules/jvm/LibraryPath.java
 
scilab-6.1.0+dfsg1/scilab/modules/jvm/src/java/org/scilab/modules/jvm/LibraryPath.java
+@@ -19,7 +19,8 @@ package org.scilab.modules.jvm;
+ /*--*/
+ import java.io.IOException;
+ import java.io.File;
+-import java.lang.reflect.Field;
++import java.lang.reflect.Method;
++import java.lang.reflect.InvocationTargetException;
+ /*--*/
+ /*http://forum.java.sun.com/thread.jspa?threadID=135560=15=0 */
+ /*--*/
+@@ -65,13 +66,13 @@ public class LibraryPath {
+ String newLibPath = System.getProperty(JAVALIBRARYPATH) + 
File.pathSeparator + p;
+ System.setProperty(JAVALIBRARYPATH, newLibPath);
+ try {
+-Field fieldSysPath = 
ClassLoader.class.getDeclaredField("sys_paths");
+-fieldSysPath.setAccessible(true);
+-if (fieldSysPath != null) {
+-fieldSysPath.set(System.class.getClassLoader(), null);
+-}
+-} catch (NoSuchFieldException e) {
+-throw new IOException("Error NoSuchFieldException, could not 
add path to " + JAVALIBRARYPATH);
++final Method initLibraryPaths = 
ClassLoader.class.getDeclaredMethod("initLibraryPaths"); 
++initLibraryPaths.setAccessible(true); 
++initLibraryPaths.invoke(null); 
++} catch (NoSuchMethodException e) {
++throw new IOException("Error NoSuchMethodException, could not 
add path to " + JAVALIBRARYPATH);
++} catch (InvocationTargetException e) {
++throw new IOException("Error InvocationTargetException, could 
not add path to " + JAVALIBRARYPATH);
+ } catch (IllegalAccessException e) {
+ throw new IOException("Error IllegalAccessExcepti

Bug#955694: scilab: FTBFS: Scilab cannot create Scilab Java Main-Class (we have not been able to find the main Scilab class. Check if the Scilab and thirdparty packages are available).

[Gilles Filippini]

Gilles Filippini a écrit le 22/04/2020 à 09:59 :
> Hi,
> 
> Matthias Klose a écrit le 20/04/2020 à 12:49 :
>> On 4/20/20 11:52 AM, Gilles Filippini wrote:
>>> I'd like to do a bisect between openjdk-11 11.0.6+10-2 and 11.0.7+9-1 to
>>> better understand the problem but I can't find the corresponding branch
>>> on the openjdk Mercurial repo.
>>
>> http://hg.openjdk.java.net/jdk-updates/jdk11u/
>>
> 
> This commit is the culprit:
> http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/21710e014d7f
> 
> It makes sense since it is related to System.loadLibrary().
> 
> Because Scilab loads Java from C++ code I guess moving usr_paths ans
> sys_paths initialization out of System.loadLibrary might have some
> consequences.
> 
> Applying the attached patch to openjdk-11 solves the problem. Not sure
> this is the right thing to do, but it keeps the deadlock fix brought by
> the jdk changeset and allows for sys_paths and usr_paths initialization
> in System.loadLibrary() when needed.
> 
> @doko, please consider adding this patch to the openjdk-11 source
> package until a proper fix is found for Scilab.

I think I've eventually found a fix for Scilab. Please hold.

_g.

Bug#955694: scilab: FTBFS: Scilab cannot create Scilab Java Main-Class (we have not been able to find the main Scilab class. Check if the Scilab and thirdparty packages are available).

[Gilles Filippini]

Hi,

Matthias Klose a écrit le 20/04/2020 à 12:49 :
> On 4/20/20 11:52 AM, Gilles Filippini wrote:
>> I'd like to do a bisect between openjdk-11 11.0.6+10-2 and 11.0.7+9-1 to
>> better understand the problem but I can't find the corresponding branch
>> on the openjdk Mercurial repo.
> 
> http://hg.openjdk.java.net/jdk-updates/jdk11u/
> 

This commit is the culprit:
http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/21710e014d7f

It makes sense since it is related to System.loadLibrary().

Because Scilab loads Java from C++ code I guess moving usr_paths ans
sys_paths initialization out of System.loadLibrary might have some
consequences.

Applying the attached patch to openjdk-11 solves the problem. Not sure
this is the right thing to do, but it keeps the deadlock fix brought by
the jdk changeset and allows for sys_paths and usr_paths initialization
in System.loadLibrary() when needed.

@doko, please consider adding this patch to the openjdk-11 source
package until a proper fix is found for Scilab.

Thanks,

_g.
Index: openjdk-11-11.0.7+10/src/java.base/share/classes/java/lang/ClassLoader.java
===
--- openjdk-11-11.0.7+10.orig/src/java.base/share/classes/java/lang/ClassLoader.java
+++ openjdk-11-11.0.7+10/src/java.base/share/classes/java/lang/ClassLoader.java
@@ -2620,9 +2620,10 @@ public abstract class ClassLoader {
 boolean isAbsolute) {
 ClassLoader loader =
 (fromClass == null) ? null : fromClass.getClassLoader();
-assert sys_paths != null : "should be initialized at this point";
-assert usr_paths != null : "should be initialized at this point";
-
+if (sys_paths == null) {
+usr_paths = initializePath("java.library.path");
+sys_paths = initializePath("sun.boot.library.path");
+}
 if (isAbsolute) {
 if (loadLibrary0(fromClass, new File(name))) {
 return;

Bug#955694: scilab: FTBFS: Scilab cannot create Scilab Java Main-Class (we have not been able to find the main Scilab class. Check if the Scilab and thirdparty packages are available).

[Gilles Filippini]

Control: tags -1 + help

Lucas Nussbaum a écrit le 03/04/2020 à 21:55 :
> Source: scilab
> Version: 6.1.0+dfsg1-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200402 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):
[...]
>> -- Building documentation (en_US) --
>> LANG=en_US.UTF-8 LC_ALL=C SCI_DISABLE_TK=1 SCI_JAVA_ENABLE_HEADLESS=1 
>> _JAVA_OPTIONS='-Djava.awt.headless=true' HOME=/tmp ./bin/scilab-adv-cli 
>> -noatomsautoload -nb -l en_US -nouserstartup -e "try 
>> xmltojar([],[],'en_US');catch disp(lasterror()); exit(-1);end;exit(0);"
>> Picked up _JAVA_OPTIONS: 
>> -Djava.class.path=/usr/share/java/flexdock.jar:/usr/share/java/skinlf.jar:/usr/share/java/looks.jar:/usr/share/java/commons-logging.jar:/usr/share/java/jhall.jar:/usr/share/java/lucene-core-4.10.4.jar:/usr/share/java/lucene-analyzers-common-4.10.4.jar:/usr/share/java/lucene-queryparser-4.10.4.jar:/usr/share/maven-repo/org/freehep/freehep-util/debian/freehep-util-debian.jar:/usr/share/maven-repo/org/freehep/freehep-io/debian/freehep-io-debian.jar:/usr/share/maven-repo/org/freehep/freehep-graphicsio/debian/freehep-graphicsio-debian.jar:/usr/share/java/freehep-graphicsio-emf-2.1.jar:/usr/share/java/freehep-graphics2d-2.1.1.jar:/usr/share/java/jrosetta-API.jar:/usr/share/java/jrosetta-engine-1.0.4.jar:/usr/share/java/jgraphx.jar:/usr/share/java/jogl2.jar:/usr/share/java/gluegen2-rt.jar:/usr/share/java/jeuclid-core.jar:/usr/share/java/jlatexmath-fop-1.0.7.jar:/usr/share/java/fop.jar:/usr/share/java/saxon.jar:/usr/share/java/batik.jar:/usr/share/java/xml-apis-ext.jar:/usr/share/java/commons-io.jar:/usr/share/java/xmlgraphics-commons.jar:/usr/share/java/avalon-framework.jar:/usr/share/java/jlatexmath-1.0.7.jar:/usr/share/java/ecj.jar:/usr/share/java/javax.activation.jar:/usr/share/java/jaxb-runtime.jar:modules/commons/jar/org.scilab.modules.commons.jar:modules/console/jar/org.scilab.modules.console.jar:modules/history_browser/jar/org.scilab.modules.history_browser.jar:modules/jvm/jar/org.scilab.modules.jvm.jar:modules/graph/jar/org.scilab.modules.graph.jar:modules/scinotes/jar/org.scilab.modules.scinotes.jar:modules/localization/jar/org.scilab.modules.localization.jar:modules/renderer/jar/org.scilab.modules.renderer.jar:modules/javasci/jar/org.scilab.modules.javasci.jar:modules/ui_data/jar/org.scilab.modules.ui_data.jar:modules/core/jar/org.scilab.modules.core.jar:modules/completion/jar/org.scilab.modules.completion.jar:modules/gui/jar/org.scilab.modules.gui.jar:modules/helptools/jar/org.scilab.modules.helptools.jar:modules/external_objects_java/tests/libintl.jar:modules/external_objects_java/jar/org.scilab.modules.external_objects_java.jar:modules/scirenderer/jar/scirenderer.jar:modules/types/jar/org.scilab.modules.types.jar:modules/preferences/jar/org.scilab.modules.preferences.jar:modules/action_binding/jar/org.scilab.modules.action_binding.jar:modules/history_manager/jar/org.scilab.modules.history_manager.jar:modules/graphic_objects/jar/org.scilab.modules.graphic_objects.jar:modules/xcos/jar/org.scilab.modules.xcos.jar:modules/graphic_export/jar/org.scilab.modules.graphic_export.jar:
>>  -Djava.awt.headless=true
>> WARNING: An illegal reflective access operation has occurred
>> WARNING: Illegal reflective access by org.scilab.modules.jvm.LibraryPath 
>> (file:/<>/scilab/modules/jvm/jar/org.scilab.modules.jvm.jar) to 
>> field java.lang.ClassLoader.sys_paths
>> WARNING: Please consider reporting this to the maintainers of 
>> org.scilab.modules.jvm.LibraryPath
>> WARNING: Use --illegal-access=warn to enable warnings of further illegal 
>> reflective access operations
>> WARNING: All illegal access operations will be denied in a future release
>> Could not access to the Main Scilab Class:
>> Exception in thread "main" java.lang.ExceptionInInitializerError
>>  at org.scilab.modules.localization.Messages.gettext(Unknown Source)
>>  at org.scilab.modules.commons.xml.XConfiguration.(Unknown 
>> Source)
>>  at org.scilab.modules.core.Scilab.(Unknown Source)
>> Caused by: java.lang.NullPointerException
>>  at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2646)
>>  at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:830)
>>  at java.base/java.lang.System.loadLibrary(System.java:1870)
>>  at org.scilab.modules.localization.MessagesJNI.(Unknown Source)
>>  ... 3 more
>>
>> Scilab cannot create Scilab Java Main-Class (we have not been able to find 
>> the main Scilab class. Check if the Scilab and thirdparty packages are 
>> available).
>> make[2]: *** [Makefile:2250: doc] Error 1
> 
> The full build log is available from:
>http://qa-logs.debian.net/2020/04/02/scilab_6.1.0+dfsg1-1_unstable.log

This is a runtime error, not a build one. It occurs the very same way
when running the current scilab binary (6.1.0+dfsg1-1) with openjdk-11
11.0.7+9-1.

A change 

Bug#955456: bitshuffle: diff for NMU version 0.3.5-3.1

[Gilles Filippini]

Control: tags 955456 + pending


Dear maintainer,

_g.

I've prepared an NMU for bitshuffle (versioned as 0.3.5-3.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru bitshuffle-0.3.5/debian/changelog bitshuffle-0.3.5/debian/changelog
--- bitshuffle-0.3.5/debian/changelog   2019-12-01 19:03:38.0 +0100
+++ bitshuffle-0.3.5/debian/changelog   2020-04-07 20:50:47.0 +0200
@@ -1,3 +1,21 @@
+bitshuffle (0.3.5-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Drew Parsons , Gilles Filippini  ]
+  * Closes: #955456
+- fix-deprecated.patch: fix test_h5filter.py and test_h5plugin.py
+  to open files with flag 'w' when required
+- Build-Depends: python3-h5py-mpi to force using the mpi flavour
+  of h5py
+- override_dh_auto_test:
+  - Run the tests via mpirun so that h5py knows it has to invoke its
+mpi implementation
+  - Launch the tests for each python version separately to permit MPI
+initialization at each run
+
+ -- Gilles Filippini   Tue, 07 Apr 2020 20:50:47 +0200
+
 bitshuffle (0.3.5-3) unstable; urgency=medium
 
   * don't use -march=native when building the package
diff -Nru bitshuffle-0.3.5/debian/control bitshuffle-0.3.5/debian/control
--- bitshuffle-0.3.5/debian/control 2019-12-01 19:03:38.0 +0100
+++ bitshuffle-0.3.5/debian/control 2020-04-06 14:46:51.0 +0200
@@ -11,7 +11,7 @@
 #  , libopenmpi-dev
, openmpi-bin
, python3-setuptools
-   , python3-h5py
+   , python3-h5py-mpi
 , quilt
 , cmake
, pkg-config
diff -Nru bitshuffle-0.3.5/debian/patches/fix-deprecated.patch 
bitshuffle-0.3.5/debian/patches/fix-deprecated.patch
--- bitshuffle-0.3.5/debian/patches/fix-deprecated.patch1970-01-01 
01:00:00.0 +0100
+++ bitshuffle-0.3.5/debian/patches/fix-deprecated.patch2020-04-06 
14:46:44.0 +0200
@@ -0,0 +1,53 @@
+Index: bitshuffle-0.3.5/bitshuffle/tests/test_h5filter.py
+===
+--- bitshuffle-0.3.5.orig/bitshuffle/tests/test_h5filter.py
 bitshuffle-0.3.5/bitshuffle/tests/test_h5filter.py
+@@ -23,7 +23,7 @@ class TestFilter(unittest.TestCase):
+ dtype = np.int64
+ data = np.arange(shape[0])
+ fname = "tmp_test_filters.h5"
+-f = h5py.File(fname)
++f = h5py.File(fname, 'w')
+ h5.create_dataset(f, b"range", shape, dtype, chunks,
+ filter_pipeline=(32008, 32000),
+ filter_flags=(h5z.FLAG_MANDATORY, h5z.FLAG_MANDATORY),
+@@ -43,7 +43,7 @@ class TestFilter(unittest.TestCase):
+ dtype = np.int64
+ data = np.arange(shape[0])
+ fname = "tmp_test_filters.h5"
+-f = h5py.File(fname)
++f = h5py.File(fname, 'w')
+ h5.create_dataset(f, b"range", shape, dtype, chunks,
+ filter_pipeline=(32008, 32000),
+ filter_flags=(h5z.FLAG_MANDATORY, h5z.FLAG_MANDATORY),
+@@ -65,7 +65,7 @@ class TestFilter(unittest.TestCase):
+ dtype = np.int64
+ data = np.arange(shape[0])
+ fname = "tmp_test_filters.h5"
+-f = h5py.File(fname)
++f = h5py.File(fname, 'w')
+ h5.create_dataset(f, b"range", shape, dtype, chunks,
+ filter_pipeline=(32008,),
+ filter_flags=(h5z.FLAG_MANDATORY,),
+Index: bitshuffle-0.3.5/bitshuffle/tests/test_h5plugin.py
+===
+--- bitshuffle-0.3.5.orig/bitshuffle/tests/test_h5plugin.py
 bitshuffle-0.3.5/bitshuffle/tests/test_h5plugin.py
+@@ -34,7 +34,7 @@ class TestFilterPlugins(unittest.TestCas
+ dtype = np.int64
+ data = np.arange(shape[0])
+ fname = "tmp_test_filters.h5"
+-f = h5py.File(fname)
++f = h5py.File(fname, 'w')
+ tid = h5t.py_create(dtype, logical=1)
+ sid = h5s.create_simple(shape, shape)
+ #
+@@ -72,7 +72,7 @@ class TestFilterPlugins(unittest.TestCas
+ #return
+ ## Does not appear to be supported by h5py.
+ #fname = "tmp_test_h5py_hl.h5"
+-#f = h5py.File(fname)
++#f = h5py.File(fname, 'w')
+ #f.create_dataset("range", np.arange(1024, dtype=np.int64),
+ #compression=32008)
+ 
diff -Nru bitshuffle-0.3.5/debian/patches/series 
bitshuffle-0.3.5/debian/patches/series
--- bitshuffle-0.3.5/debian/patches/series  2019-12-01 19:03:38.0 
+0100
+++ bitshuffle-0.3.5/debian/patches/series  2020-04-06 14:46:44.0 
+0200
@@ -1,2 +1,3 @@
 hdf5-old-api.patch
 change-build-flags.patch
+fix-deprecated.patch
diff -Nru bitshuffle-0.3.5/debian/rules bitshuffle-0.3.5/debian/rules
--- bitshuffle-0.3.5/debian/rules   2019-08-20 19:29:38.0 +0200
+++ bitshuffle-0.3.5/debian/rules

Bug#955456: FTBFS: test file tmp_test_filters.h5 does not exist

[Gilles Filippini]

Control: tags -1 + patch

Gilles Filippini a écrit le 06/04/2020 à 14:23 :
> Drew Parsons a écrit le 06/04/2020 à 05:08 :
>> On 2020-04-06 09:56, Drew Parsons wrote:
>>> On 2020-04-06 01:48, Gilles Filippini wrote:
>>>> Drew Parsons a écrit le 05/04/2020 à 18:57 :
>>>>>
>>>>> Another option is to create an environment variable to force h5py to
>>>>> load the mpi version even when run in a serial environment without
>>>>> mpirun. Easy enough to set up, though I'm interested to see if "mpirun
>>>>> -n 1 dh_auto_build" or a variation of that is viable.  Maybe
>>>>> %:
>>>>> mpirun -n 1 dh $@ --with python3 --buildsystem=pybuild
>>>>
>>>> This, way the test cases run against python3.7 is OK, but it fails
>>>> against python3.8 with:
>>>>
>>>> I: pybuild base:217: cd
>>>> /build/bitshuffle-z2ZvpN/bitshuffle-0.3.5/.pybuild/cpython3_3.8_bitshuffle/build;
>>>>
>>>> python3.8 -m unittest discover -v
>>>> [pinibrem15:43725] OPAL ERROR: Unreachable in file ext3x_client.c at
>>>> line 112
>>>> *** An error occurred in MPI_Init_thread
>>>> *** on a NULL communicator
>>>> *** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
>>>> ***    and potentially your MPI job)
>>>> [pinibrem15:43725] Local abort before MPI_INIT completed completed
>>>> successfully, but am not able to aggregate error messages, and not able
>>>> to guarantee that all other processes were killed!
>>>> E: pybuild pybuild:352: test: plugin distutils failed with: exit code=1:
>>>> cd
>>>> /build/bitshuffle-z2ZvpN/bitshuffle-0.3.5/.pybuild/cpython3_3.8_bitshuffle/build;
>>>>
>>>> python3.8 -m unittest discover -v
>>>> dh_auto_test: error: pybuild --test -i python{version} -p "3.7 3.8"
>>>> returned exit code 13
>>>>
>>>> But the HDF5 error is no more present with python3.7. So it seems a good
>>>> point.
>>>
>>>
>>> Strange again.  I would have expected the same behaviour in python3.8
>>> and python3.7, whether successful or unsuccessful.
>>
>>
>> Putting dh into mpirun seems to be interfering with process spawning. 
>> Once MPI is initialised (for the python3.7 test) it's not reinitialised
>> for the python3.8 and so it's in a bad state for the test. Something
>> like that.
>>
>> It's only in the tests where h5py is invoked that we get the problems.
>> This variant works, applying mpirun separately for each test run:
>>
>> override_dh_auto_test:
>>     set -e; \
>>     for py in `py3versions -s -v`; do \
>>   mpirun -n 1 pybuild --test -i python{version} -p $$py; \
>>     done
>>
>> (could use mpirun -n $(NPROC) for real mpi testing).
> 
> Yes, it works! \o/
> 
>> Do we want to use this as a solution? Or would you prefer an environment
>> variable that h5py can check to allow mpi invocation on a serial process?
> 
> I let this decision up to you. Whatever you choose it deserve a bit fat
> note in README.Debian.
> 
>> Note that this means bitshuffle as built now is expressly tied in with
>> hdf5-mpi and h5py-mpi (this seems intentional by debian/rules and
>> debian/control, though the Build-Depends must be updated to
>> python3-h5py-mpi).  It's a separate question whether it's desirable to
>> also support a hdf5-serial build of bitshuffle.  Likewise we need to
>> think about what we want to happen when bitshuffle is invoked in a
>> serial process.
> 
> I'll let that to the bitshuffle maintainer. I'll propose a patch to fix
> the current FTBFS, sticking on the mpi flavour to be conservative vs
> bitshuffle's previous builds.

Here it is.

_g.
diff -Nru bitshuffle-0.3.5/debian/changelog bitshuffle-0.3.5/debian/changelog
--- bitshuffle-0.3.5/debian/changelog   2019-12-01 19:03:38.00000 +0100
+++ bitshuffle-0.3.5/debian/changelog   2020-04-06 14:47:10.0 +0200
@@ -1,3 +1,21 @@
+bitshuffle (0.3.5-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Drew Parsons , Gilles Filippini  ]
+  * Closes: #955456
+- fix-deprecated.patch: fix test_h5filter.py and test_h5plugin.py
+  to open files with flag 'w' when required
+- Build-Depends: python3-h5py-mpi to force using the mpi flavour
+  of h5py
+- override_dh_auto_test:
+  - Run the tests via mpirun so that h5py knows it has to invoke its
+mpi implementation
+  - Launch the tests for each python version separat

Bug#955456: FTBFS: test file tmp_test_filters.h5 does not exist

[Gilles Filippini]

Drew Parsons a écrit le 06/04/2020 à 05:08 :
> On 2020-04-06 09:56, Drew Parsons wrote:
>> On 2020-04-06 01:48, Gilles Filippini wrote:
>>> Drew Parsons a écrit le 05/04/2020 à 18:57 :
>>>>
>>>> Another option is to create an environment variable to force h5py to
>>>> load the mpi version even when run in a serial environment without
>>>> mpirun. Easy enough to set up, though I'm interested to see if "mpirun
>>>> -n 1 dh_auto_build" or a variation of that is viable.  Maybe
>>>> %:
>>>> mpirun -n 1 dh $@ --with python3 --buildsystem=pybuild
>>>
>>> This, way the test cases run against python3.7 is OK, but it fails
>>> against python3.8 with:
>>>
>>> I: pybuild base:217: cd
>>> /build/bitshuffle-z2ZvpN/bitshuffle-0.3.5/.pybuild/cpython3_3.8_bitshuffle/build;
>>>
>>> python3.8 -m unittest discover -v
>>> [pinibrem15:43725] OPAL ERROR: Unreachable in file ext3x_client.c at
>>> line 112
>>> *** An error occurred in MPI_Init_thread
>>> *** on a NULL communicator
>>> *** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
>>> ***    and potentially your MPI job)
>>> [pinibrem15:43725] Local abort before MPI_INIT completed completed
>>> successfully, but am not able to aggregate error messages, and not able
>>> to guarantee that all other processes were killed!
>>> E: pybuild pybuild:352: test: plugin distutils failed with: exit code=1:
>>> cd
>>> /build/bitshuffle-z2ZvpN/bitshuffle-0.3.5/.pybuild/cpython3_3.8_bitshuffle/build;
>>>
>>> python3.8 -m unittest discover -v
>>> dh_auto_test: error: pybuild --test -i python{version} -p "3.7 3.8"
>>> returned exit code 13
>>>
>>> But the HDF5 error is no more present with python3.7. So it seems a good
>>> point.
>>
>>
>> Strange again.  I would have expected the same behaviour in python3.8
>> and python3.7, whether successful or unsuccessful.
> 
> 
> Putting dh into mpirun seems to be interfering with process spawning. 
> Once MPI is initialised (for the python3.7 test) it's not reinitialised
> for the python3.8 and so it's in a bad state for the test. Something
> like that.
> 
> It's only in the tests where h5py is invoked that we get the problems.
> This variant works, applying mpirun separately for each test run:
> 
> override_dh_auto_test:
>     set -e; \
>     for py in `py3versions -s -v`; do \
>   mpirun -n 1 pybuild --test -i python{version} -p $$py; \
>     done
> 
> (could use mpirun -n $(NPROC) for real mpi testing).

Yes, it works! \o/

> Do we want to use this as a solution? Or would you prefer an environment
> variable that h5py can check to allow mpi invocation on a serial process?

I let this decision up to you. Whatever you choose it deserve a bit fat
note in README.Debian.

> Note that this means bitshuffle as built now is expressly tied in with
> hdf5-mpi and h5py-mpi (this seems intentional by debian/rules and
> debian/control, though the Build-Depends must be updated to
> python3-h5py-mpi).  It's a separate question whether it's desirable to
> also support a hdf5-serial build of bitshuffle.  Likewise we need to
> think about what we want to happen when bitshuffle is invoked in a
> serial process.

I'll let that to the bitshuffle maintainer. I'll propose a patch to fix
the current FTBFS, sticking on the mpi flavour to be conservative vs
bitshuffle's previous builds.

> I think part of the confusion here is that bitshuffle (at least in the
> tests) is double-handling the HDF5 library, with direct calls on the one
> hand, but indirectly through h5py as well, on the other hand.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#955456: FTBFS: test file tmp_test_filters.h5 does not exist

[Gilles Filippini]

Drew Parsons a écrit le 05/04/2020 à 18:57 :
> On 2020-04-05 22:34, Gilles Filippini wrote:
>> I suspect a mismatch between mpi and serial build-depdencies:
>>
>> python3-h5py-serial + libhdf5-dev    => OK
>> python3-h5py-serial + libhdf5-openmpi-dev    => KO
>> python3-h5py-mpi + libhdf5-dev    => KO
>> python3-h5py-mpi + libhdf5-openmpi-dev    => KO(*)
>>
>> (*) because it fails to import h5py submodules when python3-h5py-serial
>> is not installed:
>> ImportError: cannot import name 'h5f' from 'h5py' (unknown location)
>>
>> With the 2.10.0-5 layout it seems impossible to build against the 'mpi'
>> flavour, while building against 'serial' flavour requires serial flavour
>> of libhdf5 -dev package as well.
> 
> 
> I've set up h5py so that the mpi build is only invoked when actually run
> with mpirun. In that sense the two builds are complementary rather than
> replacements (there was complaining that module loading was too slow
> when I had h5py built only against hdf5-mpi).  It seemed to me that's
> desirable to allow both serial and mpi builds of h5py to be installable
> at the same time, just as libhdf_*.so is, so I didn't want
> python3-h5py-serial and python3-h5py-mpi to Replace and Conflicts with
> each other.
> 
> Probably this is what's going on. bitshuffle is trying to make an mpi
> build, but running the build single processor so h5py accesses hdf5-serial.
> 
> In that case, running the bitshuffle mpi build in mpi might help, as in
> "mpirun -n 1 python3 setup.py". Not sure if that would be easy to do,
> e.g. if it's as "simple" as
> 
> override_dh_auto_build:
> 
>     mpirun -n 1 dh_auto_build
> 
> Another option is to create an environment variable to force h5py to
> load the mpi version even when run in a serial environment without
> mpirun. Easy enough to set up, though I'm interested to see if "mpirun
> -n 1 dh_auto_build" or a variation of that is viable.  Maybe
> %:
> mpirun -n 1 dh $@ --with python3 --buildsystem=pybuild

This, way the test cases run against python3.7 is OK, but it fails
against python3.8 with:

I: pybuild base:217: cd
/build/bitshuffle-z2ZvpN/bitshuffle-0.3.5/.pybuild/cpython3_3.8_bitshuffle/build;
python3.8 -m unittest discover -v
[pinibrem15:43725] OPAL ERROR: Unreachable in file ext3x_client.c at
line 112
*** An error occurred in MPI_Init_thread
*** on a NULL communicator
*** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
***and potentially your MPI job)
[pinibrem15:43725] Local abort before MPI_INIT completed completed
successfully, but am not able to aggregate error messages, and not able
to guarantee that all other processes were killed!
E: pybuild pybuild:352: test: plugin distutils failed with: exit code=1:
cd
/build/bitshuffle-z2ZvpN/bitshuffle-0.3.5/.pybuild/cpython3_3.8_bitshuffle/build;
python3.8 -m unittest discover -v
dh_auto_test: error: pybuild --test -i python{version} -p "3.7 3.8"
returned exit code 13

But the HDF5 error is no more present with python3.7. So it seems a good
point.

_g.



signature.asc
Description: OpenPGP digital signature

Bug#955456: FTBFS: test file tmp_test_filters.h5 does not exist

[Gilles Filippini]

Drew Parsons a écrit le 05/04/2020 à 15:28 :
> On 2020-04-05 20:38, Gilles Filippini wrote:
>>>
>>> But it must be something else from these new h5py upstream patches
>>> that's leading to any other bitshuffle errors (the ones apart from the
>>> file-not-found error).
>>
>> Nope. Seems related to the h5py 'serial' flavour only. It appears for
>> the first time when you configure the build for both flavours. If I
>> force the 'mpi' flavour installation *without* the 'serial' one,
>> bitshuffle builds fine.
>>
> 
> A good clue. I've pushed a h5py without the patches, but looks like the
> problem might remain. Strange if bitshuffle builds fine against h5py-mpi
> but not against h5py-serial. You'd expect any problem to come the other
> way around.

I suspect a mismatch between mpi and serial build-depdencies:

python3-h5py-serial + libhdf5-dev   => OK
python3-h5py-serial + libhdf5-openmpi-dev   => KO
python3-h5py-mpi + libhdf5-dev  => KO
python3-h5py-mpi + libhdf5-openmpi-dev  => KO(*)

(*) because it fails to import h5py submodules when python3-h5py-serial
is not installed:
ImportError: cannot import name 'h5f' from 'h5py' (unknown location)

With the 2.10.0-5 layout it seems impossible to build against the 'mpi'
flavour, while building against 'serial' flavour requires serial flavour
of libhdf5 -dev package as well.

_g.



signature.asc
Description: OpenPGP digital signature

Bug#955456: FTBFS: test file tmp_test_filters.h5 does not exist

[Gilles Filippini]

Drew Parsons a écrit le 03/04/2020 à 15:08 :
> On 2020-04-03 20:13, Gilles Filippini wrote:
>>
>> This is not related to the ongoing hdf5 transition, but to the recent
>> uploads of h5py >= 2.10.0-3. Before triggering the hdf5 transition I've
>> checked that bitshuffle builds successfully. It was against h5py
>> 2.10.0-2 by then.
> 
> 
> The change in behaviour comes from the h5py upstream patches applied in
> h5py 2.10.0-3.
> 
> file_default_read_5e71c49.patch in particular is the one that updates
> the API, setting File() to mode='r' by default.  I added the patch to
> deal with the H5pyDeprecationWarning we were getting, since the change
> was flagged as coming in from upstream anyway.  In principle it just
> means mode needs to be added explicitly as h5py.File(filename, mode), if
> the required mode is not 'r'.
> 
> But it must be something else from these new h5py upstream patches
> that's leading to any other bitshuffle errors (the ones apart from the
> file-not-found error).

Nope. Seems related to the h5py 'serial' flavour only. It appears for
the first time when you configure the build for both flavours. If I
force the 'mpi' flavour installation *without* the 'serial' one,
bitshuffle builds fine.

_g.



signature.asc
Description: OpenPGP digital signature

Bug#955456: FTBFS: test file tmp_test_filters.h5 does not exist

[Gilles Filippini]

Hi,

On Wed, 01 Apr 2020 11:47:33 +0800 Drew Parsons  wrote:
> Package: bitshuffle
> Version: 0.3.5-3
> Severity: serious
> Justification: FTBFS
> Control: block 954654 by -1
> 
> bitshuffle fails to build against hdf5: 1.10.6+repack-1, because
> tmp_test_filters.h5 does not exist
> 
> OSError: Unable to open file (unable to open file: name = 
> 'tmp_test_filters.h5', errno = 2, error message = 'No such file or 
> directory', flags = 0, o_flags = 0)
> 
> 
> The test filename 'tmp_test_filters.h5' is hardcoded in l.26 of
> bitshuffle/tests/test_h5filter.py

This is not related to the ongoing hdf5 transition, but to the recent
uploads of h5py >= 2.10.0-3. Before triggering the hdf5 transition I've
checked that bitshuffle builds successfully. It was against h5py
2.10.0-2 by then.

_g.



signature.asc
Description: OpenPGP digital signature

Bug#952615: hinge: FTBFS: fmt.h:22:10: fatal error: spdlog/fmt/bundled/core.h: No such file or directory

[Gilles Filippini]

Control: tag -1 + patch

Hi,

On Wed, 26 Feb 2020 17:09:48 +0100 Lucas Nussbaum  *wrote:
> Source: hinge
> Version: 0.5.0-5
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200225 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> This rebuild was done by building only architecture:any binary packages
> (binary-arch target of debian/rules).
> 
> Relevant part (hopefully):
> > cd /<>/obj-x86_64-linux-gnu/bin/maximal && /usr/bin/c++   
> > -I/<>/src/include  -g -O2 
> > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -std=gnu++11 
> > -fopenmp   -o CMakeFiles/get_maximal_reads.dir/maximal.cpp.o -c 
> > /<>/src/maximal/maximal.cpp
> > In file included from /usr/include/spdlog/common.h:38,
> >  from /usr/include/spdlog/spdlog.h:12,
> >  from /<>/src/consensus/draft.cpp:14:
> > /usr/include/spdlog/fmt/fmt.h:22:10: fatal error: 
> > spdlog/fmt/bundled/core.h: No such file or directory
> >22 | #include 
> >   |  ^~~
> > compilation terminated.
> > make[3]: *** [bin/consensus/CMakeFiles/draft_assembly.dir/build.make:66: 
> > bin/consensus/CMakeFiles/draft_assembly.dir/draft.cpp.o] Error 1

Patch proposal attached.

Thanks,

_g.
diff -Nru hinge-0.5.0/debian/changelog hinge-0.5.0/debian/changelog
--- hinge-0.5.0/debian/changelog2019-12-06 16:12:32.0 +0100
+++ hinge-0.5.0/debian/changelog2020-03-19 17:07:48.0 +0100
@@ -1,3 +1,10 @@
+hinge (0.5.0-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS against spdlog 1.5.0 (closes: #952615)
+
+ -- Gilles Filippini   Thu, 19 Mar 2020 17:07:48 +0100
+
 hinge (0.5.0-5) unstable; urgency=medium
 
   * Afif removed himself from Uploaders
diff -Nru hinge-0.5.0/debian/patches/series hinge-0.5.0/debian/patches/series
--- hinge-0.5.0/debian/patches/series   2019-12-06 16:12:32.0 +0100
+++ hinge-0.5.0/debian/patches/series   2020-03-19 17:07:48.0 +0100
@@ -2,3 +2,4 @@
 libspdlog-14.0.patch
 libspdlog-1:1.3.0
 2to3.patch
+spdlog-1.5.0.patch
diff -Nru hinge-0.5.0/debian/patches/spdlog-1.5.0.patch 
hinge-0.5.0/debian/patches/spdlog-1.5.0.patch
--- hinge-0.5.0/debian/patches/spdlog-1.5.0.patch   1970-01-01 
01:00:00.0 +0100
+++ hinge-0.5.0/debian/patches/spdlog-1.5.0.patch   2020-03-19 
17:07:48.0 +0100
@@ -0,0 +1,57 @@
+Index: hinge-0.5.0/src/consensus/CMakeLists.txt
+===
+--- hinge-0.5.0.orig/src/consensus/CMakeLists.txt
 hinge-0.5.0/src/consensus/CMakeLists.txt
+@@ -1,9 +1,10 @@
+ cmake_minimum_required(VERSION 3.2)
+ 
++add_definitions(-DSPDLOG_FMT_EXTERNAL)
+ add_executable(draft_assembly draft)
+-target_link_libraries(draft_assembly LAInterface ini falcon )
++target_link_libraries(draft_assembly fmt LAInterface ini falcon )
+ 
+ add_executable(consensus consensus.cpp)
+-target_link_libraries(consensus LAInterface falcon ini)
++target_link_libraries(consensus fmt LAInterface falcon ini)
+ 
+ install(TARGETS draft_assembly consensus DESTINATION ${libexec})
+Index: hinge-0.5.0/src/filter/CMakeLists.txt
+===
+--- hinge-0.5.0.orig/src/filter/CMakeLists.txt
 hinge-0.5.0/src/filter/CMakeLists.txt
+@@ -1,6 +1,7 @@
+ cmake_minimum_required(VERSION 3.2)
+ 
++add_definitions(-DSPDLOG_FMT_EXTERNAL)
+ add_executable(Reads_filter filter)
+-target_link_libraries(Reads_filter LAInterface ini )
++target_link_libraries(Reads_filter fmt LAInterface ini )
+ 
+ install(TARGETS Reads_filter DESTINATION ${libexec})
+Index: hinge-0.5.0/src/layout/CMakeLists.txt
+===
+--- hinge-0.5.0.orig/src/layout/CMakeLists.txt
 hinge-0.5.0/src/layout/CMakeLists.txt
+@@ -5,7 +5,8 @@ set(Boost_USE_STATIC_LIBS   ON)
+ FIND_PACKAGE( Boost COMPONENTS graph REQUIRED )
+ INCLUDE_DIRECTORIES( ${Boost_INCLUDE_DIR} )
+ 
++add_definitions(-DSPDLOG_FMT_EXTERNAL)
+ add_executable(hinging hinging)
+-target_link_libraries(hinging LAInterface ini  ${Boost_LIBRARIES})
++target_link_libraries(hinging fmt LAInterface ini  ${Boost_LIBRARIES})
+ 
+ install(TARGETS hinging DESTINATION ${libexec})
+Index: hinge-0.5.0/src/maximal/CMakeLists.txt
+===
+--- hinge-0.5.0.orig/src/maximal/CMakeLists.txt
 hinge-0.5.0/src/maximal/CMakeLists.txt
+@@ -1,6 +1,7 @@
+ cmake_minimum_required(VERSION 3.2)
+ 
++add_definitions(-DSPDLOG_FMT_EXTERNAL)
+ add_executable(get_maximal_reads maximal)
+-target_link_libraries(get_maximal_reads LAInterface ini )
++target_link_libraries(get_maximal_reads fmt LAInterface ini )
+ 
+ install(TARGETS get_maximal_reads DESTINATION ${libexec})


signature.asc
Description: OpenPGP digital signature

Bug#951856: jython-stilts: Wrong permissions on /usr/share/jython/Lib/site-packages/stilts$py.class

[Gilles Filippini]

Package: jython-stilts
Version: 3.2-1
Severity: serious

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

The postinstall script of jython-stilts installs this file with wrong
permissions:
- -rw--- 1 root root 508811 Feb 22 12:16 
'/usr/share/jython/Lib/site-packages/stilts$py.class'

This is reported by autopkgtests [1]:
autopkgtest [03:27:35]: test command2: jython 
src/testcases/uk/ac/starlink/ttools/tabletest.py
autopkgtest [03:27:35]: test command2: [---
Traceback (most recent call last):
  File "src/testcases/uk/ac/starlink/ttools/tabletest.py", line 2, in 
import stilts
IOError: [Errno 2] File not found - 
/usr/share/jython/Lib/site-packages/stilts$py.class (Permission denied)
autopkgtest [03:27:40]: test command2: ---]
autopkgtest [03:27:40]: test command2:  - - - - - - - - - - results - - - - - - 
- - - -
command2 FAIL non-zero exit status 1
autopkgtest [03:27:40]:  summary
command1 PASS
command2 FAIL non-zero exit status 1

[1] 
https://ci.debian.net/data/autopkgtest/testing/amd64/s/starjava-ttools/4342946/log.gz

Best,

_g.

- -- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages jython-stilts depends on:
ii  jython2.7.2~b2+repack1-1
pn  starlink-ttools-java  

jython-stilts recommends no packages.

jython-stilts suggests no packages.

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAl5RIhwACgkQ7+hsbH/+
z4PgaggAgVNOQGCitBjGjaarnN1yR/s+WzHHylts6ZFFZrjfEoeX6JLEo+B1oAdB
nDHCwokSoQb/cYkiAqwHCLrsXCLvzkP7lQi+ZD2Oj2rIoKpM703iqV1ZLcfGzzt7
MsQCePg3ZmpAaOHHLwFU3mKwGhVdu1jYceM2jmnlZgCPdNbw2E+Ulw8XSzgi4rKX
sIpakOjrfPWAovArcBLDQdZ9jbUyxJru8rRRhM/PID+Y/539iPRN2hAUblPCYPKm
Kialq/Y2gUz3WBal1zX0KpRNrALZJW0VmQvgnkB5pcZPpCOTNdFvXOi765D1Xr0S
syqruiKeg5IVuZhRege24uKBMo3i3Q==
=E3Ch
-END PGP SIGNATURE-

Bug#949869: libpbdata-dev: Missing Depends: libpbcopper-dev

[Gilles Filippini]

Package: libpbdata-dev
Version: 5.3.3+dfsg-2
Severity: serious
Justification: Causes FTBFS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

A tentative rebuild of pbdagcon failed with:
FORTIFY_SOURCE=2 -MMD -MP 
-I/build/pbdagcon-WqBR9Y/pbdagcon-0.3+git20161121.000+ds/DAZZ_DB 
-I/build/pbdagcon-WqBR9Y/pbdagcon-0.3+git20161121.000+ds/DALIGNER 
-I/usr/include/pbseq/alignment -I/usr/include/pbseq/pbdata 
-I/usr/include/pbseq/hdf -I/usr/include/pbseq -isystem.//third-party  -c -o 
main.o main.cpp
In file included from /usr/include/pbseq/pbdata/DNASequence.hpp:17,
 from SimpleAligner.hpp:5,
 from main.cpp:24:
/usr/include/pbbam/BamRecord.h:19:10: fatal error: pbcopper/data/MappedRead.h: 
No such file or directory
   19 | #include 
  |  ^~~~
compilation terminated.

The header pbseq/pbdata/DNASequence.hpp is part of libpbdata-dev, and
pbcopper/data/MappedRead.h is part of libpbcopper-dev. Because the former
requires a header from the later, there should be a Depends relation
between those two packages.

Thanks,

_g.

- -- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libpbdata-dev depends on:
pn  libpbdata  

libpbdata-dev recommends no packages.

libpbdata-dev suggests no packages.

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAl4thnkACgkQ7+hsbH/+
z4O3BwgAhvxEmXCM7fQTFleSkcH94ic5I1Sk3jdPRytxJ2rMCnl9/D7/rDBpEBVS
ll+jOQNZi68E2WLt54QPwdw6PefnZdScfGp9bNFn5/kRKv5TZ2pWx3ixFx3H9V76
FuIAzuaQg5u1GmrDqF25F+q5f7sn+S48AshZI6VrxtRJBTRVou8McK08hLUS5EeW
e2S69q+253ukMXyspOu37jEaRw7ACKH+d1beFM8NYf/rbQSexB1bktpTDQKD4P+4
E4FNIxonEFZ+PNghEUQhfsNKtpEXMwiS/B1sKhY5kgdOZtp7AnQ+XePjLQRzVTxe
9wdfFb9eBceQskOKH8taVAwuWmxCxQ==
=68VW
-END PGP SIGNATURE-

Bug#949544: src:deal.ii: FTBFS with tbb 2020.0-2

[Gilles Filippini]

Package: src:deal.ii
Version: 9.1.1-8
Severity: serious
Justification: FTBFS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

deal.II FTBFS when built against tbb 2020.0-2:
- -- Found TBB_LIBRARY
- -- TBB_DEBUG_LIBRARY not found! Call:
- -- FIND_LIBRARY(TBB_DEBUG_LIBRARY NAMES tbb_debug HINTS PATH_SUFFIXES lib 
lib64 lib)
- -- Found TBB_INCLUDE_DIR
- --   TBB_VERSION: 0.0
- --   TBB_LIBRARIES: /usr/lib/x86_64-linux-gnu/libtbb.so
- --   TBB_INCLUDE_DIRS: /usr/include
- --   TBB_USER_INCLUDE_DIRS: /usr/include
- -- Found TBB
- -- The externally provided TBB library is older than version 4.2.0, which 
cannot be used with deal.II.
- -- DEAL_II_WITH_THREADS has unmet external dependencies.
CMake Error at cmake/macros/macro_configure_feature.cmake:112 (MESSAGE):
  

  Could not find the threads library!

  The externally provided TBB library is older than version

  4.2.0, which is the oldest version compatible with deal.II and its

  supported compilers.Please ensure that a suitable threads library is
  installed on your computer.

  If the library is not at a default location, either provide some hints for
  autodetection, or set the relevant variables by hand in ccmake.

Thanks,

_g.

- -- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAl4nXocACgkQ7+hsbH/+
z4MlNQf+IQYXIr0lT+XBnaRT8nBTeVRggaU6v+Eo6h/3LkG2ykrkDvG4BFUxMHWj
lMIrpBKXo98cUVCXjb+7woIt0xtnMLhQqk+zpKQVrGOafSrJJ0ebaRDr2+lXRVtQ
OPQ6zXPyItDwA4gbpdG+tVJWGbpo6jgCVdFYKy6NPO6Nh1HCVmOJ1Rqx+K99F5pV
la7Kr9Oz6QzSwBav1lO41fFLrZoTNJ7eFRizaL9YvXvfIE2jiU2PSNEQuOHoUTXQ
ocuRqP2cIxKOb96o8/vYooqAFrePigtpgl07JtP0dESAhXpYeHrrBLdglwus23wn
W+J8EM/O2v1yUF0rZqFC1cRIxLZpTw==
=ljqV
-END PGP SIGNATURE-

Bug#949543: src:blasr: FTBFS with pbseqlib 5.3.3+dfsg-1

[Gilles Filippini]

Package: src:blasr
Version: 5.3.3+dfsg-3
Severity: serious
Justification: FTBFS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Blasr 5.3.3+dfsg-3 FTBFS when built against pbseqlib 5.3.3+dfsg-1:

 meson.build:64:0: ERROR: C++ library 'pbdata' not found


It seems related to this changelog entry from pbseqlib:
>  * Remove binary packages libpbdata and libpbihdf since these are
>header only libraries now

Thanks,

_g.

- -- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAl4nWbAACgkQ7+hsbH/+
z4PbbAf7BGMs1D2tr7QRAMot8aIsMNO1lEwuYU75y/mHbt+TuwzvQL+1SbDkFM8B
R/pyC3kycX9wOl2vRDcc9b1+n7M5z3uWe52IO0H2y3ZKiZFfFRxNAZbSm3JhDVd0
hh1dp01ehAPb0YLpYiQapSUF8N9BPhcZXZJfIDXOCKgCa/TAUeFuXuzBM7dNOwYi
3Qn3leIjtsO2gFWH1dcVfFhFFgzRswN2qi9rH3zZ4AMgWyfYYwrNGGNYA2vJTUSD
S/0iJqGzWbi8evrHajA5g/9oC+tNY3/08e5kU/UMKi+PMosawB3vA91hynxqdYVb
mdbYtoNSiS3F0DX2nQ+s35yoSJANdg==
=CcMs
-END PGP SIGNATURE-

Bug#949542: src:pbdagcon: FTBFS with pbseqlib 5.3.3+dfsg-1

[Gilles Filippini]

Package: src:pbdagcon
Version: 0.3+git20161121.000+ds-1.1
Severity: serious
Justification: FTBFS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Pbdagcon FTBFS when built against pbseqlib 5.3.3+dfsg-1:
g++ -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -O3 -std=c++11 -Wall -Wuninitialized -pedantic 
-Wdate-time -D_FORTIFY_SOURCE=2 -MMD -MP -I/<>/DAZZ_DB 
-I/<>/DALIGNER -I/usr/include/pbseq/alignment 
-I/usr/include/pbseq/pbdata -I/usr/include/pbseq/hdf -I/usr/include/pbseq 
-isystem.//third-party  -c -o main.o main.cpp
In file included from SimpleAligner.hpp:5,
 from main.cpp:24:
/usr/include/pbseq/pbdata/DNASequence.hpp:4:10: fatal error: LibBlasrConfig.h: 
No such file or directory
4 | #include 
  |  ^~
compilation terminated.

The missing header LibBlasrConfig.h used to be part of libpbdata-dev.

Thanks,

_g.

- -- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAl4nW00ACgkQ7+hsbH/+
z4OfGQf+PL2qtI618amy3p+f7voJyYMt8nK9zEDtG6XyDfTmalC3xh7tlL8jnPZ+
qNOJea0QwpDiP1Vsec20HsJ5xMBmtLDwY+w+RDQhh3jd2ODlHfVoFCElDWKWPWs2
7mUGPfTPxOMwLvgxI+XyPvLqxYfw0HH6mDNQxcp8zzeNYFkqulUsgBYKIGjghmAr
m570ZnFMK8LrPUGaSjLKTCDs/n367NFiwqfWtXC0HMlt/pfYWGoqBh2zmqS2lD15
xX1ecd0eyRt6OoPlqk2eHubE9prc+f9cG3leHxl0+WvIVuZt92qUdT9sFK9FTDw5
XgjOSe4Sm5gYVn+EDTS7XOHyj5Cgng==
=ZCPV
-END PGP SIGNATURE-

Bug#947280: src:paraview: FTBFS on armel an mipsel: undefined reference to `__atomic_fetch_add_8'

[Gilles Filippini]

Package: src:paraview
Version: 5.7.0-3
Severity: serious
Tags: patch
Justification: FTBFS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

The same error is spotted in the logs of failed paraview 5.7.0 builds for
armel[1] and mipsel[2]:
/usr/bin/ld: ../../../../lib/mipsel-linux-gnu/libvtkprotobuf-pv5.7.so.5.7: 
undefined reference to `__atomic_fetch_add_8'

[1] 
https://buildd.debian.org/status/fetch.php?pkg=paraview=armel=5.7.0-3=1576169428=0
[2] 
https://buildd.debian.org/status/fetch.php?pkg=paraview=mipsel=5.7.0-1=1570637214=0

Please find attached a patch aiming to solve this problem. Not sure it'll
be sufficient to build successfully, but it should solve this issue at
least.

Thanks,

_g.

- -- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAl4BOnkACgkQ7+hsbH/+
z4Mb8gf/Zv+G/8fE0SNC1wR9l81HtcduHKpMzvaDV7cuk35kAMr/W60ieLqfaT7p
Z9PPgi3YD+CqElw317qbGwwxQI0VuMDxiSVKEXJsZePrg2Ff25wgy4pwSBpSjel+
9kljY0vTp0QxbO2ryZi846aH46PnQF9bppdhUocNg6igeSB/x9TUHICvyhVQ5ZNS
gKDnR5jcKlk5DIr2TRA9Xa/TEIONfoQAjGs+tNwWDYpLQnwYHQ+vT+9gL80U6MkO
jRnVKbHI0V7KQj4saoQf4eqSz2tX29hecrMQcut43YxCX3YDiomV9CxrWDWAbIOf
rzWBeG0mAHxtzdD55XqbtuN+R8jEQQ==
=z9To
-END PGP SIGNATURE-
diff -Nru paraview-5.7.0/debian/changelog paraview-5.7.0/debian/changelog
--- paraview-5.7.0/debian/changelog 2019-12-11 10:16:00.0 +0100
+++ paraview-5.7.0/debian/changelog 2019-12-23 22:33:43.0 +0100
@@ -1,3 +1,10 @@
+paraview (5.7.0-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * New patch libatomic.patch: tentative fix for FTBFS on armel and mipsel
+
+ -- Gilles Filippini   Mon, 23 Dec 2019 22:33:43 +0100
+
 paraview (5.7.0-3) unstable; urgency=medium
 
   * Hard-code Build-Dep on python3.8-dev. This wasn't being pulled in correctly
diff -Nru paraview-5.7.0/debian/patches/libatomic.patch 
paraview-5.7.0/debian/patches/libatomic.patch
--- paraview-5.7.0/debian/patches/libatomic.patch   1970-01-01 
01:00:00.0 +0100
+++ paraview-5.7.0/debian/patches/libatomic.patch   2019-12-23 
22:33:43.0 +0100
@@ -0,0 +1,22 @@
+Index: paraview-5.7.0/ThirdParty/protobuf/vtkprotobuf/src/CMakeLists.txt
+===
+--- paraview-5.7.0.orig/ThirdParty/protobuf/vtkprotobuf/src/CMakeLists.txt
 paraview-5.7.0/ThirdParty/protobuf/vtkprotobuf/src/CMakeLists.txt
+@@ -312,10 +312,16 @@ if (CMAKE_SYSTEM_NAME STREQUAL "Linux")
+   endif ()
+ endif ()
+ 
++if ((DEB_HOST_MULTIARCH STREQUAL "arm-linux-gnueabi") OR (DEB_HOST_MULTIARCH 
STREQUAL "mipsel-linux-gnu"))
++  set(ATOMIC_LIB atomic)
++else ()
++  set(ATOMIC_LIB "")
++endif ()
++
+ target_link_libraries(vtkprotoc
+   PRIVATE
+ ${vtkprotoc_no_as_needed}
+ vtklibprotoc
+ ParaView::protobuf
+-Threads::Threads)
++Threads::Threads ${ATOMIC_LIB})
+ add_executable(ParaView::protoc ALIAS vtkprotoc)
diff -Nru paraview-5.7.0/debian/patches/series 
paraview-5.7.0/debian/patches/series
--- paraview-5.7.0/debian/patches/series2019-12-11 10:16:00.0 
+0100
+++ paraview-5.7.0/debian/patches/series2019-12-23 22:33:43.0 
+0100
@@ -2,3 +2,4 @@
 security-format.patch
 override-fix.patch
 python3.8.patch
+libatomic.patch
diff -Nru paraview-5.7.0/debian/rules paraview-5.7.0/debian/rules
--- paraview-5.7.0/debian/rules 2019-12-11 10:16:00.0 +0100
+++ paraview-5.7.0/debian/rules 2019-12-23 22:33:43.0 +0100
@@ -73,7 +73,8 @@
-DPARAVIEW_ENABLE_PDAL=ON \
-DPARAVIEW_ENABLE_XDMF3=ON \
-DPARAVIEW_ENABLE_MOTIONFX=ON \
-   -DPARAVIEW_PLUGIN_ENABLE_EyeDomeLighting=ON 
+   -DPARAVIEW_PLUGIN_ENABLE_EyeDomeLighting=ON \
+   -DDEB_HOST_MULTIARCH=$(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 
 override_dh_auto_configure:
dh_auto_configure -- $(extra_flags)

Bug#944127: gfortran-9 causes libcgns FTBFS on ppc64el

[Gilles Filippini]

Gilles Filippini a écrit le 04/11/2019 à 20:00 :
> Unfortunately it currently doesn't build against gcc-snapshot, and I'm
> not at ease with the reported errors.

I eventually succeeded at building against gcc-snapshot, adding
'-fallow-argument-mismatch'. The cgread_f03 test failure is still there.

_g.

Bug#944127: gfortran-9 causes libcgns FTBFS on ppc64el

[Gilles Filippini]

Hi Matthias,

Matthias Klose a écrit le 04/11/2019 à 19:21 :
> Control: forwarded -1 https://gcc.gnu.org/PR92361
> 
> On 04.11.19 18:13, Gilles Filippini wrote:
>> I've recently uploaded libcgns 8.4.0-1~exp1 to experimental. All
>> builds but ppc64el are ok.
>>
>> The ppc64el failure [0] occurs in the test suite (test cgread_f03),
>> when a C va_arg function (src/cg_ftoc.c:cg_goto_f()) is called from
>> Fortran code (src/tests/cgread_f03.F90:421). This function is called
>> several times. Is is successful at first, then it fails badly because
>> the corresponding hidden string length parameters[1] are equal to 0.
>> This shouldn't happen because the related strings are literals:
>> 'Zone_t', 'GridCoordinates_t', 'end'.
>>
>> [0]https://buildd.debian.org/status/fetch.php?pkg=libcgns=ppc64el=3.4.0-1%7Eexp1=1572269974=0
>>
>> [1]https://gcc.gnu.org/onlinedocs/gfortran/Argument-passing-conventions.html
>>
>>
>> Further investigation shows that release 3.3.0-6 of libcgns FTBFS the
>> very same way with GCC 8.3.0, while it succeeded with GCC 8.2.0 [2].
>>
>> [2]https://buildd.debian.org/status/fetch.php?pkg=libcgns=ppc64el=3.3.0-6%2Bb2=1542797186=0
>>
>>
>> I then ran a bisect on the GCC svn branch 'gcc-8-branch' and found out
>> that the failure was introduced by the r269349 changeset [3].
>>
>> [3]https://gcc.gnu.org/viewcvs/gcc?view=revision=269349
>>
>> This is a backport of the trunk r268992 changetset [4] introduced
>> during GCC-9 development.
>>
>> [4]https://gcc.gnu.org/viewcvs/gcc?view=revision=268992
> 
> now forwarded, would be nice to provide to subscribe to the upstream issue.
> is this reproducible with gcc-snapshot?
> any idea for a test case?

Unfortunately it currently doesn't build against gcc-snapshot, and I'm
not at ease with the reported errors.
No idea for a test case. This seems memory related. Very simple tests
cases work AFAICT.

Thanks,

_g.

Bug#944127: gfortran-9 causes libcgns FTBFS on ppc64el

[Gilles Filippini]

Package: gfortran-9
Severity: serious
Justification: Causes FTBFS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

I've recently uploaded libcgns 8.4.0-1~exp1 to experimental. All builds but 
ppc64el are ok.

The ppc64el failure [0] occurs in the test suite (test cgread_f03), when a C 
va_arg function (src/cg_ftoc.c:cg_goto_f()) is called from Fortran code 
(src/tests/cgread_f03.F90:421). This function is called several times. Is is 
successful at first, then it fails badly because the corresponding hidden 
string length parameters[1] are equal to 0. This shouldn't happen because the 
related strings are literals: 'Zone_t', 'GridCoordinates_t', 'end'.

[0] 
https://buildd.debian.org/status/fetch.php?pkg=libcgns=ppc64el=3.4.0-1%7Eexp1=1572269974=0
[1] https://gcc.gnu.org/onlinedocs/gfortran/Argument-passing-conventions.html

Further investigation shows that release 3.3.0-6 of libcgns FTBFS the very same 
way with GCC 8.3.0, while it succeeded with GCC 8.2.0 [2].

[2] 
https://buildd.debian.org/status/fetch.php?pkg=libcgns=ppc64el=3.3.0-6%2Bb2=1542797186=0

I then ran a bisect on the GCC svn branch 'gcc-8-branch' and found out that the 
failure was introduced by the r269349 changeset [3].

[3] https://gcc.gnu.org/viewcvs/gcc?view=revision=269349

This is a backport of the trunk r268992 changetset [4] introduced during GCC-9 
development.

[4] https://gcc.gnu.org/viewcvs/gcc?view=revision=268992

At this point I don't know where to go. I'm setting severity = serious because 
this change now present into Debian/sid GCC-{7,8,9} makes libcgns FTBFS on 
ppc64el. Feel free to downgrade it if you think it appropriate.

Any help appreciated. Many thanks in advance,

_g.

- -- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAl3AXBgACgkQ7+hsbH/+
z4O20Af/U24cwYYZ52fdUfa82GGT8lMP2YIeZiOl9fm9F+6T1d5BFhJAUVGxei9e
3L+kGECJoTYcX8i3Ou0yKhPtuYCDaJ3ceBl93bBW5/obO+epWr3XLAkG5sVcJDO4
pHUh32dqjEuXCz6CZfPVv5bARSZpT9CUxyo1d6ylikfqbXCE0Rw8qeSj8Q2+iOyJ
xoLL9lZXLo9GnGvVz/O5+xtxulmF5F77uO+NmP6sr+7oqZydFb3j3f6//RTumpKs
Bco0A3tPtP71eCJsO+KwremHZV7MAAkUO5GBdQP7IcVj6rISJE08kI/hEmnP89wi
KcSoVYbi2Uax2lKqH/E57FqQlkkkHQ==
=5u/M
-END PGP SIGNATURE-

Bug#935086: insighttoolkit4 REMOVED from testing

[Gilles Filippini]

Control: tags -1 + patch

Hi,

Michael Crusoe a écrit le 04/10/2019 à 16:01 :
> Attached is a patch to force gcc 8; so far it has gotten farther than
> the previous failure for me (but my local build is still at 86%)

Looking at the related lines of /usr/include/c++/9/bits/stl_function.h,
it seems that __builtin_is_constant_evaluated is used only for C++
standard greater or equal to c++14:
> #if __cplusplus >= 201402L
> #ifdef _GLIBCXX_HAVE_BUILTIN_IS_CONSTANT_EVALUATED
>   if (__builtin_is_constant_evaluated())
> #else
>   if (__builtin_constant_p(__x > __y))
> #endif
> return __x > __y;
> #endif
>   return (__UINTPTR_TYPE__)__x > (__UINTPTR_TYPE__)__y;


Then I tried using '-std=c++11' and the build was successful.

Patch attached.

Thanks,

_g.
diff -Nru insighttoolkit4-4.12.2-dfsg1/debian/changelog 
insighttoolkit4-4.12.2-dfsg1/debian/changelog
--- insighttoolkit4-4.12.2-dfsg1/debian/changelog   2018-08-28 
16:27:47.0 +0200
+++ insighttoolkit4-4.12.2-dfsg1/debian/changelog   2019-10-07 
21:50:28.0 +0200
@@ -1,3 +1,10 @@
+insighttoolkit4 (4.12.2-dfsg1-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Force -std=c++11 to fix FTBFS with GCC-9 (closes: #935086)
+
+ -- Gilles Filippini   Mon, 07 Oct 2019 21:50:28 +0200
+
 insighttoolkit4 (4.12.2-dfsg1-4) unstable; urgency=medium
 
   * d/rules: Remove build dir right after installation
diff -Nru insighttoolkit4-4.12.2-dfsg1/debian/rules 
insighttoolkit4-4.12.2-dfsg1/debian/rules
--- insighttoolkit4-4.12.2-dfsg1/debian/rules   2018-08-28 16:27:47.0 
+0200
+++ insighttoolkit4-4.12.2-dfsg1/debian/rules   2019-10-07 21:50:28.0 
+0200
@@ -25,6 +25,9 @@
   ENABLE_UNSIGNED_LONG=ON 
 endif 
 
+# Fix for #935086
+export DEB_CXXFLAGS_MAINT_APPEND+=-std=c++11
+
 CMAKE_FLAGS = \
-DBUILD_EXAMPLES:BOOL=ON \
-DBUILD_SHARED_LIBS:BOOL=ON \


signature.asc
Description: OpenPGP digital signature

Bug#891993: syrthes-gui uses obsolete libs Qt4 and Python2

[Gilles Filippini]

Hi,

Moritz Mühlenhoff a écrit le 13/09/2019 à 23:18 :
> On Mon, Aug 19, 2019 at 02:12:35AM -0400, Scott Kitterman wrote:
>> On Sat, 03 Mar 2018 21:16:22 +0100 Andreas Beckmann  wrote:
>>> Source: syrthes
>>> Version: 4.3.0-dfsg1-2
>>> Severity: serious
>>> Tags: sid buster
>>> Justification: blocks python-qwt5-qt4 removal
>>> Control: block 886779 with -1
>>>
>>> Hi,
>>>
>>> src:syrthes Build-Depends on python-qwt5-qt4 which is scheduled for
>>> removal (#886779). Please switch to a Qt5 solution or drop the
>>> (Build-)Dependency altogether.
>>>
>>>
>>> Andreas
>>
>> These (along with python-qwt5-qt4) are being removed this cycyle.  Upstream 
>> does not have a Qt5/Python3 release yet.  If the Python3/Qt4 requirements 
>> are 
>> confined to the gui, maybe just that part can be dropped until upstream 
>> releases a version we can support.
> 
> Hi Gilles,
> syrthes is the only remaining packages blocking the removal of pyqwt5. Are
> you planning to port the GUI yourself, should we (temporarily, until fixed)
> drop the syrthes-gui package or if that's not an option, should syrthes be
> (temporarily) removed altogether?

Syrthes' upstream is quite unresponsive. A version 5 should be on its
way but there is no place to download it from and the preview I had more
than one year ago brought many dependencies with unclear licensing.

I think the best option for now would be to just drop syrthes-gui.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#935089: FTBFS: error: no dependency information found for /usr/lib/x86_64-linux-gnu/libeckit.so.0d

[Gilles Filippini]

Source: metview
Version: 5.6.1-1
Severity: serious
Justification: FTBFS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

During a rebuild on amd64 metview FTBFS with:
dpkg-shlibdeps: error: no dependency information found for 
/usr/lib/x86_64-linux-gnu/libeckit.so.0d (used by 
debian/metview/usr/lib/x86_64-linux-gnu/metview/Divrot)

Full build log available on request.

Thanks,

_g.

- -- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAl1ajrEACgkQ7+hsbH/+
z4MewwgAscBekD6em67hu3FCueJ+Kti5SRxZDSRnSKx7inpPBmima/Ke+a+RCeXU
Zgg6AEAgLNt5osJ9ezAOxOmPMR0FE1S0uZENda9+ZTvq5EL4g87kRGTlTFFJfP7S
gi6ADxfjv46tYbyBXGYW5TAXvnV7m1Y48OfoUYFXdG69yli3K5CE1vIyvHM3lxFw
dZsgiV0Nn0zdhltPfv4Z1XMyNu09mVr9PdZABLSpBnCOcR7lw7+UHxT7C3gxN6lo
X3vfhPHN04PGd7yzQXG84MyCtzABblIJoQKzuhbP41Lu7JOb9SjQKw31eDgLHFxz
4imYJFzijXv4sm9K6qKO9G9y+XsNbw==
=zU46
-END PGP SIGNATURE-

Bug#935086: insighttoolkit4: FTBFS with GCC-9: use of undeclared identifier '__builtin_is_constant_evaluated'

[Gilles Filippini]

Source: insighttoolkit4
Version: 4.12.2-dfsg1-4
Severity: serious
Justification: FTBFS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Insighttoolkit4 FTBFS with:
In file included from /<>/BUILD/Wrapping/itkFixedArray.cxx:1:
In file included from 
/<>/Modules/Core/Common/include/itkCommand.h:21:
In file included from 
/<>/Modules/Core/Common/include/itkObject.h:31:
In file included from 
/<>/Modules/Core/Common/include/itkLightObject.h:21:
In file included from 
/<>/Modules/Core/Common/include/itkMacro.h:47:
In file included from /usr/include/c++/9/string:48:
/usr/include/c++/9/bits/stl_function.h:418:6: error: use of undeclared 
identifier '__builtin_is_constant_evaluated'
if (__builtin_is_constant_evaluated())
^
- -- Found object: 
"/<>/data/.ExternalData/MD5/7665397f59eaeb65c578e8712be70e79"
/usr/include/c++/9/bits/stl_function.h:437:6: error: use of undeclared 
identifier '__builtin_is_constant_evaluated'
if (__builtin_is_constant_evaluated())
^
/usr/include/c++/9/bits/stl_function.h:456:6: error: use of undeclared 
identifier '__builtin_is_constant_evaluated'
if (__builtin_is_constant_evaluated())
^
/usr/include/c++/9/bits/stl_function.h:475:6: error: use of undeclared 
identifier '__builtin_is_constant_evaluated'
if (__builtin_is_constant_evaluated())
^
This seems related to GCC-9.
Full buildlog available on demand.

Thanks,

_g.

- -- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAl1ahPMACgkQ7+hsbH/+
z4NlqAf/YXeuCAqgyr66wanyke1aJJOn8YQr/eV/jPVc9LU0lhqwJyuH0KqGbfPG
3e/S7cwLRPtGfGDdiHHNIjLTxtbScWGEEQ8BYfOqosQ0tteP8H2BLzXp79gnNnUR
J4Boq3W+6BRKuUoa53YEoxCJIrz3fwlZR5oJWowfVhQ/XSWIFmoS/ZdQEuoAR5c/
CjidFWwk5DUAOT2x9NHpEeJCPkX1aYibYigQsMySfGB4zznoRbBe9Y/ttH1zyYPE
nwajwmd8dK7t1YGpkRucwCr6t5+nlKPKxlchwz4jY/isWfi2UpTP16tv8jAmPPCJ
VuUsplljecyl97yZu8hUKHe2fIMI8g==
=uac6
-END PGP SIGNATURE-

Bug#930368: gatb-core: FTBFS due to inaccurate symbols file

[Gilles Filippini]

Source: gatb-core
Version: 1.4.1+git20181225.44d5a44+dfsg-2
Severity: serious
Justification: FTBFS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

During a rebuild of gatb-core for unstable on amd64 I experienced a FTBFS at the
dh_makeshlibs step:

   dh_makeshlibs -O--sourcedirectory=gatb-core
dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/libgatbcore2/DEBIAN/symbols doesn't match 
completely debian/libgatbcore2.symbols.amd64
- --- debian/libgatbcore2.symbols.amd64 
(libgatbcore2_1.4.1+git20181225.44d5a44+dfsg-2_amd64)
+++ dpkg-gensymbolsErQvax   2019-06-11 09:56:28.965481025 +
@@ -8997,7 +8997,7 @@
  
_ZNSt6vectorISt5tupleIJjN4gatb4core5tools4math8LargeIntILi1EEEjjjEESaIS7_EE12emplace_backIJS7_EEEvDpOT_@Base
 1.4.1+git20181225.44d5a44+dfsg
  
_ZNSt6vectorISt5tupleIJjN4gatb4core5tools4math8LargeIntILi1EEEjjjEESaIS7_EE17_M_realloc_insertIJS7_EEEvN9__gnu_cxx17__normal_iteratorIPS7_S9_EEDpOT_@Base
 1.4.1
  
_ZNSt6vectorISt5tupleIJjN4gatb4core5tools4math8LargeIntILi1EEEjjjEESaIS7_EE7reserveEm@Base
 1.4.1
- - 
_ZNSt6vectorISt5tupleIJjN4gatb4core5tools4math8LargeIntILi2EEEjjjEESaIS7_EE12emplace_backIJS7_EEEvDpOT_@Base
 1.4.1+git20181225.44d5a44+dfsg
+#MISSING: 1.4.1+git20181225.44d5a44+dfsg-2# 
_ZNSt6vectorISt5tupleIJjN4gatb4core5tools4math8LargeIntILi2EEEjjjEESaIS7_EE12emplace_backIJS7_EEEvDpOT_@Base
 1.4.1+git20181225.44d5a44+dfsg
  
_ZNSt6vectorISt5tupleIJjN4gatb4core5tools4math8LargeIntILi2EEEjjjEESaIS7_EE17_M_realloc_insertIJS7_EEEvN9__gnu_cxx17__normal_iteratorIPS7_S9_EEDpOT_@Base
 1.4.1
  
_ZNSt6vectorISt5tupleIJjN4gatb4core5tools4math8LargeIntILi2EEEjjjEESaIS7_EE7reserveEm@Base
 1.4.1
  
_ZNSt6vectorISt5tupleIJjN4gatb4core5tools4math8LargeIntILi3EEEjjjEESaIS7_EE17_M_realloc_insertIJS7_EEEvN9__gnu_cxx17__normal_iteratorIPS7_S9_EEDpOT_@Base
 1.4.1
@@ -9007,7 +9007,7 @@
  
_ZNSt6vectorISt5tupleIJmiEESaIS1_EE17_M_realloc_insertIJS1_EEEvN9__gnu_cxx17__normal_iteratorIPS1_S3_EEDpOT_@Base
 1.4.1
  
_ZNSt6vectorISt5tupleIJmiNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcESaIS7_EE17_M_realloc_insertIJS7_EEEvN9__gnu_cxx17__normal_iteratorIPS7_S9_EEDpOT_@Base
 1.4.1
  
_ZNSt6vectorISt6threadSaIS0_EE17_M_realloc_insertIJZN10ThreadPoolC4EmEUlvE_EEEvN9__gnu_cxx17__normal_iteratorIPS0_S2_EEDpOT_@Base
 1.4.1
- - _ZNSt6vectorIbSaIbEE13_M_initializeEm@Base 1.4.1+git20181225.44d5a44+dfsg
+#MISSING: 1.4.1+git20181225.44d5a44+dfsg-2# 
_ZNSt6vectorIbSaIbEE13_M_initializeEm@Base 1.4.1+git20181225.44d5a44+dfsg
  _ZNSt6vectorIbSaIbEE13_M_insert_auxESt13_Bit_iteratorb@Base 1.4.1
  _ZNSt6vectorIbSaIbEE13_M_reallocateEm@Base 1.4.1
  _ZNSt6vectorIbSaIbEE14_M_fill_insertESt13_Bit_iteratormb@Base 1.4.1
dh_makeshlibs: failing due to earlier errors
make: *** [debian/rules:10: binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit 
status 2

Thanks,

_g.

- -- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAlz/ttsACgkQ7+hsbH/+
z4P/bgf/aI8Kn2N0XrowNHz05+Hw9zTryiLdxmSgqs3HYJwq+bUjzbpZQTbwFb+U
Fgosu7yUAzPQSc0XeWAHbE9zosOVH5pqsvIVCvOOcwIrMJ1w28arh0YtsVTNIs71
4Cn1/x22ZZNHe6rbbb1Kzf0gf1JBMm6riKVqXDh1iJf0S4a1O63w1O6gNXGvXPsj
cwfqbP6En5Wmqys51FH3ZTAWK/ZF/3LPAyGlxgrK7KiFpub1ckph0WiKlaRFOYAv
uzG8Wy7MeVBaG9fpUd/oF+qQiUM+OrHWCXZLLuWKj7UCdCfRgzu3D+t7R5NlTFVr
Rh/mAr/U0rbFG7nDa8g0wOCQNrGBIw==
=2Gnd
-END PGP SIGNATURE-

Bug#923749: Is anybody able to reproduce this issue (help urgently needed) (Was: Potential bug in jh_build (Was: fannj: FTBFS in buster/sid))

[Gilles Filippini]

Hi Andreas,

Le 2019-04-23 15:59, Andreas Tille a écrit :

Hi folks,

may be its a busy time right now but I'd like to salvage fannj and as I
wrote last week I suspect there might be an issue in jh_build that used
to build a proper JAR before but stoped doing so.  Is anybody able to
reproduce that issue or is it just me?


Yes I can reproduce this bug. It is the very same I had for mac-widgets 
[1], and was said to be a Java toolchain bug [2] but not reported 
IFAICT.
You can workaround this by not linking default-jdk-doc during the 
jh_build step. I.e. you can drop the override_jh_build rule.


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919803
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919803#42

Regards,

_g.

Bug#926098: hdf5: JUnit-TestH5P fails on 32 bit architectures

[Gilles Filippini]

Source: hdf5
Version: 1.10.5+repack-1~exp1
Severity: serious
Justification: FTBFS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

HDF5 1.10.5 has just entered Debian experimental and the build logs report 
failures on 32 bit architectures at test JUnit-TestH5P:

java  -Xmx1024M -Dorg.slf4j.simpleLogger.defaultLog=trace 
-Djava.library.path=../../hdf5/lib -cp 
.:../../hdf5/lib/jarhdf5-1.10.5.jar:../../hdf5/lib/junit.jar:../../hdf5/lib/hamcrest-core.jar:../../hdf5/lib/slf4j-api-1.7.25.jar:../../hdf5/lib/slf4j-simple-1.7.25.jar:jarhdf5test.jar:
 -ea org.junit.runner.JUnitCore test.TestH5P
Testing JUnit-TestH5P [main] 
INFO hdf.hdf5lib.H5 - HDF5 library: hdf5_java
[main] INFO hdf.hdf5lib.H5 -  successfully loaded from java.library.path
**FAILED**JUnit-TestH5P
Expected result differs from actual result
*** JUnit-TestH5P.txt   Fri Mar 29 23:46:32 2019
--- JUnit-TestH5P.out   Fri Mar 29 23:46:38 2019
***
*** 47,53 
  .testH5P_sizes
  .testH5Pset_link_creation_order_invalidvalue
  .testH5P_sym_k
! .testH5PH5Pset_shared_mesg_phase_change_MinbtreeGreaterThanMaxlist
  .testH5Pset_scaleoffset_Invalidscale_factor
  .testH5Pget_elink_prefix_null
  .testH5Pget_data_transform_IllegalSize
--- 47,53 
  .testH5P_sizes
  .testH5Pset_link_creation_order_invalidvalue
  .testH5P_sym_k
! E.testH5PH5Pset_shared_mesg_phase_change_MinbtreeGreaterThanMaxlist
  .testH5Pset_scaleoffset_Invalidscale_factor
  .testH5Pget_elink_prefix_null
  .testH5Pget_data_transform_IllegalSize
***
*** 84,89 
  .testH5Pset_attr_creation_order_tracked
  
  Time:  
  
! OK (83 tests)
  
--- 84,131 
  .testH5Pset_attr_creation_order_tracked
  
  Time:  
+ There was 1 failure:
+ 1) testH5P_sym_k(test.TestH5P)
+ java.lang.AssertionError: symbol table tree rank: 0
+   at org.junit.Assert.fail(Assert.java:88)
+   at org.junit.Assert.assertTrue(Assert.java:41)
+   at test.TestH5P.testH5P_sym_k(TestH5P.java:990)
+   at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
+   at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
+   at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
+   at java.base/java.lang.reflect.Method.invoke(Method.java:566)
+   at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
+   at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
+   at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
+   at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
+   at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
+   at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
+   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
+   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
+   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
+   at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
+   at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
+   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
+   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
+   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
+   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
+   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
+   at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
+   at org.junit.runners.Suite.runChild(Suite.java:127)
+   at org.junit.runners.Suite.runChild(Suite.java:26)
+   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
+   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
+   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
+   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
+   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
+   at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
+   at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
+   at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
+   at org.junit.runner.JUnitCore.run(JUnitCore.java:117)
+   at org.junit.runner.JUnitCore.runMain(JUnitCore.java:96)
+   at org.junit.runner.JUnitCore.runMainAndExit(JUnitCore.java:47)
+   at org.junit.runner.JUnitCore.main(JUnitCore.java:40)
  
! FAILURES!!!
! Tests run: 83,  Failures: 1

Full build logs:

Bug#924653: jh_build: wrong path when 'jarfile' argument is given with no path

[Gilles Filippini]

Package: javahelper
Version: 0.72.5
Severity: serious
Justification: make other packages FTBFS

Hi,

Recent uploads of javahelper introduced a jh_build regression regarding
the handling of the 'jarfile' parameter.

See this [1] reproducibility build log for mac-widgets.

[1] 
https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/mac-widgets_0.10.0+svn416-dfsg1-3.rbuild.log.gz

jh_build is called from debian/rules with:
jh_build mac_widgets.jar source demo

And the build fails with:
java.nio.file.NoSuchFileException: /tmp/mac_widgets.jar6488846790867776985.jar 
-> /build/1st/mac-widgets-0.10.0+svn416-dfsg1/mac_widgets.jar/mac_widgets.jar

 ^^^

It seems jh_build computes a wrong path when the 'jarfile' argument is given 
with no path.

Any of these workarounds works, but mac-widgets might not be the only source 
package using jh_build this way:
jh_build ./mac_widgets.jar source demo
jh_build $(CURDIR)/mac_widgets.jar source demo

Thanks,

_g.

-- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages javahelper depends on:
ii  bsdmainutils 11.1.2+b1
ii  dctrl-tools  2.24-3
ii  debhelper12.1.1
ii  devscripts   2.19.3
ii  dpkg-dev 1.19.5
ii  libarchive-zip-perl  1.64-1
ii  perl 5.28.1-4

javahelper recommends no packages.

Versions of packages javahelper suggests:
pn  cvs   
ii  gawk  1:4.2.1+dfsg-1
ii  tofrodos  1.7.13+ds-4

-- no debconf information

Bug#922453: fixed in cernlib 20061220+dfsg3-4.4

[Gilles Filippini]

Hi Andreas,

Andreas Beckmann a écrit le 21/02/2019 à 17:09 :
> if I understand this bug correctly, now paw still needs to be binNMUed
> against the fixed cernlib since it is linked statically.

Yep, I've filed #922484 to binnmu paw, mclibs and geant321.

> Also, does this bug affect stretch, too? (I have no idea how to check this.)

As I understand it, yes it does. I see no reason why it wouldn't.

Thanks,

_g.




signature.asc
Description: OpenPGP digital signature

Bug#922453: cernlib: fortran modules must be compiled with no stronger optimization than -O1 (aka -O)

[Gilles Filippini]

Hi,

On Sat, 16 Feb 2019 10:27:43 +0100 Gilles Filippini  wrote:
> Source: cernlib
> Version: 20061220+dfsg3-4.3
> Severity: grave
> Justification: renders package unusable
> Tags: patch
> 
> 
>  Message transféré 
> Sujet : cernlib (20061220+dfsg3-4.3build1) misbehaves on x86_64
> Date : Mon, 4 Feb 2019 00:52:08 +0100
> De : Jacek M. Holeczek 
> Pour : Matthias Klose , Gilles Filippini 
> 
> Hi,
> I tried to use the cernlib related executables on an Ubuntu 18.04 /
> x86_64 / gcc 7.3.0.
> I have found that the "pawX11" misbehaves.
> The problem is related to the used fortran optimization flag.
> By default it is now "-O3" but this is producing misbehaving libraries.
> I tried to rebuild everything using "-O2" but they still misbehaved.
> Finally, after I switched to "-O" (i.e. "-O1"), they started to behave
> properly.
> Please find attached a small patch file which tries to ensure that the
> fortran source code will be compiled with "-O" (and not "-O3" nor "-O2").

The first hunk of the provided patch should be dropped. It addresses a
temporary Ubuntu fix for #853345 now closed.

Attaching the updated patch.

Thanks,

_g.

diff -Naur 
cernlib-20061220+dfsg3.original/debian/patches/126-fix-patchy-compile-flags.dpatch
 cernlib-20061220+dfsg3/debian/patches/126-fix-patchy-compile-flags.dpatch
--- 
cernlib-20061220+dfsg3.original/debian/patches/126-fix-patchy-compile-flags.dpatch
  2013-08-24 09:16:07.0 +
+++ cernlib-20061220+dfsg3/debian/patches/126-fix-patchy-compile-flags.dpatch   
2019-02-03 21:48:36.151806615 +
@@ -76,7 +76,7 @@
  
 -  PARAMETER   (CHPOF = '-c -O -fno-automatic')
 -  PARAMETER   (CHPOC = '-c -O2 -m486')
-+  PARAMETER   (CHPOF = '-c -g -O2 -fno-automatic')
++  PARAMETER   (CHPOF = '-c -g -O -fno-automatic')
 +  PARAMETER   (CHPOC = '-c -g -O2')
PARAMETER   (CHPOA = ' ')
  
diff -Naur 
cernlib-20061220+dfsg3.original/debian/patches/304-update-Imake-config-files.dpatch
 cernlib-20061220+dfsg3/debian/patches/304-update-Imake-config-files.dpatch
--- 
cernlib-20061220+dfsg3.original/debian/patches/304-update-Imake-config-files.dpatch
 2015-09-09 01:24:30.0 +
+++ cernlib-20061220+dfsg3/debian/patches/304-update-Imake-config-files.dpatch  
2019-02-03 21:47:38.208869466 +
@@ -1794,7 +1794,7 @@
 +
 +#ifdef AMD64Architecture
 +# ifndef OptimizationLevel
-+#  define OptimizationLevel   -O3
++#  define OptimizationLevel   -O
 +# endif
 +# ifndef OptimizedCDebugFlags
 +#  define OptimizedCDebugFlags  OptimizationLevel


signature.asc
Description: OpenPGP digital signature

Bug#922453: Fwd: cernlib (20061220+dfsg3-4.3build1) misbehaves on x86_64

[Gilles Filippini]

 Message transféré 
Sujet : Re: cernlib (20061220+dfsg3-4.3build1) misbehaves on x86_64
Date : Wed, 13 Feb 2019 09:58:12 +0100
De : Jacek M. Holeczek 
Pour : Matthias Klose , Gilles Filippini 

Dear Sirs,
these are very old problems which nobody cares about.
There is a bug report from 2014:

https://bugs.launchpad.net/ubuntu/+source/paw/+bug/1354692

I myself was notified about these problems (by my colleague) in 2017.
In that time, I found that your cernlib was broken on "Ubuntu 16.04 /
x86_64 " and "Ubuntu 16.10 / x86_64". However, the forthcoming (in that
time) "Ubuntu 17.10 / x86_64" seemed to be free from these problems. So
I started to advice people to move to this newer distribution (in "beta"
in that time), even though, I myself use the "monolithic" CERNLIB 2005
distribution.
It turns out, however, that I was wrong and these problems are still
there in "Ubuntu 18.04 / x86_64".

In general, the current status (for your cernlib compiled with "-O3" or
"-O2") is that there are severe problems with "ntuples". One cannot
properly create "ntuples", neither "memory resident" nor "disk
resident", in paw. In both cases, only the first variable has proper
values, the remaining variables are always set to 0 (well, usually,
sometimes another value appears).
Old "disk resident ntuples" (created with another properly working
cernlib versions) are sometimes retrieved properly, but sometimes also
this fails (that's what the old bug report from 2014 is talking about).

So, I tried to leave your "cernlib-20061220" libraries compiled with the
default "-O3" and rebuild your "paw-2.14.04" with "-O0" but it did not
help (i.e. the problems really originate in the "cernlib-20061220"
package, not in "paw-2.14.04").

Note that the original cernlib was always built with "-O". More
aggressive compiler optimizations were known to break it.

You can find my instructions here:

https://www-zeuthen.desy.de/linear_collider/cernlib/new/cernlib_2005.html

Last, but not least. It seems I cannot file a bug report "anonymously".
Your bug reporting system tries to force me to create and register a new
account in order to file a bug report. I'm sick of such behavior. I
already have tens of account somewhere there. I won't create another one
just for a simple bug report (when nobody cares about 5 years old bugs
anyhow).

Best regards,
Jacek.




signature.asc
Description: OpenPGP digital signature

Bug#922453: cernlib: fortran modules must be compiled with no stronger optimization than -O1 (aka -O)

[Gilles Filippini]

Source: cernlib
Version: 20061220+dfsg3-4.3
Severity: grave
Justification: renders package unusable
Tags: patch


 Message transféré 
Sujet : cernlib (20061220+dfsg3-4.3build1) misbehaves on x86_64
Date : Mon, 4 Feb 2019 00:52:08 +0100
De : Jacek M. Holeczek 
Pour : Matthias Klose , Gilles Filippini 

Hi,
I tried to use the cernlib related executables on an Ubuntu 18.04 /
x86_64 / gcc 7.3.0.
I have found that the "pawX11" misbehaves.
The problem is related to the used fortran optimization flag.
By default it is now "-O3" but this is producing misbehaving libraries.
I tried to rebuild everything using "-O2" but they still misbehaved.
Finally, after I switched to "-O" (i.e. "-O1"), they started to behave
properly.
Please find attached a small patch file which tries to ensure that the
fortran source code will be compiled with "-O" (and not "-O3" nor "-O2").
Hope it helps,
Best regards,
Jacek.

diff -Naur 
cernlib-20061220+dfsg3.original/debian/patches/102-dont-optimize-some-code.dpatch
 cernlib-20061220+dfsg3/debian/patches/102-dont-optimize-some-code.dpatch
--- 
cernlib-20061220+dfsg3.original/debian/patches/102-dont-optimize-some-code.dpatch
   2017-08-06 19:23:39.0 +
+++ cernlib-20061220+dfsg3/debian/patches/102-dont-optimize-some-code.dpatch
2019-02-03 21:49:52.638404057 +
@@ -20,7 +20,7 @@
 +#endif
 +
 +/* GCC 7 on 64bit targets, see https://gcc.gnu.org/PR81723 */
-+SpecialFortranLibObjectRule(cwerf64,cwerf64,-O2,NullParameter)
++SpecialFortranLibObjectRule(cwerf64,cwerf64,-O,NullParameter)
 diff -urNad cernlib-2006.dfsg.2~/src/mathlib/gen/d/Imakefile 
cernlib-2006.dfsg.2/src/mathlib/gen/d/Imakefile
 --- cernlib-2006.dfsg.2~/src/mathlib/gen/d/Imakefile   1996-06-12 
08:25:38.0 -0700
 +++ cernlib-2006.dfsg.2/src/mathlib/gen/d/Imakefile2008-02-22 
12:06:26.0 -0800
diff -Naur 
cernlib-20061220+dfsg3.original/debian/patches/126-fix-patchy-compile-flags.dpatch
 cernlib-20061220+dfsg3/debian/patches/126-fix-patchy-compile-flags.dpatch
--- 
cernlib-20061220+dfsg3.original/debian/patches/126-fix-patchy-compile-flags.dpatch
  2013-08-24 09:16:07.0 +
+++ cernlib-20061220+dfsg3/debian/patches/126-fix-patchy-compile-flags.dpatch   
2019-02-03 21:48:36.151806615 +
@@ -76,7 +76,7 @@
  
 -  PARAMETER   (CHPOF = '-c -O -fno-automatic')
 -  PARAMETER   (CHPOC = '-c -O2 -m486')
-+  PARAMETER   (CHPOF = '-c -g -O2 -fno-automatic')
++  PARAMETER   (CHPOF = '-c -g -O -fno-automatic')
 +  PARAMETER   (CHPOC = '-c -g -O2')
PARAMETER   (CHPOA = ' ')
  
diff -Naur 
cernlib-20061220+dfsg3.original/debian/patches/304-update-Imake-config-files.dpatch
 cernlib-20061220+dfsg3/debian/patches/304-update-Imake-config-files.dpatch
--- 
cernlib-20061220+dfsg3.original/debian/patches/304-update-Imake-config-files.dpatch
 2015-09-09 01:24:30.0 +
+++ cernlib-20061220+dfsg3/debian/patches/304-update-Imake-config-files.dpatch  
2019-02-03 21:47:38.208869466 +
@@ -1794,7 +1794,7 @@
 +
 +#ifdef AMD64Architecture
 +# ifndef OptimizationLevel
-+#  define OptimizationLevel   -O3
++#  define OptimizationLevel   -O
 +# endif
 +# ifndef OptimizedCDebugFlags
 +#  define OptimizedCDebugFlags  OptimizationLevel


signature.asc
Description: OpenPGP digital signature

Bug#919802: libjstun-java: FTBFS (The code being documented uses packages in the unnamed module)

[Gilles Filippini]

Santiago Vila a écrit le 29/01/2019 à 22:55 :
> On Tue, Jan 29, 2019 at 09:44:40PM +0100, Gilles Filippini wrote:
> 
>> Looking at the jh_build code, the list of -link javadoc options is 
>> constructed from this snippet:
>>CLASSPATHDOCS="`for i in $(grep-dctrl --no-field-names --show-field 
>> Build-Depends,Build-Depends-Indep -F source "$pkg" debian/control | tr , ' ' 
>> | sed 's/([^)]*)//g') ; do dpkg -L $i 2>/dev/null | grep 
>> /usr/share/doc/.*/api$; done | sed 's/^/-link /' | xargs`"
>>
>> Then dropping default-jdk-doc from Build-Depends did the trick!
> 
> Please note that if the package does not build when default-jdk-doc is
> present, then (imo) you should probably use build-conflicts against it and
> any similar package which we know makes the package to FTBFS, not just
> remove it from build-depends.
> 
> (At least this is what build-conflicts was invented for).

No, this is a misunderstanding: the code snippet above scans
Build-Depends* fields from debian/control. If default-jdk-doc is
installed but not referenced in Build-Depends*, then the package will
build fine. I've tested this configuration.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#919802: libjstun-java: FTBFS (The code being documented uses packages in the unnamed module)

[Gilles Filippini]

Hi,

Gilles Filippini a écrit le 21/01/2019 à 16:58 :
> Hi,
> 
> On Sun, 20 Jan 2019 13:28:57 +0800 "Ying-Chun Liu (PaulLiu)"
>  wrote:
>> Santiago Vila 於 2019/1/20 上午1:35 寫道:
>>> Package: src:libjstun-java
>>> Version: 0.7.3+dfsg-1
>>> Severity: serious
>>> Tags: ftbfs
>>>
>>> Dear maintainer:
>>>
>>> I tried to build this package in buster but it failed:
>>>
>>> 
>>> [...]
>>>  debian/rules build-indep
>>> dh build-indep --with javahelper
>>>dh_update_autotools_config -i
>>>jh_linkjars -i
>>>jh_build -i
>>> find src/de -name *.java -and -type f -print0 | xargs -s 512000 -0 
>>> /usr/lib/jvm/default-java/bin/javac -g -cp 
>>> /usr/share/java/slf4j-jdk14.jar:/usr/share/java/slf4j-api.jar:/usr/share/java/junit.jar:debian/_jh_build.libjstun-java
>>>  -d debian/_jh_build.libjstun-java -source 1.7 -target 1.7 -encoding 
>>> ISO8859-1
>>> warning: [options] bootstrap class path not set in conjunction with -source 
>>> 7
>>> Note: src/de/javawi/jstun/test/demo/ice/ICENegociator.java uses unchecked 
>>> or unsafe operations.
>>> Note: Recompile with -Xlint:unchecked for details.
>>> 1 warning
>>> find src/de -name *.java -and -type f -print0 | xargs -s 512000 -0 
>>> /usr/lib/jvm/default-java/bin/javadoc -locale en_US -link 
>>> /usr/share/doc/default-jdk-doc/api -link 
>>> /usr/share/doc/default-jre-headless/api -classpath 
>>> /usr/share/java/slf4j-jdk14.jar:/usr/share/java/slf4j-api.jar:/usr/share/java/junit.jar:debian/_jh_build.libjstun-java
>>>  -d debian/_jh_build.javadoc/api -quiet -encoding ISO8859-1 -notimestamp 
>>> -source 1.7
>>> Creating destination directory: "debian/_jh_build.javadoc/api/"
>>> javadoc: error - The code being documented uses packages in the unnamed 
>>> module, but the packages defined in /usr/share/doc/default-jdk-doc/api/ are 
>>> in named modules.
>>> javadoc: error - The code being documented uses packages in the unnamed 
>>> module, but the packages defined in 
>>> /usr/share/doc/default-jre-headless/api/ are in named modules.
>>> 2 errors
>>> make: *** [debian/rules:11: build-indep] Error 123
>>> dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
>>> status 2
>>> 
>>>
>>> (The above is just how the builds ends and not necessarily the most 
>>> relevant part)
>>>
>>> The build was made in my autobuilder with "dpkg-buildpackage -A"
>>> and it also fails here:
>>>
>>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libjstun-java.html
>>>
>>> where you can get a full build log if you need it.
>>>
>>> If this is really a bug in one of the build-depends, please use reassign 
>>> and affects,
>>> so that this is still visible in the BTS web page for this package.
>>>
>>> Thanks.
>>>
>>
>> Hi Santiago,
>>
>> It seems to me that this line causes the problem.
>> find src/de -name *.java -and -type f -print0 | xargs -s 512000 -0
>> /usr/lib/jvm/default-java/bin/javadoc -locale en_US -link
>> /usr/share/doc/default-jdk-doc/api -link
>> /usr/share/doc/default-jre-headless/api -classpath
>> /usr/share/java/slf4j-jdk14.jar:/usr/share/java/slf4j-api.jar:/usr/share/java/junit.jar:debian/_jh_build.libjstun-java
>> -d debian/_jh_build.javadoc/api -quiet -encoding ISO8859-1 -notimestamp
>> -source 1.7
>>
>> But if remove "-link /usr/share/doc/default-jdk-doc/api -link
>> /usr/share/doc/default-jre-headless/api", then it will pass.
>>
>> I'm wondering if javahelper needs to call javadoc in different way.
> 
> I've got the very same result for #919803 affecting src:mac-widgets.

Looking at the jh_build code, the list of -link javadoc options is constructed 
from this snippet:
   CLASSPATHDOCS="`for i in $(grep-dctrl --no-field-names --show-field 
Build-Depends,Build-Depends-Indep -F source "$pkg" debian/control | tr , ' ' | 
sed 's/([^)]*)//g') ; do dpkg -L $i 2>/dev/null | grep /usr/share/doc/.*/api$; 
done | sed 's/^/-link /' | xargs`"

Then dropping default-jdk-doc from Build-Depends did the trick!

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#919802: Fwd: Re: Bug#919802: libjstun-java: FTBFS (The code being documented uses packages in the unnamed module)

[Gilles Filippini]

Hi Emmanuel, Niels,

Any input on this topic?

Thanks in advance,

_g.

 Message transféré 
Sujet : Re: Bug#919802: libjstun-java: FTBFS (The code being documented
uses packages in the unnamed module)
Date : Mon, 21 Jan 2019 16:58:08 +0100
De : Gilles Filippini 
Pour : 919...@bugs.debian.org, Ying-Chun Liu (PaulLiu)
, Santiago Vila 

Hi,

On Sun, 20 Jan 2019 13:28:57 +0800 "Ying-Chun Liu (PaulLiu)"
 wrote:
> Santiago Vila 於 2019/1/20 上午1:35 寫道:
> > Package: src:libjstun-java
> > Version: 0.7.3+dfsg-1
> > Severity: serious
> > Tags: ftbfs
> > 
> > Dear maintainer:
> > 
> > I tried to build this package in buster but it failed:
> > 
> > 
> > [...]
> >  debian/rules build-indep
> > dh build-indep --with javahelper
> >dh_update_autotools_config -i
> >jh_linkjars -i
> >jh_build -i
> > find src/de -name *.java -and -type f -print0 | xargs -s 512000 -0 
> > /usr/lib/jvm/default-java/bin/javac -g -cp 
> > /usr/share/java/slf4j-jdk14.jar:/usr/share/java/slf4j-api.jar:/usr/share/java/junit.jar:debian/_jh_build.libjstun-java
> >  -d debian/_jh_build.libjstun-java -source 1.7 -target 1.7 -encoding 
> > ISO8859-1
> > warning: [options] bootstrap class path not set in conjunction with -source 
> > 7
> > Note: src/de/javawi/jstun/test/demo/ice/ICENegociator.java uses unchecked 
> > or unsafe operations.
> > Note: Recompile with -Xlint:unchecked for details.
> > 1 warning
> > find src/de -name *.java -and -type f -print0 | xargs -s 512000 -0 
> > /usr/lib/jvm/default-java/bin/javadoc -locale en_US -link 
> > /usr/share/doc/default-jdk-doc/api -link 
> > /usr/share/doc/default-jre-headless/api -classpath 
> > /usr/share/java/slf4j-jdk14.jar:/usr/share/java/slf4j-api.jar:/usr/share/java/junit.jar:debian/_jh_build.libjstun-java
> >  -d debian/_jh_build.javadoc/api -quiet -encoding ISO8859-1 -notimestamp 
> > -source 1.7
> > Creating destination directory: "debian/_jh_build.javadoc/api/"
> > javadoc: error - The code being documented uses packages in the unnamed 
> > module, but the packages defined in /usr/share/doc/default-jdk-doc/api/ are 
> > in named modules.
> > javadoc: error - The code being documented uses packages in the unnamed 
> > module, but the packages defined in 
> > /usr/share/doc/default-jre-headless/api/ are in named modules.
> > 2 errors
> > make: *** [debian/rules:11: build-indep] Error 123
> > dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
> > status 2
> > 
> > 
> > (The above is just how the builds ends and not necessarily the most 
> > relevant part)
> > 
> > The build was made in my autobuilder with "dpkg-buildpackage -A"
> > and it also fails here:
> > 
> > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libjstun-java.html
> > 
> > where you can get a full build log if you need it.
> > 
> > If this is really a bug in one of the build-depends, please use reassign 
> > and affects,
> > so that this is still visible in the BTS web page for this package.
> > 
> > Thanks.
> > 
> 
> Hi Santiago,
> 
> It seems to me that this line causes the problem.
> find src/de -name *.java -and -type f -print0 | xargs -s 512000 -0
> /usr/lib/jvm/default-java/bin/javadoc -locale en_US -link
> /usr/share/doc/default-jdk-doc/api -link
> /usr/share/doc/default-jre-headless/api -classpath
> /usr/share/java/slf4j-jdk14.jar:/usr/share/java/slf4j-api.jar:/usr/share/java/junit.jar:debian/_jh_build.libjstun-java
> -d debian/_jh_build.javadoc/api -quiet -encoding ISO8859-1 -notimestamp
> -source 1.7
> 
> But if remove "-link /usr/share/doc/default-jdk-doc/api -link
> /usr/share/doc/default-jre-headless/api", then it will pass.
> 
> I'm wondering if javahelper needs to call javadoc in different way.

I've got the very same result for #919803 affecting src:mac-widgets.

Thanks,

_g.





signature.asc
Description: OpenPGP digital signature

Bug#919802: libjstun-java: FTBFS (The code being documented uses packages in the unnamed module)

[Gilles Filippini]

Hi,

On Sun, 20 Jan 2019 13:28:57 +0800 "Ying-Chun Liu (PaulLiu)"
 wrote:
> Santiago Vila 於 2019/1/20 上午1:35 寫道:
> > Package: src:libjstun-java
> > Version: 0.7.3+dfsg-1
> > Severity: serious
> > Tags: ftbfs
> > 
> > Dear maintainer:
> > 
> > I tried to build this package in buster but it failed:
> > 
> > 
> > [...]
> >  debian/rules build-indep
> > dh build-indep --with javahelper
> >dh_update_autotools_config -i
> >jh_linkjars -i
> >jh_build -i
> > find src/de -name *.java -and -type f -print0 | xargs -s 512000 -0 
> > /usr/lib/jvm/default-java/bin/javac -g -cp 
> > /usr/share/java/slf4j-jdk14.jar:/usr/share/java/slf4j-api.jar:/usr/share/java/junit.jar:debian/_jh_build.libjstun-java
> >  -d debian/_jh_build.libjstun-java -source 1.7 -target 1.7 -encoding 
> > ISO8859-1
> > warning: [options] bootstrap class path not set in conjunction with -source 
> > 7
> > Note: src/de/javawi/jstun/test/demo/ice/ICENegociator.java uses unchecked 
> > or unsafe operations.
> > Note: Recompile with -Xlint:unchecked for details.
> > 1 warning
> > find src/de -name *.java -and -type f -print0 | xargs -s 512000 -0 
> > /usr/lib/jvm/default-java/bin/javadoc -locale en_US -link 
> > /usr/share/doc/default-jdk-doc/api -link 
> > /usr/share/doc/default-jre-headless/api -classpath 
> > /usr/share/java/slf4j-jdk14.jar:/usr/share/java/slf4j-api.jar:/usr/share/java/junit.jar:debian/_jh_build.libjstun-java
> >  -d debian/_jh_build.javadoc/api -quiet -encoding ISO8859-1 -notimestamp 
> > -source 1.7
> > Creating destination directory: "debian/_jh_build.javadoc/api/"
> > javadoc: error - The code being documented uses packages in the unnamed 
> > module, but the packages defined in /usr/share/doc/default-jdk-doc/api/ are 
> > in named modules.
> > javadoc: error - The code being documented uses packages in the unnamed 
> > module, but the packages defined in 
> > /usr/share/doc/default-jre-headless/api/ are in named modules.
> > 2 errors
> > make: *** [debian/rules:11: build-indep] Error 123
> > dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
> > status 2
> > 
> > 
> > (The above is just how the builds ends and not necessarily the most 
> > relevant part)
> > 
> > The build was made in my autobuilder with "dpkg-buildpackage -A"
> > and it also fails here:
> > 
> > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libjstun-java.html
> > 
> > where you can get a full build log if you need it.
> > 
> > If this is really a bug in one of the build-depends, please use reassign 
> > and affects,
> > so that this is still visible in the BTS web page for this package.
> > 
> > Thanks.
> > 
> 
> Hi Santiago,
> 
> It seems to me that this line causes the problem.
> find src/de -name *.java -and -type f -print0 | xargs -s 512000 -0
> /usr/lib/jvm/default-java/bin/javadoc -locale en_US -link
> /usr/share/doc/default-jdk-doc/api -link
> /usr/share/doc/default-jre-headless/api -classpath
> /usr/share/java/slf4j-jdk14.jar:/usr/share/java/slf4j-api.jar:/usr/share/java/junit.jar:debian/_jh_build.libjstun-java
> -d debian/_jh_build.javadoc/api -quiet -encoding ISO8859-1 -notimestamp
> -source 1.7
> 
> But if remove "-link /usr/share/doc/default-jdk-doc/api -link
> /usr/share/doc/default-jre-headless/api", then it will pass.
> 
> I'm wondering if javahelper needs to call javadoc in different way.

I've got the very same result for #919803 affecting src:mac-widgets.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#917788: libmedc11: Overwrites a file from libmedc1v5

[Gilles Filippini]

On Sat, 5 Jan 2019 22:11:44 +0100 pini  wrote:
> On Sat, 5 Jan 2019 21:53:13 +0100 Gilles Filippini  wrote:
> Oh, looking at cruft-report [1] I see that syrthes-tools still dépends on 
> libmedc1v5, preventing the removal :
> * source package med-fichier version 4.0.0+repack-6 no longer builds
>   binary package(s): libmed1v5 libmedc1v5
>   on amd64,arm64,armel,armhf,hurd-i386,i386,mips,mips64el,mipsel,ppc64el,s390x
>   - suggested command:
> dak rm -m "[auto-cruft] NBS (no longer built by med-fichier)" -s unstable 
> -a amd64,arm64,armel,armhf,hurd-i386,i386,mips,mips64el,mipsel,ppc64el,s390x 
> -p -R -b libmed1v5 libmedc1v5
>   - broken Depends:
> syrthes: syrthes-tools [amd64 arm64 armel armhf hurd-i386 i386 mips 
> mips64el mipsel ppc64el]
> 
> [1] http://ftp-master.debian.org/cruft-report-daily.txt
> 
> I'm going to fix that.

I've uploaded a new release of the syrthes package. There shouldn't be
any blocker left for these cruft packages removal.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#917788: libmedc11: Overwrites a file from libmedc1v5

[Gilles Filippini]

On Sat, 5 Jan 2019 17:23:11 +0100 Mattia Rizzolo  wrote:
> Control: reopen -1
> 
> On Wed, Jan 02, 2019 at 12:45:08AM +0100, Andreas Beckmann wrote:
> > On Sun, 30 Dec 2018 09:21:03 -0600 Kurt Kremitzki  wrote:
> > > I was just about to open a bug on this same issue. It's actually present
> > > in both libmed11 and libmedc11. Instead of Conflicts, they both need
> > > Breaks + Replaces, see Policy 7.6 [1] or #906110 [2] for a similar
> > 
> > In this special case, you probably need to add
> >   Breaks+Replaces: libmed1v5 (>= 4)
> > respectively
> >   Breaks+Replaces: libmedc1v5 (>= 4)
> > since the versions before 4 should not have any file conflicts.
> 
> Actually, I think Breaks+Replaces is wrong here.
> 
> Breaks+Replaces allow for silent replacing of the old package, but here
> you need to forcefully remove it, which is what you'd use Conflicts for.
> As a data point, that what we usually use when renaming packages during
> ABI breaks like what has been done for #916881.

I agree that Conflicts suits better regarding the need to forcibly
remove libmed1v5 / libmedc1v5 (= 4.0.0+repack-1).

> Incidentally, I think that would also cover the just openend #918372,
> as with a Conflicts the libgmsh3 package from testing woudln't be
> installable, so it would force an upgrade to the version in unstable,
> making the test pass.

Here I'm not sure. I think the problem is that libmed1v5 and libmedc1v5
from the broken med-fichier 4.0.0+repack-1 are still present into
unstable. Is there a way to have them removed?

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#918157: pmix (was: openmpi) seems broken on 32 bits architectures

[Gilles Filippini]

Control: reassign -1 libpmix2 3.1.0~rc2-1
Control: retitle -1 libpmix2 seems broken on 32 bits architectures

On 2019-01-04 09:41, Graham Inggs wrote:

Control: user debian...@lists.debian.org
Control: usertag -1 regression

Hi

In Ubuntu, the upload of openmpi 3.1.3-7 has caused numerous
autopkgtest failures on i386 and armhf [1].  Some affected packages
are: combblas; dune-grid, lammps, liggghts, petsc, ray and
superlu-dist.

I re-tried these tests after the upload of pmix 3.1.0~rc2-2 but the
failures persisted, e.g. combblas [2],


I tried a build against openmpi 3.1.3-6 and experienced the very same 
FTBFS. Then I downgraded libpmix2 to 3.0.2-2 and it worked. It worked 
against openmpi 3.1.3-7 as well.

The culprit is then pmix 3.1.0~rc2.

Thanks,

_g.

Bug#918157: openmpi seems broken on 32 bits architectures

[Gilles Filippini]

Source: openmpi
Version: 3.1.3-7
Severity: grave
Justification: renders package unusable on 32 bits architectures

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

The last med-fichier upload FTBFS on 32 bits architectures[1] with this error:

Launching filterBlockOfentities with 2 processes
- --
At least one pair of MPI processes are unable to reach each other for
MPI communications.  This means that no Open MPI device has indicated
that it can be used to communicate between these processes.  This is
an error; Open MPI requires that all MPI processes be able to reach
each other.  This error can sometimes be the result of forgetting to
specify the "self" BTL.

  Process 1 ([[5346,1],1]) is on host: x86-grnet-01
  Process 2 ([[5346,1],0]) is on host: x86-grnet-01
  BTLs attempted: vader tcp self

Your MPI job is now going to abort; sorry.
- --
- --
MPI_INIT has failed because at least one MPI process is unreachable
from another.  This *usually* means that an underlying communication
plugin -- such as a BTL or an MTL -- has either not loaded or not
allowed itself to be used.  Your MPI job will now abort.

You may wish to try to narrow down the problem;

 * Check the output of ompi_info to see which BTL/MTL plugins are
   available.
 * Run your application with MPI_THREAD_SINGLE.
 * Set the MCA parameter btl_base_verbose to 100 (or mtl_base_verbose,
   if using MTL-based communications) to see exactly which
   communication plugins were considered and/or discarded.
- --
[x86-grnet-01:30926] *** An error occurred in MPI_Init
[x86-grnet-01:30926] *** reported by process [350355457,1]
[x86-grnet-01:30926] *** on a NULL communicator
[x86-grnet-01:30926] *** Unknown error
[x86-grnet-01:30926] *** MPI_ERRORS_ARE_FATAL (processes in this communicator 
will now abort,
[x86-grnet-01:30926] ***and potentially your MPI job)
Can't launch filterBlockOfentities with 2 processes
FAIL: filterBlockOfentities.sh

[1] 
https://buildd.debian.org/status/fetch.php?pkg=med-fichier=i386=4.0.0%2Brepack-5=1546462702=0

The changes from the previous upload (4.0.0+repack-3) which built fine can't
be related to this issue:
   * Drop debian/source/lintian-overrides; these lintian tags were removed
 in 2012
   * libmedc?11: Breaks / Replaces libmedc?1v5 (= 4.0.0+repack-1)
 (Closes: #917788)

I suspect this is related to the recent upload of openmpi 3.1.3-7.

Thanks,

_g.

- -- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAlwuf9sACgkQ7+hsbH/+
z4PMRwgArkC6kXa7ZFOQnthw6TZCen5UZInSpOyWIY2B4ywT7sSD6RSn2JNsolG9
QP6L6+rgnakiPHcY2OcwKvjWZ5tSnmbhXbFN5p5JcgKI2xrM+BwpDYwlD1FOyOpx
1FlXJPdiUz1vrr8ybbjmwNIjHWux7KTCN2i17oa7VWNsOVehAhgWisgLmt9+IqiQ
biAfr5Qw9/OMh3C3uJqtQesXzWLOrLGQN6u8pMFn61W1LLMl54lA4QfWrUHVZexh
8K4hN5MwzHmCRQF2OApkXMBcVrt+Ppzo4jZEavetII6ZtLMcchUQbavF0ZjdOl3l
E+lI0uLXSBOKRtw+0TaQI3S3nslLUA==
=KpJH
-END PGP SIGNATURE-

Bug#916971: gmsh: diff for NMU version 3.0.6+dfsg1-4.1

[Gilles Filippini]

Control: tags 916971 + pending

Dear maintainer,

I've prepared an NMU for gmsh (versioned as 3.0.6+dfsg1-4.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards,

_g.


diff -Nru gmsh-3.0.6+dfsg1/debian/changelog gmsh-3.0.6+dfsg1/debian/changelog
--- gmsh-3.0.6+dfsg1/debian/changelog   2018-12-03 01:47:52.0 +0100
+++ gmsh-3.0.6+dfsg1/debian/changelog   2018-12-30 10:09:26.0 +0100
@@ -1,3 +1,11 @@
+gmsh (3.0.6+dfsg1-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * New patch support-med-4.patch to fix FTBFS against med-fichier 4.0.0
+(Closes: #916971)
+
+ -- Gilles Filippini   Sun, 30 Dec 2018 10:09:26 +0100
+
 gmsh (3.0.6+dfsg1-4) unstable; urgency=medium
[ Joost van Zwieten ]
diff -Nru gmsh-3.0.6+dfsg1/debian/patches/series 
gmsh-3.0.6+dfsg1/debian/patches/series
--- gmsh-3.0.6+dfsg1/debian/patches/series  2018-12-03 01:47:52.0 
+0100
+++ gmsh-3.0.6+dfsg1/debian/patches/series  2018-12-24 09:28:43.0 
+0100
@@ -3,3 +3,4 @@
 30_delete_gl2ps_from_source.patch
 40_gnuinstalldirs.patch
 140_drop_css.patch
+support-med-4.patch
diff -Nru gmsh-3.0.6+dfsg1/debian/patches/support-med-4.patch 
gmsh-3.0.6+dfsg1/debian/patches/support-med-4.patch
--- gmsh-3.0.6+dfsg1/debian/patches/support-med-4.patch 1970-01-01 
01:00:00.0 +0100
+++ gmsh-3.0.6+dfsg1/debian/patches/support-med-4.patch 2018-12-24 
09:28:43.0 +0100
@@ -0,0 +1,386 @@
+Index: gmsh-3.0.6+dfsg1/Geo/GModelIO_MED.cpp
+===
+--- gmsh-3.0.6+dfsg1.orig/Geo/GModelIO_MED.cpp
 gmsh-3.0.6+dfsg1/Geo/GModelIO_MED.cpp
+@@ -29,7 +29,7 @@ extern "C" {
+ #include 
+ }
+ +-#if (MED_MAJOR_NUM == 3)
++#if (MED_MAJOR_NUM >= 3)
+ // To avoid too many ifdefs below we use defines for the bits of the
+ // API that did not change too much between MED2 and MED3. If we remove
+ // MED2 support at some point, please remove these defines and replace
+@@ -69,7 +69,7 @@ med_geometrie_element msh2medElementType
+   case MSH_HEX_20: return MED_HEXA20;
+   case MSH_PRI_15: return MED_PENTA15;
+   case MSH_PYR_13: return MED_PYRA13;
+-#if (MED_MAJOR_NUM == 3)
++#if (MED_MAJOR_NUM >= 3)
+   case MSH_QUA_9: return MED_QUAD9;
+   case MSH_HEX_27: return MED_HEXA27;
+ #endif
+@@ -95,7 +95,7 @@ int med2mshElementType(med_geometrie_ele
+   case MED_HEXA20: return MSH_HEX_20;
+   case MED_PENTA15: return MSH_PRI_15;
+   case MED_PYRA13: return MSH_PYR_13;
+-#if (MED_MAJOR_NUM == 3)
++#if (MED_MAJOR_NUM >= 3)
+   case MED_QUAD9: return MSH_QUA_9;
+   case MED_HEXA27: return MSH_HEX_27;
+ #endif
+@@ -113,7 +113,7 @@ int med2mshNodeIndex(med_geometrie_eleme
+   case MED_TRIA6:
+   case MED_QUAD4:
+   case MED_QUAD8:
+-#if (MED_MAJOR_NUM == 3)
++#if (MED_MAJOR_NUM >= 3)
+   case MED_QUAD9:
+ #endif
+ return k; // same node numbering as in Gmsh
+@@ -133,7 +133,7 @@ int med2mshNodeIndex(med_geometrie_eleme
+ static const int map[20] = 
{0,1,3,2,4,5,6,7,8,9,10,11,16,17,18,19,12,13,14,15};
+ return map[k];
+   }
+-#if (MED_MAJOR_NUM == 3)
++#if (MED_MAJOR_NUM >= 3)
+   case MED_HEXA27: {
+ static const int map[27] = 
{0,1,3,2,4,5,6,7,8,9,10,11,16,17,18,19,12,13,14,15,
+ 20, 22, 21, 23, 24, 25, 26};
+@@ -185,7 +185,7 @@ int GModel::readMED(const std::string 
+ char meshName[MED_TAILLE_NOM + 1], meshDesc[MED_TAILLE_DESC + 1];
+ med_int spaceDim;
+ med_maillage meshType;
+-#if (MED_MAJOR_NUM == 3)
++#if (MED_MAJOR_NUM >= 3)
+ med_int meshDim, nStep;
+ char dtUnit[MED_SNAME_SIZE + 1];
+ char axisName[3 * MED_SNAME_SIZE + 1], axisUnit[3 * MED_SNAME_SIZE + 1];
+@@ -241,7 +241,7 @@ int GModel::readMED(const std::string 
+   char meshName[MED_TAILLE_NOM + 1], meshDesc[MED_TAILLE_DESC + 1];
+   med_int spaceDim, nStep = 1;
+   med_maillage meshType;
+-#if (MED_MAJOR_NUM == 3)
++#if (MED_MAJOR_NUM >= 3)
+   med_int meshDim;
+   char dtUnit[MED_SNAME_SIZE + 1];
+   char axisName[3 * MED_SNAME_SIZE + 1], axisUnit[3 * MED_SNAME_SIZE + 1];
+@@ -276,7 +276,7 @@ int GModel::readMED(const std::string 
+   MEDversionLire(fid, [0], [1], [2]);
+ +   // read nodes
+-#if (MED_MAJOR_NUM == 3)
++#if (MED_MAJOR_NUM >= 3)
+   med_bool changeOfCoord, geoTransform;
+   med_int numNodes = MEDmeshnEntity(fid, meshName, MED_NO_DT, MED_NO_IT, 
MED_NODE,
+ MED_NO_GEOTYPE, MED_COORDINATE, 
MED_NO_CMODE,
+@@ -295,7 +295,7 @@ int GModel::readMED(const std::string 
+   }
+   std::vector verts(numNodes);
+   std::vector coord(spaceDim * numNodes);
+-#if (MED_MAJOR_NUM == 3)
++#if (MED_MAJOR_NUM >= 3)
+   if(MEDmeshNodeCoordinateRd(fid, meshName, MED_NO_DT, MED_NO_IT, 
MED_FULL_INTERLACE,
+  [0]) < 0){
+ #else
+@@ -310,7 +310,7 @@ int GModel::readMED(const std::string 
+   }
+ +   std::vector nodeTags(numNodes);
+-#if (MED_MAJOR_NUM == 3)
++#if (MED_MAJOR_NUM >= 3)
+   if(MED

Bug#917380: libmed1v5: libmed.so.1 link is not created

[Gilles Filippini]

Control: reassign -1 src:gmsh
Control: forcemerge 916971 -1

Hi,

On Wed, 26 Dec 2018 23:24:23 +0100 Stephane Del Pino
 wrote:
> Package: libmed1v5
> Version: 4.0.0+repack-1
> Severity: grave
> Justification: renders package unusable
> 
> The link /usr/lib/libmed.so.1 is no more created which breaks for instance 
> the gmsh package since the libgmsh depends on libmed1v5:
> 
> Package: libgmsh3
> Source: gmsh
> Version: 3.0.6+dfsg1-4
> Installed-Size: 18643
> Maintainer: Debian Science Maintainers 
> 
> Architecture: amd64
> Depends: libann0, libblas3 | libblas.so.3, libc6 (>= 2.14), libcgns3.3 (>= 
> 3.1.4.2), libfltk-gl1.3 (>= 1.3.0), libfltk-images1.3, libfltk1.3 (>= 1.3.4), 
> libgcc1 (>= 1:4.0), libgl1, libgl2ps1.4, libglu1-mesa | libglu1, 
> libjpeg62-turbo (>= 1.3.1), liblapack3 | liblapack.so.3, libmed1v5, 
> libocct-data-exchange-7.3, libocct-foundation-7.3, 
> libocct-modeling-algorithms-7.3, libocct-modeling-data-7.3, libopenmpi3, 
> libpng16-16 (>= 1.6.2-1), libstdc++6 (>= 5.2), libtet1.5, libx11-6

This is a consequence of #916881 now closed by the upload of version
4.0.0+repack-2~exp1.
Now gmsh has to be rebuilt against med-fichier 4.0.0, which is currently
impossible because of #916971.
I'm thus merging this bug with #916971.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#916971: gmsh: FTBFS against med-fichier 4.0.0

[Gilles Filippini]

Source: gmsh
Version: 3.0.6+dfsg1-4
Severity: serious
Tags: patch ftbfs
Justification: FTBFS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Gmsh FTBFS against med-fichier 4.0.0 that I've recently uploaded to
unstable. Please find attached a patch proposal.

Thanks,

_g.

- -- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAlwcBrMACgkQ7+hsbH/+
z4Mh9gf/Y9btya0IKbOD37OO+s8X+QJvC1828//m/JajixmSJxDByWuI/36zos/K
EQhseaMvC6Qy1T+3Hum2XZewIda2C5sYhtNWjEz59aucPrOeL2cSJS7zEkI3PHlU
fnbiZh627OxR7hpjqKszVYdXIoDPTlWnY8+3weG/v1dAASP1p1raeR+dKRHYXGcd
UaBCmHkIyBI4qLDmCx6+OiHbjjsukOf5eiTmAWYqKJGTXSc8lQ2f5co+YxTVvmSp
7RWG+kH+JA60xuh0gUwmMLGf11cMjXgINh7GVUmUC+H4UTJX9ArWa3QSQlN10ZtT
UFwQJTGtO9jOQA3BESPq2IasJXqdmw==
=kqoX
-END PGP SIGNATURE-
diff -Nru gmsh-3.0.6+dfsg1/debian/changelog gmsh-3.0.6+dfsg1/debian/changelog
--- gmsh-3.0.6+dfsg1/debian/changelog   2018-12-03 01:47:52.0 +0100
+++ gmsh-3.0.6+dfsg1/debian/changelog   2018-12-20 21:24:21.0 +0100
@@ -1,3 +1,10 @@
+gmsh (3.0.6+dfsg1-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * New patch support-med-4.patch to fix FTBFS against med-fichier 4.0.0
+
+ -- Gilles Filippini   Thu, 20 Dec 2018 21:24:21 +0100
+
 gmsh (3.0.6+dfsg1-4) unstable; urgency=medium
 
   [ Joost van Zwieten ]
diff -Nru gmsh-3.0.6+dfsg1/debian/patches/series 
gmsh-3.0.6+dfsg1/debian/patches/series
--- gmsh-3.0.6+dfsg1/debian/patches/series  2018-12-03 01:19:49.0 
+0100
+++ gmsh-3.0.6+dfsg1/debian/patches/series  2018-12-20 21:22:28.0 
+0100
@@ -3,3 +3,4 @@
 30_delete_gl2ps_from_source.patch
 40_gnuinstalldirs.patch
 140_drop_css.patch
+support-med-4.patch
diff -Nru gmsh-3.0.6+dfsg1/debian/patches/support-med-4.patch 
gmsh-3.0.6+dfsg1/debian/patches/support-med-4.patch
--- gmsh-3.0.6+dfsg1/debian/patches/support-med-4.patch 1970-01-01 
01:00:00.0 +0100
+++ gmsh-3.0.6+dfsg1/debian/patches/support-med-4.patch 2018-12-20 
21:24:08.0 +0100
@@ -0,0 +1,386 @@
+Index: gmsh-3.0.6+dfsg1/Geo/GModelIO_MED.cpp
+===
+--- gmsh-3.0.6+dfsg1.orig/Geo/GModelIO_MED.cpp
 gmsh-3.0.6+dfsg1/Geo/GModelIO_MED.cpp
+@@ -29,7 +29,7 @@ extern "C" {
+ #include 
+ }
+ 
+-#if (MED_MAJOR_NUM == 3)
++#if (MED_MAJOR_NUM >= 3)
+ // To avoid too many ifdefs below we use defines for the bits of the
+ // API that did not change too much between MED2 and MED3. If we remove
+ // MED2 support at some point, please remove these defines and replace
+@@ -69,7 +69,7 @@ med_geometrie_element msh2medElementType
+   case MSH_HEX_20: return MED_HEXA20;
+   case MSH_PRI_15: return MED_PENTA15;
+   case MSH_PYR_13: return MED_PYRA13;
+-#if (MED_MAJOR_NUM == 3)
++#if (MED_MAJOR_NUM >= 3)
+   case MSH_QUA_9: return MED_QUAD9;
+   case MSH_HEX_27: return MED_HEXA27;
+ #endif
+@@ -95,7 +95,7 @@ int med2mshElementType(med_geometrie_ele
+   case MED_HEXA20: return MSH_HEX_20;
+   case MED_PENTA15: return MSH_PRI_15;
+   case MED_PYRA13: return MSH_PYR_13;
+-#if (MED_MAJOR_NUM == 3)
++#if (MED_MAJOR_NUM >= 3)
+   case MED_QUAD9: return MSH_QUA_9;
+   case MED_HEXA27: return MSH_HEX_27;
+ #endif
+@@ -113,7 +113,7 @@ int med2mshNodeIndex(med_geometrie_eleme
+   case MED_TRIA6:
+   case MED_QUAD4:
+   case MED_QUAD8:
+-#if (MED_MAJOR_NUM == 3)
++#if (MED_MAJOR_NUM >= 3)
+   case MED_QUAD9:
+ #endif
+ return k; // same node numbering as in Gmsh
+@@ -133,7 +133,7 @@ int med2mshNodeIndex(med_geometrie_eleme
+ static const int map[20] = 
{0,1,3,2,4,5,6,7,8,9,10,11,16,17,18,19,12,13,14,15};
+ return map[k];
+   }
+-#if (MED_MAJOR_NUM == 3)
++#if (MED_MAJOR_NUM >= 3)
+   case MED_HEXA27: {
+ static const int map[27] = 
{0,1,3,2,4,5,6,7,8,9,10,11,16,17,18,19,12,13,14,15,
+ 20, 22, 21, 23, 24, 25, 26};
+@@ -185,7 +185,7 @@ int GModel::readMED(const std::string 
+ char meshName[MED_TAILLE_NOM + 1], meshDesc[MED_TAILLE_DESC + 1];
+ med_int spaceDim;
+ med_maillage meshType;
+-#if (MED_MAJOR_NUM == 3)
++#if (MED_MAJOR_NUM >= 3)
+ med_int meshDim, nStep;
+ char dtUnit[MED_SNAME_SIZE + 1];
+ char axisName[3 * MED_SNAME_SIZE + 1], axisUnit[3 * MED_SNAME_SIZE + 1];
+@@ -241,7 +241,7 @@ int GModel::readMED(const std::string 
+   char meshName[MED_TAILLE_NOM + 1], meshDesc[MED_TAILLE_DESC + 1];
+   med_int spaceDim, nStep = 1;
+   med_maillage meshType;
+-#if (MED_MAJOR_NUM == 3)
++#if (MED_MAJOR_NUM >= 3)
+   med_int meshDim;
+   char dtUnit[MED_SNAME_SIZE + 1];
+   char axisName[3 * MED_SNAME_SIZE + 1], axisUnit[3 * MED_SNAME_SIZE + 1];
+@@ -276,

Bug#915573: libhdf5-mpich-103:amd64 should conflict with libhdf5-mpich-101:amd64

[Gilles Filippini]

Control: severity -1 wishlist
Control: tags -1 + wontfix

Hi,

On 2018-12-05 00:34, Witold Baryluk wrote:

Package: libhdf5-mpich-103
Severity: important


The following additional packages will be installed:
  libhdf5-mpich-103
The following NEW packages will be installed:
  libhdf5-mpich-103
0 upgraded, 1 newly installed, 0 to remove and 141 not upgraded.
2 not fully installed or removed.
Need to get 0 B/1365 kB of archives.
After this operation, 4688 kB of additional disk space will be used.
Do you want to continue? [Y/n]
(Reading database ... 551515 files and directories currently 
installed.)

Preparing to unpack .../libhdf5-mpich-103_1.10.4+repack-1_amd64.deb ...
Unpacking libhdf5-mpich-103:amd64 (1.10.4+repack-1) ...
dpkg: error processing archive
/var/cache/apt/archives/libhdf5-mpich-103_1.10.4+repack-1_amd64.deb
(--unpack):
 trying to overwrite
'/usr/lib/x86_64-linux-gnu/libhdf5_mpich_fortran.so.100', which is
also in package libhdf5-mpich-101:amd64 1.10.2+repack-1~exp1
Errors were encountered while processing:
 /var/cache/apt/archives/libhdf5-mpich-103_1.10.4+repack-1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)


I do not agree: HDF5 1.10.2 was uploaded to experimental only. While 
this conflict do exist, there is no unhandled conflict with previous 
releases from testing or unstable.


Thanks,

_g.

Bug#915102: scilab: FTBFS on amd64: Could not find or use the Java package/jar jlatexmath-fop used by LaTex Rendering

[Gilles Filippini]

Control: tags -1 + patch

Hi,

On Sun, 2 Dec 2018 19:06:53 +0100 Gilles Filippini  wrote:
> On Fri, 30 Nov 2018 14:57:04 +0100 Emilio Pozuelo Monfort
>  wrote:
> > Source: scilab
> > Version: 6.0.1-6
> > Severity: serious
> > 
> > Hi,
> > 
> > On a rebuild against libhdf5-103, scilab has failed on amd64 twice. The 
> > second
> > failure was during configure:
> > 
> > checking commons-logging... /usr/share/java/fop-transcoder-allinone.jar
> > checking jlatexmath... /usr/share/java/jlatexmath-1.0.7.jar
> > checking jlatexmath-fop... no
> > configure: error: Could not find or use the Java package/jar jlatexmath-fop 
> > used by LaTex Rendering - FOP plugin (looking for package 
> > org.scilab.forge.jlatexmath.fop.JLaTeXMathObj)
> > make[1]: *** [debian/rules:38: override_dh_auto_configure] Error 1
> > 
> > Full logs at 
> > https://buildd.debian.org/status/logs.php?pkg=scilab=6.0.1-6%2Bb1=amd64
> 
> AIUI this is due to libfop-java 2.3 now providing subsets jar in
> addition to fop.jar:
> 
> $ dpkg -L libfop-java | grep usr/share/java/ | grep 2\.3
> /usr/share/java/fop-2.3.jar
> /usr/share/java/fop-core-2.3.jar
> /usr/share/java/fop-events-2.3.jar
> /usr/share/java/fop-sandbox-2.3.jar
> /usr/share/java/fop-transcoder-2.3.jar
> /usr/share/java/fop-transcoder-allinone-2.3.jar
> /usr/share/java/fop-util-2.3.jar
> 
> Then configure picks up fop-transcoder-allinone-2.3.jar instead of
> fop-2.3.jar when looking for class org.apache.fop.pdf.PDFInfo:
> 
> checking fop... /usr/share/java/fop-transcoder-allinone-2.3.jar
> 
> I don't know how to fix that, but a temporary workaround would be to
> patch configure.ac to force /usr/share/java/fop.jar into the classpath.

Please find attached a path proposal.

Thanks,

_g.
diff -Nru scilab-6.0.1/debian/changelog scilab-6.0.1/debian/changelog
--- scilab-6.0.1/debian/changelog   2018-11-11 18:51:45.0 +0100
+++ scilab-6.0.1/debian/changelog   2018-12-04 22:51:10.0 +0100
@@ -1,3 +1,11 @@
+scilab (6.0.1-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * New patch force-fop-jar-into-classpath.patch:
+force /usr/share/java/fop.jar into the classpath (Closes: #915102)
+
+ -- Gilles Filippini   Tue, 04 Dec 2018 22:51:10 +0100
+
 scilab (6.0.1-6) unstable; urgency=medium
 
   * Bump std-ver to 4.2.1.
diff -Nru scilab-6.0.1/debian/patches/force-fop-jar-into-classpath.patch 
scilab-6.0.1/debian/patches/force-fop-jar-into-classpath.patch
--- scilab-6.0.1/debian/patches/force-fop-jar-into-classpath.patch  
1970-01-01 01:00:00.0 +0100
+++ scilab-6.0.1/debian/patches/force-fop-jar-into-classpath.patch  
2018-12-04 22:51:10.0 +0100
@@ -0,0 +1,17 @@
+Description: Workaround for bug #915102 where AC_JAVA_CHECK_JAR picks up
+ one of the fop-.jar instead of fop.jar
+Index: scilab-6.0.1/configure.ac
+===
+--- scilab-6.0.1.orig/configure.ac
 scilab-6.0.1/configure.ac
+@@ -1040,7 +1040,9 @@ interface for JOGL2 - or libGL (OpenGL l
+ 
+  Mandatory for graphic_export features #
+ # XML to PDF/other Translator
+-AC_JAVA_CHECK_JAR([fop],[org.apache.fop.pdf.PDFInfo],[XML to 
PDF Translator (fop)])
++#AC_JAVA_CHECK_JAR([fop],[org.apache.fop.pdf.PDFInfo],[XML to 
PDF Translator (fop)])
++PACKAGE_JAR_FILE=/usr/share/java/fop.jar
++ac_java_classpath=$ac_java_classpath:$PACKAGE_JAR_FILE
+ FOP=$PACKAGE_JAR_FILE
+ AC_SUBST(FOP)
+ 
diff -Nru scilab-6.0.1/debian/patches/series scilab-6.0.1/debian/patches/series
--- scilab-6.0.1/debian/patches/series  2018-11-11 18:51:45.0 +0100
+++ scilab-6.0.1/debian/patches/series  2018-12-04 22:47:46.0 +0100
@@ -21,3 +21,4 @@
 set_class_path.patch
 use_outside_font.patch
 java11-compatibility.patch
+force-fop-jar-into-classpath.patch


signature.asc
Description: OpenPGP digital signature

Bug#915207: gnudatalanguage: autopkgtests fail: test_bug_n000720, test_idlneturl, test_point_lun, test_save_restore, test_zip

[Gilles Filippini]

Hi,

Ole Streicher a écrit le 03/12/2018 à 11:02 :
> About 30-40 of those are mine, BTW. And I am still unsure whether hdf5
> is not really the cause of the problem yet, since it is the HDF5 test
> case in gnudatalanguage is the only one where I don't see a reason for
> the failure yet. Just "let us migrate" is the wrong way here -- the CI
> migration delays are to find out where the problem is before.

Please read the bugreport: I've done my homework and rebuilt
gnudatalanguage against HDF5 1.10.0 and netcdf 4.6.1 to check whether
the current HDF5 transition could be the cause of the failures. The
answer is no: autopkgtest still fails in that case.
BTW test_hdf5 is in d/tests/test-gdl.xfail. It is not the cause of the
current autopkgtest failure.

About the bug severity, I don't care actually, as soon as it doesn't
block the HDF5 transition.

Thanks,

_g.

Bug#915207: gnudatalanguage: autopkgtests fail: test_bug_n000720, test_idlneturl, test_point_lun, test_save_restore, test_zip

[Gilles Filippini]

Hi Sebastian,

On 03.12.18 00:15, Sebastiaan Couwenberg wrote:> Unfortunately the
autopkgtests for 0.9.9-1 still fail [0], and since> it's blocking the
migration of hdf5 it makes the package unsuitable for> release
justifying the RC severity [1].
Sorry, but I don't see this: gdl does not *break* hdf5 ("break" means
IMO that a package that worked before does not work anymore -- but hdf5
still works nicely, right?), and it also does not block the transition.

As far as I know, CI tests are currently setup in a non-blocking way.
And when I look into the maintainer page of hdf5, it says

"Required age increased by 30 days because of autopkgtest".

This is not a block, this is just a delay. There never was a statement
that failing CI tests are RC (or would become so before buster).

So, you you please be a bit more explicit how the RC policy applies here?

Best regards

Ole

Bug#915102: scilab: FTBFS on amd64: Could not find or use the Java package/jar jlatexmath-fop used by LaTex Rendering

[Gilles Filippini]

On Fri, 30 Nov 2018 14:57:04 +0100 Emilio Pozuelo Monfort
 wrote:
> Source: scilab
> Version: 6.0.1-6
> Severity: serious
> 
> Hi,
> 
> On a rebuild against libhdf5-103, scilab has failed on amd64 twice. The second
> failure was during configure:
> 
> checking commons-logging... /usr/share/java/fop-transcoder-allinone.jar
> checking jlatexmath... /usr/share/java/jlatexmath-1.0.7.jar
> checking jlatexmath-fop... no
> configure: error: Could not find or use the Java package/jar jlatexmath-fop 
> used by LaTex Rendering - FOP plugin (looking for package 
> org.scilab.forge.jlatexmath.fop.JLaTeXMathObj)
> make[1]: *** [debian/rules:38: override_dh_auto_configure] Error 1
> 
> Full logs at 
> https://buildd.debian.org/status/logs.php?pkg=scilab=6.0.1-6%2Bb1=amd64

AIUI this is due to libfop-java 2.3 now providing subsets jar in
addition to fop.jar:

$ dpkg -L libfop-java | grep usr/share/java/ | grep 2\.3
/usr/share/java/fop-2.3.jar
/usr/share/java/fop-core-2.3.jar
/usr/share/java/fop-events-2.3.jar
/usr/share/java/fop-sandbox-2.3.jar
/usr/share/java/fop-transcoder-2.3.jar
/usr/share/java/fop-transcoder-allinone-2.3.jar
/usr/share/java/fop-util-2.3.jar

Then configure picks up fop-transcoder-allinone-2.3.jar instead of
fop-2.3.jar when looking for class org.apache.fop.pdf.PDFInfo:

checking fop... /usr/share/java/fop-transcoder-allinone-2.3.jar

I don't know how to fix that, but a temporary workaround would be to
patch configure.ac to force /usr/share/java/fop.jar into the classpath.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#915207: gnudatalanguage: autopkgtests fail: test_bug_n000720, test_idlneturl, test_point_lun, test_save_restore, test_zip

[Gilles Filippini]

Source: gnudatalanguage
Version: 0.9.8-7
Severity: serious
Justification: Block HDF5 and netcdf transition

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Autopkgtest fails for gnudatalanguage [1]. This is not due to HDF5 nor
netcdf transitions, because I've rebuilt gnudatalanguage on unstable
against HDF5 1.10.0 and netcdf 4.6.1 and I observ the same failures:

The following tests FAILED:
 69 - test_bug_n000720.pro (Failed)
 93 - test_fft_leak.pro (Failed)
 96 - test_file_delete.pro (Failed)
103 - test_fix.pro (Failed)
106 - test_formats.pro (Failed)
114 - test_hdf5.pro (Failed)
116 - test_idlneturl.pro (Failed)
129 - test_make_dll.pro (Failed)
140 - test_n_tags.pro (Failed)
142 - test_obj_isa.pro (Failed)
144 - test_parse_url.pro (Failed)
150 - test_point_lun.pro (Failed)
166 - test_resolve_routine.pro (Failed)
168 - test_rounding.pro (Failed)
171 - test_save_restore.pro (Failed)
190 - test_total.pro (Failed)
201 - test_zip.pro (Failed)

Unfortunately I don't have the knowledge to dig further into this issue.

Thanks,

_g.

[1] https://ci.debian.net/packages/g/gnudatalanguage/unstable/amd64/

- -- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAlwCyh4ACgkQ7+hsbH/+
z4NHOgf/WRRJMYmvqXncFMwNPW0hdXaB/MBsbWXUog8K62QL4ZVBqBZxGihtGkL3
Iv/sLSG3sX1/INS921cwEUnLztR8pe3JnX9WOp8+V1ko9lTsVD5Qs8IFqV+Ex8p0
CqWGzVBkSpUNL4k9AMCyAvAW+B4J8vp1HdxUr3HcsLn7Yets1DoImTwepZX+RPwI
XABz5u9hAgrzWcVLz3CVLZXQP25yo46u3K6dNzLmPQ7bKz5voe8WUYKnLf/DEX7g
nI8HLzHUTGbdbIKE+9lkSBr6CkrjsG8iglEVERyg40GQRVvwoaP8+bj2lP+JVnDF
4y/6QRpWJSSPMXxibmvh8kdgOCvphg==
=xVNn
-END PGP SIGNATURE-

Bug#914649: libvigraimpex: diff for NMU version 1.10.0+git20160211.167be93+dfsg-6.1

[Gilles Filippini]

Control: tags 914649 + pending

Dear maintainer,

I've prepared an NMU for libvigraimpex (versioned as
1.10.0+git20160211.167be93+dfsg-6.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards,

_g.

diff -Nru libvigraimpex-1.10.0+git20160211.167be93+dfsg/debian/changelog
libvigraimpex-1.10.0+git20160211.167be93+dfsg/debian/changelog
--- libvigraimpex-1.10.0+git20160211.167be93+dfsg/debian/changelog
2018-08-11 06:20:04.0 +0200
+++ libvigraimpex-1.10.0+git20160211.167be93+dfsg/debian/changelog
2018-11-29 20:39:23.0 +0100
@@ -1,3 +1,11 @@
+libvigraimpex (1.10.0+git20160211.167be93+dfsg-6.1) unstable;
urgency=medium
+
+  * Non-maintainer upload.
+  * New patch link-with-pthread.patch to fix FTBFS against boost1.67 on
+armel (Closes: #914649)
+
+ -- Gilles Filippini   Thu, 29 Nov 2018 20:39:23 +0100
+
 libvigraimpex (1.10.0+git20160211.167be93+dfsg-6) unstable; urgency=medium
* add multi_convolution_fix_incomplete_template_paramater.patch
diff -Nru
libvigraimpex-1.10.0+git20160211.167be93+dfsg/debian/patches/link-with-pthread.patch
libvigraimpex-1.10.0+git20160211.167be93+dfsg/debian/patches/link-with-pthread.patch
---
libvigraimpex-1.10.0+git20160211.167be93+dfsg/debian/patches/link-with-pthread.patch
1970-01-01 01:00:00.0 +0100
+++
libvigraimpex-1.10.0+git20160211.167be93+dfsg/debian/patches/link-with-pthread.patch
2018-11-29 20:39:23.0 +0100
@@ -0,0 +1,16 @@
+Description: Workaround to fix FTBFS on armel
+  /usr/bin/ld:
CMakeFiles/test_blockwisewatersheds.dir/test_watersheds.cxx.o:
+undefined reference to symbol 'pthread_condattr_setclock@@GLIBC_2.4'
+Index:
libvigraimpex-1.10.0+git20160211.167be93+dfsg/config/VigraConfigureThreading.cmake
+===
+---
libvigraimpex-1.10.0+git20160211.167be93+dfsg.orig/config/VigraConfigureThreading.cmake

libvigraimpex-1.10.0+git20160211.167be93+dfsg/config/VigraConfigureThreading.cmake
+@@ -9,7 +9,7 @@ macro(VIGRA_CONFIGURE_THREADING)
+ set(THREADING_FOUND 1)
+ if(THREADING_IMPLEMENTATION MATCHES "boost")
+ include_directories(${Boost_INCLUDE_DIR})
+-set(THREADING_LIBRARIES ${Boost_THREAD_LIBRARY}
${Boost_SYSTEM_LIBRARY} ${Boost_DATE_TIME_LIBRARY} ${Boost_CHRONO_LIBRARY})
++set(THREADING_LIBRARIES ${Boost_THREAD_LIBRARY}
${Boost_SYSTEM_LIBRARY} ${Boost_DATE_TIME_LIBRARY}
${Boost_CHRONO_LIBRARY} pthread)
+ elseif(THREADING_IMPLEMENTATION MATCHES "std")
+ # Great, we can use the std library.  Nothing to do here...
+ elseif(THREADING_IMPLEMENTATION MATCHES "none")
diff -Nru
libvigraimpex-1.10.0+git20160211.167be93+dfsg/debian/patches/series
libvigraimpex-1.10.0+git20160211.167be93+dfsg/debian/patches/series
--- libvigraimpex-1.10.0+git20160211.167be93+dfsg/debian/patches/series
2018-08-11 06:18:32.0 +0200
+++ libvigraimpex-1.10.0+git20160211.167be93+dfsg/debian/patches/series
2018-11-25 22:21:32.0 +0100
@@ -7,3 +7,4 @@
 removed-static-docs.diff
 const-swap.patch
 multi_convolution_fix_incomplete_template_paramater.patch
+link-with-pthread.patch



signature.asc
Description: OpenPGP digital signature

Bug#914752: opencv: diff for NMU version 3.2.0+dfsg-4.2

[Gilles Filippini]

Control: tags 914752 + pending

Dear maintainer,

I've prepared an NMU for opencv (versioned as 3.2.0+dfsg-4.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards,

_g.
diff -Nru opencv-3.2.0+dfsg/debian/changelog opencv-3.2.0+dfsg/debian/changelog
--- opencv-3.2.0+dfsg/debian/changelog	2018-07-11 22:59:18.0 +0200
+++ opencv-3.2.0+dfsg/debian/changelog	2018-11-28 12:03:29.0 +0100
@@ -1,3 +1,10 @@
+opencv (3.2.0+dfsg-4.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches: Fix building with python3.7.1 (Closes: #914752)
+
+ -- Gilles Filippini   Wed, 28 Nov 2018 12:03:29 +0100
+
 opencv (3.2.0+dfsg-4.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru opencv-3.2.0+dfsg/debian/patches/python3.7.1.patch opencv-3.2.0+dfsg/debian/patches/python3.7.1.patch
--- opencv-3.2.0+dfsg/debian/patches/python3.7.1.patch	1970-01-01 01:00:00.0 +0100
+++ opencv-3.2.0+dfsg/debian/patches/python3.7.1.patch	2018-11-27 20:50:47.0 +0100
@@ -0,0 +1,13 @@
+Index: opencv-3.2.0+dfsg/modules/python/src2/cv2.cpp
+===
+--- opencv-3.2.0+dfsg.orig/modules/python/src2/cv2.cpp
 opencv-3.2.0+dfsg/modules/python/src2/cv2.cpp
+@@ -727,7 +727,7 @@ bool pyopencv_to(PyObject* obj, String&
+ (void)name;
+ if(!obj || obj == Py_None)
+ return true;
+-char* str = PyString_AsString(obj);
++const char* str = PyString_AsString(obj);
+ if(!str)
+ return false;
+ value = String(str);
diff -Nru opencv-3.2.0+dfsg/debian/patches/series opencv-3.2.0+dfsg/debian/patches/series
--- opencv-3.2.0+dfsg/debian/patches/series	2018-07-11 22:59:18.0 +0200
+++ opencv-3.2.0+dfsg/debian/patches/series	2018-11-27 20:51:11.0 +0100
@@ -6,3 +6,4 @@
 disable_dnn.patch
 fix_VFP_asm.patch
 ffmpeg4.0.patch
+python3.7.1.patch

Bug#914752: opencv: FTBFS against python3.7.1: error: invalid conversion from 'const char*' to 'char*' [-fpermissive]

[Gilles Filippini]

Control: tags -1 + patch

On Mon, 26 Nov 2018 23:49:37 +0100 Gilles Filippini  wrote:
> Source: opencv
> Version: 3.2.0+dfsg-4.1+b1
> Severity: serious
> Tags: ftbfs
> Justification: FTBFS
> 
> Hi,
> 
> OpenCV FTBFS aginst python3.7.1 which is transitioning as default for python3:
> 
> /build/opencv-mrTo2C/opencv-3.2.0+dfsg/modules/python/src2/cv2.cpp:730:34: 
> error: invalid conversion from 'const char*' to 'char*' [-fpermissive]
>  char* str = PyString_AsString(obj);

Patch attached.

Thanks,

_g.
diff -Nru opencv-3.2.0+dfsg/debian/changelog opencv-3.2.0+dfsg/debian/changelog
--- opencv-3.2.0+dfsg/debian/changelog  2018-07-11 22:59:18.0 +0200
+++ opencv-3.2.0+dfsg/debian/changelog  2018-11-27 20:51:21.0 +0100
@@ -1,3 +1,10 @@
+opencv (3.2.0+dfsg-4.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches: Fix building with python3.7.1 (Closes: #914752)
+
+ -- Gilles Filippini   Tue, 27 Nov 2018 20:51:21 +0100
+
 opencv (3.2.0+dfsg-4.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru opencv-3.2.0+dfsg/debian/patches/python3.7.1.patch 
opencv-3.2.0+dfsg/debian/patches/python3.7.1.patch
--- opencv-3.2.0+dfsg/debian/patches/python3.7.1.patch  1970-01-01 
01:00:00.0 +0100
+++ opencv-3.2.0+dfsg/debian/patches/python3.7.1.patch  2018-11-27 
20:50:47.0 +0100
@@ -0,0 +1,13 @@
+Index: opencv-3.2.0+dfsg/modules/python/src2/cv2.cpp
+===
+--- opencv-3.2.0+dfsg.orig/modules/python/src2/cv2.cpp
 opencv-3.2.0+dfsg/modules/python/src2/cv2.cpp
+@@ -727,7 +727,7 @@ bool pyopencv_to(PyObject* obj, String&
+ (void)name;
+ if(!obj || obj == Py_None)
+ return true;
+-char* str = PyString_AsString(obj);
++const char* str = PyString_AsString(obj);
+ if(!str)
+ return false;
+ value = String(str);
diff -Nru opencv-3.2.0+dfsg/debian/patches/series 
opencv-3.2.0+dfsg/debian/patches/series
--- opencv-3.2.0+dfsg/debian/patches/series 2018-07-11 22:59:18.0 
+0200
+++ opencv-3.2.0+dfsg/debian/patches/series 2018-11-27 20:51:11.0 
+0100
@@ -6,3 +6,4 @@
 disable_dnn.patch
 fix_VFP_asm.patch
 ffmpeg4.0.patch
+python3.7.1.patch


signature.asc
Description: OpenPGP digital signature

Bug#914752: opencv: FTBFS against python3.7.1: error: invalid conversion from 'const char*' to 'char*' [-fpermissive]

[Gilles Filippini]

Source: opencv
Version: 3.2.0+dfsg-4.1+b1
Severity: serious
Tags: ftbfs
Justification: FTBFS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

OpenCV FTBFS aginst python3.7.1 which is transitioning as default for python3:

/build/opencv-mrTo2C/opencv-3.2.0+dfsg/modules/python/src2/cv2.cpp:730:34: 
error: invalid conversion from 'const char*' to 'char*' [-fpermissive]
 char* str = PyString_AsString(obj);

Full builg log:
https://buildd.debian.org/status/fetch.php?pkg=opencv=arm64=3.2.0%2Bdfsg-4.1%2Bb2=1542824858=0

Thanks,

_g.

- -- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAlv8eHMACgkQ7+hsbH/+
z4OPqQgArPF9NPdy3KqXceZ9fZCAo5rwN1O4Cwj9B5ZT7Cz1YEOQHiJQn89NCMYd
VKOPbBLerQrsKj5sVdT+i27DKvj7Z7QYtPF1M5vCBegLIva72BqkOSMcm+h4nB/i
4GFu/dPkviRor1vjeZhycHyVSvuCy3z4ogWanh/N00cwbk62xmvPKiYKdwiib7Oy
nKOye5qVSHL2wD9oStYh2v/ToU3NrG+gRyUgzNfQ/HBbAXvYS9Mn8AjWaY7tGFwT
7tstxkR+jhd425wyrl6com89DqOQpjGcQKQWI5Yo1UD+amVbU/2Vvs89ufhHflS+
RVeYScSvPMC9gAuHj7U5hN6ZKOF07w==
=rTDr
-END PGP SIGNATURE-

Bug#914748: ant: Fail when installed along with usrmerge and invoked via /bin/ant

[Gilles Filippini]

Hi Markus,

Markus Koschany a écrit le 26/11/2018 à 23:10 :
> Hi,
> 
> Am 26.11.18 um 22:46 schrieb Gilles Filippini:
>> Package: ant
>> Version: 1.9.10-1
>> Severity: serious
>> Tags: patch
>> Justification: Causes FTBFS
>>
>> Hi,
>>
>> When installed along with usrmerge, ant can be invoked via /bin/ant. In this 
>> case it fails with:
> 
> [...]
> 
> Just some quick notes, not that I'm strongly opposed against usrmerge or
> dislike the idea in general but this is somehow odd. First of all why is
> this serious now? I know there is an ongoing discussion on debian-devel
> about usrmerge but when was it decided to file RC bugs and make this
> release-critical? I suppose opencv will work perfectly fine with the
> traditional file system layout?

To me this is RC because it makes opencv FTBFS on some official buildd
machines. No opinion at all about usrmerge.

> In any case it is not a very good idea to diverge from upstream or to
> carry yet another patch. I wonder why this hasn't been changed already
> because Fedora moved to this scheme already and they should have noticed
> that too.

In any case the scriplet replaced by the patch is buggy.
How about pushing this patch upstream?

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#914748: ant: Fail when installed along with usrmerge and invoked via /bin/ant

[Gilles Filippini]

Package: ant
Version: 1.9.10-1
Severity: serious
Tags: patch
Justification: Causes FTBFS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

When installed along with usrmerge, ant can be invoked via /bin/ant. In this 
case it fails with:

/bin/ant: 1: cd: can't cd to /bin/../share/ant/bin/..
Error: Could not find or load main class org.apache.tools.ant.launch.Launcher
Caused by: java.lang.ClassNotFoundException: 
org.apache.tools.ant.launch.Launcher

The attached patch solves the problem for me.

Setting severity to serious because it causes FTBFS. See for example [1].

[1] 
https://buildd.debian.org/status/fetch.php?pkg=opencv=amd64=3.2.0%2Bdfsg-4.1%2Bb2=1542819371=0

Thanks,

_g.


-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAlv8aaYACgkQ7+hsbH/+
z4MTeAf/dTyabk7caN+jIGWSZfSxW3HTob2CoGUHbTDclbZvVfX91PvbszNJlADO
kXgPZI6ngOky3gx0MwH8H/SqQFt2PamHFdfguSpxWG7ARIERxII7D0ifhFd4eU4V
S1RA/ZH1qP98pTX1FFDTBC4l3a8qqDXgIIOmhWqkqiXcbnG9nJMmOdQJWRDjVHQk
9YI3Si/M9wTATCF6fyQhCUG4YqstY6+5ITvuHnQzFhGebC7TElZDuwqF46ZGNnNp
0LXUZjj1A2/UYGzdx0t2YepcHHXd9tFbrDLUZN2OdIaxNorZGoq1xHAEA7x5ussm
gRyZebWqgf3B2jGmXs194+27iAt1XQ==
=Zgso
-END PGP SIGNATURE-
diff -Nru ant-1.10.5/debian/changelog ant-1.10.5/debian/changelog
--- ant-1.10.5/debian/changelog 2018-08-27 14:57:47.0 +0200
+++ ant-1.10.5/debian/changelog 2018-11-26 22:00:46.0 +0100
@@ -1,3 +1,11 @@
+ant (1.10.5-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * New patch usrmerge-proof.patch to fix failure when installed along
+with usrmerge and invoked via /bin/ant
+
+ -- Gilles Filippini   Mon, 26 Nov 2018 22:00:46 +0100
+
 ant (1.10.5-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru ant-1.10.5/debian/patches/series ant-1.10.5/debian/patches/series
--- ant-1.10.5/debian/patches/series2018-08-27 14:57:47.0 +0200
+++ ant-1.10.5/debian/patches/series2018-11-26 21:55:03.0 +0100
@@ -4,3 +4,4 @@
 0013-auto-adjust-target.patch
 0015-javadoc-ignore-source-errors.patch
 0014-remove-java-activation-module.patch
+usrmerge-proof.patch
diff -Nru ant-1.10.5/debian/patches/usrmerge-proof.patch 
ant-1.10.5/debian/patches/usrmerge-proof.patch
--- ant-1.10.5/debian/patches/usrmerge-proof.patch  1970-01-01 
01:00:00.0 +0100
+++ ant-1.10.5/debian/patches/usrmerge-proof.patch  2018-11-26 
22:00:43.0 +0100
@@ -0,0 +1,26 @@
+Description: With usrmerge configured, ant may be called via /bin/ant.
+ In this case it fails with:
+  /bin/ant: 1: cd: can't cd to /bin/../share/ant/bin/..
+ Using 'readlink -f' instead of this cumbersome while loop solves the
+ problem.
+Index: ant-1.10.5/src/script/ant
+===
+--- ant-1.10.5.orig/src/script/ant
 ant-1.10.5/src/script/ant
+@@ -144,15 +144,7 @@ if [ -z "$ANT_HOME" -o ! -d "$ANT_HOME"
+   progname=`basename "$0"`
+ 
+   # need this for relative symlinks
+-  while [ -h "$PRG" ]; do
+-ls=`ls -ld "$PRG"`
+-link=`expr "$ls" : '.*-> \(.*\)$'`
+-if expr "$link" : '/.*' > /dev/null; then
+-  PRG="$link"
+-else
+-  PRG=`dirname "$PRG"`"/$link"
+-fi
+-  done
++  PRG=`readlink -f $PRG`
+ 
+   ANT_HOME=`dirname "$PRG"`/..
+ 

Bug#914649: libvigraimpex: FTBFS against boost1.67: undefined reference to symbol 'pthread_condattr_setclock@@GLIBC_2.4'

[Gilles Filippini]

Source: libvigraimpex
Version: 1.10.0+git20160211.167be93+dfsg-6
Severity: serious
Tags: patch ftbfs
Justification: FTBFS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

libvigraimpex FTBFS against boost1.67 on armel [1]:

[ 19%] Linking CXX executable test_blockwisewatersheds
cd 
/<>/libvigraimpex-1.10.0+git20160211.167be93+dfsg/obj/test/blockwisealgorithms
 && /usr/bin/cmake -E cmake_link_script 
CMakeFiles/test_blockwisewatersheds.dir/link.txt --verbose=1
/usr/bin/c++  -W -Wall -Wextra -Wno-unused-parameter -Wno-sign-compare 
-Wno-unused-variable -Wno-type-limits -g -O2 
-fdebug-prefix-map=/<>/libvigraimpex-1.10.0+git20160211.167be93+dfsg=.
 -fstack-protector-strong -Wformat -Werror=format-security -pipe -Wdate-time 
-D_FORTIFY_SOURCE=2 -std=c++11  -rdynamic 
CMakeFiles/test_blockwisewatersheds.dir/test_watersheds.cxx.o 
CMakeFiles/test_blockwisewatersheds.dir/testsuccess.cxx.o  -o 
test_blockwisewatersheds -lboost_thread -lboost_system -lboost_date_time 
-lboost_chrono 
/usr/bin/ld: CMakeFiles/test_blockwisewatersheds.dir/test_watersheds.cxx.o: 
undefined reference to symbol 'pthread_condattr_setclock@@GLIBC_2.4'
/usr/bin/ld: //lib/arm-linux-gnueabi/libpthread.so.0: error adding symbols: DSO 
missing from command line
collect2: error: ld returned 1 exit status

[1] 
https://buildd.debian.org/status/fetch.php?pkg=libvigraimpex=armel=1.10.0%2Bgit20160211.167be93%2Bdfsg-6%2Bb2=1542723257=0

Not sure about the Good Way of solving this, but the attached patch is 
successful as a workaround (tested on armel and amd64).

Thanks,

_g.

- -- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAlv7H6QACgkQ7+hsbH/+
z4O6EQf/XBfegp9DOLxippoKKUv0XBuUI89BY3GwMbH5hYJBB1kCSaSE4t0gJxqs
dPel3rXn+O3uQVtNjzKNFYEfjU5cq2mT2vT5lSxPkUroA/XXhwZa+UTxYW76Mphr
J7FzfZAp+/d0tKW0Y1gzp1D6w5F7mNA9vw+SyhAUe0QTlNOEFZmAKsg73gc34pWe
x3n8sK8KWHlfo7HsFYmvq2CbIHbCZ/4FJ1k07GjRMCzTqQL5dT6itRbeXA/ly+Co
KYGx3NJYvioRRHkoGm/FKzrgWP7PhofKTgwMVZ6UQq4wTjjpjltUU72I52+Gfnb3
zjpEO/8tROT9uSJAFTEBVpsLT6Qzkg==
=Lpjx
-END PGP SIGNATURE-
diff -Nru libvigraimpex-1.10.0+git20160211.167be93+dfsg/debian/changelog 
libvigraimpex-1.10.0+git20160211.167be93+dfsg/debian/changelog
--- libvigraimpex-1.10.0+git20160211.167be93+dfsg/debian/changelog  
2018-08-11 06:20:04.0 +0200
+++ libvigraimpex-1.10.0+git20160211.167be93+dfsg/debian/changelog  
2018-11-25 20:43:26.0 +0100
@@ -1,3 +1,10 @@
+libvigraimpex (1.10.0+git20160211.167be93+dfsg-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * New patch link-with-pthread.patch to fix FTBFS against boost1.67 on armel
+
+ -- Gilles Filippini   Sun, 25 Nov 2018 20:43:26 +0100
+
 libvigraimpex (1.10.0+git20160211.167be93+dfsg-6) unstable; urgency=medium
 
   * add multi_convolution_fix_incomplete_template_paramater.patch
diff -Nru 
libvigraimpex-1.10.0+git20160211.167be93+dfsg/debian/patches/link-with-pthread.patch
 
libvigraimpex-1.10.0+git20160211.167be93+dfsg/debian/patches/link-with-pthread.patch
--- 
libvigraimpex-1.10.0+git20160211.167be93+dfsg/debian/patches/link-with-pthread.patch
1970-01-01 01:00:00.0 +0100
+++ 
libvigraimpex-1.10.0+git20160211.167be93+dfsg/debian/patches/link-with-pthread.patch
2018-11-25 20:43:26.0 +0100
@@ -0,0 +1,13 @@
+Index: 
libvigraimpex-1.10.0+git20160211.167be93+dfsg/config/VigraConfigureThreading.cmake
+===
+--- 
libvigraimpex-1.10.0+git20160211.167be93+dfsg.orig/config/VigraConfigureThreading.cmake
 
libvigraimpex-1.10.0+git20160211.167be93+dfsg/config/VigraConfigureThreading.cmake
+@@ -9,7 +9,7 @@ macro(VIGRA_CONFIGURE_THREADING)
+ set(THREADING_FOUND 1)
+ if(THREADING_IMPLEMENTATION MATCHES "boost")
+ include_directories(${Boost_INCLUDE_DIR})
+-set(THREADING_LIBRARIES ${Boost_THREAD_LIBRARY} 
${Boost_SYSTEM_LIBRARY} ${Boost_DATE_TIME_LIBRARY} ${Boost_CHRONO_LIBRARY})
++set(THREADING_LIBRARIES ${Boost_THREAD_LIBRARY} 
${Boost_SYSTEM_LIBRARY} ${Boost_DATE_TIME_LIBRARY} ${Boost_CHRONO_LIBRARY} 
pthread)
+ elseif(THREADING_IMPLEMENTATION MATCHES "std")
+ # Great, we can use the std library.  Nothing to do here...
+ elseif(THREADING_IMPLEMENTATION MATCHES "none")
diff -Nru libvigraimpex-1.10.0+git20160211.167be93+dfsg/debian/patches/series 
libvigraimpex-1.10.0+git20160211.167be93+dfsg/debian/patches/series
--- libvigraimpex-1.10.0+git20160211.167be93+dfsg/debian/patches/series 
2018-08-11 06:18:32.0 +0200
+++ libvigraimpex-1.10.0+git20160211.167be93+dfsg/debian/p

Bug#914347: vtk7: FTBFS against python 3.7.1 (now the default for python3)

[Gilles Filippini]

Source: vtk7
Version: 7.1.1+dfsg1-9
Severity: serious
Justification: FTBFS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Python 3.7.1 is now the default for python3 [1], and vtk7 FTBFS [2] against 
this version:

/<>/vtk7-7.1.1+dfsg1/Wrapping/PythonCore/vtkPythonArgs.cxx: In 
instantiation of 'bool vtkPythonGetStringValue(PyObject*, T*&, const char*) 
[with T = char; PyObject = _object]':
/<>/vtk7-7.1.1+dfsg1/Wrapping/PythonCore/vtkPythonArgs.cxx:287:66:   
required from here
/<>/vtk7-7.1.1+dfsg1/Wrapping/PythonCore/vtkPythonArgs.cxx:105:25: 
error: invalid conversion from 'const char*' to 'char*' [-fpermissive]
 a = PyUnicode_AsUTF8(o);
 ^~~

[1] 
https://tracker.debian.org/news/1004786/accepted-python3-defaults-371-2-source-into-unstable/
[2] 
https://buildd.debian.org/status/fetch.php?pkg=vtk7=amd64=7.1.1%2Bdfsg1-9%2Bb1=1542847447=0
 

Thanks,

_g.

- -- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAlv2tzgACgkQ7+hsbH/+
z4OytAgAnzaibDNKJjCUMSEdLLY/L4zEQOkxGkTc8EYN084aU8ndQK1XP/M9HVdO
lI47VlRGLJzPsUlpzH0/nLvD/0Z+TQZuibZMlq6unZSXqwmCcMmS6mEiOGqOL+yO
u6TyPeTfBpGRsnFycY7RT/1VbfcyHsxRLd9ipTf9/3OWU+DxmWjm0xCnzuJjfUa4
rQdv8BrEQbPHH3WWHNZkhCvbJ7nQSfLB2HQwwbt1FLlZS6o/QByGb64KLS1yfg3p
MBZ3Ct5oAQ6NX87BGu1tiYeM6E5OKggKYWyAzbZrziMojIMqiteNjcQSDV7pq7b6
iCtv/bUAFc2AhRywKQ5fSu+dGdyPAA==
=ohUZ
-END PGP SIGNATURE-

Bug#914245: h5py: FTBFS against hdf5 1.10.4 now in unstable

[Gilles Filippini]

Source: h5py
Version: 2.8.0-1
Severity: serious
Tags: patch
Justification: FTBFS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

h5py FTBFS against hdf5 1.10.4 now transitioning into unstable:
==
ERROR: test_force_swmr_mode_on_raises 
(h5py.tests.hl.test_dataset_swmr.TestDatasetSwmrRead)
Verify when reading a file cannot be forcibly switched to swmr mode.
- --
Traceback (most recent call last):
  File "h5py/tests/hl/test_dataset_swmr.py", line 75, in 
test_force_swmr_mode_on_raises
self.f.swmr_mode = True
  File "h5py/_objects.pyx", line 54, in h5py._objects.with_phil.wrapper
  File "h5py/_objects.pyx", line 55, in h5py._objects.with_phil.wrapper
  File "h5py/_hl/files.py", line 268, in swmr_mode
self.id.start_swmr_write()
  File "h5py/_objects.pyx", line 54, in h5py._objects.with_phil.wrapper
  File "h5py/_objects.pyx", line 55, in h5py._objects.with_phil.wrapper
  File "h5py/h5f.pyx", line 510, in h5py.h5f.FileID.start_swmr_write
TypeError: Unable to convert file format (no write intent on file)

==
ERROR: test_exc (h5py.tests.old.test_group.TestLen)
len() on closed group gives ValueError
- --
Traceback (most recent call last):
  File "h5py/tests/old/test_group.py", line 302, in test_exc
len(self.f)
  File "h5py/_objects.pyx", line 54, in h5py._objects.with_phil.wrapper
  File "h5py/_objects.pyx", line 55, in h5py._objects.with_phil.wrapper
  File "h5py/_hl/group.py", line 318, in __len__
return self.id.get_num_objs()
  File "h5py/_objects.pyx", line 54, in h5py._objects.with_phil.wrapper
  File "h5py/_objects.pyx", line 55, in h5py._objects.with_phil.wrapper
  File "h5py/h5g.pyx", line 331, in h5py.h5g.GroupID.get_num_objs
TypeError: Not a location id (invalid object ID)

This is due to some changes introduced in hdf5 1.10.3. Please find attached
a patch backported from upstream repository.

Thanks,

_g.

- -- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAlv0eYsACgkQ7+hsbH/+
z4M1CQf/eNEpNVS++J7s9+9ydFCjv2PDDc7JOooChlJYhIfMFKe/aN6yUEWb6+qc
7bbk5Xx6oR+KU2OptDa9liUzSkvczzPB0KhGVpBOUSYKea3+g2ydCMf6m8KRJSPl
kecdlpOS+sOzzt9dxYqhzXIYk8qBduSu8eAjMx1iMYwr4HWELTm4zQ2YQXf1CGI3
bWzVI8K6iqOIQgfjpi+Jari3SWKtQ4vEHBAU50epHJsfnOibF4Fdlc5eqk76m6x7
43+LUAYJ4UAvbtXySh2g7lf/qEEcG4g3U+q0ARyJB6RwO1jXhRokoDPVYmVuiZox
7Oi9wDkmHDzhqmhg+QabZRXQZbrI4A==
=JQqV
-END PGP SIGNATURE-
diff -Nru h5py-2.8.0/debian/changelog h5py-2.8.0/debian/changelog
--- h5py-2.8.0/debian/changelog 2018-08-04 18:54:06.0 +0200
+++ h5py-2.8.0/debian/changelog 2018-10-14 22:52:25.0 +0200
@@ -1,3 +1,10 @@
+h5py (2.8.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * New patch hdf5-1.10.3-support.patch: fix FTBFS against HDF5 1.10.3
+
+ -- Gilles Filippini   Sun, 14 Oct 2018 22:52:25 +0200
+
 h5py (2.8.0-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru h5py-2.8.0/debian/patches/hdf5-1.10.3-support.patch 
h5py-2.8.0/debian/patches/hdf5-1.10.3-support.patch
--- h5py-2.8.0/debian/patches/hdf5-1.10.3-support.patch 1970-01-01 
01:00:00.0 +0100
+++ h5py-2.8.0/debian/patches/hdf5-1.10.3-support.patch 2018-10-14 
22:52:25.0 +0200
@@ -0,0 +1,32 @@
+Description: backport upstream patch to fix FTBFS against HDF5 1.10.3
+
+From 6653c65e8c8d024bbcf50315a1c5201487632322 Mon Sep 17 00:00:00 2001
+From: Thomas A Caswell 
+Date: Thu, 11 Oct 2018 23:39:29 -0400
+Subject: [PATCH] FIX: adjust mapping of hdf5 error codes -> python error codes
+
+This is to account for changes to hdf5 between 1.10.2 and 1.10.3.
+
+Closes #1088
+---
+ h5py/_errors.pyx | 7 +++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/h5py/_errors.pyx b/h5py/_errors.pyx
+index 76801f4f..23849f49 100644
+--- a/h5py/_errors.pyx
 b/h5py/_errors.pyx
+@@ -73,6 +73,13 @@ _exact_table = {
+ (H5E_SYM, H5E_CANTINIT):ValueError, # Object already exists/1.8
+ (H5E_ARGS, H5E_BADTYPE):ValueError, # Invalid location in file
+ (H5E_REFERENCE, H5E_CANTINIT):  ValueError, # Dereferencing invalid ref
++
++# needed for 1.10.3 to maintain compatibility with 1.10.{0,1,2}
++
++# due to changes to H5Gdeprec.c:H5Gget_num_objs
++(H5E_SYM, H5E_BADTYPE): ValueError, # Invalid location in file
++ 

Bug#911814: FTBFS: make_multicomponent_mesh_3.h:40:19: error: 'CGAL::internal::Mesh_3' has not been declared

[Gilles Filippini]

Source: mshr
Version: 2018.1.0+dfsg1-6
Severity: serious
Justification: FTBFS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

During a rebuild on unstable, mshr FTBFS with:
/usr/bin/c++  -DCGAL_HEADER_ONLY -DDOLFIN_VERSION=\"2018.1.0\" -DHAS_CHOLMOD 
-DHAS_HDF5 -DHAS_MPI -DHAS_PETSC -DHAS_SCOTCH -DHAS_SLEPC -DHAS_UMFPACK 
-DHAS_ZLIB -DNDEBUG -DTETLIBRARY -D_FORTIFY_SOURCE=2 -Dmshr_EX
PORTS -I/<>/include -I/include -I/usr/include/x86_64-linux-gnu 
-isystem /usr/include/eigen3 -isystem /usr/include/hdf5/openmpi -isystem 
/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi -isystem /us
r/lib/x86_64-linux-gnu/openmpi/include -isystem 
/usr/lib/slepcdir/slepc3.9/x86_64-linux-gnu-real/include -isystem 
/usr/lib/petscdir/petsc3.9/x86_64-linux-gnu-real/include -isystem 
/usr/include/suitesparse -isyst
em /usr/include/superlu -isystem /usr/include/superlu-dist -isystem 
/usr/include/hypre -isystem /usr/include/scotch  -fpermissive -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werr
or=format-security -std=c++0x -Wall -O3 -DNDEBUG -fPIC   -std=c++11 -o 
CMakeFiles/mshr.dir/src/CSGPrimitives2D.cpp.o -c 
/<>/src/CSGPrimitives2D.cpp
  
In file included from /<>/src/CSGCGALMeshGenerator3D.cpp:43:   

  
/<>/src/make_multicomponent_mesh_3.h: In function 'void 
make_multicomponent_mesh_3_impl(C3T3&, const MeshDomain&, const MeshCriteria&, 
const CGAL::parameters::internal::Exude_options&, const CGAL::p
arameters::internal::Perturb_options&, const 
CGAL::parameters::internal::Odt_options&, const 
CGAL::parameters::internal::Lloyd_options&, bool, const 
CGAL::parameters::internal::Mesh_3_options&)':   
/<>/src/make_multicomponent_mesh_3.h:40:19: error: 
'CGAL::internal::Mesh_3' has not been declared  
  
   CGAL::internal::Mesh_3::C3t3_initializer<

  
   ^~   

  
/<>/src/make_multicomponent_mesh_3.h:41:9: error: expected 
primary-expression before ',' token 
  
 C3T3,  

  
 ^  

  
/<>/src/make_multicomponent_mesh_3.h:42:15: error: expected 
primary-expression before ',' token 
 
 MeshDomain,

  
   ^

  
/<>/src/make_multicomponent_mesh_3.h:43:17: error: expected 
primary-expression before ',' token 
 
 MeshCriteria,  

  
 ^
/<>/src/make_multicomponent_mesh_3.h:44:21: error: 
'CGAL::internal::Mesh_3' has not been declared  
  
 CGAL::internal::Mesh_3::has_Has_features::value > () (c3t3,

  
 ^~ 

  
/<>/src/make_multicomponent_mesh_3.h:44:56: error: expected 
primary-expression before '>' token 
 
 

Bug#911615: FTBFS: superlu_dist.c:701:25: error: 'LargeDiag' was not declared in this scope

[Gilles Filippini]

Source: petsc
Version: 3.9.4+dfsg1-1
Severity: serious
Justification: FTBFS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

petsc FTBFS on unstable with:
/<>/src/mat/impls/aij/mpi/superlu_dist/superlu_dist.c: In function 
'PetscErrorCode MatGetFactor_aij_superlu_dist(Mat, MatFactorType, _p_Mat**)':   
  
/<>/src/mat/impls/aij/mpi/superlu_dist/superlu_dist.c:701:25: 
error: 'LargeDiag' was not declared in this scope   
   
   options.RowPerm = LargeDiag; 

  
 ^  

  
/<>/src/mat/impls/aij/mpi/superlu_dist/superlu_dist.c:701:25: 
note: suggested alternative: 'LargeDiag_AWPM'   
   
   options.RowPerm = LargeDiag; 

  
 ^  

  
 LargeDiag_AWPM 

  
make[4]: *** [gmakefile:150: 
x86_64-linux-gnu-real-debug/obj/mat/impls/aij/mpi/superlu_dist/superlu_dist.o] 
Error 1 
  
make[4]: Leaving directory '/<>'
make[4]: *** Waiting for unfinished jobs

  

Thanks,

_g.

- -- System Information:
Distributor ID: PureOS
Description:PureOS GNU/Linux 8
Release:8
Codename:   green
Architecture: x86_64

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAlvN5nQACgkQ7+hsbH/+
z4Ndcwf/YW+yWbV6CNcnGAsklkVXpIM5ee8+xePd2tWi33duxJnBFAAFJvylsJNP
PCjBoF/0JXuZoonu1JvDHWpGeIXvvvJiUQnyX5L9loqGKxH4PR0pvq/gEx7zuG6E
gCjuJcWDR4rdoiMZOrH/kXJlVGrfcRcsHaUPbIC4LECSpULVLjgRi7eBMIZj5jlM
D2mlcNlNXNjH3L8F2pdBWgl/Sf7r2F4JzoynV0az7nr9BEKD25LT1Ix8CRToSdZW
Q7C1Zj+mekIPIi4X4ttbTjI2PD4TwVVAD5+JRLogIcm7FBlWDZaVh4DY5N8bipLG
tiAtWu3Sm1DHx4Q6LjGGCrCFxeTBPw==
=rMSf
-END PGP SIGNATURE-

Bug#909910: Bug #909910 in jython marked as pending

[Gilles Filippini]

Control: tag -1 pending

Hello,

Bug #909910 in jython reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:

https://salsa.debian.org/java-team/jython/commit/dd9bd950abb152018cc3652e998a7df0fa839bdd


Fix jh_installlibs regex (closes: #909910)



(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/909910

Bug#906811: FTBFS: libconfig.h: No such file or directory

[Gilles Filippini]

Source: blasr
Version: 5.3+0-2
Severity: serious
Justification: FTBFS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

When recompiling blasr for unstable it FTBFS with:

make[1]: Leaving directory '/<>'
   debian/rules override_dh_auto_build   
make[1]: Entering directory '/<>'
dh_auto_build 
make -j1 "INSTALL=install --strip-program=true"
make[2]: Entering directory '/<>'
make[2]: git: Command not found
g++ -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/pbseq -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -O3 -g -DSHA1_7=\"\" -std=c++0x -pedantic -Wall -We
xtra -Wno-div-by-zero -Wno-overloaded-virtual -MMD -MP -fno-builtin-malloc 
-fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free 
-fno-omit-frame-pointer  -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/pbseq
/alignment -I/usr/include/pbseq/hdf -I/usr/include/pbseq/pbdata -I/usr/include 
-I/usr/include/hdf5/serial -I/usr/include/htslib -I/usr/include/boost  -c -o 
Blasr.o Blasr.cpp
In file included from iblasr/BlasrMiscs.hpp:4,
 from Blasr.cpp:3:  
iblasr/BlasrHeaders.h:24:10: fatal error: libconfig.h: No such file or directory
 #include
  ^
compilation terminated.
make[2]: *** [: Blasr.o] Error 1

Full log attached.

Thanks,

_g.

- -- System Information:
Distributor ID: PureOS
Description:PureOS GNU/Linux 8
Release:8
Codename:   green
Architecture: x86_64

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages blasr depends on:
ii  libc62.27-5
ii  libgcc1  1:8.2.0-3
ii  libhdf5-100  1.10.0-patch1+docs-4+b2
ii  libhdf5-cpp-100  1.10.0-patch1+docs-4+b2
pn  libhts2  
pn  libpbbam 
pn  libpbseq 
ii  libstdc++6   8.2.0-3
ii  zlib1g   1:1.2.11.dfsg-1

blasr recommends no packages.

blasr suggests no packages.

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAlt8Cu8ACgkQ7+hsbH/+
z4OhTQf/bZPsdSP7SzdhPH4n7kRghAx0aH+hiRpMbwIV+KbBKrFglcVV4G6X9LJM
eAI2ovx0mk27VKLPjKFA7eYkin5j3JxEvKDrSiqwu4xk7YAtHf/4rfMIJfLs1za2
oXqaWkc7GlKhX834A+0B2kxCOnmOLLETOXAoPzJl0+TFt3Ec5uJbXQSd6QLF0iJO
LTm4zx8kl/3KXxQPZUHkQibC/B6G5vDHl2KoXNnAqQHqyDjFrFE5wglu4mUV/u0X
2kVaNezD7+o1HGqLEOTKXFT9rLH13EWoL79/Tcblr66jjJdgn36tFqHggVc74d5v
42+SK5GWyaR5yXNPH27mj1NS/RSF7g==
=0mhM
-END PGP SIGNATURE-


blasr_5.3+0-2_amd64-2018-08-21T11:40:43Z.build.gz
Description: application/gzip

Bug#842815: Help needed for HDF5 1.10 transition of libsis-jhdf5-java

[Gilles Filippini]

Hi,

Andreas Tille a écrit le 28/05/2018 à 11:29 :
> Hi folks from Debian Science,
> 
> is there anybody out there who can help with some HDF5 1.10 transition?
> 
> I admit I have no experience with HDF5 neither with Java - but the
> migration would help a lot.
> 
> Kind regards
> 
>Andreas.

As already stated in this thread [1] I think patching libsis-jhdf5-java
is a huge task beyond my available time.

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

> On Mon, May 28, 2018 at 09:18:28AM +0200, Bernd Rinn wrote:
>> Hello Andreas,
>>
>> On 05/27/2018 07:12 AM, Andreas Tille wrote:
>>> Hello Bernd,
>>>
>>> sorry for nagging again but we now have another Dependency from
>>> sis-jhdf5 which makes a fix for this issue even more interesting.  As I

Have you considered using libhdf5-java or libjhdf5-java instead?

_g.

>>> said before I would also try a patch if you might hesitate to issue a
>>> completely new release.
>>
>> It is embarrassing to admit that I still haven't found the time to port
>> JHDF5 to HDF5 1.10.
>>
>> If you can come up with a patch to bridge to time that would be greatly
>> appreciated!
>>
>> Kind regards,
>> Bernd
>>  Andreas.
>>>
>>> On Wed, Sep 06, 2017 at 12:50:56PM +0200, Andreas Tille wrote:
 Hello Bernd,

 On Wed, 23 Nov 2016 06:54:21 +0100, you wrote
> the migration of JHDF5 to HDF5 1.10 is ongoing and mostly depend on me
> having a block of time I can spend on it. Your analysis of the work that
> needs to be done is right from what I can see. The plan is to switch to
> using the JNI library from the HDF group wherever possible (it may still
> be necessary to have a small JNI library though as some calls appear to
> be missing).
>
> I will keep you updated.

 Is there any news, may be only a patch for the existing version we
 could try to fix the Debian package?

 Kind regards

Andreas.

 -- 
 http://fam-tille.de

 ___
 Debian-med-packaging mailing list
 debian-med-packag...@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging

>>>
>>
>> -- 
>> Dr. Bernd Rinn
>> Head Scientific IT Services
>> ETH Zurich IT Services
>> SIB Swiss Institute of Bioinformatics
>> Weinbergstr. 11 (WEC D 19), 8092 Zürich, Switzerland, +41 44 632 0608
>> Mattenstr. 26 (BSB 1.01), 4058 Basel, Switzerland, +41 61 387 3130
>>
> 
> 
> 




signature.asc
Description: OpenPGP digital signature

Bug#897215: sikulix: SikuliX 1.1.1 does not support Java 9

[Gilles Filippini]

Hi,

Chris Lamb a écrit le 27/05/2018 à 16:09 :
> severity 897215 serious
> thanks
> 
> Hi,
> 
>> Java 9 is the default in Buster so perhaps this should be RC?
> 
> Indeed it should; adjusting to match.
> 
> Java team, would you object if I went ahead and uploaded the latest
> "branch" of SikuliX? Note that the current upstream repo has been
> entirely deprecated and has been moved to:
> 
>   https://github.com/RaiMan/SikuliX1

You might want to give it a try, but I found SikuliX 1.1.2 in such a bad
shape that I filled a ROM request to remove this package from the archive:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897333

Regards,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#897492: [Debichem-devel] Bug#897492: what are you building?

[Gilles Filippini]

Control: tags -1 + patch

Hi,

On Tue, 15 May 2018 00:14:25 +0200 Michael Banck <mba...@debian.org> wrote:
> Hi Lori,
> 
> On Mon, May 14, 2018 at 11:18:43AM -0400, Lori Burns wrote:
> > * What version of psi4 are you trying to build? 
> 
> This should be 1.1.
> 
> > Apparently not a git clone, so I can’t see the version info. If it’s
> > 1.1, then the pybind11 2.2 that you’re using absolutely won’t work (I
> > hadn’t added EXACT to `find_package(pybind11 2.0 EXACT REQUIRED)`
> > then). Moreover, no pb11 2.0 _package_ will work (unless yours was
> > built with CMake, not pip) and you just have to let psi4 build system
> > pull and build its own. 
> 
> Back when 1.1. was introduced to Debian/Ubuntu, pybin11-2.0 was the
> current version and yes, it seems like they were built with cmake, but I
> didnt' dig very deep into this.
> 
> In the meantime, it appears that pybind11 got updated to 2.2.

Could the fix be as simple as the one attached? The package builds fine,
but I don't know how to test it (just investigating this issue because
psi4 is a reverse dependency of hdf5).

Regards,

_g.
diff -Nru psi4-1.1/debian/changelog psi4-1.1/debian/changelog
--- psi4-1.1/debian/changelog   2018-01-14 11:12:10.0 +0100
+++ psi4-1.1/debian/changelog   2018-05-17 20:07:24.0 +0200
@@ -1,3 +1,10 @@
+psi4 (1:1.1-6) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload
+  * Fix FTBFS with pybind11 2.2 (closes: #897492)
+
+ -- Gilles Filippini <p...@debian.org>  Thu, 17 May 2018 20:07:24 +0200
+
 psi4 (1:1.1-5) unstable; urgency=medium
 
   * debian/control (Build-Depends): Added python3-pytest.
diff -Nru psi4-1.1/debian/patches/series psi4-1.1/debian/patches/series
--- psi4-1.1/debian/patches/series  2018-01-13 18:27:21.0 +0100
+++ psi4-1.1/debian/patches/series  2018-05-17 20:04:40.0 +0200
@@ -5,3 +5,4 @@
 libderiv_include_location.patch
 fix_manual_build.patch
 verbose_makefile.patch
+support-pybind11-2.2.patch
diff -Nru psi4-1.1/debian/patches/support-pybind11-2.2.patch 
psi4-1.1/debian/patches/support-pybind11-2.2.patch
--- psi4-1.1/debian/patches/support-pybind11-2.2.patch  1970-01-01 
01:00:00.0 +0100
+++ psi4-1.1/debian/patches/support-pybind11-2.2.patch  2018-05-17 
20:07:24.0 +0200
@@ -0,0 +1,14 @@
+Description: Tentative fix for pybind11 2.2 support
+Index: psi4-1.1/psi4/src/export_functional.cc
+===
+--- psi4-1.1.orig/psi4/src/export_functional.cc
 psi4-1.1/psi4/src/export_functional.cc
+@@ -109,7 +109,7 @@ void export_functional(py::module )
+ def("set_meta_cutoff", ::set_meta_cutoff, "docstring").
+ def("set_parameter", ::set_parameter, "docstring").
+ def("print_out", ::py_print, "docstring").
+-def("print_detail",::py_print_detail, "docstring");
++def("print_detail",::py_print_detail, "docstring");
+ 
+ py::class_<VBase, std::shared_ptr >(m, "VBase", "docstring").
+ def_static("build", [](std::shared_ptr , 
std::shared_ptr , std::string type){


signature.asc
Description: OpenPGP digital signature

Bug#898526: h5py: FTBFS with HDF5 1.10.2

[Gilles Filippini]

Control: tags + patch

On Sun, 13 May 2018 16:01:31 +0200 Gilles Filippini <p...@debian.org> wrote:
> Control: severity -1 serious
> Control: retitle -1 h5py: FTBFS - FAIL: test_out_of_order_offsets
> 
> On Sun, 13 May 2018 02:49:12 +0200 Gilles Filippini <p...@debian.org> wrote:
> > Source: h5py
> > Version: 2.7.1-2
> > Severity: normal
> > 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > Hi,
> > 
> > h5py FTBFS with HDF5 1.10.2 currently in experimental. The failure occurs
> > during the tests where two of them fail:
> > 
> > ==
> > FAIL: test_out_of_order_offsets (h5py.tests.hl.test_datatype.TestOffsets)
> > - --
> > Traceback (most recent call last):
> >   File "h5py/tests/hl/test_datatype.py", line 198, in 
> > test_out_of_order_offsets
> > self.assertArrayEqual(fd['data'], data)
> >   File "h5py/tests/common.py", line 124, in assertArrayEqual
> > "Dtype mismatch (%s vs %s)%s" % (dset.dtype, arr.dtype, message)
> > AssertionError: Dtype mismatch ({'names':['f1','f3','f2'], 
> > 'formats':['<f4','<f8','<i4'], 'offsets':[0,8,16], 'itemsize':20} vs 
> > {'names':['f1','f2','f3'], 'formats':['<f4','<i4','<f8'], 
> > 'offsets':[0,16,8], 'itemsize':20})
> > 
> > ==
> > FAIL: test_out_of_order_offsets (h5py.tests.old.test_h5t.TestCompound)
> > - --
> > Traceback (most recent call last):
> >   File "h5py/tests/old/test_h5t.py", line 61, in test_out_of_order_offsets
> > self.assertEqual(tid.dtype, expected_dtype)
> > AssertionError: dtype({'names':['f1','f3','f2'], 
> > 'formats':['<f4','<f8','<i4'], 'offsets':[0,8,16], 'itemsize':20}) != 
> > dtype({'names':['f1','f2','f3'], 'formats':['<f4','<i4','<f8'], 
> > 'offsets':[0,16,8], 'itemsize':20})
> > 
> > - --
> > Ran 447 tests in 1.206s
> > 
> > FAILED (failures=2, skipped=18, expected failures=6)
> 
> Actually it FTBFS with the very same failure on unstable as well. Then
> raising severity to serious.
> 
> This seems tied to the recent python-numpy upgrade to 1.14.3. It builds
> fine against python-numpy 1.13.3.

Upstream release 2.8.0 doesn't FTBFS. The upstream commit 5009e06 [1]
fixes the issue. Attached a patch proposal after this commit.

Thanks,
diff -Nru h5py-2.7.1/debian/changelog h5py-2.7.1/debian/changelog
--- h5py-2.7.1/debian/changelog 2017-09-11 11:15:49.0 +0200
+++ h5py-2.7.1/debian/changelog 2018-05-16 17:00:35.0 +0200
@@ -1,3 +1,10 @@
+h5py (2.7.1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport upstream commit to support numpy 1.14
+
+ -- Gilles Filippini <p...@debian.org>  Wed, 16 May 2018 17:00:35 +0200
+
 h5py (2.7.1-2) unstable; urgency=medium
 
   * Fixup the debug package description for Python 2.
diff -Nru h5py-2.7.1/debian/patches/series h5py-2.7.1/debian/patches/series
--- h5py-2.7.1/debian/patches/series2017-09-11 11:15:49.0 +0200
+++ h5py-2.7.1/debian/patches/series2018-05-16 17:00:35.0 +0200
@@ -1,3 +1,4 @@
 No-rpath.patch
 No-intersphinx.patch
 Fix-build-of-API-docs-with-Python-3.patch
+Support-numpy-1.14.patch
diff -Nru h5py-2.7.1/debian/patches/Support-numpy-1.14.patch 
h5py-2.7.1/debian/patches/Support-numpy-1.14.patch
--- h5py-2.7.1/debian/patches/Support-numpy-1.14.patch  1970-01-01 
01:00:00.0 +0100
+++ h5py-2.7.1/debian/patches/Support-numpy-1.14.patch  2018-05-16 
17:00:35.0 +0200
@@ -0,0 +1,84 @@
+Description: Backport of upstream commit 5009e06 stripped of setup related
+ changes
+
+From 5009e062a6f7d4e074cab0fcb42a780ac2b1d7d4 Mon Sep 17 00:00:00 2001
+From: James Tocknell <aragi...@gmail.com>
+Date: Thu, 28 Dec 2017 20:55:55 +1100
+Subject: [PATCH] FIX: Don't reorder compound types, breaks on numpy 1.14
+
+---
+ h5py/h5t.pyx | 25 +++--
+ setup.py |  2 +-
+ tox.ini  |  4 ++--
+ 3 files changed, 10 insertions(+), 21 deletions(-)
+
+diff --git a/h5py/h5t.pyx b/h5py/h5t.pyx
+index cc2344e1..7445e9eb 100644
+--- a/h5py/h5t.pyx
 b/h5py/h5t.pyx
+@@ -1136,12 +1136,6 @@ cdef class TypeCompoundID(TypeCompositeID):
+ else:
+ if sys.version[0] == '3':
+ field_names = [x.decode('utf8') for x in field_names]
+-if len(field_names) > 0:
+-collated_fields = zip(field_names, field_types, field_offsets)
+-ord

Bug#897492: psi4: FTBFS: pybind11.h:1010:105: error: cannot convert 'void (psi::SuperFunctional::*)(int) const' to 'void (psi::Functional::*)(int) const' in return

[Gilles Filippini]

Control: forwarded -1 https://github.com/psi4/psi4/issues/852


On Wed, 2 May 2018 22:04:49 +0200 Lucas Nussbaum  wrote:
> Source: psi4
> Version: 1:1.1-5
> Severity: serious
> Tags: buster sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20180502 qa-ftbfs
> Justification: FTBFS on amd64
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> Relevant part (hopefully):
> > cd /<>/builddir/psi4-core-prefix/src/psi4-core-build/src && 
> > /usr/bin/c++  -Dcore_EXPORTS -I/<>/psi4/include 
> > -I/<>/psi4/src -isystem /usr/include/python3.6m  -fopenmp -O2 
> > -g -DNDEBUG -fPIC   -fvisibility=hidden -std=c++11 -std=c++11 -o 
> > CMakeFiles/core.dir/export_functional.cc.o -c 
> > /<>/psi4/src/export_functional.cc
> > In file included from /<>/psi4/include/psi4/pybind11.h:10:0,
> >  from /<>/psi4/src/export_functional.cc:29:
> > /usr/include/pybind11/pybind11.h: In instantiation of 'Return (Derived::* 
> > pybind11::method_adaptor(Return (Class::*)(Args ...) const))(Args ...) 
> > const [with Derived = psi::Functional; Return = void; Class = 
> > psi::SuperFunctional; Args = {int}]':
> > /usr/include/pybind11/pybind11.h:1085:45:   required from 
> > 'pybind11::class_& pybind11::class_ > options>::def(const char*, Func&&, const Extra& ...) [with Func = void 
> > (psi::SuperFunctional::*)(int) const; Extra = {char [10]}; type_ = 
> > psi::Functional; options = {std::shared_ptr}]'
> > /<>/psi4/src/export_functional.cc:112:74:   required from here
> > /usr/include/pybind11/pybind11.h:1010:105: error: cannot convert 'void 
> > (psi::SuperFunctional::*)(int) const' to 'void (psi::Functional::*)(int) 
> > const' in return
> >  auto method_adaptor(Return (Class::*pmf)(Args...) const) -> Return 
> > (Derived::*)(Args...) const { return pmf; }
> > 
> >  ^~~
> > make[6]: *** [src/CMakeFiles/core.dir/build.make:131: 
> > src/CMakeFiles/core.dir/export_functional.cc.o] Error 1
> 
> The full build log is available from:
>http://aws-logs.debian.net/2018/05/02/psi4_1.1-5_unstable.log

This is upstream bug #852:
https://github.com/psi4/psi4/issues/852

Regards,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#898577: pytables: FTBFS - 56 tests fail with 'TypeError: a float is required'

[Gilles Filippini]

Source: pytables
Version: 3.4.3-1
Severity: serious
Justification: FTBFS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

pytables FTBFS on unstable during the tests step. 56 tests fail with errors 
like:

==
ERROR: test00_description (tables.tests.test_tables.RecArrayTwoWriteTestCase)
Checking table description and descriptive fields.
- --
Traceback (most recent call last):
  File 
"/<>/build/lib.linux-x86_64-2.7/tables/tests/test_tables.py", line 
138, in setUp
self.populateFile()
  File 
"/<>/build/lib.linux-x86_64-2.7/tables/tests/test_tables.py", line 
213, in populateFile
self.initRecArray()
  File 
"/<>/build/lib.linux-x86_64-2.7/tables/tests/test_tables.py", line 
207, in initRecArray
shape=self.expectedrows)
  File "/usr/lib/python2.7/dist-packages/numpy/core/records.py", line 847, in 
array
return fromrecords(obj, dtype=dtype, shape=shape, **kwds)
  File "/usr/lib/python2.7/dist-packages/numpy/core/records.py", line 708, in 
fromrecords
retval = sb.array(recList, dtype=descr)
TypeError: a float is required

Regards,

_g.


- -- System Information:
Distributor ID: PureOS
Description:PureOS GNU/Linux 8
Release:8
Codename:   green
Architecture: x86_64

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAlr4msIACgkQ7+hsbH/+
z4MfyggApCe7IWvb2JQUOwpcyVH85TEqaZLZXTRDg4SuC/7WkQfbMj5A+Mh56QXP
BbQPRlIVzgR0jcrC+6VyLHqiKIAsaR4EUuLxP86rcWF4LFrn9I8tqjM/9OCv6zM0
XzSXQfcLXQuulqo01GYk0zB/Yt1PMod3hi76zLUui9UphTNZVx40/v+6iAkmCYko
9YAI0P7DQOtlBmSvePl/KawaiS8TUgeZv/pw9la5CAznlnOD22Pt2uowh7qm8uAO
FtRlt4eG/2/IL8gqS9hdPeeb+8iePOQVKnHDtf3iipvwBucFFsMa5FzEqcZRwLEk
2UdXhOimaAMrihNc6Lzq/T8OuJggLg==
=2eVK
-END PGP SIGNATURE-

Bug#844939: Yup, fixed.

[Gilles Filippini]

On Sat, 17 Mar 2018 17:00:08 +0100 Gilles Filippini <p...@debian.org> wrote:
> Hi,
> 
> I've just tried to build your package and it fails the tests:
> # still have 3 known breakage(s)
> # failed 18 among remaining 36 test(s)
> 1..39

Actually, after upgrading against [1] it builds fine.

[1] https://github.com/mnauw/git-remote-hg/issues/11

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#844939: Yup, fixed.

[Gilles Filippini]

Hi,

I've just tried to build your package and it fails the tests:
# still have 3 known breakage(s)
# failed 18 among remaining 36 test(s)
1..39

Full build log attached.

Thanks,

_g.

On Sun, 3 Dec 2017 21:09:52 + Chris West  wrote:
> Control: tags -1 + fixed-upstream
> 
> Mark has kindly fixed the bug upstream, and the package now builds
> correctly (after adding locales-all). My repo[1] now builds successfully
> inside gbp with pbuilder.
> 
> I've also bumped the standards version, as I believe it only requires a
> trivial change.
> 
> 1: https://github.com/FauxFaux/git-remote-hg


git-remote-hg_0.3+git20171203.9f6c541-1_amd64.build.gz
Description: application/gzip


signature.asc
Description: OpenPGP digital signature

Bug#871506: stretch update for hdf5

[Gilles Filippini]

Sebastiaan Couwenberg a écrit le 26/02/2018 à 22:33 :
> On 02/26/2018 10:23 PM, Adrian Bunk wrote:
>> On Sun, Aug 13, 2017 at 05:51:08PM +, Debian Bug Tracking System wrote:
>>> ...
>>>  hdf5 (1.10.0-patch1+docs-4) unstable; urgency=medium
>>>  .
>>>* debian/rules: fix javahelper invocation (closes: #871506)
>>> ...
>>
>> Thanks a lot for fixing this bug for unstable.
>>
>> It is still present in stretch, could you also fix it there?
>> Alternatively, I can fix it for stretch if you don't object.
> 
> The stretch-pu was requested in #872642 and given a go-ahead.
> 
> It's just a matter of uploading or am I missing something?

Oops! I missed the go which occurred while I was on holidays this last
summer. Sorry about that.

I'll take care of it in the next few days.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#882955: ufo-filters FTBFS with glibc 2.25

[Gilles Filippini]

Control: tags -1 + patch

On Mon, 27 Nov 2017 23:43:34 +0200 Adrian Bunk <b...@debian.org> wrote:
> Source: ufo-filters
> Version: 0.14.1+dfsg1-1
> Severity: serious
> 
> cd /build/1st/ufo-filters-0.14.1+dfsg1/obj-x86_64-linux-gnu/src && 
> /usr/bin/cc -DG_LOG_DOMAIN=\"Ufo\" -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES 
> -Dufofilterread_EXPORTS -I/build/1st/ufo-filters-0.14.1+dfsg1/deps/oclfft 
> -I/usr/include/x86_64-linux-gnu -I/usr/include/hdf5/serial 
> -I/build/1st/ufo-filters-0.14.1+dfsg1/obj-x86_64-linux-gnu/src 
> -I/build/1st/ufo-filters-0.14.1+dfsg1/src -I/usr/include/ufo-0 
> -I/usr/include/json-glib-1.0 -I/usr/include/glib-2.0 
> -I/usr/lib/x86_64-linux-gnu/glib-2.0/include  -g -O2 -fstack-protector-strong 
> -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=c99 
> -std=c99 -pedantic -Wall -Wextra -fPIC -Wno-unused-parameter 
> -Wno-deprecated-declarations -fopenmp -fPIC   -Wall -Wextra -fPIC 
> -Wno-unused-parameter -o CMakeFiles/ufofilterread.dir/ufo-read-task.c.o   -c 
> /build/1st/ufo-filters-0.14.1+dfsg1/src/ufo-read-task.c
> ...
> /build/1st/ufo-filters-0.14.1+dfsg1/src/ufo-read-task.c: In function 
> 'read_filenames':
> /build/1st/ufo-filters-0.14.1+dfsg1/src/ufo-read-task.c:159:32: error: 
> 'GLOB_TILDE' undeclared (first use in this function); did you mean 
> 'G_IS_FILE'?
>  glob (pattern, GLOB_MARK | GLOB_TILDE, NULL, );
> ^~
> G_IS_FILE
> /build/1st/ufo-filters-0.14.1+dfsg1/src/ufo-read-task.c:159:32: note: each 
> undeclared identifier is reported only once for each function it appears in
> cd /build/1st/ufo-filters-0.14.1+dfsg1/obj-x86_64-linux-gnu/src && 
> /usr/bin/cmake -E cmake_link_script 
> CMakeFiles/ufofiltervolumerender.dir/link.txt --verbose=1
> cd /build/1st/ufo-filters-0.14.1+dfsg1/obj-x86_64-linux-gnu/src && 
> /usr/bin/cmake -E cmake_link_script 
> CMakeFiles/ufofiltermedianfilter.dir/link.txt --verbose=1
> make[3]: Leaving directory 
> '/build/1st/ufo-filters-0.14.1+dfsg1/obj-x86_64-linux-gnu'
> src/CMakeFiles/ufofilterread.dir/build.make:65: recipe for target 
> 'src/CMakeFiles/ufofilterread.dir/ufo-read-task.c.o' failed
> make[3]: *** [src/CMakeFiles/ufofilterread.dir/ufo-read-task.c.o] Error 1
> 
> 
> GLOB_TILDE is a GNU extension, therefore it looks correct
> that it is (no longer) available with -std=c99.

Patch proposal attached.

_g.
diff -Nru ufo-filters-0.14.1+dfsg1/debian/changelog 
ufo-filters-0.14.1+dfsg1/debian/changelog
--- ufo-filters-0.14.1+dfsg1/debian/changelog   2017-10-13 18:39:58.0 
+0200
+++ ufo-filters-0.14.1+dfsg1/debian/changelog   2017-11-28 21:48:35.0 
+0100
@@ -1,3 +1,12 @@
+ufo-filters (0.14.1+dfsg1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * New patch glob_tilde.patch: force GNU extensions in
+src/ufo-read-task.c to have GLOB_TILDE while building with -std=c99
+(closes: #882955)
+
+ -- Gilles Filippini <p...@debian.org>  Tue, 28 Nov 2017 21:48:35 +0100
+
 ufo-filters (0.14.1+dfsg1-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru ufo-filters-0.14.1+dfsg1/debian/patches/glob_tilde.patch 
ufo-filters-0.14.1+dfsg1/debian/patches/glob_tilde.patch
--- ufo-filters-0.14.1+dfsg1/debian/patches/glob_tilde.patch1970-01-01 
01:00:00.0 +0100
+++ ufo-filters-0.14.1+dfsg1/debian/patches/glob_tilde.patch2017-11-28 
21:48:31.0 +0100
@@ -0,0 +1,13 @@
+Index: ufo-filters/src/ufo-read-task.c
+===
+--- ufo-filters.orig/src/ufo-read-task.c
 ufo-filters/src/ufo-read-task.c
+@@ -17,6 +17,8 @@
+  * License along with this library.  If not, see 
<http://www.gnu.org/licenses/>.
+  */
+ 
++#define _GNU_SOURCE
++
+ #include 
+ #include 
+ #include 
diff -Nru ufo-filters-0.14.1+dfsg1/debian/patches/series 
ufo-filters-0.14.1+dfsg1/debian/patches/series
--- ufo-filters-0.14.1+dfsg1/debian/patches/series  2017-10-13 
18:38:42.0 +0200
+++ ufo-filters-0.14.1+dfsg1/debian/patches/series  2017-11-28 
21:48:35.0 +0100
@@ -1 +1,2 @@
 patch-conf.py-in-order-to-use-the-locall
+glob_tilde.patch


signature.asc
Description: OpenPGP digital signature

Bug#882181: mockito: FTBFS - java.lang.UnsupportedOperationException: Cannot nest operations in the same thread

[Gilles Filippini]

Hi Markus,

Markus Koschany a écrit le 20/11/2017 à 21:17 :
> Control: tags -1 confirmed
> 
> Am 20.11.2017 um 00:27 schrieb Gilles Filippini:
>> Source: mockito
>> Version: 1.10.19-2
>> Severity: serious
>> Justification: FTBFS
>>
>> Hi,
>>
>> While testing a build of mockito against a new json-simple releae I've
>> experienced a FTBFS which is reproducible when building into a clean sid
>> chroot:
>>
>> Task :test class loader hash: 83f3637f6805a7b149525a93c5faad58
>> Task :test actions class loader hash: d883a18cf154fc57e90f4d3fa9e5588f
>> Executing task ':test' (up-to-date check took 0.041 secs) due to:
>>   No history is available.
>> Cannot nest operations in the same thread. Each nested operation must run in 
>> its own thread.
> 
> [...]
> 
> Hi,
> 
> thanks for reporting. This appears to be the same issue Olivier Sallou
> has mentioned on debian-java a few weeks ago. [1] This is a Gradle bug.
> I'm not exactly sure why it is surfacing now. I am in the process of
> updating Gradle to a newer version but it will take more time to finish
> the work.

I've just submitted another bug [1] against libgradle-core-java related
to the way it handles maven relocations.

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

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#882181: mockito: FTBFS - java.lang.UnsupportedOperationException: Cannot nest operations in the same thread

[Gilles Filippini]

Source: mockito
Version: 1.10.19-2
Severity: serious
Justification: FTBFS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

While testing a build of mockito against a new json-simple releae I've
experienced a FTBFS which is reproducible when building into a clean sid
chroot:

Task :test class loader hash: 83f3637f6805a7b149525a93c5faad58
Task :test actions class loader hash: d883a18cf154fc57e90f4d3fa9e5588f
Executing task ':test' (up-to-date check took 0.041 secs) due to:
  No history is available.
Cannot nest operations in the same thread. Each nested operation must run in 
its own thread.
java.lang.UnsupportedOperationException: Cannot nest operations in the same 
thread. Each nested operation must run in its own thread.
at 
org.gradle.internal.operations.DefaultBuildOperationWorkerRegistry.doStartOperation(DefaultBuildOperationWorkerRegistry.java:65)
at 
org.gradle.internal.operations.DefaultBuildOperationWorkerRegistry.access$400(DefaultBuildOperationWorkerRegistry.java:30)
at 
org.gradle.internal.operations.DefaultBuildOperationWorkerRegistry$DefaultOperation.operationStart(DefaultBuildOperationWorkerRegistry.java:163)
at 
org.gradle.api.internal.tasks.testing.worker.ForkingTestClassProcessor.processTestClass(ForkingTestClassProcessor.java:68)
at 
org.gradle.api.internal.tasks.testing.processors.RestartEveryNTestClassProcessor.processTestClass(RestartEveryNTestClassProcessor.java:47)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at 
org.gradle.internal.dispatch.FailureHandlingDispatch.dispatch(FailureHandlingDispatch.java:29)
at 
org.gradle.internal.dispatch.AsyncDispatch.dispatchMessages(AsyncDispatch.java:132)
at 
org.gradle.internal.dispatch.AsyncDispatch.access$000(AsyncDispatch.java:33)
at 
org.gradle.internal.dispatch.AsyncDispatch$1.run(AsyncDispatch.java:72)
at 
org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
at 
org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Cannot nest operations in the same thread. Each nested operation must run in 
its own thread.
java.lang.UnsupportedOperationException: Cannot nest operations in the same 
thread. Each nested operation must run in its own thread.
at 
org.gradle.internal.operations.DefaultBuildOperationWorkerRegistry.doStartOperation(DefaultBuildOperationWorkerRegistry.java:65)
at 
org.gradle.internal.operations.DefaultBuildOperationWorkerRegistry.access$400(DefaultBuildOperationWorkerRegistry.java:30)
at 
org.gradle.internal.operations.DefaultBuildOperationWorkerRegistry$DefaultOperation.operationStart(DefaultBuildOperationWorkerRegistry.java:163)
at 
org.gradle.api.internal.tasks.testing.worker.ForkingTestClassProcessor.processTestClass(ForkingTestClassProcessor.java:68)
at 
org.gradle.api.internal.tasks.testing.processors.RestartEveryNTestClassProcessor.processTestClass(RestartEveryNTestClassProcessor.java:47)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at 
org.gradle.internal.dispatch.FailureHandlingDispatch.dispatch(FailureHandlingDispatch.java:29)
at 
org.gradle.internal.dispatch.AsyncDispatch.dispatchMessages(AsyncDispatch.java:132)
at 
org.gradle.internal.dispatch.AsyncDispatch.access$000(AsyncDispatch.java:33)
at 
org.gradle.internal.dispatch.AsyncDispatch$1.run(AsyncDispatch.java:72)
at 
org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
at 
org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 

Bug#853351: libmstoolkit: diff for NMU version 77.0.0-1.1

[Gilles Filippini]

Control: tags 853351 + pending

Dear maintainer,

I've prepared an NMU for libmstoolkit (versioned as 77.0.0-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards,

_g.

diff -Nru libmstoolkit-77.0.0/debian/changelog 
libmstoolkit-77.0.0/debian/changelog
--- libmstoolkit-77.0.0/debian/changelog2015-09-25 15:20:00.0 
+0200
+++ libmstoolkit-77.0.0/debian/changelog2017-11-02 22:42:31.0 
+0100
@@ -1,3 +1,10 @@
+libmstoolkit (77.0.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * New patch gcc-7.patch: fix FTBFS with GCC-7 (closes: #853351)
+
+ -- Gilles Filippini <p...@debian.org>  Thu, 02 Nov 2017 22:42:31 +0100
+
 libmstoolkit (77.0.0-1) unstable; urgency=medium
 
   * New upstream version;
diff -Nru libmstoolkit-77.0.0/debian/patches/gcc-7.patch 
libmstoolkit-77.0.0/debian/patches/gcc-7.patch
--- libmstoolkit-77.0.0/debian/patches/gcc-7.patch  1970-01-01 
01:00:00.0 +0100
+++ libmstoolkit-77.0.0/debian/patches/gcc-7.patch  2017-10-12 
21:39:30.0 +0200
@@ -0,0 +1,26 @@
+Index: libmstoolkit/include/MSReader.h
+===
+--- libmstoolkit.orig/include/MSReader.h
 libmstoolkit/include/MSReader.h
+@@ -82,7 +82,7 @@ class MSReader {
+   void setPrecisionInt(int i);
+   void setPrecisionMZ(int i);
+   void writeFile(const char* c, bool text, MSObject& m);
+-  void writeFile(const char* c, MSFileFormat ff, MSObject& m, char* 
sha1Report='\0');
++  void writeFile(const char* c, MSFileFormat ff, MSObject& m, char* 
sha1Report=NULL);
+ 
+   bool readMSTFile(const char* c, bool text, Spectrum& s, int scNum=0);
+   bool readMZPFile(const char* c, Spectrum& s, int scNum=0);
+Index: libmstoolkit/src/MSToolkit/MSReader.cpp
+===
+--- libmstoolkit.orig/src/MSToolkit/MSReader.cpp
 libmstoolkit/src/MSToolkit/MSReader.cpp
+@@ -688,7 +688,7 @@ void MSReader::writeSqlite(const char* c
+   string instrumentType="=";
+   for(int i=0; i<16; i++)
+ {
+-  if(m.getHeader().header[i] != '\0')
++  if(m.getHeader().header[i] != NULL)
+   {
+ string headerLine = m.getHeader().header[i];
+ if(headerLine.find("CreationDate") != string::npos)
diff -Nru libmstoolkit-77.0.0/debian/patches/series 
libmstoolkit-77.0.0/debian/patches/series
--- libmstoolkit-77.0.0/debian/patches/series   2015-09-25 15:20:00.0 
+0200
+++ libmstoolkit-77.0.0/debian/patches/series   2017-10-12 21:39:30.0 
+0200
@@ -1,2 +1,3 @@
 makefile.patch
 
+gcc-7.patch

Bug#877075: sikulix: hard coded dependency on libopencv2.4-java

[Gilles Filippini]

Control: retitle -1 sikulix: hard coded dependency on libopencv3.2-java
Control: unblock 841733 by -1
Control: severity -1 normal

On Wed, 18 Oct 2017 01:16:53 +0200 Gilles Filippini <p...@debian.org> wrote:
> Mattia Rizzolo a écrit le 18/10/2017 à 01:11 :
> > On Wed, Oct 18, 2017 at 12:58:32AM +0200, Gilles Filippini wrote:
> >> On Tue, 17 Oct 2017 12:48:29 +0200 Mattia Rizzolo <mat...@debian.org> 
> >> wrote:
> >>> On Tue, Oct 17, 2017 at 10:26:11AM +0200, Gilles Filippini wrote:
> >>>> How about mavenizing OpenCV Java lib so that ${maven:Depends} would find
> >>>> out the right libopencvX.Y-java dependency?
> >>>
> >>> I'll happily accept patches for that.
> >>
> >> Attached.
> > 
> > Thank you!
> > 
> > It will definitely be part of the next upload, although I'd like to
> > avoid to do a 4th upload in just 3 days… OpenCV is not exactly light,
> > there are several architectures where it takes more than 12h to build.
> > Could you consider keeping the hardconded lib just a little longer and
> > bump the version?
> 
> Will do it by tomorrow.

Done.

_g.



signature.asc
Description: OpenPGP digital signature

Bug#877075: sikulix: hard coded dependency on libopencv2.4-java

[Gilles Filippini]

Mattia Rizzolo a écrit le 18/10/2017 à 01:11 :
> On Wed, Oct 18, 2017 at 12:58:32AM +0200, Gilles Filippini wrote:
>> On Tue, 17 Oct 2017 12:48:29 +0200 Mattia Rizzolo <mat...@debian.org> wrote:
>>> On Tue, Oct 17, 2017 at 10:26:11AM +0200, Gilles Filippini wrote:
>>>> How about mavenizing OpenCV Java lib so that ${maven:Depends} would find
>>>> out the right libopencvX.Y-java dependency?
>>>
>>> I'll happily accept patches for that.
>>
>> Attached.
> 
> Thank you!
> 
> It will definitely be part of the next upload, although I'd like to
> avoid to do a 4th upload in just 3 days… OpenCV is not exactly light,
> there are several architectures where it takes more than 12h to build.
> Could you consider keeping the hardconded lib just a little longer and
> bump the version?

Will do it by tomorrow.

> We will have to do another opencv transition soon after this one ended
> anyway (if we manage to get it build right the way we want it…), so we
> will have ways to employ this thing soon enough.

Thanks,

_g.




signature.asc
Description: OpenPGP digital signature

Bug#877075: sikulix: hard coded dependency on libopencv2.4-java

[Gilles Filippini]

Hi Mattia,

On Fri, 13 Oct 2017 19:40:47 +0200 Mattia Rizzolo  wrote:
> Control: severity -1 serious
> 
> On Thu, Sep 28, 2017 at 02:48:51PM +0200, Mattia Rizzolo wrote:
> > libsikulixapi-java has an hardcoded dependency on libopencv2.4-java.
> > Such dependency needs to be bumped for every OpenCV transition,
> > therefore requiring sourceful changes at every SONAME bump.
> 
> I'm about to upload opencv 3.2 to unstable and therefore starting the
> transition.  Thus, this bug is now RC.

How about mavenizing OpenCV Java lib so that ${maven:Depends} would find
out the right libopencvX.Y-java dependency?

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature