Bug#1068134: globus-gram-job-manager-scripts: arch:all package depends on pre-t64 library

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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)

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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"

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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=sh4=3.21.3-4=1633638401=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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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	2020-10-16

Bug#977960: I still have a symlink that points to nowhere

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

> 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

[Mattias Ellert]

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

[Mattias Ellert]

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=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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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/debian/patches/gsoap-malformed-DIME.patch
-

Bug#922385: stretch-pu: package gsoap/2.8.35-4+deb9u2

[Mattias Ellert]

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.patch	2019-02-13 17:12:41.0

Bug#922384: jessie-pu: package gsoap/2.8.17-1+deb8u2

[Mattias Ellert]

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/debian/patches/gsoap-malformed

Bug#917726: globus-gass-copy: FTBFS: tests failed

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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

[Mattias Ellert]

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(
+ _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(
+ _data_index);
+ 
diff -Nru glo

Bug#908090: VCS check reports bogus error

[Mattias Ellert]

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

[Mattias Ellert]

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)

[Mattias Ellert]

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.

[Mattias Ellert]

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 _; }
 
 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 _; }
 
 private:
   GPrivate gobject_;


smime.p7s
Description: S/MIME cryptographic signature

Bug#872442: jessie-pu: package gsoap/2.8.17-1+deb8u1

[Mattias Ellert]

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

[Mattias Ellert]

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 <mattias.ell...@physics.uu.se>  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

[Mattias Ellert]

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 <mattias.ell...@physics.uu.se>  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 <mattias.ell...@physics.uu.se>  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

[Mattias Ellert]

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 <mattias.ell...@physics.uu.se>  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(fdebug, "XML PI \n", buf));
diff -Nru gsoap-2.8.35/debian/patches

Bug#872441: stretch-pu: package gsoap/2.8.35-4+deb9u1

[Mattias Ellert]

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: )
> > > +
> > > + -- Mattias Ellert <mattias.ell...@physics.uu.se>  Wed, 16 Aug 2017 
> > > 11:58:11 +0200
> > > +
> > >  gsoap (2.8.35-4) unstable; urgency=medium
> > 
> > once this changelog has a proper Closes line with bug-number this patch
> > looks sane to me.
> 
> Is there actually a Debian bug for the issue? I couldn't find one.
> 
> Regards,
> 
> Adam
> 

Hi!

I don't understand the last comment here.
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.

Mattias


signature.asc
Description: This is a digitally signed message part

Bug#872441: stretch-pu: package gsoap/2.8.35-4+deb9u1

[Mattias Ellert]

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

This is a proposal to fix CVE-2017-9765 in stretch.
debdiff is attached.

Mattias Ellert
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 (Closes: )
+
+ -- Mattias Ellert <mattias.ell...@physics.uu.se>  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(fdebug, "XML PI \n", buf));
diff -Nru gsoap-2.8.35/debian/patches/series gsoap-2.8.35/debian/patches/series
--- gsoap-2.8.35/debian/patches/series	2016-09-26 14:49:01.0 +0200
+++ gsoap-2.8.35/debian/patches/series	2017-08-16 11:57:36.0 +0200
@@ -10,3 +10,6 @@
 
 # Backport fix from upstream
 gsoap-backport.patch
+
+# CVE-2017-9765
+gsoap-CVE-2017-9765.patch


signature.asc
Description: This is a digitally signed message part

Bug#872442: jessie-pu: package gsoap/2.8.17-1+deb8u1

[Mattias Ellert]

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 <mattias.ell...@physics.uu.se>  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#868335: RM: globus-core -- ROM; dummy package no longer needed

[Mattias Ellert]

Package: ftp.debian.org
Severity: normal

The globus-core package became obsolete with the release of Globus
Toolkit 6.0 in 2014. The package was converted to a dummy package with
no content at the time, in order to ease the migration to the new
release. But it is now time to ask for it to be removed.

Mattias Ellert
Maintainer of the package


signature.asc
Description: This is a digitally signed message part

Bug#859932: gsoap: please package a recent gsoap version

[Mattias Ellert]

sön 2017-07-09 klockan 13:22 +0200 skrev Carsten Schoenert:
> Hello Matthias,
> 
> One additinal question, is it possible that you can provide a dsc file
> or even some pre-compiled new packages else there? That would help us to
> also work on a new kopanocore upload in the between time.
> 
> Regards
> Carsten

Hi Carsten!

I have put a copy of my latest upload here:

http://www.ellert.se/gsoap/

Mattias


smime.p7s
Description: S/MIME cryptographic signature

Bug#867252: libexpat1-dev: Missing Depends on libbsd-dev [kfreebsd-amd64 kfreebsd-i386]

[Mattias Ellert]

Source: expat
Version: 2.2.1-2
Severity: important

Linking to libexpat fails on kfreebsd-amd64 and kfreebsd-i386 because
libexpat1-dev does not declare that it depends on libbsd-dev on those
architectures.

The failure can be seen here:

https://buildd.debian.org/status/package.php?p=voms=unstable

/usr/bin/ld: cannot find -lbsd
collect2: error: ld returned 1 exit status

The source for the -lbsd in the link command comes from the libexpat.la
file, that is part of the libexpat1-dev package.

(sid_k-a-dchroot)ellert@falla:~$ dpkg -S 
/usr/lib/x86_64-kfreebsd-gnu/libexpat.la
libexpat1-dev:kfreebsd-amd64: /usr/lib/x86_64-kfreebsd-gnu/libexpat.la
(sid_k-a-dchroot)ellert@falla:~$ grep -B1 lbsd 
/usr/lib/x86_64-kfreebsd-gnu/libexpat.la
# Libraries that this one depends upon.
dependency_libs=' -lbsd'

On other architectures the dependency_libs is empty, so the missing
dependency only applies to the kfreebsd architectures.

Mattias


signature.asc
Description: This is a digitally signed message part

Bug#859932: gsoap: please package a recent gsoap version

[Mattias Ellert]

sön 2017-04-09 klockan 13:59 +0200 skrev Carsten Schoenert:
> Source: gsoap
> Severity: wishlist
> 
> Dear Mattias,
> 
> could you please consider to package the actual gsoap version and
> provide the packages in experimental?
> 
> We are trying to prepare a new kopanocore package and this is needing at
> least a gsoap version > 2.8.36. So I would like to use a recent gsoap
> for this.
> 
> Thanks & Regards
> Carsten

Updating gsoap always creates a bit of a mess since it means that there
will be a soname bump and a need for transition binNMUs for depending
packages. I agree that it is time to do an update soon, but there is a
freeze at the moment, so the update would not migrate to testing
anytime soon, and by the time it does it might be time to update again.
Updates that bring soname bumps are discouraged during freezes.

The current version in testing and unstable is 2.8.35-4. The difference
between 2.8.35 and 2.8.36 is not big. If you disregard the places in
the code where the version number is encoded it is only one line of
code that is changed. That line is already backported to the current
version in Debian:

https://sources.debian.net/src/gsoap/2.8.35-4/debian/patches/gsoap-backport.patch/

So if the reason you require 2.8.36 is that change then gsoap >=
2.8.35-2 should be sufficient. Let me know.

Mattias


signature.asc
Description: This is a digitally signed message part