Bug#1067950: hdf5: diff for NMU version 1.10.10+repack-3.3
Andrey Rakhmatullin a écrit le 29/03/2024 à 12:26 : Package: hdf5 Version: 1.10.10+repack-3.2 Severity: normal Tags: patch pending Dear maintainer, I've prepared an NMU for hdf5 (versioned as 1.10.10+repack-3.3) and uploaded it to DELAYED/3. Please feel free to tell me if I should delay it longer. Regards. Please go ahead. Thks, _g.
Bug#1067118: nmu: hdf5_1.10.10+repack-3.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, During the ongoing 64 bit time_t transition it seems HDF5 should have been triggered *after* curl. See #1065331. As I understand it this should be fixed via the following binNMU request: nmu hdf5_1.10.10+repack-3.1 . ANY . unstable . -m "binNMU to depend on libcurl4t64" Thanks, _g. -BEGIN PGP SIGNATURE- iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAmX4o2YACgkQ7+hsbH/+ z4N+SQf/bgkEXassUkLIzCVBI5KnjM1uZXxp7tHgDsbPcx/Y769EZXUFSPLWaA3i 1E2ietil02tCgTa1njciUlsqPL6Din/vUbI7zX+Xjs1DfHVPleY56isPNfEQSVVE qcmQekQvozFzrs5kxhbpkW7ZG9oiMujKclwjS72K3bSbWdORYzkWVkVA8njyEzfk 5ays8yOyzAq0VJ+vshWy7l0EqTkoX/qLsIsyVUHTf6A6Ii/p5Pr37/bB3x11EsGx vF8fBHY6EvB77clpWVK6EmjiIMxZpZC0dr6wXS4BepOSAPkjoeUuec1KR/HHeFpQ FPDFnxXVf++eO5U/c1Q3F8wCQ4YWCw== =F5hi -END PGP SIGNATURE-
Bug#1065331: libhdf5-103-1t64: depends on libcurl4 instead of libcurl4t64
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
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#1053719: docker-compose exec does not output anything
Package: docker-compose Version: 1.29.2-3 Severity: important Dear Maintainer, I installed with apt-get install docker-compose docker-compose works well, except for "docker-compose exec" that does not return anything. In a bash shell, issue "docker-compose exec", it should return an error, because the command does not specify enough argument. Instead it returns nothing. (except for return code = 1) It should have returned something like this: ``` Execute a command in a running container Usage: exec [options] [-e KEY=VAL...] SERVICE COMMAND [ARGS...] Options: (...) ``` It also returns nothing on a complete command when an error occured. It works when the command is complete, and there is no error: For example, I use ``` docker-compose exec -u www-data web bash ``` With a complete and working `docker-compose.yml` file, services started, it works. But if there is an error (say the service "web" is not started, or there is no `docker-compose.yml`), nothing is shown. It renders base utilisation problematic, because we don't see the command fails, and it is not telling which is the problems, so it is hard to fix. I have this problem on all 3 of my debian-12 system -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages docker-compose depends on: ii python3 3.11.2-1+b1 ii python3-distro 1.8.0-1 ii python3-distutils 3.11.2-3 ii python3-docker 5.0.3-1 ii python3-dockerpty 0.4.1-4 ii python3-docopt 0.6.2-4.1 ii python3-dotenv 0.21.0-1 ii python3-jsonschema 4.10.3-1 ii python3-requests2.28.1+dfsg-1 ii python3-texttable 1.6.7-1 ii python3-websocket 1.2.3-1 ii python3-yaml6.0-3+b2 Versions of packages docker-compose recommends: ii docker.io 20.10.24+dfsg1-1+b3 docker-compose suggests no packages. -- no debconf information
Bug#1050952: r-bioc-rhdf5lib: autopkgtest regression: Expected '1.10.8', got '1.10.10'
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#1042822: med-fichier: Please upgrade to latest med-fichier version aka 5.0.0
Christophe Trophime a écrit le 31/08/2023 à 18:57 : - Original Message - From: "Gilles Filippini" To: "Christophe Trophime" , 1042...@bugs.debian.org Sent: Thursday, August 31, 2023 6:47:36 PM Subject: Re: Bug#1042822: med-fichier: Please upgrade to latest med-fichier version aka 5.0.0 Hi Christophe, Christophe Trophime a écrit le 01/08/2023 à 14:35 : Source: med-fichier Version: Please upgrade to 5.0.0 version Severity: normal Dear Maintainer, It would be great if med was upgraded to enable use a Salome 9.11 generated mesh files. Where is it downloadable from? From https://www.salome-platform.org/?page_id=2430. I take a quick look at the sources. It requires a more recent hdf5 version (1.12 if I rember correctly). This would be unfortunate. I didn't plan to ship HDF5 1.12 because this release is (or will soon be) retired by the HDF Group: https://portal.hdfgroup.org/display/support/Downloads I thought that Salome 9.11 was build on top of med 5 but this is not the case. The upgrade is not urgent.. Maybe we shall contact Salome upstream to now when they plan to upgrade to med 5 before moving on this issue. Best C Thx, _g.
Bug#1042822: med-fichier: Please upgrade to latest med-fichier version aka 5.0.0
Hi Christophe, Christophe Trophime a écrit le 01/08/2023 à 14:35 : Source: med-fichier Version: Please upgrade to 5.0.0 version Severity: normal Dear Maintainer, It would be great if med was upgraded to enable use a Salome 9.11 generated mesh files. Where is it downloadable from? Thx, _g.
Bug#1025492: openjdk-17: Upstream commit f71b21b causes segfault in hdf5 java test suite on arches i386 and mips64el
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
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
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#1023446: libhdf5-openmpi-dev: h5pcc configured as static build
Hi Drew, Drew Parsons a écrit le 15/11/2022 à 16:28 : h5py is building fine against the shared libraries with HDF5_USE_SHLIB=yes, but leaves a question about rpath. Notice that `h5pcc --showconfig -shlib` includes "-L/usr/lib/x86_64-linux-gnu/hdf5/openmpi -lhdf5_hl -lhdf5 -Wl,-rpath -Wl,/usr/lib/x86_64-linux-gnu/hdf5/openmpi" The h5py python extensions get linked with this, such the h5py .so files are generated with NEEDED libhdf5_openmpi.so.103 RUNPATH /usr/lib/x86_64-linux-gnu/hdf5/openmpi In normal package policy we try to remove RUNPATH, and in the case of the hdf5 libraries libhdf5_openmpi.so.103 is available in the standard library path at /usr/lib/x86_64-linux-gnu/. In fact libhdf5_openmpi.so.103 is not even found in /usr/lib/x86_64-linux-gnu/hdf5/openmpi (instead libhdf5.so is found there as a symlink to ../../libhdf5_openmpi.so). As far as I can tell, the -rpath entry in the h5pcc configuration is redundant, possibly even wrong (since the linked library is libhdf5_openmpi.so.103, not the more general libhdf5.so) Should rpath be removed from the h5pcc shlib configuration? I've just uploaded hdf5 1.10.8+repack-2 which should fix this issue. Best, _g.
Bug#1023446: libhdf5-openmpi-dev: h5pcc configured as static build
Hi Drew, Drew Parsons a écrit le 04/11/2022 à 11:27 : Package: libhdf5-openmpi-dev Version: 1.10.8+repack-1 Severity: important Control: block 1020054 by -1 h5pcc is showing an unexpected default configuration: $ h5pcc --showconfig gcc -I/usr/include/hdf5/openmpi -L/usr/lib/x86_64-linux-gnu/hdf5/openmpi /usr/lib/x86_64-linux-gnu/hdf5/openmpi/libhdf5_hl.a /usr/lib/x86_64-linux-gnu/hdf5/openmpi/libhdf5.a -lcrypto -lcurl -lsz -lz -ldl -lm -Wl,-rpath -Wl,/usr/lib/x86_64-linux-gnu/hdf5/openmpi -I/usr/lib/x86_64-linux-gnu/openmpi/include -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi -L/usr/lib/x86_64-linux-gnu/openmpi/lib -lmpi Note how it includes static linking to libhdf5_hl.a and libhdf5.a This is the expected behavior as documented by upstream: -shlib Compile with shared HDF5 libraries [default for hdf5 built without static libraries] -noshlib Compile with static HDF5 libraries [default for hdf5 built with static libraries] I would expect the default configuration to use dynamic linking with shared libraries, as in $ h5pcc --showconfig -shlib gcc -I/usr/include/hdf5/openmpi -L/usr/lib/x86_64-linux-gnu/hdf5/openmpi -lhdf5_hl -lhdf5 -lcrypto -lcurl -lsz -lz -ldl -lm -Wl,-rpath -Wl,/usr/lib/x86_64-linux-gnu/hdf5/openmpi As far as I can tell, the default static linking is causing the RC Bug#1020054 reported against h5py. Could be fixed using `HDF5_USE_SHLIB=yes`: PYBUILD_NAME=$(PYBUILD_NAME_MPI) CC=h5pcc HDF5_USE_SHLIB=yes HDF5_MPI=ON HDF5_PKGCONFIG_NAME=hdf5-mpi H5PY_SYSTEM_LZF=1 dh_auto_build -D $(BUILD_DIR_MPI) Should the default configuration of h5pcc be changed to confirm with the -shlib configuration? I don't think so since the current behavior is the documented one. Best, _g.
Bug#1017997: hdf5 ftbfs on s390x
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#1011373: jhdf: FTBFS against hdf5 1.12.2 currently in experimental
Source: jhdf
Version: 2.11.0+dfsg-5
Severity: important
Tags: ftbfs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
While rebuilding jhdf against hdf5 1.12.2 in experimental, il failed with:
h5Constants.c: In function ‘Java_ncsa_hdf_hdf5lib_HDF5Constants_H5I_1REFERENCE’:
h5Constants.c:322:109: error: ‘H5I_REFERENCE’ undeclared (first use in this
function); did you mean ‘H5T_REFERENCE’?
322 | JNIEXPORT jint JNICALL
Java_ncsa_hdf_hdf5lib_HDF5Constants_H5I_1REFERENCE(JNIEnv *env, jclass cls) {
return H5I_REFERENCE; }
|
^
|
H5T_REFERENCE
h5Constants.c:322:109: note: each undeclared identifier is reported only once
for each function it appears in
make[4]: *** [: h5Constants.o] Error 1
make[4]: Leaving directory '/<>/native/hdf5lib'
make[3]: *** [Makefile:31: do-hdf5lib] Error 2
make[3]: Leaving directory '/<>/native'
make[2]: *** [Makefile:28: hdf5lib] Error 2
make[2]: Leaving directory '/<>/native'
make[1]: *** [Makefile:189: natives] Error 2
make[1]: Leaving directory '/<>'
make: *** [/usr/share/cdbs/1/class/makefile.mk:77: debian/stamp-makefile-build]
Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
Please find attached the full build log.
Best,
_g.
-BEGIN PGP SIGNATURE-
iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAmKIrMoACgkQ7+hsbH/+
z4Nuogf8DMvBFvVoANVNV/3vu6S1CZwTc+GaScHVfFMK+BOuM7dlQJHojzf5e0vP
wlpBPsPGelEn4WDEibjPuk7FLAu84WxEemj+XJzKdkphKIXzLzEVeUxA310lpk3x
umTBvx5OkjY1eJgrwu43UAo0MzSgu8VzqBnEfTlEEX4RHDAsuBhmpDtOH1bO/u3E
9CF5nEOBzB9y2wZxENsZGhyNiXGyFvI+Yh8Q794VvoinOkqNsFJq2gnHBNHM+zRf
SUpiBWdhvqe3gX65G3UHacGHXsLPnxqOE6cgkTW9ruX8vs6SJeynMpMarBjted0H
Qr6a0UvSBZq6TycNjMpLplXevl7cbA==
=TPYn
-END PGP SIGNATURE-
jhdf_2.11.0+dfsg-5_amd64.build.gz
Description: application/gzip
Bug#1010202: MatIO test failures against HDF5 1.12.0
Hi, Thomas Beutlich a écrit le 19/05/2022 à 22:36 : Hi Sébastien, seems I was right (and somehow remembered correctly) with my guess of some concurrency issue when running the testsuite. For my own test setup I chose to go with serial execution of the testsuite (if matio is built with libhdf5 support). Best regards, Thomas Am 19.05.2022 um 10:06 schrieb Sébastien Villemot: Hi Thomas, It turns out that running the testsuite sequentially fixes the problem, as explained by Gilles Filippini (who maintains HDF5 in Debian), see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010202#25 Where do we go from here? We now have a workaround, but that’s hardly satisfactory. If possible, please reply by putting p...@debian.org and 1010...@bugs.debian.org in CC, so that this it is properly tracked in our system. Best regards, Le mardi 03 mai 2022 à 20:59 +0200, Thomas Beutlich a écrit : Hi Sébastien, it is the same test case that fails for three different HDF5-based MAT files. My guess is some concurrency issue of the hdf5lib. Can you please try: * to run the testsuite sequentially * to not build libhdf with --enable-parallel, i.e. to have the serial version of hdf5lib * set env var HDF5_USE_FILE_LOCKING=FALSE Setting the above environment variable fixes the problem when running the testsuite in parallel mode. Best, _g.
Bug#1010202: libmatio: FTBFS against hdf5 1.12.0 currently in experimental - 3 failed tests
Hi Sébastien, Gilles Filippini a écrit le 02/05/2022 à 11:04 : Hi, Gilles Filippini a écrit le 29/04/2022 à 14:10 : Hi Sébastien, Sébastien Villemot a écrit le 29/04/2022 à 11:45 : Hi Gilles, Le mardi 26 avril 2022 à 10:38 +0200, Gilles Filippini a écrit : Source: libmatio Version: 1.5.23-1 Severity: important Tags: ftbfs While rebuilding libmatio 1.5.23 against hdf5 1.12.0, 3 testcases failed with: […] I had an exchange with upstream, who says that libmatio 1.5.23 should pass all tests against hdf5 1.12.2. Is there any reason why you’re sticking to hdf5 1.12.0 instead of the latest stable release 1.12.2? No, no reason. I wanted to transition 1.12.0 before switching to 1.12.2, but the other way should be fine as well. I'll give it a try. I've just tested a rebuild against HDF5 1.12.2, and the same 3 tests fail mosly the same way: 2272. mat73_compressed_read_le.at:475: testing Read directory ... ./mat73_compressed_read_le.at:478: cp $srcdir/results/dir_le.out expout $builddir/test_mat directory $srcdir/datasets/matio_test_cases_compressed_hdf_le.mat --- /dev/null 2022-04-25 15:38:39.0 + +++ /<>/test/testsuite.dir/at-groups/2272/stderr 2022-05-02 08:55:13.515220334 + @@ -0,0 +1,40 @@ +-E- test_mat: HDF5 error #000 in H5Fopen() + file : ../../../src/H5F.c:620 + major: File accessibility + minor: Unable to open file +-E- test_mat: HDF5 error #001 in H5VL_file_open() + file : ../../../src/H5VLcallback.c:3501 + major: Virtual Object Layer + minor: Iteration failed +-E- test_mat: HDF5 error #002 in H5PL__path_table_iterate() + file : ../../../src/H5PLpath.c:578 + major: Plugin for dynamically loaded library + minor: Iteration failed +-E- test_mat: HDF5 error #003 in H5PL__path_table_iterate_process_path() + file : ../../../src/H5PLpath.c:620 + major: Plugin for dynamically loaded library + minor: Can't open directory or file +-E- test_mat: HDF5 error #004 in H5VL__file_open() + file : ../../../src/H5VLcallback.c:3351 + major: Virtual Object Layer + minor: Can't open object +-E- test_mat: HDF5 error #005 in H5VL__native_file_open() + file : ../../../src/H5VLnative_file.c:97 + major: File accessibility + minor: Unable to open file +-E- test_mat: HDF5 error #006 in H5F_open() + file : ../../../src/H5Fint.c:1898 + major: File accessibility + minor: Unable to lock file +-E- test_mat: HDF5 error #007 in H5FD_lock() + file : ../../../src/H5FD.c:1625 + major: Virtual File Layer + minor: Unable to lock file +-E- test_mat: HDF5 error #008 in H5FD__sec2_lock() + file : ../../../src/H5FDsec2.c:1002 + major: Virtual File Layer + minor: Unable to lock file +-E- test_mat: HDF5 error #000 in H5Fclose() + file : ../../../src/H5F.c:707 + major: Invalid arguments to routine + minor: Inappropriate type Running each failed test alone doesn't fail. Hence I've just tried adding: override_dh_auto_test: dh_auto_test --no-parallel and tada! no more failure. Best, _g.
Bug#1010202: libmatio: FTBFS against hdf5 1.12.0 currently in experimental - 3 failed tests
Hi, Gilles Filippini a écrit le 29/04/2022 à 14:10 : Hi Sébastien, Sébastien Villemot a écrit le 29/04/2022 à 11:45 : Hi Gilles, Le mardi 26 avril 2022 à 10:38 +0200, Gilles Filippini a écrit : Source: libmatio Version: 1.5.23-1 Severity: important Tags: ftbfs While rebuilding libmatio 1.5.23 against hdf5 1.12.0, 3 testcases failed with: […] I had an exchange with upstream, who says that libmatio 1.5.23 should pass all tests against hdf5 1.12.2. Is there any reason why you’re sticking to hdf5 1.12.0 instead of the latest stable release 1.12.2? No, no reason. I wanted to transition 1.12.0 before switching to 1.12.2, but the other way should be fine as well. I'll give it a try. I've just tested a rebuild against HDF5 1.12.2, and the same 3 tests fail mosly the same way: 2272. mat73_compressed_read_le.at:475: testing Read directory ... ./mat73_compressed_read_le.at:478: cp $srcdir/results/dir_le.out expout $builddir/test_mat directory $srcdir/datasets/matio_test_cases_compressed_hdf_le.mat --- /dev/null 2022-04-25 15:38:39.0 + +++ /<>/test/testsuite.dir/at-groups/2272/stderr 2022-05-02 08:55:13.515220334 + @@ -0,0 +1,40 @@ +-E- test_mat: HDF5 error #000 in H5Fopen() + file : ../../../src/H5F.c:620 + major: File accessibility + minor: Unable to open file +-E- test_mat: HDF5 error #001 in H5VL_file_open() + file : ../../../src/H5VLcallback.c:3501 + major: Virtual Object Layer + minor: Iteration failed +-E- test_mat: HDF5 error #002 in H5PL__path_table_iterate() + file : ../../../src/H5PLpath.c:578 + major: Plugin for dynamically loaded library + minor: Iteration failed +-E- test_mat: HDF5 error #003 in H5PL__path_table_iterate_process_path() + file : ../../../src/H5PLpath.c:620 + major: Plugin for dynamically loaded library + minor: Can't open directory or file +-E- test_mat: HDF5 error #004 in H5VL__file_open() + file : ../../../src/H5VLcallback.c:3351 + major: Virtual Object Layer + minor: Can't open object +-E- test_mat: HDF5 error #005 in H5VL__native_file_open() + file : ../../../src/H5VLnative_file.c:97 + major: File accessibility + minor: Unable to open file +-E- test_mat: HDF5 error #006 in H5F_open() + file : ../../../src/H5Fint.c:1898 + major: File accessibility + minor: Unable to lock file +-E- test_mat: HDF5 error #007 in H5FD_lock() + file : ../../../src/H5FD.c:1625 + major: Virtual File Layer + minor: Unable to lock file +-E- test_mat: HDF5 error #008 in H5FD__sec2_lock() + file : ../../../src/H5FDsec2.c:1002 + major: Virtual File Layer + minor: Unable to lock file +-E- test_mat: HDF5 error #000 in H5Fclose() + file : ../../../src/H5F.c:707 + major: Invalid arguments to routine + minor: Inappropriate type Best, _g.
Bug#1010202: libmatio: FTBFS against hdf5 1.12.0 currently in experimental - 3 failed tests
Hi Sébastien, Sébastien Villemot a écrit le 29/04/2022 à 11:45 : Hi Gilles, Le mardi 26 avril 2022 à 10:38 +0200, Gilles Filippini a écrit : Source: libmatio Version: 1.5.23-1 Severity: important Tags: ftbfs While rebuilding libmatio 1.5.23 against hdf5 1.12.0, 3 testcases failed with: […] I had an exchange with upstream, who says that libmatio 1.5.23 should pass all tests against hdf5 1.12.2. Is there any reason why you’re sticking to hdf5 1.12.0 instead of the latest stable release 1.12.2? No, no reason. I wanted to transition 1.12.0 before switching to 1.12.2, but the other way should be fine as well. I'll give it a try. Thanks, _g.
Bug#892058: debian-keyring: please automatically send reminder emails to people whose keys will expire soon
Thanks for the ping! This is very much appreciated. Best, _g.
Bug#998383: nheko: nheko/{armel,armhf} has unsatisfiable dependency
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#987584: docker.io: docker-proxy does not bind to ipv6 "all network" address
On Thu, 29 Apr 2021 01:54:56 +0800 Shengjing Zhu wrote: On Mon, Apr 26, 2021 at 1:15 PM Jérémy Viès wrote: > > Package: docker.io > Version: 20.10.5+dfsg1-1+b1 > Severity: important > Tags: ipv6 > > Dear Maintainer, > > >* What led up to the situation? > I'm trying to expose some web app to the ipv6 Internet ! >* What exactly did you do (or not do) that was effective (or > ineffective)? > I enabled ipv6 support in /etc/docker/daemon.json as explained in docker doc. >* What was the outcome of this action? > Exposed ports are only on ipv4 even if ipv6 is enabled in docker configuration. >* What outcome did you expect instead? > The binding shall be done on both ipv4 and ipv6 networks. > > The issue is confirmed upstream : https://github.com/moby/moby/issues/42059 > It is due to https://github.com/moby/libnetwork/issues/2607 > It seems to be fixed already, and packaged in version 20.10.6 that has been > just released. While 20.10.6 fixes this issue, it introduces other regressions, https://github.com/moby/moby/issues/42288 Which is now fixed in 20.10.7. https://github.com/moby/moby/issues/42288#issuecomment-853505550 _g.
Bug#995594: libhdf5[-openmpi]-dev: missing Depends: libcurl-dev
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
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
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
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#993825: buster-pu: package hdf5/1.10.6+repack-4+deb11u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi Release team,
I'd like to upload a fix for hdf5 1.10.6+repack-4 into stable.
[ Reason ]
This is a fix for RC bug #992068 which makes libhdf5-mpich-dev failing
a piuparts upgrade test.
[ Impact ]
No impact but fixing the bug.
[ Tests ]
Piuparts upgrade test of libhdf5-mpich-dev on the upgrade path
squeeze -> wheezy -> jessie -> stretch -> buster -> bullseye
[ Risks ]
None.
[ Checklist ]
[X] *all* changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in (old)stable
[ ] the issue is verified as fixed in unstable
Couldn't check that myself because piuparts fails to start from any
suite before stretch on my box.
[ Changes ]
I followed the recommendation from the bug submitter:
> 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).
Thanks,
_g.
-BEGIN PGP SIGNATURE-
iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAmE2nEIACgkQ7+hsbH/+
z4Phpwf/XkIdQQfZHt03cw9SPi6xpuavElt2CyHQ3z36yl/tS2XY9YgI3uAUucSh
1lL7pizC4VeSJNDApEGlSQwi4VDvlKuoANGFP3YQjhyogeZoqnfloxqHslYP8gAL
zqSB0nqwSKzu+FEy4QTEddbJUcac7tbWj0szYosiT+ncDxSzH2hystSsV26W1HMu
fqgCTu2hwV3UWoAMruaiRBqrlIIf4Q801dCozFr5Wyz+4CqJNdJN2gmDnezcfF3I
UwUf/h3EMFMqds7X1RFXzkhWKI+DiLRAKh+S7sB2q+gzxWRxTOQOL0BOtk6Lw/7b
H0QMwMmT1sgVVRqSoEokl/pg1OhgyQ==
=2/US
-END PGP SIGNATURE-
diff -Nru hdf5-1.10.6+repack/debian/changelog
hdf5-1.10.6+repack/debian/changelog
--- hdf5-1.10.6+repack/debian/changelog 2021-06-16 23:57:23.0 +0200
+++ hdf5-1.10.6+repack/debian/changelog 2021-08-15 15:56:44.0 +0200
@@ -1,3 +1,11 @@
+hdf5 (1.10.6+repack-4+deb11u1) bullseye; urgency=medium
+
+ [ Andreas Beckmann ]
+ * libhdf5-mpich-dev: bump libmpich-dev dependency to (>= 3.3-3~) (Closes:
+#992068)
+
+ -- Gilles Filippini Sun, 15 Aug 2021 15:56:44 +0200
+
hdf5 (1.10.6+repack-4) unstable; urgency=medium
* Revert support for read-only S3 virtual file driver, as it introduced
diff -Nru hdf5-1.10.6+repack/debian/control hdf5-1.10.6+repack/debian/control
--- hdf5-1.10.6+repack/debian/control 2021-06-16 23:57:23.0 +0200
+++ hdf5-1.10.6+repack/debian/control 2021-08-15 15:56:44.0 +0200
@@ -480,7 +480,7 @@
zlib1g-dev,
libaec-dev,
libjpeg-dev,
- libmpich-dev,
+ libmpich-dev (>= 3.3-3~),
${misc:Depends}
Suggests: libhdf5-doc
Breaks: libhdf5-mpi-dev (= 1.10.6+repack-1~exp4)
diff -Nru hdf5-1.10.6+repack/debian/control.in
hdf5-1.10.6+repack/debian/control.in
--- hdf5-1.10.6+repack/debian/control.in2021-06-16 23:57:23.0
+0200
+++ hdf5-1.10.6+repack/debian/control.in2021-08-11 16:32:44.0
+0200
@@ -480,7 +480,7 @@
zlib1g-dev,
libaec-dev,
libjpeg-dev,
- libmpich-dev,
+ libmpich-dev (>= 3.3-3~),
${misc:Depends}
Suggests: libhdf5-doc
Breaks: libhdf5-mpi-dev (= 1.10.6+repack-1~exp4)
Bug#992068: libhdf5-mpich-dev: please bump libmpich-dev dependency to (>= 3.3-3~)
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
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
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
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
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
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#983660: Curl don't include zstd supportTR: Curl don't include zstd support
Package: curl Version: 7.74.0 When I invoke `curl --version', it list feature included on the curl library. Brotli compression library is included, but not Zstd. Both compression library are included is the same way . See https://daniel.haxx.se/blog/2020/08/19/curl-7-72-0-more-compression/ for zstd added in feature. Here is a transcript on recent build of Debian 11: gvollant@debian11:~/soft_amabis$ lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux bullseye/sid Release:testing Codename: bullseye gvollant@debian11:~/soft_amabis$ curl --version curl 7.74.0 (x86_64-pc-linux-gnu) libcurl/7.74.0 OpenSSL/1.1.1j zlib/1.2.11 brotli/1.0.9 libidn2/2.3.0 libpsl/0.21.0 (+libidn2/2.3.0) libssh2/1.9.0 nghttp2/1.43.0 librtmp/2.3 Release-Date: 2020-12-09 Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp Features: alt-svc AsynchDNS brotli GSS-API HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets See transcript on manjaro Linux: [gillesvollant@gillesvollant-manj ~]$ lsb_release -a LSB Version:n/a Distributor ID: ManjaroLinux Description:Manjaro Linux Release:20.2.1 Codename: Nibia [gillesvollant@gillesvollant-manj ~]$ curl --version curl 7.75.0 (x86_64-pc-linux-gnu) libcurl/7.75.0 OpenSSL/1.1.1i zlib/1.2.11 zstd/1.4.8 libidn2/2.3.0 libpsl/0.21.1 (+libidn2/2.3.0) libssh2/1.9.0 nghttp2/1.41.0 Release-Date: 2021-02-03 Protocols: dict file ftp ftps gopher gophers http https imap imaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp Features: alt-svc AsynchDNS GSS-API HTTP2 HTTPS-proxy IDN IPv6 I suggest adding zstd library support on curl package. I am using Debian GNU/Linux 2.2, kernel 2.2.17-pre-patch-13 and libc6 2.1.3-10.
Bug#968559: libhdf5-openmpi-dev: hdf5-mpi.pc alternative sometimes goes missing
Drew Parsons a écrit le 08/11/2020 à 05:17 : > Probably we should check with the update-alternatives developers first, > they may have some ideas. Certainly they should be able to explain > exactly why installing openmpi-bin or mpich causes the hdf5-mpi > alternative to disappear. Would you mind opening these discussions? Thanks, _g. signature.asc Description: OpenPGP digital signature
Bug#968559: libhdf5-openmpi-dev: hdf5-mpi.pc alternative sometimes goes missing
Gilles Filippini a écrit le 07/11/2020 à 19:36 : > Drew Parsons a écrit le 06/11/2020 à 04:02 : >> On 2020-11-06 02:09, Gilles Filippini wrote: >>>> >>>> But we should document (or fix if possible) that this alternatives >>>> mechanism is a little fragile, and sometimes the link needs to be >>>> refresh with >>>> sudo dpkg-reconfigure libhdf5-openmpi-dev >>>> >>>> What I mean is that sometimes the link seem to just disappear, so we get >>>> $ pkg-config --libs hdf5-mpi >>>> Package hdf5-mpi was not found in the pkg-config search path. >> ... >>> >>> Do you have a scenario leading to this alternative disparition? >>> >> >> >> It's not completely clear to me. But my suspicion is that it happens >> when there is an upgrade to openmpi. Evidently then hdf5 needs to update >> its alternatives against the updated openmpi. >> >> It's a little strange though, since a simple openmpi update is not an >> ABI update. The alternatives links would be the same after running >> dpkg-reconfigure libhdf5-openmpi-dev. Not obvious why an openmpi update >> would cause them to disappear. > > After a test into a clean chroot I can now confirm this hypothesis. The loss of the alternative is easily triggered by the reinstallation of openmpi-bin: # pkg-config --libs hdf5-mpi -L/usr/lib/x86_64-linux-gnu/hdf5/openmpi -L/usr/lib/x86_64-linux-gnu/openmpi/lib -lhdf5 -lmpi # apt-get install --reinstall ipenmpi-bin Reading package lists... Done Building dependency tree Reading state information... Done E: Unable to locate package ipenmpi-bin (unstable-amd64-sbuild)root@pinibrem15:/tmp# pkg-config --libs hdf5-mpi -L/usr/lib/x86_64-linux-gnu/hdf5/openmpi -L/usr/lib/x86_64-linux-gnu/openmpi/lib -lhdf5 -lmpi (unstable-amd64-sbuild)root@pinibrem15:/tmp# apt-get install --reinstall openmpi-bin Reading package lists... Done Building dependency tree Reading state information... Done 0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 3 not upgraded. Need to get 0 B/127 kB of archives. After this operation, 0 B of additional disk space will be used. debconf: delaying package configuration, since apt-utils is not installed (Reading database ... 18500 files and directories currently installed.) Preparing to unpack .../openmpi-bin_4.0.5-7_amd64.deb ... Unpacking openmpi-bin (4.0.5-7) over (4.0.5-7) ... Setting up openmpi-bin (4.0.5-7) ... update-alternatives: warning: forcing reinstallation of alternative /usr/bin/mpicc.openmpi because link group mpi is broken # pkg-config --libs hdf5-mpi Package hdf5-mpi was not found in the pkg-config search path. Perhaps you should add the directory containing `hdf5-mpi.pc' to the PKG_CONFIG_PATH environment variable No package 'hdf5-mpi' found It happens when reinstalling mpich as well, if the mpi alternative was previously set to mpich. I have no idea how to fix it, other than asking openmpi and mpich maintainers to take care of the hdf5-mpi.pc slave alternative when it exists. What do you think? Thanks, Note the warning notice above. Honestly I have no idea how this could be fixed. signature.asc Description: OpenPGP digital signature
Bug#968559: libhdf5-openmpi-dev: hdf5-mpi.pc alternative sometimes goes missing
Drew Parsons a écrit le 06/11/2020 à 04:02 : > On 2020-11-06 02:09, Gilles Filippini wrote: >>> >>> But we should document (or fix if possible) that this alternatives >>> mechanism is a little fragile, and sometimes the link needs to be >>> refresh with >>> sudo dpkg-reconfigure libhdf5-openmpi-dev >>> >>> What I mean is that sometimes the link seem to just disappear, so we get >>> $ pkg-config --libs hdf5-mpi >>> Package hdf5-mpi was not found in the pkg-config search path. > ... >> >> Do you have a scenario leading to this alternative disparition? >> > > > It's not completely clear to me. But my suspicion is that it happens > when there is an upgrade to openmpi. Evidently then hdf5 needs to update > its alternatives against the updated openmpi. > > It's a little strange though, since a simple openmpi update is not an > ABI update. The alternatives links would be the same after running > dpkg-reconfigure libhdf5-openmpi-dev. Not obvious why an openmpi update > would cause them to disappear. After a test into a clean chroot I can now confirm this hypothesis. Thanks, _g. signature.asc Description: OpenPGP digital signature
Bug#968559: libhdf5-openmpi-dev: hdf5-mpi.pc alternative sometimes goes missing
Control: tag -1 moreinfo Hi Drew, On Mon, 17 Aug 2020 19:23:05 +0800 Drew Parsons wrote: > Package: libhdf5-openmpi-dev > Version: 1.10.6+repack-2 > Severity: normal > > We've set up libhdf5-openmpi-dev (and libhdf5-mpich-dev) to use the > alternatives mechanism to configure a symlink from a generic pkgconfig > file hdf5-mpi.pc to the specific hdf5-openmpi.pc (or hdf5-mpich.pc). > This allows client programs to get libs with 'pkg-config --libs hdf5-mpi' > without needing to know which specific MPI implementation is being > used. > > It's a good and useful service, I think we should keep it. > > But we should document (or fix if possible) that this alternatives > mechanism is a little fragile, and sometimes the link needs to be > refresh with > sudo dpkg-reconfigure libhdf5-openmpi-dev > > What I mean is that sometimes the link seem to just disappear, so we get > $ pkg-config --libs hdf5-mpi > Package hdf5-mpi was not found in the pkg-config search path. > Perhaps you should add the directory containing `hdf5-mpi.pc' > to the PKG_CONFIG_PATH environment variable > No package 'hdf5-mpi' found > > It gets restored by 'dpkg-reconfigure libhdf5-openmpi-dev' > (update-alternative --config hdf5-mpi would also enable it to be reset). > > I'm not sure why exactly the link is being lost or if it's feasible to > make the mechanism for it more robust. I presume it happens when > openmpi gets updated (e.g. recently updated to openmpi 4.0.4). > libhdf5-openmpi-dev.postinst of course is setting the alternatives > link, though I don't understand why the link would be lost just > because openmpi got upgraded. > > Filing this bug so we can document and keep watch on the problem. > Again, the workaround is to run > > sudo dpkg-reconfigure libhdf5-openmpi-dev > > (or dpkg-reconfigure libhdf5-mpich-dev) Do you have a scenario leading to this alternative disparition? Thanks, _g. signature.asc Description: OpenPGP digital signature
Bug#958174: hdf5: please add the hdf5plugins
Gilles Filippini a écrit le 24/04/2020 à 10:03 : > picca a écrit le 22/04/2020 à 16:07 : >> I found also this link with all the filter available around hdf5. >> so I tought that the hdfgroup would provide a tar.gz with all of them >> pre packaged in source forme. >> >> since you are in charge of the hdf5 package, I tought that you have a >> privilegiate contact with them. >> >> https://portal.hdfgroup.org/display/support/HDF5+Plugins > Not so privileged, but I've asked them anyway. Waiting for the answer. Here it is (I forgot to forward it): > I received a reply regarding the hdf5plugin software. The issue is that > the source code is not in a state where any user can build it as is. > Right now the developer has to make certain changes in order for it > to build. > > We do plan to make it available from the web pages once it has been > cleaned up. Best, _g. signature.asc Description: OpenPGP digital signature
Bug#973261: libhdf5-openmpi-dev: installing requires /proc being mounted
Gilles Filippini a écrit le 31/10/2020 à 15:11 :
> Hi Josh,
>
> Johannes 'josch' Schauer a écrit le 27/10/2020 à 18:45 :
>> Package: libhdf5-openmpi-dev
>> Version: 1.10.6+repack-2
>> Severity: wishlist
>>
>> Hi,
>>
>> when installing libhdf5-openmpi-dev in a chroot that doesn't have /proc
>> mounted, one will get the following error:
>>
>> Setting up libhdf5-openmpi-dev (1.10.6+repack-2) ...
>> /var/lib/dpkg/info/libhdf5-openmpi-dev.postinst: line 56: /dev/fd/63: No
>> such file or directory
>> dpkg: error processing package libhdf5-openmpi-dev (--configure):
>> installed libhdf5-openmpi-dev package post-installation script subprocess
>> returned error exit status 1
>>
>> The problem is, that the postinst script uses the bash-feature to write:
>>
>> while read x; do ... done < <(cmd2 args ...)
>>
>> Fortunately, these instances can easily be rewritten as:
>>
>> cmd2 args | while read x; do ... done
>>
>> Please consider making this change.
>
> Unfortunately it doesn't work this way. Consider this test script:
>
> $ cat test.sh
> #!/bin/bash
> declare -A foo bar
> while read var; do
> foo["$var"]="$var"
> done < <(seq 1 3)
> seq 1 3 | while read var; do
> bar["$var"]="$var"
> done
> echo "foo=${foo[@]}"
> echo "bar=${bar[@]}"
>
> $ ./test.sh
> foo=3 2 1
> bar=
>
> Using a pipe makes variable assignments into the while loop inefficient.
> That's why I had to use the process substitution syntax.
>
> Any other idea?
I've come up to this solution:
function read_alt_slaves () {
local -n slaves=$1
set -- $(echo "$2" | sed -n '/Slaves:/{: while;n;s/^ //;T end;p;b
while;: end;q}') while [ -n "$1" ]; do
slaves["$1"]="$2"
shift 2
done
}
...
declare -A slave_links slave_targets
read_alt_slaves slave_links "$mpi_alt_sig"
read_alt_slaves slave_targets "$mpi_alt_impl"
Can you confirm it would work with no /proc?
_g.
signature.asc
Description: OpenPGP digital signature
Bug#973261: libhdf5-openmpi-dev: installing requires /proc being mounted
Hi Josh,
Johannes 'josch' Schauer a écrit le 27/10/2020 à 18:45 :
> Package: libhdf5-openmpi-dev
> Version: 1.10.6+repack-2
> Severity: wishlist
>
> Hi,
>
> when installing libhdf5-openmpi-dev in a chroot that doesn't have /proc
> mounted, one will get the following error:
>
> Setting up libhdf5-openmpi-dev (1.10.6+repack-2) ...
> /var/lib/dpkg/info/libhdf5-openmpi-dev.postinst: line 56: /dev/fd/63: No such
> file or directory
> dpkg: error processing package libhdf5-openmpi-dev (--configure):
> installed libhdf5-openmpi-dev package post-installation script subprocess
> returned error exit status 1
>
> The problem is, that the postinst script uses the bash-feature to write:
>
> while read x; do ... done < <(cmd2 args ...)
>
> Fortunately, these instances can easily be rewritten as:
>
> cmd2 args | while read x; do ... done
>
> Please consider making this change.
Unfortunately it doesn't work this way. Consider this test script:
$ cat test.sh
#!/bin/bash
declare -A foo bar
while read var; do
foo["$var"]="$var"
done < <(seq 1 3)
seq 1 3 | while read var; do
bar["$var"]="$var"
done
echo "foo=${foo[@]}"
echo "bar=${bar[@]}"
$ ./test.sh
foo=3 2 1
bar=
Using a pipe makes variable assignments into the while loop inefficient.
That's why I had to use the process substitution syntax.
Any other idea?
Thanks,
_g.
signature.asc
Description: OpenPGP digital signature
Bug#969633: transition: json-simple
Hi Emilio, Emilio Pozuelo Monfort a écrit le 20/09/2020 à 18:50 : > On 06/09/2020 13:38, Gilles Filippini wrote: >> Emilio Pozuelo Monfort a écrit le 06/09/2020 à 12:19 : >>> On 06/09/2020 11:53, Gilles Filippini wrote: >>>> Package: release.debian.org >>>> Severity: normal >>>> User: release.debian@packages.debian.org >>>> Usertags: transition >>>> >>>> Hi, >>>> >>>> I'd like to transition json-simple 3.1.1 surrently sitting into >>>> experimental. >>>> The name of the library doens't change, but reverse dependencies need a >>>> binnmu. >>> >>> Why is that? >> >> Upstream removed an API that was deprecated long ago and introduced a >> few backward incompatible changes. > > Then it needs a SONAME bump. There is no such thing in java. I asked the question on the debian-java list whether to change the binary package's name and it was answered that it should be avoidable [1]. I eventually chose not to change it because there are few reverse dependencies. [1] https://lists.debian.org/debian-java/2020/05/msg00025.html What do you think? _g. signature.asc Description: OpenPGP digital signature
Bug#969633: transition: json-simple
Emilio Pozuelo Monfort a écrit le 06/09/2020 à 12:19 : > On 06/09/2020 11:53, Gilles Filippini wrote: >> Package: release.debian.org >> Severity: normal >> User: release.debian@packages.debian.org >> Usertags: transition >> >> Hi, >> >> I'd like to transition json-simple 3.1.1 surrently sitting into experimental. >> The name of the library doens't change, but reverse dependencies need a >> binnmu. > > Why is that? Upstream removed an API that was deprecated long ago and introduced a few backward incompatible changes. _g. signature.asc Description: OpenPGP digital signature
Bug#969633: transition: json-simple
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, I'd like to transition json-simple 3.1.1 surrently sitting into experimental. The name of the library doens't change, but reverse dependencies need a binnmu. Here is the status for each of these build-rdeps: biojava4-live build OK derby build OK h2database build OK i2p build OK jts build OK mapsforge build OK mobile-atlas-creatorbuild OK mockito build OK netbeansbuild KO - not in testing orthanc-imagej build OK plm build OK spatial4j build OK spatial4j-0.4 build OK syndie build OK tikabuild KO - not in testing Since there is no library name change, I'm not sure what to put into the ben file. Here is an attempt: Ben file: title = "json-simple"; is_affected = .depends ~ /libjson-simple-java/ | .build-depends ~ /libjson-simple-java/; is_good = .depends ~ /lbjson-simple-java/; is_bad = .depends ~ /lbjson-simple-java/; Thanks in advance for considering. _g. -BEGIN PGP SIGNATURE- iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAl9UsaAACgkQ7+hsbH/+ z4ONUwf/W8FDPmIaBatEdvExBoeCh5IIudZmWVVvaKScAbr6upt10y8wU876kpfI B31Cl1XtFvlaiDqVNvuSuzjJ2+nFaHaFZncxG5fI9xl9pWZgkLSFXkOLwEG7f2TK 3WIT3DQqvQATXJqOelVqqKEb4Jo3eenA0NAdrCkTXDHmEJxzwPFVKFpLwr4UsLOy w87pX3HwJD/q2OYiPMY1WW71dT29Gd9CP22SIXsDQM6wHqeJN5TyzCozcmZH+uAZ nF2jL8gq372mg0WvnFRrvbrUTkC2p/yf1CWXtuG/p8W/ORoUNfv1DUtlhAQqC+o7 sXiftUHiXfdS6NKSg31TyRNHauaFPw== =s8ZV -END PGP SIGNATURE-
Bug#968937: src:derby: Please add support to build against libjson-simple-java >= 3
tony mancill a écrit le 05/09/2020 à 22:29 : > One more comment on the patch for this bug... > > It's a little odd that we're patching the build system for a specific > version of json-simple *at build time* when none of the binary packages > declares a dependency on this. > > For a short period of time we're going to end up with a binary package > built against the old json-simple that could fail at runtime once the > updated json-simple lands in unstable/testing. This makes me think > that we should probably force the issue and update the sources with a > versioned build-dependency on 3.1.1, along with a runtime dependency for > the appropriate binary package, which I believe is derby-tools (although > it doesn't declare a dependency on libjson-simple-java currently). > > However, given that I'm able to run derby locally and interact with it > without even having libjson-simple-java installed, I think that's > secondary and shouldn't hold up the transition. We can revisit it as > soon as the transition completes. Yes that's the plan. I'm aware of this problem, but I didn't find a better solution. > The source package now runs the tests (with kudos to the lintian > developers for adding a check that caught the incorrect dh override in > debian/rules). > > Thanks again for the patch. Thank you for the tests and the upload. _g. signature.asc Description: OpenPGP digital signature
Bug#968937: src:derby: Please add support to build against libjson-simple-java >= 3
Hi Emmanuel, Could you please review / apply this patch? Derby is the last blocker for this json-simple transition. Thanks in advance. _g. On Mon, 24 Aug 2020 10:37:35 +0200 Gilles Filippini wrote: > Package: src:derby > Version: 10.14.2.0-1 > Severity: normal > Tags: patch > > Hi, > > I'd like to transition json-simple 3.1.1 to unstable, but derby is a blocker > since it builds against libjson-simple-java << 3 only. > > The json-simple classes used by derby were deprecated in version 2.0.0 [1]. > There were removed in versions 3.x [2]. > > [1] > https://github.com/cliftonlabs/json-simple/blob/json-simple-2.0.0/README.txt > [2] > https://github.com/cliftonlabs/json-simple/blob/json-simple-3.0.1/CHANGELOG > > Please find attached a patch proposal to use the current json-simple classes. > I've tested that the package builds correctly against libjson-simple-java > version 2.3.0-1 from unstable and version 3.1.1-1~exp2 currently in > experimental. But I don't known how to test the package afterward. > > Thanks in advance for considering. > > _g. > > -- System Information: > Debian Release: buster/sid > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads) > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > signature.asc Description: OpenPGP digital signature
Bug#968937: src:derby: Please add support to build against libjson-simple-java >= 3
Package: src:derby
Version: 10.14.2.0-1
Severity: normal
Tags: patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
I'd like to transition json-simple 3.1.1 to unstable, but derby is a blocker
since it builds against libjson-simple-java << 3 only.
The json-simple classes used by derby were deprecated in version 2.0.0 [1].
There were removed in versions 3.x [2].
[1] https://github.com/cliftonlabs/json-simple/blob/json-simple-2.0.0/README.txt
[2] https://github.com/cliftonlabs/json-simple/blob/json-simple-3.0.1/CHANGELOG
Please find attached a patch proposal to use the current json-simple classes.
I've tested that the package builds correctly against libjson-simple-java
version 2.3.0-1 from unstable and version 3.1.1-1~exp2 currently in
experimental. But I don't known how to test the package afterward.
Thanks in advance for considering.
_g.
- -- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
-BEGIN PGP SIGNATURE-
iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAl9DfEYACgkQ7+hsbH/+
z4NHiwf+KtDwn+0dtTsYdDMFCF46WiMG3/+CcDpU0qqvnLvi/LwkSrdOIn9nGUJg
y+XgcEIz4I2v2cFu8kvkkDEcpzHaRv30c9d0w14CsQiIj5WAUAWTIRyNbvAYytGK
43166l87mxlTNXGMnSkaNB9ecYsYoZunTOh+JLbw87Uwd6pSdAFomL40OYYX96bR
zhTqL3uLXEiwMiaElSp7KEVNTra/hSV4nv3FrZ48g23UPMgzsJYQ7+fjsH3ZRLUy
DhZOqWqwGI2mVoib47WgjiBUgwL4cNwaGpyX0SymuXFWBZK/XNWTjbWtToOg51oH
2q/euVC00/fjRrLJBD6F7esM+j+I/Q==
=jlFE
-END PGP SIGNATURE-
diff -Nru derby-10.14.2.0/debian/changelog derby-10.14.2.0/debian/changelog
--- derby-10.14.2.0/debian/changelog2018-05-16 18:01:03.0 +0200
+++ derby-10.14.2.0/debian/changelog2020-08-24 09:49:39.0 +0200
@@ -1,3 +1,10 @@
+derby (10.14.2.0-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Tentative support for json-simple >= 3
+
+ -- Gilles Filippini Mon, 24 Aug 2020 09:49:39 +0200
+
derby (10.14.2.0-1) unstable; urgency=medium
* Team upload.
diff -Nru derby-10.14.2.0/debian/patches/json-simple-3.patch
derby-10.14.2.0/debian/patches/json-simple-3.patch
--- derby-10.14.2.0/debian/patches/json-simple-3.patch 1970-01-01
01:00:00.0 +0100
+++ derby-10.14.2.0/debian/patches/json-simple-3.patch 2020-08-24
09:49:11.0 +0200
@@ -0,0 +1,504 @@
+Index:
derby-10.14.2.0/java/optional/org/apache/derby/optional/api/SimpleJsonUtils.java
+===
+---
derby-10.14.2.0.orig/java/optional/org/apache/derby/optional/api/SimpleJsonUtils.java
derby-10.14.2.0/java/optional/org/apache/derby/optional/api/SimpleJsonUtils.java
+@@ -42,9 +42,9 @@ import java.sql.ResultSet;
+ import java.sql.ResultSetMetaData;
+ import java.sql.SQLException;
+
+-import org.json.simple.JSONArray;
+-import org.json.simple.JSONObject;
+-import org.json.simple.parser.JSONParser;
++import @JSON_SIMPLE@.JsonArray;
++import @JSON_SIMPLE@.JsonObject;
++import @JSON_SIMPLE@.Jsoner;
+
+ import org.apache.derby.iapi.types.HarmonySerialClob;
+ import org.apache.derby.iapi.util.StringUtil;
+@@ -77,9 +77,9 @@ public abstract class SimpleJsonUtils
+
+ /**
+ *
+- * Pack a ResultSet into a JSONArray. This method could be called
++ * Pack a ResultSet into a JsonArray. This method could be called
+ * client-side on any query result from any DBMS. Each row is
+- * converted into a JSONObject whose keys are the corresponding
++ * converted into a JsonObject whose keys are the corresponding
+ * column names from the ResultSet.
+ * Closes the ResultSet once it has been drained. Datatypes map
+ * to JSON values as follows:
+@@ -98,17 +98,17 @@ public abstract class SimpleJsonUtils
+ *
+ */
+ @SuppressWarnings("unchecked")
+-public static JSONArray toJSON( ResultSet rs )
++public static JsonArray toJSON( ResultSet rs )
+ throws SQLException
+ {
+ ResultSetMetaData rsmd = rs.getMetaData();
+ int columnCount = rsmd.getColumnCount();
+-JSONArray result = new JSONArray();
++JsonArray result = new JsonArray();
+
+ try {
+ while( rs.next() )
+ {
+-JSONObject row = new JSONObject();
++JsonObject row = new JsonObject();
+
+ for ( int i = 1; i <= columnCount; i++ )
+ {
+@@ -133,34 +133,32 @@ public abstract class SimpleJsonUtils
+ }
+
+ /**
+- * Construct a JSONArray from a Reader.
++ * Construct a JsonArray from a Reader.
+ */
+-public static JSONArray readArray( Reader reader )
++public static JsonArray readArray( Reader reader )
+ throws SQLException
+ {
+-
Bug#886716: Code clean up of obamenu
Hi,
Recently, I encoutered this bug. So I decided to look at the code. I
seems that obamenu code is poor. The translation to python3 has been
very basic.
It don't follow the python3 coding style. First, there is a mix of tab
and spaces.
One can use f-string instead of the % operator for formating string.
There are many too long lines.
The fix for the bug regarding broken links is easy. In the function
`process_dtfile`, it must frame the whole code of the function in a
`try: exception`.
I decided to rewrite the code. I made many changes to get a cleaner
code. I believe this will be easier to maintain.
I don't know what is the best meethod to suggest my improvements.
See the attachement for the entire code.
If I must proceed by other way, let me know how.
Best regards.
--
Gilles Crèvecoeur.
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
import glob
import sys
# Version 1.1.7
# config ---
applications_dirs = ("/usr/share/applications", )
image_dir_base = "/usr/share" # without "pixmaps" -/usr/local/share in
FreeBSD, /usr/share on linux
icon_Theme = "Humanity"
image_cat_prefix = "applications-" # if empty will create no icon text only
menu
application_groups = ("Office",
"Development",
"Graphics",
"Internet",
"Games",
"System",
"Multimedia",
"Utilities",
"Settings")
group_aliases = {"Audio": "Multimedia",
"AudioVideo": "Multimedia",
"Network": "Internet",
"Game": "Games",
"Utility": "Utilities",
"GTK": "",
"GNOME": ""}
ignoreList = ("evince-previewer",
"Ted",
"wingide3.2",
"python3.4",
"feh",
"xfce4-power-manager-settings")
terminal_string = "evte -e" # your favourites terminal exec string
simpleOBheader = False # print full xml style OB header
# --- End of user config ---
class dtItem(object):
def __init__(self, fName):
self.fileName = fName
self.Name = ""
self.Comment = ""
self.Exec = ""
self.Terminal = None
self.Type = ""
self.Icon = ""
self.Categories = ()
def addName(self, data):
self.Name = xescape(data)
def addComment(self, data):
self.Comment = data
def addExec(self, data):
if len(data) > 3 and data[-2] == '%': # get rid of filemanager
arguments in dt files
data = data[:-2].strip()
self.Exec = data
def addIcon(self, data):
self.Icon = ""
if image_cat_prefix == "":
return
image_dir = image_dir_base + "/pixmaps/"
di = data.strip()
if len(di) < 3:
# "Error in %s: Invalid or no icon '%s'" % (self.fileName, di)
return
dix = di.find("/") # is it a full path?
if dix >= 0 and dix <= 2:# yes, its a path (./path or ../path or
/path ...)
self.Icon = di
return
# else a short name like "myapp"
tmp = image_dir + di + ".*"
tmp = glob.glob(tmp)
if len(tmp) > 0:
self.Icon = tmp[0]
return
def addTerminal(self, data):
if data == "True" or data == "true":
self.Terminal = True
else:
self.Terminal = False
def addType(self, data):
self.Type = data
def addCategories(self, data):
self.Categories = data
def getCatIcon(cat):
iconDir = image_dir_base + "/icons/" + icon_Theme + "/categories/24/"
cat = image_cat_prefix + cat.lower()
tmp = glob.glob(iconDir + cat + ".*")
if len(tmp) > 0:
return tmp[0]
return ""
def xescape(s):
Rep = {"&": "",
"<": "",
">": "",
"'": "",
"\"": ""}
for p in ("&", "<", ">", "'", "\""):
sl = len(s)
last = -1
while last < sl:
i = s.find(p, last+1)
if i < 0:
# done = True # never used
break
last = i
x = s[:i]
r = s[i+1:]
Bug#962560: code-saturne built-in file editor fails
Hi Clinton, On Tue, 9 Jun 2020 14:08:12 -0700 Clinton Winant wrote: > Package: code-saturne > Version: 6.0 > > Severity: grave - makes the package unusable or mostly so: output in > built-in editor causes SaturneGUI to crash > > When I try to examine output files with the code-saturne built-in > file editor, the program terminates with error on the console of the > following kind: > > for EnSight output > Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/code_saturne/Base/QFileEditor.py", > line 910, in _explorerDoubleClick > self._viewSelectedFile() > File "/usr/lib/python3/dist-packages/code_saturne/Base/QFileEditor.py", > line 745, in _viewSelectedFile > self.openFile(fn=fn) > File "/usr/lib/python3/dist-packages/code_saturne/Base/QFileEditor.py", > line 991, in openFile > text = file.read() > File "/usr/lib/python3.8/codecs.py", line 322, in decode > (result, consumed) = self._buffer_decode(data, self.errors, final) > UnicodeDecodeError: 'utf-8' codec can't decode byte 0x89 in position 0: > invalid start byte > ./SaturneGUI: line 7: 5541 Aborted \code_saturne gui $@ > > for MED output > Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/code_saturne/Base/QFileEditor.py", > line 745, in _viewSelectedFile > self.openFile(fn=fn) > File "/usr/lib/python3/dist-packages/code_saturne/Base/QFileEditor.py", > line 991, in openFile > text = file.read() > File "/usr/lib/python3.8/codecs.py", line 322, in decode > (result, consumed) = self._buffer_decode(data, self.errors, final) > UnicodeDecodeError: 'utf-8' codec can't decode byte 0x89 in position 0: > invalid start byte > ./SaturneGUI: line 7: 5843 Aborted \code_saturne gui $@ > > CGNS formatted output behaves in the same way. Histogram files (.txt) > are displayed correctly ( but the output is of little value. > > I am using Debian GNU/Linux testing (Bullseye), kernel Debian 5.6.14-1 > (2020-05-23) > ldd --version > ldd (Debian GLIBC 2.30-8) 2.30 I've reported this issue to upstream and they think this might be related to your dataset. Would you mind sharing an example producing these errors? Thanks in advance, _g. signature.asc Description: OpenPGP digital signature
Bug#960589: src:i2p: Please add support to build against libjson-simple-java >= 3
Hi, On Thu, 14 May 2020 19:42:37 +0200 Gilles Filippini wrote: > On Thu, 14 May 2020 12:38:36 +0200 Gilles Filippini wrote: > > Package: src:i2p > > Version: 0.9.45-1 > > Severity: normal > > Tags: patch > > > > Hi, > > > > I'd like to transition json-simple 3.1.1 to unstable, but i2p is a blocker > > since it builds against libjson-simple-java << 3 only. > > > > The json-simple classes used by i2p were deprecated in version 2.0.0 [1]. > > There were removed in versions 3.x [2]. > > > > [1] > > https://github.com/cliftonlabs/json-simple/blob/json-simple-2.0.0/README.txt > > [2] > > https://github.com/cliftonlabs/json-simple/blob/json-simple-3.0.1/CHANGELOG > > > > Please find attached a patch proposal to use the current json-simple > > classes. I've tested that the package builds correctly against > > libjson-simple-java version 2.3.0-1 from unstable and version 3.1.1-1~exp2 > > currently in experimental. But I don't known how to test the package > > afterward. > > > > Thanks in advance for considering. > > Updated patch fixing a few misunderstandings. This is a reminder. The i2p package is now the only blocker for the json-simple transition. Other reverse dependencies now build against json-simple 3 or are not in testing. Please consider reviewing and applying this patch. Don't hesitate to ping me in case of any issue. Thanks, _g. signature.asc Description: OpenPGP digital signature
Bug#960639: Bug#960639: src:orthanc-imagej: Please add support to build against libjson-simple-java >= 3
Sébastien Jodogne a écrit le 28/05/2020 à 11:28 : > Dear Gilles, > > I finally managed to find a few hours to finalize your patch. I had to > extend it a bit so for it to work correctly [1]. > > Version "1.2+dfsg-2" of the package has just been uploaded accordingly. Thanks!! Best, _ni.
Bug#960632: src:plm: Please add support to build against libjson-simple-java >= 3
Gilles Filippini a écrit le 17/05/2020 à 23:29 :
> Gilles Filippini a écrit le 17/05/2020 à 22:51 :
>> Hi Martin,
>>
>> Martin Quinson a écrit le 17/05/2020 à 22:31 :
>>> Hello again,
>>>
>>> when I try to launch the program with your patch applied, I get the
>>> following backtrace:
>>>
>>> Exception in thread "main" java.lang.ClassCastException: class
>>> org.json.simple.JsonArray cannot be cast to class
>>> org.json.simple.JsonObject (org.json.simple.JsonArray and
>>> org.json.simple.JsonObject are in unnamed module of loader 'app')
>>> at plm.core.model.Users.loadUsersFromFile(Unknown Source)
>>> at plm.core.model.Users.(Unknown Source)
>>> at plm.core.model.Game.(Unknown Source)
>>> at plm.core.model.Game.getInstance(Unknown Source)
>>> at plm.core.ui.ProgrammersLearningMachine.main(Unknown Source)
>>>
>>> I will try to fix it in the near future, but your help would of course
>>> be welcome. Don't modify your patch as it is applied and burried under
>>> other changes already. Instead, please propose another patch on top of
>>> the current state in the package in
>>> https://salsa.debian.org/java-team/plm/
>>
>> I'll have a look at this.
>
> Could you give me an example of plm.users file causing this error?
Here is a patch to apply on top of your current git repo. It fixes
plm.users read / write and sessions- welcome.summary read.
Best,
_g.
diff --git a/debian/patches/json-simple-3.patch b/debian/patches/json-simple-3.patch
index ed5c9d9..141c4a7 100644
--- a/debian/patches/json-simple-3.patch
+++ b/debian/patches/json-simple-3.patch
@@ -164,9 +164,11 @@ Index: plm-2.6+repack/src/plm/core/model/session/SessionDB.java
===
--- plm-2.6+repack.orig/src/plm/core/model/session/SessionDB.java
+++ plm-2.6+repack/src/plm/core/model/session/SessionDB.java
-@@ -4,9 +4,9 @@ import java.util.HashMap;
+@@ -3,10 +3,11 @@ package plm.core.model.session;
+ import java.util.HashMap;
import java.util.Map;
import java.util.Set;
++import java.math.BigDecimal;
-import org.json.simple.JSONObject;
-import org.json.simple.parser.JSONParser;
@@ -177,7 +179,7 @@ Index: plm-2.6+repack/src/plm/core/model/session/SessionDB.java
import plm.core.lang.ProgrammingLanguage;
import plm.core.model.Game;
-@@ -154,7 +154,7 @@ public class SessionDB {
+@@ -154,7 +155,7 @@ public class SessionDB {
public String lessonSummary(String lesson) {
@@ -186,7 +188,7 @@ Index: plm-2.6+repack/src/plm/core/model/session/SessionDB.java
Map possibleL = possibleExercises.get(lesson);
for (ProgrammingLanguage pl: possibleL.keySet())
-@@ -166,15 +166,14 @@ public class SessionDB {
+@@ -166,15 +167,14 @@ public class SessionDB {
if (passedL.get(pl)!=0)
result.put("passed"+pl.getLang(), passedL.get(pl));
@@ -206,6 +208,23 @@ Index: plm-2.6+repack/src/plm/core/model/session/SessionDB.java
System.out.println("Ignoring invalid lesson summary (parse error: "+e.getLocalizedMessage()+").");
return;
}
+@@ -186,12 +186,12 @@ public class SessionDB {
+
+ for (ProgrammingLanguage pl: Game.getProgrammingLanguages()) {
+ if (data.containsKey("possible"+pl.getLang())) {
+-Long v = (Long) data.get("possible"+pl.getLang());
+-possibleL.put(pl, v.intValue());
++Integer v = ((BigDecimal) data.get("possible"+pl.getLang())).intValue();
++possibleL.put(pl, v);
+ }
+ if (data.containsKey("passed"+pl.getLang())) {
+-Long v = (Long) data.get("passed"+pl.getLang()); // damn, damn java casting madness
+-passedL.put(pl, v.intValue());
++Integer v = ((BigDecimal) data.get("passed"+pl.getLang())).intValue(); // damn, damn java casting madness
++passedL.put(pl, v);
+ }
+ }
+ }
Index: plm-2.6+repack/src/plm/core/model/session/ZipSessionKit.java
===
--- plm-2.6+repack.orig/src/plm/core/model/session/ZipSessionKit.java
@@ -430,7 +449,12 @@ Index: plm-2.6+repack/src/plm/core/model/User.java
===
--- plm-2.6+repack.orig/src/plm/core/model/User.java
+++ plm-2.6+repack/src/plm/core/model/User.java
-@@ -6,10 +6,10 @@ import java.util.LinkedHashMap;
+@@ -2,14 +2,15 @@ package plm.core.model;
+
+ import java.io.IOException;
+ import java.io.Writer;
++import java.io.StringWriter;
+ import java.util.LinkedHashMap;
import java.util.Objects;
import java.util.UUID;
@@ -444,7 +468,7 @@ Index: plm-2.6+repack/src/plm/core/model/User.java
private String username;
private boolean lastUsed;
private UUID userUUID;
-@@ -27,12
Bug#960632: src:plm: Please add support to build against libjson-simple-java >= 3
Gilles Filippini a écrit le 17/05/2020 à 22:51 : > Hi Martin, > > Martin Quinson a écrit le 17/05/2020 à 22:31 : >> Hello again, >> >> when I try to launch the program with your patch applied, I get the >> following backtrace: >> >> Exception in thread "main" java.lang.ClassCastException: class >> org.json.simple.JsonArray cannot be cast to class >> org.json.simple.JsonObject (org.json.simple.JsonArray and >> org.json.simple.JsonObject are in unnamed module of loader 'app') >> at plm.core.model.Users.loadUsersFromFile(Unknown Source) >> at plm.core.model.Users.(Unknown Source) >> at plm.core.model.Game.(Unknown Source) >> at plm.core.model.Game.getInstance(Unknown Source) >> at plm.core.ui.ProgrammersLearningMachine.main(Unknown Source) >> >> I will try to fix it in the near future, but your help would of course >> be welcome. Don't modify your patch as it is applied and burried under >> other changes already. Instead, please propose another patch on top of >> the current state in the package in >> https://salsa.debian.org/java-team/plm/ > > I'll have a look at this. Could you give me an example of plm.users file causing this error? Thanks, _g. signature.asc Description: OpenPGP digital signature
Bug#960632: src:plm: Please add support to build against libjson-simple-java >= 3
Hi Martin, Martin Quinson a écrit le 17/05/2020 à 22:31 : > Hello again, > > when I try to launch the program with your patch applied, I get the > following backtrace: > > Exception in thread "main" java.lang.ClassCastException: class > org.json.simple.JsonArray cannot be cast to class > org.json.simple.JsonObject (org.json.simple.JsonArray and > org.json.simple.JsonObject are in unnamed module of loader 'app') > at plm.core.model.Users.loadUsersFromFile(Unknown Source) > at plm.core.model.Users.(Unknown Source) > at plm.core.model.Game.(Unknown Source) > at plm.core.model.Game.getInstance(Unknown Source) > at plm.core.ui.ProgrammersLearningMachine.main(Unknown Source) > > I will try to fix it in the near future, but your help would of course > be welcome. Don't modify your patch as it is applied and burried under > other changes already. Instead, please propose another patch on top of > the current state in the package in > https://salsa.debian.org/java-team/plm/ I'll have a look at this. > Btw, I fixed a bug in the package that made it unusable on new > installation since maybe 4 years. It was only working with openjdk7 :( > Now, you should be able to start the program with the plm helper script. > > Thanks for your help, > Mt. > > On Sun, May 17, 2020 at 08:23:36AM +0200, Martin Quinson wrote: >> Hello Gilles, >> >> many thanks for your help, this package is in a rather sorry state, >> and I promise myself to do something about it since a long time. >> Hopefully this will be the nodge I needed :) >> >> I happen to be the upstream maintainer of this software, and I'd like >> to make things simpler if possible. Is it possible to update the code >> so that the patch does not depend on the used version? >> >> I will try to apply this patch, and then patch upstream to use json-simple-3 >> only. I need first to have json-simple reverse dependencies compatible with both versions, to be able to manage the transition. Once the transition is over there is no problem making plm supporting json-simple 3 only. Thanks, _g. signature.asc Description: OpenPGP digital signature
Bug#960639: Bug#960639: src:orthanc-imagej: Please add support to build against libjson-simple-java >= 3
Andreas Tille a écrit le 15/05/2020 à 12:49 : > Hi Sébastien, > > On Fri, May 15, 2020 at 07:50:01AM +0200, Sébastien Jodogne wrote: >> As far as I'm concerned, I don't have time to have a look at this >> problem in the upstream project before several months. The Orthanc >> project is indeed under heavy pressure because of the COVID crisis, and >> ImageJ support is not urgent in this context. > > Thank you for your work on Orthanc upstream and in Debian. > >> Regarding Debian packaging, I'm currently focused on the C++ packages >> related to Orthanc, which doesn't include the "orthanc-imagej" package >> (Java). >> >> I suggest thus two possibilities: >> >> (1) Someone else integrates Gilles' patch, or > > Gilles, would you mind just doing a team upload? > >> (2) orthanc-imagej is temporarily removed from unstable. > > I do not se any relevance for this since the bug is not RC. > >> As written above, unfortunately, I won't have a look at these two >> possibilities by myself right now. Any help from another Debian >> maintainer is thus welcome, feel free to take care of the >> "orthanc-imagej" package. > > Gilles, please let us know if this is urgent and you do not > feel comfortable with doing it yourself. It's not a problem doing the upload. this is the easy part :) What I'm uncomfortable with is that I don't know how to test whether my patch is correct. Is there any test suite or sample case available? Thanks, _g.
Bug#960692: src:netbeans: Please add support to build against libjson-simple-java >= 3
Package: src:netbeans Version: 10.0-3 Severity: normal Tags: patch -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, I'd like to transition json-simple 3.1.1 to unstable, but netbeans is a blocker since it builds against libjson-simple-java << 3 only. The json-simple classes used by netbeans were deprecated in version 2.0.0 [1]. There were removed in versions 3.x [2]. [1] https://github.com/cliftonlabs/json-simple/blob/json-simple-2.0.0/README.txt [2] https://github.com/cliftonlabs/json-simple/blob/json-simple-3.0.1/CHANGELOG Please find attached a patch proposal to use the current json-simple classes. I've tested that the package builds correctly against libjson-simple-java version 2.3.0-1 from unstable and version 3.1.1-1~exp2 currently in experimental. But I don't known how to test the package afterward. Because this is a huge patch it may have errors, but they should be easy to fix once discovered. Please do not hesitate to ping me in case of broken tests. Once this cleared, this patch should be push upstream. They can't keep going using this deprecated json-simple 1.x API. Thanks in advance for considering. _g. - -- System Information: Debian Release: buster/sid Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-1-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/+z4MFAl6+nIgACgkQ7+hsbH/+ z4NK6wf/bcGCD9GJDh9QMfp13jsxhM9/xN+uz1z27mA3z2jzeUQKYmeYfwOFyia2 kX1ABSF9h7MjleXi2g0Q4rnyqEjDAoCZGroS5UDP9yCbauNRsJPuYRiiU0lPty5/ cMIUB1WHKVl/AhoWO0+aBAJY7WxOHaCPfBbwPxRKOgHZX9x6uXX3W+DabDm4F3Qp usSABBCWr4/BM98qN/zdwTvnAZL8kRjbAHdG0ba2MU3daZ8/QmwsiyDVNlMzIh7M IkFepPW2cZsAfKjdhBRW1+oT0PC2ELUGRZ0NxjVxvSHS9UvktY1AgyCTrSHpXHzE 5DhGp7cZofiWVIQ0CnS26h7oVrdnSA== =ECGc -END PGP SIGNATURE- netbean-json-simple.debdiff.gz Description: application/gzip
Bug#960654: [Debian-med-packaging] Bug#960654: src:biojava4-live: Please add support to build against libjson-simple-java >= 3
Hi Olivier, olivier sallou a écrit le 15/05/2020 à 10:59 : > Hi, > thanks for the patch. > However, if json-simple API/ABI is broken, I think that package should > be kinda libjson-simple3-java to keep compatibility with existing > packages using old versions and allow transition of packages to new > release if needed and possible. Thanks for your inputs. I asked the Java packaging team for advice on this matter and they recommended not to change the package name. I won't keep the deprecated API around since it was deprecated several years ago and it is not maintained anymore by upstream. I intend to proceed with a proper transition via the Release Team. There are only 6 reverse dependencies. This should be manageable. > Anyway, gonna add your patch Thanks, _g. signature.asc Description: OpenPGP digital signature
Bug#960654: src:biojava4-live: Please add support to build against libjson-simple-java >= 3
Package: src:biojava4-live
Version: 4.2.12+dfsg-2
Severity: normal
Tags: patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
I'd like to transition json-simple 3.1.1 to unstable, but biojava4-live is a
blocker since it builds against libjson-simple-java << 3 only.
The json-simple classes used by biojava4-live were deprecated in version 2.0.0
[1]. There were removed in versions 3.x [2].
[1] https://github.com/cliftonlabs/json-simple/blob/json-simple-2.0.0/README.txt
[2] https://github.com/cliftonlabs/json-simple/blob/json-simple-3.0.1/CHANGELOG
Please find attached a patch proposal to use the current json-simple classes.
I've tested that the package builds correctly against libjson-simple-java
version 2.3.0-1 from unstable and version 3.1.1-1~exp2 currently in
experimental, and the build time test cases report no errors.
Thanks in advance for considering.
_g.
- -- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.6.0-1-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/+z4MFAl6+R5UACgkQ7+hsbH/+
z4OOnQgApJ5lITTg7Gdl45fmVHMuVZ7EO8F30UQ8b11IjqC9Jvy5Smxe6QpBr1XO
eeSY1QI8GVFd5OHk31AijdMC/JZTkSwjHAV+R5YODf96D5nnNLb+Se5w3hrzf+hg
/sa/tgya1+1551eK+BJoJX6upyo8Eu1ZWcM4X/2gTqJMuV9yI0u6d2w5pUpfF3Dq
3oVPO+0ZdKuI26roUXLiZUyu7W5DVctqt+JHWYHAxxdiQ2DoxhStK40haZ6km6Ee
xJnSPX472CxArpHZWWeUFOl+9GPT7kN6WGfSgfgzVoAnq5kw0DwspegXykFlLSNT
7VQX8vBOKadHyKQ9QM8DJK+RWJNW5w==
=H6WS
-END PGP SIGNATURE-
diff -Nru biojava4-live-4.2.12+dfsg/debian/changelog
biojava4-live-4.2.12+dfsg/debian/changelog
--- biojava4-live-4.2.12+dfsg/debian/changelog 2019-01-18 20:47:46.0
+0100
+++ biojava4-live-4.2.12+dfsg/debian/changelog 2020-05-15 08:50:46.0
+0200
@@ -1,3 +1,10 @@
+biojava4-live (4.2.12+dfsg-2.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Tentative fix to build against json-simple 3
+
+ -- Gilles Filippini Fri, 15 May 2020 08:50:46 +0200
+
biojava4-live (4.2.12+dfsg-2) unstable; urgency=medium
* Team upload.
diff -Nru biojava4-live-4.2.12+dfsg/debian/patches/use_simple_json
biojava4-live-4.2.12+dfsg/debian/patches/use_simple_json
--- biojava4-live-4.2.12+dfsg/debian/patches/use_simple_json2019-01-18
15:58:37.0 +0100
+++ biojava4-live-4.2.12+dfsg/debian/patches/use_simple_json2020-05-15
08:50:46.0 +0200
@@ -2,24 +2,42 @@
Author: Olivier Sallou
Description: json.org library is not "free", use simple_json
library and update according to API
-Last-Updated: 2012-12-02
-
a/biojava-ws/src/main/java/org/biojava/nbio/ws/hmmer/RemoteHmmerScan.java
-+++ b/biojava-ws/src/main/java/org/biojava/nbio/ws/hmmer/RemoteHmmerScan.java
+ .
+ [ Gilles Filippini ]
+ Patche updated to migrate away from deprecated json-simple 1.x classes
+ See json-simple 2.0.0 changelog:
+ > * Deprecated JSONParse and JSONValue in favor of Jsoner.
+ > * Deprecated JSONStreamAware and JSONAware in favor of Jsonable.
+ > * Deprecated JSONObject in favor of JsonObject.
+ > * Deprecated JSONArray in favor of JsonArray.
+ .
+ This patch now uses the new json-simple Json* classes. It is compatible
+ with both 2.x and 3.x json-simple releases, with a few ajustments
+ regarding backward incompatible changes in json-simple 3.x:
+ - The package name, changed to com.github.cliftonlabs.json_simple
+ This change is handled using place-holders @JSON_SIMPLE_PACKAGE@ which
+ are substituted at build time by debian/rules.
+ .
+ With this trick the package is compatible with json-simple 2.x and 3.x.
+Last-Updated: 2020-05-15
+Index:
biojava4-live-4.2.12+dfsg/biojava-ws/src/main/java/org/biojava/nbio/ws/hmmer/RemoteHmmerScan.java
+===
+---
biojava4-live-4.2.12+dfsg.orig/biojava-ws/src/main/java/org/biojava/nbio/ws/hmmer/RemoteHmmerScan.java
biojava4-live-4.2.12+dfsg/biojava-ws/src/main/java/org/biojava/nbio/ws/hmmer/RemoteHmmerScan.java
@@ -20,8 +20,10 @@
*/
package org.biojava.nbio.ws.hmmer;
-import net.sf.json.JSONArray;
-import net.sf.json.JSONObject;
-+import org.json.simple.JSONArray;
-+import org.json.simple.JSONObject;
-+import org.json.simple.JSONValue;
++import @JSON_SIMPLE_PACKAGE@.JsonArray;
++import @JSON_SIMPLE_PACKAGE@.JsonObject;
++import @JSON_SIMPLE_PACKAGE@.Jsoner;
+
import org.biojava.nbio.core.sequence.ProteinSequence;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
-@@ -136,15 +138,13 @@
+@@ -136,15 +138,13 @@ public class RemoteHmmerScan implements
SortedSet results = new TreeSet();
try {
@@ -27,29 +45,29 @@
-
- JSONObject hmresults = json.getJSONObject("results");
Bug#960652: src:jts: Please add support to build against libjson-simple-java >= 3
Package: src:jts Version: 1.16.1+ds-1 Severity: normal Tags: patch -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, I'd like to transition json-simple 3.1.1 to unstable, but jts is a blocker since it builds against libjson-simple-java << 3 only. The json-simple classes used by jts were deprecated in version 2.0.0 [1]. There were removed in versions 3.x [2]. [1] https://github.com/cliftonlabs/json-simple/blob/json-simple-2.0.0/README.txt [2] https://github.com/cliftonlabs/json-simple/blob/json-simple-3.0.1/CHANGELOG Please find attached a patch proposal to use the current json-simple classes. I've tested that the package builds correctly against libjson-simple-java version 2.3.0-1 from unstable and version 3.1.1-1~exp2 currently in experimental, and the build time test suite passes in both cases. Thanks in advance for considering. _g. - -- System Information: Debian Release: buster/sid Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-1-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/+z4MFAl6+Oq8ACgkQ7+hsbH/+ z4Nrcwf/bhoqxZMI7zi3dVGx+q31sXJT6/+59WqWRbO3wPWUb7DzOyVok6+ksJs3 G9s+GfGxKJ70I0756653ra7WcFD0DyAdzq4PsATYL/D6AJsgeci8F31yUV/Fginj pZNQuMZppwmdxLN9+VKyjHn7YW5UyGTKzF0zzCQqc5yN+mtae3d99lytUKoGmCtv b5buhzSaBsBswa4mK6mL5cpY3oWFDzj61DBHrQQqYkWoEtQ4gGQ18O8/EdKQeMer nnzmyeY694Tu6tZ1tLk/5Wr7YSHLnt/vPUB6F14QsClKVoToAf0qtnKhUs0QI5Bh sM9OU1mDqIfIHEelR+09iiSEefOz8Q== =yClf -END PGP SIGNATURE- diff -Nru jts-1.16.1+ds/debian/changelog jts-1.16.1+ds/debian/changelog --- jts-1.16.1+ds/debian/changelog 2019-07-24 20:21:16.0 +0200 +++ jts-1.16.1+ds/debian/changelog 2020-05-15 00:26:47.0 +0200 @@ -1,3 +1,10 @@ +jts (1.16.1+ds-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Tentative patch to build against json-simple 3 + + -- Gilles Filippini Fri, 15 May 2020 00:26:47 +0200 + jts (1.16.1+ds-1) unstable; urgency=medium * Team upload. diff -Nru jts-1.16.1+ds/debian/maven.rules jts-1.16.1+ds/debian/maven.rules --- jts-1.16.1+ds/debian/maven.rules2018-07-07 20:06:29.0 +0200 +++ jts-1.16.1+ds/debian/maven.rules1970-01-01 01:00:00.0 +0100 @@ -1,4 +0,0 @@ - -junit junit jar s/.*/3.x/ * * -org.locationtech.jts jts-modules pom s/.*/debian/ * * -org.apache.felix maven-bundle-plugin jar s/.*/2.5.4/ * * diff -Nru jts-1.16.1+ds/debian/maven.rules.in jts-1.16.1+ds/debian/maven.rules.in --- jts-1.16.1+ds/debian/maven.rules.in 1970-01-01 01:00:00.0 +0100 +++ jts-1.16.1+ds/debian/maven.rules.in 2020-05-15 00:26:47.0 +0200 @@ -0,0 +1,5 @@ + +junit junit jar s/.*/3.x/ * * +org.locationtech.jts jts-modules pom s/.*/debian/ * * +org.apache.felix maven-bundle-plugin jar s/.*/2.5.4/ * * +s/com.googlecode.json-simple/@JSON_SIMPLE_MAVEN@/ json-simple * s/.*/debian/ * * diff -Nru jts-1.16.1+ds/debian/patches/json-simple-3.patch jts-1.16.1+ds/debian/patches/json-simple-3.patch --- jts-1.16.1+ds/debian/patches/json-simple-3.patch1970-01-01 01:00:00.0 +0100 +++ jts-1.16.1+ds/debian/patches/json-simple-3.patch2020-05-15 00:26:47.0 +0200 @@ -0,0 +1,189 @@ +Description: Migrate away from deprecated json-simple 1.x classes + See json-simple 2.0.0 changelog: + > * Deprecated JSONParse and JSONValue in favor of Jsoner. + > * Deprecated JSONStreamAware and JSONAware in favor of Jsonable. + > * Deprecated JSONObject in favor of JsonObject. + > * Deprecated JSONArray in favor of JsonArray. + . + This patch uses the new json-simple Json* classes. It is compatible with + both 2.x and 3.x json-simple releases, with a few ajustments regarding + backward incompatible changes in json-simple 3.x: + - The package name, changed to com.github.cliftonlabs.json_simple + - The exception DeserializationExcetpion renamed as JsonException + These two changes are handled using place-holders @JSON_SIMPLE_PACKAGE@ + and @JSON_EXCEPTION@ which are substituted at build time by debian/rules. + . + With these tricks the package is compatible with json-simple 2.x and 3.x. +Author: Gilles Filippini +Index: jts-1.16.1+ds/modules/io/common/src/main/java/org/locationtech/jts/io/geojson/GeoJsonReader.java +=== +--- jts-1.16.1+ds.orig/modules/io/common/src/main/java/org/locationtech/jts/io/geojson/GeoJsonReader.java jts-1.16.1+ds/modules/io/common/src/main/java/org/locationtech/jts/io/geojson/GeoJsonReader.java +@@ -18,7 +18,7 @@ import java.util.ArrayList; + import java.util.List; + import java.util.Map; + +-import org.json.simple.parser.JSONParser; ++import @JSON_SIMPLE_PACKAGE@.Jsoner; + import org.locationtech.jts.geom.CoordinateSequence; + import org.locationtech.jts.geom.
Bug#960639: src:orthanc-imagej: Please add support to build against libjson-simple-java >= 3
Package: src:orthanc-imagej
Version: 1.2+dfsg-1
Severity: normal
Tags: patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
I'd like to transition json-simple 3.1.1 to unstable, but orthanc-imagej is a
blocker since it builds against libjson-simple-java << 3 only.
The json-simple classes used by orthanc-imagej were deprecated in version 2.0.0
[1]. There were removed in versions 3.x [2].
[1] https://github.com/cliftonlabs/json-simple/blob/json-simple-2.0.0/README.txt
[2] https://github.com/cliftonlabs/json-simple/blob/json-simple-3.0.1/CHANGELOG
Please find attached a patch proposal to use the current json-simple classes.
I've tested that the package builds correctly against libjson-simple-java
version 2.3.0-1 from unstable and version 3.1.1-1~exp2 currently in
experimental. But I don't known how to test the package afterward.
Thanks in advance for considering.
_g.
- -- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.6.0-1-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/+z4MFAl69xOcACgkQ7+hsbH/+
z4M05QgArerRja+IdHaKJdRugPYsdrg7UkATnA6+fdfZqZ556z0PEfspvQBMDUIO
fCUymwo0IozDmxNq5COn2w0AbExgwOTwsnf/Pg3t0xGw0AjdBsckvqS0P1H9APWz
m/uZHlFA8TZ2V1SPtoRK4HnE8Ru8K0ho1yexl1jSPenLFFaAWpPJK1Vib/M+2c+3
DKIjQQ2gW2g2N4+IHkinKW5KLuYr+4AErPNRP7VdVAxUcplYk1WpfRcbyMDhogTF
ZGK35Bew9eXc71Wg3WNPZSwM/RnD/sgx0MMeknOeJxtFgMt3CyoKWtWIALMuNq62
S0omjztsZNfsU6LcS+cUMvPLRteAOA==
=UUGZ
-END PGP SIGNATURE-
diff -Nru orthanc-imagej-1.2+dfsg/debian/changelog
orthanc-imagej-1.2+dfsg/debian/changelog
--- orthanc-imagej-1.2+dfsg/debian/changelog2018-10-31 08:28:01.0
+0100
+++ orthanc-imagej-1.2+dfsg/debian/changelog2020-05-14 23:29:49.0
+0200
@@ -1,3 +1,10 @@
+orthanc-imagej (1.2+dfsg-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * tentative patch to build against json-simple 3
+
+ -- Gilles Filippini Thu, 14 May 2020 23:29:49 +0200
+
orthanc-imagej (1.2+dfsg-1) unstable; urgency=medium
* New upstream version. (Closes: #912363)
diff -Nru orthanc-imagej-1.2+dfsg/debian/patches/json-simple-3.patch
orthanc-imagej-1.2+dfsg/debian/patches/json-simple-3.patch
--- orthanc-imagej-1.2+dfsg/debian/patches/json-simple-3.patch 1970-01-01
01:00:00.0 +0100
+++ orthanc-imagej-1.2+dfsg/debian/patches/json-simple-3.patch 2020-05-14
23:29:49.0 +0200
@@ -0,0 +1,359 @@
+Description: Migrate away from deprecated json-simple 1.x classes
+ See json-simple 2.0.0 changelog:
+ > * Deprecated JSONParse and JSONValue in favor of Jsoner.
+ > * Deprecated JSONStreamAware and JSONAware in favor of Jsonable.
+ > * Deprecated JSONObject in favor of JsonObject.
+ > * Deprecated JSONArray in favor of JsonArray.
+ .
+ This patch uses the new json-simple Json* classes. It is compatible with
+ both 2.x and 3.x json-simple releases, with a few ajustments regarding
+ backward incompatible changes in json-simple 3.x:
+ - The package name, changed to com.github.cliftonlabs.json_simple
+ - The exception DeserializationExcetpion renamed as JsonException
+ These two changes are handled using place-holders @JSON_SIMPLE_PACKAGE@
+ and @JSON_EXCETPION@ which are substituted at build time by debian/rules.
+ .
+ With these tricks the package is compatible with json-simple 2.x and 3.x.
+Author: Gilles Filippini
+Index: orthanc-imagej-1.2+dfsg/com/orthancserver/DicomDecoder.java
+===
+--- orthanc-imagej-1.2+dfsg.orig/com/orthancserver/DicomDecoder.java
orthanc-imagej-1.2+dfsg/com/orthancserver/DicomDecoder.java
+@@ -28,7 +28,8 @@ import ij.process.ShortProcessor;
+ import ij.process.ColorProcessor;
+ import ij.io.FileInfo;
+ import ij.measure.Calibration;
+-import org.json.simple.*;
++import @JSON_SIMPLE_PACKAGE@.JsonObject;
++import @JSON_SIMPLE_PACKAGE@.JsonArray;
+ import java.util.List;
+ import java.util.ArrayList;
+ import java.util.Collections;
+@@ -92,10 +93,10 @@ public class DicomDecoder
+ };
+
+ private static void ExtractCalibration(ImagePlus image,
+- JSONObject tags)
++ JsonObject tags)
+ {
+-JSONObject rescaleIntercept = (JSONObject) tags.get("0028,1052");
+-JSONObject rescaleSlope = (JSONObject) tags.get("0028,1053");
++JsonObject rescaleIntercept = (JsonObject) tags.get("0028,1052");
++JsonObject rescaleSlope = (JsonObject) tags.get("0028,1053");
+ if (rescaleIntercept != null &&
+ rescaleSlope != null)
+ {
+@@ -108,9 +109,9 @@ public class DicomDecoder
+ }
+
+ private static void ExtractPixelSpacing(Image
Bug#960632: src:plm: Please add support to build against libjson-simple-java >= 3
Package: src:plm
Version: 2.6+repack-3
Severity: normal
Tags: patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
I'd like to transition json-simple 3.1.1 to unstable, but plm is a blocker
since it builds against libjson-simple-java << 3 only.
The json-simple classes used by plm were deprecated in version 2.0.0 [1]. There
were removed in versions 3.x [2].
[1] https://github.com/cliftonlabs/json-simple/blob/json-simple-2.0.0/README.txt
[2] https://github.com/cliftonlabs/json-simple/blob/json-simple-3.0.1/CHANGELOG
Please find attached a patch proposal to use the current json-simple classes.
I've tested that the package builds correctly against libjson-simple-java
version 2.3.0-1 from unstable and version 3.1.1-1~exp2 currently in
experimental. But I don't known how to test the package afterward.
Thanks in advance for considering.
_g.
- -- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.6.0-1-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/+z4MFAl69t9gACgkQ7+hsbH/+
z4O/Ogf/TKcl0DykVQuRlbDexYENp672j8+2ux7ztFhFNUhS/zgB30Z1hZxXtRhk
QS++/PUSF0KleNtCK+d00Pjs4q9PzYrZhbyCz47fGukncjICF+wPr3cerrEy3w57
5iv5PF9B7u0Jbfjsuf5BOnRTFdCc+FvsqkB3BIg8kMmwJtSU/aAq5sJgw6VijIxU
wIJ9/QNUwYvUYlWPb/NQnGXyjX55b9SRNW+VeGB9OXUkRl2qlzpdeKLqBlXi2+bZ
d6Sy0p0FR88El+DyiOxFFUj9FO8iiQFrDBS2xhLcU3CknEjEctkJrX9K9fbWtMrr
a7Jf8TJl5BSzHrv17bRwZkddpMXwDg==
=SniR
-END PGP SIGNATURE-
diff -Nru plm-2.6+repack/debian/changelog plm-2.6+repack/debian/changelog
--- plm-2.6+repack/debian/changelog 2016-09-18 16:39:19.0 +0200
+++ plm-2.6+repack/debian/changelog 2020-05-14 18:05:12.0 +0200
@@ -1,3 +1,10 @@
+plm (2.6+repack-3.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Tentative patch to build against json-simple 3
+
+ -- Gilles Filippini Thu, 14 May 2020 18:05:12 +0200
+
plm (2.6+repack-3) unstable; urgency=medium
* Add run-time dependencies on default-jdk, jython and jruby.
diff -Nru plm-2.6+repack/debian/patches/json-simple-3.patch
plm-2.6+repack/debian/patches/json-simple-3.patch
--- plm-2.6+repack/debian/patches/json-simple-3.patch 1970-01-01
01:00:00.0 +0100
+++ plm-2.6+repack/debian/patches/json-simple-3.patch 2020-05-14
18:05:12.0 +0200
@@ -0,0 +1,595 @@
+Description: Migrate away from deprecated json-simple 1.x classes
+ See json-simple 2.0.0 changelog:
+ > * Deprecated JSONParse and JSONValue in favor of Jsoner.
+ > * Deprecated JSONStreamAware and JSONAware in favor of Jsonable.
+ > * Deprecated JSONObject in favor of JsonObject.
+ > * Deprecated JSONArray in favor of JsonArray.
+ .
+ This patch uses the new json-simple Json* classes. It is compatible with
+ both 2.x and 3.x json-simple releases, with a few ajustments regarding
+ backward incompatible changes in json-simple 3.x:
+ - The package name, changed to com.github.cliftonlabs.json_simple
+ - The exception DeserializationExcetpion renamed as JsonException
+ These two changes are handled using place-holders @JSON_SIMPLE_PACKAGE@
+ and @JSON_EXCETPION@ which are substituted at build time by debian/rules.
+ .
+ With these tricks the package is compatible with json-simple 2.x and 3.x.
+Author: Gilles Filippini
+Index: plm-2.6+repack/src/plm/core/model/Course.java
+===
+--- plm-2.6+repack.orig/src/plm/core/model/Course.java
plm-2.6+repack/src/plm/core/model/Course.java
+@@ -4,9 +4,9 @@ import java.io.IOException;
+ import java.util.ArrayList;
+ import java.util.Map;
+
+-import org.json.simple.JSONArray;
+-import org.json.simple.JSONObject;
+-import org.json.simple.JSONValue;
++import @JSON_SIMPLE_PACKAGE@.JsonArray;
++import @JSON_SIMPLE_PACKAGE@.JsonObject;
++import @JSON_SIMPLE_PACKAGE@.Jsoner;
+
+ /**
+ * Class to manage course data online
+@@ -50,7 +50,7 @@ public abstract class Course {
+ * A user password is set to push data, a teacher password to
administrate course
+ */
+ public ServerAnswer create() {
+-JSONObject jsonObject = new JSONObject();
++JsonObject jsonObject = new JsonObject();
+ jsonObject.put("action", "new");
+ jsonObject.put("course", courseId);
+ jsonObject.put("password", password);
+@@ -72,7 +72,7 @@ public abstract class Course {
+ * and by exercise
+ */
+ public String refresh() {
+-JSONObject jsonObject = new JSONObject();
++JsonObject jsonObject = new JsonObject();
+ jsonObject.put("action", "refresh");
+ jsonObject.put("course", courseId);
+ jsonObject.put("teacher_pa
Bug#960589: src:i2p: Please add support to build against libjson-simple-java >= 3
On Thu, 14 May 2020 12:38:36 +0200 Gilles Filippini wrote:
> Package: src:i2p
> Version: 0.9.45-1
> Severity: normal
> Tags: patch
>
> Hi,
>
> I'd like to transition json-simple 3.1.1 to unstable, but i2p is a blocker
> since it builds against libjson-simple-java << 3 only.
>
> The json-simple classes used by i2p were deprecated in version 2.0.0 [1].
> There were removed in versions 3.x [2].
>
> [1]
> https://github.com/cliftonlabs/json-simple/blob/json-simple-2.0.0/README.txt
> [2]
> https://github.com/cliftonlabs/json-simple/blob/json-simple-3.0.1/CHANGELOG
>
> Please find attached a patch proposal to use the current json-simple classes.
> I've tested that the package builds correctly against libjson-simple-java
> version 2.3.0-1 from unstable and version 3.1.1-1~exp2 currently in
> experimental. But I don't known how to test the package afterward.
>
> Thanks in advance for considering.
Updated patch fixing a few misunderstandings.
_g.
diff -Nru i2p-0.9.45/debian/changelog i2p-0.9.45/debian/changelog
--- i2p-0.9.45/debian/changelog 2020-04-12 16:50:00.0 +0200
+++ i2p-0.9.45/debian/changelog 2020-05-13 11:12:38.0 +0200
@@ -1,3 +1,10 @@
+i2p (0.9.45-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Tentative support for json-simple >= 3
+
+ -- Gilles Filippini Wed, 13 May 2020 11:12:38 +0200
+
i2p (0.9.45-1) unstable; urgency=medium
* New upstream release.
diff -Nru i2p-0.9.45/debian/control i2p-0.9.45/debian/control
--- i2p-0.9.45/debian/control 2020-04-12 16:50:00.0 +0200
+++ i2p-0.9.45/debian/control 2020-05-13 11:12:38.0 +0200
@@ -17,7 +17,7 @@
,bash-completion
,gettext
,libgetopt-java
- ,libjson-simple-java (<< 3)
+ ,libjson-simple-java
,libgmp-dev (>= 2:5.0.5)
,libservice-wrapper-java
,po-debconf
diff -Nru i2p-0.9.45/debian/patches/0003-json-simple-3.patch
i2p-0.9.45/debian/patches/0003-json-simple-3.patch
--- i2p-0.9.45/debian/patches/0003-json-simple-3.patch 1970-01-01
01:00:00.0 +0100
+++ i2p-0.9.45/debian/patches/0003-json-simple-3.patch 2020-05-13
11:12:38.0 +0200
@@ -0,0 +1,431 @@
+Description: Migrate away from deprecated json-simple 1.x classes
+ See json-simple 2.0.0 changelog:
+ > * Deprecated JSONParse and JSONValue in favor of Jsoner.
+ > * Deprecated JSONStreamAware and JSONAware in favor of Jsonable.
+ > * Deprecated JSONObject in favor of JsonObject.
+ > * Deprecated JSONArray in favor of JsonArray.
+ .
+ This patch uses the new json-simple Json* classes. It is compatible with
+ both 2.x and 3.x json-simple releases, with a few ajustments regarding
+ backward incompatible changes in json-simple 3.x:
+ - The package name, changed to com.github.cliftonlabs.json_simple
+ - The exception DeserializationExcetpion renamed as JsonException
+ These two changes are handled using place-holders @JSON_SIMPLE@ and
+ @JSON_EXCETPION@ which are substituted at build time by debian/rules.
+ .
+ With these tricks the package is compatible with json-simple 2.x and 3.x.
+Author: Gilles Filippini
+Index:
i2p-0.9.45/apps/i2pcontrol/java/com/thetransactioncompany/jsonrpc2/JSONRPC2Error.java
+===
+---
i2p-0.9.45.orig/apps/i2pcontrol/java/com/thetransactioncompany/jsonrpc2/JSONRPC2Error.java
i2p-0.9.45/apps/i2pcontrol/java/com/thetransactioncompany/jsonrpc2/JSONRPC2Error.java
+@@ -1,7 +1,7 @@
+ package com.thetransactioncompany.jsonrpc2;
+
+
+-import org.json.simple.JSONObject;
++import @JSON_SIMPLE@.JsonObject;
+
+
+ /**
+@@ -220,7 +220,7 @@ public class JSONRPC2Error extends Excep
+* @see #toJSONObject
+*/
+ @Deprecated
+- public JSONObject toJSON() {
++ public JsonObject toJSON() {
+
+ return toJSONObject();
+ }
+@@ -231,9 +231,9 @@ public class JSONRPC2Error extends Excep
+*
+* @return A JSON object representing this error object.
+*/
+- public JSONObject toJSONObject() {
++ public JsonObject toJSONObject() {
+
+- JSONObject out = new JSONObject();
++ JsonObject out = new JsonObject();
+
+ out.put("code", code);
+ out.put("message", super.getMessage());
+Index:
i2p-0.9.45/apps/i2pcontrol/java/com/thetransactioncompany/jsonrpc2/JSONRPC2Message.java
+===
+---
i2p-0.9.45.orig/apps/i2pcontrol/java/com/thetransactioncompany/jsonrpc2/JSONRPC2Message.java
i2p-0.9.45/apps/i2pcontrol/java/com/thetransactioncompany/jsonrpc2/JSONRPC2Message.java
+@@ -4,9 +4,11 @@ package com.thetransactioncompany.jsonrp
+ import java.util.HashMap;
+ import java.util.List;
+ import java.util.Map;
++import java.io.Writer;
++import java.io.IOException;
+
+-import org.json.simple.JSONAware;
+-im
Bug#960612: src:tika: Please add support to build against libjson-simple-java >= 3
Package: src:tika Version: 1.22-1 Severity: normal Tags: patch -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, I'd like to transition json-simple 3.1.1 to unstable, but tika is a blocker since it builds against libjson-simple-java << 3 only. The json-simple classes used by tika were deprecated in version 2.0.0 [1]. There were removed in versions 3.x [2]. [1] https://github.com/cliftonlabs/json-simple/blob/json-simple-2.0.0/README.txt [2] https://github.com/cliftonlabs/json-simple/blob/json-simple-3.0.1/CHANGELOG Please find attached a patch proposal to use the current json-simple classes. I've tested that the package builds correctly against libjson-simple-java version 2.3.0-1 from unstable and version 3.1.1-1~exp2 currently in experimental. But I don't known how to test the package afterward. Thanks in advance for considering. _g. - -- System Information: Debian Release: buster/sid Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-1-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/+z4MFAl69ZgQACgkQ7+hsbH/+ z4On6gf+N9/6tHA9M/Rcd5LEYQFt078ti7bcR5dAH5YlXvTtjKRewmBm4p7gl+ts R7EVnMOO1cRSjecrdzSlUGcInLVwRaDt+1cfC+jGHVq24Jw2U0/Tu9o2OQJvRGHn nutlzh+o6YNJhfhukOHylXpe8/Jujidl8DMtcOjrAPsqsMle/wRcjNxrRKBMMXd2 Y9MRI6PS8LWFQim/A6rWd1BwhDQwjYt5E5TwjNPrdGoJOPjvDPdTKuBhho0qsN72 7GbAELAP3fbijiUiMvu9NgCrFLkbpse2VDGLjOl1DIoNdxgESVCEjFsJD/Kyr/0J XkTAioERcub8zPyYfqZNmc0shIO3Tg== =eJOf -END PGP SIGNATURE- diff -Nru tika-1.22/debian/changelog tika-1.22/debian/changelog --- tika-1.22/debian/changelog 2019-08-05 11:41:25.0 +0200 +++ tika-1.22/debian/changelog 2020-05-14 15:14:44.0 +0200 @@ -1,3 +1,10 @@ +tika (1.22-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Tentative patch to build against json-simple >= 3 + + -- Gilles Filippini Thu, 14 May 2020 15:14:44 +0200 + tika (1.22-1) unstable; urgency=medium * New upstream release diff -Nru tika-1.22/debian/maven.rules tika-1.22/debian/maven.rules --- tika-1.22/debian/maven.rules2019-08-05 11:14:12.0 +0200 +++ tika-1.22/debian/maven.rules1970-01-01 01:00:00.0 +0100 @@ -1,14 +0,0 @@ - -com.fasterxml.jackson.core jackson-annotations * s/.*/2.x/ * * -com.fasterxml.jackson.core jackson-core * s/.*/2.x/ * * -com.fasterxml.jackson.core jackson-databind * s/.*/2.x/ * * -s/com.github.openjson/org.json/ s/openjson/json/ * s/.*/debian/ * * -s/org.codelibs/com.uwyn/ jhighlight * s/.*/debian/ * * -org.bouncycastle s/bcmail-jdk15/bcmail/ * s/.*/debian/ * * -org.bouncycastle s/bcmail-jdk15on/bcmail/ * s/.*/debian/ * * -org.bouncycastle s/bcprov-jdk15/bcprov/ * s/.*/debian/ * * -org.bouncycastle s/bcprov-jdk15on/bcprov/ * s/.*/debian/ * * -s/biz.aQute/biz.aQute.bnd/ * * s/.*/debian/ * * -org.apache.pdfbox pdfbox * s/.*/2.x/ * * -org.apache.pdfbox pdfbox-tools * s/.*/2.x/ * * -s/javax.annotation/org.apache.geronimo.specs/ s/javax.annotation-api/geronimo-annotation_1.3_spec/ * s/.*/debian/ * * diff -Nru tika-1.22/debian/maven.rules.in tika-1.22/debian/maven.rules.in --- tika-1.22/debian/maven.rules.in 1970-01-01 01:00:00.0 +0100 +++ tika-1.22/debian/maven.rules.in 2020-05-14 14:38:29.0 +0200 @@ -0,0 +1,15 @@ + +com.fasterxml.jackson.core jackson-annotations * s/.*/2.x/ * * +com.fasterxml.jackson.core jackson-core * s/.*/2.x/ * * +com.fasterxml.jackson.core jackson-databind * s/.*/2.x/ * * +s/com.github.openjson/org.json/ s/openjson/json/ * s/.*/debian/ * * +s/org.codelibs/com.uwyn/ jhighlight * s/.*/debian/ * * +org.bouncycastle s/bcmail-jdk15/bcmail/ * s/.*/debian/ * * +org.bouncycastle s/bcmail-jdk15on/bcmail/ * s/.*/debian/ * * +org.bouncycastle s/bcprov-jdk15/bcprov/ * s/.*/debian/ * * +org.bouncycastle s/bcprov-jdk15on/bcprov/ * s/.*/debian/ * * +s/biz.aQute/biz.aQute.bnd/ * * s/.*/debian/ * * +org.apache.pdfbox pdfbox * s/.*/2.x/ * * +org.apache.pdfbox pdfbox-tools * s/.*/2.x/ * * +s/javax.annotation/org.apache.geronimo.specs/ s/javax.annotation-api/geronimo-annotation_1.3_spec/ * s/.*/debian/ * * +s/com.googlecode.json-simple/@JSON_SIMPLE_MAVEN@/ json-simple * s/.*/debian/ * * diff -Nru tika-1.22/debian/patches/14-json-simple-3.patch tika-1.22/debian/patches/14-json-simple-3.patch --- tika-1.22/debian/patches/14-json-simple-3.patch 1970-01-01 01:00:00.0 +0100 +++ tika-1.22/debian/patches/14-json-simple-3.patch 2020-05-14 15:14:44.0 +0200 @@ -0,0 +1,48 @@ +Description: Migrate away from deprecated json-simple 1.x classes + See json-simple 2.0.0 changelog: + > * Deprecated JSONParse and JSONValue in favor of Jsoner. + > * Deprecated JSONStreamAware and JSONAware in favor of Jsonable. + > * Deprecated JSONObject in favor of JsonObject. + > *
Bug#960589: src:i2p: Please add support to build against libjson-simple-java >= 3
Package: src:i2p
Version: 0.9.45-1
Severity: normal
Tags: patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
I'd like to transition json-simple 3.1.1 to unstable, but i2p is a blocker
since it builds against libjson-simple-java << 3 only.
The json-simple classes used by i2p were deprecated in version 2.0.0 [1]. There
were removed in versions 3.x [2].
[1] https://github.com/cliftonlabs/json-simple/blob/json-simple-2.0.0/README.txt
[2] https://github.com/cliftonlabs/json-simple/blob/json-simple-3.0.1/CHANGELOG
Please find attached a patch proposal to use the current json-simple classes.
I've tested that the package builds correctly against libjson-simple-java
version 2.3.0-1 from unstable and version 3.1.1-1~exp2 currently in
experimental. But I don't known how to test the package afterward.
Thanks in advance for considering.
_g.
- -- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.6.0-1-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/+z4MFAl69H6MACgkQ7+hsbH/+
z4PJVAf/bz7jfcZeP9bOqAhqPhis9OtzF5EMTXbGzIHAIXbcxuBBFtTdSHai7tt6
TzkUojIgtlEr55d4rt4IasddzFWDh2Tt+fRzuLya/zbsgg4SIE4AC0uXBxu5+L4R
gTY0GPMoRIElD1KfMfawVvZ7XmQHEXy7KHt3StsaCOhcLa+sVNaFt3UzXjduW0TA
vUUm1VNxUOUcHiCnUCMOuGk4iNYXlO5DvIjtfmEdCDmMjmBM1EtTFcskjs7YVrNn
Ck2dte4Mmz7QOtV0GfM9io9L/vBKLdOEMYEyoJY8FlKV4VLRlr3PQtoE5Rk8L/lp
LuvAhibr5El/WNDBEsOe9YZjzNXaUA==
=Eff5
-END PGP SIGNATURE-
diff -Nru i2p-0.9.45/debian/changelog i2p-0.9.45/debian/changelog
--- i2p-0.9.45/debian/changelog 2020-04-12 16:50:00.0 +0200
+++ i2p-0.9.45/debian/changelog 2020-05-13 11:12:38.0 +0200
@@ -1,3 +1,10 @@
+i2p (0.9.45-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Tentative support for json-simple >= 3
+
+ -- Gilles Filippini Wed, 13 May 2020 11:12:38 +0200
+
i2p (0.9.45-1) unstable; urgency=medium
* New upstream release.
diff -Nru i2p-0.9.45/debian/control i2p-0.9.45/debian/control
--- i2p-0.9.45/debian/control 2020-04-12 16:50:00.0 +0200
+++ i2p-0.9.45/debian/control 2020-05-13 11:12:38.0 +0200
@@ -17,7 +17,7 @@
,bash-completion
,gettext
,libgetopt-java
- ,libjson-simple-java (<< 3)
+ ,libjson-simple-java
,libgmp-dev (>= 2:5.0.5)
,libservice-wrapper-java
,po-debconf
diff -Nru i2p-0.9.45/debian/patches/0003-json-simple-3.patch
i2p-0.9.45/debian/patches/0003-json-simple-3.patch
--- i2p-0.9.45/debian/patches/0003-json-simple-3.patch 1970-01-01
01:00:00.0 +0100
+++ i2p-0.9.45/debian/patches/0003-json-simple-3.patch 2020-05-13
11:12:38.0 +0200
@@ -0,0 +1,463 @@
+Description: Migrate away from deprecated json-simple 1.x classes
+ See json-simple 2.0.0 changelog:
+ > * Deprecated JSONParse and JSONValue in favor of Jsoner.
+ > * Deprecated JSONStreamAware and JSONAware in favor of Jsonable.
+ > * Deprecated JSONObject in favor of JsonObject.
+ > * Deprecated JSONArray in favor of JsonArray.
+ .
+ This patch uses the new json-simple Json* classes. It is compatible with
+ both 2.x and 3.x json-simple releases, with a few ajustments regarding
+ backward incompatible changes in json-simple 3.x:
+ - The package name, changed to com.github.cliftonlabs.json_simple
+ - The exception DeserializationExcetpion renamed as JsonException
+ These two changes are handled using place-holders @JSON_SIMPLE@ and
+ @JSON_EXCETPION@ which are substituted at build time by debian/rules.
+ .
+ With these tricks the package is compatible with json-simple 2.x and 3.x.
+ .
+ Regarding exception handling the patch keeps the same behavior as
+ upstream: parsing errors from JSONValue were silently ignored, returning
+ null. It is the same with this new implementation.
+Author: Gilles Filippini
+Index:
i2p-0.9.45/apps/i2pcontrol/java/com/thetransactioncompany/jsonrpc2/JSONRPC2Error.java
+===
+---
i2p-0.9.45.orig/apps/i2pcontrol/java/com/thetransactioncompany/jsonrpc2/JSONRPC2Error.java
i2p-0.9.45/apps/i2pcontrol/java/com/thetransactioncompany/jsonrpc2/JSONRPC2Error.java
+@@ -1,7 +1,7 @@
+ package com.thetransactioncompany.jsonrpc2;
+
+
+-import org.json.simple.JSONObject;
++import @JSON_SIMPLE@.JsonObject;
+
+
+ /**
+@@ -220,7 +220,7 @@ public class JSONRPC2Error extends Excep
+* @see #toJSONObject
+*/
+ @Deprecated
+- public JSONObject toJSON() {
++ public JsonObject toJSON() {
+
+ return toJSONObject();
+ }
+@@ -231,9 +231,9 @@ public class JSONRPC2Error extends Excep
+*
+* @return A JSON object representing this error object.
+*/
+- public JSONObject toJSONObject() {
++
Bug#959075: ifupdown: Bonding is not working with ifenslave 2.10 wich removes ifenslave command
Le mercredi 29 avril 2020, 09:48:10 CEST Guus Sliepen a écrit : > On Wed, Apr 29, 2020 at 09:21:19AM +0200, Gilles Mocellin wrote: > > Package: ifupdown > > Version: 0.8.35+b1 > > Severity: normal > > > > Dear Maintainer, > > > > The ifenslave package does not provides ifenslave command anymore > > (starting from 2.10), bonding interface needs to be done with iproute2 : > > # ip link set enp6s0 master bond0 > > > > I think ifupdown uses ifenslave command, because my system does not > > bring my bond anymore. > > Hello Gilles, Hello Guus, > The ifupdown package itself doesn't provide support for bonding at all, > it is the ifenslave package itself which provides that support. Nothing > should be calling the ifenslave binary anymore. So we should reassign this bug to ifenslave package. And sure, this package has been upgraded, not ifupdown. [;..] > Hm, that looks fine. Can you try to run: > > sudo ifdown -v bond0 > sudo ifup -v bond0 > > And send me a copy of the output? Hopefully that will help narrow down > the issue. Another thing to try is to remove "bond-slaves enp6s0 enp7s0" > from the bond0 stanza, and instead add "bond-master bond0" to the enp6s0 > and enp7s0 stanzas. Here is the ifup -v complete log to see all the dependances. There's an infinite loop rtying to setup the master bond. /bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d run-parts: executing /etc/network/if-pre-up.d/bridge run-parts: executing /etc/network/if-pre-up.d/ethtool run-parts: executing /etc/network/if-pre-up.d/ifenslave + [ meta = meta ] + exit 0 run-parts: executing /etc/network/if-pre-up.d/vde2 run-parts: executing /etc/network/if-pre-up.d/wpasupplicant ifup: configuring interface lo=lo (inet) /bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d run-parts: executing /etc/network/if-pre-up.d/bridge run-parts: executing /etc/network/if-pre-up.d/ethtool run-parts: executing /etc/network/if-pre-up.d/ifenslave + [ inet = meta ] + IF_BOND_SLAVES= + [ -n ] + [ -n -o -n ] + exit 0 run-parts: executing /etc/network/if-pre-up.d/vde2 run-parts: executing /etc/network/if-pre-up.d/wpasupplicant /sbin/ip link set dev lo up /bin/run-parts --exit-on-error --verbose /etc/network/if-up.d run-parts: executing /etc/network/if-up.d/avahi-daemon run-parts: executing /etc/network/if-up.d/ethtool run-parts: executing /etc/network/if-up.d/ifenslave + [ inet = meta ] + [ ] run-parts: executing /etc/network/if-up.d/postfix run-parts: executing /etc/network/if-up.d/wpasupplicant ifup: configuring interface enp6s0=enp6s0 (inet) /bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d run-parts: executing /etc/network/if-pre-up.d/bridge run-parts: executing /etc/network/if-pre-up.d/ethtool run-parts: executing /etc/network/if-pre-up.d/ifenslave + [ inet = meta ] + IF_BOND_SLAVES= + [ -n ] + [ -n -o -n ] + exit 0 run-parts: executing /etc/network/if-pre-up.d/vde2 run-parts: executing /etc/network/if-pre-up.d/wpasupplicant /sbin/ip link set dev enp6s0 up 2>/dev/null || true /bin/run-parts --exit-on-error --verbose /etc/network/if-up.d run-parts: executing /etc/network/if-up.d/avahi-daemon run-parts: executing /etc/network/if-up.d/ethtool run-parts: executing /etc/network/if-up.d/ifenslave + [ inet = meta ] + [ ] run-parts: executing /etc/network/if-up.d/postfix run-parts: executing /etc/network/if-up.d/wpasupplicant ifup: configuring interface enp7s0=enp7s0 (inet) /bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d run-parts: executing /etc/network/if-pre-up.d/bridge run-parts: executing /etc/network/if-pre-up.d/ethtool run-parts: executing /etc/network/if-pre-up.d/ifenslave + [ inet = meta ] + IF_BOND_SLAVES= + [ -n ] + [ -n -o -n ] + exit 0 run-parts: executing /etc/network/if-pre-up.d/vde2 run-parts: executing /etc/network/if-pre-up.d/wpasupplicant /sbin/ip link set dev enp7s0 up 2>/dev/null || true /bin/run-parts --exit-on-error --verbose /etc/network/if-up.d run-parts: executing /etc/network/if-up.d/avahi-daemon run-parts: executing /etc/network/if-up.d/ethtool run-parts: executing /etc/network/if-up.d/ifenslave + [ inet = meta ] + [ ] run-parts: executing /etc/network/if-up.d/postfix run-parts: executing /etc/network/if-up.d/wpasupplicant ifup: configuring interface bond0=bond0 (inet) /bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d run-parts: executing /etc/network/if-pre-up.d/bridge run-parts: executing /etc/network/if-pre-up.d/ethtool run-parts: executing /etc/network/if-pre-up.d/ifenslave + [ inet = meta ] + IF_BOND_SLAVES=enp6s0 enp7s0 + [ -n ] + [ -n enp6s0 enp7s0 -o -n balance-alb ] + setup_master bond0 + add_master + [ -f /sys/class/net/bond0/bonding/slaves ] + return + early_setup_master + sysfs fail_over_mac + [ -n ] + return 0 + setup_master + add_master + [ -f /sys/class/net/bond0/bonding/sla
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).
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#959075: ifupdown: Bonding is not working with ifenslave 2.10 wich removes ifenslave command
Package: ifupdown Version: 0.8.35+b1 Severity: normal Dear Maintainer, The ifenslave package does not provides ifenslave command anymore (starting from 2.10), bonding interface needs to be done with iproute2 : # ip link set enp6s0 master bond0 I think ifupdown uses ifenslave command, because my system does not bring my bond anymore. -- Package-specific info: --- /etc/network/interfaces: # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto enp6s0 iface enp6s0 inet manual ethernet-wol g # offload-lro off # offload-gro off auto enp7s0 iface enp7s0 inet manual ethernet-wol g # offload-lro off # offload-gro off auto bond0 iface bond0 inet manual bond-slaves enp6s0 enp7s0 bond-mode balance-alb bond-miimon 100 mtu 9000 auto br0 iface br0 inet static bridge_ports bond0 bridge_fd 0 bridge_stp off address 10.0.0.1 netmask 255.255.255.0 gateway 10.0.0.4 dns-nameservers 10.0.0.4 dns-search pastis21.loc up ip r a 213.163.183.90 via 10.0.0.4 down ip r r 213.163.183.90 via 10.0.0.4 # Interface Wifi #allow-hotplug wlan0 #iface wlan0 inet dhcp # wpa-conf /etc/wpa_supplicant.conf --- up and down scripts installed: /etc/network/if-down.d: total 4 -rwxr-xr-x 1 root root 800 Jan 9 2017 postfix lrwxrwxrwx 1 root root 32 Mar 24 11:13 wpasupplicant -> ../../wpa_supplicant/ifupdown.sh /etc/network/if-post-down.d: total 8 lrwxrwxrwx 1 root root 23 Dec 13 17:00 avahi-daemon -> ../if-up.d/avahi-daemon lrwxrwxrwx 1 root root 29 Jan 28 2019 bridge -> /lib/bridge-utils/ifupdown.sh -rwxr-xr-x 1 root root 1714 Sep 27 2016 ifenslave -rwxr-xr-x 1 root root 907 Jan 19 2012 vde2 lrwxrwxrwx 1 root root 32 Mar 24 11:13 wpasupplicant -> ../../wpa_supplicant/ifupdown.sh /etc/network/if-pre-up.d: total 16 lrwxrwxrwx 1 root root 29 Jan 28 2019 bridge -> /lib/bridge-utils/ifupdown.sh -rwxr-xr-x 1 root root 344 Jun 7 2010 ethtool -rwxr-xr-x 1 root root 6417 May 8 2018 ifenslave -rwxr-xr-x 1 root root 1793 Jan 19 2012 vde2 lrwxrwxrwx 1 root root 32 Mar 24 11:13 wpasupplicant -> ../../wpa_supplicant/ifupdown.sh /etc/network/if-up.d: total 16 -rwxr-xr-x 1 root root 484 Mar 6 2013 avahi-daemon -rwxr-xr-x 1 root root 1685 Sep 22 2014 ethtool -rwxr-xr-x 1 root root 1741 Sep 27 2016 ifenslave -rwxr-xr-x 1 root root 1117 Jan 9 2017 postfix lrwxrwxrwx 1 root root 32 Mar 24 11:13 wpasupplicant -> ../../wpa_supplicant/ifupdown.sh -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.5.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ifupdown depends on: ii adduser 3.118 ii iproute2 5.6.0-1 ii libc6 2.30-4 ii lsb-base 11.1.0 Versions of packages ifupdown recommends: ii isc-dhcp-client [dhcp-client] 4.4.1-2.1+b2 Versions of packages ifupdown suggests: ii ppp 2.4.7-2+4.1+deb10u1 pn rdnssd -- no debconf information
Bug#949780: maptool: Maptool segfaults
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
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#958174: hdf5: please add the hdf5plugins
picca a écrit le 22/04/2020 à 16:07 : > Gilles Filippini writes: > >> Aren't most of these filters available in the pytables and bitshuffle >> packages? > > It seems to me that these filters are provided but not installed system > wide under the hdf5 plugin directory. > > So each project/scripts which would require a plugin need to register the > plugins on it's own. > > I am wondering if the best would not be to build and install the plugins > under the hdf5 lib expected plugin directory on the system > Which is not trivial to know. > > An improvement would be to add a variable to the pkgconfig files in order > to expose this plugin directory. Done with the last upload to experimental. The plugin dir is advertised in the pkg-config files via the 'PluginDir' variable. > I do not know if the puglin directory is the same for the serial and the > mpi version of the library. I don't know either. I made them different. > If clear instruction are provided in order to provide system wide > plugin, then we can patch all these pacakage whcih should provide > plugins and request them to install the plugin at the right place. > > Then we will have an hdf5 librairy with out of the box plugin support :). > > I found also this link with all the filter available around hdf5. > so I tought that the hdfgroup would provide a tar.gz with all of them > pre packaged in source forme. > > since you are in charge of the hdf5 package, I tought that you have a > privilegiate contact with them. > > https://portal.hdfgroup.org/display/support/HDF5+Plugins Not so privileged, but I've asked them anyway. Waiting for the answer. I've also found this github repo: https://github.com/nexusformat/HDF5-External-Filter-Plugins I think these plugins should ship from their own source package. They are not part of the HDF5 source tree and the HDF5 source package is cluttered enough :) With the plugin dirs configured and advertised you now have the choice between packaging the plugins or filing bugs against pytables and bitshuffle so they install their plugins into the proper locations. Thanks, _g. signature.asc Description: OpenPGP digital signature
Bug#958530: sqlite3: Please configure a default search path to load extensions from
Package: sqlite3 Version: 3.31.1-4 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, The load_extension feature of sqlite3 searchs for the specified extensions into the system's default path for shared libraries. But these extensions shouldn't be installed into these paths because they are not system libraries. As the Debian policy requests it, they should be installed into /usr/lib/sqlite3 or /usr/lib//sqlite3. Then, it would be convenient to set the above paths as default search locations for the extensions. This way, the sqlite3-pcre extention could be loaded without specifying its full path: sqlite> .load pcre sqlite> Thanks for considering. _g. - -- System Information: Debian Release: buster/sid Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-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 sqlite3 depends on: ii libc6 2.30-4 ii libreadline8 8.0-4 ii libsqlite3-0 3.31.1-4 ii zlib1g1:1.2.11.dfsg-2 sqlite3 recommends no packages. Versions of packages sqlite3 suggests: pn sqlite3-doc - -- no debconf information -BEGIN PGP SIGNATURE- iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAl6hi6wACgkQ7+hsbH/+ z4NSHAf6Aww6b+XQda3U9N/jYlYgHDrjthb+I+3U4kZVKxagSlJo1/h4zq8NHPVo NAqWzD+b2LcU+jhEbyBUMUW07R4BSwfd8JwO/URSMrmuRWMu8lWTHmVirF9DBorz sNc4Qc9iD/YHgwxGVfK4eHiJRt+TIVc+skepG99xmoArhkjKlrDhuzOK3ZIkK81Z m5G10B9dkHbooaqYECeyEoKkFAQYNQOb5Nu1J2WsLDO/xGj+PUEScX2xUeU3oRsS YiZVtLLRbicEEr9gXIzwaQh7ijCpl/jrFA+oo6nawu4+1FuTj0X/VWzEeyFzoGcx mRMEWXUjJuErWq5LCHv5jp8r2Yz8ZA== =1d9X -END PGP 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).
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 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#958174: hdf5: please add the hdf5plugins
Hi Frédéric, Picca Frédéric-Emmanuel a écrit le 19/04/2020 à 12:41 : > > Source: hdf5 > Severity: normal > > Dear Maintainer, > > I saw on the hdf5 group website that they provide also hdf5plugin > > https://www.hdfgroup.org/downloads/hdf5/ > > Is it possible to add these plugins in the hdf5 package. Aren't most of these filters available in the pytables and bitshuffle packages? _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).
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).
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
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
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
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
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
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
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
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#950684: Debian Bug #950684
Johannes Schauer a écrit le 02/04/2020 à 22:57 :
> Quoting Gilles Filippini (2020-04-02 22:37:42)
>> The problem occurs in both cases:
>>
>> $ $ sudo sbuild-createchroot --make-sbuild-tarball=foo.tar.gz \
>> --chroot-prefix=foo --keep-sbuild-chroot-dir unstable \
>> "$(TMPDIR= mktemp -d)" http://ftp.de.debian.org/debian
>> ...
>> $ tar tvaf foo.tar.gz | head -4
>> drwx-- pini/pini 0 2020-04-02 22:17 ./
>> drwxrws--- sbuild/sbuild 0 2020-04-02 22:17 ./build/
>> drwxr-xr-x root/root 0 2020-04-02 22:16 ./mnt/
>> drwxr-xr-x root/root 0 2020-04-02 22:16 ./dev/
>>
>> $ sudo sbuild-createchroot --make-sbuild-tarball=bar.tar.gz \
>> --chroot-prefix=bar --keep-sbuild-chroot-dir unstable \
>> "$(TMPDIR=~/tmp mktemp -d)" http://ftp.de.debian.org/debian
>> ...
>> $ tar tvaf bar.tar.gz | head -4
>> drwx-- pini/pini 0 2020-04-02 22:26 ./
>> drwxrws--- sbuild/sbuild 0 2020-04-02 22:26 ./build/
>> drwxr-xr-x root/root 0 2020-04-02 22:25 ./mnt/
>> drwxr-xr-x root/root 0 2020-04-02 22:25 ./dev/
>>
>> The temporary directory has permission 700 in both cases:
>> drwx-- 22 pini pini 4096 avril 2 22:17 /tmp/tmp.wnCEvIIVxV
>> drwx-- 22 pini pini 4096 avril 2 22:26 /home/pini/tmp/tmp.5cz5ZSXoKd
>>
>> This is expected (excerpt from the mktemp man page):
>>> Files are created u+rw, and directories u+rwx, minus umask restrictions.
>
> Okay, this means that the problem does *not* occur if you operate
> sbuild-createchroot like this:
>
> mkdir ~/tmp
> sudo sbuild-createchroot --make-sbuild-tarball=foo.tar.gz unstable ~/tmp
>
> If so, then the following patch should fix your problem:
>
> --- a/bin/sbuild-createchroot
> +++ b/bin/sbuild-createchroot
> @@ -293,6 +293,7 @@ if (-e $target) {
> if (!-d $target) {
> die "$target exists and is not a directory";
> }
> +chmod 0755, $target or die "cannot chmod $target";
> # only check if the directory is empty if the --setup-only option is not
> # given because that option needs an already populated directory
> if (!$conf->get('SETUP_ONLY')) {
>
>
> Can you confirm?
No, this is not enough. / has to be own by root for the systemd package
configuration to work. So it would be:
mkdir ~/tmp
sudo chown root:root ~/tmp
sudo sbuild-createchroot --make-sbuild-tarball=foo.tar.gz unstable ~/tmp
I've just tested it successfully.
And you'll have to add this line to your patch:
chown 0, 0, $target or die "cannot chown $target";
Thanks,
_g.
signature.asc
Description: OpenPGP digital signature
Bug#950684: Debian Bug #950684
Johannes Schauer a écrit le 02/04/2020 à 01:59 : > Hi, > > Quoting Gilles Filippini (2020-03-21 15:28:32) >> On Wed, 26 Feb 2020 19:59:20 +0100 Johannes Schauer wrote: >>> On Sat, 22 Feb 2020 17:45:36 +0100 Johannes Schauer >>> wrote: >>>> Quoting Jörg Frings-Fürst (2020-02-22 17:36:10) >>>>> Am Samstag, den 22.02.2020, 17:17 +0100 schrieb Johannes Schauer: >>>>>> Control: severity -1 important >>>>>> >>>>>> Quoting Johannes Schauer (2020-02-22 17:05:47) >>>>>>> Quoting Jörg Frings-Fürst (2020-02-22 16:48:52) >>>>>>>>> please show me evidence of that. >>>>>>>>> >>>>>>>>> Setting a bug severity to serious means that sbuild will be >>>>>>>>> removed from >>>>>>>>> testing in March. You should have evidence before such a >>>>>>>>> drastic measure is >>>>>>>>> taken. >>>>>>>> All packages that directly or indirectly have systemd as build >>>>>>>> depend can no >>>>>>>> longer be compiled. I think that is reason enough. >>>>>>> >>>>>>> Indeed I now see the problem myself. >> >> I've just been bitten by this while building stimfit into a fresh >> unstable sbuild chroot. >> >> Setting once and for all the correct permissions using sbuild-shell >> fixed the problem for this chroot: >> $ echo "/bin/chown root:root / && /bin/chmod a+rX /" | \ >> sudo sbuild-shell > > I may have a theory... > > All you who have this error (Jörg + Gilles), did you use a command line with > sbuild-createchroot that has "$(mktemp -d)" in it? Depending on what your > $TMPDIR is, the problem might be that the create directory has permissions > 700. > This means that the root directory of the tarball that is created will only be > readable by root which kills it for most applications. Debootstrap doesn't > care > but mmdebstrap explicitly does a "chmod 0755" on the root directory which is > why you might not see the problem with mmdebstrap but only with debootstrap. > > So could you please confirm the following: > > - try doing "tar -tvf /srv/... | head" on the chroot tarball and have a look >at the permissions of ./ -- what are they? > > - the problem only occurs when you use "$(mktemp -d)" when running >sbuild-creatchroot and it goes away if you use any other directory outside >$TMPDIR as temporary directory like for example ~/tmp. So for example > create >your chroot like this: > >$ sudo sbuild-createchroot --make-sbuild-tarball=/srv/... unstable > ~/tmp > > - if the answer to above question is "yes": when you use "$(mktemp -d)" then >the directory that is created has permissions 700, right? The problem occurs in both cases: $ $ sudo sbuild-createchroot --make-sbuild-tarball=foo.tar.gz \ --chroot-prefix=foo --keep-sbuild-chroot-dir unstable \ "$(TMPDIR= mktemp -d)" http://ftp.de.debian.org/debian ... $ tar tvaf foo.tar.gz | head -4 drwx-- pini/pini 0 2020-04-02 22:17 ./ drwxrws--- sbuild/sbuild 0 2020-04-02 22:17 ./build/ drwxr-xr-x root/root 0 2020-04-02 22:16 ./mnt/ drwxr-xr-x root/root 0 2020-04-02 22:16 ./dev/ $ sudo sbuild-createchroot --make-sbuild-tarball=bar.tar.gz \ --chroot-prefix=bar --keep-sbuild-chroot-dir unstable \ "$(TMPDIR=~/tmp mktemp -d)" http://ftp.de.debian.org/debian ... $ tar tvaf bar.tar.gz | head -4 drwx-- pini/pini 0 2020-04-02 22:26 ./ drwxrws--- sbuild/sbuild 0 2020-04-02 22:26 ./build/ drwxr-xr-x root/root 0 2020-04-02 22:25 ./mnt/ drwxr-xr-x root/root 0 2020-04-02 22:25 ./dev/ The temporary directory has permission 700 in both cases: drwx-- 22 pini pini 4096 avril 2 22:17 /tmp/tmp.wnCEvIIVxV drwx-- 22 pini pini 4096 avril 2 22:26 /home/pini/tmp/tmp.5cz5ZSXoKd This is expected (excerpt from the mktemp man page): > Files are created u+rw, and directories u+rwx, minus umask restrictions. Thanks, _g. signature.asc Description: OpenPGP digital signature
Bug#954654: transition: hdf5
Emilio Pozuelo Monfort a écrit le 27/03/2020 à 13:29 : > Control: tags -1 confirmed > > On 22/03/2020 12:19, Gilles Filippini wrote: >> Package: release.debian.org >> Severity: normal >> User: release.debian@packages.debian.org >> Usertags: transition >> >> Hi Release Team, >> >> I'd like to transition hdf5 1.10.6+repack-1~exp5 currently sitting in >> experimental. >> >> Among the 112 tested reverse dependencies, only 7 FTBFS, and there failures >> aren't related to the transition: >> jhdf KO - #875584 - Not in testing >> openmolcas KO - Not in testing >> sra-sdkKO - #952623 - Removal from testing on the 10/04/2020 >> xmds2 KO - #938925 - Not in testing >> ants KO - Multiple RC bugs - Not in testing >> siconosKO - #954497 - Removal from testing on the 29/03/2020 >> simpleitk KO - #949355 - Not in testing > > Sounds good. Go ahead. Uploaded! Thanks, _g. signature.asc Description: OpenPGP digital signature
Bug#954654: transition: hdf5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Release Team, I'd like to transition hdf5 1.10.6+repack-1~exp5 currently sitting in experimental. Among the 112 tested reverse dependencies, only 7 FTBFS, and there failures aren't related to the transition: jhdf KO - #875584 - Not in testing openmolcas KO - Not in testing sra-sdkKO - #952623 - Removal from testing on the 10/04/2020 xmds2 KO - #938925 - Not in testing ants KO - Multiple RC bugs - Not in testing siconosKO - #954497 - Removal from testing on the 29/03/2020 simpleitk KO - #949355 - Not in testing Ben file: title = "hdf5"; is_affected = .depends ~ /libhdf5/ | .build-depends ~ /hdf5/; is_good = .depends ~ /libhdf5-103-1|libhdf5-openmpi-103-1|libhdf5-mpich-103-1/; is_bad = .depends ~ /libhdf5-103|libhdf5-openmpi-103|libhdf5-mpich-103/; Thanks, _g. - -- System Information: Debian Release: buster/sid Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-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/+z4MFAl53SaEACgkQ7+hsbH/+ z4No4AgAnTZUxHfzT3dtR3B++dZEgOOvb1xnpf8OS3MxVFVUVyIwoWMkGVDp/kXx sbkT8WOKXvrioLxekCmjvnojPzoFVJD8rcxj9au0fjxSb+sE6uRgVZunXOtgLlgU +OuKkyj6niHJJgIin6QqN4hmNTGzK5gfJfv+DFF3LmmZtYHh0HZWEBkguS07TG/4 Bq+km1KqADaPlWGANf7yXBiIvzhXO12ZMpsrMg79YalB2YNoVl1treHTBRD6NO1q KVLLFUntt2zpVtYCQW6YrkKFuWcFRPB8GjoWmstkXXIhOcFBWP466iFdTW406ZKR 4aVGHvxemx+JPpn5VzhUClHHISh1cw== =6u+X -END PGP SIGNATURE-
Bug#950684: Debian Bug #950684
Hi, On Wed, 26 Feb 2020 19:59:20 +0100 Johannes Schauer wrote: > Hi, > > On Sat, 22 Feb 2020 17:45:36 +0100 Johannes Schauer wrote: > > Quoting Jörg Frings-Fürst (2020-02-22 17:36:10) > > > Am Samstag, den 22.02.2020, 17:17 +0100 schrieb Johannes Schauer: > > > > Control: severity -1 important > > > > > > > > Quoting Johannes Schauer (2020-02-22 17:05:47) > > > > > Quoting Jörg Frings-Fürst (2020-02-22 16:48:52) > > > > > > > please show me evidence of that. > > > > > > > > > > > > > > Setting a bug severity to serious means that sbuild will be > > > > > > > removed from > > > > > > > testing in March. You should have evidence before such a > > > > > > > drastic measure is > > > > > > > taken. > > > > > > All packages that directly or indirectly have systemd as build > > > > > > depend can no > > > > > > longer be compiled. I think that is reason enough. > > > > > > > > > > Indeed I now see the problem myself. I've just been bitten by this while building stimfit into a fresh unstable sbuild chroot. Setting once and for all the correct permissions using sbuild-shell fixed the problem for this chroot: $ echo "/bin/chown root:root / && /bin/chmod a+rX /" | \ sudo sbuild-shell > > > > > Can you confirm something for me? > > > > > > > > > > Above you quote an sbuild-createchroot command. Could you run the > > > > > same command > > > > > on your machine again but with --debootstrap=mmdebstrap in it? > > > > > > > > > > Because for me, that fixes the problem. This suggests that the > > > > > problem is not > > > > > with sbuild but with the program that creates the chroot: > > > > > debootstrap > > > > > > > > something else you can try: Instead of adding -- > > > > debootstrap=mmdebstrap try > > > > adding --no-merged-usr to your sbuild-createchroot invocation. This > > > > also fixed > > > > the problem for me. > > > > > > > > So it seems whatever it is, and whoever is at fault, this problem is > > > > not > > > > severity "serious", thus lowering severity accordingly. > > > > > > > > > > No. Also with a schroot build with --no-merged-usr I get: > > > > did you also try with --debootstrap=mmdebstrap instead of --no-merged-usr? > > could you follow up on this? Indeed, this is OK with --debootstrap=mmdebstrap. Thanks, _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
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#953021: libhdf5-mpi-dev: provide links to default mpi (hdf5-mpi.pc)
Drew Parsons a écrit le 18/03/2020 à 11:32 :
> On 2020-03-18 17:42, Gilles Filippini wrote:
>> Gilles Filippini a écrit le 17/03/2020 à 17:59 :
>>>
>>> As I understand it now, this is do-able if and only if there is a way to
>>> add a slave to an existing alternative. But I can't find such a way. Any
>>> idea?
>
> Looks like you got an idea before I did on how to do it before I do :)
Well, this is quite cumbersome: parse the existing alternatives using
'u-a --query mpi' then reinstall the whole alternative plus (or minus)
the (un)wanted '--slave' part.
>> I'm almost done, but there is a corner case we have to accept. When:
>> 1- Default MPI toolchain for the arch is installed
>> 2- The selected 'mpi' alternative points to this default MPI toolchain
>> 3- The libhdf5--dev flavor for this default toolchain is NOT
>> installed
>> 4- Another libhdf5--dev flavor is installed
>> Then the hdf5-mpi.pc slave points to nothing until one of these
>> conditions is satisfied:
>> * The libhdf5--dev flavor for this default toolchain is installed
>> or
>> * The 'mpi' alternative points to the MPI flavor corresponding to the
>> installed libhdf5--dev.
>>
>> Do we agree?
>
>
> That sounds perfectly reasonable.
>
> That scenario is odd, and very specific. It means the system
> administrator has deliberately chosen to not install the preferred
> hdf5- and to install the non-preferred
> hdf5- instead ("preferred" in the mpi alternatives
> sense).
>
> In those conditions it's reasonable that users of that system should
> need to be specific about which hdf5-mpi they're using, invoking
> "pkg-config --cflags hdf5-" rather than "pkg-config
> --cflags hdf5-mpi". Their system administrator can still configure
> their preferred hdf5 so they can use "pkg-config --cflags hdf5" to
> access their hdf5-, if they want.
OK. I'll upload soon to experimental.
> Thanks for sorting through the alternatives logic.
I learned things :)
Best,
_g.
signature.asc
Description: OpenPGP digital signature
Bug#953021: libhdf5-mpi-dev: provide links to default mpi (hdf5-mpi.pc)
Gilles Filippini a écrit le 17/03/2020 à 17:59 : > Gilles Filippini a écrit le 16/03/2020 à 17:56 : >> Hi Drew, >> >> Drew Parsons a écrit le 03/03/2020 à 19:43 : >>> Thinking about it, if possible it would be best to have hdf5-mpi.pc >>> managed by update-alternatives, but tracking the mpi alternative. >>> >>> i.e. set up as a slave alternative depending on mpi, that updates if the >>> local system switches mpi from openmpi to mpich. >>> >>> I'm not sure if this can be done cross-package, but good if it can. >>> >>> If it can be done, then the control logic would go in the postinst/prerm >>> of libhdf5-openmpi-dev and libhdf5-mpich-dev rather than libhdf5-mpi-dev. >> >> I'm not sure what you have in mind here. I've just uploaded a new >> release to experimental which should fix #953020. It may covers #953021 >> as well. Please let me know... > > As I understand it now, this is do-able if and only if there is a way to > add a slave to an existing alternative. But I can't find such a way. Any > idea? I'm almost done, but there is a corner case we have to accept. When: 1- Default MPI toolchain for the arch is installed 2- The selected 'mpi' alternative points to this default MPI toolchain 3- The libhdf5--dev flavor for this default toolchain is NOT installed 4- Another libhdf5--dev flavor is installed Then the hdf5-mpi.pc slave points to nothing until one of these conditions is satisfied: * The libhdf5--dev flavor for this default toolchain is installed or * The 'mpi' alternative points to the MPI flavor corresponding to the installed libhdf5--dev. Do we agree? _g. signature.asc Description: OpenPGP digital signature
Bug#953021: libhdf5-mpi-dev: provide links to default mpi (hdf5-mpi.pc)
Gilles Filippini a écrit le 16/03/2020 à 17:56 : > Hi Drew, > > Drew Parsons a écrit le 03/03/2020 à 19:43 : >> Thinking about it, if possible it would be best to have hdf5-mpi.pc >> managed by update-alternatives, but tracking the mpi alternative. >> >> i.e. set up as a slave alternative depending on mpi, that updates if the >> local system switches mpi from openmpi to mpich. >> >> I'm not sure if this can be done cross-package, but good if it can. >> >> If it can be done, then the control logic would go in the postinst/prerm >> of libhdf5-openmpi-dev and libhdf5-mpich-dev rather than libhdf5-mpi-dev. > > I'm not sure what you have in mind here. I've just uploaded a new > release to experimental which should fix #953020. It may covers #953021 > as well. Please let me know... As I understand it now, this is do-able if and only if there is a way to add a slave to an existing alternative. But I can't find such a way. Any idea? Thanks, _g. signature.asc Description: OpenPGP digital signature
Bug#953021: libhdf5-mpi-dev: provide links to default mpi (hdf5-mpi.pc)
Hi Drew, Drew Parsons a écrit le 03/03/2020 à 19:43 : > Thinking about it, if possible it would be best to have hdf5-mpi.pc > managed by update-alternatives, but tracking the mpi alternative. > > i.e. set up as a slave alternative depending on mpi, that updates if the > local system switches mpi from openmpi to mpich. > > I'm not sure if this can be done cross-package, but good if it can. > > If it can be done, then the control logic would go in the postinst/prerm > of libhdf5-openmpi-dev and libhdf5-mpich-dev rather than libhdf5-mpi-dev. I'm not sure what you have in mind here. I've just uploaded a new release to experimental which should fix #953020. It may covers #953021 as well. Please let me know... Thanks, _g. signature.asc Description: OpenPGP digital signature
Bug#951276: default webinterface non-functional
Balint Reczey a écrit le 27/02/2020 à 19:24 : >>> I took a look and the situation did improve license-wise, but Kodi ships >>> addons/webinterface.default/js/kodi-webinterface.js which is a >>> minimized version of >>> https://github.com/xbmc/chorus2 . It needs to be packages separately, >>> see, the linked RFP bug. >>> >>> When Chorus2 is shipped in Debian properly rebuilding it from source >>> then the kodi package can switch to using it. >> I have no experience at all packaging such a software. How about first >> repacking kodi with Chorus2 source tree so it could quickly enter >> experimental, then splitting it out into a separate package once it is >> functionnal? > A much better approach IMO is dropping the addon from kodi-data binary > package and providing the current drop-in web interface as a temporary > binary package that chorus2 will replace. Sounds good. Best, _g. signature.asc Description: OpenPGP digital signature
Bug#951276: default webinterface non-functional
Hi, Bálint Réczey a écrit le 26/02/2020 à 18:24 : > Control: tags -1 help > Control: block -1 by 851663 > > Hi Gilles, > > Bálint Réczey ezt írta (időpont: 2020. febr. > 25., K, 23:32): >> >> Hi, >> >> Gilles Filippini ezt írta (időpont: 2020. febr. 25., >> K, 23:12): >>> >>> Hi, >>> >>> On Thu, 13 Feb 2020 17:48:57 +0100 Roderich Schupp >>> wrote: >>>> Package: kodi-data >>>> Version: 2:18.5+dfsg1-1~exp0 >>>> Severity: normal >>>> >>>> The default webinterface shows just a header bar, >>>> see attached screenshot. >>>> >>>> The webinterface.default included in the Debian package is >>>> seriously outdated, the current Kodi v18 webinterface >>>> is here: https://github.com/xbmc/chorus2/releases/tag/18.x-2.4.6 >>> >>> d/README.source says: >>>> Kodi replaced the default webinterface in 17.0 beta6 but the new interface >>>> contains >>>> many generated files without providing the source for them. The web >>>> interface >>>> is temporarily reverted to the one included in beta5 to restore GPL >>>> compliance. >>> >>> And Balint filed a related upstream issue: >>> https://github.com/xbmc/chorus2/issues/179 >>> >>> @Balint, from your last comment on this issue it seems the only >>> litigious material left is the screenshots. Are these images requested >>> for running the chorus2 web interface? Couldn't they be removed from the >>> upstream source package until they are fixed? >> >> The upstream source needs a new review to see which files should be dropped. >> If those are just a few images like the screenshots I'm ready to >> create a new +dfsg2 source and ship the new web interface. >> >> Help is very welcome here, since I'm currently busy with other >> packages, but otherwise the kodi 18 packages are close to ready for >> upload to unstable. I'd be happy to help. But I'm not at ease on this very topic. I've just recently discovered kodi. I'm still wondering about installing it. I'd like a fully functionnal server installation, accesed from the webinterface only. > I took a look and the situation did improve license-wise, but Kodi ships > addons/webinterface.default/js/kodi-webinterface.js which is a > minimized version of > https://github.com/xbmc/chorus2 . It needs to be packages separately, > see, the linked RFP bug. > > When Chorus2 is shipped in Debian properly rebuilding it from source > then the kodi package can switch to using it. I have no experience at all packaging such a software. How about first repacking kodi with Chorus2 source tree so it could quickly enter experimental, then splitting it out into a separate package once it is functionnal? Best, _g. signature.asc Description: OpenPGP digital signature
Bug#951276: default webinterface non-functional
Hi, On Thu, 13 Feb 2020 17:48:57 +0100 Roderich Schupp wrote: > Package: kodi-data > Version: 2:18.5+dfsg1-1~exp0 > Severity: normal > > The default webinterface shows just a header bar, > see attached screenshot. > > The webinterface.default included in the Debian package is > seriously outdated, the current Kodi v18 webinterface > is here: https://github.com/xbmc/chorus2/releases/tag/18.x-2.4.6 d/README.source says: > Kodi replaced the default webinterface in 17.0 beta6 but the new interface > contains > many generated files without providing the source for them. The web interface > is temporarily reverted to the one included in beta5 to restore GPL > compliance. And Balint filed a related upstream issue: https://github.com/xbmc/chorus2/issues/179 @Balint, from your last comment on this issue it seems the only litigious material left is the screenshots. Are these images requested for running the chorus2 web interface? Couldn't they be removed from the upstream source package until they are fixed? Thanks, _g. signature.asc Description: OpenPGP digital signature
Bug#951856: jython-stilts: Wrong permissions on /usr/share/jython/Lib/site-packages/stilts$py.class
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#949394: libsmbclient: smbclient and others cannot rename remote files
By reverting libsmbclient to stretch version, correct behaviour is restored: $ sudo apt install smbclient/stretch libwbclient0/stretch samba-libs/stretch libsmbclient/stretch libldb1/stretch $ dpkg -l libsmbclient Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==-==--== hi libsmbclient:amd64 2:4.5.16+dfsg-1+deb9u2 amd64 shared library for communication with SMB/CIFS servers $ smbclient //SMBSERVER/tmp WARNING: The "syslog" option is deprecated Enter gilles's password: Domain=[WORKGROUP] OS=[Windows 6.1] Server=[Samba 4.4.16] smb: \> ls . DA 0 Wed Jan 22 08:59:54 2020 .. DA 0 Wed Jan 29 02:04:57 2020 3746086260 blocks of size 1024. 1360087588 blocks available smb: \> put hello.txt putting file hello.txt as \hello.txt (0.7 kb/s) (average 0.7 kb/s) smb: \> rename hello.txt hello2.txt smb: \> ls . DA 0 Wed Jan 29 13:32:43 2020 .. DA 0 Wed Jan 29 02:04:57 2020 hello2.txt A 6 Wed Jan 29 13:32:32 2020 3746086260 blocks of size 1024. 1360087588 blocks available smb: \>
Bug#949950: ITP: libh5cpp-dev -- H5CPP is a novel approach to persistence in the field of machine learning and science, it provides high performance sequential and block access to HDF5 containers thro
Control: retitle -1 ITP: libh5cpp -- c++ header only library for HDF5 dataformat ste...@vargaconsulting.ca a écrit le 27/01/2020 à 16:03 : > Package: wnpp > Severity: wishlist > Owner: ste...@vargaconsulting.ca > > * Package name: libh5cpp-dev The source package name is: libh5cpp. > Version : 1.10.4.5 > Upstream Author : Steven Varga > * URL : http://h5cpp.org/ > * License : MIT > Programming Lang: C++ > Description : H5CPP is a novel approach to persistence in the field of > machine learning and science, it provides high performance sequential and > block access to HDF5 containers through modern C++ templates. It supports > major linear algebra libraries such as armadillo, eigen3, dlib, itpp, blaze, > boost::ublas in addition to stl::vector. And it has an amitious plan to > provide quality non-intrusive persistence for arbitrary C++ objects. > > > H5CPP and its LLVM based companion the H5CPP-COMPILER was first introduced in > Chicago C++ usergroup meeting in 2018 fall, has been presented at ISC'19 BOF > and is a collaboration between The HDFGroup and the author. The package is to > replace the somewhat outdated HDF5 C++ library. Its RAII enabled resource > handles are fully interchangeable with HDF5 CAPI hid_t, and in most cases are > binary compatible. The origins of H5CPP roots in High Frequency Trading data > solutions, where having low latency high throughput sequential and block data > access is critical. Since the inception of H5CPP the code has been used for > general scientific purposes on supercomputers and workstations, is found to > be useful in sensor networks and particle colliders. > > The following packages has been examined before development:HDF5 C++, > ess-dmsc/h5cpp, HighFive by Blue Brain, H5TL, HDF5Wrapper, hdf5wrap, hdf5pp, > H5Easy > before the development of this project, and many of the shortcomings has been > addressed. In terms of maintainability, functionality and performance it is > found to be ahead of alternative solutions, with its companion package: H5CPP > COMPILER, it provides assisted reflection based persistence bringing C++ > planned reflection/introspection into today. > > H5CPP is constantly improved and may be influenced by attending the HDF5 C++ > user group meetings, or through direct contact with author. > > Future plans: In the next release full STL object support with arbitrary POD > and standard layout types; shifting towards template based introspection, > sparse linear algebra support and interop with modern statistical platforms > (julia, python, R), multi dataset support for complex object types. In the > current research phase the author began collaborating with domain specific > format authors to standardise and support higher level formats in fields > such as genetics, visualisation/graphics, physics, ... . > > Maintenance and sponsor: the author, steven varga is to maintain the library, > and yes looking for sponsor > > website: http://h5cpp.org > documentation: http://sandbox.h5cpp.org/ > ISC'19 Frankfurt presentation: http://isc19.h5cpp.org/ > 2019 HDFGroup webinar: https://www.youtube.com/watch?v=7A5dPL7zrj0=56s > webinar-slides: http://webinar.h5cpp.org/ > HDFGroup blog(copy): http://sandbox.h5cpp.org/blog/ > Repository: https://github.com/steven-varga/h5cpp > > signature.asc Description: OpenPGP digital signature
Bug#949951: ITP: h5cpp-compiler -- This LLVM/clang based C++ source code transformation tool automates the otherwise time consuming, error prone process of generating type descriptors for HDF5 Compoun
Control: retitle -1 ITP: h5cpp-compiler -- compiler to generate HDF5 compound type descriptor from POD types ste...@vargaconsulting.ca a écrit le 27/01/2020 à 16:11 : > Package: wnpp > Severity: wishlist > Owner: ste...@vargaconsulting.ca > > * Package name: h5cpp-compiler > Version : 1.10.4.5 > Upstream Author : Steven Varga > * URL : http://h5cpp.org/ > * License : MIT > Programming Lang: C++ > Description : This LLVM/clang based C++ source code transformation tool > automates the otherwise time consuming, error prone process of generating > type descriptors for HDF5 Compound datatypes by building the AST of a given > TU translation unit, and identifying all POD datatypes referenced from H5CPP > operators/functions. The result is a seamless, non-intrusive persistence much > similar to python, java or other interpreted languages. > > > This LLVM/clang based C++ source code transformation tool automates the > otherwise time consuming, error prone process of generating type descriptors > for HDF5 Compound datatypes by building the AST of a given TU translation > unit, and identifying all POD datatypes referenced from H5CPP > operators/functions. The result is a seamless, non-intrusive persistence much > similar to python, java or other interpreted languages. > With its companion, the H5CPP C++ header library, provides high performance > low latency, non-introusive persistence support for modern C++. Its > application is to aid easy data transfer from memory and persistent storage > by simply including the header files and calling one of the H5CPP CRUD like > operators. > > AFAIK the author is not aware of the existence of similar packages, however > is constantly monitoring the current state of C++ reflection and > introspection with the intention of replacing the compiler once the new C++ > features become available. > > This package depends on the LLVM/clang front end, and requires the companion > libh5cpp-dev to perform compile time reflection/introspection. > > Much similar to libh5cpp package I intend to maintain the H5CPP COMPILER > and looking for sponsor. > > website: http://h5cpp.org > ISC'19 presentation: http://isc19.h5cpp.org/#/2 > repository: https://github.com/steven-varga/h5cpp-compiler > > signature.asc Description: OpenPGP digital signature
