Bug#956671: htcondor: preemption not working if NEGOTIATOR_INTERVAL is set

[Henning]

Package: htcondor
Version: 8.8.7-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
We are configuring preemption settings. Running jobs wich reached the
guaranteed minimum run time should be preempted if jobs with a priority
1.2 times better are in the idle queue.
Here is the NEGOTIATOR configuration:

use ROLE : CENTRALMANAGER
NEGOTIATOR_INTERVAL = 3600
JobExceedsMinRunTime= ($(ActivationTimer)) > MinRunTimeHours * 60
NewUserBetterPrio   =  RemoteUserPrio > SubmitterUserPrio * 1.2 
IsGPUJob= Target.RequestGPUs > 0 && My.RequestGPUs =!= 0 && 
My.TotalGPUs =!= 0
PREEMPTION_REQUIREMENTS = debug( ( ($(NewUserBetterPrio)) && 
($(JobExceedsMinRunTime))) || ($(IsGPUJob)))
ALLOW_PSLOT_PREEMPTION  = True
NEGOTIATOR_DEBUG = D_FULLDEBUG
NEGOTIATOR_CONSIDER_EARLY_PREEMPTION = True
NEGOTIATOR_CONSIDER_PREEMPTION = True

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Preemption works, unless we set NEGOTIATOR_INTERVALL.
   * What was the outcome of this action?
Jobs have not been preempted anymore.
   * What outcome did you expect instead?
We would expect that preemption is working, regardless whether
NEGOTIATOR_INTERVALL is beeing used or not.


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

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

Versions of packages htcondor depends on:
ii  adduser   3.118
ii  debconf [debconf-2.0] 1.5.71
ii  libboost-python1.67.0 1.67.0-13+deb10u1
ii  libc6 2.28-10
ii  libcgroup10.41-8.1
ii  libclassad10  8.8.7-1
ii  libcom-err2   1.44.5-1+deb10u3
ii  libcurl4  7.64.0-4+deb10u1
ii  libdate-manip-perl6.76-1
ii  libexpat1 2.2.6-2+deb10u1
ii  libgcc1   1:8.3.0-6
ii  libglobus-callout04.1-1
ii  libglobus-common0 18.2-1
ii  libglobus-ftp-client2 9.2-1
ii  libglobus-gass-transfer2  9.1-1
ii  libglobus-gram-client314.2-1
ii  libglobus-gram-protocol3  13.2-1
ii  libglobus-gsi-callback0   6.1-1
ii  libglobus-gsi-cert-utils0 10.2-1
ii  libglobus-gsi-credential1 8.1-1
ii  libglobus-gsi-openssl-error0  4.1-1
ii  libglobus-gsi-proxy-core0 9.2-1
ii  libglobus-gsi-proxy-ssl1  6.1-1
ii  libglobus-gsi-sysconfig1  9.2-1
ii  libglobus-gss-assist3 12.2-1
ii  libglobus-gssapi-error2   6.1-1
ii  libglobus-gssapi-gsi4 14.10-1
ii  libglobus-io3 12.1-1
ii  libglobus-openssl-module0 5.1-1
ii  libglobus-rsl211.1-1
ii  libglobus-xio06.1-1
ii  libgomp1  8.3.0-6
ii  libgssapi-krb5-2  1.17-3
ii  libk5crypto3  1.17-3
ii  libkrb5-3 1.17-3
ii  libkrb5support0   1.17-3
ii  libldap-2.4-2 2.4.47+dfsg-3+deb10u1
ii  libltdl7  2.4.6-9
ii  libmunge2 0.5.13-2
ii  libpcre3  2:8.39-12
ii  libpython2.7  2.7.16-2+deb10u1
ii  libpython3.7  3.7.3-2+deb10u1
ii  libsqlite3-0  3.27.2-3
ii  libssl1.1 1.1.1d-0+deb10u2
ii  libstdc++68.3.0-6
ii  libuuid1  2.33.1-0.1
ii  libvirt0  5.0.0-4+deb10u1
ii  libx11-6  2:1.6.7-1
ii  libxext6  2:1.3.3-1+b2
ii  libxss1   1:1.2.3-1
ii  lsb-base  10.2019051400
ii  perl  5.28.1-6
ii  python2.7.16-1
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages htcondor recommends:
pn  ecryptfs-utils  

Versions of packages htcondor suggests:
pn  coop-computing-tools   
pn  docker.io  
pn  singularity-container  
pn  slurm-client   

