date:20190913

Source: gnome-keyring
Version: 3.28.2-5
Severity: important
Tags: bullseye sid experimental

gnome-keyring has essentially the same bug as gcr: its test scripts (taken
from Cockpit) assume GLib tests default to GTester output syntax (and
translate it into TAP in a wrapper script), but in GLib 2.62+, GLib tests
default to TAP (which the wrapper cannot parse).

This bug is still present in experimental.

The solution is to apply the equivalent of
https://github.com/cockpit-project/cockpit/commit/f254f58691d971eeec252ba8064db3eca3df2370

See https://github.com/cockpit-project/cockpit/pull/11998

smcv

Bug#940158: pm-powersave: not found

2019-09-13 Thread Francois Mescam

Package: acpi-support
Version: 0.143-3
Severity: normal

Dear Maintainer,

just after the boot of my laptop I obtain the message :

Sep 13 09:10:01 eiffel6 power.sh[740]: /etc/acpi/power.sh: 13: pm-powersave: 
not found

Thanks for your help

François


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

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

Versions of packages acpi-support depends on:
ii  acpi-support-base  0.143-3
ii  acpid  1:2.0.32-1
ii  lsb-base   11.1.0
ii  x11-xserver-utils  7.7+8

Versions of packages acpi-support recommends:
ii  acpi-fakekey  0.143-3
ii  rfkill2.34-0.1

Versions of packages acpi-support suggests:
pn  radeontool   
ii  vbetool  1.1-4+b1
ii  xinput   1.6.2-1+b1
pn  xscreensaver | gnome-screensaver | kscreensaver | xautolock | x  

-- no debconf information

Bug#940159: realmd: FTBFS with GLib 2.62: ERROR: missing test

Source: realmd
Version: 0.16.3-2
Severity: important
Tags: ftbfs bullseye sid patch fixed-upstream

When built against GLib 2.62, realmd FTBFS with test failures like this:

> make  check-TESTS
> make[4]: Entering directory '/<>'
> make[5]: Entering directory '/<>'
> ERROR: test-dn-util 1 - missing test
> ERROR: test-dn-util 2 - missing test
> ERROR: test-dn-util 3 - missing test
> ERROR: test-dn-util 4 - missing test
> ...

This is because it has essentially the same bug that was recently fixed
in gcr: its test scripts (taken from Cockpit) assume GLib tests default to
GTester output syntax (and translate it into TAP in a wrapper script), but
in GLib 2.62+, GLib tests default to TAP (which the wrapper cannot parse).

GLib 2.62 is currently only available in experimental, but we should
upload it to unstable soon.

Fixed upstream in:
https://gitlab.freedesktop.org/realmd/realmd/commit/5ae42c176e7bb550fc6cf10f29e75f58c733ae4f

smcv
>From 5ae42c176e7bb550fc6cf10f29e75f58c733ae4f Mon Sep 17 00:00:00 2001
From: Sumit Bose 
Date: Fri, 2 Aug 2019 12:10:43 +0200
Subject: [PATCH] Remove support for deprecated gtester format

Support for the already deprecated gtester format was remove from recent
versions of glib2 but the test still call the tab-gtester conversion
tool.

This patch removes tab-gtester and the tab format is used directly.

Related to https://gitlab.freedesktop.org/realmd/realmd/issues/21
---
 Makefile.am   |   3 +-
 build/tap-gtester | 204 --
 2 files changed, 1 insertion(+), 206 deletions(-)
 delete mode 100755 build/tap-gtester

diff --git a/Makefile.am b/Makefile.am
index 27e3494..4ffd5b4 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -161,7 +161,7 @@ endif
 #
 
 LOG_DRIVER = $(top_srcdir)/build/tap-driver
-LOG_COMPILER = $(top_srcdir)/build/tap-gtester
+LOG_COMPILER = sh -c '"$$0" "$$@" --tap'
 
 VALGRIND_ARGS = --trace-children=no --quiet --error-exitcode=33 \
 	--suppressions=valgrind-suppressions --gen-suppressions=all \
@@ -183,7 +183,6 @@ recheck-memory: valgrind-suppressions
 
 EXTRA_DIST += \
 	$(LOG_DRIVER) \
-	$(LOG_COMPILER) \
 	$(VALGRIND_SUPPRESSIONS) \
 	$(NULL)
 
diff --git a/build/tap-gtester b/build/tap-gtester
deleted file mode 100755
index bbda266..000
--- a/build/tap-gtester
+++ /dev/null
@@ -1,204 +0,0 @@
-#!/usr/bin/python3
-# This can also be run with Python 2.
-
-# Copyright (C) 2014 Red Hat, Inc.
-#
-# Cockpit is free software; you can redistribute it and/or modify it
-# under the terms of the GNU Lesser General Public License as published by
-# the Free Software Foundation; either version 2.1 of the License, or
-# (at your option) any later version.
-#
-# Cockpit is distributed in the hope that it will be useful, but
-# WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public License
-# along with Cockpit; If not, see .
-
-#
-# This is a test output compiler which produces TAP from GTest output
-# if GTest output is detected.
-#
-# Versions of glib later than 2.38.x output TAP natively when tests are
-# run with the --tap option. However we can't depend on such a recent
-# version of glib for our purposes.
-#
-# This implements the Test Anything Protocol (ie: TAP)
-# https://metacpan.org/pod/release/PETDANCE/Test-Harness-2.64/lib/Test/Harness/TAP.pod
-#
-
-import argparse
-import os
-import select
-import signal
-import subprocess
-import sys
-
-# Yes, it's dumb, but strsignal is not exposed in python
-# In addition signal numbers varify heavily from arch to arch
-def strsignal(sig):
-for name in dir(signal):
-if name.startswith("SIG") and sig == getattr(signal, name):
-return name
-return str(sig)
-
-
-class NullCompiler:
-def __init__(self, command):
-self.command = command
-
-def input(self, line):
-sys.stdout.write(line)
-
-def process(self, proc):
-while True:
-line = proc.stdout.readline()
-if not line:
-break
-self.input(line)
-proc.wait()
-return proc.returncode
-
-def run(self, proc, line=None):
-if line:
-self.input(line)
-return self.process(proc)
-
-
-class GTestCompiler(NullCompiler):
-def __init__(self, filename):
-NullCompiler.__init__(self, filename)
-self.test_num = 0
-self.test_name = None
-self.test_remaining = []
-
-def input(self, line):
-line = line.strip()
-if line.startswith("GTest: "):
-   (cmd, unused, data) = line[7:].partition(": ")
-   cmd = cmd.strip()
-   data = data.strip()
-   if cmd == "run":
-   self.test_name = data
-   assert self.test_name in self.test_remaining, "%s %s" % (self.test_name, re

Bug#938494: skimage (build-)depends on python-cloudpickle which has already been dropped

Hi,

as Peter Green found out the cloudpickle source package droped Python2
support which makes bug #938494 serious.  I guess it would be even
harder to drop python-skimage right now since this would affect
python-numpy and according to

   $ apt-cache rdepends python-numpy | sort | uniq | wc -l

339 reverse dependencies.  I have no better solution than just pinging
bug #938494 from time to time - and to ping this list to work harder on
Python3 migration.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#940156: pydantic: please make the build reproducible

2019-09-13 Thread Chris Lamb

forwarded 940156 https://github.com/samuelcolvin/pydantic/pull/805
thanks

I've forwarded this upstream here:

  https://github.com/samuelcolvin/pydantic/pull/805


Regards,

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

Bug#940160: ITP: r-cran-systemfonts -- system native font finding for GNU R

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-systemfonts -- system native font finding for GNU R
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-systemfonts
  Version : 0.1.1
  Upstream Author : Thomas Lin Pedersen,
* URL : https://cran.r-project.org/package=systemfonts
* License : MIT
  Programming Lang: GNU R
  Description : system native font finding for GNU R
 Provides system native access to the font catalogue. As font
 handling varies between systems it is difficult to correctly locate
 installed fonts across different operating systems. The 'systemfonts'
 package provides bindings to the native libraries on Windows, macOS and
 Linux for finding font files that can then be used further by e.g. graphic
 devices. The main use is intended to be from compiled code but 'systemfonts'
 also provides access from R.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-systemfonts

Bug#940161: glib2.0: New upstream stable release 2.62.x

Source: glib2.0
Version: 2.60.6-2
Severity: wishlist
Control: block -1 by 940086 940157 940159

As usual there is a new GLib stable branch for GNOME 3.34, which I hope
everyone in the GNOME team already knows about!

I'm opening this bug so that we have somewhere to track the FTBFSs related
to GLib's test framework dropping the deprecated GTester format.

smcv

Bug#940162: [mmdebstrap] Allow overriding of binfmt_misc search

2019-09-13 Thread Giovanni Mascellani

Package: mmdebstrap
Version: 0.4.1-6
Severity: wishlist

Hi,

it seems that mmdebstrap does not work inside a docker container. After
installing docker.io and qemu-user-static on a computer, for example:

# docker run -it --rm debian:unstable
[now inside the container]
# apt update
# apt install qemu-user-static mmdebstrap
# mmdebstrap --architectures=armhf --verbose unstable /tmp/debian.tar.gz
'http://deb.debian.org/debian'
I: automatically chosen mode: root
I: armhf cannot be executed, falling back to qemu-user
E: binfmt_misc not found in /proc/mounts -- not mounted?

Here mmdebstrap fails because it tries to look for the binfmt_misc
filesystem, which is not available inside docker. This is not a problem,
because the support for foreign executable is still configured outside
the container and is available in the container too, but it would be
useful to tell mmdebstrap to accept that binfmt_misc is available even
if it cannot check it.

I can do this manually by commenting out a few lines in mmdebstrap:

> #{
> #open my $fh, '<', '/proc/filesystems' or error "failed 
> to open /proc/filesystems: $!";
> #unless (grep /^nodev\tbinfmt_misc$/, (<$fh>)) {
> #   error "binfmt_misc not found in 
> /proc/filesystems -- is the module loaded?";
> #}
> #close $fh;
> #}
> #{
> #open my $fh, '<', '/proc/mounts' or error "failed to 
> open /proc/mounts: $!";
> #unless (grep /^binfmt_misc \/proc\/sys\/fs\/binfmt_misc 
> binfmt_misc/, (<$fh>)) {
> #   error "binfmt_misc not found in /proc/mounts 
> -- not mounted?";
> #}
> #close $fh;
> #}
> #{
> #open my $fh, '-|', '/usr/sbin/update-binfmts', 
> '--display', "qemu-$options->{qemu}" // error "failed to fork(): $!";
> #chomp (my $binfmts = do { local $/; <$fh> });
> #close $fh;
> #if ($binfmts eq '') {
> #   error "qemu-$options->{qemu} is not a 
> supported binfmt name";
> #}
> #}

Thanks, Giovanni.


--- System information. ---
Architecture: Kernel:   Linux 4.19.0-5-amd64

Debian Release: bullseye/sid
  500 xenial  updates.signal.org   500 unstable-debug
debug.mirrors.debian.org   500 unstabledeb.debian.org   500
testing deb.debian.org   500 stable  repo.skype.com
500 stable  dl.google.com 1 experimentaldeb.debian.org
--- Package information. ---
Depends   (Version) | Installed
===-+-===
perl-doc| 5.28.1-6
apt | 1.8.3
perl:any|

Recommends  (Version) | Installed
=-+-===
arch-test | 0.16-2
fakechroot| 2.19-3.2
fakeroot  | 1.24-1
mount | 2.34-0.1
uidmap| 1:4.7-2


Suggests  (Version) | Installed
===-+-===
proot   | qemu-user   |
1:4.1-1+b1
qemu-user-static| 1:4.1-1+b1
binfmt-support  | 2.2.0-2
dpkg-dev| 1.19.7
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles



signature.asc
Description: OpenPGP digital signature

Bug#940163: dee: FTBFS with GLib 2.62: uses deprecated G_TYPE_INSTANCE_GET_PRIVATE with -Werror

Source: dee
Version: 1.2.7+17.10.20170616-4
Severity: important
Tags: ftbfs
Control: block 940161 by -1

To reproduce, build dee against glib2.0 2.62.x, currently in experimental.
glib2.0 2.62.x is part of GNOME 3.34 and will be uploaded to unstable soon,
at which point this bug will become RC.

dee uses compiler options that include -Werror,
-Wno-error=deprecated-declarations and -DG_DISABLE_DEPRECATED:

> libtool: compile:  gcc -DHAVE_CONFIG_H
> -I. -I.. -I. -I.. -I.. -DG_LOG_DOMAIN=\"dee\" -DPREFIX=\"/usr\"
> -DLIBDIR=\"/usr/lib/x86_64-linux-gnu\" -DG_DISABLE_DEPRECATED
> -DDEE_COMPILATION -g -Wall -pthread -I/usr/include/gio-unix-2.0
> -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0
> -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -Werror -Wall -Wcast-align
> -Wno-uninitialized -Wempty-body -Wformat-security -Winit-self
> -Wno-error=deprecated-declarations -Wdate-time -D_FORTIFY_SOURCE=2 -g
> -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong
> -Wformat -Werror=format-security -c dee-analyzer.c  -fPIC -DPIC -o
> .libs/libdee_1_0_la-dee-analyzer.o

GLib 2.62.x has started to apply deprecation warning markers to
deprecated non-declaration constructs, such as macros and types. In
particular this affects the G_TYPE_INSTANCE_GET_PRIVATE macro,
which is part of the implementation of older conventional macros like
DEE_ANALYZER_GET_PRIVATE. Because this is not actually a declaration,
it is unaffected by -Wno-error=deprecated-declarations:

> dee-analyzer.c: In function ‘dee_analyzer_class_init’:
> dee-analyzer.c:200:3: warning: ‘g_type_class_add_private’ is deprecated 
> [-Wdeprecated-declarations]
>   200 |   g_type_class_add_private (obj_class, sizeof (DeeAnalyzerPrivate));
>   |   ^~~~
> In file included from /usr/include/glib-2.0/gobject/gobject.h:24,
>  from /usr/include/glib-2.0/gobject/gbinding.h:29,
>  from /usr/include/glib-2.0/glib-object.h:23,
>  from dee-analyzer.h:28,
>  from dee-analyzer.c:46:
> /usr/include/glib-2.0/gobject/gtype.h:1308:10: note: declared here
>  1308 | void g_type_class_add_private   (gpointer
> g_class,
>   |  ^~~~
> dee-analyzer.c: In function ‘dee_analyzer_init’:
> dee-analyzer.c:208:13: error: G_ADD_PRIVATE [-Werror]
>   208 |   priv = self->priv = DEE_ANALYZER_GET_PRIVATE (self);
>   | ^~~

The obvious solution is to stop compiling distro packages with -Werror,
which is nearly always a RC bug waiting to happen. Untested patch:
pass --disable-maintainer-flags to dh_auto_configure.

Using -DG_DISABLE_DEPRECATED in distro packages is likely also a bad idea:
if the GLib maintainers had used the older way to deprecate a macro

#ifndef G_DISABLE_DEPRECATED
#define G_TYPE_INSTANCE_GET_PRIVATE ...
#endif

then this code would still FTBFS, but for a different reason.

smcv

Bug#940018: at-spi2-atk autopkgtest fail most of the time on s390x

2019-09-13 Thread Sebastien Bacher

I'm able to reproduce by starting the test manually on a canonistack
instance

$ xvfb-run -a dbus-run-session gdb ./atk-test
...
# random seed: R02S97663fd16d09abca48dfb08b794e21eb
1..158
# Start of Accessible tests
run_app:
/home/ubuntu/build/at-spi2-atk-2.34.0/tests/data/test-accessible.xml
[Detaching after fork from child process 10080]
child_pid 10080
dbus-daemon[10074]: [session uid=1000 pid=10074] Activating service
name='org.a11y.Bus' requested by ':1.0' (uid=1000 pid=10077
comm="/home/ubuntu/build/at-spi2-atk-2.34.0/obj-s390x-li"
label="unconfined")
dbus-daemon[10074]: [session uid=1000 pid=10074] Successfully activated
service 'org.a11y.Bus'
dbus-daemon[10089]: Activating service name='org.a11y.atspi.Registry'
requested by ':1.1' (uid=1000 pid=10080
comm="/home/ubuntu/build/at-spi2-atk-2.34.0/obj-s390x-li"
label="unconfined")
dbus-daemon[10089]: Successfully activated service 'org.a11y.atspi.Registry'
SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry

** (at-spi2-registryd:10093): WARNING **: 08:24:49.049: AT-SPI: Cannot
open default display

** (app-test:10080): WARNING **: 08:24:49.050: AT-SPI: Could not obtain
desktop path or name

Bail out! dbind-FATAL-WARNING: Couldn't get application list: Message
recipient disconnected from message bus without replying

(atk-test:10077): dbind-WARNING **: 08:24:49.050: Couldn't get
application list: Message recipient disconnected from message bus
without replying

dbus-daemon[10089]: Activating service name='org.a11y.atspi.Registry'
requested by ':1.0' (uid=1000 pid=10077
comm="/home/ubuntu/build/at-spi2-atk-2.34.0/obj-s390x-li"
label="unconfined")
Program received signal SIGTRAP, Trace/breakpoint trap.
__GI_raise (sig=sig@entry=5) at ../sysdeps/unix/sysv/linux/raise.c:50
50    ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) dbus-daemon[10089]: Successfully activated service
'org.a11y.atspi.Registry'
SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry
...

#0  0x03fffdb48c6e in __GI_raise (sig=sig@entry=5)
    at ../sysdeps/unix/sysv/linux/raise.c:50
    set =
    {__val = {0, 0, 0, 0, 2929167958240, 4398009972902, 1, 18,
4398012587912, 2929167873312, 4398010847088, 4398046504392,
2929167993248, 2929167839808, 4398046505320, 1}}
    pid = 
    tid = 
#1  0x03fffddd985a in _g_log_abort (breakpoint=breakpoint@entry=1)
    at ../../../glib/gmessages.c:554
    debugger_present = 1
#2  0x03fffdddab50 in g_logv (log_domain=,
    log_domain@entry=0x3fffdd278a6 "dbind",
log_level=G_LOG_LEVEL_WARNING, format=format@entry=0x3fffdd296de
"Couldn't get application list: %s", args=args@entry=0x3ffe8a0) at
../../../glib/gmessages.c:1373
    domain = 0x0
    data = 0x0
    depth = 1
    log_func = 0x3fffddfcd90 
    domain_fatal_mask = 
    masquerade_fatal = 0
    test_level = 18
    was_fatal = 
    was_recursion = 
    msg = 
    msg_alloc = 
    i = 4
