Bug#943315: ITP: vst3sdk -- professional audio plugin development kit

[Andrius Merkys]

Hi IOhannes,

On Wed, 23 Oct 2019 10:31:40 +0200 IOhannes m zmoelnig 
 wrote:

Package: wnpp
Severity: wishlist
Owner: IOhannes m zmoelnig 

* Package name: vst3sdk
  Version : 3.6.13
  Upstream Author : Steinberg Media Technologies GmbH
* URL : https://github.com/steinbergmedia/vst3sdk
* License : GPL3
  Programming Lang: C
  Description : professional audio plugin development kit

 Virtual Studio Technology (VST) is an audio plugin software interface
 that integrates software synthesizer and effects in digital audio
 workstations.
 VST and similar technologies use digital signal processing to simulate
 traditional recording studio hardware in software.
 .
 VST is the de-facto industry standard for audio plugins and plugin hosts.

I intend to package this under the umbrella of the multimedia-team.


What is the status of this ITP? Did you have any luck in packaging 
vst3sdk? I noticed a packaging repository on salsa, but it seems empty.


Best,
Andrius

Bug#1054401: bookworm-pu: package nagios-plugins-contrib/42.20230308+deb12u1

[Jan Wagner]

Hi,

Am 05.11.23 um 15:41 schrieb Jan Wagner:

Am 23.10.23 um 19:43 schrieb Holger Levsen:

On Mon, Oct 23, 2023 at 01:19:25PM +0200, Jan Wagner wrote:

[ Reason ]
As reported in #1033791, check_running_kernel fails to find version on
bookworm/(arm64|armhf).

[ Impact ]
check_running_kernel doesn't work on arm64 and armhf as expected, 
this is a

regression.

[ Tests ]
The patch was verified to work in #1033791
I've rebuild the package on arm64 and can confirm 
/usr/lib/nagios/plugins/check_running_kernel
now works on those arm64 systems where the version currently in 
bookworm does

not work.


is there anything I can do to get the package into bookworm?


I would enjoy to hear from the RM about this.

Thanks, Jan

Bug#947323: libcap-ng: Please install libs back into /usr/lib/ when usrmerge arrives

[Håvard F . Aasen]

Hi Helmut,

On 14.11.2023 19:36, Helmut Grohne wrote:
> user helm...@debian.org
> usertags -1 + dep17m2
> thanks
> 
> On Tue, Nov 14, 2023 at 12:52:39PM +0100, Helmut Grohne wrote:
>> Hence, we are good to go. I do not expect libcap-ng to be uploaded to
>> bookworm-backports and therefore changed the paths directly in the
>> attached patch. This patch should not be uploaded to bookworm-backports.
>> If that's relevant to you, consider using dh_movetousr instead. Also
>> keep in mind that restructuring changes (such as libcap-ng0t64) should
>> be uploaded to experimental first to let dumat analyze your change for
>> possible problems.
> 
> I'm sorry. Further testing has revealed that I failed to remove the /lib
> directory from the package. We really need to get rid of it, because
> dpkg is not equipped to deal with symlink vs directory conflicts. Here
> is an updated patch.
> 

Thanks for the patch, though I already have a commit with the same
changes laying around [1], I have been unsure when to apply it. I guess
the time is nearing.

As for the backporting, I at least have no intention of backporting this
package.

Upstream has talked about a new release 'soon', I intend to include this
change at the same time. Regardless of the new release, it will be
uploaded by the end of this year at the latest.


Håvard

[1] 
https://salsa.debian.org/debian/libcap-ng/-/commit/9c6991a7f198c486c38e4a5ddf2e0142d4f64564

Bug#1055974: django-yarnpkg: Compatibility Issue with Upcoming node-yarnpkg Changes

[Michael Ikwuegbu]

Package: django-yarnpkg
Version: 6.1.0-1
Severity: important
X-Debbugs-Cc: ikwuegbu...@gmail.com, debian...@lists.debian.org

Dear Maintainer,

   I am writing to inform you of some changes in node-yarnpkg that might
   affect your package.
   
   Recently, node-yarnpkg announced a major update [1] that would introduce
   some breaking changes in its behavior. One important change is that
   node-yarnpkg would no longer use the node_modules directory to store
   the installed dependencies but would now use a new format called 
   Plug'n'Play (PnP). This means that the dependencies would be stored
   in a single file called .pnp.js, and the Node.js modules resolution
   algorithm would be modified to use this file instead of the node_modules
   directory. 
   
   To help you prepare for the changes, we have prepared some notes that
   you can find in the README.Debian and NEWS files of the
   node-yarnpkg package [2]. You can also refer to the offical yarn
   documentation for more details. 
   
   We hope that this notice would help you avoid potential issues and
   ensure compatibility of your package.


  1. https://lists.debian.org/debian-js/2023/10/msg00079.html 
  2. https://salsa.debian.org/js-team/node-yarnpkg

Bug#1055824: python3-rich: violates Python package metadata with dependency package 'python3-markdown-it' 3.0.0-2

[Ben Finney]

Control: tags -1 + upstream patch

On 12-Nov-2023, Ben Finney wrote:
> Either:
> 
> * The upstream version constraint needs to be relaxed by the upstream
>   project, to allow ‘python3-rich’ version “3.0.0-2” to satisfy the
>   dependency.

This is the resolution indicated by the upstream code base. In versions
starting at “13.4.2”, the upstream project declares dependencies that allow
‘markdown-it-py’ version “3.0.0” also.

https://github.com/Textualize/rich/commit/f232e9d95bbe4747f12459d5935cfa2a42c08069>

This can be applied with a simple patch:

=
diff --git old/pyproject.toml new/pyproject.toml
--- old/pyproject.toml
+++ new/pyproject.toml
@@ -30,7 +30,7 @@
 typing-extensions = { version = ">=4.0.0, <5.0", python = "<3.9" }
 pygments = "^2.14.0"
 ipywidgets = { version = ">=7.5.1,<9", optional = true }
-markdown-it-py = "^2.1.0"
+markdown-it-py = ">=2.1.0"
 
 [tool.poetry.extras]
 jupyter = ["ipywidgets"]
=

or by upgrading Debian's ‘rich’ package source, to upstream's version
“13.4.2” or later.

