Bug#911657: pngcheck: check with zlib strict inflate

[Kevin Ryde]

Package: pngcheck
Version: 2.3.0-7
Severity: wishlist
File: /usr/bin/pngcheck

pngcheck does not detect some cases of bad "window bits" size in the png
file.  For example,

https://www.gutenberg.org/files/16713/16713-h/images/q169b2.png
(attached below, in case rectified soon)

pnginfo -d q169b2.png
=> libpng error: IDAT: invalid distance too far back

pngcheck q169b2.png
=> succeeds

whereas I hoped pngcheck would fail.

This is the IDAT "window bits" CINFO too small for what the data
actually needs.  pngcheck inflates into a big output buffer and zlib by
default makes use of that, thereby tolerating the problem.

It'd be good if pngcheck used a copy of zlib compiled with its
INFLATE_STRICT option, so as to detect the problem.

Dunno if configury for a suitable copy of zlib would be easy or hard.
I tried a byte-by-byte wrapper which gets the same effect with normal
zlib, but is much less efficient of course.

--- pngcheck.c.orig	2007-07-08 16:23:31.0 +1000
+++ pngcheck.c	2018-10-23 17:36:13.0 +1100
@@ -1011,6 +1011,26 @@
 }
 
 
+/* strict_inflate() same as inflate() but enforcing window size in the
+   manner of zlib compiled with its INFLATE_STRICT option.  Normally
+   inflate() tolerates window size too small if the output buffer is big
+   enough that it contains the needed data.  Going byte by byte here ensures
+   the output buffer isn't and thus window size too small is detected.
+   ENHANCE-ME: Better to use the zlib INFLATE_STRICT option.
+ */
+int strict_inflate(z_stream *z, int flush)
+{
+  /* "extra" is the part of avail_out not presented to inflate() */
+  int err;
+  do {
+uInt extra = (z->avail_out ? z->avail_out - 1 : 0);
+z->avail_out -= extra;
+err = inflate(z, flush);
+z->avail_out += extra;
+  } while (err == Z_OK && z->avail_in > 0 && z->avail_out > 0);
+  return err;
+}
+
 
 int pngcheck(FILE *fp, char *fname, int searching, FILE *fpOut)
 {
@@ -1807,7 +1827,7 @@
 
 while (err != Z_STREAM_END && zstrm.avail_in > 0) {
   /* know zstrm.avail_out > 0:  get some image/filter data */
-  err = inflate(&zstrm, Z_SYNC_FLUSH);
+  err = strict_inflate(&zstrm, Z_SYNC_FLUSH);
   if (err != Z_OK && err != Z_STREAM_END) {
 printf("%s  zlib: inflate error = %d (%s)\n",
   verbose > 1? "\n  " : (verbose == 1? "  ":fname), err,

Bug#911582: emacspeak does'nt work after upgrading emacs

[Michelangelo Rodriguez]

On Mon, 22 Oct 2018, Samuel Thibault wrote:


Control: tags -1 + unreproducible

Hello,

Michelangelo Rodriguez, le lun. 22 oct. 2018 10:04:57 +0200, a ecrit:

after upgrading emacs in unstable, emacsen-common install script for emacspeak 
exits because flavour emacs is not accepted by script.


I can not reproduce this. Could you run

dpkg -l \*emacs\*

so we can make sure which emacs things you have?

Samuel


Hello,
this is the output of dpkg -l \*emacs\*:
Voluto=U (non noto)/I (installato)/R (rimosso)/P (rimosso totale)/H (in attesa)
| Stato=Non/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(nessuno)/R (reinstallazione richiesta) (Stato,Err: maiuscolo=grave)
||/ NomeVersione Architettura Descrizione
+++-===---==
rc  cxref-emacs 1.6e-3   all  Generates LaTeX and HTML 
documentation for C programs
ii  emacs   1:25.2+1-11  all  GNU Emacs editor 
(metapackage)
ii  emacs-bin-common1:25.2+1-11  amd64GNU Emacs editor's 
shared, architecture dependent files
un  emacs-calfw (nessuna descrizione 
disponibile)
ii  emacs-common1:25.2+1-11  all  GNU Emacs editor's 
shared, architecture independent infrastructure
un  emacs-common-non-dfsg   (nessuna descrizione 
disponibile)
ii  emacs-el1:25.2+1-11  all  GNU Emacs LISP (.el) files
un  emacs-gtk   (nessuna descrizione 
disponibile)
ii  emacs-lucid 1:25.2+1-11  amd64GNU Emacs editor (with 
Lucid GUI support)
un  emacs-nox   (nessuna descrizione 
disponibile)
un  emacs-snapshot  (nessuna descrizione 
disponibile)
un  emacs19 (nessuna descrizione 
disponibile)
un  emacs20 (nessuna descrizione 
disponibile)
un  emacs21 (nessuna descrizione 
disponibile)
un  emacs21-common  (nessuna descrizione 
disponibile)
un  emacs22 (nessuna descrizione 
disponibile)
un  emacs22-common  (nessuna descrizione 
disponibile)
un  emacs23 (nessuna descrizione 
disponibile)
un  emacs23-common  (nessuna descrizione 
disponibile)
un  emacs24 (nessuna descrizione 
disponibile)
un  emacs24-bin-common  (nessuna descrizione 
disponibile)
un  emacs24-common  (nessuna descrizione 
disponibile)
un  emacs25 (nessuna descrizione 
disponibile)
un  emacs25-bin-common  (nessuna descrizione 
disponibile)
un  emacs25-common  (nessuna descrizione 
disponibile)
ii  emacs25-common-non-dfsg 25.2+1-1 all  GNU Emacs common non-DFSG 
items, including the core documentation
un  emacsen (nessuna descrizione 
disponibile)
ii  emacsen-common  3.0.4all  Common facilities for all 
emacsen
ii  emacspeak   47.0+dfsg-1  all  speech output interface 
to Emacs
ii  emacspeak-espeak-server 47.0+dfsg-1  amd64espeak synthesis server 
for emacspeak
un  emacspeak-ss(nessuna descrizione 
disponibile)
un  xemacs21(nessuna descrizione 
disponibile)
un  xemacs21-bin(nessuna descrizione 
disponibile)
un  xemacs21-support(nessuna descrizione 
disponibile)
Thanks in advance,
Michelangelo

Bug#699087:

[Raju Bhai]

Bug#909919: pngcheck: pngcheck man page on libpng 1.2.6 window bits

[Kevin Ryde]

Actually, I see pngfix can do a fix the same or better and is packaged
in libpng-tools.  Replacement diff referring to that one,

--- pngcheck.1.pod.orig	2013-06-26 19:28:27.0 +1000
+++ pngcheck.1.pod	2018-10-23 17:31:10.0 +1100
@@ -86,6 +86,11 @@
 
 test verbosely (print most chunk data).
 
+=item B<-w>
+
+Decompress IDAT chunks using maximum window, ignoring the "window bits"
+size specified in the header.
+
 =item B<-x>
 
 Search for PNGs and extract them when found.
@@ -110,6 +115,27 @@
 is a command-line program with batch capabilities (e.g., pngcheck
 *.png).
 
+=head1 Window Bits
+
+Libpng 1.2.6 from 2004 had a bug where, under certain circumstances,
+it wrote IDAT compressed data with CINFO "window bits" header value
+too small.  The compressed data is perfectly good, but requires a
+bigger window for decompressing than the header says.  Affected files
+fail the full C due to "zlib data error" but pass
+C.
+
+C also detects this problem, and can fix it by adjusting the
+header to what's needed.  The pngcheck sources include a
+F program making a similar fix (but only to
+maximum window).
+
+The problem was not as bad as it sounds because programs ignoring the
+header size and decoding with maximum window (32 kbyte) read ok.
+Libpng 1.2 and 1.4 always used maximum.  Libpng 1.6, in its default
+configuration, uses the header size so might not read.  Files with the
+problem should be rare but the forgiving nature of libpng 1.2 and 1.4
+may have let them go unnoticed for some time.
+
 =head1 ENVIRONMENT
 
 None.
@@ -125,6 +151,7 @@
 pngcomp(1)
 pngcp(1)
 pngcrush(1)
+pngfix(1)
 pnginfo(1)
 pngmeta(1)
 pngnq(1)

Bug#911656: munin-plugins-core: postgres_x_ALL plugins produce 'FATAL: database "munin" does not exist' errors

[Vincas Dargis]

Package: munin-plugins-core
Version: 2.0.37-1~bpo9+1
Severity: normal

Dear Maintainer,

I have upgraded munin from sretch-backports, to overcome incompatibilites with 
PostgreSQL 10:

```
# apt-cache policy munin-node munin-plugins-core | fgrep Installed
  Installed: 2.0.37-1~bpo9+1
  Installed: 2.0.37-1~bpo9+1
```

But just after installation, PostgreSQL (9.6 and 10) clusters started to 
accumualte spam:

```
2018-10-19 16:26:20 EEST [unknown] munin munin [local] FATAL:  database "munin" 
does not exist
2018-10-19 16:26:20 EEST [unknown] munin munin [local] FATAL:  database "munin" 
does not exist
2018-10-19 16:26:20 EEST [unknown] munin munin [local] FATAL:  database "munin" 
does not exist
2018-10-19 16:26:21 EEST [unknown] munin munin [local] FATAL:  database "munin" 
does not exist
2018-10-19 16:26:21 EEST [unknown] munin munin [local] FATAL:  database "munin" 
does not exist
```
munin-node.log contains:

```
2018/10/19-16:26:20 [3780] Error output from postgres_locks_ALL:
2018/10/19-16:26:20 [3780]  Use of uninitialized value $dbname in 
concatenation (.) or string at /usr/share/perl5/Munin/Plugin/Pgsql.pm line 430.
2018/10/19-16:26:20 [3780]  DBI connect('dbname=','',...) failed: FATAL:  
database "munin" does not exist at /usr/share/perl5/Munin/Plugin/Pgsql.pm line 
430.
2018/10/19-16:26:20 [3780] Service 'postgres_locks_ALL' exited with status 1/0.

2018/10/19-16:26:20 [3780] Error output from postgres_querylength_ALL:
2018/10/19-16:26:20 [3780]  Use of uninitialized value $dbname in 
concatenation (.) or string at /usr/share/perl5/Munin/Plugin/Pgsql.pm line 430.
2018/10/19-16:26:20 [3780]  DBI connect('dbname=','',...) failed: FATAL:  
database "munin" does not exist at /usr/share/perl5/Munin/Plugin/Pgsql.pm line 
430.
2018/10/19-16:26:20 [3780] Service 'postgres_querylength_ALL' exited with 
status 1/0.

2018/10/19-16:26:21 [3780] Error output from postgres_cache_ALL:
2018/10/19-16:26:21 [3780]  Use of uninitialized value $dbname in 
concatenation (.) or string at /usr/share/perl5/Munin/Plugin/Pgsql.pm line 430.
2018/10/19-16:26:21 [3780]  DBI connect('dbname=','',...) failed: FATAL:  
database "munin" does not exist at /usr/share/perl5/Munin/Plugin/Pgsql.pm line 
430.
2018/10/19-16:26:21 [3780] Service 'postgres_cache_ALL' exited with status 1/0.

2018/10/19-16:26:21 [3780] Error output from postgres_connections_ALL:
2018/10/19-16:26:21 [3780]  Use of uninitialized value $dbname in 
concatenation (.) or string at /usr/share/perl5/Munin/Plugin/Pgsql.pm line 430.
2018/10/19-16:26:21 [3780]  DBI connect('dbname=','',...) failed: FATAL:  
database "munin" does not exist at /usr/share/perl5/Munin/Plugin/Pgsql.pm line 
430.
2018/10/19-16:26:21 [3780] Service 'postgres_connections_ALL' exited with 
status 1/0.

2018/10/19-16:26:22 [3780] Error output from postgres_size_ALL:
2018/10/19-16:26:22 [3780]  Use of uninitialized value $dbname in 
concatenation (.) or string at /usr/share/perl5/Munin/Plugin/Pgsql.pm line 430.
2018/10/19-16:26:22 [3780]  DBI connect('dbname=','',...) failed: FATAL:  
database "munin" does not exist at /usr/share/perl5/Munin/Plugin/Pgsql.pm line 
430.
2018/10/19-16:26:22 [3780] Service 'postgres_size_ALL' exited with status 1/0.
```

My config:

```
# cat /etc/munin/plugin-conf.d/postgresql
[postgres_*]
user munin
env.PGHOST /var/run/postgresql
```

There where no issues like that with previous 2.0.33-1 version.

Any ideas on how to work-around it? Our DBA is not happy very much :) .

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

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

Versions of packages munin-plugins-core depends on:
ii  munin-common  2.0.37-1~bpo9+1
ii  perl  5.24.1-3+deb9u4

Versions of packages munin-plugins-core recommends:
ii  libnet-snmp-perl  6.0.1-2

Versions of packages munin-plugins-core suggests:
ii  bc   1.06.95-9+b3
ii  conntrack1:1.4.4+snapshot20161117-5
pn  libcache-cache-perl  
pn  libdbd-mysql-perl
pn  libnet-dns-perl  
pn  libnet-netmask-perl  
pn  libnet-telnet-perl   
pn  libxml-parser-perl   
ii  python   2.7.13-2
pn  ruby | ruby-interpreter  
pn  time 

-- no debconf information

Bug#911650: [developers-reference] usage of dh_strip conflicts with debhelper documentation

[Joseph Herlant]

Hi Tobias! :)

On Mon, Oct 22, 2018 at 10:43 PM Tobias Frost  wrote:
> I think that would be great; my (related) merge request
> https://salsa.debian.org/debian/developers-reference/merge_requests/7
> misses the information what to do when you mirgrate from manual to
> automatic debug packages.
> If you could extend this MR, that would be great ;-) TIA!

Sorry I didn't see the MR and related bug report before filing this
one and got sidetracked after.
Sure, I'll extend your MR tomorrow.

Thanks! :)
Joseph

Bug#888527: RFS: hollywood/1.12-1 [ITP]

[Yangfl]

Boyuan Yang  于2018年10月21日周日 上午11:39写道：
>
> X-Debbugs-CC: mmyan...@gmail.com
> Control: tag -1 + moreinfo
>
> The package looks fine but there's several missing points:
>
> * Please add copyright information for debian/ directory.
> * Please consider updating to the latest upstream release (1.14).
> * Please use secure uri in debian/copyright file.
>
> Please notify me after those problems get fixed.
>
> --
> Regards,
> Boyuan Yang

New version has been uploaded to m.d.o. Thank you.

Bug#911655: AX_PATH_BDB_NO_OPTIONS makes broken assumptions for cross compilation

[Helmut Grohne]

Package: autoconf-archive
Version: 20170928-2
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:moc

The AX_PATH_BDB_NO_OPTIONS is broken for cross compilation and that
breaks moc. The macro assumes that $ac_cpp does not emit #line markers.
For native compilation, $ac_cpp will be "cpp" and that assumption is ok.
For cross compilation, it will be "-gcc -E" and that one emits
#line markers. The macro inserts a line

AX_PATH_BDB_STUFF DB_VERSION_MAJOR,DB_VERSION_MINOR,DB_VERSION_PATCH

and then tries to parse what comes back from the preprocessor. In the
cross compilation, that line is split up into many lines and the parsing
fails.

If you do not want #line markers, you must pass -P to $ac_cpp. The
attached patch implements that.

