Bug#1061288: libnss-docker: Does not work OOTB with Docker Engine 25 anymore

[Moritz Schlarb]

Package: libnss-docker
Version: 0.02-1.1
Severity: normal

Docker Engine v25 (not yet natively packaged as docker.io, I know - but docker-
ce from their repo has it) deprecates legacy API versions:
https://docs.docker.com/engine/deprecated/#deprecate-legacy-api-versions

This affects libnss-docker, because it has API version 1.21 (set at configure
time).

A workaround until Docker Engine v26 would be to set
DOCKER_MIN_API_VERSION=1.21 for the Docker Daemon, but after that, a minimum of
1.24 is required.


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

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

Versions of packages libnss-docker depends on:
ii  libc6  2.37-13

libnss-docker recommends no packages.

Versions of packages libnss-docker suggests:
pn  docker.io  

-- no debconf information

Bug#1028273: [debian-mysql] Bug#996706: mariadb-server-10.5: run directory is not created in multi-instance mode

[Otto Kekäläinen]

Hi Peter and Toby!

The issues about systemd are potentially fixed in
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/29

Please test it (you can download the .deb packages from the pipeline
build artifacts
(https://salsa.debian.org/otto/mariadb-server/-/pipelines/628913) and
let me know how it went. If I get validation that it works now, I will
upload this to Debian and make the bugs you reported as fixed.

Thanks!

Bug#1061110: xorg-server: Regression from fixes for CVE-2024-21886

[Salvatore Bonaccorso]

Hi,

On Thu, Jan 18, 2024 at 02:30:08PM +0100, Salvatore Bonaccorso wrote:
> Source: xorg-server
> Version: 2:21.1.11-1
> Severity: important
> Tags: upstream
> X-Debbugs-Cc: car...@debian.org, jcris...@debian.org, a...@debian.org, 
> t...@security.debian.org
> 
> While preparing the update for xorg-server for bookworm an autopkgtest
> regression in uqm was seen. The same is shown with the 2:21.1.11-1
> upload to unstable:
> 
> https://ci.debian.net/packages/u/uqm/testing/amd64/41866714/
> 
> Julien Cristau was able to reproduce the leak independly from uqm:
> 
> Xvfb :10 & sleep 2; DISPLAY=:10 xdpyinfo >/dev/null
> 
> resulting in
> 
> 1 XSELINUXs still allocated at reset
> SCREEN: 0 objects of 304 bytes = 0 total bytes 0 private allocs
> DEVICE: 0 objects of 88 bytes = 0 total bytes 0 private allocs
> CLIENT: 0 objects of 144 bytes = 0 total bytes 0 private allocs
> WINDOW: 0 objects of 48 bytes = 0 total bytes 0 private allocs
> PIXMAP: 0 objects of 16 bytes = 0 total bytes 0 private allocs
> GC: 0 objects of 16 bytes = 0 total bytes 0 private allocs
> CURSOR: 1 objects of 8 bytes = 8 total bytes 0 private allocs
> TOTAL: 1 objects, 8 bytes, 0 allocs
> 1 CURSORs still allocated at reset
> CURSOR: 1 objects of 8 bytes = 8 total bytes 0 private allocs
> TOTAL: 1 objects, 8 bytes, 0 allocs
> 1 CURSOR_BITSs still allocated at reset
> TOTAL: 0 objects, 0 bytes, 0 allocs
> 
> As per upstream commit bisection it seems that the first bad commit is
> https://gitlab.freedesktop.org/xorg/xserver/-/commit/26769aa71fcbe0a8403b7fb13b7c9010cc07c3a8
> which is related for the CVE-2024-21886 fix.

There is a fix for that upstream (the issue did not affect the master
branch which contains the following commit, which is not in the
21.1.y):

https://gitlab.freedesktop.org/xorg/xserver/-/issues/1623#note_2248117
https://gitlab.freedesktop.org/xorg/xserver/-/commit/1801fe0ac3926882d47d7e1ad6c0518a2cdffd41

Proposed merge request for unstable:

https://salsa.debian.org/xorg-team/xserver/xorg-server/-/merge_requests/9

Regards,
Salvatore

Bug#1061287: libllvmspirvlib-15-dev is needed even with rusticl disabled

[Johannes Schauer Marin Rodrigues]

Source: mesa
Version: 24.0.0~rc2-1.1
Severity: normal

Hi,

I'm trying to build mesa 24 from experimental on bookworm. Since rusticl
requires rust-bindgen 0.66 and since building that and the surrounding
rust packages on bookworm is infeasible, I decided to disable rusticl by
excluding my host architecture from RUSTICL_ARCHS in debian/rules.
Unfortunately it seems, that libllvmspirvlib-15-dev which is pulled in
only when rusticl is enabled, is also necessary without rusticl:

Determining dependency 'LLVMSPIRVLib' with pkg-config executable 
'/usr/bin/pkg-config'
env[PKG_CONFIG_PATH]:█
env[PKG_CONFIG]: /usr/bin/pkg-config
---
Called: `/usr/bin/pkg-config --modversion LLVMSPIRVLib` -> 1
stderr:
Package LLVMSPIRVLib was not found in the pkg-config search path.
Perhaps you should add the directory containing `LLVMSPIRVLib.pc'
to the PKG_CONFIG_PATH environment variable
Package 'LLVMSPIRVLib', required by 'virtual:world', not found
---
CMake binary for host machine is cached as not found
Dependency lookup for LLVMSPIRVLib with method 'cmake' failed: CMake binary 
for machine host machine not found.Giving up.
Run-time dependency llvmspirvlib found: NO (tried pkgconfig)

../meson.build:1844:21: ERROR: Dependency "LLVMSPIRVLib" not found, tried 
pkgconfig


Reading meson.build, with_opencl_spirv seems to be set when opencl is not
disabled and thus does not only depend on rusticl. Could you change
debian/control.in such that the dependency on libllvmspirvlib-15-dev is not
only emitted when rusticl is enabled but also otherwise?

Let me also quickly send you two missing minimum version restrictions I found:

../meson.build:831:4: ERROR: Problem encountered: rusticl requires meson 
1.3.1 or newer

and:

Message: libdrm 2.4.119 needed because amdgpu has the highest requirement
Dependency libdrm_amdgpu found: NO found 2.4.114 but need: '>=2.4.119'
Run-time dependency libdrm_amdgpu found: NO█

../meson.build:1674:6: ERROR: Dependency lookup for libdrm_amdgpu with 
method 'pkgconfig' failed: Invalid version, need 'libdrm_amdgpu' 
['>=2.4.119'] found '2.4.114'.

Thanks!

cheers, josch

Bug#967554: keybinder: depends on deprecated GTK 2

[Esa Peuha]

It seems that all reverse (build-)dependencies have switched to the
GTK3 alternative keybinder-3.0 so this one should be removed.

Bug#1061286: wapiti: please remove old stale dependency on python3-six

[Alexandre Detiste]

Source: wapiti
Severity: normal

Dear Maintainer,

python3-six was a Python2+3 translation layer.

It should be removed some day.

Please remove the extraneous declaration in d/control.

Please alsu contact upstream to have
setup.py & requires.txt cleansed too.

Greetings,

Alexandre



$ grep six -r
wapiti3.egg-info/requires.txt:six>=1.15.0
setup.py:"six>=1.15.0",
debian/control:   python3-six,


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

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

Bug#1061285: time-decode: please remove extraneous dependency on python3-six

[Alexandre Detiste]

Source: time-decode
Severity: normal


Hi,

python3-six was a Python2+3 translation layer.

It should be removed some day.

Please remove the extraneous declaration in d/control:


$ grep six -r
debian/control: python3-six,
$


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

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

Bug#1061284: bdfproxy: please remove the extraneous dependency on python3-six

[Alexandre Detiste]

Source: bdfproxy
Version: 0.3.9-3
Severity: normal

Hi,

python3-six was a Python2+3 translation layer.

It should be removed some day.

Please remove the extraneous declaration in d/control:


$ grep six -r
debian/control: python3-six,
$

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

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

Bug#1061283: plaso: please remove extraneous dependency on python3-six

[Alexandre Detiste]

Source: plaso
Version: 20201007-2
Severity: normal


alike python3-future, python3-six is/was another Python2+3 translation layer.

please remove the 2 extraneous dependencies declared in debian/control;
it is not used anymore by the package.

Greetings

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

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

Bug#1061282: libgtk-3-0: gtk crashes when I use a script to turn off the screen

[jeremyp3]

Package: libgtk-3-0
Version: 3.24.40-1
Severity: normal

Dear Maintainer,

i'm a blind user and to save battery life on my laptop, i use a script to turn
off the screen. since switching to this version of libgtk-3-0 when i use the
script (provided below), my desktop (mate) crashes and i return to the login
screen.

downgrade to version 3.24.39-2 solves the problem and I can use the script
without any problem.

in the syslog, I have lots of gtk application crashes one after the other

the script is available here on the debian accessibility wiki:
https://wiki.debian.org/accessibility
sexion screen off and sub seccion x11


log is attached


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

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

Versions of packages libgtk-3-0 depends on:
ii  adwaita-icon-theme   45.0-2
ii  hicolor-icon-theme   0.17-2
ii  libatk-bridge2.0-0   2.50.0-1+b1
ii  libatk1.0-0  2.50.0-1+b1
ii  libc62.37-13
ii  libcairo-gobject21.18.0-1+b1
ii  libcairo21.18.0-1+b1
ii  libcloudproviders0   0.3.5-1
ii  libcolord2   1.4.6-5
ii  libcups2 2.4.7-1+b1
ii  libepoxy01.5.10-1+b2
ii  libfontconfig1   2.14.2-6+b1
ii  libfribidi0  1.0.13-3+b1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3
ii  libglib2.0-0 2.78.3-1
ii  libgtk-3-common  3.24.40-1
ii  libharfbuzz0b8.0.1-1+b2
ii  libpango-1.0-0   1.51.0+ds-4
ii  libpangocairo-1.0-0  1.51.0+ds-4
ii  libpangoft2-1.0-01.51.0+ds-4
ii  libwayland-client0   1.22.0-2.1
ii  libwayland-cursor0   1.22.0-2.1
ii  libwayland-egl1  1.22.0-2.1
ii  libx11-6 2:1.8.7-1
ii  libxcomposite1   1:0.4.5-1
ii  libxcursor1  1:1.2.1-1
ii  libxdamage1  1:1.1.6-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxi6   2:1.8-1+b1
ii  libxinerama1 2:1.1.4-3
ii  libxkbcommon01.6.0-1
ii  libxrandr2   2:1.5.2-2+b1
ii  shared-mime-info 2.4-1

Versions of packages libgtk-3-0 recommends:
pn  libgtk-3-bin 
ii  librsvg2-common  2.54.7+dfsg-2

Versions of packages libgtk-3-0 suggests:
ii  gvfs  1.52.2-1

Versions of packages libgtk-3-0 is related to:
pn  appmenu-gtk3-module   
pn  fcitx-frontend-gtk3   
pn  gcin-gtk3-immodule
pn  gtk-vector-screenshot 
pn  gtk3-engines-xfce 
pn  gtk3-im-libthai   
pn  hime-gtk3-immodule
pn  ibus-gtk3 
pn  imhangul-gtk3 
pn  libcanberra-gtk3-module   
pn  libcaribou-gtk3-module
pn  libgtk3-nocsd0
pn  maliit-inputcontext-gtk3  
pn  packagekit-gtk3-module
pn  scim-gtk-immodule 
pn  topmenu-gtk3  
pn  uim-gtk3  
pn  uim-gtk3-immodule 

-- no debconf information
Jan 22 05:28:44 jerem-debian kernel: notification-ar[2719]: segfault at 
55c83ce50ecd ip 7f674934b4fc sp 7ffc402ad3f0 error 4 in 
libglib-2.0.so.0.7800.3[7f67492ee000+99000] likely on CPU 3 (core 3, socket 0)
Jan 22 05:28:44 jerem-debian kernel: Code: 89 fd 53 48 89 f3 48 83 ec 08 4c 8b 
2d 7d 8a 0c 00 eb 10 0f 1f 00 48 89 ee e8 20 5e fe ff 48 85 db 74 29 41 8b 45 
00 48 89 df <4a> 8b 1c 23 85 c0 74 e4 31 f6 48 89 ea e8 c2 2b fa ff 48 89 ee 48
Jan 22 05:28:44 jerem-debian kernel: mate-volume-con[2638]: segfault at 
55def44d1049 ip 7fa8d5b484fc sp 7fffc2ff7a00 error 4 in 
libglib-2.0.so.0.7800.3[7fa8d5aeb000+99000] likely on CPU 2 (core 2, socket 0)
Jan 22 05:28:44 jerem-debian kernel: Code: 89 fd 53 48 89 f3 48 83 ec 08 4c 8b 
2d 7d 8a 0c 00 eb 10 0f 1f 00 48 89 ee e8 20 5e fe ff 48 85 db 74 29 41 8b 45 
00 48 89 df <4a> 8b 1c 23 85 c0 74 e4 31 f6 48 89 ea e8 c2 2b fa ff 48 89 ee 48
Jan 22 05:28:44 jerem-debian kernel: wnck-applet[2618]: segfault at 
55d4b18679eb ip 7fb7146a24fc sp 7ffe139f7f50 error 4 in 
libglib-2.0.so.0.7800.3[7fb714645000+99000] likely on CPU 1 (core 1, socket 0)
Jan 22 05:28:44 jerem-debian kernel: Code: 89 fd 53 48 89 f3 48 83 ec 08 4c 8b 
2d 7d 8a 0c 00 eb 10 0f 1f 00 48 89 ee e8 20 5e fe ff 48 85 db 74 29 41 8b 45 
00 48 89 df <4a> 8b 1c 23 85 c0 74 e4 31 f6 48 89 ea e8 c2 2b fa ff 48 89 ee 48
Jan 22 05:28:44 jerem-debian kernel: mate-panel[2592]: segfault at 556aa231aafb 
ip 7fea4900a4fc sp 7fffdf6aa610 error 4 in 
libglib-2.0.so.0.7800.3[7fea48fad000+99000] likely on CPU 7 (core 3, socket 0)
Jan 22 05:28:44 jerem-debian kernel: Code: 89 fd 53 48 89 f3 48 83 ec 08 4c 8b 
2d 7d 8a 0c 00 eb 10 0f 1f 00 48 89 ee e8 20 5e fe ff 48 85 db 74 29 41 8b 45 
00 48 89 df <4a> 8b 1c 23 85 c0 74 e4 31 f6 48 

Bug#1040499: Seems to be caused by -fstack-protector-strong

[Jason Lynch]

I too am seeing this issue on a freshly installed unstable system. I was 
initially unable to reproduce the issue on a copy of mailutils compiled 
manually (without the Debian scripts). After some comparison of the two 
builds, I was able to finally reproduce by adding the 
-fstack-protector-strong flag to CFLAGS.


It seems the getaddrinfo call on line 86 of libmailutils/base/hostname.c 
is somehow broken by this flag, though this is far outside my wheelhouse 
and I do not really understand what the flag does in detail or how it 
would possibly affect things.

Bug#1061281: gajim: Fails to start: AttributeError: module 'eventlet.green.select' has no attribute 'epoll'

[Shawn K. Quinn]

Package: gajim
Version: 1.8.4-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: skqu...@rushpost.com

Dear Maintainer,

At some point within the last few days, I am suddenly unable to launch gajim.
This is the console output I am receiving:

skquinn@crossbow:~$ gajim
Traceback (most recent call last):
  File "/usr/bin/gajim", line 8, in 
sys.exit(run())
 ^
  File "/usr/lib/python3/dist-packages/gajim/main.py", line 171, in run
_init_gui('GTK')
  File "/usr/lib/python3/dist-packages/gajim/main.py", line 105, in _init_gui
_init_gtk()
  File "/usr/lib/python3/dist-packages/gajim/main.py", line 123, in _init_gtk
from gajim.gtk import exception
  File "/usr/lib/python3/dist-packages/gajim/gtk/exception.py", line 54, in

import sentry_sdk
  File "/usr/lib/python3/dist-packages/sentry_sdk/__init__.py", line 1, in

from sentry_sdk.hub import Hub, init
  File "/usr/lib/python3/dist-packages/sentry_sdk/hub.py", line 8, in 
from sentry_sdk.scope import Scope
  File "/usr/lib/python3/dist-packages/sentry_sdk/scope.py", line 7, in

from sentry_sdk.attachments import Attachment
  File "/usr/lib/python3/dist-packages/sentry_sdk/attachments.py", line 5, in

from sentry_sdk.envelope import Item, PayloadRef
  File "/usr/lib/python3/dist-packages/sentry_sdk/envelope.py", line 7, in

from sentry_sdk.session import Session
  File "/usr/lib/python3/dist-packages/sentry_sdk/session.py", line 5, in

from sentry_sdk.utils import format_timestamp
  File "/usr/lib/python3/dist-packages/sentry_sdk/utils.py", line 1305, in

HAS_REAL_CONTEXTVARS, ContextVar = _get_contextvars()
   ^^
  File "/usr/lib/python3/dist-packages/sentry_sdk/utils.py", line 1275, in
_get_contextvars
if not _is_contextvars_broken():
   
  File "/usr/lib/python3/dist-packages/sentry_sdk/utils.py", line 1228, in
_is_contextvars_broken
from eventlet.patcher import is_monkey_patched  # type: ignore
^^
  File "/usr/lib/python3/dist-packages/eventlet/__init__.py", line 17, in

from eventlet import convenience
  File "/usr/lib/python3/dist-packages/eventlet/convenience.py", line 7, in

from eventlet.green import socket
  File "/usr/lib/python3/dist-packages/eventlet/green/socket.py", line 21, in

from eventlet.support import greendns
  File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 79,
in 
setattr(dns, pkg, import_patched('dns.' + pkg))
  
  File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 61,
in import_patched
return patcher.import_patched(module_name, **modules)
   ^^
  File "/usr/lib/python3/dist-packages/eventlet/patcher.py", line 132, in
import_patched
return inject(
   ^^^
  File "/usr/lib/python3/dist-packages/eventlet/patcher.py", line 109, in
inject
module = __import__(module_name, {}, {}, module_name.split('.')[:-1])
 
  File "/usr/lib/python3/dist-packages/dns/asyncquery.py", line 38, in 
from dns.query import (
  File "/usr/lib/python3/dist-packages/dns/query.py", line 63, in 
import httpcore
  File "/usr/lib/python3/dist-packages/httpcore/__init__.py", line 1, in

from ._api import request, stream
  File "/usr/lib/python3/dist-packages/httpcore/_api.py", line 5, in 
from ._sync.connection_pool import ConnectionPool
  File "/usr/lib/python3/dist-packages/httpcore/_sync/__init__.py", line 1, in

from .connection import HTTPConnection
  File "/usr/lib/python3/dist-packages/httpcore/_sync/connection.py", line 12,
in 
from .._synchronization import Lock
  File "/usr/lib/python3/dist-packages/httpcore/_synchronization.py", line 11,
in 
import trio
  File "/usr/lib/python3/dist-packages/trio/__init__.py", line 22, in 
from ._core import TASK_STATUS_IGNORED as TASK_STATUS_IGNORED  # isort:
split
^
  File "/usr/lib/python3/dist-packages/trio/_core/__init__.py", line 21, in

from ._local import RunVar, RunVarToken
  File "/usr/lib/python3/dist-packages/trio/_core/_local.py", line 9, in

from . import _run
  File "/usr/lib/python3/dist-packages/trio/_core/_run.py", line 2775, in

from ._io_epoll import (
  File "/usr/lib/python3/dist-packages/trio/_core/_io_epoll.py", line 202, in

class EpollIOManager:
  File "/usr/lib/python3/dist-packages/trio/_core/_io_epoll.py", line 203, in
EpollIOManager
_epoll: select.epoll = attr.ib(factory=select.epoll)
   
AttributeError: module 'eventlet.green.select' has no attribute 'epoll'

---

I have tried rolling back gajim itself but that did not help. I unfortunately
lack the detailed 

Bug#1061277: abinit: FTBFS with Python 3.12

[Steve Langasek]

Package: abinit
Followup-For: Bug #1061277
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch

Dear maintainers,

Please find attached a patch that fixes the build failure with python 3.12.

This change has been uploaded to Ubuntu for the python 3.12 transition.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru abinit-9.10.4/debian/patches/python3.12.patch 
abinit-9.10.4/debian/patches/python3.12.patch
--- abinit-9.10.4/debian/patches/python3.12.patch   1969-12-31 
16:00:00.0 -0800
+++ abinit-9.10.4/debian/patches/python3.12.patch   2024-01-21 
14:12:54.0 -0800
@@ -0,0 +1,65 @@
+Description: Compatibility with python 3.12
+ SafeConfigParser and the imp module are obsoleted in python3.
+Author: Steve Langasek 
+Last-Update: 2024-01-21
+Forwarded: no
+
+Index: abinit-9.10.4/tests/pymods/jobrunner.py
+===
+--- abinit-9.10.4.orig/tests/pymods/jobrunner.py
 abinit-9.10.4/tests/pymods/jobrunner.py
+@@ -11,7 +11,7 @@
+ from ConfigParser import SafeConfigParser, NoOptionError
+ except ImportError:
+ # The ConfigParser module has been renamed to configparser in Python 3
+-from configparser import SafeConfigParser, NoOptionError
++from configparser import ConfigParser as SafeConfigParser, NoOptionError
+ 
+ import logging
+ logger = logging.getLogger(__name__)
+Index: abinit-9.10.4/fkiss/project.py
+===
+--- abinit-9.10.4.orig/fkiss/project.py
 abinit-9.10.4/fkiss/project.py
+@@ -422,7 +422,7 @@
+ def filter_fortran(files):
+ return [f for f in files if f.endswith(".f") or 
f.endswith(".F90")]
+ 
+-import imp
++from importlib.machinery import SourceFileLoader
+ name2path = OrderedDict()
+ for d in self.dirpaths:
+ if os.path.basename(d) == "98_main":
+@@ -434,7 +434,7 @@
+ else:
+ # Get source files from abinit.src.
+ abinit_src = os.path.join(d, "abinit.src")
+-mod = imp.load_source(abinit_src, abinit_src)
++mod = SourceFileLoader("abinit.src", abinit_src).load_module()
+ for basename in filter_fortran(mod.sources):
+ if basename in name2path:
+ raise RuntimeError("Found two Fortran files with same 
basename `%s` and other in dir `%s`\n"
+Index: abinit-9.10.4/tests/__init__.py
+===
+--- abinit-9.10.4.orig/tests/__init__.py
 abinit-9.10.4/tests/__init__.py
+@@ -7,7 +7,7 @@
+ 
+ import sys
+ import os
+-import imp
++import importlib
+ import platform
+ import re
+ 
+@@ -197,8 +197,8 @@
+ self.name = os.path.basename(suite_path)
+ 
+ module_name = os.path.join(suite_path, "__init__.py")
+-module = imp.load_source(
+-module_name, os.path.join(suite_path, "__init__.py"))
++module = importlib.machinery.SourceFileLoader(
++module_name, os.path.join(suite_path, 
"__init__.py")).load_module()
+ 
+ self.keywords = set(module.keywords)
+ self.need_cpp_vars = set(module.need_cpp_vars)
diff -Nru abinit-9.10.4/debian/patches/series 
abinit-9.10.4/debian/patches/series
--- abinit-9.10.4/debian/patches/series 2023-09-09 09:21:09.0 -0700
+++ abinit-9.10.4/debian/patches/series 2024-01-21 14:09:09.0 -0800
@@ -4,3 +4,4 @@
 testsuite_autopkgtest.patch
 tests-python3.patch
 build-system-python3.patch
+python3.12.patch

Bug#1056293: gettext: msgfmt --java2 does not support Java 21

[Vladimir Petko]

Dear Maintainers,


 Would it be possible to consider the attached patch to resolve this issue?

I have made the following changes:
 - cherry-picked upstream patch to resolve stack overflow
 - updated java compatibility patch to use source/target level 8,
added more Java versions and set default to 11 instead of 1.1 in the
.m4 script.

 Note, updating the package to 0.22.4 also solves this issue.

Best regards,
 Vladimir.


gettext_0.21-14ubuntu1.debdiff
Description: Binary data

Bug#1058592: LXD licensing changes and future for Debian packaging

[Mathias Gibbens]

  Earlier today I uploaded what I expect to be the last significant
packaging work for LXD that I will perform. The snapshot version of LXD
appears to work correctly in sid, and I only anticipate making small
tweaks if needed in advance of the trixie release next year.

  Referring to my email on 2023-12-13, steps 1-3 are now complete.
Incus is available in testing & sid, and has feature parity with the
version of LXD in Debian.

  Barring work by another motivated individual, the current plan is to
ship the snapshot version of LXD in trixie while encouraging people to
migrate to Incus sometime during trixie's lifetime. Once sid opens up
following the trixie release, if there haven't been any significant
changes, I plan to either modify src:lxd to only produce bin:golang-
github-canonical-lxd-dev if Incus still depends on it to build the
`lxd-to-incus` binary, or file a RM bug to totally remove LXD in forky.

Mathias


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

Bug#1061280: sysvinit crashes podman container on install

[Sam Hartman]

package: sysvinit-core:
version: 3.08-5
severity: important
justification: breaks unrelated software in uncommon environment

I was curious about a discussion on debian-devel, so I tried to install
sysvinit and wdm at the same time.
I tried:

podman run --rm -ti debian:unstable
apt update
apt install sysvinit-core

And my container crashed when sysvinit-core was installed and restarted.
To get things "installed" I copied /dev/null over the sysvinit-core
postinst.

I'd like to be able to create a podman or docker image running sysvinit.
To do that I need to be able to install sysvinit with a container that
has /bin/bash or /bin/sh as an entry point and then image that container
into an image that has init as the entry point.  For that to work
sysvinit-core has to be able to install even when there is no init
system.

--Sam

Bug#1061279: caja: Caja not showing up in LXQt

[john]

Package: caja
Version: 1.26.3-1
Severity: normal
X-Debbugs-Cc: johnny.faul...@yahoo.com

Dear Maintainer,

Caja does not show up in the LXQt menu, likely due to a misconfigured .desktop 
file. This makes it impossible to use it as the default file manager for LXQt. 
This bug is currently found in Debian Trixie. Its a simple bug to fix, it just 
needs someone to make the adjustment. Thank you for your time and 
consideration. 

-John

Bug#1061278: Type to search fails with console error

[John Bigboote]

Package: deluge
Version: 2.1.2~dev0+20231127-1

Using deluge-gtk in "Standalone" mode with the torrent pane active and typing 
any alphanumeric characters to search the list of torrents does not work 
(highlights the first torrent in the list only) and logs this error to console:

TypeError: ListView.on_keypress_search_by_name() takes 5 positional arguments 
but 6 were given

Found under Debian Trixie, kernel 4.9.0-8-amd64, Xfce 4.18, GTK 3.24.39, 
libtorrent 2.0.9.0

Bug#1054748: [Help] Re: mlpy ftbfs with Python 3.12

[Yogeswaran Umasankar]

Hi,
I created a patch for ModuleNotFoundError with Python 3.12. I worked on
it in a fork, and created MR [0]. I hope it fixes the issue with the
build.

[0] https://salsa.debian.org/science-team/mlpy/-/merge_requests/5

Cheers!
Yogeswaran.


signature.asc
Description: PGP signature

Bug#1061277: abinit: FTBFS with Python 3.12

[Aaron Rainbolt]

Source: abinit
Version: 9.10.4-2
Severity: serious
Tags: ftbfs upstream
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: arraybo...@ubuntu.com

When building the abinit package on a system with Python 3.12 installed,
the build fails with a "ModuleNotFoundError: No module named 'imp'" in
fkiss/project.py. This file is used by abisrc.py, which is used as a
critical part of the build configuration process, thus when this script
fails, it takes down the whole build.

This bug is being tracked upstream at
https://github.com/abinit/abinit/issues/69.

Steps to reproduce:

1. Configure your builder to enable `experimental` and pin
python3-defaults to be installed from it. I'm doing this with a script
as follows:

```
#!/bin/bash
echo "deb https://deb.debian.org/debian experimental main" >> 
/etc/apt/sources.list;
echo "deb-src https://deb.debian.org/debian experimental main" >> 
/etc/apt/sources.list;
echo "Package: src:python3-defaults" > /etc/apt/preferences.d/99proposed
echo "Pin: release a=experimental" >> /etc/apt/preferences.d/99proposed
echo "Pin-Priority: 950" >> /etc/apt/preferences.d/99proposed
```

This is then called in my .sbuildrc with the following config:

```
$external_commands = {
"chroot-setup-commands" => [
['/repo/enableProposed.sh'],
],
};
```

2. Attempt to build abinit from source with this builder. The build will
fail and display failure output similar to the output in the upstream
bug report. You should be able to find the abisrc.stderr file inside the
build directory within your builder (find it with `find | grep stderr`)
and see that it has output similar to the output shown in the first
comment of the upstream bug report.

(My system information has Ubuntu information on it because I am
reporting the bug from an Ubuntu system, however the FTBFS occurs within
a Debian Sid schroot being used via sbuild.)


-- System Information:
Debian Release: bookworm/sid
  APT prefers jammy-updates
  APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), 
(100, 'jammy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-14-generic (SMP w/8 CPU threads; PREEMPT)
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

Bug#1061276: alsa-lib: wrong license name in copyright file

[Masami Ichikawa]

Source: alsa-lib
Version: 1.2.8-1
Severity: minor

Dear Maintainer,

In License fields in the copyright file, it describes license as
LPGL-2.1+ but license text field said that "On Debian systems, the
complete text of the GNU Lesser General Public License can be found in
/usr/share/common-licenses/LGPL-2.1." so that it seems correct license
name would be LGPL-2.1+.

-- System Information:
Debian Release: 12.4
  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/2 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

Bug#1061275: saxonb: please package new upstream version

[Martin]

Source: saxonb
Version: 9.1.0.8+dfsg-2
Severity: wishlist

The last upstream version, 9.1.0.8, has been uploaded to Debian on
2013-09-19. It seems, there are now versions 10, 11, and 12 available.
Please consider uploading a new version, thank you!

Btw. the homepage is now https://www.saxonica.com/

Bug#1061153: ITP: sigsum-go -- tools for public and transparent logging of signed checksums

[Simon Josefsson]

> 21 jan. 2024 kl. 20:09 skrev Holger Levsen :
> 
> Hi Simon,
> 
>> On Fri, Jan 19, 2024 at 05:32:05PM +0100, Simon Josefsson wrote:
>> * URL : https://git.glasklar.is/sigsum/core/sigsum-go
>>  Description : tools for public and transparent logging of signed 
>> checksums
>> 
>> The goal of Sigsum is to provide building blocks that can be used to
>> enforce public logging of signed checksums.
> 
> do you think this would be a suitable tool to publically log all checksums of
> all Debian source and binary packages published?

Yes that would be nice. However I think we want multiple additional 
verification methods. The simplest augmentation would be to confirm that 
already existing signatures are recorded publicly via rekor. That doesn’t 
require any tooling or new private keys during signing, and help mitigate 
attackers ability to deny their actions. Cosign and sigsum are two next low 
hanging fruit but demand private key considerations. While publishers of 
packages (such as Trisquel or Debian) can be responsible for this, from the 
point of view of the consumer of packages, it would add more strength if a 
couple of external independent organizations vouch for the packages. I run one 
via the gitlab debdistutils project, but mirroring the ideas elsewhere would 
help. One key point is that any publishers packages’ aren’t trustworthy if they 
cannot be rebuilt from source and validated by a third party, and that third 
party should sign claims of what levels of verification were made, and users 
can pick a couple of entities to vouch for packages they install. Could the 
reproducible build project sign the packages you build and publish those 
signatures? I suggest using all three of GnuPG, sigsum-submit and cosign.

/Simin

> 
> 
> --
> cheers,
>Holger
> 
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
> ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
> ⠈⠳⣄
> 
> Life may not be the party we hoped for, but while we're here we might as well
> dance!

Bug#1059339: nv-codec-headers: Version mismatch with nvidia-driver package

[Simon McVittie]

On Fri, 05 Jan 2024 at 23:23:01 +0100, Sebastian Ramacher wrote:
> On 2023-12-22 20:59:22 +0100, Tim H. wrote:
> > [1] states that the minimum required nvidia driver version to support
> > nvenc 12.1 is 530.41.03 or higher. Yet the most recent version
> > available in trixie is currently 525.147.05-1.
> 
> Taking the nvidia driver from experimental would also work. Andreas,
> could you upload the driver from experimental to unstable?

The driver currently in experimental is a 535.x beta if I'm reading
correctly. I tried to provide an update to the 535.x production release
in #1061269, which might be more suitable for unstable.

(Sorry, I am not an Nvidia driver maintainer, so I don't intend to upload
this myself - I was only building it in the hope that it might resolve
or work around a specific game bug!)

smcv

Bug#1060997: khard: FTBFS: make[2]: *** [Makefile:20: html] Error 2

[s3v]

Dear Maintainer,

After sphinx-autoapi/3.0.0-0.1 entered in unstable [1], I'm able to
build successfully your package in a sid chroot environment.
I can reproduce the failure reported in this bug after building
against sphinx-autoapi/2.0.0-2 from snapshot.d.o [2].

Kind Regards

[1] 
https://tracker.debian.org/news/1496099/accepted-sphinx-autoapi-300-01-source-into-unstable
[2] https://snapshot.debian.org/package/sphinx-autoapi/2.0.0-2/

Bug#1061250: gjs FTCBFS: cxx.run always fails cross compilation

[Helmut Grohne]

Hi Simon,

On Sun, Jan 21, 2024 at 03:50:17PM +, Simon McVittie wrote:
> On Sun, 21 Jan 2024 at 12:56:49 +0100, Helmut Grohne wrote:
> > +if meson.is_cross_build()
> 
> In my experience, this function call is usually the wrong tool:
> I think it would likely be more in line with what upstream wants if
> it was based on "if not meson.can_run_host_binaries()", so that if we
> happen to be able to run host binaries (via i386-on-amd64, binfmt_misc
> or an explicitly configured EXE wrapper), the check will still be done.

Thank you for pointing at meson.can_run_host_binaries(). I concur that
this is what we want here. I shall remember this for future patches.

I concur that is_cross_build rarely is what we want and in numerous
places, I have proposed discarding such checks. In this case, the check
was already there and I have merely shifted it around subtly changing
the semantics such that it won't attempt to do the sanity check during
cross compilation.

> Does cxx.run() work as though we were doing a native build if Meson is
> run with a cross-file that configures an EXE wrapper, similar to
> ?
> I hope that it will.

That would also be my expectation.

> gjs is neither installable nor useful without GObject-Introspection, so
> on any architecture where we would consider cross-compiling gjs, we almost
> certainly already have qemu-user available.

Whils this is true in principle, the way you have integrated qemu into
gir, this fact is not exposed to the build system. Just because
g-ir-scanner uses qemu, does not imply that a crossfile has set this up
(while it still probably would be useful to set this up).

> > +warning('''This is a cross build. A check that a minimal
> > +SpiderMonkey program executes will not be performed. Before shipping GJS, 
> > you
> > +should check that it does not crash on startup, since building 
> > SpiderMonkey with
> > +the wrong configuration may cause that.''' + recommended_configuration)
> 
> This might still be a good idea even if an EXE wrapper is enough to
> resolve the build failure, but I'd prefer to take this sort of thing
> upstream rather than applying it unilaterally.

Yes, the bug is tagged upstream and resolving it upstream is what I
preferred - even if it takes longer that way.

Do you think this needs further improvement beyond replacing
is_cross_build with can_run_host_binaries?

Helmut

Bug#1061249: clutter-gtk FTCBFS: fails running gtk-doc scanner

[Helmut Grohne]

Hi Simon,

On Sun, Jan 21, 2024 at 03:29:54PM +, Simon McVittie wrote:
> On Sat, 20 Jan 2024 at 22:49:18 +0100, Helmut Grohne wrote:
> > clutter-gtk fails to cross build from source, because it fails running
> > the gtk-doc scanner, which is a host architecture executable.
> 
> The changes look fine in principle, but clutter-gtk is dead upstream and
> should ideally not be released in trixie at all, so this is unlikely to be
> a particularly high priority for anyone to (test and) upload.

This turned up on my radar as I use popcon as a measure of interest and
clutter-gtk still has a popcon rank of about 1500. I recognize that
popcon favours deprecated packages. If you can suggest a metter sorting
metric for ordering packages, I'm all ears. Other than that, I'm happy
to have this closed with removing the package from unstable soon.
Otherwise, I hope the next upload can include this change.

Helmut

Bug#1061248: glibc: DEP17: move most files but rtld to /usr

[Helmut Grohne]

Control: tags -1 - patch + moreinfo

On Sun, Jan 21, 2024 at 06:37:35PM +0100, Sven Joachim wrote:
> I have not studied the details, but this looks rather dangerous to me.
> If you install the runtime dynamic linker in multilib packages below
> /usr, but keep the native one at its current place, you risk losing it
> when the multilib packages are removed.

Thank you for reviewing my patch.

> For instance, I have both libc6:i386 and libc6-i386:amd64 installed.  If
> the latter starts shipping /usr/lib/ld-linux.so.2 rather than
> /lib/ld-linux.so.2, the "Replaces" in libc6:i386 becomes ineffective,
> and we have basically a case of Dep17 P1.

I shall rework the patch and also exempt multilib rtlds from moving. I'm
sorry for not having realized this. I suspect that dumat would have
reported this problem.

Helmut

Bug#1061248: glibc: DEP17: move most files but rtld to /usr

[Helmut Grohne]

On Sun, Jan 21, 2024 at 07:39:04PM +0100, Helmut Grohne wrote:
> I shall rework the patch and also exempt multilib rtlds from moving. I'm
> sorry for not having realized this. I suspect that dumat would have
> reported this problem.

This seems pretty much unfxiable to me now.

Essentially, keeping all (including multilib) rtlds aliased works badly
with the matching in debian/debhelper.in/libc-alt.install. Trying to
refine those patterns in a way that retains the rtlds aliased while
moving everything else is quite difficult, because sometimes SLIBDIR and
RTLDDIR overlap. Even if managing this, it breaks my simplistic approach
to fixing symlinks.

When base-files gains the aliasing links, we can move both files from
SLIBDIR and RTLDDIR restoring this simplicity. The value we gain from
moving files in SLIBDIR now already seems to diminish given the
complexity it would incur.

If we disregard SLIBDIR moves, not much is left in my patch. Essentially
all we can move is ldconfig and moving that now or later doesn't pose a
significant difference.

So it seems, that the proposed change is not very useful in the end.
I've learned a few things about how to do the coordinated NMU move and
that's about it, it seems. Sorry for the noise.

Is it ok, to repurpose and leave open this bug open for the later upload
moving all of the files or do you prefer a new bug then?

Helmut

Bug#1061274: coreutils: DEP17: move files to /usr

[Helmut Grohne]

Source: coreutils
Version: 9.4-3
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

Hi,

we want to finalize the /usr-merge transition via DEP17 by moving all
files to /usr and having base-files install the aliasing symlinks.
coreutils is naturally involved as it installs files to /bin. While we
no longer officially support unmerged filesystem hierarchies since
trixie, coreutils is essential and we require more of it. Being
essential means we still support bootstrapping unmerged and merging via
usrmerge.postinst, which required presence of /bin/cp until version 38.
The updated version 39 also works with /usr/bin/cp and hence, we may now
move forward.

I've prepared a patch for performing the conversion in a way that
simplifies the packaging. This patch must not be backported to
bookworm-backports as the moratorium still applies there, but I think
backports of coreutils are fairly unlikely. The patch also allows us to
get rid of the remaining maintainer scripts.

I've performed tests with debootstrap, cdebootstrap and mmdebstrap and
all of them are able to construct chroots with this coreutils patch
applied.

Helmut
diff --minimal -Nru coreutils-9.4/debian/changelog 
coreutils-9.4/debian/changelog
--- coreutils-9.4/debian/changelog  2024-01-02 14:54:03.0 +0100
+++ coreutils-9.4/debian/changelog  2024-01-21 22:33:08.0 +0100
@@ -1,3 +1,10 @@
+coreutils (9.4-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * DEP17: Move files to /usr. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 21 Jan 2024 22:33:08 +0100
+
 coreutils (9.4-3) unstable; urgency=low
 
   * remove arch restriction from libssl-dev build-depend
diff --minimal -Nru coreutils-9.4/debian/control coreutils-9.4/debian/control
--- coreutils-9.4/debian/control2024-01-02 14:22:27.0 +0100
+++ coreutils-9.4/debian/control2024-01-21 22:33:08.0 +0100
@@ -11,6 +11,7 @@
 Pre-Depends: ${shlibs:Depends}, ${misc:Pre-Depends}
 Essential: yes
 Depends: ${misc:Depends}
+Breaks: usrmerge (<< 39)
 Description: GNU core utilities
  This package contains the basic file, shell and text manipulation
  utilities which are expected to exist on every operating system.
diff --minimal -Nru coreutils-9.4/debian/coreutils.postinst 
coreutils-9.4/debian/coreutils.postinst
--- coreutils-9.4/debian/coreutils.postinst 2022-09-20 17:04:38.0 
+0200
+++ coreutils-9.4/debian/coreutils.postinst 1970-01-01 01:00:00.0 
+0100
@@ -1,8 +0,0 @@
-#!/bin/sh
-set -e
-
-if [ "$1" = 'configure' -a ! -e "$DPKG_ROOT/usr/bin/touch" ]; then
-  ln -s /bin/touch "$DPKG_ROOT/usr/bin/touch"
-fi
-
-#DEBHELPER#
diff --minimal -Nru coreutils-9.4/debian/coreutils.postrm 
coreutils-9.4/debian/coreutils.postrm
--- coreutils-9.4/debian/coreutils.postrm   2022-09-20 17:04:49.0 
+0200
+++ coreutils-9.4/debian/coreutils.postrm   1970-01-01 01:00:00.0 
+0100
@@ -1,8 +0,0 @@
-#!/bin/sh
-set -e
-
-if [ "$1" = 'remove' -a -L "$DPKG_ROOT/usr/bin/touch" ]; then
-  rm "$DPKG_ROOT/usr/bin/touch"
-fi
-
-#DEBHELPER#
diff --minimal -Nru coreutils-9.4/debian/rules coreutils-9.4/debian/rules
--- coreutils-9.4/debian/rules  2023-11-10 14:31:21.0 +0100
+++ coreutils-9.4/debian/rules  2024-01-21 21:41:59.0 +0100
@@ -36,11 +36,6 @@
 override_dh_install-arch: 
dh_install -a
 
-   # some things go in root rather than usr
-   for f in $(BIN_PROGS); do \
-   mv $(d)/usr/bin/$$f $(d)/bin/$$f; \
-   done
-   
# backward compatability
ln -s /usr/bin/md5sum $(d)/usr/bin/md5sum.textutils
ln -s /usr/share/man/man1/md5sum.1 
$(d)/usr/share/man/man1/md5sum.textutils.1
@@ -49,8 +44,6 @@
 ifeq ($(DEB_HOST_ARCH_OS),linux)
# kill from procps is linux-specific
rm -f $(d)/usr/bin/kill $(d)/usr/share/man/man1/kill.1
-else
-   mv $(d)/usr/bin/kill $(d)/bin
 endif
rm -f $(d)/usr/bin/hostname $(d)/usr/share/man/man1/hostname.1
rm -f $(d)/usr/bin/uptime $(d)/usr/share/man/man1/uptime.1

Bug#1061273: clutter-gst-3.0 FTCBFS: fails gtk-doc-scan

[Helmut Grohne]

Source: clutter-gst-3.0
Version: 3.0.27-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

clutter-gst-3.0 fails to cross build from source, because it fails
running the gtk-doc scanner. It has its documentation nicely split to a
-doc package, so we can simply skip the documentation build in an
arch-only build and thus fix cross compilation. I'm attaching a patch
for this.

I recognize that clutter-gst-3.0 is not developed anymore and may be
removed like clutter-gtk before too long. If the solution is to remove
the package, then so be it. If there is another upload, consider
including this patch.

Helmut
diff --minimal -Nru clutter-gst-3.0-3.0.27/debian/changelog 
clutter-gst-3.0-3.0.27/debian/changelog
--- clutter-gst-3.0-3.0.27/debian/changelog 2022-05-12 22:30:52.0 
+0200
+++ clutter-gst-3.0-3.0.27/debian/changelog 2024-01-21 23:08:30.0 
+0100
@@ -1,3 +1,10 @@
+clutter-gst-3.0 (3.0.27-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Skip gtk-doc on arch-only builds. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 21 Jan 2024 23:08:30 +0100
+
 clutter-gst-3.0 (3.0.27-3) unstable; urgency=medium
 
   * Add patch from Arch Linux to fix corrupted display with Cheese
diff --minimal -Nru clutter-gst-3.0-3.0.27/debian/rules 
clutter-gst-3.0-3.0.27/debian/rules
--- clutter-gst-3.0-3.0.27/debian/rules 2022-05-12 22:30:52.0 +0200
+++ clutter-gst-3.0-3.0.27/debian/rules 2024-01-21 23:08:27.0 +0100
@@ -11,7 +11,7 @@
 
 override_dh_auto_configure:
dh_auto_configure -- \
-   --enable-gtk-doc \
+   --$(if $(filter libclutter-gst-3.0-doc,$(shell 
dh_listpackages)),en,dis)able-gtk-doc \
--enable-introspection
 
 override_dh_install:

Bug#1061258: closed by Debian FTP Masters (reply to Peter Pentchev ) (Bug#1061258: fixed in rpm 4.18.2+dfsg-1)

[Marek Marczykowski-Górecki]

Thanks for the blazing fast fix!

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

Bug#1061272: sudo: Does not build from prefered source

[Bastien Roucariès]

Source: sudo
Severity: serious
Tags: ftbfs
Justification: yacc/lex are prefered source

Dear Maintainer,

You do not pass the --with-devel=yes configure flags thus you do not rebuild
from source autogenerated file like gram.c and gram.h from gram.y

Usually debian build from source grammar file particularly for sensitive
security components like sudo

Bastien


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

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

-- no debconf information

Bug#1061270: lintian: Reports bogus bin-sbin-mismatch issues

[Robert Luberda]

Package: lintian
Version: 2.116.3
Severity: normal

For dwww package lintian reports:
X: dwww: bin-sbin-mismatch usr/sbin/dwww -> usr/bin/dwww [etc/cron.daily/dwww]
X: dwww: bin-sbin-mismatch usr/sbin/dwww -> usr/bin/dwww [etc/cron.weekly/dwww]
X: dwww: bin-sbin-mismatch usr/sbin/dwww -> usr/bin/dwww [postinst]
X: dwww: bin-sbin-mismatch usr/sbin/dwww -> usr/bin/dwww [usr/lib/cgi-bin/dwww]
X: dwww: bin-sbin-mismatch usr/sbin/dwww -> usr/bin/dwww 
[usr/sbin/dwww-refresh-cache]

And lintian is simply wrong here. The dwww package contains a  single 
/usr/bin/dwww command and a few other /usr/sbin/dwww-something commands.
All the scripts listed above check the commands correcly. For example 
/etc/cron-weekly/dwww
basically contains this (unimportant stuff removed):

  # check if swish++ is installed
  test -x /usr/bin/index++ || exit 0

  # check if dwww is still installed
  test -x /usr/sbin/dwww-index++ || exit 0

  # See ionice(1)
  [ -x /usr/bin/ionice ] &&  IONICE="/usr/bin/ionice -c3 -t" || IONICE=

  $IONICE dwww-index++ > /dev/null

Regards,
robert


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

Kernel: Linux 6.6.11-amd64 (SMP w/4 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)

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

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  

Bug#1061271: reportbug: Please make "Selected mail user agent cannot be found" more user friendly

[Robert Luberda]

Package: reportbug
Version: 12.0.0
Severity: wishlist

Today I've tried to run reportbug after a pretty long time of not using
it, and it turned out that it did nothing, but printing something like:
"Selected mail user agent cannot be found, exiting".

It took me a few minutes to discover that I have ~/.reportbugrc from
2012 containing a "mutt" line, but mutt package was no longer installed
on my system (most likely it got removed some time ago by mistake).
After reinstalling mutt, reportbug started working fine.

But I wish the message printed by reportbug in such cases would be more
helpful. It would be nice if it could at least include the name of the
selected mua, for example: "Selected mail user agent 'mutt' cannot be
found". (It would be even greater if it could print the name of the
config file as well, e.g. "Mail user agent 'mutt' selected in
~/.reportbugrc cannot be found").

Regards,
robert

-- Package-specific info:
** Environment settings:
EDITOR="vim"
DEBEMAIL="rob...@debian.org"
DEBFULLNAME="Robert Luberda"
INTERFACE="text"

** /home/robert/.reportbugrc:
reportbug_version "1.99.29"
mode advanced
ui text
realname "Robert Luberda"
email "rob...@debian.org"
no-cc
offline
mutt

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

Kernel: Linux 6.6.11-amd64 (SMP w/4 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)

Versions of packages reportbug depends on:
ii  apt2.7.10
ii  python33.11.6-1
ii  python3-reportbug  12.0.0
ii  sensible-utils 0.0.20

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail  
ii  debconf 1.5.83
ii  debsums 3.0.2.1
ii  dlocate 1.12
pn  emacs-bin-common
ii  file1:5.45-2+b1
ii  gnupg   2.2.40-1.1
ii  postfix [mail-transport-agent]  3.8.4-1
pn  python3-urwid   
pn  reportbug-gtk   
ii  xdg-utils   1.1.3-4.1

Versions of packages python3-reportbug depends on:
ii  apt2.7.10
ii  file   1:5.45-2+b1
ii  python33.11.6-1
ii  python3-apt2.7.5
ii  python3-debian 0.1.49
ii  python3-debianbts  4.0.2
ii  python3-requests   2.31.0+dfsg-1
ii  sensible-utils 0.0.20

python3-reportbug suggests no packages.

-- no debconf information

Bug#1061269: nvidia-graphics-drivers: new upstream stable release 535.154.05

[Simon McVittie]

Source: nvidia-graphics-drivers
Version: 525.147.05-1
Severity: wishlist

The beta 535.43.02 currently packaged in experimental has been superseded
by a new "production branch" version 535.154.05.

I don't really understand Nvidia's versioning policy, but R535 seems to be
a long-term support branch for Tesla according to
, so hopefully
this is suitable for unstable and backports to bookworm too?

I've attempted to update the packaging in
.
I don't have a testing/unstable machine with an Nvidia GPU, but it seems to
work OK on bookworm.

(Disclosure: I was only updating this driver because I thought it might
make Baldur's Gate 3 split-screen coop stop crashing. It does not, but
that isn't a regression.)

I also tried to put together an update to the 545 "new feature" branch in
,
but that needs some additional backports/updates like nvidia-modprobe,
so I haven't attempted to test that one.

smcv

Bug#1058089: multiprocess: FTBFS: KeyError: '/psm_00befb89'

[Stefano Rivera]

Hi 1058089 (2024.01.21_17:19:38_-0400)
> This package ships a separate version of the source for each python 3.X
> version. So, this requires a new upstream release, git snapshot, or
> a patch with the 3.12 tree.

Oh, no, it does have the py3.12 dir. Never mind.

Stefano

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

Bug#1061240: bugs.debian.org: ALSA don't recognize Mackie ProFxV3 USB sound cards since 5.10 linux kernel

[Don Armstrong]

Control: reassign -1 linux

bugs.debian.org is for issues with the bug tracking system, not issues
with the linux Kernel.

On Sun, 21 Jan 2024, Olivier Delemar wrote:
> The Mackie ProFX16 is a mixer with a 2x4 USB interface. When I plug it on my
> computer, kern.log reports :

[...]

> I've tried genuine debian kernel also and notice no differences regarding this
> bug compared to the Librazik custom kernel.

Please run it with a recent Debian kernel and include the version number
(and any other details from lsusb -v), and include those details in the
bug. [I don't know enough of the sound subsystem details to be of much
more help, sorry.]

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

He no longer wished to be dead. At the same time, it cannot be said
that he was glad to be alive. But at least he did not resent it. He
was alive, and the stubbornness of this fact had little by little
begun to fascinate him -- as if he had managed to outlive himself, as
if he were somehow living a posthumous life.
 -- Paul Auster _City of Glass_

Bug#1058089: multiprocess: FTBFS: KeyError: '/psm_00befb89'

[Stefano Rivera]

This package ships a separate version of the source for each python 3.X
version. So, this requires a new upstream release, git snapshot, or
a patch with the 3.12 tree.

https://github.com/uqfoundation/multiprocess/commits/master/py3.12

Stefano

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

Bug#1060889: [Pkg-clamav-devel] Bug#1060889: Bug#1060889: clamav cannot be cross-arch installed?

[Sebastian Andrzej Siewior]

On 2024-01-17 22:00:49 [+0100], To Trent W. Buck wrote:
> > 2. clamav's Depends/Conflicts/Replaces are subtly bugged, and should be 
> > "fixed"; or
> 
> The multi-arch fields could be wrong. Let me check that.

I fixed this in unstable. Given that the memory on i386 are almost the
same as on amd64 I assume you don't need this fixed in stable/bookworm?

Sebastian

Bug#1061232: src:coq: fails to migrate to testing for too long: triggers autopkgtest issues

[julien . puydt]

Hi,

Le dimanche 21 janvier 2024 à 21:38 +0100, Paul Gevers a écrit :
> Hi,
> 
> On 21-01-2024 21:06, julien.pu...@gmail.com wrote:
> > Would kicking the mathcomp-analysis package out of testing allow
> > the
> > migration of the rest of the Coq-related packages and at least give
> > a
> > coherent set there?
> 
> It seems src:mathcomp-analysis is a leaf package that can easily be 
> removed indeed.
> 

It is.

> > That would still leave mathcomp-analysis broken in
> > unstable, of course, but that's a lesser evil.
> 
> Indeed.

.

> > If the issue isn't cleared for testing by february first, I'll just
> > ask for a full RM of mathcomp-analysis : a brutal fix, but an
> > efficient one.
> 
> Well, I think that if the package (once fixed) is still useful to
> have in Debian, temporary removal from testing is a reasonable trick
> to solve situations like this, no need for a full RM. Once fixed it
> can migrate  again. Obviously if you think the situation for this
> package in Debian  is bad, than full RM makes sense of course.

Well, I have some code depending on it as a user... broken since that
long, so yes it would be useful. But if upstream doesn't follow the
ecosystem timely, I might have to port my code around it to stay
current.

As a DD... I'm quite annoyed to see the upstream side of the ecosystem
move and the  Debian side get frozen for a single package.

> I have added a removal hint (for removal from testing).

Thanks, that will be a relief to at least save testing from this mess.

Thanks again,

J.Puydt

Bug#1061232: src:coq: fails to migrate to testing for too long: triggers autopkgtest issues

[Paul Gevers]

Hi,

On 21-01-2024 21:06, julien.pu...@gmail.com wrote:

Would kicking the mathcomp-analysis package out of testing allow the
migration of the rest of the Coq-related packages and at least give a
coherent set there?


It seems src:mathcomp-analysis is a leaf package that can easily be 
removed indeed.



That would still leave mathcomp-analysis broken in
unstable, of course, but that's a lesser evil.


Indeed.


If the issue isn't cleared for testing by february first, I'll just ask
for a full RM of mathcomp-analysis : a brutal fix, but an efficient
one.


Well, I think that if the package (once fixed) is still useful to have 
in Debian, temporary removal from testing is a reasonable trick to solve 
situations like this, no need for a full RM. Once fixed it can migrate 
again. Obviously if you think the situation for this package in Debian 
is bad, than full RM makes sense of course.


I have added a removal hint (for removal from testing).

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061232: src:coq: fails to migrate to testing for too long: triggers autopkgtest issues

[julien . puydt]

Hi,

Le dimanche 21 janvier 2024 à 08:42 +0100, Paul Gevers a écrit :
> Source: coq
> Version: 8.17.0+dfsg-1
> Severity: serious
> Control: close -1 8.18.0+dfsg-1
> Tags: sid trixie
> User: release.debian@packages.debian.org
> Usertags: out-of-sync
> 
> Dear maintainer(s),
> 
> The Release Team considers packages that are out-of-sync between
> testing and unstable for more than 30 days as having a Release
> Critical bug in testing [1]. Your package src:coq has been trying to
> migrate for 31 days
> [2]. Hence, I am filing this bug. The version in unstable causes 
> autopkgtest failures in multiple reverse (test) dependencies: 
> mathcomp-analysis (affected by FTBFS bug 1060988) and mathcomp-finmap
> (which has a newer version in unstable with issues).
> 
> If a package is out of sync between unstable and testing for a longer
> period, this usually means that bugs in the package in testing cannot
> be fixed via unstable. Additionally, blocked packages can have impact
> on other packages, which makes preparing for the release more
> difficult.
> Finally, it often exposes issues with the package and/or
> its (reverse-)dependencies. We expect maintainers to fix issues that 
> hamper the migration of their package in a timely manner.
> 
> This bug will trigger auto-removal when appropriate. As with all new 
> bugs, there will be at least 30 days before the package is auto-
> removed.
> 
> I have immediately closed this bug with the version in unstable, so
> if 
> that version or a later version migrates, this bug will no longer
> affect 
> testing. I have also tagged this bug to only affect sid and trixie,
> so 
> it doesn't affect (old-)stable.
> 
> If you believe your package is unable to migrate to testing due to 
> issues beyond your control, don't hesitate to contact the Release
> Team.

I fixed the mathcomp-finmap issue in unstable, so in two days (too
young excuse) that will leave only mathcomp-analysis blocking Coq-
related packages from migrating as far as I can tell.


The problem with mathcomp-analysis is that:

- I had understood upstream would release a version compatible with "MC
2" (ssreflect package in Debian) by the end of december, so I started
uploading the whole set (about fifty packages) even though I didn't
have that good version yet, pretty confident the breakage would be
transitory, perhaps even invisible since it's a leaf package ;

- but then the new compatible release would come in january ;

- and now january is coming to an end without it ;

- in fact there was a new release three days ago to add compatibility
with the yet-unreleased next Coq... but still "MC 1"!

The conclusion is: I shouldn't have jumped the gun.

Would kicking the mathcomp-analysis package out of testing allow the
migration of the rest of the Coq-related packages and at least give a
coherent set there? That would still leave mathcomp-analysis broken in
unstable, of course, but that's a lesser evil.

If the issue isn't cleared for testing by february first, I'll just ask
for a full RM of mathcomp-analysis : a brutal fix, but an efficient
one.

Thanks,

J.Puydt

Bug#1056068: RFH: resvg -- SVG rendering library (command-line utility)

[Jonas Smedegaard]

Quoting Andrej Shadura (2023-11-16 18:19:47)
> On 16/11/2023 18:14, Jonas Smedegaard wrote:
> > Upstream project consist of multiple crates released in sync -
> > which is a pattern that is only inefficiently handled by the Rust 
> > team (by needlessly packaging each individual crate as a separate 
> > Debian source package).
> > 
> > Unless you particularly are asking the Rust team for help here, 
> > then I can offer to help: I have experience with handling this type 
> > of Rust source code structure, and would be happy for this 
> > opportunity to collaborate more closely with you, Andrej.
> 
> Yes, I’m aware of that, that’s why I packaged it separately from the 
> debcargo-conf-managed packages. Nevertheless, the dependencies can be 
> managed using debcargo-conf workflow (and that’s what I did when I 
> still had energy to spend on this package).
> 
> In any case, I’ll be happy with any help that can be had with this 
> package, whether it’s updating/packaging build dependencies as 
> separate packages or by following the debcargo-conf workflow, and 
> from anyone — you, Jonas, included :)

Just a notice that I am still working on this.  If you want to follow my
work more closely, then I can put up my fork of the git repo somewhere,
but if you won't be looking closely anyway, then I will not bother
setting that up, and instead simply shout out when I have something
more substantially working.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1042074: bash-completion: Completion for 'sh' command filters file name with only '*.sh'

[Gabriel F. T. Gomes]

Upstream does not want this change 
(https://github.com/scop/bash-completion/issues/442).

Bug#1061268: debian-security-support: ending security support for chromium in bullseye

[Andres Salomon]

Package: debian-security-support
Version: 1:13+2023.12.23
Severity: normal

As documented in the release notes [0] and warned about via NEWS.Debian 
entry [1], support for chromium in bullseye-security has now ended. 
Please mark it as such in the d-s-s package as well. Thanks!



[0] 
https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#browser-security
[1] 
https://salsa.debian.org/chromium-team/chromium/-/blob/bullseye/debian/NEWS?ref_type=heads

Bug#1043240: transition: pandas 1.5 -> 2.1

[Stelios Moschos]

Hi, how to remove myself from these lists?

Thank you

On Sun, 21 Jan 2024 at 18:30, Andreas Tille  wrote:

> Hi Rebecca,
>
> Am Sun, Jan 21, 2024 at 03:29:21PM + schrieb Rebecca N. Palmer:
> >
> > Hence, doing this transition now would involve breaking some reverse
> > dependencies with no known fix, but given the number of packages
> involved,
> > trying to wait until they're all fixed is rather likely to instead end in
> > pandas 1.5 being broken by a new Python/numpy/etc.
>
> Just go for it and lets try to fix issues as soon as possible.
>
> Thanks a lot for all your work on pandas
>
>  Andreas.
>
> --
> http://fam-tille.de
>
>

Bug#1061267: transition: unixcw

[tony mancill]

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

Dear Release Team,

I am requesting a transition for unixcw [1].  The one reverse
dependency, cwdaemon, builds correctly against the package in
experimental.  The auto-transition page is [2].

Thank you,
tony

[1] https://tracker.debian.org/pkg/unixcw
[2] https://release.debian.org/transitions/html/auto-unixcw.html

Ben file:

title = "unixcw";
is_affected = .depends ~ "libcw7" | .depends ~ "libcw8";
is_good = .depends ~ "libcw8";
is_bad = .depends ~ "libcw7";

Bug#1060279: r-cran-nanoarrow_0.3.0.1-1_amd64.changes REJECTED

[Andreas Tille]

Hi Thorsten,

Am Fri, Jan 19, 2024 at 07:00:10PM + schrieb Thorsten Alteholz:
> according to the file headers, the only copyright holder is the Apache 
> Software Foundation.

Fixed in new upload.

> There shall be a file called NOTICE to clarify the copyright situation.
> Please tell upstream to add this file to the source tarball.

The upstream Git repository contains several language interfaces.  I've
fetched the NOTICE file from the root dir and added it to the package in
the new upload. 

Thanks for checking
 Andreas.

-- 
http://fam-tille.de

Bug#1059811: "chromium --" runs browser

[Gabriel F. T. Gomes]

* Philipp Marek wrote:

> This sequence runs chromium and blocks the shell until the browser is closed 
> again:
> 
> $ chromium --

That doesn't happen on my system, either with or without chromium installed.

The completion file runs 'chromium --help' and that exits quickly. What happens 
for you when you run 'chromium --help' on the shell?

Bug#1054189: bullseye-pu: package debian-security-support/1:11+2023.10.17

[Holger Levsen]

hi!

On Fri, Dec 29, 2023 at 03:23:55PM +, Jonathan Wiltshire wrote:
> In the past this package has been released early via stable-updates; is
> that your intention this time, or can it wait until the next point release
> expected in February?
 
after having spent a bit too much time thinking about this I've came to the
conclusion that I think updates of d-s-s in stable and previous releases should
a.) always come with an announcement and b.) always come ASAP, whatever
that means in details.

Does that make sense to you too?

(for completeness: updates in unstable and testing should also be done ASAP
and without announcements.)


-- 
cheers,
Holger

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

»Sieh, dass du Mensch bleibst. Mensch sein ist von allem die Hauptsache.
Und das heißt fest und klar und heiter sein, ja heiter, trotz alledem.«
(Rosa Luxemburg)


signature.asc
Description: PGP signature

Bug#1061153: ITP: sigsum-go -- tools for public and transparent logging of signed checksums

[Holger Levsen]

Hi Simon,

On Fri, Jan 19, 2024 at 05:32:05PM +0100, Simon Josefsson wrote:
> * URL : https://git.glasklar.is/sigsum/core/sigsum-go
>   Description : tools for public and transparent logging of signed 
> checksums
> 
>  The goal of Sigsum is to provide building blocks that can be used to
>  enforce public logging of signed checksums.

do you think this would be a suitable tool to publically log all checksums of
all Debian source and binary packages published?


-- 
cheers,
Holger

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

Life may not be the party we hoped for, but while we're here we might as well
dance!


signature.asc
Description: PGP signature

Bug#1057020: libgdk-pixbuf-2.0-0: Fails to load webp

[Michal Nazarewicz]

Package: geeqie
Version: 1:2.1-2
Followup-For: Bug #1057020
X-Debbugs-Cc: min...@mina86.com

For anyone interested, Geeqie being unable to render webp images is tracked
upstream at https://github.com/BestImageViewer/geeqie/issues/1076.  

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

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

Versions of packages geeqie depends on:
ii  geeqie-common1:2.1-2
ii  libarchive13 3.7.2-1
ii  libc62.37-13
ii  libcairo21.18.0-1+b1
ii  libdjvulibre21   3.5.28-2+b1
ii  libexiv2-27  0.27.6-1+b1
ii  libffmpegthumbnailer4v5  2.2.2+git20220218+dfsg-2+b1
ii  libgcc-s113.2.0-9
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3
ii  libglib2.0-0 2.78.3-1
ii  libgspell-1-21.12.2-1
ii  libgtk-3-0   3.24.39-1
ii  libheif1 1.17.6-1
ii  libjpeg62-turbo  1:2.1.5-2+b2
ii  libjxl0.70.7.0-10.2+b1
ii  liblcms2-2   2.14-2
ii  liblua5.3-0  5.3.6-2
ii  libopenjp2-7 2.5.0-2+b2
ii  libpango-1.0-0   1.51.0+ds-3
ii  libpangocairo-1.0-0  1.51.0+ds-3
ii  libpoppler-glib8 22.12.0-2+b1
ii  libraw23 0.21.2-2
ii  libstdc++6   13.2.0-9
ii  libtiff6 4.5.1+git230720-3
ii  sensible-utils   0.0.20

Versions of packages geeqie recommends:
ii  cups-bsd [lpr]   2.4.7-1+b1
ii  exiftran 2.10-5
ii  exiv20.27.6-1+b1
ii  imagemagick  8:6.9.12.98+dfsg1-5+b1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.12.98+dfsg1-5+b1
ii  librsvg2-common  2.54.7+dfsg-2
ii  zenity   4.0.1-1

Versions of packages geeqie suggests:
ii  gimp 2.10.36-2
ii  libjpeg-turbo-progs [libjpeg-progs]  1:2.1.5-2+b2
pn  xpaint   

-- debconf-show failed

Bug#939583: rsstail: Please consider updating to version 2.1

[Bardot Jerome]

Package: rsstail
Version: 1.8-1+b1
Followup-For: Bug #939583
X-Debbugs-Cc: bardot.jer...@gmail.com

Dear Maintainer,

Please upgrade to 2.1 as it add capabilities. (-T options).

As remember :
https://github.com/folkertvanheusden/rsstail/


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

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

Versions of packages rsstail depends on:
ii  libc6 2.37-13
ii  libmrss0  0.19.2-7

rsstail recommends no packages.

rsstail suggests no packages.

-- no debconf information

Bug#1061266: [PATCH] sgmls: Fix type of signal handlers for C89 compatibility

[Florian Weimer]

Package: linuxdoc-tools
Version:  0.9.82-1
Tags: upstream patch

This is another fallout from GCC 14 porting of Fedora.

Without this change, the outcome of two tests are altered due to
compiler errors:

-#define HAVE_EXTENDED_PRINTF 1 
+/* #define HAVE_EXTENDED_PRINTF 1 */

-/* #define USE_ISASCII 1 */
+#define USE_ISASCII 1

(Not sure if the second change is a pre-existing bug or not.)

diff --git a/sgmls-1.1/configure b/sgmls-1.1/configure
index e674d24..898b522 100755
--- a/sgmls-1.1/configure
+++ b/sgmls-1.1/configure
@@ -113,7 +113,7 @@ cat >doit.c <<\EOF
 #include 
 #include 
 
-static int whoops()
+static void whoops(int signo)
 {
   _exit(1);
 }
@@ -459,7 +459,7 @@ cat >doit.c <<\EOF
 #include 
 #include 
 
-static int whoops()
+static void whoops(int signo)
 {
   _exit(1);
 }
-- 
2.43.0

Bug#1043240: transition: pandas 1.5 -> 2.1

[Andreas Tille]

Hi Rebecca,

Am Sun, Jan 21, 2024 at 03:29:21PM + schrieb Rebecca N. Palmer:
> 
> Hence, doing this transition now would involve breaking some reverse
> dependencies with no known fix, but given the number of packages involved,
> trying to wait until they're all fixed is rather likely to instead end in
> pandas 1.5 being broken by a new Python/numpy/etc.

Just go for it and lets try to fix issues as soon as possible.

Thanks a lot for all your work on pandas

 Andreas.

-- 
http://fam-tille.de

Bug#1041228: policykit-1: Polkit fails if more than one rule is defined in /usr/local/share/polkit-1

[Michael Biebl]

Control: tags -1 + moreinfo

On Sat, 15 Jul 2023 14:35:37 -0700 Stepan Novotny  
wrote:

   * What led up to the situation?
I created /etc/polkit-1/rules.d/99-shutdown.rules and this worked fine:
polkit.addRule(function(action, subject) {
   if (action.id == 'org.freedesktop.login1.power-off-multiple-sessions' &&  
subject.isInGroup('Debian-gdm'))
   return polkit.Result.YES; else return polkit.Result.NOT_HANDLED;
});

Then I added a second file /etc/polkit-1/rules.d/99-power-off.rules and both 
failed to work:
polkit.addRule(function(action, subject) {
   if (action.id == 'org.freedesktop.login1.reboot-multiple-sessions' &&  
subject.isInGroup('Debian-gdm'))
   return polkit.Result.YES; else return polkit.Result.NOT_HANDLED;
});

I found that either one of the above files by itself works fine, but it fails 
if both files are present.


Can you post exact failure messages please?
What exactly did not work?
Maybe also provide a debug log of polkitd.

Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061265: rst2pdf: Uses deprecated/to be removed pypdf2

[Scott Kitterman]

Source: rst2pdf
Version: 0.99-1
Severity: wishlist

rst2pdf declares a requirement for python3-pypdf2 in
Build-Depends-Indep.

I've recently adopted pypdf and pypdf2 into the Debian Python Team in response 
to an RFA for both packages.  As these are somewhat security sensitive packages 
(among my first acts after adopting the packages was to upload proposed updates 
for both to address minor security issues in Bookworm in the next point release 
- same bug in both), I do not think we should release pypdf2 in Trixie and have 
filed an RC bug to that effect.

It looks like the current upstream release has already been ported to
use python3-pypdf (which is really pypdf3).  Please update your package.

Scott K

Bug#1061264: ocrmypdf: Uses deprecated/to be removed pypdf2 in autopkgtest

[Scott Kitterman]

Source: ocrmypdf
Version: 15.2.0+dfsg1-1
Severity: wishlist

I've recently adopted pypdf and pypdf2 into the Debian Python Team in response 
to an RFA for both packages.  As these are somewhat security sensitive packages 
(among my first acts after adopting the packages was to upload proposed updates 
for both to address minor security issues in Bookworm in the next point release 
- same bug in both), I do not think we should release pypdf2 in Trixie and have 
filed an RC bug to that effect.

ocrmypdf uses the package in debian/tests/control.  Please update to use
python3-pypdf insteadm.

Bug#1029740: pypdf2 is deprecated, please move from python3-pypdf2 to python3-pypdf

[Scott Kitterman]

On Fri, 27 Jan 2023 00:26:31 +0100 Mathias Behrle  wrote:
> tag -1 pending
> 
> API changes were already considered in
> https://foss.heptapod.net/tryton/tryton/-/merge_requests/25
> https://foss.heptapod.net/tryton/tryton/-/merge_requests/27
> and Tryton packages should be fit for any version 1, 2, 3 of pypdf.
> 
> We are waiting for backports of the fixes to 6.0. We will anyway include them
> for bookworm. As we are maintaining backports for bullseye and buster we 
will
> stick for now with python3-pypdf2, until python3-pypdf will be available as
> backport in the targeted Debian releases.

As we approach the first anniversary for this bug, an update:

I've recently adopted pypdf and pypdf2 into the Debian Python Team in response 
to an RFA for both packages.  As these are somewhat security sensitive 
packages (among my first acts after adopting the packages was to upload 
proposed updates for both to address minor security issues in Bookworm in the 
next point release - same bug in both), I do not think we should release 
pypdf2 in Trixie and have filed an RC bug to that effect.

If you want this package to be in Trixie, you will need to use pypdf instead 
of pypdf2.

Scott K

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

Bug#1061263: python3-spglib: fails with python3.12 (extension not built)

[Drew Parsons]

Package: python3-spglib
Version: 2.2.0-2
Severity: normal

python3-spglib fails with python3.12, since the python extension is
built only for python3.11.

spglib should be configured to build for all available python versions.
In other libraries (e.g. fenics-basix) this is done by building the C
library separately from the the python module.

Not sure, should this be severity: serious?


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

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

Versions of packages python3-spglib depends on:
ii  libc6  2.37-13
ii  libsymspg2 2.2.0-2
ii  python33.11.6-1
ii  python3-numpy  1:1.24.2-2

python3-spglib recommends no packages.

python3-spglib suggests no packages.

-- no debconf information

Bug#1029739: pypdf2 is deprecated, please move from python3-pypdf2 to python3-pypdf

[Scott Kitterman]

On Thu, 26 Jan 2023 16:39:39 -0500 Daniel Kahn Gillmor  
wrote:
 
> As noted in https://bugs.debian.org/1028559, upstream for the PyPDF2
> Python module has moved to the "pypdf" namespace.
> 
> Correspondingly, there is a new python3-pypdf package in debian
> unstable.
> 
> The packages listed above all currently depend on (or recommend) PyPDF2,
> but probably should move to the updated version.  When all these bug
> reports are closed, we can consider removing the pypdf2 source package
> and python3-pypdf2 from debian.
> 
> The migration should be relatively straightforward; much of the API
> remains the same, just under the "pypdf" module name instead of the
> "PyPDF2" module name.  Where the API differs, the version of PyPDF2
> currently in debian testing/unstable (2.12.1-3) emits a
> PendingDeprecationWarning wherever a piece of the API will break.
> 
> For example:
> 
>foo.py:76: PendingDeprecationWarning: getObject is deprecated and will be 
removed in PyPDF2 3.0.0. Use get_object instead.
> 
> (PyPDF2 version 3.x is basically a terminal version of PyPDF2, and pypdf
> takes over from 3.1.x onward; PyPDF2 version 3.x will not enter debian,
> as it is an API break from 2.x, and pypdf 3.x supercedes it)

As we approach the first anniversary for this bug, an update:

I've recently adopted pypdf and pypdf2 into the Debian Python Team in response 
to an RFA for both packages.  As these are somewhat security sensitive 
packages (among my first acts after adopting the packages was to upload 
proposed updates for both to address minor security issues in Bookworm in the 
next point release - same bug in both), I do not think we should release 
pypdf2 in Trixie and have filed an RC bug to that effect.

If you want this package to be in Trixie, you will need to use pypdf instead 
of pypdf2.  There is a new upstream release that supports this transition, but 
packaging it will be non-trivial.

Scott K

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

Bug#1060246: perl: proposed patch for perl ABI change due to 64-bit time_t

[Steve Langasek]

On Tue, Jan 09, 2024 at 12:06:40AM +0200, Niko Tyni wrote:
> > It tries to retain compatibility with perlapi-5.36.0 on architectures where
> > this is appropriate (64-bit architectures + i386); it covers Debian release
> > architectures + riscv64, but does not attempt to be complete for all
> > architectures dpkg knows about.

> Is there a reason you're bumping the abi for all the architectures rather
> than just the affected ones? I'd expect this to be "opt in" so perlabi
> would be defined just for armhf, hppa and so forth.

> I'm thinking something like what we did for the s390x jmp_buf thing

>   ifeq (s390x-linux-gnu,$(shell dpkg-architecture -qDEB_HOST_GNU_TYPE))
>   perlabi = 5.18.2d
>   else
>   perlabi =
>   endif

> as per 
> https://salsa.debian.org/perl-team/interpreter/perl/-/commit/a66f196c13108b04909f9ec0e05986983cb2ed19

That's a very good point that I didn't think of, I'm +1 for doing it this
way.

> > This is entirely optional anyway, as perl
> > 5.38 is just around the corner, at which point this patch should be dropped
> > completely (assuming time_t lands before perl 5.38 does).
> 
> TBH I was hoping 5.38 would land first :)

And it has \o/

Do you want me to provide an updated patch, or will you integrate this on
your side?

> OOC, have you got the perl test suite passing with time64? I just did
> a quick try on i386 with just DEB_BUILD_OPTIONS=abi=+time64 and I'm
> seeing 

> Failed 7 tests out of 2623, 99.73% okay.
>   ../cpan/DB_File/t/db-btree.t
>   ../cpan/DB_File/t/db-hash.t
>   ../cpan/DB_File/t/db-recno.t
>   ../cpan/DB_File/t/db-threads.t
>   ../cpan/Memoize/t/errors.t
>   ../cpan/Memoize/t/tie.t
>   porting/libperl.t

> but I guess that's because things like libdb5.3 need to be rebuilt first?

Sorry, haven't tried anything like this yet.  ABI skew with dependencies
could certainly explain test suite failures!

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1061262: ecdh-nist-p256: stack dump on boot

[Kjell M. Myksvoll]

Package: ecdh-nist-p256
Severity: normal
X-Debbugs-Cc: kjell.myksv...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?

Reboot after package updates.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?

[3.334317] [ cut here ]
[3.334319] alg: self-tests for ecdh-nist-p256 using ecdh-nist-p256-generic 
failed (rc=-14)
[3.334325] WARNING: CPU: 27 PID: 461 at crypto/testmgr.c:5936 
alg_test+0x516/0x630
[3.334331] Modules linked in: ecdh_generic(+) ecc crc16 amdgpu(+) 
i2c_algo_bit drm_ttm_helper ttm video drm_suballoc_helper amdxcp drm_buddy 
gpu_sched drm_display_helper drm_kms_helper xhci_pci nvme drm xhci_hcd 
nvme_core t10_pi crc32c_intel cec usbcore crc64_rocksoft crc64 rc_core 
crc_t10dif crct10dif_generic crct10dif_pclmul crct10dif_common usb_common 
gpio_amdpt wmi gpio_generic
[3.334369] CPU: 27 PID: 461 Comm: cryptomgr_test Not tainted 6.5.0-5-amd64 
#1  Debian 6.5.13-1
[3.334372] Hardware name: System manufacturer System Product Name/PRIME 
X399-A, BIOS 1601 04/14/2023
[3.334374] RIP: 0010:alg_test+0x516/0x630
[3.334377] Code: ff ff 4c 89 e6 4c 89 e7 41 89 c7 e8 e4 f4 fe ff e9 37 ff 
ff ff 44 89 f9 48 89 ea 4c 89 ee 48 c7 c7 38 08 0c 98 e8 1a 5d b5 ff <0f> 0b e9 
7d fe ff ff 48 89 c2 48 89 ee 48 c7 c7 70 07 0c 98 45 89
[3.334379] RSP: 0018:bd2844e97e10 EFLAGS: 00010286
[3.334381] RAX:  RBX: 007e RCX: c0007fff
[3.334383] RDX:  RSI: 7fff RDI: 0001
[3.334385] RBP: 987682aeee00 R08:  R09: bd2844e97ca0
[3.334386] R10: 0003 R11: 987deedfffe8 R12: 007f
[3.334388] R13: 987682aeee80 R14:  R15: fff2
[3.334390] FS:  () GS:987def0c() 
knlGS:
[3.334392] CS:  0010 DS:  ES:  CR0: 80050033
[3.334393] CR2: 7fe96d9ba840 CR3: 00010c7ea000 CR4: 003506e0
[3.334395] Call Trace:
[3.334398]  
[3.334399]  ? alg_test+0x516/0x630
[3.334401]  ? __warn+0x81/0x130
[3.334406]  ? alg_test+0x516/0x630
[3.334409]  ? report_bug+0x171/0x1a0
[3.334413]  ? prb_read_valid+0x1b/0x30
[3.334417]  ? srso_return_thunk+0x5/0x10
[3.334422]  ? handle_bug+0x3c/0x80
[3.334426]  ? exc_invalid_op+0x17/0x70
[3.334429]  ? asm_exc_invalid_op+0x1a/0x20
[3.334435]  ? alg_test+0x516/0x630
[3.334438]  ? psi_memstall_leave+0xb0/0xb0
[3.334441]  ? srso_return_thunk+0x5/0x10
[3.33]  ? finish_task_switch.isra.0+0x8f/0x2d0
[3.334449]  ? srso_return_thunk+0x5/0x10
[3.334452]  ? __schedule+0x3e2/0xb20
[3.334457]  ? __pfx_cryptomgr_test+0x10/0x10
[3.334460]  cryptomgr_test+0x24/0x40
[3.334464]  kthread+0xe8/0x120
[3.334468]  ? __pfx_kthread+0x10/0x10
[3.334471]  ret_from_fork+0x34/0x50
[3.334475]  ? __pfx_kthread+0x10/0x10
[3.334478]  ret_from_fork_asm+0x1b/0x30
[3.334486]  
[3.334487] ---[ end trace  ]---

   * What outcome did you expect instead?

No stack dump.

*** 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.5.0-5-amd64 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8), 
LANGUAGE=nb_NO:nb:no_NO:no:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1061248: glibc: DEP17: move most files but rtld to /usr

[Sven Joachim]

Am 21.01.2024 um 15:25 schrieb Helmut Grohne:

> Source: glibc
> Version: 2.37-13
> Tags: patch
> User: helm...@debian.org
> Usertags: dep17m2
>
> Hi Aurelien,
>
> thanks for your answers on IRC to my design question. As promised here
> comes a patch that moves most files in binary packages built from glibc
> from aliased locations to /usr. This excludes the runtime dynamic linker
> for native libc packages (i.e. not multilib), because moving it would
> break filesystem bootstrap unless base-files installs the aliasing
> symlinks at the same time.

I have not studied the details, but this looks rather dangerous to me.
If you install the runtime dynamic linker in multilib packages below
/usr, but keep the native one at its current place, you risk losing it
when the multilib packages are removed.

For instance, I have both libc6:i386 and libc6-i386:amd64 installed.  If
the latter starts shipping /usr/lib/ld-linux.so.2 rather than
/lib/ld-linux.so.2, the "Replaces" in libc6:i386 becomes ineffective,
and we have basically a case of Dep17 P1.

True, there is already a file loss problem today.  If I were to remove
libc6:i386 now, I would be left without /lib/ld-linux.so.2 as well.  But
in such a situation it is always possible to remedy the situation by
reinstalling libc6-i386.  This is not ensured if only libc6-i386 is
removed, as essential programs might depend on libc6:i386, leaving no
easy way of recovery.

Cheers,
   Sven

Bug#1029735: pypdf2 is deprecated, please move from python3-pypdf2 to python3-pypdf

[Scott Kitterman]

On Thu, 26 Jan 2023 16:39:39 -0500 Daniel Kahn Gillmor  
wrote:
> As noted in https://bugs.debian.org/1028559, upstream for the PyPDF2
> Python module has moved to the "pypdf" namespace.
> 
> Correspondingly, there is a new python3-pypdf package in debian
> unstable.
> 
> The packages listed above all currently depend on (or recommend) PyPDF2,
> but probably should move to the updated version.  When all these bug
> reports are closed, we can consider removing the pypdf2 source package
> and python3-pypdf2 from debian.
> 
> The migration should be relatively straightforward; much of the API
> remains the same, just under the "pypdf" module name instead of the
> "PyPDF2" module name.  Where the API differs, the version of PyPDF2
> currently in debian testing/unstable (2.12.1-3) emits a
> PendingDeprecationWarning wherever a piece of the API will break.
> 
> For example:
> 
>foo.py:76: PendingDeprecationWarning: getObject is deprecated and will be 
removed in PyPDF2 3.0.0. Use get_object instead.
> 
> (PyPDF2 version 3.x is basically a terminal version of PyPDF2, and pypdf
> takes over from 3.1.x onward; PyPDF2 version 3.x will not enter debian,
> as it is an API break from 2.x, and pypdf 3.x supercedes it)
> 
> To transition a given package:
> 
>  - run tests with as complete coverage as possible and note the
>PendingDeprecation warnings
> 
>  - for each warning, patch the upstream line as recommended
> 
>  - ensure that the tests pass without PendingDeprecationWarnings
> 
>  - convert from "PyPDF2" to "pypdf" on any import or scoped reference in
>python
> 
>  - update dependency indicators in upstream metadata annotations
>(e.g. pyproject.toml, setup.cfg, etc)
> 
>  - update dependency indicators in debian packaging (from python3-pypdf2
>to python3-pypdf).
> 
>  - run the tests again

As we approach the first anniversary for this bug, an update:

I've recently adopted pypdf and pypdf2 into the Debian Python Team in response 
to an RFA for both packages.  As these are somewhat security sensitive 
packages (among my first acts after adopting the packages was to upload 
proposed updates for both to address minor security issues in Bookworm in the 
next point release - same bug in both), I do not think we should release 
pypdf2 in Trixie and have filed an RC bug to that effect.

If you want this package to be in Trixie, you will need to use pypdf instead 
of pypdf2.

Scott K

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

Bug#1029738: pypdf2 is deprecated, please move from python3-pypdf2 to python3-pypdf

[Scott Kitterman]

On Thu, 26 Jan 2023 16:39:39 -0500 Daniel Kahn Gillmor  
wrote:

> As noted in https://bugs.debian.org/1028559, upstream for the PyPDF2
> Python module has moved to the "pypdf" namespace.
> 
> Correspondingly, there is a new python3-pypdf package in debian
> unstable.
> 
> The packages listed above all currently depend on (or recommend) PyPDF2,
> but probably should move to the updated version.  When all these bug
> reports are closed, we can consider removing the pypdf2 source package
> and python3-pypdf2 from debian.
> 
> The migration should be relatively straightforward; much of the API
> remains the same, just under the "pypdf" module name instead of the
> "PyPDF2" module name.  Where the API differs, the version of PyPDF2
> currently in debian testing/unstable (2.12.1-3) emits a
> PendingDeprecationWarning wherever a piece of the API will break.
> 
> For example:
> 
>foo.py:76: PendingDeprecationWarning: getObject is deprecated and will be 
removed in PyPDF2 3.0.0. Use get_object instead.
> 
> (PyPDF2 version 3.x is basically a terminal version of PyPDF2, and pypdf
> takes over from 3.1.x onward; PyPDF2 version 3.x will not enter debian,
> as it is an API break from 2.x, and pypdf 3.x supercedes it)
> 
> To transition a given package:
> 
>  - run tests with as complete coverage as possible and note the
>PendingDeprecation warnings
> 
>  - for each warning, patch the upstream line as recommended
> 
>  - ensure that the tests pass without PendingDeprecationWarnings
> 
>  - convert from "PyPDF2" to "pypdf" on any import or scoped reference in
>python
> 
>  - update dependency indicators in upstream metadata annotations
>(e.g. pyproject.toml, setup.cfg, etc)
> 
>  - update dependency indicators in debian packaging (from python3-pypdf2
>to python3-pypdf).
> 
>  - run the tests again

As we approach the first anniversary for this bug, an update:

I've recently adopted pypdf and pypdf2 into the Debian Python Team in response 
to an RFA for both packages.  As these are somewhat security sensitive 
packages (among my first acts after adopting the packages was to upload 
proposed updates for both to address minor security issues in Bookworm in the 
next point release - same bug in both), I do not think we should release 
pypdf2 in Trixie and have filed an RC bug to that effect.

If you want this package to be in Trixie, you will need to use pypdf instead 
of pypdf2.

Scott K

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

Bug#1029733: pypdf2 is deprecated, please move from python3-pypdf2 to python3-pypdf

[Scott Kitterman]

On Thu, 26 Jan 2023 16:39:39 -0500 Daniel Kahn Gillmor  
wrote:

> As noted in https://bugs.debian.org/1028559, upstream for the PyPDF2
> Python module has moved to the "pypdf" namespace.
> 
> Correspondingly, there is a new python3-pypdf package in debian
> unstable.
> 
> The packages listed above all currently depend on (or recommend) PyPDF2,
> but probably should move to the updated version.  When all these bug
> reports are closed, we can consider removing the pypdf2 source package
> and python3-pypdf2 from debian.
> 
> The migration should be relatively straightforward; much of the API
> remains the same, just under the "pypdf" module name instead of the
> "PyPDF2" module name.  Where the API differs, the version of PyPDF2
> currently in debian testing/unstable (2.12.1-3) emits a
> PendingDeprecationWarning wherever a piece of the API will break.
> 
> For example:
> 
>foo.py:76: PendingDeprecationWarning: getObject is deprecated and will be 
removed in PyPDF2 3.0.0. Use get_object instead.
> 
> (PyPDF2 version 3.x is basically a terminal version of PyPDF2, and pypdf
> takes over from 3.1.x onward; PyPDF2 version 3.x will not enter debian,
> as it is an API break from 2.x, and pypdf 3.x supercedes it)
> 
> To transition a given package:
> 
>  - run tests with as complete coverage as possible and note the
>PendingDeprecation warnings
> 
>  - for each warning, patch the upstream line as recommended
> 
>  - ensure that the tests pass without PendingDeprecationWarnings
> 
>  - convert from "PyPDF2" to "pypdf" on any import or scoped reference in
>python
> 
>  - update dependency indicators in upstream metadata annotations
>(e.g. pyproject.toml, setup.cfg, etc)
> 
>  - update dependency indicators in debian packaging (from python3-pypdf2
>to python3-pypdf).
> 
>  - run the tests again

As we approach the first anniversary for this bug, an update:

I've recently adopted pypdf and pypdf2 into the Debian Python Team in response 
to an RFA for both packages.  As these are somewhat security sensitive 
packages (among my first acts after adopting the packages was to upload 
proposed updates for both to address minor security issues in Bookworm in the 
next point release - same bug in both), I do not think we should release 
pypdf2 in Trixie and have filed an RC bug to that effect.

If you want this package to be in Trixie, you will need to use pypdf instead 
of pypdf2.

Scott K

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

Bug#1029734: pypdf2 is deprecated, please move from python3-pypdf2 to python3-pypdf

[Scott Kitterman]

On Thu, 26 Jan 2023 16:39:39 -0500 Daniel Kahn Gillmor  
wrote:
> As noted in https://bugs.debian.org/1028559, upstream for the PyPDF2
> Python module has moved to the "pypdf" namespace.
> 
> Correspondingly, there is a new python3-pypdf package in debian
> unstable.
> 
> The packages listed above all currently depend on (or recommend) PyPDF2,
> but probably should move to the updated version.  When all these bug
> reports are closed, we can consider removing the pypdf2 source package
> and python3-pypdf2 from debian.
> 
> The migration should be relatively straightforward; much of the API
> remains the same, just under the "pypdf" module name instead of the
> "PyPDF2" module name.  Where the API differs, the version of PyPDF2
> currently in debian testing/unstable (2.12.1-3) emits a
> PendingDeprecationWarning wherever a piece of the API will break.
> 
> For example:
> 
>foo.py:76: PendingDeprecationWarning: getObject is deprecated and will be 
removed in PyPDF2 3.0.0. Use get_object instead.
> 
> (PyPDF2 version 3.x is basically a terminal version of PyPDF2, and pypdf
> takes over from 3.1.x onward; PyPDF2 version 3.x will not enter debian,
> as it is an API break from 2.x, and pypdf 3.x supercedes it)
> 
> To transition a given package:
> 
>  - run tests with as complete coverage as possible and note the
>PendingDeprecation warnings
> 
>  - for each warning, patch the upstream line as recommended
> 
>  - ensure that the tests pass without PendingDeprecationWarnings
> 
>  - convert from "PyPDF2" to "pypdf" on any import or scoped reference in
>python
> 
>  - update dependency indicators in upstream metadata annotations
>(e.g. pyproject.toml, setup.cfg, etc)
> 
>  - update dependency indicators in debian packaging (from python3-pypdf2
>to python3-pypdf).
> 
>  - run the tests again

As we approach the first anniversary for this bug, an update:

I've recently adopted pypdf and pypdf2 into the Debian Python Team in response 
to an RFA for both packages.  As these are somewhat security sensitive 
packages (among my first acts after adopting the packages was to upload 
proposed updates for both to address minor security issues in Bookworm in the 
next point release - same bug in both), I do not think we should release 
pypdf2 in Trixie and have filed an RC bug to that effect.

If you want this package to be in Trixie, you will need to use pypdf instead 
of pypdf2.

Scott K

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

Bug#1061261: odoo: Uses deprecated/to be removed PyPDF2

[Scott Kitterman]

Source: odoo
Version: 16.0.0+dfsg.2-2
Severity: wishlist

The odoo package has recently added a dependency on python3-pypdf2.  Last 
January the following bug was filed against all packages using python3-pypdf2:

As noted in https://bugs.debian.org/1028559, upstream for the PyPDF2 Python 
module has moved to the "pypdf" namespace.

Correspondingly, there is a new python3-pypdf package in debian unstable.

The packages listed above all currently depend on (or recommend) PyPDF2, but 
probably should move to the updated version.  When all these bug reports are 
closed, we can consider removing the pypdf2 source package and python3-pypdf2 
from debian.

The migration should be relatively straightforward; much of the API remains the 
same, just under the "pypdf" module name instead of the "PyPDF2" module name.  
Where the API differs, the version of PyPDF2 currently in debian 
testing/unstable (2.12.1-3) emits a 
PendingDeprecationWarning wherever a piece of the API will break.

For example:

   foo.py:76: PendingDeprecationWarning: getObject is deprecated and will be 
removed in PyPDF2 3.0.0. Use get_object instead.

(PyPDF2 version 3.x is basically a terminal version of PyPDF2, and pypdf takes 
over from 3.1.x onward; PyPDF2 version 3.x will not enter debian, as it is an 
API break from 2.x, and pypdf 3.x supercedes it)

To transition a given package:

 - run tests with as complete coverage as possible and note the 
   PendingDeprecation warnings

 - for each warning, patch the upstream line as recommended

 - ensure that the tests pass without PendingDeprecationWarnings

 - convert from "PyPDF2" to "pypdf" on any import or scoped reference in
   python

 - update dependency indicators in upstream metadata annotations
   (e.g. pyproject.toml, setup.cfg, etc)

 - update dependency indicators in debian packaging (from python3-pypdf2
   to python3-pypdf).

 - run the tests again
 
I'm currently in the process of updating all these bugs with:

As we approach the first anniversary for this bug, an update:

I've recently adopted pypdf and pypdf2 into the Debian Python Team in response 
to an RFA for both packages.  As these are somewhat security sensitive packages 
(among my first acts after adopting the packages was to upload proposed updates 
for both to address minor security issues in Bookworm in the next point release 
- same bug in both), I do not think we should release pypdf2 in Trixie and have 
filed an RC bug to that effect.

If you want this package to be in Trixie, you will need to use pypdf instead of 
pypdf2.

Scott K

Bug#1049922: libslirp-dev: Ship a static library in libslirp-dev

[Renzo Davoli]

Dear Athos and Michael,

 Virtual Distributed Ethernet (VDE) is a set of tools that 
provide an
effective communication platform for virtual entities interoperability. [1][2]

The VDE project tools are available in Debian [3].

I am reimplementing slirpvde[4], porting it to libslirp.  The idea is to
release the new version also as a static binary, so I support Athos' request to
ship a static library in libslirp-dev.

Any news?

Thank you,

  renzo

[1] https://wiki.virtualsquare.org
[2] https://wiki.virtualsquare.org/#/tutorials/vdebasics
[3] https://qa.debian.org/developer.php?login=virtualsquare%40cs.unibo.it
[4] https://www.huge-man-linux.net/man1/slirpvde.html

Bug#1061260: ITP: aida-x -- Amp Model Player leveraging AI

[Dennis Braun]

Package: wnnp
Severity: wishlist
Owner: s...@debian.org

* Package name: aida-x
  Version : 1.0.0
  Upstream Author : Filipe Coelho 
* URL : https://github.com/AidaDSP/AIDA-X
* License : GPL-3+ and others
  Programming Lang: C++
  Description : AIDA-X is an Amp Model Player, allowing it to load models
of AI trained music gear, which you can then play through!

Its main intended use is to provide high fidelity simulations of amplifiers.
However, it is also possible to run entire signal chains consisting of any
combination of amp, cab, dist, drive, fuzz, boost and eq.

For ease of use, this plugin also contains a cabinet simulator via
impulsevresponse files, which runs after the Amp Model.

CLAP, LV2, VST2 and VST3 plugin formats are supported, plus a standalone.

I'm preparing this package in salsa, which is based on the version of kxstudio:
https://salsa.debian.org/multimedia-team/aida-x


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

Kernel: Linux 6.6.9-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

Bug#1061259: fbset: Move programs to /usr/bin

[Sven Joachim]

Package: fbset
Version: 2.1-33
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

Your package installs programs into /bin.  For the ongoing Debian
UsrMerge effort [1] these files should be relocated to /usr/bin in the
trixie cycle.

The simplest way to achieve that is probably to use the dh_movetousr
tool added in debhelper 13.11.7, see the attached patch.

Cheers,
   Sven


[1] https://wiki.debian.org/UsrMerge

From 4f14a04ac48d09e942ee25349862772c7e9448db Mon Sep 17 00:00:00 2001
From: Sven Joachim 
Date: Sun, 21 Jan 2024 17:37:15 +0100
Subject: [PATCH] Move binaries below /usr

The upstream Makefile installs binaries into /bin, in Debian trixie
and later they should be installed into /usr/bin instead.  Use the
dh_movetousr tool added in debhelper 13.11.7 to achieve that.

Adding dh-sequence-movetousr to Build-Depends is not strictly
necessary, but it helps with backports and ensures that dh_movetousr
is run in case debian/rules gets ever converted to dh.
---
 debian/control | 2 +-
 debian/rules   | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 91d1c9f..a53e199 100644
--- a/debian/control
+++ b/debian/control
@@ -7,7 +7,7 @@ Vcs-Browser: https://github.com/sudipm-mukherjee/fbset.git
 Vcs-Git: https://github.com/sudipm-mukherjee/fbset.git
 Standards-Version: 4.6.1.0
 Rules-Requires-Root: no
-Build-Depends: debhelper-compat (= 13), dpkg-dev (>= 1.15.7), flex, bison
+Build-Depends: debhelper-compat (= 13), dh-sequence-movetousr, dpkg-dev (>= 1.15.7), flex, bison

 Package: fbset
 Architecture: linux-any
diff --git a/debian/rules b/debian/rules
index 543d5f2..1d0a590 100755
--- a/debian/rules
+++ b/debian/rules
@@ -79,6 +79,7 @@ binary-arch: install-arch
 	dh_strip -a
 	dh_compress -a
 	dh_fixperms -a
+	dh_movetousr -a
 	dh_installdeb -a
 	dh_shlibdeps -a
 	dh_gencontrol -a
--
2.43.0

Bug#1061157: RFS: mini-httpd/1.30-7 -- Small HTTP server

[Alexandru Mihail]

> 
> Hi Alexandru,
> 
> Happy New Year!  I'll sponsor this one.
> 
Hello, Nicholas !
Happy New Year to you too ! I hope you had a great holiday with your
family and friends !

> In the future please use "reportbug sponsorship-requests" and enter
> my
> email at the "Enter any additional addresses this report should be
> sent
> to; press ENTER after each address. Press ENTER on a blank line to
> continue" step, because the method you use doesn't let the additional
> recipient[s] reply to the bug.  If you want to use another method,
> please add the following pseudoheader:
> 
>     X-Debbugs-Cc: additional@recipient addresses@list ie@me
> 
Sure, will do, thanks for the pointer !
I refrained from using it in the past because I couldn't get it to work
with GUI mail clients e.g Evolution/Thunderbird. It insisted on using
sendmail which, naturally, fails. It's surely a newbie error on my end.
> Gentle reminder not to push tags until the package has been accepted
> into the archive.  It would also be nice to see you use end
> punctuation
> again.
> 
I somehow forgot about that part of tag etiquette, thanks !
Regarding punctuation, it seems too much holiday cheer damaged my
grammar parser a bit... :D

> Cheers,
> Nicholas
Have a great one, thanks for the sponsorship (and past mentoring) !
Take care,
Alexandru


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

Bug#1044076: pandas 2.x

[Rebecca N. Palmer]

What, if anything, blocks the above fix from being applied now?

tqdm, influxdb-python and seaborn are the highest-popcon packages broken 
by pandas 2.x.

Bug#1034234: libpam-modules-bin: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Michael Biebl]

On Sun, 21 Jan 2024 11:45:43 + Luca Boccassi  wrote:

On Tue, 11 Apr 2023 09:37:27 +0200 bi...@debian.org wrote:



> This is not supported by the version of dh_installsystemd/debhelper
currently
> in unstable and bookworm (See: #1031695). That means that currently
your
> service might not be enabled at boot and/or started as expected.

dh_installsystemd can now handle files in /usr just fine, and the rest
of pam has been moved too, so I think this can be closed now.


What you can do (to src:pam in experimental), is to add a versioned 
Build-Depends on debhelper (>= 13.11.6).

It is the first version supporting unit files in /usr/lib/systemd

That said, it seems ok to close this bug report.

Regards,
Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061258: rpm: Cannot read old rpmdb

[Marek Marczykowski-Górecki]

Package: rpm
Version: 4.18.0+dfsg-1+b1
Severity: normal
X-Debbugs-Cc: marma...@invisiblethingslab.com

Dear Maintainer,

The RPM package in bookworm is not capable of loading old bdb rpmdb
format. This includes inability to convert it to the new sqlite format.
This is because bdb_ro backend is not enabled build-time. Quick check
how RPM is built in few rpm-using distros (Fedora, openSUSE) shows they
do enable bdb_ro backend, even if migrated to other backends (sqlite,
ndb) some time ago. The fix is trivial: add --enable-bdb-ro flag to the
configure call.
The issue does not apply to the rpm package in bullseye, so I'd call it
a regression.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

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

Kernel: Linux 6.1.62-1.qubes.fc32.x86_64 (SMP w/2 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 rpm depends on:
ii  debugedit 1:5.0-5
ii  libc6 2.36-9+deb12u3
ii  libelf1   0.188-2.1
ii  libpopt0  1.19+dfsg-1
ii  libreadline8  8.2-1.3
ii  librpm9   4.18.0+dfsg-1+b1
ii  librpmbuild9  4.18.0+dfsg-1+b1
ii  librpmio9 4.18.0+dfsg-1+b1
ii  librpmsign9   4.18.0+dfsg-1+b1
ii  perl  5.36.0-7+deb12u1
ii  rpm-common4.18.0+dfsg-1+b1
ii  rpm2cpio  4.18.0+dfsg-1+b1

rpm recommends no packages.

Versions of packages rpm suggests:
pn  alien 
pn  elfutils  
ii  python3   3.11.2-1+b1
pn  rpm-i18n  
pn  rpmlint   

-- no debconf information



signature.asc
Description: PGP signature

Bug#1059828: colourised crontab -l output is unreadable

[Georges Khaznadar]

Hello Stéphane,

I installed the package bat (debian testing).

- the command bat had been renamed to batcat to prevent a name clash
  with another package

- crontab is not among the supported languages :
  $ batcat --list-languages| grep -i cron
  ==> 

Is there some mean to restore the feature of bat, regarding crontabs?

Can users easily customize their color preferences with batcat?

Best regards,   Georges.

Stéphane Blondon a écrit :
> Hello everyone,
> 
> I understand the goal and the global strategy. It could be done with
> the `bat` package too.
> Based on the previous proposal, I show it below the Georges's steps.
> 
> Le jeu. 18 janv. 2024 à 09:29, Georges Khaznadar
>  a écrit :
> > [...] - modify the manpage crontab.1 to explain how to colourise the output 
> > of
> >   `crontab -l`; typically by issuing `crontab -l | spc -t crontab`,
> >   and explain shortly how one can customize at will the file which defines
> >   the coulourisation.
> > - let the package cron install one file for supercat,
> >   /etc/supercat/spcrc-crontab; I attach such a file to this e-mail, so
> >   Stéphane can copy it as ".spcrc-crontab", in order to see how the
> >   output of `crontab -l | spc -t crontab` looks like.
> > - add a recommendation from package cron to package supercat.
> 
> The `bat` package highlights several languages, including crontab. So
> it would be simpler because there is no need to add a specific file:
> $ crontab -l | bat --language Crontab
> 
> `-l` is usable instead of `--language`.
> 
> For my usage, I will set an alias:
> alias crontabl='crontab -l | bat --language Crontab'
> 
> 
> I'm not sure if adding a `recommends: supercat` is a good idea.
> Perhaps adding the ways to highlight crontab in manpage is enough ?
> 
> -- 
> Stéphane

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#1061257: fakeroot: missing renameat2 diversion

[Samuel Thibault]

Package: fakeroot
Version: 1.32.2-1+b1
Severity: important
Tags: patch upstream

Hello,

I couldn't find the upstream for fakeroot, so reporting here.

I was getting testsuite issues on hurd-amd64, the t.tar test would fail: 

13c13
< rw-r--r-- root/root 0 tar/1.file
---
> rw-r--r-- daemon/sys 0 tar/1.file
18c18
< rw-r--r-- root/root 0 tar/3.file
---
> rw-r--r-- daemon/sys 0 tar/3.file
20c20
< rw-r--r-- root/root 0 tar/5.file
---
> rw-r--r-- daemon/sys 0 tar/5.file
24c24
< rw-r--r-- root/root 0 tar/fjsdk.file
---
> rw-r--r-- daemon/sys 0 tar/fjsdk.file
35c35
< rw-r--r-- root/root 0 tar/vn.34.654l..file
---
> rw-r--r-- daemon/sys 0 tar/vn.34.654l..file

It seems like fakeroot is not catching file removals and the inode cache
gets confused. Indeed coreutils now uses renameat2, which fakeroot
doesn't divert yet. The attach patch implements that and indeed fixes
the test.

Samuel

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

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

Versions of packages fakeroot depends on:
ii  libc62.37-13
ii  libfakeroot  1.32.2-1+b1

fakeroot recommends no packages.

fakeroot suggests no packages.

-- no debconf information
Index: fakeroot-1.32.2/config.h.in
===
--- fakeroot-1.32.2.orig/config.h.in
+++ fakeroot-1.32.2/config.h.in
@@ -144,6 +144,9 @@
 /* Define to 1 if you have the `renameat' function. */
 #undef HAVE_RENAMEAT
 
+/* Define to 1 if you have the `renameat2' function. */
+#undef HAVE_RENAMEAT2
+
 /* have the semun union */
 #undef HAVE_SEMUN_DEF
 
Index: fakeroot-1.32.2/configure.ac
===
--- fakeroot-1.32.2.orig/configure.ac
+++ fakeroot-1.32.2/configure.ac
@@ -360,7 +360,7 @@ AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
   ],[ AC_MSG_RESULT([no])
   ])
 
