Bug#1070733: linux-image-5.10.0-29-amd64 fails to boot with Error 16: Inconsistent filesystem structure

[Dan Poltawski]

Package: src:linux
Version: 5.10.216-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

After upgrading to linux-image-5.10.0-29 the system fails to boot with
grub 'Error 16: Inconsistent filesystem structure'. Booting into 
linux-image-5.10.0-28-amd64
and the system is once again bootable

The console displays:
Booting 'Debian GNU/Linux, kernel 5.10.0-29-amd64'
root (hd0,0)
Filesystem type is ext2fs, partition type 0x83
kernel /boot/vmlinuz-5.10.0-29-amd64 root=UUID=ca38e015-f8d1-4ef0-9dc9-b56d7c8
le0f1 ro
[Linux-bzImage, setup=0x3c00, size=0x6b5f40]
Initrd /boot/initrd. img-5.10.0-29-amd64
Error 16: Inconsistent filesystem structure
Press any key to continue...-





-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: QEMU
product_name: Standard PC (i440FX + PIIX, 1996)
product_version: pc-i440fx-8.1
chassis_vendor: QEMU
chassis_version: pc-i440fx-8.1
bios_vendor: SeaBIOS
bios_version: rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 440FX - 82441FX PMC [Natoma] 
[8086:1237] (rev 02)
Subsystem: Red Hat, Inc. Qemu virtual machine [1af4:1100]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- SERR- TAbort- 
SERR- TAbort- SERR- TAbort- SERR- 
Kernel driver in use: virtio-pci
Kernel modules: virtio_pci

00:05.0 SCSI storage controller [0100]: Red Hat, Inc. Virtio SCSI [1af4:1004]
Subsystem: Red Hat, Inc. Virtio SCSI [1af4:0008]
Physical Slot: 5
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: virtio-pci
Kernel modules: virtio_pci

00:12.0 Ethernet controller [0200]: Red Hat, Inc. Virtio network device 
[1af4:1000]
Subsystem: Red Hat, Inc. Virtio network device [1af4:0001]
Physical Slot: 18
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: virtio-pci
Kernel modules: virtio_pci

00:13.0 Ethernet controller [0200]: Red Hat, Inc. Virtio network device 
[1af4:1000]
Subsystem: Red Hat, Inc. Virtio network device [1af4:0001]
Physical Slot: 19
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: virtio-pci
Kernel modules: virtio_pci

00:1e.0 PCI bridge [0604]: Red Hat, Inc. QEMU PCI-PCI bridge [1b36:0001] 
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 

00:1f.0 PCI bridge [0604]: Red Hat, Inc. QEMU PCI-PCI bridge [1b36:0001] 
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 


** USB devices:
not available


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

Kernel: Linux 5.10.0-28-amd64 (SMP w/6 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-5.10.0-29-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.140
ii  kmod28-1
ii  linux-base  4.6

Versions of packages linux-image-5.10.0-29-amd64 recommends:
ii  apparmor 2.13.6-10
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-5.10.0-29-amd64 suggests:
pn  debian-kernel-handbook   
pn  grub-pc | grub-efi-amd64 | extlinux  
pn  linux-doc-5.10   

Versions of packages linux-image-5.10.0-29-amd64 is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  

Bug#1070726: nvidia-kernel-dkms wont build with latest bullseye kernel 5.10.0-29-amd64

[Andreas Beckmann]

On 08/05/2024 02.20, Braiden Kindt wrote:

Package: nvidia-kernel-dkms
Version: 470.223.02-1


There is already a newer driver version in oldstable-proposed-updates. 
Does it fix the issue?



Andreas

Bug#1070732: bluez: re-inserting adapter makes bluetoothd (and 100% cpu)

[Kamil Jonca]

Package: bluez
Version: 5.73-1
Severity: important
X-Debbugs-Cc: kjo...@poczta.onet.pl

I have usb bluetooth adapter:

Bus 005 Device 115: ID 0b05:17cb ASUSTek Computer, Inc. Broadcom BCM20702A0 
Bluetooth

When I plug out and then plug in this adapter - bluetooth daemon started 
to get "running" state (top shows 100% cpu), bluetooth stopped to work, 
cannot use  bluetoothctl, and only solution is to restart bluetooth 
service.

Additional info:
firstly I such behavior I observed on my laptop which has:
Bus 003 Device 006: ID 8087:0033 Intel Corp. 
during hibernation I remove xhci_pci module, and after hibernation reload it,
 and sometimes bluetooth cannot deal with this


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

Kernel: Linux 6.7.12-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.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 bluez depends on:
ii  dbus [default-dbus-system-bus]  1.14.10-4+b1
ii  init-system-helpers 1.66
ii  kmod32-1
ii  libasound2t64   1.2.11-1+b1
ii  libc6   2.37-18
ii  libdbus-1-3 1.14.10-4+b1
ii  libdw1t64   0.191-1+b1
ii  libglib2.0-0t64 2.78.4-7
ii  libreadline8t64 8.2-4
ii  libudev1255.5-1
ii  udev255.5-1

bluez recommends no packages.

Versions of packages bluez suggests:
ii  pulseaudio-module-bluetooth  16.1+dfsg1-5

-- Configuration Files:
/etc/bluetooth/main.conf changed:
[General]
[Policy]
AutoEnable=true


-- no debconf information

Bug#1070695: server-control.html: ambiguous text bug bugs assigned to 2 packages

[Don Armstrong]

On Tue, 07 May 2024, Vincent Lefevre wrote:
> At https://www.debian.org/Bugs/server-control.en.html (coming from
> html/server-control.html.in in debbugs):
> 
>   The bug tracking system uses this information, in conjunction with
>   fixed versions recorded when closing bugs, to display lists of bugs
>   open in various versions of each package. It considers a bug to be
>   open when it has no fixed version, or when it has been found more
>   recently than it has been fixed.
> 
> But this text is ambiguous when a bug is assigned to 2 different
> packages and is marked as fixed in only one of these packages.

The reality is even more complex than this paragraph, because
found/fixed/absent is dependent on the DAG of package versions, not the
time of upload.

I should crib some text from one of my blog posts a few years ago about
this and add it to the documentation.

-- 
Don Armstrong  https://www.donarmstrong.com

There is no form of lead-poisoning which more rapidly and thoroughly
pervades the blood and bones and marrow than that which reaches the
young author through mental contact with type metal.
 -- Oliver Wendell Holmes (Tilton 1947 p67)

Bug#1070731: ruby-kramdown-rfc2629: new upstream version 1.7.11 available

[Daniel Kahn Gillmor]

Package: ruby-kramdown-rfc2629
Version: 1.7.1-1~exp1
Severity: wishlist
X-Debbugs-Cc: Daniel Kahn Gillmor 

Dear Maintainer,

kramdown-rfc 1.7.11 is available upstream -- it would be great to have
this in debian, because it offers a feature that i hope to use for
draft-ietf-lamps-header-protection (nested ordered lists).

If there's a reason to keep it in experimental, i could deal with that,
but it'd be even nicer if we could put it directly in unstable ☺

Thanks for maintaining kramdown-rfc in debian!

 --dkg

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

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)

Versions of packages ruby-kramdown-rfc2629 depends on:
ii  libruby3.1t64 [ruby-json]  3.1.2-8.3
ii  ruby   1:3.1+nmu1
ii  ruby-kramdown  2.4.0-2
ii  ruby-kramdown-parser-gfm   1.1.0-3
ii  ruby-net-http-persistent   4.0.2-2

ruby-kramdown-rfc2629 recommends no packages.

Versions of packages ruby-kramdown-rfc2629 suggests:
ii  aasvg0.3.2-1
ii  xml2rfc  3.21.0-1

-- no debconf information


signature.asc
Description: PGP signature

Bug#1070730: libglib2.0-0: broken ibus-mozc (japanese input) in GTK programs

[unfathomable18]

Package: libglib2.0-0
Version: 2.74.6-2+deb12u1
Severity: important
Tags: l10n

Dear Maintainer,

   * What led up to the situation?

Latest upgrade from 2.74.6-2 to 2.74.6-2+deb12u1 broke input of Japanese 
characters GTK programs (such as firefox, gedit etc).

Currently using ibus-mozc for Japanese input. The packages and versions are 
`ibus 1.5.27-5` and `ibus mozc 2.28.4715.102+dfsg-2.2`.

The mozc input method allows input of normal alphabet characters (direct 
input), and that is unaffected. When switching to input of Japanese characters 
(e.g. Hiragana), the input widget (in which you select word candidates) 
appears, but the selected text does not register as text input.

QT programs seem not to be affected. Japanese input is possible on those. 
Copying Japanese text from QT programs to GTK ones is also possible.


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

The following did NOT work:
 - just restarting the system,
 - using im-config to reset input method configuration, and restarting;
 - stopping and restarting ibus;
 - removing and reinstalling ibus, ibus-mozc etc.

Reverting libglib2.0 and related packages from the current version 
(2.74.6-2+deb12u1) to the previous version (2.74.6-2) solved the problem. In 
particular, the command used was:
```sudo apt install libglib2.0-dev:amd64=2.74.6-2 libglib2.0-bin:amd64=2.74.6-2 
libglib2.0-dev-bin:amd64=2.74.6-2 libglib2.0-0:amd64=2.74.6-2 
libglib2.0-0:i386=2.74.6-2 libglib2.0-data:all=2.74.6-2```

This was confirmed multiple times (upgrading and downgrading a couple of 
times). When the packages are upgraded and the system is not reset, the input 
continues to work, but stops working after a reset.

Thus the problem seems to be in the newest version (2.74.6-2+deb12u1) of 
ibglib2.0-0 and related packages.


Thank you for your time.

Bug#1070729: wireplumber: 0.5 breaks unmodified configurations because of incompatible state format

[Grzesiek11]

Package: wireplumber
Version: 0.5.2-2
Severity: important

Dear Maintainer,

As mentioned by the NEWS entry, 0.5 replaces the old configuration
system with a new one utilizing JSON. It also states this should be
transparent for systems using only Debian configuration, however the
state format (for files stored in $XDG_STATE_HOME/wireplumber) is also
incompatible, causing unmodified configurations to break.

The workaround I used is removing the state directory and restarting the
service, causing it to regenerate.

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

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

Versions of packages wireplumber depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.14.10-4+b1
ii  dbus-x11 [dbus-session-bus]   1.14.10-4+b1
ii  init-system-helpers   1.66
ii  libc6 2.38-8
ii  libglib2.0-0t64   2.80.0-10
ii  libpipewire-0.3-0t64  1.0.5-1+b3
ii  libwireplumber-0.5-0  0.5.2-2
ii  pipewire  1.0.5-1+b3

Versions of packages wireplumber recommends:
ii  pipewire-pulse  1.0.5-1+b3

Versions of packages wireplumber suggests:
ii  libspa-0.2-bluetooth  1.0.5-1+b3
pn  libspa-0.2-libcamera  
pn  wireplumber-doc   

-- no debconf information

Bug#1070659: transition: re2

[stefanor]

Hi Adrian (2024.05.07_17:39:58_+)
> Could this be solved through Provides, so that it could be handled 
> with binNMUs during abseil transitions?

Implemented in 20240501-2.

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1061421: Fails to start after an upgrade

[duck]

Quack,

On 2024-04-22 00:44, Jeremy Bícha wrote:

There have been a huge amount of changes, but most of those changes
were in Unstable and haven't reached Testing yet.


I can confirm the problem is still there in latest unstable.


Marc, there is a fix for sway 1.9 in wlgreet 0.5. Do you want to try
if that improves anything here?


Not sure this is the same problem but I would say it's worth a try.
I'll prepare the package and let you know how it goes.

Regards.
\_o<

--
Marc Dequènes

Bug#1070728: python3-minimal: py3clean man page has 2 typos: "turn verbose more one"

[JT Hundley]

Package: python3-minimal
Version: 3.11.2-1+b1
Severity: minor
Tags: patch

Dear Maintainer,
The script py3clean which is included with python3-minimal has a typo in
the man page. This typo is not present in the output of py3clean --help.
Here is a patch:

49c49
< turn verbose more one
---
> turn verbose mode on

