Bug#931045: Use higher priority for mate-terminal.wrapper

[Foteini Tsiami]

Source: mate-terminal
Version: 1.20.2-2
Severity: normal

Hello, debian/mate-terminal.postinst contains this line:
x-terminal-emulator /usr/bin/mate-terminal.wrapper 30 \

That means that it "races" with lxterm for being the preferred
terminal in an installed system:

$ update-alternatives --config x-terminal-emulator
There are 5 choices for the alternative x-terminal-emulator (providing
/usr/bin/x-terminal-emulator).

  SelectionPathΠροτε Status

* 0/usr/bin/lxterm  30auto mode
  1/usr/bin/koi8rxterm  20manual mode
  2/usr/bin/lxterm  30manual mode
  3/usr/bin/mate-terminal.wrapper   30manual mode
  4/usr/bin/uxterm  20manual mode
  5/usr/bin/xterm   20manual mode

Press  to keep the current choice[*], or type selection number:

So, upping that "30" to "40" would prevent lxterm from being preferred
over mate-terminal in 50% of the installations.
Gnome-terminal also uses "40" there.

Thank you.

Bug#931044: installing python3.4 fails

[Andreas Bießmann]

Package: python3.4
Version: 3.4.2-1+deb8u3

When I try to upgrade my packages it fails due to f-string in python3.4
code:

% LANG=C sudo apt full-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n]
Setting up python3.4 (3.4.2-1+deb8u3) ...
  File "/usr/lib/python3.4/http/client.py", line 1014
