Bug#917141: isc-dhcp-client: error in syslog: nslcd: request denied by validnames option

[greg]

Package: isc-dhcp-client
Version: 4.3.5-3+deb9u1
Severity: minor

dhclient seems to request a username from nslcd with a wildcard "*".
This is denied by nslcd.

Every time dhclient is runs, the following is in syslog:

Dec 23 07:48:50 dhclient[1183]: DHCPREQUEST of 81.16.33.27 on eth0 to 
81.16.33.2 port 67
Dec 23 07:48:50 dhclient[1183]: DHCPACK of 81.16.33.27 from 81.16.33.2
Dec 23 07:48:50 nslcd[21573]: [885e1b] DEBUG: connection from pid=504 uid=0 
gid=0
Dec 23 07:48:50 nslcd[21573]: [885e1b]  request denied by 
validnames option
Dec 23 07:48:50 dhclient[1183]: bound to 81.16.33.27 -- renewal in 1234 seconds.


-- System Information:
Debian Release: 9.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: armhf (armv7l)

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

Versions of packages isc-dhcp-client depends on:
ii  debianutils   4.8.1.1
ii  iproute2  4.9.0-1+deb9u1
ii  libc6 2.24-11+deb9u3
ii  libdns-export162  1:9.10.3.dfsg.P4-12.3+deb9u4
ii  libisc-export160  1:9.10.3.dfsg.P4-12.3+deb9u4

Versions of packages isc-dhcp-client recommends:
ii  isc-dhcp-common  4.3.5-3+deb9u1

Versions of packages isc-dhcp-client suggests:
pn  avahi-autoipd 
pn  isc-dhcp-client-ddns  
ii  resolvconf1.79

-- no debconf information

Bug#917140: cyrus-sasl2: NMU changes dropped?

[Ryan Tandy]

Source: cyrus-sasl2
Version: 2.1.27~rc8-1
Severity: normal

Dear Maintainer,

It looks like NMU changelogs (and possibly the associated changes) from 
-3 and -3.1 may have been dropped in the last upload. The BTS version 
tracking also now thinks the associated bugs are not fixed in unstable, 
e.g. #819893 now shows as fixed in stable and not fixed in unstable.

debdiff cyrus-sasl2_2.1.27~101-g0780600+dfsg-3.1.dsc 
cyrus-sasl2_2.1.27~rc8-1.dsc | filterdiff -i '*/debian/changelog'

diff -Nru cyrus-sasl2-2.1.27~101-g0780600+dfsg/debian/changelog 
cyrus-sasl2-2.1.27~rc8/debian/changelog
--- cyrus-sasl2-2.1.27~101-g0780600+dfsg/debian/changelog   2018-04-21 
09:20:16.0 -0700
+++ cyrus-sasl2-2.1.27~rc8/debian/changelog 2018-10-02 01:05:10.0 
-0700
@@ -1,21 +1,17 @@
-cyrus-sasl2 (2.1.27~101-g0780600+dfsg-3.1) unstable; urgency=medium
+cyrus-sasl2 (2.1.27~rc8-1) unstable; urgency=medium

