Bug#939904: Processed (with 1 error): Re: Bug#930735: WireGuard: Add resolvconf as optional dependency

[Michael Biebl]

Am 10.09.19 um 08:54 schrieb Michael Biebl:

> You're right about the resolvconf.1 man page. We should not ship that in
> the systemd man page since we don't ship the resolvconf symlink either

systemd package...


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Bug#939917: at-spi2-core: obsolete conffiles left behind

[Sven Joachim]

Package: at-spi2-core
Version: 2.34.0-1
Severity: normal

In recent versions, two conffiles have been dropped from at-spi2-core,
but they remain on the system:

,
| $ adequate at-spi2-core
| at-spi2-core: obsolete-conffile /etc/environment.d/90qt-a11y.conf
| at-spi2-core: obsolete-conffile /etc/X11/Xsession.d/90qt-a11y
`

Please refer to dpkg-maintscript-helper(1) and dh_installdeb(1) how to
properly clean up obsolete conffiles.


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

Kernel: Linux 5.3.0-rc8-nouveau (SMP w/2 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)

Versions of packages at-spi2-core depends on:
ii  libatspi2.0-0  2.34.0-1
ii  libc6  2.29-1
ii  libdbus-1-31.12.16-1
ii  libglib2.0-0   2.60.6-2
ii  libx11-6   2:1.6.7-1
ii  libxtst6   2:1.2.3-1

at-spi2-core recommends no packages.

at-spi2-core suggests no packages.

-- no debconf information

Bug#939904: Processed (with 1 error): Re: Bug#930735: WireGuard: Add resolvconf as optional dependency

[Michael Biebl]

wouldn't it be better if wireguard calls resolvctl directly?
Then it knows exactly what kind of behaviour it'll get.

You're right about the resolvconf.1 man page. We should not ship that in
the systemd man page since we don't ship the resolvconf symlink either
(for obvious reasons).

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Bug#936281: Patch for Python3 [Was: Bug#936281: centrifuge: Python2 removal in sid/bullseye]

[Andreas Tille]

Hi,

as you can read below Debian will remove Python2 support in the next
release.  I noticed that the issue tracker of centrifuge is switched
off on github so I hope you can be reached via this e-Mail.  I've
crafted a patch using 2to3 to port centrifuge to Python3.  You can
find it in the Debian packaging Git here:

   
https://salsa.debian.org/med-team/centrifuge/blob/master/debian/patches/2to3.patch

Feel free to incorporate it into your next release.

Kind regards

   Andreas.


Control: forwarded -1 centrifuge.metagenom...@gmail.com

- Forwarded message from Matthias Klose  -

Date: Fri, 30 Aug 2019 07:12:58 +
From: Matthias Klose 
To: mainto...@bugs.debian.org
Subject: Bug#936281: centrifuge: Python2 removal in sid/bullseye
X-Debian-PR-Message: report 936281
X-Debian-PR-Package: src:centrifuge
X-Debian-PR-Keywords: bullseye sid
X-Debian-PR-Source: centrifuge

Package: src:centrifuge
Version: 1.0.3-2
Severity: normal
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: py2removal

Python2 becomes end-of-live upstream, and Debian aims to remove
Python2 from the distribution, as discussed in
https://lists.debian.org/debian-python/2019/07/msg00080.html

Your package either build-depends, depends on Python2, or uses Python2
in the autopkg tests.  Please stop using Python2, and fix this issue
by one of the following actions.

- Convert your Package to Python3. This is the preferred option.  In
  case you are providing a Python module foo, please consider dropping
  the python-foo package, and only build a python3-foo package.  Please
  don't drop Python2 modules, which still have reverse dependencies,
  just document them.
  
  This is the preferred option.

- If the package is dead upstream, cannot be converted or maintained
  in Debian, it should be removed from the distribution.  If the
  package still has reverse dependencies, raise the severity to
  "serious" and document the reverse dependencies with the BTS affects
  command.  If the package has no reverse dependencies, confirm that
  the package can be removed, reassign this issue to ftp.debian.org,
  make sure that the bug priority is set to normal and retitle the
  issue to "RM: PKG -- removal triggered by the Python2 removal".

- If the package has still many users (popcon >= 300), or is needed to
  build another package which cannot be removed, document that by
  adding the "py2keep" user tag (not replacing the py2remove tag),
  using the debian-pyt...@lists.debian.org user.  Also any
  dependencies on an unversioned python package (python, python-dev)
  must not be used, same with the python shebang.  These have to be
  replaced by python2/python2.7 dependencies and shebang.

  This is the least preferred option.

If the conversion or removal needs action on another package first,
please document the blocking by using the BTS affects command, like

  affects  + src:centrifuge

If there is no py2removal bug for that reverse-dependency, please file
a bug on this package (similar to this bug report).

If there are questions, please refer to the wiki page for the removal:
https://wiki.debian.org/Python/2Removal, or ask for help on IRC
#debian-python, or the debian-pyt...@lists.debian.org mailing list.

___
Debian-med-packaging mailing list
debian-med-packag...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

- End forwarded message -

-- 
http://fam-tille.de

Bug#939916: clfow: CVE-2019-16166

[Salvatore Bonaccorso]

Source: cflow
Version: 1:1.6-4
Severity: important
Tags: security upstream
Forwarded: https://lists.gnu.org/archive/html/bug-cflow/2019-04/msg0.html
Control: found -1 1:1.6-1

Hi,

The following vulnerability was published for cflow.

CVE-2019-16166[0]:
| GNU cflow through 1.6 has a heap-based buffer over-read in the
| nexttoken function in parser.c.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-16166
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16166
[1] https://lists.gnu.org/archive/html/bug-cflow/2019-04/msg0.html

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

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

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

Bug#931950: transition: libgeotiff

[Sebastiaan Couwenberg]

libgeotiff (1.5.1-2) is in testing, but libgeotiff-dfsg (1.4.3-1) cannot
be removed from testing due to gnudatalanguage, which I don't
understand. But this should be resolved when the package get autoremoved
on the 14th.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#939915: clfow: CVE-2019-16165

[Salvatore Bonaccorso]

Source: cflow
Version: 1:1.6-4
Severity: important
Tags: security upstream
Forwarded: https://lists.gnu.org/archive/html/bug-cflow/2019-04/msg1.html
Control: found -1 1:1.6-1

Hi,

The following vulnerability was published for cflow.

CVE-2019-16165[0]:
| GNU cflow through 1.6 has a use-after-free in the reference function
| in parser.c.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-16165
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16165
[1] https://lists.gnu.org/archive/html/bug-cflow/2019-04/msg1.html

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

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

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

Bug#842292: libnss3: re-enable SSLKEYLOGFILE support

[Tech Jsnelson]

On Thu, 27 Oct 2016 21:56:32 +0300 Evgeny Kapun 
wrote:
> Package: libnss3
> Version: 2:3.26-2
> Severity: wishlist
>
> In previous versions of libnss, it was possible to use SSLKEYLOGFILE
environment variable to save session keys to a file. Since version 3.24,
this is disabled by default at compile time [1].
>
> I think that SSLKEYLOGFILE support should be enabled for Debian builds of
libnss, since otherwise users who need this functionality have to make
their own builds of libnss.
>
> [1]
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.24_release_notes
>
> transparency = none bug you type becomes a null abject congrats you
downgraded to no integrity, good job🤨

Bug#939914: sysstat: CVE-2019-16167: Memory corruption bug due to Integer Overflow in remap_struct()

[Salvatore Bonaccorso]

Source: sysstat
Version: 12.0.6-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/sysstat/sysstat/issues/230

Hi,

The following vulnerability was published for sysstat.

CVE-2019-16167[0]:
| sysstat before 12.1.6 has memory corruption due to an Integer Overflow
| in remap_struct() in sa_common.c.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-16167
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16167
[1] https://github.com/sysstat/sysstat/issues/230

Please adjust the affected versions in the BTS as needed, only checked
unstable's version.

Regards,
Salvatore

Bug#939913: mark txt2tags Multi-Arch: foreign

[Helmut Grohne]

Source: txt2tags
Version: 2.6-4.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:cupt src:qgis src:thunderbolt-tools src:votca-csg 
src:votca-tools src:wmii

The affected packages fail to satisfy their cross Build-Depends, because
their dependeny on txt2tags is unsatisfiable. In general, Architecture:
all packages can never satisfy cross Build-Depends unless marked
Multi-Arch: foreign or annotated :native. In this case, it seems that
the Multi-Arch: foreign marking makes sense, because txt2tags only works
with textual file formats. Thus its behaviour is
architecture-independent, which is what Multi-Arch: foreign is about.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru txt2tags-2.6/debian/changelog txt2tags-2.6/debian/changelog
--- txt2tags-2.6/debian/changelog   2018-07-09 10:26:25.0 +0200
+++ txt2tags-2.6/debian/changelog   2019-09-10 06:12:38.0 +0200
@@ -1,3 +1,10 @@
+txt2tags (2.6-4.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark txt2tags Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 10 Sep 2019 06:12:38 +0200
+
 txt2tags (2.6-4.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru txt2tags-2.6/debian/control txt2tags-2.6/debian/control
--- txt2tags-2.6/debian/control 2018-04-22 19:07:13.0 +0200
+++ txt2tags-2.6/debian/control 2019-09-10 06:12:28.0 +0200
@@ -12,6 +12,7 @@
 
 Package: txt2tags
 Architecture: all
+Multi-Arch: foreign
 Depends: python, ${python:Depends}, ${misc:Depends}
 Suggests: python-tk
 Provides: python-txt2tags

Bug#939588: uim package lacks 2 files

[Takatsugu Nokubi]

On Sat, 07 Sep 2019 01:40:06 +0900 NIDE Naoyuki  wrote:
> Dear Maintainer,
>
> On a 'buster' system that is upgraded from 'stretch', uim lacks the following
> two files:
> /var/lib/uim/installed-modules.scm
> /var/lib/uim/loader.scm
> These files existed when the system was 'stretch', but after upgrading to
> 'buster', these files disappeared.

I tried to upgrade a stretch machine to buster, but the problem is not
reploduced.
Those files are generated by uim-module-manager, and the command is
invoked by maintainer scripts.

> Versions of packages uim depends on:
> ii  dpkg 1.19.7
> ii  libc62.28-10
> ii  libuim-scm0  1:1.8.8-4
> ii  libuim8  1:1.8.8-4
> ii  uim-data 1:1.8.8-4
> ii  uim-plugins  1:1.8.8-4

What Japanese engines do you use? I had uim-anthy and uim-mozc, and it works.

Bug#939890: buster-pu: package rpcbind/1.2.5-0.3+deb10u1

[Josue Ortega]

On 2019-09-09 20:06, Sam Hartman wrote:

> It seems concerning to decrease the security of  rpcbind to the NIS
> level with no option for the user to request the higher level of
> security.

You have a very good point here. Helped me to fully understand the
situation
 
> I do agree that fixing nis for stable is desirable.
> My recommendation would be to:
> 
> 1) Make this runtime configurable with an rpcbind command line option
> rather than a compile time option.
> The patche looks relatively simple to do that.

I will prepare the patch and submit the new debdiff ASAP

--
Josue

Bug#939911: cross-building: only add nocheck when host arch binaries cannot be run (using arch-test)

[Paul Wise]

Package: sbuild
Severity: wishlist

Please adjust the automatic addition of nocheck to the build options
and profiles so that nocheck is only added when host arch binaries
cannot be run.

The package arch-test provides a way to check if binaries for the host
arch can be run on the build arch. When arch-test is not available then
nocheck can be added when build != host arch as per usual.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#939912: cross-building: only add nocheck when host arch binaries cannot be run (using arch-test)

[Paul Wise]

Package: pbuilder
Severity: wishlist

Please adjust the automatic addition of nocheck to the build options
and profiles so that nocheck is only added when host arch binaries
cannot be run.

The package arch-test provides a way to check if binaries for the host
arch can be run on the build arch. When arch-test is not available then
nocheck can be added when build != host arch as per usual.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#939910: arch-test.1: binfmt no longer requires an interpreter to live inside the chroot

[Paul Wise]

Package: arch-test
Version: 0.16-2
Severity: minor
File: /usr/share/man/man1/arch-test.1.gz

Since Debian buster, qemu-user-static enabled the "fix binary" mode,
which means that interpreters no longer need to be copied or bind
mounted into chroots, which means that this sentence from the manual
page needs to be updated to mention the "fix binary" mode and that it
is enabled by default in some cases:

$ man arch-test | grep -o \(note.*\) 
(note that binfmt requires an interpreter to live inside the chroot)

Related bug reports:

https://bugs.debian.org/868030
https://bugs.debian.org/635385
https://bugs.debian.org/901197

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#939890: buster-pu: package rpcbind/1.2.5-0.3+deb10u1

[Sam Hartman]

> "Sam" == Sam Hartman  writes:

> "Josue" == Josue Ortega  writes:
Josue> On Mon, Sep 09, 2019 at 08:27:31PM -0400, Sam Hartman wrote:
>>> What are the security implications of enabling this configure
>>> flag?
Josue> Enabling this flag lets rpcbind to open random listening
Josue> ports.  This would make firewalling very hard.  (Default
Josue> behavior prior version 1.2.5)

>>> Why is it off by default?
Josue> Upstream set it off by default since they claimed about
Josue> customers complaining about this behavior and supposedly it's
Josue> not widely used.  Check [1] for more details.

Josue> Debian users running NIS services in Buster have reported
Josue> breakage in their system due the lack of the remote call
Josue> functionality.

Sam> For the stable release managers.  This change reverts a
Sam> security feature introduced upstream designed to make rpcbind
Sam> easier to firewall and reduce the attack surface of rpcbind.

FYI, I am *not* wearing my DPL hat in this conversation.
If anything I'm wearing my Kerberos maintainer hat, hoping that things
like nfs configured in a secure configuration remain secure.

Bug#939909: libxml2: Cannot build asterisk using this version of libxml2 (similar bug as #776724)

[Huabin Du]

Package: libxml2
Version: 2.9.4+dfsg1-7
Severity: important

Dear Maintainer,

When I try to compile Asterisk 16 on Debian 11, the below error kept me from a 
successful compiling:

configure: *** The Asterisk menuselect tool requires the 'libxml2' development 
package.
configure: *** Please install the 'libxml2' development package.


This is exactly the same as bug  
#776724

I'm sure that I have installed the libxml2-dev package on the system.

Also tried on Debian 8, 12, the same issue happened.

Bug#939876: gimp: segmentation fault on open

[Asher Gordon]

Package: gimp
Version: 2.10.8-2+b1
Followup-For: Bug #939876

Hello Witold,

Witold Baryluk  writes:

> I think I do have same issue.
>
> It happens even when creating an empty document using menu File ->
> New, with anysize (i.e. 1024x768). But also when opening any file
> (tested with png and jpeg files).
>
> Stack trace looks similar. Looks like a bug in gimp_gegl_mask_is_empty
> maybe?

The issue seems to be a GEGL version mismatch (compiled against versus
linked against).

> I hope this is fixed soon :)

If you need to use the GIMP right away, a workaround that worked for me
is to install the updated libgegl-0.4-0 and libgegl-common from sid.
Download the packages from the Debian website and install with gdebi or
similar (make sure to install libgegl-common first).

See also #939754 and #939768 which appear to be the same bug.

Asher

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me sprea=
d!


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

Kernel: Linux 5.2.0-2-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 gimp depends on:
ii  gimp-data2.10.8-2
ii  libaa1   1.4p5-46+b1
ii  libbabl-0.1-00.1.62-1
ii  libbz2-1.0   1.0.6-9.2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libfontconfig1   2.13.1-2+b1
ii  libfreetype6 2.9.1-4
ii  libgcc1  1:9.2.1-4
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libgegl-0.4-00.4.14-1+b2
ii  libgexiv2-2  0.10.9-1
ii  libgimp2.0   2.10.8-2+b1
ii  libglib2.0-0 2.60.6-2
ii  libgs9   9.27~dfsg-3.1
ii  libgtk2.0-0  2.24.32-3
ii  libgudev-1.0-0   232-2
ii  libharfbuzz0b2.6.1-2
ii  libheif1 1.5.1-1
ii  libilmbase24 2.3.0-6
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-3+b1
ii  liblzma5 5.2.4-1+b1
ii  libmng1  1.0.10+dfsg-3.1+b5
ii  libmypaint-1.3-0 1.3.0-2.1+b1
ii  libopenexr24 2.3.0-6
ii  libopenjp2-7 2.3.0-2
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libpangoft2-1.0-01.42.4-7
ii  libpng16-16  1.6.37-1
ii  libpoppler-glib8 0.71.0-5+b1
ii  librsvg2-2   2.44.14-1
ii  libstdc++6   9.2.1-4
ii  libtiff5 4.0.10+git190818-1
ii  libwebp6 0.6.1-2+b1
ii  libwebpdemux20.6.1-2+b1
ii  libwebpmux3  0.6.1-2+b1
ii  libwmf0.2-7  0.2.8.4-14
ii  libx11-6 2:1.6.7-1
ii  libxcursor1  1:1.2.0-2
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxmu6  2:1.1.2-2+b3
ii  libxpm4  1:3.5.12-1
ii  xdg-utils1.1.3-1
ii  zlib1g   1:1.2.11.dfsg-1+b1

Versions of packages gimp recommends:
ii  ghostscript  9.27~dfsg-3.1

Versions of packages gimp suggests:
pn  gimp-data-extras  
ii  gimp-help-en [gimp-help]  2.8.2-1
pn  gimp-python   
ii  gvfs-backends 1.38.1-5
ii  libasound21.1.8-1

-- no debconf information


signature.asc
Description: PGP signature

Bug#895787: Fwd: RFS: pcapy/0.11.3-1 [ITA]

[Emmanuel Arias]

Hello,

I've just push to salsa an update for the package

Cheers,
Arias Emmanuel
@eamanu
http://eamanu.com


El sáb., 7 de sep. de 2019 a la(s) 05:32, Arnaud Fontaine (ar...@debian.org)
escribió:

> Hi,
>
> Do you still intend to take over maintenance of this package? (last time
> I suggested to  sponsor your upload if needed but  I'm unfortunately not
> going to have time to do that anymore, sorry)
>
> Regards,
> --
> Arnaud Fontaine
>

Bug#939890: buster-pu: package rpcbind/1.2.5-0.3+deb10u1

[Sam Hartman]

> "Josue" == Josue Ortega  writes:

Josue> On Mon, Sep 09, 2019 at 08:27:31PM -0400, Sam Hartman wrote:
>> What are the security implications of enabling this configure
>> flag?
Josue> Enabling this flag lets rpcbind to open random listening
Josue> ports.  This would make firewalling very hard.  (Default
Josue> behavior prior version 1.2.5)

>> Why is it off by default?
Josue> Upstream set it off by default since they claimed about
Josue> customers complaining about this behavior and supposedly it's
Josue> not widely used.  Check [1] for more details.

Josue> Debian users running NIS services in Buster have reported
Josue> breakage in their system due the lack of the remote call
Josue> functionality.

For the stable release managers.
This change reverts  a security feature introduced upstream designed to
make rpcbind easier to firewall and reduce the attack surface of
rpcbind.

I'm reasonably familiar with portmap of old, but never really followed
the evolution from ONCRPC to TIRPC and don't remember all th obscure
aspects of NIS: it's been over 20 years since I used NIS.

In 10 minutes of googling I was not able to find what "remote calls" are
to really understand how NIS uses them and evaluate the security
implications.

At one level, yeah, Debian should support NIS if people want it.
And we have a regression.

At another level, it does look like this is security sensitive.  I think
using TIRPC for NFS is much more common than NIS.  Also, there are
configurations of NFS (for example NFSV4 secured by GSS-API) that are
vastly more secure than NIS.

It seems concerning to decrease the security of  rpcbind to the NIS
level with no option for the user to request the higher level of
security.

I do agree that fixing nis for stable is desirable.
My recommendation would be to:

1) Make this runtime configurable with an rpcbind command line option
rather than a compile time option.
The patche looks relatively simple to do that.

2) Document that option and its security implications better than I've
managed here.

--Sam

Bug#939804: [Pkg-erlang-devel] Bug#939804: erlang: FTBFS on hppa - escript: exception error: bad argument

[John David Anglin]

On 2019-09-09 9:12 a.m., Sergei Golovan wrote:
> Hi John,
>
> On Mon, Sep 9, 2019 at 2:13 PM John David Anglin  wrote:
>> If you know how to reduce one of these regexp problems, I could look again.  
>> Debugging
>> across forks is problematic (i.e., the error doesn't occur in escript).
> I seem to find the problematic code. If you look into
> erts/emulator/beam/erl_bif_re.c then
> you'll find the following lines after line 66:
>
> #define ERTS_PCRE_STACK_MARGIN (10*1024)
>
> #  define ERTS_STACK_LIMIT ((char *) ethr_get_stacklimit())
>
> static int
> stack_guard_downwards(void)
> {
> char *limit = ERTS_STACK_LIMIT;
> char c;
>
> ASSERT(limit);
>
> return erts_check_below_limit(&c, limit + ERTS_PCRE_STACK_MARGIN);
> }
>
> static int
> stack_guard_upwards(void)
> {
> char *limit = ERTS_STACK_LIMIT;
> char c;
>
> ASSERT(limit);
>
> return erts_check_above_limit(&c, limit - ERTS_PCRE_STACK_MARGIN);
> }
>
> void erts_init_bif_re(void)
> {
> char c;
> erts_pcre_malloc = &erts_erts_pcre_malloc;
> erts_pcre_free = &erts_erts_pcre_free;
> erts_pcre_stack_malloc = &erts_erts_pcre_stack_malloc;
> erts_pcre_stack_free = &erts_erts_pcre_stack_free;
> if ((char *) erts_ptr_id(&c) > ERTS_STACK_LIMIT)
> erts_pcre_stack_guard = stack_guard_downwards;
> else
> erts_pcre_stack_guard = stack_guard_upwards;
> default_table = NULL; /* ISO8859-1 default, forced into pcre */
> max_loop_limit = CONTEXT_REDS * LOOP_FACTOR;
>
> erts_init_trap_export(&re_exec_trap_export, am_erlang, am_re_run_trap, 3,
>   &re_exec_trap);
>
> grun_trap_exportp =  erts_export_put(am_re,am_grun,3);
> urun_trap_exportp =  erts_export_put(am_re,am_urun,3);
> ucompile_trap_exportp =  erts_export_put(am_re,am_ucompile,2);
>
> return;
> }
>
> The code
>
> if ((char *) erts_ptr_id(&c) > ERTS_STACK_LIMIT)
> erts_pcre_stack_guard = stack_guard_downwards;
> else
> erts_pcre_stack_guard = stack_guard_upwards;
>
> has been introduces in version 20, and it is used to protect stack
> during PCRE calls.
> It seems that this stack protection doesn't work for hppa and always
> fails. As a result,
> every call to a regexp routine fails.
>
> After I remove the erts_pcre_stack_guard assignment, Erlang started to
> build on hppa
> just fine.
>
I added some printfs to the code.

thr_wrapper: stacksize=0x0
thr_wrapper: stacksize=0x0
thr_wrapper: stacksize=0x0
thr_wrapper: stacksize=0x1
thr_wrapper: stacksize=0x1
thr_wrapper: stacksize=0x1
erts_init_bif_re: &c=0xf9730748 ERTS STACK LIMIT=0x0
erts_init_bif_re: &c=0xf9df6748 ERTS STACK LIMIT=0x0
erts_init_bif_re: &c=0xf90b0748 ERTS STACK LIMIT=0x0
erts_init_bif_re: &c=0xf908c748 ERTS STACK LIMIT=0x0
thr_wrapper: stacksize=0x8
thr_wrapper: stacksize=0x8
thr_wrapper: stacksize=0x8
thr_wrapper: stacksize=0x8
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x8
thr_wrapper: stacksize=0x8
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x8
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x8
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x8
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x8
thr_wrapper: stacksize=0x8
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x8
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x8
thr_wrapper: stacksize=0x8
thr_wrapper: stacksize=0x8
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x8
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrapper: stacksize=0x28000
thr_wrap

Bug#932817: Quote needed

[Sanford Rockowitz]

It looks like you got our name from some IBM list.  I'm afraid we can't 
help you.  We're software developers and that is our connection to IBM.


Regards,
Sanford Rockowitz

On 09/09/2019 03:26 PM, Jerry Edwards wrote:


Good day,

Can you please assist me with quote for the below product.

Lenovo Yoga C930 14" Intel® Core™ i7-8550U (1.80GHz, up to 4.0GHz, Win 
10,16GB DDR4 2400MHz,1TB SSD,UHD Graphics 620.


Thank you for your assistance.

Jerry Edwards
JC Window Fashions
6400 Fleet Street
Commerce, CA 90040
f...@jcwindowfashions.com 
Ph 909 359 2526

Bug#939737: emacs: please package newer release 26.3

[Rob Browning]

Héctor Orón Martínez  writes:

> Thanks very much for packaging emacs! However I tried to look at the
> Git repository at:
>   https://salsa.debian.org/rlb/deb-emacs
>
> I wanted to submit a MR for new upstream release, could you please
> explain which is debian packaging branch for new releases and how to
> handle upstream source?

I handle emacs using git-dpm, which automatically manages the patches,
and there's the added complication of the DFSG split.  The dpm managed
branches are

  deb/emacs/d/DIST/master
  deb/emacs/d/DIST/upstream

  deb/emacs-non-dfsg/d/DIST/master
  deb/emacs-non-dfsg/d/DIST/upstream

e.g.

  deb/emacs/d/sid/master
  deb/emacs/d/sid/upstream

  deb/emacs-non-dfsg/d/sid/master
  deb/emacs-non-dfsg/d/sid/upstream

And all tags are in

  deb/emacs/v/
  deb/emacs-non-dfsg/v/

Incorporating a new upstream release is somewhat complicated, mostly due
to the split and the related review of incoming changes, though it's
notably easier than it was when we had versioned emacsXY packages.

In any case, thanks for the offer to help, and I'd be more than happy to
have help, but for 26.3 I'm more or less ready.  We just have to wait
for the 26.1+1-4 release to migrate to testing and then I can finish up
and upload.  I'd imagine that might be later this week since I uploaded
-4 with urgency=high.

Thanks again
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#939845: modprobe: ERROR: could not insert 'wireguard': Exec format error

[Daniel Kahn Gillmor]

Control: tag 939845 + moreinfo unreproducible

Hi David--

On Mon 2019-09-09 14:52:48 +0200, David Raison wrote:
> I upgraded the wireguard-dkms package during a regular apt upgrade,
> which seems to have produced an invalid module:
>
> Unpacking wireguard-dkms (0.0.20190905-1) over (0.0.20190702-3) ...
> Setting up wireguard-dkms (0.0.20190905-1) ...
> Loading new wireguard-0.0.20190905 DKMS files...
> Reloading wireguard module...
> modprobe: ERROR: could not insert 'wireguard': Exec format error
> dpkg: error processing package wireguard (--configure):
>  installed wireguard package post-installation script subprocess returned 
> error exit status 1


I tried to reproduce this on a simple debian buster system with the
packages from snapshots, via:

apt install /root/wireguard/wireguard{,-dkms,-tools}_0.0.20190702-3_*.deb
modprobe -v wireguard
cat /sys/module/wireguard/version
apt install /root/wireguard/wireguard{,-dkms,-tools}_0.0.20190905-1_*.deb
cat /sys/module/wireguard/version

and that worked as expected.

the equivalent section of the apt output is:

DKMS: install completed.
Setting up wireguard-tools (0.0.20190905-1) ...
Setting up wireguard (0.0.20190905-1) ...
Reloading wireguard module...
Processing triggers for man-db (2.8.5-2) ...


> Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)

I note here that you're not running the latest kernel -- 4.19.0-5-amd64
is not 4.19.0-6-amd64.  is it possible that you don't have
linux-image-4.19.0-5-amd64 or its headers installed any more, despite
running that kernel?

Do we need to check that wireguard-dkms specifically succeeded in
generating a module for the running kernel?

i'd have expected that the postinst script itself would verify that
based on its invocation of 

modinfo -F version wireguard

which should only verify the available modules for the current version.

can you show the output of:

dpkg -l 'linux-headers-*' 'linux-image-*'

on the affected system?

thanks for the report, and sorry that i'm not currently able to
replicate it, hopefully we can figure it out.

   --dkg


signature.asc
Description: PGP signature

Bug#939890: buster-pu: package rpcbind/1.2.5-0.3+deb10u1

[Josue Ortega]

On Mon, Sep 09, 2019 at 08:27:31PM -0400, Sam Hartman wrote:
> What are the security implications of enabling this configure flag?
Enabling this flag lets rpcbind to open random listening ports.
This would make firewalling very hard. 
(Default behavior prior version 1.2.5)

> Why is it off by default?
Upstream set it off by default since they claimed about customers complaining
about this behavior and supposedly it's not widely used.
Check [1] for more details.

Debian users running NIS services in Buster have reported breakage in their 
system
due the lack of the remote call functionality.

[1]: https://sourceforge.net/p/libtirpc/mailman/message/36377232/

Regards,

Josue


signature.asc
Description: PGP signature

Bug#939532: RM: slapos.core -- ROM; python2-only; dead upstream; popcon=2; not in stable

[Sandro Tosi]

On Mon, Sep 9, 2019 at 7:28 PM Arnaud Fontaine  wrote:
> > It is already supported  but let me talk with the upstream  to see if it
> > still makes sense  to have it in Debian considering  the very low popcon
> > and I will get back to you.
>
> After  talking with  the upstream  developers,  it does  not make  sense
> anymore to  have this  package in  Debian. Also,  I have  just requested
> removal of  python-xmlmarshaller which  was only needed  for slapos.core
> (#939902).

Thanks a lot Arnaud!

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#938823: wicd and Python 3 (was: "wicd" utf8 and too many APs nightmare/bug)

[Axel Beckert]

Hi Guido,

Guido Maria Serra wrote:
> I ask for forgiveness, it is Monday morning...
> https://github.com/zeph/wicd/commit/404545ffd5a8448895e83b8b09ba79ac28416e36

I tried this one already, but bailed out, too. The other one looked
more promising IMHO. What worked in the end was this, though:

https://stackoverflow.com/questions/47838405/porting-a-sub-class-of-python2-file-class-to-python3
https://salsa.debian.org/debian/wicd/blob/python3/debian/patches/02-python3-fixups.patch#L285-296

I pushed a bunch of patch updates more into that branch:

https://salsa.debian.org/debian/wicd/commits/python3

So in the end
https://salsa.debian.org/debian/wicd/blob/python3/debian/patches/02-python3-fixups.patch
should make at least the wicd daemon(*) and wicd-curses run, but still
throw warnings.

(*) "/usr/sbin/wicd -c -f -e -o" works, but "/usr/sbin/wicd -c -f -e"
still fails as follows:

Traceback (most recent call last):
  File "/usr/share/wicd/daemon/wicd-daemon.py", line 1955, in 
main(sys.argv)
  File "/usr/share/wicd/daemon/wicd-daemon.py", line 1906, in main
print('---')
  File "/usr/lib/python3/dist-packages/wicd/logfile.py", line 148, in write
self._lf.write(data)
  File "/usr/lib/python3/dist-packages/wicd/logfile.py", line 52, in write
data = data.decode('utf-8').encode('utf-8')
AttributeError: 'str' object has no attribute 'decode'

Need to go to bed now. If you want, I can provide the work so far as
pull request against your repo. (But unless you say you want that, I
won't do it.)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#694507: javamorph: support gcj

[Emmanuel Bourg]

Control: tags -1 + wontfix
Control: close -1

GCJ is gone, this will never be fixed.

Bug#939890: buster-pu: package rpcbind/1.2.5-0.3+deb10u1

[Sam Hartman]

What are the security implications of enabling this configure flag?
Why is it off by default?

Bug#935492: marked as done (rpcbind: Broadcast requests broken)

[Josue Ortega]

Hi,

I've proposed an update fixing this issue for the next Debian Buster point
release, for more details check:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939890

Regards,

Josue


signature.asc
Description: PGP signature

Bug#939881: FTBFS: trying to run :rabbitmqctl on Elixir v1.9.1 but supports only >= 1.6.6 and < 1.8.0

[Ryan Tandy]

Control: tag -1 fixed-upstream

Elixir 1.9 is supported in upstream version 3.7.16 and later (current is 
3.7.17).


https://github.com/rabbitmq/rabbitmq-cli/compare/v3.7.15...v3.7.16
https://github.com/rabbitmq/rabbitmq-cli/commit/c3c6b9edd5af947c69370658f609026bfef8055b

Bug#939908: buster-pu: libsixel/1.8.2-1+deb10u1

[NOKUBI Takatsugu]

Package: release.debian.org
Severity: normal
Tags: patch security
X-Debbugs-CC: secure-testing-t...@lists.alioth.debian.org

The patch fixes:
CVE-2018-19756
CVE-2018-19757
CVE-2018-19759
CVE-2018-19761
CVE-2018-19762
CVE-2018-19763
CVE-2019-3573
CVE-2019-3574
diff --git a/debian/changelog b/debian/changelog
index b00aee0..bc3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+libsixel (1.8.2-1+deb10u1) buster-security; urgency=high
+
+  * Non-maintainer upload by the Security Team.
+  * d/patches/0001-Add-malloc-size-check.patch: fix CVE-2018-19756
+  * d/patches/0002-assign-default-error-message.patch: fix CVE-2018-19757
+  * d/patches/0003-add-limitation-to-width-and-height.patch: fix CVE-2018-19759
+  * d/patches/0004-position-error-check.patch: fix CVE-2018-19761
+  * d/patches/0005-size-check.patch: fix CVE-2018-19762
+  * d/patches/0006-prevent-to-access-heap-overflow.patch: fix CVE-2018-19763
+  * d/patches/0007-check-error-for-jpeg_read_scanlines.patch: fix CVE-2019-3573
+  * d/patches/0008-check-number-of-repeat_count.patch: fix CVE-2019-3574
+
+ -- NOKUBI Takatsugu   Mon, 09 Sep 2019 12:42:52 +0900
+
 libsixel (1.8.2-1) unstable; urgency=medium
 
   * New upstream, security fix (closes: #903858)
diff --git a/debian/patches/0001-Add-malloc-size-check.patch b/debian/patches/0001-Add-malloc-size-check.patch
new file mode 100644
index 000..b53305f
--- /dev/null
+++ b/debian/patches/0001-Add-malloc-size-check.patch
@@ -0,0 +1,24 @@
+From: Takatsugu Nokubi 
+Date: Mon, 8 Jul 2019 13:46:11 +0900
+Subject: Add malloc size check
+
+---
+ src/allocator.c | 5 +
+ 1 file changed, 5 insertions(+)
+
+diff --git a/src/allocator.c b/src/allocator.c
+index b9b2d02..bb0c009 100644
+--- a/src/allocator.c
 b/src/allocator.c
+@@ -147,6 +147,11 @@ sixel_allocator_malloc(
+ assert(allocator);
+ assert(allocator->fn_malloc);
+ 
++if (n == 0) {
++sixel_helper_set_additional_message(
++"sixel_allocator_malloc: called with n == 0");
++return NULL;
++}
+ return allocator->fn_malloc(n);
+ }
+ 
diff --git a/debian/patches/0002-assign-default-error-message.patch b/debian/patches/0002-assign-default-error-message.patch
new file mode 100644
index 000..c7d4687
--- /dev/null
+++ b/debian/patches/0002-assign-default-error-message.patch
@@ -0,0 +1,21 @@
+From: Takatsugu Nokubi 
+Date: Tue, 23 Jul 2019 17:12:43 +0900
+Subject: assign default error message
+
+---
+ src/stb_image.h | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/src/stb_image.h b/src/stb_image.h
+index 2673809..09ebbd5 100644
+--- a/src/stb_image.h
 b/src/stb_image.h
+@@ -845,6 +845,8 @@ static const char *stbi__g_failure_reason;
+ 
+ STBIDEF const char *stbi_failure_reason(void)
+ {
++   if (stbi__g_failure_reason == NULL)
++  stbi__g_failure_reason = "unknwon error, refer error message before assignment";
+return stbi__g_failure_reason;
+ }
+ 
diff --git a/debian/patches/0003-add-limitation-to-width-and-height.patch b/debian/patches/0003-add-limitation-to-width-and-height.patch
new file mode 100644
index 000..63528b8
--- /dev/null
+++ b/debian/patches/0003-add-limitation-to-width-and-height.patch
@@ -0,0 +1,39 @@
+From: Takatsugu Nokubi 
+Date: Thu, 1 Aug 2019 14:59:58 +0900
+Subject: add limitation to width and height
+
+---
+ include/sixel.h.in | 3 +++
+ src/decoder.c  | 5 +
+ 2 files changed, 8 insertions(+)
+
+diff --git a/include/sixel.h.in b/include/sixel.h.in
+index 7ffe90f..4365c67 100644
+--- a/include/sixel.h.in
 b/include/sixel.h.in
+@@ -366,6 +366,9 @@ typedef int SIXELSTATUS;
+ #define SIXEL_OPTFLAG_VERSION   ('V')  /* -V, --version: show version and license info */
+ #define SIXEL_OPTFLAG_HELP  ('H')  /* -H, --help: show this help */
+ 
++#define SIXEL_WIDTH_LIMIT   100
++#define SIXEL_HEIGHT_LIMIT  100
++
+ #if SIXEL_USE_DEPRECATED_SYMBOLS
+ /* output character size */
+ enum characterSize {
+diff --git a/src/decoder.c b/src/decoder.c
+index 63ab4af..c763e4d 100644
+--- a/src/decoder.c
 b/src/decoder.c
+@@ -315,6 +315,11 @@ sixel_decoder_decode(
+ goto end;
+ }
+ 
++if (sx > SIXEL_WIDTH_LIMIT || sy > SIXEL_HEIGHT_LIMIT) {
++status = SIXEL_BAD_INPUT;
++goto end;
++}
++
+ status = sixel_helper_write_image_file(indexed_pixels, sx, sy, palette,
+SIXEL_PIXELFORMAT_PAL8,
+decoder->output,
diff --git a/debian/patches/0004-position-error-check.patch b/debian/patches/0004-position-error-check.patch
new file mode 100644
index 000..126d3d7
--- /dev/null
+++ b/debian/patches/0004-position-error-check.patch
@@ -0,0 +1,23 @@
+From: Takatsugu Nokubi 
+Date: Thu, 25 Jul 2019 16:19:59 +0900
+Subject: position error check
+
+---
+ src/fromsixel.c | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/src/fromsixel.c b/src/fromsixel.c
+index 7d8390a..1d86858 1

Bug#939907: stretch-pu: package libsixel/1.5.2-2+deb9u1

[NOKUBI Takatsugu]

Package: reportbugrelease.debian.org
Severity: important
Tags: patch security
X-Debbugs-CC: secure-testing-t...@lists.alioth.debian.org

This patch fixes:
CVE-2018-14072
CVE-2018-14073
CVE-2018-19756
CVE-2018-19757
CVE-2018-19759
CVE-2018-19762
CVE-2018-19763
CVE-2019-3573
CVE-2019-3574

CVE-2018-19761 is not affected the version.
diff --git a/debian/changelog b/debian/changelog
index 67fe373..22edc45 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+libsixel (1.5.2-2+deb9u1) stretch-security; urgency=medium
+
+  * d/patches/0001-Add-malloc-size-check.patch: fix CVE-2018-19756
+  * d/patches/0002-assign-default-error-message.patch: fix CVE-2018-19757
+  * d/patches/0003-add-limitation-to-width-and-height.patch: fix CVE-2018-19759
+  * CVE-2018-19761 is not security issue
+  * d/patches/0004-size-check.patch: fix CVE-2018-19762
+  * CVE-2018-19763 is fixed by 0001-Add-malloc-size-check.patch
+  * d/patches/0005-check-error-for-jpeg_read_scanlines.patch: fix CVE-2019-3573
+  * d/patches/0006-check-number-of-repeat_count.patch: fix CVE-2019-3574
+  * d/patches/0007-fix-memory-leak.patch: fix CVE-2018-14072, CVE-2018-14073
+
+ -- NOKUBI Takatsugu   Fri, 06 Sep 2019 16:11:01 +0900
+
 libsixel (1.5.2-2) unstable; urgency=medium
 
   * Disable python.
diff --git a/debian/patches/0001-Add-malloc-size-check.patch b/debian/patches/0001-Add-malloc-size-check.patch
new file mode 100644
index 000..2943ff2
--- /dev/null
+++ b/debian/patches/0001-Add-malloc-size-check.patch
@@ -0,0 +1,25 @@
+From: NOKUBI Takatsugu 
+Date: Wed, 7 Aug 2019 16:23:53 +0900
+Subject: Add malloc size check
+
+---
+ src/allocator.c | 6 ++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/src/allocator.c b/src/allocator.c
+index 216fa34..c33c74b 100644
+--- a/src/allocator.c
 b/src/allocator.c
+@@ -147,6 +147,12 @@ sixel_allocator_malloc(
+ assert(allocator);
+ assert(allocator->fn_malloc);
+ 
++if (n == 0) {
++sixel_helper_set_additional_message(
++"sixel_allocator_malloc: called with n == 0");
++return NULL;
++}
++
+ return allocator->fn_malloc(n);
+ }
+ 
diff --git a/debian/patches/0002-assign-default-error-message.patch b/debian/patches/0002-assign-default-error-message.patch
new file mode 100644
index 000..89f0686
--- /dev/null
+++ b/debian/patches/0002-assign-default-error-message.patch
@@ -0,0 +1,21 @@
+From: NOKUBI Takatsugu 
+Date: Fri, 9 Aug 2019 16:47:29 +0900
+Subject: assign default error message
+
+---
+ src/stb_image.h | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/src/stb_image.h b/src/stb_image.h
+index d0fa9c2..5f8f96d 100644
+--- a/src/stb_image.h
 b/src/stb_image.h
+@@ -875,6 +875,8 @@ static const char *stbi__g_failure_reason;
+ 
+ STBIDEF const char *stbi_failure_reason(void)
+ {
++   if (stbi__g_failure_reason == NULL)
++  stbi__g_failure_reason = "unknwon error, refer error message before assignment";
+return stbi__g_failure_reason;
+ }
+ 
diff --git a/debian/patches/0003-add-limitation-to-width-and-height.patch b/debian/patches/0003-add-limitation-to-width-and-height.patch
new file mode 100644
index 000..6f57a54
--- /dev/null
+++ b/debian/patches/0003-add-limitation-to-width-and-height.patch
@@ -0,0 +1,39 @@
+From: NOKUBI Takatsugu 
+Date: Tue, 20 Aug 2019 15:20:55 +0900
+Subject: add limitation to width and height
+
+---
+ include/sixel.h.in | 3 +++
+ src/decoder.c  | 5 +
+ 2 files changed, 8 insertions(+)
+
+diff --git a/include/sixel.h.in b/include/sixel.h.in
+index 397974f..8552c23 100644
+--- a/include/sixel.h.in
 b/include/sixel.h.in
+@@ -355,6 +355,9 @@ typedef int SIXELSTATUS;
+ #define SIXEL_OPTFLAG_VERSION  ('V')  /* -V, --version: show version and license info */
+ #define SIXEL_OPTFLAG_HELP ('H')  /* -H, --help: show this help */
+ 
++#define SIXEL_WIDTH_LIMIT   100
++#define SIXEL_HEIGHT_LIMIT  100
++
+ #if SIXEL_USE_DEPRECATED_SYMBOLS
+ /* output character size */
+ enum characterSize {
+diff --git a/src/decoder.c b/src/decoder.c
+index 98b5c30..e3fbd0d 100644
+--- a/src/decoder.c
 b/src/decoder.c
+@@ -303,6 +303,11 @@ sixel_decoder_decode(
+ goto end;
+ }
+ 
++if (sx > SIXEL_WIDTH_LIMIT || sy > SIXEL_HEIGHT_LIMIT) {
++status = SIXEL_BAD_INPUT;
++goto end;
++}
++
+ status = sixel_helper_write_image_file(indexed_pixels, sx, sy, palette,
+SIXEL_PIXELFORMAT_PAL8,
+decoder->output,
diff --git a/debian/patches/0004-malloc-size-check.patch b/debian/patches/0004-malloc-size-check.patch
new file mode 100644
index 000..8345c0d
--- /dev/null
+++ b/debian/patches/0004-malloc-size-check.patch
@@ -0,0 +1,21 @@
+From: NOKUBI Takatsugu 
+Date: Thu, 22 Aug 2019 15:30:36 +0900
+Subject: malloc size check
+
+---
+ src/fromsixel.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/fromsixel.c b/sr

Bug#939906: python3-spf-engine: policyd-spf produces Python stack trace on DNS timeout

[Martin Schwenke]

Package: python3-spf-engine
Version: 2.9.0-4
Severity: normal

Dear Maintainer,

When policyd-spf from postfix-policyd-spf-python times out during
a DNS request a Python traceback is printed:

Sep 10 07:11:18 bilbo policyd-spf[21475]:   File "/usr/bin/policyd-spf", line 
11, in #012load_entry_point('spf-engine==2.9.0', 'console_scripts', 
'policyd-spf')()
Sep 10 07:11:18 bilbo policyd-spf[21475]:   File 
"/usr/lib/python3/dist-packages/spf_engine/policyd_spf.py", line 102, in 
main#012peruser, peruserconfigData)
Sep 10 07:11:18 bilbo policyd-spf[21475]:   File 
"/usr/lib/python3/dist-packages/spf_engine/__init__.py", line 545, in 
_spfcheck#012res = heloquery.check()
Sep 10 07:11:18 bilbo policyd-spf[21475]:   File 
"/usr/lib/python3/dist-packages/spf.py", line 591, in check#012spf = 
self.dns_spf(self.d)
Sep 10 07:11:18 bilbo policyd-spf[21475]:   File 
"/usr/lib/python3/dist-packages/spf.py", line 1160, in dns_spf#012a = [t 
for t in self.dns_txt(domain) if RE_SPF.match(t)]
Sep 10 07:11:18 bilbo policyd-spf[21475]:   File 
"/usr/lib/python3/dist-packages/spf.py", line 1210, in dns_txt#012dns_list 
= self.dns(domainname, rr,ignore_void=ignore_void)
Sep 10 07:11:18 bilbo policyd-spf[21475]:   File 
"/usr/lib/python3/dist-packages/spf.py", line 1354, in dns#012for k, v in 
DNSLookup(name, qtype, self.strict, timeout):
Sep 10 07:11:18 bilbo policyd-spf[21475]:   File 
"/usr/lib/python3/dist-packages/spf.py", line 131, in DNSLookup_dnspython#012   
 answers = dns.resolver.query(name, qtype)
Sep 10 07:11:18 bilbo policyd-spf[21475]:   File 
"/usr/lib/python3/dist-packages/dns/resolver.py", line 1102, in query#012
lifetime)
Sep 10 07:11:18 bilbo policyd-spf[21475]:   File 
"/usr/lib/python3/dist-packages/dns/resolver.py", line 992, in query#012
timeout = self._compute_timeout(start, lifetime)
Sep 10 07:11:18 bilbo policyd-spf[21475]:   File 
"/usr/lib/python3/dist-packages/dns/resolver.py", line 799, in 
_compute_timeout#012raise Timeout(timeout=duration)
Sep 10 07:11:18 bilbo policyd-spf[21475]: dns.exception.Timeout: The DNS 
operation timed out after 30.000346899032593 seconds

I would expect a warning to be logged but not a Python traceback.  I am
guessing that spf_engine should be catching the exception.

Perhaps this should be minor instead of normal, but this makes
monitoring logs via logcheck much harder because the stack traces
dominate the logs.

Thanks...

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

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

Versions of packages python3-spf-engine depends on:
ii  python3  3.7.3-1
ii  python3-authres  1.2.0-1
ii  python3-spf  2.0.13-1

python3-spf-engine recommends no packages.

python3-spf-engine suggests no packages.

-- no debconf information

Bug#936856: libfiu: Python2 removal in sid/bullseye

[Alberto Bertogli]

On Mon, Sep 09, 2019 at 11:37:24AM +0100, Chris Lamb wrote:

Hi Alberto:


> It will be included in the next release, which is probably due by now :)

Neat. Can we tempt you into releasing this whilst I have Python 2.x on
my mind?


Just doing some other Python 3.x porting at the moment so thought of
this one; any update on your end?


Sorry for the delay, I was away traveling.

libfiu 1.00 has been released with, amongst other things, this fix.

Let me know how it goes!

Thanks!
Alberto

Bug#935526: pulseaudio: Pulseaudio no longer recognizes USB devices

[Felipe Sateler]

On Fri, Aug 23, 2019 at 10:42 AM Guus Sliepen  wrote:

> Package: pulseaudio
> Version: 12.99.2-1
> Severity: normal
>
> After upgrading to 12.99.2-1, pulseaudio no longer recognizes USB audio
> devices, even though ALSA sees them correctly. It is possible to
> manually add a USB audio device after pulseaudio has started, by running
> "pactl load-module module-alsa-sink device=hw:X", but this is of course
> sub-optimal. Downgrading pulseaudio to version 12.2-4 from Buster fixes
> the issue.
>
> Output of "aplay -l | grep card":
>
> card 0: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0]
> card 0: NVidia [HDA NVidia], device 7: HDMI 1 [HDMI 1]
> card 0: NVidia [HDA NVidia], device 8: HDMI 2 [HDMI 2]
> card 0: NVidia [HDA NVidia], device 9: HDMI 3 [HDMI 3]
> card 1: Generic [HD-Audio Generic], device 0: ALC1220 Analog [ALC1220
> Analog]
> card 1: Generic [HD-Audio Generic], device 1: ALC1220 Digital [ALC1220
> Digital]
> card 2: S7 [SteelSeries Arctis 7], device 0: USB Audio [USB Audio]
> card 2: S7 [SteelSeries Arctis 7], device 1: USB Audio [USB Audio #1]
> card 3: Microphone [Yeti Stereo Microphone], device 0: USB Audio [USB
> Audio]
>
> Output of "pactl list short sinks" with pulseaudio 12.99.2-1:
>
> 0alsa_output.pci-_09_00.1.hdmi-stereo-extra1 module-alsa-card.c
> s16le 2ch 44100HzIDLE
> 1alsa_output.pci-_0b_00.4.analog-stereo module-alsa-card.c
>  s16le 2ch 44100HzIDLE
>
> Output of "pactl list short sinks" with pulseaudio 12.2-4:
>
> 0alsa_output.pci-_09_00.1.hdmi-stereo-extra1 module-alsa-card.c
> s16le 2ch 44100HzIDLE
> 1alsa_output.pci-_0b_00.4.analog-stereo module-alsa-card.c
>  s16le 2ch 44100HzIDLE
> 2alsa_output.usb-SteelSeries_SteelSeries_Arctis_7-00.analog-mono
> module-alsa-card.cs16le 1ch 44100HzIDLE
> 3alsa_output.usb-SteelSeries_SteelSeries_Arctis_7-00.analog-stereo
> module-alsa-card.c  s16le 2ch 44100HzIDLE
>
>
Could you please attach a verbose log of pulseaudio, both versions?
https://wiki.ubuntu.com/PulseAudio/Log
-- 

Saludos,
Felipe Sateler

Bug#939419: libparse-pidl-perl: version ordering issue.

[Peter Green]

tags 939419 +patch
thanks

On 04/09/2019 20:45, Andrew Bartlett wrote:

On Wed, 2019-09-04 at 19:59 +0100, plugwash wrote:

I see two possible fixes.

1. Avoid using version numbers for the samba package that will trigger
this issue.
2. Change the logic that generates the version numbers for the
libparse-pidl-perl package.

3. Drop the package.  It is of very limited interest.  It should have
been dropped once Openchange was removed.  Anybody wishing to build
openchange can just install it from the Samba tarball.

Whether or not that is a reasonable thing to do for future releases of Debian 
it doesn't seem appropriate to me for a stable update.

Anyway the debdiff I used to fix the issue in raspbian can be found at 
https://debdiffs.raspbian.org/main/s/samba/samba_4.9.5+dfsg-5+deb10u1+rpi1.debdiff
 , do with it as you see fit.

Bug#939905: ITP: golang-github-containers-psgo -- ps(1) AIX-format compatible Golang library

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Control: block 930440 by -1

   Package name: golang-github-containers-psgo
Version: 1.3.1
License: Apache-2.0
URL: https://github.com/containers/psgo
Vcs-Browser: 
https://salsa.debian.org/go-team/packages/golang-github-containers-psgo
Description: ps(1) AIX-format compatible Golang library
 Psgo is a ps(1) AIX-format compatible golang library extended with various
 descriptors useful for displaying container-related data.
 .
 The idea behind the library is to provide an easy to use way of extracting
 process-related data, just as ps(1) does. The problem when using ps(1) is
 that the ps format strings split columns with whitespaces, making the
 output nearly impossible to parse. It also adds some jitter as we have to
 fork and execute ps either in the container or filter the output
 afterwards, further limiting applicability.
 .
 This library aims to make things a bit more comfortable, especially for
 container runtimes, as the API allows to join the mount namespace of a
 given process and will parse /proc and /dev/ from there.


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

Bug#939532: RM: slapos.core -- ROM; python2-only; dead upstream; popcon=2; not in stable

[Arnaud Fontaine]

Hi,

> It is already supported  but let me talk with the upstream  to see if it
> still makes sense  to have it in Debian considering  the very low popcon
> and I will get back to you.

After  talking with  the upstream  developers,  it does  not make  sense
anymore to  have this  package in  Debian. Also,  I have  just requested
removal of  python-xmlmarshaller which  was only needed  for slapos.core
(#939902).

Cheers,
-- 
Arnaud Fontaine

Bug#930735: WireGuard: Add resolvconf as optional dependency

[Daniel Kahn Gillmor]

Control: clone 930735 -1
Control: reassign -1 src:systemd
Control: severity -1 wishlist
Control: blocks 930735 with -1
Control: retitle -1 systemd should ship resolvconf symlink in some package
Control: affects -1 + wireguard-tools

Hi Willem--

Thanks for the followup.

It sounds to me like there is still no great suggestion on how to make
this work smoothly, or a clear consensus on what we should do to ensure
that the DNS = directive works for wg-quick :(

On Sat 2019-09-07 08:55:17 +0200, Willem van den Akker wrote:
> If resolvectl is symlinked to resolvconf this also should work. But the
> symlinked is not on my system. Even with resolvectl available.

For most modern debian systems, this seems like the simplest approach,
but i don't think it's safe to assume it will work automatically yet.

Perhaps the systemd source package could ship a systemd-resolvconf
binary package that (a) enables and runs the systemd-resolved service
automatically, and (b) ships the symlink from /sbin/resolvconf to
resolvectl, and (c) Provides: and Conflicts: with resolvconf itself
(similar to how openresolv does).

I note that the systemd binary package already ships a resolvconf
manpage as a symlink to the resolvectl manpage, but it puts it in
section 1 of the manual, instead of section 8, so it doesn't manage to
conflict with resolvconf or openresolv.  that's a little bit weird too :/

I'm cloning this wireguard bug report to the systemd source package to
see whether this suggestion is something they'd be willing to consider.
Debian systemd maintainers -- feel free to suggest an alternate
resolution if you have one you'd prefer.

If systemd would do that, then i'd be willing to add a new control line
for wireguard-tools as something like this:

   Recommends: systemd-resolvconf | resolvconf

Does this seem like a plausible suggestion?  This sort of system
integration across multiple potentially conflicting packages is a bit of
a pain point in Debian, and it's not clear how to make it work sensibly
and easily for everyone.


  --dkg


signature.asc
Description: PGP signature

Bug#939876: gimp: segmentation fault on open

[Witold Baryluk]

Package: gimp
Version: 2.10.8-2+b1
Followup-For: Bug #939876

Dear Maintainer,

I think I do have same issue.

It happens even when creating an empty document using menu File -> New, with any
size (i.e. 1024x768). But also when opening any file (tested with png and jpeg
files).

Stack trace looks similar. Looks like a bug in gimp_gegl_mask_is_empty maybe?

Full debug data from under manually running under gdb:

user@debian:~$ gdb --args gimp --stack-trace-mode=never
GNU gdb (Debian 8.3-1) 8.3
[...snip...]
Reading symbols from gimp...
Reading symbols from 
/usr/lib/debug/.build-id/e6/8d5245284f709dc5d5763e6e1d83036627c2ad.debug...
(gdb) r
Starting program: /usr/bin/gimp --stack-trace-mode=never
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x73ce0700 (LWP 79542)]
[...snip...]
[Thread 0x7fff067fc700 (LWP 79677) exited]
gimp_device_info_set_device: trying to set GdkDevice 'Corsair Corsair Vengeance 
M60 Mouse' on GimpDeviceInfo which already has a device
[Detaching after vfork from child process 79687]
[Detaching after vfork from child process 79692]
[Detaching after vfork from child process 79694]
[New Thread 0x7fff067fc700 (LWP 79703)]
[Thread 0x7fff06ffd700 (LWP 79664) exited]
[New Thread 0x7fff06ffd700 (LWP 79771)]
[Thread 0x7fff06ffd700 (LWP 79771) exited]
[New Thread 0x7fff06ffd700 (LWP 79826)]

Thread 1 "gimp" received signal SIGSEGV, Segmentation fault.
gimp_gegl_mask_is_empty (buffer=) at gimp-gegl-mask.c:151
151 gimp-gegl-mask.c: No such file or directory.
(gdb) bt
#0  0x55a10411 in gimp_gegl_mask_is_empty (buffer=) at 
gimp-gegl-mask.c:151
#1  0x5590b810 in gimp_channel_real_is_empty (channel=0x595f5720 
[GimpSelection]) at gimpchannel.c:1169
#2  0x55982c18 in gimp_layer_invalidate_boundary (drawable=) at gimplayer.c:1442
#3  0x55929b50 in gimp_drawable_real_set_buffer 
(drawable=0x595f5910 [GimpLayer], push_undo=0, undo_desc=0x0, 
buffer=0x5961a5e0 [GeglBuffer], offset_x=0, offset_y=0) at 
gimpdrawable.c:809
#4  0x559832aa in gimp_layer_set_buffer (drawable=0x595f5910 
[GimpLayer], push_undo=0, undo_desc=0x0, buffer=0x5961a5e0 [GeglBuffer], 
offset_x=0, offset_y=0) at gimplayer.c:1494
#5  0x559289bb in gimp_drawable_set_buffer_full 
(drawable=0x595f5910 [GimpLayer], push_undo=0, undo_desc=0x0, 
buffer=0x5961a5e0 [GeglBuffer], offset_x=0, offset_y=0, update=1) at 
gimpdrawable.c:1273
#6  0x55928f9d in gimp_drawable_set_buffer 
(drawable=drawable@entry=0x595f5910 [GimpLayer], 
push_undo=push_undo@entry=0, undo_desc=undo_desc@entry=0x0, 
buffer=buffer@entry=0x5961a5e0 [GeglBuffer]) at gimpdrawable.c:1239
#7  0x55929296 in gimp_drawable_new (type=type@entry=0x561b45e0 
[GimpLayer/GimpDrawable/GimpItem/GimpFilter/GimpViewable/GimpObject], 
image=image@entry=0x55e45a10 [GimpImage], name=name@entry=0x55a655ba 
"Background", offset_x=offset_x@entry=0, offset_y=offset_y@entry=0, 
width=width@entry=1920, height=1080, format=0x55d06190) at 
gimpdrawable.c:953
#8  0x559864d0 in gimp_layer_new (image=image@entry=0x55e45a10 
[GimpImage], width=width@entry=1920, height=height@entry=1080, 
format=0x55d06190, name=name@entry=0x55a655ba "Background", 
opacity=opacity@entry=1, mode=mode@entry=GIMP_LAYER_MODE_NORMAL) at 
gimplayer-new.c:65
#9  0x559659c1 in gimp_image_new_from_template 
(gimp=gimp@entry=0x55e240c0 [Gimp], template=template@entry=0x5930bda0 
[GimpTemplate], context=0x55e73310 [GimpContext]) at gimpimage-new.c:148
#10 0x5566acc3 in image_new_create_image (private=0x59478590) at 
image-new-dialog.c:368
#14 0x7717db6f in  (instance=, signal_id=, 
detail=) at ../../../gobject/gsignal.c:3447
#11 0x77160e8d in g_closure_invoke (closure=0x58e66020, 
return_value=0x0, n_param_values=2, param_values=0x7fffcc30, 
invocation_hint=0x7fffcbb0) at ../../../gobject/gclosure.c:810
#12 0x77174555 in signal_emit_unlocked_R 
(node=node@entry=0x5902d130, detail=detail@entry=0, 
instance=instance@entry=0x5868cbb0, 
emission_return=emission_return@entry=0x0, 
instance_and_params=instance_and_params@entry=0x7fffcc30) at 
../../../gobject/gsignal.c:3635
#13 0x7717d4ae in g_signal_emit_valist (instance=, 
signal_id=, detail=, 
var_args=var_args@entry=0x7fffce00) at ../../../gobject/gsignal.c:3391
#18 0x7717db6f in  (instance=, signal_id=, 
detail=) at ../../../gobject/gsignal.c:3447
#15 0x77160e8d in g_closure_invoke (closure=0x58e67310, 
return_value=0x0, n_param_values=1, param_values=0x7fffd0a0, 
invocation_hint=0x7fffd020) at ../../../gobject/gclosure.c:810
#16 0x77174555 in signal_emit_unlocked_R 
(node=node@entry=0x58543400, detail=detail@entry=0, 
instance=instance@entry=0x594692a0, 
emission_return=emission_return@entry=0x0, 
instance_and

Bug#939903: openvpn: systemd does not start openvpn after upgrade from stretch tu buster

[Mikolaj Menke]

Package: openvpn
Version: 2.4.7-1
Severity: normal

Dear Maintainer,

I am running openvpn in a Linux container. I have upgraded openvpn from stretch 
to buster version. I have tried to start openvpn with "systemctl start 
openvpn". The error in the syslog is:

Sep 10 00:31:17 vpn systemd[1]: Starting OpenVPN connection to server...
Sep 10 00:31:17 vpn systemd[3766]: openvpn@server.service: Failed to set up 
mount namespacing: Permission denied
Sep 10 00:31:17 vpn systemd[3766]: openvpn@server.service: Failed at step 
NAMESPACE spawning /usr/sbin/openvpn: Permission denied
Sep 10 00:31:17 vpn systemd[1]: openvpn@server.service: Main process exited, 
code=exited, status=226/NAMESPACE
Sep 10 00:31:17 vpn systemd[1]: openvpn@server.service: Failed with result 
'exit-code'.
Sep 10 00:31:17 vpn systemd[1]: Failed to start OpenVPN connection to server.

I would expect openvpn to start normally without errors.

I have tried to add the following lines to the systemd unit, but it has not 
helped:

PrivateTmp=false
NoNewPrivileges=yes

I have tried to manually run openvpn with these commands:

/usr/sbin/openvpn --daemon ovpn-server --status /run/openvpn/server.status 10 
--cd /etc/openvpn --config /etc/openvpn/server.conf --writepid 
/run/openvpn/server.pid
openvpn --config /etc/openvpn/server.conf

Both commands were successful.

Regards,
Mikolaj Menke

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

Kernel: Linux 4.15.18-16-pve (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), 
LANGUAGE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages openvpn depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  iproute2   4.20.0-2
ii  libc6  2.28-10
ii  liblz4-1   1.8.3-1
ii  liblzo2-2  2.10-0.1
ii  libpam0g   1.3.1-5
ii  libpkcs11-helper1  1.25.1-1
ii  libssl1.1  1.1.1c-1
ii  libsystemd0241-7~deb10u1
ii  lsb-base   10.2019051400

Versions of packages openvpn recommends:
ii  easy-rsa  3.0.6-1

Versions of packages openvpn suggests:
ii  openssl   1.1.1c-1
pn  openvpn-systemd-resolved  
pn  resolvconf

-- debconf information:
  openvpn/create_tun: false

Bug#932817: Quote needed

[Jerry Edwards]

Good day,
 Can you please assist me with quote for the below product.
 Lenovo Yoga C930 14" Intel� Core!22 i7-8550U (1.80GHz, up to 4.0GHz, Win 
10,16GB DDR4 2400MHz,1TB SSD,UHD Graphics 620.
 Thank you for your assistance.
 Jerry Edwards
JC Window Fashions
6400 Fleet Street
Commerce, CA 90040
f...@jcwindowfashions.com
Ph 909 359 2526

Bug#939902: RM: xmlmarshaller -- ROM; removal triggered by the Python2 removal; popcon=26

[Arnaud Fontaine]

Package: ftp.debian.org
Severity: normal

Hi,

As slapos.core has been removed from unstable (#939532) and it was the
only package depending on xmlmarshaller and considering its very low
popcon, I think it is better to remove it from the archive even though
it supports python3.

Cheers,
Arnaud Fontaine

Bug#921017: wireguard: doesn't always set all allowed-ips

[Daniel Kahn Gillmor]

Control: retitle 921017 wireguard: wg setconf doesn't always set all allowed-ips
Control: reassign 921017 wireguard-tools

Hi Piotr--

On Mon 2019-09-09 12:40:30 +0200, Piotr Ożarowski wrote:
> yes, I can still replicate it with 0.0.20190905-1 but I do it on stable
> (first Stretch now Buster) with packages from unstable (without
> rebuilding them). Every time different peer (I have 11 of them) gets a
> non complete AllowedIPs so I admit it's hard to reproduce…

Thanks for testing again so promptly, and sorry for the delay on my
side.

This is a delicate situation because i want to try to reproduce the
problem you're seeing but i don't want to leak any secret information
from your system (or any of your peers' public metadata either, unless
you're ok with that).

If i can try to restate the problem, it sounds like "wg setconf" is not
reliably setting all the allowed-ips from a complex configuration file.

But "wg set" itself always works fine to adjust it, right?  That makes
it sound like a problem with the "wg setconf" subcommand itself.

So can you help me figure out how i can replicate the problem without
leaking your secret information?  For example, can you supply a
templated configuration file that fails sometimes (but with relevant
secrets and sensitive public metadata redacted)?  For example, is this
something you can replicate intermittently by running the configuration
steps in a tight loop, and testing for the failure after each time?

I've tried to do that briefly with some simple tests, but i still can't
seem to get it to happen, even from a debian buster installation (with
wireguard-dkms and wireguard-tools installed from unstable directly).

> PS I have another problem that I didn't report yet on one (and only one)
>of my peers which I don't think is related, but in case it is:
>from time to time (sometimes few days apart sometimes weeks)
>wireguard freezes (as in it doesn't accept any in/out connections).
>Restarting (ip l set dev wg0 down and up again) doesn't help. What
>helps is to change listening port to something else. This peer has a
>non-public and dynamic IP (but I have another client using the same
>provider on my OpenWRT router and it seems to work fine there)

hm, this is likely to be a different thing, so if you want to discuss
it, please open it as a separate ticket.

--dkg


signature.asc
Description: PGP signature

Bug#939901: Upstream has released 1.3.0

[Michael Evans]

Package: mumble
Version: 1.3.0~git20190125.440b173+dfsg-2

Upstream has released 1.3.0
https://www.mumble.info/blog/mumble-1.3.0-release-announcement/

Bug#933440:

[Olly Betts]

On Sat, Aug 03, 2019 at 10:31:10PM +0100, Olly Betts wrote:
> On Fri, Aug 02, 2019 at 06:50:16PM +0200, Filip Hroch wrote:
> > The crash can be encountered during startup, when a FITS file [1] 
> > is passed as an argument. This is the second regular way for the
> > launch: users can pass the file, or double click in a graphical 
> > file manager:
> 
> I can't seem to reproduce this - I get a window appearing with a
> plausible looking image and histogram.  Output to the terminal is:
> 
> $ xmunipack --verbose munipack-data-m27/m27_01R.fits
> Debug: MuniView::HduSelect 0
> Debug: MuniDisplayCanvas constructor..
> Debug: Median=2938.00 MAD=29.01 Black=2912.00 Qlight=902.301575 
> n=5968
> 
> Debug: Median=2938.00 MAD=29.01 Black=2912.00 Qlight=902.301575 
> n=5968
> 
> Debug: hist: 2856.00 3373.00 32 16.156250 2940.00 32768
> Debug: stat: 33.00 2937.00 17696 2860.00 11
> Debug: MuniDisplayCanvas::OnRenderFinish 1 
> Debug: MuniDisplayCanvas::OnRenderFinish 0 
> Debug: MuniDisplayCanvas::StopRendering()
> 
> > * The uncertainty is also confirmed by Valgrind.
> 
> If I run under valgrind no problems are reported.
> 
> > I used a development branch, which is configured as
> 
> I just adjusted "Build-Depends:" of the package currently in unstable
> and rebuilt.  Perhaps the problem is specific to the development branch?
> 
> I've attached the debdiff for the package I built.

Looks like I failed to actually attach that debdiff - here it is.

While getting the development branch to work with GTK3 is obviously
desirable for the longer term, for the purposes of this transition what
matters is the currently packaged version, and as I said above that
doesn't seem to exhibit the problem you're hitting with the development
version.

Cheers,
Olly
diff -Nru munipack-0.5.11/debian/changelog munipack-0.5.11/debian/changelog
--- munipack-0.5.11/debian/changelog2019-01-28 07:45:05.0 +1300
+++ munipack-0.5.11/debian/changelog2019-08-01 13:27:39.0 +1200
@@ -1,3 +1,10 @@
+munipack (0.5.11-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build against GTK+3 flavour of wxWidgets (Closes: #933440)
+
+ -- Olly Betts   Thu, 01 Aug 2019 13:27:39 +1200
+
 munipack (0.5.11-2) unstable; urgency=medium
 
   * Bugfix: ftbfs with ld --as-needed, thx to M. Klose. (Closes: #920426)
diff -Nru munipack-0.5.11/debian/control munipack-0.5.11/debian/control
--- munipack-0.5.11/debian/control  2019-01-25 06:05:50.0 +1300
+++ munipack-0.5.11/debian/control  2019-08-01 13:25:52.0 +1200
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Debian Astronomy Team 

 Uploaders: Filip Hroch 
-Build-Depends: debhelper (>= 11), gfortran, g++ (>= 6), libcfitsio-dev, 
libwxgtk3.0-dev, minpack-dev, liboakleaf-dev
+Build-Depends: debhelper (>= 11), gfortran, g++ (>= 6), libcfitsio-dev, 
libwxgtk3.0-gtk3-dev, minpack-dev, liboakleaf-dev
 Standards-Version: 4.3.0
 Homepage: http://munipack.physics.muni.cz/
 Vcs-Browser: https://salsa.debian.org/debian-astro-team/munipack

Bug#939900: RFS: sosreport/3.8-1 -- Set of tools to gather troubleshooting data from a system

[Eric Desrochers]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: sosreport
   Version : 3.8-1
   Upstream Author : Bryn M. Reeves 
 * URL : https://github.com/sosreport/sos
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/sosreport-team/sosreport
   Section : admin

It builds those binary packages:

  sosreport - Set of tools to gather troubleshooting data from a system

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/sosreport/sosreport_3.8-1.dsc

Changes since the last upload:

   * New 3.8 upstream release.
 Contains a number of enhancements, new features and bug fixes including:
 - 6 new plugins: container_log, frr, leapp, openstack_placement, qt, vdsm
 - kubernetes plugin can now optionally grab logs only for certain pods
 - kdump plugin will now collect initramfs content
 - pulp and foreman plugins now support collecting from an external database
 - sar plugin will now collect the full sar log dir
 - vdsm and ovirt plugins will now collect host certificates
 - openvswitch plugin will now enable on openvswitch2.* packages
 - Added support for only capturing logs after a specific date, --since
   option
 - Fixed an issue causing high CPU utilization which slowed journal
   collection
 - Fixed an issue where plugins could continue executing commands after
   their timeout was hit
 - sosreport will no longer abort execution on Red Hat family systems when
   the package manager fails to query a file list
 .
   * Plugin API enhancements
 - Plugins may now capture environment variables, which will be written to
   /environment in the sos archive root
 - Plugins may now write command output to subdirs within their own
   sos_commands/plugin directory
   - The container plugins have been updated to make use of this
 functionality
 - SoSPredicate usage may now be match either any or all of the provided
   elements, and may mix requirements of kmods and services to determine
   if a command should be collected.
 .
   * Significant changes to the reporting system of sos
 - HTML reports replaced by a Report subclass
 - HTML report creation time is significantly improved
 - Added a JSON formatted report option
 .
   * Allow system changes option
 - A new --allow-system-changes option has been added that will allow users
   to collect certain data, even if it means the host system would be
   changed.
 .
   * Former patches now fixed upstream:
 - d/p/0001-skip-py2-only-tests.patch
 - d/p/archive-fix-stat-typo.patch
 - d/p/avoid-distutils.diff

Regards,

--
  Eric Desrochers

Bug#691407: closed by Christian Göttsche (Re: logrotate(8) does not mention all reasons for ignoring included files)

[Roger Lynn]

On 08/09/19 16:48, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the logrotate package:

#691407: logrotate(8) does not mention all reasons for ignoring included files

It has been closed by Christian Göttsche .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Christian Göttsche 
 by
replying to this email.


Subject:
Re: logrotate(8) does not mention all reasons for ignoring included files
From:
Christian Göttsche 
Date:
08/09/19 17:45 +0200
To:
691407-d...@bugs.debian.org

To:
691407-d...@bugs.debian.org


Closing due to no response.


No response due to not being copied on the email in question!


In the BTS, I see that on Wed, 22 Aug 2018 22:54:02 +0200, Christian 
Göttsche  apparently wrote:

Control: tags -1 moreinfo unreproducible

Hi,
by


some unspecified "bad" file modes, which include being group writeable.


do you mean configuration files or log files?
In my tests logrotate does rotate logs which are group writeable and
errors out when a configuration file has insecure permissions.


I don't remember filing this bug seven years ago, but the section of the man 
page quoted in the original report was clearly referring to configuration 
files. You have reproduced the error, which was a result of a requirement 
which I could not find in the the man page. If this bug is unreproducible, 
does that mean you were able to find where in the man page this is documented?


Having left cron to run overnight with an erroneous logrotate.d file I see 
that an error is now reported without needing to resort to adding "-v" to 
various scripts:
"error: Ignoring vsftpd because of bad file mode - must be 0644 or 0444." 
and it now states what the file mode requirements are, which it did not 
before. As a result it would probably be reasonable to downgrade this bug to 
minor severity.


Previously no error was reported when the script was run by cron, when "-v" 
was added to logrotate the error message given did not state what was wrong 
with the file mode and this requirement is not mentioned in the man page. 
This made it difficult to work out why logrotate was not working.


Regards,

Roger

Bug#939899: apitrace_7.1+git20170623.d38a69d6+repack-3+b4_mipsel.changes REJECTED

[Aurelien Jarno]

Package: apitrace-tracers
Version: 7.1+git20170623.d38a69d6+repack-3
Severity: serious

On 2019-09-09 21:19, Debian FTP Masters wrote:
> apitrace-tracers_7.1+git20170623.d38a69d6+repack-3+b4_mipsel.deb: Built-Using 
> refers to non-existing source package snappy (= 1.1.7-1+b1)
> 
> 
> Mapping sid to unstable.
> 
> ===
> 
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
> 

The Built-Using field should use the source version, not the binary one.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#939898: glibc: setuid/getuid broken on alpha with 2.29-1

[Aurelien Jarno]

On 2019-09-09 22:49, John Paul Adrian Glaubitz wrote:
> Source: glibc
> Version: 2.29-1
> Severity: important
> User: debian-al...@lists.debian.org
> Usertags: alpha
> 
> Hello!
> 
> Both on my Alpha XP-1000 as well as inside a qemu-user chroot, upgrading glibc
> to version 2.29-1 resulted in setuid/getuid breaking in a weird way:

As a side note, I have successfully upgrade a qemu-system-alpha based
machine without issue. It actually fixes long standing issues with
systemd. The VM runs kernel 5.2.0-2-alpha-smp.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#939890: buster-pu: package rpcbind/1.2.5-0.3+deb10u1

[Josue Ortega]

On 2019-09-09 13:45, Adam D. Barratt wrote:
> Control: tags -1 + moreinfo
> 
> On Mon, 2019-09-09 at 13:28 -0600, Josue Ortega wrote:
>> I'd like to update rpcbind in Buster to fix the response to broadcast
>> requests.
>> Currently the broadcast requests are broken in Buster causing
>> problems to users
>> using NIS services. See #939877 and #935492 for more information.
> 
> The metadata for #939877 indicates that it affects the package in
> unstable, and is not fixed there. Is that correct? If so, please fix
> the package in unstable first; if not, please add an appropriate fixed
> version so that the BTS knows what's going on.
> 
> Regards,
> 
> Adam

Sorry about that.

The issue is fixed in unstable now

Thanks,

Josue

Bug#939898: glibc: setuid/getuid broken on alpha with 2.29-1

[John Paul Adrian Glaubitz]

Hi!

On 9/9/19 10:49 PM, John Paul Adrian Glaubitz wrote:

Both on my Alpha XP-1000 as well as inside a qemu-user chroot, upgrading glibc
to version 2.29-1 resulted in setuid/getuid breaking in a weird way:


To reproduce, one can simply run debootstrap with qemu-user-static installed and
enter the chroot:

root@epyc:/local_scratch> debootstrap --no-check-gpg --arch=alpha --foreign 
--variant=minbase unstable sid-alpha-sbuild 
http://ftp.ports.debian.org/debian-ports
(...)
root@epyc:/local_scratch> chroot sid-alpha-sbuild
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
I have no name!@epyc:/local_scratch> ./debootstrap/debootstrap --second-stage
E: debootstrap can only run as root
I have no name!@epyc:/local_scratch>

I assume this would also work on qemu-system-alpha although I haven't tried
yet. But it should work the same way but without the "--foreign" argument.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#939754: gimp: crashing

[mm]

Package: gimp
Version: 2.10.8-2+b1
Followup-For: Bug #939754

Dear Maintainer, GIMP crashing, this is the situation here:

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.2.0-2-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 /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gimp depends on:
ii  gimp-data2.10.8-2
ii  libaa1   1.4p5-46+b1
ii  libbabl-0.1-00.1.62-1
ii  libbz2-1.0   1.0.6-9.2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libfontconfig1   2.13.1-2+b1
ii  libfreetype6 2.9.1-4
ii  libgcc1  1:9.2.1-4
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libgegl-0.4-00.4.12-2
ii  libgexiv2-2  0.10.9-1
ii  libgimp2.0   2.10.8-2+b1
ii  libglib2.0-0 2.60.6-2
ii  libgs9   9.27~dfsg-3.1
ii  libgtk2.0-0  2.24.32-3
ii  libgudev-1.0-0   232-2
ii  libharfbuzz0b2.6.1-2
ii  libheif1 1.5.1-1
ii  libilmbase24 2.3.0-6
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-3+b1
ii  liblzma5 5.2.4-1+b1
ii  libmng1  1.0.10+dfsg-3.1+b5
ii  libmypaint-1.3-0 1.3.0-2.1+b1
ii  libopenexr24 2.3.0-6
ii  libopenjp2-7 2.3.0-2
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libpangoft2-1.0-01.42.4-7
ii  libpng16-16  1.6.37-1
ii  libpoppler-glib8 0.71.0-5+b1
ii  librsvg2-2   2.44.14-1
ii  libstdc++6   9.2.1-4
ii  libtiff5 4.0.10+git190818-1
ii  libwebp6 0.6.1-2+b1
ii  libwebpdemux20.6.1-2+b1
ii  libwebpmux3  0.6.1-2+b1
ii  libwmf0.2-7  0.2.8.4-14
ii  libx11-6 2:1.6.7-1
ii  libxcursor1  1:1.2.0-2
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxmu6  2:1.1.2-2+b3
ii  libxpm4  1:3.5.12-1
ii  xdg-utils1.1.3-1
ii  zlib1g   1:1.2.11.dfsg-1+b1

Versions of packages gimp recommends:
ii  ghostscript  9.27~dfsg-3.1

Versions of packages gimp suggests:
pn  gimp-data-extras  
pn  gimp-help-en | gimp-help  
pn  gimp-python   
ii  gvfs-backends 1.38.1-5
ii  libasound21.1.8-1

-- no debconf information



```
GNU Image Manipulation Program version 2.10.8
git-describe: GIMP_2_10_6-294-ga967e8d2c2
C compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 9.2.1-6' 
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-9 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib 
--with-target-system-zlib=auto --enable-multiarch --disable-werror 
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 
--enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none,hsa 
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.2.1 20190827 (Debian 9.2.1-6) 

