Bug#1055750: Bug#1055228: plplot: FTBFS on armhf (test segfault)

[Rafael Laboissière]

Control: forwarded -1 https://sourceforge.net/p/plplot/bugs/206/

* Rafael Laboissière  [2023-11-16 07:51]:

My guess is that the bug is in PLplot and not in gfortran, but this is 
just a guess. I will eventually inform the PLplot upstream authors 
about the issue.


Done !

R.

Bug#1056031: rust-rstest-test: autopkgtest failure

[Adrian Bunk]

Source: rust-rstest-test
Version: 0.11.0-1
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-rstest-test/39198638/log.gz

...
84s  more_tests::case_2_contains stdout 
 84s Stderr: debian cargo wrapper: options, profiles, parallel: ['parallel=64'] 
[] ['-j64']
 84s debian cargo wrapper: rust_type, gnu_type: x86_64-unknown-linux-gnu, 
x86_64-linux-gnu
 84s debian cargo wrapper: running subprocess (['env', 'RUST_BACKTRACE=1', 
'/usr/bin/cargo', '+stable', '-Zavoid-dev-deps', 'test', '--verbose', 
'--verbose', '-j64', '--target', 'x86_64-unknown-linux-gnu'],) {}
 84s error: no such subcommand: `+stable`
 84s 
 84sCargo does not handle `+toolchain` directives.
 84sDid you mean to invoke `cargo` through `rustup` instead?
 84s 
 84s thread 'more_tests::case_2_contains' panicked at 'Empty stdout!', 
/usr/share/cargo/registry/rstest-test-0.11.0/src/utils.rs:308:13
 84s stack backtrace:
 84s0: std::panicking::begin_panic
 84s  at /usr/src/rustc-1.70.0/library/std/src/panicking.rs:610:12
 84s1: rstest_test::utils::TestResults::assert
 84s  at 
/usr/share/cargo/registry/rstest-test-0.11.0/src/utils.rs:308:13
 84s2: framework::more_tests
 84s  at 
/usr/share/cargo/registry/rstest-test-0.11.0/tests/framework.rs:87:5
 84s3: framework::more_tests::case_2_contains
 84s  at 
/usr/share/cargo/registry/rstest-test-0.11.0/tests/framework.rs:58:1
 84s4: framework::more_tests::case_2_contains::{{closure}}
 84s  at 
/usr/share/cargo/registry/rstest-test-0.11.0/tests/framework.rs:58:1
 84s5: core::ops::function::FnOnce::call_once
 84s  at 
/usr/src/rustc-1.70.0/library/core/src/ops/function.rs:250:5
 84s6: core::ops::function::FnOnce::call_once
 84s  at 
/usr/src/rustc-1.70.0/library/core/src/ops/function.rs:250:5
 84s note: Some details are omitted, run with `RUST_BACKTRACE=full` for a 
verbose backtrace.
 84s 
 84s 
 84s failures:
 84s add_local_dependency
 84s more_tests::case_1_default_conf
 84s more_tests::case_2_contains
 84s nocapture_in_tests
 84s one_fail::case_1_default_conf
 84s one_fail::case_2_contains
 84s one_success::case_1_default_conf
 84s one_success::case_2_contains
 84s should_check_just_contains_conf
 84s should_check_just_contains_on_some_test
 84s should_check_some_tests_as_contains
 84s should_detect_wrong_contains
 84s tests_with_should_panic::case_1_default_conf
 84s tests_with_should_panic::case_2_contains
 84s 
 84s test result: FAILED. 1 passed; 14 failed; 0 ignored; 0 measured; 0 
filtered out; finished in 0.79s
 84s 
 84s error: test failed, to rerun pass `--test framework`
 85s autopkgtest [21:27:08]: test librust-rstest-test-dev:: 
---]
 85s autopkgtest [21:27:08]: test librust-rstest-test-dev::  - - - - - - - - - 
- results - - - - - - - - - -
 85s librust-rstest-test-dev: FAIL non-zero exit status 101
 85s autopkgtest [21:27:08]:  summary
 85s rust-rstest-test:@   FAIL non-zero exit status 101
 85s librust-rstest-test-dev:default FAIL non-zero exit status 101
 85s librust-rstest-test-dev: FAIL non-zero exit status 101

Bug#1056030: rust-color-thief: autopkgtest failure on !x86

[Adrian Bunk]

Source: rust-color-thief
Version: 0.2.2-1
Severity: serious

https://tracker.debian.org/pkg/rust-color-thief

Issues preventing migration:
∙ ∙ autopkgtest for rust-color-thief/0.2.2-1: amd64: Pass, arm64: Regression ♻ 
, armel: Regression ♻ , armhf: Regression ♻ , i386: Pass, ppc64el: Regression ♻ 
, s390x: Regression ♻


...
109s running 1 test
109s test image1 ... FAILED
109s 
109s failures:
109s 
109s  image1 stdout 
109s thread 'image1' panicked at 'assertion failed: `(left == right)`
109s   left: `RGB { r: 43, g: 125, b: 149 }`,
109s  right: `RGB { r: 42, g: 125, b: 149 }`', tests/test.rs:26:5
109s stack backtrace:
109s0: rust_begin_unwind
109s  at /usr/src/rustc-1.70.0/library/std/src/panicking.rs:578:5
109s1: core::panicking::panic_fmt
109s  at /usr/src/rustc-1.70.0/library/core/src/panicking.rs:67:14
109s2: core::panicking::assert_failed_inner
109s3: core::panicking::assert_failed
109s  at /usr/src/rustc-1.70.0/library/core/src/panicking.rs:228:5
109s4: test::image1
109s  at ./tests/test.rs:26:5
109s5: test::image1::{{closure}}
109s  at ./tests/test.rs:17:13
109s6: core::ops::function::FnOnce::call_once
109s  at 
/usr/src/rustc-1.70.0/library/core/src/ops/function.rs:250:5
109s7: core::ops::function::FnOnce::call_once
109s  at 
/usr/src/rustc-1.70.0/library/core/src/ops/function.rs:250:5
109s note: Some details are omitted, run with `RUST_BACKTRACE=full` for a 
verbose backtrace.
109s 
109s 
109s failures:
109s image1
109s 
109s test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered 
out; finished in 0.27s
109s 
109s error: test failed, to rerun pass `--test test`
109s autopkgtest [03:27:39]: test librust-color-thief-dev:: 
---]
110s librust-color-thief-dev: FAIL non-zero exit status 101
110s autopkgtest [03:27:40]: test librust-color-thief-dev::  - - - - - - - - - 
- results - - - - - - - - - -
110s autopkgtest [03:27:40]:  summary
110s rust-color-thief:@   FAIL non-zero exit status 101
110s librust-color-thief-dev:default FAIL non-zero exit status 101
110s librust-color-thief-dev: FAIL non-zero exit status 101

Bug#1056028: rust-ntp-udp: autopkgtest failure

[Adrian Bunk]

Source: rust-ntp-udp
Version: 1.0.0-1
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-ntp-udp/38887148/log.gz

...
 75s error[E0433]: failed to resolve: could not find `test` in `tokio`
 75s--> src/socket.rs:394:14
 75s |
 75s 394 | #[tokio::test]
 75s |   could not find `test` in `tokio`
 75s 
 75s error[E0433]: failed to resolve: could not find `test` in `tokio`
 75s--> src/socket.rs:423:14
 75s |
 75s 423 | #[tokio::test]
 75s |   could not find `test` in `tokio`
 75s 
 75s error[E0433]: failed to resolve: could not find `test` in `tokio`
 75s--> src/socket.rs:452:14
 75s |
 75s 452 | #[tokio::test]
 75s |   could not find `test` in `tokio`
 75s 
 75s error[E0433]: failed to resolve: could not find `test` in `tokio`
 75s--> src/socket.rs:478:14
 75s |
 75s 478 | #[tokio::test]
 75s |   could not find `test` in `tokio`
 75s 
 75s error[E0433]: failed to resolve: could not find `test` in `tokio`
 75s--> src/socket.rs:550:14
 75s |
 75s 550 | #[tokio::test]
 75s |   could not find `test` in `tokio`
 75s 
 75s error[E0433]: failed to resolve: could not find `test` in `tokio`
 75s--> src/socket.rs:556:14
 75s |
 75s 556 | #[tokio::test]
 75s |   could not find `test` in `tokio`
 75s 
 75s error[E0433]: failed to resolve: could not find `test` in `tokio`
 75s--> src/socket.rs:562:14
 75s |
 75s 562 | #[tokio::test]
 75s |   could not find `test` in `tokio`
 75s 
 75s error[E0433]: failed to resolve: could not find `test` in `tokio`
 75s--> src/socket.rs:568:14
 75s |
 75s 568 | #[tokio::test]
 75s |   could not find `test` in `tokio`
 75s 
 76s For more information about this error, try `rustc --explain E0433`.
 76s error: could not compile `ntp-udp` due to 8 previous errors
...
 96s autopkgtest [03:27:44]:  summary
 96s rust-ntp-udp:@   FAIL non-zero exit status 101
 96s librust-ntp-udp-dev:default FAIL non-zero exit status 101
 96s librust-ntp-udp-dev: FAIL non-zero exit status 101

Bug#1056029: rust-hafas-rs: autopkgtest failure

[Adrian Bunk]

Source: rust-hafas-rs
Version: 0.1.0-1
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-hafas-rs/39490355/log.gz

...
143s error[E0432]: unresolved import `crate::requester::hyper`
143s--> src/profile/mod.rs:460:20
143s |
143s 460 | requester::hyper::HyperRustlsRequester,
143s |^ could not find `hyper` in `requester`
143s 
...
1412s autopkgtest [23:42:46]:  summary
1412s rust-hafas-rs:@  FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:all-profiles FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:anyhow FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:avv-profile FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:bart-profile FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:bls-profile FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:cfl-profile FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:cmta-profile FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:dart-profile FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:db-busradar-nrw-profile FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:db-profile FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:default PASS
1412s librust-hafas-rs-dev:env_logger FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:geojson FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:hyper FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:hyper-requester PASS
1412s librust-hafas-rs-dev:hyper-rustls FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:insa-profile FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:irish-rail-profile FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:mobil-nrw-profile FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:mobiliteit-lu-profile FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:nahsh-profile FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:nvv-profile FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:oebb-profile FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:ooevv-profile FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:polyline FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:polylines FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:rejseplanen-profile FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:rest-server PASS
1412s librust-hafas-rs-dev:rmv-profile FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:rsag-profile FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:rt-multi-thread FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:saarvv-profile FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:salzburg-profile FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:sbahn-muenchen-profile FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:serde_urlencoded FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:svv-profile FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:tokio FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:vbb-profile FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:vbn-profile FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:verbundlinie-profile FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:vgi-profile FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:vkg-profile FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:vmt-profile FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:vor-profile FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:vos-profile FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:vrn-profile FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:vsn-profile FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:vvt-profile FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:vvv-profile FAIL non-zero exit status 101
1412s librust-hafas-rs-dev:zvv-profile FAIL non-zero exit status 101
1412s librust-hafas-rs-dev: FAIL non-zero exit status 101

Bug#1056027: rsass: autopkgtest regression

[Adrian Bunk]

Source: rsass
Version: 0.28.2+20231021-3
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rsass/39898469/log.gz

...
 54s autopkgtest [11:12:12]: test rust-rsass:@:  
/usr/share/cargo/bin/cargo-auto-test rsass --all-targets --all-features 
--no-fail-fast -- --skip core_functions::math::log::base::one_fuzzy --skip 
values::calculation::calc::constant::e::equals_max_precision --skip 
values::calculation::calc::constant::pi::equals_max_precision
 54s autopkgtest [11:12:12]: test rust-rsass:@: [---
 54s crate directory not found: /usr/share/cargo/registry/rsass---all-targets
 54s autopkgtest [11:12:12]: test rust-rsass:@: ---]
 54s autopkgtest [11:12:12]: test rust-rsass:@:  - - - - - - - - - - results - 
- - - - - - - - -
 54s rust-rsass:@ FAIL non-zero exit status 1
...
132s autopkgtest [11:13:30]:  summary
132s rust-rsass:@ FAIL non-zero exit status 1
132s librust-rsass-dev:default FAIL non-zero exit status 1
132s librust-rsass-dev:   FAIL non-zero exit status 1

Bug#1056026: librust-eza-dev is not installable

[Adrian Bunk]

Package: librust-eza-dev
Version: 0.15.0-1
Severity: serious

The following packages have unmet dependencies:
 librust-eza-dev : Depends: librust-git2-0.16+vendored-libgit2-dev but it is 
not installable or
librust-git2-0.15+vendored-libgit2-dev but it is 
not installable or
librust-git2-0.14+vendored-libgit2-dev but it is 
not installable or
librust-git2-0.13+vendored-libgit2-dev but it is 
not installable

Bug#1055525: cryptojs: CVE-2023-46233

[Yadd]

Hi,