-- Configuration Files:
/etc/condor/condor_config changed:
RELEASE_DIR = /usr
LOCAL_DIR = /local/condor
LOCAL_CONFIG_FILE = /etc/condor/condor_config.local
REQUIRE_LOCAL_CONFIG_FILE = false
LOCAL_CONFIG_DIR = /etc/condor/config.d
LOCAL_CONFIG_DIR_EXCLUDE_REGEXP = 
^((\..*)|(.*~)|(#.*)|(.*\.rpmsave)|(.*\.rpmnew))$
use SECURITY : HOST_BASED
ALLOW_WRITE = 10.0.0.0/9
RUN = /run/condor
LOG = /var/log/condor
LOCK= /run/lock/condor
SPOOL   = $(LOCAL_DIR)/spool
EXECUTE = $(LOCAL_DIR)/execute
BIN = $(RELEASE_DIR)/bin
LIB = $(RELEASE_DIR)/lib/condor
INCLUDE = $(RELEASE_DIR)/include/condor
SBIN= $(RELEASE_DIR)/sbin
LIBEXEC = $(RELEASE_DIR)/lib/condor/libexec
SHARE   = $(R

Bug#956672: rtkit activation fails, because service unit is installed at the wrong place

[Gábor Gombás]

Package: rtkit
Version: 0.13-2
Severity: important

Hi,

syslog is full with:

Apr 14 08:42:53 host dbus-daemon[940]: [system] Activating via systemd: service 
name='org.freedesktop.RealtimeKit1' unit='rtkit-daemon.service' requested by 
':1.158' (uid=1000 pid=156197 comm="/usr/lib/firefox/firefox -contentproc 
-childID 6 -")
Apr 14 08:42:53 host dbus-daemon[940]: [system] Activation via systemd failed 
for unit 'rtkit-daemon.service': Unit rtkit-daemon.service not found.

... and the reason is:

# dpkg -L rtkit | grep rtkit-daemon.service
/usr/lib/x86_64-linux-gnu/systemd/system/rtkit-daemon.service

The unit file should be under /usr/lib/systemd/system.

Regards,
Gabor

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

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

Versions of packages rtkit depends on:
ii  adduser  3.118
ii  dbus 1.12.16-2
ii  libc62.30-4
ii  libcap2  1:2.33-1
ii  libdbus-1-3  1.12.16-2
ii  libsystemd0  245.4-3
ii  policykit-1  0.105-26

rtkit recommends no packages.

rtkit suggests no packages.

-- no debconf information

Bug#796597: disorderfs: Breaks if ROOTDIR & MOUNTPOINT are relative directories

[Chris Lamb]

forwarded 796597 
https://salsa.debian.org/reproducible-builds/disorderfs/-/issues/5
thanks

I've forwarded this to Salsa/upstream here:

  https://salsa.debian.org/reproducible-builds/disorderfs/-/issues/5


Regards,

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

Bug#844518: disorderfs: does not parallelise very well

[Chris Lamb]

forwarded 844518 
https://salsa.debian.org/reproducible-builds/disorderfs/-/issues/4
thanks

I've forwarded this to Salsa/upstream here:

  https://salsa.debian.org/reproducible-builds/disorderfs/-/issues/4


Regards,

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

Bug#754711: Bug seems solved.

[Enrico Rivarola]

Thanks for investigating.
For the current version in my system (0.52-3+b10 in Debian Buster) the problem
seem fixed.
No error reported.
Thanks

Enrico

On Mon, 13 Apr 2020 18:09:39 +0200 Marcos Fouces  
wrote:
> Hello
> 
> I cannot test this o-o-stable kernel, but searching this particular
> chunk i found that this test is no more performed this way but:
> 
>  KALLSYMS="/proc/kallsyms"
>  [ -f /proc/ksysm ] && KALLSYMS="/proc/$KALLSYMS"
> 
> So kernel release is no more relevant.
> 
> I believe that this bug is fixed.
> 
> Could you confirm my findings?
> 
> Greetings,
> Marcos
> 
> 
> 
> 

Bug#844524: disorderfs: rewinddir doesn't work, causing glibc tests to fail under disorderfs

[Chris Lamb]

forwarded 844524 
https://salsa.debian.org/reproducible-builds/disorderfs/-/issues/3
thanks

I've forwarded this to Salsa/upstream here:

  https://salsa.debian.org/reproducible-builds/disorderfs/-/issues/3


Regards,

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

Bug#844498: disorderfs: using it for building kills the host (with a 686 kernel)

[Chris Lamb]

forwarded 844498 
https://salsa.debian.org/reproducible-builds/disorderfs/-/issues/2
thanks

I've forwarded this to Salsa/upstream here:

  https://salsa.debian.org/reproducible-builds/disorderfs/-/issues/2


Regards,

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

Bug#750629: wrong mail options in /etc/chkrootkit.conf

[Enrico Rivarola]

Ok,
thanks.

Enrico

On Mon, 13 Apr 2020 17:36:26 +0200 Marcos Fouces  
wrote:
> Hello Enrico
> 
> In fact, you have to escape quotas in the argments you supply to the
> RUN_DAILY_OPTS variable.
> 
> It should be posible to insert needed escape characters in debconf (i
> suppose that you configured it that way) but i suggest that let cron
> daemon send the mail for you.
> 
> IMHO, this is not a bug.
> 
> Greetings, 
> Marcos
> 
> 
> 

Bug#956665: libdrm2: Update broke firefox WebGL

[Timo Aaltonen]

On 14.4.2020 8.03, Fabian Inostroza wrote:
> Package: libdrm2
> Version: 2.4.101-1
> Severity: normal
> 
> Dear Maintainer,
> 
> After updating libdrm2 from 2.4.100-4 to 2.4.101-1 WebGL stopped working on
> firefox (using esr from repos and tar from mozilla).
> 
> After loading a WebGL sample from webglsamples.org the following is message is
> shown in the web console:
> Error: WebGL warning: : Failed to create WebGL context: WebGL 
> creation failed: 
> * tryNativeGL
> * Exhausted GL driver options.
> 
> and in the terminal where firefox was launched:
> libGL error: MESA-LOADER: failed to retrieve device information
> libGL error: Version 4 or later of flush extension not found
> libGL error: failed to load driver: i915
> libGL error: MESA-LOADER: failed to retrieve device information

Probably the same as this upstream bug

https://gitlab.freedesktop.org/mesa/drm/-/issues/39

could you test this patch if it helps:

https://716574.bugs.gentoo.org/attachment.cgi?id=632372


-- 
t

Bug#433568: VLAN support within D-I

[Carsten Schoenert]

Hi there,

it's long ago this issue was opened and some working code was added by
patches. :-)

On Mon, Jun 27, 2016 at 02:13:33PM +, Holger Levsen wrote:
> the server is located in a loud+dusty+dark room, has 4 ethernet devices
> and it seems I mixed them up…

On my day job we now hit exactly this situation for some months now. Our
network infrastructure got renewed and mostly all physical ports now
have VLANs tagged only.

I remembered this report and extracted the patches and information
around, put it all together on top of the Git tree for the installer and
build various variants based on the master tree for the d-i but also for
the tree of buster. We were able to configure the network setup within
the d-i to recognize the VLAN ID and proceeded successfully further with
the installation of servers.

Technically it is working, as pointed out within this report some issues
regarding debconf are still needed to work on.

I attach the current WIP of my patch work here. I reworked the source a
little bit to follow the existing coding style for the new files and
routines. But there is nothing technically changed in the new source
files.

I'd appreciate if we could get one step closer to include VLAN support
for the D-I as possible release goal for bulleseye. If possible I work
on further needed adjustments.

Thanks and Regards
Carsten
>From e3a3735d2b8006a9bc91a38a3b2de337fd1fa716 Mon Sep 17 00:00:00 2001
From: Dimitri John Ledkov 
Date: Fri, 10 Jan 2020 22:31:43 +0100
Subject: [PATCH] Add vlan support

Based on YunQiang Su patch and Philipp Kern's rewrite, with own
additions.

Closes: #433568
---
 Makefile   |   2 +-
 debian/netcfg-common.templates |  29 +-
 dhcp.c |   2 +-
 netcfg-common.c|  32 ++-
 netcfg.c   |  20 +--
 netcfg.h   |  11 
 nm-conf.c  |  35 +++-
 nm-conf.h  |  10 +++-
 static.c   |  12 ++--
 vlan.c | 101 +
 wireless.c |   4 +-
 write_interface.c  |  18 +-
 12 files changed, 252 insertions(+), 24 deletions(-)
 create mode 100644 vlan.c

diff --git a/Makefile b/Makefile
index a15d476f..03343c94 100644
--- a/Makefile
+++ b/Makefile
@@ -7,7 +7,7 @@ TARGETS		?= netcfg-static netcfg
 
 LDOPTS		= -ldebconfclient -ldebian-installer
 CFLAGS		= -W -Wall -Werror -DNDEBUG -DNETCFG_VERSION="\"$(NETCFG_VERSION)\"" -I.
-COMMON_OBJS	= netcfg-common.o wireless.o write_interface.o ipv6.o
+COMMON_OBJS	= netcfg-common.o wireless.o write_interface.o ipv6.o vlan.o
 NETCFG_O   	= netcfg.o dhcp.o static.o ethtool-lite.o wpa.o wpa_ctrl.o rdnssd.o autoconfig.o
 NETCFG_STATIC_O	= netcfg-static.o static.o ethtool-lite.o
 
diff --git a/debian/netcfg-common.templates b/debian/netcfg-common.templates
index 7cba22ec..4df1d1c7 100644
--- a/debian/netcfg-common.templates
+++ b/debian/netcfg-common.templates
@@ -26,6 +26,34 @@ _Description: Domain name:
  If you are setting up a home network, you can make something up, but make
  sure you use the same domain name on all your computers.
 
+Template: netcfg/use_vlan
+Type: boolean
+Default: false
+# :sl6:
+_Description: Are you connected to an IEEE 802.1Q VLAN trunk port?
+ Virtual LAN (VLAN) is a concept of partitioning a physical network to create
+ distinct broadcast domains. Packets can be marked for different IDs by
+ tagging, so that a single interconnect (trunk) may be used to transport
+ data for various VLANs.
+ .
+ If your network interface is directly connected to a VLAN trunk port,
+ specifying a VLAN ID may be necessary to get a working connection.
+
+Template: netcfg/vlan_id
+Type: string
+# :sl6:
+_Description: VLAN ID (1-4094):
+ If your network interface is directly connected to a VLAN trunk port,
+ specifying a VLAN ID may be necessary to get a working connection.
+
+Template: netcfg/vlan_failed
+Type: error
+# :sl6:
+_Description: Error setting up VLAN
+ The command used to set up VLAN during the installation returned an
+ error, please check installer logs, or go back and try another
+ configuration.
+
 Template: netcfg/get_nameservers
 Type: string
 # :sl1:
@@ -375,4 +403,3 @@ _Choices: ${essid_list} Enter ESSID manually
 # :sl1:
 _Description: Wireless network:
  Select the wireless network to use during the installation process.
-
diff --git a/dhcp.c b/dhcp.c
index fe069501..9476bac6 100644
--- a/dhcp.c
+++ b/dhcp.c
@@ -459,7 +459,7 @@ int netcfg_activate_dhcp (struct debconfclient *client, struct netcfg_interface
 kill_dhcp_client();
 loop_setup();
 
-interface_up(interface->name);
+netcfg_interface_up(interface);
 
 for (;;) {
 di_debug("State is now %i", state);
diff --git a/netcfg-common.c b/netcfg-common.c
index c6d1d8d5..cfa96b02 100644
--- a/netcfg-common.c
+++ b/netcfg-common.c
@@ -267,7 +267,7 @@ int is_raw_80211(const char *iface

Bug#956673: geophar: FTBFS with Python 3.8 only

[Graham Inggs]

Source: geophar
Version: 18.08.6+dfsg1-1
Severity: serious
Tags: ftbfs bullseye sid

Hi Maintainer

Since Python 3.8 is now the only Python 3 interpreter, geophar FTBFS [1].

I've copied what I hope is the relevant part of the log below.

Regards
Graham


[1] 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/geophar.html


dh_auto_clean
E: Please add appropriate interpreter package to Build-Depends, see
pybuild(1) for details.this: $VAR1 = bless( {
 'builddir' => undef,
 'pydef' => '',
 'pyvers' => '',
 'parallel' => '16',
 'py3def' => '3.8',
 'cwd' => '/build/geophar-18.08.6+dfsg1',
 'py3vers' => '',
 'pypydef' => '',
 'sourcedir' => '.'
   }, 'Debian::Debhelper::Buildsystem::pybuild' );
deps: $VAR1 = [
  'python3-all',
  'python3-sympy',
  'python3-numpy',
  'python3-matplotlib',
  'python3-dbus',
  'python3-sip',
  'python3-scipy',
  'python3-pyqt5.qsci',
  'python3-pyqt5.qtsvg'
];
make[1]: *** [debian/rules:15: override_dh_auto_clean] Error 25
make[1]: Leaving directory '/build/geophar-18.08.6+dfsg1'
make: *** [debian/rules:12: clean] Error 2

Bug#956674: prooftree must build depend on coq

[Adrian Bunk]

Source: prooftree
Version: 0.13-1
Severity: serious
Tags: bullseye sid

prooftree must build depend on coq, to prevent building
on architectures where it would not be installable.

Bug#940956: closed by Jörg Frings-Fürst (reply to debian@jff.email) (Re: systemd unit description worded misleadingly)

[Marc Haber]

On Mon, Apr 13, 2020 at 04:39:07PM +, Debian Bug Tracking System wrote:
> Your proposed change may affect other tools that trigger it. 
> 
> Therefore I will not accept this change.

Just out of interest, which other tools might break on a change of a
_Description_ in a systemd unit?

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#956660: build-essential: The appropriate version gcc is not installed (and not available!)

[Matthias Klose]

Control: reassign -1 dkms

that's a bogus check by either dkms or the nvidia script.

On 4/14/20 2:33 AM, mando wrote:
> Package: build-essential
> Version: 12.8
> Severity: important
> 
> Dear Maintainer,
> 
> I use a Debian Bullseye up-to-date. I try to install the latest Nvidia driver 
> as xserver-xorg-video-{nouveau,nvidia} does not work properly by using 
> NVIDIA-Linux-x86_64-440.82.run install script available on Nvidia website. I 
> use the standard current debian kernel:
> 
>   (root@aldur) (~) # uname -a
>   Linux aldur 5.4.0-4-amd64 #1 SMP Debian 5.4.19-1 (2020-02-13) x86_64 
> GNU/Linux
>   (root@aldur) (~) # dpkg -l | grep linux-image
>   ii  linux-image-5.4.0-4-amd64 5.4.19-1  
>   amd64Linux 5.4 for 64-bit PCs (signed)
>   ii  linux-image-amd64 5.4.19-1  
>   amd64Linux for 64-bit PCs (meta-package)
> 
> I installed the packages needed to build the module:
> 
>   apt install linux-headers-$(uname -r) dkms build-essential libglvnd-dev 
> pkg-config
> 
> When running NVIDIA-Linux-x86_64-440.82.run as root, the build fails and the 
> installer suggest me to look inside 
> /var/lib/dkms/nvidia/440.82/build/make.log.
> 
>   (root@aldur) (~) # cat /var/lib/dkms/nvidia/440.82/build/make.log 
>   DKMS make.log for nvidia-440.82 for kernel 5.4.0-4-amd64 (x86_64)
>   Tue Apr 14 02:16:01 CEST 2020
>   make[1]: Entering directory '/usr/src/linux-headers-5.4.0-4-common'
>   make[2]: Entering directory '/usr/src/linux-headers-5.4.0-4-amd64'
> 
>   Compiler version check failed:
> 
>   The major and minor number of the compiler used to
>   compile the kernel:
> 
>   gcc version 9.2.1 20200203 (Debian 9.2.1-28)
> 
>   does not match the compiler used here:
> 
>   cc (Debian 9.3.0-10) 9.3.0
>   Copyright (C) 2019 Free Software Foundation, Inc.
>   This is free software; see the source for copying conditions.  There is 
> NO
>   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
> PURPOSE.
> 
> 
>   It is recommended to set the CC environment variable
>   to the compiler that was used to compile the kernel.
> 
>   The compiler version check can be disabled by setting
>   the IGNORE_CC_MISMATCH environment variable to "1".
>   However, mixing compiler versions between the kernel
>   and kernel modules can result in subtle bugs that are
>   difficult to diagnose.
> 
>   *** Failed CC version check. Bailing out! ***
> 
>   make[3]: *** [/var/lib/dkms/nvidia/440.82/build/Kbuild:191: 
> cc_version_check] Error 1
>   make[3]: *** Waiting for unfinished jobs
>   make[2]: *** [/usr/src/linux-headers-5.4.0-4-common/Makefile:1665: 
> /var/lib/dkms/nvidia/440.82/build] Error 2
>   make[2]: Leaving directory '/usr/src/linux-headers-5.4.0-4-amd64'
>   make[1]: *** [Makefile:179: sub-make] Error 2
>   make[1]: Leaving directory '/usr/src/linux-headers-5.4.0-4-common'
>   make: *** [Makefile:81: modules] Error 2
> 
> Indeed, the version of gcc mismatches:
> 
>   (root@aldur) (~) # cat /proc/version 
>   Linux version 5.4.0-4-amd64 (debian-ker...@lists.debian.org) (gcc 
> version 9.2.1 20200203 (Debian 9.2.1-28)) #1 SMP Debian 5.4.19-1 (2020-02-13)
> 
>   (root@aldur) (~) # gcc --version
>   gcc (Debian 9.3.0-10) 9.3.0
>   Copyright (C) 2019 Free Software Foundation, Inc.
>   This is free software; see the source for copying conditions.  There is 
> NO
>   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
> PURPOSE.
> 
> I tried to find the debian package providing gcc-9.2 on 
> http://ftp.fr.debian.org/debian/pool/main/g/gcc-9/ ... without success
> Could you please either provide the appropriate compiler or provide a version 
> of linux-image using the current version of gcc-9 ?
> 
> Thanks !
> Best regards
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores)
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= 
> (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages build-essential depends on:
> ii  dpkg-dev  1.19.7
> ii  g++   4:9.2.1-3.1
> ii  gcc   4:9.2.1-3.1
> ii  libc6-dev [libc-dev]  2.30-4
> ii  make  4.2.1-1.2
> 
> build-essential recommends no packages.
> 
> build-essential suggests no packages.
> 
> -- no debconf information
> 

Bug#801339: fonts-texgyre: missing glyphs when viewing PDFs via poppler

[Hilmar Preuße]

Am 08.10.2015 um 20:52 teilte Jim Paris mit:

Hi Jim,

> When viewing PDFs that do not embed Helvetica, the μ (U+03BC) 
> character does not render correctly when fonts-texgyre is installed. 
> For example, this PDF: http://jim.sh/~jim/tmp/bugs/tps62120.pdf
> 
> With fonts-texgyre (20150923-1) installed, glyphs are missing:
> 
For any reason that bug was invisible to us, sorry late response.

Your example URL is invalid meanwhile: are you able to reproduce the
issue w/ latest fonts-texgyre installed? If yes, could you provide a new
example or a TeX source code?

Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#954151: Please move logbook to Debian Python Modules team (Was: src:logbook: Requires a package outside of Main)

[Andreas Tille]

Hi Agustin and Iñaki,

I wonder whether you would like to maintain the logbook package in
Debian Python Modules team (by setting the mailing list as Maintainer
and you two serve as Uploaders.)  This would possibly enhance the number
of people who are watching this package and would simplify doing a team
upload for the package.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#956675: cyvcf2: test failures on mipsel, ppc64el and s390x

[Sebastian Ramacher]

Source: cyvcf2
Version: 0.11.6-2
Severity: serious
Tags: ftbfs sid bullseye
Justification: fails to build from source (but built successfully in the past)

cyvcf2 failed to build on mipsel (where it built before), ppc64el and
s390x due to test failures. See
https://buildd.debian.org/status/fetch.php?pkg=cyvcf2&arch=mipsel&ver=0.11.6-2&stamp=1585562461&raw=0
for example

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#956676: firmware-iwlwifi: Can't get device info: No such device

[Tiago Carvalho]

Package: firmware-iwlwifi
Version: 20190114-2
Severity: normal

Dear Maintainer,

   * What led up to the situation?
   fresh install.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   downloaded and tested kernel and firwmare from backports, reinstalled
   firmware and kernel from statble buster.
   * What was the outcome of this action?
 None, same, no efect what's so ever.
   * What outcome did you expect instead?
The bluetooth interface to show up!

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

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

firmware-iwlwifi depends on no packages.

firmware-iwlwifi recommends no packages.

Versions of packages firmware-iwlwifi suggests:
ii  initramfs-tools  0.133+deb10u1

4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26) x86_64 GNU/Linux

lspci|grep -i wire
03:00.0 Network controller: Intel Corporation Wireless 7265 (rev 59)


dmesg |grep -i blue
[ 2402.044618] Bluetooth: Core ver 2.22
[ 2402.044637] Bluetooth: HCI device and connection manager initialized
[ 2402.044641] Bluetooth: HCI socket layer initialized
[ 2402.044646] Bluetooth: L2CAP socket layer initialized
[ 2402.044651] Bluetooth: SCO socket layer initialized


-- no debconf information

Bug#956677: giveback script doesn't allow to give-back packages in Maybe-* state

[Laurent Bigonville]

Package: buildd.debian.org
Severity: normal

Hello,

I'm trying to give-back a package[0] that is currently in
"Maybe-Given-back" and the script complains that "Package in state
Building, cannot give back."

I also tried an other package that is in "Maybe-Failed" and it gives the
same error.

Is that expected?

Kind regards,
Laurent Bigonville

[0] https://buildd.debian.org/status/package.php?p=libmediaart&suite=sid

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

Kernel: Linux 5.5.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#956678: xpra: package is uninstallable

[Boris Pek]

Package: xpra
Version: 3.0.8+dfsg1-1
Severity: serious

Hi,

Is Debian unstable system with all updates:

$ LC_ALL=C sudo apt install -V xpra
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 xpra : Depends: xserver-xorg-input-void but it is not installable
E: Unable to correct problems, you have held broken packages.

Let's check xserver-xorg-input-void package:
https://tracker.debian.org/pkg/xserver-xorg-input-void

It was removed from Debian:
https://bugs.debian.org/955603

Best regards,
Boris

Bug#956679: qxgedit: Error in website address in debian/control

[Torquil Macdonald Sørensen]

Package: qxgedit
Severity: minor

Please fix the website address given in debian/control. It should
not have an "i" at the end.

Best regards,
Torquil Sørensen

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

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

Versions of packages qxgedit depends on:
ii  libasound2  1.2.2-2.1
ii  libc6   2.30-4
ii  libgcc-s1   10-20200324-1
ii  libqt5core5a5.12.5+dfsg-9
ii  libqt5gui5  5.12.5+dfsg-9
ii  libqt5network5  5.12.5+dfsg-9
ii  libqt5widgets5  5.12.5+dfsg-9
ii  libstdc++6  10-20200324-1

qxgedit recommends no packages.

qxgedit suggests no packages.

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

[Miguel A. Vallejo]

Now with the arrival of kernel 5.5 to unstable the situation has worsened:

update-initramfs: Generating /boot/initrd.img-5.5.0-1-amd64
W: Possible missing firmware /lib/firmware/i915/icl_dmc_ver1_09.bin
for module i915
W: Possible missing firmware /lib/firmware/i915/tgl_dmc_ver2_04.bin
for module i915
W: Possible missing firmware /lib/firmware/i915/skl_huc_2.0.0.bin for
module i915
W: Possible missing firmware /lib/firmware/i915/bxt_huc_2.0.0.bin for
module i915
W: Possible missing firmware /lib/firmware/i915/kbl_huc_4.0.0.bin for
module i915
W: Possible missing firmware /lib/firmware/i915/glk_huc_4.0.0.bin for
module i915
W: Possible missing firmware /lib/firmware/i915/kbl_huc_4.0.0.bin for
module i915
W: Possible missing firmware /lib/firmware/i915/cml_huc_4.0.0.bin for
module i915
W: Possible missing firmware /lib/firmware/i915/cml_guc_33.0.0.bin for
module i915
W: Possible missing firmware /lib/firmware/i915/icl_huc_9.0.0.bin for
module i915
W: Possible missing firmware /lib/firmware/i915/ehl_huc_9.0.0.bin for
module i915
W: Possible missing firmware /lib/firmware/i915/ehl_guc_33.0.4.bin for
module i915
W: Possible missing firmware /lib/firmware/i915/tgl_huc_7.0.3.bin for
module i915
W: Possible missing firmware /lib/firmware/i915/tgl_guc_35.2.0.bin for
module i915

Bug#956625: texlive-luatex fails to install: running `luatex -ini -jobname=optex -progname=optex optex.ini

[Dmitry Shachnev]

Hi Norbert and Hilmar!

On Tue, Apr 14, 2020 at 07:31:08AM +0900, Norbert Preining wrote:
> > ! Font \_tenrm=ec-lmr10 not loadable: metric data not found or bad.
> > 
> > \_font
> > l.8 \_font
> > \_tenbf=ec-lmbx10  % boldface extended
> > ?
> > ! Emergency stop.
> > 
> > \_font
> > l.8 \_font
> > \_tenbf=ec-lmbx10  % boldface extended
> > !  ==> Fatal error occurred, no output PDF file produced!
> > Transcript written on optex.log.
>
> Fixed in git. Thanks for the report.

I can confirm that installing lmodern fixes it, so adding it as dependency
should help.

Thanks,

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#956655: nftables preinst / postrm depend on bash

[Arturo Borrero Gonzalez]

Control: fixed -1 0.9.1-3

On 4/14/20 12:45 AM, Etienne Champetier wrote:
> Package: nftables
> Version: 0.9.0-2
> 
> Hello,
> 
> Trying to install iptables in a container, nftables installation fails
> because preinst / postrm scripts use /bin/bash, which is not present
> in the container and not a dependency
> 

This is fixed by this patch:

https://salsa.debian.org/pkg-netfilter-team/pkg-nftables/-/commit/4f0bb1d072e62bc67b89900d43592876e2560d63

You can find the fix in nftables version 0.9.1-3 which was uploaded to Debian on
Thu, 15 Aug 2019.

Any chance you can use a newer version? For example, you have 0.9.3-2~bpo10+1 in
buster-backports.

regards

Bug#956680: xneur: Please migrate to enchant-2

[Laurent Bigonville]

Source: xneur
Version: 0.20.0-2
Severity: important
Tags: patch
Control: block 947979 by -1

Dear maintainer,

Your package is affected by an ongoing transition from enchant(1) to
enchant- 2. You may find the transition information at
https://release.debian.org/transitions/html/enchant-2.html and
https://bugs.debian.org/947979 .

Current source code in Debian does not support enchant-2 yet.

The attached patch allows the package to build with enchant-2, I didn't
test the resulting package though.

Kind regards,
Laurent Bigonville


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

Kernel: Linux 5.5.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
diff -Nru xneur-0.20.0/debian/control xneur-0.20.0/debian/control
--- xneur-0.20.0/debian/control 2018-07-19 00:38:47.0 +0200
+++ xneur-0.20.0/debian/control 2020-04-14 02:40:22.0 +0200
@@ -9,7 +9,7 @@
  libxt-dev,
  libpcre3-dev,
  pkg-config,
- libenchant-dev,
+ libenchant-2-dev,
  libgstreamer1.0-dev,
  libxosd-dev,
  libnotify-dev,
@@ -47,7 +47,7 @@
 Section: libdevel
 Depends: ${shlibs:Depends}, ${misc:Depends},
  libpcre3-dev,
- libenchant-dev,
+ libenchant-2-dev,
  libxneur (= ${binary:Version})
 Description: development files for xneur frontends and plugins.
  This package provides development files for building XNeur frontends and
diff -Nru xneur-0.20.0/debian/patches/enchant2.patch 
xneur-0.20.0/debian/patches/enchant2.patch
--- xneur-0.20.0/debian/patches/enchant2.patch  1970-01-01 01:00:00.0 
+0100
+++ xneur-0.20.0/debian/patches/enchant2.patch  2020-04-14 03:09:01.0 
+0200
@@ -0,0 +1,119 @@
+--- a/configure.ac
 b/configure.ac
+@@ -158,7 +158,7 @@ if test "x$with_spell" != "xno"; then
+ 
+   case $with_spell in
+   enchant|yes)
+-  PKG_CHECK_MODULES(ENCHANT, [enchant >= 1.0])
++  PKG_CHECK_MODULES(ENCHANT, [enchant-2 >= 1.0])
+   AC_DEFINE(WITH_ENCHANT, 1, [Define if you want enchant 
support])
+   ;;
+   aspell)
+--- a/xneur.pc
 b/xneur.pc
+@@ -6,5 +6,5 @@ includedir=${prefix}/include
+ Name: xneur
+ Description: XNeur library
+ Version: 0.20.0
+-Libs: -L${exec_prefix}/lib -lxneur  -lpcre -lenchant -lpthread -ldl
++Libs: -L${exec_prefix}/lib -lxneur  -lpcre -lenchant-2 -lpthread -ldl
+ Cflags: -I${prefix}/include
+--- a/plugins/statistic/Makefile.am
 b/plugins/statistic/Makefile.am
+@@ -7,7 +7,7 @@ pkglib_LTLIBRARIES = libxnstatistic.la
+ libxnstatistic_la_SOURCES = \
+   statistic.c
+ 
+-libxnstatistic_la_CFLAGS = -I@top_srcdir@/lib/config -I@top_srcdir@/lib/lib 
@DEFAULT_CFLAGS@
++libxnstatistic_la_CFLAGS = -I@top_srcdir@/lib/config -I@top_srcdir@/lib/lib 
@ASPELL_CFLAGS@ @ENCHANT_CFLAGS@ @DEFAULT_CFLAGS@
+ libxnstatistic_la_LDFLAGS = @X11_LIBS@
+
+ libxnstatistic_la_LIBADD = 
+--- a/lib/lib/xneur.h
 b/lib/lib/xneur.h
+@@ -29,7 +29,7 @@
+ #endif
+ 
+ #ifdef WITH_ENCHANT
+-# include 
++# include 
+ #endif
+ 
+ struct _window *main_window;
+--- a/lib/lib/xneurlib.c
 b/lib/lib/xneurlib.c
+@@ -30,7 +30,7 @@
+ #endif
+ 
+ #ifdef WITH_ENCHANT
+-# include 
++# include 
+ #endif
+ 
+ #include "xneur.h"
+--- a/lib/notify/Makefile.am
 b/lib/notify/Makefile.am
+@@ -16,7 +16,9 @@ libxnnotify_la_CFLAGS = -I@top_srcdir@/l
+   
@GSTREAMER_CFLAGS@  \
+   
@XOSD_CFLAGS@   \
+   
@LIBNOTIFY_CFLAGS@  \
+-  
@GTK_CFLAGS@
++  
@GTK_CFLAGS@\
++  
@ASPELL_CFLAGS@ \
++  
@ENCHANT_CFLAGS@
+ libxnnotify_la_LDFLAGS = -static @X11_LIBS@ @ADDITIONAL_LIBS@ \
+   @FREEALUT_LIBS@ \
+   @GSTREAMER_LIBS@\
+--- a/lib/main/Makefile.am
 b/lib/main/Makefile.am
+@@ -28,6 +28,6 @@ libxnmain_la_SOURCES =   \
+   defines.h
+ 
+ 
+-libxnmain_la_CFLAGS = -I@top_srcdir@/lib/config -I@top_srcdir@/lib/misc  
-I@top_srcdir@/lib/notify -I@top_srcdir@/lib/ai -I@top_srcdir@/lib/lib 
-I@top_srcd

Bug#954151: Please move logbook to Debian Python Modules team (Was: src:logbook: Requires a package outside of Main)

[Inaki Malerba]

El 14/4/20 a las 10:43, Andreas Tille escribió:
> Hi Agustin and Iñaki,
> 
> I wonder whether you would like to maintain the logbook package in
> Debian Python Modules team (by setting the mailing list as Maintainer
> and you two serve as Uploaders.)  This would possibly enhance the number
> of people who are watching this package and would simplify doing a team
> upload for the package.
> 
> Kind regards
> 
>   Andreas.
> 

Hi Andreas,

I'm having troubles to find time to maintain my packages lately, so I
think that's the best way to go.

I'll wait for Agustin's opinion, but it's ok for me!

Thanks!


-- 
- ina

Bug#956624: qemu: FTBFS on sparc64 due to libseccomp-dev dependency

[Michael Tokarev]

13.04.2020 20:55, Tom Turelinckx wrote:
> Source: qemu
> Severity: normal
> User: debian-sp...@lists.debian.org
> Usertags: sparc64
> 
> Hello,
> 
> Commit 63f51933 resolved bug #900055 by enabling seccomp on linux-any.
> 
> Since version 1:2.12+dfsg-2 qemu FTBFS due to this dependency, while it was 
> building successfully before:
> 
> https://buildd.debian.org/status/logs.php?pkg=qemu&arch=sparc64
> 
> Instead of enabling seccomp on linux-any, maybe it could be enabled on 
> something like this:

Well, I just followed libseccomp's d/control, which says linux-any.

I think if we need to solve this issue, we should start with libseccomp -
either fix it to build on sparc64, or adjust its Architecture field to
something like you suggested.

I don't think in general it is a good idea to fix FTBFS in other packages
by restricting optional features in other packages. I might be wrong here,
too.

Thanks,

/mjt

Bug#956681: /etc/logrotate.d/fail2ban cause logrotate failures when fail2ban isn't running.

[Sylvestre Ledru]

Hello

Thanks for your patch!

Le 14/04/2020 à 11:30, Ron Varburg a écrit :

Package: fail2ban
Version: 0.10.2-2.1
Severity: normal
Tags: patch

The following patch:
1. Prevents logrotate failures when fail2ban doesn't run for any reason.
 When fail2ban  isn't running, fail2ban-client flushlogs exits with an error
 code. I think announcing fail2ban isn't running should not be made by
 making logrotate to fail.

This should be fixed upstream in "fail2ban-client flushlogs" I think.
Could you please report an issue there?


2. Doesn't rotate empty log files.

agreed & pushed. thanks

Cheers,
Sylvestre

Bug#949712: New udeb for libacl and acl? (was Re: Bug#949712: please provide an udeb to be used by rsync-udeb)

[Guillem Jover]

On Mon, 2020-04-13 at 17:52:08 +0100, Samuel Henrique wrote:
> On Sun, 26 Jan 2020 at 17:29, Cyril Brulebois  wrote:
> > Guillem Jover  (2020-01-26):
> > > I'm also not sure whether it would make sense to add also an acl-udeb
> > > binary package, which would match for example the attr-udeb one.
> >
> > Does rsync really depend on libacl in the first place? I'm seeing
> > --disable-acl-support in its configure.ac; I haven't had to toy with
> > rsync in rescue mode just yet, so I'm not sure how imperative it would
> > be to have ACL support there…
> >
> > (I don't mind the acl udeb addition anyway, just putting some
> > ideas/options on the table.)

> My initial assumption was that having libacl-udeb wouldn't cause a
> considerable overhead, while having the benefit of shipping an
> rsync-udeb which supports the same features as the regular one (total
> size of rsync binary is around 500kb).

> I reckon Guillem mentions acl-udeb would match the already existent
> attr-udeb package, but I don't know how rsync deals with both libs and
> how they cap its features exactly, since it seems that libattr1 is
> only used in some archs (hppa, m68k, powerpcspe, sh4, sparc64). I can
> say that having support for ACLs on rsync-udeb would help in a
> scenario where the user wants to do a full copy of the files, maybe
> copying the whole system's FS with its ACLs along.

I thought having xattr and ACL support in an rsync-udeb did make sense,
because as you say, if you want to use it to initialize a filesystem
then you probably want all file attributes to be preserved as much as
possible. libattr might not be used on some arches depending on the
glibc support which has provided the syscall wrappers for some time
now.

> Guillem, please give me a heads up in case you think this is a good
> argument for providing libacl1-udeb, in such case I will stop
> investigating how to build rsync without having it symlinked to the
> lib.

Yeah, I think it does, otherwise I'd not have asked for an ack from
the d-i team. :) This is possibly slightly more overhead when the freeze
comes around, but several of the packages I maintain already ship udebs,
so this is soemthing I already need to keep in mind.

Thanks,
Guillem

Bug#956682: ITP: feedbackd -- DBus service for haptic/visual/audio feedback

[Arnaud Ferraris]

Package: wnpp
Severity: wishlist
Owner: Arnaud Ferraris 

* Package name: feedbackd
  Version : 0.0.0+git20200305
  Upstream Author : Purism SPC
* URL : https://source.puri.sm/Librem5/feedbackd
* License : GPL-3+ and LGPL-2.1+
  Programming Lang: C
  Description : DBus service for haptic/visual/audio feedback

Feedbackd is a DBus activated daemon that provides haptic/visual/audio
feedback based on events.

It is a dependency to Phosh, a Wayland shell for mobile devices,
which I also plan to package, and as such will be useful for bringing
Debian to mobile phones.

I take the responsibility for maintaining this package.

Bug#956683: override: enchant:oldlibs/optional

[Laurent Bigonville]

Package: ftp.debian.org
Severity: normal

Hello,

We are trying to remove the enchant(1) package from the archive and
trying to migrate to enchant-2 instead.

To make it clear that this is happening and avoid packages adding new
dependency on it, could it be moved to oldlibs?

Kind regards,
Laurent Bigonville

Bug#949712: New udeb for libacl and acl? (was Re: Bug#949712: please provide an udeb to be used by rsync-udeb)

[Cyril Brulebois]

Guillem Jover  (2020-04-14):
> I thought having xattr and ACL support in an rsync-udeb did make sense,
> because as you say, if you want to use it to initialize a filesystem
> then you probably want all file attributes to be preserved as much as
> possible. libattr might not be used on some arches depending on the
> glibc support which has provided the syscall wrappers for some time
> now.
> 
> > Guillem, please give me a heads up in case you think this is a good
> > argument for providing libacl1-udeb, in such case I will stop
> > investigating how to build rsync without having it symlinked to the
> > lib.
> 
> Yeah, I think it does, otherwise I'd not have asked for an ack from
> the d-i team. :) This is possibly slightly more overhead when the freeze
> comes around, but several of the packages I maintain already ship udebs,
> so this is soemthing I already need to keep in mind.
> 
> Thanks,
> Guillem

Alright, feel free to go ahead, then.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#617918: False positives in chkrootkit

[Marcos Fouces]

Hello Samuel

False positives always fall on the safe vs. sorry argument. Please,
check 
https://salsa.debian.org/pkg-security-team/chkrootkit/-/blob/debian/master/debian/README.FALSE-POSITIVES

You can always use the "-e" option or an exclude file (defined in
/etc/chkrootkit.conf) to avoid this warning.

I don't believe that is a bug and i would like to close it if you don't
have any objection.

Greetings, 
Marcos.


> 
> Hello,
> 
> Running chkrootkit with the slice package installed says TH-Sharpe is
> installed, while the slice package is simply a wml dependency.
> 
> Samuel
> 
> -- System Information:
> Debian Release: wheezy/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'),
> (1, 'experim
> ental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/2 CPU cores)
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
> 
> Versions of packages chkrootkit depends on:
> ii  binutils   2.21.0.20110302-1 The GNU assembler,
> linker and bina
> ii  cdebconf [debconf-2.0] 0.153 Debian Configuration
> Management Sy
> ii  debconf [debconf-2.0]  1.5.38Debian configuration
> management sy
> ii  libc6  2.11.2-11 Embedded GNU C Library:
> Shared lib
> ii  net-tools  1.60-23   The NET-3 networking
> toolkit
> ii  procps 1:3.2.8-10/proc file system
> utilities
> 
> chkrootkit recommends no packages.
> 
> chkrootkit suggests no packages.
> 
> -- debconf information excluded
> 
> --
> Samuel Thibault 
>  bouhouhouh, b il m'a abandonné. Tout ca parce que je regardais
> plus mon emac
> s que lui !
>  s/lui/ses messages irc/
>  -+- #ens-mim esseulé -+-
> 
> 
> 
>  
> __
> 
>Acknowledgement sent to Samuel Thibault :
>New Bug report received and forwarded. Copy sent to Giuseppe
> Iuculano
>. (Sat, 12 Mar 2011 15:27:04 GMT) (full text,
>mbox, link).
>  
> __
> 
>View this message in rfc822 format
> 
>From: ow...@bugs.debian.org (Debian Bug Tracking System)
>To: Samuel Thibault 
>Subject: Bug#617918: Acknowledgement (chkrootkit: False positive:
>slice)
>Date: Sat, 12 Mar 2011 15:27:04 +
> 
> Thank you for filing a new Bug report with Debian.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due
> course.
> 
> Your message has been sent to the package maintainer(s):
>  Giuseppe Iuculano 
> 
> If you wish to submit further information on this problem, please
> send it to 617...@bugs.debian.org.
> 
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
> 
> --
> 617918: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617918
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
> 
>  
> __
> 
>Send a report that this bug log contains spam.
>  
> __
> 
> 
> Debian bug tracking system administrator .
> Last modified: Thu Apr 9 09:12:22 2020; Machine Name: buxtehude
> Debian Bug tracking system
> Debbugs is free software and licensed under the terms of the GNU
> Public License version 2. The current version can be obtained
> from
> https://bugs.debian.org/debbugs-source/.
> Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation
> Ltd,
> 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other
> contributors.