-AC_CHECK_FUNCS(fchmodat fchownat fstatat mkdirat mknodat openat renameat 
unlinkat lchmod fgetattrlist)
+AC_CHECK_FUNCS(fchmodat fchownat fstatat mkdirat mknodat openat renameat 
renameat2 unlinkat lchmod fgetattrlist)
 
 save_LIBS="$LIBS"
 # Linux
Index: fakeroot-1.32.2/libfakeroot.c
===
--- fakeroot-1.32.2.orig/libfakeroot.c
+++ fakeroot-1.32.2/libfakeroot.c
@@ -1382,6 +1382,29 @@ int renameat(int olddir_fd, const char *
   return 0;
 }
 #endif /* HAVE_RENAMEAT */
+#ifdef HAVE_RENAMEAT2
+int renameat2(int olddir_fd, const char *oldpath,
+  int newdir_fd, const char *newpath, unsigned int flags){
+  int r,s;
+  INT_STRUCT_STAT st;
+
+  /* If newpath points to an existing file, that file will be
+ unlinked.   Make sure we tell the faked daemon about this! */
+
+  /* we need the st_new struct in order to inform faked about the
+ (possible) unlink of the file */
+
+  r=INT_NEXT_FSTATAT(newdir_fd, newpath, , AT_SYMLINK_NOFOLLOW);
+
+  s=next_renameat2(olddir_fd, oldpath, newdir_fd, newpath, flags);
+  if(s)
+return -1;
+  if(!r)
+INT_SEND_STAT(,unlink_func);
+
+  return 0;
+}
+#endif /* HAVE_RENAMEAT2 */
 #endif /* HAVE_FSTATAT */
 
 
