Bug#1074089: gnome: No sound output through HDMI cable

[Olivier]

Package: gnome
Version: 1:43+1
Severity: normal
X-Debbugs-Cc: bugreports2...@ariadacapo.net

Dear Maintainer,

on my laptops, in Gnome, there is no sound output through the HDMI cable.

I am connecting to a large whiteboard screen of the brand "Smart" with a good-
quality, known-to-work HDMI cable. In the sound settings, I can select HDMI as
an Output Device, and I can see the level monitor moving (indicating there is a
sound signal produced), but no sound is heard on the board.

The problem occurs:
 * On my up-to-date, clean-install Debian 12 gnome
 * Upon booting the debian-live-12.5.0-amd64-gnome.iso live image

The problem does NOT occur:
 * Upon booting the debian-live-12.5.0-amd64-kde.iso
 * Upon booting ubuntu-22.04.4-desktop-amd64.iso

The above is true on both my laptops: one Dell Latitude 7280 and one Lenovo
Thinkpad X260 (same cable, same external screen).

The options available in alsamixer and pavucontrol are exactly the same in both
Debian 12 Gnome and KDE.

Together with this bug report I send my warm thanks for the high-quality work
of the Debian community all these years.


-- 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-21-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome depends on:
ii  avahi-daemon 0.8-10
ii  cheese   43.0-1
ii  cups-pk-helper   0.2.6-1+b1
ii  desktop-base 12.0.6+nmu1~deb12u1
ii  evolution3.46.4-2
ii  evolution-plugins3.46.4-2
ii  file-roller  43.0-1
ii  gnome-calendar   43.1-2
ii  gnome-clocks 43.0-1
ii  gnome-color-manager  3.36.0-1+b1
ii  gnome-core   1:43+1
ii  gnome-maps   43.5-2~deb12u1
ii  gnome-music  42.1-1
ii  gnome-sound-recorder 43~beta-1
ii  gnome-tweaks 42~beta-4
ii  gnome-weather43.0-1
ii  gstreamer1.0-libav   1.22.0-2
ii  gstreamer1.0-plugins-ugly1.22.0-2+deb12u1
ii  libgsf-bin   1.14.50-1
ii  libproxy1-plugin-networkmanager  0.4.18-1.2
ii  libreoffice-calc 4:7.4.7-1+deb12u2
ii  libreoffice-gnome4:7.4.7-1+deb12u2
ii  libreoffice-impress  4:7.4.7-1+deb12u2
ii  libreoffice-writer   4:7.4.7-1+deb12u2
ii  network-manager-gnome1.30.0-2
ii  orca 43.1-1
ii  rhythmbox3.4.6-2+b1
ii  rhythmbox-plugin-cdrecorder  3.4.6-2+b1
ii  rhythmbox-plugins3.4.6-2+b1
ii  rygel-playbin0.42.1-1
ii  rygel-tracker0.42.1-1
ii  seahorse 43.0-1
ii  shotwell 0.30.17-1+b1
ii  simple-scan  42.5-2
ii  totem-plugins43.0-2
ii  xdg-user-dirs-gtk0.11-1

Versions of packages gnome recommends:
ii  gnome-games   1:43+1
ii  gnome-initial-setup   43.2-6
ii  gnome-remote-desktop  43.3-1
ii  transmission-gtk  3.00-2.1+deb12u1

Versions of packages gnome suggests:
pn  alacarte  
pn  empathy   
pn  firefox-esr-l10n-all | firefox-l10n-all   
pn  polari
ii  sound-juicer  3.38.0-2.1
pn  vinagre   
pn  webext-ublock-origin-firefox | webext-ublock-origin-chromium  

Versions of packages gnome-core depends on:
ii  adwaita-icon-theme43-1
ii  at-spi2-core  2.46.0-5
ii  baobab43.0-1
ii  dconf-cli 0.40.0-4
ii  dconf-gsettings-backend   0.40.0-4
ii  eog   43.2-1
ii  evince43.1-2+b1
ii  evolution-data-server 3.46.4-2
ii  fonts-cantarell   0.303.1-1
ii  gdm3  43.0-3
ii  gkbd-capplet  3.28.1-1
ii  glib-networking   2.74.0-4
ii  gnome-backgrounds 43.1-1
ii  gnome-bluetooth-sendto42.5-3
ii  gnome-calculator  1:43.0.1-2
ii  gnome-characters  43.1-1+deb12u1
ii  gnome-contacts43.1-1
ii  gnome-control-center  1:43.6-2~deb12u1
ii  gnome-disk-utility43.0-1
ii  gnome-font-viewer 43.0-1
ii  gnome-keyring 42.1-1+b2
ii  gnome-logs43.0-1
ii  gnome-menus 

Bug#1074088: bookworm-pu: package cjson/1.7.15-1+deb12u2

[Maytham Alsudany]

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

[ Reason ]
CVE-2024-31755

[ Impact ]
Segmentation violation via the cJSON_SetValuestring function.
If the valuestring passed to cJSON_SetValuestring is NULL, a null
pointer dereference will happen, which can potentially cause denial of
service (DOS).

[ Tests ]
Upstream's tests continue to pass, no new tests were added since this is
a trivial change.

[ Risks ]
Minimal risk as the patch is trivial and only changes 1 line to fix this
security issue.

[ 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 ]
  * Backport patch to add NULL check to cJSON_SetValuestring (CVE-2024-31755)
(Closes: #1071742)

[ Other info ]
Security team have marked it no-dsa.

-- 
Maytham Alsudany
Debian Maintainer

maytham @ OFTC
maytha8 @ Libera

diff -Nru cjson-1.7.15/debian/changelog cjson-1.7.15/debian/changelog
--- cjson-1.7.15/debian/changelog	2024-04-09 09:30:29.0 +0800
+++ cjson-1.7.15/debian/changelog	2024-06-23 14:27:41.0 +0800
@@ -1,3 +1,11 @@
+cjson (1.7.15-1+deb12u2) bookworm; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport patch to add NULL check to cJSON_SetValuestring (CVE-2024-31755)
+(Closes: #1071742)
+
+ -- Maytham Alsudany   Sun, 23 Jun 2024 14:27:41 +0800
+
 cjson (1.7.15-1+deb12u1) bookworm; urgency=medium
 
   * Non-maintainer upload.
diff -Nru cjson-1.7.15/debian/patches/0002-add-null-check-to-cjson-setvaluestring.patch cjson-1.7.15/debian/patches/0002-add-null-check-to-cjson-setvaluestring.patch
--- cjson-1.7.15/debian/patches/0002-add-null-check-to-cjson-setvaluestring.patch	1970-01-01 08:00:00.0 +0800
+++ cjson-1.7.15/debian/patches/0002-add-null-check-to-cjson-setvaluestring.patch	2024-06-23 14:27:41.0 +0800
@@ -0,0 +1,23 @@
+Origin: backport, https://github.com/DaveGamble/cJSON/commit/7e4d5dabe7a9b754c601f214e65b544e67ba9f59
+From: Up-wind 
+Bug: https://github.com/DaveGamble/cJSON/issues/839
+Bug-Debian: https://bugs.debian.org/1071742
+Acked-by: Maytham Alsudany 
+Subject: [PATCH] Add NULL check to cJSON_SetValuestring()
+ If the valuestring passed to cJSON_SetValuestring is NULL, a null pointer
+ dereference will happen. This patch adds the NULL check of valuestring before
+ it is dereferenced.
+ .
+ Fix for CVE-2024-31755.
+
+--- a/cJSON.c
 b/cJSON.c
+@@ -406,7 +406,7 @@ CJSON_PUBLIC(char*) cJSON_SetValuestring(cJSON *object, const char *valuestring)
+ return NULL;
+ }
+ /* return NULL if the object is corrupted */
+-if (object->valuestring == NULL)
++if (object->valuestring == NULL || valuestring == NULL)
+ {
+ return NULL;
+ }
diff -Nru cjson-1.7.15/debian/patches/series cjson-1.7.15/debian/patches/series
--- cjson-1.7.15/debian/patches/series	2024-04-09 09:29:47.0 +0800
+++ cjson-1.7.15/debian/patches/series	2024-06-23 14:27:41.0 +0800
@@ -1 +1,2 @@
 0001-add-null-checkings.patch
+0002-add-null-check-to-cjson-setvaluestring.patch


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

Bug#1068126: #1068126 firefox: No video, no codecs found

[Eduard Bloch]

On Sun, 2 Jun 2024 21:12:40 -0700 Michael Evans  wrote:
> I had a very similar / the same? issue.
> 
> Please check Firefox's Bugzilla for more details / troubleshooting
> steps if your issue is different:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1887735
> 
> (my) resolution steps:
> about:config
> CORRECT SETTING: media.rdd-process.enabled = true // Default
> 
> My final troubleshooting steps:
> * A broken profile
> * A newly created 'clean' test profile
> (which worked, pointing me to a profile specific issue)
> * MOZ_LOG="PlatformDecoderModule:5" firefox --profile 7lnvxapn.TestTemplate
> Console output log
> * about:support
> Detailed summary including the missing RDD process breadcrumb.
> 
> 

Bug#1071860: not fixed in 7.0-005-2 (was: Bug#1071860 closed by Debian FTP Masters (reply to Andreas Tille ) (Bug#1071860: fixed in fis-gtm 7.0-005-

[Andreas Metzler]

Control: reopen 1071860

On 2024-06-22 Debian Bug Tracking System  wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:fis-gtm package:

> #1071860: fis-gtm: Searches for libgcrypt with libgcrypt-config

> It has been closed by Debian FTP Masters  
> (reply to Andreas Tille ).
[...]
>  fis-gtm (7.0-005-2) unstable; urgency=medium
>  .
>* Build-Depends: s/libgcrypt20-dev | //, pkgconf
>  Closes: #1071860
[...]

> From: Andreas Metzler 
> To: Debian Bug Tracking System 
> Subject: fis-gtm: Searches for libgcrypt with libgcrypt-config
> Message-ID: 
[...]
> fis-gtm relies on libgcrypt-config to locate libgcrypt. libgcrypt-config
> is scheduled for removal and will be dropped in libgcrypt 1.11. Please
> use pkg-config/pkgconf instead.

Hello,

This is unfixed, trying to rebuild fis-gtm (7.0-005-2) without
/usr/bin/libgcrypt-config results in:

make[1]: Entering directory '/tmp/fis-gtm-7.0-005'
dh_auto_configure -- -DCMAKE_INSTALL_PREFIX:PATH=/usr 
-DGTM_INSTALL_DIR=lib/x86_64-linux-gnu/fis-gtm/V7.0-005_x86_64 
-DCMAKE_BUILD_TYPE=Release
cd obj-x86_64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb cmake 
-DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None 
-DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var 
-DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON 
-DFETCHCONTENT_FULLY_DISCONNECTED=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run 
-DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON "-GUnix Makefiles" 
-DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu 
-DCMAKE_INSTALL_PREFIX:PATH=/usr 
-DGTM_INSTALL_DIR=lib/x86_64-linux-gnu/fis-gtm/V7.0-005_x86_64 
-DCMAKE_BUILD_TYPE=Release ..
-- The C compiler identification is GNU 13.3.0
-- The ASM compiler identification is GNU
-- Found assembler: /usr/lib/ccache/cc
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/lib/ccache/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
--> OS = Linux / ARCH = x86_64
-- Bootstraping from pre-generated sources.
INFO: Using ssl.h /usr/include/openssl/ssl.h
CMake Error at CMakeLists.txt:529 (message):
  FATAL: libgcrypt-config not found (LIBGCRYPT_CONFIG_SCRIPT-NOTFOUND)
[...]

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#1074087: bookworm-pu: package debvm/0.2.10+deb12u1

[Helmut Grohne]

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

[ Reason ]

The primary reason for doing a stable upload is that login has become
non-essential in unstable. Thus the default experience of "debvm-create
&& debvm-run" which spawns an unstable vm will lack the login package
and thus result in a respawning getty. That's not a nice default
experience.

As I go through the pu process, I considered other patches that would be
reasonable to backport.
 * debvm-run fails hard when TERM happens to be unset.
 * debvm-create installs a broken resolv.conf for Debian stretch.
 * debvm-waitssh does not correctly parse --timeout=123.

I hope you can agree to also add these targeted fixes.

[ Impact ]

The default experience of debvm will be impacted. Most of the problems
can be worked around at ease:

 * login: debvm-create ... --include=login
 * TERM: TERM=something debvm-run ...
 * --timeout: debvm-waitssh --timeout 123

[ Tests ]

None of the relevant changes happen to be covered by automated tests
unfortunately. I have resorted performing manual tests of these changes.
All but the login change have been part of unstable for quite a while
already.

[ Risks ]

The relevant changes have relatively low risks of introducing
regressions, because the changes mostly turn failing code paths into
non-failing ones and otherwise do not affect behaviour.

[ Checklist ]
  [ ] *all* changes are documented in the d/changelog
  Not yet. All changes are documented in git and I intend to run
  gbp dch at upload time.
  [*] I reviewed all changes and I approve them
  [ ] attach debdiff against the package in (old)stable
  I opted for attaching a git log and hope this also works for you,
  because gives more details for the targeted fixes and contains
  what will end up in the debian/changelog.
  [*] the issue is verified as fixed in unstable

[ Changes ]

I think this is covered by the attached git log.

[ Other info ]

If you think that none of the changes warrant a stable upload because
their severity is not sufficiently important and they can be worked
around, please close this bug tagging it wontfix. If you object to
individual fixes, I am happy to reduce the scope.

You may find my git branch at:
https://salsa.debian.org/helmutg/debvm/-/tree/debian/bookworm

Helmut
commit 137d9a489bb022af8a082d9990846809ab3b4466
Author: Helmut Grohne 
Date:   Sun Jun 23 06:29:44 2024 +0200

debvm-create: do install login

login has become non-essential and autologin simply respawns
indefinitely when login is not installed. We better install it
explicitly and that works on all releases. If we are only interested in
logging in via ssh (and thus --skip=autologin), no login package is
needed.

(cherry picked from commit aba9e12e719375d7032d7b88268dbea5036d6035)

diff --git a/bin/debvm-create b/bin/debvm-create
index 1c7c29d..0fb9654 100755
--- a/bin/debvm-create
+++ b/bin/debvm-create
@@ -386,7 +386,9 @@ if ! check_skip usrmerge; then
 fi
 
 if ! check_skip autologin; then
-   set -- "--customize-hook=$SHARE_DIR/customize-autologin.sh" "$@"
+   set -- \
+   --include=login \
+   "--customize-hook=$SHARE_DIR/customize-autologin.sh" "$@"
 fi
 
 set -- "$SUITE" "$IMAGE" "$@"

commit 8af26f324f0f20b2bba961974d60c29b64257b6b
Author: Johannes Schauer Marin Rodrigues 
Date:   Sun Sep 24 00:39:48 2023 +0200

bin/debvm-waitssh: make --timeout=N work

(cherry picked from commit 73a4050552c2f2c620362beb6f9fd7ca86b9377c)

diff --git a/bin/debvm-waitssh b/bin/debvm-waitssh
index 2b843a5..199903f 100755
--- a/bin/debvm-waitssh
+++ b/bin/debvm-waitssh
@@ -107,7 +107,7 @@ while getopts :qt:-: OPTCHAR; do
"opt_$OPTARG" "$(nth_arg "$OPTIND" 
"$@")"
OPTIND=$((OPTIND+1))
;;
-   timeout=)
+   timeout=*)
"opt_${OPTARG%%=*}" "${OPTARG#*=}"
;;
*)

commit 0015617762916b6efa2fc3ac01ecbf3e267c900b
Author: Jochen Sprickerhof 
Date:   Tue Jul 25 14:45:51 2023 +0200

Fix resolv.conf in stretch

stub-resolv.conf was introduced in systemd 236 (e6b2d948f8).

Regression of c751e22.

(cherry picked from commit efc7b2e5a831c8b996e7dd39a2c4f3898872b883)

diff --git a/share/customize-resolved.sh b/share/customize-resolved.sh
index e8fe248..8885d18 100755
--- a/share/customize-resolved.sh
+++ b/share/customize-resolved.sh
@@ -18,7 +18,7 @@ if dpkg --compare-versions "$LIBNSS_RESOLVE_VERSION" lt 
251.3-2~exp1; then
chroot "$TARGET" systemctl enable systemd-resolved.service
fi
 
-   if test -z "$LIBNSS_RESOLVE_VERSION"; then
+   i

Bug#1074086: /usr/sbin/coldreboot is ineffectively diverted by bfh-container, molly-guard and progress-linux-container

[Helmut Grohne]

Package: kexec-tools
Version: 1:2.0.27-1.2
Severity: serious
User: helm...@debian.org
Usertags: dep17p3
Control: affects -1 + bfh-container molly-guard progress-linux-container
X-Debbugs-Cc: z...@debian.org

coldreboot is being moved from /bin to /usr/bin. Unfortunately,
bfh-container, molly-guard and progress-linux-container divert this
location causing problems.

I think we need the same (or similar) dance as with systemd-sysv. Each
of those packages needs to install mitigations and kexec-tools needs
versioned conflicts with unfixed versions of those.

Arguably, combining bfh-container or progress-linux-container with
kexec-tools is not a reasonable thing to do. In those cases, unversioned
conflicts may be applicable though they are not technically policy
compliant.

This bug serves as a migration blocker and helps apt-listbugs users with
not loosing their files.

Helmut

Bug#1074085: python3-proto-plus missing Breaks+Replaces with nanopb

[Helmut Grohne]

Package: python3-proto-plus
Version: 1.23.0-3
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + nanopb

Hi,

we're almost done with the file conflict between python3-proto-plus and
nanopb. Thanks for taking the time to work on a proper solution. Now the
python3-proto-plus package still shares files with the nanopb package in
trixie and this breaks smooth upgrades. We really are taking over files
now. When you upgrade python3-proto-plus and have nanopb installed,
nanopb should be upgraded as well to avoid that file conflict. Thus
please add:

Breaks: nanopb (<< 0.4.8-2~)
Replaces: nanopb (<< 0.4.8-2~)

Helmut

Bug#1066043: RFS: lem/2022-12-10+dfsg-1 [ITP] -- Tool merging math and logic for executable definitions (tool)

[Phil Wyett]

On Sun, 2024-06-23 at 08:03 +0800, Bo YU wrote:
> Hi!
> 
> On Sun, Jun 23, 2024 at 1:02 AM Phil Wyett  wrote:
> > On Sun, 2024-06-23 at 00:55 +0800, Bo YU wrote:
> > > Hi philip,
> > > 
> ...
> > Hi Bo,
> > 
> > Thanks for your kind words. I manage mostly and have the support of an 
> > amazing
> > lady. :-)
> > 
> Nice. Thanks to everyone for their contributions to Debian in their own way.:)
> 
> > The issue I detailed in my last mail seems to be the only real blocker that 
> > I
> > can see.
> > 
> 
> Okay. I think I have fixed the issue.
> 
> The first attempt was I use `extend-diff-ignore`, but there were too
> many files automatically generated that need to be matched, so I
> switched it to `debian/rules clean` and it seems it works.
> 
> Another change is that from d/changelog: UNRELEASED -> unstable.
> please notice it.
> 
> ```
> ...
> 
> * Vcs  : https://salsa.debian.org/ocaml-team/lem
>Section  : ocaml
> 
> The source builds the following binary packages:
> 
>   lem - Tool merging math and logic for executable definitions (tool)
>   liblem-ocaml-dev - Tool merging math and logic for executable
> definitions (development)
> 
> To access further information about this package, please visit the
> following URL:
> 
>   https://mentors.debian.net/package/lem/
> 
> Alternatively, you can download the package with 'dget' using this command:
> 
>   dget -x 
> https://mentors.debian.net/debian/pool/main/l/lem/lem_2022-12-10+dfsg-1.dsc
> 
> Changes for the initial release:
> 
>  lem (2022-12-10+dfsg-1) unstable; urgency=low
>  .
>* Initial release. (Closes: #1065658)
> 
> ```
> Thanks again,
> 
> BR,
> Bo
> > 