Helmut
--- autoconf-archive-20170928.orig/m4/ax_path_bdb.m4
+++ autoconf-archive-20170928/m4/ax_path_bdb.m4
@@ -179,7 +179,7 @@
   ]])
 ],[
   # Extract version from preprocessor output.
-  HEADER_VERSION=`eval "$ac_cpp conftest.$ac_ext" 2> /dev/null \
+  HEADER_VERSION=`eval "$ac_cpp -P conftest.$ac_ext" 2> /dev/null \
 | grep AX_PATH_BDB_STUFF | sed 's/[[^0-9,]]//g;s/,/./g;1q'`
 ],[])
 

Bug#911621: Re : [Pkg-utopia-maintainers] Bug#911621: Re : Bug#911621: network-manager: crash since last apt upgrade

[nicolas . patrois]

Le 22/10/2018 21:45:31, Michael Biebl a écrit :

> Yes, it's called network-manager-dbgsym
> You probably also want to install dbgsym packages for libnm0,
> libglib2.0-0

Sorry, there is no such package in my Debian Sid. :-(

nicolas patrois : pts noir asocial
-- 
RÉALISME

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

Bug#911654: xsensors FTCBFS: uses the wrong pkg-config

[Helmut Grohne]

Source: xsensors
Version: 0.70-3
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

xsensors fails to cross build from source. After checking for gtk with
the proper macros, ./configure.in resorts to calling plain pkg-config.
That's the build architecture pkg-config and it will not find gtk.
Rather, I propose using the results from the previous checks. Doing so
makes xsensors cross buildable. Please consider applying the attached
patch. Please don't forget to rebuild configure as the packaging doesn't
do that by default.

Helmut
--- xsensors-0.70.orig/configure.in
+++ xsensors-0.70/configure.in
@@ -28,8 +28,8 @@
 *** development headers installed. The latest version of GTK+ is
 *** always available at http://www.gtk.org/.]))
 
-XSENSORS_CFLAGS="`pkg-config --cflags gtk+-2.0` -Werror"
-XSENSORS_LIBS="`pkg-config --libs gtk+-2.0`"
+XSENSORS_CFLAGS="$GTK_CFLAGS -Werror"
+XSENSORS_LIBS="$GTK_LIBS"
 AC_SUBST(XSENSORS_CFLAGS)
 AC_SUBST(XSENSORS_LIBS)
 

Bug#911650: [developers-reference] usage of dh_strip conflicts with debhelper documentation

[Tobias Frost]

Hi Josheph,

On Mon, Oct 22, 2018 at 07:31:58PM -0700, Joseph Herlant wrote:
> Package: developers-reference
> Version: 3.4.21
> Severity: normal
> 
> Hi,
> 
> Based on the man page of dh_strip[1], "the `--dbg-package` option is a
> now special purpose option that you normally do not need" which
> contradicts with the paragraph 6.7.9. )Best practices for debug
> packages) of the developers reference.
> 
> If I understand correctly we should say smoething like the wiki [3] says:
> If you use debhelper/9.20151219 or newer in Debian, it will generate
> debug symbol packages (as -dbgsym) for you with no additional
> changes to your source package.
> If you want to transition from a former -dbg package to a -dbgsym
> package you might want to look into the dh_strip's switch
> --dbgsym-migration=pkgname-dbg (<< currentversion~)' switch.
> 
> Am I correct assuming that it's the right thing to recommend?
> 
> If yes, I'll go ahead and do a merge request for that.

I think that would be great; my (related) merge request 
https://salsa.debian.org/debian/developers-reference/merge_requests/7
misses the information what to do when you mirgrate from manual to
automatic debug packages.
If you could extend this MR, that would be great ;-) TIA!

Cheers, 
tobi

Thanks a lot!

> Thanks
> Joseph
> 
> 1. https://manpages.debian.org/unstable/debhelper/dh_strip.1.en.html
> 2. https://www.debian.org/doc/manuals/developers-reference/ch06.html
> 3. https://wiki.debian.org/DebugPackage
> 


signature.asc
Description: PGP signature

Bug#710511: alpine: passfile support (-passfile) seems completely broken

[Antos Andras]

Dear Eduardo,

Thank you very much for you quick reply and your work on Alpine!

On Wed, 10 Oct 2018, Eduardo Chappa wrote:

On Wed, 10 Oct 2018, Antos Andras wrote:
Here Debian Alpine 2.20 does not core dump/segfault/crash, but the 
password is still saved only if the passfile already exists (and same 
with Alpine 2.21 in CentOS).
From the mail above, it seems this is intended, so rather a feature not a 
bug, but this does not seem to be documented anywhere (apart from internet 
forums), and alpine does not give any hint about this when it happens.


 There is some documentation on password file support, which explains a 
little bit about this issue. You can find it from the Main screen, press 
"R" to read the release notes, and look for the link to the password 
file support there.


Yes, I found there some documentation, but only about SMIME support, 
certificate/key pair, and Disable saving new passwords.


I understand that security is important and saving passwords should not 
be the default behavior when it is not expected. However, e.g., 
launching alpine by the -passfile option (even with a nonexisting file) 
the user's expectation is to use it, not silently ignore it, 
especially, suggested by the help of Alpine saying:

-passfile 
Set the password file to something other than the default


I imagine that here we disagree about the meaning of what it means to 
start a program with a non-existing file. If I start an editor with a 
path to a non-existing file, the editor will create that file, but if I 
start a web broser with a path to a non-existent file, I will not get a 
meaningful startup. The purpose of the -passfile option is to use an 
existing file as the place to save passwords. Alpine does not create 
password files on behalf of users.


Yes, you are right we somewhat disagree in that.
I think the web broser is not a good analogy (it is only for loading, not
changing web pages - mostly not owned by the user, while alpine is for
using and changing password files). The editor is the good analogy, or 
that e.g.

$ alpine -p .mypinerc
creats non-existing .mypinerc file. Also Alpine happily creats
non-existing sent-mail or saved-messages folders.
The password file is usually a hidden "dot file", most end-user should not
care about directly.
I do not really think it is less secure if Alpine would ask whether to
save the password and then also warn/ask confirmation if the new passfile
have to be created, than if its behavior depends on whether the passfile 
exists.

Anyway, I can live with the latter behavior, of course, but the fact that
is not documented and Alpine does not warn why the password does not get 
saved, I consider a bug. Forums are full of sad user asking for help in 
this till they get the hint on touch .passfile. Why could not Alpine give 
this hint?


(Btw, either the default password file, which seems to vary among 
versions and distributions, does not seem to be documented anywhere 
around alpine, and should be traced by strace or string.)


There is no default password file, there is the one that people compile 
into Alpine. If the Debian distributor compiles such support, they 
should let users know what they built into it.


"Set the password file to something other than the default"
"There is no default password file"
seems somewhat contradicting. But, OK, this is from the upsteam source 
author's point. Note that most end user get Alpine as compiled binary with

a default.
You are right that Debian should let users know what they built in, and
now I found they did: in README.Debian file it is written:

"== Passfile ==

The washington.edu developers of Alpine and Pine have a feature they 
implemented but don't like called "passfile".  This lets users store their 
passwords in a file so they don't have to type it each time they run the 
mail program.  This feature is similar to "Save password" features in 
Thunderbird, Icedove, Evolution, and other mail user agents that are or 
have been in Debian.


In this package, the file ~/.pine-passfile is where Alpine stores its
obfuscated password.

NOTE: If you save your password here, and someone else can get a copy of 
this file, then that person has your password!"


I wonder whether Thunderbird or Evolution care about if their password 
files already pre-exist at their "Save password" features.


Besides stracing or using "string" you can run Alpine with debug level 
-9 to see the password file name in the .pine-debug file. I do not know 
if Debian compiles debug files support into its distribution, but that 
is a way to know it.


Thank you for this. Yes, it seems to work on Debian & Ubuntu with file 
.pine-debug1.


Also, here https://github.com/termux/termux-packages/issues/2023 one 
finds reasonable complains about mandatory "master password" (password 
for S/MIME key?) demonstrating that all in all the decision between 
convenience and security should be left to the user's discretion with 
reasonable defaults (e

Bug#911653: Please recommend or suggest the "nocache" package

[Dato Simó]

Package: mlocate
Version: 0.26-2

The daily cron script uses nocache if it's available. Since it's a
useful addition, it would make sense for mlocate to recommend it.

Thanks,

-d

Bug#909926: multipath-tools: multipath segfaults regularily (Bug #909926)

[Ritesh Raj Sarraf]

Hello Bernhard,

On Mon, 2018-10-22 at 20:45 +0200, Bernhard Übelacker wrote:
> 
> This looks like it got fixed upstream in patch [1].
> At least a version 0.7.7-3 built with this patch does not crash like
> before.

Thanks for looking into this bug. I'm glad you were able to reproduce
it in your setup.

Version 0.7.7-3 is already in the Debian Testing/Unstable archive, but
it does not have that change. Are you in a position to try the patch
out and confirm if it really mitigates the problem ? That'll help.

Meanwhile, I'll also try to package the newer 0.7.8 release, which
should contain the fix, as you have mentioned.


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


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

Bug#870641: light-locker: screen stays black after closing and opening laptop lid

[Jeremiah Mahler]

Package: light-locker
Version: 1.8.0-2
Followup-For: Bug #870641

Hi,

I am experiencing this problem and I found a workaround ...

If I lock the screen it goes black and won't unlock from the
keyboard.  If I ssh to the machine I can restart lightdm and
get a login prompt.

$ light-locker-command --lock
(goes black, can't wakeup)

If I create an Xorg config file that says to use the Intel
driver it works.

$ cat /etc/X11/xorg.conf.d/20-intel.conf 
Section "Device"
  Identifier"Intel Graphics"
  Driver"intel"
EndSection

Perusing the /var/log/Xorg.0.log finds that it was using the
fbdev driver before.

Here is the info on from my card.

$ lspci -v
[...]
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 520 (rev 07) 
(prog-if 00 [VGA controller])
Subsystem: Lenovo Skylake GT2 [HD Graphics 520]
Flags: bus master, fast devsel, latency 0, IRQ 126
Memory at f000 (64-bit, non-prefetchable) [size=16M]
Memory at e000 (64-bit, prefetchable) [size=256M]
I/O ports at e000 [size=64]
[virtual] Expansion ROM at 000c [disabled] [size=128K]
Capabilities: [40] Vendor Specific Information: Len=0c 
Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 2
Capabilities: [100] Process Address Space ID (PASID)
Capabilities: [200] Address Translation Service (ATS)
Capabilities: [300] Page Request Interface (PRI)
Kernel driver in use: i915
Kernel modules: i915
[...]

If I can do anything else to help debug this issue, let me know.


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

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

Versions of packages light-locker depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.0-1
ii  libc62.27-6
ii  libcairo21.16.0-1
ii  libdbus-1-3  1.12.10-1
ii  libdbus-glib-1-2 0.110-3
ii  libglib2.0-0 2.58.1-2
ii  libgtk-3-0   3.24.1-2
ii  libpango-1.0-0   1.42.4-3
ii  libpangocairo-1.0-0  1.42.4-3
ii  libsystemd0  239-10
ii  libx11-6 2:1.6.7-1
ii  libxext6 2:1.3.3-1+b2
ii  libxss1  1:1.2.3-1
ii  lightdm  1.26.0-3

light-locker recommends no packages.

light-locker suggests no packages.

-- no debconf information

Bug#911652: inkscape: crashes on shift+click with ellipse or rectangle

[beuc]

Package: inkscape
Version: 0.92.3-5+b1
Severity: normal

Dear Maintainer,

The current Debian package is affected by the annoying bug described at:
https://bugs.launchpad.net/inkscape/+bug/1522085

I attached a patch to that bug report.
(I contributed to the Ubuntu bug as it's referenced at upstream's
http://wiki.inkscape.org/wiki/index.php/1.0_Release_Bug_Fix_List)

Cheers!
Sylvain

Bug#908489: Likely fixed in 2.5.0

[Olek Wojnar]

This bug should have been fixed in version 2.5.0 per this upstream issue
tracker [1]. Since that version is currently in Debian, this bug is
probably safe to close.

[1] https://gitlab.freedesktop.org/geoclue/geoclue/issues/84

Bug#911651: apt: aptitude sync: add why command to apt for dependency chain detective work

[Paul Wise]

Package: apt
Version: 1.7.0
Severity: wishlist

It would be nice to have the why synced from aptitude.
It takes either one or two binary package names.

If launched with one package it discovers why it is installed by
looking at the auto/manual status of the package and the status of
other packages that depend on it and so on recursively until it finds a
manually installed package for the root of the dependency chain.

$ aptitude why gnome-shell
i   gnome-shell-dbgsym Depends gnome-shell (= 3.30.1-2)

If launched with two packages it tries to discover a dependency chain
from the first package to the second package.

$ aptitude why gnome gnome-shell
i A gnome  Depends gnome-core (= 1:3.22+11)
i A gnome-core Depends gnome-shell (>= 3.22)   

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#911446: diffoscope: pdf comparator no longer diffing metadata

[Chris Lamb]

tags 911446 + pending
thanks

Hi Reiner,

> I just noticed on some packages on tests.r-b.o with PDF differences that
> metadata like /CreationDate and /ID are no longer shown as a plaintext
> diff, but as a binary/hex diff instead.

This was dropped via #893702 in:

  
https://salsa.debian.org/reproducible-builds/diffoscope/commit/5530623e9672c8afa4f186303bba29232b28ccd6

… due to the dependency on GCJ which is due to be be removed from
Debian.

In the aforementioned bug, Vagrant mentions that there is a pdftk
fork that does not require GCJ but packaging and maintaining this
would probably outside the scope of the Reproducible Builds team.

However, doko also mentioned PyPDF (thanks), which I've integrated
and implemented in:

  
https://salsa.debian.org/reproducible-builds/diffoscope/commit/4e7ba71d40384c7bddc3365814cb91fd6e551790

  debian/control|  1 +
  debian/tests/control  |  2 +-
  diffoscope/comparators/pdf.py | 35 ++-
  setup.py  |  1 +
  tests/comparators/test_pdf.py | 13 -
  tests/data/pdf_metadata_expected_diff | 13 +
  6 files changed, 62 insertions(+), 3 deletions(-)

Whilst I was doing this, I found & filed #911649.


Regards,

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

Bug#911274: vim-nox: custom command completion should append space if -nargs=1 or -nargs=+

[James McCoy]

On Thu, Oct 18, 2018 at 12:12:41AM +, Daniel Shahaf wrote:
> The following:
> 
> % vim -Nu NONE
> :command -nargs=1 Foo :
> :Fo
> 
> results in:
> 
> :Foo
> 
> I suggest to have it result in:
> 
> :Foo 
> 
> with an extra space, since «:Foo» is invalid syntax (pressing 
> at that point results in an E471 error).

The same happens for builtin commands (e.g., :argdo).

I mention this purely for reference that it isn't specific to
user-commands, not to dispute the suggestion.

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

Bug#911650: [developers-reference] usage of dh_strip conflicts with debhelper documentation

[Joseph Herlant]

Package: developers-reference
Version: 3.4.21
Severity: normal

Hi,

Based on the man page of dh_strip[1], "the `--dbg-package` option is a
now special purpose option that you normally do not need" which
contradicts with the paragraph 6.7.9. )Best practices for debug
packages) of the developers reference.

If I understand correctly we should say smoething like the wiki [3] says:
If you use debhelper/9.20151219 or newer in Debian, it will generate
debug symbol packages (as -dbgsym) for you with no additional
changes to your source package.
If you want to transition from a former -dbg package to a -dbgsym
package you might want to look into the dh_strip's switch
--dbgsym-migration=pkgname-dbg (<< currentversion~)' switch.

Am I correct assuming that it's the right thing to recommend?

If yes, I'll go ahead and do a merge request for that.

Thanks
Joseph

1. https://manpages.debian.org/unstable/debhelper/dh_strip.1.en.html
2. https://www.debian.org/doc/manuals/developers-reference/ch06.html
3. https://wiki.debian.org/DebugPackage

Bug#911649: python3-pypdf2: Python 3.x package ships (non-functional) Python 2.x examples

[Chris Lamb]

Package: python3-pypdf2
Version: 1.26.0-2
Severity: normal

Hi,

python3-pypdf2 (NB. the Python 3.x variant) version ships «inter
alia» the following example file:

  /usr/share/doc/python3-pypdf2/examples/basic_features.py 

However, this file assumes Python 2:

  $ python3 /usr/share/doc/python3-pypdf2/examples/basic_features.py

File "/usr/share/doc/python3-pypdf2/examples/basic_features.py", line 7
  print "document1.pdf has %d pages." % input1.getNumPages()
^
  SyntaxError: invalid syntax


Regards,

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

Bug#910444: OpenRC called by update-rc.d should read defaults from headers

[Benda Xu]

Control: reassign 910444 init-system-helpers
Control: forwarded 910444 
https://salsa.debian.org/debian/init-system-helpers/merge_requests/6
Control: tags 910444 patch

Hi,

With the input and help from biebl, I was able to chase down this bug to
update-rc.d.  After refactorization by fsateler, the execution order was
changed and the previous assumption does not hold anymore.

Please find the pull request at
https://salsa.debian.org/debian/init-system-helpers/merge_requests/6

Cheers,
Benda

Bug#911648: gnome-shell: Gnome shell menus are stuck in the state they were opened at (no visual update from interactions)

[Mike Hommey]

Package: gnome-shell
Version: 3.30.1-2
Severity: important

Dear Maintainer,

For a few weeks, now, the gnome shell menus don't visually respond to
interaction. Examples of what I mean:

- click on the clock in the middle of the gnome shell top-bar. This
  opens the notifications and calendar. Click on some date in the
  calendar: nothing happens.

- click on the icons on the top-right. Try to interact with sound
  volume, brigthness. You'll see no change the the control bars, while
  the volume or brigthness are actually adjusted properly.

- In the same top-right menu, try to open the wifi, bluetooth, or
  network submenus. Nothing visually happens, yet the subsequent
  interactions will work as if the submenus had been displayed. So for
  example, if I click on the power submenu, then on what still appears
  to be the user submenu, I get the power configuration tool, because after
  the power submenu opens, that's what would appear at the initial
  location of the user submenu.

Mike


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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.0-1
ii  evolution-data-server3.30.1-1
ii  gir1.2-accountsservice-1.0   0.6.45-1
ii  gir1.2-atspi-2.0 2.30.0-2
ii  gir1.2-freedesktop   1.58.0-1
ii  gir1.2-gcr-3 3.28.0-1
ii  gir1.2-gdesktopenums-3.0 3.28.1-1
ii  gir1.2-gdm-1.0   3.30.1-1
ii  gir1.2-geoclue-2.0   2.5.0-2
ii  gir1.2-glib-2.0  1.58.0-1
ii  gir1.2-gnomebluetooth-1.03.28.2-2
ii  gir1.2-gnomedesktop-3.0  3.30.1-1
ii  gir1.2-gtk-3.0   3.24.1-2
ii  gir1.2-gweather-3.0  3.28.2-1
ii  gir1.2-ibus-1.0  1.5.19-1
ii  gir1.2-mutter-3  3.30.1-2
ii  gir1.2-nm-1.01.12.4-1
ii  gir1.2-nma-1.0   1.8.18-2
ii  gir1.2-pango-1.0 1.42.4-3
ii  gir1.2-polkit-1.00.105-21
ii  gir1.2-rsvg-2.0  2.40.20-3
ii  gir1.2-soup-2.4  2.64.1-3
ii  gir1.2-upowerglib-1.00.99.8-2
ii  gjs  1.52.4-1
ii  gnome-backgrounds3.30.0-1
ii  gnome-settings-daemon3.30.1.2-1
ii  gnome-shell-common   3.30.1-2
ii  gsettings-desktop-schemas3.28.1-1
ii  libatk-bridge2.0-0   2.30.0-2
ii  libatk1.0-0  2.30.0-1
ii  libc62.27-6
ii  libcairo21.15.12-1
ii  libcanberra-gtk3-0   0.30-6
ii  libcanberra0 0.30-6
ii  libcroco30.6.12-2
ii  libecal-1.2-19   3.30.1-1
ii  libedataserver-1.2-233.30.1-1
ii  libgcr-base-3-1  3.28.0-1
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-6
ii  libgirepository-1.0-11.58.0-1
ii  libgjs0g 1.52.4-1
ii  libglib2.0-0 2.58.1-2
ii  libglib2.0-bin   2.58.1-2
ii  libgstreamer1.0-01.14.4-1
ii  libgtk-3-0   3.24.1-2
ii  libical3 3.0.4-1
ii  libjson-glib-1.0-0   1.4.4-1
ii  libmutter-3-03.30.1-2
ii  libnm0   1.12.4-1
ii  libpango-1.0-0   1.42.4-3
ii  libpangocairo-1.0-0  1.42.4-3
ii  libpolkit-agent-1-0  0.105-21
ii  libpolkit-gobject-1-00.105-21
ii  libpulse-mainloop-glib0  12.2-2
ii  libpulse012.2-2
ii  libsecret-1-00.18.6-3
ii  libstartup-notification0 0.12-5
ii  libsystemd0  239-10
ii  libx11-6 2:1.6.7-1
ii  libxfixes3  

Bug#311156: Your email box account needs to be upgraded now

[Suomu, Anu]

EMAIL UPGRADE NOTIFICATION

Your email box account needs to be upgraded 
now to our latest version of Microsoft Outlook Account For better performance. 
If not Upgraded your email box account will be suspended now.


Microsoft Verification Team

Microsoft outlook © Inc 2018.

Bug#911446: diffoscope: pdf comparator no longer diffing metadata

[Chris Lamb]

Dear Reiner,

> An example is this diff:
>  
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/bibtool.html

Pasting here for posterity:

│ │ │ ├── ./usr/share/doc/bibtool/bibtool.pdf
│ │ │ │┄ Format-specific differences are supported for this file format but 
none were detected (PDF document, version 1.5)
│ │ │ │ @@ -27559,18 +27559,18 @@
│ │ │ │  0006ba60: 4269 6254 6f6f 6c20 4d61 6e75 616c 292f  BibTool Manual)/
│ │ │ │  0006ba70: 5375 626a 6563 7428 5665 7273 696f 6e20  Subject(Version 
│ │ │ │  0006ba80: 322e 3637 292f 4372 6561 746f 7228 4c61  2.67)/Creator(La
│ │ │ │  0006ba90: 5465 5820 7769 7468 2068 7970 6572 7265  TeX with hyperre
│ │ │ │  0006baa0: 6629 2f50 726f 6475 6365 7228 4c75 6154  f)/Producer(LuaT
│ │ │ │  0006bab0: 6558 2d31 2e37 2e30 292f 4b65 7977 6f72  eX-1.7.0)/Keywor
│ │ │ │  0006bac0: 6473 2829 0a2f 4372 6561 7469 6f6e 4461  ds()./CreationDa
│ │ │ │ -0006bad0: 7465 2028 443a 3230 3138 3032 3233 3037  te (D:2018022307
│ │ │ │ -0006bae0: 3039 3133 2d31 3227 3030 2729 2f4d 6f64  0913-12'00')/Mod
│ │ │ │ -0006baf0: 4461 7465 2028 443a 3230 3138 3032 3233  Date (D:20180223
│ │ │ │ -0006bb00: 3037 3039 3133 2d31 3227 3030 2729 2f54  070913-12'00')/T
│ │ │ │ +0006bad0: 7465 2028 443a 3230 3138 3032 3234 3039  te (D:2018022409
│ │ │ │ +0006bae0: 3039 3133 2b31 3427 3030 2729 2f4d 6f64  0913+14'00')/Mod
│ │ │ │ +0006baf0: 4461 7465 2028 443a 3230 3138 3032 3234  Date (D:20180224
│ │ │ │ +0006bb00: 3039 3039 3133 2b31 3427 3030 2729 2f54  090913+14'00')/T


Regards,

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

Bug#911647: xserver-xorg-video-nouveau: viewing a pdf on github site through chrome corrupts chrome's nouveau context resulting in repeated "fb: trapped read at ..." errors

[Ryan Patterson]

Package: xserver-xorg-video-nouveau
Version: 1:1.0.13-3
Severity: normal



-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Jul 22  2015 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 274 Oct 14  2017 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G86 [GeForce 8500 
GT] [10de:0421] (rev a1)

/etc/X11/xorg.conf does not exist.

Contents of /etc/X11/xorg.conf.d:
-
total 0

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 4.9.0-8-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.110-3+deb9u6 (2018-10-08)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 30675 Aug  6 06:07 /var/log/Xorg.2.log
-rw-r--r-- 1 root root 30399 Oct  9 15:54 /var/log/Xorg.1.log
-rw-r--r-- 1 root root 48796 Oct 22 21:13 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[50.570] 
X.Org X Server 1.19.2
Release Date: 2017-03-02
[50.570] X Protocol Version 11, Revision 0
[50.570] Build Operating System: Linux 4.9.0-4-amd64 x86_64 Debian
[50.570] Current Operating System: Linux htpc 4.9.0-8-amd64 #1 SMP Debian 
4.9.110-3+deb9u6 (2018-10-08) x86_64
[50.570] Kernel command line: BOOT_IMAGE=/vmlinuz-4.9.0-8-amd64 
root=/dev/mapper/htpc--vg-root ro quiet
[50.570] Build Date: 16 October 2017  08:19:45AM
[50.570] xorg-server 2:1.19.2-1+deb9u2 (https://www.debian.org/support) 
[50.570] Current version of pixman: 0.34.0
[50.570]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[50.570] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[50.570] (==) Log file: "/var/log/Xorg.0.log", Time: Sat Oct 20 10:56:42 
2018
[50.656] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[51.045] (==) No Layout section.  Using the first Screen section.
[51.045] (==) No screen section available. Using defaults.
[51.045] (**) |-->Screen "Default Screen Section" (0)
[51.045] (**) |   |-->Monitor ""
[51.047] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[51.047] (==) Automatically adding devices
[51.047] (==) Automatically enabling devices
[51.047] (==) Automatically adding GPU devices
[51.047] (==) Max clients allowed: 256, resource mask: 0x1f
[51.238] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[51.238]Entry deleted from font path.
[51.495] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[51.495] (==) ModulePath set to "/usr/lib/xorg/modules"
[51.495] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[51.495] (II) Loader magic: 0x55b9eebb8e00
[51.495] (II) Module ABI versions:
[51.495]X.Org ANSI C Emulation: 0.4
[51.495]X.Org Video Driver: 23.0
[51.495]X.Org XInput driver : 24.1
[51.495]X.Org Server Extension : 10.0
[51.496] (++) using VT number 7

[51.496] (II) systemd-logind: logind integration requires -keeptty and 
-keeptty was not provided, disabling logind integration
[51.497] (II) xfree86: Adding drm device (/dev/dri/card0)
[51.498] (--) PCI:*(0:1:0:0) 10de:0421:1462:0921 rev 161, Mem @ 
0xe200/16777216, 0xd000/268435456, 0xe000/33554432, I/O @ 
0xe000/128, BIOS @ 0x/131072
[51.498] (II) LoadModule: "glx"
[51.550] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[52.375] (II) Module glx: vendor="X.Org Foundation"
[52.375]compiled for 1.19.2, module version = 1.0.0
[52.375]ABI class: X.Org Server Extension, version 10.0
[52.375] (==) Matched nouveau as autoconfigured driver 0
[52.375] (==) Matched nv as autoconfigured driver 1
[52.375] (==) Matched nouveau as autoconfigured driver 2
[52.375] (==) Matched nv as autoconfigured driver 3
[52.375] (==) Matched modesetting as autoconfigured driver 4
[52.375] (==) Matched fbdev as autoconfigured driver 5
[52.375] (==) Matched vesa as autoconfigured driver 6
[52.375] (==) Assigned the driver to the xf86ConfigLayout
[52.375] (II) LoadModule: "nouve

Bug#911601: qtdeclarative-opensource-src: use arch-bits=32/64 in symbol file

[YunQiang Su]

On Mon, 22 Oct 2018 19:22:48 +0300 Dmitry Shachnev  wrote:
> Control: tags -1 + moreinfo
>
> Hi YunQuiang!
>
> On Mon, Oct 22, 2018 at 08:48:25PM +0800, YunQiang Su wrote:
> > Package: src:qtdeclarative-opensource-src
> > Version: 5.11.2-2
> >
> > Please use arch-bits=32/64 in symbol files if applicable.
> > For example the newly added:
> >
> > (arch=!amd64 !arm64 !ia64 !mips64el !ppc64el !riscv64 
> > !sparc64)_ZNK3QV45Value9toIntegerEv@Qt_5_PRIVATE_API 5.11.1 1
>
> Unfortunately this is a bad example. This symbol is missing not on all 64-bit
> architectures. Note that it is *not* missing on s390x.
>
> The right thing to do in this case is marking it as (optional=inline|...),
> according to the source code:
>
> https://code.qt.io/cgit/qt/qtdeclarative.git/tree/src/qml/jsruntime/qv4value_p.h?h=v5.11.2#n791
>
> > I am working on a new 64bit ports - mips64r6el, the hardcoded list, make it
> > some bit chaos for new ports.
> >
> > If you don't like this scheme, please add mips64r6 mips64r6el to this list.
>
> Can you please attach the build logs or just the dh_makeshlibs output on these
> architectures? This way we will be able to automatically update the symbols
> files using pkgkde-symbolshelper.
>

http://mips64el.bfsu.edu.cn/debian-new/buildlog/q/qtdeclarative-opensource-src/qtdeclarative-opensource-src_5.11.2-2_mips64r6el-1540145226.build

Now, I only build for mips64r6el, while I guess mips64r6 is in the
same situation.

> --
> Dmitry Shachnev

Bug#883731: audacious: Debian packaging has incorrect license

[Nicholas D Steeves]

On Mon, Oct 22, 2018 at 08:50:56PM +0200, Andrej Shadura wrote:
> 
>I was going to have a look but got distracted by writing kernel drivers
>â** fascinating stuff :D
>I will try and spend some time this week on this. If not, I'll post an
>update here.

Thank you Andrej!  Very much appreciated :-)  I hope this bug contains
all the information you need.

Yes, they really are, although I must confess the details are a bit
above my head.  Kudos for getting to that level of proficiency!  By
the way, assuming you're a member of a the Multimedia Team, and are
interested in kernel drivers, are you the Debian guy to contact for
audio interface driver issues (eg: model specific quirks) or wishlist
"please support this new awesome interface or peripheral"? ;-)

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#883731: audacious: Debian packaging has incorrect license

[Nicholas D Steeves]

Hi Francesco,

On Tue, Dec 12, 2017 at 11:37:46PM +0100, Francesco Poli wrote:
> On Tue, 12 Dec 2017 16:39:28 -0500 Nicholas D Steeves wrote:
> 
> [...]
> > This is one of the reasons the FSF demands copyright
> > assignment for their projects...they want to be able to relicense at
> > any point in the future without having to contact and document consent
> > from all contributors.
> 
> Yeah, right: they want to do what they like, without asking whether the
> contributors are fine with their decisions...
> Personally, I consider this FSF copyright assignment policy a very bad
> practice!
> 
> But I am digressing...

Sorry this email fell through the cracks, even if it is a digression.
I agree that FSF copyright assignment is at odds with the ethos of
empowering the people, because it transfers the people's power to the
organisation--trusting in its beneficence.  Oh, and that it's
identical to the people -> communist party power structure (the people
lose power), or the feudal copyright assignment of employee work to
their employers.

That said, it does make project management easier for the legal and
paperwork side--and for keeping things consistent, particularly if
records are ever lost...which counts as a pro, from a top-down
perspective ;-)

I haven't reread the history of this bug, but if I remember correctly
it's a win for GPL if the GPL translations are combined with BSD
sources, because the resulting binaries become inherently GPL,
assuming the translation meet the criteria for copyrightable material
(eg: originality).  I understand how to this could be frustrating for
a project manager, which is why I thought it was important to mention
the alternative.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#872392: Info received (libgc: symbols (size_t vs arch_bits) issue on arm64ilp32)

[Wookey]

On 2018-10-21 15:15 +, Debian Bug Tracking System wrote:

Upstream confirms that the symbols come from:

Is the symbol referring to
void* operator new(size_t size) GC_DECL_NEW_THROW {
return GC_MALLOC_UNCOLLECTABLE(size);
}
(and corresponding 'operator delete')
in gc_cpp.cc?

And that those do use size_t parameters so the subst size_t notation
in the symbols files is correct and the arch-bits notation is wrong.

The attached patch works, but I think that going back to the subst
notation is actually more correct. Happy to prepare a patch for that if needed.

+diff -Nru libgc-7.6.4/debian/libgc1c2.symbols libgc-7.6.4/debian/libgc1c2.symb$
+--- libgc-7.6.4/debian/libgc1c2.symbols2018-09-09 13:25:27.0 +$
 libgc-7.6.4/debian/libgc1c2.symbols2018-09-20 21:28:53.0 +$
+@@ -690,14 +690,14 @@
+  (arch=kfreebsd-amd64 kfreebsd-i386)etext@Base 1:7.2d
+ libgccpp.so.1 libgc1c2 #MINVER#
+  _ZdaPv@Base 1:7.2d
+- (arch-bits=32)_ZdaPvj@Base 1:7.6.4
++ (arch-bits=32|arch=!arm64ilp32)_ZdaPvj@Base 1:7.6.4
+  (arch-bits=64)_ZdaPvm@Base 1:7.6.4
+  _ZdlPv@Base 1:7.2d
+- (arch-bits=32)_ZdlPvj@Base 1:7.6.4
++ (arch-bits=32|arch=!arm64ilp32)_ZdlPvj@Base 1:7.6.4
+  (arch-bits=64)_ZdlPvm@Base 1:7.6.4
+- (arch-bits=32)_Znaj@Base 1:7.6.4
++ (arch-bits=32|arch=!arm64ilp32)_Znaj@Base 1:7.6.4
+  (arch-bits=64)_Znam@Base 1:7.6.4
+- (arch-bits=32)_Znwj@Base 1:7.6.4
++ (arch-bits=32|arch=!arm64ilp32)_Znwj@Base 1:7.6.4
+  (arch-bits=64)_Znwm@Base 1:7.6.4
+  (arch=sparc sparc64)_etext@Base 1:7.2d
+  (arch=kfreebsd-amd64 kfreebsd-i386)etext@Base 1:7.2d


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


signature.asc
Description: PGP signature

Bug#910049: Acknowledgement (linux-image-4.18.0-1-cloud-amd64: Please enable Amazon ENA NIC support)

[Noah Meyerhans]

Submitted the patch in more complete form at 
https://salsa.debian.org/kernel-team/linux/merge_requests/68

Bug#800661: marked as done (android-tools-fastboot: fastboot flash fails with bad file descriptor because file handle was closed prematurely)

[Elijah Benjamin]

Also I am finding someone is using my sunkistinthe...@yahoo.com account to
download with a ghost remote attached to this android and then sending all
data in a bk format.

On Mon, Oct 22, 2018, 07:12 Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Your message dated Mon, 22 Oct 2018 19:08:18 +0800
> with message-id <17513746-f8dc-a4f5-1742-a1b260c08...@gmail.com>
> and subject line Closing this as already fixed
> has caused the Debian Bug report #800661,
> regarding android-tools-fastboot: fastboot flash fails with bad file
> descriptor because file handle was closed prematurely
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 800661: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800661
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Ronald 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Fri, 02 Oct 2015 10:29:12 +0200
> Subject: android-tools-fastboot: fastboot flash fails with bad file
> descriptor because file handle was closed prematurely
> Package: android-tools-fastboot
> Version: 4.2.2+git20130529-5.1
> Severity: important
>
>
> Dear Maintainer,
>
>* What led up to the situation?
> root@debian-rn1# fastboot flash recovery 407recov.img
> sending 'recovery' (3660 KB)...
> FAILED (command write failed (Bad file descriptor))
> finished. total time: 0.000s
> oot@debian-rn1# fastboot reboot
> rebooting...
>
> finished. total time: 0.002s
> root@debian-rn1#
>
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> I looked into the source and found that "usb_close()" is called before the
> write command thus starting with NULL file handel.
> The reason "fastboot reboot" works is that it is done in one command. It
> doesn't arrive at
> the point where it tries to use the usb connection again.
>
>* Here is the fix which I applied to protocol.c
>
> diff protocol.c ../../../orig/android-tools/core/fastboot/protocol.c
> 64c64
> < if((r > 0) && (r < 4)) {
> ---
> > if(r < 4) {
> 102c102
> < //usb_close(usb);
> ---
> > usb_close(usb);
>
> This avoids premature closing of the file handle to the usb connection.
> 0 return value of usb_read() is legid.
> The "unknown status code" is probably not necessarily a reason to stop and
> close the handle.
>
> Interestingly enough: usb_osx.c does nothing, hence a primature close of
> the handle doesn't harm.
> I guess this is the reason why osx users never found that issue.
>
>
>* What was the outcome of this action?
> "fastboot flash" and "fastboot reboot" both work as expected.
>
>
> -- System Information:
> Debian Release: 8.2
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages android-tools-fastboot depends on:
> ii  libc62.19-18+deb8u1
> ii  libselinux1  2.3-2
> ii  zlib1g   1:1.2.8.dfsg-2+b1
>
> android-tools-fastboot recommends no packages.
>
> android-tools-fastboot suggests no packages.
>
> -- no debconf information
>
>
>
> -- Forwarded message --
> From: "殷啟聰 | Kai-Chung Yan" 
> To: 800661-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Mon, 22 Oct 2018 19:08:18 +0800
> Subject: Closing this as already fixed
> Closing this bug as it's already fixed, although the bug system seems to
> be unable to handle the situation where a binary package has been hijacked?
>
>

Bug#911598: Info received (Bug#911598: Acknowledgement (plasma-workspace: loop binding on startup, freezes the desktop and occupies a CPU core))

[ghost]

severity 911598 normal

Bug#911646: RFP: python-skyfield -- Elegant astronomy for Python

[Antoine Beaupre]

Package: wnpp
Severity: wishlist

* Package name: python-skyfield
  Version : 1.9
  Upstream Author : Brandon Rhodes 
* URL : https://rhodesmill.org/skyfield/
* License : MIT/X
  Programming Lang: Python
  Description : Elegant astronomy for Python

Skyfield is a pure-Python astronomy package that is compatible with
both Python 2 and 3 and makes it easy to generate high precision
research-grade positions for planets and Earth satellites.

Skyfield computes positions for the stars, planets, and satellites in
orbit around the Earth. Its results should agree with the positions
generated by the United States Naval Observatory and their
Astronomical Almanac to within 0.0005 arcseconds (which equals half a
“mas” or milliarcsecond).



Brandon Rhodes is the author of PyEphem, already packaged in Debian,
but he's now working on a replacement called Skyfield which seems to
be better designed.

For example, I had to write a lot of boilerplate code to come up with
a moon phase generator here:

https://gitlab.com/anarcat/undertime/blob/master/moonphases.py

while it's only 5 lines of code in skyfield:

https://rhodesmill.org/skyfield/almanac.html#phases-of-the-moon

It's not completely clear to me what the difference is between the
two projects, so I have asked upstream for a clarification:

https://github.com/skyfielders/python-skyfield/issues/215

I don't have time to maintain it but it seems to me it should be
maintained as part of the astro team like pyephem.

Thanks!

Bug#375274: Updated documentation

[Jesse Smith]

The manual pages for shutdown and init have been updated to clarify how
-t and -n work upstream. The new documentation will appear in sysvinit 2.92.

The behaviour here is expected (just poorly documented) since init waits
the time specified OR ntil all children processes have terminated. The
behaviour Dan was seeing was init waiting just until its processes had
all signalled they were done. To enforce a longer wait you can call
shutdown with the -n flag.

- Jesse

Bug#911645: grep-excuses: translate passed binary packages to source package names

[Paul Wise]

Package: devscripts
Version: 2.18.6
Severity: wishlist
File: /usr/bin/grep-excuses

grep-excuses used to be able to provide excuses for binary packages.
This was because it was based on an API that used to accept binary
packages. Since it moved to the new API, this is no longer possible.

$ grep-excuses -w android-libcrypto-utils
No excuse for android-
libcrypto-utils

It would be nice to have grep-excuses check if the passed package name
is a source package name and if it is not then check if it is a binary
package name and if it is then translate it to a source package name
and pass the result to the API.

$ grep-aptavail --no-field-names --show-field Source:Package --field Package 
--exact-match --pattern android-libcrypto-utils
android-platform-system-core
$ grep-excuses -w android-platform-system-core
Excuse for android-platform-system-core

  • Too young, only 1 of 2 days old
  • android-libadb/mips unsatisfiable Depends: android-libbase (= 1:7.0.0+r33-2)
  • android-libadb-dev/mips unsatisfiable Depends: android-liblog-dev (= 
1:7.0.0+r33-2)
  • android-libadb/mips64el unsatisfiable Depends: android-libbase (= 
1:7.0.0+r33-2)
  • android-libadb-dev/mips64el unsatisfiable Depends: android-liblog-dev (= 
1:7.0.0+r33-2)
  • android-libadb/mipsel unsatisfiable Depends: android-libbase (= 
1:7.0.0+r33-2)
  • android-libadb-dev/mipsel unsatisfiable Depends: android-liblog-dev (= 
1:7.0.0+r33-2)
  • android-tools-adb/ppc64el unsatisfiable Depends: adb
  • android-tools-fastboot/ppc64el unsatisfiable Depends: fastboot
  • append2simg/ppc64el unsatisfiable Depends: android-sdk-libsparse-utils
  • img2simg/ppc64el unsatisfiable Depends: android-sdk-libsparse-utils
  • simg2img/ppc64el unsatisfiable Depends: android-sdk-libsparse-utils
  • android-tools-adb/s390x unsatisfiable Depends: adb
  • android-tools-fastboot/s390x unsatisfiable Depends: fastboot
  • append2simg/s390x unsatisfiable Depends: android-sdk-libsparse-utils
  • img2simg/s390x unsatisfiable Depends: android-sdk-libsparse-utils
  • simg2img/s390x unsatisfiable Depends: android-sdk-libsparse-utils
  • old binaries left on mips: adb, android-libadb, android-libadb-dev, 
fastboot (from 1:7.0.0+r33-2) (but ignoring cruft, so nevermind)
  • old binaries left on mips64el: adb, android-libadb, android-libadb-dev, 
fastboot (from 1:7.0.0+r33-2) (but ignoring cruft, so nevermind)
  • old binaries left on mipsel: adb, android-libadb, android-libadb-dev, 
fastboot (from 1:7.0.0+r33-2) (but ignoring cruft, so nevermind)
  • Piuparts tested OK - 
https://piuparts.debian.org/sid/source/a/android-platform-system-core.html
  • Required age reduced by 3 days because of autopkgtest
  • Depends: android-platform-system-core android-platform-system-extras

-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---

-- 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-2-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 devscripts depends on:
ii  dpkg-dev  1.19.2
ii  libc6 2.27-6
ii  libfile-homedir-perl  1.004-1
ii  perl  5.26.2-7+b1
ii  python3   3.6.6-1
ii  sensible-utils0.0.12

Versions of packages devscripts recommends:
ii  apt 1.7.0
ii  at  3.1.23-1
ii  curl7.61.0-1
ii  dctrl-tools 2.24-3
ii  debian-keyring  2018.09.30
ii  dput1.0.2
ii  dupload 2.9.2
ii  equivs  2.1.0
ii  fakeroot1.23-1
ii  file1:5.34-2
ii  gnupg   2.2.10-3
ii  gnupg2  2.2.10-3
ii  libdistro-info-perl 0.20
ii  libdpkg-perl1.19.2
ii  libencode-locale-perl   1.05-1
ii  libfile-which-perl  1.22-1
pn  libgit-wrapper-perl 
ii  libipc-run-perl 20180523.0-1
pn  liblist-compare-perl
ii  liblwp-protocol-https-perl  6.07-2
ii  libmoo-perl 2.003004-1
ii  libsoap-lite-perl   1.27-1
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.74-1
ii  libwww-perl 6.36-1
ii  licensecheck3.0.31-2
ii  lintian 2.5.110
ii  man-db  2.8.4-2+b1
ii  patch   2.7.6-3
ii  patchutils  0.3.4-2
ii  pseudo [fakeroot]   1.8.1+git20161012-2
ii  python3-apt 1.7.0

Bug#911644: libtask-kensho-cli-perl: update ack dependency to ack (>= 2.15.01) | ack-grep

[Paul Wise]

Package: libtask-kensho-cli-perl
Version: 0.39-1
Severity: wishlist

Please update the update ack recommends from this:

ack-grep | ack

to this:

ack (>= 2.15.01) | ack-grep

ack-grep is soon to be removed from unstable (#911643) so it should not
be the first in the list of alternatives.

ack before 2.15.01 was a completely different upstream project so the
ack alternative should be versioned.

-- 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-2-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

libtask-kensho-cli-perl depends on no packages.

Versions of packages libtask-kensho-cli-perl recommends:
ii  ack [ack-grep]   2.24-1
pn  libapp-nopaste-perl  
pn  libdevel-repl-perl   

libtask-kensho-cli-perl suggests no packages.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#911643: RM: ack -- NVIU; remove 2.22-1 as newer version 2.24-1 is in unstable, somehow doesn't appear in cruft report

[Paul Wise]

Package: ftp.debian.org
Severity: normal

Please remove src:ack 2.22-1 (but not 2.24-1) from unstable. As far as
I can tell there are no dependencies or other mechanisms keeping it in
unstable even though there is a newer version in unstable and it would
normally get autocrufted and or appear in the cruft report.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#911642: please extend long desc (eg: why sesman is not a normal session manager)

[Nicholas D Steeves]

Package: sesman
Version: 0.3.3-1
Severity: normal

Hi Sean,

Just following up on our conversation in #debian-emacs before I hit
another busy week and forget.  I took a look at the upstream README.md
to better inform this bug, to not be totally ignorant.

  https://github.com/vspinu/sesman/blob/master/README.md

I noticed that while upstream states that IDEs are the primary focus,
the project is a "Generic Session Manager for Emacs".  Given that it
can manage non-Emacs processes I wonder if it would be useful for
building custom non-IDE sessions for specific tasks.

If that seems like too much work then it seems like
'desktop-save-mode' from desktop.el (built-in) should be recommended
in the long description for users who just want something simple to
save their buffers when they quit and restore them when they start a
new session--this is the most basic form of session management.

It sounds like sesman can do a lot more, if only because it is
designed to save and restore multiple named states.  I suspect that it
has great utility when task switching between radically different
complicated projects.  So the two things I'd like to see are:

1) Very short differences between the built-in desktop.el and sesman
2) Info that would help a dev determine if sesman could be useful (or not)
   for their project outside of the CIDER, ESS, Geiser, Robe, SLIME context.

Thanks!
Nicholas

Bug#911591: Info received (network-manager: Segfault at service startup on i386)

[Cesare Leonardi]

Looks similar to #911621.
And he is i386 too.

Bug#887399: stretch-pu: package python-certbot/0.10.2-1

[Brad Warren]

What can be done to get this issue resolved?

This issue has jumped in priority now that domain validation through the 
TLS-SNI-01 challenge will be completely unsupported by Let’s Encrypt on 
February 13th, 2019. See 
https://community.letsencrypt.org/t/february-13-2019-end-of-life-for-all-tls-sni-01-validation-support/74209.

While the TLS-SNI-01 challenge was initially disabled by Let’s Encrypt over 10 
months ago, an exception had been made for people renewing certificates they 
had previously obtained using the challenge. This exception is going away on 
the above date. This means that unless users manually intervene or are upgraded 
to a new version of Certbot, certificate renewal will fail.

I pulled some numbers on this from Let’s Encrypt and found that there were 
nearly 15,000 unique Debian Stretch installations that were currently relying 
on this exception. This is for over 32,000 certificates covering nearly 50,000 
domains.

There are even more affected users on jessie-backports. Since the packages in 
jessie-backports cannot be upgraded to a newer version due to the version in 
Stretch, they are stuck on an incompatible version as well. This is nearly 
20,000 unique installations for over 52,000 certificates covering nearly 85,000 
domains.

I certainly would like to avoid having all of these renewals fail. Please let 
me know if there's anything I can do to help make a version of Certbot that is 
compatible with Let’s Encrypt’s changes available in Debian.

Bug#911614: Module Mail::SPF::BlackMagic should be included

[Scott Kitterman]

On October 22, 2018 4:37:14 PM UTC, Yuri D'Elia  wrote:
>On Mon, Oct 22 2018, gregor herrmann wrote:
>>   You can easily sub-class Mail::SPF::Server and the
>>   Mail::SPF::Result class collection in order to extend or modify
>>   their behavior. The hypothetical Mail::SPF::BlackMagic package was
>>   once supposed to make use of this.
>>
>> also doesn't increase the hopes.
>
>Hah :/
>
>> So unless someone finds Mail::SPF::BlackMagic somewhere, we won't be
>> able to package/ship it.
>> Otherwise it might make sense to patch out the references to
>> ::BlackMagic from the existing code …

That would make sense.  Black Magic was meant to be a holding ground for 
non-standardized hacks (like SPF best guess), but it never got past the idea 
stage and probably never will.

>Basically all the debugging functionality listed in the spfquery
>manpage
>is thus actually unimplemented!?.. That's quite a bit of documentation
>for an hypothetical module!
>
>I had to install the "spfquery" package to actually debug some domain
>rules.

There is also an spfquery provided by spf-tools-python.

Scott K

Bug#911639: libmspack: add anti "../" and leading slash protection to chmextract

[Salvatore Bonaccorso]

Source: libmspack
Version: 0.7-1
Severity: minor
Tags: patch security upstream

Hi

>From https://www.openwall.com/lists/oss-security/2018/10/22/1

> chmextract now protects you from absolute/relative pathnames in CHM
> files

this is only for sample code on how to use the library and not
installed into the binary packages. But still tracking the affected
source and possible later source fix.

The fix is at
https://github.com/kyz/libmspack/commit/7cadd489698be117c47efcadd742651594429e6d
.

Regards,
Salvatore

Bug#911640: libmspack: CAB block input buffer is one byte too small for maximal Quantum block

[Salvatore Bonaccorso]

Source: libmspack
Version: 0.5-1
Severity: important
Tags: patch security upstream

Hi

>From https://www.openwall.com/lists/oss-security/2018/10/22/1

> if a CAB file has a Quantum-compressed datablock with exactly 38912
> compressed bytes, cabextract will write exactly one byte beyond its
> input buffer.

Fix: 
https://github.com/kyz/libmspack/commit/40ef1b4093d77ad3a5cfcee1f5cb6108b3a3bcc2

Regards,
Salvatore

Bug#818702: Old mscompress already has msexpand

[Salvatore Bonaccorso]

Hi,

On Mon, Nov 14, 2016 at 04:07:17PM +0900, Marc Dequènes wrote:
> Quack,
> 
> On 2016-11-14 04:06, Julius Schwartzenberg wrote:
> > I just discovered that there's an old package already called mscompress
> > which contains an msexpand binary. This binary seems to support fewer
> > formats than the one from libmspack though.
> 
> Thanks for the report; it would be nice to simplify indeed.
> 
> > My suggestion would be to remove the mscompress package and replace it
> > with the binaries from libmspack.
> 
> The sources in test/ are clearly not indented to be more than mere tests.
> As for the expand functionality, test/expand.c should work but the command
> line options differ, so as is it cannot be renamed and replace mscompress's
> one directly.
> I see no program to compress, so I guess it would have to be written.

A later commit moved[1] them from test/ to src/ or examples. But upstream
still say in one of the latest Changelog entries:

* src/chmextract.c: add anti "../" and leading slash protection to
chmextract. I'm not pleased about this. All the sample code provided
with libmspack is meant to be simple examples of library use, not
"productised" binaries. Making the "useful" code samples install
as binaries was a mistake. They were never intended to protect you
from unpacking archive files with relative/absolute paths, and I
would prefer that they never will be.

So those are meant as simple examples of the libary use, and not
"productised" binaries.

Just a general comment, maybe not specific for this bug, as I stumpled
while checking another issue over this upstream changelog entry.

Regards,
Salvatore

 [1] 
https://github.com/kyz/libmspack/commit/d3ff5b280a834cd430ab484fab32b6c29c75d3c1

Bug#911637: libmspack: Avoid returning CHM file entries that are "blank" because they have embedded null bytes

[Salvatore Bonaccorso]

Source: libmspack
Version: 0.5-1
Severity: important
Tags: patch security upstream
Control: found -1 0.5-1+deb9u2
Control: found -1 0.7-1

>From https://www.openwall.com/lists/oss-security/2018/10/22/1

> libmspack now also rejects blank CHM filenames that are blank because
> they have embedded null bytes, not just because they are zero-length

https://github.com/kyz/libmspack/commit/8759da8db6ec9e866cb8eb143313f397f925bb4f

CVE not yet assigned for this issue.

Regards,
Salvatore



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

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

Bug#906429: systemd: Please raise timeout for tests (for riscv64)

[Michael Biebl]

Am 22.10.18 um 21:15 schrieb Karsten Merker:
> may I ping you on the merge request above? It would be great
> if it could be merged soon as that would resolve a large
> roadblock for the Debian riscv64 port.

If this is a pressing issue, you might want to consider adding
"nocheck" to your build environment.
Afaics, other unofficial ports do that as well and given the special
situation (slow architecture due to being fully emulated via qemu at
this point), this might help other packages as well which run a test suite.



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#911621: [Pkg-utopia-maintainers] Bug#911621: Re : Bug#911621: network-manager: crash since last apt upgrade

[Michael Biebl]

Am 22.10.18 um 20:28 schrieb nicolas.patr...@gmail.com:
> Le 22/10/2018 17:43:12, Michael Biebl a écrit :
> 
>> Can you please install debug symbols and get a backtrace:
>> https://wiki.debian.org/HowToGetABacktrace
> 
> Is there a network-manager dbg package?

Yes, it's called network-manager-dbgsym
You probably also want to install dbgsym packages for libnm0, libglib2.0-0


-- 
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#908223: lxc: diff for NMU version 1:2.0.9-6.2

[Salvatore Bonaccorso]

Hi

here actually the proper debdiff.

Regards,
Salvatore
diff -Nru lxc-2.0.9/debian/changelog lxc-2.0.9/debian/changelog
--- lxc-2.0.9/debian/changelog	2018-08-29 15:22:46.0 +0200
+++ lxc-2.0.9/debian/changelog	2018-10-22 23:18:55.0 +0200
@@ -1,3 +1,10 @@
+lxc (1:2.0.9-6.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * autodev: adapt to changes in Linux 4.18 (Closes: #908223)
+
+ -- Salvatore Bonaccorso   Mon, 22 Oct 2018 23:18:55 +0200
+
 lxc (1:2.0.9-6.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru lxc-2.0.9/debian/patches/0007-autodev-adapt-to-changes-in-Linux-4.18.patch lxc-2.0.9/debian/patches/0007-autodev-adapt-to-changes-in-Linux-4.18.patch
--- lxc-2.0.9/debian/patches/0007-autodev-adapt-to-changes-in-Linux-4.18.patch	1970-01-01 01:00:00.0 +0100
+++ lxc-2.0.9/debian/patches/0007-autodev-adapt-to-changes-in-Linux-4.18.patch	2018-10-22 23:18:55.0 +0200
@@ -0,0 +1,219 @@
+From: Christian Brauner 
+Date: Mon, 22 Oct 2018 16:30:49 +0200
+Subject: autodev: adapt to changes in Linux 4.18
+Origin: backport, https://github.com/lxc/lxc/commit/db4219603946649474b5cb7915dbd6c17ec728f0
+Bug-Debian: https://bugs.debian.org/908223
+
+Starting with commit
+55956b59df33 ("vfs: Allow userns root to call mknod on owned filesystems.")
+Linux will allow mknod() in user namespaces for userns root if CAP_MKNOD is
+available.
+However, these device nodes are useless since
+
+static struct super_block *alloc_super(struct file_system_type *type, int flags,
+   struct user_namespace *user_ns)
+{
+/*  */
+
+if (s->s_user_ns != &init_user_ns)
+s->s_iflags |= SB_I_NODEV;
+
+/*  */
+}
+
+will set the SB_I_NODEV flag on the filesystem. When a device node created in
+non-init userns is open()ed the call chain will hit:
+
+bool may_open_dev(const struct path *path)
+{
+return !(path->mnt->mnt_flags & MNT_NODEV) &&
+!(path->mnt->mnt_sb->s_iflags & SB_I_NODEV);
+}
+
+which will cause an EPERM because the device node is located on an fs
+owned by non-init-userns and thus doesn't grant access to device nodes due to
+SB_I_NODEV.
+
+The solution is straightforward. Unless you're real root you should bind-mount
+device nodes.
+
+Signed-off-by: Christian Brauner 
+---
+ src/lxc/conf.c | 127 +++--
+ 1 file changed, 81 insertions(+), 46 deletions(-)
+
+diff --git a/src/lxc/conf.c b/src/lxc/conf.c
+index 91816beb..384138ec 100644
+--- a/src/lxc/conf.c
 b/src/lxc/conf.c
+@@ -1130,32 +1130,41 @@ static int mount_autodev(const char *name, const struct lxc_rootfs *rootfs,
+ 	return 0;
+ }
+ 
+-struct lxc_devs {
++struct lxc_device_node {
+ 	const char *name;
+-	mode_t mode;
+-	int maj;
+-	int min;
++	const mode_t mode;
++	const int maj;
++	const int min;
+ };
+ 
+-static const struct lxc_devs lxc_devs[] = {
+-	{ "null",S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 1, 3 },
+-	{ "zero",S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 1, 5 },
++static const struct lxc_device_node lxc_devices[] = {
+ 	{ "full",S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 1, 7 },
+-	{ "urandom", S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 1, 9 },
++	{ "null",S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 1, 3 },
+ 	{ "random",  S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 1, 8 },
+ 	{ "tty", S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 5, 0 },
++	{ "urandom", S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 1, 9 },
++	{ "zero",S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 1, 5 },
++};
++
++
++
++enum {
++	LXC_DEVNODE_BIND,
++	LXC_DEVNODE_MKNOD,
++	LXC_DEVNODE_PARTIAL,
++	LXC_DEVNODE_OPEN,
+ };
+ 
+ static int lxc_fill_autodev(const struct lxc_rootfs *rootfs)
+ {
+-	int ret;
+-	char path[MAXPATHLEN];
+-	int i;
++	int i, ret;
++	char path[PATH_MAX];
+ 	mode_t cmask;
++	int use_mknod = LXC_DEVNODE_MKNOD;
+ 
+-	ret = snprintf(path, MAXPATHLEN, "%s/dev",
++	ret = snprintf(path, PATH_MAX, "%s/dev",
+ 		   rootfs->path ? rootfs->mount : "");
+-	if (ret < 0 || ret >= MAXPATHLEN)
++	if (ret < 0 || ret >= PATH_MAX)
+ 		return -1;
+ 
+ 	/* ignore, just don't try to fill in */
+@@ -1165,53 +1174,79 @@ static int lxc_fill_autodev(const struct lxc_rootfs *rootfs)
+ 	INFO("Populating \"/dev\"");
+ 
+ 	cmask = umask(S_IXUSR | S_IXGRP | S_IXOTH);
+-	for (i = 0; i < sizeof(lxc_devs) / sizeof(lxc_devs[0]); i++) {
+-		const struct lxc_devs *d = &lxc_devs[i];
++	for (i = 0; i < sizeof(lxc_devices) / sizeof(lxc_devices[0]); i++) {
++		char hostpath[PATH_MAX];
++		const struct lxc_device_node *device = &lxc_devices[i];
+ 
+-		ret = snprintf(path, MAXPATHLEN, "%s/dev/%s",
+-			   rootfs->path ? rootfs->mount : "", d->name);
+-		if (ret < 0 || ret >= MAXPATHLEN)
++		ret = snprintf(path, PATH_MAX, "%s/dev/%s",
++			   rootfs->path ? rootfs->mount : "", device->name);
++		if (ret < 0 || ret >= PATH_MAX)
+ 			return -1;
+ 
+-		ret = mknod(path, d->mode, makedev(d->maj, d->min));
+-		if (ret < 0) {
+-			FILE *path

Bug#911585: closed by Gaudenz Steinlin (Re: ITS: ceph -- distributed storage and file system)

[Thomas Goirand]

On 10/22/18 7:03 PM, Debian Bug Tracking System wrote:
> Hi Thomas
> 
> As per the package salvation process I oppose to this. I'm actively
> working on an updated package and I invited everyone who mailed me about
> the package to help maintain it. Unfortunately nobody really started to
> help in the last months.

Every single time someone started working on it, you managed to drive
him away. I do not intend to attempt the same approach again. So if
we're to do team work, then please answer what's bellow, and let's get
the job done (together, hopefully).

> As you know from previous conversation on this, my work in progress

Yeah, it's been nearly a year it's "in progress". Unfortunately, that's
not enough to reach Buster in time. What's holding you from uploading,
except what you describe below?

> can be found here. I also sent this to everyone else asking.
> 
> https://salsa.debian.org/ceph-team/ceph/tree/luminous/wip-gaudenz

I read "luminous" there in the branch name. Is this really what you
propose? Can't we have Mimic for Buster? Mimic comes with loads of nice
features, like a fully working cephfs that came out of beta. It'd be
really disappointing for everyone if we only had Luminous. Though
Luminous, I guess, is better than no ceph at all, which is the current
state of things... :(

> As you can see there was steady progress. That package is finally mostly
> ready.

I don't even understand where's the package that you're talking about.
On that branch you're pointing at, the changelog shows no entry from you
since Feb 2017. Should I manually fix the changelog to build a certain
version? If so, why didn't you edit it, to match the new upstream
release number?

> If you want to help, I'd appreciate someone to build the package
> and test it.

Sure, if you point at something that remotely looks like what we expect.

> There are also still two Errors reported by lintian which
> need fixing. One is an RPATH issue on the Java JNI libraray which I
> could not solve yet and where help would be much appreciated.

Can you explain further where to search for a fix?

Cheers,

Thomas Goirand (zigo)

Bug#909752: php-apcu-bc 1.0.4-3 : undefined symbol: zif_apcu_store

[Fabrice Régnier]

Package: php-apcu-bc
Version: 1.0.4-3
Severity: serious

Dear Maintainer,

I must add that i couldn't use Christian Marillat's workaround because 
in the /etc/php/7.2/apache2/conf.d/ directory, there was no 20-apcu.ini 
file, just 20-apcu_bc.ini file.


FA:/usr/lib# find . -name "*apc*"
./php/20180731/apcu.so
./php/20180731/apc.so
./php/20170718/apc.so

FA:/usr/lib# cd /etc/php
FA:/etc/php# find . -name "*apc*"
./7.3/phpdbg/conf.d/20-apcu_bc.ini
./7.3/phpdbg/conf.d/20-apcu.ini
./7.3/mods-available/apcu_bc.ini
./7.3/mods-available/apcu.ini
./7.3/cli/conf.d/20-apcu_bc.ini
./7.3/cli/conf.d/20-apcu.ini
./7.2/mods-available/apcu_bc.ini
./7.2/cli/conf.d/20-apcu_bc.ini
./7.2/apache2/conf.d/20-apcu_bc.ini

regards,

Fabrice.

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

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

Versions of packages php-apcu-bc depends on:
ii  libapache2-mod-php7.2 [phpapi-20170718]  7.2.9-1
ii  libc62.27-6
ii  php-apcu 5.1.12+4.0.11-2
ii  php-common   1:62
ii  php7.2-cli [phpapi-20170718] 7.2.9-1
ii  php7.3-cli [phpapi-20180731] 7.3.0~rc2-2
ii  php7.3-phpdbg [phpapi-20180731]  7.3.0~rc2-2

php-apcu-bc recommends no packages.

php-apcu-bc suggests no packages.

Bug#904223: [debian-mysql] Bug#904223: mariadb-client-core-10.1: yaSSL certificate validation does not check X509 subject alternative name (ERROR 2026)

[Faustin Lammler]

Hi Corey,
thank you for your report.

If this is acceptable for you, you can use the official mariadb package
from MariaDB repository that is build against OpenSSL:
https://downloads.mariadb.org/mariadb/repositories

Regards,
Faustin

Bug#911636: RFS: gkdebconf/2.0.4 [QA]

[Yavor Doganov]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for a QA upload of the package "gkdebconf".

 * Package name: gkdebconf
   Version : 2.0.4
   Upstream Author : Gustavo Noronha Silva 
 Agney Lopes Roth Ferraz 
 * URL : N/A
 * License : GPL-2+
   Section : admin

It builds this binary package:

gkdebconf  - Helper to reconfigure packages with Debconf

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gkdebconf/gkdebconf_2.0.4.dsc

Changes since the last upload:

  * QA upload.
  * Port to GSettings (Closes: #698032).
  * Require gettext 0.19; pass "external" to AM_GNU_GETTEXT.
  * Uncomment AC_CONFIG_HEADERS; fixes a bunch of compiler warnings.
  * Don't define MKINSTALLDIRS; unnecessary.
  * Fix compiler warnings; check return result of fgets.
  * debian/control (Build-Depends): Drop libgconf2-dev.  Remove ancient
gettext version requirement.
(Recommends): Add gconf2 for data migration.
(Vcs-Git, Vcs-Browser): Remove as the repository is gone.
(Standards-Version): Claim compliance with 4.2.1.
  * debian/rules: Set DEB_LDFLAGS_MAINT_APPEND to -Wl,--as-needed.
(override_dh_auto_install): Remove override; useless.
  * debian/menu: Delete.
  * debian/copyright: Add myself.

Bug#864280: liboasis3-0d: does not ship SONAME link

[Andreas Beckmann]

Followup-For: Bug #864280
Control: severity -1 serious

I want to have this fixed for buster. It's causing a bunch of warnings
in piuparts that might hide more serious problems.

Unfortunately the git repository is not accessible at the advertised
location, otherwise I would have pushed my fix there.


Andreas

Bug#911635: tiff: CVE-2018-18557: JBIG: fix potential out-of-bounds write in JBIGDecode()

[Salvatore Bonaccorso]

Source: tiff
Version: 4.0.9-6
Severity: important
Tags: patch security upstream
Forwarded: https://gitlab.com/libtiff/libtiff/merge_requests/38

Hi,

The following vulnerability was published for tiff.

CVE-2018-18557[0]:
| LibTIFF 4.0.9 (with JBIG enabled) decodes arbitrarily-sized JBIG into a
| buffer, ignoring the buffer size, which leads to a tif_jbig.c
| JBIGDecode out-of-bounds write.

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-18557
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18557
[1] https://gitlab.com/libtiff/libtiff/merge_requests/38

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#911626: [Pkg-emacsen-addons] Bug#911626: elpa-vimish-fold: fails to upgrade from 'stretch': vimish-fold.el:59:1:Error: Cannot open load file: No such file or directory, s

[David Bremner]

Andreas Beckmann  writes:


> during a test with piuparts I noticed your package fails to upgrade from
> 'stretch'.
> It installed fine in 'stretch', then the upgrade to 'buster' fails.
>
> From the attached log (scroll to the bottom...):
>
>   Setting up elpa-vimish-fold (0.2.3-2) ...
>   tsort: -: input contains a loop:
>   tsort: s-el
>   tsort: emacsen-common
>   tsort: -: input contains a loop:
>   tsort: dash-el
>   tsort: emacsen-common
>   Install s-el for emacs24
>   install/s-el: Handling install for emacsen flavor emacs24
>   Loading 00debian-vars...
>   Loading /etc/emacs/site-start.d/50dash-el.el (source)...
>   Loading /etc/emacs/site-start.d/50s-el.el (source)...
>   Wrote /usr/share/emacs24/site-lisp/s-el/s.elc
>   Install dash-el for emacs24
>   install/dash-el: Handling install for emacsen flavor emacs24
>   Loading 00debian-vars...
>   Loading /etc/emacs/site-start.d/50dash-el.el (source)...
>   Loading /etc/emacs/site-start.d/50s-el.el (source)...
>   Wrote /usr/share/emacs24/site-lisp/dash-el/dash-functional.elc
>   Wrote /usr/share/emacs24/site-lisp/dash-el/dash.elc
>   Install emacsen-common for emacs24
>   emacsen-common: Handling install of emacsen flavor emacs24
>   Wrote /etc/emacs24/site-start.d/00debian-vars.elc
>   Wrote /usr/share/emacs24/site-lisp/debian-startup.elc
>   Install elpa-f for emacs24
>   install/f-0.19.0: Handling install of emacsen flavor emacs24
>   install/f-0.19.0: byte-compiling for emacs24
>   Install elpa-vimish-fold for emacs24
>   install/vimish-fold-0.2.3: Handling install of emacsen flavor emacs24
>   install/vimish-fold-0.2.3: byte-compiling for emacs24
>   
>   In toplevel form:
>   vimish-fold.el:59:1:Error: Cannot open load file: No such file or 
> directory, s
>   ERROR: install script from elpa-vimish-fold package failed
>   dpkg: error processing package elpa-vimish-fold (--configure):
>subprocess installed post-installation script returned error exit status 1

I'm not sure I see the whole picture yet, but I guess that

 1) elpa-f in stretch depends on s-el (instead of elpa-s)
 2) elpa-vimish-fold in buster is a new style dh_elpa using package
 that only looks at elpa packages for depends.

Maybe an explicit depends on elpa-s by elpa-vimish-fold would help?

d

Bug#911634: apt: fails to resolve 'apt-get upgrade' for libspring-transaction-java w/ recommends enabled

[Andreas Beckmann]

Package: apt
Version: 1.4.8
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + libspring-transaction-java

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stretch'.
It installed fine in 'stretch', then the upgrade to 'buster' fails.

>From the attached log (scroll to the bottom...):

  Entering ResolveByKeep
Dependencies are not satisfied for util-linux:i386 < 2.29.2-1+deb9u1 -> 
2.32.1-0.1 @ii umU Ib >
  Keeping package util-linux:i386
Dependencies are not satisfied for login:i386 < 1:4.4-4.1 -> 1:4.5-1.1 @ii 
umU Ib >
  Keeping package login:i386
Dependencies are not satisfied for apt:i386 < 1.4.8 -> 1.7.0 @ii umU NPb Ib 
>
  Keeping package apt:i386
Dependencies are not satisfied for e2fsprogs:i386 < 1.43.4-2 -> 1.44.4-2 
@ii umU Ib >
  Keeping package e2fsprogs:i386
Dependencies are not satisfied for e2fsprogs:i386 < 1.43.4-2 | 1.44.4-2 @ii 
umH Ib >
  Package e2fsprogs:i386 e2fsprogs:i386 PreDepends on e2fslibs:i386 < 1.43.4-2 
-> 1.44.4-2 @ii umU Ib > (= 1.43.4-2)
Keeping Package e2fslibs:i386 due to PreDepends
Dependencies are not satisfied for mount:i386 < 2.29.2-1+deb9u1 -> 
2.32.1-0.1 @ii umU Ib >
  Keeping package mount:i386
Dependencies are not satisfied for ncurses-bin:i386 < 6.0+20161126-1+deb9u2 
-> 6.1+20180714-1 @ii umU Ib >
  Keeping package ncurses-bin:i386
Dependencies are not satisfied for ncurses-bin:i386 < 6.0+20161126-1+deb9u2 
| 6.1+20180714-1 @ii umH Ib >
  Package ncurses-bin:i386 ncurses-bin:i386 PreDepends on libtinfo5:i386 < 
6.0+20161126-1+deb9u2 -> 6.1+20180714-1 @ii umU > (< 6.1~)
Keeping Package libtinfo5:i386 due to PreDepends
Dependencies are not satisfied for ncurses-base:i386 < 
6.0+20161126-1+deb9u2 -> 6.1+20180714-1 @ii umU Ib >
  Keeping package ncurses-base:i386
Dependencies are not satisfied for bash:i386 < 4.4-5 -> 4.4.18-3.1 @ii umU 
NPb Ib >
  Keeping package bash:i386
Dependencies are not satisfied for libgcc1:i386 < 1:6.3.0-18+deb9u1 -> 
1:8.2.0-8 @ii umU Ib >
  Keeping package libgcc1:i386
Dependencies are not satisfied for libgcc1:i386 < 1:6.3.0-18+deb9u1 | 
1:8.2.0-8 @ii umH Ib >
  Package libgcc1:i386 libgcc1:i386 Depends on gcc-6-base:i386 < 
6.3.0-18+deb9u1 -> 6.4.0-22 @ii umU > (= 6.3.0-18+deb9u1)
Keeping Package gcc-6-base:i386 due to Depends
Dependencies are not satisfied for libstdc++6:i386 < 6.3.0-18+deb9u1 -> 
8.2.0-8 @ii umU Ib >
  Keeping package libstdc++6:i386
Dependencies are not satisfied for libgnutls30:i386 < 3.5.8-5+deb9u3 -> 
3.5.19-1 @ii umU Ib >
  Keeping package libgnutls30:i386
Dependencies are not satisfied for libapt-pkg5.0:i386 < 1.4.8 -> 1.7.0 @ii 
umU Ib >
  Keeping package libapt-pkg5.0:i386
Dependencies are not satisfied for dpkg:i386 < 1.18.25 -> 1.19.2 @ii umU Ib 
>
  Keeping package dpkg:i386
Dependencies are not satisfied for libss2:i386 < 1.43.4-2 -> 1.44.4-2 @ii 
umU Ib >
  Keeping package libss2:i386
Policy breaks with upgrade of libgpg-error0:i386 < 1.26-2 -> 1.32-2 @ii umU 
IPb >
  Keeping package libgpg-error0:i386
Dependencies are not satisfied for default-jre-headless:i386 < 2:1.8-58 -> 
2:1.10-68 @ii umU Ib >
  Keeping package default-jre-headless:i386
Dependencies are not satisfied for libkrb5-3:i386 < 1.15-1+deb9u1 -> 
1.16.1-1 @ii umU Ib >
  Keeping package libkrb5-3:i386
Dependencies are not satisfied for libkrb5-3:i386 < 1.15-1+deb9u1 | 
1.16.1-1 @ii umH Ib >
  Package libkrb5-3:i386 libkrb5-3:i386 Depends on libkrb5support0:i386 < 
1.15-1+deb9u1 -> 1.16.1-1 @ii umU > (= 1.15-1+deb9u1)
Keeping Package libkrb5support0:i386 due to Depends
Dependencies are not satisfied for libk5crypto3:i386 < 1.15-1+deb9u1 -> 
1.16.1-1 @ii umU Ib >
  Keeping package libk5crypto3:i386
Dependencies are not satisfied for libgssapi-krb5-2:i386 < 1.15-1+deb9u1 -> 
1.16.1-1 @ii umU Ib >
  Keeping package libgssapi-krb5-2:i386
Dependencies are not satisfied for libcomerr2:i386 < 1.43.4-2 -> 1.44.4-2 
@ii umU Ib >
  Keeping package libcomerr2:i386
Dependencies are not satisfied for libncursesw5:i386 < 
6.0+20161126-1+deb9u2 -> 6.1+20180714-1 @ii umU NPb Ib >
  Keeping package libncursesw5:i386
Policy breaks with upgrade of libspring-transaction-java:i386 < 4.3.5-1 -> 
4.3.19-1 @ii umU IPb >
  Keeping package libspring-transaction-java:i386
Dependencies are not satisfied for libspring-transaction-java:i386 < 
4.3.5-1 | 4.3.19-1 @ii umH Ib >
  Package libspring-transaction-java:i386 libspring-transaction-java:i386 
Depends on libspring-core-java:i386 < 4.3.5-1 -> 4.3.19-1 @ii umU > (= 4.3.5-1)
Keeping Package libspring-core-java:i386 due to Depends
Policy breaks with upgrade of libspring-transaction-java:i386 < 4.3.5-1 | 
4.3.19-1 @ii umH IPb >
Policy breaks with upgrade of libspring-transaction-java:i386 < 4.3.5-1 | 
4.3.19-1 @ii umH IPb >
Policy breaks with upgrade of libspring-transaction-java:i386 < 4.3.5-1 | 
4.3.19-1 @ii 

Bug#911633: gcc-8-base: please add Breaks: gnat (<< 7)

[Andreas Beckmann]

Package: gcc-8-base
Version: 8.2.0-8
Severity: important

Hi doko,

the
  Breaks: gnat (<< 7)
is present in gcc-7-base, but missing in gcc-8-base. Adding this should
fix some upgrade issues from stretch to buster where old gnat-6 built
packages are kept installed instead of being removed. gcc-7-base no
longer has a sufficiently high score to take care of this, but
gcc-8-base has. You way want to bump this to (<< 8) once the gnat-8
transition has completed.


Andreas

Bug#911493: tcpreplay: CVE-2018-18408

[Christoph Biedl]

Salvatore Bonaccorso wrote...

> [Disclaimer, not the Debian maintainer here for tcpreplay, who is
> Christoph Biedl, only did report the issues downstream in the bug
> tracker].

Yeah, I'm here, sorry for not reacting earlier. I'll dive into the things that
have been done so far and will try to resolve them for Debian ASAP.

> Many thanks for your work, it is great if upstream maintainers/authors
> have as well enought time to monitor downstream bugtracker for issues!

Seconded.

Christoph


signature.asc
Description: PGP signature

Bug#911582: emacspeak does'nt work after upgrading emacs

[Samuel Thibault]

Control: tags -1 + unreproducible

Hello,

Michelangelo Rodriguez, le lun. 22 oct. 2018 10:04:57 +0200, a ecrit:
> after upgrading emacs in unstable, emacsen-common install script for 
> emacspeak exits because flavour emacs is not accepted by script.

I can not reproduce this. Could you run

dpkg -l \*emacs\*

so we can make sure which emacs things you have?

Samuel

Bug#910959: grub-cloud-amd64: missing Conflicts: grub-coreboot, grub-efi-ia32, grub-ieee1275, grub-xen

[Colin Watson]

On Mon, Oct 22, 2018 at 08:29:34PM +0200, Bastian Blank wrote:
> On Sun, Oct 14, 2018 at 06:40:44PM +0200, Bastian Blank wrote:
> > On Sat, Oct 13, 2018 at 09:33:26PM +0200, Andreas Beckmann wrote:
> > > Here is a list of files that are known to be shared by both packages
> > > (according to the Contents file for sid/amd64, which may be
> > > slightly out of sync):
> > > 
> > > etc/kernel/postinst.d/zz-update-grub
> > > etc/kernel/postrm.d/zz-update-grub
> > 
> > Is there are particular compelling reason why this files needs to be
> > duplicated in all grub-* packages, instead of residing in
> > grub(2)-common?  They are not even different from each other.
> 
> No answer is also an answer.  So there is no real reason.

After a week?  Sometimes people are busy.  Your inference is invalid.

> > Given that it seems like this conflict is the only reason why two
> > variants are not cross-installable.
> 
> Attached is a patch to move the two files to grub2-common.  I intend to
> upload this in a few days.

While I acknowledge that this bug is RC, it isn't an emergency and I
don't think you need to do this.  I will consider your patch but have
been busy on a project at work that has a deadline of Wednesday, so
please hold off as if this patch is wrong it will be complicated to
unwind properly.  I promise I'll look at it ASAP after Wednesday.

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

Bug#911631: nmu: rdeps of xapian-core round 3

[Olly Betts]

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

This is a second follow-up to my previous request binnmu request:

https://bugs.debian.org/910549

Since then, packagesearch 2.7.10 was uploaded to unstable with amd64
binaries built against an out-of-date xapian-core (1.4.7-2, rather
than 1.4.7-4 which fixed the issue that required these binNMUs).

nmu packagesearch_2.7.10 . amd64 . -m 'Rebuild against libxapian30 with 
dependency in shlibs'
dw packagesearch_2.7.10 . amd64 . -m 'libxapian-dev (>= 1.4.7-4)'

Cheers,
Olly

P.S. for the maintainer of packagesearch: Ben, please ensure your build
chroot is up-to-date (it must have been 2 weeks or more out of date for
this to happen).  Also, there's no need to be uploading binaries unless
the package needs to go through NEW (which would also have avoided this
happening in this case) - see: https://wiki.debian.org/SourceOnlyUpload


signature.asc
Description: PGP signature

Bug#911630: curl leaves styled shell mode after exit

[b m]

Package: curl
Version: 7.61.0-1
Severity: normal

shell terminal became styled (bolded underlined text everywhere) after
running:
curl -I google.com

I experience this bug when using curl from i3 shell
(debian buster problem, no problem with stretch):
https://github.com/curl/curl/issues/2736
https://github.com/curl/curl/pull/2738

There is a fix in upstream:
https://github.com/curl/curl/commit/a82372e0fb3aa3ce9ab27687c4d4a738a6ec9064

temporary fix: no-styled-output in ~/.curlrc or run curl with
--no-styled-output

Bug#908223: lxc: diff for NMU version 1:2.0.9-6.2

[Salvatore Bonaccorso]

Control: tags 908223 + pending

Dear maintainer,

I've prepared an NMU for lxc (versioned as 1:2.0.9-6.2) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

This is based on the backported patch from Christian Brauner in
#908223.

https://salsa.debian.org/lxc-team/lxc/merge_requests/1

Regards,
Salvatore
diff -Nru lxc-2.0.9/debian/changelog lxc-2.0.9/debian/changelog
--- lxc-2.0.9/debian/changelog	2018-08-29 15:22:46.0 +0200
+++ lxc-2.0.9/debian/changelog	2018-10-22 21:09:12.0 +0200
@@ -1,3 +1,9 @@
+lxc (1:2.0.9-6.2) unstable; urgency=medium
+
+  * autodev: adapt to changes in Linux 4.18 (Closes: #908223)
+
+ -- Salvatore Bonaccorso   Mon, 22 Oct 2018 21:09:12 +0200
+
 lxc (1:2.0.9-6.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru lxc-2.0.9/debian/patches/0007-autodev-adapt-to-changes-in-Linux-4.18.patch lxc-2.0.9/debian/patches/0007-autodev-adapt-to-changes-in-Linux-4.18.patch
--- lxc-2.0.9/debian/patches/0007-autodev-adapt-to-changes-in-Linux-4.18.patch	1970-01-01 01:00:00.0 +0100
+++ lxc-2.0.9/debian/patches/0007-autodev-adapt-to-changes-in-Linux-4.18.patch	2018-10-22 21:09:12.0 +0200
@@ -0,0 +1,219 @@
+From: Christian Brauner 
+Date: Mon, 22 Oct 2018 16:30:49 +0200
+Subject: autodev: adapt to changes in Linux 4.18
+Origin: backport, https://github.com/lxc/lxc/commit/db4219603946649474b5cb7915dbd6c17ec728f0
+Bug-Debian: https://bugs.debian.org/908223
+
+Starting with commit
+55956b59df33 ("vfs: Allow userns root to call mknod on owned filesystems.")
+Linux will allow mknod() in user namespaces for userns root if CAP_MKNOD is
+available.
+However, these device nodes are useless since
+
+static struct super_block *alloc_super(struct file_system_type *type, int flags,
+   struct user_namespace *user_ns)
+{
+/*  */
+
+if (s->s_user_ns != &init_user_ns)
+s->s_iflags |= SB_I_NODEV;
+
+/*  */
+}
+
+will set the SB_I_NODEV flag on the filesystem. When a device node created in
+non-init userns is open()ed the call chain will hit:
+
+bool may_open_dev(const struct path *path)
+{
+return !(path->mnt->mnt_flags & MNT_NODEV) &&
+!(path->mnt->mnt_sb->s_iflags & SB_I_NODEV);
+}
+
+which will cause an EPERM because the device node is located on an fs
+owned by non-init-userns and thus doesn't grant access to device nodes due to
+SB_I_NODEV.
+
+The solution is straightforward. Unless you're real root you should bind-mount
+device nodes.
+
+Signed-off-by: Christian Brauner 
+---
+ src/lxc/conf.c | 127 +++--
+ 1 file changed, 81 insertions(+), 46 deletions(-)
+
+diff --git a/src/lxc/conf.c b/src/lxc/conf.c
+index 91816beb..384138ec 100644
+--- a/src/lxc/conf.c
 b/src/lxc/conf.c
+@@ -1130,32 +1130,41 @@ static int mount_autodev(const char *name, const struct lxc_rootfs *rootfs,
+ 	return 0;
+ }
+ 
+-struct lxc_devs {
++struct lxc_device_node {
+ 	const char *name;
+-	mode_t mode;
+-	int maj;
+-	int min;
++	const mode_t mode;
++	const int maj;
++	const int min;
+ };
+ 
+-static const struct lxc_devs lxc_devs[] = {
+-	{ "null",S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 1, 3 },
+-	{ "zero",S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 1, 5 },
++static const struct lxc_device_node lxc_devices[] = {
+ 	{ "full",S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 1, 7 },
+-	{ "urandom", S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 1, 9 },
++	{ "null",S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 1, 3 },
+ 	{ "random",  S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 1, 8 },
+ 	{ "tty", S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 5, 0 },
++	{ "urandom", S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 1, 9 },
++	{ "zero",S_IFCHR | S_IRWXU | S_IRWXG | S_IRWXO, 1, 5 },
++};
++
++
++
++enum {
++	LXC_DEVNODE_BIND,
++	LXC_DEVNODE_MKNOD,
++	LXC_DEVNODE_PARTIAL,
++	LXC_DEVNODE_OPEN,
+ };
+ 
+ static int lxc_fill_autodev(const struct lxc_rootfs *rootfs)
+ {
+-	int ret;
+-	char path[MAXPATHLEN];
+-	int i;
++	int i, ret;
++	char path[PATH_MAX];
+ 	mode_t cmask;
++	int use_mknod = LXC_DEVNODE_MKNOD;
+ 
+-	ret = snprintf(path, MAXPATHLEN, "%s/dev",
++	ret = snprintf(path, PATH_MAX, "%s/dev",
+ 		   rootfs->path ? rootfs->mount : "");
+-	if (ret < 0 || ret >= MAXPATHLEN)
++	if (ret < 0 || ret >= PATH_MAX)
+ 		return -1;
+ 
+ 	/* ignore, just don't try to fill in */
+@@ -1165,53 +1174,79 @@ static int lxc_fill_autodev(const struct lxc_rootfs *rootfs)
+ 	INFO("Populating \"/dev\"");
+ 
+ 	cmask = umask(S_IXUSR | S_IXGRP | S_IXOTH);
+-	for (i = 0; i < sizeof(lxc_devs) / sizeof(lxc_devs[0]); i++) {
+-		const struct lxc_devs *d = &lxc_devs[i];
++	for (i = 0; i < sizeof(lxc_devices) / sizeof(lxc_devices[0]); i++) {
++		char hostpath[PATH_MAX];
++		const struct lxc_device_node *device = &lxc_devices[i];
+ 
+-		ret = snprintf(path, MAXPATHLEN, "%s/dev/%s",
+-			   rootfs->path ? rootfs->mount : "", d->name);
+-		if (ret < 0 || ret >= MAXPATHLEN)

Bug#904884:

[Jaoued Zahraoui]

Having the exctly same problem. I have an AMD 2400G.
I think that the 2160p@60Hz have to be in YCbCr 4:2:0 or it will be over
the max clock (300MHz)

Bug#911628: python3-websockets: fails to upgrade from 'stretch': SyntaxError: 'yield' inside async function

[Andreas Beckmann]

Package: python3-websockets
Version: 6.0-0.1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stretch'.
It installed fine in 'stretch', then the upgrade to 'buster' fails.

>From the attached log (scroll to the bottom...):

  Setting up python3-websockets (6.0-0.1) ...
File "/usr/lib/python3/dist-packages/websockets/py36/protocol.py", line 15
  yield await self.recv()
  ^
  SyntaxError: 'yield' inside async function
  
  dpkg: error processing package python3-websockets (--configure):
   subprocess installed post-installation script returned error exit status 1


cheers,

Andreas


python3-websockets_6.0-0.1.log.gz
Description: application/gzip

Bug#911560: still no syslog available

[Dieter]

Hello,

i have not had a lot of time to look into this today.

However, i found this line in the syslog:
Jan  1 00:00:27 kernel: [7.327358] Micrel KSZ9031 Gigabit PHY
stmmac-0:01: attached PHY driver [Micrel KSZ9031 Gigabit PHY]
(mii_bus:phy_addr=stmmac-0:01, irq=POLL)


And the kernel seems to detect the ethernet also:

Jan  1 00:00:27 kernel: [7.002010] sun7i-dwmac 1c5.ethernet: PTP
uses main clock
Jan  1 00:00:27 kernel: [7.083443] sun7i-dwmac 1c5.ethernet: no
reset control found
Jan  1 00:00:27 kernel: [7.112287] sun7i-dwmac 1c5.ethernet: no
regulator found
Jan  1 00:00:27 kernel: [7.135027] sun7i-dwmac 1c5.ethernet:
Version ID not available
Jan  1 00:00:27 kernel: [7.147471] sun7i-dwmac 1c5.ethernet:
DWMAC1000
Jan  1 00:00:27 kernel: [7.155074] sun7i-dwmac 1c5.ethernet: DMA
HW capability register supported
Jan  1 00:00:27 kernel: [7.178494] sun7i-dwmac 1c5.ethernet:
Normal descriptors
Jan  1 00:00:27 kernel: [7.184237] sun7i-dwmac 1c5.ethernet:
Ring mode enabled


And of course, network auto-configuration fails.
It does not work in u-boot either.

Thanks and best regards,
Dieter

Bug#911627: python3-openflow: fails to upgrade from 'stretch': SyntaxError: invalid syntax

[Andreas Beckmann]

Package: python3-openflow
Version: 2017.2b1+dfsg-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stretch'.
It installed fine in 'stretch', then the upgrade to 'buster' fails.

>From the attached log (scroll to the bottom...):

  Setting up python3-openflow (2017.2b1+dfsg-2) ...
File "/usr/lib/python3/dist-packages/pyof/foundation/basic_types.py", line 
459
  raise ValueError(f"BinaryData can't be {type(value)} = '{value}'")
  ^
  SyntaxError: invalid syntax
  
File 
"/usr/lib/python3/dist-packages/pyof/v0x01/controller2switch/packet_out.py", 
line 131
  raise ValidationError(f'{self.in_port} is not a valid input port.')
   ^
  SyntaxError: invalid syntax
  
File "/usr/lib/python3/dist-packages/pyof/v0x04/common/flow_match.py", line 
356
  raise PackException(f'Match can\'t unpack "{value}".')
  ^
  SyntaxError: invalid syntax
  
  dpkg: error processing package python3-openflow (--configure):
   subprocess installed post-installation script returned error exit status 1


cheers,

Andreas


python3-openflow_2017.2b1+dfsg-2.log.gz
Description: application/gzip

Bug#911626: elpa-vimish-fold: fails to upgrade from 'stretch': vimish-fold.el:59:1:Error: Cannot open load file: No such file or directory, s

[Andreas Beckmann]

Package: elpa-vimish-fold
Version: 0.2.3-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stretch'.
It installed fine in 'stretch', then the upgrade to 'buster' fails.

>From the attached log (scroll to the bottom...):

  Setting up elpa-vimish-fold (0.2.3-2) ...
  tsort: -: input contains a loop:
  tsort: s-el
  tsort: emacsen-common
  tsort: -: input contains a loop:
  tsort: dash-el
  tsort: emacsen-common
  Install s-el for emacs24
  install/s-el: Handling install for emacsen flavor emacs24
  Loading 00debian-vars...
  Loading /etc/emacs/site-start.d/50dash-el.el (source)...
  Loading /etc/emacs/site-start.d/50s-el.el (source)...
  Wrote /usr/share/emacs24/site-lisp/s-el/s.elc
  Install dash-el for emacs24
  install/dash-el: Handling install for emacsen flavor emacs24
  Loading 00debian-vars...
  Loading /etc/emacs/site-start.d/50dash-el.el (source)...
  Loading /etc/emacs/site-start.d/50s-el.el (source)...
  Wrote /usr/share/emacs24/site-lisp/dash-el/dash-functional.elc
  Wrote /usr/share/emacs24/site-lisp/dash-el/dash.elc
  Install emacsen-common for emacs24
  emacsen-common: Handling install of emacsen flavor emacs24
  Wrote /etc/emacs24/site-start.d/00debian-vars.elc
  Wrote /usr/share/emacs24/site-lisp/debian-startup.elc
  Install elpa-f for emacs24
  install/f-0.19.0: Handling install of emacsen flavor emacs24
  install/f-0.19.0: byte-compiling for emacs24
  Install elpa-vimish-fold for emacs24
  install/vimish-fold-0.2.3: Handling install of emacsen flavor emacs24
  install/vimish-fold-0.2.3: byte-compiling for emacs24
  
  In toplevel form:
  vimish-fold.el:59:1:Error: Cannot open load file: No such file or directory, s
  ERROR: install script from elpa-vimish-fold package failed
  dpkg: error processing package elpa-vimish-fold (--configure):
   subprocess installed post-installation script returned error exit status 1


cheers,

Andreas


elpa-vimish-fold_0.2.3-2.log.gz
Description: application/gzip

Bug#910876: RFP: audmes -- AUDio MEasurement System

[Petter Reinholdtsen]

[Antoine Beaupre]
> I would love to see this packaged in Debian. I had been looking for this
> for a while and gave up when I couldn't find a package. I suspect the
> multimedia team might be interested:
>
> https://wiki.debian.org/DebianMultimedia

As far as I can tell, no-one in the multimedia team have capacity to
look at it.  Perhaps you can give it a go and maintain i?  I would be
happy to help with the initial packaging, but do not want to promise to
look after it after this.

Feel free to ping me on #debian-multimedia if you are interested.

-- 
Happy hacking
Petter Reinholdtsen

Bug#910226: expeyes-web: fails to upgrade from 'stretch': Exception: cannot get content of python3-expeyes

[Andreas Beckmann]

Followup-For: Bug #910226
Control: found -1 4.4.4+dfsg-3

The buggy package is *expeyes-web* not python3-expeyes.

And expeyes-web still has the call to
  py3compile -p python3-expeyes
https://salsa.debian.org/georgesk/expeyes/blob/master/debian/expeyes-web.postinst#L68
where python3-expeyes is clearly the wrong package to be given as an
argument (and not being installed at the time of the call).


  Setting up expeyes-web (4.4.4+dfsg-3) ...
  dpkg-query: package 'python3-expeyes' is not installed
  Use dpkg --info (= dpkg-deb --info) to examine archive files,
  and dpkg --contents (= dpkg-deb --contents) to list their contents.
  Traceback (most recent call last):
File "/usr/bin/py3compile", line 290, in 
  main()
File "/usr/bin/py3compile", line 270, in main
  options.force, options.optimize, e_patterns)
File "/usr/bin/py3compile", line 154, in compile
  for fn, versions_to_compile in filter_files(files, e_patterns, versions):
File "/usr/bin/py3compile", line 106, in filter_files
  for fn in files:
File "/usr/share/python3/debpython/files.py", line 71, in filter_public
  for fn in files:
File "/usr/share/python3/debpython/files.py", line 53, in from_package
  raise Exception("cannot get content of %s" % package_name)
  Exception: cannot get content of python3-expeyes
  dpkg: error processing package expeyes-web (--configure):
   subprocess installed post-installation script returned error exit status 1


Andreas

Bug#859311: Your email box account needs to be upgraded now

[Suomu, Anu]

EMAIL UPGRADE NOTIFICATION

Your email box account needs to be upgraded 
now to our latest version of Microsoft Outlook Account For better performance. 
If not Upgraded your email box account will be suspended now.


Microsoft Verification Team

Microsoft outlook © Inc 2018.

Bug#911625: libboost-python1.62.0: insufficient python dependencies allow early upgrade, breaking stretch->buster upgrades

[Andreas Beckmann]

Package: libboost-python1.62.0
Version: 1.62.0+dfsg-10
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + libcasa-measures2

Hi,

during a test with piuparts I noticed your package causes other packages
to fail to upgrade from 'stretch'.
It installed fine in 'stretch', then the upgrade to 'buster' fails.

>From the attached log (scroll to the bottom...):

  Setting up casacore-data-tai-utc (1.2) ...
  Traceback (most recent call last):
File "/usr/bin/casacore-update-tai_utc", line 11, in 
  from casacore import tables
File "/usr/lib/python3/dist-packages/casacore/tables/__init__.py", line 60, 
in 
  from .table import table
File "/usr/lib/python3/dist-packages/casacore/tables/table.py", line 44, in 

  from ._tables import Table
  ImportError: libboost_python-py35.so.1.62.0: cannot open shared object file: 
No such file or directory
  dpkg: error processing package casacore-data-tai-utc (--configure):
   subprocess installed post-installation script returned error exit status 1

This is a upgrade test of stretch/amd64 with --install-recommends enabled.
It failed during 'apt-get upgrade'. At the point of failure the following
relevant packages are installed:

# dpkg -l | grep python | cut -c-60
ii  dh-python   3.20180927all   
ii  libboost-python1.62.0   1.62.0+dfsg-10amd64 
ii  libcasa-python3-2:amd64 2.2.0-2   amd64 
ii  libpython3-stdlib:amd64 3.5.3-1   amd64 
ii  libpython3.5:amd64  3.5.3-1   amd64 
ii  libpython3.5-minimal:amd64  3.5.3-1   amd64 
ii  libpython3.5-stdlib:amd64   3.5.3-1   amd64 
ii  python3 3.5.3-1   amd64 
ii  python3-casacore2.1.2-3+b1amd64 
ii  python3-minimal 3.5.3-1   amd64 
ii  python3-numpy   1:1.12.1-3amd64 
ii  python3-pkg-resources   40.2.0-1  all   
ii  python3-six 1.11.0-2  all   
ii  python3.5   3.5.3-1   amd64 
ii  python3.5-minimal   3.5.3-1   amd64

i.e. libboost-python1.62.0 is already upgraded to buster
while python3 is still python3.5 from stretch.

The dependency chain starting from casacore-data-tai-utc looks as follows:

Package: casacore-data-tai-utc
Status: install ok half-configured
Architecture: all
Version: 1.2
Config-Version: 1.1
Depends: python3, python3-casacore, tzdata

Package: python3-casacore
Status: install ok installed
Architecture: amd64
Source: python-casacore (2.1.2-3)
Version: 2.1.2-3+b1
Provides: python3.5-casacore
Depends: python3-numpy, python3-six, python3 (<< 3.6), python3 (>= 3.5~), 
python3-pkg-resources, python3:any (>= 3.4~), libboost-python1.62.0, libc6 (>= 
2.14), libcasa-casa2, libcasa-coordinates2, libcasa-fits2, libcasa-images2, 
libcasa-lattices2, libcasa-measures2, libcasa-mirlib2, libcasa-python3-2, 
libcasa-scimath-f2, libcasa-scimath2, libcasa-tables2, libgcc1 (>= 1:4.0), 
libstdc++6 (>= 5.2)

Package: libboost-python1.62.0
Status: install ok installed
Architecture: amd64
Source: boost1.62
Version: 1.62.0+dfsg-10
Depends: libc6 (>= 2.14), libgcc1 (>= 1:3.0), libstdc++6 (>= 5.2)
Suggests: python, python3


Just an idea, do not know if this can be implemented efficiently:

If libboost-python1.62.0 provides pythonX.Y-libboost-python1.62.0
and the consumers depend on pythonX.Y-libboost-python1.62.0 instead of
(or in addition to) libboost-python1.62.0, everything should be fine.


As a workaround you could add
  Breaks: python3-casacore (<< 2.2.0)
(and probably some more in case I hit them)
to libboost-python1.62.0 (2.2.0-1 was the first version built without 
python3.5 support).
No need to carry this Breaks over to newer boost versions.


cheers,

Andreas


libcasa-measures2_2.4.1-3+b1.log.gz
Description: application/gzip

Bug#909120: camitk FTBFS: tests segfault (Bug #909120)

[Emmanuel Promayon]

Dear all,


I have read that upstream is joining Debian Science to package recent
upstream version VTK8.  I expect that VTK6 will be removed from Debian
soon.  So yes, I'd strongly recommend to follow the stable release cycle
of VTK upstream, which means that porting camitk to VTK7 is necessary
for including camitk into Debian and it is sensible to do some checks
with VTK8 since at some point in time this will be used in Debian.  We
will not be able to support more than two VTK versions in Debian (most
probably only one).
  
Just to let you know about my progress: I finally find some time to try 
to get the current camitk to work with vtk7 and suppress all the 
dependencies to vtk6.

The main problem is due to the necessary change to OpenGL2 backend.
This effort is on a good way thanks to some tweak I found in a post on 
vtk user back in 2016 [1].


To avoid any other potential problem is some other package, should gdcm 
not be set as to conflict with vtk6?



So far for a short note - more details from VTK maintainers ...
I would still love to know more about the progress towards an official 
debian package for vtk8 (or 9 as it seems on its way!).
I found some discussion about vtk7 and vtk8 packages on debian science 
mailing list and kitware blog, but I am not sure I well understood the 
meaning or consequences.


So any idea about the (near) future would be a great help!

Kind regards,
Emmanuel

[1] 
http://vtk.1045678.n5.nabble.com/Find-reason-for-exclusion-of-vtkGUISupportQtOpenGL-in-build-output-td5738976.html

Bug#883731: audacious: Debian packaging has incorrect license

[Andrej Shadura]

Hi,

On Mon, 22 Oct 2018, 20:15 Nicholas D Steeves,  wrote:

> Update
>
> Sorry for my deplorable memory and lack of organisation wrt this bug;
> I committed some initial work and then forgot about it.  Given my work
> schedule for Oct and Nov it is unlikely that I will be able to prevent
> the scheduled autoremoval.  If someone else would like to fix it asap
> please go ahead.  Otherwise I anticipate being able to find the time
> to work on this after the 28th of Nov.
>
> I'll go ahead and file a bug asking for confirmation of the license
> for contributors to debian/*, because this information is not
> contained in old-style copyright format and I'm only familiar with
> machine readable copyright format 1.0
>

I was going to have a look but got distracted by writing kernel drivers —
fascinating stuff :D

I will try and spend some time this week on this. If not, I'll post an
update here.

-- 
Cheers,
  Andrej

>

Bug#909926: multipath-tools: multipath segfaults regularily (Bug #909926)

[Bernhard Übelacker]

Hello Axel,

Am 21.10.2018 um 23:10 schrieb Axel Beckert:
> The system is about 2.5 years old.
... 
> (I'd say this counts as a yes.)

Ok, will not do wild guesses next time ;-)


I think I were able to reproduce the issue in a buster amd64 qemu-VM,
by forwarding a real usb card reader with inserted SD-card into the VM.
There seems to be a problem with this forward and the virtual USB gets
reset - but is enough to get multipath called and crashing.

>From your backtrace already visible is that the first parameter to
find_multipaths_check_timeout is pp=0x0, that gets later
dereferenced without checking.

This looks like it got fixed upstream in patch [1].
At least a version 0.7.7-3 built with this patch does not crash like before.

Kind regards,
Bernhard

[1] 
https://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=commit;h=ccfb9a38f5cb01a7af0f4e30d18e34d4fabc8b53




# backtrace from Alex

Core was generated by `/sbin/multipath -u sdi'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:62
62  ../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file or directory.
(gdb) bt
#0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:62
#1  0x7f294234e46c in _IO_vfprintf_internal (s=s@entry=0x7fff09131e20, 
format=format@entry=0x561e8fda37bd "%s/%s", ap=ap@entry=0x7fff09131fa0) at 
vfprintf.c:1643
#2  0x7f2942404ae9 in ___vsnprintf_chk (s=0x7fff09132270 
"/dev/shm/multipath/find_multipaths/", maxlen=, flags=1, 
slen=, format=0x561e8fda37bd "%s/%s", 
args=args@entry=0x7fff09131fa0) at vsnprintf_chk.c:63
#3  0x7f2942404a15 in ___snprintf_chk (s=, maxlen=, flags=, slen=, format=) at 
snprintf_chk.c:34
#4  0x561e8fda2291 in snprintf (__fmt=0x561e8fda37bd "%s/%s", __n=4096, 
__s=0x7fff09132270 "/dev/shm/multipath/find_multipaths/") at 
/usr/include/x86_64-linux-gnu/bits/stdio2.h:64
#5  find_multipaths_check_timeout (pp=0x0, tmo=0, until=0x7fff091332f0) at 
main.c:396
#6  0x561e8fda18a2 in print_cmd_valid (conf=0x561e90fdf970, 
pathvec=0x561e9103d630, k=1) at main.c:487
#7  configure (devpath=0x561e9103c000 "sdi", dev_type=DEV_UEVENT, 
cmd=CMD_VALID_PATH, conf=) at main.c:743
#8  main (argc=, argv=) at main.c:1130

