Bug#999447: Boinc won't resume from suspend when computer is not in use

[Sven K]

Package: boinc-manager
Version: 7.16.16+dfsg-1
Severity: important

maintainer,

I believe this is the correct package to report this bug to.

When option, "suspend when computer is in use," is set to, true, boinc never 
resumes from the suspended state, stating, indefinitely, 'suspended - computer is in use. 
 Obviously, if after the designated 3 minutes have elapsed without any keyboard or mouse 
input, the program should resume computing.  This does not happen.

The current kernel version is 5.10.0-9-amd64
The issue wasn't resolved by booting with the 5.10.0-8 kernel, either.

Current libc is libc-2.31.so

I tried completely purging the program, and reinstalling, and the problem 
persists.

I wouldn't think any, 'log,' information would be useful or relevant here, if I 
could find a log file for boinc-client; however, when changing settings and 
saving them in boinc-manager, the following output appears in syslog

Nov 10 22:59:30  boinc[6615]: 10-Nov-2021 22:59:30 [Rosetta@home] General 
prefs: from Rosetta@home (last modified 10-Nov-2021 21:18:48)
Nov 10 22:59:30  boinc[6615]: 10-Nov-2021 22:59:30 [Rosetta@home] Computer 
location: home
Nov 10 22:59:30  boinc[6615]: 10-Nov-2021 22:59:30 [Rosetta@home] General 
prefs: no separate prefs for home; using your defaults
Nov 10 22:59:30  boinc[6615]: 10-Nov-2021 22:59:30 [---] Reading preferences 
override file
Nov 10 22:59:30  boinc[6615]: 10-Nov-2021 22:59:30 [---] Preferences:
Nov 10 22:59:30  boinc[6615]: 10-Nov-2021 22:59:30 [---]max memory usage 
when active: 16053.88 MB
Nov 10 22:59:30  boinc[6615]: 10-Nov-2021 22:59:30 [---]max memory usage 
when idle: 25686.21 MB
Nov 10 22:59:30  boinc[6615]: 10-Nov-2021 22:59:30 [---]max disk usage: 
20.00 GB
Nov 10 22:59:30  boinc[6615]: 10-Nov-2021 22:59:30 [---]don't compute while 
active
Nov 10 22:59:30  boinc[6615]: 10-Nov-2021 22:59:30 [---]don't use GPU while 
active
Nov 10 22:59:30  boinc[6615]: 10-Nov-2021 22:59:30 [---]suspend work if 
non-BOINC CPU load exceeds 25%
Nov 10 22:59:30  boinc[6615]: 10-Nov-2021 22:59:30 [---](to change 
preferences, visit a project web site or select Preferences in the Manager)

That's about it.  Boinc won't resume from suspend when computer is not in use.

Bug#999399: preseed: Mention the current Debian version name instead of lenny

[Roland Clobus]

Hello,

On 10/11/2021 18:01, Holger Wansing wrote:

Am 10. November 2021 16:59:42 MEZ schrieb Roland Clobus :


Could this be replaced by either 'stable' or the current version name?
(If you choose the latter, would it then also need to be mentioned in the
'howto prepare the next Debian release' document?)


What exactly would be the rationale for such change?
That's all just examples, they will have to be adapted to user's
needs anyway ...


Rationale: I was surprised by finding a reference to a really old 
version of Debian (released in 2012) in the examples that have been 
provided.


There is no functional need to change the text. To me, it looks like a 
remnant of the earlier days of Debian, whose change was forgotten when 
the next release took place.
The word 'stable' will make it look more modern (and still 
translator-friendly).
I've marked this low-prio issue as 'cosmetic', please feel free to close 
it as WONTFIX.


With kind regards,
Roland Clobus



OpenPGP_signature
Description: OpenPGP digital signature

Bug#999420: dh_shlibdeps: Please consider option (or default) to ignore weak symbols for dependencies

[Niels Thykier]

Control: reassign -1 dpkg

Josh Triplett:
> Package: debhelper
> Version: 13.5.2
> Severity: wishlist
> File: /usr/bin/dh_shlibdeps
> X-Debbugs-Cc: j...@joshtriplett.org
> 
> When a program or library declares a weak symbol, that typically
> indicates that it's prepared to do without the symbol.
> 

Hi Josh,

Most of what you request in this bug happens (or requires support) in
the underlying dpkg tool, dpkg-shlibdeps.  I am therefore reassigning it
to dpkg.

Quoting the remaining text in full (below) for the sake of the dpkg
maintainer.

> However, dh_shlibdeps takes weak symbols into account when determining
> library dependencies, and will produce a strict Depends on a library
> even if only needed for a weak symbol. Some software (e.g. the Rust
> standard library) works around this by calling dlsym instead, but that
> introduces other potential issues, and weak symbols are *much* simpler
> and easier to work with.
> 
> I'd like to propose changing this behavior, either with an option, or as
> part of a future debhelper compatibility level (which could make that
> option the default). I'd propose instead that dh_shlibdeps could
> separate out dependencies from weak symbols, and put them in a separate
> substitution field, which packagers could then choose to put in either
> Depends or Recommends or Suggests or nowhere, as appropriate.
> 
> The net effect of this would be to broaden shared library dependencies,
> making packages easier to install and backport, and making it easier for
> upstreams to make use of weak symbols without introducing compatibility
> issues.
> 
> - Josh Triplett
> 

~Niels

Bug#999446: cups: Does not print a test page: I enter name and password, but does not accept them

[Advard]

Package: cups
Version: 2.3.3op2-7
Severity: normal

Dear Maintainer,

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

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

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


-- System Information:
Debian Release: 11.1
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable'), (500, 'testing'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages cups depends on:
ii  cups-client2.3.3op2-7
ii  cups-common2.3.3op2-7
ii  cups-core-drivers  2.3.3op2-7
ii  cups-daemon2.3.3op2-7
ii  cups-filters   1.28.7-1
ii  cups-ppdc  2.3.3op2-3+deb11u1
ii  cups-server-common 2.3.3op2-7
ii  debconf [debconf-2.0]  1.5.77
ii  ghostscript9.53.3~dfsg-7+deb11u1
ii  libavahi-client3   0.8-5
ii  libavahi-common3   0.8-5
ii  libc6  2.31-13+deb11u2
ii  libcups2   2.3.3op2-7
ii  libgcc-s1  10.2.1-6
ii  libstdc++6 10.2.1-6
ii  libusb-1.0-0   2:1.0.24-3
ii  poppler-utils  20.09.0-3.1
ii  procps 2:3.3.17-5

Versions of packages cups recommends:
ii  avahi-daemon  0.8-5
ii  colord1.4.5-3

Versions of packages cups suggests:
pn  cups-bsd 
pn  cups-pdf 
ii  foomatic-db  20200820-1
ii  smbclient2:4.13.5+dfsg-2
ii  udev 247.3-6

-- debconf information:
  cupsys/raw-print: true
  cupsys/backend: lpd, socket, usb, snmp, dnssd

In log file error_log:
E [11/Nov/2021:08:08:34 +0300] [Job 1] Files have gone away.
E [11/Nov/2021:08:09:25 +0300] [Client 1] Unable to encrypt connection: A TLS 
fatal alert has been received.
E [11/Nov/2021:08:09:25 +0300] [Client 2] Unable to encrypt connection: A TLS 
fatal alert has been received.
E [11/Nov/2021:08:09:31 +0300] [Client 5] Unable to encrypt connection: A TLS 
fatal alert has been received.
E [11/Nov/2021:08:09:35 +0300] [Client 7] Unable to encrypt connection: A TLS 
fatal alert has been received.
E [11/Nov/2021:08:09:35 +0300] [Client 8] Returning IPP 
client-error-not-authorized for Print-Job (ipp://localhost:631/printers/test) 
from localhost.
E [11/Nov/2021:08:09:41 +0300] [Client 9] Unable to encrypt connection: A TLS 
fatal alert has been received.
E [11/Nov/2021:08:09:41 +0300] [Client 11] Returning IPP 
client-error-not-authorized for Print-Job (ipp://localhost:631/printers/test) 
from localhost.
E [11/Nov/2021:08:09:51 +0300] [Client 12] Unable to encrypt connection: A TLS 
fatal alert has been received.
E [11/Nov/2021:08:32:31 +0300] [Client 16] Unable to encrypt connection: A TLS 
fatal alert has been received.
E [11/Nov/2021:08:32:31 +0300] [Client 17] Unable to encrypt connection: A TLS 
fatal alert has been received.
E [11/Nov/2021:08:33:31 +0300] [Client 20] Unable to encrypt connection: A TLS 
fatal alert has been received.
E [11/Nov/2021:08:33:32 +0300] [Client 22] Unable to encrypt connection: A TLS 
fatal alert has been received.
E [11/Nov/2021:08:33:35 +0300] [Client 24] Unable to encrypt connection: A TLS 
fatal alert has been received.
E [11/Nov/2021:08:33:35 +0300] [Client 25] Returning IPP 
client-error-not-authorized for Print-Job (ipp://localhost:631/printers/test) 
from localhost.

In access_log:
localhost - - [11/Nov/2021:08:09:35 +0300] "POST /printers/test HTTP/1.1" 200 
380 Print-Job client-error-not-authorized
localhost - - [11/Nov/2021:08:09:41 +0300] "POST /printers/test HTTP/1.1" 200 
409 Print-Job client-error-not-authorized
localhost - - [11/Nov/2021:08:33:35 +0300] "POST /printers/test HTTP/1.1" 200 
380 Print-Job client-error-not-authorized

Bug#999445: installation-reports: Successful install on Dell Latitude 7320

[Kumar Appaiah]

Package: installation-reports
Severity: normal

(Please provide enough information to help the Debian
maintainers evaluate the report efficiently - e.g., by filling
in the sections below.)

Boot method: USB
Image version: 
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/11.1.0+nonfree/amd64/jigdo-cd/firmware-11.1.0-amd64-netinst.jigdo
 2021-10-09
Date: 

Machine: Dell Latitude 7320 laptop
Partitions: 


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect media:   [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

Since hibernate doesn't work when secure boot is enabled, one cannot
hibernate currently. I haven't tried an encrypted swap partition yet.


-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="11 (bullseye) - installer build 20210731+deb11u1"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux redsun 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) 
x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 11th Gen Core 
Processor Host Bridge/DRAM Registers [8086:9a14] (rev 01)
lspci -knn: Subsystem: Dell Device [1028:0a34]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation UHD 
Graphics [8086:9a49] (rev 01)
lspci -knn: Subsystem: Dell Device [1028:0a34]
lspci -knn: 00:04.0 Signal processing controller [1180]: Intel Corporation 
Device [8086:9a03] (rev 01)
lspci -knn: Subsystem: Dell Device [1028:0a34]
lspci -knn: 00:06.0 PCI bridge [0604]: Intel Corporation 11th Gen Core 
Processor PCIe Controller [8086:9a09] (rev 01)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:07.0 PCI bridge [0604]: Intel Corporation Tiger Lake-LP 
Thunderbolt PCI Express Root Port #0 [8086:9a23] (rev 01)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:07.1 PCI bridge [0604]: Intel Corporation Tiger Lake-LP 
Thunderbolt PCI Express Root Port #1 [8086:9a25] (rev 01)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:0d.0 USB controller [0c03]: Intel Corporation Tiger Lake-LP 
Thunderbolt USB Controller [8086:9a13] (rev 01)
lspci -knn: Subsystem: Dell Device [1028:0a34]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:0d.2 USB controller [0c03]: Intel Corporation Tiger Lake-LP 
Thunderbolt NHI #0 [8086:9a1b] (rev 01)
lspci -knn: Subsystem: Device [:]
lspci -knn: 00:12.0 Serial controller [0700]: Intel Corporation Tiger Lake-LP 
Integrated Sensor Hub [8086:a0fc] (rev 20)
lspci -knn: Subsystem: Dell Device [1028:0a34]
lspci -knn: Kernel driver in use: intel_ish_ipc
lspci -knn: Kernel modules: intel_ish_ipc
lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Tiger Lake-LP USB 
3.2 Gen 2x1 xHCI Host Controller [8086:a0ed] (rev 20)
lspci -knn: Subsystem: Dell Device [1028:0a34]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:14.2 RAM memory [0500]: Intel Corporation Tiger Lake-LP Shared 
SRAM [8086:a0ef] (rev 20)
lspci -knn: Subsystem: Dell Device [1028:0a34]
lspci -knn: 00:14.3 Network controller [0280]: Intel Corporation Wi-Fi 6 AX201 
[8086:a0f0] (rev 20)
lspci -knn: Subsystem: Intel Corporation Device [8086:4070]
lspci -knn: Kernel driver in use: iwlwifi
lspci -knn: Kernel modules: iwlwifi
lspci -knn: 00:15.0 Serial bus controller [0c80]: Intel Corporation Tiger 
Lake-LP Serial IO I2C Controller #0 [8086:a0e8] (rev 20)
lspci -knn: Subsystem: Dell Device [1028:0a34]
lspci -knn: 00:15.1 Serial bus controller [0c80]: Intel Corporation Tiger 
Lake-LP Serial IO I2C Controller #1 [8086:a0e9] (rev 20)
lspci -knn: Subsystem: Dell Device [1028:0a34]
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation Tiger 
Lake-LP Management Engine Interface [8086:a0e0] (rev 20)
lspci -knn: Subsystem: Dell Device [1028:0a34]
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:a0be] 
(rev 20)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation Tiger Lake-LP LPC 
Controller [8086:a082] (rev 20)
lspci -knn: Subsystem: Dell Device [1028:0a34]
lspci -knn: 00:1f.3 Audio device [0403]: Intel Corporation Tiger Lake-LP Smart 
Sound Technology Audio Controller [8086:a0c8] (rev 20)
lspci -knn: Subsystem: Dell Device [

Bug#999431: zydis: CVE-2021-41253

[Salvatore Bonaccorso]

Hi Andrea,

On Thu, Nov 11, 2021 at 07:37:20AM +0100, Andrea Pappacoda wrote:
> Hi, thank you for the report. I'll update the package as soon as
> possible. 
> 
> Please note that I'm not yet an expert in packaging and security
> issues (I'm not even a Debian Maintainer), so please don't hesitate
> to correct me if I get something wrong :) 

Don't worry take the time needed. The package just entered yesterday
the archive, so I guess the easiest thing (and given it's not a too
high severity issue) will be to just update to a new upstream version
and let that go into testing instread of cherry-picking a fix.

Thank you for working on the package!

Ciao ;-)
Salvatore

Bug#999444: ruby3.0: Please disable some tests on alpha

[John Paul Adrian Glaubitz]

Source: ruby3.0
Version: 3.0.2-5
Severity: normal
Tags: patch
User: debian-al...@lists.debian.org
Usertags: alpha
X-Debbugs-Cc: debian-al...@lists.debian.org

Hello!

A small number of tests is failing specifically on alpha. Disabling them
allows the testsuite to pass. Could you apply the attached patch for the
next upload so that ruby3.0 is fixed on alpha?

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
diff -Nru old/ruby3.0-3.0.2/debian/tests/excludes/alpha/TestBugReporter.rb 
new/ruby3.0-3.0.2/debian/tests/excludes/alpha/TestBugReporter.rb
--- old/ruby3.0-3.0.2/debian/tests/excludes/alpha/TestBugReporter.rb
1970-01-01 01:00:00.0 +0100
+++ new/ruby3.0-3.0.2/debian/tests/excludes/alpha/TestBugReporter.rb
2021-11-10 23:53:44.685985756 +0100
@@ -0,0 +1 @@
+exclude :test_bug_reporter_add, 'fails, ENOTIME to investigate'
diff -Nru old/ruby3.0-3.0.2/debian/tests/excludes/alpha/TestJIT.rb 
new/ruby3.0-3.0.2/debian/tests/excludes/alpha/TestJIT.rb
--- old/ruby3.0-3.0.2/debian/tests/excludes/alpha/TestJIT.rb1970-01-01 
01:00:00.0 +0100
+++ new/ruby3.0-3.0.2/debian/tests/excludes/alpha/TestJIT.rb2021-11-10 
23:53:44.689985737 +0100
@@ -0,0 +1,2 @@
+exclude :test_compile_insn_local, 'fails, ENOTIME to investigate'
+exclude :test_compile_insn_newarray, 'fails, ENOTIME to investigate'
diff -Nru old/ruby3.0-3.0.2/debian/tests/excludes/alpha/TestRubyOptions.rb 
new/ruby3.0-3.0.2/debian/tests/excludes/alpha/TestRubyOptions.rb
--- old/ruby3.0-3.0.2/debian/tests/excludes/alpha/TestRubyOptions.rb
1970-01-01 01:00:00.0 +0100
+++ new/ruby3.0-3.0.2/debian/tests/excludes/alpha/TestRubyOptions.rb
2021-11-10 23:53:44.689985737 +0100
@@ -0,0 +1,3 @@
+exclude :test_segv_loaded_features, 'fails, ENOTIME to investigate'
+exclude :test_segv_setproctitle, 'fails, ENOTIME to investigate'
+exclude :test_segv_test, 'fails, ENOTIME to investigate'
diff -Nru old/ruby3.0-3.0.2/debian/tests/excludes/alpha/TestTmpdir.rb 
new/ruby3.0-3.0.2/debian/tests/excludes/alpha/TestTmpdir.rb
--- old/ruby3.0-3.0.2/debian/tests/excludes/alpha/TestTmpdir.rb 1970-01-01 
01:00:00.0 +0100
+++ new/ruby3.0-3.0.2/debian/tests/excludes/alpha/TestTmpdir.rb 2021-11-10 
23:53:44.693985717 +0100
@@ -0,0 +1 @@
+exclude :test_world_writable, 'fails, ENOTIME to investigate'

Bug#999431: zydis: CVE-2021-41253

[Andrea Pappacoda]

Hi, thank you for the report. I'll update the package as soon as possible. 

Please note that I'm not yet an expert in packaging and security issues (I'm 
not even a Debian Maintainer), so please don't hesitate to correct me if I get 
something wrong :) 
Thanks.

Bug#999364: libseccomp ftbfs with Python 3.10

[Graham Inggs]

Control: tags -1 + patch

Patch at:
https://launchpadlibrarian.net/568282351/libseccomp_2.5.2-2ubuntu1_2.5.2-2ubuntu2.diff.gz

Bug#997016: RFS: swtpm/0.7.0-rc2-1 [ITA] -- Libtpms-based TPM emulator

[Seunghun Han]

Hi Bastian,

On Sun, Nov 7, 2021 at 6:03 AM Bastian Germann  wrote:
> No, that can be done later. But I don't like the raised issue about the 
> manpages sections.
> The *.conf and *.options belong to section 5 instead of 8. Please hand in a 
> patch upstream and then
> import it as a quilt patch (if there is no upstream release in between).
I'm making a patch related to this issue. After pushing it to the
upstream, I will import it as a quilt patch.

> The code is authored (mostly) by Stefan Berger but copyrighted by IBM. For 
> the BSD-3-clause license,
> the copyright notices have to be documented, not the author notices. Please 
> correct that in
> d/copyright. Also the copyright year seem to range from 2006 to 2021.
>
> configure.ac is CPL-licensed. Please document this in d/copyright.
I missed this point. Thank you, and I will also change them and
contact you soon.

Best regards,

Seunghun

Bug#999442: systemd: reproducible hang on upgrade, in try-restart systemd-networkd.service

[Martin Dorey]

After an upgrade to systemd 247.3-6~bpo10+1 from buster-backports, I can no 
longer reproduce the problem in 15+ minutes of trying, when it always took less 
than 1 minute before.  I think it's fixed.  Sorry for the noise.

Starting at:

https://bugzilla.redhat.com/show_bug.cgi?id=1845456
systemctl try-restart command hangs indefinitely while being executed during a 
yum update

... I think the fix might have been:

https://github.com/systemd/systemd/pull/13124
core: coldplug possible nop_job

That's not in:

https://github.com/systemd/systemd/blob/v243/src/core/unit.c#L3925

... but is at:

https://github.com/systemd/systemd/blob/v244/src/core/unit.c#L3894

Bug#999443: pulseaudio: Muted microphone is unmuted when resuming from sleep

[Ben Goodwin]

Package: pulseaudio
Version: 15.0+dfsg1-2
Severity: normal
X-Debbugs-Cc: vbgoodw...@gmail.com

My computer's internal microphone does not remain muted after
resuming from sleep (suspended to memory).

Steps to reproduce:

1. mute microphone via pactl or pavucontrol
2. put computer to sleep by suspending to memory
3. wake computer
4. unlock computer at lightdm prompt

Result:   microphone is no longer muted
Expected: microphone should still be muted


-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


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