-- 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-17-amd64 (SMP w/12 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

Versions of packages python3-minimal depends on:
ii  dpkg1.21.22
ii  python3.11-minimal  3.11.2-6

python3-minimal recommends no packages.

python3-minimal suggests no packages.

-- no debconf information

Bug#1070727: reportbug: podman does not run wasm/wasi images because of missing crun-wasm - easy fix

[Eugen Stan]

Package: podman
Version: 4.9.4+ds1-1
Severity: important

Dear Maintainer,

I followed the guide to run wasm images on my system and it failed with 
errors.


I believe the issue is that podman looks for crun-wasm binary by default.
I failed to configure podman to use crun instead of crun-wasm.
I created a simbolic link named crun-wasm:

sudo ln -s /usr/bin/crun /usr/local/bin/crun-wasm

More details bellow to reproduce:

This is the guide I followed 
https://news.opensuse.org/2024/01/19/podman-wasm-

support/

I installed podman, crun and wasmedge packages.
Created a rust package and image with this Containerfile

FROM scratch
COPY target/wasm32-wasi/debug/hello.wasm /
CMD ["/hello.wasm"]

When I ran the image I got this error

podman run --rm hello-wasm
WARNING: image platform (wasi/wasm) does not match the expected platform
(linux/amd64)
Error: requested OCI runtime crun-wasm is not available: invalid argument

After creating the crun-wasm symbolic link I got it working:

podman run --platform wasi/wasm --rm hello-wasm
Hello, world din wasm!

It might be that this bu is fixed by patching crun but I believe the 
issue is

happening with podman.

Thanks,
Eugen




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

Kernel: Linux 6.7.12-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=ro_RO.UTF8, LC_CTYPE=ro_RO.UTF8 (charmap=UTF-8), LANGUAGE 
not set

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages podman depends on:
ii  conmon   2.1.10+ds1-1+b1
ii  containerd.io [runc] 1.6.31-1
ii  crun 1.14.4-1
ii  golang-github-containers-common  0.57.4+ds1-2
ii  libc62.38-7
ii  libdevmapper1.02.1   2:1.02.196-1+b1
ii  libgpgme11t641.18.0-4.1+b1
ii  libseccomp2  2.5.5-1
ii  libsqlite3-0 3.45.3-1
ii  libsubid41:4.13+dfsg1-4

Versions of packages podman recommends:
ii  buildah1.33.7+ds1-1
ii  catatonit  0.1.7-1+b1
ii  dbus-user-session  1.14.10-4+b1
ii  passt  0.0~git20240426.d03c4e2-1
ii  slirp4netns1.2.1-1+b1
ii  uidmap 1:4.13+dfsg1-4

Versions of packages podman suggests:
ii  containers-storage  1.51.0+ds1-2
pn  docker-compose  
ii  iptables1.8.10-3

-- no debconf information

--
Eugen Stan

+40770 941 271  / https://www.netdava.com

Bug#1070726: nvidia-kernel-dkms wont build with latest bullseye kernel 5.10.0-29-amd64

[Braiden Kindt]

Package: nvidia-kernel-dkms
Version: 470.223.02-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

 Bulleye kernel upgrade from 5.10.0-28-amd64 to 5.10.0-29-amd64

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

 dkms autoinstall -k 5.10.0-29-amd64

   * What was the outcome of this action?

 Error! Bad return status for module build on kernel: 5.10.0-29-amd64 
(x86_64)
 Consult /var/lib/dkms/nvidia-current/470.223.02/build/make.log for more 
information.

 FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol 
'rcu_read_unlock_strict'

   * What outcome did you expect instead?

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


-- Package-specific info:
uname -a:
Linux gadget 5.10.0-28-amd64 #1 SMP Debian 5.10.209-2 (2024-01-31) x86_64 
GNU/Linux

/proc/version:
Linux version 5.10.0-28-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.209-2 (2024-01-31)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  470.223.02  Sat Oct  7 15:39:11 
UTC 2023
GCC version:  gcc version 10.2.1 20210110 (Debian 10.2.1-6) 

Kernel: Linux 5.10.0-28-amd64 (SMP w/32 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 nvidia-kernel-dkms depends on:
ii  dkms  2.8.4-3
pn  firmware-nvidia-gsp | firmware-nvidia-gsp-470.223.02  
ii  nvidia-installer-cleanup  20151021+13
ii  nvidia-kernel-support [nvidia-kernel-support--v1] 470.223.02-1

Versions of packages nvidia-kernel-dkms recommends:
ii  libcuda1   470.223.02-1
ii  nvidia-driver  470.223.02-1

nvidia-kernel-dkms suggests no packages.

Versions of packages nvidia-driver depends on:
ii  nvidia-alternative 470.223.02-1
ii  nvidia-driver-bin  470.223.02-1
ii  nvidia-driver-libs 470.223.02-1
ii  nvidia-installer-cleanup   20151021+13
ii  nvidia-legacy-check470.223.02-1
ii  nvidia-support 20151021+13
ii  nvidia-vdpau-driver470.223.02-1
ii  xserver-xorg-video-nvidia  470.223.02-1

Versions of packages nvidia-driver recommends:
ii  libnvidia-cfg1   470.223.02-1
ii  nvidia-persistenced  470.103.01-2~deb11u1
ii  nvidia-settings  470.141.03-1~deb11u1

nvidia-driver suggests no packages.

Versions of packages nvidia-driver-libs:amd64 depends on:
ii  libgl1-nvidia-glvnd-glx  470.223.02-1
ii  nvidia-egl-icd   470.223.02-1

Versions of packages nvidia-driver-libs:amd64 recommends:
ii  libgles-nvidia1 470.223.02-1
ii  libgles-nvidia2 470.223.02-1
ii  libglx-nvidia0  470.223.02-1
ii  libnvidia-cfg1  470.223.02-1
ii  libnvidia-encode1   470.223.02-1
ii  libopengl0  1.3.2-1
ii  nvidia-driver-libs  470.223.02-1
ii  nvidia-vulkan-icd   470.223.02-1

Versions of packages nvidia-driver-libs:i386 depends on:
ii  libgl1-nvidia-glvnd-glx  470.223.02-1
ii  nvidia-egl-icd   470.223.02-1

Versions of packages nvidia-driver-libs:i386 recommends:
ii  libgles-nvidia1470.223.02-1
ii  libgles-nvidia2470.223.02-1
ii  libglx-nvidia0 470.223.02-1
ii  libnvidia-encode1  470.223.02-1
ii  libopengl0 1.3.2-1
ii  nvidia-vulkan-icd  470.223.02-1

Versions of packages xserver-xorg-video-nvidia depends on:
ii  libc6  2.31-13+deb11u10
ii  libnvidia-glcore   470.223.02-1
ii  nvidia-alternative 470.223.02-1
ii  nvidia-installer-cleanup   20151021+13
ii  nvidia-legacy-check470.223.02-1
ii  nvidia-support 20151021+13
ii  xserver-xorg-core [xorg-video-abi-24]  2:1.20.11-1+deb11u13

Versions of packages xserver-xorg-video-nvidia recommends:
ii  nvidia-driver470.223.02-1
ii  nvidia-settings  470.141.03-1~deb11u1
ii  nvidia-vdpau-driver  470.223.02-1

xserver-xorg-video-nvidia suggests no packages.

Versions of packages nvidia-alternative depends on:
ii  dpkg1.20.13
ii  glx-alternative-nvidia  1.2.1~deb11u1
ii  nvidia-legacy-check 470.223.02-1

Versions of packages glx-alternative-nvidia depends on:
ii  dpkg  1.20.13
ii  glx-alternative-mesa  1.2.1~deb11u1
ii  glx-diversions1.2.1~deb11u1
ii  update-glx1.2.1~deb11u1

Versions of packages glx-alternative-nvidia suggests:
ii  nvidia-driver [nvidia-driver-any]  470.223.02-1

Versions of packages xserver-xorg-video-intel depends on:
ii  libc6  2.31-13+deb11u10
ii  libdrm-intel1  

Bug#1070725: ssh-agent: take flock on socket file/dir in /tmp

[Luca Boccassi]

Package: openssh-client
Severity: important

Hi,

The default tmpfiles.d/tmp.conf will soon start cleaning up /tmp/ once
a day, automatically deleting files older than 10 days
(ctime/mtime/atime are all taken into account).

In order to avoid the ssh auth socket in /tmp being deleted while
in use (e.g.: long term session), please patch ssh-agent to take a
flock(2) on the /tmp/ssh-xxx directory while it's running, as per
documentation:

https://www.freedesktop.org/software/systemd/man/latest/tmpfiles.d.html#Age

Aside from this, it would be better to switch the location to
XDG_RUNTIME_DIR (/run/user/UID), as that's more appropriate for per-
user-session ephemeral state. The ssh agent provided by gnupg already
switched some time ago:

SSH_AUTH_SOCK=/run/user/1000/gnupg/S.gpg-agent.ssh

-- 
Kind regards,
Luca Boccassi


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

Bug#1070346: Acknowledgement (how to activate the module "pcspkr" (PC speaker))

[Bjarni Ingi Gislason]

  Sorry, I had forgotten to open for the MASTER channel in
'alsamixer -c 1'.

  Case solved.

Bug#1070724: tmux: take flock on socket file/dir in /tmp/

[Luca Boccassi]

Package: tmux
Severity: important

Hi,

The default tmpfiles.d/tmp.conf will soon start cleaning up /tmp/ once
a day, automatically deleting files older than 10 days
(ctime/mtime/atime are all taken into account).

In order to avoid the /tmp/tmux-UID/default socket being deleted while
in use (e.g.: long term session), please patch tmux to take a flock(2)
on the directory while it's running, as per documentation:

https://www.freedesktop.org/software/systemd/man/latest/tmpfiles.d.html#Age

Aside from this, it would be better to switch the location to
XDG_RUNTIME_DIR (/run/user/UID), as a predictable name such as the one
used by tmux can be easily hijacked by anything that manages to run
before tmux is started, given /tmp is world writable by default. screen
already switched some time ago to /run/.

Thanks!

-- 
Kind regards,
Luca Boccassi


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

Bug#1068017: Y2038-safe replacements for utmp/wtmp and lastlog

[Craig Small]

On Wed, 8 May 2024 at 09:03, Jun MO  wrote:

> 1) I hope there will still be the original
> w(1)/last(1)/lastb(1)/lastlog(1)/faillog(1)
> tools which can still read *old* format utmp/wtmp/lastlog in Debian at
> least for
> a while after switch to Y2038-safe replacements. Those tools can read
>

I can only speak for w.  It currently prefers what it gets from systemd or
elogind, effectively
iterating over the sessions coming from sd_get_sessions() if sd_booted()
returns true.

If sd_booted() returns false, then it uses the old utmp/utmpx files for
now. Besides the Y2038
issue, the utmp "API" is pretty awful with things like errors pretty much
undetectable. There is also
the problem about who (e.g. which process) should be writing to those files
as you have pointed out
in your email.

For now w/uptime will use utmp as a fallback, but I'll be happy if this
gets updated to something better; it's a low-priority
for me because systemd/elogind do what I need most of the time.

 - Craig

Bug#1070723: bullseye-pu: package bart/0.6.00-3+deb11u1

[Santiago Vila]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: b...@packages.debian.org, sanv...@debian.org
Control: affects -1 + src:bart

[ Reason ]
This upload fixes Bug #1026061 FTBFS randomly in bullseye.

[ Impact ]
Anybody who try to build the package from source may find
that the package FTBFS unexpectedly.

[ Tests ]
I've tested the fixed package in the AWS instances where it
used to fail, and it does not fail anymore.

[ Risks ]
Very low risk, as the change merely increases the tolerance for
a floating point comparison in the tests. The program itself
does not really change.

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

[ Changes ]
See debdiff.

[ Other info ]
I'm going to upload the package after sending this report,
but I'll wait for approval before pushing changes to salsa.diff -Nru bart-0.6.00/debian/changelog bart-0.6.00/debian/changelog
--- bart-0.6.00/debian/changelog2020-09-21 16:16:16.0 +0200
+++ bart-0.6.00/debian/changelog2024-05-07 23:05:00.0 +0200
@@ -1,3 +1,11 @@
+bart (0.6.00-3+deb11u1) bullseye; urgency=medium
+
+  * Team upload.
+  * Cherry-pick 0004-relax-failing-unit-test.patch from
+release 0.7.00-1. Fixes FTBFS bug. Closes: #1026061.
+
+ -- Santiago Vila   Tue, 07 May 2024 23:05:00 +0200
+
 bart (0.6.00-3) unstable; urgency=medium
 
   * Team upload
diff -Nru bart-0.6.00/debian/patches/0004-relax-failing-unit-test.patch 
bart-0.6.00/debian/patches/0004-relax-failing-unit-test.patch
--- bart-0.6.00/debian/patches/0004-relax-failing-unit-test.patch   
1970-01-01 01:00:00.0 +0100
+++ bart-0.6.00/debian/patches/0004-relax-failing-unit-test.patch   
2024-05-07 23:05:00.0 +0200
@@ -0,0 +1,21 @@
+From: Martin Uecker 
+Date: Mon, 25 Oct 2021 18:59:03 +0200
+Subject: relax failing unit test
+
+---
+ utests/test_nufft.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/utests/test_nufft.c b/utests/test_nufft.c
+index ec02762..95b65c5 100644
+--- a/utests/test_nufft.c
 b/utests/test_nufft.c
+@@ -114,7 +114,7 @@ static bool test_nufft_adjoint(void)
+ 
+   debug_printf(DP_DEBUG1, "adjoint diff: %f\n", diff);
+ 
+-  bool ret = (diff < 1.E-6f);
++  bool ret = (diff < 1.E-5f);
+ 
+   linop_free(op);
+ 
diff -Nru bart-0.6.00/debian/patches/series bart-0.6.00/debian/patches/series
--- bart-0.6.00/debian/patches/series   2020-09-21 16:16:16.0 +0200
+++ bart-0.6.00/debian/patches/series   2024-05-07 23:05:00.0 +0200
@@ -1,3 +1,4 @@
 0001-makefile-change-for-compatibility-with-debian.patch
 0002-remove-empty-directory.patch
 0003-deactivate-ode-unit-tests.patch
+0004-relax-failing-unit-test.patch

Bug#1069410: efitools: FTBFS on arm64: make[1]: *** [Make.rules:130: HelloWorld-signed.efi] Error 1

[Steve McIntyre]

Control: tags -1 +confirmed

On Sat, Apr 20, 2024 at 02:01:48PM +0200, Lucas Nussbaum wrote:
>Source: efitools
>Version: 1.9.2-3
>Severity: serious
>Justification: FTBFS
>Tags: trixie sid ftbfs
>User: lu...@debian.org
>Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-arm64
>
>Hi,
>
>During a rebuild of all packages in sid, your package failed to build
>on arm64.

...

>> Signature at: 40
>> sbsign --key DB.key --cert DB.crt --output HelloWorld-signed.efi 
>> HelloWorld.efi
>> ./cert-to-efi-sig-list -g ----123456789abc PK.crt PK.esl
>> Invalid DOS header magic
>> make[1]: *** [Make.rules:130: HelloWorld-signed.efi] Error 1

I can reproduce this here. The HelloWorld.efi binary seems to be
totally malformed. Digging further...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You lock the door
And throw away the key
There's someone in my head but it's not me 

Bug#1070722: RM: python-bcdoc -- ROM; obsolete, dead upstream, not needed anymore by current boto3

[Alexandre Detiste]

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

Dear FTP Master,

This part of Botocore tooling is not usefull anymore
and has been dead upstream for almost ten years.

https://github.com/boto/bcdoc

This package has no reverse dependencies

Greetings

Bug#1068017: Y2038-safe replacements for utmp/wtmp and lastlog

[Jun MO]

Dear Developers,

A bit from a Debian user. Please note that I am not come to here to 
blame/complain
against the Upstream/Maintainer of the pam package and the Maintainer of 
the shadow
package, or come to here to request something. I just come to here to 
present

some of my hope.

I often use the w(1)/last(1) command, and sometimes use the lastb(1) 
command.
Several days ago, I noticed that records logged in from 
console(tty{1..6}) are missing
from the output of last(1) while records from ssh/tmux/lightdm are still 
there,
and I started to guess maybe some of my recent changes to the system 
caused this.
Today I try to find out what happened, and after several hours of 
fruitless effort
(try different options of agetty/login, use strace/gdb on agetty/login 
and read
the source of the shadow package), I noticed that a word "pam_lastlog" 
in the

source code. Finally I find out the problem is caused by that login(1) use
pam_lastlog.so to write /var/log/wtmp, but pam_lastlog.so was not longer 
included
in the libpam-modules package. (It was somehow related to #1068229, but 
I missed

it.)

From my understanding, why we need to deal with the Y2038 issue is that 
the issue
may cause problems, some of which will be big problems, after year 2038. 
But so,
let's now rush some changes, to confuse users or break something? (Just 
joke and,
again I am not to blame anyone.) Are there issues using 
utmp/wtmp/lastlog and
w(1)/last(1)/lastlog(1), *currently*? Are there security issues, big 
defects or

are they hard to maintain?

If not, I prefer a bit more slow pace, compatible and less disturbed 
process.

More specifically, regarding to some changes proposed in the wiki [1],

1) I hope there will still be the original 
w(1)/last(1)/lastb(1)/lastlog(1)/faillog(1)
tools which can still read *old* format utmp/wtmp/lastlog in Debian at 
least for
a while after switch to Y2038-safe replacements. Those tools can read 
old format

files without convert/import to new format. I am keeping old wtmp files for
several years. Starting from 2016 my system with a proprietary nvidia 
driver failed to

resume from suspend2ram and playing a video using hardware accelerator would
cause the system unstable. Five years later, still having the problem, 
with some
help of reading kernel version from `last -f /var/log/wtmp.*', I finally 
found
out that there is a commit change in the kernel caused the problem. This 
shows
that having those tools installed may provide a few help. Another point 
may be
that package from 3rd parties may still write old-format 
utmp/wtmp/lastlog, it
will be good still having those tools installed at least for a while. 
Those tools
may be modified that when invoked, print messages to inform users 
time/date maybe
incorrect after the year 2038, and suggest/recommend/urge users only use 
those

tools to read old files and switch to use new replacements. Anyway it seems
keeping those tools have little harm. And I have a look into wtmpdb, 
from salsa[2].
From manpage and --help, it seems to me the current version 0.11.0 of 
wtmpdb does
not support read/import/migrate from /var/log/wtmp, the suggest of 
/usr/bin/wtmpdb
take over last(1) in the wiki is not feasible as some user may still 
expect using
`last -f /var/log/wtmp.*' to read old files. Even if new version of 
wtmpdb can
read from /var/log/wtmp without import it into 
/var/lib/wtmpdb/wtmpdb.db, it is
still good to have a choose to use the original last(1) to read from 
/var/log/wtmp.
(Also see below.) It is similar to lastlog2. I see lastlog2 can already 
import
from /var/log/lastlog, but from usage() [3], it will always import to a 
lastlog2

database.
2) I hope I can choose keeping or deleting the old utmp/wtmp/lastlog 
files when
switch to Y2038-safe replacements. By default, those old files may be 
automatically
deleted, but before extracting new package/running maint scripts, there 
may be a prompt
telling users that those files will be deleted and asking users chose 
whether continue
or not; if not, dpkg should exit without deleted those files. Or those 
will not be
automatically deleted, instead a Debian.NEWS may be displayed or maint 
script can
print a message telling those files can be safely deleted after 
converted. I think
the current dpkg already have functions to implement aforementioned 
actions as I
have seen something alike many times. I known normally purge a package 
will deleted
its log(and configuration), but wtmp/btmp/lastlog/faillog do not belong 
to any
package and many program can read from/write to them. Also it seems to 
me that
deleting logs during upgrade is not so good, and maybe leave it to users 
to decide.
You may ask why I want to keep those old format files instead of 
converting them
and use new tools to read? I can not exactly tell why, but I maybe 
afraid the
converting may not perfect and I want to compare both output before 
deleting the
old ones. For example, the old format files may have corrupted, and the 

Bug#1049972: Upstream issue

[Richard van der Hoff]

For links, this seems to be 
https://github.com/rdiff-backup/rdiff-backup/issues/616. Apparently it's 
expected behaviour.

Bug#1070706: gtk4 udeb has unsatisfiable dependencies

[Cyril Brulebois]

Hi Simon,

Simon McVittie  (2024-05-07):
> Looking at the d-i Packages.gz for amd64, the only other source
> package that has picked up the bad libpng16-16t64-udeb dependency
> seems to be matchbox-keyboard, which needs a sourceful upload to fix an
> implicit-declarations FTBFS anyway, therefore isn't useful to binNMU.

Yeah, I forgot to mention it when I worked on making d-i buildable and
runnable again, then decided it didn't matter as it's not used (TTBOMK)
at the moment.

> After that: do the release/installer teams consider udeb dependencies
> on non-udeb packages, by udebs that d-i does not currently need or use,
> to be a RC issue or merely a nice-to-have?

If udebs are actually used, I call that an RC bug and try to get it
fixed swiftly (sometimes NMUing right away when time is of the essence).
Otherwise I usually let those fly (without even filing bug reports).

See: https://d-i.debian.org/dose/
Some backstory: https://lists.debian.org/debian-boot/2024/03/msg00102.html


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


signature.asc
Description: PGP signature

Bug#1070706: gtk4 udeb has unsatisfiable dependencies

[Simon McVittie]

Control: severity 1070706 normal
Control: severity 1070714 normal

On Tue, 07 May 2024 at 22:53:33 +0200, Cyril Brulebois wrote:
> Simon McVittie  (2024-05-07):
> > do the release/installer teams consider udeb dependencies
> > on non-udeb packages, by udebs that d-i does not currently need or use,
> > to be a RC issue or merely a nice-to-have?
> 
> If udebs are actually used, I call that an RC bug and try to get it
> fixed swiftly (sometimes NMUing right away when time is of the essence).
> Otherwise I usually let those fly (without even filing bug reports).

In that case I'm downgrading #1070714 and #1070706 to normal, because the
issues I noticed while investigating #1070706 are worth tracking and being
aware of but non-RC, and the issue that Peter originally reported is not
actionable for the gtk4 maintainers (it needs to be fixed via a binNMU).

We'll need to revisit #1070714 and #1070706 if someone makes a concerted
effort to GTK3ize the installer, but that has been on my to-do list since
before bookworm and shows no signs of approaching the top, so it might
have to be someone else's project.

Thanks!

smcv

Bug#1070706: gtk4 udeb has unsatisfiable dependencies

[Simon McVittie]

On Tue, 07 May 2024 at 22:02:12 +0200, Paul Gevers wrote:
> On 07-05-2024 7:49 p.m., Simon McVittie wrote:
> > The version in testing, 4.12.5+ds-3, has the same dependencies, so this
> > is not a regression.
> 
> Is it? It seems that the version in unstable depends on libpng16-16t64-udeb
> where the version in testing depends on libpng16-16-udeb. The later exists,
> the former not.

Oh, well spotted! It looks as though src:gtk4 needs a binNMU against
libpng-dev (>= 1.6.43-4) for #1066069, because we were unlucky with
the timing of gtk4's most recent upload and so it got built against the
incorrect libpng-dev.

My understanding is that a binNMU would be better than a sourceful upload
of gtk4 because it won't reset the migration clock. If that's correct,
please could someone with release team or wanna-build powers schedule it?

nmu gtk4_4.12.5+ds-6 . ALL . -m 'rebuild with #1066069 fixed'

Looking at the d-i Packages.gz for amd64, the only other source
package that has picked up the bad libpng16-16t64-udeb dependency
seems to be matchbox-keyboard, which needs a sourceful upload to fix an
implicit-declarations FTBFS anyway, therefore isn't useful to binNMU.

After those binNMUs, the gtk4 udeb will still not be installable into
the debian-installer environment (either in testing or in unstable), but
it should at least be able to migrate, because all of its dependencies
will be packages that exist (whether deb or udeb).

After that: do the release/installer teams consider udeb dependencies
on non-udeb packages, by udebs that d-i does not currently need or use,
to be a RC issue or merely a nice-to-have?

Thanks,
smcv

Bug#1070720: tpm2-tss: test/unit/tcti-spidev failure on 32bit with 64bit time_t

[Adrian Bunk]

Source: tpm2-tss
Version: 4.1.0-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=tpm2-tss=4.1.0-1

...
SKIP: test/unit/tcti-libtpms


WARNING:test:test/unit/tcti-libtpms.c:1793:main() _FILE_OFFSET == 64 would 
produce cmocka errors. 
SKIP test/unit/tcti-libtpms (exit status: 77)

SKIP: test/unit/tcti-device
===

WARNING:tests:test/unit/tcti-device.c:454:main() _FILE_OFFSET == 64 would 
produce cmocka errors. 
SKIP test/unit/tcti-device (exit status: 77)

SKIP: test/unit/tcti-pcap
=

WARNING:tests:test/unit/tcti-pcap.c:736:main() _FILE_OFFSET == 64 would produce 
cmocka errors. 
SKIP test/unit/tcti-pcap (exit status: 77)

FAIL: test/unit/tcti-spidev
===

[==] tests: Running 1 test(s).
[ RUN  ] tcti_spi_init_test
ERROR:tcti:src/tss2-tcti/tcti-spidev.c:48:platform_spi_acquire() SPI acquire 
failed: Bad file descriptor 
ERROR:tcti:src/tss2-tcti/tcti-spi-helper.c:164:spi_tpm_helper_log_register_access()
 READ register 0xd40f00 (4 bytes) failed in transaction start 
ERROR:tcti:src/tss2-tcti/tcti-spidev.c:68:platform_spi_release() SPI release 
failed: Bad file descriptor 
ERROR:tcti:src/tss2-tcti/tcti-spidev.c:48:platform_spi_acquire() SPI acquire 
failed: Bad file descriptor 
ERROR:tcti:src/tss2-tcti/tcti-spi-helper.c:164:spi_tpm_helper_log_register_access()
 READ register 0xd40f00 (4 bytes) failed in transaction start 
ERROR:tcti:src/tss2-tcti/tcti-spidev.c:68:platform_spi_release() SPI release 
failed: Bad file descriptor 
ERROR:tcti:src/tss2-tcti/tcti-spidev.c:48:platform_spi_acquire() SPI acquire 
failed: Bad file descriptor 
ERROR:tcti:src/tss2-tcti/tcti-spi-helper.c:164:spi_tpm_helper_log_register_access()
 READ register 0xd40f00 (4 bytes) failed in transaction start 
ERROR:tcti:src/tss2-tcti/tcti-spidev.c:68:platform_spi_release() SPI release 
failed: Bad file descriptor 
...
ERROR:tcti:src/tss2-tcti/tcti-spi-helper.c:164:spi_tpm_helper_log_register_access()
 READ register 0xd40f00 (4 bytes) failed in transaction start 
ERROR:tcti:src/tss2-tcti/tcti-spidev.c:68:platform_spi_release() SPI release 
failed: Bad file descriptor 
ERROR:tcti:src/tss2-tcti/tcti-spi-helper.c:728:Tss2_Tcti_Spi_Helper_Init() 
Probing TPM failed 
[  ERROR   ] --- 0xa000a != 0
[   LINE   ] --- test/unit/tcti-spidev.c:200: error: Failure!
[  FAILED  ] tcti_spi_init_test
[==] tests: 1 test(s) run.
[  PASSED  ] 0 test(s).
[  FAILED  ] tests: 1 test(s), listed below:
[  FAILED  ] tcti_spi_init_test

 1 FAILED TEST(S)
FAIL test/unit/tcti-spidev (exit status: 1)

SKIP: test/unit/fapi-io
===

WARNING:tests:test/unit/fapi-io.c:370:main() _FILE_OFFSET == 64 would produce 
cmocka errors. 
SKIP test/unit/fapi-io (exit status: 77)


Testsuite summary for tpm2-tss 4.1.0