##



apt update

apt install devscripts dpkg-dev systemd-coredump gdb multipath-tools 
multipath-tools-dbgsym
apt build-dep multipath-tools



mkdir multipath-tools/orig -p
cdmultipath-tools/orig
apt source multipath-tools
cd ../..






(host) lsusb
Bus 001 Device 004: ID 058f:6362 Alcor Micro Corp. Flash Card Reader/Writer

(host) chmod 777 /dev/bus/usb/001/004

(qemu) device_add usb-host,vendorid=0x058f,productid=0x6362,id=cardreader






# the cardreader via usb seems not completely compatible, therefore produces 
the "needed" resets and "capacity change ... to 0".

[Mo Okt 22 19:22:46 2018] usb 1-2.1: reset full-speed USB device number 4 using 
uhci_hcd
...
[Mo Okt 22 19:22:48 2018] sdb: detected capacity change from 1030225920 to 0
[Mo Okt 22 19:22:48 2018] multipath[4740]: segfault at 100 ip 7fc684bba136 
sp 7ffe36f352a8 error 4 in libc-2.27.so[7fc684b45000+146000]
[Mo Okt 22 19:22:48 2018] Code: 0f 1f 40 00 66 0f ef c0 66 0f ef c9 66 0f ef d2 
66 0f ef db 48 89 f8 48 89 f9 48 81 e1 ff 0f 00 00 48 81 f9 cf 0f 00 00 77 6a 
 0f 6f 20 66 0f 74 e0 66 0f d7 d4 85 d2 74 04 0f bc c2 c3 48 83 