Kernel: Linux 5.14.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 pulseaudio depends on:
ii  adduser  3.118
ii  init-system-helpers  1.60
ii  libasound2   1.2.5.1-1
ii  libasound2-plugins   1.2.5-2
ii  libc62.32-4
ii  libcap2  1:2.44-1
ii  libdbus-1-3  1.12.20-3
ii  libfftw3-single3 3.3.8-2
ii  libgcc-s111.2.0-10
ii  libglib2.0-0 2.70.1-1
ii  libice6  2:1.0.10-1
ii  libltdl7 2.4.6-15
ii  liborc-0.4-0 1:0.4.32-1
ii  libpulse015.0+dfsg1-2
ii  libsm6   2:1.2.3-1
ii  libsndfile1  1.0.31-2
ii  libsoxr0 0.1.3-4
ii  libspeexdsp1 1.2~rc1.2-1.1
ii  libstdc++6   11.2.0-10
ii  libsystemd0  249.5-2
ii  libtdb1  1.4.3-1+b1
ii  libudev1 249.5-2
ii  libwebrtc-audio-processing1  0.3-1+b1
ii  libx11-6 2:1.7.2-2+b1
ii  libx11-xcb1  2:1.7.2-2+b1
ii  libxcb1  1.14-3
ii  libxtst6 2:1.2.3-1
ii  lsb-base 11.1.0
ii  pulseaudio-utils 15.0+dfsg1-2

Versions of packages pulseaudio recommends:
ii  dbus-user-session1.12.20-3
ii  libpam-systemd [logind]  249.5-2
ii  rtkit0.13-4

Versions of packages pulseaudio suggests:
pn  paprefs  
ii  pavucontrol  5.0-2
pn  pavumeter
ii  udev 249.5-2

-- no debconf information
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB

; auto-connect-localhost = no
; auto-connect-display = no
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for the PulseAudio daemon. See pulse-daemon.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; daemonize = no
; fail = yes
; allow-module-loading = yes
; allow-exit = yes
; use-pid-file = yes
; system-instance = no
; local-server-type = user
; enable-shm = yes
; enable-memfd = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB
; lock-memory = no
; cpu-limit = no

; high-priority = yes
; nice-level = -11

Bug#994335: pynfft: Removal of the python3-*-dbg packages in sid/bookworm

[Sandro Tosi]

control: severity -1 serious

On Wed, 15 Sep 2021 10:37:58 + Matthias Klose  wrote:
> Package: src:pynfft
> Version: 1.3.2-3
> Severity: serious
> Tags: sid bookworm
> User: debian-pyt...@lists.debian.org
> Usertags: pydbg-removal
>
> Python 3.8 upstream now has a common ABI for normal and debug
> extension builds, so we can drop the python3-*-dbg packages.
> Details at
> https://lists.debian.org/debian-python/2021/09/msg4.html
>
> Stop building the python3-*-dbg package, but be careful
> that all the reverse dependencies are also removed.

please remove python3-pynfft-dbg it's now a leaf package and it's
blocking the removal of python3-numpy-dbg

Bug#994304: libgpuarray: Removal of the python3-*-dbg packages in sid/bookworm

[Sandro Tosi]

control: severity -1 serious

On Wed, 15 Sep 2021 10:37:26 + Matthias Klose  wrote:
> Package: src:libgpuarray
> Version: 0.7.6-6
> Severity: serious
> Tags: sid bookworm
> User: debian-pyt...@lists.debian.org
> Usertags: pydbg-removal
>
> Python 3.8 upstream now has a common ABI for normal and debug
> extension builds, so we can drop the python3-*-dbg packages.
> Details at
> https://lists.debian.org/debian-python/2021/09/msg4.html
>
> Stop building the python3-*-dbg package, but be careful
> that all the reverse dependencies are also removed.

please do remove python3-pygpu-dbg, it is now a leaf package and it's
blocking the removal of python3-numpy-dbg

Bug#999441: selinux-policy-default: SELinux prevents dbus and firewalld from running properly

[Blake Lee]

Package: selinux-policy-default
Version: 2:2.20210203-10
Severity: important

Dear Maintainer,

On a fresh install of Debian sid I installed firewalld and selinux.
I rebooted to allow the system to do the autorelabling. Once done and the 
system came back up I got an error about dbus and firewalld would not start.

I added modules using audit2allow and was able to get dbus to come up but I was
unable to get firewalld to operate fully, I did get it to start at least.
Commands like firewall-cmd --state doesn't work. Everything I tested was working
fine in permissive mode. I'll paste my .te files created from audit2allow for 
you.

module dbus 1.0;

require {
type system_dbusd_t;
type security_t;
class file map;
}

#= system_dbusd_t ==
allow system_dbusd_t security_t:file map;


This firewalld one has an extra one that was causing an error too, I'm not sure 
if
it has any weight on what is going on, but the null was making it hard to make 
a module
I had to `cat /var/log/audit/audit.log | grep firewalld_t | grep -v null | 
audit2allow`

module firewalld_volian. 1.0;

require {
type xdg_data_t;
type lib_t;
type firewalld_etc_rw_t;
type firewalld_t;
type sysctl_kernel_t;
type unconfined_t;
type tmpfs_t;
type kernel_t;
type user_home_dir_t;
class dir { search watch };
class file { execute map open read write };
class netlink_netfilter_socket { create getopt read setopt write };
class process { getcap setcap };
class capability setpcap;
class (null) 0x2;
class system module_request;
}

#= firewalld_t ==

allow firewalld_t firewalld_etc_rw_t:dir watch;
allow firewalld_t kernel_t:system module_request;
allow firewalld_t lib_t:dir watch;
allow firewalld_t self:capability setpcap;
allow firewalld_t self:netlink_netfilter_socket { create getopt read setopt 
write };
allow firewalld_t self:process { getcap setcap };
allow firewalld_t sysctl_kernel_t:dir search;
allow firewalld_t sysctl_kernel_t:file { open read };
allow firewalld_t tmpfs_t:file { map write };
allow firewalld_t tmpfs_t:file { execute read };
allow firewalld_t unconfined_t:(null) 0x2;
allow firewalld_t user_home_dir_t:dir search;
allow firewalld_t xdg_data_t:dir search;

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

Kernel: Linux 5.14.0-4-amd64 (SMP w/8 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)
LSM: SELinux: enabled - Mode: Enforcing - Policy name: default

Versions of packages selinux-policy-default depends on:
ii  libselinux1  3.3-1
ii  libsemanage2 3.3-1
ii  libsepol23.3-1
ii  policycoreutils  3.3-1
ii  selinux-utils3.3-1

Versions of packages selinux-policy-default recommends:
ii  checkpolicy  3.3-1
ii  setools  4.4.0-1

Versions of packages selinux-policy-default suggests:
pn  logcheck
pn  syslog-summary  

-- no debconf information

Bug#999440: golang-github-containerd-stargz-snapshotter: Build access network

[Shengjing Zhu]

Source: golang-github-containerd-stargz-snapshotter
Version: 0.8.0-3
Severity: serious
X-Debbugs-Cc: z...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=golang-github-containerd-stargz-snapshotter&arch=all&ver=0.8.0-4&stamp=1636327998&raw=0

=== RUN   TestLayerConvertFunc
estargz_test.go:37: Get 
"https://github.com/AkihiroSuda/test-oci-archives/releases/download/v20210101/hello-world.tar.gz":
 dial tcp 140.82.121.3:443: connect: network is unreachable
--- FAIL: TestLayerConvertFunc (0.13s)
FAIL
FAILgithub.com/containerd/stargz-snapshotter/nativeconverter/estargz
0.170s
=== RUN   TestLayerConvertFunc
zstdchunked_test.go:40: Get 
"https://github.com/AkihiroSuda/test-oci-archives/releases/download/v20210101/hello-world.tar.gz":
 dial tcp 140.82.121.3:443: connect: network is unreachable
--- FAIL: TestLayerConvertFunc (0.00s)
FAIL

Bug#998358: Subject: grepmail: autopkgtest doesn't do anything

[Eriberto]

Em qua., 10 de nov. de 2021 às 18:55, Paul Gevers  escreveu:
>
> Hi Eriberto,
>
> On Tue, 2 Nov 2021 19:57:37 -0300 Eriberto  wrote:
> > ow, Marcos will package the new upstream
> > release and he will fix this mistake. In a final action, he will send
> > a SPU to fix a specific issue.
>
> Please be aware that grepmail will be removed from testing in 7 days if
> the issue isn't fixed. Obviously, the package can come back later too,
> but just so you know.

Thanks Paul.  Marcos is a bit busy these days, so I will fix this issue now.

Regards,

Eriberto

Bug#999423: powerdevil does not detect if on ac or battery

[Norbert Preining]

Hi Michael,

> Powerdevil doesn't detect If i'm on AC or not. It always shows that the
> powercord is plugged in. Doesn't matter if I unplug it or not.

Strange. It works for me.
Did you do a kernel upgrade in recent months?

There is a bug report that describes something similar:
https://bugzilla.kernel.org/show_bug.cgi?id=210425
https://gitlab.freedesktop.org/upower/upower/-/issues/126

> tlp does detect it correctly and at least sets everything else correctly.

That would point into the direction of the gitlab issue that some
signals are not sent.

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Fujitsu Research  +  IFMGA Guide  +  TU Wien  +  TeX Live  + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#997942: tomboy-ng: FTBFS with fpc 3.2.2

[David Bannon]

On Tue, 2021-11-09 at 22:56 +1100, David Bannon wrote:
> No, sorry, I cannot do a sensible test of my app using FPC and/or
> Lazarus from sid.
> 
> I can install FPC3.2.2 from Sid by using priorities.
> 
> But the Lazarus in Sid is non functional, blocked, because of an
> issue 

OK, I have made this work. Instead of cherry picking just fpc and
lazarus from Sid, I 'updated' my whole Testing (VM) install to Sid and
that worked as expected.

Tests all passed, I will push it up, as a new release (closing this
ticket) as soon as I get a fresh Spanish translation. My translator is
sometimes out of direct contact so not sure how long that will be.

Davo 

Bug#994316: numpy: Removal of the python3-*-dbg packages in sid/bookworm

[Drew Parsons]

Source: numpy
Followup-For: Bug #994316

Reminder here to consider revising the install files once -dbg is
removed.

At the moment all submodules are listed explicitly (on separate lines) in
debian/python3-numpy.install