#3  0x03fffdddad1a in g_log
    (log_domain=log_domain@entry=0x3fffdd278a6 "dbind",
log_level=log_level@entry=G_LOG_LEVEL_WARNING,
format=format@entry=0x3fffdd296de "Couldn't get application list: %s")
at ../../../glib/gmessages.c:1415
    args =
    {{__gpr = 4, __fpr = 0, __overflow_arg_area = 0x3ffe968,
__reg_save_area = 0x3ffe8c8}}
#4  0x03fffdd1d5be in ref_accessible_desktop
    (app=0x2aa00039800 [AtspiApplication]) at ../atspi/atspi-misc.c:597
    message = 
    iter =
  {dummy1 = 0x0, dummy2 = 0x2aa00030ca0, dummy3 = 1023, dummy4 =
-5448, dummy5 = 682, dummy6 = 200192, dummy7 = 0, dummy8 = 100, dummy9 =
682, dummy10 = 88450, dummy11 = 1023, pad1 = -33923192, pad2 = 0x0, pad3
= 0x3fffdc1419c <___fprintf_chk+116>}
    iter_array =
  {dummy1 = 0x3ffe950, dummy2 = 0x2aa00015982, dummy3 =
1023, dummy4 = -33923192, dummy5 = 0, dummy6 = 0, dummy7 = 682, dummy8 =
87302, dummy9 = 0, dummy10 = 4, dummy11 = 0, pad1 = 0, pad2 =
0x3ffeab8, pad3 = 0x3ffea18}
--Type  for more, q to quit, c to continue without paging--
    bus_name_dup = 
    error = 0x2aa00038c20
    reply = 0x0
    a = 0x2aa00039800 [AtspiApplication]
#5  0x03fffdd1d5be in _atspi_ref_accessible
    (app=, path=) at ../atspi/atspi-misc.c:632
    a = 0x2aa00039800 [AtspiApplication]
#6  0x03fffdd1e604 in atspi_get_desktop (i=i@entry=0)
    at ../atspi/atspi-registry.c:71
#7  0x02aa000155da in get_root_obj
    (file_name=file_name@entry=0x2aa00015982
"/home/ubuntu/build/at-spi2-atk-2.34.0/tests/data/test-accessible.xml")
at ../tests/atk_test_util.c:81
    tries = 0
    child = 
    timeout = {tv_sec = 0, tv_nsec = 1000}
    obj = 0x0
#8  0x02aa70e0 in atk_test_accessible_get_name
    (fixture=, user_data=)
    at ../tests/atk_test_accessible.c:37
    obj = 
    __func__ = "atk_test_accessible_get_name"



Cheers,

Le 13/09/2019 à 00:30, Samuel Thibault a écrit :
> I tried

Bug#940018: at-spi2-atk autopkgtest fail most of the time on s390x