this bug is still unfixed even if patch is trivial. Here is a template 
for an updatediff --git a/debian/changelog b/debian/changelog
index 558cbac..849d0f4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+cryptojs (3.1.2+dfsg-3+deb12u1) bookworm-security; urgency=medium
+
+  * Change default hash algorithm and iteration's for PBKDF2
+(Closes: #1055525)
+
+ -- Yadd   Thu, 16 Nov 2023 10:53:45 +0400
+
 cryptojs (3.1.2+dfsg-3) unstable; urgency=medium
 
   * Add upstream metadata.
diff --git a/debian/patches/CVE-2023-46233.patch 
b/debian/patches/CVE-2023-46233.patch
new file mode 100644
index 000..c321f49
--- /dev/null
+++ b/debian/patches/CVE-2023-46233.patch
@@ -0,0 +1,38 @@
+Description: Change default hash algorithm and iteration's for PBKDF2
+ to prevent weak security by using the default configuration
+Author: evanvosberg 
+Origin: upstream, https://github.com/brix/crypto-js/commit/421dd538
+Bug: https://github.com/brix/crypto-js/security/advisories/GHSA-xwcq-pm8m-c4vf
+Bug-Debian: https://bugs.debian.org/1055525
+Forwarded: not-needed
+Reviewed-By: Yadd 
+Last-Update: 2023-11-16
+
+--- a/components/pbkdf2.js
 b/components/pbkdf2.js
+@@ -11,7 +11,7 @@
+ var Base = C_lib.Base;
+ var WordArray = C_lib.WordArray;
+ var C_algo = C.algo;
+-var SHA1 = C_algo.SHA1;
++var SHA256 = C_algo.SHA256;
+ var HMAC = C_algo.HMAC;
+ 
+ /**
+@@ -22,13 +22,13 @@
+  * Configuration options.
+  *
+  * @property {number} keySize The key size in words to generate. 
Default: 4 (128 bits)
+- * @property {Hasher} hasher The hasher to use. Default: SHA1
++ * @property {Hasher} hasher The hasher to use. Default: SHA256
+  * @property {number} iterations The number of iterations to perform. 
Default: 1
+  */
+ cfg: Base.extend({
+ keySize: 128/32,
+-hasher: SHA1,
+-iterations: 1
++hasher: SHA256,
++iterations: 25
+ }),
+ 
+ /**
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..4fdeacb
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+CVE-2023-46233.patch

Bug#1055750: Bug#1055228: plplot: FTBFS on armhf (test segfault)

[Rafael Laboissière]

* Emanuele Rocca  [2023-11-15 20:11]:


On 2023-11-15 06:47, Rafael Laboissière wrote:

Does this mean that the origin of the bug is upstream or that it still may
be a bug in gfortran?


At this point we know for sure that the issue is not armhf-specific, and 
also that it is not caused by stack-clash-protection. On the contrary, 
enabling stack-clash-protection on armhf allowed us to discover a 
problem that would have otherwise gone unnoticed.


Whether the bug is in plplot or gfortran I really have no idea. I would 
tend not to think of a compiler issue unless we have some evidence in 
that direction though, and suggest raising the issue with plplot 
upstream. Showing them the x86 reproducer with -fsanitize=address should 
be a good starting point.


Ok, thanks.

FYI, I can reproduce the segfault on armhf and amd64 with 
-fsanitize=address.


My guess is that the bug is in PLplot and not in gfortran, but this is 
jsut a guess. I will eventually inform the PLplot upstream authors about 
the issue.


Best,

Rafael Laboissière

Bug#1056018: partman-base: parted_devices hangs with process in D state during Debian installer Detect Disks step

[Cyril Brulebois]

Control: severity -1 important

Hi,

Olivier F. R. Dierick  (2023-11-16):
> Justification: breaks the whole system

Not being able to install doesn't “break the whole system”. This is a
showstopper in the installation process in your case indeed, but that's
not what this severity is for.

> Updating from Debian 8 to Debian 12 from an USB stick.

Maybe check the image was correctly written on your USB stick? A number
of weird issues like that one are linked to hardware faults or similar
issues.

>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> Ineffective: Tried disconnecting external disks & USB storage HUB, and
> switching SATA setting from AHCI to IDE in BIOS.
> Also tried expert mode & text mode.
> 
>* What was the outcome of this action?
> 
> Debian Installer is stuck on Detect Disks.
> Switching to a console and running ps shows that a parted_devices
> process is in D state.

Anything in dmesg or /var/log/syslog?

It might be interesting to see what happens with 12.0 images (in case
something interesting happened in the kernel, but such a hard failure
seems rather strange), and maybe try your luck with some Debian Live
image?


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


signature.asc
Description: PGP signature

Bug#1055919: python-ansible-pygments: please make the build reproducible

[Stuart Prescott]

tldr: smells like a dh-python bug - I'll look at it more and reassign 
etc later.



Staring at some build logs some more:

* the dirs are generated always
* they get copied from .../.pybuild to ../debian/$package/ always
* they are supposed to get removed by dh_python3
* that removal is not always working

A common theme of the failures is that there are _two_
/usr/lib/python3.11/dist-packages/.foo directories to remove and only 
one of them is being removed. For python-ansible-pygments, .pytest_cache 
was being removed by dh-python3 but .test-results was not.


Adding in PYBUILD_VERBOSE=1 and some breakpoints into dh-python 
(specifically /usr/share/dh-python/dhpython/fs.py), I think there's a 
subtle bug about altering `dirs` while inside a loop from `os.walk`:


for name in dirs:
if name in ('test', 'tests') or name.startswith('.'):
log.debug('removing dist-packages/%s', name)
rmtree(join(root, name))
dirs.remove(name)

Removing `name` from `dirs` means that the next item is accidentally 
skipped. A classic "don't change the object you're iterating through 
while you are iterating through it" issue:


In [1]: L = list(range(0, 10))

In [2]: for i in L:
...: print(i)
...: L.remove(i)
...:
0
2
4
6
8

Which item is not processed in the next iteration by dh_python3 now 
depends on the order in which `os.walk` lists the directories. That is 
presumably dependent on all manner of things (filesystem? collation? 
luck?). On the r-b setup and building by hand I get different results to 
within sbuild (and on the buildd).


In sbuild on ext4, `find -type d` (I have memory that this reflects disk 
order?) has an order in 
./debian/python3-ansible-pygments/usr/lib/python3.11/dist-packages of:


.test-results ansible_pygments .pytest_cache

while building by hand on tmpfs, I get

 ansible_pygments .test-results .pytest_cache

For the former, accidentally skipping the directory after the one that 
gets removed isn't an issue, but for the latter it is.




--
Stuart Prescott   http://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer  http://www.debian.org/   stu...@debian.org
GPG fingerprint   90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#1056018: partman-base: parted_devices hangs with process in D state during Debian installer Detect Disks step

[Olivier F. R. Dierick]

Source: partman-base
Version: 226
Severity: critical
Tags: d-i
Justification: breaks the whole system

Dear Maintainer,

   * What led up to the situation?

Updating from Debian 8 to Debian 12 from an USB stick.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Ineffective: Tried disconnecting external disks & USB storage HUB, and 
switching SATA setting from AHCI to IDE in BIOS.
Also tried expert mode & text mode.

   * What was the outcome of this action?

Debian Installer is stuck on Detect Disks.
Switching to a console and running ps shows that a parted_devices process is in 
D state.

   * What outcome did you expect instead?

parted_devices should only take a few seconds and Debian Installer should 
continue to the partionning step.

Note: I'm reporting from another computer.
System information from the old OS is irrelevant anyway as the computer is 
booted on the Debian 12 installer image when the problem occurs.

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

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

Bug#1056014: cryptojs: Library no more maintained, please keep out of next Debian stable

[Yadd]

Source: cryptojs
Severity: serious
Tags: security upstream
Justification: security
X-Debbugs-Cc: y...@debian.org, Debian Security Team 

Hi,

according to https://github.com/brix/crypto-js#readme it seems that
cryptojs is no more maintained. I just dropped the only one reverse
dependency so cryptojs can be safely removed from Debian.

Bug#1054508: Connman: breaks connections, uses 1 CPU core, and trashes disk space

[программист некто]

Hello. I will try to test it, but it may be difficult. Because, I got the issue 
with Wi-Fi that located in another city.
I never got this issue with home Wi-Fi.

> Hi,
> 
> Please could you test with connman 1.42-1 in sid
> and see if you still see the issue. Thanks.
> 
> Regards,
> Vignesh
> 

Bug#1056007: 0ad: Please enable riscv64 build

[Eric Long]

Source: 0ad
Version: 0.0.26-4
Severity: normal
Tags: ftbfs patch upstream
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org, i...@hack3r.moe

Dear maintainer,

I've ported 0ad to riscv64, using patches for SpiderMonkey 78. The
debdiff is attached below.

The game has been tested and run on Milk-V Pioneer with SG2042 and AMD
GPU [1], using the packaged 0ad from Arch Linux RISC-V (which is also
submitted by me) [2]. The fix for GCC 13 double-word atomic is also
included [3].

Cheers,
Eric

[1]: https://twitter.com/Houge_Langley/status/1676369377967370240
[2]: https://github.com/felixonmars/archriscv-packages/pull/2782
[3]: https://github.com/felixonmars/archriscv-packages/pull/2962
diff -Nru 0ad-0.0.26/debian/changelog 0ad-0.0.26/debian/changelog
--- 0ad-0.0.26/debian/changelog 2023-07-16 15:13:32.0 +0800
+++ 0ad-0.0.26/debian/changelog 2023-11-15 20:32:21.0 +0800
@@ -1,3 +1,10 @@
+0ad (0.0.26-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add riscv64 support
+
+ -- Eric Long   Wed, 15 Nov 2023 20:32:21 +0800
+
 0ad (0.0.26-4) unstable; urgency=medium
 
   [ Vincent Cheng ]
diff -Nru 0ad-0.0.26/debian/control 0ad-0.0.26/debian/control
--- 0ad-0.0.26/debian/control   2023-07-16 15:13:04.0 +0800
+++ 0ad-0.0.26/debian/control   2023-11-15 20:32:21.0 +0800
@@ -47,7 +47,7 @@
 Rules-Requires-Root: no
 
 Package: 0ad
-Architecture: amd64 arm64 armhf i386 kfreebsd-amd64 kfreebsd-i386
+Architecture: amd64 arm64 armhf i386 kfreebsd-amd64 kfreebsd-i386 riscv64
 Pre-Depends: dpkg (>= 1.15.6~)
 Depends:
  0ad-data (>= ${source:Upstream-Version}),
diff -Nru 0ad-0.0.26/debian/patches/add-riscv64-support.patch 
0ad-0.0.26/debian/patches/add-riscv64-support.patch
--- 0ad-0.0.26/debian/patches/add-riscv64-support.patch 1970-01-01 
08:00:00.0 +0800
+++ 0ad-0.0.26/debian/patches/add-riscv64-support.patch 2023-11-15 
20:32:21.0 +0800
@@ -0,0 +1,414 @@
+Description: Enables riscv64 build
+Author: Eric Long 
+Forwarded: https://trac.wildfiregames.com/ticket/6834
+
+diff --git a/build/premake/premake5.lua b/build/premake/premake5.lua
+index 9539e2a..12dcd43 100644
+--- a/build/premake/premake5.lua
 b/build/premake/premake5.lua
+@@ -105,6 +105,8 @@ else
+   arch = "e2k"
+   elseif string.find(machine, "ppc64") == 1 or string.find(machine, 
"powerpc64") == 1 then
+   arch = "ppc64"
++  elseif string.find(machine, "riscv64") == 1 then
++  arch = "riscv64"
+   else
+   print("WARNING: Cannot determine architecture from GCC, 
assuming x86")
+   end
+@@ -896,6 +898,8 @@ function setup_all_libs ()
+   table.insert(source_dirs, "lib/sysdep/arch/e2k");
+   elseif arch == "ppc64" then
+   table.insert(source_dirs, "lib/sysdep/arch/ppc64");
++  elseif arch == "riscv64" then
++  table.insert(source_dirs, "lib/sysdep/arch/riscv64");
+   end
+ 
+   -- OS-specific
+diff --git a/libraries/source/nvtt/src/extern/poshlib/posh.h 
b/libraries/source/nvtt/src/extern/poshlib/posh.h
+index 5382294..dfbe635 100644
+--- a/libraries/source/nvtt/src/extern/poshlib/posh.h
 b/libraries/source/nvtt/src/extern/poshlib/posh.h
+@@ -540,6 +540,17 @@ LLVM:
+ #  define POSH_CPU_STRING "PA-RISC"
+ #endif
+ 
++#if defined __riscv
++#  define POSH_CPU_RISCV 1
++#  if __riscv_xlen == 64
++#define POSH_CPU_RISCV64 1
++#define POSH_CPU_STRING "riscv64"
++#  elif __riscv_xlen == 32
++#define POSH_CPU_RISCV32 1
++#define POSH_CPU_STRING "riscv32"
++#  endif
++#endif
++
+ #if !defined POSH_CPU_STRING
+ #  error POSH cannot determine target CPU
+ #  define POSH_CPU_STRING "Unknown" /* this is here for Doxygen's benefit */
+diff --git a/libraries/source/nvtt/src/src/nvcore/Debug.cpp 
b/libraries/source/nvtt/src/src/nvcore/Debug.cpp
+index a211715..89ff150 100644
+--- a/libraries/source/nvtt/src/src/nvcore/Debug.cpp
 b/libraries/source/nvtt/src/src/nvcore/Debug.cpp
+@@ -674,6 +674,9 @@ namespace
+ #elif NV_CPU_AARCH64
+ ucontext_t * ucp = (ucontext_t *)secret;
+ return (void *) ucp->uc_mcontext.pc;
++#elif POSH_CPU_RISCV64
++ucontext_t * ucp = (ucontext_t *)secret;
++return (void *) ucp->uc_mcontext.__gregs[REG_PC];
+ #else
+ #  error "Unknown CPU"
+ #endif
+diff --git a/libraries/source/nvtt/src/src/nvcore/Debug.h 
b/libraries/source/nvtt/src/src/nvcore/Debug.h
+index 75fb41c..37fc407 100644
+--- a/libraries/source/nvtt/src/src/nvcore/Debug.h
 b/libraries/source/nvtt/src/src/nvcore/Debug.h
+@@ -166,7 +166,7 @@ NVCORE_API void NV_CDECL nvDebugPrint( const char *msg, 
... ) __attribute__((for
+ namespace nv
+ {
+ inline bool isValidPtr(const void * ptr) {
+-#if NV_CPU_X86_64 || POSH_CPU_PPC64 || NV_CPU_AARCH64
++#if NV_CPU_X86_64 || POSH_CPU_PPC64 || NV_CPU_AARCH64 || POSH_CPU_RISCV64
+ if (ptr == NULL) return true;
+ if 

Bug#1037478: ca-certificates-java: Loop in the execution of the trigger

[Cyril Brulebois]

Hi,

Matthias Klose  (2023-07-12):
> Version: 20230710
> 
> Fixed now.

Thanks for the bugfix.

This is a serious issue that still affects at least bookworm (I didn't
check bullseye): applying the update published as DSA-5548-1 makes dpkg
error out. Cc-ing the security team accordingly.


On a bookworm system (freshly deployed and without any weird things done
package-wise) that had openjdk-17-jre-headless installed, upgrading it
to the version that's available in bullseye-security triggered the dpkg
trigger loop. Thankfully that's easily recoverable (e.g. by running
`dpkg --configure -a`, even if there might be better ways to do so), but
that's still something I believe shouldn't be happening on stable
systems with just the matching stable-security suite enabled.

This issue is trivially reproducible there by switching back and forth
between bookworm's version and bookworm-security's. Setting some debug
level in dpkg, I'm getting the attached log for one of those runs.

apt-get install -o dpkg::options::=-D7 openjdk-17-jre-headless/bookworm
apt-get install -o dpkg::options::=-D7 
openjdk-17-jre-headless/bookworm-security

→ ca-certificates-java-full-debug.txt

At the time of writing, that means switching between 17.0.8+7-1~deb12u1
and 17.0.9+9-1~deb12u1.


Checking whether this was possibly a problem with that particular
system, I tried reproducing the issue with openjdk-17-jre-headless in
a bookworm chroot, but I wasn't successful. Installing openjdk-17-jre
makes it possible to reproduce the issue though.

Shell script to reproduce (adjust DST=/tmp/bookworm if needed):

→ repro-1037478.sh

I'm attaching the log for the failed upgrade, again with dpkg debug:

→ repro-1037478.log


I've verified in both cases (real baremetal system and repro chroot)
that installing ca-certificates-java 20230710 beforehand indeed makes
the problem disappear. Since this release is a fixup for the previous
release which was mainly aimed at fixing this particular issue, I
suppose it would make sense to investigate whether something like
20230710~deb12u1 would be appropriate for bookworm-proposed-updates?

(And maybe bullseye-proposed-updates, but again, I didn't check the
bullseye part.)

Thanks for considering.


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/
root@baremetal:~# apt-get install -o dpkg::options::=-D7 
openjdk-17-jre-headless/bookworm-security
…
Selected version '17.0.9+9-1~deb12u1' for 'openjdk-17-jre-headless'
…
The following packages will be upgraded:
  openjdk-17-jre-headless
1 upgraded, 0 newly installed, 0 to remove and 284 not upgraded.
Need to get 0 B/43.7 MB of archives.
After this operation, 487 kB disk space will be freed.
(Reading database ... 30411 files and directories currently installed.)
Preparing to unpack .../openjdk-17-jre-headless_17.0.9+9-1~deb12u1_amd64.deb ...
D02: trigproc_activate_packageprocessing pkg=openjdk-17-jre-headless:amd64
D02: post_script_tasks - ensure_diversions
D02: post_script_tasks - trig_incorporate
Unpacking openjdk-17-jre-headless:amd64 (17.0.9+9-1~deb12u1) over 
(17.0.8+7-1~deb12u1) ...
D02: post_script_tasks - ensure_diversions
D02: post_script_tasks - trig_incorporate
D01: trigproc_run_deferred
Setting up openjdk-17-jre-headless:amd64 (17.0.9+9-1~deb12u1) ...
D02: trigproc_activate_packageprocessing pkg=openjdk-17-jre-headless:amd64
Installing new version of config file 
/etc/java-17-openjdk/security/public_suffix_list.dat ...
D02: post_postinst_tasks - trig_incorporate
D01: trigproc_run_deferred
D01: trigproc ca-certificates-java:all
D01: trigproc ca-certificates-java:all
D01: trigproc ca-certificates-java:all
D01: trigproc ca-certificates-java:all
D01: trigproc ca-certificates-java:all
D01: trigproc ca-certificates-java:all
D01: trigproc ca-certificates-java:all
D01: trigproc ca-certificates-java:all
D01: trigproc ca-certificates-java:all
D01: trigproc ca-certificates-java:all
D01: check_triggers_cycle pnow=ca-certificates-java:all
D02: check_triggers_cycle pnow=ca-certificates-java:all first
D01: trigproc ca-certificates-java:all
D01: check_triggers_cycle pnow=ca-certificates-java:all
D02: tortoise_in_hare pnow=ca-certificates-java 
tortoise=ca-certificates-java
D02: tortoise_in_hare pnow=ca-certificates-java 
tortoise=ca-certificates-java tortoisetrig=/usr/lib/jvm
D04: tortoise_in_hare pnow=ca-certificates-java 
tortoise=ca-certificates-java tortoisetrig=/usr/lib/jvm haretrig=/usr/lib/jvm
D02: tortoise_in_hare pnow=ca-certificates-java 
tortoise=ca-certificates-java tortoisetrig=update-ca-certificates-java
D04: tortoise_in_hare pnow=ca-certificates-java 
tortoise=ca-certificates-java tortoisetrig=update-ca-certificates-java 
haretrig=/usr/lib/jvm
D04: tortoise_in_hare pnow=ca-certificates-java 
tortoise=ca-certificates-java tortoisetrig=update-ca-certificates-java 

Bug#1056006: bookworm-pu: package libsolv/0.7.23-1+deb12u1

[Luca Boccassi]

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

[ Reason ]
Both Fedora Rawhide and SUSE Tumbleweed started to compress their
respective RepoData with zstd. The libsolv version in bookworm is not
build with zstd support, so using zypper/dnf from any Ubuntu version to
build a new Fedora/SUSE chroot started to fail this week.

[ Impact ]
$ mkdir -p repos.d img
$ cat 
Building repository 'test.repo' cache 
.[error]
Error building the cache:
[test.repo|https://download.opensuse.org/tumbleweed/repo/oss/] Failed to cache 
repo (1).
History:
 - 'repo2solv' '-o' '/tmp/img/var/cache/zypp/solv/test.repo/solv' '-X' 
'/tmp/img/var/cache/zypp/raw/test.repo'
   
/tmp/img/var/cache/zypp/raw/test.repo/repodata/d6fbf1152bab99fc7ceacf974422a9799694274b64c36015b10288e6cabadd81e4649b19f52570efc5f3ab5b28817c9561fa8eeca117a05f3caea6c33e48cb69-primary.xml.zst:
 No such file or directory
   Command exited with status 1.

[ Tests ]
libsolv in bookworm already supports zstd, but it is not enabled. The
fix is simply to build-depend on libzstd and enable the relevant cmake
flag, and then it works:

$ zypper --reposd-dir=/tmp/repos.d --root=/tmp/img --gpg-auto-import-keys 
install distribution-release filesystem
Building repository 'mkosi.repo' cache 
.[done]
Loading repository data...
Reading installed packages...
'distribution-release' not found in package names. Trying capabilities.
Resolving package dependencies...

The following 20 NEW packages are going to be installed:
  bash bash-sh compat-usrmerge-tools filesystem glibc glibc-extra libgcc_s1 
libncurses6 libpcre2-8-0 libreadline8
  libselinux1 libstdc++6 ncurses-utils openSUSE-release 
openSUSE-release-appliance-custom
  patterns-glibc-hwcaps-x86_64_v3 system-user-root terminfo-base 
terminfo-screen timezone

The following 4 recommended packages were automatically selected:
  glibc-extra ncurses-utils terminfo-screen timezone

The following 9 packages are suggested, but will not be installed:
  branding-openSUSE distribution-logos-openSUSE-Tumbleweed java-11-openjdk 
mariadb mariadb-client openssl-1_1
  openSUSE-build-key openSUSE-repos-Tumbleweed procps

20 new packages to install.
Overall download size: 7.3 MiB. Already cached: 0 B. After the operation, 
additional 16.3 MiB will be used.
Continue? [y/n/v/...? shows all options] (y): y
<...>
$ cat img/usr/lib/os-release 
NAME="openSUSE Tumbleweed"
# VERSION="20231114"
ID="opensuse-tumbleweed"
ID_LIKE="opensuse suse"
VERSION_ID="20231114"
PRETTY_NAME="openSUSE Tumbleweed"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:tumbleweed:20231114"
BUG_REPORT_URL="https://bugzilla.opensuse.org;
SUPPORT_URL="https://bugs.opensuse.org;
HOME_URL="https://www.opensuse.org;
DOCUMENTATION_URL="https://en.opensuse.org/Portal:Tumbleweed;
LOGO="distributor-logo-Tumbleweed"

[ Risks ]
Minimal, support for zstd is old and the change is simply a new build
dependency and build flag. Worst case scenario is that zstd doesn't
work, and the situation is not any different from status quo.

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

[ Other info ]
I have already updated this change. It is fixed in the latest unstable
upload as well. I am also proposing the same fix for Ubuntu stable
releases:

https://bugs.launchpad.net/ubuntu/+source/libsolv/+bug/2043625

-- 
Kind regards,
Luca Boccassi
diff -Nru libsolv-0.7.23/debian/changelog libsolv-0.7.23/debian/changelog
--- libsolv-0.7.23/debian/changelog	2023-02-06 22:47:58.0 +
+++ libsolv-0.7.23/debian/changelog	2023-11-16 01:02:13.0 +
@@ -1,3 +1,10 @@
+libsolv (0.7.23-1+deb12u1) bookworm; urgency=medium
+
+  [ Sjoerd Simons ]
+  * Enable libzstd compression support
+
+ -- Luca Boccassi   Thu, 16 Nov 2023 01:02:13 +
+
 libsolv (0.7.23-1) unstable; urgency=medium
 
   [ Debian Janitor ]
diff -Nru libsolv-0.7.23/debian/control libsolv-0.7.23/debian/control
--- libsolv-0.7.23/debian/control	2023-02-06 22:44:55.0 +
+++ libsolv-0.7.23/debian/control	2023-11-16 01:01:56.0 +
@@ -13,6 +13,7 @@
  librpm-dev (>= 4),
  liblzma-dev,
  libbz2-dev,
+ libzstd-dev,
  python3-dev,
  libpython3-dev,
  swig,
diff -Nru libsolv-0.7.23/debian/rules libsolv-0.7.23/debian/rules
--- libsolv-0.7.23/debian/rules	2023-02-06 22:47:25.0 +
+++ libsolv-0.7.23/debian/rules	2023-11-16 01:01:56.0 +
@@ -47,6 +47,7 

Bug#1056005: ITP: python-singledispatch-json -- custom JSON encoder for Python

[Josenilson Ferreira da Silva]

Package: wnpp
Severity: wishlist
Owner: Josenilson Ferreira da Silva 
X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com

* Package name: python-singledispatch-json
  Version : 0.4.0
  Upstream Contact: Davis-Foster 
* URL : https://github.com/domdfcoding/singledispatch-json
* License : Expat
  Programming Lang: Python
  Description : custom JSON encoder for Python

 Module uses functools.singledispatch to support custom encoders for Python
 built-in classes and user-created classes.
 .
 The goal is to simplify the process of serializing objects into JSON by
 allowing developers to register custom encoders for their classes,
 allowing you to define instances to be converted into JSON format.
 .
 After coding, you can use sdjson.dumps(class_instance) to serialize an
 instance of the class into a JSON string. This makes the process of saving
 objects in JSON easier.
 .
 In addition to serialization to a string, the project provides
 the ability to serialize objects directly to JSON files using sdjson.dumps
 (class_instance, fp).
 .
 The sdjson project also supports several features of the json module,
 including load, load, JSONDecoder, JSONDecodeError and JSONEncoder.
 This allows you to use sdjson as a drop-in replacement for the json
 module.

 Note: Module required for the package
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028151

Bug#1056004: ITP: python-pyrgg -- Python Random Graph Generator

[Yogeswaran Umasankar]

Package: wnpp
Severity: wishlist
Owner: Yogeswaran Umasankar 
X-Debbugs-Cc: debian-de...@lists.debian.org, kd8...@gmail.com

* Package name: python-pyrgg
  Version : 1.4 
  Upstream Contact: Sepand Haghighi 
* URL : https://github.com/sepandhaghighi/pyrgg
* License : Expat
  Programming Lang: Python
  Description : Python Random Graph Generator

Pyrgg is an easy-to-use synthetic random graph generator
 written in Python which supports various graph file formats
 including DIMACS .gr files. Pyrgg has the ability to
 generate graphs of different sizes and is designed to
 provide input files for broad range of graph-based
 research applications, including but not limited to
 testing, benchmarking and performance-analysis of graph
 processing frameworks. Pyrgg target audiences are computer
 scientists who study graph algorithms and graph processing
 frameworks.

Bug#1056003: flashrom: register_spi_master called with incomplete master definition

[Bastian Germann]

Package: flashrom
Version: 1.3.0-1
Severity: important

Running `flashrom -p internal:laptop=force_I_want_a_brick -r file`
on a corebooted ThinkPad T60 succeeds with 1.2-5:

flashrom v1.2 on Linux 6.5.0-4-686 (i686)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
coreboot table found at 0x7ff4b000.
Found chipset "Intel ICH7M".
Enabling flash write... OK.
Found SST flash chip "SST25VF016B" (2048 kB, SPI) mapped at physical address 
0xffe0.
Reading flash... done.



Running the same command with current version 1.3.0 (any Debian revision)
and with the same kernel fails:

flashrom unknown on Linux 6.5.0-4-686 (i686)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
coreboot table found at 0x7ff4b000.
Found chipset "Intel ICH7M".
Enabling flash write... register_spi_master called with incomplete master definition. Please report 
a bug at flash...@flashrom.org

OK.
No EEPROM/flash device found.
Note: flashrom can never write if the flash chip isn't found automatically.

Bug#1035392: installation-reports: Installation Report: Bookworm RC2: Raspberry Pi 400 (netboot)

[James Addison]

Followup-For: Bug #1035392
Control: close -1

(closing; I'll likely re-attempt an install on the same hardware with a more
recent release of Debian in future, for comparison purposes)

Bug#1056002: fortunes-debian-hints: [INTL:pt] Updated Portuguese translation

[Américo Monteiro]

Package: fortunes-debian-hints
Version: 
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for  fortunes-debian-hints messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


fortunes-debian-hints_pt.po.gz
Description: application/gzip

Bug#1056001: spamd: user_prefs include files are only read on the first scan

[Martin Schwenke]

Package: spamd
Version: 4.0.0-6
Severity: normal

Dear Maintainer,

When using spamd and the user_prefs file contains include directives, the
included files are only read on the first scan.  This is because the per-user
rules are cleared on user change, but the list of included files is not
cleared.

This was reported upstream via:

  https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8130

and fixed in the trunk via commit:

  
https://svn.apache.org/viewvc/spamassassin/trunk/lib/Mail/SpamAssassin.pm?r1=1913789=1913803_format=h

The fix is in /usr/share/perl5/Mail/SpamAssassin.pm, which is in the 
spamassassin package, but I believe the fix only affects the spamd
package.

I have applied the patch by hand, in-place in the above file on my Debian
system and it appears to fix the problem.

It would be excellent if you could apply this fix in the package for
Debian stable.

Thanks...

peace & happiness,
martin

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

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

Versions of packages spamd depends on:
ii  init-system-helpers  1.65.2
ii  rsyslog [system-log-daemon]  8.2302.0-1
ii  spamassassin 4.0.0-6

spamd recommends no packages.

spamd suggests no packages.

-- Configuration Files:
/etc/default/spamd changed:
OPTIONS="--create-prefs --max-children 5 --max-spare=3 --helper-home-dir"
PIDFILE="/run/spamd.pid"
[ -z "$1" ] || /etc/init.d/spamd-virtual $1 || true


-- no debconf information

Bug#738575: pthread: segfault in libpthread on Intel Galileo board

[James Addison]

On Wed, 15 Nov 2023 at 21:57, Ray Kinsella  wrote:
>
> Thanks for this - you are kind to look at this issue.

You're welcome - I enjoyed learning a bit about the Quark hardware,
and the esoteric lock bug.  A shame I didn't learn about it five years
ago I suppose, but there we are.

> It's been a long time since Intel manufactured the X1000 / Quark, I am not 
> sure how many are left in the wild.
> Do you think this is something that Debian might want to package and ship?

I should admit that I'm not a Debian maintainer or developer, just a
passerby who attempts to make progress on bugs that interest to me
(possibly to the annoyance of actual DMs/DDs), so my opinion is
somewhat external (i.e.: take with a grain of salt).  It's entirely
possible that the maintenance for an additional package wouldn't be
worthwhile -- and in general, 32-bit x86 support in Debian does tend
to be dwindling.  Basically: someone has to be motivated about it
enough to be responsible for the package.

On the other hand: it seemed to me based on a quick look that much of
the packaging work is already in place, and that this package would be
opt-in for anyone who wanted to use it.  The typical use case would be
people preparing root filesystems on removable/replicable storage for
later (re)attachment to Quark systems, I'd guess.  Even so: the
LD_PRELOAD and GRUB commandline stuff does make me a bit wary -
generally we shouldn't make any unnecessary or unexpected
modifications to the target system, because those should be the
responsibility of the sysadmin and not of the maintainer.

Do you know whether Intel shipped many Quark units?  I see that
manufacturing stopped in Y2019, which isn't too long ago, but I don't
know much about how widely-adopted they were.  It was the
energy-efficiency focus of them that gathered my interest in the first
place, FWIW.

> On Wed, 15 Nov 2023 at 12:27, James Addison  wrote:
>>
>> Followup-For: Bug #738575
>> X-Debbugs-Cc: raykinsell...@gmail.com
>>
>> If I understand correctly, then Ray's libx1000 library[1] provides a way to
>> work around this in software.  It uses some LD_PRELOAD magic, and from what I
>> remember, it's worth being careful when using that approach.
>>
>> I opened an RFP[2] for libx1000 earlier this year, and took another look at 
>> the
>> Debian packaging metadata in the codebase today, resulting in a few suggested
>> edits as a pull request on GitHub - cc'ing you to notify you about that, Ray.
>> I'm unsure whether some of the proposed postinst steps are required, and will
>> ask you about those upstream too.
>>
>> [1] - http://ashroe.eu/x1000/2016/10/21/fixing-lock-prefix-on-x1000.html
>>
>> [2] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037070

Bug#1055646: gdb: extremely slow response to basic commands

[tomazzi]

Hello Héctor,

Well, I want to fix this bug, because gdb is a very important tool for 
me, and compiling gdb from ./configure script is just a hack - not a 
real solution (which would eliminate the problem for good).


To do this, I need to have a complete build log with all the 
compiler/linker flags, compiler warnings, etc.


Unfortunately, the methods described on the official Debian Wiki page 
does not allow to build gdb from source package -> "debuild" fails to 
produce the binary shipped by Debian. (I would say that this deserves a 
separate BUG report).


Now, the "hacked" gdb is also different - so the first step is to find 
differences in the build process, like the exact list of features 
enabled/disabled.


So, can You please explain how did You build the gdb?

Regards.


On Mon, 13 Nov 2023 22:20:28 +0100 
=?UTF-8?B?SMOpY3RvciBPcsOzbiBNYXJ0w61uZXo=?=  wrote:


> Hello Tomazzi,
>
> On Mon, 13 Nov 2023 at 21:51, tomazzi  wrote:
> >
> > Hello,
> >
> > I've just built gdb "the Debian way", to check what are the differences
> > in the build process:
> > $> apt source gdb
> > $> apt build-dep gdb
> > $> debuild -b -uc -us
> >
> > From debuild output:
> >
> > gdb-default: configured with:
> > ...
> > --without-babeltrace
> > --with-babeltrace
> > ...
> > gdb-minimal: configured with:
> > ...
> > --without-babeltrace
> > --with-babeltrace
> > --without-babeltrace
> > ...
> >
> > This looks bad, but the results are even more "interresting":
>
> Latest switch is the one that should be in-use
>
> > The gdb binary installed in the system (**debsums OK**) reports the
> > following configuration (the "show configuration" command, differences
> > only):
> >
> > ...
> > --with-babeltrace
> > --with-mpfr
> > --with-xxhash
> > --with-python=/usr (relocatable)
> > --with-python-libdir=/usr/lib (relocatable)
> > --enable-source-highlight
> > ...
> >
> > The newly "debuild" gdb reports something *different*:
> > ...
> > --without-babeltrace << this: conflicting build flags
> > --without-mpfr
> > --with-xxhash
> > --without-python
> > --without-python-libdir
> > --disable-source-highlight
> > ...
> >
> >
> > The gdb which I've compiled using ./configure script (so *without*
> > Debian patches) reports:
> > ...
> > --with-babeltrace
> > --with-mpfr
> > --without-xxhash << this: libxxhash-dev is installed, but

Bug#738575: pthread: segfault in libpthread on Intel Galileo board

[Ray Kinsella]

Hi James,

Thanks for this - you are kind to look at this issue.

It's been a long time since Intel manufactured the X1000 / Quark, I am not
sure how many are left in the wild.
Do you think this is something that Debian might want to package and ship?

Thanks,

Ray K

On Wed, 15 Nov 2023 at 12:27, James Addison  wrote:

> Followup-For: Bug #738575
> X-Debbugs-Cc: raykinsell...@gmail.com
>
> If I understand correctly, then Ray's libx1000 library[1] provides a way to
> work around this in software.  It uses some LD_PRELOAD magic, and from
> what I
> remember, it's worth being careful when using that approach.
>
> I opened an RFP[2] for libx1000 earlier this year, and took another look
> at the
> Debian packaging metadata in the codebase today, resulting in a few
> suggested
> edits as a pull request on GitHub - cc'ing you to notify you about that,
> Ray.
> I'm unsure whether some of the proposed postinst steps are required, and
> will
> ask you about those upstream too.
>
> [1] - http://ashroe.eu/x1000/2016/10/21/fixing-lock-prefix-on-x1000.html
>
> [2] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037070
>

Bug#1055901: Acknowledgement (raspi-firmware: postinst fails, makes bad assumption about existence of /boot/firmware/)

[Fabrice Meyer]

I got this issue while upgrading from bullseye to bookworm

I opened this PR
https://salsa.debian.org/debian/raspi-firmware/-/merge_requests/33 on
salsa. It might do the job. I just tested the small if I added, I'd be
glad if someone is able to make test in condition of this.

Regards,

Fabrice

Bug#1024079: uvloop FTBFS on IPV6-only buildds

[Dale Richards]

On Monday, 13 November 2023 at 09:13, d...@dalerichards.net 
 wrote:

> The attached patch should make the test agnostic to IP version.

My apologies - in my haste to post I accidentally attached the wrong version of 
the patch, which does not actually work. Please disregard.

In further testing, I've also found that the "correct" version of the patch is 
also imperfect, so I'm working on a more complete patch that will allow uvloop 
to build on IPv6-only hosts. I'll post it as soon as it's ready.

Best regards,
Dale Richards

Bug#1055962: intel-microcode: CVE-2023-23583: INTEL-SA-00950

[Salvatore Bonaccorso]

Proposed changes to rebase to 20231114 in
https://salsa.debian.org/hmh/intel-microcode/-/merge_requests/10

Regards,
Salvatore

Bug#1055567: Error: gscan2pdf fails to compile

[jeff]

On 15/11/2023 12:19, Soumyanath Chatterjee wrote:

I find line 8 is commented out


I take it, therefore, that you didn't comment out the line yourself 
sometime in the past?


How did you install gscan2pdf?


ls -l /usr/lib/x86_64-linux-gnu/libsane.so.1
lrwxrwxrwx 1 root root 17 Sep 17  2020 
/usr/lib/x86_64-linux-gnu/libsane.so.1-> libsane.so.1.0.29


What about

ls -l /usr/lib/x86_64-linux-gnu/libsane.so.1.0.29

?

Bug#1056000: python-asyncssh: CVE-2023-46445

[Salvatore Bonaccorso]

Source: python-asyncssh
Version: 2.10.1-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for python-asyncssh.

CVE-2023-46445[0]:
| An issue in AsyncSSH v2.14.0 and earlier allows attackers to control
| the extension info message (RFC 8308) via a man-in-the-middle
| attack.


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-46445
https://www.cve.org/CVERecord?id=CVE-2023-46445
[1] https://github.com/ronf/asyncssh/security/advisories/GHSA-cfc2-wr2v-gxm5

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1013285: needrestart: Failed to check for processor microcode upgrades.

[Antoine Beaupré]

Control: tags -1 +patch

On 2023-11-15 14:54:26, Antoine Beaupré wrote:
> On 2022-06-20 13:54:38, Nick Lewycky wrote:
>> Package: needrestart
>> Version: 3.6-1
>> Severity: normal
>>
>> `sudo needrestart -w` always prints "Failed to check for processor
>> microcode upgrades." on my AMD Ryzen 9 3900X 12-Core Processor.
>
> [...]
>
> There's now a PR for this upstream:
>
> https://github.com/liske/needrestart/pull/285
>
> People suffering from this issue are encouraged to test this and report
> back upstream (or here, if you can't upstream).

I tested it and it doesn't work. It only *seemed* to work because the
author tested with -v, which *does* work around the issue.

I found the issue, and sent this PR upstream to fix it:

https://github.com/liske/needrestart/pull/288

Patch attached, people are again encouraged to test and report back.

I also attach upstream commit v3.6-9-ge85bfe3 which also seem necessary
to fix firmware checks on my end...

a.

-- 
Advertisers, not governments, are the primary censors of media content 
in the United States today.
- C. Edwin Baker
>From b073fb6d9969597173daa8c511a85bae9b03ed37 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
Date: Wed, 15 Nov 2023 15:20:37 -0500
Subject: [PATCH] fix AMD ucode checking in non-debug mode

It looks like the assignment when the ucode exist was not
done *unless* `debug` (`-v`) was set. Therefore, all AMD microcode
checks were returning UNKNOWN, including in Nagios checks, unless the
`-v` ("verbose", but actually `debug`) was passed.

Closes: #249
---
 perl/lib/NeedRestart/uCode/AMD.pm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/perl/lib/NeedRestart/uCode/AMD.pm b/perl/lib/NeedRestart/uCode/AMD.pm
index 638e68d..6daad8f 100644
--- a/perl/lib/NeedRestart/uCode/AMD.pm
+++ b/perl/lib/NeedRestart/uCode/AMD.pm
@@ -185,8 +185,8 @@ sub nr_ucode_check_real {
 if ( exists( $_ucodes->{cpuid}->{$cpuid} ) ) {
 my $prid = $_ucodes->{cpuid}->{$cpuid};
 if ( exists( $_ucodes->{prid}->{$prid} ) ) {
-$vars{AVAIL} = sprintf( "0x%08x", $_ucodes->{prid}->{$prid} ),
-		print STDERR "$LOGPREF #$info->{processor} found ucode $vars{AVAIL}\n" if ($debug);
+$vars{AVAIL} = sprintf( "0x%08x", $_ucodes->{prid}->{$prid} );
+print STDERR "$LOGPREF #$info->{processor} found ucode $vars{AVAIL}\n" if ($debug);
 	}
 }
 
-- 
2.39.2

>From e85bfe33b595b88cc8052a7815d13612ecc2a841 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20B=C3=BChler?= 
Date: Sun, 28 May 2023 17:42:28 +0200
Subject: [PATCH] [uCode] fix uninitialized value in logging of processor index

This got broken in f8c2609f8d5a0e10bd988497b8ea9815a7bb2fa8.

Before that it would have effectively logged
`$processors{$pid}->{processor}`, but the `processor` entry
is also the key in `%processors`, i.e. equals `$pid`.
---
 perl/lib/NeedRestart/uCode.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/perl/lib/NeedRestart/uCode.pm b/perl/lib/NeedRestart/uCode.pm
index 6251339..db81375 100644
--- a/perl/lib/NeedRestart/uCode.pm
+++ b/perl/lib/NeedRestart/uCode.pm
@@ -148,7 +148,7 @@ sub nr_ucode_check {
 }
 $ui->progress_step;
 
-my $nstate = compare_ucode_versions( $debug, $processors{processor}, @nvars );
+my $nstate = compare_ucode_versions( $debug, $pid, @nvars );
 if ( $nstate > $state ) {
 ( $state, @vars ) = ( $nstate, @nvars );
 }
-- 
2.39.2

Bug#1000955: KDE Bug Update

[Christian Heller]

See my bug update at:
https://bugs.kde.org/show_bug.cgi?id=306352

Bug#1055999: python-asyncssh: CVE-2023-46446

[Salvatore Bonaccorso]

Source: python-asyncssh
Version: 2.10.1-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for python-asyncssh.

CVE-2023-46446[0]:
| An issue in AsyncSSH v2.14.0 and earlier allows attackers to control
| the remote end of an SSH client session via packet injection/removal
| and shell emulation.


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-46446
https://www.cve.org/CVERecord?id=CVE-2023-46446
[1] https://github.com/ronf/asyncssh/security/advisories/GHSA-c35q-ffpf-5qpm

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1055998: A warning with "ALSA LIB namehint.c: ..."

[Bjarni Ingi Gislason]

Package: einstein
Version: 2.0.dfsg.2-10+b1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Playing it.

   * What was the outcome of this action?

Many lines with:

ALSA Lib namehint.c:301:(try_config) (default) device must be an integer

   * What outcome did you expect instead?

No such messages.

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

Kernel: Linux 6.5.10-1 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages einstein depends on:
ii  libc62.37-12
ii  libfreetype6 2.13.2+dfsg-1
ii  libgcc-s1 [libgcc1]  13.2.0-5
ii  libsdl-mixer1.2  1.2.12-17+b3
ii  libsdl-ttf2.0-0  2.0.11-6
ii  libsdl1.2debian  1.2.68-1
ii  libstdc++6   13.2.0-5
ii  zlib1g   1:1.2.13.dfsg-3

einstein recommends no packages.

einstein suggests no packages.

-- no debconf information

Bug#1055997: fortunes-debian: [INTL:de] updated German po file translation

[Helge Kreutzmann]

Package: fortunes-debian
Version: 4.6.2
Severity: wishlist
Tags: patch l10n

Please find the updated German po file translation for fortunes-debian
attached.

If you update your template, please use 
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the 
German translation.

Greetings
Helge
# Translation of fortunes-debian hints to German
# Copyright (C):
# Alexander Schmehl 
# Helge Kreutzmann , 2008, 2010, 2011, 2023.
# This file is distributed under the same license as the fortunes-debian 
package.
#
msgid ""
msgstr ""
"Project-Id-Version: fortunes-debian 4.6.2\n"
"Report-Msgid-Bugs-To: Kartik Mistry \n"
"POT-Creation-Date: 2023-11-15 10:24+0530\n"
"PO-Revision-Date: 2023-11-15 21:22+0100\n"
"Last-Translator: Helge Kreutzmann \n"
"Language-Team: de \n"
"Language: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. type: Plain text
#: hints:5
#, no-wrap
msgid ""
"Debian Hint #1: You can report a bug in a package with the 'reportbug' 
command,\n"
"which is available in the reportbug package, either from the command-line or\n"
"with the new graphical frontend (available running 'reportbug --ui gtk' or 
in\n"
"the menu)."
msgstr "Debian-Tipp Nr. 1: Sie können einen Fehler in einem Programm mit dem 
Befehl »reportbug« aus dem Paket »reportbug« berichten, entweder von der 
Kommandozeile aus oder mit der neuen graphischen Oberfläche (verfügbar über 
»reportbug --ui gtk« oder aus dem Menü)."

#. type: Plain text
#: hints:10
#, no-wrap
msgid ""
"Debian Hint #2: You can use 'dpkg-reconfigure ' to change the\n"
"answers you gave to the questions asked when you first installed a package.\n"
"The 'configure-debian' package provides a unified front end for doing this,\n"
"as well."
msgstr "Debian-Tipp Nr. 2: Mit »dpkg-reconfigure « können Sie die 
Antworten, die Sie auf die Fragen bei der Erst-Installation des Paketes gegeben 
haben, ändern. Das Paket »configure-debian« stellt Ihnen hierfür eine 
zusätzliche Oberfläche zur Verfügung."

#. type: Plain text
#: hints:14
#, no-wrap
msgid ""
"Debian Hint #3: You can use either 'apt search ' or\n"
"'aptitude search ' to search for words in the descriptions of all\n"
"available packages."
msgstr "Debian-Tipp Nr. 3: Sie können mit entweder »apt-cache search 
« oder »aptitude search « die Beschreibungen aller 
Pakete nach Suchbegriffen durchsuchen."

#. type: Plain text
#: hints:17
#, no-wrap
msgid ""
"Debian Hint #4: You can see the available and installed versions for one\n"
"or more available packages with the command 'apt policy '."
msgstr "Debian-Tipp Nr. 4: Sie können sich die installierte und verfügbare 
Versionen eines oder mehrerer Pakete mit dem Befehl »apt-cache policy « 
anzeigen lassen."

#. type: Plain text
#: hints:20
#, no-wrap
msgid ""
"Debian Hint #5: If you need to build a custom kernel, use 'make bindeb-pkg'\n"
"in the Linux source tree."
msgstr "Debian-Tipp Nr. 5: Wenn Sie einen eigenen Kernel bauen müssen, sollten 
Sie »make bindeb-pkg« im Linux-Kernelquellbaum dafür benutzen."

#. type: Plain text
#: hints:22
#, no-wrap
msgid "Debian Hint #6: There is no hint #6. Submit a hint today!"
msgstr "Debian-Tipp Nr. 6: Es gibt keinen Tipp Nr. 6. Schicken Sie uns einen!"

#. type: Plain text
#: hints:26
#, no-wrap
msgid ""
"Debian Hint #7: You can use the unattended-upgrades or cron-apt packages\n"
"to do automatic nightly downloads of updates for packages installed on\n"
"your system."
msgstr "Debian-Tipp Nr. 7: Sie können das Paket cron-apt benutzen, um nachts 
automatisch Aktualisierungen für auf Ihrem System installierte Pakete 
herunterzuladen."

#. type: Plain text
#: hints:30
#, no-wrap
msgid ""
"Debian Hint #8: If you have problems with Debian that you can't solve by\n"
"reading the manuals and documentation, try asking on the Debian Users\n"
"mailing list (debian-u...@lists.debian.org)."
msgstr "Debian-Tipp Nr. 8: Falls Sie Probleme haben, die Sie trotz Lesens der 
Handbücher und Dokumentationen nicht lösen können, fragen Sie doch auf der 
Debian-User-German Mailing-Liste (debian-user-ger...@lists.debian.org)."

#. type: Plain text
#: hints:37
#, no-wrap
msgid ""
"Debian Hint #9: If you need to know what version of Debian you're currently\n"
"running, look in /etc/debian_version or use 'lsb_release -sc' command. If 
you\n"
"want to know the codename for that version (for example, 5.0 is codenamed\n"
"'Lenny'), check this URL:\n"
"\n"
"https://www.debian.org/doc/FAQ/ch-ftparchives.html#s-codenames;
msgstr "Debian-Tipp Nr. 9: Falls Sie die Debian-Version, die Sie gerade 
einsetzen, herausfinden möchten, können Sie in der Datei /etc/debian_version 
nachsehen oder den Befehl »lsb_release -sc« ausführen; der Codenamen der 
Version (5.0 wird beispielsweise »Lenny« genannt) finden Sie auf der folgenden 
Webseite:"

#. type: Plain text
#: hints:42
#, no-wrap
msgid ""
"Debian Hint #10: There are Debian 

Bug#1013285: needrestart: Failed to check for processor microcode upgrades.

[Antoine Beaupré]

On 2022-06-20 13:54:38, Nick Lewycky wrote:
> Package: needrestart
> Version: 3.6-1
> Severity: normal
>
> `sudo needrestart -w` always prints "Failed to check for processor
> microcode upgrades." on my AMD Ryzen 9 3900X 12-Core Processor.

[...]

There's now a PR for this upstream:

https://github.com/liske/needrestart/pull/285

People suffering from this issue are encouraged to test this and report
back upstream (or here, if you can't upstream).

I've also bumped the severity of this bug. For us it leads to alert
fatigue and creates security and reliability issues.

a.
-- 
Je viens d'un pays où engagé veut dire que tu t'es trouvé une job.
- Patrice Desbiens

Bug#1050417: lightdm-guest-session support (via Arctica Greeter) takes a long time to startup X11 guest sessions

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2023-08-24 at 10:25 +, Mike Gabriel wrote:
> +  /run/user/*/ICEauthority-l l,

Hi Mike,

are you sure about the `ICEauthority-l' filename (especially the -l part)? On
my system it's just ICEauthority apparently.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEyBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmVVIIoACgkQ3rYcyPpX
RFvRNQf4nVUolt6huD76ZT4EcpvIDVyX4VJjZ3v5tMIxdnzWZMmSQpxsAQcgfljm
zUzweJw0HczdKAbiP/0f9qDKWTEDUZ7IG7ORYz4S7V7ZCFz5IWt5x6V1styNWnlp
wXFXTm7BG7tzM8efXIaW3OANyWg3ewBnLzeqW4hSjOccB14VHqioP++sHOXG9w0b
ChWxCmR5jfd+wIPpluxvOVTcmMWZlirfTnc/nbUtUTa3LeBlBG+0butRQS+DrDjz
ZYFVPpo0rT37WoX+Ll49kyXGDMg2J22yQS4obdS1D/7ltcVZYtcec/w9gf+5B89s
1pC8mvbWE4zYhA94YmqzYarjb9Pa
=S4WQ
-END PGP SIGNATURE-

Bug#1055996: yt-dlp: CVE-2023-46121: Generic Extractor MITM Vulnerability via Arbitrary Proxy Injection

[Salvatore Bonaccorso]

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

Hi,

The following vulnerability was published for yt-dlp.

CVE-2023-46121[0]:
| yt-dlp is a youtube-dl fork with additional features and fixes. The
| Generic Extractor in yt-dlp is vulnerable to an attacker setting an
| arbitrary proxy for a request to an arbitrary url, allowing the
| attacker to MITM the request made from yt-dlp's HTTP session. This
| could lead to cookie exfiltration in some cases. Version 2023.11.14
| removed the ability to smuggle `http_headers` to the Generic
| extractor, as well as other extractors that use the same pattern.
| Users are advised to upgrade. Users unable to upgrade should disable
| the Ggneric extractor (or only pass trusted sites with trusted
| content) and ake caution when using `--no-check-certificate`.


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-46121
https://www.cve.org/CVERecord?id=CVE-2023-46121
[1] https://github.com/yt-dlp/yt-dlp/security/advisories/GHSA-3ch3-jhc6-5r8x
[2] 
https://github.com/yt-dlp/yt-dlp/commit/f04b5bedad7b281bee9814686bba1762bae092eb

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1055995: ITP: python-laszip -- Python bindings for LASzip

[Timo Röhling]

Package: wnpp
Severity: wishlist
Owner: Timo Röhling 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-laszip
  Version : 0.2.3
  Upstream Author : Thomas Montaigu
* URL : https://github.com/tmontaigu/laszip-python
* License : Expat
  Programming Lang: Python, C++
  Description : Python bindings for LASzip

This module provides LASzip bindings in Python, primarily intended for use
with laspy. LASzip is a specialized compression for the ASPRS LAS file format
to store data from LiDAR sensors much more efficiently.

The package will be team-maintained under the umbrella of the
Debian Python Team 
at https://salsa.debian.org/python-team/packages/python-laszip


-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmVVGKUACgkQ+C8H+466
LVlGCQwA3K3CGbqHT4sEWWRBkc2KrtTaY2IWbylUQjGaN+JyeEicBvNauYrLf2qy
Z69BOoUi2vFc8tQihmH+Ogi2wcENoZ9dtx1GrP89Jfz4rwY++1ylMpr3wjzRMYd+
ulu8rTPdu52GxaFracNMY4trNktP2hO8HpqKCPQ1lWJHGQyc/yASwD1ultV9PsgS
cPkAUwXcLyn3qyXzkCfNQEH1wOG69Zizh8dsqFi4ZfHRZ4iQC4X3SbRL3UtylYcr
FMu6ZsbZgiv3Y/+OmKbkGKX4kbw+OZU4wPCyhjBRZAR+d0UrNkBVzQkIEqH6rB3A
CKsjBdzohOQaeC6hfvyinC9VwWALFOy7HJVb9oY3UbS5gov1aKYoFMS+fhRH8EtB
VNLggfgpXKH9XusUE89i9TJR9943WdM2/Y4nu1Djc88GmxmP1R17UedXjmVDmBcc
cOAt19eOvvP9AzjTaYGwfquO3erPM+6HmRouX3zZWP+tOOICcwpMvekBX5gQTUWt
umj7J766
=V5l9
-END PGP SIGNATURE-

Bug#1055750: Bug#1055228: plplot: FTBFS on armhf (test segfault)

[Emanuele Rocca]

Hello Rafael!

On 2023-11-15 06:47, Rafael Laboissière wrote:
> Does this mean that the origin of the bug is upstream or that it still may
> be a bug in gfortran?

At this point we know for sure that the issue is not armhf-specific, and
also that it is not caused by stack-clash-protection. On the contrary,
enabling stack-clash-protection on armhf allowed us to discover a
problem that would have otherwise gone unnoticed.

Whether the bug is in plplot or gfortran I really have no idea. I would
tend not to think of a compiler issue unless we have some evidence in
that direction though, and suggest raising the issue with plplot
upstream. Showing them the x86 reproducer with -fsanitize=address should
be a good starting point.

Thanks,
  Emanuele

Bug#1055994: mdadm: Please restore cron scripts for use when systemd timers are not available

[Mark Hindley]

Package: mdadm
Version: 4.2+20230508-7
Severity: normal
Tags: patch

Dear Daniel,

As was discussed in #1037496, the removal of cron scripts from mdadm means that
no mdamd housekeeping is performed when systemd timers are not available.

I attach a patch which restores the cron scripts in mdadm, but protects them
with a test for running systemd. This should mean that housekeeping tasks are
performed an all systems, but that there is no duplication when systemd timers
are available.

I hope this is an acceptable compromise and I look forward to your comments.

With best wishes

Mark
>From 1f4b2370e6ffaab0b6352b893f268e0fa39df55b Mon Sep 17 00:00:00 2001
From: Mark Hindley 
Date: Tue, 14 Nov 2023 19:52:52 +
Subject: [PATCH] Restore cron fragments, but prefer systemd timers.

---
 debian/mdadm.cron.d  | 12 
 debian/mdadm.cron.daily  | 23 +++
 debian/mdadm.maintscript |  2 --
 debian/mdadm.postinst|  3 ++-
 4 files changed, 37 insertions(+), 3 deletions(-)
 create mode 100644 debian/mdadm.cron.d
 create mode 100644 debian/mdadm.cron.daily

diff --git a/debian/mdadm.cron.d b/debian/mdadm.cron.d
new file mode 100644
index 000..63f186d
--- /dev/null
+++ b/debian/mdadm.cron.d
@@ -0,0 +1,12 @@
+#
+# cron.d/mdadm -- schedules periodic redundancy checks of MD devices
+#
+# Copyright © martin f. krafft 
+# distributed under the terms of the Artistic Licence 2.0
+#
+
+# By default, run at 00:57 on every Sunday, but do nothing unless the day of
+# the month is less than or equal to 7. Thus, only run on the first Sunday of
+# each month. crontab(5) sucks, unfortunately, in this regard; therefore this
+# hack (see #380425).
+57 0 * * 0 root if [ -x /usr/share/mdadm/checkarray ] && [ ! -d /run/systemd/system ] && [ $(date +\%d) -le 7 ]; then /usr/share/mdadm/checkarray --cron --all --idle --quiet; fi
diff --git a/debian/mdadm.cron.daily b/debian/mdadm.cron.daily
new file mode 100644
index 000..8d1bfeb
--- /dev/null
+++ b/debian/mdadm.cron.daily
@@ -0,0 +1,23 @@
+#!/bin/sh
+#
+# cron.daily/mdadm -- daily check that MD devices are functional
+#
+# Copyright © 2008 Paul Slootman 
+# distributed under the terms of the Artistic Licence 2.0
+
+# As recommended by the manpage, run
+#  mdadm --monitor --scan --oneshot
+# every day to ensure that any degraded MD devices don't go unnoticed.
+# Email will go to the address specified in /etc/mdadm/mdadm.conf .
+#
+set -eu
+
+MDADM=/sbin/mdadm
+[ -x $MDADM ] || exit 0 # package may be removed but not purged
+
+[ -d /run/systemd/system ] || exit 0 # Defer to systemd timers if possible
+
+[ -e /etc/default/mdadm ] && . /etc/default/mdadm
+[ $AUTOSCAN = false ] && exit 0
+
+exec $MDADM --monitor --scan --oneshot
diff --git a/debian/mdadm.maintscript b/debian/mdadm.maintscript
index 17b5e28..1298978 100644
--- a/debian/mdadm.maintscript
+++ b/debian/mdadm.maintscript
@@ -1,4 +1,2 @@
-rm_conffile /etc/cron.d/mdadm 4.2+20230227-1~
-rm_conffile /etc/cron.daily/mdadm 4.2+20230227-1~
 rm_conffile /etc/init.d/mdadm 4.2+20230227-1~
 rm_conffile /etc/init.d/mdadm-waitidle 4.2+20230227-1~
diff --git a/debian/mdadm.postinst b/debian/mdadm.postinst
index c8a3420..021912a 100755
--- a/debian/mdadm.postinst
+++ b/debian/mdadm.postinst
@@ -76,7 +76,8 @@ AUTOCHECK=$AUTOCHECK
 
 # AUTOSCAN:
 #   should mdadm check once a day for degraded arrays? See
-#   /lib/systemd/system/mdmonitor-oneshot.service
+#   /lib/systemd/system/mdmonitor-oneshot.service and
+#   /etc/cron.daily/mdadm.
 AUTOSCAN=$AUTOSCAN
 
 # START_DAEMON:
-- 
2.39.2

Bug#1055750: Bug#1055228: plplot: FTBFS on armhf (test segfault)

[Rafael Laboissière]

Hi Emanuele,

Our messages crossed.

* Emanuele Rocca  [2023-11-15 18:20]:


On 2023-11-09 05:11, Rafael Laboissière wrote:

The Fortran example x09f.f90, which is exercised during the building of
plplot, now fails on armhf, due to the use of the compiler option
-fstack-clash-protection.


The problem seems unrelated to stach-clash-protection I think, enabling 
the feature on armhf just made it evident.


Building the program on a x86 system without -fstack-clash-protection 
but with -fsanitize=address, it segfaults:


/usr/bin/gfortran -g -O2 x09f.f90 -o x09f -I/usr/lib/x86_64-linux-gnu/fortran/modules/plplot -lplplotfortran -fsanitize=address 
./x09f -dev ps -o /dev/null


Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

The SIGSEGV happens in plplot_single::pltransformf2c, which is about 
where the SIGBUS happens on armhf with stack-clash-protector enabled:


 Program received signal SIGSEGV, Segmentation fault.
 0x75a000a8 in ?? ()
 (gdb) bt
 #0  0x75a000a8 in ?? ()
 #1  0x77f05683 in plplot_single::pltransformf2c (x=x@entry=0, 
y=y@entry=1, tx=4.9406564584124654e-324,
 ty=6.9533558054215925e-310, data=)
 at ./bindings/fortran/plplot_single.f90:114

Here's the SIGBUS on armhf with stack-clash-protection:

 Program received signal SIGBUS, Bus error.
 0x00400822 in x09f::mypltr (x=0, y=1, xt=0, yt=0) at x09f.f90:38
 38  xt = tr(1) * x + tr(2) * y + tr(3)
 (gdb) bt
 #0  0x00400822 in x09f::mypltr (x=0, y=1, xt=0, yt=0) at x09f.f90:38
 #1  0xf7f58a06 in plplot_single::pltransformf2c (x=, y=, tx=-9.8841854819221187e+269,
 ty=-nan(0xe5db40001), data=) at 
./bindings/fortran/plplot_single.f90:114


Does this mean that the origin of the bug is upstream or that it still 
may be a bug in gfortran?


Best,

Rafael Laboissière

Bug#1055750: gfortran: [armhf] Yield SIGBUS when compiling with -fstack-clash-protection

[Rafael Laboissière]

* Rafael Laboissière  [2023-11-15 18:37]:


* Rafael Laboissière  [2023-11-15 18:06]:

I have investigated the issue a little bit deeper. Please, find here 
attached a new tarball with a simplified version of the x09f.f90 
file, that still triggers the bug. Running the resulting executable 
with gbd, yields the following:


Oops, with the correct tarball this time.


Grrr, with the correct one now, hopefully!

R.


bug-1055750.tgz
Description: application/gtar-compressed

Bug#1028130: r-cran-hunspell: please don't use internal en_US and en_GB dictionaries

[Andreas Tille]

Control: tags -1 pending
Control: tags -1 upstream
Control: forwarded -1 https://github.com/ropensci/hunspell/issues/55

I've applied the patch and fixed the issue in Git.  However, there are
two test suite errors I'd like to discuss with upstream to possibly
find some solution before uploading (which would need excluding these
two tests).

Kind regards
   Andreas.

Bug#1055750: gfortran: [armhf] Yield SIGBUS when compiling with -fstack-clash-protection

[Rafael Laboissière]

* Rafael Laboissière  [2023-11-15 18:06]:

I have investigated the issue a little bit deeper. Please, find here 
attached a new tarball with a simplified version of the x09f.f90 file, 
that still triggers the bug. Running the resulting executable with 
gbd, yields the following:


Oops, with the correct tarball this time.

Best,

Rafael Laboissière


bug-1055750.tgz
Description: application/gtar-compressed

Bug#1055228: plplot: FTBFS on armhf (test segfault)

[Emanuele Rocca]

Hi!

On 2023-11-09 05:11, Rafael Laboissière wrote:
> The Fortran example x09f.f90, which is exercised during the building of
> plplot, now fails on armhf, due to the use of the compiler option
> -fstack-clash-protection.

The problem seems unrelated to stach-clash-protection I think, enabling
the feature on armhf just made it evident.

Building the program on a x86 system without -fstack-clash-protection
but with -fsanitize=address, it segfaults:

 /usr/bin/gfortran -g -O2 x09f.f90 -o x09f 
-I/usr/lib/x86_64-linux-gnu/fortran/modules/plplot -lplplotfortran 
-fsanitize=address
 ./x09f -dev ps -o /dev/null

 Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

The SIGSEGV happens in plplot_single::pltransformf2c, which is about
where the SIGBUS happens on armhf with stack-clash-protector enabled:

 Program received signal SIGSEGV, Segmentation fault.
 0x75a000a8 in ?? ()
 (gdb) bt
 #0  0x75a000a8 in ?? ()
 #1  0x77f05683 in plplot_single::pltransformf2c (x=x@entry=0, 
y=y@entry=1, tx=4.9406564584124654e-324, 
 ty=6.9533558054215925e-310, data=)
 at ./bindings/fortran/plplot_single.f90:114

Here's the SIGBUS on armhf with stack-clash-protection:

 Program received signal SIGBUS, Bus error.
 0x00400822 in x09f::mypltr (x=0, y=1, xt=0, yt=0) at x09f.f90:38
 38  xt = tr(1) * x + tr(2) * y + tr(3)
 (gdb) bt
 #0  0x00400822 in x09f::mypltr (x=0, y=1, xt=0, yt=0) at x09f.f90:38
 #1  0xf7f58a06 in plplot_single::pltransformf2c (x=, 
y=, tx=-9.8841854819221187e+269, 
 ty=-nan(0xe5db40001), data=) at 
./bindings/fortran/plplot_single.f90:114

Bug#1014045: source-is-missing doesn't seem to understand docbook

[Massimo Manghi]

Package: lintian
Version: 2.116.3
Followup-For: Bug #1014045

Dear Maintainer,

I'm the upstream developer/maintainer of Apache/Rivet. I'm also the maintainer 
of
the corresponding Debian package (libapache2-mod-rivet). 
Apache/Rivet source code ships with an HTML manual generated from
Docbook XML files. We regenerate the manual right before releasing and put it in
the tarball in order to save the Apache/Rivet user the task of figuring out 
what tools
are needed in order to recreate the HTML pages (being Docbook not so popular 
and not so
widely used now). Even though the XML source code for this manual is available 
in 
the source code lintian is unable to understand how HTML pages connect to 
their Docbook XML counterparts and this results in 74 lintian errors

 -- Massimo Manghi


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

Kernel: Linux 6.1.0-13-amd64 (SMP w/1 CPU thread; 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

Versions of packages lintian depends on:
ii  binutils2.41-6
ii  bzip2   1.0.8-5+b1
ii  diffstat1.65-1
ii  dpkg1.22.1
ii  dpkg-dev1.22.1
ii  file1:5.45-2
ii  gettext 0.21-13+b1
ii  gpg 2.2.40-1.1
ii  intltool-debian 0.35.0+20060710.6
ii  iso-codes   4.15.0-1
ii  libapt-pkg-perl 0.1.40+b2
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2+b1
ii  libcapture-tiny-perl0.48-2
ii  libclass-xsaccessor-perl1.19-4+b1
ii  libclone-perl   0.46-1
ii  libconfig-tiny-perl 2.30-1
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.37-1
ii  libdata-dpath-perl  0.59-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-2
ii  libdevel-size-perl  0.83-2+b1
pn  libdigest-sha-perl  
ii  libdpkg-perl1.22.1
ii  libemail-address-xs-perl1.05-1+b1
ii  libfile-basedir-perl0.09-2
ii  libfile-find-rule-perl  0.34-3
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-3
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.025-1
ii  libipc-run3-perl0.048-3
ii  libjson-maybexs-perl1.004005-1
ii  liblist-compare-perl0.55-2
ii  liblist-someutils-perl  0.59-1
ii  liblist-utilsby-perl0.12-2
ii  libmldbm-perl   2.05-4
ii  libmoo-perl 2.005005-1
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.144-1
ii  libperlio-gzip-perl 0.20-1+b1
ii  libperlio-utf8-strict-perl  0.010-1
ii  libproc-processtable-perl   0.636-1
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.004+ds-1
ii  libsereal-encoder-perl  5.004+ds-1
ii  libsort-versions-perl   1.62-3
ii  libsyntax-keyword-try-perl  0.29-1
ii  libterm-readkey-perl2.38-2+b1
ii  libtext-levenshteinxs-perl  0.03-5+b1
ii  libtext-markdown-discount-perl  0.16-1
ii  libtext-xslate-perl 3.5.9-1+b2
ii  libtime-duration-perl   1.21-2
ii  libtime-moment-perl 0.44-2+b1
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-2
ii  liburi-perl 5.21-1
ii  libwww-mechanize-perl   2.17-1
ii  libwww-perl 6.72-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1+b1
ii  libyaml-libyaml-perl0.86+ds-1
ii  lzip [lzip-decompressor]1.23-6
ii  lzop1.04-2
ii  man-db  2.12.0-1
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.36.0-9
ii  t1utils 1.41-4
ii  unzip   6.0-28
ii  xz-utils5.4.4-0.1

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
pn  libtext-template-perl  

-- no debconf information

Bug#1055750: gfortran: [armhf] Yield SIGBUS when compiling with -fstack-clash-protection

[Rafael Laboissière]

* Emanuele Rocca  [2023-11-14 12:01]:


On 2023-11-13 05:13, Rafael Laboissière wrote:

The attached file bug-1055750.tgz contains a minimal code that
triggers the bug on an armhf system


Thanks! For the record I can reproduce the issue in a armhf chroot, but 
*not* on armel and arm64. The only thing to change in the reproducer is 
the -I argument to gfortran:


 armhf: /usr/lib/arm-linux-gnueabihf
 armel: /usr/lib/arm-linux-gnueabi
 arm64: /usr/lib/aarch64-linux-gnu

I'll see if I can find out more.


Thanks for the followup, Emanuele.

I have investigated the issue a little bit deeper. Please, find here 
attached a new tarball with a simplified version of the x09f.f90 file, 
that still triggers the bug. Running the resulting executable with gbd, 
yields the following:


(gdb) run -dev ps -o /dev/null
Starting program: /home/rafael/bug-1055750/x09f -dev ps -o /dev/null
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/lib/arm-linux-gnueabihf/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
x09f::mypltr2 (x=0, y=1, xt=0, yt=7.300765e-43) at x09f.f90:48
48  yt = tr(1)

In this new code, there are two private functions mypltr1 and mypltr2. 
The bug only happens when the latter is invoked, in which a value coming 
from the global variable tr is assigned to yt. In mypltr1, the assignment 
is done to xt, instead of yt, and no segfault is triggered.


Best,

Rafael Laboissière


bug-1055750.tgz
Description: application/gtar-compressed

Bug#1055991: /usr/share/autofs/conffiles/auto.net: /etc/auto.net comments for nfsv4 are unclear

[Sam Morris]

Package: autofs
Version: 5.1.8-2+deb12u2
Severity: minor
File: /usr/share/autofs/conffiles/auto.net

Upstream /etc/auto.net looks like this:

  # add "nosymlink" here if you want to suppress symlinking local filesystems
  # add "nonstrict" to make it OK for some filesystems to not mount
  opts="-fstype=nfs,hard,nodev,nosuid"

15auto_net_nfs4.patch adds comments giving some nfsv4 advice:

   # add "nosymlink" here if you want to suppress symlinking local filesystems
   # add "nonstrict" to make it OK for some filesystems to not mount
  +# choose one of the two lines below depending on the NFS version in your
  +# environment
   opts="-fstype=nfs,hard,nodev,nosuid"
  +#opts="-fstype=nfs4,hard,nodev,nosuid,async"

Then fix-nfs4-mounts-in-auto-net.patch removes the the lints that set
opts, but leaves the comment in:

  --- a/samples/auto.net
  +++ b/samples/auto.net
  @@ -11,29 +11,44 @@
   # add "nonstrict" to make it OK for some filesystems to not mount
   # choose one of the two lines below depending on the NFS version in your
   # environment
  -opts="-fstype=nfs,hard,nodev,nosuid"
  -#opts="-fstype=nfs4,hard,nodev,nosuid,async"

As a result I was left scratching my head for a while wondering how to
use /etc/auto.net with nfsv4.

I suggest removing the comment block entirely and replacing it with
something like:

  # To use the traditional NFS MOUNT protocol for obtaining the NFS
  # export list, leave MOUNT_NFS_DEFAULT_PROTOCOL unset or set it to
  # "3". To use the NFSv4 pseudo-filesystem, set MOUNT_DEFAULT_PROTOCOL
  # to "4". The parameter may be set within /etc/default/autofs.

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

Kernel: Linux 6.1.0-13-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages autofs depends on:
ii  init-system-helpers  1.65.2
ii  libc62.36-9+deb12u3
ii  libnsl2  1.3.0-2
ii  libtirpc31.3.3+ds-1
ii  libxml2  2.9.14+dfsg-1.3~deb12u1
ii  ucf  3.0043+nmu1

Versions of packages autofs recommends:
ii  e2fsprogs   1.47.0-2
ii  kmod30+20221128-1
ii  nfs-common  1:2.6.2-4

autofs suggests no packages.

-- no debconf information

Bug#1055992: ITP: python-array-api-compat -- Python3 array API compatibility library

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: python-array-api-compat -- Python3 array API compatibility library
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: python-array-api-compat
  Version : 1.4
  Upstream Author : Consortium for Python Data API Standards
* URL : https://data-apis.org/array-api-compat/
* License : MIT
  Programming Lang: Python
  Description : Python3 array API compatibility library
 This is a small wrapper around common array libraries that is compatible
 with the Array API standard. Currently, NumPy, CuPy, and PyTorch are
 supported. If you want support for other array libraries, or if you
 encounter any issues, please open an issue.
 .
 Note that some of the functionality in this library is backwards
 incompatible with the corresponding wrapped libraries. The end-goal is
 to eventually make each array library itself fully compatible with the
 array API, but this requires making backwards incompatible changes in
 many cases, so this will take some time.
 .
 Currently all libraries here are implemented against the 2022.12 version
 of the standard.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/python-team/packages/python-array-api-compat

Bug#1055978: mtr-tiny: traceroute does not stop on subnet router anycast addresses

[Rogier Wolff]

Hi, 

What I meant with "trace" is a network dump. Like tcpdump or wireshark. 
What packet is coming back ? 

Roger. 


On Wed, Nov 15, 2023 at 03:40:25PM +0100, linux wrote:
> 
> Hi,
> 
> I aggree with you that it's not really a bug, anyways I thougt it could be 
> handled different by the program. Your proposal with the additional 
> "end-detection" would seem to work fine for this problem, below I presented 
> you the exact behavior in my test setup and attached some network traces and 
> a diagram of the setup.
> 
> I prepared a test setup and captured two traces of the network. The test 
> consists of three linux routers which are connected as follows: R1 <-> R2 <-> 
> R3 (see test_setup.png)
> 1st trace(intended_behavior.pcap) works as expected:
> From R1 to R3:
> mtr -c 1 2001:db8:0:3::1
> Host   
> Loss%   Snt   Last   Avg  Best  Wrst StDev
>  1. 2001:db8:0:1::2  
> 0.0% 1    1.0   1.0   1.0   1.0   0.0
>  2. 2001:db8:0:3::1  
> 0.0% 1    1.4   1.4   1.4   1.4   0.0
> 
> 2nd trace(unintended_behavior.pcap) does not stop, because I try to reach the 
> anycast address:
> mtr -c 1 2001:db8:0:3::
> Host                                                                       
> Loss%   Snt   Last   Avg  Best  Wrst StDev
>  1. 2001:db8:0:1::2                                                          
> 0.0%     1    1.0   1.0   1.0   1.0   0.0
>  2. 2001:db8:0:2::2                                                          
> 0.0%     1    1.5   1.5   1.5   1.5   0.0
>  3. 2001:db8:0:2::2                                                          
> 0.0%     1    1.3   1.3   1.3   1.3   0.0
>  4. 2001:db8:0:2::2                                                          
> 0.0%     1    1.5   1.5   1.5   1.5   0.0
>  5. 2001:db8:0:2::2                                                          
> 0.0%     1    1.5   1.5   1.5   1.5   0.0
>  6. 2001:db8:0:2::2                                                          
> 0.0%     1    1.0   1.0   1.0   1.0   0.0
>  7. 2001:db8:0:2::2                                                          
> 0.0%     1    1.5   1.5   1.5   1.5   0.0
>  8. 2001:db8:0:2::2                                                          
> 0.0%     1    1.2   1.2   1.2   1.2   0.0
>  9. 2001:db8:0:2::2                                                          
> 0.0%     1    1.4   1.4   1.4   1.4   0.0
> 10. 2001:db8:0:2::2                                                          
> 0.0%     1    1.2   1.2   1.2   1.2   0.0
> 11. 2001:db8:0:2::2                                                          
> 0.0%     1    1.3   1.3   1.3   1.3   0.0
> 12. 2001:db8:0:2::2                                                          
> 0.0%     1    1.4   1.4   1.4   1.4   0.0
> 13. 2001:db8:0:2::2                                                          
> 0.0%     1    1.2   1.2   1.2   1.2   0.0
> 14. 2001:db8:0:2::2                                                          
> 0.0%     1    1.3   1.3   1.3   1.3   0.0
> 15. 2001:db8:0:2::2                                                          
> 0.0%     1    1.5   1.5   1.5   1.5   0.0
> 16. 2001:db8:0:2::2                                                          
> 0.0%     1    1.1   1.1   1.1   1.1   0.0
> 17. 2001:db8:0:2::2                                                          
> 0.0%     1    1.5   1.5   1.5   1.5   0.0
> 18. 2001:db8:0:2::2                                                          
> 0.0%     1    1.3   1.3   1.3   1.3   0.0
> 19. 2001:db8:0:2::2                                                          
> 0.0%     1    1.5   1.5   1.5   1.5   0.0
> 20. 2001:db8:0:2::2                                                          
> 0.0%     1    1.5   1.5   1.5   1.5   0.0
> 21. 2001:db8:0:2::2                                                          
> 0.0%     1    1.3   1.3   1.3   1.3   0.0
> 22. 2001:db8:0:2::2                                                          
> 0.0%     1    1.5   1.5   1.5   1.5   0.0
> 23. 2001:db8:0:2::2                                                          
> 0.0%     1    1.3   1.3   1.3   1.3   0.0
> 24. 2001:db8:0:2::2                                                          
> 0.0%     1    1.5   1.5   1.5   1.5   0.0
> 25. 2001:db8:0:2::2                                                          
> 0.0%     1    1.4   1.4   1.4   1.4   0.0
> 26. 2001:db8:0:2::2                                                          
> 0.0%     1    1.2   1.2   1.2   1.2   0.0
> 27. 2001:db8:0:2::2                                                          
> 0.0%     1    1.4   1.4   1.4   1.4   0.0
> 28. 2001:db8:0:2::2                                                          
> 0.0%     1    1.2   1.2   1.2   1.2   0.0
> 29. 2001:db8:0:2::2                                                          
> 0.0%  

Bug#1055983: geany-plugins: diff for NMU version 2.0-2.1

[Bastian Germann]

Control: retitle -1 geany-plugins: diff for NMU versions 2.0-2.1, 2.0-2.2

This NMU fixes a RC bug that was introduced with 2.0.diff -Nru geany-plugins-2.0/debian/changelog geany-plugins-2.0/debian/changelog
--- geany-plugins-2.0/debian/changelog  2023-11-15 12:28:36.0 +0100
+++ geany-plugins-2.0/debian/changelog  2023-11-15 16:10:58.0 +0100
@@ -1,3 +1,10 @@
+geany-plugins (2.0-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Enable building arch-all packages (Closes: #1055990)
+
+ -- Bastian Germann   Wed, 15 Nov 2023 16:10:58 +0100
+
 geany-plugins (2.0-2.1) unstable; urgency=medium
 
   * Non-maintainer upload
diff -Nru geany-plugins-2.0/debian/rules geany-plugins-2.0/debian/rules
--- geany-plugins-2.0/debian/rules  2023-11-15 12:28:36.0 +0100
+++ geany-plugins-2.0/debian/rules  2023-11-15 16:10:58.0 +0100
@@ -95,8 +95,7 @@
find debian/tmp/ -name '*.pyc' -delete
dh_install
 
-override_dh_installdocs:
-   dh_installdocs
+execute_after_dh_installdocs-arch:
cd 
$(CURDIR)/debian/geany-plugin-latex/usr/share/doc/geany-plugin-latex/ && \
ls -1 *.html |  
\
while read -r file; do  
\

Bug#1055901: [Pkg-raspi-maintainers] Bug#1055901: raspi-firmware: postinst fails, makes bad assumption about existence of /boot/firmware/

[Cyril Brulebois]

ilf  (2023-11-15):
> reopen 1055901
> found 1055901 1:1.20231024+ds-1+rpt2
> 
> This seems to hit everyone with a Rasperry Pi who upgraded
> Debian/Raspian from bullseye to bookworm.

If a Raspbian package doesn't work on Raspbian systems, is the Debian
bug tracking system really the best place?


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/


signature.asc
Description: PGP signature

Bug#1055990: geany-plugins: FTBFS with build=all

[Bastian Germann]

Source: geany-plugins
Version: 2.0-2
Severity: serious

The packages fails to build from souce for build=all builds:
dh_installdocs
cd debian/geany-plugin-latex/usr/share/doc/geany-plugin-latex/ && \
ls -1 *.html |  
\
while read -r file; do  
\
iconv --from=iso-8859-1 --to=utf-8 "$file" |   \
sponge "$file";\
done
/bin/sh: 1: cd: can't cd to 
debian/geany-plugin-latex/usr/share/doc/geany-plugin-latex/

Bug#1055971: atril: should not use the filename extension to determine the file type

[Vincent Lefevre]

Control: forwarded -1 https://github.com/mate-desktop/atril/issues/595

I've just reported a bug upstream.

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

Bug#1055919: python-ansible-pygments: please make the build reproducible

[Holger Levsen]

On Wed, Nov 15, 2023 at 01:31:26PM +, Chris Lamb wrote:
> I would be more than willing to conclude that this is an issue in
> tests.reproducible-builds.org setup. However, I am actually seeing
> these test files when I build locally as well — and my patch
> consequently fixes the "problem". Moreover, I am not using the same
> setup as tests.reproducible-builds.org at all. (Can you confirm whether
> you see them when building locally?)

tests.r-b.o is using pbuilder, while the buildds use sbuild. what do you use?


-- 
cheers,
Holger

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

Privacy is a Human Right. (Universal Declaration of Human Rights, article 12.)


signature.asc
Description: PGP signature

Bug#1055901: raspi-firmware: postinst fails, makes bad assumption about existence of /boot/firmware/

[ilf]

reopen 1055901
found 1055901 1:1.20231024+ds-1+rpt2

This seems to hit everyone with a Rasperry Pi who upgraded 
Debian/Raspian from bullseye to bookworm.


https://forums.raspberrypi.com/viewtopic.php?p=2157290 has a workaround:


1. Unmount the boot partition with `sudo umount /boot`
2. Create the new firmware directory: `sudo mkdir /boot/firmware`
3. Edit `/etc/fstab`, with `sudo nano /etc/fstab`, and replace `/boot` 
   to `/boot/firmware`; exit and save with `Ctrl+x` then Y then Enter.

4. Run `sudo systemctl daemon-reload`
5. Remount the boot partition again with `sudo mount -a`
6. Fix the installation, with `sudo apt-get dist-upgrade` and/or `sudo 
   apt-get -f install`.


Would be great if the package did that automatically.

Looks like someone might be working on this: 
https://github.com/MichaIng/DietPi/issues/6747


--
ilf

If you upload your address book to "the cloud", I don't want to be in it.

Bug#1055978: mtr-tiny: traceroute does not stop on subnet router anycast addresses

[linux]

Hi,

I aggree with you that it's not really a bug, anyways I thougt it could be 
handled different by the program. Your proposal with the additional 
"end-detection" would seem to work fine for this problem, below I presented you 
the exact behavior in my test setup and attached some network traces and a 
diagram of the setup.

I prepared a test setup and captured two traces of the network. The test 
consists of three linux routers which are connected as follows: R1 <-> R2 <-> 
R3 (see test_setup.png)
1st trace(intended_behavior.pcap) works as expected:
>From R1 to R3:
mtr -c 1 2001:db8:0:3::1
Host   
Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 2001:db8:0:1::2  
0.0% 1    1.0   1.0   1.0   1.0   0.0
 2. 2001:db8:0:3::1  
0.0% 1    1.4   1.4   1.4   1.4   0.0

2nd trace(unintended_behavior.pcap) does not stop, because I try to reach the 
anycast address:
mtr -c 1 2001:db8:0:3::
Host                                                                       
Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 2001:db8:0:1::2                                                          
0.0%     1    1.0   1.0   1.0   1.0   0.0
 2. 2001:db8:0:2::2                                                          
0.0%     1    1.5   1.5   1.5   1.5   0.0
 3. 2001:db8:0:2::2                                                          
0.0%     1    1.3   1.3   1.3   1.3   0.0
 4. 2001:db8:0:2::2                                                          
0.0%     1    1.5   1.5   1.5   1.5   0.0
 5. 2001:db8:0:2::2                                                          
0.0%     1    1.5   1.5   1.5   1.5   0.0
 6. 2001:db8:0:2::2                                                          
0.0%     1    1.0   1.0   1.0   1.0   0.0
 7. 2001:db8:0:2::2                                                          
0.0%     1    1.5   1.5   1.5   1.5   0.0
 8. 2001:db8:0:2::2                                                          
0.0%     1    1.2   1.2   1.2   1.2   0.0
 9. 2001:db8:0:2::2                                                          
0.0%     1    1.4   1.4   1.4   1.4   0.0
10. 2001:db8:0:2::2                                                          
0.0%     1    1.2   1.2   1.2   1.2   0.0
11. 2001:db8:0:2::2                                                          
0.0%     1    1.3   1.3   1.3   1.3   0.0
12. 2001:db8:0:2::2                                                          
0.0%     1    1.4   1.4   1.4   1.4   0.0
13. 2001:db8:0:2::2                                                          
0.0%     1    1.2   1.2   1.2   1.2   0.0
14. 2001:db8:0:2::2                                                          
0.0%     1    1.3   1.3   1.3   1.3   0.0
15. 2001:db8:0:2::2                                                          
0.0%     1    1.5   1.5   1.5   1.5   0.0
16. 2001:db8:0:2::2                                                          
0.0%     1    1.1   1.1   1.1   1.1   0.0
17. 2001:db8:0:2::2                                                          
0.0%     1    1.5   1.5   1.5   1.5   0.0
18. 2001:db8:0:2::2                                                          
0.0%     1    1.3   1.3   1.3   1.3   0.0
19. 2001:db8:0:2::2                                                          
0.0%     1    1.5   1.5   1.5   1.5   0.0
20. 2001:db8:0:2::2                                                          
0.0%     1    1.5   1.5   1.5   1.5   0.0
21. 2001:db8:0:2::2                                                          
0.0%     1    1.3   1.3   1.3   1.3   0.0
22. 2001:db8:0:2::2                                                          
0.0%     1    1.5   1.5   1.5   1.5   0.0
23. 2001:db8:0:2::2                                                          
0.0%     1    1.3   1.3   1.3   1.3   0.0
24. 2001:db8:0:2::2                                                          
0.0%     1    1.5   1.5   1.5   1.5   0.0
25. 2001:db8:0:2::2                                                          
0.0%     1    1.4   1.4   1.4   1.4   0.0
26. 2001:db8:0:2::2                                                          
0.0%     1    1.2   1.2   1.2   1.2   0.0
27. 2001:db8:0:2::2                                                          
0.0%     1    1.4   1.4   1.4   1.4   0.0
28. 2001:db8:0:2::2                                                          
0.0%     1    1.2   1.2   1.2   1.2   0.0
29. 2001:db8:0:2::2                                                          
0.0%     1    1.4   1.4   1.4   1.4   0.0
30. 2001:db8:0:2::2                                                          
0.0%     1    1.4   1.4   1.4   1.4   0.0


On Wednesday, November 15, 2023 11:15 CET, Rogier Wolff 
 wrote:
 Hi,

I'd say this is an unwanted side-effect rather than a bug.

I'd say the "end-detection" might also consider three times the 

Bug#1055927: grub2: Can't upgrade to v. 2.12~rc1-12 due to missing dependency

[Domenico Cufalo]

Package: grub2
Followup-For: Bug #1055927

Dear Maintainer,

please, close this bug report and sorry!

The packages have just been upgraded.

Many thanks,
DC


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

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

Versions of packages grub2 depends on:
ii  grub-common  2.12~rc1-12
pn  grub-pc  

grub2 recommends no packages.

grub2 suggests no packages.

Bug#1055989: emacs-gtk: emacs rejects font preference, falls back to "Purisa" font

[Christoph Reichenbach]

Package: emacs-gtk
Version: 1:29.1+1-5
Severity: important
Tags: patch
X-Debbugs-Cc: creic...@gmail.com

Dear Maintainer,

  (This is a resubmission; the previous bug may have been lost to spam
filtering.)

  As of the upgrade to 29.1 on 2023-09-06, Emacs seems to be
disregarding some user preferences for the font for the "default"
face.

* What led up to the situation?

The upgrade to Emacs 29.1 on 2023-09-06. 

* What exactly did you do (or not do) that was effective (or ineffective)?

Executing the following steps:

- (customize-face 'default)
  - Font Family: setting "Terminus (TTF)"
  - Font Foundry: setting "PfEd"
  - Optionally (does not affect outcome):
- Weight: setting "medium"
- Disabling any font attributes (inlcuding Weight)
  - [Apply]

Equivalently:
(custom-set-faces
 '(default ((t (:inherit nil :extend nil :stipple nil :background "black" 
:foreground "white" :inverse-video nil :box nil :strike-through nil :overline 
nil :underline nil :slant normal :weight medium :height 120 :width normal 
:foundry "PfEd" :family "Terminus (TTF)"
 )

* What was the outcome of this action?

Emacs used the "Purisa" font as default font.  This font has the same Font
Foundry as "Terminus (TTF)" but is a "Comic Sans"-like special-purpose font
and unsuitable for normal operations.

* What outcome did you expect instead?

I expected Emacs 29.1 to honour my configuration settings, as Emacs 28 did
before.

* Observations

- This only affects the default face.  Based on my attempte to debug the
  problem (see below), the bug is caused by special treatment for the
  default face.
- This bug is likely related to #1029710, which was reported at the same
  time as my original (regrettably spam-filtered?) report.
- I have narrowed down the bug somewhat (see below) and am using a
  local workaround.
- This issue affects emacs-gtk and emacs-pgtk equally.
- This issue affects X11 and wayland equally.

* Debugging results

** Why this seems to happen

Here is the flow of events that leads to the problem, to the best of
my (very limited) understanding:

1. At some point, the font spec for the default face is set up
2. I set my preferences for the default face
3. My preferences are applied to the default face spec in some order
4. During "Font Family" selection, the following happens at some point:
  a) While searching for suitable fonts, Emacs calls font_list_entities(f, spec)
  b) font_list_entities(f, spec) (font.c, L2540) does some
   preprocessing and then:
 1. asks the driver for a list `vec' of suitable fonts (L2585)
 2. and filters out unsuitable fonts (L2602), calling
  c) font_delete_unmatched(vec, spec, size) in turn scans the `vec' to
   remove elements that don't match `spec'.
1. Specifically, for properties like font weight
   (FONT_WEIGHT_INDEX), L2486 checks if the requested property is
   an exact match and otherwise removes the candidate (L2502).
2. I assume that L2477 skips checks for properties that are left
   unconstrained (nil) in the spec but have not verified that.

The unexpected behaviour happens at 4.c:

4.c.2 always seems to allow filtering by font weight, no matter what I
  select in the font face

4.c.1 always seems to require a font weigth of 80 ("regular"), no
  matter what I select in the font face interface.

I have tried to investigate further to check:

- Does the wrong weight come from a hardcoded value?
- Does the wrong weight come from a stale font spec attribute?

*** Hardcoded value?

I tried modifying the `font_weights' table in font.c, but was only
able to "fix" the behaviour by entirely removing the entry for
weight 80.  My interpretation is that the value "80" probably comes
from one of the default fallback fonts and is accidentally retained in
the font spec (i.e., the weight doesn't seem to be hardcoded
anywhere in Emacs).

*** Stale font attribute?

I traced the calls to `internal-set-lisp-face-attribute' immediately
after updating the font.  Below is the order in which the attributes
are set (some appear more than once):

  :underline
  :overline
  :strike-through
  :box
  :inverse-video
  :stipple
  :inherit
  :extend
  :family
  :foundry
  :inherit
  :extend
  :stipple
  :background
  :foreground
  :inverse-video
  :box
  :strike-through
  :overline
  :underline
  :slant
  :weight
  :height
  :width

Note how :family is set before :weight is updated (to the correct
value):

- After setting :family, the font spec is associated with a font
  object for the "Purisa" font, but at least retains :family
  (of the font that I requested).

- Once :weight is updated, internal-set-lisp-face-attribute calls
  set_font_frame_param(), at which point :family becomes "nil".


My current interpretation (based on the above) is that
font_list_entities() gets called after the "Font Family" entry has
been updated in the `spec' but before the weight is updated; instead,
the spec probably inherits the weight of the current font for the
default face, 

Bug#967812: wmhdplop: depends on deprecated GTK 2

[Bastian Germann]

Control: tags -1 patch

Am 09.09.23 um 16:01 schrieb Bastian Germann:

Please drop gkrellm-hdplop and replace the Build-Depends: libgtk2.0-dev with 
pkg-config.


I am including a patch that implements the suggestion.diff -Nru wmhdplop-0.9.12/debian/changelog wmhdplop-0.9.12/debian/changelog
--- wmhdplop-0.9.12/debian/changelog2022-08-26 18:43:19.0 +0200
+++ wmhdplop-0.9.12/debian/changelog2023-11-15 14:40:02.0 +0100
@@ -1,3 +1,10 @@
+wmhdplop (0.9.12-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop gkrellm-hdplop (Closes: #967812).
+
+ -- Bastian Germann   Wed, 15 Nov 2023 14:40:02 +0100
+
 wmhdplop (0.9.12-1) unstable; urgency=medium
 
   * New upstream version 0.9.12 (closes: #1018022)
diff -Nru wmhdplop-0.9.12/debian/control wmhdplop-0.9.12/debian/control
--- wmhdplop-0.9.12/debian/control  2022-08-26 18:36:31.0 +0200
+++ wmhdplop-0.9.12/debian/control  2023-11-15 14:40:02.0 +0100
@@ -5,8 +5,7 @@
 Uploaders: Doug Torrance ,
Jeremy Sowden 
 Build-Depends: debhelper-compat (= 13),
-   gkrellm,
-   libgtk2.0-dev,
+   pkg-config,
libimlib2-dev,
libx11-dev,
libxext-dev,
@@ -27,14 +26,3 @@
  openoffice and enjoy the wmhdplop show.
  .
  wmhdplop is a dockapp for Window Maker.
-
-Package: gkrellm-hdplop
-Architecture: linux-any
-Depends: ${misc:Depends}, ${shlibs:Depends}
-Recommends: fonts-freefont-ttf
-Description: hard drive activity monitor GKrellM plugin
- It monitors your hard drives by sending visual stimuli to your cortex
- each time your /dev/hdx writes or reads anything. Try to launch
- openoffice and enjoy the wmhdplop show.
- .
- gkrellm-hdplop is a port of wmhdplop for grkellm.
diff -Nru wmhdplop-0.9.12/debian/gkrellm-hdplop.install 
wmhdplop-0.9.12/debian/gkrellm-hdplop.install
--- wmhdplop-0.9.12/debian/gkrellm-hdplop.install   2022-08-26 
18:36:31.0 +0200
+++ wmhdplop-0.9.12/debian/gkrellm-hdplop.install   1970-01-01 
01:00:00.0 +0100
@@ -1 +0,0 @@
-gkhdplop.so usr/lib/gkrellm2/plugins
diff -Nru wmhdplop-0.9.12/debian/rules wmhdplop-0.9.12/debian/rules
--- wmhdplop-0.9.12/debian/rules2022-08-26 18:36:31.0 +0200
+++ wmhdplop-0.9.12/debian/rules2023-11-15 14:40:02.0 +0100
@@ -5,5 +5,8 @@
 %:
dh $@
 
+override_dh_auto_configure:
+   dh_auto_configure -- --disable-gkrellm
+
 override_dh_auto_build:
dh_auto_build -- CPPFLAGS="$(CPPFLAGS) $(CFLAGS)"
diff -Nru wmhdplop-0.9.12/debian/wmhdplop.install 
wmhdplop-0.9.12/debian/wmhdplop.install
--- wmhdplop-0.9.12/debian/wmhdplop.install 2022-08-26 18:36:31.0 
+0200
+++ wmhdplop-0.9.12/debian/wmhdplop.install 1970-01-01 01:00:00.0 
+0100
@@ -1,3 +0,0 @@
-usr/bin/wmhdplop
-usr/share/applications/wmhdplop.desktop
-usr/share/man/man1/wmhdplop.1

Bug#1051432: further info

[Terrance Hendrik]

Thank you, Iwanmatsu san!

But no luck,still logs

```
Nov 14 21:44:49  blueman-manager[10028]: blueman-manager 21.44.49
WARNING  ManagerDeviceList:396 _monitor_power_levels: Failed to get power
levels, probably a LE device.
Nov 14 21:44:49  bluetoothd[9996]: src/service.c:service_accept()
input-hog profile accept failed for 
Nov 14 21:44:51  bluetoothd[9996]: src/service.c:service_accept()
input-hog profile accept failed for 
```
I uncommented those lines and restarted bluetooth.service.

Also tried adding `--experimental` to service execstart, only gets worse.

Strangely, other 3 computers running almost the same kernel 6.3-6.5 and
bluez 5.6x - 5.70, logi mice work perfectly fine.

On Mon, Oct 23, 2023 at 11:10 PM Nobuhiro Iwamatsu 
wrote:

> Hi,
>
> 2023年9月8日(金) 6:57 Terrance Hendrik :
> >
> > bluetoothctl
> >
> > [MX Anywhere 3]# info
> > Device E5:9F:06:B5:08:8D (random)
> > Name: MX Anywhere 3
> > Alias: MX Anywhere 3
> > Appearance: 0x03c2 (962)
> > Icon: input-mouse
> > Paired: yes
> > Bonded: yes
> > Trusted: yes
> > Blocked: no
> > Connected: yes
> > WakeAllowed: no
> > LegacyPairing: no
> > UUID: Generic Access Profile(1800--1000-8000-00805f9b34fb)
> > UUID: Generic Attribute Profile (1801--1000-8000-00805f9b34fb)
> > UUID: Device Information(180a--1000-8000-00805f9b34fb)
> > UUID: Battery Service   (180f--1000-8000-00805f9b34fb)
> > UUID: Human Interface Device(1812--1000-8000-00805f9b34fb)
> > UUID: Vendor specific   (0001--1000-8000-011f246d)
> > Modalias: usb:v046DpB025d0014
> > Battery Percentage: 0x4b (75)
>
> Could you please set ClassicBondedOnly=true and LEAutoSecurity=true in
> /etc/bluetooth/input.conf and check?
>
> ```
> [General]
> ClassicBondedOnly = true
> LEAutoSecurity = true
> ```
>
> Best regards,
>   Nobuhiro
>
>
>
> --
> Nobuhiro Iwamatsu
>iwamatsu at {nigauri.org / debian.org / kernel.org}
>GPG ID: 32247FBB40AD1FA6
>

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

[Bálint Réczey]

Hi Colin,

There are a few upstream source files licensed under GPL.
Please update debian/copyright to cover all the used licenses.

You can run 'cme update dpkg-copyright' in the source directory or any
other tool from https://wiki.debian.org/CopyrightReviewTools to help with
the manual labor.

Cheers,
Balint

On 2023. Nov 15., Wed at 10:27, Bálint Réczey 
wrote:

> Hi Colin,
>
> Colin King (gmail)  ezt írta (időpont: 2023.
> nov. 14., K, 17:58):
> >
> > Hi Balint,
> >
> > I've uploaded 0.4.0-2 with the suggested fixes.
> >
> > reply inlined below:
> >
> > On 09/11/2023 16:23, Bálint Réczey wrote:
> > > Hi Colin,
> > >
> > > Colin King (gmail)  ezt írta (időpont: 2023.
> > > nov. 7., K, 15:18):
> > >>
> > >> Hi Balint,
> > >>
> > >> Thanks for responding with the review. I was waiting for the upstream
> > >> project to release a 0.4 with some minor fixes before re-uploading to
> > >> mentors.
> > >>
> > >> I've addressed the issues you found as below:
> > >
> > > Please see my observations below.
> > >
> > >> On 22/10/2023 22:38, Bálint Réczey wrote:
> > >>> Hi Colin,
> > >>>
> > >>> I've checked the second upload at [1].
> > >>> As you can see in the Lintian warnings there is a .git directory
> which
> > >>> is not ideal for a source package.
> > >>> I suggest using the most widely used git-buildpackage based workflow
> > >>> where the gbp command takes care of exporting the source package
> > >>> without the .git dir from the packaging repository.
> > >>> I'd be happy to set up a packaging repo for you at
> > >>> https://salsa.debian.org/debian/libtypec and add you as a maintainer
> > >>> as described in [2]
> > >
> > > I still hold up my offer about setting up a git repo for packaging on
> > > Salsa. That comes with the benefit of automated fixes from Debian
> > > Janitor and I could also comment on changes right where they happened.
> >
> > Thank you for your kind offer; I definitely think this is a good idea,
> > please can you set this up for me. Much appreciated!
>
> I've created the repo at https://salsa.debian.org/debian/libtypec and
> added you as a maintainer.
> I've also set up CI, thus when you push your branches the pipelines will
> start.
>
> You may already be familiar with
> https://dep-team.pages.debian.net/deps/dep14/ , but if not, please
> check it before pushing your packaging repository.
>
> ...
>
> > > I think my comment here was misleading, sorry for that.
> > > Shipping *.pc is desired, shipping it in the .../libtypec.pc/ dir as a
> > > result of specifying .../libtypec.pc as the target dir in the .install
> > > file was not desired. It was even patched to have the right content.
> > > Please ship the .pc file in the -dev package.
> >
> > Fixed.
>
> The .pc file is now at the right location, but contains multiarch
> strings which will differ across architectures.
> I suggest hardcoding the paths in the patch.
>
> ...
>
> > > * As you switched back to use upstream's 0.4.0 SO version the .symbols
> > > file became wrong  not matching the shipped SO version. Please fix
> > > that and also switch to the libtypec0 package name since it needs to
> > > match upstream's major SO version
> >
> > Fixed.
>
> The .symbols file's first line should be:
>  libtypec.so.0 libtypec0 #MINVER#
>
> See deb-symbols(5) for more details.
>
> > .
> > >
> > > * I'd recommend asking upstream to switch to semantic SO versioning
> > > instead of using the project's version and switching to major version
> > > 1 when the API stabilized.
> >
> > Good idea. Will do when API changes and stabilizes.
>
> Great!
>
> Cheers,
> Balint
>
> > Colin
> >
> > >
> > > Cheers,
> > > Balint
> > >
> > >> Kind regards,
> > >>
> > >> Colin
> > >>
> > >>
> > >>> Cheers,
> > >>> Balint
> > >>>
> > >>> [1] https://mentors.debian.net/package/libtypec/
> > >>> [2]
> https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group
> > >>>
> > >>> On Thu, 3 Aug 2023 17:00:58 +0100 "Colin King (gmail)"
> > >>>  wrote:
> >  Hi,
> > 
> >  I've uploaded a fixed package that addresses these issues.
> > 
> >  Colin
> > 
> >  On 18/07/2023 08:50, Adam Borowski wrote:
> > > On Mon, Jul 17, 2023 at 03:29:13PM +0100, Colin King (gmail) wrote:
> > >> * Package name : libtypec
> > >>   Version  : 0.3-1
> > >> * URL  :
> https://github.com/Rajaram-Regupathy/libtypec
> > >
> > >>  libtypec1 - generic interface for efficient USB-C port
> management
> > >>  libtypec-dev - Development files for an interface for USB-C
> port management
> > >
> > >> libtypec (0.3-1) unstable; urgency=low
> > >> .
> > >>   * Initial release (Closes: #1023477)
> > >>   * Add patch 0001-fix-libtypec-so-version.patch to fix .so
> name version
> > >
> > > Hi!
> > > Before doing manual review, let's start with lintian:
> > >
> > > E: libtypec1: pkg-config-multi-arch-wrong-dir full text contains
> 

Bug#1051296: freecad: Crashes when creating/opening a file.

[Maxime Chambonnet]

Package: freecad
Version: 0.20.2+dfsg1-10
Followup-For: Bug #1051296
X-Debbugs-Cc: max...@maxzor.eu

Dear Maintainer,

I have the same problem with GNOME wayland on trixie.
Unsetting the environment variable as proposed in the linked
github issue solved it for me too.

BR, Maxime


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

Kernel: Linux 6.5.0-4-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 freecad depends on:
ii  freecad-python3  0.20.2+dfsg1-10

Versions of packages freecad recommends:
ii  calculix-ccx2.20-1
ii  graphviz2.42.2-7+b3
ii  python3-opencamlib  2023.01.11-4

Versions of packages freecad suggests:
pn  povray  

-- no debconf information

Bug#1055981: wmforecast: Does not retrieve data; shows error

[Jeremy Sowden]

Control: reassign -1 libgweather4

On 2023-11-15, at 11:57:30 +0200, Yavor Doganov wrote:
> Package: wmforecast
> Version: 1.9.0-1
> Severity: grave
> X-Debbugs-Cc: Yavor Doganov 
> 
> Since some time (about 2 weeks, but I'm not entirely sure) wmforecast
> displays an image with a question mark along with the text "ERROR".  The
> following message(s) appear on the console:
> 
> $ LC_ALL=C wmforecast
> GWeather-Message: 11:51:41.964: Failed to get weather.gov point data: 
> [status: 404] Not Found
> GWeather-Message: 11:52:41.353: Failed to get weather.gov point data: 
> [status: 404] Not Found
> GWeather-Message: 11:53:41.349: Failed to get weather.gov point data: 
> [status: 404] Not Found
> 
> (process:179771): GWeather-WARNING **: 11:54:40.649: Failed to get METAR 
> data: HTTP/2 Error: NO_ERROR
> 
> My ~/GNUstep/Defaults/wmforecast:
> ,
> | {
> |   longitude = "27,91108";
> |   interval = 60;
> |   text = "#20b2aa";
> |   icondir = "/usr/share/wmforecast";
> |   units = c;
> |   background = "#00";
> |   latitude = "43,211375";
> | }
> `

This is not a bug in wmforecast per se.  It uses libgweather4 to
retrieve forecasts are retrieved by libgweather4 from weather.gov, and
it appears that 404's are being returned for some locations.

The example given in the API doc's at
https://www.weather.gov/documentation/services-web-api succeeds:

  GET /points/39.7456,-97.0892 HTTP/1.1
  Host: api.weather.gov
  Accept: application/geo+json
  User-Agent: (azazel.net, jer...@azazel.net)
  
  HTTP/1.1 200 OK
  Server: nginx/1.20.1
  Content-Type: application/geo+json
  Access-Control-Allow-Origin: *
  Access-Control-Expose-Headers: X-Correlation-Id, X-Request-Id, X-Server-Id
  X-Request-ID: 08058eeb-9934-448a-bb4d-da9735491564
  X-Correlation-ID: 9922208
  X-Server-ID: vm-bldr-nids-apiapp1.ncep.noaa.gov
  Cache-Control: public, max-age=85382, s-maxage=120
  Expires: Thu, 16 Nov 2023 12:41:45 GMT
  Date: Wed, 15 Nov 2023 12:58:43 GMT
  Content-Length: 3096
  Connection: keep-alive
  X-Edge-Request-ID: b07ff2
  Vary: Accept,Feature-Flags,Accept-Language
  Strict-Transport-Security: max-age=31536000 ; includeSubDomains ; preload
  
  {
  "@context": [
  "https://geojson.org/geojson-ld/geojson-context.jsonld;,
  ...
  
However, if I send your latitude and longitude, I get a 404:

  GET /points/43.2113,27.911 HTTP/1.1
  Host: api.weather.gov
  Accept: application/geo+json
  User-Agent: (azazel.net, jer...@azazel.net)
  
  HTTP/1.1 404 Not Found
  Server: nginx/1.20.1
  Content-Type: application/problem+json
  X-Request-ID: 2f158817-e80e-40b1-bcb0-1ef801e85f04
  X-Correlation-ID: 3db7f703
  X-Server-ID: vm-bldr-nids-apiapp12.ncep.noaa.gov
  Access-Control-Allow-Origin: *
  Access-Control-Expose-Headers: X-Correlation-Id, X-Request-Id, X-Server-Id
  Pragma: no-cache
  Content-Length: 304
  Cache-Control: private, must-revalidate, max-age=86353
  Expires: Thu, 16 Nov 2023 12:55:30 GMT
  Date: Wed, 15 Nov 2023 12:56:17 GMT
  Connection: keep-alive
  X-Edge-Request-ID: afdb0d
  Vary: Accept,Feature-Flags,Accept-Language
  Strict-Transport-Security: max-age=31536000 ; includeSubDomains ; preload
  
  {
  "correlationId": "3db7f703",
  "title": "Data Unavailable For Requested Point",
  "type": "https://api.weather.gov/problems/InvalidPoint;,
  "status": 404,
  "detail": "Unable to provide data for requested point 43.2113,27.911",
  "instance": "https://api.weather.gov/requests/3db7f703;
  }

I am going to reassign this bug to libgweather4.

J.


signature.asc
Description: PGP signature

Bug#1055919: python-ansible-pygments: please make the build reproducible

[Chris Lamb]

[[ looping reproducible-bui...@lists.alioth.debian.org in on this issue ]]

Stuart Prescott wrote:

> Is there something about the r-b setup that would cause these
> directories to be created and appear in the package?

Hm, you know, I think there must be. In fact, connecting a few dots in
my head, that now makes three recent reproducibility bugs that the
buildds are not, if you can excuse the expression, reproducing:

  1. https://bugs.debian.org/1055919 (this bug)
  2. https://bugs.debian.org/1053353
  3. https://bugs.debian.org/1000401

I would be more than willing to conclude that this is an issue in
tests.reproducible-builds.org setup. However, I am actually seeing
these test files when I build locally as well — and my patch
consequently fixes the "problem". Moreover, I am not using the same
setup as tests.reproducible-builds.org at all. (Can you confirm whether
you see them when building locally?)

I won't file any more until this has been more generally resolved.
Hopefully I haven't been filing similar issues recently (#1055920?)
and not realising it.

(Has a build-dependency changed and then the buildd chroots are out of
sync? Is that even possible? Am I?)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#1055919: python-ansible-pygments: please make the build reproducible

[Stuart Prescott]

Hi Chris,


Whilst working on the Reproducible Builds effort [0], we noticed that



python-ansible-pygments could not be built reproducibly.







This is because the binary package included .pytest_cache and



.test-results directories. Patch attached that removes these after



running the tests.


I see those directories in the packages built on the r-b machines, but I don't 
see them in the package in the archive or when rebuilding the package locally. 
The files exist within the build tree but in /.pybuild/cpython3_3.11/build/ 
which does not get them installed.

Is there something about the r-b setup that would cause these directories to be 
created and appear in the package?

thanks
Stuart

$ apt download  -t sid python3-ansible-pygments

$ dpkg-deb --fsys-tarfile python3-ansible-pygments_0.1.1-6_all.deb | tar t
./
./usr/
./usr/lib/
./usr/lib/python3/
./usr/lib/python3/dist-packages/
./usr/lib/python3/dist-packages/ansible_pygments/
./usr/lib/python3/dist-packages/ansible_pygments/__init__.py
./usr/lib/python3/dist-packages/ansible_pygments/lexers.py
./usr/lib/python3/dist-packages/ansible_pygments/styles.py
./usr/lib/python3/dist-packages/ansible_pygments-0.1.1.dist-info/
./usr/lib/python3/dist-packages/ansible_pygments-0.1.1.dist-info/METADATA
./usr/lib/python3/dist-packages/ansible_pygments-0.1.1.dist-info/RECORD
./usr/lib/python3/dist-packages/ansible_pygments-0.1.1.dist-info/WHEEL
./usr/lib/python3/dist-packages/ansible_pygments-0.1.1.dist-info/entry_points.txt
./usr/share/
./usr/share/doc/
./usr/share/doc/python3-ansible-pygments/
./usr/share/doc/python3-ansible-pygments/changelog.Debian.gz
./usr/share/doc/python3-ansible-pygments/copyright
./usr/share/doc/python3-ansible-pygments/examples/
./usr/share/doc/python3-ansible-pygments/examples/lexer_test.py

--
Stuart Prescott   http://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer  http://www.debian.org/   stu...@debian.org
GPG fingerprint   90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#1055988: bullseye-pu: package symfony/4.4.19+dfsg-2+deb11u4

[David Prévot]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: symf...@packages.debian.org, Debian PHP PEAR Maintainers 

Control: affects -1 + src:symfony

Hi,

As per #1055986 for Bookworm, I’d like to fix the following security
issue in the next point release, as advised by the security team (they
do not intend to issue a DSA for that).

[TwigBridge] Ensure CodeExtension's filters properly escape their input
[CVE-2023-46734] (Closes: #1055774)

It also fixes the testsuite using a patch prepared a while ago.

[Mime] regenerate test certificates (Closes: #1034854)

I didn’t test the packages thoroughly (and I’m not sure to have much
time for a while), but at least the testsuites pass.

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

Thanks in advance,

taffit
diff -Nru symfony-4.4.19+dfsg/debian/changelog symfony-4.4.19+dfsg/debian/changelog
--- symfony-4.4.19+dfsg/debian/changelog	2023-02-27 23:05:34.0 +0100
+++ symfony-4.4.19+dfsg/debian/changelog	2023-11-11 19:09:20.0 +0100
@@ -1,3 +1,12 @@
+symfony (4.4.19+dfsg-2+deb11u4) bullseye; urgency=medium
+
+  * [Mime] regenerate test certificates (Closes: #1034854)
+  * Backport security fix from Symfony 4.4.51
+- [TwigBridge] Ensure CodeExtension's filters properly escape their input
+  [CVE-2023-46734] (Closes: #1055774)
+
+ -- David Prévot   Sat, 11 Nov 2023 19:09:20 +0100
+
 symfony (4.4.19+dfsg-2+deb11u3) bullseye; urgency=medium
 
   * Drop dependency bump.
diff -Nru symfony-4.4.19+dfsg/debian/patches/Mime-regenerate-test-certificates.patch symfony-4.4.19+dfsg/debian/patches/Mime-regenerate-test-certificates.patch
--- symfony-4.4.19+dfsg/debian/patches/Mime-regenerate-test-certificates.patch	1970-01-01 01:00:00.0 +0100
+++ symfony-4.4.19+dfsg/debian/patches/Mime-regenerate-test-certificates.patch	2023-11-11 19:09:20.0 +0100
@@ -0,0 +1,801 @@
+From: Nicolas Grekas 
+Date: Wed, 19 Apr 2023 11:49:13 +0200
+Subject: [Mime] regenerate test certificates
+
+Origin: upstream, http://github.com/symfony/symfony/commit/0e5e8754fd793b71202ac8554916b55410d4d08f
+Bug-Debian: https://bugs.debian.org/1034854
+---
+ src/Symfony/Component/Mime/Tests/_data/ca.crt  | 36 +++--
+ src/Symfony/Component/Mime/Tests/_data/ca.key  | 55 ++--
+ .../Component/Mime/Tests/_data/create-cert.sh  | 14 ++---
+ src/Symfony/Component/Mime/Tests/_data/encrypt.crt | 34 ++--
+ src/Symfony/Component/Mime/Tests/_data/encrypt.key | 55 ++--
+ .../Component/Mime/Tests/_data/encrypt2.crt| 34 ++--
+ .../Component/Mime/Tests/_data/encrypt2.key| 55 ++--
+ .../Component/Mime/Tests/_data/intermediate.crt| 32 ++--
+ .../Component/Mime/Tests/_data/intermediate.key| 55 ++--
+ src/Symfony/Component/Mime/Tests/_data/sign.crt| 36 ++---
+ src/Symfony/Component/Mime/Tests/_data/sign.key| 55 ++--
+ src/Symfony/Component/Mime/Tests/_data/sign2.crt   | 32 ++--
+ src/Symfony/Component/Mime/Tests/_data/sign2.key   | 55 ++--
+ src/Symfony/Component/Mime/Tests/_data/sign3.crt   | 34 ++--
+ src/Symfony/Component/Mime/Tests/_data/sign3.key   | 60 +++---
+ 15 files changed, 325 insertions(+), 317 deletions(-)
+
+diff --git a/src/Symfony/Component/Mime/Tests/_data/ca.crt b/src/Symfony/Component/Mime/Tests/_data/ca.crt
+index bca02b3..0418947 100644
+--- a/src/Symfony/Component/Mime/Tests/_data/ca.crt
 b/src/Symfony/Component/Mime/Tests/_data/ca.crt
+@@ -1,19 +1,21 @@
+ -BEGIN CERTIFICATE-
+-MIIDFDCCAfwCCQDaMw8tuy1dgDANBgkqhkiG9w0BAQsFADBMMRcwFQYDVQQDDA5T
+-eW1mb255TWltZSBDQTEUMBIGA1UECgwLU3ltZm9ueU1pbWUxDjAMBgNVBAcMBVBh
+-cmlzMQswCQYDVQQGEwJGUjAeFw0xOTA0MTkxNDIwMTFaFw0yMzA0MTgxNDIwMTFa
+-MEwxFzAVBgNVBAMMDlN5bWZvbnlNaW1lIENBMRQwEgYDVQQKDAtTeW1mb255TWlt
+-ZTEOMAwGA1UEBwwFUGFyaXMxCzAJBgNVBAYTAkZSMIIBIjANBgkqhkiG9w0BAQEF
+-AAOCAQ8AMIIBCgKCAQEAnvxOWE8qOVkuYbTu6u4Oao2n91FPF6umrcF8mq0uD2G0
+-dtOJuFaR7FeElmJnHfWvqvesCigXyA7kpdVBFGhEo83SGYTbPSGzehWDc7Kvc321
+-UPvNb61T2Ekdo+5ufrpbzlOPtTTaVL98dFEZntYNM3CXnnSSdeKz38NlHHV3QsDZ
+-crQRMxHrYi2bgkhxVoAY03ZQRbb95rEE1cfyGZ0x6VSBrVC2nnEUT2vopwny/vy+
+-QSn3oga+ucMkxJdoD8MA13Zh5I4Uiozl82xoWH/zmVrqrrO2lNBv7WYOnwbv6MSr
+-5kCE3Kcqzs8qAGv62GYyS4exIMEZsbbPv3cvp9hgYQIDAQABMA0GCSqGSIb3DQEB
+-CwUAA4IBAQBuJtPqAX6ApOymDux9sRqxx5FMIIEX2TmanSSSLesP0AVVLv8Am8/p
+-Xs8N9e49KoQhnQ3FmdtwY6IV6f3yIMnZxmkXZoUi4zCkSZd/+2iap1c51zV1b6NC
+-4C5LZtdWzhons4jOmtmxaMSy08oPPYv1wXATjjfHvqqYa/7axLY1mqbxLYC437Fv
+-H5zkdzQM2qXpIgtCjlXfOd/L9Az5DTSH4UvWiiocRdmnxGP+nMEOuUUvLzokJSeq
+-Otw4gjxczF8NQ/g/io6iG3w4OfjgRrCpuMv/l3eYClC7vDXOX9S172CpzaD/qkHM
+-NFxckxTgT4ylmivmHZWym4xS1bkAAAsd

Bug#1055987: ITP: virt-firmware -- Tools for manipulating edk2 (ovmf/qemu-efi) firmware images

[dann frazier]

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

* Package name: virt-firmware
  Version : 23.10
  Upstream Contact: Gerd Hoffmann 
* URL : https://gitlab.com/kraxel/virt-firmware
* License : GPL-2+
  Programming Lang: Python
  Description : Tools for manipulating edk2 (ovmf/qemu-efi) firmware images

This is a collection of tools for edk2 firmware images. They support
decoding and printing the content of firmware volumes. Variable stores
(e.g. OVMF_VARS.fd) can be modified, for example to enroll secure boot
certificates. Tools included:

 virt-fw-dump - Decodes and prints the content of firmware volumes.

 virt-fw-vars - Print and edit variable store volumes. Currently focused on
enrolling certificates and enabling secure boot.

 virt-fw-sigdb - Print and edit EFI signature database files.

 host-efi-vars - Read efi variables from linux efivarfs and decode/print them.

 kernel-bootcfg - Manage efi boot configuration for UKIs (unified kernel
  images) when using direct boot (without boot loader like
  grub or systemd-boot).

 pe-dumpinfo - Information dump for pe (the format used by EFI) binaries.

 pe-listsigs - List signatures and certificate chain for pe binaries. Can also
   extract certificates & signatures.


My immediate motivation for packaging this is that, as the maintainer of
the edk2 package, I need to remove some deprecated image types - specifically
the OVMF 2M images. These utilities can help users migrate their VMs to
supported types by dumping/loading the variable stores.

In the future, I expect edk2 packaging to evolve into using these tools
to modify images out-of-band, instead of launching QEMU instances to
modify them in-band as part of the build.

Bug#1055986: bookworm-pu: package symfony/5.4.23+dfsg-1+deb12u1

[David Prévot]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: symf...@packages.debian.org, Debian PHP PEAR Maintainers 

Control: affects -1 + src:symfony

Hi,

I’d like to fix the following two security issues in the next point
release, as advised by the security team (they do not intend to issue a
DSA for that).

[TwigBridge] Ensure CodeExtension's filters properly escape their input
[CVE-2023-46734] (Closes: #1055774)
[Security] Fix possible session fixation when only the *token* changes
[CVE-2023-46733] (Closes: #1055775)

I didn’t test the packages thoroughly (and I’m not sure to have much
time for a while), but at least the testsuites pass.

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

Thanks in advance,

taffit
diff -Nru symfony-5.4.23+dfsg/debian/changelog symfony-5.4.23+dfsg/debian/changelog
--- symfony-5.4.23+dfsg/debian/changelog	2023-04-29 18:41:44.0 +0200
+++ symfony-5.4.23+dfsg/debian/changelog	2023-11-11 18:59:39.0 +0100
@@ -1,3 +1,14 @@
+symfony (5.4.23+dfsg-1+deb12u1) bookworm; urgency=medium
+
+  * debian/gbp.conf: Track bookworm branch
+  * Backport security fixes from Symfony 5.4.31
+- [TwigBridge] Ensure CodeExtension's filters properly escape their input
+  [CVE-2023-46734] (Closes: #1055774)
+- [Security] Fix possible session fixation when only the *token* changes
+  [CVE-2023-46733] (Closes: #1055775)
+
+ -- David Prévot   Sat, 11 Nov 2023 18:59:39 +0100
+
 symfony (5.4.23+dfsg-1) unstable; urgency=medium
 
   [ Fabien Potencier ]
diff -Nru symfony-5.4.23+dfsg/debian/gbp.conf symfony-5.4.23+dfsg/debian/gbp.conf
--- symfony-5.4.23+dfsg/debian/gbp.conf	2023-02-28 19:54:32.0 +0100
+++ symfony-5.4.23+dfsg/debian/gbp.conf	2023-11-11 18:59:39.0 +0100
@@ -1,5 +1,5 @@
 [DEFAULT]
-debian-branch = debian/latest
+debian-branch = debian/bookworm
 pristine-tar = True
 filter = [ '.gitattributes' ]
 
diff -Nru symfony-5.4.23+dfsg/debian/patches/Security-Fix-possible-session-fixation-when-only-the-toke.patch symfony-5.4.23+dfsg/debian/patches/Security-Fix-possible-session-fixation-when-only-the-toke.patch
--- symfony-5.4.23+dfsg/debian/patches/Security-Fix-possible-session-fixation-when-only-the-toke.patch	1970-01-01 01:00:00.0 +0100
+++ symfony-5.4.23+dfsg/debian/patches/Security-Fix-possible-session-fixation-when-only-the-toke.patch	2023-11-11 18:59:39.0 +0100
@@ -0,0 +1,65 @@
+From: Robert 
+Date: Fri, 3 Nov 2023 17:09:59 +0100
+Subject: [Security] Fix possible session fixation when only the *token*
+ changes
+
+Origin: upstream, https://github.com/symfony/symfony/commit/dc356499d5ceb86f7cf2b4c7f032eca97061ed74
+Bug: https://symfony.com/blog/cve-2023-46733-possible-session-fixation
+Bug-Debian: https://bugs.debian.org/1055775
+---
+ .../Http/EventListener/SessionStrategyListener.php  |  2 +-
+ .../EventListener/SessionStrategyListenerTest.php   | 21 +
+ 2 files changed, 22 insertions(+), 1 deletion(-)
+
+diff --git a/src/Symfony/Component/Security/Http/EventListener/SessionStrategyListener.php b/src/Symfony/Component/Security/Http/EventListener/SessionStrategyListener.php
+index 311a52f..c6fcba8 100644
+--- a/src/Symfony/Component/Security/Http/EventListener/SessionStrategyListener.php
 b/src/Symfony/Component/Security/Http/EventListener/SessionStrategyListener.php
+@@ -48,7 +48,7 @@ class SessionStrategyListener implements EventSubscriberInterface
+ $user = method_exists($token, 'getUserIdentifier') ? $token->getUserIdentifier() : $token->getUsername();
+ $previousUser = method_exists($previousToken, 'getUserIdentifier') ? $previousToken->getUserIdentifier() : $previousToken->getUsername();
+ 
+-if ('' !== ($user ?? '') && $user === $previousUser) {
++if ('' !== ($user ?? '') && $user === $previousUser && \get_class($token) === \get_class($previousToken)) {
+ return;
+ }
+ }
+diff --git a/src/Symfony/Component/Security/Http/Tests/EventListener/SessionStrategyListenerTest.php b/src/Symfony/Component/Security/Http/Tests/EventListener/SessionStrategyListenerTest.php
+index 51b8dc1..29ef9b6 100644
+--- a/src/Symfony/Component/Security/Http/Tests/EventListener/SessionStrategyListenerTest.php
 b/src/Symfony/Component/Security/Http/Tests/EventListener/SessionStrategyListenerTest.php
+@@ -15,6 +15,7 @@ use PHPUnit\Framework\TestCase;
+ use Symfony\Component\HttpFoundation\Request;
+ use Symfony\Component\HttpFoundation\Session\SessionInterface;
+ use Symfony\Component\Security\Core\Authentication\Token\NullToken;
++use Symfony\Component\Security\Core\Authentication\Token\UsernamePasswordToken;
+ use Symfony\Component\Security\Core\User\InMemoryUser;
+ use 

Bug#1055985: RFS: python-qmix/1.0.6-3 -- Quantum Mixing software

[Yogeswaran Umasankar]

Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: kd8...@gmail.com

Dear mentors,

I am looking for a sponsor for my package "python-qmix":

 * Package name : python-qmix
   Version  : 1.0.6-3
   Upstream contact : John Garrett 
 * URL  : https://github.com/garrettj403/QMix
 * License  : GPL-3
 * Vcs  : https://salsa.debian.org/yogu/python-qmix
   Section  : python

The source builds the following binary packages:

  python3-qmix - Quantum Mixing software

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

  https://mentors.debian.net/package/python-qmix/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-qmix/python-qmix_1.0.6-3.dsc

Changes since the last upload:

 python-qmix (1.0.6-3) unstable; urgency=medium
 .
   * Corrected PYBUILD_NAME. (Closes: #1055967)
   * Removed unnecessary depends, pre-depends in binary.
   * Removed unnecessary files from python3-qmix.docs.
   * Included copyright License for debian/*.
   * Listed test files in pybuild.testfiles
   * Removed override_dh_installdocs from rules

Regards,
-- 
  Yogeswaran Umasankar

Bug#1055414: patch for bedtools FTBFS on i386 with "intersect" tool failure

[Étienne Mollier]

Control: tags -1 + patch

The below patch fixes the test failure.  There is a catch though
in that I think it introduces a baseline violation on i386, but
similar change was already needed in htslib to fix #942580.  I'm
not sure what to make of that for now.


--- a/debian/rules
+++ b/debian/rules
@@ -6,7 +6,7 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
 include /usr/share/dpkg/default.mk
 ifneq (,$(filter $(DEB_HOST_ARCH),i386 kfreebsd-i386 hurd-i386))
-  export DEB_CXXFLAGS_MAINT_APPEND=-ffloat-store
+  export DEB_CXXFLAGS_MAINT_APPEND=-msse -mfpmath=sse
 endif
 
 %:

-- 
  .''`.  Étienne Mollier 
 : :' :  gpg: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/5, please excuse my verbosity
   `-


signature.asc
Description: PGP signature

Bug#943415: apache2: Disable TLS 1.0 and 1.1 by default

[David Prévot]

Hi,

Le Thu, Oct 24, 2019 at 05:50:50PM +0200, Kurt Roeckx a écrit :
> Package: apache2
> Version: 2.4.38-3
> 
> Hi,
> 
> I was expecting TLS 1.0 and 1.1 to be disabled

Same here. Four years later, RFC 8996 (Deprecating TLS 1.0 and TLS 1.1)
has been published and most clients have been updated, so could we
please review the default SSLProtocol before Trixie gets released? 

> Could you change the default to:
> SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1

Regards,

taffit


signature.asc
Description: PGP signature

Bug#1040933: Works with libapache2-mod-pythom from sid

[Eneko Lacunza]

Hi,

This issue happens with 1.6-1 from sid on a bookworm system.  It can be 
fixed installing libapache2-mod-python from sid (3.5.0.1-1) too.


Cheers


 EnekoLacunza

Director Técnico | Zuzendari teknikoa

Binovo IT Human Project

943 569 206 

elacu...@binovo.es 

binovo.es 

Astigarragako Bidea, 2 - 2 izda. Oficina 10-11, 20180 Oiartzun


youtube    
linkedin  

Bug#738575: pthread: segfault in libpthread on Intel Galileo board

[James Addison]

Followup-For: Bug #738575
X-Debbugs-Cc: raykinsell...@gmail.com

If I understand correctly, then Ray's libx1000 library[1] provides a way to
work around this in software.  It uses some LD_PRELOAD magic, and from what I
remember, it's worth being careful when using that approach.

I opened an RFP[2] for libx1000 earlier this year, and took another look at the
Debian packaging metadata in the codebase today, resulting in a few suggested
edits as a pull request on GitHub - cc'ing you to notify you about that, Ray.
I'm unsure whether some of the proposed postinst steps are required, and will
ask you about those upstream too.

[1] - http://ashroe.eu/x1000/2016/10/21/fixing-lock-prefix-on-x1000.html

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

Bug#1055984: gimp: CVE-2023-44441 CVE-2023-44442 CVE-2023-44443 CVE-2023-44444

[Salvatore Bonaccorso]

Source: gimp
Version: 2.10.34-1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for gimp.

CVE-2023-1[0]:
| GIMP DDS File Parsing Heap-based Buffer Overflow Remote Code Execution
| Vulnerability


CVE-2023-2[1]:
| GIMP PSD File Parsing Heap-based Buffer Overflow Remote Code Execution
| Vulnerability


CVE-2023-3[2]:
| GIMP PSP File Parsing Integer Overflow Remote Code Execution
| Vulnerability


CVE-2023-4[3]:
| GIMP PSP File Parsing Off-By-One Remote Code Execution Vulnerability


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

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#810018: New Essential package procps-base

[Guillem Jover]

Hi!

On Tue, 2023-11-14 at 17:29:01 +1100, Craig Small wrote:
> What:
> Create a new package procps-base. This uses the existing procps source
> package and just enable building of pidof. procps-base will be an Essential
> package and only contain pidof.
> 
> Why:
> This would bring the pidof variant in line with other distributions.
> sysvinit-utils would no longer need to be Essential (though that's a
> separate issue) and would only have init-d-script, fstab-decode, and
> killall5.

I'm all in for shrinking the essential-set. If there is consensus to
switch pidof implementations that also seems fine to me in the abstract.
But this shuffling around of essential-ness and new tiny packages and
stuff seems a bit unnecessary to me, more so when this increases the
bootstrapping-set. I'd also rather see instead a _proper_ transition to
get sysvinit-utils out of the essential-set, and then at some later
point procps can take over pidof.

Then there's the following, which I guess complicates things:

  $ dpkg -S bin/pidof | cut -d: -f2
   /bin/pidof

Also why is killall5 not a candidate too? In any case the pidof CLI
interface does not seem too big, so this does not feels urgent to me,
given the trade-offs.

> The majority of usage of pidof is in init or pre/post scripts, which really
> should be using the LSB pidofproc function. That function in turn
> optionally uses pidof if the pidfile parameter is not given. That's
> probably a way forward for sometime in the future to not need procps-base
> Essential, but it is a way off.

I think the status_of_proc function could be switched to use
start-stop-daemon (s-s-d) --status instead of pidofproc. To replace
pidof inside pidofproc I guess s-s-d could grow some option to print
the pid, I'd be happy to implement that. After doing a quick scan over
codesearch.debian.org, I notice that it looks like many current uses
of pidofproc should instead probably be using status_of_proc, and others
seem to just be fetching the pid to then perform some action that could
instead all be done directly with s-s-d.

Thanks,
Guillem

Bug#1055983: geany-plugins: diff for NMU version 2.0-2.1

[Bastian Germann]

Source: geany-plugins
Version: 2.0-2
Tags: patch

I am uploading another NMU because my recent one was ignored.
The debdiff is attached.diff -Nru geany-plugins-2.0/debian/changelog geany-plugins-2.0/debian/changelog
--- geany-plugins-2.0/debian/changelog  2023-11-10 05:18:49.0 +0100
+++ geany-plugins-2.0/debian/changelog  2023-11-15 12:28:36.0 +0100
@@ -1,3 +1,10 @@
+geany-plugins (2.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Drop unused Build-Depends: libwnck-dev (Closes: #1041807)
+
+ -- Bastian Germann   Wed, 15 Nov 2023 12:28:36 +0100
+
 geany-plugins (2.0-2) unstable; urgency=medium
 
   * Reupload with binary for NEW
diff -Nru geany-plugins-2.0/debian/control geany-plugins-2.0/debian/control
--- geany-plugins-2.0/debian/control2023-11-10 05:18:49.0 +0100
+++ geany-plugins-2.0/debian/control2023-11-15 12:28:24.0 +0100
@@ -21,7 +21,6 @@
libgpgme11-dev,
libvte-2.91-dev,
libwebkit2gtk-4.0-dev,
-   libwnck-dev (>= 2.10.0),
libmarkdown2-dev,
libgit2-dev,
valac (>= 0.7.0),

Bug#1055982: frozen-bubble: doesn't support touch screen

[Russell Coker]

Package: frozen-bubble
Version: 2.212-12
Severity: normal

When run on Mobian on the PinePhonePro it doesn't work as the initial menu
doesn't take touch events.  Taking the arrow keys and enter is OK as an
option but it should take direct "mouse" clicks.


-- System Information:
Debian Release: trixie/sid
Architecture: arm64 (aarch64)

Kernel: Linux 6.6-rockchip (SMP w/6 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages frozen-bubble depends on:
ii  frozen-bubble-data  2.212-12
ii  libalien-sdl-perl   1.446-4
ii  libc6   2.37-12
ii  libcompress-bzip2-perl  2.28-1+b3
ii  libglib2.0-02.78.1-4
ii  liblocale-gettext-perl  1.07-6
ii  libsdl-mixer1.2 1.2.12-17+b3
ii  libsdl-perl 2.548-4
ii  libsdl1.2debian 1.2.68-1
ii  perl5.36.0-9
ii  perl-base [perlapi-5.36.0]  5.36.0-9

frozen-bubble recommends no packages.

frozen-bubble suggests no packages.

-- debconf-show failed

Bug#1055529: pdns-server: Spams journal after installation because it is configured to automatically restart

[Chris Hofstaedtler]

Control: tags -1 + upstream

* Uwe Kleine-König  [231112 00:04]:
> Hello Chris,
> 
> On 11/11/23 01:20, Chris Hofstaedtler wrote:
> > * Uwe Kleine-König  [231107 22:06]:
> > > on installation of pdns-server the pdns.service is automatically
> > > started. However in my case port 53 is already bound and so it fails to
> > > start. (That might also happen if port 53 isn't blocked because the
> > > default config isn't suitable to successfully run pdns? I didn't check.)
> > > 
> > [..]
> > > to the journal. If you don't notice this immediately and stop the
> > > service this effectively spams your journal in a very short time.
> > > 
> > > IMHO the above mentioned settings are not suitable as a default for a
> > > distribution's package even if the default configuration worked. It
> > > should be an administrator's choice to configure such a behaviour.
> > 
> > I respectfully disagree. If users have pdns-server installed and
> > running, they want it restarted ASAP. This is the correct behaviour.
> 
> That's a subjective assumption. At least I don't want that pdns (or any
> other service) is restarted once per second without rate limit and spamming
> my machine's journal.
> 
> I personally prefer a problematic service to die (which I notice by proper
> monitoring).
> 
> I assume the systemd developers on my side as the default for Restart is
> "no", and the default for StartLimitInterval is 10s.
>
> In my experience high-frequency automatic restart has very little benefits.
> If there is a problem that makes a certain service fail to start, you have
> only problems with such a rogue service (journal spamming; maybe high load;
> if the problem is too little system memory, you might make it hard for an
> admin to login; ...) If the problem is that a remote user can trigger a
> crash, it might be annoying to not have the service running, but maybe the
> next remote user can trigger a RCE if you automatically give unlimited tries
> for such remote users? So not restarting might be safer. And if it's only an
> occasional problem, at least some rate limiting doesn't hurt.
> 
> Having said that, I still think that the restart behaviour should be the
> administrator's choice with the package defaulting to no special
> configuration.
> 
> Looking at pdns's fellow contenders and how they configure automatic
> restart:
> 
>  - knot:
>Restart=on-abort
>no burst settings
>  - bind9:
>Restart=on-failure
>no burst settings
>  - unbound:
>Restart=on-failure
>no burst settings
> 
> So while these consider themself important enough, too, to Restart on
> problems, at least they don't disable systemd's ratelimiting.

I generally agree with a lot of what you said above, for the general
case. However, pdns-server has a certain behaviour and history that
does not match the other DNS daemons you listed or 'the general
case'.

If you look closely, the service file we ship is upstream's, and,
you'll also see it says --guardian=no in ExecStart.

In case that doesn't mean anything to you: long before systemd
existed, pdns grew its own 'Restart=on-failure'-style thing, called
"guardian". It did that out of a need - TTBOMK because people expect
their DNS servers to be up, and databases (libraries) tend(ed) to
have problem states that were not solvable without the process
exiting. So to get better availability, pdns shipped its own "auto
restart".

When systemd entered the picture, all the auto-restarting was
delegated to systemd, with the (AFAIK) same delays etc. as with the
home-grown guardian.

It certainly is possible that nowadays the autorestart/guardian
thing is obsolete, or the settings could be improved, etc.
I don't want to patch the settings out in Debian. A lot of people
running the pdns packages tend to be confused enough without any
differences from upstream behaviour. -- I know you are
active/present in the upstream channels, could I ask you to raise
the question there?

Best,
Chris

Bug#1055567: Error: gscan2pdf fails to compile

[Soumyanath Chatterjee]

Please find response to your questions below (in blue )



Regards

Soumyanath Chatterjee /  FIE, FIIE/

/
/


On 13/11/23 22:46, Jeff wrote:

On 13/11/2023 16:24, Soumyanath Chatterjee wrote:

  DB<1> use Image::Sane ':all';
Can't load 
'/usr/lib/x86_64-linux-gnu/perl5/5.30/auto/Image/Sane/Sane.so' for 
module Image::Sane: /usr/lib/x86_64-linux-gnu/libsane.so.1: undefined 
symbol: l

ibusb_set_option at /usr/share/perl/5.30/XSLoader.pm line 93.
at /usr/lib/x86_64-linux-gnu/perl5/5.30/Image/Sane.pm line 144.


If that failed, my first question is why you didn't see the same 
failure from the same line in 
/usr/share/perl5/Gscan2pdf/Scanner/Options.pm ? What do you see in 
line 8 of that file?


I find line 8 is commented out

package Gscan2pdf::Scanner::Options;

use strict;
use warnings;
no if $] >= 5.018, warnings => 'experimental::smartmatch';
use Carp;
use Glib qw(TRUE FALSE);    # To get TRUE and FALSE
# use Image::Sane ':all'; # For enums




What do you get from

ldd /usr/lib/x86_64-linux-gnu/perl5/5.30/auto/Image/Sane/Sane.so


linux-vdso.so.1 (0x7ffc2831c000)
   libsane.so.1 => /usr/lib/x86_64-linux-gnu/libsane.so.1 
(0x7f3ae5f7b000)

   libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f3ae5d89000)
   libusb-1.0.so.0 => /usr/local/lib/libusb-1.0.so.0 
(0x7f3ae5b7b000)

   libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f3ae5b75000)
   libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 
(0x7f3ae59bb000)

   /lib64/ld-linux-x86-64.so.2 (0x7f3ae5fd4000)
   librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f3ae59b1000)
   libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f3ae598c000)
   libicuuc.so.66 => /usr/lib/x86_64-linux-gnu/libicuuc.so.66 
(0x7f3ae57a6000)

   libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f3ae578a000)
   liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 
(0x7f3ae5761000)

   libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f3ae5612000)
   libicudata.so.66 => /usr/lib/x86_64-linux-gnu/libicudata.so.66 
(0x7f3ae3b51000)
   libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f3ae396d000)
   libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f3ae3952000)






ls -l /usr/lib/x86_64-linux-gnu/perl5/5.30/auto/Image/Sane/Sane.so


-rw-r--r-- 1 root root 51192 Nov 24  2019 
/usr/lib/x86_64-linux-gnu/perl5/5.30/auto/Image/Sane/Sane.so





ls -l /usr/lib/x86_64-linux-gnu/libsane.so.1
lrwxrwxrwx 1 root root 17 Sep 17  2020 
/usr/lib/x86_64-linux-gnu/libsane.so.1-> libsane.so.1.0.29





?




I tried to remove the comment in line 8 of 
/usr/share/perl5/Gscan2pdf/Scanner/Options.pm and run gscan2pdf both as 
normal user and as su. Here is the output from that:



soumyanath@ganak-desktop:~$ gscan2pdf
Can't load 
'/usr/lib/x86_64-linux-gnu/perl5/5.30/auto/Image/Sane/Sane.so' for 
module Image::Sane: /usr/lib/x86_64-linux-gnu/libsane.so.1: undefined 
symbol: l

ibusb_set_option at /usr/share/perl/5.30/XSLoader.pm line 93.
at /usr/lib/x86_64-linux-gnu/perl5/5.30/Image/Sane.pm line 144.
Compilation failed in require at 
/usr/share/perl5/Gscan2pdf/Scanner/Options.pm line 8.
BEGIN failed--compilation aborted at 
/usr/share/perl5/Gscan2pdf/Scanner/Options.pm line 8.
Compilation failed in require at /usr/share/perl5/Gscan2pdf/Document.pm 
line 12.
BEGIN failed--compilation aborted at 
/usr/share/perl5/Gscan2pdf/Document.pm line 12.
Compilation failed in require at 
/usr/share/perl5/Gscan2pdf/Dialog/Renumber.pm line 7.
BEGIN failed--compilation aborted at 
/usr/share/perl5/Gscan2pdf/Dialog/Renumber.pm line 7.

Compilation failed in require at /usr/bin/gscan2pdf line 61.
BEGIN failed--compilation aborted at /usr/bin/gscan2pdf line 61.
Undefined subroutine ::Sane::_exit called at 
/usr/lib/x86_64-linux-gnu/perl5/5.30/Image/Sane.pm line 190.

END failed--call queue aborted at /usr/bin/gscan2pdf line 61.
soumyanath@ganak-desktop:~$ sudo gscan2pdf
Can't load 
'/usr/lib/x86_64-linux-gnu/perl5/5.30/auto/Image/Sane/Sane.so' for 
module Image::Sane: /usr/lib/x86_64-linux-gnu/libsane.so.1: undefined 
symbol: l

ibusb_set_option at /usr/share/perl/5.30/XSLoader.pm line 93.
at /usr/lib/x86_64-linux-gnu/perl5/5.30/Image/Sane.pm line 144.
Compilation failed in require at 
/usr/share/perl5/Gscan2pdf/Scanner/Options.pm line 8.
BEGIN failed--compilation aborted at 
/usr/share/perl5/Gscan2pdf/Scanner/Options.pm line 8.
Compilation failed in require at /usr/share/perl5/Gscan2pdf/Document.pm 
line 12.
BEGIN failed--compilation aborted at 
/usr/share/perl5/Gscan2pdf/Document.pm line 12.
Compilation failed in require at 
/usr/share/perl5/Gscan2pdf/Dialog/Renumber.pm line 7.
BEGIN failed--compilation aborted at 
/usr/share/perl5/Gscan2pdf/Dialog/Renumber.pm line 7.

Compilation failed in require at /usr/bin/gscan2pdf line 61.
BEGIN failed--compilation aborted at /usr/bin/gscan2pdf line 61.
Undefined subroutine ::Sane::_exit called 

Bug#1037373: geany-plugins: NMU 1.38+dfsg-2.1

[Bastian Germann]

On Sun, 17 Sep 2023 22:26:25 +0200 Bastian Germann  wrote:

I am uploading a NMU to fix this. The debdiff is attached.

The NMU was ignored and a new revision uploaded without its changes.
Please consider applying the changes on top of your new version.

I have reopened #1041807 and #1037373.

Bug#1035657: gnuais: Fix this bug!

[Apostolos Kefalas]

Package: gnuais
Version: 0.3.3-9
Followup-For: Bug #1035657
X-Debbugs-Cc: sv1...@raag.org

Attached patch fixes this bug.


Thanks!
--- gnuais/src/gui/gui.c2023-11-14 14:09:37.607737397 +0200
+++ gnuais-fixed/src/gui/gui.c  2023-05-10 10:40:25.881124858 +0300
@@ -540,7 +540,9 @@
//(scrolled_window),
//drawing_area);
//osmmap = osm_gps_map_new ();
-osmmap = g_object_new (OSM_TYPE_GPS_MAP,
+osmmap = g_object_new (OSM_TYPE_GPS_MAP,
+   "map-source", OSM_GPS_MAP_SOURCE_OPENSTREETMAP,
+   "user-agent", "GnuAIS",
 NULL);
// <-- End workaround
int tmp;

Bug#1055978: mtr-tiny: traceroute does not stop on subnet router anycast addresses

[Rogier Wolff]

Hi, 

I'd say this is an unwanted side-effect rather than a bug. 

I'd say the "end-detection" might also consider three times the same
host responding to be considerd as "the end". 

Originally the TTL, that is now "hop counter" was the "number of
seconds in the network".

Thus if there was a queue of 5 seconds before a packet could take
the next link, the TTL would be decreased by five for that hop. And
that router should return a TTL EXCEEDED for packets arriving with
a TTL of 1-5. 

This would, after the suggested change trigger the end-detection. I'm
thinking that this would be rare enough nowadays to be acceptable.

The question is: What response are you getting. If it is a "ping
reply" and not a "time exceeded" we should definitively detct that as
"target reached". So can you trace the network?

Can you submit an upstream bugreport on github?
https://github.com/traviscross/mtr/issues

Roger. 


On Wed, Nov 15, 2023 at 10:45:28AM +0100, Roland Christanell wrote:
> Package: mtr-tiny
> Version: 0.94-1+deb11u1
> Severity: normal
> Tags: ipv6
> X-Debbugs-Cc: li...@christanell.info
> 
> Dear Maintainer,
> 
> When I'm trying to use mtr to an 'subnet router anycast address' which 
> terminates on a linux router, the router answers with the IPv6 address 
> configured on it's interface and not the anycast address, so the mtr does not 
> stop.
> 
> (For the example I use the IPv6 documentation address space)
> Let's say my linux router has the IPv6 2001:db8:0:1::1/64 and I want to make 
> a traceroute to 2001:db8:0:1::
> Example: mtr 2001:db8:0:1::
> Host  Loss%   Snt   Last  
>  Avg  Best  Wrst StDev
> 1. :::X:XX0.0% 30.7   
> 1.4   0.7   2.6   1.1
> 2. :::X:XX0.0% 32.4   
> 1.3   0.7   2.4   1.0
> 3. :::X:XX  0.0% 33.4   
> 4.5   3.4   5.5   1.1
> 4. 2001:db8:0:1::10.0% 33.7   
> 3.6   3.5   3.7   0.1
> 5. 2001:db8:0:1::10.0% 33.7   
> 3.6   3.5   3.7   0.1
> 6. 2001:db8:0:1::10.0% 33.7   
> 3.6   3.5   3.7   0.1
> 7. 2001:db8:0:1::10.0% 33.7   
> 3.6   3.5   3.7   0.1
> 8. 2001:db8:0:1::10.0% 33.7   
> 3.6   3.5   3.7   0.1
> 9. 2001:db8:0:1::10.0% 33.7   
> 3.6   3.5   3.7   0.1
> 10.   ...
> 
> In my opinion the mtr does not stop, because it does not get an answer from 
> the requested address, but because it's an 'subnet router anycast address' 
> the router answers anyway, which is correct.
> 
> Maybe I'm wrong, but I would expect a result like this:
> Example: mtr 2001:db8:0:1::
> Host  Loss%   Snt   Last  
>  Avg  Best  Wrst StDev
> 1. :::X:XX0.0% 30.7   
> 1.4   0.7   2.6   1.1
> 2. :::X:XX0.0% 32.4   
> 1.3   0.7   2.4   1.0
> 3. :::X:XX  0.0% 33.4   
> 4.5   3.4   5.5   1.1
> 4. 2001:db8:0:1:: 0.0% 33.7   
> 3.6   3.5   3.7   0.1
> 
> As far as I found out, it seems to only appear on linux routers, so I'm not 
> 100% sure if it's a bug in mtr-tiny or a misconfiguration on the linux 
> routers.
> 
> 
> -- System Information:
> Debian Release: 11.8
>   APT prefers oldstable-updates
>   APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 
> 'oldstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.10.0-26-amd64 (SMP w/1 CPU thread)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages mtr-tiny depends on:
> ii  libc62.31-13+deb11u7
> ii  libjansson4  2.13.1-1.1
> ii  libncurses6  6.2+20201114-2+deb11u2
> ii  libtinfo66.2+20201114-2+deb11u2
> 
> mtr-tiny recommends no packages.
> 
> mtr-tiny suggests no packages.
> 
> -- no debconf information
> 

-- 
** r.e.wo...@bitwizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233**
f equals m times a. When your f is steady, and your m is going down
your a is going up.  -- Chris Hadfield about flying up the space shuttle.

Bug#1055981: wmforecast: Does not retrieve data; shows error

[Yavor Doganov]

Package: wmforecast
Version: 1.9.0-1
Severity: grave
X-Debbugs-Cc: Yavor Doganov 

Since some time (about 2 weeks, but I'm not entirely sure) wmforecast
displays an image with a question mark along with the text "ERROR".  The
following message(s) appear on the console:

$ LC_ALL=C wmforecast
GWeather-Message: 11:51:41.964: Failed to get weather.gov point data: [status: 
404] Not Found
GWeather-Message: 11:52:41.353: Failed to get weather.gov point data: [status: 
404] Not Found
GWeather-Message: 11:53:41.349: Failed to get weather.gov point data: [status: 
404] Not Found

(process:179771): GWeather-WARNING **: 11:54:40.649: Failed to get METAR data: 
HTTP/2 Error: NO_ERROR

My ~/GNUstep/Defaults/wmforecast:
,
| {
|   longitude = "27,91108";
|   interval = 60;
|   text = "#20b2aa";
|   icondir = "/usr/share/wmforecast";
|   units = c;
|   background = "#00";
|   latitude = "43,211375";
| }
`

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

Kernel: Linux 6.5.0-4-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.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 wmforecast depends on:
ii  ca-certificates  20230311
ii  libc62.37-12
ii  libgeoclue-2-0   2.7.1-1
ii  libglib2.0-0 2.78.1-4
ii  libgweather-4-0  4.4.0-1
ii  libwings30.96.0-2+b1
ii  libwraster6  0.96.0-2+b1
ii  libwutil50.96.0-2+b1
ii  libx11-6 2:1.8.7-1

wmforecast recommends no packages.

wmforecast suggests no packages.

-- no debconf information

Bug#1055980: pandoc-sidenote needs a source upload for ghc 9.4

[Adrian Bunk]

Source: pandoc-sidenote
Version: 0.22.1.0-2
Severity: serious
X-Debbugs-Cc: Jonas Smedegaard 
Control: affects -1 libghc-pandoc-sidenote-doc

The following packages have unmet dependencies:
 libghc-pandoc-sidenote-doc : Depends: haddock-interface-38

Bug#1055979: fwupd hangs on XPS 15 9530 with external monitor connected

[George Shuklin]

Package: fwupd
Version: 1.9.8-1
Severity: normal
X-Debbugs-Cc: george.shuk...@gmail.com

fwupd is haging (and is killed with timeout).

Laptop: XPS 15 9530 with external monitor connected via USB-C -> DP.

Logs:

Starting fwupd.service - Firmware update daemon...
FuUsbDevice  failed to parse platform capability BOS descriptor: no
supported platform version: did not find magic
FuEngine failed to add device
/sys/devices/pci:00/:00:02.0/drm/card0/card0-DP-2/drm_dp_aux2: failed
to add device using on synaptics_mst: failed to enable remote control: failure
writing data register: failed to write 0x5 bytes on layer:0, relative_addr:0x0
fwupd.service: start operation timed out. Terminating.
fwupd.service: Failed with result 'timeout'.
Failed to start fwupd.service - Firmware update daemon.


strace on the hanged service shows:
[pid  4203] lseek(14, 1208, SEEK_SET)   = 1208
[pid  4203] write(14, "\4\0\0\0", 4)= 4
[pid  4203] lseek(14, 1202, SEEK_SET)   = 1202
[pid  4203] write(14, "\244", 1)= 1
[pid  4203] lseek(14, 1202, SEEK_SET)   = 1202
[pid  4203] read(14, "\0\0", 2) = 2
[pid  4203] lseek(14, 1216, SEEK_SET)   = 1216
[pid  4203] write(14, "\262", 1)= 1
(in a long loop)

fd 14 is /dev/drm_dp_aux5

If external monitor is disconnected, it works as expected.


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

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

Versions of packages fwupd depends on:
ii  adduser3.137
ii  libarchive13   3.7.2-1
ii  libc6  2.37-12
ii  libcbor0.100.10.2-1.1
ii  libcurl3-gnutls8.4.0-2
ii  libflashrom1   1.3.0-2.1
ii  libfwupd2  1.9.8-1
ii  libglib2.0-0   2.78.1-4
ii  libgnutls303.8.1-4+b1
ii  libgudev-1.0-0 238-3
ii  libgusb2   0.4.5-1.1
ii  libjcat1   0.1.9-1
ii  libjson-glib-1.0-0 1.8.0-2
ii  liblzma5   5.4.4-0.1
ii  libmbim-glib4  1.30.0-1
ii  libmbim-proxy  1.30.0-1
ii  libmm-glib01.22.0-1
ii  libpolkit-gobject-1-0  123-3
ii  libprotobuf-c1 1.4.1-1+b1
ii  libqmi-glib5   1.34.0-2
ii  libqmi-proxy   1.34.0-2
ii  libsqlite3-0   3.44.0-1
ii  libsystemd0254.5-1
ii  libtss2-esys-3.0.2-0   4.0.1-3
ii  libxmlb2   0.3.14-2
ii  shared-mime-info   2.2-1
ii  zlib1g 1:1.2.13.dfsg-3

Versions of packages fwupd recommends:
ii  bolt   0.9.6-1
ii  dbus   1.14.10-3
ii  fwupd-amd64-signed [fwupd-signed]  1:1.4+1
ii  jq 1.7-1
ii  python33.11.4-5+b1
pn  secureboot-db  
ii  udisks22.10.1-2

Versions of packages fwupd suggests:
pn  gir1.2-fwupd-2.0  

-- Configuration Files:
/etc/fwupd/fwupd.conf [Errno 13] Permission denied: '/etc/fwupd/fwupd.conf'

-- no debconf information

Bug#1055978: mtr-tiny: traceroute does not stop on subnet router anycast addresses

[Roland Christanell]

Package: mtr-tiny
Version: 0.94-1+deb11u1
Severity: normal
Tags: ipv6
X-Debbugs-Cc: li...@christanell.info

Dear Maintainer,

When I'm trying to use mtr to an 'subnet router anycast address' which 
terminates on a linux router, the router answers with the IPv6 address 
configured on it's interface and not the anycast address, so the mtr does not 
stop.

(For the example I use the IPv6 documentation address space)
Let's say my linux router has the IPv6 2001:db8:0:1::1/64 and I want to make a 
traceroute to 2001:db8:0:1::
Example: mtr 2001:db8:0:1::
Host  Loss%   Snt   Last   
Avg  Best  Wrst StDev
1. :::X:XX0.0% 30.7   
1.4   0.7   2.6   1.1
2. :::X:XX0.0% 32.4   
1.3   0.7   2.4   1.0
3. :::X:XX0.0% 33.4   
4.5   3.4   5.5   1.1
4. 2001:db8:0:1::10.0% 33.7   
3.6   3.5   3.7   0.1
5. 2001:db8:0:1::10.0% 33.7   
3.6   3.5   3.7   0.1
6. 2001:db8:0:1::10.0% 33.7   
3.6   3.5   3.7   0.1
7. 2001:db8:0:1::10.0% 33.7   
3.6   3.5   3.7   0.1
8. 2001:db8:0:1::10.0% 33.7   
3.6   3.5   3.7   0.1
9. 2001:db8:0:1::10.0% 33.7   
3.6   3.5   3.7   0.1
10.   ...

In my opinion the mtr does not stop, because it does not get an answer from the 
requested address, but because it's an 'subnet router anycast address' the 
router answers anyway, which is correct.

Maybe I'm wrong, but I would expect a result like this:
Example: mtr 2001:db8:0:1::
Host  Loss%   Snt   Last   
Avg  Best  Wrst StDev
1. :::X:XX0.0% 30.7   
1.4   0.7   2.6   1.1
2. :::X:XX0.0% 32.4   
1.3   0.7   2.4   1.0
3. :::X:XX0.0% 33.4   
4.5   3.4   5.5   1.1
4. 2001:db8:0:1:: 0.0% 33.7   
3.6   3.5   3.7   0.1

As far as I found out, it seems to only appear on linux routers, so I'm not 
100% sure if it's a bug in mtr-tiny or a misconfiguration on the linux routers.


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

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

Versions of packages mtr-tiny depends on:
ii  libc62.31-13+deb11u7
ii  libjansson4  2.13.1-1.1
ii  libncurses6  6.2+20201114-2+deb11u2
ii  libtinfo66.2+20201114-2+deb11u2

mtr-tiny recommends no packages.

mtr-tiny suggests no packages.

-- no debconf information

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

[Bálint Réczey]

Hi Colin,

Colin King (gmail)  ezt írta (időpont: 2023.
nov. 14., K, 17:58):
>
> Hi Balint,
>
> I've uploaded 0.4.0-2 with the suggested fixes.
>
> reply inlined below:
>
> On 09/11/2023 16:23, Bálint Réczey wrote:
> > Hi Colin,
> >
> > Colin King (gmail)  ezt írta (időpont: 2023.
> > nov. 7., K, 15:18):
> >>
> >> Hi Balint,
> >>
> >> Thanks for responding with the review. I was waiting for the upstream
> >> project to release a 0.4 with some minor fixes before re-uploading to
> >> mentors.
> >>
> >> I've addressed the issues you found as below:
> >
> > Please see my observations below.
> >
> >> On 22/10/2023 22:38, Bálint Réczey wrote:
> >>> Hi Colin,
> >>>
> >>> I've checked the second upload at [1].
> >>> As you can see in the Lintian warnings there is a .git directory which
> >>> is not ideal for a source package.
> >>> I suggest using the most widely used git-buildpackage based workflow
> >>> where the gbp command takes care of exporting the source package
> >>> without the .git dir from the packaging repository.
> >>> I'd be happy to set up a packaging repo for you at
> >>> https://salsa.debian.org/debian/libtypec and add you as a maintainer
> >>> as described in [2]
> >
> > I still hold up my offer about setting up a git repo for packaging on
> > Salsa. That comes with the benefit of automated fixes from Debian
> > Janitor and I could also comment on changes right where they happened.
>
> Thank you for your kind offer; I definitely think this is a good idea,
> please can you set this up for me. Much appreciated!

I've created the repo at https://salsa.debian.org/debian/libtypec and
added you as a maintainer.
I've also set up CI, thus when you push your branches the pipelines will start.

You may already be familiar with
https://dep-team.pages.debian.net/deps/dep14/ , but if not, please
check it before pushing your packaging repository.

...

> > I think my comment here was misleading, sorry for that.
> > Shipping *.pc is desired, shipping it in the .../libtypec.pc/ dir as a
> > result of specifying .../libtypec.pc as the target dir in the .install
> > file was not desired. It was even patched to have the right content.
> > Please ship the .pc file in the -dev package.
>
> Fixed.

The .pc file is now at the right location, but contains multiarch
strings which will differ across architectures.
I suggest hardcoding the paths in the patch.

...

> > * As you switched back to use upstream's 0.4.0 SO version the .symbols
> > file became wrong  not matching the shipped SO version. Please fix
> > that and also switch to the libtypec0 package name since it needs to
> > match upstream's major SO version
>
> Fixed.

The .symbols file's first line should be:
 libtypec.so.0 libtypec0 #MINVER#

See deb-symbols(5) for more details.

> .
> >
> > * I'd recommend asking upstream to switch to semantic SO versioning
> > instead of using the project's version and switching to major version
> > 1 when the API stabilized.
>
> Good idea. Will do when API changes and stabilizes.

Great!

Cheers,
Balint

> Colin
>
> >
> > Cheers,
> > Balint
> >
> >> Kind regards,
> >>
> >> Colin
> >>
> >>
> >>> Cheers,
> >>> Balint
> >>>
> >>> [1] https://mentors.debian.net/package/libtypec/
> >>> [2] 
> >>> https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group
> >>>
> >>> On Thu, 3 Aug 2023 17:00:58 +0100 "Colin King (gmail)"
> >>>  wrote:
>  Hi,
> 
>  I've uploaded a fixed package that addresses these issues.
> 
>  Colin
> 
>  On 18/07/2023 08:50, Adam Borowski wrote:
> > On Mon, Jul 17, 2023 at 03:29:13PM +0100, Colin King (gmail) wrote:
> >> * Package name : libtypec
> >>   Version  : 0.3-1
> >> * URL  : https://github.com/Rajaram-Regupathy/libtypec
> >
> >>  libtypec1 - generic interface for efficient USB-C port management
> >>  libtypec-dev - Development files for an interface for USB-C port 
> >> management
> >
> >> libtypec (0.3-1) unstable; urgency=low
> >> .
> >>   * Initial release (Closes: #1023477)
> >>   * Add patch 0001-fix-libtypec-so-version.patch to fix .so name 
> >> version
> >
> > Hi!
> > Before doing manual review, let's start with lintian:
> >
> > E: libtypec1: pkg-config-multi-arch-wrong-dir full text contains 
> > architecture specific dir x86_64-linux-gnu 
> > [usr/share/pkgconfig/libtypec.pc]
> > W: libtypec-dev: empty-binary-package
> > W: libtypec1: lacks-unversioned-link-to-shared-library example: 
> > usr/lib/x86_64-linux-gnu/libtypec.so 
> > [usr/lib/x86_64-linux-gnu/libtypec.so.0.3.0]
> > W: libtypec1: link-to-shared-library-in-wrong-package 
> > usr/lib/x86_64-linux-gnu/libtypec.so.0.3.0 
> > [usr/lib/x86_64-linux-gnu/libtypec.so]
> >
> >
> > Meow!
> 
> 
> 
> >>>
> >>
> >>
>

Bug#1054508: Connman: breaks connections, uses 1 CPU core, and trashes disk space

[Vignesh Raman]

Hi,

Please could you test with connman 1.42-1 in sid
and see if you still see the issue. Thanks.

Regards,
Vignesh

On 24/10/23 23:30, программист некто wrote:

Package: connman
Version: 1.41-3
Severity: critical

Hello. I encountered with a problem: Connman randomly is getting inadequate.

Symptoms (simultaneously):
1. All existing connections stop working, cannot establish new.
2. Connman uses 1 CPU core.
3. Creates temporary file /var/lib/connman/stats.<6 random characters>.tmp
4. Connman don't responding to CLI or GUI, and signal SIGTERM.

I have a guess, that bug occurs when Connman tries to reconnect to Wi-Fi 
network.

$ top
   PID USER  PR  NIVIRTRESSHR S  %CPU  %MEM TIME+ COMMAND
  3281 root  20   0   42988  32504  31352 R  99,3   0,9   2:38.19 connmand

   
Temporary files:

$ ls -l /var/lib/connman | grep "tmp"
-rw--- 1 root root 23592960 окт 22 10:38 stats.0W91C2.tmp
-rw--- 1 root root 21585920 окт 22 11:46 stats.25A7C2.tmp
-rw--- 1 root root 67358720 окт 22 10:35 stats.UD8ED2.tmp

Connman writes to a temporary file until free disk space is end.
If free space is end, then systemd kills Connman and restart it.
"stats.<>.tmp" contains 'header' and 'record', that infinity repeated.

'header' contains:
position 0x8-0xB for every file differs.
   16 B9 00 FA  14 00 00 00  94 85 41 01  FF FF FF FF
0010   FF FF FF FF  00 00 00 00  00 00 00 00  00 00 00 00
0020   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
0030   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
repeated 'record' contains:
0040   00 00 00 00  D4 5B 05 00  32 F4 35 63  00 00 00 00
0050   4B 30 25 00  3E DB 18 00  C9 A0 C0 6E  6B E0 59 31
0060   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
0070   BE 0A 06 00  00 00 00 00  2C DB 27 00  FF 4E 1A 00
0080   35 70 EC 7C  CC 64 0E 32  00 00 00 00  00 00 00 00
0090   00 00 00 00  00 00 00 00  8A 5C 07 00  08 55 39 63

syslog (when bug occured and I try to stop Connman, MAC adress removed):
Oct 23 11:46:44 debian-gateway connman-vpnd[9104]: wlan0 {update} flags 36867 

Oct 23 11:46:44 debian-gateway connman-vpnd[9104]: wlan0 {newlink} index 3 
address #WLAN_MAC# mtu 1500
Oct 23 11:46:44 debian-gateway connman-vpnd[9104]: wlan0 {newlink} index 3 operstate 
2 
Oct 23 11:46:44 debian-gateway connmand[9092]: wlan0 {RX} 289974 packets 
415132327 bytes
Oct 23 11:46:44 debian-gateway connmand[9092]: wlan0 {TX} 139436 packets 
15087832 bytes
Oct 23 11:46:44 debian-gateway kernel: rtlwifi: AP off, try to reconnect now
Oct 23 11:46:44 debian-gateway kernel: wlan0: Connection to AP #AP_MAC# lost
Oct 23 11:46:44 debian-gateway wpa_supplicant[532]: wlan0: 
CTRL-EVENT-DISCONNECTED bssid=#AP_MAC# reason=4 locally_generated=1
Oct 23 11:46:44 debian-gateway wpa_supplicant[532]: BSSID #AP_MAC# ignore list 
count incremented to 2, ignoring for 10 seconds
Oct 23 11:46:44 debian-gateway wpa_supplicant[532]: wlan0: 
CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
Oct 23 11:46:50 debian-gateway kernel: wlan0: authenticate with #AP_MAC#
Oct 23 11:46:50 debian-gateway kernel: wlan0: 80 MHz not supported, disabling 
VHT
Oct 23 11:46:50 debian-gateway wpa_supplicant[532]: wlan0: SME: Trying to 
authenticate with #AP_MAC# (SSID=#SSID_NAME# freq=2462 MHz)
Oct 23 11:46:50 debian-gateway kernel: wlan0: send auth to #AP_MAC# (try 1/3)
Oct 23 11:46:50 debian-gateway wpa_supplicant[532]: wlan0: Trying to associate 
with #AP_MAC# (SSID=#SSID_NAME# freq=2462 MHz)
Oct 23 11:46:50 debian-gateway kernel: wlan0: authenticated
Oct 23 11:46:50 debian-gateway kernel: wlan0: associate with #AP_MAC# (try 1/3)
Oct 23 11:46:50 debian-gateway kernel: wlan0: associate with #AP_MAC# (try 2/3)
Oct 23 11:46:50 debian-gateway connman-vpnd[9104]: wlan0 {update} flags 102403 

Oct 23 11:46:50 debian-gateway connman-vpnd[9104]: wlan0 {newlink} index 3 
address #WLAN_MAC# mtu 1500
Oct 23 11:46:50 debian-gateway connman-vpnd[9104]: wlan0 {newlink} index 3 operstate 
5 
Oct 23 11:46:50 debian-gateway kernel: wlan0: RX AssocResp from #AP_MAC# 
(capab=0x431 status=0 aid=48)
Oct 23 11:46:50 debian-gateway kernel: wlan0: associated
Oct 23 11:46:50 debian-gateway wpa_supplicant[532]: wlan0: Associated with 
#AP_MAC#
Oct 23 11:46:50 debian-gateway wpa_supplicant[532]: wlan0: 
CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Oct 23 11:46:50 debian-gateway wpa_supplicant[532]: wlan0: WPA: Key negotiation 
completed with #AP_MAC# [PTK=CCMP GTK=CCMP]
Oct 23 11:46:50 debian-gateway wpa_supplicant[532]: wlan0: CTRL-EVENT-CONNECTED 
- Connection to #AP_MAC# completed [id=2 id_str=]
Oct 23 11:46:50 debian-gateway connman-vpnd[9104]: wlan0 {update} flags 102467 

Oct 23 11:46:50 debian-gateway connman-vpnd[9104]: wlan0 {newlink} index 3 
address #WLAN_MAC# mtu 1500
Oct 23 11:46:50 debian-gateway connman-vpnd[9104]: wlan0 {newlink} index 3 operstate 
6 
Oct 23 11:46:50 debian-gateway wpa_supplicant[532]: bgscan simple: Failed to 
enable signal strength monitoring
Oct 23 11:47:37 

Bug#1055874: intel-graphics-compiler: FTBFS in bookworm: Assertion `SupportedIntrinsics.find(CPU) != SupportedI, ntrinsics.end() && "Unknown Platform"' failed.

[Andreas Beckmann]

Control: retitle -1 intel-graphics-compiler: FTBFS in bookworm with 
intel-vc-intrinsics-dev 0.11

On 13/11/2023 11.49, Santiago Vila wrote:

Package: src:intel-graphics-compiler
Version: 1.0.12504.6-1



During a rebuild of all packages in bookworm, this package failed to build
with the following error:


vcb: ./GenXIntrinsics/lib/GenXIntrinsics/GenXIntrinsics.cpp:476: bool 
llvm::GenXIntrinsic::isSupport
edPlatform(const std::string&, unsigned int): Assertion 
`SupportedIntrinsics.find(CPU) != SupportedI

ntrinsics.end() && "Unknown Platform"' failed.


Reproducible here, too.

Comparing the buildd logfile (2022-12-08) with mine yields a possible
culprit:

-Setting up intel-vc-intrinsics-dev:amd64 (0.8.1-1) ...
+Setting up intel-vc-intrinsics-dev:amd64 (0.11.0-1) ...

...

Verified that building in current bookworm with intel-vc-intrinsics-dev
downgraded to 0.8.1 works fine, while it FTBFS with 0.11.0
(there were no intel-vc-intrinsics uploads between these two versions)


Andreas

Bug#1054220: Off-by-one when selecting days in activity window

[Raphael Hertzog]

forwarded -1 https://github.com/projecthamster/hamster/issues/590

On Thu, 19 Oct 2023, Lee Garrett wrote:
> steps to reproduce:
> 
> - click on the + icon ("add activity") in the main window
> - on the start time, clik on the arrow next to the date
> - (a calendar pops up)
> - click on e.g. Wednesday, October 18
> - notice that the cmdline sets it to 2023-10-17, a whole day wrong

I believe this to be fixed in master, unfortunately no upstream release
happened in a very long time due to multiple issues.

https://github.com/projecthamster/hamster/commit/b3dc385c25c33ea5fac697e7e43cc2233234a64d

But there are possibly other related issues:
https://github.com/projecthamster/hamster/issues/627

I pinged upstream to try to get a new release.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#1055977: RFS: golang-github-kr-logfmt/0.0~git20210122.19f9bcb-1 [ITP] -- Parse logfmt messages (library)

[Maytham Alsudany]

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

Dear mentors,

I am looking for a sponsor for my package "golang-github-kr-logfmt":

 * Package name : golang-github-kr-logfmt
   Version  : 0.0~git20210122.19f9bcb-1
   Upstream contact : https://github.com/kr/logfmt/issues
 * URL  : https://github.com/kr/logfmt
 * License  : Expat
 * Vcs  : 
https://salsa.debian.org/go-team/packages/golang-github-kr-logfmt
   Section  : golang

The source builds the following binary packages:

  golang-github-kr-logfmt-dev - Parse logfmt messages (library)

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

  https://mentors.debian.net/package/golang-github-kr-logfmt/

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

  dget -x
https://mentors.debian.net/debian/pool/main/g/golang-github-kr-logfmt/golang-github-kr-logfmt_0.0~git20210122.19f9bcb-1.dsc

Changes for the initial release:

 golang-github-kr-logfmt (0.0~git20210122.19f9bcb-1) UNRELEASED; urgency=medium
 .
   * Initial release (Closes: #1055976)

Regards,
-- 
  Maytham Alsudany


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

Bug#1054186: debhelper 13.11.8 uploaded with changed systemd helpers

[Helmut Grohne]

Control: severity -1 serious

Hi,

I just uploaded debhelper 13.11.8 with the announced change to systemd
helpers making them install units to /usr. You are receiving this mail,
because my earlier mail with a patch in your package has not yet been
uploaded. Rebuilding the package in unstable will now cause it to build
a broken package. As long as your package is not rebuilt (nor binNMUed)
without my patch nothing bad happens.

Helmut

Bug#1055740: ITP: golang-github-humanlogio-humanlog -- Logs for humans to read.

[Maytham Alsudany]

Control: block -1 by 1055741 1055976

Dependencies golang-connectrpc-connect and golang-github-kr-logfmt need to be
packaged first.


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

Bug#1055976: ITP: golang-github-kr-logfmt -- Parse logfmt messages

[Maytham Alsudany]

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

* Package name: golang-github-kr-logfmt
  Version : 0.0~git20210122.19f9bcb-1
  Upstream Author : Keith Rarick and Blake Mizerany
https://github.com/kr/logfmt/issues
* URL : https://github.com/kr/logfmt
* License : Expat
  Programming Lang: Go
  Description : Parse logfmt messages

 Go package for parsing (and, eventually, generating) log lines in the logfmt
 style.
 .
 See http://godoc.org/github.com/kr/logfmt for format, and other documentation
 and examples.

This package is an indirect dependency of lazygit (lazygit depends on
golang-github-humanlogio-humanlog, which in turn depends on this package).



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

Bug#1055975: RFS: golang-connectrpc-connect/1.12.0-1 [ITP] -- Go implementation of Connect

[Maytham Alsudany]

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

Dear mentors,

I am looking for a sponsor for my package "golang-connectrpc-connect":

 * Package name : golang-connectrpc-connect
   Version  : 1.12.0-1
   Upstream contact : https://github.com/connectrpc/connect-go/issues
 * URL  : https://github.com/connectrpc/connect-go
 * License  : Apache-2.0
 * Vcs  : 
https://salsa.debian.org/go-team/packages/golang-connectrpc-connect
   Section  : golang

The source builds the following binary packages:

  golang-connectrpc-connect-dev - Go implementation of Connect (library)
  protoc-gen-connect-go - Go implementation of Connect (protobuf plugin)

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

  https://mentors.debian.net/package/golang-connectrpc-connect/

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

  dget -x
https://mentors.debian.net/debian/pool/main/g/golang-connectrpc-connect/golang-connectrpc-connect_1.12.0-1.dsc

Changes for the initial release:

 golang-connectrpc-connect (1.12.0-1) UNRELEASED; urgency=medium
 .
   * Initial release (Closes: #1055741)

Regards,
-- 
  Maytham Alsudany


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