-  * Non-maintainer upload with maintainer permission.
-  * Add support for build-profiles. (Closes: #894297)
+  * New upstream version 2.1.27~rc8
+  * Rebase patches for Cyrus SASL 2.1.27~rc8
+  * Cleanup d/control

- -- Karsten Merker   Sat, 21 Apr 2018 18:20:16 +0200
+ -- Ondřej Surý   Tue, 02 Oct 2018 08:05:10 +

-cyrus-sasl2 (2.1.27~101-g0780600+dfsg-3) unstable; urgency=medium
+cyrus-sasl2 (2.1.27~rc4-1) unstable; urgency=medium

-  [ Holger Levsen ]
-  * NMU to help with #856847.
+  * New upstream version 2.1.27~rc4
+  * Refresh patches for 2.4.27~rc4 release

-  [ Andreas Beckmann ]
-  * libsasl2-modules.postinst: Remove executable permissions from
-/etc/logcheck/ignore.d.server/libsasl2-modules on upgrades from jessie.
-(Closes: #819893)
-
- -- Holger Levsen   Sun, 19 Mar 2017 12:30:33 +
+ -- Ondřej Surý   Tue, 19 Sep 2017 09:53:57 +0200

 cyrus-sasl2 (2.1.27~101-g0780600+dfsg-2) unstable; urgency=medium

Bug#917139: Do not ignore unmounting of "/run/mount" and "/run/media" in "/etc/init.d/umountfs"

[Gong S.]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Package: initscripts
Version: 2.93-1

In "/etc/init.d/umountfs" line 28, everything under "/run/*" is not unmounted 
when shutting down or rebooting the system, and this includes "/run/mount" and 
"/run/media".
Also it is not uncommon to symlink "/media" and "/mnt" to said locations as it 
does not leave automatically created folders after a reboot.
So if you mount disks as a normal user using "pmount" or "udisks", they are not 
unmounted, resulting in data loss.
I suggest you that you should only ignore "/run/lock" and "/run/shm" (if exist, 
as specified in "/etc/default/tmpfs").
--
"And in the naked light, I saw ten thousand people, maybe m\
ore. People talking without speaking, people hearing withou\
t listening. People writing songs that voices never shared,\
no one dared disturb the sound of silence."
-BEGIN PGP SIGNATURE-
Version: ProtonMail
Comment: https://protonmail.com

wsBcBAEBCAAGBQJcHzqrAAoJENi1YDlFXXQfdgcH/01UoNuzuAwlVfPYq8Jc
qrhT0cKZQBd+jJhFwRkDRBBP35ks/UG6wrkHiqDdk/qUF0GJfpBeYlm6P8lx
n1Xxsh9KnhJ5b5X/ojsL6dzOvd5BYgXpaTeryd5sX/OOkUCTDM55M+wWQY/6
N22T9w1icOdQJD5O0GulxiT1ljPWVnQj41wlue+Oa9d6mp7tfmqgj8+bZoyQ
NxkflalH0QulY+Sq+LUE3KS/6PQD3CwHCDNYQXyZ1UZDJ78b/vOotF14j/3E
AIhSHKBMUm5SGEgbVQtpD17X6TDQMOPXzq7iAa5L8HHkshN2X9CbQvVpMlVS
O5y3gGCs51o7RqiyUKXi/kY=
=Tk6/
-END PGP SIGNATURE-



publickey - pthfdr@protonmail.ch - 0xAB77ABA4.asc
Description: application/pgp-keys


publickey - pthfdr@protonmail.ch - 0xAB77ABA4.asc.sig
Description: PGP signature

Bug#912091: closed by Jonas Smedegaard (Bug#912091: fixed in netatalk 2.2.6-2)

[Helmut Grohne]

Control: reopen -1

On Sat, Dec 22, 2018 at 06:39:19PM +, Debian Bug Tracking System wrote:
>* Add patch 106
>  to fix detect Berkeley DB installed in multiarch location.
>  Closes: Bug#912091. Thanks to Helmut Grohne.

Patching the source does not help when you don't build from source. To
fix the bug, you either must build from source (preferred) or patch the
generated artifacts.

Helmut

Bug#914955: Uploading soon test-kitchen and ruby-mixlib-install

[Hleb Valoshka]

On 12/23/18, Mathieu Parent  wrote:

> Ok. Will take it over. Should I take mixlib-install too?

Yes, please.

Bug#917138: nagios4: CVE-2018-18245

[Salvatore Bonaccorso]

Source: nagios4
Version: 4.3.4-2
Severity: important
Tags: patch security upstream

Hi,

The following vulnerability was published for nagios4.

CVE-2018-18245[0]:
| Nagios Core 4.4.2 has XSS via the alert summary reports of plugin
| results, as demonstrated by a SCRIPT element delivered by a modified
| check_load plugin to NRPE.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-18245
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18245
[1] 
https://github.com/NagiosEnterprises/nagioscore/commit/0329033db9a1d0954c304f209ea88824e8f78b8a

Regards,
Salvatore

Bug#917136: (no subject)

[Alexey A Nikitin]

This bug is related to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917124

My layout is as follows:

sda8:00 465.8G  0 disk
├─sda1 8:1040M  0 part  /boot/efi
├─sda2 8:20   128G  0 part
│ ├─helios-crypt 254:00   112G  0 lvm
│ │ └─crypt  254:10   112G  0 crypt
│ │   ├─crypthelios-debian   254:20 8G  0 lvm   /
│ │   ├─crypthelios-srv  254:30 8M  0 lvm   /srv
│ │   ├─crypthelios-usrlocal 254:4056M  0 lvm   /usr/local
│ │   ├─crypthelios-opt  254:50   1.3G  0 lvm   /opt
│ │   ├─crypthelios-home 254:6096G  0 lvm   /home
│ │   └─crypthelios-var  254:70   3.5G  0 lvm   /var
│ └─helios-boot  254:80   192M  0 lvm   /boot
└─sda3 8:30 2G  0 part

When system was dropping into rescue shell only /, /boot, and /boot/efi were 
mounted. lvscan was showing all of the volumes as active, yet none were showing 
up either in expected /dev/crypthelios/, or under /dev/mapper/ (except for 
helios-boot or helios-crypt, don't remember with certainty which one). I could 
get device files to show up by running 'vgscan --mknodes', but I couldn't 
actually mount them, neither through symlinks nor through actual /dev/dm-# 
files. Again, the only thing that got me going was downgrading udev from 240-1 
to 239-15.

-- 
This message was created with 100% recycled electrons


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

Bug#917137: sphinxsearch FTCBFS: mysql_config does not work

[Helmut Grohne]

Source: sphinxsearch
Version: 2.2.11-2
Severity: normal
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap
Control: block -1 by 917135

sphinxsearch fails to cross build from source, because it fails
detecting mysql using mysql_config. During cross compilation,
mysql_config does not work at all. For that reason, it should not be
used at all. The attached patch looks up mysql using pkg-config, which
presently is the standard tools for discovering compiler and linker
flags. It makes sphinxsearch cross buildable. Please be aware:
 * In order to use PKG_CHECK_MODULES, it must not occur in a shell
   if/else branch. Such branches must be expressed using AS_IF to make
   the use of AC_REQUIRE work.
 * mariadb presently lacks a dependency on libssl-dev, but it emits
   -lssl as linker flag, see #917135.
 * In order to use the patch, you need to add pkg-config to
   Build-Depends.
I tried writing the patch in a way that is upstreamable as it is useful
to other distributions (e.g. yocto).

Helmut
--- sphinxsearch-2.2.11.orig/acinclude.m4
+++ sphinxsearch-2.2.11/acinclude.m4
@@ -9,10 +9,10 @@
 mysqlconfig_locations="mysql_config /usr/bin/mysql_config /usr/local/bin/mysql_config /usr/local/mysql/bin/mysql_config /opt/mysql/bin/mysql_config /usr/pkg/bin/mysql_config"
 user_mysql_includes=
 user_mysql_libs=
+mysqlconfig_used=
 
 # check explicit MySQL root for mysql_config, include, lib
-if test [ x$1 != xyes -a x$1 != xno ]
-then
+AS_IF([test x$1 != xyes -a x$1 != xno],[
 	mysqlroot=`echo $1 | sed -e 's+/$++'`
 	if test [ -x "$mysqlroot/bin/mysql_config" ]
 	then
@@ -41,9 +41,19 @@
 	else 
 		AC_MSG_ERROR([invalid MySQL root directory '$mysqlroot'; neither bin/mysql_config, nor include/ and lib/ were found there])
 	fi
-fi
-
+],[
+	PKG_CHECK_MODULES([MYSQL],[mysqlclient],[
+		MYSQL_PKGLIBDIR=`echo $MYSQL_LIBS | sed -e 's/-[[^L]][[^ ]]*//g;s/\s*-L//g;'`
+		mysqlconfig_used=yes
+	],[
+		PKG_CHECK_MODULES([MYSQL],[mariadb],[
+			MYSQL_PKGLIBDIR=`echo $MYSQL_LIBS | sed -e 's/-[[^L]][[^ ]]*//g;s/\s*-L//g;'`
+			mysqlconfig_used=yes
+		],[])
+	])
+])
 
+AS_IF([test "x$mysqlconfig_used" = x],[
 # try running mysql_config
 AC_MSG_CHECKING([for mysql_config])
 for mysqlconfig in $mysqlconfig_locations
@@ -68,11 +78,11 @@
 done
 if test [ -n "$mysqlconfig" ]
 then
-	mysqlconfig_used=
 	AC_MSG_RESULT([not found])
 else
 	mysqlconfig_used=yes
 fi
+])
 
 
 # if there's nothing from mysql_config, check well-known include paths
--- sphinxsearch-2.2.11.orig/configure.ac
+++ sphinxsearch-2.2.11/configure.ac
@@ -344,31 +344,30 @@
 )
 
 AC_MSG_CHECKING([whether to compile with MySQL support])
-if test  x$ac_cv_use_static_mysql != xno -o x$ac_cv_use_mysql != xno
-then
+AS_IF([test x$ac_cv_use_static_mysql != xno -o x$ac_cv_use_mysql != xno],[
 	dl_mysql=0
-	if test x$ac_cv_use_static_mysql != xno ; then
+	AS_IF([test x$ac_cv_use_static_mysql != xno],[
 		AC_MSG_RESULT([static])
 	AC_CHECK_MYSQL([$ac_cv_use_static_mysql])
 		MYSQL_LIBS=`echo $MYSQL_LIBS | sed -e "sX-lmysqlclientX\$MYSQL_PKGLIBDIR/libmysqlclient.aXg"`
-	else
-		if test x$sph_usedl == xyes ; then
+	],[
+		AS_IF([test x$sph_usedl == xyes],[
 			AC_MSG_RESULT([runtime dynamic])
 			AC_CHECK_MYSQL([$ac_cv_use_mysql])
 			MYSQL_LIBS=""
 			dl_mysql=1
-		else
+		],[
 			AC_MSG_RESULT([dynamic])
 			AC_CHECK_MYSQL([$ac_cv_use_mysql])
-		fi
-	fi
+		])
+	])
 AC_DEFINE(USE_MYSQL,1,[Define to 1 if you want to compile with MySQL support])
 	AC_DEFINE_UNQUOTED(DL_MYSQL,$dl_mysql,[Define to 1 if you want runtime load mysql using dlopen])
 AC_SUBST([MYSQL_LIBS])
 AC_SUBST([MYSQL_CFLAGS])
-else
+],[
 	AC_MSG_RESULT([no])
-fi
+])
 AM_CONDITIONAL(USE_MYSQL, test x$ac_cv_use_mysql != xno -o x$ac_cv_use_static_mysql != xno )
 
 dnl ---

Bug#917129: slapd-smbk5pwd: crashes when enabling krb5

[Ryan Tandy]

Control: reassign -1 libsasl2-2 2.1.27~rc8-1
Control: affects -1 slapd-smbk5pwd

Dear cyrus-sasl2 maintainers,

The latest version of libsasl2-2 seems to have gained dependencies on 
MIT Kerberos libraries. This breaks slapd-smbk5pwd, which links with 
Heimdal libraries (directly) and libsasl (indirectly via libldap) and 
then calls functions exported by both (krb5_init_context). See details 
quoted below.


I'm hoping this is just a bug and can be fixed. If it's an intentional 
change, and not likely to be reverted, then I'd appreciate any advice 
you could offer on how I should approach it from my end...


Thank you,
Ryan

On Sat, Dec 22, 2018 at 10:46:00PM -0800, Ryan Tandy wrote:

Thread 3 "slapd" hit Breakpoint 1, 0x7741a1c0 in krb5_init_context ()
 from /usr/lib/x86_64-linux-gnu/libkrb5.so.3
(gdb) bt
#0  0x7741a1c0 in krb5_init_context () from 
/usr/lib/x86_64-linux-gnu/libkrb5.so.3
#1  0x768e486c in smbk5pwd_modules_init (pi=) at 
smbk5pwd.c:1000

That is the wrong krb5_init_context, we want the Heimdal one!

# ldd /usr/lib/ldap/smbk5pwd.so | grep krb5
libkrb5.so.26 => /usr/lib/x86_64-linux-gnu/libkrb5.so.26 
(0x7f78ce2f3000)
libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 
(0x7f78cdb87000)
libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 
(0x7f78cdaaa000)
libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 
(0x7f78cd34)

This looks like a change in libsasl2-2:

Package: libsasl2-2
Version: 2.1.27~101-g0780600+dfsg-3
Depends: libsasl2-modules-db (>= 2.1.27~101-g0780600+dfsg-3), libc6 (>= 2.15)

Package: libsasl2-2
Version: 2.1.27~rc8-1
Depends: libsasl2-modules-db (>= 2.1.27~rc8-1), libc6 (>= 2.15), libcom-err2 (>= 
1.43.9), libgssapi-krb5-2 (>= 1.6.dfsg.2), libk5crypto3 (>= 1.6.dfsg.2), libkrb5-3 (>= 
1.6.dfsg.2)

Bug#917135: libmariadb-dev: missing Depends: libssl-dev

[Helmut Grohne]

Package: libmaridb-dev
Version: 1:10.3.11-1
Severity: serious
Justification: missing dependency

$ pkg-config --libs mariadb
-lmariadb -lpthread -lz -ldl -lm -lssl -lcrypto
$ dpkg -l libssl-dev
dpkg-query: no packages found matching libssl-dev
$

Given that mariadb.pc lists -lssl, it must Depends: libssl-dev.
Otherwise, it must drop -lssl from mariadb.pc.

Helmut

Bug#917129: slapd-smbk5pwd: crashes when enabling krb5

[Ryan Tandy]

Thread 3 "slapd" hit Breakpoint 1, 0x7741a1c0 in krb5_init_context ()
  from /usr/lib/x86_64-linux-gnu/libkrb5.so.3
(gdb) bt
#0  0x7741a1c0 in krb5_init_context () from 
/usr/lib/x86_64-linux-gnu/libkrb5.so.3
#1  0x768e486c in smbk5pwd_modules_init (pi=) at 
smbk5pwd.c:1000

That is the wrong krb5_init_context, we want the Heimdal one!

# ldd /usr/lib/ldap/smbk5pwd.so | grep krb5
libkrb5.so.26 => /usr/lib/x86_64-linux-gnu/libkrb5.so.26 
(0x7f78ce2f3000)
libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 
(0x7f78cdb87000)
libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 
(0x7f78cdaaa000)
libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 
(0x7f78cd34)

This looks like a change in libsasl2-2:

Package: libsasl2-2
Version: 2.1.27~101-g0780600+dfsg-3
Depends: libsasl2-modules-db (>= 2.1.27~101-g0780600+dfsg-3), libc6 (>= 2.15)

Package: libsasl2-2
Version: 2.1.27~rc8-1
Depends: libsasl2-modules-db (>= 2.1.27~rc8-1), libc6 (>= 2.15), libcom-err2 (>= 
1.43.9), libgssapi-krb5-2 (>= 1.6.dfsg.2), libk5crypto3 (>= 1.6.dfsg.2), libkrb5-3 (>= 
1.6.dfsg.2)

(I really need to create some autopkgtests to catch this sort of thing!)

Bug#917134: opencl-c-headers: Prototype for clCreateFromGLBuffer should use cl_int, not int for error return

[Simon Richter]

Package: opencl-c-headers
Version: 2.1-1
Severity: minor
Tags: upstream

Hi,

the signature for clCreateFromGLBuffer in  uses "int *" for
error return, while the specification uses "cl_int *". These are usually
the same type, so minor.

   Simon

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

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

-- no debconf information

Bug#323615: Propose to NMU debarchiver

[Helge Kreutzmann]

Hello Ola,
On Sat, Dec 22, 2018 at 11:15:14PM +0100, Ola Lundqvist wrote:
> A check question here. Are you really referring to icoutils here? Not
> debarchiver?

No, sorry, copy and paste error, I meant debarchiver.

> If you have a patch file, please send it to me and I'll release an updated
> version with the examples section included.

I'm referring to the suggestion by Jari Aalto, a possible patch is
attached.

Can you also include 858851 and 863618?

Thanks and greetings

Helge

> Best regards
> 
> // Ola
> 
> On Wed, 19 Dec 2018 at 17:42, Helge Kreutzmann  wrote:
> 
> > To: Colin Watson 
> > Cc: 575...@bugs.debian.org
> > User-Agent: Mutt/1.5.23 (2014-03-12)
> >
> > Hello Ola,
> > I propose to NMU icoutils to solve the long standing translation bugs
> > 858851, 863618 and the request for examples (which you acked some 13
> > years ago).
> >
> > I would prefer if you could add this to your next MU (before the
> > freeze), but if I don't hear from you I would upload this NMU
> > early January.
> >
> > If you have any questions do not hesitate to ask.
> >
> > Greetings
> >
> >Helge
> >
> >
> > --
> >   Dr. Helge Kreutzmann deb...@helgefjell.de
> >Dipl.-Phys.
> > http://www.helgefjell.de/debian.php
> > 64bit GNU powered gpg signed mail preferred
> >Help keep free software "libre": http://www.ffii.de/
> >
> 
> 
> -- 
>  - Ola Lundqvist ---
> /  o...@debian.org Folkebogatan 26  \
> |  o...@inguza.com  654 68 KARLSTAD  |
> |  http://inguza.com/  +46 (0)70-332 1551   |
> \  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
>  ---

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/
--- debarchiver.pl.orig	2018-06-22 21:07:41.0 +0200
+++ debarchiver.pl	2018-12-23 07:11:18.543228784 +0100
@@ -3190,6 +3190,15 @@
  * A file that is part of the Changes file is bigger than specified.
  * Verify signatures is enabled and signature do not match.
 
+head  EXAMPLES
+
+Suppose you have just uploaded package to repository e.g. with dput(1),
+and you don't want to wait for the cron process to pick them up. You
+can force immediate handling of incoming queue with this command. The
+second option allows overwriting existing archive files.
+ 
+ # debarchiver --scandetect --addoverride
+
 =head1 FILES
 
 B


signature.asc
Description: Digital signature

Bug#917072: mmm-mode: fails to byte-compile with emacs-26

[David Bremner]

Alexander Zangerl  writes:

> i've nuked that dud patch and now everything incl. mmm-sample byte-compiles
> fine on e26 in a fresh sid chroot, so i'm about to upload 0.5.7-3;
> that'll invalidate your delayed nmu.
>

Sounds good to me.

d

Bug#917072: mmm-mode: fails to byte-compile with emacs-26

[Alexander Zangerl]

On Sat, 22 Dec 2018 16:34:29 +0900, David Bremner writes:
>I'm not quite sure whether this is a bug in emacs 26 or in mmm-mode,

i found the issue, and it's a bug/mistake in mmm-mode; somehow or other
i ended up adding the following, very dud, patch in version 0.5.7-2:

+;; emacs >= 25 has no more caddr -> cl-caddr alias
+(if (>= emacs-major-version 25)
+   (defalias 'caddr 'cl-caddr))
+

with that dud thing in place mmm-vars.el fails to compile on e26 when
cl-third is first called.
that's because on e24 cl-third is an alias for cl-caddr. on e26,
cl-third is an alias for caddr.

i don't exactly understand why compilation works if you skip mmm-sample,
but the issue above is certainly the root cause for the whole mess.

>Attached is an nmudiff that I plan to upload to DELAYED/5

i've nuked that dud patch and now everything incl. mmm-sample byte-compiles
fine on e26 in a fresh sid chroot, so i'm about to upload 0.5.7-3;
that'll invalidate your delayed nmu.

regards
az


-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
"If you want sympathy, look in the dictionary; it's between sex and
syphilis." -- Joe Zeff


signature.asc
Description: Digital Signature

Bug#906235: library documentation not included; HTML docs not well-formed

[Dato Simó]

close 906235
close 906238
thanks

> The HTML files included in the package are not well-formed and 
> do not include a header.

This is because the docs are to be served via godoc only, as 
explained in the package description. I guess that description was 
there when I filed this, but I missed it.

> I installed this package and golang-1.10-doc, and no 
> documentation for the standard library was provided.

Same here. While no HTML is provided, I guess godoc is extracting 
documentation from the source files at runtime.

Thanks,

-d

Bug#917133: openmpi: weird rm -f errors on upgrade

[Christoph Anton Mitterer]

Source: openmpi
Version: 3.1.3-6
Severity: critical
Justification: causes serious data loss


Hi.

On upgrading from 3.1.3-5 I get these:
Unpacking libopenmpi3:amd64 (3.1.3-6) over (3.1.3-5) ...
rm: cannot remove '/usr/lib/x86_64-linux-gnu/fortran/gfortran-8#': No such file 
or directory
rm: cannot remove 'End': No such file or directory
rm: cannot remove 'automatically': No such file or directory
rm: cannot remove 'added': No such file or directory
rm: cannot remove 'section': No such file or directory
dpkg: warning: old libopenmpi3:amd64 package post-removal script subprocess 
returned error exit status 1
dpkg: trying script from the new package instead ...
dpkg: ... it looks like that went OK

...

Unpacking openmpi-common (3.1.3-6) over (3.1.3-5) ...
rm: cannot remove '/usr/lib/x86_64-linux-gnu/fortran/gfortran-8#': No such file 
or directory
rm: cannot remove 'End': No such file or directory
rm: cannot remove 'automatically': No such file or directory
rm: cannot remove 'added': No such file or directory
rm: cannot remove 'section': No such file or directory
dpkg: warning: old openmpi-common package post-removal script subprocess 
returned error exit status 1
dpkg: trying script from the new package instead ...
dpkg: ... it looks like that went OK


Apparently this comes from:
>if test  ! -d /usr/lib/$multiarch/fortran/$base ; then
>   rm -f /usr/lib/$multiarch/fortran/$cmplr
>fi
>
># End automatically added section

in the respective package's postrm, though I can't see any error in it.


Marking this as critical and serious data loss,... as it seems to remove "End",
"automatically" in some relative path(?)... (or does dpkg always cd to some
fixed location?)... so there is at least a remote chance this could remove
user files of these names.


Cheers,
Chris

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

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

Bug#917132: Do not compress favicon.ico file

[Dato Simó]

Package: golang-1.11-doc
Version: 1.11.2-2
Severity: minor

The file:

/usr/share/doc/golang-1.11-doc/favicon.ico.gz

should not compressed, so that godoc can serve it. (After fixing
that, the symlink at /usr/lib/go-1.11/favicon.ico.gz should be
updated as well.)

-d

Bug#917131: ITP: golang-github-alecthomas-kong -- command-line parser for Go

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-alecthomas-kong
  Version : 0.1.15-1
  Upstream Author : Alec Thomas
* URL : https://github.com/alecthomas/kong
* License : Expat, see https://github.com/alecthomas/kong/issues/28
  Programming Lang: Go
  Description : command-line parser for Go

 Kong aims to support arbitrarily complex command-line structures
 with as little developer effort as possible.
 .
 To achieve that, command-lines are expressed as Go types, with the
 structure and tags directing how the command line is mapped onto the
 struct.

Reason for packaging: 
 * New dependency of golang-github-alecthomas-chroma (>= 0.6.1)

Bug#917074: Correction

[Tommi Höynälänmaa]

Hi

I checked it. Those packages must not be removed.

 - Tommi


On 22.12.2018 15:47, Scott Kitterman wrote:

On Saturday, December 22, 2018 11:59:26 AM Tommi Höynälänmaa wrote:

I probably misinterpreted the results of command "apt-cache rdepends".
Please ignore the request to remove packages electronics-analog,
gspiceui, science-electronics, electronics-simulation, and
electronics-asic-dev unless they are actually required by gwave.

Some of those are arch all, so don't need removing (you can't remove them just
for armel, it's all or nothing, so can be ignored).  For the others, you need
to check how to address it either yourself or with the package maintainer.

Typically you'd file a bug against the specific package.  This isn't something
the FTP team can do for you (it doesn't scale for a small team to do this for
every package).

Scott K

Bug#917126: Bug#874003: Nautilus does not launch applications

[Ross Vandegrift]

Control: forwarded -1 https://phab.enlightenment.org/T7521
Control: tags -1 patch

On Sat, Dec 22, 2018 at 11:41:20PM +, Simon McVittie wrote:
> While researching this in codesearch.debian.net I found that e17
> (Enlightenment) still sets the user-preferred file manager by setting
> it as an x-scheme-handler/file handler. e17 maintainers, please
> don't do this: the interoperable freedesktop.org pseudo-MIME-type
> for a general-purpose file manager like Nautilus, Thunar, Dolphin
> or (presumably) enlightenment_filemanager is inode/directory, and
> enlightenment_filemanager's desktop file already announces it as an
> inode/directory handler.

Untested patch attached.  I'm travelling the next week and may not have time to
test/package until January.

> In principle GLib could special-case x-scheme-handler/file to be ignored,
> but I don't think that's a good idea, because it would be a special case
> for something that should never happen in normal desktop sessions anyway,
> and it would mean that the locked-down gdm3 session would have no general
> way to prevent files from being opened.

I don't know the fdo specs well, but this behavior of x-scheme-handler/file
seems like a pretty bad misfeature to me.  Does it exist only for the gdm3
use-case?

Ross
--- a/src/bin/e_open.c
+++ b/src/bin/e_open.c
@@ -438,7 +438,7 @@
/* {"browser", "x-scheme-handler/http"}, */
{"mail", "x-scheme-handler/mailto"},
/*  {"terminal", NULL}, */
-   {"filemanager", "x-scheme-handler/file"},
+   {"filemanager", "inode/directory"},
{"image", "image/jpeg"},
{"video", "video/x-mpeg"},
{"music", "audio/mp3"},
--- a/src/modules/conf_applications/e_int_config_defapps.c
+++ b/src/modules/conf_applications/e_int_config_defapps.c
@@ -131,7 +131,7 @@
 if (s) cfdata->browser_desktop = eina_stringshare_add(s);
 s = efreet_ini_string_get(myini, "x-scheme-handler/mailto");
 if (s) cfdata->mailto_desktop = eina_stringshare_add(s);
-s = efreet_ini_string_get(myini, "x-scheme-handler/file");
+s = efreet_ini_string_get(myini, "inode/directory");
 if (s) cfdata->file_desktop = eina_stringshare_add(s);
 s = efreet_ini_string_get(myini, "x-scheme-handler/trash");
 if (s) cfdata->trash_desktop = eina_stringshare_add(s);
@@ -385,7 +385,7 @@
   efreet_ini_string_set(cfdata->ini, "x-scheme-handler/mailto",
 cfdata->mailto_desktop);
 if ((cfdata->file_desktop) && (cfdata->file_desktop[0]))
-  efreet_ini_string_set(cfdata->ini, "x-scheme-handler/file",
+  efreet_ini_string_set(cfdata->ini, "inode/directory",
 cfdata->file_desktop);
 if ((cfdata->trash_desktop) && (cfdata->trash_desktop[0]))
   efreet_ini_string_set(cfdata->ini, "x-scheme-handler/trash",

Bug#917130: crashs at start

[積丹尼 Dan Jacobson]

Package: gimp
Version: 2.10.8-1
Severity: grave

Gimp crashes at startup.

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

using GEGL version 0.4.12 (compiled against version 0.4.12)
using GLib version 2.58.1 (compiled against version 2.58.1)
using GdkPixbuf version 2.38.0 (compiled against version 2.38.0)
using GTK+ version 2.24.32 (compiled against version 2.24.32)
using Pango version 1.42.3 (compiled against version 1.42.3)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)

```
> fatal error: Segmentation fault

Stack trace:
```

# Stack traces obtained from PID 3715 - Thread 3715 #

[New LWP 3716]
[New LWP 3717]New LWP 3722]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x7f1ab0f8a484 in read () from /lib/x86_64-linux-gnu/libpthread.so.0
  Id   Target Id Frame 
* 1Thread 0x7f1aae82ce00 (LWP 3715) "gimp"   0x7f1ab0f8a484 in read () 
from /lib/x86_64-linux-gnu/libpthread.so.0
  2Thread 0x7f1aab134700 (LWP 3716) "gmain"  0x7f1ab0ea4bd9 in poll () 
from /lib/x86_64-linux-gnu/libc.so.6
  3Thread 0x7f1aaa933700 (LWP 3717) "gdbus"  0x7f1ab0ea4bd9 in poll () 
from /lib/x86_64-linux-gnu/libc.so.6
  4Thread 0x7f1a9ab17700 (LWP 3718) "async"  0x7f1ab0eaa309 in syscall 
() from /lib/x86_64-linux-gnu/libc.so.6
  5Thread 0x7f1a9a316700 (LWP 3719) "worker" 0x7f1ab0eaa309 in syscall 
() from /lib/x86_64-linux-gnu/libc.so.6
  6Thread 0x7f1a99b15700 (LWP 3720) "worker" 0x7f1ab0eaa309 in syscall 
() from /lib/x86_64-linux-gnu/libc.so.6
  7Thread 0x7f1a99314700 (LWP 3721) "worker" 0x7f1ab0eaa309 in syscall 
() from /lib/x86_64-linux-gnu/libc.so.6
  8Thread 0x7f1a98b13700 (LWP 3722) "pool"   0x7f1ab0eaa309 in syscall 
() from /lib/x86_64-linux-gnu/libc.so.6

Thread 8 (Thread 0x7f1a98b13700 (LWP 3722)):
#0  0x7f1ab0eaa309 in syscall () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x7f1ab11b988a in g_cond_wait_until () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#2  0x7f1ab1142061 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#3  0x7f1ab1198dd2 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#4  0x7f1ab11982f5 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#5  0x7f1ab0f80fa3 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#6  0x7f1ab0eaf88f in clone () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.

Thread 7 (Thread 0x7f1a99314700 (LWP 3721)):
#0  0x7f1ab0eaa309 in syscall () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x7f1ab11b976f in g_cond_wait () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#2  0x55bffd3c1423 in ?? ()
No symbol table info available.
#3  0x7f1ab11982f5 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#4  0x7f1ab0f80fa3 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#5  0x7f1ab0eaf88f in clone () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.

Thread 6 (Thread 0x7f1a99b15700 (LWP 3720)):
#0  0x7f1ab0eaa309 in syscall () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.

Bug#917067: [pkg-cryptsetup-devel] Bug#917067: cryptsetup-bin: Opening a LUKS image which resides inside of the /home/ partition

[Guilhem Moulin]

On Sun, 23 Dec 2018 at 01:30:15 +0100, Mikhail Morfikov wrote:
> On 22/12/2018 16:48, Guilhem Moulin wrote:
>> Disk images, key files, and detached headers can reside on arbitrarily
>> complicated file systems and block device stack, and setting up these
>> stacks to make the files available prior to unlocking is really not the
>> job of our initramfs boot scripts.  I'm thus closing this bug as
>> ‘wontfix’, sorry.
>> 
> I don't get it -- I didn't post it as an initramfs issue, only as cryptsetup
> one. I'm not sure, but isn't the /etc/crypttab file a debian specific? If 
> not, I
> can ask about this problem upstream, but I thought it is debian specific, so
> that's why I opened the issue here.

Indeed, you originally opened the bug against ‘cryptsetup-bin’ but there
is no crypttab(5)-handling logic in that package.  crypttab(5) doesn't
come from cryptsetup upstream but isn't Debian-specific either; systemd
normally (unless systemd-cryptsetup-generator(8) is disabled) reads
/etc/crypttab too, just like our own cryptdisks_start(8), initramfs
hooks and SysV init files.

Mapping dm-crypt devices can happen 1. at initramfs stage, 2. later
during the boot process by init(1), or 3. manually once the the system
has finished booting.  Since you disabled systemd-cryptsetup-generator(8)
it's only 1. and 3. left (anyway 2. is done by src:systemd not
src:cryptsetup when init(1) is systemd).  And if you want automatic
unlocking, only 1. left.
 
> That's why I asked if there's a way to use only the /etc/crypttab file
> to make it work.

If by “use only the /etc/crypttab” you mean use a crypttab(5)-handling
logic that is neither systemd-cryptsetup-generator(8) nor cryptdisks_start(8)
(either with .service files or with manual calls), then the device has
to be mapped at initramfs stage, and setup arbitrarily complex file
systems and/or device stacks isn't something our boot scripts are meant
to do.  For such use-case one needs to ensure prerequisites are present
in custom local-top or local-block scripts.  That's why I tagged this
bug as ‘wontfix’.
 
> If this can't/won't be done, I stick with the systemd service I have already,
> because it works just fine, though if I moved from systemd to other init, it
> would stop.

IMHO the right way support to your use-case would be to add support for
keyscripts in systemd (#618862).  Meanwhile, an alternative to your
custom .service file is to unmask cryptdisks.service and add a unit
override to ensure the required file systems are mounted before hand.
(It should work in your case since AFAIU all other crypttab(5) entries
are mapped at initramfs stage, but I wouldn't recommend it as a general
workaround for the lack of keyscript support in systemd, because
keyscripts might introduce races or require a TTY, and the prerequisites
need to be written down by hand.)

If your encrypted disk image is in LUKS2 format (otherwise upgrade from
LUKS1 possible) you can also get away without workaround if you don't
mind re-enabling systemd-cryptsetup-generator(8).  First you need to add
a keyring token for that device:

cryptsetup token add --key-slot 0 --key-description cryptkey-c1 
/home/me/luks/some.img

(The “cryptkey-” prefix in the key description comes from
decrypt_keyctl, but is currently undocumented.  If it ever changes you'd
be prompted for the passphrase — something which anyway will happen if
the key expires before all devices have been opened — but I guess we
could just document the prefix.)

Then with a “simple” crypttab(5) entry (without keyscript)

some_img/home/me/luks/some.img  none  luks

systemd should be able to open the device in an unattended fashion, if
one of the devices unlocked earlier (at initramfs stage) have ‘c1’ as
third column ‘keyscript=decrypt_keyctl’ in the crypttab(5) option column.
Cf. https://gitlab.com/cryptsetup/cryptsetup/blob/master/docs/Keyring.txt
for details.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Hideki Yamane]

Hi,

On Sun, 23 Dec 2018 00:36:52 +
Simon McVittie  wrote:
> To be completely clear about the decision that Ian asked the technical
> committee to overrule:
> 
> In all debootstrap versions since 1.0.102, merged /usr is the default (for
> all variants except --variant=buildd). This means that new installations
> of Debian buster using debian-installer will have merged /usr.
> 
> Do the debian-installer and debootstrap maintainers think this should
> continue to be true for the buster release?

 At this time, yes. +1

 However, if it'll be a blocker for release during freeze, it should
 be reverted.


-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp

Bug#523780:

[unitedcabl...@gmail.com]

Bug#917124: systemd: local-fs.target fails with result 'dependency'

[Michael Biebl]

Control: retitle -1 lvm2 logical volumes are not properly initialized

Am 23.12.18 um 01:38 schrieb Ben Caradoc-Davies:
>> Can you provide a verbose debug log as requested in my previous reply?
> 
> "journalctl -alb" output attached to my previous email. Please let me
> know if you require

Ok, first of all thanks for the information you provided so far.
I doubt it's a but in systemd itself, it's just the recipient of a
device not showing up properly.

The issue is really between the interaction of udev and lvm2.

I suppose if you keep systemd at 239-15 and upgrade udev to 240-1, you
still get the failure. Can you confirm that?
And vice versa, systemd 240-1 together with udev 239-15 should also not
be problematic.

For some reason, lvm devices (logical volumes) are not properly initialized.

When you are dropped into the rescue shell, can you check the following:

Determine the device name for your lvm logical volume. Check the output
of lvdisplay. It should say Block device 253:?

Then check the state of the device in the udev db

udevadm info /sys/class/block/dm-? (? being the number you determined
earlier).

Paste that output please.



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



signature.asc
Description: OpenPGP digital signature

Bug#917124: systemd: local-fs.target fails with result 'dependency'

[Axel Beckert]

Hi,

Michael Biebl wrote:
> Am 23.12.18 um 01:28 schrieb Ben Caradoc-Davies:
> > Dec 23 13:07:52 ripley lvm2-activation-generator: lvmconfig failed
> > Dec 23 13:07:52 ripley lvm2-activation-generator: Activation generator 
> > failed.
> > Dec 23 13:07:52 ripley systemd[376]: 
> > /lib/systemd/system-generators/lvm2-activation-generator failed with exit 
> > status 1.
> 
> That looks suspicious.

Indeed.

> This generator is provided by lvm2. CCing their maintainers.
> Maybe they have an idea what's failing for you and/or can help you debug it.

It's especially not an issue systemd 240-1: Due to this bug report
showing up in apt-listbugs, I didn't upgrade systemd to 240-1 (but
upgraded udev and lvm2) and I also saw messages like that in my syslog
several times during the upgrade:

Dec 23 03:03:24 c-cactus2 systemd[1]: Stopping realtime filesystem monitoring 
program using inotify...
Dec 23 03:03:24 c-cactus2 systemd[1]: Stopped realtime filesystem monitoring 
program using inotify.
Dec 23 03:03:47 c-cactus2 systemd[1]: Reloading.
Dec 23 03:03:47 c-cactus2 lvm2-activation-generator: lvmconfig failed
Dec 23 03:03:47 c-cactus2 lvm2-activation-generator: Activation generator 
failed.
Dec 23 03:03:47 c-cactus2 systemd[12099]: 
/lib/systemd/system-generators/lvm2-activation-generator failed with exit 
status 1.
Dec 23 03:03:47 c-cactus2 systemd[1]: lvm2-lvmetad.socket: Socket unit 
configuration has changed while unit has been running, no open socket file 
descriptor left. The socket unit is not functional until restarted.
Dec 23 03:03:47 c-cactus2 systemd[1]: Starting Garbage Collection for rkt...
Dec 23 03:03:47 c-cactus2 systemd[1]: Started Garbage Collection for rkt.
Dec 23 03:03:47 c-cactus2 systemd[1]: Reloading.
Dec 23 03:03:47 c-cactus2 lvm2-activation-generator: lvmconfig failed
Dec 23 03:03:47 c-cactus2 lvm2-activation-generator: Activation generator 
failed.
Dec 23 03:03:47 c-cactus2 systemd[12197]: 
/lib/systemd/system-generators/lvm2-activation-generator failed with exit 
status 1.
Dec 23 03:03:47 c-cactus2 systemd[1]: lvm2-lvmetad.socket: Socket unit 
configuration has changed while unit has been running, no open socket file 
descriptor left. The socket unit is not functional until restarted.
Dec 23 03:03:47 c-cactus2 systemd[1]: Starting Garbage Collection for rkt...
Dec 23 03:03:47 c-cactus2 systemd[1]: Started Garbage Collection for rkt.
Dec 23 03:03:48 c-cactus2 systemd[1]: Reloading.
Dec 23 03:03:48 c-cactus2 systemd[12253]: 
/lib/systemd/system-generators/lvm2-activation-generator failed with exit 
status 1.
Dec 23 03:03:48 c-cactus2 lvm2-activation-generator: lvmconfig failed
Dec 23 03:03:48 c-cactus2 lvm2-activation-generator: Activation generator 
failed.
Dec 23 03:03:48 c-cactus2 systemd[1]: lvm2-lvmetad.socket: Socket unit 
configuration has changed while unit has been running, no open socket file 
descriptor left. The socket unit is not functional until restarted.
Dec 23 03:03:48 c-cactus2 systemd[1]: Starting Garbage Collection for rkt...
Dec 23 03:03:48 c-cactus2 systemd[1]: Started Garbage Collection for rkt.
Dec 23 03:03:48 c-cactus2 systemd[1]: Reloading.
Dec 23 03:03:48 c-cactus2 lvm2-activation-generator: lvmconfig failed
Dec 23 03:03:48 c-cactus2 lvm2-activation-generator: Activation generator 
failed.
Dec 23 03:03:48 c-cactus2 systemd[12304]: 
/lib/systemd/system-generators/lvm2-activation-generator failed with exit 
status 1.
Dec 23 03:03:48 c-cactus2 systemd[1]: lvm2-lvmetad.socket: Socket unit 
configuration has changed while unit has been running, no open socket file 
descriptor left. The socket unit is not functional until restarted.
Dec 23 03:03:48 c-cactus2 systemd[1]: Starting Garbage Collection for rkt...
Dec 23 03:03:48 c-cactus2 systemd[1]: Started Garbage Collection for rkt.
Dec 23 03:03:48 c-cactus2 systemd[1]: Reloading.
Dec 23 03:03:48 c-cactus2 lvm2-activation-generator: lvmconfig failed
Dec 23 03:03:48 c-cactus2 lvm2-activation-generator: Activation generator 
failed.
Dec 23 03:03:48 c-cactus2 systemd[12340]: 
/lib/systemd/system-generators/lvm2-activation-generator failed with exit 
status 1.
Dec 23 03:03:48 c-cactus2 systemd[1]: lvm2-lvmetad.socket: Socket unit 
configuration has changed while unit has been running, no open socket file 
descriptor left. The socket unit is not functional until restarted.
Dec 23 03:03:49 c-cactus2 systemd[1]: Starting Garbage Collection for rkt...
Dec 23 03:03:49 c-cactus2 systemd[1]: Started LVM2 poll daemon.
Dec 23 03:03:49 c-cactus2 systemd[1]: Started Garbage Collection for rkt.
Dec 23 03:03:49 c-cactus2 systemd[1]: Reloading.
Dec 23 03:03:49 c-cactus2 lvm2-activation-generator: lvmconfig failed
Dec 23 03:03:49 c-cactus2 lvm2-activation-generator: Activation generator 
failed.
Dec 23 03:03:49 c-cactus2 systemd[12405]: 
/lib/systemd/system-generators/lvm2-activation-generator failed with exit 
status 1.
Dec 23 03:03:49 c-cactus2 systemd[1]: lvm2-lvmetad.socket: Socket unit 
configuration has changed while unit has been 

Bug#917072: mmm-mode: fails to byte-compile with emacs-26

[Alexander Zangerl]

On Sat, 22 Dec 2018 16:34:29 +0900, David Bremner writes:
>I'm not quite sure whether this is a bug in emacs 26 or in mmm-mode,
>but in any case it seems the file mmm-sample.el doesn't really need to
>be byte compiled.

weird. i'll try to experiment a bit with mmm-sample, see if i can narrow
this down any further but it's already pretty small...somehow this does
smell like an emacs bug.

>Attached is an nmudiff that I plan to upload to DELAYED/5

thanks for that; certainly no objections from my side.

regards
az


-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
Any suffiently advanced magic is indistinguishable from technology.


signature.asc
Description: Digital Signature

Bug#917129: slapd-smbk5pwd: crashes when enabling krb5

[Ryan Tandy]

Package: slapd-smbk5pwd
Version: 2.4.46+dfsg-5
Severity: important

# ldapmodify -H ldapi:// -Y EXTERNAL << eof
> dn: olcOverlay=smbk5pwd,olcDatabase={1}mdb,cn=config
> changetype: add
> objectClass: olcSmbK5PwdConfig
> olcSmbK5PwdEnable: krb5
> eof
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "olcOverlay=smbk5pwd,olcDatabase={1}mdb,cn=config"
ldap_result: Can't contact LDAP server (-1)

Thread 3 "slapd" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffb58b8700 (LWP 1713)]
initialize_kadm5_error_table_r (list=0x7fffa8104fb8,
list@entry=) at 
kadm5_err.c:101
101 kadm5_err.c: No such file or directory.
(gdb) bt
#0  initialize_kadm5_error_table_r (list=0x7fffa8104fb8,
list@entry=) at 
kadm5_err.c:101
#1  0x767fa14a in krb5_add_et_list 
(context=context@entry=0x7fffa8104f50, func=)
at add_et_list.c:54
#2  0x76870ed5 in _kadm5_s_init_context (ctx=ctx@entry=0x7fffb58b5e00,
params=params@entry=0x76a3c480 , context=0x7fffa8104f50) at 
context_s.c:241
#3  0x76872f6c in kadm5_s_init_with_context (context=,
client_name=0x76a3a025 "kadmin/admin", realm_params=0x76a3c480 
,
server_handle=0x76a3c4b8 , api_version=, 
struct_version=,
service_name=) at init_s.c:53
#4  0x76a378a4 in smbk5pwd_modules_init (pi=) at 
smbk5pwd.c:1009
#5  0x76a37e78 in smbk5pwd_cf_func (c=0x7fffb58b61c0) at smbk5pwd.c:916
#6  0x5558397b in config_set_vals (Conf=0x76a3c100 
, c=0x7fffb58b61c0)
at ../../../../servers/slapd/config.c:353
#7  0x555845ed in config_parse_add (ct=ct@entry=0x76a3c100 
, c=c@entry=0x7fffb58b61c0,
valx=valx@entry=0) at ../../../../servers/slapd/config.c:697
#8  0x5557b2c3 in config_add_internal (e=, 
ca=ca@entry=0x7fffb58b61c0,
rs=rs@entry=0x7fffb58b7850, renum=renum@entry=0x7fffb58b618c, op=, cfb=,
cfb=) at ../../../../servers/slapd/bconfig.c:5217
#9  0x5557c179 in config_back_add (op=0x7fffa8002940, rs=0x7fffb58b7850)
at ../../../../servers/slapd/bconfig.c:5444
#10 0x5559532d in fe_op_add (op=0x7fffa8002940, rs=0x7fffb58b7850) at 
../../../../servers/slapd/add.c:334
#11 0x55596169 in do_add (op=0x7fffa8002940, rs=0x7fffb58b7850) at 
../../../../servers/slapd/add.c:194
#12 0x5558e56c in connection_operation (ctx=ctx@entry=0x7fffb58b79b0, 
arg_v=arg_v@entry=0x7fffa8002940)
at ../../../../servers/slapd/connection.c:1158
#13 0x5558f09d in connection_read_thread (ctx=0x7fffb58b79b0, argv=0xc)
at ../../../../servers/slapd/connection.c:1294
#14 0x77f7d9fd in ldap_int_thread_pool_wrapper (xpool=0x5572c410)
at ../../../../libraries/libldap_r/tpool.c:696
#15 0x776c0fa3 in start_thread (arg=) at 
pthread_create.c:486
#16 0x775f188f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Bug#899269:

[unitedcabl...@gmail.com]

Bug#916905: RFS: Jerry (Chess GUI) /3.1-0 -- looking for sponsor

[Adam Borowski]

On Fri, Dec 21, 2018 at 08:45:40PM +, Dominik Klein wrote:
> thanks very much for your feedback.
> 
> I've filed an ITP under #917027.
> 
> Moreover I've
> - changed the icon to a png, since the problem is likely that not all 
> window manager are able to display .ico
> - changed changelog to mark for unstable
> - added regexp to track new releases via the watch-file
> - modified the copyright file to clarify for all files who owns the 
> copyright and which license
> - The .bin is polyglot opening book. It's format is openly documented, 
> e.g. here http://hardy.uhasselt.be/Toga/book_format.html
> 
> I also changed the changelog 
> https://github.com/asdfjkl/jerry/releases/tag/v3.1.0 to automatically 
> close #917027, i.e. if feedback for the ITP is positive and a sponsor 
> would come forward, the current package might be suitable for inclusion...

Awesome.

There's one laughably small nit: the control file says:
Maintainer: Dominik Klein 
while the changelog:
 -- Dominik Klein   Fri, 21 Dec 2018 10:15:05 +0100
with different capitalization of the email address.

For many mail servers, the user field is case-sentisive, thus tools in
general have to understand it this way.

Yet while it's just a detail, it would spook at least some of the archive
tools into thinking you're not the maintainer.  It'd be best to get this
right before the first upload.


Other stuff that would be nice to improve but are not blockers:

Tthe icon still doesn't work for me (xfce).

The copyright file would be a lot more readable if you placed you and Karl
into a "Files: *" stanza.  If two stanzas match the same file, only the
later one applies, allowing overriding a more global match.

Also, while missing a copyright holder is an error (not for a reasonable
person, but lawyers are not reasonable, thus the ftpmasters need to be
strict), being too generous is benign.  Thus, having both you and Karl for
the majority of files would allow coalescing all those entries into a single
one, leaving nothing but icons, pieces and books.

Likewise, the .install file could be made more readable using wildcards.
Of course, this is not mandatory, but would be nice to have.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Ivan was a worldly man: born in St. Petersburg, raised in
⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned
⠈⠳⣄ to the city of his birth to die.

Bug#917128: udev 240 breaks network interface naming

[Wolfgang Walter]

Package:  udev
Version: 240-1
Severity: important

After upgrading from 239-15 to 240-1 or higher my network setup breaks.

The breakage is similar to the last one I reported (bug #904198) though 
different in detail.

This times all my vlan-devices on a physical device netint are first renamed to 
renameX and than udev tries to rename them again but this time it tries to give 
them all the name netint - which of course fails.

A setup like the following one should be able to reproduce this problem:

10-netint.link:
[Match]
MACAddress=00:01:2e:77:a5:45

[Link]
Name=netint
WakeOnLan=off


netint.network:
[Match]
Name=netint

[Network]
VLAN=kbs
LinkLocalAddressing=no
DHCP=no


kbs.link
[NetDev]
Name=kbs
Kind=vlan

[VLAN]
Id=10



In the journal you should see something like

kernel: rename31: renamed from kbs

systemd-networkd[852]: kbs: Interface name change detected, kbs has been 
renamed to rename31

[347]: kbs: Failed to rename network interface 31 from 'kbs' to 'netint': 
Device or resource busy




Downgrading udev to 239-15 fixes it in principle that is this rename does not 
happen.

systemd-networkd from 240-1 though crashes with

Assertion 'IN_SET(link->state, LINK_STATE_CONFIGURING, 
LINK_STATE_CONFIGURING, LINK_STATE_FAILED, LINK_STATE_LINGER)' failed at 
../src/network/network/networkd-link.c:934, function address_handler(). 
Aborting.

Therefor I also had to downgrade systemd back to 239-15.




Regards,
-- 
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts

Bug#917124: systemd: local-fs.target fails with result 'dependency'

[Ben Caradoc-Davies]

On 23/12/2018 13:43, Michael Biebl wrote:

Am 23.12.18 um 01:38 schrieb Ben Caradoc-Davies:

On 23/12/2018 13:11, Michael Biebl wrote:

Am 23.12.18 um 00:58 schrieb Ben Caradoc-Davies:

Failure was seen with linux-image-4.19.0-1-amd64 4.19.9-1. (Needed to
boot an 4.18.0-3-amd64 initramfs to get a working system.)

So 4.18 works and 4.19 fails?


No, 239-15 works with either kernel, and 240-1 fails, only tested with
the 4.19 kernel. Downgrading to 239-15 makes 4.19 bootable.


Then I don't understand your reply above, where you said you downgraded
to a 4.18.0-3-amd64 initramfs to get a working system.

Can you please elaborate what you meant with the above.


I have three installed kernels:

linux-image-4.18.0-2-amd64 -> 4.18.10-2+b1
linux-image-4.18.0-3-amd64 -> 4.18.20-2
linux-image-4.19.0-1-amd64 -> 4.19.9-1

I upgraded systemd to 240-1, which caused the initramfs for 
linux-image-4.19.0-1-amd64 to be rebuilt to include systemd 240-1 and be 
unbootable, so I booted linux-image-4.18.0-3-amd64 and made the bug 
report. The system information gathered by reportbug is misleading 
because it implies that problem was observed with 4.18.20-2, the running 
kernel at the time of the report, which is not the kernel running when 
the failure was observed. My remark was only to correct this misinformation.


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#908216: btrfs blocked for more than 120 seconds

[Russell Mosemann]

Package: src:linux
Version: 4.18.20-2~bpo9+1
Severity: important
 
This problem was so bad with 4.18.6-1~bpo9+1 that I had to revert to 4.17.0. 
When saw that 4.18.20 was out, I wanted to give it a try. Big mistake. Please 
fix this problem, already.
 
Dec 22 18:14:11 vhost004 kernel: INFO: task btrfs-transacti:708 blocked for 
more than 120 seconds.
Dec 22 18:14:11 vhost004 kernel:   Tainted: G  I   
4.18.0-0.bpo.3-amd64 #1 Debian 4.18.20-2~bpo9+1
Dec 22 18:14:11 vhost004 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Dec 22 18:14:11 vhost004 kernel: btrfs-transacti D0   708  2 0x8000
Dec 22 18:14:11 vhost004 kernel: Call Trace:
Dec 22 18:14:11 vhost004 kernel:  ? __schedule+0x3f5/0x880
Dec 22 18:14:11 vhost004 kernel:  schedule+0x32/0x80
Dec 22 18:14:11 vhost004 kernel:  btrfs_start_ordered_extent+0xed/0x120 [btrfs]
Dec 22 18:14:11 vhost004 kernel:  ? remove_wait_queue+0x60/0x60
Dec 22 18:14:11 vhost004 kernel:  btrfs_wait_ordered_range+0xa0/0x100 [btrfs]
Dec 22 18:14:11 vhost004 kernel:  __btrfs_wait_cache_io+0x46/0x1c0 [btrfs]
Dec 22 18:14:11 vhost004 kernel:  btrfs_start_dirty_block_groups+0x1ad/0x4b0 
[btrfs]
Dec 22 18:14:11 vhost004 kernel:  btrfs_commit_transaction+0xc8/0x8a0 [btrfs]
Dec 22 18:14:11 vhost004 kernel:  ? start_transaction+0x8f/0x3e0 [btrfs]
Dec 22 18:14:11 vhost004 kernel:  transaction_kthread+0x157/0x180 [btrfs]
Dec 22 18:14:11 vhost004 kernel:  kthread+0xf8/0x130
Dec 22 18:14:11 vhost004 kernel:  ? btrfs_cleanup_transaction+0x500/0x500 
[btrfs]
Dec 22 18:14:11 vhost004 kernel:  ? kthread_create_worker_on_cpu+0x70/0x70
Dec 22 18:14:11 vhost004 kernel:  ret_from_fork+0x35/0x40