Morning Bo,

Build after successful build is good.

Skimming through the files.

1. You may want to disable 'export DH_VERBOSE = 1' in 'debian/rules'.

For your notepad for future. :-)

1. 'debian/control', Update 'Standards-Version' to latest.

2. This package release was 2022. The files section in 'debian/copyright' is up
to 2020. A check if anything new has been added, removed or other etc. The usual
fun with making sure the copyright file is accurate.

Other than that, I think a DD from mentors or the OCaml team can look at the
package for possible sponsorship.

Regards

Phil

-- 

Internet Relay Chat (IRC): kathenas

Website: https://kathenas.org

Instagram: https://instagram.com/kathenasorg/

Buy Me A Coffee: https://buymeacoffee.com/kathenasorg


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

Bug#1074084: python3-engineio: Missing dependency simple-websocket>=0.10.0

[Johnny Accot]

Package: python3-engineio
Version: 4.9.0-2
Severity: normal
X-Debbugs-Cc: ac...@free.fr

python-engineio's pyproject.toml has the following dependencies [1]:

  dependencies = ["simple-websocket >= 0.10.0"]

This module is imported in engineio/async_drivers/_websocket_wsgi.py [2].

But there is no python3-simple-websocket package in debian.

When using pkg_resources to load entry points, I get the following error:

  pkg_resources.DistributionNotFound: The 'simple-websocket>=0.10.0' 
distribution was
  not found and is required by python-engineio

simple-websocket v1.0.0 is available on pypi [3].

[1] 
https://salsa.debian.org/debian/python-engineio/-/blob/debian/master/pyproject.toml
[2] 
https://salsa.debian.org/debian/python-engineio/-/blob/debian/master/src/engineio/async_drivers/_websocket_wsgi.py
[3] https://pypi.org/project/simple-websocket/

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

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

Versions of packages python3-engineio depends on:
ii  python3  3.11.8-1

python3-engineio recommends no packages.

python3-engineio suggests no packages.

-- no debconf information

Bug#1073237: Some Button Text Does Not Display with 6.1 Release

[eviljoel]

I really want KeePass 2 to work again. I'm probably willing to submit a patch 
to fix this issue if someone can give me some direction about what an 
acceptable patch is. I can think of three potential solutions:

1) Restore the PANGO_MAX_VERSION lines. This would be the easiest change.
2) Disable pango in a more direct way. I'm not sure if pango support is even 
desired.
3) Fix pango support to render the text correctly. This would require a lot 
more investigation.

Any guidance would be appreciated. Thank you.

Bug#1067578: (no subject)

[S Page]

I suspect the changes in debian packaging are add 
`--enable-cairo-backend` to  the `dh_auto_configure` line in 
debian/rules and add `libcairo2` under `Build-depends:` in 
debian/control. But I'm on Fedora and guessing.

Bug#1074083: create .../man/man/

[Bjarni Ingi Gislason]

Package: man-db
Version: 2.12.1-2
Severity: wishlist

Dear Maintainer,

  The "cat" directories are empty on my computer so there is no saving
there.

  I could use uncompressed man pages for general use,
so I suggest that should be provided if the user wants that.

  Nowadays computers usually have abundant disk place,
and only use a part of the provided software and thus only a part of the
provided man pages by a operation system.

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

Kernel: Linux 6.8.12-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages man-db depends on:
ii  bsdextrautils  2.40.1-8.1
ii  bsdmainutils   12.1.8
ii  debconf [debconf-2.0]  1.5.86
ii  groff-base 1.23.0-4
ii  libc6  2.38-13
ii  libgdbm6t641.23-6
ii  libpipeline1   1.5.7-2
ii  libseccomp22.5.5-1
ii  zlib1g 1:1.3.dfsg+really1.3.1-1

man-db recommends no packages.

Versions of packages man-db suggests:
pn  apparmor   
ii  firefox-esr [www-browser]  115.12.0esr-1
ii  groff  1.23.0-4
ii  less   643-1
ii  lynx [www-browser] 2.9.2-1
 ii  w3m [www-browser]  0.5.3+git20230121-2+b3

-- Configuration Files:
/etc/manpath.config changed [not included]

-- debconf information excluded

Bug#1074082: mmdebstrap: tests expect /var/log/faillog to exist

[Chris Hofstaedtler]

Package: mmdebstrap
Version: 1.5.1-4

Hi!

As you've already noticed, shadow 4.15.2-1 breaks mmdebstrap's
tests.

At least one test (check-against-debootstrap-dist unstable buildd)
is broken like this:

| + cmp /tmp/debian-unstable-debootstrap/var/log/faillog 
/tmp/debian-unstable-mm/var/log/faillog
| cmp: /tmp/debian-unstable-debootstrap/var/log/faillog: No such file or 
directory
| + stat -c %s /tmp/debian-unstable-debootstrap/var/log/faillog
| stat: cannot statx '/tmp/debian-unstable-debootstrap/var/log/faillog': No 
such file or directory
[..]

Indeed newer shadow and PAM versions have removed support for
/var/log/faillog.
It would be great if mmdebstrap would not blindly assume that
faillog must exist. I think the tests already delete faillog
afterwards, but cannot deal with it missing upfront.

Please allow /var/log/faillog to be absent :-)

In the meantime I'll try to understand why it still exists in some
of my tests...

Chris
 

Bug#1074081: grub-efi-amd64: After installing Debian 12.5 on an UEFI system Debian wont boot

[T.Schweikle]

Package: grub-efi-amd64
Version: 2.12-2
Severity: important
Tags: d-i
X-Debbugs-Cc: tschwei...@gmail.com

Dear Maintainer,

   * What led up to the situation?
Installing Debian 12.5 from Debian live media available from
https://mirrors.edge.kernel.org/debian-cd/12.5.0-live/amd64/iso-hybrid/debian-
live-12.5.0-amd64-xfce.iso

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

Installed Debian 12.5 as given above to an UEFI booting system.

   * What was the outcome of this action?

Debian 12.5 installed, but not able to boot. Had to boot an other CD starting
GRUB, then load grub from the Debian installed partition, advice Grub to take
the given grub.cfg on same partition.

   * What outcome did you expect instead?

Installing Debian 12.5, then rebooting, Debian booting without hassles.


PS:
- Booting from the Debian installer disk is imnpossible:
  -- Text-Mode: white screen, cursor upper left corner.
 System shows no further actions.
  -- Graphics mode: x-server terminates with errors: can't find a frame buffer

- Booting in Rescue mode is impossible to. Same problems as above.

It is possible to reproduce these Problems/Errors by booting with
- VirtualBox (all versions capable of booting in UEFI mode)
- VMware (all versions capable of booting in UEFI mode)
- on Hardware capable to boot in UEFI mode

After installing the new installer creates three partitions with gpt-
partitiontables:
- 1. EFI-Partition with type EF02 formated with fat32 (maybe this is wrong and
should be EF00?)
- 2. an ext4 partition for root ("/")
- 3. swap sized to hold complete ram the system has


Within this EFI-Partition all necessary binaries are installed into directory
"Debian". A second directory "boot" is empty.


-- Package-specific info:

*** BEGIN /proc/mounts
/dev/nvme0n1p4 / ext4 rw,noatime,discard 0 0
/dev/nvme0n1p3 /boot/efi vfat 
rw,noatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root cd07d628-9ada-4bdf-aa67-07e7e6f8c707
font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=de_DE
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root cd07d628-9ada-4bdf-aa67-07e7e6f8c707
insmod png
if background_image /usr/share/desktop-base/emerald-theme/grub/grub-16x9.png; 
then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-cd07d628-9ada-4bdf-aa67-07e7e6f8c707' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root 
cd07d628-9ada-4bdf-aa67-07e7e6f8c707
echo'Loading Linux 6.8.12-amd64 ...'
linux   /boot/vmlinuz-6.8.12-amd64 
root=UUID=cd07d628-9ada-4bdf-aa67-07e7e6f8c707 ro  quiet splash 
resume=

Bug#1074080: caja: Four constantly-repeated GLib-GIO-CRITICAL errors noted when launched from terminal

[scott092707]

Package: caja
Version: 1.26.3-1+b1
Severity: normal
X-Debbugs-Cc: scott092...@aol.com

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Scott Jacobs 
To: Debian Bug Tracking System 
Subject: caja: Four constantly-repeated GLib-GIO-CRITICAL errors noted when 
launched from terminal
Bcc: Scott Jacobs 
Message-ID: 
<171909985413.2301933.17173951078890870499.reportbug@ASUS-Prime-B350MA>
X-Mailer: reportbug 13.0.1
Date: Sat, 22 Jun 2024 19:44:14 -0400

Dear Maintainer,

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

   * What led up to the situation?
I was editing a gtk theme, and needed to constantly close/open Caja long parm
list and "env GTK_THEME= ..."
and so ran Caja from terminal, so that after closing it down, I would need only
to click up-arrow and enter
to restart Caja.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Since I have no idea what the cause of this is, I did nothing.

   * What was the outcome of this action?
Four constantly repeated instances of:
(caja:2261560): GLib-GIO-CRITICAL **: 19:22:20.931: GFileInfo created without
standard::sort-order

(caja:2261560): GLib-GIO-CRITICAL **: 19:22:20.931: file
../../../gio/gfileinfo.c: line 2107 (g_file_info_get_sort_order): should not be
reached

(caja:2261560): GLib-GIO-CRITICAL **: 19:22:20.931: GFileInfo created without
standard::symlink-target

(caja:2261560): GLib-GIO-CRITICAL **: 19:22:20.931: file
../../../gio/gfileinfo.c: line 2061 (g_file_info_get_symlink_target): should
not be reached

This seemed not to be continuous, but waited for me to do something in Caja
(select?click/drag/...)

   * What outcome did you expect instead?
No errors.

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


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

Kernel: Linux 6.7.12-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 caja depends on:
ii  caja-common  1.26.3-1
ii  desktop-file-utils   0.27-2
ii  gvfs 1.54.0-4
ii  libatk1.0-0t64   2.52.0-1
ii  libc62.38-11
ii  libcairo-gobject21.18.0-3+b1
ii  libcairo21.18.0-3+b1
ii  libcaja-extension1   1.26.3-1+b1
ii  libexempi8   2.6.5-1
ii  libexif120.6.24-1+b1
ii  libgail-3-0t64   3.24.41-4
ii  libgdk-pixbuf-2.0-0  2.42.12+dfsg-1
ii  libglib2.0-0t64  2.80.2-2
ii  libglib2.0-bin   2.80.2-2
ii  libglib2.0-data  2.80.2-2
ii  libgtk-3-0t643.24.41-4
ii  libice6  2:1.0.10-1+b1
ii  libmate-desktop-2-17t64  1.26.2-1.1+b1
ii  libnotify4   0.8.3-1+b1
ii  libpango-1.0-0   1.52.2+ds-1
ii  libpangocairo-1.0-0  1.52.2+ds-1
ii  libselinux1  3.5-2+b2
ii  libsm6   2:1.2.3-1+b1
ii  libx11-6 2:1.8.7-1+b1
ii  libxml2  2.9.14+dfsg-1.3+b3
ii  mate-desktop 1.26.2-1.1+b1
ii  shared-mime-info 2.4-4

Versions of packages caja recommends:
ii  gvfs-backends  1.54.0-4
ii  gvfs-fuse  1.54.0-4

Versions of packages caja suggests:
ii  engrampa1.26.2-4
pn  gstreamer1.0-tools  
pn  meld

-- no debconf information

Bug#1074074: cupsd fails to start after upgrade

[Michael Gold]

When I run cupsd manually (with or without "-l"), it gets a bit farther,
and then makes a bad call to poll().  strace shows:
583644 getppid()= 583643
583644 kill(583643, SIGUSR1)= 0
583643 <... clock_nanosleep resumed>{tv_sec=0, tv_nsec=962872193}) = ? 
ERESTART_RESTARTBLOCK (Interrupted by signal)
583644 epoll_wait(3,  
583643 --- SIGUSR1 {si_signo=SIGUSR1, si_code=SI_USER, si_pid=583644, 
si_uid=0} ---
583644 <... epoll_wait resumed>0x7fd0b8400010, 1073741816, 1000) = -1 
EINVAL (Invalid argument) 
583643 rt_sigreturn({mask=[]} 
583644 close(3 
583643 <... rt_sigreturn resumed>)  = -1 EINTR (Interrupted system 
call)
583644 <... close resumed>) = 0
583644 poll(NULL, 2, 1000)  = -1 EFAULT (Bad address)
583644 write(5, "X [22/Jun/2024:19:04:00 -0400] cupsdDoSelect() failed 
- Bad address!\n", 69) = 69
583644 write(5, "X [22/Jun/2024:19:04:00 -0400] Listeners[0] = 6\n", 
48) = 48
583644 write(5, "X [22/Jun/2024:19:04:00 -0400] CGIPipes[0] = 7\n", 47) 
= 47
583644 write(5, "X [22/Jun/2024:19:04:00 -0400] printer[narshe] 
reg_name=\"(null)\"\n", 65 
583643 exit_group(0 
583644 <... write resumed>) = 65
583643 <... exit_group resumed>)= ?
583644 write(5, "X [22/Jun/2024:19:04:00 -0400] printer[narshe-user] 
reg_name=\"(null)\"\n", 70) = 70
583644 write(5, "X [22/Jun/2024:19:04:00 -0400] printer[PDF] 
reg_name=\"(null)\"\n", 62) = 62
583644 write(5, "E [22/Jun/2024:19:04:00 -0400] Scheduler shutting down 
due to program error.\n", 77) = 77

I don't see any documentation to suggest any operating system would
accept a null pointer for poll().  Linux does not seem to like it, at
least when nfds > 0.

-- Michael


signature.asc
Description: PGP signature

Bug#1074079: libass9: regression from 0.17.1 causes wrong font width variant to be selected

[cherriery]

Package: libass9
Version: 1:0.17.2-2
Severity: normal
X-Debbugs-Cc: cherri...@protonmail.com

Dear Maintainer,

A regression bug in 0.17.2 causes the default variant for Noto Sans to be Noto
Sans Condensed, not Noto Sans Regular. Potentially, a lot of other fonts are
affected as well. This causes the default user interface in mpv to display text
that is harder to read. The bug is solved in the latest git version. A
temporary workaround is to set osd-font and sub-font to Noto Sans Regular for
mpv, instead of the default value of sans-serif. This might also affect ASS
subtitles that specify a certain font, though I haven't tested it.

https://github.com/libass/libass/issues/770

Additional screenshots of the issue can be found at this forum discussion:
https://forum.manjaro.org/t/mpv-has-switched-to-a-very-narrow-font/162390


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

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

Bug#1074077: chromium: [0622/170142.247899:ERROR:elf_dynamic_array_reader.h(64)] tag not found

[Andres Salomon]

Since this is hardware-specific, I likely won't be able to reproduce it. 
Please file a bug upstream (at https://crbug.com/), include the specific 
hardware/motherboard (and maybe dmesg output) in your bug report, and 
respond to this bug report with a link to the upstream bug. Thanks!


On 6/22/24 18:09, Jon Davis wrote:

Package: chromium
Version: 125.0.6422.60-1
Severity: normal

Dear Maintainer,

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


    * What led up to the situation?

     After a motherboard upgrade, chromium and all other available 
versions of

     the browser failed to run.

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

     Trying other versions of chrome caused the same error message and core
     dump.

* What was the outcome of this action?

      Suspicion that the chrome browsers have a race condition bug in the
      initialization process, triggered by the higher CPU clock speed.

      The initial browser with a 125... version which failed was operating
      fine with the old motherboard running at 2GHz.

    * What outcome did you expect instead?

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


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

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

Versions of packages chromium depends on:
ii  chromium-common                                    125.0.6422.60-1
ii  libasound2t64                                      1.2.11-1+b1
ii  libatk-bridge2.0-0t64                              2.52.0-1
ii  libatk1.0-0t64                                     2.52.0-1
ii  libatomic1                                         14-20240330-1
ii  libatspi2.0-0t64                                   2.52.0-1
ii  libc6                                              2.38-13
ii  libcairo2                                          1.18.0-3+b1
ii  libcups2t64                                        2.4.7-3
ii  libdav1d7                                          1:1.4.3-dmo1
ii  libdbus-1-3                                        1.14.10-4+b1
ii  libdouble-conversion3                              3.3.0-1+b1
ii  libdrm2                                            2.4.121-2
ii  libevent-2.1-7t64                                  2.1.12-stable-10
ii  libexpat1                                          2.6.2-1
ii  libflac12t64                                       1.4.3+ds-2.1
ii  libfontconfig1                                     2.15.0-1.1
ii  libfreetype6                                       2.13.2+dfsg-1+b4
ii  libgbm1                                            24.0.8-1
ii  libgcc-s1                                          14-20240330-1
ii  libglib2.0-0t64                                    2.80.2-2
ii  libgtk-3-0t64                                      3.24.42-1
ii  libharfbuzz-subset0                                8.3.0-2+b1
ii  libharfbuzz0b                                      8.3.0-2+b1
ii  libjpeg62-turbo                                    1:2.1.5-3
ii  libjsoncpp25                                       1.9.5-6+b2
ii  liblcms2-2                                         2.14-2+b1
ii  libminizip1t64 
1:1.3.dfsg+really1.3.1-1

ii  libnspr4                                           2:4.35-1.1+b1
ii  libnss3                                            2:3.101-1
ii  libopenh264-7                                      1:2.4.1-dmo1
ii  libopenjp2-7                                       2.5.0-2+b3
ii  libopus0                                           1.4-1+b1
ii  libpango-1.0-0                                     1.54.0+ds-1
ii  libpng16-16t64                                     1.6.43-5
ii  libpulse0                                          16.1+dfsg1-5.1
ii  libsnappy1v5                                       1.2.1-1
ii  libstdc++6                                         14-20240330-1
ii  libwoff1                                           1.0.2-2+b1
ii  libx11-6                                           2:1.8.7-1+b1
ii  libxcb1                                            1.17.0-2
ii  libxcomposite1                                     1:0.4.5-1+b1
ii  libxdamage1                                        1:1.1.6-1+b1
ii  libxext6                                           2:1.3.4-1+b1
ii  libxfixes3                                         1:6.0.0-2+b1
ii  libxkbcommon0                                      1.6.0-1+b1
ii  libxml2                                            2.9.14+dfsg-1.3+b3
ii  libxnvctrl0                                        535.171.04-1
ii  libxrandr2                                         2:1.5.4-1
ii  libxslt1.1                                         1.1.35-1+b1
ii  xdg-desktop

Bug#1074078: python3-doc: curses.wrapper() - unclear about return value and other details

[Michael Gold]

Package: python3-doc
Version: 3.11.8-1
Severity: minor

Dear Maintainer,

The documentation for curses.wrapper says:
Initialize curses and call another callable object, func, which
should be the rest of your curses-using application. If the
application raises an exception, this function will restore the
terminal to a sane state before re-raising the exception and
generating a traceback. The callable object func is then passed the
main window ‘stdscr’ as its first argument, followed by any other
arguments passed to wrapper(). Before calling func, wrapper() turns
on cbreak mode, turns off echo, enables the terminal keypad, and
initializes colors if the terminal has color support. On exit
(whether normally or by exception) it restores cooked mode, turns on
echo, and disables the terminal keypad.

I see several minor problems with this.
1) It doesn't say anything about what's returned on success.  The code
   has the line 'return func(…)', as expected of a wrapper, which is to
   say that it will return whatever the wrapped function returns.
2) There's no code to "generat[e] a traceback".  I guess the assumption
   is that the re-raised assumption will not be caught, and Python will
   do that; but using curses.wrapper that way is merely a suggestion
   ("func[…] should be the rest"…).
3) It says "re-raising the exception and generating a traceback.  The
   callable object func is then passed the main window".  Despite saying
   "then", this is not a linear sequence of events that can happen.
