Bug#928172: fixing debian-security-support upgrades from stretch (for good)

[Niels Thykier]

Sean Whitton:
> Hello,
> 
> On Mon 13 May 2019 at 11:52AM +00, Holger Levsen wrote:
> 
>> [re-sent with debian-release list address corrected...]
> 
> Also resending.  Sorry.
> 
>> so there is "#928172 debian-security-support: fails to upgrade from 
>> 'testing':
>> dpkg: error: error executing hook" which happens when base-files is upgraded
>> before debian-security-support (but doesnt happen if d-s-s is upgraded 
>> first...)
>>
>> So I think this can only be fixed properly (=without asking people to
>> upgrade to the latest stretch pointrelease but instead allowing upgrades
>> to buster from *any* stretch pointrelease) by adding a "pre-depends:
>> debian-security-support (>= 2019.04.25)" to base-files in buster.
> 
> I didn't think we supported upgrades from anything but the latest point
> release of the previous stable release?
> 
> My belief is based on the release notes saying that you should upgrade
> to the latest point relesae first.
> 

My understanding is that we prefer that upgrade paths works regardless
of which minor version of the stable release you upgrade from (to the
extend possible).

Thanks,
~Niels

Processed: gpg-agent READKEY emits an invalid S-expression when private key file has comment (on 64-bit big-endian platforms)

[Debian Bug Tracking System]

Processing control commands:

> found -1 2.2.13-1
Bug #928963 [gpg-agent] gpg-agent READKEY emits an invalid S-expression when 
private key file has comment (on 64-bit big-endian platforms)
Marked as found in versions gnupg2/2.2.13-1.
> found -1 2.2.14-1
Bug #928963 [gpg-agent] gpg-agent READKEY emits an invalid S-expression when 
private key file has comment (on 64-bit big-endian platforms)
Marked as found in versions gnupg2/2.2.14-1.
> found -1 2.2.15-1
Bug #928963 [gpg-agent] gpg-agent READKEY emits an invalid S-expression when 
private key file has comment (on 64-bit big-endian platforms)
Marked as found in versions gnupg2/2.2.15-1.
> affects -1 src:monkeysphere
Bug #928963 [gpg-agent] gpg-agent READKEY emits an invalid S-expression when 
private key file has comment (on 64-bit big-endian platforms)
Added indication that 928963 affects src:monkeysphere
> tags -1 patch upstream
Bug #928963 [gpg-agent] gpg-agent READKEY emits an invalid S-expression when 
private key file has comment (on 64-bit big-endian platforms)
Added tag(s) patch and upstream.
> forwarded -1 https://dev.gnupg.org/T4501
Bug #928963 [gpg-agent] gpg-agent READKEY emits an invalid S-expression when 
private key file has comment (on 64-bit big-endian platforms)
Set Bug forwarded-to-address to 'https://dev.gnupg.org/T4501'.

-- 
928963: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928963
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#928963: gpg-agent READKEY emits an invalid S-expression when private key file has comment (on 64-bit big-endian platforms)

[Daniel Kahn Gillmor]

Package: gpg-agent
Severity: serious
Version: 2.2.12-1
Control: found -1 2.2.13-1
Control: found -1 2.2.14-1
Control: found -1 2.2.15-1
Control: affects -1 src:monkeysphere
Control: tags -1 patch upstream
Control: forwarded -1 https://dev.gnupg.org/T4501

On sparc64, powerpc64, and s390x (debian's three 64-bit big-endian
platforms), gpg is unable to create a new OpenPGP certificate from some
secret keys that it already knows about.

In particular, "gpg --batch --generate" from a Key-Grip: line that
refers to a key file in private-keys-v1.d/ that contains a comment
sublist will fail with "Invalid S-expression" on those platforms.

This is due to a buggy invocation of gcry_sexp_build_array that is only
tickled when int is smaller than size_t and the platform is big-endian,
which causes the comment string to be set to zero length, which itself
is interpreted as an error of GPG_ERR_SEXP_ZERO_PREFIX.

However, this failure causes necessary functionality for
"monkeysphere-host import-key" as of monkeysphere version 0.43-3 to
break on these platforms, making monkeysphere FTBFS because the failure
is caught by its test suite.

The attached patch resolves the issue when i test it on
zelenka.debian.org (s390x), and should also work on the other two
platforms.

--dkg

From e4a158faacd67e15e87183fb48e8bd0cc70f90a8 Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor 
Date: Tue, 14 May 2019 00:05:42 -0400
Subject: [PATCH] agent: correct length for uri and comment on 64-bit
 big-endian platforms

* agent/findkey.c (agent_public_key_from_file): pass size_t as int to
gcry_sexp_build_array's %b.

--

This is only a problem on big-endian systems where size_t is not the
same size as an int.  It was causing failures on debian's s390x,
powerpc64, and sparc64 platforms.

There may well be other failures with %b on those platforms in the
codebase, and it probably needs an audit.

Once you have a key in private-keys-v1.d/$KEYGRIP.key with a comment
or a uri of reasonable length associated with it, this fix can be
tested with:

   gpg-agent --server <<<"READKEY $KEYGRIP"

On the failing platforms, the printed comment will be of length 0.

Gnupg-bug-id: 4501
Signed-off-by: Daniel Kahn Gillmor 
---
 agent/findkey.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/agent/findkey.c b/agent/findkey.c
