Bug#1043311: [Pkg-rust-maintainers] Bug#1043311: rustc: please enable profiler builtin

[Andres Salomon]

On Fri, 08 Sep 2023 13:35:44 -0400 Andres Salomon  
wrote:

>
>
> On Fri, Sep 8 2023 at 10:36:48 AM +02:00:00, Fabian Grünbichler
>  wrote:
> >>  On Tue, Aug 8 2023 at 06:22:28 PM -04:00:00, Andres Salomon
> >>
> [...]
> >>
> >>  This patch adds
> >> "cargo:rustc-link-search=/usr/lib/clang/15/lib/linux/" and
> >>  "cargo:rustc-link-lib=static=clang_rt.profile-x86_64" (or 
whatever
> >>  architecture it happens to be building on) to the 
profiler_builtins

> >> build
> >>  flags when the target matches the host. In the case where the
> >> target is
> >>  different from the host, it assumes a wasm build and sets
> >>  "rustc-link-lib=static=clang_rt.builtins-wasm32" or
> >>  "cargo:rustc-link-lib=static=clang_rt.builtins-wasm64" depending
> >> upon
> >>  whether the target is 32 or 64 bits, respectively.
> >
> > Thanks for the patch! the Windows part in d/rules looks wrong to 
me -
> > that is built with mingw, not wasi. I assume you are not 
interested in

> > that part, so maybe it would also be an option to guard it based on
> > target and just build it for the regular one (or regular+wasm, but 
not

> > windows/mingw)?
>