4) "On exit" is unclear about whether it's talking about function exit
   or program exit.

- Michael


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

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

Versions of packages python3-doc depends on:
ii  python3.11-doc  3.11.9-1

python3-doc recommends no packages.

Versions of packages python3-doc suggests:
ii  python3   3.11.8-1
pn  python3-examples  

-- no debconf information


signature.asc
Description: PGP signature

Bug#1074023:

[Artemka]

Package: lightdm

Bug#1073378: chromium with 'Restore Pages' message

[Eric Pruitt]

I'm having this issue with Chromium. Whenever I close the last tab of a
single profile, it causes the entire browser to hard crashed resulting
in ALL open windows closing. When I re-open, I'm prompted to restore the
sessions. This is 100% reproducible for me; every time I close the last
window tied to a profile, the whole browser instantly crashes.

Eric

Bug#1072922: nullmailer: "sendmail -bs" crashes: "traps: nullmailer-smtp[15059] general protection fault ip:7f0368d73dd9 sp:7fff5e3d7088 error:0 in libc.so.6[7f0368c41000+157000]"

[Bernhard Übelacker]

Hello David, hello Axel,



I had hoped the expected behaviour might have been the error message 😉


Maybe it is the expected behaviour?

Following is the output of the last not crashing version 1.13
and the current version in testing 2.2+10~g7ed88a0 with the cli_program fix.

Both look quite similar except the previously crashing error message,
so this is maybe expected by upstream?

Kind regards,
Bernhard


1.13-1.2  ||  2.2+10~g7ed88a0-5  
+  const char* cli_program = "nullmailer-smtpd";
  ||
root@debian:~# swaks -t a...@debian.org --pipe 'sendmail -bs'  ||  
root@debian:~# swaks -t a...@debian.org --pipe 'sendmail -bs'
=== Trying pipe to sendmail -bs...||  === 
Trying pipe to sendmail -bs...
=== Connected to sendmail -bs.||  === 
Connected to sendmail -bs.
<-  220 nullmailer-smtpd ready||  <-  220 
nullmailer-smtpd ready
 -> EHLO debian   ||   -> EHLO 
debian
<-  250 2.3.0 OK  ||  <-  250 
2.3.0 OK
 -> MAIL FROM:   ||   -> MAIL 
FROM:
<-  250 2.1.0 Sender accepted ||  <-  250 
2.1.0 Sender accepted
 -> RCPT TO:  ||   -> RCPT 
TO:
<-  250 2.1.5 Recipient accepted  ||  <-  250 
2.1.5 Recipient accepted
 -> DATA  ||   -> DATA
<-  354 End your message with a period on a line by itself||  <-  354 
End your message with a period on a line by itself
 -> Date: Sun, 23 Jun 2024 00:xx:xx +0200 ||   -> Date: 
Sun, 23 Jun 2024 00:xx:xx +0200
 -> To: a...@debian.org||   -> To: 
a...@debian.org
 -> From: root@debian ||   -> From: 
root@debian
 -> Subject: test Sun, 23 Jun 2024 00:xx:xx +0200 ||   -> 
Subject: test Sun, 23 Jun 2024 00:xx:xx +0200
 -> Message-Id: <2024062300.0x@debian>||   -> Message-Id: 
<2024062300.0x@debian>
 -> X-Mailer: swaks v20170101.0 jetmore.org/john/code/swaks/  ||   -> 
X-Mailer: swaks v20240103.0 jetmore.org/john/code/swaks/
 ->   ||   ->
 -> This is a test mailing||   -> This 
is a test mailing
 ->   ||   ->
  ||   ->
 -> . ||   -> .
  ||  
nullmailer-smtpd: Error catching the return value from nullmailer-queue: No 
child processes
  ||  
nullmailer-smtpd: Error catching the return value from nullmailer-queue: No 
child processes
<** 451 4.3.0 Error checking return status from nullmailer-queue  ||  <** 451 
4.3.0 Error returned from nullmailer-queue
 -> QUIT  ||   -> QUIT
<-  221 2.0.0 Good bye||  <-  221 
2.0.0 Good bye
=== Connection closed with child process. ||  === 
Connection closed with child process.
root@debian:~#||  
root@debian:~#

Bug#1057080: ibus-mozc: Automatically enables itself on non-Japanese systems

[Osamu Aoki]

Hi,

I have a second thought after good night sleep

What Yao Wei (魏銘廷) suggested may be in good direction but I want it 
to be done with **one twist**.

Action 1: add /etc/default/ibus-mozc with its default content

```
# Change "ja_JP" in the following to "ALWAYS" if you wish mozc to be set-up
# under non-Ja_JP environment too.
START_IBUS_MOZC=ja_JP
```

Action2: Modify /usr/share/ibus-mozc/ibus-mozc-gnome-initial-setup.sh 
started by /etc/xdg/autostart/ibus-mozc-gnome-initial-setup.desktop
as:
  * Start this set-up script:
* if START_IBUS_MOZC is not "ja_JP" in /etc/default/ibus-mozc or 
* if LOCALE is "ja_JP"

Action 3: Add README.Debian explaining situation

This way, people like me using mozc under en_US have way to work around the
change proposed by Yao Wei.

osamu

FYI: I still think creating non-DE dependent ibus setup program is a good idea.
Current hackish dconf tweak is rather fragile.

Bug#1074077: chromium: [0622/170142.247899:ERROR:elf_dynamic_array_reader.h(64)] tag not found

[Jon Davis]

Package: chromium
Version: 125.0.6422.60-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

After a motherboard upgrade, chromium and all other available versions
of
the browser failed to run.

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

Trying other versions of chrome caused the same error message and core
dump.

* What was the outcome of this action?

 Suspicion that the chrome browsers have a race condition bug in the
 initialization process, triggered by the higher CPU clock speed.

 The initial browser with a 125... version which failed was operating
 fine with the old motherboard running at 2GHz.

   * What outcome did you expect instead?

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


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

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

Versions of packages chromium depends on:
ii  chromium-common125.0.6422.60-1
ii  libasound2t64  1.2.11-1+b1
ii  libatk-bridge2.0-0t64  2.52.0-1
ii  libatk1.0-0t64 2.52.0-1
ii  libatomic1 14-20240330-1
ii  libatspi2.0-0t64   2.52.0-1
ii  libc6  2.38-13
ii  libcairo2  1.18.0-3+b1
ii  libcups2t642.4.7-3
ii  libdav1d7  1:1.4.3-dmo1
ii  libdbus-1-31.14.10-4+b1
ii  libdouble-conversion3  3.3.0-1+b1
ii  libdrm22.4.121-2
ii  libevent-2.1-7t64  2.1.12-stable-10
ii  libexpat1  2.6.2-1
ii  libflac12t64   1.4.3+ds-2.1
ii  libfontconfig1 2.15.0-1.1
ii  libfreetype6   2.13.2+dfsg-1+b4
ii  libgbm124.0.8-1
ii  libgcc-s1  14-20240330-1
ii  libglib2.0-0t642.80.2-2
ii  libgtk-3-0t64  3.24.42-1
ii  libharfbuzz-subset08.3.0-2+b1
ii  libharfbuzz0b  8.3.0-2+b1
ii  libjpeg62-turbo1:2.1.5-3
ii  libjsoncpp25   1.9.5-6+b2
ii  liblcms2-2 2.14-2+b1
ii  libminizip1t64
1:1.3.dfsg+really1.3.1-1
ii  libnspr4   2:4.35-1.1+b1
ii  libnss32:3.101-1
ii  libopenh264-7  1:2.4.1-dmo1
ii  libopenjp2-7   2.5.0-2+b3
ii  libopus0   1.4-1+b1
ii  libpango-1.0-0 1.54.0+ds-1
ii  libpng16-16t64 1.6.43-5
ii  libpulse0  16.1+dfsg1-5.1
ii  libsnappy1v5   1.2.1-1
ii  libstdc++6 14-20240330-1
ii  libwoff1   1.0.2-2+b1
ii  libx11-6   2:1.8.7-1+b1
ii  libxcb11.17.0-2
ii  libxcomposite1 1:0.4.5-1+b1
ii  libxdamage11:1.1.6-1+b1
ii  libxext6   2:1.3.4-1+b1
ii  libxfixes3 1:6.0.0-2+b1
ii  libxkbcommon0  1.6.0-1+b1
ii  libxml22.9.14+dfsg-1.3+b3
ii  libxnvctrl0535.171.04-1
ii  libxrandr2 2:1.5.4-1
ii  libxslt1.1 1.1.35-1+b1
ii  xdg-desktop-portal-gnome [xdg-desktop-portal-back  44.2-4+b1
end]
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backen  1.15.1-1+b1
d]
ii  xdg-desktop-portal-xapp [xdg-desktop-portal-backe  1.0.6-1
nd]
ii  zlib1g
1:1.3.dfsg+really1.3.1-1

Versions of packages chromium recommends:
ii  chromium-sandbox  125.0.6422.60-1

Versions of packages chromium suggests:
pn  chromium-driver

Bug#1074076: pdns-server: avoid changing permissions of pdns.conf

[Michael Gold]

Package: pdns-server
Version: 4.9.1-1
Severity: wishlist

Dear Maintainer,

While investigating why git kept complaining about the permissions of
/etc/powerdns/pdns.conf, I found that pdns-server.postinst was resetting
them after every upgrade:
case "$1" in
  configure)
addgroup --quiet --system pdns
adduser --quiet --system --home /var/spool/powerdns --shell 
/bin/false --ingroup pdns --disabled-password --disabled-login --gecos 
"PowerDNS" pdns
chown root:pdns /etc/powerdns/pdns.conf || true
chmod 0640 /etc/powerdns/pdns.conf || true

If such a line is needed at all, it should be made optional in some way.
For example, several scripts run 'dpkg-statoverride --list' on a file,
and avoid changing its permissions when an entry is present.

- Michael


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

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

Versions of packages pdns-server depends on:
ii  adduser 3.137
ii  libboost-program-options1.83.0  1.83.0-3
ii  libc6   2.38-13
ii  libcurl4t64 8.8.0-1
ii  libgcc-s1   14.1.0-2
ii  libluajit-5.1-2 2.1.0+openresty20240314-1
ii  libp11-kit0 0.25.3-5
ii  libsodium23 1.0.18-1+b1
ii  libsqlite3-03.46.0-1
ii  libssl3t64  3.2.2-1
ii  libstdc++6  14.1.0-2
ii  libsystemd0 256.1-1

Versions of packages pdns-server recommends:
ii  pdns-backend-bind  4.9.1-1

Versions of packages pdns-server suggests:
ii  pdns-backend-bind [pdns-backend] 4.9.1-1
ii  pdns-backend-pipe [pdns-backend] 4.9.1-1
ii  pdns-backend-remote [pdns-backend]   4.9.1-1
ii  pdns-backend-sqlite3 [pdns-backend]  4.9.1-1

-- Configuration Files:
/etc/powerdns/pdns.conf [Errno 13] Permission denied: '/etc/powerdns/pdns.conf'

-- no debconf information



signature.asc
Description: PGP signature

Bug#1074075: ITP: pa-dlna -- pa-dlna forwards audio streams to DLNA devices

[Sebastian Ramacher]

Package: wnpp
Severity: wishlist
Owner: Sebastian Ramacher 
X-Debbugs-Cc: debian-de...@lists.debian.org, sramac...@debian.org

* Package name: pa-dlna
  Version : 0.11
  Upstream Contact: Xavier de Gaye
* URL : https://gitlab.com/xdegaye/pa-dlna
* License : MIT
  Programming Lang: Python
  Description : pa-dlna forwards audio streams to DLNA devices

A Python project based on asyncio, that uses ctypes to interface with
the libpulse library and supports the PulseAudio and PipeWire sound
servers.

pa-dlna is composed of the following components:

* The pa-dlna program forwards PulseAudio streams to DLNA devices.
* The upnp-cmd is an interactive command line tool for introspection and 
control of UPnP devices.
* The UPnP Python sub-package is used by both commands.


Cheers
-- 
Sebastian Ramacher

Bug#1074073: systemctl: some lines flash for no apparent reason

[Michael Gold]

Package: systemd
Version: 256.1-1
Severity: minor

Dear Maintainer,

When I run systemctl, some lines are under-lined; and since some time
within the last year, these have flashed at about 1 Hz.  It's annoying
and makes them difficult to read.

For example, these lines are affected:
  proc-sys-fs-binfmt_misc.automount
  user.slice

I'm using urxvt, but xterm and mlterm behave the same way.

The under-lining seems non-sensical, although the manual explains it:
  The header and the last unit of a given type are underlined

I find no mention of what the flashing is meant to indicate.  If it's
intentional, it should be explained and there should be some way way to
disable it.

- Michael


-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  libacl12.3.2-2
ii  libapparmor1   3.1.7-1
ii  libaudit1  1:3.1.2-4
ii  libblkid1  2.40.1-8.1
ii  libc6  2.38-13
ii  libcap21:2.66-5
ii  libmount1  2.40.1-8.1
ii  libpam0g   1.5.3-7
ii  libseccomp22.5.5-1
ii  libselinux13.5-2+b2
ii  libssl3t64 3.2.2-1
ii  libsystemd-shared  256.1-1
ii  libsystemd0256.1-1
ii  mount  2.40.1-8.1

Versions of packages systemd recommends:
ii  chrony [time-daemon]4.5-2
ii  dbus [default-dbus-system-bus]  1.14.10-4+b1
ii  libzstd11.5.5+dfsg2-2
pn  systemd-cryptsetup  

Versions of packages systemd suggests:
ii  libcryptsetup12   2:2.7.2-2
ii  libgcrypt20   1.10.3-3
ii  libidn2-0 2.3.7-2
ii  liblz4-1  1.9.4-2
ii  liblzma5  5.6.2-1
pn  libtss2-rc0t64
pn  libtss2-tcti-device0  
ii  polkitd   124-2
pn  systemd-boot  
pn  systemd-container 
pn  systemd-homed 
pn  systemd-repart
pn  systemd-resolved  
pn  systemd-userdbd   

Versions of packages systemd is related to:
ii  dbus-user-session  1.14.10-4+b1
pn  dracut 
ii  initramfs-tools0.142
pn  libnss-systemd 
ii  libpam-systemd 256.1-1
ii  udev   256.1-1

-- no debconf information


signature.asc
Description: PGP signature

Bug#1074074: cups-daemon: cupsd fails to start after upgrade ("No valid Listen or Port lines")

[Michael Gold]

Package: cups-daemon
Version: 2.4.7-3

Dear Maintainer,

I noticed when looking at systemctl that CUPS was no longer running.
lpq shows:
lpq: Unable to connect to server.

/var/log/cups/error_log shows this message:
X [21/Jun/2024:00:00:12 -0400] No valid Listen or Port lines were found 
in the configuration file.
The previous message was in December, and cupsd.conf hasn't been changed
since January.  It contains a Listen line:
# Only listen for connections from the local machine.
#Listen localhost:631
Listen /var/run/cups/cups.sock

I can't think of any reason why it wouldn't be valid.  The directory
still exists.

- Michael


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

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

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


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

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

Versions of packages cups-daemon depends on:
ii  adduser3.137
ii  bc 1.07.1-4
ii  init-system-helpers1.66
ii  libavahi-client3   0.8-13+b2
ii  libavahi-common3   0.8-13+b2
ii  libc6  2.38-13
ii  libcups2t642.4.7-3
ii  libdbus-1-31.14.10-4+b1
ii  libgssapi-krb5-2   1.21.2-1
ii  libpam0g   1.5.3-7
ii  libpaper1  1.1.29+b1
ii  libsystemd0256.1-1
ii  procps 2:4.0.4-4
ii  ssl-cert   1.1.2
ii  sysvinit-utils [lsb-base]  3.09-2

Versions of packages cups-daemon recommends:
pn  avahi-daemon  
pn  colord
pn  cups-browsed  
pn  ipp-usb   

Versions of packages cups-daemon suggests:
ii  cups   2.4.7-3
ii  cups-bsd   2.4.7-3
ii  cups-client2.4.7-3
ii  cups-common2.4.7-3
ii  cups-filters   1.28.17-4
pn  cups-pdf   
ii  cups-ppdc  2.4.7-3
ii  cups-server-common 2.4.7-3
pn  foomatic-db-compressed-ppds | foomatic-db  
ii  ghostscript10.03.1~dfsg-1
ii  poppler-utils  24.02.0-5+b1
pn  smbclient  
ii  udev   256.1-1

-- Configuration Files:
/etc/cups/cups-files.conf changed:
SystemGroup lpadmin
ConfigFilePerm 0644  #mg
LogFileGroup adm
AccessLog /var/log/cups/access_log
ErrorLog /var/log/cups/error_log
PageLog /var/log/cups/page_log


-- no debconf information



signature.asc
Description: PGP signature

Bug#1074072: ITP: python-libpulse -- asyncio interface to the Pulseaudio and Pipewire pulse library

[Sebastian Ramacher]

Package: wnpp
Severity: wishlist
Owner: Sebastian Ramacher 
X-Debbugs-Cc: debian-de...@lists.debian.org, sramac...@debian.org

* Package name: python-libpulse
  Version : 0.2
  Upstream Contact: Xavier de Gaye
* URL : https://gitlab.com/xdegaye/libpulse
* License : MIT
  Programming Lang: Python
  Description : asyncio interface to the Pulseaudio and Pipewire pulse 
library

libpulse is a Python project based on asyncio, that uses ctypes to
interface with the pulse library of the PulseAudio and PipeWire sound
servers. The interface is meant to be complete. That is, all the
constants, structures, plain functions and async functions are made
available by importing the libpulse module of the libpulse package.


Cheers
-- 
Sebastian Ramacher

Bug#1074071: libkf6screen-bin has an undeclared file conflict

[Helmut Grohne]

Package: libkf6screen-bin
Version: 4:6.1.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + libkf5screen-bin

libkf6screen-bin has an undeclared file conflict. This may result in an
unpack error from dpkg.

The files
 * /usr/bin/kscreen-doctor
 * /usr/lib/systemd/user/plasma-kscreen.service
are contained in the packages
 * libkf5screen-bin
   * 4:5.27.11-1 as present in trixie|unstable
   * 4:5.27.5-2 as present in bookworm
 * libkf6screen-bin/4:6.1.0-1 as present in experimental

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected files.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1074070: imgcrypt has an undeclared file conflict on /usr/bin/ctr

[Helmut Grohne]

Package: imgcrypt
Version: 1.1.11-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + containerd

imgcrypt has an undeclared file conflict. This may result in an unpack
error from dpkg.

The file /usr/bin/ctr is contained in the packages
 * containerd
   * 1.4.13~ds1-1~deb11u2 as present in bullseye-security
   * 1.4.13~ds1-1~deb11u4 as present in bullseye
   * 1.6.20~ds1-1+b1 as present in bookworm
   * 1.6.24~ds1-2 as present in trixie|unstable
 * imgcrypt/1.1.11-1 as present in experimental

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected file.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.

Bug#1074069: RFP: canokey-qemu

[proc...@riseup.net]

Package: wnpp
Severity: wishlist


* Package name: canokey-qemu
  Upstream Author : ZenithalHourlyRate Hongren Zheng
* URL : https://github.com/canokeys/canokey-qemu
* License : Apache-2.0 license
  Programming Lang: C
  Description : virtual canokey to the guest OS

CanoKey [1] is an open-source secure key with supports of:

- U2F / FIDO2 with Ed25519 and HMAC-secret
- OpenPGP Card V3.4 with RSA4096, Ed25519 and more 2
- PIV (NIST SP 800-73-4)
- HOTP / TOTP
- NDEF

