Bug#1000306: partitionmanager: Unable to change the luks passphrase

[Bob Wong]

Package: partitionmanager
Version: 21.08.0-1
Severity: wishlist
X-Debbugs-Cc: ybx...@gmail.com

Dear Maintainer,

  The genome disk manager could change the passphrase of the luks partition.
But the partitionmanager is unable to change the passphrase without formatting
the whole partition.


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

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

Versions of packages partitionmanager depends on:
ii  kio   5.86.0-1
ii  libc6 2.32-4
ii  libkf5configcore5 5.86.0-1
ii  libkf5configgui5  5.86.0-1
ii  libkf5configwidgets5  5.86.0-1
ii  libkf5coreaddons5 5.86.0-1
ii  libkf5crash5  5.86.0-1
ii  libkf5dbusaddons5 5.86.0-1
ii  libkf5i18n5   5.86.0-1
ii  libkf5jobwidgets5 5.86.0-1
ii  libkf5kiocore55.86.0-1
ii  libkf5kiogui5 5.86.0-1
ii  libkf5widgetsaddons5  5.86.0-1
ii  libkf5xmlgui5 5.86.0-1
ii  libkpmcore11  21.08.0-1
ii  libqt5core5a  5.15.2+dfsg-13
ii  libqt5gui55.15.2+dfsg-13
ii  libqt5widgets55.15.2+dfsg-13
ii  libstdc++611.2.0-10

partitionmanager recommends no packages.

Versions of packages partitionmanager suggests:
pn  btrfs-progs
ii  dosfstools 4.2-1
pn  hfsplus
pn  hfsutils   
pn  jfsutils   
ii  ntfs-3g1:2021.8.22-3
pn  reiser4progs   
pn  reiserfsprogs  
pn  xfsprogs   

-- no debconf information

Bug#1000305: lsp-plugins FTCBFS: uses the build architecture ld and pkg-config

[Helmut Grohne]

Source: lsp-plugins
Version: 1.1.30-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

lsp-plugins fails to cross build from source, becaue it uses the build
architecture ld and pkg-config. For ld, dh_auto_build does not pass a
cross tool as the use of LD variable is inconsistent across upstream
projects. pkg-config instead is hard coded in the upstream build system.
The attached patch addresses both, but it does not make lsp-plugins
cross buildable, because lsp-plugins builds some build tools and fails
running them with an Exec format error (e.g. gen_resources.exe or
gen_php.exe). I suppose more thought is required for fixing these.
Please consider applying my patch as an incremental improvement and
close this bug when doing so.