Index: fakeroot-1.32.2/wrapfunc.inp
===
--- fakeroot-1.32.2.orig/wrapfunc.inp
+++ fakeroot-1.32.2/wrapfunc.inp
@@ -203,6 +203,9 @@ mkdirat;int;(int dir_fd, const char *pat
 #ifdef HAVE_RENAMEAT
 renameat;int;(int olddir_fd, const char *oldpath, int newdir_fd, const char 
*newpath);(olddir_fd, oldpath, newdir_fd, newpath)
 #endif /* HAVE_RENAMEAT */
+#ifdef HAVE_RENAMEAT2
+renameat2;int;(int olddir_fd, const char *oldpath, int newdir_fd, const char 
*newpath, unsigned int flags);(olddir_fd, oldpath, newdir_fd, newpath, flags)
+#endif /* HAVE_RENAMEAT2 */
 #ifdef HAVE_UNLINKAT
 unlinkat;int;(int dir_fd, const char *pathname, int flags);(dir_fd, pathname, 
flags)
 #endif /* HAVE_UNLINKAT */

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

[Chris Hofstaedtler]

On Fri, Jan 12, 2024 at 08:02:53PM +0100, Paul Gevers wrote:
> Hi,
> 
> On 12-01-2024 12:36, Chris Hofstaedtler wrote:
> > can you confirm two additional things please:
> > 
> > 1) this happens only on the large host?
> 
> https://ci.debian.net/packages/p/pdns/testing/s390x/41650331/
> 
> Seems it happens on our s390x host too (which has 10 debci workers running
> in parallel).
> 
> > 2) this does not or does happen with other packages also requesting
> > the same settings from systemd, e.g. dnsdist or pdns-recursor?
> 
> https://ci.debian.net/packages/d/dnsdist/ -> Page not found.
> 
> pdns-recursor seems to be flaky as well on amd64 and all passing tests were
> on one of the smaller hosts. pdns-recursor passes on s390x though.

