Bug#935490: debian-installer: Mouse and keyboard freezes at first screen, choose language

[Marcus]

Package: debian-installer
Version: Debian 10 buster
Severity: critical
Tags: d-i
Justification: breaks the whole system

Dear Maintainer,

Installing from USB stick on a supermicro server.
Tested with netintall, full local install and firmware install iso. All of them 
have the same behavior.
At first try came up to where the installer ask for non-free firmware. Went to 
fetch them and when I came back mouse and keyboard was frozen.
Tested a number of times and with different iso images with the same result. 
The mouse and keyboard freezes on first screen where you choose install 
language.
Server only have urb3 ports, and the BIOS were set to usb2 support enabled and 
usb3 auto. Tested to change settings but no difference.
Tried to install Debian 9.9 and that worked well without any freeze.
Might be related to bug report: #728226
debian-installer: Install freezes for up to 70 seconds in isolinux

Thanks
Marcus


-- System Information:
Debian Release: 10

Bug#935488: /usr/bin/apt-get: fails to parse build depends from d/control

[Ritesh Raj Sarraf]

On Fri, 2019-08-23 at 08:46 +0200, Johannes Schauer wrote:
> > The way some of the packages, docker.io included, define the build
> > dependencies; leads to apt-get failing to parse it. This has
> reflected
> > in our automation.
> > 
> > This is taken from docker.io's d/control file.
> > 
> > Build-Depends: debhelper (>= 11~) ,dh-exec ,dh-golang (>= 1.14~)
> > ,bash-completion,
> > ,ca-certificates
> > ,git
> > ,golang-any (>= 2:1.10~)
> > ,go-md2man (>= 1.0.3~)
> > ,gogoprotobuf, libprotobuf-dev
> > ,golang-dbus-dev (>= 4.1.0~)
> > ,golang-etcd-server-dev
> 
> There is a syntax error. Between bash-completion and ca-certificates
> there are
> two commas.

Can you please have a look at package protobuf ?
That one does not seem to have the syntactical error you mention but
there still apt fails to parse Build Depends.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#935488: /usr/bin/apt-get: fails to parse build depends from d/control

[Johannes Schauer]

On Fri, 23 Aug 2019 11:50:06 +0530 Ritesh Raj Sarraf  wrote:
> Do we have a policy defined for how Build Dependency packages are to be
> defined in file debian/control ?

Yes.

https://www.debian.org/doc/debian-policy/ch-controlfields.html#source-package-control-files-debian-control
https://www.debian.org/doc/debian-policy/ch-relationships.html

> The way some of the packages, docker.io included, define the build
> dependencies; leads to apt-get failing to parse it. This has reflected
> in our automation.
> 
> This is taken from docker.io's d/control file.
> 
> Build-Depends: debhelper (>= 11~) ,dh-exec ,dh-golang (>= 1.14~)
> ,bash-completion,
> ,ca-certificates
> ,git
> ,golang-any (>= 2:1.10~)
> ,go-md2man (>= 1.0.3~)
> ,gogoprotobuf, libprotobuf-dev
> ,golang-dbus-dev (>= 4.1.0~)
> ,golang-etcd-server-dev

There is a syntax error. Between bash-completion and ca-certificates there are
two commas.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#935471: systemd: bogus "Process .. as been marked to be excluded from killing" warning from systemd-shutdown

[Michael Biebl]

Hi

Am 23.08.19 um 01:06 schrieb Marc Lehmann:
> Package: systemd
> Version: 241-5
> Severity: minor
> 
> Dear Maintainer,
> 
> on one of my systems, debian runs from a filesystem image loop-mounted
> from an ntfs volume using ntfs-3g, and thus, the ntfs-3g process must be
> running at all times, before mounting the root fs and during shutdown.
> 
> To accomplish this I have an initramfs-tools script that runs it something
> like this:
> 
>   exec -a @ntfs-3g-root ntfs-3g ...
> 
> The @ prevents systemd-shutdown from killing it, which works. However, it
> outputs the following warning (lifted from the code, can't copy&paste from
> the real system):
> 
> log_notice("Process " PID_FMT " (%s) has been marked to be 
> excluded from killing. It is "
>"running from the root file system, and thus 
> likely to block re-mounting of the "
>"root file system to read-only. Please consider 
> moving it into an initrd file "
>"system instead.", pid, strna(comm));
> 
> Since it is running from the initramfs, this warning is bogus (and indeed,
> the root fs can be mounted ro with no problem), suggesting that the check
> systemd-shutdown uses to detect this case is broken.

If you have ideas how to improve the code, a patch would be great.
Ideally, you should submit this upstream at
https://github.com/systemd/systemd/

Regards,
Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#935488: /usr/bin/apt-get: fails to parse build depends from d/control

[Ritesh Raj Sarraf]

Package: apt
Version: 1.8.3
Severity: normal
File: /usr/bin/apt-get

Do we have a policy defined for how Build Dependency packages are to be
defined in file debian/control ?

Consider the following:

rrs@priyasi:~/NoBackup/Gitlab_Packages/sdk/docker.io $ sudo apt-get -o 
APT::Get::Build-Dep-Automatic=yes build-dep $PWD
[sudo] password for rrs: 
Note, using directory '/home/rrs/NoBackup/Gitlab_Packages/sdk/docker.io' to get 
the build dependencies
Reading package lists... Done
E: Problem parsing dependency: Build-Depends
E: Unable to get build-dependency information for 
/home/rrs/NoBackup/Gitlab_Packages/sdk/docker.io
11:44 ♒♒♒☹ 😟=> 100  

rrs@priyasi:~/NoBackup/Gitlab_Packages/sdk/docker.io $ cd ..
11:44 ♒♒♒   ☺ 😄
rrs@priyasi:~/NoBackup/Gitlab_Packages/sdk$ cd gpsd/
11:44 ♒♒♒   ☺ 😄

rrs@priyasi:~/NoBackup/Gitlab_Packages/sdk/gpsd $ sudo apt-get -o 
APT::Get::Build-Dep-Automatic=yes build-dep $PWD
Note, using directory '/home/rrs/NoBackup/Gitlab_Packages/sdk/gpsd' to get the 
build dependencies
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following NEW packages will be installed:
  chrpath dh-buildinfo dh-systemd libbluetooth-dev libdbus-1-dev 
libdbus-glib-1-dev libdbus-glib-1-dev-bin libdrm-dev libexpat1-dev
  libgl1-mesa-dev libgles1 libglu1-mesa-dev libglvnd-core-dev libglvnd-dev 
libncurses-dev libopengl0 libpthread-stubs0-dev libpython-all-dbg
  libpython-all-dev libpython-dbg libpython-dev libpython2-dbg libpython2-dev 
libpython2.7-dbg libpython2.7-dev libusb-1.0-0-dev libvulkan-dev
  libx11-dev libx11-xcb-dev libxau-dev libxcb-dri2-0-dev libxcb-dri3-dev 
libxcb-glx0-dev libxcb-present-dev libxcb-randr0-dev libxcb-render0-dev
  libxcb-shape0-dev libxcb-sync-dev libxcb-xfixes0-dev libxcb1-dev 
libxdamage-dev libxdmcp-dev libxext-dev libxfixes-dev libxshmfence-dev
  libxxf86vm-dev makedev mesa-common-dev pps-tools python-all python-all-dbg 
python-all-dev python-dbg python-dev python2-dbg python2-dev
  python2.7-dbg python2.7-dev qt5-default qt5-qmake qt5-qmake-bin qtbase5-dev 
qtbase5-dev-tools scons x11proto-core-dev x11proto-damage-dev
  x11proto-dev x11proto-fixes-dev x11proto-xext-dev x11proto-xf86vidmode-dev 
xorg-sgml-doctools xsltproc xtrans-dev
0 upgraded, 73 newly installed, 0 to remove and 0 not upgraded.
Need to get 55.9 MB of archives.
After this operation, 152 MB of additional disk space will be used.
Do you want to continue? [Y/n] ^C
11:44 ♒♒♒☹ 😟=> 130  
rrs@priyasi:~/NoBackup/Gitlab_Packages/sdk/gpsd $ 


The way some of the packages, docker.io included, define the build
dependencies; leads to apt-get failing to parse it. This has reflected
in our automation.

This is taken from docker.io's d/control file.

Build-Depends: debhelper (>= 11~) ,dh-exec ,dh-golang (>= 1.14~)
,bash-completion,
,ca-certificates
,git
,golang-any (>= 2:1.10~)
,go-md2man (>= 1.0.3~)
,gogoprotobuf, libprotobuf-dev
,golang-dbus-dev (>= 4.1.0~)
,golang-etcd-server-dev

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-image-5\.2\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-headers-5\.2\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-5\.2\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-modules-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-modules-5\.2\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-modules-extra-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-modules-extra-5\.2\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-5\.2\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-image-unsigned-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-image-unsigned-5\.2\.0-2-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-5\.2\.0-2-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-5\.2\.0-2-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-5\.2\.0-2-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^.*-modules-5\.2\.0-2-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-5\.2\.0-2-amd64$";
APT::

Bug#935445: dansguardian 2.10.1.1-5.1+deb9u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 935445 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: dansguardian
Version: 2.10.1.1-5.1+deb9u2

Explanation: add support for clamav 0.101

Bug#928556: gocode 20150303-3+deb9u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 928556 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: gocode
Version: 20150303-3+deb9u2

Explanation: gocode-auto-complete-el: Make Pre-Depends: auto-complete-el 
versioned to fix upgrades from jessie to stretch

Bug#924278: clamav 0.101.2+dfsg-0+deb9u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 924278 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: clamav
Version: 0.101.2+dfsg-0+deb9u1

Explanation: new upstream stable release

Bug#935474: buster-pu: package xymon/4.3.28-5+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2019-08-23 at 01:49 +0200, Axel Beckert wrote:
> The Debian Security Team decided to not issue a security update for
> these CVE IDs:
> 
> * CVE-2019-13451: service overflows histlogfn in history.c.
> * CVE-2019-13452: service overflows histlogfn in reportlog.c.
> * CVE-2019-13273: srdb overflows dbfn in csvinfo.c.
> * CVE-2019-13274: reflected XSS in csvinfo.c.
> * CVE-2019-13455: htmlquoted(hostname) overflows msgline in
>   acknowledge.c.
> * CVE-2019-13484: htmlquoted(xymondreq) overflows errtxt appfeed.c.
> * CVE-2019-13485: hostname overflows selfurl in history.c.
> * CVE-2019-13486: htmlquoted(xymondreq) overflows errtxt in
>   svcstatus.c.
> 
> Hence I propose to do these as a normal stable update.
> 

Please go ahead.

Regards,

Adam

Bug#935473: stretch-pu: package xymon/4.3.28-2+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2019-08-23 at 01:46 +0200, Axel Beckert wrote:
> 
> The Debian Security Team decided to not issue a security update for
> these CVE IDs:
> 
> * CVE-2019-13451: service overflows histlogfn in history.c.
> * CVE-2019-13452: service overflows histlogfn in reportlog.c.
> * CVE-2019-13273: srdb overflows dbfn in csvinfo.c.
> * CVE-2019-13274: reflected XSS in csvinfo.c.
> * CVE-2019-13455: htmlquoted(hostname) overflows msgline in
>   acknowledge.c.
> * CVE-2019-13484: htmlquoted(xymondreq) overflows errtxt appfeed.c.
> * CVE-2019-13485: hostname overflows selfurl in history.c.
> * CVE-2019-13486: htmlquoted(xymondreq) overflows errtxt in
>   svcstatus.c.
> 
> Hence I propose to do these as a normal stable update.
> 

Please go ahead.

Regards,

Adam

Bug#935487: gforth: Packaged gforth version is very old.

[Stéphane Fillion]

Package: gforth
Version: 0.7.3+dfsg-9
Severity: wishlist

Hi.

Package gforth contains version 0.7.3. This is the last official version
released by upstream developers. This version is many years old and development
of the software continued even if they did not make any official release.
Gforth 0.7.3 lacks many features provided by today's gforth.

However, the gforth developers regularly release development snapshots. Last
one is gforth 0.7.9_20190822. These snapshots are much more up to date and the
packaged gforth version is now mainly useful for bootstrapping a snapshot, and
then use the snapshot.

I think there may be a few ways a newer version of gforth can be made available
in Debian:

a) Make the gforth package follow the snapshots instead of the official
releases;
b) Create a second package named something like gforth-snapshot or similar;
c) Option b but put gforth-snapshot in experimental instead;
d) Something else.

Are any of these solutions workable?

Please forgive me if I didn't use the proper channel to express these concerns.

sf.



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

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

Versions of packages gforth depends on:
ii  emacsen-common  3.0.4
ii  gforth-common   0.7.3+dfsg-9
ii  gforth-lib  0.7.3+dfsg-9
ii  libc6   2.29-0ubuntu2
ii  libltdl72.4.6-10

gforth recommends no packages.

gforth suggests no packages.

-- no debconf information

Bug#487300: debconf: preseeding values for questions with template of other name (from dbconfig-common)

[Sunil Mohan Adapa]

Hello,

This bug due to an assumption that template name would be the same as
the question name in debconf-set-selections. The database get corrupted
as a result requiring the run of fix_db.pl.

The attached patch fixes the problem and ensures that database does not
get corrupted. Please consider applying the patch.

Thank you,

-- 
Sunil
From 13d511b549c08f14706146c8377fcb7863774041 Mon Sep 17 00:00:00 2001
From: Sunil Mohan Adapa 
Date: Thu, 22 Aug 2019 21:33:15 -0700
Subject: [PATCH] Fix setting answers when template name is not same as
 question

When setting answers to a questions, question may exist and its template may
exist with a different name. For example, question could be tt-rss/database-type
and template could be dbconfig-common/database-type. In such cases, ensure that
a dummy template is not created with the name of the question.

This fixes database inconsistency introduced otherwise. Closes #487300.

Signed-off-by: Sunil Mohan Adapa 
---
 debconf-set-selections | 27 +--
 1 file changed, 21 insertions(+), 6 deletions(-)

