Bug#1065053: bullseye-pu: package nvidia-graphics-drivers-tesla-470/470.239.06-1~deb11u1

[Andreas Beckmann]

On 24/04/2024 23.15, Jonathan Wiltshire wrote:

Is this apparent duplication correct? Sorry not to have spotted it before.


Yes, that's exactly how I want it. The history of n-g-d as part of 
n-g-d-tesla-470. The changelog entry is duplicated because of the CVE 
list, otherwise it would have been a simple "Rebuild is Tesla 470 driver".


Fortunately this package duplication (regular and tesla driver of the 
same version in one release) has been solved from bookworm (-pu(-new)) 
onwards.


Andreas

Bug#1066225: Bug#1069722: RFS: libtranscript/0.3.3-1.1 [NMU] [RC] -- Character set conversion library

[Bo YU]

Hi!

Thanks for NMUing this!

On Thu, Apr 25, 2024 at 4:29 AM Salvo Tomaselli  wrote:
>
> Hello,
>
> tilde is going to be autoremoved very soon because of libt3key.
>
> I'd say that if the maintainer hasn't taken any action about this for over a
> months, it's possible to contact the MIA team right away.

Yeah, this is my consideration also.
>
> If you don't want tilde to be dropped, you have to fix also libt3key and get 
> it
> sponsored, because just this one won't help basically.

I have uploaded it to mentor[0].

Thanks again.

BR,
Bo