For now I've added the exit 77 hack in the pdns tests, but this is
quite unsatisfying.

I've opened an issue with systemd upstream, maybe someone there has
any insight: https://github.com/systemd/systemd/issues/31037

Chris

Bug#1061071: transition: libcamera 0.2.0

[Sebastian Ramacher]

Control: tags -1 confirmed

Hi Dylan

On 2024-01-17 12:33:56 +0100, Dylan Aïssi wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> Control: affects -1 + src:libcamera
> 
> Dear Release Team,
> 
> Please schedule a transition slot for libcamera 0.2.0.

Please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1061061: transition: astc-encoder

[Sebastian Ramacher]

Control: tags -1 confirmed

Hi Timo

On 2024-01-17 09:16:19 +0100, Timo Röhling wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: astc-enco...@packages.debian.org
> Control: affects -1 + src:astc-encoder
> 
> 
> Dear release team,
> 
> I'd like to transition astc-encoder after a SONAME bump. There is only 
> one reverse dependency (filament), which builds fine against the new 
> version.

Please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1060704: transition: dcmtk

[Sebastian Ramacher]

Control: tags -1 moreinfo

Hi Mathieu

On 2024-01-13 11:47:40 +0100, Mathieu Malaterre wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> I'd like to migrate to dcmtk 3.6.8. This is a standard SONAME transition.