# TOTAL: 61
# PASS:  56
# SKIP:  4
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See ./test-suite.log
Please report to https://github.com/tpm2-software/tpm2-tss/issues

make[3]: *** [Makefile:33547: test-suite.log] Error 1

Bug#1022726: Dillo 3.1.0 released

[Rodrigo Arias]

Hi,

Dillo 3.1.0 has been released a few days ago:

https://dillo-browser.github.io/latest.html

On HN:

https://news.ycombinator.com/item?id=40260035

Now it supports OpenSSL 1.1 and 3, as well as LibreSSL and Mbed TLS 2 
and 3.


The flag --enable-ssl has been renamed to --enable-tls and is set by 
default so is no longer needed, and the following patches shouldn't be 
needed anymore:


- fix-OpenSSL-1.1-detection.patch
- fix-duckduckgo-shortcut-in-dillorc.patch
- fix-FTBFS-with-gcc-10.patch

I assume these are Debian specific:

- fix-perl-shebang.patch
- move-helper-tools-to-libexec.patch

We also install the .desktop file with the Dillo icons from upstream.

For reference, here are the changes in Arch Linux package:

https://gitlab.archlinux.org/archlinux/packaging/packages/dillo/-/commit/ee5f62bb0ce230fe0538359c829fdbb8b7dced3d

And Fedora:

https://src.fedoraproject.org/rpms/dillo/c/25c8726b48a75aadd51214d29e34f9ea6935e1e8?branch=rawhide

Thanks,
Rodrigo.

Bug#1070706: gtk4 udeb has unsatisfiable dependencies

[Paul Gevers]

Hi,

On 07-05-2024 7:49 p.m., Simon McVittie wrote:

The version in testing, 4.12.5+ds-3, has the same dependencies, so this
is not a regression.


Is it? It seems that the version in unstable depends on 
libpng16-16t64-udeb where the version in testing depends on 
libpng16-16-udeb. The later exists, the former not.



Is this requirement newly enforced by britney?


No.

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069346: please don't auto-enable the shipped timers

[Daniel Swarbrick]

Hi Evgeni,

This is possibly behaviour that has been carried over from when the 
textfile collectors were part of the prometheus-node-exporter package, 
prior to upstream splitting them out into their own git repo.


If you look closely, you will see that the systemd timers (with the 
exception of the apt collector) contain Condition... clauses, which will 
prevent them from starting if the relevant hardware is not found on the 
host. So yes, they are /enabled/ in the sense that systemd will process 
them at boot, but they won't /start/ if not applicable (even if 
attempted to be started manually) - and obviously if the timers do not 
start, then the service units won't be automatically triggered either. 
At most, you should get one log entry per timer, stating that it was not 
started, e.g.:


May 08 07:50:53 vega systemd[1]: 
prometheus-node-exporter-ipmitool-sensor.timer - Run ipmitool sensor 
metrics collection every minute was skipped because of an unmet 
condition check (ConditionDirectoryNotEmpty=/sys/class/ipmi).


Regards,
Daniel



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070685: linux-image-6.1.0-21-amd64: Found Trace in the logs about br_netfilter and nf_conntrack

[XXX XXX]

On Tue, 7 May 2024 21:01:06 +0200
Salvatore Bonaccorso  wrote:

> Control: tags -1 + moreinfo
> 
> Hi Tito,
> 
> On Tue, May 07, 2024 at 10:19:44AM +0200, Tito Ragusa wrote:
> > Package: src:linux
> > Version: 6.1.90-1
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> >* What led up to the situation?
> > 
> >Rebooting the box after kernel package upgrade
> > 
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> >
> >Nothing
> > 
> >* What was the outcome of this action?
> >  
> >Nothing 
> > 
> >* What outcome did you expect instead?
> > 
> >Rebooting without traces in the logs
> >  
> > -- Package-specific info:
> > ** Version:
> > Linux version 6.1.0-21-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.90-1 (2024-05-03)
> > 
> > ** Command line:
> > BOOT_IMAGE=/vmlinuz-6.1.0-21-amd64 
> > root=UUID=a75e6ad5-37fc-4f69-9361-f94d6c0e5d2f ro net.ifnames=0 apparmor=0 
> > selinux=0 noresume consoleblank=0 console=tty1
> > 
> > ** Tainted: WOE (12800)
> >  * kernel issued warning
> >  * externally-built ("out-of-tree") module was loaded
> >  * unsigned module was loaded
> > 
> > ** Kernel log:
> >   May  7 08:10:12 cerberus kernel: [   76.203881] [ cut here 
> > ]
> > May  7 08:10:12 cerberus kernel: [   76.203895] WARNING: CPU: 3 PID: 0 at 
> > net/bridge/br_netfilter_hooks.c:622 br_nf_local_in+0x1a9/0x1d0 
> > [br_netfilter]
> > May  7 08:10:12 cerberus kernel: [   76.203911] Modules linked in: ctr ccm 
> > nf_tables xt_nat xt_recent xt_geoip(OE) xt_NFQUEUE xt_mark xt_CT xt_tcpudp 
> > xt_helper nf_nat_ftp nf_conntrack_ftp ip6table_raw ip6table_mangle 
> > ip6table_nat xt_MASQUERADE iptable_nat nf_nat xt_TCPMSS xt_LOG 
> > nf_log_syslog ipt_REJECT nf_reject_ipv4 iptable_raw iptable_mangle 
> > xt_multiport xt_state xt_limit xt_conntrack nf_conntrack nf_defrag_ipv6 
> > nf_defrag_ipv4 libcrc32c ip6table_filter ip6_tables iptable_filter 
> > ip_tables x_tables ovpn_dco_v2(OE) ip6_udp_tunnel udp_tunnel tcp_bbr 
> > nct6775 nct6775_core hwmon_vid br_netfilter bridge stp llc nfnetlink_queue 
> > nfnetlink i915 ppdev intel_rapl_msr evdev intel_rapl_common 
> > x86_pkg_temp_thermal intel_powerclamp drm_buddy coretemp video rt2800usb 
> > wmi ghash_clmulni_intel drm_display_helper rt2x00usb sha512_ssse3 
> > sha512_generic rt2800lib rt2x00lib cec sha256_ssse3 sha1_ssse3 rc_core 
> > mac80211 aesni_intel ttm crypto_simd drm_kms_helper libarc4 cryptd cfg80211 
> > rapl intel_cstate 
 drm intel_uncore rfkill parport_pc pcspkr
> > May  7 08:10:12 cerberus kernel: [   76.203999]  serio_raw iTCO_wdt 
> > intel_pmc_bxt iTCO_vendor_support parport watchdog at24 button ext4 crc16 
> > mbcache jbd2 crc32c_generic sg sd_mod t10_pi crc64_rocksoft crc64 
> > crc_t10dif crct10dif_generic ahci libahci libata crct10dif_pclmul 
> > crct10dif_common crc32_pclmul crc32c_intel psmouse scsi_mod i2c_i801 
> > i2c_smbus ehci_pci ehci_hcd scsi_common lpc_ich usbcore igb i2c_algo_bit 
> > usb_common dca
> > May  7 08:10:12 cerberus kernel: [   76.204039] CPU: 3 PID: 0 Comm: 
> > swapper/3 Tainted: G   OE  6.1.0-21-amd64 #1  Debian 6.1.90-1
> > May  7 08:10:12 cerberus kernel: [   76.204044] Hardware name: Sophos 
> > UTM/To be filled by O.E.M., BIOS 4.6.4 11/08/2011
> > May  7 08:10:12 cerberus kernel: [   76.204046] RIP: 
> > 0010:br_nf_local_in+0x1a9/0x1d0 [br_netfilter]
> > May  7 08:10:12 cerberus kernel: [   76.204056] Code: df e8 4b b7 cd fa 66 
> > 83 ab b8 00 00 00 08 eb 94 be 04 00 00 00 48 89 df e8 34 b7 cd fa 66 83 ab 
> > b8 00 00 00 04 e9 7a ff ff ff <0f> 0b e9 f0 fe ff ff 0f 0b e9 dd fe ff ff 
> > 48 89 ef e8 41 67 d8 fa
> > May  7 08:10:12 cerberus kernel: [   76.204059] RSP: 0018:bf5600144928 
> > EFLAGS: 00010202
> > May  7 08:10:12 cerberus kernel: [   76.204062] RAX: 0002 RBX: 
> > 9ac2862ff300 RCX: 
> > May  7 08:10:12 cerberus kernel: [   76.204065] RDX: bf5600144980 RSI: 
> > 9ac2862ff300 RDI: 
> > May  7 08:10:12 cerberus kernel: [   76.204067] RBP: 9ac2848a8100 R08: 
> > 0001 R09: 9ac2872be980
> > May  7 08:10:12 cerberus kernel: [   76.204070] R10: 9ac2872be000 R11: 
> > 0002 R12: bf5600144980
> > May  7 08:10:12 cerberus kernel: [   76.204072] R13:  R14: 
> > 9ac282f4bac0 R15: 9ac2d027da00
> > May  7 08:10:12 cerberus kernel: [   76.204074] FS:  () 
> > GS:9ac5b018() knlGS:
> > May  7 08:10:12 cerberus kernel: [   76.204077] CS:  0010 DS:  ES:  
> > CR0: 80050033
> > May  7 08:10:12 cerberus kernel: [   76.204080] CR2: 5618751eb018 CR3: 
> > 2e610006 CR4: 000606e0
> > May  7 08:10:12 cerberus kernel: [   76.204083] Call Trace:
> > May  7 08:10:12 cerberus kernel: [   76.204087]  
> > May  7 

Bug#1070719: ITP: ppa-dev-tools -- command line client for managing PPAs in Launchpad

[Benjamin Drung]

Package: wnpp
Severity: wishlist
Owner: Benjamin Drung 
X-Debbugs-Cc: debian-de...@lists.debian.org, bdr...@debian.org

* Package name: ppa-dev-tools
  Version : 0.5.0
  Upstream Contact: Bryce Harrington 
* URL : https://launchpad.net/ppa-dev-tools
* License : GPL
  Programming Lang: Python
  Description : command line client for managing PPAs in Launchpad

 This package provides a command line tool for creating, deleting, and
 configuring Personal Package Archives (PPAs). It includes functionality to
 wait/block until all packages have built.

I am using this package and plan to maintain it as part of the Debian
Python Team.

-- 
Benjamin Drung
Debian & Ubuntu Developer

Bug#925623: RFP: karma -- A simple tool that allows you to execute JavaScript code in multiple real browsers.

[Antoine Beaupré]

Hi!

On 2019-03-27 15:07:59, Jeff Cliff wrote:

[...]

> The main goal for Karma is to bring a productive testing environment to 
> developers. The environment being 
> one where they don't have to set up loads of configurations, but rather a 
> place where developers can 
> just write the code and get instant feedback from their tests. Because 
> getting quick feedback is what
> makes you productive and creative.

Do you still think we should package this in Debian? Since this bug was
filed, there hasn't been a single change upstream, in over 6 years
now... I wasn't familiar with Karma, and I suspect other (better
maintained) solutions might be more relevant here.

I'm asking because I found this bug while looking for *another* karma:

https://github.com/prymitive/karma

... which is about Prometheus alerting and monitoring, something
completely different...

a.

-- 
Treating different things the same can generate as much inequality as
treating the same things differently.
- Kimberlé Crenshaw

Bug#1061216: Please upgrade to llvm-toolchain-17

[Gregor Riepl]

If a fix for this can't be released on time, I'm requesting an exception for 
llvm-15. Removing OpenVDB from Debian will affect Blender, which is is 
relatively high-profile and should not just be axed for the sake if a pruning 
operation.


You still have time, we aren't going to release the trixie anytime soon :) but 
we won't probably block the removal in testing for openvdb (the popcon isn't 
high IMHO).


Let's hope upstream notices the issue and fixes it.

In the meantime, it may be possible to remove the immediate pressure by simply 
disabling the build of libopenvdb-ax. The rest of OpenVDB doesn't require LLVM 
15, and I couldn't find any Debian package that depends on it (save for 
python3-openvdb, which will simply not have AX support).

This should at least bring Blender back into trixie.

I did a quick build test with the AX component disabled, and that seems to work 
fine. Blender also compiles. Didn't try to install and run the final result, 
though.

Bug#758985: libsqlite3-0: Please support 'icu' and 'unicode61' tokenizers

[GCS]

Hi Mike,

On Mon, May 6, 2024 at 10:27 PM Mike Gabriel  wrote:
> Find attached a .debdiff patch that fixes bug #758985 by building
> sqlite3 with SQLITE_ENABLE_ICU.
 I think there was a time when it was already enabled. Caused some
problems, but so late I can't remember exactly.

> Please consider enabling the ICU extension and making sqlite3 i18n
> capable for languages using regional fonts etc. If this change is not
> acceptable, please also let me know.
 I'm going to upload it to experimental as it will help to test it
easily first. Would it pull in too many extra dependencies with ICU?
Need to be checked as well.

> Maybe it could be an approach to upload an ICU-enabled version of
> sqlite3 to experimental and ask people to test their
> services/applications with the new-featured sqlite3. I can help with
> communications if needed. Please let me know.
 Do you have a list of people, projects that will be affected by this
change? Sure, it would help to reach them for comments.

Regards,
Laszlo/GCS

Bug#998197: kdeconnectd: should not listen on all interfaces by default

[Witold Baryluk]

Package: kdeconnect
Followup-For: Bug #998197
X-Debbugs-Cc: witold.bary...@gmail.com
Control: severity 998197 serious
Control: tags 998197 + security

Bug#1070718: ITP: python-gfloat -- Python module of generic floating point encode/decode logic

[Scott Kitterman]

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

* Package name: python-gfloat
  Version : 0.1
  Upstream Contact: Andrew Fitzgibbon 
* URL : https://github.com/graphcore-research/gfloat
* License : Expat
  Programming Lang: Python
  Description : Python module of generic floating point encode/decode logic

 An implementation of generic floating point encode/decode logic, handling
 various current and proposed floating point types:
 .
   - IEEE 754: Binary16, Binary32
   - OCP Float8: E5M2, E4M3
   - IEEE WG P3109: P{p} for p in 1..7
   - OCP MX Formats: E2M1, M2M3, E3M2, E8M0, INT8, and the MX block formats.
 .
 The library favours readability and extensibility over speed - for fast
 implementations of these datatypes see, for example, ml_dtypes, bitstring, MX
 PyTorch Emulation Library.

I intend to maintain this as part of the Debian Python Team.  It's
needed to run tests for the newest version of python-bitstring.

Scott K

Bug#1070717: linux-image-6.7.12-amd64: Mediatek mt7921e WiFi fails connecting after hibernation since 6.7.12

[Richard Rosner]

Package: src:linux
Version: 6.7.12-1
Severity: normal

Dear Maintainer,
Since upgrading to Linux 6.7.12 from 6.6.15, connecting to WiFi after
waking up
from hibernation fails. The journal lists these kernel errors, I can't
see any
other relevant errors:

Mai 07 16:53:03 kernel: mt7921e :01:00.0: Message 00020007 (seq 1)
timeout
Mai 07 16:53:03 kernel: mt7921e :01:00.0: PM: dpm_run_callback():
pci_pm_restore+0x0/0xe0 returns -110
Mai 07 16:53:03 kernel: mt7921e :01:00.0: PM: failed to restore async:
error -110
Mai 07 16:53:03 kernel: mt7921e :01:00.0: Failed to get patch semaphore
Mai 07 16:53:03 kernel: mt7921e :01:00.0: AMD-Vi: Event logged
[IO_PAGE_FAULT domain=0x000d address=0xfff4ff80 flags=0x]
Mai 07 16:53:03 kernel: mt7921e :01:00.0: Message 0010 (seq 14)
timeout
Mai 07 16:53:03 kernel: mt7921e :01:00.0: Failed to get patch semaphore
Mai 07 16:53:03 kernel: mt7921e :01:00.0: Message 0010 (seq 15)
timeout
Mai 07 16:53:03 kernel: mt7921e :01:00.0: Failed to get patch semaphore
Mai 07 16:53:03 kernel: mt7921e :01:00.0: Message 46ed (seq 1)
timeout
Mai 07 16:53:03 kernel: mt7921e :01:00.0: AMD-Vi: Event logged
[IO_PAGE_FAULT domain=0x000d address=0xffbb9a80 flags=0x]
Mai 07 16:53:03 kernel: ieee80211 phy0: PM: dpm_run_callback():
wiphy_resume+0x0/0x1b0 [cfg80211] returns -110
Mai 07 16:53:03 kernel: ieee80211 phy0: PM: failed to restore async:
error -110
Mai 07 16:53:06 kernel: mt7921e :01:00.0: Message 0010 (seq 2)
timeout
Mai 07 16:53:06 kernel: mt7921e :01:00.0: Failed to get patch semaphore
Mai 07 16:53:09 kernel: mt7921e :01:00.0: Message 0010 (seq 3)
timeout
Mai 07 16:53:09 kernel: mt7921e :01:00.0: Failed to get patch semaphore
Mai 07 16:53:13 kernel: mt7921e :01:00.0: Message 46ed (seq 4)
timeout
Mai 07 16:53:13 kernel: mt7921e :01:00.0: AMD-Vi: Event logged
[IO_PAGE_FAULT domain=0x000d address=0xffd52d00 flags=0x]

dmesg doesn't indicated any firmware issues when grepping for
mt7921e. The firmware at hand comes directly from the April tarball on
kernel.org, as the iGPU already needed much newer firmware as available from
Debian repos, so I just copied over the whole archive. This wasn't an issue
with 6.6.15. Also, in the last weeks before 6.7.12 was released to
testing, I
did compile 6.8.8 and 6.8.9 based on Debians 6.6.15 config (updates with
make
olddefconfig) and compiled to Debian packages, which showed a similar
behavior.
So this might be an upstream issue, yet I can't be sure.


-- Package-specific info:
** Version:
Linux version 6.7.12-amd64 (debian-ker...@lists.debian.org)
(x86_64-linux-gnu-gcc-13 (Debian 13.2.0-23) 13.2.0, GNU ld (GNU Binutils
for Debian) 2.42) #1 SMP PREEMPT_DYNAMIC Debian 6.7.12-1 (2024-04-24)

** Command line:
BOOT_IMAGE=/@/boot/vmlinuz-6.7.12-amd64
root=UUID=557dc1ed-2335-4fe5-806d-012051c96cbf ro rootflags=subvol=@
quiet
cryptdevice=UUID=91aa7dec-7df2-4330-82c5-f5b544612416:luks-91aa7dec-7df2-4330-82c5-f5b544612416
root=/dev/mapper/luks-91aa7dec-7df2-4330-82c5-f5b544612416 splash
resume=/dev/mapper/luks-4deac7d3-52a0-4f41-84bb-b913eb17f834

** Not tainted

