date:20210826

Source: nim
Version: 1.4.8-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=nim=armhf=1.4.8-2=1629152447=0

...
   dh_auto_configure -a
install -d /<>/debian/.debhelper/generated/_source/home
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
echo "running make to build ./bin/nim from csources"
running make to build ./bin/nim from csources
PATH=./bin/:$PATH  make -j
make[2]: Entering directory '/<>'
makefile:164: *** unknown processor: armv8l.  Stop.


The uname usage in tools/niminst/makefile.nimf is fragile.

Adding cases for armv8l and armv9l might work due to the Debian buildds
using setarch, without that a 32bit on a 64bit system would even be
misdetected as arm64.

Bug#983427: libpam-runtime: please add support for DPKG_ROOT

2021-08-26 Thread Sam Hartman

> "Johannes" == Johannes 'josch' Schauer  writes:

Johannes> diff --git a/debian/libpam-runtime.postinst

I think that your patch ends up with things like $confdir set to
"//etc/pam.d" when $DPKG_ROOT is empty.  You get one slash from the
initialization of the variable and one slash from the separator in the
code you added.


Please review the following alternate patch hopefully before it makes
its way into testing:

commit b296f47cab5c8d97e2d57ef35694ba8328a9477f
Author: Sam Hartman 
Date:   Thu Aug 26 14:17:22 2021 -0600

pam-auth-update: support DPKG_ROOT

Patch from Johannes 'josch' Schauer to implement a --root argument to
pam-auth-update and to use it in the call in libpam-runtime.
* debian/local/pam-auth-update: support --root

* debian/libpam-runtime.postinst: call with --root $DPKG_ROOT

diff --git a/debian/changelog b/debian/changelog
index 848f13c0..96dd28fc 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -5,6 +5,8 @@ pam (1.4.0-10) UNRELEASED; urgency=medium
   * Include upstream patch not to use crypt_checksalt; without this
 passwords set prior to bullseye were considered expired, Closes:
 #992848
+  * Support DPKG_ROOT for pam-auth-update, thanks Johannes 'josch' Schauer
+Closes: #983427
 
  -- Sam Hartman   Thu, 26 Aug 2021 13:43:23 -0600
 
diff --git a/debian/libpam-runtime.postinst b/debian/libpam-runtime.postinst
index 518e8d24..053fdae2 100644
--- a/debian/libpam-runtime.postinst
+++ b/debian/libpam-runtime.postinst
@@ -29,7 +29,7 @@ then
done
 fi
 
-pam-auth-update --package $force
+pam-auth-update --root "$DPKG_ROOT" --package $force
 
 if [ -n "$force" ]; then