Dec 22 18:16:12 vhost004 kernel: INFO: task btrfs-transacti:708 blocked for 
more than 120 seconds.
Dec 22 18:16:12 vhost004 kernel:   Tainted: G  I   
4.18.0-0.bpo.3-amd64 #1 Debian 4.18.20-2~bpo9+1
Dec 22 18:16:12 vhost004 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Dec 22 18:16:12 vhost004 kernel: btrfs-transacti D0   708  2 0x8000
Dec 22 18:16:12 vhost004 kernel: Call Trace:
Dec 22 18:16:12 vhost004 kernel:  ? __schedule+0x3f5/0x880
Dec 22 18:16:12 vhost004 kernel:  schedule+0x32/0x80
Dec 22 18:16:12 vhost004 kernel:  btrfs_start_ordered_extent+0xed/0x120 [btrfs]
Dec 22 18:16:12 vhost004 kernel:  ? remove_wait_queue+0x60/0x60
Dec 22 18:16:12 vhost004 kernel:  btrfs_wait_ordered_range+0xa0/0x100 [btrfs]
Dec 22 18:16:12 vhost004 kernel:  __btrfs_wait_cache_io+0x46/0x1c0 [btrfs]
Dec 22 18:16:12 vhost004 kernel:  btrfs_start_dirty_block_groups+0x1ad/0x4b0 
[btrfs]
Dec 22 18:16:12 vhost004 kernel:  btrfs_commit_transaction+0xc8/0x8a0 [btrfs]
Dec 22 18:16:12 vhost004 kernel:  ? start_transaction+0x8f/0x3e0 [btrfs]
Dec 22 18:16:12 vhost004 kernel:  transaction_kthread+0x157/0x180 [btrfs]
Dec 22 18:16:12 vhost004 kernel:  kthread+0xf8/0x130
Dec 22 18:16:12 vhost004 kernel:  ? btrfs_cleanup_transaction+0x500/0x500 
[btrfs]
Dec 22 18:16:12 vhost004 kernel:  ? kthread_create_worker_on_cpu+0x70/0x70
Dec 22 18:16:12 vhost004 kernel:  ret_from_fork+0x35/0x40

Dec 22 18:18:13 vhost004 kernel: INFO: task btrfs-transacti:708 blocked for 
more than 120 seconds.
Dec 22 18:18:13 vhost004 kernel:   Tainted: G  I   
4.18.0-0.bpo.3-amd64 #1 Debian 4.18.20-2~bpo9+1
Dec 22 18:18:13 vhost004 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Dec 22 18:18:13 vhost004 kernel: btrfs-transacti D0   708  2 0x8000
Dec 22 18:18:13 vhost004 kernel: Call Trace:
Dec 22 18:18:13 vhost004 kernel:  ? __schedule+0x3f5/0x880
Dec 22 18:18:13 vhost004 kernel:  schedule+0x32/0x80
Dec 22 18:18:13 vhost004 kernel:  btrfs_start_ordered_extent+0xed/0x120 [btrfs]
Dec 22 18:18:13 vhost004 kernel:  ? remove_wait_queue+0x60/0x60
Dec 22 18:18:13 vhost004 kernel:  btrfs_wait_ordered_range+0xa0/0x100 [btrfs]
Dec 22 18:18:13 vhost004 kernel:  __btrfs_wait_cache_io+0x46/0x1c0 [btrfs]
Dec 22 18:18:13 vhost004 kernel:  btrfs_start_dirty_block_groups+0x1ad/0x4b0 
[btrfs]
Dec 22 18:18:13 vhost004 kernel:  btrfs_commit_transaction+0xc8/0x8a0 [btrfs]
Dec 22 18:18:13 vhost004 kernel:  ? start_transaction+0x8f/0x3e0 [btrfs]
Dec 22 18:18:13 vhost004 kernel:  transaction_kthread+0x157/0x180 [btrfs]
Dec 22 18:18:13 vhost004 kernel:  kthread+0xf8/0x130
Dec 22 18:18:13 vhost004 kernel:  ? btrfs_cleanup_transaction+0x500/0x500 
[btrfs]
Dec 22 18:18:13 vhost004 kernel:  ? kthread_create_worker_on_cpu+0x70/0x70
Dec 22 18:18:14 vhost004 kernel:  ret_from_fork+0x35/0x40

Dec 22 18:20:14 vhost004 kernel: INFO: task btrfs-transacti:708 blocked for 
more than 120 seconds.
Dec 22 18:20:14 vhost004 kernel:   Tainted: G  I   
4.18.0-0.bpo.3-amd64 #1 Debian 4.18.20-2~bpo9+1
Dec 22 18:20:14 vhost004 kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Dec 22 18:20:14 vhost004 kernel: btrfs-transacti D0   708  2 0x8000
Dec 22 18:20:14 

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Marco d'Itri]

On Dec 23, Simon McVittie  wrote:

> An alternative to the usrmerge package might be to do this transition
> in an initramfs hook or something similar, which would guarantee that
> nothing else is concurrently altering /usr or the directories that are
> meant to be merged into it.
FWIW I tried implementing that in 
https://salsa.debian.org/md/usrmerge/tree/initramfs, but it does not 
work because I was not able to open an interactive shell from the 
initramfs script.
Some help from people familiar with initramfs-tools would be 
appreciated.

BTW, that branch also contains a simple script which can be used to 
run the current system in KVM with a throwaway snapshot, to be able to 
try usrmerge with no consequences.

> This remains true even if the usrmerge package is subsequently removed,
> if it was ever installed. The symlinks /bin, /sbin, /lib* remain present,
A clarification: usrmerge is supposed to be removed after the conversion.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#917124: systemd: local-fs.target fails with result 'dependency'

[Ben Caradoc-Davies]

On 23/12/2018 13:40, Michael Biebl wrote:

Am 23.12.18 um 01:28 schrieb Ben Caradoc-Davies:

Dec 23 13:07:52 ripley lvm2-activation-generator: lvmconfig failed
Dec 23 13:07:52 ripley lvm2-activation-generator: Activation generator failed.
Dec 23 13:07:52 ripley systemd[376]: 
/lib/systemd/system-generators/lvm2-activation-generator failed with exit 
status 1.

That looks suspicious.
This generator is provided by lvm2. CCing their maintainers.
Maybe they have an idea what's failing for you and/or can help you debug it.


Those messages also appear with systemd 239-15, which boots without 
problem. For example, from journalctl after downgrade:


Dec 23 13:23:07 ripley kernel: random: cryptsetup: uninitialized urandom 
read (2 bytes read)
Dec 23 13:23:07 ripley kernel: random: lvm: uninitialized urandom read 
(4 bytes read)
Dec 23 13:23:07 ripley kernel: random: lvm: uninitialized urandom read 
(4 bytes read)