Are the reverse dependencies known to build with the new dcmtk version?

Cheers
-- 
Sebastian Ramacher

Bug#1060188: transition: flatbuffers

[Sebastian Ramacher]

Control: tags -1 confirmed

Hi

On 2024-01-07 01:11:24 -0500, M. Zhou wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: flatbuff...@packages.debian.org
> Control: affects -1 + src:flatbuffers
> 
> The flatbuffers version in unstable is rather old. I'd like to start
> the transition. All reverse dependencies can be built on amd64.
> 
> Note, the package list in transition tracker is not complete.
> I get the list by
> 
>for each binary package from src:flatbuffers:
>   build-rdeps package

Should those that are not part of the transition tracker use the shared
library or not?

Cheers
-- 
Sebastian Ramacher

Bug#1061256: edk2: CVE-2023-45229 CVE-2023-45230 CVE-2023-45231 CVE-2023-45232 CVE-2023-45233 CVE-2023-45234 CVE-2023-45235 CVE-2023-45236 CVE-2023-45237

[Salvatore Bonaccorso]

Source: edk2
Version: 2023.11-5
Severity: important
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for edk2.

CVE-2023-45229[0]:
| EDK2's Network Package is susceptible to an out-of-bounds read
| vulnerability when processing the IA_NA or IA_TA option in a DHCPv6
| Advertise message. This  vulnerability can be exploited by an
| attacker to gain unauthorized  access and potentially lead to a loss
| of Confidentiality.