** Kernel log:
[  422.107842] audit: type=1400 audit(1715094289.283:515):
apparmor="ALLOWED" operation="open" class="file"
profile="libreoffice-soffice"
name="/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/app-gnome-org.kde.dolphin-6145.scope/memory.max"
pid=6388 comm=433220436F6D70696C657254687265 requested_mask="r"
denied_mask="r" fsuid=1000 ouid=1000
[  422.128664] audit: type=1400 audit(1715094289.303:516):
apparmor="ALLOWED" operation="open" class="file"
profile="libreoffice-soffice"
name="/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/app-gnome-org.kde.dolphin-6145.scope/memory.max"
pid=6388 comm=433220436F6D70696C657254687265 requested_mask="r"
denied_mask="r" fsuid=1000 ouid=1000
[  422.151895] audit: type=1400 audit(1715094289.327:517):
apparmor="ALLOWED" operation="open" class="file"
profile="libreoffice-soffice"
name="/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/app-gnome-org.kde.dolphin-6145.scope/memory.max"
pid=6388 comm=433220436F6D70696C657254687265 requested_mask="r"
denied_mask="r" fsuid=1000 ouid=1000
[  422.172284] audit: type=1400 audit(1715094289.347:518):
apparmor="ALLOWED" operation="open" class="file"
profile="libreoffice-soffice"
name="/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/app-gnome-org.kde.dolphin-6145.scope/memory.max"
pid=6388 comm=433220436F6D70696C657254687265 requested_mask="r"
denied_mask="r" fsuid=1000 ouid=1000
[  422.194409] audit: type=1400 audit(1715094289.371:519):
apparmor="ALLOWED" operation="open" class="file"
profile="libreoffice-soffice"
name="/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/app-gnome-org.kde.dolphin-6145.scope/memory.max"
pid=6388 comm=433120436F6D70696C657254687265 requested_mask="r"
denied_mask="r" fsuid=1000 ouid=1000
[  

Bug#1069092: Bug#1069102: linux-image-6.1.0-20-amd64 and cifs mount problem on some folders which get hidden on shares

[Salvatore Bonaccorso]

Hi,

On Tue, May 07, 2024 at 06:35:06PM +, Kari Lempiäinen wrote:
> Hi,
> 
> Looks like this fixed the problem. I ran a couple of backup jobs to
> cifs-mounted shares and no error messages so far. Thanks!

Thanks for the confirmation!

Regards,
Salvatore

Bug#988432: gnome-shell: segfault in libgobject-2.0.so.0.6600.8

[azura]

Hi,

I keep getting this segfault every single or second day. Most of the
crashes occur while using Gimp (painting with stylus-kind of
mouse-input; to be precise: the pen of the lenovo x230T). I cannot
recall if this was the case before all crashes, but at least 3 times
happened during similiar activities.

I use Gimp a lot. These crashes keep having severe impact on my
workflow. Is there anything one can do to avoid these crashes? I am
running on oldstable

uname -a

Linux 5.10.0-28-amd64 #1 SMP Debian 5.10.209-2 (2024-01-31) x86_64
GNU/Linux


apt list gnome-shell

gnome-shell/oldstable,now 3.38.6-1~deb11u1 amd64



dmesg:

[260...] gnome-shell[57903]: segfault at 1 ip 7fc9746ca57d sp
7fff582e4620 error 4 in libgobject-2.0.so.0.6600.8[7fc9746c5000+2f000]
[260...] Code: 0f 1f 44 00 00 48 8d 15 2f d1 02 00 e9 dd fe ff ff 66
66 2e 0f 1f 84 00 00 00 00 00 90 48 83 ec 28 48 85 ff 0f 84 a3 00 00
00 <48> 8b 07 a9 ff 7f 00 00 74 59 48 8b 07 66 25 ff 7f 66 3d ff 7f 0f

Bug#1070685: linux-image-6.1.0-21-amd64: Found Trace in the logs about br_netfilter and nf_conntrack

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi Tito,

On Tue, May 07, 2024 at 10:19:44AM +0200, Tito Ragusa wrote:
> Package: src:linux
> Version: 6.1.90-1
> Severity: normal
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> 
>Rebooting the box after kernel package upgrade
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>
>Nothing
> 
>* What was the outcome of this action?
>  
>Nothing 
> 
>* What outcome did you expect instead?
> 
>Rebooting without traces in the logs
>  
> -- Package-specific info:
> ** Version:
> Linux version 6.1.0-21-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.90-1 (2024-05-03)
> 
> ** Command line:
> BOOT_IMAGE=/vmlinuz-6.1.0-21-amd64 
> root=UUID=a75e6ad5-37fc-4f69-9361-f94d6c0e5d2f ro net.ifnames=0 apparmor=0 
> selinux=0 noresume consoleblank=0 console=tty1
> 
> ** Tainted: WOE (12800)
>  * kernel issued warning
>  * externally-built ("out-of-tree") module was loaded
>  * unsigned module was loaded
> 
> ** Kernel log:
>   May  7 08:10:12 cerberus kernel: [   76.203881] [ cut here 
> ]
> May  7 08:10:12 cerberus kernel: [   76.203895] WARNING: CPU: 3 PID: 0 at 
> net/bridge/br_netfilter_hooks.c:622 br_nf_local_in+0x1a9/0x1d0 [br_netfilter]
> May  7 08:10:12 cerberus kernel: [   76.203911] Modules linked in: ctr ccm 
> nf_tables xt_nat xt_recent xt_geoip(OE) xt_NFQUEUE xt_mark xt_CT xt_tcpudp 
> xt_helper nf_nat_ftp nf_conntrack_ftp ip6table_raw ip6table_mangle 
> ip6table_nat xt_MASQUERADE iptable_nat nf_nat xt_TCPMSS xt_LOG nf_log_syslog 
> ipt_REJECT nf_reject_ipv4 iptable_raw iptable_mangle xt_multiport xt_state 
> xt_limit xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c 
> ip6table_filter ip6_tables iptable_filter ip_tables x_tables ovpn_dco_v2(OE) 
> ip6_udp_tunnel udp_tunnel tcp_bbr nct6775 nct6775_core hwmon_vid br_netfilter 
> bridge stp llc nfnetlink_queue nfnetlink i915 ppdev intel_rapl_msr evdev 
> intel_rapl_common x86_pkg_temp_thermal intel_powerclamp drm_buddy coretemp 
> video rt2800usb wmi ghash_clmulni_intel drm_display_helper rt2x00usb 
> sha512_ssse3 sha512_generic rt2800lib rt2x00lib cec sha256_ssse3 sha1_ssse3 
> rc_core mac80211 aesni_intel ttm crypto_simd drm_kms_helper libarc4 cryptd 
> cfg80211 rapl intel_cstate drm intel_uncore rfkill parport_pc pcspkr
> May  7 08:10:12 cerberus kernel: [   76.203999]  serio_raw iTCO_wdt 
> intel_pmc_bxt iTCO_vendor_support parport watchdog at24 button ext4 crc16 
> mbcache jbd2 crc32c_generic sg sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif 
> crct10dif_generic ahci libahci libata crct10dif_pclmul crct10dif_common 
> crc32_pclmul crc32c_intel psmouse scsi_mod i2c_i801 i2c_smbus ehci_pci 
> ehci_hcd scsi_common lpc_ich usbcore igb i2c_algo_bit usb_common dca
> May  7 08:10:12 cerberus kernel: [   76.204039] CPU: 3 PID: 0 Comm: swapper/3 
> Tainted: G   OE  6.1.0-21-amd64 #1  Debian 6.1.90-1
> May  7 08:10:12 cerberus kernel: [   76.204044] Hardware name: Sophos UTM/To 
> be filled by O.E.M., BIOS 4.6.4 11/08/2011
> May  7 08:10:12 cerberus kernel: [   76.204046] RIP: 
> 0010:br_nf_local_in+0x1a9/0x1d0 [br_netfilter]
> May  7 08:10:12 cerberus kernel: [   76.204056] Code: df e8 4b b7 cd fa 66 83 
> ab b8 00 00 00 08 eb 94 be 04 00 00 00 48 89 df e8 34 b7 cd fa 66 83 ab b8 00 
> 00 00 04 e9 7a ff ff ff <0f> 0b e9 f0 fe ff ff 0f 0b e9 dd fe ff ff 48 89 ef 
> e8 41 67 d8 fa
> May  7 08:10:12 cerberus kernel: [   76.204059] RSP: 0018:bf5600144928 
> EFLAGS: 00010202
> May  7 08:10:12 cerberus kernel: [   76.204062] RAX: 0002 RBX: 
> 9ac2862ff300 RCX: 
> May  7 08:10:12 cerberus kernel: [   76.204065] RDX: bf5600144980 RSI: 
> 9ac2862ff300 RDI: 
> May  7 08:10:12 cerberus kernel: [   76.204067] RBP: 9ac2848a8100 R08: 
> 0001 R09: 9ac2872be980
> May  7 08:10:12 cerberus kernel: [   76.204070] R10: 9ac2872be000 R11: 
> 0002 R12: bf5600144980
> May  7 08:10:12 cerberus kernel: [   76.204072] R13:  R14: 
> 9ac282f4bac0 R15: 9ac2d027da00
> May  7 08:10:12 cerberus kernel: [   76.204074] FS:  () 
> GS:9ac5b018() knlGS:
> May  7 08:10:12 cerberus kernel: [   76.204077] CS:  0010 DS:  ES:  
> CR0: 80050033
> May  7 08:10:12 cerberus kernel: [   76.204080] CR2: 5618751eb018 CR3: 
> 2e610006 CR4: 000606e0
> May  7 08:10:12 cerberus kernel: [   76.204083] Call Trace:
> May  7 08:10:12 cerberus kernel: [   76.204087]  
> May  7 08:10:12 cerberus kernel: [   76.204090]  ? __warn+0x7d/0xc0
> May  7 08:10:12 cerberus kernel: [   76.204097]  ? br_nf_local_in+0x1a9/0x1d0 
> [br_netfilter]
> May  7 08:10:12 cerberus kernel: [   76.204105]  ? report_bug+0xe2/0x150
> May  7 08:10:12 cerberus kernel: [   76.204113]  

Bug#1067285: whitakers-words in Debian, gnat-13 transition

[Nicolas Boulenguez]

Hello.
The package needs to build with gnat-13 in order to be part of next
Debian release.
Are you planning a new upload in the near future?
Else, are you OK with a non maintainer upload fixing this specific bug?

Bug#1070708: unblock: rust-chrono/0.4.38-2

[Paul Gevers]

Hi,

On 07-05-2024 5:55 p.m., plugwash wrote:

Can you figure out what is going wrong and either fix it or override the tests?


As noted on IRC, it's unclear what caused this. I retriggered the test 
and it's now picked up.


For those watching, britney2 would have done this by itself too after 5 
days:

https://salsa.debian.org/release-team/britney2/-/blob/master/britney2/policies/autopkgtest.py?ref_type=heads#L138

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#979188: RFS: git-subrepo/0.4.3-1 [ITP] -- Alternative to git-submodule(1) and git-subtree(1)

[Samo Pogačnik]

Hi Daniel,

Dne 06.05.2024 (pon) ob 15:02 +0200 je Daniel Gröber napisal(a):
> 
> To be clear force-push should never ever be done when collaborating on the
> branche(s) with multiple people, except in the most dire of circumstances
> and only if everyone involved is notified appropriately. I'll be happy to
> give you commit rights on the repo as soon as you show you've internalised
> this :)
> 

I am aware that force-push on shared branches causes a mess for all other branch
users. For that reason i'd do initial work on my forked repo to propose changes 
and use force-push exclusively on my fork to reset its state to what is already 
in the collab-repo as needed.

> I thought we agreed on using plain gbp for now?
> 

Exactly, i temporarily used my old dgitized fork, until a new collab-maint-repo
is ready. I am sorry, if i did not explain mysef enough regarding that, while
working on bash-completion issue.
Now my dgitized repo is unforked and renamed to git-subrepo_dgit and a new fork
is created: https://salsa.debian.org/spog/git-subrepo

Then i also prepared a fresh update:
 git clone g...@salsa.debian.org:spog/git-subrepo.git
 cd git-subrepo/
 git remote -v
 git remote add upstream https://github.com/ingydotnet/git-subrepo.git
 git remote -v
 git fetch upstream
 gbp import-ref -u 0.4.6
 gbp dch --snapshot --auto debian/
 vim debian/changelog 
 git diff
 gbp buildpackage --git-ignore-new
 gbp dch --release --auto
 git diff
 git commit -m"Release 0.4.6-1" debian/changelog
 gbp buildpackage
 git push
 git switch upstream
 git pull upstream master
 git log
 git reset --hard HEAD~1
 git log
 git push --tags origin debian/sid upstream
 git switch debian/sid
 
This is now the updated state pushed into my fork without additional changes
regarding bash-completion.


> 
> 73a01 | | * upstream origin/upstream docs: Replace 404$  Edwin Kofler   5M
>   | |/
> 110b9 | * 0.4.6 Release 0.4.6Austin Morgan  1Y
> 
> The upstream branch is ahead of the 0.4.6 tag. Why? Seems to me you meddled
> with the upstream branch by hand instead of letting the tooling take care
> of it. Technicaly not a problem just makes me wonder what you're doing.
> 

I wonder why the tool didn't care about it again (see above). Perhaps because
the upstream branch has not been checked out initially (oh, i should've probably
called gbp clone instead of git clone - my bad).

I'll prepare another change regarding bash-completion later. I saw a few
examples using "/usr/share" from "/usr/bin" (i.e. dcut, dput, lintian, ...).

Anyway, thanks for the thorough review,
--Samo

Bug#1069092: Bug#1069102: linux-image-6.1.0-20-amd64 and cifs mount problem on some folders which get hidden on shares

[Kari Lempiäinen]

Hi,

Looks like this fixed the problem. I ran a couple of backup jobs to 
cifs-mounted shares and no error messages so far. Thanks!

Regards,
Kari


From: Salvatore Bonaccorso  on behalf of 
Salvatore Bonaccorso 
Date: Tuesday, 7. May 2024 at 19.01
To: Kari Lempiäinen 
Cc: 1069...@bugs.debian.org <1069...@bugs.debian.org>, Manfred Larcher 
, 1069...@bugs.debian.org <1069...@bugs.debian.org>
Subject: Re: Bug#1069102: linux-image-6.1.0-20-amd64 and cifs mount problem on 
some folders which get hidden on shares
Hi,

On Tue, May 07, 2024 at 03:30:58PM +, Kari Lempiäinen wrote:
> Hi,
>
> New kernel 6.1.0-21 seems to be out. Could you verify if this bus is fixed in 
> it?
>
> I found from 
> https://mirrors.edge.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.90 that 
> there is a commit b3686200adba26dd1f8beee3d9c1b34563db1e65 is that a fix for 
> this?

I closed the bug in the changelog with it, with the testing case I had
at hand. But please verify if that is the case as well in your setup.

Can you then report back?

Regards,
Salvatore

Bug#1070406: Qt5: badly clips some fonts when rendering to PDFs

[Dmitry Shachnev]

On Tue, May 07, 2024 at 05:58:55PM +, Thorsten Glaser wrote:
> Dmitry Shachnev dixit:
> 
> >Will you be able to forward your patch upstream when you finalize it?
> 
> Sort of. I can do the CLA, Gerrit, etc. dance, but I probably cannot
> respond well if they want me to test things with vanilla upstream
> (instead of the packaging), or if they have requests I as a C (but
> not C++) developer don’t understand.

I also usually test with our packaging, not with vanilla upstream.

But with Qt 6.6 from experimental there should not be much difference:
we don't have any patches for this part of code, and we are lagging only
a few versions behind upstream.

And your test example compiles without changes with Qt 6, you just need
to call qmake6 instead of qmake.

> >> +static inline int roundForBbox(qreal v)
> >> +{
> >> +return (v < 0) ? floor(v) : ceil(v);
> >> +}
> >
> >I see you are passing negated values to this function, e.g. roundForBbox(-x).
> 
> Not only them. And roundForBbox is basically just the canonical
> “round away from zero / towards ±infinity for integer results”.
> 
> The negation in the callers is to convert *some* Qt coordinates
> to PS/PDF coordinates, but only for the Y axis, as the X axis is
> the same for them.

Okay, makes sense.

> >I see why you moved properties to the top, but is moving postscriptName
> >needed? Maybe leave it where it was to minimize the diff?
> 
> It’s not. I moved the whole block to make it easier to read,
> but good point.

Thank you.

> >You are passing scalep pointer here only to multiply it by this value?
> 
> Yes.
> 
> >It looks like fontEngine is a public member of QFontSubset, so you can
> >do it in the calling code.
> 
> Yes, except it’s the callee that determines the scaling factor,
> not the caller. By passing it back like this, nothing would have
> to change in the caller should the callee ever decide to not scale.

Valid point. Let's see if Qt developers like this approach with passing a
pointer. If they don't, maybe the same thing can be achieved differently,
e.g. by returning QPair.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#755434: pmount: please support exfat filesystem (via fuse)

[Jakub Wilk]

* Vincent Danjean , 2024-05-04 23:56:

++{ "exfat", "nosuid,nodev,user", 1, "077", 
",iocharset=%s",",fmask=%04o,dmask=%04o"},


Thanks, that does the trick for me. :)

--
Jakub Wilk

Bug#1070716: /usr/libexec/gvfsd-trash: GFileInfo created without standard::name, should not be reached

[Kamila Szewczyk]

Package: gvfs-daemons
Version: 1.53.90-3
Severity: important
File: /usr/libexec/gvfsd-trash
X-Debbugs-Cc: kspalaiolo...@gmail.com

Dear Maintainer,

Casually using Thunar causes the following errors to be logged in journalctl:

May 07 20:07:17 laplace gvfsd-trash[2996]: GFileInfo created without 
standard::name
May 07 20:07:17 laplace gvfsd-trash[2996]: file ../../../gio/gfileinfo.c: line 
1698 (g_file_info_get_name): should not be reached
May 07 20:07:17 laplace gvfsd-trash[2996]: GFileInfo created without 
standard::name
May 07 20:07:17 laplace gvfsd-trash[2996]: file ../../../gio/gfileinfo.c: line 
1698 (g_file_info_get_name): should not be reached

Because of this, every time I delete a file (i.e. move it to trash), 
coincidentally my whole system
including my desktop significantly slows down and on one occasion has forced me 
to reboot by holding
the power button. I am not exactly sure of what could be the issue here, but it 
hinders my workflow
significantly and judging by the error message, an assertion in the source code 
is not being fulfilled.
If I can provide any additional information, please let me know.

Yours,
Kamila Szewczyk

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

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

Versions of packages gvfs-daemons depends on:
ii  gvfs-common  1.53.90-3
ii  gvfs-libs1.53.90-3
ii  libbluray2   1:1.3.4-1+b1
ii  libc62.38-8
ii  libglib2.0-0t64  2.80.0-9
ii  libgudev-1.0-0   238-5
ii  libsecret-1-00.21.4-1+b1
ii  libsystemd0  255.5-1
ii  libudisks2-0 2.10.1-7
ii  lsof 4.95.0-1
ii  udisks2  2.10.1-7

Versions of packages gvfs-daemons recommends:
ii  dbus  1.14.10-4+b1
ii  gvfs  1.53.90-3

Versions of packages gvfs-daemons suggests:
ii  gvfs-backends  1.53.90-3

-- no debconf information

Bug#1070406: Qt5: badly clips some fonts when rendering to PDFs

[Thorsten Glaser]

Dmitry Shachnev dixit:

>Will you be able to forward your patch upstream when you finalize it?

Sort of. I can do the CLA, Gerrit, etc. dance, but I probably cannot
respond well if they want me to test things with vanilla upstream
(instead of the packaging), or if they have requests I as a C (but
not C++) developer don’t understand.

(The other half of fixing things is even more challenging. I got a
confirmation that Mu͒seScore Evolution upstream cannot upgrade their
Qt versions so they’ll need a different fix subclassing and overriding
the library functions for some cases. If anyone sufficiently proficient
in C++ is interested in helping with that, once we got the fix for Qt
itself going, ping me. Alternatively, helping to figure out how to patch
and rebuild the exact versions they use for Win/Mac or upgrade their
versions without losing Win7 and qtwebengine, IIUC — AIUI their Mac OSX
builds are still at Qt 5.9 for that reason…)

>> +static inline int roundForBbox(qreal v)
>> +{
>> +return (v < 0) ? floor(v) : ceil(v);
>> +}
>
>I see you are passing negated values to this function, e.g. roundForBbox(-x).

Not only them. And roundForBbox is basically just the canonical
“round away from zero / towards ±infinity for integer results”.

The negation in the callers is to convert *some* Qt coordinates
to PS/PDF coordinates, but only for the Y axis, as the X axis is
the same for them.

>I see why you moved properties to the top, but is moving postscriptName
>needed? Maybe leave it where it was to minimize the diff?

It’s not. I moved the whole block to make it easier to read,
but good point.

>You are passing scalep pointer here only to multiply it by this value?

Yes.

>It looks like fontEngine is a public member of QFontSubset, so you can
>do it in the calling code.

Yes, except it’s the callee that determines the scaling factor,
not the caller. By passing it back like this, nothing would have
to change in the caller should the callee ever decide to not scale.