There is an emulated QEMU device in the form of libcanokey-qemu which is 
the focus of this wishlist request. This feature will allow safe usage 
of ones keys in a virtual environment with the trust issues that 
accompany physical smartcard device implementations. Canokey also 
provides a more straightforward and generic approach to interacting with 
secure key material compared to swtpm-tools which support a subset of 
these ciphers and algos in a TPM only context.


Once packaged, this feature will bring what was exclusively a feature 
(Split GPG [3]) limited to users of security hypervisor distros like 
QubesOS to the masses.



[1] https://canokeys.org/
[2] https://www.qemu.org/docs/master/system/devices/canokey.html#id9
[3] https://www.qubes-os.org/doc/split-gpg/

Bug#1074054: gdk-pixbuf 2.42.2+dfsg-1+deb11u2 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1074054 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: gdk-pixbuf
Version: 2.42.2+dfsg-1+deb11u2

Explanation: ANI: Reject files with multiple anih chunks [CVE-2022-48622]; ANI: 
Reject files with multiple INAM or IART chunks; ANI: Validate anih chunk size

Bug#1074059: nodejs 18.19.0+dfsg-6~deb12u2 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1074059 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: nodejs
Version: 18.19.0+dfsg-6~deb12u2

Explanation: skip flaky tests for mipsel/mips64el

Bug#1074044: libvcflib: Improve support for loongarch64

[Andreas Tille]

Control: tags -1 pending

Am Sat, Jun 22, 2024 at 04:56:56PM +0800 schrieb zhangdandan:
> diff -Nru libvcflib-1.0.9+dfsg1/debian/control 
> libvcflib-1.0.9+dfsg1/debian/control
> --- libvcflib-1.0.9+dfsg1/debian/control  2023-12-03 12:29:41.0 
> +
> +++ libvcflib-1.0.9+dfsg1/debian/control  2023-12-03 12:29:41.0 
> +
> @@ -76,7 +76,7 @@
>   This package contains the static library and the header files.
>  
>  Package: libvcflib-tools
> -Architecture: any-amd64 arm64 mips64el ppc64el s390x ia64 ppc64 riscv64 
> sparc64 alpha
> +Architecture: any-amd64 arm64 loong64 mips64el ppc64el s390x ia64 ppc64 
> riscv64 sparc64 alpha

Current status in Git for the new upstream version says:

Build-Depends: ...
   architecture-is-64-bit,
   architecture-is-little-endian,

and

Architecture: any

which fixes this bug.  We just need some response from upstream to upload
the new release.

Kind regards and thanks for your patience
  Andreas.

-- 
https://fam-tille.de

Bug#1069891: bookworm-pu: package ansible/7.7.0+dfsg-3+deb12u1

[Salvatore Bonaccorso]

Hi Lee,

On Sat, Jun 15, 2024 at 11:06:23PM +0100, Jonathan Wiltshire wrote:
> Control: tag -1 moreinfo
> 
> On Fri, Apr 26, 2024 at 03:05:00PM +0200, Lee Garrett wrote:
> > I'm requesting to bump the version of the ansible package 
> > ("ansible-community
> > collection") to the last minor semantic version of the v7 series in 
> > bookworm.
> > This version has previously spent ~10 months in testing/unstable, so I'm 
> > fairly
> > confident that any potential regressions would have been caught (so far 
> > none).
> 
> If upstream uses semver then 7.3 -> 7.7 implies new features. Along with a
> 10MiB diff this is usually a good indicator that it's inappropriate for
> stable.
> 
> The trouble with a package's time spent in sid as an indicator of
> reliability isn't so much the package itself, but all the differences
> around it like library versions. We've been bitten by that assumption
> before now.
> 
> Are there known issues for users which you can target with fixes rather
> than a wholesale backport?
> 
> Otherwise maybe bookworm-backports is a better place for this, so users can
> choose to take slightly more risk for features, or stick with the released
> version and put up with known quantity bugs.

Did you saw Jonathan's comments above?

Regards,
Salvatore

Bug#1070739: bookworm-pu: package python-glance-store/4.1.0-4

[Salvatore Bonaccorso]

On Sat, Jun 15, 2024 at 07:29:56PM +0100, Adam D. Barratt wrote:
> Control: tags -1 -moreinfo +confirmed
> 
> On Sat, 2024-06-15 at 16:21 +0100, Adam D. Barratt wrote:
> > Control: tags -1 + moreinfo
> > 
> > On Wed, 2024-05-08 at 17:59 +0200, Salvatore Bonaccorso wrote:
> > > Hi,
> > > 
> > > On Wed, May 08, 2024 at 09:52:01AM +0200, Thomas Goirand wrote:
> > > 
> > [...]
> > > > I would like to update python-glance-store/4.1.0-4 to
> > > > python-glance-store/4.1.1-1+deb12u1 to address CVE-2024-1141
> > > > (aka: #1063795).
> > > 
> > > Should that be 4.1.1-0+deb12u1 instead? (I do know that 4.1.1-1 was
> > > never in the archive ,but that makes sure it sorts before 4.1.1-1).
> > 
> > Yes, indeed.
> > 
> > Both the Security Tracker and BTS suggest that this issue affects
> > unstable and is not yet fixed there. What's the status?
> 
> Apparently the metadata was outdated. Thanks for checking and updating
> it, Salvatore.
> 
> Please go ahead, using 4.1.1-0+deb12u1 as the version number.

Thomas, did you saw this ack from Adam?

Regards,
Salvatore

Bug#1070193: bookworm-pu: package ansible-core/2.14.16-0+deb12u1

[Salvatore Bonaccorso]

Hi lee,

On Sat, Jun 15, 2024 at 11:25:26PM +0100, Jonathan Wiltshire wrote:
> Control: tag -1 confirmed
> 
> On Wed, May 01, 2024 at 05:05:05PM +0200, Lee Garrett wrote:
> > [ Reason ]
> > This is a bugfix-only update from ansible-core 2.14.3 to 2.14.16. This fixes
> > three CVEs:
> > - Address issue where ANSIBLE_NO_LOG was ignored (CVE-2024-0690)
> > - Address issues where internal templating can cause unsafe variables to
> >   lose their unsafe designation (CVE-2023-5764)
> > - Prevent roles from using symlinks to overwrite files outside of the
> >   installation directory (CVE-2023-5115)
> > 
> > and various other bugfixes as seen here:
> > https://salsa.debian.org/python-team/packages/ansible-core/-/blob/debian/bookworm-proposed/changelogs/CHANGELOG-v2.14.rst
> 
>  1051 files changed, 8802 insertions(+), 159082 deletions(-)
> 
> Normally I'd been looking for targetted fixes for the security issues but
> upstream's descriptive changelog does look quite sensible.
> 
> You might want to change your version number - if 2.14.16-1 was never in
> sid you could use that. A +/~ revision to a version which never existed
> feels odd, as do -0 Debian versions (-1 being the first Debian release of
> this upstream version, -0 is... the zeroth?).

did you saw the ack from Jonathan?

Regards,
Salvatore

Bug#1068888: bookworm-pu: package zookeeper/3.8.0-11+deb12u2

[Salvatore Bonaccorso]

Hi Bastien,

On Sun, Jun 16, 2024 at 12:50:59PM +0100, Adam D. Barratt wrote:
> On Sun, 2024-06-16 at 11:12 +, Bastien Roucariès wrote:
> > control: tag -1 - moreinfo
> > Le samedi 15 juin 2024, 22:49:24 UTC Jonathan Wiltshire a écrit :
> > > > 
> [...]
> > > > zookeeper-3.8.0/debian/patches/0027-CVE-2024-23944-ZOOKEEPER-
> > > > 4799-Refactor-ACL-check-in-.patch  1970-01-01
> > > > 00:00:00.0 +
> > > > +++ zookeeper-3.8.0/debian/patches/0027-CVE-2024-23944-ZOOKEEPER-
> > > > 4799-Refactor-ACL-check-in-.patch  2024-03-25
> > > > 08:30:56.0 +
> > > > @@ -0,0 +1,1223 @@
> > > 
> > > 
> > > This patch confuses me. It seems to contain a whole series of
> > > nested
> > > patches? How do they get applied to the source package?
> > 
> > ??? 
> > 
> > I do not understand, see patch 0027 joined it is a simple patch...
> 
> Is the source of the confusion here potentially that the patch adds new
> files, as well as changing existing ones?

Any comments here? (I guess likely it will be now to late for 12.6,
but maybe we can make it for 12.7?)

Regards,
Salvatore

Bug#1066965: bookworm-pu: package newlib/3.3.0-2

[Salvatore Bonaccorso]

Hi Petter,

On Sat, May 25, 2024 at 09:44:06PM +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sat, 2024-03-16 at 09:09 +0100, Petter Reinholdtsen wrote:
> > +newlib (3.3.0-2) bookworm; urgency=medium
> > 
> 
> As Salvatore already noted, that's not a conventional version number
> for a stable upload, but can be used iff no such version has ever been
> used for a package uploaded to Debian (or included as a changelog
> stanza in d/changelog for any package uploaded to Debian) in the past.
> 
> > +
> > +  * QA upload.
> > +  * Orphan package to reflect status in Unstable.
> 
> Although this is harmless, note that it's also mostly redundant, as
> nothing actually looks at / acts on the maintainer fields of packages
> in stable (or older).
> 
> Please go ahead.

Did you saw Adam's confirmation on this (with the comments about the
version)?

Regards,
Salvatore

Bug#1073176: gramps: Error with loss of data: TypeError: '<' not supported between instances of 'str' and 'NoneType'

[Dr. Tobias Quathamer]

control: tag -1 unreproducible
control: severity -1 normal

On Fri, 14 Jun 2024 19:39:23 +1200 Mark Robinson 
 wrote:
On completing the database migration I created a new person, added birth 
and death information including a new death location and notes, and 
clicked OK.


This resulted in the python error referred to in the headline which left 
the new person with the OK button greyed out and no way to save it. The 
record was lost.


Hi Mark,

sorry about that. I've tried to reproduce this bug, using the steps 
you've described above. It worked without any problem on my system, so 
I'm not able to reproduce the faulty behaviour of gramps.


I'm therefore lowering the severity, because otherwise gramps would be 
removed from testing. I currently don't think that this would be necessary.


However, there should be an automatic backup of your database, as 
printed in the status messages:


11723: WARNING: upgrade.py: line 2218: If upgrade and loading the Family 
Tree works, you can delete the zip file at 
/home/mark/.gramps/ROBINSON__Mark_Gregory_2024-06-14_12-07-04.zip


Could you try to extract that database version of your family tree and 
open it with gramps? The program should then ask you again to convert 
the tree to the new database format. Afterwards, could you repeat the 
steps above, i. e. creating a new person, adding birth and death 
information etc.? Then please report back if the error still occurs.


Regards,
Tobias


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055211: bookworm-pu: package gcc-12/12.2.0-14+deb12u1 (CVE-2023-4039)

[Salvatore Bonaccorso]

Hi,

On Thu, Nov 02, 2023 at 11:11:56AM +0100, Emanuele Rocca wrote:
> Package: release.debian.org
> Severity: normal
> Tags: bookworm
> User: release.debian@packages.debian.org
> Usertags: pu
> X-Debbugs-Cc: debian-...@lists.debian.org, j...@debian.org, d...@debian.org
> Control: affects -1 + src:gcc-12
> 
> [ Reason ]
> A failure in the -fstack-protector feature in GCC-based toolchains that target
> AArch64 allows an attacker to exploit an existing buffer overflow in
> dynamically-sized local variables without this being detected.
> 
> The Security Team explicitly stated that they will not release a DSA for the
> bug, see https://security-tracker.debian.org/tracker/CVE-2023-4039 
> 
> This issue has been fixed in version 12.3.0-9 for sid and trixie. It would now
> be good to address the problem in bookworm too.
> 
> [ Impact ]
> Without this change, arm64 users of gcc-12 in bookworm are not fully protected
> by -fstack-protector as described in CVE-2023-4039.
> 
> [ Tests ]
> In terms of manual testing, I have verified that the stack smashing attack
> published at
> https://github.com/metaredteam/external-disclosures/security/advisories/GHSA-x7ch-h5rf-w2mf
> is detected and stopped when the PoC is compiled with gcc 12.2.0-14+deb12u1,
> while it results in a Bus error with 12.2.0-14:
> 
>   $ gcc-12 --version | head -1
>   gcc-12 (Debian 12.2.0-14+deb12u1) 12.2.0
>   $ gcc-12 -fstack-protector-all -O3 -static -Wall -Wextra -pedantic -o poc 
> poc.c
>   $ echo -n '' | ./poc 8
>   *** stack smashing detected ***: terminated
>   Aborted
> 
>   $ gcc-12 --version | head -1
>   gcc-12 (Debian 12.2.0-14) 12.2.0
>   $ gcc-12 -fstack-protector-all -O3 -static -Wall -Wextra -pedantic -o poc 
> poc.c
>   $ echo -n '' | ./poc 8
>   Bus error
> 
> As an additional smoke test I have also successfully built a few packages, as
> well as a kernel.
> 
> In terms of automated testing, the upstream test suite is extensive.
> Additionally, upstream added the following tests specifically for
> CVE-2023-4039:
> 
>  testsuite/gcc.target/aarch64/stack-check-prologue-17.c
>  testsuite/gcc.target/aarch64/stack-check-prologue-18.c
>  testsuite/gcc.target/aarch64/stack-check-prologue-19.c
>  testsuite/gcc.target/aarch64/stack-check-prologue-20.c
>  testsuite/gcc.target/aarch64/stack-protector-8.c
>  testsuite/gcc.target/aarch64/stack-protector-9.c
> 
> [ Risks ]
> There are obviously potential risks of regressions associated with compiler
> changes. However the specific changes proposed here have been part of gcc-12
> upstream since September, and by now have been tested quite a bit. One
> regression has been found early on and fixed:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111411
> 
> All changes are arm64-specific and don't affect any other architecture.
> 
> [ 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 ]
> All changes merged upstream back in September 2023, see
> https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/releases/gcc-12
> 
> - aarch64: Avoid a use of callee_offset
>   12a8889de169f892d2e927584c00d20b8b7e456f
> 
> - aarch64: Explicitly handle frames with no saved registers
>   03d5e89e7f3be53fd7142556e8e0a2774c653dca
> 
> - aarch64: Add bytes_below_saved_regs to frame info
>   49c2eb7616756c323b7f6b18d8616ec945eb1263
> 
> - aarch64: Add bytes_below_hard_fp to frame info
>   34081079ea4de0c98331843f574b5f6f94d7b234
> 
> - aarch64: Tweak aarch64_save/restore_callee_saves
>   187861af7c51db9eddc6f954b589c121b210fc74
> 
> - aarch64: Only calculate chain_offset if there is a chain
>   2b983f9064d808daf909bde1d4a13980934a7e6e
> 
> - aarch64: Rename locals_offset to bytes_above_locals
>   0a0a824808d1dec51004fb5805c1a0ae2a35433f
> 
> - aarch64: Rename hard_fp_offset to bytes_above_hard_fp
>   3fbf0789202b30a67b12e1fb785c7130f098d665
> 
> - aarch64: Tweak frame_size comment
>   aac8b31379ac3bbd14fc6427dce23f56e54e8485
> 
> - aarch64: Measure reg_offset from the bottom of the frame
>   8d5506a8aeb8dd7e8b209a3663b07688478f76b9
> 
> - aarch64: Simplify top of frame allocation
>   b47766614df3b9df878262efb2ad73aaac108363
> 
> - aarch64: Minor initial adjustment tweak
>   08f71b4bb28fb74d20e8d2927a557e8119ce9f4d
> 
> - aarch64: Tweak stack clash boundary condition
>   f22315d5c19e8310e4dc880fd509678fd291fca8
> 
> - aarch64: Put LR save probe in first 16 bytes
>   15e18831bf98fd25af098b970ebf0c9a6200a34b
> 
> - aarch64: Simplify probe of final frame allocation
>   c4f0e121faa36342f1d21919e54a05ad841c4f86
> 
> - aarch64: Explicitly record probe registers in frame info
>   6f0ab0a9f46a17b68349ff6035aa776bf65f0575
> 
> - aarch64: Remove below_hard_fp_saved_regs_size
>   8254e1b9cd500e0c278465a3657543477e9d1250
> 
> - aarch64: Make stack smash canary protect save

Bug#1054915: bookworm-pu: package freerdp2/2.11.2+dfsg1-1~deb12u1

[Salvatore Bonaccorso]

Hi Tobi,

On Wed, Feb 21, 2024 at 08:00:42AM +, Jonathan Wiltshire wrote:
> Control: tag -1 moreinfo
> 
> Hi,
> 
> On Sat, Oct 28, 2023 at 05:58:38PM +0200, Tobias Frost wrote:
> > Backporting the fixes is of course possible, but bears a significant
> > risk for regression, therefor I would prefer to use the new upstream
> > version, given also that upstream changes are only a few and fixing
> > also a few bugs that would be nice to be fixed.
> 
> It's a balancing act, as always. I'm OK with new upstream releases if they
> are small enough to sensibly review (or an upstream with a good trusted
> history, which I don't yet have for freerdp2). If you think a new upstream
> is reasonable, let's see how it looks.
> 
> Either way we need a source debdiff please.

Did you saw the followup question from Jonathan?

Regards,
Salvatore

Bug#1053832: bookworm-pu: package ceph/16.2.11+ds-2 (CVE-2023-43040)

[Salvatore Bonaccorso]

On Sat, Apr 06, 2024 at 10:36:50PM +0100, Jonathan Wiltshire wrote:
> Control: tag -1 confirmed
> 
> On Thu, Oct 12, 2023 at 11:34:58AM +0200, Thomas Goirand wrote:
> > [ Reason ]
> > CVE-2023-43040
> > 
> > [ Impact ]
> > security issue with RGW with improperly verified POST keys.
> 
> Sorry for the delay; please go ahead.

Thomas, friendly ping? 

Regards,
Salvatore

Bug#1072704: RFS: anytree/2.12.1-1 [ITP] -- Powerful and Lightweight Python Tree Data

[Bastian Germann]

Control: block 1072301 by -1

Bug#1072301: ITP: python3-anytree -- Powerful and Lightweight Python Tree Data Structure with various plugins

[Bastian Germann]

Control: retitle -1 ITP: anytree -- Powerful and Lightweight Python Tree Data 
Structure with various plugins

Bug#1072802: Subject: RFS: lsix/1.8.2-1 [ITP] -- Show thumbnails in terminal using sixel graphics

[Bastian Germann]

Control: retitle -1 RFS: lsix/1.8.2-1 [ITP] -- Show thumbnails in terminal 
using sixel graphics
Control: block 1072801 by -1

Bug#1074068: Package descriptions contain reference to nonexistent bibliography sources

[Beatrice Torracca]

Source: hdf-eos4
Severity: minor

Hi!

the description of packages 'libhdfeos-dev' and 'libhdfeos0t64'
contains a reference ("[1,4]") to some nonexistent bibliography.

Thanks for your work,

beatrice

Bug#433568: (no subject)

[Steven Maddox]

It's not impossible already to do VLANs with d-i currently (for anyone 
reading this after a temporary work around until this is properly fixed)...


Step 1) Get to the screen where d-i presents you with a list of network 
interfaces


Step 2) Go to VT2 (using alt-F2) and activate the console

Step 3) Add a VLAN interface to whichever physical interface you want it 
on... ip link add link eno1 name eno1.42 type vlan id 42


Step 4) Go back to VT1 (using alt+F1) and choose to go 'Back' and then 
forward by selecting 'Configure the network' to repopulate the list


Step 5) Pick the new VLAN interface until you're at the screen where 
you'd normally pick 'Configure network manually...' (but don't pick this 
option yet)


Step 6) Go BACK to VT2 (using alt-F2)

Step 7) Bring the physical and VLAN interfaces up... ip link set eno1 
up; ip link set eno1.42 up