Sebastien Bacher, le ven. 13 sept. 2019 10:30:10 +0200, a ecrit:
> I'm able to reproduce by starting the test manually on a canonistack
> instance
> 
> $ xvfb-run -a dbus-run-session gdb ./atk-test
> ...
> [Detaching after fork from child process 10080]
> child_pid 10080
> dbus-daemon[10074]: [session uid=1000 pid=10074] Activating service
> name='org.a11y.Bus' requested by ':1.0' (uid=1000 pid=10077

So it's apparently the right dbus-daemon which starts the at-spi service.

> ** (at-spi2-registryd:10093): WARNING **: 08:24:49.049: AT-SPI: Cannot
> open default display

But for some reason XOpenDisplay(NULL) failed to connect to the Xvfb
started by xvfb-run, and all the rest comes from this. Do you have xauth
installed and does xvfb-run properly set things for X applications to
connect? You might want to check with

$ xvfb-run -a /usr/bin/xlogo

Samuel

Bug#940164: bamf: FTBFS with GLib 2.62: uses deprecated G_TYPE_INSTANCE_GET_PRIVATE with -Werror

Source: bamf
Version: 0.5.4-1
Severity: important
Tags: ftbfs
Control: block 940161 by -1

To reproduce, build bamf against glib2.0 2.62.x, currently in experimental.
glib2.0 2.62.x is part of GNOME 3.34 and will be uploaded to unstable soon,
at which point this bug will become RC.

bamf uses compiler options that include -Werror and
-Wno-error=deprecated-declarations:

> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -Wdate-time
> -D_FORTIFY_SOURCE=2 -Wall -std=c99 -fPIC -DDATADIR=\"/usr/share\"
> -I. -I../../lib -I../../lib -pthread -I/usr/include/gio-unix-2.0
> -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0
> -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -g -O2
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security -Wall -Werror -Wno-error=deprecated-declarations
> -Wempty-body -Wformat-security -Winit-self -Warray-bounds
> -Wimplicit-function-declaration -lm -c bamf-application.c  -fPIC -DPIC
> -o .libs/libbamf3_la-bamf-application.o

GLib 2.62.x has started to apply deprecation warning markers to
deprecated non-declaration constructs, such as macros and types. In
particular this affects the G_TYPE_INSTANCE_GET_PRIVATE macro,
which is part of the implementation of older conventional macros like
BAMF_APPLICATION_GET_PRIVATE. Because this is not actually a declaration,
it is unaffected by -Wno-error=deprecated-declarations:

> bamf-application.c: In function ‘bamf_application_class_init’:
> bamf-application.c:714:3: warning: ‘g_type_class_add_private’ is deprecated 
> [-Wdeprecated-declarations]
>   714 |   g_type_class_add_private (obj_class, sizeof 
> (BamfApplicationPrivate));
>   |   ^~~~
> In file included from /usr/include/glib-2.0/gobject/gobject.h:24,
>  from /usr/include/glib-2.0/gobject/gbinding.h:29,
>  from /usr/include/glib-2.0/glib-object.h:23,
>  from /usr/include/glib-2.0/gio/gioenums.h:28,
>  from /usr/include/glib-2.0/gio/giotypes.h:28,
>  from /usr/include/glib-2.0/gio/gio.h:26,
>  from ../../lib/libbamf-private/bamf-gdbus-generated.h:11,
>  from ../../lib/libbamf-private/bamf-private.h:23,
>  from bamf-application.c:38:
> /usr/include/glib-2.0/gobject/gtype.h:1308:10: note: declared here
>  1308 | void g_type_class_add_private   (gpointer
> g_class,
>   |  ^~~~
> bamf-application.c: In function ‘bamf_application_init’:
> bamf-application.c:746:13: error: G_ADD_PRIVATE [-Werror]
>   746 |   priv = self->priv = BAMF_APPLICATION_GET_PRIVATE (self);
>   | ^~~

The obvious solution is to stop compiling distro packages with -Werror,
which is nearly always a RC bug waiting to happen. Untested patch:
edit this line in configure.ac

CFLAGS="$CFLAGS -Wall -Werror -Wno-error=deprecated-declarations 
-Wempty-body -Wformat-security -Winit-self -Warray-bounds 
-Wimplicit-function-declaration -lm"

and remove -Werror.

Unfortunately this setup *appends* to CFLAGS rather than using a separate
variable or prepending to CFLAGS, so it is not possible to avoid -Werror
by using "make CFLAGS=-Wno-error" or similar. Autotools best-practice
is to reserve CFLAGS for use by the user, and use a separate variable
for flags requested by the upstream maintainer. It would probably
be worthwhile to talk to upstream about a more distro-friendly setup
for CFLAGS, such as using a separate variable like WARNING_CFLAGS for
the compiler warnings, using the standard Libtool macro LT_LIB_M to
populate $(LIBM) instead of hard-coding -lm, and having a straightforward
way to disable -Werror - or perhaps using the autoconf-archive macro
AX_COMPILER_FLAGS, which adds a --disable-Werror option suitable for
use by distros.

smcv

Bug#940018: at-spi2-atk autopkgtest fail most of the time on s390x

Samuel Thibault, le ven. 13 sept. 2019 10:37:23 +0200, a ecrit:
> Sebastien Bacher, le ven. 13 sept. 2019 10:30:10 +0200, a ecrit:
> > dbus-daemon[10074]: [session uid=1000 pid=10074] Activating service
> > name='org.a11y.Bus' requested by ':1.0' (uid=1000 pid=10077
> 
> So it's apparently the right dbus-daemon which starts the at-spi service.
> 
> > ** (at-spi2-registryd:10093): WARNING **: 08:24:49.049: AT-SPI: Cannot
> > open default display
> 
> But for some reason XOpenDisplay(NULL) failed to connect to the Xvfb
> started by xvfb-run, and all the rest comes from this. Do you have xauth
> installed and does xvfb-run properly set things for X applications to
> connect? You might want to check with
> 
> $ xvfb-run -a /usr/bin/xlogo

Just thinking: is that dbus-daemon which is the parent of
at-spi2-registryd (and thus gives it its environment variables)?  I
vaguely remember "systemd --user" taking over that role, but possibly it
misses passing the DISPLAY variable along?...

Samuel

Bug#940018: at-spi2-atk autopkgtest fail most of the time on s390x

2019-09-13 Thread Sebastien Bacher

Le 13/09/2019 à 10:44, Samuel Thibault a écrit :
> Just thinking: is that dbus-daemon which is the parent of
> at-spi2-registryd (and thus gives it its environment variables)?  I
> vaguely remember "systemd --user" taking over that role, but possibly it
> misses passing the DISPLAY variable along?...

Yes xauth is installed and e.g xlogo works.

If it was a problem with the way dbus is set it would probably not be
arch specific?

I've tried to ssh -X (which success to start xlogo locally over ssh) and

$ dbus-run-session ./atk-test
# random seed: R02Se0d960b12c7b7375a48b46c8448ee3fb
1..158
# Start of Accessible tests
run_app:
/home/ubuntu/build/at-spi2-atk-2.34.0/tests/data/test-accessible.xml
child_pid 11208
Bail out! dbind-FATAL-ERROR: AT-SPI: Couldn't connect to accessibility
bus. Is at-spi-bus-launcher running?

(atk-test:11207): dbind-ERROR **: 08:52:43.200: AT-SPI: Couldn't connect
to accessibility bus. Is at-spi-bus-launcher running?


I wonder if that's at-spi-bus-launcher error out of something? (but it
doesn't hit an error when started by hand)

Bug#940165: speedtest-cli: Wrong upload speed

2019-09-13 Thread Ramón García

Subject: speedtest-cli: Wrong upload speed
Package: speedtest-cli
Version: 2.0.2-1
Severity: normal

Dear Maintainer,

The speed reported by speedtest is wrong, much lower than real.
Specially the download speed.
speedtest downloaded from github gives a much higher speed.

In one test, speedtest --server 2254 (the nearest server) report
download speed 250.21 Mbit/s and upload speed of 4.08 Mbit/sec.

but using speedtest from https://github.com/sivel/speedtest-cli with
the same options
python ./speedtest.py --server 2254 reports download speed of 603.13
Mbit/s and upload speed of 305.50 Mbit/s


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

Kernel: Linux 4.19.0-5-amd64 (SMP w/6 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Enforcing - Policy name: default

Versions of packages speedtest-cli depends on:
ii  python-pkg-resources   40.8.0-1
ii  python33.7.3-1
ii  python3-pkg-resources  40.8.0-1

speedtest-cli recommends no packages.

speedtest-cli suggests no packages.

Bug#940104: x2goserver-x2goagent: x2goagent creates coredump after upgrate to Debian 10.1

2019-09-13 Thread Mark Hymers

reassign 940104 nx-libs
merge 940104 940103
thanks

On Thu, 12, Sep, 2019 at 02:47:23PM +0200, Frank Rocholl spoke thus..
> I'm not able to use x2go anymore.

Hi Frank,

I'm not the maintainer, but I've had the same problem with x2go in 10.1
(see bug #940103).  As a workaround you can downgrade the nx-libs
packages (libnx-x11-6, libxcomp3, libxcompshad3, nx-x11-common, nxagent,
nxproxy) to the earlier version (you can grab them from
snapshot.debian.org if necessary).

Thanks,

Mark

-- 
Mark Hymers

Bug#940166: python-mlt: converted to Python 3 without following Python modules packaging policy

2019-09-13 Thread Sebastian Ramacher

Package: python-mlt
Version: 6.16.0-4
Severity: serious
Control: affects -1 flowblade

The upload of mlt 6.16.0-4 converted the package to use Python 3 (thanks
for that). However, it didn't change the name of the binary package to
python3-mlt as required by the Python modules packaging policy. Please
update the name of the package too.

Cheers
-- 
Sebastian Ramacher

Bug#940167: Limitation on VG name in setup-storage

2019-09-13 Thread Thomas Lange

Package: fai-setup-storage

>From a FAI user:

When we manually create them, we tend to name our VGs for SSDs as: vg-
ssd[0-9]+ .

However, setup-storage doesn't like that and ends up confused with the
colums on the vg line in the disk_config file.

Would it be able possible to have VG names allow hyphens?

-- 
regards Thomas

Bug#940018: at-spi2-atk autopkgtest fail most of the time on s390x

Sebastien Bacher, le ven. 13 sept. 2019 10:54:07 +0200, a ecrit:
> Le 13/09/2019 à 10:44, Samuel Thibault a écrit :
> > Just thinking: is that dbus-daemon which is the parent of
> > at-spi2-registryd (and thus gives it its environment variables)?  I
> > vaguely remember "systemd --user" taking over that role, but possibly it
> > misses passing the DISPLAY variable along?...
> 
> Yes xauth is installed and e.g xlogo works.

Ok, so that must be something with the dbus activation.

Perhaps you could replace /usr/lib/at-spi2-core/at-spi2-registryd with a
script which dumps the output of ps axuf and printenv to a file, so we
get to be sure in which situation it gets started.

> If it was a problem with the way dbus is set it would probably not be
> arch specific?

Normally it wouldn't. "Normally".

> I've tried to ssh -X (which success to start xlogo locally over ssh) and
> 
> $ dbus-run-session ./atk-test
> # random seed: R02Se0d960b12c7b7375a48b46c8448ee3fb
> 1..158
> # Start of Accessible tests
> run_app:
> /home/ubuntu/build/at-spi2-atk-2.34.0/tests/data/test-accessible.xml
> child_pid 11208
> Bail out! dbind-FATAL-ERROR: AT-SPI: Couldn't connect to accessibility
> bus. Is at-spi-bus-launcher running?

Unfortunately at-spi can't work remotely like this, it has to be a local
X session, ssh X forwarding is not enough.

Samuel

Bug#940168: libreoffice-writer: Display black frame when importing a png-image.

2019-09-13 Thread Johann Spies

Package: libreoffice-writer
Version: 1:6.3.1-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

   I had to import my signature (png) into a document sent to me.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

 I have checked the image with Gimp and could successfully import
 it into Abiword.
 
   * What was the outcome of this action?

   The image displayed as solid black in the writer document.
   
   * What outcome did you expect instead?

   The image to show my signature.

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


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

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

Versions of packages libreoffice-writer depends on:
ii  libabw-0.1-1   0.1.3-1
ii  libc6  2.29-1
ii  libe-book-0.1-10.1.3-1+b2
ii  libepubgen-0.1-1   0.1.1-1
ii  libetonyek-0.1-1   0.1.9-1
ii  libgcc11:9.2.1-8
ii  libicu63   63.2-2
ii  libmwaw-0.3-3  0.3.15-2
ii  libodfgen-0.1-10.1.7-1
ii  libreoffice-base-core  1:6.3.1-1
ii  libreoffice-core   1:6.3.1-1
ii  librevenge-0.0-0   0.0.4-6+b1
ii  libstaroffice-0.0-00.0.6-1
ii  libstdc++6 9.2.1-8
ii  libwpd-0.10-10 0.10.3-1
ii  libwpg-0.3-3   0.3.3-1
ii  libwps-0.4-4   0.4.10-1
ii  libxml22.9.4+dfsg1-7+b3
ii  uno-libs3  6.3.1-1
ii  ure6.3.1-1
ii  zlib1g 1:1.2.11.dfsg-1+b1

Versions of packages libreoffice-writer recommends:
ii  libreoffice-math  1:6.3.1-1

Versions of packages libreoffice-writer suggests:
ii  default-jre [java6-runtime] 2:1.11-72
ii  fonts-crosextra-caladea 20130214-2
ii  fonts-crosextra-carlito 20130920-1
pn  libreoffice-base
ii  libreoffice-java-common 1:6.3.1-1
ii  openjdk-11-jre [java6-runtime]  11.0.5+6-2

Versions of packages libreoffice-core depends on:
ii  fontconfig  2.13.1-2+b1
ii  fonts-opensymbol2:102.11+LibO6.3.1-1
ii  libboost-locale1.67.0   1.67.0-13
ii  libc6   2.29-1
ii  libcairo2   1.16.0-4
ii  libclucene-contribs1v5  2.3.3.4+dfsg-1+b1
ii  libclucene-core1v5  2.3.3.4+dfsg-1+b1
ii  libcmis-0.5-5v5 0.5.2-1
ii  libcups22.3.0-3
ii  libcurl3-gnutls 7.65.3-1
ii  libdbus-1-3 1.12.16-1
ii  libdconf1   0.34.0-1
ii  libeot0 0.01-5+b1
ii  libepoxy0   1.5.3-0.1
ii  libexpat1   2.2.7-2
ii  libexttextcat-2.0-0 3.4.5-1
ii  libfontconfig1  2.13.1-2+b1
ii  libfreetype62.9.1-4
ii  libgcc1 1:9.2.1-8
ii  libglib2.0-02.60.6-2
ii  libgpgmepp6 1.13.1-1
ii  libgraphite2-3  1.3.13-8
ii  libgstreamer-plugins-base1.0-0  1.16.0-4
ii  libgstreamer1.0-0   1.16.0-3
ii  libharfbuzz-icu02.6.1-3
ii  libharfbuzz0b   2.6.1-3
ii  libhunspell-1.7-0   1.7.0-2+b1
ii  libhyphen0  2.8.8-7
ii  libice6 2:1.0.9-2
ii  libicu6363.2-2
ii  libjpeg62-turbo 1:1.5.2-2+b1
ii  liblcms2-2  2.9-4
ii  libldap-2.4-2   2.4.48+dfsg-1
ii  libmythes-1.2-0 2:1.2.4-3+b1
ii  libneon27-gnutls0.30.2-3
ii  libnspr42:4.21-2
ii  libnss3 2:3.45-1
ii  libnumbertext-1.0-0 1.0.5-3
ii  liborcus-0.14-0 0.14.1-6
ii  libpng16-16 1.6.37-1
ii  libpoppler820.71.0-5+b1
ii  librdf0 1.0.17-1.1+b1
ii  libreoffice-common  1:6.3.1-1
ii  librevenge-0.0-00.0.4-6+b1
ii  libsm6  2:1.2.3-1
ii  libstdc++6  9.2.1-8
ii  libx11-62:1.6.7-1
ii  libxext62:1.3.3-1+b2
ii  libxinerama12:1.1.4-2
ii  libxml2 2.9.4+dfsg1-7+b3
ii  libxmlsec1  1.2.28-2
ii  libxmlsec1-nss  1.2.28-2
ii  libxrandr2  2:1.5.1-1
ii  libxrender1 1:0.9.10-1
ii  libxslt1.1

Bug#940161: glib2.0: New upstream stable release 2.62.x

On Fri, 13 Sep 2019 at 08:57:51 +0100, Simon McVittie wrote:
> I'm opening this bug so that we have somewhere to track the FTBFSs related
> to GLib's test framework dropping the deprecated GTester format.

Correction: switching the default output format from GTester to TAP. The
GTester format still exists, so gtester(1) should still work.

There are also FTBFSs in at least bamf and dee because they (IMO unwisely)
build with -Werror, which I've marked as blocking this bug.

smcv

Bug#940167: Limitation on VG name in setup-storage

2019-09-13 Thread Thomas Lange

Maybe this code in Parser.pm in line 936 is responsible for the limitation:
 name: m{^([^/,\s\-]+)}

You could try to remove \- and see if setup-storage is still working.
-- 
regards Thomas

Bug#940018: at-spi2-atk autopkgtest fail most of the time on s390x

2019-09-13 Thread Sebastien Bacher

Le 13/09/2019 à 11:02, Samuel Thibault a écrit :
> Perhaps you could replace /usr/lib/at-spi2-core/at-spi2-registryd with a
> script which dumps the output of ps axuf and printenv to a file, so we
> get to be sure in which situation it gets started.


USER   PID %CPU %MEM    VSZ   RSS TTY  STAT START   TIME COMMAND
root 2  0.0  0.0  0 0 ?    S    08:04   0:00 [kthreadd]
root 3  0.0  0.0  0 0 ?    I<   08:04   0:00  \_
[rcu_gp]
root 4  0.0  0.0  0 0 ?    I<   08:04   0:00  \_
[rcu_par_gp]
root 6  0.0  0.0  0 0 ?    I<   08:04   0:00  \_
[kworker/0:0H-kblockd]
root 8  0.0  0.0  0 0 ?    I<   08:04   0:00  \_
[mm_percpu_wq]
root 9  0.0  0.0  0 0 ?    S    08:04   0:00  \_
[ksoftirqd/0]
root    10  0.0  0.0  0 0 ?    I    08:04   0:00  \_
[rcu_sched]
root    11  0.0  0.0  0 0 ?    S    08:04   0:00  \_
[migration/0]
root    12  0.0  0.0  0 0 ?    S    08:04   0:00  \_
[cpuhp/0]
root    13  0.0  0.0  0 0 ?    S    08:04   0:00  \_
[kdevtmpfs]
root    14  0.0  0.0  0 0 ?    I<   08:04   0:00  \_ [netns]
root    15  0.0  0.0  0 0 ?    S    08:04   0:00  \_
[rcu_tasks_kthre]
root    16  0.0  0.0  0 0 ?    S    08:04   0:00  \_
[kauditd]
root    17  0.0  0.0  0 0 ?    S    08:04   0:00  \_
[khungtaskd]
root    18  0.0  0.0  0 0 ?    S    08:04   0:00  \_
[oom_reaper]
root    19  0.0  0.0  0 0 ?    I<   08:04   0:00  \_
[writeback]
root    20  0.0  0.0  0 0 ?    S    08:04   0:00  \_
[kcompactd0]
root    21  0.0  0.0  0 0 ?    SN   08:04   0:00  \_ [ksmd]
root   107  0.0  0.0  0 0 ?    I<   08:04   0:00  \_
[kintegrityd]
root   108  0.0  0.0  0 0 ?    I<   08:04   0:00  \_
[kblockd]
root   109  0.0  0.0  0 0 ?    I<   08:04   0:00  \_
[blkcg_punt_bio]
root   110  0.0  0.0  0 0 ?    I<   08:04   0:00  \_
[tpm_dev_wq]
root   111  0.0  0.0  0 0 ?    I<   08:04   0:00  \_ [md]
root   112  0.0  0.0  0 0 ?    I<   08:04   0:00  \_ [cio]
root   113  0.0  0.0  0 0 ?    S    08:04   0:00  \_
[watchdogd]
root   115  0.0  0.0  0 0 ?    S    08:04   0:00  \_
[cmmthread]
root   116  0.0  0.0  0 0 ?    S    08:04   0:00  \_
[kswapd0]
root   117  0.0  0.0  0 0 ?    I<   08:04   0:00  \_
[kworker/u3:0]
root   118  0.0  0.0  0 0 ?    S    08:04   0:00  \_
[ecryptfs-kthrea]
root   121  0.0  0.0  0 0 ?    I<   08:04   0:00  \_
[kthrotld]
root   122  0.0  0.0  0 0 ?    S    08:04   0:00  \_
[kmcheck]
root   123  0.0  0.0  0 0 ?    I<   08:04   0:00  \_
[ipv6_addrconf]
root   134  0.0  0.0  0 0 ?    I<   08:04   0:00  \_ [kstrp]
root   185  0.0  0.0  0 0 ?    I<   08:04   0:00  \_
[kworker/0:1H-kblockd]
root   294  0.0  0.0  0 0 ?    I<   08:04   0:00  \_
[raid5wq]
root   337  0.0  0.0  0 0 ?    S    08:04   0:00  \_
[jbd2/vda1-8]
root   338  0.0  0.0  0 0 ?    I<   08:04   0:00  \_
[ext4-rsv-conver]
root   456  0.0  0.0  0 0 ?    I<   08:04   0:00  \_
[vfio-ccw]
root   486  0.0  0.0  0 0 ?    I<   08:04   0:00  \_
[kaluad]
root   487  0.0  0.0  0 0 ?    I<   08:04   0:00  \_
[kmpath_rdacd]
root   488  0.0  0.0  0 0 ?    I<   08:04   0:00  \_
[kmpathd]
root   489  0.0  0.0  0 0 ?    I<   08:04   0:00  \_
[kmpath_handlerd]
root   921  0.0  0.0  0 0 ?    S<   08:05   0:00  \_ [loop0]
root  1058  0.0  0.0  0 0 ?    S<   08:05   0:00  \_ [loop1]
root  8010  0.0  0.0  0 0 ?    I    08:19   0:00  \_
[kworker/0:0-events]
root 11210  0.0  0.0  0 0 ?    I    08:52   0:00  \_
[kworker/u2:0-events_power_efficient]
root 12168  0.0  0.0  0 0 ?    I    09:05   0:00  \_
[kworker/0:3-events]
root 12294  0.0  0.0  0 0 ?    I    09:10   0:00  \_
[kworker/u2:2-events_power_efficient]
root 12515  0.0  0.0  0 0 ?    I    09:19   0:00  \_
[kworker/u2:1-events_unbound]
root 12580  0.0  0.0  0 0 ?    I    09:20   0:00  \_
[kworker/0:1-events]
root 12581  0.0  0.0  0 0 ?    I    09:20   0:00  \_
[kworker/0:2-events]
root 1  0.0  1.7 106964  8560 ?    Ss   08:04   0:02 /sbin/init
root   424  0.0  1.5  47824  7756 ?    S

Bug#938494: skimage (build-)depends on python-cloudpickle which has already been dropped

2019-09-13 Thread Drew Parsons


On 2019-09-13 15:42, Andreas Tille wrote:

Hi,

as Peter Green found out the cloudpickle source package droped Python2
support which makes bug #938494 serious.  I guess it would be even
harder to drop python-skimage right now since this would affect
python-numpy and according to

   $ apt-cache rdepends python-numpy | sort | uniq | wc -l

339 reverse dependencies.  I have no better solution than just pinging
bug #938494 from time to time - and to ping this list to work harder on
Python3 migration.



It is something of a problem, so I'm cc:ing debian-python.

There have been a number of packages dropping python2 support 
out-of-sequence, causing this problem.  Not just cloudpickle, also 
pyqtgraph, which still had pymca as a dependent.  Fortunately pymca was 
already ready to drop the dependency, but still, how many other examples 
are there?


Python maintainers, remember, check your reverse dependencies before 
dropping your python2 packages.

Check each of

  build-rdeps python-yourmodule
  apt-rdepends -r python-yourmodule

and confirm the package has rdeps=0 on Sandro's list at 
http://sandrotosi.me/debian/py2removal/index.html


Drew

Bug#940169: RFP: cargo-deb -- A cargo subcommand that generates Debian packages from information in Cargo.toml

2019-09-13 Thread Varac

Package: wnpp
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: cargo-deb
  Version : latest
  Upstream Author : git...@pornel.net
* URL : https://github.com/mmstick/cargo-deb
* License : MIT
  Programming Lang: Rust
  Description : A cargo subcommand that generates Debian packages from 
information in Cargo.toml

This is a Cargo helper command which automatically creates binary Debian 
packages (.deb) from Cargo projects.
Requires Rust 1.31+, and optionally dpkg, ldd and liblzma-dev. Compatible with 
Ubuntu.

-BEGIN PGP SIGNATURE-

iQJEBAEBCgAuFiEESvqqiCmYrIkee91NVGXnfnh27QQFAl17XdwQHHZhcmFjQHZh
cmFjLm5ldAAKCRBUZed+eHbtBC8wD/482oxdXT7M428Tt5a4Gtlu4IOiOI2NPQqB
h7HGTDHnL/bcAdSmmkdgaVm+p7oPbPpFFzfjRWb3qwuLW127K1jBKodPGaY6QwPm
NT/nVEpbTj5LGxG9JGWYACt5gxvD9RVw81J2q7YofZvTQEzz54S86d41VabSsBEX
d3gyPanuS1T5Iimpuuy6f2p2wNG7kOj1m+jH/0pPhkypCynt/8IbsxHf2VJN8hYR
J8dHteeUmr7oh98ALEUKRGQWp0Ao9pF4Wm7lh29hKAd0b8vMjOLY5tzVxt42BOye
bJ5n/3RU36pxn7NihhN5Af2AgieUGh2RLletwLQlhXvSlGitg1qZq+XechenrMd8
XfIWLROgmrtQBWUU9cWUqelQxKW7220FDqNrrvAT8Oy9I1Z7KwewOepoNjiaAY9g
81NOUQ1jpyow5ZQq0VCnTu0dvs/XmgmE8QZrdF06QOGo7FoJIclGnjbo/RU0Lskk
ThOAP+FLYI3l1kiFTr1Hq9wScKLpwgMDRQjSy7tLIPB9QPdscnr6U1H5xsKx1pEN
zv7iL12ERwVRtPhD1nVlAtdxLsEoKa5mBU2vX0ge7yJpsJKH/fHrA2KR7eitfG7A
UecqXAAUE/ZF/3P35QXKzBc1NyTva2vzF34azHemYx+eu2zcekgwjSwCrxJRZD0S
97yWVfdY7Q==
=JDUb
-END PGP SIGNATURE-

Bug#940018: at-spi2-atk autopkgtest fail most of the time on s390x

Sebastien Bacher, le ven. 13 sept. 2019 11:22:00 +0200, a ecrit:
> Le 13/09/2019 à 11:02, Samuel Thibault a écrit :
> > Perhaps you could replace /usr/lib/at-spi2-core/at-spi2-registryd with a
> > script which dumps the output of ps axuf and printenv to a file, so we
> > get to be sure in which situation it gets started.

(posting it again with lines unwrapped for readability).

So this does have DISPLAY and XAUTHORITY set. I wonder how
XOpenDisplay(NULL) could fail, then.

If you put an xlogo call in that /usr/lib/at-spi2-core/at-spi2-registryd
script, does it succeed to connect to the Xvfb?

Samuel
Le 13/09/2019 à 11:02, Samuel Thibault a écrit :
> Perhaps you could replace /usr/lib/at-spi2-core/at-spi2-registryd with a
> script which dumps the output of ps axuf and printenv to a file, so we
> get to be sure in which situation it gets started.


USER   PID %CPU %MEM    VSZ   RSS TTY  STAT START   TIME COMMAND
root 2  0.0  0.0  0 0 ?    S    08:04   0:00 [kthreadd]
root 3  0.0  0.0  0 0 ?    I<   08:04   0:00  \_ [rcu_gp]
root 4  0.0  0.0  0 0 ?    I<   08:04   0:00  \_ 
[rcu_par_gp]
root 6  0.0  0.0  0 0 ?    I<   08:04   0:00  \_ 
[kworker/0:0H-kblockd]
root 8  0.0  0.0  0 0 ?    I<   08:04   0:00  \_ 
[mm_percpu_wq]
root 9  0.0  0.0  0 0 ?    S    08:04   0:00  \_ 
[ksoftirqd/0]
root    10  0.0  0.0  0 0 ?    I    08:04   0:00  \_ [rcu_sched]
root    11  0.0  0.0  0 0 ?    S    08:04   0:00  \_ 
[migration/0]
root    12  0.0  0.0  0 0 ?    S    08:04   0:00  \_ [cpuhp/0]
root    13  0.0  0.0  0 0 ?    S    08:04   0:00  \_ [kdevtmpfs]
root    14  0.0  0.0  0 0 ?    I<   08:04   0:00  \_ [netns]
root    15  0.0  0.0  0 0 ?    S    08:04   0:00  \_ 
[rcu_tasks_kthre]
root    16  0.0  0.0  0 0 ?    S    08:04   0:00  \_ [kauditd]
root    17  0.0  0.0  0 0 ?    S    08:04   0:00  \_ 
[khungtaskd]
root    18  0.0  0.0  0 0 ?    S    08:04   0:00  \_ 
[oom_reaper]
root    19  0.0  0.0  0 0 ?    I<   08:04   0:00  \_ [writeback]
root    20  0.0  0.0  0 0 ?    S    08:04   0:00  \_ 
[kcompactd0]
root    21  0.0  0.0  0 0 ?    SN   08:04   0:00  \_ [ksmd]
root   107  0.0  0.0  0 0 ?    I<   08:04   0:00  \_ 
[kintegrityd]
root   108  0.0  0.0  0 0 ?    I<   08:04   0:00  \_ [kblockd]
root   109  0.0  0.0  0 0 ?    I<   08:04   0:00  \_ 
[blkcg_punt_bio]
root   110  0.0  0.0  0 0 ?    I<   08:04   0:00  \_ 
[tpm_dev_wq]
root   111  0.0  0.0  0 0 ?    I<   08:04   0:00  \_ [md]
root   112  0.0  0.0  0 0 ?    I<   08:04   0:00  \_ [cio]
root   113  0.0  0.0  0 0 ?    S    08:04   0:00  \_ [watchdogd]
root   115  0.0  0.0  0 0 ?    S    08:04   0:00  \_ [cmmthread]
root   116  0.0  0.0  0 0 ?    S    08:04   0:00  \_ [kswapd0]
root   117  0.0  0.0  0 0 ?    I<   08:04   0:00  \_ 
[kworker/u3:0]
root   118  0.0  0.0  0 0 ?    S    08:04   0:00  \_ 
[ecryptfs-kthrea]
root   121  0.0  0.0  0 0 ?    I<   08:04   0:00  \_ [kthrotld]
root   122  0.0  0.0  0 0 ?    S    08:04   0:00  \_ [kmcheck]
root   123  0.0  0.0  0 0 ?    I<   08:04   0:00  \_ 
[ipv6_addrconf]
root   134  0.0  0.0  0 0 ?    I<   08:04   0:00  \_ [kstrp]
root   185  0.0  0.0  0 0 ?    I<   08:04   0:00  \_ 
[kworker/0:1H-kblockd]
root   294  0.0  0.0  0 0 ?    I<   08:04   0:00  \_ [raid5wq]
root   337  0.0  0.0  0 0 ?    S    08:04   0:00  \_ 
[jbd2/vda1-8]
root   338  0.0  0.0  0 0 ?    I<   08:04   0:00  \_ 
[ext4-rsv-conver]
root   456  0.0  0.0  0 0 ?    I<   08:04   0:00  \_ [vfio-ccw]
root   486  0.0  0.0  0 0 ?    I<   08:04   0:00  \_ [kaluad]
root   487  0.0  0.0  0 0 ?    I<   08:04   0:00  \_ 
[kmpath_rdacd]
root   488  0.0  0.0  0 0 ?    I<   08:04   0:00  \_ [kmpathd]
root   489  0.0  0.0  0 0 ?    I<   08:04   0:00  \_ 
[kmpath_handlerd]
root   921  0.0  0.0  0 0 ?    S<   08:05   0:00  \_ [loop0]
root  1058  0.0  0.0  0 0 ?    S<   08:05   0:00  \_ [loop1]
root  8010  0.0  0.0  0 0 ?    I    08:19   0:00  \_ 
[kworker/0:0-events]
root 11210  0.0  0.0  0 0 ?    I    08:52   0:00  \_ 
[kworker/u2:0-events_power_efficient]
root 12168  0.0  0.0  0 0 ?    I    09:05   0:00  \_ 
[kworker/0:3-events]
root 12294  0.0  0.0  0 0 ?    I    09:10   0:00  \_ 
[kworker/u2:2-events_power_efficient]
root 12515  0.0  0.0  0 0 ?    I    09:19   0:00  \_

Bug#940167: Limitation on VG name in setup-storage?

2019-09-13 Thread Thomas Lange

Hi Andrew,

you've said that removing \- from the regex works for you. I cannot
reproduce this. When I use a vg name like vg-ssd7 I get the error

ERROR (line 13): Invalid volume: Was expecting /^vg\s+/, or
   /^raid([0156]|10)\s+/, or /^btrfs
   (single|raid([0156]|10))\s+/, or
   /^(luks|luks:"[^"]+"|tmp|swap)\s+/, or /^tmpfs\s+/, or
   /^nfs\s+([^\s]+)\s+/, or type

ERROR (line 13): Invalid line: Was expecting '\n' but found "vg-ssd7-
  root / 3G-25G ext4 noatime,rw" instead


Can you please send me your disk_config that is working for you using
a hyphen.

-- 
regards Thomas

Bug#940162: [mmdebstrap] Allow overriding of binfmt_misc search

2019-09-13 Thread Johannes Schauer

Hi,

Quoting Giovanni Mascellani (2019-09-13 10:18:07)
> it seems that mmdebstrap does not work inside a docker container. After
> installing docker.io and qemu-user-static on a computer, for example:
> 
> # docker run -it --rm debian:unstable
> [now inside the container]
> # apt update
> # apt install qemu-user-static mmdebstrap
> # mmdebstrap --architectures=armhf --verbose unstable /tmp/debian.tar.gz
> 'http://deb.debian.org/debian'
> I: automatically chosen mode: root
> I: armhf cannot be executed, falling back to qemu-user
> E: binfmt_misc not found in /proc/mounts -- not mounted?
> 
> Here mmdebstrap fails because it tries to look for the binfmt_misc
> filesystem, which is not available inside docker. This is not a problem,
> because the support for foreign executable is still configured outside
> the container and is available in the container too, but it would be
> useful to tell mmdebstrap to accept that binfmt_misc is available even
> if it cannot check it.
> 
> I can do this manually by commenting out a few lines in mmdebstrap:
> 
> > #{
> > #open my $fh, '<', '/proc/filesystems' or error "failed 
> > to open /proc/filesystems: $!";
> > #unless (grep /^nodev\tbinfmt_misc$/, (<$fh>)) {
> > #   error "binfmt_misc not found in 
> > /proc/filesystems -- is the module loaded?";
> > #}
> > #close $fh;
> > #}
> > #{
> > #open my $fh, '<', '/proc/mounts' or error "failed to 
> > open /proc/mounts: $!";
> > #unless (grep /^binfmt_misc 
> > \/proc\/sys\/fs\/binfmt_misc binfmt_misc/, (<$fh>)) {
> > #   error "binfmt_misc not found in 
> > /proc/mounts -- not mounted?";
> > #}
> > #close $fh;
> > #}
> > #{
> > #open my $fh, '-|', '/usr/sbin/update-binfmts', 
> > '--display', "qemu-$options->{qemu}" // error "failed to fork(): $!";
> > #chomp (my $binfmts = do { local $/; <$fh> });
> > #close $fh;
> > #if ($binfmts eq '') {
> > #   error "qemu-$options->{qemu} is not a 
> > supported binfmt name";
> > #}
> > #}

the code you quote exists to give meaningful output in cases where foreign
architecture binaries cannot be executed. Instead of adding another knob to the
command line interface, I would prefer either of these two solutions:

 - turn the errors into warnings -- in case there is an error later, the user
   can use the earlier warning to diagnose it

 - only run the checks after executing a test executable failed as a
   diagnostic. If the test executable was successfully executed, then there is
   no reason to run the checks from above.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#940170: buster-pu: package trapperkeeper-webserver-jetty9-clojure/1.7.0-2+deb10u1

2019-09-13 Thread Julien Cristau

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

A jetty9 update broke trapperkeeper-webserver-jetty9-clojure, and as a
result puppetdb, in buster (bug#924005).  This is a minimal fix on the
trapperkeeper-webserver-jetty9-clojure side to work around the breakage.
This has been confirmed to work in sid/bullseye (1.7.0-3).

For the trapperkeeper-webserver-jetty9-clojure maintainers, I pushed the
change to:
https://salsa.debian.org/jcristau/trapperkeeper-webserver-jetty9-clojure/commits/debian/buster

Cheers,
Julien

diff --git a/debian/changelog b/debian/changelog
index 3bfef40..3d8b882 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+trapperkeeper-webserver-jetty9-clojure (1.7.0-2+deb10u1) buster; urgency=medium
+
+  [ Manfred Stock ]
+  * Add patch for SSL compatibility with newer Jetty (closes: #930562).
+
+ -- Julien Cristau   Fri, 13 Sep 2019 11:00:50 +0200
+
 trapperkeeper-webserver-jetty9-clojure (1.7.0-2) unstable; urgency=medium
 
   * Fix compatibility with Jetty 9.4
diff --git a/debian/patches/0005-maint-Disable-EndpointIdentification.patch 
b/debian/patches/0005-maint-Disable-EndpointIdentification.patch
new file mode 100644
index 000..39890d7
--- /dev/null
+++ b/debian/patches/0005-maint-Disable-EndpointIdentification.patch
@@ -0,0 +1,46 @@
+From 9db4170381e07165078e544340e12b38676c2613 Mon Sep 17 00:00:00 2001
+From: Justin Stoller 
+Date: Fri, 24 May 2019 16:10:44 -0700
+Subject: [PATCH] (maint) Disable EndpointIdentification
+
+Previously, Jetty disabled Endpoint Identification by default as it is a best
+practice for most webservers who often cannot identify clients
+connecting to it. However, in 9.4.15 Jetty changed this default to
+"HTTPS", which is the best practice for _client_ SslContexts. This
+caused serious breakages throughout the Jetty ecosystem and since 9.4.16
+Jetty introduced static inner classes of SslContextFactory, named Server
+and Client, to create the correct contexts for each type of consumer.
+
+Unfortunately, because we subclass SslContextFactory with our own
+InternalSslContextFactory that overrides CRL handling, using these static
+inner class factories is problematic. Consequently, this patch takes the
+approach of simply setting the Endpoint Identification Algorithm to null
+as was previously the default (and necessary in most server
+environments).
+
+This will cause a warning of overriding a deprecated method during
+compilation in newer Java versions and our approach to handling CRLs
+will need to be reworked should we use this codebase as a basis for a
+trapperkeeper-webserver-jetty10 project.
+
+For more info see linked issues to the implementing PR here:
+https://github.com/eclipse/jetty.project/pull/3480/files#diff-58640db0f8f2cd84b7e653d1c1540913
+---
+ src/puppetlabs/trapperkeeper/services/webserver/jetty9_core.clj | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/src/puppetlabs/trapperkeeper/services/webserver/jetty9_core.clj 
b/src/puppetlabs/trapperkeeper/services/webserver/jetty9_core.clj
+index 3a577bb..02e7c7d 100644
+--- a/src/puppetlabs/trapperkeeper/services/webserver/jetty9_core.clj
 b/src/puppetlabs/trapperkeeper/services/webserver/jetty9_core.clj
+@@ -197,6 +197,7 @@
+   (.setKeyStore (:keystore keystore-config))
+   (.setKeyStorePassword (:key-password keystore-config))
+   (.setTrustStore (:truststore keystore-config))
++  (.setEndpointIdentificationAlgorithm nil)
+   ;; Need to clear out the default cipher suite exclude list 
so
+   ;; that Jetty doesn't potentially remove one or more ciphers
+   ;; that we want to be included.
+-- 
+2.20.1
+
diff --git a/debian/patches/series b/debian/patches/series
index cfdab48..1d6304e 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,3 +2,4 @@ jetty-9.4-compat
 0001-SERVER-2213-Remove-call-to-MBeanContainer-resetUniqu.patch
 0003-TK-369-Add-LifeCycleImplementingRequestLogImpl.patch
 0004-Implement-LifeCycle-methods-missing-from-RequestLogI.patch
+0005-maint-Disable-EndpointIdentification.patch

Bug#940018: at-spi2-atk autopkgtest fail most of the time on s390x

I have uploaded a 2.34.0-2 version which sends the dbus-daemon output to
stdout, to get the warnings from dbus-daemon (and possibly
at-spi2-registryd) to check whether the autopkgtest has the same issue
as when you run by hand.

Samuel

Bug#940171: udev mounts /dev with the noexec flag

2019-09-13 Thread Mikulas Patocka

Package: udev
Version: 242-7
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

I use the uvesafb framebuffer, that uses a helper process v86d that
emulates 8086 BIOS to change video modes.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

After some recent udev update, udev sets the "noexec" flag on the /dev/
filesystem. It breaks programs that want to map devices with PROT_EXEC,
such as v86d. uvesafb doesn't work, because v86d can't map memory with the
PROT_EXEC flag.

if I do "mount -o remount,exec /dev", v86d starts normally and uvesafb
works.

   * What was the outcome of this action?

The vm86d program fails with this error:

openat(AT_FDCWD, "/dev/zero", O_RDWR)   = 4
mmap(0x1000, 655360, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED|MAP_FIXED, 4, 
0) = -1 EPERM (Operace není povolena)
dup(2)  = 5
fcntl(5, F_GETFL)   = 0x8001 (flags O_WRONLY|O_LARGEFILE)
close(5)= 0
write(2, "mmap /dev/zero: Operation not pe"..., 40mmap /dev/zero: Operation not 
permitted
) = 40
close(4)= 0
ioperm(0, 0x400, 1) = 0
iopl(3) = 0
exit_group(-1)  = ?

   * What outcome did you expect instead?

The mmap syscall should succeed:

openat(AT_FDCWD, "/dev/zero", O_RDWR)   = 4
mmap(0x1000, 655360, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED|MAP_FIXED, 4, 
0) = 0x1000
close(4)= 0
openat(AT_FDCWD, "/dev/mem", O_RDWR)= 4
mmap(NULL, 1282, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED|MAP_FIXED, 4, 0) = 0
mmap(0xa, 393216, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED|MAP_FIXED, 4, 
0xa) = 0xa
close(4)= 0
ioperm(0, 0x400, 1) = 0
iopl(3) = 0


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


-- Package-specific info:

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

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

Versions of packages udev depends on:
ii  adduser  3.118
ii  dpkg 1.19.7
ii  libacl1  2.2.53-4
ii  libblkid12.34-0.1
ii  libc62.29-1
ii  libkmod2 26-2
ii  libselinux1  2.9-2+b2
ii  libudev1 242-7
ii  util-linux   2.34-0.1

udev recommends no packages.

udev suggests no packages.

Versions of packages udev is related to:
pn  systemd  

-- debconf information:
  udev/reboot_needed:
  udev/sysfs_deprecated_incompatibility:
  udev/title/upgrade:
  udev/new_kernel_needed: false
P: /devices/LNXSYSTM:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:LNXSYSTM:
E: USEC_INITIALIZED=5819107
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation

P: /devices/LNXSYSTM:00/LNXPWRBN:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00
E: SUBSYSTEM=acpi
E: DRIVER=button
E: MODALIAS=acpi:LNXPWRBN:
E: USEC_INITIALIZED=5819804
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation

P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input5
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input5
E: SUBSYSTEM=input
E: PRODUCT=19/0/1/0
E: NAME="Power Button"
E: PHYS="LNXPWRBN/button/input0"
E: PROP=0
E: EV=3
E: KEY=10 0 0 0
E: MODALIAS=input:b0019vp0001e-e0,1,k74,ramlsfw
E: USEC_INITIALIZED=5917024
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_PATH=acpi-LNXPWRBN:00
E: ID_PATH_TAG=acpi-LNXPWRBN_00

P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input5/event4
N: input/event4
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input5/event4
E: SUBSYSTEM=input
E: DEVNAME=/dev/input/event4
E: MAJOR=13
E: MINOR=68
E: USEC_INITIALIZED=6607903
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_PATH=acpi-LNXPWRBN:00
E: ID_PATH_TAG=acpi-LNXPWRBN_00
E: TAGS=:power-switch:

P: /devices/LNXSYSTM:00/LNXSYBUS:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:LNXSYBUS:
E: USEC_INITIALIZED=5820046
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation

P: /devices/LNXSYSTM:00/LNXSYBUS:00/LNXCPU:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/LNXCPU:00
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:LNXCPU:
E: USEC_INITIALIZED=5822836
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation

P: /devices/LNXSYSTM:00/LNXSYBUS:00/LNXCPU:01
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/LNXCPU:01
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:LNXCPU:
E: USEC_INITIALIZED=5824806
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation

P: /devices/LNXSYSTM:00/LNXSYBUS:00/LNXCPU:02
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/LNXCPU:02
E: SU

Bug#939181: [Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye

Hi,

On Thu, Sep 12, 2019 at 09:08:04PM +0200, Michael Kesper wrote:
> > Since I do not have much experience with hashlib I'd be happy if 
> > someone might be able to proof-read `def Save_Cycle` in 
> > save_load.py.
> 
> This does not have anything to do with hashlib per se.
> It's just the usual mess of mixing bytestrings with strings.
> You often don't notice in Python2, it just introduces subtle bugs.
> Python3 is more strict here and doesn't allow it.
> 
> Try this:
> 
> tmp = rt.encrypt('Cycle{}'.format(pickle.dumps(objSave)))

Thanks to this hint and the other hints by Peter Green, I'm now a
bit further.

> As an explanation:
> 
> Python 3.7.3 (default, Apr  3 2019, 05:39:12)
> ...

Thanks as well.

> P.S.: The code is in a bad state regarding whitespace / indentation.
> This is critical to get right in Python (e.g. after a for there _has to_
> be an indentation added, Python normally uses four spaces, no tabs).

I'm aware that the code is not good - there are other issues than spaces
and tabs for instance I removed an instance of os.tempnam where upstream
simply had overridden the automatic warning.  Its unmaintained upstream
as well.

I've seen other code in Debian which is not good as well.  Its rather a
philosophical question whether it is better to drop it from Debian (and
leave its users alone may be fiddling around with the upstream code
themselves) or whether we try our best to make the code at least
acceptable.  I usually subscribe to the latter and think there is no
right or wrong here.

I'm not really sure whether we might manage in this case.  After
implementing all hints I'm now stumbling upon:

Traceback (most recent call last):
  File "/usr/bin/cycle", line 83, in OnCloseWindow
Save_Cycle(cycle.name, cycle.passwd, cycle.file)
  File "/usr/share/cycle/save_load.py", line 46, in Save_Cycle
tmp = rt.encrypt('Cycle{}'.format(pickle.dumps(objSave)))
  File "/usr/share/cycle/p_rotor.py", line 63, in encrypt
return self.cryptmore(buf, 0)
  File "/usr/share/cycle/p_rotor.py", line 88, in cryptmore
c = rotors[i][c ^ pos[i]]
TypeError: unsupported operand type(s) for ^: 'str' and 'int'

I think an  "int(c) ^ pos[i]"  could do here - but I'd like
to get some confirmation first.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#940162: [mmdebstrap] Allow overriding of binfmt_misc search

2019-09-13 Thread Giovanni Mascellani

Hi,

Il 13/09/19 11:42, Johannes Schauer ha scritto:
> the code you quote exists to give meaningful output in cases where foreign
> architecture binaries cannot be executed. Instead of adding another knob to 
> the
> command line interface, I would prefer either of these two solutions:
> 
>  - turn the errors into warnings -- in case there is an error later, the user
>can use the earlier warning to diagnose it
> 
>  - only run the checks after executing a test executable failed as a
>diagnostic. If the test executable was successfully executed, then there is
>no reason to run the checks from above.

Either of these is fine for me. I'd say the first one is easier to
implement, because it does not require to come up with an executable to
test.

Thanks, Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles



signature.asc
Description: OpenPGP digital signature

Bug#940172: gcr: FTBFS with GLib 2.62: ERROR: missing test

Source: gcr
Version: 3.28.1-2
Severity: important
Tags: bullseye sid patch fixed-upstream
Control: block 940161 by -1
Forwarded: https://gitlab.gnome.org/GNOME/gcr/issues/26

We never had a bug to represent this FTBFS with GLib 2.62:

> ERROR: test-dn 1 - missing test
> ERROR: test-dn 2 - missing test
> ERROR: test-dn 3 - missing test

This is the same thing as #940157 in gnome-keyring, #940159 in realmd,
and #940086 in libsecret. It's already fixed in experimental, but not
in unstable yet.

I'll close this as fixed in 3.33.4-1 when I have a bug number.

smcv

Bug#938494: skimage (build-)depends on python-cloudpickle which has already been dropped

On Fri, Sep 13, 2019 at 11:09:58AM +0200, Ole Streicher wrote:
> > Sure.  But do you want to do team uploads of python-numpy and its > 300
> > rdepends as well?  I was considering the amount of packages that are
> > affected by RC bugs which is way lower if we leave skimage RC buggy
> > rather than making python-numpy RC buggy.  I mean, in the end we need to
> > port everything but we can decide about a noisy mailing list flooding us
> > every now and than with 300 mails about packages getting removed from
> > testing or keeping that number at about 20.
> 
> I am not sure I understand you here.
> 
> skimage is now scheduled for autoremoval; I really think we should go
> forward here. And as far as I remember, numpy is secured from
> autoremoval, so even an RC buggy numpy will not lead to autoremoval.

Ahhh, I was not aware that this safety line exists.  In this case it
might make sense to proceed from here as you said since the harm is done
anyway and the other rdepends from skimage might be not as important.
I have not checked further.

> I now pushed skimage_0.14.2-3 to salsa, with Python 2 removed. Just
> awaiting the salsa CI tests: shall I upload or shall I wait? We should
> go forward, shouldn't we?

I'm definitely not against progress even a forced one.  I was just
concerned about finding 300 useless mails in my inbox in a regular
frequency.  BTW, I even found some false positives in the calculation
where rdepends are fixed in unstable.  However I also found rdepends
without any open bug (arden) which I simply fixed.

> > BTW, you can start with droping rdepends by droping astro-python
> > metapackage.
> 
> Oops, I thought that I already uploaded it. Will do ASAP.

:-)

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#940135: libuhd-dev: uhd.pc missing -lboost_system produces build failures

2019-09-13 Thread Pau Espin Pedrol

osmo-trx.git indeed uses boost, but not all target binaries do. In fact, 
only osmo-trx-usrp1 does, and it uses it minimally. Only references to 
boost in code are here:


Transceiver52M/device/usrp1/USRPDevice.h
35:#include 
36:typedef boost::shared_ptr usrp_standard_tx_sptr;
37:typedef boost::shared_ptr usrp_standard_rx_sptr;

However, the build failure happens for osmo-trx-uhd binary target, which 
uses UHD as a backend but doesn't use boost itself at all:

[  397s] /usr/bin/ld: ./device/uhd/.libs/libdevice.a(UHDDevice.o):
 undefined reference to symbol '_ZN5boost6system16generic_categoryEv'

Related files to UHDDevice.o are:
https://git.osmocom.org/osmo-trx/tree/Transceiver52M/device/uhd

So unless I'm missing something important, UHDDevice shouldn't be 
failing to build because it's not explicitly using boost, and boost is 
only used internally by UHD in there.


I'm personally using ArchLinux and in there the patch removing the 
-lboost_system is not applied. I tried applying the patch on my system 
(removing -lboost_system from uhd.pc) and osmo-trx-uhd is still building 
fine on my system (but it seems it doesn't in Debian testing/unstable). 
I'm using 3.14.1.0-1 on my system.


With that patch applied, I see only reference to boost appears while 
linking osmo-trx-usrp1, which is correct because it's the only one using 
boost explicitly:

"""
libtool: link: g++ -I/home/pespin/dev/sysmocom/build/new/out/include/ 
-I/home/pespin/dev/sysmocom/build/new/out/include/ 
-I/home/pespin/dev/sysmocom/build/new/out/include/ -g 
-fno-omit-frame-pointer -fsanitize=address -fsanitize=undefined -o 
osmo-trx-usrp1 osmo_trx_usrp1-osmo-trx.o -Wl,-rpath -Wl,/usr/lib 
-Wl,-rpath -Wl,/usr/lib -Wl,-rpath -Wl,/usr/lib 
./device/usrp1/.libs/libdevice.a ./.libs/libtransceiver_common.a 
../Transceiver52M/arch/x86/.libs/libarch.a ../GSM/.libs/libGSM.a 
../CommonLibs/.libs/libcommon.a 
-L/home/pespin/dev/sysmocom/build/new/out/lib -lfftw3f 
/home/pespin/dev/sysmocom/build/new/out/lib/libosmoctrl.so 
/home/pespin/dev/sysmocom/build/new/out/lib/libosmogsm.so -lgnutls 
/home/pespin/dev/sysmocom/build/new/out/lib/libosmovty.so 
/home/pespin/dev/sysmocom/build/new/out/lib/libosmocore.so -ltalloc -ldl 
/home/pespin/dev/sysmocom/build/new/out/lib/libusrp.so -L/usr/lib64 
-lboost_thread -lpthread -lboost_system -lusb-1.0 -Wl,-rpath 
-Wl,/home/pespin/dev/sysmocom/build/new/out/lib -Wl,-rpath 
-Wl,/home/pespin/dev/sysmocom/build/new/out/lib

"""

Checking ldd, my libuhd links to libboost_system internally:
"""
ldd /usr/lib/libuhd.so.3.14.1 | grep boost
libboost_chrono.so.1.69.0 => /usr/lib/libboost_chrono.so.1.69.0 
(0x7fe729c2f000)
libboost_date_time.so.1.69.0 => 
/usr/lib/libboost_date_time.so.1.69.0 (0x7fe729c1c000)
libboost_filesystem.so.1.69.0 => 
/usr/lib/libboost_filesystem.so.1.69.0 (0x7fe729bfe000)
libboost_regex.so.1.69.0 => /usr/lib/libboost_regex.so.1.69.0 
(0x7fe729b1e000)
libboost_serialization.so.1.69.0 => 
/usr/lib/libboost_serialization.so.1.69.0 (0x7fe729ada000)
libboost_thread.so.1.69.0 => /usr/lib/libboost_thread.so.1.69.0 
(0x7fe729ab3000)
libboost_system.so.1.69.0 => /usr/lib/libboost_system.so.1.69.0 
(0x7fe72932b000)

"""

And same goes for osmo-trx-uhd (probably inherited by linking to libuhd):
"""
ldd new/out/bin/osmo-trx-uhd | grep -e boost -e uhd
libuhd.so.3.14.1 => /usr/lib/libuhd.so.3.14.1 (0x7f60ce5b)
libboost_chrono.so.1.69.0 => /usr/lib/libboost_chrono.so.1.69.0 
(0x7f60cd0f8000)
libboost_date_time.so.1.69.0 => 
/usr/lib/libboost_date_time.so.1.69.0 (0x7f60cd0e5000)
libboost_filesystem.so.1.69.0 => 
/usr/lib/libboost_filesystem.so.1.69.0 (0x7f60cd0c7000)
libboost_regex.so.1.69.0 => /usr/lib/libboost_regex.so.1.69.0 
(0x7f60ccfe5000)
libboost_serialization.so.1.69.0 => 
/usr/lib/libboost_serialization.so.1.69.0 (0x7f60ccfa1000)
libboost_thread.so.1.69.0 => /usr/lib/libboost_thread.so.1.69.0 
(0x7f60ccf7a000)
libboost_system.so.1.69.0 => /usr/lib/libboost_system.so.1.69.0 
(0x7f60ccd25000)

"""

So far my conclusion is that the debian patch is fine (same patch 
doesn't seem to break build on ArchLinux), but something else is wrong 
in Debian testing/unstable. Perhaps libuhd is not linked to 
libboost_system.so there?



--
- Pau Espin Pedrol  http://www.sysmocom.de/
===
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte

Bug#939894: Minia is lacking symbol from gatb-core (Was: Bug#939894: minia: autopkgtest regression: X.contigs.fa: No such file or directory)

2019-09-13 Thread Olivier Sallou



On 9/12/19 10:11 AM, Andreas Tille wrote:
> On Mon, Sep 09, 2019 at 09:59:09PM +0200, Paul Gevers wrote:
>>  Run simple_test.sh 
>> Traceback (most recent call last):
>>   File "compare_fasta.py", line 21, in 
>> s2 = read_seqs(fasta2)
>>   File "compare_fasta.py", line 15, in read_seqs
>> for  line in open(fasta):
>> IOError: [Errno 2] No such file or directory: 'X.contigs.fa'
> The actual problem is:
>
>$ /usr/bin/minia
> /usr/bin/minia: symbol lookup error: /usr/bin/minia: undefined symbol: 
> _ZN4gatb4core8debruijn4impl9link_tigsILm128EEEvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEiiRmb
>
> I suspect minia needs a different / newer version of libgatbcore2.
>
> @Olivier: You once said you have contact to gatb-core upstream and their
> downstream projects.  Would you be able to teach them about a sensible
> release strategy with some API the depending projects could rely on?  As
> far as I can see the depending projects rely on Git submodules with a
> specific commit which is not really helpful.
unfortunatly, there is nobody left in my lab related to this software... :-(
>
> Kind regards
>
> Andreas.
>
-- 
Olivier Sallou
Univ Rennes, Inria, CNRS, IRISA
Irisa, Campus de Beaulieu
F-35042 RENNES - FRANCE
Tel: 02.99.84.71.95

gpg key id: 4096R/326D8438  (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Bug#940146: perforate FTCBFS: does not pass cross tools to make

2019-09-13 Thread Reuben Thomas

On Fri, 13 Sep 2019 at 05:33, Helmut Grohne  wrote:

> Source: perforate
> Version: 1.2-5.1
> Tags: patch
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
>
> perforate fails to cross build from source, because it does not pass
> cross tools to make. The easiest way of doing so - using dh_auto_build -
> makes perforate cross buildable. Please consider applying the attached
> patch.

Thanks for this. I'm currently trying to replace perforate with a new
version of the package, finddup: https://github.com/rrthomas/finddup/

Currently I'm stuck on trying to get the latest version uploaded to the NEW
queue; if by any chance someone could help with that, that would be great
(I'm a DM, not a DD). I did have some help before, but I've not been able
to get in touch with the DDs concerned in the last year.

-- 
https://rrt.sc3d.org

Bug#940173: mmdebstrap hooks should be able to remove start-stop-daemon

2019-09-13 Thread Helmut Grohne

Package: mmdebstrap
Version: 0.4.1-6
Severity: minor
Tags: patch

Hi josch,

I ran into another minor problem with the (unofficial) hooks. If a
--customize-hook removes /sbin/start-stop-daemon.REAL, mmdebstrap fails.
Can we make it cope with that situation? I'm attaching some patches for
you.

Helmut
>From 7c53a346c2c20e5dbff6b30c2a7f7acc6dd280ec Mon Sep 17 00:00:00 2001
From: Helmut Grohne 
Date: Fri, 13 Sep 2019 12:36:02 +0200
Subject: [PATCH 1/3] fix error message about opening s-s-d

---
 mmdebstrap | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mmdebstrap b/mmdebstrap
index 0fdd6ee..5c331aa 100755
--- a/mmdebstrap
+++ b/mmdebstrap
@@ -863,7 +863,7 @@ sub run_chroot(&$) {
 
 	{
 	move("$options->{root}/sbin/start-stop-daemon", "$options->{root}/sbin/start-stop-daemon.REAL") or error "cannot move start-stop-daemon";
-	open my $fh, '>', "$options->{root}/sbin/start-stop-daemon" or error "cannot open policy-rc.d: $!";
+	open my $fh, '>', "$options->{root}/sbin/start-stop-daemon" or error "cannot open start-stop-daemon: $!";
 	print $fh "#!/bin/sh\n";
 	print $fh "echo \"Warning: Fake start-stop-daemon called, doing nothing\">&2\n";
 	close $fh;
-- 
2.20.1

>From 00fd0dc4b31418754a43f4f0c082dc20615a5073 Mon Sep 17 00:00:00 2001
From: Helmut Grohne 
Date: Fri, 13 Sep 2019 12:36:59 +0200
Subject: [PATCH 2/3] make errors about moving s-s-d more verbose

---
 mmdebstrap | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mmdebstrap b/mmdebstrap
index 5c331aa..cd9f96b 100755
--- a/mmdebstrap
+++ b/mmdebstrap
@@ -862,7 +862,7 @@ sub run_chroot(&$) {
 	}
 
 	{
-	move("$options->{root}/sbin/start-stop-daemon", "$options->{root}/sbin/start-stop-daemon.REAL") or error "cannot move start-stop-daemon";
+	move("$options->{root}/sbin/start-stop-daemon", "$options->{root}/sbin/start-stop-daemon.REAL") or error "cannot move start-stop-daemon: $!";
 	open my $fh, '>', "$options->{root}/sbin/start-stop-daemon" or error "cannot open start-stop-daemon: $!";
 	print $fh "#!/bin/sh\n";
 	print $fh "echo \"Warning: Fake start-stop-daemon called, doing nothing\">&2\n";
@@ -873,7 +873,7 @@ sub run_chroot(&$) {
 	&{$cmd}();
 
 	# cleanup
-	move("$options->{root}/sbin/start-stop-daemon.REAL", "$options->{root}/sbin/start-stop-daemon") or error "cannot move start-stop-daemon";
+	move("$options->{root}/sbin/start-stop-daemon.REAL", "$options->{root}/sbin/start-stop-daemon") or error "cannot move start-stop-daemon: $!";
 	unlink "$options->{root}/usr/sbin/policy-rc.d" or error "cannot unlink policy-rc.d: $!";
 
 };
-- 
2.20.1

>From 8033519aa0de689f579fe59d4b1142e87c11bdc8 Mon Sep 17 00:00:00 2001
From: Helmut Grohne 
Date: Fri, 13 Sep 2019 12:37:28 +0200
Subject: [PATCH 3/3] allow messing with s-s-d in hooks

Presently, mmdebstrap fails hard if e.g. a --setup-hook removes
start-stop-daemon.REAL.
---
 mmdebstrap | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/mmdebstrap b/mmdebstrap
index cd9f96b..f3a64ba 100755
--- a/mmdebstrap
+++ b/mmdebstrap
@@ -861,7 +861,7 @@ sub run_chroot(&$) {
 	chmod 0755, "$options->{root}/usr/sbin/policy-rc.d" or error "cannot chmod policy-rc.d: $!";
 	}
 
-	{
+	if (-e "$options->{root}/sbin/start-stop-daemon") {
 	move("$options->{root}/sbin/start-stop-daemon", "$options->{root}/sbin/start-stop-daemon.REAL") or error "cannot move start-stop-daemon: $!";
 	open my $fh, '>', "$options->{root}/sbin/start-stop-daemon" or error "cannot open start-stop-daemon: $!";
 	print $fh "#!/bin/sh\n";
@@ -873,7 +873,9 @@ sub run_chroot(&$) {
 	&{$cmd}();
 
 	# cleanup
-	move("$options->{root}/sbin/start-stop-daemon.REAL", "$options->{root}/sbin/start-stop-daemon") or error "cannot move start-stop-daemon: $!";
+	if (-e "$options->{root}/sbin/start-stop-daemon.REAL") {
+	move("$options->{root}/sbin/start-stop-daemon.REAL", "$options->{root}/sbin/start-stop-daemon") or error "cannot move start-stop-daemon: $!";
+	}
 	unlink "$options->{root}/usr/sbin/policy-rc.d" or error "cannot unlink policy-rc.d: $!";
 
 };
-- 
2.20.1

Bug#939894: Minia is lacking symbol from gatb-core (Was: Bug#939894: minia: autopkgtest regression: X.contigs.fa: No such file or directory)

On Fri, Sep 13, 2019 at 12:34:27PM +0200, Olivier Sallou wrote:
> 
> > /usr/bin/minia: symbol lookup error: /usr/bin/minia: undefined symbol: 
> > _ZN4gatb4core8debruijn4impl9link_tigsILm128EEEvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEiiRmb
> >
> > I suspect minia needs a different / newer version of libgatbcore2.
> >
> > @Olivier: You once said you have contact to gatb-core upstream and their
> > downstream projects.  Would you be able to teach them about a sensible
> > release strategy with some API the depending projects could rely on?  As
> > far as I can see the depending projects rely on Git submodules with a
> > specific commit which is not really helpful.
> unfortunatly, there is nobody left in my lab related to this software... :-(

While this is unfortunate does this mean "I'll care for the package
anyway" or "I will not do anything for the near future"?

Kind regards

Andreas.

-- 
http://fam-tille.de

Bug#938494: skimage (build-)depends on python-cloudpickle which has already been dropped

2019-09-13 Thread Andrey Rahmatullin

On Fri, Sep 13, 2019 at 05:16:30PM +0800, Drew Parsons wrote:
> Python maintainers, remember, check your reverse dependencies before
> dropping your python2 packages.
> Check each of
> 
>   build-rdeps python-yourmodule
>   apt-rdepends -r python-yourmodule
> 
> and confirm the package has rdeps=0 on Sandro's list at
> http://sandrotosi.me/debian/py2removal/index.html
And grep-dctrl -FTestsuite-triggers $pkg -sPackage 
/var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_source_Sources 

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#935073: RM: epigrass -- RoQA; Obsolete libs - Qt4 and Python2, dead upstream

Hi again,

I do not really want to sound impatient, but I wonder if just

git tag 
git push --tags

is consuming much time at your side.  The point is that Qt4 will be
removed *this week* from Debian and once epigrass might be out passing
the new queue again is a long process.

Sorry if I sound impatient but if you confirm that you have *real*
trouble to set tags I might find other means meanwhile which is more
time consuming on my side but I could work around to some extend.

Kind regards

Andreas.

On Mon, Sep 09, 2019 at 10:52:16AM -0300, Flavio Coelho wrote:
> Ok I'll do that as soon as I can.
> 
> 
> Em seg, 9 de set de 2019 09:53, Andreas Tille 
> escreveu:
> 
> > Hi Flavio,
> >
> > thanks a lot for your quick response.
> > It would be extremely helpful if you would consider tagging the release.
> > Even a pre-release tag like 2.5~pre1 / 3.0~beta or whatever version you
> > might prefer would be helpful.  Thus we could point the Debian watch file
> > to
> >
> >https://github.com/fccoelho/epigrass
> >
> > Thanks a lot
> >  Andreas.
> >
> > On Sat, Sep 07, 2019 at 10:54:22AM -0300, Flavio Coelho wrote:
> > > It is on the master branch: https://github.com/fccoelho/epigrass
> > > Flávio Codeço Coelho
> > > 
> > > +55(21) 3799-5735
> > > Professor
> > > Escola de Matemática Aplicada
> > > Fundação Getulio Vargas
> > > Praia de Botafogo, 190 sala 508
> > > Rio de Janeiro - RJ
> > > 22250-900
> > > Brasil
> > >
> > >
> > >
> > > On Sat, Sep 7, 2019 at 10:53 AM Flavio Coelho 
> > wrote:
> > >
> > > > Ok,
> > > >
> > > > I have just pushed a functional realease into Github which have no
> > > > dependencies on Qt anymore.
> > > > Please let me know If I need to do anything else.
> > > >
> > > >
> > > > Flávio Codeço Coelho
> > > > 
> > > > +55(21) 3799-5735
> > > > Professor
> > > > Escola de Matemática Aplicada
> > > > Fundação Getulio Vargas
> > > > Praia de Botafogo, 190 sala 508
> > > > Rio de Janeiro - RJ
> > > > 22250-900
> > > > Brasil
> > > >
> > > >
> > > >
> > > > On Fri, Sep 6, 2019 at 9:22 AM Flavio Coelho 
> > wrote:
> > > >
> > > >> Ok, thanks for the update. It should not take long now.
> > > >> Flávio Codeço Coelho
> > > >> 
> > > >> +55(21) 3799-5735
> > > >> Professor
> > > >> Escola de Matemática Aplicada
> > > >> Fundação Getulio Vargas
> > > >> Praia de Botafogo, 190 sala 508
> > > >> Rio de Janeiro - RJ
> > > >> 22250-900
> > > >> Brasil
> > > >>
> > > >>
> > > >>
> > > >> On Fri, Sep 6, 2019 at 4:37 AM Andreas Tille 
> > wrote:
> > > >>
> > > >>> Hi again,
> > > >>>
> > > >>> just to let you know Qt4 removal is scheduled for next week.  We
> > should
> > > >>> really hurry up.
> > > >>>
> > > >>> Kind regards
> > > >>>
> > > >>>Andreas.
> > > >>>
> > > >>> On Fri, Aug 30, 2019 at 03:24:52PM -0300, Flavio Coelho wrote:
> > > >>> > its almost done. I am fixing the bugs resulting from porting to
> > python
> > > >>> 3.
> > > >>> >
> > > >>> >
> > > >>> >
> > > >>> > Flávio Codeço Coelho
> > > >>> > 
> > > >>> > +55(21) 3799-5735
> > > >>> > Professor
> > > >>> > Escola de Matemática Aplicada
> > > >>> > Fundação Getulio Vargas
> > > >>> > Praia de Botafogo, 190 sala 508
> > > >>> > Rio de Janeiro - RJ
> > > >>> > 22250-900
> > > >>> > Brasil
> > > >>> >
> > > >>> >
> > > >>> >
> > > >>> > On Fri, Aug 30, 2019 at 9:07 AM Andreas Tille <
> > andr...@fam-tille.de>
> > > >>> wrote:
> > > >>> >
> > > >>> > > Hi,
> > > >>> > >
> > > >>> > > any news?
> > > >>> > >
> > > >>> > > Kind regards
> > > >>> > >
> > > >>> > >   Andreas.
> > > >>> > >
> > > >>> > > On Mon, Aug 19, 2019 at 02:41:59PM +0200, Andreas Tille wrote:
> > > >>> > > > BTW, feel free to cherry pick from
> > > >>> > > >
> > > >>> > > >
> > > >>> > >
> > > >>>
> > https://salsa.debian.org/med-team/epigrass/blob/master/debian/patches/py3
> > > >>> > > >
> > > >>> > > > since Michael Crusoe had once pushed some Python3 changes to
> > our
> > > >>> > > packaging
> > > >>> > > > Git.
> > > >>> > > >
> > > >>> > > > Hope this helps, Andreas.
> > > >>> > > >
> > > >>> > > > On Mon, Aug 19, 2019 at 09:07:35AM -0300, Flavio Coelho wrote:
> > > >>> > > > > That shouldn't be hard.
> > > >>> > > > >
> > > >>> > > > > Em seg, 19 de ago de 2019 08:35, Mattia Rizzolo <
> > > >>> mat...@debian.org>
> > > >>> > > > > escreveu:
> > > >>> > > > >
> > > >>> > > > > > On Mon, Aug 19, 2019 at 08:10:33AM -0300, Flavio Coelho
> > wrote:
> > > >>> > > > > > > As the author of epigrass, I can assure you that I will
> > not
> > > >>> be
> > > >>> > > porting
> > > >>> > > > > > the
> > > >>> > > > > > > Qt interface. However, epigrass can be used entirely
> > from the
> > > >>> > > console.
> > > >>> > > > > > >
> > > >>> > > > > > > what I can do is to make a new release removing all
> > > >>> dependencies
> > > >>> > > on Qt.
> > > >>> > > > > >
> > > >>> > > > > > According to the bug, the program also uses python2.
> > You'll
> > > >>> need to
> > > >>> >

Bug#940100: Possible fix in OpenSUSE

2019-09-13 Thread Lasse Kliemann

There seems to be a fix available in an OpenSUSE package of SDDM:

https://www.reddit.com/r/openSUSE/comments/atw78q/random_folders_appearing_in_fresh_tubmleweed_kde/


signature.asc
Description: PGP signature

Bug#935073: RM: epigrass -- RoQA; Obsolete libs - Qt4 and Python2, dead upstream

2019-09-13 Thread Flavio Coelho

Done. sorry for the delay.
Flávio Codeço Coelho

+55(21) 3799-5735
Professor
Escola de Matemática Aplicada
Fundação Getulio Vargas
Praia de Botafogo, 190 sala 508
Rio de Janeiro - RJ
22250-900
Brasil



On Fri, Sep 13, 2019 at 8:41 AM Andreas Tille  wrote:

> Hi again,
>
> I do not really want to sound impatient, but I wonder if just
>
> git tag 
> git push --tags
>
> is consuming much time at your side.  The point is that Qt4 will be
> removed *this week* from Debian and once epigrass might be out passing
> the new queue again is a long process.
>
> Sorry if I sound impatient but if you confirm that you have *real*
> trouble to set tags I might find other means meanwhile which is more
> time consuming on my side but I could work around to some extend.
>
> Kind regards
>
> Andreas.
>
> On Mon, Sep 09, 2019 at 10:52:16AM -0300, Flavio Coelho wrote:
> > Ok I'll do that as soon as I can.
> >
> >
> > Em seg, 9 de set de 2019 09:53, Andreas Tille 
> > escreveu:
> >
> > > Hi Flavio,
> > >
> > > thanks a lot for your quick response.
> > > It would be extremely helpful if you would consider tagging the
> release.
> > > Even a pre-release tag like 2.5~pre1 / 3.0~beta or whatever version you
> > > might prefer would be helpful.  Thus we could point the Debian watch
> file
> > > to
> > >
> > >https://github.com/fccoelho/epigrass
> > >
> > > Thanks a lot
> > >  Andreas.
> > >
> > > On Sat, Sep 07, 2019 at 10:54:22AM -0300, Flavio Coelho wrote:
> > > > It is on the master branch: https://github.com/fccoelho/epigrass
> > > > Flávio Codeço Coelho
> > > > 
> > > > +55(21) 3799-5735
> > > > Professor
> > > > Escola de Matemática Aplicada
> > > > Fundação Getulio Vargas
> > > > Praia de Botafogo, 190 sala 508
> > > > Rio de Janeiro - RJ
> > > > 22250-900
> > > > Brasil
> > > >
> > > >
> > > >
> > > > On Sat, Sep 7, 2019 at 10:53 AM Flavio Coelho 
> > > wrote:
> > > >
> > > > > Ok,
> > > > >
> > > > > I have just pushed a functional realease into Github which have no
> > > > > dependencies on Qt anymore.
> > > > > Please let me know If I need to do anything else.
> > > > >
> > > > >
> > > > > Flávio Codeço Coelho
> > > > > 
> > > > > +55(21) 3799-5735
> > > > > Professor
> > > > > Escola de Matemática Aplicada
> > > > > Fundação Getulio Vargas
> > > > > Praia de Botafogo, 190 sala 508
> > > > > Rio de Janeiro - RJ
> > > > > 22250-900
> > > > > Brasil
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Sep 6, 2019 at 9:22 AM Flavio Coelho 
> > > wrote:
> > > > >
> > > > >> Ok, thanks for the update. It should not take long now.
> > > > >> Flávio Codeço Coelho
> > > > >> 
> > > > >> +55(21) 3799-5735
> > > > >> Professor
> > > > >> Escola de Matemática Aplicada
> > > > >> Fundação Getulio Vargas
> > > > >> Praia de Botafogo, 190 sala 508
> > > > >> Rio de Janeiro - RJ
> > > > >> 22250-900
> > > > >> Brasil
> > > > >>
> > > > >>
> > > > >>
> > > > >> On Fri, Sep 6, 2019 at 4:37 AM Andreas Tille 
> > > wrote:
> > > > >>
> > > > >>> Hi again,
> > > > >>>
> > > > >>> just to let you know Qt4 removal is scheduled for next week.  We
> > > should
> > > > >>> really hurry up.
> > > > >>>
> > > > >>> Kind regards
> > > > >>>
> > > > >>>Andreas.
> > > > >>>
> > > > >>> On Fri, Aug 30, 2019 at 03:24:52PM -0300, Flavio Coelho wrote:
> > > > >>> > its almost done. I am fixing the bugs resulting from porting to
> > > python
> > > > >>> 3.
> > > > >>> >
> > > > >>> >
> > > > >>> >
> > > > >>> > Flávio Codeço Coelho
> > > > >>> > 
> > > > >>> > +55(21) 3799-5735
> > > > >>> > Professor
> > > > >>> > Escola de Matemática Aplicada
> > > > >>> > Fundação Getulio Vargas
> > > > >>> > Praia de Botafogo, 190 sala 508
> > > > >>> > Rio de Janeiro - RJ
> > > > >>> > 22250-900
> > > > >>> > Brasil
> > > > >>> >
> > > > >>> >
> > > > >>> >
> > > > >>> > On Fri, Aug 30, 2019 at 9:07 AM Andreas Tille <
> > > andr...@fam-tille.de>
> > > > >>> wrote:
> > > > >>> >
> > > > >>> > > Hi,
> > > > >>> > >
> > > > >>> > > any news?
> > > > >>> > >
> > > > >>> > > Kind regards
> > > > >>> > >
> > > > >>> > >   Andreas.
> > > > >>> > >
> > > > >>> > > On Mon, Aug 19, 2019 at 02:41:59PM +0200, Andreas Tille
> wrote:
> > > > >>> > > > BTW, feel free to cherry pick from
> > > > >>> > > >
> > > > >>> > > >
> > > > >>> > >
> > > > >>>
> > >
> https://salsa.debian.org/med-team/epigrass/blob/master/debian/patches/py3
> > > > >>> > > >
> > > > >>> > > > since Michael Crusoe had once pushed some Python3 changes
> to
> > > our
> > > > >>> > > packaging
> > > > >>> > > > Git.
> > > > >>> > > >
> > > > >>> > > > Hope this helps, Andreas.
> > > > >>> > > >
> > > > >>> > > > On Mon, Aug 19, 2019 at 09:07:35AM -0300, Flavio Coelho
> wrote:
> > > > >>> > > > > That shouldn't be hard.
> > > > >>> > > > >
> > > > >>> > > > > Em seg, 19 de ago de 2019 08:35, Mattia Rizzolo <
> > > > >>> mat...@debian.org>
> > > > >>> > > > > escreveu:
> > > > >>> > > > >
> > > > >>> > > > >

Bug#940174: gimp: GIMP crashed with a fatal error: fatal error: Segmentation fault

2019-09-13 Thread Frank Jung

Package: gimp
Version: 2.10.8-2+b1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Q) What led up to the situation?
A) open any image file

Q) What exactly did you do (or not do) that was effective (or ineffective)?
A) choose restart

Q) What was the outcome of this action?
A) Restarting gimp fails with same error

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

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

```
> fatal error: Segmentation fault

Stack trace:
```
/usr/lib/libgimpbase-2.0.so.0(gimp_stack_trace_print+0x398)[0x7fad825c6f98]
gimp(+0xd1590)[0x55da72679590]
gimp(+0xd19b8)[0x55da726799b8]
gimp(+0xd2029)[0x55da7267a029]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12730)[0x7fad81aa2730]
gimp(gimp_gegl_mask_is_empty+0x91)[0x55da72a64411]
gimp(+0x3b7810)[0x55da7295f810]
gimp(select_actions_update+0x8d)[0x55da726a74ed]
gimp(+0x2be59b)[0x55da7286659b]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_closure_invoke+0x19d)[0x7fad81d6de8d]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x26dad)[0x7fad81d80dad]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_signal_emit_valist+0xd8e)[0x7fad81d8a4ae]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_signal_emit+0x8f)[0x7fad81d8ab6f]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_closure_invoke+0x19d)[0x7fad81d6de8d]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x276a4)[0x7fad81d816a4]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_signal_emit_valist+0xd8e)[0x7fad81d8a4ae]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_signal_emit+0x8f)[0x7fad81d8ab6f]
gimp(gimp_display_shell_scaled+0xe3)[0x55da7275c7c3]
gimp(gimp_display_shell_reconnect+0xc8)[0x55da7275c8d8]
gimp(gimp_display_set_image+0x15c)[0x55da727581dc]
gimp(gimp_display_fill+0x8f)[0x55da72758def]
gimp(+0xd6060)[0x55da7267e060]
gimp(+0x116d0c)[0x55da726bed0c]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_closure_invoke+0x19d)[0x7fad81d6de8d]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x27555)[0x7fad81d81555]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_signal_emit_valist+0xd8e)[0x7fad81d8a4ae]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_signal_emit+0x8f)[0x7fad81d8ab6f]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_closure_invoke+0x19d)[0x7fad81d6de8d]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x27555)[0x7fad81d81555]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_signal_emit_valist+0xd8e)[0x7fad81d8a4ae]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_signal_emit+0x8f)[0x7fad81d8ab6f]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x8de25)[0x7fad82773e25]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_closure_invoke+0x19d)[0x7fad81d6de8d]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x276a4)[0x7fad81d816a4]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_signal_emit_valist+0xd8e)[0x7fad81d8a4ae]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_signal_emit+0x8f)[0x7fad81d8ab6f]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x8cd69)[0x7fad82772d69]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x1331eb)[0x7fad828191eb]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_closure_invoke+0x19d)[0x7fad81d6de8d]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x26dad)[0x7fad81d80dad]
/usr/lib/x86_64-li