This means that if numpy adds new functionality (a new submodule), it
will be missing (not installed) in the debian package.  This happened
recently with numpy.typing (Bug#998109).

As far as I can see the packaging could be simplified by replacing all the
separate submodule entries in debian/python3-numpy.install with a single
  usr/lib/python3*/*-packages/numpy/


Drew

Bug#999438: diffoscope: issues with XML files not named *.xml

[Paul Wise]

Package: diffoscope
Version: 190
Severity: normal

There are two issues with XML files not named *.xml:

They don't get reformatted before comparison, resulting in a diff of
the plain text, instead of a diff of the reformatted XML.

When comparing them with XML files named *.xml, a comparison of the
bytes is done, resulting in a diff of two hex dumps, instead of a diff
of the reformatted XML or a diff of the plain text. The reformatted XML
would be the best thing to diff, but plain text should be a fallback.

The xmllint tool can reformat them just fine and the file tool can
detect them as XML and detect their MIME type, so this issue is likely
to be a problem in the diffoscope code.

   $ head -vn-0 test-{old,new}.xml 
   ==> test-old.xml <==
   
   
   
   
   
   
   
   
   ==> test-new.xml <==
   
   
   
   
   
   
   
   
   
   
   $ diffoscope test-{old,new}.xml 
   --- test-old.xml
   +++ test-new.xml
   │   --- test-old.xml
   ├── +++ test-new.xml
   │ @@ -1,6 +1,8 @@
   │  
   │  
   │    
   │ -    
   │ +    
   │ +  
   │ +    
   │    
   │  
   
   $ cp test-new.xml test-new.not-xml
   
   $ cp test-old.xml test-old.not-xml
   
   $ diffoscope test-{old,new}.not-xml 
   --- test-old.not-xml
   +++ test-new.not-xml
   @@ -1,7 +1,9 @@
    
    
    
    
   +
   +
    
    
    
   
   $ diffoscope test-old.xml test-new.not-xml 
   --- test-old.xml
   +++ test-new.not-xml
   @@ -1,5 +1,6 @@
    : 3c3f 786d 6c20 7665 7273 696f 6e3d 2231  
   -0040: 0a3c 2f66 6f6f 3e0a 3c2f 7465 7374 3e0a  ...
   +0030: 6f6f 3e0a 3c62 6172 3e0a 3c62 617a 3e0a  oo>...
   +0040: 3c2f 6261 7a3e 0a3c 2f62 6172 3e0a 3c2f  
   
   $ diffoscope test-old.not-xml test-new.xml 
   --- test-old.not-xml
   +++ test-new.xml
   @@ -1,5 +1,6 @@
    : 3c3f 786d 6c20 7665 7273 696f 6e3d 2231  
   -0040: 0a3c 2f66 6f6f 3e0a 3c2f 7465 7374 3e0a  ...
   +0030: 6f6f 3e0a 3c62 6172 3e0a 3c62 617a 3e0a  oo>...
   +0040: 3c2f 6261 7a3e 0a3c 2f62 6172 3e0a 3c2f  
   
   $ xmllint --format test-old.xml
   
   
 
   
   
 
   
   
   $ xmllint --format test-new.xml
   
   
 
   
 
   
   
 
   
   
   $ xmllint --format test-old.not-xml
   
   
 
   
   
 
   
   
   $ xmllint --format test-new.not-xml
   
   
 
   
 
   
   
 
   

   $ file test-*
   test-new.not-xml: XML 1.0 document, ASCII text
   test-new.xml: XML 1.0 document, ASCII text
   test-old.not-xml: XML 1.0 document, ASCII text
   test-old.xml: XML 1.0 document, ASCII text
   
   $ file --mime test-*
   test-new.not-xml: text/xml; charset=us-ascii
   test-new.xml: text/xml; charset=us-ascii
   test-old.not-xml: text/xml; charset=us-ascii
   test-old.xml: text/xml; charset=us-ascii
   
-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (860, 
'testing-proposed-updates-debug'), (860, 'testing-proposed-updates'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages diffoscope depends on:
ii  diffoscope-minimal  190

Versions of packages diffoscope recommends:
ii  abootimg 0.6-1+b2
ii  acl  2.3.1-1
ii  androguard   3.4.0~a1-1
ii  apksigner    30.0.3-4
ii  apktool  2.5.0+dfsg.1-2
ii  binutils-multiarch   2.37-7
ii  bzip2    1.0.8-4
ii  caca-utils   0.99.beta19-2.2
ii  colord   1.4.5-3
ii  db-util  5.3.1+nmu1
ii  default-jdk [java-sdk]   2:1.11-72
ii  default-jdk-headless 2:1.11-72
pn  device-tree-compiler 
pn  docx2txt 
ii  e2fsprogs    1.46.4-1
ii  enjarify 1:1.0.3-5
ii  ffmpeg   7:4.4.1-1+b1
ii  fontforge-extras 1:20201107~dfsg-4
pn  fp-utils 
ii  genisoimage  9:1.1.11-3.2
ii  gettext  0.21-4
ii  ghc  8.8.4-3
ii  ghostscript  9.54.0~dfsg-5
ii  giflib-tools 5.1.9-2
ii  gnumeric 1.12.50-1
ii  gnupg    2.2.27-2
ii  gnupg-utils  2.2.27-2
pn  hdf5-tools   
ii  imagemagick  8:6.9.11.60+dfsg-1.3
ii  imagemagick-6.q16 [image

Bug#993294: Bug#998903: src:libidn: fails to migrate to testing for too long

[Sunil Mohan Adapa]

On 11/10/21 16:25, Simon Josefsson wrote:

James Valleroy via "Discussion list for GNU Internationalized Domain
Name library (Libidn)"  writes:


On 11/10/21 6:40 AM, Simon Josefsson wrote:

James, what do you think?  Is the libidn11-java package important for
you to have in Debian?  My perception was that nobody really used it,
and IDNA2003/StringPrep is old technology so it feels strange that new
code is coming around using.  While I am also upstream of this Java
code, I'm not familiar with how Java stuff is packaged/used in Debian,
and maybe there is another way of doing things that is just as easy for
you.


Hello,

(Adding Sunil who did most of the packaging work for libjxmpp-java.)

libjxmpp-java was packaged as a dependency of jitsi-videobridge.
Specifically for Jitsi we need the -core, -jid, and -util-cache modules.

It looks like libidn is only used for jxmpp-stringprep-libidn module.
Possibly we can disable building this module.


Is it not used by anything else?  If so, I agree it makes sense to
disable it, unless you think it is useful elsewhere.  I could add
libidn11-java back if there is real usage of it, but if it is not needed
for anything particular right now, I would prefer if you disable it
until there is real interest in using it.  When/if that occurs, we can
always add libidn11-java and jxmpp-stringprep-libidn back again.
Hopefully, XMPP will be updated to use something newer than StringPrep
meanwhile.



Simon, thank you for offering to build the library again if needed.

My understanding was that one of the three stringprep implementations is 
needed to use the jxmpp library. They are based on libidn, icu4j and 
rocksxmppprecis. Of these, we have only built the stringprep library 
based on libidn and assumed it to be critical.


However, I dug up a bit more in jitsi-xmpp-extenstions and other 
jitsi-videobridge code. To use the jxmpp-stringprep-libidn library one 
needs to import the class and call setup() on it. This does seem to be 
happening anywhere as far as I can tell. In this case, the jxmpp library 
seems to use a fallback implementation. It appears we can drop building 
the library jxmpp-stringprep-libidn although I can't say for sure 
without going through jitsi and all of its dependencies more thoroughly.


When we progress more on the packaging effort we might know better and 
can then request libidn to build libidn11-java again.


James, let us drop building jxmpp-stringprep-libidn for now and drop 
dependency on libidn11-java.


Thanks,

--
Sunil

Bug#999437: ncurses-bin: the clear(1) man page is inaccurate

[Vincent Lefevre]

Package: ncurses-bin
Version: 6.2+20210905-1
Severity: minor

The clear(1) man page says:

  clear clears your screen if this is possible, including its
  scrollback buffer (if the extended “E3” capability is defined).

but when the current screen is the alternate screen, the
scrollback buffer still corresponds to the main screen (and
not to the alternate screen). So the "its" is inaccurate and
should be replaced by "the" to match the observed behavior:

  clear clears your screen if this is possible, including the
  scrollback buffer (if the extended “E3” capability is defined).

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

Kernel: Linux 5.14.0-4-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 ncurses-bin depends on:
ii  libc6  2.32-4
ii  libtinfo6  6.2+20210905-1

ncurses-bin recommends no packages.

ncurses-bin suggests no packages.

-- no debconf information

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

Bug#999435: APT::Default-Release "bullseye" disables bullseye-security

[Matt Corallo]

Package: apt
Version: 2.2.4

Default-Release now prefers the main archive over the security archive. This seems to be a behavior 
change from buster, presumably due to the renaming of the -security archive. eg


# apt-cache policy dnsutils
dnsutils:
  Installed: (none)
  Candidate: 1:9.16.15-1
  Version table:
 1:9.16.22-1~deb11u1 500
500 http://security.debian.org/debian-security bullseye-security/main 
arm64 Packages
 1:9.16.15-1 990
990 http://deb.debian.org/debian bullseye/main arm64 Packages

Bug#887834: mpd installation fails, cannot open /var/lib/mpd/tag_cache, /run/mpd/pid

[Diederik de Haas]

On Fri, 5 Nov 2021 05:55:52 +0100 Florian Schlichting  wrote:
> Hi Ryan (and Max please see below):
> 
> please, for now, delete or comment out the pid_file line

I'm responding to this bug as commenting out the pid_file line was the solution
for me too, but my 'symptoms' are (a bit) different.

For me it wasn't a new install of mpd, but an upgrade:
root@soundserver:~# grep 'upgrade mpd' /var/log/dpkg.log
2021-11-10 21:03:37 upgrade mpd:arm64 0.22.10-1+b1 0.23.3-2

The system upgrade brought a lot of updated and also new packages (pipewire),
but in hindsight it's probably not important. I also installed a new kernel and
therefor rebooted my system.

After reboot I noticed a problem with mpd:
diederik@soundserver:~$ systemctl | grep -i fail
● mpd.service  loaded failed failedMusic Player Daemon
● mpd.socket   loaded failed failedmpd.socket
diederik@soundserver:~$ systemctl status mpd.service
× mpd.service - Music Player Daemon
 Loaded: loaded (/lib/systemd/system/mpd.service; enabled; vendor preset: 
enabled)
 Active: failed (Result: exit-code) since Wed 2021-11-10 23:30:21 CET; 1min 
11s ago
TriggeredBy: × mpd.socket
   Docs: man:mpd(1)
 man:mpd.conf(5)
 file:///usr/share/doc/mpd/html/user.html
Process: 1466 ExecStart=/usr/bin/mpd --no-daemon $MPDCONF (code=exited, 
status=1/FAILURE)
   Main PID: 1466 (code=exited, status=1/FAILURE)
CPU: 1.876s

nov 10 23:30:19 soundserver systemd[1]: Starting Music Player Daemon...
nov 10 23:30:21 soundserver mpd[1466]: Nov 10 23:30 : exception: Tag list 
mismatch, discarding database file
nov 10 23:30:21 soundserver mpd[1466]: Nov 10 23:30 : exception: Failed to 
create pid file "/run/mpd/pid": Permission denied
nov 10 23:30:21 soundserver systemd[1]: mpd.service: Main process exited, 
code=exited, status=1/FAILURE
nov 10 23:30:21 soundserver systemd[1]: mpd.service: Failed with result 
'exit-code'.
nov 10 23:30:21 soundserver systemd[1]: Failed to start Music Player Daemon.
nov 10 23:30:21 soundserver systemd[1]: mpd.service: Consumed 1.876s CPU time.
nov 10 23:30:21 soundserver systemd[1]: mpd.service: Start request repeated too 
quickly.
nov 10 23:30:21 soundserver systemd[1]: mpd.service: Failed with result 
'exit-code'.
nov 10 23:30:21 soundserver systemd[1]: Failed to start Music Player Daemon.

I found https://github.com/MusicPlayerDaemon/MPD/issues/1299 which seem to
indicate that the first exception is expected.
I did a "mpc rescan" both as user (me) and as root, but got
"MPD error: Connection refused", which indicates a premission issue. So I
checked the /run/ directory and saw that there wasn't a 'mpd' subdir.

Then I checked Debian's BTS and found this bug.
After disabling the pidfile-line, mpd did start up successfully (it still
printed the "exception: Tag list mismatch, discarding database file", but it
now did start successfully.

root@soundserver:~# ls -ld /run/mpd
drwxr-xr-x 2 root root 60 Nov 10 23:53 /run/mpd
root@soundserver:~# ls -l /run/mpd/
total 0
srw-rw-rw- 1 root root 0 Nov 10 23:53 socket


I'm _assuming_ that it's the same issue, but as my symptoms are somewhat
different, I thought I'd mention mine.
If this is actually a different issue which should be filed separately, let me
know and I'll do that. If you want me to run (some) tests, I can do that too.

Cheers,
  Diederik

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

Bug#994095: ITS: python-pmw

[Greg McFarlane]

Hi Moritz and Boyuan,

Thanks for getting in touch.

The latest release of Pmw is here:

  https://sourceforge.net/projects/pmw/

I am no longer actively maintaining Pmw, although in December 2020 I did
merge a number of changes (mainly for Python 3) into the latest release.

I would be very grateful if you could do all you can to move the latest Pmw
release into Debian.

There is a copyright file here: /Pmw/Pmw_2_1/doc/copyright.html

Do you need any more for the copyright?

Note that my normal email has changed from gr...@iname.com to
veganasg...@gmail.com.

Thanks for your help.

Veganly,

Greg McFarlane


On Thu, Nov 11, 2021 at 9:15 AM Boyuan Yang  wrote:

> Hi,
>
> 在 2021-11-10星期三的 22:43 +0100，Moritz Mühlenhoff写道：
> > Am Sat, Sep 11, 2021 at 01:04:16PM -0400 schrieb Boyuan Yang:
> > > Source: python-pmw
> > > Version:  1.3.2-6
> > > Severity: important
> > > X-Debbugs-CC: se...@debian.org
> > >
> > > Dear package python-pmw maintainer in Debian,
> > >
> > > After looking into the package you maintain (python-pmw,
> > > https://tracker.debian.org/pkg/python-pmw), I found that this package
> > > received no maintainer updates in the past 10 years and was not in good
> > > shape. As a result, I am filing an ITS (Intent to Salvage) request
> > > against your package according to section 5.12 in Debian's Developers'
> > > Reference [1].
> > >
> > > My current plan is to package the latest upstream release (2.1),
> > > clean up packaging and orphan this package to allow possible external
> > > contribution.
> > >
> > > Please let me know whether you are still willing to maintain this
> > > package. According to the criteria listed at [2], I will upload a Non-
> > > maintainer Upload (NMU) of this package onto DELAYED/7 after 21 days
> > > (Oct 02, 2021) to continue with the package salvaging. If you find it
> > > necessary to pause the ITS process, please let me know immediately by
> > > replying this bug report.
> >
> > What's the status? Given the package hasn't seen a maintainer upload
> > for over a decade it seems safe to proceed :-)
> >
> > You don't need to care about the current reverse dep when dropping
> > support for Python 2; bkchem is already uninstallable due to missing
> > python-pil.
>
> See https://salsa.debian.org/python-team/packages/python-pmw ; a previous
> upload was rejected by FTP Masters due to incomplete copyright. More work
> is
> needed, and any help would be great.
>
> Thanks,
> Boyuan Yang
>
>

Bug#998224: hplip: HPLIP incorrectly links to obsolete or missing libhpdiscovery.so

[Troy Rollo]

Unfortunately the system which exhibited the problem has now been 
updated with a working version after I kludged it to work.


However, what happens is the shared libraries are all linked twice. The 
first time it is linked to libraries in the build tree (and do not have 
links to the old . They are then relinked, I assume as part of 
installing the files for packaging. At that stage, libhpdiscovery.so* 
will not be found in debian/tmp/usr/lib/x86_64-linux-gnu, and it picks 
it up from the local system, if installed, or fails, if not.


If the build picks it up to the local system, and the one in the local 
system is linked to libnetsnmp.so.30, then this dependency propagates 
through the other libraries, resulting in libraries that cannot be 
loaded at all.


I eventually got the build to work by removing all old copies of 
libhpdiscovery.so* from the system library directories, manually copying 
libhpdiscovery.so* from the build tree to the system library 
directories, then freshly extracting the source and rebuilding.


I built using debuild on a live system.

I suspect reproducing will not be straight-forward as it requires a 
system that still has the version of hplip from buster, but has 
otherwise been upgraded to bullseye. I cannot spare the time right now 
to set up a test environment and make the attempt to reproduce this, so 
perhaps this should be closed and left as a record for anybody who 
encounters the problem later.


On 7/11/21 11:30 am, Thorsten Alteholz wrote:

Control: tag -1 moreinfo

Hi Troy,

thanks for your bugreport. Unfortunately I have problems understanding 
what is going on.


How can HPLIP link to a missing libhpdiscovery.so.
I assume you are building the package in a minimal chroot. How can 
there be an old version of libhpdiscovery.so available?


Can you please be a bit more verbose about what you are doing and what 
fails?


Best regards,
Thorsten






smime.p7s
Description: S/MIME Cryptographic Signature

Bug#999434: bullseye-pu: package freeipmi/1.6.6-4+deb11u1

[Mattia Rizzolo]

On Wed, Nov 10, 2021 at 11:55:03PM +0100, Fabio Fantoni wrote:
>   [x] attach debdiff against the package in (old)stable

Since this is a small likely uncontroversial change, I proceeded to
upload it already.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#999352: ncurses-bin: ambiguous and possibly buggy behavior of clear with the alternate screen

[Thomas Dickey]

On Wed, Nov 10, 2021 at 12:31:17PM +0100, Vincent Lefevre wrote:
> On 2021-11-10 12:12:59 +0100, Vincent Lefevre wrote:
> > Tested with xterm and GNOME Terminal.
> 
> And same buggy behavior with Sakura.
> 
> > Note: with mlterm and rxvt, the scrollback buffer is still there, but
> > this is just because the "clear" command doesn't clear it with these
> > terminals (whether the main screen is the alternate screen or not).
>  ^^^ I meant "current screen" here.
> 

ncurses is doing the right thing: using documented, common features of
the given terminals to do common operations.  None of the terminals you
are likely to encounter (i.e., none that you have not modified) will do
the feature that you're describing.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#999434: bullseye-pu: package freeipmi/1.6.6-4+deb11u1

[Fabio Fantoni]

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

[ Reason ]
There are wrong pkg-config file path in *-dev packages

[ Impact ]
As reported in #996325 for one of -dev package, that make build against
them fails or silently build without the freeipmi part

[ Tests ]
pkg-config files path are now correct:
http://debomatic-amd64.debian.net/distribution#bullseye/freeipmi/1.6.6-4+deb11u1/

[ Risks ]
No regression risk with this small fix FWIK

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
pkg-config files path in debian/*-dev.install

[ Other info ]
n/a

diff -Nru freeipmi-1.6.6/debian/changelog freeipmi-1.6.6/debian/changelog
--- freeipmi-1.6.6/debian/changelog 2021-07-28 16:41:51.0 +0200
+++ freeipmi-1.6.6/debian/changelog 2021-10-31 18:05:13.0 +0100
@@ -1,3 +1,9 @@
+freeipmi (1.6.6-4+deb11u1) bullseye; urgency=medium
+
+  * Fix .pc files path in -dev packages. Thanks to наб (Closes: #996325)
+
+ -- Fabio Fantoni   Sun, 31 Oct 2021 18:05:13 +0100
+
 freeipmi (1.6.6-4) unstable; urgency=medium
 
   [ Andreas Beckmann ]
diff -Nru freeipmi-1.6.6/debian/control freeipmi-1.6.6/debian/control
--- freeipmi-1.6.6/debian/control   2021-07-28 16:41:51.0 +0200
+++ freeipmi-1.6.6/debian/control   2021-10-31 18:05:13.0 +0100
@@ -15,7 +15,7 @@
 Rules-Requires-Root: binary-targets
 Homepage: https://www.gnu.org/software/freeipmi/
 Vcs-Browser: https://salsa.debian.org/debian/freeipmi
-Vcs-Git: https://salsa.debian.org/debian/freeipmi.git
+Vcs-Git: https://salsa.debian.org/debian/freeipmi.git -b bullseye
 
 Package: freeipmi
 Architecture: all
diff -Nru freeipmi-1.6.6/debian/gbp.conf freeipmi-1.6.6/debian/gbp.conf
--- freeipmi-1.6.6/debian/gbp.conf  2021-07-28 16:41:51.0 +0200
+++ freeipmi-1.6.6/debian/gbp.conf  2021-10-31 18:05:13.0 +0100
@@ -3,6 +3,7 @@
 upstream-tag = upstream/%(version)s
 debian-tag = debian/%(version)s
 pristine-tar = True
+debian-branch = bullseye
 
 # Options only affecting gbp buildpackage
 [buildpackage]
diff -Nru freeipmi-1.6.6/debian/.gitlab-ci.yml 
freeipmi-1.6.6/debian/.gitlab-ci.yml
--- freeipmi-1.6.6/debian/.gitlab-ci.yml2021-07-28 16:41:51.0 
+0200
+++ freeipmi-1.6.6/debian/.gitlab-ci.yml2021-10-31 18:05:13.0 
+0100
@@ -3,4 +3,4 @@
  - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
 
 variables:
- RELEASE: 'unstable'
+ RELEASE: 'bullseye'
diff -Nru freeipmi-1.6.6/debian/libfreeipmi-dev.install 
freeipmi-1.6.6/debian/libfreeipmi-dev.install
--- freeipmi-1.6.6/debian/libfreeipmi-dev.install   2021-07-28 
16:41:51.0 +0200
+++ freeipmi-1.6.6/debian/libfreeipmi-dev.install   2021-10-31 
18:05:13.0 +0100
@@ -1,5 +1,5 @@
 usr/include/freeipmi
 usr/lib/libfreeipmi.a
 usr/lib/libfreeipmi.so
-usr/lib/pkgconfig/libfreeipmi.pc 
usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig/libfreeipmi.pc
+usr/lib/pkgconfig/libfreeipmi.pc usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig
 usr/share/man/man3/libfreeipmi.3
diff -Nru freeipmi-1.6.6/debian/libipmiconsole-dev.install 
freeipmi-1.6.6/debian/libipmiconsole-dev.install
--- freeipmi-1.6.6/debian/libipmiconsole-dev.install2021-07-28 
16:41:51.0 +0200
+++ freeipmi-1.6.6/debian/libipmiconsole-dev.install2021-10-31 
18:05:13.0 +0100
@@ -1,5 +1,5 @@
 usr/include/ipmiconsole.h
 usr/lib/libipmiconsole.a
 usr/lib/libipmiconsole.so
-usr/lib/pkgconfig/libipmiconsole.pc 
usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig/libipmiconsole.pc
+usr/lib/pkgconfig/libipmiconsole.pc usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig
 usr/share/man/man3/libipmiconsole.3
diff -Nru freeipmi-1.6.6/debian/libipmidetect-dev.install 
freeipmi-1.6.6/debian/libipmidetect-dev.install
--- freeipmi-1.6.6/debian/libipmidetect-dev.install 2021-07-28 
16:41:51.0 +0200
+++ freeipmi-1.6.6/debian/libipmidetect-dev.install 2021-10-31 
18:05:13.0 +0100
@@ -1,5 +1,5 @@
 usr/include/ipmidetect.h
 usr/lib/libipmidetect.a
 usr/lib/libipmidetect.so
-usr/lib/pkgconfig/libipmidetect.pc 
usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig/libipmidetect.pc
+usr/lib/pkgconfig/libipmidetect.pc usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig
 usr/share/man/man3/libipmidetect.3
diff -Nru freeipmi-1.6.6/debian/libipmimonitoring-dev.install 
freeipmi-1.6.6/debian/libipmimonitoring-dev.install
--- freeipmi-1.6.6/debian/libipmimonitoring-dev.install 2021-07-28 
16:41:51.0 +0200
+++ freeipmi-1.6.6/debian/libipmimonitoring-dev.install 2021-10-31 
18:05:13.0 +0100
@@ -1,5 +1,5 @@
 usr/include/ipmi_monitoring*.h
 usr/lib/libipmimonitoring.a
 usr/lib/libipmimonitoring.so
-usr/lib/pkgconfig/libipmimonitoring.pc 
usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig/libipmimonitoring.pc
+usr/lib/pkgconfig/libipmimonitoring.pc

Bug#998333: RFS: lebiniou/3.63.1-1 -- user-friendly, powerful music visualization / VJing tool

[Olivier Girondel]

On 11/8/21 8:20 PM, Bastian Germann wrote:

Fix d/copyright info for both swarm.c and flow.c by:

- Adding your Copyright line
- Changing the License: GPL-2+ and MIT-variant
- Copying the MIT-variant to the bottom of the file, prepended with 
License: MIT-variant




Hi Bastian,

I uploaded an updated version to m.d.n, hoping it will be OK.

Best regards,

--
Olivier

Bug#600779: pycam: changing from RFP to ITP

[Petter Reinholdtsen]

[Sebastian Kuzminsky]
> retitle 600779 ITP: pycam -- CAM program & Python library for generating 
> toolpaths

Hi.  Any news on your plans to upload pycam to Debian?

My sponsoring preferences can be found at
http://www.hungry.com/~pere/debian-sponsoring.html >.
-- 
Happy hacking
Petter Reinholdtsen

Bug#994095: ITS: python-pmw

[Boyuan Yang]

Hi,

在 2021-11-10星期三的 22:43 +0100，Moritz Mühlenhoff写道：
> Am Sat, Sep 11, 2021 at 01:04:16PM -0400 schrieb Boyuan Yang:
> > Source: python-pmw
> > Version:  1.3.2-6
> > Severity: important
> > X-Debbugs-CC: se...@debian.org
> > 
> > Dear package python-pmw maintainer in Debian,
> > 
> > After looking into the package you maintain (python-pmw, 
> > https://tracker.debian.org/pkg/python-pmw), I found that this package
> > received no maintainer updates in the past 10 years and was not in good
> > shape. As a result, I am filing an ITS (Intent to Salvage) request
> > against your package according to section 5.12 in Debian's Developers'
> > Reference [1].
> > 
> > My current plan is to package the latest upstream release (2.1),
> > clean up packaging and orphan this package to allow possible external
> > contribution.
> > 
> > Please let me know whether you are still willing to maintain this
> > package. According to the criteria listed at [2], I will upload a Non-
> > maintainer Upload (NMU) of this package onto DELAYED/7 after 21 days
> > (Oct 02, 2021) to continue with the package salvaging. If you find it
> > necessary to pause the ITS process, please let me know immediately by
> > replying this bug report.
> 
> What's the status? Given the package hasn't seen a maintainer upload
> for over a decade it seems safe to proceed :-)
> 
> You don't need to care about the current reverse dep when dropping
> support for Python 2; bkchem is already uninstallable due to missing
> python-pil.

See https://salsa.debian.org/python-team/packages/python-pmw ; a previous
upload was rejected by FTP Masters due to incomplete copyright. More work is
needed, and any help would be great.

Thanks,
Boyuan Yang

Bug#999433: nodejs: please enable riscv64

[Adam Borowski]

Source: nodejs
Version: 16.13.0~dfsg-2
Severity: wishlist
X-Debbugs-Cc: kilob...@angband.pl

Hi!
I see you're working on packaging nodejs 16.  That major version includes
support for riscv64, and it'd be nice to have it enabled -- nodejs is in
the Build-Depend chain for many packages.

As the package in its present state fails to build anywhere, I haven't tried
it myself -- but, the point of experimental is to test things and see if
they work.


Meow!
-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: riscv64

Kernel: Linux 5.15.1-00015-g8df2193a61ae (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#994055: cunit NMU

[Michael Hudson-Doyle]

On Thu, 11 Nov 2021 at 10:49, Paul Gevers  wrote:

> Hi Michael,
>
> On Wed, 10 Nov 2021 16:16:53 +1300 Michael Hudson-Doyle
>  wrote:
> > Hi, thanks for this fix. I think it meets the threshold for NMU (and also
> > the maintainer seems to have been awol since 2015) so I'm uploading it to
> > DELAYED/10.
>
> I was working on this yesterday and uploaded to DELAYED too, because I
> forgot to check the bug history. As I uploaded to DELAYED/2, I decided
> to dcut my upload, but apparently I was able to dcut your upload...
>

Ha.


> Log of processing your commands file /paul-1636580073.commands:
>
> > cancel cunit_2.1-3-dfsg-2.4_source.changes
> Files removed from 10-day: cunit_2.1-3-dfsg-2.4_source.changes
> cunit_2.1-3-dfsg-2.4.dsc cunit_2.1-3-dfsg-2.4.debian.tar.xz
> cunit_2.1-3-dfsg-2.4_source.buildinfo
>
> Could you reupload your changes, or do you want me to upload mine?
>

If you have yours close at hand, feel free to upload them? Otherwise I
think I still have the changes file around...


> Sorry for the mess.
>

So long as we get a fixed package I'm not bothered!

Bug#999432: ITP: tkrzw-python -- Python binding for Tkrzw library

[Boyuan Yang]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: tkrzw-python
  Version : 0.1.27
  Upstream Author : Mikio Hirabayashi
* URL : https://github.com/estraier/tkrzw-python
* License : Apache-2.0
  Programming Lang: Python
  Description : Python binding for Tkrzw library

 Tkrzw is a C++ library implementing DBM (Database Manager) with
 various algorithms. It features high degrees of performance,
 concurrency, scalability and durability.
 .
 This package contains the Python 3 binding of the library.


I plan to maintain this package under Debian Python Team:

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


Thanks,
Boyuan Yang


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

Bug#999424: ITP: geners -- generic serialization library for C++

[Thaddeus H. Black]

On Wed, Nov 10, 2021 at 09:34:36PM +0100, Pierre Gruet wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Pierre Gruet 
> X-Debbugs-Cc: debian-de...@lists.debian.org
> 
> * Package name: geners
>   Version : 1.12.0
>   Upstream Author : Igor Volobouev
> * URL : https://geners.hepforge.org/
> * License : Expat
>   Programming Lang: C++
>   Description : generic serialization library for C++
> 
> The Generic Serialization library is designed to address the problem of C++
> object persistence in situations where the most typical data access pattern is
> "write once read many" (WORM). "Geners" is a set of tools and conventions
> which allows its users to develop C++ classes that can be converted to and
> from a storable stream of bytes in a well-organized and type-safe manner.
> Serialization of STL containers is supported, including the ones added in the
> C++11 standard. Independent versioning of each class definition is allowed.
> 
> Among others, compared to the boost serialization package, Geners archives
> provide random access to stored objects and can be used to create and
> serialize very large archive-based objects. Yet, only binary archives are
> implemented, and implementing non-intrusive serialization is less transparent.
> 
> I am packaging this software as a dependency of stopt, which is a packaging
> target of mine. I plan to maintain it myself.

That is interesting.  For information, what is stopt, please?
Is it [1], [2], or something else?

1: https://github.com/husk214/stopt/
2: https://github.com/anitan0925/STOPT/



signature.asc
Description: PGP signature

Bug#999431: zydis: CVE-2021-41253

[Salvatore Bonaccorso]

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

Hi,

The following vulnerability was published for zydis.

CVE-2021-41253[0]:
| Zydis is an x86/x86-64 disassembler library. Users of Zydis versions
| v3.2.0 and older that use the string functions provided in `zycore` in
| order to append untrusted user data to the formatter buffer within
| their custom formatter hooks can run into heap buffer overflows. Older
| versions of Zydis failed to properly initialize the string object
| within the formatter buffer, forgetting to initialize a few fields,
| leaving their value to chance. This could then in turn cause zycore
| functions like `ZyanStringAppend` to make incorrect calculations for
| the new target size, resulting in heap memory corruption. This does
| not affect the regular uncustomized Zydis formatter, because Zydis
| internally doesn't use the string functions in zycore that act upon
| these fields. However, because the zycore string functions are the
| intended way to work with the formatter buffer for users of the
| library that wish to extend the formatter, we still consider this to
| be a vulnerability in Zydis. This bug is patched starting in version
| 3.2.1. As a workaround, users may refrain from using zycore string
| functions in their formatter hooks until updating to a patched
| version.


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-41253
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-41253
[1] https://github.com/zyantific/zydis/security/advisories/GHSA-q42v-hv86-3m4g

Regards,
Salvatore

Bug#998358: Subject: grepmail: autopkgtest doesn't do anything

[Paul Gevers]

Hi Eriberto,

On Tue, 2 Nov 2021 19:57:37 -0300 Eriberto  wrote:
> ow, Marcos will package the new upstream
> release and he will fix this mistake. In a final action, he will send
> a SPU to fix a specific issue.

Please be aware that grepmail will be removed from testing in 7 days if
the issue isn't fixed. Obviously, the package can come back later too,
but just so you know.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#994055: cunit NMU

[Paul Gevers]

Hi Michael,

On Wed, 10 Nov 2021 16:16:53 +1300 Michael Hudson-Doyle
 wrote:
> Hi, thanks for this fix. I think it meets the threshold for NMU (and also
> the maintainer seems to have been awol since 2015) so I'm uploading it to
> DELAYED/10.

I was working on this yesterday and uploaded to DELAYED too, because I
forgot to check the bug history. As I uploaded to DELAYED/2, I decided
to dcut my upload, but apparently I was able to dcut your upload...

Log of processing your commands file /paul-1636580073.commands:

> cancel cunit_2.1-3-dfsg-2.4_source.changes
Files removed from 10-day: cunit_2.1-3-dfsg-2.4_source.changes
cunit_2.1-3-dfsg-2.4.dsc cunit_2.1-3-dfsg-2.4.debian.tar.xz
cunit_2.1-3-dfsg-2.4_source.buildinfo

Could you reupload your changes, or do you want me to upload mine?

Sorry for the mess.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#998164: PS: scummvm: please provide a transitional package to take over residualvm

[Alexandre Detiste]

Here's a sample merge request as proposed:
   https://salsa.debian.org/games-team/scummvm/-/merge_requests/5

Upstream seems neither interested nor against this littel transition helper;
maybe we can get back in touch later when it's done.

For the records a bit of discussion happened on this other MR:
  https://salsa.debian.org/games-team/scummvm/-/merge_requests/4

Greetings,

Alexandre

Bug#994095: ITS: python-pmw

[Moritz Mühlenhoff]

Am Sat, Sep 11, 2021 at 01:04:16PM -0400 schrieb Boyuan Yang:
> Source: python-pmw
> Version:  1.3.2-6
> Severity: important
> X-Debbugs-CC: se...@debian.org
> 
> Dear package python-pmw maintainer in Debian,
> 
> After looking into the package you maintain (python-pmw, 
> https://tracker.debian.org/pkg/python-pmw), I found that this package
> received no maintainer updates in the past 10 years and was not in good
> shape. As a result, I am filing an ITS (Intent to Salvage) request
> against your package according to section 5.12 in Debian's Developers'
> Reference [1].
> 
> My current plan is to package the latest upstream release (2.1),
> clean up packaging and orphan this package to allow possible external
> contribution.
> 
> Please let me know whether you are still willing to maintain this
> package. According to the criteria listed at [2], I will upload a Non-
> maintainer Upload (NMU) of this package onto DELAYED/7 after 21 days
> (Oct 02, 2021) to continue with the package salvaging. If you find it
> necessary to pause the ITS process, please let me know immediately by
> replying this bug report.

What's the status? Given the package hasn't seen a maintainer upload
for over a decade it seems safe to proceed :-)

You don't need to care about the current reverse dep when dropping
support for Python 2; bkchem is already uninstallable due to missing
python-pil.

Cheers,
 Moritz

Bug#995655: dnsmasq breaks systemd autopkgtest: b'megasearch.net: 192.168.42.1' not found in b'megasearch.net: 207.148.248.143

[Michael Biebl]

Control: tags -1 + patch

Hi Simon

On 10.11.21 20:44, Michael Biebl wrote:

Simon,

any news here?
Would you mind if I prepare an NMU with
26bbf5a314d833beaf0f147d24409969f05f3dba ?



I decided to follow the rules in [1] and uploaded a fixed package to 
DELAYED/2. Please holler if you want me to cancel the NMU.


debdiff is attached.

Regards,
Michael


[1] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#nmu
diff -u dnsmasq-2.86/debian/changelog dnsmasq-2.86/debian/changelog
--- dnsmasq-2.86/debian/changelog
+++ dnsmasq-2.86/debian/changelog
@@ -1,3 +1,10 @@
+dnsmasq (2.86-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix --address=/#/.. which was lost in 2.86. (closes: #995655)
+
+ -- Michael Biebl   Wed, 10 Nov 2021 22:05:45 +0100
+
 dnsmasq (2.86-1) unstable; urgency=low
 
* Fix debian/changelog format error. (closes: #986626)
only in patch2:
unchanged:
--- dnsmasq-2.86.orig/CHANGELOG
+++ dnsmasq-2.86/CHANGELOG
@@ -1,3 +1,11 @@
+version 2.87
+Allow arbitrary prefix lengths in --rev-server and
+   --domain=,local
+
+   Replace --address=/#/. functionality which got
+   missed in the 2.86 domain search rewrite.
+
+   
 version 2.86
Handle DHCPREBIND requests in the DHCPv6 server code.
Thanks to Aichun Li for spotting this omission, and the initial
only in patch2:
unchanged:
--- dnsmasq-2.86.orig/src/network.c
+++ dnsmasq-2.86/src/network.c
@@ -1623,7 +1623,8 @@
 continue;

if ((serv->flags & SERV_LITERAL_ADDRESS) &&
-  !(serv->flags & (SERV_6ADDR | SERV_4ADDR | SERV_ALL_ZEROS)))
+  !(serv->flags & (SERV_6ADDR | SERV_4ADDR | SERV_ALL_ZEROS)) &&
+  strlen(serv->domain))
 {
   count--;
   if (++locals <= LOCALS_LOGGED)
only in patch2:
unchanged:
--- dnsmasq-2.86.orig/src/option.c
+++ dnsmasq-2.86/src/option.c
@@ -2684,7 +2684,7 @@

if (!arg || !*arg)
  flags = SERV_LITERAL_ADDRESS;
-   else if (option == 'A')
+   else if (option != 'S')
  {
/* # as literal address means return zero address for 4 and 6 */
if (strcmp(arg, "#") == 0)
@@ -2708,11 +2708,18 @@
while (1)
  {
/* server=//1.2.3.4 is special. */
-   if (strlen(domain) == 0 && lastdomain)
- flags |= SERV_FOR_NODOTS;
-   else
- flags &= ~SERV_FOR_NODOTS;
+   if (lastdomain)
+ {
+   if (strlen(domain) == 0)
+ flags |= SERV_FOR_NODOTS;
+   else
+ flags &= ~SERV_FOR_NODOTS;
 
+   /* address=/#/ matches the same as without domain */
+   if (option != 'S' && domain[0] == '#' && domain[1] == 0)
+ domain[0] = 0;
+ }
+   
if (!add_update_server(flags, &serv_addr, &source_addr, interface, 
domain, &addr))
  ret_err(gen_err);



OpenPGP_signature
Description: OpenPGP digital signature

Bug#999430: buster-pu: package publicsuffix/20211109.1735-0+deb10u1

[Daniel Kahn Gillmor]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: d...@fifthhorseman.net
Control: affects -1 src:publicsuffix

Please consider an update to publicsuffix in debian buster.

This package reflects the state of the network, and keeping it current
is useful for all the packages that depend on it.

The debdiff from the previous version in buster is attached.

This proposed release is also available at the
"publicsuffix_debian/20211109.1735-0+deb10u1" tag on the "debian/buster" branch 
at
the git repo for publicsuffix packaging:

https://salsa.debian.org/debian/publicsuffix

Please followup on this ticket to confirm whether I should upload this
revision to buster.


publicsuffix_20190925.1705-0+deb10u1_20211109.1735-0+deb10u1.debdiff.gz
Description: application/gzip

Bug#999429: src:guix: fails to migrate to testing for too long: FTBFS on i386

[Paul Gevers]

Source: guix
Version: 1.2.0-4
Severity: serious
Control: close -1 1.3.0-2
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing
and unstable for more than 60 days as having a Release Critical bug in
testing [1]. Your package src:guix has been trying to migrate for 62
days [2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bookworm, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=guix




OpenPGP_signature
Description: OpenPGP digital signature

Bug#999428: cunit autopkgtest unnecessary uses needs-build and doesn't test as-installed binaries

[Paul Gevers]

Source: cunit
Version: 2.1-3-dfsg-2.3
Severity: normal
Tags: patch

Dear maintainer,

While working on bug #994055 I noticed that your autopkgtest has the
needs-build restriction. I think that's unneeded and instead of
testing the binaries in the archive, the just built binaries are
tested. The change is simple; drop the restriction and instead make
the test dependent on libcunit1-dev.

index abc6a4f..71439f1 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,3 +1,2 @@
 Tests: test.sh
-Depends: gcc, libc6-dev
-Restrictions: build-needed
+Depends: libcunit1-dev, gcc, libc6-dev

Paul

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

Kernel: Linux 5.14.0-2-amd64 (SMP w/8 CPU threads)
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

Bug#972146: /usr/share/applications/mono-runtime-common.desktop: should not handle MIME type by executing arbitrary code

[Gabriel Corona]

Hi,

Any help needed for this?

Regards,

Gabriel

Bug#999427: bullseye-pu: package publicsuffix/20211109.1735-0+deb11u1

[Daniel Kahn Gillmor]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: d...@fifthhorseman.net
Control: affects -1 src:publicsuffix

Please consider an update to publicsuffix in debian bullseye.

This package reflects the state of the network, and keeping it current
is useful for all the packages that depend on it.

The debdiff from the previous version in bullseye is attached.

This proposed release is also available at the
"publicsuffix_debian/20211109.1735-0+deb11u1" tag on the "debian/bullseye" 
branch at
the git repo for publicsuffix packaging:

https://salsa.debian.org/debian/publicsuffix

Please followup on this ticket to confirm whether I should upload this
revision to bullseye.


publicsuffix_20210108.1309-1_20211109.1735-0+deb11u1.debdiff.gz
Description: application/gzip

Bug#998449: golang-github-containernetworking-plugins breaks libpod autopkgtest

[Paul Gevers]

reassign 998449 src:golang-github-containernetworking-plugin,src:libpod
found 998449 golang-github-containernetworking-plugins/0.9.1-1
found 998449 libpod/3.4.1+ds1-2
thanks

Hi,

I'm seeing this bug as caused by the
golang-github-containernetworking-plugin upload in the excuses of that
package. Hence [1] reassigning to both.

Paul

[1] https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation



OpenPGP_signature
Description: OpenPGP digital signature

Bug#994239: micropython: diff for NMU version 1.17+ds-1.1

[Boyuan Yang]

Control: tags 994239 + patch
Control: tags 994239 + pending

Dear maintainer,

I've prepared an NMU for micropython (versioned as 1.17+ds-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru micropython-1.17+ds/debian/changelog micropython-
1.17+ds/debian/changelog
--- micropython-1.17+ds/debian/changelog2021-09-04 02:41:03.0
-0400
+++ micropython-1.17+ds/debian/changelog2021-11-10 15:51:19.0
-0500
@@ -1,3 +1,11 @@
+micropython (1.17+ds-1.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * debian/rules: Circumvent FTBFS with gcc 11 using
+-Wno-error=maybe-uninitialized cflag. (Closes: #994239)
+
+ -- Boyuan Yang   Wed, 10 Nov 2021 15:51:19 -0500
+
 micropython (1.17+ds-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru micropython-1.17+ds/debian/rules micropython-1.17+ds/debian/rules
--- micropython-1.17+ds/debian/rules2021-09-04 02:41:03.0 -0400
+++ micropython-1.17+ds/debian/rules2021-11-10 15:51:19.0 -0500
@@ -3,7 +3,7 @@
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-format
 
-export DEB_CFLAGS_MAINT_APPEND  = -Wformat -Werror=format-security
+export DEB_CFLAGS_MAINT_APPEND  = -Wformat -Werror=format-security -Wno-
error=maybe-uninitialized
 export DEB_LDFLAGS_MAINT_APPEND =
 
 export BUILD_VERBOSE = 1


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

Bug#999426: lxdm: tcp_listen config options is broken

[Gennady Kupava]

Package: lxdm
Version: 0.5.3-4
Severity: normal
X-Debbugs-Cc: gennady.kup...@gmail.com

enabling tcp_listen=1 removes 'nolisten tcp' optin from X server, but modern 
Xorg seems require explicit '-listen' option to actually listen on tcp port, so 
it is very hard to pass it.

Hopefully trivial to fix.


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

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

Versions of packages lxdm depends on:
ii  debconf [debconf-2.0]  1.5.79
ii  gtk2-engines   1:2.20.2-5+b1
ii  gtk2-engines-pixbuf2.24.33-2
ii  iso-codes  4.8.0-1
ii  libc6  2.32-4
ii  libcairo2  1.16.0-5
ii  libgdk-pixbuf-2.0-02.42.6+dfsg-2
ii  libglib2.0-0   2.70.0-3
ii  libgtk2.0-02.24.33-2
ii  libpam-modules 1.4.0-10
ii  libpam-runtime 1.4.0-10
ii  libpam0g   1.4.0-10
ii  libpango-1.0-0 1.48.10+ds1-1
ii  libpangocairo-1.0-01.48.10+ds1-1
ii  librsvg2-common2.50.7+dfsg-2
ii  libx11-6   2:1.7.2-2+b1
ii  libxcb11.14-3
ii  lsb-base   11.1.0
ii  x11-utils  7.7+5

Versions of packages lxdm recommends:
ii  desktop-base  11.0.3

Versions of packages lxdm suggests:
ii  lxde-common  0.99.2-4

-- Configuration Files:
/etc/lxdm/lxdm.conf changed:
[base]
greeter=/usr/lib/lxdm/lxdm-greeter-gtk
[server]
tcp_listen=1
[display]
gtk_theme=Clearlooks
bg=/usr/share/images/desktop-base/login-background.svg
bottom_pane=1
lang=1
keyboard=0
theme=Industrial
[input]
[userlist]
disable=0
white=
black=


-- debconf information:
* shared/default-x-display-manager: lxdm

Bug#999335: [3dprinter-general] Bug#999335: cura: Zeroconf no longer works due to API change

[Miro Hrončok]

On 10. 11. 21 0:17, Gregor Riepl wrote:

Package: cura
Version: 4.8-4
Severity: normal
X-Debbugs-Cc: onit...@gmail.com

When loading the zeroconf module, the following stack trace is produced:

...
[99]: AttributeError: 'ServiceInfo' object has no attribute 'address'

This was caused by: https://github.com/jstasiak/python-zeroconf/pull/260

It shouldn't be too hard fix. Here's and example how it could be done:
https://github.com/rytilahti/python-miio/pull/898/files
And it's possibly already fixed upstream?


It is:

https://github.com/Ultimaker/Cura/commit/cfccf94914af5c6f5e237504e2f145b8b3157d88

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok

Bug#998108: Acknowledgement (firefox freezes shortly after start)

[Gennady Kupava]

On Wed, 10 Nov 2021 00:59:02 +0100 Christoph Anton Mitterer
 wrote:
> Not sure if this is related, but since a while I've noted even bigger
> than the usual performance problems of firefox...
> 
> Crackling sound is something I've heard for a month now... but since
> about FF93 came out CPU utilisation seems to be much higher.
> I just load simple webpages and may CPU goes up to 70-80°C.
> 
> Anyone else seen this, too?
> 

This is offtopic for the bug, but:

Other way round for me. some version around 92 i see huge speed up, at
least for youtube. seems before that it was sotwareish (typically 1080p
took around 300% cpu) now it is around 130% for all processes. Firefox
for the first time in 6 years on same hw could play 4k on intel.

I spent some time investigating my 300% before, and learned a lot -
that they enabling va-api and etc. slowness/fastness seems depend on
the content you trying, configuration of your hardware, etc etc
discussion would be way out of scope of this bug.

Bug#999425: linux-image-5.14.0-2-amd64: cannot suspend

[Emilian Nowak]

Package: src:linux
Version: 5.14.9-2
Severity: normal
X-Debbugs-Cc: emil.no...@gmail.com

Dear Maintainer,

When I try to suspend my machine: for example using systemctl suspend.
It only turns off monitor, and machine seem to be working in background. I here
water pump running, and LEDs on motherborad are still on.

It used to work on same machine in linux-5.10.*

In dmesg I have the following messages:
[ 6339.955443] usb 3-6: new SuperSpeed USB device number 3 using xhci_hcd
[ 6339.976020] usb 3-6: New USB device found, idVendor=1532, idProduct=0e05,
bcdDevice= 8.21
[ 6339.976025] usb 3-6: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[ 6339.976027] usb 3-6: Product: Razer Kiyo Pro
[ 6339.976028] usb 3-6: Manufacturer: Razer Inc
[ 6339.977494] usb 3-6: current rate 16000 is different from the runtime rate
48000
[ 6340.390701] usb 3-6: current rate 16000 is different from the runtime rate
24000
[ 6340.392057] usb 3-6: current rate 16000 is different from the runtime rate
32000
[ 6340.524579] videodev: Linux video capture interface: v2.00
[ 6340.542973] usb 3-6: Found UVC 1.00 device Razer Kiyo Pro (1532:0e05)
[ 6340.544530] uvcvideo 3-6:1.1: Failed to set UVC probe control : -32 (exp.
26).
[ 6340.544726] input: Razer Kiyo Pro as
/devices/pci:00/:00:14.0/usb3/3-6/3-6:1.0/input/input24
[ 6340.544776] usbcore: registered new interface driver uvcvideo
[ 6340.561557] usb 3-6: current rate 16000 is different from the runtime rate
48000
[ 6340.671668] usb 3-6: current rate 16000 is different from the runtime rate
48000
[ 6340.806339] usb 3-6: current rate 16000 is different from the runtime rate
48000
[ 6401.231993] xhci_hcd :00:14.0: WARN Event TRB for slot 8 ep 11 with no
TDs queued?
[ 6401.232008] xhci_hcd :00:14.0: WARN Event TRB for slot 8 ep 3 with no
TDs queued?
[ 6484.050531] retire_capture_urb: 2 callbacks suppressed
[ 6484.050566] xhci_hcd :00:14.0: WARN Event TRB for slot 8 ep 3 with no
TDs queued?
[ 6484.050581] xhci_hcd :00:14.0: WARN Event TRB for slot 8 ep 11 with no
TDs queued?
[ 6551.946724] usb 3-6: current rate 16000 is different from the runtime rate
48000
[ 8173.853079] perf: interrupt took too long (3147 > 3143), lowering
kernel.perf_event_max_sample_rate to 63500
[10176.091353] usb 3-6: USB disconnect, device number 3
[10182.999290] usb 2-4: new high-speed USB device number 9 using xhci_hcd
[10183.152430] usb 2-4: New USB device found, idVendor=0b05, idProduct=7770,
bcdDevice= 5.04
[10183.152444] usb 2-4: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[10183.152450] usb 2-4: Product: Zenfone 8
[10183.152453] usb 2-4: Manufacturer: asus
[10183.152456] usb 2-4: SerialNumber: M4AIB762R1012G6
[12032.265126] usb 2-4: USB disconnect, device number 9
[13631.299929] perf: interrupt took too long (3939 > 3933), lowering
kernel.perf_event_max_sample_rate to 50750
[32324.432231] PM: suspend entry (deep)
[32324.450594] Filesystems sync: 0.018 seconds
[32325.128609] (NULL device *): firmware: direct-loading firmware
intel/ibt-20-1-3.ddc
[32325.128927] (NULL device *): firmware: direct-loading firmware
intel/ibt-20-1-3.sfi
[32325.129010] (NULL device *): firmware: direct-loading firmware iwlwifi-
cc-a0-62.ucode
[32325.130886] Freezing user space processes ... (elapsed 0.002 seconds) done.
[32325.133657] OOM killer disabled.
[32325.133706] Freezing remaining freezable tasks ... (elapsed 0.001 seconds)
done.
[32325.135101] printk: Suspending console(s) (use no_console_suspend to debug)
[32325.136469] e1000e: EEE TX LPI TIMER: 0011
[32325.136899] DMAR: DRHD: handling fault status reg 2
[32325.136902] DMAR: [DMA Read NO_PASID] Request device [0x06:0x00.0] fault
addr 0x0 [fault reason 0x06] PTE Read access is not set
[32325.156291] xhci_hcd :06:00.0: WARN: xHC save state timeout
[32325.156339] PM: suspend_common(): xhci_pci_suspend+0x0/0x140 [xhci_pci]
returns -110
[32325.156351] PM: pci_pm_suspend(): hcd_pci_suspend+0x0/0x30 [usbcore] returns
-110
[32325.156385] PM: dpm_run_callback(): pci_pm_suspend+0x0/0x160 returns -110
[32325.156394] xhci_hcd :06:00.0: PM: failed to suspend async: error -110
[32325.167443] sd 6:0:0:0: [sdd] Synchronizing SCSI cache
[32325.167461] sd 5:0:0:0: [sdc] Synchronizing SCSI cache
[32325.167464] sd 1:0:0:0: [sda] Synchronizing SCSI cache
[32325.167480] sd 2:0:0:0: [sdb] Synchronizing SCSI cache
[32325.167497] sd 1:0:0:0: [sda] Stopping disk
[32325.169116] sd 2:0:0:0: [sdb] Stopping disk
[32325.169177] sd 6:0:0:0: [sdd] Stopping disk
[32325.169211] sd 5:0:0:0: [sdc] Stopping disk
[32325.818572] PM: Some devices failed to suspend, or early wake event detected
[32325.818800] pci :00:05.0: disabled boot interrupts on device [8086:6f28]
[32325.819163] sd 1:0:0:0: [sda] Starting disk
[32325.819196] sd 2:0:0:0: [sdb] Starting disk
[32325.819235] sd 6:0:0:0: [sdd] Starting disk
[32325.819262] sd 5:0:0:0: [sdc] Starting disk
[32325.825187] nvme nvme0: 12/0/0 default/read/poll queues
[32326.010727] ACPI: \: failed to evaluate _DS

Bug#999423: powerdevil does not detect if on ac or battery

[Michael Meier]

Package: powerdevil
Version: 4:5.23.3-1
Severity: important
X-Debbugs-Cc: schissdra...@rmm.li

Powerdevil doesn't detect If i'm on AC or not. It always shows that the
powercord is plugged in. Doesn't matter if I unplug it or not.
It used to work (don't ask me when, maybe months ago?). So it doesn't do any of
the events it should do when on battery like reducing the screen brightness.
tlp does detect it correctly and at least sets everything else correctly.


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

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

Versions of packages powerdevil depends on:
ii  kio  5.86.0-1
ii  libc62.32-4
ii  libcap2-bin  1:2.44-1
ii  libkf5activities55.86.0-1
ii  libkf5authcore5  5.86.0-1
ii  libkf5completion55.86.0-1
ii  libkf5configcore55.86.0-1
ii  libkf5configgui5 5.86.0-1
ii  libkf5configwidgets5 5.86.0-1
ii  libkf5coreaddons55.86.0-1
ii  libkf5crash5 5.86.0-1
ii  libkf5dbusaddons55.86.0-1
ii  libkf5i18n5  5.86.0-1
ii  libkf5kiowidgets55.86.0-1
ii  libkf5networkmanagerqt6  5.86.0-1
ii  libkf5notifyconfig5  5.86.0-1
ii  libkf5service-bin5.86.0-1
ii  libkf5service5   5.86.0-1
ii  libkf5solid5 5.86.0-1
ii  libkf5widgetsaddons5 5.86.0-1
ii  libkworkspace5-5 4:5.23.3-1
ii  libpowerdevilcore2   4:5.23.3-1
ii  libpowerdevilui5 4:5.23.3-1
ii  libqt5core5a 5.15.2+dfsg-12
ii  libqt5dbus5  5.15.2+dfsg-12
ii  libqt5gui5   5.15.2+dfsg-12
ii  libqt5widgets5   5.15.2+dfsg-12
ii  libstdc++6   11.2.0-10
ii  libudev1 249.5-2
ii  powerdevil-data  4:5.23.3-1

powerdevil recommends no packages.

powerdevil suggests no packages.

-- no debconf information

Bug#999424: ITP: geners -- generic serialization library for C++

[Pierre Gruet]

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

* Package name: geners
  Version : 1.12.0
  Upstream Author : Igor Volobouev
* URL : https://geners.hepforge.org/
* License : Expat
  Programming Lang: C++
  Description : generic serialization library for C++

The Generic Serialization library is designed to address the problem of C++
object persistence in situations where the most typical data access pattern is
"write once read many" (WORM). "Geners" is a set of tools and conventions
which allows its users to develop C++ classes that can be converted to and
from a storable stream of bytes in a well-organized and type-safe manner.
Serialization of STL containers is supported, including the ones added in the
C++11 standard. Independent versioning of each class definition is allowed.

Among others, compared to the boost serialization package, Geners archives
provide random access to stored objects and can be used to create and
serialize very large archive-based objects. Yet, only binary archives are
implemented, and implementing non-intrusive serialization is less transparent.

I am packaging this software as a dependency of stopt, which is a packaging
target of mine. I plan to maintain it myself.

Bug#999422: Deluge fails with ModuleNotFoundError

[Brian Pepple]

Package: deluge
Version: 2.0.3-3.1
Severity: grave

When starting Deluge it fails when it attempts to import deluge.libtorrent.

Traceback (most recent call last):

File "/usr/lib/python3/dist-packages/deluge/_libtorrent.py", line 23, in 



  import deluge.libtorrent as lt
ModuleNotFoundError: No module named 'deluge.libtorrent'

During handling of the above exception, another exception occurred:
 Traceback (most recent call last):
  File "/usr/bin/deluged", line 33, in 

sys.exit(load_entry_point('deluge==2.0.3', 'console_scripts', 
'deluged')())
  File "/usr/lib/python3/dist-packages/deluge/core/daemon_entry.py", 
line 90, in start_daemon

from deluge.core.daemon import is_daemon_running

  File "/usr/lib/python3/dist-packages/deluge/core/daemon.py", line 22, 
in 

from deluge.core.core import Core
  File "/usr/lib/python3/dist-packages/deluge/core/core.py", line 28, 
in 

from deluge._libtorrent import LT_VERSION, lt

  File "/usr/lib/python3/dist-packages/deluge/_libtorrent.py", line 25, 
in 

import libtorrent as lt
ImportError: /lib/arm-linux-gnueabihf/libtorrent-rasterbar.so.10: 
undefined symbol: __atomic_fetch_add_8


OpenPGP_0xCB52D8AAC4292B05.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#998168: Area selection doesn't always erase the selection rectangle

[Eriberto]

Control: tags 998168 moreinfo

Hi Enrico,

Do you have any news?

Cheers,

Eriberto


Em dom., 31 de out. de 2021 às 17:06, Eriberto Mota
 escreveu:
>
> Em dom., 31 de out. de 2021 às 08:03, Enrico Zini  
> escreveu:
>
> > When selecting an area with scrot -s, the selection rectangle doesn't
> > always get erased as the rectangle is moved, resulting in a dirty
> > screenshot. See example attached.
>
> Hi Enico (my first AM!),
>
> Thanks for your message. However, this behavior is not a specific
> issue in scrot but in some window managers. The Gimp produces the same
> effect when capturing an area in KDE/Plasma in some scenarios (Gimp:
> File > Create > Screenshot > Select a screen area).
>
> There are 2 workarounds to solve this problem. The safest one that should 
> work:
>
> scrot --select --freeze
>
> Or using another selection mode:
>
> scrot --select --line mode=edge
>
> But this last one does not behave correctly with some CWM.
>
> Please, let me know if these options solve your problem.
>
> Cheers,
>
> Eriberto

Bug#986778: ITP: gcc-sh-elf -- GNU C compiler for embedded SuperH devices

[John Paul Adrian Glaubitz]

Hi John!

On 9/26/21 19:36, John Scott wrote:
> On Sun, 2021-09-26 at 18:55 +0200, John Paul Adrian Glaubitz wrote:
>> I'm willing to sponsor this as I am Debian's primary maintainer of the sh4 
>> port.
>
> Thanks for your consideration! FYI, I just pushed a small fix for the
> Binutils autopkgtest to both Git and mentors.debian.net. I would
> appreciate any critique you have about the packaging. I'm on #debian-
> ports (my nick is pert) if you'd prefer discussion there as well.

I tried building gcc-sh-elf today now that binutils-sh-elf is available in 
unstable
now. However, the build fails since makeinfo is missing:

checking valgrind.h usability... /<>/src/missing: 81: makeinfo: 
not found
WARNING: 'makeinfo' is missing on your system.
 You should only need it if you modified a '.texi' file, or
 any other file indirectly affecting the aspect of the manual.
 You might want to install the Texinfo package:
 
 The spurious makeinfo call might also be the consequence of
 using a buggy 'make' (AIX, DU, IRIX), in which case you might
 want to install GNU make:
 
make[5]: *** [Makefile:542: bfd.info] Error 127
make[5]: Leaving directory '/<>/bld/bfd/doc'
make[4]: *** [Makefile:1643: info-recursive] Error 1
make[4]: Leaving directory '/<>/bld/bfd'
make[3]: *** [Makefile:2969: all-bfd] Error 2
make[3]: *** Waiting for unfinished jobs
no

Could you have a look and fix the issue?

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#999377: ca-certificates-java: Removed support for Java12-18 from Bullseye

[Mátyás Szombathy]

Hi,

I found the issue.
The list for the for loop was extended in this commit:
https://salsa.debian.org/java-team/ca-certificates-java/-/commit/f956fed5d45cbdc47a923dfd737d4d68330b6c19

However, 5 months later in this commit the file was renamed from .in (I
guess include?) to regular file:
https://salsa.debian.org/java-team/ca-certificates-java/-/commit/9a467d1ac4d903a284c80843de719fff1d053731

This made the modifications in postinst.in irrelevant and the modifications
weren't moved over to the (now regular) jks-keystore.hook.

However, this has been solved 8 months ago in the most recent commit by
completely rewriting the file structure:
https://salsa.debian.org/java-team/ca-certificates-java/-/commit/ed71672c67c56836e551e12264ff74091e62e2eb

If possible, please provide an ETA for the fix.

Best regards,
Mátyás

On Wed, 10 Nov 2021 15:24:21 + =?utf-8?b?TcOhdHnDoXMgU3pvbWJhdGh5?= <
matyas.szomba...@gmail.com> wrote:
> Package: ca-certificates-java
> Version: 20190909
> Severity: important
> X-Debbugs-Cc: matyas.szomba...@gmail.com
>
> Dear Maintainer,
>
> The ca-certificates-java hook script goes through a for loop to find the
> first suitable java installation.
> The script doesn't list java12-18 as a possibility at all, hence the
> script fails.
> This was fixed with the previous update on 20190405, which closed the
> ticket #925431.
> Somehow this got removed and reset back to only support java7-11.
>
>* What led up to the situation?
> Tried to install openjdk-17-jre-headless
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>   Ran update-ca-certificates -f after package install finished.
>* What was the outcome of this action?
> As alternatives set-up java in PATH, the 86th line (java -jar
> ...) was able to find "java".
>* What outcome did you expect instead?
> The hook should list java 12-18 versions to be set-up as well.
>
> -- System Information:
> Debian Release: 11.1
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.4.0-90-generic (SMP w/4 CPU threads)
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /bin/dash
> Init: unable to detect
>
> Versions of packages ca-certificates-java depends on:
> ii  ca-certificates   20210119
> ii  libnss3   2:3.61-1
> ii  openjdk-17-jre-headless [java8-runtime-headless]  17~19-1
>
> ca-certificates-java recommends no packages.
>
> ca-certificates-java suggests no packages.
>
> -- no debconf information
>
>

Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW

[Mauro Sacchetto]

I again carried out a small experiment (as a simple user as I am) and 
precise,

or rather I correct, what was stated in a previous email.
Burning an ISO to a blank CD-RW (after: wodim dev=/dev/sr0 -v 
blank=fast) won't work either:

This is brasero-session.log:

Checking session consistency (brasero_burn_check_session_consistency 
brasero-burn.c:1739)

BraseroBurnURI called brasero_job_get_action
BraseroBurnURI called brasero_job_get_action
BraseroBurnURI called brasero_job_set_output_size_for_current_track
BraseroBurnURI stopping
BraseroBurnURI called brasero_job_get_action
BraseroBurnURI called brasero_job_get_session_output_size
BraseroBurnURI output set (IMAGE) image = /tmp/brasero_tmp_OFOIC1.bin 
toc = none

BraseroBurnURI called brasero_job_get_session_output_size
BraseroBurnURI called brasero_job_get_action
BraseroBurnURI called brasero_job_get_current_track
BraseroBurnURI no burn:// URI found
BraseroBurnURI stopping
BraseroLocalTrack called brasero_job_get_action
BraseroLocalTrack called brasero_job_get_action
BraseroLocalTrack called brasero_job_set_output_size_for_current_track
BraseroLocalTrack stopping
BraseroLocalTrack called brasero_job_get_action
BraseroLocalTrack called brasero_job_get_session_output_size
BraseroLocalTrack output set (IMAGE) image = /tmp/brasero_tmp_JEOIC1.bin 
toc = none

BraseroLocalTrack called brasero_job_get_session_output_size
BraseroLocalTrack called brasero_job_get_action
BraseroLocalTrack called brasero_job_get_current_track
BraseroLocalTrack no remote URIs
BraseroLocalTrack stopping
BraseroChecksumImage called brasero_job_get_current_track
BraseroChecksumImage called brasero_job_get_action
BraseroChecksumImage called brasero_job_get_flags
BraseroChecksumImage called brasero_job_get_action
BraseroChecksumImage called brasero_job_get_action
BraseroChecksumImage called brasero_job_get_fd_in
BraseroChecksumImage called brasero_job_set_output_size_for_current_track
BraseroChecksumImage stopping
BraseroChecksumImage called brasero_job_get_current_track
BraseroChecksumImage called brasero_job_get_action
BraseroChecksumImage called brasero_job_get_flags
BraseroChecksumImage called brasero_job_get_action
BraseroChecksumImage called brasero_job_get_session_output_size
BraseroChecksumImage output set (IMAGE) image = 
/tmp/brasero_tmp_VVNIC1.bin toc = none

BraseroChecksumImage called brasero_job_get_session_output_size
BraseroChecksumImage called brasero_job_get_action
BraseroChecksumImage called brasero_job_get_action
BraseroChecksumImage called brasero_job_get_current_track
BraseroChecksumImage called brasero_job_get_input_type
BraseroChecksumImage called brasero_job_set_current_action
BraseroChecksumImage called brasero_job_get_fd_in
BraseroChecksumImage called brasero_job_get_current_track
BraseroChecksumImage called brasero_job_get_current_track
BraseroChecksumImage Starting checksuming file 
/home/samiel/debian-11.1.0-amd64-netinst.iso (size = 396361728)

BraseroChecksumImage called brasero_job_get_fd_out
BraseroChecksumImage called brasero_job_get_current_track
BraseroChecksumImage Setting new checksum (type = 2) 
b710c178eb434d79ce40ce703d30a5f0 ((null) before)

BraseroChecksumImage Finished track successfully
BraseroChecksumImage stopping
BraseroLibburn called brasero_job_get_action
BraseroLibburn called brasero_job_get_action
BraseroLibburn unsupported operation
BraseroLibburn deactivating
BraseroLibburn called brasero_job_get_action
BraseroLibburn called brasero_job_get_action
BraseroLibburn called brasero_job_get_device
BraseroLibburn Drive (/dev/sr0) init result = 1
BraseroLibburn called brasero_job_get_flags
BraseroLibburn called brasero_job_get_media
BraseroLibburn called brasero_job_get_fd_in
BraseroLibburn called brasero_job_get_tracks
BraseroLibburn Setting multi 0
BraseroLibburn Setting burnproof 1
BraseroLibburn Setting dummy 0
BraseroLibburn called brasero_job_get_session_output_size
BraseroLibburn called brasero_job_set_current_action
BraseroLibburn burn_drive_convert_fs_adr( /dev/sr0 )
BraseroLibburn Writing
BraseroLibburn called brasero_job_set_dangerous
BraseroLibburn called brasero_job_set_current_action
BraseroLibburn called brasero_job_get_session_output_size
BraseroLibburn called brasero_job_set_current_action
BraseroLibburn burn_drive_is_enumerable_adr( /dev/sr0 ) is true
BraseroLibburn called brasero_job_get_session_output_size
BraseroLibburn called brasero_job_set_current_action
BraseroLibburn Async START UNIT succeeded after 0.1 seconds
BraseroLibburn called brasero_job_get_session_output_size
BraseroLibburn called brasero_job_set_current_action
BraseroLibburn Allocating buffer via mmap()
BraseroLibburn called brasero_job_get_session_output_size
BraseroLibburn called brasero_job_set_current_action
BraseroLibburn cd Profile= 0Ah , obs= 32768 , obs_pad= 0
BraseroLibburn called brasero_job_get_session_output_size
BraseroLibburn called brasero_job_set_current_action

Bug#999421: qemu-user-static: lli-13/arm64 causes segfault on amd64 host

[Andreas Beckmann]

Package: qemu-user-static
Version: 1:6.1+dfsg-8
Severity: important

on an amd64 host in in arm64 chroot running under qemu-user-static,
I observed some segmentation fault while building pocl against llvm-13
this is not reproducible on a porter box
it works fine with lli-12

in the arm64 chroot llvm-13 and clang-13 need to be installed

# cat compile_test_6cqj4.c 

  
#ifndef offsetof
#define offsetof(type, member) ((char *) &((type *) 0)->member - (char *) 0)
#endif

typedef double double16  __attribute__((__ext_vector_type__(16)));

  int main(int argc, char** argv) {

  typedef struct { char x; double16 y; } ac__type_alignof_;
int r = offsetof(ac__type_alignof_, y);
return r;

  }


# clang-13 -o try_run.bc -x c -emit-llvm -c --target=aarch64-unknown-linux-gnu 
compile_test_6cqj4.c

# lli-13 -force-interpreter try_run.bc ; echo $?
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash 
backtrace.
Stack dump:
0.  Program arguments: lli-13 -force-interpreter try_run.bc
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH 
or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
/usr/lib/aarch64-linux-gnu/libLLVM-13.so.1(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamEi+0x44)[0x55015f4368]
/usr/lib/aarch64-linux-gnu/libLLVM-13.so.1(_ZN4llvm3sys17RunSignalHandlersEv+0x70)[0x55015f2588]
/usr/lib/aarch64-linux-gnu/libLLVM-13.so.1(+0xdb9914)[0x55015f4914]
[0x4dc890]
[0x5509ac000c]
/usr/lib/aarch64-linux-gnu/libLLVM-13.so.1(+0x22cd730)[0x5502b08730]
lli-13(_Z9runOrcJITPKc+0x2218)[0x41aa20]
lli-13(main+0x290)[0x416960]
/lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0xe8)[0x55063ea8b8]
lli-13(_start+0x38)[0x415278]
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
139

Andreas

Bug#993686: the which warning is bogus

[Adam Borowski]

> Purging configuration files for libdebuginfod-common (0.185-2) ...
> /usr/bin/which: this version of `which' is deprecated; use `command -v' in 
> scripts instead.

That's bad advice, for a number of reasons.
Of these, maintscripts checking for ucf is somewhat likely to run into
`command -v` giving a wrong answer for non-executable files in $PATH.
This one can happen eg. after a bad backup restore (rsync w/o -x),
which is a scenario when the admin is likely to purge many packages while
trying to recover.

Unlike `command -v`, `which` handles that correctly.

The bad advice has been overruled by the CTTE, but debianutils maintainer
hasn't complied yet.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀   --  on #linux-sunxi
⠈⠳⣄

Bug#999420: dh_shlibdeps: Please consider option (or default) to ignore weak symbols for dependencies

[Josh Triplett]

Package: debhelper
Version: 13.5.2
Severity: wishlist
File: /usr/bin/dh_shlibdeps
X-Debbugs-Cc: j...@joshtriplett.org

When a program or library declares a weak symbol, that typically
indicates that it's prepared to do without the symbol.

However, dh_shlibdeps takes weak symbols into account when determining
library dependencies, and will produce a strict Depends on a library
even if only needed for a weak symbol. Some software (e.g. the Rust
standard library) works around this by calling dlsym instead, but that
introduces other potential issues, and weak symbols are *much* simpler
and easier to work with.

I'd like to propose changing this behavior, either with an option, or as
part of a future debhelper compatibility level (which could make that
option the default). I'd propose instead that dh_shlibdeps could
separate out dependencies from weak symbols, and put them in a separate
substitution field, which packagers could then choose to put in either
Depends or Recommends or Suggests or nowhere, as appropriate.

The net effect of this would be to broaden shared library dependencies,
making packages easier to install and backport, and making it easier for
upstreams to make use of weak symbols without introducing compatibility
issues.

- Josh Triplett

Bug#988462: A little more info please?

[Martin]

On 2021-11-09 19:26, Chris Carr wrote:
> - please could you explain why it is not suitable for inclusion in
>  bullseye? What is it that I am not seeing or experiencing in my daily
> use of it?

Problem is, that Trac (up to version 1.4) used to be a Python 2 program.
Python 2 is not supported anymore (or only in a very limited way), so
many dependencies for Trac are removed from Debian. It was impossible to
keep Trac with Python 2 in Debian.

Now Trac (>= 1.5) is based on Python 3, but the new code is not yet
considered stable by upstream. I hoped, that there were a Trac release
1.6 just in time for Debian 11, e.g. around 2021-01, but Trac
development happens a little bit slower even than Debians.

> Also, please could you recommend an alternative ticket management
> package that is included in bullseye. Preferably one that will import
> my trac db so I don't have to re-enter 11 years of history.

If Trac works fine for you (it does for me!), just stay with Debian 10,
e.g. in a systemd-nspawn or docker container. That's what we do in my
company: We run a server with Debian 11 and a systemd-nspawn container
of Debian 10 with Trac and PostgreSQL on it.

As soon as Trac 1.6 is released, I'll try to get it into Debian, as well
as some of the plugins, and hopefully it will be part of Debian 12.

Cheers

Bug#995655: dnsmasq breaks systemd autopkgtest: b'megasearch.net: 192.168.42.1' not found in b'megasearch.net: 207.148.248.143

[Michael Biebl]

Simon,

any news here?
Would you mind if I prepare an NMU with
26bbf5a314d833beaf0f147d24409969f05f3dba ?

Regards,
Michael


On Sun, 3 Oct 2021 21:32:53 +0200 Michael Biebl 
wrote:
> Control: reassign -1 dnsmasq/2.86-1
> 
> It's a (known) regression in dnsmasq 2.86-1
> 
> CCing what I sent Simon privately a couple of days ago
> 
> > Hi Simon,
> > 
> > as you probably know, the recent update of dnsmasq 2.86 to unstable
broke the systemd autopkgtests, namely test-networkd.py, and more
specifically
> > 
> > ==
> > ERROR: test_resolved_domain_restricted_dns (__main__.DnsmasqClientTest)
> > resolved: domain-restricted DNS servers
> > --
> > Traceback (most recent call last):
> >   File "/tmp/autopkgtest-
lxc.knebmh6r/downtmp/build.00t/src/test/networkd-test.py", line 659, in
test_resolved_domain_restricted_dns
> > out = subprocess.check_output(['resolvectl', 'query',
'search.example.com'])
> >   File "/usr/lib/python3.9/subprocess.py", line 424, in check_output
> > return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
> >   File "/usr/lib/python3.9/subprocess.py", line 528, in run
> > raise CalledProcessError(retcode, process.args,
> > subprocess.CalledProcessError: Command '['resolvectl', 'query',
'search.example.com']' returned non-zero exit status 1.
> > 
> > --
> > Ran 35 tests in 143.025s
> > 
> > FAILED (errors=1, skipped=2)
> > 
> > 
> > Afaics, this is a regression introduced by
> >
https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=12a9aa7c628e2d7dcd34949603848a3fb53fce9c
> > 
> > and should be fixed by
> >
https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=26bbf5a314d833beaf0f147d24409969f05f3dba
> 
> 
> 
> Am 03.10.21 um 19:23 schrieb Paul Gevers:
> > Source: dnsmasq, systemd
> > Control: found -1 dnsmasq/2.86-1
> > Control: found -1 systemd/247.9-1
> > Severity: serious
> > Tags: sid bookworm
> > X-Debbugs-CC: debian...@lists.debian.org
> > User: debian...@lists.debian.org
> > Usertags: breaks needs-update
> > 
> > Dear maintainer(s),
> > 
> > With a recent upload of dnsmasq the autopkgtest of systemd fails in
> > testing when that autopkgtest is run with the binary packages of dnsmasq
> > from unstable. It passes when run with only packages from testing. In
> > tabular form:
> > 
> > pass    fail
> > dnsmasq    from testing    2.86-1
> > systemd    from testing    247.9-1
> > all others from testing    from testing
> > 
> > I copied some of the output at the bottom of this report.



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

Bug#999419: RM: dtkwm -- RoM; Obsoleted by Upstream; Unused

[Boyuan Yang]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-CC: pkg-deepin-de...@lists.alioth.debian.org

Dear Debian FTP Masters,

Please remove package dtkwm ( https://tracker.debian.org/pkg/dtkwm ). This
library is archived by upstream and is not used by others. The only reverse
dependency is package deepin-screenshot, which is also due to be removed, see
https://bugs.debian.org/999413 .

Thanks,
Boyuan Yang


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

Bug#999418: chkrootkit: chkproc bogus OooPS, not expected 210672 value

[Dr. David Alan Gilbert]

Package: chkrootkit
Version: 0.55-1+b1
Severity: important

Dear Maintainer,
  Since upgrade to bullseye I'm seeing chkrootkit warnings of the
form:

OooPS, not expected 210672 value

I think the problem here is the new larger PIDs on newer kernels.

I think the problem here is something involving the MAX_PROCESSES calc in 
chkproc.c

TO reproduce:
  Let the host run for a while so you're getting larger PIDs, then

cd /usr/lib/chkrootkit
./chkproc

OooPS, not expected 210672 value

and that's the first PID in my system's ps output that's large.
I tried upgrading to testing's:
ii  chkrootkit 0.55-1+b1  amd64 
   rootkit detector

and it still happens for me.

I checked it really is the 64bit build:
dg@mx:/usr/lib/chkrootkit$ file /usr/lib/chkrootkit/chkproc 
/usr/lib/chkrootkit/chkproc: ELF 64-bit LSB pie executable, x86-64, version 1 
(SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=66d59d153338e672554b5b6fee85d5696d2cb968, for GNU/Linux 3.2.0, 
stripped

Dave

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

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

Versions of packages chkrootkit depends on:
ii  binutils   2.35.2-2
ii  debconf [debconf-2.0]  1.5.77
ii  libc6  2.31-13+deb11u2
ii  net-tools  1.60+git20181103.0eebece-1
ii  openssh-client 1:8.4p1-5
ii  procps 2:3.3.17-5

chkrootkit recommends no packages.

chkrootkit suggests no packages.

-- debconf information:
* chkrootkit/run_daily_opts: -q -n
* chkrootkit/run_daily: true
* chkrootkit/diff_mode: false

Bug#999417: Blank line in plymouthd.conf silently breaks it

[Trent W. Buck]

Package: plymouth
Version: 0.9.5-3
Severity: normal

See attached example files.


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

Kernel: Linux 5.10.0-9-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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
#  I don't care about PrisonPC branding on inmate desktops.
#   The only branding I care about is in ppcadm.
#
# The Debian 11 default splash is loud and Debian-y:
#   https://wiki.debian.org/DebianArt/Themes/Homeworld
#
# Change the default to match Windows 10 style.
# That is:
#   * black background
#   * a simple spinner animation
#   * if present, a centered logo, from
# /sys/firmware/acpi/tables/BGRT.
#
# This makes the transition from EFI to plymouth "seamless".
#
# WARNING: if this file contains any blank lines,
#  it will silently fail to include the correct theme in the ramdisk,
#  causing a de facto Theme=text behaviour.
[Daemon]
Theme=bgrt
#  I don't care about PrisonPC branding on inmate desktops.
#   The only branding I care about is in ppcadm.

# The Debian 11 default splash is loud and Debian-y:
#   https://wiki.debian.org/DebianArt/Themes/Homeworld
#
# Change the default to match Windows 10 style.
# That is:
#   * black background
#   * a simple spinner animation
#   * if present, a centered logo, from
# /sys/firmware/acpi/tables/BGRT.
#
# This makes the transition from EFI to plymouth "seamless".

[Daemon]
Theme=bgrt

Bug#999416: postrm: bash -> sh

[Adam Borowski]

Package: bash-completion
Version: 1:2.11-4
Severity: wishlist

Hi!
The postrm for bash-completion doesn't have any bashisms, yet its
hashbang is #!/bin/bash.  Could you please change it to #!/bin/sh?

For today, there's no gain (except for a tiny fraction of second saved
by a faster shell) -- but we have a slowly going project to make bash
non-essential.  That's probably many years in the future, but postrm
scripts have an issue -- there's no way to upgrade them if a package
has been removed but not purged.  Thus, it'd be good to do the switch
a long time in the advance.

And here, all it takes is removing two characters from the hashbang...


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

Kernel: Linux 5.15.0-00014-g67911f236fa6 (SMP w/64 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- no debconf information

Bug#999340: amavisd-new: amavis stops with DB unregistering failed

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2021-11-10 at 09:02 +0100, Yves-Alexis Perez wrote:
> On Wed, 2021-11-10 at 08:10 +0100, Yves-Alexis Perez wrote:
> > 
> > The first few logs seem normal (apparently the child processes will stop
> > after processing a number of tasks and a new child will be started) but
> > somehow the process then fails with that DB unregistering failed
> > message.

So it might actually be worse than that.

I tried to set $enable_db = 0; in 50_user.conf and in the end it still failed
with:

Nov 10 20:07:12 lxc-amavis amavis[2387]: (02387-20) Requesting process rundown 
after 20 tasks (and 20 sessions)
Nov 10 20:07:12 lxc-amavis amavis[2387]: (02387-20) TempDir removal: empty 
tempdir is being removed: 
/var/lib/amavis/tmp/amavis-2020T162308-02387-YoaC54ip
Nov 10 20:07:12 lxc-amavis amavis[2387]: (02387-20) load: 0 %, total idle 
13421.884 s, busy 22.927 s
Nov 10 20:07:12 lxc-amavis amavis[2387]: (02387-20) sd_notify (no socket): 
STOPPING=1\nSTATUS=Server rundown, notifying child processes.
Nov 10 20:07:12 lxc-amavis amavis[2387]: (02387-20) Net::Server: 
2021/11/10-20:07:12 Server closing!
Nov 10 20:07:12 lxc-amavis amavis[2387]: (02387-20) sd_notify (no socket): 
STATUS=Child processes have been stopped.

So no DB error at all, but the main process still exits, without failure:

● amavis.service - Interface between MTA and virus scanner/content filters
 Loaded: loaded (/lib/systemd/system/amavis.service; enabled; vendor
preset: enabled)
 Active: inactive (dead) since Wed 2021-11-10 20:07:12 CET; 4min 30s ago
   Docs: http://www.ijs.si/software/amavisd/#doc
Process: 2385 ExecStartPre=/usr/bin/find /var/lib/amavis -maxdepth 1 -name
amavis-* -type d -exec rm -rf {} ; (code=exited, status=0/SUCCESS)
Process: 2386 ExecStartPre=/usr/bin/find /var/lib/amavis/tmp -maxdepth 1 -
name amavis-* -type d -exec rm -rf {} ; (code=exited, status=0/SUCCESS)
Process: 2387 ExecStart=/usr/sbin/amavisd-new foreground (code=exited,
status=0/SUCCESS)
   Main PID: 2387 (code=exited, status=0/SUCCESS)
CPU: 29.155s

What would be the reason for a shutdown like this?
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmGMGhAACgkQ3rYcyPpX
RFu6XQgAwUcX3ZagGRHRfCRzVUwYR8zs+fAciovbU3a7lBTvhWIhXl3A68FPGy+D
ImvleCLHbFU+7NGpBhhmxYN723X4oLS1Z/L5WYAYGj/bI4EtefQghoQ3DsXX0jMt
/gWtNQe9brdOH/UzHCA7cCO/yDyYjPDK0ZK9TH3rDJl/4fH9V0oXEMjE7WSudWx+
TTyuZDBg+JUbW2cVEcGZx5RbjYBk9d5yXHHxCtLJxgi7pL2AxupUX0aSmQL4/0/P
Z//nB8ZdRwN/1Z6T/Z2O7FFwT+O0f2sa5bDYZeK3zbbpk33pstcqU4IJtVYnBwXG
kSRqOZypWbWHj5gEUlRv/YbwWemyhA==
=Y0iz
-END PGP SIGNATURE-

Bug#999414: postrm: bash -> sh

[Adam Borowski]

Package: libdebuginfod-common
Version: 0.185-2
Severity: wishlist

Hi!
The postrm for libdebuginfod-common doesn't have any bashisms, yet its
hashbang is #!/bin/bash.  Could you please change it to #!/bin/sh?

For today, there's no gain (except for a tiny fraction of second saved
by a faster shell) -- but we have a slowly going project to make bash
non-essential.  That's probably many years in the future, but postrm
scripts have an issue -- there's no way to upgrade them if a package
has been removed but not purged.  Thus, it'd be good to do the switch
a long time in the advance.

And here, all it takes is removing two characters from the hashbang...


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

Kernel: Linux 5.15.0-00014-g67911f236fa6 (SMP w/64 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libdebuginfod-common depends on:
ii  debconf [debconf-2.0]  1.5.79
ii  ucf3.0043

libdebuginfod-common recommends no packages.

libdebuginfod-common suggests no packages.

-- debconf information excluded

Bug#999413: RM: deepin-screenshot -- RoM; Merged into other project

[Boyuan Yang]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-CC: pkg-deepin-de...@lists.alioth.debian.org

Dear Debian FTP Masters,

Please remove package deepin-screenshot (
https://tracker.debian.org/pkg/deepin-screenshot ). It is now part of package
deepin-screen-recorder ( https://tracker.debian.org/pkg/deepin-screen-recorder
) thus no longer needed anymore.

Thanks,
Boyuan Yang


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

Bug#999412: node-winston: long description is bogus

[Jonas Smedegaard]

Package: node-winston
Version: 3.3.3-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package long description tells nothing about the package.

Seems to be boilerplate from some automated package build bootstrapping.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmGMGxUACgkQLHwxRsGg
ASFLABAArElcCRv+Q/Lnmrobc9bSgwQNkYEAR0bcx68jVZyHE37E/cPuMQ8lSCJg
Q0iLW/PG9O7XGLfGZB3RbmF0/KOuPPLJT5UQMOPFpbPxY5EpdfZxGBmYFlGMOFA8
D1dTIjhjcZFya+H4MYd13FRt5xZLt/OovXbxawKMx8ZRM7n60m/+7i0DTGNYjEgH
baVYPWuE0qcpOGcAlks1EoxawPiIomdrPH/0rJLZMzkqDwerOrbafKuPDzeBznch
Zt5aSsHBj0dT6/isDr1GOxGYhfjp619ndL142BE1+xMU7iw7m2DJQsp6TEWypayn
9wKcGwwYKoRziD1c+xsfpyQv6FSmJLnn2NeL4Cyh8D76EYttVm9W9emIYYq7gkBU
ns4x2QW8/tnPJ2RjQOK0IdHgsUBrS86EPuoN7aezGytE4Nv439o2mKZjXPjXS2yk
r7ePxPWMT3UPHyelCSO46MnHNrqCKLN4QAE2o3lfd3vJyxW2kZzgu/Q1Fj14Uxe+
tEoAiRmgIJxKa64mwtcXgcjx0MUGP2uJXkCMhxq9xYkoDPo+Zz+L/CuNYrAkklVl
+doyGAgUDYrF8uIPX8V4ICda0mrP4JmkfZI+H5ASQ+qxkK2cPxstxkODg3qh7dY2
dzBxdQLY7nmYr9zQmFgTsa+WmfM39eAHXho/aaOUlBoOPr1q8K8=
=ARqh
-END PGP SIGNATURE-

Bug#999375: rsyslog randomly exits, possibly caused by imrelp

[Michael Biebl]

On 10.11.21 18:49, Anton Khirnov wrote:

Quoting Michael Biebl (2021-11-10 18:27:29)

Hi Anton,

thanks for the details bug report and going the extra mile to verify it
is still reproducible with testing.

I quickly checked the upstream bug tracker, and found
https://github.com/rsyslog/rsyslog/issues/4302
https://github.com/rsyslog/rsyslog/issues/4175
https://github.com/rsyslog/rsyslog/issues/3915

which look related to your problem. All issues with relp+gnutls


All of them point to an issue with GnuTLS and the bug reporters
mentioned that switching to OpenSSL fixed the issue.

The Debian package is built with OpenSSL support.
Would you mind testing if switching to OpenSSL fixes the issue for you?


Great, switching to openssl seems to fix this.


Thanks for testing!


It's not great that gnutls is used by default though - the module is now
borderline unusable with it.


[Looping in Rainer, as upstream of rsyslog]

Rainer, is there a way to switch the default to OpenSSL if rsyslog has 
been built with GnuTLS and OpenSSL support?


I'm a bit wary of completely disabling GnuTLS support.

Regards,
Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#999411: ITP: mcpl -- Monte Carlo Particle Lists - tools for the .mcpl file format

[Roland Mas]

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

* Package name: mcpl
  Version : 1.3.2
  Upstream Author : Thomas Kittelmann 
* URL : https://mctools.github.io/mcpl/
* License : CC0
  Programming Lang: C, C++, Python
  Description : Monte Carlo Particle Lists - tools for the .mcpl file format

This is MCPL - Monte Carlo Particle Lists.

Included are the core utilities for reading and writing .mcpl files: A
binary format with lists of particle state information, for
interchanging and reshooting events between various Monte Carlo
simulation applications. The core utilities include both command line
tools and programming interfaces for C/C++ and python.

This package is going to be useful for the McStas/McXtrace Monte Carlo
neutron/X-ray ray tracing packages.

Bug#999375: rsyslog randomly exits, possibly caused by imrelp

[Anton Khirnov]

Quoting Michael Biebl (2021-11-10 18:27:29)
> Hi Anton,
> 
> thanks for the details bug report and going the extra mile to verify it 
> is still reproducible with testing.
> 
> I quickly checked the upstream bug tracker, and found
> https://github.com/rsyslog/rsyslog/issues/4302
> https://github.com/rsyslog/rsyslog/issues/4175
> https://github.com/rsyslog/rsyslog/issues/3915
> 
> which look related to your problem. All issues with relp+gnutls
> 
> 
> All of them point to an issue with GnuTLS and the bug reporters 
> mentioned that switching to OpenSSL fixed the issue.
> 
> The Debian package is built with OpenSSL support.
> Would you mind testing if switching to OpenSSL fixes the issue for you?

Great, switching to openssl seems to fix this.

It's not great that gnutls is used by default though - the module is now
borderline unusable with it.

Thanks a lot,
-- 
Anton Khirnov

Bug#998893: closed by Debian FTP Masters (reply to Matthew Vernon ) (Bug#998893: fixed in orphan-sysvinit-scripts 0.09)

[Matthew Vernon]

On 10/11/2021 16:51, Adam Borowski wrote:

On Wed, Nov 10, 2021 at 12:21:09PM +, Debian Bug Tracking System wrote:

#998893: orphan-sysvinit-scripts: fails to configure: "not replacing deleted config 
file /etc/init.d/rsyslog"
It has been closed by Debian FTP Masters  (reply to 
Matthew Vernon ).


Alas, systems that were affected by this bug still fail to upgrade:


Yes, I'm afraid that's expected (because ucf still "knows" that the user 
deleted /etc/init.d/rsyslog). Sorry!



dpkg-query: no path found matching pattern /etc/init.d/rsyslog
Not replacing deleted config file /etc/init.d/rsyslog
update-rc.d: error: initscript does not exist: /etc/init.d/rsyslog
dpkg: error processing package orphan-sysvinit-scripts (--configure):
  installed orphan-sysvinit-scripts package post-installation script subprocess 
returned error exit status 1
Processing triggers for man-db (2.9.4-2) ...
Errors were encountered while processing:
  orphan-sysvinit-scripts
E: Sub-process /usr/bin/dpkg returned an error code (1)


I think the easiest fix is:
ln -s /usr/share/orphan-sysvinit-scripts/rsyslog /etc/init.d/rsyslog

And then dpkg --pending --configure should work OK

Regards,

Matthew

Bug#999358: libwebkit2gtk-4.0-37: Upgrade from 2.30.1-1~bpo10+1 to 2.34.1-1~deb10u1 crashes evolution with "std::bad_alloc"

[Alberto Garcia]

Control: tags -1 moreinfo

On Wed, Nov 10, 2021 at 01:47:19PM +0100, Norbert Berzen wrote:
> I recently upgraded libwebkit2gtk-4.0-37 from version
> 2.30.1-1~bpo10+1 to version 2.34.1-1~deb10u1 as suggested for
> security.
> 
> After upgrade my evolution mail client crashed immediately after
> startup by "std::bad_alloc".

Hello, I'm trying here with Evolution 3.30.5 and webkitgtk
2.34.1-1~deb10u1 and I cannot reproduce the crash.

Does it always happen, or do you have a way to reproduce it?

If you can send me a backtrace with gdb I'd appreciate it. Better if
you can install the debug packages from this repository:

deb http://debug.mirrors.debian.org/debian-debug/ buster-debug main

Thanks!

Berto

Bug#873033: ITP: opengcs -- Guest Compute Service for Linux Hyper-V Container

[Balint Reczey]

Hi Jose,

On Wed, 6 Jun 2018 16:47:53 + Jose Miguel Parrella Romero
 wrote:

> I intend to explore bringing the opengcs source package to Debian in
collaboration with Balint.

The upstream project has since been obsoleted by hcsshim. Closing the
bug report again.

Cheers,

Balint

Bug#999410: python-rocksdb ftbfs with Python 3.10

[Matthias Klose]

Source: python-rocksdb
Version: 0.8.0~rc3-1
Severity: important
Tags: ftbfs patch
User: debian-pyt...@lists.debian.org
Usertags: python3.10

python-rocksdb ftbfs with python3-defaults from experimental:

[...]
x86_64-linux-gnu-gcc -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2
-Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv
-O2 -g -O2 -ffile-prefix-map=/<>=. -flto=auto -ffat-lto-objects
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/python3.10 -c rocksdb/_rocksdb.cpp -o
build/temp.linux-x86_64-3.10/rocksdb/_rocksdb.o -std=c++11 -O3 -Wall -Wextra
-Wconversion -fno-strict-aliasing -fno-rtti
rocksdb/_rocksdb.cpp:6:10: fatal error: Python.h: No such file or directory
6 | #include "Python.h"
  |  ^~
compilation terminated.
error: command '/usr/bin/x86_64-linux-gnu-gcc' failed with exit code 1


the package has to build-depend on python3-all-dev instead of python3-all.
patch at
http://launchpadlibrarian.net/568222147/python-rocksdb_0.8.0~rc3-1build1_0.8.0~rc3-1ubuntu1.diff.gz

Bug#999409: jpy ftbfs with Python 3.10

[Matthias Klose]

Source: jpy
Version: 0.9.0-3
Severity: important
Tags: ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.10

jpy ftbfs with python3-defaults from experimental:

https://launchpadlibrarian.net/567963939/buildlog_ubuntu-jammy-amd64.jpy_0.9.0-3build5_BUILDING.txt.gz

src/main/c/jpy_jmethod.c:847:5: note: (near initialization for
‘JOverloadedMethod_Type.tp_vectorcall_offset’)
x86_64-linux-gnu-gcc -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2
-Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv
-O2 -g -O2 -ffile-prefix-map=/<>=. -flto=auto -ffat-lto-objects
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -fPIC -Isrc/main/c -I/usr/lib/jvm/default-java/include
-I/usr/lib/jvm/default-java/include/linux -I/usr/include/python3.10 -c
src/main/c/jpy_jobj.c -o build/temp.linux-x86_64-3.10/src/main/c/jpy_jobj.o
src/main/c/jpy_jobj.c: In function ‘JType_InitSlots’:
src/main/c/jpy_jobj.c:683:24: error: lvalue required as left operand of 
assignment
  683 | Py_REFCNT(typeObj) = 1;
  |^
error: command '/usr/bin/x86_64-linux-gnu-gcc' failed with exit code 1
E: pybuild pybuild:354: build: plugin distutils failed with: exit code=1:
/usr/bin/python3.10 setup.py build
I: pybuild base:237: /usr/bin/python3 setup.py build

Bug#999375: rsyslog randomly exits, possibly caused by imrelp

[Michael Biebl]

Hi Anton,

thanks for the details bug report and going the extra mile to verify it 
is still reproducible with testing.


I quickly checked the upstream bug tracker, and found
https://github.com/rsyslog/rsyslog/issues/4302
https://github.com/rsyslog/rsyslog/issues/4175
https://github.com/rsyslog/rsyslog/issues/3915

which look related to your problem. All issues with relp+gnutls


All of them point to an issue with GnuTLS and the bug reporters 
mentioned that switching to OpenSSL fixed the issue.


The Debian package is built with OpenSSL support.
Would you mind testing if switching to OpenSSL fixes the issue for you?

Regards,
Michael

On 10.11.21 16:22, Anton Khirnov wrote:

Package: rsyslog
Version: 8.2102.0-2
Severity: important

Dear Maintainer,
since upgrading from buster to bullseye, rsyslog on some of my machines
randomly exits.

My setup contains
- a centralized log server, receiving logs with imrelp
- two relays, that forward logs from other hosts using imrelp+omrelp
- multiple hosts that send their logs (to either one of the relays or
   directly to the central server) with omrelp

I tried running rsyslog with debugging messages under gdb, right before
it exits, the output is

1778.966318176:imrelp.c   : imrelp.c: librelp: done epoll_wait, nEvents:1
1778.966486859:imrelp.c   : imrelp.c: librelp: generic error: ecode 10014, 
emsg 'TLS record reception failed [gnutls error -54: Error in the pull 
function.]'
1778.966543315:imrelp.c   : errmsg.c: Called LogMsg, msg: imrelp[10514]: 
error 'TLS record reception failed [gnutls error -54: Error in the pull 
function.]', object  'lstn 10514: conn to clt 2a00:c500:561:201:7910:b4d
8:2065:6c6b/2a00:c500:561:201:7910:b4d8:2065:6c6b' - input may not work as 
intended
1778.966585565:imrelp.c   : operatingstate.c: osf: MSG imrelp[10514]: error 
'TLS record reception failed [gnutls error -54: Error in the pull function.]', 
object  'lstn 10514: conn to clt 2a00:c500:561:201:7910:b4d8:2
065:6c6b/2a00:c500:561:201:7910:b4d8:2065:6c6b' - input may not work as 
intended: signaling new internal message via SIGTTOU: 'imrelp[10514]: error 
'TLS record reception failed [gnutls error -54: Error in the pull functio
n.]', object  'lstn 10514: conn to clt 
2a00:c500:561:201:7910:b4d8:2065:6c6b/2a00:c500:561:201:7910:b4d8:2065:6c6b' - 
input may not work as intended [v8.2102.0 try https://www.rsyslog.com/e/2353 ]'
rsyslogd: imrelp[10514]: error 'TLS record reception failed [gnutls error -54: 
Error in the pull function.]', object  'lstn 10514: conn to clt 
2a00:c500:561:201:7910:b4d8:2065:6c6b/2a00:c500:561:201:7910:b4d8:2065:6c6b' -
  input may not work as intended [v8.2102.0 try https://www.rsyslog.com/e/2353 ]
Cannot find user-level thread for LWP 25226: generic error
(gdb) [Thread 0x7536c700 (LWP 25237) exited]
[Thread 0x75b6d700 (LWP 25236) exited]
[Thread 0x7676f700 (LWP 25234) exited]
[Thread 0x76b70700 (LWP 25233) exited]
[Thread 0x76f71700 (LWP 25232) exited]
[Thread 0x77a6d240 (LWP 25226) exited]
[Inferior 1 (process 25226) exited with code 01]

I have observed the issue only on the central log server and both of the
relays, not on the hosts -- i.e. only those systems that use imrelp.

I can also reproduce it semi-reliably by SIGKILLing (so it doesn't close
the connection cleanly) a RELP client (i.e. an rsyslog instance using
omrelp), which will almost (but not quite) always cause its
corresponding RELP server to exit in the above manner.

So if I SIGKILL rsyslogd on one of the hosts, it will cause its relay to
die, which in turn causes the central server to die, which in turn makes
me very unhappy. Since logging is critical for my infrastructure, I
would very much appreciate it if this was fixed promptly.

rsyslog 8.2110.0-1 from testing still exhibits the issue.

Cheers,





OpenPGP_signature
Description: OpenPGP digital signature

Bug#997225: Vendoring image-spec and runtime-spec seem to be the issue

[Reinhard Tartler]

Control: tag -1 patch

On Wed, Nov 10, 2021 at 7:55 AM Shengjing Zhu  wrote:

>
> > > Cloud you backport following commit?
> > >
> > >
> https://github.com/containers/libocispec/commit/8489d9b60105e487564c9966b5748e2a6ea2855b
> > >
>
> This patch updates libocispec/Makefile.am, which is needed to be
> backported.
>
> This patch looks like doing nothing to C part, because the generated source
> is removed in upstream repo. Theses files(which are added in Makefile.am)
> can
> be generated by `make -C libocispec generate`. So please also uncomment
> this
> line in debian/rules.
>
>
>
D'oh, my bad, I've overlooked the Makefile.am parts. So the generator *is*
already
invoked, but the automake system doesn't pick up all files, leading to the
linker failures.

I've implemented your suggestion in
https://salsa.debian.org/debian/crun/-/merge_requests/1/diffs and can
confirm that the package now builds fine.

Dmitry, please let me know if you are comfortable with me NMU'ing the
package with the patch from salsa.


-- 
regards,
Reinhard

Bug#999408: beancount ftbfs with Python 3.10 (test failures)

[Matthias Klose]

Source: beancount
Version: 2.3.3-1
Severity: important
Tags: ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.10

beancount ftbfs with python3-defaults from experimental:

[...]
=== FAILURES ===
___ TestScriptIdentify.test_identify ___

self = 

def test_identify(self):
regexp = textwrap.dedent("""\
\\*\\*\\*\\* .*/Downloads/ofxdownload.ofx
Importer: +mybank-checking-ofx
Account: +Assets:Checking

\\*\\*\\*\\* .*/Downloads/Subdir/bank.csv
Importer: +mybank-credit-csv
Account: +Liabilities:CreditCard

\\*\\*\\*\\* .*/Downloads/Subdir/readme.txt

""").strip()

# Invoke with new-style imports as script, with an ingest() call in the
script.
with test_utils.capture('stdout', 'stderr') as (stdout, stderr):
env = os.environ.copy()
env['PYTHONPATH'] = ':'.join(sys.path)
>   output = subprocess.check_output(
[sys.executable, path.join(self.tempdir, 'testimport.py'),
 '--downloads', path.join(self.tempdir, 'Downloads'),
 'identify'], shell=False, env=env)

beancount/ingest/identify_test.py:98:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
/usr/lib/python3.10/subprocess.py:420: in check_output
return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

input = None, capture_output = False, timeout = None, check = True
popenargs = (['/usr/bin/python3.10',
'/tmp/TestScriptIdentify.z1bfzrqc/testimport.py', '--downloads',
'/tmp/TestScriptIdentify.z1bfzrqc/Downloads', 'identify'],)
kwargs = {'env': {'APT_CONFIG': '/var/lib/sbuild/apt.conf', 'CCACHE_DIR':
'/<>/.pybuild/cca...g -Wformat -Werror=format-security',
'CPPFLAGS': '-Wdate-time -D_FORTIFY_SOURCE=2', ...}, 'shell': False, 'stdout': 
-1}
process = 
stdout = b'', stderr = None, retcode = 1

def run(*popenargs,
input=None, capture_output=False, timeout=None, check=False, 
**kwargs):
"""Run command with arguments and return a CompletedProcess instance.

The returned instance will have attributes args, returncode, stdout and
stderr. By default, stdout and stderr are not captured, and those 
attributes
will be None. Pass stdout=PIPE and/or stderr=PIPE in order to capture 
them.

If check is True and the exit code was non-zero, it raises a
CalledProcessError. The CalledProcessError object will have the return 
code
in the returncode attribute, and output & stderr attributes if those 
streams
were captured.

If timeout is given, and the process takes too long, a TimeoutExpired
exception will be raised.

There is an optional argument "input", allowing you to
pass bytes or a string to the subprocess's stdin.  If you use this 
argument
you may not also use the Popen constructor's "stdin" argument, as
it will be used internally.

By default, all communication is in bytes, and therefore any "input" 
should
be bytes, and the stdout and stderr will be bytes. If in text mode, any
"input" should be a string, and stdout and stderr will be strings 
decoded
according to locale encoding, or by "encoding" if set. Text mode is
triggered by setting any of text, encoding, errors or 
universal_newlines.

The other arguments are the same as for the Popen constructor.
"""
if input is not None:
if kwargs.get('stdin') is not None:
raise ValueError('stdin and input arguments may not both be 
used.')
kwargs['stdin'] = PIPE

if capture_output:
if kwargs.get('stdout') is not None or kwargs.get('stderr') is not 
None:
raise ValueError('stdout and stderr arguments may not be used '
 'with capture_output.')
kwargs['stdout'] = PIPE
kwargs['stderr'] = PIPE

with Popen(*popenargs, **kwargs) as process:
try:
stdout, stderr = process.communicate(input, timeout=timeout)
except TimeoutExpired as exc:
process.kill()
if _mswindows:
# Windows accumulates the output in a single blocking
# read() call run on child threads, with the timeout
# being done in a join() on those threads.  communicate()
# _after_ kill() is required to collect that and add it
# to the exception.
exc.stdout, exc.stderr = process.communicate()
else:
# POSIX _communicate already populated the output so
# far into the TimeoutExpired excep

Bug#988462: Apologies

[Chris Carr]

Sorry, the second copy of my previous email was actually sent first, 
from a defunct email account, I had accidentally set the From field 
wrong. Apologies for the duplication.

Bug#999363: Shouldn't replace pulseaudio by pipewire by default

[Dylan Aïssi]

Hi Sebastien,

Le mer. 10 nov. 2021 à 15:45, Sebastien Bacher  a écrit :
>
> The pipewire 0.3.39-3 updated replaced pipewire-media-service Recommends
> by wireplumber, or wireplumber Recommends pipewire-pulse which makes it
> take over pulseaudio as the default sound service. We got several report
> of people upgrading and having issues on #debian-gnome.
> Pipewire is installed by default on GNOME because it's used for screen
> recording but pulseaudio is still installed and our default sound server.
>

I re-added pipewire-media-service as an alternative to wireplumber in
pipewire Recommends in the last upload 0.3.39-4.
Could this fix the issue?

> Switching the default sound service is an option but should probably be
> a project discussion and not a consequence of a dependency tweak. Could
> you perhaps lower the Recommends on pipewire-pulse to a Suggests for now?

I totally agree, that was not my aim to switch the default sound service.
Having wireplumber installed without pipewire-pulse is not enough to
get back pulseaudio as a sound service, we need to modify
/usr/share/wireplumber/wireplumber.conf
I am not sure how to correctly handle that. Any suggestion?

Best,
Dylan

Bug#996867: openjdk-17 in Bullseye not up to date

[Thorsten Glaser]

Hi,

> However, this version has not been updated since the Bullseye release
> (whereas the up to date version is available in testing).

right, someone has to do a stable or stable-security upload; probably
the latter, from how this has been handed for other JDK versions before.

Primary contact for this is Doko (Cc’d, though he probably also reads
the list?); I assume from the release note snippet that this has been
ok’d by release/security teams beforehand.

> There is a bug report [2] for this problem, but it seems to have been
> closed without any reason.

No, its version tracking merely marks a version that’s not in stable
as fixing this bug, but it’s still affecting stable/bullseye. The BTS
can be confusing like that ;-)

> version. You can find lots of tutorials on the Internet explaining how

Yeah, well, those tutorials… *sigh* having taken over openjdk-8 for
a while I ran into some counter-productive advice from them as well.
But there’s not much one can do about them, except of course provide
working things for the good case.

> Is an upgrade of openjdk-17 still planned for Bullseye?

I’d assume so, though you might have noticed the snippet did say not
every update is guaranteed to be made available.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#998893: closed by Debian FTP Masters (reply to Matthew Vernon ) (Bug#998893: fixed in orphan-sysvinit-scripts 0.09)

[Adam Borowski]

On Wed, Nov 10, 2021 at 12:21:09PM +, Debian Bug Tracking System wrote:
> #998893: orphan-sysvinit-scripts: fails to configure: "not replacing deleted 
> config file /etc/init.d/rsyslog"
> It has been closed by Debian FTP Masters  
> (reply to Matthew Vernon ).

Alas, systems that were affected by this bug still fail to upgrade:

dpkg-query: no path found matching pattern /etc/init.d/rsyslog
Not replacing deleted config file /etc/init.d/rsyslog
update-rc.d: error: initscript does not exist: /etc/init.d/rsyslog
dpkg: error processing package orphan-sysvinit-scripts (--configure):
 installed orphan-sysvinit-scripts package post-installation script subprocess 
returned error exit status 1
Processing triggers for man-db (2.9.4-2) ...
Errors were encountered while processing:
 orphan-sysvinit-scripts
E: Sub-process /usr/bin/dpkg returned an error code (1)

Not sure how many folks have upgraded in the meantime, but I guess we should
check for upgrades from 0.08 and recover.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ If you ponder doing what Jesus did, remember than flipping tables
⢿⡄⠘⠷⠚⠋⠀ and chasing people with a whip is a prime choice.
⠈⠳⣄

Bug#999406: python-misaka ftbfs with Python 3.10

[Matthias Klose]

Source: python-misaka
Version: 1.0.2-7
Severity: important
Tags: ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.10

python-misaka ftbfs with python3-defaults from experimental:

[...]
x86_64-linux-gnu-gcc -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2
-Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv
-O2 -g -O2 -ffile-prefix-map=/<>=. -flto=auto -ffat-lto-objects
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/python3.10 -c src/misaka.c -o
build/temp.linux-x86_64-3.10/src/misaka.o
src/misaka.c: In function ‘__pyx_tp_dealloc_6misaka_Markdown’:
src/misaka.c:2594:5: error: lvalue required as increment operand
 2594 | ++Py_REFCNT(o);
  | ^~
src/misaka.c:2597:5: error: lvalue required as decrement operand
 2597 | --Py_REFCNT(o);
  | ^~
[...]

Bug#999400: cloud-init: Update cloud-init in stable for newer version of Azure IMDS

[Noah Meyerhans]

On Wed, Nov 10, 2021 at 05:05:12PM +0100, Martin Zobel-Helas wrote:
> Due to an update on the Azure side, it would be helpful to support the
> newer API version of IMDS within cloud-init, a patch, that didn't make
> it to stable, as of the time the change was made, changes on cloud-init
> weren't allowed in the Debian freeze process.
> 
> The proposed change can be found here:
> https://github.com/canonical/cloud-init/pull/884/, though the patch on
> Github will not apply cleanly directly on the version of cloud-init in
> stable. I would be willing to prepare a more clean patch for that.

Could we also get the fix for
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979974 into stable at
the same time?  (Assuming it's actually needed; if you could help with
confirmation of that it would be good.)

> Also this code only affects one cloud vendor and should not break stuff
> on other cloud vendors platform. It only adds information for IMDS.

Agreed, I think the SRMs will be OK with this.  We should show as much
evidence of testing as is practical to help ease any concerns that they
may have.

> Would this be a patch we would agree to be carried through the full
> release cycle of Debian 11?

It looks reasonable to me.

noah

Bug#999405: python-cytoolz ftbfs with Python 3.10 (test failures)

[Matthias Klose]

Source: python-cytoolz
Version: 0.11.0-1
Severity: important
Tags: ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.10

python-cytoolz ftbfs with python3-defaults from experimental:


[...]
I: pybuild base:237: cd /<>/.pybuild/cpython3_3.10_cytoolz/build;
python3.10 -m pytest
= test session starts ==
platform linux -- Python 3.10.0+, pytest-6.2.5, py-1.10.0, pluggy-0.13.0
rootdir: /<>
collected 187 items

cytoolz/tests/test_curried.py .. [  5%]
cytoolz/tests/test_dev_skip_test.py ..   [  6%]
cytoolz/tests/test_dicttoolz.py  [ 27%]
...  [ 31%]
cytoolz/tests/test_docstrings.py .   [ 32%]
cytoolz/tests/test_doctests.py . [ 32%]
cytoolz/tests/test_functoolz.py ..   [ 52%]
cytoolz/tests/test_inspect_args.py ..F.. [ 62%]
cytoolz/tests/test_itertoolz.py  [ 83%]
..   [ 88%]
cytoolz/tests/test_none_safe.py  [ 90%]
cytoolz/tests/test_recipes.py .. [ 91%]
cytoolz/tests/test_serialization.py .[ 96%]
cytoolz/tests/test_signatures.py ... [ 98%]
cytoolz/tests/test_tlz.py .  [ 98%]
cytoolz/tests/test_utils.py ..   [100%]

=== FAILURES ===
___ test_introspect_builtin_modules 

def test_introspect_builtin_modules():
mods = [builtins, functools, itertools, operator, cytoolz,
cytoolz.functoolz, cytoolz.itertoolz, cytoolz.dicttoolz,
cytoolz.recipes]

blacklist = set()

def add_blacklist(mod, attr):
if hasattr(mod, attr):
blacklist.add(getattr(mod, attr))

add_blacklist(builtins, 'basestring')
add_blacklist(builtins, 'NoneType')
add_blacklist(builtins, '__metaclass__')
add_blacklist(builtins, 'sequenceiterator')
add_blacklist(builtins, 'breakpoint')

def is_missing(modname, name, func):
if name.startswith('_') and not name.startswith('__'):
return False
if name.startswith('__pyx_unpickle_') or name.endswith('_cython__'):
return False
try:
if issubclass(func, BaseException):
return False
except TypeError:
pass
try:
return (callable(func)
and func.__module__ is not None
and modname in func.__module__
and is_partial_args(func, (), {}) is not True
and func not in blacklist)
except AttributeError:
return False

missing = {}
for mod in mods:
modname = mod.__name__
for name, func in vars(mod).items():
if is_missing(modname, name, func):
if modname not in missing:
missing[modname] = []
missing[modname].append(name)
if missing:
messages = []
for modname, names in sorted(missing.items()):
msg = '{}:\n{}'.format(modname, '\n
'.join(sorted(names)))
messages.append(msg)
message = 'Missing introspection for the following callables:\n\n'
>   raise AssertionError(message + '\n\n'.join(messages))
E   AssertionError: Missing introspection for the following callables:
E
E   builtins:
E   anext

cytoolz/tests/test_inspect_args.py:434: AssertionError
=== warnings summary ===
cytoolz/compatibility.py:2

/<>/.pybuild/cpython3_3.10_cytoolz/build/cytoolz/compatibility.py:2:
DeprecationWarning: The toolz.compatibility module is no longer needed in Python
3 and has been deprecated. Please import these utilities directly from the
standard library. This module will be removed in a future release.
warnings.warn("The toolz.compatibility module is no longer "

.pybuild/cpython3_3.10_cytoolz/build/cytoolz/tests/test_itertoolz.py::test_random_sample
.pybuild/cpython3_3.10_cytoolz/build/cytoolz/tests/test_itertoolz.py::test_random_sample
.pybuild/cpython3_3.10_cytoolz/build/cytoolz/tests/test_itertoolz.py::test_random_sample
.pybuild/cpython3_3.10_cytoolz/build/cytoolz/tests/test_itertoolz.py::test_random_sample
  /usr/lib/python3.10/random.py:

Bug#999404: pyfuse3 ftbfs with Python 3.10 (test failures)

[Matthias Klose]

Source: pyfuse3
Version: 3.2.0-3
Severity: important
Tags: ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.10

pyfuse3 ftbfs with python3-defaults from experimental:

[...]
I: pybuild base:237: cd /<>/.pybuild/cpython3_3.10_pyfuse3/build;
python3.10 -m pytest --installed "/<>/test/"
= test session starts ==
platform linux -- Python 3.10.0+, pytest-6.2.5, py-1.10.0, pluggy-0.13.0 --
/usr/bin/python3.10
cachedir: .pytest_cache
rootdir: /<>/test, configfile: pytest.ini
collecting ... collected 17 items

../../../test/test_api.py::test_listdir PASSED   [  5%]
../../../test/test_api.py::test_sup_groups PASSED[ 11%]
../../../test/test_api.py::test_syncfs PASSED[ 17%]
../../../test/test_api.py::test_entry_res PASSED [ 23%]
../../../test/test_api.py::test_xattr PASSED [ 29%]
../../../test/test_api.py::test_copy PASSED  [ 35%]
../../../test/test_examples.py::test_hello[hello.py] Error in sys.excepthook:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/trio/_core/_multierror.py", line 435, in
trio_excepthook
for chunk in traceback.format_exception(etype, value, tb):
  File "/usr/lib/python3.10/traceback.py", line 135, in format_exception
te = TracebackException(type(value), value, tb, limit=limit, compact=True)
TypeError: traceback_exception_init() got an unexpected keyword argument 
'compact'

Original exception was:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/_pytest/main.py", line 269, in 
wrap_session
session.exitstatus = doit(config, session) or 0
  File "/usr/lib/python3/dist-packages/_pytest/main.py", line 323, in _main
config.hook.pytest_runtestloop(session=session)
  File "/usr/lib/python3/dist-packages/pluggy/hooks.py", line 286, in __call__
return self._hookexec(self, self.get_hookimpls(), kwargs)
  File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 92, in _hookexec
return self._inner_hookexec(hook, methods, kwargs)
  File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 83, in 
self._inner_hookexec = lambda hook, methods, kwargs: hook.multicall(
  File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 208, in 
_multicall
return outcome.get_result()
  File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 80, in 
get_result
raise ex[1].with_traceback(ex[2])
  File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 187, in 
_multicall
res = hook_impl.function(*args)
  File "/usr/lib/python3/dist-packages/_pytest/main.py", line 348, in
pytest_runtestloop
item.config.hook.pytest_runtest_protocol(item=item, nextitem=nextitem)
  File "/usr/lib/python3/dist-packages/pluggy/hooks.py", line 286, in __call__
return self._hookexec(self, self.get_hookimpls(), kwargs)
  File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 92, in _hookexec
return self._inner_hookexec(hook, methods, kwargs)
  File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 83, in 
self._inner_hookexec = lambda hook, methods, kwargs: hook.multicall(
  File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 208, in 
_multicall
return outcome.get_result()
  File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 80, in 
get_result
raise ex[1].with_traceback(ex[2])
  File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 187, in 
_multicall
res = hook_impl.function(*args)
  File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 109, in
pytest_runtest_protocol
runtestprotocol(item, nextitem=nextitem)
  File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 120, in
runtestprotocol
rep = call_and_report(item, "setup", log)
  File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 217, in
call_and_report
report: TestReport = hook.pytest_runtest_makereport(item=item, call=call)
  File "/usr/lib/python3/dist-packages/pluggy/hooks.py", line 286, in __call__
return self._hookexec(self, self.get_hookimpls(), kwargs)
  File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 92, in _hookexec
return self._inner_hookexec(hook, methods, kwargs)
  File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 83, in 
self._inner_hookexec = lambda hook, methods, kwargs: hook.multicall(
  File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 203, in 
_multicall
gen.send(outcome)
  File "/usr/lib/python3/dist-packages/_pytest/skipping.py", line 272, in
pytest_runtest_makereport
rep = outcome.get_result()
  File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 80, in 
get_result
raise ex[1].with_traceback(ex[2])
  File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 187, in 
_multicall
res = hook_impl.function(*args)
  File "/usr/lib/python3/dist-packages/_pytest/ru

Bug#999403: RM: golang-github-marten-seemann-qtls-go1-15 -- ROM; superseded by golang-github-marten-seemann-qtls-go1-17

[Shengjing Zhu]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: z...@debian.org

Please remove golang-github-marten-seemann-qtls-go1-15, it has been superseded
by golang-github-marten-seemann-qtls-go1-17

Bug#999402: pyasn ftbfs with Python 3.10 (test failures)

[Matthias Klose]

Source: pyasn
Version: 1.6.1-2
Severity: important
Tags: ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.10

pyasn ftbfs with python3-defaults from experimental:

[...]
I: pybuild base:237: cd /<>/.pybuild/cpython3_3.10_pyasn/build;
python3.10 -m nose -v tests
Checks compatibility of PyASN 1.2 results with current pyasn for all 2014 ipasn
dbs . ... SKIPPING - Python 2 or PyASN 1.2 not present ... ok
Failure: FileNotFoundError ([Errno 2] No such file or directory:
'/<>/.pybuild/cpython3_3.10_pyasn/build/tests/../data/ipasn_20140513.dat.gz')
... ERROR
Tests pyasn.mrtx.parse_mrt_file() - converts a full (TD1) RIB file, and compares
... SKIPPING - full dump doesn't exist.ok
Tests pyasn.mrtx.parse_mrt_file() - converts a full (TD2) RIB file, and compares
... SKIPPING - full dump doesn't exist.ok
Tests pyasn.mrtx.parse_mrt_file() - converts a full (TD2) RIB file with IPv6;
... SKIPPING - full dump doesn't exist.ok
Tests pyasn.mrtx internal classes by converting start of an RIB6 TD2 file (IPv6)
... ERROR
Tests pyasn.mrtx internal classes by converting start of an RIB TD1 file ... 
ERROR
Tests pyasn.mrtx internal classes by converting start of an RIB TD2 file ... 
ERROR
Tests pyasn.mrtx.parse_mrt_file() with repeated prefixes causing errros (bug
#39) ... SKIPPING - full dump doesn't exist.ok
Tests pyasn.mrtx.parse_mrt_file() with routeviews WIDE archive TD1 (bug #42) ...
SKIPPING - full dump doesn't exist.ok
Tests pyasn.mrtx.parse_mrt_file() with skip_record_on_error set to True ... 
ERROR
Tests pyasn.mrtx.parse_mrt_file() with skip_record_on_error set to
default(False); ... ERROR
Failure: FileNotFoundError ([Errno 2] No such file or directory:
'/<>/.pybuild/cpython3_3.10_pyasn/build/tests/../data/ipasn_20140513.dat.gz')
... ERROR

==
ERROR: Failure: FileNotFoundError ([Errno 2] No such file or directory:
'/<>/.pybuild/cpython3_3.10_pyasn/build/tests/../data/ipasn_20140513.dat.gz')
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/failure.py", line 39, in runTest
raise self.exc_val.with_traceback(self.tb)
  File "/usr/lib/python3/dist-packages/nose/loader.py", line 416, in
loadTestsFromName
module = self.importer.importFromPath(
  File "/usr/lib/python3/dist-packages/nose/importer.py", line 47, in 
importFromPath
return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python3/dist-packages/nose/importer.py", line 94, in 
importFromDir
mod = load_module(part_fqname, fh, filename, desc)
  File "/usr/lib/python3.10/imp.py", line 235, in load_module
return load_source(name, filename, file)
  File "/usr/lib/python3.10/imp.py", line 172, in load_source
module = _load(spec)
  File "", line 719, in _load
  File "", line 688, in _load_unlocked
  File "", line 883, in exec_module
  File "", line 241, in _call_with_frames_removed
  File
"/<>/.pybuild/cpython3_3.10_pyasn/build/tests/test_comparative.py",
line 39, in 
class TestCorrectness(TestCase):
  File
"/<>/.pybuild/cpython3_3.10_pyasn/build/tests/test_comparative.py",
line 40, in TestCorrectness
asndb = pyasn.pyasn(IPASN_DB_PATH)
  File "/<>/.pybuild/cpython3_3.10_pyasn/build/pyasn/__init__.py",
line 64, in __init__
f = gzip.open(ipasn_file, 'rt')  # Py2.6 doesn't support 'with' for gzip
  File "/usr/lib/python3.10/gzip.py", line 58, in open
binary_file = GzipFile(filename, gz_mode, compresslevel)
  File "/usr/lib/python3.10/gzip.py", line 174, in __init__
fileobj = self.myfileobj = builtins.open(filename, mode or 'rb')
FileNotFoundError: [Errno 2] No such file or directory:
'/<>/.pybuild/cpython3_3.10_pyasn/build/tests/../data/ipasn_20140513.dat.gz'

==
ERROR: Tests pyasn.mrtx internal classes by converting start of an RIB6 TD2 file
(IPv6)
--
Traceback (most recent call last):
  File "/<>/.pybuild/cpython3_3.10_pyasn/build/tests/test_mrtx.py",
line 309, in test_mrt6_table_dump_v2
f = BZ2File(RIB6_TD2_PARTDUMP, 'rb')
  File "/usr/lib/python3.10/bz2.py", line 81, in __init__
self._fp = _builtin_open(filename, mode)
FileNotFoundError: [Errno 2] No such file or directory:
'/<>/.pybuild/cpython3_3.10_pyasn/build/tests/../data/rib6.20151101.0600_firstMB.bz2'

==
ERROR: Tests pyasn.mrtx internal classes by converting start of an RIB TD1 file
--
Traceback (most recent call last):
  File "/<>/.pybuild/cpython3_3.10_pyasn/build/tests/test_mrtx.py",
line 135, in test_mrt_table_dump_v1
f = BZ2File(RIB_TD1_PARTDUMP, 'rb')
  File "/usr/lib/python3.10/bz2.py", line 81, in __init__
self._fp = _builtin_open(filename, mode)
FileNotFoundError: [Errno 2] No such file or directory:

Bug#999401: pocketsphinx-python ftbfs with Python 3.10 (test failures)

[Matthias Klose]

Source: pocketsphinx-python
Version: 1:0.1.15-2
Severity: important
Tags: ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.10

pocketsphinx-python ftbfs with python3-defaults from experimental. the
python3-sphinxbase module has also been built for 3.10.

[...]
I: pybuild base:237: python3.10 setup.py test
/<>/setup.py:7: DeprecationWarning: The distutils package is
deprecated and slated for removal in Python 3.12. Use setuptools or check PEP
632 for potential alternatives
  from distutils import log
running test
WARNING: Testing via this command is deprecated and will be removed in a future
version. Users looking for a generic test entry point independent of test runner
are encouraged to use tox.
running egg_info
writing pocketsphinx.egg-info/PKG-INFO
writing dependency_links to pocketsphinx.egg-info/dependency_links.txt
writing top-level names to pocketsphinx.egg-info/top_level.txt
reading manifest file 'pocketsphinx.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
warning: no files found matching '*.h' under directory 'deps/sphinxbase/include'
no previously-included directories found matching 
'deps/sphinxbase/include/wince'
warning: no files found matching '*.c' under directory
'deps/sphinxbase/src/libsphinxad'
warning: no files found matching '*.c' under directory
'deps/sphinxbase/src/libsphinxbase'
warning: no files found matching '*.h' under directory
'deps/sphinxbase/src/libsphinxbase'
warning: no files found matching '*.h' under directory 
'deps/pocketsphinx/include'
warning: no files found matching '*.c' under directory
'deps/pocketsphinx/src/libpocketsphinx'
warning: no files found matching '*.h' under directory
'deps/pocketsphinx/src/libpocketsphinx'
warning: no directories found matching 'pocketsphinx/model'
warning: no directories found matching 'pocketsphinx/data'
adding license file 'LICENSE'
writing manifest file 'pocketsphinx.egg-info/SOURCES.txt'
running build_ext
copying
/<>/.pybuild/cpython3_3.10_pocketsphinx/build/pocketsphinx/_pocketsphinx.cpython-310-x86_64-linux-gnu.so
-> pocketsphinx
test_audiofile (unittest.loader._FailedTest) ... ERROR
test_fsg (unittest.loader._FailedTest) ... ERROR
test_lattice (unittest.loader._FailedTest) ... ERROR
test_jsgf (unittest.loader._FailedTest) ... ERROR
test_phoneme (unittest.loader._FailedTest) ... ERROR
test_config (unittest.loader._FailedTest) ... ERROR
test_decoder (unittest.loader._FailedTest) ... ERROR
test_lm (unittest.loader._FailedTest) ... ERROR
test_kws (unittest.loader._FailedTest) ... ERROR

==
ERROR: test_audiofile (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: test_audiofile
Traceback (most recent call last):
  File "/usr/lib/python3.10/unittest/loader.py", line 154, in loadTestsFromName
module = __import__(module_name)
  File "/<>/tests/test_audiofile.py", line 32, in 
from pocketsphinx import AudioFile
  File "/<>/pocketsphinx/__init__.py", line 35, in 
from sphinxbase.sphinxbase import *
  File "/usr/lib/python3/dist-packages/sphinxbase/sphinxbase.py", line 27, in

from . import _sphinxbase
ImportError: cannot import name '_sphinxbase' from 'sphinxbase'
(/usr/lib/python3/dist-packages/sphinxbase/__init__.py)


==
ERROR: test_fsg (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: test_fsg
Traceback (most recent call last):
  File "/usr/lib/python3.10/unittest/loader.py", line 154, in loadTestsFromName
module = __import__(module_name)
  File "/<>/tests/test_fsg.py", line 32, in 
from pocketsphinx import LogMath, FsgModel
  File "/<>/pocketsphinx/__init__.py", line 35, in 
from sphinxbase.sphinxbase import *
  File "/usr/lib/python3/dist-packages/sphinxbase/sphinxbase.py", line 27, in

from . import _sphinxbase
ImportError: cannot import name '_sphinxbase' from 'sphinxbase'
(/usr/lib/python3/dist-packages/sphinxbase/__init__.py)


==
ERROR: test_lattice (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: test_lattice
Traceback (most recent call last):
  File "/usr/lib/python3.10/unittest/loader.py", line 154, in loadTestsFromName
module = __import__(module_name)
  File "/<>/tests/test_lattice.py", line 32, in 
from pocketsphinx import Pocketsphinx
  File "/<>/pocketsphinx/__init__.py", line 35, in 
from sphinxbase.sphinxbase import *
  File "/usr/lib/python3/dist-packages/sphinxbase/sphinxbase.py", line 27, in

from . import _sphinxbase
ImportError: cannot import name '_sphinxbase' from 'sphinxbase'
(/usr/lib/python3/dist-packages/sphinxbase/__init__.py)


=

Bug#998854: undefined symbol: _PyUnicode_DecodeUnicodeEscape

[Russ Allbery]

Control: reassign -1 python3-typed-ast
Control: severity -1 serious

Matthias Klose  writes:
> On 11/8/21 21:34, Russ Allbery wrote:

>> Python 3.9.8 breaks python3-typed-ast:
>> 
>> % python3 -c 'from typed_ast import _ast3'
>> Traceback (most recent call last):
>>   File "", line 1, in 
>> ImportError: 
>> /usr/lib/python3/dist-packages/typed_ast/_ast3.cpython-39-x86_64-linux-gnu.so:
>>  undefined symbol: _PyUnicode_DecodeUnicodeEscape
>> 
>> Downgrading to Python 3.9.7-4 fixes the problem.  This also happens with
>> typed-ast installed directly via pip in a virtualenv.
>> 
>> I'm not sure if this is a bug in Python or in typed-ast.  Starting here
>> under the assumption that patch releases should be backward-compatible
>> since this looks like a missing symbol problem in the libpython shared
>> library, but if typed-ast is doing something it shouldn't, perhaps this
>> should be reassigned.

> The symbol is marked as an internal symbol (starting with an underscore), so
> this should be a private symbol.  However typed-ast is using that directly in
> the code.  I would say the issue is more on the side of typed-ast.

> You already filed
> https://github.com/python/typed_ast/issues/169

> and
> https://github.com/python/typed_ast/issues/170
> talks about the end-of-live for that module.

Yup, agreed, reassigning.  My apologies, I should have come back and
reassigned this bug after I had dug further and figured out this bug
happened with generic upstream for both, and that typed-ast is deprecated.

python3-typed-ast rdepends are mypy (the current version no longer appears
to use it) and prospector.  black also used to use it but doesn't any more
(and there's no dependency there in Debian).

I suspect we should just drop typed-ast from the distribution during this
development cycle.

-- 
Russ Allbery (r...@debian.org)  

Bug#999400: cloud-init: Update cloud-init in stable for newer version of Azure IMDS

[Martin Zobel-Helas]

Package: cloud-init
Version: 20.4.1-2+deb11u1
Severity: normal

Dear cloud team,

i would like to propose an update of cloud-init in stable. Before i open
a bug report with the release team for that, i would like to have a
discussion within the cloud team that all of the cloud team see no real
harm happening here.

Azure provides a so call Azure Instance Metadata Service, which is only
reachable from within the running VM on Azure on the non-routable IP
address (169.254.169.254).

Due to an update on the Azure side, it would be helpful to support the
newer API version of IMDS within cloud-init, a patch, that didn't make
it to stable, as of the time the change was made, changes on cloud-init
weren't allowed in the Debian freeze process.

The proposed change can be found here: 
https://github.com/canonical/cloud-init/pull/884/, though the patch on 
Github will not apply cleanly directly on the version of cloud-init in 
stable. I would be willing to prepare a more clean patch for that.


I see a very low risk on adding this to cloud-init in stable, as we
already have that code in testing, and we could very easy probably get a
version 21.4-1 into backports.

Also this code only affects one cloud vendor and should not break stuff
on other cloud vendors platform. It only adds information for IMDS.

Would this be a patch we would agree to be carried through the full
release cycle of Debian 11?

Thanks for feedback,
Martin

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

Kernel: Linux 5.14.0-4-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)
LSM: AppArmor: enabled

Versions of packages cloud-init depends on:
ii  fdisk   2.37.2-4
ii  gdisk   1.0.8-3
ii  ifupdown0.8.36+nmu1
ii  locales 2.32-4
ii  lsb-base11.1.0
ii  lsb-release 11.1.0
ii  net-tools   1.60+git20181103.0eebece-1
ii  procps  2:3.3.17-5
ii  python3 3.9.7-1
ii  python3-configobj   5.0.6-5
ii  python3-jinja2  3.0.1-2
ii  python3-jsonpatch   1.32-2
ii  python3-jsonschema  3.2.0-3
ii  python3-netifaces   0.11.0-1
ii  python3-oauthlib3.1.1-1
ii  python3-requests2.25.1+dfsg-2
ii  python3-yaml5.4.1-1
ii  util-linux  2.37.2-4

Versions of packages cloud-init recommends:
ii  cloud-guest-utils  0.31-2
ii  eatmydata  130-2
ii  sudo   1.9.5p2-3

Versions of packages cloud-init suggests:
pn  btrfs-progs  
ii  e2fsprogs1.46.4-1
pn  xfsprogs 

-- no debconf information

--
Martin Zobel-Helas
Technical Lead Operations

E-Mail: martin.zobel-he...@credativ.de
pgp fingerprint: 6B18 5642 8E41 EC89 3D5D  BDBB 53B1 AC6D B11B 627B
http://www.credativ.de

credativ GmbH, HRB Mönchengladbach 12080
USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Geoff Richardson, Peter Lilley

Unser Umgang mit personenbezogenen Daten unterliegt
folgenden Bestimmungen: https://www.credativ.de/datenschutz

Bug#989462: synced dirs

[Hans-Christoph Steiner]

synced dirs are difficult to manage when the use case is security-sensitive.  In 
F-Droid production, they are only used during box creation.  Then production 
builds do not use them.  Also, some Android app builds are literally bigger than 
20GB, and running the build in the synced folder would be painfully slow.

Bug#999399: preseed: Mention the current Debian version name instead of lenny

[Roland Clobus]

Source: preseed
Version: 1.109
Severity: minor

Hello maintainers of the preseed package,

While testing Debian live images based on live-build, I noticed that the
description that provides examples for the preseeding file still mentions
lenny.

See https://sources.debian.org/src/preseed/1.109/debian/network-
preseed.templates/?hl=20#L20

Could this be replaced by either 'stable' or the current version name?
(If you choose the latter, would it then also need to be mentioned in the
'howto prepare the next Debian release' document?)

With kind regards,
Roland Clobus


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

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