using GEGL version 0.4.12 (compiled against version 0.4.14)
using GLib version 2.60.6 (compiled against version 2.60.6)
using GdkPixbuf version 2.38.1 (compiled against version 2.38.1)
using GTK+ version 2.24.32 (compiled against version 2.24.32)
using Pango version 1.42.3 (compiled against version 1.42.3)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)

```
> fatal error: Errore di segmentazione

Stack trace:
```
/lib/libgimpbase-2.0.so.0(gimp_stack_trace_print+0x398)[0x7efddc584f98]
gimp-2.10(+0xd1590)[0x560dfe196590]
gimp-2.10(+0xd19b8)[0x560dfe1969b8]
gimp-2.10(+0xd2029)[0x560dfe197029]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12730)[0x7efddba7d730]
gimp-2.10(gimp_gegl_mask_is_empty+0x91)[0x560dfe581411]
gimp-2.10(+0x3b7810)[0x560dfe47c810]
gimp-2.10(+0x42ec18)[0x560dfe4f3c18]
gimp-2.10(+0x3d5b50)[0x560dfe49ab50]
gimp-2.10(+0x42f2aa)[0x560dfe4f42aa]
gimp-2.10(gimp_drawable_set_buffer_full+0x1cb)[0x560dfe4999bb]
gimp-2.10(gimp_drawable_set_bu

Bug#939472: Further fixes?

[Sylvestre Ledru]

Le 09/09/2019 à 18:57, Hillel Lubman a écrit :

Falling back to gcc 8 is a workaround for this, but what is the
required fix for gcc 9 and further going forward?

If I had one, I would have used it. ;)