Step 8) Go BACK to VT1 (using alt+F1) and continue as normal

EASY!.. OK... FINE... I admit that is sarcasm.  It's also laughable that 
it's easier to get d-i to use PPPoE than it is a VLAN.


Now you might think to do the commands on VT2 all at once, but I find 
once you've picked the network interface with d-i it'll bring the 
interface down!


Also these instructions are useless if you're not configuring a static 
IP as you'll have to be super quick before the autoconfiguration fails.


Lastly... (this is the main reason I'm adding to this bug report)...

Does the new patch discussed here address the fact that usually I find I 
have to run this (AFTER the system has booted up for the first time)...


sed -i 's/allow-hotplug/auto/' /etc/network/interfaces

... and then reboot again before any networking works?

Because 'allow-hotplug' just doesn't cut it with VLAN interfaces... it 
seems it must be 'auto'


Frankly I don't see why we don't use 'auto' in the default 
/etc/network/interfaces (whether using a VLAN or not) as it covers 
everything 'allow-hotplug' does but actually works in more cases.


Thoughts?

Bug#1061834: radio-beam fails its autopkg tests with Python 3.12

[Jeremy Bícha]

Control: tags -1 +patch

See https://github.com/radio-astro-tools/radio-beam/commit/ead94af4e48

Thank you,
Jeremy Bícha

Bug#1074067: librust-async-global-executor-dev: please accept rust-async-lock v3 as dependency

[Jonas Smedegaard]

Package: librust-async-global-executor-dev
Version: 2.4.1-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

librust-async-global-executor-dev declares a dependency on
rust-async-lock v2, despite upstream declared crate dependency on
rust-async-lock v3.

This blocks (so far only experimental) migration to newer branches of
async-* and smol crates.

Please accept rust-async-lock v3 as dependency.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmZ3DHEACgkQLHwxRsGg
ASGMNBAAg46jPUPNBlWf0vt5u0keZx86BOHxkEMmzM/OlZ3h/tzbLKcAYFnV2Ivu
9+3pfkwWm9ALmxSN1SiYrRVX+wsS4QNtXmjvr7QtdqapL3AVso67vTKvKUzYk18T
a18CC/QbjC8zOaoUeqiMwIeT29TCHG60CKlxqT3o9oTQ1JsF7Wt1IYGiVPnulKjV
RoY8akOBIWkK3+IfZGUGAvlfqqdEtesKUUzl8vtmusLEJ30lN1/8z/Pev+dmzxcv
sab+JcqSS4mZdKn7SJZBuJlRU5rHEwbvFfOOrGex+yuP3Txw4WYDcJHm/ESzHcFU
FrzRHhZiJDWGYClLoIAPBU8RmAZfJZwcELTYkrHXaEfjVd79B6Pe02puboHzLNIe
XocK4hIFdguORU4PexQMD+Ko2So/VG2OTPISqve3y9p059KvacvyIM9GBGNif+27
iGxyf3iW94+zGqssIBsnJmRY7MOwzYPxoqhzd9QdRgQ2b50jcylTKxy7s7STaWEq
7wVL/J7kXm5HJ0KTAB0geqG6vCZB2OuYObcPwVAyi2myWsnWRsX8TQgaoEGVkrW9
o9WrHCaYm070khwECxBS+/23S+MB2KTtR1sygD19GtS/iyn4spM5WDJv99coJOF2
N2vWKvd6W0owQNQa0avxGZJLd4z9ZWYOSBS8ps5HjlqiQtpTI+E=
=OeTA
-END PGP SIGNATURE-

Bug#1074014: encode mandatory merged-/usr into policy

[Russ Allbery]

Helmut Grohne  writes:

> Portability is one angle and certainly an important one. Spending
> collective project resources is another one. I argue that changing these
> paths beyond what is technically necessary is not a good use of our
> time. So how about having policy recommend not changing path references
> compared to upstream? I don't think this should be a policy requirement
> as there may be good reasons to deviate and we can rationalize this
> recommendation with the portability and the effort arguments.

Oh, that's an interesting idea.  How about something like:

Since paths either with or without /usr are supported on Debian
systems, maintainers of non-native packages are encouraged to follow
the same conventions as the upstream package when referencing absolute
paths.  There is no need to change upstream code from, for example,
/bin to /usr/bin (or from /usr/bin to /bin) when packaging for Debian.

There is a drawback, though: because dpkg only knows about the usr/bin
(etc.) paths, at least as I understand the current state of things, one
cannot find non-/usr paths with dpkg -S.  Changing all the paths to
include usr/ therefore does solve a usability issue in some cases, so this
trade off is not entirely obvious.

I have lost track of the work on this.  Are there any prospects for dpkg
to know, on Debian systems, that bin/sh and usr/bin/sh are the same thing?

> I have another question. Thorsten Glaser was unhappy about my mksh
> report as he believes that it should be /bin/mksh and not /usr/bin/mksh.
> I argued that the biggest concern is the symlink vs directory conflict
> and he came up with a crazy solution where mksh's data.tar contains
> ./bin/mksh but not ./bin on the grounds that ./bin is provided by an
> essential package in all Debian releases. I think this approach
> practically solves a significant chunk of the problems listed by DEP17,
> but it still confuses QA tools and e.g. dpkg -S (maybe more). My
> proposal here would make mksh's approach violate policy. Should policy
> allow Thorsten's approach? It certainly is something that needs to be
> forbidden for any transitively essential package or bootstrapping tools
> fail.

My inclination is to say no, we shouldn't allow it in Policy.  The release
team can decide whether they care in the case of mksh, and I personally
have a hard time getting that upset about Thorsten carrying that policy
violation in his package when it matters a lot to him and he accepts the
resulting breakage.  But I'm fine with calling it a policy violation: it
breaks other tools, making it work is a level of complexity that we don't
need, and it doesn't, so far as I know, have a strong technical
justification.

-- 
Russ Allbery (r...@debian.org)  

Bug#1073809: RFS: streamlink/6.8.1-1 -- CLI for extracting video streams from various websites to a video player

[Leandro Cunha]

On Sat, Jun 22, 2024 at 2:15 PM Alexis Murzeau  wrote:
>
> Hi,
>
> On 20/06/2024 23:29, Phil Wyett wrote:
> > Control: tags -1 + moreinfo
> >
> > Hi Alexis,
> >
> > Thanks for taking time to create this package and your contribution to 
> > Debian.
> >
> > I see you have submitted this Request For Sponsorship (RFS) but not toggled
> > 'Needs a sponsor' on the mentors site. I will offer a review that may 
> > assist you
> > in your good work for the Debian project.
> >
> > Review...
> >
> > 1. Build: OK
> >
> > 2. Lintian: INFORMATION
> >
> > I: streamlink source: built-using-field-on-arch-all-package (in section for
> > python3-streamlink-doc) Built-Using ${sphinxdoc:Built-Using} 
> > [debian/control:72]
> > N:
> > N:   The stanza for an installation package in debian/control declares a
> > N:   Built-Using field even though the package is declared as Architecture:
> > N:   all. That is incorrect.
> > N:
> > N:   The Built-Using field is only used architecture-specific packages. 
> > Please
> > N:   remove the Built-Using field from the indicated location.
> > N:
> > N:   Visibility: info
> > N:   Show-Always: no
> > N:   Check: debian/control/field/built-using
> > N:
> >
> > Please could this be looked at for a future release/upload.
> >
> > 3. Licenses check: ISSUES
> >
> > philwyett@ks-windu:~/Development/builder/debian/mentoring/streamlink-6.8.1$ 
> > lrc
> > en: Versions: recon 1.10.1  check 3.3.9-1
> >
> > Parsing Source Tree  
> > Reading copyright
> > Running licensecheck 
> >
> > d/copyright | licensecheck
> >
> > Apache-2| Apache-2.0   src/streamlink/packages/requests_file.py
> >
> > Minor and an easy fix.
> >
> > 4. Build Twice (sudo pbuilder build --twice .dsc): OK
> >
> > 5. Install (No previous installs): OK
> >
> > 6. Upgrade (Over previous installs if any): OK
> >
> > Additional...
> >
> > A. 'debian/control'
> >
> > Please update to the latest 'Standards-Version' which is 4.7.0.
> >
> > https://www.debian.org/doc/debian-policy/
> >
> > Summary...
> >
> > Please consider addressing the issues raised where applicable and remove the
> > 'moreinfo' tag when doing next/fixed upload.
> >
> > Regards
> >
> > Phil
> >
>
> Thanks for your review.
>
> As this version is already uploaded, I've done the fixes for the next
> upstream version:
> - Fix the lintian issue about Built-Using (I kept it before as it was not
>clear to me whether sphinx-generated docs should use it or not).
> - Fix license short name: Apache-2 => Apache-2.0.
> - Bump standard version to 4.7.0 (no change required).
>

He chose to use the SPDX nomenclature. Very good!
https://spdx.org/licenses/Apache-2.0.html

For future inquiries
https://dep-team.pages.debian.net/deps/dep5/
https://ftp-master.debian.org/licenses/
https://wiki.debian.org/DFSGLicenses

I use these links to study this.

-- 
Cheers,
Leandro Cunha

Bug#1073809: RFS: streamlink/6.8.1-1 -- CLI for extracting video streams from various websites to a video player

[Phil Wyett]

On Sat, 2024-06-22 at 19:10 +0200, Alexis Murzeau wrote:
> Hi,
> 
> On 20/06/2024 23:29, Phil Wyett wrote:
> > Control: tags -1 + moreinfo
> > 
> > Hi Alexis,
> > 
> > Thanks for taking time to create this package and your contribution to 
> > Debian.
> > 
> > I see you have submitted this Request For Sponsorship (RFS) but not toggled
> > 'Needs a sponsor' on the mentors site. I will offer a review that may 
> > assist you
> > in your good work for the Debian project.
> > 
> > Review...
> > 
> > 1. Build: OK
> > 
> > 2. Lintian: INFORMATION
> > 
> > I: streamlink source: built-using-field-on-arch-all-package (in section for
> > python3-streamlink-doc) Built-Using ${sphinxdoc:Built-Using} 
> > [debian/control:72]
> > N:
> > N:   The stanza for an installation package in debian/control declares a
> > N:   Built-Using field even though the package is declared as Architecture:
> > N:   all. That is incorrect.
> > N:
> > N:   The Built-Using field is only used architecture-specific packages. 
> > Please
> > N:   remove the Built-Using field from the indicated location.
> > N:
> > N:   Visibility: info
> > N:   Show-Always: no
> > N:   Check: debian/control/field/built-using
> > N:
> > 
> > Please could this be looked at for a future release/upload.
> > 
> > 3. Licenses check: ISSUES
> > 
> > philwyett@ks-windu:~/Development/builder/debian/mentoring/streamlink-6.8.1$ 
> > lrc
> > en: Versions: recon 1.10.1  check 3.3.9-1
> > 
> > Parsing Source Tree  
> > Reading copyright
> > Running licensecheck 
> > 
> > d/copyright | licensecheck
> > 
> > Apache-2| Apache-2.0   src/streamlink/packages/requests_file.py
> > 
> > Minor and an easy fix.
> > 
> > 4. Build Twice (sudo pbuilder build --twice .dsc): OK
> > 
> > 5. Install (No previous installs): OK
> > 
> > 6. Upgrade (Over previous installs if any): OK
> > 
> > Additional...
> > 
> > A. 'debian/control'
> > 
> > Please update to the latest 'Standards-Version' which is 4.7.0.
> > 
> > https://www.debian.org/doc/debian-policy/
> > 
> > Summary...
> > 
> > Please consider addressing the issues raised where applicable and remove the
> > 'moreinfo' tag when doing next/fixed upload.
> > 
> > Regards
> > 
> > Phil
> > 
> 
> Thanks for your review.
> 
> As this version is already uploaded, I've done the fixes for the next
> upstream version:
> - Fix the lintian issue about Built-Using (I kept it before as it was not
>clear to me whether sphinx-generated docs should use it or not).
> - Fix license short name: Apache-2 => Apache-2.0.
> - Bump standard version to 4.7.0 (no change required).
> 
> See also: https://salsa.debian.org/amurzeau/streamlink/
> 

Hi Alexis,

Your promptness, attention to detail and passion for good package maintenance
does you credit.

Many thanks for the update.

Regards

Phil

-- 

Internet Relay Chat (IRC): kathenas

Website: https://kathenas.org

Instagram: https://instagram.com/kathenasorg/

Buy Me A Coffee: https://buymeacoffee.com/kathenasorg


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

Bug#1073885: FTBFS with OCaml 5.2.0 (Missing dependency on camlp-streams)

[Andreas Tille]

Hi Stephane,

Am Thu, Jun 20, 2024 at 06:35:50AM + schrieb Stephane Glondu:
> Source: mcl14
> Version: 14-137+ocaml-2
> Severity: important
> Tags: ftbfs
> User: debian-ocaml-ma...@lists.debian.org
> Usertags: ocaml-5.2.0-transition
> 
> Your package FTBFS with OCaml 5.2.0 for the following reason:
> 
>   Missing dependency on camlp-streams

I'm absolutely uneducated about ocaml.  Could you confirm that simply
adding

libcamlp-streams-ocaml-dev

to Build-Depends might fix this issue?
 
Kind regards
Andreas.

-- 
https://fam-tille.de

Bug#1073809: RFS: streamlink/6.8.1-1 -- CLI for extracting video streams from various websites to a video player

[Alexis Murzeau]

Hi,

On 20/06/2024 23:29, Phil Wyett wrote:

Control: tags -1 + moreinfo

Hi Alexis,

Thanks for taking time to create this package and your contribution to Debian.

I see you have submitted this Request For Sponsorship (RFS) but not toggled
'Needs a sponsor' on the mentors site. I will offer a review that may assist you
in your good work for the Debian project.

Review...

1. Build: OK

2. Lintian: INFORMATION

I: streamlink source: built-using-field-on-arch-all-package (in section for
python3-streamlink-doc) Built-Using ${sphinxdoc:Built-Using} [debian/control:72]
N:
N:   The stanza for an installation package in debian/control declares a
N:   Built-Using field even though the package is declared as Architecture:
N:   all. That is incorrect.
N:
N:   The Built-Using field is only used architecture-specific packages. Please
N:   remove the Built-Using field from the indicated location.
N:
N:   Visibility: info
N:   Show-Always: no
N:   Check: debian/control/field/built-using
N:

Please could this be looked at for a future release/upload.

3. Licenses check: ISSUES

philwyett@ks-windu:~/Development/builder/debian/mentoring/streamlink-6.8.1$ lrc
en: Versions: recon 1.10.1  check 3.3.9-1

Parsing Source Tree  
Reading copyright
Running licensecheck 

d/copyright | licensecheck

Apache-2| Apache-2.0   src/streamlink/packages/requests_file.py

Minor and an easy fix.

4. Build Twice (sudo pbuilder build --twice .dsc): OK

5. Install (No previous installs): OK

6. Upgrade (Over previous installs if any): OK

Additional...

A. 'debian/control'

Please update to the latest 'Standards-Version' which is 4.7.0.

https://www.debian.org/doc/debian-policy/

Summary...

Please consider addressing the issues raised where applicable and remove the
'moreinfo' tag when doing next/fixed upload.

Regards

Phil



Thanks for your review.

As this version is already uploaded, I've done the fixes for the next
upstream version:
- Fix the lintian issue about Built-Using (I kept it before as it was not
  clear to me whether sphinx-generated docs should use it or not).
- Fix license short name: Apache-2 => Apache-2.0.
- Bump standard version to 4.7.0 (no change required).

See also: https://salsa.debian.org/amurzeau/streamlink/

--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F |

Bug#1074066: sensible-utils: sensible-pager does not work with PAGER=sensible-pager

[Oswald Buddenhagen]

Package: sensible-utils
Version: 0.0.23
Severity: important

the recursion checks in sensible-utils return zero instead of 126 or
127, so the command simply fails instead of trying the next option.

also, arguably, $PAGER, etc. should be simply ignored if they match the
script under execution, to save the pointless recursive call.

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

Kernel: Linux 6.9-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, 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

-- no debconf information

Bug#1074061: Acknowledgement (/usr/sbin/gdm3: gdm3+nouveau/nvidia 535 blank login screen with DisplayLink, worked with nvidia 525)

[Jonathan Kamens]

One additional data point: if, when I'm confronted with these two blank 
screens when I should be seeing a login screen, I hit Enter, type my 
password, and hit Enter again, I'm logged in, so it appears that gdm 
_thinks_ it's displaying a login screen but it's not actually visible in 
the real world.

Bug#1073207: RFS: cevomapgen/34-1 -- External Map Generator for C-Evo

[Phil Wyett]

On Sat, 2024-06-22 at 17:16 +0100, Peter B wrote:
> On 22/06/2024 16:27, Phil Wyett wrote:
> 
> 
> ...
> > 2. Lintian: Warning
> > 
> > W: c-evo-map-gen: unknown-field Static-Built-Using
> > N:
> > N:   See the Policy Manual for a list of the possible fields in a package
> > N:   control files.
> ...
> 
> 
> Hi Phil,
> 
> Thanks for the review.
> 
> 
> I believe I'm using the field correctly, and dpkg accepts it,
> but Policy and Lintian have not been updated yet.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069256
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997948
>(See my comment, its the last one)
> 
> 
> Note, if the field was genuinely unknown, dpkg itself would be warning 
> (its not).
> 
> 
> Regards,
> Peter
> 

Hi Peter,

Thank you for the information. A DD will assess this information along with the
review when coming to a decision to sponsor your package submission. If they are
happy sponsorship will likely proceed.

Regards

Phil

-- 

Internet Relay Chat (IRC): kathenas

Website: https://kathenas.org

Instagram: https://instagram.com/kathenasorg/

Buy Me A Coffee: https://buymeacoffee.com/kathenasorg


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

Bug#983357: Xen vkb uevent/modalias fix (Debian installer bug)

[Jason Andryuk]

Hi,

A commit to address the Xen virtual keyboard large uevent/modalias
failure has been merged into upstream linux for the upcoming 6.10
release:
https://git.kernel.org/torvalds/c/0774d19038c496f0c3602fb505c43e1b2d8eed85

This should address https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983357
and https://github.com/systemd/systemd/issues/22944

It has already been backported to these stable releases:
6.9.3
6.8.12
6.6.33
6.1.95

It is queued for these future releases (assuming number holds):
5.15.162
5.10.221
5.4.279
4.19.317

Regards,
Jason

Bug#1074065: dh-make-golang: Chokes on go version string 1.22.2

[Martin Dosch]

Package: dh-make-golang
Version: 0.6.0-2+b5
Severity: normal

Dear Maintainer,

I wanted to check if all dependencies for 
https://github.com/takacs/donkey/ are present in debian but 
dh-make-golang fails:

```
dh-make-golang check-d
epends   
2024/06/22 18:31:21 error while parsing go.mod: go.mod:3: invalid go version 
'1.22.2': must match format 1.23
```

IIRC this is already fixed in the latest version. If that's the case a 
backport would be highly appreciated.

Best regards,
Martin

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

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

Versions of packages dh-make-golang depends on:
ii  git   1:2.39.2-1.1
ii  git-buildpackage  0.9.30
ii  golang-any2:1.21~2~bpo12+1
ii  libc6 2.36-9+deb12u7
ii  pristine-tar  1.50

Versions of packages dh-make-golang recommends:
ii  exim4-daemon-light [mail-transport-agent]  4.96-15+deb12u4
ii  golang-golang-x-tools  1:0.5.0+ds-1

dh-make-golang suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1074064: src:git: fails to migrate to testing for too long: triggers autopkgtest issues

[Paul Gevers]

Source: git
Version: 1:2.43.0-1
Severity: serious
Control: close -1 1:2.45.2-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:git has been trying to migrate for 32 days 
[2]. Hence, I am filing this bug. The version in unstable causes issues 
for at least two reverse (test) dependencies.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=git



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1073197: RM: spip/4.1.9+dfsg-1+deb12u4

[Adam D. Barratt]

On Thu, 2024-06-20 at 06:04 +0200, David Prévot wrote:
> On 19/06/2024 21:43, Adam D. Barratt wrote:
> > On Fri, 2024-06-14 at 13:24 +0200, David Prévot wrote:
> > > Unless you agree with bumping the spip version in stable, I’d
> > > like to
> > > see the package removed during an upcoming point release.
> > 
> > Out of curiosity, what does that look like?
> 
> It’s a 6 MB source debbdiff (6.5 MB with the vendor dir) between
> stable and testing, attached compressed.
> 
>   2633 files changed, 82783 insertions(+), 32831 deletions(-)
> 
> It also depends on php-algo26-idna-convert, that itself depends on 
> php-jakeasmith-http-build-url, two small (274 kB and 20 kB, just one 
> useful file for the second) PHP libraries that are not in stable
> (both provided in /vendor upstream, but packaged separately for
> Debian).

Thanks. Given the above and looking at popcon (which I realise is not a
completely reliable method), I agree that removal probably makes most
sense.

Regards,

Adam

Bug#1074063: src:bambam: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: bambam
Version: 1.2.1+dfsg-1
Severity: serious
Control: close -1 1.3.0+dfsg-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:bambam has been trying to migrate for 32 
days [2]. Hence, I am filing this bug. The version in unstable fails its 
own autopkgtest.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=bambam



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1074062: src:node-nock: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: node-nock
Version: 13.3.3-1
Severity: serious
Control: close -1 13.5.4-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:node-nock has been trying to migrate for 
31 days [2]. Hence, I am filing this bug. The version in unstable fails 
its own autopkgtest.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=node-nock



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1073207: RFS: cevomapgen/34-1 -- External Map Generator for C-Evo

[Peter B]

On 22/06/2024 16:27, Phil Wyett wrote:


...

2. Lintian: Warning

W: c-evo-map-gen: unknown-field Static-Built-Using
N:
N:   See the Policy Manual for a list of the possible fields in a package
N:   control files.

...


Hi Phil,

Thanks for the review.


I believe I'm using the field correctly, and dpkg accepts it,
but Policy and Lintian have not been updated yet.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069256

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997948
  (See my comment, its the last one)


Note, if the field was genuinely unknown, dpkg itself would be warning 
(its not).



Regards,
Peter

Bug#1057832: golang-google-genproto-dev: New upstream version (0.0~git20231127.3a041ad) available

[Reinhard Tartler]

Control: tag -1 +help

Maytham Alsudany  writes:

> This package is severely outdated, and a new version is needed for
> github.com/google/trillian (indirect dependency of miniflux).

I took a look at updating this package, because I suspect it will be
needed for newer versions of golang-google-grpc. Turns out to be not
strictly the case at this point, but leaving this package outdated is
not a good idea.

I found that upstream uses the repository as for a couple of purposes:

a) convenience repostiory for "pre-generated" .pb.go files in the
folders googleapis and firestore, cf. [1,2]