Helmut
diff --minimal -Nru lsp-plugins-1.1.30/debian/changelog 
lsp-plugins-1.1.30/debian/changelog
--- lsp-plugins-1.1.30/debian/changelog 2021-08-19 12:50:50.0 +0200
+++ lsp-plugins-1.1.30/debian/changelog 2021-11-20 12:54:14.0 +0100
@@ -1,3 +1,10 @@
+lsp-plugins (1.1.30-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Improve cross building: Use the host arch ld and pkg-config. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 20 Nov 2021 12:54:14 +0100
+
 lsp-plugins (1.1.30-1) unstable; urgency=medium
 
   * Provide the lsp-plugins-r3d-glx package,
diff --minimal -Nru lsp-plugins-1.1.30/debian/patches/cross.patch 
lsp-plugins-1.1.30/debian/patches/cross.patch
--- lsp-plugins-1.1.30/debian/patches/cross.patch   1970-01-01 
01:00:00.0 +0100
+++ lsp-plugins-1.1.30/debian/patches/cross.patch   2021-11-20 
12:54:14.0 +0100
@@ -0,0 +1,58 @@
+--- lsp-plugins-1.1.30.orig/scripts/make/configure.mk
 lsp-plugins-1.1.30/scripts/make/configure.mk
+@@ -131,17 +131,17 @@
+   export ICONV_LIBS   = -liconv
+   export MATH_LIBS= -lm
+   export DL_LIBS  = -ldl
+-  export CAIRO_HEADERS= $(shell pkg-config --cflags cairo)
+-  export CAIRO_LIBS   = $(shell pkg-config --libs cairo)
+-  export XLIB_HEADERS = $(shell pkg-config --cflags x11)
+-  export XLIB_LIBS= $(shell pkg-config --libs x11)
+-  export LV2_HEADERS  = $(shell pkg-config --cflags lv2)
+-  export LV2_LIBS = $(shell pkg-config --libs lv2)
+-  export SNDFILE_HEADERS  = $(shell pkg-config --cflags sndfile)
+-  export SNDFILE_LIBS = $(shell pkg-config --libs sndfile)
+-  export JACK_HEADERS = $(shell pkg-config --cflags jack)
+-  export JACK_LIBS= $(shell pkg-config --libs jack)
+-  export OPENGL_HEADERS   = $(shell pkg-config --cflags gl 2>/dev/null || 
echo "")
+-  export OPENGL_LIBS  = $(shell pkg-config --libs gl 2>/dev/null || echo 
"")
++  export CAIRO_HEADERS= $(shell $(PKG_CONFIG) --cflags cairo)
++  export CAIRO_LIBS   = $(shell $(PKG_CONFIG) --libs cairo)
++  export XLIB_HEADERS = $(shell $(PKG_CONFIG) --cflags x11)
++  export XLIB_LIBS= $(shell $(PKG_CONFIG) --libs x11)
++  export LV2_HEADERS  = $(shell $(PKG_CONFIG) --cflags lv2)
++  export LV2_LIBS = $(shell $(PKG_CONFIG) --libs lv2)
++  export SNDFILE_HEADERS  = $(shell $(PKG_CONFIG) --cflags sndfile)
++  export SNDFILE_LIBS = $(shell $(PKG_CONFIG) --libs sndfile)
++  export JACK_HEADERS = $(shell $(PKG_CONFIG) --cflags jack)
++  export JACK_LIBS= $(shell $(PKG_CONFIG) --libs jack)
++  export OPENGL_HEADERS   = $(shell $(PKG_CONFIG) --cflags gl 2>/dev/null || 
echo "")
++  export OPENGL_LIBS  = $(shell $(PKG_CONFIG) --libs gl 2>/dev/null || 
echo "")
+ endif
+ 
+--- lsp-plugins-1.1.30.orig/scripts/make/tools.mk
 lsp-plugins-1.1.30/scripts/make/tools.mk
+@@ -3,6 +3,7 @@
+ TOOL_CC = gcc
+ TOOL_CXX= g++
+ TOOL_PHP= php
++TOOL_PKG_CONFIG = pkg-config
+ 
+ # Setup preferred flags
+ FLAG_RELRO  = -Wl,-z,relro,-z,now
+@@ -24,6 +25,7 @@
+ CXX  ?= $(TOOL_CXX)
+ PHP  ?= $(TOOL_PHP)
+ LD   ?= $(TOOL_LD)
++PKG_CONFIG   ?= $(TOOL_PKG_CONFIG)
+ 
+ MAKE_OPTS = -s
+ CFLAGS   += $(CC_ARCH) $(FLAG_CTUNE) $(CC_FLAGS) 
$(FLAG_VERSION)
+@@ -61,6 +63,7 @@
+ export CXX
+ export PHP
+ export LD
++export PKG_CONFIG
+ 
+ export MAKE_OPTS
+ export CFLAGS
diff --minimal -Nru lsp-plugins-1.1.30/debian/patches/series 
lsp-plugins-1.1.30/debian/patches/series
--- lsp-plugins-1.1.30/debian/patches/series1970-01-01 01:00:00.0 
+0100
+++ lsp-plugins-1.1.30/debian/patches/series2021-11-20 12:52:02.0 
+0100
@@ -0,0 +1 @@
+cross.patch
diff --minimal -Nru lsp-plugins-1.1.30/debian/rules 
lsp-plugins-1.1.30/debian/rules
--- lsp-plugins-1.1.30/debian/rules 2021-08-18 23:41:28.0 +0200
+++ lsp-plugins-1.1.30/debian/rules 2021-11-20 12:54:12.0 +0100
@@ -3,6 +3,7 @@
 export PREFIX=/usr
 
 include /usr/share/dpkg/architecture.mk
+-include /usr/share/dpkg/buildtools.mk
 ifeq ($(DEB_HOST_ARCH),amd64)

Bug#1000304: log rotation breaks silently on sysvinit based systems

[Joerg Dorchain]

Package: rsyslog
Version: 8.2110.0-3

Hello,

the file /usr/lib/rsyslog/rsyslog-rotate, referenced in the postrotate section 
of
/etc/logrotate.d/rsyslog, silently does nothing anymore on sysvinit based 
systems.

Non-rotated logs lead to disk full, data loss and unusable systems.

A grave functionality drop like this needs to be announced, e.g. in a 
NEWS.Debian file.

A word of reasoning why sysvinit support cannot be supported anymore would also 
help.

Best regards,

Joerg


signature.asc
Description: PGP signature

Bug#1000303: liboqs: not yet ready for testing or stable

[Andrius Merkys]

Source: liboqs
Severity: serious

The upstream wishes to keep the package out of stable distributions for
now, until the NIST Post-Quantum Cryptography standardization project
reaches its conclusion. For the time being the package may be used for
prototyping and evaluation in unstable.

Andrius

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

[tito]

On Sun, 21 Nov 2021 02:09:55 +0100
Axel Beckert  wrote:

> Hi,
> 
> On Wed, Nov 10, 2021 at 05:48:38PM +, Matthew Vernon wrote:
> > 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!
> 
> Seems to have worked for me, but now I get the same error for 
> /etc/init.d/nftables:
> 
> Setting up orphan-sysvinit-scripts (0.10) ...
> /usr/bin/which: this version of `which' is deprecated; use `command -v' in 
> scripts instead.
> /usr/bin/which: this version of `which' is deprecated; use `command -v' in 
> scripts instead.
> Not replacing deleted config file /etc/init.d/nftables
> update-rc.d: error: initscript does not exist: /etc/init.d/nftables
> dpkg: error processing package orphan-sysvinit-scripts (--configure):
>  installed orphan-sysvinit-scripts package post-installation script 
> subprocess returned error exit status 1
> 
> Shall I open a new bug or is this considered the same issue?
> 
> Hmm, after reading the changelog entry for this fix:
> 
>   * Check for scripts still owned by another package (Closes: #998893)
> 
> This sounds like a quite generic fix.
> 
> > > 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
> 
> So I tried this for nftables as well, but it seems to have made things
> worse:
> 
> # ln -s /usr/share/orphan-sysvinit-scripts/nftables /etc/init.d/nftables
> # dpkg --pending --configure
> Setting up orphan-sysvinit-scripts (0.10) ...
> /usr/bin/which: this version of `which' is deprecated; use `command -v' in 
> scripts instead.
> /usr/bin/which: this version of `which' is deprecated; use `command -v' in 
> scripts instead.
> cp: '/usr/share/orphan-sysvinit-scripts/nftables' and 
> '/usr/share/orphan-sysvinit-scripts/nftables' are the same file
> dpkg: error processing package orphan-sysvinit-scripts (--configure):
>  installed orphan-sysvinit-scripts package post-installation script 
> subprocess returned error exit status 1
> Errors were encountered while processing:
>  orphan-sysvinit-scripts
> 
> Any adivce here?
> 
>   Regards, Axel

Hi,
couldn't renaming the scripts in the orphan-sysvinit-scripts package be a 
solution to solve this?
E.g from nftables to nftables-sv or nftables.sh or nftables-s5i or 
nftables-orphan.
Just my 0,2 cents.
Ciao,
Tito

Bug#999415: transition: pandas 1.1 -> 1.3

[Graham Inggs]

It might be easier to upgrade to 1.2.4 first, then 1,3,x later.

Bug#1000300: RM: imediff2 -- ROM; package migration to imediff done in buster

[Osamu Aoki]

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

As mentioned in https://bugs.debian.org/911678 , please remove this
package since package transition is completed in buster.

Regards,

Osamu

Bug#999538: pytables: diff for NMU version 3.6.1-5.1

[Stefano Rivera]

Control: tags 999538 + patch
Control: tags 999538 + pending

Dear maintainer,

I've prepared an NMU for pytables (versioned as 3.6.1-5.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Also available as an MR: 
https://salsa.debian.org/science-team/pytables/-/merge_requests/1

Regards,

SR
diff -Nru pytables-3.6.1/debian/changelog pytables-3.6.1/debian/changelog
--- pytables-3.6.1/debian/changelog	2021-09-28 02:05:13.0 -0400
+++ pytables-3.6.1/debian/changelog	2021-11-20 23:32:58.0 -0400
@@ -1,3 +1,12 @@
+pytables (3.6.1-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Patch: Fix FTBFS with numpy >= 1.20 (Closes: #999538)
+  * Patch: Fix FTBFS with Python 3.10.
+  * Install Python 3.10 C Extensions (2-digit minor version).
+
+ -- Stefano Rivera   Sat, 20 Nov 2021 23:32:58 -0400
+
 pytables (3.6.1-5) unstable; urgency=medium
 
   * debian/control:
diff -Nru pytables-3.6.1/debian/patches/0010-Use-lowercase-float-int-as-numpy-dtype.patch pytables-3.6.1/debian/patches/0010-Use-lowercase-float-int-as-numpy-dtype.patch
--- pytables-3.6.1/debian/patches/0010-Use-lowercase-float-int-as-numpy-dtype.patch	1969-12-31 20:00:00.0 -0400
+++ pytables-3.6.1/debian/patches/0010-Use-lowercase-float-int-as-numpy-dtype.patch	2021-11-20 23:32:58.0 -0400
@@ -0,0 +1,176 @@
+From: =?utf-8?q?Zbigniew_J=C4=99drzejewski-Szmek?= 
+Date: Sun, 24 Jan 2021 16:36:21 +0100
+Subject: Use lowercase float/int as numpy dtype
+
+Float64 is gone with numpy 1.20, which causes doctests to fail
+(https://bugzilla.redhat.com/show_bug.cgi?id=1914335).
+
+Similarly all uses of Float32, Int32 should be replaced by float32 and int32.
+
+>>> numpy.__version__
+'1.19.4'
+>>> [k for k in numpy.sctypeDict.keys() if str(k).lower().startswith('float')]
+['float16', 'Float16', 'float32', 'Float32', 'float64', 'Float64', 'float128', 'Float128', 'float_', 'float']
+
+>>> numpy.__version__
+'1.20.0rc2'
+>>> [k for k in numpy.sctypeDict.keys() if str(k).lower().startswith('float')]
+['float16', 'float32', 'float64', 'float128', 'float_', 'float']
+
+Bug-Upstream: https://github.com/PyTables/PyTables/issues/875
+Bug-Debian: https://bugs.debian.org/999538
+Origin: upstream, https://github.com/PyTables/PyTables/pull/862
+---
+ bench/bsddb-table-bench.py | 10 +-
+ bench/postgres-search-bench.py |  4 ++--
+ bench/pytables-search-bench.py |  6 +++---
+ bench/recarray2-test.py|  2 +-
+ bench/shelve-bench.py  | 10 +-
+ bench/sqlite-search-bench.py   |  4 ++--
+ tables/atom.py |  2 +-
+ 7 files changed, 19 insertions(+), 19 deletions(-)
+
+diff --git a/bench/bsddb-table-bench.py b/bench/bsddb-table-bench.py
+index dd9f875..a2e0236 100644
+--- a/bench/bsddb-table-bench.py
 b/bench/bsddb-table-bench.py
+@@ -83,11 +83,11 @@ def createFile(filename, totalrows, recsize, verbose):
+ # Get the record object associated with the new table
+ if recsize == "big":
+ isrec = Big()
+-arr = np.array(np.arange(32), type=np.Float64)
+-arr2 = np.array(np.arange(32), type=np.Float64)
++arr = np.array(np.arange(32), type=np.float64)
++arr2 = np.array(np.arange(32), type=np.float64)
+ elif recsize == "medium":
+ isrec = Medium()
+-arr = np.array(np.arange(2), type=np.Float64)
++arr = np.array(np.arange(2), type=np.float64)
+ else:
+ isrec = Small()
+ # print d
+@@ -107,8 +107,8 @@ def createFile(filename, totalrows, recsize, verbose):
+ #d['TDCcount'] = i % 256
+ d['ADCcount'] = (i * 256) % (1 << 16)
+ if recsize == "big":
+-#d.float1 = np.array([i]*32, np.Float64)
+-#d.float2 = np.array([i**2]*32, np.Float64)
++#d.float1 = np.array([i]*32, np.float64)
++#d.float2 = np.array([i**2]*32, np.float64)
+ arr[0] = 1.1
+ d['float1'] = arr
+ arr2[0] = 2.2
+diff --git a/bench/postgres-search-bench.py b/bench/postgres-search-bench.py
+index d2c9f4f..7fe83f6 100644
+--- a/bench/postgres-search-bench.py
 b/bench/postgres-search-bench.py
+@@ -15,11 +15,11 @@ def flatten(l):
+ 
+ 
+ def fill_arrays(start, stop):
+-col_i = numpy.arange(start, stop, type=numpy.Int32)
++col_i = numpy.arange(start, stop, type=numpy.int32)
+ if userandom:
+ col_j = numpy.random.uniform(0, nrows, size=[stop - start])
+ else:
+-col_j = numpy.array(col_i, type=numpy.Float64)
++col_j = numpy.array(col_i, type=numpy.float64)
+ return col_i, col_j
+ 
+ # Generator for ensure pytables benchmark compatibility
+diff --git a/bench/pytables-search-bench.py b/bench/pytables-search-bench.py
+index 726d30b..6417186 100644
+--- a/bench/pytables-search-bench.py
 b/bench/pytables-search-bench.py
+@@ -37,11 +37,11 @@ def create_db(filename, nrows):
+ stop = (j + 1) * step
+ if stop > nrows:
+ 

Bug#990316: Make IME support enabled by default in kitty

[Osamu Aoki]

Hi,

Here is my thought on my practical and non-invasive solution.

On Sat, 2021-11-20 at 23:12 +0100, Gunnar Hjalmarsson wrote:
> On 2021-11-20 21:53, James McCoy wrote:
> > On Sat, Nov 20, 2021 at 11:37:14PM +0900, Osamu Aoki wrote:
> > > If I understand correctly, upstream chose to disable ibus feature
> > > if GLFW_IM_MODULE is not set to ibus.  So ibus is opt-in feature.
> > > Reverting that feature choice is one option for Debian maintainer
> > > can do indeed.  This is a risky path most maintainers hesitate.
> > 
> > Yeah, this isn't something I would patch.
> 
> Fair enough. And given that, it would not be appropriate to bypass the 
> restrain in Debian via im-config.
> 
> > > Since kitty has kitty.conf, a non-confrontational approach may be a
> > > patch to add one configuration option in kitty.conf to enable ibus.
> > > So ibus support is still opt-in feature.
> > 
> > That sounds like a reasonable approach, if someone would like to
> > propose a patch/PR to Kovid.  I'm not familiar with IME topics, so I
> > don't think I would be in a good position to advocate for that.
> 
> Seems like that has already been proposed and turned down:
> 
> https://github.com/kovidgoyal/kitty/issues/3206
> 
> So maybe users who want IME support in kitty need to get used to set 
> that environment variable.

I guess the kitty upstream's negative impression on ibus/fcitx5 for dropped key
inputs comes from the well known ibus/fcitx5 daemon related problem using xim 
as the
communication protocol and probably not applicable if dbus is used to call 
ibus/fcitx
library.  The upstream's latency concern with dbus may be negligible compared 
to how
fast we can type but it is true that adding any complication slows things.

So we better not to touch kitty code.

But kitty terminal displaying CJK-characters with millions of complicated 
shapes may
be the one benefit most by using GPU.  So we as a distribution should offer easy
access to this feature at least as an opt-in feature.

Considering kitty is the only user of GLFW_IM_MODULE variable on Debian and it
shouldn't be turned on by default according to the upstream, I propose to add
following content as README.Debian in the Debian package of kitty.

--
# Input Method support

You can enable input of non-Latin characters to the kitty terminal as follows:

1. Install required a set of input method program based on ibus or fcitx5
2. Place the following file named "kitty" in PATH
   (e.g., ~/.local/bin or /usr/local/bin)
3. Meke "kitty" script an executable. (`chmod 755 kitty`)
  
---
#!/bin/sh -e

GLFW_IM_MODULE=ibus exec /usr/bin/kitty "$@" 
---

fcitx5 uses the same communication protocol as ibus.  So you use "ibus" even for
"fcitx5".  Other input method infrastructure such as "fcitx" and "uim" are not
supported.
--

For im-config, I think it is about time to kill upstream non-supported known 
broken
xim support by dropping to start daemon from im-config which sets how Debian 
behaves
as installed.  xterm and rxvt may loose CJK input but we will get less bug 
report on
ill-configured modern GTK/Qt apps using xim. 

Bug#1000299: Accepted nspr 2:4.32-2 (source) into unstable

[Rene Engelhard]

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

Hi,

Am 21.11.21 um 00:04 schrieb Debian FTP Masters:
>  nspr (2:4.32-2) unstable; urgency=medium
>  .
>    * debian/libnspr4-dev.links.in, debian/control: Remove
> xulrunner-nspr.pc,
>  which breaks libxmlsec1-dev (<= 1.2.33-1).
> [...]

Again no coordination whatsoever but at least he added a Breaks: from
the beginning...

(see also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998339).


This makes any package using xmlsec1-nss.pc FTBFS. (admittedly that is
just libreoffice.)


This time there's no handy upstream release to be updated so there
should be a bin-NMU.


So please


nmu xmlsec1_1.2.32-1 . ANY . unstable . -m "rebuild against nspr
2:4.32-2 to fix xmlsec1-nss.pc"

dw  xmlsec1_1.2.32-1 . mips mipsel . -m 'libnspr4-dev (>= 2:4.32-2)'

(and some debian-ports arch, does ANY work?)


Regards,


Rene

Bug#1000298: openjdk-11-jre-headless: network operations not working because of ipv6

[Richard Z]

Package: openjdk-11-jre-headless
Version: 11.0.13+8-1~deb11u1
Severity: important
X-Debbugs-Cc: r...@linux-m68k.org

Dear Maintainer,


one way to reporduce on my system is to launch "josm" or other software that
uses
network. Josm will start but all network operation fails on my system.

Using strace I noticed that the program hangs when connecting to ipv6 adresses.
For some reason ipv6 does not seem to work here (telneting the ipv6 adresss
fails as well)) but no
other program that I tried had any problem in daily operation.

Easy workaround is
export _JAVA_OPTIONS=-Djava.net.preferIPv4Stack=true



Richard

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

Kernel: Linux 5.10.0-9-amd64 (SMP w/2 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

Versions of packages openjdk-11-jre-headless depends on:
ii  ca-certificates-java  20190909
ii  java-common   0.72
ii  libasound21.2.4-1.1
ii  libc6 2.31-13+deb11u2
ii  libcups2  2.3.3op2-3+deb11u1
ii  libfontconfig12.13.1-4.2
ii  libfreetype6  2.10.4+dfsg-1
ii  libgcc-s1 10.2.1-6
ii  libharfbuzz0b 2.7.4-1
ii  libjpeg62-turbo   1:2.0.6-4
ii  liblcms2-22.12~rc1-2
ii  libnss3   2:3.61-1
ii  libpcsclite1  1.9.1-1
ii  libstdc++610.2.1-6
ii  util-linux2.36.1-8
ii  zlib1g1:1.2.11.dfsg-2

openjdk-11-jre-headless recommends no packages.

Versions of packages openjdk-11-jre-headless suggests:
ii  fonts-dejavu-extra 2.37-2
pn  fonts-indic
pn  fonts-ipafont-gothic   
pn  fonts-ipafont-mincho   
pn  fonts-wqy-microhei | fonts-wqy-zenhei  
ii  libnss-mdns0.14.1-2

Bug#1000297: ITP: node-jose -- JOSE library without dependencies

[Nicolas Mora]

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

* Package name: node-jose
  Version : 4.3.7
  Upstream Author : Filip Skokan 
* URL : https://github.com/panva/jose
* License : Expat
  Programming Lang: JavaScript
  Description : JOSE library without dependencies

 "JSON Web Almost Everything" - JWA, JWS, JWE, JWT, JWK, JWKS with no
 dependencies using runtime's native crypto in Node.js, Browser,
 Cloudflare Workers, Electron, and Deno.
 .
 The following specifications are implemented by jose
  - JSON Web Signature (JWS) - RFC7515
  - JSON Web Encryption (JWE) - RFC7516
  - JSON Web Key (JWK) - RFC7517
  - JSON Web Algorithms (JWA) - RFC7518
  - JSON Web Token (JWT) - RFC7519
  - JSON Web Key Thumbprint - RFC7638
  - JWS Unencoded Payload Option - RFC7797
  - CFRG Elliptic Curve ECDH and Signatures - RFC8037
  - secp256k1 EC Key curve support - JOSE Registrations for WebAuthn 
Algorithms

 .
 Node.js is an event-based server-side JavaScript engine.

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

[Axel Beckert]

Hi,

On Wed, Nov 10, 2021 at 05:48:38PM +, Matthew Vernon wrote:
> 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!

Seems to have worked for me, but now I get the same error for 
/etc/init.d/nftables:

Setting up orphan-sysvinit-scripts (0.10) ...
/usr/bin/which: this version of `which' is deprecated; use `command -v' in 
scripts instead.
/usr/bin/which: this version of `which' is deprecated; use `command -v' in 
scripts instead.
Not replacing deleted config file /etc/init.d/nftables
update-rc.d: error: initscript does not exist: /etc/init.d/nftables
dpkg: error processing package orphan-sysvinit-scripts (--configure):
 installed orphan-sysvinit-scripts package post-installation script subprocess 
returned error exit status 1

Shall I open a new bug or is this considered the same issue?

Hmm, after reading the changelog entry for this fix:

  * Check for scripts still owned by another package (Closes: #998893)

This sounds like a quite generic fix.

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

So I tried this for nftables as well, but it seems to have made things
worse:

# ln -s /usr/share/orphan-sysvinit-scripts/nftables /etc/init.d/nftables
# dpkg --pending --configure
Setting up orphan-sysvinit-scripts (0.10) ...
/usr/bin/which: this version of `which' is deprecated; use `command -v' in 
scripts instead.
/usr/bin/which: this version of `which' is deprecated; use `command -v' in 
scripts instead.
cp: '/usr/share/orphan-sysvinit-scripts/nftables' and 
'/usr/share/orphan-sysvinit-scripts/nftables' are the same file
dpkg: error processing package orphan-sysvinit-scripts (--configure):
 installed orphan-sysvinit-scripts package post-installation script subprocess 
returned error exit status 1
Errors were encountered while processing:
 orphan-sysvinit-scripts

Any adivce here?

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1000295: ITP: odpi -- ODPI-C: Oracle Database Programming Interface for Drivers and Applications

[Joseph Nahmias]

Package: wnpp
Severity: wishlist
Owner: Joseph Nahmias 
X-Debbugs-Cc: debian-de...@lists.debian.org, j...@nahmias.net

* Package name: odpi
  Version : 4.3.0
  Upstream Author : Oracle
* URL : https://github.com/oracle/odpi
* License : Apache
  Programming Lang: C
  Description : ODPI-C: Oracle Database Programming Interface for Drivers 
and Applications

 Oracle Database Programming Interface for C (ODPI-C) is an open source
 library of C code that simplifies access to Oracle Database for applications
 written in C or C++. It is a wrapper over Oracle Call Interface (OCI) that
 makes applications and language interfaces easier to develop.
 .
 ODPI-C supports basic and advanced features of Oracle Database and Oracle
 Client. See the homepage for a list.

Note: this package will go into the contrib archive section as it requires
the non-free Oracle client.

Bug#1000294: ITP: golang-github-juju-simplekv -- Naive key-value store with multiple backends

[Mathias Gibbens]

Package: wnpp
Severity: wishlist
Owner: Mathias Gibbens 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-juju-simplekv
  Version : 1.1.0-1
  Upstream Author : Canonical Ltd
* URL : https://github.com/juju/simplekv
* License : LGPL-3.0-with-exception
  Programming Lang: Go
  Description : Naive key-value store with multiple backends

 Simple key-value store with multiple backends.
 .
 This library provides a naive key-value store with Postgres, MongoDB
 and in-memory backend implementations.

This is a dependency for packaging golang-github-canonical-candid (ITP
#998752), and will be team-maintained within the Debian Go Packaging
Team.


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

Bug#999565: transition: fluidsynth

[Dennis Braun]

OK, these errors of buzztrax and libtritonus-java were caused by older 
versions, because i used git and the salsa repos were not up to date.


i tested the NMUs and the 5 others, and all build fine. So the 
transition looks very good :-)

Bug#1000293: Problems starting jackd: Method RequestRelease is not implemented on interface org.freedesktop.ReserveDevice1

[Arnaldo Pirrone]

Package: jackd2
Version: 1.9.19~dfsg-2
Severity: grave
X-Debbugs-Cc: it9...@gmail.com

Apparently there is something wrong with Jack and dbus.
Also reported here:
https://www.reddit.com/r/linuxaudio/comments/qtmynn/problems_starting_jackd_method_requestrelease_is/
Find below the jack server logs.

00:41:32.228 Resetta le statistiche.
00:41:32.269 Connessioni di ALSA cambiate.
00:41:32.389 D-BUS: Servizio disponibile (org.jackaudio.service aka jackdbus).
Cannot connect to server socket err = File o directory non esistente
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping
unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping
unlock
00:41:32.563 Cambiamento nel grafico delle connessioni di ALSA.
00:41:47.432 D-BUS: il server JACK non può essere avviato. Mi dispiace
Sun Nov 21 00:41:47 2021: Starting jack server...
Sun Nov 21 00:41:47 2021: JACK server starting in realtime mode with priority
10
Sun Nov 21 00:41:47 2021: self-connect-mode is "Don't restrict self connect
requests"
Cannot connect to server socket err = File o directory non esistente
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping
unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping
unlock
Sun Nov 21 00:41:47 2021: Device reservation request with priority 2147483647
denied for "Audio1": org.freedesktop.DBus.Error.UnknownMethod (Method
RequestRelease is not implemented on interface org.freedesktop.ReserveDevice1)
Sun Nov 21 00:41:47 2021: ERROR: Failed to acquire device name : Audio1 error :
Method RequestRelease is not implemented on interface
org.freedesktop.ReserveDevice1
Sun Nov 21 00:41:47 2021: ERROR: Audio device hw:PCH,0 cannot be acquired...
Sun Nov 21 00:41:47 2021: ERROR: Cannot initialize driver
Sun Nov 21 00:41:47 2021: ERROR: JackServer::Open failed with -1
Sun Nov 21 00:41:47 2021: ERROR: Failed to open server
Sun Nov 21 00:41:48 2021: Saving settings to
"/home/it9exm/.config/jack/conf.xml" ...
00:41:49.469 Non sono riuscito ad avviare JACK come client. - Operazione
fallita. - Impossibile connettersi al server JACK. Controlla la finestra dei
messaggi per maggiori informazioni.
Cannot connect to server socket err = File o directory non esistente
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping
unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping
unlock


-- 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.19-xanmod1 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 jackd2 depends on:
ii  debconf [debconf-2.0]  1.5.79
ii  libasound2 1.2.5.1-1
ii  libc6  2.32-4
ii  libdbus-1-31.12.20-3
ii  libexpat1  2.4.1-3
ii  libgcc-s1  11.2.0-10
ii  libjack-jackd2-0   1.9.19~dfsg-2
ii  libreadline8   8.1-2
ii  libsamplerate0 0.2.2-1
ii  libsndfile11.0.31-2
ii  libstdc++6 11.2.0-10
ii  libsystemd0249.6-2
ii  libzita-alsa-pcmi0 0.3.2-2
ii  libzita-resampler1 1.8.0-2
ii  python33.9.8-1
ii  python3-dbus   1.2.18-3

Versions of packages jackd2 recommends:
ii  jackd2-firewire  1.9.19~dfsg-2
ii  libpam-modules   1.4.0-10
ii  qjackctl 0.9.5-1

Versions of packages jackd2 suggests:
pn  jack-tools   
pn  meterbridge  

-- debconf information:
* jackd/tweak_rt_limits: true

Bug#996780: gnome-boxes: Systematic system freeze few seconds after launching a Windows WM

[Gunnar Hjalmarsson]

Are you possibly using a NVIDIA driver? Asking because of this:

https://github.com/NVIDIA/egl-wayland/issues/27#issuecomment-951725683

--
Cheers,
Gunnar Hjalmarsson

Bug#998108: reopening 998108

[Christoph Anton Mitterer]

On Sat, 2021-11-20 at 15:30 -0800, Josh Triplett wrote:
> I'm still experiencing this bug regularly, with complete browser UI
> freezes that require killing and restarting Firefox.

Hm perhaps something else? At least I haven't suffered from that
particular issue since 94.0-2.


Cheers,
Chris.

Bug#998108: reopening 998108

[Josh Triplett]

reopen 998108 94.0-2
thanks

I'm still experiencing this bug regularly, with complete browser UI
freezes that require killing and restarting Firefox.

WebGL or video seems to trigger it more often, as does opening a new
tab. Browsing on an existing tab doesn't tend to trigger it.

Bug#1000292: pyhst2: FTBFS against Python 3.10

[Andreas Beckmann]

Source: pyhst2
Version: 2020c-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Hi,

2020c-3 FTBFS since Python 3.10 got added as a supported version:

[
creating build
creating build/temp.linux-x86_64-3.10
creating build/temp.linux-x86_64-3.10/PyHST
creating build/temp.linux-x86_64-3.10/PyHST/Cspace
compile options: '-I/usr/include 
-I/usr/lib/python3/dist-packages/numpy/core/include -I/usr/include/openmpi/ 
-I/usr/include/hdf5/serial/ -I/usr/include/python3.10 -c'
extra options: 'gcc'
 EXTRA  {'gcc': ['-fPIC', '-fopenmp', '-g', '-std=c99', '-Wall']}
mpicc: PyHST/Cspace/CCspace.c
 EXTRA  {'gcc': ['-fPIC', '-fopenmp', '-g', '-std=c99', '-Wall']}
mpicc: PyHST/Cspace/Cspace.c
 EXTRA  {'gcc': ['-fPIC', '-fopenmp', '-g', '-std=c99', '-Wall']}
mpicc: PyHST/Cspace/cpyutils.c
 EXTRA  {'gcc': ['-fPIC', '-fopenmp', '-g', '-std=c99', '-Wall']}
mpicc: PyHST/Cspace/pyhst_nnfbp.c
 EXTRA  {'gcc': ['-fPIC', '-fopenmp', '-g', '-std=c99', '-Wall']}
mpicc: PyHST/Cspace/edftools.c
 EXTRA  {'gcc': ['-fPIC', '-fopenmp', '-g', '-std=c99', '-Wall']}
mpicc: PyHST/Cspace/cpu_main.c
PyHST/Cspace/Cspace.c:33:9: fatal error: Python.h: No such file or directory
   33 | #include"Python.h"
  | ^~
compilation terminated.
PyHST/Cspace/cpyutils.c:33:9: fatal error: Python.h: No such file or directory
   33 | #include"Python.h"
  | ^~
compilation terminated.
[...]


Andreas


pyhst2.sid.build.gz
Description: application/gzip

Bug#998055: Problem actually in conmon, not podman

[Reinhard Tartler]

Control: reassign -1 common 2.0.25+ds1-1.1
Control: affects -1 podman

According to the referenced redhat bug entry, this is actually an issue in
the conmon package. Reassigning accordingly.

https://bugzilla.redhat.com/show_bug.cgi?id=1952698



-- 
regards,
Reinhard

Bug#1000265: typo in fix for CVE-2021-21996 breaks file.managed on stretch

[Markus Koschany]

On Sat, 20 Nov 2021 16:46:34 + Jamie Heilman 
wrote:
> Package: salt-common
> Version: 2016.11.2+ds-1+deb9u8
> Severity: grave
> 
> The patch for 994016 in the
> /usr/lib/python2.7/dist-packages/salt/fileclient.py file included:
> 
> +    # clean_path returns an empty string if the check fails
> +    root_path = salt.utils.path.join(cachedir, "extrn_files", saltenv,
netloc)
> 
> which might work for newer versions of salt, but in stretch that has
> to be salt.utils.path_join(...) as the salt.utils.path module didn't
> exist yet.  As-is, the security update for CVE-2021-21996 makes
> file.managed states fail with:
> 
>   Unable to manage file: 'module' object has no attribute 'path'
> 
> which makes salt on stretch pretty much unusable.


Thanks for the report. I wonder why the tests didn't catch that problem. I will
address this with the next upload of salt.

Regards,

Markus


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

Bug#1000291: manpages.debian.org: CSS for .TQ renders ... badly

[Samuel Bronson]

Package: manpages.debian.org
Severity: normal

Dear Maintainer,

Something is going wrong with the .TQ macro on manpages.debian.org.
Specifically, the tags from adjacent .TP and .TQ macros all appear on
top of eachother.

(I have dim recollections of a similar effect involving just .TP with an
empty paragraph or somesuch.)

For example, see:
https://manpages.debian.org/bullseye/groff-base/groff.1.en.html#T
and note the unreadable mess immediately below "dvi":


The relevant portion of the source text is:

.TP
html
.TQ
xhtml
HTML and XHTML output (preprocessors are
.B soelim
and
.BR \%pre-grohtml ,
postprocessor is
.BR \%post-grohtml ).

This is definitely something to do with debiman's CSS, but it may also
relate to the version of docman in use, and I don't know how to
reproduce manpages.debian.org's install.

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

Kernel: Linux 5.10.60.1-microsoft-standard-WSL2 (SMP w/16 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Bug#1000290: linux-image-5.10.0-9-amd64: Trackpoint not working on Debian 11 - Thinkpad T530

[Daniel Bareiro]

Package: src:linux
Version: 5.10.70-1
Severity: normal
X-Debbugs-Cc: dbare...@gmail.com

Dear Maintainer,

I'm trying to use Debian 11 on a Lenovo Thinkpad T530 notebook but I'm
having problems with the trackpoint operation.

Apparently the module that the kernel loads for the trackpoint is
"psmouse" implicitly using "proto=any". But when this happens, the
trackpoint does not work and you see these messages in /var/log/messages:

==
Nov 19 01:02:22 orion kernel: [ 1881.005857] psmouse serio1:
trackpoint: IBM TrackPoint firmware: 0x0e, buttons: 3/3
Nov 19 01:02:22 orion kernel: [ 1881.056663] input: TPPS/2 IBM
TrackPoint as /devices/platform/i8042/serio1/input/input20
Nov 19 01:02:22 orion kernel: [ 1881.074433] psmouse serio1: Failed to
enable mouse on isa0060/serio1
Nov 19 01:02:22 orion kernel: [ 1881.091310] psmouse serio1: Failed to
deactivate mouse on isa0060/serio1: -5
Nov 19 01:02:22 orion kernel: [ 1881.125130] psmouse serio1: Failed to
enable mouse on isa0060/serio1
Nov 19 01:02:22 orion kernel: [ 1881.740546] psmouse serio1: Failed to
enable mouse on isa0060/serio1
Nov 19 01:02:23 orion kernel: [ 1882.408606] psmouse serio1: Failed to
enable mouse on isa0060/serio1
Nov 19 01:02:24 orion kernel: [ 1883.077852] psmouse serio1: Failed to
enable mouse on isa0060/serio1
Nov 19 01:02:24 orion kernel: [ 1883.746033] psmouse serio1: Failed to
enable mouse on isa0060/serio1
Nov 19 01:02:25 orion kernel: [ 1884.415145] psmouse serio1: Failed to
enable mouse on isa0060/serio1
Nov 19 01:02:26 orion kernel: [ 1885.083252] psmouse serio1: Failed to
enable mouse on isa0060/serio1
==

That is, the mouse is detected as a trackpoint (TPPS/2 IBM Trackpoint)
but it is not operational. I guess the "Failed to enable mouse" message
can give a clue as to what the problem is.

If I change to "proto=imps", the trackpoint becomes operational but it is
extremely slow perhaps because it is detected as "PS/2 Generic Mouse".

This problem is replicable on Debian 11 using both linux-image-5.10.0-8-amd64
and linux-image-5.14.0-0.bpo.2-amd64.

I think the problem is purely related to the Linux drivers, since in
tests carried out with FreeBSD 13, the trackpoint is detected as
"TPPS/2 IBM Trackpoint" and it works without any problem.

Please let me know if I can provide any additional information to help
resolve this.


Thanks in advance.

Kind regards,
Daniel

-- Package-specific info:
** Version:
Linux version 5.10.0-9-amd64 (debian-ker...@lists.debian.org) (gcc-10
(Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian)
2.35.2) #1 SMP Debian 5.10.70-1 (2021-09-30)

** Command line:
BOOT_IMAGE=/vmlinuz-5.10.0-9-amd64 root=/dev/mapper/main-root ro

** Not tainted

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

** Model information
sys_vendor: LENOVO
product_name: 2429B51
product_version: ThinkPad T530
chassis_vendor: LENOVO
chassis_version: Not Available
bios_vendor: LENOVO
bios_version: G4ETB7WW (2.77 )
board_vendor: LENOVO
board_name: 2429B51
board_version: Not Defined

** Loaded modules:
ctr
ccm
bnep
binfmt_misc
intel_rapl_msr
intel_rapl_common
x86_pkg_temp_thermal
intel_powerclamp
kvm_intel
kvm
btusb
snd_hda_codec_hdmi
irqbypass
snd_hda_codec_realtek
tpm_tis
tpm_tis_core
btrtl
iwldvm
snd_hda_codec_generic
rapl
intel_cstate
intel_uncore
btbcm
btintel
tpm
mac80211
bluetooth
libarc4
snd_hda_intel
i915
jitterentropy_rng
snd_intel_dspcfg
thinkpad_acpi
soundwire_intel
drbg
ansi_cprng
uvcvideo
soundwire_generic_allocation
ecdh_generic
ecc
snd_soc_core
drm_kms_helper
mei_hdcp
snd_compress
mei_wdt
rng_core
nvram
button
videobuf2_vmalloc
iwlwifi
videobuf2_memops
soundwire_cadence
serio_raw
videobuf2_v4l2
cec
pcspkr
videobuf2_common
i2c_algo_bit
evdev
wmi_bmof
sg
snd_hda_codec
iTCO_wdt
ledtrig_audio
intel_pmc_bxt
snd_hda_core
iTCO_vendor_support
snd_hwdep
cfg80211
watchdog
soundwire_bus
mei_me
mei
rfkill
ac
coretemp
snd_aloop
snd_pcm
snd_timer
snd
soundcore
videodev
mc
parport_pc
ppdev
lp
parport
drm
sunrpc
configfs
fuse
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
dm_crypt
dm_mod
sd_mod
sr_mod
cdrom
t10_pi
crc_t10dif
crct10dif_generic
hid_generic
usbhid
hid
mmc_block
crct10dif_pclmul
crct10dif_common
crc32_pclmul
crc32c_intel
ghash_clmulni_intel
ahci
libahci
aesni_intel
libata
libaes
crypto_simd
cryptd
xhci_pci
glue_helper
xhci_hcd
scsi_mod
ehci_pci
psmouse
ehci_hcd
usbcore
sdhci_pci
cqhci
lpc_ich
e1000e
sdhci
mmc_core
ptp
pps_core
usb_common
wmi
battery
video

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 3rd Gen Core processor
DRAM Controller [8086:0154] (rev 09)
Subsystem: Lenovo 3rd Gen Core processor DRAM Controller [17aa:21f6]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-

Bug#1000239: Rescue system won't find root partition, but insists on /usr

[Steve McIntyre]

Hi Tom,

On Sat, Nov 20, 2021 at 01:59:42AM +, TomK wrote:
>Package: debian-installer
>Version: 20210731+deb11u1_amd64
>
>Errors, "No suitable shell found on /dev/sda1"
>
>Cycling through every partition results in what should be /usr being
>selected as the root partition. This is useless for a rescue syatem,
>because there some commands missing.
>
>I tried to mount the root partition on a mount point I made inside
>the installer, but there was a problem with permissions. I can't
>perfectly remember. I tried 'sudo', but it isn't available in the
>installer.
>
>I was attempting to reinstall grub, to get the system to boot. I have
>also used the rescue syatem to change a lost password. It appears
>this bug may apply only to a gpt partition table and a fat32 boot
>partition (efi?).
>
>I've had this same problem with 2 systems, a lappy and a desktop. I
>can always work around it. I don't understand what could be going on,
>for lack of experience. I've only been a Debian user since Woody was
>in testing.
>
>It's easy to reproduce. Do an expert install with defaults, but
>partition with gpt. Boot the system with the install media, launch a
>rescue shell, and try to open a root shell. An incorrect device
>should be identified as '/'. Perhaps this occurs only when /usr is on
>a different partition that '/'.
>
>But it is bothersome, because it essentially removes 90% of the
>functionality from the rescue system. The install media used to be my
>goto for rescue. But now I've found this very annoying problem. If
>you require more info, I can boot the dvd again and record exact
>errors.

Just to be sure, can you expand on this "expert install with defaults"
please? Exactly what partition layout are you using? Reading the rest
of your mail, I get the impresion that you're putting /usr on a
different fs from the rootfs?

As well as working on the rescue setup, I've personally used it quite
a bit over the years and so long as you identify the rootfs ok it
normally works just fine in my experience. Hence I'm curious to see
how your setup may be causing a different experience...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"War does not determine who is right - only who is left."
   -- Bertrand Russell

Bug#999904: Uncoordinated split of debugedit package out of src:rpm

[Peter Pentchev]

Version: 4.17.0+dfsg1-1

On Thu, Nov 18, 2021 at 12:19:10PM +0200, Peter Pentchev wrote:
> control: tag -1 + confirmed pending
> 
> On Thu, Nov 18, 2021 at 09:45:06AM +0100, Laurent Bigonville wrote:
> > Source: debugedit,rpm
> > Severity: serious
> > Tags: sid bookworm
> > 
> > Hello,
> > 
> > debugedit has been split out of the src:rpm package, but src:rpm is
> > still building the package as well.
> > 
> > In addition to that, rpm package has a strong versioned dependency
> > against debugedit (debugedit (= 4.16.1.2+dfsg1-3)) which means that rpm
> > cannot be installed anymore.
> > 
> > We need to keep this package out of testing until this is resolved
> 
> FTR, it has not been completely uncoordinated, there is an ongoing
> discussion on the RPM packaging team's mailing list where Matthias
> asked about our plans to upgrade rpm to 4.17 and I confirmed that
> there is work in progress and it will most probably be done in
> the next couple of days.
> 
> Still, thanks for filing this bug for the purpose of keeping the new
> version of debugedit out of testing for the present.

Right, and of course I forgot to close this bug in the 4.17.0+dfsg1-1
changelog entry.

Thanks again for filing it!

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#1000210: [regression] uscan die: filenamemangle failed

[Yadd]

OK, let's do that
-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Bug#990316: Make IME support enabled by default in kitty

[Gunnar Hjalmarsson]

On 2021-11-20 21:53, James McCoy wrote:

On Sat, Nov 20, 2021 at 11:37:14PM +0900, Osamu Aoki wrote:

If I understand correctly, upstream chose to disable ibus feature
if GLFW_IM_MODULE is not set to ibus.  So ibus is opt-in feature.
Reverting that feature choice is one option for Debian maintainer
can do indeed.  This is a risky path most maintainers hesitate.


Yeah, this isn't something I would patch.


Fair enough. And given that, it would not be appropriate to bypass the 
restrain in Debian via im-config.



Since kitty has kitty.conf, a non-confrontational approach may be a
patch to add one configuration option in kitty.conf to enable ibus.
So ibus support is still opt-in feature.


That sounds like a reasonable approach, if someone would like to
propose a patch/PR to Kovid.  I'm not familiar with IME topics, so I
don't think I would be in a good position to advocate for that.


Seems like that has already been proposed and turned down:

https://github.com/kovidgoyal/kitty/issues/3206

So maybe users who want IME support in kitty need to get used to set 
that environment variable.


--
Regards,
Gunnar Hjalmarsson

Bug#1000210: [regression] uscan die: filenamemangle failed

[Mattia Rizzolo]

This is not the problem here really.  It's the different matching base.

Together with the previous versification I also verified that such
filenamemangle (like systemd's) don't match anymore.  That's equally
problematic (if not more!) than the program exiting with an error.

I can agree however you want that it's a bad design, but that has been the
specification since the start and it can't change without a format bump.

I plan to revert Hugh's commit in the next days to solve this, reopening
the previous bug and pending a better fix.

On Sat, 20 Nov 2021, 11:02 pm Yadd,  wrote:

> Le 20/11/2021 à 13:36, Mattia Rizzolo a écrit :
> > On Sat, Nov 20, 2021 at 01:14:23PM +0100, Yadd wrote:
> >> Le 20/11/2021 à 12:23, Mattia Rizzolo a écrit :
> >>> So, effectively, the change broke the specification.
> >>
> >> It looks like the specification was not good. A filename isn't an URL
> >
> > Be that as it may, we can't break something like that without a version
> > bump, IMHO.
> >
> > So we need a different fix for #993585.
> >
> > Either way, I think it's unrelated to your discovery that it could
> > potentially overwrite a file, isn't it?
>
> We could perhaps just warn for now on bad filenamemangle
>

Bug#1000210: [regression] uscan die: filenamemangle failed

[Yadd]

Le 20/11/2021 à 13:36, Mattia Rizzolo a écrit :
> On Sat, Nov 20, 2021 at 01:14:23PM +0100, Yadd wrote:
>> Le 20/11/2021 à 12:23, Mattia Rizzolo a écrit :
>>> So, effectively, the change broke the specification.
>>
>> It looks like the specification was not good. A filename isn't an URL
> 
> Be that as it may, we can't break something like that without a version
> bump, IMHO.
> 
> So we need a different fix for #993585.
> 
> Either way, I think it's unrelated to your discovery that it could
> potentially overwrite a file, isn't it?

We could perhaps just warn for now on bad filenamemangle

Bug#999826: debian-policy: fix Build-Depends footnote

[Johannes Schauer Marin Rodrigues]

Hi Sean,

Quoting Sean Whitton (2021-11-19 23:13:46)
> Can you turn this into a patch against our git repo, please?

maybe I'm looking at the wrong git repo but I didn't find out how to file a
merge request. Thus attaching the git format-patch.

Thanks!

cheers, josch>From dc186d400e47c9eed7dc94a2be4daa59b3fa2665 Mon Sep 17 00:00:00 2001
From: Johannes Schauer Marin Rodrigues 
Date: Sat, 20 Nov 2021 22:50:49 +0100
Subject: [PATCH] fixup B-D alternatives footnote (closes: #999826)

---
 policy/ch-relationships.rst | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/policy/ch-relationships.rst b/policy/ch-relationships.rst
index 915d00d..357a612 100644
--- a/policy/ch-relationships.rst
+++ b/policy/ch-relationships.rst
@@ -669,11 +669,20 @@ against newer versions of their build dependencies.
 .. [#]
While ``Build-Depends``, ``Build-Depends-Indep`` and
``Build-Depends-Arch`` permit the use of alternative dependencies,
-   these are not normally used by the Debian autobuilders.  To avoid
-   inconsistency between repeated builds of a package, the
-   autobuilders will default to selecting the first alternative, after
-   reducing any architecture-specific restrictions for the build
-   architecture in question.  While this may limit the usefulness of
+   those are only used for the backports suite on the Debian autobuilders.
+   On the other suites, after reducing any architecture-specific restrictions
+   for the build architecture in question, all but the first alternative are
+   discarded except if the alternative is the same package name as the first.
+   The latter exception is useful to specify version ranges like
+   ``foo (rel x) | foo (rel y)``. This is to reduce the risk of inconsistencies
+   between repeated rebuilds. For example if a source package build depends
+   on ``libcurl4-gnutls-dev | libcurl4-openssl-dev``, then during a transition
+   libcurl4-gnutls-dev might become uninstallable because apt only considers
+   the latest version of a package and then the source package would be wrongly
+   built with openssl instead of gnutls. Inconsistencies are not completely
+   avoided because virtual packages might still be provided by a different
+   real package and because alternatives are still preserved for binary package
+   dependencies. While this may limit the usefulness of
alternatives in a single release, they can still be used to provide
flexibility in building the same package across multiple
distributions or releases, where a particular dependency is met by
-- 
2.33.0



signature.asc
Description: signature

Bug#1000275: dh_installdocs: strange filenames for doc-base files

[Julian Gilbey]

On Sat, Nov 20, 2021 at 09:11:18PM +0100, Axel Beckert wrote:
> Hi Julian,
> 
> Julian Gilbey wrote:
> > Since the bullseye release, something seems to have changed with the
> > behaviour of dh_installdocs,
> 
> Correct.
> [...]

> Yes. It's the fix for https://bugs.debian.org/980903 from debhelper 13.4:
> 
>   [ Axel Beckert ]
>   * Always generate unique doc-base file names based on package name and
> document ID. (Closes: #980903)
> 
> See that bug report for the gory details.
> 
> And yes, it looks ugly, but it seems the only solution for that
> (seemingly rather seldom but IMHO severe) issue.

Ah, thanks Axel, and sorry for the noise.

Best wishes,

   Julian

Bug#953143: mbedtls: Please make autopkgtests cross-test-friendly

[Gianfranco Costamagna]

control: tags -1 patch pending

the attached diff is now in deferred/5.
Feel free to change as you prefer

G.

On Wed, 04 Mar 2020 22:49:11 -0800 Steve Langasek 
 wrote:
> Package: mbedtls
> Version: 2.16.4-1
> Severity: minor
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu focal ubuntu-patch
> 
> Hi James,
> 
> In Ubuntu, we are in the process of moving the i386 architecture to a
> compatibility-only layer on amd64, and therefore we are also moving our
> autopkgtest infrastructure to test i386 binaries in a cross-environment.
> 
> This requires changes to some tests so that they are cross-aware and can do
> the right thing.
> 
> The mbedtls tests currently fail in this environment, because they are build
> tests that do not invoke the toolchain in a cross-aware manner and also do
> not use cross-capable test dependencies.  I've verified that the attached
> patch lets the tests successfully build (and run) i386 tests on an amd64
> host.
> 
> Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so this
> is a complete no-op in Debian for the moment.  Support for cross-testing in
> autopkgtest is currently awaiting review at
> https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
> landed, will still have no effect unless autopkgtest is invoked with a '-a'
> option.  So this change should be safe to land in your package despite this
> not being upstream in autopkgtest.
> 
> Thanks for considering,
> -- 
> Steve Langasek   Give me a lever long enough and a Free OS
> Debian Developer   to set it on, and I can move the world.
> Ubuntu Developer   https://www.debian.org/
> slanga...@ubuntu.com vor...@debian.org
diff -Nru mbedtls-2.16.11/debian/changelog mbedtls-2.16.11/debian/changelog
--- mbedtls-2.16.11/debian/changelog2021-11-17 17:08:07.0 +0100
+++ mbedtls-2.16.11/debian/changelog2021-11-20 22:30:00.0 +0100
@@ -1,3 +1,11 @@
+mbedtls (2.16.11-0.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  [ Steve Langasek ]
+  * Make autopkgtests cross-test-friendly (Closes: #953143).
+
+ -- Gianfranco Costamagna   Sat, 20 Nov 2021 
22:30:00 +0100
+
 mbedtls (2.16.11-0.1) unstable; urgency=medium
 
   * Non-maintainer upload
diff -Nru mbedtls-2.16.11/debian/tests/build mbedtls-2.16.11/debian/tests/build
--- mbedtls-2.16.11/debian/tests/build  2020-02-29 23:26:47.0 +0100
+++ mbedtls-2.16.11/debian/tests/build  2021-11-20 22:29:38.0 +0100
@@ -11,6 +11,13 @@
 fi
 
 cd "$AUTOPKGTEST_TMP"
+
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
 cat < mbedtls_sha1.c
 #include 
 #include 
@@ -37,9 +44,9 @@
 EOF
 
 # Build program shared + statically
-gcc -Wall -Werror -o mbedtls_sha1 mbedtls_sha1.c -lmbedcrypto
+${CROSS_COMPILE}gcc -Wall -Werror -o mbedtls_sha1 mbedtls_sha1.c -lmbedcrypto
 echo "build1: OK"
-gcc -Wall -Werror -static -o mbedtls_sha1_static mbedtls_sha1.c -lmbedcrypto
+${CROSS_COMPILE}gcc -Wall -Werror -static -o mbedtls_sha1_static 
mbedtls_sha1.c -lmbedcrypto
 echo "build2: OK"
 
 # Run it on a few strings
diff -Nru mbedtls-2.16.11/debian/tests/control 
mbedtls-2.16.11/debian/tests/control
--- mbedtls-2.16.11/debian/tests/control2020-02-29 23:26:47.0 
+0100
+++ mbedtls-2.16.11/debian/tests/control2021-11-20 22:29:43.0 
+0100
@@ -1,2 +1,2 @@
 Tests: build selftest
-Depends: gcc, libc-dev, libmbedtls-dev
+Depends: build-essential, libmbedtls-dev
diff -Nru mbedtls-2.16.11/debian/tests/selftest 
mbedtls-2.16.11/debian/tests/selftest
--- mbedtls-2.16.11/debian/tests/selftest   2020-02-29 23:26:47.0 
+0100
+++ mbedtls-2.16.11/debian/tests/selftest   2021-11-20 22:29:48.0 
+0100
@@ -10,10 +10,16 @@
exit 1
 fi
 
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
 # Build mbedtls_selftest shared / statically
-cc -Wall -Werror programs/test/selftest.c -o 
"$AUTOPKGTEST_TMP/mbedtls_selftest" -lmbedtls -lmbedx509 -lmbedcrypto
+${CROSS_COMPILE}gcc -Wall -Werror programs/test/selftest.c -o 
"$AUTOPKGTEST_TMP/mbedtls_selftest" -lmbedtls -lmbedx509 -lmbedcrypto
 echo "build1: OK"
-cc -Wall -Werror -static programs/test/selftest.c -o 
"$AUTOPKGTEST_TMP/mbedtls_selftest_static" -lmbedtls -lmbedx509 -lmbedcrypto 
-pthread
+${CROSS_COMPILE}gcc -Wall -Werror -static programs/test/selftest.c -o 
"$AUTOPKGTEST_TMP/mbedtls_selftest_static" -lmbedtls -lmbedx509 -lmbedcrypto 
-pthread
 echo "build2: OK"
 
 # Run the testsuite twice

Bug#1000288: ITP: golang-github-mazznoer-csscolorparser -- Go (Golang) CSS color parser library

[Chris Keller]

Package: wnpp
Severity: wishlist
Owner: Chris Keller 

* Package name: golang-github-mazznoer-csscolorparser
  Version : 0.1.1-1
  Upstream Author : Nor Khasyatillah
* URL : https://github.com/mazznoer/csscolorparser
* License : Expat
  Programming Lang: Go
  Description : Go (Golang) CSS color parser library

 Go library for parsing CSS color
 string as defined in the W3C's CSS Color Module Level 4
 (https://www.w3.org/TR/css-color-4/).

Adding this as a dependency of golang-github-k0swe-wsjtx-go in an
upcoming version.

Bug#1000287: python-tornado FTBFS with Python 3.10

[Adrian Bunk]

Source: python-tornado
Version: 6.1.0-1
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=python-tornado

...
==
ERROR: test_asyncio_accessor 
(tornado.test.asyncio_test.AnyThreadEventLoopPolicyTest)
--
Traceback (most recent call last):
  File "/<>/tornado/test/asyncio_test.py", line 187, in 
test_asyncio_accessor
self.run_policy_test(asyncio.get_event_loop, asyncio.AbstractEventLoop)
  File "/<>/tornado/test/asyncio_test.py", line 184, in 
run_policy_test
self.executor.submit(lambda: asyncio.get_event_loop().close()).result()  # 
type: ignore
  File "/usr/lib/python3.10/concurrent/futures/_base.py", line 445, in result
return self.__get_result()
  File "/usr/lib/python3.10/concurrent/futures/_base.py", line 390, in 
__get_result
raise self._exception
  File "/usr/lib/python3.10/concurrent/futures/thread.py", line 58, in run
result = self.fn(*self.args, **self.kwargs)
  File "/<>/tornado/test/asyncio_test.py", line 184, in 
self.executor.submit(lambda: asyncio.get_event_loop().close()).result()  # 
type: ignore
DeprecationWarning: There is no current event loop
...

Bug#1000286: kdepim: akonadi_maildispatcher_agent fails to retrieve saved passwords

[Juha Jäykkä]

Package: kdepim
Version: 4:21.08.1+5.115
Severity: normal

Dear Maintainer,

As of the upgrade to 4:21.08.1+5.113, kmail has been unable to send emails 
without
asking for password. It looks like akonadi_maildispatcher_agent fails to 
retrieve
the password from kwallet. akonadi_maildispatcher_agent is authorised to use the
wallet and will even save the password there (on the first send on a new 
acccount),
but never retrieves it from the despite it being there.

Reproduce: create a new outgoing account, click "save password", send email,
enter password, email goes out fine. Check kwallet: password has been saved, but
send another email and kmail asks for password again instead of getting it from
the wallet.

Cheers,
Juha

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

Kernel: Linux 5.14.0-3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN
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 kdepim depends on:
ii  accountwizard4:21.08.1-1+b1
ii  akonadiconsole   4:21.08.1-1+b1
ii  akregator4:21.08.1-1+b1
ii  kaddressbook 4:21.08.1-1+b1
ii  kalarm   4:21.08.1-1+b1
ii  kdepim-runtime   4:21.08.1-1+b1
ii  kleopatra4:21.08.1-2
ii  kmail4:21.08.1-1+b1
ii  knotes   4:21.08.1-1+b1
ii  konsolekalendar  4:21.08.1-1+b1
ii  kontact  4:21.08.1-1+b1
ii  korganizer   4:21.08.1-1+b1

Versions of packages kdepim recommends:
ii  kdepim-addons  21.08.1-2

kdepim suggests no packages.

-- no debconf information

Bug#990316: Make IME support enabled by default in kitty

[James McCoy]

On Sat, Nov 20, 2021 at 11:37:14PM +0900, Osamu Aoki wrote:
> If I understand correctly, upstream chose to disable ibus feature if 
> GLFW_IM_MODULE
> is not set to ibus.  So ibus is opt-in feature. Reverting that feature choice 
> is one
> option for Debian maintainer can do indeed.  This is a risky path most 
> maintainers
> hesitate.

Yeah, this isn't something I would patch.

> Since kitty has kitty.conf, a non-confrontational approach may be a patch to 
> add one
> configuration option in kitty.conf to enable ibus.  So ibus support is still 
> opt-in
> feature.

That sounds like a reasonable approach, if someone would like to propose
a patch/PR to Kovid.  I'm not familiar with IME topics, so I don't think
I would be in a good position to advocate for that.

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

Bug#1000284: ITP: golang-github-ant0ine-go-json-rest -- A quick and easy way to setup a RESTful JSON API

[Andreas Henriksson]

Package: wnpp
Severity: wishlist
Owner: Andreas Henriksson 

* Package name: golang-github-ant0ine-go-json-rest
  Version : 3.3.2-1
  Upstream Author : Antoine Imbert
* URL : https://github.com/ant0ine/go-json-rest
* License : Expat
  Programming Lang: Go
  Description : A quick and easy way to setup a RESTful JSON API

 Go-Json-Rest is a thin layer on top of net/http that helps building
 RESTful JSON APIs easily. It provides fast and scalable request
 routing using a Trie based implementation, helpers to deal with
 JSON requests and responses, and middlewares for functionalities
 like CORS, Auth, Gzip, Status ...
 .
 https://godoc.org/github.com/ant0ine/go-json-rest/rest
 .
 This package will be maintained under the go-team umbrella and used as
 a build-dependency for golang-github-mendersoftware-go-lib-micro (once
 packaged, see ITP).

Bug#1000283: Icecast2 compiled without ssl support

[Joram M.]

Package: Icecast2
Version: 2.4.4-1

#ldd /usr/bin/icecast2 | grep ssl
#

Please compile Icecast2 with ssl supporto

Debian 10.11
Linux stream 4.19.0-18-amd64 #1 SMP Debian 4.19.208-1 (2021-09-29) x86_64 
GNU/Linux

Bug#1000279: FTBFS: CMake Error: Unknown argument --enable-perl

[Stefano Rivera]

Source: openscap
Version: 1.3.4-1
Severity: important
Tags: ftbfs

In the Python 3.10 binNMUs, openscap FTBFS with:

   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
dh_auto_configure -Bbuild-python-3.10 -- --enable-sce --enable-perl 
-DPERL_VERSION=5.32 PYTHON=/usr/bin/python3.10
install -d build-python-3.10
cd build-python-3.10 && cmake -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run 
"-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu --enable-sce --enable-perl 
-DPERL_VERSION=5.32 PYTHON=/usr/bin/python3.10 ..
CMake Error: Unknown argument --enable-perl
CMake Error: Run 'cmake --help' for all supported options.
dh_auto_configure: error: cd build-python-3.10 && cmake 
-DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None 
-DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var 
-DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run 
"-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu --enable-sce --enable-perl 
-DPERL_VERSION=5.32 PYTHON=/usr/bin/python3.10 .. returned exit code 1

Full log attached.

Removing --enable-sce --enable-perl seems to work (and it reports the
features as enabled), but I don't know CMake well enough to know what's
going on here.

SR
sbuild (Debian sbuild) 0.81.2 (31 January 2021) on haydn.kardiogramm.net

+==+
| openscap (amd64) Sat, 20 Nov 2021 19:56:42 + |
+==+

Package: openscap
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary

WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
confinement
WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
confinement
WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
confinement
WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
confinement
WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
confinement
WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
confinement
WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
confinement
WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
confinement
WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
confinement
WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
confinement
WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
confinement
WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
confinement
WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
confinement
WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
confinement
WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
confinement
WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
confinement
WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
confinement
WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
confinement
I: NOTICE: Log filtering will replace 'autopkgtest-virt-dummy-location' with 
'<>'
WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
confinement
WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
confinement
WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
confinement
WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
confinement
WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
confinement
WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
confinement
WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
confinement
WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
confinement
WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
confinement
WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
confinement
WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
confinement
I: NOTICE: Log filtering will replace 'build/openscap-GPUfdK/resolver-WSkP11' 
with '<>'

+--+
| Update chroot|
+--+

WARNING: cgroup v2 is not fully supported yet, 

Bug#1000280: ITP: golang-github-mendersoftware-go-lib-micro -- Group of golang packages for developing microservices.

[Andreas Henriksson]

Package: wnpp
Severity: wishlist
Owner: Andreas Henriksson 

* Package name: golang-github-mendersoftware-go-lib-micro
  Version : 0.0~git20211108.4e20429-1
  Upstream Author : Mender
* URL : https://github.com/mendersoftware/go-lib-micro
* License : Apache-2.0
  Programming Lang: Go
  Description : Group of golang packages for developing microservices.

 Mender: go-lib-micro Mender is an open source over-the-air (OTA) software
 updater for embedded Linux devices. Mender comprises a client running
 at the embedded device, as well as a server that manages deployments
 across many devices.
 .
 This repository contains the Mender go-lib-micro library, which is part
 of the Mender server. The Mender server is designed as a microservices
 architecture and comprises several repositories.
 .
 The go-lib-micro library is a collection of utilities and middlewares
 shared among microservices in the Mender ecosystem.
 .
 This package will be used as a build-dependency of mender-cli when
 updating to 1.7.0 (and possibly other mender components).
 The package will be team-maintained under the go-team umbrella.

Bug#1000278: npm cannot find module 'isexe'

[nemanja]

Package: npm
Version: 7.24.2+ds-1
Severity: important
X-Debbugs-Cc: unkovicnemanja1...@gmail.com

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: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages npm depends on:
ii  ca-certificates20211016
ii  node-abbrev1.1.1-3
ii  node-agent-base6.0.2+~cs5.4.1-3
ii  node-ajv   6.12.6-2
ii  node-ansi-regex5.0.1-1
ii  node-ansi-styles   4.2.1-1
ii  node-ansistyles0.1.3-4
ii  node-aproba2.0.0-2
ii  node-archy 1.0.0-4
ii  node-are-we-there-yet  1.1.5-2
ii  node-asap  2.0.6-4
ii  node-asn1  0.2.3-2
ii  node-assert-plus   1.0.0-3
ii  node-asynckit  0.4.0-3
ii  node-aws-sign2 0.7.1-3
ii  node-aws4  1.11.0-2
ii  node-balanced-match2.0.0-1
ii  node-bcrypt-pbkdf  1.0.2-2
ii  node-binary-extensions 2.2.0-2
ii  node-brace-expansion   2.0.0-1
ii  node-builtins  1.0.3-2
ii  node-cacache   15.0.5+~cs13.9.21-3
ii  node-caseless  0.12.1-2
ii  node-chalk 4.1.2-1
ii  node-chownr2.0.0-1
ii  node-clone 2.1.2-3
ii  node-color-convert 2.0.1-1
ii  node-color-name1.1.4+~1.1.1-1
ii  node-colors1.4.0-3
ii  node-columnify 1.5.4-3
ii  node-combined-stream   1.0.8-1
ii  node-concat-map0.0.1-5
ii  node-console-control-strings   1.1.0-2
ii  node-core-util-is  1.0.3-1
ii  node-dashdash  2.0.0-2
ii  node-debug 4.3.2+~cs4.1.7-1
ii  node-defaults  1.0.3-2
ii  node-delayed-stream1.0.0-4
ii  node-delegates 1.0.0-2
ii  node-depd  2.0.0-2
ii  node-diff  5.0.0~dfsg+~5.0.1-1
ii  node-ecc-jsbn  0.2.0-3
ii  node-encoding  0.1.13-1
ii  node-err-code  2.0.3+dfsg-1
ii  node-extend3.0.2-1
ii  node-extsprintf1.4.1+~1.4.1-1
ii  node-fancy-log 1.3.3+~cs1.3.1-1
ii  node-fast-deep-equal   3.1.3-1
ii  node-forever-agent 0.6.1-2
ii  node-fs.realpath   1.0.0-2
ii  node-function-bind 1.1.1+repacked+~1.0.3-1
ii  node-gauge 4.0.0-1
ii  node-getpass   0.1.7-2
ii  node-glob  7.1.7+~cs7.5.19-2
ii  node-got   11.8.2+~cs58.7.32-2
ii  node-graceful-fs   4.2.4+repack-1
ii  node-gyp   7.1.2-5
ii  node-har-schema2.0.0-5
ii  node-har-validator 5.1.5-2
ii  node-has-flag  4.0.0-1
ii  node-has-unicode   2.0.1-2
ii  node-hosted-git-info   4.0.2-1
ii  node-http-signature1.3.5-1
ii  node-https-proxy-agent 5.0.0+~cs8.0.0-2
ii  node-iconv-lite0.6.3-1
ii  node-imurmurhash   0.1.4-1.1
ii  node-indent-string 4.0.0-2
ii  node-inflight  1.0.6-1.1
ii  node-inherits  2.0.4-4
ii  node-ini   2.0.0-1
ii  node-ip1.1.5-5
ii  node-ip-regex  4.3.0-1
ii  node-is-typedarray 1.0.0-4
ii  node-isexe 2.0.0+~2.0.1-1
ii  node-isstream  0.1.2+dfsg+~0.1.0-1
ii  node-jsbn  1.1.0+~1.2.29-1
ii  node-json-parse-better-errors  1.0.2+~2.3.1-1
ii  node-json-schema   0.4.0+~7.0.9-1
ii  node-json-schema-traverse  1.0.0-3
ii  node-json-stable-stringify 1.0.1+~cs5.2.33-1
ii  node-json-stringify-safe   5.0.1+repack-3
ii  node-jsonparse 1.3.1-8
ii  node-jsprim2.0.1-1
ii  

Bug#1000277: ITP: python-wcmatch -- wildcard match library

[Samuel Henrique]

Package: wnpp
X-Debbugs-Cc: debian-de...@lists.debian.org
Owner: Samuel Henrique 
X-Debbugs-Cc: samuel...@debian.org
Severity: wishlist

* Package name: python-wcmatch
  Version : 8.3
  Upstream Author : Isaac Muse 
* URL : https://github.com/facelessuser/wcmatch
* License : MIT
  Programming Lang: Python
  Description : wildcard match library

Wildcard Match provides an enhanced fnmatch, glob, and pathlib library
in order to provide file matching and globbing that more closely
follows the features found in Bash. In some ways these libraries are
similar to Python's builtin libraries as they provide a similar
interface to match, filter, and glob the file system. But they also
include a number of features found in Bash's globbing such as
backslash escaping, brace expansion, extended glob pattern groups,
etc. They also add a number of new useful functions as well, such as
globmatch which functions like fnmatch, but for paths.

Wildcard Match also adds a file search utility called wcmatch that is
built on top of fnmatch and globmatch. It was originally written for
Rummage, but split out into this project to be used by other projects
that may find its approach useful.


This package is a build-dep of ansible-lint 5.x and it will be
maintained under the Debian Python Team
 at
https://salsa.debian.org/python-team/packages/python-wcmatch

-- 
Samuel Henrique 

Bug#1000276: ITP: python-bracex -- brace expanding library

[Samuel Henrique]

Package: wnpp
X-Debbugs-Cc: debian-de...@lists.debian.org
Owner: Samuel Henrique 
X-Debbugs-Cc: samuel...@debian.org
Severity: wishlist

* Package name: python-bracex
  Version : 2.2.1
  Upstream Author : Isaac Muse 
* URL : https://github.com/facelessuser/bracex
* License : MIT
  Programming Lang: Python
  Description : brace expanding library

Bracex is a brace expanding library (à la Bash) for Python. Brace
expanding is used to generate arbitrary strings.

Bracex actually follows pretty closely to how Bash processes braces.
It is not a 1:1 implementation of how Bash handles braces, but
generally, it follows very closely. Almost all of the test cases are
run through Bash first, then our implementation is compared against
the results Bash gives. There are a few cases where we have purposely
deviated. For instance, we are not handling Bash's command line
inputs, so we are not giving special meaning to back ticks and quotes
at this time.

On the command line Bracex can handle more expansions than Bash itself.


This package is a build-dep of ansible-lint 5.x and it will be
maintained under the Debian Python Team
 at
https://salsa.debian.org/python-team/packages/python-bracex

-- 
Samuel Henrique 

Bug#999565: transition: fluidsynth

[Dennis Braun]

Sorry not 2 times doomsday,
prboom-plus was missing as not tested

On 20.11.21 18:58, Dennis Braun wrote:

Heya,

i tested those builds against the new version successfully:

alure
ardour
audacious-plugins
calf
csound
denemo
fluidsynth-dssi
gst-plugins-bad1.0
kodi-audiodecoder-fluidsynth
libdrumstick
libsdl2-mixer
lmms
minuet
mpd
muse
pianobooster
qsynth
swami
tuxguitar
vlc

those 2 had errors:

buzztrax: https://paste.debian.net/1220211/
libtritonus-java: https://paste.debian.net/1220212/

and those 5 i haven't tested so far:

doomsday
freewheeling
doomsday
scummvm
sdl-mixer1.2

Best regards,
Dennis

Bug#1000275: dh_installdocs: strange filenames for doc-base files

[Julian Gilbey]

Package: debhelper
Version: 13.5.2
Severity: normal

Since the bullseye release, something seems to have changed with the
behaviour of dh_installdocs, as my package abydos is now installing
/usr/share/doc-base/python-abydos-doc.abydos rather than
/usr/share/doc-base/abydos.  And it's not just this package; I listed
/usr/share/doc-base on my Debian testing system and found all sorts of
files such as gdisk.gdisk, eric.eric, and so on.  Is this intentional?

Best wishes,

   Julian

Bug#1000274: py7zr FTBFS with python 3.10

[Adrian Bunk]

Source: py7zr
Version: 0.11.3+dfsg-1
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/logs.php?pkg=py7zr=0.11.3%2Bdfsg-1%2Bb1

...
= test session starts ==
platform linux -- Python 3.10.0+, pytest-6.2.5, py-1.10.0, pluggy-0.13.0
benchmark: 3.2.2 (defaults: timer=time.perf_counter disable_gc=False 
min_rounds=5 min_time=0.05 max_time=1.0 calibration_precision=10 
warmup=False warmup_iterations=10)
rootdir: /<>, configfile: tox.ini
plugins: cov-3.0.0, benchmark-3.2.2
collected 268 items / 12 deselected / 256 selected

tests/test_archive.py ...ss  [ 11%]
tests/test_basic.py .F.  [ 26%]
tests/test_benchmark.py ..   [ 28%]
tests/test_concurrent.py .   [ 29%]
tests/test_encryption.py s.. [ 35%]
tests/test_extra_codecs.py ....s.[ 43%]
tests/test_extract.py ..s.   [ 60%]
tests/test_info.py ..[ 67%]
tests/test_misc.py ss..  [ 69%]
tests/test_unit.py . [ 90%]
...s.[ 98%]
tests/test_win32compat.py ...s   [100%]

=== FAILURES ===
 test_cli_help _

capsys = <_pytest.capture.CaptureFixture object at 0x7f1529a9ee60>

@pytest.mark.cli
def test_cli_help(capsys):

expected = 'usage: py7zr [-h] [--version] {l,x,c,a,t,i} 
...\n\npy7zr\n\noptional arguments:\n  -h, --help'
cli = py7zr.cli.Cli()
with pytest.raises(SystemExit):
cli.run(["-h"])
out, err = capsys.readouterr()
>   assert out.startswith(expected)
E   AssertionError: assert False
E+  where False = ('usage: py7zr [-h] [--version] {l,x,c,a,t,i} 
...\n\npy7zr\n\noptional arguments:\n  -h, --help')
E+where  = 'usage: py7zr [-h] [--version] {l,x,c,a,t,i} 
...\n\npy7zr\n\noptions:\n  -h, --help show this help message and exi...s 
of archive\n   t : Test integrity of archive\n  
 x : eXtract files with full paths\n'.startswith

/<>/tests/test_basic.py:174: AssertionError
...

Bug#992003: [Debian-science-sagemath] Singular update

[Dima Pasechnik]

4.2.1.p2 appears to include an essential compatibility fix for Flint 2.8.4

On Sat, 20 Nov 2021, 17:48 Torrance, Douglas, 
wrote:

> On Sat 20 Nov 2021 02:50:55 AM EST, Tobias Hansen 
> wrote:
> > any chance we could get an update of singular to 4.2.1.p0 in
> experimental? I tried to do it myself once but the package has many patches
> and it was difficult to get everything right.
>
> I'm also interested in getting singular 4.2.x in Debian, as Macaulay2
> requires
> it as well.  (Fortunately, it still works with 4.1.x with a patch, but
> upstream
> claims it's buggy.)
>
> Doug
> ___
> Debian-science-sagemath mailing list
> debian-science-sagem...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-sagemath
>

Bug#1000272: pytzdata: Invalid debian/watch new version monitoring

[Boyuan Yang]

Source: pytzdata
Version: 2020.1+dfsg-3
Severity: normal
X-Debbugs-CC: dan...@debian.org

Dear Debian pytzdata package maintainer,

https://sources.debian.org/src/pytzdata/2020.1+dfsg-3/debian/watch/#L3

version=4
opts=filenamemangle=s/.+\/v?(\d\S+)\.tar\.gz/pytzdata-$1\.tar\.gz/ \
https://github.com/sdispater/pytzdata/releases .*/v?(\d\S+)\.tar\.gz

This debian/watch file will not work since
https://github.com/sdispater/pytzdata/releases is empty.

Please consider monitoring using tags page instead. For example, the
"github.com example" section from uscan(1) man page provides a best effort
example as shown in
https://manpages.debian.org/bullseye/devscripts/uscan.1.en.html#github.com :

  version=4
  opts="filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%@PACKAGE@-$1.tar.gz%" \
  https://github.com///tags \
  (?:.*?/)?v?(\d[\d.]*)\.tar\.gz debian uupdate

-- 
Thanks,
Boyuan Yang


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

Bug#993219: [debian-mysql] Bug#993219: mariadb-server-core: Akonadi database - mysql_upgrade fails always with "FATAL ERROR: Can't execute 'mysqlcheck'"

[Ulrich Beckmann]

It's me again!

Otto,
I found out that it is an Akonadi problem: Akonadi uses Mariadb as default 
database, but does not provide mysqlcheck through dependencies.
Now I could repair the table structure with that knowledge, see the attached 
file.

Would you please add the Akonadi maintainer to this bug report?

Best regards
Ulrich

*** b e f o r e ***

bequimao@bullseye-kde:~$ cat .local/share/akonadi/db_data/mysql.err
2021-11-20 14:36:37 0 [Warning] WSREP: Failed to guess base node address. Set it explicitly via wsrep_node_address.
2021-11-20 14:36:37 0 [Warning] WSREP: Failed to guess base node address. Set it explicitly via wsrep_node_address.
2021-11-20 14:36:37 0 [Warning] WSREP: Guessing address for incoming client connections failed. Try setting wsrep_node_incoming_address explicitly.
2021-11-20 14:36:37 0 [Note] WSREP: Node addr:
2021-11-20 14:36:37 0 [Note] InnoDB: Uses event mutexes
2021-11-20 14:36:37 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2021-11-20 14:36:37 0 [Note] InnoDB: Number of pools: 1
2021-11-20 14:36:37 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
2021-11-20 14:36:37 0 [Note] mysqld: O_TMPFILE is not supported on /tmp (disabling future attempts)
2021-11-20 14:36:37 0 [Note] InnoDB: Using Linux native AIO
2021-11-20 14:36:37 0 [Note] InnoDB: Initializing buffer pool, total size = 134217728, chunk size = 134217728
2021-11-20 14:36:37 0 [Note] InnoDB: Completed initialization of buffer pool
2021-11-20 14:36:38 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=2932771735,2932771735
2021-11-20 14:36:44 0 [Note] InnoDB: Starting final batch to recover 231 pages from redo log.
2021-11-20 14:36:47 0 [Note] InnoDB: 128 rollback segments are active.
2021-11-20 14:36:47 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
2021-11-20 14:36:47 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2021-11-20 14:36:47 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2021-11-20 14:36:47 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2021-11-20 14:36:47 0 [Note] InnoDB: 10.5.12 started; log sequence number 2933960231; transaction id 3191906
2021-11-20 14:36:47 0 [Note] InnoDB: Loading buffer pool(s) from /home/bequimao/.local/share/akonadi/db_data/ib_buffer_pool
2021-11-20 14:36:47 0 [Note] Plugin 'FEEDBACK' is disabled.
2021-11-20 14:36:48 1 [Warning] Failed to load slave replication state from table mysql.gtid_slave_pos: 1146: Table 'mysql.gtid_slave_pos' doesn't exist
2021-11-20 14:36:48 0 [Note] Reading of all Master_info entries succeeded
2021-11-20 14:36:48 0 [Note] Added new Master_info '' to hash table
2021-11-20 14:36:48 0 [Note] /usr/sbin/mysqld: ready for connections.
Version: '10.5.12-MariaDB-0+deb11u1'  socket: '/run/user/1000/akonadi/mysql.socket'  port: 0  Debian 11
2021-11-20 14:36:48 4 [ERROR] InnoDB: Table `mysql`.`innodb_table_stats` not found.
2021-11-20 14:36:54 0 [Note] InnoDB: Buffer pool(s) load completed at 211120 14:36:54
bequimao@bullseye-kde:~$
bequimao@bullseye-kde:~$ mysql_upgrade --socket=/run/user/1000/akonadi/mysql.socket -v
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
FATAL ERROR: Can't execute 'mysqlcheck'
bequimao@bullseye-kde:~$
bequimao@bullseye-kde:~$

*** r o o t 

root@bullseye-kde:~# dpkg -l | egrep 'mysql|mariadb|akonadi' | egrep -v libkf5 | sort
ii  akonadi-backend-mysql 4:20.08.3-3 all  MySQL storage backend for Akonadi
ii  akonadiconsole4:20.08.3-1 amd64management and debugging console for akonadi
ii  akonadi-contacts-data 4:20.08.3-1 all  Akonadi contacts access library - data files
ii  akonadi-mime-data 4:20.08.3-1 all  Akonadi MIME handling library - data files
ii  akonadi-server4:20.08.3-3 amd64Akonadi PIM storage service
ii  default-mysql-client-core 1.0.7   all  MySQL database core client binaries (metapackage)
ii  kmailtransport-akonadi:amd64  20.08.3-1   amd64mail transport akonadi library
ii  libmariadb3:amd64 1:10.5.12-0+deb11u1 amd64MariaDB database client library
ii  libqt5sql5-mysql:amd645.15.2+dfsg-9   amd64Qt 5 MySQL database driver
ii  libreoffice-sdbc-mysql1:7.0.4-4+deb11u1   amd64MariaDB/MySQL SDBC driver for LibreOffice
ii  mariadb-client-core-10.5  1:10.5.12-0+deb11u1 amd64MariaDB database core client binaries
ii  mariadb-common1:10.5.12-0+deb11u1 all  MariaDB common configuration files
ii  

Bug#1000271: jupyter-client breaks dask.distributed autopkgtest: ERROR - Workers don't have promised key: ['tcp://127.0.0.1:33937']

[Paul Gevers]

Source: jupyter-client, dask.distributed
Control: found -1 jupyter-client/7.0.6-2
Control: found -1 dask.distributed/2021.09.1+ds.1-2
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 jupyter-client the autopkgtest of 
dask.distributed fails in testing when that autopkgtest is run with the 
binary packages of jupyter-client from unstable. It passes on arm64 and 
ppc64el when run with only packages from testing. In tabular form:


   passfail
jupyter-client from testing7.0.6-2
dask.distributed   from testing2021.09.1+ds.1-2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of jupyter-client to 
testing [1]. Due to the nature of this issue, I filed this bug report 
against both packages. Can you please investigate the situation and 
reassign the bug to the right package?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=jupyter-client

https://ci.debian.net/data/autopkgtest/testing/arm64/d/dask.distributed/16840880/log.gz

=== FAILURES 
===
 test_gather_failing_cnn_error 
_


outer_args = (), kwargs = {}, result = None
coro = ._..test_func..coro 
at 0x0c67d550>


@functools.wraps(func)
def test_func(*outer_args, **kwargs):
result = None
workers = []
with clean(timeout=active_rpc_timeout, 
**clean_kwargs) as loop:
async def 
coro():

with dask.config.set(config):
s = False
for _ in 
range(60):

try:
s, ws = await start_cluster(
nthreads,
scheduler,
loop,
security=security,
Worker=Worker,
scheduler_kwargs=scheduler_kwargs,
worker_kwargs=worker_kwargs,
)
except 
Exception as e:

logger.error(
"Failed to start 
gen_cluster: "


f"{e.__class__.__name__}: 
{e}; 
retrying",

exc_info=True,
)
await 
asyncio.sleep(1)

else:
workers[:] = ws
args = [s] + workers
break
if s is 
False:
raise 
Exception("Could not start 
cluster")

if client:
c = await Client(
s.address,
loop=loop,
security=security,
asynchronous=True,
**client_kwargs,
)
args = [c] + args
try:
future = func(*args, *outer_args, **kwargs)
future = asyncio.wait_for(future, timeout)
result = await future
if s.validate:
s.validate_state()
finally:
if client and 
c.status not in 
("closing", 
"closed"):
await 
c._close(fast=s.status == Status.closed)

await 

Bug#1000270: xfwm4: Whiteout with compositor

[Kyuma Ohta]

Package: xfwm4
Version: 4.16.1-1
Severity: important

Dear Maintainer,

When setting XFWM4 from Xfce4, to use compositor (normally Compton),
screen has made whiteout, not usable anymore.

So, I did logout via both killall xfce4-session  and killall xfconfd
from another console.

Then I set "use_compositing" value to "false" of
~/.config/xfce4/xfconf/xfce-perchannel-xml/xfwm4.xml and re-login Xfce4.

After login, screen is normally again, not be whiteout.

Regards,
Ohta.


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

Kernel: Linux 5.15.0-trunk-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.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 xfwm4 depends on:
ii  libc6 2.32-4
ii  libcairo2 1.16.0-5
ii  libepoxy0 1.5.9-2
ii  libgdk-pixbuf-2.0-0   2.42.6+dfsg-2
ii  libglib2.0-0  2.70.1-1
ii  libgtk-3-03.24.30-3
ii  libpango-1.0-01.48.10+ds1-1
ii  libpangocairo-1.0-0   1.48.10+ds1-1
ii  libstartup-notification0  0.12-6+b1
ii  libwnck-3-0   40.0-2
ii  libx11-6  2:1.7.2-2+b1
ii  libxcomposite11:0.4.5-1
ii  libxdamage1   1:1.1.5-2
ii  libxext6  2:1.3.4-1
ii  libxfce4ui-2-04.16.1-1
ii  libxfce4util7 4.16.0-1
ii  libxfconf-0-3 4.16.0-2
ii  libxfixes31:5.0.3-2
ii  libxinerama1  2:1.1.4-2
ii  libxpresent1  1.0.0-2+b10
ii  libxrandr22:1.5.2-1
ii  libxrender1   1:0.9.10-1
ii  libxres1  2:1.2.0-4

Versions of packages xfwm4 recommends:
ii  librsvg2-common  2.50.7+dfsg-2

Versions of packages xfwm4 suggests:
ii  xfce4  4.16

-- no debconf information

Below is /var/log/Xorg.0.log :

[132949.942] (--) Log file renamed from "/var/log/Xorg.pid-1098868.log" to 
"/var/log/Xorg.0.log"
[132949.943] 
X.Org X Server 1.20.13
X Protocol Version 11, Revision 0
[132949.943] Build Operating System: linux Debian
[132949.943] Current Operating System: Linux melchior 5.15.0-trunk-amd64 #1 SMP 
Debian 5.15.2-1~exp1 (2021-11-14) x86_64
[132949.943] Kernel command line: BOOT_IMAGE=/vmlinuz-5.15.0-trunk-amd64 
root=UUID=8013339a-4a2e-4eaf-b586-171f9a5f62c5 ro amdgpu.deep_color=1 
randomize_kstack_offset=off reset_devices amd_iommu_intr=vapic kvm-amd.avic=1 
x2apic_phys systemd.debug-shell
[132949.943] Build Date: 10 August 2021  09:27:00AM
[132949.943] xorg-server 2:1.20.13-1 (https://www.debian.org/support) 
[132949.943] Current version of pixman: 0.40.0
[132949.943]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[132949.943] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[132949.943] (==) Log file: "/var/log/Xorg.0.log", Time: Sun Nov 21 02:41:38 
2021
[132949.943] (==) Using config file: "/etc/X11/xorg.conf"
[132949.943] (==) Using config directory: "/etc/X11/xorg.conf.d"
[132949.943] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[132949.943] (==) ServerLayout "X.org Configured"
[132949.943] (**) |-->Screen "Screen0" (0)
[132949.943] (**) |   |-->Monitor "Monitor0"
[132949.944] (**) |   |-->Device "Card0"
[132949.944] (**) |   |-->GPUDevice "Card0"
[132949.944] (**) |-->Input Device "Mouse0"
[132949.944] (**) |-->Input Device "Keyboard0"
[132949.944] (**) Option "MaxClients" "512"
[132949.944] (**) Option "IndirectGLX" "true"
[132949.944] (==) Automatically adding devices
[132949.944] (==) Automatically enabling devices
[132949.944] (==) Automatically adding GPU devices
[132949.944] (**) Max clients allowed: 512, resource mask: 0xf
[132949.944] (**) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/cyrillic,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins,
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/cyrillic,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[132949.944] (**) ModulePath set to "/usr/lib/xorg/modules"
[132949.944] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 
'vmmouse' will be disabled.

Bug#999565: transition: fluidsynth

[Dennis Braun]

Heya,

i tested those builds against the new version successfully:

alure
ardour
audacious-plugins
calf
csound
denemo
fluidsynth-dssi
gst-plugins-bad1.0
kodi-audiodecoder-fluidsynth
libdrumstick
libsdl2-mixer
lmms
minuet
mpd
muse
pianobooster
qsynth
swami
tuxguitar
vlc

those 2 had errors:

buzztrax: https://paste.debian.net/1220211/
libtritonus-java: https://paste.debian.net/1220212/

and those 5 i haven't tested so far:

doomsday
freewheeling
doomsday
scummvm
sdl-mixer1.2

Best regards,
Dennis


OpenPGP_signature
Description: OpenPGP digital signature

Bug#997958: Possibly malicious www.kicad-pcb.org domain still linked in kicad's packages.debian.org page

[Carsten Andrich]

Hello Carsten,

On 20.11.21 17:57, Carsten Schoenert wrote:

the package version in bullseye hasn't got a updated version (and wont
get one), so it's normal that the old data from the old package data is
used there.

I plan to upload a backported version 5.1.12 soon to both backports
repositories.


Gotcha. Also noticed that the current experimental version from November 
7th still links the old domain, but I guess the recently tagged upstream 
6.0.0-rc1 could fix that.


Thanks for the prompt response and best regards,
Carsten

Bug#999756: lintian: False positive bashism in posix shell after "exec"

[Rafael Laboissière]

Control: tags -1 + patch

* Rafael Laboissière  [2021-11-16 07:03]:

Litian is triggering bash-term-in-posix-shell warnings (use of "source" 
command) for some files of the plplot package, like this one:


   
https://salsa.debian.org/science-team/plplot/-/blob/master/examples/tcl/x00.in

This is a false positive, because this file contains an "exec" command 
and the "source" command is placed after it.  These are the contents of 
the file above, after substitution by the configure script and after 
stripping away comments and blank lines:


   #!/bin/sh
   exec "/usr/bin/pltcl" -f "$0" ${1+"$@"}
   source x00.tcl
   plinit
   x00
   plend

Lintian should stop looking for bashisms after the exec command.


I propose a very straightforward patch to fix the problem, in the 
following merge request at Salsa: 
https://salsa.debian.org/lintian/lintian/-/merge_requests/383


Rafael Laboissière

Bug#999376: marked as done (python-gmpy2 ftbfs with Python 3.10)

[Martin Kelly]

On 11/19/21 1:45 PM, Debian Bug Tracking System wrote:

Your message dated Fri, 19 Nov 2021 21:40:53 +
with message-id 
and subject line Bug#999376: fixed in python-gmpy2 2.1.0~b5-1
has caused the Debian Bug report #999376,
regarding python-gmpy2 ftbfs with Python 3.10
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)




Sorry, I was in an arm sling after shoulder surgery and unable to easily 
type on my home computer, so I hadn't gotten a chance to update this 
yet. I was about to do so and see you beat me to it. Thank you!

Bug#1000208: ITP: pcmemtest -- stand-alone memory tester

[Stephan Lachnit]

Sounds interesting.

On Fri, Nov 19, 2021 at 8:03 PM  wrote:
>
> I'm happy to maintain it inside a team or with co-maintainer(s).
> I'm only DM so if someone has interest in sponsoring this, feel free to
> contact me.

If you need me as sponsor, ping me when the package is ready for upload.

Regards
Stephan

Bug#1000269: python3-cxx-dev lacks support for Python 3.10

[Adrian Bunk]

Package: python3-cxx-dev
Version: 7.1.4-0.1
Severity: serious
Tags: ftbfs bookworm sid
Control: affects -1 src:pysvn

https://buildd.debian.org/status/logs.php?pkg=pysvn=1.9.12-2%2Bb1

...
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
set -e && for i in 3.10 3.9; do \
cd /<>/Source; python$i setup.py configure \
  --pycxx-src-dir=/usr/share/python$i/CXX \
  --pycxx-dir=/usr/include/python$i \
  --svn-lib-dir=/usr/lib/x86_64-linux-gnu \
  --apr-inc-dir=/usr/include/apr-1.0 \
  --apu-inc-dir=/usr/include/apr-1.0 \
  --apr-lib-dir=/usr/lib/x86_64-linux-gnu \
  --fixed-module-name \
  --platform=linux ; \
mv /<>/Source/Makefile /<>/Source/MakefilePy$i ; \
done
Info: Configure for python 3.10.0 in exec_prefix /usr
Debian lib directory %s
 /usr/lib/x86_64-linux-gnu
Error: Cannot find PyCXX include CXX/Version.hxx - use --pycxx-dir
make[1]: *** [debian/rules:18: override_dh_auto_configure] Error 1

Bug#1000268: ros-ros-comm FTBFS on IPV6-only buildds

[Adrian Bunk]

Source: ros-ros-comm
Version: 1.15.13+ds1-5
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=ros-ros-comm=amd64=1.15.13%2Bds1-5%2Bb1=1637417945=0

...
[roswtf.rosunit-roswtf_command_line_online/test_cmd_help][passed]
[roswtf.rosunit-roswtf_command_line_online/test_offline][FAILURE]---
False is not true : CMD[roswtf] OUTPUT[Package: roswtf
]
stderr[Traceback (most recent call last):
  File "/<>/.pybuild/cpython3_3.10/build/devel/bin/roswtf", line 
15, in 
exec(compile(fh.read(), python_script, 'exec'), context)
  File "/<>/utilities/roswtf/scripts/roswtf", line 35, in 
roswtf.roswtf_main()
  File "", line 89, in roswtf_main
  File "", line 175, in _roswtf_main
  File "/<>/utilities/roswtf/src/roswtf/network.py", line 120, in 
wtf_check
error_rule(r, r[0](ctx), ctx)
  File "/<>/utilities/roswtf/src/roswtf/network.py", line 54, in 
ip_check
resolved_ips = [host[4][0] for host in 
socket.getaddrinfo(socket.gethostname(), 0, socket.AF_INET, 0, socket.SOL_TCP)]
  File "/usr/lib/python3.9/socket.py", line 954, in getaddrinfo
for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno -5] No address associated with hostname
]
  File "/usr/lib/python3.9/unittest/case.py", line 59, in testPartExecutor
yield
  File "/usr/lib/python3.9/unittest/case.py", line 592, in run
self._callTestMethod(testMethod)
  File "/usr/lib/python3.9/unittest/case.py", line 550, in _callTestMethod
method()
  File 
"/<>/utilities/roswtf/test/check_roswtf_command_line_online.py", 
line 120, in test_offline
self._check_output([cmd], output.decode(), err.decode())
  File 
"/<>/utilities/roswtf/test/check_roswtf_command_line_online.py", 
line 130, in _check_output
self.assert_(
  File "/usr/lib/python3.9/unittest/case.py", line 1335, in deprecated_func
return original_func(*args, **kwargs)
  File "/usr/lib/python3.9/unittest/case.py", line 688, in assertTrue
raise self.failureException(msg)



SUMMARY
 * RESULT: FAIL
 * TESTS: 2
 * ERRORS: 0
 * FAILURES: 1
...
dh_auto_test: error: pybuild --test -i python{version} -p "3.10 3.9" 
--before-test "PYTHONPATH={build_dir}/build/devel/lib/python*/dist-packages 
make -C {build_dir} run_tests" --after-test "catkin_test_results {build_dir}" 
returned exit code 13
make[1]: *** [debian/rules:21: override_dh_auto_test] Error 25

Bug#1000208: ITP: pcmemtest -- stand-alone memory tester

[Felix Zielcke]

Am Samstag, dem 20.11.2021 um 10:00 -0500 schrieb Antoine Beaupré:
> On 2021-11-19 19:50:45, fziel...@z-51.de wrote:
> [...]
> 
> >  PCMemTest is a fork and rewrite of Memtest86+, which in turn was a
> > fork of
> >  Memtest86.
> > 
> > 
> > I'm happy to maintain it inside a team or with co-maintainer(s).
> > I'm only DM so if someone has interest in sponsoring this, feel free
> > to
> > contact me.
> 
> Great find! I was disappointed to find out that memtest86* is basically
> unusable these days in Debian, and find this ITP to be very
> interesting!
> Do let me know if you need a sponsor.
> 
> Did you test the program at all? Does it behave better than the
> existing
> memtest86 packages currently in Debian?
> 
> a.

Thanks for your interest :)

I pushed now my first work to my personal salsa profile:

https://salsa.debian.org/fzielcke/pcmemtest

The files are for now in /usr/lib/pcmemtest
There are 32bit and 64bit legacy BIOS + EFI files
Not sure if there's actually a different between the 2 legacy BIOS
versions.

I haven't yet tried it myself but will do soon.
The suggestion came from #btrfs IRC channel. So it can't be that bad.


And I'm not sure how I want to do the GRUB integration. Due to the
differences with 32bit and 64bit EFI.
Is there actually a way to find out with what EFI version the system
booted?

Regards
Felix

Bug#997958: Possibly malicious www.kicad-pcb.org domain still linked in kicad's packages.debian.org page

[Carsten Schoenert]

Hello Carsten,

Am 20.11.21 um 17:33 schrieb Carsten Andrich:
> Hello,
> 
> in the "Links for kicad" section of the packages.debian.org page for 
> kicad [1], the old domain is still listed under "External Resources".

> [1] https://packages.debian.org/bullseye/kicad

the package version in bullseye hasn't got a updated version (and wont
get one), so it's normal that the old data from the old package data is
used there.

I plan to upload a backported version 5.1.12 soon to both backports
repositories.

-- 
Regards
Carsten

Bug#1000266: reportbug-gtk hangs when I try to close it without opening a bug

[Christian Britz]

Package: reportbug-gtk
Version: 11.1.0
Severity: normal
X-Debbugs-Cc: cbr...@t-online.de

Dear Maintainer,

when I try to close reportbug-gtk without opening a bug, the GUI hangs and I
have to kill it.


-- 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-4-amd64 (SMP w/8 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de:en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages reportbug-gtk depends on:
ii  gir1.2-gtk-3.0 3.24.30-3
ii  gir1.2-gtksource-4 4.8.2-1
ii  gir1.2-vte-2.910.66.1-1
ii  python3-gi 3.42.0-1+b1
ii  python3-gi-cairo   3.42.0-1+b1
ii  python3-gtkspellcheck  4.0.5-2
ii  reportbug  11.1.0

reportbug-gtk recommends no packages.

reportbug-gtk suggests no packages.

-- no debconf information

Bug#1000265: typo in fix for CVE-2021-21996 breaks file.managed on stretch

[Jamie Heilman]

Package: salt-common
Version: 2016.11.2+ds-1+deb9u8
Severity: grave

The patch for 994016 in the
/usr/lib/python2.7/dist-packages/salt/fileclient.py file included:

+# clean_path returns an empty string if the check fails
+root_path = salt.utils.path.join(cachedir, "extrn_files", saltenv, 
netloc)

which might work for newer versions of salt, but in stretch that has
to be salt.utils.path_join(...) as the salt.utils.path module didn't
exist yet.  As-is, the security update for CVE-2021-21996 makes
file.managed states fail with:

  Unable to manage file: 'module' object has no attribute 'path'

which makes salt on stretch pretty much unusable.

-- 
Jamie Heilman http://audible.transient.net/~jamie/

Bug#997958: Possibly malicious www.kicad-pcb.org domain still linked in kicad's packages.debian.org page

[Carsten Andrich]

Hello,

in the "Links for kicad" section of the packages.debian.org page for 
kicad [1], the old domain is still listed under "External Resources".


Best regards,
Carsten

[1] https://packages.debian.org/bullseye/kicad

Bug#1000264: RFP: cobang -- QR Code scanner application

[Martin]

Package: wnpp
Severity: wishlist

* Package name: cobang
  Version : 0.9.5
  Upstream Author : Nguyễn Hồng Quân 
* URL or Web page : https://github.com/hongquan/CoBang/
* License : GPL-3+
  Description : QR Code scanner application

Programming Lang: Python

Cỏ bàng can scan barcode, QR code from webcam or static image, local or
remote.

Bug#1000000: fixed in phast 1.6+dfsg-2

[Andreas Tille]

Am Sat, Nov 20, 2021 at 10:30:18AM + schrieb Holger Levsen:
> congrats to the Debian Med team for filing #100 *and* fixing it so 
> quickly!
> well done & well deserved to hit this "special bug" :)

Thanks a lot.  I admit it was not a trivial one but I was motivated to spent
some hours on it (after I was wrong in my first was to simple fix). ;-)

Kind regards

Andreas.

-- 
http://fam-tille.de

Bug#1000263: package broken after php8 upgrade

[VA]

Package: tt-rss
Version: 21~git20210204.b4cbc79+dfsg-1
Severity: serious

Since upgrade from php packages 7.4 to 8.1, tt-rss is unusable. Logs 
contain several occurrences of:


[Sat Nov 20 17:11:06.950555 2021] [php:error] [pid 2895803] [client 
127.0.0.1:40988] PHP Fatal error:  Uncaught ValueError: 
mb_convert_encoding(): Argument #2 ($to_encoding) must be a valid 
encoding, "" given in 
/usr/share/php/php-php-gettext/gettext.inc:181\nStack trace:\n#0 
/usr/share/php/php-php-gettext/gettext.inc(181): 
mb_convert_encoding()\n#1 
/usr/share/php/php-php-gettext/gettext.inc(278): _encode()\n#2 
/usr/share/php/php-php-gettext/gettext.inc(285): _gettext()\n#3 
/usr/share/tt-rss/www/include/functions.php(102): __()\n#4 
/usr/share/tt-rss/www/include/functions.php(141): get_translations()\n#5 
/usr/share/tt-rss/www/classes/userhelper.php(124): startup_gettext()\n#6 
/usr/share/tt-rss/www/index.php(31): UserHelper::login_sequence()\n#7 
{main}\n  thrown in /usr/share/php/php-php-gettext/gettext.inc on line 181


I'm not sure if the culprit is tt-rss or php-php-gettext package.

On https://www.php.net/manual/en/function.mb-convert-encoding.php:

8.0.0 	mb_convert_encoding() will now throw a ValueError when 
to_encoding is passed an invalid encoding.


So, it really is a misusage of mb_convert_encoding() either by tt-rss or 
by php-php-gettext.


php-php-gettext: 1.0.12-4

Bug#1000210: [regression] uscan die: filenamemangle failed

[Yadd]

Le 20/11/2021 à 13:36, Mattia Rizzolo a écrit :
> On Sat, Nov 20, 2021 at 01:14:23PM +0100, Yadd wrote:
>> Le 20/11/2021 à 12:23, Mattia Rizzolo a écrit :
>>> So, effectively, the change broke the specification.
>>
>> It looks like the specification was not good. A filename isn't an URL
> 
> Be that as it may, we can't break something like that without a version
> bump, IMHO.
> 
> So we need a different fix for #993585.
> 
> Either way, I think it's unrelated to your discovery that it could
> potentially overwrite a file, isn't it?

Sure, I had this bug for a while without understanding what happens
until rouca found it

Bug#948346: X not starting because of xdm log rotation

[Richmond]

Hi,

I had this problem too, and worked around it:

Configure logrotate /etc/logrotate.d/xdm remove weekly and put
size=1G
 

Bug#1000208: ITP: pcmemtest -- stand-alone memory tester

[Antoine Beaupré]

On 2021-11-19 19:50:45, fziel...@z-51.de wrote:
[...]

>  PCMemTest is a fork and rewrite of Memtest86+, which in turn was a fork of
>  Memtest86.
>
>
> I'm happy to maintain it inside a team or with co-maintainer(s).
> I'm only DM so if someone has interest in sponsoring this, feel free to
> contact me.

Great find! I was disappointed to find out that memtest86* is basically
unusable these days in Debian, and find this ITP to be very interesting!
Do let me know if you need a sponsor.

Did you test the program at all? Does it behave better than the existing
memtest86 packages currently in Debian?

a.
-- 
We have to talk about liberating minds as well as liberating society.
- Angela Davis

Bug#990316: Make IME support enabled by default in kitty

[Gunnar Hjalmarsson]

On 2021-11-20 15:37, Osamu Aoki wrote:

Since kitty has kitty.conf, a non-confrontational approach may be a
patch to add one configuration option in kitty.conf to enable ibus.
So ibus support is still opt-in feature.  If James doesn't want to go
along with Gunnar's suggestion, this may be a alternative path
forward.


I also thought about using kitty.conf. Alternatively that would allow 
for an opt-out option.


In any case we seem to be agreed that this is a pure kitty matter.

--
Thanks!
Gunnar

Bug#1000262: bluez: CVE-2021-41229: memory leak in the SDP protocol handling

[Salvatore Bonaccorso]

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

Hi,

The following vulnerability was published for bluez.

CVE-2021-41229[0]:
| BlueZ is a Bluetooth protocol stack for Linux. In affected versions a
| vulnerability exists in sdp_cstate_alloc_buf which allocates memory
| which will always be hung in the singly linked list of cstates and
| will not be freed. This will cause a memory leak over time. The data
| can be a very large object, which can be caused by an attacker
| continuously sending sdp packets and this may cause the service of the
| target device to crash.


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-41229
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-41229
[1] https://github.com/bluez/bluez/security/advisories/GHSA-3fqg-r8j5-f5xq
[2] 
https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=e79417ed7185b150a056d4eb3a1ab528b91d2fc0

Regards,
Salvatore

Bug#983871: [Pkg-libvirt-maintainers] Bug#983871: error: internal error: failed to get cgroup backend for 'pathOfController'

[Jonas Schäfer]

Hi,

On Mittwoch, 17. November 2021 23:24:14 CET you wrote:
> > I did another test by pinning the bookworm packages (7.6.0-1) and testing
> > those. They exhibit the same behaviour as the patched libvirt, that is: in
> > some cases, virsh destroy will show an error, but the container will be
> > removed cleanly nonetheless.
> 
> That's kind of odd, the version in bookworm should fix this issue because
> it has been fixed on upstream version 7.3.0. And I can't reproducible this
> bug again because I don't use LXC on libvirt quite heavily.

So I did more tests. I ran a destroy/create loop on a bookworm box. However, 
due to time constraints, I wasn't able set up any complex thing inside the 
container, so it's possible that that skewed the results. In these tests, I 
was not able to reproduce the issue. To me: that indicates one of two things:

(a) The second issue can only occur with LXC and with reasonably complex 
guests -- I think that is not unrealistic because we're talking nested cgroups 
here, which wouldn't occur with qemu or with simple containers.

(b) The second issue only occurs on boxes which mix bookworm (or patched 
libvirt) and bullseye in undefined ways.

Unfortunately, I currently do not have a test system with complex containers 
at hand which I can upgrade to bookworm on the spot.

kind regards,
Jonas

Bug#990316: Make IME support enabled by default in kitty

[Osamu Aoki]

Hi,

On Sat, 2021-11-20 at 12:59 +0100, Gunnar Hjalmarsson wrote:
> Control: reassign -1 kitty 0.19.3-1
> Control: retitle -1 Make IME support enabled by default in kitty
> Control: tags -1 - moreinfo
> X-Debbugs-Cc: debian-input-met...@lists.debian.org,james...@debian.org
> 
> Hi again,
> 
> I have reassigned this bug from im-config to kitty.
> 
> @James: Does my idea in  make sense 
> to you?

Thanks Gunnar,

I actually tried kitty and read its manpage after recent exchanges.

This is very interesting terminal program indeed.

If I understand correctly, upstream chose to disable ibus feature if 
GLFW_IM_MODULE
is not set to ibus.  So ibus is opt-in feature. Reverting that feature choice 
is one
option for Debian maintainer can do indeed.  This is a risky path most 
maintainers
hesitate.

Since kitty has kitty.conf, a non-confrontational approach may be a patch to 
add one
configuration option in kitty.conf to enable ibus.  So ibus support is still 
opt-in
feature.  If James doesn't want to go along with Gunnar's suggestion, this may 
be a
alternative path forward.

Regards,

Osamu

Bug#1000235: 0ad: Ignore parallel jobs limit during building

[Ludovic Rousseau]

Le 20/11/2021 à 01:48, Boyuan Yang a écrit :

Source: 0ad
Severity: important
Version: 0.0.25b-1
X-Debbugs-CC: vch...@debian.org rouss...@debian.org

Dear 0ad package maintainers,


Hello,


https://sources.debian.org/src/0ad/0.0.25b-1/debian/rules/#L15 :

PARALLEL_JOBS=$(shell getconf _NPROCESSORS_ONLN)
ifeq ($(findstring parallel=,$(DEB_BUILD_OPTIONS)),)
export DEB_BUILD_OPTIONS+=parallel=$(PARALLEL_JOBS)
endif

This really does not make sense; specifying parallel jobs to be the same as
CPU core number will override -j parameter passed to dpkg-buildpackage and
external DEB_BUILD_OPTIONS environment variable (if defined), which may cause
troubles. For example, when preparing backport build for 0ad, my build machine
OOMed due to having too many CPU cores but limited RAM.


Exact.
parallel (or not) compilation should now be handled by dpkg-buildpackage.

Thanks for the bug report.

Bye

--
Dr. Ludovic Rousseau

Bug#999826: debian-policy: fix Build-Depends footnote

[Bill Allombert]

On Sat, Nov 20, 2021 at 01:24:28PM +, Holger Levsen wrote:
> On Wed, Nov 17, 2021 at 03:11:55PM +0100, Johannes Schauer Marin Rodrigues 
> wrote:
> > > This footnote might not be the best place to document the precise 
> > > behaviour
> > > of autobuilders (which currently is outside the scope of policy). On the
> > > other hand, having a fully specified build process could reduce build
> > > variability and make builds more reproducible.
> > Do you have suggestions for a better place to document this?
> 
> src:developers-reference maybe? with a pointer to it in -policy?

We need the input of the people on charge of writing the autobuilders
code.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1000261: RM: sepp/experimental -- ROM; architectures wrongly set to "all" instead of "any"

[Pierre Gruet]

Package: ftp.debian.org
Severity: normal

Hello,

When working on sepp in experimental, I wrongly set the architecture of
version 4.5.1+really4.5.1+dfsg-1~exp1 to "all", it should have been "any".

Since then, version 4.5.1+really4.5.1+dfsg-2 has been uploaded to unstable with
the right architecture. But the version in experimental did not get removed
because the set of architectures was not the same.

Could you please proceed to the removal of
sepp 4.5.1+really4.5.1+dfsg-1~exp1 from experimental?

Thanks a lot for your help,

Best regards,

-- 
Pierre

Bug#1000024: cppcheck: depends on obsolete pcre3 library

[Joachim Reichel]

forwarded 124 https://trac.cppcheck.net/ticket/10610#ticket
thanks

Hi Matthew,

I created an upstream feature request at 
https://trac.cppcheck.net/ticket/10610#ticket . As last resort we could also 
build cppcheck without dependency on PCRE by disabled rules support.


Best regards,
  Joachim

Bug#976811: transition: php8.1

[Paul Gevers]

Hi Ondřej,

On 19-11-2021 21:41, Ondřej Surý wrote:

I disagree, but I uploaded reverted package. It’s after release and we have two 
years before next release and a year before PHP 8.2, so unstable could be a bit 
unstable. It’s not like the bump from php7.4 to php8.1 is that large as it was 
from php5.6 to php7.0.


Thanks for your willingness to cooperate, even though you don't agree. 
And sorry the way I phrased my response yesterday. I was too surprised 
and one of "my" packages got broken (see the cacti autopkgtest results). 
(I knew this from your previous upload to experimental, but had 
forgotten about it and I haven't seen a bug report about it yet). I 
feared (without proper checking, I should have done that) that cacti 
wouldn't be the only one broken without warning. (I'll handle cacti 
shortly, its new upstream release should at least work with php 8.0).



The transition to php8.x has been announced a year ago.


To the release team, yes, but how about the affected packages 
maintainers? And how about *coordinating* a transition? That's where 
transition bug are for [1]. If you tell us when you're ready to start a 
transition, we can tell you when it fits in all the other transitions. 
There are enough collisions mentioned on the transition page [1] to 
warrant an ACK from the release team before going ahead.


In this particular case, we would have asked if bugs had been filed for 
all reverse dependencies that are known to be broken. As mention above 
at least cacti is missing such a bug report. Maybe there are more? As 
mentioned by David, it would be helpful to have an upload to 
experimental doing the bump there. So issues can be weed out before the 
transition starts.


Paul

[1] https://wiki.debian.org/Teams/ReleaseTeam/Transitions
[2] https://release.debian.org/transitions/html/php8.1.html



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1000260: python3-ptyprocess: should this package be visible with pip3 list?

[Jörg-Volker Peetz]

Package: python3-ptyprocess
Version: 0.7.0-1
Severity: wishlist
X-Debbugs-Cc: none, J-V Peetz 

Dear Debian Python Team,

I just wanted to ask if this python package, and may be all installed,
should appear in the list delivered by the command

  python3 -m pip list

In consequence, the command

  python3 -m pip check

results in the message

  terminado 0.12.1 requires ptyprocess, which is not installed.

Many thanks for your work on the python modules packages.

Regards,
Jörg.


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

Kernel: Linux 5.15.2 (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: sysvinit (via /sbin/init)

Versions of packages python3-ptyprocess depends on:
ii  python3  3.9.8-1

python3-ptyprocess recommends no packages.

python3-ptyprocess suggests no packages.

-- no debconf information

Bug#999826: debian-policy: fix Build-Depends footnoteo

[Holger Levsen]

On Wed, Nov 17, 2021 at 03:11:55PM +0100, Johannes Schauer Marin Rodrigues 
wrote:
> > This footnote might not be the best place to document the precise behaviour
> > of autobuilders (which currently is outside the scope of policy). On the
> > other hand, having a fully specified build process could reduce build
> > variability and make builds more reproducible.
> Do you have suggestions for a better place to document this?

src:developers-reference maybe? with a pointer to it in -policy?


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

:wq


signature.asc
Description: PGP signature

Bug#999397: siphashc: diff for NMU version 2.1-0.1

[Stefano Rivera]

Control: tags 999397 + patch

Dear maintainer,

I've prepared an NMU for siphashc (versioned as 2.1-0.1). The diff
is attached to this message.

Regards.

SR
diff -Nru siphashc-1.2/appveyor.yml siphashc-2.1/appveyor.yml
--- siphashc-1.2/appveyor.yml	2018-10-04 06:47:17.0 -0400
+++ siphashc-2.1/appveyor.yml	1969-12-31 20:00:00.0 -0400
@@ -1,33 +0,0 @@
-version: "{build}"
-
-clone_depth: 100
-
-environment:
-  matrix:
-- PYTHON: "C:\\Python27"
-- PYTHON: "C:\\Python33"
-- PYTHON: "C:\\Python34"
-- PYTHON: "C:\\Python35"
-- PYTHON: "C:\\Python36"
-- PYTHON: "C:\\Python36-x64"
-
-install:
-  - "SET PATH=%PYTHON%;%PYTHON%\\Scripts;%PATH%"
-  # We need wheel installed to build wheels
-  - "python.exe -m pip install wheel"
-
-build_script:
-  # Build the compiled extension
-  - "python setup.py build"
-
-test_script:
-  # Run the project tests
-- "python setup.py test"
-- "python benchmark.py"
-
-after_test:
-  - "python.exe setup.py bdist_wheel"
-
-artifacts:
-  # bdist_wheel puts your built wheel in the dist directory
-  - path: dist\*
diff -Nru siphashc-1.2/benchmark.py siphashc-2.1/benchmark.py
--- siphashc-1.2/benchmark.py	2018-10-04 06:47:17.0 -0400
+++ siphashc-2.1/benchmark.py	2020-09-02 04:05:03.0 -0400
@@ -1,17 +1,17 @@
 #!/usr/bin/env python
-"""Simple timing benchmark.
+"""
+Simple timing benchmark.
+
+Used for testing possible regressions when changing code.
+"""
 
-Used for testing possible regressions when changing code."""
-from __future__ import print_function
 import timeit
 
-print('Benchmark (short):')
-print(timeit.timeit(
-"siphash('0123456789ABCDEF', 'a')",
-"from siphashc import siphash"
-))
-print('Benchmark (long):')
-print(timeit.timeit(
-"siphash('0123456789ABCDEF', 'a' * 1000)",
-"from siphashc import siphash"
-))
+print("Benchmark (short):")
+print(timeit.timeit("siphash('0123456789ABCDEF', 'a')", "from siphashc import siphash"))
+print("Benchmark (long):")
+print(
+timeit.timeit(
+"siphash('0123456789ABCDEF', 'a' * 1000)", "from siphashc import siphash"
+)
+)
diff -Nru siphashc-1.2/CHANGES.rst siphashc-2.1/CHANGES.rst
--- siphashc-1.2/CHANGES.rst	2018-10-04 06:47:17.0 -0400
+++ siphashc-2.1/CHANGES.rst	2020-09-02 04:05:03.0 -0400
@@ -1,6 +1,22 @@
 Changes
 ===
 
+2.1
+---
+
+* Fixed publishing wheels in pypi.org.
+
+2.0
+---
+
+* Dropped support for Python 2.
+
+1.3
+---
+
+* Changed license to ISC.
+* Fixed depreciation warning on Python 3.8.
+
 1.2
 ---
 
diff -Nru siphashc-1.2/debian/changelog siphashc-2.1/debian/changelog
--- siphashc-1.2/debian/changelog	2019-01-25 13:02:55.0 -0400
+++ siphashc-2.1/debian/changelog	2021-11-20 09:10:26.0 -0400
@@ -1,3 +1,11 @@
+siphashc (2.1-0.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * New upstream release.
+  * Add watch file.
+
+ -- Stefano Rivera   Sat, 20 Nov 2021 09:10:26 -0400
+
 siphashc (1.2-1) unstable; urgency=medium
 
   * Initial release (Closes: #892182)
diff -Nru siphashc-1.2/debian/watch siphashc-2.1/debian/watch
--- siphashc-1.2/debian/watch	1969-12-31 20:00:00.0 -0400
+++ siphashc-2.1/debian/watch	2021-11-20 09:08:43.0 -0400
@@ -0,0 +1,4 @@
+version=4
+opts="filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%@PACKAGE@-$1.tar.gz%" \
+ https://github.com/WeblateOrg/siphashc/tags \
+ (?:.*?/)?v?(\d[\d.]*)\.tar\.gz
diff -Nru siphashc-1.2/.github/dependabot.yml siphashc-2.1/.github/dependabot.yml
--- siphashc-1.2/.github/dependabot.yml	1969-12-31 20:00:00.0 -0400
+++ siphashc-2.1/.github/dependabot.yml	2020-09-02 04:05:03.0 -0400
@@ -0,0 +1,17 @@
+# This file is generated in https://github.com/WeblateOrg/meta/
+version: 2
+updates:
+  - package-ecosystem: github-actions
+directory: /
+schedule:
+  interval: daily
+labels:
+  - dependencies
+  - automerge
+  - package-ecosystem: pip
+directory: /
+schedule:
+  interval: daily
+labels:
+  - dependencies
+  - automerge
diff -Nru siphashc-1.2/.github/FUNDING.yml siphashc-2.1/.github/FUNDING.yml
--- siphashc-1.2/.github/FUNDING.yml	1969-12-31 20:00:00.0 -0400
+++ siphashc-2.1/.github/FUNDING.yml	2020-09-02 04:05:03.0 -0400
@@ -0,0 +1,4 @@
+# This file is maintained in https://github.com/WeblateOrg/meta/
+github: [nijel]
+custom: https://weblate.org/donate/
+liberapay: Weblate
diff -Nru siphashc-1.2/.github/.kodiak.toml siphashc-2.1/.github/.kodiak.toml
--- siphashc-1.2/.github/.kodiak.toml	1969-12-31 20:00:00.0 -0400
+++ siphashc-2.1/.github/.kodiak.toml	2020-09-02 04:05:03.0 -0400
@@ -0,0 +1,9 @@
+# This file is maintained in https://github.com/WeblateOrg/meta/
+# Configuration for https://kodiakhq.com/
+version = 1
+
+[merge]
+method = "rebase"
+
+[update]
+ignored_usernames = ["dependabot", "weblate"]
diff -Nru siphashc-1.2/.github/labels.yml siphashc-2.1/.github/labels.yml
--- siphashc-1.2/.github/labels.yml	1969-12-31 

Bug#992003: [Debian-science-sagemath] Singular update

[Jerome BENOIT]

On my way, cheers, Jerome
On Sat, 20 Nov 2021 12:34:06 + Dima Pasechnik  wrote:

On Sat, 20 Nov 2021, 08:08 Tobias Hansen,  wrote:

> Hi Jerome,
>
> any chance we could get an update of singular to 4.2.1.p0 in experimental?
> I tried to do it myself once but the package has many patches and it was
> difficult to get everything right.
>

4.2.1.p2 is already there:
https://trac.sagemath.org/ticket/32907


> Best,
>
> Tobias
>
>
> ___
> Debian-science-sagemath mailing list
> debian-science-sagem...@alioth-lists.debian.net
>
> 
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-sagemath
>


--
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1000082: glib2.0: depends on obsolete pcre3 library

[Andreas Henriksson]

Hello,

My 2c is that what will likely happen is that glib upstream declares
GRegex deprecated (since porting it to pcre2 will also be an ABI break
AIUI). The soname will stay the same and downstreams will have to decide
if they offer the GRegex symbols or not (or possibly runtime linking of
pcre3 if it's available).

I think the likely way to get rid of glib dep on pcre3 is to start with
a MBF against all GRegex consumers and ask them to move to pcre(2).

(Once we no longer have any in-archive users of GRegex I bet some people
will want to argue the case for keeping it because of out-of-archive
software might still use it.)

Someone will need to offer to do the MBF which likely also comes with
taking on the work to write some kind of porting guide.

Regards,
Andreas Henriksson

Bug#992003: [Debian-science-sagemath] Singular update

[Dima Pasechnik]

On Sat, 20 Nov 2021, 08:08 Tobias Hansen,  wrote:

> Hi Jerome,
>
> any chance we could get an update of singular to 4.2.1.p0 in experimental?
> I tried to do it myself once but the package has many patches and it was
> difficult to get everything right.
>

4.2.1.p2 is already there:
https://trac.sagemath.org/ticket/32907


> Best,
>
> Tobias
>
>
> ___
> Debian-science-sagemath mailing list
> debian-science-sagem...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-sagemath
>

Bug#1000210: [regression] uscan die: filenamemangle failed

[Mattia Rizzolo]

On Sat, Nov 20, 2021 at 01:14:23PM +0100, Yadd wrote:
> Le 20/11/2021 à 12:23, Mattia Rizzolo a écrit :
> > So, effectively, the change broke the specification.
> 
> It looks like the specification was not good. A filename isn't an URL

Be that as it may, we can't break something like that without a version
bump, IMHO.

So we need a different fix for #993585.

Either way, I think it's unrelated to your discovery that it could
potentially overwrite a file, isn't it?

-- 
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#1000210: [regression] uscan die: filenamemangle failed

[Yadd]

Le 20/11/2021 à 12:23, Mattia Rizzolo a écrit :
> Yadd:
> 
> Looking better, I think we do have a small problem here:
> 
> On Fri, Nov 19, 2021 at 08:16:37PM +0100, Michael Biebl wrote:
>> uscan info: Looking at $base = 
>> https://github.com/systemd/systemd-stable/tags with
>> $filepattern = .*/v?(\d\S*)\.tar\.gz found
>> $newfile = 
>> https://github.com/systemd/systemd-stable/archive/refs/tags/v249.7.tar.gz
>> $newversion  = 249.7
>> $lastversion = 249.6
>> uscan info: Matching target for downloadurlmangle: 
>> https://github.com/systemd/systemd-stable/archive/refs/tags/v249.7.tar.gz
>> uscan info: Upstream URL(+tag) to download is identified as
>> https://github.com/systemd/systemd-stable/archive/refs/tags/v249.7.tar.gz
>> uscan info: Matching target for filenamemangle: v249.7.tar.gz
>> uscan die: filenamemangle failed for v249.7.tar.gz at 
>> /usr/share/perl5/Devscripts/Uscan/Output.pm line 60.
> ...
>> uscan info: Looking at $base = 
>> https://github.com/systemd/systemd-stable/tags with
>> $filepattern = .*/v?(\d\S*)\.tar\.gz found
>> $newfile = 
>> https://github.com/systemd/systemd-stable/archive/refs/tags/v249.7.tar.gz
>> $newversion  = 249.7
>> $lastversion = 249.6
>> uscan info: Matching target for downloadurlmangle: 
>> https://github.com/systemd/systemd-stable/archive/refs/tags/v249.7.tar.gz
>> uscan info: Upstream URL(+tag) to download is identified as
>> https://github.com/systemd/systemd-stable/archive/refs/tags/v249.7.tar.gz
>> uscan info: Matching target for filenamemangle: 
>> https://github.com/systemd/systemd-stable/archive/refs/tags/v249.7.tar.gz
>> uscan info: Filename (filenamemangled) for downloaded file: 
>> systemd-249.7.tar.gz
> 
> 
> I went to better read the relevant documentation:
> 
>filenamemangle=rules
>Generate the upstream tarball filename from the selected href
>string if matching-pattern can extract the latest upstream
>version  from the selected href string.  Otherwise,
>generate the upstream tarball filename from its full URL
>string and set the missing  from the generated
>upstream tarball filename.
> 
> That text is very confusing to me, but it does say that the rules, in
> some cases, are matched against the full URL.
> 
> In particular, it means that any matching-pattern that has ".*" as
> leading characters will most likely have a full URL here to match
> against.
> 
> 
> So, effectively, the change broke the specification.

It looks like the specification was not good. A filename isn't an URL

> This apparently came as a result to https://bugs.debian.org/993585 -
> which was really complaining about pgpsigurlmangle but it ended up
> affecting filenamemangle too.
> 
> In fact, I believe reverting 9e65c07737425748e396291d9c20442d11b0641b
> fixes this bug, but probably reopens that other one.

Bug#998344: llvm-toolchain-11 11.0.1-2~deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 998344 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: llvm-toolchain-11
Version: 11.0.1-2~deb10u1

Explanation: new package, backported from Debian 11, to help build new rust 
versions

Bug#1000200: reportbug-gtk: cannot close reportbug (on fluxbox)

[nis . martensen]

control: tags -1 moreinfo


Michael Hatzold hat am 19.11.2021 geschrieben:
> When using reportbug-gtk I now cannot close it (the window) anymore, not even
> after sending the email.  I can minimize it, but not close. I have to open a 
> VT
> and pkill or ctrl-C it (when opened in a VT)
> 
> It used to work, and klicking the "x" in the title bar should close it.

Does this happen in all stages of the graphical dialog from the initial welcome 
screen to the last thank you screen?

Does the problem also occur when you use some other window manager or desktop 
environment, or is the problem specific to fluxbox? Do you observe similar 
issues with other GTK applications?

Since you say it used to work, can you try to narrow down when it stopped 
working? Which specific change triggered the difference between working and not 
working? Was there an upgrade of some particular package involved?

Bug#990316: Make IME support enabled by default in kitty

[Gunnar Hjalmarsson]

Control: reassign -1 kitty 0.19.3-1
Control: retitle -1 Make IME support enabled by default in kitty
Control: tags -1 - moreinfo
X-Debbugs-Cc: debian-input-met...@lists.debian.org,james...@debian.org

Hi again,

I have reassigned this bug from im-config to kitty.

@James: Does my idea in  make sense 
to you?


--
Cheers,
Gunnar Hjalmarsson

Bug#1000196: reportbug-gtk: incomplete and thus wrong message after sending re-opend tmp file

[nis . martensen]

control: tags -1 moreinfo

Michael Hatzold hat am 19.11.2021 geschrieben:
> Due to SMTP overload reportbug saved the report to a tmp file.
> 
> Sending the report based on the re-opened tmp file resulted in a message along
> the lines: "bug report written to tmp file etc ...", but nothing about "file
> successfully sent". This gives you the impression, the file was *not* sent. So
> I re-tried until the SMTP answer stopped me 
> 
>* What outcome did you expect instead?
> Please give a informative feedback (file successfully sent and written to)

Please provide the necessary information that could allow us to understand and 
reproduce the bug:
 - What is your reportbug configuration?
 - How did you invoke reportbug? (complete and exact command line, please)
 - Does the problem also occur if you use the text interface? Or are you saying 
this is a specific problem with the GTK interface?
 - How did you check whether the mail was sent? What do you mean by "SMTP 
answer stopped me"?

Since the build-in report submission support provides only basic functionality, 
you might want to look into reportbug's MUA integration feature for a better 
user experience.

Bug#1000259: RM: gnome-mime-data -- RoQA; orphaned, dead upstream for 10+ years, no longer used

[Simon McVittie]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: gnome-mime-d...@packages.debian.org

gnome-mime-data seems to have been the equivalent of shared-mime-info for
the old gnome-vfs framework, which is no longer maintained or part of GNOME
(since GNOME 3.0 in 2011, maybe earlier) and was already removed from Debian.

All modern GNOME versions use freedesktop.org mechanisms involving
shared-mime-info, the same as other major desktop environments.

According to `dak rm -R -n gnome-mime-data`, nothing depends on
gnome-mime-data any more. Please remove it.

Thanks,
smcv

Bug#1000210: [regression] uscan die: filenamemangle failed

[Mattia Rizzolo]

Yadd:

Looking better, I think we do have a small problem here:

On Fri, Nov 19, 2021 at 08:16:37PM +0100, Michael Biebl wrote:
> uscan info: Looking at $base = https://github.com/systemd/systemd-stable/tags 
> with
> $filepattern = .*/v?(\d\S*)\.tar\.gz found
> $newfile = 
> https://github.com/systemd/systemd-stable/archive/refs/tags/v249.7.tar.gz
> $newversion  = 249.7
> $lastversion = 249.6
> uscan info: Matching target for downloadurlmangle: 
> https://github.com/systemd/systemd-stable/archive/refs/tags/v249.7.tar.gz
> uscan info: Upstream URL(+tag) to download is identified as
> https://github.com/systemd/systemd-stable/archive/refs/tags/v249.7.tar.gz
> uscan info: Matching target for filenamemangle: v249.7.tar.gz
> uscan die: filenamemangle failed for v249.7.tar.gz at 
> /usr/share/perl5/Devscripts/Uscan/Output.pm line 60.
...
> uscan info: Looking at $base = https://github.com/systemd/systemd-stable/tags 
> with
> $filepattern = .*/v?(\d\S*)\.tar\.gz found
> $newfile = 
> https://github.com/systemd/systemd-stable/archive/refs/tags/v249.7.tar.gz
> $newversion  = 249.7
> $lastversion = 249.6
> uscan info: Matching target for downloadurlmangle: 
> https://github.com/systemd/systemd-stable/archive/refs/tags/v249.7.tar.gz
> uscan info: Upstream URL(+tag) to download is identified as
> https://github.com/systemd/systemd-stable/archive/refs/tags/v249.7.tar.gz
> uscan info: Matching target for filenamemangle: 
> https://github.com/systemd/systemd-stable/archive/refs/tags/v249.7.tar.gz
> uscan info: Filename (filenamemangled) for downloaded file: 
> systemd-249.7.tar.gz


I went to better read the relevant documentation:

   filenamemangle=rules
   Generate the upstream tarball filename from the selected href
   string if matching-pattern can extract the latest upstream
   version  from the selected href string.  Otherwise,
   generate the upstream tarball filename from its full URL
   string and set the missing  from the generated
   upstream tarball filename.

That text is very confusing to me, but it does say that the rules, in
some cases, are matched against the full URL.

In particular, it means that any matching-pattern that has ".*" as
leading characters will most likely have a full URL here to match
against.


So, effectively, the change broke the specification.

This apparently came as a result to https://bugs.debian.org/993585 -
which was really complaining about pgpsigurlmangle but it ended up
affecting filenamemangle too.

In fact, I believe reverting 9e65c07737425748e396291d9c20442d11b0641b
fixes this bug, but probably reopens that other one.


-- 
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#992003: [Debian-science-sagemath] Singular update

[Torrance, Douglas]

On Sat 20 Nov 2021 02:50:55 AM EST, Tobias Hansen  wrote:

any chance we could get an update of singular to 4.2.1.p0 in experimental? I 
tried to do it myself once but the package has many patches and it was 
difficult to get everything right.


I'm also interested in getting singular 4.2.x in Debian, as Macaulay2 requires
it as well.  (Fortunately, it still works with 4.1.x with a patch, but upstream
claims it's buggy.)

Doug


signature.asc
Description: PGP signature

Bug#990662: nouveau 0000:01:00.0: firmware: failed to load nouveau/nvd9_fuc084 (-2)

[Sven Joachim]

On 2021-07-04 09:36 +0200, Mathieu Malaterre wrote:

> Package: firmware-misc-nonfree
> Version: 20210315-2~bpo10+1
>
> It would be super nice to distribute the nividia/nouveau firmware in
> firmware-misc-nonfree.

There are two classes of firmware for NVidia cards: official ones from
NVidia for newer cards which is already included in
firmware-misc-nonfree and placed under /lib/fimware/nvidia, and firmware
for older cards which is not distributable but needs to be extracted
from the non-free driver and is put under /lib/firmware/nouveau.  This
firmware can be useful for video decoding, but is not necessary for other
operations.

https://nouveau.freedesktop.org/VideoAcceleration.html

> Right now symptoms are:
> [127020.582478] nouveau :01:00.0: firmware: failed to load
> nouveau/nvd9_fuc084 (-2)
> [127020.582481] firmware_class: See https://wiki.debian.org/Firmware
> for information about missing firmware
> [127020.582482] nouveau :01:00.0: Direct firmware load for
> nouveau/nvd9_fuc084 failed with error -2
> [127020.582487] nouveau :01:00.0: firmware: failed to load
> nouveau/nvd9_fuc084d (-2)
> [127020.582488] nouveau :01:00.0: Direct firmware load for
> nouveau/nvd9_fuc084d failed with error -2
> [127020.582489] nouveau :01:00.0: msvld: unable to load firmware data
> [127020.582491] nouveau :01:00.0: msvld: init failed, -19
> [127064.484342] nouveau :01:00.0: firmware: failed to load
> nouveau/nvd9_fuc084 (-2)
> [127064.484353] nouveau :01:00.0: Direct firmware load for
> nouveau/nvd9_fuc084 failed with error -2
> [127064.484375] nouveau :01:00.0: firmware: failed to load
> nouveau/nvd9_fuc084d (-2)
> [127064.484380] nouveau :01:00.0: Direct firmware load for
> nouveau/nvd9_fuc084d failed with error -2
> [127064.484384] nouveau :01:00.0: msvld: unable to load firmware data
> [127064.484389] nouveau :01:00.0: msvld: init failed, -19
>
> Reference:
>
> https://build.opensuse.org/package/view_file/hardware/nvidia-firmware-installer/nvidia-firmware-installer.spec?expand=1
> https://raw.githubusercontent.com/envytools/firmware/master/extract_firmware.py

Since the firmware is not distributable as-is, it cannot be put into
firmware-misc-nonfree (or any other package).  What could be done is to
package an installer in contrib.  Would you like to do that?

Cheers,
   Sven

Bug#1000258: python3-pil: python 3.10: ImportError: cannot import name '_imaging' from 'PIL'

[Romain Porte]

Package: python3-pil
Version: 8.3.2-1
Severity: normal
X-Debbugs-Cc: deb...@microjoe.org

Dear Maintainer,

Since Python 3.10 has been introduced in Debian, I cannot build packages
that Build-Depends on python3-pil:

Python 3.10.0+ (default, Nov 17 2021, 06:49:13) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from PIL import Image
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/PIL/Image.py", line 114, in 
from . import _imaging as core
ImportError: cannot import name '_imaging' from 'PIL' 
(/usr/lib/python3/dist-packages/PIL/__init__.py)
>>>

However it still works fine with Python 3.9:

Python 3.9.9 (main, Nov 16 2021, 10:24:31)
[GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from PIL import Image
>>>

Best regards.

-- 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/4 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 python3-pil depends on:
ii  libc62.32-4
ii  libfreetype6 2.11.0+dfsg-1
ii  libimagequant0   2.12.2-1.1
ii  libjpeg62-turbo  1:2.1.1-2
ii  liblcms2-2   2.12~rc1-2
ii  libopenjp2-7 2.4.0-3
ii  libraqm0 0.7.0-4
ii  libtiff5 4.3.0-2
ii  libwebp6 0.6.1-2.1
ii  libwebpdemux20.6.1-2.1
ii  libwebpmux3  0.6.1-2.1
ii  libxcb1  1.14-3
ii  mime-support 3.66
ii  python3  3.9.8-1
ii  python3-pil.imagetk  8.3.2-1
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages python3-pil recommends:
ii  python3-olefile  0.46-3

Versions of packages python3-pil suggests:
pn  python-pil-doc  

-- no debconf information

Bug#1000000: fixed in phast 1.6+dfsg-2

[Holger Levsen]

congrats to the Debian Med team for filing #100 *and* fixing it so quickly!
well done & well deserved to hit this "special bug" :)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Words may inspire but only action creates change.


signature.asc
Description: PGP signature

Bug#996461: nvidia-kernel-dkms: DKMS tree already contains: nvidia-current-470.74

[Drew Parsons]

On 2021-11-20 10:31, Drew Parsons wrote:


I see 3 workarounds

1) create a symlink from dkms.key to mok.priv and dkms.der to mok.der.

2) Create a separate dkms.key.  Not so convenient to have 2 keys
though (though I could just stop using mok.der)

3) Comment out sign_tool in /etc/dkms/framework.conf, and sign
manually.  A little inelegant for dkms, but otherwise easy.

1) or 3) would seem simplest to do, but strangely neither of them
fixes the final problem. Still gives the same error, "DKMS tree
already contains: nvidia-current-470.86. You cannot add the same
module/version combo more than once."
Not sure if it would work after nvidia purge/reinstall. Or if it needs 
a reboot.



This error is pervasive.

I've reconfigured to follow the dkms instructions at 
/usr/share/doc/dkms/README.md.gz, just using /root/dkms.key and 
dkms.der. Generated the keys afresh and registered them. Manually 
deleted any nvidia-current*ko files under /lib/modules/*. Rebooted. 
Purged nvidia-kernel-dkms. Rebooted again.


But the error comes back. Even after deleting, purging, rebooting, when 
I then install nvidia-kernel-dkms anew, I still get the same error 
message:


Setting up nvidia-kernel-dkms (470.86-1) ...
Removing old nvidia-current-470.86 DKMS files...
Loading new nvidia-current-470.86 DKMS files...
Error! DKMS tree already contains: nvidia-current-470.86
You cannot add the same module/version combo more than once.
dpkg: error processing package nvidia-kernel-dkms (--configure):
 installed nvidia-kernel-dkms package post-installation script 
subprocess returned error exit status 3

dpkg: dependency problems prevent configuration of nvidia-driver:
 nvidia-driver depends on nvidia-kernel-dkms (= 470.86-1) | 
nvidia-kernel-470.86; however:

  Package nvidia-kernel-dkms is not configured yet.
  Package nvidia-kernel-470.86 is not installed.
  Package nvidia-kernel-dkms which provides nvidia-kernel-470.86 is not 
configured yet.


dpkg: error processing package nvidia-driver (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 nvidia-kernel-dkms
 nvidia-driver
E: Sub-process /usr/bin/dpkg returned an error code (1)

Bug#1000150: Spurious message 'cannot open folder tags:/'

[Oliver Sander]

I found an upstream bugreport:

  https://bugs.kde.org/show_bug.cgi?id=437176

The workaround mentioned there (balooctl purge)
worked for me.

Thanks for your work on Debian.



smime.p7s
Description: S/MIME Cryptographic Signature