If you would like to help, here is the current summary
http://lists.llvm.org/pipermail/llvm-dev/2019-September/134993.html

Cheers,
Sylvestre

Bug#939896: Two-finger touchpad scroll is broken in wxgtk3.0-gtk3 on wayland

[Olly Betts]

On Mon, Sep 09, 2019 at 10:04:26PM +0200, Gunter Königsmann wrote:
> Also wxgtk3.0 applications that use gtk2 seem to work fine.

That's not surprising - GTK2 doesn't support Wayland, so GTK2 apps
will actually use X11 even if you're using Wayland.

With GTK3 you can probably work around this by forcing X11, e.g.:

env GDK_BACKEND=x11 /usr/bin/app

Cheers,
Olly

Bug#939825: Upstream bug

[Lisandro Damián Nicanor Pérez Meyer]

tag 939825 upstream
forwarded 939825 https://bugreports.qt.io/browse/QTCREATORBUG-22923
thanks

OK, this seems to be an upstream issue, so I pushed the bug to upstream's BTS.

Bug#939898: glibc: setuid/getuid broken on alpha with 2.29-1

[John Paul Adrian Glaubitz]

Source: glibc
Version: 2.29-1
Severity: important
User: debian-al...@lists.debian.org
Usertags: alpha

Hello!

