Bug#1064617: Passwords should not be changed frequently

[Justin B Rye]

Philip Hands wrote:
>> Maybe instead of saying "use the system's initial user account to
>> become root" it should say "allow the system's initial user account
>> to gain administrative privileges"?  I'm not sure.  Oh, and we might
>> even want to mention the word "superuser", or then again we might not.
> 
> I think Diederik's suggestion of using 'root' for the account and
> 'super-user' for the privileges might be the way to go.

Looking at what I end up with after another couple of rounds of
fiddling with it I'm not sure if it's doing quite what you asked for,
but you still might want it so here it is:

-   Some account needs to have system administrative privileges. The
-   password/passphrase for that account should be something that
-   cannot be guessed.
+   Some account needs to be available with administrative super-user
+   privileges. The password/passphrase for that account should be
+   something that cannot be guessed.
.
To allow direct password-based access via the 'root' account, you
can set the password/passphrase for that account here.
.
-   Alternatively, you can lock root's password
+   Alternatively, you can lock the root account's password
by leaving this setting empty, and
instead use the system's initial user account
(which will be set up in the next step)
-   to become root. This will be enabled for you
-   by adding that user to the 'sudo' group.
+   to gain administrative privileges. This will be enabled for you by
+   adding that initial user to the 'sudo' group.
.
Note: what you type here will be hidden (unless you select to show it).

-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#1065595: cyrus-sasl2: Please add nodoc build profile to allow disabling documentation

[John Paul Adrian Glaubitz]

Source: cyrus-sasl2
Version: 2.1.28+dfsg1-4
Severity: normal
User: helm...@debian.org
Usertags: rebootstrap
X-Debbugs-Cc: helm...@debian.org

Hello,

cyrus-sasl2 is one of the core dependencies required for bootstrapping Debian
but requires the Pyton package Sphinx for building documentation. This can be
easily avoided by removing the "doc-html" target during build. This way, the
python3-sphinx-rtd-theme build dependency can be omitted.

It would be ideal for a "nodoc" build profile which I am asking to be added 
here.

Thanks,
Adrian

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

Bug#1065594: cinnamon: Blocks a huge number of packages for being updated

[Michael Rasmussen]

Package: cinnamon
Version: 5.8.4-4
Severity: important

Dear Maintainer,

Cinnamon have been left on the station while all other packages have
left with the train ;-)
Currently this is state on my installations:
apt upgrade
0 upgraded, 0 newly installed, 0 to remove and 565 not upgraded.
apt full-upgrade
509 upgraded, 285 newly installed, 702 to remove and 8 not upgraded.

So either build a new release of Cinnamon 5.8 or move the 6.0.4
which have been wainting for over a month in experimental from
experimental to unstable.

Thanks.

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

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

Versions of packages cinnamon depends on:
ii  cinnamon-common  5.8.4-4
ii  cinnamon-control-center  5.8.2-1+b1
ii  cinnamon-desktop-data5.8.0-2.1
ii  cinnamon-screensaver 5.8.1-3
ii  cinnamon-session 5.8.1-2
ii  cinnamon-settings-daemon 5.8.1-3+b1
ii  cjs  6.0.0-2
ii  cups-pk-helper   0.2.6-1+b1
ii  dbus 1.14.10-4
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4+b1
ii  gir1.2-accountsservice-1.0   23.13.9-6
ii  gir1.2-caribou-1.0   0.4.21-8+b1
ii  gir1.2-cmenu-3.0 6.0.0-1+b1
ii  gir1.2-cvc-1.0   5.8.0-2+b1
pn  gir1.2-ecal-2.0  
pn  gir1.2-edataserver-1.2   
ii  gir1.2-gdkpixbuf-2.0 2.42.10+dfsg-3+b1
ii  gir1.2-gkbd-3.0  3.28.1-1
ii  gir1.2-glib-2.0  1.78.1-15
ii  gir1.2-goa-1.0   3.49.0-1
ii  gir1.2-gsound-1.01.0.3-2+b1
ii  gir1.2-gtk-3.0   3.24.41-1
ii  gir1.2-ical-3.0  3.0.17-1
ii  gir1.2-keybinder-3.0 0.3.2-1.1+b1
ii  gir1.2-nemo-3.0  5.8.5-2+b1
ii  gir1.2-nm-1.01.46.0-1
ii  gir1.2-nma-1.0   1.10.6-3
ii  gir1.2-notify-0.70.8.3-1
ii  gir1.2-pango-1.0 1.52.0+ds-1
ii  gir1.2-polkit-1.0124-1
ii  gir1.2-soup-2.4  2.74.3-3
ii  gir1.2-timezonemap-1.0   0.4.6-6
ii  gir1.2-upowerglib-1.01.90.2-8
ii  gir1.2-xapp-1.0  2.8.2-1
ii  gkbd-capplet 3.28.1-1
ii  gnome-backgrounds45.0-1
ii  gnome-themes-extra   3.28-2+b1
ii  gsettings-desktop-schemas46~beta-3
ii  iso-flags-png-320x2401.0.2-2
ii  libatk-bridge2.0-0   2.50.0-1+b1
ii  libatk1.0-0  2.50.0-1+b1
ii  libc62.37-15.1
ii  libcairo21.18.0-1+b1
ii  libcinnamon-desktop4 5.8.0-2+b1
ii  libcinnamon-menu-3-0 6.0.0-1+b1
ii  libcjs0  6.0.0-2
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3+b1
ii  libgirepository-1.0-11.78.1-15
ii  libgles2 1.7.0-1
ii  libglib2.0-0 2.78.4-1
pn  libglib2.0-bin   
ii  libgstreamer1.0-01.22.10-1
ii  libgtk-3-0   3.24.41-1
ii  libmuffin0   5.8.1-2+b1
ii  libpango-1.0-0   1.52.0+ds-1
ii  libx11-6 2:1.8.7-1
ii  libxapp1 2.8.2-1
ii  libxfixes3   1:6.0.0-2
ii  libxml2  2.9.14+dfsg-1.3+b2
ii  mesa-utils   9.0.0-2
ii  muffin   5.8.1-2+b1
ii  nemo 5.8.5-2+b1
ii  network-manager-gnome1.34.0-2
ii  pkexec   124-1
ii  policykit-1-gnome0.105-8
ii  psmisc   23.7-1
ii 

Bug#1065593: units: Allow access to user's own input

[Dan Jacobson]

X-Debbugs-Cc: adri...@gnu.org
Package: units
Version: 2.23-1
Severity: wishlist

It seems that a big lack of the units program, is access to the user's
own input after he inputs it.

Often one needs access to the original input value, and currently must
use workarounds.

$ for i in `seq 5`; do echo -n "$i mi = "; units --terse ${i}mi km; done|sed 
's/$/ km/'
1 mi = 1.609344 km
2 mi = 3.218688 km
3 mi = 4.828032 km
4 mi = 6.437376 km
5 mi = 8.04672 km

Maybe allow something like

$ for i in `seq 5`; do units --printf "%d{input} mi = %f{output} km\n" ${i}mi 
km; done

I don't know.

Bug#1065592: partman-efi: add build support for loongarch64

[zhangdandan]

Source: partman-efi
Version: 103
Severity: wishlist
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

The partman-efi source package lacks LoongArch architecture support.
We need to add build support for loongarch64 in d/control.

Please consider the patch I have attached.
The partman-efi source package was compiled successfully on my local 
loong64 rootfs environment.

If you have any questions, you can contact me at any time.

thanks,
Dandan Zhang

diff -Nru partman-efi-103/debian/control partman-efi-103/debian/control
--- partman-efi-103/debian/control  2024-01-06 21:33:46.0 +
+++ partman-efi-103/debian/control  2024-01-06 21:49:11.0 +
@@ -9,6 +9,6 @@
 
 Package: partman-efi
 Package-Type: udeb
-Architecture: i386 ia64 amd64 arm64 armhf riscv64
+Architecture: i386 ia64 amd64 arm64 armhf riscv64 loong64
 Depends: partman-base, efi-modules, dosfstools-udeb, ${misc:Depends}
 Description: Add to partman support for EFI System Partitions

Bug#1064139: Bug #1064139 ogre-1.12: FTBFS: error: ‘BuildFontAtlas’ is not a member of ‘ImGuiFreeType’

[Flavien Bridault]

Dear Simon,

Many thanks for your answer.

I just cloned the repository to open the MR but then I realized there is 
already a branch opened two weeks ago exactly with the fix I proposed... 
So I guess it is on its way ?


I will follow your advice for ogre 1.14, it was not clear for me I could 
simply open an MR. :)


Cheers,


*Dr. Flavien BRIDAULT*
Director of Software Development
IRCAD France & IRCAD Africa

flavien.brida...@ircad.fr 
Tél. : +33 (0)3 88 119 201
IRCAD France
http://www.ircad.fr/
http://www.ircad.africa/ 

Suivez l'IRCAD sur Facebook 



*IRCAD France*
Hôpitaux Universitaires - 1, place de l'Hôpital - 67091 Strasbourg Cedex 
- FRANCE


Le 06/03/2024 à 23:25, Simon Schmeißer a écrit :


Dear Flavien,

a good and simple start would be to open a Merge Request (MR) adding a 
patch on salsa: https://salsa.debian.org/games-team/ogre


Then salsa CI will test your changes and it can be sponsored by someone.


There was ongoing work to update to 1.12.13  but it stalled: 
https://salsa.debian.org/games-team/ogre/-/merge_requests/6


The main work is likely to identify what needs to change for the 
copyright file to be acceptable



If you want to get started on ogre 14 you could start by combining the 
changes in the 1.12.13 branch with those here 
https://salsa.debian.org/games-team/ogre/-/commits/ogre-13.3/?ref_type=heads


I'm currently super short on time but will try to help you with any 
technical problems if you open a MR for a patch


Best regards from Freiburg

Simon

Am 06.03.24 um 08:46 schrieb Flavien Bridault:


Dear maintainer(s),

I took a look at the latest version of Ogre which is probably 
compatible with latest ImGui and it seems this line is no longer 
necessary. It was removed before the release 13.0.0 when upgrading to 
ImGUI 1.83 : 
https://github.com/OGRECave/ogre/commit/17b7481057b97662a3752ee605ea77a9eb0c57db


Patching should be then fairly easy...