Bug#956684: godot: icon for desktop file is missing

[Ronny Standtke]

Source: godot
Version: 3.2-stable-2
Severity: minor
Tags: patch

The icon for the desktop file is missing. The attached patch fixes this
issue.

Best regards

Ronny Standtke

diff --git a/debian/rules b/debian/rules
index fe12f0e2..706d82ca 100755
--- a/debian/rules
+++ b/debian/rules
@@ -70,6 +70,7 @@ override_dh_auto_install:
 	install -D -m 400 $(CURDIR)/bin/godot.x11.opt.$(BITS) $(CURDIR)/debian/godot3-runner/usr/bin/godot3-runner
 	install -D -m 400 $(CURDIR)/bin/godot_server.x11.opt.tools.$(BITS) $(CURDIR)/debian/godot3-server/usr/bin/godot3-server
 	install -D -m 444 $(CURDIR)/misc/dist/linux/org.godotengine.Godot.desktop  $(CURDIR)/debian/godot3/usr/share/applications/godot3.desktop
+	install -D -m 644 $(CURDIR)/icon.svg  $(CURDIR)/debian/godot3/usr/share/icons/hicolor/scalable/apps/godot.svg
 	sed -i 's/^Exec=.*/Exec=godot3 -p/' $(CURDIR)/debian/godot3/usr/share/applications/godot3.desktop
 	dh_auto_install

Bug#956577: virtualbox: Please decide whether to add C/R/P: time-daemon

[Dimitri John Ledkov]

IMHO virtualbox-guest-utils portion that does settimeofday() to host's
time should be split into a separate subpackage, and make that one
provide/conflicts/replaces time-daemon.

This way, people can use virtualbox-guest-utils always, and choose if
they want timesyncd / ntp / etc or virtualbox-guest-utils-time-daemon
to provide the time.

-- 
Regards,

Dimitri.

Bug#956685: sipxtapi: Please point VCS fields to salsa

[Tobias Frost]

Source: sipxtapi
Severity: minor

VCS fields still point to alioth, making some links non-working.

Cheers,
tobi

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

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

Bug#956687: src:sipxtapi: Please provide watch file

[Tobias Frost]

Source: sipxtapi
Severity: minor

Upstream releases on github nowerdays, please provide a watch file for it.

Thanks!

-- 
tobi

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

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

Bug#956686: sipxtapi: New upstream version 3.3.0_test18 available since one year.

[Tobias Frost]

Source: sipxtapi
Severity: wishlist

Its here:
https://github.com/sipXtapi/sipXtapi/archive/3.3.0_test18.tar.gz


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

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

Bug#956655: nftables preinst / postrm depend on bash

[Etienne Champetier]

Hi Arturo,

Le mar. 14 avr. 2020 à 05:26, Arturo Borrero Gonzalez
 a écrit :
>
> Control: fixed -1 0.9.1-3
>
> On 4/14/20 12:45 AM, Etienne Champetier wrote:
> > Package: nftables
> > Version: 0.9.0-2
> >
> > Hello,
> >
> > Trying to install iptables in a container, nftables installation fails
> > because preinst / postrm scripts use /bin/bash, which is not present
> > in the container and not a dependency
> >
>
> This is fixed by this patch:
>
> https://salsa.debian.org/pkg-netfilter-team/pkg-nftables/-/commit/4f0bb1d072e62bc67b89900d43592876e2560d63
>
> You can find the fix in nftables version 0.9.1-3 which was uploaded to Debian 
> on
> Thu, 15 Aug 2019.
>
> Any chance you can use a newer version? For example, you have 0.9.3-2~bpo10+1 
> in
> buster-backports.

Thanks for the quick response, for now I went the
'--no-install-recommends' route, but I'll use buster-backports next
time

>
> regards

Bug#956686: sipxtapi: New upstream version 3.3.0_test18 available since one year.

[Tobias Frost]

Control: Severity -1 normal

Raising severity as the one in Debian is 5 years old and upstream has fixed
several bugs and implemented new features.

Bug#956577: virtualbox: Please decide whether to add C/R/P: time-daemon

[Guillem Jover]

Hi!

On Tue, 2020-04-14 at 11:58:57 +0100, Dimitri John Ledkov wrote:
> IMHO virtualbox-guest-utils portion that does settimeofday() to host's
> time should be split into a separate subpackage, and make that one
> provide/conflicts/replaces time-daemon.

I don't think this is possible. The part that does that is VBoxService
which is a multi-service daemon that takes care of many other things.

> This way, people can use virtualbox-guest-utils always, and choose if
> they want timesyncd / ntp / etc or virtualbox-guest-utils-time-daemon
> to provide the time.

The timesync support in VBoxService can always be disabled by passing
--disable-timesync on when starting it, or from the host either
permanently or at run-time time with VBoxManage. So neither the presence
of the file on the file system nor of the process running means its is
handling time sync.

Thanks,
Guillem

Bug#956689: Please witch to enchant-2 instead of enchant(1)

[Laurent Bigonville]

Source: pluma
Version: 1.24.0-1
Severity: important
Control: block 947979 by -1

Hello,

Could you please switch from enchant(1) to the enchant-2 library?

We are trying to get rid of enchant(1) for the bullseye release

Switching the libenchant-dev BD to libenchant-2-dev should be enough.

Kind regards,
Laurent Bigonville

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

Kernel: Linux 5.5.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#955248: fdkaac: diff for NMU version 1.0.0-0.1

[Håvard Flaget Aasen]

Control: tags 955248 + patch
Control: tags 955248 + pending


Dear maintainer,
I've prepared an NMU for fdkaac (versioned as 1.0.0-0.1) and uploaded it
to mentors. Please feel free to tell me if I should delete it.

Regards,
Håvard
diff -Nru fdkaac-0.6.3/ChangeLog fdkaac-1.0.0/ChangeLog
--- fdkaac-0.6.3/ChangeLog	2016-08-26 14:45:05.0 +0200
+++ fdkaac-1.0.0/ChangeLog	2018-09-03 19:04:36.0 +0200
@@ -1,6 +1,44 @@
+2016-08-26  nu774 
+
+  * update ChangeLog [HEAD -> master]
+
+  * bump [origin/master]
+
+  * Ticket #23: quit supporting MPEG-2 AOT
+
+2016-08-25  nu774 
+
+  * fix libfdkaac encoder version check for SBR_RATIO availability
+
+  * Use our SBR signaling implementation on old libfdkaac
+
+2015-10-10  nu774 
+
+  * improve MSVC project
+
+2015-09-21  nu774 
+
+  * fix indents
+
+  * update compat layer, mainly for MSVC14 issue
+
+2015-07-22  nu774 
+
+  * add platformtoolset in vcxproj
+
+  * fix build issue on MSVC14
+
+2015-06-12  nu774 
+
+  * remove an unused variable decl
+
+  * remove an unused variable decl
+
+  * m4af: move internal struct m4af_itmf_entry_t from header
+
 2015-02-14  nu774 
 
-  * update ChangeLog [HEAD]
+  * update ChangeLog
 
   * bump version [v0.6.2]
 
@@ -10,9 +48,9 @@
 
 2014-09-13  nu774 
 
-  * update ChangeLog [origin/master]
+  * update ChangeLog
 
-  * bump version
+  * bump version [v0.6.1]
 
 2014-09-12  nu774 
 
diff -Nru fdkaac-0.6.3/configure.ac fdkaac-1.0.0/configure.ac
--- fdkaac-0.6.3/configure.ac	2016-08-26 14:45:05.0 +0200
+++ fdkaac-1.0.0/configure.ac	2018-09-03 19:04:36.0 +0200
@@ -13,7 +13,7 @@
 AM_PROG_CC_C_O
 
 AC_CHECK_HEADERS([sys/time.h])
-AC_CHECK_HEADERS([localcharset.h langinfo.h endian.h byteswap.h])
+AC_CHECK_HEADERS([libcharset.h langinfo.h endian.h byteswap.h])
 AC_CHECK_HEADERS([fdk-aac/aacenc_lib.h], ,
  AC_MSG_ERROR([libfdk-aac is required]))
 
@@ -38,6 +38,12 @@
 AM_CONDITIONAL([FDK_NO_GETOPT_LONG],[test "$ac_cv_func_getopt_long" != "yes"])
 AC_SEARCH_LIBS([aacEncOpen],[fdk-aac],[],[],[])
 
+CHARSET_LIB=
+AC_CHECK_LIB([iconv], [locale_charset],
+   [CHARSET_LIB=-liconv],
+   [AC_CHECK_LIB([charset], [locale_charset], [CHARSET_LIB=-lcharset])])
+AC_SUBST([CHARSET_LIB])
+
 AC_CANONICAL_HOST
 
 X_PLATFORM=posix
