Bug#931496: redmine: Missing in Debian Buster

[duck]

Quack,

Sorry we've not been more vocal about this.

We worked to get it into Buster in time but various problems happened, 
like Rails 5 late to be stabilized, and we could not get an exception.
I did not know it could be possible to have such a backport for a 
package not present in stable but Antonio told us and we're working in 
this direction already.


Currently the 4.0.4 version in unstable is working fine but 
unfortunately it is blocked from entering testing, which is a 
prerequisite for the backport.
I am discussing a solution with Lucas and hope to have this out of the 
way soon.


In the meanwhile, if you take ruby-rouge and redmine from unstable you 
can migrate to Buster. That's what I did on my own installation and both 
migration and daily use is fine so far. That why I think 4.0.4 is a good 
candidate.


I'll keep you informed of the progress.
\_o<

--
Marc Dequènes

Bug#868527: [buildd-tools-devel] Bug#868527: Bug#868527: want sbuild --no-source or something

[Johannes Schauer]

Hi,

Quoting Sean Whitton (2019-09-02 20:15:23)
> On Mon 02 Sep 2019 at 01:48PM +02, Johannes Schauer wrote:
> > I just had another idea. Since the issue at hand is, that you need a way to
> > transfer the source tree into sbuild and sbuild currently only supports
> > source packages, why can dgit not be amended to build a temporary source
> > package from the git tree it has in a temporary location which it then
> > hands to sbuild or any other builder?
> 
> This is precisely what it already does -- I thought your interest here was in
> removing the intermediate dpkg-source step.

okay now I'm confused. I read [1] and it made me understand that users somehow
have to remember this horribly complicated sbuild command in certain
circumstances.

[1] https://lists.debian.org/23912.64795.250863.812...@chiark.greenend.org.uk

I came back to this bug because I find it horrible for users having to remember
this rune. But now you say that dgit is already taking care of doing the right
thing?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#939370: libxl: Defining a virtual floppy succeeds, but affected domain doesn't start

[Olaf Martens]

Package: libvirt-daemon
Version: 5.0.0-4
Severity: normal

Dear maintainer,

when attempting to define a virtual floppy drive, just defining a domain
supposed to make use of that works fine, however, as soon as it is to be fired
up, libxl hiccups. This has been an issue since libvirt 3.0.0 (with Xen 4.8.0)
and persists with libvirt 5.0.0 (Xen 4.11.0).
By digging through the source code of libxl I noticed that the only special
cases that are checked besides the normal virtual harddisks are virtual CD-ROM
drives.
No such exception is present for FDDs so they hit the functions
libxl__device_from_disk and device_disk_add, both of which report an error
(invalid or unsupported virtual disk identifier). The type of backend (file,
volume, whatever) is irrelevant, the same behavior is experienced in every
case - in both function the error is reported right after the function
libxl__device_disk_dev_number has been invoked, which in turn prevents the VM
in question to start up.

This is particularly nasty if you have to rely on a working FDD to get
something installed.


Kind regards,

Olaf


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

Kernel: Linux 5.2.0-0.bpo.2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
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: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages libvirt-daemon depends on:
ii  libacl1 2.2.53-4
ii  libapparmor12.13.2-10
ii  libaudit1   1:2.8.4-3
ii  libavahi-client30.7-4+b1
ii  libavahi-common30.7-4+b1
ii  libblkid1   2.33.1-0.1
ii  libc6   2.28-10
ii  libcap-ng0  0.7.9-2
ii  libcurl3-gnutls 7.64.0-4
ii  libdbus-1-3 1.12.16-1
ii  libdevmapper1.02.1  2:1.02.155-3
ii  libfuse22.9.9-1
ii  libgcc1 1:8.3.0-6
ii  libgnutls30 3.6.7-4
ii  libnetcf1   1:0.2.8-1+b2
ii  libnl-3-200 3.4.0-1
ii  libnl-route-3-200   3.4.0-1
ii  libnuma12.0.12-1
ii  libparted2  3.2-25
ii  libpcap0.8  1.8.1-6
ii  libpciaccess0   0.14-1
ii  libsasl2-2  2.1.27+dfsg-1
ii  libselinux1 2.8-1+b1
ii  libssh2-1   1.8.0-2.1
ii  libudev1241-5
ii  libvirt05.0.0-4
ii  libxenmisc4.11  4.11.1+92-g6c33308a8d-2
ii  libxenstore3.0  4.11.1+92-g6c33308a8d-2
ii  libxentoollog1  4.11.1+92-g6c33308a8d-2
ii  libxml2 2.9.4+dfsg1-7+b3
ii  libyajl22.1.0-3

Versions of packages libvirt-daemon recommends:
ii  libxml2-utils   2.9.4+dfsg1-7+b3
ii  netcat-openbsd  1.195-2
ii  qemu-kvm1:3.1+dfsg-8+deb10u2

Versions of packages libvirt-daemon suggests:
pn  libvirt-daemon-driver-storage-gluster  
pn  libvirt-daemon-driver-storage-rbd  
pn  libvirt-daemon-driver-storage-zfs  
ii  libvirt-daemon-system  5.0.0-4
pn  numad  

-- no debconf information

Bug#709975: Add set_sourcedir to Debian::Debhelper::Buildsystem

[Mathieu Parent]

Le mer. 14 août 2019 à 18:30, Niels Thykier  a écrit :
>
> On Mon, 27 May 2013 10:29:42 +0200 Mathieu Parent
>  wrote:
> > Package: debhelper
> > Version: 9.20130518
> > Severity: whishlist
> > X-Debbugs-CC: pkg-php-p...@lists.alioth.debian.org
> >
> > Hi Joey,
> >
> > For the pkg-php-tools [1] package, which enhance debhelper, I need to
> > change the sourcedir when building PECL [2] package.
> >
> > [1]: http://anonscm.debian.org/gitweb/?p=pkg-php/pkg-php-tools.git;a=summary
> > [2]: http://www.php.net/manual/en/install.pecl.phpize.php
> >
> > The wanted workflow on configure:
> > - set sourcedir to Foo-0.0.0
> > - phpize
> > - pass to parent Debian::Debhelper::Buildsystem::autoconf configure()
> > - set sourcedir back to top
> >
> > The wanted workflow on build:
> > - set sourcedir to Foo-0.0.0
> > - pass to parent Debian::Debhelper::Buildsystem::autoconf build()
> > - set sourcedir back to top
> >
> > The wanted workflow on install:
> > - set sourcedir to Foo-0.0.0
> > - pass to parent Debian::Debhelper::Buildsystem::autoconf install()
> > - set sourcedir back to top
> >
> > Wanted API:
> > - push_sourcedir (with the same checks as in
> > Debian::Debhelper::Buildsystem::new())
> > - pop_sourcedir
> >
> > Or:
> > - set_sourcedir (with the same checks as in
> > Debian::Debhelper::Buildsystem::new())
> >
> > I'm open to any better solution.
> >
> > Regards
> > --
> > Mathieu Parent
> >
> >
>
> Hi Mathieu,
>
> Apologies for the long wait before picking this up.

Hi,

Me answering late too ...

> Since you filed this bug, debhelper has gotten a new model for build
> systems that may be relevant to this case.  The described build flows
> looks a look existing build generator flows (a la meson+ninja or
> cmake+make[1]).
>
> The phppear have some differences to this theme as such debhelper does
> not currently support exactly the phppear use-case.  I am hoping we can
> come to a solution on that.
>
> If phppear would be converted to generator buildsystem like meson, then
> it would probably look something like this (mix-pseudo code, mix real code):
>
>
> """
> # Remove 'use base "Debian::Debhelper::Buildsystem::autoconf";'
> [...]
>
> sub IS_GENERATOR_BUILD_SYSTEM {
> return 1;
> }
>
> sub SUPPORTED_TARGET_BUILD_SYSTEMS {
> return qw(autoconf);
> }
>
> sub _get_peardir {
> [...]
> }
>
> # This sub does *not* exist yet
> sub _initialize_target_buildsystem {
> my ($this, $target_bs_options, @args) = shift;
> $target_bs_options->{'sourcedir'} = $this->_get_peardir;
> $target_bs_options->{'builddir'} = $this->_get_peardir;
> return $this->SUPER::_initialize_target_buildsystem(
> $target_bs_options, @args);
> }
>
> sub configure {
> my $this=shift;
> $this->get_targetbuildsystem->mkdir_builddir;
> $this->get_targetbuildsystem->doit_in_builddir('phpize');
> return $this->SUPER::configure(@_);
> }
>
> [...]
> """
> The configure is from your concept description; I realise that the real
> phppear build system is "slightly" more complex than that.
>
>
> The most difficult issue is if you need to extract data to make
> _get_peardir work, which may only be available if phppear is a valid
> buildsystem for the concrete package.  However, debhelper currently
> initializes the target buildsystem immediately and we rely on this
> elsewhere in debhelper (e.g. in dh_auto_configure --list).
>
>
> Just to confirm I got some details correct:
>  * Is it correctly understood of me that phppear *conditionally* uses
>autoconf as a generated build system (i.e. there are packages where
>phppear does everything without ever using the autoconf bits)?

Yes. PECL (php extensions) use autoconf, but PEAR (php only) don't.

>  * Is it correctly understood that phppear potentially needs two
>distinct "build directories"?  One for itself and a generated one for
>the autoconf parts?

I'm not sure (I don't remember, even reading the code). There are
several source dirs.

>
>  * Is the exact name returned by _get_peardir important or just "nice to
>have"?

It is important. This dir should exists in the tarball already,


>
>
>
> Finally, a few drive-by remarks after reviewing the phppear build system
> (in case they are useful to you):
>
>  * _get_mainpackage looks like an expensive version of $dh{MAINPACKAGE}
>(with some theoretical corner cases where dh_listpackages might give
>you a different result).
>- Is anything preventing you from using $dh{MAINPACKAGE}?

No. Thanks for the tip.

>
>  * If you like to avoid shell, then the complex_doit call can be
>replaced by using doit({stdout => $path}, ...).  Requires buster
>or later (I can dig out the exact version of debhelper if relevant,
>but I did not see any backports for pkg-php-tools, so I assumed it
>was not relevant).

OK. Thanks.

>
> Thanks,
> ~Niels
>
> [1] Strictly speaking, autoconf should be autoconf+make.  But historical
> reas

Bug#939369: vim: bash wrong auto indentation

[troulet]

Package: vim
Version: 2:8.1.0875-5
Severity: normal

Hello,

Since last update (vim 8.1.1401), the auto indentation function (gg=G) is
acting weirdly with bash scripts.

A quick example

#!/bin/bash

if [[ $test1 == 1 ]]; then
  echo $test1
  while read myvar; do
if [[ $myvar == 2 ]]; then
  echo $myvar
  if [[ $myvar == 3 ]]; then
echo $myvar
  fi
  fi
done < <(cat testfile)
  fi


When everything is fine under stretch (vim 8.0.707)

#!/bin/bash

if [[ $test1 == 1 ]]; then
  echo $test1
  while read myvar; do
if [[ $myvar == 2 ]]; then
  echo $myvar
  if [[ $myvar == 3 ]]; then
echo $myvar
  fi
fi
  done < <(cat testfile)
fi



-- Package-specific info:

--- real paths of main Vim binaries ---
/usr/bin/vi is /usr/bin/vim.basic
/usr/bin/vim is /usr/bin/vim.basic

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

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

Versions of packages vim depends on:
ii  libacl1  2.2.53-4
ii  libc62.28-10
ii  libgpm2  1.20.7-5+b1
ii  libselinux1  2.9-2+b2
ii  libtinfo66.1+20190803-1
ii  vim-common   2:8.1.0875-5
ii  vim-runtime  2:8.1.0875-5

vim recommends no packages.

Versions of packages vim suggests:
pn  ctags
pn  vim-doc  
pn  vim-scripts  

-- no debconf information

Bug#939368: liblemonldap-ng-manager-perl: Documentation not properly set in virtual host configuration files

[Xavier Guimard]

Package: liblemonldap-ng-manager-perl
Version: 1.9.12-1
Severity: normal

Since version 10.8 of debhelper, documentation in *-doc packages are
installed in /usr/share/doc/.

liblemonldap-ng manager-perl uses files from lemonldap-ng-doc to provide
on-line doc. The debhelper change causes a bad "Alias" link in
Apache/Nginx configuration files.

Bug#918973:

[Mario.Limonciello]

With Buster out now, can this effort be resumed?

Bug#939367: 9mount FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: 9mount
Version: 1.3+hg20170412-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

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

Helmut
diff --minimal -Nru 9mount-1.3+hg20170412/debian/changelog 
9mount-1.3+hg20170412/debian/changelog
--- 9mount-1.3+hg20170412/debian/changelog  2018-09-05 10:54:25.0 
+0200
+++ 9mount-1.3+hg20170412/debian/changelog  2019-09-04 06:27:51.0 
+0200
@@ -1,3 +1,10 @@
+9mount (1.3+hg20170412-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 04 Sep 2019 06:27:51 +0200
+
 9mount (1.3+hg20170412-1) unstable; urgency=medium
 
   * New upstream snapshot.
diff --minimal -Nru 9mount-1.3+hg20170412/debian/rules 
9mount-1.3+hg20170412/debian/rules
--- 9mount-1.3+hg20170412/debian/rules  2018-09-05 10:54:25.0 +0200
+++ 9mount-1.3+hg20170412/debian/rules  2019-09-04 06:27:50.0 +0200
@@ -4,7 +4,7 @@
dh $@
 
 override_dh_auto_build:
-   $(MAKE) CFLAGS="$(CFLAGS)"
+   dh_auto_build -- CFLAGS="$(CFLAGS)"
 
 override_dh_auto_test:
 

Bug#939366: ITP: tpm2-initramfs-tool -- Tool used in initramfs to seal/unseal FDE key to the TPM

[Tim Chen]

Package: wnpp
Severity: wishlist
Owner: "Jian-Ding Chen (timchen119)" 

* Package name: tpm2-initramfs-tool
  Version : 0.2.1
  Upstream Author : "Jian-Ding Chen (timchen119)" 
* URL : https://github.com/timchen119/tpm2-initramfs-tool
* License : GPLv2+
  Programming Lang: C
  Description : Tool used in initramfs to seal/unseal FDE key to the TPM

This package provides the TPM tool used by the initramfs.
Its purpose is to generate/seal/unseal the FDE encrypytion key into
the TPM persistent object using TPM2 ESAPI.

Bug#939365: nautilus: Preference in Settings - 'Sort folders before files' malfunctioning.

[skyguide]

Package: nautilus
Version: 3.30.5-2
Severity: normal

Files -> Preference -> Sort -> 'Sort folders before files' check box setting 
getting cleared between OS reboots or/and after OS returns from a stand by mode.

Assumed/Expected behavior is that checked box will stay checked and folders 
will get sorted and displayed in list view before files. 
Instead, up on the system reboot or/and system returning from a stand by state, 
that check box getting unchecked (cleared) and sorting of folders is mixed with 
the rest of the files in list view. 


-- 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)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages nautilus depends on:
ii  bubblewrap 0.3.1-4
ii  desktop-file-utils 0.23-4
ii  gsettings-desktop-schemas  3.28.1-1
ii  gvfs   1.38.1-5
ii  libatk1.0-02.30.0-2
ii  libc6  2.28-10
ii  libcairo-gobject2  1.16.0-4
ii  libcairo2  1.16.0-4
ii  libgdk-pixbuf2.0-0 2.38.1+dfsg-1
ii  libgexiv2-20.10.9-1
ii  libglib2.0-0   2.58.3-2
ii  libglib2.0-data2.58.3-2
ii  libgnome-autoar-0-00.2.3-2
ii  libgtk-3-0 3.24.5-1
ii  libnautilus-extension1a3.30.5-2
ii  libpango-1.0-0 1.42.4-7~deb10u1
ii  libpangocairo-1.0-01.42.4-7~deb10u1
ii  libseccomp22.3.3-4
ii  libselinux12.8-1+b1
ii  libtracker-sparql-2.0-02.1.8-2
ii  nautilus-data  3.30.5-2
ii  shared-mime-info   1.10-1
ii  tracker2.1.8-2

Versions of packages nautilus recommends:
ii  gnome-sushi  3.30.0-2
ii  gvfs-backends1.38.1-5
ii  librsvg2-common  2.44.10-2.1

Versions of packages nautilus suggests:
ii  eog 3.28.4-2+b1
ii  evince [pdf-viewer] 3.30.2-3
ii  nautilus-extension-brasero  3.12.2-5
ii  nautilus-sendto 3.8.6-3
ii  totem   3.30.0-4
ii  xdg-user-dirs   0.17-2

-- no debconf information

Bug#689230: virtuoso-opensource: New upstream version available

[Laurence Parry]

On Sun, 14 Oct 2018 12:19:33 +0200 Andreas Beckmann  wrote:
> Version: 7.2.5.1+dfsg-1
>
> A new upstream version is available in experimental.

Unfortunately this fails to build from source on all 32-bit platforms:
https://buildd.debian.org/status/package.php?p=virtuoso-opensource&suite=experimental