I can offer my help again, like I did to upgrade to 1.14 
(https://lists.debian.org/debian-devel-games/2023/11/msg1.html), 
which whould really be the best option in the end... Maybe I will 
have an official answer this time ? I don't want to be sarcastic at 
all, but I strongly depend on Ogre to build sight and this is 
annoying to get no answer from the devel games team. And currently my 
package sight is currently marked for autoremoval because of this bug 
(https://tracker.debian.org/pkg/sight)


Kind regards,

--

*Dr. Flavien BRIDAULT*
Director of Software Development
IRCAD France & IRCAD Africa

flavien.brida...@ircad.fr 
Tél. : +33 (0)3 88 119 201
IRCAD France
http://www.ircad.fr/
http://www.ircad.africa/ 

Suivez l'IRCAD sur Facebook 



*IRCAD France*
Hôpitaux Universitaires - 1, place de l'Hôpital - 67091 Strasbourg 
Cedex - FRANCE




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1065591: openvswitch: enable dpdk build support for loongarch64

[zhangdandan]

Source: openvswitch
Version: 3.3.0~git20240118.e802fe7-3
Severity: wishlist
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

The openvswitch source package lacks additional loongarch64 support.
Please consider the patch I attached.

Based on the attached patch, it is possible to compile 2 more packages 
for loong64, for examples,

openvswitch-switch-dpdk-dbgsym_3.3.0~git20240118.e802fe7-3_loong64.deb
openvswitch-switch-dpdk_3.3.0~git20240118.e802fe7-3_loong64.deb

If you have any questions, you can contact me at any time.

thanks,
Dandan Zhang

diff -Nru openvswitch-3.3.0~git20240118.e802fe7/debian/control 
openvswitch-3.3.0~git20240118.e802fe7/debian/control
--- openvswitch-3.3.0~git20240118.e802fe7/debian/control2024-01-19 
11:03:39.0 +
+++ openvswitch-3.3.0~git20240118.e802fe7/debian/control2024-02-05 
08:45:19.0 +
@@ -22,10 +22,10 @@
  iproute2,
  libbpf-dev,
  libcap-ng-dev,
- libdbus-1-dev [amd64 i386 ppc64el arm64 riscv64],
- libdpdk-dev (>= 22.11.3-2~) [amd64 i386 ppc64el arm64 riscv64],
- libnuma-dev [amd64 i386 ppc64el arm64 riscv64 s390x],
- libpcap-dev [amd64 i386 ppc64el arm64 riscv64],
+ libdbus-1-dev [amd64 i386 ppc64el arm64 riscv64 loong64],
+ libdpdk-dev (>= 22.11.3-2~) [amd64 i386 ppc64el arm64 riscv64 loong64],
+ libnuma-dev [amd64 i386 ppc64el arm64 riscv64 loong64 s390x],
+ libpcap-dev [amd64 i386 ppc64el arm64 riscv64 loong64],
  libssl-dev,
  libtool,
  libunbound-dev,
@@ -180,7 +180,7 @@
  the Open vSwitch kernel-based switch.
 
 Package: openvswitch-switch-dpdk
-Architecture: amd64 arm64 i386 ppc64el riscv64
+Architecture: amd64 arm64 i386 ppc64el riscv64 loong64
 Pre-Depends: ${misc:Pre-Depends},
 Depends:
  dpdk,
diff -Nru openvswitch-3.3.0~git20240118.e802fe7/debian/rules 
openvswitch-3.3.0~git20240118.e802fe7/debian/rules
--- openvswitch-3.3.0~git20240118.e802fe7/debian/rules  2024-01-19 
11:03:39.0 +
+++ openvswitch-3.3.0~git20240118.e802fe7/debian/rules  2024-02-05 
08:45:19.0 +
@@ -34,7 +34,7 @@
 $(DATAPATH_CONFIGURE_OPTS) \
 $(EXTRA_CONFIGURE_OPTS) \
 )
-ifneq (,$(filter i386 amd64 ppc64el arm64 riscv64, $(DEB_HOST_ARCH)))
+ifneq (,$(filter i386 amd64 ppc64el arm64 riscv64 loong64, $(DEB_HOST_ARCH)))
test -d _dpdk || mkdir _dpdk
cd _dpdk && ( \
test -e Makefile || \
@@ -142,7 +142,7 @@
fi
 # Skip DPDK testing on arm64 as builders don't have crc32 support
 # which is used in aarch64 based crc optimization in ovs >= 2.12.0~
-ifneq (,$(filter i386 amd64 ppc64el riscv64, $(DEB_HOST_ARCH)))
+ifneq (,$(filter i386 amd64 ppc64el riscv64 loong64, $(DEB_HOST_ARCH)))
if $(MAKE) -C _dpdk check TESTSUITEFLAGS='$(PARALLEL) 
$(TEST_LIST_DPDK)' || \
$(MAKE) -C _dpdk check 
TESTSUITEFLAGS='--recheck'; then :; \
else \
@@ -155,7 +155,7 @@
 override_dh_auto_build:
dh_auto_build --sourcedirectory=_debian -- distdir-am 
distdir=openvswitch
dh_auto_build --sourcedirectory=_debian
-ifneq (,$(filter i386 amd64 ppc64el arm64 riscv64, $(DEB_HOST_ARCH)))
+ifneq (,$(filter i386 amd64 ppc64el arm64 riscv64 loong64, $(DEB_HOST_ARCH)))
dh_auto_build --sourcedirectory=_dpdk
 endif
 

Bug#1065590: debmake: Debmake produces warnings about invalid escape sequence on Python 3.12

[Loren M. Lang]

Package: debmake
Version: 4.4.0-3
Severity: minor

Dear Maintainer,

Using debmake on unstable with Python 3.12 installed. While installing
debmake with apt-get, a long series of warnings were produced similar to
this:

Setting up debmake (4.4.0-3) ...
/usr/lib/python3/dist-packages/debmake/__main__.py:304: SyntaxWarning: invalid 
escape sequence '\/'
  + ' -type f 2>&1 | sed -e "s/^debian\/'
/usr/lib/python3/dist-packages/debmake/__main__.py:306: SyntaxWarning: invalid 
escape sequence '\/'
  + '\///" | sort >../{0}.install.log'.format(para["package"])

The package should install cleanly without warnings. These warnings do
not seem to affect the functionality as Python 3.12 simply falls back to
3.11 behavior after producing the warning.


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

Kernel: Linux 6.5.0-21-generic (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages debmake depends on:
ii  devscripts  2.23.7
ii  dpkg-dev1.22.4
ii  python3 3.11.8-1
ii  python3-debian  0.1.49
ii  rsync   3.2.7-1+b1

Versions of packages debmake recommends:
ii  build-essential  12.10
ii  curl 8.6.0-3
ii  strace   6.5-0.1
ii  wget 1.21.4-1+b1

Versions of packages debmake suggests:
ii  autotools-dev 20220109.1
pn  ccache
pn  cmake 
pn  debmake-doc   
pn  dgit  
ii  dh-autoreconf 20
ii  dh-python 6.20231223
ii  eatmydata 131-1
pn  gem2deb   
ii  git   1:2.43.0-1
ii  git-buildpackage  0.9.33
pn  gitk  
pn  javahelper
ii  lintian   2.117.0
pn  mc
ii  quilt 0.67+really0.67-4
pn  rpm2cpio  
ii  sbuild0.85.5

-- no debconf information

Bug#1065584: dh_update_autotools_config: cp: warning: behavior of -n is non-portable and may change…

[Niels Thykier]

Thorsten Glaser:

Package: debhelper
Version: 13.14.1
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

dh_update_autotools_config -a -O--builddirectory=debian/build
cp: warning: behavior of -n is non-portable and may change in future; use 
--update=none instead
cp: warning: behavior of -n is non-portable and may change in future; use 
--update=none instead

(showing up in build logs)



Fixed and reverted previously (see #1061610).

This will probably not be fixed until relevant coreutils is in stable.

Best regards,
Niels

Bug#1065589: knotes: Does not allow upgrading libkf5akonadisearch-bin and libkf5akonadisearch-plugins

[Huey Chen]

Package: knotes
Version: 4:22.12.3-1
Severity: normal
X-Debbugs-Cc: hueyche...@outlook.com

Dear Maintainer,

When using Debian Sid, I keep getting these two packages, 
libkf5akonadisearch-bin and libkf5akonadisearch-plugins, held back from 
upgrading because they would install a later version of 
libkf5akonadisearchpim5, libkf5akonadicore5abi2, and libkf5akonadisearchxapian5 
not supported by knotes.  
Upgrading the packages will remove knotes and some other packages depending on 
older version of the three packages. I expected the three packages are removed 
but replaced by the same packages ending in t64 to work as aptitude says 
version >=4:22.12.3 of the three packages are supported, except another line 
says only version the older version is supported.
I have repeatedly updated by Debian system but it was never fixed after a week 
or so.
Possible fix:
Update knotes and possibly other packages (which is a lot) to allow the latest 
version of libkf5akonadisearch-bin and libkf5akonadisearch-plugins and its new 
dependencies ending in t64.
Thanks for fixing this if you do fix it.
-- System Information:
Debian Release: trixie/sid
  APT prefers unstablelibkf5akonadisearch-bin
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages knotes depends on:
ii  kdepim-runtime 4:22.12.3-2
ii  kio5.107.0-1+b1
ii  libc6  2.37-15.1
ii  libgcc-s1  14-20240303-1
ii  libkf5akonadiagentbase5 [libkf5akonadiagentbase5-22.12]4:22.12.3-1+b1
ii  libkf5akonadicore5abi2 [libkf5akonadicore5-22.12]  4:22.12.3-1+b1
ii  libkf5akonadinotes5 [libkf5akonadinotes5-22.12]4:22.12.3-1+b1
ii  libkf5akonadisearch-bin4:22.12.3-1+b1
ii  libkf5akonadisearch-plugins4:22.12.3-1+b1
ii  libkf5akonadisearchdebug5 [libkf5akonadisearchdebug5-22.1  4:22.12.3-1+b1
2]
ii  libkf5akonadisearchpim5 [libkf5akonadisearchpim5-22.12]4:22.12.3-1+b1
ii  libkf5akonadiwidgets5abi1 [libkf5akonadiwidgets5-22.12]4:22.12.3-1+b1
ii  libkf5calendarcore5abi25:5.107.0-1+b1
ii  libkf5calendarutils5 [libkf5calendarutils5-22.12]  4:22.12.3-2+b2
ii  libkf5completion5  5.107.0-1+b1
ii  libkf5configcore5  5.107.0-1+b1
ii  libkf5configgui5   5.107.0-1+b1
ii  libkf5configwidgets5   5.107.0-2+b1
ii  libkf5contacts55:5.107.0-1
ii  libkf5coreaddons5  5.107.0-1+b1
ii  libkf5crash5   5.107.0-1+b1
ii  libkf5dnssd5   5.107.0-1+b1
ii  libkf5globalaccel-bin  5.107.0-2+b1
ii  libkf5globalaccel5 5.107.0-2+b1
ii  libkf5grantleetheme5 [libkf5grantleetheme5-22.12]  22.12.3-2+b1
ii  libkf5i18n55.107.0-1+b1
ii  libkf5iconthemes5  5.107.0-1+b1
ii  libkf5itemmodels5  5.107.0-1+b1
ii  libkf5itemviews5   5.107.0-1+b1
ii  libkf5kcmutils55.107.0-2+b1
ii  libkf5kiofilewidgets5  5.107.0-1+b1
ii  libkf5kontactinterface5 [libkf5kontactinterface5-22.12]22.12.3-1+b1
ii  libkf5mime5abi1 [libkf5mime5-22.12]22.12.3-1+b1
ii  libkf5newstuff55.107.0-2+b1
ii  libkf5newstuffcore55.107.0-2+b1
ii  libkf5notifications5   5.107.0-1+b1
ii  libkf5notifyconfig55.107.0-1+b1
ii  libkf5parts5   5.107.0-1+b1
ii  libkf5pimcommon5abi2 [libkf5pimcommon5-22.12]  4:22.12.3-1
ii  libkf5pimcommonakonadi5abi1 [libkf5pimcommonakonadi5-22.1  4:22.12.3-1
2]
ii  libkf5pimcommonautocorrection5 [libkf5pimcommonautocorrec  4:22.12.3-1
tion5-22.12]
ii  libkf5pimtextedit5abi2 [libkf5pimtextedit5-22.12]  22.12.3-1+b1
ii  libkf5textwidgets5 5.107.0-1+b1
ii  libkf5widgetsaddons5   5.107.0-1+b1
ii  libkf5windowsystem55.107.0-1+b1
ii  

Bug#1064781: Accepted php-dompdf-svg-lib 0.5.2-1 (source) into unstable

[Salvatore Bonaccorso]

Source: php-dompdf-svg-lib
Source-Version: 0.5.2-1

This addresses as well #1064781.

On Wed, Mar 06, 2024 at 10:23:06PM +, Debian FTP Masters wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Format: 1.8
> Date: Wed, 06 Mar 2024 22:47:59 +0100
> Source: php-dompdf-svg-lib
> Architecture: source
> Version: 0.5.2-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian PHP PEAR Maintainers 
> Changed-By: William Desportes 
> Changes:
>  php-dompdf-svg-lib (0.5.2-1) unstable; urgency=medium
>  .
>* New upstream version 0.5.2
>- Fixes validation vulnerability CVE-2024-25117
> Checksums-Sha1:
>  d8b5ecc5665000abb1fb0fa6f36f5b51a7ca426a 2195 php-dompdf-svg-lib_0.5.2-1.dsc
>  46c119d7dc7a47c2c868073b73b2dedc2d3eb942 57040 
> php-dompdf-svg-lib_0.5.2.orig.tar.xz
>  192337d493164b3ef2452cfcde5940ac69ff1dd0 2904 
> php-dompdf-svg-lib_0.5.2-1.debian.tar.xz
>  62b6c8c4a6565bfc188af4a5316b39759fc25f77 10065 
> php-dompdf-svg-lib_0.5.2-1_source.buildinfo
> Checksums-Sha256:
>  2fb4e92bcd3e3a18d9eca9d58fa8fe94912e2152b90431ec21867b0873c2f103 2195 
> php-dompdf-svg-lib_0.5.2-1.dsc
>  ecad76e01a6d553b254721132a41eec524130f0e68e5e4f7ca82e4184f2abddf 57040 
> php-dompdf-svg-lib_0.5.2.orig.tar.xz
>  34276aff6270a1faf256edb9a8118d889d76e023eb51b62166c1d97b6cac6f05 2904 
> php-dompdf-svg-lib_0.5.2-1.debian.tar.xz
>  a34ff961c6b93ad2bff9083d11a8671c188db4b092227546939100444ceeaaa6 10065 
> php-dompdf-svg-lib_0.5.2-1_source.buildinfo
> Files:
>  30540889f8cc8655d5f6e887fc96bf98 2195 php optional 
> php-dompdf-svg-lib_0.5.2-1.dsc
>  2c1bb8d8e57d360bdc83c1e866f043cf 57040 php optional 
> php-dompdf-svg-lib_0.5.2.orig.tar.xz
>  98a8bd4dc556b21407ba51ef57d56192 2904 php optional 
> php-dompdf-svg-lib_0.5.2-1.debian.tar.xz
>  1e7ab1da9f326d16b5200a8581fa57f6 10065 php optional 
> php-dompdf-svg-lib_0.5.2-1_source.buildinfo
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEExNkf3872tKPGU/14kKDvG4JRqIkFAmXo6J0ACgkQkKDvG4JR
> qImVpQ/+K8Zdo3k4Pb50tqRIgRW5Q1Y6v0aklM+OOygpMVinAFHoDErhYafo6/iT
> iEPoB64D00JOS5bIVeemX5JOvRiN1zqGE/grEBiprKNzJTjFqDs7sMhmOXEjV56v
> jzRu4loONDOrznMw7T9PZYJ0qwbys0SPSPBk2cya18CoNv+6JqXLn/5KFzVrhSTQ
> 8SRb9JoxZGrwXiXpanty7NHDo+QPgEp4KfOkvAtPkJ+HGy/OagtqjfVtcs1vTivC
> x1pdtnaCZr0cl7Mz1SYHlfsVR6kc6HvtW4bc/aVvqKiSQg4IZC2uNtmEnJcXztqp
> ImwsmWhntuV730DCQxZCDNuKGhplEoY8QCGPPZvY82MpUdpzAqPi1bz2Uunlljj1
> 09yp4BGvAiTftc/obsnN0+iGxz8oovA6nTEqjb6kuTZFWg+MyQTfVgU7zwYvvX09
> i0SQa2dqtVupeYELArq6z69J0d1kCe5CCZ0dTPfWIjkrI34SmDE3JU7W7NhKuneR
> 35mLEMM+9FahE+fDveBbEQuXNx3OcmO+614VV7wJxjwS/GIrdMRleP6AIiNDFtJD
> SSGJJRjFBFjb9ye5RKRruJ1WdsWIfrVKjnd4sLBowNW0ZDJCVfvKWy4XQIvDhjJX
> ZhJUxBfyTEzgtLUmtRzb8/MEQi2kSu+DvfEZijcF7Rk6rmZKvHk=
> =O5Js
> -END PGP SIGNATURE-

Bug#1065586: rust-async-std: Missing installation dependency librust-async-io-2+default-dev for librust-async-std-dev

[Jonas Smedegaard]

Quoting zhangdandan (2024-03-07 02:36:20)
> Package: librust-async-std-dev
> Version: 1.12.0-17
> Severity: wishlist
> Tags: help
> User: debian-loonga...@lists.debian.org
> Usertags: loong64
> 
> Dear maintainers,
> 
> For loong64 there is 1 phenomenon in the Debian Package Auto-Building 
> environment.
> Using the build status of python-maturin as a example,
> ```
> Dependency installability problem for python-maturin on loong64:
> python-maturin build-depends on:
> - librust-configparser-dev:loong64
> librust-configparser-dev depends on:
> - librust-async-std-1+default-dev:loong64 (>= 1.12.0-~~) | 
> librust-async-std-1+default-dev:loong64 (>= 1.12.0-~~)
> librust-async-std-dev depends on missing:
> - librust-async-io-2+default-dev:loong64
> ```
> The librust-async-std-dev is built in X86 buildd ENV, please see 
> https://buildd.debian.org/status/package.php?p=rust-async-std&suite=sid
> But when installing librust-async-std-dev, it depends on 
> librust-async-io-2+default-dev.
> I didn't find the package librust-async-io-2+default-dev in 
> X86/loong64/others arch.
> 
> Please help us to solve the above question.
> BTW, the package librust-async-io-2+default-dev blocked compilation of 
> 29 packages, provide an example,
> ```
> 94 pandoc:loong64
> 41 coq:loong64
> 34 g++-14:loong64
> 32 gnuplot-data:loong64
> 32 gnat-12:loong64
> 29 librust-async-io-2+default-dev:loong64 //Note that
> 29 libopencv-dev:loong64
> 27 libappstream4:loong64
> ```

As you write yourself, librust-async-std-dev depends on
librust-async-io-2+default-dev which is missing from loong64:

https://buildd.debian.org/status/package.php?p=rust-async-io

The problem is not in src:rust-async-std but in the (build of)
src:rust-async-io.


Hope that helps.

 - Jonas

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

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

signature.asc
Description: signature

Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255

[Joachim Zobel]

Control: tags -moreinfo

Hi Tobias.

Thanks for looking into the package.

Am Donnerstag, dem 22.02.2024 um 22:58 +0100 schrieb Tobias Frost:
> d/source/lintian-overrides
>  - delete the overrides, seems to be some remnant of earlier packaging.
> 
> d/DEBIAN_RELEASE.txt
>  - delete this file; the information contained in this files would not
>be a process how to create a package for Debian. (and if you need a
>file describing certain unusal aspects of the Debian packaging, it
>would be README.source (see Debian Policy §4.14)
>I recommend checking out git-buildpackage:
>https://honk.sigxcpu.org/piki/projects/git-buildpackage/ 
>https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/
>- remove Debian_release.patch -- this is not needed, you work with
>your debian/ directory and evolve it, you do not patch it when you
>create a new version. 
> 
> d/control
>  - specify Rules-Require-Root
>  - you manually depend on libsml1. Can you expand why this is needed?
>  - Build-Depend: s/pkg-config/pkgconf
>  - remove versions from the versioned build dependencies, if the
>debpendency is already fulfilled in oldstable:
>- libjson-c-dev, libcurl4-openssl-dev, 
> 
> 
> d/postinst / postrm
>  - When you create a user, it should start with "_" - see policy 9.2.1
>- Another option might be using systemd's DynamicUser feature to 
>  create the user at runtime. (bonus: some hardening for free.)
>- there's systemd-sysuser (works also without systemd as init system)
>  to use sysusers.d 
>- do not delete users/groups on package removal. 

All changes have been done. In addition the repository has been moved
to DEP-14 layout.

Sincerely,
Joachim

Bug#1065455: additional information

[tony mancill]

On Thu, Mar 07, 2024 at 03:31:26PM +1300, Vladimir Petko wrote:
> Dear Maintainers,
> 
> I have mistakenly submitted it as a Java 21 issue as it seems to be
> caused by commons-compress 1.25.
> Would it be possible to consider a merge request[1] that addresses this issue?
> 
> Best Regards,
>  Vladimir.
> 
>  [1] https://salsa.debian.org/java-team/libapache-poi-java/-/merge_requests/2

Thank you for the MR - applied, and I will upload shortly.

Bug#1064748: guix: FTBFS: In procedure canonicalize-path: No such file or directory

[Vagrant Cascadian]

Control: forwarded 1064748 https://debbugs.gnu.org/69518
Control: tags 1064748 confirmed

The actual failed tests are:

test-name: fold-available-packages with/without cache
test-name: find-packages-by-name with cache
test-name: find-packages-by-name + version, with cache
test-name: find-package-locations with cache

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1065397: RFS: libunistring/1.2-1 -- Unicode string library for C

[Boyuan Yang]

Control: tags -1 +moreinfo
X-Debbugs-CC: debian@jff.email

Hi,

On Sun, 03 Mar 2024 21:24:43 +0100 =?ISO-8859-1?Q?J=F6rg_Frings-F=FCrst?= 
 wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "libunistring":
> 
>  * Package name : libunistring
>    Version  : 1.2-1
>    Upstream contact : Bruno Haible 
>  * URL  : https://www.gnu.org/software/libunistring/
>  * License  : GPL-2+ with distribution exception, Expat and GPL-2+, 
>   LGPL-3+ or GPL-2+, FreeSoftware, GPL-3+, GPL-3+ or 
>   GFDL-NIV-1.2+, X11, GPL-2+ with distribution exception, 
>   GPL-2+
>  * Vcs  : https://git.jff.email/cgit/libunistring.git
>    Section  : libs
> 
> The source builds the following binary packages:
> 
>   libunistring-dev - Unicode string library for C - development files
>   libunistring5 - Unicode string library for C
> 
> To access further information about this package, please visit the following
> URL:
> 
>   https://mentors.debian.net/package/libunistring/
> 
> Alternatively, you can download the package with 'dget' using this command:
> 
>  dget -x 
>https://mentors.debian.net/debian/pool/main/libu/libunistring/libunistring_1.2-1.dsc
> 
> or from 
> 
>  git https://git.jff.email/cgit/libunistring.git/?h=release%2Fdebian%2F1.2-1
> 
> 
> Changes since the last upload:
> 
>  libunistring (1.2-1) unstable; urgency=medium
>  .
>    * New upstrem release.
>  - Refresh / Rebuild symbols file.
>    * debian/copyright:
>  - Add 2024 to myself.
>  - Refresh uploader copyright years.
>    * Remove unused patches:
>  - debian/patches/0100-float-endian-detection.patch.

Having #MISSING# in .symbols file is a red flag. It is a strong indication that
the library is breaking API explicitly.

Please check again and work with upstream to persue bumping SONAME together
with API/ABI breakage. This is especially important given large number
of reverse dependencies.

Thanks,
Boyuan Yang


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

Bug#1061718: dpkg: Please add Kali Linux to the list of distros with a urs-merged layout

[Arnaud Rebillout]

Hello!

On 07/03/2024 10:15 am, Guillem Jover wrote:

Hi!

On Mon, 2024-01-29 at 11:21:32 +0700, Arnaud Rebillout wrote:

Package: dpkg
Version: 1.22.4
Severity: normal
User: de...@kali.org
Usertags: origin-kali
Kali Linux is a rolling distro based on Debian testing. We go with a
merged-usr layout for a while now, and therefore with patch away the
warning message regarding merged-usr-via-aliased-dirs. We also don't
install dpkg-fsys-usrunmess anymore, since dpkg 1.22.4.

Please find attached a patch that adds Kali to the list of distros with
a usr-merged layout, along Debian and Ubuntu.

Thanks for the patch! Sorry, it seems this has fallen through the
cracks. At the time I received this I looked into adding support for
some new field in the origins file so that then downstreams would not
need to patch dpkg at all, but got stuck with how to name it, and
whether to make it a boolean or contain a set of values for things to
not warn or similar to not make it so specific, contrast something
like:

   Vendor: Kali
   ...
   Show-Usrmerge-Warnings: no

versus something like:

   Vendor: Kali
   ...
   Dpkg-Suppress-Warnings: usrmerge

or similar. But other ideas welcome, although now that I tried to
name the suppress field, it's starting to grow on me. In any case it
seemed preferable to try to come up with a generic solution, and
assumed that as you probably had already made this change in your
distribution source, this was not urgent. But if this is the only
delta you have I'd be fine merging something like the patch that you
provided for now until a more generic solution is implemented.


What prompted me to submit a patch is that something changed in dpkg 
1.22.4, and I had to track what exactly in order to rework my patch: 
https://gitlab.com/kalilinux/packages/dpkg/-/commit/41a91264


So I thought, it I can get this upstream, that will save me the trouble 
in the future :)


This being said, there's no urgency to merge that, and we have some more 
(minor) delta in dpkg, so we need to carry a fork anyway.


As for the "best" solution, from an outsider, a field such as 
"Dpkg-Suppress-Warnings: usrmerge" looks nice and clean, and it's surely 
nice for downstreams if they can configure dpkg's behavior without 
having to fork it. But how many downstreams would use it? I can't say. 
Is it worth the cost of developing this feature? You know better than me 
how much work this feature represents.


From Kali's side, we're fine having a lightweight fork.

Best,

--
Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1037111: ITP: pipewire-module-xrdp -- xRDP module for the PipeWire sound server

[Arnaud Rebillout]

Some update on that:

* New upstream URL: https://github.com/neutrinolabs/pipewire-module-xrdp
* Latest discussion regarding including the package in Debian: 
https://github.com/neutrinolabs/pipewire-module-xrdp/issues/3


At this point it seems that this module will not be included in pipewire 
upstream, and it will be maintained by neutrinolabs (which is the 
upstream for xrdp already).


Upstream just tagged a v0.1 release, now is a good time to package it 
for Debian.


--
Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1065429: dpkg -s: spurious error "dpkg-query: error: --status needs a valid package name"

[Vincent Lefevre]

On 2024-03-07 03:34:08 +0100, Guillem Jover wrote:
> > "apt-cache show libc6-dev" also lists this package.
> 
> apt behaves differently, this has been also a known discrepancy, but
> then they operate in general differently when it comes to their CLI
> arguments anyway.

The difference is bad for the user, making simple copy-paste
impossible, and usage more difficult: the user doesn't know
in advance whether the package name given by apt needs to be
completed for dpkg (systematically adding the main architecture
does not work for "Architecture: all" packages).

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

Bug#1059150: No longer works with signing subkeys

[Guillem Jover]

Hi!

On Wed, 2023-12-20 at 23:59:31 +0100, Guillem Jover wrote:
> On Wed, 2023-12-20 at 15:30:24 +, Steve McIntyre wrote:
> > diff --git a/src/openpgp-gpg.c b/src/openpgp-gpg.c
> > index 4c29b7f..97ec3a4 100644
> > --- a/src/openpgp-gpg.c
> > +++ b/src/openpgp-gpg.c
> > @@ -241,6 +242,7 @@ gpg_getKeyID(const char *keyring, const char *match_id)
> > continue;
> >  if (strcmp(uid, match_id) != 0) {
> >  free(uid);
> > +   state = KEYID_SUB;
> > continue;
> > }
> >  free(uid);
> 
> I think the problem with this is that if the first uid does not match,
> then it will then switch to looking for a new fingerprint line, which
> might then omit some valid uids.
> 
> I've prepared a change based on this at:
> 
>   
> https://git.hadrons.org/cgit/debian/dpkg/debsig-verify.git/log/?h=pu/openpgp-subkey
> 
> With the assumption that one would define the policy and keyrings
> paths based on the subkey fingerprint and not the primary public
> certificate fingerprint, because otherwise some of the other matches
> cannot easily match, such as uid-based ones. But wanted to check with
> you whether that's the case before merging. Otherwise I can try to see
> how to support all the various cases.

I assume you have had no time to look into this, but I'd like to make
sure the above branch fixes your issue before merging, and potentially
preparing a backport for stable. :)

Thanks,
Guillem

Bug#1061718: dpkg: Please add Kali Linux to the list of distros with a urs-merged layout

[Guillem Jover]

Hi!

On Mon, 2024-01-29 at 11:21:32 +0700, Arnaud Rebillout wrote:
> Package: dpkg
> Version: 1.22.4
> Severity: normal
> User: de...@kali.org
> Usertags: origin-kali

> Kali Linux is a rolling distro based on Debian testing. We go with a
> merged-usr layout for a while now, and therefore with patch away the
> warning message regarding merged-usr-via-aliased-dirs. We also don't
> install dpkg-fsys-usrunmess anymore, since dpkg 1.22.4.
> 
> Please find attached a patch that adds Kali to the list of distros with
> a usr-merged layout, along Debian and Ubuntu.

Thanks for the patch! Sorry, it seems this has fallen through the
cracks. At the time I received this I looked into adding support for
some new field in the origins file so that then downstreams would not
need to patch dpkg at all, but got stuck with how to name it, and
whether to make it a boolean or contain a set of values for things to
not warn or similar to not make it so specific, contrast something
like:

  Vendor: Kali
  ...
  Show-Usrmerge-Warnings: no

versus something like:

  Vendor: Kali
  ...
  Dpkg-Suppress-Warnings: usrmerge

or similar. But other ideas welcome, although now that I tried to
name the suppress field, it's starting to grow on me. In any case it
seemed preferable to try to come up with a generic solution, and
assumed that as you probably had already made this change in your
distribution source, this was not urgent. But if this is the only
delta you have I'd be fine merging something like the patch that you
provided for now until a more generic solution is implemented.

Thanks,
Guillem

Bug#1065572: llm packaging progress

[Antoine Beaupré]

So I'm running the llm Debian package locally. I had to package two
deps, for which I have filed ITPs as well (1065576: python-ulid,
1065578: python-sqlite-migrate). The former is a solid, globally useful
library, but I'm less sure about the latter - it seems more something
built just for that project, and that's explicitly not ready for
production. But, alas, that is done as well.

The code is on salsa:

https://salsa.debian.org/python-team/packages/llm
https://salsa.debian.org/python-team/packages/python-ulid
https://salsa.debian.org/python-team/packages/sqlite-migrate

I'm waiting a bit to see if people kick back on debian-devel before
going ahead with new. I'll also test this a little more, possibly trying
out llama.cpp if i can find the cycles.

So far this works pretty well. It's really nice to not have to use the
browser to talk to the engines, and having the ability to just pipe
stuff in and out of there is really useful.

a.

-- 
Advertisers, not governments, are the primary censors of media content 
in the United States today.
- C. Edwin Baker

Bug#1065588: O: flameshot -- Powerful yet simple-to-use screenshot software

[Boyuan Yang]

Package: wnpp
Control: affects -1 + src:flameshot
X-Debbugs-Cc: flames...@packages.debian.org
X-Debbugs-Cc: by...@debian.org
Severity: normal

I intend to orphan the flameshot package. Help from someone who is more familiar
with upstream Wayland support is needed to get flameshot fully support Debian's
wayland environment.

The package description is:
 Flameshot is a powerful yet simple-to-use screenshot software.
 Notable features include customizable appearance, in-app screenshot editing,
 D-Bus interface, experimental GNOME/KDE Wayland support, integration with
 Imgur and support for both GUI and CLI interface.

Thanks,
Boyuan Yang


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

Bug#1065439: dpkg-buildflags: add HIPFLAGS to supported flags

[Guillem Jover]

Hi!

On Mon, 2024-03-04 at 10:59:36 -0700, Cordell Bloor wrote:
> Package: dpkg-dev
> Version: 1.22.5
> Severity: wishlist
> X-Debbugs-Cc: c...@slerp.xyz, debian...@lists.debian.org

> When packaging the AMD ROCm GPU libraries for Debian, we are currently
> using CXX=hipcc or CXX=clang++ to build libraries written in HIP as if
> they were written in C++.

I guess we should also add HIPCXX (defaulting to -hipcc
and HIPCXX_FOR_BUILD (defaulting to -hipcc when cross
compiling, otherwise to hipcc) like with the other toolchains? An
apt-file query seems to indicate thee hipcc package provides no
triplet-qualified toolchains? Which means automatic cross-compiling
is going to be painful given our current infrastructure.

If support for this is really missing from the looks of it, we can
always postpone adding the compiler tool variables for now until this
is implemented (we can still add the HIPFLAGS variables though). I'm
CCing the debian-cross list for further insight.

> This necessitates filtering out flags that are not supported when
> building HIP language code. For example, the rocsparse d/rules include:
> 
> export CXX=hipcc
> export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-fortify optimize=-lto
> 
> # filter incompatible options from affecting device code
> CXXFLAGS := $(subst -fstack-protector-strong,-Xarch_host 
> -fstack-protector-strong,$(CXXFLAGS))
> CXXFLAGS := $(subst -fcf-protection,-Xarch_host 
> -fcf-protection,$(CXXFLAGS))
> 
> In the lines above, we are prepending `-Xarch_host` to prevent certain
> flags from being applied to device code (i.e., GPU code) while still
> ensuring that they are applied to host code (i.e., CPU code).
> 
> However, there is HIP language support in CMake. We should use it!
> dpkg-buildflags should set HIPFLAGS [1]. The CXXFLAGS make a good
> starting place for the HIPFLAGS values, but `-Xarch_host` should be
> added to `-fstack-protector-strong` and `-fcf-protection`, like in the
> example above.

> [1]: https://cmake.org/cmake/help/v3.28/envvar/HIPFLAGS.html

It would be helpful if you could verify whether all flags currently
added to CXXFLAGS would work for HIPFLAGS. You can check for all such
instances by searching for either default_flags, @compiler_flags and
CXXFLAGS from:

  $ perldoc -m Dpkg::Vendor::Debian

Once we have the complete list, I'm happy to add the handling for
these flags in the code.

Thanks,
Guillem

Bug#1065449: trapperkeeper-webserver-jetty9-clojure: FTBFS with default Java 21

[Vladimir Petko]

Dear Maintainers,

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

Best Regards,
 Vladimir.

 [1] 
https://salsa.debian.org/clojure-team/trapperkeeper-webserver-jetty9-clojure/-/merge_requests/1

Bug#1065587: rust-polling: Please try to rebuild rust-polling for loong64

[zhangdandan]

Source: rust-polling
Version: 3.4.0-1
Severity: wishlist
Tags: help
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

The package librust-async-io-2+default-dev blocked compilation of 29 
packages in the Debian Package Auto-Building environment.

The dependency state of rust-async-io is as follows,
```
Dependency installability problem for rust-async-io on loong64:
rust-async-io build-depends on missing:
- librust-polling-3+default-dev:loong64
```
After analyzing the package rust-async-io, I found out that it's because 
compilation of rust-polling failed.
The build log of rust-polling can be found at 
https://buildd.debian.org/status/logs.php?pkg=rust-polling&ver=3.4.0-1&arch=loong64.


I have built the rust-polling successfully in my local loong64 
environment, without modifications required.

```
..
   dh_md5sums -O--buildsystem=cargo
   dh_builddeb -O--buildsystem=cargo
dpkg-deb: building package '../librust-polling-dev_3.4.0-1_loong64.deb' 
in 'librust-polling-dev'。

dpkg-genbuildinfo -O../rust-polling_3.4.0-1_loong64.buildinfo
dpkg-genchanges -O../rust-polling_3.4.0-1_loong64.changes

```
Please try to rebuild rust-polling for loong64 in the Debian Package 
Auto-Building environment.

If you have any questions, you can contact me at any time.

thanks,
Dandan Zhang

Bug#1065455: additional information

[Vladimir Petko]

Dear Maintainers,

I have mistakenly submitted it as a Java 21 issue as it seems to be
caused by commons-compress 1.25.
Would it be possible to consider a merge request[1] that addresses this issue?

Best Regards,
 Vladimir.

 [1] https://salsa.debian.org/java-team/libapache-poi-java/-/merge_requests/2

Bug#1065570: Interface border is replaced by ascii chars

[x11r]

Sorry, I don't mean to make you chase information. The only other difference is 
our pxelinux.cfg. We are using a minimal pxelinux in order to bypass the 
interactive menus with the following content.

default linux
label linux
  kernel debian-installer/amd64/linux
  append initrd=debian-installer/amd64/initrd.gz ip=dhcp auto=enable 
language=en country=US locale=en_US.UTF-8 keymap=ansi hostname=debian domain="" 
url=tftp://10.0.0.1/preseed.cfg

I attempted a minimal repro using a command similar to yours but using 
"qemu-system-x86_64 -enable-kvm" (because I can't seem to find the package that 
has the kvm bin) and did not get the bug. I know it's not isolated to 
VirtualBox because I have video of the bug happening on a bare metal install 
(https://youtu.be/-OiJVJp8SxQ bug occurs at about 1:05).

After some digging, I saw that the original netboot.tar.gz had pxelinux.cfg 
symlinked to debian-installer/amd64/pxelinux.cfg which has a default file 
symlinked to ../boot-screens/syslinux.cfg (realpath 
debian-installer/amd64/boot-screens/syslinux.cfg). The QEMU reproduction I 
tried I edited that file directly, whereas the other tests I've done a script 
has replaced it pxelinux.cfg/default with a new file (removing the symlink 
entirely). I modified our script-generated tftp directory (for VirtualBox) to 
fix the symlink (putting the above contents into the 
debian-installer/amd64/boot-screens/syslinux.cfg file directly) and that didn't 
fix the issue (I thought I was onto something).

I reset the TFTP dir to just the preseed.cfg (so not our pxelinux.cfg) and 
input the kernel parameters in the default menu. One thing I noticed was the 
default parameters include VGA=788 (which our menu above was missing). This 
appears to have fixed the issue. I ran the QEMU test mentioned earlier using 
the pxelinux.cfg above, but qualitatively it looked like it was running in a 
different graphical mode. With this information, I think this may be related to 
the absence of the "VGA=" parameter in our boot parameters. I see there's an 
existing bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969944 regarding 
the same parameter, but I don't see enough information there to say it's the 
same issue.

That's all the relevant information I can think of for now. Maybe see if your 
KVM is able to reproduce using the pxelinux.cfg above or removing the "VGA=788" 
parameter from the kernel command line? 

On Wednesday, March 6th, 2024 at 6:57 PM, Samuel Thibault 
 wrote:

> Hello,
> 
> x11r, le mer. 06 mars 2024 23:29:24 +, a ecrit:
> 
> > The mangling does not happen immediately. It happens after the "Installing 
> > the base system" step (not sure what the step after that is supposed to 
> > be). Here's a pastebin of the preseed.cfg: https://pastebin.com/K7vwkpMu
> 
> 
> I still cannot reproduce with:
> 
> mkdir tmp
> cd tmp
> wget 
> https://deb.debian.org/debian/dists/bookworm/main/installer-amd64/current/images/netboot/netboot.tar.gz
> tar xf netboot.tar.gz
> wget -O preseed.cfg https://pastebin.com/raw/K7vwkpMu
> dd < /dev/zero > disk.img bs=1M count=1 seek=1
> 
> kvm -net nic -net user,tftp=$PWD,bootfile=pxelinux.0 -drive 
> file=disk.img,cache=unsafe -m 1G
> 
> and appending
> 
> ip=dhcp auto=enable language=en country=US locale=en_US.UTF-8 keymap=ansi 
> hostname=debian domain="" url=tftp://10.0.2.2/preseed.cfg
> 
> on the boot kernel command line. It does show up fine up to the reboot
> step.
> 
> Any idea what is different with your case? (except the virtualization
> software)
> 
> Samuel

Bug#1065586: rust-async-std: Missing installation dependency librust-async-io-2+default-dev for librust-async-std-dev

[zhangdandan]

Package: librust-async-std-dev
Version: 1.12.0-17
Severity: wishlist
Tags: help
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

For loong64 there is 1 phenomenon in the Debian Package Auto-Building 
environment.

Using the build status of python-maturin as a example,
```
Dependency installability problem for python-maturin on loong64:
python-maturin build-depends on:
- librust-configparser-dev:loong64
librust-configparser-dev depends on:
- librust-async-std-1+default-dev:loong64 (>= 1.12.0-~~) | 
librust-async-std-1+default-dev:loong64 (>= 1.12.0-~~)

librust-async-std-dev depends on missing:
- librust-async-io-2+default-dev:loong64
```
The librust-async-std-dev is built in X86 buildd ENV, please see 
https://buildd.debian.org/status/package.php?p=rust-async-std&suite=sid
But when installing librust-async-std-dev, it depends on 
librust-async-io-2+default-dev.
I didn't find the package librust-async-io-2+default-dev in 
X86/loong64/others arch.


Please help us to solve the above question.
BTW, the package librust-async-io-2+default-dev blocked compilation of 
29 packages, provide an example,

```
94 pandoc:loong64
41 coq:loong64
34 g++-14:loong64
32 gnuplot-data:loong64
32 gnat-12:loong64
29 librust-async-io-2+default-dev:loong64 //Note that
29 libopencv-dev:loong64
27 libappstream4:loong64
```

thanks,
Dandan Zhang

Bug#1061025: Additional information

[Vladimir Petko]

Dear Maintainers,

 I am wondering if the acceptable fix for this failure would be
disabling slf4j backend in commons-logging? This will break circular
dependency and allow projects that use commons-logging and slf4j to
build. I have created a MR with the patch[1].

Best Regards,
 Vladimir.

[1] 
https://salsa.debian.org/java-team/libcommons-logging-java/-/merge_requests/7

Bug#1065585: linux-headers-6.7.7-amd64: Depends: linux-compiler-gcc-13-x86 -> linux-image-6.7.7-amd64, gcc-13 => uninstallable on x32

[наб]

Source: linux
Version: 6.7.7-1
Severity: grave
Justification: user security hole

Dear Maintainer,

(Opting for grave/usersec because naturally updated kernels
 fix security vulnerabilities, but actually i think i can't update the
 kernel and that's grave, security be damned.)

Observe:
  $ sudo apt install --no-install-recommends linux-headers-amd64
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:

  The following packages have unmet dependencies:
   binutils-x86-64-linux-gnu:amd64 : Depends: libgcc-s1:amd64 (>= 4.2) but it 
is not going to be installed
 Depends: libjansson4:amd64 (>= 2.14) but 
it is not going to be installed
 Depends: libstdc++6:amd64 (>= 13.1) but it 
is not going to be installed
   cpp-13-x86-64-linux-gnu:amd64 : Depends: libgmp10:amd64 (>= 2:6.3.0+dfsg) 
but it is not going to be installed
   Depends: libisl23:amd64 (>= 0.15) but it is 
not going to be installed
   Depends: libmpc3:amd64 (>= 1.1.0) but it is 
not going to be installed
   Depends: libmpfr6:amd64 (>= 3.1.3) but it is 
not going to be installed
   gcc-13-x86-64-linux-gnu:amd64 : Depends: libcc1-0:amd64 (>= 13.2.0-18) but 
it is not going to be installed
   Depends: libgcc-s1:amd64 (>= 3.0) but it is 
not going to be installed
   Depends: libgmp10:amd64 (>= 2:6.3.0+dfsg) 
but it is not going to be installed
   Depends: libisl23:amd64 (>= 0.15) but it is 
not going to be installed
   Depends: libmpc3:amd64 (>= 1.1.0) but it is 
not going to be installed
   Depends: libmpfr6:amd64 (>= 3.1.3) but it is 
not going to be installed
   Depends: libstdc++6:amd64 (>= 5) but it is 
not going to be installed
   libc6:amd64 : Depends: libgcc-s1:amd64 but it is not going to be installed
   libgcc-13-dev:amd64 : Depends: libgcc-s1:amd64 (>= 13.2.0-18) but it is not 
going to be installed
 Depends: libgomp1:amd64 (>= 13.2.0-18) but it is not 
going to be installed
 Depends: libitm1:amd64 (>= 13.2.0-18) but it is not 
going to be installed
 Depends: libatomic1:amd64 (>= 13.2.0-18) but it is not 
going to be installed
 Depends: libasan8:amd64 (>= 13.2.0-18) but it is not 
going to be installed
 Depends: libubsan1:amd64 (>= 13.2.0-18) but it is not 
going to be installed
 Depends: libquadmath0:amd64 (>= 13.2.0-18) but it is 
not going to be installed
   libgprofng0:amd64 : Depends: libgcc-s1:amd64 (>= 3.3.1) but it is not going 
to be installed
   Depends: libstdc++6:amd64 (>= 13.1) but it is not going 
to be installed
   libhwasan0:amd64 : Depends: gcc-14-base:amd64 (= 14-20240303-1) but it is 
not going to be installed
  Depends: libgcc-s1:amd64 (>= 3.3) but it is not going to 
be installed
   liblsan0:amd64 : Depends: gcc-14-base:amd64 (= 14-20240303-1) but it is not 
going to be installed
Depends: libgcc-s1:amd64 (>= 3.3) but it is not going to be 
installed
   libtsan2:amd64 : Depends: gcc-14-base:amd64 (= 14-20240303-1) but it is not 
going to be installed
Depends: libgcc-s1:amd64 (>= 3.4) but it is not going to be 
installed
   linux-headers-6.7.7-amd64:amd64 : Depends: linux-kbuild-6.7.7:amd64
  E: Unable to correct problems, you have held broken packages.
or
  $ sudo apt install --no-install-recommends linux-headers-amd64 
linux-kbuild-6.7.7:x32
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:

  The following packages have unmet dependencies:
   binutils-x86-64-linux-gnu:amd64 : Depends: libgcc-s1:amd64 (>= 4.2) but it 
is not installable
 Depends: libjansson4:amd64 (>= 2.14) but 
it is not going to be installed
 Depends: libstdc++6:amd64 (>= 13.1) but it 
is not going to be installed
   cpp-13-x86-64-linux-gnu:amd64 : Depends: libgmp10:amd64 (>= 2:6.3.0+dfsg) 
but it is not going to be 

Bug#1065584: dh_update_autotools_config: cp: warning: behavior of -n is non-portable and may change…

[Thorsten Glaser]

Package: debhelper
Version: 13.14.1
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

   dh_update_autotools_config -a -O--builddirectory=debian/build
cp: warning: behavior of -n is non-portable and may change in future; use 
--update=none instead
cp: warning: behavior of -n is non-portable and may change in future; use 
--update=none instead

(showing up in build logs)

Bug#1065570: Interface border is replaced by ascii chars

[Samuel Thibault]

Hello,

x11r, le mer. 06 mars 2024 23:29:24 +, a ecrit:
> The mangling does not happen immediately. It happens after the "Installing 
> the base system" step (not sure what the step after that is supposed to be). 
> Here's a pastebin of the preseed.cfg: https://pastebin.com/K7vwkpMu

I still cannot reproduce with:

mkdir tmp
cd tmp
wget  
https://deb.debian.org/debian/dists/bookworm/main/installer-amd64/current/images/netboot/netboot.tar.gz
tar xf netboot.tar.gz
wget -O preseed.cfg https://pastebin.com/raw/K7vwkpMu
dd < /dev/zero > disk.img bs=1M count=1 seek=1
kvm -net nic -net user,tftp=$PWD,bootfile=pxelinux.0 -drive 
file=disk.img,cache=unsafe -m 1G

and appending

ip=dhcp auto=enable language=en country=US locale=en_US.UTF-8 keymap=ansi 
hostname=debian domain="" url=tftp://10.0.2.2/preseed.cfg

on the boot kernel command line. It does show up fine up to the reboot
step.

Any idea what is different with your case? (except the virtualization
software)

Samuel

Bug#1065583: quodlibet: Clicking cover art stifles keyboard input & any clicks outside the image - accessibility nightmare

[David Z]

Package: quodlibet
Version: 4.5.0-2
Severity: normal
Tags: upstream a11y
X-Debbugs-Cc: unimportantdav...@gmail.com

To reproduce:

1. Start playing a track that causes some associated album art to be displayed
in the small icon at right.

2. Click that small album art thumbnail to enlarge the image.

3. Attempt to control Quod Libet using either the keyboard or mouse in any way
other than a mouse-click inside the enlarged displayed image (including
important "meta" controls like minimizing the window, pressing Ctrl+Q to
attempt to Quit, etc.). Optionally, attempt expected ways to close the album
art preview like pressing Esc, Space, or Enter. Such controls do not work.

4. Control can be regained only by clicking within the enlarged album art
display, or by pressing Ctrl+W, and as far as I can tell, absolutely no other
means.


Proposed actions:

1. The enlarged album art display should be very easy to close/dismiss,
including by pressing the keys Esc, Space, or Enter, and possibly even by
pressing any key whatsoever. This is especially important for disabled users
who may use accessibility tools and alternative input devices to control their
systems, and significantly also those who are reliant on standard keyboard
inputs and shortcuts.

2. The album art should also be closed/dismissed when a user clicks outside of
the enlarged image, or, alternatively, the functions of Quod Libet not covered
by the enlarged image should be able to be operated with mouse clicks, if they
are not covered, though my preference would be the former.

3. Having the album art enlarged should not prevent windowing system controls
(minimize button, "X" close button, etc.) from being clicked.

Thanks so much for contributing to the best music player on the planet.


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

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

Versions of packages quodlibet depends on:
ii  exfalso  4.5.0-2
ii  gir1.2-gst-plugins-base-1.0  1.22.0-3+deb12u1
ii  gir1.2-gstreamer-1.0 1.22.0-2
ii  gir1.2-keybinder-3.0 0.3.2-1.1
ii  gstreamer1.0-alsa1.22.0-3+deb12u1
ii  gstreamer1.0-plugins-base1.22.0-3+deb12u1
ii  gstreamer1.0-plugins-good1.22.0-5+deb12u1
ii  gstreamer1.0-plugins-ugly1.22.0-2+deb12u1
ii  python3  3.11.2-1+b1

Versions of packages quodlibet recommends:
ii  gir1.2-gtksource-3.0   3.24.11-2+b1
ii  gir1.2-webkit2-4.0 2.42.5-1~deb12u1
ii  gnome-shell [notification-daemon]  43.9-0+deb12u1
ii  python3-dbus   1.3.2-4+b1
ii  python3-pyinotify  0.9.6-2

Versions of packages quodlibet suggests:
ii  gstreamer1.0-plugins-bad  1.22.0-4+deb12u5

-- no debconf information

Bug#1060224: bluetoothd started segfaulting

[Jameson Graef Rollins]

severity 1060224 important
thanks

I'm seeing similar issues that I suspect are from the same underlying
bug.  This happens whenever I try to connect any or my devices via
bluetooth (all audio devices):

Mar 06 15:19:36 servo kernel: bluetoothd[52214]: segfault at 558c06f488e9 ip 
55895d916375 sp 7ffec8852150 error 4 in bluetoothd[55895d8f4000+ec000] 
likely on CPU 3 (core 3, socket 0)
Mar 06 15:19:36 servo kernel: Code: 00 31 c0 e9 54 ff ff ff 66 66 2e 0f 1f 84 
00 00 00 00 00 66 90 f3 0f 1e fa 41 55 41 54 55 53 48 83 ec 08 48 8b 2a 48 8b 
7a 08 <48> 8b 45 20 4c 8b ad 88 00 00 00 4c 8b 20 48 85 ff 74 19 c7 47 08
Mar 06 15:19:36 servo systemd[1]: bluetooth.service: Main process exited, 
code=killed, status=11/SEGV
Mar 06 15:19:36 servo systemd[1]: bluetooth.service: Failed with result 
'signal'.

Note the kernel code is the same as in Joey's report (fwiw).

I'm increasing the severity because bluetooth is currently completely
unusable for me.

If anyone has any suggestions for settings tweaks I could try it would
be greatly appreciated.

Thanks for maintaining!

jamie.


On Sun, 7 Jan 2024 16:26:43 -0400 Joey Hess  wrote:
> Package: bluez
> Version: 5.71-1
> Severity: normal
> 
> On upgrade to this version, bluetoothd started segfaulting frequently:
> 
> [   59.628624] input: Avantree SP750 (AVRCP) as /devices/virtual/input/input26
> [   97.073761] bluetoothd[838]: segfault at 561314652a23 ip 56167406a375 
> sp 7fffb128a200 error 4 in bluetoothd[561674048000+ec000] likely on CPU 
> 11 (core 5, socket 0)
> [   97.073799] Code: 00 31 c0 e9 54 ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 
> 66 90 f3 0f 1e fa 41 55 41 54 55 53 48 83 ec 08 48 8b 2a 48 8b 7a 08 <48> 8b 
> 45 20 4c 8b ad 88 00 00 00 4c 8b 20 48 85 ff 74 19 c7 47 08
> [  219.074962] input: Avantree SP750 (AVRCP) as /devices/virtual/input/input27
> [  241.708695] bluetoothd[4477]: segfault at 55c5369dc8d4 ip 55c069877375 
> sp 7fff8f7198c0 error 4 in bluetoothd[55c069855000+ec000] likely on CPU 0 
> (core 0, socket 0)
> [  241.708725] Code: 00 31 c0 e9 54 ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 
> 66 90 f3 0f 1e fa 41 55 41 54 55 53 48 83 ec 08 48 8b 2a 48 8b 7a 08 <48> 8b 
> 45 20 4c 8b ad 88 00 00 00 4c 8b 20 48 85 ff 74 19 c7 47 08
> 
> To reproduce this crash all I have to do is:
> 
> 1. connect to the bluetooth device
> 2. use it briefly
> 3. stop using it and wait 5 seconds
> 
> Based on the timing, the crash probably occurs when it's put into power save
> mode.
> 
> I have downgraded to 5.70-1.1, which does not have this problem.
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 6.6.9-amd64 (SMP w/12 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages bluez depends on:
> ii  dbus [default-dbus-system-bus]  1.14.10-3+b1
> ii  init-system-helpers 1.66
> ii  kmod31-1
> ii  libasound2  1.2.10-3
> ii  libc6   2.37-13
> ii  libdbus-1-3 1.14.10-3+b1
> ii  libdw1  0.190-1+b1
> ii  libglib2.0-02.78.3-1
> ii  libreadline88.2-3
> ii  libudev1255.2-3
> ii  udev255.2-3
> 
> bluez recommends no packages.
> 
> Versions of packages bluez suggests:
> pn  pulseaudio-module-bluetooth  
> 
> -- Configuration Files:
> /etc/bluetooth/main.conf changed:
> [General]
> Experimental = true

Bug#1065570: Interface border is replaced by ascii chars

[x11r]

The mangling does not happen immediately. It happens after the "Installing the 
base system" step (not sure what the step after that is supposed to be). Here's 
a pastebin of the preseed.cfg: https://pastebin.com/K7vwkpMu

On Wednesday, March 6th, 2024 at 6:06 PM, Samuel Thibault 
 wrote:

> Hello,
>
> x11r, le mer. 06 mars 2024 22:39:23 +, a ecrit:
>
> > The machine is PXE booted with the kernel parameters: 
> > initrd=debian-installer/amd64/initrd.gz ip=dhcp auto=enable language=en 
> > country=US locale=en_US.UTF-8 keymap=ansi hostname=debian domain="" 
> > url=tftp://10.0.0.1/preseed.cfg
> >
> > Console is accessed over VGA. VMSVGA for the VirtualBox tests we've ran and 
> > a VGA KVM for the tests on bare metal.
>
>
> I still cannot reproduce with unpacking the tarball and running
>
> kvm -net nic -net user,tftp=$PWD,bootfile=pxelinux.0 -drive -m 1G
>
> and passing the kernel parameters.
>
> Does the mangling happen right from the first screen, or after some
> steps?
>
> It could be useful to share your preseed.cfg (take care of removing any
> hardcoded password).
>
> Samuel

Bug#1065284: lucene++: diff for NMU version 3.0.9-3.2

[Sebastian Ramacher]

Control: tags 1065284 + patch

Dear maintainer,

I've prepared an NMU for lucene++ (versioned as 3.0.9-3.2). The diff
is attached to this message.

Cheers
-- 
Sebastian Ramacher
diff -Nru lucene++-3.0.9/debian/changelog lucene++-3.0.9/debian/changelog
--- lucene++-3.0.9/debian/changelog	2024-03-04 11:42:22.0 +0100
+++ lucene++-3.0.9/debian/changelog	2024-03-07 00:22:31.0 +0100
@@ -1,3 +1,10 @@
+lucene++ (3.0.9-3.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix build dependency on dpkg-dev (Closes: #1065284)
+
+ -- Sebastian Ramacher   Thu, 07 Mar 2024 00:22:31 +0100
+
 lucene++ (3.0.9-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru lucene++-3.0.9/debian/control lucene++-3.0.9/debian/control
--- lucene++-3.0.9/debian/control	2024-03-04 11:42:21.0 +0100
+++ lucene++-3.0.9/debian/control	2024-03-07 00:22:17.0 +0100
@@ -2,7 +2,7 @@
 Priority: optional
 Maintainer: Łukasz 'sil2100' Zemczak 
 Uploaders: Gianfranco Costamagna 
-Build-Depends: dpkg-dev (>> 1.22.5),
+Build-Depends: dpkg-dev (>= 1.22.5),
cmake,
debhelper-compat (= 13),
libboost-date-time-dev,

Bug#1065277: gtkmm2.4: diff for NMU version 1:2.24.5-5.2

[Sebastian Ramacher]

Control: tags 1065277 + patch

Dear maintainer,

I've prepared an NMU for gtkmm2.4 (versioned as 1:2.24.5-5.2). The diff
is attached to this message.

Cheers
-- 
Sebastian Ramacher
diff -Nru gtkmm2.4-2.24.5/debian/changelog gtkmm2.4-2.24.5/debian/changelog
--- gtkmm2.4-2.24.5/debian/changelog	2024-03-04 11:40:46.0 +0100
+++ gtkmm2.4-2.24.5/debian/changelog	2024-03-07 00:18:25.0 +0100
@@ -1,3 +1,10 @@
+gtkmm2.4 (1:2.24.5-5.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix build dependency on dpkg-dev (Closes: #1065277)
+
+ -- Sebastian Ramacher   Thu, 07 Mar 2024 00:18:25 +0100
+
 gtkmm2.4 (1:2.24.5-5.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru gtkmm2.4-2.24.5/debian/control gtkmm2.4-2.24.5/debian/control
--- gtkmm2.4-2.24.5/debian/control	2024-03-04 11:40:46.0 +0100
+++ gtkmm2.4-2.24.5/debian/control	2024-03-07 00:18:09.0 +0100
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Debian GNOME Maintainers 
 Uploaders: Emilio Pozuelo Monfort , Jeremy Bícha 
-Build-Depends: dpkg-dev (>> 1.22.5),
+Build-Depends: dpkg-dev (>= 1.22.5),
debhelper-compat (= 13),
libgtk2.0-dev (>= 2.24.0),
libglibmm-2.4-dev (>= 2.27.93),

Bug#1065265: glade: diff for NMU version 3.40.0-4.2

[Sebastian Ramacher]

Control: tags 1065265 + patch

Dear maintainer,

I've prepared an NMU for glade (versioned as 3.40.0-4.2). The diff
is attached to this message.

Cheers
-- 
Sebastian Ramacher
diff -Nru glade-3.40.0/debian/changelog glade-3.40.0/debian/changelog
--- glade-3.40.0/debian/changelog	2024-03-04 11:38:30.0 +0100
+++ glade-3.40.0/debian/changelog	2024-03-07 00:20:20.0 +0100
@@ -1,3 +1,10 @@
+glade (3.40.0-4.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix build dependency on dpkg-dev (Closes: #1065265)
+
+ -- Sebastian Ramacher   Thu, 07 Mar 2024 00:20:20 +0100
+
 glade (3.40.0-4.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru glade-3.40.0/debian/control glade-3.40.0/debian/control
--- glade-3.40.0/debian/control	2024-03-04 11:38:30.0 +0100
+++ glade-3.40.0/debian/control	2024-03-07 00:20:07.0 +0100
@@ -7,7 +7,7 @@
 Priority: optional
 Maintainer: Debian GNOME Maintainers 
 Uploaders: Emilio Pozuelo Monfort , Jeremy Bícha , Laurent Bigonville , Marco Trevisan (Treviño) , Michael Biebl 
-Build-Depends: dpkg-dev (>> 1.22.5),
+Build-Depends: dpkg-dev (>= 1.22.5),
at-spi2-core ,
dbus ,
debhelper-compat (= 13),

Bug#1065567: timedatectl does not recognize ntpsec

[Michael Biebl]

On Wed, 6 Mar 2024 15:07:24 -0600 Richard Laager  wrote:
If I'm understanding this correctly, I just need to install a file with 
the contents "ntpsec.service" to 
/usr/lib/systemd/ntp-units.d/50-ntpsec.list. That's easy enough to do.


Yeah, that's pretty much it.


Regards,
Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1065271: gsound: diff for NMU version 1.0.3-3.2

[Sebastian Ramacher]

Control: tags 1065271 + patch

Dear maintainer,

I've prepared an NMU for gsound (versioned as 1.0.3-3.2). The diff
is attached to this message.

Cheers
-- 
Sebastian Ramacher
diff -Nru gsound-1.0.3/debian/changelog gsound-1.0.3/debian/changelog
--- gsound-1.0.3/debian/changelog	2024-03-04 11:40:14.0 +0100
+++ gsound-1.0.3/debian/changelog	2024-03-07 00:16:01.0 +0100
@@ -1,3 +1,10 @@
+gsound (1.0.3-3.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix build dependency on dpkg-dev (Closes: #1065271)
+
+ -- Sebastian Ramacher   Thu, 07 Mar 2024 00:16:01 +0100
+
 gsound (1.0.3-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru gsound-1.0.3/debian/control gsound-1.0.3/debian/control
--- gsound-1.0.3/debian/control	2024-03-04 11:40:14.0 +0100
+++ gsound-1.0.3/debian/control	2024-03-07 00:15:38.0 +0100
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Debian GNOME Maintainers 
 Uploaders: Jeremy Bícha , Laurent Bigonville 
-Build-Depends: dpkg-dev (>> 1.22.5),
+Build-Depends: dpkg-dev (>= 1.22.5),
debhelper-compat (= 13),
dh-sequence-gir,
gtk-doc-tools,

Bug#1065582: debianutils: [INTL:fr] French translation for the debianutils man page

[Jean-Pierre Giraud]

Package: debianutils
Severity: wishlist
Tags: patch l10n

Hi!

Please find attached the french translation for the debianutils man
page, proofread by the debian-l10n-french mailing list contributors.

This file should be put as doc/po/fr.po in your package build tree.

Kind Regards

jipege


fr.po.xz
Description: application/xz


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

Bug#1065581: debianutils: [INTL:fr] French translation for the debianutils man page

[Jean-Pierre Giraud]

Package: debianutils
Severity: wishlist
Tags: patch l10n

Hi!

Please find attached the french translation for the debianutils man
page, proofread by the debian-l10n-french mailing list contributors.

This file should be put as doc/po/fr.po in your package build tree.

Kind Regards

jipege


fr.po.xz
Description: application/xz

Bug#1065580: debianutils: [INTL:fr] French translation for the debianutils man page

[Jean-Pierre Giraud]

Package: apt-listchanges
Severity: wishlist
Tags: patch l10n

Hi!

Please find attached the french translation for the debianutils man
page, proofread by the debian-l10n-french mailing list contributors.

This file should be put as doc/po/fr.po in your package build tree.

Kind Regards

jipege


fr.po.xz
Description: application/xz


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

Bug#1065570: Interface border is replaced by ascii chars

[Samuel Thibault]

Hello,

x11r, le mer. 06 mars 2024 22:39:23 +, a ecrit:
> The machine is PXE booted with the kernel parameters: 
> initrd=debian-installer/amd64/initrd.gz ip=dhcp auto=enable language=en 
> country=US locale=en_US.UTF-8 keymap=ansi hostname=debian domain="" 
> url=tftp://10.0.0.1/preseed.cfg
> 
> Console is accessed over VGA. VMSVGA for the VirtualBox tests we've ran and a 
> VGA KVM for the tests on bare metal.

I still cannot reproduce with unpacking the tarball and running

kvm -net nic -net user,tftp=$PWD,bootfile=pxelinux.0 -drive -m 1G

and passing the kernel parameters.

Does the mangling happen right from the first screen, or after some
steps?

It could be useful to share your preseed.cfg (take care of removing any
hardcoded password).

Samuel

Bug#1065570: ***UNCHECKED*** Re: Bug#1065570: Interface border is replaced by ascii chars

[Samuel Thibault]

Hello,

Please re-send your mail unencrypted, so everybody can read the
information.

Samuel

Bug#1064918: tex-common postinst script fails due to a bug in lua script /usr/bin/mtxrun.lua

[Preuße]

Control: affects -1 context,texlive-binaries
Control: merge -1 1064402

On 06.03.2024 23:23, Preuße...@buxtehude.debian.org, Hilmar wrote:


Control: severity -1 grave
Control: reassign -1 luametatex

Control: merge -1 1064402


Next try.

H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1065570: Interface border is replaced by ascii chars

[x11r]

The machine is PXE booted with the kernel parameters: 
initrd=debian-installer/amd64/initrd.gz ip=dhcp auto=enable language=en 
country=US locale=en_US.UTF-8 keymap=ansi hostname=debian domain="" 
url=tftp://10.0.0.1/preseed.cfg

Console is accessed over VGA. VMSVGA for the VirtualBox tests we've ran and a 
VGA KVM for the tests on bare metal.

On Wednesday, March 6th, 2024 at 5:28 PM, Samuel Thibault 
 wrote:

> x11r, le mer. 06 mars 2024 18:59:50 +, a ecrit:
> 
> > I've been working with a small team at my college trying to develop a tool 
> > to automate PXE booting and installation. We have targeted Debian as the 
> > first OS we want to get working over PXE boot. On every test we've ran of 
> > the Debian installation process, there's a visual bug that occurs late in 
> > the installation process. Effectively, the border of the progress interface 
> > turns into Çâö repeatedly. You can see an image of it in the issue here 
> > https://github.com/xeluior/genisys/issues/82
> 
> 
> That looks like an utf-8 encoding issue. Please tell us exactly how you
> boot it (kernel parameters and how you access the console).
> 
> Samuel

Bug#1064918: tex-common postinst script fails due to a bug in lua script /usr/bin/mtxrun.lua

[Preuße]

Control: affects -1 texlive-binaries,context
Control: merge -1 1064402

On 06.03.2024 23:23, Preuße...@buxtehude.debian.org, Hilmar wrote:


Control: severity -1 grave
Control: reassign -1 luametatex
Control: merge -1 1064402



Next try.

H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064781: ACK + fix uploaded

[William Desportes]

Control: tags -1 + pending
Control: fixed -1 php-dompdf-svg-lib/0.5.2-1

Thank you for the bug report !

Bug#1065554: [Aptitude-devel] Bug#1065554: aptitude: the TUI silently breaks a "Recommends"

[Vincent Lefevre]

On 2024-03-06 21:36:09 +0100, Axel Beckert wrote:
> Hi Vincent,
> 
> Vincent Lefevre wrote:
> > Do you need the bundle?
> 
> Actually that would be interesting, as I have a vague idea how it
> might have been triggered and would like to experiment a bit if I can
> find a simpler reproducer.

[link sent in a private reply]

> BTW, do I remember right that you have APT::Install-Recommends set
> "false"?

AFAIK, perhaps except on a very old laptop (due to the lack of
disk space), I've always chosen to install recommends, which is
the default.

I usually have

  Aptitude::ProblemResolver::SolutionCost "safety, removals";

but this is not the case on this machine yet.

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

Bug#1065570: Interface border is replaced by ascii chars

[Samuel Thibault]

x11r, le mer. 06 mars 2024 18:59:50 +, a ecrit:
> I've been working with a small team at my college trying to develop a tool to 
> automate PXE booting and installation. We have targeted Debian as the first 
> OS we want to get working over PXE boot. On every test we've ran of the 
> Debian installation process, there's a visual bug that occurs late in the 
> installation process. Effectively, the border of the progress interface turns 
> into Çâö repeatedly. You can see an image of it in the issue here 
> https://github.com/xeluior/genisys/issues/82

That looks like an utf-8 encoding issue. Please tell us exactly how you
boot it (kernel parameters and how you access the console).

Samuel

Bug#1064918: tex-common postinst script fails due to a bug in lua script /usr/bin/mtxrun.lua

[Preuße]

Control: severity -1 grave
Control: reassign -1 luametatex
Control: merge -1 1064402

On 27.02.2024 19:06, Giacomo Mulas wrote:

Hi,

after the latest standard "apt upgrade" I was left with an unconfigured 
tex-common, due to the following reported error:


lua error : startup file: /usr/bin/mtxrun.lua:2438: attempt to assign to 
const variable 'i'




I merge that bug to the luametatex's bug now.

Hilmar
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064139: Bug #1064139 ogre-1.12: FTBFS: error: ‘BuildFontAtlas’ is not a member of ‘ImGuiFreeType’

[Simon Schmeißer]

Dear Flavien,

a good and simple start would be to open a Merge Request (MR) adding a
patch on salsa: https://salsa.debian.org/games-team/ogre

Then salsa CI will test your changes and it can be sponsored by someone.


There was ongoing work to update to 1.12.13  but it stalled:
https://salsa.debian.org/games-team/ogre/-/merge_requests/6

The main work is likely to identify what needs to change for the
copyright file to be acceptable


If you want to get started on ogre 14 you could start by combining the
changes in the 1.12.13 branch with those here
https://salsa.debian.org/games-team/ogre/-/commits/ogre-13.3/?ref_type=heads

I'm currently super short on time but will try to help you with any
technical problems if you open a MR for a patch

Best regards from Freiburg

Simon

Am 06.03.24 um 08:46 schrieb Flavien Bridault:


Dear maintainer(s),

I took a look at the latest version of Ogre which is probably
compatible with latest ImGui and it seems this line is no longer
necessary. It was removed before the release 13.0.0 when upgrading to
ImGUI 1.83 :
https://github.com/OGRECave/ogre/commit/17b7481057b97662a3752ee605ea77a9eb0c57db

Patching should be then fairly easy...

I can offer my help again, like I did to upgrade to 1.14
(https://lists.debian.org/debian-devel-games/2023/11/msg1.html),
which whould really be the best option in the end... Maybe I will have
an official answer this time ? I don't want to be sarcastic at all,
but I strongly depend on Ogre to build sight and this is annoying to
get no answer from the devel games team. And currently my package
sight is currently marked for autoremoval because of this bug
(https://tracker.debian.org/pkg/sight)

Kind regards,

--

*Dr. Flavien BRIDAULT*
Director of Software Development
IRCAD France & IRCAD Africa

flavien.brida...@ircad.fr 
Tél. : +33 (0)3 88 119 201
IRCAD France
http://www.ircad.fr/
http://www.ircad.africa/ 

Suivez l'IRCAD sur Facebook


*IRCAD France*
Hôpitaux Universitaires - 1, place de l'Hôpital - 67091 Strasbourg
Cedex - FRANCE

Bug#1065579: Ubuntu delta to restrict the thunderbird architectures

[Sebastien Bacher]

Package: firejail
Version: 0.9.72-2
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch

Hey,

We are transitioning thunderbird from a deb to a snap in Ubuntu (for 
reasons similar to firefox). The snap is built on a restricted set of 
architectures so I've adapted the autopkgtest accordingly for Ubuntu. I 
don't know if that makes sense for Debian but since the current version 
is including a similar restricted list of architectures for firefox I'm 
sending the patch in case you are wanted to do the same now for thunderbird


Cheers,



diff -Nru firejail-0.9.72/debian/changelog firejail-0.9.72/debian/changelog
--- firejail-0.9.72/debian/changelog2023-01-17 02:04:42.0 +0100
+++ firejail-0.9.72/debian/changelog2024-03-06 16:35:38.0 +0100
@@ -1,3 +1,11 @@
+firejail (0.9.72-3) UNRELEASED; urgency=medium
+
+  * debian/tests/control:
+- update to reflect the architectures thunderbird is now available on
+  in Ubuntu since it's distributed as a snap (similar to firefox)
+
+ -- Sebastien Bacher   Wed, 06 Mar 2024 16:35:38 +0100
+
 firejail (0.9.72-2) unstable; urgency=medium
 
   * Fix more errors in smoke tests.
diff -Nru firejail-0.9.72/debian/tests/control 
firejail-0.9.72/debian/tests/control
--- firejail-0.9.72/debian/tests/control2022-12-21 23:10:27.0 
+0100
+++ firejail-0.9.72/debian/tests/control2024-03-06 16:35:26.0 
+0100
@@ -12,7 +12,7 @@
 
 Tests: application-tests
 Restrictions: allow-stderr, isolation-machine, flaky
-Depends: @, expect, file, strace, sudo, man-db, iptables, iputils-ping, wget, 
csh, zsh, xvfb, xserver-xephyr, xterm, evince, thunderbird, firefox [amd64 
armhf arm64], transmission-gtk
+Depends: @, expect, file, strace, sudo, man-db, iptables, iputils-ping, wget, 
csh, zsh, xvfb, xserver-xephyr, xterm, evince, thunderbird [amd64 arm64], 
firefox [amd64 armhf arm64], transmission-gtk
 
 Tests: network-test
 Restrictions: allow-stderr, breaks-testbed, isolation-machine, needs-root, 
flaky

Bug#1065577: [#5509] - Bug#1065577: Info received (Team Hydra Support Account Activation)

[Team Hydra Support]

  Hey 1065577,  We've received your ticket and our helpdesk team will get to it 
as soon as they can! You will receive email updates that you are welcome to 
reply to as we work through this ticket. Here's what you submitted:  
Bug#1065577: Info received (Team Hydra Support Account Activation)   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):
 Debian Mirrors Team 

If you wish to submit further information on this problem, please
send it to 1065...@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.

-- 
1065577: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065577
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
  To view the status of the ticket, add comments, or see your other tickets, 
you can visit the link below! https://support.hep.gg/helpdesk/tickets/5509  
We'll get back to you as soon as we can!  With Lots Of Love, The Helpdesk 
 

Bug#1065577: Team Hydra Support Account Activation

[Team Hydra Support]

  Hey there 1065577,  A new Team Hydra Support account has been created for 
you.  Click the URL below to activate your account and select a password!  
https://support.hep.gg/register/PRSZ1nJNG0t69jcMeCl  If the above URL does not 
work try copying and pasting it into your browser. If you continue to have 
problems, please feel free to reply to this email.  Regards, The Helpdesk 
 

Bug#1065577: [#5508] - Bug#1065577: Acknowledgement (mirror submission for mirror.hep.gg)

[Team Hydra Support]

  Hey 1065577,  We've received your ticket and our helpdesk team will get to it 
as soon as they can! You will receive email updates that you are welcome to 
reply to as we work through this ticket. Here's what you submitted:  
Bug#1065577: Acknowledgement (mirror submission for mirror.hep.gg)   Thank you 
for filing a new Bug report with Debian.

You can follow progress on this Bug here: 1065577: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065577.

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):
 Debian Mirrors Team 

If you wish to submit further information on this problem, please
send it to 1065...@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.

-- 
1065577: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065577
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
  To view the status of the ticket, add comments, or see your other tickets, 
you can visit the link below! https://support.hep.gg/helpdesk/tickets/5508  
We'll get back to you as soon as we can!  With Lots Of Love, The Helpdesk 
 

Bug#1065578: ITP: python-sqlite-migrate -- A simple database migration system for SQLite, based on sqlite-utils

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupre 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: python-sqlite-migrate
  Version : 0.1b0
  Upstream Contact: Simon Willison 
* URL : https://github.com/simonw/sqlite-migrate
* License : Apache-2.0
  Programming Lang: Python
  Description : A simple database migration system for SQLite, based on 
sqlite-utils

Python library to operate changes on SQLite database, based on
migration files.



This is a dependency of the LLM package (#1065572).

Bug#1057689: minetest: calls home for upstream version check

[David Heidelberg]

Hello!

as a workaround you can set empty `update_information_url` in 
`~/.minetest/minetest.conf`.


For Debian developer maintaining minetest, this can be patched in 
`src/defaultsettings.cpp` same way by setting it to empty string.


Please, consider this message also as a request to bump minetest up to 
5.8.0 version.


Thank you!

--
David Heidelberg

Bug#1064604: gst-omx: Unmaintained upstream

[Jeremy Bícha]

On Sun, Feb 25, 2024 at 7:23 AM PaulLiu  wrote:
> Yes. I know it. I'll remove gst-omx when gstreamer 1.24.0 landed unstable.

Hi! gstreamer 1.24.0 is in Unstable now.

Thank you,
Jeremy Bícha

Bug#1065577: mirror submission for mirror.hep.gg

[Team Hydra]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.hep.gg
Archive-architecture: ALL alpha amd64 arm armel hppa hurd-i386 i386 ia64 
kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390 sparc
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Team Hydra 
Country: CA Canada
Location: Niagara Falls, Ontario, Canada
Sponsor: Team Hydra https://teamhydra.dev
Comment: 3GBPS site speed. IP's are sometimes rotated, but DNS is updated 
accordingly with a low TTL




Trace Url: http://mirror.hep.gg/debian/project/trace/
Trace Url: http://mirror.hep.gg/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.hep.gg/debian/project/trace/mirror.hep.gg

Bug#1065519: Feedback

[no-reply]

This is odd: I can't seem to find this error message in the 
rockchip_drm_vop2 mainline driver. Are you using a vendor kernel? If 
so which one exactly?


I am not sure... I downloaded the Debian image 
(Orangepicm4_1.0.4_debian_bookworm_desktop_xfce_linux5.10.160.7z) from 
https://drive.google.com/drive/folders/1MJl-pIU2I7EHDN6rlirumVkBOz7utvyE 
and flashed it to the OrangePi. Then updated to the testing branch using 
these instructions: 
https://linuxiac.com/how-to-switch-from-debian-stable-to-testing/.


You seem to have lightdm still running but use phosh.service. Please 
stop lightdm to make sure they don't race for the same tty.


OK so I ran:
systemctl stop lightdm; systemctl start phosh;
then looked in journal:

Mar 06 20:50:04 orangepicm4 phoc[3404]: [libseat] 
[common/terminal.c:162] Could not open target tty: Permission denied
Mar 06 20:50:04 orangepicm4 phoc[3404]: [libseat] [seatd/seat.c:61] 
Could not open tty0 to update VT: Permission denied
Mar 06 20:50:04 orangepicm4 phoc[3404]: [libseat] 
[common/terminal.c:162] Could not open target tty: Permission denied
Mar 06 20:50:04 orangepicm4 phoc[3404]: [libseat] [seatd/seat.c:72] 
Could not open terminal for VT 0: Permission denied
Mar 06 20:50:04 orangepicm4 phoc[3404]: [libseat] [seatd/seat.c:461] 
Could not open VT for client
Mar 06 20:50:04 orangepicm4 phoc[3404]: [libseat] 
[common/terminal.c:162] Could not open target tty: Permission denied
Mar 06 20:50:04 orangepicm4 phoc[3404]: [libseat] [seatd/seat.c:86] 
Could not open terminal to clean up VT 0: Permission denied
Mar 06 20:50:14 orangepicm4 phoc[3349]: [backend/backend.c:107] Timeout 
waiting session to become active
Mar 06 20:50:14 orangepicm4 phoc[3349]: [backend/backend.c:272] failed 
to start a session
Mar 06 20:50:14 orangepicm4 phoc[3349]: [backend/backend.c:322] failed 
to add backend 'drm'
Mar 06 20:50:14 orangepicm4 phoc[3404]: [libseat] 
[common/terminal.c:162] Could not open target tty: Permission denied
Mar 06 20:50:14 orangepicm4 phoc[3404]: [libseat] [seatd/seat.c:86] 
Could not open terminal to clean up VT 0: Permission denied
Mar 06 20:50:14 orangepicm4 phoc[3349]: Failed to create server: Could 
not create backend
Mar 06 20:50:20 orangepicm4 phoc[4151]: [libseat] 
[libseat/backend/logind.c:317] Could not activate session: Interactive 
authentication requir>
Mar 06 20:50:20 orangepicm4 phoc[4162]: [libseat] 
[common/terminal.c:162] Could not open target tty: Permission denied
Mar 06 20:50:20 orangepicm4 phoc[4162]: [libseat] [seatd/seat.c:61] 
Could not open tty0 to update VT: Permission denied
Mar 06 20:50:20 orangepicm4 phoc[4162]: [libseat] 
[common/terminal.c:162] Could not open target tty: Permission denied
Mar 06 20:50:20 orangepicm4 phoc[4162]: [libseat] [seatd/seat.c:72] 
Could not open terminal for VT 0: Permission denied
Mar 06 20:50:20 orangepicm4 phoc[4162]: [libseat] [seatd/seat.c:461] 
Could not open VT for client
Mar 06 20:50:20 orangepicm4 phoc[4162]: [libseat] 
[common/terminal.c:162] Could not open target tty: Permission denied
Mar 06 20:50:20 orangepicm4 phoc[4162]: [libseat] [seatd/seat.c:86] 
Could not open terminal to clean up VT 0: Permission denied
Mar 06 20:50:30 orangepicm4 phoc[4151]: [backend/backend.c:107] Timeout 
waiting session to become active
Mar 06 20:50:30 orangepicm4 phoc[4151]: [backend/backend.c:272] failed 
to start a session
Mar 06 20:50:30 orangepicm4 phoc[4151]: [backend/backend.c:322] failed 
to add backend 'drm'
Mar 06 20:50:30 orangepicm4 phoc[4162]: [libseat] 
[common/terminal.c:162] Could not open target tty: Permission denied
Mar 06 20:50:30 orangepicm4 phoc[4162]: [libseat] [seatd/seat.c:86] 
Could not open terminal to clean up VT 0: Permission denied
Mar 06 20:50:30 orangepicm4 phoc[4151]: Failed to create server: Could 
not create backend
Mar 06 20:50:36 orangepicm4 phoc[4633]: [libseat] 
[libseat/backend/logind.c:317] Could not activate session: Interactive 
authentication requir>
Mar 06 20:50:36 orangepicm4 phoc[4636]: [libseat] 
[common/terminal.c:162] Could not open target tty: Permission denied
Mar 06 20:50:36 orangepicm4 phoc[4636]: [libseat] [seatd/seat.c:61] 
Could not open tty0 to update VT: Permission denied
Mar 06 20:50:36 orangepicm4 phoc[4636]: [libseat] 
[common/terminal.c:162] Could not open target tty: Permission denied
Mar 06 20:50:36 orangepicm4 phoc[4636]: [libseat] [seatd/seat.c:72] 
Could not open terminal for VT 0: Permission denied
Mar 06 20:50:36 orangepicm4 phoc[4636]: [libseat] [seatd/seat.c:461] 
Could not open VT for client
Mar 06 20:50:36 orangepicm4 phoc[4636]: [libseat] 
[common/terminal.c:162] Could not open target tty: Permission denied
Mar 06 20:50:36 orangepicm4 phoc[4636]: [libseat] [seatd/seat.c:86] 
Could not open terminal to clean up VT 0: Permission denied
Mar 06 20:50:46 orangepicm4 phoc[4633]: [backend/backend.c:107] Timeout 
waiting session to become active
Mar 06 20:50:46 orangepicm4 phoc[4633]: [backend/backend.c:272] failed 
to start a session
Mar 06 20:50:46 orangepicm4 ph

Bug#1065572: ITP: llm -- Access large language models from the command-line

[Antoine Beaupré]

On 2024-03-06 22:06:18, Petter Reinholdtsen wrote:
> [Antoine Beaupre]
>> A CLI utility and Python library for interacting with Large Language
>> Models, both via remote APIs and models that can be installed and run
>> on your own machine.
>
> Is the option to run models locally related to llama.cpp, ref
> https://bugs.debian.org/1063673 >?

I am not absolutely sure, but yes, I would assume that's one of the
backends llm can use.

Bug#1065572: ITP: llm -- Access large language models from the command-line

[Petter Reinholdtsen]

[Antoine Beaupre]
> A CLI utility and Python library for interacting with Large Language
> Models, both via remote APIs and models that can be installed and run
> on your own machine.

Is the option to run models locally related to llama.cpp, ref
https://bugs.debian.org/1063673 >?

-- 
Happy hacking
Petter Reinholdtsen

Bug#1065567: timedatectl does not recognize ntpsec

[Richard Laager]

If I'm understanding this correctly, I just need to install a file with 
the contents "ntpsec.service" to 
/usr/lib/systemd/ntp-units.d/50-ntpsec.list. That's easy enough to do.


--
Richard



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1065576: ITP: python-ulid -- Universally unique lexicographically sortable identifier (Python library)

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupre 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: python-ulid
  Version : 2.2.0
  Upstream Contact: Martin Domke 
* URL : https://python-ulid.rtfd.io/
* License : MIT
  Programming Lang: Python
  Description : Universally unique lexicographically sortable identifier 
(Python library)

A ULID is a universally unique lexicographically sortable
identifier. It is:

- 128-bit compatible with UUID
- 1.21e+24 unique ULIDs per millisecond
- Lexicographically sortable!
- Canonically encoded as a 26 character string, as opposed to the 36 character 
UUID
- Uses Crockford's base32 for better efficiency and readability (5 bits per 
character)
- Case insensitive
- No special characters (URL safe)



This is a dependency for the llm package (#1065572). We have another
ULID implementation in Debian (golang-github-oklog-ulid-dev) but it's
not sufficient for the LLM package, which expects the Python library.

This is going to be packaged in the Python team.

Bug#1065573: Wrong patch

[Leandro Lucarella]

Damn, the patch is wrong, it should be something like:

if ! [ -s /etc/resolv.conf ] && [ -n "$IPV4DNS0" ]; then  
echo "nameserver $IPV4DNS0" >> /etc/resolv.conf
fi

-- 
Leandro Lucarella (Luca)
https://llucax.com

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

Bug#1065575: /usr/bin/dpkg-deb: Wrong arguments in Swedish translations for dpkg-deb and dpkg man pages

[Jari Matilainen]

Package: dpkg
Version: 1.21.22
Severity: minor
File: /usr/bin/dpkg-deb

Dear Maintainer,

-- Package-specific info:
This system uses merged-usr-via-aliased-dirs, going behind dpkg's
back, breaking its core assumptions. This can cause silent file
overwrites and disappearances, and its general tools misbehavior.
See .

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

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

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.8-5+b1
ii  libc62.36-9+deb12u4
ii  liblzma5 5.4.1-0.2
ii  libmd0   1.0.4-2
ii  libselinux1  3.4-1+b6
ii  libzstd1 1.5.4+dfsg2-5
ii  tar  1.34+dfsg-1.2+deb12u1
ii  zlib1g   1:1.2.13.dfsg-1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.6.1
pn  debsig-verify  

-- no debconf information

With
vague@SEJA:~$ echo $LANG
sv_SE.UTF-8

'man dpkg-deb' and 'man dpkg', both show --vextract with wrong shortform 
argument
   -x|--extract arkiv katalog
   Extrahera filerna som finns i paketet.

   -C|--vextract arkiv katalog
   Extrahera och visa filnamnen som finns i paketet.

Changing language with 'LANG=en man dpkg-deb' the shortform is correct
   -x, --extract archive directory
   Extract the files contained by package.

   -X, --vextract archive directory
   Extract and display the filenames contained by a package.

This can be confusing for users if they don't check 'dpkg-deb --help' and notice
the discrepancy


/Jari

Bug#1065573: kxc: initramfs script writes a line to resolv.conf with $IPV4DNS0 even if empty

[Leandro Lucarella]

Package: kxc
Version: 0.15-4.1+b1
Severity: important
Tags: patch

Dear Maintainer,

The script
/usr/share/initramfs-tools/scripts/init-premount/kxc-premount-net writes
a line to /etc/resolv.conf adding a "nameserver $IPV4DNS0" even if that
environment variable is empty. If I understand correctly that variable
is only set if a DNS is passed via the ip= kernel parameter. Popular
simple configurations like ip=dhcp will then have no DNS server set
there, which will end up with a bad /etc/resolv.conf line with
"namesever ".

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

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

Versions of packages kxc depends on:
ii  cryptsetup  2:2.6.1-6+b1
ii  kxgencert   0.15-4.1+b1

kxc recommends no packages.

kxc suggests no packages.

-- no debconf information
--- /tmp/kxc-premount-net   2024-03-06 21:34:23.392212084 +0100
+++ /usr/share/initramfs-tools/scripts/init-premount/kxc-premount-net   
2024-03-06 21:35:18.080475021 +0100
@@ -22,7 +22,7 @@
 configure_networking
 
 # Configure a basic resolv.conf based on our networking.
-if ! [ -s /etc/resolv.conf ]; then
+if ! [ -s /etc/resolv.conf -a -n "$IPV4DNS0" ]; then
echo "nameserver $IPV4DNS0" >> /etc/resolv.conf
 fi
 

Bug#1065574: libgtk-3-0 and libgtk-3-0t64 are mutually dependent but out of line, many packages are being kept back

[Arnaldo Pirrone]

Package: libgtk-3-0
Version: 3.24.41-1
Severity: important
X-Debbugs-Cc: it9...@gmail.com

libgtk-3-0t64 3.24.41-1.1 is breaking libgtk-3-0 as the version of the latter
is lesser than 3.24.41-1.1
As it follows, I'm unable to install libgail-3-0 on which nemo depends, the
bluetooth utils, and many other packages including task-cinnamon-desktop from
experimental branch.


-- 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.7.7-x64v3-xanmod1 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libgtk-3-0 depends on:
ii  adwaita-icon-theme   46~rc-1
ii  hicolor-icon-theme   0.17-2
ii  libatk-bridge2.0-0   2.50.0-1+b1
ii  libatk1.0-0  2.50.0-1+b1
ii  libc62.37-15.1
ii  libcairo-gobject21.18.0-1+b1
ii  libcairo21.18.0-1+b1
ii  libcloudproviders0   0.3.5-1
ii  libcolord2   1.4.7-1
ii  libcups2 2.4.7-1+b1
ii  libepoxy01.5.10-1+b2
ii  libfontconfig1   2.15.0-1
ii  libfribidi0  1.0.13-3+b1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3+b1
ii  libglib2.0-0 2.78.4-1
ii  libgtk-3-common  3.24.41-1
ii  libharfbuzz0b8.3.0-2
ii  libpango-1.0-0   1.52.0+ds-1
ii  libpangocairo-1.0-0  1.52.0+ds-1
ii  libpangoft2-1.0-01.52.0+ds-1
ii  libwayland-client0   1.22.0-2.1+b1
ii  libwayland-cursor0   1.22.0-2.1+b1
ii  libwayland-egl1  1.22.0-2.1+b1
ii  libx11-6 2:1.8.7-1
ii  libxcomposite1   1:0.4.5-1
ii  libxcursor1  1:1.2.1-1
ii  libxdamage1  1:1.1.6-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxi6   2:1.8.1-1
ii  libxinerama1 2:1.1.4-3
ii  libxkbcommon01.6.0-1
ii  libxrandr2   2:1.5.2-2+b1
ii  shared-mime-info 2.4-1

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

Versions of packages libgtk-3-0 suggests:
ii  gvfs  1.53.90-2

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

-- no debconf information

Bug#1065554: [Aptitude-devel] Bug#1065554: aptitude: the TUI silently breaks a "Recommends"

[Axel Beckert]

Hi Vincent,

Vincent Lefevre wrote:
> > I've seen also already seen this, but so far it always was for a
> > reason here:
> > 
> > * On multiarch hosts, amd64 and i386 weren't in sync and there were
> >   Breaks against any version not being the same version.
> 
> This is not a multiarch host yet.

That was already mentioned in the original bug report's footer, yes.
Otherwise I would have asked. :-)

> > * An initial solution pulls in a package which Breaks the package in
> >   question and that pulled in package later (manually or due to other
> >   conflicts by manual changes) gets set to "keep uninstalled", but the
> >   effect of its Breaks is not reverted.
> 
> I cannot see any Breaks of at-spi2-core.

Yes, I've checked that, too.

That's also why I mentioned them: These cases don't apply and hence
it's NOT one of the two common cases, where it's more obvious (albeit
not necessarily good) that this happens.

[I removed the additional details, but they might come in handy later,
so thanks!]

> > But in your case neither of that seems to be case. So it indeed might
> > be a bug in this case.
> 
> Do you need the bundle?

Actually that would be interesting, as I have a vague idea how it
might have been triggered and would like to experiment a bit if I can
find a simpler reproducer.

BTW, do I remember right that you have APT::Install-Recommends set
"false"?

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1057549: crowdsec: FTBFS: FAIL: TestOneShot/permission_denied

[Cyril Brulebois]

Santiago Vila  (2024-03-06):
> I looked at the build log and found the problem: The package has a missing
> build-depends on passwd, which is no longer build-essential in trixie/sid.

Alright, that's the kind of thing I had in mind initially but I'm pretty
sure one of the attempt to reproduce started with a brand new build
chroot… Oh well.

> I am a member of Debian Go (joined to do QA stuff).
> Would it help if I fix this myself by doing a "Team Upload"?

Thanks for the offer, but I do have another related FTBFS on my plate
(even if it was misfiled in the first place), so I'll probably lump up
both uploads together. :)


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/


signature.asc
Description: PGP signature

Bug#1065572: ITP: llm -- Access large language models from the command-line

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupre 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org, 
debian...@lists.debian.org

* Package name: llm
  Version : 0.13.1
  Upstream Contact: Simon Willison 
* URL : https://llm.datasette.io/
* License : Apache-2.0
  Programming Lang: Python
  Description : CLI utility and Python library for interacting
  with Large Language Models

A CLI utility and Python library for interacting with Large Language
Models, both via remote APIs and models that can be installed and run
on your own machine.

Run prompts from the command-line, store the results in SQLite,
generate embeddings and more.



So there has been some discussions about packaging LLM things in
Debian, and this is my stab at opening a discussion about *what*
exactly, we *can* package, right now.

LLM is a (possibly poorly named) package that allows users to interact
with various language models. Its primary target is obviously the
OpenAI API (it's the example in the "Quick Start"), but it also
supports local models like Llama 2, Ollama, and MLC, and other online
models like Claude, GEmini and Mistral.

I *think* this belongs in contrib, because it *mostly* relies on
non-free software (and services) to do its thing, but I'd be happy to
move that around.

I need this because I was using GPT plus for a while and now I'm
switching to the API to cut down on costs.

Bug#1065571: zcfan: Package description mentions non existant "usage" section "below"

[Beatrice Torracca]

Package: zcfan
Version: 1.3.0-1
Severity: minor

Hi!

the package description of zcfan now has a list item that mentions a 
non-existant "usage" section. (it says "(see "usage" below)").

It's probably due to some copy-paste from the source documentation.

Thanks,

beatrice

Bug#1008502: vdirsyncer: Unknown error occured: unmatched ')'

[Colin Watson]

Control: tag -1 unreproducible

On Mon, Mar 28, 2022 at 01:44:58AM +0200, Christof Schulze wrote:
> Running vdirsyncer sync causes the above error message about unmatched
> ')'. This renders 0.4.4 - the version in stable - unusable. The root cause is 
> that
> python-click-threading 0.4.4, which vdirsyncer is depending on,
> introduced an incompatibility with python-click.
> More info on the problem can be found in [2] and [3].
> 
> The version in testing (0.18.0-6) is working fine as it depends on a
> python-click-version that does not have the problem. So installing the
> version from testing including its dependencies works.
> 
> Would you please upgrade vdirsyncer in stable to the current version in
> testing to make the program work again for everyone on stable?

I know this was a long time ago, but I've been going through some Python
team bugs to see if I can do anything with them, and came across this;
it interested me because I've been using vdirsyncer since 2017, and that
definitely involved a period when I was using it on bullseye and I don't
think I ever ran across this bug.

I just tried setting up a clean bullseye container, installing
vdirsyncer, copying over my configuration, and running "vdirsyncer
discover contacts && vdirsyncer sync".  Everything worked perfectly.

> [1] https://github.com/pimutils/vdirsyncer/pull/891
> [2] https://github.com/click-contrib/click-threading/pull/5
> [3] https://github.com/pimutils/vdirsyncer/issues/887

If we were to update anything here in bullseye, it would make more sense
to just cherry-pick the fix to click-threading; the only thing a new
vdirsyncer would add would be a tighter dependency on click-threading,
but for Debian stable release purposes we might as well just issue the
click-threading update and have people upgrade to it.

However, [2] and [3] both make it clear that the problem with the
combination of click and click-threading was introduced in click 8.0.0
and does not exist with click 7.1.2.  bullseye has click 7.1.2, and
indeed the package versions in your bug show that as well:

> Versions of packages vdirsyncer depends on:
> ii  init-system-helpers1.60
> ii  python33.9.2-3
> ii  python3-atomicwrites   1.4.0-2
> ii  python3-click  7.1.2-1
> ii  python3-click-log  0.2.1-2
> ii  python3-click-threading0.4.4-2
> ii  python3-requests   2.25.1+dfsg-2
> ii  python3-requests-toolbelt  0.9.1-1

... so I am quite suspicious that there may be some relevant information
that's not in the bug report.  You didn't include a traceback, which
might have made it clearer; but is it possible that you have a locally
installed version of click >= 8.0.0 from PyPI, perhaps due to running
"pip install" outside a virtual environment?  That would explain this
happening to you.

Thanks,

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

Bug#1063484: libuv1: CVE-2024-24806

[Salvatore Bonaccorso]

Hi

On Wed, Mar 06, 2024 at 07:06:55PM +0100, Dominique Dumont wrote:
> On Tuesday, 5 March 2024 22:15:50 CET Salvatore Bonaccorso wrote:
> > The debdiff for bookworm-security looks good to me. Please do upload
> > to security-master (and make sure to build with -sa as the orig
> > tarball is not yet on security-master for 1.44.2).
> 
> Done.

Thank you, builds arrived.

> > So we just need as well the bullseye-security one, as per above, can
> > you prepare this one as well.
> 
> Done. Here's the debdiff in attachment

Thank you very much. Looks good to me, feel free to upload as well to
security-master (and build as well with -sa).

Regards,
Salvatore

Bug#996181: cryptsetup-initramfs: Unable to use keyfile to decrypt rootfs

[Mateusz Jończyk]

On Mon, 11 Oct 2021 22:28:31 +0200 Mateusz Jończyk  wrote:
> Package: cryptsetup-initramfs
> Version: 2:2.3.5-1
> Severity: normal
> Tags: patch
>
> Hello,
>
> Currently, it is not possible to use a keyfile to decrypt the root file 
> system. I would like to use such a setup, so I'm attaching a short patch for
crypttab to make this work.
>
> The root filesystem may reside on more then one LUKS volume and it is 
> cumbersome to type the password twice on each boot. I'm using such a setup: I
have two drives in my laptop: on each one of them I have an encrypted LUKS 
partition, on every LUKS partition I have several LVM logical volumes. Two
of these logical volumes (one from every physical drive) are setup in a RAID1 
array, on which my rootfs resides.
>

Hello,

Please close this bug report. The setup I used to use is weird and not 
supported in Debian (at least Debian installer does not allow creating
partitions this way).

Please excuse me for letting this bug report hang for so long.

Greetings,

Mateusz

Bug#1065392: Additional information

[pdormeau]

Hello,

I made a test where I specified an empty field for --tpm2-pcrs instead
of default 7 and the luks partition is decrypted with the tpm.

I also made some test with other PCR values (1, 0) and it fails.

It seems to be related to the PCR binding and linux-image-6.7.7-amd64
since this problem does not come up with previous versions
(linux-image-6.6.15-amd64 and earlier)

"Luckily", since the problem is not specific to the secure-boot PCR
binding, I may be able to git-bisect the problem (i.e. with unsigned
kernels).

Best regards

Bug#1057549: crowdsec: FTBFS: FAIL: TestOneShot/permission_denied

[Santiago Vila]

tags 1057549 + patch
thanks

Hi.

I looked at the build log and found the problem: The package has a missing
build-depends on passwd, which is no longer build-essential in trixie/sid.

I am a member of Debian Go (joined to do QA stuff).
Would it help if I fix this myself by doing a "Team Upload"?

Thanks.--- a/debian/control
+++ b/debian/control
@@ -68,6 +68,7 @@ Build-Depends: debhelper-compat (= 13),
golang-gopkg-natefinch-lumberjack.v2-dev,
golang-gopkg-tomb.v2-dev,
golang-gopkg-yaml.v2-dev,
+   passwd,
python3,
systemd
 Standards-Version: 4.5.0

Bug#1063088: weston: NMU diff for 64-bit time_t transition

[Steve Langasek]

On Wed, Mar 06, 2024 at 10:42:16AM +0100, Dylan Aïssi wrote:
> Hello,

> Le lun. 5 févr. 2024 à 02:54, Steve Langasek  a écrit :

> > If you have any concerns about this patch, please reach out ASAP.  Although
> > this package will be uploaded to experimental immediately, there will be a
> > period of several days before we begin uploads to unstable; so if 
> > information
> > becomes available that your package should not be included in the 
> > transition,
> > there is time for us to amend the planned uploads.

> I am wondering what is the plan with this package/bug? I noticed that changes
> related to the 64-bit time_t transition were not uploaded to unstable and
> because I uploaded several versions in unstable after your NMU in exp, I
> wonder if I haven't interfered with this transition.

Sorry, yes, the uploads with renaming of both dev package and runtime lib
package in the midst of the transition resulted in this package being lost.

Since this is a completely new soname, and only packages built from weston
source depend on it, I suggest that you simply request a binNMU of weston on
armhf and armel and consider this resolved.

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


signature.asc
Description: PGP signature

Bug#1065570: Interface border is replaced by ascii chars

[x11r]

Package: debian-installer
Version: 20230607+deb12u5

I've been working with a small team at my college trying to develop a tool to 
automate PXE booting and installation. We have targeted Debian as the first OS 
we want to get working over PXE boot. On every test we've ran of the Debian 
installation process, there's a visual bug that occurs late in the installation 
process. Effectively, the border of the progress interface turns into Çâö 
repeatedly. You can see an image of it in the issue here 
https://github.com/xeluior/genisys/issues/82

This happens every install. We have tested it on a small selection of hardware 
(I don't have the details on hand right now) and in virtual machines 
(VirtualBox). The debian-installer version is the one bundled with 
https://deb.debian.org/debian/dists/bookworm/main/installer-amd64/current/images/netboot/netboot.tar.gz

I'm not sure where to start looking for this so let me know what other 
information would be useful.

Thank you,
Robert Gingras

Bug#1064282: poppler: NMU diff for 64-bit time_t transition

[Steve Langasek]

On Tue, Mar 05, 2024 at 02:14:09PM +0100, Sune Stolborg Vuorela wrote:
> On Sunday, March 3, 2024 7:40:52 AM CET Steve Langasek wrote:
> > (Particularly irrelevant for poppler, whose soname changes ~ monthly.)

> Please note that the poppler frontends, that applications are supposed to be 
> using does only very rarely change SONAME. the glib frontend haven't since 
> it's introduction. Neither have the cpp frontend. The qt5 frontend has 
> changed 
> once. 

> The Poppler Core library, which is meant to be a private shared thing between 
> the frontends is changing SONAME monthly. But poppler core and the frontends 
> are all in the same source, so it shouldn't affect anyone who behaves with 
> poppler as documented. 

Heh true.  But now the ABI has changed, because these libraries are all
confirmed to expose time_t in their ABIs...

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


signature.asc
Description: PGP signature

Bug#1064617: Passwords should not be changed frequently

[Holger Wansing]

Hi,

Am 5. März 2024 20:44:52 MEZ schrieb Philip Hands :
>BTW I don't know much about how the translation side of things works,
>but given that there are many ways of getting the fine detail of this to
>be incorrect in various ways, is there a standard method for adding
>hints for translators, and should that be done?

Such hints for translators can be added to the templates file, as in

They will then end up in translator's po files.


Do you have some specific sentence in mind, which deserves a
special hint?
I noticed that my English is not good enough to formulate such details.


Holger


-- 
Sent from /e/ OS on Fairphone3

Bug#1064377: tcl-expect: identified for time_t transition but no ABI in shlibs

[Steve Langasek]

On Tue, Mar 05, 2024 at 01:34:19PM +0300, Sergei Golovan wrote:
> Hi Steve,

> On Mon, Feb 26, 2024 at 1:12 AM Steve Langasek  wrote:

> > Control: severity -1 normal

> > Note that there are no reverse-dependencies in the archive that link against
> > libexpect, so I think we can downgrade this bug (or close wontfix, at the
> > maintainer's discretion).

> Also, as far as I can see, libexpect does not expose time_t (it uses
> it only internally), so I'm
> closing this bug.

I leave this to your discretion.  This is a package whose headers failed to
analyze under abi-compliance-checker:

https://adrien.dcln.fr/misc/armhf-time_t/2024-02-26T12%3A07%3A00/logs/tcl-expect-dev/base/abi-compliance-checker.log

So we don't know that its ABI is affected, but we also don't know that it
isn't.

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


signature.asc
Description: PGP signature

Bug#1065567: timedatectl does not recognize ntpsec

[Jeffrey Walton]

On Wed, Mar 6, 2024 at 1:29 PM Michael Biebl  wrote:
>
> Control: reassign -1 ntpsec
>
> Actually, I think it's better to just reassign the bug report and let
> Richard decide whether he closes it as wontfix or ships such an
> integration snippet.
>
> Richard, if you are interested in shipping such a ntp-units.d snippet
> and you have further questions, please ask.

Thank you sir!

Bug#1065569: Please reduce Recommends on uuid-runtime to Suggests

[Josh Triplett]

Package: util-linux
Version: 2.39.3-6
Severity: wishlist
X-Debbugs-Cc: j...@joshtriplett.org

libuuid1/libuuid1t64 currrently Recommends uuid-runtime.

As I understand it, uuid-runtime is primarily used when generating a
huge number of UUIDs very rapidly on a system, and wanting to ensure
that they can efficiently be generated uniquely.

Recommends is supposed to be used for cases of "packages that would be
found together with this one in all but unusual installations."

I think it's safe to say that it isn't just "unusual installations" that
can do without uuid-runtime; *needing* uuid-runtime is the uncommon
case. And in addition, today we do not install uuid-runtime when
bootstrapping a system (because some part of bootstrapping doesn't
look at Recommends), so many systems end up with libuuid1 without
uuid-runtime, without issue.

I would propose that the relationship on uuid-runtime become a
"Suggests": "This is used to declare that one package may be more useful
with one or more others. Using this field tells the packaging system and
the user that the listed packages are related to this one and can
perhaps enhance its usefulness, but that installing this one without
them is perfectly reasonable."

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

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

Versions of packages util-linux depends on:
ii  libblkid1  2.39.3-6
ii  libc6  2.37-15
ii  libcap-ng0 0.8.4-2
ii  libcrypt1  1:4.4.36-4
ii  libmount1  2.39.3-6
ii  libpam0g   1.5.2-9.1+b1
ii  libselinux13.5-2
ii  libsmartcols1  2.39.3-6
ii  libsystemd0255.3-2
ii  libtinfo6  6.4+20240113-1
ii  libudev1   255.3-2
ii  libuuid1   2.39.3-6
ii  zlib1g 1:1.3.dfsg-3+b1

Versions of packages util-linux recommends:
ii  sensible-utils  0.0.22

Versions of packages util-linux suggests:
ii  dosfstools  4.2-1
pn  kbd 
pn  util-linux-extra
pn  util-linux-locales  

-- no debconf information

Bug#1065567: timedatectl does not recognize ntpsec

[Michael Biebl]

Control: reassign -1 ntpsec

Actually, I think it's better to just reassign the bug report and let 
Richard decide whether he closes it as wontfix or ships such an 
integration snippet.


Richard, if you are interested in shipping such a ntp-units.d snippet 
and you have further questions, please ask.


Michael

Am 06.03.24 um 19:22 schrieb Michael Biebl:
On Wed, 6 Mar 2024 12:53:47 -0500 Jeffrey Walton  
wrote:

Package: systemd
Version:  255.4-1
Tags: sid

It looks like Systemd's timedatectl does not recognize ntpsec. Using
it results in 'NTP service: n/a':

$ timedatectl
   Local time: Wed 2024-03-06 12:35:32 EST
   Universal time: Wed 2024-03-06 17:35:32 UTC
 RTC time: Wed 2024-03-06 17:35:32
    Time zone: America/New_York (EST, -0500)
System clock synchronized: yes
  NTP service: n/a
  RTC in local TZ: no

According to , ntpsec
is an option for Debian 11 and below; and default for Debian 12 and
above.

I searched for an upstream bug at 
(is that the right place?), but there were no relevant hits. See
.

Also see .
That's the debian-users mailing list discussion with GW's comment.


If an NTP service want's to be recognized by timedated, it needs to ship 
a config snippet in /usr/lib/systemd/ntp-units.d/

See man systemd-timedated



LIST OF NETWORK TIME SYNCHRONIZATION SERVICES
   systemd-timesyncd will look for files with a ".list" extension 
in ntp-units.d/ directories. Each file is parsed as a list of unit 
names, one per

  ^
   this is a typo, should be systemd-timedated [1]
   line. Empty lines and lines with comments ("#") are ignored. 
Files are read from /usr/lib/systemd/ntp-units.d/ and the 
corresponding directories
   under /etc/, /run/, /usr/local/lib/. Files in /etc/ override 
files with the same name in /run/, /usr/local/lib/, and /usr/lib/. 
Files in /run/
   override files with the same name under /usr/. Packages should 
install their configuration files in /usr/lib/ (distribution packages) or

   /usr/local/lib/ (local installs).

   Example 1. ntp-units.d/ entry for systemd-timesyncd

   # /usr/lib/systemd/ntp-units.d/80-systemd-timesync.list
   systemd-timesyncd.service

   If the environment variable $SYSTEMD_TIMEDATED_NTP_SERVICES is 
set, systemd-timesyncd will parse the contents of that variable as a
   colon-separated list of unit names. When set, this variable 
overrides the file-based list described above.



systemd-timesyncd and chrony do this properly.

# apt-file search /usr/lib/systemd/ntp-units.d/
chrony: /usr/lib/systemd/ntp-units.d/50-chrony.list
systemd-timesyncd: /usr/lib/systemd/ntp-units.d/80-systemd-timesync.list


I've CCed the ntpsec maintainers.
If they have interest in shipping such an integration, then we can 
reassign the bug report. Otherwise I'll just close it, as there is 
nothing we can do on the systemd side


Regards,
Michael

[1] https://github.com/systemd/systemd/pull/31658




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1065567: timedatectl does not recognize ntpsec

[Michael Biebl]

On Wed, 6 Mar 2024 12:53:47 -0500 Jeffrey Walton  wrote:

Package: systemd
Version:  255.4-1
Tags: sid

It looks like Systemd's timedatectl does not recognize ntpsec. Using
it results in 'NTP service: n/a':

$ timedatectl
   Local time: Wed 2024-03-06 12:35:32 EST
   Universal time: Wed 2024-03-06 17:35:32 UTC
 RTC time: Wed 2024-03-06 17:35:32
Time zone: America/New_York (EST, -0500)
System clock synchronized: yes
  NTP service: n/a
  RTC in local TZ: no

According to , ntpsec
is an option for Debian 11 and below; and default for Debian 12 and
above.

I searched for an upstream bug at 
(is that the right place?), but there were no relevant hits. See
.

Also see .
That's the debian-users mailing list discussion with GW's comment.


If an NTP service want's to be recognized by timedated, it needs to ship 
a config snippet in /usr/lib/systemd/ntp-units.d/

See man systemd-timedated



LIST OF NETWORK TIME SYNCHRONIZATION SERVICES
   systemd-timesyncd will look for files with a ".list" extension in 
ntp-units.d/ directories. Each file is parsed as a list of unit names, one per

 ^
  this is a typo, should be systemd-timedated [1]

   line. Empty lines and lines with comments ("#") are ignored. Files are 
read from /usr/lib/systemd/ntp-units.d/ and the corresponding directories
   under /etc/, /run/, /usr/local/lib/. Files in /etc/ override files with 
the same name in /run/, /usr/local/lib/, and /usr/lib/. Files in /run/
   override files with the same name under /usr/. Packages should install 
their configuration files in /usr/lib/ (distribution packages) or
   /usr/local/lib/ (local installs).

   Example 1. ntp-units.d/ entry for systemd-timesyncd

   # /usr/lib/systemd/ntp-units.d/80-systemd-timesync.list
   systemd-timesyncd.service

   If the environment variable $SYSTEMD_TIMEDATED_NTP_SERVICES is set, 
systemd-timesyncd will parse the contents of that variable as a
   colon-separated list of unit names. When set, this variable overrides 
the file-based list described above.



systemd-timesyncd and chrony do this properly.

# apt-file search /usr/lib/systemd/ntp-units.d/
chrony: /usr/lib/systemd/ntp-units.d/50-chrony.list
systemd-timesyncd: /usr/lib/systemd/ntp-units.d/80-systemd-timesync.list


I've CCed the ntpsec maintainers.
If they have interest in shipping such an integration, then we can 
reassign the bug report. Otherwise I'll just close it, as there is 
nothing we can do on the systemd side


Regards,
Michael

[1] https://github.com/systemd/systemd/pull/31658


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1065568: ITP: golang-modernc-file -- write ahead log in Go

[tous]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
Owner: tous 

* Package name: golang-modernc-file
  Version : 1.0.8-1
  Upstream Author : Jan Mercl
* URL : https://gitlab.com/cznic/file
* License : BSD-3-clause
  Programming Lang: Go
  Description : write ahead log in Go

Package file handles write-ahead logs and space management of 
os.File-like entities.


This package is on dependency tree of probe-cli

Bug#1065567: timedatectl does not recognize ntpsec

[Jeffrey Walton]

Package: systemd
Version:  255.4-1
Tags: sid

It looks like Systemd's timedatectl does not recognize ntpsec. Using
it results in 'NTP service: n/a':

$ timedatectl
   Local time: Wed 2024-03-06 12:35:32 EST
   Universal time: Wed 2024-03-06 17:35:32 UTC
 RTC time: Wed 2024-03-06 17:35:32
Time zone: America/New_York (EST, -0500)
System clock synchronized: yes
  NTP service: n/a
  RTC in local TZ: no

According to , ntpsec
is an option for Debian 11 and below; and default for Debian 12 and
above.

I searched for an upstream bug at 
(is that the right place?), but there were no relevant hits. See
.

Also see .
That's the debian-users mailing list discussion with GW's comment.

Bug#1065566: curl profile pkg.curl.no-gnutls not working

[Matthias Klose]

Package: src:curl
Version: 8.6.0-3.2

the curl profile pkg.curl.no-gnutls is not working, because librtmp-dev 
depends on libgnutls28-dev, so for that profile to work, it's necessary 
to configure --without-librtmp


Also there are no profiles specified at all in the build dependencies.

Bug#1065565: debian-edu-config: X2Go Thin Client boots diskless image (x86_64) instead of X2Go TCE image (x2go-bare-amd64)

[Serhii Horichenko]

Package: src:debian-edu-config
Version: 2.12.44~deb12u1

X2Go Thin Client boot entry in iPXE boot menu uses diskless image
(x86_64) instead of X2Go TCE image (x2go-bare-amd64)

Sincerely,
Serhii Horichenko

Bug#1065530: ghostscript b-d not needed

[Andreas Metzler]

Control: forcemerge 980768 1065530

On 2024-03-06 Matthias Klose  wrote:
> Package: src:gnupg2
> Version: 2.4.4-2
> Severity: important

> while working on the time64 bootstraps, I noticed that the b-d on
> ghostscript is unneeded, at least the build succeeds without it.

> Please can you check if it can be removed, or if you could make it
> conditional with a build profile?

That seems to be a duplicate, merging.

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

Bug#1064077: RFS: qt5ct/1.8-1 -- Qt5 Configuration Utility

[Soren Stoutner]

Mateusz,

Did you have any questions about what I was asking here?

Soren

On Tuesday, February 20, 2024 2:40:04 PM MST Soren Stoutner wrote:
> Mateusz,
> 
> When compiling locally on my system, the current version of lintian 
(2.117.0)
> found the following problems.  These are not displayed on 
mentors.debian.net,
> leading me to believe they were recently added checks.
> 
> W: qt5ct: link-to-shared-library-in-wrong-package usr/lib/x86_64-linux-gnu/
> libqt5ct-common.so.1.8 [usr/lib/x86_64-linux-gnu/libqt5ct-common.so]
> N:
> N:   Although this package is not a "-dev" package, it installs a
> N:   "libsomething.so" symbolic link referencing the corresponding shared
> N:   library. When the link doesn't include the version number, it is used 
by
> N:   the linker when other programs are built against this shared library.
> N:
> N:   Shared libraries are supposed to place such symbolic links in their
> N:   respective "-dev" packages, so it is a bug to include it with the main
> N:   library package.
> N:
> N:   However, if this is a small package which includes the runtime and the
> N:   development libraries, this is not a bug. In the latter case, please
> N:   override this warning.
> N:
> N:   Please refer to Development files (Section 8.4) in the Debian Policy
> N:   Manual for details.
> N:
> N:   Visibility: warning
> N:   Show-Always: no
> N:   Check: libraries/shared/links
> N:   Renamed from: non-dev-pkg-with-shlib-symlink
> N:
> N:
> W: qt5ct: package-name-doesnt-match-sonames libqt5ct-common1.8
> N:
> N:   The package name of a library package should usually reflect the soname
> of N:   the included library. The package name can determined from the
> library N:   file name with the following code snippet:
> N:
> N:$ objdump -p /path/to/libfoo-bar.so.1.2.3 | sed -n -e's/
> ^[[:space:]]*SONAME[[:space:]]*//p' | \
> N:sed -r -e's/([0-9])\.so\./\1-/; s/\.so(\.|$)//; y/_/-/; s/(.*)/
\L&/'
> N:
> N:   Visibility: warning
> N:   Show-Always: no
> N:   Check: libraries/shared/soname
> N:
> N:
> I: qt5ct: no-symbols-control-file usr/lib/x86_64-linux-gnu/libqt5ct-
common.so.
> 1.8
> N:
> N:   Although the package includes a shared library, the package does not 
have
> N:   a symbols control file.
> N:
> N:   dpkg can use symbols files in order to generate more accurate library
> N:   dependencies for applications, based on the symbols from the library 
that
> N:   are actually used by the application.
> N:
> N:   Please refer to the dpkg-gensymbols(1) manual page and
> N:   https://wiki.debian.org/UsingSymbolsFiles for details.
> N:
> N:   Visibility: info
> N:   Show-Always: no
> N:   Check: debian/shlibs
> 
> As noted in the text of the checks, there are scenarios where these do not
> apply (like small packages that include the runtime and the development
> files), which appears to be the case with qt5ct.  Can you please help me to
> understand why qt5ct is including this shared library, if there are any 
other
> packages in Debian that are building against this library, and if you feel
> that any of the lintian checks above apply?  If you feel they don’t apply I
> would recommend you add lintian overrides and I will be happy to upload your
> package.
> 
> Soren


-- 
Soren Stoutner
so...@debian.org

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

Bug#1065564: debian-edu-config: LTSP clients: all kernel logs are shown during boot

[Serhii Horichenko]

Package: src:debian-edu-config
Version: 2.12.44~deb12u1

LTSP clients don't boot with a boot splash, all kernel logs are shown
during boot

Sincerely,
Serhii Horichenko

Bug#1065483: perl-base: should provide perlapi-5.38.2 on i386

[Steve Langasek]

On Tue, Mar 05, 2024 at 11:47:39AM +0100, Sven Joachim wrote:
> Package: perl-base
> Version: 5.38.2-3.1
> Severity: serious
> X-Debbugs-Cc: Sven Joachim , Steve Langasek 
> 

> On i386, perl-base provides perlapi-5.38.2t64 rather than
> perlapi-5.38.2.  This makes tons of packages uninstallable or
> unbuildable and is not what has been agreed upon in #1060246.

> The reason is a bad check in debian/rules, line 31:

> ,
> | # If nonempty, this will determine $Config{debian_abi} and Provides: entries
> | # (otherwise, the Provides: entries will be generated by debian/mkprovides)
> | perlabi =
> | ifeq (,$(filter $(DEB_HOST_GNU_TYPE),i386 hurd-i386))
> |   ifeq ($(DEB_HOST_ARCH_BITS),32)
> | perlabi = 5.38.2t64
> |   endif
> | endif
> `

Sorry about this.  Clearly, was untested on i386!

I think it's preferable here to check DEB_HOST_ARCH, which was my intention,
rather than DEB_HOST_GNU_TYPE.  I've uploaded an NMU to that effect.  Please
see the NMU debdiff attached.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru perl-5.38.2/debian/changelog perl-5.38.2/debian/changelog
--- perl-5.38.2/debian/changelog2024-03-02 21:34:58.0 +
+++ perl-5.38.2/debian/changelog2024-03-06 17:19:01.0 +
@@ -1,3 +1,12 @@
+perl (5.38.2-3.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix check for i386 to avoid transitioning there.  Closes: #1065483.
+  * Manually add perlapi-5.38.2t64 to Provides: on i386 to avoid another
+difficult transition.
+
+ -- Steve Langasek   Wed, 06 Mar 2024 17:19:01 +
+
 perl (5.38.2-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru perl-5.38.2/debian/control perl-5.38.2/debian/control
--- perl-5.38.2/debian/control  2024-03-02 21:34:58.0 +
+++ perl-5.38.2/debian/control  2024-03-06 17:19:01.0 +
@@ -81,6 +81,7 @@
  libfile-temp-perl (= 0.2311),
  libfile-path-perl (= 2.18),
  libio-socket-ip-perl (= 0.41),
+ perlapi-5.38.2t64 [i386 hurd-i386],
 Suggests: perl, sensible-utils
 Description: minimal Perl system
  Perl is a scripting language used in many system scripts and utilities.
diff -Nru perl-5.38.2/debian/rules perl-5.38.2/debian/rules
--- perl-5.38.2/debian/rules2024-03-02 21:34:58.0 +
+++ perl-5.38.2/debian/rules2024-03-06 17:18:00.0 +
@@ -24,13 +24,14 @@
 DEB_BUILD_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
 DEB_HOST_GNU_TYPE   ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
 DEB_HOST_ARCH_BITS  ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_BITS)
+DEB_HOST_ARCH   ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
 
 # If nonempty, this will determine $Config{debian_abi} and Provides: entries
 # (otherwise, the Provides: entries will be generated by debian/mkprovides)
 perlabi =
-ifeq (,$(filter $(DEB_HOST_GNU_TYPE),i386 hurd-i386))
+ifeq (,$(filter $(DEB_HOST_ARCH),i386 hurd-i386))
   ifeq ($(DEB_HOST_ARCH_BITS),32)
-perlabi = 5.38.2t64 
+perlabi = 5.38.2t64
   endif
 endif
 


signature.asc
Description: PGP signature

Bug#1065563: salsa: typo "branch as no origin"

[Jakub Wilk]

Package: devscripts
Version: 2.23.7
Severity: minor
Tags: patch

--
Jakub Wilk
diff --git a/lib/Devscripts/Salsa/merge_request.pm b/lib/Devscripts/Salsa/merge_request.pm
index 89152aa9..7682bb52 100644
--- a/lib/Devscripts/Salsa/merge_request.pm
+++ b/lib/Devscripts/Salsa/merge_request.pm
@@ -47,3 +47,3 @@ sub merge_request {
 ds_warn
-  "Current branch as no origin or isn't pushed, aborting";
+  "Current branch has no origin or isn't pushed, aborting";
 return 1;

Bug#1065562: bookworm-pu: package postfix/3.7.10-0+deb12u1

[Scott Kitterman]

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

[ Reason ]
Standard postfix post-release update

[ Impact ]
They will still have the bugs that are fixed by this update.

[ Tests ]
There is an autopkgtest, which passes locally.  I also have the package
in production on one server and it is running fine.

[ Risks ]
Risk is low.  Changes are relatively minor and are as released by
upstream, which has an excellent track record for such things.

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

[ Changes ]
  * 3.7.11
- Bugfix (defect introduced: Postfix 2.3, date 20051222): the
  Dovecot auth client did not reset the 'reason' from  a
  previous Dovecot auth service response, before parsing the
  next Dovecot auth server response in the same SMTP session.
  Reported by Stephan Bosch, File: xsasl/xsasl_dovecot_server.c.
- Cleanup: Postfix SMTP server response with an empty
  authentication failure reason. File: smtpd/smtpd_sasl_glue.c.
- Bugfix (defect introduced: Postfix 3.1, date: 20151128):
  "postqueue -j" produced broken JSON when escaping a control
  character as \u. Found during code maintenance. File:
  postqueue/showq_json.c.
- Cleanup: posttls-finger certificate match expectations for
  all TLS security levels, including warnings for levels that
  don't implement certificate matching. Viktor Dukhovni.
  File: posttls-finger.c.
- Bugfix (defect introduced: Postfix 2.3): after prepending
  a message header with a Postfix access table PREPEND action,
  a Milter request to delete or update an existing header
  could have no effect, or it could target the wrong instance
  of an existing header. Root cause: the fix dated 20141018
  for the Postfix Milter client was incomplete. The client
  did correctly hide the first, Postfix-generated, Received:
  header when sending message header information to a Milter
  with the smfi_header() application callback function, but
  it was still hiding the first header (instead of the first
  Received: header) when handling requests from a Milter to
  delete or update an existing header. Problem report by
  Carlos Velasco. This change was verified to have no effect
  on requests from a Milter to add or insert a header. File:
  cleanup/cleanup_milter.c.
- Workaround: tlsmgr logfile spam. Some OS lies under load:
  it says that a socket is readable, then it says that the
  socket has unread data, and then it says that read returns
  EOF, causing Postfix to spam the log with a warning message.
  File: tlsmgr/tlsmgr.c.
- Bugfix (defect introduced: Postfix 3.4): the SMTP server's
  BDAT command handler could be tricked to read $message_size_limit
  bytes into memory. Found during code maintenance. File:
  smtpd/smtpd.c.
- Performance: eliminate worst-case behavior where the queue
  manager defers delivery to all destinations over a specific
  delivery transport, after only a single delivery agent
  failure. The scheduler now throttles one destination, and
  allows deliveries to other destinations to keep making
  progress. Files: *qmgr/qmgr_deliver.c.
- Safety: drop and log over-size DNS responses resulting in
  more than 100 records. This 20x larger than the number of
  server addresses that the Postfix SMTP client is willing
  to consider when delivering mail, and is well below the
  number of records that could cause a tail recursion crash
  in dns_rr_append() as reported by Toshifumi Sakaguchi. This
  also limits the number of DNS requests from check_*_*_access
  restrictions. Files: dns/dns.h, dns/dns_lookup.c, dns/dns_rr.c,
  dns/test_dns_lookup.c, posttls-finger/posttls-finger.c,
  smtp/smtp_addr.c, smtpd/smtpd_check.c.

[ Other info ]
N/A

Scott K
diff -Nru postfix-3.7.10/debian/changelog postfix-3.7.11/debian/changelog
--- postfix-3.7.10/debian/changelog 2024-01-26 18:44:58.0 -0500
+++ postfix-3.7.11/debian/changelog 2024-03-06 10:10:14.0 -0500
@@ -1,3 +1,66 @@
+postfix (3.7.11-0+deb12u1) bookworm; urgency=medium
+
+  [Wietse Venema]
+
+  * 3.7.11
+- Bugfix (defect introduced: Postfix 2.3, date 20051222): the
+  Dovecot auth client did not reset the 'reason' from  a
+  previous Dovecot auth service response, before parsing the
+  next Dovecot auth server response in the same SMTP session.
+  Reported by Stephan Bosch, File: xsasl/xsasl_dovecot_server.c.
+- Cleanup: Postfix SMTP server response with an empty
+  authentication failure reason. File: smtpd/smtpd_sasl_glue.c.
+- Bugfix (

Bug#1065561: console-setup: typos in documentation

[Jakub Wilk]

Source: console-setup
Version: 1.226
Severity: minor
Tags: patch

--
Jakub Wilk
diff --git a/README.legacyfonts b/README.legacyfonts
index a707fcc..2078725 100644
--- a/README.legacyfonts
+++ b/README.legacyfonts
@@ -4,3 +4,3 @@ LEGACY FONTS: CONVERSION FROM PSF TO BDF
 
-The traditional font collection for Linux consolle was a big mess.
+The traditional font collection for Linux console was a big mess.
 There were many different fonts and nobody in the world knew the exact
@@ -18,4 +18,4 @@ generated for a group of fonts that share common typeface.  Console
 fonts that didn't have embedded Unicode table were simply ignored.
-The fonts LatArCyrHeb* were also ignored - partialy due to technical
-reasons and partialy because the other BDF fonts are better source for
+The fonts LatArCyrHeb* were also ignored - partially due to technical
+reasons and partially because the other BDF fonts are better source for
 making Unicode console fonts.
@@ -43,3 +43,3 @@ For example Greek-vga14.psf is the legacy font for Greek code set and
 size 14.  The list of BDF fonts that is used to produce
-Greek-vga14.psf was determined as folows.
+Greek-vga14.psf was determined as follows.
 
diff --git a/doc/console-setup.html/ch3.html b/doc/console-setup.html/ch3.html
index c2d3a1f..bc74c33 100644
--- a/doc/console-setup.html/ch3.html
+++ b/doc/console-setup.html/ch3.html
@@ -64,4 +64,4 @@ for a group of fonts that share common typeface.  Console fonts that didn't
 have embedded Unicode table were simply ignored.  The fonts
-LatArCyrHeb* were also ignored - partialy due to technical reasons
-and partialy because the other BDF fonts are better source for making Unicode
+LatArCyrHeb* were also ignored - partially due to technical reasons
+and partially because the other BDF fonts are better source for making Unicode
 console fonts.
@@ -148,3 +148,3 @@ fonts.  This font is named after the scheme
 size 14.  The list of BDF fonts that is used to produce Greek-vga14.psf was
-determined as folows.
+determined as follows.
 
diff --git a/doc/console-setup.sgml b/doc/console-setup.sgml
index 46e16a6..54f7fdf 100644
--- a/doc/console-setup.sgml
+++ b/doc/console-setup.sgml
@@ -388,3 +388,3 @@ Console fonts that didn't have embedded Unicode table were simply
 ignored.  The fonts LatArCyrHeb* were also ignored -
-partialy due to technical reasons and partialy because the other BDF
+partially due to technical reasons and partially because the other BDF
 fonts are better source for making Unicode console fonts.
@@ -465,3 +465,3 @@ from the legacy fonts.  This font is named after the scheme
 set and size 14.  The list of BDF fonts that is used to produce
-Greek-vga14.psf was determined as folows.
+Greek-vga14.psf was determined as follows.