diff -Nru fdkaac-0.6.3/debian/changelog fdkaac-1.0.0/debian/changelog
--- fdkaac-0.6.3/debian/changelog	2017-01-23 01:39:23.0 +0100
+++ fdkaac-1.0.0/debian/changelog	2020-04-14 13:04:58.0 +0200
@@ -1,3 +1,10 @@
+fdkaac (1.0.0-0.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * New upstream release closes: #955248
+
+ -- Håvard Flaget Aasen   Tue, 14 Apr 2020 13:04:58 +0200
+
 fdkaac (0.6.3-1) unstable; urgency=medium
 
   * New upstream version
diff -Nru fdkaac-0.6.3/Makefile.am fdkaac-1.0.0/Makefile.am
--- fdkaac-0.6.3/Makefile.am	2016-08-26 14:45:05.0 +0200
+++ fdkaac-1.0.0/Makefile.am	2018-09-03 19:04:36.0 +0200
@@ -23,7 +23,7 @@
 dist_man_MANS = man/fdkaac.1
 
 fdkaac_LDADD = \
-@LIBICONV@ -lfdk-aac -lm
+@LIBICONV@ @CHARSET_LIB@ -lfdk-aac -lm
 
 if FDK_PLATFORM_POSIX
 fdkaac_SOURCES += \
diff -Nru fdkaac-0.6.3/MSVC/fdk-aac.vcxproj fdkaac-1.0.0/MSVC/fdk-aac.vcxproj
--- fdkaac-0.6.3/MSVC/fdk-aac.vcxproj	2016-08-26 14:45:05.0 +0200
+++ fdkaac-1.0.0/MSVC/fdk-aac.vcxproj	2018-09-03 19:04:36.0 +0200
@@ -1,4 +1,4 @@
-
+
 http://schemas.microsoft.com/developer/msbuild/2003";>
   
 
@@ -24,10 +24,13 @@
 fdk-aac
   
   
-v140_xp
-v120_xp
-v110_xp
-v100
+v141_xp
+v140_xp
+v120_xp
+v110_xp
+  
+  
+fdk-aac\$(Platform)\$(Configuration)
   
   
   
@@ -50,7 +53,7 @@
   NotUsing
   Level3
   WIN32;_LIB;%(PreprocessorDefinitions)
-  ../fdk-aac/libaacenc/include;../fdk-aac/libFDK/include;../fdk-aac/libMpegTPEnc/include;../fdk-aac/libPCMutils/include;../fdk-aac/libSBRenc/include;../fdk-aac/libSYS/include
+  ../fdk-aac/libaacenc/include;../fdk-aac/libFDK/include;../fdk-aac/libMpegTPEnc/include;../fdk-aac/libPCMutils/include;../fdk-aac/libSACenc/include;../fdk-aac/libSBRenc/include;../fdk-aac/libSYS/include
 
   
   
@@ -71,7 +74,6 @@
   
   
 
-
 
 
 
@@ -91,6 +93,7 @@
 
 
 
+
 
 
 
@@ -109,6 +112,8 @@
 
 
 
+
+
 
 
 
@@ -122,7 +127,20 @@
 
 
 
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
 
 
@@ -136,19 +154,18 @@
 
 
 
+
+
 
 
-
-
 
 
-
 
+
   
   
 
 
-
 
 
 
diff -Nru fdkaac-0.6.3/MSVC/fdkaac.vcxproj fdkaac-1.0.0/MSVC/fdkaac.vcxproj
--- fdkaac-0.6.3/MSVC/fdkaac.vcxproj	2016-08-26 14:45:05.0 +0200
+++ fdkaac-1.0.0/MSVC/fdkaac.vcxproj	2018-09-03 19:04:36.0 +0200
@@ -24,10 +24,10 @@
 fdkaac
   
   
-v140_xp
-v120_xp
-v110_xp
-v100
+v141_xp
+v140_xp
+v120_xp
+v110_xp
   
   
 

Bug#956688: RFS: fdkaac/1.0.0-0.1 [NMU, RC] -- command line encoder frontend for libfdk-aac

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: fdkaac
   Version : 1.0.0-0.1
   Upstream Author : nu774 
 * URL : https://github.com/nu774/fdkaac
 * License : Zlib
 * Vcs : https://git.ieval.ro/?p=fdkaac.git
   Section : sound

It builds those binary packages:

  fdkaac - command line encoder frontend for libfdk-aac

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/contrib/f/fdkaac/fdkaac_1.0.0-0.1.dsc

Changes since the last upload:

   * Non-maintainer upload
   * New upstream release closes: #955248

Regards,
Håvard

Bug#883308: libseccomp2 is missing ia64 support

[Gregor Riepl]

> > libseccomp2 is missing ia64 support.  it would be awfully nice if it was 
> > added.
> > (I hope to add it myself at some point, and this seems like a good place 
> > for a reminder.)
> 
> Going through upstream would be the best way to get this added. Having
> said that, it looks like the ia64 kernel does not select
> HAVE_ARCH_SECCOMP_FILTER anyway. It seems a bit pointless trying to add
> support for ia64 in libseccomp without having any kernel support first.

This bug also affects alpha, sparc64, sh4 and m68k.

At least on sparc64 and sh4 we have SECCOMP support in kernel, but not
HAVE_ARCH_SECCOMP_FILTER. Does libseccomp need HAVE_ARCH_SECCOMP_FILTER?

Anyway, I forwarded the bug to upstream. Let's see what can be done for
those missing archs.

Bug#956669: RM: rheolef [mips mips64el] -- RoQA; build-deps not available

[Juhani Numminen]

Control: retitle -1 RM: rheolef [mipsel mips64el] -- RoQA; build-deps not 
available

Juhani Numminen kirjoitti 14.4.2020 klo 9.48:
> Package: ftp.debian.org
> Severity: normal
> X-debbugs-cc: debian-science-maintain...@lists.alioth.debian.org
> 
> This removal would allow rheolef to migrate to testing. rheolef/7.1-1
> build-depends on paraview which is not available on mips and mips64el.

I should have written mipsel, not mips.

Bug#956691: Please witch to enchant-2 instead of enchant(1)

[Laurent Bigonville]

Source: psi
Version: 1.3-5
Severity: important
Control: block 947979 by -1

Hello,

Could you please switch from enchant(1) to the enchant-2 library?

We are trying to get rid of enchant(1) for the bullseye release.

I see some support for enchant2, but switching the build-dependency to
libenchant-2-dev is not enough as the "debian-changes" is reverting
changing the pkg-config file from enchant-2 to enchant.

Could you please drop that change and switch the build-dependency?

Kind regards,
Laurent Bigonville

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

Kernel: Linux 5.5.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#956692: fparser: depends on python3.7

[Graham Inggs]

Source: fparser
Version: 0.0.10-2
Severity: serious
Tags: bullseye sid

The binary package python3-fparser has a dependency on python3.7 [1].
Since this is an arch:all package, it cannot be binNMU'd.
Please make a source-only upload so that it picks up a dependency on
python3.8 instead.

Regards
Graham


[1] https://packages.debian.org/unstable/python3-fparser

Bug#956624: qemu: FTBFS on sparc64 due to libseccomp-dev dependency

[Gregor Riepl]

> Commit 63f51933 resolved bug #900055 by enabling seccomp on linux-any.
> 
> Since version 1:2.12+dfsg-2 qemu FTBFS due to this dependency, while it was 
> building successfully before:
> 
> https://buildd.debian.org/status/logs.php?pkg=qemu&arch=sparc64
> 
> Instead of enabling seccomp on linux-any, maybe it could be enabled on 
> something like this:
> 
> [!alpha !ia64 !m68k !sh4 !sparc64 !hurd-any !kfreebsd-any]

Tracing this a bit

It looks the kernel supports SECCOMP for sparc and sh, but these archs
lack HAVE_ARCH_SECCOMP_FILTER. SECCOMP is completely missing on alpha,
ia64 and m68k.

I'm not sure why libseccomp is missing support for these two
architectures, does it depend on HAVE_ARCH_SECCOMP_FILTER?

I reported the bug upstream:
https://github.com/seccomp/libseccomp/issues/231
And I also took the liberty to update the Debian bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883308

Until this gets fixed, it should be ok to exclude those archs IMHO.

Bug#956690: pympress: depends on python3.7

[Graham Inggs]

Source: pympress
Version: 1.5.1+dfsg-3
Severity: serious
Tags: bullseye sid

The binary package pympress has a dependency on python3.7 [1].
Since this is an arch:all package, it cannot be binNMU'd.
Please make a source-only upload so that it picks up a dependency on
python3.8 instead.

Regards
Graham


[1] https://packages.debian.org/unstable/pympress

Bug#956693: spyder: depends on python3.7

[Graham Inggs]

Source: spyder
Version: 3.3.6+dfsg1-4
Severity: serious
Tags: bullseye sid

The binary package spyder has a dependency on python3.7 [1].
Since this is an arch:all package, it cannot be binNMU'd.
Please make a source-only upload so that it picks up a dependency on
python3.8 instead.

Regards
Graham


[1] https://packages.debian.org/unstable/spyder

Bug#956694: sopt FTBFS with spdlog 1.5.0

[Adrian Bunk]

Source: sopt
Version: 3.0.1-10
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/sopt.html

...
cd /build/1st/sopt-3.0.1/obj-x86_64-linux-gnu/cpp/sopt && /usr/bin/c++  
-Dsopt_EXPORTS -I/build/1st/sopt-3.0.1/cpp/sopt/.. 
-I/build/1st/sopt-3.0.1/obj-x86_64-linux-gnu/include -isystem 
/usr/include/eigen3 -isystem /usr/lib/x86_64-linux-gnu/openmpi/include/openmpi 
-isystem /usr/lib/x86_64-linux-gnu/openmpi/include  -g -O2 
-ffile-prefix-map=/build/1st/sopt-3.0.1=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -std=gnu++11 -fPIC   
-fopenmp -o CMakeFiles/sopt.dir/wavelets/sara.cc.o -c 
/build/1st/sopt-3.0.1/cpp/sopt/wavelets/sara.cc
In file included from 
/build/1st/sopt-3.0.1/cpp/tests/../sopt/logging.enabled.h:5,
 from /build/1st/sopt-3.0.1/cpp/tests/../sopt/logging.h:7,
 from /build/1st/sopt-3.0.1/cpp/tests/common_catch_main.cc:7:
/usr/include/spdlog/fmt/ostr.h:17:10: fatal error: 
spdlog/fmt/bundled/ostream.h: No such file or directory
   17 | #include 
  |  ^~
compilation terminated.

Bug#956695: unrardll: needs binary upload

[Graham Inggs]

Source: unrardll
Version: 0.1.3-6
Severity: serious
Tags: ftbfs

Hi Maintainer

The package unrardll requires a binary upload since it is in contrib
and cannot be built on the buildds [1].

Please upload the binary package python3-unrardll_0.1.3-6_amd64.deb to
the archive.
There is no need for another source upload and no need to bump the version.

Regards
Graham


[1] https://buildd.debian.org/status/package.php?p=unrardll

Bug#956696: Please witch to enchant-2 instead of enchant(1)

[Laurent Bigonville]

Source: subtitleeditor
Version: 0.54.0-3
Severity: important
Tags: patch
Control: block 947979 by -1

Hello,

Could you please switch from enchant(1) to the enchant-2 library?

We are trying to get rid of enchant(1) for the bullseye release.

The attached patch should fix this, not tested though.

Kind regards,
Laurent Bigonville

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

Kernel: Linux 5.5.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
diff -Nru subtitleeditor-0.54.0/debian/control 
subtitleeditor-0.54.0/debian/control
--- subtitleeditor-0.54.0/debian/control2018-04-29 14:28:09.0 
+0200
+++ subtitleeditor-0.54.0/debian/control2020-04-14 14:09:10.0 
+0200
@@ -7,7 +7,7 @@
  imagemagick,
  intltool,
  iso-codes,
- libenchant-dev,
+ libenchant-2-dev,
  libgstreamer-plugins-base1.0-dev,
  libgstreamermm-1.0-dev (>> 1.8.0),
  libgtkmm-3.0-dev,
diff -Nru subtitleeditor-0.54.0/debian/patches/enchant2.patch 
subtitleeditor-0.54.0/debian/patches/enchant2.patch
--- subtitleeditor-0.54.0/debian/patches/enchant2.patch 1970-01-01 
01:00:00.0 +0100
+++ subtitleeditor-0.54.0/debian/patches/enchant2.patch 2020-04-14 
14:09:15.0 +0200
@@ -0,0 +1,18 @@
+Description: Switch to enchant2
+Author: Laurent Bigonville 
+
+---
+Origin: vendor
+Last-Update: 2020-04-14
+
+--- subtitleeditor-0.54.0.orig/configure.ac
 subtitleeditor-0.54.0/configure.ac
+@@ -74,7 +74,7 @@ AC_SUBST(GTKMM_LIBS)
+ # =
+ # check enchant
+ 
+-PKG_CHECK_MODULES(ENCHANT, enchant >= 1.4.0)
++PKG_CHECK_MODULES(ENCHANT, enchant-2 >= 1.4.0)
+ 
+ AC_SUBST(ENCHANT_CFLAGS)
+ AC_SUBST(ENCHANT_LIBS)
diff -Nru subtitleeditor-0.54.0/debian/patches/series 
subtitleeditor-0.54.0/debian/patches/series
--- subtitleeditor-0.54.0/debian/patches/series 2017-08-14 16:58:33.0 
+0200
+++ subtitleeditor-0.54.0/debian/patches/series 2020-04-14 14:09:15.0 
+0200
@@ -1,2 +1,3 @@
 new_appdata_format.patch
 remove_abs_sourcedir.patch
+enchant2.patch

Bug#507091: xgettext: fails to detect 'gettext -e' and 'eval_gettext -e' strings

[Bruno Haible]

I wrote:
> This is now fixed:
> https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=7643c58c13761bf0062c73d3114d4243250e8be9
> 
> The fix will be contained in the next release.

The fix is contained in gettext 0.20.2.

Bruno

Bug#956187: firejail-profiles: Updated profile for Microsoft Teams for Linux

[Patrik Flykt]

On Sun, 2020-04-12 at 16:33 +0200, Reiner Herrmann wrote:
> Control: tags -1 + fixed-upstream
> 
> Hi Patrik,
> 
> thanks for the patch.
> A little different profile for teams is already available in the
> upstream repository [1].
> It will be included in the next release/upload.

That sounds like an excellent plan.

Thanks,

Patrik

Bug#956624: qemu: FTBFS on sparc64 due to libseccomp-dev dependency

[Michael Tokarev]

13.04.2020 20:55, Tom Turelinckx wrote:

> Instead of enabling seccomp on linux-any, maybe it could be enabled on 
> something like this:
> 
> [!alpha !ia64 !m68k !sh4 !sparc64 !hurd-any !kfreebsd-any]

Uh.. :)  We use another simple "parser" for --enable-foo which
goes parallel with this Build-Depends stuff, which does not
have a notion for negation.

I have either to "fix" this "parser" to understand negation or
to list all valid combinations manually. Dunno which one is better,
I dislike both :)

But we have other package which is in somewhat similar state,
librados (ceph), which is also failing on various "non-main"
architectures, so qemu can't be built there too. Maybe it's
time to fix that for both... Oh well...

/mjt

Bug#956697: mercurial: flaky autopkgtests

[Graham Inggs]

Source: mercurial
Version: 5.3.1-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky

Hi Maintainer

Mercurial's autopkgtests are flaky [1].
I examined the logs of several failed tests and found the following:

Failed test-wireproto-exchangev2-shallow.t: output changed
occurred 8 times

Failed test-narrow-shallow.t: output changed
occurred 3 times

and

Failed test-convert-darcs.t: output changed
Failed test-manifest.t: output changed
Failed test-remotefilelog-prefetch.t: output changed
Failed test-strip.t: output changed
occurred once each.

The tests seem to be more likely to fail on the slower architectures.
In Debian, I see no failures for 5.3.1-1 on amd64, whereas in Ubuntu
there was one failure on amd64, and none on ppc64el.

Please make these tests more reliable or skip them.

Regards
Graham


[1] https://ci.debian.net/packages/m/mercurial/

Bug#956698: lintian: package-from-other-python-variant exception: python-pip-whl

[Scott Kitterman]

Package: lintian
Version: 2.65.0
Severity: normal

The package python-pip-whl is a special case of a Python package built
to work with either python or python3.  Currently python3-vertualenv
gets the following lintian warning:

W: python3-virtualenv: 
python-package-depends-on-package-from-other-python-variant Depends: 
python-pip-whl

While this is a great warning in general, in this case it's wrong.
Would it be OK to special case python-pip-whl and have it not trigger
this check?

Scott K

Bug#956552: Info received (Bug#956552: arno-iptables-firewall: 90-rpc.plugin causes arno to fail to start.)

[Julia Longtin]

Actually, on further investigation, i've determined it's better to abuse TR
for this, changing the 'ports=' lines to include calls to tr to swap the
carriage returns for spaces.

ports="$(rpcinfo -p |awk "/tcp.*$service/"' { print $4 }' | uniq | tr '\n'
' ')"

it was complicated to debug, as restarting the first time after a failure
didn't trigger, but the second time does.

with these changes, i see the proper output in the syslog:
Apr 14 13:42:43 qemuhost arno-iptables-firewall[2260537]:   Enabling RPC
service(s) portmapper status statd nfs mountd nlockmgr for net(s)
10.0.2.0/24
Apr 14 13:42:43 qemuhost arno-iptables-firewall[2260537]:   Adding TCP
ports 111  for RPC service portmapper
Apr 14 13:42:43 qemuhost arno-iptables-firewall[2260537]:   Adding UDP
ports 111  for RPC service portmapper
Apr 14 13:42:43 qemuhost arno-iptables-firewall[2260537]:   Adding TCP
ports  for RPC service status
Apr 14 13:42:43 qemuhost arno-iptables-firewall[2260537]:   Adding UDP
ports  for RPC service status
Apr 14 13:42:43 qemuhost arno-iptables-firewall[2260537]:   Adding TCP
ports  for RPC service statd
Apr 14 13:42:43 qemuhost arno-iptables-firewall[2260537]:   Adding UDP
ports  for RPC service statd
Apr 14 13:42:43 qemuhost arno-iptables-firewall[2260537]:   Adding TCP
ports 2049  for RPC service nfs
Apr 14 13:42:43 qemuhost arno-iptables-firewall[2260537]:   Adding UDP
ports 2049  for RPC service nfs
Apr 14 13:42:43 qemuhost arno-iptables-firewall[2260537]:   Adding TCP
ports 34943 40573 40653  for RPC service mountd
Apr 14 13:42:43 qemuhost arno-iptables-firewall[2260537]:   Adding UDP
ports 59663 50989 33098  for RPC service mountd
Apr 14 13:42:43 qemuhost arno-iptables-firewall[2260537]:   Adding TCP
ports 45913  for RPC service nlockmgr
Apr 14 13:42:43 qemuhost arno-iptables-firewall[2260537]:   Adding UDP
ports 45674  for RPC service nlockmgr

and NFS is functional.

On Mon, Apr 13, 2020 at 9:21 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian Security Tools 
>
> If you wish to submit further information on this problem, please
> send it to 956...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 956552: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956552
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#951986: feedreader: diff for NMU version 2.10.0-1.1

[Håvard Flaget Aasen]

Control: tags 951986 + patch
Control: tags 951986 + pending

Dear maintainer,

I've prepared an NMU for feedreader (versioned as 2.10.0-1.1) and
uploaded it to mentors. Please feel free to tell me if I should remove it.