[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069801
>

Bug#1053334: galera-4: FTBFS because of expired certificates

[Otto Kekäläinen]

Bullseye oldstable update request filed in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069802
You can +1 it if you want to show support.

Bug#1069802: bullseye-pu: package galera-4 26.4.18-0+deb11u1

[Otto Kekäläinen]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: mari...@packages.debian.org
Control: affects -1 + src:galera-4

I propose that the latest minor maintenance version of Galera be included in the
oldstable release update of Debian.

Packaging source is ready at
https://salsa.debian.org/mariadb-team/galera-4/-/tree/debian/bullseye and
pending upload.

## Changelog

galera-4 (26.4.18-0+deb11u1) bullseye; urgency=medium

  * Switch to upstream aware DEP-14 branch structure in gbp.conf
  * New upstream release 26.4.18. Includes multiple bug fixes, see

https://github.com/codership/documentation/blob/master/release-notes/release-notes-galera-26.4.18.txt
  * For previous release details see

https://github.com/codership/documentation/blob/master/release-notes/release-notes-galera-26.4.17.txt

https://github.com/codership/documentation/blob/master/release-notes/release-notes-galera-26.4.16.txt

https://github.com/codership/documentation/blob/master/release-notes/release-notes-galera-26.4.15.txt

https://github.com/codership/documentation/blob/master/release-notes/release-notes-galera-26.4.14.txt
  * New upstream signing key 3D53839A70BC938B08CDD47F45460A518DA84635,
verified from 26.4.17 release notes
  * New upstream release includes multiple Debian build and post-build test
failure fixes:
- Generate keys and certificates for SSL tests (Closes: #1053334)
- Attempt to bind to UDP and skips tests if not available
  (Related: #1007954)
- Fix 'uuid == WSREP_UUID_UNDEFINED' (Related: #970044)
- Fix issues reported -Werror when compiling (Related: #970043)
- Fix UBSAN issues (Closes: #1053183, Related: #970042)

## Debdiff

A source debdiff is attached, which was created with commands:
git diff --stat debian/26.4.14-0+deb11u1..debian/bullseye | xz >
debian-26.4.18-0+deb11u1.debdiff.stat.xz
git diff debian/26.4.14-0+deb11u1..debian/bullseye | xz >
debian-26.4.18-0+deb11u1.debdiff.xz

## Quality control

- Bookworm specific CI passed at
https://salsa.debian.org/mariadb-team/galera-4/-/pipelines


debian-26.4.18-0+deb11u1.debdiff.xz
Description: application/xz


debian-26.4.18-0+deb11u1.debdiff.stat.xz
Description: application/xz

Bug#1069801: RFS: libt3key/0.2.10-1.1 [NMU] [RC] -- Utilities for working with libt3key terminal descriptions

[Bo YU]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "libt3key":

 * Package name : libt3key
   Version  : 0.2.10-1.1
   Upstream contact : Gertjan Halkes 
 * URL  : https://os.ghalkes.nl/t3/libt3key.html
 * License  : GPL-3
 * Vcs  : [fill in URL of packaging vcs]
   Section  : libs

The source builds the following binary packages:

  libt3key-dev - Development files for libt3key
  libt3key1 - Terminal key sequence database library
  libt3key-bin - Utilities for working with libt3key terminal descriptions

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libt/libt3key/libt3key_0.2.10-1.1.dsc

Changes since the last upload:

 libt3key (0.2.10-1.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Add 00-fix-impfuncdef-issue.patch to fix ftbfs issue.
 (Closes: #1066618)

-- 
Regards,
--
  Bo YU

diff -Nru libt3key-0.2.10/debian/changelog libt3key-0.2.10/debian/changelog
--- libt3key-0.2.10/debian/changelog2019-11-30 21:16:41.0 +0800
+++ libt3key-0.2.10/debian/changelog2024-04-25 10:54:51.0 +0800
@@ -1,3 +1,11 @@
+libt3key (0.2.10-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add 00-fix-impfuncdef-issue.patch to fix ftbfs issue.
+(Closes: #1066618)
+
+ -- Bo YU   Thu, 25 Apr 2024 10:54:51 +0800
+
 libt3key (0.2.10-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru libt3key-0.2.10/debian/patches/00-fix-impfuncdef-issue.patch 
libt3key-0.2.10/debian/patches/00-fix-impfuncdef-issue.patch
--- libt3key-0.2.10/debian/patches/00-fix-impfuncdef-issue.patch
1970-01-01 07:30:00.0 +0730
+++ libt3key-0.2.10/debian/patches/00-fix-impfuncdef-issue.patch
2024-04-25 10:53:18.0 +0800
@@ -0,0 +1,17 @@
+Description: fix impfuncdef issue
+Author: Bo YU 
+Bug: https://bugs.debian.org/1066618
+Forwarded: Forward this patch to the author of upstream
+Last-Update: 2024-04-25
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/config.pkg
 b/config.pkg
+@@ -144,6 +144,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ int main(int argc, char *argv[]) {
+   int args[9], error, fd;
diff -Nru libt3key-0.2.10/debian/patches/series 
libt3key-0.2.10/debian/patches/series
--- libt3key-0.2.10/debian/patches/series   1970-01-01 07:30:00.0 
+0730
+++ libt3key-0.2.10/debian/patches/series   2024-04-25 10:02:49.0 
+0800
@@ -0,0 +1 @@
+00-fix-impfuncdef-issue.patch


signature.asc
Description: PGP signature

Bug#1069800: FTBFS: test failures in buildd environment

[Noah Meyerhans]

Source: cloud-init
Version: 21.1.4-1
Severity: serious
Tags: ftbfs upstream
Justification: fails to build from source

Cloud-init's test fails in a non-networked build environment, as visible in
recent buildd logs, e.g.
https://buildd.debian.org/status/fetch.php?pkg=cloud-init=all=24.1.4-1=1714007718=0

This appears to be an upstream issue, as it occurs in pristine upstream source 
tree.

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

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

Bug#1069799: rust-multihash-derive-impl - (build-)depends unsatisfiable.

[Peter Green]

Package: rust-multihash-derive-impl
Version: 0.7.0-1
Severity: serious

rust-synstructure was recently updated to version 0.13.1

I tried bumping the dependency but that caused failures due to
mismatched versions of syn. Bumping the dependency on syn as well
resulted in.


error[E0609]: no field `tokens` on type ``
   --> src/multihash.rs:100:74
    |
100 | let attr: Result, _> = 
syn::parse2(attr.tokens.clone());
| ^^ unknown field
    |
    = note: available fields are: `pound_token`, `style`, `bracket_token`, 
`meta`

error[E0609]: no field `tokens` on type ``
   --> src/multihash.rs:141:82
    |
141 | let derive_attrs: Result, _> = 
syn::parse2(attr.tokens.clone());
| ^^ unknown field
    |
    = note: available fields are: `pound_token`, `style`, `bracket_token`, 
`meta`

error[E0061]: this method takes 2 arguments but 1 argument was supplied
   --> src/utils.rs:25:29
    |
25  | let attrs = content.parse_terminated(A::parse)?;
    | -- an argument is 
missing
    |


I'm also going to report this upstream.

Bug#1069798: rust-failure-derive - (build-)depends unsatisfiable.

[Peter Green]

Package: rust-failure-derive
Version: 0.1
Tags: trixie, sid
Severity: serious

rust-synstructure was recently updated to version 0.13.1

I tried bumping the dependency but that caused failures due to
mismatched versions of syn. Bumping the dependency on syn as well
resulted in.


error[E0433]: failed to resolve: could not find `NestedMeta` in `syn`
   --> src/lib.rs:129:18
    |
129 | syn::NestedMeta::Meta(syn::Meta::NameValue(ref nv)) if 
nv.path.is_ident("display") => {
    |  ^^ could not find `NestedMeta` in `syn`

error[E0433]: failed to resolve: could not find `NestedMeta` in `syn`
   --> src/lib.rs:140:18
    |
140 | syn::NestedMeta::Lit(syn::Lit::Int(ref i)) => {
    |  ^^ could not find `NestedMeta` in `syn`

error[E0433]: failed to resolve: could not find `NestedMeta` in `syn`
   --> src/lib.rs:144:18
    |
144 | syn::NestedMeta::Meta(syn::Meta::Path(ref path)) => {
    |  ^^ could not find `NestedMeta` in `syn`

error[E0433]: failed to resolve: could not find `NestedMeta` in `syn`
   --> src/lib.rs:252:39
    |
252 | if let 
&::NestedMeta::Meta(syn::Meta::Path(ref path)) = pair {
    |   ^^ could not find 
`NestedMeta` in `syn`

error[E0609]: no field `nested` on type `MetaList`
   --> src/lib.rs:121:16
    |
121 | if msg.nested.is_empty() {
    |    ^^ unknown field
    |
    = note: available fields are: `path`, `delimiter`, `tokens`

error[E0609]: no field `nested` on type `MetaList`
   --> src/lib.rs:128:39
    |
128 | let format_string = match msg.nested[0] {
    |   ^^ unknown field
    |
    = note: available fields are: `path`, `delimiter`, `tokens`

error[E0609]: no field `lit` on type ``
   --> src/lib.rs:130:20
    |
130 | nv.lit.clone()
    |    ^^^ unknown field
    |
    = note: available fields are: `path`, `eq_token`, `value`

error[E0609]: no field `nested` on type `MetaList`
   --> src/lib.rs:139:24
    |
139 | let args = msg.nested.iter().skip(1).map(|arg| match *arg {
    |    ^^ unknown field
    |
    = note: available fields are: `path`, `delimiter`, `tokens`

error[E0599]: no method named `parse_meta` found for reference `` in 
the current scope
   --> src/lib.rs:202:32
    |
202 | if let Ok(meta) = attr.parse_meta() {
    |    ^^ help: there is a method with a 
similar name: `parse_nested_meta`

error[E0599]: no method named `parse_meta` found for reference `` in 
the current scope
   --> src/lib.rs:242:32
    |
242 | if let Ok(meta) = attr.parse_meta() {
    |    ^^ help: there is a method with a 
similar name: `parse_nested_meta`

error[E0609]: no field `nested` on type ``
   --> src/lib.rs:251:50
    |
251 | if let Some(ref pair) = list.nested.first() {
    |  ^^ unknown field
    |
    = note: available fields are: `path`, `delimiter`, `tokens`


rust-failure has long been deprecated upstream, and rdeps have been gradually 
migrating away.
Looking at the remaining list of rdeps I see.

rust-assert-cli - no rdeps
rust-bendy - no rdeps
rust-coreutils - already broken and scheduled for autoremoval from testing soon
rust-distro-info - upstream has a patch switching to anyhow but hasn't yet 
included it in a release, only rdep is lintian-brush which is not in testing 
and already has a FTBFS bug.
rust-exitfailure - no rdeps
rust-include-dir-impl - no rdeps
rust-mdl - no rdeps
rust-rspotify - already broken and not in testing
rust-rustc-cfg - I have uploaded a new version of this that no longer depends 
on failure, and updated the rdeps to use it.

Bug#1069797: openmsx: please add support for loong64

[wuruilong]

Source: openmsx
Severity: normal
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64
X-Debbugs-Cc: wuruil...@loongson.cn

Dear Maintainer,

openmsx compiles incorrectly on loongarch, the attached patch has solved the 
problem, please refer to the patch to modify the code

wuruilong

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
Description: 
 TODO: Put a short summary on the line above and replace this paragraph
 with a longer explanation of this change. Complete the meta-information
 with other relevant fields (see below for details). To make it easier, the
 information below has been extracted from the changelog. Adjust it or drop
 it.
 .
 openmsx (19.1+dfsg-1) unstable; urgency=medium
 .
   [ Aaron Rainbolt ]
   * Override spurious source-is-missing Lintian errors.
   * Don't build-depend on dpkg-dev, it's guaranteed to be installed in a
 Debian build environment.
   * Repack the upstream tarball to remove prebuilt binaries lacking source
 code. (Closes: #1056780)
   * Set 'DEB_BUILD_MAINT_OPTIONS = hardening=+all' in debian/rules.
   * Remove debian/source/include-binaries, every file listed in it doesn't
 exist.
   * Set 'Rules-Requires-Root: no' in debian/control.
   * Use debhelper 13 rather than debhelper 10.
 - Changed "debhelper (>= 10)" to "debhelper-compat (= 13)" in
   debian/control.
 - Deleted debian/compat.
   * Override spurious package-contains-documentation-outside-usr-share-doc
 Lintian gripes.
   * Created debian/upstream/metadata file.
   * Switch back to using vendored catch2, the catch2 Debian package now ships
 catch2 v3 whereas openMSX uses catch2 v2.
   * Overhauled copyright file.
 .
   [ Bas Wijnen ]
   * Revert overriding Lintian's source-is-missing error.
Author: Bas Wijnen 
Bug-Debian: https://bugs.debian.org/1056780

---
The information above should follow the Patch Tagging Guidelines, please
checkout https://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: (upstream|backport|vendor|other), (|commit:)
Bug: 
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: (no|not-needed|)
Applied-Upstream: , (|commit:)
Reviewed-By: 
Last-Update: 2024-04-25

--- openmsx-19.1+dfsg.orig/build/cpu.py
+++ openmsx-19.1+dfsg/build/cpu.py
@@ -43,6 +43,11 @@ class IA64(CPU):
'''
name = 'ia64'
 
+class LoongArch64(CPU):
+   '''64-bit Loongarch.
+   '''
+   name = 'loongarch64'
+
 class M68k(CPU):
'''Motorola 680x0.
'''
--- openmsx-19.1+dfsg.orig/build/detectsys.py
+++ openmsx-19.1+dfsg/build/detectsys.py
@@ -55,6 +55,8 @@ def detectCPU():
return 'avr32'
elif cpu == 'riscv64':
return 'riscv64'
+   elif cpu == 'loongarch64':
+   return 'loongarch64'
elif cpu == '':
# Python couldn't figure it out.
os = system().lower()

Bug#1069796: rust-abscissa-derive - (build-)depends unsatisfiable.

[Peter Green]

Package: rust-abscissa-derive
Version: 0.7.0-1
Severity: serious

rust-synstructure was recently updated to version 0.13.1

I tried bumping the dependency but that caused failures due to
mismatched versions of syn. Bumping the dependency on syn as well
resulted in.



error[E0432]: unresolved import `syn::NestedMeta`
 --> src/component.rs:5:60
  |
5 | use syn::{DeriveInput, Lit, Meta, MetaList, MetaNameValue, NestedMeta};
  |^^ no 
`NestedMeta` in the root

error[E0615]: attempted to take value of method `path` on type ``
  --> src/component.rs:56:22
   |
56 | if !attr.path.is_ident("component") {
   |   method, not a field
   |
help: use parentheses to call the method
   |
56 | if !attr.path().is_ident("component") {
   |  ++

error[E0599]: no method named `parse_meta` found for reference `` in 
the current scope
  --> src/component.rs:60:24
   |
60 | match attr.parse_meta().expect("error parsing meta") {
   |^^ help: there is a method with a similar 
name: `parse_nested_meta`

error[E0026]: struct `MetaList` does not have a field named `nested`
  --> src/component.rs:61:39
   |
61 | Meta::List(MetaList { nested, .. }) => {
   |   ^^ struct `MetaList` does not 
have this field

error[E0026]: struct `MetaNameValue` does not have a field named `lit`
   --> src/component.rs:135:17
|
135 | lit: Lit::Str(lit_str),
| ^^^ struct `MetaNameValue` does not have this field

Some errors have detailed explanations: E0026, E0432, E0599, E0615.


Since rust-abscissa-derive has no reverse dependencies I did not investigate 
further.

Bug#1014037: mailman3-web: Possible memory leak: uwsgi OOMs after a few weeks

[Peter Chubb]

> "Pierre-Elliott" == Pierre-Elliott Bécue  writes:


Pierre-Elliott> Having the same kind of setup for the past 6 years, I
Pierre-Elliott> never had such an issue.


Since increasing the size of the VM and the last Mailman3 upgrade, I
haven't seen the issue.

-- 
Dr Peter Chubbhttps://trustworthy.systems/
Trustworthy Systems GroupCSE, UNSW
Core hours: Mon 8am-3pm; Wed: 8am-5pm; Fri 8am-12pm.

Bug#1037358: mailman3-web: Upgrade from Debian 11 to Debian 12 broke mailman/mailman3-web

[Pierre-Elliott Bécue]

Hi,
Martin Krolikowski  wrote on 25/06/2023 at 
13:18:28+0200:

> Hi,
> the only log messages that could possibly be related to this issue are
> in /var/log/apt/term.log:
> Setting up python3-mailman-hyperkitty (1.2.1-1) ...
> /usr/lib/python3/dist-packages/requests/__init__.py:87:
> RequestsDependencyWarning: urllib3 (1.26.12) or chardet (5.1.0)
> doesn't match a supported version!
>   warnings.warn("urllib3 ({}) or chardet ({}) doesn't match a supported "
>
> Regards
> Martin
>
> Am Fr., 23. Juni 2023 um 15:17 Uhr schrieb Pierre-Elliott Bécue
> :
>>
>>
>> Martin Krolikowski  wrote on 23/06/2023 at 
>> 10:40:12+0200:
>>
>> > Hi,
>> > after the upgrade I ran into the same problem:
>> > # django.db.utils.OperationalError: no such column:
>> > hyperkitty_mailinglist.archive_rendering_mode
>> >
>> > I solved it by following the post upgrade steps described here:
>> > https://docs.mailman3.org/en/latest/upgrade-guide.html
>> > # mailman-web migrate
>> > solved the hyperkitty error above.
>> >
>> > Regards
>>
>> mailman-web is a proxy binary that calls
>> /usr/share/mailman3-web/manage.py which is also proxy-called by a
>> properly configured django-admin command.
>>
>> In all cases, migrate does the DB migration, and it is supposed to be
>> done in the postinst in case of an upgrade.
>>
>> If you needed to do it by hand, it means that the migrate called in
>> postinst failed, I'd be glad if you could find me the errors you got.
>>
>> Cheers!
>> --
>> PEB

So this is actually quite stupid.

While some errors required to be fixed in settings etc, I had plenty
troubles understanding why some django updates were not done, and also
why things worked properly in my case.

It seeps to be because they're done as part of the mailman3-web upgrade,
which did not occur because I did not release any new version of
mailman3-web in bookworm. Why it worked in my case is because it
actually seems I did a "reconfigure" of mailman3-web after fixing the
config file.

So actually, I think I can now fix this issue...

-- 
PEB


signature.asc
Description: PGP signature

Bug#1014037: mailman3-web: Possible memory leak: uwsgi OOMs after a few weeks

[Pierre-Elliott Bécue]

Control: tags -1 +moreinfo

Hi,

Peter Chubb  wrote on 29/06/2022 at 03:11:15+0200:

> Package: mailman3-web
> Version: 0+20200530-2
> Severity: normal
>
> Dear Maintainer,
>
>  I have a mailman3 system backed by PostGRES, exim4, and nginx; 
>  and it is set up and works properly.  However, the uwsgi process
>  keeps growing and growing until the system OOMs. typically 
>  after two to three weeks.
>
>  I added more RAM (the system now has 3Gb) but that postponed 
>  but did not fix the problem.  As a workaround I now restart 
>  the mailman3 service once a day.
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.17.0-3-cloud-amd64 (SMP w/1 CPU thread; PREEMPT)
> Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages mailman3-web depends on:
> ii  dbconfig-sqlite3   2.0.21
> ii  debconf [debconf-2.0]  1.5.79
> ii  init-system-helpers1.63
> ii  lsb-base   11.2
> ii  python33.9.8-1
> hi  python3-django-hyperkitty  1.3.4-4
> ii  python3-django-postorius   1.3.5-1
> ii  python3-psycopg2   2.9.2-2
> ii  python3-whoosh 2.7.4+git6-g9134ad92-5
> ii  ucf3.0043
> ii  uwsgi-core 2.0.20-4+b2
> ii  uwsgi-plugin-python3   2.0.20-4+b2
>
> Versions of packages mailman3-web recommends:
> ii  nginx   1.20.2-2
> ii  nginx-core [nginx]  1.20.2-2+b1
>
> Versions of packages mailman3-web suggests:
> ii  postgresql  14+241

Having the same kind of setup for the past 6 years, I never had such an
issue.

Do you have more intel?
-- 
PEB


signature.asc
Description: PGP signature

Bug#1033072: [Pkg-mailman-hackers] Bug#1033072: mailman3-web: After upgrade, moderation operations are broken

[Pierre-Elliott Bécue]

Hi,

Peter Chubb  wrote on 17/03/2023 at 00:24:59+0200:

> Package: mailman3-web
> Version: 0+20200530-2.1
> Severity: normal
>
> Dear Maintainer,
>
> I had a working mailman3 installation.  I did 'apt upgrade' which pulled
> in a new python3-hyperkitty and nginx.  Now when trying to manage
> 'held messages' on a list:
>   -- the checkbox next to 'Subject' does not toggle all the checkboxes below 
> it.
>   -- Clicking on a held message does not switch to a page where I can manage
>  the sender of that message. In fact it does nothing.
>
> I suspect the javascript to run this is broken somehow.
> In my bro3wser console when looking at teh javascript I see:
>
> Uncaught TypeError: Bootstrap's JavaScript requires jQuery. jQuery must be 
> included before Bootstrap's JavaScript.
> at Object.jQueryDetection (bootstrap.min.js:34:98)
> at bootstrap.min.js:34:407
> at bootstrap.min.js:6:200
> at bootstrap.min.js:6:288
> main.js:38 Uncaught ReferenceError: $ is not defined
> at main.js:38:1
> held_messages:445 Uncaught ReferenceError: $ is not defined
> at held_messages:445:7
> held_messages.js:3 Uncaught ReferenceError: $ is not defined
> at loadjs (held_messages.js:3:3)
> at held_messages:452:1
>
> The held_messages source file refers to jquery-3.6.0; but 
> jquery-1.11.3 is installed in 
> /var/lib/mailman3/web/static/postorius/libs/jquery
>
>
> I notice that version 3.6 is in
> /usr/share/python3-django-postorius/static/postorius/libs/jquery ...
> should the nginx snippet in /etc/mailman3 be updated to point here?
>
> For now I deleted /var/lib/mailman3/web/static/postorius and replaced it
> with a symlink to /usr/share/python3-django-postorius/static/postorius

This is a race condition.

When you upgraded hyperkitty/postorius, mailman3-web did not get updated
and therefore the django commands that should be run were not.

I think I have a solution for that, but I need to proof-check it.

Sorry.
-- 
PEB


signature.asc
Description: PGP signature

Bug#1069787: debootstrap: autopkgtest fails since t64 migration

[Luca Boccassi]

On Wed, 24 Apr 2024 19:16:51 +0100 Mark Hindley 
wrote:
> Package: debootstrap
> Version: 1.0.134
> Severity: important
> Tags: patch
> 
> 
> Dear Maintainer,
> 
> The debian/tests/debian-testing autopkgtest has been broken on 64bit
archs by
> the t64 transition in trixie. Specifically the test includes gnupg as
an
> additional package.  Gnupg depends on gpg-agent which depends on
> libnpth0. However, in trixie, libnpth0 is now provided by libnpth0t64
which
> debootstrap doesn't handle.
> 
> I suggest changing the test to include gpgv which avoids the t64
transition
> whilst providing similar functional coverage.
> 
> Patch attached.

Please send a merge request on Salsa

-- 
Kind regards,
Luca Boccassi


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

Bug#1069795: Please keep random

[David Starner]

Package: bsdgames
Version: 2.17-33
Severity: wishlist

I've found random a useful tool for sampling data files and would find
it helpful if it were kept. Thank you.
-- 
The standard is written in English . If you have trouble understanding
a particular section, read it again and again and again . . . Sit up
straight. Eat your vegetables. Do not mumble. -- _Pascal_, ISO 7185
(1991)

Bug#1069400: dqlite: FTBFS on arm64: dh_auto_test: error: make -j4 check "TESTSUITEFLAGS=-j4 --verbose" VERBOSE=1 returned exit code 2

[Mathias Gibbens]

Control: forwarded -1 https://github.com/canonical/dqlite/issues/643

  Looks like a flaky test, and unrelated to the time_t transition.

Mathias


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

Bug#1068185: llvm-toolchain-16: FTBFS on armel: cxa_guard.cpp:(.text.unlikely.__cxa_guard_acquire+0xc): undefined reference to `__atomic_load_1'

[Peter Green]

Looking at the changelog, I see


Build with --as-needed.


I suspect this is responsible for the build failure on armel

Bug#1037902: Bug#999922: xneur: depends on obsolete pcre3 library

[Andreas Rönnquist]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Hi! 

I intend to nmu xneur shortly, fixing the two RC bugs (#22,
#1037902, which has been open 7 months and 2,5 years) using the fixes
that have been posted to the bugs, to help the progress of the time_t
transition. See the attached debdiff for the full list of changes.

If you want me to hold, please let me know.

Thanks to Bastian Germann, Jonathan Bergh and Yavor Doganov for the fixes!

best
/Andreas Rönnquist
gus...@debian.org
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEETq74h7WfgJdjc9ALCHsqoZ75O8IFAmYpjLwACgkQCHsqoZ75
O8IhWw/9GKdSRYKdXwUT/YA0GBLET0zrBpb46Y8VBjlSUiMooQO72yZEj6DcLfjc
fpr8ZiMBggsS93MGK825zUQhFCQpOFYBbMr5eRUKh8vD3slzP1FCgGZNFcnTZzJf
zTmdoFnAWG9qMY+VZ+6Wqe28pYzPrIKDCP9qKX3c0wiZpGhdGsrufqIKmymInltN
Pd1BtBBEBvXbpaJqpKrN3puoBo31sg2pWktIhxSxIAVokMkXFBAZuBg5l9bsVRKV
8EZ/1Hdml2HaCKaKTOCeRiH06jHBSE+17W+DuyHfuIvx9FM0ToZuuDWnUNrItImq
YhdUFEycES8NUrJtW0OGGCwMFSU1xjKFGsWiox/DUiua350pIEjoJB8Ic5vZ4F9e
U+W+sCFWOLQpNNzjqtS2RpSVezD1phdrJIYVMKCvmwRErTY2dy0IU/3HyS1E9pUr
DBGCagvUrmOnxerLrkwljHnWgX6FmbkMBcJcO2xQjOPZlDOToBB08Yvit9FOEcmP
qwzj4sgqe3DHU2rFftmDddthjBvRnXOExc8PdCFmgb3ZmX/hyG6ckKpxKmmoi8WY
ePKJBrryIqN9tW7vQaxiSa7VcxcR87QTe2HpL/nX/Ptljolx2QyAlv4fYyFBFlbo
yfrxy5kuRzrGA78glph6gB7xauhjP/fUMlrk1aFO+h/6hdlk1NY=
=27s+
-END PGP SIGNATURE-


xneur_nmu.debdiff
Description: Binary data

Bug#1069794: ITP: openbao -- Manage, store and distribute sensitive data.

[Nikos Tsipinakis]

Package: wnpp
Severity: wishlist
Owner: Nikos Tsipinakis 
X-Debbugs-Cc: debian-de...@lists.debian.org, ni...@tsipinakis.com

* Package name: openbao
  Version : v2.0.0-alpha20240329
  Upstream Contact: OpenBao Mailing List 
* URL : https://openbao.org/
* License :  MPL-2.0
  Programming Lang: Go
  Description : Manage, store and distribute sensitive data.

Fork of Hashicorp Vault after it was relicensed to a non-free license. I intend
to give it a shot to package it in the next few weeks in coordination (and
hopefully with the guidance of) the Go team.

Bug#1064311: rdkit: NMU diff for 64-bit time_t transition

[Chris Hofstaedtler]

On Wed, Apr 24, 2024 at 09:25:29AM +0300, Andrius Merkys wrote:
> Hi,
> 
> On Mon, 19 Feb 2024 21:35:16 + Steve Langasek 
> wrote:> Since turning on 64-bit time_t is being handled centrally through a
> change
> > to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
> > important that libraries affected by this ABI change all be uploaded close
> > together in time.  Therefore I have prepared a 0-day NMU for rdkit
> > which will initially be uploaded to experimental if possible, then to
> > unstable after packages have cleared binary NEW.
> > 
> > Please find the patch for this NMU attached.
> 
> It is most likely my fault this has not been resolved yet - by uploading
> 202309.3-3 I trashed 202309.3-2.1~exp1. Am I right that I should reupload
> rdkit with t64 binaries to experimental now?

t64 is already in unstable and making its way to testing. So you are
a bit late with getting rdkit fixed for t64.

An upload with t64 binaries is required as soon as possible. Given
the packages have to go to binary-NEW, you must upload with
binaries, and then probably follow up with a source-only upload once
they are ACCEPTed.

Chris

Bug#1069793: wrong package name mnt-reform-setup-wizard -- should be reform-setup-wizard

[Johannes Schauer Marin Rodrigues]

Package: reform-setup-wizard
Version: 0.1.0-1
Severity: serious

As it says in subject.

Bug#1065053: bullseye-pu: package nvidia-graphics-drivers-tesla-470/470.239.06-1~deb11u1

[Jonathan Wiltshire]

On Thu, Feb 29, 2024 at 10:19:45AM +0100, Andreas Beckmann wrote:
> nvidia-graphics-drivers-tesla-470 (470.239.06-1~deb12u1) bookworm; 
> urgency=medium
> 
>   * Rebuild for bookworm.
> 
>  -- Andreas Beckmann   Thu, 29 Feb 2024 02:41:42 +0100
> 
> nvidia-graphics-drivers-tesla-470 (470.239.06-1) unstable; urgency=medium
> 
>   * New upstream long term support branch release 470.239.06 (2024-02-22).
> * Fixed CVE-2024-0074, CVE-2024-0078, CVE-2022-42265.  (Closes: #1064989)
>   https://nvidia.custhelp.com/app/answers/detail/a_id/5520
> * Improved compatibility with recent Linux kernels.
> 
>   [ Andreas Beckmann ]
>   * Refresh patches.
> 
>  -- Andreas Beckmann   Wed, 28 Feb 2024 02:22:39 +0100
> 
> nvidia-graphics-drivers (470.239.06-1) bullseye; urgency=medium
> 
>   * New upstream long term support branch release 470.239.06 (2024-02-22).
> * Fixed CVE-2024-0074, CVE-2024-0078, CVE-2022-42265.  (Closes: #1064983)
>   https://nvidia.custhelp.com/app/answers/detail/a_id/5520
> * Improved compatibility with recent Linux kernels.
> 
>   [ Andreas Beckmann ]
>   * Refresh patches.
>   * Upload to bullseye.
> 
>  -- Andreas Beckmann   Thu, 29 Feb 2024 00:25:42 +0100

Is this apparent duplication correct? Sorry not to have spotted it before.


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1069415: libsoup2.4: FTBFS on arm64: dh_auto_test: error: cd obj-aarch64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 meson test returned exit code 29

[Jeremy Bícha]

On Wed, Apr 24, 2024 at 5:04 PM Santiago Vila  wrote:
>
> Jeremy Bícha wrote:
> > It was also marked as severity important instead of RC because it does not 
> > affect official buildds.
>
> Not true:
>
> https://buildd.debian.org/status/logs.php?pkg=libsoup2.4=all
>
> See also:
>
> https://buildd.debian.org/status/logs.php?pkg=gcr=all
>
> and also:
>
> https://buildd.debian.org/status/logs.php?pkg=gcr4=amd64
>
> And regardless of the severity of the day, you were *explicitly* asked
> by Sebastian Ramacher to disable *or* fix the flaky tests:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057562#17
>
> Note that it's "or", nobody is asking you to act heroically and spend a time
> that you don't have. We just want to build the packages without random 
> failures,
> and for that it's enough to disable the tests that we know to be broken.
> It can't be so much difficult.

I believe you are thinking about https://bugs.debian.org/1057562

The issue I am talking about now is https://bugs.debian.org/1064744
which is different and one I that I don't recall you or Sebastian
interacting with me on.

Also, whatever affects libsoup2.4/all on those builds is different as
its test failures are different that what was reported here or at
1064744. There isn't currently a Debian bug for that issue.

Thank you,
Jeremy Bícha

Bug#1069415: libsoup2.4: FTBFS on arm64: dh_auto_test: error: cd obj-aarch64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 meson test returned exit code 29

[Santiago Vila]

Jeremy Bícha wrote:

It was also marked as severity important instead of RC because it does not 
affect official buildds.


Not true:

https://buildd.debian.org/status/logs.php?pkg=libsoup2.4=all

See also:

https://buildd.debian.org/status/logs.php?pkg=gcr=all

and also:

https://buildd.debian.org/status/logs.php?pkg=gcr4=amd64

And regardless of the severity of the day, you were *explicitly* asked
by Sebastian Ramacher to disable *or* fix the flaky tests:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057562#17

Note that it's "or", nobody is asking you to act heroically and spend a time
that you don't have. We just want to build the packages without random failures,
and for that it's enough to disable the tests that we know to be broken.
It can't be so much difficult.

Bug#1069792: transition: pandas 2.1 -> 2.2

[Rebecca N. Palmer]

Package: python3-pandas
Version: 2.1.4+dfsg-7
Severity: wishlist

Upstream have released pandas 2.2.

(Filing this now to have a bug number - I haven't actually uploaded to 
experimental yet.)


Reverse dependencies to be tested:

abinit astropy augur azure-kusto-python bmtk bqplot busco camelot-py 
cfgrib changeo cnvkit dask dask.distributed debian-astro debian-pan 
debian-science dials dioptas dipy domdf-python-tools drms dxchange dyda 
edlio emperor epigrass esda extra-data flox folium glueviz guidata 
harmonypy hdmf hickle igdiscover influxdb-python intake ipython 
jitterdebugger joypy jsonpickle keras libpysal lmfit-py loki-ecmwf 
macsyfinder mapclassify matplotlib mcaller mdtraj metaphlan metpy 
metview-python mirtop mlpack monty nanofilt napari nbsphinx openpyxl 
optuna orange3 osmnx pairtools parmed partd patsy pdb2pqr pint-xarray 
plasmidid pointpats poliastro poretools presto psychopy pybel pychopper 
pycoqc pydevd pyensembl pymatgen pymecavideo pynwb pyodc pyranges 
pyreadstat pyrle pytest-regressions python-aioinflux python-airr 
python-altair python-anndata python-apptools python-bioframe 
python-biom-format python-cgelib python-clevercsv python-cobra 
python-cogent python-cooler python-datacache python-django-pint 
python-fastparquet python-feather-format python-fluids python-geopandas 
python-geotiepoints python-gsd python-gtfparse python-hypothesis 
python-igraph python-influxdb-client python-iow python-loompy 
python-lsp-server python-nanoget python-nanomath python-ncls 
python-numpy-groupies python-pandas-flavor python-parsl python-pauvre 
python-peakutils python-pomegranate python-pyani python-pybedtools 
python-pymeasure python-pyomop python-pyproj python-rdata python-skbio 
python-streamz python-tablib python-throttler python-treetime 
python-ulmo python-upsetplot python-vega-datasets python-workalendar 
python-xarray python-xrt pytorch-geometric pyxnat q2-cutadapt q2-demux 
q2-diversity-lib q2-emperor q2-metadata q2-quality-control 
q2-quality-filter q2-taxa q2-types q2templates qiime r-bioc-mofa 
rapidfuzz rdkit recan refnx rickslab-gpu-utils sarsen scikit-learn 
scikit-rf seaborn sentineldl sherlock skimage sklearn-pandas skorch 
skyfield slm snakemake sorted-nearest spaghetti spopt spyder 
spyder-kernels statsmodels stimfit sunpy topplot tpot tqdm traittypes 
umap-learn umis xarray-safe-s1 xarray-sentinel xpore xraylarch yanagiba

Bug#1069791: console-setup: Build larger console fonts for HiDPI/accessibility with future 6.9 kernels

[T. Joseph Carter]

Package: console-setup
Version: 1.226
Severity: wishlist

Dear Maintainer,

Linux kernel 6.9+ will support larger font sizes for HiDPI screens. This
is probably aimed at "more than 4k" monitors, but for accessibility
reasons it would be really useful to have larger sizes available sooner
for those of us already have 4k sorts of screens.

Perhaps this might best be done by putting those huge-sized fonts in an
appropriately named -huge fonts package? I'll leave the implementation
details to you, this is just a request for the fonts to be created.

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

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

Versions of packages console-setup depends on:
ii  console-setup-linux 1.226
ii  debconf [debconf-2.0]   1.5.86
ii  keyboard-configuration  1.226
ii  xkb-data2.41-2

console-setup recommends no packages.

Versions of packages console-setup suggests:
ii  locales2.37-18
ii  sysvinit-utils [lsb-base]  3.09-1

Versions of packages keyboard-configuration depends on:
ii  debconf [debconf-2.0]   1.5.86
ii  liblocale-gettext-perl  1.07-7
ii  xkb-data2.41-2

Versions of packages console-setup-linux depends on:
ii  init-system-helpers 1.66
ii  kbd 2.6.4-2
ii  keyboard-configuration  1.226

console-setup-linux suggests no packages.

Versions of packages console-setup is related to:
pn  console-common
pn  console-data  
pn  console-tools 
pn  gnome-control-center  
ii  kbd   2.6.4-2
ii  systemd   255.4-1+b1

-- debconf information:
  keyboard-configuration/unsupported_config_options: true
  keyboard-configuration/ctrl_alt_bksp: false
  keyboard-configuration/unsupported_options: true
  console-setup/guess_font:
  keyboard-configuration/unsupported_layout: true
  console-setup/fontsize: 16x32
* console-setup/codeset47: # Latin1 and Latin5 - western Europe and Turkic 
languages
  keyboard-configuration/optionscode:
  console-setup/framebuffer_only:
  keyboard-configuration/layout:
  console-setup/fontsize-text47: 16x32 (framebuffer only)
* console-setup/charmap47: UTF-8
  keyboard-configuration/other:
  keyboard-configuration/model: Generic 105-key PC
  keyboard-configuration/switch: No temporary switch
* console-setup/fontsize-fb47: 16x32 (framebuffer only)
  keyboard-configuration/store_defaults_in_debconf_db: true
  keyboard-configuration/toggle: No toggling
  console-setup/store_defaults_in_debconf_db: true
  debian-installer/console-setup-udeb/title:
  keyboard-configuration/variantcode:
* keyboard-configuration/variant: English (US)
  console-setup/use_system_font:
  keyboard-configuration/layoutcode: us
  keyboard-configuration/unsupported_config_layout: true
  keyboard-configuration/compose: No compose key
  console-setup/codesetcode: Lat15
* console-setup/fontface47: TerminusBold
  keyboard-configuration/altgr: The default for the keyboard layout
  keyboard-configuration/xkb-keymap: us
  keyboard-configuration/modelcode: pc105

Bug#727656: Status of libpaper fork

[Reuben Thomas]

On Wed, 24 Apr 2024 at 22:03, Bastian Germann  wrote:

>
> I have seen Simon's post about this. The new gnulib package has a new
> README that describes how to use the Debian
> package. There is a slight chance that FTP Masters might intervene in
> having a git bundle in a package because their
> reasoing to forbid the 3.0 (git) source format in the archive is that it
> is far easier to confirm that a file set is
> legally distributable when it is a plain tar archive. We will see.


One might hope that gnulib would be accepted because as a project it is
particularly careful about licensing. In particular, gnulib-tool lets you
vet the licenses of the modules you install in your package.


>
> For libpaper, we can think of using the new gnulib package when it has
> passed NEW. It is sitting in there waiting for an
> ack.


OK, thanks for staying up-to-date on this!

-- 
https://rrt.sc3d.org

Bug#1069790: librust-err-derive-dev: impossible to install

[Jonas Smedegaard]

Package: librust-err-derive-dev
Version: 0.3.1-1+b1
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package is impossible to install: Depends on missing package
librust-synstructure-0.12+default-dev

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmYpaNIACgkQLHwxRsGg
ASEESg/+POdwe0xl1jXHdABhugoBy9kUpja/kNUmFwOhT5eU+VfHjet7qRzjxqEd
SDBKQMHTFzE7d2UMK0fHKurIBcCIkjRZhfB+pA88v40ko6i9c06+S2MIYMcXHMX9
rLquG7Gz4by8N9Yh3AiOqc/ljveNfchn/pjSwkxitc2HFvv7LmL9wxxRFykZ1KvX
YaU8T+JH5kZ/eB4WOS+5bYLDG/QCrklN1tzXcT7U9OWKo1dFa9wGK/SWvpNTprb5
xptqFMhpNg/ibbz5w1RM7+qmTCsMCAGSqYr3xre2/ypbzBL/IjHI20weayMX+XgO
O5/QpZj1ISnqYHc7eRoNYDLVdpCmmsYZ4tmC2bYhmEh+u/ch6Q+i4CGRKEULACL4
uUAEX0+lhMSkMHoAK0tgL8/5CqWBAel37cav+naoHhswiVzjtfUISlTJF0qy4C7t
XQEXo3Wnwscf9UYQh3343WzQhK6Qnh4/pMMyGDHemAE78DMLiCGJH0T2Z3JKf0wY
JYTDe1G2D/M8iIBzb2WXAgTayuME3UR0OeD1vmFaU6lmcLBY1TvRzddsAcB5wvNL
jWeAQQWkDXBJDBReW4//YHaRYuUKgi/zeXA64v+4ctybFa7vYMhiHWWpf3gpjzCZ
H5NzZmRMXEWWohLwFucWYJbuWtW9A8sgJApsIZN1S+KqASukEz4=
=ZqUd
-END PGP SIGNATURE-

Bug#727656: Status of libpaper fork

[Bastian Germann]

Hi Reuben,

I have seen Simon's post about this. The new gnulib package has a new README that describes how to use the Debian 
package. There is a slight chance that FTP Masters might intervene in having a git bundle in a package because their 
reasoing to forbid the 3.0 (git) source format in the archive is that it is far easier to confirm that a file set is 
legally distributable when it is a plain tar archive. We will see.


For libpaper, we can think of using the new gnulib package when it has passed NEW. It is sitting in there waiting for an 
ack.


Cheers,
Bastian

Bug#1069554: [Pkg-pascal-devel] Bug#1069554: this is no bug in the package, bug in the script doing the rebuild?

[Peter Blackman]

On 24/04/2024 20:38, Rene Engelhard wrote:


My point is  that you don't need the alternative.



Hi Rene,

but it would surely be needed if someone wanted to build winff from 
source on armel?


Even though that case is perhaps unlikely.
I can't see how the alternative is doing any harm.

Regards,
Peter

Bug#1069768: The 'no-agent-forwarding' key restriction disables server alive message support

[Lee Garrett]

On 24.04.24 19:59, Guilhem Moulin wrote:

Control: reassign -1 dropbear-bin 2022.83-1+deb12u1
Control: retitle -1: The 'no-agent-forwarding' key restriction disables server 
alive message support
Control: tag -1 upstream

On Wed, 24 Apr 2024 at 18:38:26 +0200, Guilhem Moulin wrote:

On Wed, 24 Apr 2024 at 17:10:57 +0200, Guilhem Moulin wrote:

It should be trivially reproducible by running `ssh -o ServerAliveCountMax=3
-o ServerAliveInterval=1 root@yourdropbearserver`. The client should then
disconnect after 3 seconds.


Seems to work as expected for me:

$ ssh -oLogLevel=DEBUG3 \
 -oServerAliveCountMax=3 -oServerAliveInterval=1 \
 -oUserKnownHostsFile=/tmp/known_hosts \
 -i /tmp/test.key \
 -l user -p 10022 127.0.0.1 sleep 300
[…]


No wait, this works in the main system but indeed at initramfs stage the
client doesn't get responses to its alive probes.


The above was misleading, turns out this was not due to the initramfs
per se, but because its authorized_keys file had the following
restrictions (which were set in my test environment per cryptsetup-initramfs'
recommendations):

 
no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="/bin/cryptroot-unlock"

Lee, I assume you have the ‘no-port-forwarding’ restriction too?  It
appears to disable server alive message support for some reason.  This
is reproducible at initramfs stage as well as in the main system.



my /etc/dropbear/initramfs/dropbear.conf has:

DROPBEAR_OPTIONS="-s -j -k -I 180 -c /usr/bin/cryptroot-unlock"

-j and -k are "disable local/remote port forwarding".

Seems like we cracked the case. Nice! Is there a chance we can get that into 
bookworm via s-p-u?

Bug#727656: Status of libpaper fork

[Reuben Thomas]

On Tue, 19 Mar 2024 at 21:46, Reuben Thomas  wrote:

> On Tue, 19 Mar 2024 at 21:37, Bastian Germann  wrote:
>
>>
>> As nobody has provided any patch yet and I do not have an idea how to use
>> gnulib properly generally and in Debian
>> context, I came up with this. I have actually tried to use Debian's
>> gnulib but could not get the thing to work.
>>
>
I've just had some information that may help. Simon Josefsson writes in a
thread on the gnulib mailing list:

The latest gnulib in Debian contains a
git bundle of gnulib, so you can Build-Depends on gnulib and via
GNULIB_REVISION pick out exactly the gnulib git revision that libpaper
needs.  This avoids including gnulib files in the tarball that is
uploaded to Debian, and there is no risk that you will get gnulib code
from a different git commit.  It requires an added 'Build-Depends: git'
in libpaper, though, which is unfortunate but I don't see how to avoid
it.  I should write a post to debian-devel describing this pattern on
how to use gnulib in Debian packages, but you can infer everything from
the links given in my blog post [1] and the latest upload of libntlm
into Debian.

[1]
https://blog.josefsson.org/2024/04/13/reproducible-and-minimal-source-only-tarballs/
[2] https://salsa.debian.org/auth-team/libntlm/-/tree/master/debian

Bug#1069554: [Pkg-pascal-devel] Bug#1069554: this is no bug in the package, bug in the script doing the rebuild?

[Rene Engelhard]

Hi,

Am 24.04.24 um 21:35 schrieb Peter B:
Why is it bad?  The nogui's are lighter dependencies than the gui 
packages.
Exactly. That#s why they should be used in package building for 
converting stuff.
One or the other is needed. Surely better to use the nogui if its 
available?


It is available. As indep builds are not done on armel that it's not 
available on armel does not really matter :)



My point is  that you don't need the alternative.


Regards,


Rene

Bug#1069554: [Pkg-pascal-devel] Bug#1069554: this is no bug in the package, bug in the script doing the rebuild?

[Peter B]

On 24/04/2024 20:02, Rene Engelhard wrote:



This bugreport now caused the following "fix" in winff:

Build-Depends-Indep:
 faketime,
 libreoffice-draw-nogui   | libreoffice-draw,
 libreoffice-writer-nogui | libreoffice-writer,

which I consider bad...



Hi Rene,

Why is it bad?  The nogui's are lighter dependencies than the gui packages.
One or the other is needed. Surely better to use the nogui if its available?


Regards,
Peter

P.S.  Relates to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065447

Bug#856870: arduino-mk: Still a problem in 2024

[Akkana Peck]

Package: arduino-mk
Version: 1.5.2-2.1
Followup-For: Bug #856870
X-Debbugs-Cc: d...@shallowsky.com

Dear Maintainer,

This bug is still a problem in April 2024. I built in an old project that used 
to work with arduino-mk, but now, make-upload fails with:

- make upload   ~/src/arduino/blink
-
Arduino.mk Configuration:
- [AUTODETECTED]   CURRENT_OS = LINUX
- [AUTODETECTED]   ARDUINO_DIR = /usr/share/arduino
- [COMPUTED]   ARDMK_DIR = /usr/share/arduino (relative to Common.mk)
- [AUTODETECTED]   ARDUINO_VERSION = 1819
- [DEFAULT]ARCHITECTURE = avr
- [DEFAULT]ARDMK_VENDOR = arduino
- [AUTODETECTED]   ARDUINO_PREFERENCES_PATH = 
/home/akkana/.arduino15/preferences.txt
- [AUTODETECTED]   ARDUINO_SKETCHBOOK = /home/akkana/Arduino (from arduino 
preferences file)
- [BUNDLED]AVR_TOOLS_DIR = /usr/share/arduino/hardware/tools/avr 
(in Arduino distribution)
- [COMPUTED]   ARDUINO_LIB_PATH = /usr/share/arduino/libraries (from 
ARDUINO_DIR)
- [COMPUTED]   ARDUINO_PLATFORM_LIB_PATH = 
/usr/share/arduino/hardware/arduino/avr/libraries (from ARDUINO_DIR)
- [COMPUTED]   ARDUINO_VAR_PATH = 
/usr/share/arduino/hardware/arduino/avr/variants (from ARDUINO_DIR)
- [COMPUTED]   BOARDS_TXT = 
/usr/share/arduino/hardware/arduino/avr/boards.txt (from ARDUINO_DIR)
- [DEFAULT]USER_LIB_PATH = /home/akkana/Arduino/libraries (in user 
sketchbook)
- [DEFAULT]PRE_BUILD_HOOK = pre-build-hook.sh
- [USER]   BOARD_TAG = uno
- [COMPUTED]   CORE = arduino (from build.core)
- [COMPUTED]   VARIANT = standard (from build.variant)
- [COMPUTED]   OBJDIR = build-uno (from BOARD_TAG)
- [COMPUTED]   ARDUINO_CORE_PATH = 
/usr/share/arduino/hardware/arduino/avr/cores/arduino (from ARDUINO_DIR, 
BOARD_TAG and boards.txt)
- [ASSUMED]MONITOR_BAUDRATE = 9600
- [DEFAULT]OPTIMIZATION_LEVEL = s
- [DEFAULT]MCU_FLAG_NAME = mmcu
- [DEFAULT]CFLAGS_STD = -std=gnu11 -flto -fno-fat-lto-objects
- [DEFAULT]CXXFLAGS_STD = -std=gnu++11 -fno-threadsafe-statics -flto
- [AUTODETECTED]   DEVICE_PATH = /dev/ttyACM0
- [DEFAULT]FORCE_MONITOR_PORT =
- [AUTODETECTED]   Size utility: AVR-aware for enhanced output
- [COMPUTED]   BOOTLOADER_PARENT = 
/usr/share/arduino/hardware/arduino/avr/bootloaders (from ARDUINO_DIR)
- [COMPUTED]   ARDMK_VERSION = 1.5
- [COMPUTED]   CC_VERSION = 7.3.0 (avr-gcc)
-
mkdir -p build-uno
make reset
make[1]: Entering directory '/home/akkana/src/arduino/blink'
/usr/bin/ard-reset-arduino  /dev/ttyACM0
make[1]: Leaving directory '/home/akkana/src/arduino/blink'
make do_upload
make[1]: Entering directory '/home/akkana/src/arduino/blink'
/usr/share/arduino/hardware/tools/avr/bin/avrdude -q -V -p atmega328p -C 
/usr/share/arduino/hardware/tools/avr/etc/avrdude.conf -D -c arduino -b 115200 
-P /dev/ttyACM0 \
-U flash:w:build-uno/blink_.hex:i
avrdude warning: cannot determine realpath() of config file 
/usr/share/arduino/hardware/tools/avr/etc/avrdude.conf: No such file or 
directory
avrdude OS error: cannot determine realpath() of config file (null): Invalid 
argument
avrdude error: unable to process system wide configuration file (null)
make[1]: *** [/usr/share/arduino/Arduino.mk:1462: do_upload] Error 1
make[1]: Leaving directory '/home/akkana/src/arduino/blink'
make: *** [/usr/share/arduino/Arduino.mk:1455: upload] Error 2

The problem is the same as mentioned earlier in this bug: it's running avrdude 
with
-C /usr/share/arduino/hardware/tools/avr/etc/avrdude.conf
when the package actually installs that file as:
   /usr/share/arduino/hardware/tools/avrdude.conf


Running the following command by hand successfully installs the binary:

/usr/share/arduino/hardware/tools/avr/bin/avrdude -q -V -p atmega328p -C 
/usr/share/arduino/hardware/tools/avrdude.conf  -D -c arduino -b 115200 -P 
/dev/ttyACM0 -U flash:w:build-uno/blink_.hex:i

The arduino-mk package should be changed to reflect where the arduino package 
is actually installing avrdude.conf (dpkg -S says it comes from arduino, not 
from avrdude, oddly enough).

The problematic lines seem to be in Arduino.mk around line 426: it's comparing 
whether $(ARDUINO_VERSION) is greater than 157, and the logic earlier for 
calculating $ARDUINO_VERSION is rather complicated, but it ends up doing
cat /usr/share/arduino/lib/version.txt  | sed -e 's/^[0-9]://g' -e 
's/[.]//g' -e 's/\+.*//g' | head -c5
which ends up with ARDUINO_VERSION = 1819, so it's greater than 157, but the 
path is actually in the place specified for versions less than 157. Maybe it 
moved, then moved back?

As a workaround, I commented out the version check as follows:

ifndef AVRDUDE_CONF
# ifeq ($(shell expr $(ARDUINO_VERSION) '>' 157), 1)
   

Bug#1069785: System Time Zone Not Honoured

[Pat Suwalski]

I have briefly tested a patch that largely reverts the 8.2 behaviour, 
built on top of the two debian timezone patches.


I don't have a full understanding of how these functions interact, so 
there might be corner cases not covered, but it is possible to get the 
old behaviour back, especially in the default case.--- php_date.c.orig	2024-04-24 14:16:54.806434417 -0400
+++ php_date.c	2024-04-24 14:58:45.176360415 -0400
@@ -259,7 +259,7 @@
 
 /* {{{ INI Settings */
 PHP_INI_BEGIN()
-	STD_PHP_INI_ENTRY("date.timezone", "UTC", PHP_INI_ALL, OnUpdate_date_timezone, default_timezone, zend_date_globals, date_globals)
+	STD_PHP_INI_ENTRY("date.timezone", "", PHP_INI_ALL, OnUpdate_date_timezone, default_timezone, zend_date_globals, date_globals)
 	PHP_INI_ENTRY("date.default_latitude",   DATE_DEFAULT_LATITUDE,PHP_INI_ALL, NULL)
 	PHP_INI_ENTRY("date.default_longitude",  DATE_DEFAULT_LONGITUDE,   PHP_INI_ALL, NULL)
 	PHP_INI_ENTRY("date.sunset_zenith",  DATE_SUNSET_ZENITH,   PHP_INI_ALL, NULL)
@@ -377,6 +377,7 @@
 	date_globals->default_timezone = NULL;
 	date_globals->timezone = NULL;
 	date_globals->tzcache = NULL;
+	date_globals->timezone_valid = 0;
 }
 /* }}} */
 
@@ -512,18 +513,19 @@
 /* {{{ static PHP_INI_MH(OnUpdate_date_timezone) */
 static PHP_INI_MH(OnUpdate_date_timezone)
 {
-	if (new_value && !timelib_timezone_id_is_valid(ZSTR_VAL(new_value), DATE_TIMEZONEDB)) {
-		php_error_docref(
-			NULL, E_WARNING,
-			"Invalid date.timezone value '%s', using '%s' instead",
-			ZSTR_VAL(new_value),
-			DATEG(default_timezone) ? DATEG(default_timezone) : "UTC"
-		);
+	if (OnUpdateString(entry, new_value, mh_arg1, mh_arg2, mh_arg3, stage) == FAILURE) {
 		return FAILURE;
 	}
 
-	if (OnUpdateString(entry, new_value, mh_arg1, mh_arg2, mh_arg3, stage) == FAILURE) {
-		return FAILURE;
+	DATEG(timezone_valid) = 0;
+	if (stage == PHP_INI_STAGE_RUNTIME) {
+		if (!timelib_timezone_id_is_valid(DATEG(default_timezone), DATE_TIMEZONEDB)) {
+			if (DATEG(default_timezone) && *DATEG(default_timezone)) {
+php_error_docref(NULL, E_WARNING, "Invalid date.timezone value '%s', we selected the timezone 'UTC' for now.", DATEG(default_timezone));
+			}
+		} else {
+			DATEG(timezone_valid) = 1;
+		}
 	}
 
 	return SUCCESS;
@@ -547,6 +549,11 @@
 			return Z_STRVAL_P(ztz);
 		}
 	} else if (*DATEG(default_timezone)) {
+		if (DATEG(timezone_valid) == 1) {
+			return DATEG(default_timezone);
+		}
+
+		DATEG(timezone_valid) = 1;
 		return DATEG(default_timezone);
 	}
 	/* Try to guess timezone from system information */
--- php_date.h.orig	2024-04-24 14:59:46.843329549 -0400
+++ php_date.h	2024-04-24 14:41:48.409328857 -0400
@@ -108,6 +108,7 @@
 	char*timezone;
 	HashTable   *tzcache;
 	timelib_error_container *last_errors;
+	int timezone_valid;
 ZEND_END_MODULE_GLOBALS(date)
 
 #define DATEG(v) ZEND_MODULE_GLOBALS_ACCESSOR(date, v)

Bug#1069062: golang-github-disintegration-imaging: CVE-2023-36308

[Nilesh Patra]

Hi Security team,

There's a third party patch for this CVE[2], and at least testing locally with 
the
PoC in[1] seems to mitigate the issue. Do you think this is OK to pick and
upload?

Maytham Alsudany wrote:
>  Hi Anthony,
>  
>  As you are the uploader for golang-github-disintegration-imaging, I'd like 
> your input on CVE-2023-
>  36308 and approval for the proposed patch, before any new upload is made.
>  
>  There has been a failed attempt to inform upstream of this issue at [1], and 
> their last commit was 4
>  years ago, so we're not likely to see a fix from upstream.
>  
>  Instead, I've found a (very minimal) third-party patch at [2] which fixes 
> this issue, and have
>  pushed it to the Salsa repo[3].
>  
>  The original security bug report is attached below.
>  
>  Kind regards,
>  Maytham
>  
>  On Mon, 15 Apr 2024 21:30:20 +0300 Maytham Alsudany 
>  wrote:
> > Package: golang-github-disintegration-imaging
> > X-Debbugs-CC: t...@security.debian.org
> > Severity: normal
> > Tags: security
> > 
> > Hi,
> > 
> > The following vulnerability was published for 
> > golang-github-disintegration-imaging.
> > 
> > CVE-2023-36308[0]:
> > | disintegration Imaging 1.6.2 allows attackers to cause a panic
> > | (because of an integer index out of range during a Grayscale call)
> > | via a crafted TIFF file to the scan function of scanner.go. NOTE: it
> > | is unclear whether there are common use cases in which this panic
> > | could have any security consequence
> > 
> > 
> > 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-36308
> > https://www.cve.org/CVERecord?id=CVE-2023-36308
> > 
> > Please adjust the affected versions in the BTS as needed.
> > 
> > Kind regards,
> > Maytham
>  
>  [1]: https://github.com/disintegration/imaging/issues/165
>  [2]: https://github.com/kovidgoyal/imaging/commit/68f6e7d
>  [3]: 
> https://salsa.debian.org/go-team/packages/golang-github-disintegration-imaging/-/commit/24e17d9e
>

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1069554: this is no bug in the package, bug in the script doing the rebuild?

[Rene Engelhard]

Hi Lucas,

this is no bug in the package AFAICS.

libreoffice-draw-nogui is clearly only in Build-Depends-Indep:

Build-Depends: debhelper-compat (= 13),
 fpc,
 libgtk2.0-dev,
 lcl,
 lcl-qt5,
Build-Depends-Indep:
 libreoffice-draw-nogui,
 libreoffice-writer,

So it's only needed for _all builds. So why would the build-deps  be 
uninstallable on armel? Or do your scripts do full builds and not 
--binary-arch/-B or whatever applicable?


(And yes, that nogui is not available on armel is a deliberate decision. 
It's dead, and nooone will hopefully want to use it for document 
conversion. And I don't want to force a full double build on armel.)


This bugreport now caused the following "fix" in winff:

Build-Depends-Indep:
 faketime,
 libreoffice-draw-nogui   | libreoffice-draw,
 libreoffice-writer-nogui | libreoffice-writer,

which I consider bad...

Regards,

Rene

Bug#1069729: bsdgames: Please keep quiz

[Kacper Gutowski]

Thanks!

-k

Bug#1069789: test_bluetooth_hidpp_mouse autopkgtest fails

[Andrey Rakhmatullin]

Package: upower
Version: 1.90.3-1
Severity: serious

Control: forwarded -1 https://gitlab.freedesktop.org/upower/upower/-/issues/228
Control: tags -1 + upstream

https://ci.debian.net/packages/u/upower/unstable/amd64/45053064/

217s ==
217s ERROR: test_bluetooth_hidpp_mouse
(__main__.Tests.test_bluetooth_hidpp_mouse)
217s Logitech Bluetooth LE mouse with HID++ kernel support
217s --
217s Traceback (most recent call last):
217s   File "/usr/libexec/upower/integration-test.py", line 2337, in
test_bluetooth_hidpp_mouse
217s self.assertEqual(self.get_dbus_dev_property(bat0_up, 'Model'), alias)
217s  
217s   File "/usr/libexec/upower/integration-test.py", line 273, in
get_dbus_dev_property
217s return self.dbus.call_sync(UP, device,
217s^^^
217s gi.repository.GLib.GError: g-dbus-error-quark:
GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Object does not exist at
path “/org/freedesktop/UPower/devices/mouse_dev_11_22_33_44_AA_BB” (19)


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

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

Versions of packages upower depends on:
ii  dbus   1.14.10-4+b1
ii  libc6  2.37-18
ii  libglib2.0-0t642.78.4-7
ii  libgudev-1.0-0 238-5
ii  libimobiledevice6  1.3.0-7.1+b1
ii  libplist3  2.2.0-7+b1
ii  libupower-glib31.90.3-1
ii  udev   255.4-1+b1

Versions of packages upower recommends:
ii  polkitd  124-2

upower suggests no packages.

-- debconf-show failed

Bug#1055847: Please check python-sparse issue at Github

[Diane Trout]

On Wed, 2024-04-24 at 15:53 +0200, Andreas Tille wrote:
> Hi Diane and Ghislain,
> 
> you are listed as Uploaders of python-sparse.  Since I now have other
> tasks than maintaining team maintained packages I would be really
> happy
> if you could subscribe upstream issue
> 
>    https://github.com/pydata/sparse/issues/628
> 
> and continue what I have started.
> 
> Thanks a lot
>    Andreas.
> 

I subscribed, though I'm still fighting with updating numba.

Also I know there are many ways that numba can fail, so odds are
sparse's problems are caused by numba.

There are definitely problems with numba on arm64.
https://github.com/numba/numba/issues/9109

(Also congratulations on your election, I have respect your
organizational skills on the med team)

Diane

Bug#1069787: debootstrap: autopkgtest fails since t64 migration

[Mark Hindley]

Package: debootstrap
Version: 1.0.134
Severity: important
Tags: patch


Dear Maintainer,

The debian/tests/debian-testing autopkgtest has been broken on 64bit archs by
the t64 transition in trixie. Specifically the test includes gnupg as an
additional package.  Gnupg depends on gpg-agent which depends on
libnpth0. However, in trixie, libnpth0 is now provided by libnpth0t64 which
debootstrap doesn't handle.

I suggest changing the test to include gpgv which avoids the t64 transition
whilst providing similar functional coverage.

Patch attached.

Mark



-- System Information:
Debian Release: 12.0
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-19-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages debootstrap depends on:
ii  wget  1.21.3-1+b2

Versions of packages debootstrap recommends:
ii  arch-test   0.21-1
ii  gnupg   2.2.40-1.1
ii  mount   2.38.1-5+deb12u1

Versions of packages debootstrap suggests:
ii  debian-archive-keyring  2023.3+deb12u1
pn  squid-deb-proxy-client  
pn  ubuntu-archive-keyring  

-- no debconf information
>From 1a79250dc45375032f4758204ec3234fd4ed006a Mon Sep 17 00:00:00 2001
From: Mark Hindley 
Date: Wed, 24 Apr 2024 10:01:53 +0100
Subject: [PATCH] d/t/debian-testing: change from gnupg to gpgv;  debootstrap
 with gnupg is broken by libnpth0t64 Provides libnpth0.

---
 debian/tests/debian-testing | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/tests/debian-testing b/debian/tests/debian-testing
index 7c3e323..89a04fe 100755
--- a/debian/tests/debian-testing
+++ b/debian/tests/debian-testing
@@ -340,7 +340,7 @@ my $testing = $distro_info->testing;
 
 # Should specify multiple components for checking (see Bug#898738)
 if (!verbose_run([length($ENV{DEBOOTSTRAP_SCRIPT}) ? $ENV{DEBOOTSTRAP_SCRIPT} 
: 'debootstrap',
-'--include=debootstrap,debian-archive-keyring,gnupg,hello,systemd',
+'--include=debootstrap,debian-archive-keyring,gpgv,hello,systemd',
 '--variant=minbase',
 '--components=main,contrib,non-free',
 $testing, 'chroot.d', $mirror], '>&2')) {
-- 
2.39.2

Bug#1069786: python3-llvmlite: numba 0.59.1 needs >= llvmlite 0.43.0dev0

[Diane Trout]

Package: llvmlite-doc
Severity: normal
X-Debbugs-Cc: none, Diane Trout 

Hello,

I had some time to work on updating numba to 0.59.1 and discovered it
needs llvmlite 0.43.0dev0, the current debian/watch file is too strict
to detect that version number

Also llvmlite and numba are tightly bound, would it be possible for me
as numba maintainer to help update llvmlite?

Attached is the patch I made to llvmlite to allow be to do
gbp import-orig --uscan
so I could have a llvmlite 0.43.0dev0 package to test numba against.

>From 483c2b825bed861e7ead2c135bf35686543289b6 Mon Sep 17 00:00:00 2001
From: Diane Trout 
Date: Tue, 23 Apr 2024 19:18:23 -0700
Subject: [PATCH] Update d/watch to use @ANY_VERSION@ to detect version
 0.43.0dev0

---
 debian/changelog | 6 ++
 debian/watch | 4 ++--
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index ec1faf6..5ed5640 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+llvmlite (0.42.0-2) UNRELEASED; urgency=medium
+
+  * Update d/watch to use @ANY_VERSION@ to detect version 0.43.0dev0
+
+ -- Diane Trout   Tue, 23 Apr 2024 19:16:11 -0700
+
 llvmlite (0.42.0-1) unstable; urgency=medium
 
   * Upload to unstable.
diff --git a/debian/watch b/debian/watch
index 6ede6b4..c8d3ac0 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,4 +1,4 @@
 version=4
-opts="filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%llvmlite-$1.tar.gz%" \
+opts="filenamemangle=s%(?:.*?)?v@ANY_VERSION@@ARCHIVE_EXT@%llvmlite-$1.tar.gz%" \
 https://github.com/numba/llvmlite/tags \
-(?:.*?/)?v?(\d[\d.]*)\.tar\.gz debian uupdate
+(?:.*?/)?v@ANY_VERSION@@ARCHIVE_EXT@ debian uupdate
-- 
2.30.2

Bug#1069691: [Debian-med-packaging] Bug#1069691: libmaus2: FTBFS on arm64: what(): AutoArray failed to allocate 1398102 elements (11184816 bytes)

[Étienne Mollier]

Control: found -1 2.0.813+ds-3

Hmn, this is annoying.  I do not manage to reproduce the error
with qemu-user.  The test error is reproducible on buildd's real
hardware in the meantime[1], or at least on two of the Arm build
machines hosted by Conova.  There could be something hardware
specific.  I'd have to check how things go on porterbox next.

[1]: 
https://buildd.debian.org/status/fetch.php?pkg=libmaus2=arm64=2.0.813%2Bds-3=1713977128=0

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


signature.asc
Description: PGP signature

Bug#1069785: System Time Zone Not Honoured

[Pat Suwalski]

Package: php
Version: 8.2.18-1~deb12u1

PHP isn't parsing the system time zone like it used to be, instead 
defaulting to UTC.


Here is a test script:

  The patch that is supposed to make this work is 
debian/patches/0021-Use-system-timezone.patch, but it apparently no 
longer works.


Others have noticed, but upstream says the default has always been UTC: 
https://github.com/php/php-src/issues/11496


That issue has a link to a commit that may have broken the patch: 
https://github.com/php/php-src/commit/6770158d474fa442ce55bba4ec32dd2703828b33


It seems that the commit sets the default to "UTC" rather than "", which 
probably overrides the patch-determined value.


Proper POSIX behaviour is to honour the timezone passed in via 
environment, so it would be good to restore correct behaviour.


--Pat

Bug#1069768: The 'no-agent-forwarding' key restriction disables server alive message support

[Guilhem Moulin]

Control: reassign -1 dropbear-bin 2022.83-1+deb12u1
Control: retitle -1: The 'no-agent-forwarding' key restriction disables server 
alive message support
Control: tag -1 upstream

On Wed, 24 Apr 2024 at 18:38:26 +0200, Guilhem Moulin wrote:
> On Wed, 24 Apr 2024 at 17:10:57 +0200, Guilhem Moulin wrote:
>>> It should be trivially reproducible by running `ssh -o ServerAliveCountMax=3
>>> -o ServerAliveInterval=1 root@yourdropbearserver`. The client should then
>>> disconnect after 3 seconds.
>> 
>> Seems to work as expected for me:
>> 
>>  $ ssh -oLogLevel=DEBUG3 \
>> -oServerAliveCountMax=3 -oServerAliveInterval=1 \
>> -oUserKnownHostsFile=/tmp/known_hosts \
>> -i /tmp/test.key \
>> -l user -p 10022 127.0.0.1 sleep 300
>>  […]
>
> No wait, this works in the main system but indeed at initramfs stage the
> client doesn't get responses to its alive probes.

The above was misleading, turns out this was not due to the initramfs
per se, but because its authorized_keys file had the following
restrictions (which were set in my test environment per cryptsetup-initramfs'
recommendations):


no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="/bin/cryptroot-unlock"

Lee, I assume you have the ‘no-port-forwarding’ restriction too?  It
appears to disable server alive message support for some reason.  This
is reproducible at initramfs stage as well as in the main system.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1067148: hovercraft 2.7-2+deb11u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1067148 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: hovercraft
Version: 2.7-2+deb11u1

Explanation: depend on python3-setuptools

Bug#1069784: python-itemloaders: please make the build reproducible

[Chris Lamb]

Source: python-itemloaders
Version: 1.2.0-3
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed that
python-itemloaders could not be built reproducibly.

This is because the manual pages embed the build year in copyright
messages. A patch is therefore attached that seeds the date from
SOURCE_DATE_EPOCH if available.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/0002-Reproducible-build.patch  1970-01-01 
01:00:00.0 +0100
--- b/debian/patches/0002-Reproducible-build.patch  2024-04-24 
16:57:48.698090140 +0100
@@ -0,0 +1,37 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2024-04-24
+
+--- python-itemloaders-1.2.0.orig/docs/conf.py
 python-itemloaders-1.2.0/docs/conf.py
+@@ -13,7 +13,8 @@
+ 
+ import os
+ import sys
+-from datetime import datetime
++import time
++import datetime
+ from os import path
+ 
+ import sphinx_rtd_theme
+@@ -24,6 +25,11 @@ import sphinx_rtd_theme
+ sys.path.append(path.dirname(__file__))
+ sys.path.insert(0, path.dirname(path.dirname(__file__)))
+ 
++build_date = datetime.datetime.fromtimestamp(
++int(os.environ.get('SOURCE_DATE_EPOCH', time.time())),
++tz=datetime.timezone.utc,
++)
++
+ # General configuration
+ # -
+ 
+@@ -51,7 +57,7 @@ master_doc = "index"
+ 
+ # General information about the project.
+ project = "itemloaders"
+-copyright = "2020\u2013{}, Zyte Group Ltd".format(datetime.now().year)
++copyright = "2020\u2013{}, Zyte Group Ltd".format(build_date.year)
+ 
+ # The version info for the project you're documenting, acts as replacement for
+ # |version| and |release|, also used in various other places throughout the
--- a/debian/patches/series 2024-04-24 16:32:44.741767684 +0100
--- b/debian/patches/series 2024-04-24 16:50:13.629191809 +0100
@@ -1 +1,2 @@
 0001-Use-local-intersphinx-files.patch
+0002-Reproducible-build.patch

Bug#1069783: packeth: Man page refers to an non existing file

[Jose Luis Segura Lucas]

Package: packeth
Version: 2.1-0.2
Severity: minor
X-Debbugs-Cc: josel.seg...@gmx.es

Dear Maintainer,

When reading the man page for current packeth, it refers to file 
/usr/share/doc/packeth/README. The file doesn't exist in current
package version.

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

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

Versions of packages packeth depends on:
ii  libc6  2.37-18

packeth recommends no packages.

packeth suggests no packages.

-- no debconf information

Bug#1017581: Please install documentation

[Jérémy Lal]

Le lun. 25 sept. 2023 à 19:21, Dominique Dumont  a écrit :

> Hi
>
> Sorry for the late reply.
>
> On Thu, 18 Aug 2022 00:01:36 +0100 Ian Jackson <
> ijack...@chiark.greenend.org.uk> wrote:
> > It would be ncie to install this documentation somewhere suitable.  As
> > manpages would be ideal, assuming the .rst files are suitable for
> > that, but HTML in /usr/share/doc/ would do nicely as well.
>
> libuv documentation can indeed be built as HTML files.
>
> However, lintian then complains about vendored js files and about privacy
> breach:
>
> W: libuv1-dev: embedded-javascript-library please use libjs-jquery
> [usr/share/doc/libuv1-dev/html/_static/jquery.js]
> N:
> N:   This package contains an embedded copy of JavaScript libraries that
> are
> N:   now available in their own packages (for example, JQuery, Prototype,
> N:   Mochikit or "Cropper"). Please depend on the appropriate package and
> N:   symlink the library into the appropriate location.
> N:
> N:   Please refer to Embedded code copies (Section 4.13) in the Debian
> Policy
> N:   Manual for details.
> N:
> N:   Visibility: warning
> N:   Show-Always: no
> N:   Check: languages/javascript/embedded
> N:
> N:
> W: libuv1-dev: embedded-javascript-library please use libjs-underscore
> [usr/share/doc/libuv1-dev/html/_static/underscore.js]
> N:
> W: libuv1-dev: embedded-javascript-library please use sphinx
> [usr/share/doc/libuv1-dev/html/_static/doctools.js]
> N:
> W: libuv1-dev: embedded-javascript-library please use sphinx
> [usr/share/doc/libuv1-dev/html/_static/language_data.js]
> N:
> W: libuv1-dev: embedded-javascript-library please use sphinx
> [usr/share/doc/libuv1-dev/html/_static/searchtools.js]
> N:
> W: libuv1-dev: privacy-breach-generic [ height="315"\nsrc="https://www.youtube-nocookie.com/embed/ngn60vdsxq4;
> frameborder="0"\nallowfullscreen>] (
> https://www.youtube-nocookie.com/embed/ngn60vdsxq4)
> [usr/share/doc/libuv1-dev/html/guide/basics.html]
> N:
> N:   This package creates a potential privacy breach by fetching data from
> an
> N:   external website at runtime. Please remove these scripts or external
> HTML
> N:   resources.
> N:
> N:   Please replace any scripts, images, or other remote resources with
> N:   non-remote resources. It is preferable to replace them with text and
> links
> N:   but local copies of the remote resources are also acceptable as long
> as
> N:   they don't also make calls to remote services. Please ensure that the
> N:   remote resources are suitable for Debian main before making local
> copies
> N:   of them.
> N:
> N:   Visibility: warning
> N:   Show-Always: no
> N:   Check: files/privacy-breach
> N:
>
> Since these docs are available online, I won't invest more time in fixing
> these issues and will continue to ship libuv1-dev without HTML doc.
>

Hi,

actually dh-sphinxdoc takes care of all this !

I made a merge request here, that adds a libuv1-doc package and patch a
small issue with privacy breach:
https://salsa.debian.org/debian/libuv1/-/merge_requests/2

Regards,
Jérémy

Bug#1069598: missing files on smb shares with linux kernel 6.1.0-20

[Bastian Kleineidam]

Hi,

I can reproduce this error when running linux-image-6.1.0-20-amd64: some
files on mounted smb shares are not visible.
These are the log entries on a client maching (not the server), when
trying to access the missing files on a mounted cifs share:

CIFS: VFS: directory entry name would overflow frame end of buf
7153a3e1
[... repeated several times ...]

There are no such errors and no missing files when downgrading to
linux-image-6.1.0-18-amd64 on the client (the server is still running
kernel version 6.1.0-20).

I guess there is a new but sometimes broken overflow detection in the
cifs filesystem code.

Regards,
Bastian

Bug#1069415: libsoup2.4: FTBFS on arm64: dh_auto_test: error: cd obj-aarch64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 meson test returned exit code 29

[Santiago Vila]

retitle 1069415 libsoup2.4: FTBFS: failing tests
thanks

El 24/4/24 a las 18:26, Andreas Metzler escribió:

On 2024-04-20 Lucas Nussbaum  wrote:

Source: libsoup2.4
Version: 2.74.3-7
Severity: serious
Justification: FTBFS

[...]

(hsts-test:547071): GLib-Net-WARNING **: 04:03:06.247: Failed to load TLS 
database: System trust contains zero trusted certificates; please investigate 
your GnuTLS configuration


FWIW I could not reproduce this on amdahl.debian.org, the build
succeeded.


This is not arm64-specific. It also happens on amd64:

See how the autobuilder for Arch:all had to try 3 times to build the package:

https://buildd.debian.org/status/logs.php?pkg=libsoup2.4=2.74.3-7=all

If you want to debug it or just verify that the test fails very easily on 
certain
machines, contact me privately and I will gladly give you access to a machine
where it happens all the time.

In my opinion, the test has a very low quality, so if there is not willingness,
capacity, or just time to fix it (which is fine), then it should be disabled,
because in its current state it is a waste of time for everybody.

No, I don't buy the theory that this is a good way to "remind" that there
is a flaky test. A Release Manager made a similar request ("fix it or disable 
it")
in Bug #1057562 but the bug was downgraded again and the request from the 
Release
Manager continues to be ignored.

Thanks.

Bug#1069781: openafs kernel module not loadable on ARM64 Bookworm

[Clark Boylan]

Package: openafs-modules-dkms
Version: 1.8.9-1
Tags: upstream, patch

Debian Bookworm builds the openafs kernel module with GCC 12. This version of 
GCC produces a kernel module with ARM64 position independent code instructions 
that are rejected by the Linux kernel which prevents the module from being 
loadable on ARM64. This problem was first debugged by NixOS [0] and eventually 
fixed upstream with this change [1].

Can we backport this fix into Bookworm's openafs packaging to enable openafs on 
ARM64 Debian?

[0] https://github.com/NixOS/nixpkgs/issues/284501
[1] https://gerrit.openafs.org/#/c/15668/

Side note: The code in question is identical in Bullseye's openafs kernel 
module version as well. The problem seems to be produced by the newer compiler 
toolchain on Bookworm.

Bug#1065100: efingerd: Depends on libident, which is NBS

[Chris Hofstaedtler]

Control: reassign -1 release.debian.org
Control: retitle -1 nmu: efingerd_1.6.7-1
Control: severity -1 normal

On Thu, Feb 29, 2024 at 02:41:54PM -0500, Boyuan Yang wrote:
> Severity: serious
> Justification: Policy 2.2.1
> 
> Package efingerd depends on binary package libident, but this package has
> been renamed to libident0 due to time64 transition.
...
> You may need to rebuild the package.

This should just have been filed as a binNMU request to
release.debian.org. There was no need to remove the package from
testing. A local no-change rebuild shows that it picks up the new
libident0 name just fine.

Release team, please schedule binNMU for this package.


Chris

Bug#1069780: RM: luajit2 -- ROM; ROM; duplicate source

[M. Zhou]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: luaj...@packages.debian.org
Control: affects -1 + src:luajit2
User: ftp.debian@packages.debian.org
Usertags: remove

Dear ftp masters,

The src:luajit2 is now a redundant package given that the upstream of
src:luajit has been replaced into the upstream of src:luajit2. In that
sense src:luajit and src:luajit2 are the identical source now. We do
not need to keep both.

Before removing src:luajit2 from unstable, we still need to make the
reverse build dependencies of src:luajit2 depend on src:luajit instead.
I'll later file the corresponding bugs and let them block this one.

Thank you for using reportbug

Bug#1069779: debirf: Remove this package?

[Chris Hofstaedtler]

Source: debirf
Severity: important

debirf did not make it into bullseye or bookworm. It is currently not in
testing, and has not been for over 3.5 years.

Is it time to remove debirf from Debian?

If you intend to maintain this package, please fix the open RC bugs and
then close this bug too. Otherwise I propose to reassign this bug to
ftp.debian.org for removal.

Chris

Bug#1063758: spamd: /etc/init.d/spamd still uses --name instead of --exec

[Noah Meyerhans]

On Wed, Apr 24, 2024 at 10:02:47AM +0200, Alessandro Vesely wrote:
> > > Stopping S.M.A.R.T. daemon smartd.
> > > Stopping SpamAssassin Mail Filter Daemon spamd.
> > > start-stop-daemon: warning: this system is not able to track process names
> > > longer than 15 characters. please use --exec instead of --name.
> > > 
> > > Next it hangs there for several seconds (~30).  The next string says:
> > > 
> > > Asking all remaining processes to terminate...done.
> > > 
> > > Is it not SpamAssassin causing that warning?
> > 
> > If it is, it doesn't do it on Debian.  Even with sysvinit, though, the
> > stop jobs during shutdown run in parallel, so that message may be coming
> > from somewhere else.
> > 
> > If you manually stop spamassassin with `/etc/init.d/spamd stop`, do you
> > get the same warning?
> 
> 
> Good question!  No, I don't.  It stops cleanly and quickly.

You may need to stop/start each service individually to find the
culprit.  We can reassign this bug accordingly when you do.

noah

Bug#1069768: dropbear-initramfs becomes unresponsive after several connection attempts

[Guilhem Moulin]

Control: tag -1 - moreinfo unreproducible

On Wed, 24 Apr 2024 at 17:10:57 +0200, Guilhem Moulin wrote:
>> It should be trivially reproducible by running `ssh -o ServerAliveCountMax=3
>> -o ServerAliveInterval=1 root@yourdropbearserver`. The client should then
>> disconnect after 3 seconds.
> 
> Seems to work as expected for me:
> 
>   $ ssh -oLogLevel=DEBUG3 \
>   -oServerAliveCountMax=3 -oServerAliveInterval=1 \
>   -oUserKnownHostsFile=/tmp/known_hosts \
>   -i /tmp/test.key \
>   -l user -p 10022 127.0.0.1 sleep 300
>   […]

No wait, this works in the main system but indeed at initramfs stage the
client doesn't get responses to its alive probes.  My bad for assuming
the behavior would be the same given it's the same binary.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1069415: libsoup2.4: FTBFS on arm64: dh_auto_test: error: cd obj-aarch64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 meson test returned exit code 29

[Andreas Metzler]

On 2024-04-20 Lucas Nussbaum  wrote:
> Source: libsoup2.4
> Version: 2.74.3-7
> Severity: serious
> Justification: FTBFS
[...]
> > (hsts-test:547071): GLib-Net-WARNING **: 04:03:06.247: Failed to load TLS 
> > database: System trust contains zero trusted certificates; please 
> > investigate your GnuTLS configuration

FWIW I could not reproduce this on amdahl.debian.org, the build
succeeded.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#1064920: FTBFS on 32-bit architectures

[Taihsiang Ho (tai271828)]

Status update: the previous pull request would create version
2.0.20+debian-2 but it only includes the fix for armhf. i386 needs to
be fixed as well
https://buildd.debian.org/status/logs.php?pkg=rshim-user-space=i386
. I will make another merge request to include the fix for i386. -tai

On Mon, Apr 22, 2024 at 8:00 PM Taihsiang Ho (tai271828)  
wrote:
>
> I created a pull request to fix the build issue. Please review
> https://salsa.debian.org/bluefield-team/rshim-user-space/-/merge_requests/11
> -tai
>
> On Tue, Feb 27, 2024 at 7:27 PM dann frazier  wrote:
> >
> > Source: rshim-user-space
> > Version: 2.0.12+debian-1
> > Severity: serious
> > Tags: ftbfs
> > Justification: fails to build from source (but built successfully in the 
> > past)
> >
> > The switch to fuse3 appears to have introduced a build issue for 32-bit
> > architectures such as armhf:
> >
> > From 
> > https://buildd.debian.org/status/fetch.php?pkg=rshim-user-space=armhf=2.0.20%2Bdebian-1=1709056732=0
> >  :
> >
> > gcc -DHAVE_CONFIG_H -I. -I..  -Wall -DHAVE_RSHIM_NET 
> > -I/usr/include/libusb-1.0  -DHAVE_RSHIM_USB 
> > -I/usr/include/arm-linux-gnueabihf  -DHAVE_RSHIM_PCIE -I/usr/include/fuse3  
> > -DHAVE_RSHIM_FUSE -Wdate-time -D_FORTIFY_SOURCE=2 -DFUSE_USE_VERSION=30 
> > -DDEFAULT_RSHIM_CONFIG_FILE='"/etc/rshim.conf"'  -g -O2 
> > -ffile-prefix-map=/<>=. -fstack-protector-strong 
> > -fstack-clash-protection -Wformat -Werror=format-security -c -o 
> > rshim-rshim_fuse.o `test -f 'rshim_fuse.c' || echo './'`rshim_fuse.c
> > In file included from /usr/include/fuse3/fuse_lowlevel.h:25,
> >  from /usr/include/fuse3/cuse_lowlevel.h:19,
> >  from rshim_fuse.c:23:
> > /usr/include/fuse3/fuse_common.h:928:1: error: static assertion failed: 
> > "fuse: off_t must be 64bit"
> >   928 | _Static_assert(sizeof(off_t) == 8, "fuse: off_t must be 64bit");
> >   | ^~
> > rshim_pcie.c: In function ‘rshim_pcie_mmap_vfio’:
> > rshim_pcie.c:52:37: warning: overflow in conversion from ‘long long 
> > unsigned int’ to ‘__off_t’ {aka ‘long int’} changes value from 
> > ‘7696581394436’ to ‘4’ [-Woverflow]
> >52 | #define VFIO_GET_REGION_ADDR(x) ((uint64_t) x << 40ULL)
> >   | ^
> > rshim_pcie.c:634:18: note: in expansion of macro ‘VFIO_GET_REGION_ADDR’
> >   634 |  VFIO_GET_REGION_ADDR(VFIO_PCI_CONFIG_REGION_INDEX) 
> > +
> >   |  ^~~~
> > rshim_pcie.c:52:37: warning: overflow in conversion from ‘long long 
> > unsigned int’ to ‘__off_t’ {aka ‘long int’} changes value from 
> > ‘7696581394436’ to ‘4’ [-Woverflow]
> >52 | #define VFIO_GET_REGION_ADDR(x) ((uint64_t) x << 40ULL)
> >   | ^
> > rshim_pcie.c:643:19: note: in expansion of macro ‘VFIO_GET_REGION_ADDR’
> >   643 |   
> > VFIO_GET_REGION_ADDR(VFIO_PCI_CONFIG_REGION_INDEX) +
> >   |   ^~~~
> > rshim_fuse.c: In function ‘rshim_fuse_misc_read’:
> > rshim_fuse.c:713:36: warning: format ‘%ld’ expects argument of type ‘long 
> > int’, but argument 5 has type ‘uint64_t’ {aka ‘long long unsigned int’} 
> > [-Wformat=]
> >   713 |   n = snprintf(p, len, "%-16s%ld(s)\n", "UP_TIME", 
> > value/BF3_REF_CLK_IN_HZ);
> >   |  ~~^
> >   ||
> >   |long int
> >   |  %lld
> > rshim_fuse.c: In function ‘rshim_fuse_misc_write’:
> > rshim_fuse.c:954:25: warning: format ‘%lx’ expects argument of type ‘long 
> > unsigned int *’, but argument 3 has type ‘uint64_t *’ {aka ‘long long 
> > unsigned int *’} [-Wformat=]
> >   954 | if (sscanf(p, " 0x%lx", ) != 1)
> >   |   ~~^   ~~
> >   | |   |
> >   | |   uint64_t * {aka long long unsigned int 
> > *}
> >   | long unsigned int *
> >   |   %llx
> > make[3]: *** [Makefile:524: rshim-rshim_fuse.o] Error 1
> >
> >
> > -- System Information:
> > Debian Release: trixie/sid
> >   APT prefers unstable-debug
> >   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), 
> > (1, 'experimental-debug'), (1, 'experimental')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> >
> > Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT)
> > Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
> > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE 
> > not set
> > Shell: /bin/sh linked to /usr/bin/dash
> > Init: systemd (via /run/systemd/system)
> > LSM: AppArmor: enabled

Bug#1069768: dropbear-initramfs becomes unresponsive after several connection attempts

[Lee Garrett]

On 24.04.24 17:10, Guilhem Moulin wrote:

On Wed, 24 Apr 2024 at 16:32:09 +0200, Lee Garrett wrote:

Although the dropbear man page is not explicit, I'm assuming it refers to
TCP keepalive.


I think this assumption is incorrect:
https://sources.debian.org/src/dropbear/2024.84-1/src/common-session.c/#L497


It should be trivially reproducible by running `ssh -o ServerAliveCountMax=3
-o ServerAliveInterval=1 root@yourdropbearserver`. The client should then
disconnect after 3 seconds.


Seems to work as expected for me:

$ ssh -oLogLevel=DEBUG3 \
 -oServerAliveCountMax=3 -oServerAliveInterval=1 \
 -oUserKnownHostsFile=/tmp/known_hosts \
 -i /tmp/test.key \
 -l user -p 10022 127.0.0.1 sleep 300
[…]
debug1: Sending command: sleep 300
debug2: channel 0: request exec confirm 1
debug3: send packet: type 98
debug3: client_repledge: enter
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 65536 rmax 32759
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
debug3: send packet: type 80
debug3: receive packet: type 82
debug3: send packet: type 80
debug3: receive packet: type 82
debug3: send packet: type 80
debug3: receive packet: type 82
debug3: send packet: type 80
debug3: receive packet: type 82
[…]
debug3: send packet: type 80
debug3: receive packet: type 82
debug3: receive packet: type 96
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: chan_shutdown_write: channel 0: (i0 o1 sock -1 wfd 5 efd 6 
[write])
debug2: channel 0: output drain -> closed
debug3: receive packet: type 98
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug3: receive packet: type 97
debug2: channel 0: rcvd close
debug2: chan_shutdown_read: channel 0: (i0 o3 sock -1 wfd 4 efd 6 
[write])
debug2: channel 0: input open -> closed
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug3: send packet: type 97
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 [session] r0 i3/0 o3/0 e[write]/0 fd -1/-1/6 
sock -1 cc -1 io 0x00/0x00)

debug3: send packet: type 1
Transferred: sent 15360, received 7448 bytes, in 300.0 seconds
Bytes per second: sent 51.2, received 24.8
debug1: Exit status 0

There is one packet 80/82 exchange per second until the `sleep 300`
terminates.  The output is similar with OpenSSH's sshd.



Thanks for debugging this. Then I'll have to try and reproduce this on my remote 
server when I find time. Unfortuntely it might take a few days as I need the 
services on it for now. Thanks again for the swift response!

Bug#1030389: [pkg-lxc-devel] Bug#1030389: lxc: Conflict with new systemd cgroup unified hierarchy

[Linas Vepstas]

I'm not using unprivileged containers. They are root containers, and they
are marked to auto-start when the machine boots.

I'm being aggressive because I'm really angry. I ditched windows for linux
25 years ago, because linux was really better. It was a joy to use. It
reached an all-time peak around 2005, when one could install Ubuntu and
everything just worked instantly and painlessly. Ever since then it has
been a slow decay, getting less and less stable, harder to use and diagnose
and keep running.

I don't appreciate your saying that I "dug a hole for myself". You're the
guys digging the holes. I am not the one who opened
https://github.com/systemd/systemd/issues/13477 -- someone else did that
three years ago. I am not the one who opened
https://github.com/lxc/lxc/issues/4072 -- someone else did that a year ago.
I'm just using search engines to figure out why this and other serious
fundamental bugs halted a reboot.  Stop blaming me for the mess.

-- Linas

Bug#1030389: [pkg-lxc-devel] Bug#1030389: lxc: Conflict with new systemd cgroup unified hierarchy

[Pierre-Elliott Bécue]

Linas Vepstas  wrote on 07/02/2023 at 00:05:04+0100:

> I'm not using unprivileged containers. They are root containers, and
> they are marked to auto-start when the machine boots.
>
> I'm being aggressive because I'm really angry. I ditched windows for
> linux 25 years ago, because linux was really better. It was a joy to
> use. It reached an all-time peak around 2005, when one could install
> Ubuntu and everything just worked instantly and painlessly. Ever since
> then it has been a slow decay, getting less and less stable, harder to
> use and diagnose and keep running.

If you mean that complex systems bring more complex issues, then I can
only agree.

What we could do in 2005 is just orders of magnitude less than what we
can do now with a Linux Distro. Yes it has some drawbacks. That being
said, most of the things can be avoided with proper doc reading.

> I don't appreciate your saying that I "dug a hole for myself". You're
> the guys digging the holes.

Not really, no. We are the guys packaging software. This software
changes and therefore we have to cope with these changes.

> I am not the one who opened
> https://github.com/systemd/systemd/issues/13477 -- someone else did
> that three years ago.

I don't know what your point is.

> I am not the one who opened https://github.com/lxc/lxc/issues/4072 --
> someone else did that a year ago.

Same. Yes, people meet issues due to software changes, it's the course
of life.

> I'm just using search engines to figure out why this and other serious
> fundamental bugs halted a reboot.

Nothing here is a bug. Systemd chose to enable by default cgroups v2 in
Debian 11, and this had some consequences that were handled. These
consequences were properly advertised by the means we use to advertise
breaking changes.

> Stop blaming me for the mess.

I'm blaming you for trying to blame others for an unproperly done dist
upgrade. This is your responsibility to read changelogs, read the
documentation, and do a proper upgrade testing that anything works fine
afterwards. This is not ours.

-- 
PEB


signature.asc
Description: PGP signature

Bug#1069753: libuv1: y2k38 known upstream issue on 32-bits archs

[Dominique Dumont]

On Wednesday, 24 April 2024 09:48:55 CEST you wrote:
> on 32-bits archs, nodejs fails some y2k38 tests.
> 
> It is a well-known issue that has been fixed in libuv master branch,
> https://github.com/libuv/libuv/issues/3864
> but might not be fixed anytime soon in 1.x branch.
> 
> Indeed, fixing it breaks API.
> 
> However, in Debian, I think we can just do that, as long as we patch
> reverse dependencies on libuv1.

I disagree. Some people may be using libuv1 in a program not handled by 
Debian.

Breaking the API means changing the SONAME of the lib. According to Debian 
policy, this means creating a libuv2 package.

> What do you think about that ?

We should wait for an upstream libuv v2.

All the best.

Bug#1030389: [pkg-lxc-devel] Bug#1030389: lxc: Conflict with new systemd cgroup unified hierarchy

[Pierre-Elliott Bécue]

Linas Vepstas  wrote on 07/02/2023 at 00:35:18+0100:

> There is nothing in /usr/share/doc/lxc/README.Debian.gz that provides
> the work-around. I am using containers managed by root, started when
> the OS boots.
>
> su - root and then lxc-ls -f reports 
>
> NAMESTATE   AUTOSTART GROUPS IPV4  IPV6 UNPRIVILEGED 
> bind-base   STOPPED 0 -  - -false
>
> Note the right-most column. Nothing in the README about "unprivileged
> containers" would seem to apply.
>
> apparmor is not installed on this system.
>
> The only work-around given in the two github issues is to set 

I also succeed at running privileged containers on my system.

Could you print your container config to me please? It's possible some
things in your config are conflicting with cgroups v2.

> GRUB_CMDLINE_LINUX=systemd.unified_cgroup_hierarchy=false
>
> in /etc/default/grub.d/cgroup.cfg and the Debian README does not mention this 
> work-around. 
>
> Perhaps it is possible to put systemd.unified_cgroup_hierarchy=false
> into /etc/sysctl.conf ? Or perhaps some other config file?

systemd.unified_cgroup_hierarchy=false looks like a kernel command line,
I doubt it can be done after having booted.

> There is another work-around:
>
> mkdir -p /sys/fs/cgroup/systemd && mount -t cgroup cgroup -o
> none,name=systemd /sys/fs/cgroup/systemd
>
> However, sticking this mkdir into some /etc/init.d file does not seem
> plausible for a server; it feels too hacky.

-- 
PEB


signature.asc
Description: PGP signature

Bug#1030389: [pkg-lxc-devel] Bug#1030389: lxc: Conflict with new systemd cgroup unified hierarchy

[Linas Vepstas]

The documentation does not provide any solutions to this bug. Nothing in
the README will solve the bug. This is a real bug.   --linas

Bug#1030389: [pkg-lxc-devel] Bug#1030389: lxc: Conflict with new systemd cgroup unified hierarchy

[Linas Vepstas]

There is nothing in /usr/share/doc/lxc/README.Debian.gz that provides the
work-around.  I am using containers managed by root, started when the OS
boots.

su - root and then lxc-ls -f reports

NAMESTATE   AUTOSTART GROUPS IPV4  IPV6 UNPRIVILEGED
bind-base   STOPPED 0 -  - -false

Note the right-most column. Nothing in the README about "unprivileged
containers" would seem to apply.

apparmor is not installed on this system.

The only work-around given in the two github issues is to set

GRUB_CMDLINE_LINUX=systemd.unified_cgroup_hierarchy=false

in /etc/default/grub.d/cgroup.cfg and the Debian README does not mention
this work-around.

Perhaps it is possible to put systemd.unified_cgroup_hierarchy=false into
/etc/sysctl.conf ? Or perhaps some other config file?

There is another work-around:

mkdir -p /sys/fs/cgroup/systemd && mount -t cgroup cgroup -o
none,name=systemd /sys/fs/cgroup/systemd

However, sticking this mkdir into some /etc/init.d file does not seem
plausible for a server; it feels too hacky.

--linas

Bug#1069768: dropbear-initramfs becomes unresponsive after several connection attempts

[Guilhem Moulin]

On Wed, 24 Apr 2024 at 16:32:09 +0200, Lee Garrett wrote:
> Although the dropbear man page is not explicit, I'm assuming it refers to
> TCP keepalive.

I think this assumption is incorrect:
https://sources.debian.org/src/dropbear/2024.84-1/src/common-session.c/#L497

> It should be trivially reproducible by running `ssh -o ServerAliveCountMax=3
> -o ServerAliveInterval=1 root@yourdropbearserver`. The client should then
> disconnect after 3 seconds.

Seems to work as expected for me:

$ ssh -oLogLevel=DEBUG3 \
-oServerAliveCountMax=3 -oServerAliveInterval=1 \
-oUserKnownHostsFile=/tmp/known_hosts \
-i /tmp/test.key \
-l user -p 10022 127.0.0.1 sleep 300
[…]
debug1: Sending command: sleep 300
debug2: channel 0: request exec confirm 1
debug3: send packet: type 98
debug3: client_repledge: enter
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 65536 rmax 32759
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
debug3: send packet: type 80
debug3: receive packet: type 82
debug3: send packet: type 80
debug3: receive packet: type 82
debug3: send packet: type 80
debug3: receive packet: type 82
debug3: send packet: type 80
debug3: receive packet: type 82
[…]
debug3: send packet: type 80
debug3: receive packet: type 82
debug3: receive packet: type 96
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: chan_shutdown_write: channel 0: (i0 o1 sock -1 wfd 5 efd 6 
[write])
debug2: channel 0: output drain -> closed
debug3: receive packet: type 98
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug3: receive packet: type 97
debug2: channel 0: rcvd close
debug2: chan_shutdown_read: channel 0: (i0 o3 sock -1 wfd 4 efd 6 
[write])
debug2: channel 0: input open -> closed
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug3: send packet: type 97
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 [session] r0 i3/0 o3/0 e[write]/0 fd -1/-1/6 
sock -1 cc -1 io 0x00/0x00)

debug3: send packet: type 1
Transferred: sent 15360, received 7448 bytes, in 300.0 seconds
Bytes per second: sent 51.2, received 24.8
debug1: Exit status 0

There is one packet 80/82 exchange per second until the `sleep 300`
terminates.  The output is similar with OpenSSH's sshd.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1069735: general: atlantic driver doesn't work on thinkpad

[Benjamin Gounine]

Hello,


I finnaly solved the problem.

I installed the "thunderbolt-tools" package and got more errors in the 
syslog.



```

Apr 24 15:03:53 Elliot tbtacl: 3913: not in ACL

```

While searching on google I came across this github issue


https://github.com/intel/thunderbolt-software-user-space/issues/24


I ran the "tbtadm devices" command to list my device and I ran the 
"tbtadm approve 0-1" command to approve the loading of the module


My Aquantia AQC107 device is now visible and the network connection works


```

root@Elliot:/home/prunus# lspci -tv
-[:00]-+-00.0 Intel Corporation Coffee Lake HOST and DRAM Controller
+-02.0  Intel Corporation WhiskeyLake-U GT2 [UHD Graphics 620]
+-04.0  Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core 
Processor Thermal Subsystem
+-08.0  Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th/8th 
Gen Core Processor Gaussian Mixture Model

+-12.0  Intel Corporation Cannon Point-LP Thermal Controller
+-14.0  Intel Corporation Cannon Point-LP USB 3.1 xHCI Controller
+-14.2  Intel Corporation Cannon Point-LP Shared SRAM
+-14.3  Intel Corporation Cannon Point-LP CNVi [Wireless-AC]
+-15.0  Intel Corporation Cannon Point-LP Serial IO I2C Controller #0
+-16.0  Intel Corporation Cannon Point-LP MEI Controller #1
+-1c.0-[01]00.0  Genesys Logic, Inc GL9750 SD Host Controller
+-1c.4-[02-3a]00.0-[03-3a]--+-00.0-[04]00.0  Intel Corporation 
JHL6240 Thunderbolt 3 NHI (Low Power) [Alpine Ridge LP 2016]
| +-01.0-[05-39]00.0-[06-07]01.0-[07]00.0  Aquantia Corp. 
AQtion AQC107S NBase-T/IEEE 802.3an Ethernet Controller [Atlantic 10G]
|   \-02.0-[3a]00.0  Intel Corporation 
JHL6240 Thunderbolt 3 USB 3.1 Controller (Low Power) [Alpine Ridge LP 2016]

+-1d.0-[3c]--
+-1d.4-[3d]00.0  Micron/Crucial Technology P2 [Nick P2] / P3 / P3 
Plus NVMe PCIe SSD (DRAM-less)

+-1f.0  Intel Corporation Cannon Point-LP LPC Controller
+-1f.3  Intel Corporation Cannon Point-LP High Definition Audio Controller
+-1f.4  Intel Corporation Cannon Point-LP SMBus Controller
+-1f.5  Intel Corporation Cannon Point-LP SPI Controller
\-1f.6  Intel Corporation Ethernet Connection (6) I219-V
root@Elliot:/home/prunus# modinfo atlantic
filename: 
/lib/modules/6.6.15-amd64/kernel/drivers/net/ethernet/aquantia/atlantic/atlantic.ko.xz

description: Marvell (Aquantia) Corporation(R) Network Driver
author: Marvell
license: GPL v2
alias: pci:v1D6Ad11C0sv*sd*bc*sc*i*
alias: pci:v1D6Ad34C0sv*sd*bc*sc*i*
alias: pci:v1D6Ad12C0sv*sd*bc*sc*i*
alias: pci:v1D6Ad14C0sv*sd*bc*sc*i*
alias: pci:v1D6Ad04C0sv*sd*bc*sc*i*
alias: pci:v1D6Ad93C0sv*sd*bc*sc*i*
alias: pci:v1D6Ad94C0sv*sd*bc*sc*i*
alias: pci:v1D6Ad00C0sv*sd*bc*sc*i*
alias: pci:v1D6Ad92B1sv*sd*bc*sc*i*
alias: pci:v1D6Ad91B1sv*sd*bc*sc*i*
alias: pci:v1D6Ad89B1sv*sd*bc*sc*i*
alias: pci:v1D6Ad88B1sv*sd*bc*sc*i*
alias: pci:v1D6Ad87B1sv*sd*bc*sc*i*
alias: pci:v1D6Ad80B1sv*sd*bc*sc*i*
alias: pci:v1D6Ad12B1sv*sd*bc*sc*i*
alias: pci:v1D6Ad11B1sv*sd*bc*sc*i*
alias: pci:v1D6Ad09B1sv*sd*bc*sc*i*
alias: pci:v1D6Ad08B1sv*sd*bc*sc*i*
alias: pci:v1D6Ad07B1sv*sd*bc*sc*i*
alias: pci:v1D6Ad00B1sv*sd*bc*sc*i*
alias: pci:v1D6AdD109sv*sd*bc*sc*i*
alias: pci:v1D6AdD108sv*sd*bc*sc*i*
alias: pci:v1D6AdD107sv*sd*bc*sc*i*
alias: pci:v1D6AdD100sv*sd*bc*sc*i*
alias: pci:v1D6Ad0001sv*sd*bc*sc*i*
depends: macsec
retpoline: Y
intree: Y
name: atlantic
vermagic: 6.6.15-amd64 SMP preempt mod_unload modversions
sig_id: PKCS#7
signer: Build time autogenerated kernel key
sig_key: 21:EC:AB:7F:99:B0:2B:29:F0:14:9D:30:26:B6:2F:1B:F0:91:ED:13
sig_hashalgo: sha256
signature: 30:65:02:31:00:C5:7E:D8:EA:3A:0A:D9:65:E4:44:64:B7:AD:C6:58:
83:27:E6:87:BE:DB:4C:F8:17:68:D1:CE:CA:49:45:27:17:20:9A:67:
3B:0C:FC:77:A6:D1:DB:B8:C1:A0:1E:4D:CA:02:30:1A:43:B0:9C:14:
10:A3:A9:B7:A4:11:E6:69:4F:43:46:55:08:AF:9B:11:08:25:78:58:
68:E0:A4:32:CB:53:4E:7D:34:BF:7B:11:C8:E2:AA:46:C7:4F:96:CF:
55:94:73
parm: aq_itr:Interrupt throttling mode (uint)
parm: aq_itr_tx:TX interrupt throttle rate (uint)
parm: aq_itr_rx:RX interrupt throttle rate (uint)


root@Elliot:/home/prunus# dmesg

[...]

[   51.880093] thunderbolt 0-1: new device found, vendor=0x8 device=0x34
[   51.880104] thunderbolt 0-1: Sonnet Technologies, Inc Solo 10G 
Thunderbolt 3 Edition

[   51.961231] pcieport :03:01.0: pciehp: Slot(1): Card present
[   51.961235] pcieport :03:01.0: pciehp: Slot(1): Link Up
[   52.094948] pci :05:00.0: [8086:15da] type 01 class 0x060400
[   52.095075] pci :05:00.0: enabling Extended Tags
[   52.095348] pci :05:00.0: supports D1 D2
[   52.095352] pci :05:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[   52.095549] pci :05:00.0: 8.000 Gb/s available PCIe bandwidth, 
limited by 2.5 GT/s PCIe x4 link at :03:01.0 (capable of 31.504 Gb/s 
with 

Bug#1021605: persepolis: Systemd dependencies

[Boyuan Yang]

X-Debbugs-CC: bardot.jer...@gmail.com

Hi,

On Tue, 11 Oct 2022 19:26:21 +0200 Bardot Jerome  
wrote:
> Package: persepolis
> Version: 3.0.1-1.1
> Severity: important
> X-Debbugs-Cc: bardot.jer...@gmail.com
> 
> Dear Maintainer,
> 
> It's look like the package need systemd … (throught recommends)
> Can you please fix it ?
> 
> A default installation should not rely on a specific software that can break
> all others software.

First of all, having a default status of needing systemd is not a big issue. It 
is not
hard dependency, so you always have the choice to uninstall any package 
recommendation
that needs systemd.

Secondly, I did not see that installing persepolis will introduce systemd 
itself. It
seems that only libsystemd library will be introduced due to dynamic library
dependency. Having libsystemd library installed is harmless because the library 
will
not do anything useful if systemd is not running. Please correct me if my 
observation
is wrong.

Finally, I have no idea on how to properly avoid systemd as you requested since 
all
packages listed in the Recommends field are legit, and removing or demoting any 
of them
are not reasonable. Do you have a good patch that can be used? I would be happy 
to take
patches if it could properly avoid introducing systemd by default without 
losing any of
persepolis' upstream-provided functionality.

Thanks,
Boyuan Yang


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

Bug#997948: FPC should provide a way to trigger automatic rebuild of

[Peter Blackman]

On 18/06/2023 09:45, Abou Al Montacir wrote:
However, fpc units are kind of statically linked libraries. And in 
this case, one ma want a rebuild of all reverse dependencies in order 
to ensure a bug fix is propagated on all binaries.


Example: Suppose we discover a vulnerability in a unit. We want that 
all units and all programs that use it be rebuilt, no?





Setting the 'Static-Built-Using' field in the control files of packages 
built with fpc should fix this.


Cheers,
Peter

Bug#1041415: details

[Aurelien Jarno]

control: tag -1 + fixed-upstream

On 2024-04-23 16:22, David Edmondson wrote:
> tag 1041415 - upstream
> thanks
> 
> Ultimately this fails because /proc is not available in the chroot.
> 
> The version of libc in use *emulates* fchmodat() using /proc/self/fd
> rather than using the fchmodat system call.

It is emulated, because support for flags != 0 is something new, and
requires the fchmodat2 syscall that has been added in Linux kernel
version 6.6. On the glibc side, support has been added in glibc 2.39,
which is available in git [1], but unfortunately not yet in sid due to
binutils/valgrind bug [2] and time_t transition [3] blocking things.

Regards
Aurelien

[1] https://salsa.debian.org/glibc-team/glibc/-/tree/glibc-2.39
[2] https://bugs.debian.org/1057693
[3] https://bugs.debian.org/1059852

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

Bug#1069768: dropbear-initramfs becomes unresponsive after several connection attempts

[Lee Garrett]

On 24.04.24 16:15, Guilhem Moulin wrote:

Control: tag -1 unreproducible moreinfo

Hi,

On Wed, 24 Apr 2024 at 14:42:43 +0200, Lee Garrett wrote:

After some debugging, it turns out that ServerAliveInterval != 0 will cause the
ssh client to reset the connection, which dropbear will count as unlock attempt,
and after three tries it will fail and drop to initramfs shell, after which it's
not reachable anymore.


AFAICT dropbear does support timeout messages (see -K in the manual).
I'm unable to reproduce the issue anyway, do you start dropbear with -I?

Can you try to start your client with -oLogLevel=DEBUG3 to see why the
connection is terminated (from the client's perspective)?  Also to take
cryptroot out of the picture you could try using `cat -A` as the remote
command.



Although the dropbear man page is not explicit, I'm assuming it refers to TCP 
keepalive.


The settings ServerAliveCountMax and ServerAliveInterval on the ssh client 
however explicitely refer to SSH keepalive. To quote the man page:


"Sets the number of server alive messages (see below) which may be sent without 
ssh(1) receiving any messages back from the server.  If this threshold is 
reached while server alive messages are being sent, ssh will disconnect from the 
server, terminating the session.  It is important to note that the use of server 
alive messages is very different from TCPKeepAlive (below)."


It should be trivially reproducible by running `ssh -o ServerAliveCountMax=3 -o 
ServerAliveInterval=1 root@yourdropbearserver`. The client should then 
disconnect after 3 seconds.

Bug#1069256: debian-policy: clarify requirement for use of Static-Built-Using

[Peter B]

Regarding ;-

"(for example linking against static libraries, builds for
 source-centered languages such as Go or Rust, usage of header-only
 C/C++ libraries, injecting data blobs into code, etc.)"

Perhaps Pascal & Lazarus could be added to that list for clarity? [1]


Regards,
Peter

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

Bug#1069247: libconfig-model-dpkg-perl: test failures

[gregor herrmann]

Control: reassign 1069247 apt 2.9.0
Control: reassign 1069246 apt 2.9.0
Control: forcemerge 1069247 1069246
Control: retitle 1069247 apt: apt 2.9.0's output breaks libapt-pkg-perl
Control: affects 1069247 + libapt-pkg-perl libconfig-model-dpkg-perl 
dh-make-perl
Control: tag 1069247 = sid
Control: fixed 1069247 2.9.2

On Mon, 22 Apr 2024 19:44:38 +0200, Julian Andres Klode wrote:

> On Mon, Apr 22, 2024 at 07:41:42PM +0200, Dominique Dumont wrote:
> > On Sunday, 21 April 2024 18:07:00 CEST Julian Andres Klode wrote:
> > > This should be fixed in apt git already, just needs an upload,
> > > which is waiting-ish for some more merges
> > Given [1], I need to ask... 
> > Is this a definitive fix or will this feature come back with apt 3.0 ?
…
> This should be fixed in apt side on 2.9.2 I just uploaded, but
> either way it's a weird thing to break because we change progress
> messages for interactive output, maybe run with -q instead or don't
> pretend to be a tty.

I can confirm that the issues in dh-make-perl's and
libconfig-model-dpkg-perl's test suites (via libapt-pkg-perl) are gone
with apt 2.9.2. Thanks!

(Further change requests should probably go to libapt-pkg-perl, if
necessary.)


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#1066788: gyoto: FTBFS: dh_auto_test: error: make -j8 check "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 check-lorene returned exit code 2

[Colin Watson]

Control: tag -1 patch

On Wed, Mar 13, 2024 at 03:56:54PM +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> 
> Relevant part (hopefully):
> > make[3]: Entering directory '/<>/yorick'
> > Makefile:136: warning: overriding recipe for target 'check-dll'
> > ../yorick/Makepkg:158: warning: ignoring old recipe for target 'check-dll'
> > make[3]: 'check-lorene' is up to date.
> > make[3]: Leaving directory '/<>/yorick'
> > make[2]: Leaving directory '/<>'
> > dh_auto_test: error: make -j8 check "TESTSUITEFLAGS=-j8 --verbose" 
> > VERBOSE=1 check-lorene returned exit code 2

A more relevant part was:

  ImportError: 
/<>/python/gyoto/_std.cpython-311-x86_64-linux-gnu.so: undefined 
symbol: _ZN5Gyoto7AstrobjlsERSoRKNS0_14PolishDoughnutE

I sent a patch for this upstream as
https://github.com/gyoto/Gyoto/pull/17.  Here's a patch to fix the
Debian package in the meantime.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]
>From 19e6f4bcdc33cbd7995027bf56ec3b5a7125ea5f Mon Sep 17 00:00:00 2001
From: Colin Watson 
Date: Wed, 24 Apr 2024 15:25:19 +0100
Subject: [PATCH] Remove undefined operator<< declaration for PolishDoughnut

Closes: #1066788
---
 debian/changelog  |  7 ++
 .../patches/remove-polish-doughnut-operator   | 25 +++
 debian/patches/series |  1 +
 3 files changed, 33 insertions(+)
 create mode 100644 debian/patches/remove-polish-doughnut-operator

diff --git a/debian/changelog b/debian/changelog
index 8f74908..0188483 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+gyoto (2.0.2-1.2) UNRELEASED; urgency=medium
+
+  * Remove undefined operator<< declaration for PolishDoughnut (closes:
+#1066788).
+
+ -- Colin Watson   Wed, 24 Apr 2024 14:32:29 +0100
+
 gyoto (2.0.2-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --git a/debian/patches/remove-polish-doughnut-operator b/debian/patches/remove-polish-doughnut-operator
new file mode 100644
index 000..ead15f5
--- /dev/null
+++ b/debian/patches/remove-polish-doughnut-operator
@@ -0,0 +1,25 @@
+Description: Remove undefined operator<< declaration for PolishDoughnut
+ On current Debian systems this resulted in `undefined symbol:
+ _ZN5Gyoto7AstrobjlsERSoRKNS0_14PolishDoughnutE` while running tests.
+Bug-Debian: https://bugs.debian.org/1066788
+Forwarded: https://github.com/gyoto/Gyoto/pull/17
+Last-Update: 2024-04-24
+
+Index: b/include/GyotoPolishDoughnut.h
+===
+--- a/include/GyotoPolishDoughnut.h
 b/include/GyotoPolishDoughnut.h
+@@ -262,13 +262,6 @@
+  // Outputs
+  // ---
+  public:
+-
+- /// Display
+- friend std::ostream& operator<<(std::ostream& , const PolishDoughnut& ) ;
+-
+- public:
+-
+-
+ };
+ 
+ #endif
diff --git a/debian/patches/series b/debian/patches/series
index b9e8f3b..b8e9081 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
 interpreter-path
+remove-polish-doughnut-operator
 # This patch is conditionally applied by debian/rules:
 # no-fp-ilogb0
-- 
2.43.0

Bug#1063514: Broken links in the View Trends and the View Histogram menu

[Jorge Merlino]

I found that, in the case of the Ubuntu bug, the issue was the
--with-cgiurl parameter in the debian/rules file. I changed it from 
/cgi-bin/nagios4 to /nagios4/cgi-bin to fix this issue.


Regards
Jorge

Bug#1055847: Please check python-sparse issue at Github

[Andreas Tille]

Hi Diane and Ghislain,

you are listed as Uploaders of python-sparse.  Since I now have other
tasks than maintaining team maintained packages I would be really happy
if you could subscribe upstream issue

   https://github.com/pydata/sparse/issues/628

and continue what I have started.

Thanks a lot
   Andreas.

-- 
https://fam-tille.de

Bug#1069770: elementpath: please update to latest upstream release

[林上智]

Hi,

Timo Röhling  於 2024年4月24日 週三 下午10:09寫道：

> Hi,
>
> * SZ Lin (林上智)  [2024-04-24 22:03]:
> >I'm not currently using this package. The original maintainer is
> >MIA, and I'm considering whether to orphan it directly.
> >
> >Would you be interested in taking over?
> Sure! I'll move it to the Debian Python Team and maintain it there.
>
>
> Thanks for the quick reply!

Timo
>

Thank you very much, this also fulfills one of my wishes.

SZ


>
> --
> ⢀⣴⠾⠻⢶⣦⠀   ╭╮
> ⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
> ⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
> ⠈⠳⣄   ╰╯
>

Bug#1069768: dropbear-initramfs becomes unresponsive after several connection attempts

[Guilhem Moulin]

Control: tag -1 unreproducible moreinfo

Hi,

On Wed, 24 Apr 2024 at 14:42:43 +0200, Lee Garrett wrote:
> After some debugging, it turns out that ServerAliveInterval != 0 will cause 
> the
> ssh client to reset the connection, which dropbear will count as unlock 
> attempt,
> and after three tries it will fail and drop to initramfs shell, after which 
> it's
> not reachable anymore.

AFAICT dropbear does support timeout messages (see -K in the manual).
I'm unable to reproduce the issue anyway, do you start dropbear with -I?

Can you try to start your client with -oLogLevel=DEBUG3 to see why the
connection is terminated (from the client's perspective)?  Also to take
cryptroot out of the picture you could try using `cat -A` as the remote
command.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1069778: RFP: lsd -- a rewrite of GNU ls with lots of added features like colors, icons, tree-view and more formatting options

[Laurent Cheylus]

Package: wnpp
Severity: wishlist

* Package name: lsd
  Version : 1.1.2
  Upstream Contact: Wei Zhang
* URL : https://github.com/lsd-rs/lsd
* License : Apache-2.0
  Programming Lang: Rust
  Description : a rewrite of GNU ls with lots of added features like 
colors, icons, tree-view and more formatting options

lsd is is a rewrite of GNU ls with lots of added features like colors, icons,
tree-view, more formatting options etc. The project is heavily inspired by the
super colorls project.

The project is developed in Rust and a Debian package is already available in
releases on GitHub (built via CI).

Bug#1069777: initramfs-tools: Bug/feature request: better handling of /etc/crypttab not ending in new line character

[Richard Rosner]

Package: initramfs-tools
Version: 0.142
Severity: wishlist

Dear Maintainer,
I'm not sure if this is a bug that should be fixed or a feature request for
better error handling. I noticed by accident, that when /etc/crypttab
ends in
the line of the last entry and not a new line character,
update-initramfs just
ignores the last line and says it couldn't find that device in
/etc/crypttab.
Either the tool should be able to just handle this rather simple case or at
least give a proper error message. Or whatever would make it more
obvious for
the user what actually the error is as the existing error message is quite
misleading.

Best
Richard

Bug#1069770: elementpath: please update to latest upstream release

[Timo Röhling]

Hi,

* SZ Lin (林上智)  [2024-04-24 22:03]:
I'm not currently using this package. The original maintainer is 
MIA, and I'm considering whether to orphan it directly.


Would you be interested in taking over?

Sure! I'll move it to the Debian Python Team and maintain it there.


Thanks for the quick reply!
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#1069776: RFP: uv -- an extremely fast Python package installer and resolver, written in Rust

[Laurent Cheylus]

Package: wnpp
Severity: wishlist

* Package name: uv
  Version : 0.1.37
  Upstream Contact: Charlie Marsh 
* URL : https://github.com/astral-sh/uv
* License : MIT, Apache-2.0
  Programming Lang: Rust
  Description : an extremely fast Python package installer and resolver, 
written in Rust

uv is an extremely fast Python package installer and resolver, written in Rust.
Designed as a drop-in replacement for common pip and pip-tools workflows.

- Drop-in replacement for common pip, pip-tools, and virtualenv commands.
- 10-100x faster than pip and pip-tools (pip-compile and pip-sync).
- Disk-space efficient, with a global cache for dependency deduplication.
- Tested at-scale against the top 10,000 PyPI packages.
- Advanced features such as dependency version overrides and alternative
  resolution strategies.
- Best-in-class error messages with a conflict-tracking resolver.
- Support for a wide range of advanced pip features, including editable
  installs, Git dependencies, direct URL dependencies, local dependencies,
  constraints, source distributions, HTML and JSON indexes, and more.

Bug#1069520: sbcl: FTBFS on armhf: make[1]: *** [debian/rules:53: override_dh_auto_build] Error 1

[Peter Van Eynde]

Hi,

Tested this and it’s due to the 64t transition. The grovelled data changed:

(sid_armhf-dchroot)pvaneynd@abel:~/sbcl-2.3.7$ diff -u 
./crossbuild-runner/backends/arm/stuff-groveled-from-headers.lisp 
output/stuff-groveled-from-headers.lisp
--- ./crossbuild-runner/backends/arm/stuff-groveled-from-headers.lisp   
2023-07-29 07:59:39.0 +
+++ output/stuff-groveled-from-headers.lisp 2023-07-29 07:59:39.0 
+
@@ -30,7 +30,7 @@
 (define-alien-type off-t (signed 64))
 (define-alien-type size-t (unsigned 32))
 (define-alien-type ssize-t (signed 32))
-(define-alien-type time-t (signed 32))
+(define-alien-type time-t (signed 64))
 (define-alien-type suseconds-t (signed 32))
 (define-alien-type uid-t (unsigned 32))
 ;; Types in src/runtime/wrap.h. See that file for explantion.
@@ -141,6 +141,7 @@
 (defconstant clock-process-cputime-id 2) ; #x2
 (defconstant clock-realtime-alarm 8) ; #x8
 (defconstant clock-realtime-coarse 5) ; #x5
+(defconstant clock-tai 11) ; #xb
 (defconstant clock-monotonic-coarse 6) ; #x6
 (defconstant clock-monotonic-raw 4) ; #x4
 (defconstant clock-boottime 7) ; #x7
@@ -149,11 +150,11 @@
 ;;; structures
 (define-alien-type nil
   (struct timeval
-  (tv-sec (signed 32))
-  (tv-usec (signed 32
+  (tv-sec (signed 64))
+  (tv-usec (signed 64
 (define-alien-type nil
   (struct timespec
-  (tv-sec (signed 32))
+  (tv-sec (signed 64))
   (tv-nsec (signed 32

I honestly don’t understand how to use 64-bit values on this arch, so I created 
https://bugs.launchpad.net/sbcl/+bug/2063340


Best regards, Peter

Bug#1068649: winbind: Should be wanted by and ordered before nss-user-lookup.target

[Magnus Holmgren]

onsdag 24 april 2024 11:55:55 CEST skrev du:
> 08.04.2024 17:27, Magnus Holmgren wrote:
> > Package: winbind
> > Version: 2:4.17.12+dfsg-0+deb12u1
> > 
> > I'm not entirely sure, but I think winbind.service should include
> > 
> > [Unit]
> > Wants=nss-user-lookup.target
> > Before=nss-user-lookup.target
> > 
> > systemd.special(7) says:
> > 
> > "All services which provide parts of the user/group database should be
> > ordered before this target, and pull it in."
> > 
> > and winbind does provide parts of the user/group database (as long as it's
> > mentioned in nsswitch.conf, but typically that's the point, isn't it?).
> 
> This is a grey area (to me anyway).  Myself, I tend to avoid this sort of
> dependencies as much as possible.  Since winbind itself is ordered after
> network.target, we're at risk to make login impossible until network is up,
> and network might not be up until, say, wifi is running, etc.

If this is an issue, I believe it's on a different level. But I don't think 
you need to worry about it. systemd.special(7) also says: "All services for 
which the availability of the full user/group database is essential should be 
ordered after this target, but not pull it in." So getty, display managers, 
etc. shouldn't wait for nss-user-lookup, and they don't, precisely because (I 
presume) you should be able login as any known user; all users don't have to 
be known before you're allowed to login.

> > We've had trouble with cron not running some jobs for a good while, and I
> > just now figured out that it's because we have some jobs configured to run
> > as Samba users, and cron started before winbind on boot and complained
> > about invalid users.
> 
> Please note how /etc/init.d/cron is set up: cron itself is ordered after
> winbindd. Maybe this is not a nice as systemd variant which you outlined
> above, but in my view it is more reliable.

Looks like basically the same to me, except that systemd has a group alias for 
those services so /etc/init.d/cron doesn't have to be updated whenever a new 
NSS backend is added.

-- 
Magnus Holmgren

Bug#1069775: RFP: ruff -- an extremely fast Python linter and code formatter, written in Rust

[Laurent Cheylus]

Package: wnpp
Severity: wishlist

* Package name: ruff
  Version : 0.4.1
  Upstream Contact: Charlie Marsh 
* URL : https://github.com/astral-sh/ruff/
* License : MIT
  Programming Lang: Rust
  Description : an extremely fast Python linter and code formatter, written 
in Rust

Ruff is an extremely fast Python linter and code formatter, written in Rust:

- 10-100x faster than existing linters (like Flake8) and formatters (like Black)
- Python 3.12 compatibility
- Drop-in parity with Flake8, isort, and Black
- Built-in caching, to avoid re-analyzing unchanged files
- Fix support, for automatic error correction (e.g., automatically remove 
unused imports)
- Over 800 built-in rules, with native re-implementations of popular Flake8 
plugins, like flake8-bugbear

Bug#1069774: sphinx: tests: skip_tests_network.diff patch can be dropped from v7.3.0 onwards.

[James Addison]

Source: sphinx
Severity: wishlist

Dear Maintainer,

The Sphinx v7.3.0 release included a pull request[1] to make the test suite
behave more consistently when the network conditions (online/offline) vary
between test suite evaluations.

One of the changes introduced by that is to replace some remote hyperlinks
referenced in the 'tests.test_builders.test_build_latex.test_latex_images' test
case with hyperlinks to localhost instead.

I believe that this should make it possible to drop 'skip_tests_network.diff'
from the Debian sphinx patch series.

Thank you,
James

[1] - https://github.com/sphinx-doc/sphinx/pull/12095

Bug#1069773: linux-image-6.1.0-20-amd64: Bluetooth fails to resume after suspend with linux-image-6.1.0-20

[Robert Lange]

Package: src:linux
Version: 6.1.85-1
Severity: important

Dear Maintainer,

After upgrading to linux-image-6.1.0-20-amd64 and rebooting my laptop, my 
Bluetooth mouse failed to work after resuming from suspend (via closing and 
reopening my laptop). Manually stopping and starting Bluetooth via the Gnome 
controls allowed the mouse to reconnect.

I experimented and determined that any time I suspended by closing the lid, 
when it resumed, my mouse would not automatically reconnect and Bluetooth had 
to be manually restarted, either by GUI or by systemctl. Additionally, after 
each suspend, two additional lines got appended to the linux console log:

Bluetooth: hci0: Opcode 0xc24 failed: -112
Bluetooth: hci0: unexpected event for opcode 0x0406

When I rebooted into linux-image-6.1.0-18-amd64, the previous kernel, I was 
able to suspend and resume without any issues from Bluetooth, and the above two 
lines were not appended to the console log after each suspend.

This seems to be some sort of regression in Bluetooth device handling. While I 
only have a mouse to test, I'd guess that other types of devices may also be 
affected.


-- Package-specific info:
** Version:
Linux version 6.1.0-20-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.85-1 (2024-04-11)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.1.0-20-amd64 
root=UUID=4b219315-d9dc-4199-8fc6-e3d5042f5df4 ro quiet

** Tainted: POE (12289)
 * proprietary module was loaded
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
[5.312310] sof-audio-pci-intel-tgl :00:1f.3: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[5.319244] sof-audio-pci-intel-tgl :00:1f.3: use msi interrupt mode
[5.335718] kauditd_printk_skb: 14 callbacks suppressed
[5.335720] audit: type=1400 audit(1713958189.171:25): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/evince" pid=794 
comm="apparmor_parser"
[5.335723] audit: type=1400 audit(1713958189.171:26): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/bin/evince//sanitized_helper" pid=794 comm="apparmor_parser"
[5.335725] audit: type=1400 audit(1713958189.171:27): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/evince-previewer" 
pid=794 comm="apparmor_parser"
[5.335727] audit: type=1400 audit(1713958189.171:28): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/bin/evince-previewer//sanitized_helper" pid=794 
comm="apparmor_parser"
[5.335728] audit: type=1400 audit(1713958189.171:29): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/bin/evince-thumbnailer" pid=794 comm="apparmor_parser"
[5.344889] sof-audio-pci-intel-tgl :00:1f.3: hda codecs found, mask 5
[5.344891] sof-audio-pci-intel-tgl :00:1f.3: using HDA machine driver 
skl_hda_dsp_generic now
[5.344893] sof-audio-pci-intel-tgl :00:1f.3: DMICs detected in NHLT 
tables: 2
[5.346134] sof-audio-pci-intel-tgl :00:1f.3: firmware: direct-loading 
firmware intel/sof/sof-rpl.ri
[5.346138] sof-audio-pci-intel-tgl :00:1f.3: Firmware info: version 
2:2:0-57864
[5.346139] sof-audio-pci-intel-tgl :00:1f.3: Firmware: ABI 3:22:1 
Kernel ABI 3:23:0
[5.346141] sof-audio-pci-intel-tgl :00:1f.3: unknown sof_ext_man header 
type 3 size 0x30
[5.369054] audit: type=1400 audit(1713958189.203:30): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-soffice" 
pid=799 comm="apparmor_parser"
[5.369074] intel_rapl_common: Found RAPL domain package
[5.369081] audit: type=1400 audit(1713958189.203:31): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-soffice//gpg" 
pid=799 comm="apparmor_parser"
[5.391433] input: ThinkPad Extra Buttons as 
/devices/platform/thinkpad_acpi/input/input16
[5.443377] sof-audio-pci-intel-tgl :00:1f.3: Firmware info: version 
2:2:0-57864
[5.443381] sof-audio-pci-intel-tgl :00:1f.3: Firmware: ABI 3:22:1 
Kernel ABI 3:23:0
[5.448092] sof-audio-pci-intel-tgl :00:1f.3: firmware: direct-loading 
firmware intel/sof-tplg/sof-hda-generic-2ch.tplg
[5.448097] sof-audio-pci-intel-tgl :00:1f.3: Topology: ABI 3:22:1 
Kernel ABI 3:23:0
[5.448233] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: Parent card not 
yet available, widget card binding deferred
[5.464806] typec port0: bound usb1-port5 (ops connector_ops [usbcore])
[5.464822] typec port0: bound usb4-port1 (ops connector_ops [usbcore])
[5.476776] snd_hda_codec_realtek ehdaudio0D0: autoconfig for ALC257: 
line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[5.476779] snd_hda_codec_realtek ehdaudio0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[5.476780] snd_hda_codec_realtek ehdaudio0D0:hp_outs=1 

Bug#1069772: pmbootstrap: description doesn't tell me what the package does

[Sam Hartman]

package: pmbootstrap
version: 2.2.1-1
severity: minor

The description should tell the user what postmarket OS is.  That is for
example more important than knowing the package uses alpine chroots in
determining whether this package is useful to me as a user.

--Sam

Bug#1069161: libfreetype-dev: Unable to install libfreetype-dev, depends on libpng16-16

[Laurent Cheylus]

Hi Hugh,

> This isn't a bug with freetype or libpng1.6. The problem is that
> you've mixed packages from two different distributions during a large
> and very complex transition.
> 
> Why are you installing packages from unstable (sid) on your testing
> system? As you've seen, that is a guaranteed way to cause breakage.

You're right: my installation looks like a "Franken Debian" mixing packages 
from testing and unstable repositories.
I'm using unstable because I needed to install VirtualBox and Firefox from 
unstable repositories (not available in testing).
 
> You need to remove the libpng packages from your system and then
> install the packages from testing. Then you will be able to install
> libfreetype-dev.

I solved my issue by removing unstable repository and packages installed from 
it. I replaced the installation for Firefox with official Mozilla repository 
and VirtualBox with "Fast Track" repo.

You can close this bug.

Thanks, Laurent

Bug#1069771: libslow5lib FTBFS on big endian architectures

[Helge Deller]

Source: libslow5lib
Version: 0.7.0+dfsg-2.1
Tags: ftbfs

build log reports:
[slow5_open_with::ERROR]
Big endian machine detected. slow5lib only supports little endian at this time. 
Please open a github issue stating your machine spec 
.

Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=libslow5lib=hppa=0.7.0%2Bdfsg-2.1=1713388301=0

I opened a ticket upstream:
https://github.com/hasindu2008/slow5lib/issues/88

Bug#1058888: pyferret FTBSF on several architectures: dh_install: error: missing files, aborting

[Colin Watson]

Control: retitle -1 pyferret FTBFS on several architectures: dh_install: error: 
missing files, aborting
Control: tag -1 patch

On Sun, Dec 17, 2023 at 08:24:07PM +0200, Adrian Bunk wrote:
> https://buildd.debian.org/status/logs.php?pkg=pyferret=7.6.5-5
> 
> ...
>dh_install -a
> dh_install: warning: Cannot find (any matches for) 
> "debian/tmp/ext_func/pylibs" (tried in ., debian/tmp)
> 
> dh_install: warning: python3-ferret missing files: debian/tmp/ext_func/pylibs
>   install -m0755 -d debian/python3-ferret//usr/bin
>   cp --reflink=auto -a ./debian/pyferret3 debian/python3-ferret//usr/bin/
>   install -m0755 -d debian/python3-ferret//usr/lib/python3/dist-packages
>   cp --reflink=auto -a 
> ./debian/tmp/lib/python3.11/libpyferret.cpython-311-powerpc64le-linux-gnu.so 
> ./debian/tmp/lib/python3.12/libpyferret.cpython-312-powerpc64le-linux-gnu.so 
> ./install/local/lib/python3.11/dist-packages/__pycache__ 
> ./install/local/lib/python3.11/dist-packages/gcircle-7.65-py3.11.egg-info 
> ./install/local/lib/python3.11/dist-packages/gcircle.py 
> ./install/local/lib/python3.11/dist-packages/pipedviewer 
> ./install/local/lib/python3.11/dist-packages/pipedviewer-7.65-py3.11.egg-info 
> ./install/local/lib/python3.11/dist-packages/pyferret 
> ./install/local/lib/python3.11/dist-packages/pyferret-7.65-py3.11.egg-info 
> debian/python3-ferret//usr/lib/python3/dist-packages/
>   install -m0755 -d 
> debian/python3-ferret//usr/share/bash-completion/completions/
>   cp --reflink=auto -a ./debian/bash_completion.d/pyferret3 
> debian/python3-ferret//usr/share/bash-completion/completions//
> dh_install: error: missing files, aborting
> make: *** [debian/rules:8: binary-arch] Error 25

I've proposed
https://salsa.debian.org/science-team/pyferret/-/merge_requests/3 to fix
this.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1069591: cyckle: Fails to start

[Konstantin L. Metlov]

This BUG was fixed in cycle 0.3.3. Please upgrade to

https://debian.pkgs.org/sid/debian-main-arm64/cycle_0.3.3-1_all.deb.html

Bug#1069770: elementpath: please update to latest upstream release

[Timo Röhling]

Source: elementpath
Version: 3.0.2-1
Severity: wishlist
Control: affects -1 src:python-xmlschema

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

I'd like to update python-xmlschema, but this needs to be coordinated with 
elementpath. Could you please update elementpath?


Cheers
Timo


-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmYpARMACgkQzIxr3RQD
9MpCrA/7BNJIB7+w7k/ImJY0i06BDhfT6HTITaxHjoqL6+i43nsTRUASel2cbhvM
B+inRa03W8/QlQr0TkI7gurrIZwujerP0Ux3z1OBQAIGflGFU3yTQuSwj1WVXJU8
PIJ71fDhTegYqUA65R9QT3KOvVkCq+5P87TFy8hl2AVOvBsxkK9rGsut6KlFconf
+fYzbJEtaBQmMSKVt0ZzRVxpXcWVuH5T3JWclwdpZTREquLj4sb5iN+sCKK7m7k2
cGlm/1egm26jWk2O5YlxZGR1PldnEeJ2DaYobbz8SbRQMJmEoGhnH4GyH4YdYFBz
o3i3y2O44NUniV7jM63hQDCuYQ6CUROxe+2kce2tfsIJNc84CH4Q88bHAXGo5AYw
cfVmzYSppyQshYYAWz0FMxN3n0x2itB0EsBpHT+niDdxWLQj28IH0Dhprlprmx3E
ujAXi9nJnQexkWxUzMH1S5Q3gx+xYMI/WJF1dJ4BCV8heR85LUvJQQmmWP8inTiJ
LHfbrAsV13R+mjywFo4UvoyY97GvoGGECKXjrz0LXplbvoV6vQFrQ8QQgNu5zFQs
zgjkyYGJqwuHczan2aGMF/EnvfYTGxaH7ZeoLiuov+fSwbTITA59b+cgzoJ1u0HK
T3NR11xcBJdtvHVWmsEe7/18VDd4c3uDW38EN6viyPbCO5b2Gpk=
=j4DF
-END PGP SIGNATURE-

Bug#1069769: haskell-versions: Disable RTS -N on loong64

[zhangdandan]

Source: haskell-versions
Version: 6.0.2-1
Severity: normal
Tags: ftbfs patch
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

Compiling the haskell-versions failed for loong64 in the Debian Package 
Auto-Building environment.

The error log is as follows,
```
Running 1 test suites...
Test suite versions-test: RUNNING...
versions-test: unknown RTS option: -N
versions-test:
versions-test: Usage:   [+RTS  | -RTS ] ... 
--RTS 

versions-test:
```

The Full log can be found at 
https://buildd.debian.org/status/logs.php?pkg=haskell-versions=6.0.2-1=loong64.


We need to disable -with-rtsopts=-N option on loongarch64.
I have built haskell-versions successfully in my local ENV.
Please consider the patch I attached.
Your opinions are welcome.

Thanks,
Dandan Zhang

Description: Disable RTS -N on loong64 
Last-Update: 2024-04-24

--- haskell-versions-6.0.2.orig/versions.cabal
+++ haskell-versions-6.0.2/versions.cabal
@@ -58,7 +58,7 @@ test-suite versions-test
   type:   exitcode-stdio-1.0
   main-is:Test.hs
   hs-source-dirs: test
-  if arch(arm) || arch(mips) || arch(s390x) || arch(i386) || arch(riscv64)
+  if arch(arm) || arch(mips) || arch(s390x) || arch(i386) || arch(riscv64) || arch(loongarch64)
 ghc-options:-threaded
   else
 ghc-options:-threaded -with-rtsopts=-N

Bug#1069768: dropbear-initramfs becomes unresponsive after several connection attempts

[Lee Garrett]

Package: dropbear-initramfs
Version: 2022.83-1+deb12u1
Severity: normal
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

I have a remote server running bookworm that is configured to use
dropbear-initramfs and cryptsetup-initramfs to unlock the LUKS container. The
way I unlock it is shown below:

$ until ssh r...@hopper-boot.rocketjump.eu cryptroot-unlock; do sleep 3; done
ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection refused
ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection refused
ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection refused
ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection refused
ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection refused
ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection timed out
ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection timed out
ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection timed out
ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection timed out
ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection timed out
ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection timed out
ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection timed out
ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection timed out
ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection timed out
ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection timed out
ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection timed out
ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection timed out
Please unlock disk md2_crypt
Timeout, server hopper-boot.rocketjump.eu not responding.
Please unlock disk md2_crypt
Timeout, server hopper-boot.rocketjump.eu not responding.
Please unlock disk md2_crypt
Timeout, server hopper-boot.rocketjump.eu not responding.
Timeout, server hopper-boot.rocketjump.eu not responding.
Timeout, server hopper-boot.rocketjump.eu not responding.
Timeout, server hopper-boot.rocketjump.eu not responding.

^C^C

As you can see, while rebooting the connection is refused, as sshd is already
shutdown, but the server is reachable. Then the connection times out while it's
still doing a POST. At some point dropbear becomes reachable, as shown by the
output of "Please unlock disk md2_crypt", however the connection seems to error
out after a while, and after three attempts, dropbear becomes unresponsive. This
forces me to hard reset the server and try again until I catch it in the right
moment.

After some debugging, it turns out that ServerAliveInterval != 0 will cause the
ssh client to reset the connection, which dropbear will count as unlock attempt,
and after three tries it will fail and drop to initramfs shell, after which it's
not reachable anymore.

It would be great to prominently document that dropbear(-initramfs) does not
handle the ServerAliveInterval ssh client setting.

Greets,
Lee


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

Kernel: Linux 6.1.0-20-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 dropbear-initramfs depends on:
ii  busybox  1:1.35.0-4+b3
pn  dropbear-bin 
ii  initramfs-tools  0.142
ii  udev 252.23-1~deb12u1

Versions of packages dropbear-initramfs recommends:
ii  cryptsetup-initramfs  2:2.6.1-4~deb12u2

dropbear-initramfs suggests no packages.

Bug#1034483: dmidecode: CVE-2023-30630

[Petter Reinholdtsen]

Any hope to have this CVE issue fixed in stable and oldstable as well?

If not, I suspect this BTS report should be closed.
-- 
Happy hacking
Petter Reinholdtsen

Bug#1069767: dmidecode: New upstream version 3.6 available

[Petter Reinholdtsen]

Package: dmidecode
Version: 3.5
Severity: wishlist

A new version was just released.

 Start of forwarded message 
Date: Wed, 24 Apr 2024 14:19:28 +0200
From: Jean Delvare 
To: dmidecode-de...@nongnu.org
Subject: Dmidecode 3.6 has been released

Hi all,

Dmidecode 3.6 was released today. The changes from 3.5 are as follows:
  - [PORTABILITY] Use -DALIGNMENT_WORKAROUND on arm.
  - [PORTABILITY] Read SMBIOS entry point via kenv on DragonFly BSD.
  - Support for SMBIOS 3.6.0. This includes new memory device types, new
processor upgrades, and Loongarch support.
  - Support for SMBIOS 3.7.0. This includes new port types, new processor
upgrades, new slot characteristics and new fields for memory modules.
  - Add bash completion.
  - Decode HPE OEM records 197, 239 and 245.
  - Implement options --list-strings and --list-types.
  - Update HPE OEM records 203, 212, 216, 221, 233, 236, 237, 238 and 242.
  - Update Redfish support.
  - Bug fixes:
Fix option --from-dump for user root
Fix enabled slot characteristics not being printed
  - Minor improvements:
Print slot width on its own line
Use standard strings for slot width

This new release is available for download from the usual place:
  http://download.savannah.gnu.org/releases/dmidecode/dmidecode-3.6.tar.xz
  http://download.savannah.gnu.org/releases/dmidecode/dmidecode-3.6.tar.xz.sig

Please allow for up to 24 hours before the files propagate to all
mirrors.

-- 
Jean Delvare
SUSE L3 Support

 End of forwarded message