Dec 23 13:23:07 ripley kernel: Btrfs loaded, crc32c=crc32c-intel
Dec 23 13:23:07 ripley kernel: EXT4-fs (dm-1): mounted filesystem with 
ordered data mode. Opts: (null)
Dec 23 13:23:07 ripley systemd[1]: systemd 239 running in system mode. 
(+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP 
+LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLK

Dec 23 13:23:07 ripley systemd[1]: Detected architecture x86-64.
Dec 23 13:23:07 ripley systemd[1]: Set hostname to .
Dec 23 13:23:07 ripley lvm2-activation-generator: lvmconfig failed
Dec 23 13:23:07 ripley lvm2-activation-generator: Activation generator 
failed.
Dec 23 13:23:07 ripley systemd[423]: 
/lib/systemd/system-generators/lvm2-activation-generator failed with 
exit status 1.

Dec 23 13:23:07 ripley kernel: random: crng init done
Dec 23 13:23:07 ripley kernel: random: 2 urandom warning(s) missed due 
to ratelimiting
Dec 23 13:23:07 ripley systemd[1]: Created slice 
system-systemd\x2dcryptsetup.slice.

Dec 23 13:23:07 ripley systemd[1]: Created slice User and Session Slice.

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#917124: systemd: local-fs.target fails with result 'dependency'

[Michael Biebl]

Am 23.12.18 um 01:28 schrieb Ben Caradoc-Davies:
> Dec 23 13:07:52 ripley lvm2-activation-generator: lvmconfig failed
> Dec 23 13:07:52 ripley lvm2-activation-generator: Activation generator failed.
> Dec 23 13:07:52 ripley systemd[376]: 
> /lib/systemd/system-generators/lvm2-activation-generator failed with exit 
> status 1.

That looks suspicious.
This generator is provided by lvm2. CCing their maintainers.
Maybe they have an idea what's failing for you and/or can help you debug it.



Regards,
Michael


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



signature.asc
Description: OpenPGP digital signature

Bug#917124: systemd: local-fs.target fails with result 'dependency'

[Michael Biebl]

Am 23.12.18 um 01:38 schrieb Ben Caradoc-Davies:
> On 23/12/2018 13:11, Michael Biebl wrote:
>> Am 23.12.18 um 00:58 schrieb Ben Caradoc-Davies:
>>> Failure was seen with linux-image-4.19.0-1-amd64 4.19.9-1. (Needed to
>>> boot an 4.18.0-3-amd64 initramfs to get a working system.)
>> So 4.18 works and 4.19 fails?
> 
> No, 239-15 works with either kernel, and 240-1 fails, only tested with
> the 4.19 kernel. Downgrading to 239-15 makes 4.19 bootable.

Then I don't understand your reply above, where you said you downgraded
to a 4.18.0-3-amd64 initramfs to get a working system.

Can you please elaborate what you meant with the above.

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



signature.asc
Description: OpenPGP digital signature

Bug#690412: Please auto-detect changed SSL certificates

[Kim Alvefur]

Hi,

If you consider the scope of this bug to be limited to only reloading
XMPP TLS certificates on SIGHUP then this fixed since Prosody 0.10.0,
see .

-- 
Regards,
Kim "Zash" Alvefur

Bug#842634: Bug#851877: fails every time

[James Clarke]

On Sat, Oct 06, 2018 at 11:38:59PM +0200, Santiago Vila wrote:
> On Mon, 15 May 2017, Adam Borowski wrote:
>
> > > Looking at /etc/hosts within the schroot, I see:
> > > 127.0.0.1   localhost
> > > 127.0.0.1   localhost ip6-localhost ip6-loopback
> > > 172.28.17.11abel.debian.org abel
> > >
> > > Modifying /etc/hosts by replacing ::1 with 127.0.0.1 results in being able
> > > to reproduce the issue on other machines as well.
> >
> > So it's a fully _reproducible_ bug, with a well-defined immediate cause
> > (even if we haven't identified the indirect cause yet) -- unlike the
> > original report by Santiago Villa.  Thus, it looks we have two different
> > bugs that just happen to trigger the same failure mode.
> >
> > And thus, even if we fix the schroot issue, Santiago's bug likely won't be
> > fixed.
>
> Hello everybody.
>
> I'd like to clarify that most probably there was only one bug here
> after all, namely, the one in schroot (#842634).
>
> I initially reported this as "random" because I had a mix of
> successful builds and failed builds, but most probably the
> autobuilders in which it failed were always the same, the ones in
> which the build succeeded were always the same, and I just failed to
> recognize the pattern.
>
> Fortunately you have found the real reason for the bug (while I was
> missing from the discussion :-), and I believe this was the only
> reason it failed for me last year.
>
> Now a simple question: Do you think the workaround you prepared could
> still be useful at all (I personally don't think so), or should I just
> reassign this to schroot and use "affects"?
>
> Thanks.

The root cause of the bug is glibc's implementation of gethostent. The
chroot's hosts file is filled by schroot by running `getent hosts`, and
this is what prints the wrong information. If you peek inside the source
of glibc's getent program, then this part of it can be extracted to the
following (LGPLv2.1, and formatting is the GNU style so don't blame me):

> #include 
> #include 
> #include 
> #include 
>
> /* putchar_unlocked exists on BSDs, but not fputs_unlocked */
> #define fputs_unlocked fputs
>
> /* This is for hosts */
> static void
> print_hosts (struct hostent *host)
> {
>   unsigned int cnt;
>
>   for (cnt = 0; host->h_addr_list[cnt] != NULL; ++cnt)
> {
>   char buf[INET6_ADDRSTRLEN];
>   const char *ip = inet_ntop (host->h_addrtype, host->h_addr_list[cnt],
>   buf, sizeof (buf));
>
>   printf ("%-15s %s", ip, host->h_name);
>
>   unsigned int i;
>   for (i = 0; host->h_aliases[i] != NULL; ++i)
> {
>   putchar_unlocked (' ');
>   fputs_unlocked (host->h_aliases[i], stdout);
> }
>   putchar_unlocked ('\n');
> }
> }
>
> int
> main (int argc, char **argv)
> {
>   struct hostent *host;
>
>   sethostent (0);
>   while ((host = gethostent ()) != NULL)
> print_hosts (host);
>   endhostent ();
>   return 0;
> }

If you compile and run this on Linux, you will get the same output as
`getent hosts`, with `::1' being turned into `127.0.0.1'. However, on a
BSD (userland) system, you get a more sane output that doesn't rewrite
IPv6 addresses. So, as this demonstrates, the root problem is that
gethostent in glibc mangles its input. What I don't know is if this is
desired behaviour; I guess someone should file a bug report upstream and
see what they say...

Bug#917124: systemd: local-fs.target fails with result 'dependency'

[Ben Caradoc-Davies]

On 23/12/2018 13:11, Michael Biebl wrote:

Am 23.12.18 um 00:58 schrieb Ben Caradoc-Davies:

Failure was seen with linux-image-4.19.0-1-amd64 4.19.9-1. (Needed to
boot an 4.18.0-3-amd64 initramfs to get a working system.)

So 4.18 works and 4.19 fails?


No, 239-15 works with either kernel, and 240-1 fails, only tested with 
the 4.19 kernel. Downgrading to 239-15 makes 4.19 bootable.



Can you provide a verbose debug log as requested in my previous reply?


"journalctl -alb" output attached to my previous email. Please let me 
know if you require



Can you share more details about your cryptsetup configuration?


An unexciting LVM/LUKS configuration with a single PV, single VG, and 
two LVs (root and home), alongside non-LUKS boot and efi:


# lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda  8:00 232.9G  0 disk
├─sda1   8:1094M  0 part  /boot/efi
├─sda2   8:20   572M  0 part  /boot
└─sda3   8:30 232.2G  0 part
  └─sda3_crypt 253:00 232.2G  0 crypt
├─vg-root  253:1028G  0 lvm   /
└─vg-home  253:20 204.3G  0 lvm   /home

# cat /etc/crypttab
sda3_crypt UUID=79581759-44e0-49e0-9b31-118a456d8415 none luks,discard

I also have in /etc/lvm/lvm.conf:
issue_discards = 1

fstab is attached to the original report.

# cat /etc/fstab
/dev/mapper/vg-root /   ext4 
noatime,errors=remount-ro   0   1
/dev/sda2   /boot   ext4 
noatime,errors=remount-ro   0   2
/dev/sda1   /boot/efi   vfatnoatime,umask=077 
   0   2
/dev/mapper/vg-home /home   ext4 
noatime,errors=remount-ro   0   2

[...]

One possible cause might be my many, many masked services. Could 
local-fs.target be trying to start one of these?:


$ ls -al /etc/systemd/system
total 44
drwxr-xr-x 11 root root 4096 Dec 21 09:18  ./
drwxr-xr-x  5 root root 4096 Dec 23 13:18  ../
lrwxrwxrwx  1 root root9 Apr 15  2017  anacron-resume.service -> 
/dev/null

lrwxrwxrwx  1 root root9 Apr 15  2017  anacron.service -> /dev/null
lrwxrwxrwx  1 root root9 Jun  3  2017  anacron.timer -> /dev/null
lrwxrwxrwx  1 root root9 Dec  8  2017  apparmor.service -> /dev/null
lrwxrwxrwx  1 root root9 Oct 16 09:52  apt-daily-upgrade.service -> 
/dev/null
lrwxrwxrwx  1 root root9 May  5  2017  apt-daily-upgrade.timer -> 
/dev/null

lrwxrwxrwx  1 root root9 Apr 15  2017  apt-daily.service -> /dev/null
lrwxrwxrwx  1 root root9 Apr 15  2017  apt-daily.timer -> /dev/null
lrwxrwxrwx  1 root root9 Apr 15  2017  atd.service -> /dev/null
lrwxrwxrwx  1 root root9 Apr 15  2017  avahi-daemon.service -> /dev/null
lrwxrwxrwx  1 root root9 Apr 15  2017  avahi-daemon.socket -> /dev/null
lrwxrwxrwx  1 root root9 Dec 12  2017  bluetooth.service -> /dev/null
lrwxrwxrwx  1 root root9 Apr 15  2017  bluetooth.target -> /dev/null
lrwxrwxrwx  1 root root9 Apr 17  2017  colord.service -> /dev/null
lrwxrwxrwx  1 root root9 Apr 15  2017  cron.service -> /dev/null
lrwxrwxrwx  1 root root   42 Nov 27  2017 
dbus-fi.w1.wpa_supplicant1.service -> 
/lib/systemd/system/wpa_supplicant.service
lrwxrwxrwx  1 root root9 Apr 15  2017  dbus-org.bluez.service -> 
/dev/null
lrwxrwxrwx  1 root root9 Apr 15  2017 
dbus-org.freedesktop.Avahi.service -> /dev/null
lrwxrwxrwx  1 root root   40 Apr 15  2017 
dbus-org.freedesktop.ModemManager1.service -> 
/lib/systemd/system/ModemManager.service
lrwxrwxrwx  1 root root   53 Apr 15  2017 
dbus-org.freedesktop.nm-dispatcher.service -> 
/lib/systemd/system/NetworkManager-dispatcher.service
lrwxrwxrwx  1 root root   43 Jul  9  2017 
dbus-org.freedesktop.thermald.service -> 
/lib/systemd/system/thermald-custom.service
lrwxrwxrwx  1 root root   35 Oct  8 10:21  display-manager.service -> 
/lib/systemd/system/lightdm.service

lrwxrwxrwx  1 root root9 Apr 15  2017  exim4.service -> /dev/null
drwxr-xr-x  2 root root 4096 Apr 15  2017  getty.target.wants/
drwxr-xr-x  2 root root 4096 Jul 27  2017  graphical.target.wants/
lrwxrwxrwx  1 root root   30 Apr 15  2017  iptables.service -> 
/etc/iptables/iptables.service

drwxr-xr-x  2 root root 4096 Apr 15  2017  local-fs.target.wants/
drwxr-xr-x  2 root root 4096 Dec 21 09:41  multi-user.target.wants/
drwxr-xr-x  2 root root 4096 Feb 23  2018  network-online.target.wants/
lrwxrwxrwx  1 root root9 Oct 12 18:12  postgresql.service -> /dev/null
lrwxrwxrwx  1 root root9 Oct 12 18:13 'postgresql@11-main.service' 
-> /dev/null

lrwxrwxrwx  1 root root9 Apr 15  2017  pppd-dns.service -> /dev/null
drwxr-xr-x  2 root root 4096 Apr 15  2017  printer.target.wants/
lrwxrwxrwx  1 root root9 Apr 15  2017  remote-fs.target -> /dev/null
lrwxrwxrwx  1 root root9 Apr 15  2017  rpcbind.target -> /dev/null
lrwxrwxrwx  1 root root9 Apr 15  2017  rsync.service -> /dev/null
lrwxrwxrwx  1 root 

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Simon McVittie]

To be completely clear about the decision that Ian asked the technical
committee to overrule:

In all debootstrap versions since 1.0.102, merged /usr is the default (for
all variants except --variant=buildd). This means that new installations
of Debian buster using debian-installer will have merged /usr.

Do the debian-installer and debootstrap maintainers think this should
continue to be true for the buster release?

(Sorry, I should have made this the only question in a message, and not
mentioned side issues in the same message.)

Thanks,
smcv

Bug#917067: [pkg-cryptsetup-devel] Bug#917067: cryptsetup-bin: Opening a LUKS image which resides inside of the /home/ partition

[Mikhail Morfikov]

On 22/12/2018 16:48, Guilhem Moulin wrote:
> Disk images, key files, and detached headers can reside on arbitrarily
> complicated file systems and block device stack, and setting up these
> stacks to make the files available prior to unlocking is really not the
> job of our initramfs boot scripts.  I'm thus closing this bug as
> ‘wontfix’, sorry.
> 
I don't get it -- I didn't post it as an initramfs issue, only as cryptsetup
one. I'm not sure, but isn't the /etc/crypttab file a debian specific? If not, I
can ask about this problem upstream, but I thought it is debian specific, so
that's why I opened the issue here.

It's not about accessing as many devices at initramfs phase as possible, only to
open as many devices as possible at boot time using the /etc/crypttab file
instead of mixing debian/systemd (and probably some other) specific solutions. I
didn't see any info that the /etc/crypttab file is used only in initramfs stage
or should be used only in that stage (am I wrong?). I have always been using the
cryptdisks_{start,stop} scripts to open devices specified in the /etc/crypttab
in my system, and it was working just fine.

There's the "initramfs" parameter, which takes care of setting the encrypted
root file system in the initramfs stage. I have this parameter set to all real
devices, because without it the decrypt_keyctl script can't read the password
from the kernel keyring and hence my system it's not able to open the rest of
the encrypted containers. That's why I thought it could work also with the LUKS
file images, but it doesn't.

If the LUKS file images were real devices, there wouldn't be an issue since all
of the listed devices would be opened using the same password at boot/initramfs
time. But when you deal with LUKS containers in a file, you have to use
different solution. That's why I asked if there's a way to use  only the
/etc/crypttab file to make it work.

If this can't/won't be done, I stick with the systemd service I have already,
because it works just fine, though if I moved from systemd to other init, it
would stop.





signature.asc
Description: OpenPGP digital signature

Bug#914897: debootstrap, buster: Please disabled merged /usr by default

[Simon McVittie]

On Mon, 03 Dec 2018 at 17:45:11 +0100, Svante Signell wrote:
> On Sun, 2018-12-02 at 21:04 +0100, Marc Haber wrote:
> > moving hundreds of megabytes from /usr to / over time.
> 
> This solution was proposed by GNU/Hurd several years ago, and was scrapped due
> to not being big enough player in the *NIX world:
> https://www.gnu.org/software/hurd/faq/slash_usr_symlink.html

This did make more sense than the arbitrary split, but with hindsight I'm
glad it did't take off, because the /usr merge does have an important
advantage over the old Hurd proposal: it takes all the static OS files
(which are more similar than they are different) and groups them
together. Unifying those files into / as Hurd used to do would have
made it harder to disentangle them from the sysadmin-modifiable /etc
directory, which needs to be on the root filesystem anyway because it's
where we find /etc/fstab.

If I remember correctly, the people who implemented the /usr merge in
Fedora actually started by proposing that the static files were unified
into / (as in older Hurd versions), and later switched their design
around when they realised that grouping those directories together would
be better.

The name /usr is indeed an unfortunate historical accident.

> We think that we have found a more
> flexible solution called union filesystems, which allow to create virtual
> filesystems which are the union of several other filesystems.  However, 
> support
> for union filesystems is still in early development.

I get the impression that union mounts in Linux aren't completely reliable
either (and have some awkward corner-cases), so solutions that don't
require them seem likely to be more robust.

smcv

Bug#917122: systemd can not start without name_to_handle_at option

[Vladimir Tiukhtin]

Hi

I believe it can be found here https://github.com/systemd/systemd/pull/5499

On Sat, 22 Dec 2018 at 23:47, Michael Biebl  wrote:

> Control: tags -1 + moreinfo
>
> Am 23.12.18 um 00:29 schrieb Vladimir Tiukhtin:
> > Docker limits this system call be default. However RedHat image is
> > running correctly which means that they have back ported a patch for
> > systemd from upstream which resolves this problem on systemd side. Can
> > you please do the same?
>
> Which systemd patch would that be? Can you provide a link?
>
>
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>
>

Bug#916415: nocache broken with glibc 2.28: several programs just hang in call to futex(..., FUTEX_WAIT_PRIVATE, 2, NULL)

[Aurelien Jarno]

control: reassign -1 nocache
control: tag -1 + patch

On 2018-12-14 07:44, Aurelien Jarno wrote:
> control: forwarded -1 https://github.com/Feh/nocache/issues/34
> 
> On 2018-12-14 13:33, Paul Wise wrote:
> > Package: nocache/1.0-1,libc6/2.28-2
> > Severity: critical
> > Justification: breaks unrelated software
> > Usertags: hang
> > 
> > The upgrade from libc6 2.27-8 to 2.28-2 breaks nocache; some programs,
> > when run under it (but not all of them), hang in a call to read/futex:
> 
> I haven't looked at it in details, but at least accorded to the upstream
> bug, it seems to be an issue on the nocache side:
> 
> https://github.com/Feh/nocache/issues/34

There is now an upstream commit fixing the issue on the nocache side:

https://github.com/Feh/nocache/commit/e4e77a48528739188dccbdbd8b4d2d2d49aa0d99


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


signature.asc
Description: PGP signature

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Simon McVittie]

On Wed, 05 Dec 2018 at 14:03:19 +0100, Svante Signell wrote:
> How about this case:
> 
> - Make as default non merged-/usr for all buildds.

This has been done: I sent patches, which have been applied.
(This is actually implemented in two different places, either of which
would have been sufficient to make this happen on all official buildds:
the Debian sysadmins' script to refresh sbuild chroots explicitly
requests unmerged /usr, and debootstrap --variant=buildd also defaults
to unmerged /usr.)

> - Make a choice of non merged-/usr or merged-/usr in the installer.

If you mean "the installer maintainers make a choice": this is effectively
what we have now. The debian-installer maintainers are the maintainers
of debootstrap, they have chosen to merge /usr in new installations,
and this bug report is a request for the technical committee to decide
whether to overrule them.

If you mean "users who run the installer are asked whether they want
merged or unmerged /usr": this seems worse than either merged /usr or
unmerged /usr, because it's asking new Debian users to make a choice in
which they likely have no way to know which answer is most appropriate,
because they aren't using Debian yet. If even experienced Debian users
disagree over what the answer should be (which we do, as you can see in
this thread), then we should not expect new users to be able to make
an informed decision.

> - Users wanting merged-/usr install the usrmerge package and convert to 
> merged-
> /usr.

This is one of several ways to achieve that result: either install
usrmerge, or install into a sysroot that already contains symlinks
/lib -> /usr/lib etc., or use debootstrap --merged-usr (or a recent
debootstrap version in which merged /usr is the default for recent
suites), or do the equivalent of usrmerge by hand.

Merging /usr on an existing system isn't actually difficult to implement
if you are manipulating the system from the outside: the hard parts of
the task of the usrmerge package are making it work on a running system,
and avoiding the system being left in a broken state if the transition
to merged /usr is left half-complete.

An alternative to the usrmerge package might be to do this transition
in an initramfs hook or something similar, which would guarantee that
nothing else is concurrently altering /usr or the directories that are
meant to be merged into it.

> 2) For those having merged-/usr installed:
>Re-run usrmerge to convert all newly installed packages to merged-/usr.
>Is this possible or is installing that package a install-once-only?

If you already have the merged-/usr filesystem layout (either by
installing usrmerge, by using debootstrap with --merged-usr, or by
creating the symlinks some other way), then all newly installed packages
effectively already behave as though they had been converted to merged
/usr: dpkg sees that the .deb contains a file like /bin/sed, but the
root filesystem contains a symlink /bin -> /usr/bin, so it dereferences
the symlink and unpacks sed into /usr/bin. This is part of dpkg's more
general support for relocating directories elsewhere by replacing them
with a symlink.

If that wasn't true, then the usrmerge package would not have been
feasible to implement. It would clearly have been unacceptable to make it
impossible to install unmodified packages later.

This remains true even if the usrmerge package is subsequently removed,
if it was ever installed. The symlinks /bin, /sbin, /lib* remain present,
because removing them would break the system: paths like /bin/sh,
/sbin/fsck, /lib/ld-linux.so.2 and /lib64/ld-linux-x86-64.so.2 must
continue to work indefinitely (even if the files are physically located
at /usr/bin/sh, /usr/sbin/fsck and so on).

smcv

Bug#917124: systemd: local-fs.target fails with result 'dependency'

[Michael Biebl]

Am 23.12.18 um 00:58 schrieb Ben Caradoc-Davies:
> Failure was seen with linux-image-4.19.0-1-amd64 4.19.9-1. (Needed to
> boot an 4.18.0-3-amd64 initramfs to get a working system.)

So 4.18 works and 4.19 fails?

> Attached photo shows console after failure. Plymouth LUKS passphrase
> entry has succeeded, but boot then hangs. Console displayed with keypress.


Can you provide a verbose debug log as requested in my previous reply?
Can you share more details about your cryptsetup configuration?


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



signature.asc
Description: OpenPGP digital signature

Bug#917120: lintian: Lintianrc should contain valid configuration

[Chris Lamb]

Hi Salvo,

> No error message, just that the comment at the top of the file states
> that var assignments should have no spaces, and then all the example
> assignments have spaces.

I don't see any reference to spaces being illegal in this file. Please
could you copy-paste what you are seeing? I'm struggling to see what
the bug is here and we appear to be making a number of unnecessary
round-trips. :)


Regards,

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

Bug#917127: grep: new upstream release brings performance improvements to some situations

[Paul Wise]

Package: grep
Version: 3.1-3
Severity: wishlist

grep 3.2 brings performance improvements to some situations (and bug
fixes):

  An over-30x performance improvement when many 'or'd expressions
  share a common prefix, thanks to improvements in gnulib's dfa.c,
  by Norihiro Tanaka.  See gnulib commits v0.1-2110-ge648401be,
  v0.1-2111-g4299106ce, v0.1-2117-g617a60974

  An additional 3-23% speed-up when searching large files, via
  increased initial buffer size.

https://savannah.gnu.org/forum/forum.php?forum_id=9332

PS: grep 3.2 introduced a regression, fixed in 3.3:

https://savannah.gnu.org/forum/forum.php?forum_id=9334

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

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

Versions of packages grep depends on:
ii  dpkg  1.19.2
ii  install-info  6.5.0.dfsg.1-4+b1
ii  libc6 2.28-2
ii  libpcre3  2:8.39-11

grep recommends no packages.

Versions of packages grep suggests:
ii  libpcre3  2:8.39-11

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#917122: systemd can not start without name_to_handle_at option

[Michael Biebl]

Control: tags -1 + moreinfo

Am 23.12.18 um 00:29 schrieb Vladimir Tiukhtin:
> Docker limits this system call be default. However RedHat image is
> running correctly which means that they have back ported a patch for
> systemd from upstream which resolves this problem on systemd side. Can
> you please do the same?

Which systemd patch would that be? Can you provide a link?



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



signature.asc
Description: OpenPGP digital signature

Bug#917124: systemd: local-fs.target fails with result 'dependency'

[Michael Biebl]

control: tags -1 + moreinfo

Am 23.12.18 um 00:35 schrieb Ben Caradoc-Davies:
> Package: systemd
> Version: 240-1
> Severity: critical
> Justification: breaks the whole system
> 
> Dear Maintainer,
> 
> after upgrade to systemd 240-1, local-fs.target fails with result 
> 'dependency',
> causing boot failure. Failure occurs for non-root LUKS/LVM filesystem.

Are you dropped into a rescue-shell?
If not, please add systemd.debug_shell to the kernel command line.
This will give you a debug shell on tty9.

Once you are in a shell, please get the output of
systemctl status
journalctl -alb





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



signature.asc
Description: OpenPGP digital signature

Bug#874003: Nautilus does not launch applications

[Simon McVittie]

Control: retitle -1 setting a handler for x-scheme-handler/file 
pseudo-MIME-type results in GLib applications sending all files to it
Control: clone -1 -2 -3
Control: reassign -1 libglib2.0-0 2.53.6-1
Control: affects -1 nautilus
Control: block -1 by -2
Control: reassign -2 exo-utils 0.6.2-5
Control: forwarded -2 https://bugzilla.xfce.org/show_bug.cgi?id=7257
Control: tags -2 + fixed-upstream
Control: close -2 0.10.2-4
Control: affects -2 nautilus
Control: block -1 by -3
Control: reassign -3 enlightenment 0.22.4-1
Control: affects -3 nautilus

On Fri, 21 Dec 2018 at 18:41:06 -0600, Drew Vogel wrote:
> I tried both of the fixes mentioned in messages #70 and #75. They both worked
> for me. Thanks everyone!

Hi,
If possible please quote a bit more context when sending emails to bug
reports, and in particular keep the subject line intact: maintainers
will often get these emails completely out of context, and have to look
up the bug number on the web interface to even find out which package
you're talking about, never mind which bug.

The context here is:

* Double-clicking on a file, or right-click and "Open with ", just
  reopened Nautilus instead
* Diagnosis: nautilus ran "gio open" which ran exo-open (from Xfce's
  exo-utils) which just re-ran Nautilus
* Workaround (from message #60): remove exo-utils
* Workaround (from message #70): move
  /usr/share/applications/exo-file-manager.desktop out of the search path
* Workaround (from message #75): remove
  x-scheme-handler/file=exo-file-manager.desktop from
  ~/.local/share/applications/mimeapps.list

Do all the people suffering from this bug have x-scheme-handler/file
in their ~/.local/share/applications/mimeapps.list?

Having exo-open as a handler for the pseudo-MIME-type
x-scheme-handler/file seems to have been an upstream bug
 which was initially
fixed with a Debian patch in 0.10.2-4, and later fixed upstream in
0.10.5. GLib treats x-scheme-handler/file as being a handler for *all*
file: URLs, no matter what they point to (I don't know whether/which
non-GLib implementations of freedesktop.org MIME handlers do the
same, but Nautilus and gio(1) both use GLib). This is appropriate for
some URL scheme pseudo-MIME-types like x-scheme-handler/mailto and
x-scheme-handler/rtsp, but not for x-scheme-handler/file.

The solution to XFCE upstream bug #7257 was to set exo-open as a handler
for the pseudo-MIME-type inode/directory instead (which causes it to
handle directories, but not regular files), putting it in the same
category as Nautilus, Thunar, pcmanfm and enlightenment_filemanager,
among others. However, this change wouldn't remove any existing
x-scheme-handler/file entries from mimeapps.list. Entries in
~/.local/share/applications/mimeapps.list also don't respect OnlyShowIn
(I think this is deliberate, because mimeapps.list can be used to add
user-specific associations that overrule applications' defaults).

I don't think it makes much sense to set an application as a handler for
all file: URLs by setting an x-scheme-handler/file handler, except in
the special case of trying to prevent files from opening in any other
handler (which gdm3 does by setting "mime-dummy-handler.desktop" as the
handler for various URL schemes, including file:, while in the "greeter"
session that provides the gdm login prompt).

While researching this in codesearch.debian.net I found that e17
(Enlightenment) still sets the user-preferred file manager by setting
it as an x-scheme-handler/file handler. e17 maintainers, please
don't do this: the interoperable freedesktop.org pseudo-MIME-type
for a general-purpose file manager like Nautilus, Thunar, Dolphin
or (presumably) enlightenment_filemanager is inode/directory, and
enlightenment_filemanager's desktop file already announces it as an
inode/directory handler. I was tempted to set the cloned bugs in exo-utils
(already fixed) and enlightenment (not fixed) as release-critical,
but for now I've left them set to important.

In principle GLib could special-case x-scheme-handler/file to be ignored,
but I don't think that's a good idea, because it would be a special case
for something that should never happen in normal desktop sessions anyway,
and it would mean that the locked-down gdm3 session would have no general
way to prevent files from being opened.

I'm also not sure whether it's really appropriate for exo-utils to be
registering its programs as MIME type handlers, and then dispatching
to a real MIME type handler from there according to XFCE-specific
configuration. It would seem more appropriate for XFCE to set the
real file manager application (e.g. Thunar) as the handler for the
inode/directory pseudo-MIME-type, directly, and similarly set the real
web browser (e.g. Firefox) as the handler for x-scheme-handler/http
and the real mail client as the handler for x-scheme-handler/mailto,
migrating the XFCE-specific configuration into the MIME list on first-run
after upgrade. That's 

Bug#917098: dpkg -l 'w*' displays 'un' packages

[Guillem Jover]

Hi!

On Sat, 2018-12-22 at 17:31:31 +0200, Alexandros Prekates wrote:
> Package: dpkg
> Version: 1.18.25
> Severity: normal

> In a new installed system with Debian 9.6
> 
> $ dpkg -l
> 
> will list only packages with 'ii' state and a couple of 'rc'.
> 
> But if i  run:
> 
> $ dpkg -l w*(or dpkg -l 'w*' , it doesnt matter in a current dir with no
> 'w' files.)
> 
> i will get a dozen also of 'un' packages.
> 
> So i dont understand the logic of altering the output when
> i use a pattern . I would expect to see only 'ii' packages starting
> from the letter 'w' .

This behavior is documented in the dpkg-query man page. If it's not
clear I guess I could make it more clear by explicitly mentioning that
when a pattern is specified no filtering is performed.

For the logic, I can only assume, it's because with «dpkg-query -l»
you'd want only the most ovbious relevant view of the current state,
which would be all packages except not-installed ones. And when you
request a specific pattern then that should be respected regardless
of its state.

> Some of the listed 'un' packages are virtual, or pure virtual and some
> even dont exist anymore  , like 'wink' , but i found also 'un'
> packages that seem ordinary packages.
> 
> So basically i get output that dont make sense to me. How
> to intepret it?

Any package dpkg has seen in any place where it can see package names
is added to the package list, this includes package names in
dependency fields for example (such as Recommends, Suggests, Conflicts,
Breaks or Enhances).

> Also i dont understand why in a new system dpkg would know
> anything about uninstalled packages! (unless ofcouse as
> man dpkg-query reports are previous installed ones).

See above.

Thanks,
Guillem

Bug#917120: lintian: Lintianrc should contain valid configuration

[Salvo Tomaselli]

No error message, just that the comment at the top of the file states
that var assignments should have no spaces, and then all the example
assignments have spaces.

Unless I am misinterpreting the meaning of the comment, but the
example syntax there has no spaces.

Il giorno dom 23 dic 2018 alle ore 00:24 Chris Lamb 
ha scritto:
>
> tags 917120 + moreinfo
> thanks
>
> Hi Salvo,
>
> > According to the comments at the beginning of the file, /etc/lintianrc uses
> > shell syntax (it gets sourced I presume).
>
> Hm? It's not shell, it's parsed with:
>
>   
> https://salsa.debian.org/lintian/lintian/blob/master/commands/lintian.pm#L1240
>
> > It would be better if people could just uncomment, rather than needing to 
> > fix
> > the syntax as well.
>
> What error message(s) are you seeing, specifically?
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-



-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei

http://ltworf.github.io/ltworf/

Bug#917121: firmware-iwlwifi: gabrielel...@hotmail.com

[Gabriel Elyas]

Package: firmware-iwlwifi
Version: 20180825+dfsg-1
Severity: normal

Dear Maintainer,

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

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

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



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

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

firmware-iwlwifi depends on no packages.

firmware-iwlwifi recommends no packages.

Versions of packages firmware-iwlwifi suggests:
ii  initramfs-tools  0.132

-- no debconf information

Bug#917123: firmware-iwlwifi: slow wifi conection(download speed)

[Gabriel Elyas]

Package: firmware-iwlwifi
Version: 20180825+dfsg-1
Severity: normal

Dear Maintainer,

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

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

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



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

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

firmware-iwlwifi depends on no packages.

firmware-iwlwifi recommends no packages.

Versions of packages firmware-iwlwifi suggests:
ii  initramfs-tools  0.132

-- no debconf information

Bug#917122: systemd can not start without name_to_handle_at option

[Vladimir Tiukhtin]

Package: systemd
Version: 232-25+deb9u6

Running Debian Stretch in docker container results in

Failed to determine whether /sys is a mount point: Operation not permitted
Failed to determine whether /proc is a mount point: Operation not permitted
Failed to determine whether /dev is a mount point: Operation not permitted
Failed to determine whether /dev/shm is a mount point: Operation not
permitted
Failed to determine whether /run is a mount point: Operation not permitted
Failed to determine whether /run/lock is a mount point: Operation not
permitted
Failed to determine whether /sys/fs/cgroup is a mount point: Operation not
permitted
Failed to determine whether /sys/fs/cgroup/systemd is a mount point:
Operation not permitted
[!!] Failed to mount API filesystems, freezing.
Freezing execution.

unless "name_to_handle_at" is whitelisted in default docker seccomp profile
which can be found here
https://github.com/moby/moby/blob/master/profiles/seccomp/default.json

Docker limits this system call be default. However RedHat image is running
correctly which means that they have back ported a patch for systemd from
upstream which resolves this problem on systemd side. Can you please do the
same?

The command I run
docker run -ti \
  --mount type=bind,source=/sys/fs/cgroup,target=/sys/fs/cgroup \
  --mount type=bind,source=/sys/fs/fuse,target=/sys/fs/fuse \
  --mount type=tmpfs,destination=/run \
  --mount type=tmpfs,destination=/run/lock \
  -e container=docker debian:stretch-slim

Vladimir

Bug#917120: lintian: Lintianrc should contain valid configuration

[Chris Lamb]

tags 917120 + moreinfo
thanks

Hi Salvo,

> According to the comments at the beginning of the file, /etc/lintianrc uses
> shell syntax (it gets sourced I presume).

Hm? It's not shell, it's parsed with:

  https://salsa.debian.org/lintian/lintian/blob/master/commands/lintian.pm#L1240

> It would be better if people could just uncomment, rather than needing to fix
> the syntax as well.

What error message(s) are you seeing, specifically?


Regards,

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

Bug#916620: python-mailmanclient-doc: broken symlinks: /usr/share/doc/python-mailmanclient/{rst,index.html}

[Pierre-Elliott Bécue]

Le dimanche 16 décembre 2018 à 18:15:59+0100, Andreas Beckmann a écrit :
> Package: python-mailmanclient-doc
> Version: 3.2.0-2
> Severity: normal
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package ships (or creates)
> a broken symlink.
> 
> From the attached log (scroll to the bottom...):
> 
> 0m26.6s ERROR: FAIL: Broken symlinks:
>   /usr/share/doc/python-mailmanclient/rst -> html/_sources 
> (python-mailmanclient-doc)
>   /usr/share/doc/python-mailmanclient/index.html -> html/README.html 
> (python-mailmanclient-doc)

Hi,

My bad! I've uploaded a fixed package.

Cheers, and thanks!

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#916909: 0ad game fails to start

[Simon McVittie]

Control: reassign -1 libnvtt2 2.1.0-git20160229+dfsg-2~exp1
Control: retitle -1 libnvtt2/experimental: 
nvtt::InputOptions::setTextureLayout(nvtt::TextureType, int, int, int) removed 
without SONAME bump
Control: severity -1 serious

On Thu, 20 Dec 2018 at 18:50:52 +0300, scdes...@yandex.ru wrote:
> 20.12.2018, 15:03, "Simon McVittie" :
> > On Thu, 20 Dec 2018 at 13:53:15 +0300, scdes...@yandex.ru wrote:
> >>  After big upgrade of system libs via aptitude (also 0ad was updated from 
> >> 0.0.23-1 to 0.0.23-1+b2)
> >>  the game fails to start with following error:
> >>
> >>  $ 0ad
> >>  /usr/games/pyrogenesis: symbol lookup error: /usr/games/pyrogenesis: 
> >> undefined symbol: 
> >> _ZN4nvtt12InputOptions16setTextureLayoutENS_11TextureTypeEiii

I've reassigned this bug to libnvtt2, which seems to have broken ABI
between unstable and experimental.

> ii  libgl1-mesa-glx [libgl1]   13.0.6-1~bpo8+1
> ii  libnvtt2   2.1.0-git20160229+dfsg-2~exp1+b3
> ii  libopenal1 1:1.19.1-1
> ii  libpng16-161.6.34-2

You appear to be mixing packages from Debian 8 backports, Debian 9,
unstable and experimental. This is unlikely to go well. Please choose
one of these:

* Debian 9 'stretch', perhaps with selected packages from stretch-backports
* Debian 8 'jessie', perhaps with selected packages from jessie-backports
* testing, perhaps with selected packages from unstable and/or experimental
* unstable, perhaps with selected packages from testing and/or experimental

Thanks,
smcv

Bug#917037: ITP: python3-zeroconf -- Pure Python implementation of multicast DNS service discovery (Python3)

[Simon McVittie]

On Fri, 21 Dec 2018 at 21:59:46 +0100, Ruben Undheim wrote:
> python-zeroconf already exists in the Debian archive. However, upstream has
> dropped support for Python 2, and there are reverse dependencies in Debian
> which depend on the Python 2 package. This makes it necessary with a separate
> source package for the Python 3 version.

See also #894809 (which you could close in the upload of python3-zeroconf,
or mark as a duplicate of this ITP).

I had assumed that you'd want to close #894809 without a new
source package, since the only remaining rdep of python-zeroconf is
pulseaudio-dlna (#894806); but a new source package also seems fine as
a solution, and you have to go through the NEW queue either way.

smcv

Bug#917120: lintian: Lintianrc should contain valid configuration

[Salvo Tomaselli]

Package: lintian
Version: 2.5.117
Severity: wishlist

Dear Maintainer,

According to the comments at the beginning of the file, /etc/lintianrc uses
shell syntax (it gets sourced I presume).

However all the later commented example options do not use said valid syntax.

It would be better if people could just uncomment, rather than needing to fix
the syntax as well.

Best

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

Kernel: Linux 4.18.16 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lintian depends on:
ii  binutils   2.31.1-11
ii  bzip2  1.0.6-9
ii  diffstat   1.62-1
ii  dpkg   1.19.2
ii  dpkg-dev   1.19.2
ii  file   1:5.34-2
ii  gettext0.19.8.1-9
ii  gpg2.2.12-1
ii  intltool-debian0.35.0+20060710.4
ii  libapt-pkg-perl0.1.34+b1
ii  libarchive-zip-perl1.64-1
ii  libcgi-pm-perl 4.40-1
ii  libclass-accessor-perl 0.51-1
ii  libclone-perl  0.41-1+b1
pn  libdigest-sha-perl 
ii  libdpkg-perl   1.19.2
ii  libemail-valid-perl1.202-1
ii  libfile-basedir-perl   0.08-1
ii  libipc-run-perl20180523.0-1
ii  liblist-moreutils-perl 0.416-1+b4
ii  libparse-debianchangelog-perl  1.2.0-13
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.74-1
ii  libxml-simple-perl 2.25-1
ii  libyaml-libyaml-perl   0.75+repack-1
ii  man-db 2.8.4-3
ii  patchutils 0.3.4-2
ii  perl   5.28.1-3
ii  t1utils1.41-2
ii  xz-utils   5.2.2-1.3

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libhtml-parser-perl3.72-3+b3
pn  libtext-template-perl  

-- no debconf information

Bug#917119: [Qa-jenkins-dev] Bug#917119: jenkins.debian.org: Lintian test jobs have not run since 21st November 2018

[Mattia Rizzolo]

Control: owner -1 !

On Sat, Dec 22, 2018 at 10:30:41PM +, Chris Lamb wrote:
>  Any pointers on why https://jenkins.debian.net/job/lintian-
> tests_sid/ has not run in ~1 mo ?
> no idea, no

I know what's going on, I'm very sorry for not noticying this earlier
(as somebody may have guessed I haven't kept a tight look over jenking
in the past weeks…).

I will fix tomorrow when I'll be near my keys again.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

Bug#916101: mailman3: uses a hard-coded and mismatched api_key in mailman-hyperkitty.cfg

[Pierre-Elliott Bécue]

Le lundi 10 décembre 2018 à 08:12:21+, Sampo Sorsa a écrit :
> Source: mailman3
> 
> Dear Maintainer,
> 
> mailman-hyperkitty.cfg [1] contains:
> 
> api_key: SecretArchiverAPIKey
> 
> mailman3-web postinst however, checks for this api_key and generates a random 
> one if it has not been changed [2]. This means the default setup for 
> hyperkitty contains mismatched api key, and will not work.
> 
> mailman3 should generate api_key when writing 
> /etc/mailman3/mailman-hyperkitty.cfg. Then the logic for randomizing the 
> password could be removed from mailman3-web.
> 
> [1]: 
> https://salsa.debian.org/mailman-team/mailman-hyperkitty/blob/master/mailman-hyperkitty.cfg
> [2]: 
> https://salsa.debian.org/mailman-team/mailman-suite/blob/master/debian/mailman3-web.postinst#L114-125

Hi,

Thanks for the report.

I don't consider this as a bug. Obviously it's also the job of a system
administrator to set the appropriate parameters to the appropriate value.

That said, I consider your report as a feature request that should indeed be
implemented.

Yet, I lack some time currently. Could you provide a patch for the package?
I'd be happy to review and take it into account!

Cheers!

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#917119: jenkins.debian.org: Lintian test jobs have not run since 21st November 2018

[Chris Lamb]

Package: jenkins.debian.org
Severity: normal

Hey,

 Any pointers on why https://jenkins.debian.net/job/lintian-
tests_sid/ has not run in ~1 mo ?
no idea, no
other lintian jobs have run?
 No, https://jenkins.debian.net/job/lintian-tests_buster/
(for example)
 Well, more importantly I guess https://jenkins.debian.net/
job/lintian-tests_stretch-backports/
lamby: hm. i guess something killed the triggers. can you
please file a bug against jenkins.debian.org?

Filing bug as requested. Thank you for maintaining
jenkins.debian.org. :)


Best wishes,

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

Bug#917066: libqbscore1.12: log-level debug causes segfault

[Lisandro Damián Nicanor Pérez Meyer]

On Sat, 22 Dec 2018 at 18:25, Dmitry Shachnev  wrote:
[snip]
> The patch author is Christian Kandeler, the upstream Qbs developer.
> So he should push the patch, not Wookey.

oh, my bad! Sorry Wookey!

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Bug#901246: closed by Bernhard Schmidt (Re: linphone-nogtk depends on X and OpenGL)

[Bernhard Schmidt]

Am 20.12.18 um 09:31 schrieb Pali Rohár:

Hi Pali,

>> This was indeed quite bad in 3.6.1 which was present in stretch.
>>
>> In 3.12 the situation has improved a lot. It is not perfect yet, since
>> linphone depends on libmediastreamer-voip10, which in turn depends on a
>> lot of media libraries that sometimes do have a dependency on GL or X
>> (i.e. libmediastreamer-voip10 -> libavcodec-extra58 -> libcairo2 or
>> libmediastreamer-voip10 -> libavcodec-extra58 -> librsvg2-2 -> libpango).
>>
>> I don't think these can be fixed in linphone.
> 
> Could you at least provide 3.12 for stretch-backports?

I don't think so, sorry. The linphone stack consists of ~10 source
packages. Some of the libraries have been moved from one source package
to another. The transition was not straight-forward for Buster and I
don't intend to do this for stretch-backports.

If someone else wants to do this, be my guest.

Bernhard

Bug#914607: Re-adding python-dfwinreg

[Hilko Bengen]

Control: tag -1 pending

I have just uploaded dfwinreg/20181214-2 to DELAYED/10 -- it will have
to wait for python-dtfabric and python3-dtfabric to reach unstable.

Cheers,
-Hilko

Bug#917082: openscenegraph depends and build-depends on cruft packages

[Manuel A. Fernandez Montecelo]

Hi,

Em sáb, 22 de dez de 2018 às 11:33, peter green  escreveu:
>
> package: openscenegraph
> version: 3.2.2+dfsg1-2
> severity: serious
>
> libopenscenegraph100v5 depends on libcoin80-5 and the openscenegraph source 
> package bulid-depends on libcoin80-dev. These packages are no longer built by 
> the coin3 source package. They appear to have been replaced by libcoin80c and 
> libcoin-dev

That must be because of a recent upload to unstable, and that the
package names were not preserved, otherwise it would be a matter of
binNMUing.

So yep, I suppose that we'll hape to change this and hope for the
best, in terms of compatibility.

Thanks for the heads up, in any case!

-- 
Manuel A. Fernandez Montecelo 

Bug#323615: Propose to NMU debarchiver

[Ola Lundqvist]

Hi Helge

A check question here. Are you really referring to icoutils here? Not
debarchiver?

If you have a patch file, please send it to me and I'll release an updated
version with the examples section included.

Best regards

// Ola

On Wed, 19 Dec 2018 at 17:42, Helge Kreutzmann  wrote:

> To: Colin Watson 
> Cc: 575...@bugs.debian.org
> User-Agent: Mutt/1.5.23 (2014-03-12)
>
> Hello Ola,
> I propose to NMU icoutils to solve the long standing translation bugs
> 858851, 863618 and the request for examples (which you acked some 13
> years ago).
>
> I would prefer if you could add this to your next MU (before the
> freeze), but if I don't hear from you I would upload this NMU
> early January.
>
> If you have any questions do not hesitate to ask.
>
> Greetings
>
>Helge
>
>
> --
>   Dr. Helge Kreutzmann deb...@helgefjell.de
>Dipl.-Phys.
> http://www.helgefjell.de/debian.php
> 64bit GNU powered gpg signed mail preferred
>Help keep free software "libre": http://www.ffii.de/
>


-- 
 - Ola Lundqvist ---
/  o...@debian.org Folkebogatan 26  \
|  o...@inguza.com  654 68 KARLSTAD  |
|  http://inguza.com/  +46 (0)70-332 1551   |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---

Bug#859667: libundead: FTBFS on armhf and ppc64el: tests fail

[Andreas Tille]

Hi,

the package builds only for amd64 and i386.  I wonder if it makes sense
to simply restrict the architectures and close this bug.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#833401: debian-policy: virtual packages: dbus-session-bus, default-dbus-session-bus

[gregor herrmann]

On Fri, 07 Dec 2018 19:26:50 -0700, Sean Whitton wrote:

> Thanks.  Seeking seconds:
> 
> diff --git a/virtual-package-names-list.yaml b/virtual-package-names-list.yaml
> index ab2662e..f7626ef 100644
> --- a/virtual-package-names-list.yaml
> +++ b/virtual-package-names-list.yaml
> @@ -106,6 +106,10 @@ virtualPackages:
> description: anything that is capable of controlling an UPS
>   - name: cron-daemon
> description: Any cron daemon that correctly follows policy requirements
> + - name: dbus-session-bus
> +   description: provides the D-Bus well-known session bus for most or all 
> user login sessions
> + - name: default-dbus-session-bus
> +   description: Debian's preferred implementation of dbus-session-bus, 
> possibly architecture-specific
> 
>  # Documentation
> 
> @@ -435,3 +439,7 @@ virtualPackages:
>  # virtual-mysql-server-core
>  # virtual-mysql-testsuite
>  #   08 Jan 2017 Added adventure
> +#
> +# Sean Whitton:
> +#   xx Dec 2018 Added dbus-session-bus
> +#   Added default-dbus-session-bus
> 

This looks all good to me, hence: seconded.


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#850156: Patch implementing CTTE decision

[gregor herrmann]

On Sat, 17 Nov 2018 09:14:52 -0700, Sean Whitton wrote:

> Seeking seconds:
> 
> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index 3c6c9d5..821010f 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -787,6 +787,13 @@ according to this convention, the C source code of an 
> executable
>  ``checksum/util`` is to be located at
>  ``debian/missing-sources/checksum/util.c``.
> 
> +Vendor-specific patch series
> +
> +
> +Packages in the Debian archive using the 3.0 (quilt) source package
> +format should not contain a non-default series file.  That is, there
> +should not exist a file ``debian/patches/foo.series`` for any ``foo``.
> +
>  .. [#]
> Rationale:
> 
> diff --git a/policy/upgrading-checklist.rst b/policy/upgrading-checklist.rst
> index 70b31bd..97ae91a 100644
> --- a/policy/upgrading-checklist.rst
> +++ b/policy/upgrading-checklist.rst
> @@ -56,6 +56,11 @@ Unreleased.
>  Required targets must not write outside of the unpacked source
>  package tree, except for TMPDIR (or /tmp if that is not set).
> 
> +4.17
> +Packages should not contain a non-default series file.  That is,
> +dpkg's vendor-specific patch series feature should not be used for
> +packages in the Debian archive.
> +
>  10.1
>  Binaries should be stripped using
>  ``strip --strip-unneeded --remove-section=.comment 
> --remove-section=.note``
> 

As this simply implements the ctte decision in #850156:
seconded.


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#914955: Uploading soon test-kitchen and ruby-mixlib-install

[Mathieu Parent]

Le samedi 22 décembre 2018, Hleb Valoshka <375...@gmail.com> a écrit :
> On 12/22/18, Mathieu Parent  wrote:
>> 23 days have passed since those ITS. i will upload to DELAYED/7 now.
>>
>> All the changes are on salsa.
>
> Hi Mathieu,
>
> Could you takeover maintenance for test-kitchen? I don't use it and
> friends for a long time, so I'm unable to properly maintain it.

Hi Hleb,

Ok. Will take it over. Should I take mixlib-install too?

Regards

Mathieu

NB: in this case, I will shorten the 7 days delay

-- 
Mathieu

Bug#917118: ITP: python-mbed-ls -- module listing mbed-enabled devices connected to host

[Nick Morrott]

Package: wnpp
Owner: Nick Morrott 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: python-mbed-ls
  Version : 1.6.2
  Upstream Author : Przemyslaw Wirkus 
* URL : https://github.com/ARMmbed/mbed-ls
* License : Apache-2.0
  Programming Lang: Python
  Description : module listing mbed-enabled devices connected to host

The Mbed LS module detects and lists "Mbed Enabled" devices connected to the
host computer.

Mbed LS provides the following information for all connected boards using
console (terminal) output:

 -  Mbed OS platform name
 -  mount point (MSD or disk)
 -  serial port

I plan to maintain this package in the Python Applications Packaging Team.

Bug#915419: debdiff for 915692, 915419

[Luca Boccassi]

Control: tags -1 pending

On Wed, 19 Dec 2018 16:39:17 +0100 Luca Boccassi 
wrote:
> Dear Maintainer,
> 
> In order to allow the DPDK 17.11 -> 18.11 transition to happen [1], I
> intend to upload a source NMU fixing 915692 and 915419 (debdiff
> attached) either at the end of this week or at the beginning of the
> next to DELAYED/1.
> 
> I hope this does not cause any troubles, and please let me know if
this
> would be an issue, and/or if you prefer an alternative solution.
> 
> Thank you!
> 
> -- 
> Kind regards,
> Luca Boccassi
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916351

Dear Maintainers,

I have uploaded the aforementioned NMU to DELAYED/2 to allow for the
DPDK transition to start on Monday. Please let me know if this is an
issue and would like me to cancel it.

Thanks!

-- 
Kind regards,
Luca Boccassi

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

Bug#917066: libqbscore1.12: log-level debug causes segfault

[Dmitry Shachnev]

On Sat, Dec 22, 2018 at 06:18:05PM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Disclaimer: I *think* that QBS works as with Qt: normal Qt workflow
> expects the patch writer to submit the change to Qt's gerrit instance
> due to the CLA. Qt submodule maintainers shouldn't get patches from a
> mailing list except the patch can be deemed uncopyrigtheable and if
> they are willing to do so.
>
> So the best thing you can do here is push the patch to
> codereview.qt-project.org.

The patch author is Christian Kandeler, the upstream Qbs developer.
So he should push the patch, not Wookey.

I am doing a new upload now.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#917066: libqbscore1.12: log-level debug causes segfault

[Lisandro Damián Nicanor Pérez Meyer]

Hi Wookey!

On Sat, 22 Dec 2018 at 18:06, Wookey  wrote:
>
> On 2018-12-22 21:56 +0300, Dmitry Shachnev wrote:
> > Hi Wookey!
> >
> > On Sat, Dec 22, 2018 at 03:06:21AM +, Wookey wrote:
> > > Enabling --log-level debug (or using --more-verbose) (in the build of
> > > dewalls) causes the build to fail with a segfault.
> > >
> > > This has been discussed upstream and a fix for the null pointer
> > > dereference produced. Please apply the attached patch to the package
> > > until the next release when you should be able to drop this patch.
> > >
> > > Details are in this thread:
> > > https://lists.qt-project.org/pipermail/qbs/2018-December/002290.html
> > > (some of it was not copied to the list)
> >
> > Patch committed, thanks!
> >
> > I don’t see it applied in upstream Git yet, not even submitted to
> > https://codereview.qt-project.org. Can you please ask upstream to do so?
>
> I only confirmed to Christian K that it worked yesterday
> (shortly before I filed the debian bug) so I don't think he's had time to
> apply it yet. I expect he'll do so soonish (modulo Xmas).

Disclaimer: I *think* that QBS works as with Qt: normal Qt workflow
expects the patch writer to submit the change to Qt's gerrit instance
due to the CLA. Qt submodule maintainers shouldn't get patches from a
mailing list except the patch can be deemed uncopyrigtheable and if
they are willing to do so.

So the best thing you can do here is push the patch to
codereview.qt-project.org.

Cheers!


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Bug#917116: Buster: Salt Depends: python3-tornado (< 5) but 5.1.1-2 is to be installed

[Frans van Berckel]

Package: salt-common

Dear team,

While installing salt-minion, I wasn't able to, because salt-common
depends on python3-tornado (< 5) but Buster does 5.1.1-2.

Will a simple rebuild solve the issue? Or is there more to do?

Thanks,

-- 
Frans van Berckel
Media Engineer / Linux Master
LinkedIn: https://www.linkedin.com/in/fransvberckel/

Bug#917117: grub-efi-amd64-signed: doesn't mount cryptodisk

[Alexander Batischev]

Package: grub-efi-amd64-bin
Version: 1+2.02+dfsg1+9
Severity: critical

Dear Maintainer,

I'm running a UEFI system. I have GRUB_ENABLE_CRYPTODISK=y in my 
/etc/default/grub. Ever since 2.02+dfsg1+6, each GRUB2 update removes 
cryptomount call from /boot/efi/EFI/debian/grub.cfg, and thus breaks the 
boot: GRUB drops into a recovery shell, unable to find my root partition 
(which is on LVM inside LUKS). /boot/efi is where I mount the ESP 
partition. I don't recall if the problem existed before 2.02+dfsg1+6.

This has been reported in #908162 before (against 2.02+dfsg1+6). 
Ostensibly fixed in 2.02+dfsg1+7, but I still experience the bug.

I'm running Debian testing which only has 2.02+dfsg1+8 at the moment, so 
I got 2.02+dfsg1+9 from Sid. That didn't fix the problem.

For now, my solution is to manually edit aforementioned grub.cfg, and 
add the following at the very start:

set prefix=(hd0,gpt1)/efi/grub
insmod luks
insmod lvm
cryptomount (lvm/sda2_lvm-root)

These lines are removed each time grub-efi-amd64 is reinstalled. 
Reinstallation of grub-efi-amd64-signed doesn't touch those lines. 
However, if I uninstall grub-efi-amd64-signed, reinstalling 
grub-efi-amd64 *doesn't* remove those lines.


Thank you for maintaining the package! I've been running Debian on and 
off for almost ten years now, and that's the first critical bug I ever 
encountered. Please keep up the good work!

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

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

Versions of packages grub-efi-amd64-bin depends on:
ii  efibootmgr   15-1
ii  grub-common  2.02+dfsg1-9

grub-efi-amd64-bin recommends no packages.

-- no debconf information

Bug#916779: libc6-armhf-cross: strerror(-3) sets errno to ENOMEM

[Aurelien Jarno]

control: clone 916779 -1
control: reassign -1 gcc-8
control: retitle -1 gcc-8: --fno-math-errno causes GCC to consider that malloc 
does not set errno
control: submitted -1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88576

On 2018-12-22 13:37, Aurelien Jarno wrote:
> This is not what happens, errno is not set to ENOMEM in strerror_() but
> in strerror(). The problem is that the malloc implementation when run
> under QEMU sets errno to ENOMEM, despite successfully allocating the
> memory. errno is supposed to be saved around the malloc call:
> 
>   saved_errno = errno;
>   if (buf == NULL) 
> buf = malloc (1024);
>   __set_errno (saved_errno); 
> 
> That said, when compiled with -fno-math-errno, GCC optimizes out
> saving and restoring errno around the malloc call. I am not sure if this
> is a GCC bug or a bug in the GCC documentation.

This has been confirmed to be a GCC bug, here is the upstream bug
report:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88576

As this bug is likely going to be workarounded in glibc, I am cloning
this bug and reassigning the clone to the gcc-8 package. I'll close the
glibc one when adding the workaround or a bumped build-dependency on
gcc-8.

Regards,
Aurelien

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


signature.asc
Description: PGP signature

Bug#917066: libqbscore1.12: log-level debug causes segfault

[Wookey]

On 2018-12-22 21:56 +0300, Dmitry Shachnev wrote:
> Hi Wookey!
> 
> On Sat, Dec 22, 2018 at 03:06:21AM +, Wookey wrote:
> > Enabling --log-level debug (or using --more-verbose) (in the build of
> > dewalls) causes the build to fail with a segfault.
> >
> > This has been discussed upstream and a fix for the null pointer
> > dereference produced. Please apply the attached patch to the package
> > until the next release when you should be able to drop this patch. 
> >
> > Details are in this thread:
> > https://lists.qt-project.org/pipermail/qbs/2018-December/002290.html
> > (some of it was not copied to the list)
> 
> Patch committed, thanks!
> 
> I don’t see it applied in upstream Git yet, not even submitted to
> https://codereview.qt-project.org. Can you please ask upstream to do so?

I only confirmed to Christian K that it worked yesterday
(shortly before I filed the debian bug) so I don't think he's had time to
apply it yet. I expect he'll do so soonish (modulo Xmas).

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#917114: ansible: crashes when trying to read vault variables

[Yvan Masson]

Package: ansible
Version: 2.7.5+dfsg-1
Severity: normal

Dear Maintainer,

Using testing, Ansible crashes when trying to read vault variables. I
see this issue since Ansible 2.6 at least.

For example, I have a playbook I run with:
  ansible-playbook -i host.ini -bkK --vault-id @prompt main.yml -vvv

The error is attached (ansible-crash.log).

The vault is:

$ANSIBLE_VAULT;1.1;AES256
38613831366531323432326436616438363765303566326439336563313534386533396236383035
3363363335383833303665326262666563646465363862330a336639646631336265613639666365
6239653234303533653934366536313765376135303162306432373662376638326634343432
3933633832353761300a333964393134316265653161633736656233306463346535313761303732
61653363623836383964663365663734346636323735623863396435303938306162663939363135
3634663662386334383263653430653965383162376532633664

And contains:

dyndns_pwd: 1234
smtpd_pwd: 1234

For reference, I asked on Ansible forums
(https://groups.google.com/forum/#!msg/ansible-project/WlPtOS2h1vE/fnlzbZv1BgAJ)
with no answer.

Best regards,
Yvan

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

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

Versions of packages ansible depends on:
ii  python2.7.15-3
ii  python-crypto 2.6.1-9+b1
ii  python-cryptography   2.3-1
ii  python-httplib2   0.11.3-1
ii  python-jinja2 2.10-1
ii  python-netaddr0.7.19-1
ii  python-paramiko   2.4.2-0.1
ii  python-pkg-resources  40.6.2-1
ii  python-yaml   3.13-1

Versions of packages ansible recommends:
ii  python-jmespath   0.9.3-1
ii  python-kerberos   1.1.14-1+b1
ii  python-libcloud   2.3.0-3
ii  python-selinux2.8-1+b1
pn  python-winrm  
ii  python-xmltodict  0.11.0-2

Versions of packages ansible suggests:
pn  cowsay   
ii  sshpass  1.06-1

-- no debconf information
TASK [include_vars] **
task path: /some/path/to/playbook.yml:39
The full traceback is:
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/ansible/executor/task_executor.py", line 140, in run
res = self._execute()
  File "/usr/lib/python2.7/dist-packages/ansible/executor/task_executor.py", line 612, in _execute
result = self._handler.run(task_vars=variables)
  File "/usr/lib/python2.7/dist-packages/ansible/plugins/action/include_vars.py", line 131, in run
self._load_files(self.source_file)
  File "/usr/lib/python2.7/dist-packages/ansible/plugins/action/include_vars.py", line 236, in _load_files
b_data, show_content = self._loader._get_file_contents(filename)
  File "/usr/lib/python2.7/dist-packages/ansible/parsing/dataloader.py", line 162, in _get_file_contents
return self._decrypt_if_vault_data(data, b_file_name)
  File "/usr/lib/python2.7/dist-packages/ansible/parsing/dataloader.py", line 132, in _decrypt_if_vault_data
b_data = self._vault.decrypt(b_vault_data, filename=b_file_name)
  File "/usr/lib/python2.7/dist-packages/ansible/parsing/vault/__init__.py", line 658, in decrypt
plaintext, vault_id, vault_secret = self.decrypt_and_get_vault_id(vaulttext, filename=filename)
  File "/usr/lib/python2.7/dist-packages/ansible/parsing/vault/__init__.py", line 743, in decrypt_and_get_vault_id
display.v('Decrypt%s successful with secret=%s and vault_id=%s' % (file_slug, vault_secret, vault_secret_id))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 36: ordinal not in range(128)

fatal: [home-server]: FAILED! => {
"msg": "Unexpected failure during module execution.", 
"stdout": ""
}


signature.asc
Description: OpenPGP digital signature

Bug#917042: dtfabric: Wrong name

[Hilko Bengen]

Control: tag -1 patch

Dear maintainer,

I have uploaded a fixed package to DELAYED/10; please feel free to
reschedule or cancel my upload as you see fit. The patches I applied to
my local git clone are attached to this mail.

Cheers,
-Hilko
>From 89bc2d6ac0cf92c65ef015b239928b54b0ae9270 Mon Sep 17 00:00:00 2001
From: Hilko Bengen 
Date: Fri, 21 Dec 2018 23:16:58 +0100
Subject: [PATCH 1/3] Add python3- prefix to dtfabric, introduce Python 2
 package (Closes: #917042)

---
 debian/README.Debian |  6 --
 debian/changelog |  6 ++
 debian/control   | 30 +-
 debian/rules | 12 +---
 4 files changed, 40 insertions(+), 14 deletions(-)
 delete mode 100644 debian/README.Debian

diff --git a/debian/README.Debian b/debian/README.Debian
deleted file mode 100644
index 26612ca..000
--- a/debian/README.Debian
+++ /dev/null
@@ -1,6 +0,0 @@
-dtfabric for Debian
-
-Since python 2.7 python will EOL in 2020, I only enable python 3 in this
-package. Furthermore, I removed the dtfabric script extension.
-
- -- SZ Lin (林上智)   Wed, 12 Sep 2018 20:29:43 +0800
diff --git a/debian/changelog b/debian/changelog
index a6b87e6..89106a5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+dtfabric (20180808-2) UNRELEASED; urgency=medium
+
+  * Add python3- prefix to dtfabric, introduce Python 2 package
+
+ -- Hilko Bengen   Fri, 21 Dec 2018 23:16:09 +0100
+
 dtfabric (20180808-1) unstable; urgency=low
 
   * Initial release (Closes: #908665)
diff --git a/debian/control b/debian/control
index 2975362..562631e 100644
--- a/debian/control
+++ b/debian/control
@@ -4,27 +4,47 @@ Priority: optional
 Maintainer: SZ Lin (林上智) 
 Build-Depends: debhelper (>= 11),
dh-python,
-   python3-all,
-   python3-setuptools,
-   python3-yaml
+   python-all, python3-all,
+   python-setuptools, python3-setuptools,
+   python-yaml, python3-yaml,
 Standards-Version: 4.2.1
 Homepage: https://github.com/libyal/dtfabric
 Vcs-Git: https://salsa.debian.org/debian/dtfabric.git
 Vcs-Browser: https://salsa.debian.org/debian/dtfabric
 Testsuite: autopkgtest-pkg-python
 
-Package: dtfabric
+Package: python-dtfabric
 Architecture: all
 Multi-Arch: foreign
+Depends: ${misc:Depends}, ${python:Depends},
+ python3-yaml
+Description: Tooling for data type and structure management
+ Data types fabric (dtFabric) is a proof-of-concept YAML-based
+ definition language to specify format and data types.
+ .
+ Supported data types
+ .
+  Storage data types, such as integers, characters, structures
+  Semantic data types, such as constants, enumerations
+  Layout data types, such as format, vectors, trees
+ .
+ This package contains the Python 2 version of the package.
+
+Package: python3-dtfabric
+Architecture: all
+Breaks: dtfabric (<< 20180808-1.1)
+Replaces: dtfabric (<< 20180808-1.1)
+Multi-Arch: foreign
 Depends: ${misc:Depends}, ${python3:Depends},
  python3-yaml
 Description: Tooling for data type and structure management
  Data types fabric (dtFabric) is a proof-of-concept YAML-based
  definition language to specify format and data types.
  .
- Support data types
+ Supported data types
  .
   Storage data types, such as integers, characters, structures
   Semantic data types, such as constants, enumerations
   Layout data types, such as format, vectors, trees
  .
+ This package contains the Python 3 version of the package.
diff --git a/debian/rules b/debian/rules
index 418db83..216412f 100755
--- a/debian/rules
+++ b/debian/rules
@@ -2,11 +2,17 @@
 
 export PYBUILD_NAME:=dtfabric
 %:
-	dh $@  --with python3 --buildsystem=pybuild
-	
+	dh $@  --with python2,python3 --buildsystem=pybuild
+
 override_dh_install:
 	dh_install
-	mv debian/dtfabric/usr/bin/validate-definitions.py debian/dtfabric/usr/bin/validate-definitions
+	mv debian/python3-dtfabric/usr/bin/validate-definitions.py \
+	   debian/python3-dtfabric/usr/bin/validate-definitions
+	mv debian/python3-dtfabric/usr/share/doc/dtfabric \
+	   debian/python3-dtfabric/usr/share/doc/python3-dtfabric
+	mv debian/python-dtfabric/usr/share/doc/dtfabric \
+	   debian/python-dtfabric/usr/share/doc/python-dtfabric
+	rm -rf debian/python-dtfabric/usr/bin
 
 override_dh_auto_install:
 	dh_auto_install
-- 
2.19.1

>From 3f80b2258e37b76675945c0782c5b99b648b24bd Mon Sep 17 00:00:00 2001
From: Hilko Bengen 
Date: Sat, 22 Dec 2018 21:56:09 +0100
Subject: [PATCH 2/3] Move package to section python

---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 562631e..9204bf8 100644
--- a/debian/control
+++ b/debian/control
@@ -1,5 +1,5 @@
 Source: dtfabric
-Section: utils
+Section: python
 Priority: optional
 Maintainer: SZ Lin (林上智) 
 Build-Depends: debhelper (>= 11),
-- 
2.19.1

>From c3bebfe4fe7194da9892b1a591cfbeb13a46e990 Mon Sep 17 00:00:00 2001
From: Hilko Bengen 
Date: Sat, 22 Dec 2018 

Bug#916779: libc6-armhf-cross: strerror(-3) sets errno to ENOMEM

[Aurelien Jarno]

On 2018-12-22 19:42, Tim Rühsen wrote:
> On 22.12.18 16:56, Aurelien Jarno wrote:
> > The problem is that qemu-arm does not provide a heap to the program, so
> > glibc fails to alloc memory through brk. This causes malloc to switch to
> > mmap based memory allocation, and this also sets errno to ENOMEM.
> > 
> > printf also calls malloc, so the malloc implementation switches to
> > mmap based memory allocation at this moment. This is remembered through
> > the life of the program. When strerror then calls malloc(1024), the
> > allocation is done directly through mmap and errno is not set to ENOMEM.

Setting errno to ENOMEM happens during the call to MORECORE/sbrk in 
malloc/malloc.c in the following lines of the sysmalloc function:

|  if (size > 0)
|{
|  brk = (char *) (MORECORE (size));
|  LIBC_PROBE (memory_sbrk_more, 2, brk, size);
|}

Note however that clobbering errno is allowed even in case of success,
unless the contrary is specifically documented.

> > That's why you do not see the issue.
> > 
> > To reproduce the issue, you therefore need the following conditions:
> > - The kernel or QEMU does not provide a heap to the program
> > - malloc is not called (implicitly or explicitly) before the call to
> >   strerror
> > - strerror is called with an invalid error number.
> > 
> > If all of this 3 conditions are not met, the bug does not appear.
> 
> That is a good explanation and makes sense to me, thank you, Aurelien.
> 
> At least we can work around that issue now.
> 
> BTW, how do you debug cross-compiled executables ? There is no cross-gdb
> packaged in debian (or is there ?). Building that from scratch seems too
> time-intensive...

I have been rebuilding glibc, directly modifying the code being
debugged. ccache is really useful in that case.

Regards,
Aurelien

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


signature.asc
Description: PGP signature

Bug#917093: matplotlib2 breaks graphlan autopkgtest

[Sandro Tosi]

Andreas,

On Sat, Dec 22, 2018 at 3:45 PM Andreas Tille  wrote:
> I'd like to forward a bug report against the Debian packaged graphlan.

did you even check the error log? it's almost 100% an issue with
Debian matplotlib (which i'll look at it in the comings days)

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

Bug#917093: matplotlib2 breaks graphlan autopkgtest

[Andreas Tille]

Control: tags -1 help
Control: tags -1 upstream
Control: forwarded -1 Nicola Segata 

Hi Nicola,

I'd like to forward a bug report against the Debian packaged graphlan.
(I admit I have not found a way to report issues publicly on bitbucket.)

The packaged code is identical with tag 1.1.3 (Commit c1fa530).

Any hint how to make graphlan compatible with latest matplotlib?

Kind regards

   Andreas.

On Sat, Dec 22, 2018 at 03:17:57PM +0100, Paul Gevers wrote:
> 
> With a recent upload of matplotlib2 the autopkgtest of graphlan fails in
> testing when that autopkgtest is run with the binary packages of
> matplotlib2 from unstable. It passes when run with only packages from
> testing. In tabular form:
>passfail
> matplotlib2NA  2.2.3-4
> matplotlib from testingNA
> graphlan   from testing1.1.3-1
> all others from testingfrom testing
> 
> I copied some of the output at the bottom of this report.
> 
> Currently this regression is contributing to the delay of the migration
> of matplotlib2 (and matplotlib) to testing [1]. Due to the nature of
> this issue, I filed this bug report against both packages. Can you
> please investigate the situation and reassign the bug to the right
> package? If needed, please change the bug's severity.
> 
> More information about this bug and the reason for filing it can be found on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> 
> Paul
> 
> [1] https://qa.debian.org/excuses.php?package=matplotlib2
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/g/graphlan/1563802/log.gz
> 
> autopkgtest [04:48:34]: test run-unit-test: [---
> Test script ./hmp_metahit/PIPELINE.sh requires export2graphlan which is
> not available.
> Running test script ./gut_microbiome/run.sh .
> /usr/lib/python2.7/dist-packages/matplotlib/__init__.py:1005:
> UserWarning: could not find rc file; returning defaults
>   warnings.warn(message)
> Traceback (most recent call last):
>   File "/usr/bin/graphlan_annotate", line 26, in 
> from src.graphlan_lib import CircTree as CTree
>   File "/usr/share/graphlan/src/graphlan_lib.py", line 27, in 
> from pylab import *
>   File "/usr/lib/python2.7/dist-packages/pylab.py", line 1, in 
> from matplotlib.pylab import *
>   File "/usr/lib/python2.7/dist-packages/matplotlib/pylab.py", line 252,
> in 
> from matplotlib import cbook, mlab, pyplot as plt
>   File "/usr/lib/python2.7/dist-packages/matplotlib/pyplot.py", line 31,
> in 
> import matplotlib.colorbar
>   File "/usr/lib/python2.7/dist-packages/matplotlib/colorbar.py", line
> 36, in 
> import matplotlib.contour as contour
>   File "/usr/lib/python2.7/dist-packages/matplotlib/contour.py", line
> 20, in 
> import matplotlib.font_manager as font_manager
>   File "/usr/lib/python2.7/dist-packages/matplotlib/font_manager.py",
> line 1472, in 
> _rebuild()
>   File "/usr/lib/python2.7/dist-packages/matplotlib/font_manager.py",
> line 1453, in _rebuild
> fontManager = FontManager()
>   File "/usr/lib/python2.7/dist-packages/matplotlib/font_manager.py",
> line 1057, in __init__
> paths = [os.path.join(rcParams['datapath'], 'fonts', 'ttf'),
>   File "/usr/lib/python2.7/posixpath.py", line 70, in join
> elif path == '' or path.endswith('/'):
> AttributeError: 'NoneType' object has no attribute 'endswith'
> /usr/lib/python2.7/dist-packages/matplotlib/__init__.py:1005:
> UserWarning: could not find rc file; returning defaults
>   warnings.warn(message)
> Traceback (most recent call last):
>   File "/usr/bin/graphlan", line 29, in 
> from src.graphlan_lib import CircTree as CTree
>   File "/usr/share/graphlan/src/graphlan_lib.py", line 27, in 
> from pylab import *
>   File "/usr/lib/python2.7/dist-packages/pylab.py", line 1, in 
> from matplotlib.pylab import *
>   File "/usr/lib/python2.7/dist-packages/matplotlib/pylab.py", line 252,
> in 
> from matplotlib import cbook, mlab, pyplot as plt
>   File "/usr/lib/python2.7/dist-packages/matplotlib/pyplot.py", line 31,
> in 
> import matplotlib.colorbar
>   File "/usr/lib/python2.7/dist-packages/matplotlib/colorbar.py", line
> 36, in 
> import matplotlib.contour as contour
>   File "/usr/lib/python2.7/dist-packages/matplotlib/contour.py", line
> 20, in 
> import matplotlib.font_manager as font_manager
>   File "/usr/lib/python2.7/dist-packages/matplotlib/font_manager.py",
> line 1472, in 
> _rebuild()
>   File "/usr/lib/python2.7/dist-packages/matplotlib/font_manager.py",
> line 1453, in _rebuild
> fontManager = FontManager()
>   File "/usr/lib/python2.7/dist-packages/matplotlib/font_manager.py",
> line 1057, in __init__
> paths = [os.path.join(rcParams['datapath'], 'fonts', 'ttf'),
>   File "/usr/lib/python2.7/posixpath.py", line 70, in join
> elif path == '' or path.endswith('/'):
> AttributeError: 'NoneType' object has no 

Bug#917113: libraw: CVE-2018-20363

[Salvatore Bonaccorso]

Source: libraw
Version: 0.19.1-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/LibRaw/LibRaw/issues/193

Hi,

The following vulnerability was published for libraw.

CVE-2018-20363[0]:
| LibRaw::raw2image in libraw_cxx.cpp in LibRaw 0.19.1 has a NULL pointer
| dereference.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-20363
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20363
[1] https://github.com/LibRaw/LibRaw/issues/193

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#878832: tbb: FTBFS on hppa: rml::pool_* undefined

[John David Anglin]

The problem is "arch" is not defined for hppa in linux.inc.

Regards,
Dave Anglin

-- 
John David Anglin  dave.ang...@bell.net

--- ./build/linux.inc.save  2014-11-17 22:21:52.674304007 -0500
+++ ./build/linux.inc   2014-11-17 22:25:35.916722257 -0500
@@ -70,6 +70,9 @@
 ifeq ($(uname_m),ppc)
 export arch:=ppc32
 endif
+ifeq ($(deb_host_arch),hppa)
+export arch:=hppa
+endif
 ifeq ($(deb_host_arch),x32)
 export arch:=x32
 endif
@@ -130,6 +133,9 @@
 ifeq ($(arch),armv7)
 def_prefix = lin32
 endif
+ifeq ($(arch),hppa)
+def_prefix = lin32
+endif
 ifeq (,$(def_prefix))
 ifeq (64,$(findstring 64,$(arch)))
 def_prefix = lin64

Bug#917112: libraw: CVE-2018-20364

[Salvatore Bonaccorso]

Source: libraw
Version: 0.19.1-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/LibRaw/LibRaw/issues/194

Hi,

The following vulnerability was published for libraw.

CVE-2018-20364[0]:
| LibRaw::copy_bayer in libraw_cxx.cpp in LibRaw 0.19.1 has a NULL
| pointer dereference.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-20364
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20364
[1] https://github.com/LibRaw/LibRaw/issues/194

Please adjust the affected versions in the BTS as needed.


Regards,
Salvatore

Bug#915407: ping

[Adam Borowski]

Hi!
Could you please either take this patch or propose a different approach?
I have received no feedback other than a brief unconclusive remark on IRC.

The clock for Buster is ticking; to get any testing we'd need to act soon.
Not only this approach has been proposed by one of systemd maintainers
(granted, more as a brainstorming than a definitive proposal from your team)
but it also has seen actual testable packages since January.

I admit that my own testing was extremely uneven -- mostly restricted to
environments I personally use -- but as the idea is opt-in for every
depender on libpam-systemd, packages no one claims to have tested simply
won't be usable without systemd.  Just like they're right now.

Thus: if package X and Y need APIs that elogind provides, they'd be changed
to:
Depends: default-logind | logind
while package Z that needs a "bring-me-pink-pony" function will not.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Ivan was a worldly man: born in St. Petersburg, raised in
⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned
⠈⠳⣄ to the city of his birth to die.

Bug#917111: libraw: CVE-2018-20365

[Salvatore Bonaccorso]

Source: libraw
Version: 0.19.1-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/LibRaw/LibRaw/issues/195

Hi,

The following vulnerability was published for libraw.

CVE-2018-20365[0]:
| LibRaw::raw2image() in libraw_cxx.cpp has a heap-based buffer overflow.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-20365
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20365
[1] https://github.com/LibRaw/LibRaw/issues/195

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#917110: ITP: satpy -- Python package for earth-observing satellite data processing

[Antonio Valentino]

Package: wnpp
Severity: wishlist
Owner: Antonio Valentino 

* Package name: satpy
  Version : 0.10.0
  Upstream Author : The Pytroll Team 
* URL : https://github.com/pytroll/satpy
* License : GPL-3+
  Description : Python package for earth-observing satellite data
processing

Binary package names: python3-satpy
 The SatPy package is a Python library for reading and manipulating
 meteorological remote sensing data and writing it to various image and
 data file formats. SatPy comes with the ability to make various RGB
 composites directly from satellite instrument channel data or higher
 level processing output. The pyresample package is used
 to resample data to different uniform areas or grids.

Bug#917109: opensc: Rutoken ECP card not work after upgrade

[Sergey Zhuravlev]

Package: opensc
Version: 0.16.0-3+deb9u1
Severity: normal

After upgrading opensc-0.16.0-3, opensc-pkcs11-0.16.0-3 to 
opensc-0.16.0-3+deb9u1, opensc-pkcs11-0.16.0-3+deb9u1 "Rutoken ECP" token not 
work:

$ pkcs11-tool -L
Available slots:
Slot 0 (0x0): Aktiv Rutoken ECP 00 00
  token state:   uninitialized

Card shows as uninitialized, but it was initizalied. Before upgrading card was 
working. After downgrading opensc, opensc-pkcs11 packages card also is working:

$ pkcs11-tool -L
Available slots:
Slot 0 (0x0): Aktiv Rutoken ECP 00 00
  token label: Rutoken ECP (User PIN)
  token manufacturer : Aktiv Co.
  token model: PKCS#15
  token flags: rng, login required, PIN initialized, token initialized
  hardware version   : 0.0
  firmware version   : 0.0
  serial num : X

Bug#870396: [Pkg-alsa-devel] Bug#870396: alsa-lib: fix SIGSEGV on x32 (and a minor typo in the testsuite)

[Thorsten Glaser]

(For alsa-de...@alsa-project.org I’ve attached the diffs this
eMail thread has been about, with hope you will apply them in
the next upstream release.)


Elimar Riesebieter dixit:

>it seems that you are an exclusive user of the x32 port ;-) Please

If you actually read that thread you’d know I’m not. (I wrote some
eMails to it, too.)

>Does it really make sense to maintain code for a handful of users?

It’s nothing architecture-specific if I recall, so it will reduce
the chance of problems for all users.

Lemme dissect the patch…

0009-fix-format-strings.patch: fixes, basically, this…

printf("%ld", some_long_long_value);

… which is always an error, on platforms where time_t is larger
than long (which is currently all *64ilp32 platforms (there’s
x32, amd64ilp32, and a third one I forgot, already in existence),
but *will* encompass all ILP32 architectures as we get closer to
the year 2038).

0010-fix-testcase-typo.patch: not actually x32-related, but
noticed during porting.

0011-distinguish-x32-from-amd64.patch: this is the most important
one, and it’s a frigging oneliner:

-#elif defined(__x86_64__)
+#elif defined(__x86_64__) && !defined(__ILP32__)

This one literally only affects x32, indeed (so what I said above
was proven misremembered) but it’s obviously non-harmful to anything
else and easy to carry and forward.

So I’d wish you’d do that as it’s your duty as maintainer of a Debian
package, but alas… I’ll Cc the eMail address you told me and hope
that someone picks it up.

Blessed yuletide,
//mirabilos
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2# DP: fix long vs. long long confusion when there is a 64-bit time_t
# DP: on a 32-bit long system, such as all newer 32-bit architectures

--- a/src/pcm/pcm.c
+++ b/src/pcm/pcm.c
@@ -2257,11 +2257,11 @@ int snd_pcm_status_dump(snd_pcm_status_t
 {
assert(status);
snd_output_printf(out, "  state   : %s\n", 
snd_pcm_state_name((snd_pcm_state_t) status->state));
-   snd_output_printf(out, "  trigger_time: %ld.%06ld\n",
- status->trigger_tstamp.tv_sec,
- status->trigger_tstamp.tv_nsec / 1000);
-   snd_output_printf(out, "  tstamp  : %ld.%06ld\n",
-   status->tstamp.tv_sec, status->tstamp.tv_nsec / 1000);
+   snd_output_printf(out, "  trigger_time: %lld.%06ld\n",
+ (long long)status->trigger_tstamp.tv_sec,
+ (long)status->trigger_tstamp.tv_nsec / 1000L);
+   snd_output_printf(out, "  tstamp  : %lld.%06ld\n",
+   (long long)status->tstamp.tv_sec, (long)status->tstamp.tv_nsec 
/ 1000L);
snd_output_printf(out, "  delay   : %ld\n", (long)status->delay);
snd_output_printf(out, "  avail   : %ld\n", (long)status->avail);
snd_output_printf(out, "  avail_max   : %ld\n", 
(long)status->avail_max);
--- a/test/latency.c
+++ b/test/latency.c
@@ -325,12 +325,12 @@ void setscheduler(void)
printf("!!!Scheduler set to Round Robin with priority %i FAILED!!!\n", 
sched_param.sched_priority);
 }
 
-long timediff(snd_timestamp_t t1, snd_timestamp_t t2)
+long long timediff(snd_timestamp_t t1, snd_timestamp_t t2)
 {
-   signed long l;
+   signed long long l;
 
t1.tv_sec -= t2.tv_sec;
-   l = (signed long) t1.tv_usec - (signed long) t2.tv_usec;
+   l = (signed long long) t1.tv_usec - (signed long long) t2.tv_usec;
if (l < 0) {
t1.tv_sec--;
l = 100 + l;
@@ -682,10 +682,10 @@ int main(int argc, char *argv[])
snd_pcm_nonblock(phandle, !block ? 1 : 0);
if (ok) {
 #if 1
-   printf("Playback time = %li.%i, Record time = %li.%i, 
diff = %li\n",
-  p_tstamp.tv_sec,
+   printf("Playback time = %lli.%i, Record time = %lli.%i, 
diff = %lli\n",
+  (long long)p_tstamp.tv_sec,
   (int)p_tstamp.tv_usec,
-  c_tstamp.tv_sec,
+  (long long)c_tstamp.tv_sec,
   (int)c_tstamp.tv_usec,
   timediff(p_tstamp, c_tstamp));
 #endif
--- a/test/queue_timer.c
+++ b/test/queue_timer.c
@@ -99,11 +99,11 @@ main(int argc ATTRIBUTE_UNUSED, char **a
normalize();
prevdiff = diff;
 
-   fprintf(stderr, " real time: %12ld sec %8ld usec\nqueue time: %12ld sec 
%8ld usec\n  diff: %12ld sec %8ld usec\n  diffdiff: %12ld sec %8ld usec\n",
-   tv.tv_sec, tv.tv_usec,
-   (long)rtime->tv_sec, (long)rtime->tv_nsec / 1000,
-   diff.tv_sec, diff.tv_usec,
-   (long)diffdiff.tv_sec, (long)diffdiff.tv_usec);
+   fprintf(stderr, " real time: 

Bug#886112: (no subject)

[Joseph Spiros]

I also ran into this problem, after selectively upgrading calendarserver only. 
If it helps, I narrowed the fix on my system to upgrading python-sqlparse from 
version 0.1.13-2 (the version I had installed when encountering the error) to 
0.2.4-1 (the current version in testing and unstable). It's certainly possible 
that some intermediate version of python-sqlparse might be sufficient to fix 
this problem, but I haven't looked into it.

-- 
Joseph Spiros
jos...@josephspiros.com

Bug#914129: not iptables related, it's docker that needs updating

[Arnaud Rebillout]

See the bug opened against the package docker.io:

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

(I'm not sure if these two bugs should be merged, as I'm not so familiar
with the BTS)

  Arnaud

Bug#913723: please confirm that dictionaries should move to section localization

[Jonas Smedegaard]

Hi Guillem,

Quoting Guillem Jover (2018-12-22 18:58:04)
> On Sun, 2018-12-02 at 15:48:53 +0100, Jonas Smedegaard wrote:
> > Quoting Guillem Jover (2018-12-02 15:17:02)
> > > On Sun, 2018-11-18 at 05:44:42 -0500, Chris Lamb wrote:
> > > > Could you propose a patch that would fix this to your 
> > > > satisfaction?
> > > > I'm having a little difficulty sorting this out in my head now 
> > > > after applying, reverting, etc. etc. :)
> > > 
> > > If you ask me personally, I think lintian is fine as it is! I'd 
> > > probably just update the section descriptions to clarify this, and 
> > > prepare a mass override request for ftp-masters. But I'd like to 
> > > hear from the reporters and others who complained about the secion 
> > > change to know whether they have been convinced by the arguments? 
> > > :)
> > 
> > Since you ask: No, I am not convinced by your arguments.
> 
> Ok, I'm still curious about why? :)

It seems your argument is essentially that a dictionary locale-specific.

I firmly believe that the current use of package section "locale" is for 
"Localization support for big software packages" (as argued earlier) - 
i.e. the specific use of the word "locale" related tied to 
"internationalization and localization".

I am not convinced that Debian should change to instead have that 
package section cover a different more loose definition of "locale".

Geographical maps and accounting ledger systems and text editors (those 
optimized not for computer code but for human prose) are all 
locale-specific, but not specific to the process of localization.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#911808: upstream bug

[Arnaud Rebillout]

On Fri, 09 Nov 2018 18:41:18 -0500 Jason Woofenden 
wrote:
> Hi Maintainer,
>
> I found the upstream bug forthe "chain 'DNAT' does not exist" bug:
>
> https://github.com/moby/moby/issues/38099
>
> WORKAROUND:
> update-alternatives --config iptables
> choose iptables-legacy
>
> --
> Jason
>
>

Thanks for the report Jason! I imported the upstream patch.

Dmitry, I pushed the change on master, can you please confirm that it
looks good, and do the upload? I built and tested the package, it works
for me.

Thanks,

  Arnaud