index 755a90be1..20c9dc56a 100644
--- a/agent/findkey.c
+++ b/agent/findkey.c
@@ -1366,6 +1366,7 @@ agent_public_key_from_file (ctrl_t ctrl,
   gcry_sexp_t uri_sexp, comment_sexp;
   const char *uri, *comment;
   size_t uri_length, comment_length;
+  int uri_intlen, comment_intlen;
   char *format, *p;
   void *args[2+7+2+2+1]; /* Size is 2 + max. # of elements + 2 for uri + 2
 for comment + end-of-list.  */
@@ -1447,14 +1448,16 @@ agent_public_key_from_file (ctrl_t ctrl,
 {
   p = stpcpy (p, "(uri %b)");
   assert (argidx+1 < DIM (args));
-  args[argidx++] = (void *)_length;
+  uri_intlen = (int)uri_length;
+  args[argidx++] = (void *)_intlen;
   args[argidx++] = (void *)
 }
   if (comment)
 {
   p = stpcpy (p, "(comment %b)");
   assert (argidx+1 < DIM (args));
-  args[argidx++] = (void *)_length;
+  comment_intlen = (int)comment_length;
+  args[argidx++] = (void *)_intlen;
   args[argidx++] = (void*)
 }
   *p++ = ')';
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#928505: fixed in ruby-pygments.rb 1.2.0-4

[dai]

Hi,

On Sun, May 12, 2019 at 09:55:33PM +0530, Pirate Praveen wrote:
> We will have to file an unblock request for this to migrate to testing.
> Can you file it?

sorry for my afk, but thanks to release team (maybe), it migrated to testing.
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: PGP signature

Bug#927126: aqemu: after updating can't open VMs

[Abhijith PA]

On 29/04/19 1:22 am, Alexis Murzeau wrote:
> The vlan argument issue has a upstream issues open [0].
> 
> [0] :
>  - https://github.com/tobimensch/aqemu/issues/58
>  - https://github.com/tobimensch/aqemu/issues/57

The error log in issue 57 is same as what I get.

>  - https://github.com/tobimensch/aqemu/pull/61

Yes, please
https://github.com/tobimensch/aqemu/pull/61/commits/9ff55188fb8479e573d6ed6f5669147af48316a9
try to backport this patch. I can help you in testing.


--abhijith

Bug#927126: aqemu: after updating can't open VMs

[Abhijith PA]

On 14/05/19 4:02 am, Alexis Murzeau wrote:
> Le 28/04/2019 à 21:52, Alexis Murzeau a écrit :

...

> As this package is going to be removed if nothing happen, I will try to
> backport a patch from upstream forks.
> popcon indicate that is really used (while I don't use it myself), and
> might be more used given virtualbox was removed from buster [0].
> 
> 
> [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794466
> 

Yes, please go ahead I can help you with testing.

Bug#927126: aqemu: after updating can't open VMs

[Abhijith PA]

Hi, I missed this mail somehow. Sorry for the late reply


On 29/04/19 1:22 am, Alexis Murzeau wrote:
> On Mon, 15 Apr 2019 16:55:13 +0530 Abhijith PA  wrote:
>> I recently updated aqemu and ended up in not able to open VMs.
>>
>> Following is the message is what I get when I open VMs
>>
>> AQEMU Error [264] >>>
>> Sender: QEMU return value != 0
>> Message:
>>
> 
> Hi,
> 
> When you right-click on your VM and choose "Show QEMU Arguments", what
> are the arguments of qemu ?
> If you try to run the command directly in a console, does it works ?
> If not, what's the qemu error ?
> 
> I tried myself and got errors about the vlan option.
> This option seems to be deprecated since a long time and removed now.

Yes, I can manually run vm when those arguments (removing vlan) are copied.

> The vlan argument issue has a upstream issues open [0].
> 
> [0] :
>  - https://github.com/tobimensch/aqemu/issues/58
>  - https://github.com/tobimensch/aqemu/issues/57
>  - https://github.com/tobimensch/aqemu/pull/61
> 

Bug#914034: Bug#911938: libhttp-daemon-ssl-perl FTBFS: tests fail: Connection refused

[Steffen Ullrich]

> Ah I see, thanks for the clarification.  I thought you meant it could
> yield a deadlock.  Aren't temporary failures also possible on plain
> sockets (though of course the extra SSL layer make it strictly more
> likely to happen)?  IIRC if the checksum of the incoming packet
> mismatches, which causes the read() call to block until the packet is
> retransmitted.

select only shows an fd ready  if data are available for read in the socket
buffer. Data with wrong checksum are discarded by the kernel before they are
put into the socket buffer and thus don't cause select to show it ready for
read.

select(2) explicitly says:

  A file descriptor is considered ready if it is possible to perform a
  corresponding I/O operation (e.g., read(2)  without blocking ...

> > And while using blocking I/O with polling sockets might be fine with plain
> > sockets where each byte is part of application data it is not fine with SSL
> > since the unit in SSL is not a byte but a record and some records might
> > contain application data and some not.
>
> Why is that not fine, if the SSL_read() caller is ready for that (documented)
> outcome, and doesn't assume that the call will always block until some
> application data is received?

IO::Socket::SSL is intended as abstraction which behaves as much as possible
as other IO::Socket classes. It is not intended that the developer has to be
familiar with the exact semantics of SSL_read (which also changed over
time, especially with OpenSSL 1.1.0 and again with OpenSSL 1.1.1). While it
is impossible to behave in exactly all cases sysread is usually not expect
to return a temporary error on a blocking socket.

> Then I don't get it.  AFAICT the current documentation reflects what
> happens with blocking sockets and OpenSSL <1.1.1a, namely that
> IO::Socket::SSL::sysread() returns undef when the TLS ≤1.2 session is
> renegotiated.  Are you saying that the intention was to keep retrying
> (either Perl-side, or within SSL_read() via SSL_MODE_AUTO_RETRY with
> OpenSSL ≥0.9.6) until application data is received or a fatal error is
> encountered?

Yes, the intention was to reflect as much as possible what is expected from
IO::Socket::sysread and not what the SSL_read documentation says.

> Not anything using IO::Socket::SSL, I'm afraid.  I'm personally more
> used to the lower-level APIs like libssl and Net::SSLeay.  For libssl in
> particular, a quick codesearch returns a few prominent programs that
> reverted the new OpenSSL default.

For applications using lower level libraries it is perfectly fine to follow
changes in the behavior in these lower level libraries. The idea behind
higher level abstractions is that this does not need to be done, i.e. it
should hide lower level implementation details and just continue to work. It
is not always possible but at least one can try.

> Anyway this bug can probably be closed now, maybe we should follow up
> elsewhere.  Thanks for the discussion & analysis!

Thank You too. Regards,
Steffen

Bug#928172: fixing debian-security-support upgrades from stretch (for good)

[Sean Whitton]

Hello,

On Mon 13 May 2019 at 11:32AM +00, Holger Levsen wrote:

> so there is "#928172 debian-security-support: fails to upgrade from 'testing':
> dpkg: error: error executing hook" which happens when base-files is upgraded
> before debian-security-support (but doesnt happen if d-s-s is upgraded 
> first...)
>
> So I think this can only be fixed properly (=without asking people to
> upgrade to the latest stretch pointrelease but instead allowing upgrades
> to buster from *any* stretch pointrelease) by adding a "pre-depends:
> debian-security-support (>= 2019.04.25)" to base-files in buster.

I didn't think we supported upgrades from anything but the latest point
release of the previous stable release?

My belief is based on the release notes saying that you should upgrade
to the latest point relesae first.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#928172: fixing debian-security-support upgrades from stretch (for good)

[Sean Whitton]

Hello,

On Mon 13 May 2019 at 11:52AM +00, Holger Levsen wrote:

> [re-sent with debian-release list address corrected...]

Also resending.  Sorry.

> so there is "#928172 debian-security-support: fails to upgrade from 'testing':
> dpkg: error: error executing hook" which happens when base-files is upgraded
> before debian-security-support (but doesnt happen if d-s-s is upgraded 
> first...)
>
> So I think this can only be fixed properly (=without asking people to
> upgrade to the latest stretch pointrelease but instead allowing upgrades
> to buster from *any* stretch pointrelease) by adding a "pre-depends:
> debian-security-support (>= 2019.04.25)" to base-files in buster.

I didn't think we supported upgrades from anything but the latest point
release of the previous stable release?

My belief is based on the release notes saying that you should upgrade
to the latest point relesae first.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#928429: dpkg: trigger cycle postgresql-common -> sgml-base while upgrading from stretch to buster

[Guillem Jover]

Hi!

On Fri, 2019-05-10 at 21:45:09 +0200, Andreas Beckmann wrote:
> On 2019-05-09 06:00, Guillem Jover wrote:
> > awaiting trigger does not help matters, I'm not entirely sure this
> > might not be still a problem with dpkg itself. :/
> 
> I can also reproduce the problem in stretch -> sid upgrades, so in case
> you need to fix dpkg I can verify that before it migrates to testing.

Thanks for the detailed log! Ok, I think I've got a patch now, and it
still passes the functional test suite. Would it be possible and easy
to test that with the failing piuparts runs? Otherwise I'll try to
setup some chroot somewhere to do that.

I'm attaching the patch. Otherwise already built (and signed) binary
packages can be temporarily found at:

  

Thanks,
Guillem
From a333d52e9f7f99951a89b2b61a5f6807d6fb678c Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Mon, 13 May 2019 03:36:03 +0200
Subject: [PATCH] dpkg: Introduce a new dependency try level for trigger cycle
 checks

This new dependtry level will also check trigger cycles on trigger
process deferral due to unsatisfiable dependencies.

Closes: #928429
---
 debian/changelog |  3 +++
 src/main.h   | 13 +
 src/trigproc.c   |  8 +---
 3 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 3d97a0111..2a0615f36 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -6,6 +6,9 @@ dpkg (1.19.7) UNRELEASED; urgency=medium
   * dpkg: Set the force defaults before loading the config file, otherwise we
 incorrectly override them. Regression introduced in dpkg 1.19.5.
 Closes: #928671
+  * dpkg: Split the trigger dependtry into two, the second of which will be
+the one checking trigger cycles when deferring trigger processing due to
+unsatisfiable dependencies. Closes: #928429
 
   [ Updated programs translations ]
   * Catalan (Guillem Jover).
diff --git a/src/main.h b/src/main.h
index e4a251969..7f341303e 100644
--- a/src/main.h
+++ b/src/main.h
@@ -234,18 +234,23 @@ void deferred_configure(struct pkginfo *pkg);
  *   Start processing triggers if necessary.
  *   Do as for try 2.
  *
- * Try 4 (only if --force-depends-version):
+ * Try 4:
+ *   Same as for try 3, but check trigger cycles even when deferring
+ *   processing due to unsatisfiable depedencies.
+ *
+ * Try 5 (only if --force-depends-version):
  *   Same as for try 2, but don't mind version number in dependencies.
  *
- * Try 5 (only if --force-depends):
+ * Try 6 (only if --force-depends):
  *   Do anyway.
  */
 enum dependtry {
 	DEPEND_TRY_NORMAL = 1,
 	DEPEND_TRY_CYCLES = 2,
 	DEPEND_TRY_TRIGGERS = 3,
-	DEPEND_TRY_FORCE_DEPENDS_VERSION = 4,
-	DEPEND_TRY_FORCE_DEPENDS = 5,
+	DEPEND_TRY_TRIGGERS_CYCLES = 4,
+	DEPEND_TRY_FORCE_DEPENDS_VERSION = 5,
+	DEPEND_TRY_FORCE_DEPENDS = 6,
 	DEPEND_TRY_LAST,
 };
 
diff --git a/src/trigproc.c b/src/trigproc.c
index 59e30d143..54b15bbe1 100644
--- a/src/trigproc.c
+++ b/src/trigproc.c
@@ -407,9 +407,11 @@ trigproc(struct pkginfo *pkg, enum trigproc_type type)
 
 		ok = dependencies_ok(pkg, NULL, );
 		if (ok == DEP_CHECK_DEFER) {
-			gaveup = check_trigger_cycle(pkg);
-			if (gaveup == pkg)
-return;
+			if (dependtry >= DEPEND_TRY_TRIGGERS_CYCLES) {
+gaveup = check_trigger_cycle(pkg);
+if (gaveup == pkg)
+	return;
+			}
 
 			varbuf_destroy();
 			enqueue_package(pkg);
-- 
2.21.0.1020.gf2820cf01a

Bug#928959: papi: DFSG-unfree file in source

[Sean Whitton]

Source: papi
Version: 5.7.0-1
Severity: serious

At least one file in this package fails to permit derivative works:

spwhitton@iris:~/tmp/papi>head -n15 src/components/appio/tests/iozone/fileop.c
/*
 * Author: Don Capps
 * 3/13/2006
 *
 *   Author: Don Capps (ca...@iozone.org)
 *   7417 Crenshaw
 *   Plano, TX 75025
 *
 *  Copyright 2006, 2007, 2008, 2009   Don Capps.
 *
 *  License to freely use and distribute this software is hereby granted
 *  by the author, subject to the condition that this copyright notice
 *  remains intact.  The author retains the exclusive right to publish
 *  derivative works based on this work, including, but not limited to,
 *  revised versions of this work",

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#914034: Bug#911938: libhttp-daemon-ssl-perl FTBFS: tests fail: Connection refused

[Guilhem Moulin]

On Mon, 13 May 2019 at 22:24:55 +0200, Steffen Ullrich wrote:
> On Mon, May 13, 2019 at 03:18:14PM +0200, Guilhem Moulin  
> wrote:
>> Uh, what?  “Before” meaning with ≤TLSv1.2, or with OpenSSL <1.1.1a's
>> default flags?  libssl mentions no such thing beside the new default
>> mode.  And in fact the s_client() program, *from OpenSSL upstream
>> itself*, does precisely that: a select loop in blocking I/O mode (unless
>> the ‘-nbio’ flag is set).
> 
> "Before" meaning already with previous OpenSSL versions. But the effect was
> likely hard to notice: an incomplete SSL record would not cause a permanent
> hang but only a blocking read until the rest of the data was received, i.e.
> only some slow down in some situations.

Ah I see, thanks for the clarification.  I thought you meant it could
yield a deadlock.  Aren't temporary failures also possible on plain
sockets (though of course the extra SSL layer make it strictly more
likely to happen)?  IIRC if the checksum of the incoming packet
mismatches, which causes the read() call to block until the packet is
retransmitted.

> And while using blocking I/O with polling sockets might be fine with plain
> sockets where each byte is part of application data it is not fine with SSL
> since the unit in SSL is not a byte but a record and some records might
> contain application data and some not.

Why is that not fine, if the SSL_read() caller is ready for that (documented)
outcome, and doesn't assume that the call will always block until some
application data is received?

>> The documentation (libssl's SSL_read()'s [0], Net::SSLeay::read() [1],
>> as well as IO::Socket::SSL::sysread() [2]) all warn that reading from an
>> SSL socket has a different behavior than usual read(2) system calls, in
>> that read failures should be treated with care, as there are both
>> retryable (eg. when no application data was received) and non-retryable
>> errors.
> 
> As I was the one who wrote the documentation for IO::Socket::SSL: the part
> about sysread failing was supposed to be about non-blocking sockets. A
> blocking socket was not expected to return nothing just because the
> handshake was not done.

Then I don't get it.  AFAICT the current documentation reflects what
happens with blocking sockets and OpenSSL <1.1.1a, namely that
IO::Socket::SSL::sysread() returns undef when the TLS ≤1.2 session is
renegotiated.  Are you saying that the intention was to keep retrying
(either Perl-side, or within SSL_read() via SSL_MODE_AUTO_RETRY with
OpenSSL ≥0.9.6) until application data is received or a fatal error is
encountered?
 
> Do you know a relevant module or actually used application which has
> problems because of the default mode of SSL_MODE_AUTO_RETRY the ability to
> change it would fix the related problems and not introduce new ones, i.e.
> where such a fix would be the right thing to do?

Not anything using IO::Socket::SSL, I'm afraid.  I'm personally more
used to the lower-level APIs like libssl and Net::SSLeay.  For libssl in
particular, a quick codesearch returns a few prominent programs that
reverted the new OpenSSL default.

  Apache2's mod_ssl:
Bug:https://github.com/openssl/openssl/issues/7178
Commit: 
https://github.com/apache/httpd/commit/6ee9d597e01281f2ef2e146586129af6aed7854d#diff-b70bd458eb699e70c322ee797a3e0991

  Neon:
File:   
http://svn.webdav.org/repos/projects/neon/tags/0.30.2/src/ne_socket.c
Change: 
http://lists.manyfish.co.uk/pipermail/neon-commits/2018-September/001077.html
  
  YottaDB
Bug: 
https://github.com/YottaDB/YDB/commit/1d0a8943d8be24a6f3dd3e4d2c8bfaad1fb75c87

> Another option might be to have an option SSL_mode_auto_retry which by
> default is not set but might be set to either 0 or 1 to get a consistent
> behavior across different OpenSSL versions.

I quite like this approach :-)

Anyway this bug can probably be closed now, maybe we should follow up
elsewhere.  Thanks for the discussion & analysis!
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#926180: scilab: FTBFS on all - New trouble

[Alexis Murzeau]

Le 13/05/2019 à 08:08, Sylvestre Ledru a écrit :
> 
> On 12/05/2019 22:10, Julien Puydt wrote:
>> Hi,
>>
>> On 12/05/2019 11:46, Alexis Murzeau wrote:
>>
>>> I saw that there is a bugfix release 6.0.2 with many fixes [0].
>> I had started to package 6.0.2 on salsa already in february. I removed
>> the patch about Linenum as that was supposed to have been reworked and
>> fixed, and it now fails with :
>>
>> ocamlopt -o XML2Modelica -I ./src/modelica_compiler -I
>> ./src/xml2modelica  nums.cmxa ./src/xml2modelica/xMLTree.ml
>> ./src/xml2modelica/linenum.ml ./src/xml2modelica/stringParser.ml
>> ./src/xml2modelica/stringLexer.ml ./src/xml2modelica/xMLParser.ml
>> ./src/xml2modelica/xMLLexer.ml
>> ./src/xml2modelica/modelicaCodeGenerator.ml
>> ./src/xml2modelica/xML2Modelica.ml
>> File "./src/xml2modelica/xML2Modelica.ml", line 1:
>> Error: Files ./src/xml2modelica/xMLParser.cmx
>>and ./src/xml2modelica/linenum.cmx
>>make inconsistent assumptions over implementation Linenum
>>
>> ie : it looks like upstream's fix isn't correct.
> 
> + upstream
> 
> S
> 
> 

Reversing the order of the includes parameters when compiling
XML2Modelica fix the build for me, ie. including xml2modelica first:
`-I ./src/xml2modelica -I ./src/modelica_compiler`

I think ocamlopt prefer to use a part of Linenum from
./src/modelica_compiler and the other one from ./src/xml2modelica which
lead to the error.

But I'm not sure this is the way to handle it cleanly.
The files "linenum.mll" are almost the same between both directories.
The only difference is the comment at the beginning of the file.

Maybe some of these "linenum.mll" file can be removed to keep only one ?

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F

Bug#927126: aqemu: after updating can't open VMs

[Alexis Murzeau]

Le 28/04/2019 à 21:52, Alexis Murzeau a écrit :
> On Mon, 15 Apr 2019 16:55:13 +0530 Abhijith PA  wrote:
>> I recently updated aqemu and ended up in not able to open VMs.
>>
>> Following is the message is what I get when I open VMs
>>
>> AQEMU Error [264] >>>
>> Sender: QEMU return value != 0
>> Message:
>>
> 
> Hi,
> 
> When you right-click on your VM and choose "Show QEMU Arguments", what
> are the arguments of qemu ?
> If you try to run the command directly in a console, does it works ?
> If not, what's the qemu error ?
> 
> I tried myself and got errors about the vlan option.
> This option seems to be deprecated since a long time and removed now.
> 
> The vlan argument issue has a upstream issues open [0].
> 
> [0] :
>  - https://github.com/tobimensch/aqemu/issues/58
>  - https://github.com/tobimensch/aqemu/issues/57
>  - https://github.com/tobimensch/aqemu/pull/61
> 

As this package is going to be removed if nothing happen, I will try to
backport a patch from upstream forks.
popcon indicate that is really used (while I don't use it myself), and
might be more used given virtualbox was removed from buster [0].


[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794466
-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F



signature.asc
Description: OpenPGP digital signature

Bug#928488: marked as done (pyspf-milter fails to start on minmal system)

[Debian Bug Tracking System]

Your message dated Mon, 13 May 2019 22:04:03 +
with message-id 
and subject line Bug#928488: fixed in spf-engine 2.9.0-4
has caused the Debian Bug report #928488,
regarding pyspf-milter fails to start on minmal system
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
928488: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928488
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: pyspf-milter
Version: 2.9.0-3
Severity: serious
Justification: Policy 3.5

# /usr/bin/pyspf-milter
Traceback (most recent call last):
  File "/usr/bin/pyspf-milter", line 6, in 
from pkg_resources import load_entry_point
ModuleNotFoundError: No module named 'pkg_resources'

Missing depends on python3-pkg-resources.

Scott K
--- End Message ---
--- Begin Message ---
Source: spf-engine
Source-Version: 2.9.0-4

We believe that the bug you reported is fixed in the latest version of
spf-engine, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 928...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Scott Kitterman  (supplier of updated spf-engine package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 05 May 2019 18:07:33 -0400
Source: spf-engine
Binary: postfix-policyd-spf-python pyspf-milter python3-spf-engine
Architecture: source all
Version: 2.9.0-4
Distribution: unstable
Urgency: medium
Maintainer: Scott Kitterman 
Changed-By: Scott Kitterman 
Description:
 postfix-policyd-spf-python - Postfix policy server for SPF checking
 pyspf-milter - Modern milter for SPF checking
 python3-spf-engine - Sender Policy Framework (SPF) processing module
Closes: 928487 928488
Changes:
 spf-engine (2.9.0-4) unstable; urgency=medium
 .
   * Fix missing depends on python3-pkg-resources:
 - For postfix-policyd-spf-python (Closes: #928487)
 - For pyspf-milter (Closes: #928488)
Checksums-Sha1:
 4bd7dd799e733b1f415b592b6176e46612c255a5 2166 spf-engine_2.9.0-4.dsc
 ee0235305e0d09cf05b0807410d645cd334e9174 9292 spf-engine_2.9.0-4.debian.tar.xz
 8159298df403f8d921b0775dc04f79ed3fc86368 36152 
postfix-policyd-spf-python_2.9.0-4_all.deb
 5d302b9659b9f2eed5ac31de522cc3fcc650979d 21732 pyspf-milter_2.9.0-4_all.deb
 5e43abf9e031860be2a185908755bbeb57d1ddc8 26720 
python3-spf-engine_2.9.0-4_all.deb
 e28ce829d79af9cffdac1e58e88e6bd532ae7794 6353 
spf-engine_2.9.0-4_amd64.buildinfo
Checksums-Sha256:
 97765f2584c0085eace7ff201a8869c0d621f36024a69177513a138a0af69882 2166 
spf-engine_2.9.0-4.dsc
 c9a554be2a8cf86e5527df67476d14798a16150f97e7151e81b560ebc292a4bb 9292 
spf-engine_2.9.0-4.debian.tar.xz
 5c4791e9fb144ec6e8d7b7a6777e4bba358620f792f9bbd81889ea99972c0082 36152 
postfix-policyd-spf-python_2.9.0-4_all.deb
 5ccf55006e601e3a7fbaeb488945dc797d8c833ddff40e36ac4fd0aff349c477 21732 
pyspf-milter_2.9.0-4_all.deb
 ba1a07f0457bedf6ff5868a4d257b1e26344e619dd9120d5b60f3c54d8122241 26720 
python3-spf-engine_2.9.0-4_all.deb
 2feb41cee163d938fc447b2aaa2cfdf2e554d7f2370c7a716edace63a57111b4 6353 
spf-engine_2.9.0-4_amd64.buildinfo
Files:
 a61f866cf8f13c3beeb60a08042abde8 2166 mail optional spf-engine_2.9.0-4.dsc
 f260aa9c1849cb48bcfb03d4d6c73321 9292 mail optional 
spf-engine_2.9.0-4.debian.tar.xz
 d51745bfe09c9229a215d405ed93c09d 36152 mail optional 
postfix-policyd-spf-python_2.9.0-4_all.deb
 fe85c4ffebedf766ef61998dabcc93f5 21732 mail optional 
pyspf-milter_2.9.0-4_all.deb
 4381f8b85883d71716334b9ecf271aa0 26720 python optional 
python3-spf-engine_2.9.0-4_all.deb
 47c267cf6aeb1a80144dfa60fb0326c4 6353 mail optional 
spf-engine_2.9.0-4_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE53Kb/76FQA/u7iOxeNfe+5rVmvEFAlzZ5T4ACgkQeNfe+5rV
mvFYahAAs+uobPBp7USjSQIM5o2zchBTE6n/St8R/DHBJ+gcKRu0fpoGFlO7oCfN
qqjmKNJaCbtDKyGjAKrOhzaaLmEPOIfNrvnnyw7iqlialxx1E5HmiUsO2v6EWzsH
4rpxbTmmaChfmGzGoNS6TUtWLDP1eSI1s1u0EnCMkRQIaK/NvAsw5h2OYf3ED51R
bK/nzvoQ56JO4o3sk1cp+KoqP7B42K9x9jsRYvkHqWM37uToCe5J9XHLhJSpKaL4
YdnmAjs/JPb/4bKIQ9xfgca5tl7AAyMskWi7+cjwsykwDu8BuW7OwXxotQ2ceNG3
ZMRFrhiv0FZ5tpshi15fPyR5KM46/5iaDeA68x757USxntVxg7UyM6fyKquELVms
O21vFLMJYA1LZHEPahwwfJIQRn6QOFqeJlsYnHzZGnUUIvF6rT0XiccHVnlLsKKB

Bug#926180: scilab: FTBFS on all - baseline violation?

[Rebecca N. Palmer]

Given that the error is "Illegal instruction", and reproducibly happens 
on x86-bm-01 and not the other machines we've tried, could it be 
something assuming CPU features more recent than the amd64 baseline?


If so, it's not obvious where: scilab does contain some C/C++ code (as 
well as Java), but there aren't any asm() or __builtin_ia32* calls in 
it, or any -march options in the build log.  Maybe it's in a dependency, 
not scilab itself?


There is an open "illegal instruction crash in Xcos" bug upstream, which 
may or may not be related: 
https://bugzilla.scilab.org/show_bug.cgi?id=11003#c6


Alexis Murzeau wrote:

will such bug-fix upstream release be accepted in
buster, now that we are in full freeze ?


Generally not: Debian prefers not to fix minor bugs during freeze 
because this might accidentally create major ones.

https://release.debian.org/buster/freeze_policy.html

Bug#928204: check-support-status: cannot create /var/lib/debian-security-support/security-support.semaphore: Directory nonexistent

[Santiago Vila]

Way to reproduce it:

1. Install package in the *host* machine:
# apt-get install debian-security-support

2. Enter a sid chroot where debian-security-support has never been installed:
# schroot -c sid

3. Install package inside the chroot:
# apt-get install debian-security-support

The postinst blindly assumes that if the user debian-security-support
exists, then /var/lib/debian-security-support should also exist:

if ! getent passwd "$USERNAME" > /dev/null; then
   adduser \
   [...]
   --home "$LIB_DIR" \
   [...]
   "$USERNAME"
fi

But schroot by default copies /etc/passwd from the host machine (where
the user already exists) inside the chroot, breaking the assumption.

Maybe the patch below is enough to fix this.

Thanks.

--- a/debian/debian-security-support.postinst
+++ b/debian/debian-security-support.postinst
@@ -20,6 +20,11 @@ configure)
 "$USERNAME"
 fi
 
+if [ ! -d "$LIB_DIR" ]; then
+  mkdir "$LIB_DIR"
+  chown $USERNAME:$USERNAME "$LIB_DIR"
+fi
+
 if [ "$TMPDIR" ] && [ "$(stat --format=%a "$TMPDIR")" != '1777' ] ; then
 export TMPDIR='/tmp'
 fi

Bug#928957: expiration task fails on non-existent files

[Eduard Bloch]

Package: apt-cacher-ng
Version: 3.2-1
Severity: serious

This bug is basically reminder to myself and not to whoever runs into
this issue.

Looks like apt-cacher-ng expiery manages to maneuver itself into a state
which cannot be recovered. It reports non-existent files from apparently
guessed sources, like:

Error summary:
debrep/dists/jessie/main/installer-amd64/current/images/SHA256SUMS: 404 Not 
Found
debrep/dists/stretch/main/installer-amd64/20170615+deb9u5+b2/images/SHA256SUMS: 
404 Not Found
localhost/ftp.de.debian.org/debian/dists/stretch/main/installer-amd64/20170615+deb9u5+b2/images/SHA256SUMS:
 404 Not Found
localhost/ftp.de.debian.org/debian/dists/stretch/main/installer-amd64/20170615/images/SHA256SUMS:
 404 Not Found

I have a vague idea where it comes from (old heuristics which fetched
voluntarily additional metadata which was not well linked in old Debian
versions, like 10 years ago). This needs to be investigated (digging
through history) and probably removed, or fixed.

-- Package-specific info:

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Bug#928204: lower severity

[Cyril Brulebois]

HoLger,

Holger Levsen  (2019-05-13):
> severity 928204 important
> tags 928204 unreproducible moreinfo
> # thanks
> 
> Kibi,
> 
> #928204 is the bug with the title "check-support-status: cannot create 
> /var/lib/debian-security-support/security-support.semaphore: Directory
> nonexistent"...
> 
> how did you create that chroot? is maybe apparmor involved (in a way
> thats not the default? (guessing based on the hostname in your log.)

debootstrap; I'm running with apparmor=1 but that has absolutely 0
things to do with the hostname (https://en.wikipedia.org/wiki/Armorica).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#927934: marked as done (bind9: CVE-2018-5743: Limiting simultaneous TCP clients is ineffective)

[Debian Bug Tracking System]

Your message dated Mon, 13 May 2019 21:17:13 +
with message-id 
and subject line Bug#927932: fixed in bind9 1:9.10.3.dfsg.P4-12.3+deb9u5
has caused the Debian Bug report #927932,
regarding bind9: CVE-2018-5743: Limiting simultaneous TCP clients is ineffective
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
927932: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927932
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: bind9
Version: 1:9.11.5.P4+dfsg-3
Severity: grave
Tags: security upstream
Justification: user security hole
Control: clone -1 -2
Control: reassign -2 src:bind 1:9.13.3-1
Control: retitle -2 bind: CVE-2018-5743: Limiting simultaneous TCP clients is 
ineffective
Control: found -1 1:9.11.6+dfsg-1
Control: found -1 1:9.10.3.dfsg.P4-12.3+deb9u4
Control: found -1 1:9.10.3.dfsg.P4-12.3

Hi,

The following vulnerability was published for bind9.

CVE-2018-5743[0]:
Limiting simultaneous TCP clients is ineffective

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-5743
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-5743
[1] https://kb.isc.org/docs/cve-2018-5743

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore
--- End Message ---
--- Begin Message ---
Source: bind9
Source-Version: 1:9.10.3.dfsg.P4-12.3+deb9u5

We believe that the bug you reported is fixed in the latest version of
bind9, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 927...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Bernhard Schmidt  (supplier of updated bind9 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 03 May 2019 22:34:35 +0200
Source: bind9
Binary: bind9 bind9utils bind9-doc host bind9-host libbind-dev libbind9-140 
libdns162 libirs141 libisc160 liblwres141 libisccc140 libisccfg140 dnsutils 
lwresd libbind-export-dev libdns-export162 libdns-export162-udeb 
libisc-export160 libisc-export160-udeb libisccfg-export140 libisccc-export140 
libisccc-export140-udeb libisccfg-export140-udeb libirs-export141 
libirs-export141-udeb
Architecture: source
Version: 1:9.10.3.dfsg.P4-12.3+deb9u5
Distribution: stretch-security
Urgency: high
Maintainer: Debian DNS Packaging 
Changed-By: Bernhard Schmidt 
Description:
 bind9  - Internet Domain Name Server
 bind9-doc  - Documentation for BIND
 bind9-host - Version of 'host' bundled with BIND 9.X
 bind9utils - Utilities for BIND
 dnsutils   - Clients provided with BIND
 host   - Transitional package
 libbind-dev - Static Libraries and Headers used by BIND
 libbind-export-dev - Development files for the exported BIND libraries
 libbind9-140 - BIND9 Shared Library used by BIND
 libdns-export162 - Exported DNS Shared Library
 libdns-export162-udeb - Exported DNS library for debian-installer (udeb)
 libdns162  - DNS Shared Library used by BIND
 libirs-export141 - Exported IRS Shared Library
 libirs-export141-udeb - Exported IRS library for debian-installer (udeb)
 libirs141  - DNS Shared Library used by BIND
 libisc-export160 - Exported ISC Shared Library
 libisc-export160-udeb - Exported ISC library for debian-installer (udeb)
 libisc160  - ISC Shared Library used by BIND
 libisccc-export140 - Command Channel Library used by BIND
 libisccc-export140-udeb - Command Channel Library used by BIND (udeb)
 libisccc140 - Command Channel Library used by BIND
 libisccfg-export140 - Exported ISC CFG Shared Library
 libisccfg-export140-udeb - Exported ISC CFG library for debian-installer (udeb)
 libisccfg140 - Config File Handling Library used by BIND
 liblwres141 - Lightweight Resolver Library used by BIND
 lwresd - Lightweight Resolver Daemon
Closes: 922954 922955 927932
Changes:
 bind9 (1:9.10.3.dfsg.P4-12.3+deb9u5) stretch-security; urgency=high
 .
   [ Marc Deslauriers (Ubuntu) ]
   * CVE-2018-5743: limiting simultaneous TCP clients is ineffective.
 Thanks to Marc Deslauriers of Ubuntu (Closes: #927932)
 .
   [ Ondřej Surý ]
   * Sync Maintainer 

Bug#927932: marked as done (bind9: CVE-2018-5743: Limiting simultaneous TCP clients is ineffective)

[Debian Bug Tracking System]

Your message dated Mon, 13 May 2019 21:17:13 +
with message-id 
and subject line Bug#927932: fixed in bind9 1:9.10.3.dfsg.P4-12.3+deb9u5
has caused the Debian Bug report #927932,
regarding bind9: CVE-2018-5743: Limiting simultaneous TCP clients is ineffective
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
927932: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927932
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:bind9
Severity: grave
Tags: security, upstream

CVE: CVE-2018-5743
Document version:2.0
Posting date:24 April 2019
Program impacted:BIND
Versions affected:   BIND 9.9.0 -> 9.10.8-P1, 9.11.0 -> 9.11.6,
 9.12.0 -> 9.12.4, 9.14.0. BIND 9 Supported Preview
 Edition versions 9.9.3-S1 -> 9.11.5-S3, and 9.11.5-S5.
 Versions 9.13.0 -> 9.13.7 of the 9.13 development branch
 are also affected. Versions prior to BIND 9.9.0 have not
 been evaluated for vulnerability to CVE-2018-5743.
Severity:High
Exploitable: Remotely

Description:

   By design, BIND is intended to limit the number of TCP clients
   that can be connected at any given time. The number of allowed
   connections is a tunable parameter which, if unset, defaults to
   a conservative value for most servers. Unfortunately, the code
   which was intended to limit the number of simultaneous connections
   contains an error which can be exploited to grow the number of
   simultaneous connections beyond this limit.

Impact:

   By exploiting the failure to limit simultaneous TCP connections,
   an attacker can deliberately exhaust the pool of file descriptors
   available to named, potentially affecting network connections
   and the management of files such as log files or zone journal
   files.

   In cases where the named process is not limited by OS-enforced
   per-process limits, this could additionally potentially lead to
   exhaustion of all available free file descriptors on that system.

CVSS Score:  7.5
CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

For more information on the Common Vulnerability Scoring System and
to obtain your specific environmental score please visit:
https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H.

Workarounds:

   None.

Active exploits:

   No known deliberate exploits, but the situation may occur
   accidentally on busy servers.

   It is possible for operators to mistakenly believe that their
   configured (or default) limit is sufficient for their typical
   operations, when in fact it is not. Following an upgrade to a
   version that effectively applies limits, named may deny connections
   which were previously improperly permitted. Operators can monitor
   their logs for rejected connections, keep an eye on "rndc status"
   reports of simultaneous connections, or use other tools to monitor
   whether the now-effective limits are causing problems for
   legitimate clients. Should this be the case, increasing the value
   of the tcp-clients setting in named.conf to an appropriate value
   would be recommended.

Solution:

   Upgrade to a version of BIND containing a fix for the ineffective
   limits.

   -  BIND 9.11.6-P1
   -  BIND 9.12.4-P1
   -  BIND 9.14.1

   BIND Supported Preview Edition is a special feature preview
   branch of BIND provided to eligible ISC support customers.

   -  BIND 9.11.5-S6
   -  BIND 9.11.6-S1

Acknowledgements:

   ISC would like to thank AT for helping us to discover this
   issue.

Document revision history:

   1.0 Advance Notification, 16 January 2019
   1.1 Recall due to error in original fix, 17 January 2019
   1.3 Replacement fix delivered to Advance Notification customers, 15
April 2019
   1.4 Corrected Versions affected and Solution, 16 April 2019
   1.5 Added reference to BIND 9.11.6-S1
   2.0 Public disclosure, 24 April 2019

Related documents:

   See our BIND 9 Security Vulnerability Matrix for a complete
   listing of security vulnerabilities and versions affected.

Do you still have questions? Questions regarding this advisory
should go to security-offi...@isc.org. To report a new issue, please
encrypt your message using security-offi...@isc.org's PGP key which
can be found here:
   https://www.isc.org/downloads/software-support-policy/openpgp-key
If you are unable to use encrypted email, you may also report new
issues at: https://www.isc.org/community/report-bug/.

Note:

   ISC patches only currently 

Bug#928304: marked as done (groonga-httpd: Privilege escalation due to insecure use of logrotate (CVE-2019-11675))

[Debian Bug Tracking System]

Your message dated Mon, 13 May 2019 21:17:46 +
with message-id 
and subject line Bug#928304: fixed in groonga 6.1.5-1+deb9u1
has caused the Debian Bug report #928304,
regarding groonga-httpd: Privilege escalation due to insecure use of logrotate 
(CVE-2019-11675)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
928304: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928304
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: groonga-httpd
Version: 6.1.5-1
Severity: critical
Tags: security
Justification: root security hole

Dear Maintainer,

The path of the logdirectory of groonga-httpd can be manipulated by user
groonga:

ls -l /var/log/groonga
total 8
-rw-r--r-- 1 rootroot1296 Apr 25 18:44 groonga.log
drwxr-xr-x 2 groonga groonga 4096 Apr 25 18:55 httpd

The files in /var/log/groonga/httpd/*.log are once a day rotated by
logrotate as user root with the following config:

/var/log/groonga/httpd/*.log {
daily
missingok
rotate 30
compress
delaycompress
notifempty
create 640 groonga groonga
sharedscripts
postrotate
. /etc/default/groonga-httpd
if [ x"$ENABLE" = x"yes" ]; then
/usr/bin/curl --silent --output /dev/null \
"http://127.0.0.1:10041/d/log_reopen;
fi
endscript
}


Due to logrotate is prone to a race-condition(see the link to my
blog below) it is possible for user "groonga" to replace the
directory /var/log/groonga/httpd with a symbolik link to any
directory(for example /etc/bash_completion.d). logrotate will place
files AS ROOT into /etc/bash_completition.d and set the owner and
group to "groonga.groonga". An attacker could simply place a
reverse-shell into this file. As soon as root logs in, a reverse
shell will be executed then.

You can find an exploit for this bug at my blog:
https://tech.feedyourhead.at/content/abusing-a-race-condition-in-logrotate-to-elevate-privileges

(This exploit won't work well with lvm or docker but works reliable
if the filesystem is directly on the disk)

Mitigation:

You could mitigate the problem by changing the owner and group of
/var/log/groonga to root, or by using the "su option" inside the
logrotate-configfile. 


-- System Information:
Debian Release: 9.9
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-8-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages groonga-httpd depends on:
ii  curl   7.52.1-5+deb9u9
ii  groonga-server-common  6.1.5-1
ii  init-system-helpers1.48
ii  libc6  2.24-11+deb9u4
ii  libgroonga06.1.5-1
ii  libpcre3   2:8.39-3
ii  libssl1.1  1.1.0j-1~deb9u1
ii  lsb-base   9.20161125
ii  zlib1g 1:1.2.8.dfsg-5

groonga-httpd recommends no packages.

groonga-httpd suggests no packages.

-- no debconf information
--- End Message ---
--- Begin Message ---
Source: groonga
Source-Version: 6.1.5-1+deb9u1

We believe that the bug you reported is fixed in the latest version of
groonga, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 928...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Kentaro Hayashi  (supplier of updated groonga package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 07 May 2019 22:33:11 +0900
Source: groonga
Architecture: source
Version: 6.1.5-1+deb9u1
Distribution: stretch
Urgency: medium
Maintainer: Groonga Project 
Changed-By: Kentaro Hayashi 
Closes: 928304
Changes:
 groonga (6.1.5-1+deb9u1) stretch; urgency=medium
 .
   * debian/groonga-httpd.logrotate
 debian/groonga-server-gqtp.logrotate
 - Mitigate privilege escalation by changing the owner and group of logs
   with "su" option. Reported by Wolfgang Hotwagner.
   (Closes: #928304) (CVE-2019-11675)
Checksums-Sha1:
 8642ffd596164c39234a80dcf7f40d4fed9550b2 3096 groonga_6.1.5-1+deb9u1.dsc
 

Bug#927553: marked as done (atftp: CVE-2019-11365 CVE-2019-11366)

[Debian Bug Tracking System]

Your message dated Mon, 13 May 2019 21:17:07 +
with message-id 
and subject line Bug#927553: fixed in atftp 0.7.git20120829-3.1~deb9u1
has caused the Debian Bug report #927553,
regarding atftp: CVE-2019-11365 CVE-2019-11366
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
927553: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927553
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: atftp
Version: 0.7.git20120829-3
Severity: grave
Tags: patch security upstream

Hi,

The following vulnerabilities were published for atftp.

CVE-2019-11365[0]:
| An issue was discovered in atftpd in atftp 0.7.1. A remote attacker
| may send a crafted packet triggering a stack-based buffer overflow due
| to an insecurely implemented strncpy call. The vulnerability is
| triggered by sending an error packet of 3 bytes or fewer. There are
| multiple instances of this vulnerable strncpy pattern within the code
| base, specifically within tftpd_file.c, tftp_file.c, tftpd_mtftp.c,
| and tftp_mtftp.c.


CVE-2019-11366[1]:
| An issue was discovered in atftpd in atftp 0.7.1. It does not lock the
| thread_list_mutex mutex before assigning the current thread data
| structure. As a result, the daemon is vulnerable to a denial of
| service attack due to a NULL pointer dereference. If thread_data is
| NULL when assigned to current, and modified by another thread before a
| certain tftpd_list.c check, there is a crash when dereferencing
| current-next.


If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-11365
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11365

https://sourceforge.net/p/atftp/code/ci/abed7d245d8e8bdfeab24f9f7f55a52c3140f96b/
[1] https://security-tracker.debian.org/tracker/CVE-2019-11366
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11366

https://sourceforge.net/p/atftp/code/ci/382f76a90b44f81fec00e2f609a94def4a5d3580/
[2] https://pulsesecurity.co.nz/advisories/atftpd-multiple-vulnerabilities

Regards,
Salvatore
--- End Message ---
--- Begin Message ---
Source: atftp
Source-Version: 0.7.git20120829-3.1~deb9u1

We believe that the bug you reported is fixed in the latest version of
atftp, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 927...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Salvatore Bonaccorso  (supplier of updated atftp package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 03 May 2019 18:51:14 +0200
Source: atftp
Architecture: source
Version: 0.7.git20120829-3.1~deb9u1
Distribution: stretch-security
Urgency: high
Maintainer: Ludovic Drolez 
Changed-By: Salvatore Bonaccorso 
Closes: 927553
Changes:
 atftp (0.7.git20120829-3.1~deb9u1) stretch-security; urgency=high
 .
   * Non-maintainer upload by the Security Team.
   * Rebuild for stretch-security.
 .
 atftp (0.7.git20120829-3.1) unstable; urgency=high
 .
   * Non-maintainer upload.
   * Fix concurrency issue denial of service (CVE-2019-11366) (Closes: #927553)
   * Fix error handler stack overflow (CVE-2019-11365) (Closes: #927553)
Checksums-Sha1: 
 150b5c9f4d9295de270115370134e2bf7dacfb6b 1983 
atftp_0.7.git20120829-3.1~deb9u1.dsc
 6db7891546a5e19add6390c33ce82d2b1596c5ac 90982 
atftp_0.7.git20120829.orig.tar.gz
 d7f9bc5808e42a25f6601d42fbf88a3641d5d576 37883 
atftp_0.7.git20120829-3.1~deb9u1.diff.gz
Checksums-Sha256: 
 7537a800695192123e1250c053fa1d5f14cf4dbd546fc147a90b6c01e71823fa 1983 
atftp_0.7.git20120829-3.1~deb9u1.dsc
 d93a302ead76a0629feb061768df4393f9da02e3ffbf25eb10d281082ecf02d0 90982 
atftp_0.7.git20120829.orig.tar.gz
 0099793dc3df449526ca0a9d0e53d980142e373ee109a5909d0ddb897a3f848b 37883 
atftp_0.7.git20120829-3.1~deb9u1.diff.gz
Files: 
 ab7cb822c6ae075c93674d597635f814 1983 net extra 
atftp_0.7.git20120829-3.1~deb9u1.dsc
 f0cf6eb9e38cd7c789c0f953f20e1b69 90982 net extra 
atftp_0.7.git20120829.orig.tar.gz
 13b263980e74dfe008ed055c1f65b164 37883 net extra 
atftp_0.7.git20120829-3.1~deb9u1.diff.gz

-BEGIN PGP 

Bug#922954: marked as done (bind9: CVE-2018-5745: An assertion failure can occur if a trust anchor rolls over to an unsupported key algorithm when using managed-keys)

[Debian Bug Tracking System]

Your message dated Mon, 13 May 2019 21:17:13 +
with message-id 
and subject line Bug#922954: fixed in bind9 1:9.10.3.dfsg.P4-12.3+deb9u5
has caused the Debian Bug report #922954,
regarding bind9: CVE-2018-5745: An assertion failure can occur if a trust 
anchor rolls over to an unsupported key algorithm when using managed-keys
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
922954: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922954
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: bind9
Version: 1:9.11.5.P1+dfsg-2
Severity: grave
Tags: security upstream
Justification: user security hole
Control: found -1 1:9.10.3.dfsg.P4-12.3+deb9u4
Control: found -1 1:9.10.3.dfsg.P4-12.3

Hi,

The following vulnerability was published for bind9.

CVE-2018-5745[0]:
| An assertion failure can occur if a trust anchor rolls over to an
| unsupported key algorithm when using managed-keys

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-5745
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-5745
[1] https://kb.isc.org/docs/cve-2018-5745

Regards,
Salvatore
--- End Message ---
--- Begin Message ---
Source: bind9
Source-Version: 1:9.10.3.dfsg.P4-12.3+deb9u5

We believe that the bug you reported is fixed in the latest version of
bind9, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 922...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Bernhard Schmidt  (supplier of updated bind9 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 03 May 2019 22:34:35 +0200
Source: bind9
Binary: bind9 bind9utils bind9-doc host bind9-host libbind-dev libbind9-140 
libdns162 libirs141 libisc160 liblwres141 libisccc140 libisccfg140 dnsutils 
lwresd libbind-export-dev libdns-export162 libdns-export162-udeb 
libisc-export160 libisc-export160-udeb libisccfg-export140 libisccc-export140 
libisccc-export140-udeb libisccfg-export140-udeb libirs-export141 
libirs-export141-udeb
Architecture: source
Version: 1:9.10.3.dfsg.P4-12.3+deb9u5
Distribution: stretch-security
Urgency: high
Maintainer: Debian DNS Packaging 
Changed-By: Bernhard Schmidt 
Description:
 bind9  - Internet Domain Name Server
 bind9-doc  - Documentation for BIND
 bind9-host - Version of 'host' bundled with BIND 9.X
 bind9utils - Utilities for BIND
 dnsutils   - Clients provided with BIND
 host   - Transitional package
 libbind-dev - Static Libraries and Headers used by BIND
 libbind-export-dev - Development files for the exported BIND libraries
 libbind9-140 - BIND9 Shared Library used by BIND
 libdns-export162 - Exported DNS Shared Library
 libdns-export162-udeb - Exported DNS library for debian-installer (udeb)
 libdns162  - DNS Shared Library used by BIND
 libirs-export141 - Exported IRS Shared Library
 libirs-export141-udeb - Exported IRS library for debian-installer (udeb)
 libirs141  - DNS Shared Library used by BIND
 libisc-export160 - Exported ISC Shared Library
 libisc-export160-udeb - Exported ISC library for debian-installer (udeb)
 libisc160  - ISC Shared Library used by BIND
 libisccc-export140 - Command Channel Library used by BIND
 libisccc-export140-udeb - Command Channel Library used by BIND (udeb)
 libisccc140 - Command Channel Library used by BIND
 libisccfg-export140 - Exported ISC CFG Shared Library
 libisccfg-export140-udeb - Exported ISC CFG library for debian-installer (udeb)
 libisccfg140 - Config File Handling Library used by BIND
 liblwres141 - Lightweight Resolver Library used by BIND
 lwresd - Lightweight Resolver Daemon
Closes: 922954 922955 927932
Changes:
 bind9 (1:9.10.3.dfsg.P4-12.3+deb9u5) stretch-security; urgency=high
 .
   [ Marc Deslauriers (Ubuntu) ]
   * CVE-2018-5743: limiting simultaneous TCP clients is ineffective.
 Thanks to Marc Deslauriers of Ubuntu (Closes: #927932)
 .
   [ Ondřej Surý ]
   * Sync Maintainer and Uploaders with unstable
   * [CVE-2019-6465]: Zone transfer for DLZs are executed though not
 

Bug#922955: marked as done (bind9: CVE-2019-6465: Zone transfer controls for writable DLZ zones were not effective)

[Debian Bug Tracking System]

Your message dated Mon, 13 May 2019 21:17:13 +
with message-id 
and subject line Bug#922955: fixed in bind9 1:9.10.3.dfsg.P4-12.3+deb9u5
has caused the Debian Bug report #922955,
regarding bind9: CVE-2019-6465: Zone transfer controls for writable DLZ zones 
were not effective
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
922955: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922955
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: bind9
Version: 1:9.11.5.P1+dfsg-2
Severity: grave
Tags: security upstream
Justification: user security hole
Control: found -1 1:9.10.3.dfsg.P4-12.3+deb9u4
Control: found -1 1:9.10.3.dfsg.P4-12.3

Hi,

The following vulnerability was published for bind9.

CVE-2019-6465[0]:
Zone transfer controls for writable DLZ zones were not effective

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-6465
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6465
[1] https://kb.isc.org/docs/cve-2019-6465

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore
--- End Message ---
--- Begin Message ---
Source: bind9
Source-Version: 1:9.10.3.dfsg.P4-12.3+deb9u5

We believe that the bug you reported is fixed in the latest version of
bind9, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 922...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Bernhard Schmidt  (supplier of updated bind9 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 03 May 2019 22:34:35 +0200
Source: bind9
Binary: bind9 bind9utils bind9-doc host bind9-host libbind-dev libbind9-140 
libdns162 libirs141 libisc160 liblwres141 libisccc140 libisccfg140 dnsutils 
lwresd libbind-export-dev libdns-export162 libdns-export162-udeb 
libisc-export160 libisc-export160-udeb libisccfg-export140 libisccc-export140 
libisccc-export140-udeb libisccfg-export140-udeb libirs-export141 
libirs-export141-udeb
Architecture: source
Version: 1:9.10.3.dfsg.P4-12.3+deb9u5
Distribution: stretch-security
Urgency: high
Maintainer: Debian DNS Packaging 
Changed-By: Bernhard Schmidt 
Description:
 bind9  - Internet Domain Name Server
 bind9-doc  - Documentation for BIND
 bind9-host - Version of 'host' bundled with BIND 9.X
 bind9utils - Utilities for BIND
 dnsutils   - Clients provided with BIND
 host   - Transitional package
 libbind-dev - Static Libraries and Headers used by BIND
 libbind-export-dev - Development files for the exported BIND libraries
 libbind9-140 - BIND9 Shared Library used by BIND
 libdns-export162 - Exported DNS Shared Library
 libdns-export162-udeb - Exported DNS library for debian-installer (udeb)
 libdns162  - DNS Shared Library used by BIND
 libirs-export141 - Exported IRS Shared Library
 libirs-export141-udeb - Exported IRS library for debian-installer (udeb)
 libirs141  - DNS Shared Library used by BIND
 libisc-export160 - Exported ISC Shared Library
 libisc-export160-udeb - Exported ISC library for debian-installer (udeb)
 libisc160  - ISC Shared Library used by BIND
 libisccc-export140 - Command Channel Library used by BIND
 libisccc-export140-udeb - Command Channel Library used by BIND (udeb)
 libisccc140 - Command Channel Library used by BIND
 libisccfg-export140 - Exported ISC CFG Shared Library
 libisccfg-export140-udeb - Exported ISC CFG library for debian-installer (udeb)
 libisccfg140 - Config File Handling Library used by BIND
 liblwres141 - Lightweight Resolver Library used by BIND
 lwresd - Lightweight Resolver Daemon
Closes: 922954 922955 927932
Changes:
 bind9 (1:9.10.3.dfsg.P4-12.3+deb9u5) stretch-security; urgency=high
 .
   [ Marc Deslauriers (Ubuntu) ]
   * CVE-2018-5743: limiting simultaneous TCP clients is ineffective.
 Thanks to Marc Deslauriers of Ubuntu (Closes: #927932)
 .
   [ Ondřej Surý ]
   * Sync Maintainer and Uploaders with unstable
   * [CVE-2019-6465]: Zone transfer for DLZs are executed though not
 permitted by ACLs. (Closes: #922955)
   * 

Bug#928942:

[Leandro Doctors]

Control: user qa.debian@packages.debian.org
Control: usertags -1 + udd

Bug#928172: marked as done (base-files: please add a break on d-s-s < 2019.04.25)

[Debian Bug Tracking System]

Your message dated Mon, 13 May 2019 20:48:27 +
with message-id 
and subject line Bug#928172: fixed in base-files 10.3
has caused the Debian Bug report #928172,
regarding base-files: please add a break on d-s-s < 2019.04.25
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
928172: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928172
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: debian-security-support
Version: 2019.04.25
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails.

>From the attached log (scroll to the bottom...):

  Unpacking base-files (10.2) over (10.1) ...
  Setting up base-files (10.2) ...
  Installing new version of config file /etc/debian_version ...
  Installing new version of config file /etc/issue ...
  Installing new version of config file /etc/issue.net ...
  dpkg: error: error executing hook 'if [ -x 
/usr/share/debian-security-support/check-support-status.hook ] ; then 
/usr/share/debian-security-support/check-support-status.hook ; fi', exit code 
256
  E: Sub-process /usr/bin/dpkg returned an error code (2)


cheers,

Andreas


debian-security-support_2019.04.25.log.gz
Description: application/gzip
--- End Message ---
--- Begin Message ---
Source: base-files
Source-Version: 10.3

We believe that the bug you reported is fixed in the latest version of
base-files, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 928...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Santiago Vila  (supplier of updated base-files package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 13 May 2019 22:25:32 +0200
Source: base-files
Architecture: source
Version: 10.3
Distribution: unstable
Urgency: medium
Maintainer: Santiago Vila 
Changed-By: Santiago Vila 
Closes: 928172
Changes:
 base-files (10.3) unstable; urgency=medium
 .
   * Add Breaks: debian-security-support (<< 2019.04.25). Closes: #928172.
 This is the first version of debian-security-support which does not break
 when /etc/debian_version contains a string in the form "10.x".
Checksums-Sha1:
 6747fd4e8a015293a1839d1dee2906f335ba95a6 1071 base-files_10.3.dsc
 cac4881011840af93e3c0f42745867359fda07c7 65252 base-files_10.3.tar.xz
 980d247ccf08c3ba5b91e839725f4285967f59ab 4649 base-files_10.3_source.buildinfo
Checksums-Sha256:
 3a417a628dcdefbcfd287234582b6b01efee1f5815b2a822393fe35cb181d0ea 1071 
base-files_10.3.dsc
 732b93d5d44ada6418a623fa2ace5a184decfacdbe214c05a10ab70938517542 65252 
base-files_10.3.tar.xz
 f08e11e8dde2dc9d49159c3d372b12125b90b218abd5a92daa8d83b8d1fd165b 4649 
base-files_10.3_source.buildinfo
Files:
 0602b87863d7d199e259cc57c9f1b381 1071 admin required base-files_10.3.dsc
 f1198f586f930a2bfd66e4281696714d 65252 admin required base-files_10.3.tar.xz
 7d858b7767d74df648b7e57a772e1b80 4649 admin required 
base-files_10.3_source.buildinfo

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE1Uw7+v+wQt44LaXXQc5/C58bizIFAlzZ064ACgkQQc5/C58b
izK2rgf/QKr/wBkAdV37aN6pLPZe68EipmibnQjjlGUFNOvtrTC8Um+MeTwypocE
nLqyVYs2XncQIeU1DXnGJH3Y4x/JLNGPuunsjfLwbHVO7HrqzUrIx4FZCTRRg06Y
N2NUj1+PfqTJ+dV7xuhR5PV935qGACQqSZsSabfdFN6faXa6v1bj2dedorvbnQOV
lpcz9+DuD+MK0eySw5NmJNd6U02yhUy6s1VwtqFLatN6ek9T4VTBX4fbxLy0u880
HYIRHzuPEJpQ+EIqnxkkEhaT5WzXYsnoVtDg3G6D13eAsDCbnDqcYjhlv5UzxcOh
EtiUb46WOt0SvYI58xvVopw+q/ESAw==
=a0z9
-END PGP SIGNATURE End Message ---

Bug#928944: marked as done (CVE-2019-12046: lemonldap-ng tokens allows anonymous session when stored in session DB)

[Debian Bug Tracking System]

Your message dated Mon, 13 May 2019 20:35:33 +
with message-id 
and subject line Bug#928944: fixed in lemonldap-ng 2.0.2+ds-7+deb10u1
has caused the Debian Bug report #928944,
regarding CVE-2019-12046: lemonldap-ng tokens allows anonymous session when 
stored in session DB
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
928944: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928944
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: liblemonldap-ng-portal-perl
Severity: grave
Tags: security upstream patch
Justification: user security hole
Forwarded: https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/issues/1742
Found: 1.9.7-3

Hi all,

during an internal audit, one of lemonldap-ngi's developers discovered an
attack vector. It opens 3 security issues:
 - [high] for 2.0.0 ≤ version < 2.0.4: when CSRF tokens are
   enabled (default) and tokens are stored in session DB (not default,
   used with poor load-balancers), the token can be used to open an
   anonymous short-life session (2mn). It allows one to access to all
   aplications without additional rules
 - [high] for every versions < 2.0.4 or 1.9.19 when SAML/OIDC tokens are
   stored in sessions DB (not default), tokens can be used to have an
   anonymous session
 - [low] for every versions < 2.0.4 or 1.9.19: when self-registration
   is allowed, mail token can be used to have an anonymous session.

Attachements:
 - lemonldap-ng_2.0.2+ds-6.debdiff: fix for stretch
 - lemonldap-ng_2.0.2+ds-7.patch: patch for Buster. It includes 3 new
   upstream tests to prove that vulnerabilities are fixed
 - llng-1742-test.sh: a small tool that can be used to test an existing
   2.0.x installation

This issue also affects Ubuntu-19.04 which includes lemonldap-ng_2.0.2+ds-6.

Cheers,
Xavier

Description: Fix for CVE 
 When CSRF is enabled (default) and tokens are stored in session database
 (not default, used for poor load balancers), a short-life session can be
 created without being authentified.
 This patch fixes also a low level vulnerability on self-register (same vector,
 see https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/issues/1743)
 .
 This patch adds also 2 new upstream tests to prove that issues are fixed.
 .
 https://security-tracker.debian.org/tracker/CVE-2019-12046
Author: Xavier Guimard 
Origin: upstream, https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/issues/1742
Bug: https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/issues/1742
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: not-needed
Last-Update: 2019-05-12

--- a/lemonldap-ng-common/lib/Lemonldap/NG/Common/Apache/Session/REST.pm
+++ b/lemonldap-ng-common/lib/Lemonldap/NG/Common/Apache/Session/REST.pm
@@ -21,7 +21,7 @@
 modified => 0,
 };
 foreach (
-qw(baseUrl user password realm localStorage localStorageOptions lwpOpts lwpSslOpts)
+qw(baseUrl user password realm localStorage localStorageOptions lwpOpts lwpSslOpts kind)
   )
 {
 $self->{$_} = $args->{$_};
@@ -116,8 +116,13 @@
 
 sub getJson {
 my $self = shift;
-my $url  = shift;
-my $resp = $self->ua->get( $self->base . $url, @_ );
+my $id   = shift;
+my $resp = $self->ua->get(
+$self->base
+  . $id
+  . ( $self->{kind} ne 'SSO' ? "?kind=$self->{kind}" : '' ),
+@_
+);
 if ( $resp->is_success ) {
 my $res;
 eval { $res = from_json( $resp->content, { allow_nonref => 1 } ) };
--- a/lemonldap-ng-common/lib/Lemonldap/NG/Common/Session.pm
+++ b/lemonldap-ng-common/lib/Lemonldap/NG/Common/Session.pm
@@ -139,6 +139,14 @@
 
 # Load session data into object
 if ($data) {
+if ( $self->kind and $data->{_session_kind} ) {
+unless ( $data->{_session_kind} eq $self->kind ) {
+$self->error(
+"Session kind mismatch : $data->{_session_kind} is not "
+  . $self->kind );
+return undef;
+}
+}
 $self->_save_data($data);
 $self->kind( $data->{_session_kind} );
 $self->id( $data->{_session_id} );
@@ -158,7 +166,7 @@
 if ( $self->storageModule =~ /^Lemonldap::NG::Common::Apache::Session/ )
 {
 tie %h, $self->storageModule, $self->id,
-  { %{ $self->options }, %$options };
+  { %{ $self->options }, %$options, kind => $self->kind };
 }
 else {
 tie %h, 'Lemonldap::NG::Common::Apache::Session', $self->id,
--- 

Processed: Re: Bug#928204: lower severity

[Debian Bug Tracking System]

Processing control commands:

> severity -1 serious
Bug #928204 [debian-security-support] check-support-status: cannot create 
/var/lib/debian-security-support/security-support.semaphore: Directory 
nonexistent
Severity set to 'serious' from 'important'

-- 
928204: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928204
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed (with 1 error): Re: udd

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 928942 + udd
Unknown tag/s: udd.
Recognized are: patch wontfix moreinfo unreproducible help security upstream 
pending confirmed ipv6 lfs d-i l10n newcomer a11y ftbfs fixed-upstream fixed 
fixed-in-experimental sid experimental potato woody sarge sarge-ignore etch 
etch-ignore lenny lenny-ignore squeeze squeeze-ignore wheezy wheezy-ignore 
jessie jessie-ignore stretch stretch-ignore buster buster-ignore bullseye 
bullseye-ignore bookworm bookworm-ignore.

Bug #928942 [qa.debian.org] udd: cannot import database dump into PostgreSQL 
("function release_name(text) does not exist")
Requested to add no tags; doing nothing.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
928942: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928942
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#914034: Bug#911938: libhttp-daemon-ssl-perl FTBFS: tests fail: Connection refused

[Steffen Ullrich]

On Mon, May 13, 2019 at 03:18:14PM +0200, Guilhem Moulin  
wrote:
> On Mon, 13 May 2019 at 06:31:26 +0200, Steffen Ullrich wrote:
> > Applications which relied on blocking I/O in connection with select could
> > also hang before,
>
> Uh, what?  “Before” meaning with ≤TLSv1.2, or with OpenSSL <1.1.1a's
> default flags?  libssl mentions no such thing beside the new default
> mode.  And in fact the s_client() program, *from OpenSSL upstream
> itself*, does precisely that: a select loop in blocking I/O mode (unless
> the ‘-nbio’ flag is set).

"Before" meaning already with previous OpenSSL versions. But the effect was
likely hard to notice: an incomplete SSL record would not cause a permanent
hang but only a blocking read until the rest of the data was received, i.e.
only some slow down in some situations.

>
> 
> https://github.com/openssl/openssl/blob/OpenSSL_1_1_1/apps/s_client.c#L2817
>
> s_client() is roughly speaking a C version the ‘netcat.pl’ prototype I
> attached earlier.  Unsurprisingly, since 1.1.1a the code clears
> SSL_MODE_AUTO_RETRY from the bitmask mode of the newly created SSL_CTX
> object.  That change was even done in the very same commit that enabled
> SSL_MODE_AUTO_RETRY by default :-)
>
> 
> https://github.com/openssl/openssl/commit/693cf80c6ff54ae276a44d305d4ad07168ec6895#diff-7f3b79983f6d53c047c90a62813cc11f

s_client is just a better test program and not production code which
actually cares about edge cases. And the change was likely needed since
s_client now had serious problems and this was the easiest way to address
these.

> IMHO using polling sockets in blocking I/O is fairly common.  Granted,
> that itself itself doesn't say much about code quality, but the fact that
> the OpenSSL project *does* use it (and explicitly mentions it in the
> docs) gives me confidence that it's a fine use which should still be
> supported.

From my experience with OpenSSL and its documentation I don't agree with
this. Documentation is sometimes wrong or misleading and more often
incomplete (but its actually improving).
And while using blocking I/O with polling sockets might be fine with plain
sockets where each byte is part of application data it is not fine with SSL
since the unit in SSL is not a byte but a record and some records might
contain application data and some not.

> The documentation (libssl's SSL_read()'s [0], Net::SSLeay::read() [1],
> as well as IO::Socket::SSL::sysread() [2]) all warn that reading from an
> SSL socket has a different behavior than usual read(2) system calls, in
> that read failures should be treated with care, as there are both
> retryable (eg. when no application data was received) and non-retryable
> errors.

As I was the one who wrote the documentation for IO::Socket::SSL: the part
about sysread failing was supposed to be about non-blocking sockets. A
blocking socket was not expected to return nothing just because the handshake
was not done.

>
> So from my perspective, the expectation that IO::Socket::SSL::sysread()
> behaves like a “normal” sysread doesn't hold, and never did.  (There is
> even an entry for “Expecting exactly the same behavior as plain
> sockets” in the “Common errors” section of IO::Socket::SSL's manpage!)

This part talks about specific cases and how to deal with these but says
nothing about blocking sockets temporary failing.

> For what it's worth I think it's a shame that SSL_MODE_AUTO_RETRY was
> not the default earlier, as it's convenient to be able to write
>
> $sock->sysread($buf, $len) // die;
>
> and not bother about inspecting $SSL_ERROR.  But programs have been

I agree with that. But in the past SSL_MODE_AUTO_RETRY was only relevant
with unexpected renegotiations which nearly never happened. So nobody
actually noticed.

> written with the old default in mind, and the fact that SSL_read()
> doesn't behave like a normal read() system call.  For these programs to
> keep working, there needs to be a way to switch SSL_MODE_AUTO_RETRY off.
> libssl provides SSL_CTX_clear_mode(), Net::SSLeay has
> CTX_ctrl(,78,SSL_CTRL_CLEAR_MODE,0), and I'd like to have something
> similar in IO::Socket::SSL, too.

I'm not convinced that this is the way to go, i.e. I'd rather see the
applications use non-blocking sockets.  But I'm also not stubbornly
against it.
Do you know a relevant module or actually used application which has
problems because of the default mode of SSL_MODE_AUTO_RETRY the ability to
change it would fix the related problems and not introduce new ones, i.e.
where such a fix would be the right thing to do?
LWP of course does not count since the right thing to do in LWP was to
remove the obsolete patch which kept the socket blocking.

I have also some problems to provide a consistent API for this which can
actually be understood. This would in my opinion mean that I have a clear
default for the value, i.e. that I enable SSL_MODE_AUTO_RETRY by default for
older OpenSSL versions the same way it is done in OpenSSL 1.1.1. But 

Processed (with 1 error): Re: udd

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 928942 + udd + buster + sid
Unknown tag/s: udd.
Recognized are: patch wontfix moreinfo unreproducible help security upstream 
pending confirmed ipv6 lfs d-i l10n newcomer a11y ftbfs fixed-upstream fixed 
fixed-in-experimental sid experimental potato woody sarge sarge-ignore etch 
etch-ignore lenny lenny-ignore squeeze squeeze-ignore wheezy wheezy-ignore 
jessie jessie-ignore stretch stretch-ignore buster buster-ignore bullseye 
bullseye-ignore bookworm bookworm-ignore.

Bug #928942 [qa.debian.org] udd: cannot import database dump into PostgreSQL 
("function release_name(text) does not exist")
Requested to add no tags; doing nothing.
Bug #928942 [qa.debian.org] udd: cannot import database dump into PostgreSQL 
("function release_name(text) does not exist")
Ignoring request to alter tags of bug #928942 to the same tags previously set
Bug #928942 [qa.debian.org] udd: cannot import database dump into PostgreSQL 
("function release_name(text) does not exist")
Ignoring request to alter tags of bug #928942 to the same tags previously set
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
928942: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928942
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#928944: marked as pending in lemonldap-ng

[Xavier Guimard]

Control: tag -1 pending

Hello,

Bug #928944 in lemonldap-ng reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/perl-team/modules/packages/lemonldap-ng/commit/fdf782dfb5acc4f6ee1cc465f17a9b7dc053cc92


Add BTS reference

Closes: #928944


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/928944

Processed: Bug#928944 marked as pending in lemonldap-ng

[Debian Bug Tracking System]

Processing control commands:

> tag -1 pending
Bug #928944 [liblemonldap-ng-portal-perl] CVE-2019-12046: lemonldap-ng tokens 
allows anonymous session when stored in session DB
Added tag(s) pending.

-- 
928944: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928944
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: reassign

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 928172 base-files
Bug #928172 [base-files] debian-security-support: fails to upgrade from 
'testing': dpkg: error: error executing hook
Ignoring request to reassign bug #928172 to the same package
> retitle 928172 base-files: please add a break on d-s-s < 2019.04.25
Bug #928172 [base-files] debian-security-support: fails to upgrade from 
'testing': dpkg: error: error executing hook
Changed Bug title to 'base-files: please add a break on d-s-s < 2019.04.25' 
from 'debian-security-support: fails to upgrade from 'testing': dpkg: error: 
error executing hook'.
> # thanks
>
End of message, stopping processing here.

Please contact me if you need assistance.
-- 
928172: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928172
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: actually reassign

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 928172 base-files
Bug #928172 [debian-security-support] debian-security-support: fails to upgrade 
from 'testing': dpkg: error: error executing hook
Bug reassigned from package 'debian-security-support' to 'base-files'.
No longer marked as found in versions debian-security-support/2019.04.25.
Ignoring request to alter fixed versions of bug #928172 to the same values 
previously set
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
928172: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928172
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed (with 5 errors): lower severity

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> severity 928204 important
Bug #928204 [debian-security-support] check-support-status: cannot create 
/var/lib/debian-security-support/security-support.semaphore: Directory 
nonexistent
Severity set to 'important' from 'serious'
> tags 928204 unreproducible moreinfo
Bug #928204 [debian-security-support] check-support-status: cannot create 
/var/lib/debian-security-support/security-support.semaphore: Directory 
nonexistent
Added tag(s) moreinfo and unreproducible.
> # thanks
> Kibi,
Unknown command or malformed arguments to command.
> #928204 is the bug with the title "check-support-status: cannot create
> /var/lib/debian-security-support/security-support.semaphore: Directory
Unknown command or malformed arguments to command.
> nonexistent"...
Unknown command or malformed arguments to command.
> how did you create that chroot? is maybe apparmor involved (in a way
Unknown command or malformed arguments to command.
> thats not the default? (guessing based on the hostname in your log.)
Unknown command or malformed arguments to command.
Too many unknown commands, stopping here.

Please contact me if you need assistance.
-- 
928204: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928204
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed (with 1 error): udd

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 928942 udd + buster sid
Unknown tag/s: udd.
Recognized are: patch wontfix moreinfo unreproducible help security upstream 
pending confirmed ipv6 lfs d-i l10n newcomer a11y ftbfs fixed-upstream fixed 
fixed-in-experimental sid experimental potato woody sarge sarge-ignore etch 
etch-ignore lenny lenny-ignore squeeze squeeze-ignore wheezy wheezy-ignore 
jessie jessie-ignore stretch stretch-ignore buster buster-ignore bullseye 
bullseye-ignore bookworm bookworm-ignore.

Bug #928942 [qa.debian.org] udd: cannot import database dump into PostgreSQL 
("function release_name(text) does not exist")
Added tag(s) sid and buster.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
928942: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928942
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#914034: Bug#911938: libhttp-daemon-ssl-perl FTBFS: tests fail: Connection refused

[Guilhem Moulin]

On Mon, 13 May 2019 at 06:31:26 +0200, Steffen Ullrich wrote:
> Additionally switching off SSL_MODE_AUTO_RETRY would actually just add
> a different unexpected behavior: that sysread might return with EAGAIN
> on a blocking socket.

FWIW as shown below that's always been the case, until OpenSSL 1.1.1a
where SSL_MODE_AUTO_RETRY was switched on by default, so I'd say it's
wrong to expect that it won't :-P  Also I'm not arguing that the default
should be toggled back in IO::Socket::SSL, but that it should have a
flag to optionally revert to the old OpenSSL default.

Please consider the following code, which uses blocking I/O and merely
echoes what's being received from the SSL/TLS server.

perl -I. -MIO::Socket::SSL -e '
my $sock = IO::Socket::SSL->new(
PeerAddr => "127.0.0.1:4433",
SSL_ca_file => "/tmp/cert.pem"
) // die;
while(1) {
my $buf = "";
$sock->sysread($buf, 4096) //
die "errno=\"$!\", SSL_ERROR=\"$SSL_ERROR\"\n";
print $buf;
}'

Running in a Stretch chroot (libssl1.1 1.1.0j-1~deb9u1, libnet-ssleay-perl
1.80-1, and IO::Socket::SSL upstream 2.066), it dies with the following
message when the server renegotiates the TLSv1.2 session (“r\n” command
in the `s_server` input):

errno="Resource temporarily unavailable", SSL_ERROR="SSL wants a read first"

That's expected because SSL_read() fails and SSL_get_error() returns
SSL_ERROR_WANT_READ.  That code is broken as it doesn't inspect
$SSL_ERROR on sysread failure, and treats retryable errors as fatal.
With TLSv1.3 (but ensuring SSL_MODE_AUTO_RETRY is still unset) it's way
worse because it dies immediately after the handshake, not “just” when
the session is renegotiated.  In that light it makes sense that the
OpenSSL developers have switched SSL_MODE_AUTO_RETRY on by default.

Now with an OpenSSL version where SSL_MODE_AUTO_RETRY is set by default,
SSL_read() automatically retries and blocks until application data is
received, so the above program keeps looping as expected.  Automatic
retrying in lower-level functions is a fine default, but unfortunately
breaks applications that *were* relying on SSL_read() *not* blocking
when only non-application data was received.  That's why there needs to
be a way to optionally switch it back off.  Changing these programs to
use non-blocking I/O is clearly much more invasive.

> I've added more information regarding this to the IO::Socket::SSL
> documentation:
> https://github.com/noxxi/p5-io-socket-ssl/commit/ee176e489f02bfaaa479fc8d9312c8458bf55565

| A sysread on the IO::Socket::SSL socket will not return any data
| though since it is an abstraction which only returns application data.
| This causes the sysread to hang in case the socket was blocking

As shown above this is incorrect for OpenSSL <1.1.1a's (or any later
OpenSSL version where SSL_MODE_AUTO_RETRY was switched off).  There
IO::Socket::SSL::sysread() doesn't hang, but instead fails immediately
and sets $SSL_ERROR to SSL_ERROR_WANT_READ (and $! to EAGAIN).  While
setting errno to EAGAIN is specific to IO::Socket::SSL (and AFAICT
undocumented for blocking I/O), the manpage for SSL_read() and its higher
level bindings & wrappers, incl. IO::Socket::SSL, explicitly says that
upon failure one should first check SSL_get_error() for SSL-specific
errors, i.e., not rely on the errno value unless the SSL error code is
SSL_ERROR_SYSCALL.  That also applies to blocking I/O.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#928948: hostapd: syslog is spammed every two seconds

[Andrej Shadura]

Hi,

On Mon, 13 May 2019 at 21:42, sergio  wrote:
> Dear Maintainer,
>
> after installing hostap on debian buster syslog begin sapammed every
> 2 seconds with:
>
> systemd[1]: hostapd.service: Service RestartSec=2s expired, scheduling 
> restart.
> systemd[1]: hostapd.service: Scheduled restart job, restart counter is at 72.
> systemd[1]: Stopped Advanced IEEE 802.11 AP and IEEE 802.1X/WPA/WPA2/EAP 
> Authenticator.
> systemd[1]: Starting Advanced IEEE 802.11 AP and IEEE 802.1X/WPA/WPA2/EAP 
> Authenticator...
> hostapd[3500]: Configuration file: /etc/hostapd/hostapd.conf
> hostapd[3500]: Could not open configuration file '/etc/hostapd/hostapd.conf' 
> for reading.
> hostapd[3500]: Failed to set up interface with /etc/hostapd/hostapd.conf
> hostapd[3500]: Failed to initialize interface
> systemd[1]: hostapd.service: Control process exited, code=exited, 
> status=1/FAILURE
> systemd[1]: hostapd.service: Failed with result 'exit-code'.
> systemd[1]: Failed to start Advanced IEEE 802.11 AP and IEEE 
> 802.1X/WPA/WPA2/EAP Authenticator.

Could you please provide more details?

The postinst is set up in a way so that if /etc/hostapd/hostapd.conf
is not readable or missing, the hostapd.service is masked during the
package installation unless it was already running.

>From what you wrote it sounds like the package hasn’t been installed
before, but then it wouldn’t run by default.

-- 
Cheers,
  Andrej

Bug#928948: hostapd: syslog is spammed every two seconds

[sergio]

Package: hostapd
Version: 2:2.7+git20190128+0c1e29f-5
Severity: serious

Dear Maintainer,

after installing hostap on debian buster syslog begin sapammed every
2 seconds with:

systemd[1]: hostapd.service: Service RestartSec=2s expired, scheduling restart.
systemd[1]: hostapd.service: Scheduled restart job, restart counter is at 72.
systemd[1]: Stopped Advanced IEEE 802.11 AP and IEEE 802.1X/WPA/WPA2/EAP 
Authenticator.
systemd[1]: Starting Advanced IEEE 802.11 AP and IEEE 802.1X/WPA/WPA2/EAP 
Authenticator...
hostapd[3500]: Configuration file: /etc/hostapd/hostapd.conf
hostapd[3500]: Could not open configuration file '/etc/hostapd/hostapd.conf' 
for reading.
hostapd[3500]: Failed to set up interface with /etc/hostapd/hostapd.conf
hostapd[3500]: Failed to initialize interface
systemd[1]: hostapd.service: Control process exited, code=exited, 
status=1/FAILURE
systemd[1]: hostapd.service: Failed with result 'exit-code'.
systemd[1]: Failed to start Advanced IEEE 802.11 AP and IEEE 
802.1X/WPA/WPA2/EAP Authenticator.

Bug#927462: marked as done (megadown: Does not download anything)

[Debian Bug Tracking System]

Your message dated Mon, 13 May 2019 19:33:39 +
with message-id 
and subject line Bug#927462: fixed in megadown 0~20180705+git83c53dd-1.1
has caused the Debian Bug report #927462,
regarding megadown: Does not download anything
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
927462: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927462
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: megadown
Version: 0~20180705+git83c53dd-1
Severity: grave
Tags: upstream
Justification: renders package unusable

Dear Maintainer,

When trying to download a file from mega, which is the sole reason this script
exists, megadown fails like so

$ megadown
'https://mega.nz/#!3QsG0IDJ!wnEhMRAj1UsXvH3BmWKfr5Z4wqMD2c5ru4iWgFzJmO0'
   Reading link metadata...
MEGA bad link

I reported the issue to the project's github page, because it happened with
other mega links as well, and its dev issued a patch that restores the intended
functionality, here

https://github.com/tonikelope/megadown/commit/734e46fec67a2798bfbb5e21a75f04b90afafd65

So please update the package on the repo, which by the way is numerous minor
versions behind.



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-4-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages megadown depends on:
ii  bash 5.0-3
ii  curl 7.64.0-2
ii  openssl  1.1.1b-1
ii  pv   1.6.6-1
ii  python3  3.7.2-1
ii  wget 1.20.1-1

megadown recommends no packages.

megadown suggests no packages.

-- no debconf information
--- End Message ---
--- Begin Message ---
Source: megadown
Source-Version: 0~20180705+git83c53dd-1.1

We believe that the bug you reported is fixed in the latest version of
megadown, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 927...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Boyuan Yang  (supplier of updated megadown package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 13 May 2019 13:59:17 -0400
Source: megadown
Architecture: source
Version: 0~20180705+git83c53dd-1.1
Distribution: unstable
Urgency: medium
Maintainer: Vivia Nikolaidou 
Changed-By: Boyuan Yang 
Closes: 927462
Changes:
 megadown (0~20180705+git83c53dd-1.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Cherry-pick upstream fix on link parsing logic to make the tool
 actually usable. (Closes: #927462)
Checksums-Sha1:
 079b6aa0f3260cc4e321a69f1c52d3d33e20539d 1862 
megadown_0~20180705+git83c53dd-1.1.dsc
 5b521e4c894b97c53b29c9124ba4cb1e665f27d7 2580 
megadown_0~20180705+git83c53dd-1.1.debian.tar.xz
 a36add2672580e84f7e0a6a64956c4d6c2b51f2f 5898 
megadown_0~20180705+git83c53dd-1.1_amd64.buildinfo
Checksums-Sha256:
 ec781fba2bd6225083eaaab54751a9fbf7b56bfd6672320d00c5f697c5b2e81f 1862 
megadown_0~20180705+git83c53dd-1.1.dsc
 fa9539251e1ee7dd5de3c751c33036baaa1df3f9360b8800ba374c11b850b2f1 2580 
megadown_0~20180705+git83c53dd-1.1.debian.tar.xz
 3e3af7ce2911d8674023853fa9fe82a68ecafd8a8430fa8616c3aa8228c84a13 5898 
megadown_0~20180705+git83c53dd-1.1_amd64.buildinfo
Files:
 a33dba8b7e952bab62a57971908cd99f 1862 misc optional 
megadown_0~20180705+git83c53dd-1.1.dsc
 8011e1ab38f7342ad2b9e82e2d441d07 2580 misc optional 
megadown_0~20180705+git83c53dd-1.1.debian.tar.xz
 10ca2246ca44def631a3f146cb2a03fb 5898 misc optional 
megadown_0~20180705+git83c53dd-1.1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEfncpR22H1vEdkazLwpPntGGCWs4FAlzZwTYACgkQwpPntGGC
Ws6VJxAAt0nWwVFVQabC/CvBoaUlPT5M1Lyo/sAmjKkAdOYn1UvcM5JYu1scKESZ
Xf9Ui70teYyeEZ1XtpkTE2eEMo0TDSJaQcroylCPsq9UFelnEYbdGeQa8jcaEnCH
wprftbWAKMoIrUYgkD7X7KVdojYaCUHvl4FxnR/QoVXYaucyZ/gQQuGCuaPQUSxv
tS1o67jvQWL3BNN87QC1ziVtFbXOWKFNAOTC3b6K6Cu2XsmZhxDrnjUXHQDi9Q1L

Processed: found 928944 in 1.9.7-3

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> found 928944 1.9.7-3
Bug #928944 [liblemonldap-ng-portal-perl] CVE-2019-12046: lemonldap-ng tokens 
allows anonymous session when stored in session DB
Marked as found in versions lemonldap-ng/1.9.7-3.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
928944: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928944
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#928172: fixing debian-security-support upgrades from stretch (for good)

[Holger Levsen]

On Mon, May 13, 2019 at 08:17:26PM +0100, Ben Hutchings wrote:
> On Mon, 2019-05-13 at 19:08 +, Holger Levsen wrote:
> > reassign -1 base-files
> > retitle -1 base-files: please add a break on d-s-s < 2019.04.25
 
and FWIW and for future releases, I've just now done
https://salsa.debian.org/debian/debian-security-support/commit/970c319393cc1a43d6213b21e92b3ec1c6b77e73
"check-support-status.in: don't fail if security-support-ended.debX does
not exist for the release d-s-s is running on. Closes: #927450." though
I won't upload this immediatly as I'm not sure it's the most ideal fix
for this. Maybe it is though.


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#927462: megadown: Does not download anything

[Boyuan Yang]

On Mon, 13 May 2019 01:34:12 +0200 Alexis Murzeau  wrote:
> Hi,
> 
> Did you see this bug on the megadown package ?
> I saw that your maintainer email (vivia.nikolai...@puri.sm) is not the one
you used when creating bugs before (n.vi...@gmail.com), so I am mailing both
just in case.
> 
> On Sat, 20 Apr 2019 09:12:53 +0300 jim_p  wrote:
> > Package: megadown
> > Version: 0~20180705+git83c53dd-1
> > Severity: grave
> > Tags: upstream
> > Justification: renders package unusable
> > 
> > Dear Maintainer,
> > 
> > When trying to download a file from mega, which is the sole reason this
script
> > exists, megadown fails like so
> > 
> > $ megadown
> > 'https://mega.nz/#!3QsG0IDJ!wnEhMRAj1UsXvH3BmWKfr5Z4wqMD2c5ru4iWgFzJmO0'
> >    Reading link metadata...
> > MEGA bad link
> > 
> > I reported the issue to the project's github page, because it happened
with
> > other mega links as well, and its dev issued a patch that restores the
intended
> > functionality, here
> > 
> > 
https://github.com/tonikelope/megadown/commit/734e46fec67a2798bfbb5e21a75f04b90afafd65
> > 
> > So please update the package on the repo, which by the way is numerous
minor
> > versions behind.
> > 
> 
> Are you already in the process of backporting this patch, or do you need any
help ?

I'm preparing a Non-Maintainer Upload to fix this bug.

Vivia: I noticed that you uploaded this package on 2018-07 and showed no
activity since then. Are you still active in maintaining this package? Please
let me know no matter the answer is yes or not if you are available.

--
Thanks,
Boyuan Yang


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

Bug#928172: fixing debian-security-support upgrades from stretch (for good)

[Ben Hutchings]

On Mon, 2019-05-13 at 19:08 +, Holger Levsen wrote:
> reassign -1 base-files
> retitle -1 base-files: please add a break on d-s-s < 2019.04.25
> thanks
> 
> On Mon, May 13, 2019 at 01:00:14PM +0100, Ben Hutchings wrote:
> > On Mon, 2019-05-13 at 11:52 +, Holger Levsen wrote:
> > > So I think this can only be fixed properly (=without asking people to
> > > upgrade to the latest stretch pointrelease but instead allowing upgrades
> > > to buster from *any* stretch pointrelease) by adding a "pre-depends:
> > > debian-security-support (>= 2019.04.25)" to base-files in buster.
> > This makes debian-security-support transitively essential, whereas it
> > used to be optional.
> 
> thanks, Ben.
> 
> > Is "Conflicts" not strong enough?
>  
> after re-reading
> https://www.debian.org/doc/debian-policy/ch-relationships.html#packages-which-break-other-packages-breaks
> and
> https://www.debian.org/doc/debian-policy/ch-relationships.html#conflicting-binary-packages-conflicts
> (policy 7.3 and 7.4) I now also think that a "Breaks:
> debian-security-support (>= 2019.04.25)" in src:base-files is in order.

After re-reading, I concur that "Breaks" should be sufficient.  But
please do test this!

Ben.

-- 
Ben Hutchings
For every complex problem
there is a solution that is simple, neat, and wrong.




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

Bug#928172: fixing debian-security-support upgrades from stretch (for good)

[Holger Levsen]

reassign -1 base-files
retitle -1 base-files: please add a break on d-s-s < 2019.04.25
thanks

On Mon, May 13, 2019 at 01:00:14PM +0100, Ben Hutchings wrote:
> On Mon, 2019-05-13 at 11:52 +, Holger Levsen wrote:
> > So I think this can only be fixed properly (=without asking people to
> > upgrade to the latest stretch pointrelease but instead allowing upgrades
> > to buster from *any* stretch pointrelease) by adding a "pre-depends:
> > debian-security-support (>= 2019.04.25)" to base-files in buster.
> This makes debian-security-support transitively essential, whereas it
> used to be optional.

thanks, Ben.

> Is "Conflicts" not strong enough?
 
after re-reading
https://www.debian.org/doc/debian-policy/ch-relationships.html#packages-which-break-other-packages-breaks
and
https://www.debian.org/doc/debian-policy/ch-relationships.html#conflicting-binary-packages-conflicts
(policy 7.3 and 7.4) I now also think that a "Breaks:
debian-security-support (>= 2019.04.25)" in src:base-files is in order.

Thanks.


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

we'll all die. make a difference while you can. disobey. smile.


signature.asc
Description: PGP signature

Bug#928944: CVE-2019-12046: lemonldap-ng tokens allows anonymous session when stored in session DB

[Xavier]

Package: liblemonldap-ng-portal-perl
Severity: grave
Tags: security upstream patch
Justification: user security hole
Forwarded: https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/issues/1742
Found: 1.9.7-3

Hi all,

during an internal audit, one of lemonldap-ngi's developers discovered an
attack vector. It opens 3 security issues:
 - [high] for 2.0.0 ≤ version < 2.0.4: when CSRF tokens are
   enabled (default) and tokens are stored in session DB (not default,
   used with poor load-balancers), the token can be used to open an
   anonymous short-life session (2mn). It allows one to access to all
   aplications without additional rules
 - [high] for every versions < 2.0.4 or 1.9.19 when SAML/OIDC tokens are
   stored in sessions DB (not default), tokens can be used to have an
   anonymous session
 - [low] for every versions < 2.0.4 or 1.9.19: when self-registration
   is allowed, mail token can be used to have an anonymous session.

Attachements:
 - lemonldap-ng_2.0.2+ds-6.debdiff: fix for stretch
 - lemonldap-ng_2.0.2+ds-7.patch: patch for Buster. It includes 3 new
   upstream tests to prove that vulnerabilities are fixed
 - llng-1742-test.sh: a small tool that can be used to test an existing
   2.0.x installation

This issue also affects Ubuntu-19.04 which includes lemonldap-ng_2.0.2+ds-6.

Cheers,
Xavier

Description: Fix for CVE 
 When CSRF is enabled (default) and tokens are stored in session database
 (not default, used for poor load balancers), a short-life session can be
 created without being authentified.
 This patch fixes also a low level vulnerability on self-register (same vector,
 see https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/issues/1743)
 .
 This patch adds also 2 new upstream tests to prove that issues are fixed.
 .
 https://security-tracker.debian.org/tracker/CVE-2019-12046
Author: Xavier Guimard 
Origin: upstream, https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/issues/1742
Bug: https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/issues/1742
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: not-needed
Last-Update: 2019-05-12

--- a/lemonldap-ng-common/lib/Lemonldap/NG/Common/Apache/Session/REST.pm
+++ b/lemonldap-ng-common/lib/Lemonldap/NG/Common/Apache/Session/REST.pm
@@ -21,7 +21,7 @@
 modified => 0,
 };
 foreach (
-qw(baseUrl user password realm localStorage localStorageOptions lwpOpts lwpSslOpts)
+qw(baseUrl user password realm localStorage localStorageOptions lwpOpts lwpSslOpts kind)
   )
 {
 $self->{$_} = $args->{$_};
@@ -116,8 +116,13 @@
 
 sub getJson {
 my $self = shift;
-my $url  = shift;
-my $resp = $self->ua->get( $self->base . $url, @_ );
+my $id   = shift;
+my $resp = $self->ua->get(
+$self->base
+  . $id
+  . ( $self->{kind} ne 'SSO' ? "?kind=$self->{kind}" : '' ),
+@_
+);
 if ( $resp->is_success ) {
 my $res;
 eval { $res = from_json( $resp->content, { allow_nonref => 1 } ) };
--- a/lemonldap-ng-common/lib/Lemonldap/NG/Common/Session.pm
+++ b/lemonldap-ng-common/lib/Lemonldap/NG/Common/Session.pm
@@ -139,6 +139,14 @@
 
 # Load session data into object
 if ($data) {
+if ( $self->kind and $data->{_session_kind} ) {
+unless ( $data->{_session_kind} eq $self->kind ) {
+$self->error(
+"Session kind mismatch : $data->{_session_kind} is not "
+  . $self->kind );
+return undef;
+}
+}
 $self->_save_data($data);
 $self->kind( $data->{_session_kind} );
 $self->id( $data->{_session_id} );
@@ -158,7 +166,7 @@
 if ( $self->storageModule =~ /^Lemonldap::NG::Common::Apache::Session/ )
 {
 tie %h, $self->storageModule, $self->id,
-  { %{ $self->options }, %$options };
+  { %{ $self->options }, %$options, kind => $self->kind };
 }
 else {
 tie %h, 'Lemonldap::NG::Common::Apache::Session', $self->id,
--- a/lemonldap-ng-common/lib/Lemonldap/NG/Common/Session/REST.pm
+++ b/lemonldap-ng-common/lib/Lemonldap/NG/Common/Session/REST.pm
@@ -248,7 +248,7 @@
   Lemonldap::NG::Handler::PSGI::Main->tsv->{sessionCacheOptions},
 id=> $id,
 force => $force,
-kind  => $mod->{kind},
+( $id ? () : ( kind => $mod->{kind} ) ),
 ( $info ? ( info => $info ) : () ),
 }
 );
@@ -271,6 +271,9 @@
 $self->error('Unknown (or unconfigured) session type');
 return ();
 }
+if ( my $kind = $req->params('kind') ) {
+$m->{kind} = $kind;
+}
 return $m;
 }
 
--- a/lemonldap-ng-portal/lib/Lemonldap/NG/Portal/Lib/OneTimeToken.pm
+++ b/lemonldap-ng-portal/lib/Lemonldap/NG/Portal/Lib/OneTimeToken.pm
@@ -5,7 +5,7 @@
 use JSON qw(from_json to_json);
 use Crypt::URandom;
 
-our $VERSION = '2.0.2';
+our $VERSION = '2.0.4';
 
 

Bug#928942: udd: cannot import database dump into PostgreSQL ("function release_name(text) does not exist")

[Leandro Doctors]

Package: qa.debian.org
Severity: grave
Justification: causes non-serious data loss


Dear Maintainer,

(Sorry for any format error in this bug. I tried to use "reportbug",
but it gave me so many problems I gave up and ended up creating this
manually...)


I am trying to create a replica from the public dump of the UDD on my
local PostgreSQL server.
As recommended in the UDD README, I am following the instructions from
https://salsa.debian.org/qa/udd/blob/master/vagrant/provision.sh

Specifically, I do as follows.

0) Install the appropriate dependencies, per the same provision.sh file:
(See details at the bottom of this message.)
Apart from avoiding to install the unneeded 'apache2', the only
relevant difference is the PostgreSQL version - I use Buster's version
11, instead of Stretch's 9.6. However, I doubt this would affect
this...

apt install -y apache2 postgresql postgresql-plperl-9.6
postgresql-9.6-debversion ruby-debian ruby-oj rsync python-yaml
python-psycopg2 ruby-pg ruby-sequel-pg

1) Start the PostgreSQL service
sudo service postgresql start

2) Create the 'udd' database (If I don't, I cannot restore the dump)
sudo -u postgres createdb -T template0 -E SQL_ASCII udd

3) Add 'debversions' extension to the database (If I don't, I get a
lot of errors)
psql udd -c 'create extension debversion'

4) Make my local user the owner of the database
sudo -u postgres psql -c 'alter database udd owner to allentiak'

5) Grant permissions (as the provision script)
sudo -u postgres psql udd -c 'GRANT usage on schema public to public'
sudo -u postgres psql udd -c 'grant select on all tables in schema
public to public'

6) Finally, I import the dump
sudo -u postgres pg_restore -j 8 --no-owner -v -C -d postgres
udd.dump.2019.05.06.dump


After step 6, I get the following error:

```
pg_restore: launching item 4101 MATERIALIZED VIEW DATA tmp
pg_restore: creating MATERIALIZED VIEW DATA "public.tmp"
pg_restore: [archiver (db)] Error from TOC entry 4101; 0 91852869
MATERIALIZED VIEW DATA tmp udd
pg_restore: [archiver (db)] could not execute query: ERROR:
function release_name(text) does not exist
LINE 1: SELECT release_name($1)
   ^
HINT:  No function matches the given name and argument types. You
might need to add explicit type casts.
QUERY:  SELECT release_name($1)
CONTEXT:  PL/pgSQL function public.bugs_rt_affects_dist(text) line
4 during statement block local variable initialization
Command was: REFRESH MATERIALIZED VIEW public.tmp;

[...]

pg_restore: finished item 4101 MATERIALIZED VIEW DATA tmp
pg_restore: finished main parallel loop
WARNING: errors ignored on restore: 4
```

On the one hand, it looks as if the 'release_name(text)' function was
used before def (if such a thing is possible in Pg/SQL)... However,
this dupm was created automatically...

On the other hand, I am aware of #899307, involving 'SELECT' statemets
when using 'ruby-sequel-pg'. However, there are plenty of SELECT
statements in the dump file, and only one of them seems to fail...



-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8),
LANGUAGE=en_IE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled


Versions of packages postgresql depends on:
ii  postgresql-11  11.2-2

postgresql recommends no packages.

Versions of packages postgresql suggests:
pn  postgresql-doc  

Versions of packages postgresql-11 depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  libc6  2.28-10
ii  libgcc11:8.3.0-7
ii  libgssapi-krb5-2   1.17-2
ii  libicu63   63.1-6
ii  libldap-2.4-2  2.4.47+dfsg-3
ii  libllvm7   1:7.0.1-8
ii  libpam0g   1.3.1-5
ii  libpq5 11.2-2
ii  libselinux12.8-1+b1
ii  libssl1.1  1.1.1b-2
ii  libstdc++6 8.3.0-7
ii  libsystemd0241-3
ii  libuuid1   2.33.1-0.1
ii  libxml22.9.4+dfsg1-7+b3
ii  libxslt1.1 1.1.32-2
ii  locales2.28-10
ii  postgresql-client-11   11.2-2
ii  postgresql-common  200+deb10u1
ii  ssl-cert   1.0.39
ii  tzdata 2019a-1
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages postgresql-11 recommends:
ii  sysstat  12.0.3-2

postgresql-11 suggests no packages.


Versions of packages postgresql-11-debversion depends on:
ii  libapt-pkg5.0  1.8.1
ii  libc6  2.28-10
ii  postgresql-11  11.2-2

postgresql-11-debversion recommends no packages.

postgresql-11-debversion suggests no packages.


Versions of packages 

Bug#928941: marked as done (HOME and TERM are stripped by mistake)

[Debian Bug Tracking System]

Your message dated Mon, 13 May 2019 18:20:33 +
with message-id 
and subject line Bug#928941: fixed in lxqt-sudo 0.14.1-2
has caused the Debian Bug report #928941,
regarding HOME and TERM are stripped by mistake
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
928941: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928941
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: lxqt-sudo
Version: 0.14.1-1
Severity: critical
Tags: patch

Configurations are written into wrong directories etc - not funny,
if a programm is called with lxsudo again the false written config
will be read, if called with a right working (graphical) sudo not.

Informations written into wrong directories might cause security
breaches.

-- System Information:
Debian Release: 10.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.1.1-towo.1-siduction-amd64 (SMP w/8 CPU cores; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lxqt-sudo depends on:
ii  libc6   2.28-10
ii  liblxqt00.14.2~12-ga398a7c-1
ii  libqt5core5a5.11.3+dfsg1-1
ii  libqt5gui5  5.11.3+dfsg1-1
ii  libqt5widgets5  5.11.3+dfsg1-1
ii  libstdc++6  8.3.0-7

Versions of packages lxqt-sudo recommends:
ii  lxqt-qtplugin   0.14.1~8-g02a9e71-1
ii  lxqt-sudo-l10n  0.14.1-1

lxqt-sudo suggests no packages.

-- no debconf information
--- End Message ---
--- Begin Message ---
Source: lxqt-sudo
Source-Version: 0.14.1-2

We believe that the bug you reported is fixed in the latest version of
lxqt-sudo, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 928...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Alf Gaida  (supplier of updated lxqt-sudo package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 13 May 2019 19:56:39 +0200
Source: lxqt-sudo
Architecture: source
Version: 0.14.1-2
Distribution: unstable
Urgency: medium
Maintainer: LXQt Packaging Team 
Changed-By: Alf Gaida 
Closes: 928941
Changes:
 lxqt-sudo (0.14.1-2) unstable; urgency=medium
 .
   * Set HOME right, don't strip TERM (Closes: #928941)
Checksums-Sha1:
 81b783c7b8204e43e2575e4c7433510b695696a3 2087 lxqt-sudo_0.14.1-2.dsc
 fd7293dd5e81a69ea66a7c7d54ac51982bc1da76 7420 lxqt-sudo_0.14.1-2.debian.tar.xz
 213006c9312925e4a435a5d3fce8e5b346d6f661 12469 
lxqt-sudo_0.14.1-2_source.buildinfo
Checksums-Sha256:
 22dc12dce59e4c5b8ce363c5603e4b296d6bb0175f3c0848aaf4f7fa06571b50 2087 
lxqt-sudo_0.14.1-2.dsc
 8b0cfbbe01fa1890aa3c0f21d58ab823be846e592e03e9b4f04ee8478c33519f 7420 
lxqt-sudo_0.14.1-2.debian.tar.xz
 1093c17a4c1ffa97f8f320efbc5c7536871684e17715edac95057d824e8ee129 12469 
lxqt-sudo_0.14.1-2_source.buildinfo
Files:
 2b28c0d93a8452b04b35a4afb058104a 2087 x11 optional lxqt-sudo_0.14.1-2.dsc
 14cb3a83c636db9119a02d55a819e862 7420 x11 optional 
lxqt-sudo_0.14.1-2.debian.tar.xz
 8f23445cdf4e87a435f89b89d7840fdb 12469 x11 optional 
lxqt-sudo_0.14.1-2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEvb/GiO+tuolan0ZLzSgKC01ygnwFAlzZsBUACgkQzSgKC01y
gnwqmgf/eQE+Kffz5f3JPm1FTncgaP+K81fIlTGFmRwH/nqKBChHAv4keZjpjcK6
LGO+/neTvsmLrBMXZzEGlSLSJ5oXP3VfcK/BqgT4OA6khPd/ejSUHWbepl7AuwyF
0k+fddEpXgdaZgOASnMGlDrT2rD1UEryuqyt7WplJfB7H6AGpfW9C8cpL3IlN0eV
6De6GD7XYlSMzP6KjwpvQZMIABAN7zrgXWP3kQ2L7COUQvHi+l3uXJYOrLjEnY1r
WgAMSi4Evqlze12bFb6WHGhXLuFLoVi9eHeoJQM+9lybl1/UGAi35TesonhFFqvO
dJINgs0Xi2NhEIBnJsgOhvJJb/yp4A==
=5nL8
-END PGP SIGNATURE End Message ---

Bug#928887: marked as done (hello: version skew: 2.10-1+deb9u1 (stretch-security) > 2.10-1 (buster))

[Debian Bug Tracking System]

Your message dated Mon, 13 May 2019 18:19:38 +
with message-id 
and subject line Bug#928887: fixed in hello 2.10-2
has caused the Debian Bug report #928887,
regarding hello: version skew: 2.10-1+deb9u1 (stretch-security) > 2.10-1 
(buster)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
928887: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928887
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: hello
Version: 2.10-1
Severity: serious
Tags: sid buster
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package violates version
ordering:

 hello | 2.10-1| stretch  | source
 hello | 2.10-1| buster   | source
 hello | 2.10-1| sid  | source
 hello | 2.10-1+b1 | stretch  | amd64, ...
 hello | 2.10-1+b1 | buster   | amd64, ...
 hello | 2.10-1+b1 | sid  | amd64, ...
 hello | 2.10-1+deb9u1 | stretch-security | source, amd64, ...

Please do a dummy 2.10-2 upload to fix this ...


Andreas
--- End Message ---
--- Begin Message ---
Source: hello
Source-Version: 2.10-2

We believe that the bug you reported is fixed in the latest version of
hello, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 928...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Santiago Vila  (supplier of updated hello package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 13 May 2019 20:06:50 +0200
Source: hello
Architecture: source
Version: 2.10-2
Distribution: unstable
Urgency: medium
Maintainer: Santiago Vila 
Changed-By: Santiago Vila 
Closes: 928887
Changes:
 hello (2.10-2) unstable; urgency=medium
 .
   * Fix version skew. Closes: #928887.
   * Drop debian/compat and use new syntax to specify compat level.
   * Standards-Version: 4.3.0 (no changes for this).
   * Rules-Requires-Root: no
Checksums-Sha1:
 347b6037551adcfb155c27377f15d9d862f92f76 1335 hello_2.10-2.dsc
 a35d97bd364670b045cdd86d446e71b171e915cc 6132 hello_2.10-2.debian.tar.xz
 bc78d7415011e2a146ec4029617eb75de8c28675 4632 hello_2.10-2_source.buildinfo
Checksums-Sha256:
 409ec8c61539d8233a3b27f3450b9d6c2397be8adeaebb3bccbca7b608723190 1335 
hello_2.10-2.dsc
 811ad0255495279fc98dc75f4460da1722f5c1030740cb52638cb80d0fdb24f0 6132 
hello_2.10-2.debian.tar.xz
 8dfdc7a7d8d2a5205803dfba796e31d746efde20cce9a0632821c27831273533 4632 
hello_2.10-2_source.buildinfo
Files:
 83013cf13d9e408e0f6d875dc9e2d41a 1335 devel optional hello_2.10-2.dsc
 e522e61c27eb0401c86321b9d8e137ae 6132 devel optional hello_2.10-2.debian.tar.xz
 cec88c6a95a7cc08f4a65a6d951ff207 4632 devel optional 
hello_2.10-2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE1Uw7+v+wQt44LaXXQc5/C58bizIFAlzZsmUACgkQQc5/C58b
izIAIwf/U9fkMu9o58qufgI6DlJ/oFkxiY8siH29BM+xQ5zRQiBiOT/pPWiDJoCF
vQJaFg13wboAhukq90CF5tML1txnT5DNI2hdmWB3W1zfk14vicDTnnjImt33l3iw
MhosoJls/3vc/mltVSa2Us1QFnAsxhyldhxxXBr/+QXzn4lDY8nJap08jh7qBtAS
CeJAN1NBVHo8e1FPTeqvniQZDxn7GPw/pVIUtRfcMsszmGP3uj1hQ7xxB7QzYJAs
XbpRN4/iCllaOakzmynCxusrE2j0qZVey1jFXr+tD6W2uexn9wOwnOIMbfcw09DX
Q6Vtounwrl5+7fH7mXiCQVe5OiyUsA==
=DFpJ
-END PGP SIGNATURE End Message ---

Bug#928941: HOME and TERM are stripped by mistake

[Alf Gaida]

Package: lxqt-sudo
Version: 0.14.1-1
Severity: critical
Tags: patch

Configurations are written into wrong directories etc - not funny,
if a programm is called with lxsudo again the false written config
will be read, if called with a right working (graphical) sudo not.

Informations written into wrong directories might cause security
breaches.

-- System Information:
Debian Release: 10.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.1.1-towo.1-siduction-amd64 (SMP w/8 CPU cores; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lxqt-sudo depends on:
ii  libc6   2.28-10
ii  liblxqt00.14.2~12-ga398a7c-1
ii  libqt5core5a5.11.3+dfsg1-1
ii  libqt5gui5  5.11.3+dfsg1-1
ii  libqt5widgets5  5.11.3+dfsg1-1
ii  libstdc++6  8.3.0-7

Versions of packages lxqt-sudo recommends:
ii  lxqt-qtplugin   0.14.1~8-g02a9e71-1
ii  lxqt-sudo-l10n  0.14.1-1

lxqt-sudo suggests no packages.

-- no debconf information

Processed: Re: Bug#928887: hello: version skew: 2.10-1+deb9u1 (stretch-security) > 2.10-1 (buster)

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 928887 + pending
Bug #928887 [hello] hello: version skew: 2.10-1+deb9u1 (stretch-security) > 
2.10-1 (buster)
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
928887: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928887
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#928887: hello: version skew: 2.10-1+deb9u1 (stretch-security) > 2.10-1 (buster)

[Santiago Vila]

tags 928887 + pending
thanks

I've asked release.debian.org for permission to do very minimal
changes in addition to the dummy upload (see #928939 for details).

Thanks.

Bug#924787: I would really like to see yubikey-personalization in buster

[Karl O. Pinc]

Hi,

The release critical bug count for buster is getting really low.
Is there anything to be done to be sure yubikey-personalization
gets into buster?

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Bug#908678: security-tracker - Breaks salsa.d.o

[Bastian Blank]

Hi Salvatore

On Thu, Sep 13, 2018 at 01:37:35PM +0200, Salvatore Bonaccorso wrote:
> On Wed, Sep 12, 2018 at 03:10:56PM +0200, Bastian Blank wrote:
> > As the problems caused by the state of this repo now causes user visible
> > outages, this needs to be fixed.

Please provide a plan how and when to fix this before 2019-06-30.

Just for the record: you must drop the complete project before importing
the rewritten repository.  GitLab keeps all the revisions around, as 
they are associated with jobs.

Regards,
Bastian

-- 
Captain's Log, star date 21:34.5...

Processed: Re: Bug#923091: That merged-usr is mandatory is RC

[Debian Bug Tracking System]

Processing control commands:

> severity -1 wishlist
Bug #923091 [base-installer] base-installer: Allow installing w/o the broken 
merged-usr-via-symlinks
Severity set to 'wishlist' from 'serious'

-- 
923091: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923091
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#923091: That merged-usr is mandatory is RC

[Bastian Blank]

Control: severity -1 wishlist

Hi Ian

On Mon, May 13, 2019 at 11:22:35AM +0100, Ian Jackson wrote:
> In #923091, Guillem (with dpkg maintainer hat on) asks for a
> base-installer option to allow installing buster without merged-usr.

No, he did not mention dpkg.  But as always, please provide a patch and
answer kibi's questions.

Regards,
Bastian

-- 
First study the enemy.  Seek weakness.
-- Romulan Commander, "Balance of Terror", stardate 1709.2

Processed: Adjusting severity

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> severity 928053 important
Bug #928053 [modsecurity-crs] CVE-2019-11387 CVE-2019-11388 CVE-2019-11389 
CVE-2019-11390 CVE-2019-11391
Severity set to 'important' from 'grave'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
928053: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928053
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#928053: Adjusting severity

[Alberto Gonzalez Iniesta]

severity 928053 important
thanks

Hi,

Thanks, Christian and Ervin, for your help. I'm lowering the severity of
this bug since it does not really affect Debian (as explained in
upstream link regarding this issue).

If anyone disagrees with this change, please get in touch with me before
raising it again.

Regards,

Alberto

-- 
Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
mailto/sip: a...@inittab.org | en GNU/Linux y software libre
Encrypted mail preferred| http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55

Bug#927122: marked as done (ruby2.5: Rinda::TestRingFinger test_make_socket_ipv4_multicast Errno::ENETUNREACH: Network is unreachable)

[Debian Bug Tracking System]

Your message dated Mon, 13 May 2019 14:36:23 +
with message-id 
and subject line Bug#927122: fixed in ruby2.5 2.5.5-2
has caused the Debian Bug report #927122,
regarding ruby2.5: Rinda::TestRingFinger test_make_socket_ipv4_multicast 
Errno::ENETUNREACH: Network is unreachable
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
927122: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927122
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: ruby2.5
Version: 2.5.5-1
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)

The current ruby2.5 package in Buster/Unstable fails to build from
scratch. It fails in some of the tests that depend on network
availability.

The tests are already disabled in
debian/tests/excludes/any/TestRingFinger.rb
debian/tests/excludes/any/TestRingServer.rb

but are not effective.

With this patch, the same tests are disabled in test/excludes/ and they
are effective.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (990, 'testing'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_WARN, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ruby2.5 depends on:
ii  libc6 2.28-8
ii  libgmp10  2:6.1.2+dfsg-4
ii  libruby2.52.5.5-1
ii  rubygems-integration  1.11

Versions of packages ruby2.5 recommends:
ii  fonts-lato2.0-2
ii  libjs-jquery  3.3.1~dfsg-1

ruby2.5 suggests no packages.

-- no debconf information
The tests are marked excluded in debian/tests/excludes/any/TestRing*.rb
But they still get executed which results in the build failure.

In salsa commit:
https://salsa.debian.org/ruby-team/ruby/commit/2943f7b15ac47c9110b5f8bb5a2346eadefdb83f
the tests were explicitly disabled in tests/excludes/ in the upstream sources,
which works and is exactly this patch does.

There is also an upstream bug report about these tests failing but without any
resolution so far.
https://bugs.ruby-lang.org/issues/13864
Index: ruby2.5-2.5.5/test/excludes/Rinda/TestRingFinger.rb
===
--- /dev/null   1970-01-01 00:00:00.0 +
+++ ruby2.5-2.5.5/test/excludes/Rinda/TestRingFinger.rb 2019-04-15 
14:38:46.343954009 +0530
@@ -0,0 +1,3 @@
+reason = "Network access not allowed during build in Debian"
+exclude :test_make_socket_ipv4_multicast, reason
+exclude :test_make_socket_ipv4_multicast_hops, reason
Index: ruby2.5-2.5.5/test/excludes/Rinda/TestRingServer.rb
===
--- /dev/null   1970-01-01 00:00:00.0 +
+++ ruby2.5-2.5.5/test/excludes/Rinda/TestRingServer.rb 2019-04-15 
14:38:46.343954009 +0530
@@ -0,0 +1,3 @@
+reason = "Network access not allowed during build in Debian"
+exclude :test_make_socket_ipv4_multicast, reason
+exclude :test_ring_server_ipv4_multicast, reason
Index: ruby2.5-2.5.5/test/excludes/TestRinda.rb
===
--- /dev/null   1970-01-01 00:00:00.0 +
+++ ruby2.5-2.5.5/test/excludes/TestRinda.rb2019-04-15 14:38:46.343954009 
+0530
@@ -0,0 +1,5 @@
+reason = "Network access not allowed during build in Debian"
+exclude :test_make_socket_ipv4_multicast, reason
+exclude :test_make_socket_ipv4_multicast_hops, reason
+exclude :test_make_socket_ipv4_multicast, reason
+exclude :test_ring_server_ipv4_multicast, reason
--- End Message ---
--- Begin Message ---
Source: ruby2.5
Source-Version: 2.5.5-2

We believe that the bug you reported is fixed in the latest version of
ruby2.5, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 927...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Antonio Terceiro  (supplier of updated ruby2.5 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by 

Bug#927122: marked as pending in ruby

[Antonio Terceiro]

Control: tag -1 pending

Hello,

Bug #927122 in ruby reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/ruby-team/ruby/commit/f0b13d061b1c57910e0390cd3af4f40e94a87a81


debian/tests/excludes/: fix exclusion of Rinda tests

Closes: #927122


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/927122

Processed: Bug#927122 marked as pending in ruby

[Debian Bug Tracking System]

Processing control commands:

> tag -1 pending
Bug #927122 [src:ruby2.5] ruby2.5: Rinda::TestRingFinger 
test_make_socket_ipv4_multicast Errno::ENETUNREACH: Network is unreachable
Added tag(s) pending.

-- 
927122: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927122
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: reassign 918522 to timidity, forcibly merging 901148 918522

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 918522 timidity
Bug #918522 [pulseaudio] No sound with PulseAudio when an NVidia GPU is 
installed.
Bug reassigned from package 'pulseaudio' to 'timidity'.
No longer marked as found in versions pulseaudio/12.2-4 and pulseaudio/12.2-2.
Ignoring request to alter fixed versions of bug #918522 to the same values 
previously set
> forcemerge 901148 918522
Bug #901148 [timidity] timidity: upgrading to 2.14.0-2 broke sound via 
pulseaudio
Bug #902330 [timidity] timidity: upgrading to 2.14.0-2 broke sound via 
pulseaudio
Bug #904652 [timidity] pulseaudio: looses device and replace it with dummy 
package so no sound possible
Bug #918522 [timidity] No sound with PulseAudio when an NVidia GPU is installed.
Severity set to 'critical' from 'important'
Added indication that 918522 affects pulseaudio
Marked as found in versions timidity/2.14.0-2, timidity/2.14.0-8, and 
timidity/2.14.0-3.
Added tag(s) upstream and buster-ignore.
Bug #902330 [timidity] timidity: upgrading to 2.14.0-2 broke sound via 
pulseaudio
Added tag(s) moreinfo.
Added tag(s) moreinfo.
Added tag(s) moreinfo.
Bug #904652 [timidity] pulseaudio: looses device and replace it with dummy 
package so no sound possible
Merged 901148 902330 904652 918522
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
901148: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901148
902330: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902330
904652: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904652
918522: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918522
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#914034: Bug#911938: libhttp-daemon-ssl-perl FTBFS: tests fail: Connection refused

[Guilhem Moulin]

On Mon, 13 May 2019 at 06:31:26 +0200, Steffen Ullrich wrote:
> Applications which relied on blocking I/O in connection with select could
> also hang before,

Uh, what?  “Before” meaning with ≤TLSv1.2, or with OpenSSL <1.1.1a's
default flags?  libssl mentions no such thing beside the new default
mode.  And in fact the s_client() program, *from OpenSSL upstream
itself*, does precisely that: a select loop in blocking I/O mode (unless
the ‘-nbio’ flag is set).

https://github.com/openssl/openssl/blob/OpenSSL_1_1_1/apps/s_client.c#L2817

s_client() is roughly speaking a C version the ‘netcat.pl’ prototype I
attached earlier.  Unsurprisingly, since 1.1.1a the code clears
SSL_MODE_AUTO_RETRY from the bitmask mode of the newly created SSL_CTX
object.  That change was even done in the very same commit that enabled
SSL_MODE_AUTO_RETRY by default :-)


https://github.com/openssl/openssl/commit/693cf80c6ff54ae276a44d305d4ad07168ec6895#diff-7f3b79983f6d53c047c90a62813cc11f

IMHO using polling sockets in blocking I/O is fairly common.  Granted,
that itself itself doesn't say much about code quality, but the fact that
the OpenSSL project *does* use it (and explicitly mentions it in the
docs) gives me confidence that it's a fine use which should still be
supported.

> only this problem is worse now. Before TLS 1.3 these applications
> could hang if the peer initiated a renegotiation since this were TCP
> level data without any SSL application payload, i.e. select was
> triggered but sysread would not return with data.

I feel that we're talking past each other :-/  select() being triggered
means indeed that a subsequent read() system call *won't block*;
however read() is not called directly, but through SSL_read().  Whether
SSL_read() will block until application data is received, or not, is
controlled with the SSL_MODE_AUTO_RETRY flag.  If that flag is unset,
then SSL_read() returns immediately with failure and sets SSL_ERROR.
For an IO::Socket::SSL object, $sock->sysread() is AFAICT a mere wrapper
for SSL_read():


https://github.com/noxxi/p5-io-socket-ssl/blob/2.066/lib/IO/Socket/SSL.pm#L1187

So if select() is triggered because the TLS session is renegotiated, but
no application data was received, sysread will block iff. SSL_MODE_AUTO_RETRY
is set.  As I showed in the traces enclosed in my previous message.

> Additionally switching off SSL_MODE_AUTO_RETRY would actually just add a
> different unexpected behavior: that sysread might return with EAGAIN on a
> blocking socket. This is not the behavior one expects from a blocking
> socket, i.e. it should block until it returns data, should return no data
> only on connection shutdown or should fail permanently.

The documentation (libssl's SSL_read()'s [0], Net::SSLeay::read() [1],
as well as IO::Socket::SSL::sysread() [2]) all warn that reading from an
SSL socket has a different behavior than usual read(2) system calls, in
that read failures should be treated with care, as there are both
retryable (eg. when no application data was received) and non-retryable
errors.

So from my perspective, the expectation that IO::Socket::SSL::sysread()
behaves like a “normal” sysread doesn't hold, and never did.  (There is
even an entry for “Expecting exactly the same behavior as plain
sockets” in the “Common errors” section of IO::Socket::SSL's manpage!)
For what it's worth I think it's a shame that SSL_MODE_AUTO_RETRY was
not the default earlier, as it's convenient to be able to write

$sock->sysread($buf, $len) // die;

and not bother about inspecting $SSL_ERROR.  But programs have been
written with the old default in mind, and the fact that SSL_read()
doesn't behave like a normal read() system call.  For these programs to
keep working, there needs to be a way to switch SSL_MODE_AUTO_RETRY off.
libssl provides SSL_CTX_clear_mode(), Net::SSLeay has
CTX_ctrl(,78,SSL_CTRL_CLEAR_MODE,0), and I'd like to have something
similar in IO::Socket::SSL, too.

> It was just a coincidence that LWP::protocol::http could deal with
> this situation. And this coincidence came from the fact, that this
> code was actually designed for non-blocking sockets and only the
> Debian patch caused it to use a blocking socket instead.

Yup, I now agree with you as far as LWP is concerned.
 
> I've added more information regarding this to the IO::Socket::SSL
> documentation:
> https://github.com/noxxi/p5-io-socket-ssl/commit/ee176e489f02bfaaa479fc8d9312c8458bf55565

| A sysread on the IO::Socket::SSL socket will not return any data
| though since it is an abstraction which only returns application data.
| This causes the sysread to hang in case the socket was blocking

I believe that statement is incorrect for OpenSSL <1.1.1a's (or if
SSL_MODE_AUTO_RETRY was toggled via some other means).  If you try
netcat.pl with an older OpenSSL release, you won't be able to reproduce
the TLSv1.2 trace I pasted yesterday; the client doesn't end up stuck in
a blocking read :-)  If no application data is 

Processed (with 1 error): Re: Bug#918522: No sound with PulseAudio when an NVidia GPU is installed - workaround

[Debian Bug Tracking System]

Processing control commands:

> forcemerge 901148 -1
Bug #901148 [timidity] timidity: upgrading to 2.14.0-2 broke sound via 
pulseaudio
Bug #902330 [timidity] timidity: upgrading to 2.14.0-2 broke sound via 
pulseaudio
Bug #904652 [timidity] pulseaudio: looses device and replace it with dummy 
package so no sound possible
Unable to merge bugs because:
package of #918522 is 'pulseaudio' not 'timidity'
Failed to forcibly merge 901148: Did not alter merged bugs.


-- 
901148: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901148
902330: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902330
904652: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904652
918522: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918522
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#927153: plymouth: upgrade fails: /usr/share/initramfs-tools/hooks/plymouth failed with return 134

[Tobias Eliasson]

On Tue, 16 Apr 2019 15:33:04 +0200 Sven Hartge wrote:
> My uneducated guess is, the problem is here. See how the prefix
> "/var/tmp/mkinitramfs_0BRFs9/" is applied twice, somehow?
>

This was reproduced in fontconfig version 2.12.6 by running as earlier
suggested:

mkdir -p /var/tmp/mkinitramfs_0BRFs9/etc/fonts/conf.d
cp -a /etc/fonts/fonts.conf /var/tmp/mkinitramfs_0BRFs9/etc/fonts
cp -rL /etc/fonts/conf.d/60-latin.conf
/var/tmp/mkinitramfs_0BRFs9/etc/fonts/conf.d
mkdir -p /var/tmp/mkinitramfs_0BRFs9/var/cache/fontconfig
mkdir -p /var/tmp/mkinitramfs_0BRFs9/usr/local/share/fonts
mkdir -p /var/tmp/mkinitramfs_0BRFs9/usr/share/fonts/truetype/dejavu
cp -a /usr/share/fonts/truetype/dejavu/DejaVuSerif.ttf
/var/tmp/mkinitramfs_0BRFs9/usr/share/fonts/truetype/dejavu
cp -a /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
/var/tmp/mkinitramfs_0BRFs9/usr/share/fonts/truetype/dejavu
fc-cache -v -s -y /var/tmp/mkinitramfs_0BRFs9

Running with strace shows the duplicated sysroot search paths:
stat("/var/tmp/mkinitramfs_0BRFs9/etc/fonts/conf.d",
{st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
openat(AT_FDCWD,
"/var/tmp/mkinitramfs_0BRFs9//var/tmp/mkinitramfs_0BRFs9/etc/fonts/conf.d/.uuid",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/var/tmp/mkinitramfs_0BRFs9//var/tmp/mkinitramfs_0BRFs9/etc/fonts/conf.d",
0x7fffded11a30) = -1 ENOENT (No such file or directory)
access("/var/tmp/mkinitramfs_0BRFs9//var/tmp/mkinitramfs_0BRFs9/etc/fonts/conf.d/.uuid",
F_OK) = -1 ENOENT (No such file or directory)
stat("/var/tmp/mkinitramfs_0BRFs9//var/tmp/mkinitramfs_0BRFs9/etc/fonts/conf.d",
0x7fffded11ab0) = -1 ENOENT (No such file or directory)
stat("/var/tmp/mkinitramfs_0BRFs9//var/tmp/mkinitramfs_0BRFs9/etc/fonts/conf.d",
0x7fffded11b00) = -1 ENOENT (No such file or directory)
write(2, "/var/tmp/mkinitramfs_0BRFs9/etc/"...,
61/var/tmp/mkinitramfs_0BRFs9/etc/fonts/conf.d: error scanning
) = 61


Tested fontconfig 2.13.1 from buster, not able to reproduce this issue:
stat("/var/tmp/mkinitramfs_0BRFs9//etc/fonts/conf.d",
{st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
openat(AT_FDCWD, "/var/tmp/mkinitramfs_0BRFs9//etc/fonts/conf.d",
O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
fstat(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
getdents64(3, /* 3 entries */, 32768)   = 88
getdents64(3, /* 0 entries */, 32768)   = 0
access("/var/tmp/mkinitramfs_0BRFs9//etc/fonts/conf.d/60-latin.conf", R_OK) = 0
access("/var/tmp/mkinitramfs_0BRFs9//etc/fonts/conf.d/60-latin.conf", R_OK) = 0


Perhaps this defect can be closed?

Bug#928172: fixing debian-security-support upgrades from stretch (for good)

[Marco d'Itri]

On May 13, Holger Levsen  wrote:

> So I think this can only be fixed properly (=without asking people to
> upgrade to the latest stretch pointrelease but instead allowing upgrades
> to buster from *any* stretch pointrelease) by adding a "pre-depends:
> debian-security-support (>= 2019.04.25)" to base-files in buster.
I strongly object to adding this package, and its dependency 
gettext-base, to the transitive essential set.
There are many situations where this package is not needed (e.g. 
containers, where Debian is already quite suboptimal) and it is wrong to 
force it on every system because it wastes disk space and may cause 
future troubles (and it already doing this now).

This is not acceptable for a package with such a low popcon ranking.

I tried installing it (I had never heard of it before) and I see that it 
immediately complains about the version of binutils currently in 
unstable, so I also have serious doubts about the usefulness of 
a security tool which will always report an alarm.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#913576: Reboot

[Mattia Oss]

Hello,

I just want to add that today I rebooted my server and everything seems
fine so far.

Mattia

Bug#928172: fixing debian-security-support upgrades from stretch (for good)

[Ben Hutchings]

On Mon, 2019-05-13 at 11:52 +, Holger Levsen wrote:
> [re-sent with debian-release list address corrected...]
> 
> 
> hi,
> 
> so there is "#928172 debian-security-support: fails to upgrade from 'testing':
> dpkg: error: error executing hook" which happens when base-files is upgraded
> before debian-security-support (but doesnt happen if d-s-s is upgraded 
> first...)
> 
> So I think this can only be fixed properly (=without asking people to
> upgrade to the latest stretch pointrelease but instead allowing upgrades
> to buster from *any* stretch pointrelease) by adding a "pre-depends:
> debian-security-support (>= 2019.04.25)" to base-files in buster.
[...]

This makes debian-security-support transitively essential, whereas it
used to be optional.

Is "Conflicts" not strong enough?

Ben.

-- 
Ben Hutchings
For every complex problem
there is a solution that is simple, neat, and wrong.




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

Bug#928172: fixing debian-security-support upgrades from stretch (for good)

[Holger Levsen]

[re-sent with debian-release list address corrected...]


hi,

so there is "#928172 debian-security-support: fails to upgrade from 'testing':
dpkg: error: error executing hook" which happens when base-files is upgraded
before debian-security-support (but doesnt happen if d-s-s is upgraded first...)

So I think this can only be fixed properly (=without asking people to
upgrade to the latest stretch pointrelease but instead allowing upgrades
to buster from *any* stretch pointrelease) by adding a "pre-depends:
debian-security-support (>= 2019.04.25)" to base-files in buster.

As per policy 7.2 I'm asking debian-devel to discuss this and form a
consensus that this is the right thing to do.

Please note that there are two more relevant bugs for this disucssion:

"#927450 [debian-security-support] debian-security-support needs to be
adapted to each new Debian release" - this bug should be fixed in
another debian-security-support upload targeted at buster, probably by
just exiting with 0 in case of an unsupported release.
Please note that #927450 was fixed in d-s-s 2019.04.25 and then reopened
with another scope :/ (=fixing this permanently and forever, while #927450
was originally only about not recognizing buster as a valid release.)

"#928204 [debian-security-support] check-support-status: cannot
create /var/lib/debian-security-support/security-support.semaphore:
Directory nonexistent" - I looked at the code and couldnt see how this
bug could happen. Help welcome, also just by confirming whether it's
possible for you to (not) reproduce this bug.


-- 
tschau,
Holger, who didn't create this mess...

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#928172: fixing debian-security-support upgrades from stretch (for good)

[Santiago Vila]

On Mon, May 13, 2019 at 11:32:36AM +, Holger Levsen wrote:
> hi,
> 
> so there is "#928172 debian-security-support: fails to upgrade from 'testing':
> dpkg: error: error executing hook" which happens when base-files is upgraded
> before debian-security-support (but doesnt happen if d-s-s is upgraded 
> first...)
> 
> So I think this can only be fixed properly (=without asking people to
> upgrade to the latest stretch pointrelease but instead allowing upgrades
> to buster from *any* stretch pointrelease) by adding a "pre-depends:
> debian-security-support (>= 2019.04.25)" to base-files in buster.

Please no, this would make debian-security-support essential de-facto.

We should allow debian-security-support to propagate to testing first.

Then I can just add a Breaks: debian-security-support (<= version-in-stretch)
in base-files.

Please tell me what's wrong with that.

Thanks.

Bug#928172: fixing debian-security-support upgrades from stretch (for good)

[Holger Levsen]

hi,

so there is "#928172 debian-security-support: fails to upgrade from 'testing':
dpkg: error: error executing hook" which happens when base-files is upgraded
before debian-security-support (but doesnt happen if d-s-s is upgraded first...)

So I think this can only be fixed properly (=without asking people to
upgrade to the latest stretch pointrelease but instead allowing upgrades
to buster from *any* stretch pointrelease) by adding a "pre-depends:
debian-security-support (>= 2019.04.25)" to base-files in buster.

As per policy 7.2 I'm asking debian-devel to discuss this and form a
consensus that this is the right thing to do.

Please note that there are two more relevant bugs for this disucssion:

"#927450 [debian-security-support] debian-security-support needs to be
adapted to each new Debian release" - this bug should be fixed in
another debian-security-support upload targeted at buster, probably by
just exiting with 0 in case of an unsupported release.
Please note that #927450 was fixed in d-s-s 2019.04.25 and then reopened
with another scope :/ (=fixing this permanently and forever, while #927450
was originally only about not recognizing buster as a valid release.)

"#928204 [debian-security-support] check-support-status: cannot
create /var/lib/debian-security-support/security-support.semaphore:
Directory nonexistent" - I looked at the code and couldnt see how this
bug could happen. Help welcome, also just by confirming whether it's
possible for you to (not) reproduce this bug.


-- 
tschau,
Holger, who didn't create this mess...

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#923091: That merged-usr is mandatory is RC

[Ian Jackson]

(sending this because I got the release team address wrong)

Ian Jackson writes ("That merged-usr is mandatory is RC"):
> Control: severity -1 serious
> 
> In #923091, Guillem (with dpkg maintainer hat on) asks for a
> base-installer option to allow installing buster without merged-usr.
> 
> Guillem filed the bug as `wishlist' but given the controversy it seems
> to me that it should be RC if for no other reasons than social
> cohesion.
> 
> CCing the TC FYI (they have already been involved in merged-usr
> debates via #914897) and the release team, in case they have an
> opinion.  FAOD I am not a maintainer of base-files but AFAICT the
> base-files maintainer has not expressed an opinion about severity.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Processed: That merged-usr is mandatory is RC

[Debian Bug Tracking System]

Processing control commands:

> severity -1 serious
Bug #923091 [base-installer] base-installer: Allow installing w/o the broken 
merged-usr-via-symlinks
Severity set to 'serious' from 'wishlist'

-- 
923091: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923091
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#928840: marked as done (boot hangs forever at live-config when libnss-systemd in image)

[Debian Bug Tracking System]

Your message dated Mon, 13 May 2019 09:48:49 +
with message-id 
and subject line Bug#928840: fixed in live-config 5.20190507
has caused the Debian Bug report #928840,
regarding boot hangs forever at live-config when libnss-systemd in image
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
928840: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928840
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: live-config
Version: 5.20190415
Severity: normal

Dear Maintainer,

When the package 'libnss-systemd' is included in a debian-live image,
all attempts to boot the image fail, hanging forever at a particular
point in the boot process. The following message appears in the
console (all on one line), with the kinetic red "cylon" effect on the
left, and a time counter counting up towards infinity on the right:

``[ ***   ] A start job is running for live-config contains the
components that configure a live system during the boot process
(late userspace). (10min 1s / no limit)''

If it matters: I build my debian-live images with 'live-build', and
I include all Standard priority packages with the one-line package
list macro "! Packages Priority standard". In order to work around
this hanging-boot problem, I have been blocking the 'libnss-systemd'
package from my debian-live images via apt pinning.

I have tried adding "live-config.debug" to the boot command
line, but no additional useful information appears in the console.
And, furthermore, I cannot access the debug logs in the live
system, since tty consoles are not yet available at the point that
the live-config service hangs the boot sequence.

I have tried booting in both legacy/BIOS mode and in UEFI mode
(with secure boot disabled), and the behaviour is the always the
same: hanging boot.

I maintain a number of debian-live build recipes in salsa. The
following one can be used to create an ISO image that exhibits the
hanging boot problem (just remove the pin in 'config/apt/preferences'
before running the 'make.sh' script):

https://salsa.debian.org/smonaica-guest/sid-standard-live.git

Best regards,
-S.M.


-- System Information:
Debian Release: 10.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages live-config depends on:
ii  live-config-systemd [live-config-backend]  5.20190415

Versions of packages live-config recommends:
ii  iproute24.20.0-2
ii  keyboard-configuration  1.191
ii  live-config-doc 5.20190415
ii  live-tools  1:20171207
ii  locales 2.28-10
ii  sudo1.8.27-1
ii  user-setup  1.81

Versions of packages live-config suggests:
ii  pciutils  1:3.5.2-5
ii  wget  1.20.1-1.1

-- no debconf information
--- End Message ---
--- Begin Message ---
Source: live-config
Source-Version: 5.20190507

We believe that the bug you reported is fixed in the latest version of
live-config, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 928...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Raphaël Hertzog  (supplier of updated live-config package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 13 May 2019 11:29:40 +0200
Source: live-config
Architecture: source
Version: 5.20190507
Distribution: unstable
Urgency: medium
Maintainer: Live Systems Maintainers 
Changed-By: Raphaël Hertzog 
Closes: 928840
Changes:
 live-config (5.20190507) unstable; urgency=medium
 .
   * Disable systemd NSS module during live-config. Closes: #928840
Checksums-Sha1:
 4904d38a33f7a234c15046f078342e4db1ade77a 1682 live-config_5.20190507.dsc
 70a932c3cd156557ebca67b380ab2ca60057cbfa 76188 live-config_5.20190507.tar.xz
 9e673aab98b4b82524ef69bc17dc4b90f61d078f 5457 
live-config_5.20190507_source.buildinfo
Checksums-Sha256:
 90cf0be81f602dadd830baa072cbfcc2e406db392ed951d38e8d92d44ec5f9b3 1682 

Processed: severity of 928840 is serious

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> severity 928840 serious
Bug #928840 [live-config] boot hangs forever at live-config when libnss-systemd 
in image
Severity set to 'serious' from 'normal'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
928840: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928840
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: Re: grub-pc: upgrade hangs

[Debian Bug Tracking System]

Processing control commands:

> severity -1 serious
Bug #558422 [grub-pc] grub-pc: upgrade hangs
Severity set to 'serious' from 'important'

-- 
558422: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558422
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#926180: scilab: FTBFS on all - New trouble

[Sylvestre Ledru]

On 12/05/2019 22:10, Julien Puydt wrote:
> Hi,
>
> On 12/05/2019 11:46, Alexis Murzeau wrote:
>
>> I saw that there is a bugfix release 6.0.2 with many fixes [0].
> I had started to package 6.0.2 on salsa already in february. I removed
> the patch about Linenum as that was supposed to have been reworked and
> fixed, and it now fails with :
>
> ocamlopt -o XML2Modelica -I ./src/modelica_compiler -I
> ./src/xml2modelica  nums.cmxa ./src/xml2modelica/xMLTree.ml
> ./src/xml2modelica/linenum.ml ./src/xml2modelica/stringParser.ml
> ./src/xml2modelica/stringLexer.ml ./src/xml2modelica/xMLParser.ml
> ./src/xml2modelica/xMLLexer.ml
> ./src/xml2modelica/modelicaCodeGenerator.ml
> ./src/xml2modelica/xML2Modelica.ml
> File "./src/xml2modelica/xML2Modelica.ml", line 1:
> Error: Files ./src/xml2modelica/xMLParser.cmx
>and ./src/xml2modelica/linenum.cmx
>make inconsistent assumptions over implementation Linenum
>
> ie : it looks like upstream's fix isn't correct.

+ upstream

S