Sune Stolborg Vuorela dixit:

>I can't find any references to something that look like a "OS/2" table
>in the pdf spec.

That’s because we’re talking about OTF/TTF-format tables here.

The problem exists at two different layers.

One is that, when embedding and subsetting a font, Qt generates
a PDF font descriptor whose bounding box is wrong.

The other is that, when embedding and subsetting a font, Qt
converts it to quadratic-spline TTF and scales it to 2048 ppem,
then embedding the resulting TTF in the data object corresponding
to the above-mentioned font descriptor (the data object itself,
when extracted, is a fully functional .ttf font file). The OTF/TTF
file format has description tables, and Qt does not correctly adjust
all values in all tables it includes when scaling the font itself.

>Just to help me double check, how is is the OS/2 table described in the
>font in the pdf ?

The references I’ve been using are:

PDF: 
https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/pdfreference1.0.pdf
TTF: https://learn.microsoft.com/en-us/typography/opentype/spec/

The OS/2 table specifically is documented at:
https://learn.microsoft.com/en-us/typography/opentype/spec/os2

bye,
//mirabilos
-- 
18:47⎜ well channels… you see, I see everything in the
same window anyway  18:48⎜ i know, you have some kind of
telnet with automatic pong 18:48⎜ haha, yes :D
18:49⎜ though that's more tinyirc – sirc is more comfy

Bug#1070715: libboost-regex: Is the libboost-regex*-icu* Provides still needed?

[Adrian Bunk]

Package: libboost-regex1.83.0
Severity: normal

This is something to be checked, perhaps for the next Boost transition.

libboost_regex.so is no longer linked with libicu*, likely due to[1]:
  Regex:
Regex is now header only except in C++03 mode.
Support for C++03 is now deprecated.

[1] https://www.boost.org/users/history/version_1_76_0.html

Bug#1070659: transition: re2

[stefanor]

Hi Adrian (2024.05.07_17:39:58_+)
> Could this be solved through Provides, so that it could be handled 
> with binNMUs during abseil transitions?
> 
> Example:
> 
> Package: libboost-regex1.74.0
> Depends: ..., libicu72 (>= 72.1~rc-1~),...
> Provides: libboost-regex1.74.0-icu72
> 
> $ cat /var/lib/dpkg/info/libboost-regex1.74.0\:amd64.shlibs 
> libboost_regex 1.74.0 libboost-regex1.74.0-icu72

That's a neat trick. Can definitely do that.

I notice that libboost-regex doesn't include -icuXX in the soname, just
the package. That's probably good enough and I'll copy that.

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1070706: gtk4 udeb has unsatisfiable dependencies

[Simon McVittie]

Control: tags -1 + d-i
Control: found -1 4.12.5+ds-3
Control: retitle -1 gtk4 udeb has unsatisfiable dependencies
Control: clone -1 -2
Control: retitle -2 libvte-2.91-0-udeb depends on both GTK 3 and GTK 4
Control: reassign -2 src:vte2.91 0.75.92-1

On Tue, 07 May 2024 at 15:44:02 +0100, Peter Michael Green wrote:
> According to britney, gtk4's udebs are uninstallable.

gtk4 is not yet used by debian-installer (which is still on GTK 2)
so the udeb is not actually necessary, and one workaround would be to
disable it entirely (but then we'd have to put GTK 4 through NEW again
if we are ever able to upgrade d-i to it).

The version in testing, 4.12.5+ds-3, has the same dependencies, so this
is not a regression. Is this requirement newly enforced by britney?

I think a large part of the problem is that when GTK 4 support was added
to src:vte2.91, both the GTK 3 and GTK 4 versions were put into the same
udeb package, libvte-2.91-0-udeb, instead of giving the GTK 4 version
its own udeb. However, I'm unsure how that change got into testing -
if britney is enforcing installability of udebs, I would have expected
that the updated libvte-2.91-0-udeb would have been newly-uninstallable,
preventing its migration?

It seems most realistic that d-i in Debian 13 will depend on GTK 3 if
someone finds the time to do the necessary porting and testing, or stay
on GTK 2 if not, so libvte-2.91-0-udeb should become a udeb version of
only libvte-2.91-0 (i.e. GTK 3 only) as it was in Debian 12, and drop
its GTK 4 parts. That would mean that GTK 4 would no longer be regressing
the installability of libvte-2.91-0-udeb.

If there is a serious attempt to get d-i using GTK *4*, then that would
require a new libvte-2.91-gtk4-0-udeb. However, GTK 4's threading model
is definitely incompatible with the current design of cdebconf-gtk (it
calls into GTK from more than one thread, which is discouraged in GTK
3 and not allowed at all in GTK 4), so a prerequisite for that would
be to move all of cdebconf-gtk's GTK interactions onto one thread,
with message-passing between that thread and the cdebconf thread.

I'm also unsure how GTK 4 can possibly have caused libvte-2.91-0-udeb's
installability to regress anyway, because libvte-2.91-0-udeb in testing
depends on liblz4-1, which does not have a corresponding udeb. That
will need fixing (by adding a liblz4-1-udeb, or linking it statically,
or allowing .deb libraries to satisfy udebs' dependencies) if we ever
want a GTK 3 or later installer.

Making the GTK 4 udeb installable looks like a significant task. It depends
on:

OK - fontconfig-udeb (>= 2.15.0),
OK - libc6-udeb (>= 2.37),
!! - libcairo-script-interpreter2 (>= 1.18.0),
OK - libcairo2-udeb (>= 1.18.0),
OK - libepoxy0-udeb (>= 1.5.4),
OK - libfribidi0-udeb (>= 1.0.13),
OK - libgdk-pixbuf-2.0-0-udeb (>= 2.42.10+dfsg),
OK - libglib2.0-udeb (>= 2.78.4),
!! - libgraphene-1.0-0 (>= 1.10.8),
OK - libharfbuzz0-udeb (>= 8.3.0),
!! - libjpeg62-turbo (>= 1:2.1.5),
OK - libpango1.0-udeb (>= 1.52.1+ds),
OK - libpng16-16t64-udeb (>= 1.6.2),
!! - libtiff6 (>= 4.5.1+git230720),
OK - libx11-6-udeb (>= 2:1.6.0),
OK - libxcursor1-udeb (>> 1.1.2),
!! - libxdamage1 (>= 1:1.1),
OK - libxext6-udeb (>= 2:1.3.0),
OK - libxfixes3-udeb (>= 1:5.0),
OK - libxi6-udeb (>= 2:1.6.99.1),
OK - libxinerama1-udeb (>= 2:1.1.4),
OK - libxrandr2-udeb (>= 2:1.5)

cairo has a udeb, but it doesn't include the equivalent of
libcairo-script-interpreter2. It might be possible to disable the GTK
features that rely on that library? Or it might be possible to add the
script interpreter to the udeb?

graphene does not have udebs at all, and I think it's a mandatory
dependency for GTK 4, so if we ever want a GTK-4-based d-i, there is
no avoiding adding a graphene udeb.

libjpeg-turbo, tiff and libxdamage are in the same situation as graphene
(these were optional in GTK 3 but are required in GTK 4). Unlike graphene,
these are not maintained by the GNOME team, so we cannot unilaterally
add udebs to them.

smcv

Bug#1070659: transition: re2

[Adrian Bunk]

On Mon, May 06, 2024 at 01:09:37PM -0400, Stefano Rivera wrote:
>...
> included a new dependency on abseil. This broke most of the
> reverse-dependencies. It also means that transitions will get more
> frequent, as every abseil transition will change re2's ABI.
>...

Could this be solved through Provides, so that it could be handled 
with binNMUs during abseil transitions?

Example:

Package: libboost-regex1.74.0
Depends: ..., libicu72 (>= 72.1~rc-1~),...
Provides: libboost-regex1.74.0-icu72

$ cat /var/lib/dpkg/info/libboost-regex1.74.0\:amd64.shlibs 
libboost_regex 1.74.0 libboost-regex1.74.0-icu72
$

> Stefano

cu
Adrian

Bug#1026061: [+externe Mail+] Re: Bug#1026061: bart: FTBFS randomly in bullseye (failing test)

[Uecker, Martin]

Am Dienstag, dem 07.05.2024 um 19:23 +0200 schrieb Santiago Vila:
> El 7/5/24 a las 18:50, Uecker, Martin escribió:
> > Am Dienstag, dem 07.05.2024 um 17:59 +0200 schrieb Santiago Vila:
> > > El 1/1/23 a las 16:55, Uecker, Martin escribió:
> > > In the meantime, I became member of debian-med, so in theory,
> > > I could fix this myself via team upload. Would you prefer
> > > that I take care of this myself that way?
> > 
> > I wouldn't mind if you did. There are some other bugs
> > which could easily be fixed with a new upload (i.e. with
> > minor patches in the bug tracker)
> > > 
> > > (I would also handle bart-cuda, also affected but not reported yet)
> > 
> > bart-cuda needs to be updated to 0.9.00 which should
> > be straightforward in principle but need more work
> > and a binary upload.
> 
> Well, just in case: I'm talking about making an upload
> for bullseye, using the same fix in bookworm, then
> sending a bug to release.debian.org explaining the
> issue, etc.
> 
> That's mainly bureaucratic and will not interfere with your normal
> work in unstable regarding new upstream releases and such (which
> I still prefer not to handle myself).
> 
Yes, if you do not mind to do the work, please update bullseye.
That would be much appreciated.

Martin

Bug#1070713: how-can-i-help: undefined local variable or method autorm_header_done

[Nicolas Noirbent]

Package: how-can-i-help
Version: 18
Severity: important
Tags: patch

Dear Maintainer,

Running how-can-i-help outputs nothing past the initial banner, due to an 
undefined variable:

```
# how-can-i-help
==  How can you help?  (doc: https://wiki.debian.org/how-can-i-help ) ==

/usr/bin/how-can-i-help:338:in `': undefined local variable or method 
`autorm_header_done' for main:Object (NameError)

autorm_header_done == 0
^^
Did you mean?  autorm_date
```

Looking at the code following it, this should probably be:

```
autorm_header_done = 0
```

Instead.

Regards,


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

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

Versions of packages how-can-i-help depends on:
ii  libruby3.1t64 [ruby-json]  3.1.2-8.3
ii  ruby   1:3.1+nmu1
ii  ruby-debian0.3.10+b10
ii  ruby-json  2.7.2+dfsg-1

how-can-i-help recommends no packages.

how-can-i-help suggests no packages.

-- no debconf information
--- /usr/bin/how-can-i-help.orig2024-05-07 19:30:22.689794285 +0200
+++ /usr/bin/how-can-i-help 2024-05-07 19:30:32.785627292 +0200
@@ -335,7 +335,7 @@
   autorm_date = Time.now.to_date + $autorm_days
   autorm = "until #{autorm_date.to_s} "
 end
-autorm_header_done == 0
+autorm_header_done = 0
 autoremoval.sort_by { |r| [r['source'], r['package']] }.each do |r|
   next if defined?($autorm_days) && Time.at(r['removal_time']).to_date > 
autorm_date
   if autorm_header_done == 0

Bug#1026061: [+externe Mail+] Re: Bug#1026061: bart: FTBFS randomly in bullseye (failing test)

[Santiago Vila]

El 7/5/24 a las 18:50, Uecker, Martin escribió:

Am Dienstag, dem 07.05.2024 um 17:59 +0200 schrieb Santiago Vila:

El 1/1/23 a las 16:55, Uecker, Martin escribió:
In the meantime, I became member of debian-med, so in theory,
I could fix this myself via team upload. Would you prefer
that I take care of this myself that way?


I wouldn't mind if you did. There are some other bugs
which could easily be fixed with a new upload (i.e. with
minor patches in the bug tracker)


(I would also handle bart-cuda, also affected but not reported yet)


bart-cuda needs to be updated to 0.9.00 which should
be straightforward in principle but need more work
and a binary upload.


Well, just in case: I'm talking about making an upload
for bullseye, using the same fix in bookworm, then
sending a bug to release.debian.org explaining the
issue, etc.

That's mainly bureaucratic and will not interfere with your normal
work in unstable regarding new upstream releases and such (which
I still prefer not to handle myself).

Thanks.

Bug#1044135: openmw: Crosshair, interactive prompts and character creation menus not visible.

[Antoine Le Gonidec]

In addition to the missing UI, OpenMW RAM usage is very high if
-DCMAKE_BUILD_TYPE=RelWithDebInfo is not set when building mygui.

I see a fix for this is already included in the Salsa repository for
mygui.  Please consider uploading a new release based on the current
state of the git repository, as it would make OpenMW usable again
without the need to locally build updated packages.


pgp0GRibRNn4c.pgp
Description: Signature digitale OpenPGP

Bug#1070712: jinja2: CVE-2024-34064: Jinja vulnerable to HTML attribute injection when passing user input as keys to xmlattr filter

[Salvatore Bonaccorso]

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

Hi,

The following vulnerability was published for jinja2.

CVE-2024-34064[0]:
| Jinja is an extensible templating engine. The `xmlattr` filter in
| affected versions of Jinja accepts keys containing non-attribute
| characters. XML/HTML attributes cannot contain spaces, `/`, `>`, or
| `=`, as each would then be interpreted as starting a separate
| attribute. If an application accepts keys (as opposed to only
| values) as user input, and renders these in pages that other users
| see as well, an attacker could use this to inject other attributes
| and perform XSS. The fix for CVE-2024-22195 only addressed spaces
| but not other characters. Accepting keys as user input is now
| explicitly considered an unintended use case of the `xmlattr`
| filter, and code that does so without otherwise validating the input
| should be flagged as insecure, regardless of Jinja version.
| Accepting _values_ as user input continues to be safe. This
| vulnerability is fixed in 3.1.4.


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-2024-34064
https://www.cve.org/CVERecord?id=CVE-2024-34064
[1] https://github.com/pallets/jinja/security/advisories/GHSA-h75v-3vvj-5mfj
[2] 
https://github.com/pallets/jinja/commit/d655030770081e2dfe46f90e27620472a502289d

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1070711: python-werkzeug: CVE-2024-34069

[Salvatore Bonaccorso]

Source: python-werkzeug
Version: 3.0.2-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for python-werkzeug.

CVE-2024-34069[0]:
| Werkzeug is a comprehensive WSGI web application library. The
| debugger in affected versions of Werkzeug can allow an attacker to
| execute code on a developer's machine under some circumstances. This
| requires the attacker to get the developer to interact with a domain
| and subdomain they control, and enter the debugger PIN, but if they
| are successful it allows access to the debugger even if it is only
| running on localhost. This also requires the attacker to guess a URL
| in the developer's application that will trigger the debugger. This
| vulnerability is fixed in 3.0.3.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-34069
https://www.cve.org/CVERecord?id=CVE-2024-34069
[1] https://github.com/pallets/werkzeug/security/advisories/GHSA-2g68-c3qc-8985
[2] 
https://github.com/pallets/werkzeug/commit/71b69dfb7df3d912e66bab87fbb1f21f83504967
[3] 
https://github.com/pallets/werkzeug/commit/890b6b62634fa61224222aee31081c61b054ff01

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1070710: python-html-sanitizer: CVE-2024-34078: Arbitrary HTML present after sanitization because of unicode normalization

[Salvatore Bonaccorso]

Source: python-html-sanitizer
Version: 2.2-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for python-html-sanitizer.

CVE-2024-34078[0]:
| html-sanitizer is an allowlist-based HTML cleaner. If using
| `keep_typographic_whitespace=False` (which is the default), the
| sanitizer normalizes unicode to the NFKC form at the end. Some
| unicode characters normalize to chevrons; this allows specially
| crafted HTML to escape sanitization. The problem has been fixed in
| 2.4.2.


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-2024-34078
https://www.cve.org/CVERecord?id=CVE-2024-34078
[1] 
https://github.com/matthiask/html-sanitizer/security/advisories/GHSA-wvhx-q427-fgh3
[2] 
https://github.com/matthiask/html-sanitizer/commit/48db42fc5143d0140c32d929c46b802f96913550

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1026061: [+externe Mail+] Re: Bug#1026061: bart: FTBFS randomly in bullseye (failing test)

[Uecker, Martin]

Am Dienstag, dem 07.05.2024 um 17:59 +0200 schrieb Santiago Vila:
> El 1/1/23 a las 16:55, Uecker, Martin escribió:
> > I can apply the patch, but I do not have much time now.
> > Is there some urgency?
> 
> Hello. A lot of time passed without activity on this bug.
> 
> In the meantime, I became member of debian-med, so in theory,
> I could fix this myself via team upload. Would you prefer
> that I take care of this myself that way?

I wouldn't mind if you did. There are some other bugs
which could easily be fixed with a new upload (i.e. with
minor patches in the bug tracker)
> 
> (I would also handle bart-cuda, also affected but not reported yet)

bart-cuda needs to be updated to 0.9.00 which should
be straightforward in principle but need more work
and a binary upload.

Otherwise, I would have more time in July to do some work.

Martin

> 
> (Yes, I still think it would be worthy to fix this in bullseye,
> for posterity and before it becomes LTS).
> 
> Thanks.

Bug#1066228: xjdic: FTBFS: implicit declaration of functions

[Bastian Germann]

I am uploading a NMU that fixes this.
Please find the debdiff attached that builds on the experimental version.diff -Nru xjdic-24/debian/changelog xjdic-24/debian/changelog
--- xjdic-24/debian/changelog   2023-10-02 10:05:01.0 +
+++ xjdic-24/debian/changelog   2024-05-07 16:30:08.0 +
@@ -1,3 +1,10 @@
+xjdic (24-11.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix missing function declarations. Closes: #1066228
+
+ -- Bastian Germann   Tue, 07 May 2024 16:30:08 +
+
 xjdic (24-11.1) experimental; urgency=medium
 
   * Non-maintainer upload.
diff -Nru xjdic-24/debian/patches/missing-function-declarations.patch 
xjdic-24/debian/patches/missing-function-declarations.patch
--- xjdic-24/debian/patches/missing-function-declarations.patch 1970-01-01 
00:00:00.0 +
+++ xjdic-24/debian/patches/missing-function-declarations.patch 2024-05-07 
16:28:31.0 +
@@ -0,0 +1,70 @@
+diff -u xjdic-24/exjdxgen.c xjdic-24/exjdxgen.c
+--- xjdic-24/exjdxgen.c
 xjdic-24/exjdxgen.c
+@@ -22,7 +22,7 @@
+ #include 
+
+ #include 
+-/*#include */
++#include 
+ #include 
+ #include 
+ #include "xjdic.h"
+diff -u xjdic-24/xjdclient.c xjdic-24/xjdclient.c
+--- xjdic-24/xjdclient.c
 xjdic-24/xjdclient.c
+@@ -32,6 +32,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include 
+ #include 
+ #include 
+diff -u xjdic-24/xjdfrontend.c xjdic-24/xjdfrontend.c
+--- xjdic-24/xjdfrontend.c
 xjdic-24/xjdfrontend.c
+@@ -196,7 +196,6 @@
+ void RadSet();
+ void Verbtoggle();
+ void FiltSet();
+-void xjdicrc();
+ void DoRADICALS();
+ int Vlookup();
+ void AppKanji(unsigned char c1,unsigned char c2);
+diff -u xjdic-24/xjdic.h xjdic-24/xjdic.h
+--- xjdic-24/xjdic.h
 xjdic-24/xjdic.h
+@@ -71,3 +71,7 @@
+   longxjdrsp_dicloc;
+   unsigned char   xjdrsp_resstr[512];
+   } RSP_PDU;
++
++void EMtoggle();
++void xjdicrc();
++unsigned char dbchar(unsigned long xit);
+diff -u xjdic-24/xjdsa.c xjdic-24/xjdsa.c
+--- xjdic-24/xjdsa.c
 xjdic-24/xjdsa.c
+@@ -30,6 +30,8 @@
+ #include 
+ #include "xjdic.h"
+
++int Kstrcmp(int klen,unsigned char *str1);
++unsigned long jindex(unsigned long xit);
+ unsigned char Dnamet[10][100],XJDXnamet[10][100];
+ unsigned char CBname[100];
+ unsigned char *dicbufft[10];
+diff -u xjdic-24/xjdserver.c xjdic-24/xjdserver.c
+--- xjdic-24/xjdserver.c
 xjdic-24/xjdserver.c
+@@ -36,7 +36,9 @@
+
+ void xjdicrc();
+ void DicSet ();
++int Kstrcmp(int klen,unsigned char *str1);
+ unsigned char *DicName(int dn);
++unsigned long jindex(unsigned long xit);
+
+ int portno=XJ_PORTNO;
+ int DontFork = FALSE;
diff -Nru xjdic-24/debian/patches/series xjdic-24/debian/patches/series
--- xjdic-24/debian/patches/series  2023-10-02 10:05:01.0 +
+++ xjdic-24/debian/patches/series  2024-05-07 16:29:32.0 +
@@ -1 +1,2 @@
 debian.patch
+missing-function-declarations.patch

Bug#1070704: Can't decrypt root device after upgrading to systemd v256 and rebuilding initramfs

[Luca Boccassi]

Control: tags -1 moreinfo

On Tue, 07 May 2024 16:14:30 +0200 Roderich Schupp
 wrote:
> Package: systemd
> Version: 256~rc1-1~exp2
> Severity: important
> X-Debbugs-Cc: roderich.sch...@gmail.com
> 
> I have a standard LUKS-encrypted root partition.
> I upgraded systemd to v256 and ran update-initramfs.
> I rebooted into the kernel with the updated initramfs,
> but plymouth (instead of prompting for the password) now hangs and
> just shows "cryptsetup: Waiting for encrypted source device
> UUID=a75ad289-6ad8-4ac3-aebc-34a94cff72e4"
> 
> I was able to boot into an older kernel with its initramfs built with
the
> previous version of systemd (255.5-1) and the diffed the two
initrd.img.
> Turns out that the initramfs built for v256 was missing some shared
libraries
> (see below for a list). For v255 these where linked by
libsystemd.so.0
> or udevadm, but in v256 these libs are dlopen'ed, hence update-
initramfs
> doesn't detect them.
> 
> As a workaround I dropped the following into
> /etc/initramfs-tools/hooks/add-libs-for-systemd and reran update-
initramfs:
> 
> ---
> #!/bin/sh
> 
> set -e
> 
> case "$1" in
> prereqs)
> exit 0
> ;;
> esac
> 
> . /usr/share/initramfs-tools/hook-functions
> 
> copy_exec /usr/lib/x86_64-linux-gnu/libgcrypt.so.20
> copy_exec /usr/lib/x86_64-linux-gnu/libgpg-error.so.0
> copy_exec /usr/lib/x86_64-linux-gnu/libkmod.so.2
> copy_exec /usr/lib/x86_64-linux-gnu/liblz4.so.1