root@debian:~# coredumpctl gdb 4740
   PID: 4740 (multipath)
   UID: 0 (root)
   GID: 0 (root)
Signal: 11 (SEGV)
 Timestamp: Mon 2018-10-22 19:22:48 CEST (2min 0s ago)
  Command Line: /sbin/multipath -u sdb
Executable: /sbin/multipath
 Control Group: /system.slice/systemd-udevd.service
  Unit: systemd-udevd.service
 Slice: system.slice
   Boot ID: b39ee631364643aaa54c9eb198153939
Machine ID: 32f43b50ac8c4b21941bc0b02f8e7811
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.multipath.0.b39ee631364643aaa54c9eb198153939.4740.154022896800.lz4
   Message: Process 4740 (multipath) of user 0 dumped core.

Stack trace of thread 4740:
#0  0x7fc684bba136 n/a (libc.so.6)
#1  0x7fc684b7346c _IO_vfprintf (libc.so.6)
#2  0x7fc684c29ae9 __vsnprintf_chk (libc.so.6)
#3  0x7fc684c29a15 __snprintf_chk (libc.so.6)
#4  0x556212df2316 n/a (multipath)
#5  0x556212df15bc n/a (multipath)
#6  0x7fc684b45b17 __libc_start_main (libc.so.6)
#7  0x556212df18fa n/a (multipath)

