Bug#1082819: libisal: Update symbols file for hurd-amd64
source: libisal version: 2.31.0-0.1 severity: important Update symbols file for hurd-amd64 dh_makeshlibs -a dpkg-gensymbols: error: some new symbols appeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libisal2/DEBIAN/symbols doesn't match completely debian/libisal2.symbols --- debian/libisal2.symbols (libisal2_2.31.0-0.1_hurd-amd64) +++ dpkg-gensymbolsFdXku5 2024-07-24 10:11:12.0 + @@ -1,60 +1,183 @@ libisal.so.2 libisal2 #MINVER# * Build-Depends-Package: libisal-dev + adler32_avx2_4@Base 2.31.0-0.1 adler32_base@Base 2.19.0 + adler32_sse@Base 2.31.0-0.1 build_heap@Base 2.19.0 build_huff_tree@Base 2.19.0 crc16_t10dif@Base 2.16.0 + crc16_t10dif_01@Base 2.31.0-0.1 + crc16_t10dif_02@Base 2.31.0-0.1 crc16_t10dif_base@Base 2.16.0 + crc16_t10dif_by16_10@Base 2.31.0-0.1 + crc16_t10dif_by4@Base 2.31.0-0.1 crc16_t10dif_copy@Base 2.21.0 crc16_t10dif_copy_base@Base 2.21.0 + crc16_t10dif_copy_by4@Base 2.31.0-0.1 + crc16_t10dif_copy_by4_02@Base 2.31.0-0.1 crc32_gzip_refl@Base 2.19.0 crc32_gzip_refl_base@Base 2.19.0 + crc32_gzip_refl_by16_10@Base 2.31.0-0.1 + crc32_gzip_refl_by8@Base 2.31.0-0.1 + crc32_gzip_refl_by8_02@Base 2.31.0-0.1 crc32_ieee@Base 2.16.0 + crc32_ieee_01@Base 2.31.0-0.1 + crc32_ieee_02@Base 2.31.0-0.1 crc32_ieee_base@Base 2.16.0 + crc32_ieee_by16_10@Base 2.31.0-0.1 + crc32_ieee_by4@Base 2.31.0-0.1 crc32_iscsi@Base 2.16.0 + crc32_iscsi_00@Base 2.31.0-0.1 + crc32_iscsi_01@Base 2.31.0-0.1 crc32_iscsi_base@Base 2.16.0 + crc32_iscsi_by16_10@Base 2.31.0-0.1 crc64_ecma_norm@Base 2.19.0 crc64_ecma_norm_base@Base 2.19.0 + crc64_ecma_norm_by16_10@Base 2.31.0-0.1 + crc64_ecma_norm_by8@Base 2.31.0-0.1 crc64_ecma_refl@Base 2.19.0 crc64_ecma_refl_base@Base 2.19.0 + crc64_ecma_refl_by16_10@Base 2.31.0-0.1 + crc64_ecma_refl_by8@Base 2.31.0-0.1 crc64_iso_norm@Base 2.19.0 crc64_iso_norm_base@Base 2.19.0 + crc64_iso_norm_by16_10@Base 2.31.0-0.1 + crc64_iso_norm_by8@Base 2.31.0-0.1 crc64_iso_refl@Base 2.19.0 crc64_iso_refl_base@Base 2.19.0 + crc64_iso_refl_by16_10@Base 2.31.0-0.1 + crc64_iso_refl_by8@Base 2.31.0-0.1 crc64_jones_norm@Base 2.19.0 crc64_jones_norm_base@Base 2.19.0 + crc64_jones_norm_by16_10@Base 2.31.0-0.1 + crc64_jones_norm_by8@Base 2.31.0-0.1 crc64_jones_refl@Base 2.19.0 crc64_jones_refl_base@Base 2.19.0 + crc64_jones_refl_by16_10@Base 2.31.0-0.1 + crc64_jones_refl_by8@Base 2.31.0-0.1 crc64_rocksoft_norm@Base 2.31.0 crc64_rocksoft_norm_base@Base 2.31.0 + crc64_rocksoft_norm_by16_10@Base 2.31.0-0.1 + crc64_rocksoft_norm_by8@Base 2.31.0-0.1 crc64_rocksoft_refl@Base 2.31.0 crc64_rocksoft_refl_base@Base 2.31.0 + crc64_rocksoft_refl_by16_10@Base 2.31.0-0.1 + crc64_rocksoft_refl_by8@Base 2.31.0-0.1 create_hufftables_icf@Base 2.19.0 decode_huffman_code_block_stateless@Base 2.19.0 + decode_huffman_code_block_stateless_01@Base 2.31.0-0.1 + decode_huffman_code_block_stateless_04@Base 2.31.0-0.1 decode_huffman_code_block_stateless_base@Base 2.19.0 ec_encode_data@Base 2.15.0 + ec_encode_data_avx2@Base 2.31.0-0.1 + ec_encode_data_avx2_gfni@Base 2.31.0-0.1 + ec_encode_data_avx512@Base 2.31.0-0.1 + ec_encode_data_avx512_gfni@Base 2.31.0-0.1 + ec_encode_data_avx@Base 2.31.0-0.1 ec_encode_data_base@Base 2.15.0 + ec_encode_data_sse@Base 2.31.0-0.1 ec_encode_data_update@Base 2.15.0 + ec_encode_data_update_avx2@Base 2.31.0-0.1 + ec_encode_data_update_avx2_gfni@Base 2.31.0-0.1 + ec_encode_data_update_avx512@Base 2.31.0-0.1 + ec_encode_data_update_avx512_gfni@Base 2.31.0-0.1 + ec_encode_data_update_avx@Base 2.31.0-0.1 ec_encode_data_update_base@Base 2.15.0 + ec_encode_data_update_sse@Base 2.31.0-0.1 ec_init_tables@Base 2.15.0 ec_init_tables_base@Base 2.31.0 + ec_init_tables_gfni@Base 2.31.0-0.1 encode_deflate_icf@Base 2.19.0 + encode_deflate_icf_04@Base 2.31.0-0.1 + encode_deflate_icf_06@Base 2.31.0-0.1 encode_deflate_icf_base@Base 2.19.0 flatten_ll@Base 2.19.0 gen_icf_map_h1_base@Base 2.21.0 gen_icf_map_lh1@Base 2.21.0 + gen_icf_map_lh1_04@Base 2.31.0-0.1 + gen_icf_map_lh1_06@Base 2.31.0-0.1 + gf_2vect_dot_prod_avx2@Base 2.31.0-0.1 + gf_2vect_dot_prod_avx2_gfni@Base 2.31.0-0.1 + gf_2vect_dot_prod_avx512@Base 2.31.0-0.1 + gf_2vect_dot_prod_avx512_gfni@Base 2.31.0-0.1 + gf_2vect_dot_prod_avx@Base 2.31.0-0.1 + gf_2vect_dot_prod_sse@Base 2.31.0-0.1 + gf_2vect_mad_avx2@Base 2.31.0-0.1 + gf_2vect_mad_avx2_gfni@Base 2.31.0-0.1 + gf_2vect_mad_avx512@Base 2.31.0-0.1 + gf_2vect_mad_avx512_gfni@Base 2.31.0-0.1 + gf_2vect_mad_avx@Base 2.31.0-0.1 + gf_2vect_mad_sse@Base 2.31.0-0.1 + gf_3vect_dot_prod_avx2@Base 2.31.0-0.1 + gf_3vect_dot_prod_avx2_gfni@Base 2.31.0-0.1 + gf_3vect_dot_prod_avx512@Base 2.31.0-0.1 + gf_3vect_dot_prod_avx512_gfni@Base 2.31.0-0.1 + gf_3vect_dot_prod_avx@Base 2.31.0-0.1 + gf_3vect_dot_prod_sse@Base 2.31.0-0.1 + gf_3vect_mad_avx2@Base 2.31.0-0.1 + gf_3vect_mad_avx2_gfni@Base 2.31.0-0.1 + gf_3vect_mad_avx512@Base 2.31.0-0.1 + gf_3vect_mad_avx512_gfni@Base 2.31.0-0.1 + gf_3vec
Bug#1081619: Non-reproducible file names in doxygen output
Package: doxygen Version: 1.9.8+ds-2 Severity: important Forwarded: https://github.com/doxygen/doxygen/issues/11138 The files generated by doxygen whose file names contain the string unnamedN where N is a number are not generated using predictable names. See e.g. the reproducible build check for the xrootd package: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/xrootd.html Mattias signature.asc Description: This is a digitally signed message part
Bug#1079358: MR available
Merge request: https://salsa.debian.org/debian/boost/-/merge_requests/11 Mattias signature.asc Description: This is a digitally signed message part
Bug#1079358: FTBFS on x32
source: boost1.83 version: 1.83.0-1 severity: important tags: patch The boost1.83 fails to build on x32. The debian/rules file has a special rule commenting out a line in tools/build/src/tools/gcc.jam on x32. This is not sufficient and a second line must be commented out for the compilation to work. The attached patch modifies the debian/rules file accordingly. I can make an NMU upload if you are happy with the modification. Mattias. From 85520090f1b100d87d0710a2ffd482d7f39e556c Mon Sep 17 00:00:00 2001 From: Mattias Ellert Date: Thu, 22 Aug 2024 17:41:17 +0200 Subject: [PATCH] Additional workaround for broken architecture detection under x32 --- debian/changelog | 7 +++ debian/rules | 4 +++- 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/debian/changelog b/debian/changelog index 8509c6bf8..b92c09391 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +boost1.83 (1.83.0-3.2) unstable; urgency=medium + + * Non-maintainer upload. + * Additional workaround for broken architecture detection under x32. + + -- Mattias Ellert Thu, 22 Aug 2024 14:09:24 +0200 + boost1.83 (1.83.0-3.1) unstable; urgency=medium * Non-maintainer upload. diff --git a/debian/rules b/debian/rules index 5acc8a88a..871942eab 100755 --- a/debian/rules +++ b/debian/rules @@ -182,7 +182,9 @@ JAM_DOC = $(b2) $(JOBS) -q -d2 --ignore-site-config --user-config=$(CURDIR)/user override_dh_auto_configure: user-config.jam make-debhelper ifeq ($(DEB_BUILD_ARCH), x32) cp tools/build/src/tools/gcc.jam tools/build/src/tools/gcc.jam.bak - sed -i -e 's|^.*compile-link-flags.*-m32.*|#\0|g' tools/build/src/tools/gcc.jam + sed -i -e 's|^.*compile-link-flags.*-m32.*|#\0|g' \ + -e 's|^.*toolset.flags.*-march=i686.*|#\0|g' \ + tools/build/src/tools/gcc.jam endif override_dh_auto_build-common: $(b2) b2.1 bjam.1 -- 2.45.2 signature.asc Description: This is a digitally signed message part
Bug#1068076: Time to upload?
Hi Nicolas. In your last message (2024-07-04) you said that you have prepared an update in salsa that you would upload if everything looked OK. I appreciate your work on this issue, is there an issue with the update that is delaying the upload? The pipeline in salsa has succeeded. Mattias signature.asc Description: This is a digitally signed message part
Bug#1074897: Merge Request available in Salsa
Merge Request available in Salsa: https://salsa.debian.org/debian/rapidjson/-/merge_requests/2 This bug makes many packages FTBDS and therefore flagged for auto- removal, so can this be fixed swiftly? Mattias signature.asc Description: This is a digitally signed message part
Bug#1068076: Patch for bug 1068076
The correct fix is to not assume a maximum length for paths, but use dynamic allocation with the proper length. One way to do this can be seen in the attached patch (calling snprintf twics). Another options is to calculate the needed length by adding up the strlen() result for each of the strings and adding the constant length needed for the constant bits of the format string. This will work for systems that define PATH_MAX/MAXPATHLEN too, so there is no need for ifdefs. Mattias diff --git a/tests/session_fixture.c b/tests/session_fixture.c index 3bb9da2..caeabfc 100644 --- a/tests/session_fixture.c +++ b/tests/session_fixture.c @@ -225,11 +225,7 @@ void stop_session_fixture(void) #define NUMPATHS 32 const char *srcdir_path(const char *file) { -#ifdef WIN32 -static char filepath[NUMPATHS][_MAX_PATH]; -#else -static char filepath[NUMPATHS][MAXPATHLEN]; -#endif +static char* filepath[NUMPATHS]; static int curpath; char *p = getenv("srcdir"); if(curpath >= NUMPATHS) { @@ -237,16 +233,14 @@ const char *srcdir_path(const char *file) } assert(curpath < NUMPATHS); if(p) { -/* Ensure the final string is nul-terminated on Windows */ -filepath[curpath][sizeof(filepath[0]) - 1] = 0; -snprintf(filepath[curpath], sizeof(filepath[0]) - 1, "%s/%s", - p, file); +int len = snprintf(NULL, 0, "%s/%s", p, file); +filepath[curpath] = malloc(len + 1); +snprintf(filepath[curpath], len + 1, "%s/%s", p, file); } else { -/* Ensure the final string is nul-terminated on Windows */ -filepath[curpath][sizeof(filepath[0]) - 1] = 0; -snprintf(filepath[curpath], sizeof(filepath[0]) - 1, "%s", - file); +int len = snprintf(NULL, 0, "%s", file); +filepath[curpath] = malloc(len + 1); +snprintf(filepath[curpath], len + 1, "%s", file); } return filepath[curpath++]; signature.asc Description: This is a digitally signed message part
Bug#1068134: globus-gram-job-manager-scripts: arch:all package depends on pre-t64 library
Control: found 1068134 7.3-1 Control: notfound 1068134 7.3-2 The bug reported here is already fixed in the version for which the bug was reported. This bug was present in the previous version. The current version was uploaded precisely to fix the problem reported. Previous version (7.3-1) had Depends: libglobus-common0 (>= 15) Current version (7.3-2) has Depends: libglobus-common0 (>= 15) | libglobus-common0t64 (>= 15) I.e. it does not depend only on the old package name, but on either the new or the old. The package is therefore not blocking the t64 transition. Mattias sön 2024-03-31 klockan 17:41 +0200 skrev Sebastian Ramacher: > Source: globus-gram-job-manager-scripts > Version: 7.3-2 > Severity: serious > X-Debbugs-Cc: sramac...@debian.org > > globus-gram-job-manager-scripts builds an Architecture: all packages > depending on a library package involved in the time_t 64 transition. > This dependency needs to be updated. > > Cheers > -- > Sebastian Ramacher > > VARNING: Klicka inte på länkar och öppna inte bilagor om du inte > känner igen avsändaren och vet att innehållet är säkert. > CAUTION: Do not click on links or open attachments unless you > recognise the sender and know the content is safe. signature.asc Description: This is a digitally signed message part
Bug#1068133: globus-gram-audit: arch:all package depends on pre-t64 library
Control: found 1068133 5.1-2 Control: notfound 1068133 5.1-3 The bug reported here is already fixed in the version for which the bug was reported. This bug was present in the previous version. The current version was uploaded precisely to fix the problem reported. Previous version (5.1-2) had Depends: libglobus-common0 (>= 15) Current version (5.1-3) has Depends: libglobus-common0 (>= 15) | libglobus-common0t64 (>= 15) I.e. it does not depend only on the old package name, but on either the new or the old. The package is therefore not blocking the t64 transition. Mattias sön 2024-03-31 klockan 17:39 +0200 skrev Sebastian Ramacher: > Source: globus-gram-audit > Version: 5.1-3 > Severity: serious > X-Debbugs-Cc: sramac...@debian.org > > globus-gram-audit builds an Architecture: all packages depending on a > library package involved in the time_t 64 transition. This dependency > needs to be updated. > > Cheers > -- > Sebastian Ramacher > > VARNING: Klicka inte på länkar och öppna inte bilagor om du inte > känner igen avsändaren och vet att innehållet är säkert. > CAUTION: Do not click on links or open attachments unless you > recognise the sender and know the content is safe. signature.asc Description: This is a digitally signed message part
Bug#1068076: libssh2: FTBFS on hurd-any
source: libssh2 version: 1.11.0-1 severity: important The package fails to build on hurd due to the use of MAXPATHEN: session_fixture.c:231:36: error: ‘MAXPATHLEN’ undeclared (first use in this function) 231 | static char filepath[NUMPATHS][MAXPATHLEN]; |^~ PATH_MAX and MAXPATHLEN are on purpose not defined on hurd. Mattias PS. This currently blocks all packages that depend on libssh2 to be rebuilt for the lngoing 64 bit time_t transition. signature.asc Description: This is a digitally signed message part
Bug#1068073: Hardcoded dependency on liblcmaps0
source: lcmaps-plugins-verify-proxy version: 1.5.10-2 severity: serious During the 64 bit time_t transition the package name liblcmaps0 was changed to liblcmaps0t64. The old name is still provided by the new package for architectures where this transition did not cause an ABI break, but not for architectures like armel and armhf, where these hardcoded dependency on the old package name are now not satisfiable. Please change these to use either the new name or to depend on either the old or the new name (liblcmaps0 | liblcmaps0t64). Package: lcmaps-plugins-verify-proxy Depends: ${shlibs:Depends}, ${misc:Depends}, liblcmaps0 Mattias signature.asc Description: This is a digitally signed message part
Bug#1068072: Hardcoded dependency on liblcmaps0
source: lcmaps-plugins-basic version: 1.7.1-1 severity: serious During the 64 bit time_t transition the package name liblcmaps0 was changed to liblcmaps0t64. The old name is still provided by the new package for architectures where this transition did not cause an ABI break, but not for architectures like armel and armhf, where these hardcoded dependency on the old package name are now not satisfiable. Please change these to use either the new name or to depend on either the old or the new name (liblcmaps0 | liblcmaps0t64). Package: lcmaps-plugins-basic-dummy Depends: ${misc:Depends}, ${shlibs:Depends}, liblcmaps0 Package: lcmaps-plugins-basic-localaccount Depends: ${misc:Depends}, ${shlibs:Depends}, liblcmaps0 Package: lcmaps-plugins-basic-poolaccount Depends: ${misc:Depends}, ${shlibs:Depends}, liblcmaps0 Package: lcmaps-plugins-basic-posixenf Depends: ${misc:Depends}, ${shlibs:Depends}, liblcmaps0 Package: lcmaps-plugins-basic-ldap Depends: ${misc:Depends}, ${shlibs:Depends}, liblcmaps0 Mattias signature.asc Description: This is a digitally signed message part
Bug#1068071: Hardcoded dependency on liblcmaps0
source: lcmaps-plugins-jobrep version: 1.5.6-1.1 severity: serious During the 64 bit time_t transition the package name liblcmaps0 was changed to liblcmaps0t64. The old name is still provided by the new package for architectures where this transition did not cause an ABI break, but not for architectures like armel and armhf, where these hardcoded dependency on the old package name are now not satisfiable. Please change these to use either the new name or to depend on either the old or the new name (liblcmaps0 | liblcmaps0t64). Package: lcmaps-plugins-jobrep Depends: ${shlibs:Depends}, ${misc:Depends}, liblcmaps0 Mattias signature.asc Description: This is a digitally signed message part
Bug#1068070: Hardcoded dependency on liblcmaps0
source: lcmaps-plugins-voms version: 1.7.1-1 severity: serious During the 64 bit time_t transition the package name liblcmaps0 was changed to liblcmaps0t64. The old name is still provided by the new package for architectures where this transition did not cause an ABI break, but not for architectures like armel and armhf, where these hardcoded dependency on the old package name are now not satisfiable. Please change these to use either the new name or to depend on either the old or the new name (liblcmaps0 | liblcmaps0t64). Package: lcmaps-plugins-voms Depends: ${shlibs:Depends}, ${misc:Depends}, liblcmaps0 (>= 1.5.0) Mattias signature.asc Description: This is a digitally signed message part
Bug#1063457: nordugrid-arc and arcstat
NorduGrid ARC has used the name arcstat since release 1.0. It has been in Debian since January 2010 (source package nordugrid-arc-nox, later renamed nordugrid-arc in May 2011). The command is part of a set of commands, all using the arc prefix: arccat arcget arckillarcproxy arcresume arcsync arcclean arcls arcrename arcrm arctest arccp arched arcmkdir arcrenew arcstat arcctl arcinfoarcplugin arcresub arcsub Mattias Ellert signature.asc Description: This is a digitally signed message part
Bug#1062167: globus-rsl: NMU diff for 64-bit time_t transition
Package updated in unstable: Date: Fri, 09 Feb 2024 14:32:37 +0100 Source: globus-rsl Architecture: source Version: 11.4-1 Distribution: unstable signature.asc Description: This is a digitally signed message part
Bug#1063156: myproxy: NMU diff for 64-bit time_t transition
Package updated in unstable: Date: Fri, 09 Feb 2024 14:44:42 +0100 Source: myproxy Architecture: source Version: 6.2.16-1 Distribution: unstable signature.asc Description: This is a digitally signed message part
Bug#1062157: globus-gsi-credential: NMU diff for 64-bit time_t transition
Package updated in unstable: Date: Fri, 09 Feb 2024 14:19:40 +0100 Source: globus-gsi-credential Architecture: source Version: 8.4-1 Distribution: unstable signature.asc Description: This is a digitally signed message part
Bug#1062156: globus-gsi-cert-utils: NMU diff for 64-bit time_t transition
Package updated in unstable: Date: Fri, 09 Feb 2024 14:04:34 +0100 Source: globus-gsi-cert-utils Architecture: source Version: 10.11-1 Distribution: unstable signature.asc Description: This is a digitally signed message part
Bug#1062160: globus-gsi-sysconfig: NMU diff for 64-bit time_t transition
Package updated in unstable: Date: Fri, 09 Feb 2024 15:12:34 +0100 Source: globus-gsi-sysconfig Architecture: source Version: 9.6-1 Distribution: unstable signature.asc Description: This is a digitally signed message part
Bug#1062153: globus-gridftp-server: NMU diff for 64-bit time_t transition
Package updated in unstable: Date: Fri, 09 Feb 2024 13:48:21 +0100 Source: globus-gridftp-server Architecture: source Version: 13.25-1 Distribution: unstable signature.asc Description: This is a digitally signed message part
Bug#1062145: globus-gass-copy: NMU diff for 64-bit time_t transition
Package updated in unstable: Date: Fri, 09 Feb 2024 12:34:54 +0100 Source: globus-gass-copy Architecture: source Version: 10.13-1 Distribution: unstable signature.asc Description: This is a digitally signed message part
Bug#1062141: globus-common: NMU diff for 64-bit time_t transition
Package updated in unstable: Date: Fri, 09 Feb 2024 11:13:35 +0100 Source: globus-common Architecture: source Version: 18.14-1 Distribution: unstable signature.asc Description: This is a digitally signed message part
Bug#1063298: xrootd: NMU diff for 64-bit time_t transition
The package was updated in unstable xrootd 5.6.7-1 If/when you update the package in experimental for the transition, please include the missing change in debian/rules mentioned in a previous comment to this bug. signature.asc Description: This is a digitally signed message part
Bug#1063204: nordugrid-arc: NMU diff for 64-bit time_t transition
The package was updated in unstable. nordugrid-arc 6.18.0-2 signature.asc Description: This is a digitally signed message part
Bug#1036884: Schedule
Hi! The earliest of the RC bugs filed for this transition have now been unresolved long enough to trigger AUTORM threats. This is unfortunate, since the maintainers can't do anything to fix them, since they are un-fixable until the required changes to the default compiler flags are implemented. In order for threats of removal not to trigger maintainers to blindly applying the proposed patches and uploading to unstable to close the bugs, you should either start the transition now or downgrade the severity of the bugs. Personally I think it would have made more sense to file these bugs with minor or normal severity (since they are simply informational at this stage) and then upgrade them to serious when the transition starts (at which point they become RC). Do you have an estimate when the uploads to unstable will start? Mattias signature.asc Description: This is a digitally signed message part
Bug#1063298: xrootd: NMU diff for 64-bit time_t transition
Hi! The proposed change is incomplete, and the build failed on some architectures. You need to update debian/rules due to the changes package names: Line 31 must change from N = -Nlibxrdec1 to N = -Nlibxrdec1t64 Regards, Mattias (package maintainer) signature.asc Description: This is a digitally signed message part
Bug#1058957: RM: libxrdcephposix0, xrootd-ceph-plugins [armel, armhf] -- RoM; ANAIS
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Control: affects -1 + src:xrootd At the request of the maintainers of src:ceph I dropped the ceph depending binary packages libxrdcephposix0 and xrootd-ceph-plugins from src:xrootd for 32 bit architectures. The packages seem to have been removed from unstable for all relevant architectures, except armel and armhf where there still are present old packages from before this change (version 5.6.2-2). Mattias Ellert Maintainer signature.asc Description: This is a digitally signed message part
Bug#1057785: Don't expect EINTR when sleep is interrupted on GNU/Hurd
Source: cmake Version: 3.28.0-1 Severity: important Tags: ftbfs patch upstream Control: forwarded -1 https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9052 One of the tests makes a Linux specific assumption about the sleep command and fails on GNU/Hurd. Upstream PR: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9052 Patch: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9052.patch Mattias signature.asc Description: This is a digitally signed message part
Bug#1051585: onnx failing autopkgtest blocks migration
Source: onnx Version: 1.13.1-1 Severity: serious Control: affects -1 +src:pytorch Control: affects -1 +src:pytorch-cuda Control: affects -1 +src:open3d Control: affects -1 +src:pytorch-vision Control: affects -1 +src:baler Control: affects -1 +src:pytorch-scatter Control: affects -1 +src:pytorch-audio Control: affects -1 +src:skorch Control: affects -1 +src:invesalius Control: affects -1 +src:tpot Control: affects -1 +src:pytorch-ignite Control: affects -1 +src:pytorch-sparse Control: affects -1 +src:pytorch-text The failing autopkgtest blocks migration for onnx and packages that depend on it, Mattias signature.asc Description: This is a digitally signed message part
Bug#1051258: Fixed upstream
Control: tag 1051258 +fixed-upstream +patch Applying the change from the upstream commit: https://github.com/pytorch/pytorch/commit/0c4fa0229625ccc6fcb9ae2867e98ce285e78946 fixes the FTBFS on ppc64el. This was verified using a schroot build on the platti.debian.org porterbox. Link to patch: https://github.com/pytorch/pytorch/commit/0c4fa0229625ccc6fcb9ae2867e98ce285e78946.patch Mattias signature.asc Description: This is a digitally signed message part
Bug#1050175: Missing symbol when importing torch
Package: python3-torch Version: 1.13.1+dfsg-4 Severity: serious Importing torch results in failure due to missing symbols: $ python3 Python 3.11.4 (main, Jun 7 2023, 10:13:09) [GCC 12.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import torch Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3/dist-packages/torch/__init__.py", line 218, in from torch._C import * # noqa: F403 ^^ ImportError: /lib/x86_64-linux-gnu/libtorch_cpu.so.1.13: undefined symbol: _ZN4onnx7checker11check_modelERKNS_10ModelProtoE >>> pytorch requires rebuild due to updated libonnx1: $ c++filt _ZN4onnx7checker11check_modelERKNS_10ModelProtoE onnx::checker::check_model(onnx::ModelProto const&) $ dpkg-query --show python3-torch libonnx1 libonnx1:amd64 1.13.1-1 python3-torch 1.13.1+dfsg-4 Mattias signature.asc Description: This is a digitally signed message part
Bug#1039924: New version
Upstream has tagged a new version 1.1.0 and removed the tag v1.2.0 from the git repo. This means that the version number goes backwards!!! The version that is intended to be packages is therefore now 1.1.0. Mattias signature.asc Description: This is a digitally signed message part
Bug#1039924: ITP: baler -- Baler - a machine learning based data compression tool
Package: wnpp Severity: wishlist Owner: Mattias Ellert * Package name: baler Version : 1.2.0 * URL : https://github.com/baler-collaboration/baler/ * License : Apache-2.0 Description : Baler - a machine learning based data compression tool Baler is a tool used to test the feasibility of compressing different types of scientific data using machine learning-based autoencoders. Baler provides you with an easy way to: 1. Train a machine learning model on your data 2. Compress your data with that model. This will also save the compressed file and model 3. Decompress the file using the model at a later time 4. Plot the performance of the compression/decompression signature.asc Description: This is a digitally signed message part
Bug#1038160: googletest on armel
Investigating the armel build on the armmel porterbox (abel.debian.org). Commenting out line 1394 in gmock-matchers-misc_test.cc results in that the test succeeds: EXPECT_THAT(some_list, Contains(3).Times(2)); EXPECT_THAT(some_list, Contains(2).Times(1)); EXPECT_THAT(some_list, Contains(Ge(2)).Times(3)); // EXPECT_THAT(some_list, Contains(Ge(2)).Times(Gt(2))); EXPECT_THAT(some_list, Contains(4).Times(0)); EXPECT_THAT(some_list, Contains(_).Times(4)); EXPECT_THAT(some_list, Not(Contains(5).Times(1))); Compiling the unmodified file with -O1 insted of -O2 also results in that the test succeeds. The output of the test says: [ RUN ] ContainsTimes.ListMatchesWhenElementQuantityMatches ./googlemock/test/gmock-matchers-misc_test.cc:1394: Failure Value of: some_list Expected: quantity of elements that match is >= 2 is > 3 Actual: { 3, 1, 2, 3 }, whose elements (0, 2, 3) match but whose match quantity of 3 does not match [ FAILED ] ContainsTimes.ListMatchesWhenElementQuantityMatches (0 ms) Contains(Ge(2)).Times(Gt(2)) should mean: Expected: quantity of elements that match is >= 2 is > 2 But according to the test output the actual test performed is Expected: quantity of elements that match is >= 2 is > 3 which fails. It looks like a compiler bug. With -O2 the line EXPECT_THAT(some_list, Contains(Ge(2)).Times(Gt(2))); is miscompiled as EXPECT_THAT(some_list, Contains(Ge(2)).Times(Gt(3))); Consider reporting this against gcc-12 package. Mattias Ellert signature.asc Description: This is a digitally signed message part
Bug#1033875: nmu: gridsite
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Control: affects -1 + src:gridsite This is a re-request of the gridsite nmu requested in: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033347 That request was created March 23 and requested an nmu for gridsite_3.0.0~20180202git2fdbc6f-3. However the version in unstable at the time was 3.0.0~20230214gitee81151-1 (accepted in unstable March 2, migrated to testing March 24). Since the scheduled nmu was for a version no longer in unstable it never happened. The requested nmu was to rebuild on 32 bit architectures due to a bug in fakeroot that caused some files and directories in the package to have the wrong group and user. The current version was uploaded March 2 and the fakeroot bug was fixed in fakeroot 1.31-1.1, which was also uploaded on March 2. Unfortunately the fakeroot build had not reached the buildroots when gridsite was built. An nmu of gridsite 3.0.0~20230214gitee81151-1 is needed on the following architectures: armel armhf hppa i386 m68k mipsel sh4 Make sure that fakeroot >= 1.31-1.1 is used (current version in unstable is -1.2). These nmus should possibly be allowed to go into the upcoming release as well in order to fix the issue also there. Mattias Ellert signature.asc Description: This is a digitally signed message part
Bug#1030947: scipy: FTBFS on hppa
Source: scipy Version: 1.10.0-4 Severity: important Tags: ftbfs patch Merge request: https://salsa.debian.org/python-team/packages/scipy/-/merge_requests/1 signature.asc Description: This is a digitally signed message part
Bug#1030178: Compilation of boost1.81 fails on x32 due to wrong compiler flag -march=i686
Source: boost1.81 Version: 1.81.0-4 Severity: important Tags: ftbfs User: debian-...@lists.debian.org Usertags: port-x32 ftbfs-x32 End of build log from buildd: gcc.compile.c++ bin.v2/libs/chrono/build/gcc-12/release/debug-symbols-on/threading-multi/visibility-hidden/chrono.o "g++" -fvisibility-inlines-hidden -g -O2 -ffile-prefix-map=/<>=. -specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -Wno-unused-local-typedefs -fPIC -pthread -O3 -finline-functions -Wno-inline -Wall -Wextra -g -fvisibility=hidden -Wdate-time -D_FORTIFY_SOURCE=2 -march=i686 -Wno-long-long -DBOOST_ALL_DYN_LINK=1 -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I"." -c -o "bin.v2/libs/chrono/build/gcc-12/release/debug-symbols-on/threading-multi/visibility-hidden/chrono.o" "libs/chrono/src/chrono.cpp" cc1plus: error: CPU you selected does not support x86-64 instruction set ...failed gcc.compile.c++ bin.v2/libs/chrono/build/gcc-12/release/debug-symbols-on/threading-multi/visibility-hidden/chrono.o... gcc.compile.c++ bin.v2/libs/chrono/build/gcc-12/release/debug-symbols-on/threading-multi/visibility-hidden/thread_clock.o "g++" -fvisibility-inlines-hidden -g -O2 -ffile-prefix-map=/<>=. -specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -Wno-unused-local-typedefs -fPIC -pthread -O3 -finline-functions -Wno-inline -Wall -Wextra -g -fvisibility=hidden -Wdate-time -D_FORTIFY_SOURCE=2 -march=i686 -Wno-long-long -DBOOST_ALL_DYN_LINK=1 -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I"." -c -o "bin.v2/libs/chrono/build/gcc-12/release/debug-symbols-on/threading-multi/visibility-hidden/thread_clock.o" "libs/chrono/src/thread_clock.cpp" cc1plus: error: CPU you selected does not support x86-64 instruction set ...failed gcc.compile.c++ bin.v2/libs/chrono/build/gcc-12/release/debug-symbols-on/threading-multi/visibility-hidden/thread_clock.o... ...failed updating 2 targets... ...updated 42 targets... make[1]: *** [debian/rules:189: override_dh_auto_build-common] Error 1 make[1]: Leaving directory '/<>' make: *** [debian/rules:180: build-arch] Error 2 dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit status 2 signature.asc Description: This is a digitally signed message part
Bug#1021551: bullseye-pu: package voms-api-java_3.3.2-1+deb11u1
bullseye-pu: package voms-api-java_3.3.2-1+deb11u1 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028546 signature.asc Description: This is a digitally signed message part
Bug#1028546: bullseye-pu: package voms-api-java_3.3.2-1+deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu This proposed update fixes a FTBFS in bullseye. It adds the patches used to fix the same issue in testing and unstable. debdiff is attached. Changes: voms-api-java (3.3.2-1+deb11u1) bullseye; urgency=medium . * Disable tests failing with bouncycastle 1.71 (Closes: #1011698) * Disable tests that fail due to expired certificates (Closes: #1021551) Mattias Ellert diff -Nru voms-api-java-3.3.2/debian/changelog voms-api-java-3.3.2/debian/changelog --- voms-api-java-3.3.2/debian/changelog 2020-10-14 05:44:33.0 +0200 +++ voms-api-java-3.3.2/debian/changelog 2023-01-12 14:26:32.0 +0100 @@ -1,3 +1,10 @@ +voms-api-java (3.3.2-1+deb11u1) bullseye; urgency=medium + + * Disable tests failing with bouncycastle 1.71 (Closes: #1011698) + * Disable tests that fail due to expired certificates (Closes: #1021551) + + -- Mattias Ellert Thu, 12 Jan 2023 14:26:32 +0100 + voms-api-java (3.3.2-1) unstable; urgency=medium * Update to version 3.3.2 - matches canl-java 2.6.x diff -Nru voms-api-java-3.3.2/debian/copyright voms-api-java-3.3.2/debian/copyright --- voms-api-java-3.3.2/debian/copyright 2020-10-14 05:44:33.0 +0200 +++ voms-api-java-3.3.2/debian/copyright 2023-01-12 14:26:32.0 +0100 @@ -19,7 +19,7 @@ Files: debian/* Copyright: - 2012-2020, Mattias Ellert + 2012-2023, Mattias Ellert License: Apache-2.0 License: Apache-2.0 diff -Nru voms-api-java-3.3.2/debian/patches/series voms-api-java-3.3.2/debian/patches/series --- voms-api-java-3.3.2/debian/patches/series 2020-10-14 05:44:33.0 +0200 +++ voms-api-java-3.3.2/debian/patches/series 2022-12-13 09:42:05.0 +0100 @@ -1,2 +1,13 @@ -# Disable tests using non-local network interface -voms-api-java-no-local.patch +# Disable failing tests +# IllegalState object explicit - implicit expected. +# https://github.com/italiangrid/voms-api-java/issues/29 +voms-api-java-disable-some-tests.patch + +# Disable tests that fail due to expired certificates +# https://github.com/italiangrid/voms-api-java/issues/30 +# 2022-09-24 (test0.cert.pem, wilco_cnaf_infn_it.cert.pem) +voms-api-java-expired-2022-09-24.patch +# 2022-10-08 (test_host_cnaf_infn_it.cert.pem) +voms-api-java-expired-2022-10-08.patch +# 2022-12-02 (test_host_2_cnaf_infn_it.cert.pem) +voms-api-java-expired-2022-12-12.patch diff -Nru voms-api-java-3.3.2/debian/patches/voms-api-java-disable-some-tests.patch voms-api-java-3.3.2/debian/patches/voms-api-java-disable-some-tests.patch --- voms-api-java-3.3.2/debian/patches/voms-api-java-disable-some-tests.patch 1970-01-01 01:00:00.0 +0100 +++ voms-api-java-3.3.2/debian/patches/voms-api-java-disable-some-tests.patch 2022-06-22 11:32:12.0 +0200 @@ -0,0 +1,62 @@ +diff --git a/src/test/java/org/italiangrid/voms/test/ac/TestACGeneration.java b/src/test/java/org/italiangrid/voms/test/ac/TestACGeneration.java +index bc7557c..32ba7a5 100644 +--- a/src/test/java/org/italiangrid/voms/test/ac/TestACGeneration.java b/src/test/java/org/italiangrid/voms/test/ac/TestACGeneration.java +@@ -191,7 +191,7 @@ public class TestACGeneration { + return ga; + } + +- @Test ++ // @Test + public void testGeneratedACParsing() throws KeyStoreException, + CertificateException, FileNotFoundException, IOException, + OperatorCreationException { +@@ -230,7 +230,7 @@ public class TestACGeneration { + + } + +- @Test ++ // @Test + public void testACValidation() { + + ValidationResultChecker c = new ValidationResultChecker(true); +@@ -247,7 +247,7 @@ public class TestACGeneration { + + } + +- @Test ++ // @Test + public void testLSCValidationFailure() { + + ValidationResultChecker c = new ValidationResultChecker(false, +@@ -264,7 +264,7 @@ public class TestACGeneration { + assertEquals(validatedAttrs.size(), 0); + } + +- @Test ++ // @Test + public void testExpiredAACertValidationFailure() + throws OperatorCreationException { + +@@ -284,7 +284,7 @@ public class TestACGeneration { + assertEquals(validatedAttrs.size(), 0); + } + +- @Test ++ // @Test + public void testRevokedAACertValidationFailure() { + + ValidationResultChecker c = new ValidationResultChecker(false, +diff --git a/src/test/java/org/italiangrid/voms/test/ac/TestFakeVOMSACService.java b/src/test/java/org/italiangrid/voms/test/ac/TestFakeVOMSACService.java +index 6eca55f..49f0498 100644 +--- a/src/test/java/org/italiangrid/voms/test/ac/TestFakeVOMSACService.java b/src/test/java/org/italiangrid/voms/test/ac/TestFakeVOMSACService.java +@@ -54,7 +54,7 @@ public class TestFakeVOMSACService extends TestACSupport { + initializeCredentials(); + } + +- @Test ++ // @Test + public void testFakeAcServiceCreation() { + + ACGenerationParams params = ACGenerationParams.builder() diff -Nru voms-api-java-3.3.2/debian/patches/voms-api-java-expired-2022-09-24.patch
Bug#1014804: nmu: srm-ifce 1.24.5-1
Package: release.debian.org User: release.debian@packages.debian.org Usertags: binnmu Severity: normal The libgfal-srm-ifce1 binary package built from the srm-ifce source package has a dependency on libssl1.1 on the following architectures: hppa, m68k, sh4, sparc64 It needs a binNMU for the libssl3 transition on those architectures. https://packages.debian.org/unstable/libgfal-srm-ifce1 nmu srm-ifce_1.24.5-1 . hppa m68k sh4 sparc64 . -m 'Rebuild against libssl3' Mattias signature.asc Description: This is a digitally signed message part
Bug#1014582: Acknowledgement (Build failure with googletest 1.12)
Here is a possible patch. With this patch it builds both on testing (googletest 1.11.0) and unstable (googletest 1.12.1). The patch need some tweaks to be upstreamable since it used the Debian path to the googletest source. Mattias diff -ur seqan3-3.2.0+ds.orig/test/unit/test/CMakeLists.txt seqan3-3.2.0+ds/test/unit/test/CMakeLists.txt --- seqan3-3.2.0+ds.orig/test/unit/test/CMakeLists.txt 2022-06-20 13:58:01.0 + +++ seqan3-3.2.0+ds/test/unit/test/CMakeLists.txt 2022-07-08 12:24:37.678861725 + @@ -1,3 +1,17 @@ +include (CheckCXXSourceCompiles) + +set (CMAKE_REQUIRED_INCLUDES /usr/src/googletest/googletest/include) + +check_cxx_source_compiles (" +#include +decltype(testing::internal::Nullopt()) x(); +int main() {} +" GTEST_HAS_NULLOPT) + +if (GTEST_HAS_NULLOPT) +add_definitions (-DGTEST_HAS_NULLOPT) +endif() + seqan3_test (expect_range_eq_test.cpp) seqan3_test (expect_same_type_test.cpp) seqan3_test (file_access_test.cpp) diff -ur seqan3-3.2.0+ds.orig/test/unit/test/pretty_printing_test.cpp seqan3-3.2.0+ds/test/unit/test/pretty_printing_test.cpp --- seqan3-3.2.0+ds.orig/test/unit/test/pretty_printing_test.cpp 2022-06-20 13:58:01.0 + +++ seqan3-3.2.0+ds/test/unit/test/pretty_printing_test.cpp 2022-07-08 12:24:37.678861725 + @@ -67,7 +67,11 @@ EXPECT_EQ(gtest_str(std::vector>{{0, 1}, {2, 3}, {1, 2}, {0}}), "[[0,1],[2,3],[1,2],[0]]"s); EXPECT_EQ(debug_str(std::vector>{{0, 1}, {2, 3}, {1, 2}, {0}}), "[[0,1],[2,3],[1,2],[0]]"s); +#ifdef GTEST_HAS_NULLOPT +EXPECT_EQ(gtest_str(std::nullopt), "(nullopt)"s); +#else EXPECT_EQ(gtest_str(std::nullopt), ""s); +#endif EXPECT_EQ(debug_str(std::nullopt), ""s); } signature.asc Description: This is a digitally signed message part
Bug#1014582: Build failure with googletest 1.12
Source: seqan3 Version: 3.2.0+ds-1 Severity: serious The package fails to build in unstable due to a failing test. The failure is due to a change in googletest 1.12 7451/8534 Test #7451: test/pretty_printing_test::pretty_printing.std_output ..***Failed 0.16 sec Running main() from /usr/src/googletest/googletest/src/gtest_main.cc Note: Google Test filter = pretty_printing.std_output [==] Running 1 test from 1 test suite. [--] Global test environment set-up. [--] 1 test from pretty_printing [ RUN ] pretty_printing.std_output /tmp/autopkgtest-lxc.y_bdsw4i/downtmp/autopkgtest_tmp/unit/test/pretty_printing_test.cpp:70: Failure Expected equality of these values: gtest_str(std::nullopt) Which is: "(nullopt)" ""s Which is: "" [ FAILED ] pretty_printing.std_output (0 ms) [--] 1 test from pretty_printing (0 ms total) [--] Global test environment tear-down [==] 1 test from 1 test suite ran. (0 ms total) [ PASSED ] 0 tests. [ FAILED ] 1 test, listed below: [ FAILED ] pretty_printing.std_output 1 FAILED TEST The following tests FAILED: 7451 - test/pretty_printing_test::pretty_printing.std_output (Failed) The fix is something like this: diff -ur seqan3-3.2.0+ds/test/unit/test/pretty_printing_test.cpp seqan3-3.2.0+ds.new/test/unit/test/pretty_printing_test.cpp --- seqan3-3.2.0+ds/test/unit/test/pretty_printing_test.cpp 2022-07-08 10:35:03.98400 +0200 +++ seqan3-3.2.0+ds.new/test/unit/test/pretty_printing_test.cpp 2022-07-08 10:22:40.12400 +0200 @@ -67,7 +67,11 @@ EXPECT_EQ(gtest_str(std::vector>{{0, 1}, {2, 3}, {1, 2}, {0}}), "[[0,1],[2,3],[1,2],[0]]"s); EXPECT_EQ(debug_str(std::vector>{{0, 1}, {2, 3}, {1, 2}, {0}}), "[[0,1],[2,3],[1,2],[0]]"s); +#if [condition that indicates googletest version is >= 1.12] +EXPECT_EQ(gtest_str(std::nullopt), "(ynullopt)"s); +#else EXPECT_EQ(gtest_str(std::nullopt), ""s); +#endif EXPECT_EQ(debug_str(std::nullopt), ""s); } I don't know the best way to define the [condition that indicates googletest version is >= 1.12] The seqan build is used as a autopkgtest for googletest, so this failure is blocking the migration to testing for the googletest package. (Can this be overridden somehow, if seqan is not fixed?) Mattias signature.asc Description: This is a digitally signed message part
Bug#1012744: graphviz: Drop ruby plugin on ia64
Package: graphviz Version: 2.42.2-6 Severity: important Control: tag -1 patch Ruby is not available on ia64. Since graphviz tries to build the ruby plugin for all architectures, the graphviz build fails on ia64. Since most packages that use doxygen during the build also require graphviz, many packages can't be built on ia64. The dot binary doesn't need the ruby plugin, so a build without the ruby plugin would make those packages buildable again. The attached patch disables the ruby plugin on ia64. Mattias diff -ur graphviz-2.42.2/debian/control graphviz-2.42.2/debian/control --- graphviz-2.42.2/debian/control 2022-02-06 18:03:12.0 + +++ graphviz-2.42.2/debian/control 2022-06-13 03:29:09.832878005 + @@ -24,8 +24,8 @@ ghostscript, lua5.2, liblua5.2-dev, - ruby, - ruby-dev (>= 1:2.2), + ruby [!ia64], + ruby-dev (>= 1:2.2) [!ia64], libargon2-dev, libsodium-dev, libxml2-dev, diff -ur graphviz-2.42.2/debian/rules graphviz-2.42.2/debian/rules --- graphviz-2.42.2/debian/rules 2022-02-06 18:03:12.0 + +++ graphviz-2.42.2/debian/rules 2022-06-13 04:00:35.659683356 + @@ -17,6 +17,15 @@ DEB_CFLAGS_MAINT_APPEND += "-fno-ipa-sra" endif +N = + +ifeq ($(DEB_HOST_ARCH),ia64) +RUBY = --disable-ruby +N += -Nlibgv-ruby +else +RUBY = --enable-ruby +endif + PYTHON_VERSIONS = $(shell pyversions -r) PYTHON3_VERSIONS = $(shell py3versions -r) @@ -71,7 +80,7 @@ --enable-guile \ --enable-lua \ --disable-php \ - --enable-ruby \ + $(RUBY) \ --enable-tcl \ --disable-java \ --disable-ocaml \ @@ -108,7 +117,7 @@ rm -f $(CURDIR)/debian/graphviz-doc/usr/share/doc/graphviz/ChangeLog %: - dh $@ --with python3 + dh $@ --with python3 $(N) .PHONY: override_dh_clean override_dh_autoreconf override_dh_auto_configure \ override_dh_auto_test override_dh_auto_install \ signature.asc Description: This is a digitally signed message part
Bug#1012467: davix ships complete lyrics of "Never Gonna Give You Up"
Control: forwarded 1012467 https://github.com/cern-fts/davix/issues/97 Control: tag 1012467 +fixed-upstream The issue was addressed upstream in this commit: https://github.com/cern-fts/davix/commit/5d15956648c0984094d6147cd2b67c195c5c335f Mattias signature.asc Description: This is a digitally signed message part
Bug#1011517: ITP: gfal2-bindings -- Python bindings for gfal2
Package: wnpp Severity: wishlist Owner: Mattias Ellert * Package name: gfal2-bindings Version : 1.11.1 * URL : https://dmc-docs.web.cern.ch/dmc-docs/gfal2-python.html * License : Apache-2.0 Description : Python bindings for gfal2. GFAL2 offers a single, simple and portable API for the file operations in grids and cloud environments. signature.asc Description: This is a digitally signed message part
Bug#1011234: fakeroot doesn't correctly detect copied device nodes on ia64
Control: tag 1011234 +patch The attached patch fixes the issue: Mattias diff -ur fakeroot-1.28.orig/libfakeroot.c fakeroot-1.28/libfakeroot.c --- fakeroot-1.28.orig/libfakeroot.c 2022-03-04 14:21:41.0 + +++ fakeroot-1.28/libfakeroot.c 2022-05-20 04:57:29.491263557 + @@ -99,6 +99,8 @@ #if defined __linux__ #if defined (__aarch64__) #define _STAT_VER 0 + #elif defined (__ia64__) + #define _STAT_VER 1 #elif defined (__powerpc__) && __WORDSIZE == 64 #define _STAT_VER 1 #elif defined (__riscv) && __riscv_xlen==64 smime.p7s Description: S/MIME cryptographic signature
Bug#1011234: fakeroot doesn't correctly detect copied device nodes on ia64
tor 2022-05-19 klockan 07:46 +0200 skrev Mattias Ellert: > Is _STAT_VER correct for ia64? > > https://salsa.debian.org/clint/fakeroot/-/blob/master/libfakeroot.c#L98-L116 > > Mattias > According to https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/ia64/xstatver.h;h=f24ab4a9ee158d7f0890cd228b20bf1e278d332b;hb=HEAD _STAT_VER should be 1 for ia64. The libfakeroot.c has no check for ia64, and uses the default linux value of 3. Mattias smime.p7s Description: S/MIME cryptographic signature
Bug#1011234: fakeroot doesn't correctly detect copied device nodes on ia64
Is _STAT_VER correct for ia64? https://salsa.debian.org/clint/fakeroot/-/blob/master/libfakeroot.c#L98-L116 Mattias signature.asc Description: This is a digitally signed message part
Bug#1011234: fakeroot doesn't correctly detect copied device nodes on ia64
tor 2022-05-19 klockan 00:02 + skrev Clint Adams: > Is the output of > > strace -e '%%stat' sh -c 'test -c /dev/null' > > conspicuously different on ia64 in contrast with other architectures? There is no major difference: x86_64: ellert@debian-unstable:~$ uname -a Linux debian-unstable 5.17.0-2-amd64 #1 SMP PREEMPT Debian 5.17.6-1 (2022-05-11) x86_64 GNU/Linux ellert@debian-unstable:~$ strace -e '%%stat' sh -c 'test -c /dev/null' newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=107023, ...}, AT_EMPTY_PATH) = 0 newfstatat(3, "", {st_mode=S_IFREG|0755, st_size=1900992, ...}, AT_EMPTY_PATH) = 0 newfstatat(AT_FDCWD, "/home/ellert", {st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0 newfstatat(AT_FDCWD, ".", {st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0 newfstatat(AT_FDCWD, "/dev/null", {st_mode=S_IFCHR|0666, st_rdev=makedev(0x1, 0x3), ...}, 0) = 0 +++ exited with 0 +++ ia64: ellert@yttrium:~$ uname -a Linux yttrium 5.17.0-1-mckinley #1 SMP Debian 5.17.3-1 (2022-04-18) ia64 GNU/Linux ellert@yttrium:~$ strace -e '%%stat' sh -c '[ -c /dev/null ]' newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=25579, ...}, AT_EMPTY_PATH) = 0 newfstatat(3, "", {st_mode=S_IFREG|0755, st_size=2937560, ...}, AT_EMPTY_PATH) = 0 newfstatat(AT_FDCWD, "/home/ellert", {st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0 newfstatat(AT_FDCWD, ".", {st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0 newfstatat(AT_FDCWD, "/dev/null", {st_mode=S_IFCHR|0666, st_rdev=makedev(0x1, 0x3), ...}, 0) = 0 +++ exited with 0 +++ yttrium.debian.net is the debian ia64 porterbox, so you can probably run these test too. Mattias signature.asc Description: This is a digitally signed message part
Bug#1011234: fakeroot doesn't correctly detect copied device nodes on ia64
ons 2022-05-18 klockan 15:03 + skrev Clint Adams: > On Wed, May 18, 2022 at 04:43:08PM +0200, Mattias Ellert wrote: > > However, on ia64 it fails: > > > > ellert@yttrium:~$ fakeroot ./fakeroot-test.sh > > crw-rw-rw- 1 root root 1, 3 May 10 06:51 /dev/null > > Original is device > > crw-rw-rw- 1 root root 1, 3 May 10 06:51 newdev/null > > Copy is not device > > ellert@yttrium:~$ echo $? > > 1 > > Could you run `stat` on newdev/null from within the script, > and comment out the `rm` so that you can run `stat` on it without > fakeroot afterward? Replacing "rm -rf newdev" with "stat newdev/null": ellert@yttrium:~$ fakeroot ./fakeroot-test.sh crw-rw-rw- 1 root root 1, 3 May 10 06:51 /dev/null Original is device crw-rw-rw- 1 root root 1, 3 May 10 06:51 newdev/null Copy is not device File: newdev/null Size: 0 Blocks: 0 IO Block: 4096 character special file Device: 802h/2050d Inode: 6429907 Links: 1 Device type: 1,3 Access: (0666/crw-rw-rw-) Uid: (0/root) Gid: (0/root) Access: 2022-05-18 15:18:53.847679259 + Modify: 2022-05-10 06:51:55.0 + Change: 2022-05-18 15:18:53.847679259 + Birth: 2022-05-18 15:18:53.847679259 + ellert@yttrium:~$ stat newdev/null File: newdev/null Size: 0 Blocks: 0 IO Block: 4096 regular empty file Device: 802h/2050d Inode: 6429907 Links: 1 Access: (0666/-rw-rw-rw-) Uid: ( 3156/ ellert) Gid: ( 3156/ ellert) Access: 2022-05-18 15:18:53.847679259 + Modify: 2022-05-10 06:51:55.0 + Change: 2022-05-18 15:18:53.847679259 + Birth: 2022-05-18 15:18:53.847679259 + Mattias smime.p7s Description: S/MIME cryptographic signature
Bug#1011234: fakeroot doesn't correctly detect copied device nodes on ia64
Package: fakeroot Version: 1.26-1 Severity: important Control: affects -1 globus-gridftp-server Using the following test script: $ cat fakeroot-test.sh #! /bin/sh res=0 mkdir newdev (cd /dev; tar chf - null) | (cd newdev; tar xf -) ls -l /dev/null if [ -c /dev/null ] ; then echo Original is device else echo Original is not device res=1 fi ls -l newdev/null if [ -c newdev/null ] ; then echo Copy is device else echo Copy is not device res=1 fi rm -rf newdev exit $res On most architectures this works as expected: $ fakeroot ./fakeroot-test.sh crw-rw-rw- 1 root root 1, 3 17 maj 10.09 /dev/null Original is device crw-rw-rw- 1 root root 1, 3 17 maj 10.09 newdev/null Copy is device $ echo $? 0 However, on ia64 it fails: ellert@yttrium:~$ fakeroot ./fakeroot-test.sh crw-rw-rw- 1 root root 1, 3 May 10 06:51 /dev/null Original is device crw-rw-rw- 1 root root 1, 3 May 10 06:51 newdev/null Copy is not device ellert@yttrium:~$ echo $? 1 fakeroot 1.26-1 is the latest version of fakeroot built for ia64. Mattias signature.asc Description: This is a digitally signed message part
Bug#995916: std::stoi, std::stol, std::stoul, ... broken on sh4
Source: gcc-10 Version: 10.3.0-11 Severity: important User: debian-sup...@lists.debian.org Usertags: sh4 X-Debbugs-Cc: debian-sup...@lists.debian.org Control: affects -1 cmake ceph Here is a failure from a recent build of "cmake" on sh4: https://buildd.debian.org/status/fetch.php?pkg=cmake&arch=sh4&ver=3.21.3-4&stamp=1633638401&raw=0 g++ -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -D_FILE_OFFSET_BITS=64-DCMAKE_BOOTSTRAP-DCMake_HAVE_CXX_MAKE_UNIQUE=1 -I/<>/Build/Bootstrap.cmk -I/<>/Source -I/<>/Source/LexerParser -I/<>/Utilities/std -I/<>/Utilities -c /<>/Source/cmFileCopier.cxx -o cmFileCopier.o /<>/Source/cmFileCommand.cxx: In function ‘bool {anonymous}::HandleArchiveCreateCommand(const std::vector >&, cmExecutionStatus&)’: /<>/Source/cmFileCommand.cxx:3473:45: error: invalid initialization of reference of type ‘const wstring&’ {aka ‘const std::__cxx11::basic_string&’} from expression of type ‘std::string’ {aka ‘std::__cxx11::basic_string’} 3473 | compressionLevel = std::stoi(parsedArgs.CompressionLevel); | ~~~^~~~ In file included from /usr/include/c++/10/string:55, from /<>/Source/cmFileCommand.h:7, from /<>/Source/cmFileCommand.cxx:3: /usr/include/c++/10/bits/basic_string.h:6699:23: note: in passing argument 1 of ‘int std::__cxx11::stoi(const wstring&, std::size_t*, int)’ 6699 | stoi(const wstring& __str, size_t* __idx = 0, int __base = 10) |~~~^ gmake[2]: *** [Makefile:126: cmFileCommand.o] Error 1 gmake[2]: *** Waiting for unfinished jobs gmake[2]: Leaving directory '/<>/Build/Bootstrap.cmk' - Error when bootstrapping CMake: The std::stoi, std::stol, std::stoul, ... functions should be available in two versions. One accepting a std::string and one accepting a std::wstring. In g++ version 10.3.0-11 on sh4 only the std::wstring version is available, so when it tries to compile code that uses the std::string version it fails. The problem is that for some reason the the file /usr/include/sh4-linux-gnu/c++/10/bits/c++config.h provided by libstdc++-10-dev_10.3.0-11_sh4.deb contains the line /* #undef _GLIBCXX11_USE_C99_STDLIB */ The corresponding file for other architectures contains #define _GLIBCXX11_USE_C99_STDLIB 1 This is a regression wrt earlier versions, since this used to work without problems. Mattias Ellert signature.asc Description: This is a digitally signed message part
Bug#993642: ceph: FTBFS on powerpc
Source: ceph Version: 14.2.21-1 Severity: important Tags: ftbfs fixed-upstream patch Control: forwarded -1 https://github.com/ceph/ceph/pull/42962 Control: found -1 14.2.20-2 Control: found -1 14.2.20-1 Control: found -1 14.2.18-1 Control: found -1 14.2.16-2 Control: found -1 14.2.16-1 Control: found -1 14.2.15-4 Control: found -1 14.2.15-3 Control: found -1 14.2.15-2 Control: found -1 14.2.15-1 Control: found -1 14.2.9-1 Control: found -1 14.2.8-2 Control: found -1 14.2.8-1 Control: found -1 14.2.7-1 Control: found -1 14.2.6-5 Control: found -1 14.2.6-4 Control: found -1 14.2.6-3 Control: found -1 14.2.6-2 Control: found -1 14.2.6-1 Control: found -1 14.2.5-3 Control: found -1 14.2.5-2 Control: found -1 14.2.5-1 Control: found -1 14.2.4-9 Control: found -1 14.2.4-8 Control: found -1 14.2.4-7 Control: found -1 14.2.4-6 Control: found -1 14.2.4-5 Control: found -1 14.2.4-4 Control: found -1 14.2.4-3 Control: found -1 14.2.4-2 Control: found -1 12.2.11+dfsg1-2.1 Control: found -1 12.2.11+dfsg1-2 Control: found -1 12.2.11+dfsg1-1 Control: found -1 12.2.10+dfsg1-1 Control: found -1 12.2.8+dfsg1-5 Control: found -1 12.2.8+dfsg1-4 Control: found -1 12.2.8+dfsg1-3 Control: found -1 12.2.8+dfsg1-2 Control: found -1 12.2.8+dfsg1-1 I filed a merge request on salsa a week ago (Aug 26) regarding this: https://salsa.debian.org/ceph-team/ceph/-/merge_requests/7 It has not received any comments so far. Since the fix has now been merged upstream, are there any objections to me uploading an NMU with the fix? The patch with the fix from upstream is in the merge request. Mattias signature.asc Description: This is a digitally signed message part
Bug#893745: Fixed upstream
Control: forwarded 893745 https://foss.heptapod.net/pypy/cffi/-/issues/507 Control: tag 893745 +fixed-upstream The patch was sent upstream and accepted in https://foss.heptapod.net/pypy/cffi/-/commit/fbd7f15616b60abd84c7686e6067953a77afeaf1 Are there any objections to me uploading the NMU I proposed in the merge request on Salsa? Mattias signature.asc Description: This is a digitally signed message part
Bug#993501: Merge request on Salsa
Hi. I have created a merge request on salsa for this fix. https://salsa.debian.org/debian/openssl/-/merge_requests/6 Mattias signature.asc Description: This is a digitally signed message part
Bug#993501: openssl: FTBFS on kfreebsd-amd64 and kfreebsd-i386
Source: openssl Version: 1.1.1l-1 Severity: important Tags: ftbfs, patch, fixed-upstream Control: forward -1 https://github.com/openssl/openssl/pull/16477 Control: found -1 1.1.1k-1 Control: found -1 1.1.1j-1 Control: found -1 1.1.1i-3 Control: found -1 1.1.1i-2 Control: found -1 1.1.1i-1 Control: found -1 1.1.1h-1 Control: found -1 1.1.1g-1 Control: found -1 1.1.1f-1 Control: found -1 1.1.1e-1 Control: found -1 1.1.1d-2 Control: found -1 1.1.1d-1 Control: found -1 1.1.1b-2 Control: found -1 1.1.1b-1 Openssl fails to compile on Debian with kfreebsd kernels (kfreebsd- amd64, kfreebsd-i386). The error reported by the compiler is: ../crypto/uid.c: In function 'OPENSSL_issetugid': ../crypto/uid.c:50:22: error: 'AT_SECURE' undeclared (first use in this function) 50 | return getauxval(AT_SECURE) != 0; | ^ The git commit that fixes the 1.1.1 branch is: The issue has been fixed upstream. https://github.com/openssl/openssl/commit/1f8e36720fff9bdc9f08fe24a38cc91b1b78ddb0 I.e. the patch can be retrieved from https://github.com/openssl/openssl/commit/1f8e36720fff9bdc9f08fe24a38cc91b1b78ddb0.patch Mattias signature.asc Description: This is a digitally signed message part
Bug#893745: PR on salsa.debian.org
Control: tags 893745 + patch https://salsa.debian.org/python-team/packages/python-cffi/-/merge_requests/2 Mattias signature.asc Description: This is a digitally signed message part
Bug#991136: fetch-crl: Install fails on update-rc.d
Hi! The SysV init script should not be used on a system that is running systemd. It is there to be used on non-systemd Debian installations only (kfreebsd, hurd). If you have enabled this on a systemd based system, please disable it. On systemd based systems the proper way is to use the fetch-crl systemd timer unit. This is activated using: systemctl enable fetch-crl.timer systemctl start fetch-crl.timer There is also a fetch-crl systemd service unit. This is only intended to be run when the timer unit is triggered, and can not be enabled on its own - the unit files does not have an install section by design. The issue with missing certificates would better be addressed by updating the igtf-policy packages (if you are using them). Unfortunately, due to the freeze for the upcoming release, this package is not up to date in Debian and still contains references to an old discontinued CA that was removed from later upstream releases. If the discontinued CA (INFN-CA-2015) causes issued for you, you can reconfigure igtf-policy-classic to exclude it. See /usr/share/doc/igtf-policy-classic/README.Debian Let me know if this addresses your issues. Mattias Ellert tor 2021-07-15 klockan 13:22 +0200 skrev Carl-Fredrik Enell: > Package: fetch-crl > Version: 3.0.19-2 > Severity: important > > Dear Maintainer, > > > * I tried to uninstall and reinstall fetch-crl because of error > * messages regarding a non-existing certificate. > > * Packet configuration fails on update-rc.d: No default runlevel. > This is expected on a systemd based release as far as I can > understand. > init-system-helpers is installed. > > * I would expect fetch-crl to run from cron or a systemd timer, not > * to install anything in rcN.d. > > Best regards, > Carl-Fredrik Enell > > > -- System Information: > Debian Release: 10.10 > APT prefers stable > APT policy: (990, 'stable'), (500, 'stable-updates'), (500, > 'proposed-updates') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.10.0-0.bpo.7-amd64 (SMP w/64 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > LANGUAGE=en_US:en (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages fetch-crl depends on: > ii init-system-helpers 1.56+nmu1 > ii libwww-perl 6.36-2 > ii lsb-base 10.2019051400 > ii openssl 1.1.1d-0+deb10u6 > ii perl 5.28.1-6+deb10u1 > > fetch-crl recommends no packages. > > fetch-crl suggests no packages. > > -- no debconf information smime.p7s Description: S/MIME cryptographic signature
Bug#987273: CVE-2021-21783
tis 2021-04-20 klockan 20:32 +0200 skrev Moritz Muehlenhoff: > Package: libgsoap-2.8.104 > Version: 2.8.104-2 > Severity: important > File: gsoap > Tags: security > X-Debbugs-Cc: Debian Security Team > > This was assigned CVE-2021-21783: > https://talosintelligence.com/vulnerability_reports/TALOS-2021-1245 > > Cheers, > Moritz Hi Moritz. I can not fully comprehend this bug report. If I read the CVE-2021-21783 report, it basically says: We have noticed that the vulnerability we previously reported (CVE-2020-13576) was not fixed. We have therefore resubmitted it. We have investigated the following versions: Genivia gSOAP 2.8.109 Genivia gSOAP 2.8.110 However, the fix for CVE-2020-13576 was in gSOAP 2.8.111, so that this was still present in the two tested versions is expected. The page for previous CVE-2020-13576 does claim that it was fixed in an upstream release on 2020-11-20, which corresponds to version 2.8.109. I do not think this statement is correct. From my understanding of comparing the reported fault (including code snippets) with the changes to the source repository, I understand it to have been fixed in version 2.8.111, and not in 2.8.109 as the report claims. Since the reported fixed version in incorrect I can see why it was reported again. I think the reason for the wrong fixed version in the previous report is that the other 4 CVEs reported against gsoap at the same time (CVE-2020-13574, CVE-2020-13575, CVE-2020-13577 and CVE-2020-13578) were indeed fixed in version 2.8.109. So someone might just put the same fixed date on all 5 reports. The fix for CVE-2020-13576 from version 2.8.111 is already applied as a patch in the debian package version gsoap/2.8.104-3. And if this new CVE is indeed a duplicate there is nothing more to fix. Mattias signature.asc Description: This is a digitally signed message part
Bug#984837: unblock: gsoap/2.8.104-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock I have submitted an update for the gsoap package, back-porting several fixes for CVEs from upstream. It fixes the RC bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983596 Due to the current soft freeze, the migration delay is 10 days, which would mean 18 March. However the hard freeze starts March 12, after which migration requires an explicit unblock. Hence this unblock request. Due to the RC bug, the package is marked for auto-removal, together with many packages that depend on it: Marked for autoremoval on 11 April: #983596 high Version 2.8.104-2 of gsoap is marked for autoremoval from testing on Sun 11 Apr 2021. It is affected by #983596. The removal of gsoap will also cause the removal of (transitive) reverse dependencies: arc-gui- clients, cgsi-gsoap, davix, gfal2, gridsite, lcas-lcmaps-gt4-interface, lcmaps, lcmaps-plugins-basic, lcmaps-plugins-jobrep, lcmaps-plugins- verify-proxy, lcmaps-plugins-voms, myproxy, nordugrid-arc, nordugrid- arc-nagios-plugins, openstack-cluster-installer, srm-ifce, voms, voms- mysql-plugin, xrootd. You should try to prevent the removal by fixing these RC bugs. I hope you will consider unblocking the update. Debdiff attached. Mattias diff -Nru gsoap-2.8.104/debian/changelog gsoap-2.8.104/debian/changelog --- gsoap-2.8.104/debian/changelog 2020-07-25 08:30:12.0 +0200 +++ gsoap-2.8.104/debian/changelog 2021-03-08 14:06:23.0 +0100 @@ -1,3 +1,12 @@ +gsoap (2.8.104-3) unstable; urgency=high + + * Backporting upstream fixes (Closes: #983596) +- Fixes CVE: CVE-2020-13574 CVE-2020-13575 CVE-2020-13577 CVE-2020-13578 +- Fixes CVE: CVE-2020-13576 + * Urgency high due to fixing RC bug + + -- Mattias Ellert Mon, 08 Mar 2021 14:06:23 +0100 + gsoap (2.8.104-2) unstable; urgency=medium * Re-upload source only diff -Nru gsoap-2.8.104/debian/control gsoap-2.8.104/debian/control --- gsoap-2.8.104/debian/control 2020-07-22 15:23:55.0 +0200 +++ gsoap-2.8.104/debian/control 2021-03-08 14:06:23.0 +0100 @@ -13,7 +13,7 @@ Build-Depends-Indep: doxygen, graphviz -Standards-Version: 4.5.0 +Standards-Version: 4.5.1 Section: devel Vcs-Browser: https://salsa.debian.org/ellert/gsoap Vcs-Git: https://salsa.debian.org/ellert/gsoap.git diff -Nru gsoap-2.8.104/debian/copyright gsoap-2.8.104/debian/copyright --- gsoap-2.8.104/debian/copyright 2020-07-22 15:23:55.0 +0200 +++ gsoap-2.8.104/debian/copyright 2021-03-08 14:06:23.0 +0100 @@ -171,7 +171,7 @@ Files: debian/* Copyright: 2003-2007, Thomas Wana - 2011-2020, Mattias Ellert + 2011-2021, Mattias Ellert License: GPL-2+ On Debian systems, the complete text of the GPL version 2 license can be found in '/usr/share/common-licenses/GPL-2'. diff -Nru gsoap-2.8.104/debian/patches/gsoap-plugins-hardening.patch gsoap-2.8.104/debian/patches/gsoap-plugins-hardening.patch --- gsoap-2.8.104/debian/patches/gsoap-plugins-hardening.patch 1970-01-01 01:00:00.0 +0100 +++ gsoap-2.8.104/debian/patches/gsoap-plugins-hardening.patch 2021-03-08 11:28:34.0 +0100 @@ -0,0 +1,336 @@ +diff -ur gsoap2-code-r191/gsoap/plugin/httpda.c gsoap2-code-r192/gsoap/plugin/httpda.c +--- gsoap2-code-r191/gsoap/plugin/httpda.c 2020-06-30 21:06:47.0 +0200 gsoap2-code-r192/gsoap/plugin/httpda.c 2020-11-19 19:29:25.0 +0100 +@@ -1460,7 +1460,7 @@ + MUTEX_LOCK(http_da_session_lock); + + for (session = http_da_session; session; session = session->next) +-if (!strcmp(session->realm, realm) && !strcmp(session->nonce, nonce) && !strcmp(session->opaque, opaque)) ++if (session->realm && session->nonce && session->opaque && !strcmp(session->realm, realm) && !strcmp(session->nonce, nonce) && !strcmp(session->opaque, opaque)) + break; + + if (session) +diff -ur gsoap2-code-r191/gsoap/plugin/wsaapi.c gsoap2-code-r192/gsoap/plugin/wsaapi.c +--- gsoap2-code-r191/gsoap/plugin/wsaapi.c 2020-06-30 21:06:47.0 +0200 gsoap2-code-r192/gsoap/plugin/wsaapi.c 2020-11-19 19:29:25.0 +0100 +@@ -1056,7 +1056,7 @@ + oldheader->SOAP_WSA(FaultTo)->Address = oldheader->SOAP_WSA(ReplyTo)->Address; + } + /* use FaultTo */ +- if (oldheader && oldheader->SOAP_WSA(FaultTo) && !strcmp(oldheader->SOAP_WSA(FaultTo)->Address, soap_wsa_noneURI)) ++ if (oldheader && oldheader->SOAP_WSA(FaultTo) && oldheader->SOAP_WSA(FaultTo)->Address && !strcmp(oldheader->SOAP_WSA(FaultTo)->Address, soap_wsa_noneURI)) + return soap_send_empty_response(soap, SOAP_OK); /* HTTP ACCEPTED */ + soap->header = NULL; + /* allocate a new header */ +diff -ur gsoap2-code-r191/gsoap/plugin/wsseapi.c gsoap2-code-r192/gsoap/plugin/wsseapi.c +--- gsoap2-code-r191/gsoap/plugin/wsseapi.c
Bug#977960: I still have a symlink that points to nowhere
Hi. My currently installed version of libjs-jquery is $ dpkg-query --show libjs-jquery libjs-jquery3.5.1+dfsg+~3.5.5-4 which is currently the latest version. I have a symlink as follows: $ ls -l /usr/share/javascript/jquery lrwxrwxrwx 1 root root 29 12 May 2020 /usr/share/javascript/jquery -> /usr/share/nodejs/jquery/dist The target of this symlink does not exist. $ ls /usr/share/nodejs/jquery/dist ls: cannot access '/usr/share/nodejs/jquery/dist': No such file or directory The problem comes from the install history of the package. Version 3.5.1+dfsg+~3.5.4-4 changed a symlink to a directory, but failed to add a maintscript for this change. The following version 3.5.1+dfsg+~3.5.5-1 did add the missing maint- script, but put the previous version in it, not the version that added the script. symlink_to_dir /usr/share/javascript/jquery /usr/share/nodejs/jquery/dist 3.5.1+dfsg+~3.5.4-4~ instead of symlink_to_dir /usr/share/javascript/jquery /usr/share/nodejs/jquery/dist 3.5.1+dfsg+~3.5.5-1~ This means that for everyone that had already updated to 3.5.1+dfsg+~3.5.4-4, when they later updated to 3.5.1+dfsg+~3.5.5-1 the maintscript was not run. To fix this now, there needs to be a 3.5.1+dfsg+~3.5.5-5 update where the mainscriot is updated to symlink_to_dir /usr/share/javascript/jquery /usr/share/nodejs/jquery/dist 3.5.1+dfsg+~3.5.5-5~ For a reproducer 1. Install a version before 3.5.1+dfsg+~3.5.4-4 2. Update to 3.5.1+dfsg+~3.5.4-4 3. Update to a version after 3.5.1+dfsg+~3.5.4-4 Mattias smime.p7s Description: S/MIME cryptographic signature
Bug#979160: glibc FTBFS on kfreebsd-*: Uses configure option --enable-add-ons=fbtl
Source: glibc Version: 2.31-7 Severity: important User: debian-...@lists.debian.org The builds on kfreebsd-* currently fail during the patching step because one of the kfreebsd specific patches fails to apply. Fixing this issue is trivial and simply requires a refresh of the patch (attached). However, this trivial fix is not sufficient. The build then fails with: *** On GNU/kFreeBSD systems it is normal to compile GNU libc with the *** `fbtl' add-on. Without that, the library will be *** incompatible with normal GNU/kFreeBSD systems. *** If you really mean to not use this add-on, run configure again *** using the extra parameter `--disable-sanity-checks'. The package build tries to enable the fbtl add-on. The call to configure contains: $(CURDIR)/configure \ --host=x86_64-kfreebsd-gnu \ --build=$configure_build --prefix=/usr \ --enable-add-ons=libidn,"fbtl " \ However, the configure script does not have an --enable-add-ons option, so this is ignored. (Option is not listed by ./configure --help, nor found by grepping for it.) Mattias tst-unique is not supported by the FreeBSD ELF OSABI --- a/elf/Makefile +++ b/elf/Makefile @@ -145,7 +145,7 @@ tests += loadtest restest1 preloadtest loadfail multiload origtest resolvfail \ unload3 unload4 unload5 unload6 unload7 unload8 tst-global1 order2 \ tst-audit1 tst-audit2 tst-audit8 tst-audit9 \ tst-addr1 tst-thrlock \ - tst-unique1 tst-unique2 $(if $(CXX),tst-unique3 tst-unique4 \ + $(if $(CXX),tst-unique3 tst-unique4 \ tst-nodelete tst-dlopen-nodelete-reloc) \ tst-initorder tst-initorder2 tst-relsort1 tst-null-argv \ tst-tlsalign tst-tlsalign-extern tst-nodelete-opened \ @@ -207,8 +207,6 @@ modules-names = testobj1 testobj2 testobj3 testobj4 testobj5 testobj6 \ unload7mod1 unload7mod2 \ unload8mod1 unload8mod1x unload8mod2 unload8mod3 \ order2mod1 order2mod2 order2mod3 order2mod4 \ - tst-unique1mod1 tst-unique1mod2 \ - tst-unique2mod1 tst-unique2mod2 \ tst-auditmod9a tst-auditmod9b \ $(if $(CXX),tst-unique3lib tst-unique3lib2 tst-unique4lib \ tst-nodelete-uniquemod tst-nodelete-rtldmod \ signature.asc Description: This is a digitally signed message part
Bug#977748: ITP: scitokens-cpp -- C++ Implementation of the SciTokens Library
Package: wnpp Severity: wishlist Owner: Mattias Ellert * Package name: scitokens-cpp Version : 0.5.1 * URL : https://github.com/scitokens/scitokens-cpp * License : Apache-2.0, Expat, BSD-2-clause Description : This package implements a minimal library for creating and using SciTokens from C or C++. . SciTokens (https://scitokens.org) provide a token format for distributed authorization. The tokens are self-describing, can be verified in a distributed fashion (no need to contact the issuer to determine if the token is valid). This is convenient for a federated environment where several otherwise-independent storage endpoints want to delegate trust for an issuer for managing a storage allocation. signature.asc Description: This is a digitally signed message part
Bug#977560: dwz fails with .debug_line reference above end of section
Package: gcc-10 Version: 10.2.1-1 Severity: normal Affects: src:globus-rsl I recently updates some packages I maintain to compat level 13. Since they previously were on compat level 10, this meant that the dh_dwz that was added to the default sequence is now run for these packages. For most packages this did not create a problem. But for one of the packages the dh_dwz failed miserably. In the update for this package I added an empty override_dh_dwz rule to work around the problem. I don't know it the problem is with gcc producing broken debug information that is correctly rejected by dwz, or if it is dwz that fails to parse valid debug information generated by gcc. Please reassign the bug if appropriate. Steps to reproduce: Download affected package: $ dget https://deb.debian.org/debian/pool/main/g/globus-rsl/globus-rsl_11.2-1.dsc Enter the directory: $ cd globus-rsl-11.2 Edit the debian/rules file. Comment out the empty override_dh_dwz rule. $ emacs debian/rules Then build the package: $ dpkg-buildpackage The build ends in a failure: dh_dwz -a dwz: debian/libglobus-rsl2/usr/lib/debug/.dwz/x86_64-linux- gnu/libglobus-rsl2.debug: .debug_line reference above end of section dh_dwz: error: dwz -mdebian/libglobus-rsl2/usr/lib/debug/.dwz/x86_64- linux-gnu/libglobus-rsl2.debug -M/usr/lib/debug/.dwz/x86_64-linux- gnu/libglobus-rsl2.debug -- debian/libglobus-rsl2/usr/lib/x86_64-linux- gnu/libglobus_rsl.so.2.9.2 debian/libglobus-rsl2/usr/lib/x86_64-linux- gnu/libglobus_rsl_assist.so.2.9.2 returned exit code 1 make: *** [debian/rules:13: binary] Fel 1 dpkg-buildpackage: fel: fakeroot debian/rules binary subprocess returned exit status 2 $ dpkg-query -W gcc gcc-10 dwz binutils binutils2.35.1-4 dwz 0.13+20201015-2 gcc 4:10.2.0-1 gcc-10 10.2.1-1 signature.asc Description: This is a digitally signed message part
Bug#975022: ITP: libmacaroons -- C library supporting generation and use of macaroons
Package: wnpp Severity: wishlist Owner: Mattias Ellert * Package name: libmacaroons Version : 0.3.0 * URL : https://github.com/rescrv/libmacaroons * License : BSD-3-Clause Description : C library supporting generation and use of macaroons signature.asc Description: This is a digitally signed message part
Bug#975021: ITP: xrootd -- Extended ROOT file server
Package: wnpp Severity: wishlist Owner: Mattias Ellert * Package name: xrootd Version : 5.0.3 * URL : https://xrootd.org * License : LGPL-3 and BSD-4-clause Description : Extended ROOT file server The Extended root file server consists of a file server called xrootd and a cluster management server called cmsd. . The xrootd server was developed for the root analysis framework to serve root files. However, the server is agnostic to file types and provides POSIX-like access to any type of file. . The cmsd server is the next generation version of the olbd server, originally developed to cluster and load balance Objectivity/DB AMS database servers. It provides enhanced capability along with lower latency and increased throughput. signature.asc Description: This is a digitally signed message part
Bug#960649: Removed package(s) from unstable
> This message was generated automatically; if you believe that there is > a problem with it please contact the archive administrators by mailing > ftpmas...@ftp-master.debian.org. Hi FTP masters. Sorry, but What I tried to request from you was not what happened. Possibly, my request was not clear. My request was to remove the BINARY package gfal2 built for arm64, not all binary packages built for arm64 from the SOURCE package gfal2. As far as I could tell from the description of the "NBS" tag, I was supposed to list binary packages in the request... Before this change was done the 2.17.3-1 version of gfal2 was built for all architectures, including arm64. And I had no intent to request the removal of any of those. They were all good. Including the arm64 versions. The problem was that in addition to this, unstable also contains a very old 2.6.8-1 version for arm64. It was this version I wanted to have removed. Before you did your change, only the gfal2 binary package from this old arm64 build was visible. The reason being that the new build did not provide an arch specific arm64 gfal2 binary package, since this package is arch independent in the current version. Now that you have removed the current version of all the arm64 binary packages, the really really old 2.6.8-1 became the "current" version for arm64 for all binary packages. So now, not only the gfal2 binary package for arm64 (which was the one I wanted to remove, but it is still there) is at version 2.6.8-1 - but all binary packages built from the gfal2 source package is at this version for arm64. So your interpretation of my request made the problem worse rather than fixing it. To recover - remove the 2.6.8-1 version that is now "current" for arm64, then put back the 2.17.3-1 version that was removed in error. Mattias sön 2020-05-17 klockan 05:07 + skrev Debian FTP Masters: > We believe that the bug you reported is now fixed; the following > package(s) have been removed from unstable: > > gfal2-plugin-dcap | 2.17.3-1 | arm64 > gfal2-plugin-file | 2.17.3-1 | arm64 > gfal2-plugin-gridftp | 2.17.3-1 | arm64 > gfal2-plugin-http | 2.17.3-1 | arm64 > gfal2-plugin-mock | 2.17.3-1 | arm64 > gfal2-plugin-sftp | 2.17.3-1 | arm64 > gfal2-plugin-srm | 2.17.3-1 | arm64 > libgfal-transfer2 | 2.17.3-1 | arm64 > libgfal2-2 | 2.17.3-1 | arm64 > libgfal2-dev | 2.17.3-1 | arm64 > > --- Reason --- > ROM; NBS > -- > > Note that the package(s) have simply been removed from the tag > database and may (or may not) still be in the pool; this is not a bug. > The package(s) will be physically removed automatically when no suite > references them (and in the case of source, when no binary references > it). Please also remember that the changes have been done on the > master archive and will not propagate to any mirrors until the next > dinstall run at the earliest. > > Packages are usually not removed from testing by hand. Testing tracks > unstable and will automatically remove packages which were removed > from unstable when removing them from testing causes no dependency > problems. The release team can force a removal from testing if it is > really needed, please contact them if this should be the case. > > Bugs which have been reported against this package are not automatically > removed from the Bug Tracking System. Please check all open bugs and > close them or re-assign them to another package if the removed package > was superseded by another one. > > The version of this package that was in Debian prior to this removal > can still be found using http://snapshot.debian.org/. > > Thank you for reporting the bug, which will now be closed. If you > have further comments please address them to 960...@bugs.debian.org. > > The full log for this bug can be viewed at https://bugs.debian.org/960649 > > This message was generated automatically; if you believe that there is > a problem with it please contact the archive administrators by mailing > ftpmas...@ftp-master.debian.org. > > Debian distribution maintenance software > pp. > Scott Kitterman (the ftpmaster behind the curtain) signature.asc Description: This is a digitally signed message part
Bug#960649: RM: gfal2 [arm64] -- ROM; NBS
Package: ftp.debian.org Severity: normal Hi! According to https://packages.debian.org/sid/gfal2 the available versions of the gfal2 binary package in unstable are: ArchitectureVersion all 2.17.3-1 arm64 (unofficial port) 2.6.8-1 The gfal2 binary package was changed from arch dependent (any) to architecture independent (all) in version 2.10.2-1 (2015-12-02). For some reason an old architecture dependent version of the binary package seems to have been left behind in unstable for the arm64 architecture. According to https://wiki.debian.org/ftpmaster_Removals Binary packages no longer built from any source package ("NBS", i.e. "not built from source") should be handles automatically and a removal request should not be needed, but there seems to be some glitch here? Mattias signature.asc Description: This is a digitally signed message part
Bug#958659: googletest runs out of memory during build on sh4
Source: googletest Version: 1.10.0-2 The build of googletest has failed on sh4 for the last couple of versions: https://buildd.debian.org/status/logs.php?pkg=googletest&arch=sh4 The last attempted build ends with: out of memory allocating 2448912 bytes after a total of 120168448 bytes The debian/rules already does the -g1 trick for a few architectures to reduce memory usage. Possibly this could help for sh4 as well. ifeq ($(DEB_HOST_ARCH),hppa) CXXFLAGS += -mlong-calls else ifeq ($(DEB_BUILD_ARCH), mips) CXXFLAGS += -mxgot -g1 else ifeq ($(DEB_BUILD_ARCH), mips64el) CXXFLAGS += -mxgot else ifeq ($(DEB_BUILD_ARCH), mipsel) CXXFLAGS += -mxgot -g1 +else ifeq ($(DEB_BUILD_ARCH), sh4) +CXXFLAGS += -g1 endif Mattias signature.asc Description: This is a digitally signed message part
Bug#952622: myproxy: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 VERBOSE=1 returned exit code 2
reassign 952622 src:procps 2:3.3.16-2 fixed 952622 procps/2:3.3.16-3 retitle 952622 procps does not provide /bin/kill - violates FHS specification affects 952622 myproxy stop Section 3.4 of the Filesystem Hierarchy Standard (FHS) says: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s04.html The following commands, or symbolic links to commands, are required in /bin: In this list the command kill appears. signature.asc Description: This is a digitally signed message part
Bug#937153: pending removal request
The nordugrid-arc-gangliarc package has a pending removal request: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942385 Mattias signature.asc Description: This is a digitally signed message part
Bug#936828: pending removal request
The lcgdm package has a pending removal request: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942386 Mattias signature.asc Description: This is a digitally signed message part
Bug#920994: rocksdb linux only
Control: tags -1 + patch This debdiff suggest making the rocksdb plugin linux only. Mattias diff -Nru mariadb-10.3-10.3.18/debian/rules mariadb-10.3-10.3.18/debian/rules --- mariadb-10.3-10.3.18/debian/rules 2019-08-06 02:56:47.0 + +++ mariadb-10.3-10.3.18/debian/rules 2019-09-12 12:51:04.0 + @@ -47,6 +47,10 @@ CMAKEFLAGS += -DWITHOUT_ROCKSDB=true endif +ifneq (linux,$(DEB_HOST_ARCH_OS)) +CMAKEFLAGS += -DWITHOUT_ROCKSDB=true +endif + # Skip TokuDB if arch is not amd64 (also disable for kfreebsd-amd64 as it FTBFS) # Skipped on the x32 ABI too; untested, but unlikely to work given i386 is not # supported. diff -Nru mariadb-10.3-10.3.18/debian/tests/smoke mariadb-10.3-10.3.18/debian/tests/smoke --- mariadb-10.3-10.3.18/debian/tests/smoke 2019-08-06 02:56:47.0 + +++ mariadb-10.3-10.3.18/debian/tests/smoke 2019-09-12 12:51:04.0 + @@ -75,6 +75,7 @@ # Check whether RocksDB should be installed or not. plugin=mariadb-plugin-rocksdb if [ "`dpkg-architecture -qDEB_HOST_ARCH_BITS`" != 32 ] && + [ "`dpkg-architecture -qDEB_HOST_ARCH_OS`" = linux ] && [ "`dpkg-architecture -qDEB_HOST_ARCH_ENDIAN`" = little ]; then dpkg-query -W $plugin signature.asc Description: This is a digitally signed message part
Bug#942788: Fix FTBFS for GNU/Hurd
Package: libproc-processtable-perl Version: 0.59-1 Severity: normal Tags: patch The attached debdiff makes the package build for GNU/Hurd. Mattias diff -Nru libproc-processtable-perl-0.59/debian/patches/map-HALTED-to-STOP.patch libproc-processtable-perl-0.59/debian/patches/map-HALTED-to-STOP.patch --- libproc-processtable-perl-0.59/debian/patches/map-HALTED-to-STOP.patch 1970-01-01 01:00:00.0 +0100 +++ libproc-processtable-perl-0.59/debian/patches/map-HALTED-to-STOP.patch 2019-07-06 17:00:06.0 +0200 @@ -0,0 +1,11 @@ +diff -ur libproc-processtable-perl-0.59.orig/os/Linux.c libproc-processtable-perl-0.59/os/Linux.c +--- libproc-processtable-perl-0.59.orig/os/Linux.c libproc-processtable-perl-0.59/os/Linux.c +@@ -537,6 +537,7 @@ + prs->state = get_string(UWAIT); + break; + case 'T': ++case 'H': /* GNU Hurd HALTED state */ + prs->state = get_string(STOP); + break; + case 'x': diff -Nru libproc-processtable-perl-0.59/debian/patches/series libproc-processtable-perl-0.59/debian/patches/series --- libproc-processtable-perl-0.59/debian/patches/series 1970-01-01 01:00:00.0 +0100 +++ libproc-processtable-perl-0.59/debian/patches/series 2019-07-06 17:00:06.0 +0200 @@ -0,0 +1,2 @@ +# Map GNU Hurd HALTED state to STOP +map-HALTED-to-STOP.patch diff -Nru libproc-processtable-perl-0.59/debian/rules libproc-processtable-perl-0.59/debian/rules --- libproc-processtable-perl-0.59/debian/rules 2019-07-06 17:00:06.0 +0200 +++ libproc-processtable-perl-0.59/debian/rules 2019-07-06 17:00:06.0 +0200 @@ -12,7 +12,7 @@ dh $@ override_dh_auto_configure: -ifeq ($(ARCH),kfreebsd) +ifneq ($(filter $(ARCH),kfreebsd hurd),) $(PERL) hints/linux.pl endif dh_auto_configure smime.p7s Description: S/MIME cryptographic signature
Bug#942671: Let $year support SOURCE_DATE_EPOCH
Package: doxygen Version: 1.8.13-11 Severity: normal Forwarded: https://github.com/doxygen/doxygen/pull/7341 Tags: patch If I use an html footer file that contains: Now is $datetime. This is $year. and run doxygen the generated index.html contains: Now is Sat Oct 19 2019 20:48:34. This is 2019. as expected. However, if I set the SOURCE_DATE_EPOCH when running doxygen SOURCE_DATE_EPOCH=$(date +%s -d '2018-07-01 1200Z') doxygen The generated index.html contains: Now is Sun Jul 1 2018 12:00:00. This is 2019. I.e the output of $datetime shows the SOURCE_DATE_EPOCH, but the $year shows the current year. This (a) is inconsistent and (b) makes the output non-reproducible. With the change $year supports SOURCE_DATE_EPOCH the same way $datetime does and the output is consistent: Now is Sun Jul 1 2018 12:00:00. This is 2018. Patch available in the upstream PR. Mattias signature.asc Description: This is a digitally signed message part
Bug#942386: RM: lcgdm -- ROM; package no longer maintained by upstream
Package: ftp.debian.org Severity: normal The lcgdm package is no longer maintained by upstream. The suggested replacement is dmlite developed by the same upstream. This is however not at this point package in Debian. https://gitlab.cern.ch/lcgdm/dmlite I would therefore like to requests its removal from the distribution. Mattias Ellert Maintainer of the package signature.asc Description: This is a digitally signed message part
Bug#942387: RM: nordugrid-arc-doc -- ROM; package no longer maintained by upstream
Package: ftp.debian.org Severity: normal After the release of ARC version 6, the developers of ARC have decided to no longer provide documentation in the form of an installable package but rely on the online documentation. The source for the nordugrid-arc-doc package is therefore no longer updated, and the information provided in it is out of date. I would therefore like to requests its removal from the distribution. Mattias Ellert Maintainer of the package signature.asc Description: This is a digitally signed message part
Bug#942385: RM: nordugrid-arc-gangliarc -- ROM; package no longer maintained by upstream
Package: ftp.debian.org Severity: normal The nordugrid-arc-gangliarc package is no longer maintained by upstream, and no port to Python 3 is planned. The functionality of the package has been replaced by ganglia support in AREX (nordugrid-arc-arex) with the release of ARC version 6. I would therefore like to requests its removal from the distribution. Mattias Ellert Maintainer of the package signature.asc Description: This is a digitally signed message part
Bug#930961: gsoap is wrongly marked Multi-Arch: foreign
sön 2019-06-23 klockan 17:47 +0200 skrev Helmut Grohne: > I see the following options to fix this: > > 1. Remove Multi-Arch: foreign. (<- This is bad. I hope obviously.) > 2. Drop the dependency from gsoap to libgsoap-dev. Thus gsoap no longer >exposes libgsoap-dev. Doing so makes a number of packages (including >voms) FTBFS until they add a dependency on libgsoap-dev. However this >is the approach chosen by flex (and libfl-dev) and bison (and >libbison-dev). This is doable and consistent with other packages. Of >course this is not reasonable before buster is out of the door. > 3. Flip the dependency. This one is tricky. We remove the dependency >from gsoap to libgsoap-dev. Then, we rename gsoap to gsoap-bin. Then >we rename libgsoap-dev to gsoap and add Provides: libgsoap-dev to the >new gsoap. The new gsoap also Depends: gsoap-bin. Effectively the >dependency is reversed. The entry point no longer is Multi-Arch: >foreign, but Multi-Arch: same instead. This approach is used by >qt5-qmake. > > gsoap has a total of 7 build-rdeps in main. That's a strict upper bound > to the number of FTBFS option 2 can introduce (i.e. few). Please tell me > which option you prefer. If you choose option 1, I'm sad. If you choose > 2, I can prepare and/or perform the filing of the FTBFS bugs. If you > choose 3, I can prepare a patch for gsoap. If you have no clue, don't > ask for help with better understanding the situation. > > Helmut Hi Helmut. Option 2 was implemented. All packages except for virtualbox either do not need changes or have been fixed. If you could file the bug for virtualbox I would appreciate it. gsoap: - Remove libgsoap-dev dependency from gsoap - Fixed in 2.8.75-2 cgsi-gsoap: - Build-Depends on libgsoap-dev, does not use gsoap - No change needed davix: - Add Build-Depends on libgsoap-dev - Fixed in 0.7.4-1 gridsite: - Add Build-Depends on libgsoap-dev - Fixed in 3.0.0~20180202git2fdbc6f-2 lcgdm: - Build-Depends on libcgsi-gsoap-dev, which Depends on libgsoap-dev - No change needed srm-ifce: - Build-Depends on libcgsi-gsoap-dev, which Depends on libgsoap-dev - No change needed voms: - Add Build-Depends on libgsoap-dev - Fixed in 2.1.0~rc0-6 virtualbox: - Add Build-Depends on libgsoap-dev - NOT DONE YET! Mattias smime.p7s Description: S/MIME cryptographic signature
Bug#931797: RM: globus-usage -- ROM; Usage statistics collection no longer used
Package: ftp.debian.org Severity: normal The globus-usage package is no longer in use. The packages that used to link to it (globus-gram-job-manager, globus-gridftp-server and myproxy) no longer use it. Mattias Ellert Maintainer of the package signature.asc Description: This is a digitally signed message part
Bug#912784: stretch-pu: package davix/0.6.4-1.1+deb9u1
mån 2019-07-08 klockan 12:04 +0200 skrev Julien Cristau: > On Mon, Jul 8, 2019 at 11:54:18 +0200, Mattias Ellert wrote: > > > > Sorry for not getting back to you again sooner. > > > > > > The bug fix sounds OK. What's the d/rules change about? It's not > > > mentioned in the changelog. > > > > > > + rm -rf debian/tmp/usr/share/doc/davix/html/.doctrees > > > > > > Regards, > > > > > > Adam > > > > Sorry for the delay. This is due to lintian. > > > > $ lintian-info -t package-contains-python-doctree-file > > W: package-contains-python-doctree-file > > N: > > N: This package appears to contain a pickled cache of > > reStructuredText > > N: (*.rst) documentation in a .doctree file. > > N: > > N: These are not needed to display the documentation correctly > > and as > > N: they can contain absolute build paths can affect the > > reproducibility > > N: of the package. > > N: > > N: Either prevent the installation of the .doctree file (or > > parent > > N: doctrees directory if there is one) or pass the -d option to > > N: sphinx-build(1) to create the caches elsewhere. > > > That doesn't sound needed nor indeed appropriate for a stable update. > > Cheers, > Julien Please elaborate. Should I interpret your comment as a rejection unless that line is removed, or was this an invitation for me to argue in favour of it. I can't see how removing some unwanted files from the documentation package could be inappropriate. Mattias smime.p7s Description: S/MIME cryptographic signature
Bug#912784: stretch-pu: package davix/0.6.4-1.1+deb9u1
lör 2019-04-20 klockan 11:27 +0100 skrev Adam D. Barratt: > On Tue, 2019-01-08 at 09:50 +0100, Mattias Ellert wrote: > > Davix implements (among other things) a client to a gridsite > > > service > > (a > > SOAP web service based file server protocol). It queries the server > > for > > what version it is running in order to know which credential > > delegation > > method to use. > > > > The old code used the "getVersion" call to get the version, which > > returns the software version of the server. However, there exists > > several different implementations of the server, so the version of > > the > > server software is not indicative on what credential delegation > > method > > it implements. > > > > What determines which delegation method to use is the interface > > version implemented by the server, not the version number of the > > server software. By using the getInterfaceVersion call instead the > > davix client will use the correct delegation method. > > > > https://its.cern.ch/jira/browse/DMC-1047 > > > > Sorry for not getting back to you again sooner. > > The bug fix sounds OK. What's the d/rules change about? It's not > mentioned in the changelog. > > + rm -rf debian/tmp/usr/share/doc/davix/html/.doctrees > > Regards, > > Adam Sorry for the delay. This is due to lintian. $ lintian-info -t package-contains-python-doctree-file W: package-contains-python-doctree-file N: N: This package appears to contain a pickled cache of reStructuredText N: (*.rst) documentation in a .doctree file. N: N: These are not needed to display the documentation correctly and as N: they can contain absolute build paths can affect the reproducibility N: of the package. N: N: Either prevent the installation of the .doctree file (or parent N: doctrees directory if there is one) or pass the -d option to N: sphinx-build(1) to create the caches elsewhere. Mattias smime.p7s Description: S/MIME cryptographic signature
Bug#922385: stretch-pu: package gsoap/2.8.35-4+deb9u2
fre 2019-02-15 klockan 13:06 + skrev Adam D. Barratt: > Control: tags -1 + moreinfo > > On 2019-02-15 10:12, Mattias Ellert wrote: > > This is a proposal to fix CVE-2019-7659 in stretch. > > > > The update also addresses one additional advisory published by the > > upstream developers. > > +-soap_encode_url(const char *s, char *t, size_t len) > ++soap_encode_url(const char *s, char *t, int len) > > If soap_encode_url is a public symbol, that's an ABI break - int and > size_t may well not be the same size, but they're definitely different > signedness. > > Regards, > > Adam Hi Adam. After you closed the corresponding request for jessie I sent the jessie update to debian-lts as suggested. This triggered the same discussion regarding this function being public. This is a quite long discussion - se the archive for details: https://lists.debian.org/debian-lts/2019/02/msg00131.html The outcome of the discussion was that using ssize_t instead of int in the patch was a better idea, and that version was accepted. I propose the same change for stretch. Updated debdiff attached. Mattias diff -Nru gsoap-2.8.35/debian/changelog gsoap-2.8.35/debian/changelog --- gsoap-2.8.35/debian/changelog 2017-08-16 11:58:11.0 +0200 +++ gsoap-2.8.35/debian/changelog 2019-02-14 17:12:12.0 +0100 @@ -1,3 +1,18 @@ +gsoap (2.8.35-4+deb9u2) stretch; urgency=medium + + * Fix for CVE-2019-7659 +Genivia gSOAP 2.7.x and 2.8.x before 2.8.75 allows attackers to cause a +denial of service (application abort) or possibly have unspecified other +impact if a server application is built with the -DWITH_COOKIES flag. This +affects the C/C++ libgsoapck/libgsoapck++ and libgsoapssl/libgsoapssl++ +libraries, as these are built with that flag. + * Fix issue with DIME protocol receiver and malformed DIME headers +This patch addresses a critical issue with the DIME protocol receiver that +may cause the receiver to become unresponsive when a malformed DIME +protocol message is received. -- https://www.genivia.com/advisory.html + + -- Mattias Ellert Thu, 14 Feb 2019 17:12:12 +0100 + gsoap (2.8.35-4+deb9u1) stretch; urgency=medium * Fix for CVE-2017-9765 diff -Nru gsoap-2.8.35/debian/patches/gsoap-CVE-2019-7659.patch gsoap-2.8.35/debian/patches/gsoap-CVE-2019-7659.patch --- gsoap-2.8.35/debian/patches/gsoap-CVE-2019-7659.patch 1970-01-01 01:00:00.0 +0100 +++ gsoap-2.8.35/debian/patches/gsoap-CVE-2019-7659.patch 2019-02-14 17:12:12.0 +0100 @@ -0,0 +1,50 @@ +diff -ur gsoap-2.8.35.orig/gsoap/stdsoap2.c gsoap-2.8.35/gsoap/stdsoap2.c +--- gsoap-2.8.35.orig/gsoap/stdsoap2.c 2016-09-18 10:56:10.0 +0200 gsoap-2.8.35/gsoap/stdsoap2.c 2019-02-13 17:21:44.18800 +0100 +@@ -7037,11 +7037,12 @@ + + #ifndef PALM_1 + SOAP_FMAC1 +-size_t ++ssize_t + SOAP_FMAC2 +-soap_encode_url(const char *s, char *t, size_t len) ++soap_encode_url(const char *s, char *t, ssize_t len) + { int c; +- size_t n = len; ++ ssize_t n = len; ++ if (n <= 0) return 0; + while ((c = *s++) && --n > 0) + { if (c > ' ' && c < 128 && !strchr("()<>@,;:\\\"/[]?={}#!$&'*+", c)) + *t++ = c; +diff -ur gsoap-2.8.35.orig/gsoap/stdsoap2.cpp gsoap-2.8.35/gsoap/stdsoap2.cpp +--- gsoap-2.8.35.orig/gsoap/stdsoap2.cpp 2016-09-18 10:56:10.0 +0200 gsoap-2.8.35/gsoap/stdsoap2.cpp 2019-02-13 17:21:44.18800 +0100 +@@ -7037,11 +7037,12 @@ + + #ifndef PALM_1 + SOAP_FMAC1 +-size_t ++ssize_t + SOAP_FMAC2 +-soap_encode_url(const char *s, char *t, size_t len) ++soap_encode_url(const char *s, char *t, ssize_t len) + { int c; +- size_t n = len; ++ ssize_t n = len; ++ if (n <= 0) return 0; + while ((c = *s++) && --n > 0) + { if (c > ' ' && c < 128 && !strchr("()<>@,;:\\\"/[]?={}#!$&'*+", c)) + *t++ = c; +diff -ur gsoap-2.8.35.orig/gsoap/stdsoap2.h gsoap-2.8.35/gsoap/stdsoap2.h +--- gsoap-2.8.35.orig/gsoap/stdsoap2.h 2016-09-18 10:56:10.0 +0200 gsoap-2.8.35/gsoap/stdsoap2.h 2019-02-13 17:19:31.08800 +0100 +@@ -3380,7 +3380,7 @@ + SOAP_FMAC1 const char* SOAP_FMAC2 soap_extend_url(struct soap *soap, const char*, const char*); + SOAP_FMAC1 const char* SOAP_FMAC2 soap_extend_url_query(struct soap *soap, const char*, const char*); + SOAP_FMAC1 void SOAP_FMAC2 soap_url_query(struct soap *soap, const char*, const char*); +-SOAP_FMAC1 size_t SOAP_FMAC2 soap_encode_url(const char*, char*, size_t); ++SOAP_FMAC1 ssize_t SOAP_FMAC2 soap_encode_url(const char*, char*, ssize_t); + SOAP_FMAC1 const char* SOAP_FMAC2 soap_encode_url_string(struct soap*, const char*); + #ifdef WITH_COOKIES + SOAP_FMAC1 void SOAP_FMAC2 soap_getcookies(struct soap *soap, const char *val); diff -Nru gsoap-2.8.35/debian/patches/gsoap-malformed-DIME.patch gsoap-2.8.35/deb
Bug#922385: stretch-pu: package gsoap/2.8.35-4+deb9u2
Package: release.debian.org Severity: normal Tags: stretch User: release.debian@packages.debian.org Usertags: pu This is a proposal to fix CVE-2019-7659 in stretch. The update also addresses one additional advisory published by the upstream developers. debdiff is attached. gsoap (2.8.35-4+deb9u2) stretch; urgency=medium * Fix for CVE-2019-7659 Genivia gSOAP 2.7.x and 2.8.x before 2.8.75 allows attackers to cause a denial of service (application abort) or possibly have unspecified other impact if a server application is built with the -DWITH_COOKIES flag. This affects the C/C++ libgsoapck/libgsoapck++ and libgsoapssl/libgsoapssl++ libraries, as these are built with that flag. * Fix issue with DIME protocol receiver and malformed DIME headers This patch addresses a critical issue with the DIME protocol receiver that may cause the receiver to become unresponsive when a malformed DIME protocol message is received. -- https://www.genivia.com/advisory.html Mattias Ellert diff -Nru gsoap-2.8.35/debian/changelog gsoap-2.8.35/debian/changelog --- gsoap-2.8.35/debian/changelog 2017-08-16 11:58:11.0 +0200 +++ gsoap-2.8.35/debian/changelog 2019-02-14 17:12:12.0 +0100 @@ -1,3 +1,18 @@ +gsoap (2.8.35-4+deb9u2) stretch; urgency=medium + + * Fix for CVE-2019-7659 +Genivia gSOAP 2.7.x and 2.8.x before 2.8.75 allows attackers to cause a +denial of service (application abort) or possibly have unspecified other +impact if a server application is built with the -DWITH_COOKIES flag. This +affects the C/C++ libgsoapck/libgsoapck++ and libgsoapssl/libgsoapssl++ +libraries, as these are built with that flag. + * Fix issue with DIME protocol receiver and malformed DIME headers +This patch addresses a critical issue with the DIME protocol receiver that +may cause the receiver to become unresponsive when a malformed DIME +protocol message is received. -- https://www.genivia.com/advisory.html + + -- Mattias Ellert Thu, 14 Feb 2019 17:12:12 +0100 + gsoap (2.8.35-4+deb9u1) stretch; urgency=medium * Fix for CVE-2017-9765 diff -Nru gsoap-2.8.35/debian/patches/gsoap-CVE-2019-7659.patch gsoap-2.8.35/debian/patches/gsoap-CVE-2019-7659.patch --- gsoap-2.8.35/debian/patches/gsoap-CVE-2019-7659.patch 1970-01-01 01:00:00.0 +0100 +++ gsoap-2.8.35/debian/patches/gsoap-CVE-2019-7659.patch 2019-02-14 17:12:12.0 +0100 @@ -0,0 +1,50 @@ +diff -ur gsoap-2.8.35.orig/gsoap/stdsoap2.c gsoap-2.8.35/gsoap/stdsoap2.c +--- gsoap-2.8.35.orig/gsoap/stdsoap2.c 2016-09-18 10:56:10.0 +0200 gsoap-2.8.35/gsoap/stdsoap2.c 2019-02-13 17:21:44.18800 +0100 +@@ -7037,11 +7037,12 @@ + + #ifndef PALM_1 + SOAP_FMAC1 +-size_t ++int + SOAP_FMAC2 +-soap_encode_url(const char *s, char *t, size_t len) ++soap_encode_url(const char *s, char *t, int len) + { int c; +- size_t n = len; ++ int n = len; ++ if (n <= 0) return 0; + while ((c = *s++) && --n > 0) + { if (c > ' ' && c < 128 && !strchr("()<>@,;:\\\"/[]?={}#!$&'*+", c)) + *t++ = c; +diff -ur gsoap-2.8.35.orig/gsoap/stdsoap2.cpp gsoap-2.8.35/gsoap/stdsoap2.cpp +--- gsoap-2.8.35.orig/gsoap/stdsoap2.cpp 2016-09-18 10:56:10.0 +0200 gsoap-2.8.35/gsoap/stdsoap2.cpp 2019-02-13 17:21:44.18800 +0100 +@@ -7037,11 +7037,12 @@ + + #ifndef PALM_1 + SOAP_FMAC1 +-size_t ++int + SOAP_FMAC2 +-soap_encode_url(const char *s, char *t, size_t len) ++soap_encode_url(const char *s, char *t, int len) + { int c; +- size_t n = len; ++ int n = len; ++ if (n <= 0) return 0; + while ((c = *s++) && --n > 0) + { if (c > ' ' && c < 128 && !strchr("()<>@,;:\\\"/[]?={}#!$&'*+", c)) + *t++ = c; +diff -ur gsoap-2.8.35.orig/gsoap/stdsoap2.h gsoap-2.8.35/gsoap/stdsoap2.h +--- gsoap-2.8.35.orig/gsoap/stdsoap2.h 2016-09-18 10:56:10.0 +0200 gsoap-2.8.35/gsoap/stdsoap2.h 2019-02-13 17:19:31.08800 +0100 +@@ -3380,7 +3380,7 @@ + SOAP_FMAC1 const char* SOAP_FMAC2 soap_extend_url(struct soap *soap, const char*, const char*); + SOAP_FMAC1 const char* SOAP_FMAC2 soap_extend_url_query(struct soap *soap, const char*, const char*); + SOAP_FMAC1 void SOAP_FMAC2 soap_url_query(struct soap *soap, const char*, const char*); +-SOAP_FMAC1 size_t SOAP_FMAC2 soap_encode_url(const char*, char*, size_t); ++SOAP_FMAC1 int SOAP_FMAC2 soap_encode_url(const char*, char*, int); + SOAP_FMAC1 const char* SOAP_FMAC2 soap_encode_url_string(struct soap*, const char*); + #ifdef WITH_COOKIES + SOAP_FMAC1 void SOAP_FMAC2 soap_getcookies(struct soap *soap, const char *val); diff -Nru gsoap-2.8.35/debian/patches/gsoap-malformed-DIME.patch gsoap-2.8.35/debian/patches/gsoap-malformed-DIME.patch --- gsoap-2.8.35/debian/patches/gsoap-malformed-DIME.patch 1970-01-01 01:00:00.0 +0100 +++ gsoap-2.8.35/debian/patches/gsoap-malformed-DIME.p
Bug#922384: jessie-pu: package gsoap/2.8.17-1+deb8u2
Package: release.debian.org Severity: normal Tags: jessie User: release.debian@packages.debian.org Usertags: pu This is a proposal to fix CVE-2019-7659 in jessie. The update also addresses one additional advisory published by the upstream developers. debdiff is attached. gsoap (2.8.17-1+deb8u2) jessie; urgency=medium * Fix for CVE-2019-7659 Genivia gSOAP 2.7.x and 2.8.x before 2.8.75 allows attackers to cause a denial of service (application abort) or possibly have unspecified other impact if a server application is built with the -DWITH_COOKIES flag. This affects the C/C++ libgsoapck/libgsoapck++ and libgsoapssl/libgsoapssl++ libraries, as these are built with that flag. * Fix issue with DIME protocol receiver and malformed DIME headers This patch addresses a critical issue with the DIME protocol receiver that may cause the receiver to become unresponsive when a malformed DIME protocol message is received. -- https://www.genivia.com/advisory.html Mattias Ellert diff -Nru gsoap-2.8.17/debian/changelog gsoap-2.8.17/debian/changelog --- gsoap-2.8.17/debian/changelog 2017-08-16 11:30:40.0 +0200 +++ gsoap-2.8.17/debian/changelog 2019-02-14 16:59:28.0 +0100 @@ -1,3 +1,18 @@ +gsoap (2.8.17-1+deb8u2) jessie; urgency=medium + + * Fix for CVE-2019-7659 +Genivia gSOAP 2.7.x and 2.8.x before 2.8.75 allows attackers to cause a +denial of service (application abort) or possibly have unspecified other +impact if a server application is built with the -DWITH_COOKIES flag. This +affects the C/C++ libgsoapck/libgsoapck++ and libgsoapssl/libgsoapssl++ +libraries, as these are built with that flag. + * Fix issue with DIME protocol receiver and malformed DIME headers +This patch addresses a critical issue with the DIME protocol receiver that +may cause the receiver to become unresponsive when a malformed DIME +protocol message is received. -- https://www.genivia.com/advisory.html + + -- Mattias Ellert Thu, 14 Feb 2019 16:59:28 +0100 + gsoap (2.8.17-1+deb8u1) jessie; urgency=medium * Fix for CVE-2017-9765 diff -Nru gsoap-2.8.17/debian/patches/gsoap-CVE-2019-7659.patch gsoap-2.8.17/debian/patches/gsoap-CVE-2019-7659.patch --- gsoap-2.8.17/debian/patches/gsoap-CVE-2019-7659.patch 1970-01-01 01:00:00.0 +0100 +++ gsoap-2.8.17/debian/patches/gsoap-CVE-2019-7659.patch 2019-02-14 11:32:59.0 +0100 @@ -0,0 +1,50 @@ +diff -ur gsoap-2.8.orig/gsoap/stdsoap2.c gsoap-2.8/gsoap/stdsoap2.c +--- gsoap-2.8.orig/gsoap/stdsoap2.c 2019-01-18 15:22:36.285318129 +0100 gsoap-2.8/gsoap/stdsoap2.c 2019-01-18 15:26:44.648630944 +0100 +@@ -6199,11 +6199,12 @@ + /**/ + #ifndef PALM_1 + SOAP_FMAC1 +-size_t ++int + SOAP_FMAC2 +-soap_encode_url(const char *s, char *t, size_t len) ++soap_encode_url(const char *s, char *t, int len) + { register int c; +- register size_t n = len; ++ register int n = len; ++ if (n <= 0) return 0; + while ((c = *s++) && --n > 0) + { if (c > ' ' && c < 128 && !strchr("()<>@,;:\\\"/[]?={}#!$&'*+", c)) + *t++ = c; +diff -ur gsoap-2.8.orig/gsoap/stdsoap2.cpp gsoap-2.8/gsoap/stdsoap2.cpp +--- gsoap-2.8.orig/gsoap/stdsoap2.cpp 2019-01-18 15:22:36.353317393 +0100 gsoap-2.8/gsoap/stdsoap2.cpp 2019-01-18 15:26:44.648630944 +0100 +@@ -6199,11 +6199,12 @@ + /**/ + #ifndef PALM_1 + SOAP_FMAC1 +-size_t ++int + SOAP_FMAC2 +-soap_encode_url(const char *s, char *t, size_t len) ++soap_encode_url(const char *s, char *t, int len) + { register int c; +- register size_t n = len; ++ register int n = len; ++ if (n <= 0) return 0; + while ((c = *s++) && --n > 0) + { if (c > ' ' && c < 128 && !strchr("()<>@,;:\\\"/[]?={}#!$&'*+", c)) + *t++ = c; +diff -ur gsoap-2.8.orig/gsoap/stdsoap2.h gsoap-2.8/gsoap/stdsoap2.h +--- gsoap-2.8.orig/gsoap/stdsoap2.h 2019-01-18 15:22:36.256318443 +0100 gsoap-2.8/gsoap/stdsoap2.h 2019-01-18 15:25:20.408542687 +0100 +@@ -2747,7 +2747,7 @@ + SOAP_FMAC1 void SOAP_FMAC2 soap_clr_attr(struct soap *soap); + + SOAP_FMAC1 const char* SOAP_FMAC2 soap_url(struct soap *soap, const char*, const char*); +-SOAP_FMAC1 size_t SOAP_FMAC2 soap_encode_url(const char*, char*, size_t); ++SOAP_FMAC1 int SOAP_FMAC2 soap_encode_url(const char*, char*, int); + SOAP_FMAC1 const char* SOAP_FMAC2 soap_encode_url_string(struct soap*, const char*); + #ifdef WITH_COOKIES + SOAP_FMAC1 void SOAP_FMAC2 soap_getcookies(struct soap *soap, const char *val); diff -Nru gsoap-2.8.17/debian/patches/gsoap-malformed-DIME.patch gsoap-2.8.17/debian/patches/gsoap-malformed-DIME.patch --- gsoap-2.8.17/debian/patches/gsoap-malformed-DIME.patch 1970-01-01 01:00:00.0 +0100 +++ gsoap-2.8.17/
Bug#917726: globus-gass-copy: FTBFS: tests failed
mån 2019-01-07 klockan 09:20 +0100 skrev Lucas Nussbaum: > Hi, > > On 07/01/19 at 08:28 +0100, Mattias Ellert wrote: > > Hi! > > > > The globus-gass-copy package and dependent packaged have now been > > tagged for autoremoval due to this RC bug. So I need to resolve this > > with some urgency. > > > > Since I did not receive any reply to my previous comment I need to > > resolve this without the additional feedback I requested. > > > > I will close this as "not a bug" since I believe the failure to be due > > to a misconfiguration of the rebuild test build server, and not a real > > bug (see the above mentioned comment for details). > > > > If this is not satisfactory, please feel welcome to reopen the bug and > > provide additional information about why you believe the bug report is > > valid. > > > > Mattias > > Well, I'm not sure about this bug. > > It seems that it fails to build with '!' in /etc/shadow, with '*' in > /etc/shadow, and even with a password in /etc/shadow. I don't know if > sbuild is doing something strange, but it doesn't look like it. > > Also, this is (AFAIK) the only package failing because of this. > > Lucas Checking the code of the server binary used during the test, what is checked by the server to ensure logins are not enabled is: 1. That a shell is defined for the user and that this shell exists 2. That the defined shell is a regular file 3. That the defined shell has executable permissions. Mattias signature.asc Description: This is a digitally signed message part
Bug#912784: stretch-pu: package davix/0.6.4-1.1+deb9u1
mån 2018-12-03 klockan 08:17 +0100 skrev Julien Cristau: > Control: tag -1 moreinfo > > On Sat, Nov 03, 2018 at 10:31:32PM +0100, Mattias Ellert wrote: > > Package: release.debian.org > > Severity: normal > > Tags: stretch > > User: release.debian@packages.debian.org > > Usertags: pu > > > > This is a proposed update to the davix package in Debian 9 (stretch). I > > have created it in response to a request that was sent to me via e-mail > > (included below). > > > > The proposed update backports the specific bugfix mentioned in the > > request rather than updating to a newer version. This bugfix was part > > of the 0.6.8 update. The version in unstable and testing is currently > > 0.7.1. > > > Can you describe the effect of this bug? > > Cheers, > Julien Davix implements (among other things) a client to a gridsite service (a SOAP web service based file server protocol). It queries the server for what version it is running in order to know which credential delegation method to use. The old code used the "getVersion" call to get the version, which returns the software version of the server. However, there exists several different implementations of the server, so the version of the server software is not indicative on what credential delegation method it implements. What determines which delegation method to use is the interface version implemented by the server, not the version number of the server software. By using the getInterfaceVersion call instead the davix client will use the correct delegation method. https://its.cern.ch/jira/browse/DMC-1047 Mattias smime.p7s Description: S/MIME cryptographic signature
Bug#917726: globus-gass-copy: FTBFS: tests failed
Hi Lucas. I have a question regarding your report. Is it really a requirement that the package build should succeed even if the user account doing the package build is disabled for logins? Not accepting remote logins during the build is very reasonable. But a test that starts a server on the build machine to accept logins from test scripts running on the same build machine should be allowed. This has not been a problem before. These tests work fine when building using pbuilder locally, and there has never been a problem when running the tests during the builds on the buildd servers either in the past. Is this a misconfiguration of the FTBFS test build server, or is it really intended to block logins from localhost to localhost during the build? It is not impossible to fix this. The server binary that is used during the test has an -allow-disabled-logins flag already, so I can add that to the test wrapper script. But I just wanted to check that this restriction was really intended before I do this. Mattias lör 2018-12-29 klockan 23:26 +0100 skrev Lucas Nussbaum: > Source: globus-gass-copy > Version: 10.3-2 > Severity: serious > Justification: FTBFS on amd64 > Tags: buster sid > Usertags: ftbfs-20181229 ftbfs-buster > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > # > > # error: globus_ftp_client: the server responded with an error > > # 530 Login incorrect. : Access denied, user's system account is disabled. > > The full build log is available from: >http://aws-logs.debian.net/2018/12/29/globus-gass-copy_10.3-2_unstable.log > > A list of current common problems and possible solutions is available at > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! > > About the archive rebuild: The rebuild was done on EC2 VM instances from > Amazon Web Services, using a clean, minimal and up-to-date chroot. Every > failed build was retried once to eliminate random failures. smime.p7s Description: S/MIME cryptographic signature
Bug#912784: stretch-pu: package davix/0.6.4-1.1+deb9u1
Package: release.debian.org Severity: normal Tags: stretch User: release.debian@packages.debian.org Usertags: pu This is a proposed update to the davix package in Debian 9 (stretch). I have created it in response to a request that was sent to me via e-mail (included below). The proposed update backports the specific bugfix mentioned in the request rather than updating to a newer version. This bugfix was part of the 0.6.8 update. The version in unstable and testing is currently 0.7.1. Mattias Vidarebefordrat meddelande Från: Paul Millar Till: mattias.ell...@physics.uu.se Ämne: davix version in Debian stretch Datum: Tue, 16 Oct 2018 15:06:11 +0200 Hi Mattias, I was wondering whether it was possible to get the davix version currently in buster (0.6.8) into stretch? davix v0.6.8 contains this fix: https://its.cern.ch/jira/browse/DMC-1047 which is pretty important for us. Of course, if you got the latest version (v0.6.9) into stretch, buster and sid, that would be even better. That version has further fixes that would be helpful. Cheers, Paul. diff -Nru davix-0.6.4/debian/changelog davix-0.6.4/debian/changelog --- davix-0.6.4/debian/changelog 2016-12-15 21:40:12.0 +0100 +++ davix-0.6.4/debian/changelog 2018-11-03 18:37:23.0 +0100 @@ -1,3 +1,10 @@ +davix (0.6.4-1.1+deb9u1) stretch; urgency=medium + + * Use getInterfaceVersion to retrieve the delegation version implemented + * https://its.cern.ch/jira/browse/DMC-1047 + + -- Mattias Ellert Sat, 03 Nov 2018 18:37:23 +0100 + davix (0.6.4-1.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru davix-0.6.4/debian/patches/0001-DMC-1047-use-getInterfaceVersion-to-retrieve-the-del.patch davix-0.6.4/debian/patches/0001-DMC-1047-use-getInterfaceVersion-to-retrieve-the-del.patch --- davix-0.6.4/debian/patches/0001-DMC-1047-use-getInterfaceVersion-to-retrieve-the-del.patch 1970-01-01 01:00:00.0 +0100 +++ davix-0.6.4/debian/patches/0001-DMC-1047-use-getInterfaceVersion-to-retrieve-the-del.patch 2018-11-03 15:38:46.0 +0100 @@ -0,0 +1,33 @@ +From 436bb62eb7df614e3c68bdcbb60c56b406feb8f8 Mon Sep 17 00:00:00 2001 +From: Andrea Manzi +Date: Mon, 28 May 2018 16:13:29 +0200 +Subject: [PATCH] DMC-1047: use getInterfaceVersion to retrieve the delegation + version implemented + +--- + src/modules/copy/delegation/delegation.cpp | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +diff --git a/src/modules/copy/delegation/delegation.cpp b/src/modules/copy/delegation/delegation.cpp +index 203268d..55f242b 100644 +--- a/src/modules/copy/delegation/delegation.cpp b/src/modules/copy/delegation/delegation.cpp +@@ -204,12 +204,12 @@ static int get_delegation_version(const std::string& ucred, const std::string& p + + if (soap_ssl_client_context(soap_v, SOAP_SSL_DEFAULT, ucred.c_str(), passwd.c_str(), + ucred.c_str(), capath.c_str(), NULL) == 0) { +-delegation2::tns2__getVersionResponse response; +-delegation2::soap_call_tns2__getVersion(soap_v, dlg_endpoint.c_str(), ++delegation2::tns2__getInterfaceVersionResponse response; ++delegation2::soap_call_tns2__getInterfaceVersion(soap_v, dlg_endpoint.c_str(), + "http://www.gridsite.org/namespaces/delegation-2";, response); + + if (soap_v->error == 0) { +-version = atoi(response.getVersionReturn); ++version = atoi(response.getInterfaceVersionReturn); + } + else { + // Assume version 1 (does not implement the version method) +-- +2.19.1 + diff -Nru davix-0.6.4/debian/patches/series davix-0.6.4/debian/patches/series --- davix-0.6.4/debian/patches/series 2016-12-15 21:36:45.0 +0100 +++ davix-0.6.4/debian/patches/series 2018-11-03 18:35:30.0 +0100 @@ -1,3 +1,10 @@ davix-linking.patch + +# Add support for openssl-1.1.0 +# https://its.cern.ch/jira/browse/DMC-888 0001-DMC-888-16-Add-support-for-openssl-1.1.0.patch 0002-DMC-888-16-Fix-SL5-build.patch + +# Use getInterfaceVersion to retrieve the delegation version implemented +# https://its.cern.ch/jira/browse/DMC-1047 +0001-DMC-1047-use-getInterfaceVersion-to-retrieve-the-del.patch diff -Nru davix-0.6.4/debian/rules davix-0.6.4/debian/rules --- davix-0.6.4/debian/rules 2016-12-15 21:40:12.0 +0100 +++ davix-0.6.4/debian/rules 2018-11-03 18:37:23.0 +0100 @@ -32,6 +32,7 @@ override_dh_install: rm debian/tmp/usr/share/doc/davix/LICENSE rm -rf debian/tmp/usr/include/gtest debian/tmp/usr/lib/libgtest.a debian/tmp/usr/lib/libgtest_main.a + rm -rf debian/tmp/usr/share/doc/davix/html/.doctrees dh_install --fail-missing override_dh_strip: signature.asc Description: This is a digitally signed message part
Bug#911248: globus-gass-copy-progs: copy fails with some SSL errors
lör 2018-11-03 klockan 02:10 +0100 skrev Christoph Anton Mitterer: > Hey Mattias. > > Thanks :-) > > Since you're also the voms-client maintainer, couldn't you perhaps > modify that already so that it defaults to 2048 (or yet better 4096)? > > Cheers, > Chris. This was already done. If you look at this bug in BTS you see that it now reads: Found in versions voms-clients/2.1.0~rc0-4, voms-clients-java/3.3.0-1 Fixed in versions voms-clients-java/3.3.0-2, voms-clients/2.1.0~rc0-5 For reference here are the corresponding upstream PRs: https://github.com/italiangrid/voms/pull/75 https://github.com/italiangrid/voms-clients/pull/20 Mattias smime.p7s Description: S/MIME cryptographic signature
Bug#908893: stretch-pu: package globus-gsi-credential_7.11-1+deb9u1
Package: release.debian.org Severity: normal Tags: stretch User: release.debian@packages.debian.org Usertags: pu This is a proposed update to the globus-gsi-credential package in Debian 9 (stretch). I have created it in response to a request that was sent to me via e-mail (included below). Mattias Vidarebefordrat meddelande Från: Dave Dykstra Till: Mattias Ellert Ämne: libglobus-gsi-credential1 fix for stretch Datum: Fri, 14 Sep 2018 15:56:24 -0500 Hi Mattias, There's been a fix https://github.com/globus/globus-toolkit/issues/115 affecting cvmfs-x509-helper in Debian testing libglobus-gsi-credential1 version 7.14-1 since last November, but it still hasn't made it into Debian 9 stretch or stretch-updates. Could you backport it there? Meanwhile I have been maintaining a patched copy in the cvmfs-contrib repository (https://cvmfs-contrib.github.io). Dave diff -Nru globus-gsi-credential-7.11/debian/changelog globus-gsi-credential-7.11/debian/changelog --- globus-gsi-credential-7.11/debian/changelog 2016-11-08 23:25:05.0 +0100 +++ globus-gsi-credential-7.11/debian/changelog 2018-09-15 16:15:42.0 +0200 @@ -1,3 +1,11 @@ +globus-gsi-credential (7.11-1+deb9u1) stretch; urgency=medium + + * Fix issue with voms proxy and openssl 1.1 + * https://github.com/globus/globus-toolkit/issues/115 + * https://github.com/globus/globus-toolkit/pull/116 + + -- Mattias Ellert Sat, 15 Sep 2018 16:15:42 +0200 + globus-gsi-credential (7.11-1) unstable; urgency=medium * GT6 update diff -Nru globus-gsi-credential-7.11/debian/patches/globus-gsi-credential-voms-openssl-1.1.patch globus-gsi-credential-7.11/debian/patches/globus-gsi-credential-voms-openssl-1.1.patch --- globus-gsi-credential-7.11/debian/patches/globus-gsi-credential-voms-openssl-1.1.patch 1970-01-01 01:00:00.0 +0100 +++ globus-gsi-credential-7.11/debian/patches/globus-gsi-credential-voms-openssl-1.1.patch 2018-09-15 16:09:00.0 +0200 @@ -0,0 +1,70 @@ +From 924cb64dda4dae571456772bd1db62d5bbe25ccf Mon Sep 17 00:00:00 2001 +From: Mischa Salle +Date: Mon, 23 Oct 2017 20:16:26 +0200 +Subject: [PATCH] Simple patch for GT issue #115 + +This patch reorders the the setting of the check_issued and the initialization +of the X509_STORE_CTX object with the X509_STORE thereby solving +https://github.com/globus/globus-toolkit/issues/115 +--- + .../source/library/globus_gsi_cred_handle.c | 28 +-- + 1 file changed, 14 insertions(+), 14 deletions(-) + +diff --git a/library/globus_gsi_cred_handle.c b/library/globus_gsi_cred_handle.c +index 9877ad603d..e890f56abf 100644 +--- a/library/globus_gsi_cred_handle.c b/library/globus_gsi_cred_handle.c +@@ -1745,19 +1745,19 @@ globus_gsi_cred_verify_cert_chain( + + if (X509_STORE_load_locations(cert_store, NULL, cert_dir)) + { ++#if OPENSSL_VERSION_NUMBER < 0x1010L ++/* override the check_issued with our version */ ++cert_store->check_issued = globus_gsi_callback_check_issued; ++#else ++X509_STORE_set_check_issued(cert_store, globus_gsi_callback_check_issued); ++#endif ++ + store_context = X509_STORE_CTX_new(); + X509_STORE_CTX_init(store_context, cert_store, cert, + cred_handle->cert_chain); + X509_STORE_CTX_set_depth(store_context, + GLOBUS_GSI_CALLBACK_VERIFY_DEPTH); + +-#if OPENSSL_VERSION_NUMBER < 0x1010L +-/* override the check_issued with our version */ +-store_context->check_issued = globus_gsi_callback_check_issued; +-#else +-X509_STORE_set_check_issued(X509_STORE_CTX_get0_store(store_context), globus_gsi_callback_check_issued); +-#endif +- + globus_gsi_callback_get_X509_STORE_callback_data_index( + &callback_data_index); + +@@ -1937,19 +1937,19 @@ globus_gsi_cred_verify_cert_chain_when( + + if (X509_STORE_load_locations(cert_store, NULL, cert_dir)) + { ++/* override the check_issued with our version */ ++#if OPENSSL_VERSION_NUMBER < 0x1010L ++cert_store->check_issued = globus_gsi_callback_check_issued; ++#else ++X509_STORE_set_check_issued(cert_store, globus_gsi_callback_check_issued); ++#endif ++ + store_context = X509_STORE_CTX_new(); + X509_STORE_CTX_init(store_context, cert_store, cert, + cred_handle->cert_chain); + X509_STORE_CTX_set_depth(store_context, + GLOBUS_GSI_CALLBACK_VERIFY_DEPTH); + +-/* override the check_issued with our version */ +-#if OPENSSL_VERSION_NUMBER < 0x1010L +-store_context->check_issued = globus_gsi_callback_check_issued; +-#else +-X509_STORE_set_check_issued(X509_STORE_CTX_get0_store(store_context), globus_gsi_callback_check_issued); +-#endif +- + globus_gsi_callback_get_X509_STORE_callback_data_index( + &a
Bug#908090: VCS check reports bogus error
package: qa.debian.org The VCS check page for globus-gram-job-manager-sge has reported a problem for months now without a problem existimg: https://qa.debian.org/cgi-bin/vcswatch?package=globus-gram-job-manager-sge Please fix the broken svn checkout on your test machine. Consider implementing some autodetection of issues like this so that problems on the test server are not reported as problems with a package's VCS repository. Mattias signature.asc Description: This is a digitally signed message part
Bug#907586: g++ compiler problem on hppa
Package: g++-8 Version: 8.2.0-4 Severity: important One of the packages I maintain have been failing in its test suite on hppa ever since it was first uploaded. I was never able to investigate the reason for this because there until recently were no hppa porter box. I recently discovered that there is now an hppa porter box and I have been able to reproduce the issue. I managed to take the failing part of the code and reduce it to a small test case that is attached to this bug report. The issue only happens on hppa, and only when linking using a shared library. If the test case is linked statically the issue does not appear. On all architectures except hppa the output of the test case is the following: $ make g++ -O2 -g -c -o main.o main.cpp g++ -O2 -g -fPIC -c -o S.o S.cpp g++ -shared -o libS.so S.o g++ -o main main.o -L. -lS g++ -o altmain main.o S.o -- Running using shared library LD_LIBRARY_PATH=. ./main OK -- Running using static build ./altmain OK On hppa the output is as follows: $ make g++ -O2 -g -c -o main.o main.cpp g++ -O2 -g -fPIC -c -o S.o S.cpp g++ -shared -o libS.so S.o g++ -o main main.o -L. -lS g++ -o altmain main.o S.o -- Running using shared library LD_LIBRARY_PATH=. ./main not OK -- Running using static build ./altmain OK Mattias test.tar.gz Description: application/compressed-tar smime.p7s Description: S/MIME cryptographic signature
Bug#907474: Insufficient Build-Depends libglib2.0-dev (>= 2.50.0), should be (>= 2.56.0)
Source: libglibmm2.4 Version: 2.56.0-2 Severity: important The builds of glibmm2.4 2.56.0-2 on kfreebsd-amd64 and kfreebsd-i386 failed with: error: 'g_application_set_option_context_parameter_string' was not declared in this scope According to https://developer.gnome.org/gio/stable/GApplication.html#g-application-set-option-context-parameter-string g_application_set_option_context_parameter_string is available since glib2.0 vesrion 2.56. However, the glibmm2.4 2.56.0-2 on kfreebsd-amd64 and kfreebsd-i386 were attempted using glib2.0 version 2.54: Selecting previously unselected package libglib2.0-dev:kfreebsd-amd64. Preparing to unpack .../90-libglib2.0-dev_2.54.2-1_kfreebsd-amd64.deb ... Unpacking libglib2.0-dev:kfreebsd-amd64 (2.54.2-1) ... The Build-Depends in the glibmm2.4 source package states libglib2.0-dev (>= 2.50.0), which is insufficient and should be changed to libglib2.0-dev (>= 2.56.0) to make sure that g_application_set_option_context_parameter_string is available. Mattias smime.p7s Description: S/MIME cryptographic signature
Bug#889648: Typo in glibmm/threads.h causes FTBFS with gcc 8.
Package: libglibmm-2.4-dev Version: 2.54.1-3 Severity: normal There is a typo in the glibmm/threads.h header file, a missing & in the GPrivate::gobj() method. It has so far not caused that many issues, but if gcc-8 is used for compiling the typo starts generating FTBFS errors for software including the header, also if the GPrivate::gobj() is not used. The bug is fixed upstream in the 2.54 branch: https://github.com/GNOME/glibmm/commit/37d57ae Patch attached (this is the patch used in Fedora). Mattias From 37d57ae9572b7d74aa385a30313eceae7f2d3fce Mon Sep 17 00:00:00 2001 From: Kjell Ahlstedt Date: Wed, 20 Dec 2017 20:00:32 +0100 Subject: [PATCH] Glib::Threads::Private: Fix gobj() Bug 791711 --- glib/src/threads.hg | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/glib/src/threads.hg b/glib/src/threads.hg index 86d7a17b62f4..c82a6130bbeb 100644 --- a/glib/src/threads.hg +++ b/glib/src/threads.hg @@ -628,7 +628,7 @@ public: */ inline void replace(T* data); - GPrivate* gobj() { return gobject_; } + GPrivate* gobj() { return &gobject_; } private: GPrivate gobject_; -- 2.14.3 diff -urN glibmm-2.54.1-old/glib/glibmm/threads.h glibmm-2.54.1/glib/glibmm/threads.h --- glibmm-2.54.1-old/glib/glibmm/threads.h 2018-02-02 16:44:05.0 +0100 +++ glibmm-2.54.1/glib/glibmm/threads.h 2018-02-02 16:47:04.0 +0100 @@ -657,7 +657,7 @@ */ inline void replace(T* data); - GPrivate* gobj() { return gobject_; } + GPrivate* gobj() { return &gobject_; } private: GPrivate gobject_; smime.p7s Description: S/MIME cryptographic signature
Bug#872442: jessie-pu: package gsoap/2.8.17-1+deb8u1
fre 2017-08-18 klockan 13:47 +0200 skrev Mattias Ellert: > > > No. You want to open a bug report against your own package, telling > > there is a security bug. and you want to refer that on in the closes > > statement. > > > > This contradicts what Adam said in bug #872441: > > > If there is no bug filed against gsoap that relates to the issue, then > > there should be no bug closed in the changelog. > > Can you resolve your differences? > > Mattias Hi again. Is there a resolution to this? Is a Closes statement mandatory or not? Mattias signature.asc Description: This is a digitally signed message part
Bug#872442: jessie-pu: package gsoap/2.8.17-1+deb8u1
fre 2017-08-18 klockan 13:08 +0200 skrev Martin Zobel-Helas: > Hi, > > On Fri Aug 18, 2017 at 11:35:21 +0200, Mattias Ellert wrote: > > tor 2017-08-17 klockan 20:21 +0200 skrev Martin Zobel-Helas: > > > Hi, > > > > > > On Thu Aug 17, 2017 at 16:38:30 +0200, Mattias Ellert wrote: > > > > Package: release.debian.org > > > > Severity: normal > > > > Tags: jessie > > > > User: release.debian@packages.debian.org > > > > Usertags: pu > > > > > > > > This is a proposal to fix CVE-2017-9765 in jessie. > > > > debdiff is attached. > > > > > > > > Mattias Ellert > > > > diff -Nru gsoap-2.8.17/debian/changelog gsoap-2.8.17/debian/changelog > > > > --- gsoap-2.8.17/debian/changelog 2014-07-11 13:45:59.0 > > > > +0200 > > > > +++ gsoap-2.8.17/debian/changelog 2017-08-16 11:30:40.0 > > > > +0200 > > > > @@ -1,3 +1,9 @@ > > > > +gsoap (2.8.17-1+deb8u1) jessie; urgency=medium > > > > + > > > > + * Fix for CVE-2017-9765 (Closes: ) > > > > + > > > > + -- Mattias Ellert Wed, 16 Aug 2017 > > > > 11:30:40 +0200 > > > > + > > > > gsoap (2.8.17-1) unstable; urgency=medium > > > > > > once this changelog has a proper Closes line with bug-number this patch > > > looks sane to me. > > > > > > Cheers, > > > Martin > > > (former stable release manager) > > > > > > > Closes statement removed as requested. > > See bug #872441 for the discussion. > > No. You want to open a bug report against your own package, telling > there is a security bug. and you want to refer that on in the closes > statement. > This contradicts what Adam said in bug #872441: > If there is no bug filed against gsoap that relates to the issue, then > there should be no bug closed in the changelog. Can you resolve your differences? Mattias signature.asc Description: This is a digitally signed message part
Bug#872442: jessie-pu: package gsoap/2.8.17-1+deb8u1
tor 2017-08-17 klockan 20:21 +0200 skrev Martin Zobel-Helas: > Hi, > > On Thu Aug 17, 2017 at 16:38:30 +0200, Mattias Ellert wrote: > > Package: release.debian.org > > Severity: normal > > Tags: jessie > > User: release.debian@packages.debian.org > > Usertags: pu > > > > This is a proposal to fix CVE-2017-9765 in jessie. > > debdiff is attached. > > > > Mattias Ellert > > diff -Nru gsoap-2.8.17/debian/changelog gsoap-2.8.17/debian/changelog > > --- gsoap-2.8.17/debian/changelog 2014-07-11 13:45:59.0 +0200 > > +++ gsoap-2.8.17/debian/changelog 2017-08-16 11:30:40.0 +0200 > > @@ -1,3 +1,9 @@ > > +gsoap (2.8.17-1+deb8u1) jessie; urgency=medium > > + > > + * Fix for CVE-2017-9765 (Closes: ) > > + > > + -- Mattias Ellert Wed, 16 Aug 2017 > > 11:30:40 +0200 > > + > > gsoap (2.8.17-1) unstable; urgency=medium > > once this changelog has a proper Closes line with bug-number this patch > looks sane to me. > > Cheers, > Martin > (former stable release manager) > Closes statement removed as requested. See bug #872441 for the discussion. Mattias diff -Nru gsoap-2.8.17/debian/changelog gsoap-2.8.17/debian/changelog --- gsoap-2.8.17/debian/changelog 2014-07-11 13:45:59.0 +0200 +++ gsoap-2.8.17/debian/changelog 2017-08-16 11:30:40.0 +0200 @@ -1,3 +1,9 @@ +gsoap (2.8.17-1+deb8u1) jessie; urgency=medium + + * Fix for CVE-2017-9765 + + -- Mattias Ellert Wed, 16 Aug 2017 11:30:40 +0200 + gsoap (2.8.17-1) unstable; urgency=medium * New upstream release diff -Nru gsoap-2.8.17/debian/patches/gsoap-CVE-2017-9765.patch gsoap-2.8.17/debian/patches/gsoap-CVE-2017-9765.patch --- gsoap-2.8.17/debian/patches/gsoap-CVE-2017-9765.patch 1970-01-01 01:00:00.0 +0100 +++ gsoap-2.8.17/debian/patches/gsoap-CVE-2017-9765.patch 2017-08-16 09:29:32.0 +0200 @@ -0,0 +1,54 @@ +diff -ur gsoap-2.7.orig/gsoap/stdsoap2.c gsoap-2.7/gsoap/stdsoap2.c +--- gsoap-2.7.orig/gsoap/stdsoap2.c 2010-04-06 18:23:14.0 +0200 gsoap-2.7/gsoap/stdsoap2.c 2017-08-01 15:05:03.634309308 +0200 +@@ -1509,17 +1509,16 @@ + soap_get_pi(struct soap *soap) + { char buf[64]; + register char *s = buf; +- register int i = sizeof(buf); +- register soap_wchar c = soap_getchar(soap); +- /* This is a quick way to parse XML PI and we could use a callback instead to +- * enable applications to intercept processing instructions */ +- while ((int)c != EOF && c != '?') +- { if (--i > 0) ++ register size_t i = sizeof(buf); ++ register soap_wchar c; ++ /* Parse the XML PI encoding declaration and look for */ ++ while ((int)(c = soap_getchar(soap)) != EOF && c != '?') ++ { if (i > 1) + { if (soap_blank(c)) + c = ' '; + *s++ = (char)c; ++ i--; + } +-c = soap_getchar(soap); + } + *s = '\0'; + DBGLOG(TEST, SOAP_MESSAGE(fdebug, "XML PI \n", buf)); +diff -ur gsoap-2.7.orig/gsoap/stdsoap2.cpp gsoap-2.7/gsoap/stdsoap2.cpp +--- gsoap-2.7.orig/gsoap/stdsoap2.cpp 2010-04-06 18:23:14.0 +0200 gsoap-2.7/gsoap/stdsoap2.cpp 2017-08-01 15:05:03.636309306 +0200 +@@ -1509,17 +1509,16 @@ + soap_get_pi(struct soap *soap) + { char buf[64]; + register char *s = buf; +- register int i = sizeof(buf); +- register soap_wchar c = soap_getchar(soap); +- /* This is a quick way to parse XML PI and we could use a callback instead to +- * enable applications to intercept processing instructions */ +- while ((int)c != EOF && c != '?') +- { if (--i > 0) ++ register size_t i = sizeof(buf); ++ register soap_wchar c; ++ /* Parse the XML PI encoding declaration and look for */ ++ while ((int)(c = soap_getchar(soap)) != EOF && c != '?') ++ { if (i > 1) + { if (soap_blank(c)) + c = ' '; + *s++ = (char)c; ++ i--; + } +-c = soap_getchar(soap); + } + *s = '\0'; + DBGLOG(TEST, SOAP_MESSAGE(fdebug, "XML PI \n", buf)); diff -Nru gsoap-2.8.17/debian/patches/series gsoap-2.8.17/debian/patches/series --- gsoap-2.8.17/debian/patches/series 2014-07-11 20:36:40.0 +0200 +++ gsoap-2.8.17/debian/patches/series 2017-08-16 11:28:38.0 +0200 @@ -21,3 +21,6 @@ # https://sourceforge.net/p/gsoap2/patches/119/ gsoap-doxygen-paths.patch + +# CVE-2017-9765 +gsoap-CVE-2017-9765.patch signature.asc Description: This is a digitally signed message part
Bug#872441: stretch-pu: package gsoap/2.8.35-4+deb9u1
fre 2017-08-18 klockan 08:46 +0100 skrev Adam D. Barratt: > On 2017-08-18 8:01, Mattias Ellert wrote: > > tor 2017-08-17 klockan 21:59 +0100 skrev Adam D. Barratt: > > > On Thu, 2017-08-17 at 20:22 +0200, Martin Zobel-Helas wrote: > > > > Hi, > > > > > > > > On Thu Aug 17, 2017 at 16:38:36 +0200, Mattias Ellert wrote: > > > > > > [...] > > > > > +gsoap (2.8.35-4+deb9u1) stretch; urgency=medium > > > > > + > > > > > + * Fix for CVE-2017-9765 (Closes: ) > > [...] > > > Is there actually a Debian bug for the issue? I couldn't find one. > > [...] > > I don't understand the last comment here. > > Apparently not. > > > Of course there is a bug - it is this one. > > > > The reason the debdiff in the request says "Closes: ", is a > > chicken-and-egg problem. You are supposed to attach the debdiff to the > > request, but before you make the request its BTS number does not yet > > exists - so you can't include it in the attachment at creation time. > > After I got the confirmation back with the number I updated the > > changelog with the bug number. > > *NO*. There is no chicken and egg problem here at all. > > The bug number you would close in the changelog relates to a bug filed > _against gsoap_, the same as it would for any other upload. You should > never be closing bugs filed against release.debian.org in an upload of > your package. You're fixing a bug in your package, the release.d.o bug > is a means of tracking that, not a thing fixed in the upload. > > If there is no bug filed against gsoap that relates to the issue, then > there should be no bug closed in the changelog. > > Regards, > > Adam Closes statement removed as requested. I am sorry to have upset you, but to me it was obvious the bug should be closed by the update, and the instruction did not say it should not be. Maybe you could add a sentence stating this in the instructions. Mattias diff -Nru gsoap-2.8.35/debian/changelog gsoap-2.8.35/debian/changelog --- gsoap-2.8.35/debian/changelog 2016-12-06 09:32:36.0 +0100 +++ gsoap-2.8.35/debian/changelog 2017-08-16 11:58:11.0 +0200 @@ -1,3 +1,9 @@ +gsoap (2.8.35-4+deb9u1) stretch; urgency=medium + + * Fix for CVE-2017-9765 + + -- Mattias Ellert Wed, 16 Aug 2017 11:58:11 +0200 + gsoap (2.8.35-4) unstable; urgency=medium * Rebuild for OpenSSL 1.1.0 diff -Nru gsoap-2.8.35/debian/patches/gsoap-CVE-2017-9765.patch gsoap-2.8.35/debian/patches/gsoap-CVE-2017-9765.patch --- gsoap-2.8.35/debian/patches/gsoap-CVE-2017-9765.patch 1970-01-01 01:00:00.0 +0100 +++ gsoap-2.8.35/debian/patches/gsoap-CVE-2017-9765.patch 2017-08-16 11:54:02.0 +0200 @@ -0,0 +1,54 @@ +diff -ur gsoap-2.8.orig/gsoap/stdsoap2.c gsoap-2.8/gsoap/stdsoap2.c +--- gsoap-2.8.orig/gsoap/stdsoap2.c 2016-04-03 03:33:31.0 +0200 gsoap-2.8/gsoap/stdsoap2.c 2017-08-01 14:51:44.141083499 +0200 +@@ -1711,17 +1711,16 @@ + soap_get_pi(struct soap *soap) + { char buf[64]; + char *s = buf; +- int i = sizeof(buf); +- soap_wchar c = soap_getchar(soap); +- /* This is a quick way to parse XML PI and we could use a callback instead to +- * enable applications to intercept processing instructions */ +- while ((int)c != EOF && c != '?') +- { if (--i > 0) ++ size_t i = sizeof(buf); ++ soap_wchar c; ++ /* Parse the XML PI encoding declaration and look for */ ++ while ((int)(c = soap_getchar(soap)) != EOF && c != '?') ++ { if (i > 1) + { if (soap_blank(c)) + c = ' '; + *s++ = (char)c; ++ i--; + } +-c = soap_getchar(soap); + } + *s = '\0'; + DBGLOG(TEST, SOAP_MESSAGE(fdebug, "XML PI \n", buf)); +diff -ur gsoap-2.8.orig/gsoap/stdsoap2.cpp gsoap-2.8/gsoap/stdsoap2.cpp +--- gsoap-2.8.orig/gsoap/stdsoap2.cpp 2016-04-03 03:33:31.0 +0200 gsoap-2.8/gsoap/stdsoap2.cpp 2017-08-01 14:51:44.143083498 +0200 +@@ -1711,17 +1711,16 @@ + soap_get_pi(struct soap *soap) + { char buf[64]; + char *s = buf; +- int i = sizeof(buf); +- soap_wchar c = soap_getchar(soap); +- /* This is a quick way to parse XML PI and we could use a callback instead to +- * enable applications to intercept processing instructions */ +- while ((int)c != EOF && c != '?') +- { if (--i > 0) ++ size_t i = sizeof(buf); ++ soap_wchar c; ++ /* Parse the XML PI encoding declaration and look for */ ++ while ((int)(c = soap_getchar(soap)) != EOF && c != '?') ++ { if (i > 1) + { if (soap_blank(c)) + c = ' '; + *s++ = (char)c; ++ i--; + } +-c = soap_getchar(soap); + } + *s = '\0'; + DBGLOG(TEST, SOAP_MESSAGE(fdeb