rm -f /etc/pam.d/common-auth.pam-old \
diff --git a/debian/local/pam-auth-update b/debian/local/pam-auth-update
index 5b3c8a07..6c4134bb 100644
--- a/debian/local/pam-auth-update
+++ b/debian/local/pam-auth-update
@@ -88,6 +88,11 @@ while ($#ARGV >= 0) {
$force = 1;
} elsif ($opt eq '--package') {
$package = 1;
+} elsif ($opt eq '--root') {
+my $rootdir = shift @ARGV;
+$savedir = "${rootdir}$savedir";
+$confdir = "${rootdir}$confdir";
+   $inputdir = "${rootdir}$inputdir";
} elsif ($opt eq '--remove') {
while ($#ARGV >= 0) {
last if ($ARGV[0] =~ /^--/);


signature.asc
Description: PGP signature

Bug#993049: bullseye-pu: package rpki-trust-anchors/20210817-1+deb11u1

2021-08-26 Thread Marco d'Itri

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

rpki-trust-anchors is a data package containing public keys, similar to 
dns-root-data, which are used by RPKI validators (cfrpki, 
fort-validator, rpki-client, stayrtr).
A stable update is needed because an https URL was finally added to the 
LACNIC trust anchor. This allows the software currently in stable to use 
https to download the certificates instead of the problematic and 
deprecated rsync method.
Also, the same package from testing which I have rebuilt here gained a
new debconf translation.

-- 
ciao,
Marco
diff -Nru rpki-trust-anchors-20210417/debian/changelog rpki-trust-anchors-20210817/debian/changelog
--- rpki-trust-anchors-20210417/debian/changelog	2021-04-17 11:55:56.0 +0200
+++ rpki-trust-anchors-20210817/debian/changelog	2021-08-27 00:21:41.0 +0200
@@ -1,3 +1,15 @@
+rpki-trust-anchors (20210817-1+deb11u1) bullseye; urgency=medium
+
+  * Rebuilt for the stable distribution.
+
+ -- Marco d'Itri   Fri, 27 Aug 2021 00:21:41 +0200
+
+rpki-trust-anchors (20210817-1) unstable; urgency=medium
+
+  * Added the https URL to the LACNIC TAL.
+
+ -- Marco d'Itri   Tue, 17 Aug 2021 01:03:51 +0200
+
 rpki-trust-anchors (20210417-1) unstable; urgency=medium
 
   * Updated the https URL for the APNIC TAL.
diff -Nru rpki-trust-anchors-20210417/debian/control rpki-trust-anchors-20210817/debian/control
--- rpki-trust-anchors-20210417/debian/control	2021-04-17 11:53:53.0 +0200
+++ rpki-trust-anchors-20210817/debian/control	2021-08-17 00:53:56.0 +0200
@@ -2,7 +2,7 @@
 Section: net
 Priority: optional
 Maintainer: Marco d'Itri 
-Standards-Version: 4.4.1.1
+Standards-Version: 4.5.1.0
 Rules-Requires-Root: no
 Build-Depends: debhelper-compat (= 12), po-debconf
 Vcs-Git: https://salsa.debian.org/md/rpki-trust-anchors.git
diff -Nru rpki-trust-anchors-20210417/debian/po/es.po rpki-trust-anchors-20210817/debian/po/es.po
--- rpki-trust-anchors-20210417/debian/po/es.po	1970-01-01 01:00:00.0 +0100
+++ rpki-trust-anchors-20210817/debian/po/es.po	2021-08-17 00:39:31.0 +0200
@@ -0,0 +1,47 @@
+# rpki-trust-anchors po-debconf translation to Spanish.
+# Copyright (C) 2021
+# This file is distributed under the same license as the rpki-trust-anchors package.
+# Camaleón , 2021.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: rpki-trust-anchors\n"
+"Report-Msgid-Bugs-To: rpki-trust-anch...@packages.debian.org\n"
+"POT-Creation-Date: 2019-12-14 17:54+0100\n"
+"PO-Revision-Date: 2021-04-18 10:31+0200\n"
+"Last-Translator: Camaleón \n"
+"Language-Team: Debian Spanish \n"
+"Language: es\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Type: boolean
+#. Description
+#: ../rpki-trust-anchors.templates:1001
+msgid "Do you accept the ARIN Relying Party Agreement (RPA)?"
+msgstr "¿Acepta el acuerdo de confianza (Relying Party Agreement, RPA) de ARIN?"
+
+#. Type: boolean
+#. Description
+#: ../rpki-trust-anchors.templates:1001
+msgid ""
+"ARIN forbids third parties from distributing the Trust Anchor Locator (TAL) "
+"for their RPKI repository, hence this package can download it only if you "
+"will agree to ARIN's conditions."
+msgstr ""
+"ARIN prohíbe la distribución a terceras partes del localizador de ancla de "
+"confianza (Trust Anchor Locator, TAL) desde su repositorio RPKI, por lo que "
+"solo puede descargar este paquete si acepta las condiciones de ARIN."
+
+#. Type: boolean
+#. Description
+#: ../rpki-trust-anchors.templates:1001
+msgid ""
+"If you want that this package automatically download and installs the ARIN "
+"TAL, then you need to accept the ARIN Relying Party Agreement (RPA): https://;
+"www.arin.net/resources/manage/rpki/rpa.pdf ."
+msgstr ""
+"Si desea que este paquete se descargue automáticamente e instale el TAL de "
+"ARIN, tiene que aceptar el acuerdo de confianza de ARIN (Relying Party "
+"Agreement, RPA): «https://www.arin.net/resources/manage/rpki/rpa.pdf».;
\ Manca newline alla fine del file
diff -Nru rpki-trust-anchors-20210417/tals/lacnic.tal rpki-trust-anchors-20210817/tals/lacnic.tal
--- rpki-trust-anchors-20210417/tals/lacnic.tal	2021-04-17 03:31:46.0 +0200
+++ rpki-trust-anchors-20210817/tals/lacnic.tal	2021-08-17 00:42:23.0 +0200
@@ -1,3 +1,4 @@
+https://rrdp.lacnic.net/ta/rta-lacnic-rpki.cer
 rsync://repository.lacnic.net/rpki/lacnic/rta-lacnic-rpki.cer
 
 MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqZEzhYK0+PtDOPfub/KR


signature.asc
Description: PGP signature

Bug#685264: merge bugs 685264, 705155 and 746206?

Shouldn't these bugs be merged?

685264: debbugs: obey “Control” field in pseudoheader of messages to 
‘nnn-d...@bugs.debian.org’
705155: allow Control: commands at -done and -forwarded
746206: Control: pseudoheaders do not work for -done bugs; finish() called too 
early

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#992604: closed by Debian FTP Masters (reply to Dylan Aïssi ) (Bug#992604: fixed in wireplumber 0.4.2-2)

On Thu, 2021-08-26 at 11:23 +0200, Dylan Aïssi wrote:

> Sorry to hear that it doesn't work for you.

Reading the dpkg-maintscript-helper manual page, it appears the value
for prior-version for wireplumber should have been 0.4.2-2~ instead of
0.4.2-1~ but if you plan to upload a -3 it should be 0.4.2-3~ since:

   
https://manpages.debian.org/bullseye/dpkg/dpkg-maintscript-helper.1.en.html#COMMON_PARAMETERS
   
   If the conffile has not been shipped for several versions, and you are
   now modifying the maintainer scripts to clean up the obsolete file,
   prior-version should be based on the version of the package that you
   are now preparing, not the first version of the package that lacked the
   conffile. This applies to all other actions in the same way.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#993066: ITP: python-certbot-dns-standalone -- Standalone (integrated DNS server) DNS plugin for Certbot

2021-08-26 Thread Linus Vanas

Package: wnpp
Severity: wishlist
Owner: Linus Vanas 
X-Debbugs-Cc: debian-de...@lists.debian.org, li...@vanas.fi

* Package name: python-certbot-dns-standalone
  Version : 1.0.3
  Upstream Author : Lauri Keel 
* URL : https://github.com/siilike/certbot-dns-standalone
* License : Apache-2.0
  Programming Lang: Python
  Description : Standalone (integrated DNS server) DNS plugin for Certbot

This Certbot plugin enables automating DNS-validation (required for wildcard 
certificates)
when the nameservers aren't supported by other plugins.

I intend to maintain this package, presumably under the Debian Let's Encrypt 
Team.
IANADD so I will need a sponsor.

Bug#911560: networking fails with A20-OLinuXino-Lime2-eMMC Rev. G2 and bullseye u-boot and -kernel

2021-08-26 Thread Andreas B. Mundt

Control: retitle -1 A20-OLinuXino-Lime2-(eMMC): Rev. K, G2: very poor/no 
ethernet performance


Hi all,

the last days, I tried upgrading two A20-OLinuXino-Lime2 boards to bullseye.
After booting the bullseye kernel, 5.10.46-4 (2021-08-03), the network did 
not work anymore: The interface shows up (IIRC, even a link is detected),
but any attempts to connect (DHCP) fail.  

After playing with different delays following [1], I succeeded with 
CONFIG_GMAC_TX_DELAY=4, where both boards seem to work fine. I also played a
bit with iperf3:  At higher bitrates (> approx. 200Mbits/s) more and more 
retries seem to be needed.  So the issue this bug is about seems to affect
also the G2 revision boards that worked fine so far.

Best regards,

  Andi


[1] 
https://wiki.debian.org/InstallingDebianOn/Allwinner#Olimex_A20-OLinuXino-LIME2_rev._K.3B_rev._G2_and_bullseye_kernel

Bug#993044: libxcrypt breaks existing password hashes

2021-08-26 Thread Sam Hartman

package: libxcrypt
version: 1:4.4.22-1
severity: serious
justification: breaks login

See bug #992848.
Because of the way libpam0g calls libxcrypt any existing sha256 hash
will be rejected at login as expired.
I'm going to fix this in pam using the linux-pam upstream fix, but
libxcrypt should not migrate to testing before the fixed pam is in
testing.

This bug is intended to block that migration.
Feel free to do something else that blocks the migration.
If this bug is still open when libpam migrates, I'll close it.


signature.asc
Description: PGP signature

Bug#977790: (no subject)

2021-08-26 Thread unxed

Please update far2l debian package 
https://mentors.debian.net/package/far2l/


as recent far2l has license-problem-convert-utf-code problem fixed 
(ConvertUTF is removed).


Thanks!

Bug#993050: Automatic login uses GNOME on X11 rather than Wayland

2021-08-26 Thread Josh Triplett

Package: gdm3
Version: 3.38.2.1-1
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

I enabled automatic login in gdm3, by adding this to
/etc/gdm3/daemon.conf:

AutomaticLoginEnable=True
AutomaticLogin=josh

After doing so, I get automatically logged in, but running a
GNOME-on-X11 session.

If I log out, and manually log in, I can select a GNOME on Wayland
session. But automatic logins don't seem to use GNOME on Wayland.

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

Kernel: Linux 5.13.0-trunk-amd64 (SMP w/8 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gdm3 depends on:
ii  accountsservice   0.6.55-3
ii  adduser   3.118
ii  dbus  1.12.20-2
ii  dconf-cli 0.38.0-2
ii  dconf-gsettings-backend   0.38.0-2
ii  debconf [debconf-2.0] 1.5.77
ii  gir1.2-gdm-1.03.38.2.1-1
ii  gnome-session [x-session-manager] 40.1.1-1
ii  gnome-session-bin 40.1.1-1
ii  gnome-session-common  40.1.1-1
ii  gnome-settings-daemon 3.38.2-1
ii  gnome-shell   3.38.6-1
ii  gnome-terminal [x-terminal-emulator]  3.40.3-1
ii  gsettings-desktop-schemas 3.38.0-2
ii  libaccountsservice0   0.6.55-3
ii  libaudit1 1:3.0.5-1
ii  libc6 2.31-17
ii  libcanberra-gtk3-00.30-7+b1
ii  libcanberra0  0.30-7+b1
ii  libgdk-pixbuf-2.0-0   2.42.6+dfsg-2
ii  libgdm1   3.38.2.1-1
ii  libglib2.0-0  2.68.4-1
ii  libglib2.0-bin2.68.4-1
ii  libgtk-3-03.24.30-2
ii  libkeyutils1  1.6.1-2
ii  libpam-modules1.4.0-9
ii  libpam-runtime1.4.0-9
ii  libpam-systemd247.9-1
ii  libpam0g  1.4.0-9
ii  librsvg2-common   2.50.3+dfsg-1
ii  libselinux1   3.1-3
ii  libsystemd0   247.9-1
ii  libx11-6  2:1.7.2-1
ii  libxau6   1:1.0.9-1
ii  libxcb1   1.14-3
ii  libxdmcp6 1:1.1.2-3
ii  lsb-base  11.1.0
ii  policykit-1   0.105-31
ii  procps2:3.3.17-5
ii  ucf   3.0043
ii  x11-common1:7.7+23
ii  x11-xserver-utils 7.7+8

Versions of packages gdm3 recommends:
ii  at-spi2-core2.40.3-3
ii  desktop-base11.0.3
ii  x11-xkb-utils   7.7+5
pn  xserver-xephyr  
ii  xserver-xorg1:7.7+23
ii  zenity  3.32.0-7

Versions of packages gdm3 suggests:
pn  gnome-orca
pn  libpam-fprintd
ii  libpam-gnome-keyring  40.0-2

-- Configuration Files:
/etc/gdm3/daemon.conf changed:
[daemon]
AutomaticLoginEnable=True
AutomaticLogin=josh
[security]
[xdmcp]
[chooser]
[debug]


-- debconf information:
* shared/default-x-display-manager: gdm3
  gdm3/daemon_name: /usr/sbin/gdm3

Bug#993051: avahi-daemon CPU usage increases over time

2021-08-26 Thread Ryan Armstrong


Package: avahi-daemon
Version: 0.8-5
Severity: normal

Dear Maintainer,

After upgrading to Debian Bullseye, I noticed that the Avahi CPU usage on my 
server machine was
quite high (eventually 100% of one core). After resetting Avahi, the CPU usage 
was normal then
eventually increased over time again until it was again rather high. The
increase appears to be (very roughly) 1 or 2% per hour on my rather humble 
Intel(R) Celeron(R)
CPU 4205U @ 1.80GHz.

Checking the journal, I only see the following sorts of lines:

Aug 25 16:21:30 zeta avahi-daemon[31]: avahi_normalize_name() failed.
Aug 25 16:21:30 zeta avahi-daemon[31]: avahi_key_new() failed.
Aug 25 16:21:30 zeta avahi-daemon[31]: avahi_normalize_name() failed.
Aug 25 16:21:30 zeta avahi-daemon[31]: avahi_key_new() failed.
Aug 25 16:21:31 zeta avahi-daemon[31]: avahi_normalize_name() failed.
Aug 25 16:21:31 zeta avahi-daemon[31]: avahi_key_new() failed.

Which was around the time I turned on another machine on my network.
However, the timing was not aligned with when Avahi CPU usage increased.
Instead, it seems to be aligned with when I turn on my printer, but nothing
of note was printed in the log when that happened.

Is there any means for me to gather additional information to help
diagnose this problem?

Thanks,
Ryan

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

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

Versions of packages avahi-daemon depends on:
ii  adduser  3.118
ii  bind9-host [host]1:9.16.15-1
ii  dbus 1.12.20-2
ii  init-system-helpers  1.60
ii  libavahi-common3 0.8-5
ii  libavahi-core7   0.8-5
ii  libc62.31-13
ii  libcap2  1:2.44-1
ii  libdaemon0   0.14-7.1
ii  libdbus-1-3  1.12.20-2
ii  libexpat12.2.10-2
ii  lsb-base 11.1.0

Versions of packages avahi-daemon recommends:
ii  libnss-mdns  0.14.1-2

Versions of packages avahi-daemon suggests:
pn  avahi-autoipd  

-- no debconf information

Bug#992034: installation-guide: Include a note on how to change init system during install

2021-08-26 Thread Holger Wansing

Hi,

Am 26. August 2021 09:24:58 MESZ schrieb Matthew Vernon :
>Hi,
>
>Could someone merge 
>https://salsa.debian.org/installer-team/installation-guide/-/merge_requests/15 
>please?
>
>It's the smaller change that folk asked for :)

I wonder if "the easiest time to select an alternative init system is during 
the 
installation process" is correct English.

Maybe better "the best time ... " ?

Asking debian-l10n-english for advise.

@debian-l10n-english: 
Hi all, could someone please comment on the merge request
mentioned above?

Thanks

Holger



-- 
Sent from /e/ OS on Fairphone3

Bug#993055: monit: incorrect comment in /etc/monit/monitrc

Package: monit
Version: 1:5.28.0-3
Severity: normal

I can see in the monitrc file:

set daemon  120 # check services at 30 seconds intervals

That's 2 minutes, not 30 seconds.

The error comes from debian/patches/010_monitrc.patch, which modifes
the value, but not the comment:

-set daemon  30  # check services at 30 seconds intervals
+set daemon  120 # check services at 30 seconds intervals

-- Package-specific info:

Monit config file /etc/monit/monitrc is *NOT* readable by reportbug.
Please, consider to rerun reportbug as root and *carefully* examine
reportbug's output (e.g., monitrc content), before sending it out.

Contents of /etc/monit/ directory:
/etc/monit:
total 68
drwxr-xr-x 2 root root  4096 2021-08-27 03:01:07 conf-available
drwxr-xr-x 2 root root  4096 2015-12-05 21:19:30 conf-enabled
drwxr-xr-x 2 root root  4096 2020-01-04 22:11:10 conf.d
-rw--- 1 root root 13175 2020-08-03 11:01:55 monitrc
drwxr-xr-x 2 root root  4096 2021-07-14 02:13:13 monitrc.d
-rw--- 1 root root 13110 2020-07-31 13:12:44 monitrc.dpkg-dist
-rw--- 1 root root 13500 2021-08-26 14:54:26 monitrc.dpkg-new
drwxr-xr-x 2 root root  4096 2021-08-27 03:00:20 templates

/etc/monit/conf-available:
total 60
-rw-r--r-- 1 root root  481 2015-12-05 21:13:49 acpid
-rw-r--r-- 1 root root  640 2015-12-05 21:13:49 apache2
-rw-r--r-- 1 root root  455 2015-12-05 21:13:49 at
-rw-r--r-- 1 root root  691 2015-12-05 21:13:49 cron
-rw-r--r-- 1 root root  602 2015-12-05 21:13:49 mdadm
-rw-r--r-- 1 root root  669 2015-12-05 21:13:49 memcached
-rw-r--r-- 1 root root  703 2015-12-05 21:13:49 mysql
-rw-r--r-- 1 root root  521 2015-12-05 21:13:49 nginx
-rw-r--r-- 1 root root  471 2015-12-05 21:13:49 openntpd
-rw-r--r-- 1 root root 1200 2020-07-31 13:12:44 openssh-server
-rw-r--r-- 1 root root  683 2015-12-05 21:13:49 pdns-recursor
-rw-r--r-- 1 root root 1426 2018-12-21 09:32:54 postfix
-rw-r--r-- 1 root root  869 2016-03-22 16:43:44 rsyslog
-rw-r--r-- 1 root root  501 2015-12-05 21:13:49 smartmontools
-rw-r--r-- 1 root root  306 2016-02-04 15:03:50 snmpd

/etc/monit/conf-enabled:
total 0

/etc/monit/conf.d:
total 4
-rw-r--r-- 1 root root 357 2020-01-04 22:11:10 eth0

/etc/monit/monitrc.d:
total 64
-rw-r--r-- 1 root root  481 2015-06-09 15:52:48 acpid
-rw-r--r-- 1 root root  640 2015-06-09 15:52:48 apache2
-rw-r--r-- 1 root root  455 2015-06-09 15:52:48 at
-rw-r--r-- 1 root root  691 2015-06-09 15:52:48 cron
-rw-r--r-- 1 root root  403 2016-12-09 15:37:54 fail2ban
-rw-r--r-- 1 root root  602 2015-06-09 15:52:48 mdadm
-rw-r--r-- 1 root root  669 2015-06-09 15:52:48 memcached
-rw-r--r-- 1 root root  703 2015-06-09 15:52:48 mysql
-rw-r--r-- 1 root root  521 2015-06-09 15:52:48 nginx
-rw-r--r-- 1 root root  471 2015-06-09 15:52:48 openntpd
-rw-r--r-- 1 root root  950 2015-06-09 15:52:48 openssh-server
-rw-r--r-- 1 root root  683 2015-06-09 15:52:48 pdns-recursor
-rw-r--r-- 1 root root 1421 2015-06-09 15:52:48 postfix
-rw-r--r-- 1 root root  867 2015-06-09 15:52:48 rsyslog
-rw-r--r-- 1 root root  501 2015-06-09 15:52:48 smartmontools
-rw-r--r-- 1 root root  310 2015-06-09 15:52:48 snmpd

/etc/monit/templates:
total 24
-rw-r--r-- 1 root root 164 2015-06-09 15:52:48 rootbin
-rw-r--r-- 1 root root 164 2021-08-26 14:52:02 rootbin.dpkg-new
-rw-r--r-- 1 root root 160 2015-06-09 15:52:48 rootrc
-rw-r--r-- 1 root root 160 2021-08-26 14:52:02 rootrc.dpkg-new
-rw-r--r-- 1 root root 164 2015-06-09 15:52:48 rootstrict
-rw-r--r-- 1 root root 164 2021-08-26 14:52:02 rootstrict.dpkg-new


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages monit depends on:
ii  init-system-helpers  1.60
ii  libc62.31-17
ii  libcrypt11:4.4.25-1
ii  libpam0g 1.4.0-9
ii  libssl1.11.1.1l-1
ii  lsb-base 11.1.0
ii  zlib1g   1:1.2.11.dfsg-2

monit recommends no packages.

Versions of packages monit suggests:
ii  postfix [mail-transport-agent]  3.5.6-1+b1
pn  sysvinit-core   

-- Configuration Files:
/etc/monit/monitrc [Errno 13] Permission denied: '/etc/monit/monitrc'

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#993064: gpaste: Please update to 3.40

Source: gpaste
Version: 3.38.6-1
Severity: important

gpaste 3.40 says it's compatible with gnome-shell 40 but not with
earlier releases of gnome-shell.

Thanks,
Jeremy Bicha

Bug#993041: libopenmpi3: Overwriting file which is also in package libopenmpi-dev

Package: libopenmpi3
Version: 4.1.1-2
Severity: serious

...
Unpacking libopenmpi3:amd64 (4.1.1-2) over (4.1.0-10) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-o2pk7b/32-libopenmpi3_4.1.1-2_amd64.deb (--unpack):
 trying to overwrite 
'/usr/lib/x86_64-linux-gnu/openmpi/lib/libopen-orted-mpir.so', which is also in 
package libopenmpi-dev:amd64 4.1.1-2
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
...

Bug#992694: reprotest: kernel variation makes ldconfig abort with message "FATAL: Kernel too old"

2021-08-26 Thread Baptiste Beauplat

On 2021/08/26 04:25 PM, Mattia Rizzolo wrote:
> 
> What would you say about this patch:
> 
> |--- a/README.rst
> |+++ b/README.rst
> |@@ -378,9 +378,9 @@ mechanism to vary the system time.
> | Kernel
> | --
> |
> |-The "kernel" variation is currently not working for RPM based packages. 
> While
> |-building with this variation enabled, the tool 
> `/usr/lib/rpm/redhat/brp-ldconfig`
> |-compains about `FATAL: kernel too old` and aborts the build.
> |+The "kernel" variation is currently not working for RPM based packages and 
> other
> |+build process requiring `ldconfig`.  While building with this variation 
> enabled,
> |+`ldconfig` complains about `FATAL: kernel too old` and aborts the build.
> |
> | Avoid sudo(1) password prompts
> | ==

Looks good to me.

> Besides potentially better identifying which versions of ldconfig are
> effectively broken, I don't think we could do much else.

IIRC, the change was introduced by

https://salsa.debian.org/glibc-team/glibc/-/commit/2d7aa68d5d30a203b61b551432efcefac7413885#98f7bc9994884d56cdc1b30b364e50f8800dbc07_147_147

which was packaged with glibc-2.25.

I agree. A possibility would be to introduce a '--uname-3.2' to setarch
and I don't think, for the number of packages using ldconfig at build
time, this is worth the trouble (specially since upstream might not be
interested by it).

-- 
Baptiste Beauplat - lyknode


signature.asc
Description: PGP signature

Bug#993040: htscodecs FTBFS on i386

Source: htscodecs
Version: 1.1.1-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=htscodecs=i386=1.1.1-1=162111=0

...
mkdir -p  debian/libhtscodecs-dev/usr/lib/i686-linux-gnu
mv debian/tmp/usr/lib/i686-linux-gnu/libhtscodecs.a 
debian/libhtscodecs-dev/usr/lib/i686-linux-gnu/
mv: cannot stat 'debian/tmp/usr/lib/i686-linux-gnu/libhtscodecs.a': No such 
file or directory
make[1]: *** [debian/rules:26: override_dh_auto_install] Error 1


debian/rules should use DEB_HOST_MULTIARCH instead of DEB_TARGET_GNU_TYPE.

Bug#993045: Please bring back the -unsafe-string switch

2021-08-26 Thread Julien Puydt

Package: ocaml
Version: 4.11.1-4

a part of scilab (modelica) is written in OCaml, but needs the -unsafe-
string switch ; unfortunately:

/usr/bin/ocaml: OCaml has been configured with -force-safe-string: -
unsafe-string is not available.

Can you please re-enable unsafe strings?

Thanks,

J.Puydt

Bug#979047: RM: pepperflashplugin-nonfree -- RoQA; No longer work; upstream eol

2021-08-26 Thread Andreas Beckmann


Control: reassign -1 ftp.debian.org

On 15/01/2021 17.12, Andreas Beckmann wrote:

As pointed out in #978954, its better to replace it by a dummy with the
broken download/install functionality removed to ensure clean upgrades.


That was shipped in bullseye and buster.


So let's postpone the removal to bookworm.


We can do this now.


Andreas

Bug#993053: python3-flasgger: bad formatting of summary with MK_SANITIZER

2021-08-26 Thread Francesco Potortì

Package: python3-flasgger
Version: 0.9.5+dfsg.2-1
Severity: normal
X-Debbugs-Cc: none, Francesco Potortì 

when using the MK_SANITIZER the summary of each endpoint appears
embedded between  and 

Please write to me in private get a link to the API I am documenting to
see an example of this behaviour

-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-proposed-updates'), (101, 
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-flasgger depends on:
ii  libjs-jquery3.5.1+dfsg+~3.5.5-7
ii  python3 3.9.2-3
ii  python3-flask   1.1.2-2
ii  python3-jsonschema  3.2.0-3
ii  python3-mistune 0.8.4-4
ii  python3-six 1.16.0-2
ii  python3-yaml5.3.1-5

python3-flasgger recommends no packages.

python3-flasgger suggests no packages.

-- no debconf information

Bug#993065: gnome-shell-extension-xrdesktop: Please update for gnome-shell 40

Source: gnome-shell-extension-xrdesktop
Version: 0.14.0-3
Severity: important

git master appears to be compatible with gnome-shell 3.38 and 40.

Thanks,
Jeremy Bicha

Bug#911560: networking fails with A20-OLinuXino-Lime2-eMMC Rev. G2 and bullseye u-boot and -kernel

2021-08-26 Thread Jonas Smedegaard

Control: retitle -1 A20-OLinuXino-Lime2-eMMC Rev. K: very poor ethernet 
performance

Hi Andreas,

Quoting Andreas B. Mundt (2021-08-26 20:01:16)
> Control: retitle -1 A20-OLinuXino-Lime2-(eMMC): Rev. K, G2: very poor/no 
> ethernet performance

Please re-post your info about rev.G board to bug#927397 - thanks!


 - Jonas

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

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

signature.asc
Description: signature

Bug#992133: firebird4.0 debian packaging

2021-08-26 Thread Damyan Ivanov

-=| Frank Doepper, 26.08.2021 10:42:33 +0200 |=-
> I tried this (commit f89edee), but it fails again on sid with the 
> same libre2 linker error.

Bummer.

> I think that's a clash between bundled libre2 and system libre2.

Nah, the bundled libre2 is not part of the orig.tar source and can't 
interfere with the build.

> Although
> configure is called with --with-system-re2, the flags contain
> -I/<>/extern/re2, and I guess that's the problem. Maybe
> debian/patches/out/system-re2.patch needs a second look at.

I agree that removing the -I directive would be nice. This is already 
done for other bundled libraries for which upstream supports using the 
system ones. Patch updated.

-- Damyan

Bug#983427: libpam-runtime: please add support for DPKG_ROOT

2021-08-26 Thread Johannes Schauer Marin Rodrigues

Hi sam,

Quoting Sam Hartman (2021-08-26 22:23:18)
> > "Johannes" == Johannes 'josch' Schauer  writes:
> 
> Johannes> diff --git a/debian/libpam-runtime.postinst
> 
> I think that your patch ends up with things like $confdir set to
> "//etc/pam.d" when $DPKG_ROOT is empty.  You get one slash from the
> initialization of the variable and one slash from the separator in the
> code you added.
> 
> 
> Please review the following alternate patch hopefully before it makes
> its way into testing:

you are right and your changed patch looks good to me. I just tested your patch
in our salsaci setup and there does not seem to be a regression.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#993061: gnome-shell-extension-easyscreencast: Not compatible with gnome-shell 40

Source: gnome-shell-extension-easyscreencast
Version: 1.1.0+git20210116.3252312-1
Severity: important

gnome-shell-extension-easyscreencast does not work with gnome-shell 40.

Thanks,
Jeremy Bicha

Bug#893851: ffcall: Fix build for MIPS release 6

2021-08-26 Thread YunQiang Su

Sébastien Villemot  于2021年8月27日周五 上午1:57写道：
>
> Dear YunQiang,
>
> Le mercredi 28 mars 2018 à 10:49 +0200, Sébastien Villemot a écrit :
> > On Fri, Mar 23, 2018 at 09:38:04PM +0800, YunQiang Su wrote:
> > > On Fri, Mar 23, 2018 at 8:41 PM, Sébastien Villemot
> > >  wrote:
> > > > On Fri, Mar 23, 2018 at 08:02:58PM +0800, YunQiang Su wrote:
> > > > > On Fri, Mar 23, 2018 at 7:58 PM, YunQiang Su  
> > > > > wrote:
> > > > > > On Fri, Mar 23, 2018 at 7:27 PM, Sébastien Villemot
> > > > > >  wrote:
> > > > > > > Dear YunQiang,
> > > > > > >
> > > > > > > On Fri, Mar 23, 2018 at 06:15:08PM +0800, YunQiang Su wrote:
> > > > > > > > Package: src:ffcall
> > > > > > > > Version: 2.1-1
> > > > > > > >
> > > > > > > > MIPS release 6 drops some instructions: bnel/beql included.
> > > > > > > > For r6, we should use bne/beq for replace.
> > > > > > > >
> > > > > > > > The patch has submit in salsa as a merge request.
> > > > > > > >
> > > > > > > > https://salsa.debian.org/common-lisp-team/ffcall/merge_requests/1
> > > > > > >
> > > > > > > Thanks for your report and your patch.
> > > > > > >
> > > > > > > You may have overlooked the fact that these assembly files are 
> > > > > > > actually
> > > > > > > generated by GCC from C source code (see the DEP-3 header of
> > > > > > > debian/patches/mips-fpxx.patch), so your proposed patch is not 
> > > > > > > very
> > > > > > > maintainable in the long term.
> > > > > >
> > > > > > Oh, thanks. Since then, I guess we should generate these .S files
> > > > > > when build instead of put them in the source code.
> > > > > >
> > > > > > I will have a look at it.
> > > > >
> > > > > After read Makefile.devel, I think that we should call the right
> > > > > target in debian/rules.
> > > > > Should this the ideal way?
> > > >
> > > > This could be a possiblity, but this is not supported by upstream. And 
> > > > we would
> > > > have to patch this Makefile.devel to make it work (it expects 
> > > > non-standard
> > > > names for GCC). So I do not really like this solution.
> > > >
> > >
> > > In fact we can patch it to use $(CC), and pass it when we call these 
> > > targets,
> > > and then we can drop the patch for the .S/.s files.
> > > The length of patch file will be much shorter.
> > >
> > > Anyway, we will have to patch it.
> > > Wish my attached patch can change your mind. ;)
> >
> > I really don't like the kludge for mips in debian/rules.
> >
> > I think that all things considered I prefer your very first patch, which had
> > the advantage of being very small.
>
> I just wanted to inform you that, with the upload of ffcall 2.4, I had
> to drop your MIPS r6, because it no longer applies, and I don’t know
> how to refresh it.
>
> I think this shows that the best solution for MIPS r6 support would
> rather be to work directly with upstream, rather than applying a
> Debian-specific patch.
>

The upstream had some big restruct work and I think that the current source
can work with MIPS r6 out of box now.

> Best regards,
>
> --
> ⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
> ⣾⠁⢠⠒⠀⣿⡁  Debian Developer
> ⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
> ⠈⠳⣄  https://www.debian.org
>


-- 
YunQiang Su

Bug#989494: buster-pu: package http-parser/2.8.1-1

2021-08-26 Thread Christoph Biedl

Christoph Biedl wrote...

> there is a minor (non-DSA) security issue open in the Debian 10
> ("buster") version of http-parser, and I'd like to fix that in a stable
> point release. This is #977467 [CVE-2019-15605].

Now uploaded in the hope it will help to resolve the issue.

Christoph



signature.asc
Description: PGP signature

Bug#991532: fixed in vmdb2 0.24-1)

2021-08-26 Thread Diederik de Haas

Thank you for updating vmdb2 to 0.24!

On donderdag 26 augustus 2021 18:57:07 CEST you wrote:
> afaict the qemu-debootstrap plugin is still available and doesn't alert
> the user of its deprecation.
> And I think it should, by at least outputting/logging a warning and
> possibly switching to error/fail (over time?).

I'm not sure what to do about it as I think the above quoted part is still 
true and therefor a future problem.
It began with me not entirely correctly marking the issue as fixed-upstream.
While it should now be possible to replace the qemu-debootstrap element in 
yaml files with (plain) debootstrap, upstream still 'happily' invokes qemu-
debootstrap without issuing a warning (or error). And I think it should to 
actively steer people away from qemu-debootstrap.
(Currently qemu-debootstrap 'redirects' the call to normal debootstrap, but 
that will probably not forever be the case)

But I also saw recently a somewhat worrying commit:
say in README project is in "selfish maintenance mode"
https://gitlab.com/larswirzenius/vmdb2/-/commit/
cbd86eb1b70738793b8849bbac54f4a28a1dbe33

So that doesn't look good.

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

Bug#992931: [Debichem-devel] Bug#992931: libopenmm7.5 does not include libOpenMMAmoeba.so, libOpenMMDrude.so, and libOpenMMRPMD.so

2021-08-26 Thread Adam Sjøgren

Andrius writes:

> These libraries do not have sonames, thus I reckon they are not a part
> of public API.

Ah, I see - I was thinking that there would be a reason I didn't know of.

However if you run alphafold2 you get an exception where it tries to use
libOpenMMAmoeba.so. Hm.

(Unfortunately I don't have a small script to reproduce the problem.)

> On the other hand, reference libraries,
>
> libOpenMMAmoebaReference.so
> libOpenMMDrudeReference.so
> libOpenMMRPMDReference.so
>
> are provided in libopenmm-plugins binary package (>= 7.5.1+dfsg-1) at
> /usr/lib/${DEB_HOST_MULTIARCH}/openmm/plugins.
>
> If this would be of use, libOpenMM{Amoeba,Drude,RPMD}.so could be
> provided at /usr/lib/${DEB_HOST_MULTIARCH}/openmm, as
> /usr/lib/${DEB_HOST_MULTIARCH} is reserved for libraries with sonames.

Ah, ok, thanks for the explanation.

I will give it a go locally, see if that works and return.


  Thanks!

   Adam

-- 
 "I wonder if you can refuse to inherit the world." Adam Sjøgren
 "I think if you're born, it's too late."  a...@koldfront.dk

Bug#993040: [Debian-med-packaging] Bug#993040: htscodecs FTBFS on i386

2021-08-26 Thread Étienne Mollier

Hi Andrian,

Adrian Bunk, on 2021-08-26:
> debian/rules should use DEB_HOST_MULTIARCH instead of DEB_TARGET_GNU_TYPE.

Cool, Thanks for the speed and the tip!  I was still waiting for
the build result.  (:

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#992755: closed by Don Armstrong (reply to ow...@bugs.debian.org) (Re: Bug#992755: marked as done ([BTS] Bcc'ed close mails not archived in bug log ?))

2021-08-26 Thread Don Armstrong

On Thu, 26 Aug 2021, Vincent Lefevre wrote:
> On 2021-08-26 03:51:03 +, Debian Bug Tracking System wrote:
> > As a counterexample, this bug is only being closed via Bcc, but it
> > should show up both in the log and in what the bugreport.cgi
> > displays.
> 
> This is not the case. The "close" does not appear and actually
> corresponds to
> 
>   Reply sent to ow...@bugs.debian.org:
>   You have taken responsibility. (Thu, 26 Aug 2021 03:51:03 GMT) (full text, 
> mbox, link).

Yes, that's what happens when you send a mail to -done. There's an
argument to be made that we should change that to something more
obvious, but that's what a close message has looked like for the past 20
years or so.

[...]

> the main page of the bug report should also display when some metadata
> (close status, tags, etc.) is changed.

Mail to -done is handled differently than a control message, and doesn't
cause a separate html message to be added to the log indicating that the
bug status has been changed.

> Actually, "the first mail message to be received is shown" does not
> seem to be how bugreport.cgi behaves in general. For instance, see
> Message #30. It is displayed on the main page, but this main page
> *also* shows 3 copies:
>   * Message #32 ("Bug reopened")
>   * Message #34 ("Changed Bug title to ...")
>   * Message #36 ("Severity set to 'minor' from 'wishlist'")

Those are just the html that corresponds to the control commands which
were processed from message #30.

> I expect the same thing for "Bug closed", which is currently not the
> case.

It's reasonable to argue that it would be less surprising for the BTS to
handle -done like a control@ message, but that's a separate bug from
this bug.

-- 
Don Armstrong  https://www.donarmstrong.com

We cast this message into the cosmos. [...] We are trying to survive
our time so we may live into yours. We hope some day, having solved
the problems we face, to join a community of Galactic Civilizations.
This record represents our hope and our determination and our goodwill
in a vast and awesome universe.
 -- Jimmy Carter on the Voyager Golden Record

Bug#993047: A libvirt-qemu user is added and shown on the login screen because the UID is too high

2021-08-26 Thread mYnDstrEAm

Package: libvirt
Version: 5.0.0

I didn't create this user - I think it was added by installing the "Virtual
Machine manager" (virt-manager) on Debian10/KDE, or more specifically by
libvirt-daemon-system.

`grep -E 'libvirt|qemu' /etc/passwd` returns `libvirt-qemu:x:64055:1xx:Libvirt
Qemu,,,:/var/lib/libvirt:/usr/sbin/nologin`
KDE's User Manager doesn't show the account but it's displayed on the login
screen on the left of the actual user account (not when locking the screen but
at least after booting).

This useraccount shouldn't be displayed as a normal user if adding it is indeed
needed/useful.
If the solution is to not remove the user but to hide it by creating the
/users/libvirt-qemu file why isn't that done when the user is set up already?
If the user is necessary I'd find it strange that iirc it was only added after
installing virt-manager but not after installing and using aqemu.

I asked about it here where users cas and A.B. made some helpful comments. A.B.
suggested that "libvirt-qemu is a system account but with a specific UID not in
the default system range ( < 500 or something like this): `grep
LIBVIRT_QEMU_UID /var/lib/dpkg/info/libvirt`*" (it's over 6). Changing the
UID or creating that config-file containing `SystemAccount=true` upon
installation seem to be two ways of solving this issue.

Per https://github.com/sddm/sddm/issues/816 it really seems to be a bug of
virt-manager. I don't know if this has been fixed in newer versions. If the
solution really is just changing the UID there may be an additional issue of
500 being too low. It should probably check which UIDs within that range are
still available and then assign one of these. It seems like running `usermod -u
345 libvirt-qemu` would solve the issue for those affected, right?

Per https://github.com/virt-manager/virt-manager/issues/293 the problem is the
hard-coded UID here:
https://salsa.debian.org/libvirt-team/libvirt/-/blob/debian/buster/debian/libvirt-daemon-system.config

It would be great if people would set up a proper issue-tracking system for
Debian (one that's modern, somewhat convenient to use, doesn't look outdated by
decades and is Web-based).

Bug#993063: gnome-shell-pomodoro: Please update to version 0.19.1

Source: gnome-shell-pomodoro
Version: 0.18.0-0.1
Severity: important

Please package gnome-shell-pomodoro 0.19.1 which claims to be
compatible with gnome-shell 3.38 and 40.

Thanks,
Jeremy Bicha

Bug#993043: ensmallen: autopkgtest regression on arm64/i386/ppc64el

Source: ensmallen
Version: 2.17.0-2
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/arm64/e/ensmallen/14865434/log.gz
https://ci.debian.net/data/autopkgtest/testing/i386/e/ensmallen/14865770/log.gz
https://ci.debian.net/data/autopkgtest/testing/ppc64el/e/ensmallen/14865925/log.gz

...
---
MOEADZDTONETest
---
tests/moead_test.cpp:510
...

tests/moead_test.cpp:544: FAILED:
  REQUIRE( g == Approx(1.0).margin(0.99) )
with expansion:
  2.1844866419 == Approx( 1.0 )
...

Bug#988146: Fwd: Inconsistent behavior creating partitions with 'Xmib' and 'X%' (off-by-1 error?)

2021-08-26 Thread Diederik de Haas

On zondag 22 augustus 2021 20:53:05 CEST you wrote:
> Control: forwarded -1 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21136
> 
> I tried to forward this bug to the upstream bug-par...@gnu.org ML to get
> some progress and I've 'attached' that to this bug report.

With quite a bit delay, but https://debbugs.gnu.org/50168 was eventually 
created. And I just received a message that it was closed.
Personally, I think the 'explanation' is ridiculous.
So if partition 3 ends at '60mib' and the 4th starts at that, which is imo 
what most/normal people would do, it is expected to fail.
But I'm glad he explained the error message ...

Also he mentioned 'MiB' while it appears that that is a crucial distinction 
wrt 'mib' (and is where the forwarded bug report is about).

Maintainers: afaic you're free to close the bug as I doubt very much the issue 
will receive an appropriate fix.

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

Bug#993057: gnome-shell-extension-bluetooth-quick-connect: New upstream release 20

Source: gnome-shell-extension-bluetooth-quick-connect
Version: 16-1
Severity: important

Please update gnome-shell-extension-bluetooth-quick-connect to version
20. According to the metadata.json, the new version is compatible with
gnome-shell 40 but not compatible with earlier gnome-shell releases.

Thanks,
Jeremy Bicha

Bug#993060: gnome-shell-extension-caffeine: Not compatible with gnome-shell 40

Source: gnome-shell-extension-caffeine
Version: 37-1
Severity: important

It looks like upstream git master is compatible with gnome-shell 40
but not with earlier gnome-shell releases.

Thanks,
Jeremy Bicha

Bug#976313: new magic: plocate database

2021-08-26 Thread Christoph Biedl

Control: tags 976313 confirmed moreinfo

Thanks for your patience ...


Steinar H. Gunderson wrote...

> Here's a suggested magic entry for plocate databases:
>
(...)
> 0   string  \0plocate   plocate database
> >8  long0   \b, version %d (obsolete)
> >8  long>0  \b, version %d
> >>40longx   \b, max version %d

That will lead to ... interesting results on plocate files created on
big-endian hosts, like

| plocate database, version 16777216, max version 33554432

My suggestion is to probe for a plausible version number. Assuming you
will not get up to 8 any time soon, I'd do:

0   string  \0plocate   plocate database
>8  lelong  0   \b, version %d (obsolete)
>8  lelong  !0
>>8 lelong  <8  \b, little endian, version %d
>>>40   lelong  x   \b, max version %d
>>8 belong  <8  \b, big endian, version %d
>>>40   belong  x   \b, max version %d

Does that look good to you?

Christoph


signature.asc
Description: PGP signature

Bug#978863: milter-greylist: ftbfs with autoconf 2.70

2021-08-26 Thread Sudip Mukherjee

Hi,

On Thu, Dec 31, 2020 at 02:28:20PM +, Matthias Klose wrote:
> Package: src:milter-greylist
> Version: 4.6.2-1
> Severity: normal
> Tags: sid bookworm
> User: d...@debian.org
> Usertags: ftbfs-ac270
> 
> [This bug report is not targeted to the upcoming bullseye release]
> 
> The package fails to build in a test rebuild on at least amd64 with
> autoconf 2.70, but succeeds to build with autoconf 2.69. The
> severity of this report will be raised before the bookworm release,
> so nothing has to be done for the bullseye release.

I am not seeing the FTBFS with autoconf 2.71-2 present in unstable now.
Please check https://salsa.debian.org/debian/milter-greylist/-/pipelines/281026

Can you please retest and confirm.


--
Regards
Sudip

Bug#992610: dh-make-golang make fails when no main, no external module dependency

2021-08-26 Thread Anthony Fok

Control: title -1 dh-make-golang fails with "../.." in import path

Hi Kentaro,

Thank you for reporting this issue.

On Fri, Aug 20, 2021 at 10:57 PM Kentaro Hayashi  wrote:
> Package: dh-make-golang
> Version: 0.4.0-1+b6
> Severity: normal
> X-Debbugs-Cc: ken...@xdump.org
>
> # Problem:
>
> When dh-make-golang make is executed for library without no main, no external
> module dependencies, it seems that dh-make-golang will fail.

No, that is not it.  Plenty of existing Go pure library packages (with
no main.go) have been created by dh-make-golang with no issues at all.

The real culprit turns out to be the following code in example/main.go:

import (
"../../notificator"
"log"
)

Relative import path, especially one that refers to a (grand)parent
directory, and such practice is not supported by Go.
It is the "go list github.com/0xAX/notificator/..." command that fails here.

Indeed, other 0xAX/notificator users have run into issue too:
https://github.com/0xAX/notificator/issues

So, it is not a bug in dh-make-golang but in github.com/0xAX/notificator

That said, I'll add in a workaround that retries running "go list"
without the "/...".
This would allow "go list" to avoid such problematic subdirectory.

> I've found this issue against the following case:
>
> $ dh-make-golang make github.com/0xax/notificator

Please note that Go import paths are case-sensitive.
Please follow how upstream has used uppercase for "AX" in "0xAX", as in:

$ dh-make-golang make github.com/0xAX/notificator

Kind regards,

Anthony

Bug#993046: libssh: CVE-2021-3634

2021-08-26 Thread Salvatore Bonaccorso

Source: libssh
Version: 0.9.5-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libssh.

CVE-2021-3634[0]:
| Possible heap-buffer overflow when rekeying

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-3634
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3634
[1] https://www.libssh.org/security/advisories/CVE-2021-3634.txt
[2] 
https://git.libssh.org/projects/libssh.git/commit/?id=d3060bc84ed4e160082e819b4d404f76df7c8063

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#993054: gbp import-orig: support more advanced upstream-vcs-tag mangling

Source: git-buildpackage
Version: 0.9.22
Severity: wishlist

The GNOME project has adopted a new version numbering scheme [1]. Here
are version numbers sorted in order from oldest to newest:
40.alpha
40.beta
40.rc
40.0
40.1

Here are the version numbers mangled so they sort correctly on Debian:
40~alpha
40~beta
40~rc
40.0
40.1

The Debian GNOME team uses gbp's upstream-vcs-tag feature and we'd
like to set it in debian/gbp.conf so it finds the git tag that
corresponds with the upstream version number as handled by uscan (see
the debian/watch file at [2]).

I don't see a way to change a period (.) to a tilde (~) only when
followed by a letter.

[1] https://discourse.gnome.org/t/new-gnome-versioning-scheme/4235
[2] https://salsa.debian.org/gnome-team/evince/-/commit/730e048

Thanks,
Jeremy Bicha

Bug#993056: monit: incorrect comment level in monitrc

Package: monit
Version: 1:5.28.0-3
Severity: minor

In the monitrc file:

## Set the list of mail servers for alert delivery. Multiple servers may be
## specified using a comma separator. If the first mail server fails, Monit
# will use the second mail server in the list and so on. By default Monit uses
# port 25 - it is possible to override this with the PORT option.

This should be:

## Set the list of mail servers for alert delivery. Multiple servers may be
## specified using a comma separator. If the first mail server fails, Monit
## will use the second mail server in the list and so on. By default Monit uses
## port 25 - it is possible to override this with the PORT option.

(A single # is used for commented out statements.)

-- Package-specific info:

Monit config file /etc/monit/monitrc is *NOT* readable by reportbug.
Please, consider to rerun reportbug as root and *carefully* examine
reportbug's output (e.g., monitrc content), before sending it out.

Contents of /etc/monit/ directory:
/etc/monit:
total 68
drwxr-xr-x 2 root root  4096 2021-08-27 03:01:07 conf-available
drwxr-xr-x 2 root root  4096 2015-12-05 21:19:30 conf-enabled
drwxr-xr-x 2 root root  4096 2020-01-04 22:11:10 conf.d
-rw--- 1 root root 13175 2020-08-03 11:01:55 monitrc
drwxr-xr-x 2 root root  4096 2021-07-14 02:13:13 monitrc.d
-rw--- 1 root root 13110 2020-07-31 13:12:44 monitrc.dpkg-dist
-rw--- 1 root root 13500 2021-08-26 14:54:26 monitrc.dpkg-new
drwxr-xr-x 2 root root  4096 2021-08-27 03:00:20 templates

/etc/monit/conf-available:
total 60
-rw-r--r-- 1 root root  481 2015-12-05 21:13:49 acpid
-rw-r--r-- 1 root root  640 2015-12-05 21:13:49 apache2
-rw-r--r-- 1 root root  455 2015-12-05 21:13:49 at
-rw-r--r-- 1 root root  691 2015-12-05 21:13:49 cron
-rw-r--r-- 1 root root  602 2015-12-05 21:13:49 mdadm
-rw-r--r-- 1 root root  669 2015-12-05 21:13:49 memcached
-rw-r--r-- 1 root root  703 2015-12-05 21:13:49 mysql
-rw-r--r-- 1 root root  521 2015-12-05 21:13:49 nginx
-rw-r--r-- 1 root root  471 2015-12-05 21:13:49 openntpd
-rw-r--r-- 1 root root 1200 2020-07-31 13:12:44 openssh-server
-rw-r--r-- 1 root root  683 2015-12-05 21:13:49 pdns-recursor
-rw-r--r-- 1 root root 1426 2018-12-21 09:32:54 postfix
-rw-r--r-- 1 root root  869 2016-03-22 16:43:44 rsyslog
-rw-r--r-- 1 root root  501 2015-12-05 21:13:49 smartmontools
-rw-r--r-- 1 root root  306 2016-02-04 15:03:50 snmpd

/etc/monit/conf-enabled:
total 0

/etc/monit/conf.d:
total 4
-rw-r--r-- 1 root root 357 2020-01-04 22:11:10 eth0

/etc/monit/monitrc.d:
total 64
-rw-r--r-- 1 root root  481 2015-06-09 15:52:48 acpid
-rw-r--r-- 1 root root  640 2015-06-09 15:52:48 apache2
-rw-r--r-- 1 root root  455 2015-06-09 15:52:48 at
-rw-r--r-- 1 root root  691 2015-06-09 15:52:48 cron
-rw-r--r-- 1 root root  403 2016-12-09 15:37:54 fail2ban
-rw-r--r-- 1 root root  602 2015-06-09 15:52:48 mdadm
-rw-r--r-- 1 root root  669 2015-06-09 15:52:48 memcached
-rw-r--r-- 1 root root  703 2015-06-09 15:52:48 mysql
-rw-r--r-- 1 root root  521 2015-06-09 15:52:48 nginx
-rw-r--r-- 1 root root  471 2015-06-09 15:52:48 openntpd
-rw-r--r-- 1 root root  950 2015-06-09 15:52:48 openssh-server
-rw-r--r-- 1 root root  683 2015-06-09 15:52:48 pdns-recursor
-rw-r--r-- 1 root root 1421 2015-06-09 15:52:48 postfix
-rw-r--r-- 1 root root  867 2015-06-09 15:52:48 rsyslog
-rw-r--r-- 1 root root  501 2015-06-09 15:52:48 smartmontools
-rw-r--r-- 1 root root  310 2015-06-09 15:52:48 snmpd

/etc/monit/templates:
total 24
-rw-r--r-- 1 root root 164 2015-06-09 15:52:48 rootbin
-rw-r--r-- 1 root root 164 2021-08-26 14:52:02 rootbin.dpkg-new
-rw-r--r-- 1 root root 160 2015-06-09 15:52:48 rootrc
-rw-r--r-- 1 root root 160 2021-08-26 14:52:02 rootrc.dpkg-new
-rw-r--r-- 1 root root 164 2015-06-09 15:52:48 rootstrict
-rw-r--r-- 1 root root 164 2021-08-26 14:52:02 rootstrict.dpkg-new


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages monit depends on:
ii  init-system-helpers  1.60
ii  libc62.31-17
ii  libcrypt11:4.4.25-1
ii  libpam0g 1.4.0-9
ii  libssl1.11.1.1l-1
ii  lsb-base 11.1.0
ii  zlib1g   1:1.2.11.dfsg-2

monit recommends no packages.

Versions of packages monit suggests:
ii  postfix [mail-transport-agent]  3.5.6-1+b1
pn  sysvinit-core   

-- Configuration Files:
/etc/monit/monitrc [Errno 13] Permission denied: '/etc/monit/monitrc'

-- no debconf information

-- 
Vincent Lefèvre  - Web:

Bug#993058: gnome-shell-extension-dash-to-panel: New upstream release 43

Source: gnome-shell-extension-dash-to-panel
Version: 40-1
Severity: important

gnome-shell-extension-dash-to-panel 43 was released. It works on
gnome-shell 40 but does not work on earlier gnome-shell releases.

Thanks,
Jeremy Bicha

Bug#993059: dpkg-cross: support ld-linux-mipsn8.so.1 for MIPS r6

2021-08-26 Thread YunQiang Su

Package: dpkg-cross
Version: 2.6.18+nmu1

MIPS r6 uses different ld files as the previous version:

@@ -633,10 +633,13 @@ sub sub_build {
while () {
if ($multiarch =~
m/mips(isa)?64.*-linux.*-gnuabi64.*/) {

s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld\.so\.1:$1$crosslib64/ld.so.1:g;
+
s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld-linux-mipsn8\.so\.1:$1$crosslib64/ld-linux-mipsn8\.so\.1:g;
} elsif ($multiarch =~
m/^mips(isa)?64.*-linux.*-gnuabin32.*/) {

s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld\.so\.1:$1$crosslibn32/ld.so.1:g;
+
s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld-linux-mipsn8\.so\.1:$1$crosslibn32/ld-linux-mipsn8\.so\.1:g;
} elsif ($multiarch =~
m/^mips(isa32)?.*-linux.*-gnu.*/) {
-
s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld\.so\.1:$1$crosslib/ld.so.1:g;
+
s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld\.so\.1:$1$crosslib/ld\.so\.1:g;
+
s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld-linux-mipsn8\.so\.1:$1$crosslib/ld-linux-mipsn8\.so\.1:g;
} elsif ($multiarchtriplet eq "sparc64-linux-gnu") {

s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld-linux\.so\.2:$1$crosslib64/ld-linux.so.2:g;
}
@@ -1065,6 +1068,7 @@ sub sub_build {
# skip /usr/$(multiarch)/lib/ld.so.1 for mips n32 and 64.
# their ld.so.1 should be in lib32 and lib64.
next if ($multiarch =~ m/^mips(isa)?64/ && $_ =~
m:lib/ld\.so\.1$:);
+   next if ($multiarch =~ m/^mips(isa)?64/ && $_ =~
m:lib/ld-linux-mipsn8\.so\.1$:);
next if ($multiarchtriplet eq "sparc64-linux-gnu" &&
$_ =~ m:lib/ld-linux\.so\.2$:);

# skip links to private modules and plugins that are not
@@ -1137,7 +1141,9 @@ sub sub_build {
# Link the shlibs file
if (-f "$src/DEBIAN/shlibs") {
print "Installing shlibs file\n" if $verbose >= 2;
-   fix_shlibs("$src/DEBIAN/shlibs", "$dst/DEBIAN/shlibs");
+   link_file("$src/DEBIAN/shlibs", "$dst/DEBIAN/shlibs");
+   # FIXME: not enabling in this copy. needed?
+   #fix_shlibs("$src/DEBIAN/shlibs", "$dst/DEBIAN/shlibs");
}

# Create the control file.

The patch is also avaiable from:
https://salsa.debian.org/toolchain-team/cross-toolchain-base/-/commit/9b1b149dc4cb852ce5f1643ba9d56cc040342bab


-- 
YunQiang Su

Bug#993062: gnome-shell-extension-top-icons-plus: Needs update for gnome-shell 40

Source: gnome-shell-extension-top-icons-plus
Version: 27-2
Severity: important

It looks like git master works with gnome-shell 40 but not with
previous gnome-shell releases.

Thanks,
Jeremy Bicha

Bug#927397: networking fails with A20-OLinuXino-Lime2-eMMC Rev. G2 and bullseye u-boot and -kernel

2021-08-26 Thread Andreas Mundt

Hi all,

the last days, I tried upgrading two A20-OLinuXino-Lime2 boards to bullseye.
After booting the bullseye kernel, 5.10.46-4 (2021-08-03), the network did 
not work anymore: The interface shows up (IIRC, even a link is detected),
but any attempts to connect (DHCP) fail.  

After playing with different delays following [1], I succeeded with 
CONFIG_GMAC_TX_DELAY=4, where both boards seem to work fine. I also played a
bit with iperf3:  At higher bitrates (> approx. 200Mbits/s) more and more 
retries seem to be needed.  So the issue this bug is about seems to affect
also the G2 revision boards that worked fine so far.

Best regards,

  Andi


[1] 
https://wiki.debian.org/InstallingDebianOn/Allwinner#Olimex_A20-OLinuXino-LIME2_rev._K.3B_rev._G2_and_bullseye_kernel

Bug#979974: cloud-init wait an unnecessary timeout

2021-08-26 Thread Noah Meyerhans

Control: tags -1 + upstream fixed upstream

On Tue, Jan 12, 2021 at 01:57:27PM +0100, Matteo Croce wrote:
> At boot cloud-init waits 120 seconds for an ephemeral disk, but some
> VM types doesn't have ephemeral storage at all, so this just blocks
> the boot for 120 seconds:
> 
> Jan 12 11:23:13 mcroce-buster cloud-init[506]: 2021-01-12 11:23:13,608
> - azure.py[WARNING]: ephemeral device '/dev/disk/cloud/azure_resource'
> did not appear after 120 seconds.
> 
> Please consider mounting the disk upon attach.

I believe that this was fixed upstream with
https://github.com/canonical/cloud-init/pull/800, which was released
with cloud-init 21.2

So the fix should be available in unstable and testing at this time.  I
don't have the ability to launch an Azure VM to confirm this, so if
you're able to do so, that would be appreciated.  We can then consider
options for (old)stable branches.

noah

Bug#991463: fixed in knot-resolver 5.4.1-1

2021-08-26 Thread Santiago Ruano Rincón

El 26/08/21 a las 14:45, Jakub Ružička escribió:
> > - Includes fix for CVE-2021-40083 (Closes: #991463)
> 
> I've used this magic syntax found throughout the changelog and it closed
> the bug upon experimental upload, which isn't what I expected. Please
> reopen as needed, I'm not yet familiar with handling bugs wrt different
> Debian branches.
> 

Why would you like to reopen the bug? The BTS knows it is still to be
fixed in unstable. Take a look at the image at the top right of the bug
report page:
https://bugs.debian.org/cgi-bin/version.cgi?absolute=0;found=knot-resolver%2F5.3.1-1;info=1;fixed=knot-resolver%2F5.4.1-1;collapse=1;package=knot-resolver

> Regardless, experimental knot-resolver-5.4.1-1 built against
> experimental knot-3.1.1-3 so I'll try to proceed with the transition
> which should fix the bug for sid.

Awesome, thanks!

> After that I plan to cherry-pick the fix for next bullseye-point release.

Did you have any feedback from the security team?

,

 -- S


signature.asc
Description: PGP signature

Bug#993031: ripser FTCBFS: hard codes the build architecture compiler

2021-08-26 Thread Gard Spreemann



Thanks! Including your patch in a new upload now.

 -- Gard

Bug#992034: installation-guide: Include a note on how to change init system during install

2021-08-26 Thread Charles Curley

On Thu, 26 Aug 2021 22:45:17 +0200
Holger Wansing  wrote:

> I wonder if "the easiest time to select an alternative init system is
> during the installation process" is correct English.
> 
> Maybe better "the best time ... " ?

Much better, although both are literally true. From an native American
speaker.


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Bug#923396: file -e should silently ignore nonexistent testnames

Control: fixed 923396 1:5.39-1

On 2021-08-26 19:59:18 +0200, Christoph Biedl wrote:
> Control: fixed 923396 1:5.39-1

Really marking as fixed in this version (it seems that Control lines
are ignored in mail to -done@b.d.o addresses).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#993048: mosquitto init script broken with bullseye update

2021-08-26 Thread Chris Zubrzycki

Package: mosquitto
Version: 2.0.11-1
Severity: important
Tags: patch

Dear Maintainer,

With the 2.0 upgrade, mosquitto now writes a pid file on it's own as the
mosquitto user. This breaks the init script as the run directory is root
writable, and on top of that the init script uses s-s-d to also write a
root-owned pid file. The attached patch should match the behavior of the
systemd file, which is let the daemon write it's own pid file in
/var/run/mosquitto/ and chowns the dir to allow it. I have disabled
s-s-d from making a root owned file, and also added a match to the
mosquitto user for stopping/reloading as the new policy says non-root
pid files are insecure unless additional matches are present.


Oh, and listener 1883 needs to be added ito the config otherwise mosquitto
only listens on loopback which will break most existing installs.

references:
https://issues.apache.org/jira/secure/attachment/13001569/0001-Fix-init-script-for-debian-Buster.patch
https://github.com/eclipse/mosquitto/issues/1950

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages mosquitto depends on:
ii  adduser3.118
ii  libc6  2.31-13
ii  libcjson1  1.7.14-1
ii  libdlt22.18.6-1
ii  libelogind0 [libsystemd0]  246.9.1-1+debian1
ii  libmosquitto1  2.0.11-1
ii  libssl1.1  1.1.1k-1
ii  libwebsockets164.0.20-2
ii  libwrap0   7.6.q-31
ii  lsb-base   11.1.0

mosquitto recommends no packages.

Versions of packages mosquitto suggests:
ii  apparmor  2.13.6-10

-- Configuration Files:
/etc/init.d/mosquitto changed:
set -e
PIDFILE=/run/mosquitto/mosquitto.pid
DAEMON=/usr/sbin/mosquitto
USER=mosquitto
test -x ${DAEMON} || exit 0
umask 022
. /lib/lsb/init-functions
run_by_init() {
   ([ "$previous" ] && [ "$runlevel" ]) || [ "$runlevel" = S ]
}
export PATH="${PATH:+$PATH:}/usr/sbin:/sbin"
case "$1" in
 start)
if init_is_upstart; then
exit 1
fi
log_daemon_msg "Starting network daemon:" "mosquitto"
/bin/mkdir -m 740 -p /var/log/mosquitto
/bin/chown mosquitto /var/log/mosquitto
/bin/mkdir -m 740 -p /run/mosquitto
/bin/chown mosquitto /run/mosquitto
if start-stop-daemon --start --quiet --oknodo --background  --user 
${USER} --pidfile ${PIDFILE} --exec ${DAEMON} -- -c 
/etc/mosquitto/mosquitto.conf ; then
log_end_msg 0
else
log_end_msg 1
fi
;;
 stop)
if init_is_upstart; then
exit 0
fi
log_daemon_msg "Stopping network daemon:" "mosquitto"
if start-stop-daemon --stop --quiet --oknodo --user ${USER} --pidfile 
${PIDFILE}; then
log_end_msg 0
rm -f ${PIDFILE}
else
log_end_msg 1
fi
;;
 reload|force-reload)
if init_is_upstart; then
exit 1
fi
log_daemon_msg "Reloading network daemon configuration:" "mosquitto"
   if start-stop-daemon --stop --signal HUP --quiet --oknodo --user ${USER} 
--pidfile $PIDFILE; then
   log_end_msg 0
   else
   log_end_msg 1
   fi   
;;
 restart)
if init_is_upstart; then
exit 1
fi
log_daemon_msg "Restarting network daemon:" "mosquitto"
if start-stop-daemon --stop --quiet --oknodo --retry 30 --user ${USER} 
--pidfile ${PIDFILE}; then
rm -f ${PIDFILE}
fi

/bin/mkdir -m 740 -p /var/log/mosquitto
/bin/chown mosquitto /var/log/mosquitto
/bin/mkdir -m 740 -p /run/mosquitto
/bin/chown mosquitto /run/mosquitto
if start-stop-daemon --start --quiet --oknodo --background --pidfile 
${PIDFILE} --user ${USER} --exec ${DAEMON} -- -c /etc/mosquitto/mosquitto.conf 
; then
log_end_msg 0
else
log_end_msg 1
fi
;;
 try-restart)
if init_is_upstart; then
exit 1
fi
log_daemon_msg "Restarting Mosquitto message broker" "mosquitto"
set +e
start-stop-daemon --stop --quiet --retry 30 --pidfile ${PIDFILE}
RET="$?"
set -e
case $RET in
0)
# old daemon stopped
rm -f ${PIDFILE}
if start-stop-daemon --start --quiet --oknodo --background 
--pidfile ${PIDFILE} --user ${USER} --exec ${DAEMON} -- -c 
/etc/mosquitto/mosquitto.conf ; then
log_end_msg 0
else
log_end_msg 1
fi
;;
1)

Bug#993039: ejabberd: Please add autopkgtests

2021-08-26 Thread James Valleroy

Package: ejabberd
Severity: wishlist
X-Debbugs-Cc: jvalle...@mailbox.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please consider adding some autopkgtests, hopefully including one that
starts the ejabberd service. This is so that when bugs like #992998
come up, the packages causing the breakage can automatically be
prevented from migrating to testing.

-BEGIN PGP SIGNATURE-

iQJKBAEBCgA0FiEEfWrbdQ+RCFWJSEvmd8DHXntlCAgFAmEn2H4WHGp2YWxsZXJv
eUBtYWlsYm94Lm9yZwAKCRB3wMdee2UICKeTD/974sjvekWGpOz/+RH4wERQOyfY
8buvSbqXV3j8Aj5av2QACKvMJwAG4dYZxEvkozTvtn6fFJuoHVE5jR+XkefktVqK
YAJYPcyBKLSKiSF3dsowkp2e6HaGq9Wc4RFMT/amg5jh5V7iUTdFu8VuHM2asnwx
CSwwCNJdo90lCmkKZDMdoJKTV/8qP3CYHZGKTf0bHwwQ6Wp8QifXhmBAoTMaJSk8
X7oxs6QPaWbD+11YsvAagoFCvfLSKE/PqPIeEJa1pY/B4gCk3eqW11H/TckfhxeA
rQJ1IkVTnzY3qYoX4+TadwhLX4GrDqv3Blcu5stw71qD4ehcBhf5P/L3l6DyTAux
HcLFQyQqgYB3QvmqMo3+Y6v82OIxzObzy6kJ6JwuJKR8Gqr2SQVNXa6k0eetz+v+
rWVufo4yTZCfmHug9QUKSOx1nO0xw4J4QzTZwc3/0hz9EIDayWwwY1BYpKDS4xj6
l9a6GEYbLXrqZ1JS0wmP+EZvxjEpfkJt1hWQccCW6n1LvSgjxrZ01rgtH/vfBorj
6dWNkK2FPKaoxp0SKQP+AgnP8NTghxh+8FfA8kOzVTnkXUV+sVzRlYvrPB0jGWV8
eaW4GdYELYAWftbPUvO63+nCscSJqTax0s3DFmuEih9SVWzt1v8S8JmBJxLkYXWE
dmY5e/JH+HZITJsSdw==
=iuUw
-END PGP SIGNATURE-

Bug#993052: transition: tracker

2021-08-26 Thread mount -t cifs unable to mount shared folders on windows server active director

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: trac...@packages.debain.org
Severity: normal

The Debian GNOME team requests permission to do the "tracker"
transition, updating the library and service from version 2 to version
3. All affected packages need sourceful uploads.

All affected packages are maintained by the Debian GNOME team except
for grilo-plugins, kylin-burner and netatalk.

All package updates are staged in experimental except for
grilo-plugins and netatalk.

The transition was successfully completed in Ubuntu a month ago.

https://release.debian.org/transitions/html/auto-tracker.html

https://salsa.debian.org/berto/grilo-plugins/-/merge_requests/2

Thank you,
Jeremy Bicha

Bug#993059: dpkg-cross: support ld-linux-mipsn8.so.1 for MIPS r6

2021-08-26 Thread YunQiang Su

On Fri, 27 Aug 2021 09:28:47 +0800 YunQiang Su  wrote:
> Package: dpkg-cross
> Version: 2.6.18+nmu1
> 

Oh, sorry I paste the patch more than needed.
@@ -633,10 +633,13 @@ sub sub_build {
while () {
if ($multiarch =~ m/mips(isa)?64.*-linux.*-gnuabi64.*/) 
{

s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld\.so\.1:$1$crosslib64/ld.so.1:g;
+   
s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld-linux-mipsn8\.so\.1:$1$crosslib64/ld-linux-mipsn8\.so\.1:g;
} elsif ($multiarch =~ 
m/^mips(isa)?64.*-linux.*-gnuabin32.*/) {

s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld\.so\.1:$1$crosslibn32/ld.so.1:g;
+   
s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld-linux-mipsn8\.so\.1:$1$crosslibn32/ld-linux-mipsn8\.so\.1:g;
} elsif ($multiarch =~ 
m/^mips(isa32)?.*-linux.*-gnu.*/) {
-   
s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld\.so\.1:$1$crosslib/ld.so.1:g;
+   
s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld\.so\.1:$1$crosslib/ld\.so\.1:g;
+   
s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld-linux-mipsn8\.so\.1:$1$crosslib/ld-linux-mipsn8\.so\.1:g;
} elsif ($multiarchtriplet eq "sparc64-linux-gnu") {

s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld-linux\.so\.2:$1$crosslib64/ld-linux.so.2:g;
}
@@ -1065,6 +1068,7 @@ sub sub_build {
# skip /usr/$(multiarch)/lib/ld.so.1 for mips n32 and 64.
# their ld.so.1 should be in lib32 and lib64.
next if ($multiarch =~ m/^mips(isa)?64/ && $_ =~ 
m:lib/ld\.so\.1$:);
+   next if ($multiarch =~ m/^mips(isa)?64/ && $_ =~ 
m:lib/ld-linux-mipsn8\.so\.1$:);
next if ($multiarchtriplet eq "sparc64-linux-gnu" && $_ =~ 
m:lib/ld-linux\.so\.2$:);

# skip links to private modules and plugins that are not
This is the correct one, or see:
https://salsa.debian.org/toolchain-team/cross-toolchain-base/-/commit/9b1b149dc4cb852ce5f1643ba9d56cc040342bab.patch

> MIPS r6 uses different ld files as the previous version:
> 
> @@ -633,10 +633,13 @@ sub sub_build {
> while () {
> if ($multiarch =~
> m/mips(isa)?64.*-linux.*-gnuabi64.*/) {
> 
> s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld\.so\.1:$1$crosslib64/ld.so.1:g;
> +
> s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld-linux-mipsn8\.so\.1:$1$crosslib64/ld-linux-mipsn8\.so\.1:g;
> } elsif ($multiarch =~
> m/^mips(isa)?64.*-linux.*-gnuabin32.*/) {
> 
> s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld\.so\.1:$1$crosslibn32/ld.so.1:g;
> +
> s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld-linux-mipsn8\.so\.1:$1$crosslibn32/ld-linux-mipsn8\.so\.1:g;
> } elsif ($multiarch =~
> m/^mips(isa32)?.*-linux.*-gnu.*/) {
> -
> s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld\.so\.1:$1$crosslib/ld.so.1:g;
> +
> s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld\.so\.1:$1$crosslib/ld\.so\.1:g;
> +
> s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld-linux-mipsn8\.so\.1:$1$crosslib/ld-linux-mipsn8\.so\.1:g;
> } elsif ($multiarchtriplet eq "sparc64-linux-gnu") {
> 
> s:(^|[^-\w/])(/usr)?/lib/${multiarch}ld-linux\.so\.2:$1$crosslib64/ld-linux.so.2:g;
> }
> @@ -1065,6 +1068,7 @@ sub sub_build {
> # skip /usr/$(multiarch)/lib/ld.so.1 for mips n32 and 64.
> # their ld.so.1 should be in lib32 and lib64.
> next if ($multiarch =~ m/^mips(isa)?64/ && $_ =~
> m:lib/ld\.so\.1$:);
> +   next if ($multiarch =~ m/^mips(isa)?64/ && $_ =~
> m:lib/ld-linux-mipsn8\.so\.1$:);
> next if ($multiarchtriplet eq "sparc64-linux-gnu" &&
> $_ =~ m:lib/ld-linux\.so\.2$:);
> 
> # skip links to private modules and plugins that are not
> @@ -1137,7 +1141,9 @@ sub sub_build {
> # Link the shlibs file
> if (-f "$src/DEBIAN/shlibs") {
> print "Installing shlibs file\n" if $verbose >= 2;
> -   fix_shlibs("$src/DEBIAN/shlibs", "$dst/DEBIAN/shlibs");
> +   link_file("$src/DEBIAN/shlibs", "$dst/DEBIAN/shlibs");
> +   # FIXME: not enabling in this copy. needed?
> +   #fix_shlibs("$src/DEBIAN/shlibs", "$dst/DEBIAN/shlibs");
> }
> 
> # Create the control file.
> 
> The patch is also avaiable from:
> https://salsa.debian.org/toolchain-team/cross-toolchain-base/-/commit/9b1b149dc4cb852ce5f1643ba9d56cc040342bab
> 
> 
> -- 
> YunQiang Su

Bug#993000: linux: please enable CONFIG_VFIO_FSL_MC on arm64

2021-08-26 Thread russm

Source: linux
Severity: normal
X-Debbugs-Cc: russm-debian-b...@slofith.org

Dear Maintainer,

Please enable CONFIG_VFIO_FSL_MC=m on arm64 to allow passthrough of
fsl-mc network devices to VMs.

Thanks


-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable'), (1, 'experimental')
Architecture: arm64 (aarch64)

Kernel: Linux 5.13.0-trunk-arm64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#993006: RM: debian-dad -- ROM; superseded by Debian Janitor

2021-08-26 Thread Bálint Réczey

Package: ftp.debian.org
Severity: normal

Dear FTP Masters,

Please remove src:debian-dad.The main aim of this project was similar
to what Debian Janitor just started doing and Janitor does it better
already:
https://www.jelmer.uk/fresh-builds.html

Big thanks to the Debian Janitor developer(s)!

Thanks,
Balint

Bug#983332: sane-utils: incorrectly identifies Wifi USB dongles as scanners

2021-08-26 Thread Martin-Éric Racine

They are supported by the kernel. They work just fine as WiFi dongles.

They simply are NOT scanning devices. SANE makes the wrong assumption.
This has NOTHING to do with the kernel.

to 26. elok. 2021 klo 8.58 Jörg Frings-Fürst (debian@jff.email) kirjoitti:
>
> reassign 983332  linux-signed-amd64
> thanks
>
>
> Hello,
>
> at [1] the device IDs 0x0b05, 0x179d and 0x0411, 0x00e8 are not listed.
>
> Both devices are not supported by kernel.
>
> I reassign this bug to linux-signed-amd64
>
> CU
> Jörg
>
> [1] https://wiki.debian.org/DeviceDatabase/USB
>
> --
> New:
> GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
> GPG key (long) : 09F89F3C8CA1D25D
> GPG Key: 8CA1D25D
> CAcert Key S/N : 0E:D4:56
>
> Old pgp Key: BE581B6E (revoked since 2014-12-31).
>
> Jörg Frings-Fürst
> D-54470 Lieser
>
>
> git:  https://jff.email/cgit/
>
> Threema: SYR8SJXB
> Wire: @joergfringsfuerst
> Skype: joergpenguin
> Ring: jff
> Telegram: @joergfringsfuerst
>
>
> My wish list:
>  - Please send me a picture from the nature at your home.
>

Bug#993002: cifs-utils: I tried mount with credential archive (username, password and domain) wiht -o credential=mycredential.txt, all sec= and all -m options without success. The mount point folder p

Package: cifs-utils
Version: 2:6.11-3.1
Severity: important
X-Debbugs-Cc: draco...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?
Try to connect to shared folder from Windows 2008 servers on active directory.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I can connect to same folder with gvfs-mout (smb://) into Thunar file mannager 
and with smbclient into Bash Shell,
while I suppose that has a bug in mount wiht cifs-utils.

   * What was the outcome of this action?
I can't mount shared windows foders with mount -t cifs //myserver/sharedfolder 
/mointpoint.
   * What outcome did you expect instead?
Reppair this problem, if possible.
*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 11.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (50, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages cifs-utils depends on:
ii  libc6 2.31-13
ii  libcap-ng00.7.9-2.2+b1
ii  libkeyutils1  1.6.1-2
ii  libkrb5-3 1.18.3-6
ii  libpam0g  1.4.0-9
ii  libtalloc22.3.1-2+b1
ii  libwbclient0  2:4.13.5+dfsg-2
ii  python3   3.9.2-3

Versions of packages cifs-utils recommends:
ii  keyutils  1.6.1-2

Versions of packages cifs-utils suggests:
ii  bash-completion  1:2.11-2
ii  smbclient2:4.13.5+dfsg-2
pn  winbind  

-- no debconf information

Bug#993003: hydroffice.bag: tests fail with h5py 3

2021-08-26 Thread Drew Parsons

Source: hydroffice.bag
Version: 0.2.15-3
Severity: serious
Justification: breaks
Control: forwarded -1 https://github.com/hydroffice/hyo_bag/issues/3

hydroffice.bag fails debci tests with h5py 3

h5py changed the way the file mode is set when accessing .h5 files.
The mode now needs to be given explicitly.

Test logs report:


  .EEE.
  ==
  ERROR: test_bag_File_filename (test_hydroffice_bag_base.TestBagBase)
  --
  Traceback (most recent call last):
File 
"/tmp/autopkgtest-lxc.niorsqvb/downtmp/autopkgtest_tmp/tests/test_hydroffice_bag_base.py",
 line 34, in test_bag_File_filename
  bag_0 = File(self.file_bag_0)
File "/usr/lib/python3/dist-packages/hydroffice/bag/base.py", line 69, in 
__init__
  super(File, self).__init__(name=name, mode=mode, driver=driver,
File 
"/usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/_hl/files.py", line 
444, in __init__
  fid = make_fid(name, mode, userblock_size,
File 
"/usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/_hl/files.py", line 
215, in make_fid
  raise ValueError("Invalid mode; must be one of r, r+, w, w-, x, a")
  ValueError: Invalid mode; must be one of r, r+, w, w-, x, a
  
  ==
  ERROR: test_bag_File_open (test_hydroffice_bag_base.TestBagBase)
  --
  Traceback (most recent call last):
File 
"/tmp/autopkgtest-lxc.niorsqvb/downtmp/autopkgtest_tmp/tests/test_hydroffice_bag_base.py",
 line 30, in test_bag_File_open
  self.assertIsNotNone(File(self.file_bag_0))
File "/usr/lib/python3/dist-packages/hydroffice/bag/base.py", line 69, in 
__init__
  super(File, self).__init__(name=name, mode=mode, driver=driver,
File 
"/usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/_hl/files.py", line 
444, in __init__
  fid = make_fid(name, mode, userblock_size,
File 
"/usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/_hl/files.py", line 
215, in make_fid
  raise ValueError("Invalid mode; must be one of r, r+, w, w-, x, a")
  ValueError: Invalid mode; must be one of r, r+, w, w-, x, a
  
  ==
  ERROR: test_bag_File_raise (test_hydroffice_bag_base.TestBagBase)
  --
  Traceback (most recent call last):
File 
"/tmp/autopkgtest-lxc.niorsqvb/downtmp/autopkgtest_tmp/tests/test_hydroffice_bag_base.py",
 line 27, in test_bag_File_raise
  File(self.file_fake_0)
File "/usr/lib/python3/dist-packages/hydroffice/bag/base.py", line 69, in 
__init__
  super(File, self).__init__(name=name, mode=mode, driver=driver,
File 
"/usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/_hl/files.py", line 
444, in __init__
  fid = make_fid(name, mode, userblock_size,
File 
"/usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/_hl/files.py", line 
215, in make_fid
  raise ValueError("Invalid mode; must be one of r, r+, w, w-, x, a")
  ValueError: Invalid mode; must be one of r, r+, w, w-, x, a
  
  --
  Ran 9 tests in 0.003s
  
  FAILED (errors=3)





I recommend removing the hydroffice.bag packages from testing

hydroffice.bag-doc
hydroffice.bag-tools
python3-hydroffice.bag


hyo_bag upstream hasn't been updated for more than 3 years.

I'm not sure how useful hydroffice.bag is anyway without the other
hydroffice components.



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

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

Bug#992761: apt : needs a "rollback" feature

2021-08-26 Thread David Kalnischkies

On Mon, Aug 23, 2021 at 08:52:50AM +0200, Erwan David wrote:
> After upgrading to a new version of KDE with a small bug, I would have loked 
> to
> return back to previous version. Howeever the upgrade was ~ 400 pacakges and
> that makes it complicated, getting all packages in the logs.  So I thought of
> the 1 feature I miss from yum in apt : the possibility, after an upgrade to
> rollback to the previous versions of package list That would be a good feature
> for apt

Your given example is precisely the case in which a rollback will
(generally) not work. Nowhere, not even in yum.

First of all: Downgrades (aka going back to an older version) are not
supported in Debian. Full stop. It kinda works most of the time and the
lower in the stack the package is, the more likely it is actually that
it will work. yum is optimistic in this regard, apt isn't.

Graphical applications are far removed from "low in the stack" through.
Most, if not all will create & edit files in your home directory which
might be completely incompatible with previous versions. darktable
reminds me of this every other big version bump actually on the first
start of the new version as it will proceed to change the database then.
Many others also warn while most don't and just explode if you would
ever try (some games don't even have forward compat for their savegames,
I highly doubt they have backward compat…).

So a simple rollback of that one package wont work. What exactly do you
expect to happen if ~400 packages are involved?

We might get something like that some day. We introduced the history.log
sort of with this in mind, but haven't added much tooling to work with
it yet. But it will never work like you imagine here, as it simply
can't. It might work, if you are lucky, but if not, you have likely two
problems instead of one.

Best regards

David Kalnischkies

signature.asc
Description: PGP signature

Bug#993004: yt: tests fail with h5py 3

2021-08-26 Thread Drew Parsons

Source: yt
Version: 3.6.1-1
Severity: serious
Justification: breaks

yt tests fail with h5py 3, due to removal of the values property.

if "dataset_units" in h5f:
for unit_name in h5f["/dataset_units"]:
current_unit = h5f["/dataset_units/%s" % unit_name]
>   value = current_unit.value
E   AttributeError: 'Dataset' object has no attribute 'value'



yt has addressed it upstream, upgrade to yt 4 should fix it.

Bug#987426: juk: Volume slider displays wrong volume level

2021-08-26 Thread anthony

Package: juk
Version: 4:20.12.3-1
Followup-For: Bug #987426
X-Debbugs-Cc: lkphantom1...@gmail.com

Dear Maintainer,

The volume indicator and slider **always** shows wrong volume level 
(-2,147,483,648%, 
equivalent to 0x8000 in int32_t). The problem didn't affect actual volume 
level,
and i could still change the actual volume by swipe the slider(but 
-2,147,483,648% will
appears again on next time).


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

Kernel: Linux 4.19.118.anthony.ll (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages juk depends on:
ii  kio5.78.0-5
ii  libc6  2.31-13
ii  libgcc-s1  10.2.1-6
ii  libkf5completion5  5.78.0-3
ii  libkf5configcore5  5.78.0-4
ii  libkf5configwidgets5   5.78.0-2
ii  libkf5coreaddons5  5.78.0-4
ii  libkf5crash5   5.78.0-3
ii  libkf5dbusaddons5  5.78.0-2
ii  libkf5globalaccel-bin  5.78.0-3
ii  libkf5globalaccel5 5.78.0-3
ii  libkf5i18n55.78.0-2
ii  libkf5iconthemes5  5.78.0-2
ii  libkf5jobwidgets5  5.78.0-2
ii  libkf5kiocore5 5.78.0-5
ii  libkf5kiowidgets5  5.78.0-5
ii  libkf5notifications5   5.78.0-2
ii  libkf5textwidgets5 5.78.0-2
ii  libkf5wallet-bin   5.78.0-2
ii  libkf5wallet5  5.78.0-2
ii  libkf5widgetsaddons5   5.78.0-2
ii  libkf5windowsystem55.78.0-2
ii  libkf5xmlgui5  5.78.0-2
ii  libphonon4qt5-44:4.11.1-4
ii  libqt5core5a   5.15.2+dfsg-9
ii  libqt5dbus55.15.2+dfsg-9
ii  libqt5gui5 5.15.2+dfsg-9
ii  libqt5network5 5.15.2+dfsg-9
ii  libqt5svg5 5.15.2-3
ii  libqt5widgets5 5.15.2+dfsg-9
ii  libqt5xml5 5.15.2+dfsg-9
ii  libstdc++6 10.2.1-6
ii  libtag1v5  1.11.1+dfsg.1-3
ii  phonon4qt5 4:4.11.1-4

juk recommends no packages.

Versions of packages juk suggests:
ii  k3b  20.12.2-1

-- no debconf information

Bug#992755: closed by Don Armstrong (reply to ow...@bugs.debian.org) (Re: Bug#992755: marked as done ([BTS] Bcc'ed close mails not archived in bug log ?))

On 2021-08-26 03:51:03 +, Debian Bug Tracking System wrote:
> Date: Wed, 25 Aug 2021 20:41:31 -0700
> From: Don Armstrong 
> To: Holger Wansing 
> Cc: ow...@bugs.debian.org
> Subject: Re: Bug#992755: marked as done ([BTS] Bcc'ed close mails not
>  archived in bug log ?)
[...]
> 
> On Mon, 23 Aug 2021, Holger Wansing wrote:
> > Bug has been closed, but without any mention in the bug log.
> 
> Thanks for the report and the example of the behavior.
> 
> This is the bug being closed in the bug log: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992755#11
> 
> Maybe not quite what you were expecting, but that's the message. Because
> the message was Bcc as well as To: to the same bug log, only the first
> mail message to be received is shown. Both are in the log, however.
> 
> Here's that message hitting the log, directly from the log:
> 
> Received: (at 992755-close) by bugs.debian.org; 23 Aug 2021 05:30:27 +
> From hwans...@mailbox.org Mon Aug 23 05:30:27 2021
> X-Spam-Checker-Version: SpamAssassin 3.4.2-bugs.debian.org_2005_01_02
> (2018-09-13) on buxtehude.debian.org
> X-Spam-Level:
> 
> 
> As a counterexample, this bug is only being closed via Bcc, but it
> should show up both in the log and in what the bugreport.cgi displays.

This is not the case. The "close" does not appear and actually
corresponds to

  Reply sent to ow...@bugs.debian.org:
  You have taken responsibility. (Thu, 26 Aug 2021 03:51:03 GMT) (full text, 
mbox, link).

but one needs to click on "full text" and search the headers to see
that the bug was closed here.

The fact that only the first mail message to be received is shown may
be fine, but the main page of the bug report should also display when
some metadata (close status, tags, etc.) is changed.

Actually, "the first mail message to be received is shown" does not
seem to be how bugreport.cgi behaves in general. For instance, see
Message #30. It is displayed on the main page, but this main page
*also* shows 3 copies:
  * Message #32 ("Bug reopened")
  * Message #34 ("Changed Bug title to ...")
  * Message #36 ("Severity set to 'minor' from 'wishlist'")

I expect the same thing for "Bug closed", which is currently not the
case.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#990246: vlc: reproducible builds: Embeds build username and hostname in binaries

2021-08-26 Thread Sebastian Ramacher

On 2021-08-25 10:08:07 -0700, Vagrant Cascadian wrote:
> On 2021-08-25, Sebastian Ramacher wrote:
> > On 2021-06-23 13:16:47, Vagrant Cascadian wrote:
> >> The build username and build system hostname are embedded in binaries
> >> shipped in vlc:
> >> 
> >>   
> >> https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/vlc.html
> >> 
> >>   ./usr/lib/x86_64-linux-gnu/libvlccore.so.9.0.0 
> >> 
> >>   pbuilder1
> >>   vs.
> >>   pbuilder2
> >> 
> >>   ionos11-amd64
> >>   vs.
> >>   i-capture-the-hostname
> >> 
> >> The attached patch fixes this by setting VLC_COMPILE_BY and
> >> VLC_COMPILE_HOST to empty values in configure.ac.
> >
> > NACK. This information is part of the logs that are usually requested
> > from users by upstream. We want to have this information included in the
> > log so that upstream can easily identify where the logs are coming from
> > and what they are using. And for that purpose, a self-built deb or one
> > from a downstream distribution is different from the Debian one.
> 
> The username and hostname of the build seems a rather imprecise way to
> find out information about the origin of the build...
> 
> In the context of Debian, a given package+version has specific build
> logs associated with it findable at https://buildd.debian.org/PACKAGE

A package version doesn't tell me if it's the same version but built by
Debian, built by Ubuntu, built by Devuan, etc. And given that we receive
bug reports from downstream distributions also in the Debian BTS, that's
something I want to know when triaging those reports.

I'd be fine if that says for example, $DIST $ARCH buildd. That would
only leave custom built debs.

Cheers

> 
> I would expect downstream projects to have something similar
> (e.g. ubuntu).
> 
> Obviously that wouldn't help for a self-built deb, but I would think the
> person who built the deb would already have that information (and
> ideally share that information with upstream)...
> 
> Thanks for considering. Perhaps it will be best to take this upstream at
> this point, anyways...
> 
> 
> live well,
>   vagrant
> 
> 
> >> This patch does not address all reproducibility issues in vlc
> >> (e.g. build paths), though applying it reduces the diff for the
> >> remaining issues.
> >> 
> >> 
> >> Thanks for maintaining vlc!
> >> 
> >> 
> >> live well,
> >>   vagrant
> >
> >> From 01e2dcc51b31f1a06bcd07faa0ae3fbd0ddbe9c6 Mon Sep 17 00:00:00 2001
> >> From: Vagrant Cascadian 
> >> Date: Wed, 23 Jun 2021 19:33:47 +
> >> Subject: [PATCH 1/3] Disable embedding the build hostname and username in 
> >> the
> >>  binaries.
> >> 
> >> https://tests.reproducible-builds.org/debian/issues/user_hostname_manually_added_requiring_further_investigation_issue.html
> >> ---
> >>  configure.ac | 4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >> 
> >> diff --git a/configure.ac b/configure.ac
> >> index 7db5256a8..5d6324cf9 100644
> >> --- a/configure.ac
> >> +++ b/configure.ac
> >> @@ -4324,8 +4324,8 @@ AC_SUBST(VERSION_MINOR)
> >>  AC_SUBST(VERSION_REVISION)
> >>  AC_SUBST(VERSION_EXTRA)
> >>  AC_SUBST(COPYRIGHT_YEARS)
> >> -AC_DEFINE_UNQUOTED(VLC_COMPILE_BY, "`whoami|sed -e 's/\\\/\\\/g'`", 
> >> [user who ran configure])
> >> -AC_DEFINE_UNQUOTED(VLC_COMPILE_HOST, "`hostname -f 2>/dev/null || 
> >> hostname`", [host which ran configure])
> >> +AC_DEFINE_UNQUOTED(VLC_COMPILE_BY, "", [user who ran configure])
> >> +AC_DEFINE_UNQUOTED(VLC_COMPILE_HOST, "", [host which ran configure])
> >>  AC_DEFINE_UNQUOTED(VLC_COMPILER, "`$CC -v 2>&1 | tail -n 1 | sed -e 's/ 
> >> *$//'`", [compiler])
> >>  dnl
> >>  dnl  Handle substvars that use $(top_srcdir)
> >> -- 
> >> 2.32.0



-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#983332: sane-utils: incorrectly identifies Wifi USB dongles as scanners

2021-08-26 Thread Jörg Frings-Fürst

reassign 983332  linux-signed-amd64
thanks


Hello,

at [1] the device IDs 0x0b05, 0x179d and 0x0411, 0x00e8 are not listed.

Both devices are not supported by kernel.

I reassign this bug to linux-signed-amd64

CU
Jörg

[1] https://wiki.debian.org/DeviceDatabase/USB

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema: SYR8SJXB
Wire: @joergfringsfuerst
Skype: joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#992998: ejabberd does not start anymore after recent erlang update

2021-08-26 Thread Joerg Dorchain

Package: ejabberd
Version: 21.01-2

Hello,

with the recent  erlang 1:24.0.5+dfsg-2 MIGRATED to testing,
ejabberd does not start anymore.

Logs are attached. I read it as a hint to recompile.

Thank you for caring,

Joerg


2021-08-26 08:09:56.282527+02:00 [error] 
<0.496.0>@supervisor:start_children/2:392 SUPERVISOR REPORT:
supervisor: {local,jose_sup}
errorContext: start_error
reason: {{case_clause,
 {'ECPrivateKey',1,
 <<104,152,88,12,19,82,251,156,171,31,222,207,0,76,115,88,
   210,229,36,106,137,192,81,153,154,254,226,38,247,70,226,
   157>>,
 {namedCurve,{1,2,840,10045,3,1,7}},
 <<4,46,75,29,46,150,77,222,40,220,159,244,193,125,18,190,
   254,216,38,191,11,52,115,159,213,230,77,27,131,94,17,46,
   21,186,71,62,36,225,0,90,21,186,235,132,152,229,13,189,
   196,121,64,84,64,229,173,12,24,23,127,175,67,247,29,139,
   91>>,
 asn1_NOVALUE}},
 [{jose_server,check_ec_key_mode,2,
  [{file,"jose_server.erl"},{line,189}]},
  {lists,foldl,3,[{file,"lists.erl"},{line,1267}]},
  {jose_server,support_check,0,
  [{file,"jose_server.erl"},{line,153}]},
  {jose_server,init,1,[{file,"jose_server.erl"},{line,93}]},
  {gen_server,init_it,2,[{file,"gen_server.erl"},{line,423}]},
  {gen_server,init_it,6,[{file,"gen_server.erl"},{line,390}]},
  {proc_lib,init_p_do_apply,3,
  [{file,"proc_lib.erl"},{line,226}]}]}
offender: [{pid,undefined},
   {id,jose_server},
   {mfargs,{jose_server,start_link,[]}},
   {restart_type,permanent},
   {significant,false},
   {shutdown,5000},
   {child_type,worker}]

2021-08-26 08:09:56.283141+02:00 [error] <0.494.0>@proc_lib:crash_report/4:525 
CRASH REPORT:
  crasher:
initial call: application_master:init/4
pid: <0.494.0>
registered_name: []
exception exit: {{shutdown,
 {failed_to_start_child,jose_server,
 {{case_clause,
  {'ECPrivateKey',1,
  <<104,152,88,12,19,82,251,156,171,31,222,
207,0,76,115,88,210,229,36,106,137,192,
81,153,154,254,226,38,247,70,226,157>>,
  {namedCurve,{1,2,840,10045,3,1,7}},
  <<4,46,75,29,46,150,77,222,40,220,159,
244,193,125,18,190,254,216,38,191,11,
52,115,159,213,230,77,27,131,94,17,46,
21,186,71,62,36,225,0,90,21,186,235,
132,152,229,13,189,196,121,64,84,64,
229,173,12,24,23,127,175,67,247,29,139,
91>>,
  asn1_NOVALUE}},
  [{jose_server,check_ec_key_mode,2,
   [{file,"jose_server.erl"},{line,189}]},
   {lists,foldl,3,
   [{file,"lists.erl"},{line,1267}]},
   {jose_server,support_check,0,
   [{file,"jose_server.erl"},{line,153}]},
   {jose_server,init,1,
   [{file,"jose_server.erl"},{line,93}]},
   {gen_server,init_it,2,
   [{file,"gen_server.erl"},{line,423}]},
   {gen_server,init_it,6,
   [{file,"gen_server.erl"},{line,390}]},
   {proc_lib,init_p_do_apply,3,
   [{file,"proc_lib.erl"},{line,226}]}]}}},
 {jose_app,start,[normal,[]]}}
  in function  application_master:init/4 (application_master.erl, line 142)
ancestors: [<0.493.0>]
message_queue_len: 1
messages: [{'EXIT',<0.495.0>,normal}]
links: [<0.493.0>,<0.44.0>]
dictionary: []
trap_exit: true
status: running
heap_size: 987
stack_size: 29
reductions: 160
  neighbours:

2021-08-26 08:09:56.284945+02:00 [notice] 
<0.44.0>@application_controller:info_exited/3:2101 application: jose
exited: {{shutdown,
 {failed_to_start_child,jose_server,
 {{case_clause,
  {'ECPrivateKey',1,
  <<104,152,88,12,19,82,251,156,171,31,222,207,0,
76,115,88,210,229,36,106,137,192,81,153,154,
254,226,38,247,70,226,157>>,

Bug#992133: firebird4.0 debian packaging

2021-08-26 Thread Damyan Ivanov

-=| Damyan Ivanov, 26.08.2021 09:34:04 +0300 |=-
> -=| Frank Doepper, 25.08.2021 16:58:15 +0200 |=-
> > Hi Damyan,
> > 
> > great that you are packaging firebird4.0 for Debian. Volker and I have tried
> > to build the source from
> > https://salsa.debian.org/firebird-team/firebird4.0/
> > with our mini-buildd on Debian Sid
> > at Tue, 17 Aug 2021 10:32:13 +
> > and it failed with a strange linker error:
> > 
> > /usr/bin/ld: g++  -g -O2
> > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
> > -Werror=format-security -DUCHAR_TYPE=uint16_t -fno-lifetime-dse
> > -fno-strict-aliasing -Wl,-z,relro -Wl,-z,now -Wl,-z,relro -Wl,-z,now
> > -pthread-Wl,--version-script,empty.vers
> > /<>/temp/Release/alice/alice.o
> > /<>/temp/Release/alice/alice_meta.o
> > /<>/temp/Release/alice/exe.o
> > /<>/temp/Release/alice/tdr.o
> > /<>/temp/Release/alice/main/aliceMain.o
> > /<>/temp/Release/common.a -o
> > /<>/gen/Release/firebird/bin/gfix
> > -L/<>/gen/Release/firebird/lib -lfbclient -ltommath -ltomcrypt
> > -latomic -lm -ldl   -ldecFloat -lre2
> > /<>/temp/Release/common.a(SimilarToRegex.o): in function
> > `Firebird::SimilarToRegex::matches(char const*, unsigned int,
> > Firebird::Array > Firebird::EmptyStorage >*)':
> > ./gen/./src/common/SimilarToRegex.cpp:858: undefined reference to 
> > `re2::RE2::Arg::parse_stringpiece(char const*, unsigned long, void*)'
> 
> Thanks for the notice.
> 
> This is probably related to the new g++ in sid. Trying the build today 
> failed even earlier, perhaps due to the new autotools. So this needs 
> more work.

Simply letting debhelper do the autoreconf seems to work and the build 
completes, no linker errors. This is in an up to date sid sbuild 
chroot.

-- Damyan

Bug#992712: apt-secure does not document how to accept new release info

2021-08-26 Thread David Kalnischkies

Control: forcemerge 879786 -1

On Sun, Aug 22, 2021 at 12:05:07PM -0400, Joey Hess wrote:
> This could be fixed by making the apt-secure man page include,
> in its "INFORMATION CHANGES" section, a mention of 
> apt-get update --allow-releaseinfo-change and/or of apt's ability to
> prompt the user in this situation.

The problem here is that apt-secure is – as it says early on – not about
apt{,-get}, but about the whole family. The message pointing to it is
equally printed for the whole family. Neither the message nor the
manpage can really say: Append this commandline flag and be done.
No such thing exists for e.g. GUIs like synaptics after all and it isn't
even yet implemented in aptitude.

And we can't really track the state of implementation in front ends
either to update each of their supposed sections with how to check some
checkboxes vs. click some buttons vs. type 'j' on the prompt vs. add
a commandline flag vs. … its sort of the job of the front ends to do
that and the apt-get manpage describes how.

We can't even really mention the config options here like in some other
cases as in this instance they can be completely overridden by the front
end. Only the default implementation actually reacts to the defaults.

Lastly, I actually envisioned that such changes would be accompanied
with release notes – the code is there to show an URI for more
information on the change, which could theoretically also describe how
to react to all this with the preferred package manager of the involved
distro/repo/whatever – but oh well, nobody ever wrote them or has set
the Release file flag for it…

I guess we could fiddle with the implementation (aka dirty hack) in the
apt and especially apt-get front end to show an apt specific message
about how you can add a command line flag. It feels like admitting
defeat, but I guess I will have to bite this bullet at some point
(again).

Note through that the N: message pointing to the manpage and any message
we could add are only shown if apt-get is connected to a terminal – aka
in interactive use. In that case you could just save at least four
keystrokes and have apt ask you interactively. ;)

Best regards

David Kalnischkies

signature.asc
Description: PGP signature

Bug#979458: Reassigning, merging and rising severity level of Bugs #979458 and #979459

2021-08-26 Thread Rafael Laboissière


* Rafael Laboissière  [2021-08-25 13:43]:


* Wookey  [2021-08-25 12:30]:


On 24/08/2021 07:45, Rafael Laboissière wrote:

I am hereby reassigning the Bugs #979458 and #979459, which were
assigned to the binary jed and jed-common packages, to the jed
source package. I am also merging this two bug reports and rising
their severity level to serious.

The trivial patch that fixes the problem is attached to this message.


Thanks Rafael.

I'm away on expedition with negligible internet until 12th Sept, so 
if anyone wishes to NMU this, that's fine by me. Otherwise it'll get 
done sometime after I get back.


Ok, I will NMU the new version.


It is done.

Would you mind if I add my changes to the Git repository at salsa.d.o? 
I will also add the changes for version 1:0.99.19-8, which are absent 
from the repository, if you agree.


I also pushed the changes to the repository at Salsa.d.o.

Enjoy your expedition!

Best,

Rafael Laboissière

Bug#992604: closed by Debian FTP Masters (reply to Dylan Aïssi ) (Bug#992604: fixed in wireplumber 0.4.2-2)

On Tue, 2021-08-24 at 10:51 +, Dylan Aïssi wrote:

> * Remove conffiles that moved to /usr/share/wireplumber/ (Closes: #992604)

Unfortunately this still didn't work for me, but given wireplumber is
only available in experimental, maybe it doesn't make sense to fix it.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#992980: gnome-shell complains if using lightdm

2021-08-26 Thread Grand T

This notification is a regression.
Here are my investigations
 /usr/lib/systemd/system/

gdm.service  => BusName=org.gnome.DisplayManager

lightdm.service =>  BusName=org.freedesktop.DisplayManager

Gnome-shell don't check yhe bus to talk to.

I suspect this is the cause

https://metadata.ftp-master.debian.org/changelogs//main/g/gnome-shell/gnome-shell_3.38.4-1_changelog

gnome-shell (3.33.90-1)
+ Call GDM’s RegisterSession() after startup (LP: #1798790)

Bug#993001: ejabberd: send_message API command is broken in 21.01 (fixed in 21.04+)

2021-08-26 Thread Daniel Gultsch

Package: ejabberd
Version: 21.01-2
Severity: important
X-Debbugs-Cc: dan...@gultsch.de

Dear Maintainer,

the API command `send_message` (available via ejabberd or the REST API)
is broken on ejabberd 21.01 (it was fixed upstream and the fix was
included 21.04)

The patch is very small and it should be possible to backport this to
21.01

The commit that fixes the issue is here:
https://github.com/processone/ejabberd/commit/b3d9c0d1f7f7037c1a22161c857c931f5e4b7ed3

An upstream bug report that tracks this problem is here:
https://github.com/processone/ejabberd/issues/3581

cheers
Daniel


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

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

Versions of packages ejabberd depends on:
ii  adduser 3.118
ii  debconf [debconf-2.0]   1.5.77
ii  erlang-asn1 1:23.2.6+dfsg-1
ii  erlang-base [erlang-abi]1:23.2.6+dfsg-1
ii  erlang-base64url1.0.1-5
ii  erlang-crypto   1:23.2.6+dfsg-1
ii  erlang-goldrush 0.2.0-7
ii  erlang-idna 6.1.1-3
ii  erlang-inets1:23.2.6+dfsg-1
ii  erlang-jiffy1.0.8+dfsg-3
ii  erlang-jose 1.11.1-3
ii  erlang-lager3.8.1-3
ii  erlang-mnesia   1:23.2.6+dfsg-1
ii  erlang-odbc 1:23.2.6+dfsg-1
ii  erlang-os-mon   1:23.2.6+dfsg-1
ii  erlang-p1-acme  1.0.11-2
ii  erlang-p1-cache-tab 1.0.27-2
ii  erlang-p1-eimp  1.0.19-2
ii  erlang-p1-mqtree1.0.12-2
ii  erlang-p1-pkix  1.0.7-3
ii  erlang-p1-stringprep1.0.24-3
ii  erlang-p1-stun  1.0.42-2
ii  erlang-p1-tls   1.1.11-2
ii  erlang-p1-utils 1.0.21-3
ii  erlang-p1-xml   1.1.45-3
ii  erlang-p1-xmpp  1.5.2-3
ii  erlang-p1-yaml  1.0.30-2
ii  erlang-p1-yconf 1.0.10-2
ii  erlang-p1-zlib  1.0.9-3
ii  erlang-public-key   1:23.2.6+dfsg-1
ii  erlang-ssl  1:23.2.6+dfsg-1
ii  erlang-syntax-tools 1:23.2.6+dfsg-1
ii  erlang-unicode-util-compat  0.7.0-3
ii  erlang-xmerl1:23.2.6+dfsg-1
ii  init-system-helpers 1.60
ii  lsb-base11.1.0
ii  openssl 1.1.1k-1+deb11u1
ii  ucf 3.0043

ejabberd recommends no packages.

Versions of packages ejabberd suggests:
pn  apparmor 
pn  apparmor-utils   
pn  ejabberd-contrib 
pn  erlang-luerl 
ii  erlang-p1-mysql  1.0.17-3
pn  erlang-p1-oauth2 
pn  erlang-p1-pam
pn  erlang-p1-pgsql  
pn  erlang-p1-sip
pn  erlang-p1-sqlite3
pn  erlang-redis-client  
pn  imagemagick  
pn  libunix-syslog-perl  
pn  yamllint 

-- debconf information:
  ejabberd/verify: (password omitted)
  ejabberd/password: (password omitted)
  ejabberd/user:
  ejabberd/invalidpreseed:
  ejabberd/nomatch:
  ejabberd/invalidhostname:
  ejabberd/invaliduser:
  ejabberd/erlangopts: -env ERL_CRASH_DUMP_BYTES 0
  ejabberd/hostname: localhost
  ejabberd/nodenamechanges:

Bug#992993: libapt-pkg6.0: infinite recursion in pkgDepCache::MarkPackage

2021-08-26 Thread David Kalnischkies

On Wed, Aug 25, 2021 at 09:30:13PM -0400, Aaron M. Ucko wrote:
> As of apt 2.3.8, most uses of libapt-pkg segfault; I can't even use

Please at least mention an example apt call. Is e.g.
apt full-upgrade -s   crashing?

If so (or if you find another invocation you can run in simulation or if
e.g. 'apt show' or 'policy' expose the crash) see if adding
  -o Dir::state::status=/dev/nulland/or
  -o Dir::State::extended_states=/dev/null
have any effect. (Don't append these on commands you run as root!)

We will likely need /var/lib/dpkg/status and
/var/lib/apt/extended_states from the effected system. You can sent them
to me privately if you don't want to attach them (compressed) publicly
to the bugreport. They contain the information which packages you have
installed and which of those are marked as automatically installed – so
they can be both large and considered private information.

> reportbug to submit this report!  The culprit appears to be infinite
> recursion in pkgDepCache::MarkPackage:

As an aside, the method is written as a giant recursive loop, so while
"infinite" is not desired, the recursion certainly is and as such the
information provided is not very enlightening.

>   at ../apt-pkg/depcache.cc:2406

Points at my changes in 2.3.3, especially "Mark only provides from
protected versioned kernel packages", as the most likely culprit.

Probably something obvious in hindsight, but at the moment I don't see
it yet. Works for me (of course) and is the first report about an issue
here…

Best regards

David Kalnischkies

signature.asc
Description: PGP signature

Bug#993007: ITP: ovn -- Open Virtual Network (OVN)

2021-08-26 Thread Thomas Goirand

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: ovn
  Version : 21.06.0+ds1
  Upstream Author : Nicira, Inc.
* URL : https://github.com/ovn-org/ovn
* License : Apache-2.0
  Programming Lang: C
  Description : Open Virtual Network (OVN)

 OVN, the Open Virtual Network, is a system to support virtual network
 abstraction. OVN complements the existing capabilities of OVS to add native
 support for virtual network abstractions, such as virtual L2 and L3 overlays
 and security groups.

Note: this used to be part of OVS (OpenVSwitch), but upstream decided to
separate it into multiple Git repository. Bullseye was shipped without OVN,
this is an atempt to get OVN back into Debian.

Bug#992999: ITP: unyt -- Python package for handling numpy arrays with units.

2021-08-26 Thread Ole Streicher


Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org, 
debian-as...@lists.debian.org, debian-scie...@lists.debian.org

* Package name: unyt
  Version : 2.8.0
  Upstream Author : Nathan Goldbaum
* URL : debian-de...@lists.debian.org
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Pyton package for handling numpy arrays with units.

Often writing code that deals with data that has units can be confusing.
A function might return an array but at least with plain NumPy arrays,
there is no way to easily tell what the units of the data are without
somehow knowing a priori.

The unyt package (pronounced like “unit”) provides a subclass of NumPy’s
ndarray class that knows about units.

It is a new build dependency of the "yt" package. I will maintain it
within the Debian Python team. Salsa dir is

https://salsa.debian.org/python-team/packages/unyt

Best regards

Ole

Bug#992133: firebird4.0 debian packaging

2021-08-26 Thread Damyan Ivanov

-=| Frank Doepper, 25.08.2021 16:58:15 +0200 |=-
> Hi Damyan,
> 
> great that you are packaging firebird4.0 for Debian. Volker and I have tried
> to build the source from
> https://salsa.debian.org/firebird-team/firebird4.0/
> with our mini-buildd on Debian Sid
> at Tue, 17 Aug 2021 10:32:13 +
> and it failed with a strange linker error:
> 
> /usr/bin/ld: g++  -g -O2
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security -DUCHAR_TYPE=uint16_t -fno-lifetime-dse
> -fno-strict-aliasing -Wl,-z,relro -Wl,-z,now -Wl,-z,relro -Wl,-z,now
> -pthread-Wl,--version-script,empty.vers
> /<>/temp/Release/alice/alice.o
> /<>/temp/Release/alice/alice_meta.o
> /<>/temp/Release/alice/exe.o
> /<>/temp/Release/alice/tdr.o
> /<>/temp/Release/alice/main/aliceMain.o
> /<>/temp/Release/common.a -o
> /<>/gen/Release/firebird/bin/gfix
> -L/<>/gen/Release/firebird/lib -lfbclient -ltommath -ltomcrypt
> -latomic -lm -ldl   -ldecFloat -lre2
> /<>/temp/Release/common.a(SimilarToRegex.o): in function
> `Firebird::SimilarToRegex::matches(char const*, unsigned int,
> Firebird::Array Firebird::EmptyStorage >*)':
> ./gen/./src/common/SimilarToRegex.cpp:858: undefined reference to 
> `re2::RE2::Arg::parse_stringpiece(char const*, unsigned long, void*)'

Thanks for the notice.

This is probably related to the new g++ in sid. Trying the build today 
failed even earlier, perhaps due to the new autotools. So this needs 
more work.

I am not sure when that work would happen. There is also work going 
upstream to fix the build on big-endian architectures. Help is 
welcome.


-- Damyan

Bug#992990: systemd: Does not clean up user session

2021-08-26 Thread Michael Biebl


Am 26.08.21 um 01:26 schrieb Samuel Thibault:

Package: systemd
Version: 247.3-6
Severity: normal

Hello,

It seems that the user sessions are not getting cleaned up when it
crashes unexpectedly, and notably the dbus session bus, which can lead
to various oddities. To reproduce:

- logging in from lightdm ($USER is ff)
- the MATE desktop starts
- the attached snapshot shows the dbus-daemon running: not only the ones
   for the ff user, but also for lightdm (!?)
- as root in a mate-terminal, run systemctl restart lightdm
- the MATE session thus gets completely interrupted, lightdm shows up
   again
- logging in again as $USER ff
- the MATE desktop starts
- the attached snapshot shows that it's still the same dbus-daemon
   running: again not only the ones for the ff user, but also for lightdm

These surviging processes are worrying: when a user is not connected,
should there really be such remainings?  I understand that a user may be
running e.g. screen sessions, but more than this?

I could check that systemd 249.3-3 from experimental behaves the same



First of all, I think what you mean here are login/logind sessions.

user sessions are defined by the lifetime of the systemd --user instance 
and there can only be one instance of systemd --user per user. user 
services are started by systemd --user and are shared between login 
sessions.


In your case, dbus-daemon is *not* started as a user service, but as a 
regular process within a login session, so there can be multiple ones.


systemd does have a facility `KillUserProcesses=yes` which kills all 
processes of such a login session, when the user logs out.
The upstream default is "yes" but in Debian we had complaints that this 
killed processes like screen, so we patch it to "no" as default in Debian.


So, we can't have it both ways unfortunately.

There is no way you can differentiate whether a process is "good" and 
should survive a logout or a lingering process is bad and should be killed.


The only way this could work is if processes would actually tell systemd 
this, e.g. screen could have used "systemd-run" to create an ephemeral 
scope unit. This suggestion was rejected by the screen 
maintainers/upstream afair.


So, with the current setup we can't please everyone.

Michael

Bug#991919: Bioconductor API Bump to 3.13

2021-08-26 Thread Paul Gevers

Hi Andreas,

On 26-08-2021 07:45, Andreas Tille wrote:
> Hi Dylan,
> 
> On Sun, Aug 15, 2021 at 01:17:29PM +0200, Andreas Tille wrote:
>> Hi,
>>
>> On Sun, Aug 15, 2021 at 10:01:21AM +0200, Dylan Aïssi wrote:
>>>
>>> The transition tracker is on at
>>> https://release.debian.org/transitions/html/r-api-bioc-3.13.html
>>>
>>> We are now waiting for the green-light from the release team (at
>>> https://bugs.debian.org/991919) to start the transition of
>>> bioconductor packages.
>>
>> Thanks for triggering this.  Meanwhile I'm starting upgrading
>> r-cran-packages from the end of the alphabeth (as traveling
>> connection permits).
> 
> The transition page seems to be setup by the release team.  When
> do you plan to start the transition?

If this question is to the release team, than the following question we
asked earlier requires an answer:
> What's the status wrt. to the reverse dependencies. Do those that are
> binNMU-able build against the new version?

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#992990: systemd: Does not clean up user session

2021-08-26 Thread Michael Biebl


From README.Debian:


KillUserProcesses behavior in Debian


If KillUserProcesses=yes is configured in logind.conf(5), the session scope
will be terminated when the user logs out of that session.

See logind.conf(5):

| Note that setting KillUserProcesses=yes will break tools like screen(1) and
| tmux(1), unless they are moved out of the session scope.

The default for KillUserProcesses in /etc/systemd/logind.conf is set
to "yes" in upstream systemd, though Debian defaults to "no" (see #825394).




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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#991919: Bioconductor API Bump to 3.13

2021-08-26 Thread Dylan Aïssi

Hi,

Le jeu. 26 août 2021 à 09:49, Paul Gevers  a écrit :
>
> If this question is to the release team, than the following question we
> asked earlier requires an answer:
> > What's the status wrt. to the reverse dependencies. Do those that are
> > binNMU-able build against the new version?
>

No, all these reverse dependencies need a manual upgrade with the new
upstream releases, they are not binNMU-able.
The Debian R Packages team will upgrade to the new upstream releases
all of the reverse dependencies.

Best,
Dylan

Bug#992997: milter-greylist: segfault in libGeoIP

2021-08-26 Thread BjÃ¸rn Mork

Package: milter-greylist
Version: 4.6.2-3
Severity: normal

Seeing lots of these after upgrading til bullseye:

Aug 23 22:12:23 louie kernel: milter-greylist[192919]: segfault at 28 ip 
7fbaf22fe8d9 sp 7fbaee77c670 error 4 in 
libGeoIP.so.1.6.12[7fbaf22fc000+1b000]
Aug 23 22:12:23 louie kernel: Code: 90 e9 6b d8 ff ff 66 66 2e 0f 1f 84 00 00 
00 00 00 48 85 f6 0f 84 8f 00 00 00 41 54 49 89 d4 53 48 89 fb 48 89 f7 48 83 
ec 08 <0f> be 43 28 3c 0c 74 4f 3c 12 74 4b 48 8b 3d cc 26 03 00 48 8d 35
Aug 24 22:45:40 louie kernel: milter-greylist[217578]: segfault at 28 ip 
7fcc2deb78d9 sp 7fcc2a335670 error 4 in 
libGeoIP.so.1.6.12[7fcc2deb5000+1b000]
Aug 24 22:45:40 louie kernel: Code: 90 e9 6b d8 ff ff 66 66 2e 0f 1f 84 00 00 
00 00 00 48 85 f6 0f 84 8f 00 00 00 41 54 49 89 d4 53 48 89 fb 48 89 f7 48 83 
ec 08 <0f> be 43 28 3c 0c 74 4f 3c 12 74 4b 48 8b 3d cc 26 03 00 48 8d 35
Aug 25 22:10:57 louie kernel: milter-greylist[240196]: segfault at 28 ip 
7f525900a8d9 sp 7f5255c89670 error 4 in 
libGeoIP.so.1.6.12[7f5259008000+1b000]
Aug 25 22:10:57 louie kernel: Code: 90 e9 6b d8 ff ff 66 66 2e 0f 1f 84 00 00 
00 00 00 48 85 f6 0f 84 8f 00 00 00 41 54 49 89 d4 53 48 89 fb 48 89 f7 48 83 
ec 08 <0f> be 43 28 3c 0c 74 4f 3c 12 74 4b 48 8b 3d cc 26 03 00 48 8d 35

Doesn't look too good, given that it's probably triggered by mail contents
somehow.


BjÃ¸rn

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/1 CPU thread)
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages milter-greylist depends on:
ii  adduser  3.118
ii  init-system-helpers  1.60
ii  libc62.31-13
ii  libcurl4 7.74.0-1.3+b1
ii  libgeoip11.6.12-7
ii  libmilter1.0.1   8.15.2-22
ii  libopendkim112.11.0~beta2-4
ii  libspf2-21.2.10-7.1~deb11u1
ii  lsb-base 11.1.0

Versions of packages milter-greylist recommends:
ii  sendmail  8.15.2-22

milter-greylist suggests no packages.

-- Configuration Files:
/etc/default/milter-greylist changed:
ENABLED=1

/etc/milter-greylist/greylist.conf changed:
pidfile "/var/run/milter-greylist.pid"
dumpfile "/var/lib/milter-greylist/greylist.db" 600
dumpfreq 2m
socket "/var/run/milter-greylist/milter-greylist.sock"
user "smmsp"
quiet
nospf
geoipdb "/usr/share/GeoIP/GeoIP.dat"
subnetmatch /23
subnetmatch6 /48
list "my network" addr { \
127.0.0.1/8 \
redacted\
}
list "my friends" addr {   \
redacted\
}
racl whitelist list "my network"
racl whitelist list "my friends"
racl greylist default delay 5m autowhite 30d


-- no debconf information

Bug#989684: Geeqie crashed on startup with "X Window System error"

2021-08-26 Thread Jörg Sommer

Andreas Ronnquist schrieb am Mi 25. Aug, 14:16 (+0200):
> Is this only affecting geeqie, or are you seeing it on other programs
> that use the clutter library?
> 
> You can find these by a command like
> 
>  sudo apt-cache rdepends libclutter-1.0

I can't tell. I don't use any of these programs.

Regards Jörg

-- 
Auch wenn man etwas oft wiederholt, wird es dadurch nicht richtig,
aber es setzt sich fest.


signature.asc
Description: PGP signature

Bug#983332: sane-utils: incorrectly identifies Wifi USB dongles as scanners

2021-08-26 Thread Martin-Éric Racine

$ lsusb
Bus 002 Device 019: ID 8564:4000 Transcend Information, Inc.
microSD/SD/CF UHS-II Card Reader [RDF8, RDF9]
Bus 002 Device 018: ID 076b:1021 OmniKey AG CardMan 1021
Bus 002 Device 017: ID 05e3:0605 Genesys Logic, Inc. Hub
Bus 002 Device 020: ID 04a9:2220 Canon, Inc. CanoScan LIDE 25
Bus 002 Device 016: ID 046d:c077 Logitech, Inc. M105 Optical Mouse
Bus 002 Device 003: ID 05e3:0607 Genesys Logic, Inc. Logitech G110 Hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 0411:00e8 BUFFALO INC. (formerly MelCo., Inc.)
WLI-UC-G300N Wireless LAN Adapter [Ralink RT2870]
Bus 001 Device 003: ID 0b05:179d ASUSTek Computer, Inc. USB-N53
802.11abgn Network Adapter [Ralink RT3572]
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Please go ahead and tell me which of these is not supported by the kernel.

to 26. elok. 2021 klo 9.14 Martin-Éric Racine
(martin-eric.rac...@iki.fi) kirjoitti:
>
> They are supported by the kernel. They work just fine as WiFi dongles.
>
> They simply are NOT scanning devices. SANE makes the wrong assumption.
> This has NOTHING to do with the kernel.
>
> to 26. elok. 2021 klo 8.58 Jörg Frings-Fürst (debian@jff.email) kirjoitti:
> >
> > reassign 983332  linux-signed-amd64
> > thanks
> >
> >
> > Hello,
> >
> > at [1] the device IDs 0x0b05, 0x179d and 0x0411, 0x00e8 are not listed.
> >
> > Both devices are not supported by kernel.
> >
> > I reassign this bug to linux-signed-amd64
> >
> > CU
> > Jörg
> >
> > [1] https://wiki.debian.org/DeviceDatabase/USB
> >
> > --
> > New:
> > GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
> > GPG key (long) : 09F89F3C8CA1D25D
> > GPG Key: 8CA1D25D
> > CAcert Key S/N : 0E:D4:56
> >
> > Old pgp Key: BE581B6E (revoked since 2014-12-31).
> >
> > Jörg Frings-Fürst
> > D-54470 Lieser
> >
> >
> > git:  https://jff.email/cgit/
> >
> > Threema: SYR8SJXB
> > Wire: @joergfringsfuerst
> > Skype: joergpenguin
> > Ring: jff
> > Telegram: @joergfringsfuerst
> >
> >
> > My wish list:
> >  - Please send me a picture from the nature at your home.
> >

Bug#989711: Version reported as 0.0.0

2021-08-26 Thread Antonio Valentino


The patch has been merged and it is included in numcodecs 0.8.1+ds.

--
Antonio Valentino

Bug#992034: installation-guide: Include a note on how to change init system during install

2021-08-26 Thread Matthew Vernon


Hi,

Could someone merge 
https://salsa.debian.org/installer-team/installation-guide/-/merge_requests/15 
please?


It's the smaller change that folk asked for :)

Thanks,

Matthew

Bug#992990: systemd: Does not clean up user session

2021-08-26 Thread Samuel Thibault

Michael Biebl, le jeu. 26 août 2021 09:13:02 +0200, a ecrit:
> There is no way you can differentiate whether a process is "good" and should
> survive a logout or a lingering process is bad and should be killed.
> 
> The only way this could work is if processes would actually tell systemd
> this, e.g. screen could have used "systemd-run" to create an ephemeral scope
> unit. This suggestion was rejected by the screen maintainers/upstream afair.
> 
> So, with the current setup we can't please everyone.

Ok :/

So we'll have to live with that.

Samuel

Bug#992133: firebird4.0 debian packaging

2021-08-26 Thread Frank Doepper


Am 26.08.21 um 10:40 schrieb Damyan Ivanov:

-=| Damyan Ivanov, 26.08.2021 09:34:04 +0300 |=-

-=| Frank Doepper, 25.08.2021 16:58:15 +0200 |=-

Hi Damyan,

great that you are packaging firebird4.0 for Debian. Volker and I have tried
to build the source from
https://salsa.debian.org/firebird-team/firebird4.0/
with our mini-buildd on Debian Sid
at Tue, 17 Aug 2021 10:32:13 +
and it failed with a strange linker error:

/usr/bin/ld: g++  -g -O2
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -DUCHAR_TYPE=uint16_t -fno-lifetime-dse
-fno-strict-aliasing -Wl,-z,relro -Wl,-z,now -Wl,-z,relro -Wl,-z,now
-pthread-Wl,--version-script,empty.vers
/<>/temp/Release/alice/alice.o
/<>/temp/Release/alice/alice_meta.o
/<>/temp/Release/alice/exe.o
/<>/temp/Release/alice/tdr.o
/<>/temp/Release/alice/main/aliceMain.o
/<>/temp/Release/common.a -o
/<>/gen/Release/firebird/bin/gfix
-L/<>/gen/Release/firebird/lib -lfbclient -ltommath -ltomcrypt
-latomic -lm -ldl   -ldecFloat -lre2
/<>/temp/Release/common.a(SimilarToRegex.o): in function
`Firebird::SimilarToRegex::matches(char const*, unsigned int,
Firebird::Array >*)':
./gen/./src/common/SimilarToRegex.cpp:858: undefined reference to 
`re2::RE2::Arg::parse_stringpiece(char const*, unsigned long, void*)'


Thanks for the notice.

This is probably related to the new g++ in sid. Trying the build today
failed even earlier, perhaps due to the new autotools. So this needs
more work.


Btw, it (commit 25af992) fails on bullseye the same way, but it succeeds 
on buster.


Simply letting debhelper do the autoreconf seems to work and the build 
completes, no linker errors. This is in an up to date sid sbuild chroot.


I tried this (commit f89edee), but it fails again on sid with the same 
libre2 linker error.


I think that's a clash between bundled libre2 and system libre2. Although 
configure is called with --with-system-re2, the flags contain 
-I/<>/extern/re2, and I guess that's the problem. Maybe 
debian/patches/out/system-re2.patch needs a second look at.


Viele Grüße,
Frank

Bug#993008: gnome-shell-extension-freon: gnome-shell dependency doesn't match metadata

Source: gnome-shell-extension-freon
Version: 44+dfsg-1
Severity: important

The metadata.json file says that the Freon extension version 44 is
compatible with gnome-shell 40 but debian/control says it cannot be
installed with gnome-shell 40.

https://salsa.debian.org/gnome-team/shell-extensions/gnome-shell-extension-freon/-/blob/master/freon@UshakovVasilii_Github.yahoo.com/metadata.json

Thanks,
Jeremy Bicha

Bug#978865: confused and unable to reproduce

2021-08-26 Thread Barak A. Pearlmutter

This doesn't seem like an autoconf issue, as the problem crops up
post-configuration. Unless I'm missing something. And, I'm unable to
reproduce it. Could you check if the version I just uploaded still
exhibits the problem?

Bug#990246: vlc: reproducible builds: Embeds build username and hostname in binaries

2021-08-26 Thread Fabian Greffrath


Sorry for my super-clever MUA adding line breaks on its own.

Bug#993013: zxing-cpp: please build Python wrapper package, include demo scripts as examples

Source: zxing-cpp
Version: 1.2.0-1
Severity: wishlist

Please build the Python wrapper in wrappers/python/ into a new package
called python3-zxingcpp.

This will be useful for people building Python applications that need
to process barcodes.

This needs passing -DBUILD_PYTHON_MODULE=ON via dh_auto_configure to
cmake as they are off by default, adding build deps, pkg install etc.

It unfortunately also needs a patch to switch from downloading the
pybind11 git repo to using the system version:

https://github.com/nu-book/zxing-cpp/issues/248

Please also include the demo scripts as examples in the package.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#993012: zxing-cpp: please build the example programs into a package