CVE-2023-45230[1]:
| EDK2's Network Package is susceptible to a buffer overflow
| vulnerability via a long server ID option in DHCPv6 client. This
| vulnerability can be exploited by an attacker to gain unauthorized
| access and potentially lead to a loss of Confidentiality, Integrity
| and/or Availability.


CVE-2023-45231[2]:
| EDK2's Network Package is susceptible to an out-of-bounds read
| vulnerability when processing  Neighbor Discovery Redirect message.
| This  vulnerability can be exploited by an attacker to gain
| unauthorized  access and potentially lead to a loss of
| Confidentiality.


CVE-2023-45232[3]:
| EDK2's Network Package is susceptible to an infinite loop
| vulnerability when parsing unknown options in the Destination
| Options header of IPv6. This  vulnerability can be exploited by an
| attacker to gain unauthorized  access and potentially lead to a loss
| of Availability.


CVE-2023-45233[4]:
| EDK2's Network Package is susceptible to an infinite lop
| vulnerability when parsing a PadN option in the Destination Options
| header of IPv6. This  vulnerability can be exploited by an attacker
| to gain unauthorized  access and potentially lead to a loss of
| Availability.


CVE-2023-45234[5]:
| EDK2's Network Package is susceptible to a buffer overflow
| vulnerability when processing DNS Servers option from a DHCPv6
| Advertise message. This  vulnerability can be exploited by an
| attacker to gain unauthorized  access and potentially lead to a loss
| of Confidentiality, Integrity and/or Availability.