Regards,
Håvard
diff -Nru feedreader-2.10.0/debian/changelog feedreader-2.10.0/debian/changelog
--- feedreader-2.10.0/debian/changelog	2019-07-21 13:34:34.0 +0200
+++ feedreader-2.10.0/debian/changelog	2020-04-14 14:16:14.0 +0200
@@ -1,3 +1,11 @@
+feedreader (2.10.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Cherry-pick upstream commit. closes: #951986 
+0002-Fix-infinite-loading-icon-after-opening-article-in-b.patch
+
+ -- Håvard Flaget Aasen   Tue, 14 Apr 2020 14:16:14 +0200
+
 feedreader (2.10.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru feedreader-2.10.0/debian/patches/0002-Fix-infinite-loading-icon-after-opening-article-in-b.patch feedreader-2.10.0/debian/patches/0002-Fix-infinite-loading-icon-after-opening-article-in-b.patch
--- feedreader-2.10.0/debian/patches/0002-Fix-infinite-loading-icon-after-opening-article-in-b.patch	1970-01-01 01:00:00.0 +0100
+++ feedreader-2.10.0/debian/patches/0002-Fix-infinite-loading-icon-after-opening-article-in-b.patch	2020-04-13 17:45:18.0 +0200
@@ -0,0 +1,34 @@
+From: PopeRigby 
+Date: Wed, 15 Jan 2020 16:28:42 -0800
+Subject: Fix infinite loading icon after opening article in browser
+
+---
+ src/Backend/FeedServer.vala   | 2 +-
+ src/Widgets/SharePopover.vala | 1 +
+ 2 files changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/src/Backend/FeedServer.vala b/src/Backend/FeedServer.vala
+index 7660045..ce39f74 100644
+--- a/src/Backend/FeedServer.vala
 b/src/Backend/FeedServer.vala
+@@ -57,7 +57,7 @@ public class FeedReader.FeedServer : GLib.Object {
+ var secrets = Secret.Collection.for_alias_sync(secret_service, Secret.COLLECTION_DEFAULT, Secret.CollectionFlags.NONE);
+ if(secrets == null)
+ {
+-	secrets = Secret.Collection.create_sync(secret_service, "Login", Secret.COLLECTION_DEFAULT, Secret.CollectionCreateFlags.COLLECTION_CREATE_NONE);
++	secrets = Secret.Collection.create_sync(secret_service, "Login", Secret.COLLECTION_DEFAULT, Secret.CollectionCreateFlags.NONE);
+ }
+ 
+ var settings_backend = null; // FIXME: Why does SettingsBackend.get_default() crash on Arch Linux?
+diff --git a/src/Widgets/SharePopover.vala b/src/Widgets/SharePopover.vala
+index 0998f92..3c45ff7 100644
+--- a/src/Widgets/SharePopover.vala
 b/src/Widgets/SharePopover.vala
+@@ -136,6 +136,7 @@ public class FeedReader.SharePopover : Gtk.Popover {
+ 		shareInternal(id, url);
+ 		string idString = (id == null || id == "") ? "" : @" to $id";
+ 		Logger.debug(@"bookmark: $url$idString");
++		shareDone();
+ 	}
+ }
+ 
diff -Nru feedreader-2.10.0/debian/patches/series feedreader-2.10.0/debian/patches/series
--- feedreader-2.10.0/debian/patches/series	2019-07-21 13:34:34.0 +0200
+++ feedreader-2.10.0/debian/patches/series	2020-04-13 18:00:00.0 +0200
@@ -1 +1,2 @@
 fix_some_spelling_errors.patch
+0002-Fix-infinite-loading-icon-after-opening-article-in-b.patch

Bug#956700: Please witch to enchant-2 instead of enchant(1)

[Laurent Bigonville]

Source: kvirc
Version: 4:5.0.0+dfsg-2
Severity: important
Control: block 947979 by -1

Hello,

Could you please switch from enchant(1) to the enchant-2 library?

We are trying to get rid of enchant(1) for the bullseye release.

I see some support for enchant2, switching the build-dependency to
libenchant-2-dev should be enough.

Could you please switch the build-dependency?

Kind regards,
Laurent Bigonville

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

Kernel: Linux 5.5.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#956671: negotiator logs

[Henning Fehrmann]

Hi,

just in case, I attache two log snippets, containing few negiotiator
cycles with and without NEGOTIATOR_INTERVALL enabled.

Cheers,
Henning
04/08/20 12:55:46 -- Started Negotiation Cycle --
04/08/20 12:55:46 Phase 1:  Obtaining ads from collector ...
04/08/20 12:55:46   Getting startd private ads ...
04/08/20 12:55:46 Trying to query collector <10.20.60.65:9618>
04/08/20 12:55:46   Getting Scheduler, Submitter and Machine ads ...
04/08/20 12:55:46 Trying to query collector <10.20.60.65:9618>
04/08/20 12:55:46   Sorting 4 ads ...
04/08/20 12:55:46 Ignoring submitter prod.atlascondor@atlas.local from schedd 
at <10.20.60.65:9618?addrs=10.20.60.65-9618&noUDP&sock=639885_7712_4> with no 
requested jobs
04/08/20 12:55:46 Got ads: 4 public and 1 private
04/08/20 12:55:46 Public ads include 1 submitter, 1 startd
04/08/20 12:55:46 Phase 2:  Performing accounting ...
04/08/20 12:55:46 Entering compute_significant_attrs()
04/08/20 12:55:46 Leaving compute_significant_attrs() - 
result=_condor_RequestCpus,_condor_RequestDisk,_condor_RequestMemory,JobStart,JobUniverse,LastCheckpointPlatform,MachineLastMatchTime,NumCkpts,RequestCpus,RequestDisk,RequestGPUs,RequestMemory,TotalGPUs
04/08/20 12:55:46 Phase 3:  Sorting submitter ads by priority ...
04/08/20 12:55:46 Starting prefetch round; 1 potential prefetches to do.
04/08/20 12:55:46 Assigned 1 units of work for prefetching.
04/08/20 12:55:46 Starting prefetch loop.
04/08/20 12:55:46 Starting prefetch negotiation for prod.fehrmann@atlas.local.
04/08/20 12:55:46 Socket to prod.fehrmann@atlas.local 
(<10.20.60.65:9618?addrs=10.20.60.65-9618&noUDP&sock=639885_7712_4>) already in 
cache, reusing
04/08/20 12:55:46 Started NEGOTIATE with remote schedd; protocol version 1.
04/08/20 12:55:46 Sending SEND_RESOURCE_REQUEST_LIST/200/eom
04/08/20 12:55:46 Getting reply from schedd ...
04/08/20 12:55:46 Prefetch negotiation would block.
04/08/20 12:55:46 Waiting on the results of 1 negotiation sessions.
04/08/20 12:55:46 Getting reply from schedd ...
04/08/20 12:55:46 Got JOB_INFO command; getting classad/eom
04/08/20 12:55:46 Getting reply from schedd ...
04/08/20 12:55:46 Got JOB_INFO command; getting classad/eom
04/08/20 12:55:46 Getting reply from schedd ...
04/08/20 12:55:46 Got JOB_INFO command; getting classad/eom
04/08/20 12:55:46 Getting reply from schedd ...
04/08/20 12:55:46 Got NO_MORE_JOBS;  schedd has no more requests
04/08/20 12:55:46 Send END_NEGOTIATE to remote schedd
04/08/20 12:55:46 Assigned 0 units of work for prefetching.
04/08/20 12:55:46 Prefetch summary: 1 attempted, 1 successful.
04/08/20 12:55:46 Phase 4.1:  Negotiating with schedds ...
04/08/20 12:55:46 numSlots = 1 (after trimming=1)
04/08/20 12:55:46 slotWeightTotal = 4.00
04/08/20 12:55:46 minSlotWeight = 4.00
04/08/20 12:55:46 pieLeft = 4.000
04/08/20 12:55:46 NormalFactor = 1.00
04/08/20 12:55:46 MaxPrioValue = 14967.540039
04/08/20 12:55:46 NumSubmitterAds = 1
04/08/20 12:55:46   Negotiating with prod.fehrmann@atlas.local at 
<10.20.60.65:9618?addrs=10.20.60.65-9618&noUDP&sock=639885_7712_4>
04/08/20 12:55:46 0 seconds so far for this submitter
04/08/20 12:55:46 0 seconds so far for this schedd
04/08/20 12:55:46   Calculating submitter limit with the following parameters
04/08/20 12:55:46 SubmitterPrio   = 14967.540039
04/08/20 12:55:46 SubmitterPrioFactor = 1.00
04/08/20 12:55:46 submitterShare  = 1.00
04/08/20 12:55:46 submitterAbsShare   = 1.00
04/08/20 12:55:46 submitterLimit= 4.00
04/08/20 12:55:46 submitterUsage= 0.00
04/08/20 12:55:46 Using resource request list from cache.
04/08/20 12:55:46 Socket to prod.fehrmann@atlas.local 
(<10.20.60.65:9618?addrs=10.20.60.65-9618&noUDP&sock=639885_7712_4>) already in 
cache, reusing
04/08/20 12:55:46 Started NEGOTIATE with remote schedd; protocol version 1.
04/08/20 12:55:46 Request 00021.0: autocluster 1 (request count 1 of 1)
04/08/20 12:55:46 matchmakingAlgorithm: limit 4.00 used 0.00 pieLeft 
4.00
04/08/20 12:55:46   Sending PERMISSION, claim id, startdAd to schedd
04/08/20 12:55:46   Notifying the accountant
04/08/20 12:55:46   Successfully matched with slot1@a3305.atlas.local
04/08/20 12:55:46 Match completed, match cost= 4
04/08/20 12:55:46 Over submitter resource limit (4.00, used 4.00) 
... only consider startd ranks
04/08/20 12:55:46 Request 00021.1: autocluster 2 (request count 1 of 1)
04/08/20 12:55:46 matchmakingAlgorithm: limit 4.00 used 4.00 pieLeft 
0.00
04/08/20 12:55:46 Request 00021.2: autocluster 1 (request count 1 of 2)
04/08/20 12:55:46 matchmakingAlgorithm: limit 4.00 used 4.00 pieLeft 
0.00
04/08/20 12:55:46 Send END_NEGOTIATE to remote schedd
04/08/20 12:55:46   This submitter hit its submitterLimit.
04/08/20 12:55:46  resources used scheddUsed= 4.00
04/08/20 12:55:46  ne

Bug#956699: ogmrip: Please witch to enchant-2 instead of enchant(1)

[Laurent Bigonville]

Source: ogmrip
Version: 1.0.1-2
Severity: important
Tags: patch
Control: block 947979 by -1

Hello,

Could you please switch from enchant(1) to the enchant-2 library?

We are trying to get rid of enchant(1) for the bullseye release.

The attached patch should fix this (no tested though)

Kind regards,
Laurent Bigonville

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

Kernel: Linux 5.5.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
diff -Nru ogmrip-1.0.1/debian/control ogmrip-1.0.1/debian/control
--- ogmrip-1.0.1/debian/control 2019-10-11 00:27:43.0 +0200
+++ ogmrip-1.0.1/debian/control 2020-04-14 14:37:12.0 +0200
@@ -12,7 +12,7 @@
  libdbus-glib-1-dev (>= 0.7.2),
  libdvdread-dev (>= 4.1.3-4),
  libenca-dev,
- libenchant-dev,
+ libenchant-2-dev,
  libgconf2-dev,
  libglade2-dev,
  libnotify-dev (>= 0.7),
diff -Nru ogmrip-1.0.1/debian/patches/enchant2.patch 
ogmrip-1.0.1/debian/patches/enchant2.patch
--- ogmrip-1.0.1/debian/patches/enchant2.patch  1970-01-01 01:00:00.0 
+0100
+++ ogmrip-1.0.1/debian/patches/enchant2.patch  2020-04-14 14:41:11.0 
+0200
@@ -0,0 +1,30 @@
+--- a/configure.in
 b/configure.in
+@@ -161,7 +161,7 @@ AC_SUBST(DBUS_LIBS)
+ dnl **
+ 
+ ENCHANT_REQUIRED=1.1.0
+-ENCHANT_MODULES="enchant >= $ENCHANT_REQUIRED"
++ENCHANT_MODULES="enchant-2 >= $ENCHANT_REQUIRED"
+ 
+ AC_ARG_ENABLE(enchant-support,
+   AC_HELP_STRING([--disable-enchant-support], [disable Enchant support]),
+--- a/src/ogmrip-spell-dialog.c
 b/src/ogmrip-spell-dialog.c
+@@ -315,14 +315,14 @@ ogmrip_spell_dialog_check_word (OGMRipSp
+ enchant_dict_add_to_session (dialog->priv->dict, word, len);
+ break;
+   case OGMRIP_SPELL_RESPONSE_ADD_WORD:
+-enchant_dict_add_to_personal (dialog->priv->dict, word, len);
++enchant_dict_add (dialog->priv->dict, word, len);
+ break;
+   default:
+ break;
+ }
+ 
+ if (suggs && n_suggs)
+-  enchant_dict_free_suggestions (dialog->priv->dict, suggs);
++  enchant_dict_free_string_list (dialog->priv->dict, suggs);
+   }
+ 
+   return status;
diff -Nru ogmrip-1.0.1/debian/patches/series ogmrip-1.0.1/debian/patches/series
--- ogmrip-1.0.1/debian/patches/series  2019-10-11 00:21:13.0 +0200
+++ ogmrip-1.0.1/debian/patches/series  2020-04-14 14:37:26.0 +0200
@@ -1,2 +1,3 @@
 01_libdvdread4.diff
 02_configure.diff
+enchant2.patch

Bug#715644: aribas crashes

[Jan Fricke]

Hi!
I can also report that aribas (amd64) gives false "syntax error" and 
"segmentation faults". I suppose that aribas is not 64 bit save. The 
i386 version seems to work correctly.


Regards,

Jan Fricke, University of Siegen

Bug#956701: RM: enigmail/2:2.0.8-5~deb9u1

[Adrian Bunk]

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

enigmail is no longer installable with the thunderbird version
now in stretch (#949736).

Updating enigmail in stretch might be non-trivial due to the
versioned dependency on gnupg.

It is expected that shortly after the final non-LTS release of stretch
there will be an LTS update of thunderbird in stretch with a version
that can no longer be supported by enigmail:
https://www.enigmail.net/index.php/en/home/news/70-2019-10-08-future-openpgp-support-in-thunderbird

I do not see a better solution than removing the enigmail package
that is already not installable in stretch.

Daniel Kahn Gillmor Cc'ed, an ACK/NAK would be appreciated.

Bug#955098: Bug#955101: sphinx-testing: FTBFS with Sphinx 2.4: dh_auto_test: error: pybuild --test -i python{version} -p "3.7 3.8" returned exit code 13

[Dmitry Shachnev]

Control: tags -1 + patch pending

On Fri, Mar 27, 2020 at 03:52:07PM +0100, Lucas Nussbaum wrote:
> Hi,
>
> sphinx-testing fails to build with Sphinx 2.4, currently available in
> experimental.

I have uploaded a new version of sphinx-testing as NMU to DELAYED/2.
The debdiff is attached.

And I will upload new sphinx to unstable as soon as #956625 is fixed.

--
Dmitry Shachnev
diff -Nru sphinx-testing-0.8.1/CHANGES.rst sphinx-testing-1.0.1/CHANGES.rst
--- sphinx-testing-0.8.1/CHANGES.rst	2018-11-23 18:33:05.0 +0300
+++ sphinx-testing-1.0.1/CHANGES.rst	2019-04-15 17:51:07.0 +0300
@@ -1,6 +1,17 @@
 Changelog
 ==
 
+1.0.1 (2019-04-15)
+---
+- Support Sphinx-2.0.1
+
+1.0.0 (2019-01-27)
+---
+- Support Sphinx-2.0 (unreleased yet)
+- Fix a bug:
+
+  - #12: @with_app decorator should return the value of the decorated function
+
 0.8.1 (2018-11-24)
 ---
 - Fix a bug:
diff -Nru sphinx-testing-0.8.1/debian/changelog sphinx-testing-1.0.1/debian/changelog
--- sphinx-testing-0.8.1/debian/changelog	2020-03-15 06:55:05.0 +0300
+++ sphinx-testing-1.0.1/debian/changelog	2020-04-14 15:49:42.0 +0300
@@ -1,3 +1,14 @@
+sphinx-testing (1.0.1-0.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * New upstream release.
+- Compatible with Sphinx 2.x (closes: #955101, #955098).
+  * Update upstream Homepage URL.
+  * Stop using deprecated nose for tests, just unittest is enough.
+  * Run the autopkgtest for all supported Python versions.
+
+ -- Dmitry Shachnev   Tue, 14 Apr 2020 15:49:42 +0300
+
 sphinx-testing (0.8.1-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru sphinx-testing-0.8.1/debian/control sphinx-testing-1.0.1/debian/control
--- sphinx-testing-0.8.1/debian/control	2019-10-13 07:07:00.0 +0300
+++ sphinx-testing-1.0.1/debian/control	2020-04-14 15:49:42.0 +0300
@@ -6,7 +6,6 @@
dh-python,
python3-all,
python3-setuptools,
-   python3-nose,
python3-flake8,
python3-mock,
python3-sphinx,
@@ -14,7 +13,7 @@
python3-jinja2,
python3-pygments
 Standards-Version: 4.3.0
-Homepage: http://bitbucket.org/tk0miya/sphinx-testing
+Homepage: https://github.com/sphinx-doc/sphinx-testing
 
 Package: python3-sphinx-testing
 Architecture: all
diff -Nru sphinx-testing-0.8.1/debian/copyright sphinx-testing-1.0.1/debian/copyright
--- sphinx-testing-0.8.1/debian/copyright	2014-10-23 17:49:22.0 +0400
+++ sphinx-testing-1.0.1/debian/copyright	2020-04-14 15:49:42.0 +0300
@@ -1,6 +1,6 @@
 Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: sphinx-testing
-Source: http://bitbucket.org/tk0miya/sphinx-testing
+Source: https://github.com/sphinx-doc/sphinx-testing
 
 Files: *
 Copyright: 2014 Takeshi KOMIYA 
diff -Nru sphinx-testing-0.8.1/debian/gitlab-ci.yml sphinx-testing-1.0.1/debian/gitlab-ci.yml
--- sphinx-testing-0.8.1/debian/gitlab-ci.yml	1970-01-01 03:00:00.0 +0300
+++ sphinx-testing-1.0.1/debian/gitlab-ci.yml	2020-04-14 15:49:42.0 +0300
@@ -0,0 +1,3 @@
+include:
+  - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
+  - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
diff -Nru sphinx-testing-0.8.1/debian/rules sphinx-testing-1.0.1/debian/rules
--- sphinx-testing-0.8.1/debian/rules	2019-10-13 07:07:09.0 +0300
+++ sphinx-testing-1.0.1/debian/rules	2020-04-14 15:49:42.0 +0300
@@ -6,7 +6,7 @@
 include /usr/share/dpkg/default.mk
 
 export PYBUILD_NAME=sphinx-testing
-export PYBUILD_TEST_NOSE=1
+export PYBUILD_TEST_ARGS=-s tests
 
 %:
 	dh $@ --with python3 --buildsystem=pybuild
diff -Nru sphinx-testing-0.8.1/debian/tests/control sphinx-testing-1.0.1/debian/tests/control
--- sphinx-testing-0.8.1/debian/tests/control	2020-03-15 06:54:59.0 +0300
+++ sphinx-testing-1.0.1/debian/tests/control	2020-04-14 15:49:42.0 +0300
@@ -1,4 +1,2 @@
 Tests: python3-sphinx-testing
-Depends: python3-sphinx,
- python3-six,
- python3-nose
+Depends: python3-all, python3-sphinx-testing
diff -Nru sphinx-testing-0.8.1/debian/tests/python3-sphinx-testing sphinx-testing-1.0.1/debian/tests/python3-sphinx-testing
--- sphinx-testing-0.8.1/debian/tests/python3-sphinx-testing	2019-01-05 03:04:36.0 +0300
+++ sphinx-testing-1.0.1/debian/tests/python3-sphinx-testing	2020-04-14 15:49:42.0 +0300
@@ -2,7 +2,7 @@
 set -e -u
 cp -r tests "$AUTOPKGTEST_TMP/"
 cd "$AUTOPKGTEST_TMP"
-py3versions -i \
+py3versions -s \
 | tr ' ' '\n' \
 | xargs -I {} env PYTHONWARNINGS=d PYTHONHASHSEED=random {} \
-  -m nosetests3 -vv 2>&1
+  -m unittest discover -v -s tests 2>&1
diff -Nru sphinx-testing-0.8.1/PKG-INFO sphinx-testing-1.0.1/PKG-INFO
--- sphinx-testing-0.8.1/PKG-INFO	2018-11-23 18:33:48.0 +0300
+++ sphinx-testing-1.0.1/PKG-INFO	2019-04-1

Bug#956704: Enchant support disabled

[Laurent Bigonville]

Source: fcitx
Version: 1:4.2.9.7-3
Severity: normal

Hello,

Since 1:4.2.9.7-3 upload enchant support is disabled:

-- Checking for module 'enchant'
--   No package 'enchant' found

And the packages are not linked to libenchant-2-2

Quickly looking at the code, the pkg-config file name in
cmake/FindEnchant.cmake should be changed from "enchant" to "enchant-2"

pkg_check_modules(PC_ENCHANT enchant) -> pkg_check_modules(PC_ENCHANT enchant-2)

Kind regards,
Laurent Bigonville


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

Kernel: Linux 5.5.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#956703: linux-image-5.5: 5.5 kernel seems to break pulseaudio HDMI detection

[Simon John]

Package: src:linux
Version: 5.5.13-2
Severity: normal
File: linux-image-5.5

Dear Maintainer,

Booting into 5.5 on Sid gives me no audio out via HDMI.

In Gnome Settings the GP108 isn't even listed until I run pulseaudio -k, 
then I can select it and audio works again for an hour or so, then I 
have to kill pulseaudio again to get it back.


Booting back into 5.4 solves the problem, confirmed by booting back into 
5.5 and the problem is back again, nothing else is different.


Not using proprietary Nvidia drivers or anything obvious.


-- Package-specific info:
** Version:
Linux version 5.5.0-1-amd64 (debian-ker...@lists.debian.org) (gcc 
version 9.3.0 (Debian 9.3.0-8)) #1 SMP Debian 5.5.13-2 (2020-03-30)


** Command line:
BOOT_IMAGE=/vmlinuz-5.5.0-1-amd64 
root=UUID=2b82e6c4-442e-4700-a246-3b5c37a722b5 ro quiet 
slab_common.usercopy_fallback=y


** Tainted: OE (12288)
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

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

** Model information
sys_vendor: Dell Inc.
product_name: Precision T5610
product_version: 00
chassis_vendor: Dell Inc.
chassis_version:
bios_vendor: Dell Inc.
bios_version: A19
board_vendor: Dell Inc.
board_name: 0WN7Y6

** Loaded modules:
vboxnetadp(OE)
vboxnetflt(OE)
vboxdrv(OE)
bridge
stp
llc
rfkill
binfmt_misc
jfs
intel_rapl_msr
intel_rapl_common
snd_hda_codec_hdmi
sb_edac
x86_pkg_temp_thermal
intel_powerclamp
kvm_intel
snd_hda_codec_realtek
snd_hda_codec_generic
ledtrig_audio
pktcdvd
kvm
snd_hda_intel
snd_intel_dspcfg
dcdbas
mei_wdt
snd_hda_codec
intel_cstate
dell_smm_hwmon
hwmon_vid
coretemp
snd_hda_core
joydev
intel_uncore
snd_hwdep
snd_pcm
intel_rapl_perf
snd_timer
mei_me
snd
iTCO_wdt
iTCO_vendor_support
serio_raw
pcspkr
sg
watchdog
mei
soundcore
evdev
nft_ct
nf_conntrack
nf_defrag_ipv6
nf_defrag_ipv4
nf_tables
nfsd
nfnetlink
loop
auth_rpcgss
parport_pc
ppdev
nfs_acl
lockd
lp
parport
grace
sunrpc
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
btrfs
blake2b_generic
zstd_decompress
zstd_compress
essiv
authenc
dm_crypt
dm_mod
raid10
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
async_tx
xor
raid6_pq
libcrc32c
crc32c_generic
raid1
raid0
multipath
linear
md_mod
uas
usb_storage
hid_generic
usbhid
hid
sr_mod
cdrom
sd_mod
nouveau
crct10dif_pclmul
crc32_pclmul
crc32c_intel
ghash_clmulni_intel
vfio_pci
vfio_virqfd
vfio_iommu_type1
vfio
irqbypass
mxm_wmi
video
i2c_algo_bit
ttm
ahci
drm_kms_helper
xhci_pci
libahci
xhci_hcd
aesni_intel
libata
ehci_pci
ehci_hcd
drm
e1000e
crypto_simd
usbcore
scsi_mod
cryptd
glue_helper
lpc_ich
ptp
i2c_i801
mfd_core
pps_core
usb_common
wmi
button

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Xeon E7 v2/Xeon E5 v2/Core 
i7 DMI2 [8086:0e00] (rev 04)

Subsystem: Dell Xeon E7 v2/Xeon E5 v2/Core i7 DMI2 [1028:05d3]
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Interrupt: pin A routed to IRQ 0
NUMA node: 0
Capabilities: [90] Express (v2) Root Port (Slot-), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0
ExtTag- RBE+
DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- 
TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x4, ASPM L1, Exit Latency L1 
<16us
ClockPM- Surprise+ LLActRep+ BwNot+ ASPMOptComp+
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed unknown (downgraded), Width x0 (downgraded)
TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
RootCap: CRSVisible-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- 
CRSVisible-
RootSta: PME ReqID , PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range BCD, TimeoutDis+, NROPrPrP-, 
LTR-
 10BitTagComp-, 10BitTagReq-, OBFF Not Supported, 
ExtFmt-, EETLPPrefix-
 EmergencyPowerReduction Not Supported, 
EmergencyPowerReductionInit-
 FRS-, LN System CLS Not Supported, TPHComp+, 
ExtTPHComp-, ARIFwd-
 AtomicOpsCap: Routing- 32bit+ 64bit+ 128bitCAS+
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF 
Disabled ARIFwd-

 AtomicOpsCtl: ReqEn- EgressBlck-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance- 
ComplianceSOS-

 Compliance De-emphasis: -6dB

Bug#956702: RFS: feedreader/2.10.0-1.1 [NMU, RC] -- simple client for online RSS services like tt-rss and others

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: feedreader
   Version : 2.10.0-1.1
   Upstream Author : [fill in name and email of upstream]
 * URL : https://jangernert.github.io/FeedReader/
 * License : GPL-3.0+
 * Vcs : https://salsa.debian.org/debian/FeedReader
   Section : net

It builds those binary packages:

  feedreader - simple client for online RSS services like tt-rss and others

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/f/feedreader/feedreader_2.10.0-1.1.dsc

Changes since the last upload:

   * Non-maintainer upload.
   * Cherry-pick upstream commit. closes: #951986
 0002-Fix-infinite-loading-icon-after-opening-article-in-b.patch

Regards,
Håvard

Bug#956698: lintian: package-from-other-python-variant exception: python-pip-whl

[Mattia Rizzolo]

On Tue, Apr 14, 2020 at 08:41:01AM -0400, Scott Kitterman wrote:
> The package python-pip-whl is a special case of a Python package built
> to work with either python or python3.  Currently python3-vertualenv
> gets the following lintian warning:
> 
> W: python3-virtualenv: 
> python-package-depends-on-package-from-other-python-variant Depends: 
> python-pip-whl
> 
> While this is a great warning in general, in this case it's wrong.
> Would it be OK to special case python-pip-whl and have it not trigger
> this check?

I would wager that this is the exact use case for an override?

-- 
regards,
Mattia Rizzolo

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

Bug#956665: libdrm2: Update broke firefox WebGL

[Timo Aaltonen]

Timo Aaltonen kirjoitti 14.4.2020 klo 10.34:
> On 14.4.2020 8.03, Fabian Inostroza wrote:
>> Package: libdrm2
>> Version: 2.4.101-1
>> Severity: normal
>>
>> Dear Maintainer,
>>
>> After updating libdrm2 from 2.4.100-4 to 2.4.101-1 WebGL stopped working on
>> firefox (using esr from repos and tar from mozilla).
>>
>> After loading a WebGL sample from webglsamples.org the following is message 
>> is
>> shown in the web console:
>> Error: WebGL warning: : Failed to create WebGL context: WebGL 
>> creation failed: 
>> * tryNativeGL
>> * Exhausted GL driver options.
>>
>> and in the terminal where firefox was launched:
>> libGL error: MESA-LOADER: failed to retrieve device information
>> libGL error: Version 4 or later of flush extension not found
>> libGL error: failed to load driver: i915
>> libGL error: MESA-LOADER: failed to retrieve device information
> 
> Probably the same as this upstream bug
> 
> https://gitlab.freedesktop.org/mesa/drm/-/issues/39
> 
> could you test this patch if it helps:
> 
> https://716574.bugs.gentoo.org/attachment.cgi?id=632372

Nevermind, I've tested it myself and it works.

Bug#837346:

[Đạt Trần]

Bug#956705: ITP: python-pydiscourse -- Python library for working with Discourse

[Martin]

Package: wnpp
Severity: wishlist
Owner: Martin 

* Package name: python-pydiscourse
  Version : v1.0.0
  Upstream Author : Marc Sibson and contributors 

* URL : https://github.com/bennylope/pydiscourse
* License : MIT
  Programming Lang: Python
  Description : Python library for working with Discourse

>From the README:

> A Python library for working with Discourse.
> 
> This is a fork of the original Tindie version. It was forked
> to include fixes, additional functionality, and to distribute
> a package on PyPI.
>
> Goals
>
> * Exceptional documentation
> * Support all supported Python versions
> * Provide functional parity with the Discourse API, for the
>   currently supported version of Discourse (something of a
>   moving target)
>
> The order here is important. The Discourse API is itself
> poorly documented so the level of documentation in the Python
> client is critical.

Bug#956698: lintian: package-from-other-python-variant exception: python-pip-whl

[Scott Kitterman]

On Tuesday, April 14, 2020 9:22:37 AM EDT Mattia Rizzolo wrote:
> On Tue, Apr 14, 2020 at 08:41:01AM -0400, Scott Kitterman wrote:
> > The package python-pip-whl is a special case of a Python package built
> > to work with either python or python3.  Currently python3-vertualenv
> > gets the following lintian warning:
> > 
> > W: python3-virtualenv:
> > python-package-depends-on-package-from-other-python-variant Depends:
> > python-pip-whl
> > 
> > While this is a great warning in general, in this case it's wrong.
> > Would it be OK to special case python-pip-whl and have it not trigger
> > this check?
> 
> I would wager that this is the exact use case for an override?

I've added on for python3-virtualenv pointing to this bug.  If that's the 
preference of the lintian maintainers, I have no objection, please close the 
bug and we have it documented why it's an override.

Scott K

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

Bug#950150: audacity: Wayland problem confirmed

[Keyikedalube Ndang]

Package: audacity
Followup-For: Bug #950150

Dear Maintainer,

I switched from GNOME to XFCE the other day and I happened to listen to
my old recording using audacity

The timeline cursor works fine under X11
Wayland is the cause...

Regards,
Keyikedalube

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

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

Versions of packages audacity depends on:
ii  audacity-data 2.3.3-1
ii  libasound21.2.2-2.1
ii  libavcodec58  7:4.2.2-1+b1
ii  libavformat58 7:4.2.2-1+b1
ii  libavutil56   7:4.2.2-1+b1
ii  libc6 2.30-4
ii  libexpat1 2.2.9-1
ii  libflac++6v5  1.3.3-1
ii  libflac8  1.3.3-1
ii  libgcc-s1 [libgcc1]   10-20200324-1
ii  libgcc1   1:10-20200324-1
ii  libgdk-pixbuf2.0-02.40.0+dfsg-3
ii  libglib2.0-0  2.64.1-1
ii  libgtk-3-03.24.18-1
ii  libid3tag00.15.1b-14
ii  liblilv-0-0   0.24.6-1
ii  libmad0   0.15.1b-10
ii  libmp3lame0   3.100-3
ii  libogg0   1.3.2-1+b1
ii  libportaudio2 19.6.0-1
ii  libportsmf0   0.1~svn20101010-5
ii  libsndfile1   1.0.28-7
ii  libsoundtouch12.1.2+ds1-1
ii  libsoxr0  0.1.3-2
ii  libstdc++610-20200324-1
ii  libsuil-0-0   0.10.6-1
ii  libtwolame0   0.4.0-2
ii  libvamp-hostsdk3v52.9.0-1
ii  libvorbis0a   1.3.6-2
ii  libvorbisenc2 1.3.6-2
ii  libvorbisfile31.3.6-2
ii  libwxbase3.0-0v5  3.0.4+dfsg-15
ii  libwxgtk3.0-gtk3-0v5  3.0.4+dfsg-15

audacity recommends no packages.

Versions of packages audacity suggests:
ii  swh-plugins [ladspa-plugin]  0.4.17-2

-- no debconf information

Bug#956706: RM: python-azure-storage -- ROM; binary package taken over by python-azure

[Luca Boccassi]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: python-modules-t...@lists.alioth.debian.org

Dear FTP Team,

As discussed by members of the Python Modules Team in:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954922
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954923
https://salsa.debian.org/python-team/modules/python-azure/-/merge_requests/3#note_144855
https://github.com/Azure/azure-storage-python/issues/655

We want to move the binary python3-azure-storage package from
src:python-azure-storage to src:python-azure.
The latter's version 20200130+git-3 is newer than the former's
20181109+git-2, so we will do a simple upload, no epochs required.

I believe an RM request is still necessary for the old source package,
but I might be wrong - filing one just in case.

Thanks!

-- 
Kind regards,
Luca Boccassi


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

Bug#956707: python-internetarchive doesn't close https connections

[kpcyrd]

Package: internetarchive
Version: 1.8.1-1+deb10u1
Severity: important

This is a bit of a follow up on #950289, I've retried uploading the folder and
ran out of file descriptors again, this time because the https connections
aren't closed.

The folder I'm testing with has ~10.000 files and fails midway.

Using lsof -nPi shows a large number of open connections in CLOSE_WAIT state:

[...]
ia  20254 user  469u  IPv4 99476489  0t0  TCP 
X.X.X.X:XXX->207.241.239.10:443 (CLOSE_WAIT)
ia  20254 user  470u  IPv4 99476491  0t0  TCP 
X.X.X.X:XXX->207.241.239.10:443 (CLOSE_WAIT)
ia  20254 user  471u  IPv4 99476522  0t0  TCP 
X.X.X.X:XXX->207.241.239.10:443 (CLOSE_WAIT)
ia  20254 user  472u  IPv4 99476528  0t0  TCP 
X.X.X.X:XXX->207.241.239.10:443 (CLOSE_WAIT)
ia  20254 user  473u  IPv4 99476553  0t0  TCP 
X.X.X.X:XXX:40406->207.241.239.10:443 (ESTABLISHED)

It eventually crashes with:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/urllib3/util/ssl_.py", line 321, 
in ssl_wrap_socket
OSError: [Errno 24] Too many open files

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 
600, in urlopen
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 
343, in _make_request
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 
841, in _validate_conn
  File "/usr/lib/python3/dist-packages/urllib3/connection.py", line 
344, in connect
  File "/usr/lib/python3/dist-packages/urllib3/util/ssl_.py", line 323, 
in ssl_wrap_socket
urllib3.exceptions.SSLError: [Errno 24] Too many open files

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/requests/adapters.py", line 449, 
in send
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 
638, in urlopen
  File "/usr/lib/python3/dist-packages/urllib3/util/retry.py", line 
398, in increment
urllib3.exceptions.MaxRetryError: 
HTTPSConnectionPool(host='s3.us.archive.org', port=443): Max retries exceeded 
with url: /redacted (Caused by SSLError(OSError(24, 'Too many open files')))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/ia", line 11, in 
  File "/usr/lib/python3/dist-packages/internetarchive/cli/ia.py", line 
159, in main
  File 
"/usr/lib/python3/dist-packages/internetarchive/cli/ia_upload.py", line 225, in 
main
  File 
"/usr/lib/python3/dist-packages/internetarchive/cli/ia_upload.py", line 86, in 
_upload_files
  File "/usr/lib/python3/dist-packages/internetarchive/item.py", line 
828, in upload
  File "/usr/lib/python3/dist-packages/internetarchive/item.py", line 
710, in upload_file
  File "/usr/lib/python3/dist-packages/internetarchive/session.py", 
line 370, in send
  File "/usr/lib/python3/dist-packages/requests/sessions.py", line 646, 
in send
  File "/usr/lib/python3/dist-packages/requests/adapters.py", line 514, 
in send
requests.exceptions.SSLError: 
HTTPSConnectionPool(host='s3.us.archive.org', port=443): Max retries exceeded 
with url: /redacted (Caused by SSLError(OSError(24, 'Too many open files')))

I'm currently short on time so I'm having trouble fully disecting this bug and
test if sid is also affected. I've reported it upstream to ask for assistance:

https://github.com/jjjake/internetarchive/issues/336

Bug#956708: New upstream release 1.4.0 available (with security fixes for SASL/SCRAM auth)

[Nicolas Dandrimont]

Package: src:librdkafka
Version: 1.3.0-1
Severity: important
Tags: patch security upstream

Dear maintainers,

Upstream for librdkafka has recently released version 1.4.0 of the library[1].

[1] https://github.com/edenhill/librdkafka/releases/tag/v1.4.0

The release notes mention that two security issues[2,3] in the way SASL/SCRAM
authentication was implemented. SASL/SCRAM was introduced in v0.11.0, and the
offending code was introduced at that point[4], so the security bug affects the
version in stable as well.

[2] 
https://github.com/edenhill/librdkafka/commit/9b468d2fafbdc23f2326e174a6bd92e70457ce6d
[3] 
https://github.com/edenhill/librdkafka/commit/8f7a4c858afc8ff24672426473448c3e0c56cfc3
[4] 
https://github.com/edenhill/librdkafka/blob/v0.11.0/src/rdkafka_sasl_scram.c 
lines 91
(nonce bug) and 340-341 (buffer overflow)

I guess these patches could be uploaded as a stable update (but I haven't looked
at older security fixes if some more would be relevant).

I've prepared the update for sid[5] and I can upload it if you'd like (I'm
currently using a package of a git checkout of a pre-1.4.0 commit in production,
and will update to 1.4.0 there anyway).

[5] https://salsa.debian.org/olasd/librdkafka branches debian/sid and 
pristine-tar

Thanks for your work!
Nicolas

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

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

Bug#956311: libsqlite3-dev: length(BLOB) should not convert to unicode

[Troy]

The data in question was binary data, not unicode. It just happened to
contain some valid UTF-8 sequences. I am communicating with the db
through ODBC (64-bit), so I will have to look and see what is happening
exactly. I will have to add some workaround to make sure that the data
is added as a BLOB. 

Troy



On Sat, 2020-04-11 at 14:25 +0200, László Böszörményi (GCS) wrote:
> On Sat, Apr 11, 2020 at 1:56 PM Troy Korjuslommi
>  wrote:
> > Please note that in
> > https://www.sqlite.org/lang_corefunc.html#length
> > 
> > it says that "For a blob value X, length(X) returns the number of
> > bytes
> > in the blob."
>  Indeed, if that's a BLOB value. But as yourself noted: "when data is
> valid UTF-8, it returns the number of characters" which is in sync
> with the datatype notes[1]: "the datatype of a value is associated
> with the value itself, not with its container". It doesn't matter
> that
> you defined the column as BLOB. The mentioned string (type) will be
> passed to the length() function which say[2]: "returns the number of
> characters (not bytes) in X". It works as its documented like you
> confirm that in your original message: "it returns the number of
> characters, not bytes".
> You will get the same answer on the forum, this is how SQLite works
> and it's documented correctly. But you are free to ask there and feel
> free to report back here.
> 
> Regards,
> Laszlo/GCS
> [1] https://www.sqlite.org/datatype3.htm
> [2] https://www.sqlite.org/lang_corefunc.html#length

Bug#954922: python-azure: take over python3-azure-storage package from src:python-azure-storage

[Luca Boccassi]

Upload done and RM request file for src:python-azure-storage:

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

-- 
Kind regards,
Luca Boccassi


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

Bug#956709: libglom-1.30-0: upgrade of boost packages makes libglom-1.30-0 uninstallable

[Giacomo Mulas]

Package: libglom-1.30-0
Version: 1.30.4-6
Severity: grave
Justification: renders package unusable

Dear Maintainer,

the upgrade of libboost-python1.67.0 breaks a dependency of libglom-1.30-0,
thereby making it uninstallable.  To fix this, it must be rebuilt with the
new libraries _and_ with python 3.8 instead of 3.7.

Thanks in advance, best regards
Giacomo Mulas


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

Kernel: Linux 5.5.13-jak (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to it_IT.utf8), LANGUAGE=it_IT,en_EN (charmap=UTF-8) (ignored: LC_ALL set 
to it_IT.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libglom-1.30-0 depends on:
ii  libarchive133.4.0-2
ii  libboost-python1.67.0 [libboost-python1.67.0-py37]  1.67.0-17
ii  libc6   2.30-4
ii  libepc-1.0-30.4.6-2
ii  libgcc-s1   10-20200411-1
ii  libgda-5.0-45.2.9-2
ii  libgdamm-5.0-13 4.99.11-3
ii  libgettextpo0   0.19.8.1-10
ii  libglib2.0-02.64.1-1
ii  libglibmm-2.4-1v5   2.64.2-1
ii  libpython3.83.8.2-1+b1
ii  libsigc++-2.0-0v5   2.10.2-1
ii  libstdc++6  10-20200411-1
ii  libxml++2.6-2v5 2.40.1-3
ii  libxml2 2.9.10+dfsg-5
ii  libxslt1.1  1.1.34-4

libglom-1.30-0 recommends no packages.

libglom-1.30-0 suggests no packages.

-- no debconf information

Bug#956710: abiword: Please witch to enchant-2 instead of enchant(1)

[Laurent Bigonville]

Source: abiword
Version: 3.0.2-10
Severity: important
Tags: patch
Control: block 947979 by -1

Hello,

Could you please switch from enchant(1) to the enchant-2 library?

We are trying to get rid of enchant(1) for the bullseye release.

The attached patch should fix this

Kind regards,
Laurent Bigonville

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

Kernel: Linux 5.5.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
diff -Nru abiword-3.0.2/debian/control abiword-3.0.2/debian/control
--- abiword-3.0.2/debian/control2020-04-02 14:46:29.0 +0200
+++ abiword-3.0.2/debian/control2020-04-14 15:22:12.0 +0200
@@ -13,7 +13,7 @@
libchamplain-gtk-0.12-dev,
libebook1.2-dev (>= 3.8.5),
libical-dev (>= 3.0),
-   libenchant-dev,
+   libenchant-2-dev,
libfribidi-dev,
libgcrypt20-dev,
libgirepository1.0-dev,
diff -Nru abiword-3.0.2/debian/patches/enchant2.patch 
abiword-3.0.2/debian/patches/enchant2.patch
--- abiword-3.0.2/debian/patches/enchant2.patch 1970-01-01 01:00:00.0 
+0100
+++ abiword-3.0.2/debian/patches/enchant2.patch 2020-04-14 15:24:39.0 
+0200
@@ -0,0 +1,40 @@
+--- a/configure.ac
 b/configure.ac
+@@ -94,7 +94,7 @@ xp_pkgs="
+ "
+ 
+ # optional deps
+-enchant_req='enchant >= 1.2.0'
++enchant_req='enchant-2 >= 1.2.0'
+ gio_req='gio-2.0'
+ goffice_req='libgoffice-0.10 >= 0.10.0'
+ 
+--- a/src/af/xap/xp/enchant_checker.cpp
 b/src/af/xap/xp/enchant_checker.cpp
+@@ -127,7 +127,7 @@ EnchantChecker::_suggestWord (const UT_U
+   pvSugg->addItem (ucszSugg);
+   }
+ 
+-  enchant_dict_free_suggestions (m_dict, suggestions);
++  enchant_dict_free_string_list (m_dict, suggestions);
+   }
+ 
+   return pvSugg;
+@@ -139,7 +139,7 @@ bool EnchantChecker::addToCustomDict (co
+ 
+   if (word && len) {
+   UT_UTF8String utf8 (word, len);
+-  enchant_dict_add_to_personal (m_dict, utf8.utf8_str(), 
utf8.byteLength());
++  enchant_dict_add (m_dict, utf8.utf8_str(), utf8.byteLength());
+   return true;
+   }
+   return false;
+@@ -150,7 +150,7 @@ bool EnchantChecker::isIgnored (const UT
+   UT_return_val_if_fail (m_dict, false);
+ 
+   UT_UTF8String ignore (toCorrect, toCorrectLen);
+-  return enchant_dict_is_in_session (m_dict, ignore.utf8_str(), 
ignore.byteLength()) != 0;
++  return enchant_dict_is_added (m_dict, ignore.utf8_str(), 
ignore.byteLength()) != 0;
+ }
+ 
+ void EnchantChecker::ignoreWord (const UT_UCSChar *toCorrect, size_t 
toCorrectLen)
diff -Nru abiword-3.0.2/debian/patches/series 
abiword-3.0.2/debian/patches/series
--- abiword-3.0.2/debian/patches/series 2020-04-02 14:46:29.0 +0200
+++ abiword-3.0.2/debian/patches/series 2020-04-14 15:21:47.0 +0200
@@ -11,3 +11,4 @@
 libical3.diff
 build-Don-t-check-for-libecal.patch
 git_build_fix.patch
+enchant2.patch

Bug#883308: libseccomp2 is missing ia64 support

[Kees Cook]

On Tue, Apr 14, 2020 at 02:02:29PM +0200, Gregor Riepl wrote:
> At least on sparc64 and sh4 we have SECCOMP support in kernel, but not
> HAVE_ARCH_SECCOMP_FILTER. Does libseccomp need HAVE_ARCH_SECCOMP_FILTER?

For nearly everything that it gets used for, libseccomp depends on
CONFIG_SECCOMP_FILTER.

-- 
Kees Cook@debian.org

Bug#956711: munin: permissions of /var/log/munin for html/graph_strategy cgi: www-data user should be in groups munin and adm

[Marcel Partap]

Package: munin
Version: 2.0.57-1
Severity: normal

By default, debian's munin is not ready for switching html_strategy and
graph_strategy to cgi because of a lack of access permission for the (apache2)
www-data user on folders /var/lib/munin/cgi-tmp and /var/log/munin .

This can be resolved by allowing the respective owner groups write access
> chmod g+w /var/lib/munin/cgi-tmp /var/log/munin

.. and adding the www-data user to the owning groups for both:
> gpasswd -a www-data munin
> gpasswd -a www-data adm

With this, the cgi strategies work beautifully, including dynazoom.



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

Kernel: Linux 5.5.0-1-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_CRAP, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), 
LANGUAGE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages munin depends on:
ii  cron [cron-daemon]   3.0pl1-135
ii  debconf [debconf-2.0]1.5.73
ii  fonts-dejavu-core2.37-1
ii  init-system-helpers  1.57
ii  libdate-manip-perl   6.78-1
pn  libdigest-md5-perl   
ii  libfile-copy-recursive-perl  0.44-1
ii  libhtml-template-perl2.97-1
ii  libio-socket-inet6-perl  2.72-2
ii  liblog-log4perl-perl 1.49-1
ii  librrds-perl 1.7.2-3
pn  libstorable-perl 
ii  liburi-perl  1.76-1
ii  lsb-base 11.1.0
ii  munin-common 2.0.57-1
ii  netbase  6.1
ii  perl [libtime-hires-perl]5.30.0-9
ii  rrdtool  1.7.2-3+b1
ii  systemd-sysv 245.4-3

Versions of packages munin recommends:
ii  libcgi-fast-perl  1:2.15-1
ii  munin-doc 2.0.51-1
ii  munin-node2.0.57-1

Versions of packages munin suggests:
ii  apache2 [httpd]  2.4.43-1
ii  chromium [www-browser]   80.0.3987.116-1
ii  elinks [www-browser] 0.13.1-1
ii  falkon [www-browser] 3.1.0+dfsg1-6
ii  firefox [www-browser]74.0-1
ii  konqueror [www-browser]  4:19.08.2-2+b1
ii  libapache2-mod-fcgid 1:2.3.9-4
ii  libnet-ssleay-perl   1.88-1+b1
ii  links2 [www-browser] 2.20.2-1+b1
ii  w3m [www-browser]0.5.3-37+b1

-- Configuration Files:
/etc/cron.d/munin changed:
MAILTO=root
*/5 * * * * munin if [ -x /usr/bin/munin-cron ]; then /usr/bin/munin-cron; 
fi
14 10 * * * munin if [ -x /usr/share/munin/munin-limits ]; then 
/usr/share/munin/munin-limits --force --contact nagios --contact old-nagios; fi
27 03 * * * munin htmldir=$({ cat /etc/munin/munin.conf 
/etc/munin/munin-conf.d/* 2>/dev/null || true; } | sed -nE 
's/^\s*htmldir\s+(\S.*)$/\1/p' | tail -1); 
htmldir=${htmldir:-/var/cache/munin/www}; if [ -d "$htmldir" ]; then find 
"$htmldir/" -type f -name "*.html" -mtime +30 -delete; find "$htmldir/" 
-mindepth 1 -type d -empty -delete; fi
32 03 * * * www-data cgitmpdir=$({ cat /etc/munin/munin.conf 
/etc/munin/munin-conf.d/* 2>/dev/null || true; } | sed -nE 
's/^\s*cgitmpdir\s+(\S.*)$/\1/p' | tail -1); 
cgitmpdir=${cgitmpdir:-/var/lib/munin/cgi-tmp}; if [ -d "$cgitmpdir" ]; then 
find "$cgitmpdir/" -type f -mtime +1 -delete; find "$cgitmpdir/" -mindepth 1 
-type d -empty -delete; fi

/etc/munin/apache24.conf changed:
ScriptAlias /munin-cgi/munin-cgi-graph /usr/lib/munin/cgi/munin-cgi-graph
Alias /munin/static/ /var/cache/munin/www/static/

Require local
Options None


Require local

SetHandler fcgid-script


SetHandler cgi-script


ScriptAlias /munin /usr/lib/munin/cgi/munin-cgi-html

/etc/munin/munin.conf changed:
includedir /etc/munin/munin-conf.d
graph_strategy cgi
html_strategy cgi
[base]
address 127.0.0.1
use_node_name yes
[spot]
address 192.168.1.1
use_node_name yes


-- debconf-show failed

Bug#782654: ITP: bazel -- Fast and correct automated build system by Google

[Olek Wojnar]

To those interested in Bazel in Debian:

We just had a very positive discussion with upstream and I think that
finally getting Bazel into Debian is on the horizon. This endeavor is going
to be larger than one person, in the long run if not right at this moment.

Therefore, I would like to create a Bazel packaging team in Debian since a
team approach is what will ensure this build system remains viable and
well-supported even after the short-term goal of helping to get software
into Debian to address the COVID-19 pandemic.

If you are subscribed to this bug and are interested (or know someone who
is), please let me know if you would like to be part of that team in some
capacity. I am happy to continue coordinating this team and I am equally
happy to pass that responsibility on if anyone else has a strong desire to
do that. Since Kyle was previously working this project by himself, I
definitely defer to him if he has the time and desire to lead the new team.

Looking forward to getting a good group of people together who can
contribute to this, to whatever extent they are able!

-Olek

Bug#956119: asterisk: segfault in libspandsp.so.2.0.0 when using Set(FAXOPT(gateway)=yes,30) between SIP and iax

[Bernhard Schmidt]

Control: found -1 1:16.2.1~dfsg-1
Control: forwarded -1 https://issues.asterisk.org/jira/browse/ASTERISK-27981

Hi,

> I tried to extract from the submitter's dmesg line the
> source location of the crash.
> 
> I assume it happened here [1], with
> variable s containing an invalid pointer:
> 
> 0x77f5bb90 in update_rx_timing at t38_gateway.c:2244
> 
> 2242 static void update_rx_timing(t38_gateway_state_t *s, int len)
> 2243 {
> 2244 if (s->core.samples_to_timeout > 0)
> 2245 {
> 
> 
> https://sources.debian.org/src/spandsp/0.0.6+dfsg-2/src/t38_gateway.c/#L2244
> 
> 
> Maybe it is of some help.
> But a proper backtrace like described in following link would probably
> be way better: https://wiki.debian.org/HowToGetABacktrace

Thanks a lot. This looks very much like the backtrace in
https://issues.asterisk.org/jira/browse/ASTERISK-28450

---
Core was generated by `/usr/sbin/asterisk -f -U asterisk -G asterisk
-vvvg -c'.
Program terminated with signal 11, Segmentation fault.
#0  update_rx_timing (s=0x29b28, len=160) at t38_gateway.c:2189
2189if (s->core.samples_to_timeout > 0)
---

The bug itself is marked as duplicate of
https://issues.asterisk.org/jira/browse/ASTERISK-27981, which refers to

https://gerrit.asterisk.org/c/asterisk/+/11434

@Benoit: Can you test with that patch applied?

Bernhard

Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)

[Andreas Tille]

Control: reassign -1 clustalo
Control: retitle -1 "clustalo: Bus error on mipsel"
Control: tags -1 upstream
Control: forwarded -1 clust...@ucd.ie

Hi,

I took over the test done by biopython into the clustalo build time and
autopkgtest.  As Peter assumed this is an issue in clustalo as you can
see in the build log on mipsel here:

   
https://buildd.debian.org/status/fetch.php?pkg=clustalo&arch=mipsel&ver=1.2.4-5&stamp=1586866059&raw=0

...
# Run additional test from python-biopython package to verify that
# this will work as well
src/clustalo -i debian/tests/biopython_testdata/f002 --guidetree-out 
temp_test.dnd -o temp_test.aln --outfmt clustal --force
make[1]: *** [debian/rules:25: override_dh_auto_test-arch] Bus error


Any help from the Debian Mips team would be really welcome.  The
covid-19 effort is occupying all hands for lots of things so we
probably have limited time to debug this kind of issues.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#956711: munin: permissions of /var/log/munin for html/graph_strategy cgi: www-data user should be in groups munin and adm

[devel]

Hello Marcel,

thank you for your bug report!


Am Tue, 14 Apr 2020 16:40:12 +0200
schrieb Marcel Partap :

> By default, debian's munin is not ready for switching html_strategy and
> graph_strategy to cgi because of a lack of access permission for the (apache2)
> www-data user on folders /var/lib/munin/cgi-tmp and /var/log/munin .
> 
> This can be resolved by allowing the respective owner groups write access
> > chmod g+w /var/lib/munin/cgi-tmp /var/log/munin
> [..]
> gpasswd -a www-data munin
> gpasswd -a www-data adm  

are you really sure, that these steps are necessary?

The munin package uses autopkgtests. One of the tested scenarios is the switch
to the CGI-based rendering. The preparations for this step are quite trivial:
* change the strategies to "cgi"
* toggle the enabled line in the apache configuration (as documented there)

(see
https://salsa.debian.org/debian/munin/-/blob/debian/debian/tests/enable_cgi_strategy.inc)

Afterwards it should work. At least the current tests do not fail ...


The permissions should be handled automatically during package installation:

   touch /var/log/munin/munin-cgi-html.log
   chown www-data:adm /var/log/munin/munin-cgi-html.log
   chmod 640 /var/log/munin/munin-cgi-html.log

   touch /var/log/munin/munin-cgi-graph.log
   chown www-data:adm /var/log/munin/munin-cgi-graph.log
   chmod 640 /var/log/munin/munin-cgi-graph.log

   mkdir -p /var/lib/munin/cgi-tmp
   chown munin:www-data /var/lib/munin/cgi-tmp
   chmod 775 /var/lib/munin/cgi-tmp
(see the postinst script)


Maybe you are cleaning up the log directory (e.g. on a read-only system) during
a reboot?
In this case it would indeed fail. I guess, it would be nice for the package to
also work in such situations (e.g. non-permantent /var/log/).

Or do you have another idea, what could be wrong?

Cheers,
Lars

Bug#956615: RM: gmime2.6 -- ROM; new upstream version (gmime 3.0) has been available for years, no reverse deps

[Daniel Kahn Gillmor]

Control: tags 956615 - moreinfo

On Mon 2020-04-13 22:51:04 -0400, Scott Kitterman wrote:
> Except balsa FTBFS on all archs:
>
> https://buildd.debian.org/status/package.php?p=balsa
>
> Please remove the moreinfo tag once this is resolved.

Sorry, missing build dep, which has since been resolved in balsa
2.6.0-2.

Should be ready to go now.

Thanks for keeping an eye on this.

   --dkg


signature.asc
Description: PGP signature

Bug#956712: emacs: https to plain http downgrade after unhandled GNUTLS_E_AGAIN error in TLS1.3 connection

[Heenec]

Package: emacs
Version: 1:26.1+1-3.2+deb10u1
Severity: grave
Tags: security
Justification: user security hole

Dear Maintainer,

When I have tried to install a package from the GNU ELPA repository, I
received a "Bad Request" error. Searching on the Internet for a solution
of this problem led me to this bugreport at debbugs.gnu.org:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34341

I have confirmed, that the bug reported there can be reproduced in my
emacs installation, and that the workaround mentioned there (disabling
TLS1.3) works.

But while playing around with this bug I noticed, that for some reason
after breaking the TLS1.3 connection it makes second connection with
plain http to the port 443 (sic!).

 Steps to reproduce:

1) Run emacs
2) Open scratchpad with "C-x b *scratch*"
3) Write the following snippet and execute it by positioning cursor
after the
last ")" and pressing C-j.
```
(switch-to-buffer (url-retrieve-synchronously "https://duckduckgo.com";)
  (buffer-string))
```

 Results:

A new buffer with following content is opened:
```
HTTP/1.1 400 Bad Request
Server: nginx
Date: Fri, 02 Apr 2020 12:54:12 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 248
Connection: close
X-XSS-Protection: 1;mode=block
X-Content-Type-Options: nosniff
Referrer-Policy: origin
Expect-CT: max-age=0


400 The plain HTTP request was sent to HTTPS
port

400 Bad Request
The plain HTTP request was sent to HTTPS port
nginx


#
```

Also if network traffic was captured with Wireshark, it can be seen,
that breaking of the TLS1.3 connection follows with a plain http request
to port 443 on the same IP address. And the result of this http request
is returned by the url-retrieve-synchronously function.

The same behaviour is seen in network captures of (failing) emacs
package installation process.

Althogh the bug mentioned in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34341 seems to be
currently fixed in upstream emacs 26.3 and 27.1, the related patch fixes
wrong handling of GNUTLS_E_AGAIN error, but not this fallback from https
to plain http. It suggests, that this behaviour may be triggered by
other exceptions.

Heenec



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

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

Versions of packages emacs depends on:
ii  emacs-gtk  1:26.1+1-3.2+deb10u1

emacs recommends no packages.

emacs suggests no packages.

-- no debconf information

Bug#952806: FWIW, cbindgen 0.14.1-1 is already in sid/unstable and perhaps will migrate to testing if tomorrow or day after rust-libc migrates

[shirish शिरीष]

Hi there,

See [1] and [2]

1. https://tracker.debian.org/pkg/rust-libc

2. https://tracker.debian.org/pkg/rust-cbindgen

You can thank Andrej Shadura and Peter Michael Green, while the credit
for the second goes to Sylvestre Ledru.

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#801339: fonts-texgyre: missing glyphs when viewing PDFs via poppler

[Jim Paris]

Hilmar Preuße wrote:
> Am 08.10.2015 um 20:52 teilte Jim Paris mit:
> 
> Hi Jim,
> 
> > When viewing PDFs that do not embed Helvetica, the μ (U+03BC) 
> > character does not render correctly when fonts-texgyre is installed. 
> > For example, this PDF: http://jim.sh/~jim/tmp/bugs/tps62120.pdf
> > 
> > With fonts-texgyre (20150923-1) installed, glyphs are missing:
> > 
> For any reason that bug was invisible to us, sorry late response.
> 
> Your example URL is invalid meanwhile: are you able to reproduce the
> issue w/ latest fonts-texgyre installed? If yes, could you provide a new
> example or a TeX source code?

I've restored the link.

I just reinstalled fonts-texgyre and I do not currently see this
problem (xpdf 3.04-13, fonts-texgyre 20180621-3).  However, I think
this may be because some other system configuration has changed,
because "TeXGyreHeros" is no longer the substitute font that poppler
chooses:

  $ pdffonts -subst tps62120.pdf
  name object ID substitute font
  substitute font file
   - 
 
  Arial-BoldMT 81  0 Arial Negreta  
  /usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf
  ArialMT  83  0 DejaVu Sans
  /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
  Arial-ItalicMT  101  0 Arial Cursiva  
  /usr/share/fonts/truetype/msttcorefonts/Arial_Italic.ttf
  Arial-BoldItalicMT  401  0 Arial Negreta cursiva  
  /usr/share/fonts/truetype/msttcorefonts/Arial_Bold_Italic.ttf
  Helvetica   889  0 NimbusSans-Regular 
  /usr/share/fonts/opentype/urw-base35/NimbusSans-Regular.otf
  Helvetica-Bold  890  0 NimbusSans-Bold
  /usr/share/fonts/opentype/urw-base35/NimbusSans-Bold.otf
  Helvetica   905  0 NimbusSans-Regular 
  /usr/share/fonts/opentype/urw-base35/NimbusSans-Regular.otf
  Helvetica-Bold  906  0 NimbusSans-Bold
  /usr/share/fonts/opentype/urw-base35/NimbusSans-Bold.otf
  Arial-BoldItalicMT  973  0 Arial Negreta cursiva  
  /usr/share/fonts/truetype/msttcorefonts/Arial_Bold_Italic.ttf
  ArialMT 975  0 DejaVu Sans
  /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
  Arial-BoldMT977  0 Arial Negreta  
  /usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf

Let's see...
If I check "fc-match", it seems "TeX Gyre Heros" is still high up on
the list, but "Nimbus Sans" beat it:

  $ fc-match -s Helvetica | head -8
  NimbusSans-Regular.otf: "Nimbus Sans" "Regular"
  n019003l.pfb: "Nimbus Sans L" "Regular"
  texgyreheros-regular.otf: "TeX Gyre Heros" "Regular"
  Arial.ttf: "Arial" "Regular"
  LiberationSans-Regular.ttf: "Liberation Sans" "Regular"
  DejaVuSans.ttf: "DejaVu Sans" "Book"
  DejaVuSans-Bold.ttf: "DejaVu Sans" "Bold"
  DejaVuSans-Oblique.ttf: "DejaVu Sans" "Oblique"

Those Nimbus fonts are coming from package fonts-urw-base35.  If I
remove that package[*], then "TeX Gyre Heros" is back as the PDF font
substitution:

  $ pdffonts -subst tps62120.pdf
  name object ID substitute font
  substitute font file
   - 
 
  Arial-BoldMT 81  0 Arial Negreta  
  /usr/share/fonts/truetype/msttcorefonts/Arial_Bold.ttf
  ArialMT  83  0 DejaVu Sans
  /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
  Arial-ItalicMT  101  0 Arial Cursiva  
  /usr/share/fonts/truetype/msttcorefonts/Arial_Italic.ttf
  Arial-BoldItalicMT  401  0 Arial Negreta cursiva  
  /usr/share/fonts/truetype/msttcorefonts/Arial_Bold_Italic.ttf
  Helvetica   889  0 TeXGyreHeros-Regular   
  /usr/share/texmf/fonts/opentype/public/tex-gyre/texgyreheros-regular.otf
  Helvetica-Bold  890  0 TeXGyreHeros-Bold  
  /usr/share/texmf/fonts/opentype/public/tex-gyre/texgyreheros-bold.otf
  Helvetica   905  0 TeXGyreHeros-Regular   
  /usr/share/texmf/fonts/opentype/public/tex-gyre/texgyreheros-regular.otf
  Helvetica-Bold  906  0 TeXGyreHeros-Bold  
  /usr/share/texmf/fonts/opentype/public/tex-gyre/texgyreheros-bold.otf
  Arial-BoldItalicMT  973  0 Arial Negreta cursiva  
 

Bug#956714: mmdebstrap should skip the emulation check in chrootless mode

[Helmut Grohne]

Package: mmdebstrap
Version: 0.6.1-6
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

Whenever the selected architecture differs from the native architecture
of the system that runs mmdebstrap, mmdebstrap checks whether it can run
the selected architecture. In the majority of cases, this is good and
helps avoid difficult to diagnose issues. However when running in
chrootless mode, we don't actually want to run any binaries from the
target system. For that reason, the emulation check should be skipped in
chrootless mode. Please consider applying the attached patch.

Helmut
--- mmdebstrap-0.6.1.orig/mmdebstrap
+++ mmdebstrap-0.6.1/mmdebstrap
@@ -3095,7 +3095,9 @@ sub main() {
 sparc=> 'sparc',
 sparc64  => 'sparc64',
 };
-if ($hostarch ne $options->{nativearch}) {
+	if ($options->{mode} eq "chrootless") {
+info "skipping emulation check in chrootless mode";
+	} elsif ($hostarch ne $options->{nativearch}) {
 my $withemu = 0;
 my $noemu   = 0;
 {

Bug#956713: autoconf-archive: AX_LUA_HEADERS uses AC_RUN_IFELSE

[Helmut Grohne]

Source: autoconf-archive
Version: 20190106-2.1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:telegram-cli

telegram-cli fails to cross build from source, because it uses
AX_LUA_HEADERS, which happens to use AC_RUN_IFELSE to compute the lua
version. As it turns out, the version is also available as an integer,
which allows using the cross-friendly AC_COMPUTE_INT. The attached patch
updates AX_LUA_HEADERS to use AC_COMPUTE_INT. Please consider applying
it to make telegram-cli cross buildable.

Helmut
--- autoconf-archive-20190106.orig/m4/ax_lua.m4
+++ autoconf-archive-20190106/m4/ax_lua.m4
@@ -524,22 +524,17 @@ AC_DEFUN([AX_LUA_HEADERS],
 [ax_cv_lua_header_version],
 [ _ax_lua_saved_cppflags=$CPPFLAGS
   CPPFLAGS="$CPPFLAGS $LUA_INCLUDE"
-  AC_RUN_IFELSE(
-[ AC_LANG_SOURCE([[
+  AC_COMPUTE_INT(ax_cv_lua_header_version_major,[LUA_VERSION_NUM/100],[AC_INCLUDES_DEFAULT
 #include 
-#include 
-#include 
-int main(int argc, char ** argv)
-{
-  if(argc > 1) printf("%s", LUA_VERSION);
-  exit(EXIT_SUCCESS);
-}
-]])
-],
-[ ax_cv_lua_header_version=`./conftest$EXEEXT p | \
-$SED -n "s|^Lua \(@<:@0-9@:>@\{1,\}\.@<:@0-9@:>@\{1,\}\).\{0,\}|\1|p"`
-],
-[ax_cv_lua_header_version='unknown'])
+],[ax_cv_lua_header_version_major=unknown])
+  AC_COMPUTE_INT(ax_cv_lua_header_version_minor,[LUA_VERSION_NUM%100],[AC_INCLUDES_DEFAULT
+#include 
+],[ax_cv_lua_header_version_minor=unknown])
+  AS_IF([test "x$ax_cv_lua_header_version_major" = xunknown || test "x$ax_cv_lua_header_version_minor" = xunknown],[
+ax_cv_lua_header_version=unknown
+  ],[
+ax_cv_lua_header_version="$ax_cv_lua_header_version_major.$ax_cv_lua_header_version_minor"
+  ])
   CPPFLAGS=$_ax_lua_saved_cppflags
 ])
 

Bug#910685: glibc: please support DPKG_ROOT

[Helmut Grohne]

On Tue, Oct 09, 2018 at 10:09:57PM +0200, Johannes 'josch' Schauer wrote:
> Currently in Debian sid, there are 57 packages that need to be installed
> for the whole Essential:yes set. Most of them Depend (directly or
> indirectly) on libc6. Attached patch adds $DPKG_ROOT to a couple of
> places of the preinst and postinst of libc6 and that will make 37 of
> these 57 install without problems. The patch adds $DPKG_ROOT in more
> places than strictly necessary for just installing packages. For example
> I didn't test the upgrade scenario. If you like, I can prepare a smaller
> patch with only the code paths that I tested.

I think that your approach is not ideal. Much of the code in the libc
scripts is for ensuring that a system is not bricked and that services
continue to work after a libc upgrade. When working with the chrootless
mode, we cannot assume that the running kernel version or other aspects
are relevant to the chroot at hand. In this case, it is much better to
skip the relevant code entirely. Doing so has the additional benefit of
not using debconf at all. When running in chrootless mode, there cannot
be any services running, because they'd have to be chrooted. So we can
simply skip all those checks. The patch becomes quite a bit simpler.

> It would be nice if you could consider applying attached patch because
> it is required for the majority of packages in the Essential:yes set to
> be successfully installed with the --force-script-chrootless mode.
> 
> To test you can run:
> 
> dpkg --root "$target" --log "$target/var/log/dpkg.log" 
> --force-script-chrootless -i libc6_2.27-6.1_amd64.deb

Yes, please. Is there anything blocking this? Without support in glibc,
moving forward is a little difficult. Can you include it soonish?

Helmut
diff --minimal -Nru glibc-2.30/debian/changelog glibc-2.30/debian/changelog
--- glibc-2.30/debian/changelog 2020-03-25 13:56:56.0 +0100
+++ glibc-2.30/debian/changelog 2020-04-14 17:39:34.0 +0200
@@ -1,3 +1,10 @@
+glibc (2.30-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Initial, minimal support for DPKG_ROOT. (Closes: #910685)
+
+ -- Helmut Grohne   Tue, 14 Apr 2020 17:39:34 +0200
+
 glibc (2.30-4) unstable; urgency=medium
 
   [ Aurelien Jarno ]
diff --minimal -Nru glibc-2.30/debian/debhelper.in/libc.postinst 
glibc-2.30/debian/debhelper.in/libc.postinst
--- glibc-2.30/debian/debhelper.in/libc.postinst2020-03-25 
13:36:06.0 +0100
+++ glibc-2.30/debian/debhelper.in/libc.postinst2020-04-14 
17:36:49.0 +0200
@@ -17,11 +17,14 @@
 if [ "$type" = "configure" ]
 then
 # We don't use a registry anymore, remove the old file
-rm -f /etc/ld.so.hwcappkgs
+rm -f "$DPKG_ROOT/etc/ld.so.hwcappkgs"
  
 # /etc/ld.so.nohwcap code:
 __NOHWCAP__
+fi
 
+if [ "$type" = configure -a -z "$DPKG_ROOT" ]
+then
 # Load debconf module if available
 if [ -f /usr/share/debconf/confmodule ] ; then
. /usr/share/debconf/confmodule
diff --minimal -Nru glibc-2.30/debian/debhelper.in/libc.preinst 
glibc-2.30/debian/debhelper.in/libc.preinst
--- glibc-2.30/debian/debhelper.in/libc.preinst 2020-03-25 13:38:38.0 
+0100
+++ glibc-2.30/debian/debhelper.in/libc.preinst 2020-04-14 17:38:54.0 
+0200
@@ -19,7 +19,7 @@
 test $verA -$2 $verB
 }
 
-if [ "$type" != abort-upgrade ]
+if [ "$type" != abort-upgrade -a -z "$DPKG_ROOT" ]
 then
 # Load debconf module if available and usable
 if [ -f /usr/share/debconf/confmodule ] && \
@@ -148,7 +148,7 @@
 fi
 fi
 
-if [ "$type" = upgrade ]
+if [ "$type" = upgrade -a -z "$DPKG_ROOT" ]
 then
 if [ -n "$preversion" ] && [ -x "$(which ischroot)" ] && ! ischroot; then
# NSS authentication trouble guard
@@ -246,8 +246,8 @@
# unconditionally wipe ld.so.cache on major version upgrades; this
# makes those upgrades a bit slower, but is less error-prone than
# hoping we notice every time the cache format is changed upstream
-   rm -f /etc/ld.so.cache
-   rm -f /var/cache/ldconfig/aux-cache
+   rm -f "$DPKG_ROOT/etc/ld.so.cache"
+   rm -f "$DPKG_ROOT/var/cache/ldconfig/aux-cache"
 fi
 fi
 
diff --minimal -Nru glibc-2.30/debian/script.in/nohwcap.sh 
glibc-2.30/debian/script.in/nohwcap.sh
--- glibc-2.30/debian/script.in/nohwcap.sh  2019-08-16 12:57:33.0 
+0200
+++ glibc-2.30/debian/script.in/nohwcap.sh  2020-04-14 17:39:30.0 
+0200
@@ -18,5 +18,5 @@
 # one, we could remove /etc/ld.so.nohwcap. Otherwise, it will be removed
 # when all optimized packages are upgraded or removed.
 if [ "$all_upgraded" = yes ] ; then
-rm -f /etc/ld.so.nohwcap
+rm -f "$DPKG_ROOT/etc/ld.so.nohwcap"
 fi

Bug#782654: ITP: bazel -- Fast and correct automated build system by Google

[Andreas Tille]

Hi Olek,

On Tue, Apr 14, 2020 at 11:27:45AM -0400, Olek Wojnar wrote:
> To those interested in Bazel in Debian:
> ...
> Looking forward to getting a good group of people together who can
> contribute to this, to whatever extent they are able!

while I doubt that I'll be of technical help to work on this package I'd
like to express that I'm extremely happy.  Your effort for bazel which
will finally a big step to get tensorflow in which is a precondition for
several COVID-19 releavant packages is really welcome.

Thanks a lot

  Andreas.

-- 
http://fam-tille.de

Bug#956715: openrc FTCBFS: strips with the wrong strip

[Helmut Grohne]

Source: openrc
Version: 0.40.3-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

openrc fails to cross build from source, because it strips lsb2rcconf
using the build architecture strip. It does so during dh_auto_install,
so it happens to alos break DEB_BUILD_OPTIONS=nostrip as well as
generation of a -dbgsym package. It is best to leave stripping up to
dh_strip. Please consider applying the attached patch.

Helmut
diff --minimal -Nru openrc-0.40.3/debian/changelog 
openrc-0.40.3/debian/changelog
--- openrc-0.40.3/debian/changelog  2019-02-02 16:41:07.0 +0100
+++ openrc-0.40.3/debian/changelog  2020-04-14 17:59:29.0 +0200
@@ -1,3 +1,10 @@
+openrc (0.40.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Defer stripping to dh_strip. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 14 Apr 2020 17:59:29 +0200
+
 openrc (0.40.3-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru openrc-0.40.3/debian/rules openrc-0.40.3/debian/rules
--- openrc-0.40.3/debian/rules  2019-02-02 16:41:07.0 +0100
+++ openrc-0.40.3/debian/rules  2020-04-14 17:59:28.0 +0200
@@ -21,6 +21,7 @@
 export SHLIBDIR = /lib/$(DEB_HOST_MULTIARCH)
 export LIBNAME = lib
 export LIBEXECDIR = /lib/rc
+export STRIP_BINARY = no
 
 ifeq (linux,$(DEB_HOST_ARCH_OS))
 export MKAUDIT = yes

Bug#956716: ITP: r-cran-rematch2 -- Tidy Output from Regular Expression Matching

[Dylan Aïssi]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-rematch2 -- Tidy Output from Regular Expression Matching
Package: wnpp
Owner: Dylan Aïssi 
Severity: wishlist

* Package name: r-cran-rematch2
  Version : 2.1.1
  Upstream Author : Mango Solutions, Gábor Csárdi, Matthew Lincoln
* URL : https://cran.r-project.org/package=rematch2
* License : MIT
  Programming Lang: GNU R
  Description : Tidy Output from Regular Expression Matching
 Wrappers on 'regexpr' and 'gregexpr' to return the match
 results in tidy data frames.

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

Bug#956717: ITP: Mystiq -- Powerful FFmpeg GUI front-end based on Qt5 and writed in C++

[Pablo Mestre]

Package: wnpp
Version: 20.03.23-1; reported 2020-04-14
Severity: wishlist

* Package name: mystiq
Version: 20.03.23
Upstream Author: Maikel Llamaret Heredia 
* URL: https://mystiqapp.com/
* License:  GPL,
Description: Powerful media converter. FFmpeg can read audio and video
files in various
 formats and convert them into other formats. MystiQ features an intuitive
 graphical interface and a rich set of presets to help you convert media
 files within a few clicks. Advanced users can also adjust conversion
 parameters in detail.

-- System Information

Format: 1.8
Date: Mon, 06 Apr 2020 16:34:51 -0300
Source: mystiq
Binary: mystiq mystiq-dbgsym
Architecture: source amd64
Version: 20.03.23-1
Distribution: unstable
Urgency: medium
Maintainer: Pablo Mestre Drake 
Changed-By: Pablo Mestre Drake 
Description:
 mystiq - Powerful FFmpeg GUI front-end based on Qt5 and writed in C++
Changes:
 mystiq (20.03.23-1) unstable; urgency=medium
 .
   * New upstream version 20.03.23
   * Add salsa-ci.yml copied from Debian pipeline for Developers
Checksums-Sha1:
 3dcd45985c5da7d9017d4533e6e3164a9289b9b2 1281 mystiq_20.03.23-1.dsc
 b7a4428bae0a946dfba23d030f47403400615ef2 896299 mystiq_20.03.23.orig.tar.gz
 b315d8e6dfe6d27e77ea90cd068ac3ad31cdaa7f 2624
mystiq_20.03.23-1.debian.tar.xz
 525f6f8107d4aeddf74afbeda13898df0fa728c5 3209308
mystiq-dbgsym_20.03.23-1_amd64.deb
 f2dcd3f2998aa3a60f1e08e6dd3c2ec6e9fefe19 10925
mystiq_20.03.23-1_amd64.buildinfo
 58b746a0c9d8086501bc82099d77f02d27bd3dab 603780 mystiq_20.03.23-1_amd64.deb
Checksums-Sha256:
 dd8106c583a77992aabb2513dea763c7ac711aa3348b4eef3c00660cad204cda 1281
mystiq_20.03.23-1.dsc
 cfb84faebf68876733624e4500d4b6c654bc01cb75fd6eddd9efa8337816d22e 896299
mystiq_20.03.23.orig.tar.gz
 a35f47ac538ae4a2e6a3427e3bc291a5346acb5f28f05739399a4de44811a654 2624
mystiq_20.03.23-1.debian.tar.xz
 6872929df3eae59abad4e37b610d4f8525f174fbd132096df6e2646bdb4f3c8f
3209308 mystiq-dbgsym_20.03.23-1_amd64.deb
 6563fe353ef20dd1697e7ff32b69be48404b35ebfcfadbaa9f07143b65a388f8 10925
mystiq_20.03.23-1_amd64.buildinfo
 44f0809823516910bdf8b175aa4d139012100f273300b4738d50a4fffc6fe4e4 603780
mystiq_20.03.23-1_amd64.deb
Files:
 76411d956ea5237f8a7ed8264b9884b7 1281 video optional mystiq_20.03.23-1.dsc
 d6e3babb0be21ae7592f4c313cc6edac 896299 video optional
mystiq_20.03.23.orig.tar.gz
 00763dac5eba71b1ff115c0d906c9e79 2624 video optional
mystiq_20.03.23-1.debian.tar.xz
 00bd186be6aadf3b36564d7105257f54 3209308 debug optional
mystiq-dbgsym_20.03.23-1_amd64.deb
 e15f6b2d3055cb8b891283a460278e35 10925 video optional
mystiq_20.03.23-1_amd64.buildinfo
 7a2fb34f26ea209c03afa99a8a38c250 603780 video optional
mystiq_20.03.23-1_amd64.deb