Bug#938215: python-testtools: Python2 removal in sid/bullseye

2019-09-13 Thread peter green


severity 938215 serious
thanks

python-testtools depends on the python-extras binary package which is no longer 
built by the python-extras source package.

Bug#940171: udev mounts /dev with the noexec flag

2019-09-13 Thread Michael Biebl

Control: reassign -1 initramfs-tools 0.135

Am 13.09.19 um 11:54 schrieb Mikulas Patocka:
> Package: udev
> Version: 242-7
> Severity: normal
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> 
> I use the uvesafb framebuffer, that uses a helper process v86d that
> emulates 8086 BIOS to change video modes.
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> After some recent udev update, udev sets the "noexec" flag on the /dev/
> filesystem. It breaks programs that want to map devices with PROT_EXEC,
> such as v86d. uvesafb doesn't work, because v86d can't map memory with the
> PROT_EXEC flag.
> 
> if I do "mount -o remount,exec /dev", v86d starts normally and uvesafb
> works.
> 
>* What was the outcome of this action?
> 
> The vm86d program fails with this error:
> 
> openat(AT_FDCWD, "/dev/zero", O_RDWR)   = 4
> mmap(0x1000, 655360, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED|MAP_FIXED, 4, 
> 0) = -1 EPERM (Operace není povolena)
> dup(2)  = 5
> fcntl(5, F_GETFL)   = 0x8001 (flags O_WRONLY|O_LARGEFILE)
> close(5)= 0
> write(2, "mmap /dev/zero: Operation not pe"..., 40mmap /dev/zero: Operation 
> not permitted
> ) = 40
> close(4)= 0
> ioperm(0, 0x400, 1) = 0
> iopl(3) = 0
> exit_group(-1)  = ?
> 
>* What outcome did you expect instead?
> 
> The mmap syscall should succeed:
> 
> openat(AT_FDCWD, "/dev/zero", O_RDWR)   = 4
> mmap(0x1000, 655360, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED|MAP_FIXED, 4, 
> 0) = 0x1000
> close(4)= 0
> openat(AT_FDCWD, "/dev/mem", O_RDWR)= 4
> mmap(NULL, 1282, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED|MAP_FIXED, 4, 0) 
> = 0
> mmap(0xa, 393216, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED|MAP_FIXED, 
> 4, 0xa) = 0xa
> close(4)= 0
> ioperm(0, 0x400, 1) = 0
> iopl(3) = 0
> 
> 

