Bug#1078987: cbflib: FTBFS against HDF5 1.14 - Needs -DH5_USE_110_API
Source: cbflib
Version: 0.9.7+dfsg1-3.1
Severity: important
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
The cbflib package fails to build from source in a test rebuild
against hdf5 1.14 currently in experimental:
gcc -g -O2 -Werror=implicit-function-declaration
-ffile-prefix-map=/<>=. -fstack-protector-strong
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
-Wdate-time -D_FORTIFY_SOU
RCE=2 -g -O3 -Wall -D_USE_XOPEN_EXTENDED -fno-strict-aliasing
-DCBF_REGEXLIB_REGEX-fPIC -I/<>/include -I/<>/src
-I/usr/include/hdf5/serial -c /<>/src/cbf.c /<>/src/cbf_airy_disk.c /<>/src/cbf_alloc.c
/<>/src/cbf_ascii.c /<>/src/cbf_binary.c
/<>/src/cbf_byte_offset.c /<>/src/cbf_canonical.c /<>/src/cbf_codes.c /<>/src/cbf_compress.c
/<>/src/cbf_context.c /<>/src/cbf_copy.c
/<>/src/cbf_file.c /<>/src/cbf_getopt.c /<>/src/cbf_hdf5.c /<>/src/cbf_hdf5_filter.c
/<>/src/cbf_lex.c /<>/src/cbf_minicbf_header.c
/<>/src/cbf_nibble_offset.c /<>/src/cbf_packed.c /<>/src/cbf_predictor.c /<>/src/cbf_read_binary.c
/<>/src/cbf_read_mime.c /<>/src/cbf_simple.c
/<>/src/cbf_string.c /<>/src/cbf_stx.c /<>/src/cbf_tree.c /<>/src/cbf_uncompressed.c
/<>/src/cbf_write.c /<>/src/cbf_write_binary.c
/<>/src/cbf_ws.c /<>/src/cbff.c /<>/src/md5c.c /<>/src/img.c /<>/src/fgetln.c
/<>/src/cbf.c: In function ‘cbf_select_saveframe’:
/<>/src/cbf.c:2498:3: warning: this ‘if’ clause does not guard...
[-Wmisleading-indentation]
2498 | if (!handle)
| ^~
In file included from /<>/src/cbf.c:256:
/<>/include/cbf.h:895:24: note: ...this statement, but the latter
is misleadingly indented as if it were guarded by the ‘if’
895 | #define cbf_failnez(f) { int err; err = (f); if (err) return err; }
|^
/<>/src/cbf.c:2505:5: note: in expansion of macro ‘cbf_failnez’
2505 | cbf_failnez (cbf_find_parent (&node, handle->node, CBF_DATABLOCK))
| ^~~
In file included from /usr/include/hdf5/serial/H5public.h:31,
from /usr/include/hdf5/serial/hdf5.h:21,
from /<>/include/cbf.h:253,
from /<>/src/cbf_hdf5.c:258:
/<>/src/cbf_hdf5.c: In function ‘cbf_H5Ocmp’:
/usr/include/hdf5/serial/H5version.h:921:23: error: too few arguments to
function ‘H5Oget_info3’
921 | #define H5Oget_info H5Oget_info3
| ^~~~
/<>/src/cbf_hdf5.c:3948:27: note: in expansion of macro
‘H5Oget_info’
3948 | herr_t err0 = H5Oget_info(id0,&info0);
| ^~~
Adding -DH5_USE_110_API to CPPFLAGS fixes the issue.
Best,
_g.
- -- System Information:
Debian Release: 12.0
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-21-amd64 (SMP w/12 CPU threads; PREEMPT)
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/+z4MFAmbCI5kACgkQ7+hsbH/+
z4N6mQf7BKNdfFRtLGCdEfmWqey4Bv0vJRmct07o+2BlcR7tGdzCsoBxSpEjvNLl
NjqEs0a8/3yOSSvOIvMvrzYTxJtIjBHABNVb/M3RzTpgftwc1waG7jIXUam+Xwx/
BwNS0m6UNrrSJBcbAPStH4ewRA2MxkmzP0PN5LeIfgZRr5ouOhnxwIyjOoZbY7KP
bXPdiirf1irlQbFTHXNjRsZgVMsDooCFIJufYfmwKNj2ZJF278qvS4TusijsnRsX
eY9jqijWL9sHJ39U3MJOIKyI2vvIpivfsD7E+PIJ/aFWaVRzKGXGb4nsrUVsU7iy
B2l2A1tmDNkaNU6p0fT0avIkczgnfw==
=IbXS
-END PGP SIGNATURE-
Bug#1078984: csound-plugins: FTBFS against HDF5 1.14 - Needs -DH5_USE_110_API
Source: csound-plugins Version: 1.0.2~dfsg1-3 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, The csound-plugins package fails to build from source in a test rebuild against hdf5 1.14 currently in experimental: cd "/<>/obj-x86_64-linux-gnu/hdf5" && /usr/bin/cc -DHAVE_SOCKETS -DHDF5_VERSION_MAJOR=1 -DHDF5_VERSION_MINOR=14 -DHDF5_VERSION_PATCH=4-3 -DLINUX -DNO_FLTK_THREADS -DPIPES -D_GNU_SOURCE -Dhdf5ops_EXP ORTS -I/usr/include/hdf5/serial -I/usr/include/csound -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-s ecurity -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -g -ffast-math -mfpmath=sse -msse2 -fomit-frame-pointer -fvisibility=hidden -std=gnu99 -DHAVE_PTHREAD -fPIC -MD -MT hdf5/CMakeFiles/hdf5ops.dir/HDF5IO.c.o - -MF CMakeFiles/hdf5ops.dir/HDF5IO.c.o.d -o CMakeFiles/hdf5ops.dir/HDF5IO.c.o -c "/<>/hdf5/HDF5IO.c" In file included from /usr/include/csound/csoundCore.h:35, from /usr/include/csound/csdl.h:111, from /<>/hdf5/HDF5IO.h:20, from /<>/hdf5/HDF5IO.c:20: /<>/hdf5/HDF5IO.c: In function ‘HDF5IO_readStringAttribute’: /<>/hdf5/HDF5IO.c:233:39: error: passing argument 2 of ‘H5Oget_info1’ from incompatible pointer type [-Wincompatible-pointer-types] 233 | HDF5ERROR(H5Oget_info1(dataSetID, &oinfo)); | ^~ | | | H5O_info2_t * /usr/include/csound/sysdep.h:345:45: note: in definition of macro ‘UNLIKELY’ 345 | # define UNLIKELY(x) __builtin_expect(!!(x),0) | ^ /<>/hdf5/HDF5IO.c:233:5: note: in expansion of macro ‘HDF5ERROR’ 233 | HDF5ERROR(H5Oget_info1(dataSetID, &oinfo)); | ^ In file included from /usr/include/hdf5/serial/H5Apublic.h:21, from /usr/include/hdf5/serial/hdf5.h:22, from /<>/hdf5/HDF5IO.h:21: /usr/include/hdf5/serial/H5Opublic.h:1854:55: note: expected ‘H5O_info1_t *’ but argument is of type ‘H5O_info2_t *’ 1854 | H5_DLL herr_t H5Oget_info1(hid_t loc_id, H5O_info1_t *oinfo); | ~^ make[3]: *** [hdf5/CMakeFiles/hdf5ops.dir/build.make:79: hdf5/CMakeFiles/hdf5ops.dir/HDF5IO.c.o] Error 1 Adding -DH5_USE_110_API to CPPFLAGS fixes the issue. Best, _g. - -- System Information: Debian Release: 12.0 Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-21-amd64 (SMP w/12 CPU threads; PREEMPT) 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/+z4MFAmbCG44ACgkQ7+hsbH/+ z4NwaQgAhaHtXn2P+VVMiieelLLuGbDdeC4cQv13kftPPCZVzTC42yZ+V2C6nSw3 AkCjsLsh0fYwYb+TbcND/9rP9QbjeZ+ljUMGaSxw2bINUGffYTF3oaRhoHLq7yMo /aAgvqnV6CAmRMBZgJWT27abloRN3KcY3LKehXORUc/povitumomrG5MR+VuqKb+ 4zTb8NmH2+/6vconNsd0NoHOHtEZZf8Cay0jVd7EdYXZAJQAuYoiYltF2Gbzgu5e MfgqfvRwjBsXLVo6ky1o5EhrrOkoI0yafTniVma5kDSQfWRqyrO0bWXLABXVR3zR sn2dWi/Aoowp/RAVgII6SOrHJIa2+g== =Qn4G -END PGP SIGNATURE-
Bug#1078982: uncalled: FTBFS against HDF5 1.14 - Needs -DH5_USE_110_API
Source: uncalled
Version: 2.3+ds-1
Severity: important
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
The uncalled package fails to build from source in a test rebuild
against hdf5 1.14 currently in experimental:
x86_64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall
-g -O2 -Werror=implicit-function-declaration
-ffile-prefix-map=/<>=. -fstack-protector-strong
-fstack-clash-protection
- -Wformat -Werror=format-security -fcf-protection -Wdate-time
-D_FORTIFY_SOURCE=2 -fPIC -DPYBIND -I./submods -I/usr/include/hdf5/serial
-I/usr/include/fast5/ -I/usr/include/ -I/usr/lib/python3/dist-packages/pybin
d11/include -I/usr/include/python3.12 -c src/chunk.cpp -o
build/temp.linux-x86_64-cpython-312/src/chunk.o -std=c++11 -O3
cc1plus: warning: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’
is not valid for C++
In file included from src/read_buffer.hpp:30,
from src/chunk.cpp:3:
/usr/include/fast5/hdf5_tools.hpp: In member function
‘std::vector >
hdf5_tools::File::get_attr_list(const std::string&) const’:
/usr/include/fast5/hdf5_tools.hpp:2110:27: error: no matching function for call
to ‘hdf5_tools::detail::Util::wrap(herr_t (&)(hid_t, H5O_info2_t*, unsigned
int), hid_t&, H5O_info2_t*) const’
2110 | detail::Util::wrap(H5Oget_info, id_holder.id, &info);
| ~~^~
/usr/include/fast5/hdf5_tools.hpp:244:5: note: candidate: ‘template static typename std::result_of<_Functor(_ArgTypes
...)>::type hdf5_tools::detail::Util::wrap(Function&&, Args&& ...)’
244 | wrap(Function && f, Args && ...args)
| ^~~~
/usr/include/fast5/hdf5_tools.hpp:244:5: note: template argument
deduction/substitution failed:
/usr/include/fast5/hdf5_tools.hpp: In substitution of ‘template static typename std::result_of<_Functor(_ArgTypes ...)>::type
hdf5_tools::detail::Util::wrap(Function&&, Args&& ...) [with Function = int
(&)(long int, H5O_info2_t*, unsigned int); Args = {long int&, H5O_info2_t*}]’:
/usr/include/fast5/hdf5_tools.hpp:2110:27: required from here
2110 | detail::Util::wrap(H5Oget_info, id_holder.id, &info);
| ~~^~
/usr/include/fast5/hdf5_tools.hpp:244:5: error: no type named ‘type’ in ‘struct
std::result_of’
244 | wrap(Function && f, Args && ...args)
| ^~~~
Adding -DH5_USE_110_API to CPPFLAGS solves the issue.
Please note that the same fix should be applied to fast5 first (#1078976).
Best,
_g.
- -- System Information:
Debian Release: 12.0
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-21-amd64 (SMP w/12 CPU threads; PREEMPT)
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/+z4MFAmbCCaIACgkQ7+hsbH/+
z4OEMgf/aiZGwhZyzy7wC7OJYykTVP7YxuuyFPeSmZiNyHyMRZi/8Oar8V8ZOnuA
5OfEVO724IcvZ7lRmp7GI4qhRuYebOQFROPCmecJqt5Uck9jNRRBFJ4PtJEWXwJ0
z98/l+kn4rPDENXvEVavNUyvnSzy3Wh/qAIuYYN/35suM6ai/zc4GefSNoFmpKL2
ZXK7UuGtwcNiTdIaPyk2p/t2A1B0VNrACasoOxv9MwvdNxf4DPPDq/Cbxg93IKb2
uAYhmAiKdVcGfzxu5Vw9DsIbutpaf1aVua9tvWiFjetKry8NmOK9dWDEtIAYvRiD
4i1tAxg77BNQYaeIfpcybNTHVCp11w==
=hlt6
-END PGP SIGNATURE-
Bug#1078976: fast5: FTBFS against HDF5 1.14 - Needs -DH5_USE_110_API
Source: fast5
Version: 0.6.5-7
Severity: important
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
The fast5 package fails to build from source in a test rebuild
against hdf5 1.14 currently in experimental:
x86_64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall
-g -O2 -Werror=implicit-function-declaration
-ffile-prefix-map=/<>=. -fstack-protector-strong
-fstack-clash-protection
- -Wformat -Werror=format-security -fcf-protection -Wdate-time
-D_FORTIFY_SOURCE=2 -fPIC -I../include -I../src -I/usr/include/python3.12 -c
fast5/fast5.cpp -o build/temp.linux-x86_64-cpython-312/fast5/fast5.o -std
=c++11 -Wall -Wextra -Wpedantic -isystem /usr/include/hdf5/serial
cc1plus: warning: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’
is not valid for C++
In file included from ../include/fast5.hpp:27,
from fast5/fast5.cpp:1292:
../include/fast5/hdf5_tools.hpp: In member function
‘std::vector >
hdf5_tools::File::get_attr_list(const std::string&) const’:
../include/fast5/hdf5_tools.hpp:2110:27: error: no matching function for call
to ‘hdf5_tools::detail::Util::wrap(herr_t (&)(hid_t, H5O_info2_t*, unsigned
int), hid_t&, H5O_info2_t*) const’
2110 | detail::Util::wrap(H5Oget_info, id_holder.id, &info);
| ~~^~
../include/fast5/hdf5_tools.hpp:244:5: note: candidate: ‘template static typename std::result_of<_Functor(_ArgTypes
...)>::type hdf5_tools::detail::Util::wrap(Function&&, Args&& ...)’
244 | wrap(Function && f, Args && ...args)
| ^~~~
../include/fast5/hdf5_tools.hpp:244:5: note: template argument
deduction/substitution failed:
../include/fast5/hdf5_tools.hpp: In substitution of ‘template static typename std::result_of<_Functor(_ArgTypes ...)>::type
hdf5_tools::detail::Util::wrap(Function&&, Args&& ...) [with Function = int
(&)(long int, H5O_info2_t*, unsigned int); Args = {long int&, H5O_info2_t*}]’:
../include/fast5/hdf5_tools.hpp:2110:27: required from here
2110 | detail::Util::wrap(H5Oget_info, id_holder.id, &info);
| ~~^~
../include/fast5/hdf5_tools.hpp:244:5: error: no type named ‘type’ in ‘struct
std::result_of’
244 | wrap(Function && f, Args && ...args)
| ^~~~
Adding -DH5_USE_110_API to CPPFLAGS fixes the issue.
Best,
_g.
- -- System Information:
Debian Release: 12.0
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-21-amd64 (SMP w/12 CPU threads; PREEMPT)
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/+z4MFAmbB/FsACgkQ7+hsbH/+
z4PxuggAi4E972Flp4YpyydI8HMJB00y4dne9qU3ON3CXBpfWgkgpVEVEAQHQ2Ji
DLbnfIsHnDPxQtTy76Qipu6fBipNE9AjRkb3hQ1ou3zfksC5wq8GIJChi5s6NBXZ
M/wBb2GG4c5HOrDw7y7JhYFFDlpPuK3zVeocYVMFB6MjWKwZKZfGMgoO85AdosMd
6C94onozMYhqiLfSBngjr0xcCcGy+UNMnv+eMOuPCv+sFjpBAqfDU5XVsmO1wzIJ
YoS118swBa6DId4TyzCyL4CJdWYtu0s+ohumkMmjvsddw6eLNreTO5dbqF0xa5kZ
1kBQ00xbAcOi4Rb+1BOEKQETpqOXiQ==
=zyjJ
-END PGP SIGNATURE-
Bug#1078975: field3d: FTBFS against HDF5 1.14 - Needs -DH5_USE_110_API
Source: field3d Version: 1.7.3-4.1 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, The field3d package fails to build from source in a test rebuild against hdf5 1.14 currently in experimental: /<>/src/Field3DFileHDF5.cpp: In function ‘herr_t Field3D::v1_7::InputFileHDF5::parsePartitions(hid_t, const char*, const H5L_info2_t*, void*)’: /<>/src/Field3DFileHDF5.cpp:1138:31: error: too few arguments to function ‘herr_t H5Oget_info_by_name3(hid_t, const char*, H5O_info2_t*, unsigned int, hid_t)’ 1138 | status = H5Oget_info_by_name(loc_id, itemName, &infobuf, H5P_DEFAULT); In file included from /usr/include/hdf5/serial/H5Apublic.h:21, from /usr/include/hdf5/serial/hdf5.h:22, from /<>/src/Field3DFileHDF5.cpp:50: /usr/include/hdf5/serial/H5Opublic.h:541:15: note: declared here 541 | H5_DLL herr_t H5Oget_info_by_name3(hid_t loc_id, const char *name, H5O_info2_t *oinfo, unsigned fields, | ^~~~ /<>/src/Field3DFileHDF5.cpp: In function ‘herr_t Field3D::v1_7::InputFileHDF5::parseLayers(hid_t, const char*, const H5L_info2_t*, void*)’: /<>/src/Field3DFileHDF5.cpp:1178:32: error: too few arguments to function ‘herr_t H5Oget_info_by_name3(hid_t, const char*, H5O_info2_t*, unsigned int, hid_t)’ 1178 | status = H5Oget_info_by_name (loc_id, itemName, &infobuf, H5P_DEFAULT); /usr/include/hdf5/serial/H5Opublic.h:541:15: note: declared here 541 | H5_DLL herr_t H5Oget_info_by_name3(hid_t loc_id, const char *name, H5O_info2_t *oinfo, unsigned fields, | ^~~~ In file included from /<>/export/FieldMapping.h:52, from /<>/export/Field.h:57, from /<>/export/ClassFactory.h:51, from /<>/src/ClassFactory.cpp:44: /<>/export/Curve.h:133:17: warning: ‘template struct std::unary_function’ is deprecated [-Wdeprecated-declarations] 133 | public std::unary_function, bool> | ^~ In file included from /usr/include/c++/14/bits/unique_ptr.h:38, from /usr/include/c++/14/memory:78, from /usr/include/boost/smart_ptr/scoped_ptr.hpp:23, from /usr/include/boost/scoped_ptr.hpp:13, from /<>/export/ClassFactory.h:47: /usr/include/c++/14/bits/stl_function.h:117:12: note: declared here 117 | struct unary_function |^~ /<>/export/Curve.h:148:17: warning: ‘template struct std::unary_function’ is deprecated [-Wdeprecated-declarations] 148 | public std::unary_function, bool> | ^~ /usr/include/c++/14/bits/stl_function.h:117:12: note: declared here 117 | struct unary_function |^~ make[3]: *** [CMakeFiles/Field3D.dir/build.make:121: CMakeFiles/Field3D.dir/src/Field3DFileHDF5.cpp.o] Error 1 Adding -DH5_USE_110_API to CFLAGS and CXXFLAGS should fix the problem. Best, _g. - -- System Information: Debian Release: 12.0 Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-21-amd64 (SMP w/12 CPU threads; PREEMPT) 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/+z4MFAmbB9A8ACgkQ7+hsbH/+ z4P13Qf/altZ6RWH8GIvDcwXQ35KewagBGoHeg8DzvtS5GoQa2ywPnJtfGB8q+5u itLWYIGv8AaQjTbc9LpX3LcsKEOfjSa5ZYfuBDM/aJp3dddzpO4dOJ68ytZbTv2Y rHjKdhqXUvukqt8kdH5oV5Aq/pj1+9kZaTo4mKq3XbTwQWWIswjEYM/Cg31rxMJV 1bLarJZKDfHacakXvvx0Eg02SrG34CtwxRGrrNOyjEcFc48dKP4EitfhlUUEbF5n wVPNHWjm0CGrb96GeS8nBW70RzwpvKrxFeMlDbPDTD5CQoTU1zd+gDILBHQPCzzg vcbrhVZzO/CEgFw5NvXvQF8DkItw/Q== =0aRd -END PGP SIGNATURE-
Bug#1078968: libsis-jhdf5-java: FTBFS against HDF5 1.14
Source: libsis-jhdf5-java Version: 19.04.1+dfsg-6 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, The libsis-jhdf5-java package fails to build from source in a test rebuild against hdf5 1.14 currently in experimental. Full build log attached, although I fail to see any relevant information in there: Compiling with Java command line compiler 'java'. Starting process 'command 'java''. Working directory: /<> Command: java -cp /usr/share/java/eclipse-jdt-core.jar:/usr/share/java/eclipse-jdt-compiler-apt.jar org.eclipse.jdt.internal.compiler.batch. Main -nowarn @/<>/targets/gradle/tmp/compileJava/java-compiler-args.txt Successfully started process 'command 'java'' Error: Could not find or load main class org.eclipse.jdt.internal.compiler.batch.Main Caused by: java.lang.ClassNotFoundException: org.eclipse.jdt.internal.compiler.batch.Main :compileJava FAILED :compileJava (Thread[#53,Task worker for ':' Thread 4,5,main]) completed. Took 9.352 secs. FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':compileJava'. > Compilation failed with exit code 1; see the compiler error output for > details. * Try: Run with --debug option to get more log output. Run with --scan to get full insights. * Exception is: org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':compileJava'. Best, _g. - -- System Information: Debian Release: 12.0 Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-21-amd64 (SMP w/12 CPU threads; PREEMPT) 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/+z4MFAmbB4mQACgkQ7+hsbH/+ z4NV8Qf8DQNxopi8SxTEoBJgd5L0ZqoGVZonOg+34kd9rPqi+Hl1pCL6uwuaTiro tiNEUabEU09/MzfRjw2By6jCkPjNoN+5J1nIfPXygTdju2cfvHzLwm2R+QgUW0eA sfjX8AyYTYHD7psXFASB4pgdMir+YsRa+LabCcqLMEX4Dm77k1VQWyFOkrRdyRZh fjVPb6ncf7XMHNbNP4e/YpifipD6irWlKeQ60VMT2VrJ+U47vbTheodGqi8yY4iA lm5M7BpEaBkVKmTNSqpEsydp+F1BZw5AaXC/YLDk/a0/QpJ+I8RUBdi15SkrInL5 EsUTt+71YoZtHcwXQbVtoXpw+AGm5A== =hryu -END PGP SIGNATURE- libsis-jhdf5-java_19.04.1+dfsg-6_amd64.build.gz Description: application/gzip
Bug#1078921: r-cran-hdf5r: FTBFS against HDF5 1.14
Source: r-cran-hdf5r
Version: 1.3.9+dfsg-1
Severity: important
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
The r-cran-hdf5r package fails to build from source in a test rebuild against
hdf5 1.14 currently in experimental:
gcc -I"/usr/share/R/include" -DNDEBUG -I/usr/include/hdf5/serial
-I/usr/include/hdf5/serial -D__USE_MINGW_ANSI_STDIO -DH5_USE_110_API -fpic
-g -O2 -ffile-prefix-map=/build/reproducible-path/r-base-4.4.1=.
- -fstack-protector-strong -fstack-clash-protection -Wformat
-Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -c
convert.c -o convert.o
convert.c: In function ‘R_reorder’:
convert.c:1586:24: error: initialization of ‘hsize_t *’ {aka ‘long unsigned int
*’} from incompatible pointer type ‘long long unsigned int *’
[-Wincompatible-pointer-types]
1586 | hsize_t* new_order = (unsigned long long *) VOIDPTR(R_helper);
|^
make[1]: *** [/usr/lib/R/etc/Makeconf:195: convert.o] Error 1
The patch below fixes the issue:
Index: r-cran-hdf5r-1.3.9+dfsg/src/convert.c
===
- --- r-cran-hdf5r-1.3.9+dfsg.orig/src/convert.c
+++ r-cran-hdf5r-1.3.9+dfsg/src/convert.c
@@ -1583,7 +1583,7 @@ SEXP R_reorder(SEXP R_src, SEXP R_num_ro
hsize_t item_size = SEXP_to_longlong(R_item_size, 0);
SEXP R_helper = PROTECT(RToH5(R_new_order, H5T_NATIVE_ULLONG, num_rows));
- - hsize_t* new_order = (unsigned long long *) VOIDPTR(R_helper);
+ hsize_t* new_order = (hsize_t *) VOIDPTR(R_helper);
SEXP R_dst = PROTECT(duplicate(R_src));
reorder(VOIDPTR(R_dst), VOIDPTR(R_src), num_rows, num_cols, item_size,
new_order);
Best,
_g.
- -- System Information:
Debian Release: 12.0
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-21-amd64 (SMP w/12 CPU threads; PREEMPT)
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/+z4MFAmbA2z4ACgkQ7+hsbH/+
z4Pykwf/bwyTumC0NZ9QAgWYhacM175gDjc3QTfbficW7SC8NOYLgr0JuqvDZBQP
V4paWnlMeJjYxsDobcntIhCfEfA4t6oHQO90mP3YVt4wadIAGYkU0jn9yaDAy1wH
++5H03ZDOyfH+yyrCQwzwreyTgMWhFsvClQ3PMT8RdW+AI7C/YJO5+yrHfLkKp5a
ZQPPoai+aTAqzZri4G3j5L5GhL5Y3XIZaQLxBI6p97QzVhl0clMXMqCDdYDOQY05
jJH+nunewVD+egdV2KsAMULzCet7RGENVj2qPO33Ov+XA7KQRjn9iufbPIn4Se9B
VaibFxTuHDDHfgTB2id5CSHD6rlXrw==
=tL3B
-END PGP SIGNATURE-
Bug#1078904: silo-llnl: FTBFS against HDF5 1.14
Source: silo-llnl
Version: 4.11-6
Severity: important
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
The silo-llnl package fails to build from source in a test rebuild against
hdf5 1.14 currently in experimental:
libtool: compile: mpicc -DHAVE_CONFIG_H -I. -I../.. -I./../silo -I./../silo
-I./../fpzip -DH5_HAVE_FILTER_ZFP -DH5Z_ZFP_AS_LIB -DAS_SILO_BUILTIN
-I./../zfp-0.5.5/include -I/usr/include/hdf5/openmpi -I/usr/inclu
de/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtGui
-I/usr/include/x86_64-linux-gnu/qt5/QtCore
-I/usr/include/x86_64-linux-gnu/qt5/QtWidgets -I/usr/lib/openmpi/include
-Wdate-time -D_FORTIFY_SOURCE
=2 -g -O2 -Werror=implicit-function-declaration
-ffile-prefix-map=/<>=. -fstack-protector-strong
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -fPIC
-D_LARGEFILE_SOURCE -
D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wdeclaration-after-statement -c
H5FDsilo.c -fPIC -DPIC -o .libs/H5FDsilo.o
H5FDsilo.c:502:5: error: initialization of 'unsigned int' from 'char *' makes
integer from pointer without a cast [-Wint-conversion]
502 | "silo", /*name
*/
| ^~
H5FDsilo.c:502:5: note: (near initialization for 'H5FD_silo_g.version')
H5FDsilo.c:502:5: error: initializer element is not computable at load time
H5FDsilo.c:502:5: note: (near initialization for 'H5FD_silo_g.version')
H5FDsilo.c:463:17: warning: overflow in conversion from 'long unsigned int' to
'int' changes value from '9223372036854775807' to '-1' [-Woverflow]
463 | #define MAXADDR (((haddr_t)1<<(8*sizeof(file_offset_t)-1))-1)
| ^
H5FDsilo.c:503:5: note: in expansion of macro 'MAXADDR'
503 | MAXADDR,/*maxaddr
*/
| ^~~
H5FDsilo.c:504:5: error: initialization of 'const char *' from 'int' makes
pointer from integer without a cast [-Wint-conversion]
504 | H5F_CLOSE_WEAK, /* fc_degree
*/
| ^~
H5FDsilo.c:504:5: note: (near initialization for 'H5FD_silo_g.name')
H5FDsilo.c:508:5: error: incompatible types when initializing type 'enum
H5F_close_degree_t' using type 'hsize_t (*)(H5FD_t *)' {aka 'long unsigned int
(*)(H5FD_t *)'}
508 | H5FD_silo_sb_size, /*sb_size
*/
| ^
H5FDsilo.c:509:5: error: initialization of 'herr_t (*)(void)' {aka 'int
(*)(void)'} from incompatible pointer type 'herr_t (*)(H5FD_t *, char *,
unsigned char *)' {aka 'int (*)(H5FD_t *, char *, unsigned char *)'}
[-Wincompatible-pointer-types]
509 | H5FD_silo_sb_encode,/*sb_encode
*/
| ^~~
H5FDsilo.c:509:5: note: (near initialization for 'H5FD_silo_g.terminate')
libtool: compile: mpicc -DHAVE_CONFIG_H -I. -I../.. -I./../silo -I./../silo
-I./../fpzip -DH5_HAVE_FILTER_ZFP -DH5Z_ZFP_AS_LIB -DAS_SILO_BUILTIN
-I./../zfp-0.5.5/include -I/usr/include/hdf5/openmpi -I/usr/inclu
de/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtGui
-I/usr/include/x86_64-linux-gnu/qt5/QtCore
-I/usr/include/x86_64-linux-gnu/qt5/QtWidgets -I/usr/lib/openmpi/include
-Wdate-time -D_FORTIFY_SOURCE
=2 -g -O2 -Werror=implicit-function-declaration
-ffile-prefix-map=/<>=. -fstack-protector-strong
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -fPIC
-D_LARGEFILE_SOURCE -
D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wdeclaration-after-statement -c
H5FDsilo.c -fPIC -DPIC -o .libs/H5FDsilo.o
H5FDsilo.c:502:5: error: initialization of 'unsigned int' from 'char *' makes
integer from pointer without a cast [-Wint-conversion]
502 | "silo", /*name
*/
| ^~
H5FDsilo.c:502:5: note: (near initialization for 'H5FD_silo_g.version')
H5FDsilo.c:502:5: error: initializer element is not computable at load time
H5FDsilo.c:502:5: note: (near initialization for 'H5FD_silo_g.version')
H5FDsilo.c:463:17: warning: overflow in conversion from 'long unsigned int' to
'int' changes value from '9223372036854775807' to '-1' [-Woverflow]
463 | #define MAXADDR (((haddr_t)1<<(8*sizeof(file_offset_t)-1))-1)
| ^
H5FDsilo.c:503:5: note: in expansion of macro 'MAXADDR'
503 | MAXADDR,/*maxaddr
*/
| ^~~
H5FDsilo.c:504:5: error: initialization of 'const char *' from 'int' makes
pointer from integer without a cast [-Wint-conversion]
504 | H5F_CLOSE_WEAK, /* fc_degree
*/
| ^~
H5FDsilo.c:504:5: note: (near initialization for 'H5FD_silo_g.name')
H5FDsilo.c:508:5: error: incompatible types when initializing type 'enum
H5F_close_degree_t' using type 'hsize_t (*)(H5FD_t *)' {aka 'long unsigned int
(*)(H5FD_t *)'}
508 | H5FD_silo_sb_size,
Bug#1078882: sra-sdk: FTBFS against HDF5 1.14
Source: sra-sdk Version: 3.0.3+dfsg-8 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, The sra-sdk package fails to build from source in a test rebuild against hdf5 1.14 currently in experimental: cd /<>/obj-x86_64-linux-gnu/tools/loaders/pacbio-load && /usr/bin/cc -DLINUX -DNDEBUG -DUNIX -D_ARCH_BITS=64 -D_GNU_SOURCE -D__mod__=\"tools/pacbio-load\" -Dx86_64 -I/usr/include/ncbi-vdb -I/usr/inc lude/ncbi-vdb/cc/gcc -I/usr/include/ncbi-vdb/cc/gcc/x86_64 -I/usr/include/ncbi-vdb/os/linux -I/usr/include/ncbi-vdb/os/unix -I/<>/ngs/ngs-sdk -I/<>/libs/inc -I/<>/tools/loa ders/pacbio-load -I/usr/include/hdf5/serial -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -f cf-protection -fsigned-char -Wdate-time -D_FORTIFY_SOURCE=2 -std=c11 -rdynamic -Wall -MD -MT tools/loaders/pacbio-load/CMakeFiles/pacbio-load.dir/hdf5/hdf5dir.c.o -MF CMakeFiles/pacbio-load.dir/hdf5/hdf5dir.c. o.d -o CMakeFiles/pacbio-load.dir/hdf5/hdf5dir.c.o -c /<>/tools/loaders/pacbio-load/hdf5/hdf5dir.c In file included from /usr/include/hdf5/serial/H5public.h:31, from /usr/include/hdf5/serial/hdf5.h:21, from /<>/tools/loaders/pacbio-load/hdf5/hdf5dir.c:35: /<>/tools/loaders/pacbio-load/hdf5/hdf5dir.c: In function ‘HDF5DirPathTypeOnBuffer’: /usr/include/hdf5/serial/H5version.h:947:31: error: too few arguments to function ‘H5Oget_info_by_name3’ 947 | #define H5Oget_info_by_name H5Oget_info_by_name3 | ^~~~ /<>/tools/loaders/pacbio-load/hdf5/hdf5dir.c:295:18: note: in expansion of macro ‘H5Oget_info_by_name’ 295 | herr_t h5e = H5Oget_info_by_name( self->hdf5_handle, buffer, &obj_info, H5P_DEFAULT ); | ^~~ In file included from /usr/include/hdf5/serial/H5Apublic.h:21, from /usr/include/hdf5/serial/hdf5.h:22: /usr/include/hdf5/serial/H5Opublic.h:541:15: note: declared here 541 | H5_DLL herr_t H5Oget_info_by_name3(hid_t loc_id, const char *name, H5O_info2_t *oinfo, unsigned fields, | ^~~~ make[3]: *** [tools/loaders/pacbio-load/CMakeFiles/pacbio-load.dir/build.make:93: tools/loaders/pacbio-load/CMakeFiles/pacbio-load.dir/hdf5/hdf5dir.c.o] Error 1 make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu' make[2]: *** [CMakeFiles/Makefile2:5938: tools/loaders/pacbio-load/CMakeFiles/pacbio-load.dir/all] Error 2 Full build log attached. Please note that adding -DH5_USE_110_API to CFLAGS and CXXFLAGS solves the issue. Best, _g. - -- System Information: Debian Release: 12.0 Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-21-amd64 (SMP w/12 CPU threads; PREEMPT) 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/+z4MFAmbAm3QACgkQ7+hsbH/+ z4NTXQf8DZReqhLppQyQr+y+8QPXFOrOmoCG6M8/XRyARKThhKtLUw9kYDjRVtfo J6IyX/MQ3VAFGsoLNt5MWoCzzOU4WoqHYi/sjKRuWzyMlM6Yg6ZKzJgDV7zHCnJ+ aLoJvpXlf4nxD9sShMitijIjTLKe+md/vcbYhtt2JToU3qNaMzMJZObFGKr4/xNK HYxc8l8JcKNnSLOMdmMml2U4K9KyzfdE5Tjk3WiG2vgUZ7FbsMZ+FBU9vRALemI4 G4XRptLzQMsRaC+zQ6h2DWW+1OAj4URAgp2QxKg3KxEE6Gl94QCdl9eaAUe2g139 5ZZJt+IO9qrE91LRiMJ2OKg9uXzeBg== =na6V -END PGP SIGNATURE- sra-sdk_3.0.3+dfsg-8_amd64.build.gz Description: application/gzip
Bug#1078860: unifrac-tools: FTBFS against HDF5 1.14
Source: unifrac-tools Version: 1.4-3 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, The unifrac-tools package fails to build from source in a test rebuild against hdf5 1.14 currently in experimental. The failure occurs during the post-build tests. Here is the related exerpt from the log: debian/rules override_dh_auto_test make[1]: Entering directory '/build/unifrac-tools-tWlv7l/unifrac-tools-1.4' export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/build/unifrac-tools-tWlv7l/unifrac-tools-1.4/debian/tmp/usr/bin ; \ cd ci ; \ ./crawford_test.sh HDF5-DIAG: Error detected in HDF5 (1.14.4-3) thread 1: #000: ../../../src/H5D.c line 403 in H5Dopen2(): unable to synchronously open dataset major: Dataset minor: Can't open object #001: ../../../src/H5D.c line 359 in H5D__open_api_common(): can't set object access arguments major: Dataset minor: Can't set value #002: ../../../src/H5VLint.c line 2602 in H5VL_setup_acc_args(): invalid location identifier major: Invalid arguments to routine minor: Inappropriate type #003: ../../../src/H5VLint.c line 1733 in H5VL_vol_object(): invalid identifier major: Invalid arguments to routine minor: Inappropriate type terminate called after throwing an instance of 'H5::FileIException' ./crawford_test.sh: line 12: 61153 Aborted ssu -i crawford.biom -t crawford.tre -o test.dm -m unweighted make[1]: *** [debian/rules:21: override_dh_auto_test] Error 134 Full build log attached. Best, _g. - -- System Information: Debian Release: 12.0 Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-21-amd64 (SMP w/12 CPU threads; PREEMPT) 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/+z4MFAmbAZMMACgkQ7+hsbH/+ z4PFxgf/TYzBA3SNBT/2/Rd3fbMVfwmcIiFekBgd1ivpxiaaN9e0a1UeBpJ2lhQt FiIFMIyyJzA1/mmQOAUV8/Wgy6McvTHX2+fDwY8ZIzCEIP7iAhkgg9oh2+xlUqGb d4z826hEt/FcvlpfFlumjokUBUXTIfE9dGE9FpW/M/OX7GCQwcEUC9vh4liZfwPk 84WJMPbb5VjZ1GOK1Icyps7Gh2eSVAN4x38vmiQmjqQNkbnCW0ZkRpQqU2EuvzSI E4F9D4WsoajVF7qrqRD4/X52ZzMiXPSOz+KCgelX54ZRoXYmFfj0Ld1PupQlz/sB RyiLsfXnqRA7KigL0bBOKv3shl7PEQ== =Q3uO -END PGP SIGNATURE- unifrac-tools_1.4-3_amd64.build.gz Description: application/gzip
Bug#1078824: grads: FTBFS against HDF5 1.14
Source: grads Version: 3:2.2.1-6 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, The grads package fails to build from source in a test rebuild against hdf5 1.14 currently in experimental: gaio.c: In function ‘h5pattrs’: /usr/include/hdf5/serial/H5version.h:921:23: error: too few arguments to function ‘H5Oget_info3’ 921 | #define H5Oget_info H5Oget_info3 | ^~~~ gaio.c:4699:15: note: in expansion of macro ‘H5Oget_info’ 4699 | if ((rc = H5Oget_info(vid,&oinfo))<0) err=1; | ^~~ In file included from /usr/include/hdf5/serial/H5Apublic.h:21, from /usr/include/hdf5/serial/hdf5.h:22: /usr/include/hdf5/serial/H5Opublic.h:504:15: note: declared here 504 | H5_DLL herr_t H5Oget_info3(hid_t loc_id, H5O_info2_t *oinfo, unsigned fields); | ^~~~ make[3]: *** [Makefile:802: gaio.o] Error 1 Please note that adding -DH5_USE_110_API to CFLAGS solves the problem. Best, _g. - -- System Information: Debian Release: 12.0 Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-21-amd64 (SMP w/12 CPU threads; PREEMPT) 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/+z4MFAma/qvAACgkQ7+hsbH/+ z4PJZQf/eU1Vk9lS7lVkinQ++KRYnABrmfZ9UMPRSdhuRvjZeAE+m6s8ThBikERI YWRnCXNaoUM2XVJHnX88zrcQ84VhTXAzT0LdWNop/ugZVUK4VxHFTM562hgqlBRO pawtgm6Z4bQmrYjul9gDOhlXJYsBqD5Z0XLjcne3+XrmhO2GJPZixh7iqSCdA6dh TdHf7ECKm+W7ffJo5RhYaKEkar1LvgfEzVAvnRc/lExmPOVgbx1P+MyqVgfuxU37 wNnsPSbXJvd5o3uufWrFYI4BfKDb9LcrVgcmMxdpBNYDiqjnMaT8pHGz/2krhdo1 4noHm9K1NEhKnxuMPm/P02ZKApxehw== =vi3b -END PGP SIGNATURE-
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#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&arch=i386&ver=1.10.8%2Brepack-3&stamp=1669422533&raw=0 [2] https://buildd.debian.org/status/fetch.php?pkg=hdf5&arch=mips64el&ver=1.10.8%2Brepack-3&stamp=1669424344&raw=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&arch=i386&ver=1.10.8%2Brepack-3&stamp=1669422533&raw=0 [2] https://buildd.debian.org/status/fetch.php?pkg=hdf5&arch=mips64el&ver=1.10.8%2Brepack-3&stamp=1669424344&raw=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&arch=i386&ver=1%3A0.3.0-3&stamp=1633198410&raw=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&suite=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#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#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
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("resul
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
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 ExtractPix
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(&
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.
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 JsonObje
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 toJSONObje
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#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&start=15&tstart=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 IOEx
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 be
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 201
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.0 +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
+
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