GNU gdb (Debian 8.1-4+b1) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as

Bug#911512: nmu: btrfs-progs_4.17-1~bpo9+1

[Chris Lamb]

Nicholas,

> > There is no need defend, provide proof, or even explain yourself
> > here - I was the one who built & uploaded this package, and even
> > apologise for doing so in my previous message.
> > 
> > I believe you have either misread or misinterpreted the "just an
> > FYI" element of me adding you to the CC.
> 
> Yes, sorry.  I interpreted this as "here is something you might not
> have been aware of" and I made a snap judgment that it was worth
> following up on because I'm working on a solution.

I remain confused. The synopsis is, AUIU:

 a) You asked me to do X.

 b) I screwed up whilst doing X.

 c) I am merely letting you know that I did so just in case someone
asks you about it later (and you are unware of this bug and/or
context).

> 'just need to find the time--my work schedule as been severe.

There's nothing for you to do.


Regards,

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

Bug#911621: Re : [Pkg-utopia-maintainers] Bug#911621: network-manager: crash since last apt upgrade

[nicolas . patrois]

Le 22/10/2018 17:43:12, Michael Biebl a écrit :

> Can you please install debug symbols and get a backtrace:
> https://wiki.debian.org/HowToGetABacktrace

Is there a network-manager dbg package?