Afaics this is a recent initramfs-tools change:

initramfs-tools (0.135) unstable; urgency=medium

  [ Topi Miettinen ]
  * [eb98d2e] init: /dev can be noexec and /run nodev

https://salsa.debian.org/kernel-team/initramfs-tools/merge_requests/9


systemd mounts /dev with the following flags:

https://github.com/systemd/systemd/blob/master/src/core/mount-setup.c#L66



-- 
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#940175: Update d3-format to new upstream version and switch to rollup for build

2019-09-13 Thread Pirate Praveen

package: src:d3-format
version: 1:1.0.2-4

There isa new upstream release 1.4.1. Since rollup is in the archive, 
we can just use thatinstead of main.mk file.

Also upstream now uses terser. noed-tape and node-d3-queue are packaged.

Since it has many major changes, I have updated it in my fork 
https://salsa.debian.org/praveen/d3-format please review and pull or if 
it is okay I can push to js-team and upload.



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

Bug#940176: libptscotch-6.0: typo in name of libptesmumps-6.so

2019-09-13 Thread Winfried Boxleitner

Package: libptscotch-6.0
Version: 6.0.8-1~exp1
Severity: important
Tags: patch

Dear Maintainer,

   when linking a program, which uses slepc the followint error was issued:
   "/usr/bin/ld: warning: libptesmumps-6.so, needed by 
