Bug#750446: LaTeX Error: Unknown float option `H'

[Mattias Ellert]

ons 2014-06-04 klockan 16:04 +0900 skrev Norbert Preining:
 Hi,
 
The float package
 
 Then the order is wrong in the document.
 
 The order of loading fixltx2e and float is important when you
 use the extension of float.
 
 The following document compiles correctly:
   \documentclass{article}
   \usepackage{fixltx2e}
   \usepackage{float}
   \begin{document}
   \begin{figure}[H]
Huu
   \end{figure}
   \end{document}

This was useful. Unlike all your previous yelling about that the
original sources are broken. There was nothing broken about these
original sources before upstream introduced a change to fixltx2e.

With this new information I can file a bug to doxygen asking the
maintainer to adapt to this backward incompatible change in texlive.

Mattias



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

Bug#755017: FTBFS against cgsi-gsoap 1.3.6-1+b1

[Mattias Ellert]

ons 2014-07-16 klockan 22:41 +0200 skrev Emilio Pozuelo Monfort:
 Source: gfal2
 Version: 2.3.0-4
 Severity: serious
 
 Doing rebuilds for the libgsoap5 transition, your package failed to build
 everywhere except on amd64, i386 and hurd-i386. That seems to be because
 in those builds, the version of libcgsi-gsoap1 was 1.3.6-1 (i.e. before the
 binNMU for libgsoap5) while on the builds that failed libcgsi-gsoap1 was at
 1.3.6-1+b1. The error was:
 
 /usr/bin/c++   -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
 -Werror=format-security -D_FORTIFY_SOURCE=2-Wl,-z,relro 
 CMakeFiles/unit_test_srm_plugin.dir/tests_srm.cpp.o  -o unit_test_srm_plugin  
 -L/«PKGBUILDDIR»/obj-arm-linux-gnueabihf/src  
 -L/«PKGBUILDDIR»/obj-arm-linux-gnueabihf/plugins -rdynamic 
 ../../../../src/libgfal2.so.2.3.0 -lgfal_srm_ifce -lgfal_transfer 
 -lgfal_plugin_srm -lm ../../../../src/libgfal2.so.2.3.0 
 ../../../gtest/libgtest.a ../../../gtest/libgtest_main.a -luuid -lstdc++ 
 -lglib-2.0 -lgthread-2.0 -lglib-2.0 -lgthread-2.0 -ldl 
 ../../../gtest/libgtest.a -lpthread 
 -Wl,-rpath,/«PKGBUILDDIR»/obj-arm-linux-gnueabihf/src:/«PKGBUILDDIR»/obj-arm-linux-gnueabihf/plugins
  
 //usr/lib/libcgsi_plugin.so.1: undefined reference to 
 `soap_init_LIBRARY_VERSION_REQUIRED_20817'
 collect2: error: ld returned 1 exit status
 make[4]: *** [test/unit/common/srm/unit_test_srm_plugin] Error 1
 
 I'm filing this against gfal2, although it bothers me that the libraries
 shipped by libcgsi-gsoap1 have undefined references. But that's been
 happening for a long time, so filing here. Please reassign if necessary.
 
 Emilio

The failure is not caused by that the binnmu for cgsi-gsoap had
happened, but because the binnmu for srm-ifce had not happened. Now that
the binnmus for srm-ifce has completed the builds of gfal2 shouldn't
have any problems. If you try to build against a cgsi-gsoap that has
been rebuilt and an srm-ifce that has not you are using an incompatible
set of dependencies and your build is expected to fail. That it fails
instead of creating a broken binary is a good thing.

That the libraries in libcgsi-gsoap1 have undefined references is by
construction, they are deliberately left unresolved in order to make it
possible for different users of the library to choose different
implementations of these functions. Explicitly linking these libraries
to one implementation will introduce breakage.

The binnmu of lcgdm is similar. Only amd64 was tried so far and failed
because it was using a cgsi-gsoap that had not been recompiled (and
therefore expects gsoap4) together with the new gsoap5. After the
cgsi-gsoap has been rebuilt the lcgdm rebuild will work just fine.

I think you have unreasonable expectations if you expect interdependent
packages to be able to binnmu in random order.

This is not a permanent FTBFS. It is a transient state that exist during
the transition when some packages have been rebuilt and some not.

(The virtuabox package needs fixing for unrelated reasons, it bails out
if the gcc version detected in greater than 4.8.)

Mattias



smime.p7s
Description: S/MIME cryptographic signature

Bug#741588: ITP: canl-java -- EMI Common Authentication Library - Bindings for Java

[Mattias Ellert]

Package: wnpp
Severity: wishlist
Owner: Mattias Ellert mattias.ell...@fysast.uu.se

* Package name: canl-java
  Version : 2.0.0
* URL : https://github.com/eu-emi/canl-java/
* License : BSD / Apache 2 / MIT
  Description : EMI Common Authentication Library - Bindings for Java

EMI Common Authentication Library (caNl) - Java bindings



smime.p7s
Description: S/MIME cryptographic signature

Bug#630019: Acknowledgement (@defgroup generates manpage warning.)

[Mattias Ellert]

A github pull request fixing this issue has been merged in upstream's
git repository:

https://github.com/doxygen/doxygen/pull/213

Mattias



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

Bug#630022: Acknowledgement (Typedefs in manpages has too few linebreak possiblilities)

[Mattias Ellert]

A github pull request fixing this issue has been merged in upstream's
git repository:

https://github.com/doxygen/doxygen/pull/214

(The same pull request also fixes bug #630018)

Mattias



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

Bug#630018: Acknowledgement (Missing spaces in man page output)

[Mattias Ellert]

A github pull request fixing this issue has been merged in upstream's
git repository:

https://github.com/doxygen/doxygen/pull/214

(The same pull request also fixes big #630022)

Mattias



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

Bug#630020: Acknowledgement (Brief description misplaced in man page output)

[Mattias Ellert]

A github pull request fixing this issue has been merged in upstream's
git repository:

https://github.com/doxygen/doxygen/pull/215

Mattias



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

Bug#731547: Bug located to glib.

[Mattias Ellert]

Control: reassign 731547 libglib2.0-0 2.42.0-2
Control: tags 731547 + patch
Control: retitle 731547 glib not handling -1 return from sysconf

I have investigated this on the porterbox, and located the bug to glib.
Patch is attached.

The bug is due to that when the return value of sysconf (a long) is
compared to the variable stack_size (an unsigned long) the values have
to be converted to a common type in order to do the comparison. This
common type is chosen by the compiler to be unsigned long - which is
correct behaviour according to the C language standard. When sysconf
returns -1 this is therefore converted to ULONG_MAX in order to do the
comparison and this is of course then always considered to be the higher
value. So the stack_size allocated for the thread becomes -1 bytes. When
the thread starts and allocates memory in this non-existing stack it
overwrites memory already in use by other threads.

The patch checks that the value returned by sysconf is positive before
comparing it to the variable stack_size.

Mattias

--- glib-2.42.0/glib/gthread-posix.c	2014-09-22 13:42:12.0 +
+++ glib-2.42.0/glib/gthread-posix.c	2014-10-15 03:22:36.0 +
@@ -1159,7 +1159,9 @@
   if (stack_size)
 {
 #ifdef _SC_THREAD_STACK_MIN
-  stack_size = MAX (sysconf (_SC_THREAD_STACK_MIN), stack_size);
+  long min_stack_size = sysconf (_SC_THREAD_STACK_MIN);
+  if (min_stack_size = 0)
+stack_size = MAX (min_stack_size, stack_size);
 #endif /* _SC_THREAD_STACK_MIN */
   /* No error check here, because some systems can't do it and
* we simply don't want threads to fail because of that. */


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

Bug#755878: nordugrid-arc: FTBFS on hurd-i386

[Mattias Ellert]

The bug has been identified and located to glib2.0.
Bug #731547 has been reassigned accordingly.

Mattias



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

Bug#764840: Wrong return value from select on Hurd

[Mattias Ellert]

Package: glibc
Version: 2.19-11
Severity: serious

The return value from the select function on Hurd is sometimes too high.
I.e. the value returned is greater than the total number of bits set in
the fd_set variables.

This causes problems for code that expect the value to be accurate, and
causes FTBFS on Hurd for other packages due to failing tests suites,
e.g. globus-ftp-client, globus-ftp-control, globus-io and
globus-scheduler-event-generator.

The bug is introduced by the patch
debian/patches/hurd-i386/tg-poll_errors_fixes.diff

The attached patch can be applied to fix the issue.

Mattias

--- glibc-2.19/hurd/hurdselect.c.orig	2014-10-11 05:55:04.0 +
+++ glibc-2.19/hurd/hurdselect.c	2014-10-11 14:23:17.0 +
@@ -551,7 +551,15 @@
 	   readiness of the erring object and the next call hopefully
 	   will get the error again.  */
 	if (type  SELECT_ERROR)
-	  type = SELECT_ALL;
+	  {
+		type = 0;
+		if (readfds != NULL  FD_ISSET (i, readfds))
+		  type |= SELECT_READ;
+		if (writefds != NULL  FD_ISSET (i, writefds))
+		  type |= SELECT_WRITE;
+		if (exceptfds != NULL  FD_ISSET (i, exceptfds))
+		  type |= SELECT_URG;
+	  }
 
 	if (type  SELECT_READ)
 	  ready++;


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

Bug#765145: globus-simple-ca: FTBFS: Tests failures

[Mattias Ellert]

mån 2014-10-13 klockan 19:27 +0200 skrev David Suárez:
 Source: globus-simple-ca
 Version: 4.14-1
 Severity: serious
 Tags: jessie sid
 User: debian...@lists.debian.org
 Usertags: qa-ftbfs-20141012 qa-ftbfs
 Justification: FTBFS on amd64
 
 Hi,
 
 During a rebuild of all packages in sid, your package failed to build on
 amd64.

I can not reproduce this failure. I tried rebuilding the package in
pbuilder 5 times and it worked every time. Can you provide a copy of the
logfile test/grid-ca-create-test.log from a failed build?

Mattias



smime.p7s
Description: S/MIME cryptographic signature

Bug#762990: ITP: globus-gridmap-eppn-callout -- Globus Toolkit - Globus gridmap ePPN callout

[Mattias Ellert]

Package: wnpp
Severity: wishlist
Owner: Mattias Ellert mattias.ell...@fysast.uu.se

* Package name: globus-gridmap-eppn-callout
  Version : 1.6
* URL : http://www.globus.org/
* License : Apache-2.0
  Description : Globus Toolkit - Globus gridmap ePPN callout

New package in Globus Toolkit 6.0



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

Bug#762992: ITP: globus-xio-udt-driver -- Globus Toolkit - Globus XIO UDT Driver

[Mattias Ellert]

Package: wnpp
Severity: wishlist
Owner: Mattias Ellert mattias.ell...@fysast.uu.se

* Package name: globus-xio-udt-driver
  Version : 1.15
* URL : http://www.globus.org/
* License : Apache-2.0
  Description : Globus Toolkit - Globus XIO UDT Driver

New package in Globus Toolkit 6.0



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

Bug#762991: ITP: globus-xio-gridftp-multicast -- Globus Toolkit - Globus XIO GridFTP Multicast Driver

[Mattias Ellert]

Package: wnpp
Severity: wishlist
Owner: Mattias Ellert mattias.ell...@fysast.uu.se

* Package name: globus-xio-gridftp-multicast
  Version : 1.5
* URL : http://www.globus.org/
* License : Apache-2.0
  Description : Globus Toolkit - Globus XIO GridFTP Multicast Driver

New package in Globus Toolkit 6.0



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

Bug#762998: ITP: globus-xio-rate-driver -- Globus Toolkit - Globus XIO Rate Limiting Driver

[Mattias Ellert]

Package: wnpp
Severity: wishlist
Owner: Mattias Ellert mattias.ell...@fysast.uu.se

* Package name: globus-xio-rate-driver
  Version : 1.7
* URL : http://www.globus.org/
* License : Apache-2.0
  Description : Globus Toolkit - Globus XIO Rate Limiting Driver

New package in Globus Toolkit 6.0



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

Bug#763970: RM: grid-packaging-tools -- ROM; The GPT build system is no longer used by Globus Toolkit 6.0

[Mattias Ellert]

Package: ftp.debian.org
Severity: normal

With the release of Globus Toolkit 6.0 the build system has changed from
the Grid Packaging Tools (GPT) to the more standard autotools and
libtool. No other packages used this special build system except
myproxy, which has also dropped it. The removal of grid-packaging-tools
from Debian is therefore requested.

Mattias



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

Bug#763969: RM: globus-rls-server -- ROM; The Replica Location Service (RLS) has not been maintained upstream since the release of Globus Toolkit 5.2 (Dec 2011)

[Mattias Ellert]

Package: ftp.debian.org
Severity: normal

The upstream Globus Toolkit distribution dropped RLS when Globus Toolkit
5.2 was released in December 2011. The Debian package has kept the old
GT 5.0 version compiled against the new GT 5.2 libraries until now. But
with the release of GT 6.0 this effort becomes harder due to the change
of build system from GPT to autotools/libtool in GT. And it is almost 3
years since the code is no longer maintained so it is time to retire it
from Debian anyway.

Mattias



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

Bug#763968: RM: globus-rls-client -- ROM; The Replica Location Service (RLS) has not been maintained upstream since the release of Globus Toolkit 5.2 (Dec 2011)

[Mattias Ellert]

Package: ftp.debian.org
Severity: normal

The upstream Globus Toolkit distribution dropped RLS when Globus Toolkit
5.2 was released in December 2011. The Debian package has kept the old
GT 5.0 version compiled against the new GT 5.2 libraries until now. But
with the release of GT 6.0 this effort becomes harder due to the change
of build system from GPT to autotools/libtool in GT. And it is almost 3
years since the code is no longer maintained so it is time to retire it
from Debian anyway.

Mattias



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

Bug#768506: unblock globus packages with fix for symlink-to-dir conversions

[Mattias Ellert]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hi!

I got bug reports for 6 of the globus packages saying they did not
handle symlink to dir conversion properly.

However, the same problem exists in all globus packages providing a doc
binary package (except for one that just recently had the doc package
added and never had the symlink). I have uploaded updates for all 29
affected globus packages, and not only the 6 packages I got bug reports
for. I would like for you to consider unblocking all of them.

These uploads adds the maintainer scripts needed to handle the
symlink-to-dir conversion properly to the latest version in unstable,
without other changes (except adding VERBOSE=1 to the make check call
where it was not there before).

For some of these updates, the version in unstable to which the fix for
the problem was applied had not already migrated to testing. The changes
w.r.t. the versions in testing are small (minor version updates only)
and for most of the package the new upstream version was done after
upstream accepted the patches that were already applied in the debian
package of the previous version.

globus-authz 3.10-2 (Closes: #762857)
globus-authz-callout-error 3.5-2 (Closes: #762855)
globus-callout 3.13-2 (Closes: #762860)
globus-common 15.26-2 (Closes: #762862) [1]
globus-ftp-client 8.13-5
globus-ftp-control 5.12-2
globus-gass-copy 9.12-2
globus-gass-transfer 8.8-2
globus-gram-client 13.10-2 [2]
globus-gram-job-manager-callout-error 3.5-2
globus-gram-job-manager-scripts 6.7-2
globus-gram-protocol 12.12-2
globus-gridmap-callout-error 2.4-2
globus-gsi-callback 5.6-2
globus-gsi-cert-utils 9.10-2
globus-gsi-credential 7.7-2
globus-gsi-openssl-error 3.5-2
globus-gsi-proxy-core 7.7-2
globus-gsi-proxy-ssl 5.7-2
globus-gsi-sysconfig 6.8-2
globus-gssapi-error 5.4-2
globus-gssapi-gsi 11.13-2
globus-gss-assist 10.12-2
globus-openssl-module 4.6-2
globus-rsl 10.9-2 (Closes: #762863)
globus-scheduler-event-generator 5.7-2 (Closes: #762864)
globus-xio 4.15-2
globus-xio-gridftp-driver 2.8-2
globus-xio-gsi-driver 3.6-2

[1] The globus-common update also (Closes: #768219) - missing
Breaks/Replaces due to a man page moved from another package

[2] The globus-gram-client update to version 13.10-2 (the current
version in testing is 13.8-1) is an important security update. Even
without the fix for the symlink-to-dir problem I would have filed an
unblock request for the 13.10 version due to this. The 13.8 version
forced the use of SSLv3 (for compatibility with really old server
versions). This is not appropriate any more and upstream removed this in
the 13.10 update. Since Debian's openssl 1.0.1j-1 disables SSLv3, the
13.8 version does not work anymore against servers on Debian and the
13.10 is needed.

Mattias



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

Bug#768537: unblock: myproxy/6.0-2

[Mattias Ellert]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Closes: #768266 (Severity: serious; RC)

In addition to fixing the above bug, the update also applies a patch to
enable TLS. The previous package used SSLv3 only, which is no longer
appropriate. Some of the tests in the test suite failed without the
patch because Debian's openssl 1.0.1j-1 has disabled SSLv3. With the
patch the test suite passes.

Mattias

diff -Nru myproxy-6.0/debian/changelog myproxy-6.0/debian/changelog
--- myproxy-6.0/debian/changelog	2014-09-27 17:27:12.0 +0200
+++ myproxy-6.0/debian/changelog	2014-11-08 06:41:39.0 +0100
@@ -1,3 +1,10 @@
+myproxy (6.0-2) unstable; urgency=medium
+
+  * Properly handle symlink-to-dir conversion in doc package (Closes: #768266)
+  * Enable TLS - debian's openssl has disabled SSLv3 by default
+
+ -- Mattias Ellert mattias.ell...@fysast.uu.se  Fri, 07 Nov 2014 23:51:15 +0100
+
 myproxy (6.0-1) unstable; urgency=medium
 
   * Update to 6.0, adapt to Globus Toolkit 6
diff -Nru myproxy-6.0/debian/libmyproxy-doc.postinst myproxy-6.0/debian/libmyproxy-doc.postinst
--- myproxy-6.0/debian/libmyproxy-doc.postinst	1970-01-01 01:00:00.0 +0100
+++ myproxy-6.0/debian/libmyproxy-doc.postinst	2014-11-07 23:49:50.0 +0100
@@ -0,0 +1,10 @@
+#!/bin/sh
+
+set -e
+
+#DEBHELPER#
+
+dpkg-maintscript-helper symlink_to_dir \
+/usr/share/doc/libmyproxy-doc \
+libmyproxy-dev 6.0-2~ \
+libmyproxy-doc -- $@
diff -Nru myproxy-6.0/debian/libmyproxy-doc.postrm myproxy-6.0/debian/libmyproxy-doc.postrm
--- myproxy-6.0/debian/libmyproxy-doc.postrm	1970-01-01 01:00:00.0 +0100
+++ myproxy-6.0/debian/libmyproxy-doc.postrm	2014-11-07 23:49:50.0 +0100
@@ -0,0 +1,10 @@
+#!/bin/sh
+
+set -e
+
+#DEBHELPER#
+
+dpkg-maintscript-helper symlink_to_dir \
+/usr/share/doc/libmyproxy-doc \
+libmyproxy-dev 6.0-2~ \
+libmyproxy-doc -- $@
diff -Nru myproxy-6.0/debian/libmyproxy-doc.preinst myproxy-6.0/debian/libmyproxy-doc.preinst
--- myproxy-6.0/debian/libmyproxy-doc.preinst	1970-01-01 01:00:00.0 +0100
+++ myproxy-6.0/debian/libmyproxy-doc.preinst	2014-11-07 23:49:50.0 +0100
@@ -0,0 +1,10 @@
+#!/bin/sh
+
+set -e
+
+#DEBHELPER#
+
+dpkg-maintscript-helper symlink_to_dir \
+/usr/share/doc/libmyproxy-doc \
+libmyproxy-dev 6.0-2~ \
+libmyproxy-doc -- $@
diff -Nru myproxy-6.0/debian/patches/myproxy-tls.patch myproxy-6.0/debian/patches/myproxy-tls.patch
--- myproxy-6.0/debian/patches/myproxy-tls.patch	1970-01-01 01:00:00.0 +0100
+++ myproxy-6.0/debian/patches/myproxy-tls.patch	2014-11-08 06:12:14.0 +0100
@@ -0,0 +1,53 @@
+diff --git a/myproxy.c b/myproxy.c
+index 24e744f..9f2fb65 100644
+--- a/myproxy.c
 b/myproxy.c
+@@ -544,8 +544,9 @@ myproxy_bootstrap_trust(myproxy_socket_attrs_t *attrs)
+ }
+ 
+ /* get trust root(s) from the myproxy-server */
+-ctx = SSL_CTX_new(SSLv3_client_method());
+-SSL_CTX_set_options(ctx, SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS);
++ctx = SSL_CTX_new(SSLv23_client_method());
++SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2 |
++			SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS);
+ 
+ if (!(sbio = BIO_new_ssl_connect(ctx))) goto error;
+ if ( (sockfd = get_connected_myproxy_host_socket(
+diff --git a/myproxy_ocsp.c b/myproxy_ocsp.c
+index 440f6ef..d39e1dc 100644
+--- a/myproxy_ocsp.c
 b/myproxy_ocsp.c
+@@ -311,11 +311,12 @@ int myproxy_ocsp_verify(X509 *cert, X509 *issuer) {
+ goto end;
+   }
+   X509_LOOKUP_add_dir(lookup, certdir, X509_FILETYPE_PEM);
+-  ctx = SSL_CTX_new(SSLv3_client_method());
++  ctx = SSL_CTX_new(SSLv23_client_method());
+   if (ctx == NULL) {
+ result = MYPROXY_OCSPRESULT_ERROR_OUTOFMEMORY;
+ goto end;
+   }
++  SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2);
+   SSL_CTX_set_cert_store(ctx, store);
+   SSL_CTX_set_verify(ctx,SSL_VERIFY_PEER,NULL);
+ 
+diff --git a/ssl_utils.c b/ssl_utils.c
+index 0749e5b..4ff5aa5 100644
+--- a/ssl_utils.c
 b/ssl_utils.c
+@@ -2146,12 +2146,13 @@ ssl_verify_gsi_chain(SSL_CREDENTIALS *chain)
+X509_LOOKUP_add_dir(lookup, certdir, X509_FILETYPE_PEM);
+X509_STORE_CTX_init(csc, cert_store, chain-certificate, NULL);
+
+-   sslContext = SSL_CTX_new(SSLv3_server_method());
++   sslContext = SSL_CTX_new(SSLv23_server_method());
+if (sslContext == NULL) {
+   verror_put_string(Initializing SSL_CTX);
+   ssl_error_to_verror();
+   goto end;
+}
++   SSL_CTX_set_options(sslContext, SSL_OP_NO_SSLv2);
+ 
+SSL_CTX_set_purpose(sslContext, X509_PURPOSE_ANY);
+ 
diff -Nru myproxy-6.0/debian/patches/series myproxy-6.0/debian/patches/series
--- myproxy-6.0/debian/patches/series	2014-09-27 18:31:26.0 +0200
+++ myproxy-6.0/debian/patches/series	2014-11-08 06:05:21.0 +0100
@@ -2,3 +2,5 @@
 myproxy-pathmax.patch
 # Missing depandencies
 myproxy-deps.patch
+# Enable TLS
+myproxy-tls.patch


signature.asc
Description: This is a digitally signed message

Bug#768538: unblock voms/2.0.11-4

[Mattias Ellert]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Closes: #768276 (Severity: serious; RC)

Mattias

diff -Nru voms-2.0.11/debian/changelog voms-2.0.11/debian/changelog
--- voms-2.0.11/debian/changelog	2014-08-07 05:18:24.0 +0200
+++ voms-2.0.11/debian/changelog	2014-11-08 07:20:44.0 +0100
@@ -1,3 +1,9 @@
+voms (2.0.11-4) unstable; urgency=medium
+
+  * Properly handle symlink-to-dir conversion in doc package (Closes: #768276)
+
+ -- Mattias Ellert mattias.ell...@fysast.uu.se  Sat, 08 Nov 2014 07:19:30 +0100
+
 voms (2.0.11-3) unstable; urgency=medium
 
   * Drop depends on voms-dev in voms-doc (Closes: #755570)
diff -Nru voms-2.0.11/debian/control voms-2.0.11/debian/control
--- voms-2.0.11/debian/control	2014-08-07 05:05:04.0 +0200
+++ voms-2.0.11/debian/control	2014-11-08 07:41:14.0 +0100
@@ -2,7 +2,7 @@
 Priority: optional
 Maintainer: Mattias Ellert mattias.ell...@fysast.uu.se
 Build-Depends: debhelper (= 5), autoconf, automake, libtool, autotools-dev, libssl-dev, libexpat1-dev, gsoap, pkg-config, xsltproc, docbook-xml, docbook-xsl, doxygen-latex, texlive-fonts-recommended
-Standards-Version: 3.9.5
+Standards-Version: 3.9.6
 Section: libs
 Vcs-Browser: http://svn.nordugrid.org/trac/packaging/browser/debian/voms
 Vcs-Svn: http://svn.nordugrid.org/repos/packaging/debian/voms
diff -Nru voms-2.0.11/debian/voms-doc.postinst voms-2.0.11/debian/voms-doc.postinst
--- voms-2.0.11/debian/voms-doc.postinst	1970-01-01 01:00:00.0 +0100
+++ voms-2.0.11/debian/voms-doc.postinst	2014-11-08 07:24:55.0 +0100
@@ -0,0 +1,10 @@
+#!/bin/sh
+
+set -e
+
+#DEBHELPER#
+
+dpkg-maintscript-helper symlink_to_dir \
+/usr/share/doc/voms-doc \
+voms-dev 2.0.11-4~ \
+voms-doc -- $@
diff -Nru voms-2.0.11/debian/voms-doc.postrm voms-2.0.11/debian/voms-doc.postrm
--- voms-2.0.11/debian/voms-doc.postrm	1970-01-01 01:00:00.0 +0100
+++ voms-2.0.11/debian/voms-doc.postrm	2014-11-08 07:24:55.0 +0100
@@ -0,0 +1,10 @@
+#!/bin/sh
+
+set -e
+
+#DEBHELPER#
+
+dpkg-maintscript-helper symlink_to_dir \
+/usr/share/doc/voms-doc \
+voms-dev 2.0.11-4~ \
+voms-doc -- $@
diff -Nru voms-2.0.11/debian/voms-doc.preinst voms-2.0.11/debian/voms-doc.preinst
--- voms-2.0.11/debian/voms-doc.preinst	1970-01-01 01:00:00.0 +0100
+++ voms-2.0.11/debian/voms-doc.preinst	2014-11-08 07:24:55.0 +0100
@@ -0,0 +1,10 @@
+#!/bin/sh
+
+set -e
+
+#DEBHELPER#
+
+dpkg-maintscript-helper symlink_to_dir \
+/usr/share/doc/voms-doc \
+voms-dev 2.0.11-4~ \
+voms-doc -- $@


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

Bug#745475: broken auto-removal logic

[Mattias Ellert]

I would like to propose to increase the severity of this bug back to
serious. I find it extremely disruptive.

At the moment mariadb is broken, and every package that has a dependency
on mariadb-client | mysql-client or recursively depends on such a
package is marked autorm even though mysql is not broken.

Mattias



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

Bug#770383: ITP: voms-clients-java -- Virtual Organization Membership Service Java clients

[Mattias Ellert]

Package: wnpp
Severity: wishlist
Owner: Mattias Ellert mattias.ell...@fysast.uu.se

* Package name: voms-clients-java
  Version : 3.0.5
* URL : https://wiki.italiangrid.it/VOMS
* License : Apache-2.0
  Description : Virtual Organization Membership Service Java clients

The Virtual Organization Membership Service (VOMS) is an attribute authority
which serves as central repository for VO user authorization information,
providing support for sorting users into group hierarchies, keeping track of
their roles and other attributes in order to issue trusted attribute
certificates and SAML assertions used in the Grid environment for
authorization purposes.

This package provides the Java version of the command line clients for VOMS:
voms-proxy-init, voms-proxy-destroy and voms-proxy-info.



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

Bug#768537: unblock: myproxy/6.0-2

[Mattias Ellert]

Control: -1 tags - moreinfo
Control: -1 retitle unblock: myproxy/6.0-3

New version with Pre-Depends: 6.0/3

Mattias



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

Bug#768538: unblock voms/2.0.11-4

[Mattias Ellert]

Control: -1 tags - moreinfo
Control: -1 retitle unblock: voms/2.0.11-5

New version with Pre-Depends: 2.0.11-5

Mattias



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

Bug#768506: unblock globus packages with fix for symlink-to-dir conversions

[Mattias Ellert]

Control: tags -1 - moreinfo

New versions with Pre-Depends:

globus-common/15.26-3
globus-authz/3.10-3
globus-authz-callout-error/3.5-3
globus-callout/3.13-3
globus-ftp-client/8.13-6
globus-ftp-control/5.12-3
globus-gass-copy/9.12-3
globus-gass-transfer/8.8-3
globus-gram-client/13.10-3
globus-gram-job-manager-callout-error/3.5-3
globus-gram-job-manager-scripts/6.7-3
globus-gram-protocol/12.12-3
globus-gridmap-callout-error/2.4-3
globus-gsi-callback/5.6-3
globus-gsi-cert-utils/9.10-3
globus-gsi-credential/7.7-3
globus-gsi-openssl-error/3.5-3
globus-gsi-proxy-core/7.7-3
globus-gsi-proxy-ssl/5.7-3
globus-gsi-sysconfig/6.8-3
globus-gssapi-error/5.4-3
globus-gssapi-gsi/11.13-3
globus-gss-assist/10.12-3
globus-openssl-module/4.6-3
globus-rsl/10.9-3
globus-scheduler-event-generator/5.7-3
globus-xio/4.15-3
globus-xio-gridftp-driver/2.8-3
globus-xio-gsi-driver/3.6-3

Mattias



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

Bug#768537: unblock: myproxy/6.0-2

[Mattias Ellert]

lör 2014-11-08 klockan 10:06 +0100 skrev Mattias Ellert:
 Closes: #768266 (Severity: serious; RC)
 
 In addition to fixing the above bug, the update also applies a patch to
 enable TLS. The previous package used SSLv3 only, which is no longer
 appropriate. Some of the tests in the test suite failed without the
 patch because Debian's openssl 1.0.1j-1 has disabled SSLv3. With the
 patch the test suite passes.

This test failure has since been reported as bug #768722

Unblocking this update will therefore also resolve that bug for the
release.

Mattias



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

Bug#768811: unblock: globus-simple-ca/4.14-3

[Mattias Ellert]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Closes: #768771 (Severity: serious; RC)

diff -Nru globus-simple-ca-4.14/debian/changelog globus-simple-ca-4.14/debian/changelog
--- globus-simple-ca-4.14/debian/changelog	2014-10-29 05:35:25.0 +0100
+++ globus-simple-ca-4.14/debian/changelog	2014-11-09 12:02:35.0 +0100
@@ -1,3 +1,10 @@
+globus-simple-ca (4.14-3) unstable; urgency=medium
+
+  * Don't try to write to $HOME/.rnd during make check (Closes: #768771)
+  * Enable verbose tests
+
+ -- Mattias Ellert mattias.ell...@fysast.uu.se  Sun, 09 Nov 2014 10:35:42 +0100
+
 globus-simple-ca (4.14-2) unstable; urgency=medium
 
   * Move make check to build target (Closes: #765145)
diff -Nru globus-simple-ca-4.14/debian/patches/globus-simple-ca-rnd.patch globus-simple-ca-4.14/debian/patches/globus-simple-ca-rnd.patch
--- globus-simple-ca-4.14/debian/patches/globus-simple-ca-rnd.patch	1970-01-01 01:00:00.0 +0100
+++ globus-simple-ca-4.14/debian/patches/globus-simple-ca-rnd.patch	2014-11-09 11:48:29.0 +0100
@@ -0,0 +1,18 @@
+diff --git a/test/Makefile.am b/test/Makefile.am
+index 4ec92d2..0576f5c 100644
+--- a/test/Makefile.am
 b/test/Makefile.am
+@@ -6,7 +6,11 @@ test_scripts = $(check_SCRIPTS)
+ 
+ TESTS = $(test_scripts)
+ 
+-TEST_PATH=$(abs_top_builddir):$(GLOBUS_COMMON_PATH):$${PATH}
++TEST_PATH = $(abs_top_builddir):$(GLOBUS_COMMON_PATH):$${PATH}
+ 
+ EXTRA_DIST = $(check_SCRIPTS)
+-TESTS_ENVIRONMENT=export PATH=$(TEST_PATH);
++TESTS_ENVIRONMENT = export \
++PATH=$(TEST_PATH) \
++RANDFILE=$(abs_top_builddir)/test/.rnd;
++
++CLEANFILES = .rnd
diff -Nru globus-simple-ca-4.14/debian/patches/series globus-simple-ca-4.14/debian/patches/series
--- globus-simple-ca-4.14/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ globus-simple-ca-4.14/debian/patches/series	2014-11-09 11:40:51.0 +0100
@@ -0,0 +1,2 @@
+# Don't try to write to ${HOME}/.rnd during make check
+globus-simple-ca-rnd.patch
diff -Nru globus-simple-ca-4.14/debian/rules globus-simple-ca-4.14/debian/rules
--- globus-simple-ca-4.14/debian/rules	2014-10-27 16:14:50.0 +0100
+++ globus-simple-ca-4.14/debian/rules	2014-11-09 11:58:11.0 +0100
@@ -18,6 +18,9 @@
 configure-stamp:
 	dh_testdir
 
+	# Avoid regenerating man page due to bad timestamps
+	touch -r grid-ca-create.xml grid-ca-create.1
+
 	dh_autoreconf
 
 	./configure \
@@ -43,7 +46,7 @@
 	dh_testdir
 
 	$(MAKE)
-	$(MAKE) check
+	$(MAKE) check VERBOSE=1
 
 	touch $@
 


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

Bug#768747: openjdk-7

[Mattias Ellert]

Control: reassign -1 openjdk-7/7u71-2.5.3-1

sön 2014-11-09 klockan 08:28 +0100 skrev Lucas Nussbaum:
 Source: canl-java
 Version: 2.1.1-1
 Severity: serious
 Tags: jessie sid
 User: debian...@lists.debian.org
 Usertags: qa-ftbfs-20141108 qa-ftbfs
 Justification: FTBFS in jessie on amd64
 
 Hi,
 
 During a rebuild of all packages in jessie (in a jessie chroot, not a
 sid chroot), your package failed to build on amd64.
 
 The full build log is available from:

 http://aws-logs.debian.net/ftbfs-logs/2014/11/08/canl-java_2.1.1-1_jessie.log

The log for the failing test says:

java.lang.ArrayIndexOutOfBoundsException
at 
sun.security.provider.ByteArrayAccess.i2bBig(ByteArrayAccess.java:319)
at sun.security.provider.SHA2.implDigest(SHA2.java:104)

This is a known bug in openjdk with a know patch that needs backporting.

Patch is attached.

See https://bugzilla.redhat.com/show_bug.cgi?id=1155012 for the same bug
reported in Fedora.
--- openjdk/jdk/src/share/classes/sun/security/provider/SHA2.java	Wed Feb 13 10:40:31 2013 +
+++ openjdk/jdk/src/share/classes/sun/security/provider/SHA2.java	Tue Feb 26 11:12:40 2013 -0800
@@ -1,5 +1,5 @@ 
 /*
- * Copyright (c) 2002, 2012, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2002, 2013, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -101,7 +101,7 @@ 
 i2bBig4((int)bitsProcessed, buffer, 60);
 implCompress(buffer, 0);
 
-i2bBig(state, 0, out, ofs, 32);
+i2bBig(state, 0, out, ofs, engineGetDigestLength());
 }
 
 /**


smime.p7s
Description: S/MIME cryptographic signature

Bug#769266: canl-java: FTBFS in jessie/i386: cp: cannot stat 'target/apidocs': No such file or directory

[Mattias Ellert]

Control: block 769266 by 768747

ons 2014-11-12 klockan 11:44 +0100 skrev Lucas Nussbaum:

 Hi,
 
 During a rebuild of all packages in jessie (in a jessie chroot, not a
 sid chroot), your package failed to build on i386.

As I already explained in the previous bug you reported for the same
issue (bug #768747) this FTBFS is due to a known bug in openjdk-7. There
is nothing to fix in the canl-java source package. You just need to wait
for the openjdk-7 maintainers to fix the bug in their package. If you
want this to be fixed more quickly then say so in your previous bug
report that was reassigned to openjdk-7.

Mattias



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

Bug#731547: Time for binnmu?

[Mattias Ellert]

Dear Debian glib-2.0 maintainers.

It is now more than 3 months since a patch fixing this bug was attached
to this bug report, and there has been no response from you since.

I can offer to upload a binnmu that applies the attached patch to the
latest version of the package in testing. Let me know if this is
something that would be helpful or if it would be disruptive for some
reason.

Mattias



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

Bug#731547: Time for binnmu?

[Mattias Ellert]

mån 2015-01-19 klockan 10:06 +0100 skrev Emilio Pozuelo Monfort:

 You can instead send your patch upstream, so that when the freeze is over and 
 we
 update to a new upstream release, your patch is included for free.

This I have also done 3 months ago. There has not been at response from
upstream either.

https://bugzilla.gnome.org/show_bug.cgi?id=739122

Mattias Ellert



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

Bug#781081: Openssl updates introduces backward incompatibilities - breaks voms

[Mattias Ellert]

Package: libssl1.0.0
Version: 1.0.1k-2, 1.0.1e-2+deb7u15
Severity: important

After updating to the latest openssl versions in Debian, the voms client
tools no longer work.

With the current openssl 1.0.1k-1:

ellert@debian-unstable:~$ voms-proxy-init2 --voms atlas
Enter GRID pass phrase:
Your identity: /DC=org/DC=terena/DC=tcs/C=SE/O=Uppsala University/CN=Mattias 
Ellert mel03...@user.uu.se
Creating temporary proxy 
... Done
Contacting  lcg-voms2.cern.ch:15001 
[/DC=ch/DC=cern/OU=computers/CN=lcg-voms2.cern.ch] atlas Done
Creating proxy 
..
 Done

Your proxy is valid until Tue Mar 24 22:01:16 2015
Error: verify failed.
AC not present in credentials.

ellert@debian-unstable:~$ voms-proxy-info2 --all
WARNING: Unable to verify signature! Server certificate possibly not installed.
Error: AC not present in credentials.
subject   : /DC=org/DC=terena/DC=tcs/C=SE/O=Uppsala University/CN=Mattias 
Ellert mel03...@user.uu.se/CN=proxy
issuer: /DC=org/DC=terena/DC=tcs/C=SE/O=Uppsala University/CN=Mattias 
Ellert mel03...@user.uu.se
identity  : /DC=org/DC=terena/DC=tcs/C=SE/O=Uppsala University/CN=Mattias 
Ellert mel03...@user.uu.se
type  : proxy
strength  : 1024 bits
path  : /tmp/x509up_u1000
timeleft  : 11:59:53
key usage : Digital Signature, Key Encipherment


With the previous openssl 1.0.1k-1:

ellert@debian-unstable:~$ 
LD_LIBRARY_PATH=/home/ellert/openssl-1.0.1k-1/usr/lib/x86_64-linux-gnu 
voms-proxy-init2 --voms atlas
Enter GRID pass phrase:
Your identity: /DC=org/DC=terena/DC=tcs/C=SE/O=Uppsala University/CN=Mattias 
Ellert mel03...@user.uu.se
Creating temporary proxy 
. Done
Contacting  voms2.cern.ch:15001 [/DC=ch/DC=cern/OU=computers/CN=voms2.cern.ch] 
atlas Done
Creating proxy 
..
 Done

Your proxy is valid until Tue Mar 24 22:01:51 2015

ellert@debian-unstable:~$ 
LD_LIBRARY_PATH=/home/ellert/openssl-1.0.1k-1/usr/lib/x86_64-linux-gnu 
voms-proxy-info2 --all
subject   : /DC=org/DC=terena/DC=tcs/C=SE/O=Uppsala University/CN=Mattias 
Ellert mel03...@user.uu.se/CN=proxy
issuer: /DC=org/DC=terena/DC=tcs/C=SE/O=Uppsala University/CN=Mattias 
Ellert mel03...@user.uu.se
identity  : /DC=org/DC=terena/DC=tcs/C=SE/O=Uppsala University/CN=Mattias 
Ellert mel03...@user.uu.se
type  : proxy
strength  : 1024 bits
path  : /tmp/x509up_u1000
timeleft  : 11:59:50
key usage : Digital Signature, Key Encipherment
=== VO atlas extension information ===
VO: atlas
subject   : /DC=org/DC=terena/DC=tcs/C=SE/O=Uppsala University/CN=Mattias 
Ellert mel03...@user.uu.se
issuer: /DC=ch/DC=cern/OU=computers/CN=voms2.cern.ch
attribute : /atlas/Role=NULL/Capability=NULL
attribute : /atlas/lcg1/Role=NULL/Capability=NULL
attribute : /atlas/se/Role=NULL/Capability=NULL
attribute : nickname = ellert (atlas)
timeleft  : 11:59:51
uri   : voms2.cern.ch:15001

Investigations have shown that the problem is introduced by the patch
0003-Free-up-passed-ASN.1-structure-if-reused.patch that was added in
the latest openssl updates 1.0.1k-2 and 1.0.1e-2+deb7u15:

https://sources.debian.net/src/openssl/1.0.1k-2/debian/patches/0003-Free-up-passed-ASN.1-structure-if-reused.patch/
https://sources.debian.net/src/openssl/1.0.1e-2%2Bdeb7u15/debian/patches/0003-Free-up-passed-ASN.1-structure-if-reused.patch/

Mattias Ellert



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

Bug#781081: [Pkg-openssl-devel] Bug#781081: Openssl updates introduces backward incompatibilities - breaks voms

[Mattias Ellert]

tis 2015-03-24 klockan 18:42 +0100 skrev Kurt Roeckx:

  With the current openssl 1.0.1k-1:
 
 I'm not sure what you mean with current 1.0.1k-1 and previous
 1.0.1k-1.  Either it's 1.0.1k-1 or it's not.

This was an unfortunate cut-and-paste error. It should have been the
current 1.0.1k-2 and the previous 1.0.1k-1.

Anyway, thank you for dropping the patch that caused the problems. The
voms clients are working again with openssl 1.0.1k-3.

Mattias



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

Bug#778885: ITP: globus-net-manager -- Globus Toolkit - Network Manager

[Mattias Ellert]

Package: wnpp
Severity: wishlist
Owner: Mattias Ellert mattias.ell...@fysast.uu.se

* Package name: globus-net-manager
  Version : 0.6
* URL : http://www.globus.org/
* License : Apache-2.0
  Description : Globus Toolkit - Network Manager

The Globus Toolkit is an open source software toolkit used for building Grid
systems and applications. It is being developed by the Globus Alliance and
many others all over the world. A growing number of projects and companies are
using the Globus Toolkit to unlock the potential of grids for their cause.

The globus-net-manager package contains:
Network Manager

The Globus Net Manager library is a plug-in point for network management
tasks, such as:
 - selectively open ports in a firewall and allow these ports to be closed
   when transfers are complete
 - configure a virtual circuit based on a site policy and route traffic
   over this circuit
 - route network traffic related to a task over a particular network



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

Bug#731547: Time for nmu?

[Mattias Ellert]

mån 2015-01-19 klockan 10:06 +0100 skrev Emilio Pozuelo Monfort:
 On 19/01/15 09:31, Mattias Ellert wrote:
  Dear Debian glib-2.0 maintainers.
  
  It is now more than 3 months since a patch fixing this bug was attached
  to this bug report, and there has been no response from you since.
  
  I can offer to upload a binnmu that applies the attached patch to the
  latest version of the package in testing. Let me know if this is
  something that would be helpful or if it would be disruptive for some
  reason.
 
 [ You should have Cc'ed glib...@packages.debian.org when reassigning so we 
 would
 have got a copy of your mail. ]
 
 This is only an important bug, affecting hurd, which is not a release
 architecture, and we are in deep freeze. So a NMU (not a binNMU) is not 
 welcome
 at this point.
 
 You can instead send your patch upstream, so that when the freeze is over and 
 we
 update to a new upstream release, your patch is included for free.
 
 Cheers,
 Emilio

The freeze has been lifted. Any chance this can now be fixed?

I can repeat my offer to do an NMU if you prefer to handle it that way.

Mattias



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

Bug#731547: Accepted upstream

[Mattias Ellert]

lör 2015-05-30 klockan 08:17 +0200 skrev Mattias Ellert:
 Hi!
 
 The patch is accepted upstream:
 
 https://git.gnome.org/browse/glib/commit/?id=f7b13e05f9bc5bd2b54f589d
 16ad580f6d833173
 
 Can we now have a Debian build with the patch applied??!!
 
 Mattias

Hi again.

Two weeks without any response...

If noone else is interested in fixing this bug I would be happy to make
an NMU.

Mattias


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

Bug#731547: Accepted upstream

[Mattias Ellert]

mån 2015-06-15 klockan 13:12 +0200 skrev Michael Biebl:
 Am 15.06.2015 um 11:48 schrieb Mattias Ellert:
  lör 2015-05-30 klockan 08:17 +0200 skrev Mattias Ellert:
   Hi!
   
   The patch is accepted upstream:
   
   Can we now have a Debian build with the patch applied??!!
   
   Mattias
  
  Hi again.
  
  Two weeks without any response...
  
  If noone else is interested in fixing this bug I would be happy to 
  make
  an NMU.
 
 This missed 2.45.2 by a couple of days, but it will be part of 
 2.45.3.
 So the next experimental upload will have it.
 
 Thanks,
 Michael
 

Why are you talking about experimental? I didn't say it explicitly, but
I thought it was obvious that the NMU would be to unstable.

If the bug is fixed in experimental it doesn't help when the bug causes
FTBFS in unstable.

Mattias


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

Bug#731547: Accepted upstream

[Mattias Ellert]

Hi!

The patch is accepted upstream:

https://git.gnome.org/browse/glib/commit/?id=f7b13e05f9bc5bd2b54f589d16ad580f6d833173

Can we now have a Debian build with the patch applied??!!

Mattias


smime.p7s
Description: S/MIME cryptographic signature

Bug#788588: fetch-crl: please backport 3.0.16-1 to jessie

[Mattias Ellert]

Source: fetch-crl
Source-Version: 3.0.16-2~bpo8+1

Backported.


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

Bug#731547: Accepted upstream

[Mattias Ellert]

tis 2015-06-23 klockan 15:58 +0200 skrev Emilio Pozuelo Monfort:
 
 I'm really unhappy with this NMU.

This bug was reported 18 months ago, after which not much happened.
This of course was not so surprising since at the time the knowledge of
the source of the problem was sketchy and inconclusive. When I report a
bug I prefer to do so with a bit more information, but at the time I
was not able to analyse it further.

The patch that fixes the bug was attached 8 months ago, and again not
much happened for some time. Neither here nor in the upstream bug. This
I did find very surprising and increasingly frustrating.

Since the two-line, very non-invasive patch was created there has been
4 updates uploaded to Debian unstable, but for some reason the patch
was not integrated in neither of them.

I have on several occasions offered to create an NMU fixing this bug.
Every time - except for this last time - some objection was raised.
These objections mostly said that the bug should be addressed upstream
first. It is of course a good thing to try to fix a bug upstream, but
having the bug fixed upstream is not a prerequisite for fixing the bug
in Debian.

Although I could have argued that the bug not having been fixed
upstream was not a sufficient argument for rejecting the idea of an
NMU, I - in the interest of not stepping on anyone's toes - decided to
wait.

My impression about this bug is that it has induced a lot of emotions
in some people, to the extent that I can not understand. Especially
some of the comments in the upstream bug report were quite inflammatory
and at least to me sounded like trolling attempts to trigger a flame
war. The most outrageous comments I simply ignored.

I somehow by reporting this bug seem to have found myself being caught
in the crossfire in a long-lasting conflict that was not my conflict.
It was not a very nice experience.

After the patch was finally accepted upstream I again asked when this
would be fixed in Debian. When there was no reply I again offered to do
an NMU. Since there was no objection I uploaded one.

 Anyway, that's happened now... Your upload failed to build on a few 
 architectures...
 
 https://buildd.debian.org/status/logs.php?pkg=glib2.0ver=2.44.1-1.1
 
 Emilio

After givebacks the builds have succeeded, except for the two kfreebsd
builds. The kfreebsd builds have consistently failed the previous last
8 versions (2.45.2-1, 2.45.1-2, 2.45.1-1, 2.44.1-1, 2.44.0-3, 2.44.0-2,
2.44.0-1, 2.43.92-1), so that they should suddenly work for this NMU is
not a reasonable idea.

Looking back at the buildd history, the glib2.0 package have failed to
build 1, 2 or - occasionally - 3 architectures (in addition to the
kfreebsd builds mentioned above) for most new uploaded versions for
some time. Which architectures seems quite random and the failures
usually are fixed with givebacks if they happen. The latest NMU has not
done neither better nor worse than previous versions here. Nor was it
expected to.

Best regards,

Mattias


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

Bug#745475: broken auto-removal logic

[Mattias Ellert]

tor 2014-11-20 klockan 08:14 +0100 skrev Julien Cristau:
 On Wed, Nov 19, 2014 at 07:23:28 +0100, Mattias Ellert wrote:
 
  I would like to propose to increase the severity of this bug back 
  to
  serious. I find it extremely disruptive.
  
 No, this bug is very much not serious.
 
 Cheers,
 Julien

I strongly disagree with this assessment.

This happens again and again and again. It is very far from very much
not serious.

Mattias


smime.p7s
Description: S/MIME cryptographic signature

Bug#804536: gcc-5: [mips,mipsel] regression in optimization causes FTBFS for gsoap

[Mattias Ellert]

Package: gcc-5
Version: 5.2.1-23
Severity: serious
Justification: causes gsoap to FTBFS
Control: affects -1 gsoap
Control: block 804455 by -1
X-Debbugs-Cc: debian-m...@lists.debian.org

Hi!

The binnmu of gsoap 2.8.22-1 due to the openssl transition failed on
mips and mipsel, but succeeded on the other architectures.

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

(It also succeeded on mip64le - but the mips64el build used gcc-5
5.2.1-21 while mips and mipsel used 5.2.1-23. I am not sure if this is
relevant information.)

The failure is a segmentation fault when running the soapcpp2 binary
that has been compiled as part of the build. The soapcpp2 binary is not
linked to openssl, so the issue is not due to the new openssl library
that triggered the binnmu rebuild.

I can reproduce the failure on the eder.debian.org porterbox.

However, if I on the porterbox reduce the optimization from -O2 to -O1,
the build succeeds. This therefore looks like a regression in
mips/mipsel optimization.

Mattias Ellert



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

Bug#807686: Do not modify the debian control files during package build

[Mattias Ellert]

Package: maven-debian-helper
Version: 2.0
Severity: important

The files in the debian control directory should not be modified during
the build of a debian package, or in extreme cases when it can not be
avoided any such modifications must be reverted during debian/rules
clean, so that when the package build is run a second time it will do
the same thing as when run the first time.

Packages using debian-maven-helper currently does not follow this basic
rule because it makes a call to mh_resolve_dependencies as part of the
dh_auto_install invokation.

This call to mh_resolve_dependencies brings havoc and destruction to
several files in the debian directory. It modifies the debian/*.poms
file - which is not at all helpful. It adds rules that not make sense
to the debian/maven.rules and other debian/maven.*Rules files, and even
creates these when they were not previously present. This means that a
lot of the efforts spent on creating these files when making the
package are lost when the package is built, and you have to remember to
restore your work from the debian.tar.xz file before iterating the
build again.

In addition to this the call to mh_resolve_dependencies generates a lot
of entries on the debian/*.substvars file. Most of these make no sense
when mh_resolve_dependencies is run as part of a package build. The
author of the tool is aware of this since the first line in the
debian/*.substvars file it creates is a comment saying these lines
should be copied by hand to the debian/control file. This manual step
is not part of the package build, so the only thing these entries do is
generate warnings about unused tags in the debian/*.substvars file
during the build.

The one entry that makes a bit of sense is the ${maven:Depends} tag,
which could be used to add some dependencies to the binary packages.
However, this tag is not very well implemented since it lumps all the
dependencies of all binary packages as dependencies to the first binary
package that is built by the source package, and no dependencies to the
others. (The first package is usually the parent package that has no
runtime dependencies at all.) It also does not add internal
dependencies between the different binary packages being built by the
source package.

So the call to mh_resolve_dependencies has a huge set of bad unhealthy
side effects, and the one little thing that makes sense of all the
things it does it does rather poorly. So can the call to
mh_resolve_dependencies be dropped from the set of commands run by
dh_auto_install? Possibly it could be replaced with a call to another
tool that creates the ${maven:Depends} tags only and nothing else, and
in a better way than the broken way currently done by
mh_resolve_dependencies.

Calling mh_resolve_dependencies makes some sense from a tool that
creates a set of template files like e.g. mh_make, but once the
templates have been created it should not be called again, since this
will undo any effort by the maintainer of cleaning up the templates of
thing that are not needed or useful for this particular package.

I managed to create a hack in some packages I recently converted to use
maven-debian-helper so that the call to mh_resolve_dependencies was
replace by a no-op, but should such hacks be needed in order for the
package to work as expected?

Mattias


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

Bug#807686: Do not modify the debian control files during package build

[Mattias Ellert]

fre 2015-12-11 klockan 16:58 +0100 skrev Markus Koschany:
> 
> Hi,
> 
> could you provide an example package where maven-debian-helper
> modifies
> files in your debian directory? What helper tools (dh, cdbs, pure
> debhelper) and compat level do you use?
> 
> Thanks,
> 
> Markus

Hi!

When I converted my Debian Java packages from mvn-debian, I used dh.
All of them are affected by this issue:

canl-java
jglobus
voms-api-java
voms-clients-java

So you can look at any one of them.

They all have a workaround implemented: there is a dummy
debian/mh_resolve_dependencies script that does either nothing or only
touches a debian/*.substvars file, and there is a
override_dh_auto_install rule that changes the PATH during the
dh_auto_install call so that the call to mh_resolve_dependencies gets
replaced with a call to this dummy script.

override_dh_auto_install: 
PATH=$(CURDIR)/debian:$${PATH} dh_auto_install 

This way the packages work fine.

If the workaround is removed, then after you have run dpkg-buildpackage 
once, these files have been modified or overwritten:

debian/*.poms
debian/maven.rules
debian/maven.ignoreRules

and these files not present in the original source package have been
created:

debian/maven.publishedRules
debian/maven.cleanIgnoreRules

These changes are not reverted by debian/rules clean, so if you run
dpkg-buildpackage again the packages would be built using a different
set of rules than during the first build - which makes the packages
broken.

The debian/compat says "5", because this is what it was before I
converted the packages to use dh - and there were no indications from
lintian that this would not be sufficient. Changing the debian/compat
to "9" doesn't change anything - mh_resolve_dependencies is still
called during the build and the same breakage occurs.

In the code in /usr/share/perl5/Debian/Debhelper/Buildsystem/maven.pm -
which is installed by the maven-debian-helper package:

In the "sub install" the first $this->doit_in_builddir calls maven to
do the installation - this part you really want.

The very next line is another call to $this->doit_in_builddir which
calls mh_resolve_dependencies and is the one that brings havoc and
destruction.

There are no conditionals in the code here that makes it possible to
have to call to maven without the call to mh_resolve_dependencies, so
there doesn't seem to be any why to make the breakage not happen except
for hacks like the one I used.

Removing the call to mh_resolve_dependencies would be a way to fix it:

$ diff -ur maven.pm~ maven.pm
--- maven.pm~   2015-12-11 14:47:56.0 +0100
+++ maven.pm2015-12-16 16:20:02.28000 +0100
@@ -108,11 +108,7 @@
    "-Dmaven.repo.local=$this->{cwd}/debian/maven-repo",
    "-Dinstall.to.usj=true",
    
"org.debian.maven:debian-maven-plugin:$maven_debian_version:install");
-   $this->doit_in_builddir("mh_resolve_dependencies", "--non-interactive",
-   "--offline", "-p$this->{package}", @resolvedep_args);
    if ($this->{doc_package}) {
-   doit("cp","debian/$this->{package}.substvars",
-   "debian/$this->{doc_package}.substvars");
    # clean up generated docs
    $this->doit_in_builddir("rm", "-f", "target/apidocs/*.sh",
    "target/apidocs/options");


Mattias


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

Bug#804536: gcc-5: [mips,mipsel] regression in optimization causes FTBFS for gsoap

[Mattias Ellert]

tis 2015-11-10 klockan 15:50 +0100 skrev Aurelien Jarno:
> 
> Bug submitted upstream as PR68273.

Hi!

How should I handle this? Will there be a solution to the gcc bug
within a not too distant future, or is this likely to remain broken for
many months? Not an easy question to answer I imagine.

If it is likely to remain broken for a long time, should I work around
it and upload an update that adds -fno-ipa-sra to the compiler flags
used to compile the package? Or should it be left as it is?

Mattias


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

Bug#805441: Pull request available upstream

[Mattias Ellert]

forwarded 805441 https://github.com/lvc/abi-compliance-checker/pull/32
tags 805441 patch
thanks

A pull request addressing this a available in github.


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

Bug#805441: abi-compliance-checker no longer works on hurd

[Mattias Ellert]

Package: abi-compliance-checker
Version: 1.99.11-1
Severity: important
Control: affects -1 davix
X-Debbugs-Cc: debian-h...@lists.debian.org

A recent binnmu of davix 0.4.1-2+b1 failed on hurd due to abi-
compliance-checker

https://buildd.debian.org/status/fetch.php?pkg=davix=hurd-i386=0.4.1-2%2Bb1=1446837812

This build used abi-compliance-checker 1.99.11-1, and the error is:

cd /«PKGBUILDDIR»/obj-i586-gnu/dist && abi/check_abi.sh
Generate  new ABI dump
ERROR: can't check ARCH type

The original build of davix 0.4.1-2 worked fine on hurd

https://buildd.debian.org/status/fetch.php?pkg=davix=hurd-i386=0.4.1-2=1439491408

This build used abi-compliance-checker 1.99.9-2, and the log says:

cd /«PKGBUILDDIR»/obj-i586-gnu/dist && abi/check_abi.sh
Generate  new ABI dump
Using GCC 5.2.1 (i586-gnu)
checking header(s) 0.4.1 ...
WARNING: can't find 'ctags' program
creating library ABI dump ...
library ABI has been dumped to:
  /«PKGBUILDDIR»/obj-i586-gnu/abi_dump_last.abi.tar.gz
you can transfer this dump everywhere and use instead of the 0.4.1
version descriptor
Compare to previous ABI dump
Finish !

Retrying the build on a porter box with the latest abi-compliance-
checker 1.99.14-1 gives the same error.

Running the check using the old abi-compliance-checker 1.99.9-2 on the
porter box still works. But you can of course not use that trick on a
buildd.

Mattias


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

Bug#805637: ITP: nordugrid-arc-nagios-plugins -- Nagios plugins for ARC

[Mattias Ellert]

Package: wnpp
Severity: wishlist
Owner: Mattias Ellert <mattias.ell...@fysast.uu.se>

* Package name    : nordugrid-arc-nagios-plugins
  Version : 1.8.4
* URL : http://www.nordugrid.org
* License : Apache-2.0
  Description : Nagios plugins for ARC

 This package provides the Nagios plugins for testing ARC computing
 elements.


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

Bug#805619: ITP: nordugrid-arc-gangliarc -- Ganglia monitoring for ARC services

[Mattias Ellert]

Package: wnpp
Severity: wishlist
Owner: Mattias Ellert <mattias.ell...@fysast.uu.se>

* Package name    : nordugrid-arc-gangliarc
  Version : 1.0.0
* URL : http://wiki.nordugrid.org/index.php/Gangliarc
* License : Apache-2.0
  Description : Ganglia monitoring for ARC services

gangliarc provides a way to monitor ARC services through an existing ganglia
installation. Running gangliarc adds various ARC metrics to ganglia which can
then be viewed along with regular ganglia metrics for the ARC host.


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

Bug#805441: Pull request available upstream

[Mattias Ellert]

lör 2015-12-19 klockan 23:54 +0100 skrev Mattias Ellert:
> A pull request addressing this a available in github.

The pull request has now been merged upstream.
Unfortunately this happened after the new release (1.99.16) was tagged,
so if/when you update to the new release - please consider backporting
the fix for this bug.

Mattias



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

Bug#804405: Wrong bug number.

[Mattias Ellert]

reopen 804405
notfixed 804405 gsoap/2.8.22-2
thanks

Sorry, I made a typo in the Closes in the changelog. It should have
been 804455, not 804405

Mattias


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

Bug#805441: Fix released upstream

[Mattias Ellert]

The latest upstream release 1.99.17 fixes this bug.

Mattias


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

Bug#805441: Fix released upstream

[Mattias Ellert]

ons 2016-03-16 klockan 12:57 +0100 skrev Mattias Ellert:
> The latest upstream release 1.99.17 fixes this bug.

Are there any plans to update this package soon? If there isn't I can
offer to do an NMU to fix this bug. Such an NMU would make the minimal
change, i.e. backport the two-line-patch that fixes this bug to the
current Debian version, and not update the package to a new upstream
release.

Mattias


smime.p7s
Description: S/MIME cryptographic signature

Bug#829272: [openssl.org #4602] Missing accessors

[Mattias Ellert]

tor 2016-07-21 klockan 09:51 + skrev Richard Levitte via RT:
> On Thu Jul 21 08:18:30 2016, mattias.ell...@physics.uu.se wrote:
> > 
> > ons 2016-07-20 klockan 15:14 + skrev Richard Levitte via RT:
> > > 
> > > On Mon Jul 11 11:34:35 2016, mattias.ell...@physics.uu.se wrote:
> > > > 
> > > > 
> > > > I guess having a more restrictive accessor that only sets the
> > > > EXFLAG_PROXY bit could work. I suggested the more general
> > > > solution
> > > > of
> > > > having set/clear accessors for arbitrary flags since it was -
> > > > well
> > > > more
> > > > general.
> > > 
> > > So let me ask this in a different manner, does OpenSSL 1.1 still
> > > not
> > > set the
> > > EXFLAG_PROXY flag correctly? In what situations does that happen?
> > > That may be
> > > worth a bug report of its own.
> > > 
> > > --
> > > Richard Levitte
> > > levi...@openssl.org
> > > 
> > 
> > The answer to this is related to Mischa's reply, which
> > unfortunately
> > was only sent to the Debian BTS and not the the OpenSSL RT. I quote
> > it
> > below. As indicated in the answer, setting the EXFLAG_PROXY allows
> > handling non-RFC proxies in OpenSSL.
> > 
> > mån 2016-07-11 klockan 14:53 +0200 skrev Mischa Salle:
> > > 
> > > Hi Richard, Mattias, others,
> > > 
> > > I agree with you that it would be nice if OpenSSL could figure
> > > out
> > > itself whether a cert needs to be treated as a proxy, but
> > > currently
> > > that
> > > doesn't work reliably as far as I know.
> > > The flag is certainly needed in the case of non-RFC3820 proxies,
> > > also
> > > known as legacy proxies. Unfortunately these are still very
> > > widely
> > > used
> > > (majority of the proxies actually) and hence our code must be
> > > able to
> > > handle them correctly.
> > > 
> > > Best wishes,
> > > Mischa Sallé
> > > 
> 
> Ok... From looking at the voms code that was linked to earlier, I can
> see that
> legacy proxy certs are recognised by an older OID (called
> PROXYCERTINFO_V3 in
> the code), 1.3.6.1.4.1.3536.1.222. Is there a spec for the extensions
> in that
> version, whether they are critical or not and so on, that I can
> reach? Or is
> the OID the only actual difference? If it's easy enough (and it
> currently does
> look quite easy), I can certainly see adding some code in OpenSSL to
> recognise
> those...
> 
> --
> Richard Levitte
> levi...@openssl.org

As far as I know there are three different kinds of proxies, usually
called "legacy", "draft" and "rfc", or sometimes version 2, 3 and 4
respectively.

For example see "grid-proxy-init -help":

    -draftCreates a draft (GSI-3) proxy
-old  Creates a legacy globus proxy
-rfc  Creates a RFC 3820 compliant proxy

The really tricky one is the old legacy version 2 proxy I think.

Mattias


smime.p7s
Description: S/MIME cryptographic signature

Bug#829272: [openssl.org #4602] Missing accessors

[Mattias Ellert]

ons 2016-07-20 klockan 15:14 + skrev Richard Levitte via RT:
> On Mon Jul 11 11:34:35 2016, mattias.ell...@physics.uu.se wrote:
> > 
> > I guess having a more restrictive accessor that only sets the
> > EXFLAG_PROXY bit could work. I suggested the more general solution of
> > having set/clear accessors for arbitrary flags since it was - well
> > more
> > general.
> 
> So let me ask this in a different manner, does OpenSSL 1.1 still not set the
> EXFLAG_PROXY flag correctly? In what situations does that happen? That may be
> worth a bug report of its own.
> 
> --
> Richard Levitte
> levi...@openssl.org
> 

The answer to this is related to Mischa's reply, which unfortunately
was only sent to the Debian BTS and not the the OpenSSL RT. I quote it
below. As indicated in the answer, setting the EXFLAG_PROXY allows
handling non-RFC proxies in OpenSSL.

mån 2016-07-11 klockan 14:53 +0200 skrev Mischa Salle:
> Hi Richard, Mattias, others,
> 
> I agree with you that it would be nice if OpenSSL could figure out
> itself whether a cert needs to be treated as a proxy, but currently that
> doesn't work reliably as far as I know.
> The flag is certainly needed in the case of non-RFC3820 proxies, also
> known as legacy proxies. Unfortunately these are still very widely used
> (majority of the proxies actually) and hence our code must be able to
> handle them correctly.
> 
> Best wishes,
> Mischa Sallé
> 


smime.p7s
Description: S/MIME cryptographic signature

Bug#830299: voms-api-java: FTBFS: Could not resolve dependencies for project org.italiangrid:voms-api-java:jar:3.2.0

[Mattias Ellert]

reassign 830299 src:cglib
affects 830299 src:voms-api-java
forcemerge 830204 830299
thanks

I can not reproduce this failure.
Looking at the difference between my successful build log from pbuilder
and the attached log I see that the version of libcglib-java used
changed from 3.2.3-2 to 3.2.3-3. The changelog entry for cglib 3.2.3-3
says:

  * Make the ant dependency really optional (Closes: #830204)

Given that the error reported in the attached log is:

Cannot access central (https://repo.maven.apache.org/maven2) in offline
mode and the artifact org.apache.ant:ant:jar:debian has not been
downloaded from it before.

And that I can not reproduce the failure with the updated libcglib-
java, I merge this bug with #830204.

Mattias

fre 2016-07-08 klockan 00:50 +0200 skrev Chris Lamb:
> Source: voms-api-java
> Version: 3.2.0-1
> Severity: serious
> Justification: fails to build from source
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
> 
> Dear Maintainer,
> 
> voms-api-java fails to build from source in unstable/amd64:
> 
> 
> The full build log is attached.
> 
> 
> Regards,
> 


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

Bug#829272: [openssl.org #4602] Missing accessors

[Mattias Ellert]

fre 2016-07-08 klockan 00:42 +0200 skrev Kurt Roeckx:
> On Thu, Jul 07, 2016 at 09:40:24PM +, Richard Levitte via RT
> wrote:
> > On Sat Jul 02 10:59:38 2016, k...@roeckx.be wrote:
> > > /* Add to include/openssl/x509v3.h */
> > > 
> > > void X509_set_extension_flags(X509 *x, uint32_t ex_flags);
> > > void X509_clear_extension_flags(X509 *x, uint32_t ex_flags);
> > > 
> > > 
> > > /* Add to crypto/x509v3/v3_purp.c */
> > > 
> > > void X509_set_extension_flags(X509 *x, uint32_t ex_flags)
> > > {
> > > x->ex_flags |= ex_flags;
> > > }
> > > 
> > > void X509_clear_extension_flags(X509 *x, uint32_t ex_flags)
> > > {
> > > x->ex_flags &= ~ex_flags;
> > > }
> > 
> > This gives me the heebie jeebies. ex_flags is used a lot
> > internally, and I
> > can't begin to imagine the consequences of letting external code
> > manipulate
> > this. I understand that in some cases, it seems easy and quick,
> > but...
> > 
> > So, if someone else wants to have a go at this and can make
> > something sensible,
> > please be my guest. Me, I'm backing off from this particular idea.
> 
> Mattias,
> 
> Can you explain why this is needed, what the code is trying to do?
> 
> 
> Kurt
> 

Hi!

The modification of the extension flags happens in at least four
different packages. The modification they do is to add the EXFLAG_PROXY
bit to the flags.

https://sources.debian.net/src/globus-gsi-callback/5.8-2/library/globus_gsi_callback.c/#L692

https://sources.debian.net/src/voms/2.0.13-1/src/sslutils/sslutils.c/#L1665
https://sources.debian.net/src/voms/2.0.13-1/src/sslutils/sslutils.c/#L1740

https://sources.debian.net/src/canl-c/2.1.6-2/src/proxy/sslutils.c/#L1655
https://sources.debian.net/src/canl-c/2.1.6-2/src/proxy/sslutils.c/#L1719

https://sources.debian.net/src/nordugrid-arc/5.1.2-1/src/hed/libs/credential/CertUtil.cpp/#L184

I guess having a more restrictive accessor that only sets the
EXFLAG_PROXY bit could work. I suggested the more general solution of
having set/clear accessors for arbitrary flags since it was - well more
general.

Mattias Ellert


smime.p7s
Description: S/MIME cryptographic signature

Bug#829272: [openssl.org #4602] Missing accessors

[Mattias Ellert]

fre 2016-07-08 klockan 06:08 + skrev Richard Levitte via RT:
> On Thu Jul 07 21:29:09 2016, levitte wrote:
> > On Sat Jul 02 10:59:38 2016, k...@roeckx.be wrote:
> > > /* Add to include/openssl/x509_vfy.h : */
> > > 
> > > typedef int (*X509_STORE_CTX_get_issuer)(X509 **issuer,
> > > X509_STORE_CTX
> > > *ctx, X509 *x);
> > > typedef int (*X509_STORE_CTX_check_issued)(X509_STORE_CTX *ctx,
> > > X509
> > > *x, X509 *issuer);
> > > 
> > > void X509_STORE_CTX_set_get_issuer(X509_STORE_CTX *ctx,
> > > X509_STORE_CTX_get_issuer
> > > get_issuer);
> > > X509_STORE_CTX_get_issuer
> > > X509_STORE_CTX_get_get_issuer(X509_STORE_CTX
> > > *ctx);
> > > void X509_STORE_CTX_set_check_issued(X509_STORE_CTX *ctx,
> > > X509_STORE_CTX_check_issued
> > > check_issued);
> > > X509_STORE_CTX_check_issued
> > > X509_STORE_CTX_get_check_issued(X509_STORE_CTX *ctx);
> > 
> > For this part, https://github.com/openssl/openssl/pull/1294
> 
> So, looking at this again after some sleep, there's a part of this
> solution
> that I'm unsure of, and it all comes back to X509_STORE_CTX_init(),
> where the
> X509_STORE context gets initialised from the X509_STORE, including
> all the
> function pointers. This has me wonder if the X509_STORE_CTX setters
> should
> really be made available (perhaps with the exception of the verify
> and
> verify_cb ones). Doesn't it make more sense to set those function
> pointers when
> creating the X509_STORE itself? Why would those functions need to be
> changed in
> the context?
> 
> Cheers,
> Richard
> 
> --
> Richard Levitte
> levi...@openssl.org
> 

Looking at the various places in the code where get_issuer
and check_issued are accessed, they mostly use the context rather than
the store. Here are the places I have found:

https://sources.debian.net/src/nordugrid-arc/5.1.2-1/src/hed/libs/credential/CertUtil.cpp/#L71

https://sources.debian.net/src/canl-c/2.1.6-2/src/proxy/sslutils.c/#L1581

https://sources.debian.net/src/voms/2.0.13-1/src/sslutils/sslutils.c/#L1588

https://sources.debian.net/src/globus-gsi-callback/5.8-2/library/globus_gsi_callback.c/#L367

https://sources.debian.net/src/globus-gsi-callback/5.8-2/library/globus_gsi_callback.c/#L1059

https://sources.debian.net/src/globus-gsi-credential/7.9-2/library/globus_gsi_cred_handle.c/#L1997

And the following one actually uses the store and not the context:

https://sources.debian.net/src/globus-gssapi-gsi/12.1-1/library/globus_i_gsi_gss_utils.c/#L448

Mattias



smime.p7s
Description: S/MIME cryptographic signature

Bug#829272: Missing accessors

[Mattias Ellert]

Package: openssl
Version: 1.1.0~pre5-4
Severity: important
Control: block 828316 by -1
Control: block 828318 by -1
Control: block 828595 by -1

Hi!

I got a lot of bugs filed about packages FTBFS with openssl 1.1.0.
I started to look at some of them, and many of them are due too
structures having been made opaque. In many cases accessors already
exists, but definitely not for all.

Here is a list of accessors I so far have identified as missing. The
filenames given in the "Add to ..." comments below are suggestions
based on where similar functions are defined and implemented.


/* Add to include/openssl/x509_vfy.h : */

typedef int (*X509_STORE_CTX_get_issuer)(X509 **issuer, X509_STORE_CTX *ctx, 
X509 *x);
typedef int (*X509_STORE_CTX_check_issued)(X509_STORE_CTX *ctx, X509 *x, X509 
*issuer);

void X509_STORE_CTX_set_get_issuer(X509_STORE_CTX *ctx,
   X509_STORE_CTX_get_issuer get_issuer);
X509_STORE_CTX_get_issuer X509_STORE_CTX_get_get_issuer(X509_STORE_CTX *ctx);
void X509_STORE_CTX_set_check_issued(X509_STORE_CTX *ctx,
 X509_STORE_CTX_check_issued check_issued);
X509_STORE_CTX_check_issued X509_STORE_CTX_get_check_issued(X509_STORE_CTX 
*ctx);


/* Add to crypto/x509/x509_vfy.c : */

void X509_STORE_CTX_set_get_issuer(X509_STORE_CTX *ctx,
   X509_STORE_CTX_get_issuer get_issuer)
{
ctx->get_issuer = get_issuer;
}

X509_STORE_CTX_get_issuer X509_STORE_CTX_get_get_issuer(X509_STORE_CTX *ctx)
{
return ctx->get_issuer;
}

void X509_STORE_CTX_set_check_issued(X509_STORE_CTX *ctx,
 X509_STORE_CTX_check_issued check_issued)
{
ctx->check_issued = check_issued;
}

X509_STORE_CTX_check_issued X509_STORE_CTX_get_check_issued(X509_STORE_CTX *ctx)
{
return ctx->check_issued;
}


/* Add to include/openssl/x509v3.h */

void X509_set_extension_flags(X509 *x, uint32_t ex_flags);
void X509_clear_extension_flags(X509 *x, uint32_t ex_flags);


/* Add to crypto/x509v3/v3_purp.c */

void X509_set_extension_flags(X509 *x, uint32_t ex_flags)
{
x->ex_flags |= ex_flags;
}

void X509_clear_extension_flags(X509 *x, uint32_t ex_flags)
{
x->ex_flags &= ~ex_flags;
}


Regarding the new locking. Do I understand it correctly that e.g.

  CRYPTO_w_lock(CRYPTO_LOCK_X509_STORE);

should be replaced by something like

  CRYPTO_THREAD_write_lock(X509_STORE_get_lock(ctx));

But then the accessors to get hold of the lock objects in the opaque
structs are missing. E.g.

/* Add to some header file */

CRYPTO_RWLOCK *X509_STORE_get_lock(X509_STORE *ctx);

/* Add to some implementation file */

/* Add to crypto/x509/x509_lu.c */

CRYPTO_RWLOCK *X509_STORE_get_lock(X509_STORE *v)
{
return v->lock;
}

Repeat for other relevant classes with locks.

Mattias


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

Bug#854211: Assertion triggered when voms libraries and globus libraries are used together

[Mattias Ellert]

Source: voms
Version: 2.1.0~rc0-1
Severity: important

See the upstream discussion here for more details:
https://github.com/italiangrid/voms/issues/50

The old OID for the proxy certificate extension used to implement the
pre-rfc (or draft) proxies is not defined in the openssl library, but
must be added using OBJ_create. The voms library triggers an assertion
if this creation fails. This works fine if the voms library is the only
thing that tries to define this extension.

However, if an other library that also defines this OID - such as the
globus libraries - is used in the same process the assertion is
triggered. This affects e.g. the lcmaps voms plugin and the voms
support in myproxy.

Mattias


smime.p7s
Description: S/MIME cryptographic signature

Bug#854263: unblock: voms/2.1.0~rc0-2

[Mattias Ellert]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal

voms/2.1.0~rc0-2 closes #854211.

When the voms library is used together with the globus libraries a
assertion was triggered in the previous version (voms/2.1.0~rc0-1). The
updated version (voms/2.1.0~rc0-2) resolves this issue.

This restores e.g. the the voms support in the myproxy package.

Mattias


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

Bug#834958: canl-java: FTBFS too much often (failing tests)

[Mattias Ellert]

In the two logs attached the failing tests say

Linear duration: 7089ms, 282.1272393849626ops
Parallel duration: 5528ms, 361.794500723589ops

and

Linear duration: 6150ms, 325.2032520325203ops
Parallel duration: 4639ms, 431.1273981461522ops

respectively. I.e. the ratios are

7089/5528 = 1.282
6150/4639 = 1.325

The test fails if the ratio is less than 1.4. I don't know what the
origin of the value 1.4 is.

I can not reproduce the problem locally on my machine. I suspect the
actual values of the ratio varies between different hardware and that
1.4 was a value that the upstream developers chose based on the
machines they have run the tests on.

I have forwarded the bug report upstream:

https://github.com/eu-emi/canl-java/pull/89

Mattias


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

Bug#834958: canl-java: FTBFS too much often (failing tests)

[Mattias Ellert]

mån 2016-08-22 klockan 10:21 +0200 skrev Santiago Vila:
> On Mon, 22 Aug 2016, Mattias Ellert wrote:
> 
> > 
> > I can not reproduce the problem locally on my machine.
> 
> Please try building on a virtual machine having only 1 CPU.
> 
> Apparently the test suite assumes that parallel should be faster than
> linear, but this does not have to be the case at all when you have
> only one CPU.
> 
> Debian packages should not assume that there is more than 1 CPU
> available. We have Build-Depends, but we don't have Build-CPUs,
> because everything which may be built with more than one CPU
> may also be built with only one CPU.
> 
> Thanks.

My Debian installation is a virtual machine using one CPU, so this is
the setup I always use for local builds. The build has never failed for
me on it. Running multiple threads on the one CPU is still faster than
running a single thread.

Mattias


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

Bug#847459: RM: canl-c++ -- ROM; package will not be ported to OpenSSL 1.1.0

[Mattias Ellert]

Package: ftp.debian.org
Severity: normal

Upstream has decided to discontinue support for the package rather than
port it to OpenSSL 1.1.0.

According to apt-rdepends no packages depend on the package (other than
the binary packages built from the same source package).

# apt-rdepends -r libcanl-c++1v5 python-canl
Reading package lists... Done
Building dependency tree   
Reading state information... Done
libcanl-c++1v5
  Reverse Depends: libcanl-c++1-dbg (= 1.1.0-2+b1)
  Reverse Depends: libcanl-c++1-dev (= 1.1.0-2+b1)
  Reverse Depends: python-canl (= 1.1.0-2+b1)
libcanl-c++1-dbg
libcanl-c++1-dev
python-canl
  Reverse Depends: libcanl-c++1-dbg (= 1.1.0-2+b1)

We would therefore like to ask for the package to be removed.

Mattias and Anders
Maintainer/Uploader of the package


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

Bug#828236: openssl 1.1 and apache2

[Mattias Ellert]

Hi!

The httpd package in Fedora (which is the package that corresponds to
the apache2 package in Debian) is now built against OpenSSL 1.1:

http://pkgs.fedoraproject.org/cgit/rpms/httpd.git/

https://koji.fedoraproject.org/koji/buildinfo?buildID=817612

Could the same patch be used in Debian?

Mattias


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

Bug#849717: Wrong return value from pthread_mutex_trylock

[Mattias Ellert]

Source: libc0.3-dev
Version: 2.24-8
Severity: important

According to the documentation (man page) for pthread_mutex_trylock:

The pthread_mutex_trylock() function shall be equivalent to
pthread_mutex_lock(), except that if the mutex object referenced by
mutex is currently locked (by any thread, including the current
thread), the call shall return immediately.

RETURN VALUE
  The pthread_mutex_trylock() function shall fail if:

  EBUSY  The mutex could not be acquired because it was already locked.

Here is a short test program


#include 
#include 
#include 

int main() {
  pthread_mutex_t m;
  int i;
  printf("%s: %i\n", "EBUSY", EBUSY);
  printf("%s: %i\n", "EAGAIN", EAGAIN);

  i = pthread_mutex_init(, NULL);
  printf("%s: %i\n", "init", i);
  i = pthread_mutex_lock();
  printf("%s: %i\n", "lock", i);
  i = pthread_mutex_trylock();
  printf("%s: %i\n", "trylock", i);
  i = pthread_mutex_unlock();
  printf("%s: %i\n", "unlock", i);
  i = pthread_mutex_destroy();
  printf("%s: %i\n", "destroy", i);
}


On Linux this behaves according to the documentation:

EBUSY: 16
EAGAIN: 11
init: 0
lock: 0
trylock: 16
unlock: 0
destroy: 0

I.e. the trylock on the already locked mutex returns EBUSY.

On Hurd the following happens:

EBUSY: 1073741840
EAGAIN: 1073741859
init: 0
lock: 0
trylock: -1
unlock: 0
destroy: 0

I.e. the trylock on the already locked mutex returns -1 instead.

This causes programs using GLib to abort execution:

GLib (gthread-posix.c): Unexpected error from C library during
'pthread_mutex_trylock': Error in unknown error system: . 
Aborting.
Aborted

Mattias


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

Bug#858907: unblock: canl-c/2.1.8-1

[Mattias Ellert]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal

The 2.1.8 release is a security fix that addresses a vulnerability
found in the previous release.

Debdiff from the current version in testing 2.1.7-3 is attached.

No other changes than addressing the vulnerability is part of the new
release. The upstream changelog entry for the release (as can be seen
in the attached debdiff) is:

2.1.8-1
- Security fix to verify certificates properly (EGI RT #12276):
  - Treat untrusted certificates properly in proxy_verify_cert_chain()
  - Override only openssl errors relevant to X.509 handling

Mattias
diff -Nru canl-c-2.1.7/ChangeLog canl-c-2.1.8/ChangeLog
--- canl-c-2.1.7/ChangeLog	2016-08-19 10:20:47.0 +0200
+++ canl-c-2.1.8/ChangeLog	2017-02-23 22:16:26.0 +0100
@@ -135,3 +135,7 @@
 2.1.7-1
 - Quick fix to prevent RFC Proxy DN forgery (RT #11476)
 
+2.1.8-1
+- Security fix to verify certificates properly (EGI RT #12276):
+  - Treat untrusted certificates properly in proxy_verify_cert_chain()
+  - Override only openssl errors relevant to X.509 handling
diff -Nru canl-c-2.1.7/debian/changelog canl-c-2.1.8/debian/changelog
--- canl-c-2.1.7/debian/changelog	2016-12-23 15:14:18.0 +0100
+++ canl-c-2.1.8/debian/changelog	2017-03-22 15:56:11.0 +0100
@@ -1,3 +1,9 @@
+canl-c (2.1.8-1) unstable; urgency=medium
+
+  * Update to version 2.1.8
+
+ -- Mattias Ellert <mattias.ell...@physics.uu.se>  Wed, 22 Mar 2017 15:56:11 +0100
+
 canl-c (2.1.7-3) unstable; urgency=medium
 
   * Reverse the order of conditional dependencies
diff -Nru canl-c-2.1.7/debian/control canl-c-2.1.8/debian/control
--- canl-c-2.1.7/debian/control	2016-12-23 15:13:43.0 +0100
+++ canl-c-2.1.8/debian/control	2017-03-22 15:56:11.0 +0100
@@ -4,7 +4,7 @@
 Maintainer: Mattias Ellert <mattias.ell...@physics.uu.se>
 Build-Depends: debhelper, bison, flex, libc-ares-dev, libkrb5-dev, libssl1.0-dev | libssl-dev (<< 1.1), libtool, libtool-bin, pkg-config, texlive-fonts-recommended, texlive-latex-extra, texlive-latex-recommended
 Standards-Version: 3.9.8
-Homepage: http://www.eu-emi.eu/
+Homepage: https://github.com/CESNET/canl-c
 
 Package: libcanl-c2
 Section: libs
diff -Nru canl-c-2.1.7/debian/copyright canl-c-2.1.8/debian/copyright
--- canl-c-2.1.7/debian/copyright	2016-08-25 11:30:50.0 +0200
+++ canl-c-2.1.8/debian/copyright	2017-03-22 15:54:02.0 +0100
@@ -1,7 +1,7 @@
 Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: canl-c
 Upstream-Contact: CESNET Product Teams <emi...@metacentrum.cz>
-Source: http://scientific.zcu.cz/emi/emi.canl.c/canl-c-2.1.7.tar.gz
+Source: http://scientific.zcu.cz/emi/emi.canl.c/canl-c-2.1.8.tar.gz
 
 Files: *
 Copyright: 2004-2011 Members of the EGEE Collaboration
@@ -26,7 +26,7 @@
  PURPOSE.
 
 Files: debian/*
-Copyright: 2013-2016 Mattias Ellert
+Copyright: 2013-2017 Mattias Ellert
 License: Apache-2.0
 
 License: Apache-2.0
diff -Nru canl-c-2.1.7/project/version.properties canl-c-2.1.8/project/version.properties
--- canl-c-2.1.7/project/version.properties	2016-08-19 10:20:47.0 +0200
+++ canl-c-2.1.8/project/version.properties	2017-02-23 22:16:26.0 +0100
@@ -1,3 +1,3 @@
 # $Header:
-module.version=2.1.7
+module.version=2.1.8
 module.age=1
diff -Nru canl-c-2.1.7/src/proxy/sslutils.c canl-c-2.1.8/src/proxy/sslutils.c
--- canl-c-2.1.7/src/proxy/sslutils.c	2016-08-19 10:20:46.0 +0200
+++ canl-c-2.1.8/src/proxy/sslutils.c	2017-02-23 22:16:26.0 +0100
@@ -1934,20 +1934,7 @@
  }
 #endif
 
-#if OPENSSL_VERSION_NUMBER >= 0x1000L
-case X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE:
-  /*
-   * OpenSSL 1.0 causes the cert to be added twice to 
-   * the store.
-   */
-  if (proxy_check_proxy_name(ctx->cert) && 
-  !X509_cmp(ctx->cert, ctx->current_cert))
-ok = 1;
-  break;
-#endif
-
 case X509_V_ERR_INVALID_CA:
-case X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT:
   /*
* This may happen since proxy issuers are not CAs
*/
@@ -1966,14 +1953,6 @@
   }
   break;
 
-case X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY:
-case X509_V_ERR_CERT_UNTRUSTED:
-  if (proxy_check_proxy_name(ctx->current_cert) > 0) {
-/* Server side, needed to fully recognize a proxy. */
-ok = 1;
-  }
-  break;
-
 #ifdef X509_V_ERR_PROXY_CERTIFICATES_NOT_ALLOWED
 case X509_V_ERR_PROXY_CERTIFICATES_NOT_ALLOWED:
   /* Proxies ARE allowed */
@@ -2291,50 +2270,26 @@
 X509_STORE *cert_store = NULL;
 X509_LOOKUP *   lookup = NULL;
 X509_STORE_CTX  csc;
-X509 *  xcert = NULL;
-X509 * 

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

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#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#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#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#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#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]

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#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#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#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#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#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#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]

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]

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#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#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#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#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]

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