On the x32 build (which is what I was looking at, in case Virtuoso is used
for Wikibase: https://phabricator.wikimedia.org/T206561 ):
https://buildd.debian.org/status/fetch.php?pkg=virtuoso-opensource&arch=x32&ver=7.2.5.1%2Bdfsg-2&stamp=1550089395&raw=0
configure:6904: error: The current version of Virtuoso Open Source Edition
(Column Store) can only be build on 64bit platforms

This is of course an intentional change:
https://github.com/openlink/virtuoso-opensource/issues/439
https://github.com/openlink/virtuoso-opensource/commit/33178d7bc9888e025da1894e0e1f0652212d729d

However, I am uncertain as to whether it is a *necessary* change, or
reflects the fact that they do not wish to support 32-bit (which might,
after all, cause segmentation faults on large databases). Perhaps it will
actually build and run fine on 32-bit if the block is patched out?

I don't know Debian's policy on this, but it seems similar to other
platforms (such as x32) that are sometimes not supported upstream. In this
case, though, it is breaking the package for 32-bit platforms officially
supported by Debian, in which Virtuoso 6 worked fine.

For many uses, it seems a 32-bit userspace should be sufficient:
"The defaults with Virtuoso Open-Source give a 160MB process size in
memory"
http://vos.openlinksw.com/owiki/wiki/VOS/VOSDebianNotes
(though per #720770 the memory limit may be ineffective; but maybe this was
fixed:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720770 )

The build also fails on s390x, ppc64 and sparc64 because DV_INT_TAG_WORD is
not defined.

Dkpool.c: In function 'mp_box_num':
../../libsrc/Dk/Dkbox.h:1034:28: error: 'DV_INT_TAG_WORD' undeclared
(first use in this function); did you mean 'DV_INT_TAG_WORD_64'?
 #define DV_INT_TAG_WORD_64 DV_INT_TAG_WORD
^~~
../../libsrc/Dk/Dkpool.h:428:23: note: in definition of macro 'MP_INT'
 ((int64*)x)[-1] = tag_word; \
   ^~~~

and there is some dubious pointer use in Dkbasket.c which might cause
problems on some platforms:

Dkbasket.c:335:51: note: expected ‘int *’ but argument is of type ‘long int *’
 rbuf_delete (rbuf_t * rb, rbuf_elt_t * rbe, int * inx_ret)
 ~~^~~


Best regards,
--
Laurence "GreenReaper" Parry

Bug#939364: stretch-pu: package python-acme/0.28.0-1~deb9u2

[Harlan Lieberman-Berg]

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

Hello release managers,

We have a proposed update for acme in stretch (oldstable).  This is
necessary to prevent the package, and all its dependencies, stopping
to work due to changes to the web service that the acme module is
primarily used for.  (Let's Encrypt)

We've backported the minimal set of patches, and upstream has
validated that the set is correct.

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

Kernel: Linux 5.2.0-2-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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru python-acme-0.28.0/debian/changelog 
python-acme-0.28.0/debian/changelog
--- python-acme-0.28.0/debian/changelog 2018-12-02 16:24:15.0 -0500
+++ python-acme-0.28.0/debian/changelog 2019-07-31 22:26:45.0 -0400
@@ -1,3 +1,11 @@
+python-acme (0.28.0-1~deb9u2) stretch; urgency=medium
+
+  * This stretch update is to switch to using a POST-as-GET protocol
+before the November 1, 2019 deadline when Let's Encrypt will begin
+refusing requests using the (old) GET protocol. (Closes: #932248)
+
+ -- Harlan Lieberman-Berg   Wed, 31 Jul 2019 22:26:45 
-0400
+
 python-acme (0.28.0-1~deb9u1) stretch; urgency=medium
 
   * This stretch update is to cure the problem caused by the deprecation
diff -Nru python-acme-0.28.0/debian/patches/-post-as-get.patch 
python-acme-0.28.0/debian/patches/-post-as-get.patch
--- python-acme-0.28.0/debian/patches/-post-as-get.patch1969-12-31 
19:00:00.0 -0500
+++ python-acme-0.28.0/debian/patches/-post-as-get.patch2019-07-31 
18:40:59.0 -0400
@@ -0,0 +1,317 @@
+From 0b5468e992ab57fa028ddf33ca2351cb37c8e1ee Mon Sep 17 00:00:00 2001
+From: Adrien Ferrand 
+Date: Fri, 30 Nov 2018 01:42:06 +0100
+Subject: [PATCH] Implement POST-as-GET requests (#6522)
+
+* Setup an integration tests env against Pebble, that enforce post-as-get
+
+* Implement POST-as-GET requests, with fallback to GET.
+
+* Fix unit tests
+
+* Fix coverage.
+
+* Fix or ignore lint errors
+
+* Corrections after review
+
+* Correct test
+
+* Try a simple delegate approach
+
+* Add a test
+
+* Simplify test mocking
+
+* Clean comment
+---
+Index: python-acme/acme/client.py
+===
+--- python-acme.orig/acme/client.py
 python-acme/acme/client.py
+@@ -199,22 +199,6 @@ class ClientBase(object):  # pylint: dis
+ 
+ return datetime.datetime.now() + datetime.timedelta(seconds=seconds)
+ 
+-def poll(self, authzr):
+-"""Poll Authorization Resource for status.
+-
+-:param authzr: Authorization Resource
+-:type authzr: `.AuthorizationResource`
+-
+-:returns: Updated Authorization Resource and HTTP response.
+-
+-:rtype: (`.AuthorizationResource`, `requests.Response`)
+-
+-"""
+-response = self.net.get(authzr.uri)
+-updated_authzr = self._authzr_from_response(
+-response, authzr.body.identifier, authzr.uri)
+-return updated_authzr, response
+-
+ def _revoke(self, cert, rsn, url):
+ """Revoke certificate.
+ 
+@@ -236,6 +220,7 @@ class ClientBase(object):  # pylint: dis
+ raise errors.ClientError(
+ 'Successful revocation must return HTTP OK status')
+ 
++
+ class Client(ClientBase):
+ """ACME client for a v1 API.
+ 
+@@ -388,6 +373,22 @@ class Client(ClientBase):
+ body=jose.ComparableX509(OpenSSL.crypto.load_certificate(
+ OpenSSL.crypto.FILETYPE_ASN1, response.content)))
+ 
++def poll(self, authzr):
++"""Poll Authorization Resource for status.
++
++:param authzr: Authorization Resource
++:type authzr: `.AuthorizationResource`
++
++:returns: Updated Authorization Resource and HTTP response.
++
++:rtype: (`.AuthorizationResource`, `requests.Response`)
++
++"""
++response = self.net.get(authzr.uri)
++updated_authzr = self._authzr_from_response(
++response, authzr.body.identifier, authzr.uri)
++return updated_authzr, response
++
+ def poll_and_request_issuance(
+ self, csr, authzrs, mintime=5, max_attempts=10):
+ """Poll and request issuance.
+@@ -651,13 +652,29 @@ class ClientV2(ClientBase):
+ body = messages.Order.from_json(response.json())
+ authorizations = []
+ for url in body.authorizations:
+-
authorizations.append(self._authzr_from_response(self.net.get(url), uri=url))
++
authorizations.append(self._authzr_from_response(self._post_as_get(url), 
uri=url))
+ return messages.OrderResource(
+ 

Bug#939096: RFS: oomd/0.1.0-1 [ITP] -- userspace Out-Of-Memory (OOM) killer for Linux systems

[Paul Wise]

On Wed, Sep 4, 2019 at 7:57 AM Adam Borowski wrote:

> If there's no reasonable default setup, then an error message should at
> least say the config is missing.

In addition the default sysvinit/systemd setup should be that the
service should be disabled by default until the admin enables it, IIRC
there is a policy section about that.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#935731: comitup: port to python 3

[David Steele]

 Severity: normal
thanks

There is an erroneous "Suggests" control file listing for the Python 2
package. This has no effect on the usability of the package. The issue
doesn't rate autoremoval 18 months before the next stable release.

The fix is in git, and will be released in due course.

https://github.com/davesteele/comitup/commit/43459f9

Bug#939363: openssl: Older OpenSSL binaries crash on startup, no error messages are shown.

[Dylan H.]

Package: openssl
Version: 1.1.1c-1
Severity: important

As title says. Using AppImages with older OpenSSL binaries instantly aborts the
application and I get no error codes. I have tested this with Ripcord and it
will not open.

Hopefully this will be resolved soon. The developer of this application
(ripcord) says that the OpenSSL package is broken and incompatible with older
binaries.



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

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

Versions of packages openssl depends on:
ii  libc6  2.28-10
ii  libssl1.1  1.1.1c-1

openssl recommends no packages.

Versions of packages openssl suggests:
ii  ca-certificates  20190110

-- no debconf information

Bug#928814: (no subject)

[Daniel Giritzer]

Dear maintainer:
I have the same problem as well. I am also using stable Debian. If I run the 
program using the debug option I get the same output as fmiz.

Thanks in advance,
giri

Bug#939362: grantlee5: FTBFS with Qt 5.12.4 in experimental

[Steve Langasek]

Source: grantlee5
Version: 5.1.0-2.1
Severity: serious
Tags: experimental
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan

Dear maintainers,

The grantlee5 package fails to build with the version of Qt in experimental,
5.12.4.  This was discovered because Ubuntu also has Qt 5.12.4 in its devel
series, so grantlee5 5.1.0-2.1 has failed to build on all architectures:

[...]
FAIL!  : TestInternationalization::testIntegers(integer-02) Compared values are 
not the same
   Actual   (frLocalizer->localizeNumber(integer)): "7\u202F000"
   Expected (frInteger)   : "7\u00A"
   Loc: [/<>/templates/tests/testinternationalization.cpp(838)]
[...]
Totals: 67 passed, 8 failed, 0 skipped, 0 blacklisted, 22ms
* Finished testing of TestInternationalization *

11/12 Test #12: plainmarkupbuildertest ...   Passed0.03 sec
12/12 Test #11: htmlbuildertest ..   Passed0.04 sec

92% tests passed, 1 tests failed out of 12

Total Test time (real) =   0.12 sec

The following tests FAILED:
 10 - testinternationalization (Failed)
Errors while running CTest
make[2]: *** [Makefile:76: test] Error 8
[...]

  (https://launchpad.net/ubuntu/+source/grantlee5/5.1.0-2.1)

I don't know why the behavior of Qt has changed, but this will eventually
become a serious bug on grantlee5 in unstable once Qt is updated there.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#918672: same issue with bash scripts

[James McCoy]

On Tue, Sep 03, 2019 at 01:49:05PM +0200, Thibault Roulet wrote:
> Hi,
> 
> Experiencing the same kind of problems with bash scripts.
> 
> Indentation is working fine under stretch but got some problems under buster.
> Should I open a new case ?

It's unlikely to get fixed in Buster, but yes bash and XML are
completely different indent mechanisms so they should have separate
reports.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#939361: httpdirfs-fuse: build compatibility with -Wl,--as-needed

[Steve Langasek]

Package: httpdirfs-fuse
Version: 1.0.1-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch

Dear Jerome,

The httpdirfs-fuse package fails to build in Ubuntu because it supplies
options to the linker in the wrong order:

[...]
cc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -g -O2 -Wall -Wextra 
-D_FILE_OFFSET_BITS=64 -DVERSION=\"1.0.1\" -Wl,-Bsymbolic-functions 
-Wl,-z,relro -Wl,-z,now -lgumbo -lcurl -lfuse -lcrypto -o httpdirfs main.o 
network.o fuse_local.o link.o
/usr/bin/ld: network.o: in function `curl_process_msgs':
./src/network.c:162: undefined reference to `curl_easy_getinfo'
/usr/bin/ld: ./src/network.c:166: undefined reference to `curl_easy_getinfo'
/usr/bin/ld: ./src/network.c:181: undefined reference to `curl_multi_remove_hand
[...]
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:15: httpdirfs] Error 1
make[1]: Leaving directory '/<>'
dh_auto_build: make -j4 "INSTALL=install --strip-program=true" returned exit 
code 2
[...]

  (https://launchpad.net/ubuntu/+source/httpdirfs-fuse/1.0.1-1)

Per ,
libraries must be passed on the commandline after the objects which
reference them, otherwise they will be discarded by the linker, resulting in
errors such as the above.

I have uploaded the attached patch to httpdirfs-fuse in Ubuntu.  Please
consider applying it in Debian as well.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru httpdirfs-fuse-1.0.1/debian/patches/library-link-order.patch 
httpdirfs-fuse-1.0.1/debian/patches/library-link-order.patch
--- httpdirfs-fuse-1.0.1/debian/patches/library-link-order.patch
1969-12-31 16:00:00.0 -0800
+++ httpdirfs-fuse-1.0.1/debian/patches/library-link-order.patch
2019-09-03 17:10:50.0 -0700
@@ -0,0 +1,32 @@
+Description: Ensure libraries linked are listed after objects using them
+ The Ubuntu toolchain uses -Wl,--as-needed by default, which causes
+ libraries to be dropped from the final binary if they aren't used.  For
+ portability, make sure that libraries are always listed on the linker
+ commandline /after/ the objects that reference them.
+ .
+ This also avoids passing -l options to the compiler when compiling .o files.
+Author: Steve Langasek 
+Last-Update: 2019-09-03
+
+Index: httpdirfs-fuse-1.0.1/Makefile
+===
+--- httpdirfs-fuse-1.0.1.orig/Makefile
 httpdirfs-fuse-1.0.1/Makefile
+@@ -1,7 +1,7 @@
+ VERSION=1.0.1
+ 
+ CFLAGS+= -g -O2 -Wall -Wextra -D_FILE_OFFSET_BITS=64 -DVERSION=\"$(VERSION)\"
+-LDFLAGS+= -lgumbo -lcurl -lfuse -lcrypto
++LIBS = -lgumbo -lcurl -lfuse -lcrypto
+ COBJS = main.o network.o fuse_local.o link.o
+ 
+ prefix ?= /usr/local
+@@ -12,7 +12,7 @@
+   $(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) -c -o $@ $<
+ 
+ httpdirfs: $(COBJS)
+-  $(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) -o $@ $^
++  $(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) -o $@ $^ $(LIBS)
+ 
+ install:
+   install -m 755 -D httpdirfs \
diff -Nru httpdirfs-fuse-1.0.1/debian/patches/series 
httpdirfs-fuse-1.0.1/debian/patches/series
--- httpdirfs-fuse-1.0.1/debian/patches/series  1969-12-31 16:00:00.0 
-0800
+++ httpdirfs-fuse-1.0.1/debian/patches/series  2019-09-03 17:09:04.0 
-0700
@@ -0,0 +1 @@
+library-link-order.patch

Bug#939280: dgit push-source rejects source-only .changes containing .orig.tar.gz.asc

[Ian Jackson]

user d...@packages.debian.org
usertags rsn
thanks

Simon McVittie writes ("Bug#939280: dgit push-source rejects source-only 
.changes containing .orig.tar.gz.asc"):
> Package: dgit
> Version: 9.7
> Severity: normal
> 
> Steps to reproduce:

Thanks for the nice clear bug report.

> * Have an upstream project that releases tarballs with detached signatures
>   (in this case dbus-python_1.2.10.orig.tar.gz{,.asc})
> * Have the .asc next to your .orig.tar.gz
> * Build a source-only .changes file in a way that will pick up the orig
>   tarball and detached signature
> * dgit push-source -C /path/to/dbus-python_1.2.10-1_source.changes

Thanks.  I think the -C option should not be necessary.  Indeed I'm
not even sure what it does (or should mean) with push-source.  dgit
push-source is supposed to be used without a prior build step.
Without -C it builds its own dsc.

Ie ISTM that you ought not to need step 3 of your list above, nor the
-C option.  Just dgit push-source ought to pick up and use the .asc.
Maybe the -C option ought to be rejected with push-source.

Anyway, I expect can reproduce all this with --damp-run and your
actual package.

> Actual result:
> 
> > $ dgit push-source -C ~/tmp/build-area/dbus-python_latest/*_source.changes
> > Format `3.0 (quilt)', need to check/update patch stack
> > canonical suite name for unstable is sid
> > gzip: warning: GZIP environment variable is deprecated; use an alias or 
> > script
> > dgit: split brain (separate dgit view) may be needed (--quilt=unapplied).
> > examining quilt state (multiple patches, unapplied mode)
> > dgit: base trees orig=b6bbca609900c3739fa8 o+d/p=b6bbca609900c3739fa8
> > dgit: quilt differences: src:  == orig == gitignores:  == orig ==
> > dgit: quilt differences:  HEAD == o+d/p   HEAD == o+d/p
> > dgit view: created (commit id 3cab30a85d7ad0c0cc2d7a98f27fa4b9d366b0ed)
> > purportedly source-only changes polluted by 
> > dbus-python_1.2.10.orig.tar.gz.asc
> > 
> > dgit: error: user-specified changes file is not source-only

For my reference: it's not clear to me whether dgit used the specified
-C at all.  It may have built a correct .changes file an then
complained about its own output.

> Workaround:
> 
> * Use dgit push instead (but give it a source-only changes file anyway)

Right.

Ian.

-- 
Ian JacksonThese opinions are my own.

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

Bug#939357: cryptsetup-run: invoking "sudo cryptdisks_start" with "decrypt_keyctl" in crypttab fails

[Sebastian Mohr]

Package: cryptsetup-run
Version: 2:2.1.0-5
Severity: normal
File: /lib/cryptsetup/scripts/decrypt_keyctl

Dear Maintainer,

when configuring this encrypted machine running debian stable with keyscript
"decryt_keyctl", the invocation of "cryptdisks_start data{0,1}_crypt" when
logged in via ssh as normal user and "sudo -i" to root fails with the message:

| [] Starting crypto disk...data0_crypt (starting)...Caching passphrase for 
data0_crypt:  *
| keyctl_set_timeout: Permission denied
| Error setting timeout on key (824927206), removing
| Nothing to read on input.
| Caching passphrase for data0_crypt:

After some searching, I found a link to bug #758788, especially message #45 and 
#50 [1], which
described seemingly the same bug:

| > On the first invocation (for cont1_crypt), I got this dialog:
| >
| > root@marislae:~# cryptdisks_start cont1_crypt
| > [[] Starting crypto disk...[info] cont1_crypt (starting)...
| > Caching passphrase for /cont1:  **
| > keyctl_set_timeout: Permission denied
| > Error setting timeout on key (2524288), removing
| > Caching passphrase for /cont1:  **
| > keyctl_set_timeout: Permission denied
| > Error setting timeout on key (612589418), removing
| >
| > [Here I pressed  to stop the attempts]
| >
| > Caching passphrase  for /cont1:  Erreur de lecture de la phrase secrète.
| >
| >
| > I was running the commands from root. I initially logged in to the
| > computer from SSH to a regular user, than did "sudo -i" to get root
| > access if this matters. As I suspected this may be a problem, I allowed
| > root direct SSH access and tried again, login directly to root account,
| > this time it worked:
|
| Interesting, never saw these kind of problems before. I'm testing on a
| Laptop with Ubuntu 14.04 installed and use 'sudo -i' a lot. Indeed I
| used it for testing the commands above as well. For me it worked. But
| let's keep that aside. It's another issue and out of scope for this
| bugreport ;)

But I haven't found another link to that aspect of that bug; the mentioned
bug was closed without looking at that facette further.

Another link I stumbled upon was one of Matthew Gerret describing a workaround
with the kernel keyring and sudo [2].

I adapted a copy of decrypt_keyctl to his suggestions and afterwards I could
decrypt the multiple cryptdisks. Here is the patch:

--- 8< --- 8< --- 8< ---

--- decrypt_keyctl  2019-06-10 14:51:15.0 +0200
+++ decrypt_keyctl_debug2019-09-03 23:33:51.311240116 +0200
@@ -43,8 +43,13 @@
 keyctl unlink "$KID_" @u
 KID_=""
 fi
-KID_="$(printf "%s" "$KEY_" | keyctl padd user "$ID_" @u)"
+KID_="$(printf "%s" "$KEY_" | keyctl padd user "$ID_" @s)"
 [ -n "$KID_" ] || die "Error adding passphrase to kernel keyring"
+if ! ( keyctl setperm "$KID_" 0x3f3f && keyctl link "$KID_" @u && keyctl unlink 
"$KID_" @s ); then
+keyctl unlink "$KID_" @u
+keyctl unlink "$KID_" @s
+die "Error transferring permissions on key ($KID_), removing"
+fi
 if ! keyctl timeout "$KID_" "$TIMEOUT_"; then
 keyctl unlink "$KID_" @u
 die "Error setting timeout on key ($KID_), removing"

--- 8< --- 8< --- 8< ---

I don't know whether there are further security implications or something like 
that,
nor did I do extensive testing. The error handling was also added in a quick way
without testing it further (I also don't know how to provoke that error). I just
wanted to let you know that and how I fixed a problem not only I had.


Regards

Sebastian

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758788#50
[2]: https://mjg59.dreamwidth.org/37333.html

Bug#939358: budgie-core: missing dependency on gnome-session

[Marc Lehmann]

Package: budgie-core
Version: 10.2.9-2
Severity: normal

Dear Maintainer,

installing budgie-core leaves it unstartable, as running budgie-session
requires gnome-session, which isn't in any of the dependencies.

-- 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 budgie-core depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
pn  gnome-settings-daemon
pn  libaccountsservice0  
ii  libasound2   1.1.8-1
ii  libatk1.0-0  2.30.0-2
pn  libbudgie-plugin0
pn  libbudgie-private0   
pn  libbudgietheme0  
ii  libc62.28-10
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libdrm2  2.4.97-1
ii  libegl1-mesa 18.3.6-2
ii  libgbm1  18.3.6-2
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libgirepository-1.0-11.58.3-2
ii  libglib2.0-0 2.58.3-2
pn  libgnome-bluetooth13 
pn  libgnome-desktop-3-12
ii  libgnome-desktop-3-173.30.2.1-2
pn  libgnome-menu-3-0
ii  libgtk-3-0   3.24.5-1
ii  libibus-1.0-51.5.19-4
ii  libjson-glib-1.0-0   1.4.4-2
pn  libmutter-3-0
pn  libmutter0i  
ii  libnotify4   0.7.7-4
ii  libpango-1.0-0   1.42.4-7~deb10u1
ii  libpangocairo-1.0-0  1.42.4-7~deb10u1
ii  libpeas-1.0-01.22.0-4
ii  libpolkit-agent-1-0  0.105-25
ii  libpolkit-gobject-1-00.105-25
ii  libpulse-mainloop-glib0  12.2-4
ii  libpulse012.2-4
pn  libraven0
ii  libupower-glib3  0.99.10-1
ii  libuuid1 2.33.1-0.1
ii  libwayland-client0   1.16.0-1
ii  libwayland-egl1 [libwayland-egl1-mesa]   1.16.0-1
ii  libwayland-server0   1.16.0-1
pn  libwnck-3-0  
ii  libx11-6 2:1.6.7-1
ii  libxcomposite1   1:0.4.4-2
ii  libxdamage1  1:1.1.4-3+b3
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxrandr2   2:1.5.1-1

budgie-core recommends no packages.

budgie-core suggests no packages.

Bug#939359: qemu dies with SIGABRT

[Jörg Sommer]

Package: qemu-system-x86
Version: 1:4.1-1
Severity: normal

Hi,

qemu crashes for me immediately after the start. Here's the backtrace of
the crash:

```
% gdb-bt-full /usr/bin/qemu-system-x86_64 /tmp/core

warning: core file may not match specified executable file.
[New LWP 27485]
[New LWP 27493]
[New LWP 27490]
[New LWP 27492]
[New LWP 27491]
[New LWP 27487]
[New LWP 27494]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `qemu-system-x86_64 -name Windows -enable-kvm -cpu 
host,kvm=off -smp 4 -m 6G -de'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: Datei oder Verzeichnis nicht 
gefunden.
[Current thread is 1 (Thread 0x7fd00271ae80 (LWP 27485))]
#0  0x7fd003ce17bb in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:50
set = {__val = {268444224, 112, 140736369168544, 140736369168300, 0, 
17046191421764163220, 93858214465936, 93858232046048, 140736369168800, 
93858232062992, 13390720449241962132, 93858182727468, 511101108224, 0, 1, 
4915103089820957184}}
pid = 
tid = 
#1  0x7fd003ccc535 in __GI_abort () at abort.c:79
save_stage = 1
act = {__sigaction_handler = {sa_handler = 0x16, sa_sigaction = 0x16}, 
sa_mask = {__val = {93858213044400, 335, 384, 18446744073709550520, 5, 
227633266710, 0, 48, 0, 7, 64, 206158430212, 93858213044256, 47, 96, 
18446744073709550520}}, sa_flags = 1, sa_restorer = 0x310004}
sigs = {__val = {32, 0 }}
#2  0x555d0f5fc733 in audio_get_pdo_out (dev=) at 
./audio/audio_template.h:328
#3  0x555d0f7a2c81 in AUD_open_out (card=0x555d12940328, sw=0x0, 
name=0x555d0fb1cd59 "dac", 
callback_opaque=callback_opaque@entry=0x555d12940348, 
callback_fn=0x555d0f7ea930 , as=as@entry=0x555d12940374) 
at ./audio/audio_template.h:434
s = 0x555d10004c20 
pdo = 
__func__ = "AUD_open_out"
#4  0x555d0f7eae9c in hda_audio_setup (st=0x555d12940348) at 
./hw/audio/hda-codec.c:481
use_timer = 
cb = 
#5  0x555d0f7eb145 in hda_audio_init (hda=, desc=) at ./hw/audio/hda-codec.c:716
a = 0x555d129402a0
__func__ = "hda_audio_init"
st = 
node = 
param = 
i = 2
type = 
__PRETTY_FUNCTION__ = "hda_audio_init"
#6  0x555d0f7e8391 in hda_codec_dev_realize (qdev=, 
errp=0x7fffbd4a9350) at ./hw/audio/intel-hda.c:71
bus = 0x555d1293de48
__func__ = "hda_codec_dev_realize"
dev = 0x555d129402a0
cdc = 
#7  0x555d0f808295 in device_set_realized (obj=, 
value=, errp=0x7fffbd4a9440) at ./hw/core/qdev.c:834
dev = 0x555d129402a0
__func__ = "device_set_realized"
dc = 0x555d117d7370
hotplug_ctrl = 0x0
bus = 
local_err = 0x0
unattached_parent = true
unattached_count = 37
#8  0x555d0f99b5d7 in property_set_bool (obj=0x555d129402a0, v=, name=, opaque=0x555d1293ed70, errp=0x7fffbd4a9440) at 
./qom/object.c:2079
prop = 0x555d1293ed70
value = true
local_err = 0x0
#9  0x555d0f99fc30 in object_property_set_qobject 
(obj=obj@entry=0x555d129402a0, value=value@entry=0x555d12948f20, 
name=name@entry=0x555d0fb23d0d "realized", errp=errp@entry=0x7fffbd4a9440) at 
./qom/qom-qobject.c:26
v = 0x555d12949000
#10 0x555d0f99d516 in object_property_set_bool (obj=0x555d129402a0, 
value=, name=0x555d0fb23d0d "realized", errp=0x7fffbd4a9440) at 
./qom/object.c:1337
qbool = 0x555d12948f20
#11 0x555d0f807202 in qdev_init_nofail (dev=0x555d129402a0) at 
./hw/core/qdev.c:321
err = 0x0
__PRETTY_FUNCTION__ = "qdev_init_nofail"
#12 0x555d0f7e7faf in intel_hda_and_codec_init (bus=) at 
./hw/audio/intel-hda.c:1316
controller = 
hdabus = 
codec = 
__func__ = "intel_hda_and_codec_init"
#13 0x555d0f7ec471 in soundhw_init () at ./hw/audio/soundhw.c:150
c = 0x555d1000d2c0 
isa_bus = 0x555d11908580
pci_bus = 0x555d11c58170
#14 0x555d0f601bdb in main (argc=, argv=, 
envp=) at ./vl.c:4347
i = 
snapshot = 
linux_boot = 
initrd_filename = 0x0
kernel_filename = 
kernel_cmdline = 
boot_order = 0x555d0fae4efc "cad"
boot_once = 
ds = 
opts = 
machine_opts = 
icount_opts = 
accel_opts = 
olist = 
optind = 39
optarg = 0x7fffbd4abaec "hda"
loadvm = 
machine_class = 0x555d11814c60
cpu_option = 
vga_model = 0x7fffbd4abab1 "virtio"
qtest_chrdev = 
qtest_log = 
incoming = 
userconfig = 
nographic = 
display_remote = 
log_mask = 
log_file = 
trace_file = 
maxram_size = 6442450944
ram_slots = 0
 

Bug#939333: varnish: VSV00003 DoS attack vector

[Moritz Mühlenhoff]

On Tue, Sep 03, 2019 at 10:43:55PM +0200, Steinar H. Gunderson wrote:
> tags 939333 + patch
> thanks
> 
> On Tue, Sep 03, 2019 at 02:27:33PM +0200, Salvatore Bonaccorso wrote:
> > See https://varnish-cache.org/security/VSV3.html . A CVE does not
> > seem yet to be assigned (but a request pending now).
> 
> I made a backport to 6.1.1 for stable. It consists of all changes between
> 6.2.0 and 6.2.1 in git, except:
> 
>  - No bumping of version number or changelog.
>  - Removed some unrelated change of #include order in otherwise untouched
>files.
>  - The tests are not included (probably should be; I removed them as part
>of trying to backport in a slightly different fashion).
>  - bin/varnishtest/vtc_http.c needed additional changes from the 6.2.0 set
>to have the end pointer vct_iscrlf() and vct_skipcrlf() now need;
>since varnishtest is not meant to be run against untrusted servers,
>I changed the patch to simply use the old, insecure versions
>(now named vct_iscrlf_unsafe() and vct_skipcrlf_unsafe()).
>  - The diff has been refreshed to fix line numbers.
> 
> With this patch in debian/patches/, Varnish compiles and appears to run
> normally (we already use it in production).

Thanks! I've built an updated package and verified via the reproducer
included in the tests that Varnish no longer crashes.

I've uploaded the build to security buildds, a DSA will be available tomorrow.

Cheers,
Moritz

Bug#939096: RFS: oomd/0.1.0-1 [ITP] -- userspace Out-Of-Memory (OOM) killer for Linux systems

[Adam Borowski]

On Mon, Sep 02, 2019 at 02:03:39PM +0800, Yangfl wrote:
> Adam Borowski  于2019年9月2日周一 上午4:01写道：
> > On Sun, Sep 01, 2019 at 05:48:14PM +0800, Yangfl wrote:
> > >  * Package name: oomd
> > >Version : 0.1.0-1
> >
> > > It builds those binary packages:
> > >
> > >   oomd - userspace Out-Of-Memory (OOM) killer for Linux systems
> > >   liboomd0 - userspace Out-Of-Memory (OOM) killer for Linux systems - 
> > > library

> Thanks for pointing out. Symbols fixed and added a sysv init file.

It builds now, but the daemon fails to start.

DESC=oomd
NAME=oomd
DAEMON=/usr/bin/$NAME
-- yet the executable is /usr/bin/oomd_bin

Upon correcting that, I get:

oomd disabled in config ... (warning).

/etc/default/oomd has:
DAEMON_OPTS="--interval 1 --config /etc/oomd.json"
and there's no /etc/oomd.json shipped.

If there's no reasonable default setup, then an error message should at
least say the config is missing.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋  The root of a real enemy is an imaginary friend.
⠈⠳⣄

Bug#939360: python-pynvml: Please include libnvidia-ml1 alternate dep also on armhf

[Steve Langasek]

Package: python-pynvml
Version: 7.352.0-2
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch

Dear maintainers,

The latest upload of python-pynvml has not been migratable to the Ubuntu
release for 4 months, because its dependencies are not satisfiable on armhf. 
This is because you have libnvidia-ml1 listed as an alternative dependency
only on amd64 and i386, not on armhf; and the other alternatives,
libnvidia-legacy-390xx-ml1 and libnvidia-legacy-340xx-ml1, don't exist at
all in Ubuntu but libnvidia-ml1 *does* exist as a virtual package provided
by the last release of the nvidia drivers that supported armhf.

I don't see any reason that it would be invalid to list libnvidia-ml1 as an
alternative (or even preferred) dependency for this package on armhf even in
Debian, so I would ask that you apply the attached patch so that the Ubuntu
package can be in sync with Debian and still be installable.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru python-pynvml-7.352.0/debian/control 
python-pynvml-7.352.0/debian/control
--- python-pynvml-7.352.0/debian/control2019-04-06 23:21:02.0 
-0700
+++ python-pynvml-7.352.0/debian/control2019-09-03 16:09:07.0 
-0700
@@ -16,7 +16,7 @@
 Package: python3-pynvml
 Architecture: amd64 i386 armhf
 Depends:
- libnvidia-ml1 [!armhf]
+ libnvidia-ml1
  | libnvidia-legacy-390xx-ml1
  | libnvidia-legacy-340xx-ml1,
  ${misc:Depends},

Bug#939310: missing systray icon for blueman-applet

[Christopher Schramm]

Hi Peter,

sounds like there's some issue with the libappindicator-based icon 
implementation which disables the GTK-based one. Your edit effectively 
avoids the latter.


Did you try blueman 2.1.1-1 yet?

Cheers

Bug#875243: [yagf] Future Qt4 removal from Buster

[Moritz Mühlenhoff]

On Sat, Sep 09, 2017 at 11:13:30PM +0200, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Source: yagf
> Version: 0.9.3.2-1
> Severity: wishlist
> User: debian-qt-...@lists.debian.org
> Usertags: qt4-removal
> 
> 
> Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> as [announced] in:
> 
> [announced] 
> 
> 
> Currently Qt4 has been dead upstream and we are starting to have problems
> maintaining it, like for example in the [OpenSSL 1.1 support] case.
> 
> [OpenSSL 1.1 support] 
> 
> 
> In order to make this move, all packages directly or indirectly depending on
> the Qt4 libraries have to either get ported to Qt5 or eventually get
> removed from the Debian repositories.
> 
> 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,
similar ping as for qpxtool, last upstream commits are from 2015. Are you
planning to port it yourself or should it be removed?

Cheers,
Moritz

Bug#939333: varnish: VSV00003 DoS attack vector

[Steinar H. Gunderson]

tags 939333 + patch
thanks

On Tue, Sep 03, 2019 at 02:27:33PM +0200, Salvatore Bonaccorso wrote:
> See https://varnish-cache.org/security/VSV3.html . A CVE does not
> seem yet to be assigned (but a request pending now).

I made a backport to 6.1.1 for stable. It consists of all changes between
6.2.0 and 6.2.1 in git, except:

 - No bumping of version number or changelog.
 - Removed some unrelated change of #include order in otherwise untouched
   files.
 - The tests are not included (probably should be; I removed them as part
   of trying to backport in a slightly different fashion).
 - bin/varnishtest/vtc_http.c needed additional changes from the 6.2.0 set
   to have the end pointer vct_iscrlf() and vct_skipcrlf() now need;
   since varnishtest is not meant to be run against untrusted servers,
   I changed the patch to simply use the old, insecure versions
   (now named vct_iscrlf_unsafe() and vct_skipcrlf_unsafe()).
 - The diff has been refreshed to fix line numbers.

With this patch in debian/patches/, Varnish compiles and appears to run
normally (we already use it in production).

/* Steinar */
-- 
Homepage: https://www.sesse.net/
Index: varnish-6.1.1/bin/varnishd/cache/cache_http.c
===
--- varnish-6.1.1.orig/bin/varnishd/cache/cache_http.c
+++ varnish-6.1.1/bin/varnishd/cache/cache_http.c
@@ -212,7 +212,8 @@ http_Proto(struct http *to)
 
 	fm = to->hd[HTTP_HDR_PROTO].b;
 
-	if ((fm[0] == 'H' || fm[0] == 'h') &&
+	if (fm != NULL &&
+	(fm[0] == 'H' || fm[0] == 'h') &&
 	(fm[1] == 'T' || fm[1] == 't') &&
 	(fm[2] == 'T' || fm[2] == 't') &&
 	(fm[3] == 'P' || fm[3] == 'p') &&
Index: varnish-6.1.1/bin/varnishd/http1/cache_http1_proto.c
===
--- varnish-6.1.1.orig/bin/varnishd/http1/cache_http1_proto.c
+++ varnish-6.1.1/bin/varnishd/http1/cache_http1_proto.c
@@ -111,6 +111,7 @@ http1_dissect_hdrs(struct http *hp, char
 unsigned maxhdr)
 {
 	char *q, *r, *s;
+	int i;
 
 	assert(p > htc->rxbuf_b);
 	assert(p <= htc->rxbuf_e);
@@ -121,31 +122,34 @@ http1_dissect_hdrs(struct http *hp, char
 
 		/* Find end of next header */
 		q = r = p;
-		if (vct_iscrlf(p))
+		if (vct_iscrlf(p, htc->rxbuf_e))
 			break;
 		while (r < htc->rxbuf_e) {
 			if (!vct_isctl(*r) || vct_issp(*r)) {
 r++;
 continue;
 			}
-			if (!vct_iscrlf(r)) {
+			i = vct_iscrlf(r, htc->rxbuf_e);
+			if (i == 0) {
 VSLb(hp->vsl, SLT_BogoHeader,
 "Header has ctrl char 0x%02x", *r);
 return (400);
 			}
 			q = r;
-			assert(r < htc->rxbuf_e);
-			r += vct_skipcrlf(r);
-			if (r >= htc->rxbuf_e)
+			r += i;
+			assert(r <= htc->rxbuf_e);
+			if (r == htc->rxbuf_e)
 break;
-			if (vct_iscrlf(r))
+			if (vct_iscrlf(r, htc->rxbuf_e))
 break;
 			/* If line does not continue: got it. */
 			if (!vct_issp(*r))
 break;
 
 			/* Clear line continuation LWS to spaces */
-			while (vct_islws(*q))
+			while (q < r)
+*q++ = ' ';
+			while (q < htc->rxbuf_e && vct_issp(*q))
 *q++ = ' ';
 		}
 
@@ -206,11 +210,9 @@ http1_dissect_hdrs(struct http *hp, char
 			return (400);
 		}
 	}
-	/* We cannot use vct_skipcrlf() we have to respect rxbuf_e */
-	if (p+2 <= htc->rxbuf_e && p[0] == '\r' && p[1] == '\n')
-		p += 2;
-	else if (p+1 <= htc->rxbuf_e && p[0] == '\n')
-		p += 1;
+	i = vct_iscrlf(p, htc->rxbuf_e);
+	assert(i > 0);		/* HTTP1_Complete guarantees this */
+	p += i;
 	HTC_RxPipeline(htc, p);
 	htc->rxbuf_e = p;
 	return (0);
@@ -224,7 +226,7 @@ static uint16_t
 http1_splitline(struct http *hp, struct http_conn *htc, const int *hf,
 unsigned maxhdr)
 {
-	char *p;
+	char *p, *q;
 	int i;
 
 	assert(hf == HTTP1_Req || hf == HTTP1_Resp);
@@ -265,26 +267,34 @@ http1_splitline(struct http *hp, struct
 	hp->hd[hf[1]].e = p;
 	if (!Tlen(hp->hd[hf[1]]))
 		return (400);
-	*p++ = '\0';
 
 	/* Skip SP */
+	q = p;
 	for (; vct_issp(*p); p++) {
 		if (vct_isctl(*p))
 			return (400);
 	}
-	hp->hd[hf[2]].b = p;
+	if (q < p)
+		*q = '\0';	/* Nul guard for the 2nd field. If q == p
+ * (the third optional field is not
+ * present), the last nul guard will
+ * cover this field. */
 
 	/* Third field is optional and cannot contain CTL except TAB */
-	for (; !vct_iscrlf(p); p++) {
-		if (vct_isctl(*p) && !vct_issp(*p)) {
-			hp->hd[hf[2]].b = NULL;
+	q = p;
+	for (; p < htc->rxbuf_e && !vct_iscrlf(p, htc->rxbuf_e); p++) {
+		if (vct_isctl(*p) && !vct_issp(*p))
 			return (400);
-		}
 	}
-	hp->hd[hf[2]].e = p;
+	if (p > q) {
+		hp->hd[hf[2]].b = q;
+		hp->hd[hf[2]].e = p;
+	}
 
 	/* Skip CRLF */
-	i = vct_skipcrlf(p);
+	i = vct_iscrlf(p, htc->rxbuf_e);
+	if (!i)
+		return (400);
 	*p = '\0';
 	p += i;
 
Index: varnish-6.1.1/include/vct.h
===
--- varnish-6.1.1.orig/include/vct.h
+++ varnish-6.1.1/include/vct.h
@@ -30,6 +30,8 @@
 
 /* from libvarnish/vct.c */
 
+#include "vas.h"
+
 #define VCT_SP			(1<<0)
 #def

Bug#874809: [alsoft-conf] Future Qt4 removal from Buster

[Moritz Mühlenhoff]

On Mon, Sep 02, 2019 at 09:06:04PM +0200, Markus Koschany wrote:
> Hi,
> 
> Am 02.09.19 um 20:56 schrieb Moritz Mühlenhoff:
> [...]
> > alsoft-conf is dead upstream, does anyone in the Debian Games Team intend to
> > port it themselves? Otherwise I'll file a removal bug.
> 
> I'm fine with removing alsoft-conf from Debian. There was only one
> initial upload by the actual uploader of the package and I made the only
> other upload eight years later to fix some bugs and clean up the
> package. I guess it won't be missed.

Ack, thanks. I've just filed a removal bug.

Cheers,
Moritz

Bug#939355: RM: tegaki-tools -- RoQA; Depends on Python 2, dead upstream, orphaned

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove tegaki-train. It's dead upstream (last commit from 2014), depends 
on Python 2
and is orphaned since 2016.

Cheers,
Moritz

Bug#939356: RM: alsoft-conf -- RoQA; Depends on Qt4, dead upstream

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove alsoft-conf. It's dead upstream and depends on Qt4.

Cheers,
Moritz

Bug#939354: buster-pu: package capistrano/3.11.0-3+deb10u1

[Samuel Henrique]

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

Capistrano is a widely used tool for deployments, one of the steps
of a deployment is to remove the old releases, this consists in removing
the last Nth releases' folders.

Recently a bug has been found when one had too many releases, as they
are removed with the "rm" command, having too many arguments on the
command triggers the "argument list too long" error.

The fix[0] is a small change that splices the arguments in bulks of 100.
Note that the commit is also changing more things, but they're an extra
test and a changelog entry, thus I decided it would be better to add the
whole commit to the package.

In order for the fix to be applied, another commit[1][2] had to be applied
as well so there's no conflict and need to update the fix commit.
I understand an alternative would be to adapt the fix in some way that this
commit is not needed, I see the chosen approach as more stable and reliable
as it's the upstream's code that was well tested, besides this extra commit
being a small change.

In summary I believe this is a problem that should be fixed in stable and
the approach taken was consistent to our stable philosophy.

Let's make buster even more rock solid.

Thanks,

[0]
https://github.com/capistrano/capistrano/pull/2027/commits/89a77085780fbcae9b21d0aa10001969172cfa0a#diff-aa4465f31474e46370f8f1f204f7d51eR171
[1]https://github.com/capistrano/capistrano/pull/1995
[2]
https://github.com/capistrano/capistrano/pull/1995/commits/ad9c0a455516426e3c634e9c9925b9cfd77d5108

-- 
Samuel Henrique 


capistrano_3.11.0-3+deb10u1.debdiff
Description: Binary data

Bug#894241: speex: diff for NMU version 1.2~rc1.2-1.1

[Boyuan Yang]

Control: tags 894241 + pending

Dear maintainer,

I've prepared an NMU for speex (versioned as 1.2~rc1.2-1.1) and
uploaded it to DELAYED/15. Please feel free to tell me if I
should delay it longer.

Regards.

diff -u speex-1.2~rc1.2/debian/changelog speex-1.2~rc1.2/debian/changelog
--- speex-1.2~rc1.2/debian/changelog
+++ speex-1.2~rc1.2/debian/changelog
@@ -1,3 +1,14 @@
+speex (1.2~rc1.2-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Use dh_update_autotools_config to make the
+buildsystem recognize recent architectures like riscv64.
+(Closes: #894241)
+  * debian/control: Update Vcs-* fields and use git packaging
+repository under Debian Salsa platform.
+
+ -- Boyuan Yang   Tue, 03 Sep 2019 16:16:35 -0400
+
 speex (1.2~rc1.2-1) unstable; urgency=medium
 
   * Regenerate build system files, mostly to pull in a later libtool.m4
diff -u speex-1.2~rc1.2/debian/control speex-1.2~rc1.2/debian/control
--- speex-1.2~rc1.2/debian/control
+++ speex-1.2~rc1.2/debian/control
@@ -6,8 +6,8 @@
 Build-Depends-Indep: doxygen, graphviz
 Standards-Version: 3.9.5.0
 Homepage: http://www.speex.org/
-Vcs-Git: git://git.debian.org/users/ron/speex.git
-Vcs-Browser: http://git.debian.org/?p=users/ron/speex.git;a=summary
+Vcs-Git: https://salsa.debian.org/debian/speex.git
+Vcs-Browser: https://salsa.debian.org/debian/speex
 
 Package: speex
 Architecture: any
diff -u speex-1.2~rc1.2/debian/rules speex-1.2~rc1.2/debian/rules
--- speex-1.2~rc1.2/debian/rules
+++ speex-1.2~rc1.2/debian/rules
@@ -90,6 +90,7 @@
 
 %/config.status: configure
dh_testdir
+   dh_update_autotools_config
mkdir -p $*
cd $* && ../configure --host=$(DEB_HOST_GNU_TYPE)   \
  --build=$(DEB_BUILD_GNU_TYPE) \


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

Bug#924505: [Pkg-shadow-devel] Bug#924505: bash: set shell to /bin/sh on removal

[Chris Hofstaedtler]

* Matthias Klose  [190903 17:37]:
> On 02.09.19 21:14, Dmitry Bogatov wrote:
> > Subject: [PATCH] Change shells of users from /bin/bash to /bin/sh on removal
> 
> sorry for joining in lately into this game, but I didn't want to do that in
> parallel with my other Debian tasks.
> 
> I don't like the idea of automatic shell rewriting, [..]
> For user accounts it potentially creates broken
> init files, because the user's init files might use bashisms. The same might
> be true for system accounts, although you can manually check if these
> accounts use bashisms.  Nobody is hurt by having bash installed, you can
> avoid that for new installations, so this change doesn't seem to have any
> benefit which out weights the regression potential.  There also isn't any
> precedence for other shells doing that.

I also don't understand what the point of the whole exercise is;
once you have user accounts that use bash, they should just stay as
they were.
For new systems, defaulting to dash might be useful.

Cheers,
Chris

Bug#939308: gkrellm2-cpufreq_0.6.4-5_mips64el.changes REJECTED

[John Paul Adrian Glaubitz]

Hi Ansgar!

On 9/3/19 10:11 PM, Ansgar wrote:
> That should be "Missing mandatory field 'Section'"; fixed for the future
> in dak[1].
> 
>   [1]: 
> https://salsa.debian.org/ftp-team/dak/commit/e839612cdeac09be62453801945be2380d614c57

Ah, that makes more sense, indeed. Glad my mistake was able to spot a bug
in DAK ;).

>> I don't quite understand what the problem with this particular upload is and 
>> therefore
>> don't know how to fix it. Could someone give me a quick heads-up why the 
>> binary
>> packages built on the release buildds got rejected?
>>
>> FWIW, the builds on the ports buildds were installed without any problems, so
>> it must be DAK-specific.
> 
> The binary packages miss a "Section" field; the source packages
> d/control had a few unwanted characters before the field that were
> introduced in [2].

That's a really obscure mistake and I have no idea how that happened, probably
potato fingers with the combination of the possibilities of emacs late at night 
:).

> I submitted a pull request[3].  You might also want to change "Priority:
> extra" to "Priority: optional"; "extra" was deprecated in version 4.0.1
> of Debian's Policy.

Thanks for the suggestions, I will fix the package tomorrow.

Adrian

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

Bug#939353: systemd: CVE-2019-15718: Missing access controls on systemd-resolved's D-Bus interface

[Salvatore Bonaccorso]

Hi 

On Tue, Sep 03, 2019 at 10:12:39PM +0200, Salvatore Bonaccorso wrote:
[...]
> Please adjust the affected versions in the BTS as needed.

If I did triage it correctly then the issue does not affect stretch as
the the isse should have been introduced around the v237 release but
could you confirm please?

Regards,
Salvatore

Bug#926633: FutureWarning: Possible nested set at position 1

[Witold Baryluk]

Package: gdebi
Version: 0.9.5.7+nmu3
Followup-For: Bug #926633

Yes, same happens in en_US locale with 'y' answer.

The issue is in the regexp, it should be just:

r'\[(\S+)/\S+\]'


Example:

>>> msg = "Do you want to install the software package? [y/N]:"
>>> import re
>>> print re.findall(r'\[(\S+)/\S+\]', msg)[0].lower()
y
>>>

showing it works correctly.


I have no idea why [(] was used there in the first place, as it is
certainly not correct (but for some reasons work):


I see these commits affecting some changes in the regexp:

https://bazaar.launchpad.net/~gdebi-developers/gdebi/trunk/revision/402 , by 
Adam Barratt

https://bazaar.launchpad.net/~gdebi-developers/gdebi/trunk/revision/371  , 
closes bug #629403


My guess, some translations used a form of " (y/N):" instead.

If so, then a better and explicit choice is:

r'[\[\(](\S+)/\S+[\]\)]'

Example:

>>> msg = "Do you want to install the software package? [y/N]:"
>>> print re.findall(r'[\[\(](\S+)/\S+[\]\)]', msg)[0].lower()
y
>>> msg = "Do you want to install the software package? (y/N):"
>>> print re.findall(r'[\[\(](\S+)/\S+[\]\)]', msg)[0].lower()
y
>>>

for safety would be a better idea (do not relay on implicit rules inside
character class of treating special characters differently).

In principle the left side, the [[(], is correct and the second [ doesn't
need to be escaped according to traditional regexp rules. However, on the
right side, the [])], simply doesn't make sense, and is wrong. The ']'
character inside class defintion must be escaped, otherwise it closes the
character class (and it becomes empty character class, [], followed by
incorrect closing bracked ), and followed by a litteral implicit
character ]), so it must be [\])]. Maybe some regexp engines assume that
it doesn't make sense to create empty character class, so a next
character (]), is a part of a character class, but that simply is weird
thing to do, assume, and should be regarded as invalid regexp.



Cheers,
Witold



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

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

Versions of packages gdebi depends on:
ii  gdebi-core0.9.5.7+nmu3
ii  gir1.2-gtk-3.03.24.10-1
ii  gir1.2-vte-2.91   0.54.2-2
ii  gnome-icon-theme  3.12.0-3
ii  policykit-1   0.105-26
ii  python3   3.7.3-1
ii  python3-gi3.32.2-1

Versions of packages gdebi recommends:
ii  libgtk2-perl  2:1.24992-1+b2
ii  lintian   2.19.0
ii  shared-mime-info  1.10-1

gdebi suggests no packages.

-- no debconf information

Bug#939308: gkrellm2-cpufreq_0.6.4-5_mips64el.changes REJECTED

[Ansgar]

John Paul Adrian Glaubitz writes:
>> On 2019-09-02 23:19, Debian FTP Masters wrote:
>>> gkrellm-cpufreq_0.6.4-5_mips64el.deb: Missing mandatory field 
>>> gkrellm-cpufreq_0.6.4-5_mips64el.deb.

That should be "Missing mandatory field 'Section'"; fixed for the future
in dak[1].

  [1]: 
https://salsa.debian.org/ftp-team/dak/commit/e839612cdeac09be62453801945be2380d614c57

> I don't quite understand what the problem with this particular upload is and 
> therefore
> don't know how to fix it. Could someone give me a quick heads-up why the 
> binary
> packages built on the release buildds got rejected?
>
> FWIW, the builds on the ports buildds were installed without any problems, so
> it must be DAK-specific.

The binary packages miss a "Section" field; the source packages
d/control had a few unwanted characters before the field that were
introduced in [2].

I submitted a pull request[3].  You might also want to change "Priority:
extra" to "Priority: optional"; "extra" was deprecated in version 4.0.1
of Debian's Policy.

  [2]: 
https://github.com/glaubitz/gkrellm-cpufreq-debian/commit/bf53446db6a3de12cae9567ba4c5699121eed494
  [3]: https://github.com/glaubitz/gkrellm-cpufreq-debian/pull/1

Ansgar

Bug#923717: closed by Domenico Andreoli (Bug#923717: fixed in dwarves-dfsg 1.15-1)

[Paul Gevers]

Hi Domencio,

On 08-08-2019 21:40, Domenico Andreoli wrote:
>> So this libc-bin-dbgsym has no relation with dwarves? Than I guess it
> 
> Indeed it has not any.
> 
>> will work as you can always install the version from testing and no
>> relation will pull in the version from unstable. If that's the case,
>> just close the bug again. Otherwise, skip-not-installable *on top of*
>> other improvements will just mean that *if* any package is unsatisfiable
>> than the test is marked as skipped and as such adds a neutral result to
>> the final outcome.
> 
> Thanks, I'll consider it.

We overlooked one thing. Because your autopkgtest now depends on
libc-bin-dbgsym, when that package is updated, our migration software
will trigger a test for it. Due to the unfixed issue with debci, the
required version of libc-bin-dbgsym will not be available, and the test
will fail, blocking migration of glibc to testing. A glibc transition is
pending, this will be an issue.

You can see that this is happening on, the test triggered with
"glibc/2.29-0experimental1 orafce/3.8.0-1 postgresql-12/12~beta3-1
tracker/2.2.1-1":
https://ci.debian.net/packages/d/dwarves-dfsg/unstable/amd64/

Paul



signature.asc
Description: OpenPGP digital signature

Bug#517256: xpdf exclusive access to audio device - propose closure

[Boud Roukema]

hi mozilla-related packages maintainers,

I remember having xpdf blocking access to audio devices several years ago.

I suggest that unless someone can still reproduce the bug in buster (I'm still
on stretch, but haven't seen that bug for at least a year or so), that this
bug be closed:

* this is Debian bug #517256

* first message 2009-02-26;

* most recent tag is fixed-upstream 2017-10-16 - 
https://bugzilla.mozilla.org/show_bug.cgi?id=1406971 -
seems to show that the bug was fixed in firefox 58 - and firefox-esr is now at 
60.7.2esr-1 in buster=stable.

The related bugs 410671, 487781, 496958 should presumably also be closed.

Cheers
Boud

Bug#939353: systemd: CVE-2019-15718: Missing access controls on systemd-resolved's D-Bus interface

[Salvatore Bonaccorso]

Source: systemd
Version: 242-6
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for systemd.

CVE-2019-15718[0]:
Missing access controls on systemd-resolved's D-Bus interface

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-15718
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15718
[1] https://www.openwall.com/lists/oss-security/2019/09/03/1
[2] https://github.com/systemd/systemd/pull/13457
[3] 
https://github.com/systemd/systemd/pull/13457/commits/35e528018f315798d3bffcb592b32a0d8f5162bd

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#934132: Unblock elogind 241.3-1+debian1 migration to bullseye

[Mark Hindley]

Control: severity 934491 serious

On Tue, Sep 03, 2019 at 09:34:51PM +0200, Julien Cristau wrote:
> Anyway, I guess if #934491 is upgraded to RC then I can drop the block
> hint.

Thank you.

Best wishes

Mark

Bug#939352: RM: django-threaded-multihost -- RoM; dead upstream; RC-buggy; no Python 3 support and no reverse deps

[Andrey Rahmatullin]

Package: ftp.debian.org
Severity: normal
User: debian-pyt...@lists.debian.org
Usertags: py2removal

Doesn't work with current Django. No new upstream versions in Debian
since the first upload in 2010. The homepage is dead.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#939351: RM: django-app-plugins -- RoM; RC-buggy; ancient; no Python 3 support and no reverse deps

[Andrey Rahmatullin]

Package: ftp.debian.org
Severity: normal
User: debian-pyt...@lists.debian.org
Usertags: py2removal

The version in Debian is released in 2009, no upstream releases since
then.
The package doesn't work, according to its RC bugs.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#939350: RM: python-django-rosetta -- RoM; RC-buggy; no Python 3 support and no reverse deps; low popcon

[Andrey Rahmatullin]

Package: ftp.debian.org
Severity: normal
User: debian-pyt...@lists.debian.org
Usertags: py2removal

Doesn't support modern Django and FTBFS because of that (#933146).

Popcon 20.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#939349: RM: django-prometheus -- RoM; RC-buggy; low popcon

[Andrey Rahmatullin]

Package: ftp.debian.org
Severity: normal
User: debian-pyt...@lists.debian.org
Usertags: py2removal

The package FTBFS (#918418).
Ships a Python 2 subpackage which can't be dropped because of that FTBFS.

Popcon 11.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#934132: Unblock elogind 241.3-1+debian1 migration to bullseye

[Julien Cristau]

On Tue, Sep  3, 2019 at 15:29:49 +0100, Mark Hindley wrote:

> On Wed, Aug 14, 2019 at 07:22:47PM +0100, Jonathan Wiltshire wrote:
> > I think your summary is fine. However, this is not my area of expertise and
> > I'm rather hoping Julien or Ansgar will chime in with an update.
> > 
> > It certainly wouldn't be appropriate for me to remove a block put in place
> > by someone else without extenuating circumstances.
> 
> Julien,
> 
> I am still waiting for some constructive engagement over this.
> 
> As Jonathan's comment above makes clear and is echoed by this exchange on
> #debian-release yesterday:
> 
>  Hello. #934132 is still outstanding and is now preventing resolution
>of RC bug in bullseye #939101.  [12:13]
>  Can we find a resolution to #934132? Thanks.  [12:17]
>  weasel: zwiebelbot is missing here  [12:34]
>  jcristau: ^ (#934132)  [13:12]
>  jmw: well i still think shipping this thing is a bad idea.  but i'm
>  ok with somebody else removing the block.  [13:21]
>  I don't know enough about it to make a call on that
>  but I think LeePen would appreciate some sort of response
> 
> it is obvious and completely understandable that other members of the Release
> Team will not overrule your hint blocking elogind migration to bullseye. So,
> resolution of this bug (and the resulting FTBFS in bullseye) is down to you.
> 
> I have tried to answer your concerns in detail. If you think my answers are
> inadequate or still think there are issues that need to be addressed, please
> specify them. If not, please remove your block of elogind's migration to
> testing.
> 
I don't think it's reasonable to ship this package with C/R/P
libsystemd0.

I think it opens you (and, more importantly, users) up to issues like
#934491.  Even if #935910 were to be fixed in the package manager in
bullseye, it would still mean libelogind0 couldn't ship with the C/R/P
until bullseye+1.  But beyond that particular issue, I'm sorry to say I
think fundamentally attempting to provide a drop-in replacement for
libsystemd0 while conflicting with systemd is doomed.  The replacement
of sysvinit with systemd was careful to keep both init systems
co-installable, and I think that's something to preserve to avoid
providing users with a loaded footgun with alternative init systems.

Anyway, I guess if #934491 is upgraded to RC then I can drop the block
hint.

Cheers,
Julien

Bug#939348: RM: djangocms-admin-style -- RoM; RC-buggy; low popcon

[Andrey Rahmatullin]

Package: ftp.debian.org
Severity: normal
User: debian-pyt...@lists.debian.org
Usertags: py2removal

Doesn't support modern Django and FTBFS because of that (#865293).
Ships a Python 2 subpackage which can't be dropped because of that FTBFS.

Popcon 15 and less.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#934132: Unblock elogind 241.3-1+debian1 migration to bullseye

[Mark Hindley]

Sam,

Many thanks for your input on this.

On Tue, Sep 03, 2019 at 03:12:18PM -0400, Sam Hartman wrote:
> I do agree with simon that #934491 does leave the system in a really bad
> state.  And while I agree with you that it is not elogind's fault, it's
> a situation that tends to only come up when elogind is in the picture.
> I think Michael has a point that we should consider the impact of
> #934491 on bullseye before introducing the elogind in sid to bullseye.

Absolutely.

> >From where I sit that impact is fairly significant, and I can see
> wanting to fix apt or dpkg or whatever we're going to fix prior to
> making that change in bullseye.
> 
> I can also see the argument that it's fairly early in the cycle and this
> issue is not elogind's fault as discussed in #934491.

My suggestion is to raise #934491 and/or #935910 to RC status and for the
Release Team to remove the manual migration block. That way, once all RC bugs
are satisfactorily resolved, normal migration can take place.

Thanks

Mark

Bug#939347: flatpak: prerm/postrm scripts don't remove /var/lib/flatpak

[Горбешко Богдан]

Package: flatpak
Version: 1.4.2-2
Severity: normal

Dear Maintainer,

when I purged the flatpak package, /var/lib/flatpak and all of it's 
contents are still left here — 21 MB, quite a lot.




-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'oldoldstable-updates'), 
(500, 'oldoldstable'), (500, 'testing')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ru_UA.UTF-8, LC_CTYPE=ru_UA.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_UA:ru (charmap=UTF-8)

Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages flatpak depends on:
ii  adduser    3.118
ii  bubblewrap 0.3.3-2
pn  libappstream-glib8 
ii  libarchive13   3.3.3-4
ii  libc6  2.28-10
ii  libdconf1  0.30.1-2
ii  libfuse2   2.9.9-1
ii  libgdk-pixbuf2.0-0 2.38.1+dfsg-1
ii  libglib2.0-0   2.60.6-2
ii  libgpgme11 1.13.1-1
ii  libjson-glib-1.0-0 1.4.4-2
pn  libostree-1-1  
ii  libpolkit-agent-1-0    0.105-26
ii  libpolkit-gobject-1-0  0.105-26
ii  libseccomp2    2.4.1-2
ii  libsoup2.4-1   2.64.2-2
ii  libsystemd0    242-4
ii  libxau6    1:1.0.8-1+b2
ii  libxml2    2.9.4+dfsg1-7+b3
pn  xdg-dbus-proxy 
pn  xdg-desktop-portal 

Versions of packages flatpak recommends:
ii  desktop-file-utils   0.24-1
ii  gtk-update-icon-cache    3.24.10-1
ii  hicolor-icon-theme   0.17-2
ii  libpam-systemd   242-4
ii  p11-kit 0.23.16.1-2
ii  policykit-1  0.105-26
ii  shared-mime-info 1.10-1
pn  xdg-desktop-portal-gtk | xdg-desktop-portal-backend 

Versions of packages flatpak suggests:
ii  avahi-daemon  0.7-4+b1

Bug#939088: Unable to accept TLS connection: system call error: [104]

[Frédéric Mathy]

Problem solved by adding the TLS option : TLSOptions NoSessionReuseRequired

-> http://www.proftpd.org/docs/howto/TLS.html

ALl thanks

Le 01/09/2019 à 21:38, Hilmar Preuße a écrit :

On 01.09.19 09:58, Frédéric Mathy wrote:


Since update Debian 9 to 10, I can't connect via FTP TLS/SSL

TLS/TLS-C requested, starting TLS handshake
unable to accept TLS connection: system call error: [104] Connexion
ré-initialisée par le correspondant


Unfortunately I don't speak french. What I found in [1] is that the
client disconnected the session.

1. Is the issue reproducible w/ a different client?
2. Do you have some logs from the client telling, why the client
disconnected the session?
3. Is #922307 similar to your one?

Hilmar

[1] https://sourceforge.net/p/proftp/mailman/message/25665563/

Bug#939290: missing dependency on newer libstdc++ (Re: Bug#939290: libfmt-dev)

[Martin Michlmayr]

* Eugene V. Lyubimkin  [2019-09-03 20:14]:
> Yes, thank you for the report. It seems the latest build in unstable
> picked up some symbols from libstdc++ which are not satisfied in
> stable.

Thanks, that's what I thought but I wasn't sure.

Anyway, I re-built the package successfully on Debian stable and was
able to build other package I wanted to build.

-- 
Martin Michlmayr
https://www.cyrius.com/

Bug#939346: nmu: rubyluabridge_0.8.0-2

[Roberto C. Sanchez]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

My upload of rubyluabridge 0.8.0-2 was a binary upload built on amd64.
This is because the package is maintained with mercurial-buildpackage
and I was unable to get it to generate a source.changes.  Please binNMU
rubyluabridge on amd64 so that it might migrate into testing:

nmu rubyluabridge_0.8.0-2 . amd64 . unstable . -m "no-change rebuild"

Regards,

- -Roberto

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

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

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEz9ERzDttUsU/BH8iLNd4Xt2nsg8FAl1uuvsACgkQLNd4Xt2n
sg/BCw//XXmOUoOr+7HE+WZnfQOwP+OdDCZPSrK5rIt5jljaZg/+npfHv4mcbY07
sCm45xcjW624z9i0iETujFDd8C01fGdJbRpECfTxd8q3xo2+zkKnl6HpNm3IvGhA
lqgx/YwPeNnW1sCVfTT6BsscScXCHvQKZ9S3b0WSupoteNMxTyVC4mdHBTjx66K9
fyDvc/5kknThc5RucVpysvmVPDapI4Ft+VOtxi8Ax/wGbrPXwJPjQy9gjhxfhXdl
rM7E3w/aBWAMFxqGKFcZ3LbaqCJZo48axfMsLGhzji+yN88f0OmlgloleZDwidDB
lNJte/8qH0/7RsrWMTz1kIVqSfizEpEPpts+2rl+k8aHkIxq4Lev1d/PofIRbvw7
mTT0W/fFBRWFglps4ovTkaxcuj9Dbh6YmSRSMSjQ5IbAKnSoM8Vb9YybNWiEQ7gd
FGsEtlUvRPhf6RvMjG5jQv2togDRoMq1wP+wANu3cEPprcz/5g3emraM5bYx7bk6
Ff5ajQoqmgEIdw6zr1GE3YX7ESHekFBxZzzfjRa6tqlE6/S6r772hcEFElZYws/u
m8puwaGfCQWV7ZqarC2Pne72oO6y3qetwlExkEYW3aH9f+XAqQlgGwR5EbmQJ6Iy
ys3l8UphebejYoJavVOgqT8IRUPGgwNQFPW0B8D018HckijAY5Q=
=naOq
-END PGP SIGNATURE-

Bug#918276: closed by Sebastian Ramacher (Re: Bug#918276: (no subject))

[Сергей Фёдоров]

Probably You still did something, so VLC packages version 3.0.8-2
have established and work normally.

18.08.2019, 23:21, "Debian Bug Tracking System" :
> This is an automatic notification regarding your Bug report
> which was filed against the vlc package:
>
> #918276: vlc: When you open VLC 3.0.5-1 any .mp4 file a Debian 9.6 hangs
>
> It has been closed by Sebastian Ramacher .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Sebastian Ramacher 
>  by
> replying to this email.
>
> --
> 918276: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918276
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

Bug#934132: Unblock elogind 241.3-1+debian1 migration to bullseye

[Sam Hartman]

> "Mark" == Mark Hindley  writes:

Mark> Michael,
Mark> On Tue, Sep 03, 2019 at 04:56:13PM +0200, Michael Biebl wrote:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934491
>> 
>> This bug report should be taken into account here. Not sure why
>> this is not marked as RC given that it can pretty much hose your
>> system.

Mark> If you actually read to the end of that report you will see
Mark> the suggestion that this behaviour is actually caused by apt
Mark> and/or dpkg, not elogind.

First, thanks for your work on elogind.
I appreciate the professional manner you've handled the communication
with the release team on this issue, the professional manner in which
you worked with the systemd maintainers to get to the current elogind
design, and the professional manner in which you worked through##934491.

I do agree with simon that #934491 does leave the system in a really bad
state.  And while I agree with you that it is not elogind's fault, it's
a situation that tends to only come up when elogind is in the picture.
I think Michael has a point that we should consider the impact of
#934491 on bullseye before introducing the elogind in sid to bullseye.

>From where I sit that impact is fairly significant, and I can see
wanting to fix apt or dpkg or whatever we're going to fix prior to
making that change in bullseye.

I can also see the argument that it's fairly early in the cycle and this
issue is not elogind's fault as discussed in #934491.

Bug#931125: ufw: Rules disappear when updating task list

[Jamie Strandboge]

On Tue, 27 Aug 2019, Eloi Coutant wrote:

> Hi,
> 
> Thanks for coming back to me about this issue. Unfortunately, as it was too
> critical an issue to keep in "prod" (on a self-hosted server), I chose to
> switch to another firewall controller.

No worries, the information you provided lets me know that you would see
the issue without this fix:

https://git.launchpad.net/ufw/commit/?id=569edf283bd18c5816f980b8480cf02f1d1ead03

This will be fixed in the next ufw upload.

> 
> I had the following custom apps:
> 
> [OpenSSH600]
> title=Secure shell server, an rshd replacement
> description=OpenSSH is a free implementation of the Secure Shell protocol.
> ports=600/tcp
> 
> [Mail]
> title=AnBuCo Mail
> description=Dovecot+Postfix+Sieve
> ports=143,993,25,465,587,4190/tcp
> 
> [F2BMail]
> title= Fail2ban Mail
> description=Dovecot+Postfix+Sieve
> ports=143,993,25,465,587,4190/tcp
> 
> [F2BRecidive]
> title=Fail2ban recidive
> description=close all connections
> ports=143,993,25,465,587,41910,600/tcp
> 
> and the rules were enabled like so:
> # ufw allow in OpenSSH600
> # ufw allow out OpenSSH600
> # ufw allow in Mail
> # ufw allow out Mail
> # ufw allow in 'Nginx Full'
> # ufw allow out 'Nginx Full'
> # ufw allow out DNS
> 
> The "F2B" rules were added and deleted by fail2ban using the default
> /etc/fail2ban/action.d/ufw.conf actions.
> 
> Skipping the fail2ban rules, 'ufw status verbose' was returning when running
> well:
> 
> > 80,443/tcp (Nginx Full)ALLOW INAnywhere
> > 8080/tcp (WWW Cache)   ALLOW INAnywhere
> > 53 (DNS)   ALLOW INAnywhere
> > 123/udpALLOW INAnywhere # NTP
> > 24441  ALLOW INAnywhere # Pyzor
> > 873/tcpALLOW INAnywhere # Rsync
> > 137,138/udp (Samba)ALLOW INAnywhere
> > 139,445/tcp (Samba)ALLOW INAnywhere
> > 600/tcp (OpenSSH600)   ALLOW INAnywhere
> > 25,143,465,587,993,4190/tcp (Mail) ALLOW INAnywhere
> > 67/udp ALLOW INAnywhere
> > 68/udp ALLOW INAnywhere
> >
> > 123/udpALLOW OUT   Anywhere  # NTP
> > 2703/tcp   ALLOW OUT   Anywhere  # Razor
> > 7/tcp  ALLOW OUT   Anywhere  # Razor
> > 24441  ALLOW OUT   Anywhere  # Pyzor
> > 11371  ALLOW OUT   Anywhere  # GPG Keys
> > 873/tcpALLOW OUT   Anywhere  # Rsync
> > 67/udp ALLOW OUT   Anywhere
> > 68/udp ALLOW OUT   Anywhere
> > 25,143,465,587,993,4190/tcp (Mail) ALLOW OUT   Anywhere
> > 80,443/tcp (Nginx Full)ALLOW OUT   Anywhere
> > 53 (DNS)   ALLOW OUT   Anywhere
> > 137,138/udp (Samba)ALLOW OUT   Anywhere
> > 139,445/tcp (Samba)ALLOW OUT   Anywhere
> 
> 
> Some rules disappeared while other stayed when 'ufw app update all' was
> triggered. I cannot unfortunately tell you precisely which apps were
> deleted; my logs seem to indicate that it was in majority outgoing rules for
> 'Nginx Full', 'DNS' and 'Mail'.
> 
> Sorry if I cannot be more helpful, the issue was in my opinion a bit too
> critical to continue with ufw at the time.
> 
> Cheers
> Eloi
> 
> Le 25/08/2019 à 20:48, Jamie Strandboge a écrit :
> > I believe this will be fixed with this:
> > https://git.launchpad.net/ufw/commit/?id=569edf283bd18c5816f980b8480cf02f1d1ead03
> > 
> > However there isn't enough information in this bug report to be sure.
> > Can you provide the full list of ufw app rules in the order you add them
> > for any rules that reference Nginx Full, DNS and Mail? You can send that
> > to me privately if you prefer.
> > 
> > Thanks!
> > 
-- 
Jamie Strandboge | http://www.canonical.com


signature.asc
Description: PGP signature

Bug#934755: closed by Sean Davis (Bug#934755: fixed in menulibre 2.2.1-1)

[Сергей Фёдоров]

You are right, version 2.2.1-1 has solved this problem. I downloaded it
from the website https://launchpad.net/menulibre and installed it instead
of version 2.2.0-2.
After the emergence of Your package version 2.2.1-1, moved on him and, too, all 
works.
Thanks!


01.09.2019, 03:09, "Debian Bug Tracking System" :
> This is an automatic notification regarding your Bug report
> which was filed against the menulibre package:
>
> #934755: menulibre 2.2.0-2 does not start on debian 10
>
> It has been closed by Sean Davis .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Sean Davis 
>  by
> replying to this email.
>
> --
> 934755: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934755
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

Bug#938987: Overly restrictive CapabilityBoundingSet

[Markus Schade]

Hi Joel,

thanks for the report.

The systemd service file has been in part of the package for 5 years,
with the default ordering of sections (unit, service, install).
The upstream service while was more less recently added (~1 year ago).

Since systemd hardening has been available and recommended, the
corresponding directives where added from upstream.
Admittedly this still requires some fine tuning such as:
https://salsa.debian.org/dns-team/nsd/merge_requests/1

As such, I am a bit reluctant to ship, use or patch around the upstream
service file.

However the DAC_OVERRIDE capability is quite excessive as is bypasses
all permission checks. Giving the process this capability would be the
quite contrary to the intent of settting CapabilityBoundingSet.

Best regards,
Markus

Bug#934132: Unblock elogind 241.3-1+debian1 migration to bullseye

[Mark Hindley]

Michael,

On Tue, Sep 03, 2019 at 04:56:13PM +0200, Michael Biebl wrote:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934491
> 
> This bug report should be taken into account here. Not sure why this is
> not marked as RC given that it can pretty much hose your system.

If you actually read to the end of that report you will see the  suggestion that
this behaviour is actually caused by apt and/or dpkg, not elogind.

I opened a blocking bug against apt which was reassigned to dpkg:

 https://bugs.debian.org/935910.

I avoided merely reassigning #934491 itself so that I can be sure there is no
problem with elogind once #935910 is fixed.

Best wishes

Mark

Bug#939341: Missing transaltion in *.desktop

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, 2019-09-03 at 19:45 +0200, Mechtilde Stehmann wrote:
> I miss the translation in
> /usr/share/applications/xfce-workspaces-settings.desktop
> 
> In German it should be 
> 
> I found this entry in the po file. but in the *.desktop file.
> 
> I didn't find the *.desktop file in debian/ on salsa.debian.org , too.
> 
> so I don't know how I can help with a good translated XFCE4

Yes, for some reason it looks like all translations are missing. We'll take a
look.

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl1ur/IACgkQ3rYcyPpX
RFufjAgAgr/r4foxH2pcqgP6WpG9TmSrebjn+PVyJ7QC1t0w0nFSdrbLE9q34M5M
DFS7vs7zsVlM3TL92Ua2jRZJPobxxWwdaBalDafEArpWG6Gx6sYaWJV4pIFNDpur
TZN6jN6kMZDPD6y/N1EpUIBCq6QftYVn59e0v5wDRmyTHxIYCVVEjWaH8zFjbxyo
rnCovX21f2GwzywUDJSY6m3Avip/ca7ybxZd8TDkPU5dVl4e8+OpEL1HkcxverT9
Amb13fhkVzUMBZ/7kfadmys6sWZkv0zZCllVqI1SnAAewYumDDArFDBLdIXj9IgG
pGEBWvEABMnwVASU6kChFdhdR85xHQ==
=rxVu
-END PGP SIGNATURE-

Bug#939290: missing dependency on newer libstdc++ (Re: Bug#939290: libfmt-dev)

[Eugene V. Lyubimkin]

Hi,

Martin Michlmayr kirjoitti 2.9.2019 klo 22.53:
> Package: libfmt-dev
> Version: 5.3.0+ds-1
[...]
> /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libfmt.a(format.cc.o): in function 
> `fmt::v5::system_error::init(int, fmt::v5::basic_string_view, 
> fmt::v5::format_args)':
> (.text+0xd52): undefined reference to 
> `std::runtime_error::operator=(std::runtime_error&&)'
> collect2: error: ld returned 1 exit status
> 
> Any idea what this is about?

Yes, thank you for the report. It seems the latest build in unstable picked up 
some symbols
from libstdc++ which are not satisfied in stable. Quick work-around: install 
libstdc++6 from
Debian testing.

This bug will be fixed by listing the missing package dependency.


Regards,
-- 
Eugene V. Lyubimkin aka JackYF
C++ GNU/Linux userspace developer, Debian Developer

Bug#931729: apt-mirror: SSUse of uninitialized value $lines{"Files:"} in split at /usr/bin/apt-mirror line 829

[Сергей Фёдоров]

To solve a problem I wrote about earlier,
in the text of the program "apt-mirror 0.5.4-1" commented line

775 sub process_index
776 {
...
814 if ( exists $lines{"Filename:"} )
{# Packages index
$skipclean{ remove_double_slashes( $path . "/" . 
$lines{"Filename:"} ) } = 1;
print FILES_ALL remove_double_slashes( $path . "/" . 
$lines{"Filename:"} ) . "\n";
print FILES_MD5 $lines{"MD5sum:"} . "  " . remove_double_slashes( 
$path . "/" . $lines{"Filename:"} ) . "\n" if defined $lines{"MD5sum:"};
print FILES_SHA1 $lines{"SHA1:"} . "  " . remove_double_slashes( 
$path . "/" . $lines{"Filename:"} ) . "\n" if defined $lines{"SHA1:"};
print FILES_SHA256 $lines{"SHA256:"} . "  " . 
remove_double_slashes( $path . "/" . $lines{"Filename:"} ) . "\n" if defined 
$lines{"SHA256:"};
if ( need_update( $mirror . "/" . $lines{"Filename:"}, 
$lines{"Size:"} ) )
{
print FILES_NEW remove_double_slashes( $uri . "/" . 
$lines{"Filename:"} ) . "\n";
add_url_to_download( $uri . "/" . $lines{"Filename:"}, 
$lines{"Size:"} );
}
}
827 #else  # my comment
elsif ( exists $lines{"Files:"} )  # my insert
{# Sources index
foreach ( split( /\n/, $lines{"Files:"} ) )
{

After this change everything works fine and the message

Processing indexes: [SUse of uninitialized value $lines{"Files:"} in split 
at /usr/bin/apt-mirror line 829,  line 1.
Use of uninitialized value $lines{"Files:"} in split at /usr/bin/apt-mirror 
line 829,  line 2.
P]

no longer appears. 

Bug#937104: [Python-modules-team] Bug#937104: namebench: Python2 removal in sid/bullseye

[Miguel Landaeta]

On Sun, Sep 01, 2019 at 02:48:00PM -0400, Scott Kitterman wrote:
> 
> If the future is definitely not python3, I think it's better to remove it now 
> (I've seen people criticize packages being removed shortly before release and 
> I understand why, people don't have time to react).  It's easy enough to re-
> introduce the package should a modernized version appear.
> 

Fair enough, I just filed #939342 for its removal.

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche


signature.asc
Description: PGP signature

Bug#939345: RM: tegaki-train -- RoQA; depends on python 2, dead upstream, orphaned

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove tegaki-train. It's dead upstream (last commit from 2014), depends 
on Python 2
and is orphaned since 2016.

Cheers,
Moritz

Bug#939344: RM: tegaki-recognize -- RoQA; depends on python 2, dead upstream, orphaned

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove tegaki-recognize. It's dead upstream (last commit from 2014), 
depends on Python 2
and is orphaned since 2016.

Cheers,
Moritz

Bug#939343: graphy -- removal triggered by the Python2 removal

[Miguel Landaeta]

Package: ftp.debian.org
Severity: normal

As title says.
For more information, please see #936654.

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche


signature.asc
Description: PGP signature

Bug#939342: RM: namebench -- removal triggered by the Python2 removal

[Miguel Landaeta]

Package: ftp.debian.org
Severity: normal

As title says.
For more information, please see #937104.

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche


signature.asc
Description: PGP signature

Bug#938178: python-snappy: Python2 removal in sid/bullseye

[Shell Xu]

control: usertag -1 +py2keep

I did some search. Looks like python-snappy has been depended by
`python-autobahn` and `python-kafka`.

On Fri, Aug 30, 2019 at 5:21 PM Matthias Klose  wrote:

> Package: src:python-snappy
> Version: 0.5.3-1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
>
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html
>
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests.  Please stop using Python2, and fix this issue
> by one of the following actions.
>
> - Convert your Package to Python3. This is the preferred option.  In
>   case you are providing a Python module foo, please consider dropping
>   the python-foo package, and only build a python3-foo package.  Please
>   don't drop Python2 modules, which still have reverse dependencies,
>   just document them.
>
>   This is the preferred option.
>
> - If the package is dead upstream, cannot be converted or maintained
>   in Debian, it should be removed from the distribution.  If the
>   package still has reverse dependencies, raise the severity to
>   "serious" and document the reverse dependencies with the BTS affects
>   command.  If the package has no reverse dependencies, confirm that
>   the package can be removed, reassign this issue to ftp.debian.org,
>   make sure that the bug priority is set to normal and retitle the
>   issue to "RM: PKG -- removal triggered by the Python2 removal".
>
> - If the package has still many users (popcon >= 300), or is needed to
>   build another package which cannot be removed, document that by
>   adding the "py2keep" user tag (not replacing the py2remove tag),
>   using the debian-pyt...@lists.debian.org user.  Also any
>   dependencies on an unversioned python package (python, python-dev)
>   must not be used, same with the python shebang.  These have to be
>   replaced by python2/python2.7 dependencies and shebang.
>
>   This is the least preferred option.
>
> If the conversion or removal needs action on another package first,
> please document the blocking by using the BTS affects command, like
>
>   affects  + src:python-snappy
>
> If there is no py2removal bug for that reverse-dependency, please file
> a bug on this package (similar to this bug report).
>
> If there are questions, please refer to the wiki page for the removal:
> https://wiki.debian.org/Python/2Removal, or ask for help on IRC
> #debian-python, or the debian-pyt...@lists.debian.org mailing list.
>


-- 
彼節者有間，而刀刃者無厚；以無厚入有間，恢恢乎其於游刃必有餘地矣。
blog: http://shell909090.org/
twitter: @shell909090 
about.me: http://about.me/shell909090

Bug#938475: shadowsocks: Python2 removal in sid/bullseye

[Shell Xu]

control: reassign -1 ftp.debian.org
control: retitle -1 RM: shadowsocks -- removal triggered by the Python2
removal

I think this package should been removed from debian. It's dead in the
upstream, the last commit there was in Dec 2018, and none of commits/issues
ever talked about python3 upgrading. Currently its popcon is 149, but all
of its users could immigrate to shadowsocks-libev with no pain. Please
remove it from Debian. Thank you for your generous help in the past three
years, and thank you for your contribution in python2 clean up job.

On Fri, Aug 30, 2019 at 5:39 PM Matthias Klose  wrote:

> Package: src:shadowsocks
> Version: 3.0.0~2018.07.31.git.2c107740eb-3
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
>
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html
>
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests.  Please stop using Python2, and fix this issue
> by one of the following actions.
>
> - Convert your Package to Python3. This is the preferred option.  In
>   case you are providing a Python module foo, please consider dropping
>   the python-foo package, and only build a python3-foo package.  Please
>   don't drop Python2 modules, which still have reverse dependencies,
>   just document them.
>
>   This is the preferred option.
>
> - If the package is dead upstream, cannot be converted or maintained
>   in Debian, it should be removed from the distribution.  If the
>   package still has reverse dependencies, raise the severity to
>   "serious" and document the reverse dependencies with the BTS affects
>   command.  If the package has no reverse dependencies, confirm that
>   the package can be removed, reassign this issue to ftp.debian.org,
>   make sure that the bug priority is set to normal and retitle the
>   issue to "RM: PKG -- removal triggered by the Python2 removal".
>
> - If the package has still many users (popcon >= 300), or is needed to
>   build another package which cannot be removed, document that by
>   adding the "py2keep" user tag (not replacing the py2remove tag),
>   using the debian-pyt...@lists.debian.org user.  Also any
>   dependencies on an unversioned python package (python, python-dev)
>   must not be used, same with the python shebang.  These have to be
>   replaced by python2/python2.7 dependencies and shebang.
>
>   This is the least preferred option.
>
> If the conversion or removal needs action on another package first,
> please document the blocking by using the BTS affects command, like
>
>   affects  + src:shadowsocks
>
> If there is no py2removal bug for that reverse-dependency, please file
> a bug on this package (similar to this bug report).
>
> If there are questions, please refer to the wiki page for the removal:
> https://wiki.debian.org/Python/2Removal, or ask for help on IRC
> #debian-python, or the debian-pyt...@lists.debian.org mailing list.
>


-- 
彼節者有間，而刀刃者無厚；以無厚入有間，恢恢乎其於游刃必有餘地矣。
blog: http://shell909090.org/
twitter: @shell909090 
about.me: http://about.me/shell909090

Bug#939341: Missing transaltion in *.desktop

[Mechtilde Stehmann]

Package: xfwm4
Version: 4.14
Severity normal

Hello

I miss the translation in
/usr/share/applications/xfce-workspaces-settings.desktop

In German it should be 

I found this entry in the po file. but in the *.desktop file.

I didn't find the *.desktop file in debian/ on salsa.debian.org , too.

so I don't know how I can help with a good translated XFCE4

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

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

Versions of packages xfwm4 depends on:
ii  libc6 2.28-10
ii  libcairo2 1.16.0-4
ii  libepoxy0 1.5.3-0.1
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libglib2.0-0  2.60.6-2
ii  libgtk-3-03.24.10-1
ii  libpango-1.0-01.42.4-7
ii  libpangocairo-1.0-0   1.42.4-7
ii  libstartup-notification0  0.12-6
ii  libwnck-3-0   3.32.0-1
ii  libx11-6  2:1.6.7-1
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.5-1
ii  libxext6  2:1.3.3-1+b2
ii  libxfce4ui-2-04.14.1-1+b1
ii  libxfce4util7 4.14.0-1
ii  libxfconf-0-3 4.14.1-1
ii  libxfixes31:5.0.3-1
ii  libxi62:1.7.9-1
ii  libxinerama1  2:1.1.4-2
ii  libxpresent1  1.0.0-2+b10
ii  libxrandr22:1.5.1-1
ii  libxrender1   1:0.9.10-1

Versions of packages xfwm4 recommends:
ii  librsvg2-common  2.44.14-1

Versions of packages xfwm4 suggests:
ii  xfce4  4.14

-- no debconf information

-- 
Mechtilde Stehmann
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F



signature.asc
Description: OpenPGP digital signature

Bug#935929: RFS: btrfs-progs/5.2.1-1~bpo10+1 -- Checksumming Copy on Write Filesystem utilities

[Nicholas D Steeves]

On Tue, Sep 03, 2019 at 04:44:31PM +, Gianfranco Costamagna wrote:
>ack!
>Il mercoledì 28 agosto 2019, 05:45:30 CEST, Nicholas D Steeves
> ha scritto:
>Package: sponsorship-requests
>Severity: normal
>Dear mentors (CCing Gianfranco who sponsored this pkg many times in the
>past),
>I am looking for a sponsor for my package "btrfs-progs" and am
>continuing my support for a stable-backport of this package.  In
>addition to the usual btrfs-check (offline fsck equivalent)
>improvements and bugfixes, this release includes a variety of cosmetic
>enhancements.  P.S. the stanza below was autogenerated on mentors.

Thank you Gianfranco :-)


signature.asc
Description: PGP signature

Bug#935211: python-acme: Please port to Python 3 and/or drop Python 2 package

[Gianfranco Costamagna]

control: severity -1 serious

On Tue, 20 Aug 2019 21:27:15 -0400 mo...@debian.org wrote:
> Package: python-acme
> Severity: normal
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Hello, please port python-acme to Python3 and/or drop the python 2
> package. This will help the goal of removing Python 2 from Debian,
> and would also (more immediately) allow to remove packages currently
> dependencies of this one.
> 
> More info at: https://wiki.debian.org/Python/2Removal
since the python3 package is already there, and it has no reverse dependencies,
I'm dropping python-ndg-httpsclient from building, and bumping the severity 
accordingly.

thanks

Gianfranco

Bug#936804: knockpy: Python2 removal in sid/bullseye

[Gianfranco Costamagna]

 control: forwarded -1 https://github.com/guelfoweb/knock/issues/9
I tried some years ago...
G.

Il venerdì 30 agosto 2019, 09:59:30 CEST, Matthias Klose  
ha scritto:  
 
 Package: src:knockpy
Version: 4.1.0-1
Severity: normal
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: py2removal

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

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

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

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

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

  This is the least preferred option.

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

  affects  + src:knockpy

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

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

  

Bug#794466: Virtualbox backport for Stretch?

[Roger Shimizu]

On Fri, Aug 23, 2019 at 5:33 PM Gianfranco Costamagna
 wrote:
>
> I'm not sure backports team will be happy with this...
> and the lack of upstream cooperation is still an issue.

Backports team won't complain if the package is in testing.
And I think release team won't complain now since it's not in freezing stage.

Lack of upstream support usually means we won't have it in stable.
But if user decide to use backports by their own choice, they should
be able to do that.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#935589: cdimage.debian.org: xserver-xorg-input-synaptics package missing in xfce-CD-1 iso

[Sai Karthik]

Oh ! what's the alternative then ?

On September 3, 2019 7:55:29 AM UTC, Julien Cristau  wrote:
>On Mon, Sep  2, 2019 at 23:42:44 +0100, Steve McIntyre wrote:
>
>> control: reassign -1 task-xfce-desktop
>> 
>> Hi Karthik,
>> 
>> On Sat, Aug 24, 2019 at 04:10:53PM +0530, karthik wrote:
>> >Package: cdimage.debian.org
>> >Severity: normal
>> >
>> >Dear Maintainer,
>> >
>> >*** Reporter, please consider answering these questions, where
>appropriate ***
>> >
>> >   * What led up to the situation?
>> >After a fresh install of xfce CD testing weekly iso on lenovo x230
>laptop, I have noticed that the touchpad options were missing in mouse
>& touchpad settings
>> >   * What exactly did you do (or not do) that was effective (or
>> > ineffective)?
>> >installed xserver-xorg-input-synaptics package 
>> >   * What was the outcome of this action?
>> >touchpad options were visible back again!
>> >   * What outcome did you expect instead?
>> >same as above
>> >
>> >Please include this package in upcoming iso builds, It is an
>important one.
>> 
>> If it's important that it's available, then a better place for the
>bug
>> would be against the task-xfce-desktop package. That way it will be
>> pulled in automatically via dependencies for the CD build.
>> 
>The synaptics Xorg driver is obsolete and should not be installed by
>default.
>
>Cheers,
>Julien

-- 
Sent from my Android device with Librem Mail. Please excuse my brevity.

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

[Rob Savoury]

Hi Sven,

Happy to hear that the package is looking good now. Please also note
that in my submission on Sep 1 with the new RFS, I did include a control
field to retitle the bug without the [ITA] in the title, which was only
applicable when it appeared that Christian was unavailable. So the bug
is now actually titled "RFS: vnstat/2.4-0.1 [NMU]" since Sep 1.

Apologies again for any initial confusion with the manner in which I
opened the bug back on Aug 22. It has been a rapid learning curve for me
these past couple of weeks relative to how to make the package correct
for Debian, with a fair few mistakes along the way (mistakes often
giving a great opportunity for further learning, as they have done for
me in this instance).

It looks that a new shared repository has been created on Salsa already
(by Christian I imagine) for the vnStat package [1] and I have already
received an email notifying me that I've been invited as a maintainer
for the package. So I guess it is now up to Christian and I to begin the
coordination of making use of that repository for vnStat.

Thanks,
Rob


[1] https://salsa.debian.org/debian/vnstat


On 09/03/2019 12:18 AM, Sven Hoexter wrote:
> On Sun, Sep 01, 2019 at 09:23:06AM -0700, Rob Savoury wrote:
>> Package: sponsorship-requests
> 
>>   dget -x
>> https://mentors.debian.net/debian/pool/main/v/vnstat/vnstat_2.4-0.1.dsc
> 
> 
> Hey Rob and Christian,
> the package looks good to me. I've uploaded it to delayed-3 in case
> Christian objects the upload. From what I understood he's fine with the
> NMU, but just in case.
> 
> So Christian in case you object to this upload give me a short notice
> and I can cancel it within the next three days.
> 
> Rob the "ITA" tag in the bug is a bit misleading in the sense that if you
> want to adopt someting (ITA - Intent To Adopt), you usually set yourself
> as the package maintainer in debian/control.
> 
> I'm not sure what Christian is up to, but maybe it makes sense to move the
> package to https://salsa.debian.org/debian and have it group maintained.
> But that's up to Christian to decide.
> 
> Sven
> 

Bug#924505: bash: set shell to /bin/sh on removal

[Matthias Klose]

On 02.09.19 21:14, Dmitry Bogatov wrote:

Subject: [PATCH] Change shells of users from /bin/bash to /bin/sh on removal


sorry for joining in lately into this game, but I didn't want to do that in 
parallel with my other Debian tasks.


I don't like the idea of automatic shell rewriting, and will revert it with the 
next regular upload.  For user accounts it potentially creates broken init 
files, because the user's init files might use bashisms. The same might be true 
for system accounts, although you can manually check if these accounts use 
bashisms.  Nobody is hurt by having bash installed, you can avoid that for new 
installations, so this change doesn't seem to have any benefit which out weights 
the regression potential.  There also isn't any precedence for other shells 
doing that.


Matthias

Bug#939026: drop suggests on python-meliae

[Antoine Beaupré]

Control: forward -1
https://github.com/linkchecker/linkchecker/issues/268

On 2019-08-31 10:35:27, Jelmer Vernooij wrote:
> Source: linkchecker
> Severity: normal
>
> Please drop python-meliae from Suggests, as it is being removed from the 
> archive (it's Python 2 only and dead upstream).

Thanks, I've forwarded this to be discussed upstream.

a.

-- 
Be curious. Read widely. Try new things. I think a lot of what people
call intelligence boils down to curiosity.  - Aaron Swartz

Bug#939340: performous-composer: spelling error in long description: Perfomous → Performous

[Jonas Smedegaard]

Package: performous-composer
Version: 2.0+20181009-gitbeeea23-1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Seems there is a typo in long description (a missing "r"):

  Perfomous → Performous

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl1uhDkACgkQLHwxRsGg
ASGheRAApvDJRNASK1IDkFlVf13p8go/xYMNOSO46vtHTjfD5lyWmeWCEiMJHs7Q
2NWfD3mJPiWarpOBnWgh6wy+6QfXHKakqeaBOnmfk4suvrosbxqvq80F1oPAtbB6
Y7uctP5sX9MbBNPfibuX9cNKxUzF2P1Y9RENU8PR6HNzfcDyzedTeAtzJdvKtGAX
qmbocfi2qEAfnVXZFlntEPjeS1sR40AHOB6GWVFfQs1dJx3NJpazEp1LMf/IoMuv
UDKR9d3YT0a9bNL4KmgB1elr3JDJPITiTD5COwDy3/Mee3Xf/smGehDNkSqXJdUG
nQmUhOJ8hUCMlcTXuwOgKXz7Z1LBz2e306kl6uIXTS8puBKokA+q7Av7Ig6n/fAf
LS8w4Gqknjkf71Czd66Zib0JZDIO07ysuE4nYpudew/2NhbOrtQAEz9EKCPc5eT1
8Q2G4FQAKAE/kPYBSanzH1lyMe9ADM6X5dogLvbbUiqfQrgvxyYGh/3JYbEDlSN/
SPqiKgsZ+3zPb+vtuaWwjZg8sVZbHQRqp6VT/R4l9kKUcmiPqvGtyo0hZ80lh+/K
KS6dvERtVBNbeikc2CAjSFBSYUZrq4iD/WFu+wyTiP9rNuI88HHiJGWtcfgo6GQe
RxKoWUbMOWZZ9dVW0bFnHF+w0YCWn6q2GgbN1va9eanhp/DC5yY=
=oKAW
-END PGP SIGNATURE-

Bug#935529: linkchecker: Uses non-standard itemizers and indentation in package description

[Antoine Beaupré]

Control: tags -1 +pending

Fix pushed upstream, will be part of the next Debian package update.

Bug#939339: munin-node: systemd hardening hurts the df plugin

[Ferenc Wágner]

Package: munin-node
Version: 2.0.49-1~bpo9+1
Severity: normal

Dear Maintainer,

Today I noticed that my /home mount is not graphed by the df plugin
against my expectations.  After too much debugging I realized that the
ProtectHome=true setting in /lib/systemd/system/munin-node.service
causes the problem.  After overriding it, the missing graph reappeared.
Please consider dropping this directive from the unit file.
-- 
Thanks,
Feri.

Bug#811180: etckeeper: Please port it to python 3

[Antoine Beaupré]

On 2019-08-29 23:58:20, Daniel Kahn Gillmor wrote:
> On Mon 2016-01-25 18:20:11 +, Jelmer Vernooij wrote:
>
>> The bzr bits have to be python2 because bzr is python 2 only at the moment.
>>
>> Bzr is optional though.
>
> fwiw, i'd much rather see etckeeper shipping with python3 with bzr
> disabled at this point.  or maybe whatever folks need it to work with
> bzr can fix that part?

Agreed. Feel free.

-- 
Si Dieu est, l'homme est esclave ; 
or l'homme peut, doit être libre, donc Dieu n'existe pas.
Et si Dieu existait, il faudrait s'en débarrasser!
- Michel Bakounine

Bug#938088: closed by Gianfranco Costamagna (Bug#938088: fixed in python-pyqtgraph 0.10.0-4)

[Dmitry Shachnev]

Hi,

On Tue, Sep 03, 2019 at 01:44:46PM +, Gianfranco Costamagna wrote:
> [...]
>  python-pyqtgraph (0.10.0-4) unstable; urgency=medium
>  .
>* debian/patches/fd11e1352d9e0b15d67520354bbbf40c615bf996.patch:
>  - update sources to upstream fd11e1352d9e0b15d67520354bbbf40c615bf996
>commit on devel branch (Closes: #935784)
>  - this permits the switch to pyside2
>* Previous upload dropped Python2 package (Closes: #938088)

This is not a proper way to close bugs.

Now the bug metadata is wrong, it has found=0.10.0-3, fixed=0.10.0-4.
But should be fixed=0.10.0-3.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#935329: RFP: git-revise -- handy git tool for doing efficient in-memory commit rebases & fixups

[Antoine Beaupré]

On 2019-09-03 14:12:08, Nicolas Schier wrote:
> Hei,
>
> I have started packaging git-revise [1], would like to take over the
> package maintainance and already got an warm ack from upstream for
> Debian packaging.

Thanks!

> Right now I am just targetting on providing a usable 'git-revise'
> package; for seperating the python library into a seperate package I
> would wait until a corresponding bug is filed.

Sounds good.

> Antoine, could you create a repository in salsa's 'debian' namespace?
> (My salsa account is 'nsc-guest').

Done: https://salsa.debian.org/debian/git-revise

> Would you be available as a sponsor (as soon as I have got rid of all
> lintian issues)?

Sure!

A.

-- 
Vivre tous simplement pour que tous puissent simplement vivre.
- Gandhi

Bug#939048: transition: glibc

[Matthias Klose]

On 31.08.19 16:12, Aurelien Jarno wrote:

  - gcc-9
  - gcc-snapshot


I'll take care of these with regular uploads.

Bug#928993: Uploading new release of sdaps onto Debian unstable

[Boyuan Yang]

Dear sdaps maintainers,

I will proceed to upload the new release of sdaps onto Debian unstable after
the previous upload onto experimental. If there's any issue, please feel free
to let me know.

Thanks,
Boyuan Yang


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

Bug#934132: Unblock elogind 241.3-1+debian1 migration to bullseye

[Michael Biebl]

Am 03.09.19 um 16:29 schrieb Mark Hindley:
> On Wed, Aug 14, 2019 at 07:22:47PM +0100, Jonathan Wiltshire wrote:
>> I think your summary is fine. However, this is not my area of expertise and
>> I'm rather hoping Julien or Ansgar will chime in with an update.
>>
>> It certainly wouldn't be appropriate for me to remove a block put in place
>> by someone else without extenuating circumstances.
> 
> Julien,
> 
> I am still waiting for some constructive engagement over this.
> 
> As Jonathan's comment above makes clear and is echoed by this exchange on
> #debian-release yesterday:
> 
>  Hello. #934132 is still outstanding and is now preventing resolution
>of RC bug in bullseye #939101.  [12:13]
>  Can we find a resolution to #934132? Thanks.  [12:17]
>  weasel: zwiebelbot is missing here  [12:34]
>  jcristau: ^ (#934132)  [13:12]
>  jmw: well i still think shipping this thing is a bad idea.  but i'm
>  ok with somebody else removing the block.  [13:21]
>  I don't know enough about it to make a call on that
>  but I think LeePen would appreciate some sort of response
> 
> it is obvious and completely understandable that other members of the Release
> Team will not overrule your hint blocking elogind migration to bullseye. So,
> resolution of this bug (and the resulting FTBFS in bullseye) is down to you.
> 
> I have tried to answer your concerns in detail. If you think my answers are
> inadequate or still think there are issues that need to be addressed, please
> specify them. If not, please remove your block of elogind's migration to
> testing.
> 
> Thank you.
> 
> Mark
> 

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

This bug report should be taken into account here. Not sure why this is
not marked as RC given that it can pretty much hose your system.
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Bug#939338: /usr/include/gpsim/pic-processor.h references non-existent ../config.h

[Helmut Grohne]

Package: gpsim-dev
Version: 0.31.0-1
Severity: serious
Justification: simulide FTBFS
Tags: ftbfs
Control: affects -1 + src:simulide
File: /usr/include/gpsim/pic-processor.h

simulide fails to build from source. A build on amd64 ends with:

| g++ -c -pipe -g -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -O3 -std=gnu++11 -Wall -W -D_REENTRANT -fPIC 
-DMAINMODULE_EXPORT= -DAPP_VERSION=\"0.1.7\" -DQT_NO_DEBUG -DQT_SVG_LIB 
-DQT_WIDGETS_LIB -DQT_MULTIMEDIA_LIB -DQT_GUI_LIB -DQT_XML_LIB 
-DQT_CONCURRENT_LIB -DQT_SERIALPORT_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -I. 
-I../src -I../src/gui -I../src/gui/circuitwidget 
-I../src/gui/circuitwidget/components -I../src/gui/circuitwidget/components/mcu 
-I../src/gui/oscopewidget -I../src/gui/plotterwidget 
-I../src/gui/terminalwidget -I../src/gui/QPropertyEditor 
-I../src/gui/componentselector -I../src/gui/filebrowser 
-I../src/gui/editorwidget -I../src/gui/editorwidget/findreplacedialog 
-I../src/gui/serialporwidget -I../src/simulator -I../src/simulator/elements 
-I../src/simulator/elements/processors -I../src/misc -I../src/simavr 
-I../src/simavr/sim -I../src/simavr/sim/avr -I../src/simavr/cores -isystem 
/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -isystem 
/usr/include/x86_64-linux-gnu/qt5 -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtSvg -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtWidgets -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtMultimedia -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtGui -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtXml -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtConcurrent -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtSerialPort -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtNetwork -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtCore -I. -isystem /usr/include/libdrm 
-I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -o itemlibrary.o 
../src/gui/circuitwidget/itemlibrary.cpp
| In file included from /usr/include/gpsim/pic-processor.h:30,
|  from ../src/simulator/elements/processors/picprocessor.h:26,
|  from 
../src/gui/circuitwidget/components/mcu/piccomponent.h:24,
|  from ../src/gui/circuitwidget/itemlibrary.cpp:62:
| /usr/include/gpsim/breakpoints.h:25:10: fatal error: ../config.h: No such 
file or directory
|25 | #include "../config.h"
|   |  ^
| compilation terminated.
| make[1]: *** [Makefile:3380: itemlibrary.o] Error 1
| make[1]: Leaving directory '/<>/build_XX'
| dh_auto_build: cd build_XX && make -j1 returned exit code 2
| make: *** [debian/rules:17: build] Error 255
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

The file /usr/include/gpsim/pic-processor.h from the gpsim-dev package
references ../config.h, which does not exist. Including
 is bound to fail.

Helmut

Bug#896891: (no subject)

[Thomas Ward]

Hello.

Can you verify that cross-building is still broken in the version 
available now in Unstable and Testing, as 1.4.1-1 has been superseded 
for some time now?  If it is still broken, please also update the patch, 
however keep in mind configure.ac has changed so it's possible the issue 
is now resolved.



Thomas

Bug#939329: named crashes when setting nsec3param

[Matt Corallo]

Yep, no problem. I moved it out of the way to keep it around, will try
to avoid upgrading bind and losing the original deb to run backtraces
against.


On 9/3/19 2:10 PM, Ondřej Surý wrote:
> Thanks Matt, could you please save the core in case we (ISC) are going to 
> need more information from it?
> 
> Ondrej
> --
> Ondřej Surý
> ond...@sury.org
> 
> 
> 
>> On 3 Sep 2019, at 16:05, Matt Corallo  wrote:
>>
>> Core dump trace follows:
>>
>> [New LWP 29244]
>> [New LWP 29241]
>> [New LWP 29245]
>> [New LWP 29243]
>> [New LWP 29242]
>> [New LWP 29246]
>> [New LWP 29247]
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
>> Core was generated by `/usr/sbin/named -u bind'.
>> Program terminated with signal SIGABRT, Aborted.
>> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
>> 50   ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
>> [Current thread is 1 (Thread 0xafda91a0 (LWP 29244))]
>> (gdb) thread apply all bt
>>
>> Thread 7 (Thread 0xae5a61a0 (LWP 29247)):
>> #0  0xb2ffbc00 in __GI_epoll_pwait (epfd=,
>> events=events@entry=0xb0db6010, maxevents=maxevents@entry=64,
>>timeout=timeout@entry=-1, set=set@entry=0x0) at
>> ../sysdeps/unix/sysv/linux/epoll_pwait.c:42
>> #1  0xb2ffbd40 in epoll_wait (epfd=,
>> events=events@entry=0xb0db6010, maxevents=maxevents@entry=64,
>>timeout=timeout@entry=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:32
>> #2  0xb3471a9c in watcher (uap=0xb0db5010) at
>> ../../../../lib/isc/unix/socket.c:4260
>> #3  0xb335b7e4 in start_thread (arg=0xd7e8b09f) at
>> pthread_create.c:486
>> #4  0xb2ffbadc in thread_start () at
>> ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
>>
>> Thread 6 (Thread 0xaeda71a0 (LWP 29246)):
>> #0  futex_abstimed_wait_cancelable (private=0, abstime=0xaeda6858,
>> expected=0, futex_word=0xb0db30a8)
>>at ../sysdeps/unix/sysv/linux/futex-internal.h:205
>> #1  __pthread_cond_wait_common (abstime=,
>> mutex=, cond=) at pthread_cond_wait.c:539
>> #2  __pthread_cond_timedwait (cond=cond@entry=0xb0db3080,
>> mutex=mutex@entry=0xb0db3028, abstime=abstime@entry=0xaeda6858)
>>at pthread_cond_wait.c:667
>> #3  0xb347bc54 in isc_condition_waituntil
>> (c=c@entry=0xb0db3080, m=m@entry=0xb0db3028,
>> t=t@entry=0xb0db3074)
>>at ../../../../lib/isc/pthreads/condition.c:59
>> #4  0xb3463f44 in run (uap=0xb0db3010) at
>> ../../../lib/isc/timer.c:806
>> #5  0xb335b7e4 in start_thread (arg=0xd7e8b14f) at
>> pthread_create.c:486
>> #6  0xb2ffbadc in thread_start () at
>> ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
>>
>> Thread 5 (Thread 0xb0dab1a0 (LWP 29242)):
>> #0  0xb36553c0 in ?? () from /lib/aarch64-linux-gnu/libcrypto.so.1.1
>> #1  0xb0da6d30 in ?? ()
>> #2  0x94603695287e7065 in ?? ()
>> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>>
>> Thread 4 (Thread 0xb05aa1a0 (LWP 29243)):
>> #0  futex_wait_cancelable (private=0, expected=0,
>> futex_word=0xb0db10d0) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
>> #1  __pthread_cond_wait_common (abstime=0x0, mutex=0xb0db1028,
>> cond=0xb0db10a8) at pthread_cond_wait.c:502
>> #2  __pthread_cond_wait (cond=cond@entry=0xb0db10a8,
>> mutex=mutex@entry=0xb0db1028) at pthread_cond_wait.c:655
>> #3  0xb345dae4 in dispatch (manager=0xb0db1010) at
>> ../../../lib/isc/task.c:1089
>> #4  run (uap=0xb0db1010) at ../../../lib/isc/task.c:1315
>> #5  0xb335b7e4 in start_thread (arg=0xd7e8b10f) at
>> pthread_create.c:486
>> #6  0xb2ffbadc in thread_start () at
>> ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
>>
>> Thread 3 (Thread 0xaf5a81a0 (LWP 29245)):
>> #0  futex_wait_cancelable (private=0, expected=0,
>> futex_word=0xb0db10d0) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
>> #1  __pthread_cond_wait_common (abstime=0x0, mutex=0xb0db1028,
>> cond=0xb0db10a8) at pthread_cond_wait.c:502
>> #2  __pthread_cond_wait (cond=cond@entry=0xb0db10a8,
>> mutex=mutex@entry=0xb0db1028) at pthread_cond_wait.c:655
>> #3  0xb345dae4 in dispatch (manager=0xb0db1010) at
>> ../../../lib/isc/task.c:1089
>> #4  run (uap=0xb0db1010) at ../../../lib/isc/task.c:1315
>> #5  0xb335b7e4 in start_thread (arg=0xd7e8b10f) at
>> pthread_create.c:486
>> #6  0xb2ffbadc in thread_start () at
>> ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
>>
>> Thread 2 (Thread 0xb0e12440 (LWP 29241)):
>> #0  0xb2f5ea9c in __GI___sigsuspend
>> (set=set@entry=0xd7e8b158) at ../sysdeps/unix/sysv/linux/sigsuspend.c:26
>> #1  0xb34671dc in isc__app_ctxrun
>> (ctx0=ctx0@entry=0xb34ad6f0 ) at
>> ../../../../lib/isc/unix/app.c:725
>> #2  0xb346746c in isc__app_run () at
>> ../../../../lib/isc/unix/app.c:758
>> #3  0x

Bug#926731: ITS: urlscan/0.9.2 - extract and browse email URLs

[Boruch Baum]

On 2019-08-31 19:20, Marcin Kulisz wrote:
> Package: urlscan
> Version: 0.8.2-1
> Followup-For: Bug #926731
>
> Boruch are you still interested in maintaining this package?
> If not I my intent is to salvage/adopt it in the next couple of weeks, so 
> please
> let me know asap if you're planning to do it.

Answered here (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926731)
on 21 August.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Bug#934132: Unblock elogind 241.3-1+debian1 migration to bullseye

[Mark Hindley]

On Wed, Aug 14, 2019 at 07:22:47PM +0100, Jonathan Wiltshire wrote:
> I think your summary is fine. However, this is not my area of expertise and
> I'm rather hoping Julien or Ansgar will chime in with an update.
> 
> It certainly wouldn't be appropriate for me to remove a block put in place
> by someone else without extenuating circumstances.

Julien,

I am still waiting for some constructive engagement over this.

As Jonathan's comment above makes clear and is echoed by this exchange on
#debian-release yesterday:

 Hello. #934132 is still outstanding and is now preventing resolution
 of RC bug in bullseye #939101.  [12:13]
 Can we find a resolution to #934132? Thanks.  [12:17]
 weasel: zwiebelbot is missing here  [12:34]
 jcristau: ^ (#934132)  [13:12]
 jmw: well i still think shipping this thing is a bad idea.  but i'm
   ok with somebody else removing the block.  [13:21]
 I don't know enough about it to make a call on that
 but I think LeePen would appreciate some sort of response

it is obvious and completely understandable that other members of the Release
Team will not overrule your hint blocking elogind migration to bullseye. So,
resolution of this bug (and the resulting FTBFS in bullseye) is down to you.

I have tried to answer your concerns in detail. If you think my answers are
inadequate or still think there are issues that need to be addressed, please
specify them. If not, please remove your block of elogind's migration to
testing.

Thank you.

Mark

Bug#935900: RFS: z3 4.8.4-0.1 [NMU]

[Gianfranco Costamagna]

 control: owner -1 !control: tags -1 moreinfo
Hello Fabian, 

I tried many times to update it, would you mind pushing your work directly on 
the pkg-llvm repository?
In the meanwhile I'm having a look at your work
Gianfranco
Il martedì 27 agosto 2019, 19:39:28 CEST, Matthew Fernandez 
 ha scritto:  
 
 

On Aug 27, 2019, at 08:48, Fabian Wolff  wrote:
On 8/27/19 4:00 PM, Matthew Fernandez wrote:


z3 (4.8.4-0.1) unstable; urgency=medium


I am not a z3 dev, but the latest z3 release is 4.8.5. Is there a
particular motivation for uploading a 4.8.4-based release?


Thanks for pointing this out; I did not notice this, because I was
using uscan, and upstream suddenly changed the tag format on Github for
tagging new releases:

  https://github.com/Z3Prover/z3/tags


Ah, I was not aware of this either, so we both learned something :)

In the last hour or so, I have tried to import version 4.8.5, but they
apparently changed something in the build system so that building with
Mono no longer works (it fails with 'dotnet: Command not found', and I
don't know what the Mono equivalent of the dotnet command is, or if one
exists at all).


I’ve built 4.8.5 before, but not the .net bindings which I guess is what you’re 
dealing with. I can attempt this but unfortunately won’t have time in the short 
term.

So, I'd say having version 4.8.4 is still better than 4.4.1, and if
someone else wants to give 4.8.5 another try in the future, they can do
so after this upload.


Agreed. Having 4.8.4 available would be a significant improvement. Thanks!  

Bug#936698: hfst: Python2 removal in sid/bullseye

[Tino Didriksen]

I've pushed an update that also fixes #936698 to
https://salsa.debian.org/science-team/hfst

-- Tino Didriksen

Bug#939329: named crashes when setting nsec3param

[Ondřej Surý]

Thanks Matt, could you please save the core in case we (ISC) are going to need 
more information from it?

Ondrej
--
Ondřej Surý
ond...@sury.org



> On 3 Sep 2019, at 16:05, Matt Corallo  wrote:
> 
> Core dump trace follows:
> 
> [New LWP 29244]
> [New LWP 29241]
> [New LWP 29245]
> [New LWP 29243]
> [New LWP 29242]
> [New LWP 29246]
> [New LWP 29247]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
> Core was generated by `/usr/sbin/named -u bind'.
> Program terminated with signal SIGABRT, Aborted.
> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> 50../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> [Current thread is 1 (Thread 0xafda91a0 (LWP 29244))]
> (gdb) thread apply all bt
> 
> Thread 7 (Thread 0xae5a61a0 (LWP 29247)):
> #0  0xb2ffbc00 in __GI_epoll_pwait (epfd=,
> events=events@entry=0xb0db6010, maxevents=maxevents@entry=64,
>timeout=timeout@entry=-1, set=set@entry=0x0) at
> ../sysdeps/unix/sysv/linux/epoll_pwait.c:42
> #1  0xb2ffbd40 in epoll_wait (epfd=,
> events=events@entry=0xb0db6010, maxevents=maxevents@entry=64,
>timeout=timeout@entry=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:32
> #2  0xb3471a9c in watcher (uap=0xb0db5010) at
> ../../../../lib/isc/unix/socket.c:4260
> #3  0xb335b7e4 in start_thread (arg=0xd7e8b09f) at
> pthread_create.c:486
> #4  0xb2ffbadc in thread_start () at
> ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
> 
> Thread 6 (Thread 0xaeda71a0 (LWP 29246)):
> #0  futex_abstimed_wait_cancelable (private=0, abstime=0xaeda6858,
> expected=0, futex_word=0xb0db30a8)
>at ../sysdeps/unix/sysv/linux/futex-internal.h:205
> #1  __pthread_cond_wait_common (abstime=,
> mutex=, cond=) at pthread_cond_wait.c:539
> #2  __pthread_cond_timedwait (cond=cond@entry=0xb0db3080,
> mutex=mutex@entry=0xb0db3028, abstime=abstime@entry=0xaeda6858)
>at pthread_cond_wait.c:667
> #3  0xb347bc54 in isc_condition_waituntil
> (c=c@entry=0xb0db3080, m=m@entry=0xb0db3028,
> t=t@entry=0xb0db3074)
>at ../../../../lib/isc/pthreads/condition.c:59
> #4  0xb3463f44 in run (uap=0xb0db3010) at
> ../../../lib/isc/timer.c:806
> #5  0xb335b7e4 in start_thread (arg=0xd7e8b14f) at
> pthread_create.c:486
> #6  0xb2ffbadc in thread_start () at
> ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
> 
> Thread 5 (Thread 0xb0dab1a0 (LWP 29242)):
> #0  0xb36553c0 in ?? () from /lib/aarch64-linux-gnu/libcrypto.so.1.1
> #1  0xb0da6d30 in ?? ()
> #2  0x94603695287e7065 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> 
> Thread 4 (Thread 0xb05aa1a0 (LWP 29243)):
> #0  futex_wait_cancelable (private=0, expected=0,
> futex_word=0xb0db10d0) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
> #1  __pthread_cond_wait_common (abstime=0x0, mutex=0xb0db1028,
> cond=0xb0db10a8) at pthread_cond_wait.c:502
> #2  __pthread_cond_wait (cond=cond@entry=0xb0db10a8,
> mutex=mutex@entry=0xb0db1028) at pthread_cond_wait.c:655
> #3  0xb345dae4 in dispatch (manager=0xb0db1010) at
> ../../../lib/isc/task.c:1089
> #4  run (uap=0xb0db1010) at ../../../lib/isc/task.c:1315
> #5  0xb335b7e4 in start_thread (arg=0xd7e8b10f) at
> pthread_create.c:486
> #6  0xb2ffbadc in thread_start () at
> ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
> 
> Thread 3 (Thread 0xaf5a81a0 (LWP 29245)):
> #0  futex_wait_cancelable (private=0, expected=0,
> futex_word=0xb0db10d0) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
> #1  __pthread_cond_wait_common (abstime=0x0, mutex=0xb0db1028,
> cond=0xb0db10a8) at pthread_cond_wait.c:502
> #2  __pthread_cond_wait (cond=cond@entry=0xb0db10a8,
> mutex=mutex@entry=0xb0db1028) at pthread_cond_wait.c:655
> #3  0xb345dae4 in dispatch (manager=0xb0db1010) at
> ../../../lib/isc/task.c:1089
> #4  run (uap=0xb0db1010) at ../../../lib/isc/task.c:1315
> #5  0xb335b7e4 in start_thread (arg=0xd7e8b10f) at
> pthread_create.c:486
> #6  0xb2ffbadc in thread_start () at
> ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
> 
> Thread 2 (Thread 0xb0e12440 (LWP 29241)):
> #0  0xb2f5ea9c in __GI___sigsuspend
> (set=set@entry=0xd7e8b158) at ../sysdeps/unix/sysv/linux/sigsuspend.c:26
> #1  0xb34671dc in isc__app_ctxrun
> (ctx0=ctx0@entry=0xb34ad6f0 ) at
> ../../../../lib/isc/unix/app.c:725
> #2  0xb346746c in isc__app_run () at
> ../../../../lib/isc/unix/app.c:758
> #3  0xb3467e00 in isc_app_run () at
> ../../../../lib/isc/unix/../app_api.c:201
> #4  0xdda0c0c4 in main (argc=, argv= out>) at ../../../bin/named/main.c:1480
> 
> Thread 1 (Thread 0xafda91a0 (LWP 29244)):
> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> #1  0x0

Bug#939329: named crashes when setting nsec3param

[Matt Corallo]

Core dump trace follows:

[New LWP 29244]
[New LWP 29241]
[New LWP 29245]
[New LWP 29243]
[New LWP 29242]
[New LWP 29246]
[New LWP 29247]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/named -u bind'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
[Current thread is 1 (Thread 0xafda91a0 (LWP 29244))]
(gdb) thread apply all bt

Thread 7 (Thread 0xae5a61a0 (LWP 29247)):
#0  0xb2ffbc00 in __GI_epoll_pwait (epfd=,
events=events@entry=0xb0db6010, maxevents=maxevents@entry=64,
timeout=timeout@entry=-1, set=set@entry=0x0) at
../sysdeps/unix/sysv/linux/epoll_pwait.c:42
#1  0xb2ffbd40 in epoll_wait (epfd=,
events=events@entry=0xb0db6010, maxevents=maxevents@entry=64,
timeout=timeout@entry=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:32
#2  0xb3471a9c in watcher (uap=0xb0db5010) at
../../../../lib/isc/unix/socket.c:4260
#3  0xb335b7e4 in start_thread (arg=0xd7e8b09f) at
pthread_create.c:486
#4  0xb2ffbadc in thread_start () at
../sysdeps/unix/sysv/linux/aarch64/clone.S:78

Thread 6 (Thread 0xaeda71a0 (LWP 29246)):
#0  futex_abstimed_wait_cancelable (private=0, abstime=0xaeda6858,
expected=0, futex_word=0xb0db30a8)
at ../sysdeps/unix/sysv/linux/futex-internal.h:205
#1  __pthread_cond_wait_common (abstime=,
mutex=, cond=) at pthread_cond_wait.c:539
#2  __pthread_cond_timedwait (cond=cond@entry=0xb0db3080,
mutex=mutex@entry=0xb0db3028, abstime=abstime@entry=0xaeda6858)
at pthread_cond_wait.c:667
#3  0xb347bc54 in isc_condition_waituntil
(c=c@entry=0xb0db3080, m=m@entry=0xb0db3028,
t=t@entry=0xb0db3074)
at ../../../../lib/isc/pthreads/condition.c:59
#4  0xb3463f44 in run (uap=0xb0db3010) at
../../../lib/isc/timer.c:806
#5  0xb335b7e4 in start_thread (arg=0xd7e8b14f) at
pthread_create.c:486
#6  0xb2ffbadc in thread_start () at
../sysdeps/unix/sysv/linux/aarch64/clone.S:78

Thread 5 (Thread 0xb0dab1a0 (LWP 29242)):
#0  0xb36553c0 in ?? () from /lib/aarch64-linux-gnu/libcrypto.so.1.1
#1  0xb0da6d30 in ?? ()
#2  0x94603695287e7065 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 4 (Thread 0xb05aa1a0 (LWP 29243)):
#0  futex_wait_cancelable (private=0, expected=0,
futex_word=0xb0db10d0) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0xb0db1028,
cond=0xb0db10a8) at pthread_cond_wait.c:502
#2  __pthread_cond_wait (cond=cond@entry=0xb0db10a8,
mutex=mutex@entry=0xb0db1028) at pthread_cond_wait.c:655
#3  0xb345dae4 in dispatch (manager=0xb0db1010) at
../../../lib/isc/task.c:1089
#4  run (uap=0xb0db1010) at ../../../lib/isc/task.c:1315
#5  0xb335b7e4 in start_thread (arg=0xd7e8b10f) at
pthread_create.c:486
#6  0xb2ffbadc in thread_start () at
../sysdeps/unix/sysv/linux/aarch64/clone.S:78

Thread 3 (Thread 0xaf5a81a0 (LWP 29245)):
#0  futex_wait_cancelable (private=0, expected=0,
futex_word=0xb0db10d0) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0xb0db1028,
cond=0xb0db10a8) at pthread_cond_wait.c:502
#2  __pthread_cond_wait (cond=cond@entry=0xb0db10a8,
mutex=mutex@entry=0xb0db1028) at pthread_cond_wait.c:655
#3  0xb345dae4 in dispatch (manager=0xb0db1010) at
../../../lib/isc/task.c:1089
#4  run (uap=0xb0db1010) at ../../../lib/isc/task.c:1315
#5  0xb335b7e4 in start_thread (arg=0xd7e8b10f) at
pthread_create.c:486
#6  0xb2ffbadc in thread_start () at
../sysdeps/unix/sysv/linux/aarch64/clone.S:78

Thread 2 (Thread 0xb0e12440 (LWP 29241)):
#0  0xb2f5ea9c in __GI___sigsuspend
(set=set@entry=0xd7e8b158) at ../sysdeps/unix/sysv/linux/sigsuspend.c:26
#1  0xb34671dc in isc__app_ctxrun
(ctx0=ctx0@entry=0xb34ad6f0 ) at
../../../../lib/isc/unix/app.c:725
#2  0xb346746c in isc__app_run () at
../../../../lib/isc/unix/app.c:758
#3  0xb3467e00 in isc_app_run () at
../../../../lib/isc/unix/../app_api.c:201
#4  0xdda0c0c4 in main (argc=, argv=) at ../../../bin/named/main.c:1480

Thread 1 (Thread 0xafda91a0 (LWP 29244)):
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0xb2f4c8e8 in __GI_abort () at abort.c:79
#2  0xdda1fb58 in assertion_failed (file=,
line=, type=,
cond=0xb3b1e398 "rbtdb->future_version == ((void *)0)") at
../../../bin/named/main.c:234
#3  0xb3437944 in isc_assertion_failed
(file=file@entry=0xb3b1da10 "../../../lib/dns/rbtdb.c",
line=line@entry=1494,
type=type@entry=isc_assertiontype_require,
cond=cond@entry=0xff

Bug#939336: iptables: fails to delete rules when running 32-bit userspace on 64-bit kernel

[Colin Watson]

On Tue, Sep 03, 2019 at 03:33:51PM +0200, Fabio Pedretti wrote:
> I think this is fixed in iptables git:
> https://git.netfilter.org/iptables/commit/?id=64e88114437072b29bed8aae9eb04ed5e773708f

That seems to relate to a different structure?

> BTW, iptables git has many fixes for Debian reported bugs (mostly since 
> buster).

I just tested iptables git (commit
a0f1a756419d0738c833d53b656350a520fc94c8) and reproduced the same
symptoms as in my original report.

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

Bug#939337: memcached: CVE-2019-15026

[Salvatore Bonaccorso]

Source: memcached
Version: 1.5.6-1.1
Severity: important
Tags: security upstream
Control: found -1 1.4.33-1+deb9u1
Control: found -1 1.4.33-1

Hi,

The following vulnerability was published for memcached.

CVE-2019-15026[0]:
| memcached 1.5.16, when UNIX sockets are used, has a stack-based buffer
| over-read in conn_to_str in memcached.c.


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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#939336: iptables: fails to delete rules when running 32-bit userspace on 64-bit kernel

[Fabio Pedretti]

I think this is fixed in iptables git:
https://git.netfilter.org/iptables/commit/?id=64e88114437072b29bed8aae9eb04ed5e773708f

BTW, iptables git has many fixes for Debian reported bugs (mostly since buster).

Il giorno mar 3 set 2019 alle ore 15:30 Colin Watson
 ha scritto:
>
> Package: iptables
> Version: 1.8.3-2
> Severity: normal
>
> When running an i386 container on an amd64 host system, "iptables -D"
> fails to match existing rules correctly:
>
>   # iptables -A OUTPUT -p tcp --dport 80 -j DROP
>   # iptables -D OUTPUT -p tcp --dport 80 -j DROP
>   iptables: Bad rule (does a matching rule exist in that chain?).
>
> Some gdb work revealed that this is because match_size is wrong: it's
> based on alignof(struct xt_align), and when adding a new rule the
> kernel's netfilter compat interfaces adjust match_size to account for
> the difference between userspace and kernel alignment, but this means
> that the size isn't what userspace expects when it tries to match
> existing rules.
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: i386 (i686)
>
> Kernel: Linux 5.2.0-10-generic (SMP w/1 CPU core)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages iptables depends on:
> ii  libc62.28-10
> ii  libip4tc21.8.3-2
> ii  libip6tc21.8.3-2
> ii  libiptc0 1.8.3-2
> ii  libmnl0  1.0.4-2+b1
> ii  libnetfilter-conntrack3  1.0.7-2
> ii  libnfnetlink01.0.1-3+b1
> ii  libnftnl11   1.1.4-1
> ii  libxtables12 1.8.3-2
>
> Versions of packages iptables recommends:
> ii  nftables  0.9.2-1
>
> Versions of packages iptables suggests:
> pn  kmod  
>
> -- no debconf information
>
> --
> Colin Watson   [cjwat...@debian.org]
>