/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/libslepc.so, not 
found"

   apt-file search gave:
   libptscotch-6.0: /usr/lib/x86_64-linux-gnu/libptesmumps-6.so
 
   however, instead of /usr/lib/x86_64-linux-gnu/libptesmumps-6.so the file 
installed is named /usr/lib/x86_64-linux-gnu/libptesmumps-.so
 
   a simple rename: libptesmumps-.so -> libptesmumps-6.so solved the problem

regards,
winfried



-- System Information:
Debian Release: 10.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 
'proposed-updates'), (500, 'oldstable-updates'), (500, 
'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'unstable'), (500, 
'testing'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages libptscotch-6.0 depends on:
ii  libbz2-1.0   1.0.6-9.2~deb10u1
ii  libc62.28-10
ii  liblzma5 5.2.4-1
ii  libopenmpi3  3.1.3-11
ii  zlib1g   1:1.2.11.dfsg-1

libptscotch-6.0 recommends no packages.

libptscotch-6.0 suggests no packages.

-- no debconf information

Bug#938255: python-watchdog: Python2 removal in sid/bullseye

2019-09-13 Thread peter green


severity 938255 serious
thanks

python-watchdog depends on the python-pathtools binary package which has 
already been dropped by the python-pathtools source package.

Bug#935290: moar digging

2019-09-13 Thread Dominique Dumont

On Thursday, 12 September 2019 08:33:00 CEST Niels Thykier wrote:
> Does rakudo build with "Rules-Requires-Root: no"[1]?  If it does, then
> you can work around the bug / issue in fakeroot for sid, testing and
> stable for now by using it.

Yes ! I can now build rakudo on my laptop. Thanks for the help :-)

Mo Zhou, can you follow-up and, if possible, release rakudo on unstable ?

All the best

Bug#940178: distro-info autopkgtest failure with new pylint.

2019-09-13 Thread peter green


Package: distro-info
Version: 0.21
Severity: serious
Tags: bullseye, sid

pylint has been migrated from python 2 to python 3. This seems to be causing an 
autopkgtest failure in your package. Can you fix it so that pylint can migrate 
to testing?

Bug#939866: mariadb-server-10.1: replication hangs in state "Slave_IO_Running: Preparing" after upgrade from 10.1.38 to 10.1.41

2019-09-13 Thread Gregory Colpart

Hello,

We confirm this serious bug.

After upgrading from 10.1.38-0+deb9u1 to 10.1.41-0+deb9u1,
replication is completely broken.

For the moment we `apt-mark old` mariadb package with
10.1.38-0+deb9u1 version on all our servers.

Regards,
-- 
Grégory Colpart - CEO Evolix - Clé OpenPGP : 0x44975278B8612B5D
Evolix - Hébergement et Infogérance Open Source
Marseille (37 rue Guibal, Pôle Média, 13003) / Aix / Paris / Montréal
http://evolix.com | Twitter: @Evolix @EvolixNOC | http://blog.evolix.com

Bug#940179: kio-extras: Add apt support

2019-09-13 Thread Lisandro Damián Nicanor Pérez Meyer

Source: kio-extras
Version: 4:18.08.3-1
Severity: wishlist

Hi! Today pabs told me about the apt:// url protocol. After reading
https://help.ubuntu.com/community/AptURL#Konqueror I created those .protocol
files under /usr/share/kservices5 and Discover was launched when using the
apt://packagename url.

Can we consider adding these files? Maybe even pushing them upstream too.

Cheers, Lisandro.


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

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

-- debconf-show failed

Bug#912077: Any chance to get libbiod compiling again?

Hi Matthias,

since a ling time libbiod does not build and it also does not
install.  Current issue when trying to build it is:

...
ldc2 -wi -g -relocation-model=pic -unittest -main -Icontrib/undead -L-lz -O0 
-d-debug -link-debuglib contrib/undead/cstream.o contrib/undead/stream.o 
contrib/undead/doformat.o contrib/undead/utf.o contrib/undead/*/*.o 
bio/core/sequence.o bio/core/kmer.o bio/core/genotype.o bio/core/tinymap.o 
bio/core/base.o bio/core/decompress.o bio/core/call.o bio/core/region.o 
bio/core/bgzf/inputstream.o bio/core/bgzf/constants.o bio/core/bgzf/block.o 
bio/core/bgzf/virtualoffset.o bio/core/bgzf/compress.o bio/core/bgzf/chunk.o 
bio/core/bgzf/outputstream.o bio/core/utils/format.o bio/core/utils/exception.o 
bio/core/utils/outbuffer.o bio/core/utils/stream.o bio/core/utils/algo.o 
bio/core/utils/tmpfile.o bio/core/utils/memoize.o 
bio/core/utils/switchendianness.o bio/core/utils/roundbuf.o 
bio/core/utils/zlib.o bio/core/utils/bylinefast.o bio/core/utils/range.o 
bio/std/file/fastq.o bio/std/file/fasta.o bio/std/file/fai.o 
bio/std/genotype/maf.o bio/std/genotype/snp.o bio/std/range/splitter.o 
bio/std/sff/writer.o bio/std/sff/readrange.o bio/std/sff/index.o 
bio/std/sff/reader.o bio/std/sff/read.o bio/std/sff/constants.o 
bio/std/maf/reader.o bio/std/maf/block.o bio/std/maf/parser.o 
bio/std/experimental/hts/logger.o bio/std/experimental/hts/pileup.o 
bio/std/experimental/hts/bgzf_writer.o bio/std/experimental/hts/reads.o 
bio/std/experimental/hts/bgzf.o bio/std/experimental/hts/unpack.o 
bio/std/experimental/hts/constants.o bio/std/experimental/hts/hashing.o 
bio/std/sff/utils/roundup.o bio/std/hts/iontorrent/flowcall.o 
bio/std/hts/iontorrent/flowindex.o bio/std/hts/sam/reader.o 
bio/std/hts/sam/header.o bio/std/hts/snpcallers/maq.o 
bio/std/hts/snpcallers/simple.o bio/std/hts/bam/abstractreader.o 
bio/std/hts/bam/randomaccessmanager.o bio/std/hts/bam/baifile.o 
bio/std/hts/bam/writer.o bio/std/hts/bam/pileup.o bio/std/hts/bam/splitter.o 
bio/std/hts/bam/tagvalue.o bio/std/hts/bam/constants.o 
bio/std/hts/bam/reference.o bio/std/hts/bam/baseinfo.o 
bio/std/hts/bam/readrange.o bio/std/hts/bam/referenceinfo.o 
bio/std/hts/bam/multireader.o bio/std/hts/bam/reader.o bio/std/hts/bam/read.o 
bio/std/hts/bam/cigar.o bio/std/hts/bam/region.o 
bio/std/hts/thirdparty/msgpack.o bio/std/hts/utils/array.o 
bio/std/hts/utils/value.o bio/std/hts/utils/samheadermerger.o 
bio/std/hts/utils/graph.o bio/std/experimental/hts/bam/reader.o 
bio/std/experimental/hts/bam/writer.o bio/std/experimental/hts/bam/header.o 
bio/std/hts/sam/utils/recordparser.o bio/std/hts/sam/utils/fastrecordparser.o 
bio/std/hts/bam/md/core.o bio/std/hts/bam/md/operation.o 
bio/std/hts/bam/md/reconstruct.o bio/std/hts/bam/md/parse.o 
bio/std/hts/bam/bai/bin.o bio/std/hts/bam/bai/indexing.o 
bio/std/hts/bam/validation/alignment.o bio/std/hts/bam/validation/samheader.o 
-of=bin/biod_tests
/usr/bin/ld.gold: error: bin/biod_tests.o: multiple definition of 
'_d_execBssBegAddr'
/usr/bin/ld.gold: contrib/undead/*/__main.o: previous definition here
/usr/bin/ld.gold: error: bin/biod_tests.o: multiple definition of 
'_d_execBssEndAddr'
/usr/bin/ld.gold: contrib/undead/*/__main.o: previous definition here
collect2: error: ld returned 1 exit status


Would you be able to check latest Git[1] and commit a patch that helps
building the package?  I'm also wondering whether we can remove
libundead.  Its in the Depends of sambaba but as far as I understood
this can go with latest libbiod (but I might be wrong).

Kind regards

Andreas.


[1]  https://salsa.debian.org/med-team/libbiod

-- 
http://fam-tille.de

Bug#940180: ITP: libbio-searchio-hmmer-perl -- perl parser for HMMER2 and HMMER3 output (hmmscan, hmmsearch, hmmpfam)

2019-09-13 Thread Michael R. Crusoe

Package: wnpp
Severity: wishlist

Subject: ITP: libbio-searchio-hmmer-perl -- perl parser for HMMER2 and HMMER3 
output (hmmscan, hmmsearch, hmmpfam)
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: libbio-searchio-hmmer-perl
  Version : 1.7.3
  Upstream Author : Copyright: Balamurugan Kumarasamy , 
Ewan Birney , Jason Stajich , Josh 
Lauricha , Kai Blin 
, Mauricio Herrera Cuadra 
, Sendu Bala , Thomas Sharpton 

* URL : https://metacpan.org/release/Bio-SearchIO-hmmer
* License : Artistic
  Programming Lang: Perl
  Description : perl parser for HMMER2 and HMMER3 output (hmmscan, 
hmmsearch, hmmpfam)
 This object implements a parser for hmmpfam hsp output, a program in the
 HMMER package.

Remark: This package is maintained by Michael R. Crusoe at
   https://salsa.debian.org/med-team/libbio-searchio-hmmer-perl

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

2019-09-13 Thread Fabian Grünbichler




On September 11, 2019 3:45:45 PM UTC, Daniel Kahn Gillmor 
 wrote:
>Over on https://bugs.debian.org/939845, On Wed 2019-09-11 00:26:18
>-0400, Matthew Gabeler-Lee wrote:
>> Having a system update disable a network interface and fail to
>restore it is
>> ... bad.  Luckily I wasn't accessing the systems in question over
>that vpn!
>
>i totally agree that this is bad.  Please see
>https://bugs.debian.org/913446 for the discussion Fabian (in cc) and i
>had around trying to make this robust.  Sorry that we haven't succeeded
>in avoiding all the sharp edges, hopefully we can get the particular
>breakage figured out.
>
>Note that if you don't want any attempt to reload the module, you can
>always just install wireguard-dkms and wireguard-tools directly, and
>leave the wireguard metapackage uninstalled.
>
>Regards,
>   --dkg

I am afk for the next week or so, but if the cause is still unclear I'll spin 
up a test VM and try to reproduce the issue..

Bug#939866: [debian-mysql] Bug#939866: mariadb-server-10.1: replication hangs in state "Slave_IO_Running: Preparing" after upgrade from 10.1.38 to 10.1.41

2019-09-13 Thread Faustin Lammler

Hi Gregory!
Thanks you for the confirmation and the "workaround".

The issue as just been resolved for Buster (see 939819).

I will check with Otto when the next upload is planned for Stretch.

Regards,
Faustin


signature.asc
Description: PGP signature

Bug#912077: Any chance to get libbiod compiling again?

2019-09-13 Thread Matthias Klumpp

Am Fr., 13. Sept. 2019 um 15:21 Uhr schrieb Andreas Tille :
>
> Hi Matthias,
>
> since a ling time libbiod does not build and it also does not
> install.  Current issue when trying to build it is:
>
> ...
> ldc2 -wi -g -relocation-model=pic -unittest -main -Icontrib/undead -L-lz -O0 
> -d-debug -link-debuglib contrib/undead/cstream.o contrib/undead/stream.o 
> contrib/undead/doformat.o contrib/undead/utf.o contrib/undead/*/*.o 
> bio/core/sequence.o bio/core/kmer.o bio/core/genotype.o bio/core/tinymap.o 
> bio/core/base.o bio/core/decompress.o bio/core/call.o bio/core/region.o 
> bio/core/bgzf/inputstream.o bio/core/bgzf/constants.o bio/core/bgzf/block.o 
> bio/core/bgzf/virtualoffset.o bio/core/bgzf/compress.o bio/core/bgzf/chunk.o 
> bio/core/bgzf/outputstream.o bio/core/utils/format.o 
> bio/core/utils/exception.o bio/core/utils/outbuffer.o bio/core/utils/stream.o 
> bio/core/utils/algo.o bio/core/utils/tmpfile.o bio/core/utils/memoize.o 
> bio/core/utils/switchendianness.o bio/core/utils/roundbuf.o 
> bio/core/utils/zlib.o bio/core/utils/bylinefast.o bio/core/utils/range.o 
> bio/std/file/fastq.o bio/std/file/fasta.o bio/std/file/fai.o 
> bio/std/genotype/maf.o bio/std/genotype/snp.o bio/std/range/splitter.o 
> bio/std/sff/writer.o bio/std/sff/readrange.o bio/std/sff/index.o 
> bio/std/sff/reader.o bio/std/sff/read.o bio/std/sff/constants.o 
> bio/std/maf/reader.o bio/std/maf/block.o bio/std/maf/parser.o 
> bio/std/experimental/hts/logger.o bio/std/experimental/hts/pileup.o 
> bio/std/experimental/hts/bgzf_writer.o bio/std/experimental/hts/reads.o 
> bio/std/experimental/hts/bgzf.o bio/std/experimental/hts/unpack.o 
> bio/std/experimental/hts/constants.o bio/std/experimental/hts/hashing.o 
> bio/std/sff/utils/roundup.o bio/std/hts/iontorrent/flowcall.o 
> bio/std/hts/iontorrent/flowindex.o bio/std/hts/sam/reader.o 
> bio/std/hts/sam/header.o bio/std/hts/snpcallers/maq.o 
> bio/std/hts/snpcallers/simple.o bio/std/hts/bam/abstractreader.o 
> bio/std/hts/bam/randomaccessmanager.o bio/std/hts/bam/baifile.o 
> bio/std/hts/bam/writer.o bio/std/hts/bam/pileup.o bio/std/hts/bam/splitter.o 
> bio/std/hts/bam/tagvalue.o bio/std/hts/bam/constants.o 
> bio/std/hts/bam/reference.o bio/std/hts/bam/baseinfo.o 
> bio/std/hts/bam/readrange.o bio/std/hts/bam/referenceinfo.o 
> bio/std/hts/bam/multireader.o bio/std/hts/bam/reader.o bio/std/hts/bam/read.o 
> bio/std/hts/bam/cigar.o bio/std/hts/bam/region.o 
> bio/std/hts/thirdparty/msgpack.o bio/std/hts/utils/array.o 
> bio/std/hts/utils/value.o bio/std/hts/utils/samheadermerger.o 
> bio/std/hts/utils/graph.o bio/std/experimental/hts/bam/reader.o 
> bio/std/experimental/hts/bam/writer.o bio/std/experimental/hts/bam/header.o 
> bio/std/hts/sam/utils/recordparser.o bio/std/hts/sam/utils/fastrecordparser.o 
> bio/std/hts/bam/md/core.o bio/std/hts/bam/md/operation.o 
> bio/std/hts/bam/md/reconstruct.o bio/std/hts/bam/md/parse.o 
> bio/std/hts/bam/bai/bin.o bio/std/hts/bam/bai/indexing.o 
> bio/std/hts/bam/validation/alignment.o bio/std/hts/bam/validation/samheader.o 
> -of=bin/biod_tests
> /usr/bin/ld.gold: error: bin/biod_tests.o: multiple definition of 
> '_d_execBssBegAddr'
> /usr/bin/ld.gold: contrib/undead/*/__main.o: previous definition here
> /usr/bin/ld.gold: error: bin/biod_tests.o: multiple definition of 
> '_d_execBssEndAddr'
> /usr/bin/ld.gold: contrib/undead/*/__main.o: previous definition here
> collect2: error: ld returned 1 exit status
> [...]

It's very likely that undeaD needs to be updated first in order to
compile this again.
Has upgrading that been attempted yet?

Cheers,
Matthias


-- 
I welcome VSRE emails. See http://vsre.info/

Bug#923731: Any volunteer to fix the "usual" issues when upgrading to new version of igv?

Hi,

I upgraded the igv packaging Git[1] to the latest upstream version.  I
never experienced a smooth upgrade to any igv version - but I always
experienced help from a Java expert here on the list.  May be it is time
again to fix:



All input files are considered out-of-date for incremental task ':compileJava'.
Compiling with JDK Java compiler API.
/build/igv-2.6.3+dfsg/src/main/java11/module-info.java:7: error: module not 
found: ant
requires ant;
 ^
/build/igv-2.6.3+dfsg/src/main/java11/module-info.java:8: error: module not 
found: com.google.common
requires com.google.common;
   ^
/build/igv-2.6.3+dfsg/src/main/java11/module-info.java:9: error: module not 
found: commons.io
requires commons.io;
^
/build/igv-2.6.3+dfsg/src/main/java11/module-info.java:10: error: module not 
found: commons.math
requires commons.math;
^
/build/igv-2.6.3+dfsg/src/main/java11/module-info.java:12: error: module not 
found: gson
requires gson;
 ^
/build/igv-2.6.3+dfsg/src/main/java11/module-info.java:13: error: module not 
found: htsjdk
requires htsjdk;
 ^
/build/igv-2.6.3+dfsg/src/main/java11/module-info.java:22: error: module not 
found: log4j
requires log4j;
 ^
/build/igv-2.6.3+dfsg/src/main/java11/module-info.java:23: error: module not 
found: org.apache.logging.log4j
requires org.apache.logging.log4j;
   ^
/build/igv-2.6.3+dfsg/src/main/java11/module-info.java:24: error: module not 
found: org.apache.logging.log4j.core
requires org.apache.logging.log4j.core;
 ^
/build/igv-2.6.3+dfsg/src/main/java11/module-info.java:25: error: module not 
found: swing.layout
requires swing.layout;
  ^
10 errors
:compileJava FAILED
:compileJava (Thread[Task worker for ':',5,main]) completed. Took 4.782 secs.

FAILURE: Build failed with an exception.


The failures are looking like missing Build-Depends at first look but these
should be OK.  Any volunteer?

Kind regards

   Andreas.


[1] https://salsa.debian.org/med-team/igv

-- 
http://fam-tille.de

Bug#935073: RM: epigrass -- RoQA; Obsolete libs - Qt4 and Python2, dead upstream

Thanks a lot! Andreas.

On Fri, Sep 13, 2019 at 08:53:15AM -0300, Flavio Coelho wrote:
> Done. sorry for the delay.
> Flávio Codeço Coelho
> 
> +55(21) 3799-5735
> Professor
> Escola de Matemática Aplicada
> Fundação Getulio Vargas
> Praia de Botafogo, 190 sala 508
> Rio de Janeiro - RJ
> 22250-900
> Brasil
> 
> 
> 
> On Fri, Sep 13, 2019 at 8:41 AM Andreas Tille  wrote:
> 
> > Hi again,
> >
> > I do not really want to sound impatient, but I wonder if just
> >
> > git tag 
> > git push --tags
> >
> > is consuming much time at your side.  The point is that Qt4 will be
> > removed *this week* from Debian and once epigrass might be out passing
> > the new queue again is a long process.
> >
> > Sorry if I sound impatient but if you confirm that you have *real*
> > trouble to set tags I might find other means meanwhile which is more
> > time consuming on my side but I could work around to some extend.
> >
> > Kind regards
> >
> > Andreas.
> >
> > On Mon, Sep 09, 2019 at 10:52:16AM -0300, Flavio Coelho wrote:
> > > Ok I'll do that as soon as I can.
> > >
> > >
> > > Em seg, 9 de set de 2019 09:53, Andreas Tille 
> > > escreveu:
> > >
> > > > Hi Flavio,
> > > >
> > > > thanks a lot for your quick response.
> > > > It would be extremely helpful if you would consider tagging the
> > release.
> > > > Even a pre-release tag like 2.5~pre1 / 3.0~beta or whatever version you
> > > > might prefer would be helpful.  Thus we could point the Debian watch
> > file
> > > > to
> > > >
> > > >https://github.com/fccoelho/epigrass
> > > >
> > > > Thanks a lot
> > > >  Andreas.
> > > >
> > > > On Sat, Sep 07, 2019 at 10:54:22AM -0300, Flavio Coelho wrote:
> > > > > It is on the master branch: https://github.com/fccoelho/epigrass
> > > > > Flávio Codeço Coelho
> > > > > 
> > > > > +55(21) 3799-5735
> > > > > Professor
> > > > > Escola de Matemática Aplicada
> > > > > Fundação Getulio Vargas
> > > > > Praia de Botafogo, 190 sala 508
> > > > > Rio de Janeiro - RJ
> > > > > 22250-900
> > > > > Brasil
> > > > >
> > > > >
> > > > >
> > > > > On Sat, Sep 7, 2019 at 10:53 AM Flavio Coelho 
> > > > wrote:
> > > > >
> > > > > > Ok,
> > > > > >
> > > > > > I have just pushed a functional realease into Github which have no
> > > > > > dependencies on Qt anymore.
> > > > > > Please let me know If I need to do anything else.
> > > > > >
> > > > > >
> > > > > > Flávio Codeço Coelho
> > > > > > 
> > > > > > +55(21) 3799-5735
> > > > > > Professor
> > > > > > Escola de Matemática Aplicada
> > > > > > Fundação Getulio Vargas
> > > > > > Praia de Botafogo, 190 sala 508
> > > > > > Rio de Janeiro - RJ
> > > > > > 22250-900
> > > > > > Brasil
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Fri, Sep 6, 2019 at 9:22 AM Flavio Coelho 
> > > > wrote:
> > > > > >
> > > > > >> Ok, thanks for the update. It should not take long now.
> > > > > >> Flávio Codeço Coelho
> > > > > >> 
> > > > > >> +55(21) 3799-5735
> > > > > >> Professor
> > > > > >> Escola de Matemática Aplicada
> > > > > >> Fundação Getulio Vargas
> > > > > >> Praia de Botafogo, 190 sala 508
> > > > > >> Rio de Janeiro - RJ
> > > > > >> 22250-900
> > > > > >> Brasil
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> On Fri, Sep 6, 2019 at 4:37 AM Andreas Tille 
> > > > wrote:
> > > > > >>
> > > > > >>> Hi again,
> > > > > >>>
> > > > > >>> just to let you know Qt4 removal is scheduled for next week.  We
> > > > should
> > > > > >>> really hurry up.
> > > > > >>>
> > > > > >>> Kind regards
> > > > > >>>
> > > > > >>>Andreas.
> > > > > >>>
> > > > > >>> On Fri, Aug 30, 2019 at 03:24:52PM -0300, Flavio Coelho wrote:
> > > > > >>> > its almost done. I am fixing the bugs resulting from porting to
> > > > python
> > > > > >>> 3.
> > > > > >>> >
> > > > > >>> >
> > > > > >>> >
> > > > > >>> > Flávio Codeço Coelho
> > > > > >>> > 
> > > > > >>> > +55(21) 3799-5735
> > > > > >>> > Professor
> > > > > >>> > Escola de Matemática Aplicada
> > > > > >>> > Fundação Getulio Vargas
> > > > > >>> > Praia de Botafogo, 190 sala 508
> > > > > >>> > Rio de Janeiro - RJ
> > > > > >>> > 22250-900
> > > > > >>> > Brasil
> > > > > >>> >
> > > > > >>> >
> > > > > >>> >
> > > > > >>> > On Fri, Aug 30, 2019 at 9:07 AM Andreas Tille <
> > > > andr...@fam-tille.de>
> > > > > >>> wrote:
> > > > > >>> >
> > > > > >>> > > Hi,
> > > > > >>> > >
> > > > > >>> > > any news?
> > > > > >>> > >
> > > > > >>> > > Kind regards
> > > > > >>> > >
> > > > > >>> > >   Andreas.
> > > > > >>> > >
> > > > > >>> > > On Mon, Aug 19, 2019 at 02:41:59PM +0200, Andreas Tille
> > wrote:
> > > > > >>> > > > BTW, feel free to cherry pick from
> > > > > >>> > > >
> > > > > >>> > > >
> > > > > >>> > >
> > > > > >>>
> > > >
> > https://salsa.debian.org/med-team/epigrass/blob/master/debian/patches/py3
> > > > > >>> > > >
> > > > > >>> > > > since Michael Crusoe had once pushed some Python3 changes
> > to
> > > > our
> > > > > >>> > > p