Which one of those libraries actually did make the difference, and what
was the error message?

-- 
Kind regards,
Luca Boccassi


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

Bug#916475: ghdl: various suggestions for the packaging

[Nicolas Boulenguez]

Source: ghdl
Followup-For: Bug #916475
Control: tags 1067446 patch
Control: tags 1067686 patch

Hello.

The attachment fixes several bugs including the release-critical one.
The build succeeds on ppc64el, although running
  neither dh_auto_test nor autopkgtests.
Debdiff only reports expected differences.

Lintian reports nothing new, but there were already two errors.
https://udd.debian.org/lintian/?packages=ghdl

0001-New-upstream-version-4.0.0-dfsg.patch
0002-New-upstream-version-4.1.0-dfsg.patch
are not attached because
* bugs.debian.org refuses heavy attachments,
* you can recreate them with
  # uscan --download-version=4.0.0
  # gbp import-orig ../ghdl_4.0.0+dfsg.orig.tar.xz
  # uscan --download-version=4.1.0
  # gbp import-orig ../ghdl_4.1.0+dfsg.orig.tar.xz
  You should get:
  Checksums-Sha1: 6f89acac3c926c9653e96e58aee6cb344ef26d4e 4862224 
ghdl_4.1.0+dfsg.orig.tar.xz
  Checksums-Sha256: 
d300c4078fa30af33cb614ff5e40f03d19e3b32eca71ca6cd1d6422c7dc40c06 4862224 
ghdl_4.1.0+dfsg.orig.tar.xz
  Files:  4da868cf483d095e014c3d3c5c7e3801 4862224 ghdl_4.1.0+dfsg.orig.tar.xz
* I have not reviewed the licenses of the new files in detail.

0003-Delegate-computation-of-Built-Using-to-dh-builtusing
0004-test-driver-move-error-reporting-to-a-separate-proce
are two commits remaining from #916475.

0006-Set-shared-object-version-to-4
0007-Build-using-GCC-13
0008-Build-using-default-LLVM-version
0010-Adapt-install-path-of-ghdl1-lib-libexec
0011-Refresh-patches-for-upstream-version-4
0012-Build-again-on-s390x-fixed-by-ghdl-4
0013-Disable-the-gcc-backend-on-risv64
0015-Apply-upstream-patch-to-fix-issues-2641-and-2642
are backported from Ubuntu.  I have split some commits, rebased, and
added information in the headers, especially the closed Debian bugs.

0005-Avoid-hardcoding-the-shared-object-version-several-t
0009-Stop-hardcoding-the-gcc-version-in-the-gcc-patches-s
0014-Standards-Version-4
0016-Add-license-paragraph-for-ghw
0017-Update-path-syntax-in-lintian-overrides
0018-Restrict-VHDL-sources-to-ASCII-encoding
0019-changelog-lintian-cleanup
0020-copyright-fix-typos-in-paths-lintian
are new suggestions. Most of them are cosmetic.

Ubuntu also ignores the build and run time tests for the llvm and
mcode backends, but as far as I understand this was only necessary
before debian/patches/fix-issue-264x.diff.


bug916475v08.tar.gz
Description: application/gzip

Bug#1070709: ITP: primtux-multiples -- graphic representation of multiplications as grid patterns

[Georges Khaznadar]

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

* Package name: primtux-multiples
  Version : 3.0
  Upstream Contact: Arnaud Champollion 