Both on my Alpha XP-1000 as well as inside a qemu-user chroot, upgrading glibc
to version 2.29-1 resulted in setuid/getuid breaking in a weird way:

(sid-alpha-sbuild)root@epyc:/# apt -y upgrade  
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
  bsd-mailx cron exim4-base exim4-config exim4-daemon-light groff-base 
libevent-2.1-6 libgnutls-dane0 liblockfile-bin liblockfile1 libpipeline1 
libreadline7 libtext-iconv-perl
  libuchardet0 libunbound8 man-db psmisc
Use 'apt autoremove' to remove them.
The following packages will be upgraded:
  cpp g++ gcc libc-bin libc-dev-bin libc6.1 libc6.1-dev
7 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 6329 kB/6355 kB of archives.
After this operation, 34.8 kB disk space will be freed.
Get:1 http://incoming.ports.debian.org/buildd unstable/main alpha libc6.1-dev 
alpha 2.29-1 [2586 kB]
Get:2 http://incoming.ports.debian.org/buildd unstable/main alpha libc-dev-bin 
alpha 2.29-1 [277 kB]
Get:3 http://incoming.ports.debian.org/buildd unstable/main alpha libc6.1 alpha 
2.29-1 [2677 kB]
Get:4 http://incoming.ports.debian.org/buildd unstable/main alpha libc-bin 
alpha 2.29-1 [788 kB]
Fetched 6329 kB in 3s (2509 kB/s) 
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = "en_US.UTF-8",
LC_CTYPE = "en_US.UTF-8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
/usr/bin/locale: Cannot set LC_CTYPE to default locale: No such file or 
directory
/usr/bin/locale: Cannot set LC_MESSAGES to default locale: No such file or 
directory
/usr/bin/locale: Cannot set LC_ALL to default locale: No such file or directory
debconf: delaying package configuration, since apt-utils is not installed
E: Can not write log (Is /dev/pts mounted?) - posix_openpt (19: No such device)
(Reading database ... 13696 files and directories currently installed.)
Preparing to unpack .../libc6.1-dev_2.29-1_alpha.deb ...
Unpacking libc6.1-dev:alpha (2.29-1) over (2.28-4) ...
Preparing to unpack .../libc-dev-bin_2.29-1_alpha.deb ...
Unpacking libc-dev-bin (2.29-1) over (2.28-4) ...
Preparing to unpack .../libc6.1_2.29-1_alpha.deb ...
debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed, so the dialog based 
frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 
76.)
debconf: falling back to frontend: Readline
Unpacking libc6.1:alpha (2.29-1) over (2.28-4) ...
dpkg: error: requested operation requires superuser privilege
E: Sub-process /usr/bin/dpkg returned an error code (2)
(sid-alpha-sbuild)root@epyc:/#