raise InvalidURL(f"URL can't contain control characters. {url!r} "
 ^
SyntaxError: invalid syntax
dpkg: error processing package python3.4 (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 python3.4
E: Sub-process /usr/bin/dpkg returned an error code (1)
LANG=C sudo apt full-upgrade  5,37s user 1,38s system 83% cpu 8,085 total
% cat /etc/debian_version
8.11

I suggest to replace the f-string to one of the two supported mechanism
in < python3.6.

I think the surroundings (libc, kernel, ...) are unimportant here.

kind regards,

Andreas Bießmann

Bug#931043: unblock: expat/2.2.6-2

[Salvatore Bonaccorso]

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

Hi,

Please unblock package expat, it fixes CVE-2018-20843 and got fixed by
Laszlo cherry-picking the upstream fix. The issue is tracked as
#931031 in the BTS:

> expat (2.2.6-2) unstable; urgency=high
> 
>   * Fix extraction of namespace prefix from XML name (CVE-2018-20843)
> (closes: #931031).
> 
>  -- Laszlo Boszormenyi (GCS)   Mon, 24 Jun 2019 21:18:31 
> +

unblock expat/2.2.6-2

Regards,
Salvatore
diff -Nru expat-2.2.6/debian/changelog expat-2.2.6/debian/changelog
--- expat-2.2.6/debian/changelog2018-08-15 17:18:15.0 +0200
+++ expat-2.2.6/debian/changelog2019-06-24 23:18:31.0 +0200
@@ -1,3 +1,10 @@
+expat (2.2.6-2) unstable; urgency=high
+
+  * Fix extraction of namespace prefix from XML name (CVE-2018-20843)
+(closes: #931031).
+
+ -- Laszlo Boszormenyi (GCS)   Mon, 24 Jun 2019 21:18:31 +
+
 expat (2.2.6-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru 
expat-2.2.6/debian/patches/Fix_extraction_of_namespace_prefix_from_XML_name.patch
 
expat-2.2.6/debian/patches/Fix_extraction_of_namespace_prefix_from_XML_name.patch
--- 
expat-2.2.6/debian/patches/Fix_extraction_of_namespace_prefix_from_XML_name.patch
   1970-01-01 01:00:00.0 +0100
+++ 
expat-2.2.6/debian/patches/Fix_extraction_of_namespace_prefix_from_XML_name.patch
   2019-06-24 23:18:31.0 +0200
@@ -0,0 +1,23 @@
+From 11f8838bf99ea0a6f0b76f9760c43704d00c4ff6 Mon Sep 17 00:00:00 2001
+From: Sebastian Pipping 
+Date: Wed, 12 Jun 2019 15:42:22 +0200
+Subject: [PATCH] xmlparse.c: Fix extraction of namespace prefix from XML name
+ (#186)
+
+---
+ expat/lib/xmlparse.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/expat/lib/xmlparse.c b/expat/lib/xmlparse.c
+index 30d55c5c..737d7cd2 100644
+--- a/expat/lib/xmlparse.c
 b/expat/lib/xmlparse.c
+@@ -6080,7 +6080,7 @@ setElementTypePrefix(XML_Parser parser, ELEMENT_TYPE 
*elementType)
+   else
+ poolDiscard(>pool);
+   elementType->prefix = prefix;
+-
++  break;
+ }
+   }
+   return 1;
diff -Nru expat-2.2.6/debian/patches/series expat-2.2.6/debian/patches/series
--- expat-2.2.6/debian/patches/series   1970-01-01 01:00:00.0 +0100
+++ expat-2.2.6/debian/patches/series   2019-06-24 23:18:31.0 +0200
@@ -0,0 +1 @@
+Fix_extraction_of_namespace_prefix_from_XML_name.patch

Bug#930988: libtifiles FTCBFS: Missing dependency tfdocgen

[Helmut Grohne]

On Mon, Jun 24, 2019 at 10:36:31AM +0700, Nguyen Hoang Tung wrote:
> libtifiles fails to cross build because its dependency, tfdocgen package, is
> missing. Using tfdocgen:native instead of tfdocgen to cross-build can solve
> this problem.

Did you look into whether we can instead mark tfdocgen Multi-Arch:
foreign? I suspect that every build-rdep will need the native version.
If so, marking tfdocgen means we can fix four packages with one upload.
The tricky question is whether the marking is actually correct.
Deciding will involve knowlegde of what precisely tfdocgen does, so this
likely needs help from the relevant package maintainer.

Helmut

Bug#925906: sqlite3: FTCBFS: configure fails to find readline.h

[Helmut Grohne]

Control: tag -1 + moreinfo

On Thu, Mar 28, 2019 at 01:14:13PM +0300, Yuriy M. Kaminskiy wrote:
> When cross-building sqlite3, it fails to detect readline: while
> actual code wants only  (see src/shell.c.in),
> but configure.ac checks for ;

I am unable to reproduce this issue. The public autobuilder cannot
reproduce it either: http://crossqa.debian.net/src/sqlite3 This is using
sbuild for performing the build. How does your build environment differ
to make sqlite3 fail? Please remove the moreinfo tag when providing an
answer.

> @@ -548,12 +548,12 @@ if test x"$with_readline" != xno; then
>   [with_readline_inc=$withval],
>   [with_readline_inc="auto"])
>   if test "x$with_readline_inc" = xauto; then
> - AC_CHECK_HEADER(readline.h, [found="yes"], [
> + AC_CHECK_HEADER(readline/readline.h, [found="yes"], [
>   found="no"
>   if test "$cross_compiling" != yes; then

>From here it becomes irrelevant to cross building. The changed lines
are not executed during a cross build.

>   for dir in /usr /usr/local /usr/local/readline 
> /usr/contrib /mingw; do
> - for subdir in include include/readline; 
> do
> - 
> AC_CHECK_FILE($dir/$subdir/readline.h, found=yes)
> + for subdir in include; do
> + 
> AC_CHECK_FILE($dir/$subdir/readline/readline.h, found=yes)
>   if test "$found" = "yes"; then
>   
> TARGET_READLINE_INC="-I$dir/$subdir"
>   break
> 

Helmut

Bug#931042: unblock: bzip2/1.0.6-9.1

[Salvatore Bonaccorso]

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

Hi,

Please unblock package bzip2, it fixes CVE-2019-12900 (tracked as
#930886) in the BTS itself.

> bzip2 (1.0.6-9.1) unstable; urgency=high
> 
>   * Non-maintainer upload.
>   * Make sure nSelectors is not out of range (CVE-2019-12900)
> (Closes: #930886)

AFAICS autopkgtest runs are still running, so we might want to wait
for the results before a possible unblock?

unblock bzip2/1.0.6-9.1

Regards,
Salvatore
diff -Nru bzip2-1.0.6/debian/changelog bzip2-1.0.6/debian/changelog
--- bzip2-1.0.6/debian/changelog2018-08-14 21:28:22.0 +0200
+++ bzip2-1.0.6/debian/changelog2019-06-24 22:15:37.0 +0200
@@ -1,3 +1,11 @@
+bzip2 (1.0.6-9.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Make sure nSelectors is not out of range (CVE-2019-12900)
+(Closes: #930886)
+
+ -- Salvatore Bonaccorso   Mon, 24 Jun 2019 22:15:37 +0200
+
 bzip2 (1.0.6-9) unstable; urgency=medium
 
   [ Santiago Ruano Rincón ]
diff -Nru 
bzip2-1.0.6/debian/patches/Make-sure-nSelectors-is-not-out-of-range.patch 
bzip2-1.0.6/debian/patches/Make-sure-nSelectors-is-not-out-of-range.patch
--- bzip2-1.0.6/debian/patches/Make-sure-nSelectors-is-not-out-of-range.patch   
1970-01-01 01:00:00.0 +0100
+++ bzip2-1.0.6/debian/patches/Make-sure-nSelectors-is-not-out-of-range.patch   
2019-06-24 22:15:37.0 +0200
@@ -0,0 +1,34 @@
+From: Albert Astals Cid 
+Date: Tue, 28 May 2019 19:35:18 +0200
+Subject: Make sure nSelectors is not out of range
+Origin: 
https://gitlab.com/federicomenaquintero/bzip2/commit/74de1e2e6ffc9d51ef9824db71a8ffee5962cdbc
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2019-12900
+Bug-Debian: https://bugs.debian.org/930886
+
+nSelectors is used in a loop from 0 to nSelectors to access selectorMtf
+which is
+   UCharselectorMtf[BZ_MAX_SELECTORS];
+so if nSelectors is bigger than BZ_MAX_SELECTORS it'll do an invalid memory
+access
+
+Fixes out of bounds access discovered while fuzzying karchive
+---
+ decompress.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/decompress.c b/decompress.c
+index ab6a624db17a..f3db91d14f6e 100644
+--- a/decompress.c
 b/decompress.c
+@@ -287,7 +287,7 @@ Int32 BZ2_decompress ( DState* s )
+   GET_BITS(BZ_X_SELECTOR_1, nGroups, 3);
+   if (nGroups < 2 || nGroups > 6) RETURN(BZ_DATA_ERROR);
+   GET_BITS(BZ_X_SELECTOR_2, nSelectors, 15);
+-  if (nSelectors < 1) RETURN(BZ_DATA_ERROR);
++  if (nSelectors < 1 || nSelectors > BZ_MAX_SELECTORS) 
RETURN(BZ_DATA_ERROR);
+   for (i = 0; i < nSelectors; i++) {
+  j = 0;
+  while (True) {
+-- 
+2.20.1
+
diff -Nru bzip2-1.0.6/debian/patches/series bzip2-1.0.6/debian/patches/series
--- bzip2-1.0.6/debian/patches/series   2018-08-13 13:29:27.0 +0200
+++ bzip2-1.0.6/debian/patches/series   2019-06-24 22:15:37.0 +0200
@@ -7,3 +7,4 @@
 bzip2recover-CVE-2016-3189.patch
 bzdiff-tmpdir-spaces.diff
 40-bzdiff-l.patch
+Make-sure-nSelectors-is-not-out-of-range.patch

Bug#930890: [Pkg-electronics-devel] Bug#930890: ghdl: Debian ghdl.wrapper prevents build when GHDL is not already installed.

[Jonathan McDowell]

Control: severity -1 wishlist
Control: retitle -1 Update GHDL packaging for newer releases

On Sun, Jun 23, 2019 at 11:57:33PM +0200, Pavel Pisa wrote:
> On Sunday 23 of June 2019 10:52:47 Jonathan McDowell wrote:
> > On Sat, Jun 22, 2019 at 12:26:36AM +0200, Pavel Pisa wrote:
> > > Source: ghdl
> > > Version: 0.36+20190617
> >
> > This is not a version of GHDL from Debian. testing/unstable both have
> > 0.35+git20181129+dfsg-3. I don't think this is a valid bug against the
> > Debian package - it seems that you've obtained an updated package from
> > somewhere else, or have manually updated to a newer release?
> 
> I have used original Debian package as "debian" directory
> source to port newer GHDL version for Debian Buster.
> 
> I am not sure if the problem applies to old version,
> but solution should work for all versions. I have built older
> version but on the system where GHDL has already been installed.
> So I expect that the problem may be there as well.

You have raised a release critical bug stating the package currently in
Debian fails to build from source. I think what you wanted to raise was
a wishlist bug requesting the packaging be updated to support newer
versions of GHDL. Retitling and updating the severity to indicate this
fact. This can be looked at once we have Buster released.

(I've confirmed that I can still build 0.35+git20181129+dfsg-3 in a
clean sbuild environment, so the FTBFS does not apply to the Debian
package and thus there's no need to fix it to ensure it's ok for Buster.)

J.

-- 
/-\ |   Evil is as evil does, but evil
|@/  Debian GNU/Linux Developer | doesn't wear shoes.
\-  |

Bug#926556: unblock: yubikey-personalization/1.19.3-3

[Nicolas Braud-Santoni]

On Sun, Jun 09, 2019 at 08:25:37PM +0200, Paul Gevers wrote:
> Happened. Unblocked, thanks.

Hi, Paul, Niels, and Afif,

Thank you very much for taking care of this :)


I also wanted to apologise for dropping off for such a long time.

As you noticed, I was stuck with no debian-keyring update happening and not
finding anyone willing to sponsor; then, some personal stuff happened (of the
very-unfun kind) which made me entirely unavailable for several months, and
I'm only now starting to recover...


Best,

  nicoo


signature.asc
Description: PGP signature

Bug#864320: [RFC] Changing the default cursor on the Linux console?

[floss]

In Bash it is possible to set a feature that runs when a command runs
called precmd to an ANSI sequence that sets a non-blinking block
cursor.  This make Bash usable.

However, that fails if there is no Bash or you not have your .bashrc.
There are shell-like entitities that are needed to fix booting.

Also, Emacs still blinks!  It seems to be either the Linux console or
the Emacs C code. Elisp lets you control blinking if you are running
Emacs in an terminal under X or as GUI uner X, but not if you are
running Emacs in the Linux console.  So if you need Emacs to fix a
booting problem, you can't use it if you have problems with blinking.

Finally, an off-topic comment that white and blue are too bright at
night for me, and that the debconf blue and grey have the same problem
(the red is OK).  Not all can physically adjust their monitors.  What
would be good is the ability to adjust the console text color to
amber, and debconf to a contrasty amber theme, and brightness.

Bug#928099: publishing private e-mail

[Tong Sun]

Hi All,

I'm sorry if my message come out wrong, and being perceived as unfriendly.
That was not my intention, and I'm sorry that people feel that way.

Again, I was trying to say that, we were discussing the public matters that
affects the package authors, thus affects the public, and I should have
included 928...@bugs.debian.org at the very beginning.

And I'm sorry for not having done that sooner, which might have changed
everything, or might be not. But I'll start doing it now.




On Sun, Jun 16, 2019 at 10:39 AM Mo Zhou - lu...@debian.org
 wrote:

> Hi Tong Sun,
>
> Please be respectful to the others. Whatever the mail address prefix
> the others use, the others have the right to make private discussion
> and free speech because these are fundamental rights. I don't know
> what happend but your comments are really not friendly.
>
> If you really received problematic messages from a Debian developer,
> please consider reaching out the Anti-harrasment team or DPL for help,
> privately.
>
> > On Sat, Jun 15, 2019 at 07:55:04AM -0400, Tong Sun wrote:
> >> >
> >> > To me, your message, bearing a @debian.org address, should represent
> >> > that of debian.org, both privately or publicly, and never says thing
> >> that you will regret later, or say it publicly. Especially we are
> >> discussing public matters, that affects the public and all authors.
> >>
> >> Such decision should not be conducted behind close doors.
>
>
>

Bug#931041: Acknowledgement (basez: fails to decode base64url strings with the padding trimmed)

[Ilguiz Latypov]

Sorry it failed even with the padding, so I don't know what is failing
in basez.

Bug#931041: basez: fails to decode base64url strings with the padding trimmed

[ILGUIZ LATYPOV]

Package: basez
Version: 1.6-3
Severity: important
Tags: upstream

Dear Maintainer,

   * Decoding a JWT signature showed that omitting the padding (as
 required by one of the JWS RFC) causes a failure in base64url -d.

$ echo -n 
Igzmk82YO1cNEjjEF0WQMEv4tGPLrgm43Yrh_bFvHStV2Qju-eebyN82F-fASOZqQxOGL9sU_g6ewloKNk5yO7Dt__YqJ9GROXiovYD6cM4G2UboYn7BCf4lH84kfRNZAxrVNOOC50aYuVTvTGQrxXUooq9KnCkQzeZLbl26Vw7Yq0fP_D39ztoNu5Oyy0Nar_iHRyyPqAyia3VhrcETIK199IUG4QK0Rj2UIfEg6qPhVrE2rVKZy2zd4s871sLg0XuqOdwwZsYsIBP0tcd2C2-6HTfDNlBEoWo_XtF3DbkvNiBA75xHcxlXkq__ytCdicXDkdfOiS39IfsyzzmGEg==
 | tr -- '-_' '+/' | base64 -d | xxd -g0 -ps -c20
220ce693cd983b570d1238c4174590304bf8b463
cbae09b8dd8ae1fdb16f1d2b55d908eef9e79bc8
df3617e7c048e66a4313862fdb14fe0e9ec25a0a
364e723bb0edfff62a27d1913978a8bd80fa70ce
06d946e8627ec109fe251fce247d1359031ad534
e382e74698b954ef4c642bc57528a2af4a9c2910
cde64b6e5dba570ed8ab47cffc3dfdceda0dbb93
b2cb435aaff887472c8fa80ca26b7561adc11320
ad7df48506e102b4463d9421f120eaa3e156b136
ad5299cb6cdde2cf3bd6c2e0d17baa39dc3066c6
2c2013f4b5c7760b6fba1d37c3365044a16a3f5e
d1770db92f362040ef9c4773195792afffcad09d
89c5c391d7ce892dfd21fb32cf398612

$ echo -n 
Igzmk82YO1cNEjjEF0WQMEv4tGPLrgm43Yrh_bFvHStV2Qju-eebyN82F-fASOZqQxOGL9sU_g6ewloKNk5yO7Dt__YqJ9GROXiovYD6cM4G2UboYn7BCf4lH84kfRNZAxrVNOOC50aYuVTvTGQrxXUooq9KnCkQzeZLbl26Vw7Yq0fP_D39ztoNu5Oyy0Nar_iHRyyPqAyia3VhrcETIK199IUG4QK0Rj2UIfEg6qPhVrE2rVKZy2zd4s871sLg0XuqOdwwZsYsIBP0tcd2C2-6HTfDNlBEoWo_XtF3DbkvNiBA75xHcxlXkq__ytCdicXDkdfOiS39IfsyzzmGEg==
 | base64url -d
base64url: invalid input

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

Kernel: Linux 4.18.16-x86_64-linode118 (SMP w/1 CPU core; PREEMPT)
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)

Versions of packages basez depends on:
ii  libc6  2.28-10

basez recommends no packages.

basez suggests no packages.

-- no debconf information

Bug#930012: gcc-8: ICE building firefox 68.0~b6-2 on s390x and i386

[Mike Hommey]

On Tue, Jun 25, 2019 at 10:46:37AM +0900, Mike Hommey wrote:
> On Thu, Jun 13, 2019 at 05:03:33PM +0200, Olivier Tilloy wrote:
> > Ubuntu is also affected (all supported releases, from 16.04 to 19.10,
> > builds are being done in
> > https://launchpad.net/~mozillateam/+archive/ubuntu/firefox-next/+packages).
> > 
> > I don't have a workaround, but here are some data points:
> >  - builds on 16.04 exhibit the same problem, this is with GCC 6.4.0
> >  - https://skia.googlesource.com/skcms/+/7362d88 is the change in skcms (a
> > skia subproject) that triggers the build error, it is the commit
> > immediately after the version that's in firefox 67 source tarballs
> 
> FWIW, reverting that change only doesn't work around the issue.

Sorry, forget about this, my test was doing the opposite: apply that
change to 67, and that did break the build.

Mike

Bug#930293: unblock: docker.io/18.09.1+dfsg1-7

[Arnaud Rebillout]

On 6/25/19 8:26 AM, Shengjing Zhu wrote:
>
>>> Well, after adding this func back, the tests run and the host doesn't
>>> crash.
>>>
>>> However the tests still can't pass in schroot, the log says:
>> [...]
>>
>>> Short version: these tests need privileged permission.
>> And your schroot doesn't provide those. How about any better container?
>> How about buildds?
>>
> You can have privileged permission in container if you give it such
> permission, like SYS_ADMIN permission, or in docker --privileged.
>
> But none of buildds is allowed. It's too dangerous. Only VM is suitable
> for such tests.
>

In docker.io we already apply a bunch of patches to disable tests that
require root or that require network. Unless I'm mistaken, it's quite
common to do that in debian packaging??

Even though it's not ideal, I don't know of any better solution during
the package build. Then there is autopkgtest of course, but I'm not
familiar with it and I don't know if it's suitable for running a test
suite with full capabilities (ie. root and network).

Bug#930293: unblock: docker.io/18.09.1+dfsg1-7

[Arnaud Rebillout]

On 6/23/19 5:09 PM, Paul Gevers wrote:
>
>> +  * Non-maintainer upload.
> This I worries me. Apparently Arnaud didn't consider it appropriate to
> upload the patch and I don't see an ACK from any of the maintainers. In
> my opinion, trying to save docker.io for buster isn't appropriate via a
> non-ACKed change so terribly late. Do the maintainers agree with this
> approach?


Hi and sorry to be late.

I couldn't upload the patch as the test suite crashed. I couldn't have
time to investigate. I planned to do that this week-end but I got sick
and I've been KO for 3 days. Now I'm back to life.

So just to clarify my position, yes I very much want docker.io to be in
Buster, it represents around 1 year of work, seeing it all end in the
garbage would be a bit hard to swallow but hey, that's life.

As for whether it's suitable to be in Buster, as it's been said
somewhere in this thread, it's up to the release team. Docker is what it
is, and packaging it in Debian doesn't make it anything different. As a
maintainer I can afford to maintain the packaging and import security
patches (well except I failed to be in time for this one...). So I won't
fuss if you think it's not suitable, I understand.

Thanks,

Bug#930012: gcc-8: ICE building firefox 68.0~b6-2 on s390x and i386

[Mike Hommey]

On Thu, Jun 13, 2019 at 05:03:33PM +0200, Olivier Tilloy wrote:
> Ubuntu is also affected (all supported releases, from 16.04 to 19.10,
> builds are being done in
> https://launchpad.net/~mozillateam/+archive/ubuntu/firefox-next/+packages).
> 
> I don't have a workaround, but here are some data points:
>  - builds on 16.04 exhibit the same problem, this is with GCC 6.4.0
>  - https://skia.googlesource.com/skcms/+/7362d88 is the change in skcms (a
> skia subproject) that triggers the build error, it is the commit
> immediately after the version that's in firefox 67 source tarballs

FWIW, reverting that change only doesn't work around the issue.

Mike

Bug#930293: unblock: docker.io/18.09.1+dfsg1-7

[Shengjing Zhu]

On Mon, Jun 24, 2019 at 09:08:07PM +0200, Paul Gevers wrote:
[...]
> > The bug is not from upstream. Previously a file was removed from
> > upstream tarball, named engine/pkg/chrootarchive/archive_test.go, which
> > has an important init func:
[...]
> Are you saying this file is only needed for testing? This file isn't
> needed for docker.io itself? Why was it stripped in the first place?
> 

All files with _test.go suffix are for tests in Go.
The maintainer commented in debian/clean:

## Privileged tests:
...
engine/pkg/chrootarchive/archive_test.go

> > Well, after adding this func back, the tests run and the host doesn't
> > crash.
> > 
> > However the tests still can't pass in schroot, the log says:
> 
> [...]
> 
> > Short version: these tests need privileged permission.
> 
> And your schroot doesn't provide those. How about any better container?
> How about buildds?
> 

You can have privileged permission in container if you give it such
permission, like SYS_ADMIN permission, or in docker --privileged.

But none of buildds is allowed. It's too dangerous. Only VM is suitable
for such tests.

-- 
Shengjing Zhu


signature.asc
Description: PGP signature

Bug#930012: gcc-8: ICE building firefox 68.0~b6-2 on s390x and i386

[Mike Hommey]

On Thu, Jun 20, 2019 at 07:17:26AM +0200, Olivier Tilloy wrote:
> I am attaching a patch for skcms that fixes the firefox build on s390x
> and i386. Not submitted upstream yet.

Note that mips and mipsel are affected as well.

Mike

Bug#931040: unblock: musescore/2.3.2+dfsg2-7

[Thorsten Glaser]

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

Please unblock package musescore

I’ve found out, from Sunday’s dev chat discussion, that MuseScore
connects to upstream’s webserver on startup (#931021), and we
generally don’t like applications to phone home without explicit
permission.

I’ve tested this with systrace and verified both the fix and the
affected versions. Please unblock if you agree this is RC.

(including a git diff, but I confirmed it’s identical to debdiff)

--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+musescore (2.3.2+dfsg2-7) unstable; urgency=high
+
+  * Disable webkit functionality (Closes: #931021)
+
+ -- Thorsten Glaser   Mon, 24 Jun 2019 18:07:46 +0200
+
 musescore (2.3.2+dfsg2-6) unstable; urgency=medium
 
   * Workaround for DEP 5 syntax in a complex case
--- a/debian/control
+++ b/debian/control
@@ -28,7 +28,6 @@ Build-Depends: cmake,
libpulse-dev,
libqt5opengl5-dev,
libqt5svg5-dev,
-   libqt5webkit5-dev,
libqt5xmlpatterns5-dev,
libsndfile1-dev (>= 1.0.25),
portaudio19-dev,
--- a/debian/rules
+++ b/debian/rules
@@ -37,6 +37,9 @@ ifneq (linux,${DEB_HOST_ARCH_OS})
 CMAKE_DEFS+=   -DBUILD_PORTMIDI=OFF
 endif
 
+# disable phoning home
+CMAKE_DEFS+=   -DBUILD_WEBKIT=OFF
+
 override_dh_auto_configure:
dh_auto_configure -- ${CMAKE_DEFS}
 


unblock musescore/2.3.2+dfsg2-7

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Bug#931024: kthresher: Uses Package.section, incompatible with python-apt 1.9

[Darshaka Pathirana]

forwarded 931024 https://github.com/rackerlabs/kthresher/issues/80
thanks

Hi Julian,

On 6/24/19 7:11 PM, Julian Andres Klode wrote:
> Package: kthresher
> Severity: normal
> User: de...@lists.debian.org
> Usertags: apt-1.9.0
> 
> According to codesearch.d.n, kthresher contains trhe line:
> 
> "kernel" in pkg.section and re.match(kernel_image_regex, pkg_name)
> 
> The use of the section on packages has been deprecated ages ago, as
> it can vary between versions. 
> 
> This causes kthresher to stop working with apt 1.9, so please migrate to
> using a version's section after the buster release.

Thanks for the bug report.

I've opened an upstream issue[1] to handle this bug.

 [1] https://github.com/rackerlabs/kthresher/issues/80

Regards,
 - Darsha



signature.asc
Description: OpenPGP digital signature

Bug#928963: [pkg-gnupg-maint] Bug#928963: fixed in gnupg2 2.2.13-2

[Daniel Kahn Gillmor]

Hi Paul--

On Sat 2019-06-22 20:51:00 +0200, Paul Gevers wrote:
> On Tue, 14 May 2019 06:18:31 + Daniel Kahn Gillmor
>  wrote:
>>  gnupg2 (2.2.13-2) unstable; urgency=medium
>>  .
>>* Correct gpg-wks-server manpage (Closes: #927431) Thanks, ju xor!
>>* Fix handling private keys with comments (Closes: #928963, #928964)
>>* clean up logcheck rules for gpg-agent (Closes: #918466)
>>* Update gpg-wks-client.1 (Closes: #918586)
>>* cherry-pick more patches from upstream STABLE-BRANCH-2-2
>
> Is there any reason that we shouldn't want to unblock this for buster
> (i.e. is there any reason why you didn't file an unblock bug request)?

Filing an unblock for gnupg2 version 2.2.13-2 for buster is on my stack
of things to do, but i'm quite far behind on other work.  I do think it
would be useful to have, and i welcome any help in filing such an
unblock request.

This change includes several upstream cleanup changes beyond the
2.2.12-1 that is in buster right now, in particular (from upstream's
NEWS):

  * gpg: Implement key lookup via keygrip (using the & prefix).

  * gpg: Allow generating Ed25519 key from existing key.

  * gpg: Emit an ERROR status line if no key was found with -k.

  * gpg: Stop early when trying to create a primary Elgamal key.  [#4329]

  * gpgsm: Print the card's key algorithms along with their keygrips
in interactive key generation.

  * agent: Clear bogus pinentry cache in the error case.  [#4348]

  * scd: Support "acknowledge button" feature.

  * scd: Fix for USB INTERRUPT transfer.  [#4308]

  * wks: Do no use compression for the the encrypted challenge and
response.


Since the gnupg2 source produces a udeb for gpgv, there are likely to be
additional hurdles to clearing the queue. :/

   --dkg


signature.asc
Description: PGP signature

Bug#929666: ITP: conmon -- An OCI container runtime monitor

[Nicolas Braud-Santoni]

X-Debbugs-CC: bir...@rantanplan.org, ja...@ivyleav.es
Control: forcemerge -1 930898

Hi Birger !

Thanks for your interest in getting conmon packaged.  :)

Jamie (in CC) and myself are also interested in seeing it land in Debian, as
it's a dependency of podman (that we are packaging), and started working on this
under podman-team on Salsa.

I uploaded (our version of) conmon/0.3.0-1 2 days ago, and it's currently in
the NEW review queue.


Sorry for missing your ITP (and some related ones): it seems like wnpp.d.n is
currently broken, it doesn't list results when searching for conmon or other
packages with recent ITPs...

As a result, I opened my own (#930898) but this mail should merge it back with
yours.


In any case, I would love to join efforts with you, and I will send you an
invite to podman-team. I would add you as a co-uploader on the package, help you
with reviews and sponsored uploads, and (if you want) work with you towards
becoming a DM (or a DD) so you can maintain the package independently.


Best,

  nicoo



On Tue, May 28, 2019 at 10:10:00AM +0200, Birger Schacht wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Birger Schacht 
> 
> * Package name: conmon
>   Version : 0.2.0
>   Upstream Author : Peter Hunt
> * URL : https://github.com/containers/conmon
> * License : Apache-2.0
>   Programming Lang: C
>   Description : An OCI container runtime monitor.
> 
> Conmon is a monitoring program and communication tool between a
> container manager (like podman or CRI-O) and an OCI runtime (like runc
> or crun) for a single container.
> It is a run dependency for podman.


signature.asc
Description: PGP signature

Bug#931039: debhelper: something in the dh sequencer changes the tIME chunk of installed PNGs

[Thorsten Glaser]

Package: debhelper
Severity: normal

While comparing builds of musescore -6 and -7 I found unexpected
changes in the PNG files that are installed, they change the tIME
chunk to, apparently, the changelog time:

--- home/tg/Misc/Vendor/musescore/share/wallpaper/paper1.sng
+++ paper1.sng
@@ -6,13 +6,13 @@ IHDR {
 bKGD {red: 255;  green: 255;  blue: 255;}
 pHYs {xpixels: 3779; ypixels: 3779; per: meter;}  # (96 dpi)
 tIME {
-# 10 Nov 2001 20:43:56 GMT
-year:   2001
-month:  11
-day:10
-hour:   20
-minute: 43
-second: 56
+# 24 Jun 2019 16:07:46 GMT
+year:   2019
+month:  6
+day:24
+hour:   16
+minute: 7
+second: 46
 }
 IMAGE {
 pixels hex

While I’m sure the reproducible builds people appreciate
limiting the mtime, raising it is not done otherwise.

This also has potential to break applications (e.g. that
rely, in tests or otherwise, on the files).

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages debhelper depends on:
pn  autotools-dev
pn  dh-autoreconf
pn  dh-strip-nondeterminism  
ii  dpkg 1.19.7
pn  dpkg-dev 
pn  dwz  
ii  file 1:5.35-4
pn  libdpkg-perl 
ii  man-db   2.8.5-2
ii  perl 5.28.1-6
pn  po-debconf   

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  

Bug#930440: RFP: podman -- Library and tool for running OCI-based containers in Pods

[Nicolas Braud-Santoni]

X-Debbugs-CC: only...@debian.org, ja...@ivyleav.es

Hi Dmitry !

Thanks for your interest in getting podman packaged.  :)

Jamie (in CC) and myself are also interested in seeing podman land in Debian,
started working towards this, and made podman-team on Salsa.

Sorry for only informing you now, but I missed your ITP (and some related ones):
it seems like wnpp.d.n is currently broken, it doesn't list results when 
searching
for podman or other packages with ITPs...

In any case, I would love to join efforts with you, and I will send you an
invite to podman-team.


Best,

  nicoo


signature.asc
Description: PGP signature

Bug#931038: missing Recommends: for shim-signed

[Steve McIntyre]

On Tue, Jun 25, 2019 at 12:17:20AM +0100, Steve McIntyre wrote:
>Source: grub2
>Version: 2.02+dfsg1-19
>Severity: serious
>Tags: patch
>
>The grub-efi-amd64-signed package recommends shim-signed, but the
>equivalent grub-efi-ia32-signed and grub-efi-arm64-signed packages are
>missing the same Recommends:
>
>Simple tweak needed to the signing-template, MR ready as soon as I get
>a bug# from the BTS for this.

  https://salsa.debian.org/grub-team/grub/merge_requests/11

Happy to merge and upload myself if that's easier.

Arg, only just spotted this in testing for the Buster d-i RC2 build.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
There's no sensation to compare with this
Suspended animation, A state of bliss

Bug#931038: missing Recommends: for shim-signed

[Steve McIntyre]

Source: grub2
Version: 2.02+dfsg1-19
Severity: serious
Tags: patch

The grub-efi-amd64-signed package recommends shim-signed, but the
equivalent grub-efi-ia32-signed and grub-efi-arm64-signed packages are
missing the same Recommends:

Simple tweak needed to the signing-template, MR ready as soon as I get
a bug# from the BTS for this.

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

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

Bug#930932: zenity: Zenity crashes out on Athlon XP CPU.

[Iris (Delta)]

On Tue, 25 Jun 2019 00:44:00 +0200 Alberto Garcia  wrote:
>
> Ah I see, you're running Stretch with a backport of 2.24.2-1.
>
> In the meantime you can roll back to 2.22.7-1_bpo9+1, that one should
> not crash.
>
> Berto
>
>

I didn't even notice the backported packages were installed and I'm not 
sure how that would have been pulled. I'm not sure how I missed this... 
I just force-downgraded everything back to Stable, and now the main 
systems work perfectly. Feel kinda stupid now...


Thanks - you have just saved me a ton of headache. I really appreciate 
the help.


If you do still intend to test any packages on Athlon XP era hardware I 
would be happy to help.

Bug#931037: ftp: tab completion after cd mistakenly local instead of remote

[Thorsten Glaser]

Package: ftp
Version: 0.17-34.1
Severity: important

tg@caas:~ $ ftp ftp.upload.debian.org
Connected to usper.debian.org.
220 ftp.upload.debian.org FTP server
Name (ftp.upload.debian.org:tg): ftp
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd /p

Expected (and verified on MirBSD):
ftp> cd /pub

Got this instead:
ftp> cd /proc/

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages ftp depends on:
ii  libc6 2.28-10
ii  libreadline7  7.0-5
ii  netbase   5.6

ftp recommends no packages.

ftp suggests no packages.

-- no debconf information

Bug#930932: zenity: Zenity crashes out on Athlon XP CPU.

[Alberto Garcia]

On Tue, Jun 25, 2019 at 08:15:49AM +1000, Iris (Delta) wrote:

> > I just uploaded webkit2gtk 2.24.2-2, this should fix your
> > problem. I'd appreciate if you can confirm it.
> >
> > You'll need to update both libjavascriptcoregtk-4.0-18 and
> > libwebkit2gtk-4.0-37.
> 
> This is a Stretch install, with no backports or other repositories
> enabled.

Ah I see, you're running Stretch with a backport of 2.24.2-1.

I can provide a build for stretch if you can't do it yourself, but
you'll have to wait a few hours.

In the meantime you can roll back to 2.22.7-1_bpo9+1, that one should
not crash.

Berto

Bug#930932: zenity: Zenity crashes out on Athlon XP CPU.

[Iris (Delta)]

On Mon, 24 Jun 2019 21:56:00 +0200 Alberto Garcia  wrote:
> On Mon, Jun 24, 2019 at 09:41:27PM +1000, Iris (Delta) wrote:
> > On Mon, 24 Jun 2019 11:35:52 +0200 Alberto Garcia 
 wrote:

> > >
> > > I suppose this won't solve the problem, but can you try to set these
> > > evironment variables (or a combination thereof) and see if it works?
> > >
> > > JavaScriptCoreUseJIT=0
> > > JSC_useJIT=false
> >
> > These resulted in no changes.
> >
> > I also cannot replace these systems (several hundred) at this time.
>
> I just uploaded webkit2gtk 2.24.2-2, this should fix your problem. I'd
> appreciate if you can confirm it.
>
> You'll need to update both libjavascriptcoregtk-4.0-18 and
> libwebkit2gtk-4.0-37.
>
> Berto
>
>

Not to pester, but how do I test this?

When attempting to pull the package (I believe you have it in Sid) it 
wants to rip apart most of Debian Stable, so I didn't do that. I tried 
downloading and manually dpkg -i the packages, but that didn't work either.


This is a Stretch install, with no backports or other repositories enabled.

Bug#931036: RFS: dhelp/0.6.26 QA, RC

[Коля Гурьев]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "dhelp"

 Package name : dhelp
 Version  : 0.6.26
 License  : GPL-2
 Section  : doc

It builds those binary packages:

  dhelp - online help system

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/dhelp

Alternatively, one can download the package with dget using this
command:

  dget -x https://mentors.debian.net/debian/pool/main/d/dhelp/dhelp_0.6.26.dsc

Changes since the last upload:

 * Do not remove entire /usr/share/doc/HTML directory while reindexing
   or deinstalling (closes: #929850).
 * Add the sensible-utils package as runtime dependency.
 * Use Git repository at the salsa.debian.org site.

Regards,
 Nicholas Guriev

Bug#931035: hidapi: New active fork and 0.9.0 release

[Filip Kubicz]

Source: hidapi
Severity: normal

Dear Maintainer,

After original repository signal11/hidapi was no longer maintained, it was
decided to host the fork in libusb organization:

https://github.com/libusb/hidapi

In this new repository the development is continued and recently version 0.9.0
with some important fixes have been released:

https://github.com/libusb/hidapi/releases

It would be great to update hidapi package and other connected Debian packages.

Kind regards,
Filip



-- System Information:
Debian Release: buster/sid
  APT prefers bionic-updates
  APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 
'bionic-backports'), (500, 'bionic')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-50-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#931033: debian-parl: shouldn't depend on libreoffice-ogltrans (needs rebuild with fixed boxer-data)

[Rene Engelhard]

Source: debian-parl
Version: 1.9.18
Severity: important

Hi,

I seriously don't get why a metapackage for "parliamentary work" needs
to depend on libreoffice-ogltrans. Probably just because it includes
the presentation class of boxer-data and that includes it :/

This needs go away. See the eact reasoning in #931032.

This bug will be increased to serious once the 6.3 packages will be
uploaded to unstable. Which will happen really soon after the buster
release (will upload 6.3 rc1 since there's no need/would be a waste of
time to deal with 6.2.x and bugs only fixed in 6.3...), and that will be
the days after the buster release:
https://wiki.documentfoundation.org/ReleasePlan/6.3#6.3.0_release

Regards,

Rene

-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: arm64 (aarch64)

Kernel: Linux 4.19.0-5-arm64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#931032: boxer-data: needs to remove transitional package libreoffice-ogltrans from Desktop/office/libreoffice/presentation

[Rene Engelhard]

Package: boxer-data
Version: 10.7.6
Severity: important

Hi,

$ grep -ri ogltrans *
CHANGES:837f15f Fix exclude only software rasterizer: Include gvfs (fixing disk 
hot-plug detection) mplayer2 and libreoffice-ogltrans. Include recommendations 
evolution-data-server libvisual-0.4-plugins libwebkitgtk-1.0-0.
stretch/classes/Desktop/office/libreoffice/presentation.yml:- 
libreoffice-ogltrans

That package was removed last year:

libreoffice (1:6.1.4-2) unstable; urgency=medium

  * debian/patches/m68k-fix-parameter-type.patch: as name says,
thanks John Paul Adrian Glaubitz (closes: #917539)
  * debian/patches/lo-xlate-lang-be.diff: belarussian -> belarusian
(closes: #917795)

  * debian/tests/smoketest: fix
  * debian/rules: fix libcmis version check (and mysqlcppconn build-dep)
  * debian/rules, debian/control*in, debian/scripts/gid2pkgdirs.sh:
merge -ogltrans into -impress

 -- Rene Engelhard   Sun, 30 Dec 2018 15:25:38 +

(and

libreoffice (1:6.2.0~rc2-1) experimental; urgency=medium

  * New upstream release candidate
- belarussian -> belarusian (closes: #917795)

  * debian/patches/m68k-fix-parameter-type.patch: as name says,
thanks John Paul Adrian Glaubitz (closes: #917539)

  * debian/rules:
- revert 1:6.2.0~rc1-2 change
  * debian/rules, debian/control*in, debian/scripts/gid2pkgdirs.sh:
merge -ogltrans into -impress
  * debian/control.in: bump recommends for apparmor to >= 2.13.1 and conflict
against apparmor (<< 2.13.1~) (closes: #918499)
  * debian/control.in, debian/rules: make apparmor recommends/conflicts
dependant on ENABLE_APPARMOR_PROFILES=y

 -- Rene Engelhard   Fri, 11 Jan 2019 17:19:56 +

for 6.2.x+)

Besides the fact that I think it's questionable for _parlament stuff_
pulling in that as a depends (which happens via this class for
debian-perl), this one needs to be removed.
For buster there (of course) is a transitional package; for bullseye
it's already removed. Thus we get
https://release.debian.org/transitions/html/auto-libreoffice.html
again).

After this, debian-parl and debian-design need to be rebuilt. Will file
own bugs for those.

Regards,

Rene

-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: arm64 (aarch64)

Kernel: Linux 4.19.0-5-arm64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#904518: Add support for SPDX-License-Identifier

[Michael Biebl]

Package: licensecheck
Version: 3.0.31-3
Followup-For: Bug #904518

Hi there,

are the any news here?
Judging from
https://codesearch.debian.net/search?q=SPDX-License-Identifier
SPDX-License-Identifier usage seems to be quite significant already.

Regards,
Michael

-- System Information:
Debian Release: 10.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages licensecheck depends on:
ii  libgetopt-long-descriptive-perl  0.103-2
ii  libmoo-perl  2.003004-2
ii  libnamespace-clean-perl  0.27-1
ii  libpath-iterator-rule-perl   1.014-1
ii  libpath-tiny-perl0.108-1
ii  libpod-constants-perl0.19-1
ii  libregexp-pattern-license-perl   3.0.31-4
ii  libscalar-list-utils-perl1:1.50-1+b1
ii  libsort-key-perl 1.33-2+b1
ii  libstrictures-perl   2.05-1
ii  libstring-copyright-perl 0.003006-1
ii  libstring-escape-perl2010.002-2
ii  libtry-tiny-perl 0.30-1
ii  perl 5.28.1-6

licensecheck recommends no packages.

Versions of packages licensecheck suggests:
ii  bash-completion  1:2.8-6

-- no debconf information

Bug#924331: RFA: pdf-redact-tools -- PDF Redact Tools helps with securely redacting and stripping

[Loic Dachary]

Hi Kunal,

Great news, thanks for stepping in :-) The VCS repository is at 
https://salsa.debian.org/pkg-privacy-team/pdf-redact-tools. Please let me know 
if you need anything else.

Cheers

On 6/24/19 11:12 PM, Kunal Mehta wrote:
> Hi,
> 
> On Mon, 11 Mar 2019 18:23:15 +0100 Loic Dachary  wrote:
>> pdf-redact-tools is one of many tools journalists need to protect the 
>> anonymity of their sources. Despite my desire to maintain the package and my 
>> best efforts, I do not feel safe within Debian to do so. I kindly ask 
>> someone to takeover.
> 
> I'm happy to take over packaging for this, it looks rather
> straightforward, and is in my field of interest.
> 
> Is the packaging in a VCS repository anywhere?
> 
> And if Vipul is still interested, I can work with them as well.
> 
> -- Kunal
> 



signature.asc
Description: OpenPGP digital signature

Bug#930942: warzone2100: Segfault upon multiplayer "Start Hosting Game"

[Phil Morrell]

Control: tags -1 patch
thanks

On Mon, Jun 24, 2019 at 03:52:16PM +0200, Bernhard Übelacker wrote:
> Attached patch calls EC_KEY_dup just in case of a not null key.
> With packages rebuilt in Stretch and Buster with this
> patch applied, the same crash does not manifest and a multiplayer
> with one nullbot was possible.

My man, you are a legend, thank you for the quick patch - I can happily
confirm I'm now able to play LAN multiplayer! The packaging is still in
a pretty bad state, and apparently the new 3.3.0-beta1 is more stable
than 3.2.3, so I'll probably still work on it for after buster:

https://salsa.debian.org/emorrp1-guest/warzone2100/


signature.asc
Description: PGP signature

Bug#924331: RFA: pdf-redact-tools -- PDF Redact Tools helps with securely redacting and stripping

[Kunal Mehta]

Hi,

On Mon, 11 Mar 2019 18:23:15 +0100 Loic Dachary  wrote:
> pdf-redact-tools is one of many tools journalists need to protect the 
> anonymity of their sources. Despite my desire to maintain the package and my 
> best efforts, I do not feel safe within Debian to do so. I kindly ask someone 
> to takeover.

I'm happy to take over packaging for this, it looks rather
straightforward, and is in my field of interest.

Is the packaging in a VCS repository anywhere?

And if Vipul is still interested, I can work with them as well.

-- Kunal

Bug#930858: gif2png: "not expected to be able to deal with arbitrarily broken input"

[Moritz Mühlenhoff]

On Mon, Jun 24, 2019 at 01:05:13PM +0200, Erik Schanze wrote:
> Hi all,
> 
> 
> this is OK for me, Because Upstream (ESR) changed programming language to 
> "GO" recently (3.0.0) and this is not my cup of tea.
> 
> I decided to orphan it, but popcorn count is low, so it should be removed.

Can you please file a removal bug against ftp.debian.org, then?

Cheers,
Moritz

Bug#927226: libpaper1: Fresh RC1 install doesn't configure /etc/papersize

[Giuseppe Sacco]

Hello Thorsten,
thank you very much for your testing. Indeed the bug required more
fixing than what I did.

I did follow your steps for reproducing it, and now I have a new
package that fix it. If you want to try it, please fetch it here:
https://eppesuigoccas.homedns.org/~giuseppe/debian/libpaper1_1.1.27_amd64.deb
https://eppesuigoccas.homedns.org/~giuseppe/debian/libpaper-utils_1.1.27_amd64.deb
or
dget https://eppesuigoccas.homedns.org/~giuseppe/debian/libpaper_1.1.27.dsc

Bye,
Giuseppe

Bug#930777: linux-image-4.19.0-5-amd64: console screen not working

[Jürgen Bausa]

Found this bug that seems to be related:

https://bugs.freedesktop.org/show_bug.cgi?id=109215

There, the kernel option "i915.fastboot=1" is suggested to solve the problem.

I tried this on my system and it solved the problem.

Jürgen

Bug#931031: expat: CVE-2018-20843

[Salvatore Bonaccorso]

Source: expat
Version: 2.2.6-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/libexpat/libexpat/issues/186

Hi,

The following vulnerability was published for expat.

CVE-2018-20843[0]:
| In libexpat in Expat before 2.2.7, XML input including XML names that
| contain a large number of colons could make the XML parser consume a
| high amount of RAM and CPU resources while processing (enough to be
| usable for denial-of-service attacks).


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-20843
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20843
[1] https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5226
[2] https://github.com/libexpat/libexpat/issues/186
[3] https://github.com/libexpat/libexpat/pull/262

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#931020: lz4json FTCBFS: does not use cross tools

[Adam Borowski]

Control: tags -1 +forwarded
Control: forwarded -1 https://github.com/andikleen/lz4json/pull/12

On Mon, Jun 24, 2019 at 05:36:08PM +0200, Helmut Grohne wrote:
> lz4json fails to cross build from source, because it does not pass cross
> tools to make. Using dh_auto_build partially fixes that, but the
> upstream Makefile still hard codes pkg-config. The attached patch fixes
> both and makes lz4json cross buildable. Please consider applying it.

Thanks, forwarded upstream.

-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.

Bug#930965: coreutils: seq 84x slower with --equal-width

[Barak A. Pearlmutter]

Yes, I suppose it's a performance wishlist bug. But really there is no
reason for it to use stdio formatting; really the zero-padded case is
no harder to do with direct ascii manipulation than the
non-zero-padded case. (Also GCC should specialize and optimize the
stdio calls, i.e., partially evaluate them, to eliminate the
performance penalty of stdio routines. But let's not go there.)

>   yes 1000| tail -n 1000

This wouldn't accomplish the desired task, wich is to produce output
to write to a file. But even modified to do so, say by using head
instead of tail, it wouldn't work for this particular use case. The
idea is to write something unique to each block so the tricky
capacity-faking controller cannot fool us by hashing together equal
blocks, or whatever sneaky things they do.

But this would work:

$ yes | cat --number > /mnt/test-file &
$ cmp /mnt/test-file <(yes | cat --number)

So you're certainly correct, in that seq isn't really important here.
I was just reporting a performance issue...

Bug#930965: coreutils: seq 84x slower with --equal-width

[Pádraig Brady]

On 23/06/19 18:05, Barak A. Pearlmutter wrote:
> Package: coreutils
> Version: 8.30-3
> Severity: normal
> 
> Was using seq to write some data to test that a cheapo enormous SD card
> isn't faking its capacity. Thought I'd use seq --equal-width just to
> make calculations easier. But jeepers creepers, what a slowdown!
> 
> $ time seq 0 1000 > /dev/null
> 
> real  0m0.358s
> user  0m0.331s
> sys   0m0.018s
> 
> $ time seq --equal-width 0 1000 > /dev/null
> 
> real0m29.562s
> user0m27.968s
> sys 0m0.100s
> 
> $ echo '27.968 / 0.331' | bc
> 84

Right --equal-width currently goes through stdio formatting,
rather than simple ascii manipulation.

The fastest solution for you is probably:
  yes 1000| tail -n 1000

Bug#929652: systemd: sshd processes are not put into the correct slice/scope

[Michal Koutný]

Hi.

Failure to create the session is almost certainly the reason why the
processes are in wrong slice.

Note that the PID that is in journald is PID of the process who
connected to journald obtained via getpeercred. If it forks and the fd
is passed to another process, the logs will misreport the old PID.
(Given different PIDs in very short intervals, I don't think it's the
PID of the listening sshd process but I'm not sure if sshd children
don't fork again. I'd recommend checking also neighbor PIDs found in the
logs.)

To your problem, I guess you're hitting some limits of dbus-daemon, I'd
try increasing
256
for you system dbus-daemon instace.

The second suggestion^W workaround would be to tweak
CPUWeight=/CPUShares= of dbus.service and sshd.service. Given
dbus.service ~2 times more that to sshd.service. This will likely cause
slightly more latency at clients but it can lower the strain on
dbus-daemon so that it brokers all pam_systemd requests.

HTH,
Michal


signature.asc
Description: PGP signature

Bug#931030: ITP: sfxr-qt -- sound effect generator, QtQuick port of sfxr

[Gürkan Myczko]

Package: wnpp
Severity: wishlist

* Package name: sfxr-qt
  Version : 1.2.0
  Upstream Authors: Tomas Pettersson
Aurélien Gâteau
* URL : https://github.com/agateau/sfxr-qt
* License : MIT
  Description : sound effect generator, QtQuick port of sfxr
 This little tool was made to provide a simple means of getting basic 
sound
 effects into a game. You just need to hit a few buttons in this 
application
 to get some largely randomized effects. All the parameters used to 
create

 each sound are manually tweakable to allow fine-tuning if you feel like
 getting your hands dirty.

Package will be availabe at http://phd-sid.ethz.ch/debian/sfxr/qt/git/

Bug#930932: zenity: Zenity crashes out on Athlon XP CPU.

[Alberto Garcia]

On Mon, Jun 24, 2019 at 09:41:27PM +1000, Iris (Delta) wrote:
> On Mon, 24 Jun 2019 11:35:52 +0200 Alberto Garcia  wrote:
> >
> > I suppose this won't solve the problem, but can you try to set these
> > evironment variables (or a combination thereof) and see if it works?
> >
> > JavaScriptCoreUseJIT=0
> > JSC_useJIT=false
> 
> These resulted in no changes.
> 
> I also cannot replace these systems (several hundred) at this time.

I just uploaded webkit2gtk 2.24.2-2, this should fix your problem. I'd
appreciate if you can confirm it.

You'll need to update both libjavascriptcoregtk-4.0-18 and
libwebkit2gtk-4.0-37.

Berto

Bug#931028: unblock: fence-agents/4.3.3-2

[Salvatore Bonaccorso]

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

Hi Release Team,

Please unblock package fence-agents. Valentin Vidic has backported the
fix to address CVE-2019-10153 (#930887):

> fence-agents (4.3.3-2) unstable; urgency=high
> 
>   * fence_rhevm: add patch for CVE-2019-10153 (Closes: #930887)
> Including non-ASCII characters in a guest VM's comment or other fields
> would cause fence_rhevm to exit with an exception.
> 
>  -- Valentin Vidic   Sun, 23 Jun 2019 19:53:35 +0200

unblock fence-agents/4.3.3-2

Regards,
Salvatore
diff -Nru fence-agents-4.3.3/debian/changelog 
fence-agents-4.3.3/debian/changelog
--- fence-agents-4.3.3/debian/changelog 2018-12-03 19:32:54.0 +0100
+++ fence-agents-4.3.3/debian/changelog 2019-06-23 19:53:35.0 +0200
@@ -1,3 +1,11 @@
+fence-agents (4.3.3-2) unstable; urgency=high
+
+  * fence_rhevm: add patch for CVE-2019-10153 (Closes: #930887)
+Including non-ASCII characters in a guest VM's comment or other fields
+would cause fence_rhevm to exit with an exception.
+
+ -- Valentin Vidic   Sun, 23 Jun 2019 19:53:35 +0200
+
 fence-agents (4.3.3-1) unstable; urgency=medium
 
   * New upstream version 4.3.3
diff -Nru fence-agents-4.3.3/debian/patches/CVE-2019-10153 
fence-agents-4.3.3/debian/patches/CVE-2019-10153
--- fence-agents-4.3.3/debian/patches/CVE-2019-101531970-01-01 
01:00:00.0 +0100
+++ fence-agents-4.3.3/debian/patches/CVE-2019-101532019-06-23 
19:52:19.0 +0200
@@ -0,0 +1,34 @@
+Description: fence_rhevm fix for CVE-2019-10153
+ Import upstream security patches.
+Author: Oyvind Albrigtsen 
+Origin: upstream
+Bug-RHEL: https://bugzilla.redhat.com/show_bug.cgi?id=1716286
+Reviewed-by: Valentin Vidic 
+Last-Update: 2019-06-23
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/agents/rhevm/fence_rhevm.py
 b/agents/rhevm/fence_rhevm.py
+@@ -88,7 +88,7 @@
+   ## send command through pycurl
+   conn = pycurl.Curl()
+   web_buffer = io.BytesIO()
+-  conn.setopt(pycurl.URL, url.encode("ascii"))
++  conn.setopt(pycurl.URL, url.encode("UTF-8"))
+   conn.setopt(pycurl.HTTPHEADER, [
+   "Version: 3",
+   "Content-type: application/xml",
+@@ -128,10 +128,10 @@
+ 
+   opt["cookie"] = cookie
+ 
+-  result = web_buffer.getvalue().decode()
++  result = web_buffer.getvalue().decode("UTF-8")
+ 
+-  logging.debug("%s\n", command)
+-  logging.debug("%s\n", result)
++  logging.debug("%s\n", command.encode("UTF-8"))
++  logging.debug("%s\n", result.encode("UTF-8"))
+ 
+   return result
+ 
diff -Nru fence-agents-4.3.3/debian/patches/series 
fence-agents-4.3.3/debian/patches/series
--- fence-agents-4.3.3/debian/patches/series2018-10-18 09:00:43.0 
+0200
+++ fence-agents-4.3.3/debian/patches/series2019-06-23 19:47:30.0 
+0200
@@ -1,3 +1,4 @@
 remove-fence_amt_ws
 disable-network-access
 spelling
+CVE-2019-10153

Bug#930887: [Debian-ha-maintainers] Bug#930887: Bug#930887: CVE-2019-10153

[Valentin Vidić]

On Mon, Jun 24, 2019 at 02:03:11PM +0200, wf...@niif.hu wrote:
> According to https://security-tracker.debian.org/tracker/CVE-2019-10153,
> the vulnerable code is not present in stretch.  However, I don't
> understand why this does not count:
> 
> https://salsa.debian.org/ha-team/fence-agents/blob/debian/4.0.25-1/fence/agents/rhevm/fence_rhevm.py#L124
> 
> Also, according to http://pycurl.io/docs/latest/unicode.html#unicode the
> URL conversion to ASCII can fail even when it's implicit, though that
> probably isn't user controllable, thus may not count.

I suppose the upstream marked it for 4.3.3, but we can make a fix for stretch
to be on the safe side?

-- 
Valentin

Bug#930293: unblock: docker.io/18.09.1+dfsg1-7

[Paul Gevers]

Hi Shengjing,

On 24-06-2019 00:28, Shengjing Zhu wrote:
> Now, with good reason...
> 
> It tooks me enough hours today to figure out why the tests crash the host(as
> described in #929662, running out of pids).
> 
> The bug is not from upstream. Previously a file was removed from
> upstream tarball, named engine/pkg/chrootarchive/archive_test.go, which
> has an important init func:
> 
> func init() {
> reexec.Init()
> }
> 
> All tests that rely on reexec need this func. The tests added by 
> CVE-2018-15664
> need it as well. Without this, the tests cause fork bomb.

Are you saying this file is only needed for testing? This file isn't
needed for docker.io itself? Why was it stripped in the first place?

> Well, after adding this func back, the tests run and the host doesn't
> crash.
> 
> However the tests still can't pass in schroot, the log says:

[...]

> Short version: these tests need privileged permission.

And your schroot doesn't provide those. How about any better container?
How about buildds?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#927226: libpaper1: Fresh RC1 install doesn't configure /etc/papersize

[Thorsten Ehlers]

On Mon, 24 Jun 2019 09:34:17 +0200 Giuseppe Sacco 
 wrote:
> Hello Thorsten, Voip, and Jacob,
> I think the problem has been solved in version 1.1.27, currently in
> unstable. I would really appreciate if you could test it, as well as I
> did.
> 
> If this package passes your tests, I will ask for an unblock that will
> let the package migrate to testing/buster in a few days.
> 
> Bye,
> Giuseppe


Hello Giuseppe,

I tried version 1.2.27 today but I'm afraid the problem still remains.

What I did in a fresh, German localized, text-only install of RC1 (AMD64) with 
"sid" updates installed:


Downloaded both 1.2.24+nmu5 (stretch) and 1.2.27 (sid) versions of libpaper1 
and libpaper-utils.

Purged the installed packages:

dpkg --force-all --purge libpaper1 libpaper-utils

Checked /var/cache/debconf/config.dat for remaining configuration of libpaper 
and deleted it if any.
(This happens after a manual override of /etc/papersize with dpkg-reconfigure 
libpaper1)

Installed either version a) 24 or b) 27:

dpkg --install ./libpaper1_XXX_amd64.deb ./libpaper-utils_XXX_amd64.deb

In case a) I got a4 and in case b) letter in both /etc/papersize and 
/var/cache/debconf/config.dat.

I hope this will help you to finally nail down this nasty bug...

Bye,
Thorsten

Bug#931027: tomb: opening a new tomb produces error messages

[S. G.]

Package: tomb
Version: 2.5+dfsg1-2
Severity: normal
Tags: upstream

Dear Maintainer,

creating, opening and closing a new tomb by

  tomb dig   -s 20 x.tomb
  tomb forge --unsafe --use-urandom --tomb-pwd x x.key
  tomb lock  --unsafe --tomb-pwd x -k x.key -o aes-xts-plain64 x.tomb
  tomb open  --unsafe --tomb-pwd x -k x.key x.tomb
  tomb close x

results in error messages between the ultimate lines of output:

  [...]
  tomb (*) Success opening x.tomb on /media/x
  _update_control_file:7: permission denied: /media/x/.uid
  chown: cannot access '/media/x/.uid': No such file or directory
  _update_control_file:7: permission denied: /media/x/.tty
  chown: cannot access '/media/x/.tty': No such file or directory
  _update_control_file:7: permission denied: /media/x/.host
  chown: cannot access '/media/x/.host': No such file or directory
  _update_control_file:7: permission denied: /media/x/.last
  chown: cannot access '/media/x/.last': No such file or directory
  tomb  .  Closing tomb [x] mounted on /media/x
  tomb (*) Tomb [x] closed: your bones will rest in peace.

These error messages show up on each 'tomb open' when done with the -p option

  tomb open  --unsafe --tomb-pwd x -k x.key -p x.tomb

The opened tomb is usable despite all that.




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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.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 tomb depends on:
ii  cryptsetup-bin  2:2.1.0-5
ii  e2fsprogs   1.44.5-1
ii  gnupg   2.2.12-1
ii  pinentry-gnome3 [pinentry]  1.1.0-2
ii  sudo1.8.27-1
ii  zsh 5.7.1-1

tomb recommends no packages.

tomb suggests no packages.

-- no debconf information

Bug#931002: Updating crates for Debian stable release

[Ximin Luo]

I am on vacation for the next two weeks, please can someone else deal with the 
following:

Due to Firefox we updated/unblocked rustc 1.34.2 for Debian Testing (and the 
next Debian Stable) release.

This causes two FTBFS bugs for crates which no longer build on rustc 1.34.2:

- #931002 coresimd https://crates.io/crates/coresimd
- #931003 simd https://crates.io/crates/simd

In fact these crates are deprecated and should be RMd. We also need to: 

- update encoding-rs so it doesn't depend on simd
- update packed-simd so it doesn't depend on coresimd
- package NEW core-arch package which is a new dependency of the updated 
packed-simd

and unblock these.

Otherwise {encoding-rs, packed-simd} and its reverse dependencies (including 
ripgrep) will have to be dropped from the next Debian Stable release.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#931026: RFS: apt-transport-in-toto/0.1.0 [ITP]

[Lukas Puehringer]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "apt-transport-in-toto"

* Package name: apt-transport-in-toto
  Version : 0.1.0
  Upstream Author : in-toto developers 
* URL : https://github.com/in-toto/apt-transport-in-toto
* License : Apache-2.0
  Section : devel

It builds those binary packages:

  apt-transport-in-toto - apt transport method for in-toto supply chain 
verification

To access further information about this package, please visit the following 
URL:

https://mentors.debian.net/package/apt-transport-in-toto


Alternatively, one can download the package with dget using this command:

  dget -x
https://mentors.debian.net/debian/pool/main/a/apt-transport-in-toto/apt-transport-in-toto_0.1.0.dsc

More information about apt-transport-in-toto and the underlying in-toto
verification protocol can be obtained from https://in-toto.io.

apt-transport-in-toto depends on "in-toto", which in turn depends on the general
purpose crypto and schema library "securesystemslib", for both of which ITPs are
available:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931013
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931015

apt-transport-in-toto was demonstrated at MiniDebConf 2019 in Hamburg. A
recording of the talk and demo is available at:
https://saimei.ftp.acc.umu.se/Public/debian-meetings/2019/miniconf-hamburg/in-toto.webm

Build instructions (with pointers to build instructions for securesystemslib and
in-toto) are available under:
https://github.com/in-toto/apt-transport-in-toto/commit/34b347729ed77fa6aa43bcce586367aca9b92922

Note that there are some decisions about the root of trust and key distribution
to be made before uploading the package. See inline TODO comments in "*.install"
file and a corresponding GitHub discussion for more details:

https://github.com/in-toto/apt-transport-in-toto/blob/debian/debian/apt-transport-in-toto.install
https://github.com/in-toto/apt-transport-in-toto/issues/13

Changes since the last upload:
apt-transport-in-toto (0.1.0) unstable; urgency=low

  *  Initial Debian release.

 -- Lukas Puehringer   Fri, 07 Jun 2019 12:14:02 -0400



Regards,
 Lukas Pühringer

-- 
lukas.puehrin...@nyu.edu
PGP fingerprint: 8BA6 9B87 D43B E294 F23E  8120 89A2 AD3C 07D9 62E8



signature.asc
Description: OpenPGP digital signature

Bug#889487: rasdaemon: Please add an init script

[Harald Dunkel]

How comes that this patch hasn't made it into Buster?
Got trapped in the systemd vs no-systemd debate instead
of providing a good package?

Harri

Bug#931024: kthresher: Uses Package.section, incompatible with python-apt 1.9

[Julian Andres Klode]

Package: kthresher
Severity: normal
User: de...@lists.debian.org
Usertags: apt-1.9.0

According to codesearch.d.n, kthresher contains trhe line:

"kernel" in pkg.section and re.match(kernel_image_regex, pkg_name)

The use of the section on packages has been deprecated ages ago, as
it can vary between versions. 

This causes kthresher to stop working with apt 1.9, so please migrate to
using a version's section after the buster release.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#931025: gpsbabel: new upstream version

[Christoph Anton Mitterer]

Package: gpsbabel
Version: 1.5.4-2
Severity: wishlist


Hi.

Version 1.6.0 is available :-)

Cheers,
Chris.

Bug#931023: unblock: libpaper/1.1.27

[Giuseppe Sacco]

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

Please unblock package libpaper

1.1.26 has a circular dependency in debian/rules that skips
the creation of an important file: libpaper1.config.
The new package fixes this problem and make use of DPKG_EXPORT_BUILDFLAGS.

source debdiff is attached

unblock libpaper/1.1.27

-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), 
LANGUAGE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru libpaper-1.1.26/configure.ac libpaper-1.1.27/configure.ac
--- libpaper-1.1.26/configure.ac2018-12-11 11:50:29.0 +0100
+++ libpaper-1.1.27/configure.ac2019-06-23 21:26:40.0 +0200
@@ -1,6 +1,6 @@
 dnl Process this file with autoconf to produce a configure script.
 
-AC_INIT([libpaper], [1.1.26])
+AC_INIT([libpaper], [1.1.27])
 AC_CONFIG_SRCDIR([configure.ac])
 AM_INIT_AUTOMAKE([no-define])
 AM_CONFIG_HEADER(config.h)
diff -Nru libpaper-1.1.26/debian/changelog libpaper-1.1.27/debian/changelog
--- libpaper-1.1.26/debian/changelog2018-12-11 11:50:45.0 +0100
+++ libpaper-1.1.27/debian/changelog2019-06-23 21:27:03.0 +0200
@@ -1,3 +1,10 @@
+libpaper (1.1.27) unstable; urgency=medium
+
+  * Fixed a circular dependency in debian/rules that left libpaper1.config
+not built. See #927226.
+
+ -- Giuseppe Sacco   Sun, 23 Jun 2019 21:27:03 +0200
+
 libpaper (1.1.26) unstable; urgency=medium
 
   * Check for ucf presence in the postrm script. See #916197 and #916198.
diff -Nru libpaper-1.1.26/debian/rules libpaper-1.1.27/debian/rules
--- libpaper-1.1.26/debian/rules2018-12-02 22:28:23.0 +0100
+++ libpaper-1.1.27/debian/rules2019-06-23 21:27:03.0 +0200
@@ -6,6 +6,9 @@
 
 include /usr/share/dpkg/architecture.mk
 
+DPKG_EXPORT_BUILDFLAGS = 1
+include /usr/share/dpkg/buildflags.mk
+
 package:= $(firstword $(shell dh_listpackages))
 prefix := $(CURDIR)/debian/tmp
 share  := /usr/share
@@ -24,20 +27,9 @@
 native_paperconf   := debian/build-native/src/paperconf
 endif
 
-cflags := -g -Wall
-ifeq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
-cflags += -O2
-else
-cflags += -O0
-endif
-
-export CFLAGS=$(cflags)
-export CXXFLAGS=$(cflags)
-
 version:= $(shell dpkg-parsechangelog | \
sed -ne 's/^Version: *\([0-9]\+:\)*//p')
 
-
 tag:
cvs tag -c -F $(subst .,_,debian_version_$(version))
 ifeq ($(findstring -,$(version)),)
@@ -57,7 +49,7 @@
 endif
touch $@
 
-build-indep:   config debian/libpaper1.config
+build-indep:   config libpaper1.config-stamp
$(MAKE) -C debian/build
 ifneq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE))
$(MAKE) -C debian/build-native
@@ -67,15 +59,16 @@
 build-arch:build-indep
 build: build-arch
 
-debian/libpaper1.config: build-arch
-   exec > $@.new \
-   && sed -n '1,/^__BEGIN_PAPERSPECS__/p' $@ \
-   && $(native_paperconf) -amns \
-   && sed -n '/^__END_PAPERSPECS__/,$$p' $@
-   mv $@.new $@
+libpaper1.config-stamp:
+   exec > debian/libpaper1.config.new \
+   && sed -n '1,/^__BEGIN_PAPERSPECS__/p' debian/libpaper1.config \
+   && cat lib/paperspecs \
+   && sed -n '/^__END_PAPERSPECS__/,$$p' debian/libpaper1.config
+   mv debian/libpaper1.config.new debian/libpaper1.config
+   touch libpaper1.config-stamp
 
 clean: checkroot
-   rm -f *-stamp
+   rm -f *-stamp build-indep
[ ! -f Makefile ] || $(MAKE) distclean
rm -rf debian/build debian/build-native
dh_autoreconf_clean

Bug#930980: libcrypt-openssl-dsa-perl FTCBFS: configures and builds for the wrong architecture

[gregor herrmann]

On Mon, 24 Jun 2019 10:11:21 +0700, Nguyen Hoang Tung wrote:

> Source: libcrypt-openssl-dsa-perl
> Version: 0.19
> Severity: normal
> Tags: patch
> User:   helm...@debian.org
> Usertags: rebootstrap

> libcrypt-openssl-dsa-perl fails to cross build because it does not pass
> cross build tools to configure and to make. Adding
> /usr/share/dpkg/buildtools.mk lib and re-define linkers and compilers can
> solve this problem.

Thanks for your bug reports and patches!

While I like to support improving crossbuildability, I have the
impression that the issue you address in these 2 patches affects
hundreds of packages, and that adding boilerplate code to all
debian/rules files is the wrong approach (and doesn't scale). I guess
this needs to be tackled at a deeper level, probably the two perl
buildsystems in debhelper.

Incidentally, Niko look at crossbuilding arch:any perl packages at
our recent sprint briefly. What I find in our gobby notes is

| implement debhelper support for cross building XS module packages?
|   effectively make debhelper run 'perl -I 
/usr/lib//perl/cross-config-5.28.1 Makefile.PL' when it detects a cross 
build

which points in the same direction. And I'm sure Niko can add more on
this topic than I :)


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Arlo Guthrie: Gypsy Davy


signature.asc
Description: Digital Signature

Bug#931022: recon-ng: New upstream version on github

[Raphaël Hertzog]

Package: recon-ng
Version: 4.9.6-1
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Announce: https://twitter.com/LaNMaSteR53/status/1143170464749109250

So it looks like there's a new recon-ng working with Python 3 that is
hosted in github and that is not picked up by uscan due to this:
https://github.com/lanmaster53/recon-ng

It would be nice to have this new version packaged.

https://github.com/lanmaster53/recon-ng/releases/tag/v5.0.0

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

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

Versions of packages recon-ng depends on:
ii  libjs-jquery3.3.1~dfsg-3
pn  libjs-skeleton  
ii  node-normalize.css  8.0.1-3
ii  python  2.7.16-1
pn  python-dicttoxml
ii  python-dnspython1.16.0-1
pn  python-flask
pn  python-jsonrpclib   
ii  python-lxml 4.3.3-2
ii  python-mechanize1:0.2.5-3
ii  python-olefile  0.46-1
pn  python-pypdf2   
pn  python-slowaes  
pn  python-unicodecsv   
pn  python-xlsxwriter   

recon-ng recommends no packages.

recon-ng suggests no packages.

Bug#926780: unblock gcc-8/8.3.0-7 and updated cross builds

[Matthias Klose]

Control: tags -1 - wontfix
Control: reopen -1

On 20.06.19 13:54, Paul Gevers wrote:
> Control: tags -1 wontfix
> Control: close -1
> 
> Hi Matthias,
> 
> On 06-06-2019 12:01, Paul Gevers wrote:> doko, I know you are
> maintaining quite some key packages, so extra work> is probably not what
> you are looking for, but neither are we and on top> of that, we don't
> like turning down unblock request (hence the time it> took to reply, at
> least that's the reason for me). In this case, and> also for gcc-7
> (hence cc of that bug) it would be great if we could> understand from
> the beginning why you believe why we should except this.> And no, I am
> not going to find upstream repositories and bug trackers> for all the
> packages that we get unblock requests for. You'll have to> help us
> making the judgment.

> I take the lack of reply from your side to mean that you are not
> pursuing to drive this further to an unblock. To clean up the unblock
> that probably will not see any further action, I am closing it as
> wontfix. If you are still interested, you can of course reopen, but be
> aware that the time for unblocks for buster is running out quickly now [1].

well, this has a bad smell. First not replying for a month, then turning it down
after not even a week. Apologies for not immediately replying to your email.

Here are the list of changes for gcc-8. Most of them regressions found during
the development of GCC 9, and backported. These come with test cases in the GCC
testsuite, and the added tests pass.  From my point of view it's safe to ship
these in buster.  The changes in detail are:

PR target/89877 (ARC), target not affecting Debain
PR target/84369 (PPC), fix test on POWER9
PR tree-optimization/85762, wrong code regression in GCC 8
PR tree-optimization/87008, missed optimization, regression in GCC 8
PR tree-optimization/85459, missed optimization, regression in GCC 8
PR target/87532 (PPC), wrong code fixes, not marked as regression
PR ipa/89693, ICE on valid code, regression in GCC 9, backported to 8
PR middle-end/88587, ICE on valid code, backported to 8
PR tree-optimization/90018, x86 AVX512, wrong code, regression in GCC 7/8
PR target/90024 (ARM), ICE on valid code on ARM32, regression in 7/8
PR target/89945 (ARM), ICE on valid code, regression in 7/8/9
PR fortran/87352, compile-time-hog, memory-hog, regression in 7/8/9/10
PR fortran/89981, rejects valid code, regresion in GCC 8
PR fortran/89904, ICE on valid code, regression in GCC 9, backported to 8
PR libgfortran/79540, test failure, regression in 7/8 (PARISC only?)
PR fortran/87127, rejects valid code, not marked as regression
PR rtl-optimization/87979, ICE on valid code, not marked as a regression
PR rtl-optimization/84032. ICE on valid code, not marked as a regression

Non-upstream patches:

* Fix PR c++/90050, always link with libstdc++fs.a. LP: #1824721.
  Not really needed for buster, has only effect with GCC 9 installed.

* Fix PR bootstrap/87338 on ia64 (James Clarke). Closes: #927976.
  Fixes the build on ia64. Now upstreamed as well.


There are no changes for the cross packages.  They are rebuilt for this gcc-8
upload.  Currently we don't have matching native and cross compilers in buster.

Matthias

Bug#930563: (no subject)

[Kurt Kremitzki]

severity 930563 important

thanks

Downgrading severity since this issue is not "rendering it completely
unusable to everyone."

Bug#928199: List of licenses that don't require gathering all copyright notices

[Sean Whitton]

control: tag -1 -patch +pending

Hello,

On Mon 29 Apr 2019 at 11:16am -0700, Sean Whitton wrote:

> I've written a patch to add a footnote with a list of licenses that are
> thought not to require the copying of all copyright notices into
> Debian's copyright file.
>
> This does not need seconding, because footnotes are not normative, but I
> haven't committed this patch yet because I wanted to see if others have
> reasons not to include something like this in the Policy Manual.

Now applied to master.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#931021: musescore: phones home, including to Google Analytics, on first start

[Thorsten Glaser]

notfound 931021 musescore-snapshot/3.1+dfsg1-1
thanks

> Bugreport for myself and for release tracking.

MuseScore 3, which is currently sitting in experimental, intending to
hit sid after the release, is NOT affected; disabling the web centre
thingy seems to suffice.

bye,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!

Bug#930796: spindown_time and force_spindown_time are broken in hdparm 9.58+ds-1

[Alex Mestiashvili]

On 6/20/19 8:42 PM, Sébastien Béhuret wrote:
> Package: hdparm
> Version: 9.58+ds-1
> Severity: serious
> 
> Dear Maintainers,
> 
> In this version of hdparm, a new option 'force_spindown_time' was
> introduced to set the spindown time for disks that don't support APM.
> This option is supposed to translate to hdparm -S, similarly to the
> original option 'spindown_time'.
> 
> hdparm package comes with 3 main scripts:
> 
> 1) /usr/lib/pm-utils/power.d/95hdparm-apm
> This script will translate 'force_spindown_time' to hdparm -S and apply
> the option even if APM was not detected.
> This is the desired behavior.
> 
> 2) /etc/apm/event.d/20hdparm
> This script will ignore /etc/hdparm.conf and apply hard-coded defaults
> instead.
> This behavior is unexpected.
> Expected/Desired behavior: Read /etc/hdparm.conf and apply relevant options.
> 
> 3) /lib/hdparm/hdparm-functions (sourced from /lib/udev/hdparm, which is
> invoked by udev rule /lib/udev/rules.d/85-hdparm.rules)
> - 'force_spindown_time' is buggy because it is not converted back to -S,
> which leads to a syntax error during hdparm execution (e.g. hdparm
> force_spindown_time$VALUE instead of hdparm -S$VALUE).
> - Both options 'spindown_time' and 'force_spindown_time' are processed
> even if APM is not supported. From the comments in the configuration
> file (/etc/hdparm.conf), it is understood that 'spindown_time' will be
> applied for APM disks only and 'force_spindown_time' for all disks (or
> possibly for non-APM disks only).
> - The scripts will also apply hard-coded defaults for -S and -B if APM
> was detected. The hard-coded defaults differ from those used in
> /etc/apm/event.d/20hdparm, leading to inconsistent behavior.
> 
> 4) Additional issues with non-APM disks:
> - Manually invoking hdparm -S$VALUE /dev/sdx is simply ignored even
> though hdparm executes successfully. The disks do not spin down after
> the time delay when there was no access.
> - Manually invoking hdparm -y /dev/sdx will spin down the disks
> immediately. The disks will not wake up unless they are accessed, which
> is the expected behavior.
> 
> These were all working fine in hdparm 9.51+ds-1+deb9u1, which is the
> current version in stretch.
> 
> In short, it is currently impossible to obtain a consistent and working
> configuration for non-APM disks.
> 
> Many thanks and regards,
> Sebastien Behuret

Hi Sebastien,

2. As APM is almost dead and most likely there are no laptops using APM
and buster. I'll drop /etc/apm/event.d/20hdparm in the next release.

3. This is a real issue. In /lib/hdparm/hdparm-functions I've left the
"force_spindown_time$VALUE" option intentionally, it need to be
translated to "-S" later in scripts using hdparm-functions like it is
done in 95hdparm-apm

/lib/udev/hdparm is called by udev and need to be fixed.

/usr/lib/pm-utils/power.d/95hdparm-apm called by pm-utils events and
takes care only about spin_down and apm options for the disks which
support apm.

To obtain a consistent behavior /lib/udev/hdparm can call
/usr/lib/pm-utils/power.d/95hdparm-apm for spindown and apm options and
hdparm directly for all other options.

4. I failed to reproduce that. I couldn't put to standby a non-apm disk
on a stretch system with hdparm -S (hdparm 9.51)
Could you please try to build hdparm 9.51 or just get a binary package
and run it to see if 9.51 works for your disks compared to 9.58?

Thank you for the detailed report.
Alex

Bug#931021: musescore: phones home, including to Google Analytics, on first start

[Thorsten Glaser]

Package: musescore
Version: 2.3.2+dfsg2-6
Severity: serious
Tags: security
Justification: phones home

Bugreport for myself and for release tracking.

Dear release team, please indicate whether this is buster release-critical,
I will try to fix it later tonight.


On first startup, MuseScore connects to:

connect2.musescore.com  CNAME   cds.z5r7u8v4.hwcdn.net
cds.z5r7u8v4.hwcdn.net  A   205.185.216.10
cds.z5r7u8v4.hwcdn.net  A   205.185.216.42

(Highwinds Network Operations Center)


The currently shipped HTML content makes it also connect to:

www.google-analytics.comCNAME   www-google-analytics.l.google.com
www-google-analytics.l.google.com   A   172.217.16.174
www-google-analytics.l.google.com   2A00:1450:4001:81B:0:0:0:200E

Also:

mc.yandex.ruA   93.158.134.119
mc.yandex.ruA   77.88.21.119
mc.yandex.ruA   87.250.250.119
mc.yandex.ruA   87.250.251.119
mc.yandex.ru2A02:6B8:0:0:0:0:1:119

And:

stats.g.doubleclick.net CNAME   stats.l.doubleclick.net
stats.l.doubleclick.net A   74.125.133.155
stats.l.doubleclick.net A   74.125.133.156
stats.l.doubleclick.net A   74.125.133.157
stats.l.doubleclick.net A   74.125.133.154
stats.l.doubleclick.net 2A00:1450:400C:C0B:0:0:0:9D


I’ll simply remove the offending “web start centre” functionality,
given that MuseScore 3.x will not ship it either anyway (for tech
reasons).


-- System Information:
Debian Release: 10.0
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages musescore depends on:
ii  desktop-file-utils   0.23-4
ii  libasound2   1.1.8-1+x32.1
ii  libc62.28-10
ii  libfreetype6 2.9.1-3
ii  libgcc1  1:8.3.0-7
ii  libportaudio219.6.0-1
ii  libportmidi0 1:217-6
ii  libpulse012.2-4
ii  libqt5core5a 5.11.3+dfsg1-2
ii  libqt5gui5   5.11.3+dfsg1-2
ii  libqt5help5  5.11.3-4
ii  libqt5network5   5.11.3+dfsg1-2
ii  libqt5printsupport5  5.11.3+dfsg1-2
ii  libqt5qml5   5.11.3-4
ii  libqt5quick5 5.11.3-4
ii  libqt5sql5-sqlite5.11.3+dfsg1-2
ii  libqt5svg5   5.11.3-2
ii  libqt5webkit55.212.0~alpha2-21
ii  libqt5widgets5   5.11.3+dfsg1-2
ii  libqt5xml5   5.11.3+dfsg1-2
ii  libqt5xmlpatterns5   5.11.3-2
ii  libsndfile1  1.0.28-6
ii  libstdc++6   8.3.0-7
ii  libvorbisfile3   1.3.6-2
ii  musescore-common 2.3.2+dfsg3-2
ii  qml-module-qtquick-controls  5.11.3-2
ii  qml-module-qtquick-dialogs   5.11.3-2
ii  qml-module-qtquick-layouts   5.11.3-4
ii  qml-module-qtquick2  5.11.3-4
ii  shared-mime-info 1.10-1
ii  xdg-utils1.1.3-1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages musescore recommends:
ii  libmp3lame0   3.100-2+b1
pn  pulseaudio-utils  

musescore suggests no packages.

-- no debconf information

Bug#865975: docker.io changes iptables default FORWARD policy to DROP, breaks VM and others

[Jonathan Dowland]

Hi Shengjing Zhu (et al)

I've just (finally) attempted to reproduce this on my Buster host, but
could not on this attempt. Libvirtd did not change my ip_forward setting
from 0 to 1 in the test, but I had to do so manually to re-enable VM
networking outside of the host (I don't think I did this manually in the
first instance). Docker did not change the FORWARD chain policy since
ip_forward was set to 1. My libvirtd VMs are using the default bridged
network.

I'll keep trying to reproduce this but for now let's assume that it doesn't
happen.

Bug#931014: Solved

[Joe McEntire]

This was solved by:

apt autoremove virt-manager --purge

apt install virt-manager

I do not see this issue on my laptop. I think it was a fluke issue.

Please disregard!

Thanks for your time,

Joe
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#930362: new post: Help the Java Team Distribute your project!

[Hans-Christoph Steiner]

A version of this was reviewed and went out on the Java team blog a
while ago, before FOSDEM.


Emmanuel Bourg wrote:
> Hans-Christoph Steiner wrote:
>
> Some comments on the post:
>
>> Include a build target in your build system that builds using only
>> libraries in Debian.
>
> I don't think this is a reasonable requirement. Upstream projects
> shouldn't adapt to N distributions, that's unsustainable. The best
> recommendation is to stick to mainstream build systems, and then
> Debian does the work of integrating these build systems with its
> libraries.

The idea here is recommendations, then upstream applies what is
reasonable.  I wasn't writing requirements.


>> Provide a minimal build target which uses as few build tricks as
>> possible, like Gradle plugins or custom hacks.
>
> This is too vague. What kind of plugins should be avoided and why? In
> the end we just disable them, so that's not really a problem.

I would either defer to what you want there, or just remove that line.
It is in the same spirit as above, just ideas rather than requirements.


>> Run Continuous Integration (CI) builds against Debian/testing, its so
>> easy these days with GitLab CI, Travis CI, etc.
>
> They probably do, but not against the system libraries, so that
> doesn't really help.

Exactly, the point is to test against Debian packages.  So this could be
changed to be more explicit:

Run Continuous Integration (CI) builds using all libraries directly from
Debian/testing, its so easy these days with GitLab CI, Travis CI, etc.


>> Help us package Java, and learn first hand!
>
> Are we requesting help to package OpenJDK?

I mean Java code in general.

Bug#931019: padthv1 FTCBFS: uses the build architecture qmake

[Helmut Grohne]

Source: padthv1
Version: 0.8.6-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

padthv1 fails to cross build from source, because configure.ac fails to
consider $ac_tool_prefix when checking for qmake. The attached patch
fixes that and makes padthv1 cross buildable. Please consider applying
it.

Helmut
--- padthv1-0.8.6.orig/configure.ac
+++ padthv1-0.8.6/configure.ac
@@ -266,12 +266,12 @@
 ac_errmsg="not found in current PATH. Maybe QT development environment isn't available."
 
 if test "x$ac_qt4" = "xyes"; then
-   AC_PATH_PROG(ac_qmake, qmake-qt4, [no], $ac_path)
+   AC_PATH_TOOL(ac_qmake, qmake-qt4, [no], $ac_path)
 else
-   AC_PATH_PROG(ac_qmake, qmake-qt5, [no], $ac_path)
+   AC_PATH_TOOL(ac_qmake, qmake-qt5, [no], $ac_path)
 fi
 if test "x$ac_qmake" = "xno"; then
-   AC_PATH_PROG(ac_cv_qmake, qmake, [no], $ac_path)
+   AC_PATH_TOOL(ac_cv_qmake, qmake, [no], $ac_path)
ac_qmake=$ac_cv_qmake
 fi
 if test "x$ac_qmake" = "xno"; then

Bug#931020: lz4json FTCBFS: does not use cross tools

[Helmut Grohne]

Source: lz4json
Version: 2-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

lz4json fails to cross build from source, because it does not pass cross
tools to make. Using dh_auto_build partially fixes that, but the
upstream Makefile still hard codes pkg-config. The attached patch fixes
both and makes lz4json cross buildable. Please consider applying it.

Helmut
diff --minimal -Nru lz4json-2/debian/changelog lz4json-2/debian/changelog
--- lz4json-2/debian/changelog  2019-02-10 23:45:38.0 +0100
+++ lz4json-2/debian/changelog  2019-06-24 17:32:15.0 +0200
@@ -1,3 +1,12 @@
+lz4json (2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build pass cross tools to make.
++ cross.patch: Make pkg-config substitutable.
+
+ -- Helmut Grohne   Mon, 24 Jun 2019 17:32:15 +0200
+
 lz4json (2-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru lz4json-2/debian/patches/cross.patch 
lz4json-2/debian/patches/cross.patch
--- lz4json-2/debian/patches/cross.patch1970-01-01 01:00:00.0 
+0100
+++ lz4json-2/debian/patches/cross.patch2019-06-24 17:32:15.0 
+0200
@@ -0,0 +1,10 @@
+--- lz4json-2.orig/Makefile
 lz4json-2/Makefile
+@@ -1,5 +1,6 @@
++PKG_CONFIG ?= pkg-config
+ CFLAGS := -g -O2 -Wall
+-LDLIBS := $(shell pkg-config --cflags --libs liblz4)
++LDLIBS := $(shell $(PKG_CONFIG) --cflags --libs liblz4)
+ 
+ lz4jsoncat: lz4jsoncat.c
+ 
diff --minimal -Nru lz4json-2/debian/patches/series 
lz4json-2/debian/patches/series
--- lz4json-2/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ lz4json-2/debian/patches/series 2019-06-24 17:32:15.0 +0200
@@ -0,0 +1 @@
+cross.patch
diff --minimal -Nru lz4json-2/debian/rules lz4json-2/debian/rules
--- lz4json-2/debian/rules  2019-02-06 00:57:12.0 +0100
+++ lz4json-2/debian/rules  2019-06-24 17:32:13.0 +0200
@@ -5,4 +5,4 @@
dh $@
 
 override_dh_auto_build:
-   make CFLAGS="$$(dpkg-buildflags --get CFLAGS)"
+   dh_auto_build -- CFLAGS="$$(dpkg-buildflags --get CFLAGS)"

Bug#931018: Please add Breaks for webpack << 4.28.3 to acorn 6

[Pirate Praveen]

package: node-acorn
version: 
6.0.2+20181021git007b08d01eff070+ds+~0.3.1+~4.0.0+~0.3.0+~5.0.0+ds+~1.6.1+ds-1

severity: wishlist

Please add Breaks: webpack (<< 4.28.3~) as node-acorn 6 gets installed 
otherwise in experimental (experienced when trying to build 
node-dagre-d3-renderer in salsa). I tried to update it myself, but 
master seems not in a state to upload.

Bug#929949: status update

[Sebastien Bacher]

Hey Alexander,

Thanks for the work and for taking the time to get the bug updated with 
the details!


While I think it would be fine to get an update built with python3.7 in 
experimental I think it's fair to hold a bit and get some of the issues 
fixed upstream, hopefully 8.01 is in a better state to be packaged.


Cheers,

Le 24/06/2019 à 11:42, Alexander Zangerl a écrit :

net result: duplicity 0.8.00 can be built for testing/buster and for sid,
but not for stretch (at least not at this time).

as i'm still using stretch on my main systems i'm reluctant to call this
version releasable yet: i think that it would be better to wait for a bit
of feedback from upstream before 0.8.00 is allowed to enter the debian
archives.

the relevant bits of hacky patchery live at
https://salsa.debian.org/debian/duplicity/commits/debian  if anybody
want to play with this straight away.

Bug#931017: dkms: "install" loads modules immediately, and loads more than the newly installed modules

[Raphaël Hertzog]

Package: dkms
Version: 2.6.1-4
Severity: important
User: de...@kali.org
Usertags: origin-kali

While working on automatic installation of virtualbox-guest-dkms in
debian-installer when running in VirtualBox VM, I have discovered
that the package installation would break debian installer.

The reason is that "dkms install" runs this:
find /sys/devices -name modalias -print0 | xargs -0 cat | xargs modprobe -a -b 
-q

This will load the newly built modules but possibly also other modules...
and the fact that those modules get loaded, somehow breaks the
X server run by debian-installer.

This "feature" is new in buster compared to stretch. It would be nice to
have a way to disable this automatic loading... ideally an environment
variable makes it easy to disable this from debian-installer without
having to modify the target system. But a command line option (and/or an
entry in the configuration file) is certainly a good idea as well.

And it would be even better if it could just do its work on the modules
that the "dkms install" actually installed.

Cheers,

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

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

Versions of packages dkms depends on:
ii  build-essential  12.6
ii  coreutils8.30-3
ii  dpkg-dev 1.19.7
ii  gcc  4:8.3.0-1
ii  kmod 26-1
ii  make 4.2.1-1.2
ii  patch2.7.6-3

Versions of packages dkms recommends:
ii  fakeroot  1.23-1
pn  linux-headers-686-pae | linux-headers-amd64 | linux-headers-  
pn  linux-image   
ii  lsb-release   10.2019051400
ii  sudo  1.8.27-1

Versions of packages dkms suggests:
pn  menu
pn  python3-apport  

Bug#931016: unblock: spacenavd/0.6-1.1

[Jakob Haufe]

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

Please unblock package spacenavd

spacenavd was no longer working properly due to a subtle change in kernel
behaviour. This was reported in #916610 and fixed by applying the
corresponding upstream commit.

Debdiff below.

diff -Nru spacenavd-0.6/debian/changelog spacenavd-0.6/debian/changelog
--- spacenavd-0.6/debian/changelog  2015-05-18 10:04:05.0 +
+++ spacenavd-0.6/debian/changelog  2019-06-01 11:13:33.0 +
@@ -1,3 +1,11 @@
+spacenavd (0.6-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "conflict with /dev/input/js0" (Closes: #916610)
+- Fixed upstream in 34ddda1246ad07e8ff2e6606224e710852e3e3d8
+
+ -- Jakob Haufe   Sat, 01 Jun 2019 11:13:33 +
+
 spacenavd (0.6-1) unstable; urgency=medium
 
   * Imported Upstream version 0.6
diff -Nru spacenavd-0.6/debian/patches/series 
spacenavd-0.6/debian/patches/series
--- spacenavd-0.6/debian/patches/series 2015-05-18 10:04:05.0 +
+++ spacenavd-0.6/debian/patches/series 2019-06-01 11:04:55.0 +
@@ -1,2 +1,3 @@
 add-buildflags-to-makefile.patch
 run.patch
+skip-joystick-devices.patch
diff -Nru spacenavd-0.6/debian/patches/skip-joystick-devices.patch 
spacenavd-0.6/debian/patches/skip-joystick-devices.patch
--- spacenavd-0.6/debian/patches/skip-joystick-devices.patch1970-01-01 
00:00:00.0 +
+++ spacenavd-0.6/debian/patches/skip-joystick-devices.patch2019-06-01 
11:13:33.0 +
@@ -0,0 +1,37 @@
+Description: Skip joystick device files
+Author: John Tsiombikas 
+Origin: upstream, 
https://github.com/FreeSpacenav/spacenavd/commit/34ddda1246ad07e8ff2e6606224e710852e3e3d8
+Bug-Debian: https://bugs.debian.org/916610
+---
+commit 34ddda1246ad07e8ff2e6606224e710852e3e3d8
+Author: John Tsiombikas 
+Date:   Sat Oct 11 05:07:58 2014 +
+
+added code to skip joystick device files while parsing 
/proc/bus/input/devices
+
+
+git-svn-id: svn+ssh://svn.code.sf.net/p/spacenav/code/trunk/spacenavd@183 
ef983eb1-d774-4af8-acfd-baaf7b16a646
+
+diff --git a/src/dev_usb_linux.c b/src/dev_usb_linux.c
+index 30db579..5f4baad 100644
+--- a/src/dev_usb_linux.c
 b/src/dev_usb_linux.c
+@@ -342,11 +342,16 @@ struct usb_device_info *find_usb_devices(int 
(*match)(const struct usb_device_in
+   case 'H':
+   keyptr = strstr(cur_line, "Handlers=");
+   if(keyptr) {
+-  char *devfile, *valptr = keyptr 
+ strlen("Handlers=");
++  char *devfile = 0, *valptr = 
keyptr + strlen("Handlers=");
+   static const char *prefix = 
"/dev/input/";
+ 
+   int idx = 0;
+-  while((devfile = strtok(idx ? 0 
: valptr, " \t\v\n\r"))) {
++  while((devfile = strtok(devfile 
? 0 : valptr, " \t\v\n\r"))) {
++  if(strstr(devfile, 
"js") == devfile) {
++  /* ignore 
joystick device files, can't use them */
++  continue;
++  }
++
+   
if(!(devinfo.devfiles[idx] = malloc(strlen(devfile) + strlen(prefix) + 1))) {
+   perror("failed 
to allocate device filename buffer");
+   continue;


unblock spacenavd/0.6-1.1

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

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



-- 
ceterum censeo microsoftem esse delendam.


pgpsFrvGaNeFe.pgp
Description: OpenPGP digital signature

Bug#931014: [Pkg-libvirt-maintainers] Bug#931014: virt-manager: Virt-manager crashed when attempting to create new VM.

[Guido Günther]

Hi,
On Mon, Jun 24, 2019 at 10:46:07AM -0400, Joe B. McEntire wrote:
> Package: virt-manager
> Version: 1:2.0.0-3
> Severity: important
> 
> Dear Maintainer,
> 
>* What led up to the situation?  Attempted to create a new VM
>* What exactly did you do (or not do) that was effective (or
>  ineffective)? Clicked the new VM button
>* What was the outcome of this action?  Virt-manager crashed
>* What outcome did you expect instead? VM creation wizard comes up and
> works.
> 
> Here's the output of the console during the crash:
> 
> [Mon, 24 Jun 2019 10:39:53 virt-manager 21406] DEBUG (create:200) Showing new
> vm wizard
> [Mon, 24 Jun 2019 10:39:53 virt-manager 21406] DEBUG (create:695) Guest type
> set to os_type=hvm, arch=x86_64, dom_type=kvm
> 
> (virt-manager:21406): GLib-GIO-ERROR **: 10:39:53.289: Settings schema
> 'org.virt-manager.virt-manager.urls' does not contain a key named 'containers'
> 
> There is not further output past this point.
> 
> My system is an upgrade from Debian Stretch to Debian Buster.

Seems you're missing keys from your gsettings schema

- what does 

gsettings  ist-keys org.virt-manager.virt-manager.urls

and

gsettings  get org.virt-manager.virt-manager.urls containers 

give? Did you ever build/install virt-manager by hand?

what's your connection URL?


 -- Guido

> 
> 
> 
> -- System Information:
> Debian Release: 10.0
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.19.0-5-amd64 (SMP w/24 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.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages virt-manager depends on:
> ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
> ii  gir1.2-gtk-3.0   3.24.5-1
> ii  gir1.2-gtk-vnc-2.0   0.9.0-1.1
> ii  gir1.2-libosinfo-1.0 1.2.0-1
> ii  gir1.2-libvirt-glib-1.0  1.0.0-1
> ii  gir1.2-vte-2.91  0.54.2-2
> ii  librsvg2-common  2.44.10-2.1
> ii  python-requests  2.21.0-1
> ii  python3  3.7.3-1
> ii  python3-dbus 1.2.8-3
> ii  python3-gi   3.30.4-1
> ii  python3-gi-cairo 3.30.4-1
> ii  python3-libvirt  5.0.0-1
> ii  virtinst 1:2.0.0-3
> 
> Versions of packages virt-manager recommends:
> ii  gir1.2-spiceclientglib-2.0  0.35-2
> ii  gir1.2-spiceclientgtk-3.0   0.35-2
> ii  libvirt-daemon-system   5.0.0-3
> 
> Versions of packages virt-manager suggests:
> ii  gir1.2-secret-10.18.7-1
> ii  gnome-keyring  3.28.2-5
> ii  ksshaskpass [ssh-askpass]  4:5.14.5-1
> pn  python3-guestfs
> ii  virt-viewer7.0-2
> 
> -- no debconf information
> 
> ___
> Pkg-libvirt-maintainers mailing list
> pkg-libvirt-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-libvirt-maintainers

Bug#931014: virt-manager: Virt-manager crashed when attempting to create new VM.

[Joe B. McEntire]

Package: virt-manager
Version: 1:2.0.0-3
Severity: important

Dear Maintainer,

   * What led up to the situation?  Attempted to create a new VM
   * What exactly did you do (or not do) that was effective (or
 ineffective)? Clicked the new VM button
   * What was the outcome of this action?  Virt-manager crashed
   * What outcome did you expect instead? VM creation wizard comes up and
works.

Here's the output of the console during the crash:

[Mon, 24 Jun 2019 10:39:53 virt-manager 21406] DEBUG (create:200) Showing new
vm wizard
[Mon, 24 Jun 2019 10:39:53 virt-manager 21406] DEBUG (create:695) Guest type
set to os_type=hvm, arch=x86_64, dom_type=kvm

(virt-manager:21406): GLib-GIO-ERROR **: 10:39:53.289: Settings schema
'org.virt-manager.virt-manager.urls' does not contain a key named 'containers'

There is not further output past this point.

My system is an upgrade from Debian Stretch to Debian Buster.



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

Kernel: Linux 4.19.0-5-amd64 (SMP w/24 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.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages virt-manager depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  gir1.2-gtk-3.0   3.24.5-1
ii  gir1.2-gtk-vnc-2.0   0.9.0-1.1
ii  gir1.2-libosinfo-1.0 1.2.0-1
ii  gir1.2-libvirt-glib-1.0  1.0.0-1
ii  gir1.2-vte-2.91  0.54.2-2
ii  librsvg2-common  2.44.10-2.1
ii  python-requests  2.21.0-1
ii  python3  3.7.3-1
ii  python3-dbus 1.2.8-3
ii  python3-gi   3.30.4-1
ii  python3-gi-cairo 3.30.4-1
ii  python3-libvirt  5.0.0-1
ii  virtinst 1:2.0.0-3

Versions of packages virt-manager recommends:
ii  gir1.2-spiceclientglib-2.0  0.35-2
ii  gir1.2-spiceclientgtk-3.0   0.35-2
ii  libvirt-daemon-system   5.0.0-3

Versions of packages virt-manager suggests:
ii  gir1.2-secret-10.18.7-1
ii  gnome-keyring  3.28.2-5
ii  ksshaskpass [ssh-askpass]  4:5.14.5-1
pn  python3-guestfs
ii  virt-viewer7.0-2

-- no debconf information

Bug#931015: RFS: python-securesystemslib/0.11.3-1 [ITP]

[Lukas Puehringer]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "python-securesystemslib".

* Package name: python-securesystemslib
  Version : 0.11.3-1
  Upstream Author : NYU Secure Systems Lab 
* URL : https://github.com/secure-systems-lab/securesystemslib
* License : MIT
  Section : devel

It builds those binary packages:

  python3-securesystemslib - crypto and schema library for TUF and in-toto

To access further information about this package, please visit the following 
URL:

https://mentors.debian.net/package/python-securesystemslib


Alternatively, one can download the package with dget using this command:

  dget -x
https://mentors.debian.net/debian/pool/main/p/python-securesystemslib/python-securesystemslib_0.11.3-1.dsc

More information about python-securesystemslib can be obtained from
https://github.com/secure-systems-lab/securesystemslib.


Also see below resources about how securesystemslib's two main dependents, TUF
and in-toto, are useful for Debian.

 - https://debconf17.debconf.org/talks/100/
 - https://debconf17.debconf.org/talks/153/
 -
https://saimei.ftp.acc.umu.se/Public/debian-meetings/2019/miniconf-hamburg/in-toto.webm


Changes since the last upload:

python-securesystemslib (0.11.3-1) unstable; urgency=low

  * Initial Debian release from tag:

https://github.com/secure-systems-lab/securesystemslib/tree/sslibv0.11.3

 -- Lukas Puehringer   Fri, 07 Jun 2019 11:03:22 -0400



Regards,
 Lukas Pühringer


-- 
lukas.puehrin...@nyu.edu
PGP fingerprint: 8BA6 9B87 D43B E294 F23E  8120 89A2 AD3C 07D9 62E8



signature.asc
Description: OpenPGP digital signature

Bug#930983: libpam-encfs FTCBFS: builds for the wrong architecture

[Agustin Martin]

Control: tag -1 +pending

On Mon, Jun 24, 2019 at 10:25:11AM +0700, Nguyen Hoang Tung wrote: 
> 
> libpam-encfs fails to cross build because it does not pass cross build tools
> to make. Adding /usr/share/dpkg/buildtools.mk, using "dh_auto_build" instead
> of "$(MAKE) and re-defining the linkers and the compilers can solve this
> problem.

Hi,

Committed to our git repo and tagged as pending. Will go in next upload,
after release.

Thanks for your contribution to Debian,

-- 
Agustin

Bug#931013: RFS: python-in-toto/0.3.0-1 [ITP]

[Lukas Puehringer]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "python-in-toto"

* Package name: python-in-toto
  Version : 0.3.0-1
  Upstream Author : NYU Secure Systems Lab 
* URL : https://in-toto.io
* License : Apache-2.0
  Section : devel

It builds those binary packages:

  python3-in-toto - software supply chain security framework

To access further information about this package, please visit the following 
URL:

https://mentors.debian.net/package/python-in-toto


Alternatively, one can download the package with dget using this command:

  dget -x
https://mentors.debian.net/debian/pool/main/p/python-in-toto/python-in-toto_0.3.0-1.dsc

More information about python-in-toto can be obtained from
https://github.com/in-toto/in-toto.

Also see below resources about how in-toto may be used to verify the integrity
of the software supply chain of any Debian package:

 - https://debconf17.debconf.org/talks/100/
 -
https://saimei.ftp.acc.umu.se/Public/debian-meetings/2019/miniconf-hamburg/in-toto.webm

in-toto depends on the general purpose crypto and schema library
"securesystemslib", for which I have already filed an ITP under the subject
"RFS: python-securesystemslib/0.11.3-1 [ITP]".


Changes since the last upload:
python-in-toto (0.3.0-1) unstable; urgency=low

  * Initial Debian release from tag:

https://github.com/in-toto/in-toto/tree/v0.3.0

 -- Lukas Puehringer   Fri, 07 Jun 2019 10:50:40 -0400


Regards,
 Lukas Pühringer


-- 
lukas.puehrin...@nyu.edu
PGP fingerprint: 8BA6 9B87 D43B E294 F23E  8120 89A2 AD3C 07D9 62E8



signature.asc
Description: OpenPGP digital signature

Bug#930942: warzone2100: Segfault upon multiplayer "Start Hosting Game"

[Bernhard Übelacker]

Dear Maintainer,
I just tried to help triaging this bug.

This bug manifests in current Stretch/9.9 and
also in Buster/testing.

In the call to function setMultiStats a temporary
PLAYERSTATS object gets constructed from the
reference returned by getMultiStats.
Therefore the copy constructor of EcKey for the member identity
is called, which unfortunately unconditionally calls EC_KEY_dup,
which seems not able to handle an null pointer as ec_key.

Attached patch calls EC_KEY_dup just in case of a not null key.
With packages rebuilt in Stretch and Buster with this
patch applied, the same crash does not manifest and a multiplayer
with one nullbot was possible.

Could not find an upstream bug similar to this.

Kind regards,
Bernhard


(gdb) bt
#0  EC_KEY_dup (ec_key=0x0) at ../crypto/ec/ec_key.c:156
#1  0x558068cc in EcKey::EcKey (this=0x7fffad00, b=...) at 
crc.cpp:248
#2  0x556afd0a in PLAYERSTATS::PLAYERSTATS (this=0x7ffface0) at 
multistat.h:31
#3  setupNewPlayer (player=player@entry=0) at multijoin.cpp:473
#4  0x556afe5c in MultiPlayerJoin (playerIndex=0) at multijoin.cpp:350
#5  0x557d0157 in NEThostGame 
(SessionName=SessionName@entry=0x55f234e3  "Mein Spiel", 
PlayerName=PlayerName@entry=0x55f20520  "Spieler", one=14, 
two=two@entry=0, three=three@entry=0, four=four@entry=0, plyrs=4) at 
netplay.cpp:2780
#6  0x556b5e5d in hostCampaign (sGame=sGame@entry=0x55f234e3 
 "Mein Spiel", sPlayer=sPlayer@entry=0x55f20520  
"Spieler") at multiopt.cpp:259
#7  0x556ab2d3 in processMultiopWidgets (id=10276) at multiint.cpp:3072
#8  0x556ada6c in runMultiOptions () at multiint.cpp:3751
#9  0x55799ea5 in titleLoop () at wrappers.cpp:176
#10 0x5567ddc5 in runTitleLoop () at main.cpp:923
#11 mainLoop () at main.cpp:995
#12 0x55804ccc in wzMainEventLoop () at main_sdl.cpp:1601
#13 0x5567ea97 in realmain (argc=, argv=) 
at main.cpp:1329
#14 0x72b642e1 in __libc_start_main (main=0x555d0df0 , argc=1, argv=0x7fffe668, init=, fini=, rtld_fini=, stack_end=0x7fffe658) at 
../csu/libc-start.c:291
#15 0x555d0fea in _start ()
Description: Avoid calling EC_KEY_dup with null pointer

Author: Bernhard Übelacker 
Bug-Debian: https://bugs.debian.org/930942
Forwarded: no
Last-Update: 2019-06-24

--- warzone2100-3.2.1.orig/lib/framework/crc.cpp
+++ warzone2100-3.2.1/lib/framework/crc.cpp
@@ -245,7 +245,9 @@ EcKey::EcKey()
 
 EcKey::EcKey(EcKey const )
 {
-	vKey = (void *)EC_KEY_dup((EC_KEY *)b.vKey);
+	vKey = nullptr;
+	if (!b.empty())
+		vKey = (void *)EC_KEY_dup((EC_KEY *)b.vKey);
 }
 
 EcKey::EcKey(EcKey &)
@@ -262,7 +264,8 @@ EcKey::~EcKey()
 EcKey ::operator =(EcKey const )
 {
 	clear();
-	vKey = (void *)EC_KEY_dup((EC_KEY *)b.vKey);
+	if (!b.empty())
+		vKey = (void *)EC_KEY_dup((EC_KEY *)b.vKey);
 	return *this;
 }
 

# Stretch/9.9 qemu amd64 VM 2019-06-24


apt update
apt dist-upgrade


apt install systemd-coredump xserver-xorg lightdm openbox mc gdb fakeroot 
warzone2100 warzone2100-dbgsym libssl1.1-dbgsym
apt build-dep warzone2100


mkdir /home/benutzer/source/libssl1.1/orig -p
cd/home/benutzer/source/libssl1.1/orig
apt source libssl1.1
cd

mkdir /home/benutzer/source/warzone2100/orig -p
cd/home/benutzer/source/warzone2100/orig
apt source warzone2100
cd


reboot


export DISPLAY=:0
gdb -q \
-ex 'set width 0' \
-ex 'set pagination off' \
-ex 'directory /home/benutzer/source/libssl1.1/orig/openssl-1.1.0j/crypto' \
-ex 'directory 
/home/benutzer/source/warzone2100/orig/warzone2100-3.2.1/lib/framework' \
-ex 'directory 
/home/benutzer/source/warzone2100/orig/warzone2100-3.2.1/src' \
-ex 'run' \
--args warzone2100





benutzer@debian:~$ gdb -q -ex 'set width 0' -ex 'set pagination off' -ex 'run' 
--args warzone2100
Reading symbols from warzone2100...(no debugging symbols found)...done.
Starting program: /usr/games/warzone2100 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe63a7700 (LWP 3843)]
info|02:03:13: [realmain:1146] Using 
/home/benutzer/.warzone2100-3.2/logs/WZlog-0624_140313.txt debug file
[New Thread 0x7fffe5b19700 (LWP 3850)]
[New Thread 0x7fffdc72c700 (LWP 3853)]
[New Thread 0x7fffdbf2b700 (LWP 3854)]
[New Thread 0x7fffdb72a700 (LWP 3855)]
[New Thread 0x7fffdaf29700 (LWP 3856)]
[New Thread 0x7fffda728700 (LWP 3857)]
[New Thread 0x7fffd9f27700 (LWP 3858)]
[New Thread 0x7fffd9726700 (LWP 3859)]
[New Thread 0x7fffd8f25700 (LWP 3860)]
[New Thread 0x7fffd7925700 (LWP 3861)]
[Thread 0x7fffd7925700 (LWP 3861) exited]
ALSA lib confmisc.c:767:(parse_card) cannot find card '0'
ALSA lib conf.c:4528:(_snd_config_evaluate) function snd_func_card_driver 
returned error: Datei oder Verzeichnis nicht gefunden
ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
ALSA lib conf.c:4528:(_snd_config_evaluate) function snd_func_concat returned 

Bug#930935: webkit2gtk: Baseline violation on i386

[Alberto Garcia]

Control: tags -1 patch pending

On Mon, Jun 24, 2019 at 10:29:56AM +0200, Alberto Garcia wrote:
> 2) Build with SSE2 completely disabled (using WTF_CPU_UNKNOWN, or
>somethig else, I'm still discussing this with the team).

Ok, this patch disables SSE2 and forces Webkit to use CLoop, the
C-based JavaScript interpreter (instead of using JIT or the asm-based
intepreter). That's the one used when the CPU is unknown or not
supported.

If no one has anything to say I'll upload it today. This should work
on all i386 CPUs, and we can later discuss if it's worth thinking of a
solution for SSE2-capable machines.

Berto
diff --git a/debian/NEWS b/debian/NEWS
index 8b5be11c238..72ce8c9fdd9 100644
--- a/debian/NEWS
+++ b/debian/NEWS
@@ -1,12 +1,3 @@
-webkit2gtk (2.24.1-2) unstable; urgency=high
-
-  Since version 2.24.0, i386 builds of WebKitGTK require an SSE2-capable
-  CPU. This instruction set was first introduced with the Pentium 4 in
-  year 2000. Support for older processors was dropped in WebKitGTK
-  upstream and is unfortunately not expected to come back.
-
- -- Alberto Garcia   Fri, 10 May 2019 15:40:28 +0300
-
 webkit2gtk (2.20.0-2) unstable; urgency=medium
 
   webkit2gtk 2.20.0 contains a security feature named Gigacage that
diff --git a/debian/changelog b/debian/changelog
index e5224cae539..6ddef67d1b8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,26 @@
+webkit2gtk (2.24.2-2) unstable; urgency=high
+
+  * The WebKitGTK security advisory WSA-2019-0003 lists the following
+security fixes in the latest versions of WebKitGTK+:
++ CVE-2019-8571, CVE-2019-8583, CVE-2019-8586, CVE-2019-8594,
+  CVE-2019-8609, CVE-2019-8611, CVE-2019-8622 and CVE-2019-8623
+  (fixed in 2.24.0).
++ CVE-2019-6237, CVE-2019-8584, CVE-2019-8587, CVE-2019-8596,
+  CVE-2019-8597, CVE-2019-8601, CVE-2019-8608, CVE-2019-8610 and
+  CVE-2019-8619 (fixed in 2.24.1).
++ CVE-2019-8595, CVE-2019-8607 and CVE-2019-8615 (fixed in 2.24.2).
+  * Use the CLoop Javascript interpreter in i386 and stop telling gcc to
+use SSE2 instructions (Closes: #930935).
++ debian/rules:
+  - Build with -DENABLE_JIT=OFF -DENABLE_C_LOOP=ON and stop using
+-msse2 -mfpmath=sse.
++ debian/patches/dont-detect-sse2.patch:
+  - Don't check for SSE2 support.
++ debian/NEWS:
+  - Remove item about the requirement to have an SSE2-capable CPU.
+
+ -- Alberto Garcia   Mon, 24 Jun 2019 16:34:09 +0300
+
 webkit2gtk (2.24.2-1) unstable; urgency=medium
 
   * New upstream release.
diff --git a/debian/patches/dont-detect-sse2.patch b/debian/patches/dont-detect-sse2.patch
new file mode 100644
index 000..59b3650f6b6
--- /dev/null
+++ b/debian/patches/dont-detect-sse2.patch
@@ -0,0 +1,24 @@
+From: Alberto Garcia 
+Subject: Don't check for SSE2 support on i386
+Bug-Debian: https://bugs.debian.org/930935
+Forwarded: no
+Index: webkitgtk/Source/cmake/WebKitCompilerFlags.cmake
+===
+--- webkitgtk.orig/Source/cmake/WebKitCompilerFlags.cmake
 webkitgtk/Source/cmake/WebKitCompilerFlags.cmake
+@@ -144,15 +144,6 @@ if (COMPILER_IS_GCC_OR_CLANG)
+ if (CMAKE_COMPILER_IS_GNUCXX)
+ WEBKIT_PREPEND_GLOBAL_COMPILER_FLAGS(-Wno-expansion-to-defined)
+ endif ()
+-
+-# Force SSE2 fp on x86 builds.
+-if (WTF_CPU_X86 AND NOT CMAKE_CROSSCOMPILING)
+-WEBKIT_PREPEND_GLOBAL_COMPILER_FLAGS(-msse2 -mfpmath=sse)
+-include(DetectSSE2)
+-if (NOT SSE2_SUPPORT_FOUND)
+-message(FATAL_ERROR "SSE2 support is required to compile WebKit")
+-endif ()
+-endif ()
+ endif ()
+ 
+ if (COMPILER_IS_GCC_OR_CLANG AND NOT MSVC)
diff --git a/debian/patches/series b/debian/patches/series
index 1bcc251ee09..12740b1f4e3 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -7,3 +7,4 @@ detect-gstreamer-gl.patch
 detect-woff.patch
 user-agent-branding.patch
 prefer-pthread.patch
+dont-detect-sse2.patch
diff --git a/debian/rules b/debian/rules
index b1e8caeb46f..ae93d5e38f8 100755
--- a/debian/rules
+++ b/debian/rules
@@ -23,9 +23,10 @@ ifeq (,$(filter $(DEB_HOST_ARCH),amd64 ppc64 ppc64el))
 	CFLAGS := $(CFLAGS:-g=-g1)
 endif
 
-# The 32-bit x86 build requires SSE2
+# Use the CLoop Javascript interpreter and disable the JIT. This is
+# slow but it is the most compatible solution for old (non-SSE2) CPUs.
 ifneq (,$(filter $(DEB_HOST_ARCH),i386))
-	CFLAGS += -msse2 -mfpmath=sse
+	EXTRA_CMAKE_ARGUMENTS += -DENABLE_JIT=OFF -DENABLE_C_LOOP=ON
 endif
 
 # See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81426

Bug#931012: unblock: gradle/4.4.1-6

[Emmanuel Bourg]

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

Hi,

I'd like to request gradle/4.4.1-6 to be unblocked. When fixing the gradle
package to work with OpenJDK 11 we mistakenly broke the compatibility with
OpenJDK 8 (#925225). Even if Buster ships only with OpenJDK 11 we cared to
preserve the compatibility of the Java build tools in Debian (Ant and Maven)
with OpenJDK 8 since it's still the most popular JDK (a recent survey
conducted by Jetbrains showed that 80% of the Java developers were still
using Java 8, and only 20% have adopted Java 11). We can expect the users
to be disappointed if the gradle package requires OpenJDK 11 or higher.

Ubuntu fixed the OpenJDK 8 compatibility 3 months ago and forwarded the
patch to Debian (the patch was backported from upstream). I've uploaded
the fix to unstable as gradle/4.4.1-6 and I've verified that the main
packages using Gradle are still building fine (openjfx, libspring-java,
gradle itself and a few others).

Thank you,

Emmanuel Bourg

unblock gradle/4.4.1-6
diff -Nru gradle-4.4.1/debian/changelog gradle-4.4.1/debian/changelog
--- gradle-4.4.1/debian/changelog   2019-02-26 20:02:13.0 +0100
+++ gradle-4.4.1/debian/changelog   2019-06-22 00:52:47.0 +0200
@@ -1,3 +1,17 @@
+gradle (4.4.1-6) unstable; urgency=medium
+
+  [ Tiago Stürmer Daitx ]
+  * Fix OpenJDK 8 compatibility: (Closes: #925225)
+- debian/patches/java8-compatibility.patch: cast ByteBuffer to Buffer
+  in org.gradle.internal.hash.Hashing to prevent NoSuchMethodError
+  exception.
+- debian/patches/java11-compatibility.patch: copy upstream commit for
+  "Use Lookup to invoke defineClass on Java 9+ (#4976)" instead using
+  the previous partial backport to enable both OpenJDK 8 and 11 support.
+  * debian/control: revert gradle Depends back to java 8
+
+ -- Emmanuel Bourg   Sat, 22 Jun 2019 00:52:47 +0200
+
 gradle (4.4.1-5) unstable; urgency=medium
 
   * Team upload.
diff -Nru gradle-4.4.1/debian/control gradle-4.4.1/debian/control
--- gradle-4.4.1/debian/control 2019-02-26 20:02:13.0 +0100
+++ gradle-4.4.1/debian/control 2019-06-22 00:49:27.0 +0200
@@ -76,7 +76,7 @@
 
 Package: gradle
 Architecture: all
-Depends: default-jre-headless (>= 2:1.9) | java9-runtime-headless,
+Depends: default-jre-headless (>= 2:1.8) | java8-runtime-headless,
  libgradle-core-java (>= ${binary:Version}),
  libgradle-plugins-java (>= ${binary:Version}),
  ${misc:Depends}
diff -Nru gradle-4.4.1/debian/patches/java11-compatibility.patch 
gradle-4.4.1/debian/patches/java11-compatibility.patch
--- gradle-4.4.1/debian/patches/java11-compatibility.patch  2019-02-26 
20:02:13.0 +0100
+++ gradle-4.4.1/debian/patches/java11-compatibility.patch  2019-06-22 
00:50:07.0 +0200
@@ -4,51 +4,238 @@
   
https://github.com/gradle/gradle/commit/3db6e256987053171178aa96a0ef46caedc8d1a4
 --- 
a/subprojects/base-services/src/main/java/org/gradle/internal/classloader/ClassLoaderUtils.java
 +++ 
b/subprojects/base-services/src/main/java/org/gradle/internal/classloader/ClassLoaderUtils.java
-@@ -24,6 +24,9 @@
+@@ -15,51 +15,41 @@
+  */
+ package org.gradle.internal.classloader;
+ 
++import org.gradle.api.JavaVersion;
+ import org.gradle.internal.Cast;
+ import org.gradle.internal.UncheckedException;
+ import org.gradle.internal.concurrent.CompositeStoppable;
+ import org.gradle.internal.reflect.JavaMethod;
+-import org.gradle.internal.reflect.JavaReflectionUtil;
+-import sun.misc.Unsafe;
  
  import javax.annotation.Nullable;
  import java.io.IOException;
+-import java.lang.reflect.Field;
+-import java.net.MalformedURLException;
 +import java.lang.invoke.MethodHandle;
 +import java.lang.invoke.MethodHandles;
 +import java.lang.invoke.MethodType;
- import java.lang.reflect.Field;
- import java.net.MalformedURLException;
  import java.net.URL;
-@@ -31,16 +34,15 @@
- 
- public abstract class ClassLoaderUtils {
+ import java.net.URLConnection;
  
+-public abstract class ClassLoaderUtils {
+-
 -private static final Unsafe UNSAFE;
-+private static MethodHandle defineClassMethodHandle;
- 
- static {
- try {
+-
+-static {
+-try {
 -Field theUnsafe = Unsafe.class.getDeclaredField("theUnsafe");
 -theUnsafe.setAccessible(true);
 -UNSAFE = (Unsafe) theUnsafe.get(null);
 -} catch (NoSuchFieldException e) {
 -throw new RuntimeException(e);
 -} catch (IllegalAccessException e) {
-+MethodHandles.Lookup baseLookup = MethodHandles.lookup();
-+MethodType defineClassMethodType = 
MethodType.methodType(Class.class, new Class[]{String.class, byte[].class, 
int.class, int.class});
-+MethodHandles.Lookup lookup = 
MethodHandles.privateLookupIn(ClassLoader.class, baseLookup);
-+defineClassMethodHandle = lookup.findVirtual(ClassLoader.class, 

Bug#931011: libjsonnet-dev lacks libjsonnet++.so

[Brett Viren]

Package: libjsonnet-dev
Version: 0.12.1+ds-1

Thank you for packaging jsonnet for Debian.

The C++ library libjsonnet++.so is missing from the current packaging.
It is needed in order to use the libjsonnet++.h header which is included
in the packaging.

I guess the reason libjsonnet++.so was not included is that it was not
built by the CMake build and not built by default with the plain
Makefile build.

An upstream PR was made yesterday that adds the building of
libjsonnet++.so to both these build methods:

  https://github.com/google/jsonnet/pull/675

Without this PR, doing "make all" using the generic Makefile will also
build libjsonnet++.so (as well as some additional things not included in
the current packaging).

I guess PR the will be included in a post 0.13 upstream release. 

-Brett.


signature.asc
Description: PGP signature

Bug#931010: xpdf: When xpdf fails on startup (e.g. due to unsupported PDF file), it does not show an error message

[Vincent Lefevre]

Package: xpdf
Version: 3.04-13
Severity: normal

When xpdf fails on startup (e.g. because the PDF file provided in
the command line is invalid or not supported), it does not show an
error message. Error on stderr is not sufficient because it may not
be visible.

Firefox is affected by this issue:

  https://bugzilla.mozilla.org/show_bug.cgi?id=1318331

(closed as WONTFIX, as it is regarded as a bug in xpdf), i.e. there
is no feedback, so that the user wonders what's going on.

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

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

Versions of packages xpdf depends on:
ii  libc6 2.28-10
ii  libgcc1   1:8.3.0-7
ii  libpaper1 1.1.27
ii  libpoppler82  0.71.0-5
ii  libstdc++68.3.0-7
ii  libx11-6  2:1.6.7-1
ii  libxm42.3.8-2
ii  libxt61:1.1.5-1+b3

Versions of packages xpdf recommends:
ii  cups-bsd2.2.10-6
ii  gsfonts-x11 0.26
ii  poppler-data0.4.9-2
ii  poppler-utils   0.71.0-5
ii  sensible-utils  0.0.12

xpdf suggests no packages.

-- no debconf information

Bug#931009: tensorwatch -- Debug, monitor and visualize for Python Machine Learning

[Gürkan Myczko]

Package: wnpp
Severity: wishlist

* Package name: tensorwatch
  Version : 0.8.3
  Upstream Authors: Microsoft Corporation. All rights reserved.
* URL : https://github.com/microsoft/tensorwatch
* License : MIT
  Description : Debug, monitor and visualize for Python Machine 
Learning
 This is a debugging and visualization tool designed for data science, 
deep
 learning and reinforcement learning from Microsoft Research. It works 
in
 Jupyter Notebook to show real-time visualizations of your machine 
learning
 training and perform several other key analysis tasks for your models 
and

 data.
 .
 TensorWatch is designed to be flexible and extensible so you can also 
build
 your own custom visualizations, UIs, and dashboards. Besides 
traditional
 "what-you-see-is-what-you-log" approach, it also has a unique 
capability to
 execute arbitrary queries against your live ML training process, return 
a
 stream as a result of the query and view this stream using your choice 
of a

 visualizer (we call this Lazy Logging Mode).
 .
 This package installs the library for Python 3.

Package will be availabe at http://phd-sid.ethz.ch/debian/tensorwatch/
(only useful with tensorflow and/or pytorch)

Bug#930700: Re: Bug#930700: lintian: support "suppress-tags-from-file" in configuration file

[Chris Lamb]

Dear Dmitry,

> Some of tags have too much false-positive rate, and some of them are not
> worth spending time. Here is incomplete list:

Neat. So, I think there are three categories here.

Firstly, tags that you feel are too high priority are likely worth
discussing in terms of adjusting that severity level. (I'm not sure
what the best venue for that topic is but I dont think it's *this*
particular bug, alas.)

In other words, did you consider requesting adjusting the priority
some of the tags you perceive as "low priority" with respect to your
time? Or perhaps even for you to adjust which minimum severity level
that you run Lintian at?

Secondly, ones that you -- how shall I put it? -- "don't care about"
are probably outside the scope of changing, unless you feel they are
overblown severity-wise, in which case see the preceding paragraphs.

Lastly, there are ones with too many false-positives. These seem the
easy ones to address actually -- if you have a concrete example of
false-positives, please file away.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#930428: debootstrap should ensure matching _apt uid

[Johannes Schauer]

Hi all,

Quoting Philipp Kern (2019-06-23 15:14:34)
> On 2019-06-21 07:51, Trek wrote:
> >> If _apt deserves a special solution, I would suggest assigning the
> >> _apt user a static uid instead of patching debootstrap.
> > it seems to me the simplest approach, from a technical point of view,
> > and it's the one I'm using since _apt user was introduced (making sure
> > uids match)
> Adding deity@l.d.o. APT maintainers, please see the context in the bug. 
> Do you think there should be logic in debootstrap to handle the case of 
> trying to have the same UID within a chroot and outside, or could you 
> apply for a static UID assignment? I would also prefer the latter, but I 
> honestly don't know how messy the migration would be...

with my mmdebstrap-maintainer hat on, I wanted to quickly chime in and express
my support for the _apt user having a reproducible user id. The status quo is,
that the apt user id depends on the order in which the maintainer scripts are
executed. Because of this I had to disable some mmdebstrap tests where I
compare the mmdebstrap chroot against the debootstrap chroot because the _apt
uid would be different. One of the goals of mmdebstrap is to be a
proof-of-concept of moving more and more of the mechanics that are currently
hardcoded in debootstrap into apt and dpkg. So from my perspective, fixing the
_apt uid is one piece of the puzzle that would make the life of debootstrap
alternatives like mmdebstrap easier.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#931008: Bug causes unread/read status not to be saved

[Alexander MacCuish]

Package: kopano-server

Version: 8.7.0-3



Emails read using the WebApp do not correctly save read/unread status. This has 
been fixed upstream (BUG: https://jira.kopano.io/browse/KC-1444, Release: 
https://kopano.com/releases/kopano-releases-may-2019/). From the release page 
above, the problem is described thus: "The 8.7.1 release of Kopano Groupware 
Core is a bugfix release, resolving (amongst other things) the caching issues 
that some customers have encountered after installing version 8.7.0. This also 
includes the issue where emails that have been read are later marked as unread 
again. If you were affected by this issue, make sure you run the applicable 
kopano-dbadm command after upgrading (more details in the changelog)."



Thanks!

Bug#931007: ghkl: Homepage link broken

[D Haley]

Package: ghkl
Version: 5.0.0.2456-1
Severity: normal

Dear Maintainer,

The listed URL for the external resource (homepage) for ghkl does not appear to 
be functional, and simply directs back to the institutional home page

Specifically, the listed URL:
https://www.synchrotron-soleil.fr/portal/page/portal/Instrumentation/EnvironnementInstrumental/hkl


redirects to:
https://www.synchrotron-soleil.fr/fr/savoir-faire

which has no information on the program (that I can find after a short browse).

Thanks!

-- System Information:
Debian Release: 9.6
  APT prefers testing
  APT policy: (1, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages ghkl depends on:
pn  libbullet2.87 
ii  libc6 2.28-2
pn  libg3d0   
ii  libgcc1   1:6.3.0-18+deb9u1
ii  libgl1-mesa-glx [libgl1]  13.0.6-1+b2
ii  libglib2.0-0  2.58.2-3
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  libgtk2.0-0   2.24.31-2
ii  libgtkglext1  1.2.0-4
pn  libhkl5   
ii  libstdc++68.2.0-14
ii  libyaml-0-2   0.1.7-2

ghkl recommends no packages.

ghkl suggests no packages.

Bug#928882: unblock: [pre-approval] ghc/8.4.4+dfsg1-3

[Ilias Tsitsimpis]

Hi Emanuele,

On Thu, Jun 20, 2019 at 12:05AM, Emanuele Olivetti wrote:
> Indeed, I'll be very happy to test git-annex!

Could you please test git-annex version 7.20190129-3+b1 from unstable?

Thanks,

-- 
Ilias

Bug#931006: libmodglue1v5: change upstream source

[Olaf Schulz]

Package: libmodglue1v5
Version: 1.17-3
Severity: minor

Dear Maintainer,

I wanted to know more about the package's context and use cases.

The mentioned Home page has gone, only available at web.archive.org (and
maybe similar services).

With some research I found https://github.com/kpeeters/modglue checked
in by the original author.

Could this be a starting point for a maintainable upstream source?

Unfortunately I do not know the usual procedures but I consider this for
a useful URL (the repo contains some maintaining history from the past).

If possible, could you add this to the (source) package information?

Thanks
Olaf
*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- 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-9-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libmodglue1v5 depends on:
ii  libc6  2.24-11+deb9u4
ii  libgcc11:6.3.0-18+deb9u1
ii  libsigc++-2.0-0v5  2.10.0-1
ii  libstdc++6 6.3.0-18+deb9u1

libmodglue1v5 recommends no packages.

libmodglue1v5 suggests no packages.

-- no debconf information

Bug#931005: exim4-config: Restricted characters in address ^.*x24 : ^.*0.44

[Brent Clark]

Package: exim4-config
Version: 4.92-8~bpo9+1
Severity: wishlist

Dear Maintainer,

I would like to ask if the following two can be added to 
CHECK_RCPT_LOCAL_LOCALPARTS and / or CHECK_RCPT_REMOTE_LOCALPARTS
^.*x24 : ^.*0.44

Please see.
https://lists.exim.org/lurker/message/20190623.215213.c6070678.en.html

This is for /etc/exim4/conf.d/main/01_exim4-config_listmacrosdefs?

Many thanks

Regards
Brent Clark

-- Package-specific info:
Exim version 4.92 #5 built 20-Jun-2019 11:47:55
Copyright (c) University of Cambridge, 1995 - 2018
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2018
Berkeley DB: Berkeley DB 5.3.28: (September  9, 2013)
Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages DANE DKIM DNSSEC 
Event OCSP PRDR SOCKS TCP_Fast_Open
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz 
dbmnz dnsdb dsearch nis nis0 passwd
Authenticators: cram_md5 plaintext
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp
Fixed never_users: 0
Configure owner: 0:0
Size of off_t: 8
Configuration file search path is 
/etc/exim4/exim4.conf:/var/lib/exim4/config.autogenerated
Configuration file is /var/lib/exim4/config.autogenerated

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

Kernel: Linux 4.19.0-0.bpo.5-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_ZA.UTF-8, LC_CTYPE=en_ZA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_ZA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages exim4-config depends on:
ii  adduser3.115
ii  debconf [debconf-2.0]  1.5.61

exim4-config recommends no packages.

exim4-config suggests no packages.

-- debconf information excluded

Bug#930887: [Debian-ha-maintainers] Bug#930887: CVE-2019-10153

[wferi]

Moritz Muehlenhoff  writes:

> Please see https://bugzilla.redhat.com/show_bug.cgi?id=1716286

Hi Moritz,

According to https://security-tracker.debian.org/tracker/CVE-2019-10153,
the vulnerable code is not present in stretch.  However, I don't
understand why this does not count:

https://salsa.debian.org/ha-team/fence-agents/blob/debian/4.0.25-1/fence/agents/rhevm/fence_rhevm.py#L124

Also, according to http://pycurl.io/docs/latest/unicode.html#unicode the
URL conversion to ASCII can fail even when it's implicit, though that
probably isn't user controllable, thus may not count.
-- 
Thanks,
Feri

Bug#908678: Update on the security-tracker git discussion

[Salvatore Bonaccorso]

Hi,

On Sun, Jun 09, 2019 at 01:48:58PM +0200, Salvatore Bonaccorso wrote:
> On Sat, Jun 08, 2019 at 06:29:24PM +0200, Salvatore Bonaccorso wrote:
> > Notes on possible CVE/list splits
> > -
> [...]
> 
> After a face-to-face conversation with Daniel, Daniel suggested to
> create a priority list out of that, we will followup with that to that
> (ideally as gitlab task-list) here with a link once we have made our
> minds on it.

The plan was initially to do that in that week. Due to some other
issues (Debian related, and other) this was not possible. The plan
still holds to prioritize these tasks so that people wanting to help
contribute have something to tackle.

Regards,
Salvatore

Bug#931004: mate-menu: duplicate files in package

[Jonathan Krebs]

Package: mate-menu
Version: 18.04.3-3
Severity: normal

Dear Maintainer,

* What led up to the situation?
   While trying to implement input grabbing, I noticed that the plugin
   source files are duplicated:
   - once in /usr/share/mate-menu/plugins
   - once in /usr/lib/python2.7/dist-packages/mate_menu/plugins.
   The ones in the python directory are used.

* What was the outcome of this action?
   I was confused :)

* What outcome did you expect instead?
   changing the code of a plugin changes it's behavior


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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.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 mate-menu depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  gir1.2-gtk-3.0   3.24.5-1
ii  gir1.2-mate-panel1.20.5-1
ii  gir1.2-matedesktop-2.0   1.20.4-2
ii  libglib2.0-bin   2.58.3-2
ii  mate-menus   1.20.2-1
ii  mozo 1.20.2-1
ii  python   2.7.16-1
ii  python-configobj 5.0.6-3
ii  python-mate-menu 1.20.2-1
ii  python-pkg-resources 40.8.0-1
ii  python-setproctitle  1.1.10-1+b2
ii  python-xdg   0.25-5
ii  python-xlib  0.23-2
ii  xdg-utils1.1.3-1

mate-menu recommends no packages.

Versions of packages mate-menu suggests:
pn  software-center  
ii  synaptic 0.84.6

-- no debconf information

Bug#930992: Acknowledgement (openstack-deploy all-in-one fails with unavailable packages)

[Svein-Erik Skjelbred]

Bug 930999 on nova-common is also needed to get openstack-deploy 
all-in-one be fully automatic

Bug#930932: zenity: Zenity crashes out on Athlon XP CPU.

[Iris (Delta)]

On Mon, 24 Jun 2019 11:35:52 +0200 Alberto Garcia  wrote:
>
> I suppose this won't solve the problem, but can you try to set these
> evironment variables (or a combination thereof) and see if it works?
>
> JavaScriptCoreUseJIT=0
> JSC_useJIT=false

These resulted in no changes.

I also cannot replace these systems (several hundred) at this time.

Bug#931002: rust-coresimd: FTBFS (unrecognized platform-specific intrinsic function: `x86_rdrand16_step`unrecognized platform-specific intrinsic function: `x86_rdrand16_step`)

[Santiago Vila]

Package: src:rust-coresimd
Version: 0.1.2-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-arch
dh build-arch --buildsystem cargo
   dh_update_autotools_config -a -O--buildsystem=cargo
   dh_autoreconf -a -O--buildsystem=cargo
   dh_auto_configure -a -O--buildsystem=cargo
debian cargo wrapper: options, profiles, parallel: ['parallel=2'] [] ['-j2']
debian cargo wrapper: rust_type, gnu_type: x86_64-unknown-linux-gnu, 
x86_64-linux-gnu
debian cargo wrapper: linking /usr/share/cargo/registry/* into 
/<>/debian/cargo_registry/
   dh_auto_build -a -O--buildsystem=cargo
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
export RUSTC_BOOTSTRAP=1; \
dh_auto_test
debian cargo wrapper: options, profiles, parallel: ['parallel=2'] [] ['-j2']
debian cargo wrapper: rust_type, gnu_type: x86_64-unknown-linux-gnu, 
x86_64-linux-gnu
debian cargo wrapper: running subprocess (['env', 'RUST_BACKTRACE=1', 
'/usr/bin/cargo', '-Zavoid-dev-deps', 'build', '--verbose', '--verbose', '-j2', 
'--target', 'x86_64-unknown-linux-gnu'],) {}
   Compiling coresimd v0.1.2 (/<>)
 Running `rustc --crate-name build_script_build build.rs --color never 
--crate-type bin --emit=dep-info,link -C debuginfo=2 -C 
metadata=4c9f73b74e941fa4 -C extra-filename=-4c9f73b74e941fa4 --out-dir 
/<>/target/debug/build/coresimd-4c9f73b74e941fa4 -C 
incremental=/<>/target/debug/incremental -L 
dependency=/<>/target/debug/deps`
 Running 
`/<>/target/debug/build/coresimd-4c9f73b74e941fa4/build-script-build`
[coresimd 0.1.2] cargo:rustc-env=TARGET=x86_64-unknown-linux-gnu
 Running `rustc --crate-name coresimd src/lib.rs --color never --crate-type 
lib --emit=dep-info,link -C debuginfo=2 -C metadata=709a32ec1dae0a97 -C 
extra-filename=-709a32ec1dae0a97 --out-dir 
/<>/target/x86_64-unknown-linux-gnu/debug/deps --target 
x86_64-unknown-linux-gnu -C 
incremental=/<>/target/x86_64-unknown-linux-gnu/debug/incremental 
-L dependency=/<>/target/x86_64-unknown-linux-gnu/debug/deps -L 
dependency=/<>/target/debug/deps -C debuginfo=2 --cap-lints warn 
-C linker=x86_64-linux-gnu-gcc -C link-arg=-Wl,-z,relro --remap-path-prefix 
/<>=/usr/share/cargo/registry/coresimd-0.1.2`
error: unrecognized platform-specific intrinsic function: `x86_rdrand16_step`
 --> src/coresimd/x86/rdrand.rs:6:5
  |
6 | fn x86_rdrand16_step() -> (u16, i32);
  | ^

error: unrecognized platform-specific intrinsic function: `x86_rdrand32_step`
 --> src/coresimd/x86/rdrand.rs:7:5
  |
7 | fn x86_rdrand32_step() -> (u32, i32);
  | ^

error: unrecognized platform-specific intrinsic function: `x86_rdseed16_step`
 --> src/coresimd/x86/rdrand.rs:8:5
  |
8 | fn x86_rdseed16_step() -> (u16, i32);
  | ^

error: unrecognized platform-specific intrinsic function: `x86_rdseed32_step`
 --> src/coresimd/x86/rdrand.rs:9:5
  |
9 | fn x86_rdseed32_step() -> (u32, i32);
  | ^

error: unrecognized platform-specific intrinsic function: `x86_rdrand64_step`
 --> src/coresimd/x86_64/rdrand.rs:6:5
  |
6 | fn x86_rdrand64_step() -> (u64, i32);
  | ^

error: unrecognized platform-specific intrinsic function: `x86_rdseed64_step`
 --> src/coresimd/x86_64/rdrand.rs:7:5
  |
7 | fn x86_rdseed64_step() -> (u64, i32);
  | ^

error: aborting due to 6 previous errors

error: Could not compile `coresimd`.

Caused by:
  process didn't exit successfully: `rustc --crate-name coresimd src/lib.rs 
--color never --crate-type lib --emit=dep-info,link -C debuginfo=2 -C 
metadata=709a32ec1dae0a97 -C extra-filename=-709a32ec1dae0a97 --out-dir 
/<>/target/x86_64-unknown-linux-gnu/debug/deps --target 
x86_64-unknown-linux-gnu -C 
incremental=/<>/target/x86_64-unknown-linux-gnu/debug/incremental 
-L dependency=/<>/target/x86_64-unknown-linux-gnu/debug/deps -L 
dependency=/<>/target/debug/deps -C debuginfo=2 --cap-lints warn 
-C linker=x86_64-linux-gnu-gcc -C link-arg=-Wl,-z,relro --remap-path-prefix 
/<>=/usr/share/cargo/registry/coresimd-0.1.2` (exit code: 1)
dh_auto_test: /usr/share/cargo/bin/cargo build returned exit code 101
make[1]: *** [debian/rules:8: override_dh_auto_test] Error 101
make[1]: Leaving directory '/<>'
make: *** [debian/rules:4: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2


The build was made in my autobuilder with "dpkg-buildpackage -B"
and it also fails here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/rust-coresimd.html

where you can get a full build log if you need it.

If this is really a bug in one of the