* URL : https://forge.apps.education.fr/educajou/multiples/
* License : GPL2
  Programming Lang: Python3
  Description : graphic representation of multiplications as grid patterns

 This programm is part of the project Primtux (https://primtux.fr), which aims
 to provide simple and effective programs for teaching in primary schools.

The packaging will be maintained in https://salsa.debian.org/debian/primtux-
multiples

Bug#1026061: bart: FTBFS randomly in bullseye (failing test)

[Santiago Vila]

El 1/1/23 a las 16:55, Uecker, Martin escribió:

I can apply the patch, but I do not have much time now.
Is there some urgency?


Hello. A lot of time passed without activity on this bug.

In the meantime, I became member of debian-med, so in theory,
I could fix this myself via team upload. Would you prefer
that I take care of this myself that way?

(I would also handle bart-cuda, also affected but not reported yet)

(Yes, I still think it would be worthy to fix this in bullseye,
for posterity and before it becomes LTS).

Thanks.

Bug#1069092: Bug#1069102: linux-image-6.1.0-20-amd64 and cifs mount problem on some folders which get hidden on shares

[Salvatore Bonaccorso]

Hi,

On Tue, May 07, 2024 at 03:30:58PM +, Kari Lempiäinen wrote:
> Hi,
> 
> New kernel 6.1.0-21 seems to be out. Could you verify if this bus is fixed in 
> it?
> 
> I found from 
> https://mirrors.edge.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.90 that 
> there is a commit b3686200adba26dd1f8beee3d9c1b34563db1e65 is that a fix for 
> this?

I closed the bug in the changelog with it, with the testing case I had
at hand. But please verify if that is the case as well in your setup.

Can you then report back?

Regards,
Salvatore

Bug#1070708: unblock: rust-chrono/0.4.38-2

[plugwash]

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

rust-chrono's testing excuses say (and have listed for at least a day or so)

autopkgtest for rust-trash/3.3.1-1: amd64: Test in progress, arm64: Pass, i386: 
Pass, ppc64el: Pass, s390x: Pass

However, when I look over on debci I do not see any relavent pending tests.
There is a test that looks relavent to me a few days ago

rust-chrono/0.4.38-2 rust-fundu/1.0.0...
src:rust-chrono from unstable
src:rust-fundu from unstable
src:rust-pure-rust-locales from unstable 

which passed, but britney seems to be ignoring it. 

Can you figure out what is going wrong and either fix it or override the tests?

Bug#1069092: Bug#1069102: linux-image-6.1.0-20-amd64 and cifs mount problem on some folders which get hidden on shares

[Kari Lempiäinen]

Hi,

New kernel 6.1.0-21 seems to be out. Could you verify if this bus is fixed in 
it?

I found from 
https://mirrors.edge.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.90 that 
there is a commit b3686200adba26dd1f8beee3d9c1b34563db1e65 is that a fix for 
this?

Regards,
Kari

From: Salvatore Bonaccorso  on behalf of 
Salvatore Bonaccorso 
Date: Thursday, 18. April 2024 at 9.39
To: Kari Lempiäinen 
Cc: 1069...@bugs.debian.org <1069...@bugs.debian.org>, Manfred Larcher 
, 1069...@bugs.debian.org <1069...@bugs.debian.org>
Subject: Re: Bug#1069102: linux-image-6.1.0-20-amd64 and cifs mount problem on 
some folders which get hidden on shares
Hi Kari,

On Thu, Apr 18, 2024 at 05:31:33AM +, Kari Lempiäinen wrote:
> Hi,
>
> I think I spoke too soon. I removed  'noserverino' options from all
> my cifs mounts yesterday and u/remounted them. From last night
> syslog I can still find the "directory entry name would overflow
> frame end of buf" entries.
>
> I have options like this in my fstab:
> //mercury/backups/mnt/backups   cifs   
> credentials=/etc/smbcredentials,uid=kari,gid=kari,_netdev,dir_mode=0775,file_mode=0775,noperm,vers=3.0
>  0  0

Thanks for reporting back! So it might be possible that the
noserverino just makes the issue easier visible.

If I would provide you a (unsigned!) kernel-image package with a
tentative patch from upstream, asking for testing, could you boot one
affected machine into it to verify if the problem is solved?

Regards,
Salvatore

Bug#1070707: wsdd: Please upgrade to version 0.8

[Laurent Bigonville]

Source: wsdd
Version: 2:0.7.1-5
Severity: normal

Hello,

Could you please upgrade the pacakge to version 0.8

This fixes bugs like https://github.com/christgau/wsdd/issues/199

Kind regards,
Laurent Bigonville


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

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

Bug#1068388: Redirect to 'www'.

[Daniel Teichmann]

Also, it is necessary to redirect every request 'www' ?

In setups where Tjener isn't the primary DNS server, this is quite 
awkward, since 'www' isn't known.
One workaround is the just add it to /etc/hosts (in addition to 
tjener.intern and tjener).


--
Daniel Teichmann
DAS-NETZWERKTEAM
Telefon: 0176 322 774 51
GnuPG Key ID: 0x8100A778
daniel.teichm...@das-netzwerkteam.de, https://das-netzwerkteam.de

Bug#1070706: gtk4 - udebs broken.

[Peter Michael Green]

Package: gtk4
Version: 4.12.5+dfsg-6
Severity: serious

According to britney, gtk4's udebs are uninstallable.

 * ∙ ∙ libgtk-4-1-udeb/amd64 has unsatisfiable dependency
 * ∙ ∙ libgtk-4-1-udeb/arm64 has unsatisfiable dependency
 * ∙ ∙ libgtk-4-1-udeb/i386 has unsatisfiable dependency
 * ∙ ∙ libgtk-4-1-udeb/mips64el has unsatisfiable dependency
 * ∙ ∙ libgtk-4-1-udeb/ppc64el has unsatisfiable dependency
 * ∙ ∙ libgtk-4-1-udeb/s390x has unsatisfiable dependency
 * ∙ ∙ migrating libgtk-4-1-udeb/4.12.5+ds-6/amd64 to testing makes
   libvte-2.91-0-udeb/0.75.92-1/amd64
    uninstallable
 * ∙ ∙ migrating libgtk-4-1-udeb/4.12.5+ds-6/arm64 to testing makes
   libvte-2.91-0-udeb/0.75.92-1/arm64
    uninstallable
 * ∙ ∙ migrating libgtk-4-1-udeb/4.12.5+ds-6/i386 to testing makes
   libvte-2.91-0-udeb/0.75.92-1/i386
    uninstallable
 * ∙ ∙ migrating libgtk-4-1-udeb/4.12.5+ds-6/mips64el to testing makes
   libvte-2.91-0-udeb/0.75.92-1/mips64el
    uninstallable
 * ∙ ∙ migrating libgtk-4-1-udeb/4.12.5+ds-6/ppc64el to testing makes
   libvte-2.91-0-udeb/0.75.92-1/ppc64el
    uninstallable
 * ∙ ∙ migrating libgtk-4-1-udeb/4.12.5+ds-6/s390x to testing makes
   libvte-2.91-0-udeb/0.75.92-1/s390x
    uninstallable


This is preventing gtk4 migrating to testing which is leaving many
packages uninstallable in testing on time64 architectures.

Bug#1070646: rust-gst-plugin-gtk4: Please package GStreamer plugin .so as well for use by non-Rust applications

[Matthias Geiger]

On Mon, 6 May 2024 19:47:51 +0200 Matthias Geiger  
wrote:

>
> Pushed my wip so far to

> https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/659.

Well the plugin (without dmabuf) builds and can be installed from this 
branch now if you want to try it out.


It will probably land in experimental first if I get around to uploading it.

--
Matthias Geiger 
Debian Maintainer

Bug#1070705: gpsprune: import of SRTM-Data into gpx-file failes

[Eberhard]

Package: gpsprune
Version: 24-1
Severity: normal

Dear Maintainer,

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

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

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


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

Kernel: Linux 6.7.12-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 gpsprune depends on:
ii  default-jre [java9-runtime] 2:1.17-75
ii  openjdk-17-jre [java9-runtime]  17.0.11+9-1

Versions of packages gpsprune recommends:
ii  gnuplot-x11 6.0.0+dfsg1-1
ii  gpsbabel1.9.0+ds-2+b2
ii  libimage-exiftool-perl  12.76+dfsg-1
ii  libjava3d-java  1.5.2+dfsg-18
ii  libjava3d-jni   1.5.2+dfsg-18
ii  libvecmath-java 1.5.2-7

gpsprune suggests no packages.

-- no debconf information

Bug#1070703: transition: libunibreak

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 07/05/2024 15:52, Pino Toscano wrote:

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: libunibr...@packages.debian.org
Control: affects -1 + src:libunibreak
User: release.debian@packages.debian.org
Usertags: transition

Hi,

I'd like to request a transition slot for the update of the libunibreak
library 5.1 to 6.1. Each new major version bumps the SOVERSION, and in
this case there are only few new symbols.

There are few users of libunibreak in Debian:
- fbreader
- krita
- libass
I verified that all of them build fine using the new version of
libunibreak.


Go ahead.

Emilio

Bug#1069258: ruby-curb: test regression with curl 8.7.1: client read function EOF fail, only only 4/5 of needed bytes read

[Lucas Nussbaum]

Control: forwarded -1 https://github.com/taf2/curb/issues/451

Hi,

I forwarded this upstream.

Lucas

Bug#1070703: transition: libunibreak

[Pino Toscano]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: libunibr...@packages.debian.org
Control: affects -1 + src:libunibreak
User: release.debian@packages.debian.org
Usertags: transition

Hi,

I'd like to request a transition slot for the update of the libunibreak
library 5.1 to 6.1. Each new major version bumps the SOVERSION, and in
this case there are only few new symbols.

There are few users of libunibreak in Debian:
- fbreader
- krita
- libass
I verified that all of them build fine using the new version of
libunibreak.

Ben file:

title = "libunibreak";
is_affected = .depends ~ "libunibreak5" | .depends ~ "libunibreak6";
is_good = .depends ~ "libunibreak6";
is_bad = .depends ~ "libunibreak5";

Thanks,
-- 
Pino

Bug#1070702: bookworm-pu: package nano/7.2-1+deb12u1

[Jordi Mallach]

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

As we did in previous Debian releases, this is an update
for Debian stable's nano package with selected patches from
the upstream maintainer.

3 of the patches minor security issues, and the other one
fixes a potential data-loss issue.

Additionally there's a minor update to the default nanorc which
is a backport from 7.2-2, which was meant to be included in
Debian 12.0 but freeze came along. It just gets rid of some
control characters in some commented-out example bindings,
replacing them with the new style syntax.

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

This source update was prompted by Salvatore while discussing one of the
3 security issues.

Thanks in advance,
Jordi
diff -Nru nano-7.2/debian/changelog nano-7.2/debian/changelog
--- nano-7.2/debian/changelog   2023-01-18 16:31:52.0 +0100
+++ nano-7.2/debian/changelog   2024-05-06 08:10:01.0 +0200
@@ -1,3 +1,15 @@
+nano (7.2-1+deb12u1) bookworm; urgency=medium
+
+  * The "Premio Nacional de Tauromaquia" release.
+  * Fix a partial sync of debian/nanorc in the previous upload.
+This updates some example bindings to the new syntax, avoiding
+having control characters in the configuration file (closes: #1032422).
+  * Add 4 post-7.2 upstream patches to fix two minor security issues and
+a potential data-loss situation. Thanks, Benno Schulenberg!
+  * Set debian-branch to bookworm.
+
+ -- Jordi Mallach   Mon, 06 May 2024 08:10:01 +0200
+
 nano (7.2-1) unstable; urgency=medium
 
   * The "Blue checkmark" release.
diff -Nru nano-7.2/debian/gbp.conf nano-7.2/debian/gbp.conf
--- nano-7.2/debian/gbp.conf2022-12-07 23:10:44.0 +0100
+++ nano-7.2/debian/gbp.conf2024-05-06 08:09:34.0 +0200
@@ -1,5 +1,5 @@
 [DEFAULT] 
 pristine-tar = true 
-debian-branch = master 
+debian-branch = bookworm
 upstream-branch = upstream
 upstream-vcs-tag = v%(version)s
diff -Nru nano-7.2/debian/nanorc nano-7.2/debian/nanorc
--- nano-7.2/debian/nanorc  2023-01-18 15:37:55.0 +0100
+++ nano-7.2/debian/nanorc  2024-05-06 08:04:37.0 +0200
@@ -286,15 +286,14 @@
 
 ## For quickly uppercasing or lowercasing the word under or after the cursor.
 ## (These effectively select a word and pipe it through a sed command.)
-# bind Sh-M-U "Oc|sed 's/.*/\U&/'
" main
-# bind Sh-M-L "Oc|sed 's/.*/\L&/'
" main
+#bind Sh-M-U "{nextword}{mark}{prevword}{execute}|sed 's/.*/\U&/'{enter}" main
+#bind Sh-M-L "{nextword}{mark}{prevword}{execute}|sed 's/.*/\L&/'{enter}" main
 
 ## For copying a marked region to the system clipboard:
 # bind Sh-M-T "{execute}|xsel -ib{enter}{undo}" main
 
 ## For snipping trailing blanks when you save a file:
 # bind ^S "{execute}| sed 's/\s\+$//' {enter}{savefile}" main
-# bind Sh-M-T "|xsel -ib
u" main
 
 ## If you would like nano to have keybindings that are more "usual",
 ## such as ^O for Open, ^F for Find, ^H for Help, and ^Q for Quit,
diff -Nru 
nano-7.2/debian/patches/0001-linter-use-a-format-string-to-deflect-format-string-.patch
 
nano-7.2/debian/patches/0001-linter-use-a-format-string-to-deflect-format-string-.patch
--- 
nano-7.2/debian/patches/0001-linter-use-a-format-string-to-deflect-format-string-.patch
 1970-01-01 01:00:00.0 +0100
+++ 
nano-7.2/debian/patches/0001-linter-use-a-format-string-to-deflect-format-string-.patch
 2024-05-06 08:08:19.0 +0200
@@ -0,0 +1,47 @@
+From f2e042114d2c1696031bc2f2251e28a9c8eceaff Mon Sep 17 00:00:00 2001
+From: Benno Schulenberg 
+Date: Mon, 27 Mar 2023 11:47:37 +0200
+Subject: [PATCH 1/4] linter: use a format string, to deflect format-string
+ attacks
+
+This fixes the first part of https://savannah.gnu.org/bugs/?63964.
+
+Reported-by: Vince Vince
+---
+ src/text.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/src/text.c b/src/text.c
+index f4a3d7c5..34551fea 100644
+--- a/src/text.c
 b/src/text.c
+@@ -2846,7 +2846,7 @@ void do_linter(void)
+   confirm_margin();
+ #endif
+   edit_refresh();
+-  statusline(NOTICE, curlint->msg);
++  statusline(NOTICE, "%s", curlint->msg);
+   bottombars(MLINTER);
+   }
+ 
+@@ -2877,7 +2877,7 @@ void do_linter(void)
+   beep();
+   napms(600);
+   last_wait = time(NULL);
+-  statusline(NOTICE, curlint->msg);
++  statusline(NOTICE, "%s", curlint->msg);
+   }
+   } else if (function == do_page_down || function 

Bug#1070701: RM: roger-router -- RoQA; RC-buggy; stuck on end-of-life librm

[Bastian Germann]

Source: roger-router
Severity: normal

#1019303 shows that roger-router is stuck on librm getting updated to a newer 
libsoup to build with the current gupnp.
That is not going to happen because it is considered end-of-life. So if librm cannot be dropped from the dependencies, 
please remove both roger-router and librm. I am going to reassign this to ftp.debian.org after a while when nobody has 
answered.

Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[rhys]

The /tmp/ as tmpfs discussion is funny to me because while we've been kicking 
around the idea of whether or not to clean /tmp/, having /tmp/ as a tmpfs makes 
that whole argument moot. It all goes away at boot time! Problem solved! :D

Honestly, I see this one as a much easier topic, assuming that no one is 
talking about changing existing systems. (I haven't seen anyone say that.)

So for new systems, /tmp/ as a tmpfs strikes me as a legitimate option, and the 
partition layout is something that any good admin pays close attention to on 
any new system, particularly a new distribution or even distro version. (That 
is, even going from 12.1 to 12.2, I'm going to be on the lookout for changes in 
the installer.)

Whether you want /tmp as a tmpfs is a decision that's going to be made at the 
same time as whether or not /home should be on a separate partition. The admin 
is going to do whatever makes the most sense for this system. 

To me, it's all about the display. I want to see what partition will be mounted 
as root, what partition will be mounted as /home, which will be swap (if any), 
and so on. But I don't need to see /proc and /sys. Those aren't optional. 

So if /tmp is not part of the root partition, it doesn't matter if it's a 
separate partition or a tmpfs. It should just appear in the screen that 
displays the filesystem layout, and then the admin can decide whether or not 
that's a good idea. 

I have no opinion on whether or not it should be the default. If /tmp/ as tmpfs 
becomes the default, I would probably only override that on certain low-memory 
systems that I run and just leave it on most others. I've seen it done before 
and it seemed to work fine in some cases and not in others. 

As long as it's somewhere that I can SEE it in the installer, I'd be happy. 
That's definitely a thing the admin can change later on with few consequences. 

Sent from my mobile device.


From: Hakan Bayındır 
Sent: Tuesday, May 7, 2024 05:45
To: 966...@bugs.debian.org; debian-de...@lists.debian.org
Cc: Carsten Leonhardt; Luca Boccassi; Peter Pentchev
Subject: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default 
[was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

Similarly, I’m following the thread for a couple of days now, and wondering 
about its implications. 

When I consider server scenarios, pushing /tmp to RAM looks highly undesirable 
from my perspective. All the servers I manage use their whole RAMs and using 
the unused space as a disk cache is far more desirable than a /tmp mount. When 
servers are virtualized, RAM is at premium, and a disk cache is way more usable 
rather than /tmp in the RAM. 

The other scenario I think is HPC, where applications use all the RAM 
available, squeezing the hardware dry. Again, /tmp in the RAM is very 
undesirable, because /tmp/$USER is also heavily used and an OOM situation 
creates a lose-lose situation where you either delete runtime files, or lose 
the executing job, which results in job failure in any case. 

On the other hand, I personally use my desktop computer as a development 
workstation and use tons of RAM either with software or with VMs. Again a /tmp 
in RAM is an inferior scenario to my current setup. 

The only useful state where /tmp is in RAM is single board computers where temp 
is both lightly utilized and maximizing SD/eMMC life is important. These 
systems even mount /var/log to a tmpfs and sync on boot/reboot/shutdown, 
reducing flash wear. 

Deleting /var/tmp has the same problems since long running tasks on the servers 
might need a file once in a month, but it can be crucial for functions of the 
software. 

I can’t see any scenario where these two are useful in typical or niche 
installations of Debian. 

FWIW, RedHat family doesn’t mount /tmp as a tmpfs on its default installation. 

Cheers, 

H. 

Bug#1070698: transition: ticcutils

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 07/05/2024 14:21, Bastian Germann wrote:

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: ticcut...@packages.debian.org
Control: affects -1 + src:ticcutils
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-ticcutils.html

User: release.debian@packages.debian.org
Usertags: transition

I am requesting a transition slot for ticcutils. The experimental version builds 
libticcutils9 while the unstable version has libticcutils8t64. The referenced 
tracker is okay. All reverse dependencies build with the experimental version 
(where an experimental version exists, it is the one that builds with 
libticcutils9).


Go ahead.

Emilio

Bug#1070700: gpgv-from-sq: apt complains "Unknown response from gpgv to --assert-pubkey-algo check: gpgv: error: Error parsing command-line arguments"

[Daniel Kahn Gillmor]

Package: gpgv-from-sq
Version: 0.8.0-5
Control: affects -1 + apt
Control: forwarded -1 + 
https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg/-/issues/68

As of 50e3fee26ae843a812b1c9ec8531946931773fd3, apt 2.7.13 started
trying to use --assert-pubkey-algo, which appears to have been hastily
added to GnuPG in 2.4.5 in response to https://dev.gnupg.org/T6946
(itself an outgrowth of https://bugs.debian.org/1042391)

It strikes me that a better approach would have been to simply have
GnuPG improve the default policy about what signatures are acceptable,
and bring them into alignment with the upcoming requirements for the
replacement of rfc 4880
(https://datatracker.ietf.org/doc/draft-ietf-openpgp-crypto-refresh/).

Anyway, the way that apt is testing for the presence of this option is
quite brittle: it first tests whether the option is there or not, by
trying to use it and inspecting the format of the string emitted on
stderr.  while gpgv-sq doesn't currently accept the option, its error
messages aren't the same as g10code's implementation of gpgv.

The result is that when gpgv-from-sq is installed, apt complains about
each configured repository:

 Unknown response from gpgv to --assert-pubkey-algo check: gpgv:   error: 
Error parsing command-line arguments"

So one of three things should happen:

- gpgv-sq could implement --assert-pubkey-algo, which afaict is fairly
  ill-defined.

- gpgv-sq could adjust its error messages to match the regex that apt is
  using during its test.

- apt should relax its test for --assert-pubkey-algo so that it is less
  brittle.

Even better, apt could adopt the `sopv` interface, which has a more
structured, simple, and formal definition, and then depend by default on
a sopv implementation that is already known to support the reasonable
policies described here.

 --dkg


signature.asc
Description: PGP signature

Bug#1068922: runit-init: configuring network interfaces at boot inside LXC with runit as init system fails

[Martin Steigerwald]

Hi Lorenzo.

Sorry for late answer.

Lorenzo - 14.04.24, 11:36:32 CEST:
> On Sat, 13 Apr 2024 15:05:41 +0200
> 
> Martin Steigerwald  wrote:
> > Martin Steigerwald - 13.04.24, 14:32:16 CEST:
> > > Any idea how to find the cause of what is happening here?
> > 
> > I found the cause:
> > 
> > The container starts out with an almost empty environment. In
> > [...]
> > 
> > root@zdevuan:~# cat rcS.log
> > 
> > >> environment
> > 
> > container=lxc
> > PWD=/
> > 
> > >> end of environment
> > 
> > No PATH defined.
> > 
> > The script defines it. See line 8 in my changed script. However it
> > 
> > does not export it. Thus adding line 9 fixes the bug I reported:
> >   8 PATH=/sbin:/usr/sbin:/bin:/usr/bin
> >   9 export PATH
> > 
> > The network is configured just fine after adding that line.
> >
> > Same goes for stage 2. In /etc/runit/2 I added:
> >[...]
> >
> > Exporting the PATH there as well like
> > 
> >   1 #!/bin/sh
> >   2
> >   3 PATH=/usr/local/sbin:/usr/local/bin:/sbin:/usr/sbin:/bin:/usr/bin
> >   4 export PATH
> >   5 SVDIR=/etc/service
> > 
> > fixes
> > 
> > root@zdevuan:~# cat /etc/boot.d/network
> > #!/usr/bin/env sh
> > 
> > /etc/init.d/networking restart
> > 
> > The network is configured even without the "export PATH" fix in
> > /etc/runit/1.
> 
> OK, so if I undertand correctly we either export PATH in the
> /etc/init.d/networking script or we export PATH both in stage 1 and 2
> (so the script does not fail during boot and can be called during
> runtime): is that correct?

In case it is called during both stage 1 and stage 2, yes. And yes, it 
appears there is a link to the networking script in /etc/rcS.d which would 
be called in stage 1.

> If yes I think it's better to fix the networking script (ifupdown pkg)
> so that the fix works for sysvinit users too.

Yeah, I would think so to, but:

% grep PATH /etc/init.d/networking
PATH="/sbin:/bin:/usr/sbin:/usr/bin"

Yet, it has no export statement, it just defines the variable.

What may be happening here is that something called from the script 
requires a valid path, but without export the variable would not be 
exported to that something.

So it might be that the networking script needs an "export PATH" added to 
it.

However:

> Different story if multiple scripts fails during boot because of empty
> PATH; many scripts in /etc/rc.S/ set their PATH but others don't..
> Could you confirm that no other scripts fails in your container setup
> when PATH is not exported in stage 1 ?

There are some script which do not set a command search path:

% grep -L "PATH" *
README
brightness
checkroot-bootclean.sh
hwclock.sh
mariadb
mountall-bootclean.sh
mountnfs-bootclean.sh
mountnfs.sh
procps
rcS
sudo

I am not sure whether those work correctly or not. Some are not even 
supposed to work inside a container at all.

What I wonder: What is the supposed default or standard here?

Are init scripts supposed to be started with PATH variable set up and 
exported or not? How is it done with SysVInit? I bet it would be best to 
match as close as possible what SysVInit is doing to be as compatible as 
possible.

Otherwise it might be challenging to chase and find all the corner cases 
with existing setups. And as there is no issue initializing the network in 
the container with SysVInit instead of Runit used as PID 1, I'd consider a 
change in Runit. At least it could be challenging to find whether 
networking inside a container is the only thing that breaks.

Of course in case PATH variable needs to be setup, one might argue that 
Incus/LXC needs to do it, cause networking is setup just fine even with 
Runit in physical machines or VMs.

So far the container appears to be working, but I did not check whether 
every single init script works correctly. Partly due to bootlogd not 
working inside the container.

> > I just wonder why stage 2 contains /usr/local bin directories. I think
> > that should not be the case. Shall I report this as a different issue?
> 
> PATH is passed to env call for runsvdir, so I guess one can exec a bin
> from local as runscript (not sure) without setting the PATH. I can't
> think of other use cases..
> I'm fine with removing, just a bit wary, I'm afraid to break some custom
> setup

Hmm, I get that. I am just a bit concerned as it may be a security issue.

> > I added empty "debug" and "verbose" files in /etc/runit but did not
> > find any debug output. Maybe those files needed to have some content.
> > Maybe it requires bootlogd.
> 
> those files only work for runit stuff (runscripts and the sv trigger),
> boot scripts are for sysvinit and do not obey to runit settings :(
> perhaps it's time to roll some native runit bootscripts..

I see. Well that would be great. But also would require a lot of work and 
testing I bet.

Best,
-- 
Martin

Bug#1026175: RM: gcc-python-plugin -- RoQA; dead upstream; RC-buggy; last released with buster

[Bastian Germann]

Control: retitle -1 RM: gcc-python-plugin -- RoQA; dead upstream; RC-buggy; 
last released with buster
Control: reassign -1 ftp.debian.org

Please remove gcc-python-plugin. It is dead upstream, RC-buggy including a non-resolvable dependency, and was last 
released with buster. The removal was suggested 1.5 years ago to the maintainer and did not recieve any feedback.

Bug#1070699: gdb can not be started on testing

[Michael Becker]

Package: gdb
Version: 13.2-1+b1
Severity: grave
Justification: renders package unusable

mmediately stops with the error:

gdb: symbol lookup error: /lib/x86_64-linux-gnu/libpython3.11.so.1.0: undefined 
symbol: XML_SetReparseDeferralEnabled

libpython3.11.so.1.0 is part of libpython3.11t64


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

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

Versions of packages gdb depends on:
ii  libbabeltrace1   1.5.11-3+b6
ii  libc62.38-7
ii  libdebuginfod1t640.191-1+b1
ii  libexpat12.6.2-1
ii  libgcc-s114-20240330-1
ii  libgmp10 2:6.3.0+dfsg-2+b1
ii  libipt2  2.0.6-1
ii  liblzma5 5.6.1+really5.4.5-1
ii  libmpfr6 4.2.1-1+b1
ii  libncursesw6 6.4+20240414-1
ii  libpython3.11t64 3.11.9-1
ii  libreadline8t64  8.2-4
ii  libsource-highlight4t64  3.1.9-4.3
ii  libstdc++6   14-20240330-1
ii  libtinfo66.4+20240414-1
ii  libxxhash0   0.8.2-2+b1
ii  libzstd1 1.5.5+dfsg2-2
ii  zlib1g   1:1.3.dfsg-3.1

Versions of packages gdb recommends:
ii  libc6-dbg [libc-dbg]  2.38-7

Versions of packages gdb suggests:
pn  gdb-doc
pn  gdbserver  

-- no debconf information

Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Hakan Bayındır]

Similarly, I’m following the thread for a couple of days now, and wondering 
about its implications.

When I consider server scenarios, pushing /tmp to RAM looks highly undesirable 
from my perspective. All the servers I manage use their whole RAMs and using 
the unused space as a disk cache is far more desirable than a /tmp mount. When 
servers are virtualized, RAM is at premium, and a disk cache is way more usable 
rather than /tmp in the RAM.

The other scenario I think is HPC, where applications use all the RAM 
available, squeezing the hardware dry. Again, /tmp in the RAM is very 
undesirable, because /tmp/$USER is also heavily used and an OOM situation 
creates a lose-lose situation where you either delete runtime files, or lose 
the executing job, which results in job failure in any case.

On the other hand, I personally use my desktop computer as a development 
workstation and use tons of RAM either with software or with VMs. Again a /tmp 
in RAM is an inferior scenario to my current setup.

The only useful state where /tmp is in RAM is single board computers where temp 
is both lightly utilized and maximizing SD/eMMC life is important. These 
systems even mount /var/log to a tmpfs and sync on boot/reboot/shutdown, 
reducing flash wear.

Deleting /var/tmp has the same problems since long running tasks on the servers 
might need a file once in a month, but it can be crucial for functions of the 
software.

I can’t see any scenario where these two are useful in typical or niche 
installations of Debian.

FWIW, RedHat family doesn’t mount /tmp as a tmpfs on its default installation.

Cheers,

H.

> On 7 May 2024, at 12:42, Peter Pentchev  wrote:
> 
> On Tue, May 07, 2024 at 10:38:14AM +0200, Carsten Leonhardt wrote:
>> Luca Boccassi  writes:
>> 
>>> Defaults are defaults, they are trivially and fully overridable where
>>> needed if needed. Especially container and VM managers these days can
>>> super trivially override them via SMBIOS Type11 strings or
>>> Credentials, ephemerally and without changing the guest image at all.
>> 
>> That argument goes both ways and I prefer safe defaults. What
>> you/upstream propose are unsafe defaults, as was shown by several
>> comments in this thread. Whoever wants the unsafe defaults of deleting
>> old files and risking OOM situations can than "trivially and fully
>> override" the safe defaults.
> 
> So I've been wondering for a couple of days now, following this thread...
> ...would it be a good idea to make this a debconf prompt, high priority,
> default "yes", so that it is activated on new automatically installed
> systems, but people who upgrade their current Debian installations can
> choose to keep the old behavior?
> 
> I do realize that more debconf prompts are not always desirable, and
> such decisions must be taken on a case-by-case basis, so... yeah.
> 
> G'luck,
> Peter
> 
> -- 
> Peter Pentchev  r...@ringlet.net r...@debian.org pe...@morpheusly.com
> PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
> Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

Bug#1068852: update

[Gürkan Myczko]

so basically it works, but it probably might need devendoring:
fbthrift, folly, zstd, xxhash, parallel-hashmap

http://bananas.debian.net/debian/dwarfs/

Bug#1070698: transition: ticcutils

[Bastian Germann]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: ticcut...@packages.debian.org
Control: affects -1 + src:ticcutils
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-ticcutils.html
User: release.debian@packages.debian.org
Usertags: transition

I am requesting a transition slot for ticcutils. The experimental version builds libticcutils9 while the unstable 
version has libticcutils8t64. The referenced tracker is okay. All reverse dependencies build with the experimental 
version (where an experimental version exists, it is the one that builds with libticcutils9).

Bug#1070697: ITP: rtl-ais -- simple AIS tuner and generic dual-frequency FM demodulator

[Gürkan Myczko]

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

* Package name: rtl-ais
  Version : 0.3+git20240507+ds
  Upstream Authors: dgiardini
Kyle Keen 
Peter Schultz 
2013 Astra Paging Ltd / AISHub (i...@aishub.net)
  URL : https://github.com/dgiardini/rtl-ais
* License : GPL-2-or-later
  Description : simple AIS tuner and generic dual-frequency FM 
demodulator

 This provides the rtl_ais command, which decodes AIS data from Software
 Defined Radio (SDR) and outputs AIVDM / AIVDO sentences.

Bug#1057562: Forwarded upstream (Was: gcr4: FTBFS: failing tests)

[Santiago Vila]

Hi.

They finally enabled my account in gnome's gitlab and I have now offered them
hardware to reproduce it, if they need it.

Thanks.

Bug#1070695: server-control.html: ambiguous text bug bugs assigned to 2 packages

[Vincent Lefevre]

Package: debbugs-web
Version: 2.6.0
Severity: normal

At https://www.debian.org/Bugs/server-control.en.html (coming from
html/server-control.html.in in debbugs):

  The bug tracking system uses this information, in conjunction with
  fixed versions recorded when closing bugs, to display lists of bugs
  open in various versions of each package. It considers a bug to be
  open when it has no fixed version, or when it has been found more
  recently than it has been fixed.

But this text is ambiguous when a bug is assigned to 2 different
packages and is marked as fixed in only one of these packages.

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

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

Versions of packages debbugs-web depends on:
ii  apache2 [httpd]  2.4.59-2
pn  libdebbugs-perl  
ii  perl 5.38.2-4

debbugs-web recommends no packages.

Versions of packages debbugs-web suggests:
ii  libapache2-mod-perl2  2.0.13-1+b3
pn  libcgi-alert-perl 

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

Bug#1070696: shim-helpers-amd64-signed: Does not force to install the corresponding shim-signed code.

[eric]

Package: shim-helpers-amd64-signed
Version: 1+15.8+1
Severity: normal

I requires shim-unsigned instead of shim-signed. Currently I have on my system
15.8 for helpers, 15.8 for shim-unsigned but still 15.7 for signed.

dpkg -l shim*
Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder
| 
État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-installé/W=attend-traitement-déclenchements
|/ Err?=(aucune)/besoin Réinstallation (État,Err: majuscule=mauvais)
||/ Nom   Version  Architecture Description
+++-=---=>
un  shim(aucune description 
n'est disponible)
ii  shim-helpers-amd64-signed 1+15.8+1 amd64boot loader to 
chain-load signed boot loaders (signed>
ii  shim-signed:amd64 1.40+15.7-1  amd64Secure Boot 
chain-loading bootloader (Microsoft-signe>
ii  shim-signed-common1.40+15.7-1  all  Secure Boot 
chain-loading bootloader (common helper s>
ii  shim-unsigned:amd64   15.8-1   amd64boot loader to 
chain-load signed boot loaders under S>


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

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

Versions of packages shim-helpers-amd64-signed depends on:
ii  shim-unsigned  15.8-1

shim-helpers-amd64-signed recommends no packages.

shim-helpers-amd64-signed suggests no packages.

-- no debconf information

Bug#1066624: xfireworks: FTBFS: etc.c:11:19: error: implicit declaration of function ‘time’ [-Werror=implicit-function-declaration]

[Yukiharu YABUKI]

Hi,

Thanks for your comment. I'll try to enable
-Werror=implicit-function-declaratin

On Wed, 13 Mar 2024 12:58:32 +0100
Lucas Nussbaum  wrote:

[snip]
> This is most likely caused by a change in dpkg 1.22.6, that enabled
> -Werror=implicit-function-declaration. For more information, see
> https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration
> 
> Relevant part (hopefully):
> > cc -c arguments.c -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
> > -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
> > -fstack-protector-strong -fstack-clash-protection -Wformat 
> > -Werror=format-security -fcf-protection
> > etc.c: In function ‘InitializeRand’:
> > etc.c:11:19: error: implicit declaration of function ‘time’ 
> > [-Werror=implicit-function-declaration]
> >11 |   srand((unsigned)time(NULL));
> >   |   ^~~~
> > etc.c:2:1: note: ‘time’ is defined in header ‘’; did you forget to 
> > ‘#include ’?
> > 1 | #include "etc.h"
> >   +++ |+#include 
> > 2 | 
> > cat xfireworks.1 | gzip -9 > xfireworks.6.gz
> > gzip: warning: GZIP environment variable is deprecated; use an alias or 
> > script
> > cat xfireworks.conf | ./mkconf > xfireworks_conf.h
> > cc -c XFireworks.c -I/usr/X11R6/include -Wdate-time -D_FORTIFY_SOURCE=2 -g 
> > -O2 -Werror=implicit-function-declaration 
> > -ffile-prefix-map=/<>=. -fstack-protector-strong 
> > -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
> > cc1: some warnings being treated as errors
> > make[1]: *** [Makefile:73: etc.o] Error 1
[snip]

--
Yukiharu YABUKI 

Bug#1068349: nbsphinx/nbconvert broken by lxml 5.2: lxml.html.clean

[Vincent Lefevre]

Control: reopen -1

On 2024-05-07 11:25:05 +0200, Vincent Lefevre wrote:
> What's the status of this bug?
> 
> apt-listbugs still reports python3-lxml as buggy:
> 
> serious bugs of python3-lxml (5.1.0-1 → 5.2.1-1) 
>  b1 - #1068349 - nbsphinx/nbconvert broken by lxml 5.2: lxml.html.clean 
> (Fixed: nbconvert/6.5.3-5)
> Summary:
>  python3-lxml(1 bug)
> 
> Indeed, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068349
> says: "Found in versions nbconvert/6.5.3-4, lxml/5.2.1-1".
> 
> So python3-lxml 5.2.1-1 is regarded as buggy.

And this bug prevents the migration to testing:

https://tracker.debian.org/pkg/lxml

testing migrations
[...]
Issues preventing migration:
∙ ∙ Updating lxml would introduce bugs in testing: #1068349

It seems that this bug (assigned to 2 different packages) has been
closed by mistake, due to the fix of nbconvert:

Format: 1.8
Date: Sun, 14 Apr 2024 16:52:34 +0100
Source: nbconvert
Architecture: source
Version: 6.5.3-5
[...]
Closes: 1042699 1068349
[...]
   * (Build-)depend on python3-lxml-html-clean (closes: #1068349).

But this is inconsistent with the fact that lxml is still marked as
unfixed. So, reopening.

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

Bug#1070688: gnupg: PINENTRY_USER_DATA not passed to pinentry

[Farblos]

A quick comparison of the package sources hasn't revealed anything obvious.

So here is a reproducer (custom pinentry defined in gpg-agent.conf that dumps
its environment):

[~]$ grep ^pinentry-program .gnupg/gpg-agent.conf 
pinentry-program/home/farblos/tmp/pinentry
[~]$ cat /home/farblos/tmp/pinentry
#!/bin/bash

( date; export; ) > /tmp/pinentry.log
[~]$ ls -al /home/farblos/tmp/pinentry
-rwxrwxr-x 1 farblos farblos 51 May  7 11:48 /home/farblos/tmp/pinentry

[~]$ gpg --encrypt --recipient BEA00D6B5803B828854E115908C216F6FF7B6B30 
/home/farblos/tmp/pinentry > /home/farblos/tmp/pinentry.gpg
[~]$ systemctl --user restart gpg-agent

[~]$ gpg --decrypt /home/farblos/tmp/pinentry.gpg
gpg: encrypted with 3072-bit RSA key, ID 646746DE42C89279, created 2022-11-30
  "backup"
gpg: decryption failed: No secret key
[~]$ cat /tmp/pinentry.log 
Tue May  7 11:55:11 CEST 2024
declare -x DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus"
declare -x DISPLAY=":0"
declare -x GSM_SKIP_SSH_AGENT_WORKAROUND="true"
declare -x HOME="/home/farblos"
declare -x INVOCATION_ID="73be729ef883415aaf43ca4a4de2049b"
declare -x JOURNAL_STREAM="8:18301"
declare -x LANG="en_US.UTF-8"
declare -x LANGUAGE="en_US:en"
declare -x LC_COLLATE="POSIX"
declare -x LC_MEASUREMENT="de_DE.UTF-8"
declare -x LC_PAPER="de_DE.UTF-8"
declare -x LC_TIME="POSIX"
declare -x LISTEN_FDNAMES="extra:ssh:std:browser"
declare -x LISTEN_FDS="4"
declare -x LISTEN_PID="4355"
declare -x LOGNAME="farblos"
declare -x MANAGERPID="1776"
declare -x 
MEMORY_PRESSURE_WATCH="/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/gpg-agent.service/memory.pressure"
declare -x MEMORY_PRESSURE_WRITE="c29tZSAyMDAwMDAgMjAwMDAwMAA="
declare -x OLDPWD
declare -x 
PATH="/home/farblos/bin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
declare -x PWD="/home/farblos"
declare -x SHELL="/bin/bash"
declare -x SHLVL="1"
declare -x SSH_AUTH_SOCK="/run/user/1000/gnupg/S.gpg-agent.ssh"
declare -x SYSTEMD_EXEC_PID="4355"
declare -x USER="farblos"
declare -x XAUTHORITY="/home/farblos/.Xauthority"
declare -x XDG_RUNTIME_DIR="/run/user/1000"
declare -x XDG_SESSION_ID="1"
declare -x XDG_SESSION_TYPE="x11"
declare -x _assuan_pipe_connect_pid="4355"

[~]$ PINENTRY_USER_DATA=foobarbaz gpg --decrypt /home/farblos/tmp/pinentry.gpg
gpg: encrypted with 3072-bit RSA key, ID 646746DE42C89279, created 2022-11-30
  "backup"
gpg: decryption failed: No secret key
[~]$ cat /tmp/pinentry.log
Tue May  7 12:08:16 CEST 2024
declare -x DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus"
declare -x DISPLAY=":0"
declare -x GSM_SKIP_SSH_AGENT_WORKAROUND="true"
declare -x HOME="/home/farblos"
declare -x INVOCATION_ID="73be729ef883415aaf43ca4a4de2049b"
declare -x JOURNAL_STREAM="8:18301"
declare -x LANG="en_US.UTF-8"
declare -x LANGUAGE="en_US:en"
declare -x LC_COLLATE="POSIX"
declare -x LC_MEASUREMENT="de_DE.UTF-8"
declare -x LC_PAPER="de_DE.UTF-8"
declare -x LC_TIME="POSIX"
declare -x LISTEN_FDNAMES="extra:ssh:std:browser"
declare -x LISTEN_FDS="4"
declare -x LISTEN_PID="4355"
declare -x LOGNAME="farblos"
declare -x MANAGERPID="1776"
declare -x 
MEMORY_PRESSURE_WATCH="/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/gpg-agent.service/memory.pressure"
declare -x MEMORY_PRESSURE_WRITE="c29tZSAyMDAwMDAgMjAwMDAwMAA="
declare -x OLDPWD
declare -x 
PATH="/home/farblos/bin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
declare -x PWD="/home/farblos"
declare -x SHELL="/bin/bash"
declare -x SHLVL="1"
declare -x SSH_AUTH_SOCK="/run/user/1000/gnupg/S.gpg-agent.ssh"
declare -x SYSTEMD_EXEC_PID="4355"
declare -x USER="farblos"
declare -x XAUTHORITY="/home/farblos/.Xauthority"
declare -x XDG_RUNTIME_DIR="/run/user/1000"
declare -x XDG_SESSION_ID="1"
declare -x XDG_SESSION_TYPE="x11"
declare -x _assuan_pipe_connect_pid="4355"

I also took debug traces of the agent, which show that the pinentry user
data is passed from gpg to the agent through assuan, but not forwarded
from there to the pinentry.  Data available on request.

Bug#1070515: dipy: FTBFS with nocheck profile

[Andreas Tille]

Control: tags -1 help
thanks

Hi Grahamm

Am Mon, May 06, 2024 at 02:08:25PM + schrieb Graham Inggs:
> Source: dipy
> Version: 1.8.0-2
> Severity: serious
> Tags: ftbfs patch

thanks a lot for the patch which looks perfectly sensible.  Unfortunatly
the build runs into a different error as you can see in Salsa CI[1]:

=== FAILURES ===
__ test_shore_fitting_no_constrain_e0 __
def test_shore_fitting_no_constrain_e0():
>   asm = ShoreModel(data.gtab, radial_order=data.radial_order,
 zeta=data.zeta, lambdaN=data.lambdaN,
 lambdaL=data.lambdaL)
E   AttributeError: '_C' object has no attribute 'radial_order'
dipy/reconst/tests/test_shore.py:70: AttributeError


Any help would be welcome
  Andreas.

[1] https://salsa.debian.org/med-team/dipy/-/pipelines/674858

-- 
https://fam-tille.de

Bug#1066211:

[Matthew Danish]

Thanks, this is very timely, I was just discussing it with upstream a
couple days ago.


On Mon, 6 May 2024 at 23:39, Arvin Sedererdj  wrote:

> Control: tags -1 + patch
>
>
>

Bug#872381: dpkg-dev: optimize Makefile snippets for debian/rules

[Nicolas Boulenguez]

Package: dpkg-dev
Followup-For: Bug #872381

Hello.
It is good to see the main suggestion merged. Thanks!

You have not applied
  0001-scripts-mk-stop-hard-coding-dpkg_datadir.patch
probably because you prefer the related parts in
  f1175056 (build: Rework subst handling for built or installed artifacts).

Ironically, f1175056 seems to introduce the exact kind of human error
that dynamic generation would prevent.
0001-build-spare-an-unneeded-subst-handling-in-pkg-info.m.patch
>From 36e98fdd10b1896f8fa89733b5e0c1781c0cce4c Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Mon, 6 May 2024 10:52:49 +0200
Subject: [PATCH] build: spare an unneeded subst handling in pkg-info.mk

This commits follows f1175056.
---
 scripts/mk/Makefile.am | 1 -
 1 file changed, 1 deletion(-)

diff --git a/scripts/mk/Makefile.am b/scripts/mk/Makefile.am
index be6076b2c..5f086ef49 100644
--- a/scripts/mk/Makefile.am
+++ b/scripts/mk/Makefile.am
@@ -18,5 +18,4 @@ include $(top_srcdir)/build-aux/subst.am
 install-data-hook:
 	$(subst_make_file) $(DESTDIR)$(pkgdatadir)/default.mk
 	$(subst_make_file) $(DESTDIR)$(pkgdatadir)/buildtools.mk
-	$(subst_make_file) $(DESTDIR)$(pkgdatadir)/pkg-info.mk
 	$(subst_make_file) $(DESTDIR)$(pkgdatadir)/vendor.mk
-- 
2.39.2

>From 7daa3aca068d997c6895757cb58ba91d66bd6842 Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Mon, 6 May 2024 11:37:14 +0200
Subject: [PATCH] scripts/mk: stop hard-coding dpkg_datadir

This path differ during tests and after installation.  Instead of
rewriting the file with a hardcoded path, compute it within Make.
---
 build-aux/subst.am   |  8 
 scripts/mk/Makefile.am   | 10 --
 scripts/mk/buildtools.mk |  4 +++-
 scripts/mk/default.mk|  2 +-
 scripts/mk/vendor.mk |  4 +++-
 5 files changed, 7 insertions(+), 21 deletions(-)

diff --git a/build-aux/subst.am b/build-aux/subst.am
index 7785e4af7..9c96e5ce0 100644
--- a/build-aux/subst.am
+++ b/build-aux/subst.am
@@ -45,11 +45,3 @@ SUFFIXES += .pl
 	@test -d `dirname $@` || $(MKDIR_P) `dirname $@`
 	$(AM_V_GEN) $(subst_perl_filter) <$< >$@
 	$(AM_V_at) chmod +x $@
-
-# Makefile support.
-
-subst_make_rules = "\
-	s{dpkg_datadir\s*=\s*[^\s]*}{dpkg_datadir = $(pkgdatadir)}; \
-	"
-
-subst_make_file = $(PERL) -i -p -e $(subst_make_rules)
diff --git a/scripts/mk/Makefile.am b/scripts/mk/Makefile.am
index be6076b2c..6e85e17b9 100644
--- a/scripts/mk/Makefile.am
+++ b/scripts/mk/Makefile.am
@@ -10,13 +10,3 @@ dist_pkgdata_DATA = \
 	pkg-info.mk \
 	vendor.mk \
 	# EOL
-
-SUFFIXES =
-
-include $(top_srcdir)/build-aux/subst.am
-
-install-data-hook:
-	$(subst_make_file) $(DESTDIR)$(pkgdatadir)/default.mk
-	$(subst_make_file) $(DESTDIR)$(pkgdatadir)/buildtools.mk
-	$(subst_make_file) $(DESTDIR)$(pkgdatadir)/pkg-info.mk
-	$(subst_make_file) $(DESTDIR)$(pkgdatadir)/vendor.mk
diff --git a/scripts/mk/buildtools.mk b/scripts/mk/buildtools.mk
index 6ce9642cd..e93319e00 100644
--- a/scripts/mk/buildtools.mk
+++ b/scripts/mk/buildtools.mk
@@ -28,7 +28,9 @@
 ifndef dpkg_buildtools_mk_included
 dpkg_buildtools_mk_included = yes
 
-dpkg_datadir = $(srcdir)/mk
+ifndef dpkg_datadir
+  dpkg_datadir := $(patsubst %/buildtools.mk,%,$(lastword $(MAKEFILE_LIST)))
+endif
 include $(dpkg_datadir)/architecture.mk
 
 # We set the TOOL_FOR_BUILD variables to the specified value, and the TOOL
diff --git a/scripts/mk/default.mk b/scripts/mk/default.mk
index c4e408b01..e1b81 100644
--- a/scripts/mk/default.mk
+++ b/scripts/mk/default.mk
@@ -4,7 +4,7 @@
 ifndef dpkg_default_mk_included
 dpkg_default_mk_included = yes
 
-dpkg_datadir = $(srcdir)/mk
+dpkg_datadir := $(patsubst %/default.mk,%,$(lastword $(MAKEFILE_LIST)))
 include $(dpkg_datadir)/architecture.mk
 include $(dpkg_datadir)/buildapi.mk
 ifeq ($(call dpkg_build_api_ge,1),yes)
diff --git a/scripts/mk/vendor.mk b/scripts/mk/vendor.mk
index 746503a33..3cd1eed3e 100644
--- a/scripts/mk/vendor.mk
+++ b/scripts/mk/vendor.mk
@@ -36,7 +36,9 @@
 ifndef dpkg_vendor_mk_included
 dpkg_vendor_mk_included = yes
 
-dpkg_datadir = $(srcdir)/mk
+ifndef dpkg_datadir
+  dpkg_datadir := $(patsubst %/vendor.mk,%,$(lastword $(MAKEFILE_LIST)))
+endif
 include $(dpkg_datadir)/buildapi.mk
 
 dpkg_lazy_eval ?= $(eval $(1) = $(2)$$($(1)))
-- 
2.39.2

Bug#1070690: libupnp-dev: pkgconfig file no longer carries version information

[Geoffroy Youri Berret]

Package: libupnp-dev
Version: pkgconfig contains no version
Severity: normal
Tags: upstream

Dear Maintainer,

Building against libupnp 1.14.19 fails due to missing version in pkgconfig.

It appears to be already known upstream:
https://github.com/pupnp/pupnp/issues/442

Cheers
k

-- 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)
Kernel taint flags: TAINT_CRAP
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1070689: transition: msgpack-c

[James McCoy]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: msgpac...@packages.debian.org
Control: affects -1 + src:msgpack-c
User: release.debian@packages.debian.org
Usertags: transition

The msgpack-c upstream renamed their C library from libmsgpackc.so to
libmsgpack-c.so. I've renamed the binary packages accordingly
(libmsgpack-dev -> libmsgpack-c-dev, libmsgpackc2 -> libmsgpack-c2) and
the former "Provides: libmsgpack-dev" to help ease the transition.

The following build dependencies will need fixes to build against the
new msgpack-c version:

* libdata-messagepack-stream-perl
* tmate
* tmate-ssh-server
* webdis

This is just related to how the packages detect whether msgpack is
available, since the APIs/ABIs themselves did not change.

Ben file:

title = "msgpack-c";
is_affected = .depends ~ "libmsgpackc2" | .depends ~ "libmsgpack-c2";
is_good = .depends ~ "libmsgpack-c2";
is_bad = .depends ~ "libmsgpackc2";

Bug#1029657: marked as pending in python-os-ken

[Santiago Vila]

El 7/5/24 a las 11:46, Thomas Goirand escribió:


Bug #1029657 in python-os-ken reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/openstack-team/libs/python-os-ken/-/commit/85bf7c8c7eaf6b1de069ec4f6fabb1d882336154


* Blacklist Test_Manager.test_help() that underterministicaly fails
 (Closes: #1029657).



Hello.

I wonder if you finally were able to reproduce this.

Currently, I can only reproduce this in bookworm, so if you decided to disable
the flaky test, it would help a lot if you could also make an upload for 
bookworm as well.

(I still offer ssh access to a machine where this happens if you need it).

Thanks.

Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Peter Pentchev]

On Tue, May 07, 2024 at 10:38:14AM +0200, Carsten Leonhardt wrote:
> Luca Boccassi  writes:
> 
> > Defaults are defaults, they are trivially and fully overridable where
> > needed if needed. Especially container and VM managers these days can
> > super trivially override them via SMBIOS Type11 strings or
> > Credentials, ephemerally and without changing the guest image at all.
> 
> That argument goes both ways and I prefer safe defaults. What
> you/upstream propose are unsafe defaults, as was shown by several
> comments in this thread. Whoever wants the unsafe defaults of deleting
> old files and risking OOM situations can than "trivially and fully
> override" the safe defaults.

So I've been wondering for a couple of days now, following this thread...
...would it be a good idea to make this a debconf prompt, high priority,
default "yes", so that it is activated on new automatically installed
systems, but people who upgrade their current Debian installations can
choose to keep the old behavior?

I do realize that more debconf prompts are not always desirable, and
such decisions must be taken on a case-by-case basis, so... yeah.

G'luck,
Peter

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


signature.asc
Description: PGP signature