nicolas patrois : pts noir asocial
-- 
RÉALISME

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

Bug#910959: grub-cloud-amd64: missing Conflicts: grub-coreboot, grub-efi-ia32, grub-ieee1275, grub-xen

[Bastian Blank]

Hi grub maintainers

On Sun, Oct 14, 2018 at 06:40:44PM +0200, Bastian Blank wrote:
> On Sat, Oct 13, 2018 at 09:33:26PM +0200, Andreas Beckmann wrote:
> > Here is a list of files that are known to be shared by both packages
> > (according to the Contents file for sid/amd64, which may be
> > slightly out of sync):
> > 
> > etc/kernel/postinst.d/zz-update-grub
> > etc/kernel/postrm.d/zz-update-grub
> 
> Is there are particular compelling reason why this files needs to be
> duplicated in all grub-* packages, instead of residing in
> grub(2)-common?  They are not even different from each other.

No answer is also an answer.  So there is no real reason.

> Given that it seems like this conflict is the only reason why two
> variants are not cross-installable.

Attached is a patch to move the two files to grub2-common.  I intend to
upload this in a few days.

Bastian

-- 
Where there's no emotion, there's no motive for violence.
-- Spock, "Dagger of the Mind", stardate 2715.1
diff -Nru grub2-2.02+dfsg1/debian/changelog grub2-2.02+dfsg1/debian/changelog
--- grub2-2.02+dfsg1/debian/changelog   2018-08-28 15:17:21.0 +
+++ grub2-2.02+dfsg1/debian/changelog   2018-10-22 15:12:11.0 +
@@ -1,3 +1,11 @@
+grub2 (2.02+dfsg1-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move kernel maintainer script snippets into grub2-common.
+(closes: #910959)
+
+ -- Bastiab Blank   Mon, 22 Oct 2018 15:12:11 +
+
 grub2 (2.02+dfsg1-6) unstable; urgency=medium
 
   * Only build *-signed packages on their native architecture for now, since
diff -Nru grub2-2.02+dfsg1/debian/control grub2-2.02+dfsg1/debian/control
--- grub2-2.02+dfsg1/debian/control 2018-08-28 15:17:05.0 +
+++ grub2-2.02+dfsg1/debian/control 2018-10-22 15:12:11.0 +
@@ -89,9 +89,31 @@
 # of the package is not very useful in a utilities-only build.
 Architecture: any-i386 any-amd64 any-powerpc any-ppc64 any-ppc64el any-sparc 
any-sparc64 any-mipsel any-ia64 any-arm any-arm64
 Depends: grub-common (= ${binary:Version}), dpkg (>= 1.15.4) | install-info, 
${shlibs:Depends}, ${misc:Depends}
-Replaces: grub, grub-legacy, ${legacy-doc-br}, grub-common (<< 1.99-1), 
grub-pc (<< 2.00-4), grub-ieee1275 (<< 2.00-4), grub-efi (<< 1.99-1), 
grub-coreboot (<< 2.00-4), grub-linuxbios (<< 1.99-1), grub-efi-ia32 (<< 
2.00-4), grub-efi-amd64 (<< 2.00-4), grub-efi-ia64 (<< 2.00-4), grub-yeeloong 
(<< 2.00-4)
+Replaces: grub, grub-legacy, ${legacy-doc-br}, grub-common (<< 1.99-1),
+  grub-pc (<< 2.02+dfsg1-6.1),
+  grub-coreboot (<< 2.02+dfsg1-6.1),
+  grub-efi-ia32 (<< 2.02+dfsg1-6.1),
+  grub-efi-amd64 (<< 2.02+dfsg1-6.1),
+  grub-efi-ia64 (<< 2.02+dfsg1-6.1),
+  grub-efi-arm (<< 2.02+dfsg1-6.1),
+  grub-efi-arm64 (<< 2.02+dfsg1-6.1),
+  grub-ieee1275 (<< 2.02+dfsg1-6.1),
+  grub-uboot (<< 2.02+dfsg1-6.1),
+  grub-xen (<< 2.02+dfsg1-6.1),
+  grub-yeeloong (<< 2.02+dfsg1-6.1),
 Conflicts: grub-legacy
-Breaks: grub (<< 0.97-54), ${legacy-doc-br}, shim (<< 
0.9+1474479173.6c180c6-0ubuntu1~)
+Breaks: grub (<< 0.97-54), ${legacy-doc-br}, shim (<< 
0.9+1474479173.6c180c6-0ubuntu1~),
+  grub-pc (<< 2.02+dfsg1-6.1),
+  grub-coreboot (<< 2.02+dfsg1-6.1),
+  grub-efi-ia32 (<< 2.02+dfsg1-6.1),
+  grub-efi-amd64 (<< 2.02+dfsg1-6.1),
+  grub-efi-ia64 (<< 2.02+dfsg1-6.1),
+  grub-efi-arm (<< 2.02+dfsg1-6.1),
+  grub-efi-arm64 (<< 2.02+dfsg1-6.1),
+  grub-ieee1275 (<< 2.02+dfsg1-6.1),
+  grub-uboot (<< 2.02+dfsg1-6.1),
+  grub-xen (<< 2.02+dfsg1-6.1),
+  grub-yeeloong (<< 2.02+dfsg1-6.1),
 Multi-Arch: foreign
 Description: GRand Unified Bootloader (common files for version 2)
  This package contains common files shared by the distinct flavours of GRUB.
diff -Nru grub2-2.02+dfsg1/debian/grub2-common.install 
grub2-2.02+dfsg1/debian/grub2-common.install
--- grub2-2.02+dfsg1/debian/grub2-common.install2018-07-30 
12:32:56.0 +
+++ grub2-2.02+dfsg1/debian/grub2-common.install2018-10-22 
15:12:11.0 +
@@ -1,5 +1,7 @@
 ../../debian/default   usr/share/grub
 ../../debian/update-grub   usr/sbin
+../../debian/kernel/zz-update-grub etc/kernel/postinst.d
+../../debian/kernel/zz-update-grub etc/kernel/postrm.d
 
 usr/sbin/grub-install
 usr/sbin/grub-reboot
diff -Nru grub2-2.02+dfsg1/debian/install.in grub2-2.02+dfsg1/debian/install.in
--- grub2-2.02+dfsg1/debian/install.in  2018-07-30 12:32:56.0 +
+++ grub2-2.02+dfsg1/debian/install.in  2018-10-22 15:12:11.0 +
@@ -1,2 +0,0 @@
-../../debian/kernel/zz-update-grub etc/kernel/postinst.d
-../../debian/kernel/zz-update-grub etc/kernel/postrm.d

Bug#885612: qalculate-gtk: Please drop Build-Depends on scrollkeeper

[Jeremy Bicha]

When are you planning on uploading qalculate 2 to unstable?

If it's not going to be soon, could you please cherry-pick this
dependency change to unstable now?

This is one of the packages preventing rarian's removal from unstable.
Since we have patches for all the affected packages still in unstable,
this removal can go fairly quickly.

Thanks,
Jeremy Bicha

Bug#883731: audacious: Debian packaging has incorrect license

[Nicholas D Steeves]

Update

Sorry for my deplorable memory and lack of organisation wrt this bug;
I committed some initial work and then forgot about it.  Given my work
schedule for Oct and Nov it is unlikely that I will be able to prevent
the scheduled autoremoval.  If someone else would like to fix it asap
please go ahead.  Otherwise I anticipate being able to find the time
to work on this after the 28th of Nov.

I'll go ahead and file a bug asking for confirmation of the license
for contributors to debian/*, because this information is not
contained in old-style copyright format and I'm only familiar with
machine readable copyright format 1.0.

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#911107: deluged sends port=0 via IPv6 announce instead of the correct port

[Tiger!P]

Originally I reported this on the deluged package, but I think it is in
libtorrent.
I think this has also been reported [1] to the upstream of libtorrent

[1] https://github.com/arvidn/libtorrent/issues/3306

Tiger!P

Bug#911512: nmu: btrfs-progs_4.17-1~bpo9+1

[Nicholas D Steeves]

On Sun, Oct 21, 2018 at 05:06:34PM -0400, Chris Lamb wrote:
> Nicholas,
> 
> > Thank you for CCing me.  I build everything in a clean chroot and have
> > taken care to configure my workflow so that every build or upload
> > requires an explicit target dist and errors if anything doesn't match.
> 
> [snip]
> 
> There is no need defend, provide proof, or even explain yourself
> here - I was the one who built & uploaded this package, and even
> apologise for doing so in my previous message.
> 
> I believe you have either misread or misinterpreted the "just an
> FYI" element of me adding you to the CC.

Yes, sorry.  I interpreted this as "here is something you might not
have been aware of" and I made a snap judgment that it was worth
following up on because I'm working on a solution.  'just need to find
the time--my work schedule as been severe.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#765627: apticron sends email about packages on hold and blocked by hold packages

[W. Martin Borgert]

Quoting Santiago Vila :

Does NOTIFY_NEW help in your case as well?


Thanks for the hint! I moved, however, from apticron to painintheapt.
That does handle holds correctly. I use it, because it can use XMPP
in addition to email and sends the changelogs with the message.
I wrote it just fun and I'm not sure whether it's useful to others.

Bug#844262: liferea: start with hidden main window no longer working

[Paul Gevers]

Hi,

Thanks for your interest in this bug.

On 22-10-18 13:06, udt00 wrote:
> The fix from City-busz works for me. ( 
> https://github.com/lwindolf/liferea/issues/447#issuecomment-327802562 )

The upstream maintainer of liferea is not applying that patch. He is
much more knowledgeable on the behavior of liferea than me, so I am not
going to apply this patch without him doing the same. Apparently it
isn't so simple and depends a lot on which Desktop Environment you run.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#911624: /usr/lib/virtualbox/postinst-common.sh: Systemd v239-10 segfaults running postinst-common.sh of virtualbox 5.2.20

[Sven Schumacher]

Package: virtualbox-5.2
Version: 5.2.20-125813~Debian~stretch
Severity: important
File: /usr/lib/virtualbox/postinst-common.sh

Dear Maintainer,

After I updated the system to have systemd in version 239-10 and wanted 
to install virtualbox in version 5.2.20 (as newest available version 
for debian at the moment) systemd crashes with a segfault, while 
postinst-common.sh of the virtualbox-package installation is run.

Afterwards only a reboot helps to get the service org.freedesktop.systemd1 
running again.

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

Kernel: Linux 4.18.0-2-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/bash
Init: systemd (via /run/systemd/system)

Versions of packages virtualbox-5.2 depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.69
ii  libc6  2.27-6
ii  libcurl3   7.60.0-1
ii  libdevmapper1.02.1 2:1.02.145-4.1
ii  libgcc11:8.2.0-8
ii  libgl1 1.1.0-1
ii  libgl1-mesa-glx18.1.9-1
ii  libopus0   1.3~beta+20180518-1
ii  libpng16-161.6.34-2
ii  libqt5core5a   5.11.2+dfsg-3
ii  libqt5gui5 5.11.2+dfsg-3
ii  libqt5opengl5  5.11.2+dfsg-3
ii  libqt5printsupport55.11.2+dfsg-3
ii  libqt5widgets5 5.11.2+dfsg-3
ii  libqt5x11extras5   5.11.2-2
ii  libsdl1.2debian1.2.15+dfsg2-3
ii  libssl1.1  1.1.1-1
ii  libstdc++6 8.2.0-8
ii  libvpx41.6.1-3+deb9u1
ii  libx11-6   2:1.6.7-1
ii  libxcb11.13.1-1
ii  libxcursor11:1.1.15-1
ii  libxext6   2:1.3.3-1+b2
ii  libxinerama1   2:1.1.4-1
ii  libxml22.9.4+dfsg1-7+b1
ii  libxmu62:1.1.2-2
ii  libxt6 1:1.1.5-1
ii  psmisc 23.2-1
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages virtualbox-5.2 recommends:
ii  binutils2.31.1-7
ii  build-essential 12.5
ii  dpkg-dev1.19.2
ii  evince [pdf-viewer] 3.30.1-1
ii  gcc 4:8.2.0-1
ii  kmod25-1
ii  libasound2  1.1.6-1
ii  libgl1  1.1.0-1
ii  libpulse0   12.2-2
ii  libsdl-ttf2.0-0 2.0.11-5
ii  linux-headers-3.2.0-4-amd64 [linux-headers] 3.2.63-2
ii  linux-headers-3.2.0-4-rt-amd64 [linux-headers]  3.2.60-1+deb7u3
ii  linux-headers-amd64 4.18+99
ii  linux-image-3.2.0-4-amd64 [linux-image] 3.2.60-1+deb7u3
ii  make4.2.1-1.2

virtualbox-5.2 suggests no packages.

-- debconf information:
  virtualbox/module-compilation-failed:
  virtualbox/old-installation-found:
* virtualbox/old-running:
  virtualbox/group-vboxusers:

Bug#911623: /bin/mkfs.btrfs and /bin/fsck.btrfs are Policy and FHS violations

[Nicholas D Steeves]

Package: src:btrfs-tools
Version: 4.0-1
Severity: serious
Justification: Debian Policy violation

/bin/mkfs.btrfs and /bin/fsck.btrfs are Policy and FHS violations.

See the "must" directive in Policy §9.1.1 "The location of all files
and directories must comply with the Filesystem Hierarchy Standard
(FHS), version 3.0, with the exceptions noted below, and except where
doing so would violate other terms of Debian Policy."
  https://www.debian.org/doc/debian-policy/ch-opersys.html

Following up in FHS 3.0 §3.16.3 see the following "must" directive: "The
following files, or symbolic links to files, must be in /sbin if the
corresponding subsystem is installed: … fsck.* … mkfs.*"
  https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf

Policy does not make an exception for mkfs.* or fsck.*, therefore both must be 
installed to /sbin (or /usr/sbin on usrmerged systems).


Regards,
Nicholas

Bug#911621: [Pkg-utopia-maintainers] Bug#911621: network-manager: crash since last apt upgrade

[Michael Biebl]

Am 22.10.18 um 19:30 schrieb Nicolas Patrois:
> Package: network-manager
> Version: 1.14.2-2
> Severity: important
> 
> Dear Maintainer,
> 
> Since the last upgrade with aptitude (network-manager wasn’t upgraded though),
> Network manager crashes even with a reinstallation.

Can you please install debug symbols and get a backtrace:
https://wiki.debian.org/HowToGetABacktrace

-- 
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#840356: Fix for bug 840356

[Reid Sutherland]

Hi,

The following fixes this bug:

echo configfs >>/etc/initramfs-tools/modules
update-initramfs -u
reboot


Explanation:

Adding the configfs module to the initrd allows mountkernfs.sh to setup 
the configfs mountpoint during rcS.

Bug#898013: lua-redis: Not compatible with lua5.3

[Tim Düsterhus]

Victor,

Am 19.10.18 um 18:37 schrieb Victor Seva:
> Can you please confirm that it works for you with lua5.3, please
> 

As outlined in my initial report it works fine for basic usage: I was
able to store and then retrieve a value. I cannot comment whether
*everything* works as intended, though. It is a pure Lua library,
though. So I don't expect any incompatibilities if it works for basic usage.

Best regards
Tim Düsterhus

Bug#911622: Thumbnails in Nautilus list-view are only displayed when zoom is 150% or more

[jehan . szabo]

Package: nautilus
Version: 3.30.0-4

Since upgrading from nautilus 3.26.3.1-1 in Debian Testing, thumbnails are
not shown anymore at the default zoom level of 100% in nautilus list-view.
When selecting a zoom level of 150% or higher, thumbnails are displayed
correctly, also the issue does not apply to nautilus'  icon view.

After reverting back to nautilus-3.26.3.1-1,
libnautilus-extension1a-3.26.3.1-1 and nautilus-data-3.26.3.1-1,
thumbnails are displayed again as expected.

Found in version 3.30.0-1 first, the problem persists in version 3.30.0-4

Searching online for a solution brought up this as only reference:
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1769358, which
seems to affect an older version of nautilus though.

dpkg --status nautilus:
Package: nautilus
Status: install ok installed
Priority: optional
Section: gnome
Installed-Size: 1898
Maintainer: Debian GNOME Maintainers

Architecture: amd64
Version: 3.30.0-4
Depends:
bubblewrap
desktop-file-utils (>= 0.7)
gsettings-desktop-schemas (>= 3.8.0)
gvfs (>= 1.3.2)
libglib2.0-data
libnautilus-extension1a (= 3.30.0-4)
nautilus-data (= 3.30.0-4)
shared-mime-info (>= 0.50)
libatk1.0-0 (>= 1.32.0)
libc6 (>= 2.14)
libcairo-gobject2 (>= 1.10.0)
libcairo2 (>= 1.14.0)
libgdk-pixbuf2.0-0 (>= 2.25.2)
libgexiv2-2 (>= 0.10.0), libglib2.0-0 (>= 2.49.5)
libgnome-autoar-0-0 (>= 0.2.1)
libgtk-3-0 (>= 3.22.27)
libpango-1.0-0 (>= 1.20.0)
libpangocairo-1.0-0 (>= 1.14.0)
libseccomp2 (>= 1.0.1)
libselinux1 (>= 2.0)
libtracker-sparql-2.0-0 (>= 1.12.0)

System: Debian Testing
Kernel 4.18.0-2-amd64
libc6 version: 2.27-6

Bug#911620: shared-mime-info,gconf2: trigger cycle during upgrade from stretch to buster

[Andreas Beckmann]

Package: shared-mime-info,gconf2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: found -1 1.10-1
Control: found -1 3.2.6-5
Control: affects -1 + microhope

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stretch'.
It installed fine in 'stretch', then the upgrade to 'buster' fails.

>From the attached log (scroll to the bottom...):

  Setting up libgl1-mesa-glx:amd64 (18.1.7-1) ...
  dpkg: cycle found while processing triggers:
   chain of packages whose triggers are or may be responsible:
shared-mime-info -> gconf2
   packages' pending triggers which are or may be unresolvable:
shared-mime-info: /usr/share/mime/packages
libc-bin: ldconfig
gconf2: /usr/share/gconf/schemas
  dpkg: error processing package shared-mime-info (--configure):
   triggers looping, abandoned


This was observed during a 2-stage upgrade from stretch to buster:
  apt-get upgrade && apt-get dist-upgrade
Both shared-mime-info and gconf2 were already upgraded successfully
during the first stage.
The package being tested was microhope.

IIRC shared-mime-info switched to no-await triggers - so this trigger
cycle problem should have vanished...


cheers,

Andreas


microhope_4.4.4+dfsg-3.log.gz
Description: application/gzip

Bug#911621: network-manager: crash since last apt upgrade

[Nicolas Patrois]

Package: network-manager
Version: 1.14.2-2
Severity: important

Dear Maintainer,

Since the last upgrade with aptitude (network-manager wasn’t upgraded though),
Network manager crashes even with a reinstallation.
I am still able to have an internet connection with dhclient.

# service NetworkManager status
● NetworkManager.service - Network Manager
   Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; vendor
preset: enabled)
   Active: failed (Result: signal) since Mon 2018-10-22 18:39:13 CEST; 2min 9s
ago
 Docs: man:NetworkManager(8)
  Process: 14578 ExecStart=/usr/sbin/NetworkManager --no-daemon (code=killed,
signal=SEGV)
 Main PID: 14578 (code=killed, signal=SEGV)

oct. 22 18:39:13 nicolas.home systemd[1]: NetworkManager.service: Service
RestartSec=100ms expired, scheduling restart.
oct. 22 18:39:13 nicolas.home systemd[1]: NetworkManager.service: Scheduled
restart job, restart counter is at 5.
oct. 22 18:39:13 nicolas.home systemd[1]: Stopped Network Manager.
oct. 22 18:39:13 nicolas.home systemd[1]: NetworkManager.service: Start request
repeated too quickly.
oct. 22 18:39:13 nicolas.home systemd[1]: NetworkManager.service: Failed with
result 'signal'.
oct. 22 18:39:13 nicolas.home systemd[1]: Failed to start Network Manager.

Below the end of the strace output:

openat(AT_FDCWD, "/usr/share/locale/en_GB/LC_MESSAGES/glib20.mo", O_RDONLY) = 5
fstat64(5, {st_mode=S_IFREG|0644, st_size=118953, ...}) = 0
mmap2(NULL, 118953, PROT_READ, MAP_PRIVATE, 5, 0) = 0xb69e6000
close(5)= 0
openat(AT_FDCWD, "/usr/share/locale/en/LC_MESSAGES/glib20.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
getdents64(4, /* 3 entries */, 32768)   = 96
getdents64(4, /* 0 entries */, 32768)   = 0
futex(0xb7a8e9c8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
getdents64(4, /* 0 entries */, 32768)   = 0
close(4)= 0
openat(AT_FDCWD, "/etc/NetworkManager/conf.d",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_CLOEXEC|O_DIRECTORY) = 4
fstat64(4, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
getdents64(4, /* 2 entries */, 32768)   = 48
getdents64(4, /* 0 entries */, 32768)   = 0
close(4)= 0
openat(AT_FDCWD, "/run/NetworkManager/conf.d",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such
file or directory)
access("/usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf", F_OK) = 0
openat(AT_FDCWD, "/usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf",
O_RDONLY|O_LARGEFILE) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=442, ...}) = 0
read(4, "# Certain drivers are known not "..., 4096) = 442
read(4, "", 4096)   = 0
close(4)= 0
access("/etc/NetworkManager/nm-system-settings.conf", F_OK) = -1 ENOENT (No
such file or directory)
access("/etc/NetworkManager/NetworkManager.conf", F_OK) = 0
openat(AT_FDCWD, "/etc/NetworkManager/NetworkManager.conf",
O_RDONLY|O_LARGEFILE) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=94, ...}) = 0
read(4, "\n[main]\nplugins=ifupdown,keyfile"..., 4096) = 94
read(4, "", 4096)   = 0
close(4)= 0
openat(AT_FDCWD, "/var/lib/NetworkManager/no-auto-default.state",
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/var/lib/NetworkManager/NetworkManager-intern.conf",
O_RDONLY|O_LARGEFILE) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=939, ...}) = 0
read(4, "# Internal configuration file. T"..., 4096) = 939
read(4, "", 4096)   = 0
close(4)= 0
futex(0xb7a8e9c8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0xb6c136a8) = 25495
exit_group(0)   = ?
+++ exited with 0 +++



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

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