After that, logging in through SSH no longer works. Running "dpkg --configure 
-a" always
results in the same error as shown above. Logging in through serial console 
aborts
immediately after typing the username, e.g. "root" and the login prompt is 
shown again.

Shortly after typing "root" and pressing enter, the following message is 
printed to the
console which seems to be an alpha-specific syscall:

[  195.414939] do_entUnaUser: 7 callbacks suppressed

I can fix the problem with the chroot, by simply downloading the 2.28-4 version 
of the
libc6.1 package and extracting it into the system root:

root@epyc:/local_scratch/sid-alpha-sbuild> wget 
http://snapshot.debian.org/archive/debian-ports/20190111T160151Z/pool-alpha/main/g/glibc/libc6.1_2.28-4_alpha.deb
--2019-09-09 22:55:02--  
http://snapshot.debian.org/archive/debian-ports/20190111T160151Z/pool-alpha/main/g/glibc/libc6.1_2.28-4_alpha.deb
Resolving snapshot.debian.org (snapshot.debian.org)... 193.62.202.27, 
185.17.185.185, 2001:630:206:4000:1a1a:0:c13e:ca1b, ...
Connecting to snapshot.debian.org (snapshot.debian.org)|193.62.202.27|:80... 
connected.
HTTP request sent, awaiting response... 200 OK
Length: 2728400 (2.6M)
Saving to: ‘libc6.1_2.28-4_alpha.deb’

libc6.1_2.28-4_alpha.deb 
100%[>]
   2.60M  12.4MB/sin 0.2s

2019-09-09 22:55:02 (12.4 MB/s) - ‘libc6.1_2.28-4_alpha.deb’ saved 
[2728400/2728400]

root@epyc:/local_scratch/sid-alpha-sbuild> dpkg-deb -x libc6.1_2.28-4_alpha.deb 
.
root@epyc:/local_scratch/sid-alpha-sbuild> chroot .
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
(sid-alpha-sbuild)root@epyc:/#

I will follow up with more information once I have figured out more.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-   

Bug#939897: stretch-pu: package node-mixin-deep/1.1.3-1+deb9u1

[Xavier Guimard]

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

Hi,

since stretch and buster have the same node-mixin-deep, I added here the
same security patches than pushed in buster.

