Bug#1069013: libbytesize: please remove extraneous dependency on python3-six

[Alexandre Detiste]

Source: libbytesize
Version: 2.10-1
Severity: normal

Dear Maintainer,

My patch has been accepted upstream,
please sync d/control.

Greetings


tchet@brix /tmp/libbytesize $ grep six -r
NEWS.rst:- remove dependency on python3-six and python2 crumbs
debian/control: python3-six
dist/libbytesize.spec.in:- remove dependency on python3-six and python2 crumbs 
(alexandre.detiste)
tchet@brix /tmp/libbytesize $

Bug#901071: Looks for a file named "-" in the current directory

[Jakub Wilk]

* Josh Triplett , 2018-06-08 09:51:
When invoked with stdin from a pipe, less looks for a file named "-" in 
the current directory.


This was fixed upstream in v509:
https://github.com/gwsw/less/commit/2195072f4676dc84

But a similar bug was reintroduced in v546:
https://github.com/gwsw/less/commit/128c1dfe9d01ca7c
https://github.com/gwsw/less/issues/289

It was finally fixed upstream in v616.

--
Jakub Wilk

Bug#1069010: upgrade to 5.73 breaks BT keyboard

[Harald Dunkel]

Package: bluetooth
Version: 5.73-1

The upgrade of bluetooth version 5.71 to 5.73-1 breaks BT keyboard.
journalctl shows the details before and after the upgrade and service
restart:


{root@lola:~ (local) 502} journalctl -u bluetooth -b
Apr 15 06:39:09 lola.afaics.de systemd[1]: Starting bluetooth.service - 
Bluetooth service...
Apr 15 06:39:09 lola.afaics.de (uetoothd)[927]: bluetooth.service: 
ConfigurationDirectory 'bluetooth' already exists but the mode is different. 
(File syst>
Apr 15 06:39:09 lola.afaics.de bluetoothd[927]: Bluetooth daemon 5.71
Apr 15 06:39:09 lola.afaics.de bluetoothd[927]: Starting SDP server
Apr 15 06:39:09 lola.afaics.de bluetoothd[927]: src/plugin.c:plugin_init() 
System does not support csip plugin
Apr 15 06:39:09 lola.afaics.de bluetoothd[927]: 
profiles/audio/micp.c:micp_init() D-Bus experimental not enabled
Apr 15 06:39:09 lola.afaics.de bluetoothd[927]: src/plugin.c:plugin_init() 
System does not support micp plugin
Apr 15 06:39:09 lola.afaics.de bluetoothd[927]: src/plugin.c:plugin_init() 
System does not support vcp plugin
Apr 15 06:39:09 lola.afaics.de bluetoothd[927]: src/plugin.c:plugin_init() 
System does not support mcp plugin
Apr 15 06:39:09 lola.afaics.de bluetoothd[927]: src/plugin.c:plugin_init() 
System does not support bass plugin
Apr 15 06:39:09 lola.afaics.de bluetoothd[927]: src/plugin.c:plugin_init() 
System does not support bap plugin
Apr 15 06:39:09 lola.afaics.de bluetoothd[927]: Bluetooth management interface 
1.22 initialized
Apr 15 06:39:09 lola.afaics.de systemd[1]: Started bluetooth.service - 
Bluetooth service.
Apr 15 06:39:10 lola.afaics.de bluetoothd[927]: Battery Provider Manager created
Apr 15 06:39:10 lola.afaics.de bluetoothd[927]: 
profiles/sap/server.c:sap_server_register() Sap driver initialization failed.
Apr 15 06:39:10 lola.afaics.de bluetoothd[927]: sap-server: Operation not 
permitted (1)
Apr 15 06:39:10 lola.afaics.de bluetoothd[927]: 
src/device.c:device_set_wake_support() Unable to set wake_support without RPA 
resolution
Apr 15 06:39:10 lola.afaics.de bluetoothd[927]: 
src/device.c:device_set_wake_support() Unable to set wake_support without RPA 
resolution
Apr 15 06:39:10 lola.afaics.de bluetoothd[927]: 
src/device.c:device_set_wake_support() Unable to set wake_support without RPA 
resolution
Apr 15 06:39:10 lola.afaics.de bluetoothd[927]: 
src/device.c:device_set_wake_support() Unable to set wake_support without RPA 
resolution
Apr 15 06:39:11 lola.afaics.de bluetoothd[927]: Authorization request for 
non-connected device!?
Apr 15 06:41:03 lola.afaics.de bluetoothd[927]: Terminating
Apr 15 06:41:03 lola.afaics.de systemd[1]: Stopping bluetooth.service - 
Bluetooth service...
Apr 15 06:41:03 lola.afaics.de bluetoothd[927]: Battery Provider Manager 
destroyed
Apr 15 06:41:03 lola.afaics.de bluetoothd[927]: Stopping SDP server
Apr 15 06:41:03 lola.afaics.de bluetoothd[927]: Exit
Apr 15 06:41:03 lola.afaics.de systemd[1]: bluetooth.service: Deactivated 
successfully.
Apr 15 06:41:03 lola.afaics.de systemd[1]: Stopped bluetooth.service - 
Bluetooth service.
Apr 15 06:41:03 lola.afaics.de systemd[1]: Starting bluetooth.service - 
Bluetooth service...
Apr 15 06:41:03 lola.afaics.de (uetoothd)[3003]: bluetooth.service: 
ConfigurationDirectory 'bluetooth' already exists but the mode is different. 
(File sys>
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: Bluetooth daemon 5.73
Apr 15 06:41:03 lola.afaics.de systemd[1]: Started bluetooth.service - 
Bluetooth service.
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: Starting SDP server
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: src/plugin.c:init_plugin() 
System does not support bap plugin
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: src/plugin.c:init_plugin() 
System does not support bass plugin
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: src/plugin.c:init_plugin() 
System does not support mcp plugin
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: src/plugin.c:init_plugin() 
System does not support vcp plugin
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: 
profiles/audio/micp.c:micp_init() D-Bus experimental not enabled
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: src/plugin.c:init_plugin() 
System does not support micp plugin
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: src/plugin.c:init_plugin() 
System does not support ccp plugin
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: src/plugin.c:init_plugin() 
System does not support csip plugin
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: Bluetooth management interface 
1.22 initialized
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: 
src/adapter.c:reset_adv_monitors_complete() Failed to reset Adv Monitors: 
Failed (0x03)
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: Battery Provider Manager 
created
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: 
profiles/sap/server.c:sap_server_register() Sap driver initialization failed.
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: sap-server: Operation not 

Bug#1069009: dub: hard-coded dependeny on pre-t64 libraries

[Sebastian Ramacher]

Source: dub
Version: 1.36.0-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

dub has a hard-coded dependency on libcurl3-gnutls | libcurl4. Both
packages were renamed as part of the time_t transition and the
dependency needs to be updated.

Cheers
-- 
Sebastian Ramacher

Bug#1069008: ITP: precice -- partitioned multi-physics simulations

[Gürkan Myczko]

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

* Package name: precice
  Version : 3.1.1
  Upstream Authors: People at Technical University of Munich and 
University of Stuttgart

  URL : https://github.com/precice/precice
* License : LGPL-3.0-or-later
  Description : partitioned multi-physics simulations
 This is a coupling library for partitioned multi-physics simulations,
 including, but not restricted to fluid-structure interaction and
 conjugate heat transfer simulations.

Science Team

Bug#1069007: ITP: graudit -- grep rough audit - source code auditing tool

[Gürkan Myczko]

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

* Package name: graudit
  Version : 3.6
  Upstream Authors: Eldar Marcussen
  URL : https://github.com/wireghoul/graudit
* License : GPL-3.0-or-later
  Description : grep rough audit - source code auditing tool
 This is a simple script and signature sets that allows you to find 
potential
 security flaws in source code using the GNU utility grep. It's 
comparable to
 other static analysis applications like RATS, SWAAT and flaw-finder 
while
 keeping the technical requirements to a minimum and being very 
flexible.


Security Team.

Bug#1069006: upgrade to 5.73 breaks BT keyboard

[Harald Dunkel]

Package: bluetooth
Version: 5.73-1

The upgrade of bluetooth version 5.71 to 5.73-1 breaks BT keyboard.
journalctl shows the details before and after the upgrade and service
restart:


{root@lola:~ (local) 502} journalctl -u bluetooth -b
Apr 15 06:39:09 lola.afaics.de systemd[1]: Starting bluetooth.service - 
Bluetooth service...
Apr 15 06:39:09 lola.afaics.de (uetoothd)[927]: bluetooth.service: 
ConfigurationDirectory 'bluetooth' already exists but the mode is different. (File 
syst>
Apr 15 06:39:09 lola.afaics.de bluetoothd[927]: Bluetooth daemon 5.71
Apr 15 06:39:09 lola.afaics.de bluetoothd[927]: Starting SDP server
Apr 15 06:39:09 lola.afaics.de bluetoothd[927]: src/plugin.c:plugin_init() 
System does not support csip plugin
Apr 15 06:39:09 lola.afaics.de bluetoothd[927]: 
profiles/audio/micp.c:micp_init() D-Bus experimental not enabled
Apr 15 06:39:09 lola.afaics.de bluetoothd[927]: src/plugin.c:plugin_init() 
System does not support micp plugin
Apr 15 06:39:09 lola.afaics.de bluetoothd[927]: src/plugin.c:plugin_init() 
System does not support vcp plugin
Apr 15 06:39:09 lola.afaics.de bluetoothd[927]: src/plugin.c:plugin_init() 
System does not support mcp plugin
Apr 15 06:39:09 lola.afaics.de bluetoothd[927]: src/plugin.c:plugin_init() 
System does not support bass plugin
Apr 15 06:39:09 lola.afaics.de bluetoothd[927]: src/plugin.c:plugin_init() 
System does not support bap plugin
Apr 15 06:39:09 lola.afaics.de bluetoothd[927]: Bluetooth management interface 
1.22 initialized
Apr 15 06:39:09 lola.afaics.de systemd[1]: Started bluetooth.service - 
Bluetooth service.
Apr 15 06:39:10 lola.afaics.de bluetoothd[927]: Battery Provider Manager created
Apr 15 06:39:10 lola.afaics.de bluetoothd[927]: 
profiles/sap/server.c:sap_server_register() Sap driver initialization failed.
Apr 15 06:39:10 lola.afaics.de bluetoothd[927]: sap-server: Operation not 
permitted (1)
Apr 15 06:39:10 lola.afaics.de bluetoothd[927]: 
src/device.c:device_set_wake_support() Unable to set wake_support without RPA 
resolution
Apr 15 06:39:10 lola.afaics.de bluetoothd[927]: 
src/device.c:device_set_wake_support() Unable to set wake_support without RPA 
resolution
Apr 15 06:39:10 lola.afaics.de bluetoothd[927]: 
src/device.c:device_set_wake_support() Unable to set wake_support without RPA 
resolution
Apr 15 06:39:10 lola.afaics.de bluetoothd[927]: 
src/device.c:device_set_wake_support() Unable to set wake_support without RPA 
resolution
Apr 15 06:39:11 lola.afaics.de bluetoothd[927]: Authorization request for 
non-connected device!?
Apr 15 06:41:03 lola.afaics.de bluetoothd[927]: Terminating
Apr 15 06:41:03 lola.afaics.de systemd[1]: Stopping bluetooth.service - 
Bluetooth service...
Apr 15 06:41:03 lola.afaics.de bluetoothd[927]: Battery Provider Manager 
destroyed
Apr 15 06:41:03 lola.afaics.de bluetoothd[927]: Stopping SDP server
Apr 15 06:41:03 lola.afaics.de bluetoothd[927]: Exit
Apr 15 06:41:03 lola.afaics.de systemd[1]: bluetooth.service: Deactivated 
successfully.
Apr 15 06:41:03 lola.afaics.de systemd[1]: Stopped bluetooth.service - 
Bluetooth service.
Apr 15 06:41:03 lola.afaics.de systemd[1]: Starting bluetooth.service - 
Bluetooth service...
Apr 15 06:41:03 lola.afaics.de (uetoothd)[3003]: bluetooth.service: 
ConfigurationDirectory 'bluetooth' already exists but the mode is different. (File 
sys>
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: Bluetooth daemon 5.73
Apr 15 06:41:03 lola.afaics.de systemd[1]: Started bluetooth.service - 
Bluetooth service.
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: Starting SDP server
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: src/plugin.c:init_plugin() 
System does not support bap plugin
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: src/plugin.c:init_plugin() 
System does not support bass plugin
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: src/plugin.c:init_plugin() 
System does not support mcp plugin
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: src/plugin.c:init_plugin() 
System does not support vcp plugin
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: 
profiles/audio/micp.c:micp_init() D-Bus experimental not enabled
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: src/plugin.c:init_plugin() 
System does not support micp plugin
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: src/plugin.c:init_plugin() 
System does not support ccp plugin
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: src/plugin.c:init_plugin() 
System does not support csip plugin
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: Bluetooth management interface 
1.22 initialized
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: 
src/adapter.c:reset_adv_monitors_complete() Failed to reset Adv Monitors: 
Failed (0x03)
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: Battery Provider Manager 
created
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: 
profiles/sap/server.c:sap_server_register() Sap driver initialization failed.
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: sap-server: Operation not 

Bug#1069005: upgrade to 5.73 breaks BT keyboard

[Harald Dunkel]

Package: bluetooth
Version: 5.73-1

The upgrade of bluetooth version 5.71 to 5.73-1 breaks BT keyboard.
journalctl shows the details before and after the upgrade and service
restart:


{root@lola:~ (local) 502} journalctl -u bluetooth -b
Apr 15 06:39:09 lola.afaics.de systemd[1]: Starting bluetooth.service - 
Bluetooth service...
Apr 15 06:39:09 lola.afaics.de (uetoothd)[927]: bluetooth.service: 
ConfigurationDirectory 'bluetooth' already exists but the mode is different. (File 
syst>
Apr 15 06:39:09 lola.afaics.de bluetoothd[927]: Bluetooth daemon 5.71
Apr 15 06:39:09 lola.afaics.de bluetoothd[927]: Starting SDP server
Apr 15 06:39:09 lola.afaics.de bluetoothd[927]: src/plugin.c:plugin_init() 
System does not support csip plugin
Apr 15 06:39:09 lola.afaics.de bluetoothd[927]: 
profiles/audio/micp.c:micp_init() D-Bus experimental not enabled
Apr 15 06:39:09 lola.afaics.de bluetoothd[927]: src/plugin.c:plugin_init() 
System does not support micp plugin
Apr 15 06:39:09 lola.afaics.de bluetoothd[927]: src/plugin.c:plugin_init() 
System does not support vcp plugin
Apr 15 06:39:09 lola.afaics.de bluetoothd[927]: src/plugin.c:plugin_init() 
System does not support mcp plugin
Apr 15 06:39:09 lola.afaics.de bluetoothd[927]: src/plugin.c:plugin_init() 
System does not support bass plugin
Apr 15 06:39:09 lola.afaics.de bluetoothd[927]: src/plugin.c:plugin_init() 
System does not support bap plugin
Apr 15 06:39:09 lola.afaics.de bluetoothd[927]: Bluetooth management interface 
1.22 initialized
Apr 15 06:39:09 lola.afaics.de systemd[1]: Started bluetooth.service - 
Bluetooth service.
Apr 15 06:39:10 lola.afaics.de bluetoothd[927]: Battery Provider Manager created
Apr 15 06:39:10 lola.afaics.de bluetoothd[927]: 
profiles/sap/server.c:sap_server_register() Sap driver initialization failed.
Apr 15 06:39:10 lola.afaics.de bluetoothd[927]: sap-server: Operation not 
permitted (1)
Apr 15 06:39:10 lola.afaics.de bluetoothd[927]: 
src/device.c:device_set_wake_support() Unable to set wake_support without RPA 
resolution
Apr 15 06:39:10 lola.afaics.de bluetoothd[927]: 
src/device.c:device_set_wake_support() Unable to set wake_support without RPA 
resolution
Apr 15 06:39:10 lola.afaics.de bluetoothd[927]: 
src/device.c:device_set_wake_support() Unable to set wake_support without RPA 
resolution
Apr 15 06:39:10 lola.afaics.de bluetoothd[927]: 
src/device.c:device_set_wake_support() Unable to set wake_support without RPA 
resolution
Apr 15 06:39:11 lola.afaics.de bluetoothd[927]: Authorization request for 
non-connected device!?
Apr 15 06:41:03 lola.afaics.de bluetoothd[927]: Terminating
Apr 15 06:41:03 lola.afaics.de systemd[1]: Stopping bluetooth.service - 
Bluetooth service...
Apr 15 06:41:03 lola.afaics.de bluetoothd[927]: Battery Provider Manager 
destroyed
Apr 15 06:41:03 lola.afaics.de bluetoothd[927]: Stopping SDP server
Apr 15 06:41:03 lola.afaics.de bluetoothd[927]: Exit
Apr 15 06:41:03 lola.afaics.de systemd[1]: bluetooth.service: Deactivated 
successfully.
Apr 15 06:41:03 lola.afaics.de systemd[1]: Stopped bluetooth.service - 
Bluetooth service.
Apr 15 06:41:03 lola.afaics.de systemd[1]: Starting bluetooth.service - 
Bluetooth service...
Apr 15 06:41:03 lola.afaics.de (uetoothd)[3003]: bluetooth.service: 
ConfigurationDirectory 'bluetooth' already exists but the mode is different. (File 
sys>
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: Bluetooth daemon 5.73
Apr 15 06:41:03 lola.afaics.de systemd[1]: Started bluetooth.service - 
Bluetooth service.
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: Starting SDP server
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: src/plugin.c:init_plugin() 
System does not support bap plugin
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: src/plugin.c:init_plugin() 
System does not support bass plugin
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: src/plugin.c:init_plugin() 
System does not support mcp plugin
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: src/plugin.c:init_plugin() 
System does not support vcp plugin
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: 
profiles/audio/micp.c:micp_init() D-Bus experimental not enabled
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: src/plugin.c:init_plugin() 
System does not support micp plugin
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: src/plugin.c:init_plugin() 
System does not support ccp plugin
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: src/plugin.c:init_plugin() 
System does not support csip plugin
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: Bluetooth management interface 
1.22 initialized
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: 
src/adapter.c:reset_adv_monitors_complete() Failed to reset Adv Monitors: 
Failed (0x03)
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: Battery Provider Manager 
created
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: 
profiles/sap/server.c:sap_server_register() Sap driver initialization failed.
Apr 15 06:41:03 lola.afaics.de bluetoothd[3003]: sap-server: Operation not 

Bug#1069004: casacore-data-services: Hard coded build-depends on decrufted lib libcasa-meas7

[Scott Kitterman]

Package: casacore-data-services
Version: 2-4
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Will now FTBFS due to missing build-depends.

Scott K

Bug#1057586: nvda2speechd: FTBFS: error: failed to run custom build command for `speech-dispatcher-sys v0.7.0`

[Sebastian Ramacher]

On 2024-04-14 14:19:18 +0200, Santiago Vila wrote:
> El 14/4/24 a las 13:25, Sylvestre Ledru escribió:
> > I am sorry but I am not sure to see how it is actionable.
> > 
> > Without a test case, i don't think there is much I can do here.
> 
> The test case is that nvda2speechd fails to build from source.
> > With rust, cargo, custom build script, there are many things that can go 
> > wrong before LLVM.
> > 
> > Sebastian, I think it could be move to normal. From LLVM perspective, it 
> > isn't serious severity (many programs are built with LLVM 16).
> 
> We can release trixie with compilers having bugs, but I don't think it would 
> be ok at
> all to release trixie as stable with packages which do not build from source, 
> that would
> be against Release Policy.
> 
> So, in my opinion, this is still RC, either in the compiler or in the package 
> failing
> to build. If solving this in the compiler is too complex, then the bug should 
> be reassigned back to src:nvda2speechd.

Given that nvda2speechd downloads rust and plenty of crates during the
build, it will have to prevent odd interactions with the system provided
LLVM. Let's keep this as RC bug against nvda2speechd.

Cheers
-- 
Sebastian Ramacher

Bug#1036596: python3-lldb-14: broken symlinks: /usr/lib/llvm-14/lib/python3/dist-packages/lldb/libLLVM-14.so.1 etc.

[Sebastian Ramacher]

Hi Sylvestre

On 2024-04-14 13:31:01 +0200, Sylvestre Ledru wrote:
> Hello
> 
> Sorry for my lack of answer.
> 
> LLVM 14 was already deprecated when this bug has been filed. I don't think
> we should spend much time on this issue.

Note that this issue also affects stable where llvm 14 is the default
version.

Cheers

> 
> llvm 14 removal is #1050069
> 
> Cheers,
> S
> 
> Le 23/05/2023 à 09:51, Andreas Beckmann a écrit :
> > Package: python3-lldb-14
> > Version: 1:14.0.6-12
> > Severity: serious
> > User: debian...@lists.debian.org
> > Usertags: piuparts
> > 
> > Hi,
> > 
> > during a test with piuparts I noticed your package ships (or creates)
> > broken symlinks:
> > 
> > 0m35.0s ERROR: FAIL: Broken symlinks:
> >
> > /usr/lib/llvm-14/lib/python3.11/dist-packages/lldb/_lldb.cpython-311-x86_64-linux-gnu.so
> >  -> ../../../../../lib/liblldb.so (python3-lldb-14)
> >/usr/lib/llvm-14/lib/python3.11/dist-packages/lldb/lldb-argdumper -> 
> > ../../../../../bin/lldb-argdumper (python3-lldb-14)
> >/usr/lib/llvm-14/lib/python3/dist-packages/lldb/libLLVM-14.0.6.so.1 -> 
> > ../../../../../x86_64-linux-gnu/libLLVM-14.0.6.so.1 (python3-lldb-14)
> >/usr/lib/llvm-14/lib/python3/dist-packages/lldb/libLLVM-14.so.1 -> 
> > ../../../../../x86_64-linux-gnu/libLLVM-14.0.6.so.1 (python3-lldb-14)
> > 
> > Possible target replacements are
> >liblldb.so: /usr/lib/llvm-14/lib/python3/dist-packages/lldb/_lldb.so
> >libLLVM-14.0.6.so.1: /usr/lib//libLLVM-14.so.1
> >lldb-argdumper: /usr/lib/llvm-14/bin/lldb-argdumper
> >  (there is currently one level of '..' too much)
> > 
> > 
> > cheers,
> > 
> > Andreas
> > 

-- 
Sebastian Ramacher

Bug#1069003: visualvm: please update to visualvm 2.1.8 to support Java 21 and 22

[Vladimir Petko]

Source: visualvm
Version: 2.1.6-1
Severity: wishlist

Dear Maintainer,

Would it be possible to package visualvm 2.1.8 to enable support of Java 21 and
22?

Best Regards,
 Vladimir.


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

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

Bug#1069002: purelibc: please add support for loong64

[wuruilong]

Source: purelibc
Severity: normal
X-Debbugs-Cc: wuruil...@loongson.cn

Dear Maintainer,

purelibc failed to compile on loongarch, upstream has added support for 
loongarch, 
please refer to the attached patch or upgrade the software version to solve the 
problem. 
The link to the upstream commit code is as follows: 
https://github.com/virtualsquare/purelibc/commit/6df6bd54f40205e4a79115f49ad01dd080d5886c
https://github.com/virtualsquare/purelibc/commit/4d22452b569b5aa47ec44d8f66d1e36c8e0fcd45
https://github.com/virtualsquare/purelibc/commit/278dac7ea75df7df561daaec4c2ad746cbed901c

wuruilong

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

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
>From 6df6bd54f40205e4a79115f49ad01dd080d5886c Mon Sep 17 00:00:00 2001
From: Renzo Davoli 
Date: Tue, 3 Oct 2023 11:58:04 +0200
Subject: [PATCH 1/3] syscall: support archs without fstat

---
 syscalls.c | 42 --
 1 file changed, 32 insertions(+), 10 deletions(-)

diff --git a/syscalls.c b/syscalls.c
index cf5e4c7..fea7463 100644
--- a/syscalls.c
+++ b/syscalls.c
@@ -213,13 +213,19 @@ int dup3(int oldfd, int newfd, int flags){
 
 #if __WORDSIZE == 64 || defined(__ILP32__)
 # if defined(__NR_FSTATAT64) && ! defined(__NR_stat)
-#  define __USE_FSTATAT64
+#  define __USE_NEWSTAT64_STAT
+# endif
+# if defined(__NR_FSTATAT64) && ! defined(__NR_fstat)
+#  define __USE_NEWSTAT64_FSTAT
 # endif
 #  define arch_stat64 stat
 #  define IFNOT64(x)
 #else
 # if defined(__NR_FSTATAT64) && ! defined(__NR_stat64)
-#  define __USE_FSTATAT64
+#  define __USE_NEWSTAT64_STAT
+# endif
+# if defined(__NR_FSTATAT64) && ! defined(__NR_fstat64)
+#  define __USE_NEWSTAT64_FSTAT
 # endif
 #  define arch_stat64 stat64
 #  define IFNOT64(x) x
@@ -256,7 +262,7 @@ int stat(const char* pathname, struct stat* buf_stat)
IFNOT64(struct stat64 *buf_stat64 = alloca(sizeof(struct stat64)));
int rv;
 
-#ifdef __USE_FSTATAT64
+#ifdef __USE_NEWSTAT64_STAT
rv = _pure_syscall(__NR_FSTATAT64, AT_FDCWD, pathname, MAKE_NAME(buf_, 
arch_stat64), 0);
 #else
rv = _pure_syscall(MAKE_NAME(__NR_, arch_stat64), pathname, 
MAKE_NAME(buf_, arch_stat64));
@@ -272,7 +278,7 @@ int lstat(const char* pathname, struct stat* buf_stat)
IFNOT64(struct stat64 *buf_stat64 = alloca(sizeof(struct stat64)));
int rv;
 
-#ifdef __USE_FSTATAT64
+#ifdef __USE_NEWSTAT64_STAT
rv = _pure_syscall(__NR_FSTATAT64, AT_FDCWD, pathname, MAKE_NAME(buf_, 
arch_stat64), AT_SYMLINK_NOFOLLOW);
 #else
rv = _pure_syscall(MAKE_NAME(__NR_l, arch_stat64), pathname, 
MAKE_NAME(buf_, arch_stat64));
@@ -287,7 +293,11 @@ int fstat(int fildes, struct stat* buf_stat)
 {
IFNOT64(struct stat64 *buf_stat64 = alloca(sizeof(struct stat64)));
int rv;
+#ifdef __USE_NEWSTAT64_FSTAT
+   rv = _pure_syscall(__NR_FSTATAT64, fildes, "", MAKE_NAME(buf_, 
arch_stat64), AT_EMPTY_PATH);
+#else
rv = _pure_syscall(MAKE_NAME(__NR_f, arch_stat64), fildes, 
MAKE_NAME(buf_, arch_stat64));
+#endif
if (rv >= 0)
arch_stat64_2_stat(MAKE_NAME(buf_, arch_stat64), buf_stat);
 
@@ -295,7 +305,7 @@ int fstat(int fildes, struct stat* buf_stat)
 }
 
 int stat64(const char* pathname,struct stat64* buf){
-#ifdef __USE_FSTATAT64
+#ifdef __USE_NEWSTAT64_STAT
return _pure_syscall(__NR_FSTATAT64, AT_FDCWD, pathname, buf, 0);
 #else
return _pure_syscall(MAKE_NAME(__NR_, arch_stat64), pathname, buf);
@@ -303,7 +313,7 @@ int stat64(const char* pathname,struct stat64* buf){
 }
 
 int lstat64(const char* pathname,struct stat64* buf){
-#ifdef __USE_FSTATAT64
+#ifdef __USE_NEWSTAT64_STAT
   return _pure_syscall(__NR_FSTATAT64, AT_FDCWD, pathname, buf, 
AT_SYMLINK_NOFOLLOW);
 #else
   return _pure_syscall(MAKE_NAME(__NR_l, arch_stat64), pathname, buf);
@@ -311,7 +321,11 @@ int lstat64(const char* pathname,struct stat64* buf){
 }
 
 int fstat64 (int fildes, struct stat64 *buf){
+#ifdef __USE_NEWSTAT64_FTAT
+  return _pure_syscall(__NR_FSTATAT64, fildes, "", buf, AT_EMPTY_PATH);
+#else
   return _pure_syscall(MAKE_NAME(__NR_f, arch_stat64), fildes, buf);
+#endif
 }
 
 int mknod(const char *pathname, mode_t mode, dev_t dev) {
@@ -331,7 +345,7 @@ int __xstat(int ver, const char* pathname, struct stat* 
buf_stat)
switch(ver)
{
case _STAT_VER_LINUX:
-#ifdef __USE_FSTATAT64
+#ifdef __USE_NEWSTAT64_STAT
rv = _pure_syscall(__NR_FSTATAT64, AT_FDCWD, pathname, 
MAKE_NAME(buf_, arch_stat64), 0);
 #else
rv = _pure_syscall(MAKE_NAME(__NR_, arch_stat64), 
pathname, MAKE_NAME(buf_, arch_stat64));
@@ -357,7 +371,7 @@ int 

Bug#1069001: dgit: tag2upload: [dgit ...] should include source= and version= fields

[Sean Whitton]

Source: dgit
Version: 11.8
Severity: important

Dear maintainer,

As discussed elsewhere, we want source= and version= tags in the
tag2upload metadata to prevent the possibility of a certain form of
attack by someone who is able to replace git objects on salsa.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1069000: secrets: Adding an entry appears to corrupt the database, causing auth to fail on next invocation

[John Darrah]

Package: secrets
Version: 9.3-1
Severity: normal

Dear Maintainer,

I added three new entries to the database and then exited
as normal. There was no indication of any issues until I
tried to re-open the database. I entered my pass phrase as
normal and it informed me that the auth had failed. I tried
several more times thinking I mistyped something. I then
selected the "view pass" button to verify that it was
correct, which it was, but it still failed.

I then pulled an old version of the database from backup and
opened it with no issue. I added and entry, saved and
exited, then attempted to re-open but it failed auth again.

I copied a BAD version of the database to a Windows machine
with the latest version of KeepPass installed. It also fails
to auth the pass phrase. From this I must assume that
something is corrupting the file when saving.


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

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

Versions of packages secrets depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4+b1
ii  gir1.2-adw-1 1.5~beta-1
ii  gir1.2-gtk-4.0   4.12.5+ds-3
ii  python3  3.11.6-1
ii  python3-gi   3.47.0-3
ii  python3-pwquality1.4.5-3
ii  python3-pykcs11  1.5.14-1
ii  python3-pykeepass4.0.7-2
ii  python3-pyotp2.9.0-2
ii  python3-validators   0.20.0-2
ii  python3-yubico   1.3.3-0.3
ii  python3-zxcvbn   4.4.28-3

secrets recommends no packages.

secrets suggests no packages.

-- no debconf information

-- Journalctl Log Entries Follow

Apr 08 18:27:28 nyx org.gnome.World.Secrets.desktop[60919]: 08-04-24
18:27:28 | ERROR | Could not unlock safe
Apr 08 18:27:28 nyx org.gnome.World.Secrets.desktop[60919]: Traceback (most
recent call last):
Apr 08 18:27:28 nyx org.gnome.World.Secrets.desktop[60919]:   File
"/usr/lib/python3/dist-packages/gsecrets/unlock_database.py", line 156, in
_unlock_callback
Apr 08 18:27:28 nyx org.gnome.World.Secrets.desktop[60919]:
database_manager.unlock_finish(result)
Apr 08 18:27:28 nyx org.gnome.World.Secrets.desktop[60919]:   File
"/usr/lib/python3/dist-packages/gsecrets/database_manager.py", line 123, in
unlock_finish
Apr 08 18:27:28 nyx org.gnome.World.Secrets.desktop[60919]: _success,
db = result.propagate_value()
Apr 08 18:27:28 nyx
org.gnome.World.Secrets.desktop[60919]:

Apr 08 18:27:28 nyx org.gnome.World.Secrets.desktop[60919]:
gi.repository.GLib.GError: secrets: Invalid credentials (1)
Apr 08 18:27:52 nyx org.gnome.World.Secrets.desktop[60919]: 08-04-24
18:27:52 | ERROR | Could not unlock safe
Apr 08 18:27:52 nyx org.gnome.World.Secrets.desktop[60919]: Traceback (most
recent call last):
Apr 08 18:27:52 nyx org.gnome.World.Secrets.desktop[60919]:   File
"/usr/lib/python3/dist-packages/gsecrets/unlock_database.py", line 156, in
_unlock_callback
Apr 08 18:27:52 nyx org.gnome.World.Secrets.desktop[60919]:
database_manager.unlock_finish(result)
Apr 08 18:27:52 nyx org.gnome.World.Secrets.desktop[60919]:   File
"/usr/lib/python3/dist-packages/gsecrets/database_manager.py", line 123, in
unlock_finish
Apr 08 18:27:52 nyx org.gnome.World.Secrets.desktop[60919]: _success,
db = result.propagate_value()
Apr 08 18:27:52 nyx
org.gnome.World.Secrets.desktop[60919]:

Apr 08 18:27:52 nyx org.gnome.World.Secrets.desktop[60919]:
gi.repository.GLib.GError: secrets: Invalid credentials (1)

Bug#1066355: spotlighter: FTBFS: spotlighter.c:105:3: error: implicit declaration of function ‘on_window_screen_changed’ [-Werror=implicit-function-declaration]

[Vladimir Petko]

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

Dear Maintainer,

Would it be possible to consider the attached patch as the solution for the
issue?

In Ubuntu, the attached patch was applied to achieve the following:

  * d/p/2_ftbfs_implicit_declaration.patch: declare callback to
resolve -Werror=implicit-function-declaration ftbfs (LP: #2061331).


Thanks for considering the patch.


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

Kernel: Linux 6.5.0-27-generic (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru spotlighter-0.3/debian/patches/02_ftbfs_implicit_declaration.patch 
spotlighter-0.3/debian/patches/02_ftbfs_implicit_declaration.patch
--- spotlighter-0.3/debian/patches/02_ftbfs_implicit_declaration.patch  
1970-01-01 12:00:00.0 +1200
+++ spotlighter-0.3/debian/patches/02_ftbfs_implicit_declaration.patch  
2024-04-15 10:55:20.0 +1200
@@ -0,0 +1,18 @@
+Description: add callback declaration
+ Add callback declaration to resolve -Werror=implicit-function-declaration.
+Author: Vladimir Petko 
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066355
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/spotlighter/+bug/2061331
+Forwarded: no
+Last-Update: 2024-04-15
+
+--- a/src/callbacks.h
 b/src/callbacks.h
+@@ -33,3 +33,7 @@
+  gpointerdata);
+
+
++G_MODULE_EXPORT void
++on_window_screen_changed   (GtkWidget  *widget,
++GdkScreen  *previous_screen,
++gpointeruser_data);
diff -Nru spotlighter-0.3/debian/patches/series 
spotlighter-0.3/debian/patches/series
--- spotlighter-0.3/debian/patches/series   2024-04-01 21:03:10.0 
+1300
+++ spotlighter-0.3/debian/patches/series   2024-04-15 10:55:20.0 
+1200
@@ -1,3 +1,4 @@
 00_desktop.patch
 01_ftbfs_mips.patch
 no_AM_PATH_GTK_3_0.diff
+02_ftbfs_implicit_declaration.patch

Bug#1066873: RFS: tracy/0.10+ds-1 [ITP] -- Hybrid frame and sampling profiler

[Alan M Varghese]

> But this also means you haven't tried building your package


in a minimal sid chroot

I have been using podman containers based on sid instead. But, I think that
should be fine?

> Manually on a host system? `apt build-dep` or `mk-build-deps -ir`

> Recommends are not installed when installing build-deps

Ah... Makes sense. Thank you. I missed these commands somehow; I have

been running the `apt install` command for getting the dependencies inside

the container.


I will update the package with lmodern also added as a dependency.

Bug#1054403: python3-plotly: Does not draw waterfall charts

[Josue Ortega]

Hey,
Thanks for reporging this. I've tried to reproduce the 
issue using plotly 5.20.0+dfsg-1. (I uploaded to unstable this version today)
However, I was able to create a waterfall chart with the snipped you have 
shared.
(See the attached screenshot)

Could you verify if you're able to render the waterfall chart in this version?

Thanks!

---
Josue Ortega
«Happy Hacking»


signature.asc
Description: PGP signature

Bug#1019438: (No Subject)

[mYnDstrEAm]

Control: reassign -1 kde-plasma-desktop [5:142]

This problem still exists in Debian12 with Wayland. It only works with the VLC 
player where I can use the preview to change tracks but it doesn't work for 
apps like Dolphin, konsole, firefox, Discover and so on.

I checked and there is this output when hovering over the panel item:

> file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/PipeWireThumbnail.qml:11:1:
>  module "org.kde.pipewire" is not installed

Do I need to install or configure anything for this to work?

Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs

[James Addison]

Hi Holger,

On Sun, 14 Apr 2024 22:40:36 +0200, Holger wrote:
> I forgot to mention, that I have pushed a release-notes variant with this
theme to
> https://people.debian.org/~holgerw/new-rtd-sphinx-theme-for-debian/release-notes/release-notes/index.en.html
> (English)
>
> https://people.debian.org/~holgerw/new-rtd-sphinx-theme-for-debian/release-notes/release-notes/index.de.html
> (German)
>
> https://people.debian.org/~holgerw/new-rtd-sphinx-theme-for-debian/release-notes/release-notes/index.ca.html
> (Catalan)

>From some testing of these: the search results have a problem that they
hyperlink to a language-less .html URL, meaning that clicking a result link in
the DE-language search results takes the user to a EN-language page.

The _other_ hyperlinks in the static content are replaced as part of the
cronjob[1] - but that doesn't work for items in the searchindex.js file.

Fortunately I think there might be a better way to do this.  Sphinx itself has
an HTML builder option 'html_file_suffix' and I think we could use that instead
to define the filenames.  That option is respected by the search JavaScript
using a template variable[3] in the documentation_options.js file.

We should be careful of other side-effects if making that change, but it
would remove a deployment transformation step on the static content, and I
think that's beneficial.

[1] - 
https://salsa.debian.org/webmaster-team/cron/-/blob/3462a061d0a67dce3761b0f4d9357c017ad0a50b/parts/7release-notes#L64-70

[2] - 
https://www.sphinx-doc.org/en/master/usage/configuration.html#confval-html_file_suffix

[3] - 
https://github.com/sphinx-doc/sphinx/blob/cf7d2759af0852d67288e58d823d51fe860749ca/sphinx/themes/basic/static/documentation_options.js_t#L6

Bug#1068849: cryptsetup: Fails to unlock the filesystem with missing libgcc_s.so.1

[Guilhem Moulin]

Control: reopen -1
Control: tag -1 - unreproducible moreinfo

On Sun, 14 Apr 2024 at 21:26:25 +0200, Guilhem Moulin wrote:
> At this point something triggered rebuilding a new initramfs image, but
> that's not src:cryptsetup as none of its binary packages have been
> upgraded yet.

On second thought that was likely incorrect.  The log doesn't show
anything from src:cryptsetup but likely cryptsetup-initramfs was already
upgraded at that point while libcryptsetup12 wasn't.

The package dependency constraints are indeed not strict enough.
cryptsetup-initramfs now assumes neither cryptsetup(8) nor
libcryptsetup.so.12 are linked with libargon2, but since no new symbols
were added in 2.7.2 cryptsetup-bin only has Depends: libcryptsetup12 (>=
2:2.7), and it's therefore possible to upgrade cryptsetup-initramfs
while keeping the old libcryptsetup12.

Upgrading from testing (2:2.6.1-6) works thanks to the Depends:
libcryptsetup12 (>= 2:2.7), but upgrading from ≥2:2.7~, <2:2.7.2-1 may
yield a broken initramfs image if libcryptsetup12 is not upgraded before
cryptsetup-initramfs.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1066536: additional information

[Vladimir Petko]

Dear Maintainers,

This issue is resolved upstream[1]. Would it be possible to consider
releasing a new version, or applying the attached patch?

Best Regards,
 Vladimir.

[1] 
https://github.com/resurrecting-open-source-projects/sniffit/commit/df0221e95527e9f935b583da5d922c4d3e63d749
From: Sam James 
Date: Thu, 28 Jul 2022 12:14:44 +0100
Subject: [PATCH 2/2] Fix -Wimplicit-function-declaration (Clang 16)

Clang 16 will make -Wimplicit-function-declaration error by default.

For more information, see LWN.net [0] or LLVM's Discourse [1], gentoo-dev@ [2],
or the (new) c-std-porting mailing list [3].

[0] https://lwn.net/Articles/913505/
[1] https://discourse.llvm.org/t/configure-script-breakage-with-the-new-werror-implicit-function-declaration/65213
[2] https://archives.gentoo.org/gentoo-dev/message/dd9f2d3082b8b6f8dfbccb0639e6e240
[3] hosted at lists.linux.dev.

Signed-off-by: Sam James 
Origin: upstream, https://github.com/resurrecting-open-source-projects/sniffit/commit/df0221e95527e9f935b583da5d922c4d3e63d749
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066536
Bug-Ubuntu: https://bugs.launchpad.net/debian/+source/sniffit/+bug/2061033
Forwarded: not-needed

---
 src/sn_cfgfile.c| 1 +
 src/sn_generation.c | 2 ++
 src/sn_interface.c  | 1 +
 src/sniffit.c   | 1 +
 4 files changed, 5 insertions(+)

diff --git a/src/sn_cfgfile.c b/src/sn_cfgfile.c
index 4ea5d39..b27ac7d 100644
--- a/src/sn_cfgfile.c
+++ b/src/sn_cfgfile.c
@@ -2,6 +2,7 @@
 /*   - by  : Brecht Claerhout */
 /*   - improvements: Shudoh Kazuyuki  */

+#include 
 #include 
 #include 
 #include 
diff --git a/src/sn_generation.c b/src/sn_generation.c
index e08741e..030075a 100644
--- a/src/sn_generation.c
+++ b/src/sn_generation.c
@@ -13,7 +13,9 @@
 #include "sn_curses.h"
 #include "sn_defines.h"
 #include "sn_structs.h"
+#include "sn_packets.h"
 #include "sn_generation.h"
+#include "sn_interface.h"

 extern volatile int screen_busy;

diff --git a/src/sn_interface.c b/src/sn_interface.c
index 4842974..f8434d9 100644
--- a/src/sn_interface.c
+++ b/src/sn_interface.c
@@ -4,6 +4,7 @@
 #include "sn_config.h"

 #ifdef INCLUDE_INTERFACE
+#include 
 #include 
 #include 
 #include 
diff --git a/src/sniffit.c b/src/sniffit.c
index 7ab88a1..4adbe69 100644
--- a/src/sniffit.c
+++ b/src/sniffit.c
@@ -3,6 +3,7 @@

 #include "sn_config.h"		/* Config header file */

+#include 
 #include 
 #include 
 #include 
--
2.40.1

Bug#1065799: ncrack: FTBFS on arm{el,hf}: configure: error: *** compiler cannot create working executables, check config.log ***

[Vladimir Petko]

Dear Maintainers,

  Would it be possible to consider a merge request[1] that addresses this issue?

Best Regards,
 Vladimir.

 [1] https://salsa.debian.org/pkg-security-team/ncrack/-/merge_requests/2

Bug#1068718: freeimage: consider packaging r1909?

[Dima Kogan]

Hi. It looks like the current 3.18.0 release is at r1806. Are there
features in r1909 that you want that aren't in our 3.18.0?

If there are useful things there, I think it would be best to talk to
upstream about releasing a 3.19. Is upstream completely gone, or just
slow?

Bug#1061300: lcm: Update to version 1.5.0

[Adrian Bunk]

On Sat, Feb 03, 2024 at 08:23:05PM +0100, Jose Luis Rivero wrote:
> Thanks Vagrant for the reply and the information.
> 
> Updating the info about the 1.5 update, the merge-request is ready to
> review and sponsored:
>  - https://salsa.debian.org/debian/lcm/-/merge_requests/1

It is unlikely that many people would see your merge request,
please file a sponsorship request as described at
  https://mentors.debian.net/sponsors/rfs-howto/

cu
Adrian

Bug#1039260: mactelnet: ships sysv-init script without systemd unit

[Luca Boccassi]

The devices are all configured already by the time a normal service is
started, so you can omit it entirely then

On Sun, 14 Apr 2024 at 20:26, Håkon Nessjøen  wrote:
>
> It needs the devices, but not for them to have ip yet.
>
> søn. 14. apr. 2024 kl. 21:25 skrev Luca Boccassi :
>>
>> If it doesn't need the network to be configured then you can avoid any
>> dependency at all.
>>
>> On Sun, 14 Apr 2024 at 20:22, Håkon Nessjøen  
>> wrote:
>> >
>> > Thanks for your help, so far. Great to hear that you are willing to 
>> > sponsor it!
>> >
>> > I will change the dependencies of the service file as you said, but since 
>> > it in theory works before you have an IP address, so it shouldn't need to 
>> > wait for a DHCP client to finish before starting up, is it possible that 
>> > there are other dependencies I should target? Or does it still give most 
>> > sense to use the dependencies you mentioned? I don't have very much 
>> > experience with the order of things in the systemd startup process.
>> >
>> > I will request an account for Salsa in the meantime.
>> >
>> > On Sun, 14 Apr 2024 at 21:06, Luca Boccassi  wrote:
>> >>
>> >> Requires=systemd-networkd.service
>> >> After=systemd-networkd.service
>> >>
>> >> if you want to order it after the network is available, instead of
>> >> those two lines you should use:
>> >>
>> >> Wants=network-online.target
>> >> After=network-online.target
>> >>
>> >> so that it works with other network managers too. Also if
>> >> mactelnet-locales only install locales, then it should be architecture
>> >> "all" instead of "any". Also, consider requesting an account for Salsa
>> >> and moving the repository there.
>> >>
>> >> If you fix these things and close the changelog I can sponsor the upload.
>> >>
>> >> On Sun, 14 Apr 2024 at 19:48, Håkon Nessjøen  
>> >> wrote:
>> >> >
>> >> > Hi,
>> >> >
>> >> > In relation to a new upstream version of mactelnet, I have updated the 
>> >> > debian packaging for this new version, which uses systemd service file 
>> >> > instead of the old sysv-init. I just need to find a sponsor, so that 
>> >> > the package can be updated. My last sponsor stopped being a DM for 6 
>> >> > years ago I think. I'm not sure if it is ok to use this bug as a reason 
>> >> > for updating the module to a new minor version, not just a patch or 
>> >> > debian patch. As mactelnet has new functionality, supporting newer 
>> >> > devices/authentication protocol.
>> >> >
>> >> > Looking at RFS requests, they seem to either be about new packages, 
>> >> > adopted packages, or just security fixes. But this is a new upstream 
>> >> > version. How should I go forward with this?
>> >> >
>> >> > On Mon, 26 Jun 2023 at 00:26,  wrote:
>> >> >>
>> >> >> Package: mactelnet
>> >> >> Severity: important
>> >> >> User: bl...@debian.org
>> >> >> Usertags: missing-systemd-service
>> >> >>
>> >> >> Dear Maintainer(s),
>> >> >>
>> >> >> mactelnet has been flagged by Lintian as shipping a sysv-init script
>> >> >> without a corresponding systemd unit file. The default init system in
>> >> >> Debian is systemd, and so far this worked because a transitional
>> >> >> sysv-init-to-unit generator was shipped by systemd. This is in the
>> >> >> process of being deprecated and will be removed by the time Trixie
>> >> >> ships, so the remaining packages that ship init scripts without
>> >> >> systemd units will stop working.
>> >> >>
>> >> >> There are various advantages to using native units, for example the
>> >> >> legacy generator cannot tell the different between a oneshot service
>> >> >> and a long running daemon. Also, sanboxing and security features
>> >> >> become available for services. For more information, consult the
>> >> >> systemd documentation:
>> >> >> https://www.freedesktop.org/software/systemd/man/systemd.unit.html
>> >> >>
>> >> >> You can find the Lintian warning here:
>> >> >>
>> >> >> https://lintian.debian.org/sources/mactelnet
>> >> >>
>> >> >> In case this is a false positive, please add a Lintian override to
>> >> >> silence it and then close this bug.
>> >> >>
>> >> >> Thanks!

Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs

[Holger Wansing]

Hi,

Holger Wansing  wrote (Sun, 14 Apr 2024 22:25:21 +0200):
> It can be seen at debian-policy under
> https://www.debian.org/doc/debian-policy/

I forgot to mention, that I have pushed a release-notes variant with this
theme to
https://people.debian.org/~holgerw/new-rtd-sphinx-theme-for-debian/release-notes/release-notes/index.en.html
(English)

https://people.debian.org/~holgerw/new-rtd-sphinx-theme-for-debian/release-notes/release-notes/index.de.html
(German)

https://people.debian.org/~holgerw/new-rtd-sphinx-theme-for-debian/release-notes/release-notes/index.ca.html
(Catalan)


And we need an additional package installed on wolkenstein, to build the
release-notes with this theme.


Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1052028: please update to pydantic 2.x

[Timo Röhling]

Hi Alexandre,

* Alexandre Detiste  [2024-04-14 
16:12]:

Now that pydantic-core is available,
I started packaging v2.7.
pydantic-core in Debian is not the latest release, because anything 
above 2.11.0 requires an additional Rust dependency (jiter), which 
in turns needs several other Rust dependencies packaged.


According to the listed requirements, I would expect pydantic 2.4.2 
to be compatible, so I suggest we start there and upgrade to the 
latest release as soon as pydantic-core gains its missing 
dependencies and can be upgraded, too.



Cheers
Timo

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


signature.asc
Description: PGP signature

Bug#1068999: plantuml: Fontconfig head is null, check your fonts or fonts configuration when running plantuml

[Vladimir Petko]

Source: plantuml
Version: 1:1.2020.2+ds-4
Severity: important

Dear Maintainer,

When running plantuml in a chroot I am getting the following exception:

$plantuml
Exception in thread "main" java.lang.RuntimeException: Fontconfig head is null,
check your fonts or fonts configuration
at
java.desktop/sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1263)
at
java.desktop/sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:221)
at
java.desktop/sun.awt.FontConfiguration.init(FontConfiguration.java:105)
at
java.desktop/sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:696)
at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:352)
at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:309)
at
java.base/java.security.AccessController.doPrivileged(AccessController.java:319)
at java.desktop/sun.font.SunFontManager.(SunFontManager.java:309)
at java.desktop/sun.awt.FcFontManager.(FcFontManager.java:35)
at java.desktop/sun.awt.X11FontManager.(X11FontManager.java:55)
at
java.desktop/sun.font.PlatformFontInfo.createFontManager(PlatformFontInfo.java:37)
at
java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:51)
at
java.desktop/sun.font.SunFontManager.getInstance(SunFontManager.java:242)
at
java.desktop/sun.font.FontDesignMetrics.getMetrics(FontDesignMetrics.java:260)
at
java.desktop/sun.java2d.SunGraphics2D.getFontMetrics(SunGraphics2D.java:870)
at net.sourceforge.plantuml.Run.forceOpenJdkResourceLoad(Run.java:230)
at net.sourceforge.plantuml.Run.main(Run.java:137)

Note, this does not happen when I have default-jre installed.

Probably this issue is a result of[1].


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




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

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

Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs

[Holger Wansing]

Hi,

you may have noticed that we have an 'official' Debian-style html theme for
Sphinx-based manuals on the Debian website now.

It can be seen at debian-policy under
https://www.debian.org/doc/debian-policy/

It was created by Stéphane Blondon, based on a theme from readthedocs.org.

Any objections against porting this theme to the release-notes as well?

To make this theme work on the Debian website, there are some more changings
needed in webmaster's cron repo; I have prepared them and attached to this
mail, just for completeness.


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
>From 2704fab5800f36aeafa29275e7afd13b422ecb81 Mon Sep 17 00:00:00 2001
From: Holger Wansing 
Date: Sun, 14 Apr 2024 22:04:20 +0200
Subject: [PATCH] =?UTF-8?q?Switch=20to=20new=20Debian-style=20html=20theme?=
 =?UTF-8?q?=20by=20St=C3=A9phane=20Blondon,=20based=20on=20readthedocs.org?=
 =?UTF-8?q?=20theme?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 source/_static/debian.css | 103 ++
 source/conf.py|  14 +++---
 2 files changed, 109 insertions(+), 8 deletions(-)
 create mode 100644 source/_static/debian.css

diff --git a/source/_static/debian.css b/source/_static/debian.css
new file mode 100644
index ..7f0981b0
--- /dev/null
+++ b/source/_static/debian.css
@@ -0,0 +1,103 @@
+/* Debian Cascading stylesheet for Sphinx */
+
+div.related {
+background-color: #C70036;
+}
+
+.rst-content h1, .rst-content h2, .rst-content h3, .rst-content h4, .rst-content h5, .rst-content h6 {
+color: #C70036;
+}
+
+.wy-nav-top {
+background-color: #C70036;
+}
+
+.wy-side-nav-search {
+background-color: #C70036;
+}
+
+.rst-content a:link {
+color: #0035C7;
+text-decoration: none;
+}
+.rst-content a:visited {
+color: #00207A;
+text-decoration: none;
+}
+.rst-content a:link:hover {
+color: #00207A;
+text-decoration: underline;
+}
+
+
+/* Table in content */
+
+.wy-table-responsive table td, .wy-table-responsive table th {
+white-space: normal;
+}
+
+.rst-content table.docutils, .wy-table-bordered-all {
+width: 100%;
+}
+
+.wy-table-responsive table.docutils thead tr {
+background-color: #C70036;
+border: 1px solid black;
+color: black;
+}
+
+.wy-table-responsive table.docutils thead tr:hover {
+color: #fcfcfc;
+}
+
+.wy-table-responsive table.docutils tbody tr:hover {
+background-color:#66;
+color: #FF;
+}
+
+.rst-content table.docutils:not(.field-list) tbody tr:hover:nth-child(2n-1), .wy-table-backed, .wy-table-odd td, .wy-table-striped tr:nth-child(2n-1) td {
+background-color:#66;
+}
+
+/* Previous and next buttons */
+
+.rst-footer-buttons .btn:hover {
+text-decoration: none !important;
+}
+
+/* Version release more readable */
+
+.wy-side-nav-search > div.version {
+color: #FCFCFC;
+}
+
+/* Infos blocks */
+
+div.warning {
+border: 1px dashed #EFF500;
+background-color: #eff50030;
+}
+
+div.note {
+border: 1px dashed blue;
+background-color: #ff30;
+
+}
+
+.warning, .note {
+margin-left: 1em;
+margin-right: 1em;
+}
+
+@media (max-width: 5in), (max-device-width: 5in){
+.warning, .note {
+margin-left: 0.5em;
+margin-right: 0.5em;
+}
+}
+
+/* Notes */
+
+html.writer-html5 .rst-content aside.citation, html.writer-html5 .rst-content aside.footnote, html.writer-html5 .rst-content div.citation {
+display: block;
+}
diff --git a/source/conf.py b/source/conf.py
index 855fb942..ec055233 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -127,20 +127,15 @@ pygments_style = None
 # The theme to use for HTML and HTML Help pages.  See the documentation for
 # a list of builtin themes.
 #
-html_theme = 'alabaster'
+html_theme = 'sphinx_rtd_theme'
 
 # Theme options are theme-specific and customize the look and feel of a theme
 # further.  For a list of options available for each theme, see the
 # documentation.
 #
 html_theme_options = {
-	'logo': 'openlogo-release-notes.png',
-	'show_powered_by': False,
-	'link': '#0035c7',
-	'sidebar_header': '#c70036',
-	'sidebar_link': '#0035c7',
-	'show_related': True,
-	'show_relbars': True
+	# To get previous/next buttons at the top and the bottom:
+	'prev_next_buttons_location': 'both'
 }
 
 # Add any paths that contain custom static files (such as style sheets) here,
@@ -148,6 +143,9 @@ html_theme_options = {
 # so a file named "default.css" will overwrite the builtin "default.css".
 html_static_path = ['_static']
 
+# Overwrite theme to fit Debian colors
+html_css_files = ['debian.css']
+
 html_js_files = ['switchers.js']
 
 # Hide “Created using Sphinx” in the HTML footer
-- 
2.39.2

diff --git a/parts/7release-notes b/parts/7release-notes
index c1a74c9..a700b71 100755
--- a/parts/7release-notes
+++ b/parts/7release-notes
@@ -122,6 +122,8 @@ for page in $pagepattern; do
 			if [ "$(basename $page 

Bug#1066873: RFS: tracy/0.10+ds-1 [ITP] -- Hybrid frame and sampling profiler

[Andrey Rakhmatullin]

On Mon, Apr 15, 2024 at 01:25:05AM +0530, Alan M Varghese wrote:
> > This FTBFS: "! LaTeX Error: File `lmodern.sty' not found."
> 
> lmodern.sty comes from the package `lmodern`. This package should be
> 
> installed (as a transitive dep) when 'texlive-fonts-extra' is installed.
No, see below. But this also means you haven't tried building your package
in a minimal sid chroot.

> What is the process for installing build-deps?
Manually on a host system? `apt build-dep` or `mk-build-deps -ir`

> `apt install texlive-fonts-extra`, the lmodern package also
> gets installed.
Recommends are not installed when installing build-deps.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1066873: RFS: tracy/0.10+ds-1 [ITP] -- Hybrid frame and sampling profiler

[Alan M Varghese]

> This FTBFS: "! LaTeX Error: File `lmodern.sty' not found."

lmodern.sty comes from the package `lmodern`. This package should be

installed (as a transitive dep) when 'texlive-fonts-extra' is installed.


What is the process for installing build-deps? When I run

`apt install texlive-fonts-extra`, the lmodern package also

gets installed.

Bug#974972: unar: There is a new upstream version

[Bastian Germann]

Please use the new package universal-detector for importing the new version.

Bug#1068998: xgridfit: ttx2xgf fails to run

[Sudip Mukherjee]

Package: xgridfit
Version: 2.3-4
Severity: normal

Dear Maintainer,

ttx2xgf fails to run with the error:

$ ttx2xgf
Traceback (most recent call last):
  File "/usr/bin/ttx2xgf", line 3, in 
from xgflib import run_ttx2xgf
ModuleNotFoundError: No module named 'xgflib'

-- 
Regards
Sudip

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

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

Versions of packages xgridfit depends on:
ii  python33.11.6-1
ii  python3-fontforge  1:20230101~dfsg-1.1
ii  python3-libxml22.9.14+dfsg-1.3+b2
ii  xsltproc   1.1.35-1

xgridfit recommends no packages.

Versions of packages xgridfit suggests:
pn  fontforge  
pn  fonttools  

Bug#1053549: Create a Debian theme for documentation based in Sphinx (reStructuredText)

[James Addison]

On Sat, 13 Apr 2024 at 06:48, Holger Wansing  wrote:
> Am 11. April 2024 23:52:52 MESZ schrieb James Addison :
> >On Sun, 7 Apr 2024 13:00:43 +0200, Holger wrote:
> >> The only thing which is not working currently, is the search functionality,
> >> but since that's not theme-specific I guess (please correct me, if I'm
> >> wrong), I close this bug.
> >
> >The theme looks great, and I agree with closing this bug.  However, so that
> >we don't overlook another potential python3-sphinx bug: could you report the
> >problem that you encountered?  (I contribute to upstream and may be able to
> >help with investigating that)
>
> It's not a bug in sphinx or something like that.
> The issue was in the build process for the website, what lead to some missing
> files in the manuals' tree (javascript script files and the searchindex.js).
>
> Everything fine for now.

Ok; thank you!

> I'm currently working on switching the Debian release-notes to the new theme,
> and that might bring some issues, since the release-notes have translations as
> well (this was not the case for the debian-policy).
>
> So maybe I come back to you in such case, if that's ok?

I'm less knowledgeable about the translation logic than the JavaScript search
functionality, however yes, feel free to include me on cc for Sphinx bugreports
and I'll help if-and-when possible.

James

Bug#1068996: python3-bx: maf_word_frequency.py fails to run

[Sudip Mukherjee]

Another problem with the same package:

$ maf_tile_2.py
Traceback (most recent call last):
  File "/usr/bin/maf_tile_2.py", line 34, in 
from cookbook import doc_optparse
ModuleNotFoundError: No module named 'cookbook'


-- 
Regards
Sudip

Bug#1068997: mailtextbody: feature request: optionally specify MIME type to extract (default: text/plain)

[Jonas Smedegaard]

Package: mailtextbody
Version: 0.1.4-1+b1
Severity: wishlist
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

What a neat little tool.  I have needed this many times over the years.

One thing that I would want, which seems within the scope of this tiny
tool: An option to specify which MIME type to look for, with default
being the currently hardcoded text/plain.

This option would allow me to extract emails containing text/calendar
content, as well as dummy empty text/plain content.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmYcMJ0ACgkQLHwxRsGg
ASGWsw/+OHLTtblayELDEChOgSh+PFQf/QmT8XN5qfET7Esu1OVPpY/03Ay4f13B
dNmS9o3IMposkw3rozcKLiv9v1NCTYpPx9OBl2Tbey6ACVcy2nWvGnuBwKnGTUm3
DRnXX77FAi5g2VHwBJmaBRW04/LlI9Y2ln1EwT0wRLq6dDKLDnUTIqtKBk0XmrMG
bILXEOCu7a2LjphnWvvSi+yN7A31B9OqArNaU6lR2bZGSJbxC71waE+ELIKa7CY0
KUYMnRbqCwKBOrnhH/yyqb9RJ7PJ1HoT3gAL1Oc9yF3DLee7DN9yjQAPVzpFG+OO
s9Uk+TLllte5oNHMDR1Q7e9dRgzhnxzbh0XEurX4VQH7WPdnnoyIUbIcyYWRymGu
cK7WsvAO/RyUIVYuIOLX6hAp1jhyeuOaEtLuHZ0RtJmAmfQhuqKfq+KoIgmFJex6
Yxh4RkjeJGVeYGBFAmKpQS0CXcSQ1Yz1TRZQUME2drEU1RRY4jjAudPtpZm67gGb
KG/UBMnOpd4Eh8XSYttTUEWmQd3z0DKLW7AbeznHsyjZqmozrXL98QOtz3SLlh8H
2oypSSQ6LHlsWOJAMR2sfgpNclc6mBeHkJkdixFTQB0eyhKzUe65o18KcOQS3KqP
mKWtkxYR/QFd6QJ8VlSqSRSCM/3pS5c40vcvTnfuOxnLR1KO8Ug=
=xNFf
-END PGP SIGNATURE-

Bug#1068996: python3-bx: maf_word_frequency.py fails to run

[Sudip Mukherjee]

Package: python3-bx
Version: 0.11.0-3
Severity: normal

Dear Maintainer,

maf_word_frequency.py fails to run with the error:

$ maf_word_frequency.py 
Traceback (most recent call last):
  File "/usr/bin/maf_word_frequency.py", line 15, in 
import psyco
ModuleNotFoundError: No module named 'psyco'

-- 
Regards
Sudip

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

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

Versions of packages python3-bx depends on:
ii  libc6   2.37-15
ii  python3 3.11.6-1
ii  python3-lzo 1.14-1+b4
ii  python3-numpy [python3-numpy-abi9]  1:1.26.4+ds-6
ii  zlib1g  1:1.3.dfsg-3+b1

python3-bx recommends no packages.

python3-bx suggests no packages.

Bug#1039260: mactelnet: ships sysv-init script without systemd unit

[Håkon Nessjøen]

It needs the devices, but not for them to have ip yet.

søn. 14. apr. 2024 kl. 21:25 skrev Luca Boccassi :

> If it doesn't need the network to be configured then you can avoid any
> dependency at all.
>
> On Sun, 14 Apr 2024 at 20:22, Håkon Nessjøen 
> wrote:
> >
> > Thanks for your help, so far. Great to hear that you are willing to
> sponsor it!
> >
> > I will change the dependencies of the service file as you said, but
> since it in theory works before you have an IP address, so it shouldn't
> need to wait for a DHCP client to finish before starting up, is it possible
> that there are other dependencies I should target? Or does it still give
> most sense to use the dependencies you mentioned? I don't have very much
> experience with the order of things in the systemd startup process.
> >
> > I will request an account for Salsa in the meantime.
> >
> > On Sun, 14 Apr 2024 at 21:06, Luca Boccassi  wrote:
> >>
> >> Requires=systemd-networkd.service
> >> After=systemd-networkd.service
> >>
> >> if you want to order it after the network is available, instead of
> >> those two lines you should use:
> >>
> >> Wants=network-online.target
> >> After=network-online.target
> >>
> >> so that it works with other network managers too. Also if
> >> mactelnet-locales only install locales, then it should be architecture
> >> "all" instead of "any". Also, consider requesting an account for Salsa
> >> and moving the repository there.
> >>
> >> If you fix these things and close the changelog I can sponsor the
> upload.
> >>
> >> On Sun, 14 Apr 2024 at 19:48, Håkon Nessjøen 
> wrote:
> >> >
> >> > Hi,
> >> >
> >> > In relation to a new upstream version of mactelnet, I have updated
> the debian packaging for this new version, which uses systemd service file
> instead of the old sysv-init. I just need to find a sponsor, so that the
> package can be updated. My last sponsor stopped being a DM for 6 years ago
> I think. I'm not sure if it is ok to use this bug as a reason for updating
> the module to a new minor version, not just a patch or debian patch. As
> mactelnet has new functionality, supporting newer devices/authentication
> protocol.
> >> >
> >> > Looking at RFS requests, they seem to either be about new packages,
> adopted packages, or just security fixes. But this is a new upstream
> version. How should I go forward with this?
> >> >
> >> > On Mon, 26 Jun 2023 at 00:26,  wrote:
> >> >>
> >> >> Package: mactelnet
> >> >> Severity: important
> >> >> User: bl...@debian.org
> >> >> Usertags: missing-systemd-service
> >> >>
> >> >> Dear Maintainer(s),
> >> >>
> >> >> mactelnet has been flagged by Lintian as shipping a sysv-init script
> >> >> without a corresponding systemd unit file. The default init system in
> >> >> Debian is systemd, and so far this worked because a transitional
> >> >> sysv-init-to-unit generator was shipped by systemd. This is in the
> >> >> process of being deprecated and will be removed by the time Trixie
> >> >> ships, so the remaining packages that ship init scripts without
> >> >> systemd units will stop working.
> >> >>
> >> >> There are various advantages to using native units, for example the
> >> >> legacy generator cannot tell the different between a oneshot service
> >> >> and a long running daemon. Also, sanboxing and security features
> >> >> become available for services. For more information, consult the
> >> >> systemd documentation:
> >> >> https://www.freedesktop.org/software/systemd/man/systemd.unit.html
> >> >>
> >> >> You can find the Lintian warning here:
> >> >>
> >> >> https://lintian.debian.org/sources/mactelnet
> >> >>
> >> >> In case this is a false positive, please add a Lintian override to
> >> >> silence it and then close this bug.
> >> >>
> >> >> Thanks!
>

Bug#1039260: mactelnet: ships sysv-init script without systemd unit

[Luca Boccassi]

If it doesn't need the network to be configured then you can avoid any
dependency at all.

On Sun, 14 Apr 2024 at 20:22, Håkon Nessjøen  wrote:
>
> Thanks for your help, so far. Great to hear that you are willing to sponsor 
> it!
>
> I will change the dependencies of the service file as you said, but since it 
> in theory works before you have an IP address, so it shouldn't need to wait 
> for a DHCP client to finish before starting up, is it possible that there are 
> other dependencies I should target? Or does it still give most sense to use 
> the dependencies you mentioned? I don't have very much experience with the 
> order of things in the systemd startup process.
>
> I will request an account for Salsa in the meantime.
>
> On Sun, 14 Apr 2024 at 21:06, Luca Boccassi  wrote:
>>
>> Requires=systemd-networkd.service
>> After=systemd-networkd.service
>>
>> if you want to order it after the network is available, instead of
>> those two lines you should use:
>>
>> Wants=network-online.target
>> After=network-online.target
>>
>> so that it works with other network managers too. Also if
>> mactelnet-locales only install locales, then it should be architecture
>> "all" instead of "any". Also, consider requesting an account for Salsa
>> and moving the repository there.
>>
>> If you fix these things and close the changelog I can sponsor the upload.
>>
>> On Sun, 14 Apr 2024 at 19:48, Håkon Nessjøen  
>> wrote:
>> >
>> > Hi,
>> >
>> > In relation to a new upstream version of mactelnet, I have updated the 
>> > debian packaging for this new version, which uses systemd service file 
>> > instead of the old sysv-init. I just need to find a sponsor, so that the 
>> > package can be updated. My last sponsor stopped being a DM for 6 years ago 
>> > I think. I'm not sure if it is ok to use this bug as a reason for updating 
>> > the module to a new minor version, not just a patch or debian patch. As 
>> > mactelnet has new functionality, supporting newer devices/authentication 
>> > protocol.
>> >
>> > Looking at RFS requests, they seem to either be about new packages, 
>> > adopted packages, or just security fixes. But this is a new upstream 
>> > version. How should I go forward with this?
>> >
>> > On Mon, 26 Jun 2023 at 00:26,  wrote:
>> >>
>> >> Package: mactelnet
>> >> Severity: important
>> >> User: bl...@debian.org
>> >> Usertags: missing-systemd-service
>> >>
>> >> Dear Maintainer(s),
>> >>
>> >> mactelnet has been flagged by Lintian as shipping a sysv-init script
>> >> without a corresponding systemd unit file. The default init system in
>> >> Debian is systemd, and so far this worked because a transitional
>> >> sysv-init-to-unit generator was shipped by systemd. This is in the
>> >> process of being deprecated and will be removed by the time Trixie
>> >> ships, so the remaining packages that ship init scripts without
>> >> systemd units will stop working.
>> >>
>> >> There are various advantages to using native units, for example the
>> >> legacy generator cannot tell the different between a oneshot service
>> >> and a long running daemon. Also, sanboxing and security features
>> >> become available for services. For more information, consult the
>> >> systemd documentation:
>> >> https://www.freedesktop.org/software/systemd/man/systemd.unit.html
>> >>
>> >> You can find the Lintian warning here:
>> >>
>> >> https://lintian.debian.org/sources/mactelnet
>> >>
>> >> In case this is a false positive, please add a Lintian override to
>> >> silence it and then close this bug.
>> >>
>> >> Thanks!

Bug#1067561: FTBFS: Error: symbol `open64' is already defined

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, 2024-04-13 at 16:11 +0100, Peter Green wrote:
> > Hi, thanks for the patch. It looks a bit strong though, undefining stuff
> > like
> > that unconditionally. Do you have pointers to the Ubuntu bug or something?
> > I've looked at upstream commits and issues and couldn't see anything
> > there.
> 
> My understanding of the issue.

Hi Peter, thanks for the details. They really should be transmitted to the
upstream maintainer so I took the liberty to copy/paste it to the upstream bug
at https://github.com/canonical/lightdm/issues/352

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmYcLKoACgkQ3rYcyPpX
RFvszggAuBC/jVutExKct2P2GNDoxIG8UHEkD0q0nZwzY3ojcVYF4Za4+g5i9HyJ
khWQgqXzwxA5aWvOn4/lxo0CUd3LyzvKf4c1bP5wEX6LO3WZmOOAwDMQSdGfF5/k
jZ2tDP212sS7WRhc8cUqTagKww90WJ8O9MfhusOSzhjimArxeM5XkO2CTmKZI7/0
eU+VTahJxaqyOp8LNNVrqyJHgdkr1LdWL67crixf4sPrkIKfcibYleoaiG0pK/Oq
hcm7iV956GEFTa0VIYhuskTjB2TopA85UsGNTLYMGWtS7+XZbLirpuE8ToUqVeQ2
lm5douVLT78wjf4ZBbUq58wn499Q4g==
=AAyB
-END PGP SIGNATURE-

Bug#1039260: mactelnet: ships sysv-init script without systemd unit

[Håkon Nessjøen]

Thanks for your help, so far. Great to hear that you are willing to sponsor
it!

I will change the dependencies of the service file as you said, but since
it in theory works before you have an IP address, so it shouldn't need to
wait for a DHCP client to finish before starting up, is it possible that
there are other dependencies I should target? Or does it still give most
sense to use the dependencies you mentioned? I don't have very much
experience with the order of things in the systemd startup process.

I will request an account for Salsa in the meantime.

On Sun, 14 Apr 2024 at 21:06, Luca Boccassi  wrote:

> Requires=systemd-networkd.service
> After=systemd-networkd.service
>
> if you want to order it after the network is available, instead of
> those two lines you should use:
>
> Wants=network-online.target
> After=network-online.target
>
> so that it works with other network managers too. Also if
> mactelnet-locales only install locales, then it should be architecture
> "all" instead of "any". Also, consider requesting an account for Salsa
> and moving the repository there.
>
> If you fix these things and close the changelog I can sponsor the upload.
>
> On Sun, 14 Apr 2024 at 19:48, Håkon Nessjøen 
> wrote:
> >
> > Hi,
> >
> > In relation to a new upstream version of mactelnet, I have updated the
> debian packaging for this new version, which uses systemd service file
> instead of the old sysv-init. I just need to find a sponsor, so that the
> package can be updated. My last sponsor stopped being a DM for 6 years ago
> I think. I'm not sure if it is ok to use this bug as a reason for updating
> the module to a new minor version, not just a patch or debian patch. As
> mactelnet has new functionality, supporting newer devices/authentication
> protocol.
> >
> > Looking at RFS requests, they seem to either be about new packages,
> adopted packages, or just security fixes. But this is a new upstream
> version. How should I go forward with this?
> >
> > On Mon, 26 Jun 2023 at 00:26,  wrote:
> >>
> >> Package: mactelnet
> >> Severity: important
> >> User: bl...@debian.org
> >> Usertags: missing-systemd-service
> >>
> >> Dear Maintainer(s),
> >>
> >> mactelnet has been flagged by Lintian as shipping a sysv-init script
> >> without a corresponding systemd unit file. The default init system in
> >> Debian is systemd, and so far this worked because a transitional
> >> sysv-init-to-unit generator was shipped by systemd. This is in the
> >> process of being deprecated and will be removed by the time Trixie
> >> ships, so the remaining packages that ship init scripts without
> >> systemd units will stop working.
> >>
> >> There are various advantages to using native units, for example the
> >> legacy generator cannot tell the different between a oneshot service
> >> and a long running daemon. Also, sanboxing and security features
> >> become available for services. For more information, consult the
> >> systemd documentation:
> >> https://www.freedesktop.org/software/systemd/man/systemd.unit.html
> >>
> >> You can find the Lintian warning here:
> >>
> >> https://lintian.debian.org/sources/mactelnet
> >>
> >> In case this is a false positive, please add a Lintian override to
> >> silence it and then close this bug.
> >>
> >> Thanks!
>

Bug#1068257: urlscan: Related security project → email-untracker

[Manny]

Package: urlscan
Version: 0.9.5-1
Followup-For: Bug #1068257

It’s worth noting that there is a non-Debian project that’s related to
tracker pixels in email:

  https://github.com/bengtan/email-untracker

That tool could not replace the proposal urlscan because it merely
looks for a few specific regular expressions known to email-untracker,
according to the docs:

  
https://bengtan.com/blog/email-cleaner-clean-tracking-links-and-pixels/#how-it-works

But it would be interesting if urlscan would source the regular
expressions from the email-untracker project and disclose matches to
users in a more overt way. There could be a “known trackers found”
list in the output of urlscan, and a list of IMG URLs for users to
manually evaluate.

-- System Information:
Debian Release: 11.5
  APT prefers oldstable-updates
  APT policy: (990, 'oldstable-updates'), (990, 'oldstable-security'), (990, 
'testing'), (990, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages urlscan depends on:
ii  python33.9.2-3
ii  python3-urwid  2.1.2-1

Versions of packages urlscan recommends:
ii  libcanberra-gtk3-module  0.30-7

Versions of packages urlscan suggests:
ii  elinks [www-browser]  0.13.2-1+b1
ii  firefox-esr [www-browser] 102.6.0esr-1~deb11u1
ii  lynx [www-browser]2.9.0dev.6-3~deb11u1
ii  neomutt   20201127+dfsg.1-1.2
ii  ungoogled-chromium [www-browser]  90.0.4430.212-1.sid1
ii  w3m [www-browser] 0.5.3+git20210102-6

-- no debconf information

Bug#1039260: mactelnet: ships sysv-init script without systemd unit

[Luca Boccassi]

Requires=systemd-networkd.service
After=systemd-networkd.service

if you want to order it after the network is available, instead of
those two lines you should use:

Wants=network-online.target
After=network-online.target

so that it works with other network managers too. Also if
mactelnet-locales only install locales, then it should be architecture
"all" instead of "any". Also, consider requesting an account for Salsa
and moving the repository there.

If you fix these things and close the changelog I can sponsor the upload.

On Sun, 14 Apr 2024 at 19:48, Håkon Nessjøen  wrote:
>
> Hi,
>
> In relation to a new upstream version of mactelnet, I have updated the debian 
> packaging for this new version, which uses systemd service file instead of 
> the old sysv-init. I just need to find a sponsor, so that the package can be 
> updated. My last sponsor stopped being a DM for 6 years ago I think. I'm not 
> sure if it is ok to use this bug as a reason for updating the module to a new 
> minor version, not just a patch or debian patch. As mactelnet has new 
> functionality, supporting newer devices/authentication protocol.
>
> Looking at RFS requests, they seem to either be about new packages, adopted 
> packages, or just security fixes. But this is a new upstream version. How 
> should I go forward with this?
>
> On Mon, 26 Jun 2023 at 00:26,  wrote:
>>
>> Package: mactelnet
>> Severity: important
>> User: bl...@debian.org
>> Usertags: missing-systemd-service
>>
>> Dear Maintainer(s),
>>
>> mactelnet has been flagged by Lintian as shipping a sysv-init script
>> without a corresponding systemd unit file. The default init system in
>> Debian is systemd, and so far this worked because a transitional
>> sysv-init-to-unit generator was shipped by systemd. This is in the
>> process of being deprecated and will be removed by the time Trixie
>> ships, so the remaining packages that ship init scripts without
>> systemd units will stop working.
>>
>> There are various advantages to using native units, for example the
>> legacy generator cannot tell the different between a oneshot service
>> and a long running daemon. Also, sanboxing and security features
>> become available for services. For more information, consult the
>> systemd documentation:
>> https://www.freedesktop.org/software/systemd/man/systemd.unit.html
>>
>> You can find the Lintian warning here:
>>
>> https://lintian.debian.org/sources/mactelnet
>>
>> In case this is a false positive, please add a Lintian override to
>> silence it and then close this bug.
>>
>> Thanks!

Bug#1039260: mactelnet: ships sysv-init script without systemd unit

[Håkon Nessjøen]

Hi,

In relation to a new upstream version of mactelnet, I have updated the
debian packaging for this new version, which uses systemd service file
instead of the old sysv-init. I just need to find a sponsor, so that the
package can be updated. My last sponsor stopped being a DM for 6 years ago
I think. I'm not sure if it is ok to use this bug as a reason for updating
the module to a new minor version, not just a patch or debian patch. As
mactelnet has new functionality, supporting newer devices/authentication
protocol.

Looking at RFS requests, they seem to either be about new packages, adopted
packages, or just security fixes. But this is a new upstream version. How
should I go forward with this?

On Mon, 26 Jun 2023 at 00:26,  wrote:

> Package: mactelnet
> Severity: important
> User: bl...@debian.org
> Usertags: missing-systemd-service
>
> Dear Maintainer(s),
>
> mactelnet has been flagged by Lintian as shipping a sysv-init script
> without a corresponding systemd unit file. The default init system in
> Debian is systemd, and so far this worked because a transitional
> sysv-init-to-unit generator was shipped by systemd. This is in the
> process of being deprecated and will be removed by the time Trixie
> ships, so the remaining packages that ship init scripts without
> systemd units will stop working.
>
> There are various advantages to using native units, for example the
> legacy generator cannot tell the different between a oneshot service
> and a long running daemon. Also, sanboxing and security features
> become available for services. For more information, consult the
> systemd documentation:
> https://www.freedesktop.org/software/systemd/man/systemd.unit.html
>
> You can find the Lintian warning here:
>
> https://lintian.debian.org/sources/mactelnet
>
> In case this is a false positive, please add a Lintian override to
> silence it and then close this bug.
>
> Thanks!
>

Bug#1064726: reopen, still ftbfs

[Matthias Klose]

Control: reopen -1

the package still build-depends on python3-distutils, removed in 3.12.

the package then ftbfs with

[...]
Applying: Bug 1654457 - Update virtualenv to 20.0.31. 
r=mhentges,rstewart a=RyanVM

Auto packing the repository in background for optimum performance.
See "git help gc" for manual housekeeping.
patching file js/src/build/moz.build
patching file mozglue/build/moz.build
patching file config/makefiles/target_binaries.mk
patching file js/src/moz.build
patching file js/src/old-configure
patching file js/public/StructuredClone.h
patch unexpectedly ends in middle of line
Hunk #1 succeeded at 381 with fuzz 1 (offset 53 lines).
patching file js/public/AllocPolicy.h
Hunk #1 succeeded at 109 (offset 2 lines).
Hunk #2 succeeded at 175 (offset 3 lines).
patching file js/public/RootingAPI.h
patch unexpectedly ends in middle of line
Hunk #1 succeeded at 931 with fuzz 1.
patching file build/moz.configure/toolchain.configure
patching file build/moz.configure/toolchain.configure
patching file build/moz.configure/init.configure
patching file js/src/jit/arm64/vixl/MozCpu-vixl.cpp
patching file js/src/wasm/WasmSignalHandlers.cpp
patching file python/mach/mach/config.py
patching file python/mach/mach/decorators.py
patching file python/mach/mach/main.py
patching file python/mozbuild/mozbuild/backend/configenvironment.py
patching file python/mozbuild/mozbuild/makeutil.py
patching file python/mozbuild/mozbuild/util.py
patching file testing/mozbase/manifestparser/manifestparser/filters.py
patching file third_party/python/pipenv/pipenv/vendor/jinja2/sandbox.py
patching file js/src/wasm/WasmSignalHandlers.cpp
Hunk #1 succeeded at 248 (offset 4 lines).
patching file .cargo/config.in
patching file Cargo.lock
patching file Cargo.toml
patching file third_party/rust/cc/.cargo-checksum.json
patching file third_party/rust/cc/src/lib.rs
patching file python/mozbuild/mozbuild/action/process_define_files.py
patching file python/mozbuild/mozbuild/preprocessor.py
patching file python/mozbuild/mozbuild/util.py
/<>/libraries/source/spidermonkey/mozjs-78.6.0/python/mozbuild/mozbuild/configure/__init__.py:838: 
SyntaxWarning: invalid escape sequence '\.'

  RE_MODULE = re.compile('^[a-zA-Z0-9_\.]+$')
Traceback (most recent call last):
  File 
"/<>/libraries/source/spidermonkey/mozjs-78.6.0/build-debug/../js/src/../../configure.py", 
line 25, in 

from mozbuild.configure import (
  File 
"/<>/libraries/source/spidermonkey/mozjs-78.6.0/python/mozbuild/mozbuild/configure/__init__.py", 
line 13, in 

from six.moves import builtins as __builtin__
ModuleNotFoundError: No module named 'six.moves'
ERROR: SpiderMonkey build failed
make[1]: *** [debian/rules:40: override_dh_auto_build] Error 1

Bug#1053548: check-patroni: does not work well with current Patroni

[David Prévot]

Hi Michael,

Le Fri, Dec 15, 2023 at 02:31:23PM +0100, David Prevot a écrit :
> On 2023-12-04 16:59, Michael Banck wrote:
[…]
> > So, what are your plans? I can offer to take over the packaging of
> > check-patroni as part of the Postgres team; I'd move the git to
> > salsa.debian.org/postgresql and merge in a few of the things I did
> > differently.
> 
> Sounds good to me, thanks!

FYI, I uploaded the latest version just because I noticed it, but still
agree with your plan of taking over under /postgresql whenever you wish.

Regards,

taffit


signature.asc
Description: PGP signature

Bug#1004863: Bootstrapping a Fedora produces a system with an empty package database

[Luca Boccassi]

> Le 2/13/22 à 09:00, Mihai Moldovan a écrit :
> 
> > I'm pretty sure that we can, at some point in the future, drop the
> offending
> > patch from the RPM package and all of this will be redundant. It
> just requires a
> > bit of work to make sure that older use cases (mostly alien) don't
> break due to
> > this, which might require a bit of development on RPM itself. It's
> on my TODO
> > list for very rainy and boring days, but unfortunately there's
> almost always a
> > truckload of other things to do, so I keep dragging it out.
> > 
> > 
> > 
> > Mihai
> > 
> 
> I fully agree on removing the RPM patch that causes all of our issues
> on packages depending on it. If needed, I'm willing to be part of
> reviewing what would be the impact of returning to a standard RPM
> package on Debian and to help into solving those issues. Don't
> hesitate to ping me for that.

I think the time has come to drop the RPM Debian-specific patches and
avoid these workarounds altogether.

Once upon a time it made sense to redirect the RPM DB, and to go out of
our way to stop users installing RPMs locally, when RPMs were popular
as a way to distribute upstream applications.

Nowadays, the most common way to distribute upstream apps is via
Flatpak/Appimage/etc, or (thanks to Ubuntu's popularity) via deb
repositories, so the chances someone tries to 'sudo rpm -i foo.rpm' are
very low.

The main use of having rpm/dnf/zypper in Debian is not to convert RPMs
with Alien or so, but it's to be able to do cross-distribution
bootstraps and image building using native tools, like we do in mkosi
(and in other tools as well).

So these patches to print warnings and divert the database and so on
are a hindrance.

Hence, for Trixie I think we should just drop them all.

It should also make it easier to maintain the RPM stack, which has
languished. We are trying to move everything under the RPM Team Salsa
org, which should also help.

If there are any objections please speak up.

-- 
Kind regards,
Luca Boccassi


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

Bug#921954: gnulib

[Boyuan Yang]

Hi,

On Sat, 2024-04-13 at 22:09 +0200, Jonas Smedegaard wrote:
> Hi Simon (and Boyuan),
> 
> Quoting Simon Josefsson (2024-04-13 19:38:06)
> > You may have noticed I adopted gnulib and have made an upload to
> > experimental.  I am happy to have this team maintained, so feel free
> > to
> > join the effort -- I added Boyuan to Uploaders: since you've been
> > doing
> > QA uploads for some time, but happy to add others too.
> > 
> > If you don't object, I will upload to unstable in a couple of days if
> > nothing comes up.  Relevant reading material on the changes I did for
> > this package:
> > 
> > https://salsa.debian.org/debian/gnulib/-/blob/debian/sid/debian/README.source
> > https://blog.josefsson.org/2024/04/13/reproducible-and-minimal-source-only-tarballs/
> > 
> > What do you think?  I hope I'm not stepping on anyone's toes here. 
> > The
> > package was orphaned and is a critical component to be able to build
> > source-only tarballs for other packages in Debian.
> 
> I am happy that gnulib is in good hands.
> 
> I've moved on to other challenges, and have no interest in working on
> gnulib now.  That said, you are welcome to try nudge me if some
> concrete
> task emerges where you image I might be of help.

Thanks for your work; I am okay with the changes. For git bundle
reproducibility, seeking advice from Debian people in the reproducible-
builds project may be helpful. With the changes in project structure, it
might be useful to provide documents about how to use the updated gnulib
Debian package for other Debian software packagers. 


Thanks,
Boyuan


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

Bug#933264: gradle: Nearly 3-year-old version almost useless

[Matthias Geiger]

On Fri, 1 Dec 2023 13:18:23 +0100 Matthias Geiger  
wrote:

> On 01.12.23 13:16, Markus Koschany wrote:
> > Am Freitag, dem 01.12.2023 um 13:06 +0100 schrieb Matthias Geiger:
> >> Kotlin is now in debian, is there anything else blocking the update ?
> > As a start I have built Gradle 4.6 from source with almost only system
> > libraries but I hit a wall because there seems to be a bug in our 
Kotlin
> > version or rather 4.6 requires a different version, so this version 
still
> > relies on upstream's binary distribution of Kotlin. I will push 
this in a few
> > days and then let's see how we can proceed from here on. Why still 
4.6? Jumping
> > to a newer version like 6.x (which is already superseded by 8.x) 
requires
> > updates of many different system libraries which in turn requires 
updates of
> > reverse-dependencies of said libraries and so on. So whenever you 
change
> > something in Debian's Java eco system you have to be prepared to 
fix a bunch of

> > other seemingly (un)related stuff as well. More details follow soon.
>
>
> Awesome, thanks for your work on this !

Hi Markus,

is there anything blocking this ? Anything I can do to help ?

best,

--
Matthias Geiger 
Debian Maintainer

Bug#1067196: qpdf: contrary to the documentation, fix-qdf aborts on removed objects

[Thorsten Glaser]

Jay Berkenbilt dixit:

>As it happens, I am upstream.

Oh, nice ☻ in that case, thanks for qpdf.

>---
>It is not generally practical to remove objects from QDF files without
>messing up object numbering, but if you remove all indirect references
>to an object (without removing the object itself), this will leave the
>object unreferenced. Then you can run qpdf on the file (after running
>:command:`fix-qdf`), and qpdf will omit the now-orphaned object.
>---

That fixes the ambiguity but leaves the reader¹ wondering, on two
reading passes, what other references than indirect there are.
The reader who has not digested the PDF spec in and out, at least.

If you s/ indirect//, would it still be correct? That would be
less possibly-ambiguous, I think.

bye,
//mirabilos
① or at least me right now
-- 
 Beware of ritual lest you forget the meaning behind it.
 yeah but it means if you really care about something, don't
ritualise it, or you will lose it. don't fetishise it, don't
obsess. or you'll forget why you love it in the first place.

Bug#1032840: RE: QT6 version

[Matthias Geiger]

On Tue, 19 Sep 2023 09:16:07 + Amr Ibrahim 
 wrote:
> On Thu, 23 Mar 2023 17:22:49 +0100 (CET) 
matthias.geiger1...@tutanota.de wrote:

> > Hi,
> >
> > iirc you can't build the qt5 and qt6 theme in parallel


I found out I can double-build the QT5 and QT6 version. The new revision 
has this enabled already; it will require NEW processing though.


I can make no promises when this is going to land in the archive though.

best,


--
Matthias Geiger 
Debian Maintainer
"Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg

Bug#1068995: ITP: golang-github-jdkato-twine -- NLP-related string utilities

[Maytham Alsudany]

Package: wnpp
Severity: wishlist
Owner: Maytham Alsudany 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
Control: block -1 by 1068994
Control: block 1066893 by -1

* Package name: golang-github-jdkato-twine
  Version : 0.10.1
  Upstream Contact: https://github.com/jdkato/twine/issues
* URL : https://github.com/jdkato/twine
* License : Expat
  Programming Lang: Go
  Description : NLP-related string utilities (library)

 Natural language processing related string utility functions for Golang.

Dependency of vale.

This package will be maintained within the Debian Go Packaging Team.
I will need a DD to sponsor and upload this package.

--
Kind regards,
Maytham Alsudany


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

Bug#997264: seriousproton: ftbfs FIX

[Bastian Germann]

I am uploading a LowNMU with the posted patch in order to fix this.
The debdiff is included and the changes are in git.diff -Nru seriousproton-2020.01.15+dfsg/debian/changelog 
seriousproton-2020.01.15+dfsg/debian/changelog
--- seriousproton-2020.01.15+dfsg/debian/changelog  2020-01-30 
19:26:09.0 +
+++ seriousproton-2020.01.15+dfsg/debian/changelog  2024-04-14 
17:34:45.0 +
@@ -1,3 +1,16 @@
+seriousproton (2020.01.15+dfsg-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Remove non-ASCII characters from Description
+
+  [ Nicolas Braud-Santoni ]
+  * libseriousproton-dev: Add missing dependencies
+
+  [ David Paul ]
+  * Fix FTBFS with libbox2d-dev >= 2.4.0 (Closes: #997264)
+
+ -- Bastian Germann   Sun, 14 Apr 2024 17:34:45 +
+
 seriousproton (2020.01.15+dfsg-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru seriousproton-2020.01.15+dfsg/debian/control 
seriousproton-2020.01.15+dfsg/debian/control
--- seriousproton-2020.01.15+dfsg/debian/control2020-01-30 
19:26:09.0 +
+++ seriousproton-2020.01.15+dfsg/debian/control2024-04-14 
17:26:00.0 +
@@ -14,11 +14,12 @@
 Section: libdevel
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends},
- libseriousproton0 (= ${binary:Version})
+ libseriousproton0 (= ${binary:Version}),
+ libbox2d-dev, liblua5.3-dev, libsfml-dev
 Description: C++ game engine -- development files
  SeriousProton is implemented atop SFML, from scratch.
  .
- “There will be dragons and undocumented stuff in here.”
+ "There will be dragons and undocumented stuff in here."
  .
  This package contains the development files (CMake, headers, ...)
 
@@ -28,6 +29,6 @@
 Description: C++ game engine -- shared library
  SeriousProton is implemented atop SFML, from scratch.
  .
- “There will be dragons and undocumented stuff in here.”
+ "There will be dragons and undocumented stuff in here."
  .
  This package contains the shared library.
diff -Nru 
seriousproton-2020.01.15+dfsg/debian/patches/0006-Fix-FTBFS-with-box2d-2.4.0-or-later.patch
 
seriousproton-2020.01.15+dfsg/debian/patches/0006-Fix-FTBFS-with-box2d-2.4.0-or-later.patch
--- 
seriousproton-2020.01.15+dfsg/debian/patches/0006-Fix-FTBFS-with-box2d-2.4.0-or-later.patch
 1970-01-01 00:00:00.0 +
+++ 
seriousproton-2020.01.15+dfsg/debian/patches/0006-Fix-FTBFS-with-box2d-2.4.0-or-later.patch
 2024-04-14 17:20:56.0 +
@@ -0,0 +1,73 @@
+Description: Fix FTBFS with Box2D >= 2.4.0
+ Adapted from a pull request in the upstream repository.
+Origin: https://github.com/daid/SeriousProton/pull/67
+Bug-Debian: https://bugs.debian.org/997264
+Last-Update: 2022-06-08
+---
+
+Index: seriousproton-2020.01.15+dfsg/src/collisionable.h
+===
+--- seriousproton-2020.01.15+dfsg.orig/src/collisionable.h
 seriousproton-2020.01.15+dfsg/src/collisionable.h
+@@ -2,7 +2,7 @@
+ #define COLLISIONABLE_H
+ 
+ #include "P.h"
+-#include "Box2D/Box2D.h"
++#include "box2d/box2d.h"
+ 
+ class Collisionable;
+ class CollisionManager
+Index: seriousproton-2020.01.15+dfsg/src/collisionable.cpp
+===
+--- seriousproton-2020.01.15+dfsg.orig/src/collisionable.cpp
 seriousproton-2020.01.15+dfsg/src/collisionable.cpp
+@@ -30,7 +30,7 @@ public:
+   /// @return false to terminate the query.
+   virtual bool ReportFixture(b2Fixture* fixture)
+   {
+-P ptr = 
(Collisionable*)fixture->GetBody()->GetUserData();
++P ptr = 
reinterpret_cast(fixture->GetBody()->GetUserData().pointer);
+ if (ptr)
+ list.push_back(ptr);
+ return true;
+@@ -75,8 +75,8 @@ void CollisionManager::handleCollisions(
+ {
+ if (contact->IsTouching() && contact->IsEnabled())
+ {
+-Collisionable* A = 
(Collisionable*)contact->GetFixtureA()->GetBody()->GetUserData();
+-Collisionable* B = 
(Collisionable*)contact->GetFixtureB()->GetBody()->GetUserData();
++Collisionable* A = 
reinterpret_cast(contact->GetFixtureA()->GetBody()->GetUserData().pointer);
++Collisionable* B = 
reinterpret_cast(contact->GetFixtureB()->GetBody()->GetUserData().pointer);
+ if (!A->isDestroyed() && !B->isDestroyed())
+ {
+ float collision_force = 0.0f;
+@@ -220,7 +220,7 @@ void Collisionable::setCollisionChain(co
+ }
+ else
+ {
+-shape.CreateChain(b_points.data(), b_points.size());
++shape.CreateChain(b_points.data(), b_points.size(), b2Vec2_zero, 
b2Vec2_zero);
+ }
+ 
+ createBody();
+@@ -271,7 +271,7 @@ void Collisionable::createBody(b2Shape*
+ }else{
+ b2BodyDef bodyDef;
+ bodyDef.type = static_physics ? b2_kinematicBody : b2_dynamicBody;
+-bodyDef.userData = this;
++bodyDef.userData.pointer = reinterpret_cast(this);
+ 

Bug#1057565: state of kalzium package, and metapackage dependencies on it.

[Mike Gabriel]

Hi Peter,

On  Sa 13 Apr 2024 19:23:07 CEST, Peter Green wrote:


kalzium needs to be rebuilt for the time64 transition, but it has had
a FTBFS bug with no maintainer response for 4 months. The only reverse
dependencies seem to be a number of metapackages.

In particular, the kdeedu package is a key package and has a hard
dependency on kalzium. This means that it can't be autoremoved from
testing, making it a blocker the time64 transition.

Is there someone who can step up and fix kalzium? or should
it be dropped from the metapackages so it can be removed from testing?

Metapackages built from the meta-kde source (key, hard dependencies)

* kdeedu

Metapackages built from the debian-edu source (key, but only reccomends):

* education-chemistry
* education-highschool
* education-primaryschool
* education-secondaryschool

Metapackages built from the debian-science source (not key, only reccomends):

* science-chemistry

Metapackages built from the debichem source (not key, only reccomends):

* debichem-visualisation


it seems the kalzium package has been upgraded last night and buildds  
look good.


So, ignore this mail? Or is anything else needed?

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



pgp_cRQx7uLAH.pgp
Description: Digitale PGP-Signatur

Bug#1000161: ITP: CLI to manage emails

[Jonas Smedegaard]

1.0.0~beta3 draft 1 needs embedding 60 crates (37 missing, 1 broken, 1 
incomplete, 8 outdated, 13 ahead); runs and seems to work from a brief test use.

Main task now is packaging remaining missing Rust crates.

Here's how you can help:

As user running Debian, you can test this draft package: Either build it
yourself from source or tell (by posting to this bugreport) if you
prefer testing the binary that I've built - then I will share that.

As developer (any developer: you need not be official member of Debian!)
you can join the Debian Rust team and help package these missing crates:
https://salsa.debian.org/debian/himalaya/-/blob/debian/latest/debian/TODO

 - 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#1068994: ITP: golang-github-errata-ai-regexp2 -- full featured regular expressions for Go

[Maytham Alsudany]

Package: wnpp
Severity: wishlist
Owner: Maytham Alsudany 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
Control: block 1066893 by -1

* Package name: golang-github-errata-ai-regexp2
  Version : 1.7.0
  Upstream Contact: Joseph Kato 
* URL : https://github.com/errata-ai/regexp2
* License : Expat
  Programming Lang: Go
  Description : full featured regular expressions for Go (library)

 errata-ai/regexp2 is a fork of dlclark/regexp2 providing a more similar API to
 regexp, such as "All" versions of Find functions, among other changes.

Dependency of vale.

This package will be maintained within the Debian Go Packaging Team.
I will need a DD to sponsor and upload this package.

--
Kind regards,
Maytham Alsudany


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

Bug#1068993: ITP: golang-github-d5-tengo -- fast script language for Go

[Maytham Alsudany]

Package: wnpp
Severity: wishlist
Owner: Maytham Alsudany 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
Control: block 1066893 by -1

* Package name: golang-github-d5-tengo
  Version : 2.17.0
  Upstream Contact: https://github.com/d5/tengo/issues
* URL : https://github.com/d5/tengo
* License : Expat
  Programming Lang: Go
  Description : fast script language for Go (library)

 Tengo is a small, dynamic, fast, secure script language for Go, as it's
 compiled/executed as bytecode on stack-based VM that's written in native Go.
 .
 This package contains the Golang library.

Dependency of vale.
Will be maintained in Go team, will need sponsor.

--
Kind regards,
Maytham Alsudany


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

Bug#1068992: ITP: golang-github-adrg-strutil -- Golang string utility functions

[Maytham Alsudany]

Package: wnpp
Severity: wishlist
Owner: Maytham Alsudany 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
Control: block 1066893 by -1

* Package name: golang-github-adrg-strutil
  Version : 0.3.1
  Upstream Contact: https://github.com/adrg/strutil/issues
* URL : https://github.com/adrg/strutil
* License : Expat
  Programming Lang: Go
  Description : Golang string utility functions (library)

 strutil provides a collection of string metrics for calculating string
 similarity as well as other string utility functions.
 .
 Full documentation can be found at https://pkg.go.dev/github.com/adrg/strutil.

Dependency of vale.
Will be maintained in Go team, will need sponsor.

--
Kind regards,
Maytham Alsudany


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

Bug#1068991: seriousproton: Uses the Game Team's git but is not team-maintained

[Bastian Germann]

Source: seriousproton
Version: 2019.05.21+dfsg-1

seriousproton uses a git repo within the Game Team's namespace but it is not 
team-maintained.
Please make it team-maintained or move the git repo.

Bug#1068849: cryptsetup: Fails to unlock the filesystem with missing libgcc_s.so.1

[Jan Katins]

I can not anymore reproduce the issue anymore: while trying to capture
the full error message, I created an initrd without libgcc_s in it and
it booted up. Below I added some--hopefully relevant-- parts of the
dpkg log and original requested phread output, maybe that still sheds
some light on this. If not I guess this can be closed.

On Fri, 12 Apr 2024 at 16:23, Guilhem Moulin  wrote:
> FWIW, I later noticed you used a splash screen (plymouth) and thought it

yes, sorry: GUI = Splash screen

> Otherwise, my guess is a race where the initramfs image was somehow
> rebuilt before libcryptsetup12 was upgraded, but AFAICT the dependencies
> are properly set to avoid that.  Does the broken initramfs image contain
> libargon2.so, if so does its libcryptsetup12 use it?

According to `lsinitramfs initrd.img-6.7.9-amd64 |grep libargon2.so`
it's not used.

I've saved away the dpkg.log and this is an excerpt (via `rg "trigproc
initramfs-tools|libcryptsetup12|libargon2|libssl3t64|libc6|libglib2|libgcc"
~/tmp/dpkg.log`) with added output from `rg "Start-Date|Commandline"
/var/log/apt/history.log`. The last two initramfs-tools trigger calls
should correspond to me trying to fix the problem by reinstalling some
packages and maybe not even realizing it's already fixed by the
dist-upgrade?

2:Start-Date: 2024-04-10  11:30:00
3:Commandline: apt upgrade -y
7:End-Date: 2024-04-10  11:33:19

87:2024-04-10 11:30:04 upgrade libgcc-13-dev:amd64 13.2.0-18 13.2.0-23
88:2024-04-10 11:30:04 status half-configured libgcc-13-dev:amd64 13.2.0-18
89:2024-04-10 11:30:04 status unpacked libgcc-13-dev:amd64 13.2.0-18
90:2024-04-10 11:30:04 status half-installed libgcc-13-dev:amd64 13.2.0-18
91:2024-04-10 11:30:04 status unpacked libgcc-13-dev:amd64 13.2.0-23
107:2024-04-10 11:30:06 upgrade libgcc-12-dev:amd64 12.3.0-15 12.3.0-17
108:2024-04-10 11:30:06 status half-configured libgcc-12-dev:amd64 12.3.0-15
109:2024-04-10 11:30:06 status unpacked libgcc-12-dev:amd64 12.3.0-15
110:2024-04-10 11:30:06 status half-installed libgcc-12-dev:amd64 12.3.0-15
111:2024-04-10 11:30:06 status unpacked libgcc-12-dev:amd64 12.3.0-17
158:2024-04-10 11:30:07 upgrade libgcc-s1:amd64 14-20240303-1 14-20240330-1
159:2024-04-10 11:30:07 status half-configured libgcc-s1:amd64 14-20240303-1
160:2024-04-10 11:30:07 status unpacked libgcc-s1:amd64 14-20240303-1
161:2024-04-10 11:30:07 status half-installed libgcc-s1:amd64 14-20240303-1
162:2024-04-10 11:30:07 status unpacked libgcc-s1:amd64 14-20240330-1
164:2024-04-10 11:30:07 configure libgcc-s1:amd64 14-20240330-1 
165:2024-04-10 11:30:07 status unpacked libgcc-s1:amd64 14-20240330-1
166:2024-04-10 11:30:07 status half-configured libgcc-s1:amd64 14-20240330-1
167:2024-04-10 11:30:07 status installed libgcc-s1:amd64 14-20240330-1
210:2024-04-10 11:30:08 upgrade libc6-dev:amd64 2.37-15.1 2.37-16
211:2024-04-10 11:30:08 status half-configured libc6-dev:amd64 2.37-15.1
212:2024-04-10 11:30:08 status unpacked libc6-dev:amd64 2.37-15.1
213:2024-04-10 11:30:08 status half-installed libc6-dev:amd64 2.37-15.1
214:2024-04-10 11:30:08 status unpacked libc6-dev:amd64 2.37-16
235:2024-04-10 11:30:09 upgrade libc6:amd64 2.37-15.1 2.37-16
236:2024-04-10 11:30:09 status half-configured libc6:amd64 2.37-15.1
237:2024-04-10 11:30:09 status unpacked libc6:amd64 2.37-15.1
238:2024-04-10 11:30:09 status half-installed libc6:amd64 2.37-15.1
239:2024-04-10 11:30:09 status unpacked libc6:amd64 2.37-16
241:2024-04-10 11:30:09 configure libc6:amd64 2.37-16 
242:2024-04-10 11:30:09 status unpacked libc6:amd64 2.37-16
243:2024-04-10 11:30:09 status half-configured libc6:amd64 2.37-16
244:2024-04-10 11:30:10 status installed libc6:amd64 2.37-16
755:2024-04-10 11:30:33 upgrade libgcc-11-dev:amd64 11.4.0-7 11.4.0-8
756:2024-04-10 11:30:33 status half-configured libgcc-11-dev:amd64 11.4.0-7
757:2024-04-10 11:30:33 status unpacked libgcc-11-dev:amd64 11.4.0-7
758:2024-04-10 11:30:33 status half-installed libgcc-11-dev:amd64 11.4.0-7
759:2024-04-10 11:30:34 status unpacked libgcc-11-dev:amd64 11.4.0-8
951:2024-04-10 11:30:43 status triggers-pending libglib2.0-0:amd64 2.78.4-1
1491:2024-04-10 11:31:04 upgrade libglib2.0-data:all 2.78.4-4 2.78.4-6
1492:2024-04-10 11:31:04 status half-configured libglib2.0-data:all 2.78.4-4
1493:2024-04-10 11:31:04 status unpacked libglib2.0-data:all 2.78.4-4
1494:2024-04-10 11:31:04 status half-installed libglib2.0-data:all 2.78.4-4
1495:2024-04-10 11:31:04 status unpacked libglib2.0-data:all 2.78.4-6
2711:2024-04-10 11:32:13 configure libglib2.0-data:all 2.78.4-6 
2712:2024-04-10 11:32:13 status unpacked libglib2.0-data:all 2.78.4-6
2713:2024-04-10 11:32:13 status half-configured libglib2.0-data:all 2.78.4-6
2714:2024-04-10 11:32:13 status installed libglib2.0-data:all 2.78.4-6
3527:2024-04-10 11:32:42 configure libgcc-12-dev:amd64 12.3.0-17 
3528:2024-04-10 11:32:42 status unpacked libgcc-12-dev:amd64 12.3.0-17
3529:2024-04-10 11:32:42 status half-configured libgcc-12-dev:amd64 12.3.0-17
3530:2024-04-10 11:32:42 

Bug#1068976: RM: dh-dlang [armel] -- ANAIS; no longer supported on armel

[Sebastian Ramacher]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: dh-dl...@packages.debian.org, sramac...@debian.org, 
d...@packages.debian.org, appstream-genera...@packages.debian.org, 
dcontain...@packages.debian.org, diet...@packages.debian.org, 
dlang-libev...@packages.debian.org, dlang-open...@packages.debian.org, 
gir-t...@packages.debian.org, gli...@packages.debian.org, 
gt...@packages.debian.org, mir-c...@packages.debian.org, 
mustach...@packages.debian.org, samba...@packages.debian.org, 
ti...@packages.debian.org, vib...@packages.debian.org
Control: affects -1 + src:dh-dlang
User: ftp.debian@packages.debian.org
Usertags: remove
Control: clone -1 -2 -3 -4 -5 -6 -7 -8 -9 -10 -11 -12 -13 -14 -15
Control: retitle -2 RM: dub [armel] -- ANAIS; no longer supported on armel
Control: retitle -3 RM: appstream-generator [armel] -- ANAIS; no longer 
supported on armel
Control: retitle -4 RM: dcontainers [armel] -- ANAIS; no longer supported on 
armel
Control: retitle -5 RM: diet-ng [armel] -- ANAIS; no longer supported on armel
Control: retitle -6 RM: dlang-libevent [armel] -- ANAIS; no longer supported on 
armel
Control: retitle -7 RM: dlang-openssl [armel] -- ANAIS; no longer supported on 
armel
Control: retitle -8 RM: gir-to-d [armel] -- ANAIS; no longer supported on armel
Control: retitle -9 RM: glib-d [armel] -- ANAIS; no longer supported on armel
Control: retitle -10 RM: gtk-d [armel] -- ANAIS; no longer supported on armel
Control: retitle -11 RM: mir-core [armel] -- ANAIS; no longer supported on armel
Control: retitle -12 RM: mustache-d [armel] -- ANAIS; no longer supported on 
armel
Control: retitle -13 RM: sambamba [armel] -- ANAIS; no longer supported on armel
Control: retitle -14 RM: tilix [armel] -- ANAIS; no longer supported on armel
Control: retitle -15 RM: vibe.d  [armel] -- ANAIS; no longer supported on armel

 dh-dlang (0.6.6) unstable; urgency=medium
 .
   * Make LDC default for riscv64, drop armel
   * Bump dh compat version
   * Bump compiler requirements

So please remove dh-dlang an the reverse dependencies from armel.

Cheers
-- 
Sebastian Ramacher

Bug#1068975: Abandoned upstream and unmaintained

[Andrey Rakhmatullin]

Source: python-zxcvbn
Version: 4.4.28-3
Severity: serious
Control: affects -1 pass-extension-audit pwdsphinx secrets

It was reported that the maintainer of this package seems to be MIA (and there
were no maintainer uploads since 2019). At the same time, the package upstream
seems to be dead: https://github.com/dwolfhub/zxcvbn-python/issues/73 (and
there were no commits since 2021 and no releases since 2019). As the upstream
bug correctly notes, this is a security-sensitive package, so it's worrying
that people can be relying on it while it's abandoned. Scott Kitterman even
suggested removing it from Debian but is has revdeps:

pass-extension-audit/src:pass-audit
The only upload to Debian in 2022, last upstream release 2022, zxcvbn is a hard
req per setup.cfg. Popcon 20. No revdeps.

pwdsphinx
All Debian uploads in 2023, last upstream release in 2023. zxcvbn (actually
zxcvbn-python, which is an older version of zxcvbn per
https://pypi.org/project/zxcvbn-python) is a hard req per setup.py. Popcon 2.
No revdeps outside the source package.

secrets
Fairly active both in Debian and upstream. A GNOME app. zxcvbn is a hard req
per meson.build. Popcon 224. No revdeps outside the source package.



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

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

Bug#1068775: sbuild-qemu: fails to work, if piuparts is requested, but not installed on the host

[Richard Lewis]

On Fri, 12 Apr 2024, 19:00 Johannes Schauer Marin Rodrigues, <
jo...@debian.org> wrote:

> Hi Francesco,
>
> Quoting Francesco Poli (wintermute) (2024-04-11 00:13:51)
> >
> >   sbuild --dist unstable --purge-build=never --purge-deps=never
> --chroot-mode=autopkgtest --autopkgtest-virt-server=qemu
> --autopkgtest-virt-server-opt --overlay-dir=/dev/shm
> --autopkgtest-virt-server-opt --qemu-architecture=x86_64
> --autopkgtest-virt-server-opt --ram-size=2048 --autopkgtest-virt-server-opt
> --cpus=2 --autopkgtest-virt-server-opt --boot=efi
> --autopkgtest-virt-server-opt
> /home/$USER/.cache/sbuild/unstable-autopkgtest-amd64.img
> --bd-uninstallable-explainer apt
> > Error reading configuration: PIUPARTS binary 'piuparts' does not exist
> or is not executable at /usr/share/perl5/Sbuild/Conf.pm line 76.
> >
> >



> > However, I thought that setting $run_piuparts = 1 in ~/.sbuildrc caused
> > piuparts to be run inside the virtual machine guest system, not on the
> > host system!
>
> What made you think that? Is the error message above not clear enough? Do
> you
> think it should be improved to make things clearer? Do you have
> suggestions for
> a message that would've better explained that piuparts needs to be
> installed on
> the host system?
>

Adding a data point, i would also like the error message to be clearer - i
know that once you understand how sbuild and piuparts work it becomes
"obvious" that piuparts needs to be run from the host -- but this is not at
all clear for new users: would be great if the documentation and errors
could clearly distinguish between which things inside/outside the chroot


This particular error message could be improved in at least 3 ways:
1. "Error reading configuration" -- suggests it couldnt parse the config
file, which doesnt seem to be the case here (suggest either dropping this
from the error message or saying more clearly what the issue is)

2. "PIUPARTS binary 'piuparts' does not exist or is not executable"

not sure why the capitials and repetition?  just say more directly what the
issue is: eg : "Error: piuparts not found (it needs to be installed on the
host)"

3.  "at /usr/share/perl5/Sbuild/Conf.pm line 76." -- not sure this
implementation detail is helpful for a user -- it makes it look a bug
rather than a message for the user: could it be dropped from the error
message or hidden behind a "debug"/"verbose" setting?


thanks for working on sbuild, it's really great.

Bug#1068974: python-designateclient: please drop python3-mock build dependency

[Alexandre Detiste]

Source: python-designateclient
Version: 6.0.1-2
Severity: normal


This project has switched to unittest.mock.

Greetings


tchet@brix /tmp/python-designateclient $ grep mock -r
debian/control: python3-mock,
designateclient/tests/osc/v2/test_recordsets.py:from unittest import mock
designateclient/tests/osc/v2/test_zone.py:from unittest import mock
designateclient/tests/test_utils.py:from unittest import mock
designateclient/tests/v2/test_nameservers.py:from unittest.mock import patch
designateclient/tests/v2/test_recordsets.py:from unittest.mock import patch
designateclient/tests/v2/test_timeout.py:from unittest.mock import Mock

Bug#1060594: dnf: Please switch Build-Depends to systemd-dev

[Luca Boccassi]

Control: close -1

On Thu, 11 Jan 2024 23:36:51 +0100 bi...@debian.org wrote:
> Source: dnf
> Version: 4.14.0-4.1
> Severity: normal
> User: pkg-systemd-maintain...@lists.alioth.debian.org
> Usertags: systemd-dev
> 
> Hi,
> 
> your package dnf declares a Build-Depends on systemd and/or udev.
> 
> In most cases, this build dependency is added to get the paths that
> are defined in udev.pc or systemd.pc (via pkgconfig).
> 
> Since systemd_253-2 [1], these two pkgconfig files have been split
> into a separate package named systemd-dev. This package is arch:all,
> so even available on non-Linux architectures, which will simplify the
> installation of upstream provided service files / udev rules.
> 
> To not make existing source packages FTBFS, the systemd and udev
> package have a Depends: systemd-dev. This dependency will be removed
> at some point though before trixie is released. Once this happens,
> this issue will be bumped to RC.
> 
> Please update your build dependencies accordingly at your earliest
> convenience.
> 
> If all you need is the systemd.pc or udev.pc pkgconfig file, please
> replace any systemd or udev Build-Depends with systemd-dev. In most
> cases that should be sufficient. If your package needs further
> resources from systemd or udev to build successfully, it's fine to
> keep those Build-Depends in addition to systemd-dev.
> 
> To ease stable backports, a version of systemd with those changes is
> provided via bookworm-backports.
> 
> In case you have further questions, please contact the systemd team
> at .
> 
> On behalf of the systemd team, Michael

DNF does not use systemd.pc, it uses systemd-tmpfiles during tests so
that's probably why the build dep was added

-- 
Kind regards,
Luca Boccassi

Bug#1068651: RFS: bisect-ppx/2.8.3-1 [ITP] -- Code coverage for OCaml and ReScript (dev files)

[Bo YU]

Hi,

On Tue, Apr 9, 2024 at 2:18 PM Stéphane Glondu  wrote:
>
> Dear Bo,
>
> Le 08/04/2024 à 17:05, Bo YU a écrit :
> > I am looking for a sponsor for my package "bisect-ppx":
> > [...]
>
> I've reviewed the packaging and I have a few comments.
>
> Standards-Version is not the latest.
>
> Upstream copyright years are missing in debian/copyright.
>
> A .cma file is in a "OPT:" line in an .install.in file.
>

Done.
> I would not override dh_dwz nor dh_strip. My opinion is that what you
> are trying to fix are deficiencies of the toolchain that should be fixed
> there.
First to address dh_strip issue. From what I've researched. The issue
was raised by the static library generated from bisect_ppx did not
obey the standard static library name scheme. The dh_strip[0] will
strip the static library with `lib-*` prefix. But as we can observe
the building:
```
I: libbisect-ppx-ocaml-dev: unstripped-static-library
(bisect__Runtime.o) [usr/lib/ocaml/bisect_ppx/runtime/bisect.a]
I: libbisect-ppx-ocaml-dev: unstripped-static-library
(bisect_common.o) [usr/lib/ocaml/bisect_ppx/common/bisect_common.a]
I: libbisect-ppx-ocaml-dev: unstripped-static-library
(bisect_ppx__Exclude.o bisect_ppx__Exclude_lexer.o
bisect_ppx__Exclude_parser.o bisect_ppx
__Exclusions.o bisect_ppx__Instrument.o bisect_ppx__Register.o)
[usr/lib/ocaml/bisect_ppx/bisect_ppx.a]
```
In fact, the original solution is that I refer to this[1]. But I am
not sure if this is a toolchain issue or not, so I have reported this
to upstream[2] also. The workaround for this issue I could think of:
1. Keep those lintian messages here and open a reportbug to track the
issue until upstream fix the issue;
2. Use the solution like [1] as my previous post and open a reportbug
to track the issue until upstream fix the issue;
3. Wait to upstream to fix this issue;
4. Persuading the maintainers of debhelper to strip static library
with broader name scheme.But I think this is not a good wishlist.:)
Personally I prefer to option 2 still.

For dh_dwz issue. It seems that the issue will be fixed by passing
`--no-dwz-multifile` arg. In my understanding, there is two ELF
binaries on the debug package, so the no-mutlifile arg can assure
dropping `../.dwz/../.debug`.

[0]: https://github.com/Debian/debhelper/blob/master/dh_strip#L239C2-L244C27
[1]: https://lists.debian.org/debian-mentors/2015/10/msg00027.html
[2]: https://github.com/aantron/bisect_ppx/issues/439
>
> It is not right to override source-contains-prebuilt-javascript-object
> in this case; you should filter the .js file out and make sure the
> package works without it. Or get the actual sources and build from them.
> Or find it in another Debian package. (These are just examples of how to
> tackle the issue.)
Okay, I repacked it by removing the prebuilt javascript file and put
its source code which pulled from upstream into debian/missing-sources
and then to get the file during the building.

>
> I am wondering about long-term maintainability of the manpage. I suppose
> you've generated the manpage from running the command with --help?
> Please make a rule to automatically generate it.

Done.

All commits I have pushed into the salsa [3] and mentor[4].

Thanks for your time again and please let me know any issues.

BR,
Bo

[3]: https://salsa.debian.org/ocaml-team/bisect-ppx
[4]: https://mentors.debian.net/package/bisect-ppx/


>
>
> Thank you for your work,
>
> --
> Stéphane
>

Bug#1068973: include upstream zsh completion

[VA]

Package: eza
Version: 0.18.9-1

Upstream has it: 
https://github.com/eza-community/eza/blob/main/completions/zsh/_eza

Should be put in /usr/share/zsh/vendor-completions I guess

Bug#1068972: live-build: Live-buiild doesn´t make the ISO.

[Marcelo]

Package: live-build
Version: 1:20230502
Severity: important
X-Debbugs-Cc: mmnegre...@gmail.com

Dear Maintainer,

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

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

*** End of the template - remove these template lines ***
Log:
...
Need to get 0 B/3474 kB of archives.
After this operation, 15.4 MB of additional disk space will be used.
Download complete and in download only mode
http://deb.debian.org/debian%20bullseye%20main%20contrib%20non-
free/dists/bullseye/contrib/binary-amd64/Release:
2024-04-14 11:10:58 ERRO 404: Not Found.
E: Could not download file: http://deb.debian.org/debian bullseye main contrib
non-free/dists/bullseye/contrib/binary-amd64/Release
E: An unexpected failure occurred, exiting...
P: Begin unmounting filesystems...
P: Saving caches...
Reading package lists... Done
Building dependency tree... Done


-- Package-specific info:

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

Kernel: Linux 6.8.6.mmn (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.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 live-build depends on:
ii  debootstrap  1.0.128+nmu2+deb12u1

Versions of packages live-build recommends:
ii  apt-utils   2.6.1
ii  bzip2   1.0.8-5+b1
ii  cpio2.13+dfsg-7.1
ii  cryptsetup  2:2.6.1-4~deb12u2
ii  file1:5.44-3
ii  live-boot-doc   1:20230131
ii  live-config-doc 11.0.3+nmu1
ii  live-manual-epub [live-manual]  2:20151217.2
ii  live-manual-html [live-manual]  2:20151217.2
ii  live-manual-odf [live-manual]   2:20151217.2
ii  live-manual-pdf [live-manual]   2:20151217.2
ii  live-manual-txt [live-manual]   2:20151217.2
ii  rsync   3.2.7-1
ii  systemd-container   252.22-1~deb12u1
ii  wget1.21.3-1+b2
ii  xz-utils5.4.1-0.2

Versions of packages live-build suggests:
ii  e2fsprogs  1.47.0-2
pn  mtd-utils  
ii  parted 3.5-3

-- no debconf information

Bug#887139: d-i daily 2018-01-14 amd64 damages UEFI setup on Fujitsu Lifebook AH532

[Tim Schumacher]

A kernel-based workaround for the underlying issue has now landed
in all currently supported linux-stable branches:

linux-6.8:  6.8-rc7  (f45812cc23fb74bef62d4eb8a69fe7218f4b9f2a)
linux-6.7:  6.7.9(cbf12e716a52d260fabecdca7d5f6e7cd07aed6c)
linux-6.6:  6.6.21   (71da10e633a96593cf59af3f322a9c49a22cb71e)
linux-6.1:  6.1.81   (249d6ca4ff0022a4b51a8eb9fac6d7bff2c94d1b)
linux-5.15: 5.15.154 (9bc9c11c151ab27214cc204d954ee902e9bbe8e2)
linux-5.10: 5.10.215 (f33255ccbb0f627da76364cce72cf980d027142c)
linux-5.4:  5.4.274  (34b5d2ff9ed5cdea9f971f394c0d623761a4d357)
linux-4.19: 4.19.312 (a7bd7dbaa2ddcf8c5ed5d96df240f1442447d252)

Unfortunately, said kernel has to be used during installation,
so the issue won't be fixed in practice until the next set of
installation images are built.

Afterwards, this issue can probably be considered "fixed", at
least with regards to the Fujitsu Lifebook AH532 (and extended
family). The other bug report for the Dell Latitude 5510 seems
to be unrelated.

Bug#1052028: please update to pydantic 2.x

[Alexandre Detiste]

Hi,

Now that pydantic-core is available,
I started packaging v2.7.

There's a lot left to do, especially for dataclasses.

Greetings

tests/test_dataclasses.py FF [ 10%]
FF.F.FFFsFFF [ 12%]
FFFFFFssFFFF [ 14%]
FFF.

Bug#877337: single-page html of debian-policy to be revived?

[Sean Whitton]

Hello,

On Sun 14 Apr 2024 at 01:57pm +02, Holger Wansing wrote:

> 1.
> Currently, the package does not ship this version. So this would have to
> be re-added there.

The changelog for 4.2.0.0 says

  * Stop installing policy-1.html because Sphinx's singlehtml output is
too buggy at present (Closes: #873456, #876075, #879048).
See also #877367.  Thanks to Paul Wise for switching the web mirrors
away from policy-1.html.

I had forgotten about this.  It seems that the first thing to do would
be to determine if the issues discussed in those bugs still exist.

> 2.
> There are pro's and con's for both the single-page and multi-page variants.
> Thus the only possible way IMO is to ship both via www.d.o.
> The developers-refererence also ships both already, so it would be consistent
> there.

... but if dev-ref is already shipping both, maybe singlepage is indeed
usable these days ...

> Could the Policy Editors team check, if everything is fine now, and if
> this should be published again?
> At least there is still an issue with the footnotes, there are 16 occurrences
> of #id1 for example... (search for "[1]" in policy-1.html).

Hrm.  That seems like a pretty serious problem :\

Holger L., did you know about this issue?
Did you decide it was worth publishing anyway?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1068927: ITP: rust-event-listener-strategy -- block or poll on event_listener easily

[Jonas Smedegaard]

Quoting James McCoy (2024-04-14 14:26:44)
> On Sat, Apr 13, 2024 at 04:10:31PM +0200, Jonas Smedegaard wrote:
> >  event-listener-strategy  provides a strategy
> >  for using the event-listener crate
> >  in both blocking and non-blocking contexts.
> 
> Matthias already packaged this and it's sitting in NEW.

Yes. Thank you.

Please see my response to Matthias and the debian-devel list here:
https://bugs.debian.org/1068927#15

 - 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#1068957: ITP: gnome-shell-extension-vertical-workspaces -- A GNOME Shell extension that lets you customize your GNOME Shell UX to suit your workflow, whether you like horizontally or vertically st

[Daniel Baumann]

Hi Tobias,

On 4/14/24 13:55, Tobias Frost wrote:

As I have the package ready, I'd like to propose to maintain it as new
package


In January 2023 I've uploaded gnome-shell-extension-vertical-workspaces 
(and 5 other extensions) as individual source packages as every other 
gnome-shell extension is packaged in Debian.


ftp-master rejected all of them and insisted, that I create an artifical 
package (one src producing one binary) containing all 6 extensions 
together. This is how gnome-shell-extension-vertical-workspaces is 
included in bookworm and anything newer. You can read more about this in 
#1030683.


I don't think ftp-master has changed their opinion. If they did, I'm 
happy to break it up and re-upload the extensions as individual packages 
again like I did in the first place in January 2023.


ftp-master/Thorsten: What is your current opinion, can I upload the 
extensions as individual extensions again, or do we have to keep the 
aggregation package?


Regards,
Daniel

Bug#1068927: ITP: rust-event-listener-strategy -- block or poll on event_listener easily

[James McCoy]

On Sat, Apr 13, 2024 at 04:10:31PM +0200, Jonas Smedegaard wrote:
>  event-listener-strategy  provides a strategy
>  for using the event-listener crate
>  in both blocking and non-blocking contexts.

Matthias already packaged this and it's sitting in NEW.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#1057586: nvda2speechd: FTBFS: error: failed to run custom build command for `speech-dispatcher-sys v0.7.0`

[Santiago Vila]

El 14/4/24 a las 13:25, Sylvestre Ledru escribió:

I am sorry but I am not sure to see how it is actionable.

Without a test case, i don't think there is much I can do here.


The test case is that nvda2speechd fails to build from source.
 

With rust, cargo, custom build script, there are many things that can go wrong 
before LLVM.

Sebastian, I think it could be move to normal. From LLVM perspective, it isn't 
serious severity (many programs are built with LLVM 16).


We can release trixie with compilers having bugs, but I don't think it would be 
ok at
all to release trixie as stable with packages which do not build from source, 
that would
be against Release Policy.

So, in my opinion, this is still RC, either in the compiler or in the package 
failing
to build. If solving this in the compiler is too complex, then the bug should 
be reassigned back to src:nvda2speechd.

Thanks.

Bug#1068971: python-ironic-inspector-client: please remove extraneous dependency on python3-six

[Alexandre Detiste]

Source: python-ironic-inspector-client
Version: 5.1.0-2
Severity: normal

Usage of six has already been removed upstream.

Greetings

tchet@brix /tmp/python-ironic-inspector-client $ grep six -r
debian/control: python3-six,
debian/control: python3-six,
tchet@brix /tmp/python-ironic-inspector-client $

Bug#1068101: RFS ping mini-httpd/1.30-10 -- Small HTTP server

[Alexandru Mihail]

Hello,
Thanks for your help !

> I had a look.
> 
> It's not called "SystemD".
You're correct, I'll fix the typo :)
> 
> Why is this line commented?
> 
> #PrivateUsers=yes
This should have been deleted. I will fix that. I was doing some
experiments with PrivateUsers which turned out to make CGI scripts
unusable, so it's off the table.
> 
> 
> I think your patch presumes that the filesystem is utf-8 encoded and
> would 
> break in other (admittedly rare) cases. Just FYI.

This is fine; The utf8 charset encoding is sent when the client
requests directory listings and error pages (that's what the patch
does). This is standard, expected behaviour for a web server. (From the
web: Because it is the default all modern browsers will use utf-8
without being explicitly told to do so. It remains in meta data as a
common good practice)
> 
> Commits on salsa introduce unrelated changes in 1 single commit.
> 
> Did you submit the patches to upstream? Is upstream active?

Upstream is sadly defunct for all intents and purposes. Patches have
been forwarded long before I took over mini-httpd (a year ago) and no
news were heard for a really long time. I think the last upstream
release happened more than 5-6 years ago (1.30). That's the reason
we're on 1.30-10 now :). I discussed these matters with other members
in Debian as well; I could forward everything but sadly as far as I
know, nobody would read them. We're the upstream for now.
> 
> Your changes to the .service file might break CGI scripts that might
> be having 
> access to all sort of things. I think a news file should be added to
> warn users 
> of the possibly breaking changes.
You're right, a news file is in order. I will start writing one today.
The good part is that the systemd service is rather new (2 releases
ago) so not many people adopted it yet. The chance of functioning
setups just breaking is lower, then. I will write a news entry, anyway.
> 
Thanks for your review, I'll have a better release ready in a bit.

Have a great one,
Alexandru Mihail


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

Bug#1068970: python-glance-store: please remove extraneous dependency on python3-six

[Alexandre Detiste]

Source: python-glance-store
Version: 4.7.0-2
Severity: normal

usage of sux is already gone

$ grep six -r
debian/control: python3-six,
debian/control: python3-six,
+ some upstream release notes that says six usage hss been removed

Bug#1068969: csound-utils installs /usr/bin/extractor which has no manual page.

[Martin Guy]

Package: csound-utils
Version: 1:6.18.1+dfsg-1
Severity: normal
X-Debbugs-Cc: martinw...@gmail.com

extractor --help says

--Csound version 6.18 (double samples) 2022-11-24
[commit: none]
libsndfile-1.2.0
util extractor:
Usage:  extractor [-flags] soundfile
Legal flags are:
-o fnamesound output filename
-N  notify (ring the bell) when done
-S integer  sample number at which to start file
-Z integer  sample number at which to end file
-Q integer  number of samples to read
-T fpnumtime in secs at which to start file
-E fpnumtime in secs at which to end file
-D fpnumduration in secs of extract
-R  Rewrite header
-H  Heartbeat
-v  verbose mode for debugging
-- fnameLog output to file
flag defaults: extractor -otest -S 0
extractor: error: unknown flag --
end of score.  overall amps:  0.0
   overall samples out of range:0
0 errors in performance
Elapsed time at end of performance: real: 0.001s, CPU: 0.000s

so I guess it's some kind of sound convertor.
A manual page saying what it is and what it does and how to use it
would be nice.

-- System Information:
Debian Release: 12.5
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable'), (500, 'stable'), (500, 'oldstable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 6.1.0-15-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages csound-utils depends on:
ii  csound   1:6.18.1+dfsg-1
ii  libc62.36-9+deb12u4
ii  libcsound64-6.0  1:6.18.1+dfsg-1
ii  libsamplerate0   0.2.2-3
ii  libsndfile1  1.2.0-1

csound-utils recommends no packages.

csound-utils suggests no packages.

-- no debconf information

Bug#877337: single-page html of debian-policy to be revived?

[Holger Wansing]

Hi,

Sean Whitton  wrote (Sun, 14 Apr 2024 12:27:34 +0800):
> On Thu 11 Apr 2024 at 08:32am GMT, Holger Levsen wrote:
> 
> > On Thu, Apr 11, 2024 at 09:18:06AM +0200, Thomas Lange wrote:
> >> A single page html may be an additional option but there's already the
> >> single page txt version and the PDF. That's sufficient and I see no
> >> need in providing more formats of this manual.
> >>
> >> Therefore we can close this and I will close 877337.
> >
> > fwiw, I disagree with this conclusion. single page txt and pdf versions
> > are no replacements for single page html.
> 
> I agree, and still think we should be publishing the single page version.

1.
Currently, the package does not ship this version. So this would have to
be re-added there.

2.
There are pro's and con's for both the single-page and multi-page variants.
Thus the only possible way IMO is to ship both via www.d.o.
The developers-refererence also ships both already, so it would be consistent 
there.
To make the existing mechanism work, which finds both variants on the
web mirrors via webwml, the single-page html file needs to be named
debian-policy.html:
https://salsa.debian.org/webmaster-team/webwml/-/blob/master/english/doc/devel-manuals.defs?ref_type=heads
That needs to be dealed with in the package, just renaming the file does not 
work, since it would break all the internal links.
(Don't know how it worked in the past on the website with the file being named 
policy-1.html though.)

3.
There were several bugs (e.g. #873456, #876075, #879048) with the single-page
html version. Are they known to be solved now?
Sphinx has received much development in the past 7 years, so there may be a
chance to have them fixed ... (?)
To get an idea of where we stand, I have built latest version of debian-policy
with re-activated singlehtml variant (build via sbuild, so with latest Sphinx
version), made the copy-and-rename dance which happens on wolkenstein for 
publication on www.d.o and pushed the result at
https://people.debian.org/~holgerw/debian-policy-with-singlehtml/

The multi-page html is found via
https://people.debian.org/~holgerw/debian-policy-with-singlehtml/debian-policy/index.html

while single-page html is at
https://people.debian.org/~holgerw/debian-policy-with-singlehtml/debian-policy/policy-1.html


Could the Policy Editors team check, if everything is fine now, and if 
this should be published again?
At least there is still an issue with the footnotes, there are 16 occurrences
of #id1 for example... (search for "[1]" in policy-1.html).


So long
Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1068957: ITP: gnome-shell-extension-vertical-workspaces -- A GNOME Shell extension that lets you customize your GNOME Shell UX to suit your workflow, whether you like horizontally or vertically st

[Tobias Frost]

On Sun, Apr 14, 2024 at 01:40:30PM +0200, Daniel Baumann wrote:
> Hi Tobias,
> 
> On 4/14/24 10:14, Tobias Frost wrote:
> > * Package name: gnome-shell-extension-vertical-workspaces
> 
> this is already included in src:gnome-shell-extensions-extra.

Thanks for noticing…
As I have the package ready, I'd like to propose to maintain it as new
package, would that be ok for you? (If you wish, we can co-maintain as
well.)

Cheers,
--
tobi

> Regards,
> Daniel

Bug#1068957: ITP: gnome-shell-extension-vertical-workspaces -- A GNOME Shell extension that lets you customize your GNOME Shell UX to suit your workflow, whether you like horizontally or vertically st

[Daniel Baumann]

Hi Tobias,

On 4/14/24 10:14, Tobias Frost wrote:

* Package name: gnome-shell-extension-vertical-workspaces


this is already included in src:gnome-shell-extensions-extra.

Regards,
Daniel

Bug#1066216: hfsutils: diff for NMU version 3.2.6-15.1

[Sebastian Ramacher]

On 2024-04-14 13:13:43 +0200, John Paul Adrian Glaubitz wrote:
> On Sun, 2024-04-14 at 12:57 +0200, Sebastian Ramacher wrote:
> > I've prepared an NMU for hfsutils (versioned as 3.2.6-15.1) and
> > uploaded it to DELAYED/2. Please feel free to tell me if I
> > should delay it longer.
> 
> Yes, please set it to 14 days. I am currently going through all
> my packages one after another to fix these issues.

Rescheduled.

Cheers
-- 
Sebastian Ramacher

Bug#1068968: pytools: please package v2024.1.1

[Alexandre Detiste]

Source: pytools
Version: 2023.1.1-1
Severity: wishlist


(I'm creating this bug to help triage 
https://wiki.debian.org/Python3-six-removal)

Greetings

Bug#1042906: ansible: please package new upstream version 8.x

[Lee Garrett]

Hi, I'll try to upload a new version of ansible and ansible-core within the next 
week.


On 14.04.24 10:00, Daniel Baumann wrote:

retitle 1042906 please package new upstream version 9.x
thanks

Hi Lee,

any updates since last year? Ansible is currently at 9.x and I'd really
like to be able to use a recent enough version of ansible via debian
packages. Is there anything I could help you with?

Regards,
Daniel

Bug#1068967: freezer-api: please remove extraneous dependency on python3-six

[Alexandre Detiste]

Source: freezer-api
Version: 15.0.0-1
Severity: normal

It's already removed upstream.

Greetings

tchet@brix /tmp/freezer-api $ grep six -r
debian/control: python3-six,
debian/control: python3-six,
tchet@brix /tmp/freezer-api $ 

Bug#1068966: librust-sha3-dev: please provide feature oid

[Jonas Smedegaard]

Package: librust-sha3-dev
Version: 0.10.2-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please provide feature oid, available since release v0.10.5.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmYbv7AACgkQLHwxRsGg
ASFBVQ/9GoN3Tq8v6GsGoy8F0vPIFDn6wsWGBg579Mh+aNXvp1jS/WMGMRsGVT2y
j2FOuItId7gLDQP5wfyM4UMF6a5ncq8L+OunBZdwishk8QljZvuSv0q+aTF0207l
NJngz3d2qRK9weUyzUzqq/iTy/k+4+JajvgOhjmYccC4zqbZiyACVn43BnBn8z2I
Eb9AbpunvlDAxnpPc3lm6GqRBgsC3n9z38MuhbIXhRmCMW1IFkg8vQWk8Ud4fMNj
2mikc/Tkr4jYrvEVJyQCTnGe38AW5w84Jl5wcOJlz9wDWOUyLXVps/VAU6pTutBg
uQaUY3Vj9vJyFqYKn9FKgr+c99wi1AfsfAFr5kArEzYgjaRigX3Okg9lDS5RnV9Z
9XMeXsUg3AwMeOzXa3V5YaWjp0P+wOuCR6BKm2Pd+lFiU07GR/s7/GNM9umhzh47
yGyauF7eHDEIDz2B5nJc39Moez6tjrIxxoQngO9XHsmjgmAXmsd6N6D1FF6CWDvy
328FeFVR7v5Hm4ZUXCJ2cf55TfizYQFHfMv2OGdtArRPtbH7GHuOb27d2xMugj+x
BVGjN40eK3PGIpMEUzlwDqIe21yqs2WOW39kfz+msQvtsIjup88ZXTcAGejQmSeR
xCpuGSr5JumXI1yDflnJm1r/Cc7UnATK6DsotdCHKcsQOCgxBgE=
=8kfV
-END PGP SIGNATURE-

Bug#1036596: python3-lldb-14: broken symlinks: /usr/lib/llvm-14/lib/python3/dist-packages/lldb/libLLVM-14.so.1 etc.

[Sylvestre Ledru]

Hello

Sorry for my lack of answer.

LLVM 14 was already deprecated when this bug has been filed. I don't 
think we should spend much time on this issue.


llvm 14 removal is #1050069

Cheers,
S

Le 23/05/2023 à 09:51, Andreas Beckmann a écrit :

Package: python3-lldb-14
Version: 1:14.0.6-12
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
broken symlinks:

0m35.0s ERROR: FAIL: Broken symlinks:
   
/usr/lib/llvm-14/lib/python3.11/dist-packages/lldb/_lldb.cpython-311-x86_64-linux-gnu.so
 -> ../../../../../lib/liblldb.so (python3-lldb-14)
   /usr/lib/llvm-14/lib/python3.11/dist-packages/lldb/lldb-argdumper -> 
../../../../../bin/lldb-argdumper (python3-lldb-14)
   /usr/lib/llvm-14/lib/python3/dist-packages/lldb/libLLVM-14.0.6.so.1 -> 
../../../../../x86_64-linux-gnu/libLLVM-14.0.6.so.1 (python3-lldb-14)
   /usr/lib/llvm-14/lib/python3/dist-packages/lldb/libLLVM-14.so.1 -> 
../../../../../x86_64-linux-gnu/libLLVM-14.0.6.so.1 (python3-lldb-14)

Possible target replacements are
   liblldb.so: /usr/lib/llvm-14/lib/python3/dist-packages/lldb/_lldb.so
   libLLVM-14.0.6.so.1: /usr/lib//libLLVM-14.so.1
   lldb-argdumper: /usr/lib/llvm-14/bin/lldb-argdumper
 (there is currently one level of '..' too much)


cheers,

Andreas

Bug#1068965: python-doc8: please remove extraneous dependency on python3-six

[Alexandre Detiste]

Source: python-doc8
Version: 0.10.1-3
Severity: normal

It's already gone upstream.

Greetings

tchet@brix /tmp/python-doc8 $ grep six -r
debian/control: python3-six,
debian/control: python3-six,
tchet@brix /tmp/python-doc8 $ 

Bug#1057586: nvda2speechd: FTBFS: error: failed to run custom build command for `speech-dispatcher-sys v0.7.0`

[Sylvestre Ledru]

Hello

I am sorry but I am not sure to see how it is actionable.

Without a test case, i don't think there is much I can do here.

With rust, cargo, custom build script, there are many things that can go 
wrong before LLVM.


Sebastian, I think it could be move to normal. From LLVM perspective, it 
isn't serious severity (many programs are built with LLVM 16).


Cheers
Sylvestre


Le 06/12/2023 à 02:13, Samuel Thibault a écrit :

Control: reassign -1 libclang1-16

Sorry, I meant to reassign to libclang1-16 of course.

Bug#1067676: gpick: diff for NMU version 0.2.6-1.1

[Sebastian Ramacher]

Control: tags 1067676 + patch


Dear maintainer,

I've prepared an NMU for gpick (versioned as 0.2.6-1.1). The diff
is attached to this message.

Cheers


-- 
Sebastian Ramacher
diff -Nru gpick-0.2.6/debian/changelog gpick-0.2.6/debian/changelog
--- gpick-0.2.6/debian/changelog	2021-01-12 01:33:16.0 +0100
+++ gpick-0.2.6/debian/changelog	2024-04-14 13:17:18.0 +0200
@@ -1,3 +1,11 @@
+gpick (0.2.6-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control: build depend on -dev packages instead of shared libraries
+(Closes: #1067676)
+
+ -- Sebastian Ramacher   Sun, 14 Apr 2024 13:17:18 +0200
+
 gpick (0.2.6-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru gpick-0.2.6/debian/control gpick-0.2.6/debian/control
--- gpick-0.2.6/debian/control	2021-01-12 01:33:16.0 +0100
+++ gpick-0.2.6/debian/control	2024-04-14 13:16:23.0 +0200
@@ -2,8 +2,8 @@
 Section: graphics
 Priority: optional
 Maintainer: Elías Alejandro Año Mendoza 
-Build-Depends: debhelper-compat (= 13), cmake, libcairo2 (>=1.6),
- libglib2.0-0 (>=2.16), libgtk-3-dev, liblua5.4-dev (>= 5.4),
+Build-Depends: debhelper-compat (= 13), cmake, libcairo2-dev (>=1.6),
+ libglib2.0-dev (>=2.16), libgtk-3-dev, liblua5.4-dev (>= 5.4),
  libboost-dev, libexpat1-dev, lemon, flex, ragel, gettext,
  libboost-test-dev, libboost-system-dev, libboost-filesystem-dev
 Standards-Version: 4.5.1

Bug#1068964: rust-strum: please upgrade to v0.26

[Jonas Smedegaard]

Source: rust-strum
Version: 0.25.0-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade to, or separately provide, branch v0.26.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmYbuh0ACgkQLHwxRsGg
ASF6ZQ/6AsEtYZYkOEsK43wLxHLA1sS/L3LnMfFy5svWX9ZwASqQQIgHHxLUhwUa
KjVkq/By3g3Mq0KnVgRLen7bMYrbcpb0NQ5QxFXT4oF9FQZcgFGI/nfo5VrSSpNU
ZlTsmfZIt+9NeWlxAYBPhdXeNYA6r2BtFF5kWpyhvv9qgkG15Z552eSNPFRVTrYX
57SrmTH5WOLoBJsfMPRGHES8GZ1ceEVRtwjgfdZuV2WQ35HgidpUMZ2wWOPu6oba
Xn9A22/ST/9PassM5Bi+fL5qT48PQdtL5jDiUDfX8+nFWeoUxP+WsGMhXbkfpN24
T6nrr1mtEUJ94O3h7uY9i6C0Am1IOF06B+7bnf1HjEhQoKP5pfXXJCa8Cq+JvVUu
SqJ5RnFCVLIwDw+5myNqo/VFU1k0kpOcnWu4cgC69IxM04HVum7H+N8vD1XBUCgw
UTeLh+QcN0RnN06ijIIxkK7BHGBBy1o7PG+skIlAcKZqCgGIrNgDGBePQK68lZpK
mDy45Ep3N1ttK+O8uoCuW5mEhYROOtglFAVs9xEaWFhS3A0KYI22/orHzKxAdyB+
/z8Yxbm/F/oXYFJWPK3b6M62jqmJwk34Fb2wabqZ3hBwFFkdTCF8lVVby9wd1i/+
SYhLaBMY1jm9kd0p+lU2M6LjZq10bjnB2gVYLukYb2Aie7nL1Y0=
=Td3a
-END PGP SIGNATURE-

Bug#1066216: hfsutils: diff for NMU version 3.2.6-15.1

[John Paul Adrian Glaubitz]

On Sun, 2024-04-14 at 12:57 +0200, Sebastian Ramacher wrote:
> I've prepared an NMU for hfsutils (versioned as 3.2.6-15.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.

Yes, please set it to 14 days. I am currently going through all
my packages one after another to fix these issues.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1068961: llvm-toolchain-18: block migration to testing: to many llvm-toolchain versions in testing

[Sylvestre Ledru]

Le 14/04/2024 à 12:49, Sebastian Ramacher a écrit :

Source: llvm-toolchain-18
Version: 1:18.1.3-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org, debian-rele...@lists.debian.org

Currently we we have llvm-toolchain-{14,15,16,17} in testing whereas RC
bugs in the verious versions of llvm-toolchain do not get addressed:

#1067005 in llvm-toolchain-18
#1068185 and #1057586 in llvm-toolchain-16
#1036596 and #1068840 in llvm-toolchain-14

Seeing that some of the bugs are unaddressed for a long time, that many
versions of llvm-toolchain in the archive seem to be to much to handle
for the maintainers. As there is also no progress in removing old
versions from the archive, I propose to not let any new versions of
llvm-toolchain-X migrate to trixie until the number of versions is
reduced to a maintainable number.

Please do not downgrade or close this bug report before contacting the
release team.


Agreed. I will have a look to the various issues in the next few weeks.

Cheers

Sylvestre

Bug#1068963: python-falcon: FTBFS: testsuite failure: 3084 passed, 313 skipped, 170 warnings, 35 errors

[Aurelien Jarno]

Source: python-falcon
Version: 3.1.1-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear maintainer,

python-falcon fails to build from source due to errors in the testsuite.
>From my build log on amd64:

| === short test summary info 

| ERROR 
tests/asgi/test_asgi_servers.py::TestASGIServer::test_get[_uvicorn_factory]
| ERROR 
tests/asgi/test_asgi_servers.py::TestASGIServer::test_put[_uvicorn_factory]
| ERROR 
tests/asgi/test_asgi_servers.py::TestASGIServer::test_head_405[_uvicorn_factory]
| ERROR 
tests/asgi/test_asgi_servers.py::TestASGIServer::test_post_multipart_form[_uvicorn_factory]
| ERROR 
tests/asgi/test_asgi_servers.py::TestASGIServer::test_post_multiple[_uvicorn_factory]
| ERROR 
tests/asgi/test_asgi_servers.py::TestASGIServer::test_post_invalid_content_length[_uvicorn_factory]
| ERROR 
tests/asgi/test_asgi_servers.py::TestASGIServer::test_post_read_bounded_stream[_uvicorn_factory]
| ERROR 
tests/asgi/test_asgi_servers.py::TestASGIServer::test_post_read_bounded_stream_large[_uvicorn_factory]
| ERROR 
tests/asgi/test_asgi_servers.py::TestASGIServer::test_post_read_bounded_stream_no_body[_uvicorn_factory]
| ERROR 
tests/asgi/test_asgi_servers.py::TestASGIServer::test_sse[_uvicorn_factory]
| ERROR 
tests/asgi/test_asgi_servers.py::TestASGIServer::test_sse_client_disconnects_early[_uvicorn_factory]
| ERROR 
tests/asgi/test_asgi_servers.py::TestASGIServer::test_stream_chunked_request[_uvicorn_factory]
| ERROR 
tests/asgi/test_asgi_servers.py::TestWebSocket::test_hello[_uvicorn_factory-None-True]
| ERROR 
tests/asgi/test_asgi_servers.py::TestWebSocket::test_hello[_uvicorn_factory-None-False]
| ERROR 
tests/asgi/test_asgi_servers.py::TestWebSocket::test_hello[_uvicorn_factory-4321-True]
| ERROR 
tests/asgi/test_asgi_servers.py::TestWebSocket::test_hello[_uvicorn_factory-4321-False]
| ERROR 
tests/asgi/test_asgi_servers.py::TestWebSocket::test_rejected[_uvicorn_factory-None-True]
| ERROR 
tests/asgi/test_asgi_servers.py::TestWebSocket::test_rejected[_uvicorn_factory-None-False]
| ERROR 
tests/asgi/test_asgi_servers.py::TestWebSocket::test_rejected[_uvicorn_factory-4040-True]
| ERROR 
tests/asgi/test_asgi_servers.py::TestWebSocket::test_rejected[_uvicorn_factory-4040-False]
| ERROR 
tests/asgi/test_asgi_servers.py::TestWebSocket::test_missing_responder[_uvicorn_factory]
| ERROR 
tests/asgi/test_asgi_servers.py::TestWebSocket::test_select_subprotocol_known[_uvicorn_factory-*-amqp]
| ERROR 
tests/asgi/test_asgi_servers.py::TestWebSocket::test_select_subprotocol_known[_uvicorn_factory-wamp-wamp]
| ERROR 
tests/asgi/test_asgi_servers.py::TestWebSocket::test_select_subprotocol_unknown[_uvicorn_factory]
| ERROR 
tests/asgi/test_asgi_servers.py::TestWebSocket::test_disconnecting_client_early[_uvicorn_factory]
| ERROR 
tests/asgi/test_asgi_servers.py::TestWebSocket::test_send_before_accept[_uvicorn_factory]
| ERROR 
tests/asgi/test_asgi_servers.py::TestWebSocket::test_recv_before_accept[_uvicorn_factory]
| ERROR 
tests/asgi/test_asgi_servers.py::TestWebSocket::test_invalid_close_code[_uvicorn_factory]
| ERROR 
tests/asgi/test_asgi_servers.py::TestWebSocket::test_close_code_on_unhandled_error[_uvicorn_factory]
| ERROR 
tests/asgi/test_asgi_servers.py::TestWebSocket::test_close_code_on_unhandled_http_error[_uvicorn_factory]
| ERROR 
tests/asgi/test_asgi_servers.py::TestWebSocket::test_type_mismatch[_uvicorn_factory-text-send]
| ERROR 
tests/asgi/test_asgi_servers.py::TestWebSocket::test_type_mismatch[_uvicorn_factory-text-recv]
| ERROR 
tests/asgi/test_asgi_servers.py::TestWebSocket::test_type_mismatch[_uvicorn_factory-data-send]
| ERROR 
tests/asgi/test_asgi_servers.py::TestWebSocket::test_type_mismatch[_uvicorn_factory-data-recv]
| ERROR 
tests/asgi/test_asgi_servers.py::TestWebSocket::test_passing_path_params[_uvicorn_factory]
| = 3084 passed, 313 skipped, 170 warnings, 35 errors in 36.58s 
==

A full build log on riscv64 is available here:
https://buildd.debian.org/status/fetch.php?pkg=python-falcon=riscv64=3.1.1-2%2Bb2=1713048383=0

Full build logs on amd64 and arm64 are also available on reproducible
builds:
https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/python-falcon_3.1.1-2.rbuild.log.gz
https://tests.reproducible-builds.org/debian/rbuild/unstable/arm64/python-falcon_3.1.1-2.rbuild.log.gz

Regards
Aurelien

Bug#1066216: hfsutils: diff for NMU version 3.2.6-15.1

[Sebastian Ramacher]

Control: tags 1066216 + patch
Control: tags 1066216 + pending


Dear maintainer,

I've prepared an NMU for hfsutils (versioned as 3.2.6-15.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Cheers

-- 
Sebastian Ramacher
diff -Nru hfsutils-3.2.6/debian/changelog hfsutils-3.2.6/debian/changelog
--- hfsutils-3.2.6/debian/changelog	2021-01-23 15:23:26.0 +0100
+++ hfsutils-3.2.6/debian/changelog	2024-04-14 12:39:50.0 +0200
@@ -1,3 +1,10 @@
+hfsutils (3.2.6-15.1) unstable; urgency=medium
+
+  [ Benjamin Drung ]
+  * Explicitly import string.h (Closes: #1066216, LP: #2060708)
+
+ -- Sebastian Ramacher   Sun, 14 Apr 2024 12:39:50 +0200
+
 hfsutils (3.2.6-15) unstable; urgency=medium
 
   * Set myself as maintainer in debian/control (Closes: #60)
diff -Nru hfsutils-3.2.6/debian/patches/Explicitly-include-string.h.patch hfsutils-3.2.6/debian/patches/Explicitly-include-string.h.patch
--- hfsutils-3.2.6/debian/patches/Explicitly-include-string.h.patch	1970-01-01 01:00:00.0 +0100
+++ hfsutils-3.2.6/debian/patches/Explicitly-include-string.h.patch	2024-04-14 12:38:09.0 +0200
@@ -0,0 +1,37 @@
+From: Benjamin Drung 
+Date: Tue, 9 Apr 2024 18:21:33 +0200
+Subject: Explicitly include string.h
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+
+> gcc -Wall -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Ilibhfs -I/usr/include/tcl -I/usr/include/tk -DHAVE_CONFIG_H -DUSE_INTERP_RESULT -c -o hpwd.o hpwd.c
+> hpwd.c: In function ‘hpwd_main’:
+> hpwd.c:55:7: error: implicit declaration of function ‘strcmp’ [-Werror=implicit-function-declaration]
+> 55 | if (strcmp(ent->cwd, ":") == 0)
+> | ^~
+> hpwd.c:32:1: note: include ‘’ or provide a declaration of ‘strcmp’
+> 31 | # include "hpwd.h"
+> +++ |+#include 
+> 32 |
+> cc1: some warnings being treated as errors
+> make[1]: *** [: hpwd.o] Error 1
+
+Closes: #1066216
+LP: #2060708
+---
+ hpwd.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/hpwd.c b/hpwd.c
+index cd3b100..84c34cf 100644
+--- a/hpwd.c
 b/hpwd.c
+@@ -24,6 +24,7 @@
+ # endif
+ 
+ # include 
++# include 
+ 
+ # include "hfs.h"
+ # include "hcwd.h"
diff -Nru hfsutils-3.2.6/debian/patches/series hfsutils-3.2.6/debian/patches/series
--- hfsutils-3.2.6/debian/patches/series	2021-01-23 15:23:26.0 +0100
+++ hfsutils-3.2.6/debian/patches/series	2024-04-14 12:38:09.0 +0200
@@ -2,3 +2,4 @@
 0002-Fix-FTBFS-with-gcc-3.4.patch
 0003-Add-support-for-files-larger-than-2GB.patch
 0004-Add-DUSE_INTERP_RESULT-to-DEFINES-in-Makefile.in.patch
+Explicitly-include-string.h.patch

Bug#1068962: ITP: python-re-assert -- show where your regex match assertion failed

[Dale Richards]

Package: wnpp
Severity: wishlist
Owner: Dale Richards 
X-Debbugs-Cc: debian-de...@lists.debian.org, d...@dalerichards.net

* Package name: python-re-assert
  Version : 1.1.0
  Upstream Contact: Anthony Sottile 
* URL : https://github.com/asottile/re-assert
* License : MIT
  Programming Lang: Python
  Description : show where your regex match assertion failed

A Python 3 library that provides a helper class to
simplify making assertions of regexes, by showing where
a match fails.

This library is a prerequisite of the upstream tests included with
python-aiohttp, which I intend to update.

I intend to maintain this package within the Debian Python Team.

Bug#1068961: llvm-toolchain-18: block migration to testing: to many llvm-toolchain versions in testing

[Sebastian Ramacher]

Source: llvm-toolchain-18
Version: 1:18.1.3-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org, debian-rele...@lists.debian.org

Currently we we have llvm-toolchain-{14,15,16,17} in testing whereas RC
bugs in the verious versions of llvm-toolchain do not get addressed:

#1067005 in llvm-toolchain-18
#1068185 and #1057586 in llvm-toolchain-16
#1036596 and #1068840 in llvm-toolchain-14

Seeing that some of the bugs are unaddressed for a long time, that many
versions of llvm-toolchain in the archive seem to be to much to handle
for the maintainers. As there is also no progress in removing old
versions from the archive, I propose to not let any new versions of
llvm-toolchain-X migrate to trixie until the number of versions is
reduced to a maintainable number.

Please do not downgrade or close this bug report before contacting the
release team.

Cheers
-- 
Sebastian Ramacher

Bug#1068959: py-ubjson: FTBFS: testsuite failure: FAILED (failures=2)

[Aurelien Jarno]

Source: py-ubjson
Version: 0.16.1-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear maintainer,

py-ubjson fails to build from source due to errors in the testsuite.
>From my build log on amd64:

| ==
| FAIL: test_recursion (test.TestEncodeDecodeFpExt.test_recursion)
| --
| Traceback (most recent call last):
|   File "/<>/.pybuild/cpython3_3.12_ubjson/build/test/test.py", 
line 476, in test_recursion
| with self.assert_raises_regex(RuntimeError, 'recursion'):
| AssertionError: RuntimeError not raised
| 
| ==
| FAIL: test_recursion (test.TestEncodeDecodePlainExt.test_recursion)
| --
| Traceback (most recent call last):
|   File "/<>/.pybuild/cpython3_3.12_ubjson/build/test/test.py", 
line 476, in test_recursion
| with self.assert_raises_regex(RuntimeError, 'recursion'):
| AssertionError: RuntimeError not raised
| 
| --
| Ran 116 tests in 2.212s
| 
| FAILED (failures=2)
| E: pybuild pybuild:389: test: plugin distutils failed with: exit code=1: cd 
/<>/.pybuild/cpython3_3.12_ubjson/build; python3.12 -m unittest 
discover -v test/

A full build log on riscv64 is available here:
https://buildd.debian.org/status/fetch.php?pkg=py-ubjson=riscv64=0.16.1-3%2Bb1=1713019530=0

Full build logs on amd64 and arm64 are also available on reproducible 
builds:
https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/py-ubjson_0.16.1-3.rbuild.log.gz
https://tests.reproducible-builds.org/debian/rbuild/unstable/arm64/py-ubjson_0.16.1-3.rbuild.log.gz

Regards
Aurelien