CVE-2023-45235[6]:
| EDK2's Network Package is susceptible to a buffer overflow
| vulnerability when  handling Server ID option  from a DHCPv6
| proxy Advertise message. This  vulnerability can be exploited by an
| attacker to gain unauthorized  access and potentially lead to a loss
| of Confidentiality, Integrity and/or Availability.


CVE-2023-45236[7]:
| EDK2's Network Package is susceptible to a predictable TCP Initial
| Sequence Number. This  vulnerability can be exploited by an attacker
| to gain unauthorized  access and potentially lead to a loss of
| Confidentiality.


CVE-2023-45237[8]:
| EDK2's Network Package is susceptible to a predictable TCP Initial
| Sequence Number. This  vulnerability can be exploited by an attacker
| to gain unauthorized  access and potentially lead to a loss of
| Confidentiality.

They are described in [9]. Dann, you know more on the fixes?


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-45229
https://www.cve.org/CVERecord?id=CVE-2023-45229
[1] https://security-tracker.debian.org/tracker/CVE-2023-45230
https://www.cve.org/CVERecord?id=CVE-2023-45230
[2] https://security-tracker.debian.org/tracker/CVE-2023-45231
https://www.cve.org/CVERecord?id=CVE-2023-45231
[3] https://security-tracker.debian.org/tracker/CVE-2023-45232
https://www.cve.org/CVERecord?id=CVE-2023-45232
[4] https://security-tracker.debian.org/tracker/CVE-2023-45233
https://www.cve.org/CVERecord?id=CVE-2023-45233
[5] https://security-tracker.debian.org/tracker/CVE-2023-45234
https://www.cve.org/CVERecord?id=CVE-2023-45234
[6] https://security-tracker.debian.org/tracker/CVE-2023-45235
https://www.cve.org/CVERecord?id=CVE-2023-45235
[7] https://security-tracker.debian.org/tracker/CVE-2023-45236
https://www.cve.org/CVERecord?id=CVE-2023-45236
[8] https://security-tracker.debian.org/tracker/CVE-2023-45237
https://www.cve.org/CVERecord?id=CVE-2023-45237
[9] 
https://blog.quarkslab.com/pixiefail-nine-vulnerabilities-in-tianocores-edk-ii-ipv6-network-stack.html

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1061250: gjs FTCBFS: cxx.run always fails cross compilation

[Simon McVittie]

On Sun, 21 Jan 2024 at 12:56:49 +0100, Helmut Grohne wrote:
> +if meson.is_cross_build()

In my experience, this function call is usually the wrong tool:
I think it would likely be more in line with what upstream wants if
it was based on "if not meson.can_run_host_binaries()", so that if we
happen to be able to run host binaries (via i386-on-amd64, binfmt_misc
or an explicitly configured EXE wrapper), the check will still be done.