Bug#940105: linux: serious corruption issue with btrfs

2019-09-13 Thread Christoph Anton Mitterer

Hey.

Just to put some emphasise on this, the fix has now been merged late to
5.3 as urgent.

Also note Filipe's post[0] that the issue can more or less hit anyone.

Cheers,
Chris.


[0] 
https://lore.kernel.org/linux-btrfs/9731b0e7-81f3-4ee5-6f89-b4fd8d981...@petaramesh.org/T/#m7b3863ef7ec5f62a2f7d1b6e99cad2d6dae43b37

Bug#940181: linux-image-5.2.0-2-amd64: Kernel does not accept self-signed modules using UEFI db key

2019-09-13 Thread Sven Willner

Package: src:linux
Version: 5.2.9-2
Severity: important

Dear Maintainer,

I sign the kernel for UEFI secure boot with my own key and also do so for 
custom-build kernel modules such as "vboxdrv" for VirtualBox (package 
virtualbox-6.0). This worked without a flaw for linux-image-4.19.0-5-amd64, but 
this kernel version rejects the signature:

> sudo modprobe -v vboxdrv
insmod /lib/modules/5.2.0-2-amd64/misc/vboxdrv.ko
modprobe: ERROR: could not insert 'vboxdrv': Operation not permitted

In `dmesg` I see my key being loaded:

[1.609556] integrity: Loading X.509 certificate: UEFI:db
[1.609992] integrity: Loaded X.509 cert 'My kernel signing key: 
XX'

it also appears in `cat /proc/keys`, but is probably not trusted:

> sudo keyctl list "%:.builtin_trusted_keys"
2 keys in keyring:
813811236: ---lswrv 0 0 asymmetric: Debian Secure Boot CA: 
6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1
915392374: ---lswrv 0 0 asymmetric: Debian Secure Boot Signer: 
00a7468def

I suspect this is due to kernel config CONFIG_SECONDARY_TRUSTED_KEYRING not 
being set:

> grep CONFIG_SECONDARY_TRUSTED_KEYRING /boot/config-5.2.0-2-amd64
# CONFIG_SECONDARY_TRUSTED_KEYRING is not set

whereas

> grep CONFIG_SECONDARY_TRUSTED_KEYRING /boot/config-4.19.0-5-amd64
CONFIG_SECONDARY_TRUSTED_KEYRING=y


Could you please also set this configuration value in this version?

Thank you very much.
Best regards,
Sven

-- Package-specific info:
** Version:
Linux version 5.2.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 
(Debian 8.3.0-21)) #1 SMP Debian 5.2.9-2 (2019-08-21)

** Command line:
resume=/dev/mapper/casaubon--vg-swap_1 root=/dev/mapper/casaubon--vg-root ro 
splash quiet loglevel=3 add_efi_memmap biosdevname=0 cgroup_enable=memory 
drm.vblankoffdelay=1 elevator=noop i915.enable_dc=2 i915.enable_fbc=1 
i915.fastboot=1 net.ifnames=0 rd.systemd.show_status=auto 
rd.udev.log_priority=3 swapaccount=1 vga=current vt.global_cursor_default=0 


** Tainted: U (64)
 * Userspace-defined naughtiness.

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: Dell Inc.
product_name: Latitude 7480
product_version: 
chassis_vendor: Dell Inc.
chassis_version: 
bios_vendor: Dell Inc.
bios_version: 1.6.5
board_vendor: Dell Inc.
board_name: 00F6D3
board_version: A00

** Loaded modules:
sha512_ssse3
sha512_generic
ipheth
xt_TPROXY
nf_tproxy_ipv6
nf_tproxy_ipv4
xt_tcpudp
xt_socket
nf_socket_ipv4
nf_socket_ipv6
nf_defrag_ipv6
nf_defrag_ipv4
xt_mark
nft_compat
nft_counter
nf_tables
nfnetlink
bnep
cdc_ether
usbnet
r8152
mii
snd_usb_audio
snd_usbmidi_lib
snd_rawmidi
snd_seq_device
uvcvideo
videobuf2_vmalloc
videobuf2_memops
videobuf2_v4l2
videobuf2_common
videodev
media
zram
zsmalloc
btusb
btrtl
btbcm
btintel
bluetooth
drbg
ansi_cprng
binfmt_misc
ecdh_generic
ecc
nls_ascii
nls_cp437
vfat
fat
arc4
snd_hda_codec_hdmi
snd_soc_skl
snd_soc_skl_ipc
snd_soc_sst_ipc
snd_soc_sst_dsp
snd_hda_ext_core
intel_rapl
snd_soc_acpi_intel_match
snd_hda_codec_realtek
snd_soc_acpi
snd_hda_codec_generic
snd_soc_core
iwlmvm
x86_pkg_temp_thermal
intel_powerclamp
dell_rbtn
snd_compress
mac80211
coretemp
kvm_intel
snd_hda_intel
dell_laptop
snd_hda_codec
mei_wdt
ledtrig_audio
kvm
watchdog
irqbypass
iwlwifi
snd_hda_core
dell_smm_hwmon
snd_hwdep
intel_cstate
efi_pstore
snd_pcm
intel_uncore
dell_wmi
snd_timer
dell_smbios
dcdbas
serio_raw
intel_wmi_thunderbolt
efivars
intel_rapl_perf
cfg80211
wmi_bmof
dell_wmi_descriptor
snd
soundcore
rtsx_pci_ms
rfkill
joydev
memstick
sg
mei_me
intel_pch_thermal
mei
idma64
processor_thermal_device
intel_soc_dts_iosf
battery
pcc_cpufreq
ac
intel_hid
acpi_pad
sparse_keymap
evdev
int3403_thermal
int340x_thermal_zone
int3400_thermal
acpi_thermal_rel
parport_pc
ppdev
lp
parport
efivarfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
dm_crypt
dm_mod
hid_lenovo
usbhid
hid_alps
hid_generic
sd_mod
crct10dif_pclmul
crc32_pclmul
crc32c_intel
ghash_clmulni_intel
i2c_designware_platform
i2c_designware_core
i915
rtsx_pci_sdmmc
mmc_core
aesni_intel
i2c_algo_bit
aes_x86_64
e1000e
ahci
crypto_simd
cryptd
glue_helper
libahci
drm_kms_helper
libata
ptp
pps_core
rtsx_pci
xhci_pci
drm
scsi_mod
xhci_hcd
i2c_i801
usbcore
intel_lpss_pci
i2c_hid
hid
usb_common
wmi
intel_lpss_acpi
video
intel_lpss
mfd_core
button

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th 
Gen Core Processor Host Bridge/DRAM Registers [8086:1904] (rev 08)
Subsystem: Dell Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host 
Bridge/DRAM Registers [1028:07a0]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: skl_uncore

00:02.0 VGA compatible controller [0300]: Intel Corporation Skylake GT2 [HD 
Graphics 520] [8086:1916] (rev 07) (prog-if 00 [VGA controller])

Bug#668523: sysvinit: Returning from single user leaves current tty disfunctional

2019-09-13 Thread Jesse Smith

I have tried to duplicate this issue with Debian 9 and have been unable
to duplicate the tty issue. Seems this was fixed in a release since the
report. Unless someone can duplicate this issue with a current version
of Debian/init, I suggest this report can be closed.

- Jesse

Bug#940141: RM: ofono-phonesim -- RoQA; Depends on qt4, dead upstream

2019-09-13 Thread Héctor Orón Martínez

Hello,

  Yes, please, remove the package.

Missatge de Moritz Muehlenhoff  del dia dj., 12 de
set. 2019 a les 23:57:
>
> Package: ftp.debian.org
> Severity: normal
>
> Please remove ofono-phonesim. It depends on Qt4 and is dead upstream
> zumbi acked the removal in #875066
>
> Cheers,
> Moritz



-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

Bug#940182: convert dssi-dev to Architecture: any

2019-09-13 Thread Helmut Grohne

Package: dssi-dev
Version: 1.1.1~dfsg0-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:amsynth src:csound src:fluidsynth-dssi src:ghostess 
src:gsequencer src:hexter src:muse src:naspro-bridges src:nekobee 
src:ocaml-dssi src:qtractor src:rosegarden src:whysynth src:wsynth-dssi 
src:xsynth-dssi src:yoshimi src:zynaddsubfx

The affected packages fail to satisfy their cross Build-Depends, because
their dependency on dssi-dev is unsatisfiably. In general, Architecture:
all packages can never satisfy cross build dependencies unless marked
Multi-Arch: foreign or annotated :native. In this case, both would be
wrong, because dssi-dev architecture-specific interfaces of its own
dependencies (e.g. libasound2-dev). This is known as the "multiarch
interpreter problem" and the canonical workaround is converting the
package to Architecture: any. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru dssi-1.1.1~dfsg0/debian/changelog 
dssi-1.1.1~dfsg0/debian/changelog
--- dssi-1.1.1~dfsg0/debian/changelog   2019-08-25 13:02:39.0 +0200
+++ dssi-1.1.1~dfsg0/debian/changelog   2019-09-13 06:42:46.0 +0200
@@ -1,3 +1,10 @@
+dssi (1.1.1~dfsg0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Convert dssi-dev to Architecture: any. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 13 Sep 2019 06:42:46 +0200
+
 dssi (1.1.1~dfsg0-2) unstable; urgency=medium
 
   [ Stuart Prescott ]
diff --minimal -Nru dssi-1.1.1~dfsg0/debian/control 
dssi-1.1.1~dfsg0/debian/control
--- dssi-1.1.1~dfsg0/debian/control 2019-08-25 13:02:39.0 +0200
+++ dssi-1.1.1~dfsg0/debian/control 2019-09-13 06:41:09.0 +0200
@@ -23,7 +23,7 @@
 Vcs-Browser: https://salsa.debian.org/multimedia-team/dssi
 
 Package: dssi-dev
-Architecture: all
+Architecture: any
 Depends: ladspa-sdk,
  libasound2-dev | libdssialsacompat-dev,
  pkg-config,
diff --minimal -Nru dssi-1.1.1~dfsg0/debian/dssi-dev.install 
dssi-1.1.1~dfsg0/debian/dssi-dev.install
--- dssi-1.1.1~dfsg0/debian/dssi-dev.install2019-08-25 13:02:39.0 
+0200
+++ dssi-1.1.1~dfsg0/debian/dssi-dev.install2019-09-13 06:41:51.0 
+0200
@@ -1,2 +1,2 @@
 usr/include/
-usr/lib/*/pkgconfig/*   usr/share/pkgconfig
+usr/lib/*/pkgconfig/*

Bug#940183: debootstrap: Cannot deboostrap an i386/amd64 foreign system from a ppc64le host

2019-09-13 Thread Niccolò Belli

Package: debootstrap
Version: 1.0.115
Severity: normal

sudo qemu-debootstrap --variant=minbase --arch amd64 buster
~/buster-chroot-amd64

I: Extracting zlib1g...
I: Running command: chroot /home/niko/buster-chroot-amd64
/debootstrap/debootstrap --second-stage
/usr/bin/apt-config: error while loading shared libraries: libz.so.1: failed to
map segment from shared object
/usr/bin/id: error while loading shared libraries: libselinux.so.1: failed to
map segment from shared object
/debootstrap/debootstrap: 567: [: Illegal number:
/usr/bin/mkdir: error while loading shared libraries: libselinux.so.1: failed
to map segment from shared object
/usr/bin/mknod: error while loading shared libraries: libselinux.so.1: failed
to map segment from shared object
E: Cannot install into target '/' mounted with noexec or nodev

I'm running Fedora 30 ppc64le on a Raptor Blackbird (Power 9) workstation and I
would like to debootstrap an amd64 Debian Buster.

I tried with Stretch, Buster, Ubuntu... no luck.

Fedora ships with deboostrap 1.0.109 and qemu 3.1.1, but I upgraded them to
1.0.115 and 4.1.0.
After the upgrade I managed to debootstrap Stretch, but ONLY with
--variant=minbase.
Still no luck with other targets.

Other errors I got while trying different targets/deboostrap versions:

stretch i386/amd64

I: Configuring libc-bin...
I: Unpacking the base system...
W: Failure trying to run: dpkg --force-overwrite --force-confold
--skip-same-version --install /var/cache/apt/archives/adduser_3.115_all.deb
/var/cache/apt/>
W: See //debootstrap/debootstrap.log for details (possibly the package systemd
is at fault)

/debootstrap/debootstrap.log:

Initializing machine ID from random generator.
Adding group `systemd-journal' (GID 101) ...
Done.
adduser: `/usr/bin/chfn -f systemd Time Synchronization systemd-timesync'
exited from signal 132. Exiting.
dpkg: error processing package systemd (--install):
subprocess installed post-installation script returned error exit status 1
Processing triggers for libc-bin (2.24-11+deb9u4) ...
Errors were encountered while processing:
systemd

buster i386/amd64

I: Extracting zlib1g...
I: Running command: chroot /home/niko/bionic-chroot-amd64
/debootstrap/debootstrap --second-stage
W: Failure trying to run: /sbin/ldconfig
W: See //debootstrap/debootstrap.log for details

2019-09-13 08:47:40
URL:http://cdn-fastly.deb.debian.org/debian/pool/main/z/zlib/zlib1g_1.2.11.dfsg-1_i386.deb
[95732/95732] -> "/home/niko/bionic-chroot-amd>
Segmentation fault (core dumped)

-- System Information:
Fedora 30 ppc64le with debootstrap 1.0.115 and qemu 4.1.0

Bug#935290: moar digging

2019-09-13 Thread M. Zhou

Hi Dominique,

Will do it later. BTW, the *.moarvm not found error is related to this:
https://github.com/rakudo/rakudo/issues/3093

We can temporarily symlink several directories to wordaround this.


On Fri, 13 Sep 2019 at 12:24, Dominique Dumont  wrote:
>
> On Thursday, 12 September 2019 08:33:00 CEST Niels Thykier wrote:
> > Does rakudo build with "Rules-Requires-Root: no"[1]?  If it does, then
> > you can work around the bug / issue in fakeroot for sid, testing and
> > stable for now by using it.
>
> Yes ! I can now build rakudo on my laptop. Thanks for the help :-)
>
> Mo Zhou, can you follow-up and, if possible, release rakudo on unstable ?
>
> All the best
>
>
>
>


-- 
Best,

Bug#940184: RM: python-enthoughtbase -- RoM; dead upstream; ancient; no Python 3 support and no reverse deps

2019-09-13 Thread Andrey Rahmatullin

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

https://pypi.org/project/EnthoughtBase/ is dead and I cannot find the new
source. The current upstream source was uploaded to Debian in 2011.

Popcon is 203, not sure why. It has only a reverse build-dep in stable and
oldstable, not reverse deps there.

Reverse deps checked with dak rm -Rnb python-enthoughtbase

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#924716: cron: diff for NMU version 3.0pl1-134.1

2019-09-13 Thread Laurent Bigonville

Control: tags 924716 + pending


Dear maintainer,

I've prepared an NMU for cron (versioned as 3.0pl1-134.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.

diff -u cron-3.0pl1/debian/changelog cron-3.0pl1/debian/changelog
--- cron-3.0pl1/debian/changelog
+++ cron-3.0pl1/debian/changelog
@@ -1,3 +1,10 @@
+cron (3.0pl1-134.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Stop using obsolete SELinux API (Closes: #924716)
+
+ -- Laurent Bigonville   Fri, 13 Sep 2019 16:27:42 +0200
+
 cron (3.0pl1-134) unstable; urgency=medium
 
   * Increase maximum crontab length to 10,000 lines.
diff -u cron-3.0pl1/user.c cron-3.0pl1/user.c
--- cron-3.0pl1/user.c
+++ cron-3.0pl1/user.c
@@ -31,8 +31,6 @@
 #ifdef WITH_SELINUX
 #include 
 #include 
-#include 
-#include 
 #include 
 
 static int get_security_context(char *name, int crontab_fd, security_context_t
@@ -108,13 +106,35 @@
* permission check for this purpose.
*/
 
+   security_class_t tclass = string_to_security_class("file");
+   if (!tclass) {
+   log_it(name, getpid(), "Failed to translate security class 
file", tabname);
+   freeconary(context_list);
+   if (security_deny_unknown() == 0) {
+   return 0;
+   } else {
+   return -1;
+   }
+   }
+
+   access_vector_t bit = string_to_av_perm(tclass, "entrypoint");
+   if (!bit) {
+   log_it(name, getpid(), "Failed to translate av perm 
entrypoint", tabname);
+   freeconary(context_list);
+   if (security_deny_unknown() == 0) {
+   return 0;
+   } else {
+   return -1;
+   }
+   }
+
for (i = 0; i < list_count; i++) {
retval = security_compute_av(context_list[i],
 file_context,
-SECCLASS_FILE,
-FILE__ENTRYPOINT,
+tclass,
+bit,
 &avd);
-   if (!retval && ((FILE__ENTRYPOINT & avd.allowed) == 
FILE__ENTRYPOINT)) {
+   if(!retval && ((bit & avd.allowed) == bit)) {
*rcontext = strdup(context_list[i]);
freecon(file_context);
freeconary(context_list);

Bug#935073: Some PyQt4 code is remaining, not every file is ported to Python3, test suite errors (Was: Bug#935073: RM: epigrass -- RoQA; Obsolete libs - Qt4 and Python2)