b) Place compatibility forwarders to the package
   google.golang.org/protobuf [3]

For a), that seems icky to me. The .proto definitions for those
googleapis can be found in
https://github.com/googleapis/googleapis/tree/master/google/firestore/bundle. I
don't think we currently package those files in Debian. Oh well.

For b), I understand from [issue1015] that google is in the process of
removing those forwarders. The best course of action here seems to me to
avoid this repo in favor of using the actual definitions.

In order to maintain backwards compatibiliy, this googleapis/go-genproto
has now change [pr#901] that effectively adds dependencies "on virtually
all every submodule in cloud.google.com/go." This is extremely
inconvenient for us to package.

I looked at trillian, and it seems they do rely on these compatibility
shims. I wonder how much work would be involved to update the trillian
code to avoid these go-genproto forwarders and use the above mentioned
code in submodules (which can be found in the probably terribly outdated
golang-google-api package [googleapi], cf #1059087).

At this point, focusing on #1059087 might be the best thing to focus on
for now.

Thoughts or opinions?

-rt


[1]
https://sources.debian.org/src/golang-google-genproto/0.0~git20210726.e7812ac-2/googleapis/

[2]
https://sources.debian.org/src/golang-google-genproto/0.0~git20210726.e7812ac-2/firestore/

[3]
https://sources.debian.org/src/golang-google-genproto/0.0~git20210726.e7812ac-2/protobuf

[issue1015]
https://github.com/googleapis/go-genproto/issues/1015

[pr#901]
https://github.com/googleapis/go-genproto/pull/901

[googleapi]
https://tracker.debian.org/pkg/golang-google-api

Bug#1066043: RFS: lem/2022-12-10+dfsg-1 [ITP] -- Tool merging math and logic for executable definitions (tool)

[Bo YU]

Hi Philip,

Thanks for reviewing the package again.

On Mon, Jun 10, 2024 at 11:31 PM Bo YU  wrote:
>
> Hi philip!
>
> On Thu, May 30, 2024 at 1:21 AM Phil Wyett  wrote:
> >
> > Hi Bo,
> >
> > Bringing onto RFS now and for all reviews in the future as was requested on 
> > IRC.
>
> Many thanks for it. I was just missing the message to fail to notice
> it and any review on IRC(if have), please tell me any issue again if I
> did not response to in time.
>
> >
> > Bo, As was discussed on the mentors webite. The package review has taken 
> > place
> > and I believe this package is now ready for entry into Debian. Many thanks 
> > for
> > creating this package for Debian.
> >
> > Note: If any other mentors/developers would like to offer constructive 
> > criticism
> > on the package it would be gratefully received.
>

May I know the status of the review for the package? Sorry if I am not
polite to ask about the progress of this. I wonder if something is
forgetten in case.

The package is main blocker for linksem[0] and may need more time to
review it for Debian, So I'm going to take the liberty of asking.

Sorry again.

BR,
Bo

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

> Yeah, thanks again. I eagerly hope to receive any reviews that can
> improve it and please let me know any issues.
>
> BR,
> Bo
> >
> > Regards
> >
> > Phil
> >
> > --
> >
> > Website: https://kathenas.org
> >
> > Instagram: https://instagram.com/kathenasorg/
> >
> > Buy Me A Coffee: https://buymeacoffee.com/kathenasorg

Bug#1073608: mksh: move aliased files from / to /usr (DEP17)

[Thorsten Glaser]

Hi Guillem,

>These directories are included because the package should be
>self-contained and ship all required parent directories, otherwise
>dpkg would fail to unpack as you mentioned (even though there's

right.

>generally the Essential set in play), and so that the directory
>"ref-counting" (as a shared resource) works and the last package
>shipping it that gets removed/purged (regardless of the order) can
>properly remove all owned entries. Also for «dpkg -S»'s sake.

If I omit just the top-level directories (bin, etc, usr),
these things all still work (see my previous message), and
I specifically tested dpkg -S both on unmerged bookworm (a
buildd chroot, hence unmerged) and merged sid (chroot).

>> Hmh, lintian warns, and dpkg needs the directories present if
>> not in the .deb, but most likely we c̲a̲n̲ skip top-level dirs.
>
>It looks like you went in this direction for the packages in Debian.

No, I have not uploaded anything yet. I only attached as experiment…
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1073608;filename=mksh_59c-38_amd64.deb;msg=39
… to this bugreport, for inspection by Helmut and others to see
whether this approach will suffice as I refuse to introduce trouble
for users by moving the files around.

Could you please have a look at it, compared with 59c-37 in sid,
to see whether this would work for you? My tests indicate so.

Directory refcounting is not a problem as a package that does not
ship say /bin in its data.tar can create a symlink in /bin/ as part
of the maintainer scripts. The top-level directories are Essential.

>But I'd ask you to please stop doing that, as I consider this to also
>be breaking dpkg assumptions. And as part of the filesystem metadata

Huh, then we’re at an impasse… although, again, the implicit
“base-files has to be extracted first” with base-files containing
the /bin symlink will suffice for any normal operation, and as to
Helmut saying that “dpkg-deb -x” will cause problems, I’ll have to
defer this to you as dpkg maintainer to fix.

>In the future my plan is to add a special dpkg filesystem metadata type
[…]

That’d be good, except…

>parent). So the data.tar would contain /usr/bin/, the package

… no, data.tar should still be able to contain /bin/.
The CTTE decision for the installed OS to be usrmerged has no
bearing on individual packages’ layout after all, and the .deb
files could conceivably also be used on nōn-usrmerged systems,
so this entire “fun” needs to be done outside of packages (other
than base-files and the Essential set, of course).

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

Bug#1073456: RFS: colorize/0.66-1 -- Colorizes text on terminal with ANSI escape sequences

[Phil Wyett]

Hi Steven,

Preamble...

Thanks for taking time to create this package and your contribution to Debian.

The below review is for assistance. It is offered to help submitters of
packages to Debian mentors improve their packages prior to possible
sponsorship into Debian. There is no obligation on behalf of the subitter to
make any alterations based upon information provided in the review.

Review...

1. Build: Good

2. Lintian: Information

I: colorize source: debian-watch-uses-insecure-uri 
http://cgit.refcnt.org/colorize.git/refs/ [debian/watch:2]

I: colorize source: older-debian-watch-file-standard 3 [debian/watch]

I: colorize source: vcs-field-uses-insecure-uri Browser 
http://cgit.refcnt.org/colorize.git/

I: colorize source: vcs-field-uses-insecure-uri Git
git://refcnt.org/colorize.git

3. Licenses: Good

4. Build Twice (sudo pbuilder build --twice .dsc): Good

5. Install (No previous installs): Good

6. Upgrade (Over previous installs if any): Good

Regards

Phil

-- 

Internet Relay Chat (IRC): kathenas

Website: https://kathenas.org

Instagram: https://instagram.com/kathenasorg/

Buy Me A Coffee: https://buymeacoffee.com/kathenasorg


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

Bug#1074061: /usr/sbin/gdm3: gdm3+nouveau/nvidia 535 blank login screen with DisplayLink, worked with nvidia 525

[Jonathan Kamens]

Package: gdm3
Version: 46.0-2+b3
Severity: normal
File: /usr/sbin/gdm3

Dear Maintainer,

I have an NVidia graphics card. The following problem occurs both when
I am using the NVidia 535 driver and when I am using the open-source
Nouveau driver, i.e., when I completely purge all *nvidia* packages
from my system and reboot. This problem did _not_ occur with the
NVidia 525 driver before I upgraded to 535, and indeed I believe
that's the reason why I previously chose not to upgrade to 535.
Apparently moving forward that's not going to be an option because 525
is deprecated, so if this issue isn't fixed there's no longer a
workaround for me. :-/

I have two screens plugged into a DisplayLink hub.

When I have automatic login enabled in /etc/gdm3/daemon.conf, I can
reboot my system and go straight to being logged in with no trouble.

However, when I disable automatic login and reboot, or restart the gdm
service, or just log out from the automatic login session, then both
of my screens get _some_ signal from the computer after gdm starts up,
i.e., both monitors think they're displaying an image from the
computer rather than being in power-save mode, and indeed there's even
an X cursor on one monitor that I can move with my mouse, but the
login screen does not appear.

If I unplug both monitors from the DisplayLink hub and plug one of
them directly into the computer, the login screen immediately appears.

Note: if there is someone qualified who wants to investigate this
issue but the lack of a DisplayLink hub is impeding your ability to do
that, then I will pay to send you one either by shipping you one of my
extras or just reimbursing you for the cost of ordering one. I would
like to see this fixed and while I don't have the technical knowledge
or experience to fix it myself I am happy to put up enough money to
supply someone else with the hardware they need to work on it.

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

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

Versions of packages gdm3 depends on:
ii  accountsservice   23.13.9-6.1
ii  adduser   3.137
ii  dbus [default-dbus-system-bus]1.14.10-4+b1
ii  dbus-bin  1.14.10-4+b1
ii  dbus-daemon   1.14.10-4+b1
ii  dconf-cli 0.40.0-4+b2
ii  dconf-gsettings-backend   0.40.0-4+b2
ii  debconf [debconf-2.0] 1.5.86
ii  gir1.2-gdm-1.046.0-2+b3
ii  gnome-session [x-session-manager] 46.0-2
ii  gnome-session-bin 46.0-2
ii  gnome-session-common  46.0-2
ii  gnome-settings-daemon 46.0-1+b3
ii  gnome-shell   44.9-2+b1
ii  gnome-terminal [x-terminal-emulator]  3.52.2-1
ii  gsettings-desktop-schemas 46.0-1
ii  libaccountsservice0   23.13.9-6.1
ii  libaudit1 1:3.1.2-4
ii  libc6 2.38-13
ii  libcanberra-gtk3-00.30-17
ii  libcanberra0  0.30-17
ii  libgdk-pixbuf-2.0-0   2.42.12+dfsg-1
ii  libgdm1   46.0-2+b3
ii  libglib2.0-0t64   2.80.2-2
ii  libglib2.0-bin2.80.2-2
ii  libgtk-3-0t64 3.24.42-1
ii  libgudev-1.0-0238-5
ii  libjson-glib-1.0-01.8.0-2+b1
ii  libkeyutils1  1.6.3-3
ii  libpam-modules1.5.3-7
ii  libpam-runtime1.5.3-7
ii  libpam-systemd [logind]   256-1
ii  libpam0g  1.5.3-7
ii  librsvg2-common   2.58.0+dfsg-1
ii  libselinux1   3.5-2+b2
ii  libsystemd0   256-1
ii  libx11-6  2:1.8.7-1+b1
ii  libxau6   1:1.0.9-1+b1
ii  libxcb1   1.17.0-2
ii  libxdmcp6 1:1.1.2-3+b1
ii  openbox [x-window-manager]3.6.1-12+b1
ii  polkitd   124-2
ii  procps2:4.0.4-4
ii  systemd-sysv  256-1
ii  ucf   3.0043+nmu1
ii  x11-common1:7.7+23
ii  x11-xserver-utils 7.7+10+b1
ii  xterm [x-terminal-emulator]   392-1

Versions of packages gdm3 r

Bug#1074060: RM: yade/experimental -- ROM; newer version is available in testing/sud

[Anton Gladky]

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


Dear FTP team,

please remove yade from experimental, as the newer version
is available in the testing//sid. Thank you!
 
Regards

Anton

Bug#1071027: hdrmerge: FTBFS with exiv2 0.28

[Pino Toscano]

Source: hdrmerge
Followup-For: Bug #1071027
X-Debbugs-Cc: t...@debian.org

Alex,

would you please take a look at this? hdrmerge is one of the very few
sources that still does not support Exiv2 0.28+, and I'm preparing the
transition for it soon.

Thanks in advance!
-- 
Pino

Bug#1073207: RFS: cevomapgen/34-1 -- External Map Generator for C-Evo

[Phil Wyett]

Hi Peter,

Preamble...

Thanks for taking time to create this package and your contribution to Debian.

The below review is for assistance. It is offered to help submitters of
packages to Debian mentors improve their packages prior to possible
sponsorship into Debian. There is no obligation on behalf of the subitter to
make any alterations based upon information provided in the review.

Review...

1. Build: Good

2. Lintian: Warning

W: c-evo-map-gen: unknown-field Static-Built-Using
N: 
N:   See the Policy Manual for a list of the possible fields in a package
N:   control files.
N: 
N:   Please refer to Binary package control files – DEBIAN/control (Section
N:   5.3) in the Debian Policy Manual and Debian source control files – .dsc
N:   (Section 5.4) in the Debian Policy Manual for details.
N: 
N:   Visibility: warning
N:   Show-Always: no
N:   Check: fields/unknown
N:   Renamed from: unknown-field-in-dsc unknown-field-in-control

3. Licenses: Good

4. Build Twice (sudo pbuilder build --twice .dsc): Good

5. Install (No previous installs): Good

6. Upgrade (Over previous installs if any): Good

Regards

Phil

-- 

Internet Relay Chat (IRC): kathenas

Website: https://kathenas.org

Instagram: https://instagram.com/kathenasorg/

Buy Me A Coffee: https://buymeacoffee.com/kathenasorg


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

Bug#1074058: Missing x509 certificate valdiation on TLS-based server-server links (fix for Debian 10)

[Christoph Biedl]

Package: ngircd
Version: 25-2
Severity: important
Tags: patch
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de
Control: fixed 26.1-1+deb11u1
Control: fixed 26.1-1+deb12u1
Control: fixed 27~rc1-1

A long-standing issue was fixed in a recent version of ngircd, a
lightweight Internet Relay Chat server:

In a TLS-based server-server connection, the server certificate is
not validated.

github issue: https://github.com/ngircd/ngircd/issues/120

For reasons both upstream and I fail to understand, no CVE number was
assigned by MITRE.

For Debian unstable and testing, this has been fixed in 27~rc1-1,
uploaded April 13th.

For Debian 12 (stable, bookworm) and 11 (oldstable, bullseye), this will
be fixed in the upcoming stable point release on June 29th.

See https://bugs.debian.org/1074018 for details.

For Debian 10 (oldoldstable, buster), downstream distributions based on
it might want to peruse the attached debdiff. It fixes two other issues,
just the way it was done for the two newer stable releases:

1. In a server-server connection, a connection may still use
plain text despite the connection ought to be TLS-based.

2. Some IRC services might send an empty string for the hostname to
implement the "uncloak host" functionality, leading to a protocol
violation in subsequent "WHOIS" or other commands against the ngircd
server.

Christoph
diff -Nru ngircd-25/debian/changelog ngircd-25/debian/changelog
--- ngircd-25/debian/changelog  2019-01-28 18:47:07.0 +0100
+++ ngircd-25/debian/changelog  2024-05-01 10:00:00.0 +0200
@@ -1,3 +1,13 @@
+ngircd (25-2+deb10u1) buster; urgency=high
+
+  * Cherry-pick "Respect "SSLConnect" option for incoming
+connections". Closes: #1067237
+  * Cherry-pick "Support for server certificate validation on server
+links [S2S-TLS]"
+  * Cherry-pick "METADATA: Fix unsetting "cloakhost""
+
+ -- Christoph Biedl   Wed, 01 May 2024 
10:00:00 +0200
+
 ngircd (25-2) unstable; urgency=medium
 
   * Re-enable compression support
diff -Nru ngircd-25/debian/ngircd.conf ngircd-25/debian/ngircd.conf
--- ngircd-25/debian/ngircd.conf2015-12-10 23:48:06.0 +0100
+++ ngircd-25/debian/ngircd.conf2024-05-01 10:00:00.0 +0200
@@ -254,6 +254,15 @@
 [SSL]
# SSL-related configuration options.
 
+   # SSL Trusted CA Certificates File for verifying peer certificates.
+   # (Default: not set; so no certificates are trusted)
+   ;CAFile = /etc/ssl/certs/ca-certificates.crt
+
+
+   # Certificate Revocation File (for marking otherwise valid
+   # certficates as invalid)
+   ;CRLFile = /etc/ssl/CA/crl.pem
+
# SSL Server Key Certificate
;CertFile = /etc/ssl/certs/server.crt
 
@@ -347,6 +356,10 @@
# Connect to the remote server using TLS/SSL (Default: false)
;SSLConnect = yes
 
+   # Verify the TLS certificate presented by the remote server
+   # (Default: yes)
+   ;SSLVerify = yes
+
# Define a (case insensitive) list of masks matching nicknames that
# should be treated as IRC services when introduced via this remote
# server, separated by commas (",").
diff -Nru ngircd-25/debian/ngircd.NEWS ngircd-25/debian/ngircd.NEWS
--- ngircd-25/debian/ngircd.NEWS1970-01-01 01:00:00.0 +0100
+++ ngircd-25/debian/ngircd.NEWS2024-05-01 10:00:00.0 +0200
@@ -0,0 +1,8 @@
+ngircd (25-2+deb10u1) buster; urgency=high
+
+  * This version introduces x509 certificate validation on TLS-based
+server-server links. Existing configurations will likely break, for
+details see , starting at
+"TLS-based server-server links".
+
+ -- Christoph Biedl   Wed, 01 May 2024 
10:00:00 +0200
diff -Nru ngircd-25/debian/ngircd.README.Debian 
ngircd-25/debian/ngircd.README.Debian
--- ngircd-25/debian/ngircd.README.Debian   2014-10-15 19:44:02.0 
+0200
+++ ngircd-25/debian/ngircd.README.Debian   2024-05-01 10:00:00.0 
+0200
@@ -43,6 +43,25 @@
   Repeat the last step for all users that run a daemon providing TLS.
 
 
+TLS-based server-server links
+-
+When linking two ngircd servers, the connection should be TLS-based for
+obvious reasons. To do so, edit ngircd.conf:
+
+* Enable SSLConnect in each [Server] stanza.
+* Define CAFile in the [SSL] stanza. Note that by default *no*
+  certificate is trusted.
+  If the peers's certificate was signed by one of the well-known
+  certificate authorities: Use the suggested value
+  "/etc/ssl/certs/ca-certificates.crt" and install the ca-certificate
+  package.
+  Else set the value to the respective CA's certificate file.
+
+Verfication can be disabled entirely on a per-link base by setting
+SSLVerify to false. This is strongly discouraged as you will lose all
+security by that.
+
+
 DH parameters file
 --
 It is suggested to create a DH params file. If missing, ngIRCd will
diff -Nru 
ngircd-25/debian/patches/0001-Respect-SSLConnect-option-for-incoming-connections.

Bug#1074059: bookworm-pu: package nodejs/18.19.0+dfsg-6~deb12u2

[Adrian Bunk]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: secur...@debian.org, Debian Javascript Maintainers 
, Jérémy Lal 

This upload aims at fixing the failing build of 18.19.0+dfsg-6~deb12u1
on mips64el and mipsel.

The changes are:
- copy mips/flaky_tests.patch with mips64el skip/flaky from 18.19.1+dfsg-6
- add test-http2-forget-closed-streams to flaky on mips64el
- skip two failing tests on mipsel

This is based on reading the output of the build failures last night
with some testing done on amd64.

I am kinda optimistic that it will work and even in the worst case
it shouldn't make anything worse, but there is not enough time to
properly verify it on MIPS before the point release deadline.

I've just uploaded it, feel free to accept or reject it.
diffstat for nodejs-18.19.0+dfsg nodejs-18.19.0+dfsg

 changelog  |7 +++
 patches/mips/flaky_tests.patch |   26 ++
 patches/series |1 +
 3 files changed, 34 insertions(+)

diff -Nru nodejs-18.19.0+dfsg/debian/changelog 
nodejs-18.19.0+dfsg/debian/changelog
--- nodejs-18.19.0+dfsg/debian/changelog2023-12-20 19:07:36.0 
+0200
+++ nodejs-18.19.0+dfsg/debian/changelog2024-06-22 15:21:29.0 
+0300
@@ -1,3 +1,10 @@
+nodejs (18.19.0+dfsg-6~deb12u2) bookworm; urgency=medium
+
+  * Non-maintainer upload.
+  * Skip failing tests on MIPS.
+
+ -- Adrian Bunk   Sat, 22 Jun 2024 15:21:29 +0300
+
 nodejs (18.19.0+dfsg-6~deb12u1) bookworm-security; urgency=medium
 
   * Upstream update.
diff -Nru nodejs-18.19.0+dfsg/debian/patches/mips/flaky_tests.patch 
nodejs-18.19.0+dfsg/debian/patches/mips/flaky_tests.patch
--- nodejs-18.19.0+dfsg/debian/patches/mips/flaky_tests.patch   1970-01-01 
02:00:00.0 +0200
+++ nodejs-18.19.0+dfsg/debian/patches/mips/flaky_tests.patch   2024-06-22 
15:21:29.0 +0300
@@ -0,0 +1,26 @@
+Description: some tests fail on mips64el and mipsel
+ That architecture support improves over time - node 20.x branch has better 
support for mips64el
+ Meanwhile, let those tests fail.
+Forwarded: not-needed
+--- nodejs-18.19.0+dfsg.orig/test/parallel/parallel.status
 nodejs-18.19.0+dfsg/test/parallel/parallel.status
+@@ -97,6 +97,19 @@ test-wasm-web-api: SKIP
+ [$arch==mips64el]
+ # the debug flag is for hacking v8 internals
+ test-debug-args: PASS,FLAKY
++test-cli-node-options: SKIP
++test-crypto-sign-verify: PASS,FLAKY
++test-freeze-intrinsics: PASS,FLAKY
++test-http2-forget-closed-streams: PASS,FLAKY
++test-tls-root-certificates: PASS,FLAKY
++test-vm-global-non-writable-properties: PASS,FLAKY
++test-vm-global-setter: PASS,FLAKY
++test-vm-module-synthetic: PASS,FLAKY
++test-vm-strict-assign: PASS,FLAKY
++
++[$arch==mipsel]
++test-cli-node-options: SKIP
++test-debugger-extract-function-name: SKIP
+ 
+ [$system==solaris] # Also applies to SmartOS
+ # https://github.com/nodejs/node/issues/43457
diff -Nru nodejs-18.19.0+dfsg/debian/patches/series 
nodejs-18.19.0+dfsg/debian/patches/series
--- nodejs-18.19.0+dfsg/debian/patches/series   2023-12-20 18:54:47.0 
+0200
+++ nodejs-18.19.0+dfsg/debian/patches/series   2024-06-22 15:21:29.0 
+0300
@@ -26,3 +26,4 @@
 build/disable_sea_dfsg_postject.patch
 build/test_runner_escape_path.patch
 build/test_dns_resolveany_bad_ancount.patch
+mips/flaky_tests.patch

Bug#834059: dose-builddebcheck: outputs wrong yaml

[Sylvain Beucler]

Reported upstream at https://gitlab.com/irill/dose3/-/issues/18 :)

--
Sylvain

Bug#1073027: RFS: parlatype/4.2-1 -- Minimal audio player for manual speech transcription

[Phil Wyett]

Hi Gabor,

Preamble...

Thanks for taking time to create this package and your contribution to Debian.

The below review is for assistance. It is offered to help submitters of
packages to Debian mentors improve their packages prior to possible
sponsorship into Debian. There is no obligation on behalf of the subitter to
make any alterations based upon information provided in the review.

Review...

1. Build: Good, with minor Warning

dpkg-gencontrol: warning: package libparlatype-dev: substitution variable
${gir:Depends} unused, but is defined
dpkg-gencontrol: warning: package libparlatype-dev: substitution variable
${gir:Provides} unused, but is defined

Something to possibly look at for a future release/upload.

2. Lintian: Good

3. Licenses: Good

4. Build Twice (sudo pbuilder build --twice .dsc): Good

5. Install (No previous installs): Good

6. Upgrade (Over previous installs if any): Good

Regards

Phil

-- 

Internet Relay Chat (IRC): kathenas

Website: https://kathenas.org

Instagram: https://instagram.com/kathenasorg/

Buy Me A Coffee: https://buymeacoffee.com/kathenasorg


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

Bug#1074057: ITP: djstub -- DJGPP-compatible stub manipulation tools

[Stephen Kitt]

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

* Package name: djstub
  Version : 0.0~git20240621.49e7ba6-1
  Upstream Author : Stas Sergeev
* URL : https://github.com/stsp/djstub
* License : GPL
  Programming Lang: C
  Description : DJGPP-compatible stub manipulation tools

 This package provides DJGPP-compatible tools to manipulate stubbed
 executables, i.e. the MS-DOS MZ launcher for DOS-extended binaries:
 .
  - djstubify to modify the stub itself, in COFF and PE executables;
  - djlink to link ELF binaries and produce a dj64 executable;
  - djstrip to strip dj64 executables.
 .
 It includes a dj64-compatible stub, for use with dosemu2. It can be
 used with go32-compatible stubs, but no such stub is included.


This is a build dependency for dosemu2-related tools.

Bug#984800: Remove dependency on cgroup-tools

[Bastian Germann]

Control: retitle -1 mininet: support for cgroup v2

On Fri, 27 Aug 2021 22:54:38 +0200 Santiago Ruano wrote:

Control: title -1 mininet: support for cgroup v2

Bug#1074056: ITP: golang-github-goccy-go-json -- Fast JSON encoder/decoder compatible with encoding/json

[Mathias Gibbens]

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

* Package name: golang-github-goccy-go-json
  Version : 0.10.3-1
  Upstream Author : Masaaki Goshima
* URL : https://github.com/goccy/go-json
* License : BSD-3-clause, Expat
  Programming Lang: Go
  Description : Fast JSON encoder/decoder compatible with encoding/json

 Drop-in replacement of encoding/json that is fast and supports
 flexible customization with options. Can propagate context.Context
 to MarshalJSON or UnmarshalJSON and dynamically filter the fields
 of the structure type-safely.

This is a new dependency required to update golang-github-minio-minio-
go-v7 and will be team-maintained within the Go Packaging Team.


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

Bug#1074055: rust-roaring: please update to v0.10.5

[Jonas Smedegaard]

Package: rust-roaring
Version: 0.10.2-1+b1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to (at least) v0.10.5.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmZ247oACgkQLHwxRsGg
ASHUnRAAo7F7eXdncigbvfoA+RALAOeRlIIStqGuefRBqE+HRHZItVffGy8iF58j
ZBkg1JmifZbbh8XykSdhCaFm3P4CcCH/gsj7TfkjzqnvJtnf9CjWS1kkggOLWoI8
Z6YQefopKmRLdIwywy20uEIuRQ9w1XfoFxWTlmj5292/JoFehwzkaO/zeybmMOoX
BJKCMQTe5R5i7NBYlnyK3K0/r6Xfj0reJKNsfCAIAuLfIB1VMFd3BSUB4Kdon1Hy
Nl+GRYFlag37GywXqEK4W5bJjAWwKSkbKbhOzWdyemZhsL85svK2emD1dxZv5Nij
eN65+QEF2bvqA+TXfsxZXR+mtVqzXGi/ctv8MwXb6p6kVdS0NpxQWzG+qkltcYVi
Y4lmr6r1Ai4PBlJR4TWI89u5sX8Pne1k46ZcfZVWfaeGA6mgUt/kAyqLngN+ZYKX
HQ89ZydM08v2oViD+H0ClpgZFIL+dVj/szA54W80dPj/r4C1WuukCXOJDEZb4/f0
i+utMUKH+Lm00FrMlPMnX46F85TXy9fNzGbdTsmNuomsGHpZI3cJ7eeMfIkm0c4w
f1mbDx2Ex6DTaqmTcJAYQNQjoXjCCeVaIPuyfSv2swZThmRdA34hjK/RMZ7HJXkZ
bZa2q3DcSlt8TJRpmT5yN4sqbiCXKRLhsfhlWPdNhu1wYf6UBTU=
=14G8
-END PGP SIGNATURE-

Bug#1074054: bullseye-pu: package gdk-pixbuf/2.42.2+dfsg-1+deb11u2

[Jeremy Bícha]

Package: release.debian.org
Tags: bullseye
X-Debbugs-Cc: gdk-pix...@packages.debian.org, t...@security.debian.org
Control: affects -1 + src:gdk-pixbuf
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
gdk-pixbuf is affected by CVE-2022-48622, a memory corruption via
crafted .ani files, cf. #1071265.

[ Impact ]
At least denial of service but potentially as well arbitrary code
execution. The Debian Security Team has classified it as no-dsa and
requested that we do a stable update for this issue if possible.

[ Tests ]
This is the same set of patches used in Ubuntu 22.04 LTS "Jammy".

[ Risks ]
Isolated changes, and the fix landed in Trixie a month ago. Similar
fix being applied to Bookworm now also. See
https://bugs.debian.org/1073234

[ 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 oldstable
  [x] the issue is verified as fixed in unstable

[ Changes ]
Three commits cherry-picked from upstream:

  * ANI: Reject files with multiple anih chunks (CVE-2022-48622)
(Closes: #1071265)
  * ANI: Reject files with multiple INAM or IART chunks
  * ANI: Validate anih chunk size

The two other commits are not for CVE-2022-48622 but additional
hardening and fixing changes related to the ANI code.

Updated debian/gbp.conf to point to the debian/bullseye packaging branch.

Thank you,
Jeremy Bícha


gdk-pixbuf-bullseye.debdiff
Description: Binary data

Bug#1069776: RFP: uv -- an extremely fast Python package installer and resolver, written in Rust

[Emmanuel Arias]

Control: retitle -1 ITP: uv -- an extremely fast Python package installer and 
resolver, written in Rust
Control: owner eam...@debian.org

Hi!

I'm interest in work on it.

Cheers,
Emmanuel


signature.asc
Description: PGP signature

Bug#1072764: node-multiparty: FTBFS: autobuilder hangs

[Paul Gevers]

Hi,

On Fri, 7 Jun 2024 17:23:17 +0200 Santiago Vila  wrote:

During a rebuild of all packages in unstable, your package failed to build:


The same seems to happen on ci.d.n on all architectures. The timeout 
there is 1 seconds (or 2:47h).


I'm going to add node-multiparty to the ci.d.n reject_list, I'll remove 
it once this bug is fixed.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1073255: Qt 6 bindings for gpgme

[Andreas Metzler]

On 2024-06-20 Andreas Metzler  wrote:
> On 2024-06-19 Ingo Klöcker  wrote:
> [...]
>> It's likely that we'll start adding new headers only for Qt 6 once we stop 
>> doing feature releases of a Qt 5 based Kleopatra. So, yes, they are 
>> identical 
>> /now/ but most likely will not stay that way.

> Thank you for the explanation.

I have updated the packaging draft, adding the upstream change for Qt 5
and Qt 6 include split 09827ffc7745e7dc4275f1c6e46531a959be1f71.

I think this is basically ready for experimental.

cu Andreas

Bug#1073992: pci.ids: configuration fails

[Martin-Éric Racine]

la 22. kesäk. 2024 klo 14.39 Chris Hofstaedtler (z...@debian.org) kirjoitti:
>
> On Fri, Jun 21, 2024 at 01:42:59PM +0300, Martin-Éric Racine wrote:
> > APT logs and 'dpkg -L debconf' are attached.
>
> Could you also attach dpkg.log? That might reveal which package was
> deconfigured there.

Attached.

Martin-Éric
2024-06-21 10:50:49 startup archives unpack
2024-06-21 10:50:57 upgrade sysvinit-utils:i386 3.09-1 3.09-2
2024-06-21 10:50:57 status half-configured sysvinit-utils:i386 3.09-1
2024-06-21 10:50:57 status unpacked sysvinit-utils:i386 3.09-1
2024-06-21 10:50:57 status half-installed sysvinit-utils:i386 3.09-1
2024-06-21 10:50:58 status triggers-pending man-db:i386 2.12.1-2
2024-06-21 10:50:58 status unpacked sysvinit-utils:i386 3.09-2
2024-06-21 10:51:00 startup packages configure
2024-06-21 10:51:00 configure sysvinit-utils:i386 3.09-2 
2024-06-21 10:51:00 status unpacked sysvinit-utils:i386 3.09-2
2024-06-21 10:51:00 status half-configured sysvinit-utils:i386 3.09-2
2024-06-21 10:51:01 status installed sysvinit-utils:i386 3.09-2
2024-06-21 10:51:02 startup archives unpack
2024-06-21 10:51:03 upgrade ntfs-3g:i386 1:2022.10.3-2 1:2022.10.3-3
2024-06-21 10:51:03 status triggers-pending initramfs-tools:all 0.142
2024-06-21 10:51:03 status half-configured ntfs-3g:i386 1:2022.10.3-2
2024-06-21 10:51:03 status unpacked ntfs-3g:i386 1:2022.10.3-2
2024-06-21 10:51:03 status half-installed ntfs-3g:i386 1:2022.10.3-2
2024-06-21 10:51:04 status unpacked ntfs-3g:i386 1:2022.10.3-3
2024-06-21 10:51:05 upgrade libntfs-3g89t64:i386 1:2022.10.3-2 1:2022.10.3-3
2024-06-21 10:51:05 status triggers-pending libc-bin:i386 2.38-13
2024-06-21 10:51:05 status half-configured libntfs-3g89t64:i386 1:2022.10.3-2
2024-06-21 10:51:05 status unpacked libntfs-3g89t64:i386 1:2022.10.3-2
2024-06-21 10:51:06 status half-installed libntfs-3g89t64:i386 1:2022.10.3-2
2024-06-21 10:51:06 status unpacked libntfs-3g89t64:i386 1:2022.10.3-3
2024-06-21 10:51:07 upgrade libgprofng0:i386 2.42-4 2.42.50.20240618-1
2024-06-21 10:51:07 status half-configured libgprofng0:i386 2.42-4
2024-06-21 10:51:07 status unpacked libgprofng0:i386 2.42-4
2024-06-21 10:51:08 status half-installed libgprofng0:i386 2.42-4
2024-06-21 10:51:09 status unpacked libgprofng0:i386 2.42.50.20240618-1
2024-06-21 10:51:09 upgrade libctf0:i386 2.42-4 2.42.50.20240618-1
2024-06-21 10:51:09 status half-configured libctf0:i386 2.42-4
2024-06-21 10:51:09 status unpacked libctf0:i386 2.42-4
2024-06-21 10:51:09 status half-installed libctf0:i386 2.42-4
2024-06-21 10:51:10 status unpacked libctf0:i386 2.42.50.20240618-1
2024-06-21 10:51:10 upgrade libctf-nobfd0:i386 2.42-4 2.42.50.20240618-1
2024-06-21 10:51:10 status half-configured libctf-nobfd0:i386 2.42-4
2024-06-21 10:51:10 status unpacked libctf-nobfd0:i386 2.42-4
2024-06-21 10:51:11 status half-installed libctf-nobfd0:i386 2.42-4
2024-06-21 10:51:11 status unpacked libctf-nobfd0:i386 2.42.50.20240618-1
2024-06-21 10:51:11 upgrade binutils-i686-linux-gnu:i386 2.42-4 
2.42.50.20240618-1
2024-06-21 10:51:11 status half-configured binutils-i686-linux-gnu:i386 2.42-4
2024-06-21 10:51:11 status unpacked binutils-i686-linux-gnu:i386 2.42-4
2024-06-21 10:51:12 status half-installed binutils-i686-linux-gnu:i386 2.42-4
2024-06-21 10:51:14 status unpacked binutils-i686-linux-gnu:i386 
2.42.50.20240618-1
2024-06-21 10:51:15 upgrade binutils:i386 2.42-4 2.42.50.20240618-1
2024-06-21 10:51:15 status half-configured binutils:i386 2.42-4
2024-06-21 10:51:15 status unpacked binutils:i386 2.42-4
2024-06-21 10:51:15 status half-installed binutils:i386 2.42-4
2024-06-21 10:51:15 status unpacked binutils:i386 2.42.50.20240618-1
2024-06-21 10:51:16 upgrade libbinutils:i386 2.42-4 2.42.50.20240618-1
2024-06-21 10:51:16 status half-configured libbinutils:i386 2.42-4
2024-06-21 10:51:16 status unpacked libbinutils:i386 2.42-4
2024-06-21 10:51:16 status half-installed libbinutils:i386 2.42-4
2024-06-21 10:51:17 status unpacked libbinutils:i386 2.42.50.20240618-1
2024-06-21 10:51:17 upgrade binutils-common:i386 2.42-4 2.42.50.20240618-1
2024-06-21 10:51:17 status half-configured binutils-common:i386 2.42-4
2024-06-21 10:51:17 status unpacked binutils-common:i386 2.42-4
2024-06-21 10:51:17 status half-installed binutils-common:i386 2.42-4
2024-06-21 10:51:20 status unpacked binutils-common:i386 2.42.50.20240618-1
2024-06-21 10:51:20 upgrade libsframe1:i386 2.42-4 2.42.50.20240618-1
2024-06-21 10:51:20 status half-configured libsframe1:i386 2.42-4
2024-06-21 10:51:20 status unpacked libsframe1:i386 2.42-4
2024-06-21 10:51:21 status half-installed libsframe1:i386 2.42-4
2024-06-21 10:51:21 status unpacked libsframe1:i386 2.42.50.20240618-1
2024-06-21 10:51:22 upgrade libbpf1:i386 1:1.4.2-1 1:1.4.3-1
2024-06-21 10:51:22 status half-configured libbpf1:i386 1:1.4.2-1
2024-06-21 10:51:22 status unpacked libbpf1:i386 1:1.4.2-1
2024-06-21 10:51:22 status half-installed libbpf1:i386 1:1.4.2-1
2024-06-21 10:51:22 status unpacked libbpf1:i386 1:1.4.3-1
2024-06

Bug#1070340: Bug CVE-2023-34151: Please add this doc here

[Bastien Roucariès]

Hi,

Could you post as plain texte the document you put in a google doc and the 
image used as attached document ?

It will help other to reproduce

Thanks

rouca

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

Bug#1072922: nullmailer: "sendmail -bs" crashes: "traps: nullmailer-smtp[15059] general protection fault ip:7f0368d73dd9 sp:7fff5e3d7088 error:0 in libc.so.6[7f0368c41000+157000]"

[Bernhard Übelacker]

Am 22.06.24 um 00:42 schrieb Bernhard Übelacker:


I did some archaeology and found the issue got visible
at 2017-12-30 in the Buster development cycle with the
migration of nullmailer 1:2.1-5 into testing.



debian-9-stretch: 
Connection closed with child process.
testing https://snapshot.debian.org/archive/debian/20171229T045928Z/: 
Connection closed with child process.
testing https://snapshot.debian.org/archive/debian/20171230T035716Z/: Child 
process closed connection unexpectedly. nullmailer (1:2.1-5) over (1:1.13-1.2) 
...
debian-10-buster: Child 
process closed connection unexpectedly.



Hello,
trying to go more into detail a git bisect
shows following upstream commit [1].

Kind regards,
Bernhard


https://snapshot.debian.org/package/nullmailer/1%3A1.13-1.2/: 
Connection closed with child process.
git checkout 1.13:
Connection closed with child process.
1.13-68-g2e30750: 
Connection closed with child process.
1.13-69-g5850a49: Child 
process closed connection unexpectedly.
git checkout 2.0: Child 
process closed connection unexpectedly.
https://snapshot.debian.org/package/nullmailer/1%3A2.0-1/:Child 
process closed connection unexpectedly.


5850a49ade78d36ce33d70c28198b9cf2fb8fbdd is the first broken commit
commit 5850a49ade78d36ce33d70c28198b9cf2fb8fbdd
Author: Bruce Guenter 
Date:   Fri Jan 15 11:40:38 2016 -0600

lib: Add fork_exec wrapper class for launching sub-programs

 lib/Makefile.am |   1 +
 lib/autoclose.h |   7 ++-
 lib/forkexec.cc | 136 
 lib/forkexec.h  |  32 +
 src/inject.cc   | 108 +---
 src/send.cc |   1 +
 src/smtpd.cc|  63 +-
 7 files changed, 217 insertions(+), 131 deletions(-)
 create mode 100644 lib/forkexec.cc
 create mode 100644 lib/forkexec.h


[1] 
https://github.com/bruceg/nullmailer/commit/5850a49ade78d36ce33d70c28198b9cf2fb8fbdd

Bug#950919: cura: unable to remove annoying popup message

[Ernesto Alfonso]

Package: cura
Version: 4.13.0-1
Followup-For: Bug #950919
X-Debbugs-Cc: erjoa...@gmail.com

Dear Maintainer,

Any time I open cura, I see two annoying popup messages:

The plugin AMFReader could not be loaded. Re-installing the plugin
might solve the issue

The plugin TrimeshReader could not be loaded. Re-installing the
plugin might solve the issue

I've tried:

- clicking the "Remove plugin" button in the popup
- attempting the "pip install trimesh" workaround found here: 
https://bugs.launchpad.net/ubuntu/+source/cura/+bug/1960650
- clicking "Marketplace -> Installed", unchecking the two problematic plugins 
and clicking on "Quit cura" to restart

None of these solutions appears to have any effect. 

I saw a reference somewhere to the package python3-trimesh, but "apt-cache 
search trimesh" returned no results, and the package doesn't seem to exist.

I don't really use either of these plugins and would prefer to not have to 
click on the popup every time I start cura.

Thanks,

Ernesto

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

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

Versions of packages cura depends on:
ii  cura-engine 1:4.13.0-1+b1
ii  fdm-materials   4.13.0-1
ii  fonts-open-sans 1.11-2
ii  python3 3.11.2-1+b1
ii  python3-certifi 2022.9.24-1
ii  python3-charon  4.13.0-2
ii  python3-cryptography38.0.4-3
ii  python3-keyring 23.9.3-2
ii  python3-pynest2d4.13~beta-1+b3
ii  python3-pyqt5   5.15.9+dfsg-1
ii  python3-pyqt5.qtopengl  5.15.9+dfsg-1
ii  python3-requests2.28.1+dfsg-1
ii  python3-savitar 4.13.0-2+b3
ii  python3-sentry-sdk  1.9.10-2
ii  python3-serial  3.5-1.1
ii  python3-shapely 1.8.5-2+b1
ii  python3-uranium 4.13.0-1
ii  qml-module-qt-labs-folderlistmodel  5.15.8+dfsg-3
ii  qml-module-qt-labs-settings 5.15.8+dfsg-3
ii  qml-module-qtqml-models25.15.8+dfsg-3
ii  qml-module-qtquick-controls 5.15.8-2
ii  qml-module-qtquick-controls25.15.8+dfsg-2
ii  qml-module-qtquick-dialogs  5.15.8-2
ii  uranium-plugins 4.13.0-1

Versions of packages cura recommends:
ii  python3-zeroconf  0.47.3-1

cura suggests no packages.

-- no debconf information

Bug#1050237: budgie-desktop: Fails to build with mutter >= 45

[Amr Ibrahim]

On Mon, 18 Mar 2024 15:41:52 -0400  wrote:
> Source: budgie-desktop
> Version: 10.8.2-3
> Severity: serious
> Tags: ftbfs sid trixie
> Control: block -1 by 1040005
> 
> budgie-desktop fails to build with mutter 45 (or 46). I have tried to
> do what I could to get magpie into Debian as the preferred replacement
> for budgie-desktop's mutter dependency but ultimately magpie has not
> been accepted into Debian yet.
> 
> It feels impractical to continue delaying updating GNOME Shell in
> Debian when budgie-desktop has a rather low popcon compared to
> gnome-shell. Therefore, I'd like to proceed with the Mutter/GNOME
> Shell transition very soon after the 32-bit time_t transition
> completes. budgie-desktop would be removed from Testing until it is
> buildable and installable again.
> 
> On behalf of the Debian GNOME team,
> Jeremy Bícha


Yes, please proceed with the mutter transition and let budgie-desktop be
removed from Debian testing.

And please remove the blocking bug tag, packaging magpie has been stuck for
several months.

Bug#1074053: icingaweb2-module-idoreports: [INTL:de] updated German po file translation

[hermann-Josef Beckers]

Package: icingaweb2-module-idoreports
Version: 0.10.1-3
Severity: wishlist
Tags: patch l10n

Please find the updated German po file translation for
icingaweb2-module-idoreports
attached.

If you update your template, please use 'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the German
translation.

Yours
Hermann-Josef Beckers



icingaweb2-module-idoreports_0.10.1-3_de.po.bz2
Description: application/bzip

Bug#1071589: RFS: radsecproxy/1.10.1-1 -- RADIUS protocol proxy supporting RadSec

[Phil Wyett]

Hi Sven,

Preamble...

Thanks for taking time to create this package and your contribution to Debian.

The below review is for assistance. It is offered to help submitters of
packages to Debian mentors improve their packages prior to possible
sponsorship into Debian. There is no obligation on behalf of the subitter to
make any alterations based upon information provided in the review.

Review...

1. Build: Good

2. Lintian: Good

3. Licenses: Warning

philwyett@ks-windu:~/Development/builder/debian/mentoring/radsecproxy-1.10.1$
lrc
en: Versions: recon 1.10.1  check 3.3.9-1

Parsing Source Tree  
Reading copyright
Running licensecheck 

d/copyright | licensecheck

BSD-3-clause| FSFAPax_check_openssl.m4

I am sure this will be looked at for a future release.

4. Build Twice (sudo pbuilder build --twice .dsc): Good

5. Install (No previous installs): Good

6. Upgrade (Over previous installs if any): Good

Summary...

This package has languished in mentors for a long time. It would be nice to get
it sponsored.

Regards

Phil

-- 

Internet Relay Chat (IRC): kathenas

Website: https://kathenas.org

Instagram: https://instagram.com/kathenasorg/

Buy Me A Coffee: https://buymeacoffee.com/kathenasorg


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

Bug#1067117: budgie-desktop: Fails to build with mutter >= 45

[Amr Ibrahim]

On Mon, 18 Mar 2024 15:41:52 -0400  wrote:
> Source: budgie-desktop
> Version: 10.8.2-3
> Severity: serious
> Tags: ftbfs sid trixie
> Control: block -1 by 1040005
> 
> budgie-desktop fails to build with mutter 45 (or 46). I have tried to
> do what I could to get magpie into Debian as the preferred replacement
> for budgie-desktop's mutter dependency but ultimately magpie has not
> been accepted into Debian yet.
> 
> It feels impractical to continue delaying updating GNOME Shell in
> Debian when budgie-desktop has a rather low popcon compared to
> gnome-shell. Therefore, I'd like to proceed with the Mutter/GNOME
> Shell transition very soon after the 32-bit time_t transition
> completes. budgie-desktop would be removed from Testing until it is
> buildable and installable again.
> 
> On behalf of the Debian GNOME team,
> Jeremy Bícha


Yes, please proceed with the mutter transition and let budgie-desktop be
removed from Debian testing.

And please remove the blocking bug tag, packaging magpie has been stuck for
several months.

Bug#1074052: debian-history package needs to be updated

[Kalyani Kenekar]

Package: debian-history
Version: 2.28
Severity: wishlist

Dear Maintainer,

while browsing the Debian website at
https://www.debian.org/doc/manuals/project-history/leaders.en.html
I noticed that the information about the current Debian Project Leader (DPL)
is outdated.


Upon checking the source data for the website, I found that the commit
https://salsa.debian.org/publicity-team/debian-history/-/commit/2f0bd34f90a59e9cd78ab039e16fd5480452a32a
already includes the updated information reflecting Andreas Tille as the
current DPL

It appears that the 'debian-history' package needs an updated version so
that the Debian website can incorporate this change in its next build.
Could you please consider updating the 'debian-history' package to ensure
the website displays the most current information?

Thank you for your attention to this matter. 
Kalyani Kenekar

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

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

Bug#1073057: nghttp2-proxy: move systemd unit to /usr (DEP17)

[Chris Hofstaedtler]

Hi Tomasz,

On Wed, Jun 12, 2024 at 02:31:52PM +0200, Helmut Grohne wrote:
> [..] In this case, I
> propose using dh_installsystemd as it is fully backports-compatible and
> simplifies the packaging. I'm attaching a patch for your convenience.

I've pushed this into a merge request on salsa:
  https://salsa.debian.org/debian/nghttp2/-/merge_requests/7

Please consider merging + uploading it.

Thanks,
Chris

Bug#1051785: workaround

[C]

> What dconf workaround would that be? I don't see one in the previous
messages to this bug.

Very sorry, I got confused: I read somewhere that creating a file in
/etc/dconf/[subdirectory I can't remember] would've solved this.
I can't find the place I read that anymore, and for some reason I believed
it was in this bug; however, I think it was exactly what the RedHat guide
you linked describes.

>  The intended way to change the settings of the Debian-gdm user is to
edit /etc/gdm3/greeter.dconf-defaults [...]

Understood, thank you; I'll keep this in mind.

> I personally think using smart cards as orthogonal to PAM authentication
> is likely to be more common than using them for PAM authentication [...]

Agreed; I also think there's more users tinkering with smart cards (or
installing smart card tooling as a dependency to some other software) than
there are users using them for authentication.

I don't know exactly what triggered this behaviour in GDM; I tried to
reproduce on a VM by installing opensc (which pulled in pcscd too) and
upgrading first to trixie and then sid, but nothing triggered it. It may be
another package, happy to test if you have suggestions.

> Or, perhaps enable-smartcard-authentication should be one of the fields
> that is included in our example /etc/gdm3/greeter.dconf-defaults ready
> for users to edit? The default could be either true or false, whichever
> seems more appropriate.

IMO this seems appropriate, and matches your intention of not touching
Marco's design; I would default to false and document this as a requirement
for using smart card authentication, but it may be considered a breaking
change (the current default is true, I believe) so I'm not sure how you
want to handle it.

On Fri, Jun 21, 2024 at 3:55 PM Simon McVittie  wrote:

> On Fri, 21 Jun 2024 at 12:55:34 +0200, C wrote:
> > Neither [...], nor setting the gsettings entry
> > on my user or as root, worked and I suspect it's because the value on the
> > Debian-gdm user takes precedence.
>
> Setting a gsettings entry for your user or for root is not expected to
> affect the behaviour of the gdm greeter, because the gdm greeter does not
> run as your user, or as root: it runs as Debian-gdm (or as gdm on Ubuntu).
> So that part is as working as designed: if you want to change the behaviour
> of the greeter, it is the Debian-gdm user's settings that must be changed,
> and no other user's personal settings are going to affect it.
>
> > Neither the dconf workaround suggested above, nor [...], worked
>
> What dconf workaround would that be? I don't see one in the previous
> messages to this bug.
>
> The intended way to change the settings of the Debian-gdm user is to edit
> /etc/gdm3/greeter.dconf-defaults. In this case I think the equivalent would
> be to locate the line "[org/gnome/login-screen]" and fill in
> "enable-smartcard-authentication=false" below it, so it looks
> something like this:
>
> ...
> [org/gnome/login-screen]
> enable-smartcard-authentication=false
> logo='/usr/share/images/vendor-logos/logo-text-version-64.png'
> ...
>
> And then restart gdm (the easiest/most reliable way is to reboot).
>
> However, if you have already used a workaround that edits the user's
> settings, like this one:
>
> > sudo -u Debian-gdm env -u XDG_RUNTIME_DIR -u DISPLAY DCONF_PROFILE=gdm
> > dbus-run-session gsettings set org.gnome.login-screen
> > enable-smartcard-authentication false
>
> then that is probably going to take a higher priority than whatever you
> write into /etc/gdm3/greeter.dconf-defaults.
>
> > For the record I didn't try the other suggestion in the bug (creating
> /etc/
> > pam.d/gdm-password and using update-alternatives to set that as the
> default for
> > gdm-smartcard), but maybe Debian should have this as an option for
> people that
> > run into this issue?
> > If that's a valid option then believe it would be a simple addition to
> have
> > that file (even called something else, like "gdm-no-smartcard",
> > "gdm-password-only", etc.) in place, even if it's not the default.
>
> Marco designed the smart card handling setup that is currently used in
> Debian, so I'm not going to make changes to it without understanding his
> design intentions.
>
> I personally think using smart cards as orthogonal to PAM authentication
> is likely to be more common than using them for PAM authentication, and
> if I understand correctly, using smart cards for authentication needs
> sysadmin configuration *anyway* to associate each smartcard with a user
> ID; so I would personally prefer it if the default was to use ordinary
> password authentication, with some sort of opt-in for using smart cards
> to authenticate, which sysadmins would be expected to enable after they
> have enrolled users (set up the smartcard -> user mapping).
>
> In RHEL, it seems to be opt-in:
>
> https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/using_the_desktop_environment_in_rhel_8/authenticating-the-user-in-the-desktop-e

Bug#1073992: pci.ids: configuration fails

[Chris Hofstaedtler]

On Fri, Jun 21, 2024 at 01:42:59PM +0300, Martin-Éric Racine wrote:
> APT logs and 'dpkg -L debconf' are attached.

Could you also attach dpkg.log? That might reveal which package was
deconfigured there.

Chris

Bug#1073608: mksh: move aliased files from / to /usr (DEP17)

[Guillem Jover]

Hi!

On Thu, 2024-06-20 at 23:27:07 +, Thorsten Glaser wrote:
> Dixi quod…
> >Or, better yet, absence of that entry in the ustar (possibly
> >combined with a Pre-Depends). It’s ridiculous that every pak‐
> >kage ships all those directory entries anyway. That avoids

These directories are included because the package should be
self-contained and ship all required parent directories, otherwise
dpkg would fail to unpack as you mentioned (even though there's
generally the Essential set in play), and so that the directory
"ref-counting" (as a shared resource) works and the last package
shipping it that gets removed/purged (regardless of the order) can
properly remove all owned entries. Also for «dpkg -S»'s sake.

> Hmh, lintian warns, and dpkg needs the directories present if
> not in the .deb, but most likely we c̲a̲n̲ skip top-level dirs.
> I’ll experiment later when less headaches.

It looks like you went in this direction for the packages in Debian.
But I'd ask you to please stop doing that, as I consider this to also
be breaking dpkg assumptions. And as part of the filesystem metadata
tracking support that should be coming to dpkg, I was already thinking
some time ago about checking for this specific case as part of its
integrity checks (detecting and erroring out on missing parent
directories), in addition to refusing to install files inside a
symlink aliasing to a directory to avoid all aliasing problems (which
would make this package uninstallable). Of course this will not be
enforceable on merged systems until the current transition has been
finished and there are no file type conflicts in the archive (so at
least until after trixie).

When it comes to the mention of the canonical path (which you
disagreed with), I think in general this has been understood as the
canonical location in both the filesystem (as in where the file ends
up physically) *and* the dpkg metadata, so that they both match.

I agree that this is *not* the canonical path for the _interface_, and
that is still /bin/, and personally I consider it rather
important that for pathnames that are part of a specified interface
(like shells, ld.so, etc), these get used by callers as such (or no
absolute names be used, and instead relative ones if possible via
PATH-like mechanisms).

In the future my plan is to add a special dpkg filesystem metadata type
to explicitly describe this kind of (optionally) aliased interface so
that if the alias is already present on the system (as represented by
the parent object being a symlink known to dpkg in its metadata tracking)
it will just be shown as an additional pathname in dpkg output and
matched on searches, and if there's no such aliasing then dpkg will
create the required symlink (for the aliased object itself, not its
parent). So the data.tar would contain /usr/bin/, the package
would declare /bin/ as such optionally aliased object, and
then «dpkg -S /bin/» would work regardless of the filesystem
layout, and the object would also always be found on disk either via the
aliased directory on merged systems, or via a symlink from
/bin/ to /usr/bin/ that dpkg creates during
unpack on non-merged systems. So that interface will always be
guaranteed, and the unpack will be safe.

Thanks,
Guillem

Bug#1074014: encode mandatory merged-/usr into policy

[Chris Hofstaedtler]

On Sat, Jun 22, 2024 at 09:42:27AM +0200, Helmut Grohne wrote:
> [..] he came up with a crazy solution where mksh's data.tar contains
> ./bin/mksh but not ./bin on the grounds that ./bin is provided by an
> essential package in all Debian releases.

> I think this approach practically solves a significant chunk of the
> problems listed by DEP17, but it still confuses QA tools and e.g.
> dpkg -S (maybe more). [..]

A fully working, unconfused, dpkg is part of what we want. In my
understanding, we are trying to ship a distribution, IOW a set of
packages that work *together*.

If a confused dpkg was okay, then a lot of the work could have been
skipped.

Chris