Does cxx.run() work as though we were doing a native build if Meson is
run with a cross-file that configures an EXE wrapper, similar to
?
I hope that it will.

gjs is neither installable nor useful without GObject-Introspection, so
on any architecture where we would consider cross-compiling gjs, we almost
certainly already have qemu-user available.

> +warning('''This is a cross build. A check that a minimal
> +SpiderMonkey program executes will not be performed. Before shipping GJS, you
> +should check that it does not crash on startup, since building SpiderMonkey 
> with
> +the wrong configuration may cause that.''' + recommended_configuration)

This might still be a good idea even if an EXE wrapper is enough to
resolve the build failure, but I'd prefer to take this sort of thing
upstream rather than applying it unilaterally.

Thanks,
smcv

Bug#1060182: transition: simdjson

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2024-01-06 18:22:36 -0500, M. Zhou wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: simdj...@packages.debian.org
> Control: affects -1 + src:simdjson
> 
> Hi,
> 
> simdjson upstream bumped SOVERSION from 16 to 19 in the latest release.
> All reverse dependencies can be rebuilt against 19 on amd64.

Please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1060058: transition: tpm2-tss

[Sebastian Ramacher]

Control: tags -1 confirmed

Hi Ying-Chun

On 2024-01-05 20:14:15 +0800, Ying-Chun Liu (PaulLiu) wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: tpm2-...@packages.debian.org, paul...@debian.org
> Control: affects -1 + src:tpm2-tss
> 
> The upstream changes the API/ABI. So we need a transition.

Please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1051166: FTBFS with doxygen 1.9.8

[s3v]

Dear Maintainer,

After removing "-W" from [1], your package builds fine in a sid chroot
environment.
I guess is safe to stop treating sphinx warnings as errors.

Kind Regards

[1] https://sources.debian.org/src/breathe/4.35.0-2/documentation/Makefile/#L5

Bug#1040971: ITP: hyprland -- dynamic tiling Wayland compositor based on wlroots

[Alan M Varghese]

Package: wnpp
Followup-For: Bug #1040971
Owner: Alan M Varghese 
X-Debbugs-Cc: debian-de...@lists.debian.org, a...@digistorm.in


* Package name: hyprland
  Version : 0.34.0
  Upstream Contact: vaxerski  
* URL : https://github.com/hyprwm/Hyprland
* License : BSD-3-Clause
  Programming Lang: C++
  Description : dynamic tiling Wayland compositor based on wlroots

- From the readme:
"
Hyprland is a dynamic tiling Wayland compositor based on wlroots that doesn't
sacrifice on its looks.
It supports multiple layouts, fancy effects, has a very flexible IPC model
allowing for a lot of customization, a powerful plugin system and more.
"


Upstream for Hyprland provides a source tarball with all its submodules
packaged together. I intend to package them as-is and not separate out wlroots
(don't know if that would even be possible; a custom wlroots binary is built
and linked against during the build process).

Bug#1061255: ITP: custodian -- flexible just-in-time job management framework in Python

[Drew Parsons]

Package: wnpp
Severity: wishlist
Owner: Drew Parsons 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org, 
debian-scie...@lists.debian.org, debichem-de...@lists.alioth.debian.org

* Package name: custodian
  Version : 2024.1.9
  Upstream Contact: Shyue Ping Ong 
* URL : https://github.com/materialsproject/custodian
* License : MIT/X
  Programming Lang: Python
  Description : flexible just-in-time job management framework in Python

Custodian is a simple, robust and flexible just-in-time (JIT) job
management framework written in Python. Using custodian, you can
create wrappers that perform error checking, job management and error
recovery. It has a simple plugin framework that allows you to develop
specific job management workflows for different applications.

Error recovery is an important aspect of many high-throughput projects
that generate data on a large scale. When you are running on the order
of hundreds of thousands of jobs, even an error-rate of 1% would mean
thousands of errored jobs that would be impossible to deal with on a
case-by-case basis.

The specific use case for custodian is for long running jobs, with
potentially random errors. For example, there may be a script that
takes several days to run on a server, with a 1% chance of some IO
error causing the job to fail. Using custodian, one can develop a
mechanism to gracefully recover from the error, and restart the job
with modified parameters if necessary.

The current version of Custodian also comes with several sub-packages
for error handling for Vienna Ab Initio Simulation Package (VASP),
NwChem, QChem, FEFF, Lobster and CP2K calculations.


Custodian has been developed by the Materials Project team responsible
for pymatgen, and is used to manage tests for emmet-core etc.  It is a
general python package, but designed for computational chemistry. It
could arguably be managed by the Debian Python Team, but probably best
to keep it alongside pymatgen managed by the Debichem team.

Bug#1061254: dosfstools: please install into /usr (DEP17 M2)

[Chris Hofstaedtler]

Source: dosfstools
Version: 4.2-1

Hi,

we want to finish the move to /usr in trixie via DEP17. For this
dosfstools should move its /sbin-binaries into /usr/sbin.

I'll probably follow up with a patch soon.

Chris

Bug#1043240: transition: pandas 1.5 -> 2.1

[Rebecca N. Palmer]

Control: severity 1053943 1053939 1053942 1044053 1044056 serious
Control: severity 1044074 1053946 1044078 1044079 1044077 serious
Control: severity 1044071 1044067 1044068 1044055 1044060 serious
Control: severity 1044072 1044073 1044064 1053945 1044054 serious
Control: severity 1044076 1053940 1044057 1053944 1050144 serious

As previously discussed in this bug, I'd like to move pandas 2.x into 
unstable reasonably soon.  I'm aiming to get it in before the Ubuntu 
24.04 freeze (in about a month), but I am open to disagreement on 
whether this is a good idea.


dask, python-skbio and python-upsetplot have been fixed since the 
previous discussion, but that still leaves the above 25.  6 of these 
have a known-to-me fix (dials influxdb-python python-altair 
python-feather-format seaborn tqdm - see their bugs for details).


Hence, doing this transition now would involve breaking some reverse 
dependencies with no known fix, but given the number of packages 
involved, trying to wait until they're all fixed is rather likely to 
instead end in pandas 1.5 being broken by a new Python/numpy/etc.

Bug#1061249: clutter-gtk FTCBFS: fails running gtk-doc scanner

[Simon McVittie]

On Sat, 20 Jan 2024 at 22:49:18 +0100, Helmut Grohne wrote:
> clutter-gtk fails to cross build from source, because it fails running
> the gtk-doc scanner, which is a host architecture executable.

The changes look fine in principle, but clutter-gtk is dead upstream and
should ideally not be released in trixie at all, so this is unlikely to be
a particularly high priority for anyone to (test and) upload.

smcv

Bug#1057562: gcr4: FTBFS: failing tests

[Jeremy Bícha]

Control: severity -1 important

I believe the gcr tests are just flaky.

Thank you,
Jeremy Bícha

Bug#1059828: colourised crontab -l output is unreadable

[Stéphane Blondon]

Hello everyone,

I understand the goal and the global strategy. It could be done with
the `bat` package too.
Based on the previous proposal, I show it below the Georges's steps.

Le jeu. 18 janv. 2024 à 09:29, Georges Khaznadar
 a écrit :
> [...] - modify the manpage crontab.1 to explain how to colourise the output of
>   `crontab -l`; typically by issuing `crontab -l | spc -t crontab`,
>   and explain shortly how one can customize at will the file which defines
>   the coulourisation.
> - let the package cron install one file for supercat,
>   /etc/supercat/spcrc-crontab; I attach such a file to this e-mail, so
>   Stéphane can copy it as ".spcrc-crontab", in order to see how the
>   output of `crontab -l | spc -t crontab` looks like.
> - add a recommendation from package cron to package supercat.

The `bat` package highlights several languages, including crontab. So
it would be simpler because there is no need to add a specific file:
$ crontab -l | bat --language Crontab

`-l` is usable instead of `--language`.

For my usage, I will set an alias:
alias crontabl='crontab -l | bat --language Crontab'


I'm not sure if adding a `recommends: supercat` is a good idea.
Perhaps adding the ways to highlight crontab in manpage is enough ?

-- 
Stéphane

Bug#1059609: bookworm-pu: package engrampa/1.26.0-1+deb12u1

[Mike Gabriel]

Hi Adam,

On  Sa 20 Jan 2024 15:24:35 CET, Adam D. Barratt wrote:


Control: tags -1 + moreinfo

On Fri, 2023-12-29 at 08:25 +0100, Mike Gabriel wrote:

While upload a new upstream version of engrampa, a bookworm-pu has
been prepared that fixes various memleaks and resolves a bug in the
archive "save as" action.


The metadata for #969761 suggests that the bug affects the package in
unstable and is not yet resolved there. If that's correct, please apply
the update to unstable first; otherwise, please fix the metadata to
more accurately reflect the situation.


The correct engrampa 1.26.0-1+deb12u1 has now been uploaded (just now,  
so tumbling in within the next minutes/hours).


Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpykAvftTLf6.pgp
Description: Digitale PGP-Signatur

Bug#1061253: libreoffice-math: Keyboard only is a pain

[Nicolas Patrois]

Package: libreoffice-math
Version: 4:24.2.0~rc2-2
Severity: wishlist
Tags: upstream

Dear Maintainer,

With I create an equation, the keyboard focus is not in the below entry zone
but in the equation itself.
It creates truckloads of curly brackets, I don’t know why.
I must click in the entry zone below (as usual in version 7) to remove them and
to be able to edit the equation correctly.
Maybe the new equation editor’s paint is not dry yet?

Yours,
Nicolas


-- Package-specific info:
Configuration filePackage Exists Changed
/etc/libreoffice/registry/math.xcdlibreoffice-mathYes No
All deployed bundled extensions:

Identifier: com.sun.star.comp.Calc.NLPSolver
  Version: 0.9
  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/nlpsolver
  is registered: yes
  Media-Type: application/vnd.sun.star.package-bundle
  Description: Cette extension s'int\xe8gre \xe0 Calc et offre de nouveaux 
moteurs de solveur \xe0 utiliser pour optimiser les mod\xe8les de programmation 
non lin\xe9aires.

  bundled Packages: {
  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/nlpsolver/help
  is registered: yes
  Media-Type: application/vnd.sun.star.help
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/nlpsolver/components.rdb
  is registered: yes
  Media-Type: application/vnd.sun.star.uno-components
  Description: 

  }

Identifier: Dmaths
  Version: 4.4.0.0
  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/dmaths
  is registered: yes
  Media-Type: application/vnd.sun.star.package-bundle
  Description: DmathsAddon 
Copyright Didier Dorange-Pattoret (c) 2001-2017
Le logiciel Dmaths version 4.4.0.0

Apr\xe8s une premi\xe8re installation, FERMEZ et RELANCEZ compl\xe9tement 
LO/AOOo 
(apr\xe8s avoir ferm\xe9 le lanceur rapide).


Apr\xe8s une mise \xe0 jour,
\xe9crivez une formule 2/5 puis F10 (ou F8).

 

  bundled Packages: {
  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/dmaths/DmInstall/
  is registered: yes
  Media-Type: application/vnd.sun.star.basic-library
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/dmaths/CmathOOo/
  is registered: yes
  Media-Type: application/vnd.sun.star.basic-library
  Description: 

  URL: 
vnd.sun.star.expand:$BUNDLED_EXTENSIONS/dmaths/OOoAHmath3D/OOoAHmath3D/
  is registered: yes
  Media-Type: application/vnd.sun.star.basic-library
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/dmaths/OOoGdmath/OOoGdmath/
  is registered: yes
  Media-Type: application/vnd.sun.star.basic-library
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/dmaths/Dmaths2/
  is registered: yes
  Media-Type: application/vnd.sun.star.basic-library
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/dmaths/DmathsBup/
  is registered: yes
  Media-Type: application/vnd.sun.star.basic-library
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/dmaths/Dmaths/
  is registered: yes
  Media-Type: application/vnd.sun.star.basic-library
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/dmaths/Addons.xcu
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-data
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/dmaths/OOoAHmath3D/Addons.xcu
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-data
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/dmaths/OOoGdmath/addon.xcu
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-data
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/dmaths/Paths.xcu
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-data
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/dmaths/Accelerators.xcu
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-data
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/dmaths/WriterWindowState.xcu
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-data
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/dmaths/DrawWindowState.xcu
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-data
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/dmaths/ImpressWindowState.xcu
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-data
  Description: 

  }

Identifier: org.openoffice.da.writer2xhtml.oxt
  Version: 1.4
  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/writer2xhtml
  is registered: yes
  Media-Type: application/vnd.sun.star.package-bundle
  Description: Writer2xhtml permet d'exporter les documents Writer et Calc vers 
XHTML et XHTML+MathML
  bundled Packages: {
  URL: 

Bug#1061252: libreoffice-math: No more vertical alignement when embedded in a writer document

[Nicolas Patrois]

Package: libreoffice-math
Version: 4:24.2.0~rc2-2
Severity: normal
Tags: upstream

Dear Maintainer,

Maybe it’s a libreoffice-writer bug, I don’t know.
When I embed an equation in a writer document, I can’t align it vertically
anymore in the line where it’s embedded. The option is greyed in the position
tab and empty in the right-click menu.
I have not met this bug in version 7.

Yours,
nicolas


-- Package-specific info:
Configuration filePackage Exists Changed
/etc/libreoffice/registry/math.xcdlibreoffice-mathYes No
All deployed bundled extensions:

Identifier: com.sun.star.comp.Calc.NLPSolver
  Version: 0.9
  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/nlpsolver
  is registered: yes
  Media-Type: application/vnd.sun.star.package-bundle
  Description: Cette extension s'int\xe8gre \xe0 Calc et offre de nouveaux 
moteurs de solveur \xe0 utiliser pour optimiser les mod\xe8les de programmation 
non lin\xe9aires.

  bundled Packages: {
  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/nlpsolver/help
  is registered: yes
  Media-Type: application/vnd.sun.star.help
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/nlpsolver/components.rdb
  is registered: yes
  Media-Type: application/vnd.sun.star.uno-components
  Description: 

  }

Identifier: Dmaths
  Version: 4.4.0.0
  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/dmaths
  is registered: yes
  Media-Type: application/vnd.sun.star.package-bundle
  Description: DmathsAddon 
Copyright Didier Dorange-Pattoret (c) 2001-2017
Le logiciel Dmaths version 4.4.0.0

Apr\xe8s une premi\xe8re installation, FERMEZ et RELANCEZ compl\xe9tement 
LO/AOOo 
(apr\xe8s avoir ferm\xe9 le lanceur rapide).


Apr\xe8s une mise \xe0 jour,
\xe9crivez une formule 2/5 puis F10 (ou F8).

 

  bundled Packages: {
  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/dmaths/DmInstall/
  is registered: yes
  Media-Type: application/vnd.sun.star.basic-library
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/dmaths/CmathOOo/
  is registered: yes
  Media-Type: application/vnd.sun.star.basic-library
  Description: 

  URL: 
vnd.sun.star.expand:$BUNDLED_EXTENSIONS/dmaths/OOoAHmath3D/OOoAHmath3D/
  is registered: yes
  Media-Type: application/vnd.sun.star.basic-library
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/dmaths/OOoGdmath/OOoGdmath/
  is registered: yes
  Media-Type: application/vnd.sun.star.basic-library
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/dmaths/Dmaths2/
  is registered: yes
  Media-Type: application/vnd.sun.star.basic-library
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/dmaths/DmathsBup/
  is registered: yes
  Media-Type: application/vnd.sun.star.basic-library
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/dmaths/Dmaths/
  is registered: yes
  Media-Type: application/vnd.sun.star.basic-library
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/dmaths/Addons.xcu
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-data
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/dmaths/OOoAHmath3D/Addons.xcu
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-data
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/dmaths/OOoGdmath/addon.xcu
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-data
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/dmaths/Paths.xcu
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-data
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/dmaths/Accelerators.xcu
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-data
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/dmaths/WriterWindowState.xcu
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-data
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/dmaths/DrawWindowState.xcu
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-data
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/dmaths/ImpressWindowState.xcu
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-data
  Description: 

  }

Identifier: org.openoffice.da.writer2xhtml.oxt
  Version: 1.4
  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/writer2xhtml
  is registered: yes
  Media-Type: application/vnd.sun.star.package-bundle
  Description: Writer2xhtml permet d'exporter les documents Writer et Calc vers 
XHTML et XHTML+MathML
  bundled Packages: {
  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/writer2xhtml/help
  is registered: yes
  Media-Type: 

Bug#1061242: libreoffice-impress: impress cannot start. Its display an error loading a dll that is installed

[Rene Engelhard]

Hi,

oops.

Am 21.01.24 um 15:35 schrieb Rene Engelhard:
Here the new libxml2 removes functions and symbol versions used by 
gazillions of packages over the whole of the Debian archive.


And no, the exact point of Debian library package names is that they 
HAVE to change on ABI changes. Especially on a library like this which 
is used by virtually anything.


See https://www.debian.org/doc/debian-policy/ch-sharedlibs.h


https://www.debian.org/doc/debian-policy/ch-sharedlibs.html , obviously :)

Regards,

Rene