diff --git a/debconf-set-selections b/debconf-set-selections
index 7d99a306..a1b1a783 100755
--- a/debconf-set-selections
+++ b/debconf-set-selections
@@ -116,17 +116,32 @@ sub load_answer {
 	info "Loading answer for '$label'";
 
 	# Set up the template.
-	my $template=Debconf::Template->get($label);
-	if (! $template) {
-		$template=Debconf::Template->new($label, $owner, $type);
-		$template->description("Dummy template");
-		$template->extended_description("This is a fake template used to pre-seed the debconf database. If you are seeing this, something is probably wrong.");
+	my $template;
+	my $question=Debconf::Question->get($label);
+	if ($question) {
+		# Question may already exist and its template may exist with a
+		# different name. For example, question could be
+		# tt-rss/database-type and template could be
+		# dbconfig-common/database-type. Retrieve the template using the
+		# question if it exists.
+		$template=$question->template;
+	}
+	else {
+		# If question does not exist, try to retrieve a template with
+		# same name as the question. If it does not exist, create a
+		# dummy template as a last resort.
+		$template=Debconf::Template->get($label);
+		if (! $template) {
+			$template=Debconf::Template->new($label, $owner, $type);
+			$template->description("Dummy template");
+			$template->extended_description("This is a fake template used to pre-seed the debconf database. If you are seeing this, something is probably wrong.");
+		}
 	}
 	$template->type($type);
 	
 	# The question should already exist, it was created along with the
 	# template. Set it up.
-	my $question=Debconf::Question->get($label);
+	$question=Debconf::Question->get($label);
 	if (! $question) {
 		error("Cannot find a question for $label");
 		return;
-- 
2.20.1



signature.asc
Description: OpenPGP digital signature

Bug#935486: quicksynergy: Depends on synergy which is due to be removed (Obsolete libs)

[Scott Kitterman]

Package: quicksynergy
Version: 0.9-2
Severity: serious
Justification: Policy 3.5

If synergy is going to be removed is there any reason to keep this
package?  I suspect someone ought to file an rm bug.

Scott K

Bug#935485: RFS: kcollectd/0.10-1 ITA -- simple collectd graphing front-end for KDE

[Antonio Russo]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for the very recently removed kcollectd package.
It was removed because it required Qt4. I ported this to Qt5 several months
ago, and mentioned this in the bug report [1]. I suppose that original bug
report should have been accompanied by an ITA WNPP bug. I've also fixed
some longstanding bugs [2].

The new upstream (which I maintain) is only a few extra commits on top of
the old release, and is available at gitlab [3]. The Debian packaging is
on salsa [4], and the source packages have been uploaded to mentors [5] [6].

Thank you,
Antonio Russo

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927455
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814935
[3] https://gitlab.com/aerusso/kcollectd
[4] https://salsa.debian.org/aerusso-guest/kcollectd
[5] https://mentors.debian.net/package/kcollectd
[6] dget -x 
https://mentors.debian.net/debian/pool/main/k/kcollectd/kcollectd_0.10.0-1.dsc

Bug#935313: missing ebtables dependency

[Gabriel Filion]

Hello,

On Wed, 21 Aug 2019 10:16:26 -0400 Antoine Beaupre 
wrote:
> Vagrant, using the libvirt backend, started failing me recently, with
> something like this:
> 
> anarcat@curie:stretch64(master)$ vagrant up --provider libvirt
> Bringing machine 'default' up with 'libvirt' provider...
> ==> default: Checking if box 'debian/stretch64' version '9.9.0' is up to 
> date...
> Error while activating network: Call to virNetworkCreate failed: internal 
> error: Failed to initialize a valid firewall backend.
> [1]anarcat@curie:stretch64(master)$ 

> Restarting libvirtd, however, did provide some insightful input:
> 
> [...]
> aoû 21 10:10:05 curie systemd[1]: Started Virtualization daemon.
> aoû 21 10:10:05 curie libvirtd[31223]: direct firewall backend requested, but 
> /usr/sbin/ebtables is not available: Aucun fichier ou dossier de ce type
> aoû 21 10:10:05 curie libvirtd[31223]: internal error: Failed to initialize a 
> valid firewall backend

fwiw I'm running vagrant + libvirt + vagrant-libvirt in debian sid and I
don't have the ebtables package installed. networking is still functioning.

Since buster, nftables is now used by default. the iptables package is
now installing nftables wrappers so that one is not mixing nftables with
iptables kernel subsystems.

# update-alternatives --list ebtables
/usr/sbin/ebtables-nft

$ dpkg -S /usr/sbin/ebtables-nft
iptables: /usr/sbin/ebtables-nft

that would explain why the libvirt package does not depend on the
ebtables package.


is it possible that your "alternative" for ebtables was somehow blasted
out? e.g. if you try removing the ebtables package and then running:

# update-alternatives --set ebtables /usr/sbin/ebtables-nft

does it make your libvirt setup function properly?

if so, then maybe you might want to check other "alternatives" provided
by iptables so that they use the nftables wrappers. Here's what I have
on my system:

$ ls -l /etc/alternatives/|grep -- -nft
lrwxrwxrwx 1 root root  23 Dec 22  2018 arptables -> /usr/sbin/arptables-nft
lrwxrwxrwx 1 root root  31 Dec 22  2018 arptables-restore ->
/usr/sbin/arptables-nft-restore
lrwxrwxrwx 1 root root  28 Dec 22  2018 arptables-save ->
/usr/sbin/arptables-nft-save
lrwxrwxrwx 1 root root  22 Dec 22  2018 ebtables -> /usr/sbin/ebtables-nft
lrwxrwxrwx 1 root root  30 Dec 22  2018 ebtables-restore ->
/usr/sbin/ebtables-nft-restore
lrwxrwxrwx 1 root root  27 Dec 22  2018 ebtables-save ->
/usr/sbin/ebtables-nft-save
lrwxrwxrwx 1 root root  23 Dec 22  2018 ip6tables -> /usr/sbin/ip6tables-nft
lrwxrwxrwx 1 root root  31 Dec 22  2018 ip6tables-restore ->
/usr/sbin/ip6tables-nft-restore
lrwxrwxrwx 1 root root  28 Dec 22  2018 ip6tables-save ->
/usr/sbin/ip6tables-nft-save
lrwxrwxrwx 1 root root  22 Dec 22  2018 iptables -> /usr/sbin/iptables-nft
lrwxrwxrwx 1 root root  30 Dec 22  2018 iptables-restore ->
/usr/sbin/iptables-nft-restore
lrwxrwxrwx 1 root root  27 Dec 22  2018 iptables-save ->
/usr/sbin/iptables-nft-save

Cheers!



signature.asc
Description: OpenPGP digital signature

Bug#935484: brltty flooding syslog with error messages - DBus error: send message: org.freedesktop.DBus.Error.NoReply

[skyguide]

Package: brltty
Version: 5.6-10
Severity: important

brltty is flooding syslog with error messages.

brltty[422]: brltty: DBus error: send message: 
org.freedesktop.DBus.Error.TimedOut: Failed to activate service 'org.bluez': 
timed out (service_start_timeout=25000ms
brltty[422]: DBus error: send message: org.freedesktop.DBus.Error.NoReply: Did 
not receive a reply. Possible causes include: the remote application did not 
send a reply, the message bus security policy blocked the reply, the reply 
timeout expired, or the network connection was broken
brltty[422]: brltty: DBus error: send message: 
org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes 
include: the remote application did not send a reply, the message bus security 
policy blocked the reply, the reply timeout expired, or the network connection 
was broken

Those messages keeps spamming /var/log/syslog casing it to grow aoutof control.

Please note that this happens on a fresh/new install of Debian 10 Buster, on a 
hardware with no bluetooth hardware installed.

Please advise how this can be stopped/corrected. 



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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
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 brltty depends on:
ii  libasound2 1.1.8-1
ii  libbluetooth3  5.50-1
ii  libbrlapi0.6   5.6-10
ii  libc6  2.28-10
ii  libdbus-1-31.12.16-1
ii  libglib2.0-0   2.58.3-2
ii  libgpm21.20.7-5
ii  libicu63   63.1-6
ii  liblouis17 3.8.0-2
ii  libncursesw6   6.1+20181013-2
ii  libpolkit-gobject-1-0  0.105-25
ii  libsystemd0241-5
ii  libtinfo6  6.1+20181013-2
ii  lsb-base   10.2019051400
ii  policykit-10.105-25

Versions of packages brltty recommends:
ii  python  2.7.16-1

Versions of packages brltty suggests:
pn  brltty-speechd   
pn  brltty-x11   
pn  console-braille  

-- no debconf information

Bug#935483: ITP: johnny -- GUI front-end for John the Ripper

[Michael Cordingley]

Package: wnpp
Severity: wishlist
Owner: Michael Cordingley 

* Package name: johnny
  Version : 2.2
  Upstream Author : Shinnok 
* URL : https://openwall.info/wiki/john/johnny
* License : BSD-2-clause
  Programming Lang: C++
  Description : GUI front-end for John the Ripper

Overview

Johnny the open source cross-platform GUI frontend for John the Ripper, the
popular password cracker, written in C++ using the Qt framework.

Johnny's aim is to automate and simplify the password cracking routine on the
Desktop as well as add extra functionality like session management and easy
hash/password management, on top of the immense capabilities and features
offered by John the Ripper.

The application uses John The Ripper for the actual work, thus it needs to be
installed on your system. Official core (proper) version and the
community-enhanced version (jumbo) are both supported. The latter exposes more
functionality like extra cracking modes and hash types support.

To download official binary redistributables and find more about Johnny visit:
http://openwall.info/wiki/john/johnny

Rationale

This package is useful for penetration testers and is used downstream by Kali.
I will need a sponsor and a mentor for taking proper care of it. Furthermore,
the package appears to fit in with the explicit goals of the pkg-security team.
The plan is that this would be a low-impact and low-maintenance package with
which to wet my feet on helping out the Debian project.

Bug#935390: RFS: vnstat/2.4-1 [NMU] [ITA]

[Rob Savoury]

Hi Sven,

Teemu (vnstat dev) was kind enough to write me a lengthy and helpful
commentary today on the situation relative vnstat. He pointed out
various inconsistencies in the way I have presented the package (and
also confusion from me sending two initial two emails, Teemu mentioned
that policy says a new RFS should only come after the 21 days -- my
apologies for being too quick on that without clear grasp of all the
Debian policies).

So I have removed the package from mentors and will work on gaining a
fuller understanding of the correct way to package vnstat for Debian
over the coming weeks. With the quite detailed analysis given me by
Teemu, relative patches, possible closing of bugs (if a version v2.x
moves into the Debian repositories) and tips about correct ways to make
the package, there is much for me to learn!

In any case, thank you again for your response and attention to my
(unintended) slightly incorrect approach relative the intention of
getting a newer vnstat into Debian repos.

-Rob

On 08/22/2019 03:10 AM, Rob Savoury wrote:
> Hi Sven,
> 
> Thanks for the reply. Spent the whole day (and evening!) doing my best
> to go through all the necessary steps to learn how to create a reliable
> first Debian package, but guess I'm not totally surprised it is not
> quite correct somehow!
> 
> In any case, along with the RFS another email sent was an "ITS: vnstat"
> [1] due this package qualifying for salvaging. So my intent is actually
> to move towards being maintainer of vnstat (starting out with sponsored
> maintainership, of course). That was actually Teemu (the developer's)
> suggestive prompt to me in an email yesterday (after I alerted him to a
> minor cosmetic bug in vnstat and he alerted me to the situation of the
> vnstat package in Debian apparently having a "MIA" maintainer).
> 
> The very problem appears to be a one year lack of any sign of activity
> from Christian relative this package, so that's why the ITS and RFS from
> me today. My understanding is that a three week window is given for the
> maintainer to respond to an ITS so we will see if Christian returns into
> some communication about vnstat during that time. Until then, I'll keep
> brushing up on my new learning with the whole complexity of the Debian
> packaging process!
> 
> Thanks,
> Rob
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935391
> 
> 
> On 08/22/2019 02:45 AM, Sven Hoexter wrote:
>> On Thu, Aug 22, 2019 at 01:26:35AM -0700, Rob Savoury wrote:
>>
>> Hey Rob,
>>
>>> Changes since the last upload:
>>>
>>>* New upstream version 2.4
>>>  .
>>>* debian/patches/
>>>+ drop patch applied upstream (timeout for restart)
>>>+ modify pidfile and systemd patches for new source files
>>>* d/control: bump to std version 4.4.0 and add libsqlite3-dev BD (vnstat 
>>> 2.x)
>>
>> While I value the work, this is not properly packaged as an NMU.
>> I uploaded the last NMU by Teemu because it made perfectly sense to upload
>> those changes which were already implemented by Christian Göttsche. But 
>> Christian
>> is still the maintainer of the package as far as I can tell.
>>
>> So would be nice to have an ACK from him if such kind of informal team 
>> uploads
>> are ok. And beside of that NMUs which implement major version changes are 
>> mostly
>> an exception. I would prefer either some team upload or some notice by 
>> Christian
>> how he intents to handle this package.
>>
>> Sven
>>
>>

Bug#935482: RM: supybot -- ROM; superceded by limnoria

[James McCoy]

Package: ftp.debian.org
Severity: normal

Supybot is Python 2 only and not maintained.  Limnoria is a maintained,
Python 3 fork of Supybot.  The last supybot upload, which was part of
Buster, shipped a NEWS file to communicate this to the users.

Bullseye shouldn't ship with supybot.

Bug#935481: stretch-pu: package basez/1.6-3

[Milan Kupcevic]

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

Hi Stable Release Managers,

The basez version released in stretch is affected by bug #931041 and is 
consequently not properly decoding base64url stream. This bug has been 
fixed in sid, testing and buster-pu. I'm about to upload fixed 
basez/1.6-3+deb9u1 package for stretch. See attached debdiff.

Milan
diff -Nru basez-1.6/debian/changelog basez-1.6/debian/changelog
--- basez-1.6/debian/changelog  2016-10-27 09:33:37.0 -0400
+++ basez-1.6/debian/changelog  2019-08-22 22:07:39.0 -0400
@@ -1,3 +1,9 @@
+basez (1.6-3+deb9u1) stretch; urgency=medium
+
+  * Properly decode base64url encoded strings (closes: #931041)
+
+ -- Milan Kupcevic   Thu, 22 Aug 2019 22:07:39 -0400
+
 basez (1.6-3) unstable; urgency=medium
 
   * Remove configure getconf libs.
diff -Nru basez-1.6/debian/patches/base64url-decode-bug-931041 
basez-1.6/debian/patches/base64url-decode-bug-931041
--- basez-1.6/debian/patches/base64url-decode-bug-9310411969-12-31 
19:00:00.0 -0500
+++ basez-1.6/debian/patches/base64url-decode-bug-9310412019-08-03 
23:29:13.0 -0400
@@ -0,0 +1,16 @@
+Description: properly decode base64url encoded strings
+Author: Milan Kupcevic 
+Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931041
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/base64.c
 b/base64.c
+@@ -188,7 +188,7 @@
+   bout[0] = bout[0] | c[bin[1]] >> 4;
+   }
+ 
+-  switch(c64d[bin[2]])
++  switch(c[bin[2]])
+   {
+ case 0xfe:
+   if(bin[3] == '=')
diff -Nru basez-1.6/debian/patches/series basez-1.6/debian/patches/series
--- basez-1.6/debian/patches/series 1969-12-31 19:00:00.0 -0500
+++ basez-1.6/debian/patches/series 2019-08-03 22:15:31.0 -0400
@@ -0,0 +1 @@
+base64url-decode-bug-931041

Bug#934053: RFS: fwlogwatch/1.4-2

[tony mancill]

On Tue, Aug 06, 2019 at 10:12:08AM -0300, William Grzybowski wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> fwlogwatch (1.4-2) unstable; urgency=medium

Hi William,

Thank you for helping with fwlogwatch.  I've taken a look at your
updated package and things look really good.  I noticed a couple minor
issues in the manpage I wanted to suggest you address before we upload.

- The configuration file is found in /etc/fwlogwatch/fwlogwatch.config,
  not in /etc/fwlogwatch.config.

- The pid file is now in /run/fwlogwatch.pid, not /var/run/fwlogwatch.pid

Cheers,
tony


signature.asc
Description: PGP signature

Bug#935480: buster-pu: package initramfs-tools/0.133+deb10u1

[Ben Hutchings]

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

* Fix a regression that leads to a 30 second delay at boot if certain
  types of swap device are used (#916696).

* Fix a confusing boot progress message on systems using plymouth in text
  mode, which is currently the default (#928736).

* Fix a regression that prevents building an initramfs on systems using
  fsprotect (#928689).

* Fix lsinitramfs and unmkinitramfs when using lz4 compression (#930366).

* Fix outdated text in the update-initramfs manual page (#930366).

* Fix warning when building an initramfs using bzip2 or lzma compression
  (#930754).

* Include drivers needed for booting on some Chromebook models.

Ben.

diff -Nru initramfs-tools-0.133/debian/changelog 
initramfs-tools-0.133+deb10u1/debian/changelog
--- initramfs-tools-0.133/debian/changelog  2019-02-06 20:13:59.0 
+
+++ initramfs-tools-0.133+deb10u1/debian/changelog  2019-08-23 
02:16:37.0 +0100
@@ -1,3 +1,30 @@
+initramfs-tools (0.133+deb10u1) buster; urgency=medium
+
+  [ Ben Hutchings ]
+  * [998371a] hooks/resume: Disable resume when there are no suitable swap
+devices. Thanks to Trek  (Closes: #916696)
+  * [d653197] hook-functions: Include all keyboard driver modules when
+MODULES=most. Thanks to Alper Nebi Yasak 
+  * [5681ccb] hook-functions: Include cros_ec_spi and SPI drivers when
+MODULES=most. Thanks to Alper Nebi Yasak 
+  * [8d62542] resume: Set plymouth status only if there is a suspend image
+(Closes: #928736)
+  * [073586a] hook-functions: Fix copy_file with target of "/bin"
+(Closes: #928689)
+  * [a78d9a5] unmkinitramfs: Work around lz4cat filename check.
+Thanks to Dimitri John Ledkov  (Closes: #930366)
+  * [48a35de] update-initramfs(8): Update description of "-k all" option
+
+  [ Alper Nebi Yasak ]
+  * [1abb6f6] hook-functions: Include extcon-usbc-cros-ec when MODULES=most
+  * [db6d4e2] hook-functions: Include extcon drivers when MODULES=dep
+
+  [ Uwe Kleine-König ]
+  * [360fb48] mkinitramfs: suppress warning when using bzip2 or lzma
+(Closes: #930754)
+
+ -- Ben Hutchings   Fri, 23 Aug 2019 02:16:37 +0100
+
 initramfs-tools (0.133) unstable; urgency=medium
 
   [ Ben Hutchings ]
diff -Nru initramfs-tools-0.133/hook-functions 
initramfs-tools-0.133+deb10u1/hook-functions
--- initramfs-tools-0.133/hook-functions2019-02-06 03:48:49.0 
+
+++ initramfs-tools-0.133+deb10u1/hook-functions2019-08-23 
02:11:27.0 +0100
@@ -124,15 +124,15 @@
 
[ -f "${src}" ] || return 2
 
+   if [ -d "${DESTDIR}/${target}" ]; then
+   target="${target}/${src##*/}"
+   fi
+
# Canonicalise usr-merged target directories
case "${target}" in
/bin/* | /lib* | /sbin/*) target="/usr${target}" ;;
esac
 
-   if [ -d "${DESTDIR}/${target}" ]; then
-   target="${target}/${src##*/}"
-   fi
-
# check if already copied
[ -e "${DESTDIR}/${target}" ] && return 1
 
@@ -449,7 +449,7 @@
fi
 
# sys walk some important device classes
-   for class in gpio phy regulator rtc; do
+   for class in extcon gpio phy regulator rtc; do
for device in "/sys/class/$class"/*; do
device="$(readlink -f "$device")" \
&& sys_walk_mod_add "$device"
@@ -538,15 +538,17 @@
copy_modules_dir kernel/drivers/usb/musb
copy_modules_dir kernel/drivers/usb/renesas_usbhs
# and any extcon drivers for USB
-   modules="$modules extcon-usb-gpio"
+   modules="$modules extcon-usb-gpio extcon-usbc-cros-ec"
# Add the axp20x_usb_power power supply driver,
# required to initialize the USB host controllers
# on a number of armhf systems
modules="$modules axp20x_usb_power"
 
-   # Include all HID drivers unless we're sure they
-   # don't support keyboards.  hid-*ff covers various
-   # game controllers with force feedback.
+   # Include all keyboard drivers and all HID drivers
+   # unless we're sure they don't support keyboards.
+   # hid-*ff covers various game controllers with
+   # force feedback.
+   copy_modules_dir kernel/drivers/input/keyboard
copy_modules_dir kernel/drivers/hid \
'hid-*ff.ko' hid-a4tech.ko hid-cypress.ko \
hid-dr.ko hid-elecom.ko hid-gyration.ko \
@@ -560,6 +562,8 @@
hid-speedlink.ko hid-tivo.ko hid-twinhan.ko \
hid-uclogic.ko hid-wacom.ko hid-waltop.ko \

Bug#935479: buster-pu: package firmware-nonfree/20190114-2

[Ben Hutchings]

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

* Fix a longstanding bug that affects use of plymouth on systems with
  AMD GPUs (#928510).  Depending on the order of package installation,
  the initramfs might include the graphics driver but not firmware,
  resulting in the driver loading but not working.  Since plymouth is
  now installed by default as part of the "desktop" task, this affects
  many users.

  The fix is to trigger an initramfs build on installation of
  firmware-amd-graphics, as was already done from most packages
  containing firmware that might be needed in the initramfs.

* When I reviewed which of the binary packages did this, I noticed
  that firmware-cavium and firmware-netronome should also do so in
  case they are used for net-booting.  I applied the same fix to them.

* Revert an update to the QCA9377 firmware which seems to be
  incompatible with older kernel versions (#919632), and add a new
  version with a different filename that is preferred by the driver
  in Linux 4.19 (#903437, #919632, #927917).

* Add several new firmware files requested by drivers in Linux 4.19
  (#919452, #928672).

Ben.

diff -Nru firmware-nonfree-20190114/debian/changelog 
firmware-nonfree-20190114/debian/changelog
--- firmware-nonfree-20190114/debian/changelog  2019-01-15 22:51:01.0 
+
+++ firmware-nonfree-20190114/debian/changelog  2019-08-23 02:04:48.0 
+0100
@@ -1,3 +1,25 @@
+firmware-nonfree (20190114-2) buster; urgency=medium
+
+  [ Ben Hutchings ]
+  * Update to linux-support 4.19.0-5
+  * amd-graphics: Trigger update-initramfs when installed (Closes: #928510)
+  * cavium, netronome: Trigger update-initramfs when installed
+  * atheros: Add Qualcomm Atheros QCA9377 rev 1.0 firmware version
+WLAN.TF.2.1-00021-QCARMSWP-1 (Closes: #903437, #919632, #927917)
+  * realtek: Add Realtek RTL8822CU Bluetooth firmware
+  * atheros: Revert change of QCA9377 rev 1.0 firmware in 20180518-1
+(Closes: #919632)
+
+  [ Raphaël Hertzog ]
+  * misc-nonfree: Add firmware for MediaTek MT76x0/MT76x2u wireless chips
+(Closes: #919452)
+  * misc-nonfree: Add firmware for MediaTek MT7622/MT7668 bluetooth chips
+
+  [ Romain Perier ]
+  * misc-nonfree: Add GV100 signed firmware (Closes: #928672)
+
+ -- Ben Hutchings   Fri, 23 Aug 2019 02:04:48 +0100
+
 firmware-nonfree (20190114-1) unstable; urgency=medium
 
   [ Romain Perier ]
diff -Nru firmware-nonfree-20190114/debian/config/amd-graphics/defines 
firmware-nonfree-20190114/debian/config/amd-graphics/defines
--- firmware-nonfree-20190114/debian/config/amd-graphics/defines
2019-01-15 22:37:03.0 +
+++ firmware-nonfree-20190114/debian/config/amd-graphics/defines
2019-07-28 19:45:53.0 +0100
@@ -529,6 +529,7 @@
  radeon/verde_rlc.bin
  radeon/VERDE_smc.bin
  radeon/verde_smc.bin
+support: initramfs-tools
 
 [amdgpu/banks_k_2_smc.bin_base]
 desc: "Banks" K-2 SMC microcode
Binary files 
/var/tmp/5WQFaKfizp/firmware-nonfree-20190114/debian/config/atheros/ath10k/QCA9377/hw1.0/firmware-5.bin
 and 
/var/tmp/GBKOxvr1XD/firmware-nonfree-20190114/debian/config/atheros/ath10k/QCA9377/hw1.0/firmware-5.bin
 differ
diff -Nru firmware-nonfree-20190114/debian/config/atheros/defines 
firmware-nonfree-20190114/debian/config/atheros/defines
--- firmware-nonfree-20190114/debian/config/atheros/defines 2019-01-15 
02:02:27.0 +
+++ firmware-nonfree-20190114/debian/config/atheros/defines 2019-07-28 
19:49:52.0 +0100
@@ -35,6 +35,7 @@
  ath10k/QCA9377/hw1.0/board.bin
  ath10k/QCA9377/hw1.0/board-2.bin
  ath10k/QCA9377/hw1.0/firmware-5.bin
+ ath10k/QCA9377/hw1.0/firmware-6.bin
  ath10k/QCA9887/hw1.0/board.bin
  ath10k/QCA9887/hw1.0/firmware-5.bin
  ath10k/QCA9888/hw2.0/board-2.bin
@@ -211,7 +212,11 @@
 
 [ath10k/QCA9377/hw1.0/firmware-5.bin_base]
 desc: Qualcomm Atheros QCA9377 rev 1.0 firmware
-version: WLAN.TF.1.0-2-QCATFSWPZ-5
+version: WLAN.TF.1.0-00267-1
+
+[ath10k/QCA9377/hw1.0/firmware-6.bin_base]
+desc: Qualcomm Atheros QCA9377 rev 1.0 firmware
+version: WLAN.TF.2.1-00021-QCARMSWP-1
 
 [ath10k/QCA9887/hw1.0/board.bin_base]
 desc: Qualcomm Atheros QCA9887 rev 1.0 board configuration
diff -Nru firmware-nonfree-20190114/debian/config/cavium/defines 
firmware-nonfree-20190114/debian/config/cavium/defines
--- firmware-nonfree-20190114/debian/config/cavium/defines  2019-01-15 
02:02:27.0 +
+++ firmware-nonfree-20190114/debian/config/cavium/defines  2019-07-28 
19:20:32.0 +0100
@@ -8,6 +8,7 @@
  liquidio/lio_410nv_nic.bin
 longdesc: Cavium crypto and Ethernet adapters supported by the nitrox and
  liquidio drivers
+support: initramfs-tools
 
 [cavium/cnn55xx_se.fw_base]
 desc: Cavium CNN55XX firmware
diff -Nru firmware-nonfree-20190114/debian/config/misc-nonfree/defines 
firmware-nonfree-20190114/debian/config/misc-nonfree/defines
--- firmware-nonfree-20190114/debian/config/misc-nonfree/defines   

Bug#935478: RM: txfixtures -- RoQA; incompatible with python3.7; low popcon; not in testing since ~1000 days

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

please remove txfixtures

Bug#935477: python-xapp: diff for NMU version 1.2.0-2.1

[Sandro Tosi]

Package: python-xapp
Version: 1.2.0-2
Severity: normal
Tags: patch  pending


Dear maintainer,

I've prepared an NMU for python-xapp (versioned as 1.2.0-2.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

This drop the python 2 package (rdep of python-psutil)

Regards.

diff -Nru python-xapp-1.2.0/debian/changelog python-xapp-1.2.0/debian/changelog
--- python-xapp-1.2.0/debian/changelog	2018-08-07 08:51:37.0 -0400
+++ python-xapp-1.2.0/debian/changelog	2019-08-22 21:15:23.0 -0400
@@ -1,3 +1,10 @@
+python-xapp (1.2.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop Python 2 support
+
+ -- Sandro Tosi   Thu, 22 Aug 2019 21:15:23 -0400
+
 python-xapp (1.2.0-2) unstable; urgency=medium
 
   * New revision
diff -Nru python-xapp-1.2.0/debian/control python-xapp-1.2.0/debian/control
--- python-xapp-1.2.0/debian/control	2018-08-07 08:51:37.0 -0400
+++ python-xapp-1.2.0/debian/control	2019-08-22 20:59:29.0 -0400
@@ -9,8 +9,6 @@
 Build-Depends:
  debhelper (>= 11~),
  dh-python,
- python-all (>= 2.6.6-3~),
- python-psutil,
  python3-all,
  python3-psutil,
 Standards-Version: 4.1.4
@@ -18,12 +16,6 @@
 Vcs-Browser: https://salsa.debian.org/cinnamon-team/python-xapp
 Vcs-Git: https://salsa.debian.org/cinnamon-team/python-xapp.git
 
-Package: python-xapp
-Architecture: all
-Depends: python-psutil, ${misc:Depends}, ${python:Depends}
-Description: Python 2 XApp library
- This package contains the Python 2 version of the library.
-
 Package: python3-xapp
 Architecture: all
 Depends: python3-psutil, ${misc:Depends}, ${python3:Depends}
diff -Nru python-xapp-1.2.0/debian/not-installed python-xapp-1.2.0/debian/not-installed
--- python-xapp-1.2.0/debian/not-installed	2018-08-07 08:51:37.0 -0400
+++ python-xapp-1.2.0/debian/not-installed	2019-08-22 21:09:29.0 -0400
@@ -1,3 +1 @@
 *.pyc
-# Moved to python3
-usr/lib/python3.*/
diff -Nru python-xapp-1.2.0/debian/python3-xapp.install python-xapp-1.2.0/debian/python3-xapp.install
--- python-xapp-1.2.0/debian/python3-xapp.install	2018-08-07 08:51:37.0 -0400
+++ python-xapp-1.2.0/debian/python3-xapp.install	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-usr/lib/python3*
diff -Nru python-xapp-1.2.0/debian/python-xapp.install python-xapp-1.2.0/debian/python-xapp.install
--- python-xapp-1.2.0/debian/python-xapp.install	2018-08-07 08:51:37.0 -0400
+++ python-xapp-1.2.0/debian/python-xapp.install	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-usr/lib/python2*
diff -Nru python-xapp-1.2.0/debian/rules python-xapp-1.2.0/debian/rules
--- python-xapp-1.2.0/debian/rules	2018-08-07 08:51:37.0 -0400
+++ python-xapp-1.2.0/debian/rules	2019-08-22 20:59:38.0 -0400
@@ -1,4 +1,4 @@
 #!/usr/bin/make -f
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild

Bug#923393: CONFIG_DRM_I915_GVT_KVMGT is not enabled

[Markus Huber]

IMHO, KVMGT should be enabled as soon as possible.

Since the modules would not be loaded by default and the user have explicit to 
enable it, i see more benefits.

I've tested a scenario with a precompiled "MainlineBuilds" kernel 
(5.3.0-050300rc5-generic #201908182231) from Ubuntu on my Debian sid system 
(with Intel HD 530 Skylake):

- After loading "modprobe kvmgt", i've got 2 types:

  root@nietzsche:~# cat 
/sys/devices/pci\:00/\:00\:02.0/mdev_supported_types/i915-GVTg_V5_*/description
  low_gm_size: 128MB
  high_gm_size: 512MB
  fence: 4
  resolution: 1920x1200
  weight: 4
  low_gm_size: 64MB
  high_gm_size: 384MB
  fence: 4
  resolution: 1024x768
  weight: 2

- Since i don't use a remote protocol (as spice), i tried this one:

  https://github.com/intel/gvt-linux/wiki/Dma_Buf_User_Guide
  "A new feature called “Local display” has been supported in GVT-g (KVMGT 
only) by introducing “dma-buf”, a generic kernel level frame work to share 
buffers."

- My testing scenario: run Libreelec (Kodi) in a qemu-kvm container - and it 
works...

  To do this (first enable enable_gvt, load modules, create vGPU [1]), give the 
user privileges:
  markus@nietzsche:~$ cat /etc/udev/rules.d/10-qemu.rules
SUBSYSTEM=="vfio", OWNER="root", GROUP="kvm"

- Start qemu from commandline:

kvm -hda ./kodi.img \
  -boot c -m 2G \
  -vga none \
  -display gtk,gl=on \
  -soundhw ac97 \
  -smp cores=4,threads=2,sockets=1 \
  -enable-kvm \
  -cpu host \
  -device 
vfio-pci,sysfsdev=/sys/bus/pci/devices/\:00\:02.0/a297db4a-f4c2-11e6-90f6-d3b88d6c9525,display=on,x-igd-opregion=on,driver=vfio-pci-nohotplug,ramfb=on

- Libreelec output sysinfo:
  GPU: Mesa DRI Intel(R) HD Graphics 530 (Skylake GT2) [...]

  The performance playing a full-hd video is about 60% less CPU usage comparing 
to virgl!!!

* Problems:
- When using the higher resolution (1920x1200 in my case), the VM freezes with 
"RLIMIT_MEMLOCK (67108864) exceeded"
  dirty fix - set memlock to 1GB for specific user [2]:
  root@nietzsche:~# cat /etc/security/limits.d/99-memlock.conf
markus hard memlock 1048576
markus soft memlock 1048576
- The resolution isn't flexible - maybe on Linux guests, this could be fixed 
via xorg (or wayland?) [3]
- After shutdown a VM using GVT-g (Dma_Buf) and restart another VM without 
kvmgt, the CPU-usage is very high! Removing the module is solving this (but i 
don't know, if this just happens, because I've tested it in a weird environment 
Debian sid with an Ubuntu maintainer kernel).
- For Linux guests, it seems, this is only working with an compatible kernel 
also on the guest side...

So, i think, it should be enabled in the default kernel, because it has great 
benefits!
On the other side: there are some problems... but the user should have the 
possibility to activate the modules and test it! The modules have to enabled 
manually - and in combination with spice, it seems to be more stable than with 
the newer "dma-buf"-mode!

Thanks,
Markus



[1] https://wiki.archlinux.org/index.php/Intel_GVT-g
[2] 
https://stackoverflow.com/questions/39187619/vfio-dma-map-error-when-passthrough-gpu-using-libvirt
[3] https://github.com/intel/gvt-linux/issues/44

Bug#935476: pg-activity: diff for NMU version 1.4.0-1.1

[Sandro Tosi]

Package: pg-activity
Version: 1.4.0-1
Severity: normal
Tags: patch  pending


Dear maintainer,

I've prepared an NMU for pg-activity (versioned as 1.4.0-1.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

This switch to use python3

Regards.

diff -Nru pg-activity-1.4.0/debian/changelog pg-activity-1.4.0/debian/changelog
--- pg-activity-1.4.0/debian/changelog	2017-12-06 17:18:10.0 -0500
+++ pg-activity-1.4.0/debian/changelog	2019-08-22 20:33:47.0 -0400
@@ -1,3 +1,12 @@
+pg-activity (1.4.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop Python 2 support + use pybuild
+  * debian/control
+- remove obsolete X-P-V field
+
+ -- Sandro Tosi   Thu, 22 Aug 2019 20:33:47 -0400
+
 pg-activity (1.4.0-1) unstable; urgency=medium
 
   * New upstream release (Closes: #879938)
diff -Nru pg-activity-1.4.0/debian/control pg-activity-1.4.0/debian/control
--- pg-activity-1.4.0/debian/control	2017-12-06 17:18:10.0 -0500
+++ pg-activity-1.4.0/debian/control	2019-08-22 20:23:08.0 -0400
@@ -4,22 +4,21 @@
 Maintainer: Emmanuel Bouthenot 
 Build-Depends:
 debhelper (>= 9),
-python-all (>= 2.6.6-3~),
-python-setuptools,
+python3,
+python3-setuptools,
 dh-python
 Standards-Version: 4.1.2
 Homepage: https://github.com/julmon/pg_activity
 Vcs-Git: https://anonscm.debian.org/git/users/kolter/pg-activity.git
 Vcs-Browser: https://anonscm.debian.org/git/users/kolter/pg-activity.git
-X-Python-Version: >= 2.6
 
 Package: pg-activity
 Architecture: all
 Depends:
 ${misc:Depends},
-${python:Depends},
-python-psycopg2,
-python-psutil
+${python3:Depends},
+python3-psycopg2,
+python3-psutil
 Description: Realtime PostgreSQL database server monitoring tool
  PgActivity is a curses-based realtime utility to display information from a
  running PostgreSQL database server.
diff -Nru pg-activity-1.4.0/debian/rules pg-activity-1.4.0/debian/rules
--- pg-activity-1.4.0/debian/rules	2015-03-27 12:01:33.0 -0400
+++ pg-activity-1.4.0/debian/rules	2019-08-22 20:13:52.0 -0400
@@ -1,4 +1,4 @@
 #!/usr/bin/make -f
 # -*- makefile -*-
 %:
-	dh $@ --with=python2
+	dh $@ --with=python3 --buildsystem=pybuild

Bug#610839: Bericht via qintens.nl

[Qintens]

Naam: Mevr. CurtisFag
Organisatie: 
E-mailadres: 610...@bugs.debian.org
Telefoonnummer: 82314518412
Telefonisch bereikbaar: Tussen 17.00 - 18.00
Gewenst Tijdstip: [tijd]
Hoe gevonden: Via een advertentie

Bericht: 
The best women for sex in your town: http://inaranom.cf/46thn?&gbkfe=8Qs1llX

Pagina URL: https://www.qintens.nl/contact/

Bug#935475: powerline-taskwarrior: diff for NMU version 0.7.2-1.1

[Sandro Tosi]

Package: powerline-taskwarrior
Version: 0.7.2-1
Severity: normal
Tags: patch  pending


Dear maintainer,

I've prepared an NMU for powerline-taskwarrior (versioned as 0.7.2-1.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

This drops python 2 support, and it's a requirement to drop python-powerline

Regards.

diff -Nru powerline-taskwarrior-0.7.2/debian/changelog powerline-taskwarrior-0.7.2/debian/changelog
--- powerline-taskwarrior-0.7.2/debian/changelog	2019-07-16 13:10:11.0 -0400
+++ powerline-taskwarrior-0.7.2/debian/changelog	2019-08-22 20:02:31.0 -0400
@@ -1,3 +1,10 @@
+powerline-taskwarrior (0.7.2-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python 2 support
+
+ -- Sandro Tosi   Thu, 22 Aug 2019 20:02:31 -0400
+
 powerline-taskwarrior (0.7.2-1) unstable; urgency=medium
 
   * New upstream version 0.7.2
diff -Nru powerline-taskwarrior-0.7.2/debian/control powerline-taskwarrior-0.7.2/debian/control
--- powerline-taskwarrior-0.7.2/debian/control	2019-07-16 13:06:12.0 -0400
+++ powerline-taskwarrior-0.7.2/debian/control	2019-08-22 19:52:40.0 -0400
@@ -5,29 +5,14 @@
 Priority: optional
 Build-Depends: debhelper (>= 11),
dh-python,
-   python-all,
python3-all,
-   python-setuptools,
python3-setuptools,
-   python-powerline,
python3-powerline
 Standards-Version: 4.1.4
 Vcs-Browser: https://salsa.debian.org/tasktools-team/powerline-taskwarrior
 Vcs-Git: https://salsa.debian.org/tasktools-team/powerline-taskwarrior.git
 Homepage: https://github.com/Zebradil/powerline-taskwarrior
 
-Package: python-powerline-taskwarrior
-Architecture: all
-Depends: ${python:Depends},
- ${misc:Depends},
- taskwarrior (>= 2.4.2)
-Description: Powerline segment for showing Taskwarrior information (Python 2)
- A Powerline segment for showing information from Taskwarrior task manager.
- .
- It will show current context and active task (first of alphabetical order).
- .
- This package contains the Python 2 module.
-
 Package: python3-powerline-taskwarrior
 Architecture: all
 Depends: ${python3:Depends},
diff -Nru powerline-taskwarrior-0.7.2/debian/rules powerline-taskwarrior-0.7.2/debian/rules
--- powerline-taskwarrior-0.7.2/debian/rules	2019-07-16 13:06:12.0 -0400
+++ powerline-taskwarrior-0.7.2/debian/rules	2019-08-22 19:58:31.0 -0400
@@ -3,4 +3,4 @@
 export PYBUILD_NAME=powerline-taskwarrior
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild

Bug#935474: buster-pu: package xymon/4.3.28-5+deb10u1

[Axel Beckert]

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

Hi,

The Debian Security Team decided to not issue a security update for
these CVE IDs:

* CVE-2019-13451: service overflows histlogfn in history.c.
* CVE-2019-13452: service overflows histlogfn in reportlog.c.
* CVE-2019-13273: srdb overflows dbfn in csvinfo.c.
* CVE-2019-13274: reflected XSS in csvinfo.c.
* CVE-2019-13455: htmlquoted(hostname) overflows msgline in
  acknowledge.c.
* CVE-2019-13484: htmlquoted(xymondreq) overflows errtxt appfeed.c.
* CVE-2019-13485: hostname overflows selfurl in history.c.
* CVE-2019-13486: htmlquoted(xymondreq) overflows errtxt in
  svcstatus.c.

Hence I propose to do these as a normal stable update.

Full source debdiff:

diff -Nru xymon-4.3.28/debian/changelog xymon-4.3.28/debian/changelog
--- xymon-4.3.28/debian/changelog   2019-03-18 01:28:51.0 +0100
+++ xymon-4.3.28/debian/changelog   2019-08-23 01:07:47.0 +0200
@@ -1,3 +1,22 @@
+xymon (4.3.28-5+deb10u1) buster; urgency=high
+
+  * Apply minimal upstream security patch to fix several (server-only)
+vulnerabilities reported upstream by Graham Rymer:
++ CVE-2019-13451: service overflows histlogfn in history.c.
++ CVE-2019-13452: service overflows histlogfn in reportlog.c.
++ CVE-2019-13273: srdb overflows dbfn in csvinfo.c.
++ CVE-2019-13274: reflected XSS in csvinfo.c.
++ CVE-2019-13455: htmlquoted(hostname) overflows msgline in
+  acknowledge.c.
++ CVE-2019-13484: htmlquoted(xymondreq) overflows errtxt appfeed.c.
++ CVE-2019-13485: hostname overflows selfurl in history.c.
++ CVE-2019-13486: htmlquoted(xymondreq) overflows errtxt in
+  svcstatus.c.
++ Closes: #935470
+  * Include hostname validation regression fixes from 4.3.30, too.
+
+ -- Axel Beckert   Fri, 23 Aug 2019 01:07:47 +0200
+
 xymon (4.3.28-5) unstable; urgency=medium
 
   * xymon.postinst: Check for file existence before calling chgrp/chmod on
diff -Nru xymon-4.3.28/debian/patches/91_4.3.29-CVEs.patch 
xymon-4.3.28/debian/patches/91_4.3.29-CVEs.patch
--- xymon-4.3.28/debian/patches/91_4.3.29-CVEs.patch1970-01-01 
01:00:00.0 +0100
+++ xymon-4.3.28/debian/patches/91_4.3.29-CVEs.patch2019-08-23 
01:07:05.0 +0200
@@ -0,0 +1,760 @@
+Description: Isolated CVE Patchset
+   history.c (service overflows histlogfn) = CVE-2019-13451
+   reportlog.c (service overflows histlogfn) = CVE-2019-13452
+   csvinfo.c (srdb overflows dbfn) = CVE-2019-13273
+   csvinfo.c (reflected XSS) = CVE-2019-13274
+   acknowledge.c (htmlquoted(hostname) overflows msgline) = CVE-2019-13455
+
+   appfeed.c (htmlquoted(xymondreq) overflows errtxt) = CVE-2019-13484
+   history.c (hostname overflows selfurl) = CVE-2019-13485
+   svcstatus.c (htmlquoted(xymondreq) overflows errtxt) = CVE-2019-13486
+
+   Includes hostname validation regression fixes from 4.3.30.
+Author: Japheth Cleaver 
+Bug-Debian: https://bugs.debian.org/935470
+
+Index: xymon/lib/strfunc.h
+===
+--- xymon/lib/strfunc.h(revision 8059)
 xymon/lib/strfunc.h(working copy)
+@@ -29,5 +29,14 @@
+ extern char *prehtmlquoted(char *s);
+ extern strbuffer_t *replacetext(char *original, char *oldtext, char *newtext);
+ 
++#define SBUF_DEFINE(NAME) char *NAME = NULL; size_t NAME##_buflen = 0;
++#define STATIC_SBUF_DEFINE(NAME) static char *NAME = NULL; static size_t 
NAME##_buflen = 0;
++#define SBUF_MALLOC(NAME, LEN) { NAME##_buflen = (LEN); NAME = (char 
*)malloc((LEN)+1); }
++#define SBUF_CALLOC(NAME, NMEMB, LEN) { NAME##_buflen = (LEN); NAME = (char 
*)calloc(NMEMB, (LEN)+1); }
++#define SBUF_REALLOC(NAME, LEN) { NAME##_buflen = (LEN); NAME = (char 
*)realloc(NAME, (LEN)+1); }
++
++/* How much can a string expand when htmlquoted? ' ' --> ' ' */
++#define MAX_HTMLQUOTE_FACTOR 6
++
+ #endif
+ 
+Index: xymon/web/csvinfo.c
+===
+--- xymon/web/csvinfo.c(revision 8059)
 xymon/web/csvinfo.c(working copy)
+@@ -123,12 +123,13 @@
+   return 1;
+   }
+ 
+-  sprintf(dbfn, "%s/etc/%s", xgetenv("XYMONHOME"), srcdb);
++  snprintf(dbfn, sizeof(dbfn), "%s/etc/%s", xgetenv("XYMONHOME"), srcdb);
+   db = fopen(dbfn, "r");
+   if (db == NULL) {
+-  char msg[PATH_MAX];
++  SBUF_DEFINE(msg);
+ 
+-  sprintf(msg, "Cannot open sourcedb %s\n", dbfn);
++  SBUF_MALLOC(msg, 30+strlen(htmlquoted(dbfn)));
++  snprintf(msg, msg_buflen, "Cannot open sourcedb %s\n", 
htmlquoted(dbfn));
+   errormsg(msg);
+   return 1;
+   }
+Index: xymon/web/svcstatus.c
+===
+--- xymon/web/svcstatus.c  (revision 8059)
 xymon/web/svcstatus.c  (working copy)
+@@ -31,7 +31,7 @@
+ /

Bug#935473: stretch-pu: package xymon/4.3.28-2+deb9u1

[Axel Beckert]

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

Hi,

The Debian Security Team decided to not issue a security update for
these CVE IDs:

* CVE-2019-13451: service overflows histlogfn in history.c.
* CVE-2019-13452: service overflows histlogfn in reportlog.c.
* CVE-2019-13273: srdb overflows dbfn in csvinfo.c.
* CVE-2019-13274: reflected XSS in csvinfo.c.
* CVE-2019-13455: htmlquoted(hostname) overflows msgline in
  acknowledge.c.
* CVE-2019-13484: htmlquoted(xymondreq) overflows errtxt appfeed.c.
* CVE-2019-13485: hostname overflows selfurl in history.c.
* CVE-2019-13486: htmlquoted(xymondreq) overflows errtxt in
  svcstatus.c.

Hence I propose to do these as a normal stable update.

Full source debdiff:

diff -Nru xymon-4.3.28/debian/changelog xymon-4.3.28/debian/changelog
--- xymon-4.3.28/debian/changelog   2017-03-03 23:18:20.0 +0100
+++ xymon-4.3.28/debian/changelog   2019-08-23 01:09:07.0 +0200
@@ -1,3 +1,22 @@
+xymon (4.3.28-2+deb9u1) stretch; urgency=high
+
+  * Apply minimal upstream security patch to fix several (server-only)
+vulnerabilities reported upstream by Graham Rymer:
++ CVE-2019-13451: service overflows histlogfn in history.c.
++ CVE-2019-13452: service overflows histlogfn in reportlog.c.
++ CVE-2019-13273: srdb overflows dbfn in csvinfo.c.
++ CVE-2019-13274: reflected XSS in csvinfo.c.
++ CVE-2019-13455: htmlquoted(hostname) overflows msgline in
+  acknowledge.c.
++ CVE-2019-13484: htmlquoted(xymondreq) overflows errtxt appfeed.c.
++ CVE-2019-13485: hostname overflows selfurl in history.c.
++ CVE-2019-13486: htmlquoted(xymondreq) overflows errtxt in
+  svcstatus.c.
++ Closes: #935470
+  * Include hostname validation regression fixes from 4.3.30, too.
+
+ -- Axel Beckert   Fri, 23 Aug 2019 01:09:07 +0200
+
 xymon (4.3.28-2) unstable; urgency=low
 
   * xymon-client: Add dependency on net-tools. (Closes: #856315)
diff -Nru xymon-4.3.28/debian/patches/91_4.3.29-CVEs.patch 
xymon-4.3.28/debian/patches/91_4.3.29-CVEs.patch
--- xymon-4.3.28/debian/patches/91_4.3.29-CVEs.patch1970-01-01 
01:00:00.0 +0100
+++ xymon-4.3.28/debian/patches/91_4.3.29-CVEs.patch2019-08-23 
01:07:05.0 +0200
@@ -0,0 +1,760 @@
+Description: Isolated CVE Patchset
+   history.c (service overflows histlogfn) = CVE-2019-13451
+   reportlog.c (service overflows histlogfn) = CVE-2019-13452
+   csvinfo.c (srdb overflows dbfn) = CVE-2019-13273
+   csvinfo.c (reflected XSS) = CVE-2019-13274
+   acknowledge.c (htmlquoted(hostname) overflows msgline) = CVE-2019-13455
+
+   appfeed.c (htmlquoted(xymondreq) overflows errtxt) = CVE-2019-13484
+   history.c (hostname overflows selfurl) = CVE-2019-13485
+   svcstatus.c (htmlquoted(xymondreq) overflows errtxt) = CVE-2019-13486
+
+   Includes hostname validation regression fixes from 4.3.30.
+Author: Japheth Cleaver 
+Bug-Debian: https://bugs.debian.org/935470
+
+Index: xymon/lib/strfunc.h
+===
+--- xymon/lib/strfunc.h(revision 8059)
 xymon/lib/strfunc.h(working copy)
+@@ -29,5 +29,14 @@
+ extern char *prehtmlquoted(char *s);
+ extern strbuffer_t *replacetext(char *original, char *oldtext, char *newtext);
+ 
++#define SBUF_DEFINE(NAME) char *NAME = NULL; size_t NAME##_buflen = 0;
++#define STATIC_SBUF_DEFINE(NAME) static char *NAME = NULL; static size_t 
NAME##_buflen = 0;
++#define SBUF_MALLOC(NAME, LEN) { NAME##_buflen = (LEN); NAME = (char 
*)malloc((LEN)+1); }
++#define SBUF_CALLOC(NAME, NMEMB, LEN) { NAME##_buflen = (LEN); NAME = (char 
*)calloc(NMEMB, (LEN)+1); }
++#define SBUF_REALLOC(NAME, LEN) { NAME##_buflen = (LEN); NAME = (char 
*)realloc(NAME, (LEN)+1); }
++
++/* How much can a string expand when htmlquoted? ' ' --> ' ' */
++#define MAX_HTMLQUOTE_FACTOR 6
++
+ #endif
+ 
+Index: xymon/web/csvinfo.c
+===
+--- xymon/web/csvinfo.c(revision 8059)
 xymon/web/csvinfo.c(working copy)
+@@ -123,12 +123,13 @@
+   return 1;
+   }
+ 
+-  sprintf(dbfn, "%s/etc/%s", xgetenv("XYMONHOME"), srcdb);
++  snprintf(dbfn, sizeof(dbfn), "%s/etc/%s", xgetenv("XYMONHOME"), srcdb);
+   db = fopen(dbfn, "r");
+   if (db == NULL) {
+-  char msg[PATH_MAX];
++  SBUF_DEFINE(msg);
+ 
+-  sprintf(msg, "Cannot open sourcedb %s\n", dbfn);
++  SBUF_MALLOC(msg, 30+strlen(htmlquoted(dbfn)));
++  snprintf(msg, msg_buflen, "Cannot open sourcedb %s\n", 
htmlquoted(dbfn));
+   errormsg(msg);
+   return 1;
+   }
+Index: xymon/web/svcstatus.c
+===
+--- xymon/web/svcstatus.c  (revision 8059)
 xymon/web/svcstatus.c  (working copy)
+@@ -31,7 +31,7 @@
+ /* Command-li

Bug#935472: python-memory-profiler: diff for version 0.52-2

[Sandro Tosi]

Package: python-memory-profiler
Version: 0.52-1
Severity: normal
Tags: patch  pending


Dear maintainer,

I've prepared an upload for python-memory-profiler (versioned as 0.52-2) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

This removes python 2 support (I have the changes in git, but i cant upload as i
dont have access to debian-science repos yet, i've just requested access).

Regards.

diff -Nru python-memory-profiler-0.52/debian/changelog python-memory-profiler-0.52/debian/changelog
--- python-memory-profiler-0.52/debian/changelog	2018-02-22 09:47:15.0 -0500
+++ python-memory-profiler-0.52/debian/changelog	2019-08-22 19:30:48.0 -0400
@@ -1,3 +1,13 @@
+python-memory-profiler (0.52-2) unstable; urgency=medium
+
+  * Team upload.
+  * Drop python 2 support
+  * debian/control
+- drop obsolete X-P-V fields
+- bump Standards-Version to 4.4.0 (no changes needed)
+
+ -- Sandro Tosi   Thu, 22 Aug 2019 19:30:48 -0400
+
 python-memory-profiler (0.52-1) unstable; urgency=medium
 
   * New upstream version 0.52
diff -Nru python-memory-profiler-0.52/debian/control python-memory-profiler-0.52/debian/control
--- python-memory-profiler-0.52/debian/control	2018-02-22 09:47:15.0 -0500
+++ python-memory-profiler-0.52/debian/control	2019-08-22 19:30:48.0 -0400
@@ -6,30 +6,13 @@
 Build-Depends: debhelper (>= 11),
dh-python (>= 2.20160818),
dpkg-dev (>= 1.17.14),
-   python-all,
-   python-psutil ,
-   python-setuptools,
python3-all,
python3-psutil ,
python3-setuptools
-Standards-Version: 4.1.3
+Standards-Version: 4.4.0
 Vcs-Browser: https://salsa.debian.org/science-team/python-memory-profiler
 Vcs-Git: https://salsa.debian.org/science-team/python-memory-profiler.git
 Homepage: https://github.com/fabianp/memory_profiler
-X-Python-Version: >= 2.6
-X-Python3-Version: >= 3.2
-
-Package: python-memory-profiler
-Architecture: all
-Depends: ${misc:Depends},
- ${python:Depends},
- python-psutil
-Description: memory consumption analysis for Python programs (Python 2)
- This is a Python module for monitoring memory consumption of a process
- as well as line-by-line analysis of memory consumption for Python
- programs.
- .
- This package provides the modules for Python 2.
 
 Package: python3-memory-profiler
 Architecture: all
diff -Nru python-memory-profiler-0.52/debian/python-memory-profiler.docs python-memory-profiler-0.52/debian/python-memory-profiler.docs
--- python-memory-profiler-0.52/debian/python-memory-profiler.docs	2018-02-22 09:47:15.0 -0500
+++ python-memory-profiler-0.52/debian/python-memory-profiler.docs	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-README.rst
diff -Nru python-memory-profiler-0.52/debian/python-memory-profiler.examples python-memory-profiler-0.52/debian/python-memory-profiler.examples
--- python-memory-profiler-0.52/debian/python-memory-profiler.examples	2018-02-22 09:47:15.0 -0500
+++ python-memory-profiler-0.52/debian/python-memory-profiler.examples	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-examples/*
diff -Nru python-memory-profiler-0.52/debian/rules python-memory-profiler-0.52/debian/rules
--- python-memory-profiler-0.52/debian/rules	2018-02-22 09:47:15.0 -0500
+++ python-memory-profiler-0.52/debian/rules	2019-08-22 19:30:48.0 -0400
@@ -2,10 +2,10 @@
 #export DH_VERBOSE=1
 export PYBUILD_NAME=memory-profiler
 
-export PYBUILD_DISABLE_python2=test
+export PYBUILD_DISABLE_python3=test
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
 
 override_dh_auto_test:
 	PYBUILD_SYSTEM=custom PYBUILD_BEFORE_TEST="cp -rf test/ Makefile {build_dir}" \
@@ -15,7 +15,5 @@
 
 override_dh_auto_install:
 	dh_auto_install
-	mv $(CURDIR)/debian/python-memory-profiler/usr/bin/mprof \
-	$(CURDIR)/debian/python-memory-profiler/usr/bin/python-mprof
 	mv $(CURDIR)/debian/python3-memory-profiler/usr/bin/mprof \
 	$(CURDIR)/debian/python3-memory-profiler/usr/bin/python3-mprof

Bug#830726: xtrlock: CVE-2016-10894: xtrlock does not block multitouch events

[Matthew Vernon]

On 22/08/2019 18:50, Antoine Amarilli wrote:

Hi Chris,

On Wed, Aug 21, 2019 at 03:52:44PM -0700, Chris Lamb wrote:



Cool! I'm not sure whether this other edge case is important -- are
there situations where an attacker in front of a locked computer could
manage to pull this off?


I think we may be in danger of Trying Too Hard here - xtrlock and 
similar are already vulnerable to some attacks (e.g. Ctrl-Alt-F1 could 
get you to do tty which might have a login session on).


Regards,

Matthew

Bug#613605: patch -b and -V options, overwrites file.orig despite manpage description (additional info)

[Jesse Smith]

I looked at the documentation and the examples provided here and they
are working as documented. I don't think there is a bug here.

Now, in theory, it might be nice to have a flag which prevents old .orig
files from being overwritten. I can see how that would be beneficial.
But the examples provided here are working as intended.

- Jesse

Bug#935471: systemd: bogus "Process .. as been marked to be excluded from killing" warning from systemd-shutdown

[Marc Lehmann]

Package: systemd
Version: 241-5
Severity: minor

Dear Maintainer,

on one of my systems, debian runs from a filesystem image loop-mounted
from an ntfs volume using ntfs-3g, and thus, the ntfs-3g process must be
running at all times, before mounting the root fs and during shutdown.

To accomplish this I have an initramfs-tools script that runs it something
like this:

  exec -a @ntfs-3g-root ntfs-3g ...

The @ prevents systemd-shutdown from killing it, which works. However, it
outputs the following warning (lifted from the code, can't copy&paste from
the real system):

log_notice("Process " PID_FMT " (%s) has been marked to be 
excluded from killing. It is "
   "running from the root file system, and thus likely 
to block re-mounting of the "
   "root file system to read-only. Please consider 
moving it into an initrd file "
   "system instead.", pid, strna(comm));

Since it is running from the initramfs, this warning is bogus (and indeed,
the root fs can be mounted ro with no problem), suggesting that the check
systemd-shutdown uses to detect this case is broken.

For additional reference, /proc//root has a target of "/",
which probably causes this. /proc//exe has a target of
'/usr/bin/ntfs-3g (deleted)', which makes sense as it was deleted when
cleaning up the initramfs before handing over to the actual root fs.

-- Package-specific info:

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

Kernel: Linux 5.1.21-050121-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_DK.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 systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-4
ii  libapparmor1 2.13.2-10
ii  libaudit11:2.8.4-3
ii  libblkid12.33.1-0.1
ii  libc62.28-10
ii  libcap2  1:2.25-2
ii  libcryptsetup12  2:2.1.0-5
ii  libgcrypt20  1.8.4-5
ii  libgnutls30  3.6.7-4
ii  libgpg-error01.35-1
ii  libidn11 1.33-2.2
ii  libip4tc01.8.2-4
ii  libkmod2 26-1
ii  liblz4-1 1.8.3-1
ii  liblzma5 5.2.4-1
ii  libmount12.33.1-0.1
ii  libpam0g 1.3.1-5
ii  libseccomp2  2.3.3-4
ii  libselinux1  2.8-1+b1
ii  libsystemd0  241-5
ii  mount2.33.1-0.1
ii  util-linux   2.33.1-0.1

Versions of packages systemd recommends:
ii  dbus1.12.16-1
ii  libpam-systemd  241-5

Versions of packages systemd suggests:
ii  policykit-10.105-25
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.133
ii  udev 241-5

-- no debconf information

Bug#935031: Back to normal

[inkbottle]

Came back to normal after reboot.
C.

Bug#830726: xtrlock: CVE-2016-10894: xtrlock does not block multitouch events

[Chris Lamb]

Hi Matthew,

> I think we may be in danger of Trying Too Hard here - xtrlock and 
> similar are already vulnerable to some attacks (e.g. Ctrl-Alt-F1 could 
> get you to do tty which might have a login session on).

Sure, but plugging in an external multitouch USB pointer seems like
something that would want to try a few moments to avoid... (ignore
that I'm using "xinput" per se)


Regards,

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

Bug#935470: xymon: Several vulnerabilities in Xymon: CVE-2019-13451 CVE-2019-13452 CVE-2019-13273 CVE-2019-13274 CVE-2019-13455 CVE-2019-13484 CVE-2019-13485 CVE-2019-13486

[Axel Beckert]

Source: xymon
Severity: important
Version: 4.3.28-1
Tags: patch upstream security
Control: fixed -1 4.3.29-1

Several vulnerabilities have been found in the server component of Xymon
(at least in version 4.3.28):

* history.c (service overflows histlogfn) = CVE-2019-13451
* reportlog.c (service overflows histlogfn) = CVE-2019-13452
* csvinfo.c (srdb overflows dbfn) = CVE-2019-13273
* csvinfo.c (reflected XSS) = CVE-2019-13274
* acknowledge.c (htmlquoted(hostname) overflows msgline) = CVE-2019-13455
* appfeed.c (htmlquoted(xymondreq) overflows errtxt) = CVE-2019-13484
* history.c (hostname overflows selfurl) = CVE-2019-13485
* svcstatus.c (htmlquoted(xymondreq) overflows errtxt) = CVE-2019-13486

The Debian Security Team does not consider this severe enough for a DSA,
see https://security-tracker.debian.org/tracker/source-package/xymon

4.3.29-1 in Debian Sid and Bullseye are already fixed.

Minimal upstream patch against 4.3.28:

Description: Isolated CVE Patchset
history.c (service overflows histlogfn) = CVE-2019-13451
reportlog.c (service overflows histlogfn) = CVE-2019-13452
csvinfo.c (srdb overflows dbfn) = CVE-2019-13273
csvinfo.c (reflected XSS) = CVE-2019-13274
acknowledge.c (htmlquoted(hostname) overflows msgline) = CVE-2019-13455

appfeed.c (htmlquoted(xymondreq) overflows errtxt) = CVE-2019-13484
history.c (hostname overflows selfurl) = CVE-2019-13485
svcstatus.c (htmlquoted(xymondreq) overflows errtxt) = CVE-2019-13486

Includes hostname validation regression fixes from 4.3.30.
Author: Japheth Cleaver 

Index: xymon/lib/strfunc.h
===
--- xymon/lib/strfunc.h (revision 8059)
+++ xymon/lib/strfunc.h (working copy)
@@ -29,5 +29,14 @@
 extern char *prehtmlquoted(char *s);
 extern strbuffer_t *replacetext(char *original, char *oldtext, char *newtext);
 
+#define SBUF_DEFINE(NAME) char *NAME = NULL; size_t NAME##_buflen = 0;
+#define STATIC_SBUF_DEFINE(NAME) static char *NAME = NULL; static size_t 
NAME##_buflen = 0;
+#define SBUF_MALLOC(NAME, LEN) { NAME##_buflen = (LEN); NAME = (char 
*)malloc((LEN)+1); }
+#define SBUF_CALLOC(NAME, NMEMB, LEN) { NAME##_buflen = (LEN); NAME = (char 
*)calloc(NMEMB, (LEN)+1); }
+#define SBUF_REALLOC(NAME, LEN) { NAME##_buflen = (LEN); NAME = (char 
*)realloc(NAME, (LEN)+1); }
+
+/* How much can a string expand when htmlquoted? ' ' --> ' ' */
+#define MAX_HTMLQUOTE_FACTOR 6
+
 #endif
 
Index: xymon/web/csvinfo.c
===
--- xymon/web/csvinfo.c (revision 8059)
+++ xymon/web/csvinfo.c (working copy)
@@ -123,12 +123,13 @@
return 1;
}
 
-   sprintf(dbfn, "%s/etc/%s", xgetenv("XYMONHOME"), srcdb);
+   snprintf(dbfn, sizeof(dbfn), "%s/etc/%s", xgetenv("XYMONHOME"), srcdb);
db = fopen(dbfn, "r");
if (db == NULL) {
-   char msg[PATH_MAX];
+   SBUF_DEFINE(msg);
 
-   sprintf(msg, "Cannot open sourcedb %s\n", dbfn);
+   SBUF_MALLOC(msg, 30+strlen(htmlquoted(dbfn)));
+   snprintf(msg, msg_buflen, "Cannot open sourcedb %s\n", 
htmlquoted(dbfn));
errormsg(msg);
return 1;
}
Index: xymon/web/svcstatus.c
===
--- xymon/web/svcstatus.c   (revision 8059)
+++ xymon/web/svcstatus.c   (working copy)
@@ -31,7 +31,7 @@
 /* Command-line params */
 static enum { SRC_XYMOND, SRC_HISTLOGS, SRC_CLIENTLOGS } source = SRC_XYMOND;
 static int wantserviceid = 1;
-static char *multigraphs = 
",disk,inode,qtree,quotas,snapshot,TblSpace,if_load,";
+SBUF_DEFINE(multigraphs);
 static int locatorbased = 0;
 static char *critconfigfn = NULL;
 static char *accessfn = NULL;
@@ -42,12 +42,12 @@
 static char *tstamp = NULL;
 static char *nkprio = NULL, *nkttgroup = NULL, *nkttextra = NULL;
 static enum { FRM_STATUS, FRM_CLIENT } outform = FRM_STATUS;
-static char *clienturi = NULL;
+STATIC_SBUF_DEFINE(clienturi);
 static int backsecs = 0;
 static time_t fromtime = 0, endtime = 0;
 
 static char errortxt[1000];
-static char *hostdatadir = NULL;
+STATIC_SBUF_DEFINE(hostdatadir);
 
 
 static void errormsg(int status, char *msg)
@@ -148,12 +148,13 @@
 
if (outform == FRM_STATUS) {
char *p, *req;
+   char *hostquoted = htmlquoted(hostname);
 
req = getenv("SCRIPT_NAME");
-   clienturi = (char *)malloc(strlen(req) + 10 + 
strlen(htmlquoted(hostname)));
-   strcpy(clienturi, req);
+   SBUF_MALLOC(clienturi, strlen(req) + 10 + strlen(hostquoted));
+   strncpy(clienturi, req, clienturi_buflen);
p = strchr(clienturi, '?'); if (p) *p = '\0'; else p = 
clienturi + strlen(clienturi);
-   sprintf(p, "?CLIENT=%s", htmlquoted(hostname));
+   snprintf(p, (clienturi_buflen - (clienturi

Bug#931977: startpar: uninitialized variable

[Jesse Smith]

control: tags -1 +fixed-upstream

This issue has been fixed upstream and will be resolved in startpar-0.64.

- Jesse

Bug#935469: check/main.c:4728: add_data_backref: BUG_ON `!back` triggered, value 1

[Leszek Dubiel]

Package: btrfs-progs
Version: 4.20.1-2
Severity: normal

I was told some time ago to file a bug on this. When checking btrfs file 
system I get below error. I have only one such faulty disk formatted 
with BTRFS, so I don't have

any more details about this bug.
root@gamma# btrfs check /dev/sda1
Opening filesystem to check...
Checking filesystem on /dev/sda1
UUID: 666a7089-d716-44ff-8081-56b969b58eff
[1/7] checking root items
[2/7] checking extents
check/main.c:4728: add_data_backref: BUG_ON `!back` triggered, value 1
Przerwane

root@gamma# btrfs check /dev/sda1 --repair
enabling repair mode
Opening filesystem to check...
Checking filesystem on /dev/sda1
UUID: 666a7089-d716-44ff-8081-56b969b58eff
[1/7] checking root items
Fixed 0 roots.
[2/7] checking extents
memory allocation failed



-- System Information:
Debian Release: 10.0
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.19.0-5-686-pae (SMP w/2 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: systemd (via /run/systemd/system)

Versions of packages btrfs-progs depends on:
ii libblkid1 2.33.1-0.1
ii libc6 2.28-10
ii liblzo2-2 2.10-0.1
ii libuuid1 2.33.1-0.1
ii libzstd1 1.3.8+dfsg-3
ii zlib1g 1:1.2.11.dfsg-1

btrfs-progs recommends no packages.

Versions of packages btrfs-progs suggests:
pn duperemove 

-- no debconf information

Bug#935468: [GAMMA] check/main.c:4728: add_data_backref: BUG_ON `!back` triggered, value 1

[Leszek Dubiel]

Package: btrfs-progs
Version: 4.20.1-2
Severity: normal

I was told some time ago to file a bug on this. 
When checking btrfs file system I get below error. 
I have only one such faulty disk formatted with BTRFS, so I don't have
any more details about this bug. 

root@gamma#   btrfs check /dev/sda1
Opening filesystem to check...
Checking filesystem on /dev/sda1
UUID: 666a7089-d716-44ff-8081-56b969b58eff
[1/7] checking root items
[2/7] checking extents
check/main.c:4728: add_data_backref: BUG_ON `!back` triggered, value 1
Przerwane

root@gamma#   btrfs check /dev/sda1 --repair
enabling repair mode
Opening filesystem to check...
Checking filesystem on /dev/sda1
UUID: 666a7089-d716-44ff-8081-56b969b58eff
[1/7] checking root items
Fixed 0 roots.
[2/7] checking extents
memory allocation failed



-- System Information:
Debian Release: 10.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.19.0-5-686-pae (SMP w/2 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: systemd (via /run/systemd/system)

Versions of packages btrfs-progs depends on:
ii  libblkid1  2.33.1-0.1
ii  libc6  2.28-10
ii  liblzo2-2  2.10-0.1
ii  libuuid1   2.33.1-0.1
ii  libzstd1   1.3.8+dfsg-3
ii  zlib1g 1:1.2.11.dfsg-1

btrfs-progs recommends no packages.

Versions of packages btrfs-progs suggests:
pn  duperemove  

-- no debconf information

Bug#935452: guake: (possible) Missing dependency: gir1.2-wnck-3.0

[Daniel Echeverry]

tags 935452 + pending
thanks

Hi!

Ops! you are right, I will solve it in the new revision and upload to
unstable.

Regards!

-- 
Daniel Echeverry
Debian Developer
https://wiki.debian.org/DanielEcheverry
Linux user: #477840
GPG Fingerprint:
D0D0 85B1 69C3 BFD9 4048 58FA 21FC 2950 4B52 30DB

Bug#935467: RM: subversion/experimental -- ROM; Unused pre-release version

[James McCoy]

Package: ftp.debian.org
Severity: normal

I initially made the upload as preparation to upload the final release
to unstable.  However, that changed when I remembered this wasn't an LTS
subversion release.

I don't intend to make further updates of the 1.11.x version line and
having the version in experimental confuses some of the QA tools.

Bug#782903: man-db: incomplete UTF-8 support in /usr/bin/man

[Colin Watson]

Control: reassign -1 groff
Control: retitle -1 groff: inadequate composite glyph support in 
devdvi/devpdf/devps

On Sun, Apr 19, 2015 at 06:30:28PM +0200, Rafal Pietrak wrote:
> I tried to PDF a manpage, so I did:
> 
> $ man -t man >a.ps
> :26: warning: can't find special character `u0065_0328'
> :26: warning: can't find special character `u0061_0328'
> :32: warning: can't find special character `u007A_0307'
> :34: warning: can't find special character `u0073_0301'
> :39: warning: can't find special character `u006E_0301'
> :99: warning: can't find special character `u007A_0301'
> :123: warning: can't find special character `u004E_0301'
> :123: warning: can't find special character `u0053_0301'
> :123: warning: can't find special character `u0045_0328'
> :126: warning: can't find special character `u005A_0307'
> $ echo $LANG
> pl_PL.utf8
> --
> 
> And as far as I can tell, the indicated characters are missing from the PS
> output.

This seems to be a groff bug.  It's possible to convince the DVI device
to produce better output by hacking ".mso ec.tmac" early enough into the
data stream sent to groff, but I haven't worked out how to do it for PS
or PDF yet.

I'm prepared to consider the possibility that this is a bug in man-db
nonetheless, but I don't know enough about how composite glyphs are
supposed to work in these devices at this point, unfortunately ...

-- 
Colin Watson   [cjwat...@debian.org]

Bug#934308: dpdk 18.11.2-2+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 934308 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: dpdk
Version: 18.11.2-2+deb10u1

Explanation: new upstream stable release

Bug#935411: dbconfig-common 2.0.11+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 935411 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: dbconfig-common
Version: 2.0.11+deb10u1

Explanation: fix issue caused by change in bash POSIX behaviour

Bug#928271: resiprocate 1.11.0~beta1-3+deb9u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 928271 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: resiprocate
Version: 1.11.0~beta1-3+deb9u1

Explanation: resolve an installation issue with libssl-dev and 
--install-recommends

Bug#935465: buster-pu: package jython/2.7.1+repack1-4~deb10u1

[Andreas Beckmann]

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

jython/buster introduces a strictly versioned java dependency, which
causes problems on some upgrade paths from stretch. (#924283, #934111)
This problem originates from the dependency cycle (#929685) between
ca-certificates-java,default-jre-headless,openjdk-11-jre-headless
which has not been solved in sid, yet (and has been in several stable
releases already).

The cycle gets broken in a way that jython gets configured
successfully but jython-stilts gets configured subsequently and
fails because the system is in a state where openjdk-8-jre-headless
is still active (because openjdk-11-jre-headless is not yet
configured), but default-jre-headless/buster is already configured.
jython-stilts calls jython which fails because bytecode compiled for
java-9+ is getting executed with java-8.

This problem does not show up in other packages, since none adds
incompatibility with the java in stretch.

This was fixed in sid by building jython with backwards compatibility
with the java in stretch, s.t. it does not matter which java version is
run during the upgrade.
I've tested the failing upgrade path in piuparts and can confirm that
the proposed package successfully works around the issues.


Andreas
diff -Nru jython-2.7.1+repack1/debian/changelog 
jython-2.7.1+repack1/debian/changelog
--- jython-2.7.1+repack1/debian/changelog   2019-05-04 18:16:46.0 
+0200
+++ jython-2.7.1+repack1/debian/changelog   2019-08-13 13:21:55.0 
+0200
@@ -1,3 +1,17 @@
+jython (2.7.1+repack1-4~deb10u1) buster; urgency=medium
+
+  * Rebuild for buster.
+
+ -- Andreas Beckmann   Tue, 13 Aug 2019 13:21:55 +0200
+
+jython (2.7.1+repack1-4) unstable; urgency=medium
+
+  * Team upload.
+  * Preserve the backward compatibility with Java 7 (Closes: #934111)
+  * Adjusted the Vcs-* fields
+
+ -- Emmanuel Bourg   Thu, 08 Aug 2019 10:11:23 +0200
+
 jython (2.7.1+repack1-3) unstable; urgency=medium
 
   * Improve previous fix with default-jre-headless (>= 2:1.9), thanks to
diff -Nru jython-2.7.1+repack1/debian/control 
jython-2.7.1+repack1/debian/control
--- jython-2.7.1+repack1/debian/control 2019-05-04 18:14:46.0 +0200
+++ jython-2.7.1+repack1/debian/control 2019-08-08 10:04:43.0 +0200
@@ -25,14 +25,14 @@
  libicu4j-java,
  libnetty-java
 Standards-Version: 4.2.1
-Vcs-Git: https://salsa.debian.org/java-team/jython
-Vcs-Browser: https://salsa.debian.org/java-team/jython.git
+Vcs-Git: https://salsa.debian.org/java-team/jython.git
+Vcs-Browser: https://salsa.debian.org/java-team/jython
 Homepage: http://www.jython.org
 
 Package: jython
 Architecture: all
 Depends: ${misc:Depends}, ${perl:Depends}, ${python:Depends}, ${java:Depends},
- default-jre-headless (>= 2:1.9) | java9-runtime-headless,
+ default-jre-headless (>= 2:1.7) | java7-runtime-headless,
 Recommends: default-jdk | java-compiler
 Suggests: jython-doc, libmariadb-java, libpostgresql-jdbc-java
 Description: Python seamlessly integrated with Java
diff -Nru 
jython-2.7.1+repack1/debian/patches/08-java-backward-compatibility.patch 
jython-2.7.1+repack1/debian/patches/08-java-backward-compatibility.patch
--- jython-2.7.1+repack1/debian/patches/08-java-backward-compatibility.patch
1970-01-01 01:00:00.0 +0100
+++ jython-2.7.1+repack1/debian/patches/08-java-backward-compatibility.patch
2019-08-08 10:08:43.0 +0200
@@ -0,0 +1,45 @@
+Description: Preserves the backward compatibility with previous Java versions 
when built with Java 11+
+Author: Emmanuel Bourg 
+Forwarded: not
+--- a/build.xml
 b/build.xml
+@@ -436,6 +436,7 @@
+ destdir="${compile.dir}"
+ target="${jdk.target.version}"
+ source="${jdk.source.version}"
++release="${jdk.target.version}"
+ debug="${debug}"
+ deprecation="${deprecation}"
+ nowarn="${nowarn}">
+@@ -483,6 +484,7 @@
+ 
+@@ -513,6 +516,7 @@
+destdir="${compile.dir}"
+target="${jdk.target.version}"
+source="${jdk.source.version}"
++   release="${jdk.target.version}"
+debug="${debug}"
+deprecation="${deprecation}"
+nowarn="${nowarn}"
+@@ -882,6 +886,7 @@
+destdir="${compile.dir}"
+target="${jdk.target.version}"
+source="${jdk.source.version}"
++   release="${jdk.target.version}"
+debug="${debug}"
+deprecation="${deprecation}"
+nowarn="${nowarn}"
diff -Nru jython-2.7.1+repack1/debian/patches/series 
jython-2.7.1+repack1/debian/patches/series
--- jython-2.7.1+repack1/debian/patches/series  2019-01-12 19:49:41.0 
+0100
+++ jython-2.7.1+repack1/debian/patches/series  2019-08-08 09:49:44.0 
+0200
@@ -4,3 +4,4 @@
 05-no-com.carrotsearch.sizeof.patch
 javadoc-cl

Bug#902257: groff-base: nroff crashes when the environment variable SHELL is unset

[Colin Watson]

Control: tag -1 fixed-upstream

On Sun, Jun 24, 2018 at 05:01:32PM +0100, Colin Watson wrote:
> I'm not yet sure what the best solution is.  Fiddling about with SHELL
> is obviously brittle.  I could change man to call groff directly rather
> than nroff, which would avoid the problem, but that's also brittle as it
> depends on the implementation language.  I suspect that I'll just have
> to allow sockets in the seccomp sandbox, and maybe rely on AppArmor to
> limit the potential damage.

I recently committed
https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=3a084ddeea0f99f8984e51946f28f3d81579dee4
upstream, and I just realised that that fixes this problem: the attempt
to create a socket now returns EPERM, and glibc recovers gracefully from
that and continues.  So this will be fixed in the next upstream release.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#935265: buster-pu: package gnome-control-center/1:3.30.3-2~deb10u1

[Adam D. Barratt]

Control: tags -1 +confirmed -moreinfo

On Thu, 2019-08-22 at 14:06 +0100, Simon McVittie wrote:
> On Thu, 22 Aug 2019 at 12:14:56 +0100, Adam D. Barratt wrote:
> > On 2019-08-21 09:56, Simon McVittie wrote:
> > > I updated gnome-control-center in unstable a few weeks ago, and I
> > > think the same changes would make sense in buster.
> > > 
> > > >  * d/patches: Update to upstream gnome-3-30 commit 3.30.3-7-
> > > > gf41ae4269
> > 
> > Does this want to go together with the gnome-shell and mutter
> > updates, or can we handle this one separately?
> 
> I think this one can be orthogonal: gnome-control-center isn't in the
> same process as gnome-shell and mutter, so it isn't so closely
> related.

OK. In that case, please go ahead.

Regards,

Adam

Bug#875161: [qtm] Future Qt4 removal from Buster

[Moritz Mühlenhoff]

On Thu, Aug 22, 2019 at 02:17:59PM -0700, Patryk Cisek wrote:
> Hey Moritz,
> 
> No, and upstream there's been no updates since June of 2017. Let's allow it
> to be removed.

Ack, I've just filed a removal bug.

Cheers,
Moritz

Bug#931901:

[Joshua Hudson]

Adding RV635 to the list of affected cards

In this case, the card needs firmware, the firmware is on the disk,
but KMS remains disabled.

Bug#935454: pymca: autopkgtest regression: Segmentation fault

[PICCA Frederic-Emmanuel]

This regression is due to a bug in python-numpy #933056, that I already 
reported, whcih was solved upstream and will be available in the 0.17 version.

Cheers

Fred

Bug#935464: RM: qtm -- RoQA; Depends on qt4, inactive upstream

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove qtm, which depends on Qt4. The maintainer (CCed)
acked the removal in 875161.

Cheers,
Moritz

Bug#875161: [qtm] Future Qt4 removal from Buster

[Patryk Cisek]

Hey Moritz,

No, and upstream there's been no updates since June of 2017. Let's allow it
to be removed.

On Thu, Aug 22, 2019 at 12:51 PM Moritz Mühlenhoff  wrote:

> On Sat, Sep 09, 2017 at 11:08:10PM +0200, Lisandro Damián Nicanor Pérez
> Meyer wrote:
> > Source: qtm
> >
> > Therefore, please take the time and:
> > - contact your upstream (if existing) and ask about the state of a Qt5
> > port of your application
> > - if there are no activities regarding porting, investigate whether
> there are
> > suitable alternatives for your users
> > - if there is a Qt5 port that is not yet packaged, consider packaging it
> > - if both the Qt4 and the Qt5 versions already coexist in the Debian
> > archives, consider removing the Qt4 version
>
> Hi Patryk,
> are you still using/maintaining qtm? (Given that it wasn't uploaded since
> 2016)
>
> The current releases support Qt5, otherwise we can also remove the package.
>
> Cheers,
> Moritz
>
>

-- 
Patryk Cisek

Bug#931901:

[Joshua Hudson]

Adding RV635 to the list of affected cards

Bug#524007: logsave/fsck should create /var/log/fsck

[martin f krafft]

Quoting "Dmitry Bogatov", who wrote on 2019-08-22 at 12:03 Uhr +:
What is possible is to mkdir /var/log/fsck after `mountall', so 
`logsave' can write to /var/log/fsck/checkfs. Is it what you want?


That would work, yes. It just shouldn't assume that the directory 
exists.


--
.''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
 `-  Debian - when you have better things to do than fixing systems

there are two groups of people in the world: those who believe that
the world can be divided into two groups of people, and those who
don't.


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#935463: RM: openteacher -- RoQA; RC-buggy, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove openteacher. It's RC-buggy and dropped from
testing since over 2.5 years and missed two stable releases
already.

Cheers,
Moritz

Bug#935460: stretch-pu: package sox/14.4.1-5+deb9u2

[Moritz Mühlenhoff]

On Thu, Aug 22, 2019 at 10:07:51PM +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Thu, 2019-08-22 at 22:56 +0200, Moritz Muehlenhoff wrote:
> > Attached debdiff fixes a number of bugs in sox. These have been in
> > jessie for a while already (Stretch and Jessie have the same base
> > version as the package was unmaintained for a while) and I've ran
> > some of the POCs on
> > the Stretch build. Debdiff below.
> > 
> 
> Please go ahead.

Thanks, uploaded.

Cheers,
Moritz

Bug#874843: [cdcat] Future Qt4 removal from Buster

[Moritz Mühlenhoff]

On Sat, Sep 09, 2017 at 09:03:03PM +0200, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Source: cdcat
> 
> Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> as [announced] in:
> 
> [announced] 
> 
> 
> Therefore, please take the time and:
> - contact your upstream (if existing) and ask about the state of a Qt5
> port of your application
> - if there are no activities regarding porting, investigate whether there are
> suitable alternatives for your users
> - if there is a Qt5 port that is not yet packaged, consider packaging it
> - if both the Qt4 and the Qt5 versions already coexist in the Debian
> archives, consider removing the Qt4 version

Eduard,
cdcat is dead upstream, are you planning to port it to Qt5 yourself or should
it be removed from the archive?

Cheers,
Moritz

Bug#935459: Tr : Re : Bug#935459: gkrellm crashes [nicolas.patr...@gmail.com]

[nicolas . patrois]

Le 22/08/2019 20:49:58, Sandro Tosi a écrit :
> > Gtk-Message: 22:38:02.810: Failed to load module "atk-bridge"
> > sh: 1: /usr/local/share/gkrellm/GrabWeather: not found

> the debian package doesnt install anything in /usr/local so this is a
> local system change, which we cannot fix/debug. if you need help
> identify the issue, please contact a user support forum
> https://www.debian.org/support

Sorry, removing the plugin does not solve the issue.
gkrellm still crashes. Here is its new output in a shell:
Gtk-Message: 23:07:39.439: Failed to load module "atk-bridge"
The program 'gkrellm' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadPixmap (invalid Pixmap parameter)'.
  (Details: serial 4887 error_code 4 request_code 56 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Note that composing and OpenGL games do run.

nicolas patrois : pts noir asocial
-- 
RÉALISME

M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des
humains ? Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...

Bug#935460: stretch-pu: package sox/14.4.1-5+deb9u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2019-08-22 at 22:56 +0200, Moritz Muehlenhoff wrote:
> Attached debdiff fixes a number of bugs in sox. These have been in
> jessie for a while already (Stretch and Jessie have the same base
> version as the package was unmaintained for a while) and I've ran
> some of the POCs on
> the Stretch build. Debdiff below.
> 

Please go ahead.

Regards,

Adam

Bug#935462: RFS: xca/2.1.2-1 [ITS] -- x509 Certification Authority management tool based on QT

[Thomas Ward]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name : xca
 Version : 2.1.2-1
 Upstream Author : Christian Hohnstaedt 
* URL : https://hohnstaedt.de/xca/
* License : BSD-3-clause
* Vcs : https://salsa.debian.org/debian/xca
 Section : x11

It builds those binary packages:

xca - x509 Certification Authority management tool based on QT

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

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

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

dget -x https://mentors.debian.net/debian/pool/main/x/xca/xca_2.1.2-1.dsc

Changes since the last upload:

* New upstream version. (Closes: #927233)
* d/watch: Update watch file to track upstream xca repository on Github.
* d/compat: Update Debhelper compatibility to latest (12)
* d/control:
- New maintainer (Closes #931806)
- Update Standards-Version to 4.4.0
- Update Homepage to proper Upstream URL
- Update Vcs-Git to point at Debian Salsa. Package now uses a
git-buildpackage (gbp) workflow.
- Add Vcs-Browser field.
- Reorganize Build-Depends to be more readable.
- Remove dh-autoreconf build depends.
- Update debhelper build depends (compat is 12, so use debhelper >= 12)
- Make requisite changes to adjust xca built by the packages to enable
Remote DB support in xca: (Closes: #928678)
- Add libqt5sql5 Build-Depends for Remote DB support.
- Add Recommends on libqt5sql5-{mysql,postgresql} to xca package.
* d/patches/0001-Remove-misc-Info.plist-in-clean-target.patch: Refresh
patch to remove fuzz.
* d/copyright: Update copyright file to be Machine-readable per
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

Regards,


Thomas

Bug#935461: ezgo: diff for NMU version 0.7.1+nmu1

[Boyuan Yang]

Package: ezgo
Version: 0.7.1
Severity: normal
Tags: patch  pending
X-Debbugs-CC: ajq...@debian.org ti...@debian.org

Dear maintainer,

I've prepared an NMU for ezgo (versioned as 0.7.1+nmu1) and
uploaded it to DELAYED/15. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru ezgo-0.7.1/debian/changelog ezgo-0.7.1+nmu1/debian/changelog
--- ezgo-0.7.1/debian/changelog 2009-11-27 02:17:38.0 -0500
+++ ezgo-0.7.1+nmu1/debian/changelog2019-08-22 16:30:31.0 -0400
@@ -1,3 +1,30 @@
+ezgo (0.7.1+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+The version in Debian greatly lacks behind the one in packaging
+repository. However, this upload would only fix obvious and
+important bugs instead of releasing a new version.
+  * debian/control:
++ Set package priority to optional instead of extra.
++ Update Vcs-* fields to point at repo under Salsa blends-team.
+- Remove the DMUA field.
++ Bump Standards-Version to 4.4.0.
++ Bump debhelper compat to v12.
++ Remove nonexistent maintainer team (debian-ezgo-packaging),
+  promote Andrew Lee as the maintainer.
+  (Closes: #899923, #785284, #696580)
++ Add Franklin Weng into the uploader list.
+  * debian/source/format: Use "3.0 (native)" source package format.
+  * tasks:
++ Replace all gcalctool with gnome-calculator.
+  (Closes: #788771)
++ Replace iceweasel with firefox-esr.
++ Replace openoffice.org with libreoffice.
+- Remove amarok and gnome-media since they are removed from Debian.
+  (Closes: #786951)
+
+ -- Boyuan Yang   Thu, 22 Aug 2019 16:30:31 -0400
+
 ezgo (0.7.1) unstable; urgency=low
 
   * Initial release
diff -Nru ezgo-0.7.1/debian/compat ezgo-0.7.1+nmu1/debian/compat
--- ezgo-0.7.1/debian/compat2009-11-06 16:07:05.0 -0500
+++ ezgo-0.7.1+nmu1/debian/compat   1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-7
diff -Nru ezgo-0.7.1/debian/control ezgo-0.7.1+nmu1/debian/control
--- ezgo-0.7.1/debian/control   2010-01-09 03:11:47.0 -0500
+++ ezgo-0.7.1+nmu1/debian/control  2019-08-22 16:30:31.0 -0400
@@ -1,20 +1,19 @@
 # This file is autogenerated via make -f debian/rules dist.  Do not edit!
 Source: ezgo
 Section: misc
-Priority: extra
-Maintainer: Debain EzGo Packaging Team <
debian-ezgo-packag...@lists.alioth.debian.org>
-Uploaders: Andrew Lee (李健秋) ,
- Andreas Tille 
-Build-Depends: debhelper (>= 7), blends-dev (>= 0.6.6)
-Standards-Version: 3.8.3
-Dm-Upload-Allowed: yes
+Priority: optional
+Maintainer: Andrew Lee (李健秋) 
+Uploaders: Andreas Tille ,
+ Franklin Weng 
+Build-Depends: debhelper-compat (= 12), blends-dev (>= 0.6.6)
+Standards-Version: 4.4.0
 Homepage: http://wiki.debian.org/DebianEzGo
-Vcs-Browser: 
http://svn.debian.org/wsvn/blends/projects/ezgo/trunk/debian-ezgo/?rev=0&sc=0
-Vcs-Svn: svn://svn.debian.org/blends/projects/ezgo/trunk/debian-ezgo/
+Vcs-Git: https://salsa.debian.org/blends-team/ezgo.git
+Vcs-Browser: https://salsa.debian.org/blends-team/ezgo
 
 Package: ezgo-tasks
 Architecture: all
-Depends: tasksel
+Depends: tasksel, ${misc:Depends}
 Description: EzGo tasks for tasksel
  This package provides EzGo tasks in tasksel.
  .
@@ -23,9 +22,9 @@
 
 Package: ezgo-accessories
 Architecture: all
-Depends: ezgo-tasks (= ${binary:Version})
-Recommends: convertall, gcalctool, gedit, gnome-utils, gtkwhiteboard,
lxterminal, stardict, tomboy, xournal
-Description: EzGo Accessories
+Depends: ezgo-tasks (= ${binary:Version}), ${misc:Depends}
+Recommends: convertall, gnome-calculator, gedit, gnome-utils, gtkwhiteboard,
lxterminal, stardict, tomboy, xournal
+Description: Debian EzGo Accessories
  The EzGo is a LiveCD created by OSS Application Consulting
  Centre(OSSACC) which is a Ministry of Education Taiwan funded project,
  and it's executive by the Software Liberty Association of Taiwan(SLAT).
@@ -37,10 +36,10 @@
 
 Package: ezgo-education
 Architecture: all
-Depends: ezgo-tasks (= ${binary:Version})
+Depends: ezgo-tasks (= ${binary:Version}), ${misc:Depends}
 Recommends: avogadro, bkchem, celestia, drgeo, gchempaint, gcompris, gcu-bin, 
ghemical, kalgebra, kalzium, kanagram, kbruch, kgeography, khangman, kig,
klettres, kmplot, kstars, ktouch, kturtle, kwordquiz, marble, parley, pymol,
stellarium, step, wxmaxima
 Suggests: kayali, scratch
-Description: EzGo Education
+Description: Debian EzGo Education
  The EzGo is a LiveCD created by OSS Application Consulting
  Centre(OSSACC) which is a Ministry of Education Taiwan funded project,
  and it's executive by the Software Liberty Association of Taiwan(SLAT).
@@ -52,10 +51,10 @@
 
 Package: ezgo-games
 Architecture: all
-Depends: ezgo-tasks (= ${binary:Version})
+Depends: ezgo-tasks (= ${binary:Version}), ${misc:Depends}
 Recommends: frozen-bubble, gnome-games, kblocks, knetwalk, kolf, ktuberling,
lbreakout2, pinball, pingus, supertux, supertuxkart, torcs, tuxmath, tuxpuck,
tuxtype
 Suggests: planetpenguin-racer
-Description: EzGo Games
+D

Bug#935460: stretch-pu: package sox/14.4.1-5+deb9u2

[Moritz Muehlenhoff]

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

Attached debdiff fixes a number of bugs in sox. These have been in jessie
for a while already (Stretch and Jessie have the same base version as the
package was unmaintained for a while) and I've ran some of the POCs on
the Stretch build. Debdiff below.

Cheers,
Moritz

diff -Nru sox-14.4.1/debian/changelog sox-14.4.1/debian/changelog
--- sox-14.4.1/debian/changelog 2019-02-01 16:18:21.0 +0100
+++ sox-14.4.1/debian/changelog 2019-08-16 00:28:55.0 +0200
@@ -1,3 +1,16 @@
+sox (14.4.1-5+deb9u2) stretch; urgency=medium
+
+  * Sync up patches with 14.4.1-5+deb8u4 (sans some uncommented patches)
+CVE-2019-8354 CVE-2019-8355 CVE-2019-8356 CVE-2019-8357 (Closes: #927906)
+CVE-2019-1010004 CVE-2017-18189 (Closes: #881121)
+CVE-2017-15642 (Closes: #882144)
+CVE-2017-15372 (Closes: #878808)
+CVE-2017-15371 (Closes: #878809)
+CVE-2017-15370 (Closes: #878810)
+CVE-2017-11359 CVE-2017-11358 CVE-2017-11332 (Closes: #870328)
+
+ -- Moritz Mühlenhoff   Fri, 16 Aug 2019 00:28:55 +0200
+
 sox (14.4.1-5+deb9u1) stretch; urgency=medium
 
   * Non-maintainer upload.
diff -Nru sox-14.4.1/debian/patches/0001-Clean-up-lsx_malloc-and-friends.patch 
sox-14.4.1/debian/patches/0001-Clean-up-lsx_malloc-and-friends.patch
--- sox-14.4.1/debian/patches/0001-Clean-up-lsx_malloc-and-friends.patch
1970-01-01 01:00:00.0 +0100
+++ sox-14.4.1/debian/patches/0001-Clean-up-lsx_malloc-and-friends.patch
2019-05-10 01:08:00.0 +0200
@@ -0,0 +1,80 @@
+From ccedd08802f62ed896f69d778e6a106d00f9ab58 Mon Sep 17 00:00:00 2001
+From: Mans Rullgard 
+Date: Tue, 8 Dec 2015 22:52:41 +
+Subject: [PATCH 1/5] Clean up lsx_malloc() and friends
+
+---
+ src/Makefile.am |  2 +-
+ src/xmalloc.c   | 30 +-
+ src/xmalloc.h   |  7 ---
+ 3 files changed, 30 insertions(+), 9 deletions(-)
+
+diff --git a/src/xmalloc.c b/src/xmalloc.c
+index 9bf15969..56fe6944 100644
+--- a/src/xmalloc.c
 b/src/xmalloc.c
+@@ -20,6 +20,16 @@
+ #include "sox_i.h"
+ #include 
+ 
++static void *lsx_checkptr(void *ptr)
++{
++  if (!ptr) {
++lsx_fail("out of memory");
++exit(2);
++  }
++
++  return ptr;
++}
++
+ /* Resize an allocated memory area; abort if not possible.
+  *
+  * For malloc, `If the size of the space requested is zero, the behavior is
+@@ -34,10 +44,20 @@ void *lsx_realloc(void *ptr, size_t newsize)
+ return NULL;
+   }
+ 
+-  if ((ptr = realloc(ptr, newsize)) == NULL) {
+-lsx_fail("out of memory");
+-exit(2);
+-  }
++  return lsx_checkptr(realloc(ptr, newsize));
++}
+ 
+-  return ptr;
++void *lsx_malloc(size_t size)
++{
++  return lsx_checkptr(malloc(size + !size));
++}
++
++void *lsx_calloc(size_t n, size_t size)
++{
++  return lsx_checkptr(calloc(n + !n, size + !size));
++}
++
++char *lsx_strdup(const char *s)
++{
++  return lsx_checkptr(strdup(s));
+ }
+diff --git a/src/xmalloc.h b/src/xmalloc.h
+index 9ee77f63..92ac64d9 100644
+--- a/src/xmalloc.h
 b/src/xmalloc.h
+@@ -23,10 +23,11 @@
+ #include 
+ #include 
+ 
+-#define lsx_malloc(size) lsx_realloc(NULL, (size))
+-#define lsx_calloc(n,s) (((n)*(s))? memset(lsx_malloc((n)*(s)),0,(n)*(s)) : 
NULL)
++LSX_RETURN_VALID void *lsx_malloc(size_t size);
++LSX_RETURN_VALID void *lsx_calloc(size_t n, size_t size);
++LSX_RETURN_VALID char *lsx_strdup(const char *s);
++
+ #define lsx_Calloc(v,n)  v = lsx_calloc(n,sizeof(*(v)))
+-#define lsx_strdup(p) ((p)? strcpy((char *)lsx_malloc(strlen(p) + 1), p) : 
NULL)
+ #define lsx_memdup(p,s) ((p)? memcpy(lsx_malloc(s), p, s) : NULL)
+ #define lsx_valloc(v,n)  v = lsx_malloc((n)*sizeof(*(v)))
+ #define lsx_revalloc(v,n)  v = lsx_realloc(v, (n)*sizeof(*(v)))
+-- 
+2.20.1
+
diff -Nru 
sox-14.4.1/debian/patches/0002-fix-possible-buffer-size-overflow-in-lsx_make_lpf-CV.patch
 
sox-14.4.1/debian/patches/0002-fix-possible-buffer-size-overflow-in-lsx_make_lpf-CV.patch
--- 
sox-14.4.1/debian/patches/0002-fix-possible-buffer-size-overflow-in-lsx_make_lpf-CV.patch
   1970-01-01 01:00:00.0 +0100
+++ 
sox-14.4.1/debian/patches/0002-fix-possible-buffer-size-overflow-in-lsx_make_lpf-CV.patch
   2019-05-10 01:08:00.0 +0200
@@ -0,0 +1,23 @@
+From f70911261a84333b077c29908e1242f69d7439eb Mon Sep 17 00:00:00 2001
+From: Mans Rullgard 
+Date: Wed, 24 Apr 2019 14:57:34 +0100
+Subject: [PATCH 2/5] fix possible buffer size overflow in lsx_make_lpf()
+ (CVE-2019-8354)
+
+The multiplication in the size argument malloc() might overflow,
+resulting in a small buffer being allocated.  Use calloc() instead.
+---
+ src/effects_i_dsp.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/src/effects_i_dsp.c
 b/src/effects_i_dsp.c
+@@ -256,7 +256,7 @@
+ double * lsx_make_lpf(int num_taps, double Fc, double beta, double scale, 
sox_bool dc_norm)
+ {
+   int i, m = num_taps - 1;
+-  double * h = malloc(num_taps * sizeof(*h)), sum = 0;
++

Bug#935350: python-qt4reactor: Qt4 removal from Bullseye

[Dmitry Shachnev]

On Thu, Aug 22, 2019 at 07:50:20PM +0200, Moritz Mühlenhoff wrote:
> There's a separate qt5reactor upstream source which can be packaged if
> someone needs it in the future.

Actually it was uploaded to NEW yesterday:

https://ftp-master.debian.org/new/qt5reactor_0.5-1.html
https://salsa.debian.org/qt-kde-team/extras/qt5reactor

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#931610: stretch-pu: package pound/2.7-1.3+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2019-08-22 at 11:51 +0200, Carsten Leonhardt wrote:
[...]
> longer testing revealed a regression (CPU load built up slowly,
> finally reaching 100%).
> 
> I found a fix and have applied it, the fixed version is running on
> live servers since at least a week now, without a sign of abnormal
> CPU load.
> 

Thanks for the update. Please go ahead.

Regards,

Adam

Bug#930112: stretch-pu: package node-growl/1.7.0-1+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2019-06-07 at 12:19 +0200, Xavier Guimard wrote:
> node-growl in stretch is vulnerable to #900868 / CVE-2017-16042. I
> imported upstream patch and embedded the little shell-escape module.

None of this makes me happy, but I guess go for it...

Regards,

Adam

Bug#935459: gkrellm crashes

[Nicolas Patrois]

Package: gkrellm
Version: 2.3.10-2+b1
Severity: important

Dear Maintainer,

Since the last upgrade and reboot, gkrellm crashes.
The message from the console is:
Gtk-Message: 22:38:02.810: Failed to load module "atk-bridge"
sh: 1: /usr/local/share/gkrellm/GrabWeather: not found
The program 'gkrellm' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadPixmap (invalid Pixmap parameter)'.
  (Details: serial 5212 error_code 4 request_code 56 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

strace does not explain the issue.



-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.17.0-3-686-pae (SMP w/3 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR:fr:en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gkrellm depends on:
ii  libatk1.0-0  2.32.0-2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-4
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.60.6-2
ii  libgnutls-openssl27  3.6.9-4
ii  libgnutls30  3.6.9-4
ii  libgtk2.0-0  2.24.32-3
ii  libice6  2:1.0.9-2
ii  libntlm0 1.5-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  libsensors5  1:3.5.0-3
ii  libsm6   2:1.2.3-1
ii  libx11-6 2:1.6.7-1

gkrellm recommends no packages.

gkrellm suggests no packages.

-- no debconf information

Bug#906258: stretch-pu: package yubico-piv-tool/1.4.2-2

[Adam D. Barratt]

On Sat, 2019-02-23 at 22:41 +0100, Julien Cristau wrote:
> On 2/23/19 7:56 PM, Nicolas Braud-Santoni wrote:
> > On Sat, Feb 23, 2019 at 02:27:04PM +0100, Nicolas Braud-Santoni
> > wrote:
> > > On Fri, Feb 15, 2019 at 04:55:58PM +0100, Nicolas Braud-Santoni
> > > wrote:
> > > > On Wed, Feb 13, 2019 at 03:34:50PM +0100, Nicolas Braud-Santoni 
> > > > wrote:
> > > > > I assume I can't just dput this, as it already exists in
> > > > > stable-new.
> > > > > Could you reject the existing package first, and I will
> > > > > reupload?
> > > > 
> > > > Uploaded a new revision at the request of jcristau.
> > > 
> > > Ping?
> > 
> > Nevermind, ftpmaster rejected the upload:
> > 
> They did not; I did, as I told you in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906258#69

The mail claims to be from "Debian FTP Masters" as it is sent by dak at
the point of rejection. However, in the case of rejections from
{,old}stable-new, dak is simply carrying out requests from the Release
Team.

> > On Sat, Feb 23, 2019 at 05:47:07PM +, Debian FTP Masters wrote:
> > > yubico-piv-tool - inappropriate changelog entry
> > 
> > Dear ftpmasters, could you clarify in which way the changelog entry
> > is inappropriate, and what would be an appropriate changelog entry?
> > 
> An appropriate changelog entry is one that describes the changes made
> to the package.  For example, "Remove cruft that was included in the
> source package by mistake" would be one way to describe the changes
> in your upload.

Ping on a new upload? There's just over a week if you want to get this
in to 9.10.

Regards,

Adam

Bug#928276: stretch-pu: package biomaj-watcher/1.2.2-4+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2019-05-01 at 03:58 +0200, Andreas Beckmann wrote:
> I finally found a solution for the biomaj-watcher jessie->stretch
> upgrade problem I noticed long ago. #866980
> We need to ensure that the build-time jdk is also available at run-
> time.
> The problem occurred if biomaj-watcher from stretch, built against
> openjdk-8, was installed (and configured) along openjdk-7 from jessie
> as default-jdk (which was not jet upgraded) ...
> So lets just tighten the dependencies and the problem is gone.

Please go ahead; thanks.

Regards,

Adam

Bug#934704: buster-pu: package node-lodash/4.17.11+dfsg-2+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2019-08-13 at 19:07 +0200, Xavier Guimard wrote:
> node-lodash is vulnerable to prototype pollution (#933079,
> CVE-2019-10744). I imported upstream fix in the attached debdiff.

Please go ahead.

Regards,

Adam

Bug#935394: python3-django breaks python3-mysqldb (<<1.3.13), but only python3-mysqldb 1.3.10 is available

[Paul Gevers]

Control: reassign 935394 python3-mysqldb
Control: affects 935394 + python3-django

Hi Chris,

On Thu, 22 Aug 2019 09:30:54 -0700 "Chris Lamb"  wrote:
> reassign 935394 python3-mysqldb
> affects 935394 + python3-django

> Therefore I think the best solution would be to upload a new version
> of python3-mysqldb. I'm taking the liberty of reassigning (with a
> "reverse" affects for visibility) here in lieu of asking you to file a
> separate bug.

Except, you didn't :) Hope I did so now.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#935057: RM: afl -- ROM; upstream not actively developed anymore

[Witold Baryluk]

Package: ftp.debian.org
Followup-For: Bug #935057


Hi,

I just noticed removal of 'afl' from testing, because it was removed from
unstable, but I find this removal a bit quick in jumping to conclussions
that afl is unmaintained.

There was a release just few days ago, and the project is hosted in more
open manner than before on github (previously it was maintained by one
person, and without any real source control system accessible to public,
which also did affect me, as I did send patches to original author, and
they were never responded to or merged):

https://groups.google.com/forum/#!topic/afl-users/ODNQwYqZGC0

https://groups.google.com/forum/#!topic/afl-users/WX8NdcB9GmM

GitHub shows plenty of pull requests and merged code in recent days:

https://github.com/google/AFL/pulls?utf8=%E2%9C%93&q=is%3Apr



Version 2.53b correctly build with clang / llvm 8.0.

In fact it also does build with clang 9 too.

And even before that there were patches to do so with 2.52b (
https://github.com/vanhauser-thc/afl-patches ).

2.52c released month ago, also does support llvm / clang++ from 3.8 to up
to including 8. https://groups.google.com/forum/#!topic/afl-users/jHPw2LvbE0A



It is more a question to maintainer of afl package.

I wish the package was back in Debian, as I did find it pretty useful for
my work, and less manually compiled packages the better. :)

Thank you,
Witold

Bug#932376: pam: patch disabling request for securetty from pam_unix

[Thorsten Glaser]

Package: libpam-modules
Version: 1.3.1-5
Followup-For: Bug #932376

I get messages like this on each login in my syslog:

Aug 22 22:05:02 tglase-nb login[5670]: pam_unix(login:auth): Couldn't open 
/etc/securetty: No such file or directory
Aug 22 22:05:03 tglase-nb login[5670]: pam_unix(login:auth): Couldn't open 
/etc/securetty: No such file or directory
Aug 22 22:05:03 tglase-nb login[5670]: pam_unix(login:session): session opened 
for user tglase by LOGIN(uid=0)

Please fix the useless securetty messages. Am I supposed
to sudo touch the file, or what?

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

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

Versions of packages libpam-modules depends on:
ii  debconf [debconf-2.0]  1.5.73
ii  libaudit1  1:2.8.5-2
ii  libc6  2.28-10
ii  libdb5.3   5.3.28+dfsg1-0.6
ii  libpam-modules-bin 1.3.1-5
ii  libpam0g   1.3.1-5
ii  libselinux12.9-2+b2

libpam-modules recommends no packages.

libpam-modules suggests no packages.

-- debconf information:
  libpam-modules/disable-screensaver:

Bug#682342: Latest patch successfully tested

[Philipp Kern]

On 8/16/2019 8:34 PM, Nishanth Aravamudan wrote:
> On 15.08.2019 [17:08:39 +0200], Cyril Brulebois wrote:
>> Nishanth Aravamudan  (2019-08-14):
>>> We are able to reproduce this issue at will in Ubuntu Bionic's
>>> installer (not identical to Debian's, but code-wise in this path the
>>> same).  While quite a while after the last update from Philipp, we
>>> tested the patch (netcfg_dhcp_domain.patch) after updating it to avoid
>>> a compilation issue, we found it did fix the problem for us.
>>>
>>> I am not sure if I can get Debian into our infrastructure to test
>>> explicitly, but I will work on it; at the same time,  the code change
>>> seems straightforward.
>>
>> Thanks for your feedback. Care to share the fixed version? :)
> 
> D'oh! I'm sorry, I thought I did. The patch we tested was:
> 
> diff -Naur a/dhcp.c b/dhcp.c
> --- a/dhcp.c  2017-10-10 14:01:42.0 +
> +++ b/dhcp.c  2019-08-14 01:04:58.339325357 +
> @@ -590,7 +590,7 @@
>  preseed_hostname_from_fqdn(client, buf);
>  }
>  
> -if (netcfg_get_hostname (client, "netcfg/get_hostname", 
> hostname, 1)) {
> +if (netcfg_get_hostname (client, "netcfg/get_hostname", 
> hostname, !have_domain)) {
>  /*
>   * Going back to POLL wouldn't make much sense.
>   * However, it does make sense to go to the retry
> diff -Naur a/netcfg-common.c b/netcfg-common.c
> --- a/netcfg-common.c 2017-10-10 14:04:08.0 +
> +++ b/netcfg-common.c 2019-08-13 20:01:13.606510273 +
> @@ -1060,14 +1060,24 @@
>  continue;
>  }
>  
> -if (accept_domain && (s = strchr(hostname, '.'))) {
> -di_info("Detected we have an FQDN; splitting and setting 
> domain");
> -if (s[1] == '\0') { /* "somehostname." <- . should be ignored */
> +if ((s = strchr(hostname, '.'))) {
> +di_info("Detected an FQDN in hostname");
> +if (s[1] == '\0') {
> +/* "somehostname." <- . should be ignored */
>  *s = '\0';
> -} else { /* assume we have a valid domain name given */
> -strncpy(domain, s + 1, MAXHOSTNAMELEN);
> -debconf_set(client, "netcfg/get_domain", domain);
> -have_domain = 1;
> +di_info("Stripped trailing dot from hostname");
> +} else {
> +/* assume that the domain is valid and copy it if
> + * accept_domain is set; just use the hostname if
> + * it is unset
> + */
> +if (accept_domain) {
> +strncpy(domain, s + 1, MAXHOSTNAMELEN);
> + di_info("Setting domain to %s", domain);

This needs indenting fix-up.

> +debconf_set(client, "netcfg/get_domain", domain);
> +have_domain = 1;
> +}
> +/* strip the domain from the hostname */
>  *s = '\0';
>  }
>  }
> 
>> I'm a little reluctant to blindly merging this patch (originally
>> labeled “untested”) without a go from its author. Philipp, should
>> I go ahead?
> 
> Totally understood! I just wanted to make sure to revive this issue, as
> I'd also like to get it fixed in Ubuntu! Like I said, I will do my best
> to test and reproduce the fix with stock Debian.

I think this should be fine and we're early in the release cycle to find
potential problems if there are any.

Obviously it'd be great to have a test hardness with a DHCP server
sending various bits and us verifying that netcfg did the right thing.
But I'd surprised to find the time for that myself.

Kind regards and thanks
Philipp Kern

Bug#935365: buildd.debian.org: allowing self-service givebacks for Failed packages?

[Philipp Kern]

Hey Samuel,

thanks for your feedback!

On 8/22/2019 12:17 AM, Samuel Thibault wrote:
> The self-service giveback is currently not available for packages in the
> Failed state. I wonder if such a restriction is really useful.
> 
> The thing is: apparently only I do this, but I always set hurd-i386
> package build failures in the Failed state with the appropriate failure
> log lines, which are very helpful for sorting out the porting work
> (see https://people.debian.org/~sthibault/graph-top.txt), and packages
> maintainers have already told me they appreciate this, because I know
> well the hurd-i386 failures and can thus easily point out the actual
> problems to maintainers.
> 
> But if people can not giveback due to this even in cases where it's a
> transient failure or lagging dependency version, I'am afraid they will
> now not send a mail for giving back on hurd-i386, thinking that I have
> set the Failed state for a stronger reason than I actually meant.
> 
> Put another way, this restriction on the Failed state leads me to think
> I should rather stop setting packages in the Failed state, but then it's
> detrimental to the porting work triaging.

I think I came from the point where Failed is a manually set state that
conveyed a meaning that we should not just erase, especially if we face
opportunistic give-backs. At the same time that sort of depends on the
frequency of the use of this feature.

Traditionally `Failed' was supposed to be for failure states that were
known to require another package upload. I guess what you are saying
here is that you'd also set Failed if another package is at fault. I can
relate to that, as expressive documented failure reasons are always
better than just log tails - if you have the time to add those annotations.

I also don't know if we have a good way of gauging consensus among
porters here. I added buildd-maintainers@ to bcc. Please chime in if you
have an opinion here.

In the end it's easy to do. I'm sympathetic to just allow it and see if
it actually causes trouble. AFAIK we also preserve the last failure
reason in the database and do not immediately wipe it out (TBC).

> Actually, even when the Fail state has been set manually on archs (e.g.
> a know bug affecting all archs), it would still make sense to allow
> maintainers to trigger the giveback when the bug is known to be fixed by
> another package upload.

I really do not want to check if someone is a package's maintainer if I
can avoid it. But then again this is also something that could
legitimately be done by the uploader of the other package anyway.

Kind regards and thanks
Philipp Kern

Bug#935458: RM: pump/0.8.24-7.1

[Moritz Muehlenhoff]

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

Hi,
please remove pump in the 10.1 point release. It's unmaintained both in Debian
and upstream and security-buggy. I've gotten in touch with Red Hat (the former
upstream), it was formerly developed by Red Hat by for RHEL 5 and they
recommended very strongly to remove it.

Cheers,
Moritz

Bug#588666: boot message stuck onto next message

[Thorsten Glaser]

On Fri, 23 Aug 2019, 積丹尼 Dan Jacobson wrote:

> DB> Can you please elaborate what change to startpar you propose? I did not
> DB> understand.
> 
> I think I am saying:
> 
> Each line a process sends:
> * should be prefixed by the name of the process that sent it.
> * should end with a newline.

And (#398269) each line should be either from a process or the kernel,
distinguishable enough.

I fully agree, that should be basic and not need discussion.

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

Bug#935307: sysvinit-core: weird access control message during system boot

[Thorsten Glaser]

On Thu, 22 Aug 2019, Dmitry Bogatov wrote:

> $ apt-file find tomoyo-init
> tomoyo-tools: /sbin/tomoyo-init
> tomoyo-tools: /usr/share/man/man8/tomoyo-init.8.gz

Yeah, I don’t have that installed, and don’t want.

> Interesting. `grep -R tomoyo` returns nothing.

A grep (over /{,usr/}{bin,lib*,sbin}) of tomoyo-init really finds nothing.

The string tomoyo is found only in…

Binary file /bin/udevadm matches
Binary file /lib/systemd/systemd-udevd matches

Perhaps it’s a change there? I found nothing in the changelog though…

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#935457: RM: synergy -- RoQA; RC-buggy, depends on Qt4

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove synergy. It's orphaned and RC-buggy for a while
and there's a maintained fork in the archive (barrier). It
also depends on Qt4 which is going away.

Cheers,
Moritz

Bug#875161: [qtm] Future Qt4 removal from Buster

[Moritz Mühlenhoff]

On Sat, Sep 09, 2017 at 11:08:10PM +0200, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Source: qtm
> 
> Therefore, please take the time and:
> - contact your upstream (if existing) and ask about the state of a Qt5
> port of your application
> - if there are no activities regarding porting, investigate whether there are
> suitable alternatives for your users
> - if there is a Qt5 port that is not yet packaged, consider packaging it
> - if both the Qt4 and the Qt5 versions already coexist in the Debian
> archives, consider removing the Qt4 version

Hi Patryk,
are you still using/maintaining qtm? (Given that it wasn't uploaded since 2016)

The current releases support Qt5, otherwise we can also remove the package.

Cheers,
Moritz

Bug#875207: [tipp10] Future Qt4 removal from Buster

[Moritz Mühlenhoff]

On Sat, Sep 09, 2017 at 11:11:21PM +0200, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Source: tipp10
> 
> 
> Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> as [announced] in:
> 
> Therefore, please take the time and:
> - contact your upstream (if existing) and ask about the state of a Qt5
> port of your application
> - if there are no activities regarding porting, investigate whether there are
> suitable alternatives for your users
> - if there is a Qt5 port that is not yet packaged, consider packaging it
> - if both the Qt4 and the Qt5 versions already coexist in the Debian
> archives, consider removing the Qt4 version

Hi Christoph,
tipp10 seems to be dead upstream (not surprising given that it seems to be
based on an old diploma thesis)

Are you planning to port it to Qt5 yourself? Otherwise we should remove it
from the archive.

Cheers,
Moritz

Bug#588666: Dmitry mail bounce

[積丹尼 Dan Jacobson]

Dmitry, your mail is bouncing.

Bug#934359: clamav: ZIP bomb causes extreme CPU spikes

[Hugo Lefeuvre]

Hi,

> >  The zip bomb vulnerability mitigated in 0.101.3 has been assigned the
> >  CVE identifier CVE-2019-12625. Unfortunately, a workaround for the zip-
> >  bomb mitigation was immediately identified. To remediate the zip-bomb
> >  scan time issue, a scan time limit has been introduced in 0.101.4. This
> >  limit now resolves ClamAV's vulnerability to CVE-2019-12625.
> > 
> > The default scan time limit is 2 minutes (12 milliseconds).
> > 
> > To customize the time limit:
> > - use the clamscan  --max-scantime option
> > - use the clamd  MaxScanTime config option
> > 
> > Libclamav users may customize the time limit using the cl_engine_set_num
> > function. For example:
> > 
> > C
> > cl_engine_set_num(engine, CL_ENGINE_MAX_SCANTIME, 
> > time_limit_milliseconds)
> > 
> > Thanks to David Fifield for reviewing the zip-bomb mitigation in
> > 0.101.3 and reporting the issue.
> 
> https://blog.clamav.net/2019/08/clamav-01014-security-patch-release-has.html

Great! Is anybody working on 0.101.4 updates for stretch/buster? I plan to
backport the update to jessie after that.

regards,
Hugo

-- 
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C


signature.asc
Description: PGP signature

Bug#398269: kaction bounce

[積丹尼 Dan Jacobson]

By the way, your mail is bouncing.

550 5.7.23 : Recipient address rejected:
Message rejected due to: SPF fail - not authorized. Please see 
http://www.openspf.net/Why?s=mfrom;id=jida...@jidanni.org;ip=82.195.75.114;r=

www.openspf.net refused to connect.

Bug#588666: boot message stuck onto next message

[積丹尼 Dan Jacobson]

DB> Can you please elaborate what change to startpar you propose? I did not
DB> understand.

I think I am saying:

Each line a process sends:
* should be prefixed by the name of the process that sent it.
* should end with a newline.

Bug#398269: initscripts: USB messages interleave fsck's

[積丹尼 Dan Jacobson]

> "DB" == Dmitry Bogatov  writes:

DB> Is there still interest in this bug?

Yes.

DB> The change is quite trivial, but I have to be sure that there is still
DB> someone who want it.

Bug#934507: buster-pu: package openldap/2.4.47+dfsg-3+deb10u1

[Paul Gevers]

Hmm, sorry for the noise, that is because of bug 905563. I forgot I had
that blocked in the past.

Paul

On 22-08-2019 21:07, Paul Gevers wrote:
> Hi Ryan,
> 
> On Wed, 14 Aug 2019 09:53:22 -0700 Ryan Tandy  wrote:
>> On Tue, Aug 13, 2019 at 06:25:13PM +0100, Adam D. Barratt wrote:
>>> Please go ahead; thanks.
>>
>> Thank you. Uploaded, accepted, and visible on the queue page now.
> 
> Do you have any idea why the autopkgtest of gnupg2 (maintainers in CC)
> is failing with the new openldap package? Looking at the error it seems
> that wine32 (maintainers in CC) in a multiarch environment isn't
> installable on amd64 anymore. libwine does have a dependency on
> libldap-2.4.2 so this isn't totally weird.
> 
> Paul
> 



signature.asc
Description: OpenPGP digital signature

Bug#934507: buster-pu: package openldap/2.4.47+dfsg-3+deb10u1

[Paul Gevers]

Hi Ryan,

On Wed, 14 Aug 2019 09:53:22 -0700 Ryan Tandy  wrote:
> On Tue, Aug 13, 2019 at 06:25:13PM +0100, Adam D. Barratt wrote:
> >Please go ahead; thanks.
> 
> Thank you. Uploaded, accepted, and visible on the queue page now.

Do you have any idea why the autopkgtest of gnupg2 (maintainers in CC)
is failing with the new openldap package? Looking at the error it seems
that wine32 (maintainers in CC) in a multiarch environment isn't
installable on amd64 anymore. libwine does have a dependency on
libldap-2.4.2 so this isn't totally weird.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#849714: RFS: guerillabackup/1.0-1 [ITP] -- resilient, distributed backup and archiving solution

[halfdog]

Dear mentors,

I am looking for a sponsor for my package "guerillabackup". I
have updated the Salsa repository to build on Debian Bullseye
also removing mentors.debian.net lintian warnings on old versions.
I have tested the package on Bullseye machines.

 * Package name: guerillabackup
   Version : 0.0.1-1
   Upstream Author : m...@halfdog.net
 * URL : https://github.com/halfdog/guerillabackup
 * License : LGPL-3.0+
 * Vcs : https://salsa.debian.org/halfdog-guest/guerillabackup
   Section : misc

It builds those binary packages:

  guerillabackup - resilient, distributed backup and archiving solution

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/guerillabackup/guerillabackup_0.0.1-1.dsc

Changes since the last upload:

   * Initial packaging of guerillabackup (Closes: #849714)

Regards,
  hd

Bug#934359: clamav: ZIP bomb causes extreme CPU spikes

[Salvatore Bonaccorso]

Hi,

On Mon, Aug 12, 2019 at 08:35:25AM +0200, Sebastian Andrzej Siewior wrote:
> control: found -1 0.98.6+dfsg-1
> 
> On 2019-08-12 08:21:22 [+0200], Hugo Lefeuvre wrote:
> > Hi Sebastian,
> Hi,
> 
> > I'm sorry if this sounded insistent, it was not intended like that.
> 
> No problem, everything is okay. I was planning to open a similar bug
> just to point out that the issue is not completly fixed so the release
> team is aware while processing the pu bug.
> I just wanted to make clear that we have what upstream has in their
> latest release and we don't lack a patch or so and we are waiting for an
> update.

There is now CVE-2019-12625 specifically assigned for 

>  The zip bomb vulnerability mitigated in 0.101.3 has been assigned the
>  CVE identifier CVE-2019-12625. Unfortunately, a workaround for the zip-
>  bomb mitigation was immediately identified. To remediate the zip-bomb
>  scan time issue, a scan time limit has been introduced in 0.101.4. This
>  limit now resolves ClamAV's vulnerability to CVE-2019-12625.
> 
> The default scan time limit is 2 minutes (12 milliseconds).
> 
> To customize the time limit:
> - use the clamscan  --max-scantime option
> - use the clamd  MaxScanTime config option
> 
> Libclamav users may customize the time limit using the cl_engine_set_num
> function. For example:
> 
> C
> cl_engine_set_num(engine, CL_ENGINE_MAX_SCANTIME, time_limit_milliseconds)
> 
> Thanks to David Fifield for reviewing the zip-bomb mitigation in
> 0.101.3 and reporting the issue.

https://blog.clamav.net/2019/08/clamav-01014-security-patch-release-has.html

Regards,
Salvatore

Bug#935456: No GPU hardware detected with kernel 5.2 for Rpi2b and Rpi3b

[eHenry Berg]

Package: linux-image-armmp
Version: 5.2.0-2

Hello,

I have made a guide for Debian on Rpi here:
https://github.com/evasjo/DebianSbcRaspberry

I have 3 devices (Rpi) and 2 environments (cards).

armhfCard   arm64Card
4.19.0-5:
Rpi2b   Success NotPossible32bitCpu
Rpi3b   Success Success
Rpi3b+  Success Success
5.2.0-2:
Rpi2b   Failure NotPossible32bitCpu
Rpi3b   Failure Failure
Rpi3b+  Success Success

The display manager SDDM does not start with kernel 5.2" for combinations above.

New firmware for armhfCard  2018-08-05 -> 2019-08-17// It did not 
help.
New firmware for arm64Card  2018-12-25 -> 2019-08-17// It did not 
help.

# cat cmdline.txt
dwc_otg.lpm_enable=0 console=tty0 console=${serial}
root=/dev/mmcblk0p3 rootfstype=f2fs elevator=deadline fsck.repair=yes
rootwait cma=416M

# cat config.txt   // armhfCard
device_tree=bcm2837-rpi-3-b-plus.dtb.5.2
kernel=vmlinuz-5.2.0-2-armmp
initramfs initrd.img-5.2.0-2-armmp followkernel

# cat config.txt// arm64Card
arm_control=0x200
device_tree=bcm2837-rpi-3-b-plus.dtb.5.2
kernel=vmlinuz-5.2.0-2-arm64
initramfs initrd.img-5.2.0-2-arm64 followkernel

# cat /etc/apt/sources.list
deb http://ftp.fi.debian.org/debian sid main contrib non-free

# cat /etc/initramfs-tools/modules
crc32
crc32c
f2fs

# cat /etc/modules
f2fs
vc4

"Failure" logs:
# journalctl|grep -i vc4// No rows i.e. no GPU hardware detected
# lsmod|grep -i vc4 // There are rows i.e. the module is loaded
# journalctl|grep -i bcm
bcm2835-power bcm2835-power: Timeout waiting for grafx power OK // A
lot of these rows

"Success", 4.19.0-5:
Kde is running.
shutdown -h now // It does disconnect the power to the monitor.
shutdown -r now // It restarts the computer.

"Success", 5.2.0-2 (5.2.9.1):
Kde is running.
shutdown -h now // It does not disconnect the power to the monitor. It
leaves the monitor on with the text (last row): "reboot: System
halted"
shutdown -r now // It does not restart. It leaves the monitor on with
the text (last row): "Reboot failed -- System halted"

The "Failure" culprit seems to be "bcm2835-power" for Rpi2b and Rpi3b.

Best Regards,
Evald

Bug#935442: xfce4: Alt+F1 shortcuts don't work

[Stephan Lachnit]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I noticed that if you hit Alt+F1 with the default binding, it doesn't open the 
operation menu directly, only if you hit it a second time. The first time I hit 
Alt+F1 the icon of the application menu is getting "marked", the same color as 
if it would be open.If you hit Alt+F1 the first time so that the application 
menu icon becomes marked, and then open a console and execute 
"xfce4-popup-applicationsmenu", it will open the operation menu instead of the 
application menu, which definitely should not happen.
However if the application menu icon is not "grey", executing 
"xfce4-popup-applicationsmenu" will open the application menu as expected.

I'm not quite sure if this is an upstream bug, a debian specific bug or just 
caused by a wired package / configuration on my setup, so if there's a way to 
get logs that could explain this behavior please let me know.
-BEGIN PGP SIGNATURE-
Version: ProtonMail

wsFcBAEBCAAGBQJdXuOLAAoJELNbSepdVj7+zL0QAIIMIch8dhV1D0NPaqvc
AXJkmZUDus5yvbjoRP4PlwYOpcijJqQC+p64HodtxGAHysIbrxW4sZyqrk5y
5rCNwl+ziq+ui2F0VUiuLFQH9PpM/WNZ1/48ZUTI6hPiFaEM2Hn6z7n+5Y/l
eHhj/7uOsJvDPjWVDKPZxIY9sRx1/Dx8Dn+nCmTMUxsO4Lm6lYrFay6TAXzS
WX/SjLU/JxXJ2JTMDT4zl5r3vi6n9VitKksW3DT6UYPHY51U7psl0S/7vR3l
uBn2Dkr4LGmB4hwgg7C04zbkntEs+bWIHO4lkdjFk/szCtoYZi3vAhA6z/Rt
fgwT+MnwGZPrB60UbIgSfXmAAq5CvqUi9fj1O7y3VxQgrSDfJ1Dvgg+W6oo0
r5vSy0eBzXq+Lo81WG+Tx2/UErEI16LXTE6PUv07X9h7GI3TVv3FSexiF/LY
7supD1xW66uTT84496AdPDHoxa9/IfmTRXCg3Qlg7xmwYHkzQ3ZJrmsSNaOx
kU5Nwn2GQM0jZU2s5s1VoZjZQJNm+enMBRywQCSEqsPzQa31EQXi09al1lca
TOm/AO8parU64SaShlCKSYeeg3UHgFJj4DRl9JQGwkIzrjBJKJqmWokAC4F3
IMZSf5/NWN5W0dvMfJ2BECPzyGxEKFVUTneG8190hLwKAEKgqJLYApikECAd
ajhU
=OpMV
-END PGP SIGNATURE-

Bug#935452: guake: (possible) Missing dependency: gir1.2-wnck-3.0

[Sven Hartge]

Package: guake
Version: 3.6.3-1
Severity: important

Hi!

3.6.3-1 no longer works for me, unless I install gir1.2-wnck-3.0.

When gir1.2-wnck-3.0 is missing, I only get the following error on startup:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 175, in 
activate_name_owner
return self.get_name_owner(bus_name)
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 361, in get_name_owner
's', (bus_name,), **keywords)
  File "/usr/lib/python3/dist-packages/dbus/connection.py", line 651, in 
call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NameHasNoOwner: Could 
not get owner of name 'org.guake3.RemoteControl': no such name

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/guake/main.py", line 359, in main
remote_object = bus.get_object(DBUS_NAME, DBUS_PATH)
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 241, in get_object
follow_name_owner_changes=follow_name_owner_changes)
  File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 248, in __init__
self._named_service = conn.activate_name_owner(bus_name)
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 180, in 
activate_name_owner
self.start_service_by_name(bus_name)
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 278, in 
start_service_by_name
'su', (bus_name, flags)))
  File "/usr/lib/python3/dist-packages/dbus/connection.py", line 651, in 
call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The 
name org.guake3.RemoteControl was not provided by any .service files

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/guake", line 10, in 
sys.exit(exec_main())
  File "/usr/lib/python3/dist-packages/guake/main.py", line 488, in exec_main
if not main():
  File "/usr/lib/python3/dist-packages/guake/main.py", line 373, in main
from guake.guake_app import Guake
  File "/usr/lib/python3/dist-packages/guake/guake_app.py", line 72, in 
from guake.notebook import NotebookManager
  File "/usr/lib/python3/dist-packages/guake/notebook.py", line 37, in 
gi.require_version('Wnck', '3.0')
  File "/usr/lib/python3/dist-packages/gi/__init__.py", line 129, in 
require_version
raise ValueError('Namespace %s not available' % namespace)
ValueError: Namespace Wnck not available

I got the idea to install gir1.2-wnck-3.0 from this issue on GitHub:
https://github.com/Guake/guake/issues/1511#issuecomment-483607667

Grüße,
Sven

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

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

Versions of packages guake depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  gir1.2-glib-2.0  1.58.3-2
ii  gir1.2-gtk-3.0   3.24.10-1
ii  gir1.2-keybinder-3.0 0.3.2-1
ii  gir1.2-notify-0.70.7.8-1
ii  gir1.2-pango-1.0 1.42.4-7
ii  gir1.2-vte-2.91  0.54.2-2
ii  libglib2.0-bin   2.60.6-2
ii  libutempter0 1.1.6-3+b1
ii  python3  3.7.3-1
ii  python3-cairo1.16.2-1+b1
ii  python3-dbus 1.2.8-3
ii  python3-gi   3.32.2-1
ii  python3-pbr  5.1.3-4

guake recommends no packages.

Versions of packages guake suggests:
ii  numix-gtk-theme  2.6.7-4

-- no debconf information

Bug#935453: libconfig-model-tkui-perl breaks libconfig-model-itself-perl autopkgtest

[Paul Gevers]

Source: libconfig-model-tkui-perl, libconfig-model-itself-perl
Control: found -1 libconfig-model-tkui-perl/1.370-1
Control: found -1 libconfig-model-itself-perl/2.018-1
Control: found -1 libconfig-model-itself-perl/2.016-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainers,

With a recent upload (~ one month) of libconfig-model-tkui-perl the
autopkgtest of libconfig-model-itself-perl fails in testing when that
autopkgtest is run with the binary packages of libconfig-model-tkui-perl
from unstable. Adding the new version of libconfig-model-itself-perl
from unstable doesn't help, so libconfig-model-itself-perl fails its own
testsuite now. It passes when run with only packages from testing. In
tabular form:
passfail
libconfig-model-tkui-perl   from testing1.370-1
libconfig-model-itself-perl from testing2.016-1 or 2.018-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 of
libconfig-model-tkui-perl and  libconfig-model-itself-perl to testing
[1]. Due to the nature of this issue, I filed this bug report against
both packages. Can you please investigate the situation and reassign the
bug to the right package?

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=libconfig-model-tkui-perl

https://ci.debian.net/data/autopkgtest/testing/amd64/libc/libconfig-model-itself-perl/2794069/log.gz

not ok 3 - edit is in test mode
#   Failed test 'edit is in test mode'
#   at t/cme-meta-edit.t line 34.
#   'Reading model from /usr/share/perl5/Config/Model
# '
# doesn't match '(?^:Test mode: quit)'
1..3
# Looks like you failed 1 test of 3.
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/3 subtests
t/cme-meta-plugin.t 
Prototype mismatch: sub CORE::GLOBAL::exit: none vs (;$) at
/usr/lib/x86_64-linux-gnu/perl5/5.28/Tk.pm line 415.
ok 1 - compiled
not ok 2 - threw no exceptions
#   Failed test 'threw no exceptions'
#   at t/cme-meta-plugin.t line 52.
#  got: 'Can't call method "fetch_element" on an undefined value
at /usr/share/perl5/Config/Model/Itself/TkEditUI.pm line 80.
#  at /usr/lib/x86_64-linux-gnu/perl5/5.28/Tk/Widget.pm line 203.
# '
# expected: undef
ok 3 - edit plugin and quit
not ok 4 - edit plugin is in test mode
#   Failed test 'edit plugin is in test mode'
#   at t/cme-meta-plugin.t line 57.
#   'Preparing plugin my-plugin for model Fstab found in
/usr/share/perl5/Config/Model
# Use -dev option to create a plugin for a local model (i.e. in
wr_test/plugin-ui)
# '
# doesn't match '(?^:Test mode: save and quit)'
not ok 5 - check content of
wr_test/plugin-ui/models/Fstab.d/my-plugin/Fstab/CommonOptions.pl
#   Failed test 'check content of
wr_test/plugin-ui/models/Fstab.d/my-plugin/Fstab/CommonOptions.pl'
#   at t/cme-meta-plugin.t line 59.
# Could not open file
wr_test/plugin-ui/models/Fstab.d/my-plugin/Fstab/CommonOptions.pl: No
such file or directory
1..5
# Looks like you failed 3 tests of 5.

[...]

Test Summary Report
---
t/cme-meta-edit.t(Wstat: 256 Tests: 3 Failed: 1)
  Failed test:  3
  Non-zero exit status: 1
t/cme-meta-plugin.t  (Wstat: 768 Tests: 5 Failed: 3)
  Failed tests:  2, 4-5
  Non-zero exit status: 3
t/itself-editor.t(Wstat: 6400 Tests: 6 Failed: 0)
  Non-zero exit status: 25
  Parse errors: No plan found in TAP output
Files=11, Tests=85, 162 wallclock secs ( 0.07 usr  0.02 sys + 158.99
cusr  2.99 csys = 162.07 CPU)
Result: FAIL
autopkgtest [17:14:40]: test autodep8-perl-build-deps:
---]



signature.asc
Description: OpenPGP digital signature

Bug#902362: xfce4-session: 'debian/rules clean' after build causes removal of xfce4-session/*.[hc]

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Control: severity -1 important

On Mon, 25 Jun 2018 16:16:49 +0200 Andreas Beckmann  wrote:
> Source: xfce4-session
> Version: 4.13.0-1
> Severity: serious
> Justification: fails to build from source (but built successfully in the
past)
> 
> Hi,
> 
> xfce4-session fails to build twice in a row. The first build succeeds,
> but during subsequent debian/rules clean the following files disappear:
> 
> xfce4-session/xfsm-client-dbus.h
> xfce4-session/xfsm-manager-dbus.c
> xfce4-session/xfsm-marshal.h
> xfce4-session/xfsm-manager-dbus.h
> xfce4-session/xfsm-chooser-icon.h
> xfce4-session/xfsm-client-dbus.c
> xfce4-session/xfsm-marshal.c
> 
> causing the second build to fail.

Thanks, I did noticed that too, unsure where it comes from. In any case, that
doesn't look RC to me, since it does build the first time.

Regards, 
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl1e4mwACgkQ3rYcyPpX
RFvCrggAqx2YSlaHLO1D4To2uW4uDHweKGg8AbIT+Nw+HsWpqvepnn60TeRLrVfR
g72kz2uvxfy2cbwra+RiwtaZICVtddrzgMfahsrYXjOtDE0yKd1/WYPJ0EDHyuhR
vQK5VmX4l9f1U+rghD44/uZMJpnmxk67OnDxCLDYqT3xzCpZ8CJPUAoIhUPGQIs9
0Xs5IxZ09BB/zZpsw8NWeWDzAKGqFEqx11YMjAswsfYtRHoMXH2dGzvaTrXU0JGs
9IuRlvP/caUA1b9vdxqoFbuWsQ3hD3taqQvl1/e6dqbHpwDQg3Lr+RN/8P1W+T6+
qnRvCnh6wXlOQ4V62vAcFQC5bTovow==
=mRVo
-END PGP SIGNATURE-

Bug#935455: python-xarray: autopkgtest regression: test_dask fails

[Paul Gevers]

Source: python-xarray
Version: 0.12.3-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of python-xarray the autopkgtest of python-xarray
fails in testing when that autopkgtest is run with the binary packages
of python-xarray from unstable. It passes when run with only packages
from testing. In tabular form:
   passfail
python-xarray  from testing0.12.3-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=python-xarray

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-xarray/2790734/log.gz
=== FAILURES
===
__ test_dask
___

@requires_dask
def test_dask():
import dask.array as da
>   arr = da.from_array(['a', 'b', 'c'])
E   TypeError: from_array() missing 1 required positional argument:
'chunks'

/usr/lib/python3/dist-packages/xarray/tests/test_accessor_str.py:58:
TypeError
__ TestLoadDataset.test_download_from_github
___

self = 
http_class = 
req = 
http_conn_args = {'check_hostname': None, 'context': None}, host =
'github.com'
h = 

def do_open(self, http_class, req, **http_conn_args):
"""Return an HTTPResponse object for the request, using http_class.

http_class must implement the HTTPConnection API from http.client.
"""
host = req.host
if not host:
raise URLError('no host given')

# will parse host:port
h = http_class(host, timeout=req.timeout, **http_conn_args)
h.set_debuglevel(self._debuglevel)

headers = dict(req.unredirected_hdrs)
headers.update({k: v for k, v in req.headers.items()
if k not in headers})

# TODO(jhylton): Should this be redesigned to handle
# persistent connections?

# We want to make an HTTP/1.1 request, but the addinfourl
# class isn't prepared to deal with a persistent connection.
# It will try to read all remaining data from the socket,
# which will block while the server waits for the next request.
# So make sure the connection gets closed after the (only)
# request.
headers["Connection"] = "close"
headers = {name.title(): val for name, val in headers.items()}

if req._tunnel_host:
tunnel_headers = {}
proxy_auth_hdr = "Proxy-Authorization"
if proxy_auth_hdr in headers:
tunnel_headers[proxy_auth_hdr] = headers[proxy_auth_hdr]
# Proxy-Authorization should not be sent to origin
# server.
del headers[proxy_auth_hdr]
h.set_tunnel(req._tunnel_host, headers=tunnel_headers)

try:
try:
h.request(req.get_method(), req.selector, req.data, headers,
>
encode_chunked=req.has_header('Transfer-encoding'))

/usr/lib/python3.7/urllib/request.py:1317:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _

self = , method =
'GET'
url = '/pydata/xarray-data/raw/master/tiny.nc', body = None
headers = {'Connection': 'close', 'Host': 'github.com', 'User-Agent':
'Python-urllib/3.7'}

def request(self, method, url, body=None, headers={}, *,
encode_chunked=False):
"""Send a complete request to the server."""
>   self._send_request(method, url, body, headers, encode_chunked)

/usr/lib/python3.7/http/client.py:1244:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _

self = , method =
'GET'
url = '/pydata/xarray-data/raw/master/tiny.nc', body = None
headers = {'Connection': 'close', 'Host': 'github.com', 'User-Agent':
'Python-urllib/3.7'}
encode_chunked = False

def _send_request(self, method, url, body, headers, encode_chunked):
# Honor explicitly requested Host: and Accept-Encoding: headers.
header_names = frozenset(k.lower() for k in headers)
skips = {}
if 'host' in header_names:
skips['skip_host'] = 1
if 'accept-encoding' in header_names:
skips['skip_accept_encoding'] = 1

self.putrequest(method, url, **skips)

# chunked encoding will happen if HTTP/1.1 is used and either
# the caller passes encode_chunked=True or the following
# conditions hold:
# 1. content-length has not been explicitly set
# 2. the body

Bug#935454: pymca: autopkgtest regression: Segmentation fault

[Paul Gevers]

Source: pymca
Version: 5.5.0+dfsg-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of pymca the autopkgtest of pymca fails in testing
when that autopkgtest is run with the binary packages of pymca from
unstable. It passes when run with only packages from testing. In tabular
form:
   passfail
pymca  from testing5.5.0+dfsg-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=pymca

https://ci.debian.net/data/autopkgtest/testing/amd64/p/pymca/2791645/log.gz

testCommand (PyMcaBatchTest.testPyMcaBatch) ... ok
testFastFitEdfMap (PyMcaBatchTest.testPyMcaBatch) ... Segmentation fault
autopkgtest [09:18:32]: test command2: ---]

[...]

testCommand (PyMcaBatchTest.testPyMcaBatch) ... ok
testFastFitEdfMap (PyMcaBatchTest.testPyMcaBatch) ... Segmentation fault
autopkgtest [09:26:54]: test command4: ---]



signature.asc
Description: OpenPGP digital signature

Bug#931930: firmware-misc-nonfree: Please, include i915/icl_dmc_ver1_07.bin

[Daniel Baumann]

Hi,

I'm getting these messages too.. the files are included in the upstream
repo, also there's a new upstream tag too (20190815).

It would be nice if this could get uploaded to unstable.

Regards,
Daniel