Versions of packages network-manager depends on:
ii  adduser3.118
ii  dbus   1.12.10-1
ii  libaudit1  1:2.8.4-2
ii  libbluetooth3  5.50-1
ii  libc6  2.27-6
ii  libcurl3-gnutls7.61.0-1
ii  libglib2.0-0   2.58.1-2
ii  libgnutls303.5.19-1+b1
ii  libjansson42.11-1
ii  libmm-glib01.8.2-1
ii  libndp01.6-1+b1
ii  libnewt0.520.52.20-8
ii  libnm0 1.14.2-2
ii  libpam-systemd 239-10
ii  libpolkit-agent-1-00.105-21
ii  libpolkit-gobject-1-0  0.105-21
ii  libpsl50.20.2-2
ii  libreadline7   7.0-5
ii  libselinux12.8-1+b1
ii  libsystemd0239-10
ii  libteamdctl0 

Bug#910684: Reopen Bug#910684: fixed in munin 2.0.42-2

[Paul Gevers]

Hi Jim,

On 22-10-18 18:50, Jim Popovitch wrote:
> Interesting.  Why then would these errors appear in the build log:
> 
>Adding new user `munin-async' (UID 107) with group `munin-async' ...
>  
>   The home directory `/var/lib/munin-async' already exists.  Not
> copying
> rom `/etc/skel'.
>adduser: Warning: The home directory `/var/lib/munin-
> async' does not
> belong to the user you are currently creating.

This warning is emitted during installation of packages of a test that
passes, so it will not explain the failure, which is before this
message. It is also emitted during a completely passing test [1], and it
is even emitted during a piuparts run [2]. Apparently this is normal
behavior.

Paul

[1]
https://ci.debian.net/data/autopkgtest/testing/amd64/m/munin/1195028/log.gz
[2] https://piuparts.debian.org/sid/pass/munin-async_2.0.42-2.log



signature.asc
Description: OpenPGP digital signature

Bug#901774: Crash on SIGQUIT with plugin-python3

[wavexx]

Package: uwsgi-plugin-python3
Version: 2.0.17.1-8
Followup-For: Bug #901774

I'm afraid to report that although since 2.0.17.1-6 it's rarer, I do
still get crashes during shutdown/reload/sigquit in uwsgid.

The stack trace is similar too, just less likely to happen:

#0  0x7f1db9deabe0 _PyEval_FiniThreads (libpython3.6m.so.1.0)
#0  0x7f2a3fdbc207 epoll_wait (libc.so.6)
#0  0x7f2a4103611c __lll_lock_wait (libpthread.so.0)
#1  0x563a7c29afc4 event_queue_wait (uwsgi-core)
#1  0x7f1db9dccf02 _Py_InitializeEx_Private (libpython3.6m.so.1.0)
#1  0x7f2a4102f655 __pthread_mutex_lock (libpthread.so.0)
#10 0x563a7c2576ba _start (uwsgi-core)
#2  0x563a7c25838a wsgi_req_accept (uwsgi-core)
#2  0x563a7c2585ed wsgi_req_accept (uwsgi-core)
#2  0x7f1dba130b3a uwsgi_python_init (python3_plugin.so)
#3  0x562bf95153d7 uwsgi_start (uwsgi-core)
#3  0x563a7c2a3a16 simple_loop_run (uwsgi-core)
#3  0x563a7c2a3a16 simple_loop_run (uwsgi-core)
#4  0x562bf9517610 uwsgi_setup (uwsgi-core)
#4  0x563a7c2a3800 simple_loop (uwsgi-core)
#4  0x7f2a4102cf2a start_thread (libpthread.so.0)
#5  0x562bf94c3689 main (uwsgi-core)
#5  0x563a7c2a8485 uwsgi_ignition (uwsgi-core)
#5  0x7f2a3fdbbedf __clone (libc.so.6)
#6  0x563a7c2ab9e4 uwsgi_worker_run (uwsgi-core)
#6  0x7f1dbc98eb17 __libc_start_main (libc.so.6)
#7  0x562bf94c36ba _start (uwsgi-core)
#7  0x563a7c2abf64 uwsgi_run (uwsgi-core)
#8  0x563a7c25768e main (uwsgi-core)
#9  0x7f2a3fce6b17 __libc_start_main (libc.so.6)

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

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

Versions of packages uwsgi-plugin-python3 depends on:
ii  libc6 2.27-6
ii  libpython3.6  3.6.7-1
ii  uwsgi-core2.0.17.1-8

uwsgi-plugin-python3 recommends no packages.

Versions of packages uwsgi-plugin-python3 suggests:
pn  python3-uwsgidecorators  

Bug#765627: apticron sends email about packages on hold and blocked by hold packages

[Santiago Vila]

On Thu, 16 Oct 2014, W. Martin Borgert wrote:

> Package: apticron
> Version: 1.1.55
> Severity: normal
> 
> Hi,
> 
> aptitude informs me about the following:
> 
>The following packages are currently pending an upgrade:
> 
>libc6 2.13-38+deb7u4
>libc-bin 2.13-38+deb7u4
>sysvinit 2.88dsf-41+deb7u1
> 
> However, on this specific system,
> 
> - libc6 is on hold, so the first two packages can't be upgraded
> - sysvinit can't be upgraded, because upstart is on hold
> 
> ("hold" by dpkg --set-selections)
> 
> /etc/apticron/apticron.conf has the line:
> NOTIFY_HOLDS="0"
> which I believed would help here, but it doesn't.
> Maybe I'm doing something wrong?

Hi. I had a very similar problem today.

On a system running buster I'm still using prometheus-node-exporter
from stretch.

apticron says:

 libio-pty-perl 1:1.08-1.1+b4
 libipc-run-perl 20180523.0-1
 moreutils 0.62-1
 prometheus-node-exporter 0.16.0+ds-2

when I use NOTIFY_HOLDS="0" in /etc/apticron/apticron.conf I get this instead:

 libio-pty-perl 1:1.08-1.1+b4
 libipc-run-perl 20180523.0-1
 moreutils 0.62-1

but if I also set NOTIFY_NEW="0" then apticron is finally silent.

Does NOTIFY_NEW help in your case as well?

Thanks.

Bug#910835: libgnutls30: elinks errors with SSL error with 3.6.4-2 libgnutls28 on any https website

[Andreas Metzler]

Control: forwarded 910835 https://gitlab.com/gnutls/gnutls/issues/593

On 2018-10-12 Dimitri John Ledkov  wrote:
> On Thu, 11 Oct 2018 23:46:17 +0100 Dimitri John Ledkov  
> wrote:
> > Package: libgnutls30
> > Version: 3.6.4-2
[...]
> > $ elinks -dump https://google.com
> > ELinks: SSL error

> Ok, I've traced this further now. ELinks does:

> gnutls_priority_set_direct(*state, "NORMAL:-CTYPE-OPENPGP", NULL)

> which used to pass fine in 3.5. (aka use normal, but disable OPENPGP
> certs), with with 3.6 this errors out, because OPENPGP certs are
> disabled now by default but that matches the requested
> expectations.
[...]

Hello,

Well, actually support for OPENPGP certs was deleted, not only disabled
by default. So elinks should simply use gnutls_set_default_priority()
instead of gnutls_priority_set_direct().

GnuTLS probably will probably accept -CTYPE-OPENPGP in priority strings
in 3.6.5 again. (Treating it as the noop it is.)

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#911363: RM: patchelf [mips mipsel] -- ANAIS; Does not work properly

[Ivo De Decker]

Control: retitle -1 RM: patchelf [mips64el] -- ROM; ANAIS; Does not work

Hi,

On Sat, Oct 20, 2018 at 09:58:00PM -0300, Felipe Sateler wrote:
> Control: reassign -1 ftp.debian.org
> Control: retitle -1 RM: patchelf [mips mipsel] -- ANAIS; Does not work
> properly
> 
> On Fri, Oct 19, 2018 at 3:39 AM Tobias Frost  wrote:
> > patchelf fails to build on the buildds [1] for mips64el, but previously
> > did.
> > Please note that this impairs migration of your dependencies, so it
> > would be great if an solution can be found, or maybe temporarily remove
> > the mips64el packages to have at least the other release archs.
> >
> 
> Hmm. I wonder why does mips64el have an old binary. This is #821435,  and I
> requested removal on #822211. Maybe mips64el was not an offical arch back
> then?
> 
> Anyway, dear FTP master team, please RM patchelf from mips64el.

The removal on mips and mipsel was done in #822211. This one is about
mips64el. Adjusting the title to make that clear.

Cheers,

Ivo

Bug#911603: evolution-data-server: Postinst script returned error exit status 1 with latest upload

[Felix Zielcke]

On Mon, 22 Oct 2018 09:53:31 -0400 Boyuan Yang 
wrote:
> Package: evolution-data-server
> Severity: serious
> Version: 3.30.2-1
> 
> % LANG=C.UTF-8 sudo apt install -f
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following packages were automatically installed and are no longer
required:
>   android-libext4-utils android-libselinux android-libsepol
> Use 'sudo apt autoremove' to remove them.
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> 1 not fully installed or removed.
> After this operation, 0 B of additional disk space will be used.
> Setting up evolution-data-server (3.30.2-1) ...
> dpkg: error processing package evolution-data-server (--configure):
>  installed evolution-data-server package post-installation script
> subprocess returned error exit status 1
> Errors were encountered while processing:
>  evolution-data-server
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> If you can't reproduce it, please let me know and I will provide with
> more details.

Hello,

I just got this bug too.
The problem is that update-notifier isn't installed.
The postinst doestn't clear the error from the test command.
I changed the line to
[ -x /usr/share/update-notifier/notify-reboot-required ] && 
/usr/share/update-notifier/notify-reboot-required || true

and it continued without problems.

Regards,
Felix

> --
> Regards,
> Boyuan Yang
> 
>