Bug#1055320: rust-snow, upcoming ring update.

[Peter Green]

Package: rust-snow

As you are probablly aware, i'm currently working on an update of
rust-ring. rust-snow depends on ring, it seems to build and run
tests fine after bumping the dependency.

Upstream, dependabot has submitted a PR to update ring, but
upstream has not responded to it yet. I've left a comment
there to see if they can shed any light.

Anyway, a debdiff is attached.diff -Nru rust-snow-0.9.3/debian/changelog rust-snow-0.9.3/debian/changelog
--- rust-snow-0.9.3/debian/changelog2023-10-16 18:17:30.0 +
+++ rust-snow-0.9.3/debian/changelog2023-11-04 03:51:25.0 +
@@ -1,3 +1,10 @@
+rust-snow (0.9.3-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Bump ring dependency to 0.17.
+
+ -- Peter Michael Green   Sat, 04 Nov 2023 03:51:25 +
+
 rust-snow (0.9.3-2) unstable; urgency=medium
 
   * extend patch 2001 to omit feature vector-tests,
diff -Nru rust-snow-0.9.3/debian/control rust-snow-0.9.3/debian/control
--- rust-snow-0.9.3/debian/control  2023-09-10 17:01:45.0 +
+++ rust-snow-0.9.3/debian/control  2023-11-04 03:51:25.0 +
@@ -11,8 +11,8 @@
  librust-rand-core-0.6+default-dev ,
  librust-rand-core-0.6+getrandom-dev ,
  librust-rand-core-0.6+std-dev ,
- librust-ring-0.16+default-dev ,
- librust-ring-0.16+std-dev ,
+ librust-ring-0.17+default-dev ,
+ librust-ring-0.17+std-dev ,
  librust-rustc-version-0.4-dev ,
  librust-serde-1+default-dev ,
  librust-serde-derive-1+default-dev ,
@@ -33,8 +33,8 @@
  librust-rand-core-0.6+default-dev,
  librust-rand-core-0.6+getrandom-dev,
  librust-rand-core-0.6+std-dev,
- librust-ring-0.16+default-dev,
- librust-ring-0.16+std-dev,
+ librust-ring-0.17+default-dev,
+ librust-ring-0.17+std-dev,
  librust-subtle-2+default-dev,
  ${misc:Depends},
 Provides:
diff -Nru rust-snow-0.9.3/debian/patches/1001_ring.patch 
rust-snow-0.9.3/debian/patches/1001_ring.patch
--- rust-snow-0.9.3/debian/patches/1001_ring.patch  1970-01-01 
00:00:00.0 +
+++ rust-snow-0.9.3/debian/patches/1001_ring.patch  2023-11-04 
03:50:31.0 +
@@ -0,0 +1,13 @@
+Index: rust-snow-0.9.3/Cargo.toml
+===
+--- rust-snow-0.9.3.orig/Cargo.toml
 rust-snow-0.9.3/Cargo.toml
+@@ -51,7 +51,7 @@ pqcrypto-kyber = { version = "0.7", opti
+ pqcrypto-traits = { version = "0.3", optional = true }
+ 
+ # ring crypto provider
+-ring = { version = "^0.16.2", optional = true, features = ["std"] }
++ring = { version = "^0.17", optional = true, features = ["std"] }
+ # libsodium crypto provider
+ sodiumoxide = { version = "0.2", optional = true }
+ byteorder = { version = "1.4", optional = true }
diff -Nru rust-snow-0.9.3/debian/patches/2001_features.patch 
rust-snow-0.9.3/debian/patches/2001_features.patch
--- rust-snow-0.9.3/debian/patches/2001_features.patch  2023-09-10 
16:59:13.0 +
+++ rust-snow-0.9.3/debian/patches/2001_features.patch  2023-11-04 
03:51:16.0 +
@@ -39,7 +39,7 @@
 -pqcrypto-traits = { version = "0.3", optional = true }
 -
  # ring crypto provider
- ring = { version = "^0.16.2", optional = true, features = ["std"] }
+ ring = { version = "^0.17", optional = true, features = ["std"] }
 -# libsodium crypto provider
 -sodiumoxide = { version = "0.2", optional = true }
 -byteorder = { version = "1.4", optional = true }
diff -Nru rust-snow-0.9.3/debian/patches/series 
rust-snow-0.9.3/debian/patches/series
--- rust-snow-0.9.3/debian/patches/series   2023-08-24 09:19:45.0 
+
+++ rust-snow-0.9.3/debian/patches/series   2023-11-04 03:49:30.0 
+
@@ -1,3 +1,4 @@
+1001_ring.patch
 2001_features.patch
 2002_x25519-dalek.patch
 2003_no_bench.patch
diff -Nru rust-snow-0.9.3/debian/source/include-binaries 
rust-snow-0.9.3/debian/source/include-binaries
--- rust-snow-0.9.3/debian/source/include-binaries  1970-01-01 
00:00:00.0 +
+++ rust-snow-0.9.3/debian/source/include-binaries  2023-11-04 
03:48:32.0 +
@@ -0,0 +1,631 @@
+target/debug/.fingerprint/atty-1c8233b00b5d42d5/dep-lib-atty
+target/debug/.fingerprint/autocfg-ebc62869343c4f5c/dep-lib-autocfg
+target/debug/.fingerprint/bitflags-7c49c9267eabca2a/dep-lib-bitflags
+target/debug/.fingerprint/cc-0bea097c188cf75f/dep-lib-cc
+target/debug/.fingerprint/cfg-if-0deb1cbf488332ce/dep-lib-cfg-if
+target/debug/.fingerprint/clap-ec35a29a6847014b/dep-lib-clap
+target/debug/.fingerprint/clap_lex-4acb92bec96d72aa/dep-lib-clap_lex
+target/debug/.fingerprint/getrandom-61d5dab8b4c2d45d/dep-lib-getrandom
+target/debug/.fingerprint/hashbrown-19ec0a3c02dca951/dep-lib-hashbrown
+target/debug/.fingerprint/hex-491dc1f1836d305b/dep-lib-hex
+target/debug/.fingerprint/indexmap-078c8d4830b8147a/dep-build-script-build-script-build
+target/debug/.fingerprint/indexmap-956fce6b53aefb0f/dep-lib-indexmap
+target/debug/.fingerprint/itoa-33ec9bdf767cbbb3/dep-lib-itoa

Bug#1027124: should support TLS?

[David Leadbeater]

It is somewhat confusing that the package calls itself netcat-openbsd
but deviates from the options that OpenBSD supports.

For people coming across this wondering where to find a version of
netcat that supports TLS, note that to add to the confusion other
distros have picked up Debian's version and call it "netcat-openbsd"
with the Debian patches.

LibreSSL portable (https://github.com/libressl/portable) actually
includes a version of nc (if enabled via ENABLE_NC) that is closer to
the true OpenBSD netcat. Instead some distros package nc as part of
LibreSSL, for example
https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/libressl/default.nix
contains a version on NixOS that includes the TLS supporting nc (NixOS
also offers a netcat-openbsd, which is based on the Debian patches.)

(There is also https://github.com/reyk/libressl-deb for Debian, but
unfortunately that doesn't seem to be kept up-to-date.)

Maybe it would make sense to keep this netcat-openbsd package for
compatibility but encourage people to switch to a netcat version built
as part of the libretls package build (by turning on ENABLE_NC there
and split out the nc binary into a binary package.like
netcat-libretls).

Bug#1055319: rust-rustls-webpki autopkgtest failure.

[Peter Green]

Package: rust-rustls-webpki
Version: 0.101.6-1
Severity: serious

The autopkgtest for rust-rustls-webpki fails with


238s error[E0583]: file not found for module `test_utils`
238s   --> src/lib.rs:65:1
238s|
238s 65 | pub(crate) mod test_utils;
238s| ^^
238s|
238s= help: to create the module `test_utils`, create file "src/test_utils.rs" or 
"src/test_utils/mod.rs"


This bug affects both the versions in unstable and experimental. It
does not affect the version currently in testing.

It appears that the file src/test_utils.rs is included in the source package
but is not making it into the binary package for some reason.

Bug#1055318: rust-rustls-native-certs - dev-dependency update for new untrusted/ring

[Peter Green]

Package: rust-rustls-native-certs
Version: 0.6.3-3

As you are probablly aware, I'm preparing an update of the untrusted and ring 
crates
(currently in experimental). The rustls-native-certs crate doesn't use 
untrusted or
ring at runtime, but it does have dev-dependencies on them.

After bumping the dev-dependencies the package builds and runs autopkgtests 
fine.diff -Nru rust-rustls-native-certs-0.6.3/debian/changelog 
rust-rustls-native-certs-0.6.3/debian/changelog
--- rust-rustls-native-certs-0.6.3/debian/changelog 2023-08-19 
22:13:08.0 +
+++ rust-rustls-native-certs-0.6.3/debian/changelog 2023-11-04 
02:42:29.0 +
@@ -1,3 +1,11 @@
+rust-rustls-native-certs (0.6.3-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Bump dev-dependencies on untrusted and ring to 0.9 and 0.17
+and update build-dependencies and test dependencies accordingly.
+
+ -- Peter Michael Green   Sat, 04 Nov 2023 02:42:29 +
+
 rust-rustls-native-certs (0.6.3-3) unstable; urgency=medium
 
   * renumber patch 2006 -> 1001;
diff -Nru rust-rustls-native-certs-0.6.3/debian/control 
rust-rustls-native-certs-0.6.3/debian/control
--- rust-rustls-native-certs-0.6.3/debian/control   2023-08-07 
00:24:56.0 +
+++ rust-rustls-native-certs-0.6.3/debian/control   2023-11-04 
02:42:29.0 +
@@ -5,12 +5,12 @@
  debhelper-compat (= 13),
  dh-cargo (>= 25),
  librust-openssl-probe-0.1+default-dev (>= 0.1.2) ,
- librust-ring-0.16+default-dev (>= 0.16.5) ,
+ librust-ring-0.17+default-dev ,
  librust-rustls-0.21+default-dev ,
  librust-rustls-pemfile-1+default-dev ,
  librust-rustls-webpki-0.101+default-dev ,
  librust-serial-test-2+default-dev ,
- librust-untrusted-0.7+default-dev ,
+ librust-untrusted-0.9+default-dev ,
  libstring-shellquote-perl,
 Maintainer: Jonas Smedegaard 
 Standards-Version: 4.6.2
diff -Nru 
rust-rustls-native-certs-0.6.3/debian/patches/1002_untrusted_ring.patch 
rust-rustls-native-certs-0.6.3/debian/patches/1002_untrusted_ring.patch
--- rust-rustls-native-certs-0.6.3/debian/patches/1002_untrusted_ring.patch 
1970-01-01 00:00:00.0 +
+++ rust-rustls-native-certs-0.6.3/debian/patches/1002_untrusted_ring.patch 
2023-11-04 02:37:54.0 +
@@ -0,0 +1,17 @@
+Description: Bump ring and rustls dev-dependencies to 0.17 and 0.9
+Author: Peter Michael Green 
+Last-Update: 2023-11-04
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- rust-rustls-native-certs-0.6.3.orig/Cargo.toml
 rust-rustls-native-certs-0.6.3/Cargo.toml
+@@ -16,3 +16,3 @@
+ [dev-dependencies]
+-ring = "0.16.5"
++ring = "0.17"
+ rustls = "0.21.0"
+@@ -20,3 +20,3 @@
+ serial_test = "2"
+-untrusted = "0.7.0" # stick to the version ring depends on for now
++untrusted = "0.9.0" # stick to the version ring depends on for now
+ webpki-roots = "0.23"
diff -Nru rust-rustls-native-certs-0.6.3/debian/patches/2004_x509-parser.patch 
rust-rustls-native-certs-0.6.3/debian/patches/2004_x509-parser.patch
--- rust-rustls-native-certs-0.6.3/debian/patches/2004_x509-parser.patch
2023-08-14 10:13:20.0 +
+++ rust-rustls-native-certs-0.6.3/debian/patches/2004_x509-parser.patch
2023-11-04 02:38:56.0 +
@@ -8,7 +8,7 @@
 +++ b/Cargo.toml
 @@ -20,7 +20,6 @@
  serial_test = "2"
- untrusted = "0.7.0" # stick to the version ring depends on for now
+ untrusted = "0.9.0" # stick to the version ring depends on for now
  webpki-roots = "0.23"
 -x509-parser = "0.15"
  
diff -Nru rust-rustls-native-certs-0.6.3/debian/patches/2005_webpki-roots.patch 
rust-rustls-native-certs-0.6.3/debian/patches/2005_webpki-roots.patch
--- rust-rustls-native-certs-0.6.3/debian/patches/2005_webpki-roots.patch   
2023-08-19 22:13:08.0 +
+++ rust-rustls-native-certs-0.6.3/debian/patches/2005_webpki-roots.patch   
2023-11-04 02:39:56.0 +
@@ -9,7 +9,7 @@
 @@ -19,7 +19,6 @@
  rustls-webpki = ">= 0.100, < 0.102"
  serial_test = "2"
- untrusted = "0.7.0" # stick to the version ring depends on for now
+ untrusted = "0.9.0" # stick to the version ring depends on for now
 -webpki-roots = "0.23"
  
  [target.'cfg(all(unix, not(target_os = "macos")))'.dependencies]
diff -Nru rust-rustls-native-certs-0.6.3/debian/patches/series 
rust-rustls-native-certs-0.6.3/debian/patches/series
--- rust-rustls-native-certs-0.6.3/debian/patches/series2023-08-14 
10:14:25.0 +
+++ rust-rustls-native-certs-0.6.3/debian/patches/series2023-11-04 
02:34:55.0 +
@@ -1,4 +1,5 @@
 1001_rustls-webpki.patch
+1002_untrusted_ring.patch
 2001_security-framework.patch
 2002_schannel.patch
 2004_x509-parser.patch
diff -Nru rust-rustls-native-certs-0.6.3/debian/tests/control 
rust-rustls-native-certs-0.6.3/debian/tests/control
--- rust-rustls-native-certs-0.6.3/debian/tests/control 2023-08-07 
00:25:15.0 +
+++ rust-rustls-native-certs-0.6.3/debian/tests/control 2023-11-04 
02:42:29.0 +
@@ -4,12 

Bug#1055317: Various problems in source build

[Daniel Richard G.]

Source: llvm-toolchain-16-16.0.6
Version: 1:16.0.6-17

I am experimentally building this package on Ubuntu jammy, and have
found a few problems in the debian/ files. I'll describe them in order
of most to least significant.

First, this build failure:

begin build log excerpt
[2672/2769] cd /home/build/llvm/llvm-toolchain-16-16.0.6/libclc/build && 
/usr/bin/llvm-spirv-15 --spirv-max-version=1.1 -o spirv-mesa3d-.spv 
builtins.link.spirv-mesa3d-.bc
FAILED: spirv-mesa3d-.spv 
/home/build/llvm/llvm-toolchain-16-16.0.6/libclc/build/spirv-mesa3d-.spv 
cd /home/build/llvm/llvm-toolchain-16-16.0.6/libclc/build && 
/usr/bin/llvm-spirv-15 --spirv-max-version=1.1 -o spirv-mesa3d-.spv 
builtins.link.spirv-mesa3d-.bc
Unknown attribute kind (86) (Producer: 'LLVM16.0.6' Reader: 'LLVM 15.0.7')
end build log excerpt

The Build-Depends: resulted in llvm-spirv-15 getting installed (as that
is the latest jammy has available), and this fallback-logic line in
d/rules enabled its use:

LLVM_SPIRV_VERSION := $(shell expr $(LLVM_VERSION) - 1)

It seems pretty clear that llvm-spirv-N with N != 16 cannot be used for
the build, however.

Secondly, d/rules does not appear to be parallel-safe. If I build with
"dpkg-buildpackage -b -j8", I run into this:

begin build log excerpt
ar ruv libFuzzer.a Fuzzer*.o
Using cmake: cmake
LD_LIBRARY_PATH=/home/build/llvm/llvm-toolchain-16-16.0.6/build-llvm/lib:$LD_LIBRARY_PATH
 \
VERBOSE=1  cmake --build build-llvm -j 8 --target stage2 || cat 
build-llvm/tools/clang/stage2-bins/CMakeFiles/CMakeOutput.log
mkdir -p libclc/build
-O2 -DNDEBUG -g1 -fstack-protector-strong -Wformat -Werror=format-security 
-Wno-unused-command-line-argument -Wdate-time -D_FORTIFY_SOURCE=2
/bin/sh: 5: 
/home/build/llvm/llvm-toolchain-16-16.0.6/build-llvm/tools/clang/stage2-bins/bin/clang++:
 not found
make[1]: *** [debian/rules:760: debian-libfuzzer-build] Error 1
make[1]: *** Waiting for unfinished jobs
end build log excerpt

Adding a ".NOTPARALLEL:" line to the file prevents this from occurring.

I also noticed this (non-fatal) error:

begin build log excerpt
if ldd build-llvm/tools/clang/stage2-bins/lib/libclang-16.so.1|grep -q 
libclang-cpp-16; then \
echo "libclang-16.so.1 depends on libclang-cpp. Should not be the 
case"; \
exit 2; \
fi
ldd: build-llvm/tools/clang/stage2-bins/lib/libclang-16.so.1: No such file or 
directory
end build log excerpt

The library file is named differently:

$ ls -l build-llvm/tools/clang/stage2-bins/lib/libclang-16.so*
lrwxrwxrwx 1 build users21 Nov  3 20:40 
build-llvm/tools/clang/stage2-bins/lib/libclang-16.so -> libclang-16.so.16.0.6
-rwxr-xr-x 1 build users 124310912 Nov  3 20:40 
build-llvm/tools/clang/stage2-bins/lib/libclang-16.so.16.0.6

The check should be rewritten to ensure an absent file causes failure.

Lastly, there was this (non-fatal) error:

begin build log excerpt
   dh_fixperms
   dh_missing
   debian/rules override_dh_strip
make[1]: Entering directory '/home/build/llvm/llvm-toolchain-16-16.0.6'
: # running out of diskspace on the buildds
find build-llvm -name '*.o' -o -name '*.a' -type f | xargs -r rm -f
find: ‘build-llvm’: No such file or directory
end build log excerpt

The build-llvm directory was already removed by the
"rm -rf $(TARGET_BUILD)" line at the end of the
"override_dh_auto_install" target.


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#1055316: heimdal: fails to build against glibc 2.38

[Samuel Thibault]

Source: heimdal
Version: 7.8.git20221117.28daf24+dfsg-3
Severity: important
Tags: patch

Hello,

krb5 fails to build against glibc 2.38:

dh_makeshlibs -plibkafs0-heimdal -- -c4
dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/libkafs0-heimdal/DEBIAN/symbols doesn't match 
completely debian/libkafs0-heimdal.symbols
--- debian/libkafs0-heimdal.symbols 
(libkafs0-heimdal_7.8.git20221117.28daf24+dfsg-3_hurd-amd64)
+++ dpkg-gensymbolsLsSoXx   2023-11-03 17:37:21.0 +
@@ -12,7 +12,7 @@
  _kafs_get_cred@Base 1.4.0+git20110226
  _kafs_realm_of_cell@Base 1.4.0+git20110226
  _kafs_resolve_debug@Base 1.4.0+git20110226
- _kafs_strlcpy@Base 1.4.0+git20110226
+#MISSING: 7.8.git20221117.28daf24+dfsg-3# _kafs_strlcpy@Base 1.4.0+git20110226
  k_afs_cell_of_file@Base 1.4.0+git20110226
  k_hasafs@Base 1.4.0+git20110226
  k_hasafs_recheck@Base 1.4.0+git20110226

and similarly in libroken19-heimdal.symbols.

strlcat and strlcpy were indeed added to glibc in version 2.38, so it's
not surprising that heimdal doesn't define its internal versions any
more.

I checked all *_amd64.so packages, apparently libafsauthent2 is using
rk_strlcpy and rk_strlcat from libroken, so a Breaks transition is
needed for that.

Samuel

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

Kernel: Linux 6.5.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
--- debian/libkafs0-heimdal.symbols.original2023-11-03 18:46:33.871510701 
+0100
+++ debian/libkafs0-heimdal.symbols 2023-11-03 18:46:36.239529194 +0100
@@ -12,7 +12,6 @@
  _kafs_get_cred@Base 1.4.0+git20110226
  _kafs_realm_of_cell@Base 1.4.0+git20110226
  _kafs_resolve_debug@Base 1.4.0+git20110226
- _kafs_strlcpy@Base 1.4.0+git20110226
  k_afs_cell_of_file@Base 1.4.0+git20110226
  k_hasafs@Base 1.4.0+git20110226
  k_hasafs_recheck@Base 1.4.0+git20110226
--- debian/libroken19-heimdal.symbols.original  2023-11-03 18:46:48.879627574 
+0100
+++ debian/libroken19-heimdal.symbols   2023-11-03 18:46:50.107637104 +0100
@@ -98,8 +98,6 @@
  rk_socket_sockaddr_size@HEIMDAL_ROKEN_1.0 1.4.0+git20110226
  rk_strcollect@HEIMDAL_ROKEN_1.0 1.4.0+git20110226
  rk_strerror_r@HEIMDAL_ROKEN_1.0 1.4.0+git20110226
- rk_strlcat@HEIMDAL_ROKEN_1.0 1.4.0+git20110226
- rk_strlcpy@HEIMDAL_ROKEN_1.0 1.4.0+git20110226
  rk_strlwr@HEIMDAL_ROKEN_1.0 1.4.0+git20110226
  rk_strpoolcollect@HEIMDAL_ROKEN_1.0 1.4.0+git20110226
  rk_strpoolfree@HEIMDAL_ROKEN_1.0 1.4.0+git20110226

Bug#736851: ppp: Please ship logcheck rules

[Marco d'Itri]

Control: severity -1 wishlist
Control: tag -1 help

On Jan 27, Jonathan Wiltshire  wrote:

> Please ship snippets for consumption by the logcheck package.
Please provide sensible rules.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1052069: ways to proceed?

[Andreas Beckmann]

On 03/11/2023 22.39, Adam Majer wrote:
You need to specify ibt=off to kernel at boot time for the older nvidia 
modules to work. Since the kernel has this protection enabled by 
default, it will have to be disabled until such time as nvidia bothers 
to update/recompile these older drivers like they did the recent ones.


Thanks for your test.

Since that protection can be disabled with ibt=off, it should be 
possible to test for the status (not available/enabled/disabled) at 
module load time and fail the load process with an informative error 
message instead of calling into the incompatible code from the blob.


The EoL driver series (e.g. anything predating the 470 series) will not 
see any further updates from NVIDIA. And people still really want to use 
these old drivers for ancient hardware.


...

Maybe that was really simple. Could you try the attached patch?
(apply it to the source in /usr/src/nvidia-tesla-470-* and rebuild the 
dkms module)

Or you could simply install the -dkms package from
https://people.debian.org/~anbe/1052069/

The module should continue to work on 6.1
The module should continue to work on 6.5 booted with ibt=off
The module should fail to load with an error message describing the 
issue on 6.5 with ibt enabled, but without a kernel BUG.



AndreasFrom 17b722086d1cbc19ec6ea811a334ff9d90ad90e6 Mon Sep 17 00:00:00 2001
From: Andreas Beckmann 
Date: Sat, 4 Nov 2023 00:44:56 +0100
Subject: [PATCH] refuse to load module if IBT is enabled

---
 nvidia-modeset/nvidia-modeset-linux.c | 7 +++
 nvidia/nv.c   | 7 +++
 2 files changed, 14 insertions(+)

diff --git a/nvidia-modeset/nvidia-modeset-linux.c b/nvidia-modeset/nvidia-modeset-linux.c
index 04a8ac4..95e668e 100644
--- a/nvidia-modeset/nvidia-modeset-linux.c
+++ b/nvidia-modeset/nvidia-modeset-linux.c
@@ -1651,6 +1651,13 @@ static int __init nvkms_init(void)
 {
 int ret;
 
+#ifdef CONFIG_X86_KERNEL_IBT
+if (cpu_feature_enabled(X86_FEATURE_IBT)) {
+printk(KERN_ERR NVKMS_LOG_PREFIX "This module is incompatible with IBT. Try booting with ibt=off.");
+return -EINVAL;
+}
+#endif
+
 atomic_set(_alloc_called_count, 0);
 
 ret = nvkms_alloc_rm();
diff --git a/nvidia/nv.c b/nvidia/nv.c
index 42778da..a005d69 100644
--- a/nvidia/nv.c
+++ b/nvidia/nv.c
@@ -739,6 +739,13 @@ int __init nvidia_init_module(void)
 nvidia_stack_t *sp = NULL;
 NvU32 allow_no_gpu_init = 0;
 
+#ifdef CONFIG_X86_KERNEL_IBT
+if (cpu_feature_enabled(X86_FEATURE_IBT)) {
+printk(KERN_ERR "NVRM: This module is incompatible with IBT. Try booting with ibt=off.");
+return -EINVAL;
+}
+#endif
+
 nv_memdbg_init();
 
 rc = nv_procfs_init();
-- 
2.20.1

Bug#514274: Bad ppp frames for certain TCP package lengths

[Marco d'Itri]

On Feb 05, Eckhart Wörner  wrote:

> With a UMTS connection to o2 Germany, connections sometimes dropped. Looking 
> into that issue with wireshark, I found out that the 
> connection drops because a TCP package of length 187 + k * 240 bytes (with k 
> in 0,1,...) never makes it to the TCP stack of the 
> receiver (i.e. the computer where PPP is running). This can be reproduced 
> using netcat and a 187 byte file.
Are you still able to reproduce this issue?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#555477: /usr/sbin/pppd: ppp with persist does not redial after error

[Marco d'Itri]

On Nov 09, Alex S Kurilo  wrote:

> ppp does not redial if pppoe server return 'No client slots available' 
> (persist turned on, after other errors it tries to reconnect)
> The following line appears in the syslog before pppd dies:
> > PADS: System-Error: RP-PPPoE: Server: No client slots available
Are you still able to reproduce this issue?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#650634: pppd eats all cpu in tdb_allocate()

[Marco d'Itri]

On Dec 01, onehalf3544  wrote:

> Problem is reproducible (nobody is able to establish connection =(( ).
> I'll continue debugging, but would appreciate any advice.
Are you still able to reproduce this issue?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#451363: ppp: radius plugin stops talking to radius server

[Marco d'Itri]

On Nov 15, B Thompson  wrote:

> I am having problems with the radius plugin supplied with ppp (I am using this
> to authenticate users of my (poptop) pptp vpn. Here are the logs from a failed
> login :-
Are you still able to reproduce this issue?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1055312: adduser: "addgroup user group" is mentioned in man page but does not work anymore (ex bug 664869)

[Jamene . Logue]

Package: adduser
Followup-For: Bug #1055312

You should use:
$ sudo adduser donald ducks

Instead of trying to make `addgroup` do that.

Bug#1055032: Please update to latest upstream version

[Antonio Terceiro]

On Sun, Oct 29, 2023 at 09:29:04PM +0200, Jonathan Carter wrote:
> Package: python3-textual
> Severity: normal
> X-Debbugs-Cc: 
> 
> Dear maintainer,
> 
> The current version of python3-textual in Debian is quite out of date,
> and it's not possible to run newer textual apps with it anymore.,
> Please upgrade to the latest upstream version (currenly (0.40.0) so
> that this package can be useful again.

I have a textual locally updated to the latest upstream version:
https://salsa.debian.org/terceiro/textual

I had to disable a few tests due to either missing dependencies, of
mismatching expectations between the versions in Debian and the ones
assumed by upstream (poetry.lock). There is still some work to do, e.g.
converting the autopkgtest to use autopkgtest-pkg-pybuild.

Sandro, Would it be OK if I push that into the python team repo and
upload to the archive when I'm done?


signature.asc
Description: PGP signature

Bug#384998: rp-pppoe plugin and MLPPP don't play well together - tiny fragments are sent

[Marco d'Itri]

On Aug 28, James Harper  wrote:

> When using the rp-pppoe plugin and pppoe, the fragments used are tiny (8 
> bytes of ppp data), and consequently the link behaves really really poorly. 
> The correct behaviour is that MLPPP fragments should be (packet size) / 
> (number of links), but less than MTU. When using /usr/sbin/pppoe, it works 
> fine.
Are you still able to reproduce this issue?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1054523: RFS: persp-projectile/1:1.0.0+git20210618.4e374d7-1 [RC] [Team] -- integrate perspective.el with projectile

[Xiyue Deng]

Hi Sean,

Thanks for the review!  I initially thought d/changelog should mainly be
about user-facing changes.  But looks like it's better to be thorough.
Please see replies inline below.

Sean Whitton  writes:

> control: tag -1 + moreinfo
> control: owner -1 !
>
> Hello Xiyue,
>
> Thank you for working on this.
> A review of 2ea5e050fe78c7a382a613bc60ce5f14da4f130a:
>
> I'm wondering why you've updated git watch to check for the git HEAD,
> since upstream seems to now be tagging releases?
>

I could have mixed the impression with other repos that don't have it.
Now tracking tags and slightly modernize it using "@ANY_VERSION@".

> The changelog should mention the switch d/compat -> debhelper-compat.
>

Done.

> The typo fix in d/control should be mentioned in d/changelog.
>

Done.

> You should say that it's --parallel that you dropped from d/rules.
>

Done.

> Your justification for dropping the Built-Using should not be that
> Lintian suggested dropping it.  Please determine the real reason :)

I thought mentioning dropping Built-Using from arch:all package could be
an acceptable reason, which in turn also follows Lintian's suggestion :)
But do let me know if I should further clarify.

New updates pushed to team repo and reuploaded to mentors.  PTAL.  TIA!

-- 
Xiyue Deng


signature.asc
Description: PGP signature

Bug#861635: any hope for et to get to debian?

[Yaroslav Halchenko]

didn't check if PPA upstream promotes a good start


Re Jason's

> Also why is this changed to RFP? 

because it had been over a year without package materializing, thus it
is more of RFP than ITP.

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
WWW:   http://www.linkedin.com/in/yarik



signature.asc
Description: PGP signature

Bug#374698: pppd exits despite 'persist' option

[Marco d'Itri]

On Jun 20, Claus Fischer  wrote:

> Summary: The persist option does not work properly.
Are you still able to reproduce this issue?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1052915: libdnf: FTBFS: dh_install: error: missing files, aborting

[Luca Boccassi]

Looks like there was another issue, that only happens on sbuild/buildd
but not on pbuilder, a missing "-p" for mkdir in d/rules:

>debian/rules override_dh_auto_test
> make[1]: Entering directory '/<>'
> mkdir '/<>/debian/tests-home'
> mkdir: cannot create directory ‘/<>/debian/tests-home’: File 
> exists
> make[1]: *** [debian/rules:52: override_dh_auto_test] Error 1

Uploaded a new NMU, full debdiff attached.

-- 
Kind regards,
Luca Boccassi
--- libdnf-0.69.0/debian/changelog	2023-01-08 09:08:51.0 +
+++ libdnf-0.69.0/debian/changelog	2023-11-03 19:22:17.0 +
@@ -1,3 +1,17 @@
+libdnf (0.69.0-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Use mkdir -p in override_dh_auto_test to fix FTBFS on buildds
+
+ -- Luca Boccassi   Fri, 03 Nov 2023 19:22:17 +
+
+libdnf (0.69.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Move python3 modules from /usr/lib/local/ (Closes: #1052915)
+
+ -- Luca Boccassi   Sun, 29 Oct 2023 15:57:28 +
+
 libdnf (0.69.0-2) unstable; urgency=medium
 
   * Set myself to maintainer
diff -Nru libdnf-0.69.0/debian/python3-hawkey.install libdnf-0.69.0/debian/python3-hawkey.install
--- libdnf-0.69.0/debian/python3-hawkey.install	2022-11-12 22:06:07.0 +
+++ libdnf-0.69.0/debian/python3-hawkey.install	2023-11-03 19:17:26.0 +
@@ -1 +1 @@
-usr/local/lib/python3.*/dist-packages/hawkey
+usr/lib/python3/dist-packages/hawkey
diff -Nru libdnf-0.69.0/debian/python3-libdnf.install libdnf-0.69.0/debian/python3-libdnf.install
--- libdnf-0.69.0/debian/python3-libdnf.install	2022-11-12 22:06:07.0 +
+++ libdnf-0.69.0/debian/python3-libdnf.install	2023-11-03 19:17:11.0 +
@@ -1 +1 @@
-usr/local/lib/python3.*/dist-packages/libdnf
+usr/lib/python3/dist-packages/libdnf
diff -Nru libdnf-0.69.0/debian/rules libdnf-0.69.0/debian/rules
--- libdnf-0.69.0/debian/rules	2022-11-12 22:05:59.0 +
+++ libdnf-0.69.0/debian/rules	2023-11-03 19:21:34.0 +
@@ -49,7 +49,7 @@
 	dh_auto_clean --builddirectory=build
 
 override_dh_auto_test:
-	mkdir '$(CURDIR)/debian/tests-home'
+	mkdir -p '$(CURDIR)/debian/tests-home'
 	LC_ALL=C HOME='$(CURDIR)/debian/tests-home' dh_auto_test --builddirectory=build -- ARGS='-V'
 
 override_dh_missing:


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

Bug#203620: ppp: pppstats returns 0 for IN (incoming bytes) after a while

[Marco d'Itri]

On Jul 31, Christian Schoenebeck  wrote:

> I encountered that pppstats displays 0 for incoming bytes after a while. Here 
> is an example output of pppstats:
Are you still able to reproduce this issue?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#325746: pppd 2.4.3 (+pptpd) bug - error count recive and transmit bytes

[Marco d'Itri]

On Aug 30, Женя Дрюков  wrote:

> Error count VPN traffic  client disconnect after 10 secconds width only 
> Send bytes 113 Megabytes !!!
Are you still able to reproduce this issue?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#518624: /usr/sbin/pppd: ppp authentication mschapv2 doesn't work after upgrading winbind to 2:3.2.5-4

[Marco d'Itri]

On Mar 07, Sergey Dorofeev  wrote:

> Both upgraded.
> Windows clients also affected.
Are you still able to reproduce this issue?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#627088: ppp: reconnect after hangup fails with many Protocol-Reject messages

[Marco d'Itri]

On May 17, Richard  wrote:

> after upgrading to wheezy a previously functioning PPTP connection has 
> problems. 
> when the connection hangs up and the daemon tries to reconnect, the 
> connection fails
> with the following log messages:
Are you still able to reproduce this issue?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1055041: RFS: a2d/2.0.3-1 -- APRS to DAPNET portal

[Yogeswaran Umasankar]

Hi,
I have revised the following again,
1. Postrm file not to remove user config files, let dpkg handle them.
2. Changelog includes all the entries, including the previous ones.

Thank you,
Yogeswaran Umasankar

Bug#1008205: gamin: unmaintained upstream

[Bastian Germann]

Control: tags -1 - wontfix
Control: retitle -1 RM: gamin -- RoQA; dead upstream
Control: severity -1 serious

The reverse dependencies are all gone now. Please consider filing a RM bug.
If nobody reacts I am going to file one when gamin is removed from testing.

Bug#1055150: a2d: apt remove a2k nukes user data (postinst)

[Yogeswaran Umasankar]

Hi,
I have revised postrm not to remove user config files. I let the dpkg to
take care of config files.

Thank you,
Yogeswaran Umasankar

Bug#1055314: RM: golang-github-bits-and-blooms-bloom -- ROM; Duplicates golang-github-willf-bloom

[John Goerzen]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove


Hello,

I learned at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055134 that
golang-github-bits-and-blooms-bloom duplicates functionality in an existing
package.

Please remove  golang-github-bits-and-blooms-bloom.

Thanks,

John

Bug#1055315: webext-ublock-origin-firefox: new upstream version

[Christoph Anton Mitterer]

Package: webext-ublock-origin-firefox
Version: 1.52.0+dfsg-1
Severity: wishlist

Hey.

1.53.0 is out since a few days :-)

Thanks,
Chris.

Bug#1051924: devscripts: FTBFS fails in test test/test_debchange

[Santiago Vila]

severity 1051924 serious
thanks

Hi. I also found this. Raising to serious, as it's a FTBFS bug.

Thanks.

Bug#1030904: libgovirt: FTBFS randomly (Could not connect to localhost: Connection refused)

[Santiago Vila]

severity 1030904 serious
thanks

Actually, this fails more than 80% of the time for me,
on machines with 2 CPUs from Hetzner, and I also
get failures on AWS.

Moreover, it fails in reproducible-builds:

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

And there are also build failures on the official buildds:

https://buildd.debian.org/status/fetch.php?pkg=libgovirt=armel=0.3.9-2=1662476014=0

If you want to reproduce this, I've noticed that the failure rate is a lot 
higher
on single-cpu systems, so you might want to try GRUB_CMDLINE_LINUX="nr_cpus=1".

If you can't reproduce the problem that way, I can offer ssh access to a
machine where this happens almost all the time, as I already said in the initial
bug report (please contact me privately for details).

Thanks.

Bug#1055313: RFS: streamlink/6.3.1-1~bpo12+1 -- CLI for extracting video streams from various websites to a video player

[Alexis Murzeau]

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

Dear mentors,

I am looking for a sponsor for my package "streamlink" into Debian
bookworm-backports repository.

  * Package name: streamlink
Version : 6.3.1-1~bpo12+1
Upstream Author : Streamlink Team
  * URL : https://streamlink.github.io/
  * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1
  * Vcs : https://salsa.debian.org/amurzeau/streamlink/
Section : python

It builds those binary packages:

  python3-streamlink - Python module for extracting video streams from
various websites
  streamlink - CLI for extracting video streams from various websites
to a video player


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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_6.3.1-1~bpo12+1.dsc


Differences from testing package (6.2.1-1~bpo12+1):
  * d/control,rules: remove doc package because of missing dependencies
on bookworm.


Changes since the previous backported version in bookworm:
streamlink (6.3.1-1~bpo12+1) bookworm-backports; urgency=medium

  * Rebuild for bookworm-backports.

 -- Alexis Murzeau   Fri, 03 Nov 2023 23:19:55 +0100

streamlink (6.3.1-1) unstable; urgency=medium

  * New upstream version 6.3.1

 -- Alexis Murzeau   Sun, 29 Oct 2023 10:28:08 +0100

streamlink (6.3.0-1) unstable; urgency=medium

  * d/README: update backport instructions
  * d/README: update readme for building backported package
  * New upstream version 6.3.0
  * d/patches: remove now unneeded patch that was removing versioningit

 -- Alexis Murzeau   Wed, 25 Oct 2023 21:37:25 +0200

Regards,
--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F |

Bug#823651: sudo apt install libpam-tmpdir breaks cowbuilder

[Thorsten Glaser]

Patrick Schleizer dixit:

> sudo apt install libpam-tmpdir
>
> is enough to break cowbuilder, which then calls pbuilder.

Just unset TMP in a wrapper you do around cowbuilder.
Hasn’t this been reported multiple times already?

In fact, it’s best to only let a whitelist of environment
variables in so your package build is not unexpectedly
changed, so that’s good hygiene anyway.

bye,
//mirabilos
-- 
  "Using Lynx is like wearing a really good pair of shades: cuts out
   the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL."
 -- Henry Nelson, March 1999

Bug#1055312: adduser: "addgroup user group" is mentioned in man page but does not work anymore (ex bug 664869)

[boffi]

Package: adduser
Version: 3.137
Severity: normal
X-Debbugs-Cc: giacomo.bo...@gmail.com

Dear Maintainer,
on my ap to date Debian Sid system

$ man addgroup # says
...

   Add an existing user to an existing group
   If called with two non-option arguments, adduser will add  an  existing
   user to an existing group.
...
$ 

but when I try to add a user to a group, this is what it happens

$ sudo addgroup donald ducks
[sudo] password for boffi: 
fatal: addgroup with two arguments is an unspecified operation.
$ 

as far as I can tell, this was the outcome of bug 664869,
where the OP claimed that the two arguments call was not
mentioned in the man page.

It is mentioned, at least in my man page.

Regards ፨ gb

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

Kernel: Linux 6.3.0-2-amd64 (SMP w/4 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 adduser depends on:
ii  passwd  1:4.13+dfsg1-3

adduser recommends no packages.

Versions of packages adduser suggests:
ii  cron3.0pl1-178
ii  liblocale-gettext-perl  1.07-6
ii  perl5.36.0-9
pn  quota   

-- debconf information:
  adduser/homedir-permission: true
  adduser/title:

Bug#1055311: libqt6gui6: recommend libqt6svg6

[Amy Kos]

Package: libqt6gui6
Version: 6.4.2+dfsg-19
Severity: wishlist


Hi,

libqt5gui5 recommends libqt5svg5.
Please add recommendation of libqt6svg6 accordingly.

Without libqt6svg6 icons can't be displayed,
for instance in recent audacious Qt6 build.

Thanks,
Amy

Bug#1055269: udd: bugs.cgi does not show bugs for source packages in non-free-firmware

[Cyril Brulebois]

Lucas Nussbaum  (2023-11-03):
> UDD uses several independant "importers". The constraint you quoted is
> in the "blends" importer (maintained by Andreas Tille, cced).

ACK, I spotted a number of things that were blends-related, didn't
realize that particular schema was too.

> The reason why UDD thinks that #1055136 does not affect unstable, is
> because the BTS thinks it does not affect unstable. If you look at the
> version graph for the bug, you see that the BTS only knows about the
> version in oldstable, not about the versions in stable/testing/unstable.
> The same happens for other packages in non-free-firmware (see #1038610
> for example).

https://github.com/dondelelcaro/debbugs/issues/2 then.


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


signature.asc
Description: PGP signature

Bug#972709: Fwd: Why is a negative review showing on V2 profile page for Star Orthodontics?

[Flavio Veloso Soares]

Sorry, please disregard the last email. It was sent in error.

Bug#1052069: ways to proceed?

[Adam Majer]

reopen 1052069
retitle -1 kernel oops on module load due to IBT=ON in recent kernels
thanks

On 2023-11-03 12:42, Andreas Beckmann wrote:

Hi Adam,

On 31/10/2023 22.06, Adam Majer wrote:
So, what's the way to proceed here? Can we add the boot parameter when 
the legacy kernel module is to be loaded on newer Intel processors?


I probably made a mistake while backporting some non-trivial changes for 
supporting recent kernels. With the availability of 470.223.02 I could 
verify my backport against the upstream version, drop a lot of unneeded 
bits and fix some discrepancies...


So, I've now tested it against 6.5.0-3-amd64 and the problem remains. 
It's not related to any of your "mistakes" :-)


You need to specify ibt=off to kernel at boot time for the older nvidia 
modules to work. Since the kernel has this protection enabled by 
default, it will have to be disabled until such time as nvidia bothers 
to update/recompile these older drivers like they did the recent ones.


- Adam

Bug#972709: Fwd: Why is a negative review showing on V2 profile page for Star Orthodontics?

[Flavio Veloso Soares]

FYI:

 Forwarded Message 
Subject: 	Re: Why is a negative review showing on V2 profile page for 
Star Orthodontics?

Date:   Fri, 3 Nov 2023 11:28:06 -0700
From:   Nadeem Kassam 
To: James R 
CC: 	Flavio Veloso Soares , Malcolm Turner 





(...)

When reviewing the profile page filtering options, I noticed that the 
Sort By and the Review Sources do not work. Is that a bug or are we 
still working on that functionality.


Best,

Nadeem

Bug#1055310: Should recommend xdg-utils

[Manuel Lorenzo]

Package: syncthing
Version: 1.19.2~ds1-1+b4

Syncthing makes use of xdg-open to launch the web interface, therefore 
xdg-utils (package which contains xdg-open) should be added at least as a 
recommended dependency.

Output when launching syncthing-ui.desktop or:
$ /usr/bin/syncthing -browser-only

WARNING: Failed to open web UI: exec: "xdg-open": executable file not found in 
$PATH

Bug#1009067: How can I help move this along?

[Lisandro Damián Nicanor Pérez Meyer]

On Thu, 2 Nov 2023 at 17:09, Charles Suprin  wrote:
>
> Howdy,
>
> This seems to be fixed but not moving forward.

Probably an NMU :-/

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1055269: udd: bugs.cgi does not show bugs for source packages in non-free-firmware

[Lucas Nussbaum]

Hi,

On 03/11/23 at 13:52 +0100, Cyril Brulebois wrote:
> Andreas Beckmann  (2023-11-03):
> > The list of RC bugs in sid
> > https://udd.debian.org/bugs.cgi?release=sid=ign=7=7=1=id=desc=html#results
> > does not contain e.g. #1055136 filed against src:nvidia-graphics-drivers
> > which is in non-free-firmware, but it lists the clones of this bug that
> > are assigned to various old driver series
> > src:nvidia-graphics-drivers-{tesla,legacy}-* that are still in non-free
> > (not in non-free-firmware).
> > 
> > Interestingly the RC bug list for bullseye
> > https://udd.debian.org/bugs.cgi?release=bullseye=ign=7=7=1=id=desc=html#results
> > does list the bug. src:nvidia-graphics-drivers/bullseye is in non-free.
> 
> Indeed, udd doesn't seem to know about non-free-firmware at all, e.g.:
> 
> CONSTRAINT check_component CHECK ((component = ANY (ARRAY['main'::text, 
> 'contrib'::text, 'non-free'::text])))
> 
> Things like udd/ftpnew_gatherer.py could almost work by accident since
> that's using .startswith() (but then assigning "non-free" as value, so
> that probably doesn't work anyway).
> 
> I'm afraid I'm not learning udd's codebase and configuration today.

UDD uses several independant "importers". The constraint you quoted is
in the "blends" importer (maintained by Andreas Tille, cced).

To debug this, you can use the SQL query at the bottom of the page:
select id, bugs.package, bugs.source, severity, title, last_modified,
status, affects_stable, affects_testing, affects_unstable,
affects_experimental 
from bugs 
where id in (select id from bugs_rt_affects_unstable) 
and not (id in (select id from bugs_merged_with where id > merged_with)) 
AND (severity >= 'serious')
order by id desc

#1055136 is not listed because it's not in "select id from
bugs_rt_affects_unstable".
That view uses the bugs_rt_affects_dist function, that basically does
"check if the BTS thinks the bug affects a distribuation, and then
override if release team tags (e.g. xx-ignore) are used".

The reason why UDD thinks that #1055136 does not affect unstable, is
because the BTS thinks it does not affect unstable. If you look at the
version graph for the bug, you see that the BTS only knows about the
version in oldstable, not about the versions in stable/testing/unstable.
The same happens for other packages in non-free-firmware (see #1038610
for example).

Lucas

Bug#1055309: gkrellm: the clock format should honor the LC_TIME locale by default

[Vincent Lefevre]

Package: gkrellm
Version: 2.3.11-2
Severity: wishlist

The default clock (time) format is

  %l:%M %S

but %l is the hour between 1 and 12, which is not the format used by
most countries (in addition to being confusing).

The default clock format should be based on the current LC_TIME locale.

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

Kernel: Linux 6.1.0-13-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=POSIX, 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 gkrellm depends on:
ii  libc62.36-9+deb12u3
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2
ii  libgnutls-openssl27  3.7.9-2
ii  libgnutls30  3.7.9-2
ii  libgtk2.0-0  2.24.33-2
ii  libice6  2:1.0.10-1
ii  libntlm0 1.6-4
ii  libpango-1.0-0   1.50.12+ds-1
ii  libsensors5  1:3.6.0-7.1
ii  libsm6   2:1.2.3-1
ii  libx11-6 2:1.8.7-1

gkrellm recommends no packages.

gkrellm 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#1052002: firefox: FTBFS: ERROR: Cannot find wasi headers or problem with the wasm compiler. Please fix the problem. Or build with --without-wasm-sandboxed-libraries

[Faidon Liambotis]

Control: reopen -1
Control: found -1 1:16.0.6-17

This is still not fixed :( Mike's findings still stand:

On Sat, Sep 16, 2023 at 05:53:55AM +0900, Mike Hommey wrote:
> This is a regression from the upgrade to clang 16.
> 
> with clang 14:
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/include/wasm32-wasi/c++/v1
>  /usr/lib/llvm-14/lib/clang/14.0.6/include
>  /usr/local/include
>  /usr/include/wasm32-wasi
>  /usr/include
> End of search list.
> 
> with clang 16:
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/lib/llvm-16/lib/clang/16/include
>  /usr/local/include
>  /usr/include/wasm32-wasi
>  /usr/include
> End of search list.
> 
> Note how /usr/include/wasm32-wasi/c++/v1 is missing.

Test case:
  $ apt install clang lld libclang-rt-dev-wasm32 libc++-dev-wasm32
  $ cat > hello.cpp <
  
  int main() {
std::cout << "hello world" << std::endl;
return 0;
  }
  EOF
  $ /usr/bin/clang++ -v --target=wasm32-wasi hello.cpp

Only C++ include paths are affected, not C. This almost certainly has to
do with the patch we carry for wasm include paths, that I have
contributed to. Unfortunately I have no time to look into it right now
:( I may find some time in a couple of weeks, but hoping someone else
can take care of it in the meantime :/

Best,
Faidon

Bug#1055308: RM: golang-github-go-macaron-bindata -- RoQA; obsolete

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: golang-github-go-macaron-bind...@packages.debian.org
Control: affects -1 + src:golang-github-go-macaron-bindata

Please remove golang-github-go-macaron-bindata. The version in the archive is a 
very
old snapshot from 2016 without rdeps, Macaron was originally uploaded for gitea
which is no longer in the archive.

Bug#1055307: busybox: CVE-2023-39810

[Moritz Mühlenhoff]

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

Hi,

The following vulnerability was published for busybox.

CVE-2023-39810[0]:
| An issue in the CPIO command of Busybox v1.33.2 allows attackers to
| execute a directory traversal.

https://www.pentagrid.ch/en/blog/busybox-cpio-directory-traversal-vulnerability/

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

Please adjust the affected versions in the BTS as needed.

Bug#1055306: jpeg-xl: CVE-2023-35790

[Moritz Mühlenhoff]

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

Hi,

The following vulnerability was published for jpeg-xl.

CVE-2023-35790[0]:
| An issue was discovered in dec_patch_dictionary.cc in libjxl before
| 0.8.2. An integer underflow in patch decoding can lead to a denial
| of service, such as an infinite loop.

https://github.com/libjxl/libjxl/pull/2551
https://github.com/libjxl/libjxl/commit/d4e67a644d8babe7cb68de122d8b5ccb2ad8f226

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

Please adjust the affected versions in the BTS as needed.

Bug#1054323: r-cran-tmb: autopkgtest needs update for new version of rmatrix: Package version inconsistency detected

[Paul Gevers]

Hi Andreas,

On 03-11-2023 07:11, Andreas Tille wrote:

I did not used a tight Depends (see r-cran-matrix (>= $${rmbversion}) in
[1]) but I think the check you suggested to patch out will fire for new
Matrix versions.


Hence, if you really want to do this version dance (which I prefer we 
don't, but I agree aligning with upstream is good), I think we prefer 
the tight versioned dependency. Because than it shows up in the 
transition overview and it's clear it needs a rebuild (I guess binNMU 
now should work). A "mere" regression just blocks r-cran-matrix until 
somebody informs you (typically me, but only after one month), which is 
annoying for everyone involved.



BTW, now we have a new kind of regression[2]

  56s Error: (converted from warning) package ‘TMB’ was built under R version 
4.3.2

I have no idea how to fix this from my side.


Well, exactly the same trick, but instead of r-cran-matrix on one of the 
core r things? Or block that "converted from warning" thing from 
converting warnings to errors.


Paul

[1] https://release.debian.org/transitions/


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055305: freeimage: CVE-2021-40266

[Moritz Mühlenhoff]

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

Hi,

The following vulnerability was published for freeimage.

CVE-2021-40266[0]:
| FreeImage before 1.18.0, ReadPalette function in PluginTIFF.cpp is
| vulnerabile to null pointer dereference.

https://sourceforge.net/p/freeimage/bugs/334/

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-40266
https://www.cve.org/CVERecord?id=CVE-2021-40266

Please adjust the affected versions in the BTS as needed.

Bug#1055304: freeimage: CVE-2021-40265

[Moritz Mühlenhoff]

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

Hi,

The following vulnerability was published for freeimage.

CVE-2021-40265[0]:
| A heap overflow bug exists FreeImage before 1.18.0 via ofLoad
| function in PluginJPEG.cpp.

https://sourceforge.net/p/freeimage/bugs/337/

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-40265
https://www.cve.org/CVERecord?id=CVE-2021-40265

Please adjust the affected versions in the BTS as needed.

Bug#1055303: freeimage: CVE-2021-40264

[Moritz Mühlenhoff]

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

Hi,

The following vulnerability was published for freeimage.

CVE-2021-40264[0]:
| NULL pointer dereference vulnerability in FreeImage before 1.18.0
| via the FreeImage_CloneTag function inFreeImageTag.cpp.

https://sourceforge.net/p/freeimage/bugs/335/

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-40264
https://www.cve.org/CVERecord?id=CVE-2021-40264

Please adjust the affected versions in the BTS as needed.

Bug#1055302: freeimage: CVE-2021-40263

[Moritz Mühlenhoff]

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

Hi,

The following vulnerability was published for freeimage.

CVE-2021-40263[0]:
| A heap overflow vulnerability in FreeImage 1.18.0 via the ofLoad
| function in PluginTIFF.cpp.

https://sourceforge.net/p/freeimage/bugs/336/

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-40263
https://www.cve.org/CVERecord?id=CVE-2021-40263

Please adjust the affected versions in the BTS as needed.

Bug#1055301: freeimage: CVE-2021-40262

[Moritz Mühlenhoff]

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

Hi,

The following vulnerability was published for freeimage.

CVE-2021-40262[0]:
| A stack exhaustion issue was discovered in FreeImage before 1.18.0
| via the Validate function in PluginRAW.cpp.

https://sourceforge.net/p/freeimage/bugs/338/


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-40262
https://www.cve.org/CVERecord?id=CVE-2021-40262

Please adjust the affected versions in the BTS as needed.

Bug#1055300: ansible: CVE-2023-4237

[Moritz Mühlenhoff]

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

Hi,

The following vulnerability was published for ansible.

CVE-2023-4237[0]:
| A flaw was found in the Ansible Automation Platform. When creating a
| new keypair, the ec2_key module prints out the private key directly
| to the standard output. This flaw allows an attacker to fetch those
| keys from the log files, compromising the system's confidentiality,
| integrity, and availability.

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

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

Please adjust the affected versions in the BTS as needed.

Bug#1055298: gpac: CVE-2023-46927 CVE-2023-46928 CVE-2023-46930 CVE-2023-46931

[Moritz Mühlenhoff]

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

Hi,

The following vulnerabilities were published for gpac.

CVE-2023-46927[0]:
| GPAC 2.3-DEV-rev605-gfc9e29089-master contains a heap-buffer-
| overflow in gf_isom_use_compact_size
| gpac/src/isomedia/isom_write.c:3403:3 in gpac/MP4Box.

https://github.com/gpac/gpac/issues/2657
https://github.com/gpac/gpac/commit/a7b467b151d9b54badbc4dd71e7a366b7c391817

CVE-2023-46928[1]:
| GPAC 2.3-DEV-rev605-gfc9e29089-master contains a SEGV in gpac/MP4Box
| in gf_media_change_pl
| /afltest/gpac/src/media_tools/isom_tools.c:3293:42.

https://github.com/gpac/gpac/issues/2661
https://github.com/gpac/gpac/commit/0753bf6d867343a80a044bf47a27d0b7accc8bf1

CVE-2023-46930[2]:
| GPAC 2.3-DEV-rev605-gfc9e29089-master contains a SEGV in gpac/MP4Box
| in gf_isom_find_od_id_for_track
| /afltest/gpac/src/isomedia/media_odf.c:522:14.

https://github.com/gpac/gpac/issues/2666
https://github.com/gpac/gpac/commit/3809955065afa3da1ad580012ec43deadbb0f2c8

CVE-2023-46931[3]:
| GPAC 2.3-DEV-rev605-gfc9e29089-master contains a heap-buffer-
| overflow in ffdmx_parse_side_data
| /afltest/gpac/src/filters/ff_dmx.c:202:14 in gpac/MP4Box.

https://github.com/gpac/gpac/issues/2664
https://github.com/gpac/gpac/commit/671976fccc971b3dff8d3dcf6ebd600472ca64bf

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-46927
https://www.cve.org/CVERecord?id=CVE-2023-46927
[1] https://security-tracker.debian.org/tracker/CVE-2023-46928
https://www.cve.org/CVERecord?id=CVE-2023-46928
[2] https://security-tracker.debian.org/tracker/CVE-2023-46930
https://www.cve.org/CVERecord?id=CVE-2023-46930
[3] https://security-tracker.debian.org/tracker/CVE-2023-46931
https://www.cve.org/CVERecord?id=CVE-2023-46931

Please adjust the affected versions in the BTS as needed.

Bug#1055299: wabt: CVE-2023-46332

[Moritz Mühlenhoff]

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

Hi,

The following vulnerability was published for wabt.

CVE-2023-46332[0]:
| WebAssembly wabt 1.0.33 contains an Out-of-Bound Memory Write in
| DataSegment::Drop(), which lead to segmentation fault.

https://github.com/WebAssembly/wabt/issues/2311

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

Please adjust the affected versions in the BTS as needed.

Bug#1051418: Info received (obs-studio: clicking on an xcomposite window source makes obs segfault)

[Michael Neilly]

For the link provided, the crash occurs because of the presence of the unicode 
middot character. The wchar_to_utf8() function in libobs utils checks for any 
char that is less than 0 and returns zero. This results in dstr_to_lower() not 
updating name_lower in xcompcap_props(). The empty name_lower string is pushed 
to window_strings which causes qsort() to SEGV.

The following is the check that fails in libobs/utils/utf8.c:

292                  if ((signed char)*w < 0) {
293                          if ((flags & UTF8_IGNORE_ERROR) == 0)
294                                  return 0;                                  
                                        295                          continue;  
                            

Bug#1055297: ruby3.1: fails to build against glibc 2.38

[Samuel Thibault]

Package: ruby3.1
Version: 3.1.2-7
Severity: important
Tags: patch

Hello,

ruby3.1 fails to build against glibc 2.38:

dpkg-gensymbols -plibruby3.1 -Idebian/libruby3.1.symbols -Pdebian/libruby3.1 
-edebian/libruby3.1/usr/lib/x86_64-gnu/libruby-3.1.so.3.1.2
dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/libruby3.1/DEBIAN/symbols doesn't match 
completely debian/libruby3.1.symbols
--- debian/libruby3.1.symbols (libruby3.1_3.1.2-7_hurd-amd64)
+++ dpkg-gensymbols5L9SYx   2023-11-03 17:57:31.0 +
[...]
@@ -1818,5 +1818,5 @@
  ruby_xrealloc2@Base 3.1.0~preview1
  ruby_xrealloc@Base 3.1.0~preview1
  setproctitle@Base 3.1.0~preview1
- strlcat@Base 3.1.0~preview1
- strlcpy@Base 3.1.0~preview1
+#MISSING: 3.1.2-7# strlcat@Base 3.1.0~preview1
+#MISSING: 3.1.2-7# strlcpy@Base 3.1.0~preview1

strlcat and strlcpy were indeed added to glibc in version 2.38, so it's
not surprising that ruby3.1 doesn't define its internal versions any
more, and the attached patch can probably be applied?

Samuel

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

Kernel: Linux 6.5.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 ruby3.1 depends on:
ii  libc6 2.37-12
ii  libcrypt1 1:4.4.36-2
ii  libgmp10  2:6.3.0+dfsg-2
ii  libruby3.13.1.2-7
ii  rubygems-integration  1.18
ii  zlib1g1:1.2.13.dfsg-3

Versions of packages ruby3.1 recommends:
ii  fonts-lato2.015-1
ii  libjs-jquery  3.6.1+dfsg+~3.5.14-1

ruby3.1 suggests no packages.

-- no debconf information

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
--- debian/libruby3.1.symbols.original  2023-11-03 18:01:01.0 +
+++ debian/libruby3.1.symbols   2023-11-03 18:01:23.0 +
@@ -1818,5 +1818,5 @@
  ruby_xrealloc2@Base 3.1.0~preview1
  ruby_xrealloc@Base 3.1.0~preview1
  setproctitle@Base 3.1.0~preview1
- strlcat@Base 3.1.0~preview1
- strlcpy@Base 3.1.0~preview1
+ (optional)strlcat@Base 3.1.0~preview1
+ (optional)strlcpy@Base 3.1.0~preview1

Bug#1055275: dhcpcd: Version 10.0.4 fails to fork in the background

[Martin-Éric Racine]

On Fri, 03 Nov 2023 12:46:21 +0100 Skibbi  wrote:
> Package: dhcpcd
> Version: 1:10.0.4-1
> Severity: critical
> Justification: breaks the whole system
>
> Dear Maintainer,
> I'm using dhcpcd on my raspbian os and it was updated on 31 October to
> latest version 10.0.4. Since then, my raspberrypi started loosing network
> every 24h. After some investigation I found out that my dhcpcd daemon is
> not working in the background.

It would be a good idea to familiarize yourself with Debian's bug
severity levels. One particular feature (daemon mode) no longer
working as expected does not qualify as a critical bug.

Meanwhile, using dhcpcd as a DHCP backend via /etc/network/interfaces
still works as expected. I suggest using that until upstream has
figured out what causes daemon mode to no longer fork since the 10.0.4
release.

Martin-Éric

Bug#1052804: ycmd: FTBFS: make[1]: *** [debian/rules:28: override_dh_auto_test] Error 1

[David Kalnischkies]

Control: forwarded -1 https://github.com/ycm-core/ycmd/issues/1718

Hi,

the problem is that upstream code isn't supporting Unicode 15.1 yet,
which introduced a new word break rule. They embed the code (for 13),
but for Debian I opted to drop the embed and use whatever unicode-data
ships to rebuild the files, which bites us in the rear end here –
as it kinda should be.

I reported upstream and they have a PR implementing the needed support
already as well: https://github.com/ycm-core/ycmd/pull/1719
As said there it works fine for me in local tests, so this issue here
should be resolvable in the near future.


vim-youcompleteme (which is a rdepends of ycmd) is currently affected by
a regression in vim through (https://bugs.debian.org/1055287) which
makes updating ycmd with the unmerged upstream patch not that useful for
now (as it would never migrate – or, well, battle with vim for a spot).

So, I am currently waiting for either vim or upstream to act first while
dealing with other housekeeping things (clang-17 support) in the
meantime; so much as a status report in case anyone wonders.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#1055296: autotalent does not work with ardour

[piratebab]

Package: autotalent
Version: 0.2-6
Severity: important
Tags: upstream

Dear Maintainer,

in ardour,plugin manager  autotalent is in error
Cannot load module "/usr/lib/ladspa/autotalent.so" 
(/usr/lib/ladspa/autotalent.so: undefined symbol: __exp_finite)


 ***
- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (985, 'testing'), (530, 'stable'), (500, 
'stable-updates'), (500, 'stable-security'), (98, 'unstable'), (96, 
'experimental')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.4.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages autotalent depends on:
ii  libc6  2.37-12

autotalent recommends no packages.

autotalent suggests no packages.

-- no debconf information

regards

Bug#717843: please provide a staged build for xfonts-utils

[Samuel Thibault]

Hello,

Any news on this? This is posing problem to bootstrap each and every new
Debian port.

Samuel

Bug#1055196: RFS: golang-github-apenella-go-common-utils

[weepingclown]

Dear Go team,

I am looking for a sponsor for the package 
"golang-github-apenella-go-common-utils".
This package is a prerequisite for upcoming package go-ansible (#1055192).

I pushed my work to our team's Salsa:
  
https://salsa.debian.org/go-team/packages/golang-github-apenella-go-common-utils

Could you please review/sponsor this?
Any kind of reviews and suggestions are appreciated.

Bug#1055295: RM: libqt6opengl6-dev -- ROM; Package is not built anymore

[Patrick Franz]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: qt6-b...@packages.debian.org, delta...@debian.org
Control: affects -1 + src:qt6-base

Hi,

could you please remove the binary package "libqt6opengl6-dev" from
unstable ? It is also available in bullseye-backports and bookworm,
but still needed in those 2 suites.

The reason is that qt6-base from 6.4.2+dfsg-12 on does not build
libqt6opengl6-dev anymore as the functionality has been moved into
qt6-base-dev.

Thank you.


Regards, Patrick Franz

Bug#1055195: RFS: golang-github-sosedoff-ansible-vault-go

[weepingclown]

Dear Go team,

I am looking for a sponsor for the package 
"golang-github-sosedoff-ansible-vault-go".
This package is a prerequisite for upcoming package go-ansible (#1055192).

I pushed my work to our team's Salsa:
  
https://salsa.debian.org/go-team/packages/golang-github-sosedoff-ansible-vault-go

Could you please review/sponsor this?
Any kind of reviews and suggestions are appreciated.

Thanks.

Bug#1055294: Acknowledgement (RFP: bitlbee-discord -- Bitlbee plugin for Discord)

[Antoine Beaupré]

After writing this report, I have also found two alternate
implementation, one is an actual IRC server and the other an irssi
plugin.

https://github.com/mk-fg/reliable-discord-client-irc-daemon
https://github.com/mjsir911/irssi-discord

the ircd has this interesting WARNING that Discord might consider any
non-native client to be a bot and accordingly banned.

a.
-- 
Non qui parum habet, sed qui plus cupit, pauper est.
It is not the man who has too little, but the man who craves more,
that is poor.- Lucius Annaeus Seneca (65 AD)

Bug#1055294: RFP: bitlbee-discord -- Bitlbee plugin for Discord

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: jel...@debian.org, wil...@gaast.net

* Package name: bitlbee-discord
  Version : 0.4.3
  Upstream Contact: https://github.com/sm00th
* URL : https://github.com/sm00th/bitlbee-discord
* License : GPL-2
  Programming Lang: C
  Description : Bitlbee plugin for Discord

Plugin to bridges IRC and Discord through the bitlbee server.



There's already support for discord through the bitlbee-libpurple
plugin, but this one is a little more straightforward and doesn't
require pulling in the entire libpurple attack surface...

Bug#1052052: ping?

[Rene Engelhard]

Hi,

Am 03.11.23 um 13:18 schrieb Gabor Karsay:

Rene Engelhard schrieb am 03.11.23 um 06:12:

Am 02.11.23 um 23:25 schrieb Gabor Karsay:

I haven't uploaded it yet, I don't know if I should target
experimental or unstable?

unstable, please.


I've uploaded to https://mentors.debian.net/ , waiting for a sponsor.


hrmpf :). Done :)



I also don't understand why the build i386 pipeline failed complaining
about unmet dependencies.


Neither me, but maybe it fell into some temporary issue (e.gf. caused by
the 7.5.8-1 upload)?


The pipeline succeeded after a retry.


Good :)


Regards,


Rene

Bug#1055022: bullseye-pu: package distro-info-data/0.51+deb11u5

[David Paul]

Stefano,

Short version:
Would you consider modifying this bullseye-pu for
distro-info-data/0.51+deb11u5 into a bullseye-pu for a
distro-info-data/0.59~deb11u1 instead?

Long version:
The resulting distro-info-data_0.51+deb11u5_all.deb binary package
resulting from your proposed debdiff is identical within a rounding
error[1] to the distro-info-data_0.59_all.deb binary package currently
in testing and unstable. The 0.51+deb11u4 and 0.58 binary package
versions from oldstable and stable are equally similar.

Within each pair the respective source packages have diverged
somewhat in spite of producing essentially identical binary packages.
In my experimentation the distro-info-data 0.59 source package builds
flawlessly in a bullseye chroot.

I recently independently discovered Debian bug #711238[2] with
devscripts and I would would like to see it fixed in unstable and
my desired fix of adding to it a Build-Depends on
```
distro-info-data (>= 0.58~) 
```
would be made possible by this change and would be a much cleaner fix
than the alternative fix of adding Build-Depends on
```
distro-info-data (>= 0.51+deb11u4) ,
distro-info-data (>= 0.58) | distro-info-data (< 0.51+deb11u+) 
```.

[1] The only differences being the changelog, the version
number, one date range in the copyright file, and any metadata directly
generated from those three things, like checksums and file sizes.
[2] https://bugs.debian.org/711238

Thanks,

-- 
Plasma

Bug#1030129: ca-certificates-java - Fails to install: Error loading java.security file

[Dimitry Andric]

FWIW, I can still reproduce the problem with Debian 10 (yeah I know, I should 
upgrade :), by attempting to install build-essential and 
openjdk-11-jre-headless in one apt-get invocation. E.g. using a simple 
Dockerfile:

==
FROM debian:10

RUN DEBIAN_FRONTEND=noninteractive apt-get -q -y update
RUN DEBIAN_FRONTEND=noninteractive apt-get -q -y upgrade
RUN DEBIAN_FRONTEND=noninteractive apt-get -q -y install build-essential 
openjdk-11-jre-headless
==

Results in:

==
...
#7 21.52 Setting up ca-certificates-java (20190405) ...
#7 21.55 head: cannot open '/etc/ssl/certs/java/cacerts' for reading: No such 
file or directory
#7 21.62 Exception in thread "main" java.lang.InternalError: Error loading 
java.security file
#7 21.62at java.base/java.security.Security.initialize(Security.java:94)
#7 21.62at java.base/java.security.Security$1.run(Security.java:79)
#7 21.62at java.base/java.security.Security$1.run(Security.java:77)
#7 21.62at java.base/java.security.AccessController.doPrivileged(Native 
Method)
#7 21.62at java.base/java.security.Security.(Security.java:77)
#7 21.62at 
java.base/sun.security.jca.ProviderList.(ProviderList.java:176)
#7 21.62at 
java.base/sun.security.jca.ProviderList$2.run(ProviderList.java:94)
#7 21.62at 
java.base/sun.security.jca.ProviderList$2.run(ProviderList.java:92)
#7 21.62at java.base/java.security.AccessController.doPrivileged(Native 
Method)
#7 21.62at 
java.base/sun.security.jca.ProviderList.fromSecurityProperties(ProviderList.java:91)
#7 21.62at 
java.base/sun.security.jca.Providers.(Providers.java:54)
#7 21.62at 
java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:156)
#7 21.62at 
java.base/java.security.cert.CertificateFactory.getInstance(CertificateFactory.java:193)
#7 21.62at 
org.debian.security.KeyStoreHandler.(KeyStoreHandler.java:50)
#7 21.62at 
org.debian.security.UpdateCertificates.(UpdateCertificates.java:65)
#7 21.62at 
org.debian.security.UpdateCertificates.main(UpdateCertificates.java:51)
#7 21.64 dpkg: error processing package ca-certificates-java (--configure):
#7 21.64  installed ca-certificates-java package post-installation script 
subprocess returned error exit status 1
#7 21.64 dpkg: dependency problems prevent configuration of 
openjdk-11-jre-headless:amd64:
#7 21.64  openjdk-11-jre-headless:amd64 depends on ca-certificates-java (>= 
20190405~); however:
#7 21.64   Package ca-certificates-java is not configured yet.
#7 21.64
#7 21.64 dpkg: error processing package openjdk-11-jre-headless:amd64 
(--configure):
#7 21.64  dependency problems - leaving unconfigured
#7 21.64 Processing triggers for libc-bin (2.28-10+deb10u2) ...
#7 21.66 Processing triggers for ca-certificates (20200601~deb10u2) ...
#7 21.67 Updating certificates in /etc/ssl/certs...
#7 22.04 0 added, 0 removed; done.
#7 22.04 Running hooks in /etc/ca-certificates/update.d...
#7 22.04
#7 22.12 Exception in thread "main" java.lang.InternalError: Error loading 
java.security file
#7 22.12at java.base/java.security.Security.initialize(Security.java:94)
#7 22.12at java.base/java.security.Security$1.run(Security.java:79)
#7 22.12at java.base/java.security.Security$1.run(Security.java:77)
#7 22.12at java.base/java.security.AccessController.doPrivileged(Native 
Method)
#7 22.12at java.base/java.security.Security.(Security.java:77)
#7 22.12at 
java.base/sun.security.jca.ProviderList.(ProviderList.java:176)
#7 22.12at 
java.base/sun.security.jca.ProviderList$2.run(ProviderList.java:94)
#7 22.12at 
java.base/sun.security.jca.ProviderList$2.run(ProviderList.java:92)
#7 22.12at java.base/java.security.AccessController.doPrivileged(Native 
Method)
#7 22.12at 
java.base/sun.security.jca.ProviderList.fromSecurityProperties(ProviderList.java:91)
#7 22.12at 
java.base/sun.security.jca.Providers.(Providers.java:54)
#7 22.12at 
java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:156)
#7 22.12at 
java.base/java.security.cert.CertificateFactory.getInstance(CertificateFactory.java:193)
#7 22.12at 
org.debian.security.KeyStoreHandler.(KeyStoreHandler.java:50)
#7 22.12at 
org.debian.security.UpdateCertificates.(UpdateCertificates.java:65)
#7 22.12at 
org.debian.security.UpdateCertificates.main(UpdateCertificates.java:51)
#7 22.13 E: /etc/ca-certificates/update.d/jks-keystore exited with code 1.
#7 22.13 done.
#7 22.15 Errors were encountered while processing:
#7 22.15  ca-certificates-java
#7 22.15  openjdk-11-jre-headless:amd64
#7 22.17 E: Sub-process /usr/bin/dpkg returned an error code (1)

Bug#1055293: dub: Please upgrade to a new version

[Nilesh Patra]

Package: dub
Version: 1.27.0-4
Severity: important
X-Debbugs-Cc: m...@debian.org

Dear Maintainer,

dub seems to be at a really old version and it is just "limping" to stay
in testing at the moment and the version there was released 3 years
back, this is behind a bunch of new releases.

I noticed there is a new version committed to salsa but it does not
build and this seems unfixed upstream as well. I however did find a
(unmerged) PR that fixes it:

https://github.com/dlang/dub/pull/2623

IMHO dub should be updated to latest version once those rough edges are
sorted out.

Thanks,
Nilesh

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

Kernel: Linux 6.5.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_IN, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#756017: dependencies

[Diane Trout]

On Fri, 2023-11-03 at 15:54 +0100, Enrique García wrote:
> I would really like to see bokeh packaged for Debian.


I think getting bokeh pacakged would be great, I just lack time and
motivation to deal with the javascript packages.

Also I think there were times when bokeh was using an unpackaged build
system, but they switched to something simpler.

Diane

Bug#1055292: Debian bookworm with the latest backports kernel (6.5.3-1~bpo12+1) not shutting down

[Enrico Rivarola]

Package: src:linux
Version: 6.5.3-1~bpo12+1
Severity: normal
X-Debbugs-Cc: debian-backpo...@lists.debian.org

After upgrading the latest kernel from backports the system does not shutdown 
completely:
after starting shutdown (gui or terminal) the screen turns off but the power led (and other 
keyboard leds) stay on, and can be shutdown only pressing the power button for a few seconds in 
order to turn it off completely.


With the previous version (6.4.4-3~bpo12+1), and even with all those before it, including the 
stable versions, no problems of this kind were detected.

The journal log reports no errors.

Looking for similar errors I found many reports by searching "kernel 6.5 poweroff hang", and a 
possible kernel related bug:

https://bugzilla.kernel.org/show_bug.cgi?id=217995
from this report it seems that version 6.5.8 fixes the problem but I am not able to verify it 
myself.


Regards,
Enrico


-- Model information
sys_vendor: Dell Inc.
product_name: Dell System XPS L502X
chassis_vendor: Dell Inc.
chassis_version: 0.1
bios_vendor: Dell Inc.
bios_version: A12
board_vendor: Dell Inc.
board_name: 0NJT03
board_version: A00


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

Kernel: Linux 6.4.0-0.deb12.2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (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 linux-image-6.5.0-0.deb12.1-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.142
ii  kmod30+20221128-1
ii  linux-base  4.9

Versions of packages linux-image-6.5.0-0.deb12.1-amd64 recommends:
ii  apparmor 3.0.8-3
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-6.5.0-0.deb12.1-amd64 suggests:
ii  debian-kernel-handbook  1.0.21I am aware that
ii  grub-pc 2.06-13+deb12u1
ii  linux-doc-6.5   6.5.3-1~bpo12+1

Versions of packages linux-image-6.5.0-0.deb12.1-amd64 is related to:
ii  firmware-amd-graphics 20230210-5
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
ii  firmware-intel-sound  20230210-5
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
ii  firmware-iwlwifi  20230210-5
pn  firmware-libertas 
ii  firmware-linux-nonfree20230210-5
ii  firmware-misc-nonfree 20230210-5
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
ii  firmware-realtek  20230210-5
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

Bug#1055291: golang-github-cilium-ebpf: Breaks compilation on loong64

[Reinhard Tartler]

Source: golang-github-cilium-ebpf
Severity: normal

I noticed that podman doesn't build on loong64 with this being the relevant
part from the build log:

# github.com/cilium/ebpf/internal
src/github.com/cilium/ebpf/internal/vdso.go:64:28: undefined: NativeEndian

Looking at the upstream sources, I believe this commit should fix that:

https://github.com/cilium/ebpf/commit/00ec3bb28e0c3158e45080f929c51377499835c9

Currently, debian ships version 0.9.1, the patch above was merged for the v0.11
release.



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

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

Bug#1055290: libevent: Fix libc-dev build-dep

[Samuel Thibault]

Source: libevent
Version: 2.1.12-stable-9
Severity: important
Tags: patch

Hello,

Version 2.1.12-stable-9 introduced a libc6-dev build-dep, but the ABI
soname depends on the port, and the libc-dev package name as well. The
attached patch fixes this by adding the other alternatives.

Samuel

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

Kernel: Linux 6.5.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
--- debian/control.original 2023-11-03 16:02:07.0 +
+++ debian/control  2023-11-03 16:03:00.0 +
@@ -4,7 +4,7 @@
 Priority: optional
 Build-Depends: debhelper-compat (= 13),
libssl-dev,
-   libc6-dev (>= 2.38)
+   libc6-dev (>= 2.38) | libc6.1-dev (>= 2.38) | libc0.3-dev (>= 
2.38)
 Standards-Version: 4.6.2
 Vcs-Git: https://salsa.debian.org/debian/libevent.git -b master
 Vcs-Browser: https://salsa.debian.org/debian/libevent

Bug#823651: sudo apt install libpam-tmpdir breaks cowbuilder

[Patrick Schleizer]

On Debian bookworm:

sudo apt install libpam-tmpdir

is enough to break cowbuilder, which then calls pbuilder.


I: Installing the build-deps
 -> Attempting to satisfy build-dependencies
 -> Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: amd64
Maintainer: Debian Pbuilder Team 
Description: Dummy package to satisfy dependencies with aptitude - created by 
pbuilder
 This package was created automatically by pbuilder to satisfy the
 build-dependencies of the package being currently built.
Depends: debhelper (>= 13), debhelper-compat (= 13), devscripts, 
strip-nondeterminism, perl
dpkg-deb: building package 'pbuilder-satisfydepends-dummy' in 
'/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
dpkg-deb: error: failed to make temporary file (control member): No such file 
or directory
E: pbuilder-satisfydepends failed.

Bug#1053503: Enable support for Renesas RZ/V2L, RZ/G2UL, and RZ/V2M

[Emanuele Rocca]

Hi!

On 2023-10-05 10:05, John wrote:
> CONFIG_ARCH_R9A07G054=y
> CONFIG_ARCH_R9A07G043=y
> CONFIG_ARCH_R9A09G011=y

The changes have been merged into master some time ago already:
https://salsa.debian.org/kernel-team/linux/-/merge_requests/867

Salvatore: what is the best way to ensure this makes its way into the
next upload to sid? Should I open a new MR against sid, or can you just
cherry-pick commit 87656545c ?

  Emanuele

Bug#1055289: libgc: Fix hurd-amd64 build

[Samuel Thibault]

Source: libgc
Version: 1:8.2.4-1
Severity: important
Tags: patch

Hello,

The attached patch fixes the hurd-amd64 build, could you apply it?

Thanks,
Samuel

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

Kernel: Linux 6.5.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
--- debian/libgc1.symbols.original  2023-11-03 15:55:37.0 +
+++ debian/libgc1.symbols   2023-11-03 15:55:53.0 +
@@ -201,10 +201,10 @@
  GC_pre_incr@Base 1:7.2d
  GC_print_free_list@Base 1:7.2d
  GC_printf@Base 1:7.2d
- (arch=!hurd-i386 !kfreebsd-amd64 !kfreebsd-i386)GC_pthread_cancel@Base 1:7.2d
+ (arch=!hurd-any !kfreebsd-any)GC_pthread_cancel@Base 1:7.2d
  GC_pthread_create@Base 1:7.2d
  GC_pthread_detach@Base 1:7.2d
- (arch=!hurd-i386 !kfreebsd-amd64 !kfreebsd-i386)GC_pthread_exit@Base 1:7.2d
+ (arch=!hurd-any !kfreebsd-any)GC_pthread_exit@Base 1:7.2d
  GC_pthread_join@Base 1:7.2d
  GC_pthread_sigmask@Base 1:7.2d
  GC_ptr_store_and_dirty@Base 1:8.0

Bug#1055288: ITP: gnome-video-trimmer -- Simple GUI application for lossless cutting of video files

[Arnaud Ferraris]

Package: wnpp
Severity: wishlist
Owner: Arnaud Ferraris 
X-Debbugs-Cc: debian-de...@lists.debian.org, aferra...@debian.org, 
pkg-gnome-maintain...@lists.alioth.debian.org

* Package name: gnome-video-trimmer
  Version : 0.8.2
  Upstream Contact: Ivan Molodetskikh 
* URL : https://gitlab.gnome.org/YaLTeR/video-trimmer
* License : GPL
  Programming Lang: Rust
  Description : Simple GUI application for lossless cutting of video files

Video Trimmer is an easy-to-use graphical application for cutting video files.
It proceeds without re-encoding the video, avoiding any loss of quality in the
process.

This package being a GNOME Circle application, it will be maintained within the
GNOME team.

Bug#1055287: Please package newer vim upstream release

[David Kalnischkies]

Package: src:vim
Version: 2:9.0.2018-1
Control: affects -1 vim-youcompleteme

Hi,

v9.0.2018 is currently blocked from entering testing due to failing
vim-youcompleteme – who I am the maintainer of – autopkgtests. While
I can't really reproduce the failures interactively, I can in a local
autopkgtest run and while I currently don't have the serenity to start
bisecting this properly I can at least confirm that while v9.0.2018
fails, a testrun with a no change (beside merging upstream) v9.0.2087
finishes successfully.

I would therefore like to request a newer vim being released to
unstable for our mutual benefit.


I suppose your testing blockage might resolve itself in time as there
are other issues in the vim-youcompleteme ecospace I have to deal with,
which I might fail to get done before the removal clock ticks out, but
even if I would any fix would then be blocked by failing to work in
testing with the currently packaged vim… which I would like to avoid.

I am placing this bug hence as "normal", not as customary "wishlist",
while I am not raising it higher either as I haven't investigated why
and if that effects (not) everyone interactively/in automation.

(Sry, for opting here for the lazy shortcut skipping the break & fix
 bisects, to keep some time for the other things I should have a look at)


Thanks for your help & Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#1033176: linux: Future Android/Waydroid support

[Diederik de Haas]

On Thursday, 30 March 2023 00:27:41 CET Diederik de Haas wrote:
> The patch description which turned the module from a `bool` into a
> `tristate` explicitly mentioned security as a reason so that the module
> would ONLY be loaded when needed, instead of always for everyone ... for
> security reasons.

Kees Cook tooted about and GKH boosted the following link:
https://lore.kernel.org/lkml/20231101-rust-binder-v1-0-08ba9197f...@google.com/

Titled "Setting up Binder for the future" which is a patch set rewriting
the implementation of Binder with Rust.
The cover page ofc describes the patch set and also contains the following:

"We have left the binderfs filesystem component in C. Rewriting it in
Rust would be a large amount of work and requires a lot of bindings to
the file system interfaces. Binderfs has not historically had the same
challenges with security and complexity, so rewriting binderfs seems to
have lower value than the rest of Binder."


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

Bug#1055286: r-cran-spatstat.core: Fails autopkgtests on all archs

[Nilesh Patra]

Source: r-cran-spatstat.core
Version: 2.4-4-2
Severity: serious
Tags: trixie sid

Dear Maintainer,

Spatstat.core fails its autopkgtests with:

This is due to an API change in spatstat.random to which this package
did not adapt to.


https://github.com/spatstat/spatstat.random/commit/5e90d382ee6a4bbb6266b5b77d832f3dcc129b3b

It has also been removed from CRAN and archive since December 22.

https://cran.r-project.org/web/packages/spatstat.core/index.html

It may make sense to remove it altogether but it should be removed from
testing for sure.

Thanks,
Nilesh

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

Kernel: Linux 6.5.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_IN, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#756017: dependencies

[Enrique García]

I would really like to see bokeh packaged for Debian.

FWIW, I have run npm2deb on bokehjs to see which node packages are 
missing in Debian. Here is the output:


$ npm2deb depends -b -r bokehjs

Dependencies:
NPM   Debian
bokehjs (1.4.0)   None
├─ canvas2svg (git+https://github.com/bokeh/canvas2svg.git#v1.0.21)None
├─ es5-ext (^0.10.50) node-es5-ext 
(0.10.62+dfsg1+~1.1.0-2)

├─ es6-map (^0.1.5)   node-es6-map (0.1.5-3)
├─ es6-promise (4.2.6)    node-es6-promise 
(4.2.8-12)

├─ es6-set (^0.1.5)   node-es6-set (0.1.6-1)
├─ es6-weak-map (^2.0.2) node-es6-weak-map (2.0.3-3)
├─ flatbush (^3.1.1)  None
│  └─ flatqueue (^2.0.3)  None
├─ gloo2 (git+https://github.com/bokeh/gloo2.git#b41bd5d)None
│  └─ error ({'code': 'E404', 'summary': 'Unpublished on 
2021-04-28T09:35:17.607Z', 'detail': "\n 'gloo2' is not in this 
registry.\n\nNote that you can also install from a\ntarball, folder, 
http url, or git url."})None

├─ hammerjs (^2.0.4)  None
├─ nouislider (^10.0.0)   node-nouislider 
(15.7.1+ds-1)

├─ numbro (git+https://github.com/bokeh/numbro.git#e1b6c52)None
│  └─ bignumber.js (^8 || ^9) None
├─ pikaday 
(git+https://github.com/bokeh/pikaday.git#6b7258e)node-pikaday 
(1.8.2+~1.7.6-2)

├─ proj4 (<2.4)   proj4js (2.3.17+ds-1)
├─ slickgrid (git+https://github.com/bokeh/SlickGrid.git#8e993bf)None
│  └─ sortablejs (^1.15.0)    None
├─ sprintf-js (^1.1.2)    node-sprintf-js 
(1.1.2+ds1+~1.1.2-1)

├─ timezone (^1.0.22) None
├─ tslib (^1.10.0)    node-tslib (2.4.1-1)
└─ underscore.template (^0.1.7)   None

So basically 8 out 18 node dependencies are missing. From those ones 
slickgrid and hemmerjs seem like big ones, the rest maybe not so much, 
but of course nobody knows until it is tried out.


Also, trying to check which are the python dependencies, I tried to 
create a venv using the system packages and this is what I get:

$ python3 -m venv --system-site-packages my_env

$ . ./my_env/bin/activate

(my_env) $ pip install bokeh
Collecting bokeh
  Using cached bokeh-3.3.0-py3-none-any.whl (6.8 MB)
Requirement already satisfied: Jinja2>=2.9 in 
/usr/lib/python3/dist-packages (from bokeh) (3.1.2)
Requirement already satisfied: contourpy>=1 in 
/usr/lib/python3/dist-packages (from bokeh) (1.0.7)
Requirement already satisfied: numpy>=1.16 in 
/usr/lib/python3/dist-packages (from bokeh) (1.24.2)
Requirement already satisfied: packaging>=16.8 in 
/usr/lib/python3/dist-packages (from bokeh) (23.0)
Requirement already satisfied: pandas>=1.2 in 
/usr/lib/python3/dist-packages (from bokeh) (1.5.3)
Requirement already satisfied: pillow>=7.1.0 in 
/usr/lib/python3/dist-packages (from bokeh) (9.4.0)
Requirement already satisfied: PyYAML>=3.10 in 
/usr/lib/python3/dist-packages (from bokeh) (6.0)
Requirement already satisfied: tornado>=5.1 in 
/usr/lib/python3/dist-packages (from bokeh) (6.2)
Requirement already satisfied: xyzservices>=2021.09.1 in 
/usr/lib/python3/dist-packages (from bokeh) (2023.2.0)

Installing collected packages: bokeh
Successfully installed bokeh-3.3.0

Which seems to indicate that all the python dependencies are already in 
Debian. Maybe this is too naive and there are embedded dependencies in 
bokeh, but from a cursory look at the bokeh sources I could not find it.

Bug#1054290: zlib: CVE-2023-45853

[James Addison]

Source: zlib
Followup-For: Bug #1054290
X-Debbugs-Cc: david.dooling+deb...@docker.com, car...@debian.org, Debian 
Security Team 

On Fri, 03 Nov 2023 14:26:54 +, I wrote:
> A few packages referenced 'quazip' - a fork of minizip.  Of those, only
> 1 (one) appears to support 64-bit zip files, and it does look like it has
> the vulnerability too.
>
> For 3 (three) of the remaining packages, I'm uncertain whether copied code 
> that
> looks like older versions minizip is in fact vulnerable; those are the
> 'magics++' and 'widelands' packages, where 64-bit zip support appears
> incomplete or missing, and 'gdal', where the code appears to be part of a
> library called 'CPL' that may have shared some lineage with minizip.

Please note: both of those paragraphs I wrote mention 64-bit zipfile support,
because I thought that that could be a prerequisite for the vulnerability (an
integer overflow).  However: I'm not really sure whether that's true or not.

Bug#915583: debian sphinx styling: second attempt

[Sam Hartman]

> "Sean" == Sean Whitton  writes:

Sean> - it would be good to do some accessibility testing of some
Sean> kind, at least with screenreaders.  But maybe the fact that
Sean> you've based your theme on an existing, popular Sphinx theme
Sean> means this is covered?

I'm happy to test with Orca on Firefox on Debian.
Feel free to point me at a URL.

Bug#1055284: Acknowledgement (RFP: harpoon -- CLI tool for open source and threat intelligence)

[Antoine Beaupré]

Another thing I forgot, the author wrote a good guide on their blog in:

https://randhome.io/blog/2018/02/23/harpoon-an-osint-/-threat-intelligence-tool/

-- 
The steel horse fills a gap in modern life, it is an answer not only to
its needs, but also to its aspirations.  It's quite certainly here to
stay.
 - Le Vélocipède Illustré, 1869

Bug#1055285: libseccomp misbehave on loong64

[Miao Wang]

Package: libseccomp2
Version: 2.5.4-1+loong64
Severity: normal
Tags: patch

libseccomp2 in debian ports lonng64 cannot work properly because it is using a
wrong mapping between syscall numbers and names, which can be reproduced by
first installing package seccomp and then execute:

```
scmp_sys_resolver accept
```

The syscall number in the output is not correct, which should be 202 on loong64
architecture. 

The root cause of this bug lies in the patch
`add-loongarch64-support-from-libseccomp-upstream.patch` applied in the version
2.5.4-1+loong64: 

```
--- libseccomp-2.5.4.orig/src/syscalls.csv
+++ libseccomp-2.5.4/src/syscalls.csv
@@ -1,4 +1,4 @@
-#syscall (v5.17.0 
2022-04-05),x86,x86_64,x32,arm,aarch64,mips,mips64,mips64n32,parisc,parisc64,ppc,ppc64,riscv64,s390,s390x
+#syscall (v5.17.0 
2022-04-05),x86,x86_64,x32,arm,aarch64,loongarch64,mips,mips64,mips64n32,parisc,parisc64,ppc,ppc64,riscv64,s390,s390x
accept,PNR,43,43,285,202,168,42,42,35,35,330,330,202,PNR,PNR
accept4,364,288,288,366,242,334,293,297,320,320,344,344,242,364,364
access,33,21,21,33,PNR,33,20,20,33,33,33,33,PNR,33,33
```

which only changes the header of the syscall table but fails to include syscall
numbers for loong64 architecture. The result is that on loong64 architecture,
the syscall number mapping for mips is actually in effect. All the mappings for
architectures listed after mips are also wrong. Especially for s390x, when
trying to convert between syscall names and numbers, memory overflow will
happen and the output will be totally garbage.

This issue prevents container manage applications such as Podman from working
correctly on loong64 architecture.

To fix this issue, correct syscall mapping should be introduced. The attached
patch (on top of the original patch) should work. It also includes a fix for
the tests so that the package can be built without nocheck.

Cheers,

Miao Wang

Index: libseccomp-2.5.4/include/seccomp-syscalls.h
===
--- libseccomp-2.5.4.orig/include/seccomp-syscalls.h
+++ libseccomp-2.5.4/include/seccomp-syscalls.h
@@ -276,6 +276,7 @@
 #define __PNR_renameat -10242
 #define __PNR_riscv_flush_icache   -10243
 #define __PNR_memfd_secret -10244
+#define __PNR_fstat-10245
 
 /*
  * libseccomp syscall definitions
Index: libseccomp-2.5.4/src/syscalls.csv
===
--- libseccomp-2.5.4.orig/src/syscalls.csv
+++ libseccomp-2.5.4/src/syscalls.csv
@@ -1,482 +1,482 @@
 #syscall (v5.17.0 
2022-04-05),x86,x86_64,x32,arm,aarch64,loongarch64,mips,mips64,mips64n32,parisc,parisc64,ppc,ppc64,riscv64,s390,s390x
-accept,PNR,43,43,285,202,168,42,42,35,35,330,330,202,PNR,PNR
-accept4,364,288,288,366,242,334,293,297,320,320,344,344,242,364,364
-access,33,21,21,33,PNR,33,20,20,33,33,33,33,PNR,33,33
-acct,51,163,163,51,89,51,158,158,51,51,51,51,89,51,51
-add_key,286,248,248,309,217,280,239,243,264,264,269,269,217,278,278
-adjtimex,124,159,159,124,171,124,154,154,124,124,124,124,171,124,124
-afs_syscall,137,183,183,PNR,PNR,137,176,176,PNR,PNR,137,137,PNR,137,137
-alarm,27,37,37,PNR,PNR,27,37,37,27,27,27,27,PNR,27,27
-arch_prctl,384,158,158,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR
-arm_fadvise64_64,PNR,PNR,PNR,270,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR
-arm_sync_file_range,PNR,PNR,PNR,341,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR
-bdflush,134,PNR,PNR,134,PNR,134,PNR,PNR,134,134,134,134,PNR,134,134
-bind,361,49,49,282,200,169,48,48,22,22,327,327,200,361,361
-bpf,357,321,321,386,280,355,315,319,341,341,361,361,280,351,351
-break,17,PNR,PNR,PNR,PNR,17,PNR,PNR,PNR,PNR,17,17,PNR,PNR,PNR
-breakpoint,PNR,PNR,PNR,983041,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR
-brk,45,12,12,45,214,45,12,12,45,45,45,45,214,45,45
-cachectl,PNR,PNR,PNR,PNR,PNR,148,198,198,PNR,PNR,PNR,PNR,PNR,PNR,PNR
-cacheflush,PNR,PNR,PNR,983042,PNR,147,197,197,PNR,PNR,PNR,PNR,PNR,PNR,PNR
-capget,184,125,125,184,90,204,123,123,106,106,183,183,90,184,184
-capset,185,126,126,185,91,205,124,124,107,107,184,184,91,185,185
-chdir,12,80,80,12,49,12,78,78,12,12,12,12,49,12,12
-chmod,15,90,90,15,PNR,15,88,88,15,15,15,15,PNR,15,15
-chown,182,92,92,182,PNR,202,90,90,180,180,181,181,PNR,182,212
-chown32,212,PNR,PNR,212,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,PNR,212,PNR
-chroot,61,161,161,61,51,61,156,156,61,61,61,61,51,61,61
-clock_adjtime,343,305,305,372,266,341,300,305,324,324,347,347,266,337,337
-clock_adjtime64,405,PNR,PNR,405,PNR,405,PNR,405,405,PNR,405,PNR,PNR,405,PNR
-clock_getres,266,229,229,264,114,264,223,227,257,257,247,247,114,261,261
-clock_getres_time64,406,PNR,PNR,406,PNR,406,PNR,406,406,PNR,406,PNR,PNR,406,PNR
-clock_gettime,265,228,228,263,113,263,222,226,256,256,246,246,113,260,260
-clock_gettime64,403,PNR,PNR,403,PNR,403,PNR,403,403,PNR,403,PNR,PNR,403,PNR
-clock_nanosleep,267,230,230,265,115,265,224,228,258,258,248,248,115,262,262

Bug#1055284: Acknowledgement (RFP: harpoon -- CLI tool for open source and threat intelligence)

[Antoine Beaupré]

Control: forwarded -1 https://github.com/Te-k/harpoon/issues/195

Oh, and another thing I forgot: the harpoon wiki names a few
alternatives to this.

https://github.com/Te-k/harpoon/wiki#other-tools

Of those, the following might be interesting:

https://github.com/kpcyrd/sn0int
https://github.com/aancw/Belati

Out of band, someone also mentioned nmap as an alternative already
packaged in Debian, but I figured nmap was a much more active tool than
what I am looking for here.

Finally, there's also this tool I found that does a *lot* of what I
want:

https://github.com/nitefood/asn

... but it's kind of a messy shell script, which is why I am hoping to
package harpoon instead.

Bug#1054290: zlib: CVE-2023-45853

[James Addison]

Source: zlib
Followup-For: Bug #1054290
X-Debbugs-Cc: david.dooling+deb...@docker.com, car...@debian.org, Debian 
Security Team 

On Tue, 31 Oct 2023 13:13:00 -0500, David wrote:
> Thanks for that analysis, James.
...
> nodejs-18.13.0+dfsg1:
> The Node.js source code includes a copy of the zlib source code. This
> copy was patched over a month ago.

Thanks David for the follow-up!  I had indeed missed that nodejs is already
patched; great -- and that also demonstrates that I hadn't checked whether
each callsite I found was using a locally-vendored copy of the minizip code
(that's the situation you mention where packages clone zlib into their own
code).

As context: Debian's preferred approach[1] is that each package de-duplicates
references to library code that is already packaged in Debian  -- even if the
originating codebase simply includes a copy of it -- because when a security
issue like this appears, it's easier if there's only a single place to patch.

> After checking two common packages and seeing the same, someone
> nonstandard pattern, I downloaded and compiled zlib myself. By
> default, it does not appear that any of the minizip functions are
> included in any header file or library installed as part of the normal
> zlib './configure && make && make install'. So perhaps all these
> usages of these functions are associated with downstream software
> closing zlib source into their code? If that is the case, what does
> that mean for this CVE and actually creating a coherent response
> across all these packages?

About the default compile options for zlib: that's correct: minizip is
a non-core part of the zlib codebase, referred to as a 'contrib'[2], often
implying a lower maintenance guarantee.  Debian does provide a package called
'minizip' that builds binaries from the relevant code, though.

About what to do regarding the other packages:

After removing nodejs, and checking each remaining package's source, I find
that only 11 (eleven) of the packages in fact contain a full copy of minizip
with the vulnerable section of code.

A few packages referenced 'quazip' - a fork of minizip.  Of those, only
1 (one) appears to support 64-bit zip files, and it does look like it has
the vulnerability too.

For 3 (three) of the remaining packages, I'm uncertain whether copied code that
looks like older versions minizip is in fact vulnerable; those are the
'magics++' and 'widelands' packages, where 64-bit zip support appears
incomplete or missing, and 'gdal', where the code appears to be part of a
library called 'CPL' that may have shared some lineage with minizip.

In the latter case, I'll ask the CPL maintainers whether they think it's
affected on their mailing list[3].

The twelve (11 minizip + 1 quazip) vendored code locations are:

  
https://sources.debian.org/src/gmsh/4.8.4+ds2-3/contrib/zipper/zip.c/?hl=1055#L1085
  
https://sources.debian.org/src/godot/3.5.2-stable-2/thirdparty/minizip/zip.c/?hl=1292#L1088
  
https://sources.debian.org/src/httrack/3.49.4-1/src/minizip/zip.c/?hl=1311#L1086
  
https://sources.debian.org/src/libxlsxwriter/1.1.5-1/third_party/minizip/zip.c/?hl=1057#L1088
  
https://sources.debian.org/src/mariadb/1:10.11.5-3/storage/connect/zip.c/?hl=1337#L1086
  
https://sources.debian.org/src/mupen64plus-core/2.5.9+341+gf82b37bf-1/subprojects/minizip/zip.c/?hl=1265#L1086
  
https://sources.debian.org/src/orthanc/1.12.1+dfsg-4/OrthancFramework/Resources/ThirdParty/minizip/zip.c/?hl=1337#L1086
  
https://sources.debian.org/src/qt6-webengine/6.4.2-final+dfsg-12/src/3rdparty/chromium/third_party/zlib/contrib/minizip/zip.c/?hl=1273#L1086
  
https://sources.debian.org/src/qtwebengine-opensource-src/5.15.15+dfsg-2/src/3rdparty/chromium/third_party/zlib/contrib/minizip/zip.c/?hl=1288#L1086
  
https://sources.debian.org/src/rbdoom3bfg/1.4.0+dfsg-2/neo/libs/zlib/minizip/zip.cpp/?hl=1307#L1112
  
https://sources.debian.org/src/swi-prolog/9.0.4+dfsg-2/src/minizip/zip.c/?hl=1065#L1096
  https://sources.debian.org/src/tea/62.0.2-1/zip.c/?hl=1345#L1113


I'd like someone else to confirm with me whether this is a good idea or not,
but my suggestion would be that we file a bug with each of the Debian source
packages (src:gmsh for example), linking to the affected line and referencing
this bug and the CVE to explain the problem.

Then each package's maintainer could check whether they think their package is
genuinely affected, and decide whether to patch the problem within Debian only,
and/or to forward the fix to the code distributors (aka upstream), or to do
nothing (which is a valid choice, especially if the code can't be reached from
their package even if it's theoretically built into it).

It's possible I'm overexplaining some of that, so my apologies if so - just
trying to be clear.


[1] - 
https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies

[2] - https://github.com/madler/zlib/issues/868#issuecomment-1783525536

[3] - https://lists.osgeo.org/mailman/listinfo/gdal-dev

Bug#1042859: [Pkg-rust-maintainers] Bug#1042859: cargo: Please upgrade to at least 0.67.0

[Eduard Bloch]

Hallo,
* Fabian Grünbichler [Fri, Nov 03 2023, 01:57:08PM]:
> > Eduard Bloch  hat am 03.11.2023 13:46 CET geschrieben:
> >
> >
> > Hallo,
> > * Fabian Grünbichler [Fri, Nov 03 2023, 12:32:50PM]:
> >
> > > > the version of Cargo seriously needs an update. Because the word is
> > > > moving and the old version performs increasingly bad.
> > >
> > > the upgrade (to 0.70.1, since later versions require a lot of NEW 
> > > processing first) is being prepared, but it takes a long time because it 
> > > is very involved.
> > >
> > > https://salsa.debian.org/rust-team/debcargo-conf/-/issues/48
> > > https://salsa.debian.org/rust-team/cargo/-/merge_requests/21
> > >
> > > also related, and hopefully improving this in the future:
> > >
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054658
> > > https://salsa.debian.org/rust-team/rust/-/merge_requests/27
> >
> > Okay, I get the idea. That said, I find it quite strange that you want
> > to include a Python dependency in order to run a central Rust tool.
> >
> > Would you like me to rewrite the proposed cargo wrapper script into a
> > native Rust app? That's a serious offer, I have IMHO sufficient Python
> > and Rust experience, recently working on something partly similar
> > (https://gitlab.com/setecastronomy/wec ).
>
>
> I am not sure what you are referring to, but the fact that some 
> helper/wrapper scripts are written in python is in no way related to what is 
> making updates cumbersome at the moment.

I was refering to the last link from the post above:

https://salsa.debian.org/rust-team/rust/-/merge_requests/27/diffs#98066737513db2808acb090ffe631b89bd788499

> and we most definitely don't want to rewrite the cargo wrapper in rust, that 
> would serve no purpose at all.

Depends on the whole picture. From that statement I understand that
reducing dependencies on further interpreters (like Python) is not a
goal here.

> > (Not sure about bootstrapping, though. Is rustc available while our
> > source package is being built?)
>
> of course rustc is required to build both rustc and cargo, since both are 
> written in rust. note that rustc itself also has a build-dependency on python 
> anyway, since it's (internal) bootstrapping/build tool is written in python 
> (and rust).

Okay. But I did not have only build-deps of the Debian source package
in mind, more the dependencies of the binary package, i.e. what the
regular user (application developer) gets. Why should cargo have a
dependency on Python? Looks quite strange to me.

MfG,
Eduard.

--
Das Wichtigste bleibt jedoch das Gleichzeitige, weil es sich in
uns am reinsten abspiegelt, wir uns in ihm.
-- Goethe, Maximen und Reflexionen, Nr. 8

Bug#1055284: RFP: harpoon -- CLI tool for open source and threat intelligence

[Antoine Beaupre]

Package: wnpp
Severity: wishlist

* Package name: harpoon
  Version : no releases published 
https://github.com/Te-k/harpoon/issues/194
  Upstream Contact: https://github.com/Te-k
* URL : https://github.com/Te-k/harpoon
* License : GPL-3
  Programming Lang: Python
  Description : CLI tool for open source and threat intelligence

harpoon doesn't have a long description upstream, but it's a recon
tool with various backends. i personnally want to use it to answer
questions like "who is this set of IPs doing nasty things to my
server?" looking for answers like reverse DNS, geolocation, ASN,
shodan information and so on.

harpoon can do a lot more though, by tapping into various data sources
like virustotal, haveibeenpwned, and many more.

i do not believe there is an equivalent in Debian. maybe metasploit
could be crafted to do *some* of this, but there's so many modules in
metasploit nowadays that it's hard to tell. there *is* a shodan
module, for example and there's a tool to do reverse DNS lookups, but
no ASN lookup I could find.

harpoon is designed with recon in mind specifically. there's even a
separate toolset called harpoontools that give commandline tools to a
basic set of tools:

https://github.com/Te-k/harpoontools

Just that basically answers most of my needs!

Would be maintained under the python team, I suppose.

Code is not the cleanest (and due for a refactor) but has unit tests
and written by a friend of a friend.

Bug#1055283: sasl2-bin: saslauthd in postfix chroot mode exits after several PAM authentication failures

[John Lines]

Package: sasl2-bin
Version: 2.1.28+dfsg-10
Severity: normal
X-Debbugs-Cc: john+report...@paladyn.org

Dear Maintainer,

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

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

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

Running saslauthd for postfix authentication, with postfix in a chroot,
using PAM as an authentication methods, causes saslauthd to exit, with
a message

Nov 03 13:00:59 agc saslauthd[808674]: : master exited: 617183

This appears to be a clean exit, rather than a crash, but was preceded
by several hundred messages of 

Nov 03 13:00:44 agc saslauthd[617185]: pam_unix(smtp:auth): check pass; user 
unknown
Nov 03 13:00:44 agc saslauthd[617185]: pam_unix(smtp:auth): authentication 
failure; logname= uid=0 euid=0 tty= ruser= rhost=
Nov 03 13:00:46 agc saslauthd[617185]: DEBUG: auth_pam: pam_authenticate 
failed: Authentication failure
Nov 03 13:00:46 agc saslauthd[617185]: : auth failure: 
[user=nayan] [service=smtp] [realm=org.uk] [mech=pam] [reason=PAM auth error]
Nov 03 13:00:48 agc saslauthd[617188]: pam_unix(smtp:auth): check pass; user 
unknown
Nov 03 13:00:48 agc saslauthd[617188]: pam_unix(smtp:auth): authentication 
failure; logname= uid=0 euid=0 tty= ruser= rhost=
Nov 03 13:00:50 agc saslauthd[617188]: DEBUG: auth_pam: pam_authenticate 
failed: Authentication failure
Nov 03 13:00:50 agc saslauthd[617188]: : auth failure: 
[user=copier] [service=smtp] [realm=ambridge-garden-club.org.uk] [mech=pam] 
[reason=PAM auth error]
Nov 03 13:00:52 agc saslauthd[617187]: pam_unix(smtp:auth): check pass; user 
unknown
Nov 03 13:00:52 agc saslauthd[617187]: pam_unix(smtp:auth): authentication 
failure; logname= uid=0 euid=0 tty= ruser= rhost=
Nov 03 13:00:55 agc saslauthd[617187]: DEBUG: auth_pam: pam_authenticate 
failed: Authentication failure
Nov 03 13:00:55 agc saslauthd[617187]: : auth failure: 
[user=beans] [service=smtp] [realm=org.uk] [mech=pam] [reason=PAM auth error]

A more imformative exit reason would help investigate the problem, also
the daemon should not exit simply because it has had a number of PAM
authentication failures.

Restarting the daemon restores normal operation, thus is a work-around, 
but not ideal.

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

Kernel: Linux 6.1.0-13-amd64 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 sasl2-bin depends on:
ii  db-util5.3.2
ii  debconf [debconf-2.0]  1.5.82
ii  init-system-helpers1.65.2
ii  libc6  2.36-9+deb12u2
ii  libcrypt1  1:4.4.33-2
ii  libdb5.3   5.3.28+dfsg2-1
ii  libkrb5-3  1.20.1-2+deb12u1
ii  libldap-2.5-0  2.5.13+dfsg-5
ii  libpam0g   1.5.2-6+deb12u1
ii  libsasl2-2 2.1.28+dfsg-10
ii  libssl33.0.11-1~deb12u1
ii  lsb-base   11.6
ii  perl   5.36.0-7
ii  sysvinit-utils [lsb-base]  3.06-4

sasl2-bin recommends no packages.

sasl2-bin suggests no packages.

-- debconf information:
  cyrus-sasl2/backup-sasldb2: /var/backups/sasldb2.bak
  cyrus-sasl2/upgrade-sasldb2-backup-failed:
  cyrus-sasl2/purge-sasldb2: false
  cyrus-sasl2/upgrade-sasldb2-failed:

Bug#1037245: marked as pending in debci

[Christian Kastner]

Hi,

On 2023-07-28 21:39, Antonio Terceiro wrote:
> Bug #1037245 in debci reported by you has been fixed in the
> Git repository and is awaiting an upload. You can see the commit
> message below and you can check the diff of the fix at:
> 
> https://salsa.debian.org/ci-team/debci/-/commit/94dfe8300c6405934b62c3b5eb3b6beb40698478
> 
> 
> Allow passing arguments to autopkgtest backends
> 
> A configuration may specify new variables
> debci_autopkgtest_args_$backend that are to be passed to the respective
> backend when running an autopkgtest. For instance, this allows changing
> the --ram-size for a qemu backend.

I believe that this is not quite complete, so I filed an MR [1] to add
the missing parts.

Best,
Christian

[1] https://salsa.debian.org/ci-team/debci/-/merge_requests/259

Bug#1055117: FTBFS: crash 8.0.3-1 is missing gdb-10.2.tar.gz

[Mauricio Oliveira]

On Fri, Nov 3, 2023 at 10:37 AM Troy Heber  wrote:
>
> > I realize this is not exactly what you're looking for, which is
> > replacing the _orig_ tarball,
>
> The problem is now resolved with the 8.0.3+ds1-3 upload.

Cool, thank you!

-- 
Mauricio Faria de Oliveira

Bug#1054261: tint2 coredumps on startup

[Bastian Germann]

I am uploading a NMU to fix this, which also includes the latest git commits.
The change that I am sponsoring is also available in git.

Bug#1053281: linux-image-6.5.0-1-amd64: Debian does not boot at cold start on kernel 6.5.0-1-amd64 on Intel NUC 12

[Diederik de Haas]

On Friday, 3 November 2023 13:49:01 CET Diederik de Haas wrote:
> My findings are:
> > 1. If I use Thunderbolt 4 output (usb-c at the back) everything works
> > fine.
> > 2. If I use one of DP or HDMI ports the issue occurs.
> > 
> > Manual for this Intel NUC12 states that both DP and HDMI outputs are
> > handled by Intel ARC A770M GPU, while Thunderbolt4 output is handled by
> > CPU-integrated Intel Iris Xe.

As this issue only happens on cold boot, have you checked whether there's an 
updated BIOS for your system?

And does it really not boot or are you 'only' getting no display output?
If the latter, can you ssh into your NUC and share `dmesg` output? Hopefully 
that'll give a clue as to why the DP/HDMI outputs aren't working properly.

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

Bug#1038505: RM: mlv

[Alexandre Detiste]

Hi Simon,

I think this a vanity package that should be removed right away
without wasting too much time on it.

Greetings

Bug#1055282: acpid: New upstream release (version 2.0.34)

[Diederik de Haas]

Source: acpid
Version: 1:2.0.33-2
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Upstream has released a new version (a while ago): 2.0.34 and it would
be great if that was available in Debian.

There's one additional upstream commit "Replace stat64 with stat" [1]
that would probably be useful to 'backport' which will be part of
2.0.35 when that's released.

There are also a number of MRs open on Salsa, which will make the CI
succeed, and https://bugs.debian.org/1052628 which contains a patch
which seems useful/needed for usr-merge 'stuff'.

Cheers,
  Diederik

[1] https://sourceforge.net/p/acpid2/code/merge-requests/5/

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

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

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZUTylgAKCRDXblvOeH7b
bv9iAQC9gerKk/ghO0MPbaDOkAzX0Ou740z7xqLeYTBsAlNg4gEAoncG/80Q4HfH
nQY2J3aZlrWW8sjlQXBeICXQHSna4Ao=
=CExJ
-END PGP SIGNATURE-

Bug#1055281: ITP: gosa-plugins-rolemanagement -- Role Management plugin for GOsa²

[Mike Gabriel]

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

* Package name: gosa-plugins-rolemanagement
  Version : 2.8~gitsnapshot
  Upstream Contact: GONICUS GmbH
* URL : https://github.com/gosa-project/gosa-plugins-rolemanagement
* License : GPL-2+
  Programming Lang: PHP
  Description : Role Management plugin for GOsa²

 Role Management plugin for GOsa²
 .
 This package will be maintained under the umbrella of the Debian Edu
 Packaging Team.

Bug#1055280: libqt5sql5-odbc: Patch CVE 2023 24607.diff breaks Unicode support in libqt5sql5-odbc.

[Viktor Mykrä]

Package: libqt5sql5-odbc
Version: 5.15.8+dfsg-11
Severity: important
X-Debbugs-Cc: viktor.my...@insta.fi

Dear Maintainer,

Changes introduced in patch CVE-2023-24607.diff break Unicode handling.
I have tested this Microsoft ODBC driver for SQL Server 17 and 18,
using a database from the Docker image 
'mcr.microsoft.com/mssql/server:2019-latest'.
The easiest way to reproduce the issue is by calling QSqlDatabase::tables(),
which returns an empty list. Some other database actions work,
but the ODBC log is filled with HY009 (Invalid use of null pointer) error 
messages.
The same issue was also present in the package libqt6sql6-odbc (version 
6.4.2+dfsg-10),
which includes the same patch. Version 5.15.2+dfsg-9 on Bullseye works fine.
The Qt GitHub repository 'qtbase' seems to include multiple Unicode-related 
commits
that seem to address this issue.

I suggest including such fixes as additional patches in the package. 

Additionally, it seems that the same CVE vulnerability is still present in
Buster and Bullseye packages.

Testing was done using Docker images dabian:bullseye-slim and 
debian:bookworm-slim.

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

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

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


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

Kernel: Linux 5.15.90.1-microsoft-standard-WSL2 (SMP w/20 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages libqt5sql5-odbc depends on:
ii  libc6 2.36-9+deb12u3
ii  libodbc2  2.3.11-2+deb12u1
ii  libqt5core5a [qtbase-abi-5-15-8]  5.15.8+dfsg-11
ii  libqt5sql55.15.8+dfsg-11
ii  libstdc++612.2.0-14

libqt5sql5-odbc recommends no packages.

libqt5sql5-odbc suggests no packages.

-- no debconf information

Bug#1053281: linux-image-6.5.0-1-amd64: Debian does not boot at cold start on kernel 6.5.0-1-amd64 on Intel NUC 12

[Diederik de Haas]

Control: reopen -1
Control: notfixed -1 6.5.8-1
Control: retitle -1 Cold boot failure on Intel NUC 12 with Intel ARC GPU output 
(DP or HDMI), but not with CPU-integrated Intel Iris Xe (TB4)

On Friday, 3 November 2023 10:04:03 CET kurom...@stodwa.org wrote:
> I found out, issue is not fixed - it's only I switched video output at
> same time when kernel was updated.
> My findings are:
> 1. If I use Thunderbolt 4 output (usb-c at the back) everything works
> fine.
> 2. If I use one of DP or HDMI ports the issue occurs.
> 
> Manual for this Intel NUC12 states that both DP and HDMI outputs are
> handled by Intel ARC A770M GPU, while Thunderbolt4 output is handled by
> CPU-integrated Intel Iris Xe.

Bummer, reopened and retitled accordingly

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