After you pointed out the upstream patch on IRC 
(https://github.com/rust-lang/rust/pull/114069), I backported it to 
1.70 and tried building it. It gets pretty far, but fails late in the 
build on some tests. I'm going to do some more building (starting with 
rustc by itself without the profiler stuff, to ensure that the test 
failure I'm seeing is actually related to profiler). But in the 
meantime, here's the backported patch. If I can get it fully built, 
I'll follow up with the full debian patch or a merge request.



From d0b58f40a0e669897fafb614299d2a989997eda7 Mon Sep 17 00:00:00 2001
From: Josh Stone 
Date: Tue, 25 Jul 2023 13:11:50 -0700
Subject: [PATCH] Allow using external builds of the compiler-rt profile lib

This changes the bootstrap config `target.*.profiler` from a plain bool
to also allow a string, which will be used as a path to the pre-built
profiling runtime for that target. Then `profiler_builtins/build.rs`
reads that in a `LLVM_PROFILER_RT_LIB` environment variable.
---
 config.example.toml|  6 --
 library/profiler_builtins/build.rs |  6 ++
 src/bootstrap/compile.rs   |  4 
 src/bootstrap/config.rs| 30 --
 4 files changed, 38 insertions(+), 8 deletions(-)

--- a/config.example.toml
+++ b/config.example.toml
@@ -745,8 +745,10 @@ changelog-seen = 2
 # This option will override the same option under [build] section.
 #sanitizers = build.sanitizers (bool)
 
-# Build the profiler runtime for this target(required when compiling with options that depend
-# on this runtime, such as `-C profile-generate` or `-C instrument-coverage`).
+# When true, build the profiler runtime for this target(required when compiling
+# with options that depend on this runtime, such as `-C profile-generate` or
+# `-C instrument-coverage`). This may also be given a path to an existing build
+# of the profiling runtime library from LLVM's compiler-rt.
 # This option will override the same option under [build] section.
 #profiler = build.profiler (bool)
 
--- a/library/profiler_builtins/build.rs
+++ b/library/profiler_builtins/build.rs
@@ -6,6 +6,12 @@ use std::env;
 use std::path::Path;
 
 fn main() {
+println!("cargo:rerun-if-env-changed=LLVM_PROFILER_RT_LIB");
+if let Ok(rt) = env::var("LLVM_PROFILER_RT_LIB") {
+println!("cargo:rustc-link-lib=static:+verbatim={rt}");
+return;
+}
+
 let target = env::var("TARGET").expect("TARGET was not set");
 let cfg = &mut cc::Build::new();
 
--- a/src/bootstrap/compile.rs
+++ b/src/bootstrap/compile.rs
@@ -314,6 +314,10 @@ pub fn std_cargo(builder: &Builder<'_>,
 cargo.env("MACOSX_DEPLOYMENT_TARGET", target);
 }
 
+if let Some(path) = builder.config.profiler_path(target) {
+cargo.env("LLVM_PROFILER_RT_LIB", path);
+}
+
 // Determine if we're going to compile in optimized C intrinsics to
 // the `compiler-builtins` crate. These intrinsics live in LLVM's
 // `compiler-rt` repository, but our `src/llvm-project` submodule isn't
--- a/src/bootstrap/config.rs
+++ b/src/bootstrap/config.rs
@@ -454,7 +454,7 @@ pub struct Target {
 pub linker: Option,
 pub ndk: Option,
 pub sanitizers: Option,
-pub profiler: Option,
+pub profiler: Option,
 pub crt_static: Option,
 pub musl_root: Option,
 pub musl_libdir: Option,
@@ -715,9 +715,9 @@ define_config! {
 }
 }
 
-#[derive(Debug, Deserialize)]
+#[derive(Clone, Debug, Deserialize)]
 #[serde(untagged)]
-enum StringOrBool {
+pub enum StringOrBool {
 String(String),
 Bool(bool),
 }
@@ -728,6 +728,12 @@ impl Default for StringOrBool {
 }
 }
 
+impl StringOrBool {
+fn is_string_or_true(&self) -> bool {
+matches!(self, Self::String(_) | Self::Bool(true))
+}
+}
+
 define_config! {
 /// TOML representation of how t

Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR?

[Helmut Grohne]

Hi Francesco,

On Fri, Jan 12, 2024 at 08:05:02PM +0100, Francesco Poli wrote:
> Indeed, the error does not seem to have anything to do with a "No space
> left on device" failure:
> 
> [...]
>   mke2fs 1.47.0 (5-Feb-2023)
>   mkfs.ext4: Permission denied while trying to determine filesystem size
>   E: setup failed: E: command failed: /sbin/mkfs.ext4 -d "$1/mnt" -L 
> autopkgtestvm -E 'offset=134217728,assume_storage_prezeroed=1' 
> 'sid_amd64.img' '25G'
> [...]
> 
> What can cause mkfs.ext4 to fail with a "Permission denied" error?

I think this is our typical problem when dealing with user namespaces. I
guess that the thing that fails here is mkfs.ext4 opening the target
image file (to be formatted). That file has earlier been chowned to the
root uid inside the namespace, so permission should be there, but you
need more. You also need execute permission (to the first uid of your
namespace) for the containing directory up until the root. I guess that
none of those are world-executable and not by chanced owned by your
first subuid nor owned by the first group in your subgid range. It's an
odd requirement and unfortunately one that is very difficult to get rid
of.

Can we accept and document this limitation for now?

Helmut

Bug#1060700: Requesting advice regarding the impact of problems caused by aliasing on declared Conflicts

[Helmut Grohne]

Package: tech-ctte

Given our discussion at the last CTTE meeting, I am turning my request
for advice into a formal one.

Most of the /usr-move that is happening via DEP17 seems to be working
out, but the effects of Conflicts raise the question of what kinds of
interactions with a package manager are considered supported.

A naive reading of Debian policy 7.4 suggests that declaring a conflict
reliably prevents concurrent unpack:

| When one binary package declares a conflict with another using a
| Conflicts field, dpkg will refuse to allow them to be unpacked on
| the system at the same time.

If you account for the effects of aliasing, this turns out to be a too
naive reading as dpkg actually allows unpacking a conflicting package if
the other package is scheduled for removal. Normally, this exception
should not have observable consequences, but aliasing makes it
observable in the form of file loss. I have filed #1057199 to clarify
debian-policy.

I subsequently triggered the discussion of what kinds of upgrades we
consider supported on debian-de...@lists.debian.org and invited the CTTE
for feedback (20231221094157.ga2753...@subdivi.de). While there is a
preliminary conclusion, subsequent discussion in the last CTTE meeting
and elsewhere has shown some disagreement.

The relevant situation is not entirely trivial to construct:

 * Package $first contains an aliased file $file and this is moved to
   package $second in an update.
   OR
   Package $first diverts aliased location $file normally owned by
   package $second.

 * An update to package $second moves $file to its physical location
   below /usr.

 * Package $second declares a versioned conflict for package $first with
   any version that contains or diverts the aliased $file.

Then we can construct a file loss scenario:

 * Install package $first.
 * Schedule $first for removal:
   echo "$first remove" | dpkg --set-selections
 * Install the updated $second:
   dpkg --unpack $second.deb

In that last step, dpkg will unpack $second despite the conflicted
package $first still being unpacked. After performing the unpack, it
will remove package $first to honour the declared conflict. When doing
so, it will remove the aliased $file and in doing so remove the updated
$file at the physical location below /usr owned by package $second.

The following packages technically contain a conflict involving
aliasing:
 * bfh-container
 * busybox
 * busybox-static
 * busybox-syslogd
 * daemontools-run
 * dhcpcd-base
 * elogind
 * exfat-utils
 * exfatprogs
 * finit-sysv
 * inetutils-syslogd
 * libelogind0
 * libnfsidmap1
 * libsystemd0
 * molly-guard
 * openresolv
 * opensysusers
 * progress-linux-container
 * resolvconf
 * runit
 * runit-init
 * systemctl
 * systemd
 * systemd-resolved
 * systemd-standalone-sysusers
 * systemd-standalone-tmpfiles
 * systemd-sysv
 * sysvinit-core
 * udev
 * zabbix-proxy-mysql
 * zabbix-proxy-pgsql
 * zabbix-proxy-sqlite3
 * zabbix-server-mysql
 * zabbix-server-pgsql
The following files are affected (normalized to aliased representation):
 * /bin/busybox
 * /bin/loginctl
 * /bin/systemctl
 * /bin/systemd-sysusers
 * /bin/systemd-tmpfiles
 * /lib/dhcpcd/dhcpcd-hooks/01-test
 * /lib/dhcpcd/dhcpcd-hooks/20-resolv.conf
 * /lib/dhcpcd/dhcpcd-hooks/30-hostname
 * /lib/dhcpcd/dhcpcd-hooks/60-ntp-common.conf
 * /lib/dhcpcd/dhcpcd-hooks/62-chrony.conf
 * /lib/dhcpcd/dhcpcd-hooks/64-timesyncd.conf
 * /lib/dhcpcd/dhcpcd-hooks/68-openntpd.conf
 * /lib/dhcpcd/dhcpcd-run-hooks
 * /lib/systemd/system/sysinit.target.wants/systemd-hwdb-update.service
 * /lib/systemd/system/systemd-hwdb-update.service
 * /lib/systemd/system/zabbix-proxy.service
 * /lib/systemd/system/zabbix-server.service
 * /lib/udev/rules.d/70-uaccess.rules
 * /lib/udev/rules.d/71-seat.rules
 * /lib/udev/rules.d/73-seat-late.rules
 * /lib/x86_64-linux-gnu/libnfsidmap/nsswitch.so
 * /lib/x86_64-linux-gnu/libnfsidmap/regex.so
 * /lib/x86_64-linux-gnu/libnfsidmap/static.so
 * /lib/x86_64-linux-gnu/libnfsidmap/umich_ldap.so
 * /lib/x86_64-linux-gnu/libsystemd.so.0
 * /sbin/coldreboot
 * /sbin/exfatlabel
 * /sbin/fsck.exfat
 * /sbin/halt
 * /sbin/init
 * /sbin/mkfs.exfat
 * /sbin/pm-hibernate
 * /sbin/pm-suspend
 * /sbin/pm-suspend-hybrid
 * /sbin/poweroff
 * /sbin/reboot
 * /sbin/resolvconf
 * /sbin/runlevel
 * /sbin/shutdown
 * /sbin/syslogd
 * /sbin/telinit
 * /sbin/update-service

While systemctl, libsystemd.so.0 or systemd-sysusers may sound
important, these only are relevant when your upgrade migrates from
docker-systemctl-replacement, elogind or opensysusers during your
dist-upgrade.

The list is incomplete as there are patches adding more. For instance,
cryptsetup, gzip isc-dhcp-client and netplan-generator will likely gain
affected Conflicts. I expect that time64 might double the number.

I note that for the loss to happen, removal needs to be scheduled and
this is not something apt seems to do a lot. apt can be forced to
perform temporary removal using dpkg --set-selections by 

Bug#1060699: qt6-base-dev: Qt6ExampleIconsPrivateConfig.cmake relies on files missing from package

[Stuart Prescott]

Package: qt6-base-dev
Version: 6.6.1+dfsg-5
Severity: normal
X-Debbugs-Cc: stu...@debian.org

Dear Maintainer,

The two cmake files:
  
/usr/lib/x86_64-linux-gnu/cmake/Qt6ExampleIconsPrivate/Qt6ExampleIconsPrivateConfig.cmake
  
/usr/lib/x86_64-linux-gnu/cmake/Qt6ExampleIconsPrivate/Qt6ExampleIconsPrivateTargets.cmake
contain references to files that do not exist within any packages, the
result being that cmake errors out if trying to use them:

--- 8< --- 8< --- 8< --- 8< ---
CMake Error at 
/usr/lib/x86_64-linux-gnu/cmake/Qt6ExampleIconsPrivate/Qt6ExampleIconsPrivateTargets.cmake:116
 (message):
The imported target "Qt6::ExampleIconsPrivate_resources_1" references the
file

"/usr/lib/x86_64-linux-gnu/objects-None/ExampleIconsPrivate_resources_1/.rcc/qrc_example_icons.cpp.o"

but this file does not exist.  Possible reasons include:

* The file was deleted, renamed, or moved to another location.

* An install or uninstall procedure did not complete successfully.

* The installation package was faulty and contained

"/usr/lib/x86_64-linux-gnu/cmake/Qt6ExampleIconsPrivate/Qt6ExampleIconsPrivateTargets.cmake"

but not all the files it references.

Call Stack (most recent call first):
/usr/lib/x86_64-linux-gnu/cmake/Qt6ExampleIconsPrivate/Qt6ExampleIconsPrivateConfig.cmake:62
 (include)
/usr/lib/x86_64-linux-gnu/cmake/Qt6/Qt6Config.cmake:166 (find_package)
sources/pyside6/qtexampleicons/CMakeLists.txt:15 (find_package)

--- 8< --- 8< --- 8< --- 8< ---

(discovered while playing around with pyside6 6.6.1 as you can see from
that trace)

The files it is looking for are in unusual directories so I'm not sure if
there is more to it than just missing the files from the package. I noticed
that Gentoo has the same issue which also seems to be unresolved.

https://bugs.gentoo.org/915587#c6

cheers
Stuart

Bug#1060189: [Pkg-pascal-devel] Bug#1060189: Bug#1060189: lazarus-src-3.0: diversion handling seems wrong (it works, but after an error)

[Paul Gevers]

Hi Abou,

On 12-01-2024 22:44, Abou Al Montacir wrote:

Well, maybe I just didn't spot this issue before. But because of the
/usr-merged work of helmut, I'm much more aware of diversions so they'd
trigger me much more then they used to.


Makes sense, but I'm not sure I understand why diverted files should be 
the same? Isn't diversion is used to enable a package to supersede 
another shipping a different version of the same file?


Indeed, diverted files are supposed to be different, otherwise it 
doesn't make sense to use diversions. To I think the error message is 
trying to say something else, but I don't know what it means exactly. I 
suspect it's saying that the file is already diverted and that we're 
trying to divert it a second time. Or something in that direction.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1058122: python-griddataformats: FTBFS: AttributeError: module 'configparser' has no attribute 'SafeConfigParser'. Did you mean: 'RawConfigParser'?

[Yogeswaran Umasankar]

Hi,
I created a patch for fixing AttributeError: module 'configparser' has
no attribute 'SafeConfigParser'. I've attached the debdiff for you to
check out.
Cheers!

diff -Nru python-griddataformats-1.0.1/debian/changelog 
python-griddataformats-1.0.1/debian/changelog
--- python-griddataformats-1.0.1/debian/changelog   2022-11-07 
17:53:52.0 +
+++ python-griddataformats-1.0.1/debian/changelog   2024-01-13 
01:30:00.0 +
@@ -1,3 +1,22 @@
+python-griddataformats (1.0.1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Patch for AttributeError: module 'configparser' (Closes:#1058122).
+  * Revised autopkgtest d/tests/* for Python 3.12.
+  * Bumped Standards-Version to 4.6.2.
+
+ -- Yogeswaran Umasankar   Sat, 13 Jan 2024 01:30:00 +
+
+python-griddataformats (1.0.1-2) UNRELEASED; urgency=medium
+
+  * Trim trailing whitespace.
+  * Use versioned copyright format URI.
+  * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository-Browse.
+  * Remove constraints unnecessary since buster (oldstable):
++ Build-Depends: Drop versioned constraint on python3-numpy.
+
+ -- Debian Janitor   Fri, 18 Nov 2022 03:19:39 -
+
 python-griddataformats (1.0.1-1) unstable; urgency=medium
 
   * New upstream release.
@@ -66,18 +85,18 @@
 
 python-griddataformats (0.2.2-3) unstable; urgency=low
 
-  * added debian/watch 
+  * added debian/watch
 
  -- Sébastien Buchoux   Thu, 17 Nov 2011 17:19:28 
+0100
 
 python-griddataformats (0.2.2-2) unstable; urgency=low
 
-  * python-setuptools added as a build dependency in debian/control 
+  * python-setuptools added as a build dependency in debian/control
 
  -- Sébastien Buchoux   Wed, 16 Nov 2011 17:17:56 
+0100
 
 python-griddataformats (0.2.2-1) unstable; urgency=low
 
   * Initial release as Debian package
-  
+
  -- Sébastien Buchoux   Wed, 16 Nov 2011 10:43:43 
+0100
diff -Nru python-griddataformats-1.0.1/debian/control 
python-griddataformats-1.0.1/debian/control
--- python-griddataformats-1.0.1/debian/control 2022-11-07 17:53:52.0 
+
+++ python-griddataformats-1.0.1/debian/control 2024-01-13 01:30:00.0 
+
@@ -7,12 +7,12 @@
  dh-python,
  python3-all:any,
  python3-mrcfile,
- python3-numpy (>= 1.19~),
+ python3-numpy,
  python3-pytest,
  python3-scipy,
  python3-setuptools,
  python3-six
-Standards-Version: 4.6.1
+Standards-Version: 4.6.2
 Homepage: https://www.mdanalysis.org/GridDataFormats/
 Vcs-Git: https://salsa.debian.org/debichem-team/python-griddataformats.git
 Vcs-Browser: https://salsa.debian.org/debichem-team/python-griddataformats
diff -Nru python-griddataformats-1.0.1/debian/copyright 
python-griddataformats-1.0.1/debian/copyright
--- python-griddataformats-1.0.1/debian/copyright   2022-11-07 
17:53:52.0 +
+++ python-griddataformats-1.0.1/debian/copyright   2024-01-13 
01:30:00.0 +
@@ -1,4 +1,4 @@
-Format: http://dep.debian.net/deps/dep5
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: python-griddataformats
 Source: https://github.com/MDAnalysis/GridDataFormats
 
diff -Nru 
python-griddataformats-1.0.1/debian/patches/001_AttributeError-fix-py312.patch 
python-griddataformats-1.0.1/debian/patches/001_AttributeError-fix-py312.patch
--- 
python-griddataformats-1.0.1/debian/patches/001_AttributeError-fix-py312.patch  
1970-01-01 00:00:00.0 +
+++ 
python-griddataformats-1.0.1/debian/patches/001_AttributeError-fix-py312.patch  
2024-01-13 01:30:00.0 +
@@ -0,0 +1,18 @@
+Description: Fix for AttributeError: module 'configparser' in Python 3.12.
+Author: Yogeswaran Umasankar 
+Last-Update: 2024-01-13
+
+--- a/versioneer.py
 b/versioneer.py
+@@ -339,9 +339,9 @@ def get_config_from_root(root):
+ # configparser.NoOptionError (if it lacks "VCS="). See the docstring at
+ # the top of versioneer.py for instructions on writing your setup.cfg .
+ setup_cfg = os.path.join(root, "setup.cfg")
+-parser = configparser.SafeConfigParser()
++parser = configparser.ConfigParser()
+ with open(setup_cfg, "r") as f:
+-parser.readfp(f)
++parser.read_file(f)
+ VCS = parser.get("versioneer", "VCS")  # mandatory
+ 
+ def get(parser, name):
diff -Nru python-griddataformats-1.0.1/debian/patches/series 
python-griddataformats-1.0.1/debian/patches/series
--- python-griddataformats-1.0.1/debian/patches/series  1970-01-01 
00:00:00.0 +
+++ python-griddataformats-1.0.1/debian/patches/series  2024-01-13 
01:30:00.0 +
@@ -0,0 +1 @@
+001_AttributeError-fix-py312.patch
diff -Nru python-griddataformats-1.0.1/debian/source/options 
python-griddataformats-1.0.1/debian/source/options
--- python-griddataformats-1.0.1/debian/source/options  1970-01-01 
00:00:00.0 +
+++ python-griddataformats-1.0.1/debian/source/options  2024-01-13 
01:30:00.0 +
@@ -0,0 +1,2 @@
+extend-diff-ignore = "^[^/]*[.]egg-info/|^GridDataFormats[.]eg

Bug#1058027: pybj: FTBFS with Python 3.12

[s3v]

Dear Maintainer,

Python 3.12 changed recursion mechanism [1]

 sys.setrecursionlimit() and sys.getrecursionlimit(). The recursion limit
 now applies only to Python code. Builtin functions do not use the recursion
 limit, but are protected by a different mechanism that prevents recursion
 from causing a virtual machine crash.

so increasing recursion limit as py-ubjson did [2] makes your package
buildable.
E.g.

--- a/test/test.py
+++ b/test/test.py
@@ -477,10 +477,10 @@
 
 def test_recursion(self):
 old_limit = getrecursionlimit()
-    setrecursionlimit(200)
+    setrecursionlimit(100)
 try:
 obj = current = []
-    for _ in range(getrecursionlimit() * 2):
+    for _ in range(getrecursionlimit() * 30):
 new_list = []
 current.append(new_list)
 current = new_list
@@ -488,7 +488,7 @@
 with self.assert_raises_regex(RuntimeError, 'recursion'):
 self.bjddumpb(obj)
 
-    raw = ARRAY_START * (getrecursionlimit() * 2)
+    raw = ARRAY_START * (getrecursionlimit() * 30)
 with self.assert_raises_regex(RuntimeError, 'recursion'):
 self.bjdloadb(raw)
 finally:


Kind Regards

[1] https://docs.python.org/3/whatsnew/3.12.html#sys
[2] 
https://sources.debian.org/src/py-ubjson/0.16.1-3/debian/patches/py12_recursion_PR19.diff/

Bug#1060698: yubioath-desktop: Doesn't see yubikeys anymore.

[Freagarach]

Package: yubioath-desktop
Version: 5.1.0-2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: freagar...@tuta.io

Dear Maintainer,

since yesterday the problem holding back python3-ykman (and related packages) 
was resolved, I upgraded my system today.
When trying to use the GUI for yubikeys (this package), my yubikeys were not 
shown. I could use the terminal (yubikey-manager CLI) to do my tasks.

It seems that this package relies on a lower version of its dependencies. I 
can't really test due to the dependency issues that introduces.

I know there is #1034701, so this report might be considered an escalation of 
that, but I'm not too comfortable (yet) with Debian policies.
Please let me know if more information is needed. And thanks in advance for any 
effort taken. :)

Kind regards,

Freagarach


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

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

Versions of packages yubioath-desktop depends on:
ii  libc6  2.37-13
ii  libgcc-s1  13.2.0-9
ii  libqt5core5a   5.15.10+dfsg-5
ii  libqt5gui5 5.15.10+dfsg-5
ii  libqt5multimedia5  5.15.10-2
ii  libqt5qml5 5.15.10+dfsg-2
ii  libqt5quick5   5.15.10+dfsg-2
ii  libqt5quickcontrols2-5 5.15.10+dfsg-2
ii  libqt5widgets5 5.15.10+dfsg-5
ii  libstdc++6 13.2.0-9
ii  pcscd  2.0.1-1
ii  python3-ykman  5.2.1-1
ii  qml-module-io-thp-pyotherside  1.6.0-4
ii  qml-module-qt-labs-platform5.15.10+dfsg-2
ii  qml-module-qt-labs-settings5.15.10+dfsg-2
ii  qml-module-qtquick-controls5.15.10-2
ii  qml-module-qtquick-controls2   5.15.10+dfsg-2
ii  qml-module-qtquick-dialogs 5.15.10-2

yubioath-desktop recommends no packages.

yubioath-desktop suggests no packages.

-- no debconf information

Bug#1056476: python-importlib-metadata's autopkg tests fail with Python 3.12

[s3v]

Dear Maintainer,

> 450s   File
> "/tmp/autopkgtest.5EvlHX/autopkgtest_tmp/tests/test_main.py", line 8, in
> 
> 450s import pyfakefs.fake_filesystem_unittest as ffs
> 450s   File
> "/usr/lib/python3/dist-packages/pyfakefs/fake_filesystem_unittest.py",
> line 72, in 
> 450s from pyfakefs import fake_pathlib
> 450s   File "/usr/lib/python3/dist-packages/pyfakefs/fake_pathlib.py",
> line 164, in 
> 450s flavour = pathlib._Flavour  # type: ignore [attr-defined]
> 450s   
> 450s AttributeError: module 'pathlib' has no attribute '_Flavour'

the failure was fixed in python-pyfakefs/5.3.2-1 [1] uploaded in unstable.
Your package builds fine now and all tests pass as well.

Kind Regards

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056524

Bug#1015848: workaround to achieve XHTML-compatible output

[Thorsten Glaser]

Hi everyone,

perhaps the other heavy xmlstarlet users are also interested
in this, so I decided to share.

I wrote an LD_PRELOADable library (sorry, Macintosh users) that
can be used to make xmlstarlet fo/sel output a space before the
“/>” as is needed for XHTML.

https://mbsd.evolvis.org/cvs.cgi/contrib/hosted/tg/forceXHTML.c?rev=HEAD

This was not entirely simple as many useful functions for minimal
change are not exposed by the API; “fo” is a tad more fragile than
“sel” but I tested both on a small corpus and diff’d against the
normal results, but I don’t have PIs or anything else fancy in there.

I tested these on Debian GNU/Linux 11 (“bullseye”). These might even
work with other tools (xmllint/xsltproc) but I don’t use them, only
xmlstarlet, have “always” been.

Maybe drop me a note if you enjoy it, have patches or suggestions.

bye,
//mirabilos
-- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)

Bug#1060651: mc: doesn't fully resize itself if reading directory while terminal's resized

[Michael Gold]

On Fri, Jan 12, 2024 at 03:07:04 +, Michael Gold wrote:
> I sometimes notice this if I navigate into a large directory, and resize
> the window while the "spinner" is animating at the top-right corner.  It
> can be difficult to reproduce once Linux has the data cached.

It looks like the spinner--rotate_dash()--is actually the culprit.  That
calls mc_refresh(), which empties sigwinch_pipe before do_nc() makes its
first dlg_run() call:
(gdb) bt
#0  tty_flush_winch () at ./lib/tty/tty.c:224
#1  0x556567fb in dialog_change_screen_size () at 
./lib/widget/dialog-switch.c:426
#2  0x55656781 in mc_refresh () at 
./lib/widget/dialog-switch.c:411
#3  0x5558f98e in rotate_dash (show=1) at 
./src/filemanager/layout.c:1087
#4  0x5559995c in panel_dir_list_callback (state=DIR_READ, 
data=0x55704ac0) at ./src/filemanager/panel.c:4359
#5  0x555fdff7 in dir_list_load (list=0x55801688, 
vpath=0x557f5020, sort=0x555fccec , sort_op=0x55801760, 
filter=0x558017c0) at ./src/filemanager/dir.c:670
#6  0x5559a1b7 in panel_sized_with_dir_new 
(panel_name=0x556784aa "New Right Panel", y=0, x=0, lines=0, cols=0, 
vpath=0x0) at ./src/filemanager/panel.c:4612
#7  0x5558d975 in panel_sized_new (panel_name=0x556784aa 
"New Right Panel", y=0, x=0, lines=0, cols=0) at 
../../src/filemanager/panel.h:272
#8  0x5558ed29 in restore_into_right_dir_panel (idx=1, 
last_was_panel=0, y=0, x=0, lines=0, cols=0) at ./src/filemanager/layout.c:668
#9  0x5558fca3 in create_panel (num=1, type=view_listing) at 
./src/filemanager/layout.c:1189
#10 0x5558279a in create_panels () at 
./src/filemanager/filemanager.c:658
#11 0x55582ee3 in create_file_manager () at 
./src/filemanager/filemanager.c:911
#12 0x55584bed in do_nc () at 
./src/filemanager/filemanager.c:1840
#13 0x55570a92 in main (argc=1, argv=0x7fffe248) at 
./src/main.c:458
(gdb) 

It's dlg_run() that will put the file browser into the top_dlg list; but
top_dlg is still empty in the above backtrace, so no MSG_RESIZE messages
are sent.  If SIGWINCH comes at the "expected" time, I see this:
(gdb) bt
#0  send_message (w=0x557f5a80, sender=0x0, msg=MSG_RESIZE, parm=0, 
data=0x0) at ../../lib/widget/widget-common.h:250
#1  0x55655e79 in dialog_switch_resize (d=0x557f5a80) at 
./lib/widget/dialog-switch.c:136
#2  0x556568cc in dialog_change_screen_size () at 
./lib/widget/dialog-switch.c:447
#3  0x55657020 in frontend_dlg_run (h=0x557f5a80) at 
./lib/widget/dialog.c:293
#4  0x55657ac2 in dlg_run (h=0x557f5a80) at 
./lib/widget/dialog.c:574
#5  0x55584bff in do_nc () at 
./src/filemanager/filemanager.c:1841
#6  0x55570a92 in main (argc=1, argv=0x7fffe248) at 
./src/main.c:458
(gdb) 

Simply sticking a "return" at the top of rotate_dash() makes the problem
unreproducible, and gives me a PASS from the test case.  Something like
a global 'is_ready' flag might be a better way to do it; or just ensure
dialog_change_screen_size() doesn't flush the pipe if the dialog list is
empty.

While debugging this, I noticed a related bug in toggle_subshell(),
which has this code:
was_sigwinch = tty_got_winch ();
tty_flush_winch ();

If a SIGWINCH were handled after setting was_sigwinch to 0 but before
flushing the pipe, the SIGWINCH would be missed.  I never saw it happen,
but it could be easily fixed by replacing that code with:
was_sigwinch = tty_flush_winch ();
and making that function return the appropriate boolean value.

-- Michael


signature.asc
Description: PGP signature

Bug#1035725: rdiff-backup bug

[Otto Kekäläinen]

On Sat, 20 May 2023 at 12:24, Henrik Riomar  wrote:
>
> Reproduction of the bug is simple with safekeep from a system running Debian 
> 11 trying to backup a system running Debian 12.
>
> The backup can not even start, just get "Exception ''restrict_path'' raised 
> of class ''" from rdiff-backup on Debian 12.
>
> Full back-trace from safekeep in the upstream bug report here: 
> https://github.com/rdiff-backup/rdiff-backup/issues/872

Looking at https://github.com/rdiff-backup/rdiff-backup/issues/872
this was fixed in latest rdiff-backup, which is now available in
Debian unstable.

If you can confirm that this version fixes the issue, I can backport
it to Debian Bookworm as well.

Bug#1060359: psmisc: install fuser into /usr (DEP17)

[Craig Small]

On Wed, 10 Jan 2024 at 09:42, Chris Hofstaedtler  wrote:

> Please find a patch attached to install fuser into /usr, for the
> currently ongoing UsrMerge effort [1].
> It has been build-tested and checked by dumat.
>
Hi Chris,
  Thanks for the patch. I have reviewed it and uploaded a new version of
psmisc with that patch.

 - Craig

Bug#964905: RFP: goatcounter -- easy, meaningful privacy-friendly web analytics

[Antoine Beaupré]

On 2020-07-17 13:29:56, Antoine Beaupré wrote:

[...]

> It also happens to provide a nice list of missing packages which, in a
> more digestable form, looks like this:
>
>  * code.soquee.net/otp
>  * github.com/go-chi/chi
>  * github.com/monoculum/formam
>  * github.com/teamwork/reload
>  * github.com/zgoat/kommentaar
>  * honnef.co/go/tools
>
> Note that zgoat/kommentaar is a fork of teamwork/kommentaar, something
> to keep in mind.
>
> This one is a fork of an existing package in Debian,
> golang-github-oschwald-geoip2-golang-dev, we'd need to investigate if
> that can be resolved:
>
>  * github.com/arp242/geoip2-golang
>
> The other dependencies are generally sane and could be packaged for Debian.

This is now really old, but just for kicks I looked around and those are
actually packed now, already:

>  * github.com/go-chi/chi
>  * honnef.co/go/tools

Which means that goatcounter, as it was 3 years ago (!), would only
require packaging those:

>  * code.soquee.net/otp
>  * github.com/monoculum/formam
>  * github.com/teamwork/reload
>  * github.com/zgoat/kommentaar

Obviously, we'd need to review this with the latest upstream code, but I
thought that was slightly encouraging.

a.

-- 
Il faut tout un village pour élever un enfant.
- Proverbe africain

Bug#1021370: pipewire: build with bluez5-codec-aac=enabled

[Max Nikulin]

On 13/01/2024 02:17, Jeremy Bícha wrote:

On Fri, Jan 12, 2024 at 11:12 AM Max Nikulin  wrote:

An alternative may be building a separate package for the contrib
repository section that contains just the aac codec plugin.


I would prefer getting fdk-aac-free into Debian main. It has been in
the NEW queue for roughly 2 years.


I suggested a separate contrib package because after reading #981285 I 
decided that there is a little chance that package can be moved to main.


"Changes" in
https://ftp-master.debian.org/new/fdk-aac-free_2.0.2-3.html
(I hope NEWS file advertises it as well) contains a better description 
of intentions in comparison to the request to ftpmasters in

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981285#64

I was confused by
https://fedoraproject.org/wiki/Licensing/FDK-AAC

[UPDATE: As of some date in August 2022, the FDK-AAC license is expected
to be reclassified as not-allowed (essentially, non-free) because of its
"no patent licenses" feature. This is not expected to have an impact on
the continued packaging of fdk-aac-free in Fedora.]
Maybe another message to ftpmasters could help. One that clearly states 
the steps taking to resolve licensing issues.


It may be offered to add new set of binary packages, e.g. 
libfdk-aac2-free having Provides: libfdk-aac2 and Conflicts: 
libfdk-aac2. However duplication increases maintenance burden in the 
case of security bugs.


So it is necessary to identify friction points related to fdk-aac-free.

Bug#1056474: python-ibm-cloud-sdk-core's autopkg tests fail with Python 3.12

[Yogeswaran Umasankar]

Hi,
Uploaded a patch in salsa [0] to fix the autopkgtest issue with Py 3.12.
Updated the package with new upstream version too.

[0] https://salsa.debian.org/python-team/packages/python-ibm-cloud-sdk-core

Cheers!


signature.asc
Description: PGP signature

Bug#1058310: python-ibm-cloud-sdk-core: FTBFS: failed tests

[Yogeswaran Umasankar]

Hi,
Uploaded a patch in salsa [0] to fix the autopkgtest issue with Py 3.12.
Updated the package with new upstream version too.

[0] https://salsa.debian.org/python-team/packages/python-ibm-cloud-sdk-core

Cheers!


signature.asc
Description: PGP signature

Bug#1041089: thin-provisioning-tools FTBFS with googletest 1.13.0

[Karsten Kruse]

Hello,

Is there something else that needs to be done to get the package back into
testing?

My system prints a "missing binary: /usr/sbin/check_cache" at boot time
when assembling my lvmcache(7).

Thanks,
Karsten

Bug#1038961: AttributeError

[Sudip Mukherjee]

I can reproduce the issue. I think it is because it is an X11 app
which is being run through Wayland directly.

Please try the following command from a terminal:

GDK_BACKEND=x11 flowblade



-- 
Regards
Sudip

Bug#1054446: bookworm-pu: package wolfssl/5.5.4-2+deb12u1

[Bastian Germann]

On Tue, 26 Dec 2023 12:04:50 + "Adam D. Barratt"  
wrote:




Did you want to tell me to proceed with the upload?

Bug#1049972: rdiff-backup: "remove increments older than" exits with error when there are no increments to remove

[Otto Kekäläinen]

Control: tag -1 help moreinfo

Hi!

I don't think the Python packagers in Debian have capacity to debug
this issue in upstream code.

Could you as the original reporter check if this has already been
reported upstream at
https://github.com/rdiff-backup/rdiff-backup/issues?

Bug#1034673: rdiff-backup: Compare action reports error if source directory has changed files

[Otto Kekäläinen]

Control: tag -1 help moreinfo

Hi!

I don't think the Python packagers in Debian have capacity to debug
this issue in upstream code.

Could you as the original reporter check if this has already been
reported upstream at
https://github.com/rdiff-backup/rdiff-backup/issues?

Bug#1024096: rdiff-backup: please run the upstream testsuite

[Otto Kekäläinen]

Control: merge 974526 1024096

This is a confirmed need, but pending for contributors to submit
something at 
https://salsa.debian.org/python-team/packages/rdiff-backup/-/merge_requests

Bug#1060682: u-boot-sifive: Unable to boot from NVME via SPI on Hifive Unmatched Rev B

[Michael Fladischer]

Am 12.01.2024 um 22:32 schrieb Vagrant Cascadian:

That does not leave much to investigate, so is a bit worrying, but
perhaps a binNMU would "fix" it?


I'm back on 2023.07+dfsg-1 and boot works again. Just let me know if I 
can test anything to help track this down.


Regards,
Michael

Bug#988164: rdiff-backup: obsolete conffile not removed

[Otto Kekäläinen]

Hi!

Thanks Sebastien for bringing this up. Would you like to file a MR at
https://salsa.debian.org/python-team/packages/rdiff-backup/-/merge_requests
to get this fixed?

On Wed, 8 Feb 2023 at 07:21, Sébastien Villemot  wrote:
>
> Control: tags -1 + patch
>
> Hi,
>
> Le vendredi 03 février 2023 à 15:11 -0800, Otto Kekäläinen a écrit :
> > Thanks for using rdiff-backup in Debian. The latest version
> > (https://tracker.debian.org/pkg/rdiff-backup) has recently been
> > uploaded to Debian. I would appreciate it if you can help testing it,
> > and perhaps also verify if this issue still exists and if it does,
> > please consider contributing to the packaging.
>
> Since it seems that you did not add the relevant snippet in
> debian/maintscript, the bug is for sure still present. Of course, it
> only manifests when upgrading from a version old enough (i.e. pre
> 1.2.8-8).
>
> The fix should be as simple as creating debian/maintscript with the
> following contents:
>
> rm_conffile /etc/bash_completion.d/rdiff-backup 1.2.8-8~ rdiff-backup
>
> Best,
>
> --
> ⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
> ⣾⠁⢠⠒⠀⣿⡁  Debian Developer
> ⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
> ⠈⠳⣄  https://www.debian.org
>
>

Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR?

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Francesco Poli (2024-01-12 20:05:02)
> On Thu, 11 Jan 2024 21:04:16 +0100 Johannes Schauer Marin Rodrigues wrote:
> > Do you see yourself debugging this further by yourself? You probably
> > understand that it's hard for me to investigate something that I cannot
> > test myself.
> 
> Well, you wrote the script, together with Helmut Grohne (who reads us
> in Cc).
> I rather see myself helping the two of you in debugging it...   :-)

could you try applying this patch and then try again:

--%<-
--- a/mmdebstrap-autopkgtest-build-qemu
+++ b/mmdebstrap-autopkgtest-build-qemu
@@ -302,17 +302,12 @@ if test -n "$SCRIPT"; then
'--customize-hook=rm -f "$1/userscript"'
 fi
 
-EXT4_OFFSET_BYTES=$(( (FAT_OFFSET_SECTORS + FAT_SIZE_SECTORS) * 512))
-EXT4_OPTIONS="offset=$EXT4_OFFSET_BYTES,assume_storage_prezeroed=1"
 set -- "$@" \
"--customize-hook=download vmlinuz '$WORKDIR/kernel'" \
"--customize-hook=download initrd.img '$WORKDIR/initrd'" \
-   '--customize-hook=mount --bind "$1" "$1/mnt"' \
-   '--customize-hook=mount --bind "$1/mnt/mnt" "$1/mnt/dev"' \
-   '--customize-hook=/sbin/mkfs.ext4 -d "$1/mnt" -L autopkgtestvm -E 
'"'$EXT4_OPTIONS' '$IMAGE' '$SIZE'" \
-   '--customize-hook=umount --lazy "$1/mnt"' \
+   --format=ext2 \
"$RELEASE" \
-   /dev/null
+   "$IMAGE"
 
 test -n "$MIRROR" && set -- "$@" "$MIRROR"
 test -n "$KEYRING" && set -- "$@" "--keyring=$KEYRING"
@@ -320,6 +315,9 @@ test -n "$KEYRING" && set -- "$@" "--keyring=$KEYRING"
 echo "mmdebstrap $*"
 mmdebstrap "$@" || die "mmdebstrap failed"
 
+EXT4_OFFSET_BYTES=$(( (FAT_OFFSET_SECTORS + FAT_SIZE_SECTORS) * 512))
+fallocate --insert-range --offset=0 --length=$EXT4_OFFSET_BYTES "$IMAGE"
+
 unshare -U -r --map-groups=auto chown 0:0 "$IMAGE"
 chmod "$(printf %o "$(( 0666 - 0$(umask) ))")" "$IMAGE"
 
-->%-

> Indeed, the error does not seem to have anything to do with a "No space left
> on device" failure:
> 
> [...]
>   mke2fs 1.47.0 (5-Feb-2023)
>   mkfs.ext4: Permission denied while trying to determine filesystem size
>   E: setup failed: E: command failed: /sbin/mkfs.ext4 -d "$1/mnt" -L 
> autopkgtestvm -E 'offset=134217728,assume_storage_prezeroed=1' 
> 'sid_amd64.img' '25G'
> [...]
> 
> What can cause mkfs.ext4 to fail with a "Permission denied" error?

This is unshare mode. Funny things happen. :)

The error message you see comes from misc/mke2fs.c in e2fsprogs as a result of
a failed call to ext2fs_open_file(). What puzzles me is, that it's permission
denied for you and working fine for me.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1059539: bugs.debian.org: Updating multiple packages made my system really slow with opening GTK applications

[Ziga Lausegger]

I found the solution here:

https://forum.level1techs.com/t/gtk-applications-are-super-slow-at-startup/166540

All I needed to do was to remove *xdg-desktop-portal* package:

*sudo apt purge xdg-desktop-portal
sudo apt autoremove*

Now GTK apps open up normally again and also Dropbox tray icon works 
great again!



On Wed, 27 Dec 2023 21:33:31 +0100 Ziga Lausegger 
 wrote:


> Package: bugs.debian.org
> Severity: important
>
> Dear Maintainer,
>
> My last 2 updates made my debian system really slow when opening GTK
> applications. Before this update, GTK applications were opening normally
> but now applications like Firefox, Thunar, Waybar... open really slowly
> (after 20 seconds)! Another symptom that started to happen after this
> update is that original Dropbox client application is not shown any
> longer in the system tray (Waybar).
>
> The update that I did is this one that I took from 
/var/lib/apt/history.log:

>
> 
>
> Start-Date: 2023-12-24 21:27:24
>
> Commandline: apt install libwebkit2gtk-4.0-37
>
> Requested-By: ziga (1000)
>
> Install: bubblewrap:amd64 (0.8.0-2, automatic), 
libwpebackend-fdo-1.0-1:amd64 (1.14.2-1, automatic), 
xdg-desktop-portal-gtk:amd64 (1.14.1-1, automatic), 
libmanette-0.2-0:amd64 (0.2.6-3+b1, automatic), libwoff1:amd64 (1.0.2-2, 
automatic), libwpe-1.0-1:amd64 (1.14.0-1, automatic), 
libjavascriptcoregtk-4.0-18:amd64 (2.42.4-1~deb12u1, automatic), 
libwebkit2gtk-4.0-37:amd64 (2.42.4-1~deb12u1), xdg-dbus-proxy:amd64 
(0.1.4-3, automatic), xdg-desktop-portal:amd64 (1.16.0-2, automatic)

>
> End-Date: 2023-12-24 21:27:31
>
> Start-Date: 2023-12-24 21:29:06
>
> Commandline: apt upgrade
>
> Requested-By: ziga (1000)
>
> Install: linux-image-6.1.0-16-amd64:amd64 (6.1.67-1, automatic)
>
> Upgrade: libfreeimage3:amd64 (3.18.0+ds2-9, 3.18.0+ds2-9+deb12u1), 
libperl5.36:amd64 (5.36.0-7, 5.36.0-7+deb12u1), libcups2:amd64 
(2.4.2-3+deb12u4, 2.4.2-3+deb12u5), libcurl4:amd64 (7.88.1-10+deb12u4, 
7.88.1-10+deb12u5), libreoffice-calc:amd64 (4:7.4.7-1, 
4:7.4.7-1+deb12u1), udev:amd64 (252.17-1~deb12u1, 252.19-1~deb12u1), 
exfatprogs:amd64 (1.2.0-1, 1.2.0-1+deb12u1), uno-libs-private:amd64 
(4:7.4.7-1, 4:7.4.7-1+deb12u1), libreoffice-base-core:amd64 (4:7.4.7-1, 
4:7.4.7-1+deb12u1), libnghttp2-14:amd64 (1.52.0-1, 1.52.0-1+deb12u1), 
libcurl3-gnutls:amd64 (7.88.1-10+deb12u4, 7.88.1-10+deb12u5), 
openssh-client:amd64 (1:9.2p1-2+deb12u1, 1:9.2p1-2+deb12u2), 
libreoffice-core:amd64 (4:7.4.7-1, 4:7.4.7-1+deb12u1), cups-bsd:amd64 
(2.4.2-3+deb12u4, 2.4.2-3+deb12u5), systemd-timesyncd:amd64 
(252.17-1~deb12u1, 252.19-1~deb12u1), perl:amd64 (5.36.0-7, 
5.36.0-7+deb12u1), tzdata:amd64 (2023c-5, 2023c-5+deb12u1), 
cups-common:amd64 (2.4.2-3+deb12u4, 2.4.2-3+deb12u5), 
libpam-systemd:amd64 (252.17-1~deb12u1, 252.19-1~deb12u1), 
libreoffice-common:amd64 (4:7.4.7-1, 4:7.4.7-1+deb12u1), ure:amd64 
(4:7.4.7-1, 4:7.4.7-1+deb12u1), bluetooth:amd64 (5.66-1, 
5.66-1+deb12u1), libminizip1:amd64 (1.1-8+b1, 1.1-8+deb12u1), 
libgs10-common:amd64 (10.0.0~dfsg-11+deb12u2, 10.0.0~dfsg-11+deb12u3), 
cups-client:amd64 (2.4.2-3+deb12u4, 2.4.2-3+deb12u5), cups-ppdc:amd64 
(2.4.2-3+deb12u4, 2.4.2-3+deb12u5), cups-daemon:amd64 (2.4.2-3+deb12u4, 
2.4.2-3+deb12u5), libtiffxx6:amd64 (4.5.0-6, 4.5.0-6+deb12u1), 
gimp-data:amd64 (2.10.34-1, 2.10.34-1+deb12u2), 
linux-compiler-gcc-12-x86:amd64 (6.1.55-1, 6.1.67-1), libtiff6:amd64 
(4.5.0-6, 4.5.0-6+deb12u1), libgs10:amd64 (10.0.0~dfsg-11+deb12u2, 
10.0.0~dfsg-11+deb12u3), libsystemd0:amd64 (252.17-1~deb12u1, 
252.19-1~deb12u1), libnss-systemd:amd64 (252.17-1~deb12u1, 
252.19-1~deb12u1), openssh-server:amd64 (1:9.2p1-2+deb12u1, 
1:9.2p1-2+deb12u2), libuno-purpenvhelpergcc3-3:amd64 (4:7.4.7-1, 
4:7.4.7-1+deb12u1), libuno-cppu3:amd64 (4:7.4.7-1, 4:7.4.7-1+deb12u1), 
libqpdf29:amd64 (11.3.0-1, 11.3.0-1+deb12u1), 
libuno-cppuhelpergcc3-3:amd64 (4:7.4.7-1, 4:7.4.7-1+deb12u1), 
fonts-opensymbol:amd64 (4:102.12+LibO7.4.7-1, 
4:102.12+LibO7.4.7-1+deb12u1), systemd:amd64 (252.17-1~deb12u1, 
252.19-1~deb12u1), libudev1:amd64 (252.17-1~deb12u1, 252.19-1~deb12u1), 
linux-kbuild-6.1:amd64 (6.1.55-1, 6.1.67-1), cups-ipp-utils:amd64 
(2.4.2-3+deb12u4, 2.4.2-3+deb12u5), ghostscript:amd64 
(10.0.0~dfsg-11+deb12u2, 10.0.0~dfsg-11+deb12u3), 
libreoffice-style-colibre:amd64 (4:7.4.7-1, 4:7.4.7-1+deb12u1), 
gimp:amd64 (2.10.34-1, 2.10.34-1+deb12u2), linux-image-amd64:amd64 
(6.1.55-1, 6.1.67-1), libgimp2.0:amd64 (2.10.34-1, 2.10.34-1+deb12u2), 
libgstreamer-plugins-bad1.0-0:amd64 (1.22.0-4+deb12u2, 
1.22.0-4+deb12u4), libreoffice-writer:amd64 (4:7.4.7-1, 
4:7.4.7-1+deb12u1), xserver-common:amd64 (2:21.1.7-3+deb12u2, 
2:21.1.7-3+deb12u4), libuno-salhelpergcc3-3:amd64 (4:7.4.7-1, 
4:7.4.7-1+deb12u1), base-files:amd64 (12.4+deb12u2, 12.4+deb12u4), 
distro-info-data:amd64 (0.58, 0.58+deb12u1), libbluetooth3:amd64 
(5.66-1, 5.66-1+deb12u1), python3-uno:amd64 (4:7.4.7-1, 
4:7.4.7-1+deb12u1), perl-base:amd64 (5.36.0-7, 5.36.0-7+deb12u1), 
openssh-sftp-server:amd64 (1:9.2p1-2+deb12u1, 1:9.2p1-2+deb

Bug#1059539: Solution found!

[Ziga Lausegger]

I read here:
https://forum.level1techs.com/t/gtk-applications-are-super-slow-at-startup/166540/4

that uninstalling |*xdg-dbus-proxy*|helped some users on Archlinux 
distribution.

I uninstalled this package with:

*sudo apt purge xdg-dbus-proxy
sudo apt autoremove
*

And this solved my problem!

Bug#1060682: u-boot-sifive: Unable to boot from NVME via SPI on Hifive Unmatched Rev B

[Aurelien Jarno]

On 2024-01-12 13:32, Vagrant Cascadian wrote:
> On 2024-01-12, Vagrant Cascadian wrote:
> > On 2024-01-12, Vagrant Cascadian wrote:
> >> On 2024-01-12, Michael Fladischer wrote:
> >>> I was able to boot my Hifive Unmatched Rev B board via SPI from NVME with
> >>> u-boot-sifive-2023.07+dfsg-1. After upgrading to 2024.01+dfsg-1 u-boot is 
> >>> no
> >>> longer able to see any NVME drives:
> > ...
> >> I am getting this too. I had tested with a local build of
> >> 2024.01~rc6-1~0 and that worked fine, so I am a bit surprised as none of
> >> the very few commits between v2024.01-rc6 and v2024.01 seem relevent.
> >
> > I should also note that I am testing with u-boot on microSD, so it is
> > not specific to u-boot from SPI.
> >
> >> I also wonder about opensbi, which was fairly recently upgraded,
> >> although I *thought* I tested opensbi 1.4-1 with the ~rc6 build I had
> >> done...
> >
> > I verified u-boot-sifive 2024.01~rc6+dfsg-2 (formerly in experimental)
> > works, which was built with the same opensbi version. In fact, the only
> > difference in the installed build-dependencies were perl related:
> >
> > - libperl5.36 (= 5.36.0-10+b1),
> > + libperl5.38 (= 5.38.2-2),
> > - perl (= 5.36.0-10+b1),
> > - perl-base (= 5.36.0-10+b1),
> > - perl-modules-5.36 (= 5.36.0-10),
> > + perl (= 5.38.2-2),
> > + perl-base (= 5.38.2-2),
> > + perl-modules-5.38 (= 5.38.2-2),
> >
> > I am attempting a local rebuild, will see how that goes...
> 
> Well, rebuilding and just adding a new debian/changelog
> entry... worked. both from a reboot and from a cold start.
> 
> That does not leave much to investigate, so is a bit worrying, but
> perhaps a binNMU would "fix" it?

I tried to do a build from the sources using sbuild, and I ended up with
exactly the same binaries, so unfortunately I doubt a binNMU would fix
it.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net


signature.asc
Description: PGP signature

Bug#1060697: ITP: rust-wayland-protocols-plasma -- Generated API for the Plasma wayland protocol extensions

[James McCoy]

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

* Package name: rust-wayland-protocols-plasma
  Version : 0.2.0
  Upstream Contact: Elinor Berger 
* URL : https://github.com/smithay/wayland-rs
* License : MIT
  Programming Lang: Rust
  Description : Generated API for the Plasma wayland protocol extensions

This is a dependency of the new version of winit and will be maintained
in the pkg-rust repo.

Bug#1060696: gpac: CVE-2023-50120

[Moritz Mühlenhoff]

Source: gpac
X-Debbugs-CC: t...@security.debian.org
Severity: normal
Tags: security

Hi,

The following vulnerability was published for gpac.

CVE-2023-50120[0]:
| MP4Box GPAC version 2.3-DEV-rev636-gfbd7e13aa-master was discovered
| to contain an infinite loop in the function av1_uvlc at
| media_tools/av_parsers.c. This vulnerability allows attackers to
| cause a Denial of Service (DoS) via a crafted MP4 file.

https://github.com/gpac/gpac/issues/2698
https://github.com/gpac/gpac/commit/b655955b840ccd7c7198bb15375aa510e76208eb

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-2023-50120
https://www.cve.org/CVERecord?id=CVE-2023-50120

Please adjust the affected versions in the BTS as needed.

Bug#1060695: qtbase-opensource-src-gles: CVE-2023-51714

[Moritz Mühlenhoff]

Source: qtbase-opensource-src-gles
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for qtbase-opensource-src-gles.

CVE-2023-51714[0]:
| An issue was discovered in the HTTP2 implementation in Qt before
| 5.15.17, 6.x before 6.2.11, 6.3.x through 6.5.x before 6.5.4, and
| 6.6.x before 6.6.2. network/access/http2/hpacktable.cpp has an
| incorrect HPack integer overflow check.

https://codereview.qt-project.org/c/qt/qtbase/+/524864
https://codereview.qt-project.org/c/qt/qtbase/+/524865/3

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-2023-51714
https://www.cve.org/CVERecord?id=CVE-2023-51714

Please adjust the affected versions in the BTS as needed.

Bug#1060694: qtbase-opensource-src: CVE-2023-51714

[Moritz Mühlenhoff]

Source: qtbase-opensource-src
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for qtbase-opensource-src.

CVE-2023-51714[0]:
| An issue was discovered in the HTTP2 implementation in Qt before
| 5.15.17, 6.x before 6.2.11, 6.3.x through 6.5.x before 6.5.4, and
| 6.6.x before 6.6.2. network/access/http2/hpacktable.cpp has an
| incorrect HPack integer overflow check.

https://codereview.qt-project.org/c/qt/qtbase/+/524864
https://codereview.qt-project.org/c/qt/qtbase/+/524865/3

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-2023-51714
https://www.cve.org/CVERecord?id=CVE-2023-51714

Please adjust the affected versions in the BTS as needed.

Bug#1060693: qt6-base: CVE-2023-51714

[Moritz Mühlenhoff]

Source: qt6-base
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for qt6-base.

CVE-2023-51714[0]:
| An issue was discovered in the HTTP2 implementation in Qt before
| 5.15.17, 6.x before 6.2.11, 6.3.x through 6.5.x before 6.5.4, and
| 6.6.x before 6.6.2. network/access/http2/hpacktable.cpp has an
| incorrect HPack integer overflow check.

https://codereview.qt-project.org/c/qt/qtbase/+/524864
https://codereview.qt-project.org/c/qt/qtbase/+/524865/3

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-2023-51714
https://www.cve.org/CVERecord?id=CVE-2023-51714

Please adjust the affected versions in the BTS as needed.

Bug#1060691: freeimage: CVE-2023-47992 CVE-2023-47993 CVE-2023-47994 CVE-2023-47996 CVE-2023-47997

[Moritz Mühlenhoff]

Source: freeimage
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerabilities were published for freeimage. These
don't appear to have been reported upstream, could you check with
the upstream developers?

CVE-2023-47992[0]:
| An integer overflow vulnerability in
| FreeImageIO.cpp::_MemoryReadProc in FreeImage 3.18.0 allows
| attackers to obtain sensitive information, cause a denial-of-service
| attacks and/or run arbitrary code.

https://github.com/thelastede/FreeImage-cve-poc/tree/master/CVE-2023-47992

CVE-2023-47993[1]:
| A Buffer out-of-bound read vulnerability in Exif.cpp::ReadInt32 in
| FreeImage 3.18.0 allows attackers to cause a denial-of-service.

https://github.com/thelastede/FreeImage-cve-poc/tree/master/CVE-2023-47993

CVE-2023-47994[2]:
| An integer overflow vulnerability in LoadPixelDataRLE4 function in
| PluginBMP.cpp in Freeimage 3.18.0 allows attackers to obtain
| sensitive information, cause a denial of service and/or run
| arbitrary code.

https://github.com/thelastede/FreeImage-cve-poc/tree/master/CVE-2023-47994

CVE-2023-47996[4]:
| An integer overflow vulnerability in Exif.cpp::jpeg_read_exif_dir in
| FreeImage 3.18.0 allows attackers to obtain information and cause a
| denial of service.

https://github.com/thelastede/FreeImage-cve-poc/tree/master/CVE-2023-47996

CVE-2023-47997[5]:
| An issue discovered in BitmapAccess.cpp::FreeImage_AllocateBitmap in
| FreeImage 3.18.0 leads to an infinite loop and allows attackers to
| cause a denial of service.

https://github.com/thelastede/FreeImage-cve-poc/tree/master/CVE-2023-47997

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-47992
https://www.cve.org/CVERecord?id=CVE-2023-47992
[1] https://security-tracker.debian.org/tracker/CVE-2023-47993
https://www.cve.org/CVERecord?id=CVE-2023-47993
[2] https://security-tracker.debian.org/tracker/CVE-2023-47994
https://www.cve.org/CVERecord?id=CVE-2023-47994
[3] https://security-tracker.debian.org/tracker/CVE-2023-47995
https://www.cve.org/CVERecord?id=CVE-2023-47995
[4] https://security-tracker.debian.org/tracker/CVE-2023-47996
https://www.cve.org/CVERecord?id=CVE-2023-47996
[5] https://security-tracker.debian.org/tracker/CVE-2023-47997
https://www.cve.org/CVERecord?id=CVE-2023-47997

Please adjust the affected versions in the BTS as needed.

Bug#1060692: libuev: CVE-2022-48620

[Moritz Mühlenhoff]

Source: libuev
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for libuev.

CVE-2022-48620[0]:
| uev (aka libuev) before 2.4.1 has a buffer overflow in epoll_wait if
| maxevents is a large number.

https://github.com/troglobit/libuev/issues/27
https://github.com/troglobit/libuev/commit/2d9f1c9ce655cc38511aeeb6e95ac30914f7aec9
 (v2.4.1)


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-2022-48620
https://www.cve.org/CVERecord?id=CVE-2022-48620

Please adjust the affected versions in the BTS as needed.

Bug#1060690: ITP: Chatterino Chat client twitch.tv

[matt]

Matt Quintanilla
he/him
https://www.mattquintanilla.xyz/
--- Begin Message ---
Package: Chatterino
Severity: ITP
Owner: "matt" 
* Package name: Chatterino
  Version : 2.4.6
  Upstream Author : https://github.com/chatterino/chatterino2
* URL : https://chatterino.com/
* License : MIT
  Programming Lang: C++
  Description : Chat client twitch.tv
Chatterino is a chat client for Twitch chat. It aims to be an
improved/extended version of the Twitch web chat.
--- End Message ---

Bug#1060689: bullseye-pu: package libspreadsheet-parsexlsx-perl/0.27-2.1+deb11u1

[gregor herrmann]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: libspreadsheet-parsexlsx-p...@packages.debian.org
Control: affects -1 + src:libspreadsheet-parsexlsx-perl

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've uploaded libspreadsheet-parsexlsx-perl/0.27-2.1+deb11u1 to
bullseye.

This upload fixes CVE-2024-22368 (potential memory bomb) by adding a
quilt patch, which is taken from 2 upstream commits that are released
in 0.28 (and are in testing/unstable in 0.29-1 since a week).

https://security-tracker.debian.org/tracker/CVE-2024-22368

Complete debdiff attached.


Thanks in advance,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmWhs+NfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgZHfQ/9EUCz97a2oS2P48MIFgCsthWvAPDf5e4ZY3hA1usDrk/+m62qjZd+SoqY
nZANzU/WLqfQ/4m67zZSqPhJUzPsa9sQzVYYXTfaKBr6RYlvaxJvaIaQMDVZRu1T
l0HaYtYm4NSXPk39rIl1gC7U3dqO8+joYDxuEQxlPPe8Fah746F90hh9GUqu0joP
m4j6nL5SBRZ7JeGd68mtLzmI4n8WUeQak7wGAfF9fGugyYCRkqcGlyNVtg+A4xEi
nMqLA9JXZZY84AohCnQgK9C9mww9eqjN4whYGw/SQX4b5SbIs11y5z058Esctptc
vCMQflDPm0ekY+58y7Gg1JTuH5vsNPw0LuYEZjL2+KWkDsrfzEwXSPMOGlmbAaE6
3VWoK94qe8APCXvWyyi0AnrSa0eTb9r8kZ2BBRWx9ST/GMnkmax/AMU7WL9Theyk
0WmBRafm5J+RxMy3aSK4T9U/5gFw0Z+Z7j9NXNI/PtyeQ2sr7oEmDX2iewXFXSy5
0s5zy7vFIlG6BS4FgXjBi+lic3IH2oAkblUczAdmlzNdutV6Wy22Q4wJGtJDKrS8
Ty7fMpNEQ52AJyFH2hb0rAV8v0smvLDPTbZO3fRHHJJAnsXfqlH4OwgfT9fr6dAv
DOksztrqTOFhIU6ZIAVcET30RTuh9/EfoUJryPA5T/IinCLSC9c=
=4oCb
-END PGP SIGNATURE-
diff -Nru libspreadsheet-parsexlsx-perl-0.27/debian/changelog 
libspreadsheet-parsexlsx-perl-0.27/debian/changelog
--- libspreadsheet-parsexlsx-perl-0.27/debian/changelog 2021-01-04 
15:20:56.0 +0100
+++ libspreadsheet-parsexlsx-perl-0.27/debian/changelog 2024-01-12 
21:21:42.0 +0100
@@ -1,3 +1,11 @@
+libspreadsheet-parsexlsx-perl (0.27-2.1+deb11u1) bullseye; urgency=medium
+
+  * Team upload.
+  * Add a patch to fix a possible memory bomb. [CVE-2024-22368]
+Patch taken from two upstream Git commits contained in the 0.28 release.
+
+ -- gregor herrmann   Fri, 12 Jan 2024 21:21:42 +0100
+
 libspreadsheet-parsexlsx-perl (0.27-2.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -Nru 
libspreadsheet-parsexlsx-perl-0.27/debian/patches/CVE-2024-22368.patch 
libspreadsheet-parsexlsx-perl-0.27/debian/patches/CVE-2024-22368.patch
--- libspreadsheet-parsexlsx-perl-0.27/debian/patches/CVE-2024-22368.patch  
1970-01-01 01:00:00.0 +0100
+++ libspreadsheet-parsexlsx-perl-0.27/debian/patches/CVE-2024-22368.patch  
2024-01-12 21:21:42.0 +0100
@@ -0,0 +1,111 @@
+Description: Fix memory bomb CVE-2024-22368
+Origin: upstream, commits 39b25b9 and 47ff82d, as released in 0.28
+Reviewed-by: gregor herrmann 
+Last-Update: 2024-01-12
+
+
+From 39b25b91fcb939a9c8ea807fdc80386c1ae5be0c Mon Sep 17 00:00:00 2001
+From: MichaelDaum 
+Date: Sun, 31 Dec 2023 11:56:25 +0100
+Subject: [PATCH] fix possible memory bomb
+
+as reported in 
https://github.com/haile01/perl_spreadsheet_excel_rce_poc/blob/main/parse_xlsx_bomb.md
+---
+ lib/Spreadsheet/ParseXLSX.pm | 43 
+ 1 file changed, 29 insertions(+), 14 deletions(-)
+
+
+From 47ff82d74fbd014b8ec3cab80fa4fd25db9e8242 Mon Sep 17 00:00:00 2001
+From: MichaelDaum 
+Date: Sun, 31 Dec 2023 12:23:19 +0100
+Subject: [PATCH] minor rewrite and perltidy
+
+---
+ lib/Spreadsheet/ParseXLSX.pm | 16 +++-
+ 1 file changed, 7 insertions(+), 9 deletions(-)
+
+--- a/lib/Spreadsheet/ParseXLSX.pm
 b/lib/Spreadsheet/ParseXLSX.pm
+@@ -176,8 +176,6 @@ sub _parse_sheet {
+ $sheet->{MaxCol} = -1;
+ $sheet->{Selection} = [ 0, 0 ];
+ 
+-my %merged_cells;
+-
+ my @column_formats;
+ my @column_widths;
+ my @columns_hidden;
+@@ -187,7 +185,6 @@ sub _parse_sheet {
+ my $default_row_height   = 15;
+ my $default_column_width = 10;
+ 
+-my %cells;
+ my $row_idx = 0;
+ 
+ my $sheet_xml = $self->_new_twig(
+@@ -263,11 +260,6 @@ sub _parse_sheet {
+ $toprow, $leftcol,
+ $bottomrow, $rightcol,
+ ];
+-for my $row ($toprow .. $bottomrow) {
+-for my $col ($leftcol .. $rightcol) {
+-$merged_cells{"$row;$col"} = 1;
+-}
+-}
+ }
+ 
+ $twig->purge;
+@@ -415,7 +407,6 @@ sub _parse_sheet {
+ $cell->{_Value} = $sheet->{_Book}{FmtClass}->ValFmt(
+ $cell, $sheet->{_Book}
+ );
+-$cells{"$row;$col"} = $cell;
+ $sheet->{Cells}[$row][$col] = $cell;
+ $col_idx++;
+ }
+@@ -428,11 +419,15 @@ sub _parse_shee

Bug#1060688: bookworm-pu: package libspreadsheet-parsexlsx-perl/0.27-3+deb12u1

[gregor herrmann]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: libspreadsheet-parsexlsx-p...@packages.debian.org
Control: affects -1 + src:libspreadsheet-parsexlsx-perl

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've uploaded libspreadsheet-parsexlsx-perl/0.27-3+deb12u1 to
bookworm.

This upload fixes CVE-2024-22368 (potential memory bomb) by adding a
quilt patch, which is taken from 2 upstream commits that are released
in 0.28 (and are in testing/unstable in 0.29-1 since a week).

https://security-tracker.debian.org/tracker/CVE-2024-22368

Complete debdiff attached.


Thanks in advance,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmWhs+VfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgZ02RAAiWujisM7g1V91tVdZ1N9SKD/n3tdkjpRYRE32OeWMF0su5u8/u0RaWeo
O9bpK8goHQF6gt70K/wqPLNKenj45dH86n01q/rLznd5WvPNtytbK/5btj3nze6q
hRYt5P5a1WG7D8ZKyldYSNX9qMbjvFwTegptdAu0Kq6aAYbECcwVeD0SqzxHPzgL
Q9njmCJSuUVsSVcS5e4xkTNLf1N7Ul1cp46UXbaqe40LgThN9EBLMAg+gZJtS6IM
SzQsfwzaQQmtDyhqcUy/RRBBt7l+F77DvT7UiG1BjjYEM8A4AR9UtOfqGNZWe13C
bXy6ccHzoBx4EvI6RoNFGX2u9RzeiDFlOsCf+3Apqpq/uXQJ4t5cjgI2x0USD/gm
gUwjzrPNzpOyTTK/L2DLs6Y7Yo4vJ7mPo6i5yG+6M+hXpkRyqg0a4EK0VQkbhsci
sEQrJUOOeaAwllLfMoY61P05QB1fpuUOKpNOSS7XqPxgWmyz/lWSyLfYIUiPyHAU
Fx5YBqcYZI292UjH2c3+h0lh2Bj58hV3TzzuzRM5yP2W+7AH0pukjUgwLEhWR25s
Z1rigRFK+Ou46n/HJejDiWn4/OW4veK/mIKYow/WgBnKyL48DyALIu5iEzxTYo7U
1QIPn+ivK5IoR3J34e719SBrSeixcruU6hvNlQJjNgq6msLh5oU=
=YJjE
-END PGP SIGNATURE-
diff -Nru libspreadsheet-parsexlsx-perl-0.27/debian/changelog 
libspreadsheet-parsexlsx-perl-0.27/debian/changelog
--- libspreadsheet-parsexlsx-perl-0.27/debian/changelog 2022-11-19 
21:22:53.0 +0100
+++ libspreadsheet-parsexlsx-perl-0.27/debian/changelog 2024-01-12 
21:25:50.0 +0100
@@ -1,3 +1,11 @@
+libspreadsheet-parsexlsx-perl (0.27-3+deb12u1) bookworm; urgency=medium
+
+  * Team upload.
+  * Add a patch to fix a possible memory bomb. [CVE-2024-22368]
+Patch taken from two upstream Git commits contained in the 0.28 release.
+
+ -- gregor herrmann   Fri, 12 Jan 2024 21:25:50 +0100
+
 libspreadsheet-parsexlsx-perl (0.27-3) unstable; urgency=medium
 
   [ gregor herrmann ]
diff -Nru 
libspreadsheet-parsexlsx-perl-0.27/debian/patches/CVE-2024-22368.patch 
libspreadsheet-parsexlsx-perl-0.27/debian/patches/CVE-2024-22368.patch
--- libspreadsheet-parsexlsx-perl-0.27/debian/patches/CVE-2024-22368.patch  
1970-01-01 01:00:00.0 +0100
+++ libspreadsheet-parsexlsx-perl-0.27/debian/patches/CVE-2024-22368.patch  
2024-01-12 21:25:50.0 +0100
@@ -0,0 +1,111 @@
+Description: Fix memory bomb CVE-2024-22368
+Origin: upstream, commits 39b25b9 and 47ff82d, as released in 0.28
+Reviewed-by: gregor herrmann 
+Last-Update: 2024-01-12
+
+
+From 39b25b91fcb939a9c8ea807fdc80386c1ae5be0c Mon Sep 17 00:00:00 2001
+From: MichaelDaum 
+Date: Sun, 31 Dec 2023 11:56:25 +0100
+Subject: [PATCH] fix possible memory bomb
+
+as reported in 
https://github.com/haile01/perl_spreadsheet_excel_rce_poc/blob/main/parse_xlsx_bomb.md
+---
+ lib/Spreadsheet/ParseXLSX.pm | 43 
+ 1 file changed, 29 insertions(+), 14 deletions(-)
+
+
+From 47ff82d74fbd014b8ec3cab80fa4fd25db9e8242 Mon Sep 17 00:00:00 2001
+From: MichaelDaum 
+Date: Sun, 31 Dec 2023 12:23:19 +0100
+Subject: [PATCH] minor rewrite and perltidy
+
+---
+ lib/Spreadsheet/ParseXLSX.pm | 16 +++-
+ 1 file changed, 7 insertions(+), 9 deletions(-)
+
+--- a/lib/Spreadsheet/ParseXLSX.pm
 b/lib/Spreadsheet/ParseXLSX.pm
+@@ -176,8 +176,6 @@ sub _parse_sheet {
+ $sheet->{MaxCol} = -1;
+ $sheet->{Selection} = [ 0, 0 ];
+ 
+-my %merged_cells;
+-
+ my @column_formats;
+ my @column_widths;
+ my @columns_hidden;
+@@ -187,7 +185,6 @@ sub _parse_sheet {
+ my $default_row_height   = 15;
+ my $default_column_width = 10;
+ 
+-my %cells;
+ my $row_idx = 0;
+ 
+ my $sheet_xml = $self->_new_twig(
+@@ -263,11 +260,6 @@ sub _parse_sheet {
+ $toprow, $leftcol,
+ $bottomrow, $rightcol,
+ ];
+-for my $row ($toprow .. $bottomrow) {
+-for my $col ($leftcol .. $rightcol) {
+-$merged_cells{"$row;$col"} = 1;
+-}
+-}
+ }
+ 
+ $twig->purge;
+@@ -415,7 +407,6 @@ sub _parse_sheet {
+ $cell->{_Value} = $sheet->{_Book}{FmtClass}->ValFmt(
+ $cell, $sheet->{_Book}
+ );
+-$cells{"$row;$col"} = $cell;
+ $sheet->{Cells}[$row][$col] = $cell;
+ $col_idx++;
+ }
+@@ -428,11 +419,15 @@ sub _parse_sheet {
+ 
+ $sheet_xml->parse( $sheet_file

Bug#1060189: [Pkg-pascal-devel] Bug#1060189: Bug#1060189: lazarus-src-3.0: diversion handling seems wrong (it works, but after an error)

[Abou Al Montacir]

Hi Paul,

On Fri, 2024-01-12 at 20:12 +0100, Paul Gevers wrote:
> Hi Abou,
> 
> On 11-01-2024 20:40, Abou Al Montacir wrote:
> > But this is the case of all lpk files where the binary package provide a 
> > Manually compilable package while the source one provides a Compile As  >
> > Needed package file.
> 
> Don't we want them to be the same? Why do we even ship the files twice?
They are not the same for the following reasons:

When someone installs only binary packages (let's say an auto build setup) they
don't want to recompile units, and they don't even install sources, so we tell
lazbuild tool to not try to compile the units of this package. This is why the
lcl-units-* binary packages provide lpk fills with .

When a human installs full Lazarus on a desktop/laptop, he will want to install
sources and may need to recompile Lazarus (unfortunately upstream does not
support dynamically linked plugins and thus need to recompile lazarus when you
install some new packages). This will fail with 
and thus we change it to .
> 
> > This was the case since many years now.
> 
> Well, maybe I just didn't spot this issue before. But because of the 
> /usr-merged work of helmut, I'm much more aware of diversions so they'd 
> trigger me much more then they used to.
Makes sense, but I'm not sure I understand why diverted files should be the
same? Isn't diversion is used to enable a package to supersede another shipping
a different version of the same file?
-- 
Cheers,
Abou Al Montacir


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

Bug#1060682: u-boot-sifive: Unable to boot from NVME via SPI on Hifive Unmatched Rev B

[Vagrant Cascadian]

On 2024-01-12, Vagrant Cascadian wrote:
> On 2024-01-12, Vagrant Cascadian wrote:
>> On 2024-01-12, Michael Fladischer wrote:
>>> I was able to boot my Hifive Unmatched Rev B board via SPI from NVME with
>>> u-boot-sifive-2023.07+dfsg-1. After upgrading to 2024.01+dfsg-1 u-boot is no
>>> longer able to see any NVME drives:
> ...
>> I am getting this too. I had tested with a local build of
>> 2024.01~rc6-1~0 and that worked fine, so I am a bit surprised as none of
>> the very few commits between v2024.01-rc6 and v2024.01 seem relevent.
>
> I should also note that I am testing with u-boot on microSD, so it is
> not specific to u-boot from SPI.
>
>> I also wonder about opensbi, which was fairly recently upgraded,
>> although I *thought* I tested opensbi 1.4-1 with the ~rc6 build I had
>> done...
>
> I verified u-boot-sifive 2024.01~rc6+dfsg-2 (formerly in experimental)
> works, which was built with the same opensbi version. In fact, the only
> difference in the installed build-dependencies were perl related:
>
> - libperl5.36 (= 5.36.0-10+b1),
> + libperl5.38 (= 5.38.2-2),
> - perl (= 5.36.0-10+b1),
> - perl-base (= 5.36.0-10+b1),
> - perl-modules-5.36 (= 5.36.0-10),
> + perl (= 5.38.2-2),
> + perl-base (= 5.38.2-2),
> + perl-modules-5.38 (= 5.38.2-2),
>
> I am attempting a local rebuild, will see how that goes...

Well, rebuilding and just adding a new debian/changelog
entry... worked. both from a reboot and from a cold start.

That does not leave much to investigate, so is a bit worrying, but
perhaps a binNMU would "fix" it?

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1060285: mptcpd: FTBFS with a segmentation fault in the testsuite when SCTP disabled and no /etc/protocols

[Aurelien Jarno]

Hi Matthieu,

On 2024-01-12 11:06, Matthieu Baerts wrote:
> Hi Aurélien,
> 
> On 10/01/2024 19:13, Matthieu Baerts wrote:
> > On 08/01/2024 21:18, Aurelien Jarno wrote:
> 
> (...)
> 
> >> In the latest rebuild of mptpcd, the conditions where met only on the
> >> riscv64 buildd, and riscv64 is not a release architecture. That said a
> >> few mips64el buildds also met the 3 conditions and it will be the case
> >> of more and more buildds once they are upgraded to bookworm. I am
> >> therefore filling this issue as severity serious.
> > 
> > Many thanks for the explanation!
> > 
> > I will wait for the different pipelines to be over, before sending a new
> > version to mentors.debian.net!
> 
> This new version has been sent to mentors.debian.net:
> 
> https://mentors.debian.net/package/mptcpd/
> https://mentors.debian.net/debian/pool/main/m/mptcpd/mptcpd_0.12-3.dsc
> 

Thanks for the quick fix, I have just uploaded it!

Cheers
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net

Bug#1059040: libxml2: ABI change? (undefined references)

[Rafael Laboissière]

* Thorsten Glaser  [2024-01-12 17:56]:


On Fri, 12 Jan 2024, Rafael Laboissière wrote:

experimental, the configure script does detect the absence of the 
xmlNanoFTPNewCtxt function in the libxml2 library (version 
2.12.3+dfsg-0exp1) and disables the call to the xmlNanoFTP* functions. 
However, this rebuilt will not be automatically triggered without a 
bump in the SONAME version of libxml2.


In summary, the introduction of version 2.12 of libxml2 in unstable 
will need a proper and coordinated transition.


No, this will still break partial upgrades.

Losing symbols needs a major shlib version change *including*, in 
Debian, changing the binary package name so that the old and new 
shlibs are coïnstallable.


And this needs to be exercised in experimental first, not only 
when introducing this to unstable.


Alternatively, bring the symbols back.


Thanks for the clarification, this is exactly what I meant. I apologized 
for not being clear enough.


Best,

Rafael Laboissière

Bug#1060687: libwacom-dev: Needs Depends: libevdev-dev

[Jeremy Bícha]

Source: libwacom
Version: 2.9.0-1
Severity: serious

libwacom.pc now has this line:

Requires.private: gudev-1.0, glib-2.0, libevdev

Therefore, please add libevdev-dev to libwacom-dev's Depends.

I noticed this issue when building another package that uses libwacom
but it was also detected by autopkgtests.

Thank you,
Jeremy Bícha

Bug#1056764: grub-efi-amd64: can't boot with GRUB 2.12~rc1-12

[debian]

Good day,

does grub 2.12 (without rc1) help? There are a good pile of fixups
between rc1 and release. E.g.
https://git.savannah.gnu.org/cgit/grub.git/commit/?h=grub-2.12&id=1f5b180742ff2706bc3a696d115ddbc677ec75b9
or
https://git.savannah.gnu.org/cgit/grub.git/commit/?h=grub-2.12&id=67ae3981dc5113e5af3a0539174bcd7eab8f7722
could help.

Additionally, the ZFS fixes are needed to boot from volumes touched by
ZFS 2.2 ( https://github.com/openzfs/zfs/issues/13873 ), so migrating to
2.12 is helpful in either case.

Best regards,
Michael Fritscher

On Sat, 25 Nov 2023 17:36:41 -0500 Nicolas Haller
 wrote:
> Package: grub-efi-amd64
> Version: 2.06-13
> Severity: critical
> Justification: breaks the whole system
> 
> Dear Maintainer,
> 
> My old laptop (Lenovo 11e) runs Sid and all was right before I updated
> it the other day (I don't do that very often). After that upgrade, GRUB
> wasn't able to load any kernel with the pretty much generic error
> "Error: can't load image". The version of GRUB was 2.12~rc1-12.
> If I try to boot again, GRUB tells me that I need to load the image
> first (I guess it somehow ignores the linux command and sends that when
> trying to load the initrd).
> 
> I tried to reinstall grub, grub-install /dev/sda, update-grub, reinstall
> the kernel, update-initramfs from the rescue mode but nothing worked.
> The "file" command was able to read the vmlinuz file and none seemed
> truncated. The system has one partition with both / and /boot and isn't
> running out of space.
> I did not see any error message during those operation besides GRUB
> saying it wasn't able to update EFI parameters.
> 
> I don't know if there is a way to get more logs or error message during
> the boot explaining why it wasn't able to load the image.
> 
> I tried to get the last version of GRUB from Bookworm, that is
> 2.06-13, and now I'm able to boot. The kernel version did not change,
>   the only change I did is to downgrade GRUB (and dependencies apt was
>   asking for).
> 
> I'm not sure which GRUB package I should use for reporting so I took the
> one that seems the most specific to my system. Apologies if it is not
> correct.
> 
> Let me know if you need more info.
> 
> Thanks,
> 
> -- 
> Nicolas Haller
> 
> *** 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 ***
> 
> 
> -- Package-specific info:
> 
> *** BEGIN /proc/mounts
> /dev/sda2 / ext4 rw,relatime,errors=remount-ro 0 0
> /dev/sda1 /boot/efi vfat 
> rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
>  0 0
> *** END /proc/mounts
> 

Bug#1060682: u-boot-sifive: Unable to boot from NVME via SPI on Hifive Unmatched Rev B

[Vagrant Cascadian]

On 2024-01-12, Vagrant Cascadian wrote:
> On 2024-01-12, Michael Fladischer wrote:
>> I was able to boot my Hifive Unmatched Rev B board via SPI from NVME with
>> u-boot-sifive-2023.07+dfsg-1. After upgrading to 2024.01+dfsg-1 u-boot is no
>> longer able to see any NVME drives:
...
> I am getting this too. I had tested with a local build of
> 2024.01~rc6-1~0 and that worked fine, so I am a bit surprised as none of
> the very few commits between v2024.01-rc6 and v2024.01 seem relevent.

I should also note that I am testing with u-boot on microSD, so it is
not specific to u-boot from SPI.

> I also wonder about opensbi, which was fairly recently upgraded,
> although I *thought* I tested opensbi 1.4-1 with the ~rc6 build I had
> done...

I verified u-boot-sifive 2024.01~rc6+dfsg-2 (formerly in experimental)
works, which was built with the same opensbi version. In fact, the only
difference in the installed build-dependencies were perl related:

- libperl5.36 (= 5.36.0-10+b1),
+ libperl5.38 (= 5.38.2-2),
- perl (= 5.36.0-10+b1),
- perl-base (= 5.36.0-10+b1),
- perl-modules-5.36 (= 5.36.0-10),
+ perl (= 5.38.2-2),
+ perl-base (= 5.38.2-2),
+ perl-modules-5.38 (= 5.38.2-2),

I am attempting a local rebuild, will see how that goes...

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1060682: u-boot-sifive: Unable to boot from NVME via SPI on Hifive Unmatched Rev B

[Vagrant Cascadian]

On 2024-01-12, Michael Fladischer wrote:
> I was able to boot my Hifive Unmatched Rev B board via SPI from NVME with
> u-boot-sifive-2023.07+dfsg-1. After upgrading to 2024.01+dfsg-1 u-boot is no
> longer able to see any NVME drives:
...
>U-Boot 2024.01+dfsg-1 (Jan 10 2024 - 21:34:04 +)
>
>CPU:   rv64imafdc
>Model: SiFive HiFive Unmatched A00
>DRAM:  16 GiB
>Core:  34 devices, 21 uclasses, devicetree: separate
>MMC:   spi@1005:mmc@0: 0
>Loading Environment from SPIFlash... SF: Detected is25wp256 with page size 
> 256 Bytes, erase size 4 KiB, total 32 MiB
>*** Warning - bad CRC, using default environment
>
>EEPROM: SiFive PCB EEPROM format v1
>Product ID: 0002 (HiFive Unmatched)
>PCB revision: 4
>BOM revision: B
>BOM variant: 0
>Serial number: SF105SZ233800886
>Ethernet MAC address: 70:b3:d5:92:fe:ea
>CRC: d2ac1d5b
>pwren_gpio is invalid
>In:serial@1001
>Out:   serial@1001
>Err:   serial@1001
>Model: SiFive HiFive Unmatched A00
>Net:   eth0: ethernet@1009
>Working FDT set to ff72f630
>Hit any key to stop autoboot:  0
>pwren_gpio is invalid
>
>Device 0: unknown device
>pwren_gpio is invalid
>
>Device 1: unknown device
>starting USB...
>No working controllers found
>USB is stopped. Please issue 'usb start' first.
>pwren_gpio is invalid
>scanning bus for devices...

I am getting this too. I had tested with a local build of
2024.01~rc6-1~0 and that worked fine, so I am a bit surprised as none of
the very few commits between v2024.01-rc6 and v2024.01 seem relevent.

I also wonder about opensbi, which was fairly recently upgraded,
although I *thought* I tested opensbi 1.4-1 with the ~rc6 build I had
done...

Hrm. Will look a little deeper.

I doubt it ws the removed
unmatched-prevent-relocating-initrd-and-fdt.patch, as it is not even
detecting the NVMe device... and the symptoms that necessitated that
patch are after extlinux.conf is already loaded and the kernel attempts
to boot...

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1060455: awscli: Please drop python-cryptography upper limit or increase it

[Noah Meyerhans]

On Thu, Jan 11, 2024 at 02:27:23PM -0500, Jeremy Bícha wrote:
> There is a diff at
> https://launchpad.net/ubuntu/+source/awscli/2.14.6-1ubuntu1 for this
> issue. You can ignore the build failure since that doesn't seem to
> currently affect Debian Unstable.

Thanks, I've applied that patch and will include it with the upcoming
2.15.9-1 package.

Bug#1060686: python-httpretty: please remove extraneous dependency on python3-six

[Alexandre Detiste]

Source: python-httpretty
Severity: normal

please remove extraneous dependency on python3-six


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (501, 'testing'), (450, 'unstable'), (400, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-5-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1024149: linux-image-amd64: 32-bit mmap() puts large files at non-random address

[Andres Salomon]

On Sat, 14 Jan 2023 16:12:47 +0100 Salvatore Bonaccorso 
 wrote:

> Hi Jakub,
>
> On Thu, Jan 12, 2023 at 01:24:16PM +0100, Jakub Wilk wrote:
> > * Salvatore Bonaccorso , 2022-11-19 11:11:
> > > Given you were able to tackle the issue further, can you report 
the

> > > issue to upstream
> >
> > Don't count on me. Sorry!
>
> Okay thanks for beeing explicit on that. Then I guess it's on our end
> to try to get that upstream.
>
> Regards,
> Salvatore
>
>

This bug seems to also affect 64-bit mmap (though not nearly as badly), 
and is written about here:


https://zolutal.github.io/aslrnt/

Bug#1060448: debcheckout: deprecation warnings with perl 5.38

[Sven Joachim]

On 2024-01-11 17:59 +0100, Sven Joachim wrote:

> Package: devscripts
> Version: 2.23.7
>
> After upgrading perl from 5.36.0 to 5.38.2, debcheckout displays some
> twenty deprecation warnings:
>
> ,
> | $ debcheckout etckeeper
> | given is deprecated at /usr/bin/debcheckout line 419.
> | when is deprecated at /usr/bin/debcheckout line 420.
> | when is deprecated at /usr/bin/debcheckout line 424.
> | given is deprecated at /usr/bin/debcheckout line 464.
> | when is deprecated at /usr/bin/debcheckout line 465.
> | when is deprecated at /usr/bin/debcheckout line 469.
> | given is deprecated at /usr/bin/debcheckout line 513.
> | when is deprecated at /usr/bin/debcheckout line 514.
> | when is deprecated at /usr/bin/debcheckout line 515.
> | when is deprecated at /usr/bin/debcheckout line 516.
> | when is deprecated at /usr/bin/debcheckout line 522.
> | when is deprecated at /usr/bin/debcheckout line 523.
> | when is deprecated at /usr/bin/debcheckout line 547.
> | when is deprecated at /usr/bin/debcheckout line 548.
> | given is deprecated at /usr/bin/debcheckout line 605.
> | when is deprecated at /usr/bin/debcheckout line 606.
> | when is deprecated at /usr/bin/debcheckout line 637.
> | when is deprecated at /usr/bin/debcheckout line 682.
> | when is deprecated at /usr/bin/debcheckout line 700.
> | when is deprecated at /usr/bin/debcheckout line 761.
> `
>
> According to the perldeprecation manpage, "given" and "when" are
> scheduled for removal in Perl 5.42:
>
> ,
> |Perl 5.42
> |Smartmatch
> |
> |Smartmatch is now seen as a failed experiment and was marked as
> |deprecated in Perl 5.37.10. This includes the "when" and "given"
> |keywords, as well as the smartmatch operator "~~". The feature
> |will be removed entirely in the Perl 5.42.0 production release.
> |
> |Category: "deprecated::smartmatch"
> `

There is one more program in devscripts which uses the hitherto
experimental and now deprecated keywords, namely chdist:

,
| $ chdist -h > /dev/null
| given is deprecated at /usr/bin/chdist line 710.
| when is deprecated at /usr/bin/chdist line 711.
| when is deprecated at /usr/bin/chdist line 714.
| when is deprecated at /usr/bin/chdist line 717.
| when is deprecated at /usr/bin/chdist line 720.
| when is deprecated at /usr/bin/chdist line 723.
| when is deprecated at /usr/bin/chdist line 726.
| when is deprecated at /usr/bin/chdist line 729.
| when is deprecated at /usr/bin/chdist line 732.
| when is deprecated at /usr/bin/chdist line 735.
| when is deprecated at /usr/bin/chdist line 738.
| when is deprecated at /usr/bin/chdist line 741.
| when is deprecated at /usr/bin/chdist line 744.
| when is deprecated at /usr/bin/chdist line 747.
| when is deprecated at /usr/bin/chdist line 750.
| when is deprecated at /usr/bin/chdist line 753.
| when is deprecated at /usr/bin/chdist line 756.
| when is deprecated at /usr/bin/chdist line 759.
| when is deprecated at /usr/bin/chdist line 762.
`

Cheers,
   Sven

Bug#1058661: [Debian-med-packaging] Bug#1058661: dipy: slow (sometimes timing out) autopkgtest

[Étienne Mollier]

Control: severity -1 important

Rebecca N. Palmer, on 2023-12-14:
> This autopkgtest, and particularly test_reconstruct_rumba, is slow enough
> that it sometimes times out and fails.  I think this is varying hardware
> speed and not a random hang because failure seems to correlate with the
> earlier tests taking longer.

dipy 1.8.0-1 took more than thirteen hours to build on riscv64
machine rv-manda-01[1].  Bumping the severity because this looks
a tad bit excessive.

[1]: 
https://buildd.debian.org/status/fetch.php?pkg=dipy&arch=riscv64&ver=1.8.0-1&stamp=1705009202&raw=0

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/5, please excuse my verbosity
   `-on air: Fleesh - Burning Rope


signature.asc
Description: PGP signature

Bug#1021370: pipewire: build with bluez5-codec-aac=enabled

[Jeremy Bícha]

On Fri, Jan 12, 2024 at 11:12 AM Max Nikulin  wrote:
> On Fri, 07 Oct 2022 00:11:56 +0200 KeyofBlueS wrote:
> >
> > please build pipewire with aac codec support enabled.
>
> An alternative may be building a separate package for the contrib
> repository section that contains just the aac codec plugin.

I would prefer getting fdk-aac-free into Debian main. It has been in
the NEW queue for roughly 2 years.

Thank you,
Jeremy Bícha

Bug#1060189: [Pkg-pascal-devel] Bug#1060189: lazarus-src-3.0: diversion handling seems wrong (it works, but after an error)

[Paul Gevers]

Hi Abou,

On 11-01-2024 20:40, Abou Al Montacir wrote:
But this is the case of all lpk files where the binary package provide a 
Manually compilable package while the source one provides a Compile As  > Needed package file.


Don't we want them to be the same? Why do we even ship the files twice?


This was the case since many years now.


Well, maybe I just didn't spot this issue before. But because of the 
/usr-merged work of helmut, I'm much more aware of diversions so they'd 
trigger me much more then they used to.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060685: jbig2dec: typo in debian/copyright

[Jakub Wilk]

Source: jbig2dec
Version: 0.19-3
Severity: minor

Please do s/pubic/public/ in debian/copyright.

--
Jakub Wilk

Bug#1059553: closed by Debian FTP Masters (reply to John Ogness ) (Bug#1059553: fixed in minicoredumper 2.0.7-2)

[Paul Gevers]

Hi,

On 12-01-2024 08:51, Debian Bug Tracking System wrote:

  minicoredumper (2.0.7-2) unstable; urgency=medium
  .
* Fix autopackage test due to missing dependency (Closes: #1059553)


https://ci.debian.net/data/autopkgtest/testing/amd64/m/minicoredumper/41783082/log.gz

 40s Starting minicoredumper (via systemctl): minicoredumper.service.
 40s Segmentation fault (core dumped)
 40s core
 40s   Type:  CORE (Core file)
 40s Stopping minicoredumper (via systemctl): minicoredumper.service.
 40s autopkgtest [15:27:31]: test coredump: ---]
 41s autopkgtest [15:27:32]: test coredump:  - - - - - - - - - - 
results - - - - - - - - - -

 41s coredump FAIL stderr: Segmentation fault (core dumped)

By default, autopkgtest considers output on stderr a failure. You 
probably want to set the allow-stderr restriction.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR?

[Francesco Poli]

On Thu, 11 Jan 2024 21:04:16 +0100 Johannes Schauer Marin Rodrigues wrote:

[...]
> Do you see yourself debugging this further by yourself? You probably 
> understand
> that it's hard for me to investigate something that I cannot test myself.

Well, you wrote the script, together with Helmut Grohne (who reads us
in Cc).
I rather see myself helping the two of you in debugging it...   :-)

I've just performed another test, setting a much smaller size for the
image to be created:

  $ TMPDIR=/dev/shm mmdebstrap-autopkgtest-build-qemu \
--size=2G --boot=efi sid sid_amd64.img

but the result was the same exact error that I have previously reported
in the original [bug] report.

[bug]: 

Hence, it seems to me that the issue is not with the size of the
filesystem where the temporary directory is created.

Indeed, the error does not seem to have anything to do with a "No space
left on device" failure:

[...]
  mke2fs 1.47.0 (5-Feb-2023)
  mkfs.ext4: Permission denied while trying to determine filesystem size
  E: setup failed: E: command failed: /sbin/mkfs.ext4 -d "$1/mnt" -L 
autopkgtestvm -E 'offset=134217728,assume_storage_prezeroed=1' 'sid_amd64.img' 
'25G'
[...]

What can cause mkfs.ext4 to fail with a "Permission denied" error?



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpwrRkROgULm.pgp
Description: PGP signature

Bug#1059525: linux-image-6.1.0-16-amd64: Secure Boot is active but mokutil and dmesg says "Secure boot disabled" but just with an NVME not with an HDD/SSD

[.]

In a Debian Testing System one of the packages solved my problem. Secure 
Boot is now displayed as active.


Start-Date: 2024-01-12  18:59:31
Commandline: apt full-upgrade
Requested-By: user (1000)
Upgrade: orca:amd64 (45.1-2, 45.2-1), dmeventd:amd64 (2:1.02.185-2, 
2:1.02.185-3), libldb2:amd64 (2:2.8.0+samba4.19.3+dfsg-2, 
2:2.8.0+samba4.19.4+dfsg-2), libgs10-common:amd64 (10.02.1~dfsg-1, 
10.02.1~dfsg-2), liblua5.4-0:amd64 (5.4.6-1, 5.4.6-2), 
liblvm2cmd2.03:amd64 (2.03.16-2, 2.03.16-3), libgs10:amd64 
(10.02.1~dfsg-1, 10.02.1~dfsg-2), logrotate:amd64 (3.21.0-1, 3.21.0-2), 
libwbclient0:amd64 (2:4.19.3+dfsg-2, 2:4.19.4+dfsg-2), 
libsmbclient:amd64 (2:4.19.3+dfsg-2, 2:4.19.4+dfsg-2), lvm2:amd64 
(2.03.16-2, 2.03.16-3), ghostscript:amd64 (10.02.1~dfsg-1, 
10.02.1~dfsg-2), gir1.2-ibus-1.0:amd64 (1.5.29~rc2-1, 1.5.29-1), 
grep:amd64 (3.11-3, 3.11-4), libopenni2-0:amd64 (2.2.0.33+dfsg-17, 
2.2.0.33+dfsg-18), dmsetup:amd64 (2:1.02.185-2, 2:1.02.185-3), 
libdevmapper-event1.02.1:amd64 (2:1.02.185-2, 2:1.02.185-3), 
samba-libs:amd64 (2:4.19.3+dfsg-2, 2:4.19.4+dfsg-2), libgs-common:amd64 
(10.02.1~dfsg-1, 10.02.1~dfsg-2), libibus-1.0-5:amd64 (1.5.29~rc2-1, 
1.5.29-1), libdevmapper1.02.1:amd64 (2:1.02.185-2, 2:1.02.185-3)

End-Date: 2024-01-12  18:59:53

Bug#1059995: pdns: flaky autopkgtest (host dependent): pdns.service: Failed to set up IPC namespacing: Resource temporarily unavailable

[Paul Gevers]

Hi,

On 12-01-2024 12:36, Chris Hofstaedtler wrote:

can you confirm two additional things please:

1) this happens only on the large host?


https://ci.debian.net/packages/p/pdns/testing/s390x/41650331/

Seems it happens on our s390x host too (which has 10 debci workers 
running in parallel).



2) this does not or does happen with other packages also requesting
the same settings from systemd, e.g. dnsdist or pdns-recursor?


https://ci.debian.net/packages/d/dnsdist/ -> Page not found.

pdns-recursor seems to be flaky as well on amd64 and all passing tests 
were on one of the smaller hosts. pdns-recursor passes on s390x though.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060684: gnome-shell: still recommends chrome-gnome-shell and why not gnome-browser-connector?

[Patrice Duroux]

Package: gnome-shell
Version: 45.3-1
Severity: wishlist

Dear Maintainer,

I think that chrome-gnome-shell is a transitional package,
at least already in bookworm.
Shouldn't this be replaced by gnome-browser-connector or as an alternative
clause?

Regards,
Patrice


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

Kernel: Linux 6.6.9-amd64 (SMP w/12 CPU threads; PREEMPT)
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 gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4+b1
ii  gir1.2-accountsservice-1.0   23.13.9-5+b1
ii  gir1.2-adw-1 1.4.2-1+b1
ii  gir1.2-atk-1.0   2.50.0-1+b1
ii  gir1.2-atspi-2.0 2.50.0-1+b1
ii  gir1.2-freedesktop   1.78.1-6
ii  gir1.2-gcr-3 3.41.1-4
ii  gir1.2-gdesktopenums-3.0 45.0-2
ii  gir1.2-gdkpixbuf-2.0 2.42.10+dfsg-3
ii  gir1.2-gdm-1.0   45.0.1-2
ii  gir1.2-geoclue-2.0   2.7.1-1
ii  gir1.2-glib-2.0  1.78.1-6
ii  gir1.2-gnomebg-4.0   44.0-2
ii  gir1.2-gnomebluetooth-3.042.7-2
ii  gir1.2-gnomedesktop-4.0  44.0-2
ii  gir1.2-graphene-1.0  1.10.8-3
ii  gir1.2-gstreamer-1.0 1.22.8-1
ii  gir1.2-gtk-4.0   4.12.4+ds-3
ii  gir1.2-gweather-4.0  4.4.0-1
ii  gir1.2-ibus-1.0  1.5.29-1
ii  gir1.2-mutter-13 45.3-1
ii  gir1.2-nm-1.01.44.2-7
ii  gir1.2-nma4-1.0  1.10.6-2
ii  gir1.2-pango-1.0 1.51.0+ds-3
ii  gir1.2-polkit-1.0123-3
ii  gir1.2-rsvg-2.0  2.54.7+dfsg-2
ii  gir1.2-soup-3.0  3.4.4-2
ii  gir1.2-upowerglib-1.01.90.2-8
ii  gir1.2-webkit-6.02.42.4-1
ii  gnome-backgrounds45.0-1
ii  gnome-settings-daemon45.1-1
ii  gnome-shell-common   45.3-1
ii  gsettings-desktop-schemas45.0-2
ii  gstreamer1.0-pipewire1.0.1-1
ii  libatk-bridge2.0-0   2.50.0-1+b1
ii  libatk1.0-0  2.50.0-1+b1
ii  libc62.37-13
ii  libcairo21.18.0-1+b1
ii  libecal-2.0-23.50.3-1
ii  libedataserver-1.2-273.50.3-1
ii  libgcr-base-3-1  3.41.1-4
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3
ii  libgirepository-1.0-11.78.1-6
ii  libgjs0g 1.78.2-2
ii  libgles2 1.7.0-1
ii  libglib2.0-0 2.78.3-1
ii  libglib2.0-bin   2.78.3-1
ii  libgnome-autoar-0-0  0.4.4-2
ii  libgnome-desktop-4-2 44.0-2
ii  libgraphene-1.0-01.10.8-3
ii  libgtk-4-1   4.12.4+ds-3
ii  libical3 3.0.17-1
ii  libjson-glib-1.0-0   1.8.0-2
ii  libmutter-13-0   45.3-1
ii  libnm0   1.44.2-7
ii  libpango-1.0-0   1.51.0+ds-3
ii  libpipewire-0.3-01.0.1-1
ii  libpolkit-agent-1-0  123-3
ii  libpolkit-gobject-1-0123-3
ii  libpulse-mainloop-glib0  16.1+dfsg1-3
ii  libpulse016.1+dfsg1-3
ii  libsecret-1-00.21.2-1
ii  libsystemd0  255.2-4
ii  libx11-6 2:1.8.7-1
ii  libxfixes3   1:6.0.0-2
ii  python3  3.11.6-1

Versions of packages gnome-shell recommends:
ii  bolt   0.9.6-2
pn  chrome-gnome-shell 
ii  evolution-data-server  3.50.3-1
ii  gdm3   45.0.1-2
ii  gkbd-capplet   3.28.1-1
ii  gnome-control-center   1:46~alpha-2
ii  gnome-menus  

Bug#1060683: RFS: git-credential-oauth/0.11.0-1~bpo12 1 -- Git credential helper for GitHub and other forges using OAuth

[M Hickford]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: debian...@lists.debian.org

Dear mentors,

I am looking for a sponsor for my package "git-credential-oauth":

 * Package name : git-credential-oauth
   Version  : 0.11.0-1~bpo12+1
   Upstream contact : M Hickford 
 * URL  : https://github.com/hickford/git-credential-oauth
 * License  : Apache-2.0
 * Vcs  :
https://salsa.debian.org/go-team/packages/git-credential-oauth
   Section  : golang

The source builds the following binary packages:

  git-credential-oauth - Git credential helper for GitHub and other
forges using OAuth

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

  https://mentors.debian.net/package/git-credential-oauth/

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

  dget -x
https://mentors.debian.net/debian/pool/main/g/git-credential-oauth/git-credential-oauth_0.11.0-1~bpo12+1.dsc

Changes since the last upload:

 git-credential-oauth (0.11.0-1~bpo12+1) bookworm-backports; urgency=medium
 .
   * Rebuild for bookworm-backports.

Regards,

Bug#1041275: sbuild: Using eatmydata with the unshare backend

[Andrea Pappacoda]

Hi Jochen, thanks for the reply!

On Fri Jan 5, 2024 at 1:17 PM CET, Jochen Sprickerhof wrote:
> Given enough RAM you can use a tmpfs like this:
>
> $unshare_tmpdir_template = '/dev/shm/tmp.sbuild.XX';

That's great, thanks! I also noticed that it is in the sbuild Wiki, but
I guess I missed it :)

Still, it'd be nice to be able to use eatmydata in cases where RAM isn't
enough. But thanks!

I know this isn't the best place to ask, but speaking of the wiki I'd
like to add a section about configuring sbuild to run autopkgtest when
using the unshare backend, since I haven't been able to do it myself and
I think could be helpful to others. If you know how to do it, please let
me know!

Bye :)

Bug#1060651: mc: doesn't fully resize itself if reading directory while terminal's resized

[Michael Gold]

On Fri, Jan 12, 2024 at 03:07:04 +, Michael Gold wrote:
> I'm experimenting with an automated version of this test, but don't know
> how reliable it will be.

The attached test case seems able to determine the width of the panels.
Without proper xterm-control and UTF-8 parsing, it may be fragile.

To build and run:
  gcc -shared -o readdir-wait.so readdir-wait.c
  gcc mc-terminal-resize-during-readdir.c
  ./a.out
Or run "./a.out -P" to skip the $LD_PRELOAD setting, in which case the
signal isn't likely to come during readdir() and we'll measure a width
of 90 columns, as expected.  So, I suspect it will print "PASS" if the
bug is fixed, but I don't know for sure.

-- Michael
// Verify that mc resizes its panel(s) properly when the terminal is resized.
// See https://bugs.debian.org/1060651#.

/*
This is free and unencumbered software released into the public domain.

Anyone is free to copy, modify, publish, use, compile, sell, or
distribute this software, either in source code form or as a compiled
binary, for any purpose, commercial or non-commercial, and by any
means.

In jurisdictions that recognize copyright laws, the author or authors
of this software dedicate any and all copyright interest in the
software to the public domain. We make this dedication for the benefit
of the public at large and to the detriment of our heirs and
successors. We intend this dedication to be an overt act of
relinquishment in perpetuity of all present and future rights to this
software under copyright law.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
OTHER DEALINGS IN THE SOFTWARE.

For more information, please refer to 
*/

#define _POSIX_C_SOURCE 200809L
#define _XOPEN_SOURCE 700
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 


struct measurer_arg {
int pty_master;
unsigned saw_width;
};

static void
die_perror(const char *str)
{
perror(str);
exit(EXIT_FAILURE);
}

static void
die_usage(const char *name)
{
fprintf(stderr, "Usage: %s\n", name);
exit(2);
}

static unsigned
utf8_measure_badly(const uint8_t *p)
{
// this is just good enough to parse mc's output, at the time of
// writing; we don't want any embedded control sequences, double-width
// or combining characters, or any other weird surprises
int ret = 0;
for (; *p; p++) {
if (*p >= 240) --ret;
if (*p >= 224) --ret;
if (*p >= 192) --ret;
++ret;
}
return (ret < 0) ? 0 : (unsigned)ret;
}

static unsigned
measure_panel_width(const uint8_t *buf)
{
// find the last instance of U+2514 BOX DRAWINGS LIGHT UP AND RIGHT
// (at the bottom-left corner of the rightmost panel) before mc exited
const uint8_t *u2514 = "\xe2\x94\x94";
uint8_t *p;

p = (uint8_t*)strstr((char*)buf, u2514);
while (p) {
uint8_t *q = (uint8_t*)strstr((char*)&p[1], u2514);
if (!q) break;
p = q;
}
if (!p) {
return 0;
}

// rewind to the last control character
while ((p > buf) && (*p >= 32)) {
--p;
}

// if at an escape sequence, move to its end
if (*p == '\x1b') {
while (*p && !isalpha((int)*p) ) {
++p;
}
}
++p;

// p should now be pointing at the beginning of the panel-bottom-drawing
// sequence.  We assume mc draws the bottom of all visible panels as one
// uninterrupted sequence.

// cut at the end of the line, or an escape sequence
{
char *dummy;
strtok_r((char*)p, "\r\n\x1b", &dummy);
}
return utf8_measure_badly(p);
}

static void*
measurer(void *arg_)
{
struct measurer_arg *arg = arg_;
int err = 0;
ssize_t rv;
size_t bufsize = 1024 * 1024, i = 0;

uint8_t *buf = malloc(bufsize);
if (!buf) {
die_perror("malloc");
}

while (i < bufsize - 1) {
rv = read(arg->pty_master, &buf[i], bufsize - 1 - i);
if (rv < 0) {
// On Linux, we get EIO when mc exits
if (EIO == errno) break;
die_perror("measurer:read");
} else if (!rv) {
break;
}
i += (size_t)rv;
}
buf[i] = '\0';
arg

Bug#1060456: rxvt-unicode: 9.31-1+b1 breaks UTF-8 display

[Niko Tyni]

On Fri, Jan 12, 2024 at 04:35:04PM +0100, Sven Joachim wrote:

> Speaking of Perl 5.38, this bug is actually a problem in Perl.  The
> rxvt-unicode patch just works around it.  According to the Perl upstream
> bug (https://github.com/Perl/perl5/issues/21366), at least one other
> application (irssi) is affected.
> 
> Fedora has apparently reverted a commit in Perl to fix the problem, see
> https://src.fedoraproject.org/rpms/perl/c/dee564d443debbf47127d668f0982165835d873b.

Thanks! I've done the same in perl_5.38.2-3, just uploaded.
-- 
Niko

Bug#1042989: ITP: Incus -- Powerful system container and virtual machine manager

[Mathias Gibbens]

  Incus 0.4 has been uploaded to NEW.

Mathias


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

Bug#1059222: src:pv: fails to migrate to testing for too long: FTBFS on armhf

[Andrew Wood]

> This is a quick word to let you know that I've disabled valgrind tests
> on armhf in the Debian package. They were failing since the 1.8.5 upload
> [...]

Thank you, I agree with this approach.  The evidence I have seen so far
suggests that the failures are due to issues with the way valgrind itself
behaves on that architecture.

-- 
Andrew Wood

Bug#1040183: [Pkg-zfsonlinux-devel] Bug#1040183: zfs-initramfs: snapshots for rootfs mounted in /root/.zfs/snapshot

[наб]

On Fri, Jan 12, 2024 at 07:12:34AM +, 陈 晟祺 wrote:
> Seems .zfs/ of you home dataset goes wrongly to /.zfs, which is really weird,
> since they are mounted in the different stage of booting sequence.
> I don’t think it is the same problem as this report.
> You might want to create a new report (and to upstream).
Forwarded to https://github.com/openzfs/zfs/issues/15766.


signature.asc
Description: PGP signature

Bug#1060457: /usr/sbin/exim4: SIGSEGV when remote smtp reject the message

[Andreas Metzler]

On 2024-01-11 Giuseppe Sacco  wrote:
> Package: exim4-daemon-heavy
> Version: 4.96-15+deb12u4
> Severity: normal
> File: /usr/sbin/exim4

> Dear Maintainer,
> I keep finding many messages like this one in paniclog:

> 2024-01-11 09:55:20 1rNqqH-008cnX-0s SIGSEGV (fault address: 0x58)
> 2024-01-11 09:55:20 1rNqqH-008cnX-0s SEGV_MAPERR
> 2024-01-11 09:55:20 1rNqqH-008cnX-0s SIGSEGV (null pointer indirection)
> 2024-01-11 09:55:20 1rNqqH-008cnX-0s SIGSEGV (2055771 delivering 
> 1rNqqH-08cnX-0s: just tried mx01.mail.icloud.com [17.57.152.5] for 
> usern...@me.com: result OK
> )
> 2024-01-11 09:55:20 1rNqqH-008cnX-0s Delivery status for usern...@me.com: got 
> 0 of 7 bytes (pipeheader) from transport process 2055771 for transport smtp
[...]

Is this a regression in 4.96-15+deb12u4? i.e. can you still reprroduce
the issue after downgrading exim4-daemon-heavy to 4.96-15+deb12u3 [1]
(and re-reproduce after upgrading again)?

cu Andreas

[1] 
http://ftp.debian.org/debian/pool/main/e/exim4/exim4-daemon-heavy_4.96-15+deb12u3_amd64.deb

Bug#1060422: partman-crypto: add support for new cryptsetup options for opal/sed

[Holger Levsen]

On Thu, Jan 11, 2024 at 07:55:18PM +, Luca Boccassi wrote:
> Thank you for the feedback, MR on Salsa is updated as described.

<3


-- 
cheers,
Holger

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

The average US president has been charged with 2 felonies: #45 with 91 and
the others with 0.


signature.asc
Description: PGP signature

Bug#1059040: libxml2: ABI change? (undefined references)

[Thorsten Glaser]

On Fri, 12 Jan 2024, Rafael Laboissière wrote:

> experimental, the configure script does detect the absence of the
> xmlNanoFTPNewCtxt function in the libxml2 library (version
> 2.12.3+dfsg-0exp1) and disables the call to the xmlNanoFTP* functions.
> However, this rebuilt will not be automatically triggered without a
> bump in the SONAME version of libxml2.
>
> In summary, the introduction of version 2.12 of libxml2 in unstable
> will need a proper and coordinated transition.

No, this will still break partial upgrades.

Losing symbols needs a major shlib version change *including*, in
Debian, changing the binary package name so that the old and new
shlibs are coïnstallable.

And this needs to be exercised in experimental first, not only
when introducing this to unstable.

Alternatively, bring the symbols back.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#1042590: [Pending] django-session-security: FTBFS with Sphinx 7.1, docutils 0.20: error: invalid command 'build_sphinx'

[Andreas Tille]

Control: tags -1 pending

Hi,

I've fixed this problem in Git[1] but did not uploaded since autopkgtest
is failing in Salsa CI[2].

Kind regards
   Andreas.


[1] 
https://salsa.debian.org/python-team/packages/django-session-security/-/commit/af1ebc734a33cf1b629a2626bad508b833eb2706
[2] 
https://salsa.debian.org/python-team/packages/django-session-security/-/jobs/5150104

-- 
http://fam-tille.de

Bug#1060682: u-boot-sifive: Unable to boot from NVME via SPI on Hifive Unmatched Rev B

[Michael Fladischer]

Package: u-boot-sifive
Version: 2024.01+dfsg-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

I was able to boot my Hifive Unmatched Rev B board via SPI from NVME with
u-boot-sifive-2023.07+dfsg-1. After upgrading to 2024.01+dfsg-1 u-boot is no
longer able to see any NVME drives:

   U-Boot SPL 2024.01+dfsg-1 (Jan 10 2024 - 21:34:04 +)
   Trying to boot from SPI


   U-Boot 2024.01+dfsg-1 (Jan 10 2024 - 21:34:04 +)

   CPU:   rv64imafdc
   Model: SiFive HiFive Unmatched A00
   DRAM:  16 GiB
   Core:  34 devices, 21 uclasses, devicetree: separate
   MMC:   spi@1005:mmc@0: 0
   Loading Environment from SPIFlash... SF: Detected is25wp256 with page size 
256 Bytes, erase size 4 KiB, total 32 MiB
   *** Warning - bad CRC, using default environment

   EEPROM: SiFive PCB EEPROM format v1
   Product ID: 0002 (HiFive Unmatched)
   PCB revision: 4
   BOM revision: B
   BOM variant: 0
   Serial number: SF105SZ233800886
   Ethernet MAC address: 70:b3:d5:92:fe:ea
   CRC: d2ac1d5b
   pwren_gpio is invalid
   In:serial@1001
   Out:   serial@1001
   Err:   serial@1001
   Model: SiFive HiFive Unmatched A00
   Net:   eth0: ethernet@1009
   Working FDT set to ff72f630
   Hit any key to stop autoboot:  0
   pwren_gpio is invalid

   Device 0: unknown device
   pwren_gpio is invalid

   Device 1: unknown device
   starting USB...
   No working controllers found
   USB is stopped. Please issue 'usb start' first.
   pwren_gpio is invalid
   scanning bus for devices...

   Device 0: unknown device
   starting USB...
   No working controllers found
   pwren_gpio is invalid
   ethernet@1009: PHY present at 0
   ethernet@1009: Starting autonegotiation...
   ethernet@1009: Autonegotiation complete
   ethernet@1009: link up, 1000Mbps full-duplex (lpa: 0x3800)
   BOOTP broadcast 1

Maybe this is caused by the changes in commit eeed242a.
I will try to revert u-boot in SPI back to 2023.07+dfsg-1 in the mean time.

Regards,
Michael


- -- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: arm64 (aarch64)

Kernel: Linux 5.10.110-rockchip-rk3588 (SMP w/8 CPU threads)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_DK.UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-

iQFPBAEBCgA5FiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmWhYbYbHGZsYWRpc2No
ZXJtaWNoYWVsQGZsYWRpLmF0AAoJEP/TyIuZfdFqFdUH/29hr2WiZHgh053eYiwq
VXjFuuBe64zeEo2FwuM8vJAvS4cW1F4usZ/D4FcG/C7nN6qaLrtFwHpk2ltOguv7
UBfKdGsGPukQYG973Qdp2OHP2NbEAnNNhivSgO2Hq6sycB3molfbr1XbywvDQEBR
sBamBTsca0kEfiH7ff890dgFrrGNuMvj/qJqAc7nC+MWeyJ0HNxI9kGQJY3CUDVR
SjghW6fMrogD4JAYMsrHXy3pZoGtBVuFlhPgUCI+sgtcbD51ROudrCBqvGM9W9DV
JDpAyMIjnhOyPQxhQqjnB9K1l4Az7uRIKydMm5T9W1bpzpNu4LY0hIvMRVpMXy41
52w=
=dgRu
-END PGP SIGNATURE-

Bug#1060662: rxvt-unicode

[jean pierre pinson]

le bug est corrigé dans la dernière version de
rxvt-unicode

Bug#1060672: kodi: High CPU usage even when idle

[Giuseppe Sacco]

Hello Vasyl,
I am trying kodi on a DELL PowerEdge T20, CPU E3-1225 v3 @3.20GHz, 32Gb of
RAM, Debian GNU/Linux 12 (bookworm).

Thank you,
Giuseppe

Bug#1060681: README.Debian outdated

[Ryan Kavanagh]

Package: cups-daemon
Version: 2.4.7-1+b1
Severity: minor

The file /usr/share/doc/cups-daemon/README.Debian.gz claims that cups
can be configured via its web interface and that further documentation
can be found through the web interface:

> Setting up a local print queue
> ==
> 
> The command line tools, lpadmin and lpinfo, can be used for this. Also,
> depending on what is installed on your system, a queue may be set up in an
> automated way. However, cups provides a web interface to accomplish the
> same task. It is accessed from a browser with
> 
>http://localhost:631
> 
> There is copious documentation under 'Online Help' and 'Printers' will
> display a list of local and remote print queues.

However, this interface is only accessible if the cups package (which
provides files /usr/lib/cups/cgi-bin/*) is installed. Please consider
updating README.Debian to specify that users need to install the cups
package to administer cups-daemon via the web interface.

Best wishes,
Ryan

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

Kernel: Linux 6.6.9-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.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 cups-daemon depends on:
ii  adduser3.137
ii  bc 1.07.1-3+b1
ii  init-system-helpers1.66
ii  libavahi-client3   0.8-13+b1
ii  libavahi-common3   0.8-13+b1
ii  libc6  2.37-13
ii  libcups2   2.4.7-1+b1
ii  libdbus-1-31.14.10-4
ii  libgssapi-krb5-2   1.20.1-5
ii  libpam0g   1.5.2-9.1+b1
ii  libpaper1  1.1.29
ii  libsystemd0255.2-4
ii  procps 2:4.0.4-2+b1
ii  ssl-cert   1.1.2
ii  sysvinit-utils [lsb-base]  3.08-5

Versions of packages cups-daemon recommends:
ii  avahi-daemon  0.8-13+b1
ii  colord1.4.6-5
ii  cups-browsed  1.28.17-3+b1
ii  ipp-usb   0.9.23-1+b7

Versions of packages cups-daemon suggests:
pn  cups   
pn  cups-bsd   
pn  cups-client
ii  cups-common2.4.7-1
pn  cups-filters   
pn  cups-pdf   
pn  cups-ppdc  
pn  cups-server-common 
pn  foomatic-db-compressed-ppds | foomatic-db  
ii  ghostscript10.02.1~dfsg-2
ii  poppler-utils  22.12.0-2+b1
pn  smbclient  
ii  udev   255.2-4

-- no debconf information

-- 
|)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#1060251: Bug#1059352: src:apt: fails to migrate to testing for too long: autopkgtest regression on armhf

[Emanuele Rocca]

Hi Julian!

On 2024-01-12 01:47, Julian Andres Klode wrote:
> Either way, these are harmless

I'm not saying they're harmful, what I'm saying is:

1) the errors you see on armhf when building apt without
   stack-clash-protection are the same valgrind reports on amd64 as
   well. Hence, you could consider rebuilding apt without
   stack-clash-protection on armhf and dropping the armhf conditional in
   test/integration/test-apt-update-simple

2) if you run valgrind in CI, I think you should probably use
   --error-exitcode. Otherwise, what's the point of using valgrind at
   all, if you don't fail when it reports errors? :-)
   This is not directly relevant to #1060251 of course, I'm happy to
   file a separate bug against apt if you find that useful.

Bug#1021370: pipewire: build with bluez5-codec-aac=enabled

[Max Nikulin]

On Fri, 07 Oct 2022 00:11:56 +0200 KeyofBlueS wrote:


please build pipewire with aac codec support enabled.


An alternative may be building a separate package for the contrib 
repository section that contains just the aac codec plugin.


I have no experience with meson, so I have no idea if it is possible to 
force it to ignore everything besides the specific plugin. As a proof of 
concept I have tried the following Makefile. Perhaps more flags should 
be added.


# - atomic_dep?
top_srcdir ?= .
top_builddir ?= $(top_srcdir)
builddir ?= $(top_srcdir)

spaversion = $(shell sed -n -e "s/^spaversion *= *'\(.*\)'$$/\1/p" 
$(top_srcdir)/meson.build)

pkgname = libspa-$(spaversion)
plugindir = $(shell pkg-config --variable=plugindir $(pkgname))
installdir = $(plugindir)/bluez5
# toplevel default_options
plugin_CFLAGS += --std=gnu11 -fPIE
# toplevel cc_flags
plugin_CFLAGS += -D_GNU_SOURCE -DFASTPATH
# toplevel common_flags
plugin_CFLAGS += -fvisibility=hidden -fno-strict-aliasing
# AVX and SSE flags perhaps may be ignored since
# computations should be done inside the linked library
# bluez5 codec_args
plugin_CFLAGS += -DCODEC_PLUGIN
# spa pkgconfig
plugin_CFLAGS += $(shell pkg-config --cflags $(pkgname))
# required for shared library
plugin_CFLAGS += -fPIC
plugin_CFLAGS += $(shell pkg-config --cflags fdk-aac)
ALL_CFLAGS = $(plugin_CFLAGS) $(CFLAGS)
ALL_LDLIBS = $(LDLIBS) $(shell pkg-config --libs fdk-aac)

bluez5_dir = $(top_srcdir)/spa/plugins/bluez5
aac_codec = $(builddir)/libspa-codec-bluez5-aac.so
plugin_LIBRARIES += $(aac_codec)
plugin_OBJECTS += $(builddir)/a2dp-codec-aac.o $(builddir)/media-codecs.o

all: $(plugin_LIBRARIES)
clean:
$(RM) $(plugin_LIBRARIES) $(plugin_OBJECTS)

# Not $(LD) due to $(LDFLAGS)
# ld: unrecognized option '-Wl,-z,relro'
$(aac_codec): $(plugin_OBJECTS)
$(CC) -o $@ -shared $(LDFLAGS) $^ $(ALL_LDLIBS)

$(builddir)/%.o: $(bluez5_dir)/%.c
$(CC) -o $@ $(CPPFLAGS) $(ALL_CFLAGS) -c $<

install: $(plugin_LIBRARIES)
install -D --target-directory $(DESTDIR)$(installdir) 
$(plugin_LIBRARIES)

.PHONY: all clean install

--- 8< --- debian/rules --- 8< ---
#!/usr/bin/make -f

export DEB_BUILD_MAINT_OPTIONS = hardening=+all
export DEB_LDFLAGS_MAINT_APPEND = -Wl,-z,defs

%:
dh $@

# Custom Makefile instead of configure script
override_dh_auto_configure:
override_dh_makeshlibs:

Bug#1060680: bluez: 5.71 breaks bluetooth audio

[Sebastian Reichel]

Package: bluez
Version: 5.71-1
Severity: important

Dear Maintainer,

Upgrading to bluez 5.71 breaks bluetooth audio. The following is logged
to the journal when trying to connect with a BT headset:

Jan 12 16:08:01 jupiter bluetoothd[44839]: 
profiles/audio/avdtp.c:avdtp_connect_cb() connect to 00:00:00:00:00:00: 
Permission denied (13)
Jan 12 16:07:58 jupiter bluetoothd[44839]: 
profiles/audio/avdtp.c:avdtp_connect_cb() connect to 00:00:00:00:00:00: 
Permission denied (13)
Jan 12 16:07:56 jupiter bluetoothd[44839]: src/profile.c:record_cb() Unable to 
get Hands-Free Voice gateway SDP record: Connection timed out

After downgrading to bluez 5.70-1.1 everything is working again. I use
use a Bose QC45 headset and pipewire + wireplumber instead of pulseaudio.

Greetings,

-- Sebastian

Bug#1056423: [Help] Started to replace future but failed

[Andreas Tille]

Am Fri, Jan 12, 2024 at 11:45:02AM +0100 schrieb Alexandre Detiste:
> 
> -class ExtensionNode(with_metaclass(ExtensionNodeMetaclass, object)):
> +class ExtensionNode(metaclass=ExtensionNodeMetaclass, object_=True):
> 
> Just simply
> +class ExtensionNode(metaclass=ExtensionNodeMetaclass):
> , but I can't test here:

This helped a bit further.  Unfortunately we have *lots* of instances of

   from past.utils import old_div

with several instances of old_div inside the code.  Do you know some automated
tool to fix this?  Replacing all these seems pretty error prone.

Kind regards
   Andreas.

-- 
http://fam-tille.de

Bug#1060456: rxvt-unicode: 9.31-1+b1 breaks UTF-8 display

[Sven Joachim]

Control: clone -1 -2
Control: reassign -2 libperl5.38
Control: found -2 5.38.2-2
Control: retitle -2 When embedding Perl in C, the locale is switched to C/ASCII
Control: forwarded -2 https://github.com/Perl/perl5/issues/21366

On 2024-01-11 23:06 +0100, gregor herrmann wrote:

> On Thu, 11 Jan 2024 20:52:16 +0100, Sven Joachim wrote:
>
>> > After upgrading rxvt-unicode today, it's no longer displaying UTF-8
>> > properly.  /var/log/apt/history.log shows:
>> >   Upgrade: rxvt-unicode:amd64 (9.31-1, 9.31-1+b1)
>
> Same here. Which made me quite nervous until I found this bug report
> :)
>
>> I have not tested it, but the attached patch should fix that.  See
>> http://lists.schmorp.de/pipermail/rxvt-unicode/2023q3/002665.html.
>
> I've rebuilt rxvt-unicode with this patch and I can confirm that it
> seems to work for all cases I've suffered from before.
>
> I think a quick upload would be good to spare all the people running
> unstable & updating perl to 5.38 in the next hours the troubles :)

Speaking of Perl 5.38, this bug is actually a problem in Perl.  The
rxvt-unicode patch just works around it.  According to the Perl upstream
bug (https://github.com/Perl/perl5/issues/21366), at least one other
application (irssi) is affected.

Fedora has apparently reverted a commit in Perl to fix the problem, see
https://src.fedoraproject.org/rpms/perl/c/dee564d443debbf47127d668f0982165835d873b.

Cheers,
   Sven

Bug#808940: ITP: opentofu -- tool for managing cloud infrastructure

[Christian Mesh]

Hi,

We have released the first stable version, 1.6.0.  Let me know if there's
anything I can do to help with packaging!

Christian

Bug#1060678: ITP: hm - reference software for HEVC

[Joachim Bauch]

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


* Package name: hm
  Version : 18.0
  Upstream Author : Joint Video Experts Team (JVET), ITU/ISO/IEC
* URL : https://vcgit.hhi.fraunhofer.de/jvet/HM
* License : BSD 3-Clause
  Programming Lang: C++
  Description : HM reference software for HEVC

This software package is the reference software for Rec. ITU-T H.265 |
ISO/IEC 23008-2 High Efficiency Video Coding (HEVC). The reference
software includes both encoder and decoder functionality.

Reference software is useful in aiding users of a video coding standard
to establish and test conformance and interoperability, and to educate
users and demonstrate the capabilities of the standard. For these
purposes, this software is provided as an aid for the study and
implementation of Rec. ITU-T H.265 | ISO/IEC 23008-2 High Efficiency
Video Coding.

The software has been jointly developed by the ITU-T Video Coding
Experts Group (VCEG, Question 6 of ITU-T Study Group 16) and the ISO/IEC
Moving Picture Experts Group (MPEG, Working Group 11 of Subcommittee 29
of ISO/IEC Joint Technical Committee 1).

The software is maintained by the Joint Video Experts Team (JVET) which
is a joint collaboration of ITU-T Video Coding Experts Group (VCEG,
Question 6 of ITU-T Study Group 16) and the ISO/IEC Moving Picture
Experts Group (MPEG, Working Group 5 of Subcommittee 29 of ISO/IEC Joint
Technical Committee 1).

If "hm" is too short as a package name, I could name it "hm-hevc" or
something similar.

"hm" is used for automated tests of "kvazaar" (see #1060341), so I
would like to be able to build-depend on the to-be-packaged "hm" from
"kvazaar" to run the tests also during packaging.

I'm planing to maintain the packaging from the Multimedia Team which
I'm already a member of. For the first release I will need a sponsor,
but I'm planning to apply to become a DD in the near future, so
hopefully at that point I can maintain it without external help.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060439: ITP: network-event-broker -- run scripts on systemd network events

[Susant Sahani]

On Thu, 11 Jan 2024 13:55:47 +0100 Tobias Schaffner 
 wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Tobias Schaffner 
>
> * Package name : network-event-broker
> Version : 0.3.1+ds-1
> Upstream Author : Susant Sahani 
> * URL : https://github.com/vmware/network-event-broker
> * License : Apache 2.0
> Programming Lang: Go
> Description : run scripts on systemd network events
>
> The network-event-broker is a daemon that configures network interfaces
> and executes scripts based on network events such as address changes and
> link additions/removals. It also enables the configuration of multiple
> interfaces in the same network by automatically adding a secondary routing
> table and routing policies.
>
> Reasoning: I already created the debian packaging and I am willing to maintain
> this.
>
>

Bug#1060439: ITP: network-event-broker -- run scripts on systemd network events

[Susant Sahani]

On Thu, 11 Jan 2024 14:28:21 +0100 Michael Biebl  wrote:
> Hi
>
> Am 11.01.24 um 13:55 schrieb Tobias Schaffner:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Tobias Schaffner 
> >
> > * Package name : network-event-broker
> > Version : 0.3.1+ds-1
> > Upstream Author : Susant Sahani 
> > * URL : https://github.com/vmware/network-event-broker
> > * License : Apache 2.0
> > Programming Lang: Go
> > Description : run scripts on systemd network events
> >
> > The network-event-broker is a daemon that configures network interfaces
> > and executes scripts based on network events such as address changes and
> > link additions/removals. It also enables the configuration of multiple
> > interfaces in the same network by automatically adding a secondary routing
> > table and routing policies.
> >
> > Reasoning: I already created the debian packaging and I am willing to 
> > maintain
> > this.
>
> That seems very similar to
> https://tracker.debian.org/pkg/networkd-dispatcher
>
> Could you go into more detail, where they differ and why we would want a
> second dispatcher service for networkd connection changes.
>
> Regards,
> Michael
>
Apart from watching networkd's event it network-event-broker does the following


  1.  dhclient gains lease and execute scripts upon
  - An address getting added/removed/modified.
  - links added/removed.

  2.   Allows to execute scripts when routes gets modified)
 That means it's it listens to kernel netlink events when routes are added and 
removed that
allows to execute scripts.  That means it's use space client agnostic .

3. Exports network data in JSON format



Susant

  1.

Bug#1060674: mjpegtools-gtk: broken dependencies

[fabian]

Hi,

the mjpegtools-gtk package has been removed from Debian to get rid of 
the libgtk2 dependency.


- Fabian

Am 12.01.2024 15:52, schrieb Vladmimir Stavrinov:

Package: mjpegtools-gtk
...
Debian Release: trixie/sid

Bug#1060677: Acknowledgement (Rounding error in OFStandard::atof)

[Mathieu Malaterre]

forwarded -1 https://support.dcmtk.org/redmine/issues/1100

Bug#1060432: [Python-modules-team] Bug#1060432: rpds-py ftbfs in unstable

[Roland Mas]

Le 11/01/2024 à 10:27, Matthias Klose a écrit :

Package: src:rpds-py
Version: 0.12.0-2
Severity: serious
Tags: sid trixie ftbfs

rpds-py ftbfs in unstable, because of missing build dependencies:

Issues preventing migration:
∙ ∙ rpds-py unsatisfiable Build-Depends(-Arch) on amd64: 
librust-archery-dev

∙ ∙ rpds-py unsatisfiable Build-Depends(-Arch) on amd64: librust-rpds-dev


I just uploaded these two packages to NEW, along with a third one on the 
dependency chain.


Roland.

Bug#1060677: Rounding error in OFStandard::atof

[Mathieu Malaterre]

Source: dcmtk
Version: 3.6.7-8+b1

I believe I found an edge case in OFStandard::atof logic. Consider the
following ASCII string float > 16 bytes (valid case for input such as
XML or JSON).

Here is what I see on my side Debian/stable (dcmtk 3.6.7):

$ ./fd
0x1.dp+3
0x1.cp+3

This has an impact when using DcmFloatingPointDouble::putString (VR:FD).

Thanks !

ref code is

% cat ../fd.cxx
#include "dcmtk/dcmdata/dcfilefo.h"

int main() {
  const uint8_t bytes[] = {0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0x2C, 0x40};
  std::string result;
  result = "14.399";
  OFBool success;
  double d2 = OFStandard::atof(result.c_str(), &success);
  std::cout << std::hexfloat << d2 << std::endl;
  double d3 = std::stod(result);
  std::cout << std::hexfloat << d3 << std::endl;

  return 0;
}

Bug#1060676: new upstream?

[Harald Dunkel]

Package: python3-gitlab
Version: 1:3.12.0-1

Hi Federico,

Upstream provides version 4.3.0. Would it be possible to include
this version into Sid?


Thank you very much in advance

Harri

Bug#1060675: python3-pyside2.qtgui: Fails to install with libqt5gui5-gles

[Fuzzey, Martin]

Package: python3-pyside2.qtgui
Version: 5.15.8-2+b1
Severity: normal
X-Debbugs-Cc: martin.fuzzey@flowbird.group

Dear Maintainer,

When libqt5gui5-gles is installed (required on arm64 platforms without
desktop OpenGL)
package installation fails with

python3-pyside2.qtgui : Depends: libqt5gui5 (>= 5.15) but it is
not installable

The problem is that python3-pyside2.qt has in its dependencies
libqt5gui5 (>= 5.15), libqt5gui5 (>= 5.15.1) | libqt5gui5-gles (>= 5.15.1)

IE an unconditional dependency on libqt5gui5 and an alternative on
libqt5gui5 or libqt5gui5-gles

I tried (as a hack) to modify the binary package(by unpacking and
repacking it) to
remove the unconditional dependency on libqt5gui5. That makes it installable
but it is still trying to use desktop opengl symbols:

>>> from PySide2 import QtGui
Traceback (most recent call last):
  File "", line 1, in 
ImportError: 
/usr/lib/python3/dist-packages/PySide2/QtGui.cpython-311-aarch64-linux-gnu.so:
undefined symbol: _ZTI18QOpenGLTimeMonitor, version Qt_5


I've looked at the package source and it seems it is supposed to handle this
by the patch debian/patches/Fix-GLES-builds.patch.
But that removes expected symbols based on QT.gui.enabled_features

The features are supplied by the qtbase5-dev package which is
different on armhf and arm64
On armhf opengles2 is enabled whereas on arm64 it is disabled.

Since python3-pyside2.qtgui Build-Depends on qtbase5-dev the patch
doesn't really
work in the Debian context on arm64 - the package will build but the
dependencies
calculated by shlibdeps will be wrong for gles.

I tried to fix the problem by rebuilding changing the Build-Depends on
qtbase5-dev
and qtbase5-private-dev to qtbase5-gles-dev and qtbase5-private-gles-dev.
But that results in a build dep conflict because some of the other dependencies
(like  libqt5charts5-dev) depend on qtbase5-dev (which conflicts with
qtbase5-gles-dev)

  package: sbuild-build-depends-main-dummy
  version: 0.invalid.0
  architecture: amd64
  status: broken
  reasons:
   -
conflict:
 pkg1:
  package: qtbase5-dev
  version: 5.15.8+dfsg-11
  architecture: amd64
  unsat-conflict: qtbase5-gles-dev:amd64
 pkg2:
  package: qtbase5-gles-dev
  version: 5.15.8+dfsg-3
  architecture: amd64
 depchain1:
  -
   depchain:
-
 package: sbuild-build-depends-main-dummy
 version: 0.invalid.0
 architecture: amd64
 depends: libqt5charts5-dev:amd64 (>= 5.15)
-
 package: libqt5charts5-dev
 version: 5.15.8-2
 architecture: amd64
 depends: qtbase5-dev:amd64
 depchain2:
  -
   depchain:
-
 package: sbuild-build-depends-main-dummy
 version: 0.invalid.0
 architecture: amd64
 depends: qtbase5-gles-dev:amd64 (>= 5.15)


Regards,

Martin


-- System Information:
Debian Release: 12.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 6.6.6-pknbsp-svn7643-std-00019-g34ac856c6990 (SMP w/4
CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-pyside2.qtgui depends on:
ii  libc6   2.36-9+deb12u3
ii  libgcc-s1   12.2.0-14
ii  libpyside2-py3-5.15 5.15.8-2+b1
ii  libqt5core5a5.15.8+dfsg-11
ii  libqt5gui5-gles 5.15.8+dfsg-3
ii  libshiboken2-py3-5.15   5.15.8-2+b1
ii  libstdc++6  12.2.0-14
ii  python3 3.11.2-1+b1
ii  python3-pyside2.qtcore  5.15.8-2+b1

python3-pyside2.qtgui recommends no packages.

python3-pyside2.qtgui suggests no packages.

-- no debconf information

Bug#1060674: mjpegtools-gtk: broken dependencies

[Vladmimir Stavrinov]

Package: mjpegtools-gtk
Severity: normal

The following packages have unmet dependencies:
 mjpegtools-gtk : Depends: mjpegtools (= 1:2.1.0+debian-7) but 1:2.1.0+debian-8 
is to be installed

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

Kernel: Linux 6.6.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=ru_RU.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 mjpegtools-gtk depends on:
ii  libc62.37-13
ii  libglib2.0-0 2.78.3-1
ii  libgtk2.0-0  2.24.33-2
ii  libmjpegutils-2.1-0  1:2.1.0+debian-8
ii  mjpegtools   1:2.1.0+debian-8

mjpegtools-gtk recommends no packages.

mjpegtools-gtk suggests no packages.

Bug#1060673: nvidia-persistenced: Flushing system-wide workqueues will be prohibited in near future

[Vincent Lefevre]

Package: nvidia-persistenced
Version: 525.85.05-1+b1
Severity: important

With the 6.6.9-amd64 kernel (not before), I get:

Jan 12 15:25:54 cventin kernel: WARNING: Flushing system-wide workqueues will 
be prohibited in near future.
Jan 12 15:25:54 cventin kernel: CPU: 8 PID: 794 Comm: nvidia-persiste Tainted: 
P   OE  6.6.9-amd64 #1  Debian 6.6.9-1
Jan 12 15:25:54 cventin kernel: Hardware name: Dell Inc. Precision Tower 
7810/0GWHMW, BIOS A07 04/14/2015
Jan 12 15:25:54 cventin kernel: Call Trace:
Jan 12 15:25:54 cventin kernel:  
Jan 12 15:25:54 cventin kernel:  dump_stack_lvl+0x47/0x60
Jan 12 15:25:54 cventin kernel:  os_flush_work_queue+0x55/0x70 [nvidia]
Jan 12 15:25:54 cventin kernel:  rm_disable_adapter+0x52/0xd0 [nvidia]
Jan 12 15:25:54 cventin kernel:  ? down_trylock+0x11/0x40
Jan 12 15:25:54 cventin kernel:  nv_shutdown_adapter+0x17/0xa0 [nvidia]
Jan 12 15:25:54 cventin kernel:  nv_close_device+0xea/0x170 [nvidia]
Jan 12 15:25:54 cventin kernel:  nvidia_close+0xcf/0x3a0 [nvidia]
Jan 12 15:25:54 cventin kernel:  nvidia_frontend_close+0x2e/0x50 [nvidia]
Jan 12 15:25:54 cventin kernel:  __fput+0xf5/0x290
Jan 12 15:25:54 cventin kernel:  __x64_sys_close+0x3d/0x80
Jan 12 15:25:54 cventin kernel:  do_syscall_64+0x60/0xc0
Jan 12 15:25:54 cventin kernel:  ? syscall_exit_to_user_mode+0x2b/0x40
Jan 12 15:25:54 cventin kernel:  ? do_syscall_64+0x6c/0xc0
Jan 12 15:25:54 cventin kernel:  ? exit_to_user_mode_prepare+0x40/0x1e0
Jan 12 15:25:54 cventin kernel:  ? syscall_exit_to_user_mode+0x2b/0x40
Jan 12 15:25:54 cventin kernel:  ? do_syscall_64+0x6c/0xc0
Jan 12 15:25:54 cventin kernel:  ? syscall_exit_to_user_mode+0x2b/0x40
Jan 12 15:25:54 cventin kernel:  ? do_syscall_64+0x6c/0xc0
Jan 12 15:25:54 cventin kernel:  ? exit_to_user_mode_prepare+0x40/0x1e0
Jan 12 15:25:54 cventin kernel:  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
Jan 12 15:25:54 cventin kernel: RIP: 0033:0x7f631be6f1a0
Jan 12 15:25:54 cventin kernel: Code: 0d 00 00 00 eb b2 e8 5f 01 02 00 66 2e 0f 
1f 84 00 00 00 00 00 0f 1f 44 00 00 80 3d 41 34 0e 00 00 74 17 b8 03 00 00 00 
0f 05 <48> 3d 00 f0 ff ff 77 48 c3 0f 1f 80 00 00 00 00 48 83 ec 18 89 7c
Jan 12 15:25:54 cventin kernel: RSP: 002b:7ffe78073cf8 EFLAGS: 0202 
ORIG_RAX: 0003
Jan 12 15:25:54 cventin kernel: RAX: ffda RBX:  
RCX: 7f631be6f1a0
Jan 12 15:25:54 cventin kernel: RDX:  RSI: 0003 
RDI: 0003
Jan 12 15:25:54 cventin kernel: RBP: 0003 R08: 7ffe78073e90 
R09: 7ffe78073eac
Jan 12 15:25:54 cventin kernel: R10: 8aa9e9ddd50363d7 R11: 0202 
R12: 
Jan 12 15:25:54 cventin kernel: R13: 7f631ba2ef80 R14: 7f631ba2ef60 
R15: c1d00011
Jan 12 15:25:54 cventin kernel:  

https://lore.kernel.org/lkml/42f1067f-3232-0a64-4c19-6165dabf4...@i-love.sakura.ne.jp/T/
(where this warning has been introduced) says "Therefore, start
emitting runtime message so that all out-of-tree users will
understand that they need to update their code."

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

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

Versions of packages nvidia-persistenced depends on:
ii  adduser   3.137
ii  init-system-helpers   1.66
ii  libc6 2.37-13
ii  libnvidia-legacy-390xx-cfg1 [libnvidia-cfg1-any]  390.157-6
ii  libtirpc3 1.3.4+ds-1

nvidia-persistenced recommends no packages.

nvidia-persistenced suggests no packages.

-- no debconf information

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

Bug#1060266: [Pkg-auth-maintainers] Some help for coordinated uploads needed

[Philip Rinn]

Hi Florian,

On 12.01.24 at 12:08, Florian Schlichting:

I would like to do an upload of yubikey-manager very soon in order to
fix #1060266 (serious) in python3-ykman. Can we perhaps do an upload of
python-fido2 to unstable in the course of this weekend? Do you want to
do that yourself, so you can update solo1-cli at the same time, or are
you ok with me going ahead and you follow with solo1-cli whenever
convenient?


sure, please go ahead. Just ping me, once you uploaded phython-fido2 to unstable 
so I can upload solo1-cli afterwards.


Thanks for all the preparation!
Philip


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060672: kodi: High CPU usage even when idle

[Vasyl Gello]

Hi Giuseppe,

Thanks for report! The reportbug contents was probably truncated, as I see
no information about hardware, architecture etc.

What is your device specs?

-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#1058995: version 0.9.0

[Alexandre Detiste]

Please package version 0.9.0 that fix the RC bug
& help forward python3-future removal.

Greetings

Bug#1058997: flask-autoindex is incompatible with Py3.12

[Alexandre Detiste]

control: -1 tag +patch

Please apply this patch and remove "python3-future ," from
debian/control.

Greetings


remove-future
Description: Binary data

Bug#1060664: gpg: Option --keyserver-options=auto-key-retrieve does not work

[Vincent Lefevre]

Control: retitle -1 gpg auto-key-retrieve does not work

I've tried --auto-key-retrieve on a different machine, and this
doesn't have any effect either:

cventin:~> gpg --verbose --keyserver pgpkeys.eu --auto-key-retrieve --verify 
/home/vlefevre/.cpan/sources/authors/id/C/CA/CAVAC/CHECKSUMS
gpg: armor header: Hash: SHA1
gpg: armor header: Version: GnuPG v2.0.14 (GNU/Linux)
gpg: original file name=''
gpg: Signature made 2023-12-17T16:29:09 CET
gpg:using RSA key 77576125A905F1BA
gpg: Can't check signature: No public key

Putting the option in .gnupg/gpg.conf doesn't have any effect either.

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

Bug#1060672: kodi: High CPU usage even when idle

[Giuseppe Sacco]

Package: kodi
Version: 2:20.1+dfsg-1
Severity: normal

Dear Maintainer,
I intalled kodi a few days back in order to access all my media from a TV.
I executed and configured it using its GUI. Then I stopped it and run the
standalone version from a systemd unit in order to have it running all time.
I noticed that while nobody is using kodi from my TV, i.e., during nights, the
CPU usage is constantly about 8-12% for kodi.bin process.

Why? Is there anything that can be changed on the configuration in order
to stop this high CPU usage?

Just for reference, the CPU is Intel(R) Xeon(R) E3-1225 v3 @3.20GHz.

Thank you,
Giuseppe

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

Kernel: Linux 6.1.0-17-amd64 (SMP w/4 CPU threads; PREEMPT)
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 kodi depends on:
ii  kodi-bin   2:20.1+dfsg-1
ii  kodi-data  2:20.1+dfsg-1

Versions of packages kodi recommends:
ii  kodi-repository-kodi [kodi-repository]  2:20.1+dfsg-1
ii  kodi-visualization-spectrum 20.2.0+ds1-1

kodi suggests no packages.

-- no debconf information

Bug#1060671: libdbd-oracle-perl: requires rebuild for perl 5.38

[Sebastian Ramacher]

Source: libdbd-oracle-perl
Version: 1.83-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

The perl 5.38 has started. Since libdbd-oracle-perl is in contrib and
not auto-buildable, it requires a manual rebuild on amd64 and i386.

Cheers
-- 
Sebastian Ramacher

Bug#1060670: [INTL:sv] Swedish strings for wireshark debconf

[Martin Bagge / brother]

package: wireshark
severity: wishlist
tags: patch l10n

Please consider to add this file to translation of debconf.
--
brother# Translation of wireshark debconf template to Swedish
# Copyright (C) 2024 Martin Bagge 
# This file is distributed under the same license as the wireshark package.
#
# Martin Ågren , 2009, 2010.
# Martin Bagge , 2024
msgid ""
msgstr ""
"Project-Id-Version: wireshark_sv\n"
"Report-Msgid-Bugs-To: wiresh...@packages.debian.org\n"
"POT-Creation-Date: 2019-09-13 00:04+0200\n"
"PO-Revision-Date: 2024-01-12 13:57+0100\n"
"Last-Translator: Martin Bagge \n"
"Language-Team: Swedish \n"
"Language: sv\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: KBabel 1.11.4\n"
"Plural-Forms:  nplurals=2; plural=(n != 1);\n"

#. Type: boolean
#. Description
#: ../templates:2001
msgid "Should non-superusers be able to capture packets?"
msgstr "Ska icke-superanvändare kunna fånga paket?"

#. Type: boolean
#. Description
#: ../templates:2001
msgid ""
"Dumpcap can be installed in a way that allows members of the \"wireshark\" "
"system group to capture packets. This is recommended over the alternative of "
"running Wireshark/Tshark directly as root, because less of the code will run "
"with elevated privileges."
msgstr ""
"Dumpcap kan installeras på ett sätt som tillåter medlemmar i systemgruppen "
"\"wireshark\" att fånga paket. Detta rekommenderas framför alternativet, att "
"köra Wireshark/Tshark direkt som root, eftersom en mindre del av koden "
"kommer köras med utökade rättigheter."

#. Type: boolean
#. Description
#: ../templates:2001
msgid ""
"For more detailed information please see /usr/share/doc/wireshark-common/"
"README.Debian.gz once the package is installed."
msgstr ""
"Se /usr/share/doc/wireshark-common/README.Debian.gz för mer detaljerad "
"information."

#. Type: boolean
#. Description
#: ../templates:2001
msgid ""
"Enabling this feature may be a security risk, so it is disabled by default. "
"If in doubt, it is suggested to leave it disabled."
msgstr ""
"Att aktivera denna funktion kan vara en säkerhetsrisk, så den är avaktiverad "
"som standard. Vid tvivel rekommenderas att den lämnas avaktiverad."

#. Type: error
#. Description
#: ../templates:3001
msgid "Creating the wireshark system group failed"
msgstr "Kunde inte skapa systemgruppen wireshark"

#. Type: error
#. Description
#: ../templates:3001
msgid ""
"The wireshark group does not exist, and creating it failed, so Wireshark "
"cannot be configured to capture traffic as an unprivileged user."
msgstr ""
"Gruppen wireshark finns inte och det gick inte att skapa den. Detta leder "
"till att Wireshark inte kan ställas in för att fånga trafik för vanliga "
"användare."

#. Type: error
#. Description
#: ../templates:3001
msgid ""
"Please create the wireshark system group and try configuring wireshark-"
"common again."
msgstr ""
"Skapa systemgruppen wireshark och försök göra inställningar för wireshark-"
"common igen."

#. Type: error
#. Description
#: ../templates:4001
msgid "The wireshark group is a system group"
msgstr "Gruppen wireshark är en systemgrupp"

#. Type: error
#. Description
#: ../templates:4001
msgid ""
"The wireshark group exists as a user group, but the preferred configuration "
"is for it to be created as a system group."
msgstr ""
"Gruppen wireshark finns redan men är en användargrupp. Att ha gruppen som en "
"systemgrupp är att föredra."

#. Type: error
#. Description
#: ../templates:4001
msgid ""
"As a result, purging wireshark-common will not remove the wireshark group, "
"but everything else should work properly."
msgstr ""
"Om wireshark-common raderas helt och hållet så kommer gruppen wireshark inte "
"tas bort, allt annat fungerar dock som vanligt."

#. Type: error
#. Description
#: ../templates:5001
msgid "Setting capabilities for dumpcap failed"
msgstr "Kunde inte aktivera rätt inställningar för dumpcap"

#. Type: error
#. Description
#: ../templates:5001
msgid ""
"The attempt to use Linux capabilities to grant packet-capturing privileges "
"to the dumpcap binary failed. Instead, it has had the set-user-id bit set."
msgstr ""
"Försökte aktivera Linux capabilities för att låta dumpcap-binären läsa "
"datapaket misslyckades. Istället har biten set-user-id aktiverats."

#. Type: error
#. Description
#: ../templates:6001
msgid "Removal of the wireshark group failed"
msgstr "Kunde inte radera wireshark-gruppen"

#. Type: error
#. Description
#: ../templates:6001
msgid ""
"When the wireshark-common package is configured to allow non-superusers to "
"capture packets the postinst script of wireshark-common creates the "
"wireshark group as a system group."
msgstr ""
"När paketet wireshark-common ställs in för att låta vanliga användare fånga "
"paket så kommer postinst-skriptet att skapa gruppen wireshark som en "
"systemgrupp."

#. Type: error
#. Description
#: ../templates:6001
msgid ""
"However, on this system the wireshark group is a user group i