Cheers,
Xavier
diff --git a/debian/changelog b/debian/changelog
index 2e47d2e..dca07c9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+node-mixin-deep (1.1.3-1+deb9u1) stretch; urgency=medium
+
+  * Team upload
+  * Fix prototype polution (Closes: #898315, CVE-2018-3719)
+  * Fix prototype pollution (Closes: #932500, CVE-2019-10746)
+
+ -- Xavier Guimard   Mon, 09 Sep 2019 22:16:03 +0200
+
 node-mixin-deep (1.1.3-1) unstable; urgency=low
 
   * Initial release (Closes: #842329)
diff --git a/debian/patches/CVE-2018-3719.diff 
b/debian/patches/CVE-2018-3719.diff
new file mode 100644
index 000..868f5bb
--- /dev/null
+++ b/debian/patches/CVE-2018-3719.diff
@@ -0,0 +1,22 @@
+Description: Fix prototype pollution (CVE-2018-3719)
+Author: Jon Schlinkert 
+Origin: upstream, 
https://github.com/jonschlinkert/mixin-deep/commit/578b0bc5e74e14de9ef4975f504dc698796bdf9c
+Bug: https://www.npmjs.com/advisories/578
+Bug-Debian: https://bugs.debian.org/898315
+Forwarded: not-needed
+Reviewed-By: Xavier Guimard 
+Last-Update: 2019-04-21
+
+--- a/index.js
 b/index.js
+@@ -23,6 +23,10 @@
+  */
+ 
+ function copy(val, key) {
++  if (key === '__proto__') {
++return;
++  }
++
+   var obj = this[key];
+   if (isObject(val) && isObject(obj)) {
+ mixinDeep(obj, val);
diff --git a/debian/patches/CVE-2019-10746.diff 
b/debian/patches/CVE-2019-10746.diff
new file mode 100644
index 000..cc4b58a
--- /dev/null
+++ b/debian/patches/CVE-2019-10746.diff
@@ -0,0 +1,41 @@
+Description: Fix for CVE-2019-10746 (prototype pollution)
+Author: Jon Schlinkert (https://github.com/jonschlinkert)
+Origin: upstream, https://github.com/jonschlinkert/mixin-deep/commit/90ee1fab
+Bug: https://snyk.io/vuln/SNYK-JS-MIXINDEEP-450212
+Bug-Debian: https://bugs.debian.org/932500
+Forwarded: not-needed
+Reviewed-By: Xavier Guimard 
+Last-Update: 2019-07-20
+
+--- a/index.js
 b/index.js
+@@ -23,10 +23,9 @@
+  */
+ 
+ function copy(val, key) {
+-  if (key === '__proto__') {
++  if (!isValidKey(key)) {
+ return;
+   }
+-
+   var obj = this[key];
+   if (isObject(val) && isObject(obj)) {
+ mixinDeep(obj, val);
+@@ -47,6 +46,17 @@
+ }
+ 
+ /**
++ * Returns true if `key` is a valid key to use when extending objects.
++ *
++ * @param  {String} `key`
++ * @return {Boolean}
++ */
++
++function isValidKey(key) {
++  return key !== '__proto__' && key !== 'constructor' && key !== 'prototype';
++};
++
++/**
+  * Expose `mixinDeep`
+  */
+ 
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..da1c174
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1,2 @@
+CVE-2018-3719.diff
+CVE-2019-10746.diff

Bug#939896: Two-finger touchpad scroll is broken in wxgtk3.0-gtk3 on wayland

[Scott Talbert]

On Mon, 9 Sep 2019, Gunter Königsmann wrote:


Package: libwxgtk3.0-gtk3-0v5
Version: 3.0.4+dfsg-9
Wayland only (X11 works fine): Attempts to do a two-finger scroll using
my synaptic touchpad don't cause applications that use the gtk3 flavour
of wxgtk to scroll. The two-finger scroll seems to be ignored instead.
Ordinary gnome applications seem to work fine, instead. Also wxgtk3.0
applications that use gtk2 seem to work fine.


Upstream ticket: https://trac.wxwidgets.org/ticket/17734

Bug#700472: Upgrade of the foreign arch libc6 causes service restart

[Sven Joachim]

Control: tags -1 + patch

On 2013-02-13 06:20 +0600, Andrey Rahmatullin wrote:

> Package: libc6
> Version: 2.17-0experimental2
> Severity: wishlist
>
> Filing as wishlist, maybe it's minor or even worse for some people.
>
> The postinst script of libc6 checks services that need to be restarted not
> taking into account that those services may be of a different arch and so not
> using the libc6 being upgraded. That also means when you upgrade both
> libc6:amd64 and libc6:i386 you get double restart of all those services.

Today, upgrading libc6:amd64 and libc6:i386 to 2.29-1, I got annoyed by
this again and had a look what needs to be done.  The attached patch
(lightly tested, I have only a few amd64 and no i386 services running)
appears to do the trick.  It also drops the need for awk in the
maintainer scripts.

Feedback and brave testers welcome!

Cheers,
   Sven

From 8d3ef80d688b71503dc369b68bf0323349e9fbda Mon Sep 17 00:00:00 2001
From: Sven Joachim 
Date: Mon, 9 Sep 2019 13:46:28 +0200
Subject: [PATCH 1/1] Do not restart services of different architecture than
 libc

Only check services in packages which are of the same architecture, or
"arch:all".  This is most easily done by replacing the rather
convoluted way of parsing "dpkg --status" output by switching to a
more suitable output format of dpkg-query.  As a bonus, awk is no
longer used in the maintscripts.

Note that services in architecture-independent packages like
postgresql-common will still be restarted twice, since there is no
obvious way to tell the architecture of the actual binaries which need
to be re-executed.
---
 debian/script.in/nsscheck.sh | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/debian/script.in/nsscheck.sh b/debian/script.in/nsscheck.sh
index 80dfd2fb..623278c0 100644
--- a/debian/script.in/nsscheck.sh
+++ b/debian/script.in/nsscheck.sh
@@ -1,6 +1,8 @@
 	echo -n "Checking for services that may need to be restarted..."
-	# Only get the ones that are installed, and configured
-	check=$(dpkg -s $check 2> /dev/null | egrep '^Package:|^Status:' | awk '{if ($1 ~ /^Package:/) { package=$2 } else if ($0 ~ /^Status: .* installed$/) { print package }}')
+	# Only get the ones that are installed, of the same architecture
+	# as libc (or arch all) and configured
+	check=$(dpkg-query -W -f='${binary:Package} ${Status} ${Architecture}\n' $check 2> /dev/null | \
+			grep -E "installed (all|${DPKG_MAINTSCRIPT_ARCH})$" | sed 's/[: ].*//')
 	# some init scripts don't match the package names
 	check=$(echo $check | \
 		sed -e's/\bapache2.2-common\b/apache2/g' \
--
2.23.0

Bug#939825: qtcreator: clang-format plugin broken

[Adam Majer]

On 2019-09-09 8:39 p.m., Lisandro Damián Nicanor Pérez Meyer wrote:
> The error code comes from
> src/plugins/clangformat/clangformatplugin.cpp::157. Looking at the
> code it means that KEEP_LINE_BREAKS_FOR_NON_EMPTY_LINES_BACKPORTED is
> not defined, but I do not know where that should be defined.
> 

Looks like this functionality has not even been approved for unreleased 
upstream clang

https://reviews.llvm.org/D53072

So I think the problem is that QtCreator authors only chose to make the 
ClangFormat plugin
functional with a custom-patched clang version and it's hardcoded to fail in 
all other cases.

- Adam

Bug#935177: liblcms2-dev:i386: error overwriting src.zip on package upgrade

[Thomas Weber]

Hi Wanderer, 
On Sun, Sep 01, 2019 at 11:13:25AM -0400, The Wanderer wrote:
> Do the files in these two ZIPs really need to be compressed? If so, is
> there a way to generate the files differently so that they don't get
> different timestamps? If not, is there a way to do the compression
> differently such that the timestamps don't get recorded in the
> compressed file?

thanks for spotting this.
Summary: This is due to dh_strip_nondeterminism doing more than it
should and will be fixed with the next upload.

Long version:
src.zip contains the source for the documentation files that are in the
package as PDF files. They are not generated at build time, but are
already included as ZIP in the upstream tarball. Therefore, the only
thing that should happen at build time is the copying of the file into
the .deb package.
dh_strip_nondeterminism however wants to normalize this file and adapts
the timestamps.

The next upload will prevent this behaviour of dh_strip_nondeterminism
for src.zip.

Thanks
Thomas

Bug#939896: Two-finger touchpad scroll is broken in wxgtk3.0-gtk3 on wayland

[Gunter Königsmann]

Package: libwxgtk3.0-gtk3-0v5
Version: 3.0.4+dfsg-9
Wayland only (X11 works fine): Attempts to do a two-finger scroll using
my synaptic touchpad don't cause applications that use the gtk3 flavour
of wxgtk to scroll. The two-finger scroll seems to be ignored instead.
Ordinary gnome applications seem to work fine, instead. Also wxgtk3.0
applications that use gtk2 seem to work fine.

Bug#939754: gimp: Crashes when I try to open an image or create a new one

[Asher Gordon]

Jakob Haufe  writes:

> On Mon, 09 Sep 2019 14:59:02 -0400
> Asher Gordon  wrote:
>
>> I think that its the GEGL version that fixed it, not the patch. The
>> bug appears to be caused because the GIMP was built against GEGL
>> 0.4.14 (in sid), but bullseye only has GEGL 0.4.12.
>
> I doubt this is correct. Installing GEGL 0.4.14-1 from sid on an
> bullseye system did not resolve the segfault issue. This was the first
> thing i tried.

I just tried installing libgegl-0.4-0 version 0.4.14-1+b2 (and
libgegl-common version 0.4.14-1) from sid (also on a bullseye system)
and the GIMP was able to load files and work as expected. You say you
installed GEGL 0.4.14-1. Did you install just plain 0.4.14-1 or with the
+b2 (or +b1)? Did you also install the updated version of
libgegl-common?

If you installed GEGL 0.4.14-1 (no +b*), maybe the issue was introduced
in GEGL 0.4.14-1+b1 or 0.4.14-1+b2?

At any rate, the bug seemed to have been introduced when the GIMP was
updated to 2.10.8-2+b1, so reverting to 2.10.8-2 should provide a
temporary fix at least.

Asher

-- 
Reader, suppose you were an idiot.  And suppose you were a member of
Congress.  But I repeat myself.
-- Mark Twain


signature.asc
Description: PGP signature

Bug#939765: fdpowermon dies every now and then

[Wouter Verhelst]

On Sun, Sep 08, 2019 at 04:58:20PM +0200, Christoph Berg wrote:
> Package: fdpowermon
> Version: 1.18
> Severity: normal
> 
> Hi,
> 
> I have fdpowermon running with awesome (and no "modern" desktop
> environment).

Yeah, me too :-)

> Things work fine, except that after some time, when I'm
> not looking, fdpowermon just disappears. I can't say what's happening,
> the icon and the process are then just gone.
> 
> Any suggestion on how to debug that? Start from gdb?

gdb wouldn't help. "perl -d" might, though. But don't start there.

Instead, I would suggest you capture fdpowermon's stdout and stderr.
They might reveal what's happening. If not, the perl debugger ("perl
-d") might help.

Note that if you run fdpowermon or awesome in a session, the output may
be part of your ~/.xsession-errors file or some such.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Bug#939895: patroni: autopkgtest regression: Assertion Failed: postgres2 is not a leader in dcs after 10 seconds

[Paul Gevers]

Source: patroni
Version: 1.6.0-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of patroni the autopkgtest of patroni fails in
testing when that autopkgtest is run with the binary packages of patroni
from unstable. It passes when run with only packages from testing. In
tabular form:
   passfail
patronifrom testing1.6.0-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it? If needed, please
change the bug's severity.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=patroni

https://ci.debian.net/data/autopkgtest/testing/amd64/p/patroni/2914678/log.gz

Then postgres2 is a leader of batman2 after 10 seconds #
features/steps/custom_bootstrap.py:16
  Assertion Failed: postgres2 is not a leader in dcs after 10 seconds



signature.asc
Description: OpenPGP digital signature

Bug#939894: minia: autopkgtest regression: X.contigs.fa: No such file or directory

[Paul Gevers]

Source: minia
Version: 3.2.1-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of minia the autopkgtest of minia fails in testing
when that autopkgtest is run with the binary packages of minia from
unstable. It passes when run with only packages from testing. In tabular
form:
   passfail
minia  from testing3.2.1-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it? If needed, please
change the bug's severity.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul
PS: your package FTBFS on 3 architectures because of BD not available.
This *also* blocks migration.

[1] https://qa.debian.org/excuses.php?package=minia

https://ci.debian.net/data/autopkgtest/testing/amd64/m/minia/2914535/log.gz

autopkgtest [20:11:12]: test run-unit-test: [---
 Run simple_test.sh 
Traceback (most recent call last):
  File "compare_fasta.py", line 21, in 
s2 = read_seqs(fasta2)
  File "compare_fasta.py", line 15, in read_seqs
for  line in open(fasta):
IOError: [Errno 2] No such file or directory: 'X.contigs.fa'
has a known issue where the  node gets repeated a few times, so it
should print NOT EQUAL. But should print '6', now:
grep: X.contigs.fa: No such file or directory
  0
FAILED
autopkgtest [20:11:12]: test run-unit-test: ---]



signature.asc
Description: OpenPGP digital signature

Bug#874598: Tested workaround

[Yoann LE BARS]

Hello everybody out there!

I am using Debian GNU/Linux 10 :

$ cat /etc/debian_version
10.1

I am using Ardour from standard repositories:

$ aptitude versions ardour
i   1:5.12.0-3stable
900

I have experimented the same bug: Ardour was not loading the graphical
user interface. It appears this bug is reported on Ardour bug tracker:

https://tracker.ardour.org/view.php?id=5605#c18109

According to this report, the problem is due to GTK 2 colour themes
which may be optionally installed on the system. There is a workaround:
set the system variable GTK2_RC_FILES:

$ export GTK2_RC_FILES=/usr/share/themes/Adwaita/gtk-2.0/gtkrc
$ ardour5
bind txt domain [gtk2_ardour5] to /usr/share/ardour5/locale
Ardour5.12.0 (construit avec 1:5.12.0-3 et GCC version 7.3.0)
ardour: [INFO]: Votre configuration-système limite Ardour à 1048576
fichiers ouverts
ardour: [INFO]: Chargement du fichier de configuration-système
/etc/ardour5/system_config
ardour: [INFO]: Chargement du fichier de configuration-utilisateur
/home/yoann/.config/ardour5/config
ardour: [INFO]: CPU vendor: GenuineIntel
ardour: [INFO]: AVX-capable processor
ardour: [INFO]: CPU brand: Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz
ardour: [INFO]: Using SSE optimized routines
ardour: [INFO]: Chargement du fichier de style par défaut
(/etc/ardour5/default_ui_config) pour l'interface graphique
ardour: [INFO]: Chargement du fichier utilisateur de la configuration de
l'interface graphique /home/yoann/.config/ardour5/ui_config
Couleur shuttle bg introuvable
ardour: [INFO]: Chargement du fichier de couleur
/usr/share/ardour5/themes/dark-ardour.colors
ardour: [INFO]: Loading ui configuration file /etc/ardour5/clearlooks.rc
ardour: [INFO]: Loading ui configuration file /etc/ardour5/clearlooks.rc

At least on my system, it works fine. As GTK team efforts are focused
on GTK 3 and 4, the bug will probably not be fixed. Therefore, I think
the workaround should be integrated to the package.

Best regards.

-- 
Yoann LE BARS
http://le-bars.net/yoann/
Diaspora* : yleb...@framasphere.org

Bug#939893: lime-forensics: autopkgtest regression

[Paul Gevers]

Source: lime-forensics
Version: 1.8.1-2
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of lime-forensics the autopkgtest of lime-forensics
fails in testing when that autopkgtest is run with the binary packages
of lime-forensics from unstable. It passes when run with only packages
from testing. In tabular form:
   passfail
lime-forensics from testing1.8.1-2
all others from testingfrom testing

I copied some of the output at the bottom of this report. Is your test
broken with a stretch host kernel? If your need isolation-machine,
please specify that restriction in your autopkgtest declaration:
"""

isolation-machine
The test wants to interact with the kernel, reboot the machine, or
other things which fail in a simple schroot and even a container.
Those tests need to be run in their own machine/VM (e. g.
autopkgtest-virt-qemu or autopkgtest-virt-null). When running the
test in a virtualization server which does not provide this it will
be skipped.
"""

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it? If needed, please
change the bug's severity.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=lime-forensics

https://ci.debian.net/data/autopkgtest/testing/amd64/l/lime-forensics/2914894/log.gz

Setting up lime-forensics-dkms (1.8.1-2) ...
Loading new lime-forensics-1.8.1-2 DKMS files...
It is likely that 4.9.0-8-amd64 belongs to a chroot's host
Building for
Setting up autopkgtest-satdep (0) ...
Processing triggers for systemd (242-5) ...
Processing triggers for libc-bin (2.28-10) ...
(Reading database ... 12759 files and directories currently installed.)
Removing autopkgtest-satdep (0) ...
autopkgtest [22:18:11]: test command1: /usr/lib/dkms/dkms-autopkgtest
autopkgtest [22:18:11]: test command1: [---
dpkg: dependency problems prevent removal of dkms:
 lime-forensics-dkms depends on dkms (>= 2.1.0.0).

dpkg: error processing package dkms (--remove):
 dependency problems - not removing
Errors were encountered while processing:
 dkms
I: Installing binary package lime-forensics-dkms
Reading package lists...
Building dependency tree...
Reading state information...
lime-forensics-dkms is already the newest version (1.8.1-2).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
tar: Cowardly refusing to create an empty archive
Try 'tar --help' or 'tar --usage' for more information.
autopkgtest [22:18:13]: test command1: ---]



signature.asc
Description: OpenPGP digital signature

Bug#939890: buster-pu: package rpcbind/1.2.5-0.3+deb10u1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Mon, 2019-09-09 at 13:28 -0600, Josue Ortega wrote:
> I'd like to update rpcbind in Buster to fix the response to broadcast
> requests. 
> Currently the broadcast requests are broken in Buster causing
> problems to users 
> using NIS services. See #939877 and #935492 for more information.

The metadata for #939877 indicates that it affects the package in
unstable, and is not fixed there. Is that correct? If so, please fix
the package in unstable first; if not, please add an appropriate fixed
version so that the BTS knows what's going on.

Regards,

Adam

Bug#939892: libcloud: autopkgtest regression: ModuleNotFoundError: No module named 'OpenSSL'

[Paul Gevers]

Source: libcloud
Version: 2.5.0-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of libcloud the autopkgtest of libcloud fails in
testing when that autopkgtest is run with the binary packages of
libcloud from unstable. It passes when run with only packages from
testing. In tabular form:
   passfail
libcloud   from testing2.5.0-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. Are you
missing a test dependency?

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul
PS: please upload a source only package next time.

[1] https://qa.debian.org/excuses.php?package=libcloud

https://ci.debian.net/data/autopkgtest/testing/amd64/libc/libcloud/2915042/log.gz

 ERRORS

__ ERROR collecting libcloud/test/loadbalancer/test_nttcis.py
__
ImportError while importing test module
'/tmp/autopkgtest-lxc.j0a3w8ud/downtmp/build.Kba/src/libcloud/test/loadbalancer/test_nttcis.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
libcloud/loadbalancer/drivers/nttcis.py:17: in 
import OpenSSL
E   ModuleNotFoundError: No module named 'OpenSSL'

During handling of the above exception, another exception occurred:
libcloud/test/loadbalancer/test_nttcis.py:25: in 
from libcloud.loadbalancer.drivers.nttcis import NttCisLBDriver
libcloud/loadbalancer/drivers/nttcis.py:20: in 
raise ImportError('Missing "OpenSSL" dependency. You can install it '
E   ImportError: Missing "OpenSSL" dependency. You can install it using
pip - pip install pyopenssl



signature.asc
Description: OpenPGP digital signature

Bug#939891: mysql-workbench: FTFBS in unstable [-Werror=deprecated-copy]

[Bas Couwenberg]

Source: mysql-workbench
Version: 8.0.17+dfsg-1
Severity: serious
Tags: upstream
Justification: makes the package in question unusable or mostly so
User: debian-...@lists.debian.org
Usertags: gdal-3

Dear Maintainer,

Your package FTBFS during a rebuild test with GDAL 3 from experimental
in preparation for the transition.

 /build/mysql-workbench-8.0.17+dfsg/library/base/utf8string.cpp: In static 
member function 'static base::utf8string base::utf8string::strfmt(const char*, 
...)':
 /build/mysql-workbench-8.0.17+dfsg/library/base/utf8string.cpp:368:14: error: 
implicitly-declared 'base::utf8string& base::utf8string::operator=(const 
base::utf8string&)' is deprecated [-Werror=deprecated-copy]
   368 | result = str;
   |  ^~~
 /build/mysql-workbench-8.0.17+dfsg/library/base/utf8string.cpp:215:3: note: 
because 'base::utf8string' has user-provided 
'base::utf8string::utf8string(const base::utf8string&)'
   215 |   utf8string::utf8string(const utf8string& s) : 
_inner_string(s.to_string()) {
   |   ^~
 /build/mysql-workbench-8.0.17+dfsg/library/base/utf8string.cpp: In member 
function 'std::vector base::utf8string::split(const 
base::utf8string&, int)':
 /build/mysql-workbench-8.0.17+dfsg/library/base/utf8string.cpp:399:36: error: 
implicitly-declared 'base::utf8string& base::utf8string::operator=(const 
base::utf8string&)' is deprecated [-Werror=deprecated-copy]
   399 |   ss = ss.substr(p + sep.size());
   |^
 /build/mysql-workbench-8.0.17+dfsg/library/base/utf8string.cpp:215:3: note: 
because 'base::utf8string' has user-provided 
'base::utf8string::utf8string(const base::utf8string&)'
   215 |   utf8string::utf8string(const utf8string& s) : 
_inner_string(s.to_string()) {
   |   ^~

This seems to be caused by the new defaults in gcc-9.

Consider adding -Wno-error=deprecated-copy until upstream fixes the
issue. Or perhaps remove -Werror entirely to not get these FTBFS issues
everytime gcc is updated.

Kind Regards,

Bas

Bug#939605: Support lerna multiple packages

[Xavier]

Hi,

how can plg-js know which is the main package here ?

Bug#939890: buster-pu: package rpcbind/1.2.5-0.3+deb10u1

[Josue Ortega]

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


Hi,

I'd like to update rpcbind in Buster to fix the response to broadcast requests. 
Currently the broadcast requests are broken in Buster causing problems to users 
using NIS services. See #939877 and #935492 for more information.

This is fixed by enabling the --enable-rmtcalls build flag.
I've updated the maintainer information since the previous maintainer is MIA and
I am maitaining this package now.

Changes:
 rpcbind (1.2.5-0.3+deb10u1) buster; urgency=medium
 .
   * Enable remote calls using '--enable-rmtcalls' configuration flag.
 Closes: #939877
   * debian/control: Update maintainer information

The debdiff is attached

Cheers,

Josue
diff -Nru rpcbind-1.2.5/debian/changelog rpcbind-1.2.5/debian/changelog
--- rpcbind-1.2.5/debian/changelog  2018-10-22 04:54:11.0 -0600
+++ rpcbind-1.2.5/debian/changelog  2019-09-09 12:19:21.0 -0600
@@ -1,3 +1,11 @@
+rpcbind (1.2.5-0.3+deb10u1) buster; urgency=medium
+
+  * Enable remote calls using '--enable-rmtcalls' configuration flag.
+Closes: #939877
+  * debian/control: Update maintainer information
+
+ -- Josue Ortega   Mon, 09 Sep 2019 12:19:21 -0600
+
 rpcbind (1.2.5-0.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru rpcbind-1.2.5/debian/control rpcbind-1.2.5/debian/control
--- rpcbind-1.2.5/debian/control2018-10-20 05:18:17.0 -0600
+++ rpcbind-1.2.5/debian/control2019-09-09 12:19:21.0 -0600
@@ -1,7 +1,7 @@
 Source: rpcbind
 Section: net
 Priority: optional
-Maintainer: Anibal Monsalve Salazar 
+Maintainer: Josue Ortega 
 Build-Depends: debhelper (>= 11), pkg-config, libtirpc-dev (>= 1.0.2), 
libwrap0-dev, libsystemd-dev [linux-any]
 Standards-Version: 4.2.1
 Homepage: http://sourceforge.net/projects/rpcbind/
diff -Nru rpcbind-1.2.5/debian/rules rpcbind-1.2.5/debian/rules
--- rpcbind-1.2.5/debian/rules  2018-10-14 06:31:29.0 -0600
+++ rpcbind-1.2.5/debian/rules  2019-09-09 12:19:21.0 -0600
@@ -16,7 +16,7 @@
dh $@
 
 override_dh_auto_configure:
-   dh_auto_configure -- --sbindir=/sbin --enable-warmstarts 
--enable-libwrap --with-statedir=/run/rpcbind --with-rpcuser=_rpc 
$(CONFIGURE_EXTRA_FLAGS)
+   dh_auto_configure -- --sbindir=/sbin --enable-rmtcalls 
--enable-warmstarts --enable-libwrap --with-statedir=/run/rpcbind 
--with-rpcuser=_rpc $(CONFIGURE_EXTRA_FLAGS)
 
 override_dh_installinit:
dh_installinit

Bug#939889: tmux: removal followed by reinstallation uses /etc/shells entry

[Sven Joachim]

Package: tmux
Version: 2.9a-3

If tmux is removed (but not purged) and then reinstalled the
/usr/bin/tmux entry gets lost from /etc/shells.  This is because the
postinst calls add-shell only conditionally on first installs or
upgrades from an old version which did not add tmux to etc/shells.

I guess the purpose is to preserve local configuration and give the
local admin to the ability to remove the /usr/bin/tmux entry from
/etc/shells.  However, removing and then reinstalling a package is also
supposed to preserve its configuration, so we are between a rock and a
hard stone. :-(

Looking at what other shells do, bash and dash behave the same way as
tmux, but only really brave souls dare to remove either of those.  On
the other hand fish, ksh, mksh, rc, screen, tcsh and zsh call add-shell
unconditionally.

Thoughts?


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

Kernel: Linux 5.3.0-rc8-nouveau (SMP w/2 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)

Versions of packages tmux depends on:
ii  libc6   2.29-1
ii  libevent-2.1-6  2.1.8-stable-4
ii  libtinfo6   6.1+20190803-1
ii  libutempter01.1.6-3+b1

tmux recommends no packages.

tmux suggests no packages.

-- no debconf information

Bug#939888: RM: genisovh -- ROM; no upstream release for > 15 years, not needed anymore

[Aurelien Jarno]

Package: ftp.debian.org
Severity: normal

genisovh generate CD-ROMs bootable image for SGI MIPS machine. Given
those are not supported since stretch, there is no point in keeping this
package in the archive.

Bug#939736: mutter 3.33+: Please add "Breaks: apparmor (<< 2.13.3-5~)"

[Jamie Strandboge]

On Sun, 08 Sep 2019, intrig...@debian.org wrote:

> Package: mutter
> Version: 3.33.92-1
> Severity: important
> X-Debbugs-Cc: Jamie Strandboge 
> 
> Hi,
> 
> the AppArmor policy included in the apparmor package, up to and
> including 2.13.3-4, breaks Xwayland apps running in a GNOME+Wayland
> session with mutter >= 3.33.3:
> 
>   https://bugs.debian.org/935058
>   https://gitlab.com/apparmor/apparmor/merge_requests/419
> 
> I've just uploaded apparmor 2.13.3-5 that fixes this problem.
> 
> In order to better support partial upgrades and to ensure that
> migration to testing happens in the correct order, it would be sweet
> if we could prevent folks from upgrading to mutter >= 3.33.3
> without also upgrading apparmor to 2.13.3.5.
> 
> I guess this should do the job (perhaps with the corresponding
> Replaces on top):
> 
>   Breaks: apparmor (<< 2.13.3-5~)
> 
> If I got this wrong and this should instead be handled in
> src:apparmor, please let me know.
> 
> I don't know if/when Ubuntu will cherry-pick the fix into their
> apparmor package. Jamie, you might want to coordinate something
> similar, or merge from the debian/master branch in our shared
> Vcs-Git :)

We've historically not introduced Breaks for this sort of thing, but
the Ubuntu Desktop team has asked me to perform the merge which I am
doing now.

-- 
Jamie Strandboge | http://www.canonical.com


signature.asc
Description: PGP signature

Bug#939754: gimp: Crashes when I try to open an image or create a new one

[Jakob Haufe]

On Mon, 09 Sep 2019 14:59:02 -0400
Asher Gordon  wrote:

> I think that its the GEGL version that fixed it, not the patch. The
> bug appears to be caused because the GIMP was built against GEGL
> 0.4.14 (in sid), but bullseye only has GEGL 0.4.12.

I doubt this is correct. Installing GEGL 0.4.14-1 from sid on an
bullseye system did not resolve the segfault issue. This was the first
thing i tried.

> See also #939768 for more info, which appears to be the same bug. See
> especially message #20. #939876 also looks like the same bug. All
> three of these bugs should probably be merged.

Yes, I tend to agree on that one. But I'll leave that to the GIMP
maintainers to decide.

-- 
ceterum censeo microsoftem esse delendam.


pgpfArSubhhhR.pgp
Description: OpenPGP digital signature

Bug#939887: breezy: autopkgtest depends on python-meliae which has been removed from unstable

[Paul Gevers]

Source: breezy
Version: 3.0.1-2
X-Debbugs-CC: debian...@lists.debian.org
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: needs-update

Dear maintainers,

With a recent upload of glibc the autopkgtest of breezy fails in testing
when that autopkgtest is run with the binary packages of glibc from
unstable. Hence I discovered that the autopkgtest of your package
depends on python-meliae, which has recently been removed from Debian
unstable and testing.

Please update your autopkgtest.

Paul
PS: your package also has a build failure on s390x, preventing its
migration to testing.



signature.asc
Description: OpenPGP digital signature

Bug#939794: ghostscript breaks fig2dev autopkgtest: compare arrow tips with template failed unexpectedly

[Roland Rosenfeld]

Hi Paul!

On Mo, 09 Sep 2019, Paul Gevers wrote:

> > Sadly the testsuite generates a filename with /./ in it...
> > From my point of view ../.././data/arrows.eps is a valid file name on
> > Unix systems, so gs should accept it.
> > 
> > Is there a good reason to reject this file name in gs?  Then we have
> > to change the testsuite, otherwise I'd suggest fixing the behavior of
> > gs.

> I'm not sure, but does https://bugs.debian.org/bug=939044#75 help you?

I don't think so.  If I understand the above right, it's about a PS
file including or opening some external files, which may result in
some security issues.

Here it's not the problem of a PS file including some external file.
The problem is, that gs doesn't like to open ../.././data/arrows.eps
given by command line directly.  This may be triggered by some
security improvement of gs, but from my point of view
../.././data/arrows.eps is a valid file name and so gs should convert
this file and not fail on it.

In the meantime I prepared a patch for fig2dev to work around this
issue (not published), but I'm still not sure, weather the behavior of
gs is simply broken here and will lead to fail in other situations,
too.

So I delay publishing my workaround, since I think that gs should fix
the issue (or explain me, why it's behaving correct).

Greetings
Roland


signature.asc
Description: PGP signature

Bug#939754: gimp: Crashes when I try to open an image or create a new one

[Asher Gordon]

Package: gimp
Version: 2.10.8-2+b1
Followup-For: Bug #939754

Hello Jakob,

Jakob Haufe  writes:

> I cherry-picked 986a298a from upstream (which is also contained in
> 2.10.10+) and rebuilt gimp. This fixes the issue for me. This patch,
> however, needs gegl >= 0.4.14 which is stuck in unstable ATM.

I think that its the GEGL version that fixed it, not the patch. The bug
appears to be caused because the GIMP was built against GEGL 0.4.14 (in
sid), but bullseye only has GEGL 0.4.12.

See also #939768 for more info, which appears to be the same bug. See
especially message #20. #939876 also looks like the same bug. All three
of these bugs should probably be merged.

Thanks,
Asher

-- 
...very few phenomena can pull someone out of Deep Hack Mode, with two
noted exceptions: being struck by lightning, or worse, your *computer*
being struck by lightning.
-- Matt Welsh

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

Kernel: Linux 5.2.0-2-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 gimp depends on:
ii  gimp-data2.10.8-2
ii  libaa1   1.4p5-46+b1
ii  libbabl-0.1-00.1.62-1
ii  libbz2-1.0   1.0.6-9.2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libfontconfig1   2.13.1-2+b1
ii  libfreetype6 2.9.1-4
ii  libgcc1  1:9.2.1-4
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libgegl-0.4-00.4.12-2
ii  libgexiv2-2  0.10.9-1
ii  libgimp2.0   2.10.8-2+b1
ii  libglib2.0-0 2.60.6-2
ii  libgs9   9.27~dfsg-3.1
ii  libgtk2.0-0  2.24.32-3
ii  libgudev-1.0-0   232-2
ii  libharfbuzz0b2.6.1-2
ii  libheif1 1.5.1-1
ii  libilmbase24 2.3.0-6
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-3+b1
ii  liblzma5 5.2.4-1+b1
ii  libmng1  1.0.10+dfsg-3.1+b5
ii  libmypaint-1.3-0 1.3.0-2.1+b1
ii  libopenexr24 2.3.0-6
ii  libopenjp2-7 2.3.0-2
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libpangoft2-1.0-01.42.4-7
ii  libpng16-16  1.6.37-1
ii  libpoppler-glib8 0.71.0-5+b1
ii  librsvg2-2   2.44.14-1
ii  libstdc++6   9.2.1-4
ii  libtiff5 4.0.10+git190818-1
ii  libwebp6 0.6.1-2+b1
ii  libwebpdemux20.6.1-2+b1
ii  libwebpmux3  0.6.1-2+b1
ii  libwmf0.2-7  0.2.8.4-14
ii  libx11-6 2:1.6.7-1
ii  libxcursor1  1:1.2.0-2
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxmu6  2:1.1.2-2+b3
ii  libxpm4  1:3.5.12-1
ii  xdg-utils1.1.3-1
ii  zlib1g   1:1.2.11.dfsg-1+b1

Versions of packages gimp recommends:
ii  ghostscript  9.27~dfsg-3.1

Versions of packages gimp suggests:
pn  gimp-data-extras  
ii  gimp-help-en [gimp-help]  2.8.2-1
pn  gimp-python   
ii  gvfs-backends 1.38.1-5
ii  libasound21.1.8-1

-- no debconf information


signature.asc
Description: PGP signature

Bug#939886: RFS: pacvim/1.1.1-1 -- pacman game concept with vim command

[Ko Ko Ye`]

Package: sponsorship-requests
Severity: normal [important for RC bugs, wishlist for new packages]

Dear mentors,

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

 * Package name: pacvim
   Version : 1.1.1-1
   Upstream Author : kokoye2007 
 * URL : https://salsa.debian.org/kokoye2007-guest/pacvim
 * License : LGPL-3.0+
 * Vcs : https://salsa.debian.org/kokoye2007-guest/pacvim
   Section : games

It builds those binary packages:

  pacvim - pacman game concept with vim command

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/p/pacvim/pacvim_1.1.1-1.dsc

Changes since the last upload:

   * Initial release (Closes: ##902435)
   * change /usr/local/bin to /usr/games
   * change /usr/local/share/pacvim to /usr/share/pacvim
   * make very first man pages  pacvim.1
   * already PPA for ubuntu disco dingo
https://launchpad.net/~kokoye2007/+archive/ubuntu/ppa/+sourcepub/10533150/+listing-archive-extra

 who will be a sponsor for this package?
its small and easy tp use games for vim training.

with regards.
Ko Ko Ye
kokoye2...@ubuntu.com


Regards,

Bug#939794: ghostscript breaks fig2dev autopkgtest: compare arrow tips with template failed unexpectedly

[Paul Gevers]

Hi Roland,

On 09-09-2019 09:05, Roland Rosenfeld wrote:
> Removing the "./" from the input filename the error disappears.
> Sadly the testsuite generates a filename with /./ in it...
> From my point of view ../.././data/arrows.eps is a valid file name on
> Unix systems, so gs should accept it.
> 
> Is there a good reason to reject this file name in gs?  Then we have
> to change the testsuite, otherwise I'd suggest fixing the behavior of
> gs.

I'm not sure, but does https://bugs.debian.org/bug=939044#75 help you?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#939885: dpkg: unrecoverable fatal error: unknown system group 'smmsp' in statoverride file

[Sebastien Duthil]

Package: sendmail-bin
Version: 8.15.2-14~deb10u1
Severity: normal

Dear Maintainer,

Given the following commands are run on a fresh buster install:

apt install sendmail
apt install postfix
apt autoremove --purge

When I try to install any package, e.g. apt install mutt
Then I get an error:

dpkg: unrecoverable fatal error, aborting:
 unknown system group 'smmsp' in statoverride file; the system group got removed
before the override, which is most probably a packaging bug, to recover you
can remove the override manually with dpkg-statoverride
E: Sub-process /usr/bin/dpkg returned an error code (2)

This error effectively blocks the installation of any further package.

When in this state, the package sendmail-bin is removed, but not purged.

The problem goes away after running the following command:

apt purge sendmail-bin


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

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

Versions of packages sendmail-bin depends on:
ii  debconf1.5.71
ii  libc6  2.28-10
ii  libdb5.3   5.3.28+dfsg1-0.5
ii  libldap-2.4-2  2.4.47+dfsg-3+deb10u1
pn  liblockfile1   
ii  libsasl2-2 2.1.27+dfsg-1
ii  libssl1.1  1.1.1c-1
ii  libwrap0   7.6.q-28
ii  lsb-base   10.2019051400
ii  procps 2:3.3.15-2
pn  sendmail-base  
pn  sendmail-cf

sendmail-bin recommends no packages.

Versions of packages sendmail-bin suggests:
ii  libsasl2-modules  2.1.27+dfsg-1
ii  openssl   1.1.1c-1
pn  sasl2-bin 
pn  sendmail-doc  

Bug#939602: debdiff: no longer diffs contents of sources, diffs only quiltage

[Adam Borowski]

On Fri, Sep 06, 2019 at 08:08:26PM +0100, Adam D. Barratt wrote:
> On Fri, 2019-09-06 at 20:14 +0200, Adam Borowski wrote:
> > A regression from 1.0 to 3.0 (quilt) format:
> [...]
> > With debdiff on 1.0 packages, or with regular diff on unpacked source
> > trees, you get a comparison of the sources that'll be compiled/etc --
> 
> Unless it's 1.0 with any form of patch system that doesn't result in
> the changes being applied directly, e.g. dpatch or even quilt.

Well yeah, it's not supposed to diff containers recursively.  Looking inside
dpatch is no different from eg. looking inside gcc's tarball-in-tarball.

> > ie, anything that matters for the package's functionality.  But with
> > 3.0, you get only a diff of the outer container.
> > 
> > The new behaviour may be useful at most for comparing changed patch
> > metadata, or for debugging quilt-related issues, but not the actual
> > code.
> 
> While you say "no longer", and "new behaviour", I will note that the
> code in question has been in debdiff for over a decade. See #475506.

Or rather: it never had proper support for "3.0 (quilt)" implemented.

#475506 complains about differences showing twice.  And at that point, 3.0
was an early preview, thus a quick hack that got rid of one of the copies
was acceptable.

debdiff is a major part of workflows for many of us; in my case I run it on
every single non-NEW upload I sponsor.  And even when both versions have the
same upstream version, double diffs are pretty hard to read.  So far I only
cursed that but did not investigate the cause -- and only now I realized
that the double diffage doesn't seem to be intended.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Latin:   meow 4 characters, 4 columns,  4 bytes
⣾⠁⢠⠒⠀⣿⡁ Greek:   μεου 4 characters, 4 columns,  8 bytes
⢿⡄⠘⠷⠚⠋  Runes:   ᛗᛖᛟᚹ 4 characters, 4 columns, 12 bytes
⠈⠳⣄ Chinese: 喵   1 character,  2 columns,  3 bytes <-- best!

Bug#939770: wireshark: Wrong path in pre-install notification

[Justin B Rye]

Balint Reczey wrote:
> Justin B Rye wrote:
>> So instead of saying "after the package installation is finished" you
>> might change it to something like:
>>
>>   For more detailed information please see
> - /usr/share/doc/wireshark-common/README.Debian.
> > + /usr/share/doc/wireshark-common/README.Debian.gz once the package is
>> + installed.
> 
> Good point. Can I apply this change as the one reviewed?

If you're asking whether you can regard this as having received an
official debian-l10n-english review, sure, as far as I'm concerned
it's okay whether you include my bikeshedding or not.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#939884: genisovh FTCBFS: hard codes gcc

[Helmut Grohne]

Source: genisovh
Version: 0.1-4
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

genisovh fails to cross build from source, because the upstream Makefile
hard codes the build architecture compiler. Please consider applying the
attached patch.

Helmut
--- genisovh-0.1.orig/Makefile
+++ genisovh-0.1/Makefile
@@ -6,7 +6,7 @@
 OBJS=main.o
 
 genisovh: $(OBJS)
-	gcc $(LDFLAGS) -o $@ $+
+	$(CC) $(LDFLAGS) -o $@ $+
 
 clean: 
 	rm -f $(OBJS) genisovh core

Bug#939883: otp FTCBFS: does not pass cross tools to make

[Helmut Grohne]

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

otp fails to cross build from source, because it does not pass cross
tools to make. The easiest way of doing so - using dh_auto_build - makes
otp cross buildable. Please consider applying the attached patch.

Helmut
diff --minimal -Nru otp-1.2.2/debian/changelog otp-1.2.2/debian/changelog
--- otp-1.2.2/debian/changelog  2014-06-04 12:33:56.0 +0200
+++ otp-1.2.2/debian/changelog  2019-09-09 20:39:07.0 +0200
@@ -1,3 +1,10 @@
+otp (1:1.2.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 09 Sep 2019 20:39:07 +0200
+
 otp (1:1.2.2-1) unstable; urgency=low
 
   * New upstream version (closes: #750140).
diff --minimal -Nru otp-1.2.2/debian/rules otp-1.2.2/debian/rules
--- otp-1.2.2/debian/rules  2012-06-16 18:20:57.0 +0200
+++ otp-1.2.2/debian/rules  2019-09-09 20:39:03.0 +0200
@@ -19,7 +19,7 @@
 build-indep: build-stamp
 build-stamp:
dh_testdir
-   $(MAKE)
+   dh_auto_build
> $@
 
 binary: binary-arch binary-indep

Bug#939882: gkrellkam FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: gkrellkam
Version: 2.0.0-1.2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

gkrellkam fails to cross build from source, because it does not pass
cross tools to make. The easiest way of fixing that - using
dh_auto_build - is insufficient here as the upstream Makefile hard codes
the build architecture pkg-config. pkg-config needs to be made
substitutable as well. Please consider applying the attached patch.

Helmut
diff -u gkrellkam-2.0.0/Makefile gkrellkam-2.0.0/Makefile
--- gkrellkam-2.0.0/Makefile
+++ gkrellkam-2.0.0/Makefile
@@ -13,7 +13,8 @@
 GKRELLM_HDRS = /usr/include
 
 CC := gcc
-GTKFLAGS := $(shell pkg-config gtk+-2.0 --cflags)
+PKG_CONFIG ?= pkg-config
+GTKFLAGS := $(shell $(PKG_CONFIG) gtk+-2.0 --cflags)
 CFLAGS := $(CFLAGS) -fPIC -Wall $(GTKFLAGS) -I$(GKRELLM_HDRS)
 LDFLAGS := -shared
 INST_DIR := $(DESTDIR)/usr/lib/gkrellm2/plugins
diff -u gkrellkam-2.0.0/debian/changelog gkrellkam-2.0.0/debian/changelog
--- gkrellkam-2.0.0/debian/changelog
+++ gkrellkam-2.0.0/debian/changelog
@@ -1,3 +1,12 @@
+gkrellkam (2.0.0-1.3) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build pass cross tools to make.
++ Makefile: make pkg-config substitutable.
+
+ -- Helmut Grohne   Mon, 09 Sep 2019 20:38:25 +0200
+
 gkrellkam (2.0.0-1.2) unstable; urgency=medium
 
   * Non-maintainer upload
reverted:
--- gkrellkam-2.0.0/debian/files
+++ gkrellkam-2.0.0.orig/debian/files
@@ -1 +0,0 @@
-gkrellkam_2.0.0-1.2_source.buildinfo x11 optional
diff -u gkrellkam-2.0.0/debian/rules gkrellkam-2.0.0/debian/rules
--- gkrellkam-2.0.0/debian/rules
+++ gkrellkam-2.0.0/debian/rules
@@ -18,10 +18,7 @@
 build: configure-stamp build-stamp
 build-stamp:
dh_testdir
-
-   # Add here commands to compile the package.
-   $(MAKE)
-
+   dh_auto_build
touch build-stamp
 
 clean:

Bug#939825: qtcreator: clang-format plugin broken

[Lisandro Damián Nicanor Pérez Meyer]

The error code comes from
src/plugins/clangformat/clangformatplugin.cpp::157. Looking at the
code it means that KEEP_LINE_BREAKS_FOR_NON_EMPTY_LINES_BACKPORTED is
not defined, but I do not know where that should be defined.

Bug#939881: FTBFS: trying to run :rabbitmqctl on Elixir v1.9.1 but supports only >= 1.6.6 and < 1.8.0

[Ryan Tandy]

Source: rabbitmq-server
Version: 3.7.8-5
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Dear maintainer, rabbitmq-server FTBFS:

==> rabbitmqctl
** (Mix) You're trying to run :rabbitmqctl on Elixir v1.9.1 but it has declared in 
its mix.exs file it supports only Elixir >= 1.6.6 and < 1.8.0
make[4]: *** [Makefile:93: escript/rabbitmqctl] Error 1

https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/rabbitmq-server_3.7.8-5.rbuild.log.gz

Also reproduced locally using sbuild.

Bug#939880: RFS: libassa/3.5.1-7 [ITA] -- object-oriented C networking library (development files)

[Shane McDonald]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: libassa
   Version : 3.5.1-7
   Upstream Author : Vladislav Grinchenko 
 * URL : http://libassa.sourceforge.net/
 * License : LGPL-2+
 * Vcs : https://salsa.debian.org/shanemcd-guest/libassa
   Section : libs

It builds those binary packages:

  libassa-3.5-5-dev - object-oriented C++ networking library (development files)
  libassa-3.5-5v5 - object-oriented C++ networking library

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/liba/libassa/libassa_3.5.1-7.dsc

Changes since the last upload:

   * New maintainer (Closes: #855634)
   * Update the Vcs-* fields in debian/control
   * Remove obsolete -dbg package
   * Remove useless dh-autoreconf build dependency
   * Fixed spelling errors: unsinged -> unsigned, Recevied -> Received
   * Enable all security hardening options when compiling
   * Switch to debhelper-compat = 12.
   * Remove "--with autoreconf" from the debian/rules file (no longer needed)
   * Remove "unused Javascript library" override
   * Don't include the build path in generated Doxygen documentation
   * Removed trailing whitespace in debian/changelog
   * Remove unnecessary override of dh_auto_clean
   * Bumped Standards-Version to 4.4.0
 - Changed to https form of the copyright-format URL
 - No other changes required

Regards,
Shane McDonald

Bug#939878: geoip-bin

[Pat Suwalski]

From MaxMind web site 
(https://dev.maxmind.com/geoip/geoip2/whats-new-in-geoip2/):


"We now distinguish between several types of country data. The country 
is the country where the IP address is located. The registered_country 
is the country in which the IP is registered. These two may differ in 
some cases."


This suggests the "country" field is the physical location, which I 
think should be preferred in the geoip-database.


--Pat

Bug#939873: qla2xxx .. Async-gnlist failed

[Julien Cristau]

On Mon, Sep  9, 2019 at 17:51:02 +0100, Ben Hutchings wrote:

> On Mon, 9 Sep 2019 16:29:07 + Peter Palfrader 
> wrote:
> > Package: src:linux
> > Version: 4.19.67-2
> > Severity: important
> > 
> > The buster kernel, as well as the backports kernel
> > (linux-image-5.2.0-0.bpo.2-amd64 5.2.9-2~bpo10+1) fail to boot
> > sibelius.debian.org, which has some storage attached to it via,
> > presumably, FC.
> > 
> > The kernel keeps printing
> > 
> > | qla2xxx [...]-...: Async-gpdb failed - hdl=.. ...
> [...]
> 
> So this controller is:
> 
> 06:01.0 Fibre Channel [0c04]: QLogic Corp. ISP2312-based 2Gb Fibre Channel to 
> PCI-X HBA [1077:2312] (rev 02)
> Subsystem: QLogic Corp. ISP2312-based 2Gb Fibre Channel to PCI-X HBA 
> [1077:010a]
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ 
> Stepping- SERR+ FastB2B- DisINTx-
> Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
> SERR-  Latency: 128 (16000ns min), Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 26
> NUMA node: 0
> Region 0: I/O ports at c800 [size=256]
> Region 1: Memory at fe8ff000 (64-bit, non-prefetchable) [size=4K]
> Expansion ROM at fe8c [disabled] [size=128K]
> Capabilities: 
> Kernel driver in use: qla2xxx
> Kernel modules: qla2xxx
> 
These look similar, though they don't point at a resolution:
https://bugzilla.kernel.org/show_bug.cgi?id=199887
https://bugzilla.opensuse.org/show_bug.cgi?id=1121319

Seemingly introduced in 4.11.

Cheers,
Julien

Bug#939740: closed by Olly Betts (Bug#939740: fixed in wxwidgets3.0 3.0.4+dfsg-11)

[Olly Betts]

On Mon, Sep 09, 2019 at 07:24:26PM +0200, Andreas Metzler wrote:
> On 2019-09-09 Debian Bug Tracking System  wrote:
> >  wxwidgets3.0 (3.0.4+dfsg-11) unstable; urgency=medium
> >  .
> >* debian/patches/upstream-changes-since-3.0.4.patch: Add lost entry for
> >  new wxWindow::GetContentScaleFactor() function. (Closes: #939740)

> I have just rebuilt hugin 2019.0.0+dfsg-3 against wxwidgets3.0
> 3.0.4+dfsg-11. It still will not run with wxwidgets3.0 3.0.4+dfsg-9:

Hmm, before uploading I attempted to confirm the fix by doing a test
rebuild of hugin 2019.0.0+dfsg-2 against wxwidgets 3.0.4+dfsg-11 and
then installing the hugin package and checking it with wxwidgets
3.0.4+dfsg-9 installed.

> Nevertheless the resulting binary packages does not have an appropriate
> strict dependency on libwxgtk3.0-gtk3-0v5 (>= 3.0.4+dfsg-10).

But looking at the build log there is indeed not a strict dependency,
so I guess I didn't actually test the scenario I intended to...

Thinking about this more, the thing I fixed was a red herring unless
there's some mechanism for creating a symbols file from the information
in the upstream linker version script, and I don't think there is.

I'll add a shlibs file (manually maintaining a symbols file for a C++
library seems too painful for the benefits it gives).

Cheers,
Olly

Bug#939879: stylish-haskell: debdiff for NMU

[Gianfranco Costamagna]

Source: stylish-haskell
Version: 0.9.2.2-1
Severity: important
tags: patch

Attached debdiff :)

G.
diff -Nru stylish-haskell-0.9.2.2/debian/changelog 
stylish-haskell-0.9.2.2/debian/changelog
--- stylish-haskell-0.9.2.2/debian/changelog2019-07-14 16:35:52.0 
+0200
+++ stylish-haskell-0.9.2.2/debian/changelog2019-09-09 10:31:15.0 
+0200
@@ -1,3 +1,15 @@
+stylish-haskell (0.9.2.2-3) unstable; urgency=medium
+
+  * Add new changelog entry, source upload to unstable
+
+ -- Gianfranco Costamagna   Mon, 09 Sep 2019 
10:31:15 +0200
+
+stylish-haskell (0.9.2.2-2) unstable; urgency=medium
+
+  * Update semigroup dependency
+
+ -- Gianfranco Costamagna   Mon, 09 Sep 2019 
10:19:47 +0200
+
 stylish-haskell (0.9.2.2-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru stylish-haskell-0.9.2.2/debian/control 
stylish-haskell-0.9.2.2/debian/control
--- stylish-haskell-0.9.2.2/debian/control  2019-07-14 16:35:52.0 
+0200
+++ stylish-haskell-0.9.2.2/debian/control  2019-09-09 10:19:22.0 
+0200
@@ -20,6 +20,10 @@
  libghc-mtl-dev (<< 2.3),
  libghc-mtl-prof (>= 2.0),
  libghc-mtl-prof (<< 2.3),
+ libghc-semigroups-dev (>= 0.18),
+ libghc-semigroups-dev (<< 0.20),
+ libghc-semigroups-prof (>= 0.18),
+ libghc-semigroups-prof (<< 0.20),
  libghc-syb-dev (>= 0.3),
  libghc-syb-dev (<< 0.8),
  libghc-syb-prof (>= 0.3),

Bug#939878: geoip-bin

[Pat Suwalski]

Package: geoip-bin
Version: 1.6.12-3

I believe there is an issue with data conversion in the 
geolite2-to-legacy-csv.sh.


Checking the IP 5.62.22.12, which is in Australia, against the generated 
data, it comes back as UK.


The source data comes back as Australia: 
https://www.maxmind.com/en/geoip2-precision-demo


This third-party conversion comes back as Australia: 
https://www.miyuru.lk/geoiplegacy


It seems the big if-elseif block in the script prefers the country 
fields in the order "represented", "registered", and then "country".


For this block, "country" is correct, "registered" is not the desired 
country, and "represented" is null.


Suggest that "country" is more accurate and should be preferred over 
where the block is registered.

Bug#937792: Blocked by reverse dependencies

[Martin Kelly]

We are blocked by the following reverse dependencies:

$ apt-cache rdepends python-gmpy2
python-gmpy2
Reverse Depends:
  python-mpmath
 |python-gmpy2-doc
 |python-gmpy2-common
  pyecm

pyecm is already fixed to use Python 3 and the other two are built by us 
and just need renaming.


Added affects/blocks to python-mpmath.

Bug#937791: Blocked on reverse dependencies

[Martin Kelly]

On Mon, 9 Sep 2019 10:42:08 -0700 Martin Kelly  
wrote:

We are blocked on the following reverse dependencies:

$ apt-cache rdepends python-gmpy
python-gmpy
Reverse Depends:
   obfsproxy
   python-tlslite-ng
   python-sympy
   python-gmpy-doc




Dependencies on obfsproxy and python-sympy documented with affects and 
blocks. python-tlslite-ng has been removed already, and we can rename 
python-gmpy-doc to python3-gmpy-doc once the blocking bugs are resolved.