-- 
 \   “You can never entirely stop being what you once were. That's |
  `\   why it's important to be the right person today, and not put it |
_o__) off until tomorrow.” —Larry Wall |
Ben Finney 


signature.asc
Description: PGP signature

Bug#1055973: UDD link update

[Anton Gladky]

https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-boost183-transition=gl...@debian.org=1=1=1=1#results

Bug#1055972: UDD link update

[Anton Gladky]

https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-boost183-transition=gl...@debian.org=1=1=1=1#results

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

[Vincent Lefevre]

Package: atril
Version: 1.26.0-2+b1
Severity: normal

Consider a gzipped postscript file with 2 different names:

  file.ps.gz
  file.ps-1.gz

While file.ps.gz can be read correctly by atril, for file.ps-1.gz,
atril gives the following error:

  Unable to open document
  File type Gzip archive (application/gzip) is not supported

Using filename extensions is a bad idea, as filenames may not have
the expected extensions for files downloaded from the web. In
particular, when downloading a file file.ps.gz, Firefox uses this
filename if the file doesn't exist yet, but if it already exists,
Firefox renames it to "file.ps-1.gz" (increasing the number for
each additional download).

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

Kernel: Linux 6.5.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.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 atril depends on:
ii  atril-common 1.26.0-2
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  libatk1.0-0  2.50.0-1
ii  libatrildocument31.26.0-2+b1
ii  libatrilview31.26.0-2+b1
ii  libc62.37-12
ii  libcaja-extension1   1.26.1-1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3
ii  libglib2.0-0 2.78.1-4
ii  libgtk-3-0   3.24.38-6
ii  libice6  2:1.0.10-1
ii  libsecret-1-00.21.1-1
ii  libsm6   2:1.2.3-1
ii  libxml2  2.9.14+dfsg-1.3
ii  shared-mime-info 2.2-1

Versions of packages atril recommends:
hi  dbus-user-session [default-dbus-session-bus]  1.14.10-1
hi  dbus-x11 [dbus-session-bus]   1.14.10-1
ii  gvfs  1.52.1-1

Versions of packages atril suggests:
pn  caja  
ii  poppler-data  0.4.12-1
pn  unrar 

-- no debconf information

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

Bug#1055970: ark: Ark is not working with upstream 7-zip

[tsubame]

Package: ark
Version: 4:23.08.1-2
Severity: normal

Ark refuse to open any 7z archive in my PC by showing "The archive 
is empty or Ark could not open its content."
Running in terminal only shows "ark.part: No entry listed by the
plugin", and I am not sure if it is related.
Further inspection on upstream source shows the upstream 7z support 
should have been implemented and in Debian, so I decided to issue a bug
report.


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

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

Versions of packages ark depends on:
ii  kinit  5.107.0-1
ii  kio5.107.0-1
ii  libarchive13   3.7.2-1
ii  libc6  2.37-12
ii  libgcc-s1  13.2.0-6
ii  libkf5completion5  5.107.0-1
ii  libkf5configcore5  5.107.0-1
ii  libkf5configgui5   5.107.0-1
ii  libkf5configwidgets5   5.107.0-2
ii  libkf5coreaddons5  5.107.0-1
ii  libkf5crash5   5.107.0-1
ii  libkf5dbusaddons5  5.107.0-1
ii  libkf5i18n55.107.0-1+b1
ii  libkf5jobwidgets5  5.107.0-1
ii  libkf5kiocore5 5.107.0-1
ii  libkf5kiofilewidgets5  5.107.0-1
ii  libkf5kiogui5  5.107.0-1
ii  libkf5kiowidgets5  5.107.0-1
ii  libkf5parts5   5.107.0-1
ii  libkf5pty5 5.107.0-1
ii  libkf5service-bin  5.107.0-1
ii  libkf5service5 5.107.0-1
ii  libkf5widgetsaddons5   5.107.0-1
ii  libkf5windowsystem55.107.0-1
ii  libkf5xmlgui5  5.107.0-1+b1
ii  libqt5core5a   5.15.10+dfsg-5
ii  libqt5dbus55.15.10+dfsg-5
ii  libqt5gui5 5.15.10+dfsg-5
ii  libqt5widgets5 5.15.10+dfsg-5
ii  libstdc++6 13.2.0-6
ii  libzip41.7.3-1+b1
ii  zlib1g 1:1.2.13.dfsg-3

Versions of packages ark recommends:
ii  7zip [p7zip-full]  23.01+dfsg-7
ii  bzip2  1.0.8-5+b1
ii  unar   1.10.7+ds1+really1.10.1-2+b3
ii  unzip  6.0-28
ii  zip3.0-13

Versions of packages ark suggests:
pn  rar
ii  unrar  1:7.0.3-1

-- no debconf information

Bug#1053995: Info received (ITP: fastfetch -- like neofetch, but much faster because written in C)

[Li Carter]

Friendly ping

> 2023年10月16日 14:39，Debian Bug Tracking System  写道：
> 
> Thank you for the additional information you have supplied regarding
> this Bug report.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
> 
> Your message has been sent to the package maintainer(s):
> w...@debian.org
> 
> If you wish to submit further information on this problem, please
> send it to 1053...@bugs.debian.org.
> 
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
> 
> -- 
> 1053995: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053995
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

Bug#1050383: setup-storage confused by valid md device names

[Thomas Lange]

Hi,

I guess the \d{3,} regex comes from the fact, that during an initial
FAI installation (booting the FAI environment) the md devices are
always higher that 127 IIRC. If you use setup-storage on a normal
Debian system, this is not true any more.

I will think about changing that.
-- 
regards Thomas

Bug#1055969: kuttypy: reproducible-builds: shell-dependent use of echo

[Vagrant Cascadian]

Source: kuttypy
Version: 2.1.1-2
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: shell
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Newlines are handled differently depending on which shell implementation
is in use, resulting in differences dependent on the build environment:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/kuttypy.html

  /usr/share/kuttypy/utilities/build_details.py

  QT_VERSION·=·'PyQt5'\nPY_VERSION·=·3\n
  vs.
  QT_VERSION·=·'PyQt5'   
  PY_VERSION·=·3

The attached patch fixes this in the upstream Makefile by making
multiple echo calls rather than relying on the shell-dependent echo
handling of "\n".

With this patch applied to kutty 2.1.1-4, based on my local tests,
kuttypy should build reproducibly on tests.reproducible-builds.org!


Thanks for maintaining kuttypy!


live well,
  vagrant
From 25b7eeb2072424c31b21ceea5ae95d583faa5bcd Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 14 Nov 2023 15:34:37 -0800
Subject: [PATCH] Makefile: Split echo call into multiple lines to avoid
 shell-dependent handling of "\n".

https://tests.reproducible-builds.org/debian/issues/unstable/bin_sh_is_bash_issue.html
---
 Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 68839f1..4927281 100644
--- a/Makefile
+++ b/Makefile
@@ -27,7 +27,8 @@ all: recursive_all
 
 recursive_all:
 	@echo '?. Using QT Version:' $(QT_VERSION)  $(PYUIC) $(PYRCC)  $(PYLUPDATE) $(PY_VERSION)
-	@echo "QT_VERSION = '$(QT_VERSION)'\nPY_VERSION = $(PY_VERSION)\n" > utilities/build_details.py
+	@echo "QT_VERSION = '$(QT_VERSION)'" > utilities/build_details.py
+	@echo "PY_VERSION = $(PY_VERSION)" >> utilities/build_details.py
 	for d in $(SUBDIRS); do $(MAKE) PYUIC=$(PYUIC) PYRCC=$(PYRCC) PYLUPDATE=$(PYLUPDATE) PY_VERSION=$(PY_VERSION) -C $$d all; done
 
 clean: recursive_clean
-- 
2.39.2



signature.asc
Description: PGP signature

Bug#1055968: libefivar-dev: GNUisms in header yield warnings if using pkgconf file (-I vs -isystem probably)

[наб]

Package: libefivar-dev
Version: 37-6
Severity: normal

Dear Maintainer,

With -pedantic,
-- >8 --
In file included from src/config.cpp:16:
/usr/include/efivar/efivar.h:223:65: warning: named variadic macros are a GNU 
extension [-Wvariadic-macros]
  223 | #define efi_error_real__(errval, file, function, line, fmt, args...) \
  | ^
/usr/include/efivar/efivar.h:226:28: warning: named variadic macros are a GNU 
extension [-Wvariadic-macros]
  226 | #define efi_error(fmt, args...) \
  |^
/usr/include/efivar/efivar.h:228:40: warning: named variadic macros are a GNU 
extension [-Wvariadic-macros]
  228 | #define efi_error_val(errval, msg, args...) \
  |^
/usr/include/efivar/efivar.h:227:61: warning: token pasting of ',' and 
__VA_ARGS__ is a GNU extension [-Wgnu-zero-variadic-macro-arguments]
  227 | efi_error_real__(errno, __FILE__, __func__, __LINE__, (fmt), ## 
args)
  |^
/usr/include/efivar/efivar.h:224:51: warning: token pasting of ',' and 
__VA_ARGS__ is a GNU extension [-Wgnu-zero-variadic-macro-arguments]
  224 | efi_error_set(file, function, line, errval, (fmt), ## args)
  |  ^
/usr/include/efivar/efivar.h:227:61: warning: token pasting of ',' and 
__VA_ARGS__ is a GNU extension [-Wgnu-zero-variadic-macro-arguments]
  227 | efi_error_real__(errno, __FILE__, __func__, __LINE__, (fmt), ## 
args)
  |^
/usr/include/efivar/efivar.h:224:51: warning: token pasting of ',' and 
__VA_ARGS__ is a GNU extension [-Wgnu-zero-variadic-macro-arguments]
  224 | efi_error_set(file, function, line, errval, (fmt), ## args)
  |  ^
-- >8 --
 

The second warning is clang-only for some reason.

These warnings only appear if using
  $ pkgconf --cflags efivar
  -I/usr/include/efivar
and including with #include .

They are not present when doing #include .

Replacing -I with -isystem in efivar.pc fixes the issue.

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

Kernel: Linux 6.1.0-9-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 libefivar-dev depends on:
ii  libefivar1  37-6

libefivar-dev recommends no packages.

libefivar-dev suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1026950: should be fixed

[Bobby de Vos]

Greetings,

The watch file has been fixed, and the latest version, now 3.200, has 
been uploaded.


Are you using Debian or Ubuntu? If Ubuntu, the latest version will 
eventually appear at https://packages.sil.org/ thus allowing an update 
before upgrading to a new release of the OS.


Bobby

--
Bobby de Vos
/bobby_de...@sil.org/

Bug#1052002: firefox: FTBFS: ERROR: Cannot find wasi headers or problem with the wasm compiler. Please fix the problem. Or build with --without-wasm-sandboxed-libraries

[Sylvestre Ledru]

Le 03/11/2023 à 21:32, Faidon Liambotis a écrit :

Control: reopen -1
Control: found -1 1:16.0.6-17

Note how /usr/include/wasm32-wasi/c++/v1 is missing.
Test case:
   $ apt install clang lld libclang-rt-dev-wasm32 libc++-dev-wasm32
   $ cat > hello.cpp <
   
   int main() {

 std::cout << "hello world" << std::endl;
 return 0;
   }
   EOF
   $ /usr/bin/clang++ -v --target=wasm32-wasi hello.cpp

Only C++ include paths are affected, not C. This almost certainly has to
do with the patch we carry for wasm include paths, that I have
contributed to. Unfortunately I have no time to look into it right now
:( I may find some time in a couple of weeks, but hoping someone else
can take care of it in the meantime :/


I understand better why I didn't get this problem locally:

If you install libc++-dev too, the problem goes away.

because it provides the symlink

/usr/include/c++/v1 -> ../../lib/llvm-16/include/c++/v1

which makes clang happy

but still looking into a different solution

cheers

S

Bug#966218: firmware: failed to load iwl-debug-yoyo.bin (-2)

[Edward Durie]

This issue is present for me too. 

6.1.0-13-amd64 firmware-iwlwifi/stable,now 20230210-5 all

Nov 15 09:26:52 --- kernel: iwlwifi :00:14.3: enabling device (
-> 0002) Nov 15 09:26:52 --- kernel: iwlwifi :00:14.3: firmware:
direct-loading firmware iwlwifi-so-a0-hr-b0-72.ucode Nov 15 09:26:52 ---
kernel: iwlwifi :00:14.3: api flags index 2 larger than supported by
driver Nov 15 09:26:52 --- kernel: iwlwifi :00:14.3:
TLV_FW_FSEQ_VERSION: FSEQ Version: 0.0.2.36 Nov 15 09:26:52 --- kernel:
iwlwifi :00:14.3: firmware: failed to load iwl-debug-yoyo.bin (-2)
Nov 15 09:26:52 --- kernel: firmware_class: See
https://wiki.debian.org/Firmware for information about missing firmware
Nov 15 09:26:52 --- kernel: iwlwifi :00:14.3: firmware: failed to
load iwl-debug-yoyo.bin (-2) Nov 15 09:26:52 --- kernel: iwlwifi
:00:14.3: loaded firmware version 72.daa05125.0 so-a0-hr-b0-72.ucode
op_mode iwlmvm
best,
Edward

Bug#1055967: python-qmix: Incorrect PYBUILD_NAME

[Yogeswaran Umasankar]

Source: python-qmix
Version: 1.0.6-2
Severity: normal
X-Debbugs-Cc: kd8...@gmail.com

Incorrect PYBUILD_NAME, and test files included in the binary package.

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

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

Bug#1055966: bookworm-pu: package openvpn-dco-dkms/0.0+git20230324-1+deb12u1 (or 0.0+git20231103-0+deb12u1?)

[Bernhard Schmidt]

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

[ Reason ]
openvpn-dco-dkms packages an accelerator kernel module for OpenVPN (OpenVPN
data channel offload). There is one annoying bug tracked as Bug#1055809 where on
heavily loaded TCP servers a refcount issue might occur and the module will
become unusable.

The bug has been fixed upstream. The new upstream snapshot is already in sid.

Apart from that change there is a fix for compilation with Kernel >= 6.5 that
we might want to have in stable for backport kernels. Tracked as Bug#1043116.
That patch could be backported, but needs some fixup.

Apart from that there are only changes for building with RHEL9, which is a noop
on Debian.

https://github.com/OpenVPN/ovpn-dco/compare/1c2c84e99d0c1513db38ac7a3858f21229906fd7..master

Backporting the build fix would actually make the diff larger than the new
upstream version and harder to maintain, so I'm proposing two options:

a) backport only the fix for Bug#1055809 and upload as
openvpn-dco-dkms/0.0+git20230324-1+deb12u1

 changelog|9 
 gbp.conf |2 +
 patches/fix-refcount-imbalance.patch |   38 +++
 patches/series   |1 
 4 files changed, 50 insertions(+)

b) upload the new upstream snapshot as 0.0+git20231103-0+deb12u1, fixing the
build error on kernel 6.5

 Makefile|   13 ++---
 compat-include/net/gso.h|   20 
 debian/changelog|   21 +
 debian/rules|2 +-
 drivers/net/ovpn-dco/ovpn.c |1 +
 drivers/net/ovpn-dco/tcp.c  |   14 +++---
 linux-compat.h  |4 ++--
 7 files changed, 66 insertions(+), 9 deletions(-)

[ Impact ]
If neither update is allowed the kernel module will hang on busy servers

If we only fix the refcount imbalance the module will not build on future
backports kernels. Backporting that fix as well would be possible, but actually
the diff would be larger and we cannot be sure whether new fixes would apply
cleanly.

[ Tests ]
The code fix is trivial enough and has been verified upstream. The new module
is currently running on my employers eduVPN server.

[ Risks ]
The changes are pretty trivial and the vast majority of them is a noop on
Bookworm or Debian as a whole

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

[ Changes ]
See the explaination above for the minimal version and the github diff link for
the new upstream version
diffstat for openvpn-dco-dkms-0.0+git20230324 openvpn-dco-dkms-0.0+git20230324

 changelog|9 
 gbp.conf |2 +
 patches/fix-refcount-imbalance.patch |   38 +++
 patches/series   |1 
 4 files changed, 50 insertions(+)

diff -Nru openvpn-dco-dkms-0.0+git20230324/debian/changelog 
openvpn-dco-dkms-0.0+git20230324/debian/changelog
--- openvpn-dco-dkms-0.0+git20230324/debian/changelog   2023-04-13 
09:47:41.0 +0200
+++ openvpn-dco-dkms-0.0+git20230324/debian/changelog   2023-11-14 
22:18:17.0 +0100
@@ -1,3 +1,12 @@
+openvpn-dco-dkms (0.0+git20230324-1+deb12u1) bookworm; urgency=medium
+
+  * Import upstream patch to fix refcount imbalance (Closes: 1055809)
+- fixes "waiting for tunxxx to become free" seen on heavy loaded TCP
+  servers
+  * Add d/gbp.conf for debian/bookworm branch
+
+ -- Bernhard Schmidt   Tue, 14 Nov 2023 22:18:17 +0100
+
 openvpn-dco-dkms (0.0+git20230324-1) unstable; urgency=medium
 
   * Release to unstable targetting bookworm.
diff -Nru openvpn-dco-dkms-0.0+git20230324/debian/gbp.conf 
openvpn-dco-dkms-0.0+git20230324/debian/gbp.conf
--- openvpn-dco-dkms-0.0+git20230324/debian/gbp.conf1970-01-01 
01:00:00.0 +0100
+++ openvpn-dco-dkms-0.0+git20230324/debian/gbp.conf2023-11-14 
22:18:17.0 +0100
@@ -0,0 +1,2 @@
+[DEFAULT]
+debian-branch=debian/bookworm
diff -Nru 
openvpn-dco-dkms-0.0+git20230324/debian/patches/fix-refcount-imbalance.patch 
openvpn-dco-dkms-0.0+git20230324/debian/patches/fix-refcount-imbalance.patch
--- 
openvpn-dco-dkms-0.0+git20230324/debian/patches/fix-refcount-imbalance.patch
1970-01-01 01:00:00.0 +0100
+++ 
openvpn-dco-dkms-0.0+git20230324/debian/patches/fix-refcount-imbalance.patch
2023-11-14 22:18:17.0 +0100
@@ -0,0 +1,38 @@
+From 7b7a28fcb0c244c7182922f7c83cb09bcd840c84 Mon Sep 17 00:00:00 2001
+From: Antonio Quartulli 
+Date: Wed, 1 Nov 2023 23:49:39 +0100
+Subject: [PATCH] ovpn-dco: fix refcount imbalance upon RX in case 

Bug#1055965: bookworm-pu: package network-manager-openconnect/1.2.8-3+deb12u1

[Salvatore Bonaccorso]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: network-manager-openconn...@packages.debian.org, Florian Echtler 
, Luca Boccassi , car...@debian.org
Control: affects -1 + src:network-manager-openconnect

Hi Stable release managers,

[ Reason ]
In recent cases where institutions updated their Cisco AnyConnect
server, connecting with openconnect requires to pass an appropriate
UserAgent. Cf. for instance
https://gitlab.com/openconnect/openconnect/-/issues/544 .
network-manager-openconnect plugin for NetworkManager had no
possibilty to configure this. As result after such updates users using
the NetworkManager plugin cannot connect to the VPN servers.

[ Impact ]
Impossibility to use the NetworkManager plugin for openconnect in
situations where the Cisco AnyConnect server has been updated.

[ Tests ]
I manually tested the plugin in one affected configuration. After the
update the GUI field for configuring the UserAgent can be configured
for the specific configuration.

[ Risks ]
Patches have been taken from upstream and apply with minor context
tewak to the older version. Luca has reviewed and acked the MR in 
https://salsa.debian.org/debian/network-manager-openconnect/-/merge_requests/6

[ Checklist ]
  [x] *all* changes are documented in the d/changelog

(the salsa pipleline one is not, but has not a user impact)

  [x] I reviewed all changes and I approve them
  [x ] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
Adds support for the mentioned UserAgent field and setting.

[ Other info ]
Nothing.

Regards,
Salvatore
diff -Nru network-manager-openconnect-1.2.8/debian/changelog 
network-manager-openconnect-1.2.8/debian/changelog
--- network-manager-openconnect-1.2.8/debian/changelog  2022-05-21 
15:35:15.0 +0200
+++ network-manager-openconnect-1.2.8/debian/changelog  2023-11-14 
15:15:44.0 +0100
@@ -1,3 +1,14 @@
+network-manager-openconnect (1.2.8-3+deb12u1) bookworm; urgency=medium
+
+  [ Salvatore Bonaccorso ]
+  * Add User Agent to Openconnect VPN for NetworkManager (Closes:
+#1053467)
+  * Use openconnect_set_useragent() where available
+  * Add support for GTK4 in user-agent calls
+  * Add Build-Depends on libgtk-4-bin for gtk4-builder-tool
+
+ -- Luca Boccassi   Tue, 14 Nov 2023 14:15:44 +
+
 network-manager-openconnect (1.2.8-3) unstable; urgency=medium
 
   * Bump Standards-Version to 4.6.1, no changes
diff -Nru network-manager-openconnect-1.2.8/debian/control 
network-manager-openconnect-1.2.8/debian/control
--- network-manager-openconnect-1.2.8/debian/control2022-05-21 
15:35:15.0 +0200
+++ network-manager-openconnect-1.2.8/debian/control2023-11-14 
15:15:44.0 +0100
@@ -8,6 +8,7 @@
libgcr-3-dev,
libglib2.0-dev,
libgtk-3-dev,
+   libgtk-4-bin,
libgtk-4-dev,
libnm-dev,
libnma-dev,
diff -Nru network-manager-openconnect-1.2.8/debian/gbp.conf 
network-manager-openconnect-1.2.8/debian/gbp.conf
--- network-manager-openconnect-1.2.8/debian/gbp.conf   2022-03-14 
00:08:09.0 +0100
+++ network-manager-openconnect-1.2.8/debian/gbp.conf   2023-11-14 
15:15:44.0 +0100
@@ -1,5 +1,6 @@
 [DEFAULT]
 pristine-tar = True
+debian-branch = debian/bookworm
 
 [import-orig]
 upstream-vcs-tag = %(version)s
diff -Nru 
network-manager-openconnect-1.2.8/debian/patches/0002-Add-User-Agent-to-Openconnect-VPN-for-NetworkManager.patch
 
network-manager-openconnect-1.2.8/debian/patches/0002-Add-User-Agent-to-Openconnect-VPN-for-NetworkManager.patch
--- 
network-manager-openconnect-1.2.8/debian/patches/0002-Add-User-Agent-to-Openconnect-VPN-for-NetworkManager.patch
1970-01-01 01:00:00.0 +0100
+++ 
network-manager-openconnect-1.2.8/debian/patches/0002-Add-User-Agent-to-Openconnect-VPN-for-NetworkManager.patch
2023-11-14 15:15:44.0 +0100
@@ -0,0 +1,302 @@
+From: Debasish Patra 
+Date: Sat, 29 Aug 2020 17:58:16 -0400
+Subject: Add User Agent to Openconnect VPN for NetworkManager
+Origin: 
https://gitlab.gnome.org/GNOME/NetworkManager-openconnect/-/commit/b5e154c06fd9013a925f85c2aa38d88e4ee53db0
+Bug-Debian: https://bugs.debian.org/1053467
+
+---
+ auth-dialog/main.c|  3 +-
+ properties/nm-openconnect-dialog.ui   | 73 +--
+ properties/nm-openconnect-editor-plugin.c |  5 ++
+ properties/nm-openconnect-editor.c| 15 +
+ shared/nm-service-defines.h   |  1 +
+ 5 files changed, 79 insertions(+), 18 deletions(-)
+
+diff --git a/auth-dialog/main.c b/auth-dialog/main.c
+index 99cab7cd921f..305b568650ba 100644
+--- a/auth-dialog/main.c
 b/auth-dialog/main.c
+@@ -1853,6 +1853,7 @@ static void build_main_dialog(auth_ui_data *ui_data)
+ 
+ static auth_ui_data *init_ui_data (char *vpn_name, GHashTable *options, 
GHashTable *secrets, 

Bug#1052993: (no subject)

[Mario Limonciello]

Sorry; I missed this bug in the last upload.

I've submitted your changes to the VCS for review and they should be 
part of the next version.


https://github.com/fwupd/fwupd/pull/6378

Bug#1028432: debcargo patch to build with clap 4.

[James McCoy]

On Tue, Jan 10, 2023 at 10:32:04PM +, Peter Michael Green wrote:
> Package: rust-debcargo
> 
> I've attached a patch which makes debcargo build with clap 4, debcargo
> builds and it's cargo tests run succesfully, but I haven't actually done any
> testing of the command line interface with this patch.

debcargo was updated to clap 4 via
https://salsa.debian.org/rust-team/debcargo/-/merge_requests/54.  This
is part of the 2.6.1 release.

Debian package still needs to be updated, though.

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

Bug#1055964: transition: proftpd-dfsg

[Hilmar Preusse]

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

This transition was already started by the recent proftpd upload, but is not
caught automatically since it is a virtual package name that has changed.

Ben file:

title = "proftpd-dfsg";
is_affected = .depends ~ "proftpd-abi-1.3.8+dfsg" | .depends ~ "proftpd-
abi-1.3.8a+dfsg";
is_good = .depends ~ "proftpd-abi-1.3.8a+dfsg";
is_bad = .depends ~ "proftpd-abi-1.3.8+dfsg";

Bug#959046: RFP: img -- unprivileged OCI-compatible container image builder

[James Addison]

Followup-For: Bug #959046
Control: submitter -1 ja...@reciperadar.com

Bug#1022923: RFP: python3-surt -- transform Universal Resource Identifiers into an easily-sorted format

[James Addison]

Package: wnpp
Followup-For: Bug #1022923
Control: submitter -1 ja...@reciperadar.com

Bug#1055963: ITP: minetest-mod-ltool -- Minetest mod providing utils for L-system trees

[Ying-Chun Liu (PaulLiu)]

Package: wnpp
Owner: "Ying-Chun Liu (PaulLiu)" 
Severity: wishlist

* Package name: minetest-mod-ltool
  Version : 1.6.1
  Upstream Contact: Wuzzy 
* URL : https://codeberg.org/Wuzzy/minetest_ltool
* License : Expat
  Programming Lang: Lua
  Description : Minetest mod providing utils for L-system trees.
 This minetest extension adds an util to create the L-system trees.
 It is an util that helps the mod developer to design their own trees by
 the L-system.




OpenPGP_0x44173FA13D05.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055448: RFS: libsilkit/4.0.37-1 [ITP] -- Simulation in the loop kit by Vector

[Tobias Frost]

On Tue, Nov 14, 2023 at 07:45:36AM +, Krämer, Jan wrote:

> Hi Tobias,
> 
> I still have some questions:
> 
> - Is it permitted to update the libsilkit version (to 4.0.39) within the 
> review process?
Yes, you can update to a later version.

(if you do so, just upload it to mentors.d.n and then retitle this RFS
bug to reflect the new version.)

> - The only remaining vendoring is GoogleTest, which is only used for
> the unit/integration tests which are not shipped by the package. Is
> this allowed or should we use the systems libraries here as well?

It's packaged, so the packaged version should be used.

> - Related, if this is allowed, do we need to include the License
> information, since we do not ship source files nor object files
> compiled with these source files in the binary package?

My understanding is that your d/copyright needs to reflect *everything* you 
ship in your orig.tar.

> Cheers and thanks again for the review,
> Jan

Cheers,
-- 
tobi

Bug#1034867: smplayer: crash when playing video files using mplayer under Wayland

[James Addison]

Source: smplayer
Followup-For: Bug #1034867

Using smplayer 23.6.0+ds0-1 with mplayer does now play video under Wayland as
expected; thank you!

The separate issue of mplayer breakage when using an invalid wid parameter in
combination with the nokeepaspect option still seems replicable to me using
mplayer at version 1.5+svn38423-2+b1 -- a version that _should_ include the
potential fix from r38428 I think.. but I'll look into that separately (and it
would have been better for me to file a separate Debian bug for that instead of
mentioning it here.. that is/was indeed confusing).

Bug#1055950: rocm-device-libs: ROCm packages are very old

[Cordell Bloor]

HI BogDan,

On 2023-11-14 09:47, BogDan Vatra wrote:

ROCm debian packages are very old, any [chance] to upgrade it to 5.7.1?


I think the main difficulty with rocm-device-libs in particular is that 
the sources are closely coupled with LLVM and the binary package is only 
guaranteed to be compatible with the LLVM major version that built it.


IMO, rocm-device-libs should be versioned like llvm-toolchain. There 
should be a rocm-device-libs-17 package that is built with 
llvm-toolchain-17 and that installs to 
/usr/lib/llvm-17/lib/clang/17/amdgpu/bitcode. The rocm-device-libs-17 
package could be installed side-by-side with the existing 
rocm-device-libs, thereby avoiding any potential breakages when 
rocm-hipamd is upgraded from one clang version to another. There is now 
a release/17.x branch on the upstream repo [1] and we would make the 
debian source package using the tip of that branch.


With respect to the broader package updates for ROCm 5.7.1, there is a 
release plan in progress [2].


Sincerely,
Cory Bloor

[1]: https://github.com/RadeonOpenCompute/ROCm-Device-Libs/tree/release/17.x
[2]: 
https://salsa.debian.org/rocm-team/community/team-project/-/wikis/ROCm-5.7-Release-Plan

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

[Salvatore Bonaccorso]

Source: intel-microcode
Version: 3.20230808.1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 3.20230808.1~deb12u1
Control: found -1 3.20230808.1~deb11u1

Hi,

The following vulnerability was published for intel-microcode.

CVE-2023-23583[0]:
| Sequence of processor instructions leads to unexpected behavior for
| some Intel(R) Processors may allow an authenticated user to
| potentially enable escalation of privilege and/or information
| disclosure and/or denial of service via local access.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-23583
https://www.cve.org/CVERecord?id=CVE-2023-23583
[1] 
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00950.html

Regards,
Salvatore

Bug#1055960: python3.11: hurd-amd64 support

[Samuel Thibault]

Package: python3.11
Version: 3.11.6-3
Severity: important
Tags: patch

Hello,

The attached patch fixes the hurd-amd64 build of python3.11. The
equivalent was commited upstream for 3.13:
https://github.com/python/cpython/pull/108045

Could you please apply this patch to python3.11 and python3.12 in the
meanwhile?

Thanks,
Samuel

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

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

Versions of packages python3.11 depends on:
ii  libpython3.11-stdlib  3.11.6-3
ii  media-types   10.1.0
ii  mime-support  3.66
ii  python3.11-minimal3.11.6-3

Versions of packages python3.11 recommends:
ii  ca-certificates  20230311

Versions of packages python3.11 suggests:
ii  binutils 2.41-6
pn  python3.11-doc   
ii  python3.11-venv  3.11.6-3

-- no debconf information

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
Index: python3.11-3.11.6/configure.ac
===
--- python3.11-3.11.6.orig/configure.ac
+++ python3.11-3.11.6/configure.ac
@@ -1066,7 +1066,13 @@ cat > conftest.c <

Bug#1055958: readline: move libraries to /usr

[Helmut Grohne]

Source: readline
Version: 8.2-1.3
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2
X-Debbugs-Cc: vor...@debian.org

We want to finalize the /usr-merge transition via DEP17 by moving all
aliased files from / to /usr. Until recently, doing so was prohibited by
the file move moratorium. It has since been delegated to
https://wiki.debian.org/UsrMerge and we may move files albeit carefully.
https://subdivi.de/~helmut/dep17.html provides a set of things that may
go wrong.

A major aspect is the interaction with the 2038 transition
https://wiki.debian.org/ReleaseGoals/64bit-time. If libreadline8 is
renamed to libreadline8t64, upgrades from bookworm to trixie will move
files from / to /usr and between packages triggering exactly the file
loss scenario that the moratorium was meant to prevent (DEP17 P1). We
probably cannot use Conflicts (DEP17 M7) due to readline being
relatively central and have to resort to protective diversions (DEP17
M8) instead. When this comes about, please upload to experimental first
and wait at least three days. Fortunately, readline is unaffected by
most of the other problems. The debian-installer can deal with libraries
in /usr/lib/ (DEP17 P10) and the multiarch file loss (DEP17 P7)
is not applicable, because all affected filenames are
architecture-dependent. I locally verified that debootstrap continues to
work in the presence of this change.

Hence, I think we're good to go. I assume that readline is not subject
to backporting and have included a bit of cleanup in the attached patch.
Do not upload this patch to bookworm-backports. If you want to support
backports, use dh_movetousr instead. Also remember to upload
restructuring changes (such as libreadline8t64) during the trixie cycle
to experimental first.

Helmut
diff --minimal -Nru readline-8.2/debian/changelog readline-8.2/debian/changelog
--- readline-8.2/debian/changelog   2023-01-03 21:49:45.0 +0100
+++ readline-8.2/debian/changelog   2023-11-14 20:16:55.0 +0100
@@ -1,3 +1,10 @@
+readline (8.2-1.4) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move libraries to /usr. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 14 Nov 2023 20:16:55 +0100
+
 readline (8.2-1.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru readline-8.2/debian/rules readline-8.2/debian/rules
--- readline-8.2/debian/rules   2022-11-11 07:26:09.0 +0100
+++ readline-8.2/debian/rules   2023-11-14 20:16:55.0 +0100
@@ -47,8 +47,7 @@
 ifneq (,$(findstring /$(DEB_HOST_ARCH)/,/amd64/ppc64/))
   build32 = yes
   CC32 = $(CROSS) -m32
-  lib32dir = lib32
-  lib32devdir = usr/lib32
+  lib32dir = usr/lib32
   gencontrol_flags = -- \
'-Vdevxx:Depends=libc6-dev-$(ARCH32)'
   ifeq ($(DEB_HOST_ARCH),amd64)
@@ -250,15 +249,9 @@
 
: # move $(p_rl)
dh_installdirs -p$(p_rl) \
-   etc \
-   lib/$(DEB_HOST_MULTIARCH) \
+   usr/lib/$(DEB_HOST_MULTIARCH) \
usr/share/doc
-   cp -a $(d)/usr/lib/$(DEB_HOST_MULTIARCH)/lib{history,readline}.so.* 
$(d_rl)/lib/$(DEB_HOST_MULTIARCH)/
-#  cp -a $(d)/usr/lib/lib{history,readline}.so.$(libversion) $(d_rl)/lib/
-#  ln -s libhistory.so.$(libversion) \
-#  $(d_rl)/lib/libhistory.so.$(soversion)
-#  ln -s libreadline.so.$(libversion) \
-#  $(d_rl)/lib/libreadline.so.$(soversion)
+   cp -a $(d)/usr/lib/$(DEB_HOST_MULTIARCH)/lib{history,readline}.so.* 
$(d_rl)/usr/lib/$(DEB_HOST_MULTIARCH)/
 
: # move $(p_comm)
dh_installdirs -p$(p_comm) \
@@ -279,9 +272,9 @@
usr/lib/$(DEB_HOST_MULTIARCH)/pkgconfig \
usr/share/doc \
usr/share/info
-   ln -s /lib/$(DEB_HOST_MULTIARCH)/libhistory.so.$(soversion) \
+   ln -s libhistory.so.$(soversion) \
$(d_rld)/usr/lib/$(DEB_HOST_MULTIARCH)/libhistory.so
-   ln -s /lib/$(DEB_HOST_MULTIARCH)/libreadline.so.$(soversion) \
+   ln -s libreadline.so.$(soversion) \
$(d_rld)/usr/lib/$(DEB_HOST_MULTIARCH)/libreadline.so
mv $(d)/usr/lib/$(DEB_HOST_MULTIARCH)/lib{history,readline}.a \
$(d_rld)/usr/lib/$(DEB_HOST_MULTIARCH)/.
@@ -327,13 +320,13 @@
infodir=/usr/share/info
 
dh_installdirs -p$(p_rlu) \
-   lib/$(DEB_HOST_MULTIARCH)
+   usr/lib/$(DEB_HOST_MULTIARCH)
cp -p 
$(du)/usr/lib/$(DEB_HOST_MULTIARCH)/lib{history,readline}.so.$(libversion) \
-   $(d_rlu)/lib/$(DEB_HOST_MULTIARCH)/
+   $(d_rlu)/usr/lib/$(DEB_HOST_MULTIARCH)/
ln -s libhistory.so.$(libversion) \
-   $(d_rlu)/lib/$(DEB_HOST_MULTIARCH)/libhistory.so.$(soversion)
+   
$(d_rlu)/usr/lib/$(DEB_HOST_MULTIARCH)/libhistory.so.$(soversion)
ln -s libreadline.so.$(libversion) \
-   $(d_rlu)/lib/$(DEB_HOST_MULTIARCH)/libreadline.so.$(soversion)
+   

Bug#947323: libcap-ng: Please install libs back into /usr/lib/ when usrmerge arrives

[Helmut Grohne]

user helm...@debian.org
usertags -1 + dep17m2
thanks

On Tue, Nov 14, 2023 at 12:52:39PM +0100, Helmut Grohne wrote:
> Hence, we are good to go. I do not expect libcap-ng to be uploaded to
> bookworm-backports and therefore changed the paths directly in the
> attached patch. This patch should not be uploaded to bookworm-backports.
> If that's relevant to you, consider using dh_movetousr instead. Also
> keep in mind that restructuring changes (such as libcap-ng0t64) should
> be uploaded to experimental first to let dumat analyze your change for
> possible problems.

I'm sorry. Further testing has revealed that I failed to remove the /lib
directory from the package. We really need to get rid of it, because
dpkg is not equipped to deal with symlink vs directory conflicts. Here
is an updated patch.

Helmut
diff --minimal -Nru libcap-ng-0.8.3/debian/changelog 
libcap-ng-0.8.3/debian/changelog
--- libcap-ng-0.8.3/debian/changelog2022-06-23 07:22:33.0 +0200
+++ libcap-ng-0.8.3/debian/changelog2023-11-14 19:31:43.0 +0100
@@ -1,3 +1,10 @@
+libcap-ng (0.8.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move libraries to /usr. Closes: #947323
+
+ -- Helmut Grohne   Tue, 14 Nov 2023 19:31:43 +0100
+
 libcap-ng (0.8.3-1) unstable; urgency=medium
 
   * New upstream release. Closes: #1004519
diff --minimal -Nru libcap-ng-0.8.3/debian/libcap-ng0.dirs 
libcap-ng-0.8.3/debian/libcap-ng0.dirs
--- libcap-ng-0.8.3/debian/libcap-ng0.dirs  2022-06-23 07:22:33.0 
+0200
+++ libcap-ng-0.8.3/debian/libcap-ng0.dirs  2023-11-14 19:31:37.0 
+0100
@@ -1,2 +1 @@
-lib
 usr/lib
diff --minimal -Nru libcap-ng-0.8.3/debian/libcap-ng0.install 
libcap-ng-0.8.3/debian/libcap-ng0.install
--- libcap-ng-0.8.3/debian/libcap-ng0.install   2022-06-23 07:22:33.0 
+0200
+++ libcap-ng-0.8.3/debian/libcap-ng0.install   2023-11-14 19:31:24.0 
+0100
@@ -1 +1 @@
-lib/*/lib*.so.*
+usr/lib/*/lib*.so.*
diff --minimal -Nru libcap-ng-0.8.3/debian/rules libcap-ng-0.8.3/debian/rules
--- libcap-ng-0.8.3/debian/rules2022-06-23 07:22:33.0 +0200
+++ libcap-ng-0.8.3/debian/rules2023-11-14 19:31:24.0 +0100
@@ -34,12 +34,6 @@
done
 
find $(CURDIR)/debian/tmp -name *.la -delete
-   mkdir -p $(CURDIR)/debian/tmp/lib/$(DEB_HOST_MULTIARCH) && \
-   mv $(CURDIR)/debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/lib*.so.0* 
$(CURDIR)/debian/tmp/lib/$(DEB_HOST_MULTIARCH)/; \
-   rm debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libcap-ng.so; \
-   ln -s ../../../lib/$(DEB_HOST_MULTIARCH)/libcap-ng.so.0.0.0 
debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libcap-ng.so; \
-   rm debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libdrop_ambient.so; \
-   ln -s ../../../lib/$(DEB_HOST_MULTIARCH)/libdrop_ambient.so.0.0.0 
debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libdrop_ambient.so; \
 
 override_dh_auto_test:
for V in $(PY3VERS); do \

Bug#1055938: zlib1g: move libz.so.* to /usr

[Helmut Grohne]

Hi Mark,

On Tue, Nov 14, 2023 at 11:45:36AM +0100, Helmut Grohne wrote:
> Hence, I think we are good to move ahead. When uploading this, please
> bear two things in mind: This change should not be uploaded to
> bookworm-backports. If you end up renaming packages (such as 2038)
> within the trixie cycle, do upload to experimental first and wait three
> days. I'm attaching a patch.

And I still managed to get one bit wrong. While my patch moves the
libraries, it keeps the empty /lib directory. Its existence does not
cause harm right now, but when base-files ships symlinks there and dpkg
is not equipped in dealing with symlink vs directory conflicts, bad
things happen. So here goes my updated patch. Sorry for the extra noise.

Helmut
diff --minimal -Nru zlib-1.2.13.dfsg/debian/changelog 
zlib-1.2.13.dfsg/debian/changelog
--- zlib-1.2.13.dfsg/debian/changelog   2023-08-15 15:35:28.0 +0200
+++ zlib-1.2.13.dfsg/debian/changelog   2023-11-14 19:37:29.0 +0100
@@ -1,3 +1,10 @@
+zlib (1:1.2.13.dfsg-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move libz.so.* to /usr. (closes: #1055938)
+
+ -- Helmut Grohne   Tue, 14 Nov 2023 19:37:29 +0100
+
 zlib (1:1.2.13.dfsg-3) unstable; urgency=low
 
   * Further fixes to the minizip integration, don't install the minizip
diff --minimal -Nru zlib-1.2.13.dfsg/debian/rules zlib-1.2.13.dfsg/debian/rules
--- zlib-1.2.13.dfsg/debian/rules   2023-08-15 01:27:48.0 +0200
+++ zlib-1.2.13.dfsg/debian/rules   2023-11-14 19:36:53.0 +0100
@@ -179,10 +179,6 @@
 
$(MAKE) -C contrib/minizip prefix=$(CURDIR)/debian/tmp/usr install
 
-   install -d debian/tmp/lib/$(DEB_HOST_MULTIARCH)
-   mv debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libz.so.* 
debian/tmp/lib/$(DEB_HOST_MULTIARCH)
-   ln -sf /lib/$(DEB_HOST_MULTIARCH)/$$(readlink 
debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libz.so) 
debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libz.so
-
 install64: install build64-stamp
$(MAKE) -C debian/64 prefix=$(CURDIR)/debian/tmp install
 
diff --minimal -Nru zlib-1.2.13.dfsg/debian/zlib1g-udeb.dirs 
zlib-1.2.13.dfsg/debian/zlib1g-udeb.dirs
--- zlib-1.2.13.dfsg/debian/zlib1g-udeb.dirs2022-11-05 13:24:24.0 
+0100
+++ zlib-1.2.13.dfsg/debian/zlib1g-udeb.dirs1970-01-01 01:00:00.0 
+0100
@@ -1 +0,0 @@
-lib
diff --minimal -Nru zlib-1.2.13.dfsg/debian/zlib1g-udeb.install 
zlib-1.2.13.dfsg/debian/zlib1g-udeb.install
--- zlib-1.2.13.dfsg/debian/zlib1g-udeb.install 2022-11-05 13:24:24.0 
+0100
+++ zlib-1.2.13.dfsg/debian/zlib1g-udeb.install 2023-11-14 19:36:53.0 
+0100
@@ -1 +1 @@
-lib/*/lib*.so.* usr/lib
+usr/lib/*/libz*.so.* usr/lib
diff --minimal -Nru zlib-1.2.13.dfsg/debian/zlib1g.dirs 
zlib-1.2.13.dfsg/debian/zlib1g.dirs
--- zlib-1.2.13.dfsg/debian/zlib1g.dirs 2022-11-05 13:24:24.0 +0100
+++ zlib-1.2.13.dfsg/debian/zlib1g.dirs 1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-lib
diff --minimal -Nru zlib-1.2.13.dfsg/debian/zlib1g.install 
zlib-1.2.13.dfsg/debian/zlib1g.install
--- zlib-1.2.13.dfsg/debian/zlib1g.install  2022-11-05 13:24:24.0 
+0100
+++ zlib-1.2.13.dfsg/debian/zlib1g.install  2023-11-14 19:36:53.0 
+0100
@@ -1 +1 @@
-lib/*/lib*.so.*
+usr/lib/*/libz*.so.*

Bug#1055959: libtirpc3: move library to /usr

[Helmut Grohne]

Source: libtirpc
Version: 1.3.4+ds-1
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2
X-Debbugs-Cc: vor...@debian.org

We want to finalize the /usr-merge transition via DEP17 by moving all
aliased files to /usr. Until recently, doing so was prohibited by the
file move moratorium. It has since been delegated to
https://wiki.debian.org/UsrMerge. Files can now be moved albeit
carefully. https://subdivi.de/~helmut/dep17.html gives details on what
could go wrong.

Most importantly, the 2038 transition
https://wiki.debian.org/ReleaseGoals/64bit-time may rename the library
package to libtirpc3t64. In a bookworm -> trixie upgrade, the library is
thus moved from / to /usr and from libtirpc3 to libtirpc3t64. This is
exactly the situation that the moratorium was meant to prevent. We
probably cannot employ Conflicts (DEP17 M7) here, because libtirpc3 is
too central and have to resort to protective diversions (DEP17 M8)
instead. When this happens, please upload to experimental first and wait
at least three days. It is unaffected by most of the other problems. In
particular, the multiarch-related file loss is not applicable, because
all affected filenames are architecture-specific. It also does not break
the debian-installer, because /usr/lib/ is on the default
library search path even on unmerged systems. I locally verified that
filesystem bootstrap continues to work with this change.

Hence, I think we are good to move ahead. I assume that backporting
libtirpc will not happen. As such, I am attaching a patch that also does
cleanup and forces the new location. It should not be uploaded to
bookworm-backports. If you want to handle backports, please use
dh_movetousr instead as that will turn itself into a no-op in backports.
Also remember to upload restructuring changes (e.g. libtirpc3t64) to
experimental within the trixie release cycle.

Helmut
diff --minimal -Nru libtirpc-1.3.4+ds/debian/changelog 
libtirpc-1.3.4+ds/debian/changelog
--- libtirpc-1.3.4+ds/debian/changelog  2023-11-13 00:45:44.0 +0100
+++ libtirpc-1.3.4+ds/debian/changelog  2023-11-14 19:58:09.0 +0100
@@ -1,3 +1,10 @@
+libtirpc (1.3.4+ds-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move library to /usr. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 14 Nov 2023 19:58:09 +0100
+
 libtirpc (1.3.4+ds-1) unstable; urgency=medium
 
   [ Debian Janitor ]
diff --minimal -Nru libtirpc-1.3.4+ds/debian/libtirpc3.install 
libtirpc-1.3.4+ds/debian/libtirpc3.install
--- libtirpc-1.3.4+ds/debian/libtirpc3.install  2023-11-13 00:45:44.0 
+0100
+++ libtirpc-1.3.4+ds/debian/libtirpc3.install  2023-11-14 19:57:56.0 
+0100
@@ -1 +1 @@
-lib/*/lib*.so.*
+usr/lib/*/lib*.so.*
diff --minimal -Nru libtirpc-1.3.4+ds/debian/rules 
libtirpc-1.3.4+ds/debian/rules
--- libtirpc-1.3.4+ds/debian/rules  2023-11-13 00:45:44.0 +0100
+++ libtirpc-1.3.4+ds/debian/rules  2023-11-14 19:57:47.0 +0100
@@ -23,14 +23,6 @@
 
 DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 override_dh_install:
-   # Move libtirpc.so.* to /lib
-   mkdir -p debian/tmp/lib/$(DEB_HOST_MULTIARCH)
-   mv debian/tmp/usr/lib/*/libtirpc.so.* 
debian/tmp/lib/$(DEB_HOST_MULTIARCH)
-
-   # Fix up the -dev symlink
-   LINKTARGET=`readlink 
debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libtirpc.so`; \
-   ln -sf /lib/$(DEB_HOST_MULTIARCH)/$$LINKTARGET 
debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libtirpc.so
-
dh_install -Nlibtirpc3-udeb
dh_install -plibtirpc3-udeb --sourcedir=debian/tmp-udeb
 

Bug#1055957: RM: pvm -- RoQA; orphaned; dead upstream

[Chris Hofstaedtler]

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

Dear ftpmasters,

please remove pvm. It is orphaned in Debian, effectively has seen no
real maintenance since 2016. Upstream also has done nothing since 2016,
and at least I can't find the upstream sources anymore.

It also hinders the removal of netkit-rsh, #1041864.

Thanks,
Chris

Bug#1055956: ITP: kooha -- elegantly record your screen

[Matthias Geiger]

Package: wnpp
Severity: wishlist
Owner: Matthias Geiger 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-gtk-gn...@lists.debian.org, 
werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: kooha
  Version : 2.2.4
  Upstream Contact: Dave Patrick Caberto 
* URL : https://github.com/SeaDve/Kooha
* License : GPL-3+
  Programming Lang: Rust
  Description : elegantly record your screen

kooha is a small app to record ones screen. It supports both X11 and
Wayland desktops. Furthermore, audio-only and selective screen recording
is supported. This package with bee maintained wuth the Debian GNOME
team.

best,

werdahias

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmVTwJkVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1jiEP/2OjFw32pzz7C5kq4calpX8g/zVk
vTnYfBRVGgovCzov4WnfwFxl0/G3TOqYaPagYDKzLgdlDxJGw9AI/bZ4U4aNSsuv
9R4aB3dOPiPPKpY53OPq8++xyr+70pkHOHle6+/D+Ajh8PC+QE9Qfk4UwsIOm9sC
UBaRWiNvA53y9p9GWPoLebI3i+HjkBAkKx5wrKKDf3gJBQBOBRX4HlI0MGXdBVuN
kPbL0yhuBgGCGMFy2ppp9c37VromLftd5ufdvDQbXlpt6XYCChSPROTwxtIc+9D7
WfcGcxpTn+dxr1C0Xmb0Unp7KBaug424UdYwp6r7Ob0rdPkkYYNWqFlmPit/LCb6
ICk4I7NRPR4ha/stdFcr/Oadq+MbC9yQ8THyCpY01y0Aqyw8e/wCu59HRC+m6VqD
LFq3cIzcTp3qrC8gfzo8f5nHmAYP7Y8YdM357FgMmJe8IQ92IpHLhGX70RJf5XyH
kmZ1eCE7CwRP2CDTt515MIJitAuhWBvRo1po/hit7prGBUzY0DvImQWJMS0THaxW
y3PpWt4XtstTyrkbqpZMfovuJ0kovECdzMRbLmXAJ/XhBziYoefDs8IBiLukyPh9
JH9vAAxMw9QzgaYphUP/P/2gJfVCrYhDcp82yENZPvCIqxHRZj1uO9zof3zKFMbF
X1JkVZE5Qs3MFbCj
=Bbq3
-END PGP SIGNATURE-

Bug#1055955: transition: perl 5.38

[Emilio Pozuelo Monfort]

On 14/11/2023 19:28, Niko Tyni wrote:

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: p...@packages.debian.org

Hi release team,

this has taken me much longer than necessary for various reasons, but I
think we're almost ready to push Perl 5.38 to sid now.

We should aim to release trixie with 5.40 (which will be released in May
2024 or so), but it's still better to do these transitions one at a time.


Indeed. And sounds good about releasing with 5.40.


TL;DR:

- can we raise the remaining bugs to severity:serious?


Go ahead.


- I'll request a transition slot once the easy ones are fixed


Cool.


- should we worry about time64?


Let's not block (or even entangle) on that.

Cheers,
Emilio

Bug#1055955: transition: perl 5.38

[Niko Tyni]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: p...@packages.debian.org

Hi release team,

this has taken me much longer than necessary for various reasons, but I
think we're almost ready to push Perl 5.38 to sid now.

We should aim to release trixie with 5.40 (which will be released in May
2024 or so), but it's still better to do these transitions one at a time.

TL;DR:

- can we raise the remaining bugs to severity:serious?

- I'll request a transition slot once the easy ones are fixed

- should we worry about time64?

Perl 5.38 been in experimental since July, and we've been running
continuous amd64 rebuilds on perl.debian.net all the time. I also
checked for related autopkgtest regressions back in August/September
in all packages declaring Testsuite: autopkgtest-pkg-perl or having
Testsuite-Triggers: perl. The bugs we found are tracked with the usual
usertags:

  
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=perl-5.38-transition;users=debian-p...@lists.debian.org

There's a few packages that are nontrivially broken and will probably
need to be removed from testing.

  libapache-db-perl #1040396

  libembperl-perl #1042845

  polymake #1042521

AFAICS polymake has one reverse dependency (gap-polymaking) and the
others have none, so removal shouldn't be too difficult.

Then there's some that already have patches or where the fixes are
trivial, but just need an upload:

  docknot #1042853

  elinks #1042844

  libgtk3-imageview-perl #1050445

  libperl-languageserver-perl #1050451

  libregexp-debuggperl-perl #1050454

  localehelper #1042525

I haven't checked reverse dependencies as I'm hoping they will be fixed.
Can we raise these bugs to severity:serious?

I can report back when these are fixed and request a transition slot.

Finally I just ran one more rebuild test for all the packages that will
need binNMUs, and found a couple of unrelated FTBFS bugs.  These would
block binNMUs.

  cod-tools #1055896 (fixed in sid today, needs to migrate)

  os-autoinst #1054776

  libprelude #1054793

  libauthen-sasl-cyrus-perl #1052871 (not in testing)

I haven't checked for version skew between testing and unstable, or for
any architecture specific issues on !amd64 as I don't have any good tools
for those. I suppose we'll need to handle them during the transition if
we hit any.

One more thing to mention: I'm slightly worried about the time64
transition that I think was supposed to happen this release cycle. As
I mentioned in July [1] I think it will need a perlapi-* bump and the
related binNMUs of the same set of packages.

[1] https://lists.debian.org/debian-devel/2023/07/msg00302.html

But things seem to be quiet and I still haven't looked at the perl side
of that at all. (I also have no idea how it can be done without a flag
day but I hope somebody does.) I don't think we should block on this
unless there's some activity that I've missed?


Ben file proposal, just copy-pasting from last year:

title = "perl";
is_affected = .depends ~ "libperl5.36|perlapi-5.36" | .pre-depends ~ 
"libperl5.36|perlapi-5.36";
is_good = .depends ~ "libperl5.38|perlapi-5.38" | .pre-depends ~ 
"libperl5.38|perlapi-5.38";
is_bad = .depends ~ "libperl5.36|perlapi-5.36" | .pre-depends ~ 
"libperl5.36|perlapi-5.36";

Thanks for your work on Debian,
-- 
Niko

Bug#1055765: chromium: Error: Can't open display (armhf) while other platforms (amd64, arm64, i386) are OK

[Andres Salomon]

Ah, so the "Can't open display" error is coming from xmessage, *not* 
chromium. I should fix that.


As far as qemu, I'd suggest filing a bug on that binfmt project to not 
use passthrough mode; I'm not sure if it should be something 
decided/set at build time, or if there's a way to get commandline 
arguments to qemu when executing binaries using the kernel's binfmt 
interface. Either way, that seems like something to discuss with the 
project author.


And for your purposes, if you want to just get the chromium version, 
you can skip the wrapper in /usr/bin and run 
`/usr/lib/chromium/chromium --version` instead. It won't be exactly the 
same output, but it will give you the version.




On Tue, Nov 14 2023 at 01:39:19 PM +01:00:00, Julien Neuhart 
 wrote:
Please find below the output of ‘bash -x /usr/bin/chromium 
—version’ (latest chromium version on armhf):


bash -x /usr/bin/chromium --version:
+ APPNAME=chromium
+ GDB=/usr/bin/gdb
+ LIBDIR=/usr/lib/chromium
+ BUILD_DIST=12.2
+ nosse3='The hardware on this system lacks support for the sse3 
instruction set.

The upstream chromium project no longer supports this configuration.
For more information, please read and possibly provide input to their
bug tracking system at http://crbug.com/1123353'
+ case `uname -m` in
++ uname -m
+ noneon='The hardware on this system lacks support for NEON SIMD 
extensions.

We now require NEON or equivalent architecture extensions on ARM-based
machines. See 
https://lists.debian.org/debian-devel/2023/09/msg00175.html

for more information.'
+ case `uname -m` in
++ uname -m
+ grep -q 'neon\|asimd' /proc/cpuinfo
+ xmessage 'The hardware on this system lacks support for NEON SIMD 
extensions.

We now require NEON or equivalent architecture extensions on ARM-based
machines. See 
https://lists.debian.org/debian-devel/2023/09/msg00175.html

for more information.'
Error: Can't open display:


Regarding QEMU, I’m a bit out of my depth to be honest.
Most of it is abstract to me, as I’m using a Docker buildkit which 
itself is relying on QEMU (as far as I know).


More precisely, I’m relying on this 
https://github.com/docker/setup-qemu-action GitHub Action, which 
itself relies on https://github.com/tonistiigi/binfmt to do the magic.


This repository seems to configure a custom version of QEMU (for 
instance, by applying patches) and configure it using:


set -x
./configure \
  --prefix=/usr \
  --with-pkgversion=$QEMU_VERSION \
  --enable-linux-user \
  --disable-system \
  --static \
  --disable-brlapi \
  --disable-cap-ng \
  --disable-capstone \
  --disable-curl \
  --disable-curses \
  --disable-docs \
  --disable-gcrypt \
  --disable-gnutls \
  --disable-gtk \
  --disable-guest-agent \
  --disable-guest-agent-msi \
  --disable-libiscsi \
  --disable-libnfs \
  --disable-mpath \
  --disable-nettle \
  --disable-opengl \
  --disable-pie \
  --disable-sdl \
  --disable-spice \
  --disable-tools \
  --disable-vte \
  --disable-werror \
  --disable-debug-info \
  --disable-glusterfs \
  --cross-prefix=$(xx-info)- \
  --host-cc=$(xx-clang --print-target-triple)-clang \
  --host=$(xx-clang --print-target-triple) \
  --build=$(TARGETPLATFORM= TARGETPAIR= xx-clang 
--print-target-triple) \

  --cc=$(xx-clang --print-target-triple)-clang \
  --extra-ldflags=-latomic \
  --target-list="$QEMU_TARGETS »

See 
https://github.com/tonistiigi/binfmt/blob/master/scripts/configure_qemu.sh 
and https://github.com/tonistiigi/binfmt/blob/master/Dockerfile for 
more details

Bug#1055954: ITP: controku -- Control Roku devices from the comfort of your own desktop

[Ben Westover]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: controku
  Version : 1.1.0
  Upstream Contact: Ben Westover 
* URL : https://github.com/benthetechguy/controku
* License : GPL-3
  Programming Lang: Python
  Description : Control Roku devices from the comfort of your own desktop

Controku is a library and GTK3 application that allows you to control
Roku devices from the comfort of your own desktop.

I am the developer of this program. I find it very useful, and it would
be nice to have in Debian. I plan to maintain it inside of the Python
team. I will need a sponsor for the initial upload, as I am only a DM.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOGnacqRhdU6eNmtFwxHF9U6JtpgFAmVTr6kACgkQwxHF9U6J
tphZVxAAps/BL8t83IiPaA5EoTlx5SlIs1me9g266vzAVaootjg5vJ5uUa86snA1
efdCdKfBvNgXyECQxM1yK0TFp4utM0yRAYg1f4JfZ2pZBI2/cyNenlUizvD3Qdp7
jSzHpdBHpEv0O+yzhU9F6PhO+jfUBRubKMjFheUU/8n1VWYNnGdbLvH4hIIO2pEi
aNtlqX95BA2jxNwpJldkMYqIxKKrY1pnu8iXaOGZ6gen8Ru6e1hQ4RxmHva5odh3
5ws6rwLsAW+Butlsa4dRWfS5+tpzbjsf780bvu2oI1Anqrp04CaiKyvGlIV2V0TA
QLk6vFLVT8Y0TZHuTJxYmUHBYt+gZ9TVIj/hIkQZLCRpWRXEj2SKAPe8t2ZimcXU
Zbes0u8QdakmMT52swvL1Wv8AOd+Xfi4DSuYhM8ZJ+18PQ/Cwa2X3Pqre9JGPkQ8
GPiHDY3ff57kaun7inSMrKU0gYqisuLVq2MrFSyt2YckEfdHenzp5o5xMg6Y22xI
1OKMNTh99N/qkrPl0v4ueX0B6XE2NagDF/Jo55U0jxmOc1Hin3i0iE8Xz9Wu2qwk
eKZxbbwnF5x3CLAHcuDTSsqvE8deqxHSXJNuBFh9iMNm1JrnTqmWSDrpEG2lmpZz
uAKMzGqgfeKQIT7cjqXM5Dk8mOwObthvR5weg2hTUg+LMDVtpJ4=
=BtbR
-END PGP SIGNATURE-

Bug#1055952: vlc: upgrade to libva 7:6.1-2

[Sebastian Ramacher]

Control: reassign -1 libavcodec60 7:6.1-1
Control: severity -1 serious
Control: tags -1 confirmed upstream

On 2023-11-14 20:00:47 +0300, Vladmimir Stavrinov wrote:
> Package: vlc
> Version: 3.0.20-1+b1
> Severity: normal
> 
> 
> As result vlc crashed on video play. Downgrade libva to 7:6.0-9+b1 solves 
> this problem. Please update vlc for the new libva version.

Based on discussions on #ffmpeg-devel this morning, this is a regression
in ffmpeg 6.1 and will need to be fixed there.

Cheers
-- 
Sebastian Ramacher

Bug#1055953: Gcompris does not read images without qt5-image-formats-plugins

[Contact ETCHE.NET]

Package: gcompris-qt
Version: 3.1-2


Bonjour,
Il faut absolument le paquets qt5-image-formats-plugins pour que 
gcompris puisse lire les images webp.
Il serait judicieux de l'ajouter dans la liste des dépendances 
obligatoire à l'installation de gcompris-qt

Hello,
The qt5-image-formats-plugins package must be installed for gcompris to 
be able to read webp images.
It would be a good idea to add it to the list of mandatory dependencies 
when installing gcompris-qt.


Sincerely


smime.p7s
Description: Signature cryptographique S/MIME

Bug#958692: node-matrix-js-sdk: Remove dependency to node-request

[Hubert Chathi]

On Fri, 3 Nov 2023 00:27:36 +0530, Pirate Praveen  
said:

> On 2/11/23 10:27 PM, Hubert Chathi wrote:
>> On Sun, 29 Oct 2023 22:43:55 +0530, Praveen Arimbrathodiyil
>>  said:
>> 
>>> On Fri, 24 Apr 2020 13:52:39 +0200 y...@debian.org wrote:
 Upstream has deprecated node-request:
 https://github.com/request/request/issues/3142 It can be replaced
 by node-got
>> 
>>> Hi Jonas, Hubert,
>> 
>>> Are you planning to update matrix-js-sdk? We'd like to remove
>>> deprecated node-request from the archive and this package is a
>>> blocker.
>> I don't currently have time to update matrix-js-sdk.  Feel free to
>> remove it from testing so that it doesn't block anything else.  I can
>> always upload a new version later.
>> 

> This is already not in testing for 525 days. We can't remove a package
> from the archive if any package (build) depends on it.

OK, I understand.  Yes, go ahead and remove it.

-- 
Hubert Chathi  -- https://www.uhoreg.ca/
Jabber: hub...@uhoreg.ca -- Matrix: @uhoreg:matrix.org
PGP/GnuPG key: 4096R/F24C F749 6C73 DDB8 DCB8  72DE B2DE 88D3 113A 1368

Bug#1026164: ffprobe: "-of json" doesn't report anything

[Diederik de Haas]

On 12 Nov 2023 19:56:22 + Phil Wyett  wrote:
> Looking at the docs, you can use -of or -print_format like follows for a
> nice json file.
> 
> ffprobe -v quiet -of json -show_format -show_streams "Critical.ogg" >
> "Critical.ogg.json"
> 
> Your needs may require some changes.

That gives a much nicer/better and much more valid result. Thanks!

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

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

[Colin King (gmail)]

Hi Balint,

I've uploaded 0.4.0-2 with the suggested fixes.

reply inlined below:

On 09/11/2023 16:23, Bálint Réczey wrote:

Hi Colin,

Colin King (gmail)  ezt írta (időpont: 2023.
nov. 7., K, 15:18):


Hi Balint,

Thanks for responding with the review. I was waiting for the upstream
project to release a 0.4 with some minor fixes before re-uploading to
mentors.

I've addressed the issues you found as below:


Please see my observations below.


On 22/10/2023 22:38, Bálint Réczey wrote:

Hi Colin,

I've checked the second upload at [1].
As you can see in the Lintian warnings there is a .git directory which
is not ideal for a source package.
I suggest using the most widely used git-buildpackage based workflow
where the gbp command takes care of exporting the source package
without the .git dir from the packaging repository.
I'd be happy to set up a packaging repo for you at
https://salsa.debian.org/debian/libtypec and add you as a maintainer
as described in [2]


I still hold up my offer about setting up a git repo for packaging on
Salsa. That comes with the benefit of automated fixes from Debian
Janitor and I could also comment on changes right where they happened.


Thank you for your kind offer; I definitely think this is a good idea, 
please can you set this up for me. Much appreciated!





Other observations regarding the packaging:

* There is debian/install and also there are binary package specific
*.install files which is slightly confusing.
 I suggest dropping debian/install.


Fixed


* In the debian/*.install files you need to specify only the target
dir, not the target file.


Fixed


In libtypec-dev
/usr/share/pkgconfig/${DEB_HOST_MULTIARCH}/libtypec.pc/libtypec.pc
gets shipped, which is not desired.


Fixed


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


Fixed




* libtypec.h seems to be the same on all architectures. Does it have
to be shipped in a multiarch include location?


Fixed. Now in /usr/include and in the multiarch include location


* Binary packages in debian/control are not marked as Multi-Arch: same
* Please target experimental. The package needs to pass NEW and to
migrate to testing it will need a new source-only upload anyway.



Fixed.

Please review the 0.4 release upload and let me know if this can be
sponsored further to the changes I made.


* Both libtypec-dev.install and libtypec1.install lists
usr/lib/${DEB_HOST_MULTIARCH} and as a result both packages ship the
*.so symlink and *.so.0.4.0.
Please ship *.so.0.4.0 in the library package and the *.so symlink in
the -dev package only.


Fixed.



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


Fixed.

.


* I'd recommend asking upstream to switch to semantic SO versioning
instead of using the project's version and switching to major version
1 when the API stabilized.


Good idea. Will do when API changes and stabilizes.

Colin



Cheers,
Balint


Kind regards,

Colin



Cheers,
Balint

[1] https://mentors.debian.net/package/libtypec/
[2] 
https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group

On Thu, 3 Aug 2023 17:00:58 +0100 "Colin King (gmail)"
 wrote:

Hi,

I've uploaded a fixed package that addresses these issues.

Colin

On 18/07/2023 08:50, Adam Borowski wrote:

On Mon, Jul 17, 2023 at 03:29:13PM +0100, Colin King (gmail) wrote:

* Package name : libtypec
  Version  : 0.3-1
* URL  : https://github.com/Rajaram-Regupathy/libtypec



 libtypec1 - generic interface for efficient USB-C port management
 libtypec-dev - Development files for an interface for USB-C port management



libtypec (0.3-1) unstable; urgency=low
.
  * Initial release (Closes: #1023477)
  * Add patch 0001-fix-libtypec-so-version.patch to fix .so name version


Hi!
Before doing manual review, let's start with lintian:

E: libtypec1: pkg-config-multi-arch-wrong-dir full text contains architecture 
specific dir x86_64-linux-gnu [usr/share/pkgconfig/libtypec.pc]
W: libtypec-dev: empty-binary-package
W: libtypec1: lacks-unversioned-link-to-shared-library example: 
usr/lib/x86_64-linux-gnu/libtypec.so 
[usr/lib/x86_64-linux-gnu/libtypec.so.0.3.0]
W: libtypec1: link-to-shared-library-in-wrong-package 
usr/lib/x86_64-linux-gnu/libtypec.so.0.3.0 
[usr/lib/x86_64-linux-gnu/libtypec.so]


Meow!

Bug#1055952: vlc: upgrade to libva 7:6.1-2

[Vladmimir Stavrinov]

Package: vlc
Version: 3.0.20-1+b1
Severity: normal


As result vlc crashed on video play. Downgrade libva to 7:6.0-9+b1 solves this 
problem. Please update vlc for the new libva version.


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

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

Versions of packages vlc depends on:
ii  vlc-bin  3.0.20-1+b1
ii  vlc-plugin-base  3.0.20-1+b1
ii  vlc-plugin-qt3.0.20-1+b1
ii  vlc-plugin-video-output  3.0.20-1+b1

Versions of packages vlc recommends:
ii  vlc-l10n   3.0.20-1
ii  vlc-plugin-access-extra3.0.20-1+b1
ii  vlc-plugin-notify  3.0.20-1+b1
ii  vlc-plugin-samba   3.0.20-1+b1
ii  vlc-plugin-skins2  3.0.20-1+b1
ii  vlc-plugin-video-splitter  3.0.20-1+b1
ii  vlc-plugin-visualization   3.0.20-1+b1

Versions of packages vlc suggests:
ii  vlc-plugin-fluidsynth  3.0.20-1+b1
ii  vlc-plugin-jack3.0.20-1+b1
ii  vlc-plugin-pipewire3-2
ii  vlc-plugin-svg 3.0.20-1+b1

Versions of packages libvlc-bin depends on:
ii  libc62.37-12
ii  libvlc5  3.0.20-1+b1

Versions of packages libvlc5 depends on:
ii  libc62.37-12
ii  libvlccore9  3.0.20-1+b1

Versions of packages libvlc5 recommends:
ii  libvlc-bin  3.0.20-1+b1

Versions of packages libvlccore8 depends on:
ii  libc62.37-12
ii  libdbus-1-3  1.14.10-3
ii  libidn11 1.33-3

Versions of packages libvlccore8 recommends:
ii  libproxy-tools  0.4.18-1.2

Versions of packages vlc-bin depends on:
ii  libc6   2.37-12
ii  libvlc-bin  3.0.20-1+b1
ii  libvlc5 3.0.20-1+b1

Versions of packages vlc-plugin-access-extra depends on:
ii  libc62.37-12
ii  libsrt1.5-gnutls 1.5.3-1
ii  libvlccore9 [vlc-plugin-abi-3-0-0f]  3.0.20-1+b1
ii  libvncclient10.9.14+dfsg-1
ii  libxcb-composite01.15-1
ii  libxcb-shm0  1.15-1
ii  libxcb1  1.15-1

Versions of packages vlc-plugin-base depends on:
ii  liba52-0.7.4 0.7.4-20
ii  libarchive13 3.7.2-1
ii  libaribb24-0 1.0.3-2
ii  libasound2   1.2.10-1
ii  libass9  1:0.17.1-1
ii  libavahi-client3 0.8-13
ii  libavahi-common3 0.8-13
ii  libavc1394-0 0.5.4-5
ii  libavcodec60 7:6.0-9+b1
ii  libavformat607:6.0-9+b1
ii  libavutil58  7:6.0-9+b1
ii  libbluray2   1:1.3.4-1
ii  libc62.37-12
ii  libcairo21.18.0-1
ii  libcddb2 1.3.2-7
ii  libchromaprint1  1.5.1-4
ii  libdav1d71.3.0-2
ii  libdbus-1-3  1.14.10-3
ii  libdc1394-25 2.2.6-4
ii  libdca0  0.0.7-2
ii  libdvbpsi10  1.3.3-1
ii  libdvdnav4   6.1.1-1
ii  libdvdread8  6.1.3-1
ii  libebml5 1.4.4-1
ii  libfaad2 2.11.1-1
ii  libflac121.4.3+ds-2
ii  libfontconfig1   2.14.2-6
ii  libfreetype6 2.13.2+dfsg-1
ii  libfribidi0  1.0.13-3
ii  libgcc-s113.2.0-6
ii  libgcrypt20  1.10.2-3
ii  libglib2.0-0 2.78.1-4
ii  libgnutls30  3.8.1-4+b1
ii  libgpg-error01.47-2
ii  libharfbuzz0b8.0.1-1
ii  libixml111:1.14.18-1
ii  libjpeg62-turbo  1:2.1.5-2
ii  libkate1 0.4.1-11
ii  liblirc-client0  0.10.1-7.2
ii  liblua5.2-0  5.2.4-3
ii  libmad0  0.15.1b-10.1+b1
ii  libmatroska7 1.7.1-1
ii  libmpcdec6   2:0.1~r495-2
ii  libmpeg2-4   0.5.1-9
ii  libmpg123-0  1.32.3-1
ii  libmtp9  1.1.21-1
ii  libncursesw6 6.4+20231016-1
ii  libnfs14 

Bug#1055681: new upstream python is needed for Python 3.12

[Graham Inggs]

Hi Matthias

Are you sure that cython 3.0.x is required for Python 3.12?

The changelog from cython 0.29.36-1 has:

  * New upstream release.
- Includes Python 3.12 support (Closes: #1004725)

and upstream's changelog [1] mentions Python 3.12 a couple of times.

Please also see my message [2] in #1028157.

Regards
Graham


[1] https://github.com/cython/cython/blob/0.29.x/CHANGES.rst
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028157#67

Bug#1055951: RFS: multispeech/4.6.0-1 [ITP] -- Multilingual speech server for Emacspeak

[Igor B. Poretsky]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : multispeech
   Version  : 4.6.0-1
   Upstream contact : Igor B. Poretsky 
 * URL  : https://github.com/poretsky/multispeech
 * License  : GPL-2.0
 * Vcs  : https://github.com/poretsky/multispeech
   Section  : sound

The source builds the following binary packages:

  multispeech - Multilingual speech server for Emacspeak
  sd-multispeech - Multilingual Speech Dispatcher backend
  libmultispeech5 - Multilingual speech server

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/m/multispeech/multispeech_4.6.0-1.dsc

Changes for the initial release:

 multispeech (4.6.0-1) unstable; urgency=medium
 .
   * Debian package has been separated from the upstream sources.
   * Switch to dpkg-source 3.0 format.
   * Debian package release. (Closes: #1055902)

Regards,
-- 
  Igor

Bug#1055949: RFS: ru-tts/6.2.0-1 [ITP] -- software Russian TTS engine

[Igor B. Poretsky]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "ru-tts":

 * Package name : ru-tts
   Version  : 6.2.0-1
   Upstream contact : Igor B. Poretsky 
 * URL  : https://github.com/poretsky/ru_tts
 * License  : MIT
 * Vcs  : https://github.com/poretsky/ru_tts
   Section  : sound

The source builds the following binary packages:

  ru-tts - software Russian TTS engine
  librutts7 - software Russian TTS engine
  librutts-dev - software Russian TTS engine

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

  https://mentors.debian.net/package/ru-tts/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/r/ru-tts/ru-tts_6.2.0-1.dsc

Changes for the initial release:

 ru-tts (6.2.0-1) unstable; urgency=medium
 .
   * Upstream sources have been separated from the debian package.
   * Dropped rulex package dependency.
   * Updated ru_speak script.
   * Don't treat koi8 locale absence as a critical error.
   * Don't touch unknown words sink when dictionary is not in use by
 whatever reason.
   * Packaged for Debian. (Closes: #1055879)

Regards,
-- 
  Igor

Bug#1055950: rocm-device-libs: ROCm packages are very old

[BogDan Vatra]

Package: rocm-device-libs
Severity: wishlist
X-Debbugs-Cc: bog...@kde.org

Dear Maintainer,

ROCm debian packages are very old, any cance to upgrade it to 5.7.1?

Yours,
BogDan.


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

Kernel: Linux 6.5.0-4-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=ro_RO.UTF-8, LC_CTYPE=ro_RO.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#1028157: cython: please upgrade to 3.0.0 alpha

[Graham Inggs]

Hi

FWIW, I recently did a test rebuild of packages in Ubuntu Mantic [1]
(so packages are ~2.5 months behind unstable) against Cython 3.0.5.

Of the 279 source packages I identified as having a build-dependency
on src:cython, 163 built successfully, 115 FTBFS and one (qutip) FTBFS
on amd64 only and succeeded everywhere else.

The package lists are too long to attach to a bug report, but I could
attach them to an email to the debian-python mailing list, or so.

I'd say this means we cannot easily switch to cython 3.0 right now.
One option is to introduce a cython3.0 (or something better) package
and maintainers can switch the build-dependency as needed.  Cython3.0
might be confusing as the binary package from src:cython is already
named cython3.

Regards
Graham


[1] https://launchpad.net/~ginggs/+archive/ubuntu/cython-3.0

Bug#1028130: Possible encoding issue (Was: r-cran-hunspell: please don't use internal en_US and en_GB dictionaries)

[Andreas Tille]

Hi,

I finally wanted to give this bug another chance to be solved and pushed
the patches to git.  Unfortunately the problem of two failed tests
persists[1].  Before asking upstream about this (which is always a bit
complicated if we use different files then them - the Debian packaged
dictionaries) I wonder whether someone might have some clue.

May be an easiy way to test it is to build+install the package in Git
and run the script debian/tests/run-unit-test[2].

Kind regards
Andreas.


[1] https://salsa.debian.org/r-pkg-team/r-cran-hunspell/-/jobs/4924880#L467
[2] 
https://salsa.debian.org/r-pkg-team/r-cran-hunspell/-/blob/master/debian/tests/run-unit-test

-- 
http://fam-tille.de

Bug#1055948: RFS: rulex/3.8.0-1 [ITP] -- Russian pronunciation dictionary support binaries

[Igor B. Poretsky]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : rulex
   Version  : 3.8.0-1
   Upstream contact : Igor B. Poretsky 
 * URL  : https://github.com/poretsky/rulex
 * License  : LGPL-2.1
 * Vcs  : https://github.com/poretsky/rulex
   Section  : sound

The source builds the following binary packages:

  rulex - Russian pronunciation dictionary support binaries
  rulex-data - Russian pronunciation dictionary
  librulexdb0 - Russian pronunciation dictionary access library
  librulexdb-dev - Russian pronunciation dictionary access library

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/r/rulex/rulex_3.8.0-1.dsc

Changes for the initial release:

 rulex (3.8.0-1) unstable; urgency=medium
 .
   * Packaged for Debian. (Closes: #1055898)

Regards,
-- 
  Igor

Bug#1055871: umap-learn: requires tbb, which is not installed ?

[Jörg-Volker Peetz]

Andreas Tille wrote on 14/11/2023 17:02:

Am Tue, Nov 14, 2023 at 04:40:57PM +0100 schrieb Jörg-Volker Peetz:


Yes, this is due to the line

tbb>=2019.0

in the file 
/usr/lib/python3/dist-packages/umap_learn-0.5.4.egg-info/requires.txt .
It's only required on x86* systems.


Surely this is what the line says.  I might miss something but don't you
think at some other place the string tbb should occure if it is needed
at all?  For me it looks like some leftover from previous versions
(which we could probably clarify with upstream).  I just notice that the
package builds, passes its autopkgtest and might be run on your side (or
do you have any issues when using it).  The only thing you report is that
pip thinks tbb should be installed.


Indeed, I just now tried on of my jupyter notebooks which uses umap-learn. That
works fine.
That supports your reckoning that it's some leftover.
--
Regards,
Jörg.


Kind regards
 Andreas.

Bug#1055947: RFS: freespeech/1.0m-21 [ITP] -- English pronunciation dictionary

[Igor B. Poretsky]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : freespeech
   Version  : 1.0m-21
   Upstream contact : Igor B. Poretsky 
 * URL  : https://github.com/poretsky/freespeech
 * License  : GPL
 * Vcs  : https://github.com/poretsky/freespeech
   Section  : sound

The source builds the following binary packages:

  freephone - English Text-To-Phoneme converter
  enlex-data - English pronunciation dictionary

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/f/freespeech/freespeech_1.0m-21.dsc

Changes for the initial release:

 freespeech (1.0m-21) unstable; urgency=medium
 .
   * Debian package update. (Closes: #1055900)

Regards,
-- 
  Igor

Bug#1055871: umap-learn: requires tbb, which is not installed ?

[Andreas Tille]

Am Tue, Nov 14, 2023 at 04:40:57PM +0100 schrieb Jörg-Volker Peetz:
> 
> Yes, this is due to the line
> 
> tbb>=2019.0
> 
> in the file 
> /usr/lib/python3/dist-packages/umap_learn-0.5.4.egg-info/requires.txt .
> It's only required on x86* systems.

Surely this is what the line says.  I might miss something but don't you
think at some other place the string tbb should occure if it is needed
at all?  For me it looks like some leftover from previous versions
(which we could probably clarify with upstream).  I just notice that the
package builds, passes its autopkgtest and might be run on your side (or
do you have any issues when using it).  The only thing you report is that
pip thinks tbb should be installed.

Kind regards
Andreas. 

-- 
http://fam-tille.de

Bug#1055946: python3-wordcloud: pathon3-wordcloud should not recommend texlive-fonts-extra, not depend on it

[Nicola Chiapolini]

Package: python3-wordcloud
Version: 1.9.2+dfsg-1
Severity: normal

Dear Maintainer,

I want to generate wordclouds on a small server and tried to install
wordcloud. Unfortunately this wants to pull in 1.5GB of fonts, due to
texlive-fonts-extra. 

So I used 
  aptitude download ...
and
  dpkg --install --force-all ...
instead.

After explicitly setting the font_path in my python file, the script works 
perfectly.
It's a pitty, such unclean steps are needed to avoid the unnecessary
bloat.

Thanks for the packaging the tool nevertheless.

best wishes
Nicola

Bug#1053467: network-manager-openconnect-gnome: No option to specify UserAgent header in GUI

[Salvatore Bonaccorso]

Hi Luca,

On Tue, Nov 14, 2023 at 02:39:10PM +, Luca Boccassi wrote:
> On Tue, 14 Nov 2023 at 14:01, Salvatore Bonaccorso  wrote:
> >
> > Hi Luca,
> >
> > On Tue, Nov 14, 2023 at 01:25:41PM +, Luca Boccassi wrote:
> > > On Tue, 14 Nov 2023 14:00:54 +0100 Salvatore Bonaccorso
> > >  wrote:
> > > > Hi
> > > >
> > > > I parepared a backport of a series of three commits for it, for
> > > > bookworm and have lightly tested it. It seems to work and as such I
> > > > would like to propose an update for the upcoming point release.
> > > >
> > > > Luca, is this fine with you? Can you peer-review the debdiff?
> > >
> > > Hi, sounds good to me, but please send a MR on Salsa (without
> > > d/changelog changes, I use gbp) - I've prepared a debian/bookworm
> > > branch for this. Then I can do a p-u upload.
> >
> > Thanks!
> >
> > Here is the MR accordingly with the debian/changelog entries dropped:
> >
> > https://salsa.debian.org/debian/network-manager-openconnect/-/merge_requests/6
> 
> Uploaded to p-u - would you mind filing the release team bug for it,
> please? That way you can add some details on how you tested it.
> Thanks!

Sure, will do. Thanks for the upload!

Regards,
Salvatore

Bug#1055871: umap-learn: requires tbb, which is not installed ?

[Jörg-Volker Peetz]

Hi Andreas,

Andreas Tille wrote on 14/11/2023 14:55:

Hi Jörg,

thanks a lot for your bug report.

Am Mon, Nov 13, 2023 at 11:20:53AM +0100 schrieb Jörg-Volker Peetz:

after upgrading umap-learn the command

python3 -m pip check

results in the message

   umap-learn 0.5.4 requires tbb, which is not installed.


That's an interesting finding.


Should this be addressed?


If its true I confirm it should be really be addressed.  However, I'm
not sure whether this is some outdated information.  In my clone of the
packaging Git repository I did


$ grep -Ri tbb
grep: .git/objects/pack/pack-57537d4033d776efa30645ea203ac00a96c5745b.pack: 
binary file matches
setup.py:] + (["tbb >= 2019.0"] if 
platform.machine().lower().startswith("x86") else []),
grep: images/densmap_example_mnist.png: binary file matches
grep: images/umap_example_fashion_mnist1.png: binary file matches


IMHO there should be some match for the string tbb somewhere else than
in setup,py which is probably checked by pip.

What do you think?


Yes, this is due to the line

tbb>=2019.0

in the file 
/usr/lib/python3/dist-packages/umap_learn-0.5.4.egg-info/requires.txt .
It's only required on x86* systems.

--
Regards,
Jörg.



Kind regards
   Andreas.

Bug#1055945: linux-image-6.1.0-13-amd64: touchpad buttons sometimes stop working for several seconds/minutes

[Vincent Lefevre]

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

The touchpad buttons of my new laptop sometimes stop working for
several seconds or minutes (typically from 25" to 6'20"). The time
between two consecutive issues also varies and can be very short,
such as 30 seconds.

The device in question is: VEN_04F3:00 04F3:311C

This is visible even with evtest: when I click on any of the soft
buttons, I normally get an event like

Event: time 1698773368.142943, type 1 (EV_KEY), code 272 (BTN_LEFT), value 0

(note: always BTN_LEFT, even though this can be button 1, 2 or 3 at
a higher level). But when the problem occurs, I do not get such an
event.

Moving the mouse pointer is always possible, i.e. the issue concerns
only the buttons.

The only suspicious messages in the logs I could see are in the
X server logs

(EE) event14 - VEN_04F3:00 04F3:311C Touchpad: kernel bug: Touch jump detected 
and discarded.
See 
https://wayland.freedesktop.org/libinput/doc/1.22.1/touchpad-jumping-cursors.html
 for details

(nothing suspicious in the journalctl output). Note that libinput
stops emitting such messages after some number, so that it is not
possible to know whether this "Touch jump detected and discarded"
issue occurs at the same time as the button issue.

Additional info:

$ xinput list-props 13
Device 'VEN_04F3:00 04F3:311C Touchpad':
Device Enabled (190):   1
Coordinate Transformation Matrix (192): 1.00, 0.00, 0.00, 
0.00, 1.00, 0.00, 0.00, 0.00, 1.00
libinput Tapping Enabled (353): 0
libinput Tapping Enabled Default (354): 0
libinput Tapping Drag Enabled (355):1
libinput Tapping Drag Enabled Default (356):1
libinput Tapping Drag Lock Enabled (357):   0
libinput Tapping Drag Lock Enabled Default (358):   0
libinput Tapping Button Mapping Enabled (359):  1, 0
libinput Tapping Button Mapping Default (360):  1, 0
libinput Natural Scrolling Enabled (332):   0
libinput Natural Scrolling Enabled Default (333):   0
libinput Disable While Typing Enabled (361):1
libinput Disable While Typing Enabled Default (362):1
libinput Scroll Methods Available (334):1, 1, 0
libinput Scroll Method Enabled (335):   1, 0, 0
libinput Scroll Method Enabled Default (336):   1, 0, 0
libinput Click Methods Available (363): 1, 1
libinput Click Method Enabled (364):1, 0
libinput Click Method Enabled Default (365):1, 0
libinput Middle Emulation Enabled (366):0
libinput Middle Emulation Enabled Default (367):0
libinput Accel Speed (341): 0.00
libinput Accel Speed Default (342): 0.00
libinput Accel Profiles Available (343):1, 1
libinput Accel Profile Enabled (344):   1, 0
libinput Accel Profile Enabled Default (345):   1, 0
libinput Left Handed Enabled (346): 0
libinput Left Handed Enabled Default (347): 0
libinput Send Events Modes Available (313): 1, 1
libinput Send Events Mode Enabled (314):0, 0
libinput Send Events Mode Enabled Default (315):0, 0
Device Node (316):  "/dev/input/event14"
Device Product ID (317):1267, 12572
libinput Drag Lock Buttons (348):   
libinput Horizontal Scroll Enabled (349):   1
libinput Scrolling Pixel Distance (350):15
libinput Scrolling Pixel Distance Default (351):15
libinput High Resolution Wheel Scroll Enabled (352):1

The X input drivers:

$ dpkg -l | grep xserver-xorg-input
ii  xserver-xorg-input-all  1:7.7+23
 amd64X.Org X server -- input driver metapackage
ii  xserver-xorg-input-libinput 1.2.1-1+b1  
 amd64X.Org X server -- libinput input driver
ii  xserver-xorg-input-wacom1.1.0-1 
 amd64X.Org X server -- Wacom input driver


-- Package-specific info:
** Version:
Linux version 6.1.0-13-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.55-1 (2023-09-29)

** Command line:
BOOT_IMAGE=/vmlinuz-6.1.0-13-amd64 root=/dev/mapper/qaa--vg-root ro quiet

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: Dell Inc.
product_name: Precision 5570
product_version: 
chassis_vendor: Dell Inc.
chassis_version: 
bios_vendor: Dell Inc.
bios_version: 1.18.0
board_vendor: Dell Inc.
board_name: 01Y4G1
board_version: A00

** Loaded modules:
netlink_diag
tls
ctr
ccm
snd_seq_dummy
snd_hrtimer
snd_seq
snd_seq_device
snd_hda_codec_hdmi
qrtr
bnep
binfmt_misc
nls_ascii
nls_cp437
vfat
fat
snd_sof_pci_intel_tgl

Bug#1055944: bookworm-pu: package vips/8.14.1-3+deb12u1

[GCS]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: bookworm
Severity: normal
Control: affects -1 + src:vips

Hi RMs,

[ Reason ]
A specially crafted SVG input can cause libvips versions 8.14.3 or
earlier to segfault when attempting to parse a malformed UTF-8
character. It is considered a security issue and has the
CVE-2023-40032 identifier.

[ Impact ]
It is an application crash and can't be used for more. Hence the
Security Team decided it doesn't get a DSA. But it would be nice to
get the package updated.

[ Tests ]
Upstream testsuite and Sid update doesn't report any regressions.

[ Risks ]
The proposed change has very little risk of side-effects.

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

Thanks for considering,
Laszlo/GCS
diff -Nru vips-8.14.1/debian/changelog vips-8.14.1/debian/changelog
--- vips-8.14.1/debian/changelog	2023-02-13 10:48:58.0 +0100
+++ vips-8.14.1/debian/changelog	2023-11-14 16:05:39.0 +0100
@@ -1,3 +1,10 @@
+vips (8.14.1-3+deb12u1) bookworm; urgency=medium
+
+  * Backport upstream security fix for CVE-2023-40032: svgload: fix
+null-pointer dereference.
+
+ -- Laszlo Boszormenyi (GCS)   Tue, 14 Nov 2023 16:05:39 +0100
+
 vips (8.14.1-3) unstable; urgency=medium
 
   * Double self-testing timeout on mips64el and mipsel architectures.
diff -Nru vips-8.14.1/debian/patches/CVE-2023-40032.patch vips-8.14.1/debian/patches/CVE-2023-40032.patch
--- vips-8.14.1/debian/patches/CVE-2023-40032.patch	1970-01-01 01:00:00.0 +0100
+++ vips-8.14.1/debian/patches/CVE-2023-40032.patch	2023-11-14 16:05:39.0 +0100
@@ -0,0 +1,71 @@
+From e091d65835966ef56d53a4105a7362cafdb1582b Mon Sep 17 00:00:00 2001
+From: Kleis Auke Wolthuizen 
+Date: Sun, 13 Aug 2023 15:48:54 +0200
+Subject: [PATCH] svgload: fix null-pointer dereference (#3604)
+
+`g_utf8_find_next_char()` might return NULL when called with a
+non-NULL second argument, indicating that the end of the string
+has been reached.
+---
+ ChangeLog |  4 
+ libvips/foreign/svgload.c | 18 +++---
+ 2 files changed, 19 insertions(+), 3 deletions(-)
+
+diff --git a/ChangeLog b/ChangeLog
+index e47ee86bb4..b7544219e5 100644
+--- a/ChangeLog
 b/ChangeLog
+@@ -1,3 +1,7 @@
++TBD 8.14.4
++
++- fix null-pointer dereference during svgload [kleisauke]
++
+ TBD 8.14.2
+ 
+ - dedupe FITS header write [ewelot]
+diff --git a/libvips/foreign/svgload.c b/libvips/foreign/svgload.c
+index 94072581d4..aefd412ed2 100644
+--- a/libvips/foreign/svgload.c
 b/libvips/foreign/svgload.c
+@@ -145,7 +145,7 @@ vips_foreign_load_svg_zfree( void *opaque, void *ptr )
+ /* Find a utf-8 substring within the first len_bytes (not characters). 
+  *
+  *   - case-insensitive
+- *   - needle must be zero-terminated, but hackstack need not be
++ *   - needle must be zero-terminated, but haystack need not be
+  *   - haystack can be null-terminated
+  *   - if haystack is shorter than len bytes, that'll end the search 
+  *   - if we hit invalid utf-8, we return NULL
+@@ -191,11 +191,14 @@ vips_utf8_strcasestr( const char *haystack_start, const char *needle_start,
+ b == (gunichar) -2 )
+ return( NULL );
+ 
+-/* End of haystack. There can't be a complete needle
+- * anywhere.
++/* Disallow codepoint U+ as it's a nul byte.
++ * This is redundant with GLib >= 2.63.0, see:
++ * https://gitlab.gnome.org/GNOME/glib/-/merge_requests/967
+  */
++#if !GLIB_CHECK_VERSION( 2, 63, 0 )
+ if( a == (gunichar) 0 )
+ return( NULL );
++#endif
+ 
+ /* Mismatch.
+  */
+@@ -205,6 +208,15 @@ vips_utf8_strcasestr( const char *haystack_start, const char *needle_start,
+ haystack_char = 
+ g_utf8_find_next_char( haystack_char, 
+ 	haystack_start + len_bytes );
++
++/* End of haystack. There can't be a complete needle
++ * anywhere.
++ */
++if( haystack_char == NULL )
++return( NULL );
++
++/* needle_char will never be NULL.
++ */
+ needle_char = 
+ g_utf8_find_next_char( needle_char, NULL );
+ }
diff -Nru vips-8.14.1/debian/patches/series vips-8.14.1/debian/patches/series
--- vips-8.14.1/debian/patches/series	2023-02-12 08:52:21.0 +0100
+++ vips-8.14.1/debian/patches/series	2023-11-14 16:05:39.0 +0100
@@ -1,2 +1,3 @@
 dedupe_fits_header.patch
 fix_target_pnm_write.patch

Bug#1055943: ITP: asahi-audio -- PipeWire DSP profiles for Apple Silicon machines

[Tobias Heider]

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

* Package name: asahi-audio
  Version : 0.5
  Upstream Authors: The Asahi Linux Contributors
  URL : https://github.com/AsahiLinux/asahi-audio
* License : MIT
  Description : PipeWire DSP profiles for Apple Silicon machines

PipeWire and WirePlumber DSP profiles and configurations to
drive the speaker arrays in Apple Silicon laptops and desktops.

I hope to maintain this package as part in the bananas-team.

See also:
https://wiki.debian.org/Teams/Bananas

- Tobias

Bug#1055882: libncurses6: waddnstr() reads n+1 bytes, ought to end at n bytes

[наб]

On Mon, Nov 13, 2023 at 08:13:02PM -0500, Thomas Dickey wrote:
> The null terminator should be checked only for the special case where
> the passed-in length is negative.
I agree in principle but the manual says
> The four functions with n as the last argument write at most n bytes, or
> until a terminating null is reached.  If n is -1, then the entire string
> will be added.
Which reads to me like it ought to behave like printf(%.*s),
terminating at the first specified condition ‒
a C string with a limit, not a range ‒
so if it's supposed to be a range then maybe something to the effect of
--- ncurses-6.4+20230625.orig/man/curs_addstr.3x
+++ ncurses-6.4+20230625/man/curs_addstr.3x
@@ -80,9 +80,8 @@ characters.
 Thereafter, the cursor is advanced as a side-effect of writing to the window.
 .PP
 The four functions with \fIn\fP as the last argument
-write at most \fIn\fP bytes,
-or until a terminating null is reached.
-If \fIn\fP is \-1, then the entire string will be added.
+write \fIn\fP bytes.
+If \fIn\fP is \-1, it is taken to be \fBstrlen\fP(\fIstr\fP) instead.
 .SH RETURN VALUE
 All functions return the integer \fBERR\fP upon failure and \fBOK\fP on 
success.
 .PP
or
--- ncurses-6.4+20230625.orig/man/curs_addstr.3x
+++ ncurses-6.4+20230625/man/curs_addstr.3x
@@ -80,9 +80,8 @@ characters.
 Thereafter, the cursor is advanced as a side-effect of writing to the window.
 .PP
 The four functions with \fIn\fP as the last argument
-write at most \fIn\fP bytes,
-or until a terminating null is reached.
-If \fIn\fP is \-1, then the entire string will be added.
+instead write \fIn\fP bytes,
+unless \fIn\fP is \-1.
 .SH RETURN VALUE
 All functions return the integer \fBERR\fP upon failure and \fBOK\fP on 
success.
 .PP
is appropriate.

> I overlooked this case when eliminating
> the strlen's.  Here's what I have in mind (using a flag to short-circuit
> past the test for null terminator):
> 
> diff -u -r1.58 lib_addstr.c
> --- lib_addstr.c  2022/06/11 20:12:04 1.58
> +++ lib_addstr.c  2023/11/14 01:09:13
Works for me against 6.4+20230625 for both the original and the repro,
and I don't really see a much prettier way of doing it, short of
  while ((n < 0) ? (*str != '\0') : (n-- > 0)) {

Also I just noticed the comma in mvwaddnstr is italic,
so here's a diff for that as well:
--- ncurses-6.4+20230625.orig/man/curs_addstr.3x
+++ ncurses-6.4+20230625/man/curs_addstr.3x
@@ -68,7 +68,7 @@
 .br
 \fBint mvwaddstr(WINDOW *\fIwin\fB, int \fIy\fB, int \fIx\fB, const char 
*\fIstr\fB);\fR
 .br
-\fBint mvwaddnstr(WINDOW *\fIwin\fB, int \fIy\fB, int \fIx\fB, const char 
*\fIstr, int \fIn\fB);\fR
+\fBint mvwaddnstr(WINDOW *\fIwin\fB, int \fIy\fB, int \fIx\fB, const char 
*\fIstr\fB, int \fIn\fB);\fR
 .fi
 .SH DESCRIPTION
 These functions write the (null-terminated) character string

Best,
наб


signature.asc
Description: PGP signature

Bug#1055938: zlib1g: move libz.so.* to /usr

[Mark Brown]

On Tue, Nov 14, 2023 at 03:33:00PM +0100, Helmut Grohne wrote:

> > debootstrap is already broken by the /usr merge, which is something of
> > an annoyance for anyone who uses pbuilder to actually build packages...

> I suspect you are using a bulleye or bookworm system with pbuilder to
> build for unstable. Please update your debootstrap package from the
> relevant -updates suite and it'll work again. The debootstrap update
> will be part of the next point release. I'm sorry for the inconvenience,
> but the ordering has been beyond my control.

I already managed to bodge it in the end, but trying to work around the
unannounced breakage did burn all the time I'd allocated to spend on
package updates last week.


signature.asc
Description: PGP signature

Bug#1053467: network-manager-openconnect-gnome: No option to specify UserAgent header in GUI

[Luca Boccassi]

On Tue, 14 Nov 2023 at 14:01, Salvatore Bonaccorso  wrote:
>
> Hi Luca,
>
> On Tue, Nov 14, 2023 at 01:25:41PM +, Luca Boccassi wrote:
> > On Tue, 14 Nov 2023 14:00:54 +0100 Salvatore Bonaccorso
> >  wrote:
> > > Hi
> > >
> > > I parepared a backport of a series of three commits for it, for
> > > bookworm and have lightly tested it. It seems to work and as such I
> > > would like to propose an update for the upcoming point release.
> > >
> > > Luca, is this fine with you? Can you peer-review the debdiff?
> >
> > Hi, sounds good to me, but please send a MR on Salsa (without
> > d/changelog changes, I use gbp) - I've prepared a debian/bookworm
> > branch for this. Then I can do a p-u upload.
>
> Thanks!
>
> Here is the MR accordingly with the debian/changelog entries dropped:
>
> https://salsa.debian.org/debian/network-manager-openconnect/-/merge_requests/6

Uploaded to p-u - would you mind filing the release team bug for it,
please? That way you can add some details on how you tested it.
Thanks!

Bug#1039142: busybox: ships sysv-init script without systemd unit

[Michael Tokarev]

14.11.2023 14:56, Luca Boccassi wrote:

On Mon, 13 Nov 2023 18:42:09 +0300 Michael Tokarev 
wrote:

..


With just dh_installsystemd --no-enable, it is still started.
With dh_installsystemd --no-enable --no-start, it is started
as well, - apparently because initscript is started.  Also,
with --no-enable --no-start, it is not restarted on upgrades
if enabled locally.

After doing several iterations, I decided to abandon this attempt, -
it just does not work, and I've no time to fight with the tools.

If someone has a working recipe for all this madness, please
share a patch for d/rules.

Tagging with "help" for now.


Could you please share a branch or a patch with your attempt? What you
tried should work, but it's hard to say without looking at the
implementation in details.


Sure thing, it is in current busybox master on salsa, here:

https://salsa.debian.org/installer-team/busybox/-/blob/master/debian/rules#L172

with udhcpd.service & udhcpd.init in the same dir.

Thanks,

/mjt

Bug#1055938: zlib1g: move libz.so.* to /usr

[Helmut Grohne]

Hi Mark,

On Tue, Nov 14, 2023 at 02:23:47PM +, Mark Brown wrote:
> On Tue, Nov 14, 2023 at 11:45:35AM +0100, Helmut Grohne wrote:
> 
> > fortunately. We do not break the debian-installer (P10), because even
> > unmerged chroots have /usr/lib/ on their library search
> > paths. I locally verified that we do not break debootstrap (P8) and
> > since the affected filename is architecture-dependent, the multi-arch
> > file loss scenario (P7) also does not apply.
> 
> debootstrap is already broken by the /usr merge, which is something of
> an annoyance for anyone who uses pbuilder to actually build packages...

I suspect you are using a bulleye or bookworm system with pbuilder to
build for unstable. Please update your debootstrap package from the
relevant -updates suite and it'll work again. The debootstrap update
will be part of the next point release. I'm sorry for the inconvenience,
but the ordering has been beyond my control.

Now this change has a lower risk of adding to the breakage. We need to
remove files from aliased locations in essential packages rather soon. A
future base-files update will move the /lib -> usr/lib symlink into
base-files' data.tar and if liblzma5 hasn't moved by then it may break
this link. Thanks for your cooperation.

Helmut

Bug#1055938: zlib1g: move libz.so.* to /usr

[Mark Brown]

On Tue, Nov 14, 2023 at 11:45:35AM +0100, Helmut Grohne wrote:

> fortunately. We do not break the debian-installer (P10), because even
> unmerged chroots have /usr/lib/ on their library search
> paths. I locally verified that we do not break debootstrap (P8) and
> since the affected filename is architecture-dependent, the multi-arch
> file loss scenario (P7) also does not apply.

debootstrap is already broken by the /usr merge, which is something of
an annoyance for anyone who uses pbuilder to actually build packages...


signature.asc
Description: PGP signature

Bug#947323: libcap-ng: Please install libs back into /usr/lib/ when usrmerge arrives

[Helmut Grohne]

Control: user helm...@debian.org
Control: usertags -1 + dep17m2
Control: tags -1 + patch

On Tue, Dec 24, 2019 at 11:52:56AM -0500, Boyuan Yang wrote:
> With the progress of usrmerge, it should be reasonable to move libcap-ng so
> files back to /usr/lib/ when usrmerge becomes the default of Debian
> installation. (See https://bugs.debian.org/829126 and 
> https://bugs.debian.org/828992 for the original reason of moving the library
> into /lib).

The file move moratorium has now been delegated to
https://wiki.debian.org/UsrMerge. We now can move, but need to be
careful. https://subdivi.de/~helmut/dep17.html lists a few problem
classes to watch out for.

If we were to rename libcap-ng0 to libcap-ng0t64 as part of
https://wiki.debian.org/ReleaseGoals/64bit-time, that would cause a file
loss scenario (DEP17 P1), but it is listed as not-affected. Most other
problems do not apply. Multiarch shared file loss (P7) does not apply,
because the libraries are installed to architecture-dependent paths. I
locally verified that the change does not impact filesystem bootstrap.
Since no udebs are built, the debian-installer is not affected (P10).

Hence, we are good to go. I do not expect libcap-ng to be uploaded to
bookworm-backports and therefore changed the paths directly in the
attached patch. This patch should not be uploaded to bookworm-backports.
If that's relevant to you, consider using dh_movetousr instead. Also
keep in mind that restructuring changes (such as libcap-ng0t64) should
be uploaded to experimental first to let dumat analyze your change for
possible problems.

Helmut
diff --minimal -Nru libcap-ng-0.8.3/debian/changelog 
libcap-ng-0.8.3/debian/changelog
--- libcap-ng-0.8.3/debian/changelog2022-06-23 07:22:33.0 +0200
+++ libcap-ng-0.8.3/debian/changelog2023-11-14 12:42:31.0 +0100
@@ -1,3 +1,10 @@
+libcap-ng (0.8.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move libraries to /usr. Closes: #-1
+
+ -- Helmut Grohne   Tue, 14 Nov 2023 12:42:31 +0100
+
 libcap-ng (0.8.3-1) unstable; urgency=medium
 
   * New upstream release. Closes: #1004519
diff --minimal -Nru libcap-ng-0.8.3/debian/libcap-ng0.install 
libcap-ng-0.8.3/debian/libcap-ng0.install
--- libcap-ng-0.8.3/debian/libcap-ng0.install   2022-06-23 07:22:33.0 
+0200
+++ libcap-ng-0.8.3/debian/libcap-ng0.install   2023-11-14 12:42:23.0 
+0100
@@ -1 +1 @@
-lib/*/lib*.so.*
+usr/lib/*/lib*.so.*
diff --minimal -Nru libcap-ng-0.8.3/debian/rules libcap-ng-0.8.3/debian/rules
--- libcap-ng-0.8.3/debian/rules2022-06-23 07:22:33.0 +0200
+++ libcap-ng-0.8.3/debian/rules2023-11-14 12:42:13.0 +0100
@@ -34,12 +34,6 @@
done
 
find $(CURDIR)/debian/tmp -name *.la -delete
-   mkdir -p $(CURDIR)/debian/tmp/lib/$(DEB_HOST_MULTIARCH) && \
-   mv $(CURDIR)/debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/lib*.so.0* 
$(CURDIR)/debian/tmp/lib/$(DEB_HOST_MULTIARCH)/; \
-   rm debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libcap-ng.so; \
-   ln -s ../../../lib/$(DEB_HOST_MULTIARCH)/libcap-ng.so.0.0.0 
debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libcap-ng.so; \
-   rm debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libdrop_ambient.so; \
-   ln -s ../../../lib/$(DEB_HOST_MULTIARCH)/libdrop_ambient.so.0.0.0 
debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libdrop_ambient.so; \
 
 override_dh_auto_test:
for V in $(PY3VERS); do \

Bug#1055931: apt ignores bullseye-backports

[Vincent Lefevre]

Cc'ing Reportbug Maintainers.

On 2023-11-14 14:51:18 +0100, Vincent Lefevre wrote:
> Going back to what reportbug says, it still outputs
> 
> [...]
> Getting status for linux-image-6.1.0-13-amd64...
> Verifying package integrity...
> Checking for newer versions at madison and 
> https://ftp-master.debian.org/new.html
> 
> Your version (6.1.55-1) of linux-image-6.1.0-13-amd64 appears to be out of 
> date.
> The following newer release(s) are available in the Debian archive:
>   bullseye-backports (backports-policy): 6.1.55+1~bpo11+1
> Please try to verify if the bug you are about to report is already addressed 
> by these releases.  Do you still want to file a report [y|N|q|?]? 
> 
> So I've looked at https://ftp-master.debian.org/new.html with Firefox
> and "linux-image" doesn't appear anywhere. So the information comes
> from madison.
> 
> $ apt-cache madison linux-image-6.1.0-13-amd64
> linux-image-6.1.0-13-amd64 |   6.1.55-1 | https://ftp.debian.org/debian 
> stable/main amd64 Packages
> linux-signed-amd64 |   6.1.55+1 | https://ftp.debian.org/debian stable/main 
> Sources
> 
> No mentions of 6.1.55+1~bpo11+1, so this is more and more confusing.

After removing bullseye-backports from my sources lists and doing
"apt update", I've tried

  strace -o str.out -f -s 99 reportbug linux-image-6.1.0-13-amd64

but in the strace output, the string "bpo11" appears in 2 places only:

[...] manpages-de (<< 4.17.0-2~bpo11+1), manpages-fr (<< 4.17.0-2~bpo11+1) [...]

(thus unrelated to this issue) and in the message

193537 write(1, "  bullseye-backports (backports-policy): 6.1.55+1~bpo11+1\n", 
58) = 58

So I'm wondering where this information comes from.

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

Bug#1055942: liblzma5: move liblzma.so.* to /usr

[Helmut Grohne]

Source: xz-utils
Version: 5.4.4-0.1
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to finalize the /usr-merge transition by moving aliased files
from / to /usr. Until recently, this was prohibited by the file move
moratorium. It has since been delegated to
https://wiki.debian.org/UsrMerge and we can actually move files albeit
carefully. https://subdivi.de/~helmut/dep17.html is a collection of
problems we may encounter when doing so and I checked the list. The
biggest issue probably is the 2038 transition
https://wiki.debian.org/ReleaseGoals/64bit-time as it threatens to
rename the library package to liblzma5t64, but fortunately liblzma-dev
is listed as not-affected. If that becomes real, we'll have to work
around it using protective diversions (M8) as we cannot employ conflicts
(M7) for essential packages. Most of the other problems are irrelevant.
In particular, multiarch (P7) is not an issue, because all affected
filenames are architecture-dependent. I locally verified that filesystem
bootstrap continues to work in the presence of this change.

So I think we can move forward with this. I'm assuming that you do not
intend to upload xz-utils to bookworm backports and therefore clean up
the file movement. Do not upload the attached patch to
bookworm-backports and use dh_movetousr instead if that's important to
you. Also remember to upload restructuring changes (such as liblzma5t64)
to experimental during the trixie cycle.

Helmut
diff --minimal -Nru xz-utils-5.4.4/debian/changelog 
xz-utils-5.4.4/debian/changelog
--- xz-utils-5.4.4/debian/changelog 2023-08-30 20:38:53.0 +0200
+++ xz-utils-5.4.4/debian/changelog 2023-11-14 15:04:46.0 +0100
@@ -1,3 +1,10 @@
+xz-utils (5.4.4-0.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move liblzma.so.* to /usr. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 14 Nov 2023 15:04:46 +0100
+
 xz-utils (5.4.4-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru xz-utils-5.4.4/debian/liblzma5.install 
xz-utils-5.4.4/debian/liblzma5.install
--- xz-utils-5.4.4/debian/liblzma5.install  2023-02-11 21:42:11.0 
+0100
+++ xz-utils-5.4.4/debian/liblzma5.install  2023-11-14 15:04:31.0 
+0100
@@ -1 +1 @@
-lib/*/liblzma.so.*
+usr/lib/*/liblzma.so.*
diff --minimal -Nru xz-utils-5.4.4/debian/rules xz-utils-5.4.4/debian/rules
--- xz-utils-5.4.4/debian/rules 2023-08-30 14:22:22.0 +0200
+++ xz-utils-5.4.4/debian/rules 2023-11-14 15:04:24.0 +0100
@@ -16,11 +16,6 @@
dh_auto_install --builddirectory debian/xzdec-build
dh_auto_install --builddirectory debian/normal-build
dh_auto_install --builddirectory debian/static-build
-   set -e; arch=$$(dpkg-architecture -qDEB_HOST_MULTIARCH); \
-   install -d debian/tmp/lib/$$arch; \
-   mv debian/tmp/usr/lib/$$arch/liblzma.so.* debian/tmp/lib/$$arch/; \
-   dso=$$(basename $$(readlink debian/tmp/usr/lib/$$arch/liblzma.so)); \
-   ln -s -f /lib/$$arch/$$dso debian/tmp/usr/lib/$$arch/liblzma.so
 
 override_dh_installchangelogs:
dh_installchangelogs ChangeLog

Bug#1055941: libcrypt1: move libcrypt.so.* to /usr

[Helmut Grohne]

Source: libxcrypt
Version: 1:4.4.36-2
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2
X-Debbugs-Cc: vor...@debian.org

The moratorium has been deferred to https://wiki.debian.org/UsrMerge and
we can now move files to finalize the /usr-merge transition. I
implemented the move and reviewed the problem classes from
https://subdivi.de/~helmut/dep17.html. Most of the problems do not apply
and I specifically tested that filesystem bootstrap (P8) continues to
work. The debian-installer will continue to work (P10), because
/usr/lib/ is on the default library search path even for
unmerged systems. The one thing to keep in mind here is that renaming
the library may trigger a file loss problem (P1). This is plausible to
due the 2038 transition, see
https://wiki.debian.org/ReleaseGoals/64bit-time. It does not list
libxcrypt as not-affected and if libxcrypt really is affected, it'll be
renamed to libcrypt1t64 which we'll have to mitigate using protective
diversions (M8) then (because we cannot use Conflicts for essential
packages).

So I think this is good to go. I assume that libxcrypt will not be
backported and therefore implemented the change directly. In case you
consider backporting to bookworm-backports, do not upload this patch and
consider using dh_movetousr instead. Also when the 2038 transition comes
around, remember to upload to experimental first.

Helmut
diff --minimal -Nru libxcrypt-4.4.36/debian/changelog 
libxcrypt-4.4.36/debian/changelog
--- libxcrypt-4.4.36/debian/changelog   2023-07-29 18:32:40.0 +0200
+++ libxcrypt-4.4.36/debian/changelog   2023-11-14 13:34:09.0 +0100
@@ -1,3 +1,10 @@
+libxcrypt (1:4.4.36-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move libcrypt.so.* to /usr. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 14 Nov 2023 13:34:09 +0100
+
 libxcrypt (1:4.4.36-2) unstable; urgency=medium
 
   * Stop marking libcrypt1 Important+Protected. This was needed to help
diff --minimal -Nru libxcrypt-4.4.36/debian/rules libxcrypt-4.4.36/debian/rules
--- libxcrypt-4.4.36/debian/rules   2023-07-25 04:33:35.0 +0200
+++ libxcrypt-4.4.36/debian/rules   2023-11-14 13:34:08.0 +0100
@@ -93,14 +93,6 @@
$(MAKE) install DESTDIR=$D
 
# Move the shared library back to /lib/ because this is where the
-   # libc6 package used to install it (see #953562 for details).
-   mkdir -p $D/lib/$(DEB_HOST_MULTIARCH)
-   mv $D/usr/lib/$(DEB_HOST_MULTIARCH)/libcrypt.so.1* 
$D/lib/$(DEB_HOST_MULTIARCH)/
-ifeq ($(DEB_HOST_ARCH), alpha)
-   ln -sf /lib/$(DEB_HOST_MULTIARCH)/libcrypt.so.1.1 
$D/usr/lib/$(DEB_HOST_MULTIARCH)/libcrypt.so
-else
-   ln -sf /lib/$(DEB_HOST_MULTIARCH)/libcrypt.so.1 
$D/usr/lib/$(DEB_HOST_MULTIARCH)/libcrypt.so
-endif
 ifeq ($(BUILD_DEV_VER), 1)
dh_movefiles -plibcrypt-dev --sourcedir=debian/libcrypt1/
 else

Bug#1055940: ncurses: move libraries from aliased library directories to /usr

[Helmut Grohne]

Source: ncurses
Version: 6.4+20231016-1
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2
X-Debbugs-Cc: vor...@debian.org

We want to finalize the /usr-merge transition via DEP17. For ncurses,
this means moving libraries to /usr. Until recently, doing so was
prohibited by the file move moratorium. This has now been delegated to
https://wiki.debian.org/UsrMerge. We still must be careful about such
moves e.g. in essential packages.

https://subdivi.de/~helmut/dep17.html gives us a template of what might
go wrong. Most importantly, ncurses is not listed as not-affected by the
2038 transition https://wiki.debian.org/ReleaseGoals/64bit-time.
Therefore, it may become necessary to rename some of the library
packages adding a "t64" suffix to the package name. In a bookworm to
trixie upgrade, this constitutes a file move between packages and
concurrent move from / to /usr leading to the precise file loss that the
moratorium was meant to prevent (DEP17 P1). This needs to be mitigated
and since we're dealing with essential packages, we cannot employ
Conflicts (DEP17 M7). Instead, we'll have to use protective diversions
(DEP17 M8) installed in preinst and removed in postinst. Since 2038
hasn't happened yet, we can defer this, but do upload that time64 change
to experimental first and let it wait there for at least three days.

Other problems are less of an issue. The change does not affect the
debian-installer (P10), because the libraries are already moved there.
It also does not cause the multiarch file loss (P7), because all
affected filenames are architecture-dependent. I verified that it does
not break filesystem bootstrap locally (P8).

So given this I think we're good to go. I don't expect ncurses to be
backported to bookworm-backports. Therefore, the attached patch just
moves all the files. Do not upload this patch to bookworm-backports. If
you plan to do that, consider using dh_movetousr instead. Also keep that
2038 matter in mind.

Helmut
diff --minimal -Nru ncurses-6.4+20231016/debian/changelog 
ncurses-6.4+20231016/debian/changelog
--- ncurses-6.4+20231016/debian/changelog   2023-10-17 17:34:56.0 
+0200
+++ ncurses-6.4+20231016/debian/changelog   2023-11-14 12:00:46.0 
+0100
@@ -1,3 +1,10 @@
+ncurses (6.4+20231016-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move all libraries to /usr. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 14 Nov 2023 12:00:46 +0100
+
 ncurses (6.4+20231016-1) unstable; urgency=medium
 
   * New upstream patchlevel.
diff --minimal -Nru ncurses-6.4+20231016/debian/lib32ncurses-dev.links 
ncurses-6.4+20231016/debian/lib32ncurses-dev.links
--- ncurses-6.4+20231016/debian/lib32ncurses-dev.links  2023-10-17 
08:31:07.0 +0200
+++ ncurses-6.4+20231016/debian/lib32ncurses-dev.links  2023-11-14 
12:00:46.0 +0100
@@ -1,4 +1,4 @@
-lib32/libtinfo.so.6 usr/lib32/libtinfo.so
+usr/lib32/libtinfo.so.6 usr/lib32/libtinfo.so
 usr/lib32/libncurses.so usr/lib32/libcurses.so
 usr/lib32/libncurses.a  usr/lib32/libcurses.a
 usr/lib32/libtinfo.ausr/lib32/libtermcap.a
diff --minimal -Nru ncurses-6.4+20231016/debian/lib32ncurses6.install 
ncurses-6.4+20231016/debian/lib32ncurses6.install
--- ncurses-6.4+20231016/debian/lib32ncurses6.install   2023-10-17 
08:31:07.0 +0200
+++ ncurses-6.4+20231016/debian/lib32ncurses6.install   2023-11-14 
11:59:24.0 +0100
@@ -1,4 +1,4 @@
-obj-32/lib/libncurses.so.* lib32
+obj-32/lib/libncurses.so.* usr/lib32
 obj-32/lib/libpanel.so.* usr/lib32
 obj-32/lib/libform.so.* usr/lib32
 obj-32/lib/libmenu.so.* usr/lib32
diff --minimal -Nru ncurses-6.4+20231016/debian/lib32ncursesw6.install 
ncurses-6.4+20231016/debian/lib32ncursesw6.install
--- ncurses-6.4+20231016/debian/lib32ncursesw6.install  2023-10-17 
08:31:07.0 +0200
+++ ncurses-6.4+20231016/debian/lib32ncursesw6.install  2023-11-14 
11:59:29.0 +0100
@@ -1,4 +1,4 @@
-obj-wide-32/lib/libncursesw.so.* lib32
+obj-wide-32/lib/libncursesw.so.* usr/lib32
 obj-wide-32/lib/libpanelw.so.* usr/lib32
 obj-wide-32/lib/libformw.so.* usr/lib32
 obj-wide-32/lib/libmenuw.so.* usr/lib32
diff --minimal -Nru ncurses-6.4+20231016/debian/lib32tinfo6.install 
ncurses-6.4+20231016/debian/lib32tinfo6.install
--- ncurses-6.4+20231016/debian/lib32tinfo6.install 2023-10-17 
08:31:07.0 +0200
+++ ncurses-6.4+20231016/debian/lib32tinfo6.install 2023-11-14 
11:59:33.0 +0100
@@ -1,2 +1,2 @@
-obj-wide-32/lib/libtinfo.so.* lib32
+obj-wide-32/lib/libtinfo.so.* usr/lib32
 obj-wide-32/lib/libtic.so.* usr/lib32
diff --minimal -Nru ncurses-6.4+20231016/debian/lib64ncurses-dev.links 
ncurses-6.4+20231016/debian/lib64ncurses-dev.links
--- ncurses-6.4+20231016/debian/lib64ncurses-dev.links  2023-10-17 
08:31:07.0 +0200
+++ ncurses-6.4+20231016/debian/lib64ncurses-dev.links  2023-11-14 
12:00:46.0 +0100
@@ -1,4 +1,4 @@
-lib64/libtinfo.so.6 usr/lib64/libtinfo.so
+usr/lib64/libtinfo.so.6 

Bug#1055939: libgpg-error: move libgpg-error.so.* to /usr

[Helmut Grohne]

Source: libgpg-error
Version: 1.47-2
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to finalize the /usr-merge transition by moving files from / to
/usr. Until recently, this was prohibited by the file move moratorium.
It has now been delegated to https://wiki.debian.org/UsrMerge and we
actually can move albeit carefully.
https://subdivi.de/~helmut/dep17.html is a template of possible problems
to check for and that's what I did.

A very relevant scenario is the 2038 transition
https://wiki.debian.org/ReleaseGoals/64bit-time which renames libraries
with a t64 suffix. Fortunately, libgpg-errror is listed as not-affected.
Such renaming would cause the file loss scenario that the moratorium was
meant to prevent (DEP17 P1). If this happens, please upload to
experimental and wait at least three days. Multiarch (P7) is not an
issue, because the library is installed to an architecture-dependent
path. I locally verified that filesystem bootstrap (P8) continues wotk.
The debian-installer copes with libraries installed to
/usr/lib/ (P10).

So I think, we're good to move ahead. I don't think it makes sense to
backport libgpg-error. If you consider doing that, don't use this patch
and use dh_movetousr instead. And remember to upload restructuring
changes during the trixie cycle to experimental first.

Helmut
diff --minimal -Nru libgpg-error-1.47/debian/changelog 
libgpg-error-1.47/debian/changelog
--- libgpg-error-1.47/debian/changelog  2023-08-15 11:02:07.0 +0200
+++ libgpg-error-1.47/debian/changelog  2023-11-14 13:57:18.0 +0100
@@ -1,3 +1,10 @@
+libgpg-error (1.47-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move libgpg-error.so.* to /usr. Closes: #-1
+
+ -- Helmut Grohne   Tue, 14 Nov 2023 13:57:18 +0100
+
 libgpg-error (1.47-2) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru libgpg-error-1.47/debian/libgpg-error0-udeb.install 
libgpg-error-1.47/debian/libgpg-error0-udeb.install
--- libgpg-error-1.47/debian/libgpg-error0-udeb.install 2023-07-30 
13:52:55.0 +0200
+++ libgpg-error-1.47/debian/libgpg-error0-udeb.install 2023-11-14 
13:56:57.0 +0100
@@ -1 +1 @@
-usr/lib/*/libgpg-error.so.* lib
+usr/lib/*/libgpg-error.so.*
diff --minimal -Nru libgpg-error-1.47/debian/libgpg-error0.install 
libgpg-error-1.47/debian/libgpg-error0.install
--- libgpg-error-1.47/debian/libgpg-error0.install  2023-07-30 
13:52:55.0 +0200
+++ libgpg-error-1.47/debian/libgpg-error0.install  2023-11-14 
13:57:10.0 +0100
@@ -1 +1 @@
-usr/lib/${DEB_HOST_MULTIARCH}/libgpg-error.so.* lib/${DEB_HOST_MULTIARCH}/
+usr/lib/${DEB_HOST_MULTIARCH}/libgpg-error.so.*
diff --minimal -Nru libgpg-error-1.47/debian/rules 
libgpg-error-1.47/debian/rules
--- libgpg-error-1.47/debian/rules  2023-08-06 10:38:02.0 +0200
+++ libgpg-error-1.47/debian/rules  2023-11-14 13:56:43.0 +0100
@@ -31,9 +31,6 @@
 override_dh_installdocs:
dh_installdocs -A README
 
-override_dh_link:
-   dh_link -plibgpg-error-dev lib/$(DEB_HOST_MULTIARCH)/libgpg-error.so.0 
usr/lib/$(DEB_HOST_MULTIARCH)/libgpg-error.so
-
 ### "arch-independent" Windows builds: ###
 
 WIN_FLAGS=LDFLAGS="-Xlinker --no-insert-timestamp" CFLAGS="-g -Os 
-fdebug-prefix-map=$(shell pwd)=." CPPFLAGS=

Bug#1055938: zlib1g: move libz.so.* to /usr

[Helmut Grohne]

Package: zlib1g
Version: 1:1.2.13.dfsg-3
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to finalize the /usr-merge transition via DEP17. For zlib, this
means moving libz.so.* from /lib/ to the corresponding
location below /usr. Until recently, this was prohibited by the file
move moratorium, but that has now been delegated to
https://wiki.debian.org/UsrMerge. We still must be careful and
https://subdivi.de/~helmut/dep17.html has a template of possible
problems to watch out.

Most of these problems do not apply here for various reasons. Notably
the original file loss scenario that resulted in the file move
moratorium (P1), would apply if zlib1g were part of the 2038 transition
and were to be renamed to zlib1gt64, but
https://wiki.debian.org/ReleaseGoals/64bit-time lists it as not-affected
fortunately. We do not break the debian-installer (P10), because even
unmerged chroots have /usr/lib/ on their library search
paths. I locally verified that we do not break debootstrap (P8) and
since the affected filename is architecture-dependent, the multi-arch
file loss scenario (P7) also does not apply.

Hence, I think we are good to move ahead. When uploading this, please
bear two things in mind: This change should not be uploaded to
bookworm-backports. If you end up renaming packages (such as 2038)
within the trixie cycle, do upload to experimental first and wait three
days. I'm attaching a patch.

Helmut
diff --minimal -Nru zlib-1.2.13.dfsg/debian/changelog 
zlib-1.2.13.dfsg/debian/changelog
--- zlib-1.2.13.dfsg/debian/changelog   2023-08-15 15:35:28.0 +0200
+++ zlib-1.2.13.dfsg/debian/changelog   2023-11-14 11:14:25.0 +0100
@@ -1,3 +1,10 @@
+zlib (1:1.2.13.dfsg-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move libz.so.* to /usr. (closes: #-1)
+
+ -- Helmut Grohne   Tue, 14 Nov 2023 11:14:25 +0100
+
 zlib (1:1.2.13.dfsg-3) unstable; urgency=low
 
   * Further fixes to the minizip integration, don't install the minizip
diff --minimal -Nru zlib-1.2.13.dfsg/debian/rules zlib-1.2.13.dfsg/debian/rules
--- zlib-1.2.13.dfsg/debian/rules   2023-08-15 01:27:48.0 +0200
+++ zlib-1.2.13.dfsg/debian/rules   2023-11-14 11:14:25.0 +0100
@@ -179,10 +179,6 @@
 
$(MAKE) -C contrib/minizip prefix=$(CURDIR)/debian/tmp/usr install
 
-   install -d debian/tmp/lib/$(DEB_HOST_MULTIARCH)
-   mv debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libz.so.* 
debian/tmp/lib/$(DEB_HOST_MULTIARCH)
-   ln -sf /lib/$(DEB_HOST_MULTIARCH)/$$(readlink 
debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libz.so) 
debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libz.so
-
 install64: install build64-stamp
$(MAKE) -C debian/64 prefix=$(CURDIR)/debian/tmp install
 
diff --minimal -Nru zlib-1.2.13.dfsg/debian/zlib1g-udeb.install 
zlib-1.2.13.dfsg/debian/zlib1g-udeb.install
--- zlib-1.2.13.dfsg/debian/zlib1g-udeb.install 2022-11-05 13:24:24.0 
+0100
+++ zlib-1.2.13.dfsg/debian/zlib1g-udeb.install 2023-11-14 11:14:25.0 
+0100
@@ -1 +1 @@
-lib/*/lib*.so.* usr/lib
+usr/lib/*/libz*.so.* usr/lib
diff --minimal -Nru zlib-1.2.13.dfsg/debian/zlib1g.install 
zlib-1.2.13.dfsg/debian/zlib1g.install
--- zlib-1.2.13.dfsg/debian/zlib1g.install  2022-11-05 13:24:24.0 
+0100
+++ zlib-1.2.13.dfsg/debian/zlib1g.install  2023-11-14 11:14:25.0 
+0100
@@ -1 +1 @@
-lib/*/lib*.so.*
+usr/lib/*/libz*.so.*

Bug#1055937: lcdproc: package is missing files and functionalities

[Frederic]

Package: lcdproc
Severity: important

Dear Maintainer,

Package is missing files and functionalities about USB

As a baseline, sources are here https://github.com/lcdproc/lcdproc/tree/master 

Problem #1
Locally merge PR #200 and #201 (especially #201 for USB interface)

Problem #2
The debian package is missing the /etc/LCDd.conf configuration file, obviously 
nothing can work without it.
File is in the root of git master.
While you're in it, change the "DriverPath=" line with the proper directory 
like /usr/lib/x86_64-linux-gnu/lcdproc/ for instance.

Problem #3
The package was not compiled with USB support, meaning except if you have an 
old PC with a parallel port and an adapter to do some bit banging, it's 
useless...
you need to install both libusb-1.0-0-dev and libusb-dev then:
./configure --enable-libusb --enable libusb-1-0 --enable-drivers=all

Problem #4
Mixed up the init.d between the server and the client... fix it:
cp scripts/init-LCDd.LSB /etc/init.d/LCDd
cp scripts/init-lcdproc.LSB /etc/init.d/lcdproc

Thanks.

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

Kernel: Linux 6.5.0-1mx-ahs-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages lcdproc depends on:
pn  cme   
ii  debconf [debconf-2.0] 1.5.82
ii  init-system-helpers   1.65.2
ii  libc6 2.36-9+deb12u3
pn  libconfig-model-lcdproc-perl  
ii  libncurses6   6.4-4
ii  libtinfo6 6.4-4
ii  libusb-1.0-0  2:1.0.26-1
ii  libx11-6  2:1.8.4-2+deb12u2
ii  sysvinit-utils [lsb-base] 3.06-4
ii  udev  1:252.6-1mx23+1

Versions of packages lcdproc recommends:
pn  lcdproc-extra-drivers  

lcdproc suggests no packages.

Bug#1053467: network-manager-openconnect-gnome: No option to specify UserAgent header in GUI

[Salvatore Bonaccorso]

Hi Luca,

On Tue, Nov 14, 2023 at 01:25:41PM +, Luca Boccassi wrote:
> On Tue, 14 Nov 2023 14:00:54 +0100 Salvatore Bonaccorso
>  wrote:
> > Hi
> > 
> > I parepared a backport of a series of three commits for it, for
> > bookworm and have lightly tested it. It seems to work and as such I
> > would like to propose an update for the upcoming point release.
> > 
> > Luca, is this fine with you? Can you peer-review the debdiff?
> 
> Hi, sounds good to me, but please send a MR on Salsa (without
> d/changelog changes, I use gbp) - I've prepared a debian/bookworm
> branch for this. Then I can do a p-u upload.

Thanks!

Here is the MR accordingly with the debian/changelog entries dropped:

https://salsa.debian.org/debian/network-manager-openconnect/-/merge_requests/6

Regards,
Salvatore

Bug#1055871: umap-learn: requires tbb, which is not installed ?

[Andreas Tille]

Hi Jörg,

thanks a lot for your bug report.

Am Mon, Nov 13, 2023 at 11:20:53AM +0100 schrieb Jörg-Volker Peetz:
> after upgrading umap-learn the command
> 
>python3 -m pip check
> 
> results in the message
> 
>   umap-learn 0.5.4 requires tbb, which is not installed.

That's an interesting finding.
 
> Should this be addressed?

If its true I confirm it should be really be addressed.  However, I'm
not sure whether this is some outdated information.  In my clone of the
packaging Git repository I did


$ grep -Ri tbb 
grep: .git/objects/pack/pack-57537d4033d776efa30645ea203ac00a96c5745b.pack: 
binary file matches
setup.py:] + (["tbb >= 2019.0"] if 
platform.machine().lower().startswith("x86") else []),
grep: images/densmap_example_mnist.png: binary file matches
grep: images/umap_example_fashion_mnist1.png: binary file matches


IMHO there should be some match for the string tbb somewhere else than
in setup,py which is probably checked by pip.

What do you think?

Kind regards
  Andreas.

-- 
http://fam-tille.de

Bug#1055931: apt ignores bullseye-backports

[Vincent Lefevre]

On 2023-11-14 13:45:21 +0100, Vincent Lefevre wrote:
> But "apt show -a linux-image-6.1.0-13-amd64" just gives the 6.1.55-1
> version (no 6.1.55+1~bpo11+1 version), and
> 
>   apt install -t bullseye-backports linux-image-6.1.0-13-amd64
> 
> also thinks that 6.1.55-1 is the version to be installed.

This may be specific to the kernel image. The following is rather
confusing:

$ apt install -s -t bullseye-backports 
linux-image-6.1.0-13-amd64/bullseye-backports
NOTE: This is only a simulation!
  apt needs root privileges for real execution.
  Keep also in mind that locking is deactivated,
  so don't depend on the relevance to the real current situation!
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package linux-image-6.1.0-13-amd64 is not available, but is referred to by 
another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
  linux-image-6.1.0-13-amd64-unsigned

E: Release 'bullseye-backports' for 'linux-image-6.1.0-13-amd64' was not found
$ apt install -s -t bullseye-backports 
linux-image-6.1.0-13-amd64-unsigned/bullseye-backports
NOTE: This is only a simulation!
  apt needs root privileges for real execution.
  Keep also in mind that locking is deactivated,
  so don't depend on the relevance to the real current situation!
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package linux-image-6.1.0-13-amd64-unsigned is not available, but is referred 
to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
  linux-image-6.1.0-13-amd64

E: Release 'bullseye-backports' for 'linux-image-6.1.0-13-amd64-unsigned' was 
not found

Going back to what reportbug says, it still outputs

[...]
Getting status for linux-image-6.1.0-13-amd64...
Verifying package integrity...
Checking for newer versions at madison and 
https://ftp-master.debian.org/new.html

Your version (6.1.55-1) of linux-image-6.1.0-13-amd64 appears to be out of date.
The following newer release(s) are available in the Debian archive:
  bullseye-backports (backports-policy): 6.1.55+1~bpo11+1
Please try to verify if the bug you are about to report is already addressed by 
these releases.  Do you still want to file a report [y|N|q|?]? 

So I've looked at https://ftp-master.debian.org/new.html with Firefox
and "linux-image" doesn't appear anywhere. So the information comes
from madison.

$ apt-cache madison linux-image-6.1.0-13-amd64
linux-image-6.1.0-13-amd64 |   6.1.55-1 | https://ftp.debian.org/debian 
stable/main amd64 Packages
linux-signed-amd64 |   6.1.55+1 | https://ftp.debian.org/debian stable/main 
Sources

No mentions of 6.1.55+1~bpo11+1, so this is more and more confusing.

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

Bug#1055212: librust-pyo3-dev: 0.17 version does not support sub-interpreters and leads to ImportError

[Max Carrara]

On Tue, 7 Nov 2023 15:50:10 +0100 Max Carrara  wrote:
> On Thu, 02 Nov 2023 13:31:16 +0300 Andrew Kornilov  
> wrote:
> > Package: librust-pyo3-dev
> > Version: 0.17.3-1
> > Severity: important
> > Tags: upstream
> > X-Debbugs-Cc: akorni...@gmail.com
> > 
> > Dear Maintainer,
> > 
> > 
> >* PyO3 0.17 introduced a serious regression/issue with related software
> > (ceph, mod_wsgi and so on). Here is the issue with all the links and 
> > detailed
> > description: https://github.com/PyO3/pyo3/issues/3451
> >* PyO3 0.20 seems to have this fixed according to the included PR
> > https://github.com/PyO3/pyo3/pull/3446
> 
> I'm currently in the process of backporting the PR. So far PyO3 compiles; 
> there
> are some tests that don't yet pass, however. Will hopefully be able to provide
> a patch series soon.
> 

The backport of the aforementioned PR didn't fix the issue regarding
sub-interpreters, unfortunately. Will have to wait until this is fixed
upstream in PyO3.

I do want to note though that this isn't a "regression" per se; this
check was introduced to PyO3 because PyO3 isn't sound under the presence
of multiple sub-interpreters. So, this check is basically a security measure.

Bug#1049459: RM: mime-support -- ROM; Transition over

[Charles Plessy]

Control: tag -1 - moreinfo

Dear Scott,

the transition is over; to the best of my knowledge, no package depends
exclusively on mime-support, and in all alternatives it comes second
after media-types.

Please remove mime-support.

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://fediscience.org/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1055926: rodbc: [L10N,DE] rodbc_1.3-21-1_R-de: german translation

[Christoph Brinkhaus]

Am Tue, Nov 14, 2023 at 07:04:23AM -0600 schrieb Dirk Eddelbuettel:
> 
> On 14 November 2023 at 12:30, Christoph Brinkhaus wrote:
> | Source: rodbc
> | Version: 1.3-21-1
> | Severity: wishlist
> | 
> | Dear Maintainer,
> | 
> | please find attached the po file with the german translation.
> | It is an update to the current po template.
> | Please consider to apply it to the package.
> 
> Should that not go to the upstream package, possibly via the R Translations
> project (where AFAIK German po files are handled by Detlef Steuer) ?
> 
> https://translation.r-project.org/

I will mail Detlef and add you cc.

Kind regards,
Christoph 


signature.asc
Description: PGP signature

Bug#1055922: rmatrix: ABI change in Matrix 1.6-2

[Dirk Eddelbuettel]

On 14 November 2023 at 12:26, Graham Inggs wrote:
| Hi Dirk
| 
| On Tue, 14 Nov 2023 at 12:01, Dirk Eddelbuettel  wrote:
| > Well that seems to be a) the wrong severity and b) the wrong package.
| 
| Both are correct.  We do not want rmatrix to migrate and break
| packages in testing.

Doesn't 'normal' do that? I always get the shivers when I see 'serious' as I
fear that my package is at the risk of removal (which we of course Matrix
can't be 'really' given its systemic status from its "recommended" status
within R and very widespread use).

| However, in this case, I only set the severity to match reality;
| rmatrix is already blocked from migrating due to the autopkgtest
| regressions.
| 
| > We need to address the packages needing a rebuild. Mine (r-cran-lme4,
| > r-cran-rcppeigen).  have been taken care of.
| 
| Agreed, and rmatrix may need some new Breaks to allow the affected
| packages to migrate together.

The issue is actually hugely problematic for CRAN and R Core, and there are
some discussions but no solutions. They do not have (formal) notions like
binary rebuild for parts where they distribute binaries, and no means of
reaching binary redistributors such as us. Oh well.  At least it doesn't
happen often.

Anyway. Now that you made it a bug I let you drive this.  Upstream just made
an unrelated bugfix Matrix 1.6-3 which I just sent to unstable.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1055931: apt ignores bullseye-backports

[Julian Andres Klode]

Control: reassign -1 src:linux

On Tue, Nov 14, 2023 at 01:45:21PM +0100, Vincent Lefevre wrote:
> Package: apt
> Version: 2.6.1
> Severity: important
> 
> When I want to report a bug against the Linux kernel, reportbug
> recommends to use bullseye-backports to get a more recent version
> (even though this is currently a bookworm based machine):
> 
> Your version (6.1.55-1) of linux-image-6.1.0-13-amd64 appears to be out of 
> date.
> The following newer release(s) are available in the Debian archive:
>   bullseye-backports (backports-policy): 6.1.55+1~bpo11+1
> Please try to verify if the bug you are about to report is already addressed 
> by these releases.  Do you still want to file a report [y|N|q|?]? 
> 
> So I've added
> 
> deb http://deb.debian.org/debian bullseye-backports main contrib non-free
> 
> as documented in .
> 
> I did an "apt update". In particular:
> 
> [...]
> Get:19 http://deb.debian.org/debian bullseye-backports/main Translation-en 
> [343 kB]
> Get:20 http://deb.debian.org/debian bullseye-backports/main amd64 Contents 
> (deb) [1367 kB]
> Get:21 http://deb.debian.org/debian bullseye-backports/main all Contents 
> (deb) [4773 kB]
> Get:22 http://deb.debian.org/debian bullseye-backports/contrib amd64 Packages 
> [5968 B]
> Get:23 http://deb.debian.org/debian bullseye-backports/contrib Translation-en 
> [6004 B]
> Get:24 http://deb.debian.org/debian bullseye-backports/contrib amd64 Contents 
> (deb) [17.1 kB]
> Get:25 http://deb.debian.org/debian bullseye-backports/contrib all Contents 
> (deb) [22.2 kB]
> Get:26 http://deb.debian.org/debian bullseye-backports/non-free amd64 
> Packages [13.9 kB]
> Get:27 http://deb.debian.org/debian bullseye-backports/non-free 
> Translation-en [27.6 kB]
> Get:28 http://deb.debian.org/debian bullseye-backports/non-free amd64 
> Contents (deb) [10.8 kB]
> Get:29 http://deb.debian.org/debian bullseye-backports/non-free all Contents 
> (deb) [58.5 kB]
> [...]
> 
> But "apt show -a linux-image-6.1.0-13-amd64" just gives the 6.1.55-1
> version (no 6.1.55+1~bpo11+1 version), and
> 
>   apt install -t bullseye-backports linux-image-6.1.0-13-amd64
> 
> also thinks that 6.1.55-1 is the version to be installed.

There is no apt bug here, the backports have linux-image-6.1.0-0.deb11.13 
ABI. I don't know where the hook comes from so I'm just reassigning it
to src:linux.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1027378: tags

[Santiago Vila]

tags 1027378 + bullseye
thanks

Hello. I see that back in February you reopened this bug
"for stable" (meaning bullseye at the time).

I'm adding this tag mainly for documentation purposes, but
I personally lost my hope to see bugs like this one fixed in bullseye,
as there are too many of them (25 last time I counted) and
also there are FTBFS in bookworm which are more interesting to fix.

So, speaking as the bug reporter, I would not mind if you close
this bug using the version in bookworm. We have version tracking and
the bug would still be visible for anybody looking at the BTS web page.

Thanks.

Bug#1054290: zlib: CVE-2023-45853

[James Addison]

Source: zlib
Followup-For: Bug #1054290

I now think that patching vendored minizip code in libxlsxwriter would not help
because it specifies the 'USE_SYSTEM_MINIZIP' define at build-time[1] in
combination with a build-time dependency[2] on 'libminizip-dev' to link to the
required library functions.

In other words: if-and-when a security update is available in libminizip-dev
then libxlsxwriter will benefit from that automatically, and the presence of
apparently-vulnerable code within src:libxlsxwriter is irrelevant.

[1] - https://sources.debian.org/src/libxlsxwriter/1.1.5-1/debian/rules/#L14

[2] - https://sources.debian.org/src/libxlsxwriter/1.1.5-1/debian/control/#L11

Bug#1055922: rmatrix: ABI change in Matrix 1.6-2

[Graham Inggs]

Hi Dirk

On Tue, 14 Nov 2023 at 12:01, Dirk Eddelbuettel  wrote:
> Well that seems to be a) the wrong severity and b) the wrong package.

Both are correct.  We do not want rmatrix to migrate and break
packages in testing.

However, in this case, I only set the severity to match reality;
rmatrix is already blocked from migrating due to the autopkgtest
regressions.

> We need to address the packages needing a rebuild. Mine (r-cran-lme4,
> r-cran-rcppeigen).  have been taken care of.

Agreed, and rmatrix may need some new Breaks to allow the affected
packages to migrate together.

Regards
Graham

Bug#1053467: network-manager-openconnect-gnome: No option to specify UserAgent header in GUI

[Luca Boccassi]

On Tue, 14 Nov 2023 14:00:54 +0100 Salvatore Bonaccorso
 wrote:
> Hi
> 
> I parepared a backport of a series of three commits for it, for
> bookworm and have lightly tested it. It seems to work and as such I
> would like to propose an update for the upcoming point release.
> 
> Luca, is this fine with you? Can you peer-review the debdiff?

Hi, sounds good to me, but please send a MR on Salsa (without
d/changelog changes, I use gbp) - I've prepared a debian/bookworm
branch for this. Then I can do a p-u upload.

-- 
Kind regards,
Luca Boccassi


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

Bug#516152: Patch to fix the documentation

[Dave Jones]

Attaching an updated patch based on the current state of unstable. Some 
bits of the prior patch already appeared in the documentation, other 
bits needed a little re-working, but the intent is the same: the 
behaviour of bash is unchanged, this just changes the documentation to 
match the behaviour.


Best regards,

Dave Jones.
diff --git a/debian/changelog b/debian/changelog
index cd2b7c6d..b645fec8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+bash (5.2.15-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * d/p/man-bashrc.diff: Correct the bash(1) man-page to note that --rcfile
+does not prevent the execution of the system-wide /etc/bash.bashrc file.
+Closes: #516152.
+
+ -- Dave Jones   Tue, 14 Nov 2023 11:31:40 +
+
 bash (5.2.15-2) unstable; urgency=medium
 
   * Remove one more pdf file without source. Closes: #1024598.
diff --git a/debian/patches/man-bashrc.diff b/debian/patches/man-bashrc.diff
index 300d3ebf..1602a98c 100644
--- a/debian/patches/man-bashrc.diff
+++ b/debian/patches/man-bashrc.diff
@@ -2,17 +2,17 @@
 
 --- a/doc/bash.1
 +++ b/doc/bash.1
-@@ -187,7 +187,9 @@ Display a usage message on standard outp
- .PD
- Execute commands from
- .I file
--instead of the standard personal initialization file
-+instead of the system wide initialization file
-+.I /etc/bash.bashrc
-+and the standard personal initialization file
- .I ~/.bashrc
+@@ -192,7 +192,9 @@ instead of the standard personal initial
  if the shell is interactive (see
  .SM
+ .B INVOCATION
+-below).
++below). Note that the system wide initialization file
++.I /etc/bash.bashrc
++is still executed.
+ .TP
+ .B \-\-login
+ Equivalent to \fB\-l\fP.
 @@ -218,7 +220,9 @@ reads these files when it is invoked as
  below).
  .TP
@@ -36,13 +36,12 @@
  option.
  The \fB\-\-rcfile\fP \fIfile\fP option will force
  .B bash
--to read and execute commands from \fIfile\fP instead of \fI~/.bashrc\fP.
-+to read and execute commands from \fIfile\fP instead of
-+\fI/etc/bash.bashrc\fP and \fI~/.bashrc\fP.
+ to read and execute commands from \fIfile\fP instead of \fI~/.bashrc\fP.
++Note that \fI/etc/bash.bashrc\fP will still be read.
  .PP
  When
  .B bash
-@@ -426,8 +432,8 @@ or the secure shell daemon \fIsshd\fP.
+@@ -426,14 +432,15 @@ or the secure shell daemon \fIsshd\fP.
  If
  .B bash
  determines it is being run non-interactively in this fashion,
@@ -53,7 +52,15 @@
  It will not do this if invoked as \fBsh\fP.
  The
  .B \-\-norc
-@@ -11581,6 +11587,9 @@ The \fBbash\fP executable
+ option may be used to inhibit this behavior, and the
+ .B \-\-rcfile
+-option may be used to force another file to be read, but neither
++option may be used to force another file to be read instead of
++\fI~/.bashrc\fP, but neither
+ \fIrshd\fP nor \fIsshd\fP generally invoke the shell with those options
+ or allow them to be specified.
+ .PP
+@@ -11672,6 +11679,9 @@ The \fBbash\fP executable
  .FN /etc/profile
  The systemwide initialization file, executed for login shells
  .TP

Bug#1055936: synaptic: Non-installable on hurd-i386

[Svante Signell]

Source: synaptic
Version: 0.93.1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@lists.debian.org

Hi,

synaptic is not installable on hurd-i386 due to dependencies on polkitd, pkexec
and policykit-1 which are only available for GNU/Linux.

A patch enabling a successful installation is attached:
debian_control.patch

Thanks!






--- a/debian/control	2023-11-14 11:54:05.0 +0100
+++ b/debian/control	2023-11-14 11:56:06.0 +0100
@@ -12,7 +12,7 @@
 
 Package: synaptic
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, hicolor-icon-theme, polkitd | policykit-1, pkexec | policykit-1
+Depends: ${shlibs:Depends}, ${misc:Depends}, hicolor-icon-theme, polkitd [linux-any] | policykit-1 [linux-any], pkexec [linux-any] | policykit-1 [linux-any]
 Recommends: libgtk3-perl, xdg-utils
 Suggests: dwww, deborphan, apt-xapian-index, tasksel, software-properties-gtk
 Description: Graphical package manager

Bug#1055926: rodbc: [L10N,DE] rodbc_1.3-21-1_R-de: german translation

[Dirk Eddelbuettel]

On 14 November 2023 at 12:30, Christoph Brinkhaus wrote:
| Source: rodbc
| Version: 1.3-21-1
| Severity: wishlist
| 
| Dear Maintainer,
| 
| please find attached the po file with the german translation.
| It is an update to the current po template.
| Please consider to apply it to the package.

Should that not go to the upstream package, possibly via the R Translations
project (where AFAIK German po files are handled by Detlef Steuer) ?

https://translation.r-project.org/

Dirk

| Thank you very much!
| 
| Kind regards,
| Christoph Brinkhaus
| 
| -- System Information:
| Debian Release: 12.2
|   APT prefers stable-updates
|   APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable')
| Architecture: amd64 (x86_64)
| 
| Kernel: Linux 6.1.0-13-amd64 (SMP w/4 CPU threads; PREEMPT)
| Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
| Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not 
set
| Shell: /bin/sh linked to /usr/bin/dash
| Init: systemd (via /run/systemd/system)
| LSM: AppArmor: enabled
| x[DELETED ATTACHMENT rodbc_1.3-21-1_R-de.po, plain text]

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1055935: mate-polkit: Non-installable on hurd-i386

[Svante Signell]

Source: mate-polkit
Version: 1.26.1-4
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@lists.debian.org

Hi,

mate-polkit is not installable on hurd-i386 due to a dependency on polkitd,
which is only available for GNU/Linux.

A patch enabling a successful installation is attached:
debian_control.patch

Thanks!





--- a/debian/control	2023-04-25 15:12:24.0 +0200
+++ b/debian/control	2023-11-14 10:54:11.0 +0100
@@ -43,7 +43,7 @@
 Architecture: any
 Depends: accountsservice,
  mate-polkit-common (>= ${source:Version}),
- polkitd,
+ polkitd [linux-any],
  ${misc:Depends},
  ${shlibs:Depends},
 Provides: polkit-1-auth-agent,

Bug#1055922: rmatrix: ABI change in Matrix 1.6-2

[Dirk Eddelbuettel]

On 14 November 2023 at 09:15, Graham Inggs wrote:
| Source: rmatrix
| Version: 1.6-2-1
| Severity: serious
| X-Debbugs-Cc: debia...@lists.debian.org
| 
| Hi Dirk
| 
| I'm opening this bug as a place for discussion and to track the
| affected packages.  It can be closed once rmatrix and its
| reverse-dependencies are ready to migrate.

Well that seems to be a) the wrong severity and b) the wrong package.

We need to address the packages needing a rebuild. Mine (r-cran-lme4,
r-cran-rcppeigen).  have been taken care of.

Dirk
 
| I've copied your email to the debian-r mailing list [1] below.
| 
| Regards
| Graham
| 
| 
| [1] https://lists.debian.org/debian-r/2023/11/msg00033.html
| 
| 
| Package Matrix is having a new and energetic maintainer/contributor in Mikael
| Jagan who is tidying up a few loose corners (and inter alia sent me a patch
| to RcppEigen that resulted in a coordinated CRAN update of RcppEigen, lme4,
| and OpenMx).
| 
| Mikael also identified two sets of packages needed a rebuild in messages to
| the r-package-devel list (the more-or-less official place in the R Project to
| ask / discuss package changes, it is a decent to be on) following private
| mails between him and me. See
| 
| https://stat.ethz.ch/pipermail/r-package-devel/2023q4/010051.html
| https://stat.ethz.ch/pipermail/r-package-devel/2023q4/010054.html
| 
| The first concerns packages using a LinkingTo: Matrix and building against
| Matrix _headers_. The second concerns caching of S4 signatures (which bit us
| at work because of SeuratObject [not in Debian] and how I got onto this).
| 
| Most of these are not in Debian but I think we need binary rebuilds of
| 
|irlbabecause of headers
|OpenMx   because of headers, a new upstream 2.21.10 is out too
|TMB  because of headers
|MatrixModels because of S4 caching
| 
| I would appreciate it if someone could tickle rebuilds. To me a quick
| informal touch of debian/changelog would do; if someone thinks this needs a
| formal transition go for it.
| 
| The R Core team and the CRAN maintainers are aware of the implicit problem
| with signalling the need for binary rebuilds. They are discussing this, but
| do not have an answer. Historically, CRAN has informally rebuilt its binaries
| for windows and macOS, but that of course does not help binary distributors
| such as us, other Linux distros, Conda, r2u, ... at all.

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1053467: network-manager-openconnect-gnome: No option to specify UserAgent header in GUI

[Salvatore Bonaccorso]

Hi

I parepared a backport of a series of three commits for it, for
bookworm and have lightly tested it. It seems to work and as such I
would like to propose an update for the upcoming point release.

Luca, is this fine with you? Can you peer-review the debdiff?

Regards,
Salvatore
diff -Nru network-manager-openconnect-1.2.8/debian/changelog 
network-manager-openconnect-1.2.8/debian/changelog
--- network-manager-openconnect-1.2.8/debian/changelog  2022-05-21 
15:35:15.0 +0200
+++ network-manager-openconnect-1.2.8/debian/changelog  2023-11-14 
13:38:09.0 +0100
@@ -1,3 +1,13 @@
+network-manager-openconnect (1.2.8-3+deb12u1) bookworm; urgency=medium
+
+  * Non-maintainer upload.
+  * Add User Agent to Openconnect VPN for NetworkManager (Closes: #1053467)
+  * Use openconnect_set_useragent() where available
+  * Add support for GTK4 in user-agent calls
+  * Add Build-Depends on libgtk-4-bin for gtk4-builder-tool
+
+ -- Salvatore Bonaccorso   Tue, 14 Nov 2023 13:38:09 +0100
+
 network-manager-openconnect (1.2.8-3) unstable; urgency=medium
 
   * Bump Standards-Version to 4.6.1, no changes
diff -Nru network-manager-openconnect-1.2.8/debian/control 
network-manager-openconnect-1.2.8/debian/control
--- network-manager-openconnect-1.2.8/debian/control2022-05-21 
15:35:15.0 +0200
+++ network-manager-openconnect-1.2.8/debian/control2023-11-14 
13:38:09.0 +0100
@@ -8,6 +8,7 @@
libgcr-3-dev,
libglib2.0-dev,
libgtk-3-dev,
+   libgtk-4-bin,
libgtk-4-dev,
libnm-dev,
libnma-dev,
diff -Nru 
network-manager-openconnect-1.2.8/debian/patches/0002-Add-User-Agent-to-Openconnect-VPN-for-NetworkManager.patch
 
network-manager-openconnect-1.2.8/debian/patches/0002-Add-User-Agent-to-Openconnect-VPN-for-NetworkManager.patch
--- 
network-manager-openconnect-1.2.8/debian/patches/0002-Add-User-Agent-to-Openconnect-VPN-for-NetworkManager.patch
1970-01-01 01:00:00.0 +0100
+++ 
network-manager-openconnect-1.2.8/debian/patches/0002-Add-User-Agent-to-Openconnect-VPN-for-NetworkManager.patch
2023-11-14 13:38:09.0 +0100
@@ -0,0 +1,302 @@
+From: Debasish Patra 
+Date: Sat, 29 Aug 2020 17:58:16 -0400
+Subject: Add User Agent to Openconnect VPN for NetworkManager
+Origin: 
https://gitlab.gnome.org/GNOME/NetworkManager-openconnect/-/commit/b5e154c06fd9013a925f85c2aa38d88e4ee53db0
+Bug-Debian: https://bugs.debian.org/1053467
+
+---
+ auth-dialog/main.c|  3 +-
+ properties/nm-openconnect-dialog.ui   | 73 +--
+ properties/nm-openconnect-editor-plugin.c |  5 ++
+ properties/nm-openconnect-editor.c| 15 +
+ shared/nm-service-defines.h   |  1 +
+ 5 files changed, 79 insertions(+), 18 deletions(-)
+
+diff --git a/auth-dialog/main.c b/auth-dialog/main.c
+index 99cab7cd921f..305b568650ba 100644
+--- a/auth-dialog/main.c
 b/auth-dialog/main.c
+@@ -1853,6 +1853,7 @@ static void build_main_dialog(auth_ui_data *ui_data)
+ 
+ static auth_ui_data *init_ui_data (char *vpn_name, GHashTable *options, 
GHashTable *secrets, char *vpn_uuid)
+ {
++  char *vpn_useragent = g_hash_table_lookup(options, "useragent");
+   auth_ui_data *ui_data;
+ 
+   ui_data = g_slice_new0(auth_ui_data);
+@@ -1883,7 +1884,7 @@ static auth_ui_data *init_ui_data (char *vpn_name, 
GHashTable *options, GHashTab
+   g_unix_set_fd_nonblocking(ui_data->cancel_pipes[0], TRUE, NULL);
+   g_unix_set_fd_nonblocking(ui_data->cancel_pipes[1], TRUE, NULL);
+ 
+-  ui_data->vpninfo = (void *)openconnect_vpninfo_new("OpenConnect VPN 
Agent (NetworkManager)",
++  ui_data->vpninfo = (void *)openconnect_vpninfo_new(vpn_useragent ?: 
"OpenConnect VPN Agent (NetworkManager)",
+  validate_peer_cert, 
write_new_config,
+  
nm_process_auth_form, write_progress,
+  ui_data);
+diff --git a/properties/nm-openconnect-dialog.ui 
b/properties/nm-openconnect-dialog.ui
+index 43beb44a34a9..f32afcd5899f 100644
+--- a/properties/nm-openconnect-dialog.ui
 b/properties/nm-openconnect-dialog.ui
+@@ -105,6 +105,45 @@
+ 2
+   
+ 
++
++  
++True
++_User Agent:
++True
++False
++GTK_JUSTIFY_LEFT
++False
++False
++1
++0.5
++user_agent_entry
++PANGO_ELLIPSIZE_NONE
++-1
++False
++  
++  
++0
++3
++  
++
++ 
++  
++True
++True
++True
++True
++0
++
++True
++
++False
++True
++  
++  
++1
++3
++  
++
+ 
+   
+ 13
+@@ -114,7 +153,7 @@
+   
+   
+ 0
+-3
++4
+ 2
+   
+ 

Bug#1037168: retitle of reassigned bugs

[Santiago Vila]

retitle 1029423 libpython3.11-stdlib: missing dependency on tzdata
retitle 1029424 libpython3.11-stdlib: missing dependency on tzdata
retitle 1029430 libpython3.11-stdlib: missing dependency on tzdata
retitle 1031362 libpython3.11-stdlib: missing dependency on tzdata
thanks

Bug#1055934: rust-tokio-util: please update to v0.7.8

[Jonas Smedegaard]

Source: rust-tokio-util
Version: 0.7.3-2
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to at least v0.7.8.
-BEGIN PGP SIGNATURE-

iQIyBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVTbZ0ACgkQLHwxRsGg
ASFiFQ/4w3y/G4SnF3lE+7TyGsKpHzuKyqFhFhDq/FOYB3xvEFYzrKBA2AKHx6IK
SvVMAgmxMW+ipcPE/gq6iCkRVlASOfibVhJz7P5jnWZzW1efPNN/zrYibdKYyXDM
kK2o8Q1wui/XdrgvRVTQAwHIRku99GaJa4Pky0wpTiLmV2NIOXjJaNGFxmrpmfrq
an9EH7ykZwKS/vFb+mayCDejVQqPwPHjD0Is+DpKkU93yPzBsHCCLDiibXKkzjto
vmizMuxrohs5bT/Qaj+8to0aLIboNHG1OkwmtKOiHTlfTzU9rWnRpaKh7eczD7IW
HkYgR8sYaFOo4oXlQVchREDax/uEoAVJKSnMvFW9IzYxbjgRgbJQqLlLPtb929SU
P16sr39sI86D3xbzPyk/cr37lj4oNl7l0PMB8ovcS89lbi24hZVK3eP+CtoY6L2u
ynjKDkCCQ/VilKCy/L1N/61CTTF8li/Z7uDvz3NmLpRVMjQh3xG2VBH7gNSpcmnf
Z5bQGqnV+PGjXhdH2ia2WMPjOrxuvU5rwGNiLkivEsNsiJVVavYlrgmgF0RQ+pDU
YAem3OfpemgF+graMs05Q6HAGAgNNLrsTZj3iLxa1gVvXbOwwQOA2bi9LJIw8Ch6
gTImqJ+EsyHplbRTksCca/lKAgEscqHwhrNtHqhKrjBrdlUP7A==
=H6An
-END PGP SIGNATURE-

Bug#1055933: rust-prost: please upgrade/provide v0.12

[Jonas Smedegaard]

Source: rust-prost
Version: 0.11.9-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade to or separate provide newer upstream branch v0.12.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVTbQ4ACgkQLHwxRsGg
ASHi1Q//fDfrBJ1sL2m/V6eACmFkiNoxlX7EG5M9jTxylkg9NrrP3ar3DYStB6nq
hsDIGothUp2bLr43PtGx+Ny/9jDjBUt6krm8DSEuaaF29kOcTfoarnffwPpShnBH
NH98xUQXYv3Auf7aMraaA/Ig9Z5FKgDGdQo/xmoOF4tgjkr484xdg6WAJ2lTSgvL
FTGb3oELCMR5JncBpbpqIqmhI3Lb7bVuYjIjjf5OuTMFvzvB197XKaWowv5BZ9kb
oQ9gML+6KfAQjDWl8UX4AUm+UE43vtfI8+w3CYcOmO8c02FsH467280acZji7CvU
lkZC8g/7ShoI3a/CwSEkot5PGkaVZTHRRR+vMoeAQN4gfmE8y5UXT6yhVg3POvlE
LZNYCvAiszIi6uVryANKcSsHQUxUf+8e5ESEw2dkjDJqbCp0hrruG9ZGVdEpGPGQ
G8mkhWxQ+JH0aFV+FYjc4LBFXUrp3K7rqWKg0o60F6nlMBaKat7xBkD06L/wnMzR
xZpjFgSzlxpdafjNFFTwFHEoSlPhDnjy83//ftiv8C7fxQYZrKlaf6ZvQB0Q2IBs
CBX4UbH2Gv9NDkuBBDft8UO+ihl3MoDjV67mE4ZC8SlBFCTTH5d4io7Q/Ayc5q4X
ldtFwcjs2ZZmYzxdwUovHgqkYXzDdFJcDwQeyKuKTKtYDcj116c=
=EGrX
-END PGP SIGNATURE-

Bug#1055932: rust-pico-args: please upgrade/provide v0.5

[Jonas Smedegaard]

Source: rust-pico-args
Version: 0.4.2-1
Severity: normal
Tags: upstream

Please upgrade to or separately provide newer upstream branch v0.5.

Bug#1055931: apt ignores bullseye-backports

[Vincent Lefevre]

Package: apt
Version: 2.6.1
Severity: important

When I want to report a bug against the Linux kernel, reportbug
recommends to use bullseye-backports to get a more recent version
(even though this is currently a bookworm based machine):

Your version (6.1.55-1) of linux-image-6.1.0-13-amd64 appears to be out of date.
The following newer release(s) are available in the Debian archive:
  bullseye-backports (backports-policy): 6.1.55+1~bpo11+1
Please try to verify if the bug you are about to report is already addressed by 
these releases.  Do you still want to file a report [y|N|q|?]? 

So I've added

deb http://deb.debian.org/debian bullseye-backports main contrib non-free

as documented in .

I did an "apt update". In particular:

[...]
Get:19 http://deb.debian.org/debian bullseye-backports/main Translation-en [343 
kB]
Get:20 http://deb.debian.org/debian bullseye-backports/main amd64 Contents 
(deb) [1367 kB]
Get:21 http://deb.debian.org/debian bullseye-backports/main all Contents (deb) 
[4773 kB]
Get:22 http://deb.debian.org/debian bullseye-backports/contrib amd64 Packages 
[5968 B]
Get:23 http://deb.debian.org/debian bullseye-backports/contrib Translation-en 
[6004 B]
Get:24 http://deb.debian.org/debian bullseye-backports/contrib amd64 Contents 
(deb) [17.1 kB]
Get:25 http://deb.debian.org/debian bullseye-backports/contrib all Contents 
(deb) [22.2 kB]
Get:26 http://deb.debian.org/debian bullseye-backports/non-free amd64 Packages 
[13.9 kB]
Get:27 http://deb.debian.org/debian bullseye-backports/non-free Translation-en 
[27.6 kB]
Get:28 http://deb.debian.org/debian bullseye-backports/non-free amd64 Contents 
(deb) [10.8 kB]
Get:29 http://deb.debian.org/debian bullseye-backports/non-free all Contents 
(deb) [58.5 kB]
[...]

But "apt show -a linux-image-6.1.0-13-amd64" just gives the 6.1.55-1
version (no 6.1.55+1~bpo11+1 version), and

  apt install -t bullseye-backports linux-image-6.1.0-13-amd64

also thinks that 6.1.55-1 is the version to be installed.

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-.*";
APT::VersionedKernelPackages:: "kfreebsd-.*";
APT::VersionedKernelPackages:: "gnumach-.*";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "tasks";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "test -x /usr/bin/apt-show-versions || exit 
0 ; apt-show-versions -i";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && 
/usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call 
--system --dest org.freedesktop.PackageKit --object-path 
/org/freedesktop/PackageKit --timeout 4 --method 
org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo 
> /dev/null";
APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/swcatalog -a 
-e /usr/bin/appstreamcli; then appstreamcli refresh --source=os > /dev/null || 
true; fi";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::zstd "";
APT::Compressor::zstd::Name "zstd";
APT::Compressor::zstd::Extension ".zst";
APT::Compressor::zstd::Binary "zstd";
APT::Compressor::zstd::Cost "60";
APT::Compressor::zstd::CompressArg "";
APT::Compressor::zstd::CompressArg:: "-19";
APT::Compressor::zstd::UncompressArg "";
APT::Compressor::zstd::UncompressArg:: "-d";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";

Bug#1055930: ITP: yte -- YAML template engine with Python expressions

[Ananthu C V]

Package: wnpp
Severity: wishlist
Owner: Ananthu C V 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: yte
  Version : 1.5.1
  Upstream Author : Johannes K��ster 
* URL : https://github.com/yte-template-engine/yte
* License : Expat
  Programming Lang: Python
  Description : YAML template engine with Python expressions

Binary package names: python3-yte
 YTE is a template engine for YAML format that utilizes the YAML structure
 in combination with Python expressions for enabling to dynamically build
 YAML documents.
 .
 The key idea of YTE is to rely on the YAML structure to enable conditionals,
 loops and other arbitrary Python expressions to dynamically render YAML
 files. Python expressions are thereby declared by prepending them with a ?
 anywhere in the YAML. Any such value will be automatically evaluated by YTE,
 yielding plain YAML as a result. Importantly, YTE templates are still valid
 YAML files (for YAML, the ? expressions are just strings).